Användningsfallsdiagram (use case)

Ett användningsfallsdiagram visar vem som använder systemet och vad de ska kunna göra med det. Det säger ingenting om klasser, databaser eller knappar — bara vilka som är inblandade och vilka mål de har. Därför är det ofta det första diagrammet man ritar i ett projekt: innan någon vet hur systemet ska byggas, går det att enas om vad det ska kunna.

När du läst detta ska du kunna

Känna igen och namnge delarna i ett användningsfallsdiagram
Skilja på «include» och «extend»
Rita ett diagram med flera aktörer, varav ett externt system
Översätta användningsfall till user stories — och vidare till kod

Vad används det till?

Avgränsa systemet — vad ingår, och vad gör någon annan (ett betalsystem, en annan avdelning)?
Hitta alla användare — det är lätt att glömma administratören eller ett system som anropar ditt API
Prata med beställaren — diagrammet är så enkelt att en kund kan rätta det på ett möte
Planera arbetet — varje användningsfall blir en eller flera user stories i backloggen

Delarna och vad de heter

Del	Hur den ritas	Vad den betyder
Aktör (actor)	Streckgubbe med namn under	En roll som använder systemet — en person eller ett annat system. Inte en specifik person: “Låntagare”, inte “Kalle”
Användningsfall (use case)	Ellips med ett verb + objekt	Något en aktör vill uppnå med systemet: “Låna bok”. Ett mål, inte en knapp
Systemgräns (system boundary)	Ram med systemets namn	Allt innanför bygger vi. Allt utanför — aktörerna — finns redan
Association	Heldragen linje utan pil	Aktören deltar i användningsfallet
Inkludering `«include»`	Streckad pil till det som alltid ingår	Användningsfallet gör alltid det andra som en del av sig: att låna en bok kräver alltid inloggning
Utökning `«extend»`	Streckad pil från tillägget till basfallet	Tillägget sker ibland, under ett villkor: är boken utlånad kan låntagaren reservera den
Generalisering	Heldragen linje med ihålig triangel mot den allmänna	Den speciella aktören kan allt som den allmänna kan, och mer. En bibliotekarie kan låna böcker som alla andra

Pilarna för «include» och «extend» pekar åt olika håll — det är det som oftast blir fel. Ett sätt att komma ihåg det: pilen pekar alltid från den som vet om den andra. “Låna bok” vet att den behöver inloggning → pilen går från Låna bok till Logga in. “Låna bok” vet inte om reservationer — det är reservationen som vet när den ska kliva in → pilen går från Reservera bok till Låna bok.

Exempel — ett bibliotekssystem

En låntagare kan söka, låna och lämna tillbaka böcker. Att låna kräver inloggning. Lämnas boken tillbaka för sent tillkommer en förseningsavgift, som betalas via ett externt betalsystem — det ligger utanför systemgränsen och är därför en aktör, trots att det inte är en människa. Bibliotekarien kan allt en låntagare kan, och registrerar dessutom nya böcker.

Diagrammet säger vad systemet ska kunna — inte i vilken ordning, och inte hur. Hur “Låna bok” går till steg för steg ritar du som ett aktivitetsdiagram eller ett sekvensdiagram.

Från användningsfall till user stories

Ett användningsfall och en user story beskriver samma sak från två håll. Användningsfallsdiagrammet ger överblicken — alla mål på en sida. User storyn är en av ellipserna, formulerad så att den går att planera och testa:

Användningsfall	User story
Låntagare — Låna bok	Som låntagare vill jag låna en bok, så att jag kan läsa den hemma.
Låntagare — Reservera bok («extend»)	Som låntagare vill jag reservera en utlånad bok, så att jag får den när den kommer tillbaka.
Bibliotekarie — Registrera ny bok	Som bibliotekarie vill jag registrera nya böcker, så att låntagarna kan hitta dem.

Aktören blir “Som …”, användningsfallet blir “vill jag …”, och nyttan — “så att …” — är det du själv lägger till. Mer om user stories och MVP finns i projektmetodik-boken, på sidan User story och MVP under Begrepp.

Och vidare till kod: ofta blir varje användningsfall en metod i ett service-lager — LoanService.LendBook(...), LoanService.ReturnBook(...) — och «include» blir ett anrop som alltid görs först, till exempel att kontrollera att användaren är inloggad.

När ska du välja ett användningsfallsdiagram?

Välj användningsfallsdiagram när…	Välj något annat när…
Projektet är nytt och ni ska enas om vad som ska byggas	Du ska visa hur ett användningsfall går till steg för steg → aktivitetsdiagram
Det finns flera olika användare eller externa system	Du ska visa vilka anrop som görs mellan objekten → sekvensdiagram
Du vill visa var systemets gräns går	Du ska visa vilka klasser som behövs → klassdiagram
Du pratar med en beställare som inte kodar	Du ska visa hur systemets delar och tjänster hänger ihop tekniskt → arkitekturdiagram

Vanliga misstag

Användningsfall som är knappar eller steg. “Klicka på Låna” eller “Validera ISBN” är inga mål. Fråga: skulle aktören vara nöjd om bara detta hände?
Pilar mellan användningsfallen som visar ordning. Ett användningsfallsdiagram har inget flöde. “Först sök, sedan låna” hör hemma i ett aktivitetsdiagram.
«include» och «extend» åt fel håll. Include pekar mot det som alltid ingår. Extend pekar mot basfallet som utökas.
För mycket «include» och «extend». De är kryddor. Ett diagram med bara aktörer, ellipser och linjer är oftast tydligast.
Glömt de icke-mänskliga aktörerna. Ett betalsystem, en schemalagd körning eller ett annat API är också aktörer om de använder — eller används av — systemet.

Övning

Rita ett användningsfallsdiagram för en bokningsapp till ett gym. Aktörer: Medlem, Instruktör och det externa systemet Betaltjänst. Medlemmar ska kunna boka pass, avboka pass och köpa medlemskap. Instruktörer ska kunna skapa pass och se deltagarlistor. Använd minst ett «include» (vad krävs alltid?) och ett «extend» (vad händer bara ibland — till exempel att ställa sig i kö när passet är fullt?). Skriv sedan tre av användningsfallen som user stories.

TL;DR

Begrepp	Vad det är
Användningsfallsdiagram	Vem använder systemet, och vad vill de uppnå?
Aktör	En roll utanför systemet — person eller system
Ellips	Ett mål: verb + objekt
`«include»`	Ingår alltid — pilen pekar mot det som ingår
`«extend»`	Händer ibland — pilen pekar mot basfallet
User story	Ett användningsfall formulerat för backloggen: “Som … vill jag … så att …”