Alle prüfungsrelevanten Themen der OOP-Ausarbeitungsaufgaben, kompakt und lernfertig aufbereitet.
Fokus: Was das Abitur wirklich abfragt, mit Standardformulierungen und Schlüsselbegriffen.

⚠ Hinweis zur Qualität: Dieser Lernzettel wurde von KI erstellt. Trotz sorgfältiger Prüfung können einzelne Einträge fehlerhaft oder unvollständig sein.

1. UML-Anwendungsfalldiagramm (AWD)
2. UML-Klassendiagramm (KD)
3. OOP-Konzepte — Vererbung, Aggregation, Komposition
4. Datenkapselung & Zugriffsmodifizierer
5. Client-Server-Architektur
6. Threads & Synchronisation
7. Datenstrukturen
8. Softwareentwicklungsprozess & Qualität
9. Operatoren — Was wird erwartet?

Ein AWD modelliert die Anforderungen an ein System aus Benutzersicht. Es beschreibt das Was des Systems, nicht das Wie. Es dient der Absprache zwischen Auftraggeber (Kunde) und Auftragnehmer (Entwickler) und wird in der Analysephase des Softwareentwicklungsprozesses eingesetzt.

<<include>> — Muss-Beziehung:

• AF A inkludiert AF B → B wird immer ausgeführt, wenn A ausgeführt wird
• Zweck: Gemeinsame Teilfunktionalität mehrerer Anwendungsfälle auslagern
• Der Pfeil zeigt auf den inkludierten Anwendungsfall (B)
• Beispiel: „Ticket kaufen" inkludiert immer „Anmelden"

<<extend>> — Kann-Beziehung:

• AF B extended AF A → B wird nur bei Erfüllung einer bestimmten Bedingung ausgeführt
• Zweck: Optionale Sonderfälle oder Erweiterungen modellieren
• Der Pfeil zeigt auf den erweiterten Anwendungsfall (A)
• Beispiel: „Reservierung stornieren" extended „Zahlung überwachen" — nur wenn keine Zahlung eingegangen ist

Eselsbrücke: include = immer (Muss); extend = eventuell (Kann)

Wenn Akteur B eine Generalisierung von Akteur A ist, kann B alle Anwendungsfälle von A ausführen, zusätzlich zu seinen eigenen. Der Hohlpfeil zeigt auf den allgemeineren Akteur (A).

Beispiel: Akteur „Mitarbeiter" ist Spezialisierung von „Mitglied" → Mitarbeiter kann alles, was ein Mitglied kann, plus „Rechnungen ausstellen".

„Geben Sie den Zweck von UML-Anwendungsfalldiagrammen an. Beschreiben Sie anhand des dargestellten Diagramms die wesentlichen Notationselemente und die Unterschiede zwischen extend- und include-Beziehungen."

Musterantwort-Struktur:

1. Zweck in 1–2 Sätzen
2. Alle Notationselemente (Akteur, AF, Systemgrenze, Assoziation, ggf. Beziehungstypen) benennen und beschreiben
3. <<include>> erklären + konkretes Beispiel aus dem Diagramm
4. <<extend>> erklären + konkretes Beispiel aus dem Diagramm

Wenn eine Klasse verbal beschrieben werden soll, folgt man immer derselben Struktur. Die folgenden Stichworte werden oft explizit in der Aufgabenstellung gefordert und müssen im Text verwendet werden:

Klasse, Objekt, Attribut, Methode, Konstruktor, Assoziation, Navigierbarkeit, Rolle, Multiplizität

Musterstruktur:

1. Klasse benennen, Zugriffsrecht, Attribute mit Typ aufzählen
2. Statische Attribute (falls vorhanden) und ihren Zweck nennen
3. Methoden exemplarisch beschreiben (Parameter + Rückgabetyp)
4. Assoziationen mit Richtung, Multiplizität und Rollenname beschreiben

Beispielformulierung:

„Die Klasse Patient besitzt die privaten Attribute patientenNr, name und geschlecht sowie das statische Attribut autowert, das dazu dient, jedem Patienten eine eindeutige Nummer zuzuweisen. Die Methode indikationMitHoechsterPrioritaet(): Indikation liefert ein Objekt vom Typ Indikation zurück und benötigt keinen Parameter."

Unidirektionale Assoziation:

