Hoofdstuk 5. case: klassediagram

Transcriptie

1 Hoofdstuk 5 case: klassediagram In dit hoofdstuk wordt het maken van het klassediagram in het domeinstadium voor onze case uitgewerkt. We maken dus een domein-klassediagram van EasyShop, het maaltijdsysteem van Hans en Jacqueline. Dit geschiedt volgens de stappen die in hoofdstuk 4 zijn aangegeven. 5.1 Identificeer alle kandidaatklassen Het houden van een brainstormsessie is niet te simuleren in de vorm van geschreven tekst. Daarom wordt deze eerste stap uitgevoerd op de eerste wijze die in wordt aangegeven, namelijk door onderstreping van alle zelfstandige naamwoorden in de probleembeschrijving. Daarnaast worden de resultaten gegeven van een korte brainstorm die de auteurs met betrekking tot dit onderwerp gehouden hebben om te zorgen dat onze lijst met kandidaatklassen zo compleet mogelijk is. Hierna volgt de probleembeschrijving uit hoofdstuk 3 met daarin de zelfstandige naamwoorden onderstreept. Als een woord in onderstaande tekst al eerder onderstreept is dan is verdere onderstreping achterwege gelaten. Er wordt geen onderscheid gemaakt tussen zelfstandige naamwoorden in de enkelvoudige of meervoudige vorm. Hans en Jacqueline moeten onafhankelijk van elkaar het systeem kunnen gebruiken. Ze willen per week een scherm zien waarop ze kunnen aangeven of ze wel of niet aanwezig zijn bij het diner, lunch en/of ontbijt. Bovendien moet aangegeven kunnen worden of er gasten verwacht worden. Het is de bedoeling dat elke huisgenoot alleen voor zichzelf de agenda invult. Per dag wordt bovendien aangegeven wie er kookt. Deze persoon zal uit een aantal recepten kiezen wat er die dag gegeten wordt. Op basis van de gegeven recepten plus informatie over de meest geprefereerde lunch en ontbijt van zowel Hans als Jacqueline zal het systeem één keer per week een boodschappenlijst maken. Hans of Jacqueline zal deze actie initiëren, want aanwezigheid van een van hen is vereist voor de bezorging. Op dagen die niet ingevuld zijn, wordt geacht dat er niemand aanwezig zal zijn. Deze boodschappenlijst zal per fax naar de lokale supermarkt gestuurd worden waarna de supermarkt de gevraagde boodschappen thuisbrengt (tussen en u.). Het systeem bewaart een lijst met faxnummers van lokale supermarkten met een bezorgdienst. De gebruiker zal uit deze lijst kunnen kiezen. Het systeem zal de voorraad van het huishouden bijhouden. Wanneer de boodschappen bezorgd worden, zal de gebruiker deze met de juiste hoeveelheden invoeren in 53

2 praktisch uml het systeem. Wanneer een dag verstreken is dan gaat het systeem ervan uit dat de maaltijden die dag genuttigd zijn. Tabel 5-1 Kandidaatklassen uit brainstorm afspraak bereidingswijze diepvriesgroente eter feestdag fornuis ingrediënt kok kooktijd logé prijs (van boodschap) verse groente voorraadkast Hans en Jacqueline zijn allebei geen ster in de keuken, daarom willen ze een kookboek met een groot aantal eenvoudige recepten in het systeem onderbrengen. Dit kookboek moet onafhankelijk van de agenda in te zien zijn, bijvoorbeeld op het moment dat gekookt moet worden. De mogelijke klassen die resulteren uit de onderstreping van de probleembeschrijving zijn te vinden in tabel 5 2. De mogelijke klassen uit de brainstormsessie van de auteurs staan in tabel 5 1. Tabel 5-2 Kandidaatklassen uit onderstreping actie agenda bedoeling bezorgdienst bezorging boodschap boodschappenlijst dag diner fax faxnummer gast gebruiker Hans hoeveelheid huisgenoot huishouden informatie Jacqueline keuken kookboek lunch maaltijd ontbijt persoon recept scherm ster supermarkt systeem voorraad week ze 54

