Die Entwurfsphase
  In der Entwurfsphase werden die Klassenkandidaten aus der Analysephase an das Framework angepaßt. Es wird untersucht, welche der erstellten Klassen von welchen Klassen des Frameworks erben können. Das Framwork soll nur an den Stellen des Programms genutzt werden, an denen es sinnvoll ist. Wichtige Anpassungen sind z.B. die Festlegung konkreter Bestands- und Katalogklassen. Das Ergebnis ist ein verändertes Klassendiagramm. Ein weiterer wichtiger Bestandteil dieser Phase ist das Umsetzen der Use-Case-Diagramme in Prozesse - Zustandsübergangsdiagramme werden erstellt. Es beginnt das Prototyping mit dem Entwurf der Oberfläche. Schon in dieser Phase wird die Arbeit am Benutzerhandbuch des Programms begonnen.  
  Da das Framework und Java in englischer Sprache verwendet werden, werden auch die Entwurfsdokumente in Englisch abgefaßt.  
 Anpassung an das Framework
 
Das Klassendiagramm der Entwurfsphase
Abbildung 3.1: Das Klassendiagramm der Entwurfsphase
 
  In Abbildung 3.1 werden die Klassen des Frameworks, von denen geerbt wird, nur mit Namen oben rechts in den jeweiligen Klassen benannt. Die Darstellung ist typisch für Together und soll Lesbarkeit des Klassendiagramms erhöhen.  
  Der Sonderwunsch entfällt, da in der Speise mittels eines Boolean vermerkt werden kann, ob es sich um einen solchen handelt. Der Tagesabschluß wird durch einen Prozeß geregelt und wird als Klasse nicht benötigt. Die Stornierung und die Rechnung werden ebenfalls durch Prozesse realisiert. Vom Kunden wird nur seine ID benötigt, als Nutzer des zu entwickelnden Programms ist er nicht relevant. Er wird als Unterklasse von CatalogItemsp apilogo implementiert und stellt einen Eintrag in der Bestellung (Order) dar. Um die Zusammenstellung der Speisen (Food) zu erleichtern wurde eine weitere Klasse ComplexIngredient eingeführt. Sie setzt sich aus einfachen Zutaten (Ingredient) zusammen (Bsp: Kartoffelpüree: Kartoffeln, Salz, Milch, Butter).  
 Festlegung konkreter Bestands- und Katalogklassen
  Um die Speisen, die das Restaurant anbietet und deren Zutaten verwalten zu können, werden die vom Framework angebotenen Catalogssp apilogo und Stockssp apilogo benutzt.  
  Da die Unterklassen von CatalogItemsp apilogo und StockItemsp apilogo als Klassen implementiert, die Unterklassen von Catalogsp apilogo, CountingStocksp apilogo und StoringStocksp apilogo jedoch nur im Restaurant instanziiert werden, können die Zusammenhänge der Kataloge und Bestände nur in einem Objektdiagramm verdeutlicht werden. Da Together in einem Objektdiagramm verständlicherweise keine Vererbungsbeziehungen zulässt, wurden diese als ergänzende Kommentare eingefügt. Die folgende Abbildung zeigt die Komposition dieser Objekte:  
 
Objektdiagramm: Catalogs und Stocks
Abbildung 4.1: Objektdiagramm: Catalogs und Stocks
 
  Bestandteil jeder Speise (Food) sind Zutaten (Ingedient), die sich durch bestimmte Eigenschaften auszeichnen. Für sie wird ein Catalogsp apilogo verwendet. Ein Eintrag darin repräsentiert eine Zutat. Als keysp apilogo wird der Name abgespeichert. Der valuesp apilogo ist ein quoteValuesp apilogo, der die minAnzahl und maxAnzahl, den Einkaufs- und Verkaufspreis abspeichert.  
  Von jeder Zutat ist eine bestimmte Anzahl im Lager (Store). Ein CountingStocksp apilogo speichert als Wert nur eine Anzahl ab. Da aber die Zutaten noch ein Verfallsdatum besitzen, wird ein StoringStocksp apilogo für das Lager genutzt.  
  Ist die minAnzahl von Zutaten unterschritten, werden sie beim Tagesabschluß in den Bestellvorschlag (RepeatOrderWishList) aufgenommen.  
  Die Nachbestellungsliste (RepeatOrder) enthält alle tatsächlich bestellten und noch nicht gelieferten Zutaten. Für beide Listen wird ein CountingStocksp apilogo verwendet, der den Namen und die Anzahl der Zutaten abspeichert.  
  Die Speisen setzen sich aus ihren Zutaten zusammen. In einem Catalogsp apilogo werden sie verwaltet. Der keysp apilogo wird der Name. Als valuesp apilogo wird wieder ein quoteValue genutzt. Er enthält einen Counting Stocksp apilogo mit den Zutaten und ihrer Anzahl, sowie einen Preis.  
  Kunden bestellen Speisen und Getränke. Im Catalogsp apilogo Order werden zu den Kunden-ID's die jeweiligen Bestellungen vermerkt. Das dazugehörige CatalogItemsp apilogo Customer enthält als keysp apilogo die ID und als valuesp apilogo einen CountingStock mit den Bestellungen.  
  Das Klassendiagramm in Abbildung 4.1 zeigt die Zusammenhänge noch einmal graphisch.  
 Die Prozesse
  Wie schon im technischen Überblick erwähnt, finden alle Interaktionen mit dem Laden im Rahmen von Prozessen (SaleProcesssp apilogo) statt. In den Use-Case-Diagrammen der Analysephase wurde festgelegt, welche Personen auf welche Teile des Programms zugreifen. Die Abfolge der einzelnen Aktionen wird durch Prozesse, die in Form von Zustandsübergangsdiagrammen dargestellt werden, bestimmt.  
  In Abbildung 5.1 werden die Zusammenhänge zwischen den SalesPointssp apilogo, den Prozessen und den Nutzern dargestellt.