„Klasse A kennt Klasse B (Rollenname: b). Klasse B kennt A nicht — die Assoziation ist nicht rückwärts navigierbar."

Bidirektionale Assoziation:

„Zwischen A und B besteht eine beidseitig navigierbare Assoziation. A kennt B (Rolle: b) und B kennt A (Rolle: a)."

Multiplizität:

Muss-Beziehung: Mindestens 1 — das Objekt muss in dieser Beziehung stehen
Kann-Beziehung: Minimum 0 — das Objekt kann, muss aber nicht in dieser Beziehung stehen

• Klassenattribut (static): Gehört zur Klasse, nicht zu einzelnen Objekten. Im UML unterstrichen dargestellt. Typischer Zweck: automatische Nummerierung (autoNr, autowert)
• Instanzattribut: Gehört zu jedem Objekt individuell. Normale Darstellung.

Definition: Neue Klassen werden auf Basis vorhandener Klassen definiert. Es entsteht eine Hierarchie aus Superklassen (Oberklassen) und Subklassen (Unterklassen).

Generalisierung: Gemeinsame Attribute und Methoden mehrerer ähnlicher Klassen werden in eine Superklasse ausgelagert.

Spezialisierung: Eine Subklasse erbt alle Attribute und Methoden der Superklasse und erweitert oder überschreibt diese.

Vorteil: Die Superklasse ist bereits getestet — Fehler können nur noch in den Erweiterungen auftreten. Wiederverwendung von Code.

UML: Hohlpfeil (leere Dreieckspitze) zeigt von der Subklasse auf die Superklasse.

Typische Prüfungsformulierung:

„Erläutern Sie das Konzept der Vererbung allgemein und beschreiben Sie die vorliegende Vererbungsstruktur ausführlich (Stichworte: Spezialisierung, Generalisierung, abstrakte Klassen und Methoden, Zugriffsrecht protected, Polymorphie)."

Da die Stichworte explizit genannt werden, müssen alle im Text vorkommen.

• Eine abstrakte Klasse kann nicht instanziiert werden — es lassen sich keine Objekte direkt von ihr erzeugen.
• Sie stellt eine Schnittstelle (Interface) für ihre Subklassen bereit.
• Abstrakte Methoden haben keinen Methodenrumpf und erzwingen, dass alle konkreten Subklassen diese Methode implementieren (überschreiben).
• Im UML: Klassenname und abstrakte Methoden werden kursiv dargestellt.

Beispielformulierung:

„Die abstrakte Klasse Person kann nicht instanziiert werden. Die abstrakte Methode abrechnenMonat() erzwingt, dass sie in den Unterklassen Kunde und Reinigungskraft überschrieben werden muss."

Polymorphie bedeutet, dass Methoden in verschiedenen Klassen einer Vererbungshierarchie dieselbe Signatur haben, aber unterschiedlich implementiert sind.

• Welche konkrete Methode für ein Objekt aufgerufen wird, wird erst zur Laufzeit entschieden (dynamisches Binden)
• Vorteil: Objekte unterschiedlicher Subklassen können einheitlich über den Typ der Superklasse angesprochen werden

Beispiel:

„Die Methode toString() ist in den Klassen RahmenTeil, SchaltElement und EinzelTeil polymorph — alle haben dieselbe Signatur, aber jede Klasse liefert eine andere Ausgabe. Welche der Methoden für ein konkretes Objekt verwendet wird, wird erst zur Laufzeit bestimmt."

Beide beschreiben eine Ganzes-Teile-Beziehung — ein größeres Ganzes besteht aus Teilen. Der entscheidende Unterschied liegt in der Lebensdauer der Teile.

Aggregation (offene/nicht ausgefüllte Raute):

• Schwache Abhängigkeit — Weak Ownership
• Die Teile können unabhängig vom Ganzen existieren
• Wird das Ganze gelöscht, überleben die Teile
• Beispiel: Eine Abteilung besteht aus Mitarbeitern — wird die Abteilung aufgelöst, existieren die Mitarbeiter weiterhin

Komposition (ausgefüllte Raute):

• Starke Abhängigkeit — Strong Ownership
• Die Teile existieren nicht ohne das Ganze
• Wird das Ganze gelöscht, werden die Teile mitgelöscht
• Beispiel: Eine Bestellung besteht aus Bestellpositionen — ohne die Bestellung ergibt eine Bestellposition keinen Sinn

