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.
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.
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”.
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 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.
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.
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 (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
Klasser kan relateras till (associeras med) varandra på olika sätt:
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.
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.
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.
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.
Klassdiagram kan innehålla flera andra objekt förutom klasser.
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 ä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 ä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.
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.
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 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.
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
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 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.
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).
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.
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 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 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 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.
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.
I objektsambandsdiagram visas objektattribut med sina namn i ett annat fack hos objektet de tillhör.
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
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 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.
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.
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).