Notizen · InformatikDE · Abitur

Objektorientierte Modellierung, Programmierung und Softwareentwicklung

Klassen, Objekte, Vererbung, Polymorphie und UML-Klassendiagramme bilden das didaktische Rückgrat der Oberstufeninformatik. Die KMK EPA verlangt sowohl Modellierung (UML/CRC) als auch Implementation (Java/Python) sowie eine Reflexion über Phasenmodelle der Softwareentwicklung.

6Abschnitteca. 18Min Lesezeit3KompetenzenNiveauBasis 1 · Standard 4 · Vertiefung 1Stand 06/2026

T·0222 / 8

Prüfungsprofil

KB-MI · Modellieren und Implementieren — Klassenstrukturen entwerfen und in OOP-Sprachen umsetzen.KB-SD · Strukturieren und Darstellen — UML-Klassen-, Objekt- und Sequenzdiagramme lesen und erstellen.KB-KK · Kommunizieren und Kooperieren — Softwareprojekte in Teams strukturieren (Versionierung, Reviews).

Operatoren:analysierenmodellierenimplementierenbeurteilendarstellen

grundlegendes Niveau

gA: Klassen mit Attributen und Methoden modellieren, einfache Vererbungshierarchien implementieren, UML-Klassendiagramm lesen und ergänzen.

erhöhtes Niveau

eA: Polymorphie und dynamisches Binden begründen, Mehrfachvererbung (Interface) diskutieren, Entwurfsmuster (Observer, Strategy, Singleton) erkennen und anwenden, Phasenmodelle (V-Modell, Scrum) gegenüberstellen.

Tiefe

Schrift

Inhalt · 6 Abschnitte

Objektorientierte Modellierung, Programmierung und Softwareentwicklung

Klassen, Objekte, Attribute und Methoden#

BasisKMK-EPA-Inf-ModellierenNRW-IF2BY-Inf-3

Die objektorientierte Programmierung (OOP) modelliert ein System als Menge zusammenwirkender Objekte, die Daten und Verhalten bündeln. Eine Klasse ist dabei der Bauplan — sie legt fest, welche Attribute und Methoden alle ihre Objekte besitzen —, ein Objekt ist eine konkrete, zur Laufzeit mit `new` erzeugte Instanz mit eigenem Zustand. Dieselbe Klasse `Konto` kann beliebig viele Objekte hervorbringen, deren Salden sich unabhängig voneinander ändern.

Ein Objekt hat Attribute (Felder), die seinen Zustand beschreiben, und Methoden, die sein Verhalten definieren. Beim Erzeugen initialisiert ein Konstruktor das Objekt in einen gültigen Anfangszustand; er trägt den Klassennamen, hat keinen Rückgabetyp und kann überladen werden. Der Konstruktor ist klar vom Setter zu trennen: Er erzeugt ein Objekt, während ein Setter ein bereits bestehendes Objekt nur verändert.

Das tragende Prinzip ist die Kapselung (Datenkapselung): Attribute werden `private` deklariert, der Zugriff erfolgt ausschließlich über öffentliche Methoden — Getter/Setter oder fachliche Operationen wie `einzahlen`. Das schützt die Invarianten des Objekts (ein Setter kann etwa negative Salden ablehnen), entkoppelt die öffentliche Schnittstelle von der internen Implementation und hält spätere Änderungen lokal — der Kern des „information hiding" (Parnas 1972).

Java-Skelett: ```java public class Konto { private double saldo; public Konto(double start) { this.saldo = start; } public void einzahlen(double b) { this.saldo += b; } public double getSaldo() { return this.saldo; } } ```

Zu unterscheiden sind Instanz- und Klassenebene: Instanz-Felder und -Methoden gehören jedem Objekt einzeln, statische Felder und Methoden (`static`) gehören der Klasse als Ganzem und existieren nur einmal — etwa die Konstante `Math.PI` oder ein Zähler aller erzeugten Objekte. Statische Methoden besitzen kein `this`, weil sie an kein konkretes Objekt gebunden sind.

Das Schlüsselwort `this` referenziert innerhalb einer Methode das aktuelle Objekt und löst Namenskonflikte zwischen Parametern und Feldern auf (`this.saldo = saldo`). In Python übernimmt das ausdrücklich als erstes Methodenargument geführte `self` dieselbe Rolle. Der Aufruf einer Instanzmethode (`konto.einzahlen(50)`) wirkt stets auf genau das Objekt vor dem Punkt.

