UML-element

Användningsfallsdiagram

Användningsfallsdiagram beskriver samband och beroenden mellan en grupp användningsfall och aktören som deltar i processen.

Det är viktigt att observera att användningsfallsdiagram inte är lämpade att representera konstruktionen, och kan inte beskriva systemets innanmäte. Användningsfallsdiagram är avsedda att möjliggöra kommunikation med framtida användare av systemet, och med kunden. De är till särskild hjälp för att avgöra vilka funktioner som krävs att systemet ska ha. Med andra ord talar användningsfallsdiagram om vad systemet ska göra, men de anger inte — och kan inte ange — hur detta ska åstadkommas.

Umbrello UML Modeller som visar ett användningsfallsdiagram

Umbrello UML Modeller som visar ett användningsfallsdiagram

Användningsfall

Ett användningsfall beskriver — från aktörernas synvinkel — en samling aktiviteter i ett system, som ger upphov till ett konkret, påtagligt resultat.

Användningsfall är beskrivningar av typisk växelverkan mellan användarna av ett system och systemet själv. De representerar systemets yttre gränssnitt, och anger en sorts krav på vad systemet ska göra (kom ihåg, bara vad, inte hur).

Vid arbete med användningsfall, är det viktigt att komma ihåg några enkla regler:

  • Varje användningsfall hör ihop med minst en aktör

  • Varje användningsfall har ett ursprung (dvs. en aktör)

  • Varje användningfall leder till ett relevant resultat (ett resultat med affärsvärde).

Användningfall kan också ha samband med andra användningfall. De tre mest typiska sorters samband mellan användningfall är:

  • <<include>> (innehåller), vilket anger att användningsfallet äger rum inne i ett annat användningsfall

  • <<extends>> (utökar), vilket anger att i vissa fall, eller vid något tillfälle (som kallas en utökningspunkt), kommer ett användningsfall att utökas av ett annat.

  • Generalisering anger att ett användningfall ärver egenskaperna för super-användningsfallet, och kan överskrida några av dem, eller lägga till nya på samma sätt som arv mellan klasser.

Aktör

En aktör är en extern enhet (utanför systemet) som växelverkar med systemet genom att delta i (och ofta inleda) ett användningsfall. Aktörer kan i verkligheten vara människor (till exempel användare av systemet), andra datorsystem eller yttre händelser.

Aktörer representerar inte fysiska människor eller system, utan deras roll. Det betyder att när en person växelverkar med systemet på olika sätt (antar olika roller) representeras han med flera aktörer. En person som till exempel ger kundstöd via telefon och tar emot beställningar från kunden till systemet, skulle representeras av aktören kundstödspersonal och aktören försäljningsassistens.

Beskrivning av användningsfall

En beskrivning av ett användningsfall är en textbaserad berättelse om användningsfallet. Det är ofta i form av en anteckning eller ett dokument som på något sätt är länkat till användningsfallet, och förklarar processerna eller aktiviteterna som äger rum i användningsfallet.

Klassdiagram

Klassdiagram visar de olika klasserna som bygger upp ett system och hur de relateras till varandra. Klassdiagram sägs vara statiska diagram, eftersom de visar klasserna, tillsammans med deras metoder och attribut, samt det statiska förhållandet mellan dem: vilka klasser som känner till andra klasser, eller vilka klasser som är en del av andra klasser, men visar inte metodanrop mellan dem.

Umbrello UML Modeller som visar ett klassdiagram

Umbrello UML Modeller som visar ett klassdiagram

Klass

En klass definierar attributen och metoderna för en mängd objekt. Alla objekt av klassen (instanser av klassen) delar samma beteende, och har samma mängd attribut (varje objekt har sin egen uppsättning). Termen typ används ibland istället för klass, men det är viktigt att nämna att de två inte är samma sak, och att typ är en mer generell term.

Klasser i UML representeras av rektanglar, med klassens namn, och kan också visa klassens attribut och operationer i två fack inne i rektangeln.