3 ho ofdstuk 5 case: klassediagram 5.2 Selecteer klassen uit de kandidatenlijst Het modelleren van personen De selectie van klassen beginnen we met het beschouwen van de functie van de personen in ons model. Personen spelen zonder twijfel een zelfstandige rol in het probleemdomein en daarom mag verwacht worden dat een of meer klassen die personen representeren in het model te vinden zijn. Maar hoe moeten personen worden gemodelleerd? Voor het beantwoorden van deze vraag gebruiken we de criteria uit Kandidaatklassen zijn er genoeg: gast, gebruiker, Hans, huisgenoot, Jacqueline, persoon, ze, eter, kok, logé. Dit lijstje maakt direct al duidelijk dat er sprake is van redundantie. Als we eter nemen in de betekenis van persoon die te eten komt, dan refereren de termen gast, logé en eter aan een zelfde klasse. De term eter kan ook gebruikt worden in de zin van iemand die iets eet. In dat geval komt de term overeen met Hans, Jacqueline en gast. De term is daarom zeker niet specifiek genoeg om als klasse op te nemen. Ook de term ze is te onduidelijk om als klasse te fungeren. We kiezen voorlopig gast als naam voor de klasse van personen die te eten komen en laten logé en eter vervallen. Verder kunnen we stellen dat Hans en Jacqueline elk objecten zijn, maar geen klasse. Zij zijn instanties van de klasse gebruiker, huisgenoot of persoon. Wat betreft de kandidaten persoon, gebruiker, en huisgenoot, kunnen we stellen dat gebruiker en huisgenoot beide hetzelfde begrip aanduiden: een persoon wiens aanwezigheid geregistreerd moet worden en die eventueel als kok kan fungeren. Verder is persoon een algemenere klasse dan gebruiker. Alleen Hans en Jacqueline zijn instanties van de klasse gebruiker, alle werkelijke personen kunnen instanties zijn van de klasse persoon. Daarom kiezen we ervoor om de klasse persoon in het model op te nemen. De kandidaatklasse gebruiker/huisgenoot blijft in reserve. Wellicht is onderscheid tussen de specifiekere klasse gebruiker/huisgenoot en de algemene klasse persoon op een later tijdstip nodig, nu is daar nog geen reden toe. Wanneer we ingaan op de samenhang tussen de kandidaatklassen dan zien we dat kok een rol is van een instantie van de klasse persoon. De ene maaltijd is Jacqueline kok, de volgende maaltijd is Hans kok en het is zelfs denkbaar dat op een gegeven moment een gast wordt uitgenodigd die geweldig goed kan koken en de maaltijd klaar wil maken. Op dat moment is de gast kok. Kok is dus geen klasse. Nu we gekozen hebben voor een algemene klasse persoon kunnen we stellen dat gast ofwel een specifiekere vorm van persoon is (en dus een subklasse) ofwel een rol van persoon. Omdat het gebruik van subklassen ons model minder flexibel kan maken gaan we er voorlopig van uit dat gast een rol van persoon is. Hetzelfde geldt voor gebruiker. Dit argument zal een rol moeten spelen bij de uiteindelijke beslissing om de subklassen gebruiker en gast wel of niet in het model op te nemen. Op dit moment is er dus één klasse in het klassediagram waarin personen uit de werkelijkheid worden weergegeven: de klasse persoon. 55

4 praktisch uml Duidelijke klassen We gaan verder met onze zoektocht naar klassen die een zelfstandige rol spelen in het probleemdomein. De kandidaatklassen maaltijd, voorraadkast, supermarkt, recept en kookboek spelen duidelijk die zelfstandige rol. Diner, lunch en ontbijt zijn ook duidelijke zelfstandige eenheden met een bepaalde verantwoordelijkheid (bijvoorbeeld bijhouden wie kok is bij een diner), maar dit zouden ook rollen van maaltijd kunnen zijn. Omdat diner zo n speciale verantwoordelijkheid heeft met betrekking tot recept en kok kiezen we er voorlopig voor om diner, lunch en ontbijt als aparte klassen in het model onder te brengen. Dag en week zijn ook redelijk duidelijke zelfstandige eenheden in het systeem, waarbij een goede definitie van week noodzakelijk is. Vanaf nu is een week de samenvoeging van zeven opeenvolgende dagen, te weten zondag tot en met zaterdag. Boodschappenlijst lijkt ook een duidelijk zelfstandig begrip te zijn, maar wanneer we bekijken wat een boodschappenlijst is, dan is het niets anders dan een lijst van meerdere instanties van de kandidaatklasse boodschap. Waarschijnlijk kunnen we dit beter niet met een aparte klasse maar met een associatie modelleren. Voorlopig kiezen we hiervoor. Agenda is een kandidaatklasse die inderdaad zelfstandig is, maar waarvan de definitie ons voor problemen stelt. In 5.3 zullen we hier verder op ingaan Redundante klassen In de vorige paragrafen zijn al een aantal klassen als redundant geïdentificeerd. Redundantie komt namelijk vaak voor wanneer een kandidaatklasse niet duidelijk een echte klasse is. Het is dan zaak te zorgen voor een goede naamgeving en een precieze definitie van de betreffende klasse. Een redundante klasse in deze case is de kandidaat boodschap. Deze term refereert aan eenzelfde begrip als de term ingrediënt. Omdat de term ingrediënt algemener is dan boodschap kiezen we de naam ingrediënt als naam voor de klasse in het objectmodel Irrelevante klassen Als irrelevant voor dit systeem zijn te herkennen: bezorging, fornuis, ster, afspraak, bedoeling, bezorgdienst, feestdag, huishouden en keuken, waarbij een aantal zeker relevant is, maar buiten de grenzen van dit systeem valt Vage klassen Zo snel als een aantal duidelijke klassen herkend zijn zo snel kunnen ook vage klassen worden herkend. Actie, informatie, systeem, en zoals we al gezien hebben ze, zijn vage termen en horen niet in het objectmodel thuis. Hoeveelheid is op zich ook een vage term, maar we hebben iets dergelijks wel nodig. We moeten hoeveelheden van ingrediënt ken- 56

