Q1.1 – Von der Wirklichkeit zum Objektmodell

In E3 wurde Java bereits als objektorientierte Sprache verwendet: Der Quelltext stand in einer Klasse, main war eine statische Methode, und mit String, Scanner, GUI-Komponenten und weiteren Bibliotheksklassen waren bereits Objekte im Einsatz. Im Mittelpunkt standen jedoch Variablen, Kontrollstrukturen, Methoden, Tests und einfache Algorithmen; die Klassenhülle diente vor allem als technischer Rahmen. In Q1.1 wird sie selbst zum Gegenstand: Eigene Klassen, Verantwortlichkeiten und Beziehungen werden geplant, als UML-Klassendiagramm festgehalten und in mehreren zusammenwirkenden Java-Dateien umgesetzt.

Aus E4 bleiben Projektziel, Produktgrenze, überprüfbare Anforderungen sowie Test, Review und Dokumentation wirksam: Sie richten sich nun auf Modellzweck, Systemgrenze und die Zusammenarbeit von Klassen. Aus E5 bleibt die Methode als fachlich benannte Verarbeitungsroutine mit Eingaben und Ergebnis erhalten; in Q1.1 kann sie zusätzlich an ein Objekt gebunden sein und auf dessen dauerhaften Zustand zugreifen.

Das grundlegende Niveau bildet den gemeinsamen Pflichtkern für Grundkurs und Leistungskurs. Der Weg beginnt mit einer Problembeschreibung: Relevante Objekte, Eigenschaften und Funktionalitäten werden ausgewählt, klassifiziert und in Beziehungen gesetzt; danach werden Modell und Implementation kritisch verglichen und bei Bedarf überarbeitet. Das erhöhte Niveau ergänzt diesen Grundweg ausschließlich im Leistungskurs durch Vererbung, abstrakte Klassen und Polymorphie; diese Konzepte erweitern ein bereits tragfähiges Modell, statt den Einstieg in die Modellbildung zu ersetzen.

Modellieren bedeutet, zu einem begrenzten Ausschnitt der Wirklichkeit für einen bestimmten Zweck ein fachliches Modell anzufertigen. Dazu werden relevante Gegenstände, Eigenschaften, Vorgänge und Beziehungen ausgewählt, geordnet und vereinfacht. Nicht benötigte Informationen werden bewusst weggelassen.

Am Beispiel der Schulmediathek wird der Modellierungsweg anhand übertragbarer Leitfragen nachvollzogen. Dieselben Fragen können später auf andere Realitätsausschnitte angewendet werden.

Welchen Zweck hat das Modell beziehungsweise welche Frage soll es beantworten?

In der Schulmediathek geht es zunächst um die Verfügbarkeit eines Mediums sowie um Zustandsänderungen durch Ausleihe und Rückgabe.

Wo verläuft die Systemgrenze?

Medien, Titel, Verfügbarkeit, Ausleihe und Rückgabe gehören zum ersten Ausschnitt. Anmeldung, Gebühren, Räume und Spezialdaten einzelner Medienarten bleiben begründet außerhalb.

Welche konkreten Gegenstände müssen im Modell unterscheidbar bleiben?

tschick und welle besitzen jeweils eine eigene Identität und einen eigenen Zustand.

Welche Eigenschaften und Vorgänge sind für den Modellzweck relevant?

titel, verfuegbar, ausleihen() und zurueckgeben() sind relevant; Covergestaltung und Regalstandort sind momentan unwesentlich.

Welche Gemeinsamkeiten und Verantwortlichkeiten rechtfertigen eine Klasse?

Die gemeinsamen Eigenschaften und Vorgänge führen zum Klassenkandidaten Medium. Seine Verantwortung ist die kontrollierte Verwaltung eines gültigen Verfügbarkeitszustands. Eine Klasse entsteht nicht bloß aus einem Substantiv oder zur technischen Reparatur paralleler Arrays.

