case: sequence- en communicatiediagrammen

Hoofdstuk 11 case: sequence- en communicatiediagrammen In dit hoofdstuk wordt het maken van de eerste versie van de sequence- en communicatiediagrammen voor het boodschappensysteem van Hans en Jacqueline uitgewerkt. Voor elke use-case die geïdentificeerd is in hoofdstuk 9 maken we één diagram. Deze case dient als voorbeeld, daarom zullen we in dit hoofdstuk zowel sequence- als communicatiediagrammen uitwerken. Omdat beide diagrammen dezelfde informatie geven, wordt over het algemeen tijdens een systeemontwikkelingstraject gekozen voor of de ene of de andere vorm. De structuur van dit hoofdstuk volgt niet het stappenplan uit hoofdstuk 10 omdat het stappenplan gegeven is voor een enkel diagram en we voor de case meerdere diagrammen moeten maken. Per use-case wordt het stappenplan toegepast. Daarvoor worden enkele conventies vastgelegd. 11.1 Naamgevingconventies De meeste boodschappen in sequence- en communicatiediagrammen worden bij de implementatie vertaald in operaties bij de klasse van het object dat de boodschap ontvangt. Veel case-tools hebben dan ook de mogelijkheid om een check uit te voeren die controleert of elke binnenkomende boodschap als operatie in de klasse bekend is. De keuze van namen voor de uitgewisselde boodschappen is daarom in deze stap een punt van aandacht. De naam wordt/is immers ook de naam van de operatie. De namen moeten zo duidelijk mogelijk weergeven wat van de ontvanger van de boodschap wordt verwacht. Ook is het nuttig om een bepaalde systematiek in de naamgeving te gebruiken. Een voorbeeld van naamgevingsystematiek in deze case is het gebruik van het woord is als begin van de naam voor elke boodschap waarop de ontvanger alleen ja of nee kan antwoorden (bijvoorbeeld isvoorraadvoldoende, isreceptbekend). Dergelijke boodschappen zullen worden geïmplementeerd als Booleanoperaties. Verder wordt in deze case het woord zet gebruikt als begin van de naam voor elke boodschap waarbij van de ontvanger gevraagd wordt een bepaalde waarde te onthouden (bijvoorbeeld zetkok). Het woord geef wordt gebruikt als begin van de naam voor elke boodschap waarbij de ontvanger om informatie gevraagd wordt (bijvoorbeeld geefweeknr). Een andere conventie die gebruikt wordt, is dat bij operatienamen die bestaan uit meer dan één woord, het eerste woord met een kleine letter begint en de volgende allemaal 121

praktisch uml met een hoofdletter. De woorden worden wel aan elkaar geschreven om problemen met spaties in identifiers te voorkomen (bijvoorbeeld isvoorraadvoldoende). Deze naamgevingconventies maken het ons mogelijk om het aantal boodschappen dat in de diagrammen opgenomen moet worden, te beperken. De returnwaarden bij deze boodschappen zijn dusdanig simpel te bepalen dat de returnwaarden niet expliciet in de diagrammen hoeven voor te komen. Alleen als de waarde die geretourneerd wordt van belang is voor het verloop van de interactie, wordt deze expliciet weergegeven. 11.2 Userinterface Een vraag waar we bij het maken van sequence- en communicatiediagrammen altijd mee te maken krijgen is: hoever modelleren we de userinterface? Dit is een logische vraag omdat we ons bij elk diagram af moeten vragen welk object de serviceaanvragen van de gebruiker aanneemt. Omdat we met het maken van een eerste versie van dit soort diagrammen bezig zijn met domeinmodellering en nog niet in willen gaan op hoe de userinterface er precies uit gaat zien vatten we voor dit moment de hele userinterface samen in één object (klasse): de Userinterface. In een volgende fase zullen we dit (dummy) object gaan uitsplitsen en verder specificeren. Bij elk diagram wordt de tweede stap uit het stappenplan het bepalen van het object dat aangesproken wordt door de Userinterface. 11.3 Het uitwerken van de use-cases 11.3.1 Inloggen Bij het maken van sequence- en communicatiediagrammen worden beslissingen genomen die de activiteiten tussen de objecten in het systeem steeds verder vastleggen. Wanneer iemand inlogt, wordt de agenda getoond. Hiertoe dient de huidige week alle dagen te vragen naar hun maaltijden, welke vervolgens alle aanwezigen, het recept en de kok kent. Dit is het interactiepad dat we in een diagram gaan uitwerken. Het eerste dat het systeem doet in de use-case Inloggen is het controleren of het systeem een huisgenoot met een bepaalde naam kent. In figuur 11 1, het sequencediagram bij deze use-case, stuurt de Userinterface aan de klasse Persoon de boodschap vindpersoon(naam). Dit is een representatie van de wijze waarop de Userinterface het Persoon-object zoekt dat met de werkelijke gebruiker correspondeert. Ergens in het systeem zal een lijst met persoonobjecten bijgehouden moeten worden. Deze lijst kan in de userinterface opgenomen worden, maar kan ook als klasseattribuut bij de klasse Persoon opgenomen worden. Voordat we nadere beslissingen over de userinterface gemaakt hebben kunnen we deze 122

