Aufgabe Rezepturverarbeitung (Caipirinha)  			05.10.05

Entwickeln sie ein System zum automatisierten Zubereiten von Cocktails. Aufgabe ist es ein Rezept einzugeben und anschließend die in den Rezept-Schritten angegebenen Zutaten z.B. Pitu, Zucker, Eis und ein Limettenstück in der richtigen Menge und Reihenfolge in einen Behälter zu füllen, gemäß Vorgabe im Rezept für eine definierte Zeit zu stampfen, zu rühren und anschließend zu entleeren. Der schematische Aufbau der technischen Anlage ist in der folgenden Abbildung dargestellt: 

Für jede Zutat soll eine Dosierstation vorhanden sein. Eine Dosierstationen besitzt jeweils ein Ventil das geöffnet und geschlossen werden kann. Der Limettenstückdosierer dosiert jeweils ein Stück pro Auftrag.
•	Die Zutaten werden z. B. über Rohre in einen Mischbehälter gefüllt.
•	Das System besitzt eine Stampf- und eine Rühreinrichtung die für eine Zeitdauer aktiv sein können. 
•	Der Mischbehälter besitzt ein Entleerventil, mit dem der Cocktail entleert werden kann.
•	Der Mischbehälter steht auf einer Waage, mit der der Inhalt gewogen wird. 

	Die Dosierstation
•	Eine Dosierstation besitzt jeweils ein Ventil das geöffnet und geschlossen werden kann. Die Menge der bereits dosierten Zutat muss über eine Waage kontrolliert werden. 
•	Der Stückdosierer funktioniert genauso wie die „normalen“ Dosierer.
•	Die Dosierstation sorgt selbst für die notwendige Lagerung der Zutat (z.B. Kühlung)
	Der Rezepturprozessor
•	Die Verarbeitungsschritte sind in einem Rezept (s.u.) festgelegt.
•	Der Rezepturprozessor bearbeitet nach der Auswahl des Rezepts durch den Benutzer die Schritte des Rezepts und gibt den einzelnen Stationen (Dosierstationen, Stampfer, Mischer, Entleerer) die notwendigen Kommandos.
•	Die Stationen melden nach erfolgter Ausführung eines Kommandos ein positives Ergebnis zurück. Der Rezepturprozessor führt dann den nächsten Schritt aus.
Das Rezept
•	Das Rezept ist eine geordnete Sammlung von Rezeptschritten, die vom Rezepturprozessor interpretiert werden.
	Die Rezeptschritte
•	Die Rezeptschritte sind die einzelnen Anweisungen an den Rezepturprozessor. 
•	Jeder Rezeptschritt enthält die Information welche Station (Assoziation zu Station) den Schritt ausführen soll und den Parameter, den er dazu benötigt (Menge / Anzahl / Zeitdauer).
[Das Kochbuch (Rezeptfactory) 
wird hier nicht realisiert. Wir nehmen an, es existiere nur ein Rezept. – Bei einem System, das für den operativen Einsatz geeignet wäre, müssten die Daten einiger Klassen persistent, d. h. in einer Datenbank gespeichert werden. Überlegen Sie sich: Welche Klassen würde das betreffen?]
	Die Waage
•	Die Waage hat 2 Gewichte. Das absolut gewogene Gewicht und ein Differenzgewicht „Tara“, das relativ zu einem frei setzbaren Nullpunkt ist.
•	Die Waage ist so geeicht, dass das Absolutgewicht mit dem leeren Mischbehälter 0 ist. 
•	Der „Tara-Nullpunkt“ kann durch einen Aufruf auf das aktuelle Absolutgewicht gesetzt werden.
•	Auf einem Display wird der aktuelle Netto-Gewichtswert (= Absolutgewicht – Tara) angezeigt.
•	Das Taragewicht kann auf 0 gesetzt werden.
	Der Mischer
•	Der Mischer mischt für eine definierte Zeitdauer. 
	Der Stampfer