Wie kann der Entwurf dargestellt, geprüft und bei neuen Anforderungen verändert werden?

UML stellt die ausgewählte Struktur dar; konkrete Ausleihfälle prüfen die Zustandsregeln; Java implementiert den Entwurf. Eine spätere Anforderung wie eine Ausleihhistorie kann eine Revision und die Klasse Ausleihe notwendig machen.

In E3 war die Klasse zunächst der notwendige Java-Rahmen für main; hier beschreibt Medium einen selbst definierten Referenztyp für gleichartige fachliche Objekte. Eine Variable dieses Typs kann auf eine passende Instanz verweisen; Titel, Verfügbarkeit und die Regeln für ihre Änderung liegen beim jeweiligen Objekt.

Objektorientierung ist dabei mehr als Java-Syntax: Ein objektorientiertes Programm wird als System zusammenarbeitender Objekte strukturiert. Jedes Objekt verbindet individuellen Zustand und Verhalten, übernimmt eine begrenzte Verantwortung und kommuniziert über Methoden mit anderen Objekten. Die Modellierung entwirft dieses System zunächst sprachunabhängig; die objektorientierte Programmierung setzt den Entwurf anschließend in Java um.

Modell ≠ UML-Diagramm ≠ Java-Programm: Das Modell ist die zweckgebundene fachliche Beschreibung dieser Entscheidungen. UML ist eine formale Darstellung ausgewählter Modellstrukturen; Java realisiert ausgewählte Strukturen und Verhaltensweisen.

Modellzweck → Systemgrenze → konkrete Gegenstände → relevante Eigenschaften und Vorgänge → Klassen und Verantwortlichkeiten → Darstellung, Prüfung und Revision: Dieser Zusammenhang ist auf andere Modellierungsprobleme übertragbar.

Instanzen sind konkret erzeugte Objekte. Der Klassenentwurf Medium wird in tschick : Medium und welle : Medium konkret: Beide Objekte haben eine eigene Identität, eigene Attributwerte und können denselben Vorgang unterschiedlich durchlaufen. Das folgende Beispiel verfolgt tschick vor und nach einer Ausleihe.

// Unvollständiges Fragment: tschick wird im vollständigen Grundmodell erzeugt.
Medium ersteSicht = tschick;
Medium zweiteSicht = ersteSicht;
zweiteSicht.ausleihen();
System.out.println(ersteSicht.istVerfuegbar()); // false

Die beiden Variablen enthalten Referenzen auf dasselbe Objekt. Darum wird die Änderung über zweiteSicht auch über ersteSicht sichtbar. Wie in E3 bleibt eine Variable ein typisierter Speicherplatz für einen Wert; bei einem Referenztyp ist dieser Wert eine Referenz. Die Zuweisung kopiert also den Referenzwert, nicht das Objekt. Deshalb wäre ersteSicht == zweiteSicht wahr: == prüft hier die Identität desselben Objekts. Fachliche Gleichheit kann eine Klasse mit equals definieren; das gezeigte Grundmodell tut dies noch nicht. new Medium(...) erzeugt dagegen eine neue Instanz und ruft ihren Konstruktor auf. Eine Referenzvariable ist nicht das Objekt, sondern ein Zugang zu ihm; sie kann neu gesetzt werden, ohne dass sich dadurch die Identität des bislang referenzierten Mediums ändert. Umgekehrt verändert eine Ausleihe den Zustand des Mediums, nicht seine Identität. Das Objektdiagramm zeigt diese eine konkrete Instanz mit ihren Werten, das Klassendiagramm gleich den möglichen Bauplan, und die Java-Zuweisungen machen sichtbar, welche Referenzen auf die Instanz zeigen.

