Etappe 2: Von der Analyse zum softwaretechnischen Modell

Chez Motchi entsteht als erstes Modell

Wir kennen jetzt die Grundidee der Objektorientierung und wissen, dass UML uns dabei hilft, Objekte sichtbar zu machen. In dieser Lektion wenden wir das erstmals wirklich an. Dabei geht es noch nicht darum, ein perfektes UML-Klassendiagramm zu zeichnen – das folgt in aller Ausführlichkeit erst in Kapitel 3. Hier wollen wir vor allem lernen, wie man überhaupt zu einem ersten Modell gelangt.

Schritt 1: Welche Dinge spielen überhaupt eine Rolle?

Lies die Anforderung noch einmal aufmerksam durch. Welche Begriffe fallen dir auf? Welche Dinge sind für Chez Motchi wichtig?

Bei der Analyse fallen schnell mehrere zentrale Begriffe auf:

• Gast
• Tisch
• Reservierung
• Mitarbeiter

Diese Begriffe beschreiben Dinge, die innerhalb des Systems eine Rolle spielen. In der Objektorientierung nennen wir solche Bestandteile Objekte oder – sobald wir sie allgemein betrachten – Klassen.

Schritt 2: Welche Informationen müssen gespeichert werden?

Sobald wir die wichtigsten Objekte gefunden haben, fragen wir uns: Welche Informationen müssen wir über sie speichern? Diese Informationen nennen wir Attribute.

Schritt 3: Welche Aufgaben gibt es?

Objekte speichern nicht nur Informationen, sie besitzen auch Aufgaben. Diese nennen wir Methoden.

• Eine Reservierung kann bestätigt oder storniert werden: bestaetigen(), stornieren()
• Ein Mitarbeiter kann eine Reservierung anlegen oder eine Bestellung aufnehmen: reservierungAnlegen(), bestellungAufnehmen()

Schritt 4: Wie stehen sie in Beziehung?

Ein Softwaresystem entsteht erst dadurch, dass die einzelnen Objekte miteinander verbunden sind.

• Ein Gast kann mehrere Reservierungen besitzen – etwa eine für heute und eine für nächste Woche.
• Ein Mitarbeiter kann mehrere Reservierungen bearbeiten.
• Eine Reservierung ist einem Tisch zugeordnet.

Ein erstes, noch grobes Skelett unseres Modells könnte so aussehen:

   Gast ────────── Reservierung ────────── Tisch
                        │
                    Mitarbeiter

Schritt 5: Muss etwas korrigiert werden?

In unserer ersten Version des Systems könnte derselbe Tisch versehentlich für zwei Reservierungen zur gleichen Uhrzeit vergeben werden – schließlich haben wir bisher nur festgelegt, dass eine Reservierung irgendeinem Tisch zugeordnet ist, nicht aber, dass ein Tisch zu einer bestimmten Zeit nur einmal vergeben werden darf.

Überlege: Warum ist das ein Fehler im Modell, und wie würdest du die Struktur anpassen, um das Problem zu lösen?

Die Lösung besteht darin, die Beziehung zwischen Tisch und Reservierung genauer festzulegen: Ein Tisch darf zu einer bestimmten Uhrzeit nur mit genau einer Reservierung verbunden sein. Diese Art von Regel bezeichnet man in UML später als Kardinalität – ein Konzept, das wir in Kapitel 3 im Detail behandeln.

Schritt 6: Wie erkläre ich das Motchi?

Ein Mitarbeiter von Chez Motchi fragt dich: „Wie lege ich eine neue Reservierung an und weise ihr einen Tisch zu?“ Dank unseres Modells lässt sich das klar beantworten:

1. Objekt Reservierung anlegen.
2. Gast zur Reservierung hinzufügen.
3. Freien Tisch zuordnen.

Das Modell zeigt genau, warum diese Reihenfolge nötig ist: Eine Reservierung hängt an einem Gast und an einem Tisch – ohne diese beiden Angaben ist sie unvollständig.