[UML] Klassendiagram Online Pizzeria

[martijnvds]

***************28-03-05 Klassendiagram updated, zie laatste bericht in dit topic****************
*************************************Comments gevraagd!!*******************************************

Klassendiagram

Ik moet morgen een opdracht voor een vak (Modelleren & Systeemontwikkeling, Informatiekunde, Universiteit Utrecht) inleveren. Nu heb ik met een studiegenoot een klassendiagram gemaakt wat aan de volgende beschrijving moet voldoen:

Een pizzeria biedt de mogelijkheid via het internet bestelde pizza's te laten thuisbezorgen. Een softwaresysteem houdt de omzet, de klantgegevens en de voorraden bij. Modelleer dit softwaresysteem in een UML-klassendiagram. Bedenk zelf welke gegevens omtrent klanten, leveranciers, ingrediënten etc. worden bijgehouden. Geef duidelijk aan welke methoden in welke klasse staan en welke klassen of methoden abstract zijn.


Oude versie, nieuwste versie in laatste bericht in dit topic

Use case diagram

Ik moet ook een aantal Use Cases van het systeem beschrijven en in een diagram zetten. De opdracht zegt hier het volgende over:

Een pizzeria biedt de mogelijkheid via het internet bestelde pizza's te laten thuisbezorgen. Een softwaresysteem houdt de omzet, de klantgegevens en de voorraden bij. Modelleer het gebruik van het systeem met behulp van ten minste drie use case-diagrammen en -beschrijvingen.

Ik en mijn practicumpartner hebben vier beschrijvingen gemaakt, die vind je hier.

Nu is er naar mijn idee met de beschrijvingen niet zoveel mis, maar het onderstaande diagram komt ergn simpel op mij over, maar ik zou ook niet kunnen bedenken wat er nog meer bij hoort/wat er mist. Iemand ideeen suggesties? Wederom bedankt, het is nl. erg belangrijk om deze opdracht te halen

[ Voor 59% gewijzigd door martijnvds op 28-03-2005 14:59 . Reden: Updated Klassendiagram 28-03-05 ]

[NMe]

Je hebt alle attributen private gemaakt, met die -. Dat is prima, an sich, maar het betekent wel dat je er van buiten niet aan kan. Weet je zeker dat je geen accessor-methodes nodig hebt?

Verder: moet je niet attributen opnemen om bijvoorbeeld ingrediënten op te nemen bij een pizza? Of is dat implementatiespecifiek, en hoeft dat voor je opdracht niet?

[Verwijderd]

Ik mis inderdaad getters en setters.

Verder is je pizza-ingredienten interactie nog niet optimaal. Wat doe je bijvoorbeeld als iemand een pizza met extra, of juist zonder champions wil (om maar even iets te zeggen).

Ook stokeer je adressen enzo allemaal in strings. Zou het niet beter zijn een adres-klasse te maken, zodat een klant meerdere adressen kan hebben. Dit allemaal met oog op uitbreidbaarheid. Zo zou je de adres-klasse later ook kunnen gebruiken om de adressen van de leveranciers op te slaan. Zelfde verhaaltje kan je doen met meerdere telefoonnummers, of meerdere emailadressen...

[martijnvds]

-NMe- schreef op zaterdag 26 maart 2005 @ 23:05:
Je hebt alle attributen private gemaakt, met die -. Dat is prima, an sich, maar het betekent wel dat je er van buiten niet aan kan. Weet je zeker dat je geen accessor-methodes nodig hebt?

Verder: moet je niet attributen opnemen om bijvoorbeeld ingrediënten op te nemen bij een pizza? Of is dat implementatiespecifiek, en hoeft dat voor je opdracht niet?

Wat bedoel je precies met dat laatste? Het idee is dat een klant online één of meerdere pizza's samenstelt, waarbij hij alle ingredienten zelf kan kiezen (behalve tomaat en kaas, die zijn standaard). Iedere pizza is dus 'uniek'. Van pizza naar ingredient is een aggegratie, een ingredient 'is-a-part-of' een pizza. Dus volgens mij hoef je dan bij de klasse pizza ook niet nog een keer een attribuut ingredient toe te voegen, maar dat weet ik dus niet zeker!

Verwijderd schreef op zaterdag 26 maart 2005 @ 23:58:
Ik mis inderdaad getters en setters....

Ja die dingen snap ik dus niet goed, waar zou ik ze nodig hebben en voor wat?

Verder is je pizza-ingredienten interactie nog niet optimaal. Wat doe je bijvoorbeeld als iemand een pizza met extra, of juist zonder champions wil (om maar even iets te zeggen).