Die Objektkarten zeigen ein wiederkehrendes Muster: Jedes Medium hat einen Titel und einen Verfügbarkeitszustand; jedes kann ausgeliehen oder zurückgegeben werden. Aus gleichartigen Objekten entsteht deshalb der Klassenkandidat Medium. Beim Klassenentwurf wird nicht nur ein Name gewählt: Für jede Klasse wird geklärt, welche Verantwortung sie trägt, welche Attribute dafür nötig sind, welche fachlichen Vorgänge als Methoden sichtbar werden und welcher Konstruktor einen zulässigen Anfangszustand herstellt. Die Klasse bestimmt damit, welche Attribute überhaupt vorkommen dürfen; erst ein konkretes Objekt besitzt für diese Attribute seine eigenen Werte.

Der deklarierte Referenztyp Medium legt fest, welche Objekte zugewiesen werden dürfen und welche öffentlichen Aufrufe beim Übersetzen zugänglich sind. Lokale Variablen und Parameter sind Bindungen für die Dauer einer Methode; ein Attribut gehört dagegen zum länger bestehenden Zustand jedes Mediums. Eine Instanzmethode beschreibt deshalb nicht bloß einen Codeblock: Sie bündelt Verhalten, das ein Empfängerobjekt ausführt, und macht seine Verantwortung über eine nutzbare Schnittstelle zugänglich.

Das Diagramm ist kein Java-Code ohne geschweifte Klammern, sondern der sprachunabhängige Plan des Systems. Es beantwortet die Frage nach Zuständigkeiten und zeigt mit - und +, welche Attribute verborgen und welche Operationen von außen nutzbar sind; der Code legt fest, wie Java diese Zuständigkeiten ausführt. In einer Signatur beschreibt der Parameter, welche Information eine Operation benötigt, und der Rückgabetyp, welches Ergebnis sie liefert. Beim Konstruktor fehlt dieser Rückgabetyp, weil er nicht ein vorhandenes Objekt verarbeitet, sondern dessen erlaubten Anfangszustand erzeugt. Ein Objektdiagramm würde konkrete Werte zeigen, ein Sequenzdiagramm die Nachrichten eines Ausleihvorgangs ordnen.

Ein UML-Modell im Java-Werkzeug fachsprachlich erläutern Einen Klassenentwurf aus einer Anforderung entwickeln Die Struktur im UML-Werkzeug untersuchen

Aus einer Klasse des Diagramms wird nicht automatisch ein fertiges Programm, aber ihr Java-naher Entwurf lässt sich systematisch ableiten: Attribute werden zu Feldern, der Konstruktor übernimmt die geplante Initialisierung, und Methodensignaturen werden zu öffentlichen oder internen Operationen. Eine öffentliche Top-Level-Klasse muss in einer gleichnamigen .java-Datei liegen. Getrennte Dateien stehen deshalb nicht für zerlegten Text, sondern für getrennte Verantwortlichkeiten.

Der Vergleich mit einem E3-nahen Datenbestand beginnt erst an dieser Stelle, weil er eine Implementationsform beurteilt, nicht die Modellentscheidung begründet. Titel, Inventarnummer und Verfügbarkeit können zunächst in parallelen Arrays liegen. Solange jede Bearbeitung dieselben Indexplätze in allen Arrays trifft, lässt sich ein einzelnes Medium finden. Beim Sortieren, Löschen oder Ergänzen muss diese Kopplung jedoch jedes Mal von außen gesichert werden. Ein vertauschter Index verbindet dann etwa einen Buchtitel mit dem Zustand eines Films. Die Klasse ist nicht die technische Reparatur dieser Arrays, sondern die Konsequenz der zuvor getroffenen Entscheidung, Zustand und Verhalten eines Gegenstands gemeinsam zu modellieren.

// Unvollständiges Fragment: E3-Datenausschnitt ohne Klasse und main-Methode.
String[] titel = {"Tschick", "Die Welle"};
String[] inventarNummern = {"B-2048", "F-0312"};
boolean[] verfuegbar = {true, false};

// Der Index 0 beschreibt nur dann ein Medium,
// wenn alle drei Arrays denselben Platz meinen.

