Minimaal modelleren

Vorige week brak Erwin Pasmans een lans voor het toepassen van modellen in Requirements Engineering naast het gebruik van natuurlijke taal. Verschillende mensen vroegen zich daarna af hoe die modellen er dan uit zien. Speciaal voor hen die nog niet eerder van modellen gebruik hebben gemaakt wil ik hier een tipje van de sluier oplichten door wat te vertellen over use case diagrams. Ik vertel niets over de geschiedenis hiervan, ik vertel niets over de Unified Modelling Language (UML) waarin deze diagrammen zijn opgenomen. Ik wil slechts het absolute minimum van use case diagrammen laten zien zodat ze na het lezen van dit artikel al gebruikt kunnen worden.

Ik zal eerst een aantal elementen die gebruikt worden in use case diagrams beschrijven, zonder de pretentie hierin volledig te zijn, en ze meteen toepassen in een voorbeeld.

Een korte situatieschets: De eigenaar, en tevens kok, van een restaurant overweegt om een app te laten maken om een deel van het werk te ondersteunen. Hij denkt, en hoopt, dat het in de zomer, als een groot deel van de Corona-maatregelen komt te vervallen, het weer erg druk wordt. Hij weet nog niet precies hoe, maar denkt bijvoorbeeld aan het doorgeven van bestellingen, zodat de werkdruk van de enige ober van het restaurant wat kan worden verminderd. De vrouw van de eigenaar, de “CFO”, vraagt zich af of via die app ook de betaling kan worden geregeld.

Laten we eerst het bestaande proces van het restaurant eens gaan modelleren. Hiervoor moeten we wat afspraken maken over de taal: de symbolen die we gaan gebruiken en hoe ze met elkaar gecombineerd kunnen worden (de syntax), wat die combinatie van symbolen dan betekent (de semantiek) en wat je er dan mee kunt doen (de pragmatiek).

Het eerste element in een use case diagram is … tromgeroffel … de use case. De use case wordt getekend als een ellips met daarin een korte tekst. Deze tekst omschrijft wat er in het restaurant gebeurt. Zo kunnen er diverse cases worden ge?dentificeerd, bijvoorbeeld “maaltijd bestellen”, “maaltijd bereiden”, “betaling afhandelen”.

De eerste stap richting use case diagram ziet er nu zo uit.

In het diagram kunnen we ook aangeven wie er betrokken zijn bij de use cases, dus wie bestelt er iets, wie bereidt de maaltijd etc. Deze betrokkenen worden actors genoemd en getekend als een poppetje (tekentalent is hiervoor niet vereist). Ook als de betrokkene geen persoon is maar bijvoorbeeld een systeem of computer mag deze zo worden getekend. De naam van de actor wordt onder de actor geschreven.

Het use case diagram, met actors, ziet er dan als volgt uit.

Het is natuurlijk wel handig om aan te geven welke actor met welke use case te maken heeft. De kok kookt, de ober serveert, etc. Dat kan worden aangegeven met een zogenaamde associatie, getekend als een rechte lijn.

Dit maakt het use case diagram meteen interessanter. We moeten nu gaan nadenken wie er met een bepaalde use case geassocieerd zijn. Bij het bestellen van de maaltijd zijn dat bijvoorbeeld de klant en de ober.

Met associaties ziet het er dan als volgt uit.

Op dit moment beginnen veel mensen zich al af te vragen of er niets ontbreekt. Wat als de betaling met een pinpas wordt gedaan? Hoort de bank, als actor, dan ook in dit diagram te worden opgenomen? Hoe zit het met de ingredi?nten die de kok gebruikt? Wie bestelt die, wie betaalt die? Hoort dat ook in het diagram? In dit voorbeeld laten we deze aspecten nog buiten beschouwing.

We voegen nog een laatste element toe, de systeemgrens. Die wordt getekend als een rechthoekig kader om de use cases heen, met in de linker bovenhoek de naam van het systeem. De use cases vallen binnen het kader, de actors staan er buiten. Het “complete” use case diagram ziet er dan zo uit:

Mijn verhaal eindigt hier, maar ik wil het denkproces nog even laten voortduren. Als je ge?nteresseerd bent geraakt zou je twee dingen kunnen proberen. Ten eerste: maak het use case diagram eens wat verder af, voeg die bank toe voor betaling met de pinpas, voeg de bestelling van de ingredi?nten toe etc. Je hebt dan het bestaande proces in beeld gebracht.

En vraag je daarna eens af wat je met een app zou kunnen doen. Bijvoorbeeld het bestellen van een maaltijd. Teken ook daarvoor eens een use case diagram. Wat zou binnen het nieuw te ontwikkelen systeem, de app, allemaal kunnen worden gedaan? Alleen bestellen? Of ook betalen? En wie of wat zijn dan de actors? En het allerbelangrijkste: als je hiervoor een use case diagram getekend hebt, bespreek het dan eens met iemand (in werkelijkheid liefst met een van de actors). Dan zul je de toegevoegde waarde pas echt ondervinden. 

Zoals gezegd, dit was modelleren op z’n kleinst. Met één type diagram, met een beperkt aantal modelelementen. Als je nu echt de smaak van het modelleren te pakken hebt, kijk dan bijvoorbeeld ook eens naar het activity diagram.

Collega Benjamin Timmermans pakt volgende week het stokje van onze artikelenestafette over.

Dit artikel is een artikel in de reeks over het veelzijdige vak van Requirements Engineering waarbij de komende maanden iedere week een collega van Improve Quality Services de lezer meeneemt in de zaken waar de Requirements Engineer vandaag de dag tegenaan loopt. Elk artikel zal herkenbaar zijn aan de brug, de verbinding tussen twee oevers, die symbool zal staan voor ons vak: de verbinding tussen twee partijen die goed willen samenwerken, door goed te communiceren en die wij daar graag in willen helpen.