| Sascha Deutschkron |
Version vom: $Date: 2001/02/09 15:46:27 $
|
| Zurück | Hauptseite |
OrganisatorischesKommendes SeminarSitzungsleiter: Sascha Deutschkron Protollant: Paul Hackenberger Weitere Planung Steven ändert die Operationen und schickt sie in der Mailingliste rum, damit sie sich jeder mal anschauen kann. Gruppenaufteilung Kundenoperationen: Manuel, Steven Anbieteroperationen: Ina, Michael Auktionsschnittstellenoperationen: Alphonse, Paul, Sascha Konsistenzwerkzeuge: Tina Prototyp: Serge, Jirk, Alexander, Liviu Systemspezifikation - Automaten / StateCharts und OperationenNach einigen Verzögerungen aufgrund von Problemen mit der Technik stellte dann Manuel verschiedene Automaten und StateCharts vor. Später wollte er dann auf die Operationen eingehen, die zu definieren wohl ein Problem war.Der erste Automat behandelte das An- und Abmelden, der nächste Ticket suchen / kaufen. Es wurde angeregt, bei der Rubrikensuche eine Ergebnisliste zurückgeben zu lassen - Manuel wollte dies noch überarbeiten. Der letzte Automat erklärte die Warenkorbprüfung. Dabei fiel auf, dass es sich hierbei um kein Zustandsdiagramm handelte. An dieser Stelle sprang dann Herr Löhr mit einer kurzen Präsentation von Sinn, Zweck und Aufbau von StateCharts ein. Es kam zu einer regen Diskussion. Schließlich fuhr Steven mit der Vorstellung der Operationen fort. Bei der ersten, Rubrik auswählen, sollte der Effekt wohl eher leer bleiben. Auch ist es wohl besser, Optionen mit 'entweder / oder' zu kennzeichnen. Auch bei der Operation auswählen ist der Effekt wohl eher die Ausgabe. Auch hier musste dann Herr Löhr kritisieren: Die Operationen nehmen keine Bezug auf das Klassendiagramm! Das sollten sie aber! Es folgte sogleich eine Vorstellung von zwei Beispieloperationen, die Herr Löhr ausgearbeitet hatte: anmelden Eingabe: Text id, Text passwort Ausgabe: Kauf k Voraussetzung: Es gibt einen Kunden x mit x.ID=id und x.passwort=passwort. Dieser Kunde hat keinen Mini-Warenkorb (Kauf) mit Zeitpunkt=0. Effekt: Der Kunde hat einen neuen Mini-Warenkorb (Kauf) k (=Ergebnis) mit dem Zeitpunkt=0, gesamtpreis=0. Ticket reservieren Eingabe: Ticketkontingent tk, Aufdruck a, Kauf k Ausgabe: Ticket t Voraussetzung: a ist in tk.ticketpool. Die Zahlungsarten von tk und k sind nicht disjunkt. Effekt: Der Kauf k ist um ein neues Ticket t (=Ergebnis) erweitert, mit neuer nummer, aufdruck a und preis=tk.Preisgestaltung.startpreis. tk.ticketpool ist um a geschrumpft. Evaluation von TogetherJIm Anschluss stellte Ina und Michael ihre Evaluationsergebnisse von TogetherJ vor. Es wurde sich dafür entschieden, statt RationalRose nun ab 2001 TogetherJ zu benutzen. Am 12.01.2001 werden dann Ina und Micha voraussichtlich noch einmal eine Präsentation halten, um jeden in die Bentzung einzuweisen.Vorstellung des PrototypsZum Schluss stellten Serge, Liviu und Jirk den ersten Prototypen vor. Herr Schweppe regte für das nächste Mal an, dass diese Gruppe einen Bericht fertigstellt, der darüber Aufschluss gibt, was wir jetzt durch diesen Prototypen gelernt haben und wie uns helfen kann. Außerdem sollte die Performance bewertet werden.Anwesenheit
|
| Zurück | Top | Hauptseite |