Im schulischen Mehrdateienprojekt wird deshalb jede öffentliche Klasse in einer eigenen gleichnamigen Datei geführt: Eine Klasse Medium gehört so in Medium.java; eine spätere Klasse Ausleihe erhält ihre eigene Datei. Main oder eine Testklasse erzeugt und verbindet Objekte und stößt ihr Zusammenspiel an; fachliche Zuständigkeiten liegen in den modellierten Klassen. Beziehungen aus dem UML-Modell werden durch Typverwendung, gespeicherte Referenzattribute und Methodenaufrufe implementiert. Beim Kompilieren werden die Dateien gemeinsam geprüft; die getrennten Dateiregister des Java-Werkzeugs bilden genau diese Projektarchitektur ab. Wie die Methoden intern arbeiten, entscheidet der Entwurf nicht vollständig, sondern erst die Implementation.

Damit wird die aus E4 bekannte Projektarbeit fachlich präzisiert: Aus Projektziel und Produktgrenze werden Modellzweck und Systemgrenze, aus Anforderungen überprüfbare Entscheidungen in UML und Java. Tests und Reviews prüfen Zustandsübergänge sowie Objektzusammenarbeit und können eine begründete Modellrevision auslösen. Klassenverantwortung meint dabei keine menschliche Projektrolle, sondern die Verantwortung eines modellierten Objekttyps.

Das Klassendiagramm hat für Medium einen verborgenen Zustand und eine öffentliche Ausleihoperation vorgesehen. In Java wird daraus kein beliebiges Umschalten einer Variablen: Der Zustand verfuegbar darf nicht von jeder beliebigen Klasse geschrieben werden. Sichtbarkeit und Geheimnisprinzip geben der Klasse Medium die Verantwortung, gültige Übergänge selbst zu prüfen. Die Invariante des kleinen Grundmodells lautet: Ein Medium ist stets entweder verfügbar oder ausgeliehen, und ein Ausleihversuch darf nur aus dem verfügbaren Zustand in den ausgeliehenen führen. Ein pauschaler Setter für verfuegbar wäre deshalb kein gleichwertiger Ersatz: Er würde eine fachliche Regel in eine beliebige Schreiboperation verwandeln.

// Vollständiges Mehrdateienbeispiel für den gekapselten Grundtyp.
// Datei: Medium.java
public class Medium {
  private final String titel;
  private boolean verfuegbar;
  public Medium(String titel) { this.titel = titel; this.verfuegbar = true; }
  public String getTitel() { return titel; }
  public boolean istVerfuegbar() { return verfuegbar; }
  public boolean ausleihen() { if (!verfuegbar) return false; verfuegbar = false; return true; }
  public void zurueckgeben() { verfuegbar = true; }
}

// Datei: MediumTest.java
public class MediumTest {
  public static void main(String[] args) {
    Medium medium = new Medium("Tschick");
    boolean ersteAusleihe = medium.ausleihen();
    boolean zweiteAusleihe = medium.ausleihen();
    System.out.println(ersteAusleihe);
    System.out.println(zweiteAusleihe);
    medium.zurueckgeben();
    System.out.println(medium.istVerfuegbar());
  }
}

Die Ausgabe true, false, true belegt drei Zustände des gleichen Objekts: Die erste Ausleihe gelingt, der zweite Versuch wird tatsächlich ausgeführt und abgewiesen, die Rückgabe stellt die Verfügbarkeit wieder her. Der Rückgabewert macht die kontrollierte Entscheidung nach außen sichtbar, ohne den geschützten Zustand freizugeben. Die öffentliche Methode ist damit nicht nur ein technischer Zugang, sondern die fachliche Schnittstelle der Klasse. Aus dem Code lässt sich der UML-Entwurf wieder zurücklesen: private entspricht dem verborgenen Attribut, die öffentlichen Signaturen den Operationen der Klassenkarte; die konkrete if-Prüfung ergänzt die im Diagramm noch offene Implementierung.