ho ofdstuk 11 case: sequence- en c ommunicatiediagrammen keus nog niet maken. Als een soort pro memorie wordt in dit diagram de boodschap gestuurd naar de klasse Persoon. Als resultaat van de boodschap zal een Persoon-object teruggestuurd worden. sd inloggen :Userinterface Persoon p:persoon Week w:week :Dag m:maaltijd naam p := vind Persoon(naam) geeftype() w := zoekhuidigeweek() geefaanwezigheid loop *[alle dagen] mt := geef Maaltijden loop *[m in mt] geefaanwezigen agenda aanwezigen Figuur 11-1 Sequencediagram Inloggen De Userinterface beschikt nu over het juiste Persoon-object. Vervolgens zal deze checken of dit Persoon-object ook van het type user is (boodschap geeftype()). Als het type juist is, dan wordt het Week-object gezocht dat de huidige week representeert. Dit Week-object zal ook bijbehorende Dag- en Maaltijd-objecten zoeken en bewaarde gegevens over de agenda inlezen. Vervolgens wordt de agenda getoond door de Userinterface. 11.3.2 Agenda invullen Het kenmerkende interactiepad bij de use-case Agenda invullen is die waarin de actor (Huisgenoot) aangeeft bij een aantal maaltijden aanwezig te zijn en bij één daarvan kok is. Alle andere mogelijke manieren waarop het invullen van de agenda uitgevoerd kan 123

praktisch uml worden zijn variaties op dit interactiepad. Alleen voor dit interactiepad zullen we een diagram maken. (Zie figuur 11 2.) sd agenda invullen 1:aanwezig() :Userinterface 1.1:aanwezig(persoon) 2:kok() 2.8:zetRecept(r) 2.1:ja 2.3:toon(k) 3.1: ingevuld(persoon) 2.4:zoek(criterium) 2.6:toon(k) 2.7:selecteer(r) 2.2: k:=toonkookboek() 3: klaar() 2.5: k:=zoek(criterium) :Kookboek :Maaltijd :Week Figuur 11-2 Communicatiediagram Agenda invullen Wanneer de Userinterface de boodschap krijgt dat de actor bij een maaltijd aanwezig zal zijn, zal deze dit direct aan het bijbehorende Maaltijd-object doorgeven. Om dit Maaltijd-object te kennen moet de Userinterface een koppeling hebben ofwel direct met de getoonde Maaltijden ofwel via Week met de getoonde Maaltijden. Hoe dit precies gaat beslissen we pas als de userinterface verder gedetailleerd wordt. Om de aanwezigheid van een Persoon te registreren moet het Maaltijd-object een referentie hebben naar het Persoon-object dat de actor representeert. Deze wordt dan ook als parameter bij deze boodschap meegegeven. Vervolgens wordt door de Userinterface gevraagd of de actor ook kok wil zijn. Nadat eventueel de use-case Recept kiezen is uitgevoerd (als de Maaltijd een recept nodig heeft) en aanwezigheid bij andere Maaltijden is aangegeven, geeft de huisgenoot aan dat zij klaar is en wordt aan het Week-object doorgegeven dat het huidige Persoon-object de agenda voor die week heeft ingevuld. 11.3.3 Recept kiezen Het interactiepad dat de essentie van de use-case Recept kiezen weergeeft is het pad waarin de actor op een bepaalde manier zoekt naar een recept en dit vervolgens selecteert als recept voor de warme Maaltijd. 124

