Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Kleine of grote use cases? 5 tips

 

Expert

Nicole de Swart
Requirements expert, Reaco Academy. Expert van voor het topic .

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4439629). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Een sterk artikel. Vooral punt 2, synthese in plaats van analyse is voor veel ICT-ers een uitdaging. Het vraagt een omkering van de gewoonte een probleem op te delen in kleinere onderdelen naar het perspectief van het grotere geheel. Maar ook het bekijken van het ICT vraagstuk vanuit het perspectief van de gebruiker.

Daarnaast ben ik heel benieuwd welke tips er zijn voor het opstellen van goede user stories. In veel projecten waar een agile manier van werken wordt gehanteerd, worden user stories als requirement / ontwerpdocumentatie gebruikt. Ook op dat vlak is veel winst te behalen met de juiste granulariteit en de juiste mate van detaillering.

Ik wil an de intentie en de inhoud van het artikel niets afdoen. Vanwege het feit dat ik in de materie niet thuis ben. Waar ik wel in thuis ben, al vele jaren zelfs, is de IT. Wanneer ik de koppeling gemaakt zie worden tussen uw materie en IT, dan schud ik lichtjes mijn hoofd en wil die koppeling dan ook direct ongedaan maken.

Als ik kijk naar de illustraties alleen al, dan weet ik dat uw methodiek, meteen op problemen zal gaan rekenen als hier de koppeling met IT word gemaakt. Ook de opmerking over het niet analyseren maar synthese toepassen staat haaks op de materie en de wetmatigheden van de IT. En dat is nu juist het gevaar waar ik al jaren voor waarschuw.

Telkens weer leuke dingen bedenken en dan de koppeling maken naar IT zonder dat men begrijpt hoe IT zich beweegt. Dat is telkens weer een recept voor 'problemen' gebleken in de praktijk die uiteindelijk het tegengestelde bereikte dan waar IT voor staat uiteindelijk.

Ik ben het eens met NumoQuest. Mijn vraag is: komt uw artikel voort uit een knellend probleem wat wordt ervaren in organisaties, met betrekking tot de it, of geeft u een oplossing voor een niet bestaand probleem?

Uit het artikel maak ik op dat de schrijver slechts beoogt 5 tips te geven voor een juist detailniveau van use cases. Ik kan het alleen maar eens zijn met de gegeven tips. Nieuws? Nee, maar een opfrisser.
De reacties echter roepen meer op. Kracht van use cases zit in de duidelijkheid naar de gebruiker. Dat de "echte IT-er Numoquest" al jaren waarschuwt voor kommer en kwel en dat de gebruikers weinig snappen van IT mag zich achter de oren krabben waarom hij al jaren waarschuwt en men maar niet luisteren wil. De steller noemt koppelen met IT het probleem. Een informatiesysteem is niet allen IT. De echte ict-er weet dat dit een systeem is waarmee informatie over objecten of personen beheerd - verzameld, bewerkt, geanalyseerd, geïntegreerd en gepresenteerd - kan worden. Tot een informatiesysteem in ruime zin worden naast de data en de technieken en faciliteiten om data te ordenen en te interpreteren vaak ook de ermee verbonden organisatie, personen en procedures gerekend. Je kunt de koppeling dus maar beter leggen dan ongedaan maken.

In reactie op NumoQuest en Jan: Als expert op het gebied van requirements engineering constateer ik dat er bij software-ontwikkeltrajecten vaak discussie of onduidelijkheid bestaat over de omvang van de use cases. Ik geef daarom 5 tips voor het opstellen van use case diagrammen. Ik heb de use case techniek (helaas) niet zelf bedacht. Het is één van de belangrijkste en meest gebruikte technieken voor het definiëren van de requirements. Goed geschreven use cases geven zowel voor de gebruikers als de ontwikkelaars en testers weer wat het te ontwikkelen systeem moet kunnen.
Bovendien is het use case diagram onderdeel van de internationale standaard Unified Modeling Language (UML).