Die if-Prüfung implementiert hier die fachliche Zustandsregel, der logische Operator ! prüft die Verfügbarkeit und die Zuweisung verfuegbar = false verändert den Attributwert. So bleibt die Invariante erhalten. Das UML-Klassendiagramm plant die Operation ausleihen() und ihren Rückgabetyp, nicht aber ihren vollständigen Kontrollfluss; erst der Methodenrumpf legt diese Verarbeitung fest.

Kontrollierte Zustände im Java-Werkzeug erproben Ein UML-Modell aus Java zurückübersetzen

Ein Benutzerkonto kann einem Medium die Nachricht ausleihen() schicken. Der Parameter medium ist dafür eine lokale Bindung des übergebenen Referenzwerts und wird nur für diesen Aufruf benötigt. Er begründet noch keine dauerhafte Beziehung, weil das Konto die Referenz danach nicht als eigenen Zustand speichert. In UML ist dies eine Abhängigkeit: Die gestrichelte Linie zeigt eine vorübergehende Nutzung, keine Assoziation.

// Unvollständiges Fragment: Das Konto nutzt die Referenz nur während dieses Aufrufs.
class Benutzerkonto {
  public boolean leiheAus(Medium medium) { return medium.ausleihen(); }
}

Eine Assoziation entsteht erst, wenn das System eine Beziehung dauerhaft kennen muss. Sobald eine Ausleihe ein Benutzerkonto und ein Medium als Referenzattribute speichert, bleibt die Verbindung nach dem Methodenaufruf bestehen. Die Richtung der Referenz und ein Rollenname machen sichtbar, wer wen kennt. Multiplizitäten präzisieren die fachliche Reichweite und sind nicht dekorativ: In einem reinen Modell der aktuellen Ausleihen gehört jede aktuelle Ausleihe zu genau 1 Konto und genau 1 Medium; ein Konto kann an 0..* Ausleihen beteiligt sein, ein Medium an 0..1 aktiven Ausleihen. Diese letzte Angabe passt, weil das Modell gleichzeitige Doppelverleihungen ausschließt.

Beziehungen im Werkzeug begründen

Eine Aggregation ist eine besondere Assoziation: Die Mediathek bündelt Medien als fachliches Ganzes, die Medien bleiben jedoch eigenständige Gegenstände. Deshalb steht die offene Raute an der Mediathek, und sie behauptet gerade keine gemeinsame Lebensdauer. Jede Aggregation ist eine fachlich qualifizierte Assoziation; nicht jede Assoziation ist eine Aggregation.

Ein Feld von Objekten ist in Java selbst ein Objekt fester Länge; eine Arrayvariable enthält die Referenz auf dieses Feld. Bei Medium[] enthalten seine Elemente jeweils eine Medium-Referenz oder null. Es eignet sich deshalb für die feste Zahl nummerierter Auslageplätze. Eine Liste von Objekten kann dagegen mit dem Bestand wachsen. Auch ArrayList<Medium> ist ein Objekt und verwaltet Referenzen eines festgelegten Typs. Eine ArrayList beweist aber keine Aggregation: Dieselbe Implementation kann je nach Anforderung eine allgemeine Assoziation oder eine Aggregation realisieren.

// Unvollständiges Fragment: Auslage und Bestand speichern Referenzen, die Mediathek kontrolliert ihre Regeln.
private final Medium[] auslagePlaetze;
private final ArrayList<Medium> bestand = new ArrayList<>();

public boolean stelleAus(int platz, Medium medium) {
  if (platz < 0 || platz >= auslagePlaetze.length || auslagePlaetze[platz] != null) return false;
  auslagePlaetze[platz] = medium;
  return true;
}

public boolean nehmeInBestandAuf(Medium medium) {
  if (medium == null || bestand.contains(medium)) return false;
  bestand.add(medium);
  return true;
}

