Een UML use case diagram geeft inzicht in de use cases en de actoren van het systeem en hun onderlinge relaties. De meest gebruikte relaties tussen use cases zijn de include en de extend relaties. Gebruik ze met mate! De usecasetechniek wordt gebruikt bij de bepaling van de requirements van het gedrag van een bepaald systeem.
Een use case in software engineering en systems engineering is een beschrijving van een gedrag van een systeem, dat reageert op een verzoek dat stamt van buiten het systeem. Met andere woorden, de use case beschrijft 'wie' met het betreffende systeem 'wat' kan doen (Wikipedia – red.). Martin Fowler (2004) formuleert het als volgt: 'The best way to think of a use case diagram is that it's a graphical table of contents for the use case set. It's also similar to the context diagram used in structured methods, as it shows the system boundary and the interactions with the outside world. The use case diagram shows the actors, the use cases, and the relationships between them.'
De include relatie
Included use cases worden veel gebruikt en zijn handig om te voorkomen dat je dezelfde use case stappen dubbel moet beschrijven. Ze zijn dan ook bedoeld om redundantie in de use case specificaties te voorkomen. Identieke stappen in twee of meer use cases worden dan in een afzonderlijke use case geplaatst en aangeroepen vanuit de oorspronkelijke use cases. Het is onverstandig om de include relatie in een vroeg stadium te gebruiken. Doorgaans is pas bij het uitwerken van de use case specificaties met zekerheid vast te stellen dat bepaalde use case stappen redundant voorkomen.
Een included use case blijft onderdeel uitmaken van zijn aanroepende use cases. Het is daarom geen primaire use case die geïnitieerd wordt door een actor (uitzonderingen mogelijk).
De extend relatie Een extending use case voegt extra functionaliteit aan een bestaande use case toe. De bestaande use case wordt in dat geval uitgebreid met optioneel of uitzonderlijk gedrag. In de meeste gevallen is het echter beter om dit soort gedrag als alternatieve flow in de bestaande use case op te nemen. Alleen wanneer het aanpassen van de bestaande use case specificaties onwenselijk is komt een extend relatie in beeld. Dit kan zijn bij het toevoegen van extra functionaliteit in een latere release of bij het aanbieden van optionele of klantspecifieke functionaliteit in een standaard softwarepakket.
De oorspronkelijke use case blijft ongewijzigd en 'weet niet' dat de extending use case is toegevoegd. De extending use case voegt alleen extra functionaliteit aan de bestaande use case toe.
Het essentiele verschil tussen de extend en de include relatie is de kennis die de oorspronkelijke use case heeft over de included/extending use case. Nevenstaande figuur geeft deze verschillen weer.
Ik ben erg benieuwd naar deel 2, om te lezen wat ik hier aan ga hebben in welke omstandigheden. Mocht dat ook nog gericht kunnen zijn op communicatie-infrastructuren, dan kan ik het wellicht begrijpen wat ik er aan heb.
Mooie use-case hoe je mensen wegjaagt uit de IT.
Het gevaar van allerlei modellen is dat je een grote groep mensen uitsluit omdat ze het A) niet kunnen volgen en afhaken B) Het totaal niet interessant vinden en het dus overlaten aan IT.
Ik ben ook gek op modellen, maar in mijn communicatie gebruik ik verhaaltjes en scenario’s. Die snapt iedereen en dan kun je er inhoudelijk over discussiëren. Mijn duimregel; als je het niet makkelijk uit kan leggen beheers je de materie nog niet goed genoeg.
Naar modelletje grijpen is vaak een vorm van onzekerheid en je gebruikt het model om er zekerheid uit te ontlenen, maar kijk er nu eens serieus naar en vraag je af; Voor wie is dit? en wat vindt die ervan?
Hoe moet ik de illustratie lezen? Na een beetje puzzelen kwam ik op:
linkerkolom (include): A includes B (A omvat B, sluit B in, heeft B in zich)
rechterkolom (extend): B extends A (B vergroot A, is een uitbreiding van A)
Het verschil lijkt me dat in het geval A includes B, B ook door bijvoorbeeld C en D ge-include kan worden (en B weet niet door wie hij nou weer is ge-include), terwijl in het geval B extends A, B alleen A kan extenden en niet C of D.
Uiteindelijk lijkt het me te maken te hebben met de volgorde waarin je A en B beschrijft: als je B in A wilt includen moet B eerst bestaan; als je A met B wilt extenden moet A eerst bestaan.
Daarmee lijkt het me een onderwerp voor informatici; niet iets waarmee je gebruikers lastig moet vallen.
@Henri
Ik denk dat het één het ander niet uitsluit.
Verhaaltjes en scenario’s zijn uitermate geschikt om, zoals je zelf al aangeeft, met alle betrokkenen te communiceren.
Wanneer je vervolgens op basis van de verhaaltjes/scenario’s formele modellen maakt, kun je die vervolgens hergebruiken om code te genereren (als ik me niet vergis bekend onder de kreet Model Driven Development).
Met dit soort (vaak complexe) modellen wil je de gebruiker inderdaad niet lastig vallen.
De heer Henri Koppen en eigenlijk ook de rest van de meningen van lezers kloppen als een zwerende vinger. Rest om alleen mijn conclusie hieraan te verbinden.
Het artikel is nogal verwarrend en verder niet interessant.
Helemaal mee eens dat je business stakeholders niet lastig moet vallen met ingewikkelde modellen. Ik heb dit artikeltje geschreven voor analisten die requirements opstellen. In de praktijk kom ik vaak UML use case diagrammen tegen waarin de include en extend relaties te pas en te onpas gebruikt worden. Ik heb alleen het verschil uitgelegd en pleit voor spaarzaam gebruik ervan. Inderdaad alleen interessant voor mensen die deze populaire requirementstechniek al toepassen.