@Pepijn: User stories is inderdaad een andere techniek voor het opstellen van requirements. Daarover heb ik een praktisch toepasbaar artikel gepubliceerd in XR Magazine (zie http://bit.ly/ybuApS)

Verdraaid, wat lijkt die discussie over use cases toch veel op de discussie over Data Flow Diagrams c.q. State Transition Diagrams...
"L'histoire se repete" maar dan met verse debaters en dito schrijvers.

De use case techniek is in zekere zin nogal kinderlijk en omslachtig, zeker wanneer je bedenkt dat er technieken zijn waarin je aanmerkelijk compacter en exacter kunt beschrijven wat je wil.
Maar ja, dan krijg je geen nijntjes plaatjes he.

Dit is nou zo'n punt waar ik het met de meeste vakgenoten niet eens ben en mij aansluit bij het boek "Pragmatisch modelleren met UML".

Houd voor een use case 1 scherm/widget/webservice aan, dat is voor iedereen het meest makkelijk herkenbaar en hanteerbaar. Om het overzicht te bewaren over deze vele use case kan je ze groeperen, bijvoorbeeld in hogere nivo use cases (zoals gesuggereerd in het boek) of functionele gebieden, etc.

Op die manier krijg je dus 1 super use case "Reserveren hotelkamer" met daaronder o.a. de use case "Geef gastgegevens op". Als je dit niet doet krijg je 1 gigantisch lange use case met meer dan honderd stappen die niet meer hanteerbaar is omdat je stukken functionaliteit niet kunt terugvinden.

Dit sluit tevens het beste aan bij wat de makers van UML bedacht hadden: namelijk dat een use case 1 doel moet hebben (en niet een compleet verschillend doel per alternative flow). "Manage klant" is dus geen sterke use case, omdat het aanmaken van een klant echt een ander doel is dan het verwijderen ervan.

Bij dit soort discussies is het altijd goed om te kijken naar de achterliggende oorzaken.
De neiging om te ver op te splitsen wordt veroorzaakt doordat men use case scenario's veel te gedetailleerd uitwerkt. De hele GUI wordt erin uitgetekend, inclusief validatiestappen en foutmeldingsstappen, zoek- en filteropties, voorwaardelijk beschikbare schermobjecten, etc, etc.
Daardoor worden de scenario's veel te groot en te complex. Wanneer je dan meerdere use cases hebt die enigszins op elkaar lijken (varianten op een thema), dan krijg je vanzelf veel redundantie in de uitwerking daarvan. Dat leidt dan weer tot het uitsplitsen van 'gelijke delen' in sub use cases en daarmee is de cirkel rond.
Het is veel eenvoudiger om dit soort GUI zaken in een User Interface Specification uit te werken, waarop dan meerdere Use Cases aansluiten.

Maurits, ik ben het helemaal met je eens. De use case techniek is niet bedoeld en niet geschikt voor het specificeren van de user interface. Ik had ook tips voor het opstellen van use case specificaties (i.p.v. use case diagram) kunnen geven. Daarin had niet beschrijven van de GUI zeker in de top 5 gestaan.

Bert, je noemt de use case 'Reserveren hotelkamer' een super (grote) use case. Als je de GUI achterwege laat kun je de basis flow in slechts 8 stappen beschrijven. In Handboek Requirements heb ik de volledige use case specificatie als voorbeeld opgenomen. Dat voorbeeld is ook te downloaden op http://www.reaco.nl/handboekRequirements.asp

Als je use cases wilt opdelen in kleinere eenheden (van belang in agile/scrum) is Use cases 2.0 een optie. Ivar Jacobson, bedenker van de use cases, heeft o.a. use cases-slices aan zijn techniek toegevoegd. Op het Requirements Kenniscentrum is hier meer info over te vinden. Kijk op http://www.requirementskenniscentrum.nl/.

Ik houd me sinds 1980 bezig met het omzetten van gebruikersvragen in IT-oplossingen en heb nog steeds geen generiek antwoord op de granulariteitsvraag. Bij elk project vraag ik me af hoe ik de gevraagde functionaliteit het beste op kan delen. De use case methodiek spreekt me erg aan, omdat het je als IT-er focust op de gebruiker. Iets wat binnen de IT nog wel eens vergeten wordt. Met goed gebruik van use cases krijgt de gebruiker een systeem waar hij/zij ook echt iets mee kan doen.

Ik zie echter ook een keerzijde: sommige use cases zijn vanuit gebruikersperspectief heel simpel, maar kunnen omvangrijke programmatuur vereisen. Ook interfaces tussen systemen hebben vaak een simpele use case (zet de gegevens van systeem A over naar systeem B), maar vaak ook complexe programmatuur. Als hiervoor dan toch de use case methodiek wordt gebruikt, krijg je de veel deeluses cases om het nog een beetje overzichtelijk te houden. Maar dat is misschien beter dan terugvallen op de functioneel ontwerp methodiek om te voorkomen dat je in je project meerdere ontwikkelmethoden naast elkaar gebruikt (wat ook niet werkt).

Hoewel er waarschijnlijk geen eenduidige manier is om de granulariteit te bepalen moet ik zeggen dat ik het ezelsbruggetje OTOPOP wel een handige leidraad vind.

OTOPOP: One time, one place, one person.

Als een enkele persoon de actie op een enkele plek op een enkel moment in de tijd kan uitvoeren, dan past het in OTOPOP. Hierbij dien je de granulariteit zo "grof" mogelijk te kiezen zolang het nog steeds in OTOPOP past.

Bijvoorbeeld in het geval van een ATM: "Enter pin" is op zich OTOPOP, maar een de hele actie "Withdraw cash from ATM" is nog steeds OTOPOP. Daarom kiezen we de laatste als een use case.

OTOPOP lijkt me geen wet waar niet vanaf geweken kan worden, maar het helpt wel om in de meeste gevallen de juiste granulariteit te kiezen.

Kwam deze discussie tegen na de constatering van het e-boek Use Case 2.0

Een volgende en door Ivar Jacobson aan de huidige tijd aangepaste denk- en werkwijze omtrent use cases.

Hij oppert opdeling UC in slices. Lijkt niet erg op grove granulariteit maar het omgekeerde. Krijgt de discussie dan een andere insteek?

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×