Merkhilfe: Die Raute befindet sich immer am Ganzen (nicht am Teil).

Datenkapselung (auch: Geheimnisprinzip) bezeichnet in der OOP das Verbergen von Daten vor unkontrolliertem Zugriff von außen. Der direkte Zugriff auf interne Attribute wird unterbunden — der Zugriff erfolgt ausschließlich über definierte Schnittstellen (get- und set-Methoden).

Ziel: Verhindern, dass interne Zustände unkontrolliert oder versehentlich geändert werden. Nur die definierten Methoden entscheiden, wie und wann Daten verändert werden dürfen.

„Beschreiben Sie den Zweck der Datenkapselung und erläutern Sie das Geheimnisprinzip am Beispiel der Attribute pin und kontostand der Klasse Konto."

Musterantwort:

„Als Datenkapselung wird der kontrollierte Zugriff auf Attribute und Methoden einer Klasse bezeichnet. Klassen sollen den internen Zustand anderer Klassen nicht unkontrolliert lesen oder ändern können — der Zugriff erfolgt nur über definierte Schnittstellen. Die Attribute pin und kontostand sind private und damit von außen nicht direkt zugänglich. Der Kontostand kann nur über die öffentlichen Methoden einzahlen() und ueberweisen() geändert werden — eine direkte Zuweisung von außen ist nicht möglich. Das Attribut pin ist ausschließlich über login() erreichbar."

Das Client-Server-Modell beschreibt die Verteilung von Aufgaben in einem Netzwerk auf zwei Rollen:

Client (aktive Rolle):

• Baut eine Verbindung zum Server auf
• Sendet Anfragen und empfängt Antworten
• Ist der initiierende Teil der Kommunikation

Server (passive Rolle):

• Horcht dauerhaft an einem Port auf eingehende Verbindungsanfragen
• Nimmt Verbindungen entgegen und bearbeitet sie
• Erzeugt für jeden verbundenen Client einen eigenen Thread, damit mehrere Clients parallel bedient werden können

Dienst: Eine festgelegte Aufgabe, die der Server anbietet und der Client nutzt.

Protokoll: Die Regeln der Kommunikation zwischen Client und Server — Kommandos, Bedeutung der übertragenen Daten, Formate.

Socket: Endpunkt einer Netzwerkverbindung. Ermöglicht das bidirektionale Lesen und Schreiben von Daten zwischen Client und Server.

Diese Dreiteilung (Client / Server / Thread) ist das wichtigste Muster im Abitur und taucht in nahezu jedem relevanten Vorschlag auf.

Client:

„Der Client baut über einen Socket eine Verbindung zum Server auf. Er sendet Anfragen an den Server und empfängt dessen Antworten. Der Client übernimmt die aktive Rolle beim Verbindungsaufbau."

Server:

„Der Server horcht an seinem Port und nimmt Verbindungsanfragen von Clients über einen ServerSocket entgegen. Hat er eine Verbindungsanfrage akzeptiert, erzeugt er einen neuen AnfrageThread für diesen Client — damit mehrere Clients gleichzeitig bedient werden können. Der Server erhält bei der Erzeugung eine Referenz auf das Verwaltungsobjekt (z.B. KinoManager), die er an den Thread weitergibt."

AnfrageThread / ServerThread:

„Der AnfrageThread erbt von der Klasse Thread und überschreibt die Methode run(), damit der Dialog mit dem Client in einem nebenläufigen Prozess ausgeführt werden kann. Damit run() asynchron läuft, muss der Thread über die geerbte Methode start() gestartet werden — diese ruft intern run() auf. Der Thread erhält im Konstruktor den Socket für die Kommunikation sowie eine Referenz auf das Verwaltungsobjekt. Er ruft dessen Methoden auf (z.B. anmelden(), sucheTicket()) und sendet die Ergebnisse über den Socket zurück an den Client."

Ein sehr häufig gefordertes Muster ist zu erklären, warum der Server einen Thread pro Client erzeugt:

„Da mehrere Clients gleichzeitig Verbindungen aufbauen können, muss für jeden Client ein eigener Thread erzeugt werden. So werden die Anfragen der einzelnen Clients unabhängig voneinander und parallel bearbeitet — kein Client blockiert einen anderen."