5 ho ofdstuk 5 case: klassediagram nen. Voorlopig kiezen we ervoor om ingrediënt zelf zijn hoeveelheid bij te laten houden en we wijzen hoeveelheid als klasse af Niet-kwantificeerbare zaken Zoals in de vorige paragraaf gesteld, is het nodig om een hoeveelheid bij ingrediënt bij te houden. Immers ook bloem, melk of water zijn ingrediënt van recepten. Om deze reden zouden we eigenlijk ingrediënt als klasse moeten afwijzen. Toch is ingrediënten wezenlijk in onze case, alles draait immers om het bestellen van de juiste ingrediënten. We houden daarom nog steeds (voorlopig) vast aan eerder gemaakte keuzen. In 5.5 zullen we hierop terugkomen Attributen Om een kandidaatklasse als attribuut te identificeren, is het goed om de naam van de kandidaatklasse in te vullen in de volgende vraag: is... een aspect van een andere klasse? Oftewel is de kandidaat een zelfstandig begrip? De kandidaatklassen bereidingswijze, kooktijd, voorraad en prijs vallen bij deze test direct door de mand: dit zijn attributen. Verder valt bij verse groenten en diepvriesgroenten op dat dit eigenlijk dubbele termen zijn. We moeten de termen groenten, vers en diepvries apart als kandidaat beschouwen. Groenten is in dat geval een vorm van ingrediënt, waarbij we de voorkeur geven aan de meer algemene term ingrediënt als klasse in het objectmodel. Vers en diepvries zijn beide duidelijk attributen. De term faxnummer lijkt op het eerste gezicht geen attribuut, maar ook een faxnummer is binnen dit systeem alleen zinvol als attribuut van een supermarkt. (Voor een systeem voor een telecomprovider is dit wellicht anders.) Operaties en rollen Operaties komen niet voor in onze lijst van kandidaatklassen. De rollen die voorkwamen zijn al als dusdanig geïdentificeerd in Implementatieaspecten Een van de heuristieken genoemd in is het verwijderen van implementatieaspecten uit de lijst met kandidaatklassen. Implementatieaspecten in onze case zijn: fax en scherm. In tabel 5 3 staat de lijst met klassen die in het objectmodel zullen worden opgenomen. In het vervolg van deze case zal de gangbare conventie worden aangehouden dat klassenamen met een hoofdletter en namen van instanties met kleine letters worden geschreven. 57

6 praktisch uml Tabel 5-3 Resultaat van klasseselectie Kandidaatklasse Beslissing Kandidaatklasse Beslissing actie te vaag afspraak irrelevant agenda te vaag bedoeling irrelevant bereidingswijze attribuut bezorgdienst irrelevant bezorging irrelevant boodschap redundant met ingrediënt boodschappenlijst associatie Dag is klasse diepvriesgroenten te specifiek (instantie?) Diner is klasse eter redundant met gast fax implementatie faxnummer attribuut feestdag irrelevant fornuis irrelevant gast redundant met persoon gebruiker redundant met persoon Hans instantie hoeveelheid te vaag, attribuut huishouden irrelevant huisgenoot redundant met persoon Ingrediënt is klasse informatie te vaag Jacqueline instantie keuken irrelevant kok rol Kookboek is klasse kooktijd attribuut logé redundant met gast Lunch is klasse Maaltijd is klasse Ontbijt is klasse Persoon is klasse prijs (van boodschap) attribuut Recept is klasse scherm implementatie ster irrelevant Supermarkt is klasse systeem te vaag verse groenten te specifiek (instantie?) voorraad attribuut Voorraadkast is klasse Week is klasse ze te vaag 58