ho ofdstuk 11 case: sequence- en c ommunicatiediagrammen De Userinterface zal bij de start van de interactie de volledige inhoudsopgave van het Kookboek vragen en deze tonen aan de actor. Wanneer de actor hierin wil zoeken geeft hij/zij de zoekcriteria aan. De Userinterface zal dan weer een boodschap sturen naar Kookboek. Kookboek maakt vervolgens een lijst aan van recepten die aan het door de actor gegeven criterium voldoen. Userinterface toont deze lijst. De actor selecteert een Recept. Userinterface geeft een referentie naar dit Recept door aan de Maaltijd waarvoor deze interactie gestart was. Een weergave hiervan vindt u in het communicatiediagram in figuur 11 2. 11.3.4 Gast(en) aangeven De manier waarop de use-case Gast(en) aangeven zo compleet mogelijk wordt uitgewerkt in een sequence- of communicatiediagram is door als interactiepad te kiezen voor het toevoegen van een nieuwe gast en deze als aanwezige bij de maaltijd op te nemen. Het eerste wat de actor doet is het selecteren van een Maaltijd. Dit gaat op dezelfde manier als in use-case Agenda invullen. Vervolgens zal de Userinterface een lijst met gasten moeten tonen. Net zoals we in de use-case Inloggen de Persoon-klasse vroegen om een Persoon-object met een bepaalde naam, kunnen we nu de Persoon-klasse vragen om een lijst met Persoon-objecten met het type gast. De Userinterface toont de lijst met bekende gasten. De actor geeft aan een nieuwe gast te willen toevoegen. De Userinterface vraagt de benodigde informatie over deze gast en maakt een nieuw Persoon-object van het juiste type. De actor selecteert deze Persoon als gast. Userinterface geeft een referentie naar het nieuwe Persoon-object door aan de Maaltijd. Het maken van een interactiediagram voor deze use-case laten we aan de lezer over. 11.3.5 Boodschappenlijst versturen Het meest complete interactiepad in deze use-case is wanneer alle huisgenoten hun weekschema hebben ingevuld, er een aantal Maaltijden is met een Recept en bovendien de actor extra items aan de boodschappenlijst wil toevoegen voordat deze verstuurd wordt. 125

praktisch uml sd boodschappenlijst versturen :Userinterface Persoon w:week maakbestelling lijst := vindhuisgenoten() loop *[i in lijst] isingevuld(i) maakbestelling(w) toonlijst lijst ingrediënten voegtoe(item) voegtoe(item) ref selecteer supermarkt :Voorraadkast :Maaltijd :Recept :Persoon ref bepaal_ingrediënten stuurfax :Supermarkt Figuur 11-3 Sequencediagram Boodschappenlijst versturen 126

ho ofdstuk 11 case: sequence- en c ommunicatiediagrammen Als eerste moet gecheckt worden of alle huisgenoten het weekschema hebben ingevuld. Daarvoor moet Userinterface een lijst met huisgenoten hebben. Zoals in de use-cases Inloggen en Gast(en) aangeven wordt deze lijst gevraagd aan de klasse Persoon d.m.v. het aanroepen van een klasseoperatie. Voor alle objecten uit deze lijst wordt aan Week de vraag gesteld of deze Persoon de agenda al heeft ingevuld. Vervolgens zal Userinterface aan Voorraadkast de opdracht geven om een boodschappenlijst te genereren. Voorraadkast vraagt dan aan Week om alle Maaltijden in die Week en dan aan iedere Maaltijd om de benodigde Ingrediënten. Maaltijd zelf zal dan eventueel Recept om zijn Ingrediënten vragen. Als er geen Recept aanwezig is, zal Maaltijd aan elke aanwezige Persoon om zijn Voorkeur voor die Maaltijd vragen. Maaltijd berekent op basis van het aantal aanwezigen welke Ingrediënten nodig zijn en geeft deze terug naar Voorraadkast. Voorraadkast zal alle lijsten verzamelen in één lijst en dan voor elk Ingrediënt uit die lijst berekenen wat het verschil is tussen de benodigde hoeveelheid en de voorraad. Het resultaat hiervan wordt teruggegeven aan Userinterface die dit toont aan de actor. De actor voegt een item toe en geeft aan de lijst te willen versturen. Userinterface geeft de toevoeging door aan Voorraadkast en vraagt Voorraadkast om de lijst met Supermarkten. Userinterface toont de Supermarkten. De actor selecteert een supermarkt. Userinterface geeft aan Voorraadkast de selectie door, waarop Voorraadkast de boodschappenlijst omzet in een vorm die gefaxt kan worden, om deze vervolgens aan de Supermarkt-actor te faxen. Het sequencediagram dat deze interactie beschrijft staat uitgewerkt in figuur 11 3. Omdat dit sequencediagram omvangrijk is hebben we twee onderdelen in een apart sequencediagram ondergebracht. In figuur 11 4 staat het sequencediagram bepaal ingrediënten, en in figuur 11 5 het sequencediagram selecteer supermarkt. Vanuit boodschappenlijst versturen wordt aan beide diagrammen gerefereerd. 127