Extra is bijv. geen optie, maar je kunt zelf je ingredienten kiezen. Wat klopt er niet aan de interactie?

Ook stokeer je adressen enzo allemaal in strings. Zou het niet beter zijn een adres-klasse te maken, zodat een klant meerdere adressen kan hebben. Dit allemaal met oog op uitbreidbaarheid. Zo zou je de adres-klasse later ook kunnen gebruiken om de adressen van de leveranciers op te slaan. Zelfde verhaaltje kan je doen met meerdere telefoonnummers, of meerdere emailadressen

Ik zou idd een abstracte klasse 'adres' kunnen maken inderdaad, tnx voor de tip.

[Michali]

Getters en setters zijn methods of functies waarmee je de waarde van je atributen kunt zetten (of setten) en kun halen (of getten). Dus voor het price atribuut van pizza zou je dan getPrice() en setPrice(double price) hebben oid.

Overigens denk ik niet dat het zo snel nodig is om die toe te voegen aan je diagram. Als het gewoon duidelijk is dat voor ieder atribuut een getter en setter komt dan kun je dat wel achterwege laten. Anders is het wel slim om het even expliciet aan te geven.

Verder denk ik dat -NMe- bedoelt dat je geen functie hebt om alle ingredienten van een pizza te kunnen ophalen. Iets als getIngredients() oid.

[Verwijderd]

Over je pizza-ingredient interactie. Het lijkt me de bedoeling dat een klant een standaard pizza bestelt (=kaas+tomaten) en daar komen dan (vooraf bepaalde) ingredienten bij. Ik zie alleen niet goed hoe het proces pizza-ingredient werkt. Je zegt dat het een aggregatie is, wat goed is, maar ik mis hoe de implementatie verloopt. Misschien is dit te specifiek voor je opdracht, zoals -NMe- ook opmerkte, maar je hebt zowieso enkele methoden nodig om een ingredient toe te voegen. Ik mis ook een vector ofzo om de ingredienten die op de specifieke pizza liggen, bij te houden. Misschien moet het voor je opdracht er niet bij.

Verder weet ik niet hoe specifiek de opdracht was, maar je zou bepaalde subklassen van ingredient kunnen maken met overerving van methodes en dergelijke. Zou zou je (abstacte) subklassen "vlees" en "groenten" kunnen hebben met dan weer subklassen "gehakt", "salami", "hesp" of "champion". Ingredient zou dan abstract zijn. In deze context kan je in je cursus ook de begrippen polymorfisme en dynamische binding (in combi met overloading) eens bekijken (ik veronderstal dat die wel ergens aangehaald worden ).

Je zou die aparte klasse adres kunnen maken, waardoor je straat, huisnummer, postcode en dorp/gemeente/stad afzonderlijk kan ingeven. Hierdoor kan je nadien makkelijk klanten sorteren op postcode of whatever...

Over de getters en setters: ze zijn essentieel om een OO programma te hebben (wat de essentie zou moeten zijn van het hele vak), dus moeten ze echt wel vermeld staan, zoals ook Michali zei. Het is echter zo dat door de overaanwezigheid van getters en setters je UML-schema al snel onoverzichtelijker wordt. Daarom kan je ze misschien beter weglaten, maar ik zou zeker vermelden dat je weet dat ze er moeten staan. An sich zijn ze niet zo boeiend voor de structuur van je programma. Een goeie IDE, waar je behendig mee bent maakt setters en getters automatisch aan voor je, zoals bijvoorbeeld Eclipse voor Java dev. Mail anders even je prof/assistent en vraag hoe ze het het liefst hebben.

[ Voor 4% gewijzigd door Verwijderd op 27-03-2005 14:13 ]

[NMe]

martijnvds schreef op zondag 27 maart 2005 @ 10:43:
Wat bedoel je precies met dat laatste? Het idee is dat een klant online één of meerdere pizza's samenstelt, waarbij hij alle ingredienten zelf kan kiezen (behalve tomaat en kaas, die zijn standaard). Iedere pizza is dus 'uniek'. Van pizza naar ingredient is een aggegratie, een ingredient 'is-a-part-of' een pizza. Dus volgens mij hoef je dan bij de klasse pizza ook niet nog een keer een attribuut ingredient toe te voegen, maar dat weet ik dus niet zeker!