•	Der Stampfer stampft für eine definierte Zeitdauer 
Der Entleerer des Mischbehälters
•	Der Entleerer besitzt ein Ventil das geöffnet und geschlossen werden kann. Die Restmenge im Mischbehälter muss über eine Waage kontrolliert werden. 
	Das Display
•	Das Display gibt für die aktivierte Waage die Gewichtswerte formatiert auf COUT aus (z. B. „Displayausgabe: Gewicht 8 Gramm“).

	Szenario
	Dosiervorgang (Ablauf)
1.	Nachdem der Benutzer das Herstellen des Cocktails angestoßen hat, werden entsprechend der Rezeptvorgaben Kommandos an die entsprechenden Dosierer geschickt
2.	Das Ventil des Dosierers X wird geöffnet
3.	Wenn die Waage das gewünschte Nettogewicht erreicht oder überschreitet,  wird das Ventil des Dosierers X geschlossen.
4.	Analog zu Schritt 2. und 3. werden die anderen Zutaten dosiert
5.	Der Mixer und/oder Stampfer wird für eine bestimmte Zeit aktiviert
6.	Der Cocktail wird entleert

Aufgabenstellung

In der Beschreibung der zu realisierenden Anlage hat der Kunde aus seiner Sicht und mit seinen Beschreibungsmitteln (rein verbale Beschreibung) die Funktionsweise der Anlage beschrieben.

Wir wollen nun diese Beschreibung umsetzen in eine mit UML beschriebene Spezifikation / Entwurf. Um die Aufgabe im Rahmen des Praktikums lösbar zu machen, gelten folgende Vereinfachungen.
	Vereinfachende Annahmen, Vorgaben:
•	Ausgaben auf externe physische Geräte sollen über Bildschirmausgaben simuliert werden, Nachrichten von externen Geräten sollen in den Klassen durch einen Funktionsaufruf, in denen im richtigen System später die Abfrage der Werte stattfinden könnte, simuliert werden. Z. B. bei der Waage wird von der Klasseninstanz dieWaage die Gewichtswerte in der eigenen Funktion gibZustand jeweils um 4 Gramm erhöht bzw um 20 Gramm verringert.
•	Das Abwarten der Zeit wird durch ein Wait-Statement simuliert.
•	Aktionen von Geräten werden durch Bildschirmausgaben simuliert.
•	Das Display wird durch cout simuliert
•	Das Schließen und Öffnen eines Ventils wird durch die Bidschirmausgabe „Ventil XX: geöffnet /geschlossen“ simuliert.
•	Solange ein Füllventil eines Dosierers geöffnet ist, soll die Waage ihr Gewicht nach jeder Sekunde um 4 Gramm erhöhen. Die Waage biete dazu eine entsprechende Methode, die beim Öffnen und Schließen eines Ventils aufgerufen wird. 
•	Wird ein Limettenstück dosiert, erhöht sich das Gewicht ebenfalls um 4 g/s
•	Ist das Entleerventil geöffnet so verringere sich das Gewicht der Waage um 20g/s bis der Wert Null erreicht ist.
•	Die Waage muss durch eine Funktion aktiviert und deaktiviert werden. Dies ist nötig, um die Waage nicht als extra Thread laufen lassen zu müssen. Im aktivierten Zustand erfolgt die Verarbeitung, d.h. nach der Wartezeit von 1 Sekunde (wait-Statement) wird das neue Gewicht durch Addition von 4 Gramm berechnet (beim Entleeren durch Subtraktion von 20 g).
•	Ausnahmen werden hier nicht realisiert (Dosierer hängt, ist leer etc.)
•	Rezepteingabe muss möglich sein, aber um wiederholte Eingabe zu vermeiden kann auf ein im Programm gespeichertes Standardrezept zurückgegriffen werden.
•	Wir konstruieren die Kommunikation zwischen Waage und Dosierer, Entleerer und Display nach dem Beobachter-Muster. Die Waage (Subjekt) besitzt eine verbinde- und eine loese-Funktion, mit der sich sowohl der Dosierer als auch das Display als Beobachter bei ihr an- und abmelden können…..(Simulation der Nachricht von der physischen Waage). Anschließend wird das Nettogewicht errechnet. Danach wird die Funktion aktualisieren() des Dosierers aufgerufen, der gemäß Beobachtermuster sich den Zustand (Nettogewicht) holt (Funktion gibZustand()).

