Bij de ontwikkeling van een applicatie moeten er een aantal stappen worden ondernomen en technische documenten worden opgesteld. Deze documenten moeten zodanig worden opgesteld dat een andere partij ermee aan de slag zou moeten kunnen en jou geen vragen meer hoeft te stellen van wat je nou precies wilt en hoe. In dit artikel zal ik wat tips geven over hoe je use cases kunt opstellen.
Als je deze term zou willen vertalen, zou het iets zijn als “gebruiks-situaties”. Omdat de term mij eigenlijk niet zoveel zegt, moet ik ook elke keer als ik use cases moet opstellen toch nog even opzoeken hoe het moet en wat het ook alweer is (Ik heb het tot nu toe nog maar twee keer hoeven te doen hoor). Maar omdat ik er zelf zoveel moeite mee heb, wil ik andere de moeite besparen en op een duidelijke manier uitleggen wat je moet doen.
Wanneer je gaat beginnen met het schrijven van use cases, kun je het beste eerst een use case diagram maken. Dit heet een UML diagram (Unified Modelling Language). Een UML diagram bestaat uit actore, use cases en connecties tussen deze. Verder kun je ook de systeem boundary weergeven, omdat het systeem zelf niet expliciet in de UML diagram voorkomt. Je geeft allemaal communicatie processen weer tussen de actoren en de use cases en je moet aangeven welke use cases in het systeem plaatsvinden en welke erbuiten. De actoren zoals gebruiker en dergelijke komen niet in het systeem voor, maar erbuiten. De acties die ze kunnen doen (de use cases) komen wel binnen de system boundary voor.
Om de actoren te identificeren moet je jezelf de volgende vragen stellen:
-
Wie gebruikt het systeem,
-
Wie beheert het systeem (denk aan opstarten, installeren, onderhouden, afsluiten),
-
Welke andere systemen gebruiken dit systeem,
-
Wie krijgt informatie uit het systeem
-
Wie geeft informatie aan het systeem?
Wanneer je deze “actoren” hebt geidentificeerd, moet je de use cases vast stellen door jezelf de volgende vragen te stellen:
-
Welke functies zou de actor willen van het systeem?
-
Welke informatie slaat het systeem op?
-
Welke actoren maken, lezen, vernieuwen of verwijderen deze informatie?
-
Moet het systeem interne veranderingen melden?
-
Zijn er externe dingen waar het systeem vanaf moet weten?
Nu kun je een use case diagram maken en de relaties tussen de actoren en use cases weergeven. De use cases zijn vaak wat in het midden van het veld. Links zijn de actoren die het meest belangrijk zijn en rechts zijn de secundaire actoren.
Deze informatie heb ik uit Laurie Williams’ document uit 2004. Het heeft mij heel erg geholpen om mijn use cases en diagram te maken. Verder heb ik ook voorbeelden van UML diagrammen opgezocht en deze gebruikt als vergelijking tijdens het maken van mijn eigen UML diagram.