Die Sammlung bleibt gekapselt: Sie prüft vor einer Aufnahme Kapazität und Doppelung, vor einem Zugriff den Index und vor einer Entfernung, ob das Medium tatsächlich enthalten ist. Die Sammlung selbst nach außen zu geben, würde diese Invarianten wieder außerhalb der zuständigen Klasse verlagern.

Eine feste Objektmenge im Werkzeug bearbeiten Eine wachsende Objektmenge im Werkzeug bearbeiten

Die direkte Beziehung zwischen Konto und Medium reicht für die Frage „Wer hat gerade was?“ aus. Sie beschreibt eine Momentaufnahme: Ein Medium ist dort mit höchstens einer aktuellen Ausleihe verbunden. Mit Ausleihdatum und Rückgabefrist entsteht aber ein neuer Sachverhalt: Beide Angaben beschreiben weder das Konto noch das Medium allein, sondern genau ihren gemeinsamen Ausleihvorgang. Die Klasse Ausleihe hält diese Daten deshalb dort zusammen, wo sie fachlich hingehören.

// Unvollständiges Fragment: Die Beziehung besitzt eigene Daten und Referenzen.
class Ausleihe {
  private final Benutzerkonto konto;
  private final Medium medium;
  private final LocalDate ausleihDatum;
  private final LocalDate rueckgabeFrist;
  public boolean istUeberfaellig(LocalDate heute) { /* ... */ }
}

Damit ist die frühere direkte Assoziation nicht rückwirkend falsch. Sie war für eine Momentaufnahme angemessen und wird erst durch die zusätzliche Anforderung zu grob. Im Historienmodell kann ein Medium über die Zeit an 0..* Ausleihvorgängen beteiligt sein; jede einzelne Ausleihe verweist dabei weiterhin auf genau 1 Medium. Zusätzliche Invariante dieses Historienmodells: Gleichzeitig darf höchstens ein Ausleihvorgang für dasselbe Medium aktiv sein. Ausleihdatum und Frist gehören zum einzelnen Vorgang, nicht dauerhaft zum Benutzerkonto und auch nicht zum Medium: Würden sie dort liegen, wären mehrere oder frühere Ausleihen nicht mehr eindeutig zuzuordnen. Die Revision ist deshalb eine begründete Reaktion auf veränderte Anforderungen. Wie in E4 und E5 machen Tests, Review und fachliche Bewertung dabei sichtbar, ob Zustände und Objektzusammenarbeit weiterhin zur Anforderung passen; weitere Anforderungen wie Mahnungen oder Reservierungen würden erneut prüfen lassen, welche Klasse welche Verantwortung tragen soll.

Ein Modell im Werkzeug weiterentwickeln

Der gemeinsame Grundkurs- und Leistungskurs-Grundweg endet vollständig mit Klassen, Kapselung, Objektmengen, Assoziation, Aggregation und Modellrevision. Vererbung, abstrakte Klassen und Polymorphie bilden die anschließende Vertiefung ausschließlich im Leistungskurs. Erst danach stellt sich eine andere Frage: Bücher und Filme sind beide Medien, besitzen den gleichen Titel und durchlaufen dieselben Ausleihregeln. Zugleich benötigen sie unterschiedliche Beschreibungen. Diese gemeinsame fachliche Herkunft rechtfertigt Vererbung; eine zufällige Namensgleichheit würde dafür nicht ausreichen. Ein Benutzerkonto hat zwar Ausleihen und arbeitet mit Medien zusammen, ist aber kein Medium. Die Beziehung bleibt dort eine Hat-ein-Beziehung: Verantwortlichkeit, Ersetzbarkeit und spätere Erweiterungen sprechen gegen ein extends, selbst wenn in beiden Klassen ähnliche technische Angaben vorkommen.