Typische Fehler

Klasse und Objekt verwechselt: „Die Klasse Konto hat einen Saldo von 100 €" — falsch, der Saldo gehört dem Objekt.
Direkter Zugriff auf private Felder (über Default-Sichtbarkeit oder Reflection) — verletzt die Kapselung und ihre Invarianten.
`this` in einer statischen Methode verwendet — Compilerfehler, da kein Objektbezug existiert.
Konstruktor mit Rückgabetyp deklariert — dann ist es eine gewöhnliche Methode, kein Konstruktor mehr.

LK-Vertiefung

eA-Vertiefung: Erläutern Sie das Prinzip „information hiding" (Parnas 1972) und beurteilen Sie an der Klasse `Konto`, wie eine gekapselte Invariante (z. B. Saldo ≥ Dispolimit) durch private Felder und prüfende Methoden erzwungen wird, die ein direkter Feldzugriff aushebeln würde.

Aktive Wiederholung

Modellieren Sie eine Klasse `Bibliothek` mit Attributen und Methoden für das Ausleihen und Zurückgeben von Büchern; geben Sie das UML-Klassendiagramm und eine Java-Implementation an.

Aktiv abrufen

Erinnere dich an die Kernpunkte — dann aufdecken.

Vererbung, Polymorphie und dynamisches Binden#

StandardKMK-EPA-Inf-ModellierenNRW-IF2BY-Inf-3

UML-Klassendiagramm — Vererbung Tier → Hund

Abb. 1Tier (abstrakt) wird von Hund spezialisiert; offene Pfeilspitze zeigt zur Oberklasse, Bezeichner kursiv für abstrakte Methoden.

Die Vererbung (`extends`) etabliert eine Ist-ein-Beziehung: Die Unterklasse (Subklasse) erbt alle nicht-privaten Attribute und Methoden der Oberklasse (Superklasse), kann eigene ergänzen und geerbte Methoden überschreiben (`@Override`). So entsteht eine Spezialisierungshierarchie (`Hund` ist ein `Tier`), die gemeinsamen Code an einer Stelle bündelt. Der Unterklassen-Konstruktor muss zuvor den Oberklassen-Konstruktor aufrufen (`super(...)`), damit der geerbte Teil korrekt initialisiert wird.

Die Polymorphie (Vielgestaltigkeit) bedeutet, dass derselbe Methodenaufruf je nach dynamischem Typ des Objekts unterschiedliches Verhalten zeigt. Möglich macht das die dynamische Bindung (late binding): Welche Implementierung läuft, entscheidet die JVM zur Laufzeit anhand des tatsächlichen Objekttyps — nicht der Compiler anhand des deklarierten Typs (statische Bindung). Eine Variable vom statischen Typ `Tier`, die auf ein Objekt vom dynamischen Typ `Hund` zeigt, ruft daher `Hund#lautGeben` auf.

Eine abstrakte Klasse (`abstract`) kann nicht instanziiert werden und dient als gemeinsame Oberklasse; sie darf abstrakte Methoden (nur Signatur, kein Rumpf) deklarieren, die jede konkrete Unterklasse implementieren muss, und zugleich konkrete Methoden sowie Zustand (Felder) mitbringen. Sie eignet sich, wenn verwandte Klassen Code und Daten teilen sollen.

Ein Interface (`interface`) definiert dagegen einen reinen Verhaltensvertrag ohne Objektzustand (klassisch: nur Methodensignaturen). Eine Klasse kann mehrere Interfaces implementieren — Javas pragmatische Antwort auf die fehlende Mehrfachvererbung von Klassen. Faustregel: Vererbung bzw. abstrakte Klasse modelliert „ist ein und teilt Implementierung", ein Interface modelliert „kann etwas / erfüllt einen Vertrag".

Beispiel Polymorphie: ```java Tier t = new Hund("Rex"); System.out.println(t.lautGeben()); // ruft Hund#lautGeben → "Wuff" ```