Die Prozesse im Überblick
Abbildung 5.1: Die Prozesse im Überblick
 
  Den Ablauf einer Kundenbestellung zeigt Abbildung 5.2. Alle Kunden werden im Programm mittels Kunden- und Tischnummer am identificationGate() identifiziert. Tätigt der Kunde seine erste Bestellung, muß er in die Kundenkartei (im newCustomerGate()) aufgenommen werden. Im getOrderGate() erfolgt die Eingabe der Bestellung durch den zuständigen Kellner. Es können Sonderwünsche erstellt werden. Dann ist diese Aktion beendet und das Essen kann zubereitet werden. Innerhalb aller Gatessp apilogo kann der Prozeß abgebrochen werden.
Bestellungsprozeß
Abbildung 5.2: Bestellungsprozeß
 
  Überlegt es sich ein Kunde anders bzw. schmeckt ihm das servierte Essen nicht, hat er die Möglichkeit zur Stornierung (Abbildung 5.3). Auch hier muß der Kellner den Kunden mittels einer Nummer identifizieren. Im getOrderGate() werden alle Bestellungen des Kunden angezeigt, die dann einzeln gelöscht werden können. Es ist zu beachten, daß ein bereits gekochtes Essen als Verlust in die Statistik eingehen sollte, während bei einem noch nicht zubereiteten Gericht die Zutaten lediglich ins Lager zurückgeräumt werden.
Stornierung von Bestellungen
Abbildung 5.3: Stornierung von Bestellungen
 
  Will ein Kunde das Restaurant verlassen, muß er seine Rechnung bezahlen. In Abbildung 5.4 wird dieser Vorgang dargestellt. Die Identifikation des Kunden ist hier ebenfalls unerlässlich. Zusätzlich muß sich auch der Kellner anmelden, damit bei Abrechnung am Ende einer Schicht klar ist, welcher Kellner welche Beträge abrechnen muß. Im getBillGate() wird der Rechnungsbetrag angezeigt. Im Gegensatz zum Videoautomaten im Einführenden Beispiel wird die Rückgabe von Wechselgeld nicht mit einbezogen, da dieser Vorgang direkt vom Kellner erledigt wird. Die vorliegende Lösung bietet aber die Möglichkeit mehrere Kunden abzukassieren, ohne sich erneut anmelden zu müssen. Der Kunde kann nach dem Bezahlen das Restaurant verlassen.
Rechnung erstellen
Abbildung 5.4: Rechnung erstellen
 
  Am Ende eines Tages wird das Lager auf benötigte Zutaten getestet. Dazu muß sich der Manager mit seinem Passwort anmelden. Er erhält eine Liste mit Zutaten, deren Mindestbestände unterschritten sind. Es besteht die Möglichkeit seitens des Managers die Liste zu verändern. Bestätigt er die Liste, werden die Waren bei den entsprechenden Zulieferern bestellt. Das Eintreffen der bestellten Waren erfolgt analog zu Abbildung 5.5 .
Die Nachbestellung
Abbildung 5.5: Die Nachbestellung
 
  Die Nutzerverwaltung (siehe Abbildung 5.6 )ist eine wichtige Aufgabe des Managers. Nach seiner Identifikation wird im selectionGate entschieden, ob ein neuer Mitarbeiter eingestellt werden soll, oder die Daten eines bereits vorhandenen Angestellten, z.B. seine Rechte, angepaßt werden müssen. Bei letzterem wird im getUserGate() der Mitarbeiter ausgewählt. Im editUserGate() werden seine Daten angezeigt. Wird ein neuer Mitarbeiter eingestellt sind die Eingabefelder leer. Nach korrekter Eingabe werden die (veränderten) Daten abgespeichert.
Die Nutzerverwaltung
Abbildung 5.6: Die Nutzerverwaltung
 
  Sollen die Eigenschaften der Zutaten im Lager verändert werden, wird der in Abbildung 5.7 dargestellte Prozeß genutzt. Im getStoreGate() wird der Lagerbestand angezeigt und kann editiert werden. Die anderen Gatessp apilogo dürften mittlerweile bekannt sein.
Die Lagerverwaltung
Abbildung 5.7: Die Lagerverwaltung
 
  Die Anzeige der Statistiken funktioniert analog zur Lagerverwaltung. Im getStatiticGate wird die ausgewählte Statistik angezeigt. Die Abbildung 5.8 verdeutlicht den Vorgang.
Die Statistiken
Abbildung 5.8: Die Statistiken
 
  Da die noch fehlenden Prozesse für das Essen kochen, Anmelden und Abmelden eines Kellners, sowie für den Tagesabschluß analog zu den bereits bestehenden Prozessen StoreAdministration (Abbildung 5.7) und Statistics (Abbildung 5.8) aufgebaut sind, wird an dieser Stelle auf eine bildliche Darstellung verzichtet.  
 Entwurf der Oberfläche
  Um in der Implementation zügig voranschreiten zu können, wird schon in dieser Phase die Oberfläche entworfen. Für das Aufgeben einer Bestellung des Kundens an den Kellner wurde die in Abbildung 6.1 dargestellte Menüstruktur festgelegt. Die anderen Oberflächenelemente werden analog aufgebaut  
 
Eine Bestellung aufnehmen
Abbildung 6.1: Eine Bestellung aufnehmen
 
 
vorherige Seite  Analyse Implementation und Test  naechste Seite
 

by kk15

Valid HTML 4.01!