Visuell representation av en klass i UML

Visuell representation av en klass i UML

Attribut

Attribut i UML visas åtminstone med sina namn, och kan också visas med typ, ursprungligt värde och andra egenskaper. Attribut kan också visas med synlighet:

  • + Betyder öppna (public) attribut

  • # Betyder skyddade (protected) attribut

  • - Betyder privata (private) attribut

Operationer

Operationer (metoder) visas också åtminstone med sina namn, och kan också visas med parametrar och returtyper. Operationer, precis som attribut, kan visas med sin synlighet:

  • + Betyder öppna (public) operationer

  • # Betyder skyddade (protected) operationer

  • - Betyder privata (private) operationer

Mallar

Klasser kan ha mallar, ett värde som används för en ospecificerad klass eller typ. Malltypen anges när klassen initieras (dvs. ett objekt skapas). Mallar finns i modern C++ och kommer att introduceras i Java 1.5, där de kallas Generics.

Klassassociationer

Klasser kan relateras till (associeras med) varandra på olika sätt:

Generalisering

Arv är ett av de grundläggande koncepten i objektorienterad programmering, där en klass erhåller alla attribut och operationer från klassen den ärver från, och kan överskrida/ändra några av dem, samt lägga till fler egna attribut och operationer.

En generalisering mellan två klasser i UML, placerar dem i en hierarki som representerar arvkonceptet för en härledd klass från en basklass. Generaliseringar i UML representeras med en linje som binder samman de två klasserna, med en pil på basklassens sida.

Visuell representation av en generalisering i UML

Visuell representation av en generalisering i UML

Associationer

En association representerar ett samband mellan klasser, och ger den allmänna semantiken och strukturen för många typer av förbindelse mellan objekt.

Associationer är mekanismen som tillåter att objekt kommunicerar med varandra. De beskriver förbindelsen mellan olika klasser (förbindelsen mellan de verkliga objekten kallas objektförbindelse, eller länk).

Associationer kan ha en roll, som anger associationens syfte, och kan vara enkelriktade eller ömsesidiga (anger om två objekt som deltar i sambandet kan skicka meddelanden till det andra, eller om bara ett av dem känner till det andra). Varje ända av associationen har också ett mångfaldsvärde, som bestämmer hur många objekt på denna sida av associationen som kan relatera till ett objekt på andra sidan.

Associationer i UML representeras som linjer som binder samman klasserna som deltar i sambandet, och kan också visa rollen och mångfalden för var och en av deltagarna. Mångfald visas som ett intervall [minimum..maximum] med icke-negativa värden, med en asterisk (*) på maximumsidan som representerar oändlighet.

Visuell representation av en association i UML

Visuell representation av en association i UML

Aggregering

Aggregeringar är särskilda sorters associationer, där de två deltagande klasserna inte har en likvärdig status, utan utgör ett helhet-del samband. En aggregering beskriver hur klassen som intar rollen som helhet, är sammansatt av (har) andra klasser, som intar rollerna som delar. Klassen som fungerar som helhet har alltid mångfalden ett, för aggregeringar.

Aggregeringar i UML representeras av en association som visar en romb på sidan som hör till helheten.

Visuell representation av en aggregeringsrelation i UML

Visuell representation av en aggregeringsrelation i UML

Sammansättning

Sammansättningar är associationer som representerar mycket starka aggregeringar. Det betyder att sammansättningar också formar helhet-del samband, men att sambandet är så starkt att delarna inte kan existera för sig själv. De finns bara inne i helheten, och om helheten förstörs, försvinner också delarna.

Sammansättning i UML representeras av en ifylld romb på sidan som hör till helheten.

Visuell representation av en sammansättningsrelation i UML

Andra objekt i klassdiagram

Klassdiagram kan innehålla flera andra objekt förutom klasser.

Gränssnitt

Gränssnitt är abstrakta klasser vilket betyder att instanser inte direkt kan skapas från dem. De kan innehålla operationer men inga attribut. Klasser kan ärva från gränssnitt (via en realisationsassociation) och instanser kan därefter skapas av klasserna.