Ik bedoelde deels inderdaad wat de twee posts boven me al verteld is, maar waar ik ook op doelde is dat je op zijn minst een array of andere lijstvorm moet hebben, waar je referenties naar alle ingrediënt-objecten van je pizza in opslaat. Maar zoals ik al zei: dat kan te implementatiespecifiek zijn, en ik weet niet of dat de bedoeling is van je opdracht.

[JochemK]

Even nog een vraagje, ik ben niet heel bekend met UML (krijgen wij dit trimester geloof ik TU/e) maar wel met Databases en ER's,

je geeft al je pizza's een uniek ID mee, maar je zegt ook dat iedere pizza bestaat uit een min of meer willekeurig samenraapsel van ingredienten + kaas + tomaat, als ik dan vandaag een pizza "hawaii" = kaas, tomaat, ham, ananas bestel, en volgende week weer, krijgen die dan een ander ID?

Verder staat er iets in je opdracht over leveranciers, en die zie ik niet terug in je diagram, heb je daar bewust voor gekozen?

[NMe]

kingjotte schreef op zondag 27 maart 2005 @ 16:17:
je geeft al je pizza's een uniek ID mee, maar je zegt ook dat iedere pizza bestaat uit een min of meer willekeurig samenraapsel van ingredienten + kaas + tomaat, als ik dan vandaag een pizza "hawaii" = kaas, tomaat, ham, ananas bestel, en volgende week weer, krijgen die dan een ander ID?

Je moet niet in ID's denken, maar in geïnstantieerde objecten, en die instantiëer je op het moment dat je ze nodig hebt wel.

[martijnvds]

-NMe- schreef op zondag 27 maart 2005 @ 14:21:
Ik bedoelde deels inderdaad wat de twee posts boven me al verteld is, maar waar ik ook op doelde is dat je op zijn minst een array of andere lijstvorm moet hebben, waar je referenties naar alle ingrediënt-objecten van je pizza in opslaat. Maar zoals ik al zei: dat kan te implementatiespecifiek zijn, en ik weet niet of dat de bedoeling is van je opdracht.

Dus naast een methode getIngredient in de klasse Pizza zou ik ook een variabele composition/samenstelling kunnen maken met als type een array bedoel je? Dat klinkt opzich wel logisch Er staat niks in de opdracht over implementatie, het is wel object-georienteerd. Maar bovengenoemde lijkt me, los van de taal, wel vrij essentieel?

[Verwijderd]

Je gaat inderdaad steeds een lijst (array/vector) nodig hebben waarin alle keuzes van ingredienten zitten voor de pizza die je aan het maken bent. Je zou dus een methode getIngredient(ingredient) moeten maken welke een nieuw ingredient aanmaakt en een verwijzing naar dit laatste toevoegt aan je bestaande lijstje van ingredienten.

[NMe]

martijnvds schreef op zondag 27 maart 2005 @ 17:47:
Dus naast een methode getIngredient in de klasse Pizza zou ik ook een variabele composition/samenstelling kunnen maken met als type een array bedoel je? Dat klinkt opzich wel logisch Er staat niks in de opdracht over implementatie, het is wel object-georienteerd. Maar bovengenoemde lijkt me, los van de taal, wel vrij essentieel?

Het is zeker essentiëel, en onafhankelijk van de taal die je zou gebruiken voor de implementatie heb je sowieso een of andere lijstvorm nodig. Maar als je opdracht alleen het ontwerp omvat, en niet de implementatie, en als je enige vorm van abstractie mag gebruiken, dan zou het kunnen dat je van je leraar die lijst weg mag laten. Al zou ik hem gewoon opnemen.

[Verwijderd]

Niet dat ik ik iets van UML heb gegeten, maar waarom een telefoonnummer als integer ? Je gaat er toch niet mee rekenen ? Ik denk dat je dat gewoon als String moet gaan defineren

[ranzige pad]

Verwijderd schreef op zondag 27 maart 2005 @ 23:27:
Niet dat ik ik iets van UML heb gegeten, maar waarom een telefoonnummer als integer ? Je gaat er toch niet mee rekenen ? Ik denk dat je dat gewoon als String moet gaan defineren

En handiger als je voorloop nullen hebt. Tenzij je 31xxx xxx xxx formatering gebruikt, in dat geval is een int netter, aangezien het ook een int is.

[ Voor 8% gewijzigd door ranzige pad op 27-03-2005 23:38 ]

[Erkens]

ranzige_pad schreef op zondag 27 maart 2005 @ 23:38:
[...]


En handiger als je voorloop nullen hebt. Tenzij je 31xxx xxx xxx formatering gebruikt, in dat geval is een int netter, aangezien het ook een int is.

