Kleine of grote use cases? 5 tips

Het use case-diagram is qua modelleertechniek een van de eenvoudigste diagrammen uit UML. Toch blijkt het modelleren van use cases in de praktijk niet eenvoudig te zijn. Vooral de granulariteit (letterlijk: korrelgrootte) van de use cases leidt in veel projecten tot discussies. Een use case wordt soms te groot maar meestal te klein gedefinieerd. Een systeem met een gemiddelde omvang heeft tussen de twintig en vijftig use cases

Dit artikel geeft vijf tips voor het opstellen van een use case diagram.

1. Bied overzicht
De functie van een use case diagram is het bieden van overzicht en het weergeven van het bestaansrecht van het systeem. Iedere use case in het diagram representeert namelijk een business value die door het systeem geleverd moet worden. Als een use case diagram veel kleine use cases bevat of onoverzichtelijk wordt, verliest het zijn functie. Bijgevoegde figuur geeft eerst een goed en daarna een verkeerd voorbeeld van de use cases in een use case diagram.

2. Pas geen analyse maar synthese toe
Dat een use case vaak te klein wordt gedefinieerd komt omdat veel mensen use cases als analysetechniek hanteren. In de ict bestaat een lange traditie met het analyseren (letterlijke betekenis: ontleden) van problemen. Hierbij wordt een groot, complex probleem opgedeeld in kleinere problemen zodat het eenvoudiger is om een oplossing voor elk van die kleinere problemen te ontwerpen. Een use case beschrijft geen probleem maar beschrijft de behoefte aan geautomatiseerde ondersteuning. Om die behoefte te begrijpen is het tegenovergestelde van analyse vereist, namelijk synthese. Alle (gedetailleerde) requirements die bijdragen aan het vervullen van een bepaalde business behoefte vormen namelijk samen een logisch geheel van opeenvolgende acties in een use case.

3. Vergelijk een use case met een procestaak
De granulariteit van een use case is gelijk aan die van een procestaak. Het is een eenheid van werk die op een bepaald moment in zijn geheel wordt uitgevoerd.

Voorbeelden van correcte use cases:
Reserveren hotelkamer
Opnemen geld (bij pinautomaat)
Controleren ingediende claim (inbraakverzekering)

Voorbeelden van te klein gedefinieerde use cases:
Invoeren selectiecriteria hotelkamer
Controleren pincode
Raadplegen klantinformatie (in verband met schadeclaim)

4. Herken de signalen voor te kleine use cases
Een use case diagram met te kleine use cases bevat vaak onevenredig veel zogeheten CRUD use cases. Een CRUD use case is een use case die begint met Create, Read, Update of Delete. Bijvoorbeeld de use case 'Invoeren klant- en betaalgegevens'. De meerwaarde die een use case biedt is in de meeste gevallen te omschrijven met behulp van een ander werkwoord. Bijvoorbeeld de use case 'Reserveren hotelkamer' of de use case 'Beoordelen hotelverblijf'. Als het niet lukt om CRUD use cases te vermijden is de kans groot dat de use cases te ver opgesplitst zijn.

Een ander signaal van te kleine use cases is de behoefte om relaties tussen de use cases te leggen en er een volgorde in aan te brengen. Er zijn dan waarschijnlijk meerdere use cases nodig om een eindresultaat te leveren dat waarde heeft voor de actor. Voeg in dat geval de use cases dan samen tot een use case met een duidelijke business value.

5. Benader actoren vanuit het gezichtspunt van het systeem
In een use case diagram worden de grenzen van het systeem zichtbaar gemaakt door de interactie van het systeem met zijn directe omgeving, de actoren, te modelleren. Actoren kunnen menselijke gebruikers en ander ict-systemen zijn. Een actor is een rol die iets of iemand vervult gezien vanuit het gezichtspunt van het systeem. Het figuur geeft eerst een goed en daarna een verkeerd voorbeeld van de actoren in een use case diagram.

Use case diagram actor

Als de actoren vanuit het gezichtspunt van de business worden benaderd ontstaan problemen met het aantal actoren dat interacteert met de use case. Vaak mogen meerdere functies in de organisatie een use case uitvoeren. Voor het systeem maakt het echter niet uit of bijvoorbeeld een medewerker binnendienst, een manager of een voorraadbeheerder de use case 'Plaatsen bestelling' uitvoert. Vanuit het systeem gezien heeft die gebruiker de rol van inkoper. Deze use case interacteert dus met één actor, niet met drie actoren.

Actoren onderkennen vanuit het gezichtspunt van de business is niet alleen methodisch onjuist, maar leidt tot een complex en onoverzichtelijk use case diagram. Zo'n use case diagram vergt bovendien meer onderhoud omdat wijzigingen in de benamingen en de bevoegdheden van (business) functies leiden tot aanpassingen in de specificaties.