• Aufgabenstellung
• Analyse
• Entwurf
• Die Entwurfsphase
• Anpassung an das Framework
• Festlegung konkreter Bestands- und Katalogklassen
• Die Prozesse
• Entwurf der Oberfläche
• Implementation und Test
• Wartung und Pflege
• Zusammenfassung und Quellen

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.

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.

Darstellungsform

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 CatalogItem 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).

Entwurfsentscheidungen

Um die Speisen, die das Restaurant anbietet und deren Zutaten verwalten zu können, werden die vom Framework angebotenen Catalogs und Stocks benutzt.

Da die Unterklassen von CatalogItem und StockItem als Klassen implementiert, die Unterklassen von Catalog, CountingStock und StoringStock 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

Bestandteil jeder Speise (Food) sind Zutaten (Ingedient), die sich durch bestimmte Eigenschaften auszeichnen. Für sie wird ein Catalog verwendet. Ein Eintrag darin repräsentiert eine Zutat. Als key wird der Name abgespeichert. Der value ist ein quoteValue, der die minAnzahl und maxAnzahl, den Einkaufs- und Verkaufspreis abspeichert.

Zutaten

Von jeder Zutat ist eine bestimmte Anzahl im Lager (Store). Ein CountingStock speichert als Wert nur eine Anzahl ab. Da aber die Zutaten noch ein Verfallsdatum besitzen, wird ein StoringStock für das Lager genutzt.

Lager

Ist die minAnzahl von Zutaten unterschritten, werden sie beim Tagesabschluß in den Bestellvorschlag (RepeatOrderWishList) aufgenommen.

Wunschliste

Die Nachbestellungsliste (RepeatOrder) enthält alle tatsächlich bestellten und noch nicht gelieferten Zutaten. Für beide Listen wird ein CountingStock verwendet, der den Namen und die Anzahl der Zutaten abspeichert.

Nachbestellungsliste

Die Speisen setzen sich aus ihren Zutaten zusammen. In einem Catalog werden sie verwaltet. Der key wird der Name. Als value wird wieder ein quoteValue genutzt. Er enthält einen Counting Stock mit den Zutaten und ihrer Anzahl, sowie einen Preis.

Speisen

Kunden bestellen Speisen und Getränke. Im Catalog Order werden zu den Kunden-ID's die jeweiligen Bestellungen vermerkt. Das dazugehörige CatalogItem Customer enthält als key die ID und als value einen CountingStock mit den Bestellungen.

Bestellungen

Das Klassendiagramm in Abbildung 4.1 zeigt die Zusammenhänge noch einmal graphisch.

Wie schon im technischen Überblick erwähnt, finden alle Interaktionen mit dem Laden im Rahmen von Prozessen (SaleProcess) 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.

Einordnung

In Abbildung 5.1 werden die Zusammenhänge zwischen den SalesPoints, den Prozessen und den Nutzern dargestellt.

Abbildung 5.1: Die Prozesse im Überblick

Übersicht

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 Gates kann der Prozeß abgebrochen werden.

Abbildung 5.2: Bestellungsprozeß

ReceiveOrder

Ü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.

Abbildung 5.3: Stornierung von Bestellungen

CancelOrder

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.

Abbildung 5.4: Rechnung erstellen

GetBills

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 .

Abbildung 5.5: Die Nachbestellung

RepeatOrderAdministration / GetRepeatOrder

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.

Abbildung 5.6: Die Nutzerverwaltung

UserAdministration

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 Gates dürften mittlerweile bekannt sein.

Abbildung 5.7: Die Lagerverwaltung

StoreAdministration

Die Anzeige der Statistiken funktioniert analog zur Lagerverwaltung. Im getStatiticGate wird die ausgewählte Statistik angezeigt. Die Abbildung 5.8 verdeutlicht den Vorgang.

Abbildung 5.8: Die Statistiken

Statistics

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.

Restliche Prozesse

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

Bestellung aufnehmen

Analyse

Implementation und Test