Nr. 1 L-Aufgabe 1.2002 a) In der Aufgabenstellung war ein möglichst einfaches Klassendiagramm gefordert. Daher verzichten wir auf Klassen, die zwar der Problemwelt entstammen, aber für die Lösung der geforderten Aufgabe und zur Beantwortung der vom Auftraggeber genannten Anfragen nicht erforderlich sind. In diese Kategorie fallen Klassen wie "Produktgruppe", "Warenkorb", "Produktliste", "Kasse", "Einkauf", "Zahlung", "Kreditkarte", "Preis", "Kundenkonto", "Buchung" usw. Zur Lösung der Aufgabenstellung reicht das nachfolgende Klassendiagramm aus. Wichtig ist, dass bei der Bestellung von Waren deren Preis festgehalten wird und dass eine Bestellung auch mit Produkten verbunden sein kann, die nicht mehr im Sortiment sind. Daher definieren wir ein Attribut imsortiment in der Klasse Produkt und ein Attribut bestellpreis in der Klasse Einzelposten. b) Die erste folgende Abbildung zeigt das Objektdiagramm vor der Ausführung des Bezahlvorgangs, die nächste zeigt das Objektdiagramm danach. Objektdiagramm 11
Objektdiagramm (danach) c) Es gibt mehrere Möglichkeiten, die beschriebenen Vorgänge als Anwendungsfälle zu modellieren. Die nachfolgende Abbildung zeigt eine davon. 2
Nr. 2 Aufgabe 1.2003_09 a) In der Aufgabenstellung war ein möglichst einfaches Klassendiagramm gefordert. Daher verzichten wir auf Klassen wie Sofortkauf, Bewertung oder Benachrichtigung. Abb. 1 zeigt eine mögliche Lösung. Ein Kunde kann als Verkäufer eine Auktion initiieren, als Käufer einen Kauf tätigen und als Bieter ein Gebot abgeben. Im ersten Fall ist keine Zusatzinformation notwendig, daher wird eine einfache Assoziation initiiert modelliert. Im zweiten und dritten Fall ist Zusatzinformation notwendig, die durch Attribute der Klassen Kauf und Gebot modelliert wird. Die Realisierung dieser Klassen ist jedoch unterschiedlich, weil es zu jedem Paar (Kunde, Auktion) nur eine Kauf-Instanz, aber mehrere Gebot-Instanzen geben kann. Da zwei Objekte über eine Assoziation nicht mehrfach verbunden sein können, kann nur die Klasse Kauf als Assoziationsklasse modelliert werden, während Gebot eine eigenständige Klasse sein muss. 33
b) Abb. 2 zeigt ein Objektdiagramm des Online-Auktionssystems. c) Anwendungsfallspezifikation für den Anwendungsfall "Auktion beenden": use case Auktion beenden actors Systemuhr precondition Bei einer Auktion wurde der Versteigerungs-Endzeitpunkt überschritten. main flow Das System ermittelt das höchste Gebot. Das System registriert einen Kauf des versteigerten Artikels durch den Höchstbietenden. Der Verkäufer und alle Bieter werden über den Ausgang der Versteigerung informiert. postcondition Für die Auktion können keine Gebote mehr abgegeben werden. exceptional flow keine Gebote vorhanden Der Verkäufer wird informiert, dass der Artikel nicht ersteigert wurde. postcondition Für die Auktion können keine Gebote mehr abgegeben werden. end Auktion beenden. 4
Nr. 3 L-Aufgabe 4.2002 a) Die nachfolgende Abbildung zeigt eine Lösung für ein Klassendiagramm, das die Anforderungen der Aufgabenstellung erfüllt. b) Für die in a) gezeigten Vereinfachungen sprechen folgende Gründe: Die Information, ob es sich bei einer Schülergruppe um eine Klasse oder einen Kurs handelt, kann einfacher in einem Attribut festgehalten werden. Gleiches gilt für die Jahrgangstufe einer Klasse oder eines Kurses. Da sich das Verhalten dieser Klassen nicht (oder nur sehr geringfügig) unterscheidet, können sie nach Heuristik H 25.5 zusammengefasst werden. Die Information, ob eine Schülergruppe zur Ober-, Mittel- oder Unterstufe gehört, lässt sich aus der Jahrgangstufe entnehmen und braucht daher nicht extra modelliert zu werden. Die Angabe des Wochentags ist nicht für alle Unterrichtsstunden, sondern nur für reguläre Unterrichtsstunden erforderlich. Bei Vertretungsstunden ist der Wochentag durch das Datum gegeben. Für die Angabe des Wochentags ist keine eigene Klasse erforderlich, daher wurde die Klasse Wochentag durch ein Attribut Wochentag in der Klasse ReguläreStunde ersetzt. Die Assoziation GibtUnterricht ist zu stark generalisiert: Sie enthält sowohl Stunden aus dem Lehrerstundenplan (reguläre Stunden) als auch Vertretungsstunden. Da der Lehrerstundenplan und der Vertretungsplan in der Anwendungsdomäne separat gehandhabt werden, ist es sinnvoll, die Assoziation GibtUnterricht in der Aufgabenstellung durch die Assoziationen Lehrerstundenplan und Vertretungsplan zu ersetzen (s. obige Abbildung). 55
Nr. 4 L-Aufgabe 2.2003 a) und c) Die folgende Abbildung zeigt ein Klassendiagramm, das die Anforderungen der Aufgabenstellung erfüllt. Verbessertes Klassendiagramm zur Reservierungsverwaltung b) Für die in a) gezeigten Vereinfachungen sprechen folgende Gründe: Zu der Klasse Theater existiert in der Anwendung nicht mehr als eine Instanz. Daher wird die Klasse gemäß Merkregel R19.6 aus dem Diagramm entfernt. Das Attribut anzahlsitze ist überflüssig, es kann aus der Anzahl der Instanzen der Klasse Sitz berechnet werden. Die Klassen Parkett und Loge besitzen das gleiche Verhalten und werden gemäß Heuristik H25.5 mit Hilfe der Attribute bezeichnung und preis der Klasse Kategorie modelliert. Die Attribute titel, datum und beginn der Klasse Ticket sind redundant und werden aus dem Modell entfernt. Das Attribut anzverkauftetickets der Klasse Premiere ist redundant und wird entfernt. Die Klasse Premiere wird gemäß Heuristik H25.5 als Attribut der Klasse Vorstellung modelliert. Da der Kunde bei Einzelreservierungen nicht relevant ist, wird die Assoziation der Klasse Kunde zur Klasse Reservierung entfernt und durch eine Assoziation zur Klasse Jahresabonnement ersetzt. Da die Klasse Reservierung kein Attribut und keine Assoziation mehr besitzt wird sie aus dem Modell entfernt. Die Klasse Bankverbindung ist statt mit der Klasse Jahresabonnement nun mit der Klasse Kunde assoziiert, da zu einem Kunden gleichzeitig nur höchstens eine Bankverbindung existiert und so Redundanz vermieden wird. Anm. zu c) Nur bei neu hinzu gekommenen, korrekten Assoziationen wurden Punkte vergeben. 6
Nr. 5 L-Aufgabe 2.2002 Die folgende Abbildung zeigt das Zustandsdiagramm des mobilen Roboters: Nr. 6 L-Aufgabe 3.2000 A Zustandsdiagramm für den mobilen Roboter In dieser Aufgabe sollten Sie ein Zustandsdiagramm für die Klasse Steuerung einer einfachen Fahrstuhlsteuerung entwickeln. a) Zustandsdiagramm für die Fahrstuhlsteuerung 77
Aus Gründen der Übersichtlichkeit ist bei den Aktionen (Operationsaufrufen) das Ziel nicht angegeben. So wäre z.b. die Aktion stop() an dem Übergang vom Zustand "Fahrt" in den Zustand "WartendTürOffen" präzise als Aufzugmotor.stop() zu schreiben. b) Die folgende Abbildung zeigt das Klassenmodell der Fahrstuhlsteuerung nach der Transformation. Nr. 7 L-Aufgabe 1.2001 A a) Die Abbildung auf Seite 9 stellt das Anwendungsfalldiagramm des Fahrkartenautomaten dar. b) Textuelle Spezifikation des Anwendungsfalls "Fahrkarte kaufen": use case Fahrkarte kaufen actors Kunde main flow Der Kunde wählt die Fahrkarte aus (include "Fahrkarte wählen). Der Automat zeigt den zu zahlenden Fahrpreis an. Der Kunde bezahlt den Fahrpreis (include "Fahrpreis bezahlen"). Der Automat gibt die Fahrkarte aus. exceptional flow Abbruch Der Kunde drückt die Abbruch-Taste. Die Auswahl der Fahrkarte wird aufgehoben und keine Fahrkarte ausgegeben. 8
exceptional flow TimeOut Die vollständige oder unvollständige Auswahl der Fahrkarte wird aufgehoben, wenn nicht innerhalb eines bestimmten Zeitraums die Bezahlung des Fahrpreises erfolgt. Es wird in diesem Fall keine Fahrkarte ausgegeben. exceptional flow Bezahlung fehlgeschlagen Die Bezahlung ist nicht erfolgreich. Die Auswahl der Fahrkarte wird gelöscht und keine Fahrkarte ausgegeben. end Fahrkarte kaufen Nr. 8 L-Aufgabe 3.2003 a) Die folgende Abbildung zeigt den Mechanismus des Anwendungsfalls "Video ausleihen" für den Grobentwurf. 99
Sequenzdiagramm zum Szenario c) Nein. Sequenzdiagramme unterstützen die Darstellung von alternativen Abläufen nur unzureichend. 10
Nr.9 Aufgabe 3.2003_09 a) Ein Iterator ist ein Objekt, das die Elemente eines Behälterobjekts aufzählen kann und zu diesem Zweck die Operationen hasnext():boolean und next():object anbietet. b) Abb. 4 zeigt das Sequenzdiagramm für den Ablauf der Operation tostring() der Klasse HashSet. c) Die Variable index hat den Wert 1, weil an der Indexposition 1 das erste gültige Element liegt. d) Die Operation muss nur einmal aufgerufen werden, weil sie das nächste verwendete (=gültige) Element sucht. e) Abb. 5 zeigt das verfeinerte Sequenzdiagramm für den Ablauf der Operation tostring() der Klasse HashSet. f) Wenn dem HashSet neue Elemente hinzugefügt werden, werden diese an irgendwelchen (von der Hashfunktion abhängigen) Stellen in das Array hashtable eingefügt. Der Iterator wird die neu eingefügten Elemente ausgeben, sofern sie im Array hinter der Stelle index liegen. Mit anderen Worten: Die nachträglich eingefügten Elemente werden "vielleicht" ausgegeben. Anmerkung: Eine gute Iterator-Implementierung sollte im Fall von nachträglichen Veränderungen der durchlaufenen Datenstruktur entweder eine Fehlermeldung liefern oder ein anderes, klar definiertes Verhalten zeigen. 1111
12
Nr. 10 L-Aufgabe 2.2002A a) Die folgende Abbildung zeigt das Sequenz-Diagramm für den Fall, dass ein Dienstnutzer die Operation hinzufügenkunde() eines Kundenordners aufruft. b) Die folgende Abbildung zeigt das Kollaborationsdiagramm für den Fall, dass ein Dienstnutzer einen Kundenbrowser erzeugt. 1313
Nr. 11 L-Aufgabe 4.2003 a) Die echten Ganzes-Klassen sind C und D. b) Die folgende Abbildung zeigt das Feinentwurfs-Klassendiagramm. Feinentwurfs-Klassendiagramm Alternative Verfeinerung der Assoziation zwischen Klasse A und D bzw. B und D: 14
Nr. 12 L-Aufgabe 5.2003_09 a) Es sind fünfverbindungen erforderlich, vgl. Abb. 7. b) Die Objekte b1, b2, d1, d2 und f1 sind von Instanzen anderer Klassen aus erreichbar. c) Von den Klassen B und D ist jede Instanz erreichbar. d) Die Klassen A, C, E, F, G, H, und I sind Echte Ganzes-Klassen. e) Echte Ganzes-Klassen sind genau die Klassen, für die im Entwurf auf jeden Fall ein Ordner vorgesehen werden muss, da sonst nicht alle Instanzen erreichbar sind. 1515