Q1 / OOP in Java

UML-Diagramm erzeugen

Lösung geprüft

Die Aufgabe der heutigen Stunde ist der UML-Klasseneditor! Wir haben die Klasse Termin auf dem Papier entworfen, jetzt bauen wir sie im Java-Editor nach – und zwar nicht durch Tippen, sondern über das UML-Fenster. Der Editor erzeugt den Java-Code dann selbst.

Das ist der Kasten, der am Ende im UML-Fenster stehen soll:

classDiagram
    class Termin {
        -LocalDate datum
        -LocalTime uhrzeit
        -Art art
        +Termin(LocalDate, Art)
        +Termin(LocalDate, LocalTime, Art)
        +getDatum() LocalDate
        +setDatum(LocalDate) void
        +getUhrzeit() LocalTime
        +setUhrzeit(LocalTime) void
        +getArt() Art
        +setArt(Art) void
        +toString() String
    }

So geht man im Editor vor

1. Datei > Neu > Klasse – es öffnet sich der UML-Klassen-Editor
2. Im Reiter Klasse den Namen Termin eintragen
3. Im Reiter Attribute die drei Attribute anlegen: Zugriff auf private stellen, Name und Typ eintragen, get-Methode und set-Methode ankreuzen, dann Neu
4. Im Reiter Methoden die beiden Konstruktoren und toString() ergänzen
5. Die beiden import-Zeilen von Hand oben in den Code schreiben – die kann der Editor nicht raten

Das Häkchen bei get-Methode und set-Methode ist der eigentliche Gewinn: der Editor schreibt die Getter und Setter selbst. Bei drei Attributen sind das sechs Methoden, die man sonst von Hand tippen müsste – und bei denen man garantiert einmal this. vergisst.

Lösungsprozess der Aufgabe

/**
 *
 * Die Klasse Termin fuer das Telefonbuch
 *
 * @version 1.0 vom 14.09.2025
 * @meininfokurs.cmrg.site
 */

import java.time.LocalDate;
import java.time.LocalTime;

public class Termin {

    // Die vier Arten, die ein Termin haben kann
    public enum Art {
        GEBURTSTAG, JAHRESTAG, GESCHAEFTLICH, PRIVAT
    }

    // Anfang Attribute
    private LocalDate datum;
    private LocalTime uhrzeit;
    private Art art;
    // Ende Attribute

    // Konstruktor ohne Uhrzeit - zum Beispiel fuer Geburtstage
    public Termin(LocalDate datum, Art art) {
        this.datum = datum;
        this.uhrzeit = null;
        this.art = art;
    }

    // Konstruktor mit Uhrzeit
    public Termin(LocalDate datum, LocalTime uhrzeit, Art art) {
        this.datum = datum;
        this.uhrzeit = uhrzeit;
        this.art = art;
    }

    // Anfang Methoden
    public LocalDate getDatum() {
        return datum;
    }

    public void setDatum(LocalDate datum) {
        this.datum = datum;
    }

    public LocalTime getUhrzeit() {
        return uhrzeit;
    }

    public void setUhrzeit(LocalTime uhrzeit) {
        this.uhrzeit = uhrzeit;
    }

    public Art getArt() {
        return art;
    }

    public void setArt(Art art) {
        this.art = art;
    }

    public String toString() {
        return "Termin{datum=" + datum
             + ", uhrzeit=" + uhrzeit
             + ", art=" + art + "}";
    }
    // Ende Methoden

} // end of class Termin

Die zu ergänzende Zeile: toString

Der UML-Editor legt toString() zwar an, füllt sie aber nicht. Genau das ist die Zeile, die ergänzt werden soll:

public String toString() {
    return "Termin{datum=" + datum + ", uhrzeit=" + uhrzeit + ", art=" + art + "}";
}

toString() ist eine besondere Methode. Java ruft sie automatisch auf, sobald ein Objekt in einem String-Zusammenhang auftaucht:

System.out.println(meinTermin);          // ruft intern meinTermin.toString() auf
String s = "Termin: " + meinTermin;      // hier genauso

Schreibst du keine eigene toString(), erbt deine Klasse die von Object, und die gibt so etwas aus wie Termin@6d06d69c. Das ist der Klassenname plus eine interne Speicheradresse und hilft niemandem. Deshalb gehört eine eigene toString() in jede Klasse, die man irgendwann mal ausgeben will.

Warum die Imports nicht automatisch kommen

LocalDate und LocalTime liegen im Paket java.time. Der UML-Editor kennt beim Anlegen des Attributs nur den Namen des Typs, nicht das Paket – deshalb musst du die beiden Zeilen selbst oben hinschreiben.

Fehlen sie, bekommst du cannot find symbol – class LocalDate, obwohl im UML-Diagramm alles richtig aussieht. Das ist bei dieser Aufgabe der häufigste Stolperstein, weil man im Diagramm keinen Fehler sieht.

Zwei Dateien am Ende

Der Java-Editor speichert bei dieser Arbeitsweise zwei Dateien: Termin.java mit dem Code und Termin.uml mit dem Diagramm. Beide gehören zur Abgabe.

Das Praktische daran: die beiden bleiben synchron. Änderst du das Diagramm, ändert sich der Code – und wenn du den Code änderst und das Diagramm aktualisierst, erscheint die Änderung auch dort. Deshalb steht in der Aufgabe, dass aus UML-Diagrammen automatisch Code erzeugt werden kann und umgekehrt.