Datatyper

Datatyper är primitiver som typiskt är inbyggda i ett programspråk. Vanliga exempel omfattar heltal och en boolesk typ. De kan inte ha samband med klasser, men klasser kan ha samband med dem.

Uppräkningstyper

Uppräkningstyper är enkla listor med värden. Ett typiskt exempel är en uppräkningstyp av veckodagar. Medlemmar i en uppräkningstyp kallas uppräkningsvärden. Som datatyper kan de inte ha samband med klasser, men klasser kan ha samband med dem.

Paket

Paket representerar namnrymder i ett programspråk. I ett diagram används de för att representera delar i ett system som innehåller mer än en klass, kanske hundratals klasser.

Sekvensdiagram

Sekvensdiagram visar utbyte av meddelanden (dvs. metodanrop) mellan flera objekt, i en specifik, tidsbegränsad situation. Sekvensdiagram lägger särskild vikt vid ordningen och tiden då meddelanden till objekt skickas.

Objekt representeras av vertikala streckade linjer i sekvensdiagram, med objektets namn överst. Tidsaxeln är också vertikal, och ökar neråt, så att meddelanden skickas från ett objekt till ett annat i form av pilar med operationer och parameternamn.

Umbrello UML Modeller som visar ett sekvensdiagram

Umbrello UML Modeller som visar ett sekvensdiagram

Meddelanden kan antingen vara synkrona, den normala typen för meddelandeanrop där kontrollen övergår till det anropade objektet till metoden har kört färdigt, eller asynkront där kontrollen direkt återgår till anropande objekt. Synkrona meddelanden har en vertikal ruta vid sidan om det anropade objektet, för att visa programflödet.

Samarbetsdiagram

Samarbetsdiagram visar växelverkan mellan objekt som deltar i en speciell situation. Det här är mer eller mindre samma information som visas i sekvensdiagram, men där läggs vikten vid hur växelverkan sker i tiden, medan samarbetsdiagram lägger vikten vid sambanden mellan objekten och deras topologi.

I samarbetsdiagram representeras meddelanden från ett objekt till ett annat med pilar, som visar meddelandets namn, parametrar och meddelandesekvensen. Samarbetsdiagram är särskilt lämpade att visa ett särskilt programflöde eller situation, och är bland de bästa diagramtyperna för att snabbt demonstrera eller förklara en process i programmets logik.

Umbrello UML Modeller som visar ett samarbetsdiagram

Umbrello UML Modeller som visar ett samarbetsdiagram

Tillståndsdiagram

Tillståndsdiagram visar de olika tillstånd ett objekt har under sin livstid, och de stimuli som orsakar att objektet ändrar sitt tillstånd.

Tillståndsdiagram ser objekt som tillståndsmaskiner eller finita automater, som kan vara i något av en mängd begränsade tillstånd och som kan ändra sina tillstånd via något av ett begränsat antal stimuli. Ett objekt av typen Nätserver, kan till exempel vara i något av följande tillstånd under sin livstid:

  • Klar

  • Lyssnar

  • Arbetar

  • Stoppad

och händelserna som kan göra att ett objekt byter tillstånd är

  • Objektet skapas

  • Objektet tar emot meddelandet att lyssna

  • En klient begär en anslutning via nätverket

  • En klient avslutar en begäran

  • En begäran körs och avslutas

  • Objektet tar emot meddelandet att stoppa

  • etc

Umbrello UML Modeller som visar ett tillståndsdiagram

Umbrello UML Modeller som visar ett tillståndsdiagram

Tillstånd

Tillstånd är byggblocken i tillståndsdiagram. Ett tillstånd hör till exakt en klass, och representerar en summering av de värden klassens attribut kan inta. Ett UML-tillstånd beskriver det interna tillståndet för ett objekt av en viss klass.

Observera att inte varje ändring av något av ett objekts attribut ska representeras som ett tillstånd, utan bara de ändringar som väsentligt kan påverka objektets arbete.