„Threads sind leichtgewichtige Prozesse, die sich denselben Adressraum im Speicher teilen. Innerhalb eines Prozesses können mehrere Threads quasi-parallel ablaufen. Im Gegensatz zu eigenständigen Prozessen haben Threads keinen eigenen Speicherbereich — sie teilen sich den Arbeitsspeicher, besitzen aber jeweils einen eigenen Befehlszähler und Stack."

Prozess vs. Thread:

// Klasse erbt von Thread class MeinThread extends Thread { public void run() { // Code, der nebenläufig ausgeführt wird } } // Starten: MeinThread t = new MeinThread(); t.start(); // ruft run() asynchron auf

Wichtig für die Prüfung:

• run() wird überschrieben — hier steht der nebenläufige Code
• Gestartet wird mit start(), nicht mit run() direkt (direkter Aufruf läuft nicht nebenläufig!)
• Der Thread endet, sobald run() vollständig ausgeführt ist

Das ist die häufigste Thread-Aufgabe im Abitur. Immer gleiche Struktur:

Das Problem: Wenn mehrere Threads gleichzeitig auf gemeinsame Daten zugreifen, kann es zu inkonsistenten Zuständen kommen.

Ablauf einer Race Condition:

1. Thread A liest den Wert einer gemeinsamen Variable (z.B. kontostand)
2. Das Betriebssystem unterbricht Thread A (Kontextwechsel)
3. Thread B liest denselben Wert, ändert ihn und schreibt ihn zurück
4. Thread A wird fortgesetzt und schreibt seinen veralteten Wert — Thread B's Änderung wird überschrieben

Konkretes Beispiel (E-Banking):

„Wenn zwei Clients gleichzeitig Überweisungen vornehmen, können beide Threads gleichzeitig auf den kontostand zugreifen. Thread A prüft, ob ausreichend Deckung vorhanden ist — in diesem Moment wird er unterbrochen. Thread B führt ebenfalls eine Überweisung durch und reduziert den Kontostand. Wird Thread A fortgesetzt, führt er seine Überweisung auf Basis des veralteten Kontostands durch — obwohl keine ausreichende Deckung mehr vorliegt."

Die Lösung: Die betroffene Methode mit synchronized kennzeichnen. Dadurch kann die Methode zu einem Zeitpunkt nur von einem Thread ausgeführt werden — die Ausführung wird nicht unterbrochen, bis die Methode abgeschlossen ist (atomare Ausführung).

public synchronized void ueberweisen(double betrag) {
    // Kritischer Abschnitt — nur ein Thread gleichzeitig
}

Das Abitur fragt oft nach dem Nutzen von Threads anhand eines konkreten Szenarios:

„Da sowohl die Messung der Fahrdaten als auch die Kommunikation mit der Zentrale nebenläufig ablaufen sollen, ist es sinnvoll, beide Vorgänge als Threads zu realisieren. So kann der Bordcomputer gleichzeitig Fahrdaten erfassen und auf Anfragen der Zentrale reagieren, ohne dass ein Vorgang den anderen blockiert."

Eine dynamische Datenstruktur zur Speicherung beliebig vieler Objekte.

• Jedes Listenelement enthält einen Verweis (Referenz/Pointer) auf das nächste Element
• Es gibt keinen direkten Index-Zugriff — die Liste muss vom Anfang bis zum gesuchten Element durchlaufen werden
• Vorteil gegenüber Array: Einfügen und Löschen ohne Verschieben von Elementen — nur Referenzen werden umgehängt
• Nachteil: Kein direkter Zugriff über Index möglich

Einfach verkettete Liste: Jedes Element kennt nur seinen Nachfolger
Doppelt verkettete Liste: Jedes Element kennt Nachfolger und Vorgänger (z.B. über naechste und vorherige Referenzen)

• Prinzip: LIFO — Last In, First Out
• Das zuletzt hinzugefügte Element wird als erstes wieder entnommen
• Zugriff nur auf das oberste Element möglich

Operationen:

Umsetzung: Als verkettete Liste — neues Element wird immer am Anfang eingefügt (Listenkopf = Stapelspitze).

• Prinzip: FIFO — First In, First Out
• Das zuerst hinzugefügte Element wird als erstes wieder entnommen
• Zugriff: Einfügen am Ende, Entnahme am Anfang

Operationen:

Umsetzung: Als verkettete Liste — Einfügen am Ende (tail), Entnahme am Anfang (head).

1. Analyse & Anforderungsdefinition