7 ho ofdstuk 5 case: klassediagram 5.3 Maak een modeldictionary In deze stap moeten alle klassen eenduidig gedefinieerd worden. Vaak kost dit enige moeite. De klasse Agenda is zo n probleemgeval. Wat betekent een dergelijke klasse voor ons systeem? Welke verantwoordelijkheid kunnen we eraan toekennen? Voor ons systeem is een agenda een verzameling van weken, dagen en maaltijden, waaraan informatie gekoppeld is over de aanwezigheid van personen. Het lijkt dat we deze agenda al tot in detail hebben gemodelleerd door de klassen Week, Dag, Maaltijd en Persoon op te nemen. Het is alleen wel zaak de juiste associaties tussen de klassen te leggen. De conclusie is dus dat de klasse Agenda uit het systeem verdwijnt. Tabel 5-4 De modeldictionary Klasse Dag Diner Ingrediënt Kookboek Lunch Maaltijd Ontbijt Persoon Recept Supermarkt Voorraadkast Week Omschrijving Afgeronde tijdseenheid waarbinnen een van tevoren bepaald aantal maaltijden valt. Elke maaltijd is ofwel een Ontbijt, een Lunch, ofwel een Diner. Een maaltijd waarbij warm voedsel genuttigd wordt dat wordt bereid volgens een Recept. Diner is verantwoordelijk voor het bijhouden van de aanwezigheid van Personen en voor het bijhouden van gegevens over de kok. Voedselbestanddeel dat gebruikt kan worden bij de bereiding van een Recept en/of het nuttigen van een Diner, Lunch of Ontbijt. Verzameling Recepten. Is verantwoordelijk voor zoekmethoden binnen de verzameling. Maaltijd waarbij voedsel genuttigd wordt dat niet wordt bereid volgens een Recept. Moment in tijd waarop voedsel genuttigd wordt. Maaltijd waarbij voedsel genuttigd wordt dat niet wordt bereid volgens een Recept. Representatie binnen het systeem van een reëel persoon. Wijze om van Ingrediënten warm voedsel te maken. Representatie binnen het systeem van een reële supermarkt. Beheerder van de voorraad. Is verantwoordelijk voor het bijhouden van de hoeveelheden van de Ingrediënten die in voorraad zijn en voor het opstellen en versturen van een bestelling. Samenvoeging van zeven opeenvolgende Dagen, te weten zondag tot en met zaterdag. Is verantwoordelijk voor het presenteren van de agenda aan de gebruiker. 59

8 praktisch uml De Voorraadkast is verantwoordelijk voor alle zaken die betrekking hebben op Ingrediënten, het bestellen ervan, nagaan of er voldoende voorraad van in huis is, enz. Waarschijnlijk is dit een singleton klasse, dat wil zeggen dat er maar één instantie van in het systeem zal zijn. Verder blijkt dat moeilijk onderscheid te maken valt tussen de Lunch en het Ontbijt. Omdat we verwachten dat de relatie tussen deze klassen en Diner en Maaltijd ons meer inzicht in de klassen zelf zal verschaffen, laten we op dit moment voor beide dezelfde (ontoereikende) definitie toe. Voorzover het op dit moment al duidelijk is, zijn in de definities de verantwoordelijkheden van de klassen afgebakend. Het afbakenen van verantwoordelijkheden helpt vaak bij het zoeken naar de juiste definitie. Tabel 5 4 bevat de lijst met definities voor de tot nu toe gevonden klassen. Hierin ontbreken de definities van attributen e.d. die we nu reeds herkend hebben. Het zal de lezer echter weinig fantasie kosten om deze lijst aan te vullen. 5.4 Identificeer associaties In deze stap identificeren we alle mogelijke kandidaatassociaties. In principe zijn dit alle combinaties van twee klassen uit ons model. Een aantal associaties wordt ons direct aangereikt vanuit de modeldictionary. Een Dag heeft een relatie met een aantal Maaltijden, een Week met zeven Dagen, een Recept met een Diner en meerdere Ingrediënten, enz. Associaties die niet direct uit de modeldictionary komen maar zeker relevant zijn, zijn Diner Persoon (te weten de associaties: kok en aanwezig bij), Lunch Persoon (geprefereerd, aanwezig bij) en Ontbijt Persoon (geprefereerd, aanwezig bij). Tussen Lunch en Ingrediënt ligt eveneens een associatie, zoals natuurlijk ook tussen Ontbijt en Ingrediënt. Omdat de Voorraadkast verantwoordelijk is voor het doen van een bestelling bij de Supermarkt, is er ook een associatie tussen Voorraadkast en Supermarkt. De multipliciteiten die nu al duidelijk zijn, worden bij het maken van de eerste versie van het klassediagram direct meegenomen, maar we gaan niet zoeken naar de juiste multipliciteit van de associaties. Dat doen we bij een volgende iteratieslag. Als resultaat van stap vier kan een eerste klassediagram getekend worden waarin alle klassen en hun associaties worden weergegeven. Dit klassediagram vindt u in figuur 5 1. Natuurlijk is dit slechts een eerste schets van een klassediagram en we zullen dit in de vervolgstappen verbeteren. 60