Det finns två speciella typer av tillstånd: start och slut. De är speciella på det sättet att det inte finns någon händelse som kan göra att ett objekt återgår till sitt starttillstånd, och på samma sätt finns det ingen händelse som gör det möjligt för ett objekt att lämna sitt sluttillstånd när det väl har nåtts.

Aktivitetsdiagram

Aktivitetsdiagram beskriver en följd av händelser i ett system, med hjälp av aktiviteter. Aktivitetsdiagram är en speciell form av tillståndsdiagram, som bara (eller i huvudsak) innehåller aktiviteter.

Umbrello UML Modeller som visar ett aktivitetsdiagram

Umbrello UML Modeller som visar ett aktivitetsdiagram

Aktivitetsdiagram liknar procedurella flödesdiagram, med skillnaden att alla aktiviteter är klart länkade till objekt.

Aktivitetsdiagram hör alltid ihop med en klass, en operation eller ett användningsfall.

Aktivitetsdiagram stöder sekvens- samt parallella aktiviteter. Parallell körning representeras med ikonen Dela upp/samla ihop, och det är inte viktigt för aktiviteter som kör parallellt i vilken ordning de utförs (de kan köras samtidigt eller en i taget).

Aktivitet

En aktivitet är ett enda steg i en process. En aktivitet är ett tillstånd i systemet med intern aktivitet och åtminstone en utgående övergång. Aktiviteter kan också ha mer än en utgående övergång, om de har olika villkor.

Aktiviteter kan bygga upp hierarkier, vilket betyder att en aktivitet kan bestå av flera detaljaktiviteter, där inkommande och utgående övergångar måste passa ihop med de inkommande och utgående övergångarna i detaljdiagrammet.

Hjälpelement

Det finns några få element i UML som inte har något verkligt semantiskt värde för modellen, men som hjälper till att klargöra delar av diagrammen. Dessa element är

  • Textrader

  • Anteckningar och ankare

  • Rutor

Textrader är användbara för att lägga till kort textinformation i ett diagram. Det är fristående text, och har ingen betydelse i själva modellen.

Anteckningar är användbara för att lägga till mer detaljerad information om ett objekt eller en särskild situation. De har den stora fördelen att anteckningar kan ankras vid UML-element för att visa att anteckningen hör till ett särskilt objekt eller situation.

Rutor är fristående rektanglar som kan användas för att gruppera objekt tillsammans, för att göra diagram mer läsbara. De har ingen logisk mening i modellen.

Komponentdiagram

Komponentdiagram visar programkomponenter (antingen komponentteknologier som Kparts, CORBA-komponenter eller Java Beans eller bara delar av systemet som är klart urskiljbara) och artefakterna de består av, som källkodsfiler, programbibliotek eller relationsdatabastabeller.

Komponenter kan ha gränssnitt (dvs. abstrakta klasser med operationer) som tillåter association mellan komponenter.

Utplaceringsdiagram

Utplaceringsdiagram visar komponentinstanserna vid körning och deras associationer. De omfattar noder, som är fysiska resurser, typiskt en enskild dator. De visar också gränssnitt och objekt (klassinstanser).

Objektsambandsdiagram

Objektsambandsdiagram visar begreppsmässig konstruktion av databasprogram. De avbildar de olika objekten (koncepten) i informationssystemet och befintliga samband och begränsningar mellan dem. En utökning av objektsambandsdiagram som kallas 'utökade objektsambandsdiagram' eller 'förbättade objektsambandsdiagram' används för att införliva objektorienterade konstruktionstekniker i diagrammen.

Umbrello UML Modeller som visar ett objektsambandsdiagram

Umbrello UML Modeller som visar ett objektsambandsdiagram

Objekt

Ett objekt är vilket koncept i verkligheten som helst med en oberoende existens. Det kan vara ett objekt som existerar fysiskt (t.ex. dator, robot), eller det kan vara ett objekt som existerar som koncept (t.ex. universitetskurs). Varje objekt har en uppsättning egenskaper, som beskriver objektet.

