Tabesh <DEV>

[COG][SWD] BOP 1.2: Sushirestaurant

Casus 1: Use-Case Diagram

Uit de opdracht:

In het sushirestaurant werken de volgende medewerkers:

  • Receptioniste / kassière
  • Ober
  • Kok

De medewerkers:

  • Nemen bestellingen op
  • Maken de sushi
  • Serveren het eten en/of drinken
  • Rekenen het eten af

Klanten komen in het restaurant eten. Zij doen het volgende:

  • Sushi bestellen
  • Sushi opeten
  • Eventueel drinken, bestellen en opdrinken
  • Betalen voor het eten/drinken

Maak het use-case-diagram bij casus 1.

We modeleren altijd in het Engels, tenzij wij een afweging hebben gemaakt en het ontwerp bewust in het Nederlands willen hebben.

Zoals gebruikelijk kunnen meerdere antwoorden juist zijn. Hierbij een mogelijke uitwerking:

Te begrijpen:

  1. Een kok kan sushi bereiden.
  2. Een ober kan serveren.
  3. Een klant kan bestellen, dit moet “bij” een ober.
    • Andersom: een ober kan een bestelling opnemen, dit moet “voor” een klant.
  4. Een klant kan consumeren (eten/drinken).
    • Let op: Kan een klant zijn eigen eten nuttigen? Kan een klant eten/drinken zonder te gaan betalen? Ja—maar die zaken modeleren wij niet in een Use-Case Diagram.
  5. Een klant kan een betaling doen, dit moet “bij” een kassamedewerker.
    • Andersom: een kassamedewerker kan een betaling aannemen, dit moet “vanuit” een klant.

Elke requirement is nu voldaan.

Medewerkers:

  • Medewerkers nemen bestellingen op
    • Er is niet gespecificeerd welke medewerkers. Hier is bewust gekozen om slechts de ober te modeleren als degene die bestellingen opneemt.
  • Medewerkers maken de sushi
    • Hier: de kok
  • Medewerkers serveren het eten en/of drinken
    • Hier: de ober
    • Gemodelleerd voor algemeniteit: serveren kan eten/drinken betreffen, maar zelfs iets als bestek of een servet.
  • Medewerkers rekenen het eten af
    • Hier: de kassamedewerker
    • Gekozen is voor een notitie toe te voegen, maar het kon ook weggelaten worden.
    • Gemodelleerd voor algemeniteit: betaling kan alles betreffen wat betaald dient te worden.

Klanten:

  • Klanten kunnen sushi bestellen
    • Gemodelleerd voor algemeniteit: bestellen
  • Klanten kunnen sushi opeten
    • Gemodelleerd voor algemeniteit: consumeren
  • Klanten kunnen eventueel drinken, bestellen en opdrinken
    • Gemodelleerd voor algemeniteit: bestellen en consumeren
    • Let op: Use-cases zijn per definitie “eventueel”, tenzij er sprake is van een minimale multipliciteit (bijv. 1..*), of als er sprake is van <<include>> tussen twee use-cases.
  • Klanten kunnen betalen voor het eten/drinken
    • Gemodelleerd voor algemeniteit: betaling

Mogelijk zou je <<include>> toe kunnen voegen om consumeren alleen mogelijk te maken mits er sprake is van een bestelling:

Echter zou dit betekenen dat:

  1. Een klant kan consumeren, maar daarvoor moet hij voor elke consumptie(!) een bestelling doen.
  2. Een klant kan bestellen.

Dit is niet per se onjuist, maar in de praktijk is het vaak zo dat een klant meerdere consumpties kan doen op basis van één bestelling. Daarom is in het eerste diagram gekozen om <<include>> niet toe te passen.

In UML wordt de <<include>> relatie gebruikt om aan te geven dat het gedrag van de ene use-case altijd moet worden uitgevoerd als onderdeel van een andere use-case. Het betekent dat de included use-case altijd verplicht moet worden uitgevoerd als de base use-case wordt uitgevoerd.

Casus 2: Klassendiagram