nee ook dan is het geen integer, daarnaast kan je dan problemen krijgen met de lengte ervan, waardoor je weer naar de implementatie moet kijken.
Voor telefoonnummers gebruik ik altijd een string (internationaal opgeslagen dient er een '+' voor te staan )

[Verwijderd]

Ik moet zelf ook nog een herkansing UML maken (vrijdag... en het is m'n laatste kans voor m'n propedeuse )... maar ik zou bij jouw case overwegen om bij order deliveryAdress te zetten (tenzij je alleen van plan bent om bij klanten die zelf bestellen af te leveren, ook daar is iets voor te zeggen), en uniqueID's zijn in UML niet nodig. Verder ligt het natuurlijk aan degene die het beoordeelt of je er get en set methodes bij zet, vaak wordt er al vanuit gegaan dat die er zijn voor iedere waarde dus die hoef je in het algemeen niet apart te vermelden (althans, ik hoef dat niet ).
Verder volg ik dit topic natuurlijk met mijn volle attentie .
En die descriptions die je hebt gemaakt, zijn die nou hetzelfde als use case templates? Want ik maak die dingen heel anders... (so much for 'Unified' Modeling... ).

[ Voor 17% gewijzigd door Verwijderd op 28-03-2005 00:01 ]

[martijnvds]

Bedankt voor alle tips en aandacht tot nu toe.
We hebben er nog een keer naar gekeken/over nagedacht en komen nu op het volgende diagram:



De rode nummers geven een aantal punten aan waar we nog niet over uit zijn/vragen over hebben:

1. Telephonenr aangepast naar String, gaat niet mee gerekend worden dus dat is goed lijkt ons?
Ervoor gekozen geen aparte address klasse te maken, supplier hoeven we niet op te nemen en adresgegevens zijn eenmalig. Er wordt niet voorzien in customer relationship management oid.
Tenzij iemand zegt dat het toch echt beter is om er wel een aparte klasse van te maken. In dat geval heeft de klasse Custuomer alleen een functie getAddress en setAddress nodig neem ik aan?

2. getCustomer en getPizza valide methodes/zinvol? of alleen de attributen ophalen die je echt nodig hebt? (respectievelijk naam/adres en prijs/pizzaid bijv.)

3. Moet het type van een dergelijke 'calculate' methode void zijn of echt het type van de waarde die het oplevert?

4. Pizza toch maar een id gegeven. Iedere pizza die wordt gemaakt krijgt een unieke code, zodat hij te onderscheiden is van een identieke pizza (qua ingredienten) die bij een andere order hoort. Zit te bedenken dat het type hiervan beter ook string kan zijn ivm een ordernr 000xxxxxx. Is dit logisch?

5. Maakt het uit dat hier "void" staat om moet er een resultaattype komen? Er staat op vrij veel plaatsen 'void' namelijk.

6. getIngredient een zinvolle methode of alleen de attributen ophalen die je echt nodig hebt? Zoals naam en quantity?

7. Methode checkQuantity zinnig? Is een methode die in gaten moet houden of de quantity van een bepaald ingredient niet een ingesteld minimum nadert. En moet dit minimum dan ergens in een apart attribuut in Ingredient gespecificeerd zijn?

8. Is een dependency hier op zijn plaats? Het idee is dat de klasse "Turnover" de omzet in de gaten houdt. Iedere keer dat er geld binnenkomt bij een order of wordt uitgegeven door stock aan te vullen moet deze klasse de income respectievelijk expenses opnieuw bereken waaruit de totale omzet berekend kan worden. Maar misschien moet dit wel een associatie zijn (al zou ik niet weten wat voor dan). Iemand ideeen?

Nogmaals bedankt voor alle tips/adviezen!

[NMe]

Over die void returns: daar heb je niets aan bij getters. Get-functies die returnen iets, daar maak je ze juist voor... GetPizza zou dus een object van het type Pizza moeten returnen.
Verder: je hebt wel getters, maar geen setters. Hoe stel je nou voor een pizza in welke ingrediënten hij heeft?
Verder geldt: waarden waarvan je weet dat je ze niet nodig gaat hebben, daar hoef je ook geen get-functie voor te hebben.

[martijnvds]

-NMe- schreef op maandag 28 maart 2005 @ 15:17:
Over die void returns: daar heb je niets aan bij getters. Get-functies die returnen iets, daar maak je ze juist voor... GetPizza zou dus een object van het type Pizza moeten returnen..

Duidelijk