Observera: Det finns ingen standardnotation för att avbilda objektsambandsdiagram. Olika skrifter om ämnet använder olika notation. Koncepten och notationen för utökade objektsambandsdiagram i Umbrello kommer från följande bok: Elmasri R. and Navathe S. (2004), Fundamentals of Database Systems, 4:e utgåvan, Addison Wesley.

I objektsambandsdiagram representeras objekt av rektanglar, med objektets namn längst upp, och kan också visa objektets attribut i ett annat fack inne i rektangeln.

Visuell representation av ett objekt i ett objektsambandsdiagram

Visuell representation av ett objekt i ett objektsambandsdiagram

Objektattribut

I objektsambandsdiagram visas objektattribut med sina namn i ett annat fack hos objektet de tillhör.

Begränsningar

Begränsningar i objektsambandsdiagram anger restriktioner hos data i informationsschemat.

Det finns fyra typer av begränsningar som stöds i Umbrello:

  • Primär nyckel: Egenskaperna som deklareras som primär nyckel är unika för objektet. Det kan bara finnas en primär nyckel i ett objekt, och ingen av de ingående egenskaperna kan vara tom.

  • Unik nyckel: Uppsättningen egenskaper som deklareras som unika är unika för objektet. Det kan finnas många unika begränsningar för ett objekt. Dess ingående egenskaper kan vara tomma. Unika nycklar och primära nycklar identifierar en rad i en tabell (objekt) på ett unikt sätt.

  • Främmande nyckel: En främmande nyckel är en referensbegränsning mellan två tabeller. Den främmande nyckeln identifierar en kolumn eller en uppsättning kolumner i en (den refererade) tabell. Kolumnerna i den refererade tabellen måste utgöra en primär nyckel eller en unik nyckel.

  • Kontrollbegränsning: En kontrollbegränsning (också känd som tabellkontrollbegränsning) är ett villkor som definierar giltig data när ett objekt i en tabell läggs till eller uppdateras i en relationsdatabas. En kontrollbegränsning tilldelas till varje rad i tabellen. Begränsningen måste vara ett predikat. Det kan hänvisa till en eller flera kolumner i tabellen.

    Exempel: pris >= 0

Koncept hos utökade objektsambandsdiagram

Specialisering

Specialisering är ett sätt att skapa nya objekt med användning av objekt som redan har definierats. De nya objekten, som kallas härledda objekt, tar över (eller ärver) egenskaperna hos de befintliga objekten, som kallas basobjekt. Detta har avsikten att hjälpa till att använda befintlig data med inga eller små förändringar.

I Umbrello kan man definiera separerad och överlappande specialisering.

Separerad specialisering

Separerad specialisering anger att specialiseringens delklasser måste vara separerade. Det betyder att ett objekt som mest kan vara medlem av ett av objekten härledda från specialiseringen.

Visuell representation av separerad specialisering i utökade objektsambandsdiagram

Visuell representation av separerad specialisering i utökade objektsambandsdiagram

Överlappande specialisering

När härledda objekt inte är begränsade att vara separerade, sägs deras objektmängd befinna sig i överlappande specialisering. Det betyder att samma verkliga objekt kan vara medlem i mer än ett av objekten härledda från specialiseringen.

Visuell representation av överlappande specialisering i utökade objektsambandsdiagram

Visuell representation av överlappande specialisering i utökade objektsambandsdiagram

Kategori

Ett härlett objekt sägs vara en kategori när det representerar en objektsamling som är en delmängd av unionen av de skilda objekttyperna. En kategori modelleras när behovet av ett enda superklass/delklass-förhållande med mer än en superklass, där superklasserna representerar olika objekttyper (i likhet med multipla arv i objektorienterad programmering).

Visuell representation av en kategori i utökade objektsambandsdiagram

Visuell representation av en kategori i utökade objektsambandsdiagram