9 ho ofdstuk 5 case: klassediagram Week 7 Dag Maaltijd Supermarkt Diner Lunch Ontbijt Kookboek 0..1 Recept Persoon kok Voorraadkast voorraad bestelling ingrediënt Figuur 5-1 Eerste versie klassediagram voor EasyShop 5.5 Identificeer attributen De attributen die in stap twee zijn verwijderd uit de lijst met klassen moeten nu worden toegekend aan één of meer klassen, waarbij met meer klassen wordt bedoeld dat een attribuut met eenzelfde naam bij één of meer klassen kan voorkomen. Een voorbeeld hiervan is het nieuwe attribuut naam. Dit attribuut kennen we toe aan Dag, Recept en Persoon. In de klasseselectie in stap twee hebben we een aantal attributen gevonden: bereidingswijze, faxnummer, kooktijd, prijs en het onderscheid verse en diepvries-groenten. Vers en diepvries zijn attributen die bij Ingrediënt horen, maar eigenlijk zijn dit twee waarden van een ander attribuut dat we type noemen. Prijs is een attribuut bij Ingrediënt, maar het is de vraag of we dit willen registreren, aangezien de prijs van een ingrediënt buiten het systeem om bepaald wordt en bovendien afhankelijk is van de keuze van de supermarkt. Kooktijd is een attribuut bij Recept, maar de naam bereidingstijd geeft beter weer wat er mee bedoeld wordt, namelijk de totale tijd die de kok nodig heeft om dit recept klaar te maken. Faxnummer was al geïdentificeerd als attribuut bij Supermarkt en het laatste attribuut bereidingswijze is duidelijk een attribuut bij Recept. 61

10 praktisch uml Hoeveelheid en voorraad zijn ook attributen die gevonden zijn tijdens de klasseselectie. In eerste instantie waren ze ondergebracht bij Ingrediënt, waarbij hoeveelheid gedefinieerd kan worden als de hoeveelheid van het Ingrediënt dat nodig is voor een Recept, en voorraad als de hoeveelheid die aanwezig is (in de Voorraadkast). Maar Voorraadkast moet ook bijhouden hoeveel van een bepaald Ingrediënt in bestelling is. We kunnen dit modelleren door nog een attribuut aan Ingrediënt toe te voegen, maar we kunnen dit ook oplossen door zowel de bestelling als de voorraad te modelleren als een associatie van Voorraadkast met Ingrediënt. Ingrediënt bevat nu alleen een attribuut hoeveelheid. Als Voorraadkast via de associatie voorraad een Ingrediënt-object vindt, dan betekent hoeveelheid de hoeveelheid die nog in voorraad is en als Voorraadkast via de associatie bestelling een Ingrediënt-object vindt, dan betekent hoeveelheid de hoeveelheid die in bestelling is. Evenzo geldt dat als Recept naar hoeveelheid van een Ingrediënt-object vraagt het de betekenis heeft van hoeveelheid die nodig is in dat recept. Als een soort ingrediënt zowel in voorraad is, als in recepten gebruikt wordt, dan heeft zowel de Voorraadkast als ieder Recept zijn eigen aparte instantie van Ingrediënt. Stel dat er twee kilo aardappelen in voorraad is en er is een recept waarin één kilo aardappelen nodig is. Er bestaat dan een instantie van Ingrediënt met de waarde 2 kilo voor hoeveelheid, die een link met Voorraadkast heeft. Er bestaat ook een tweede instantie van Ingrediënt met de waarde 1 kilo voor hoeveelheid, die een link met het betreffende Recept heeft. Nieuwe attributen die snel herkend kunnen worden zijn moeilijkheidsgraad bij Recept (Hans en Jacqueline waren immers geen keukenprinsessen), nummer bij Week, naam bij Maaltijd en bestellingverzondenop bij Voorraadkast. Omdat we verschillende soorten van personen hebben, voegen we een attribuut type toe aan Persoon. Op dit moment laten we het hierbij, andere attributen worden meestal snel gevonden in volgende iteratieslagen. 5.6 Identificeer operaties In deze stap ligt de focus op de verantwoordelijkheid van de klasse. Deze verantwoordelijkheid wordt als het ware omgezet in operaties die de klasse moet implementeren (services die de klasse moet bieden) om die verantwoordelijkheid waar te kunnen maken. Voor nog niet alle klassen was de verantwoordelijkheid al geheel duidelijk; daarom worden hier alleen die klassen in beschouwing genomen waarvoor in de modeldictionary de verantwoordelijkheid al is beschreven. Diner is verantwoordelijk voor het bijhouden van de gegevens over de kok. Diner heeft dus een aantal operaties zoals geefnaamkok en meldkokaan. Het is niet nodig hier volledig te zijn, we kunnen volstaan met één of meer operaties die als het ware de richting aangeven waarin de implementatie van de klasse moet gaan. Voorraadkast is verantwoordelijk voor het bijhouden van de hoeveelheid die aanwezig is en die besteld is. Voorraadkast heeft operaties die de voorraad wijzigen, bijvoorbeeld 62