Damit Polymorphie tragfähig bleibt, muss das Liskov-Substitutionsprinzip (LSP, Barbara Liskov 1987) gelten: Ein Objekt der Unterklasse muss überall einsetzbar sein, wo die Oberklasse erwartet wird, ohne deren Vertrag zu verletzen (keine verschärften Vor-, keine abgeschwächten Nachbedingungen). Zu trennen sind außerdem Überschreiben (Overriding: gleiche Signatur, neues Verhalten in der Unterklasse, dynamisch gebunden) und Überladen (Overloading: mehrere Methoden gleichen Namens mit verschiedener Signatur, statisch gebunden). Wo keine echte Ist-ein-Beziehung vorliegt, ist Komposition der Vererbung vorzuziehen („favor composition over inheritance").

Musterlösung

Polymorphismus mit abstrakter Klasse Tier

Implementieren Sie in Java eine abstrakte Klasse Tier mit abstrakter Methode lautGeben() und eine konkrete Unterklasse Hund. Demonstrieren Sie polymorphen Methodenaufruf.

Schritt 1 — Abstrakte Klasse
```java abstract class Tier { protected String name; public Tier(String name) { this.name = name; } public abstract String lautGeben(); } ```
Schritt 2 — Konkrete Unterklasse
```java class Hund extends Tier { public Hund(String name) { super(name); } @Override public String lautGeben() { return name + " bellt: Wuff!"; } } ```
Schritt 3 — Polymorphe Verwendung
```java Tier t = new Hund("Bello"); System.out.println(t.lautGeben()); // dynamic dispatch ```
Schritt 4 — Interpretation
Die Variable t hat statischen Typ Tier, dynamischen Typ Hund. Zur Laufzeit wird Hund.lautGeben() aufgerufen — dynamische Bindung. Late Binding ist Grundprinzip der OOP.

Ergebnis: Polymorphismus über Vererbung und @Override; der Methodenaufruf wird zur Laufzeit aufgelöst.

Typische Fehler

Vererbung als bloße Code-Wiederverwendung missbraucht, wo Komposition angemessen wäre („favor composition over inheritance").
Überschreiben und Überladen verwechselt: Override ersetzt Verhalten in der Unterklasse, Overload bietet mehrere Signaturen in derselben Klasse.
`super(...)` im Unterklassen-Konstruktor vergessen — Compilerfehler, wenn die Oberklasse keinen parameterlosen Konstruktor hat.
Bindung verwechselt: angenommen, der deklarierte (statische) Typ entscheide über die Methode — tatsächlich der dynamische.

LK-Vertiefung

eA-Vertiefung: Beurteilen Sie das LSP an einem Counter-Beispiel (Rechteck/Quadrat) und schlagen Sie eine alternative Modellierung vor.

Aktive Wiederholung

Modellieren Sie eine Vererbungshierarchie `Fahrzeug → Auto, Fahrrad`; implementieren Sie eine abstrakte Methode `geschwindigkeit()` und demonstrieren Sie dynamisches Binden.

Aktiv abrufen

Erinnere dich an die Kernpunkte — dann aufdecken.

UML-Klassendiagramme, Beziehungen und CRC-Karten#

StandardKMK-EPA-Inf-StrukturierenNRW-IF2BY-Inf-3

UML-Klassendiagramm — Vererbung Tier → Hund

Abb. 2Tier (abstrakt) wird von Hund spezialisiert; offene Pfeilspitze zeigt zur Oberklasse, Bezeichner kursiv für abstrakte Methoden.

Die Unified Modeling Language (UML 2) ist die standardisierte grafische Notation für Softwaremodelle; das Klassendiagramm zeigt die statische Struktur. Jede Klasse erscheint als Dreifach-Rechteck mit drei Fächern: Klassenname (oben), Attribute (Mitte), Methoden (unten). Es ist das wichtigste Diagramm der Oberstufe, weil sich jedes Fach direkt in Java-Code übersetzt — Modellierung und Implementierung greifen hier ineinander.

Vor jedem Merkmal steht ein Sichtbarkeitszeichen: `+` public, `−` private, `#` protected, `~` package. Attribute notiert man als `sichtbarkeit name : Typ`, Methoden als `sichtbarkeit name(Parameter) : Rückgabetyp`. Konventionen: Klassennamen sind großgeschriebene Substantive im Singular, Methodennamen kleingeschriebene Verben; `private` Attribute und `public` Methoden sind der Regelfall (Kapselung).

Die Beziehungstypen sind das prüfungskritische Herzstück und unterscheiden sich durch Pfeil- und Rautenform: Assoziation (einfache Linie, „kennt/nutzt"), Aggregation (offene, leere Raute an der Ganzes-Seite, lose Teil-Ganzes-Beziehung — das Teil existiert unabhängig), Komposition (gefüllte Raute, starke Teil-Ganzes-Beziehung — das Teil stirbt mit dem Ganzen), Vererbung/Generalisierung (offene Dreieckspitze zur Oberklasse) und Realisierung (gestrichelter Pfeil mit Dreieckspitze, „Klasse implementiert Interface").

An den Enden einer Assoziation stehen Multiplizitäten (Kardinalitäten): `1` (genau eins), `0..1` (höchstens eins), `` bzw. `0..` (beliebig viele), `1..` (mindestens eins). Sie werden am Ende der Gegenseite notiert — „ein Kunde hat viele Bestellungen" trägt das `` am Bestellungs-Ende und die `1` am Kunden-Ende. Eine n:m-Assoziation wird bei der Umsetzung in eine eigene Verbindungsklasse aufgelöst (Brücke zum Datenbank-Topic).

Als Vorstufe der Teammodellierung dienen CRC-Karten (Class–Responsibility–Collaboration): Jede Karteikarte trägt den Klassennamen, ihre Verantwortlichkeiten (was sie wissen und tun muss) und ihre Kollaborateure (welche anderen Klassen sie dafür braucht). Sie helfen, Verantwortung sinnvoll zu verteilen, bevor ein formales Diagramm entsteht.

Das Klassendiagramm zeigt nur die statische Struktur; den zeitlichen Ablauf ergänzen Sequenz- und Zustandsdiagramme (eigener Abschnitt „Dynamische Modellierung"). Erst beide Sichten zusammen — Struktur und Verhalten — modellieren ein System vollständig.

Musterlösung

Vom Anwendungsfall zum UML-Klassendiagramm

Modellieren Sie für eine Bibliotheksverwaltung ein UML-Klassendiagramm: Ein Leser kann mehrere Bücher gleichzeitig ausleihen, jedes Buch ist höchstens einem Leser zugeordnet. Geben Sie Klassen, Sichtbarkeiten, Multiplizitäten und eine Java-Skizze an.

Schritt 1 — Substantive als Klassenkandidaten
Aus der Beschreibung ergeben sich die Klassen Leser und Buch. Verben (ausleihen, zurückgeben) werden zu Methoden.
Schritt 2 — Attribute und Sichtbarkeiten festlegen
Leser: - leserNr:int, - name:String. Buch: - isbn:String, - titel:String, - ausgeliehen:boolean. Attribute private (−), Methoden public (+).
Schritt 3 — Beziehung und Multiplizität
Assoziation „leiht aus": Leser 0..1 ── 0..* Buch (ein Leser, viele Bücher; jedes Buch höchstens einem Leser, also 0..1, da ein nicht ausgeliehenes Buch keinem Leser zugeordnet ist). Eine Aggregation ist hier unpassend, da Bücher unabhängig vom Leser existieren.
Schritt 4 — Java-Skizze
```java class Leser { private int leserNr; private String name; private List<Buch> ausgeliehen = new ArrayList<>(); public void ausleihen(Buch b) { ausgeliehen.add(b); } } class Buch { private String isbn, titel; private boolean ausgeliehen; } ```

Ergebnis: Zwei Klassen mit 0..1-zu-0..*-Assoziation; Sichtbarkeiten und Multiplizitäten konsistent zwischen UML und Java.

Typische Fehler

Aggregation mit gefüllter Raute gezeichnet — gefüllt bedeutet Komposition.
Vererbungspfeil mit Assoziationslinie verwechselt; UML-Vererbung hat eine offene Dreieckspitze zur Oberklasse.
Multiplizitäten am falschen Ende notiert — „1 Schüler hat * Kurse" mit vertauschten Enden.
Realisierung (gestrichelt, Interface) mit Vererbung (durchgezogen, Klasse) verwechselt.

LK-Vertiefung

eA-Vertiefung: Begründen Sie an je einem Beispiel (Auto–Motor vs. Universität–Studentin/Student), warum die eine Beziehung eine Komposition, die andere eine Aggregation ist, und leiten Sie aus den Multiplizitäten die Umsetzung einer n:m-Assoziation in eine Verbindungsklasse her.

Aktive Wiederholung

Stellen Sie für ein Online-Shop-Modell mit Klassen `Kunde`, `Bestellung`, `Artikel` ein vollständiges UML-Klassendiagramm mit Multiplizitäten, Sichtbarkeiten und mindestens einer Aggregation auf.

Aktiv abrufen

Erinnere dich an die Kernpunkte — dann aufdecken.

Entwurfsmuster und Softwarequalität#

VertiefungNRW-IF2BY-Inf-3BW-Inf-4

Ein Entwurfsmuster (Design Pattern) ist eine bewährte, sprachunabhängige Schablone für ein wiederkehrendes Entwurfsproblem — kein fertiger Code, sondern eine benannte strukturelle Lösungsidee. Der Begriff geht auf die „Gang of Four" (Gamma, Helm, Johnson, Vlissides, 1994) zurück, die 23 Muster in erzeugende, strukturelle und verhaltensbezogene Kategorien ordnete. Muster geben Teams ein gemeinsames Vokabular und machen Entwürfe besprechbar.

Das Singleton (erzeugend) garantiert, dass von einer Klasse genau eine Instanz existiert, und bietet einen globalen Zugriffspunkt (privater Konstruktor plus statische `getInstance`-Methode). Es ist nützlich für zentrale Ressourcen (Logger, Konfiguration), gilt aber als kritisch: Es führt globalen, veränderlichen Zustand ein, erschwert Tests (schwer ersetzbar) und verbirgt Abhängigkeiten — oft ein Anti-Pattern, wenn es nur „überall erreichbar" meint.

Das Observer-Muster (verhaltensbezogen) entkoppelt ein Subjekt von seinen Beobachtern: Ändert sich der Zustand des Subjekts, benachrichtigt es automatisch alle registrierten Beobachter, ohne sie konkret zu kennen. Es ist die Grundlage von MVC, Event-Systemen und reaktiven Oberflächen; vom Publish-Subscribe unterscheidet es sich dadurch, dass dort ein Vermittler (Broker) Sender und Empfänger vollständig trennt.

Das Strategy-Muster kapselt austauschbare Algorithmen hinter einer gemeinsamen Schnittstelle, sodass der Client den Algorithmus zur Laufzeit wechseln kann (Komposition statt Vererbung) — es verbindet die OOP-Struktur direkt mit der algorithmischen Variation des Algorithmen-Topics (z. B. wählbare Sortierverfahren). Die Factory Method (erzeugend) delegiert die Objekterzeugung an Unterklassen und entkoppelt den Client von konkreten Klassen.

Die SOLID-Prinzipien (Robert C. Martin) bündeln die Leitlinien guten OO-Designs: Single Responsibility (eine Klasse, ein Grund zur Änderung), Open/Closed (offen für Erweiterung, geschlossen für Änderung), Liskov-Substitution, Interface Segregation (schlanke, spezifische Schnittstellen) und Dependency Inversion (Abhängigkeit von Abstraktionen statt Konkretem). Entwurfsmuster sind oft konkrete Wege, diese Prinzipien einzuhalten.

Muster sind Werkzeuge, kein Selbstzweck: Ihr unreflektierter Einsatz erhöht die Komplexität, statt sie zu senken. Eine tragfähige Begründung benennt das konkrete Problem, das ein Muster löst, und zeigt die strukturelle Beziehung im UML — nicht bloß den Musternamen.

Typische Fehler

Entwurfsmuster nur namentlich genannt, ohne die strukturelle Beziehung im UML zu zeigen.
Singleton überall eingesetzt — Anti-Pattern wegen global zugänglicher Veränderlichkeit.
Strategy mit Template Method verwechselt — Template Method nutzt Vererbung, Strategy Komposition.
SOLID als bloße Schlagwortliste wiedergegeben, statt ein Prinzip am Beispiel anzuwenden.

LK-Vertiefung

eA-Vertiefung: Beurteilen Sie das Open/Closed-Prinzip am Beispiel einer Klasse `Steuerberechner` und zeigen Sie, wie das Strategy-Muster Erweiterbarkeit fördert.

Aktive Wiederholung

Modellieren Sie eine Sortier-Anwendung mit Strategy-Muster, sodass zur Laufzeit zwischen Insertion- und Mergesort gewechselt werden kann; geben Sie UML und Java-Skelett an.

Aktiv abrufen

Erinnere dich an die Kernpunkte — dann aufdecken.

Phasenmodelle, Versionierung und Testen#

StandardNRW-IF2BY-Inf-3KMK-EPA-Inf-Kommunizieren

Software-Engineering: Wasserfall- vs. Scrum-Vorgehensmodell

Abb. 3Wasserfall sequenziell; Scrum iterativ-inkrementell mit zweiwöchigen Sprints und Backlog.

Softwareentwicklung folgt einem Vorgehensmodell, das die Tätigkeiten Analyse, Entwurf, Implementierung, Test und Wartung ordnet. Das Wasserfallmodell durchläuft diese Phasen streng sequenziell und dokumentationsstark — klar, aber unflexibel gegenüber späten Änderungen. Das V-Modell klappt den Wasserfall zu einem V: Jeder konstruktiven Phase (links absteigend) steht eine Teststufe gegenüber (rechts aufsteigend) — der Komponentenentwurf wird durch Unit-Tests, die Architektur durch Systemtests, die Anforderungen durch Abnahmetests geprüft.

Die agilen Modelle begegnen dem Hauptschwachpunkt der Wasserfallmodelle — dem schlechten Umgang mit Änderungen — durch iterativ-inkrementelles Vorgehen. Scrum liefert in kurzen Sprints (z. B. zwei Wochen) lauffähige Inkremente und organisiert die Arbeit über Product- und Sprint-Backlog sowie feste Rollen und Events (Product Owner, Scrum Master, Daily Stand-up, Review, Retrospektive). Kanban setzt auf kontinuierlichen Fluss mit Work-in-Progress-Limits statt fester Sprints. Agil heißt nicht „planlos", sondern „Planung in kurzen Zyklen".

Die Versionsverwaltung (typisch Git, verteilt) hält die Entwicklungsgeschichte fest und ermöglicht paralleles Arbeiten: Ein Commit speichert einen Stand, ein Branch ist eine abzweigende Entwicklungslinie, Merge führt Linien zusammen, ein Pull-/Merge-Request stellt Änderungen zur Überprüfung (Code Review). Klar zu trennen sind Branch (eine Zeigerverschiebung im selben Repository) und Fork (eine eigene Kopie des gesamten Repositories).

Tests sind nach Granularität gestaffelt: Unit-Tests prüfen einzelne Methoden/Klassen isoliert (JUnit, pytest), Integrationstests das Zusammenspiel von Modulen, Systemtests die Anwendung als Ganzes (End-to-End) und Abnahmetests die Erfüllung der Anforderungen aus Anwendersicht. Diese Stufen entsprechen genau der rechten Seite des V-Modells.

Die Testüberdeckung misst, wie viel Code die Tests ausführen — Anweisungs-, Zweig- und Pfadüberdeckung in steigender Strenge. Hohe Überdeckung garantiert nicht automatisch Qualität, da sie nichts über die Sinnhaftigkeit der Prüfungen aussagt. Beim testgetriebenen Entwickeln (TDD) wird der Test zuerst geschrieben und dann der Code, der ihn erfüllt — Test zuerst, nicht hinterher.

Die kontinuierliche Integration (Continuous Integration) lässt bei jedem Commit automatisch Build und Tests laufen (z. B. GitHub Actions, GitLab CI) und meldet Fehler sofort; Continuous Delivery/Deployment erweitert dies bis zur automatisierten Auslieferung. So bleiben Integrationsprobleme klein und früh sichtbar — eine technische Grundlage agilen Arbeitens.

Typische Fehler

Scrum als „kein Plan" missverstanden — tatsächlich ein strenges Rahmenwerk mit Rollen und Events.
Branch und Fork verwechselt — der Fork kopiert das Repository, der Branch verschiebt nur einen Zeiger.
TDD als „Tests nach dem Code" beschrieben — TDD verlangt den Test zuerst.
Hohe Testüberdeckung mit Qualität gleichgesetzt — die Überdeckung sagt nichts über die Aussagekraft der Tests.

LK-Vertiefung

eA-Vertiefung: Ordnen Sie die vier Teststufen den Phasen des V-Modells zu und beurteilen Sie, warum testgetriebenes Entwickeln und kontinuierliche Integration besonders gut zu Scrum, weniger gut zum reinen Wasserfallmodell passen.

Aktive Wiederholung

Vergleichen Sie das V-Modell mit Scrum hinsichtlich Anforderungswandel, Dokumentation und Teststrategien; beurteilen Sie, welches Modell für ein Online-Banking-Projekt geeigneter ist.

Aktiv abrufen

Erinnere dich an die Kernpunkte — dann aufdecken.

Dynamische Modellierung — Objekt-, Sequenz- und Zustandsdiagramme#

StandardKMK-EPA-Inf-StrukturierenNRW-IF2BY-Inf-3

UML-Sequenzdiagramm: Bestellung aufgeben

Abb. 4Drei Lebenslinien (Kunde, Bestellung, Lager); synchrone Nachrichten als durchgezogene Pfeile, Rückgaben gestrichelt.

Während ein Klassendiagramm die statische Struktur (welche Klassen, welche Beziehungen) zeigt, beschreiben Objekt-, Sequenz- und Zustandsdiagramme das dynamische Verhalten zur Laufzeit — was die Objekte tatsächlich tun. Diese Verhaltenssicht ist in der Oberstufe ebenso prüfungsrelevant wie die Struktursicht, weil ein vollständiges Modell beide Seiten braucht.

Ein Objektdiagramm ist eine Momentaufnahme des Systems zu einem Zeitpunkt: konkrete Instanzen in der Form `k1:Kunde` mit belegten Attributwerten und ihren aktuellen Verknüpfungen (Links). Es verhält sich zum Klassendiagramm wie ein konkretes Foto zum Bauplan — wo das Klassendiagramm Typen zeigt, zeigt das Objektdiagramm beispielhafte Exemplare mit Werten.

Ein Sequenzdiagramm stellt den Nachrichtenfluss zwischen Objekten über eine senkrechte Zeitachse dar (Zeit läuft nach unten). Jedes Objekt hat eine Lebenslinie (gestrichelt) mit Aktivierungsbalken während eines Methodenaufrufs; synchrone Aufrufe sind durchgezogene Pfeile mit gefüllter Spitze, Rückgaben gestrichelte Pfeile. So wird der zeitliche Ablauf eines Anwendungsfalls (etwa „Bestellung aufgeben") sichtbar.

Ein Zustandsdiagramm (Statechart) modelliert den Lebenszyklus eines einzelnen Objekts: seine möglichen Zustände und die durch Ereignisse ausgelösten Übergänge (z. B. eine Bestellung: offen → bezahlt → versandt → abgeschlossen). Es eignet sich besonders für Objekte, deren Verhalten stark vom aktuellen Zustand abhängt.

Übergänge tragen die Beschriftung `Ereignis [Bedingung] / Aktion`: Das Ereignis ist der Auslöser (Trigger), die optionale Bedingung (Guard) in eckigen Klammern muss zusätzlich erfüllt sein, die optionale Aktion wird beim Übergang ausgeführt. Ein Startzustand (gefüllter Kreis) und ein Endzustand (Ring um einen gefüllten Kreis) rahmen das Diagramm — ein Übergang ohne auslösendes Ereignis ist unzulässig.

Die Diagrammtypen ergänzen sich zu einer vollständigen Modellierung: Das Klassendiagramm liefert die Struktur, das Sequenzdiagramm die Interaktion zwischen Objekten, das Zustandsdiagramm den Lebenszyklus eines Objekts. In Klausuren werden die Nachrichten eines Sequenzdiagramms gern den Methoden des zugehörigen Klassendiagramms zugeordnet — beide Sichten müssen konsistent sein.

Typische Fehler

Klassen- und Objektdiagramm verwechselt — das Objektdiagramm zeigt Instanzen mit konkreten Werten.
Im Sequenzdiagramm Rückgaben als durchgezogene statt gestrichelte Pfeile gezeichnet.
Zustandsübergang ohne auslösendes Ereignis notiert — ein Übergang braucht einen Trigger.
Start- und Endzustand verwechselt oder ganz weggelassen.

LK-Vertiefung

eA-Vertiefung: Erstellen Sie ein Sequenzdiagramm für den Ablauf „Bestellung aufgeben → Bestand prüfen → bestätigen" und ordnen Sie jede Nachricht einer Methode im zugehörigen Klassendiagramm zu.

Aktive Wiederholung

Modellieren Sie für ein Objekt `Bestellung` ein Zustandsdiagramm mit den Zuständen offen, bezahlt, versandt, abgeschlossen sowie storniert und geben Sie für jeden Übergang das auslösende Ereignis an.

Aktiv abrufen

Erinnere dich an die Kernpunkte — dann aufdecken.

Objektorientierte Modellierung, Programmierung und Softwareentwicklung

6Abschnitteca. 18Min Lesezeit3KompetenzenNiveauBasis 1 · Standard 4 · Vertiefung 1Stand 06/2026