Generalisierung fasst den gemeinsamen Anteil in einer Oberklasse zusammen. Die Unterklassen Buch und Film spezialisieren ihn mit ihren eigenen Daten. Da ein unbestimmtes Medium keine sinnvolle Beschreibung liefern kann, wird Medium in dieser erweiterten Sicht abstrakt. Es ist damit nicht mehr die konkrete Grundklasse des Einstiegs, sondern der gemeinsame Obertyp derselben Mediathek. Vererbung, abstrakte Klasse und Polymorphie ergänzen den abgeschlossenen gemeinsamen Grundweg ausschließlich als Leistungskursvertiefung.

Die Ausleihe bleibt im erweiterten Modell erhalten. Sie kennt den Obertyp Medium und kann deshalb sowohl ein Buch als auch einen Film referenzieren. Beim Erzeugen einer Unterklasse initialisiert super(...) zunächst den gemeinsamen Titel und Ausleihzustand; danach ergänzt der Unterklassenkonstruktor etwa Autor oder Laufzeit. Die Verfeinerung ersetzt das Grundmodell nicht durch ein zweites System, sondern präzisiert die Medienseite seines bestehenden Zusammenhangs.

Strukturentscheidungen im Werkzeug vergleichen Spezialisierungen im Werkzeug implementieren

Überschreiben gibt jeder Unterklasse ihre fachlich passende Beschreibung. Polymorphie erlaubt anschließend, Buch und Film gemeinsam als Medium zu verwalten. Eine Variable, ein Parameter oder ein Listenelement des Obertyps kann eine Referenz auf ein kompatibles Unterklassenobjekt enthalten. Der deklarierte Referenztyp bestimmt, welche Nachricht zulässig ist; das konkrete Objekt bestimmt zur Laufzeit, welche überschriebene Methode antwortet. Diese dynamische Bindung wird erst nützlich, weil die Sammlung nicht wissen muss, welche Medienart sie gerade enthält. Sie ist von der aus E3 bekannten Methodenüberladung zu unterscheiden: Überladung wählt gleichnamige Methoden über verschiedene Parameterlisten, Überschreiben ersetzt die geerbte Instanzmethode einer Unterklasse.

// Vollständiges Mehrdateienbeispiel für die erweiterte Mediensicht.
// Datei: Medium.java
public abstract class Medium {
  private final String titel;
  private boolean verfuegbar = true;
  protected Medium(String titel) { this.titel = titel; }
  public String getTitel() { return titel; }
  public boolean istVerfuegbar() { return verfuegbar; }
  public boolean ausleihen() { if (!verfuegbar) return false; verfuegbar = false; return true; }
  public void zurueckgeben() { verfuegbar = true; }
  public abstract String beschreibung();
}

// Datei: Buch.java
public class Buch extends Medium {
  private final String autor;
  public Buch(String titel, String autor) { super(titel); this.autor = autor; }
  @Override
  public String beschreibung() { return getTitel() + " von " + autor; }
}

// Datei: Film.java
public class Film extends Medium {
  private final int laufzeitMinuten;
  public Film(String titel, int laufzeitMinuten) { super(titel); this.laufzeitMinuten = laufzeitMinuten; }
  @Override
  public String beschreibung() { return getTitel() + " (" + laufzeitMinuten + " Minuten)"; }
}

// Datei: Benutzerkonto.java
public class Benutzerkonto {
  private final String name;
  public Benutzerkonto(String name) { this.name = name; }
  public String getName() { return name; }
  public boolean leiheAus(Medium medium) { return medium.ausleihen(); }
}

// Datei: Ausleihe.java
import java.time.LocalDate;
public class Ausleihe {
  private final Benutzerkonto konto;
  private final Medium medium;
  private final LocalDate ausleihDatum;
  private final LocalDate rueckgabeFrist;
  public Ausleihe(Benutzerkonto konto, Medium medium, LocalDate ausleihDatum, LocalDate rueckgabeFrist) {
    if (!konto.leiheAus(medium)) throw new IllegalStateException("Medium ist nicht verfuegbar");
    this.konto = konto;
    this.medium = medium;
    this.ausleihDatum = ausleihDatum;
    this.rueckgabeFrist = rueckgabeFrist;
  }
  public boolean istUeberfaellig(LocalDate heute) { return heute.isAfter(rueckgabeFrist); }
}