praktisch uml sd bepaal ingrediënten w:week :Voorraadkast m:maaltijd :Recept p:persoon maaltijden := geefmaaltijden loop *[m in maaltijden] geef Ingrediënten alt [receptaanwezig] ingrediënten : geefingredienten [niet receptaanwezig] loop *[p in aanwezigen] geef voorkeuren(maaltijd) ingrediënten ingrediënten Figuur 11-4 Sequencediagram bepaal ingrediënten sd selecteer supermarkt :Userinterface :Voorraadkast geefsupermarkten toon (supermarkten) selecteer(s) supermarkten zetsupermarkt(s) Figuur 11-5 Sequencediagram selecteer supermarkt 128

ho ofdstuk 11 case: sequence- en c ommunicatiediagrammen 11.3.6 Kookboek inzien De interactie voor het inzien van het kookboek is vrijwel gelijk aan de interactie voor use-case Recept kiezen. We zullen deze dan ook niet hier uitwerken. 11.3.7 Overzicht aanwezigheid opvragen Het opvragen van een overzicht van de aanwezigheid van alle personen gaat op dezelfde wijze als het tonen van de agenda bij het inloggen. Het enige verschil is dat er nu meer informatie getoond wordt. Omdat het verschil tussen deze twee gevallen zo klein is kunnen we ook als default alle aanwezigen bij de maaltijden in een week laten zien. We besluiten dat dit niet werkelijk een andere use-case is, maar simpel een andere manier om de beschikbare informatie te tonen. Dit tonen zal worden afgehandeld in de userinterface. 11.3.8 Binnengekomen inkopen opvoeren Het meest kenmerkende interactiepad in deze use-case is dat waarin de actor de hoeveelheid van minstens één item in de uitstaande bestelling wijzigt en er minstens één item aan toevoegt. De Userinterface zal starten met het sturen van een boodschap naar Voorraadkast om de uitstaande bestelling te kunnen tonen. De actor zal dan in de getoonde lijst gaan wijzigen waarna de Userinterface de gewijzigde lijst terugstuurt naar de Voorraadkast. Voorraadkast zal voor elk element in de lijst de nieuwe hoeveelheid in voorraad berekenen en deze doorgeven aan de betreffende Ingrediënt-objecten. Het maken van een interactiediagram laten we als oefening aan de lezer. 11.3.9 Voorraad inzien De interactie voor het inzien van de voorraad is vrijwel gelijk aan het eerste deel van de interactie voor use-case Binnengekomen boodschappen opvoeren. We zullen deze dan ook niet hier uitwerken. 129

praktisch uml 11.4 Terugkoppeling naar het klassediagram Vervolgens bekijken we de gevolgen van het maken van deze diagrammen voor het klassediagram. De operatie berekeningrediënten in Maaltijd lijkt er toch op te wijzen dat er een onderscheid gemaakt moet worden tussen Warme en Koude Maaltijden. Voor een Maaltijd met een Recept worden de ingrediënten namelijk op een heel andere manier bepaald. Dit verschil blijft echter beperkt tot een enkele operatie. Wij blijven daarom bij onze vorige keuze en veranderen het klassediagram niet wezenlijk. Wel kunnen er veel operaties aan de klassen worden toegevoegd. Vrijwel elke binnenkomende boodschap kunnen we immers vertalen naar een operatie bij de klasse. Omdat dit werk alleen tijd en discipline vergt, maar ons niet voor grote problemen stelt, laten we ook dit aan de lezer over. 130