Hoofdstuk 9
case: use-case-diagram Dit hoofdstuk beschrijft de totstandkoming van de use-cases voor EasyShop, het maaltijd systeem van Hans en Jacqueline. Het zijn de functionele systeemeisen die hier worden vastgelegd. Het vaststellen van de use-cases gebeurt volgens de stappen die in hoofdstuk 8 zijn aangegeven. Gezien de grootte van de use-cases staan ze in de tabellen allemaal in één keer geheel uitgeschreven. De uitleg over de gevolgde werkwijze, dat wil zeggen hoe de use-cases opgebouwd worden, refereert telkens aan een specifiek onderdeel van een gerefereerde use-case.
9.1 Identificeer de grens van het systeem en vind de actoren
De grens van het systeem wordt duidelijk door de verantwoordelijkheid van het systeem af te bakenen. Het systeem is verantwoordelijk voor een deel van het huishouden van Hans en Jacqueline: het beheren van de voorraden voor de maaltijden. Het heeft alleen kennis van en kan alleen reageren op zaken die spelen binnen dit huishouden. Alles wat daarbuiten ligt valt buiten de grenzen van het systeem. De actor voor elke actie die met het systeem wordt ondernomen is ofwel Hans ofwel Jacqueline. Deze actor noemen we Huisgenoot. De supermarkt (of de fax van de supermarkt) is een systeem dat buiten het huishouden van Hans en Jacqueline ligt en daarom kunnen we Supermarkt ook als actor identificeren. Zowel Huisgenoot als Supermarkt waren ook kandidaatklassen in § 5.1. Supermarkt is inderdaad opgenomen als klasse in het systeem en in plaats van Huisgenoot is Persoon als klasse opgenomen. Toch zijn dit ook actoren. We hebben immers geheel terecht in de modeldictionary opgenomen als definitie voor Persoon: ‘Representatie binnen het systeem van een reëel persoon.’ Idem de definitie voor de Supermarkt klasse: ‘Representatie binnen het systeem van een reële supermarkt.’ Dergelijke situaties, waarbij in het systeem een representatie van de actor wordt opgenomen, komen vaak voor. Het is daarbij van belang niet de actor en de representatie van de actor te verwisselen. Het kiezen van een andere naam voor een van beide kan daarbij helpen. In ons geval heeft de belangrijkste actor (Huisgenoot) al een andere naam dan zijn representatie in het systeem (Persoon) en zullen we het hierbij laten.
95
praktisch uml
9.2 Vind use-cases voor iedere actor
In overleg met Hans en Jacqueline wordt besloten dat de actor Supermarkt passief is. Supermarkt zal geen acties in het systeem initiëren, maar alleen ontvanger zijn van de per fax verstuurde boodschappenlijst. Het initiëren van het bezorgen van de boodschappen valt namelijk buiten de grenzen van het systeem. Voor het ontvangen van de boodschappen zal de actor Huisgenoot contact hebben met het systeem en niet de Supermarkt. Voor de actor Supermarkt hoeven we dus geen use-cases te definiëren. De actor Huisgenoot is de actor die alle activiteiten in het systeem initieert. Om dit te kunnen doen moet de Huisgenoot kunnen inloggen (1), waarmee de eerste use-case gevonden is. De Huisgenoot wil bovendien een weekschema van zijn/haar aanwezigheid invullen (2), een recept kiezen (3), aangeven wanneer er gasten verwacht worden (4), een boodschappenlijst laten genereren en versturen (5) en het kookboek inzien (6). Deze vijf use-cases volgen direct uit de probleembeschrijving. Daarnaast is het zeer waarschijnlijk dat de Huisgenoot een overzicht van de aanwezigheid van alle personen zal willen zien (7). Maar om goed te kunnen functioneren heeft het systeem ook informatie nodig over de boodschappen die geleverd zijn: is alles in de juiste hoeveelheid binnengekomen? Het systeem kan onmogelijk voldoen aan zijn verantwoordelijkheden zonder deze informatie. De Huisgenoot zal deze informatie aan het systeem moeten verschaffen. Ook dient de Huisgenoot inzage te hebben in de huidige voorraad. Dit leidt tot de laatste twee usecases: inkopen binnengekomen (8) en voorraad inzien (9). De lijst met use-cases die het resultaat van deze stap vormen is: 1. Inloggen 2. Agenda invullen 3. Recept kiezen 4. Gast(en) aangeven 5. Boodschappenlijst versturen 6. Kookboek inzien 7. Overzicht aanwezigheid opvragen 8. Binnengekomen inkopen opvoeren 9. Voorraad inzien In de volgende secties wordt het stappenplan doorlopen. De meeste stappen worden voor enkele use-cases besproken, niet voor allemaal. De use-cases staan in tabel 9‑1 tot 9‑8 en worden allemaal in hun geheel beschreven.
9.3
Bepaal de aannamen
Onder welke omstandigheden mogen de nu bekende use-cases worden uitgevoerd? De meeste aannamen omtrent de omstandigheden zijn relatief simpel. Inloggen moet kunnen zodra het systeem gestart is, maar er mag niet meer dan één Huisgenoot tegelijkertijd 96
ho ofdstuk 9 – case: use-case-diagram
ingelogd zijn. Het wordt geen multiusersysteem. Bij de overige use-cases is het natuurlijk een voorwaarde dat er een Huisgenoot ingelogd is. In overleg met de opdrachtgevers wordt bepaald dat weekschema invullen zal worden gedaan via een venster waarop een weekschema getoond wordt, zodat de gebruiker een goed overzicht heeft over de betreffende week. Het vaststellen van de overige aannamen is een oefening voor de lezer.
9.4
Bepaal de interactie
In deze stap wordt bepaald hoe de gebruiker met het systeem om zal kunnen (en moeten) gaan. Voor elk van de use-cases wordt zo concreet mogelijk vastgesteld hoe de inter actie tussen gebruiker en systeem zal verlopen. Zie bijvoorbeeld de use-case ‘Inloggen’ in tabel 9‑1. Tabel 9-1 Use-case Inloggen Naam
Inloggen.
Aannamen
Systeem is zojuist gestart. Geen huisgenoten ingelogd.
Beschrijving
(1) Huisgenoot maakt zijn/haar naam kenbaar. (2) Het systeem controleert of Huisgenoot bekend is bij het systeem. Zo niet, dan treedt uitzondering [Huisgenoot niet bekend.] op. Het systeem zoekt het weekschema van de huidige week en laat daarin de aanwezigheidsgevens van Huisgenoot zien.
Uitzonderingen
[Huisgenoot niet bekend.] Een melding wordt gegeven dat het sys teem niet start omdat de naam niet die van een huisgenoot is.
Resultaat
De Huisgenoot is ingelogd en zijn weekschema is zichtbaar op het scherm.
De use-case ‘Agenda invullen’, in tabel 9‑2, begint met de gebruiker die aangeeft wanneer hij/zij aanwezig zal zijn. Het systeem kan volstaan met het opslaan van deze informatie, maar het is zinvoller om het systeem meteen te laten nagaan of de kok en het recept bij de aangegeven diners al bekend zijn. Als dat niet zo is dan zal het systeem reageren op de gebruiker met de vraag of hij/zij kookt. Als de gebruiker positief antwoordt dan reageert het systeem door de use-case ‘Recept kiezen’ uit te voeren. (Zie tabel 9‑3.) Bij het bespreken van de use-case ‘Boodschappenlijst versturen’ (zie tabel 9‑4) met Hans en Jacqueline wordt duidelijk dat er een extra systeemeis bestaat, namelijk het handmatig toevoegen van items aan de gegenereerde boodschappenlijst zodat ook zaken als schoonmaakmiddelen via de fax bij de supermarkt besteld kunnen worden. Deze eis wordt direct in de use-case verwerkt.
97
praktisch uml
Tabel 9-2 Use-case Agenda invullen Naam
Agenda invullen.
Aannamen
Huisgenoot is ingelogd en zijn/haar weekschema wordt getoond.
Beschrijving
(1) Huisgenoot geeft in het schema per maaltijd aan of hij/zij aanwezig zal zijn. (2) Als Huisgenoot dit aangeeft voor een diner, dan controleert het systeem of er al een kok bekend is. Is dat niet het geval dan wordt Huisgenoot gevraagd of hij/zij kok wil zijn. (3) Is het antwoord ja dan wordt de use-case Recept kiezen uitgevoerd. Ten slotte geeft Huisgenoot aan dat hij/zij klaar is met invullen.
Uitzonderingen
Geen.
Resultaat
Het systeem weet dat de betreffende week door Huisgenoot is ingevuld en kent de aanwezigheid van Huisgenoot bij alle maaltijden uit die week.
Tabel 9-3 Use-case Recept kiezen Naam
Recept kiezen.
Aannamen
Huisgenoot is ingelogd en zijn/haar weekschema wordt getoond. Huisgenoot heeft aangegeven kok te willen zijn voor een bepaalde WarmeMaaltijd.
Beschrijving
(1) Het systeem toont het kookboek. (2) Huisgenoot selecteert een Recept, ofwel direct uit een lijst, ofwel d.m.v. de zoekmechanismen in kookboek. (3) Het systeem vraagt om een bevestiging. (4a) Als de gebruiker die geeft dan (5) verdwijnt het kookboekscherm en is het geselecteerde Recept gekoppeld aan de betreffende WarmeMaaltijd. (4b) Geeft Huisgenoot geen bevestiging dan kan deze opnieuw een recept selecteren. (5) Het kookboekscherm verdwijnt pas en Huisgenoot kan pas verder met andere use-cases als een bevestiging is gegeven.
Uitzonderingen
Geen.
Resultaat
Er is een Recept en een kok bekend voor de betreffende WarmeMaaltijd.
De interactiebeschrijvingen van de overige use-cases zijn niet veel ingewikkelder dan die van ‘Agenda invullen’. U vindt de complete use-cases in tabellen 9‑1 tot en met 9‑8.
98
ho ofdstuk 9 – case: use-case-diagram
Tabel 9-4 Use-case Boodschappenlijst versturen Naam
Boodschappenlijst versturen.
Aannamen
Huisgenoot is ingelogd en zijn/haar weekschema wordt getoond.
Beschrijving
(1) Huisgenoot geeft aan een boodschappenlijst te willen versturen. (2) Het systeem controleert of alle huisgenoten het schema voor de getoonde week hebben ingevuld. Zo niet dan treedt er de uitzondering [Schema niet ingevuld.] op. Het systeem genereert een boodschappenlijst voor de getoonde week en toont deze. [Extension point: inzage voorraad] (3) Huisgenoot kan aan deze lijst items toevoegen en hoeveelheden wijzigen. Huisgenoot kan nu kiezen: ofwel de lijst wordt verwijderd (dit is de uitzondering [Lijst niet bewaren.] ), ofwel de lijst wordt bewaard, ofwel de lijst wordt bewaard en verstuurd. (4) Zodra Huisgenoot aangeeft dat de lijst verstuurd moet worden toont het systeem een lijst met supermarkten (5) waaruit Huisgenoot een supermarkt kiest. (6) Het systeem verstuurt de boodschappenlijst per fax naar de supermarkt. Het sys teem onthoudt of de lijst is verstuurd of niet.
Uitzonderingen
[Schema niet ingevuld.] Het systeem meldt dat een van de schema’s niet is ingevuld. De use-case wordt afgebroken. [Lijst niet bewaren.] Het systeem meldt dat de boodschappenlijst verwijderd wordt. De use-case wordt afgebroken.
Resultaat
Behalve als de use-case door het optreden van een uitzondering afgebroken is, is er in het systeem een boodschappenlijst voor de getoonde week. Deze kan al dan niet verstuurd zijn.
Tabel 9-5 Use-case Gasten aangeven Naam
Gast(en) aangeven.
Aannamen
Huisgenoot is ingelogd en zijn/haar weekschema wordt getoond.
Beschrijving
(1) Huisgenoot selecteert een maaltijd en geeft aan gasten te willen aangeven in zijn/haar schema. (2) Systeem toont een lijstje met bekende gasten. (3) Huisgenoot kan hieruit selecteren of een nieuwe gast toevoegen. (4) De geselecteerde of nieuwe gast wordt als aanwezige bij de geselecteerde maaltijd opgenomen. Als er geen gast geselecteerd wordt dan wordt er geen gast bij de maaltijd opgenomen. Gegevens over een nieuwe gast worden bewaard.
Uitzonderingen
Geen.
Resultaat
De aanwezigheid van gasten voor de geselecteerde maaltijd is aangegeven.
99
praktisch uml
Tabel 9-6 Use-case Binnengekomen boodschappen opvoeren Naam
Binnengekomen boodschappen opvoeren.
Aannamen
Huisgenoot is ingelogd en zijn/haar weekschema wordt getoond.
Beschrijving
(1) Huisgenoot geeft aan binnengekomen boodschappen te willen opvoeren. (2) Systeem toont uitstaande bestelling. De uitzondering [Geen uitstaande bestelling.] treedt op wanneer er geen uitstaande bestelling is. (3) Huisgenoot kan elk item in de bestellijst wijzigen zodat deze overeenkomt met de binnengekomen hoeveelheid van dat item. Huisgenoot kan ook items toevoegen. Nadat Huisgenoot heeft aangegeven dat de lijst oké is (4) werkt het systeem de voorraad bij en toont het systeem een overzicht van de huidige voorraad.
Uitzonderingen
[Geen uitstaande bestelling.] Het systeem geeft een melding en vraagt Huisgenoot of hij/zij de voorraad wil bijwerken. Als Huisgenoot hierop bevestigend antwoordt dan toont het systeem een overzicht van de huidige voorraad waarin Huisgenoot wijzigingen kan aanbrengen.
Resultaat
De voorraadgegevens zijn bijgewerkt en voorraad wordt getoond op het scherm. Tabel 9-7 Use-case Voorraad inzien
Naam
Voorraad inzien.
Aannamen
Huisgenoot is ingelogd en zijn/haar weekschema wordt getoond.
Beschrijving
(1) Huisgenoot geeft aan de voorraadgegevens te willen inzien. (2) Het systeem toont een overzicht van de voorraad. (3) Huisgenoot kan hierin niet wijzigen. Daarvoor moet use-case ‘Binnengekomen boodschappen opvoeren’ gebruikt worden.
Uitzonderingen
Geen.
Resultaat
Geen veranderingen in het systeem.
9.5
Bekijk mogelijke uitzonderingen
Uitzonderingsgevallen zijn vaak gevallen waarin er logisch gezien iets fout zou kunnen gaan. Een voorbeeld daarvan is wanneer een boodschappenlijst voor een bepaalde week verstuurd zou worden terwijl nog niet bekend is wie wanneer aanwezig is. De gegenereerde boodschappenlijst zou wellicht leeg zijn en zeker niet voldoen aan de verwachtingen van 100
ho ofdstuk 9 – case: use-case-diagram
Tabel 9-8 Use-case Kookboek inzien Naam
Kookboek inzien.
Aannamen
Huisgenoot is ingelogd en zijn/haar weekschema wordt getoond.
Beschrijving
(1) Huisgenoot geeft aan het kookboek te willen inzien. (2) Systeem laat het kookboek zien: een lijst met alle recepten. (3a) Huisgenoot kan één van de recepten selecteren (6) waarna de bereidingswijze, ingrediënten en de andere eigenschappen van het recept door het systeem wordt getoond. (3b) Huisgenoot kan ook een selectie maken uit de lijst met recepten op basis van een aantal zoekcriteria. Zoeken op ingrediënt, moeilijkheidsgraad, bereidingstijd, bereidingswijze en naam is mogelijk. (4b) Het systeem laat dan i.p.v. de complete lijst met recepten de lijst met recepten zien die aan de zoekcriteria voldoen. (5b) Huisgenoot kan ook hieruit een recept selecteren dat dan (6) vervolgens in detail getoond wordt.
Uitzonderingen
Geen.
Resultaat
Geen wijzigingen.
de gebruikers. Deze uitzondering wordt opgenomen bij de use-case ‘Boodschappenlijst versturen’. Bij de use-case ‘Inloggen’ kan het zo zijn dat de naam die de gebruiker ingeeft niet bekend is bij het systeem. In dat geval zal het systeem een melding geven dat het niet kan opstarten. Verder kan het in de use-case ‘Binnengekomen boodschappen opvoeren’ voorkomen dat een actor aangeeft dat er boodschappen binnengekomen zijn terwijl er geen bestelling uitstaat. Dit staan we toe omdat dit de mogelijkheid geeft de voorraad bij te werken in geval van fouten. Er zal wel een melding van gegeven worden. Bij de overige use-cases komen geen logische uitzonderingsgevallen voor.
9.6 Splits veelvoorkomende subcases uit
Als laatste stap in deze fase worden identieke delen van use-cases omgevormd tot een subcase. Vanwege de verwoording in de probleembeschrijving is direct de use-case ‘Kies recept’ als aparte use-case opgenomen. Achteraf gezien heeft dat enorm veel werk bespaard, want deze use-case kan op verschillende punten in de use-cases ‘Agenda invullen’ en ‘Gast(en) aangeven’ worden gebruikt. Maar willen we deze use-case alleen als subcase gebruiken of ook als gewone use-case, met andere woorden kan de actor Huisgenoot altijd een recept kiezen of alleen als onderdeel van de bovengenoemde usecases? Wederom is overleg met de opdrachtgevers noodzakelijk. Zij beslissen dat het kiezen van een recept altijd onderdeel is van een andere use-case. 101
praktisch uml
De tabellen in dit hoofdstuk vormen het resultaat van deze fase. Omdat de actoren voor iedere use-case hetzelfde zijn is het kopje actoren uit de use-case-template weggelaten. Ook de samenvatting is (heel gemakzuchtig) weggelaten omdat de use-cases vrij simpel en klein zijn.
9.7
Maak use-case-diagram
In figuur 9‑1 staat het use-case-diagram voor het EasyShop-systeem. Het diagram voegt niet veel informatie toe, maar geeft een goed overzicht van de mogelijkheden die het systeem aan de gebruiker geeft. Voor details van de use-cases dient de tekst uit de usecase-beschrijvingen.
EasyShop conditie: {selectie actor} extension point: inzage voorraad
Inloggen
Agenda invullen
« include »
Gast(en) aangeven
Huisgenoot
Recept kiezen
« include »
« extend » Kookboek inzien Boodschappenlijst versturen Voorraad inzien Binnengekomen boodschappen opvoeren
Figuur 9-1 Use-case-diagram voor EasyShop
102