11 ho ofdstuk 5 case: klassediagram vermindervoorraad, en operaties die de lijst met bestelde Ingrediënten wijzigen, bijvoorbeeld doebestelling en ontvangbestelling. Kookboek is verantwoordelijk voor zoekmethoden binnen de verzameling recepten en zal dus een aantal operaties met zoekalgoritmen moeten implementeren. Voorlopig volstaan we met een operatie zoekrecept. Week is verantwoordelijk voor het presenteren van de agenda en heeft natuurlijk een operatie toonweekschema. 5.7 Generaliseer met behulp van overerving In stap zeven zoeken we naar overervingrelaties. Een wel heel voor de hand liggende overervingrelatie is die tussen Maaltijd enerzijds en Diner, Lunch en Ontbijt anderzijds. Maaltijd is hierin de superklasse en de andere klassen zijn subklassen. Maar het is niet voldoende om enkel de overervingrelatie te herkennen, de associaties zullen moeten worden aangepast. De associatie aanwezigbij zal nu van Persoon naar Maaltijd lopen en niet meer van Persoon naar Diner, Lunch en Ontbijt. Op dit moment willen we ook de klassen Lunch en Ontbijt onder de loep nemen. Er zijn tot nu toe geen verschillen tussen de twee opgemerkt. Waarschijnlijk kunnen we dus met één klasse volstaan. Deze klasse noemen we KoudeMaaltijd. In tegenstelling daarmee kunnen we Diner hernoemen tot WarmeMaaltijd. Het resultaat van de stappen vijf, zes en zeven vindt u in het klassediagram in figuur 5 2 op de volgende pagina. Dit klassediagram is een hele verbetering op het diagram in figuur 5 1 waarin rond Persoon, Maaltijd en de subklassen van Maaltijd een netwerk aan associaties lag. Het model in figuur 5 2 is heel wat duidelijker. 5.8 Vervolgstappen De volgende stappen zijn het toevoegen van bedrijfsregels met behulp van OCL-constraints, het groeperen van de klassen in packages en itereren over de gedane stappen. Deze stappen zullen we voor onze case uitvoeren na het volgende hoofdstuk Object Constraint Language. 63

12 praktisch uml nummer Week 7 naam Dag naam Maaltijd toonweekschema() Supermarkt faxnummer WarmeMaaltijd nummer KoudeMaaltijd nummer Kookboek zoekrecept() geefnaamkok() meldkokaan() Recept naam bereidingswijze bereidingstijd moeilijkheidsgraad 0..1 kok voorkeuren naam type Persoon aanwezigen 0..1 Voorraadkast bestellingverzondenop voorraad 0..1 doebestelling() ontvangbestelling() vermindervoorraad() 0..1 bestelling ingrediënt type hoeveelheid Figuur 5-2 Tweede versie klassediagram voor EasyShop 64