• Dienstleistungen, Einschränkungen und Ziele des Systems werden in Zusammenarbeit mit den Benutzern aufgestellt und detailliert definiert
• Produkte: Lastenheft, Pflichtenheft, UML-Anwendungsfalldiagramm, Prototypen, Testdaten

2. Softwareentwurf

• Erkennen und Beschreiben der grundlegenden Softwarestruktur und Beziehungen zwischen Komponenten
• Produkte: UML-Klassendiagramm, UML-Sequenzdiagramm, Datenbankmodell, Schnittstellenspezifikation

3. Implementierung & Komponententests

• Der Entwurf wird in Code umgesetzt; einzelne Einheiten (Klassen, Methoden) werden getestet
• Produkte: Kommentierter Programmcode, Testprotokolle

4. Integration & Systemtests

• Einzelne Komponenten werden zusammengeführt und als Gesamtsystem getestet; anschließend Auslieferung
• Produkte: Benutzerhandbuch, Testprotokoll, Dokumentation

5. Betrieb & Wartung

• Das System wird produktiv eingesetzt; Fehler werden korrigiert, Verbesserungen und Anpassungen vorgenommen
• Produkte: Abnahmeprotokoll, aktualisierte Dokumentation, Versionshistorie

Lastenheft (erstellt vom Auftraggeber):

• Beschreibt die gesamte gewünschte Funktionalität in nicht-technischer Sprache
• Enthält: IST-Zustand, SOLL-Zustand, Schnittstellen, funktionale Anforderungen
• Wird dem Auftragnehmer übergeben

Pflichtenheft (erstellt vom Auftragnehmer):

• Beschreibt technisch, wie die Anforderungen des Lastenhefts umgesetzt werden
• Enthält: konkrete Lösungsschritte, Systemarchitektur, technische Details
• Grundlage für die Implementierung

Merksatz: Der Auftraggeber sagt was er will (Lastenheft) — der Auftragnehmer beschreibt wie er es umsetzt (Pflichtenheft).

Das Abitur verwendet präzise Operatoren, die genau definieren, was und wie viel erwartet wird. Diese Unterschiede können über Punkte entscheiden.

Vollständige, strukturierte Darstellung aller relevanten Merkmale. Sachlich und neutral — kein Werten, kein Begründen.

• Alle wichtigen Eigenschaften nennen
• Vollständige Sätze, strukturiert
• Beispiel: „Beschreiben Sie die Klasse X" → alle Attribute, Methoden, Beziehungen aufführen

Beschreiben plus Verdeutlichung im Kontext oder anhand eines Beispiels. Bezug zum vorliegenden Szenario herstellen.

• Beschreibung + Zusammenhang + Beispiel aus der Aufgabe
• Beispiel: „Erläutern Sie die Aufgaben von Client, Server und Thread" → Funktion + wie sie im konkreten System zusammenarbeiten

Sachverhalte verständlich und nachvollziehbar darstellen, besonders Ursache-Wirkung-Zusammenhänge.

• Mechanismus, Ablauf oder Begründung darlegen
• Typisch für technische Abläufe und Probleme (Race Conditions, Synchronisation)
• Beispiel: „Erklären Sie, wie es zu einer Mehrfachbelegung kommen kann"

Kurze, stichwortartige Aufzählung. Keine Vollständigkeit erforderlich, keine Ausformulierung nötig.

• Nur die geforderte Anzahl an Punkten liefern
• Beispiel: „Nennen Sie drei Passwort-Regeln" → drei knappe Stichpunkte genügen

Gemeinsamkeiten und Unterschiede strukturiert nebeneinanderstellen. Oft tabellarisch sinnvoll.

Aussage mit sachlichen Argumenten stützen — warum gilt etwas?

Wenn in einer Aufgabe steht „Stichworte: Spezialisierung, Generalisierung, abstrakte Klassen, protected, Polymorphie", dann sind das keine Hinweise, sondern Pflichtbegriffe — alle müssen im Text sinnvoll verwendet werden. Fehlende Stichworte bedeuten fehlende Punkte.

Grundregel: 1 BE ≈ 1 inhaltlich korrekte, relevante Aussage.
Nicht mehr schreiben als gefordert — irrelevante Aussagen kosten keine Punkte, stehlen aber Zeit. Bei Unsicherheit, kann es jedoch sinvoll sein eine zusätzliche zu erwähnen, falls existent.