Verder: je hebt wel getters, maar geen setters. Hoe stel je nou voor een pizza in welke ingrediënten hij heeft?

Een attribuut ingredientlist van het type array (geen int dus, staat verkeerd). een methode setIngredient die een Ingredrient in deze array 'duwt'. Of kan dat niet?

Verder geldt: waarden waarvan je weet dat je ze niet nodig gaat hebben, daar hoef je ook geen get-functie voor te hebben

Dus beter getAttribute dan getClass in dat geval?

[Zoijar]

Je moet juist geen lijst/array attribute opnemen! Dat is al verwerkt in je aggregation pijl; het implementatie attribuut vermeld je niet expliciet meer daarna.

Dingen als turnover, en total price, sla je niet op als attribuut. Daar heb je alleen de methode voor die het berekent. Of je kan het weergeven als derived attribute. Maar in principe alleen de methode. Een order heeft namelijk geen totaal bedrag, een order kan een totaal bedrag bij afgeleid worden aan de hand van het aantal en soort pizzas. (tenzij je aan prijs veranderingen doet, dan zou het wel weer kunnen. Maar zet dat er dan bij als commentaar)

Verder moet je even goed uitkijken met die aggregatie pijl bij ingredienten. Als een pizza het laatste plakje salami gebruikt, en daarna geleverd en gewist wordt, betekent dat dan dat er geen salami meer bestaat? Zoals het er nu staat wel in principe. Maar je wilt appart ingredienten hebben, en een apparte vooraad. Als je je laatste salami verkoopt, bestaat het ingredient nog wel steeds. Pizza heeft dus geen ownership over ingredienten, maar over ingredienten op vooraad.

[ Voor 80% gewijzigd door Zoijar op 28-03-2005 16:03 ]

[martijnvds]

Arrays weglaten dus. Misschien handig om de relatie tussen Order en Pizza ook een aggregation te laten zijn? Dan kan de zowel de array bij Order als bij Pizza weg.

Wat betreft turnover en totalprice attributen kan ik je volgen, dat ga ik aanpassen, tnx

Over dat ingredienten op voorraad: Ik snap wat je bedoelt, maar hoe kan ik dit modelleren? Idd ingredient moet idd niet verdwijnen. Misschien een andere relatie modelleren qua "Stock"? Iemand voorstel?

[NMe]

Pizza laten relateren aan Stock, en Stock weer op Ingrediënt, denk ik. Op die manier staat Ingrediënt redelijk los, en is die alleen gerelateerd aan Stock.

[Ansur]

Ivm getters en setters, deze worden normaal gezien NIET opgenomen in een klassediagram, deze worden verondersteld er te zijn. Hetzelfde geldt voor een constructor.

[martijnvds]

Oké ik zie een beetje door de bomen het bos niet meer, maar is dit wat?

[Verwijderd]

Customer plaatst Order(s), Een Order bestaat uit Pizza(s), Een Pizza bevat Ingredient(en).
Bij het implementeren gebruik je geen lijsten of arrays, maar Collections!
De klasse Stock lijkt overbodig, omdat je per Ingredient de aanwezige hoeveelheid bijhoudt. Indien de hoeveelheid te laag wordt kan je een signaal geven.
Bereken wel het bedrag per order voor de klant, zodat hij niet verrast wordt door prijsveranderingen. Hier kan je ook een eventuele korting aangeven.
Een statusaanduiding kan handig zijn, bijvoorbeeld 'order geplaatst', 'in behandeling', 'uitgeleverd', 'betaald'. Dit kan de zaak complexer maken, omdat je een klasse Status en per status een subklasse kan definieren met specifieke methoden.
Probeer get- en set-Methoden m.b.t. andere klassen beter te vermijden, dit werkt verwarrend. Gebruik bijvoorbeeld liever addIngredient, showIngredient, removeIngredient bij de klasse Pizza. Hoewel dit ook triviale methoden zijn m.b.t. het manipuleren van een Collection.

[ Voor 23% gewijzigd door Verwijderd op 29-03-2005 11:42 ]

[Verwijderd]

En toch vind ik niet dat een pizzaID in een klassediagram hoort
Je onderscheidt de pizza toch al, want iedere pizza is een apart object. Dat object heeft weer relaties met de ingredient-objecten. Daar hoef je het dus ook niet voor te doen.
Net als tjiba zijn de methodes get en set ingredient niet duidelijk, want die zijn eerder bedoeld om de objecten ingredient aan te roepen en te wijzigen, niet om die te maken en aan de pizza te binden.
Maar heb je niet een docent waar je het aan kan vragen?