Aufgaben

- 1. Termin: Anforderungsermittlung, Analyse

1. Anwendungsfälle (Use-Cases) 

Erstellen Sie das Use-Case-Diagramm und beschreiben Sie die einzelnen Use-Cases gemäß der in der Vorlesung vorgestellten Methode von Cockburn.

2. Domainklassenmodell (Analyse-Klassen-Diagramm)

Erstellen Sie das Klassenmodell der Domainklassen (Domainklassen: Klassen zu materiellen und immateriellen Dingen, enthalten Informationen (Attribute)

3. Erstellen Testfälle

Erstellen Sie Testfälle für den Abnahmetest auf Grund der Use-Case-Definition. Geben Sie die Eingabedaten (hier: Benutzereingaben) und die erwarteten Ergebnisse der Testdurchläufe (des Testdurchlaufes) an.

4. Review (Anforderungs-Review)

Setzen Sie sich mit einer anderen Gruppe, die auch schon Punkt 1. und 2. abgeschlossen hat, zusammen und führen Sie einen Review durch (evtl. gegenseitig). Prüfen Sie, ob die Use-Case-Spezifikation und das Domainklassenmodell den in der Aufgabenstellung aufgeführten Angaben entspricht.

- 2. Termin: Entwurf

5. Klassendiagramm (Design-Klassendiagramm)
Generieren Sie aus dem Analyse-Klassenmodell die erste Version des Design-Klassenmodells. Führen Sie die Weiterentwicklung des Domainklassenmodells durch. Definieren Sie alle Klassen, die (zusätzlichen) Attribute der Klassen,  Assoziation und Aggregationen/Kompositionen. (Benennen Sie die Klassen mit einen vorangestellten C.) Unterscheiden Sie Schnittstellen-(Boundery-)Klassen (auch Anwendungsfall-Klassen als Schnittstellenklassen), Kontroll-(Controller-)Klassen und Entitäts-(Entity-)klassen. Wählen Sie immer aussagekräftige Namen. Kennzeichnen Sie Membervariablen mit einem vorangestellten m, Funktionsparameter mit einem vorangestellten f und Pointervariablen mit einem vorangestellten p. Definieren Sie die zur Anwendung des Observer-(Beobachter-)Musters notwendigen Klassen und Beziehungen. 

6. Sequenzdiagramm
	Erstellen Sie parallel zur Erstellung der Klassendiagramme die Sequenzdiagramme zu den einzelnen Anwendungsfällen unter Berücksichtigung des Observer-Musters. Benennen Sie die Objekte evtl. z. B. mit vorangestellten der/die/das oder ein/eine. 

- 3. Termin: Entwurf

7. Abgleich Klassendiagramm, Sequenzdiagramm

Übernehmen Sie die Informationen (z. B. Operationen) des Sequenzdiagramms in die Klassendiagramme (automatisch über Innovator). 
Prüfen Sie das Klassendiagramm auf Richtigkeit (gibt es Operationen / Klassen, die mit unterschiedlichen Namen doppelt vorkommen? ...). Untersuchen Sie , wo es weitere Generalisierungshierarchien gibt? (Welche Klassen haben gleiches Verhalten?)

8. Zustandsdiagramm

Erstellen Sie ein Zustandsdiagramm der Waage. Entspricht der Ablauf, nachdem Sie die Codegenerierung des Zustandsdiagramms gemäß Vorlesung durchgeführt haben, dem Ablauf in Ihrem Sequenzdiagramm? Wo liegt der Unterschied? Muss etwas im Sequenzdiagramm korrigiert werden?

9. Erstellen Testfälle

Spezifizieren Sie die Tests der Einzelbausteine (Modultests), einzelner Teile des Systems (Integrationstests) und des Gesamtsystems (über die Abnahmetests hinausgehende Systemtests). Geben Sie zu jedem Testfall jeweils die Werte der Eingabeparameter / Benutzereingaben, Zustande der involvierten Objekte und die Werte der erwarteten Rückgabeparameter / Benutzerausgaben an.
 
10. Review (Entwurfsinspektion)

Setzen Sie sich mit einer anderen Gruppe, die auch schon die vorangegangenen Punkte abgeschlossen hat, zusammen und führen Sie einen Review durch (evtl. gegenseitig). 

- 4. Termin: Implementierung

11. Kreieren der Komponentendiagramme  und Umsetzung in Programm-Code

Kreieren Sie Komponentendiagramme, führen Sie die Abbildungen zu den Klassendiagrammen durch und erzeugen Sie automatisch Code(rahmen).

12. Erstellung des Gesamtprogramms

Schreiben sie die Main und Ergänzen Sie die Coderahmen. Führen Sie jeweils Modul- und Integrationstests und nach Fertigstellung des Programms einen Systemtest durch.

13. Review (Codeinspektion)

Setzen Sie sich mit einer anderen Gruppe, die auch schon die vorangegangenen Punkte abgeschlossen hat, zusammen und führen Sie einen Review durch (evtl. gegenseitig). 

- 5. Termin: Testen, Dokumentieren, Abnahme

14. Methodisches Austesten des Programmes

Fühen Sie die Tests durch und dokumentieren Sie die Testfälle.

15. Zusammenstellung der Dokumentation

Zusammenstellen der Dokumentation mit dem Innovator.

16. Review (Vorbereitung der Endabnahme)

Setzen Sie sich mit einer anderen Gruppe, die auch schon die vorangegangenen Punkte abgeschlossen hat, zusammen und führen Sie einen Review durch. Probe Sie auch mit dieser Gruppe den Abnahmetest. 

17. Endabnahme durch den Anwender
	Die Endabnahme wird durch mich durchgeführt. Zur Abnahme gehört auch das Prüfen aller Dokumente, wie Dokumentation, Testpläne, Dokumentationen der Tests...

- 6. Termin

Metriken. Aufgabe wird noch ausgeteilt.

Ablauf des Praktikums 

In Praktikum besteht Anwesenheitspflicht. Unentschuldigtes Fernbleiben führt zum Ausschluss und Nichtbestehen des Praktikums.
Die im jeweiligen Praktikum durchzuführenden Tätigkeiten sind vor dem Praktikumstermin vorzubereiten. Zu Beginn des Praktikums müssen zumindest Handskizzen zu den im Praktikum abzunehmenden Diagrammen und Programmen vorliegen.
Falls die bei dem Termin fertig zu stellenden Teile nicht fertig sind oder eine Abnahme am Ende der Stunde wegen Überlastung des Betreuers nicht möglich ist, wird zu Beginn der nächsten Stunde die Abnahme durchgeführt. 
Falls eine Gruppe unvorbereitet zum Praktikum erscheint oder zu Beginn des darauf folgenden Praktikums nicht die geforderte Leistung erbracht hat, wird einmalig ermahnt (GELBE KARTE). Beim 2. Vorkommen dieser Art wird der Studierende vom weitern Besuch der Veranstaltung ausgeschlossen und das Praktikum als nicht bestanden gewertet (ROTE KARTE).
Sie können auch schon vor den angegebenen Terminen Teile abnehmen lassen. Falls ein Teil, der zu einem Praktikum zur Abnahme ansteht, schon abgenommen ist, besteht keine Anwesenheitspflicht zu diesen Termin. Denken Sie daran: Am Ende des Semesters wird es immer knapp, nutzen Sie die Möglichkeit der vorgezogenen Abgabe.