Q1.1 – Objektorientierte Modellierung als Systemaufbau

A) Allgemeine Einordnung

Q1.1 führt in die objektorientierte Modellierung ein: Lernende entwickeln aus konkreten Hofladen-Objekten ein tragfähiges Klassensystem und verbinden fachliche Anforderungen mit UML-gestützter Strukturarbeit.

B) Anforderungen nach Kursniveau

Problem / fachliche Situation

Die App des Hofladens soll nicht nur Produkte auflisten, sondern zu jeder Ware die passenden Informationen liefern: Name und Preis immer, weitere Daten nur bei bestimmten Warentypen (z. B. MHD, Reifezeit, Frische).

Modellentscheidung

Wir entwickeln ein durchgehendes Warenmodell für Apfel, Milch, Käse, Brot und Wurst. Die Leitfrage lautet: Welche Eigenschaften sind gemeinsam, welche spezifisch, und welche Zuständigkeit hat jede Klasse im späteren System?

Im Hofladen tauchen Apfel, Milch und Käse zunächst genau als solche konkreten Objekte mit eigenen Zustandswerten auf.

Die spätere Klassenbildung entsteht hier aus der Beobachtung, dass viele Objekte im Diagramm dieselbe Grundstruktur teilen.

Damit wird der Hofladen nicht Kulisse, sondern Treiber aller Modellschritte. Aus dem Beispiel entsteht eine klare Entwicklungslogik: Objektbeschreibung, Klassenbildung, Redundanzanalyse, Vererbung, Polymorphie und Abstraktion.

Problem / fachliche Situation

Einzelne Waren sind leicht zu beschreiben. Für das Gesamtsystem bleibt aber offen, wie viele ähnliche Instanzen konsistent verwaltet werden sollen.

Modellentscheidung

Wir beginnen mit konkreten Objektbeschreibungen und markieren die wiederkehrenden Kerndaten als Vorbereitung für eine belastbare Klassenbildung.

Die Diagramm-Sicht macht den Übergang vom Einzelfall zur Typbildung sichtbar: Gleiche Muster wiederholen sich über mehrere Produkte hinweg.

Diese Klassenkarten nutzen dieselbe Klassenbox- und Typografie-Logik wie der UML-Klassendiagramm-Editor: Klassenname oben, getrennte Bereiche für Strukturinhalte und die gleiche visuelle Leselogik.

Im Diagramm sind die drei gezeigten WareObjekt-Karten konkrete Instanzen mit jeweils eigenen Werten.

Die Einträge name, preis und später mhd sind im Hofladenmodell genau diese Zustandsattribute.

Die Objektansicht macht den Hofladen anschaulich, liefert aber noch keinen stabilen Bauplan. Weil sich Muster wiederholen, wechseln wir jetzt in die Klassenperspektive.

Problem / fachliche Situation

Wie entstehen Klassen fachlich sinnvoll aus ähnlichen Objekten – und was passiert, wenn jede Ware als eigene, isolierte Klasse modelliert wird?

Modellentscheidung

Wir bilden zunächst getrennte Klassen (Apfel, Milch, Kaese, Brot, Wurst) und prüfen diese Struktur bewusst kritisch auf Redundanz und Zuständigkeit.

Die Klassen sind als Baupläne klarer als reine Objekte, erzeugen aber noch Codeduplizierung in Attributen und Methoden.

Die Methoden getPreis() und getName() tauchen in mehreren Warenklassen auf und zeigen die wiederholte Basislogik.

Wenn im Hofladen eine neue Milch- oder Kaese-Instanz angelegt wird, übernimmt der Konstruktor die Initialisierung von Name, Preis und Produktspezifika.

Genau diese Sicht macht im gezeigten Diagramm die doppelt modellierten Basisattribute sofort als Entwurfsproblem sichtbar.

Konvention wie im UML-Werkzeug: Sichtbarkeit wird direkt vor Attributen/Methoden notiert (- privat, # protected, + öffentlich). So ist im Diagramm sofort lesbar, welche Elemente intern bleiben und welche von außen nutzbar sind.

Die Klassenbildung ist ein Fortschritt gegenüber Einzelobjekten, aber noch nicht wirtschaftlich: gleiche Grundlogik liegt verteilt in vielen Klassen. Genau daraus entsteht der Bedarf nach Vererbung.

Problem / fachliche Situation

Klassen existieren nicht isoliert: Kundinnen, Warenkörbe und Waren stehen in fachlichen Beziehungen. Diese Grundlagen sollen vor Vererbung geklärt werden.

A) Assoziation

class Kunde {
  private String name;

  public void waehleWare(Ware ware) {
    System.out.println(name + " wählt " + ware.getName());
  }
}

Damit wird die Assoziation fachlich konkret: Kunde kennt ausgewählte Ware-Objekte für den Kaufprozess, ohne Besitzstruktur zu modellieren.

B) Aggregation

class Warenkorb {
  private final List<Ware> positionen = new ArrayList<>();

  public void add(Ware ware) { positionen.add(ware); }
  public List<Ware> getPositionen() { return positionen; }
}

Der Warenkorb aggregiert Warenpositionen für den Vorgang, die Ware-Objekte können aber auch außerhalb des Warenkorbs weiter existieren (z. B. im Sortiment).

