Q1 / OOP in Java

UML-Diagramm im Java-Editor

Lösung geprüft

Die Aufgabe der heutigen Stunde ist das UML-Diagramm im Java-Editor! Die Klassen stehen alle, jetzt schauen wir uns an, wie sie zusammenhängen. Der Editor zeichnet die Beziehungen von selbst, sobald man die Klassen ins Diagramm holt – wir müssen nur verstehen, warum er welche Linie malt.

Assoziation oder Aggregation?

Das ist die Frage, um die es hier geht, und die Antwort hängt nur an einer Sache: wie viele.

Die Faustregel aus dem Unterricht: bei einer oder zwei Beziehungen nimmt man einzelne Attribute, ab mehr als zwei ein Feld oder eine Liste – und dann ist es eine Aggregation. Bei fester Anzahl ein Array, bei variabler Anzahl eine Liste.

Das lässt sich direkt im Code ablesen:

private Adresse adresse;          // ein Objekt  -> Assoziation
private Telefon telefon;          // ein Objekt  -> Assoziation
private Email email;              // ein Objekt  -> Assoziation

private List<Termin> termine;     // viele       -> Aggregation, Raute bei Kontakt
private List<Gruppe> gruppen;     // viele       -> Aggregation

Man muss also gar nicht raten. Steht im Attribut ein einzelner Typ, ist es eine Assoziation. Steht dort eine Liste oder ein Array, ist es eine Aggregation und die Raute kommt an die Seite der Klasse, die die Liste hat – also an Kontakt.

Das fertige Diagramm

So sieht Kontakt.uml aus, nachdem Termin und Adresse dazugeholt wurden. Die Methoden sind hier weggelassen, es geht nur um die beiden Linien – die Attribute stehen dagegen alle drin, so wie der Java-Editor sie anzeigt:

classDiagram
    class Kontakt {
        -String name
        -Adresse adresse
        -Telefon telefon
        -Email email
        -List~Termin~ termine
        -List~Gruppe~ gruppen
    }
    class Termin {
        -LocalDate datum
        -LocalTime uhrzeit
        -Art art
    }
    class Adresse {
        -String strasse
        -String hausnummer
        -String plz
        -String ort
        -String land
        -Typ typ
    }
    Kontakt o-- Termin : Aggregation
    Kontakt --> Adresse : Assoziation

Und genau bei diesen Attributen gibt es zwei Schreibweisen, die man auseinanderhalten muss.

Java-Editor-Notation gegen ABI-Notation

Das ist der Punkt, der in der Klausur zählt. Der Java-Editor zeigt adresse: Adresse und termine: List<Termin> zusätzlich als Attribute im Kasten der Klasse Kontakt an – obwohl die Linie zur anderen Klasse dasselbe schon aussagt.

Nach ABI-Notation lässt man die weg. Die Beziehung steht als Linie da, damit ist sie ausgedrückt; sie nochmal als Attribut hinzuschreiben ist doppelt gemoppelt. In der Abbildung im OneNote sind die beiden Zeilen adresse: Adresse und termine: List<Termin> deshalb durchgestrichen.

Für dich heißt das konkret: zeichnest du das Diagramm in der Klausur von Hand, lässt du diese Attribute weg. Lässt du es dir vom Editor erzeugen, stehen sie drin – das ist kein Fehler des Editors, nur eine andere Konvention. Die Multiplizität gehört dann an die Linie: * bei den Terminen, 1 bei der Adresse.

Warum die Raute bei Kontakt steht

Die Raute markiert das Ganze, nicht das Teil. Ein Kontakt hat Termine, also ist der Kontakt das Ganze und die Termine sind die Teile. Deshalb sitzt die Raute am Kontakt.

Ein Gegentest, der immer funktioniert: kann das Teil auch ohne das Ganze existieren? Ein Termin ohne Kontakt ist zwar denkbar, gehört in unserem Programm aber immer zu einem. Der Kontakt übernimmt stellvertretend die Aufgaben für seine Termine – er ist es, der sie hinzufügt, entfernt und ausgibt. Genau das beschreibt die Aggregation.

Was man im Editor klickt

1. Im UML-Fenster Rechtsklick auf die freie Fläche
2. Klasse öffnen wählen und die gewünschte .java-Datei aussuchen
3. Die Klasse erscheint, und der Editor zeichnet die Linien zu den schon vorhandenen Klassen selbst
4. Über Neu layouten die Kästen ordentlich verteilen
5. Als Kontakt.uml speichern

Dass der Editor die Beziehungen selbst findet, ist ein guter Test für deinen Code: taucht eine Linie nicht auf, die du erwartet hättest, hast du das Attribut vermutlich als String statt als richtigen Typ deklariert. Zeichnet er eine Assoziation, wo du eine Aggregation erwartest, hast du ein einzelnes Attribut statt einer Liste. Das Diagramm zeigt dir also Fehler in deinem Entwurf, bevor du das Programm überhaupt startest.