|
© 1999-2003, Flemming Koch Jensen
Alle rettigheder forbeholdt | |
| Use Cases | |
|
| Gennem hele processen | Use Cases er livsnerven i Unified og moderne objektorienteret systemudvikling i almindelighed. Use Cases løber gennem hele processen fra starten af Inception (den første fase) til slutningen af Transition (den sidste fase). De binder hele forløbet sammen, og gør det muligt at følge kravene fra deres spæde start til de er realiseret i det endelige system, der leveres til brugerne. | |
| Men hvad er så en Use Case? Lad os se definitionen: | ||
| ||
| Nogle definitioner kan stå for sig selv, andre kræver en nærmere forklaring - denne hører så afgjort til de sidste. | ||
| Hvad er et "synligt" resultat, og hvad er en aktør? | ||
|
1. Aktører | ||
| En aktør er en entitet der interargerer med systemet. Samlingen af aktører udgør hele systemets omgivelse (context) | ||
|
2. Uses og Extends | ||
|
3. Use case diagrammer | ||
| Figur 1: Use case diagram |
|
|
| Figur 2: Uses mellem to use cases |
|
|
| <<uses>> er blevet ændret til <<include>> i UML 1.3 | ||
| Figur 3: En use case, der extender en anden |
|
|
| Notes: | ||
|
Use case modellen er den mindst formelle model af systemet. Den beskriver i naturligt sprog brugerens krav til systemet - hvad det skal kunne gøre for denne. Den mest formelle model er implementationsmodellen, som er selve koden. Use cases beskriver ikke krav til systemet, de bidrager med klasser, subsystemer, testcases osv. De er kilden af information til projektets øvrige artifacter; hvilket ikke kan være overraskende, da de repræsenterer kravene til systemet. En aktør er populært sagt en bruger af systemet Kravene skal dokumenteres så brugeren kan forstå dem Allerede når use cases er kendt kan man planlægge blackboxtest Use cases beskriver de funktionelle krav til systemet, de kvalitative krav må beskrives på anden måde Med aktører fokuseres der på hvem der har behov for de forskellige funktioner i systemet, og man undgår en uendelig række af funktionelle krav Use case modellen er samtidig måden man kan bruge systemet Use cases binder hele projektet sammen, lige fra starten, hvor man indsamler krav til systemet, til man tester systemet Hver use case er en opgave der skal løses - et krav som skal opfyldes. Man skal lave en specifikation der beskriver hvad use cases går ud på (analyse), dernæst skal det fastlægges hvordan man vil realisere den del af systemet, som skal opfylde kravet (design) og realisere det (implementation). Endelig skal man kontrollere at implementationen opfylder de krav use casen repræsenterer (test). Man ser her at use cases gennemløber alle fem workflows, fra use cases identificeres i kravindsamlingen (det første workflow) til man har verificeret kravopfyldelsen i testen (det sidste workflow) Use cases kan på den måde spores gennem de forskellige modeller. Ændringer spreder sig langs disse spor gennem projektet Hver use case bidrager med en inkrementering. Når man har lavet en use case er man nået et skridt længere Use cases er godt udgangspunkt for brugervejledningen Statistik over hyppighed af use cases kan bruges til at optimere performance (en kvalitet - kvalitativt krav) Aktører behøver ikke være mennekser. Det er ethvert system som bruger vores system Interaktion foregår ved at sende og modtage beskeder Ikke alle use cases har klare aktører. F.eks. "send rykker" som automatisk sendes af systemet når der er gået en vis tid |
||
| USES og EXTENDS | ||
|
Use cases er ikke nødvendigvis uafhængige af hinanden. Der kan være relationer mellem dem. Disse relationer kan antage en af to former: Uses eller Extends Uses bruges når flere use cases delvist har den samme adfærd. Denne fælles adfærd placeres som en use case for sig selv. De andre use cases anvender denne fælles use case i forbindelse med deres egen adførelse Man kan tænke på en uses, som et metode-kald (men tænkt ikke implementation når du laver use cases) Uses relationen virker som en intern use case, hvor en use case optræder som aktør for en anden Extends bruges når en use case er en variation af en anden. En use case repræsenterer selv forskellige varianter af et forløb, men i forbindelse med en extends er der tale om en udvidelse af en use case. Man vælger at dele i to use cases, hvor den ene udevider den anden for at use casen ikke skal blive for kompliceret og rodet Man kan tænke på en extends som en form for nedarvning, men i denne sammenhæng kun ved funktionel dekomposition (En klasse = En funktion) (Men vi tænker ikke implementation når vi laver use cases) <Diagrammer af både uses og extends> |
||