Modellentscheidung

public class Ware {
  private String name;
  private double preis;

  public String getName() { return name; }
  public void setPreis(double neuerPreis) {
    if (neuerPreis >= 0) preis = neuerPreis;
  }
}

So bleiben interne Daten geschützt; Zugriff erfolgt über klar definierte get-/set-Methoden statt über direkte Außenmanipulation.

1) Redundanzproblem

Änderungen an gemeinsamen Daten und Methoden müssten sonst in vielen Klassen parallel gepflegt werden. Das erhöht Fehleranfälligkeit und Wartungsaufwand.

2) Codebeispiel

public class Ware {
  protected String name;
  protected double preis;

  public double getPreis() { return preis; }
}

public class Kuehlware extends Ware {
  protected LocalDate mhd;

  public boolean istHaltbar() {
    return !mhd.isBefore(LocalDate.now());
  }
}

5) Kurze Erklärung: Die Unterklasse bekommt die gemeinsame Grundstruktur der Oberklasse und ergänzt nur ihre Besonderheiten.

A) Mehrstufige Hierarchie

Wir präzisieren die Hierarchie: Ware als Oberbegriff, darunter Kuehlware und Brotware, erst danach konkrete Klassen wie Milch, Kaese, Wurst und Brot.

B) Verhalten in Hierarchien

public class Brot extends Brotware {
  @Override
  public double berechneEndpreis() {
    return istFrisch() ? preis : preis * 0.7;
  }
}

public class Kaese extends Kuehlware {
  @Override
  public double berechneEndpreis() {
    return istHaltbar() ? preis : preis * 0.5;
  }
}

Methodenvererbung: Grundmethoden kommen aus Ware und stehen allen Unterklassen zur Verfügung.

Fachlicher Unterschied: Vererbung sichert gemeinsame Basislogik, Überschreiben liefert je Unterklasse das passende Spezialverhalten.

C) Felder und Listen von Objekten

Ware[] tagesangebot = { new Brot(), new Milch(), new Kaese() }; // feste Länge
List<Ware> warenkorb = new ArrayList<>();                     // dynamische Länge
warenkorb.add(new Brot());
warenkorb.add(new Kaese());

Objektmengen nutzen damit direkt die aufgebaute Hierarchie: Ein gemeinsamer Obertyp Ware trägt verschiedene konkrete Warenobjekte in einem Modell.

List<Ware> warenkorb = List.of(new Brot(), new Kaese(), new Milch());
for (Ware ware : warenkorb) {
  System.out.println(ware.berechneEndpreis());
}

Didaktischer Gewinn: Der Code bleibt bei der Verarbeitung von Objektmengen allgemein (Ware), das Laufzeitverhalten bleibt trotzdem konkret je Unterklasse fachlich korrekt.

public abstract class Ware {
  protected String name;
  protected double preis;

  public abstract double berechneEndpreis();
}

UML-Konvention: Abstrakte Klasse in kursiver Schrift oder mit <<abstract>>; abstrakte Methoden ebenfalls kursiv.

Abgrenzung zur allgemeinen Vererbung: Vererbung allein beschreibt nur die Strukturweitergabe. Die abstrakte Klasse legt zusätzlich verbindlich fest, dass bestimmte Methoden erst in Unterklassen konkret implementiert werden müssen.

public interface QrInfo {
  String qrText();
  String detailTitel();
}

public class Brot extends Brotware implements QrInfo {
  @Override
  public String qrText() { return name + " | " + berechneEndpreis(); }
}

UML-Konvention: Kennzeichnung mit <<interface>>, Umsetzung über gestrichelte Linie mit Pfeil zur Schnittstelle.

Fachlicher Unterschied zur Vererbung: Vererbung modelliert gemeinsame Herkunft („ist-eine“-Beziehung), ein Interface modelliert gemeinsame Fähigkeit („kann-etwas“-Beziehung) über verschiedene Klassen hinweg.

Der Lernweg folgt nun der gestuften Progression: Grundlagen (Objekt/Klasse) → erste Strukturbeziehungen (Assoziation/Aggregation) → Vererbung und Hierarchie → Verhalten und Objektmengen → Spezialfälle (Polymorphie, abstrakte Klasse, Interface).

Modell im UML-Werkzeug weiterentwickeln

Bereits angebundene Glossarbegriffe

Diese Seite nutzt verlinkte Begriffe aus dem Glossar konsistent im Modellverlauf: Objekt, Klasse, Attribut, Methode, Geheimnisprinzip, Sichtbarkeit, UML-Klassendiagramm, Vererbung, Generalisierung, Assoziation und Aggregation.

Für Glossar-Erweiterung vorgemerkt

Die folgenden Kapitelbegriffe sind in Q1.1 bereits fachlich vorbereitet und sollten im Glossar ergänzt oder geschärft werden: Instanz, Konstruktor, Oberklasse, Unterklasse, Spezialisierung, Überschreiben, Polymorphie, Interface/Schnittstelle, Feld von Objekten, Liste von Objekten, Typ, Hierarchie und Zuständigkeit.

Hinweis zur Progression: Die Begriffspaare Feld/Liste von Objekten sowie Assoziation/Aggregation werden jetzt im fachlichen Hauptverlauf eingeführt und nicht erst als Nachtrag.