// Datei: Main.java
import java.util.ArrayList;
import java.time.LocalDate;
public class Main {
  public static void main(String[] args) {
    ArrayList<Medium> medien = new ArrayList<>();
    Buch buch = new Buch("Tschick", "Wolfgang Herrndorf");
    medien.add(buch);
    medien.add(new Film("Die Welle", 107));
    for (Medium medium : medien) System.out.println(medium.beschreibung());
    Benutzerkonto konto = new Benutzerkonto("Mara");
    Ausleihe ausleihe = new Ausleihe(konto, buch, LocalDate.of(2026, 7, 1), LocalDate.of(2026, 7, 15));
    System.out.println(ausleihe.istUeberfaellig(LocalDate.of(2026, 7, 16)));
  }
}

Die Schleife muss weder nach Buch noch nach Film unterscheiden. Sie kann auf jedem Element beschreibung() aufrufen, weil diese Methode zum Vertrag des abstrakten Obertyps gehört. Die Ausgabe wird trotzdem konkret: Tschick von Wolfgang Herrndorf stammt aus Buch, Die Welle (107 Minuten) aus Film. Die anschließende Ausleihe arbeitet ebenfalls mit dem Obertyp und hält dennoch das konkrete Buch als dieselbe Referenz fest.

Abstraktes Verhalten im Werkzeug erproben

Ein Interface beschreibt eine Fähigkeit, nicht eine gemeinsame Herkunft. Ein Ausleihbeleg und ein Inventaretikett könnten beide druckbar sein, obwohl sie keine Medienarten sind. Für die Mediathek ist das ein nicht verpflichtender Ausblick über den verbindlichen Q1.1-Kern hinaus: Interface gehört weder zum grundlegenden noch zum erhöhten Q1.1-Pflichtumfang. Solange sich das gemeinsame Verhalten aus der gemeinsamen Herkunft von Medium erklärt, bleibt die abstrakte Oberklasse die klarere Struktur.

Der Modellierungskreislauf schließt sich: Eine Anforderung bestimmt Modellzweck und Systemgrenze; relevante konkrete Objekte werden auf Eigenschaften und Vorgänge reduziert und zu Klassen mit Verantwortlichkeiten klassifiziert. Das UML-Klassendiagramm hält Attribute, Schnittstellen und Beziehungen als Plan fest. Java verteilt diese Entscheidungen auf zusammenwirkende Dateien und ergänzt die Methodenimplementierung. Die aus E5 bekannte Verifikation fachlicher Routinen erweitert sich damit auf Objektzustände und Objektzusammenarbeit; Tests machen sichtbar, ob die Zustandsregeln und das Zusammenspiel der Objekte zum Modell passen.

Dieses Modell beantwortet nicht jede denkbare Frage einer realen Bibliothek. Gerade deshalb kann es erweitert werden, ohne seine bisherigen Entscheidungen zu verleugnen: Eine Reservierung, Mahnung oder abweichende Frist wäre eine neue Anforderung, die wieder Anforderung, UML und Java gegeneinander prüfen lässt. Sichtbare Verantwortlichkeiten, eine begründete Systemgrenze und nachvollziehbare Beziehungen sorgen dafür, dass diese Revision nicht den ganzen Bestand umwerfen muss. Das Modell ist tragfähig, weil es seine Grenzen und den Anlass jeder Überarbeitung erkennen lässt.

Einen vollständigen Modellierungszusammenhang im Werkzeug bearbeiten Das zusammenhängende Modell im UML-Werkzeug weiterdenken