Use cases = tasks, uppgifter

En 'actor' är en användare i en viss roll, och kan förutom människa även vara annat program e.d.

En association kallas 'link' i UML. En association uppstår vid varje beroende mellan två objekt. Följande fall kan förekomma:

• Ett objekt skickar ett meddelande till ett annat objekt.
• Ett objekt av viss typ skapar ett objekt av annan typ.
• Ett objekt består av bland annat av ett objekt av en annan typ, eller refererar till ett objekt av en annan typ.
• Ett objekt får ett meddelande med ett argument av en annan objekttyp.

Kort sagt, så fort en objekttyp har behov av att känna till en annan objekttyp så är det en link.

Man använder 7 olika typer av diagram i UML:

1. Use case diagrams
2. Class models
3. Interaction diagrams
4. State diagrams
5. Activity diagrams
6. Implementation diagrams
7. Packages

Dessa beskrivs i korthet nedan.

Man dokumenterar i ett 'use case diagram' vad varje actor kan utföra. Varje actor ritas som en namngiven streckgubbe. Varje use case skrivs i en egen oval. Streck förbinder gubbarna med ovalerna. Ett use case är alltså en uppgift som systemet ska kunna utföra.

I en 'class model' visar man relationer mellan objekt. Varje objekt är ett block, och linjer mellan dem visar relationer. En linje visande att ett objekt är ett exemplar av ett annat objekt (bok, exemplar) har en 1..* eller 0..* vid sig för att indikera ett eller flera alternativt noll eller flera exemplar. En linje som visar att ett objekt kan utföra något på ett annat objekt har handlingen skriven vid sig. T.ex. kund 'köper 1..*' exemplar av en vara. Om ett objekt är en sorts av ett annat objekt möjligtvis resulterande i ett klassarv, använder man en pil där pilhuvudet pekar på 'föräldern'. En anställd i en butik kan handla i samma butik och är då en sorts kund, men vi behöver visa på skillnaden eftersom denne ska ha personalrabatt. Pilen pekar då från anställd till kund, men pilhuvudet mot kund.

Ett 'interaction diagram' visar hur meddelanden går mellan olika objekt vid ett 'use case'. Ett meddelande är då det samma som en klassoperation (anrop av medlemsfunktion).

4. State diagrams

State diagram visar olika tillstånd i rutor med rundade hörn. Överslag mellan tillstånd (även till samma tillstånd) visas med pilar och vidhängande text som förklarar orsaken till tillståndsförändringen. En liten fylld cirkel med en pil mot en ruta visar vilket tillstånd objektet ska starta i när det skapas. Denna kallas startmarkör, och det kan finnas endast en sådan. Om den inte finns är state diagrammet inte fullständigt. Däremot kan det finnas ingen, en eller flera stoppmarkörer, som talar om vid vilka states som objektet är färdiganvänt och kan förstöras. Stoppmarkören är en inringad liten fylld cirkel.

Aktivitetsdiagram visar samspelet mellan olika aktiviteter, uppgifter. En del aktiviteter är beroende av varandra på olika sätt. Följande komponenter ingår:

• En aktivitet visas som en oval (likt en löparbana, en rektangel med halvcirklar som sidor) med en text i som namnger aktiviteten. Tekniskt sett representerar den det statusläge som uppnåtts efter att aktiviteten slutförts.
• En transition, övergång från ett status till ett annat (eller samma) visas som en pil p.s.s. som i ett statusdiagram. Dessa pilar har normalt inte någon förklarande text eftersom de visar övergång efter att aktiviteten slutförts. (Se föregående punkt.)
• Syncronization bar, synkroniseringsband, är ett horisontellt fyllt band som visar samspel mellan aktiviteter. Först när alla akviviteter som leder till bandet (normalt uppifrån) avslutats kan bandet avslutats. Då sker alla övergångar som leder ut från bandet (normalt nedåt). På så vis kan övergångar synkroniseras.
• Desition diamond, beslutsromb, visar hur övergångar kan ledas åt olika håll beroende av villkor som anges i romben.
• Dessutom finns även start och stoppmarkörer, som i ett statusdiagra.

Implementation diagrams, eller genomgörandeschema, visar komponenter och dessas inbördes beroende.

Komponenterna visas som rektanglar med två mindre rektanglar som sticker ut från vänster kortsida (de sticker även in en bit), och representerar till exempel, program, objekt, kompilerade enheter, inlänkade enheter etc. Med komponenter menar man såväl objekttyper som skapade objekt.

Inbördes beroende visas som streckade pilar. Ett beroendes typ kan skrivas bredvid pilen, t.ex. <<rmi>> som betyder att det är ett beroende som tillfredsställs vid runtime, t.ex. vid en client-server lösning.

Om man vill visa hårdvaruinstallationen gör man diagrammet som ett driftsättningsdiagram (implementation diagram). De ingående datorer och annan hårdvara som berörs visas som kuber, vilka har ingående komponenter och beroenden visade på främre ytan. Kuberna är sammanbundna med linjer som visas hur de kopplas samman. Man kan ange hur de kopplas genom att skriva en text ovanför linjen, t.ex. <<LAN>> för lokalt nätverk.

I stort sett allt som kan ingå i de olika diagrammen kallas elemetmodeller (model elements), d.v.s. de olika byggstenar vi använder när vi konstruerar diagrammen. En package (förpackning) är en samling elementmodeller. Man kan finna flera orsaker till att packa ihop ett antal elementmodeller, t.ex. för att öka överskådligheten eller att fördela arbetet. Man kan sedan använda dessa förpackningar som byggelement i vilket som helst av de diagramtyper som ingår i UML.

En package vidsas som en rektangel med en liten rektangel på övre vänstra hörnet, som en flik, med namnet inskrivet. Man brukar inte visa innehållet i den stora rektanglen, men kanske andra ingående packages eller vissa viktiga komponenter. I stället redovisas innehållet it ett annat diagram. Om man har ett verktyg för att rita diagrammen brukar en förpackning vara länkad till motsvarande diagram.