Uit de opdracht:

  • Klanten kunnen alleen op afspraak komen eten in het sushirestaurant.
  • Reserveren is alleen mogelijk op de hele uren. Daarvoor kunnen zij bellen met het restaurant en hun naam en telefoonnummer opgeven. Ze maken een afspraak voor een bepaalde dag en tijdstip.
  • Klanten kunnen ook reserveren via de website. Ook daar vullen zij hun naam en telefoonnummer in en reserveren zij voor een bepaalde dag en tijdstip.
  • Voor elke dag en elk tijdstip heeft het restaurant een maximaal aantal tafels beschikbaar.
  • Het restaurant is verdeeld in 3 zalen.
  • De obers werken altijd met 2 obers in een zaal.
  • Er staan altijd 6 koks in de keuken.
  • 1 receptionist/kassière neemt de telefoon op, ontvangt de klanten en rekent met hen af.
  • Het restaurant houdt NAW-gegevens van de werknemers bij.
  • Het restaurant is van 18:00 tot 23:00 uur open, 7 dagen in de week.

Maak het klassendiagram bij casus 2.

Een mogelijke uitwerking:

Een UML CD (Class Diagram) kan op verschillende nivo’s van abstractie worden gemodelleerd, elk met een ander doel binnen het softwareontwikkelingsproces.

Het conceptueel model—dit past goed in de analysefase van Waterval. Hierbij modelleren wij concepten uit de praktijk, zonder al te veel in te gaan op functionele details zoals relaties en multipliciteit, datatypes en operaties (functies/methodes).

Het logische model—voor het Functioneel Ontwerp zouden we dit model verder kunnen uitwerken tot een logisch model door multipliciteit toe te voegen (bijv. 1..*, 0..1, etc.), operaties toe te voegen die de functionaliteit van het systeem representeren, en eventueel generieke datatypes toe te voegen (denk: Number i.p.v. programmeertaal-specifieke integer, float, u_int32, etc.)

Het fysieke model—voor het Technisch Ontwerp zouden we dit model nog verder kunnen uitwerken tot een “fysiek model” door tot in detail alles uit te werken. Denk aan visiblility (zichbaarheid: public, protected, private), attributen, operaties, datatypes, return types, enzovoort.

Voor deze opdracht is gekozen om een conceptueel model te maken, omdat de opdracht zich richt op het begrijpen van de domeinconcepten en hun relaties binnen het sushirestaurant. Wel hebben wij multipliciteit toegevoegd waar wij het een toegevoegde waarde achtten, omdat multipliciteit nadrukkelijk werd beschreven vanuit de requirements (bijv. “2 obers per zaal”, “6 koks in de keuken”, etc.).

Qua relaties zijn wij puur omwille van lering/naslagwerk niet alleen gegaan voor eenvoudige associaties, maar hebben wij ook aggregaties, composities, en inheritance (overerfing) toegepast waar dat passend leek. Dit is eigenlijk meer weggelegd voor een logisch model (dus ook voor een fysiek model).

Zoals altijd geldt voor modeleren:

Ken jouw doelgroep.

Voor een niet-technisch onderlegde klant is dit net even te functioneel. Het is dan ook niet helemaal een conceptueel model maar eerder een halfbakken logisch model—net wat technischer.

Casus 3: Activiteitendiagram

Uit de opdracht:

  • Een klant maakt een reservering bij het sushirestaurant.
  • De klant komt op de afgesproken tijd bij het restaurant.
  • De klant wordt ontvangen door de receptioniste.
  • De ober brengt de klant naar zijn tafel.
  • De ober neemt de bestellingen op, bedient de klant.
  • De kok bereidt de maaltijd voor de klant.
  • Na de maaltijd rekent de klant af bij de receptioniste.

Punten om mee te nemen in het activiteitendiagram:

  • Is er een plek vrij op de gewenste dag en tijdstip voor de klant?
  • Is alle sushi op voorraad?
  • Hoe betaalt de klant?

Maak een activiteitendiagram bij casus 3.

Een mogelijke uitwerking:

NOTEER: Het is nog niet volledig. Wat zijn wij vergeten?