Block 03 · UML-Modellierung

A · Erklärungssatz

UML-Diagramme sind der zweitgrößte Brocken der AP2 nach den Datenbanken. In jeder der neun ausgewerteten Prüfungen musste in Teil 1 mindestens ein Diagramm gezeichnet werden, in sechs Prüfungen zusätzlich in Teil 2 – dort oft als komplette 25-Punkte-Aufgabe (Aktivitätsdiagramm S23, Sequenzdiagramm W23, Zustandsdiagramm W25). Fast immer bekommst du einen Text (Prozessbeschreibung, Interview, Anforderungsliste, Quelltext) und musst daraus ein Diagramm erstellen oder ein vorgegebenes Teil-Diagramm ergänzen.

UML-01 · Verhaltensdiagramme allgemein / Diagrammwahl Immer

Vorkommen: 9/9 · Prüfungen: alle (W21–S26) · mindestens ein Verhaltensdiagramm (Aktivität, Zustand oder Sequenz) in jeder Prüfung, in Teil 1 immer ein gezeichnetes Diagramm

Was ist UML?

Die Unified Modeling Language (UML) ist eine von der OMG (Object Management Group) standardisierte grafische Sprache, mit der Software vor und während der Entwicklung beschrieben wird (aktuelle Version 2.5). Sie definiert 14 Diagrammarten, die in zwei Gruppen zerfallen:

• Strukturdiagramme zeigen den statischen Aufbau eines Systems – was es gibt und wie es zusammenhängt (Klassen, Objekte, Komponenten, Rechnerknoten). Zeit spielt keine Rolle.
• Verhaltensdiagramme zeigen das dynamische Verhalten – was passiert, in welcher Reihenfolge, wer mit wem kommuniziert, wie ein Objekt auf Ereignisse reagiert. Die Interaktionsdiagramme (z. B. Sequenzdiagramm) sind eine Untergruppe der Verhaltensdiagramme.

Welches Diagramm wofür?

Die häufigste Verwechslung: Aktivitäts- oder Zustandsdiagramm?

Beide haben abgerundete Kästen und Pfeile – trotzdem beschreiben sie etwas völlig anderes. Im Aktivitätsdiagramm ist ein Kasten etwas, das getan wird; im Zustandsdiagramm ist ein Kasten eine Situation, in der ein Objekt verweilt, bis ein Ereignis eintritt.

Aktivitäts- oder Sequenzdiagramm?

Beide zeigen eine Reihenfolge. Das Aktivitätsdiagramm beschreibt was getan wird (fachliche Schritte, auch ohne Software, z. B. „Paket packen“). Das Sequenzdiagramm beschreibt wie Objekte dafür zusammenarbeiten – mit konkreten Nachrichten bzw. Methodenaufrufen, Parametern und Rückgabewerten. Steht im Text „ruft … auf“, „sendet eine Anfrage an“, „erhält als Antwort“ oder ist Quelltext gegeben, ist das Sequenzdiagramm gemeint.

Beispiel: Diagrammwahl bei einem Paketdienst

So gehst du vor: Diagramm aus einem Text ableiten

1. Diagrammart klären. Steht sie in der Aufgabe, ist alles klar. Wenn nicht: Leitfragen oben anwenden und im Belegsatz nachsehen, welche Notationen beiliegen.
2. Text markieren. Beteiligte/Rollen (→ Partitionen, Akteure, Lebenslinien), Tätigkeiten (→ Aktionen, Anwendungsfälle, Nachrichten), Zustände (→ Zustände), Bedingungen „wenn/falls/sonst“ (→ Entscheidung bzw. Guard), „gleichzeitig“ (→ Teilung/Synchronisation bzw. par), Wiederholungen (→ Schleife bzw. loop), Zeitangaben (→ after).
3. Grob skizzieren – erst den Hauptweg („Gutfall“), dann die Abzweigungen. Bleistift benutzen, Platz lassen.
4. Jeden Satz abhaken. Die IHK vergibt Punkte für einzelne Sachverhalte aus dem Text. Was im Text steht, muss im Diagramm vorkommen – was nicht im Text steht, wird nicht erfunden.
5. Notation prüfen (Belegsatz): Pfeilspitzen, Guards in eckigen Klammern, Start/Ende vorhanden, Rautenseite bei Aggregation/Komposition, include/extend-Richtung.

Ein gegebenes Diagramm lesen

• Aktivitätsdiagramm: Vom Startknoten aus jeden möglichen Weg mit dem Finger verfolgen. An jeder Raute: Welche Bedingung führt wohin? An jedem Balken: Was läuft parallel, worauf wird gewartet?
• Zustandsdiagramm: Für ein Ereignis im aktuellen Zustand alle ausgehenden Transitionen mit genau diesem Ereignis suchen, Bedingungen prüfen, dann in dieser Reihenfolge ausführen: exit des alten Zustands → Aktion an der Transition → entry des neuen Zustands.
• Sequenzdiagramm: von oben nach unten lesen; jede Nachricht ist ein Aufruf beim Empfänger (Pfeilspitze). Fragmente wie alt zeigen, welcher Teil nur unter welcher Bedingung abläuft.
• Klassendiagramm: Multiplizitäten immer in beide Richtungen als Satz formulieren (siehe UML-03).

Fehler in Diagrammen finden – Checkliste

UML-02 · Aktivitätsdiagramm Meistens

Vorkommen: 6/9 · Prüfungen: W21, W22, S23, W23, S24, S26 · 14–25 Punkte, meist aus einem Prozesstext oder Interview mit Partitionen

Das Aktivitätsdiagramm beschreibt einen Ablauf: einen Geschäftsprozess („Wie läuft eine Bestellung ab?“), einen Anwendungsfall im Detail oder einen Algorithmus. Es ist der Klassiker der Prüfung, weil es sich gut aus Text ableiten lässt und Verzweigung, Parallelität und Zuständigkeiten abfragt.

Die Elemente und ihre Regeln

Denkmodell „Marken“ (Token): Stell dir vor, eine Spielfigur läuft vom Startknoten aus die Pfeile entlang. An einer Entscheidung wählt sie einen Weg. An einer Teilung entstehen aus einer Figur mehrere, die gleichzeitig weiterlaufen. Eine Synchronisation lässt erst eine Figur weiter, wenn von jedem Eingang eine angekommen ist. Eine Zusammenführung lässt jede ankommende Figur sofort durch. Damit lassen sich alle Fehlerfragen beantworten: Führt man zwei parallele Figuren über eine Raute zusammen, laufen danach zwei Figuren weiter – alles danach passiert doppelt.

Abb. A-2 zeigt alle Grundelemente: Die Entscheidung mit zwei sich ausschließenden Guards, die Teilung, nach der Vertretung und Urlaubsbuchung unabhängig voneinander erledigt werden, die Synchronisation, die auf beide wartet, und die Zusammenführung, über die beide Ergebnisse (abgelehnt/genehmigt) zur letzten Aktion laufen. Die Kanten wechseln dabei die Partitionen – das ist ausdrücklich erlaubt.

Schleifen, Endknoten und Ablaufende

Eine Wiederholung entsteht, indem ein Pfeil von einer Entscheidung zurück zu einer Zusammenführung vor dem zu wiederholenden Schritt führt. Die Bedingung steht am rückführenden Pfeil (z. B. [weiteres Dokument]) und am weiterführenden Pfeil ([fertig]).

In Abb. A-3 laufen nach der Teilung „Bewerbung absenden“ und „Statistik aktualisieren“ parallel. Der untere Zweig endet mit einem Ablaufende – nur dieser Zweig ist dann fertig. Erreicht der obere Zweig den Endknoten, endet die gesamte Aktivität, selbst wenn die Statistik noch läuft. Soll beides sicher abgeschlossen werden, verwendet man stattdessen eine Synchronisation vor einem gemeinsamen Endknoten.

Partitionen (Swimlanes) richtig einsetzen

• Für jede Rolle aus dem Text eine Bahn – Personen und Systeme (z. B. „Kunde“, „Webshop“, „Lager“). Ist die Bahnaufteilung vorgegeben (Vorlage), musst du dich daran halten.
• Jede Aktion in die Bahn dessen, der sie ausführt: „Der Server prüft das Konto“ → Bahn Server. „Die Kundin erhält eine Mail“ → wer tut etwas? Das System sendet die Mail (Aktion „Mail senden“ beim System) – die Kundin liest sie höchstens.
• Entscheidungen stehen in der Bahn dessen, der entscheidet bzw. dessen Aktion das Ergebnis liefert.
• Ein Teilungs- oder Synchronisationsbalken darf über mehrere Bahnen reichen.

So gehst du vor: Aktivitätsdiagramm aus einem Text oder Interview

1. Bahnen anlegen (Beteiligte aus dem Text), Startknoten in die Bahn des Auslösers.
2. Sätze in Aktionen zerlegen: pro Tätigkeit eine Aktion, Objekt + Verb. Füllsätze („das ist bei uns schon immer so“) ignorieren.
3. Signalwörter übersetzen:

   Im Text	Im Diagramm
   „wenn … dann“, „falls“, „sonst“, „bei …“, „je nachdem“	Entscheidung mit Guards (und später meist eine Zusammenführung)
   „gleichzeitig“, „parallel“, „währenddessen“, „unabhängig voneinander“, „zweierlei passiert“	Teilung
   „erst wenn beides erledigt ist“, „sobald alle … fertig sind“	Synchronisation
   „erneut“, „wiederholt“, „für jedes“, „solange“, „bis“, „die nächste …“	Schleife: Entscheidung + Rückführung in eine Zusammenführung
   „dann ist der Vorgang beendet“, „damit ist die Sache erledigt“	Endknoten
   „nebenbei“, „dieser Teil endet hier, der Rest läuft weiter“	Ablaufende

4. Hauptweg zeichnen, dann Abzweigungen; jede Entscheidung bekommt vollständige Guards.
5. Kontrolle: Hat jede Teilung eine Synchronisation (falls die Zweige wieder zusammenlaufen)? Endet jeder Weg in einem Endknoten? Ist jeder Satz des Textes abgebildet?

UML-03 · Klassendiagramm Meistens

Vorkommen: 6/9 · Prüfungen: W21, S22, S23, S24, W24, S26 · 5–25 Punkte; oft auch als Grundlage für Pseudocode-Aufgaben

Das Klassendiagramm zeigt die statische Struktur einer objektorientierten Software: welche Klassen es gibt, welche Daten (Attribute) und Operationen (Methoden) sie haben und wie sie zusammenhängen. In der Prüfung wird es erstellt bzw. ergänzt (W24: 17 P), aus Quelltext abgeleitet, gelesen (Multiplizitäten deuten) oder als Vorgabe für Algorithmen benutzt. Die objektorientierten Konzepte dahinter (Polymorphie, Entwurfsmuster) behandelt Block 08 – hier geht es um die Notation.

Aufbau einer Klasse

Ein Rechteck mit bis zu drei Abschnitten: Name (fett, zentriert, Substantiv im Singular) – Attribute – Methoden. Leere Abschnitte dürfen weggelassen werden.

Datentypen: Verwende die Typen aus der Aufgabe oder übliche Typen: int/Integer, double, boolean, String, Date (bzw. LocalDate), Time/DateTime, Listen als List<Typ> oder mit Multiplizität Typ[*]. Geldbeträge als double (in der Praxis BigDecimal), Telefonnummern und Postleitzahlen als String (führende Nullen!).

Beziehungen

Multiplizitäten

Leseregel: Die Multiplizität steht an der Klasse, deren Anzahl sie angibt. Man liest immer vom anderen Ende her: „Ein Objekt der Klasse A steht mit [Multiplizität bei B] Objekten der Klasse B in Beziehung.“ In Abb. A-5: Ein Kunde gibt 0..* (beliebig viele) Bestellungen auf; eine Bestellung wird von genau 1 Kunden aufgegeben. Für die volle Punktzahl immer beide Richtungen als Satz formulieren.

Weitere Angaben an einem Assoziationsende: Rollenname (z. B. vorgesetzter / mitarbeiter – besonders wichtig bei Beziehungen einer Klasse zu sich selbst), {ordered} für eine geordnete Reihenfolge (Liste statt Menge), Leserichtung mit ▸ am Assoziationsnamen.

Aggregation oder Komposition?

Quelltext ↔ Klassendiagramm

Ein Attribut, das auf ein Objekt einer anderen Klasse im Diagramm verweist, wird in der Regel als Beziehungslinie dargestellt – nicht zusätzlich als Attribut (sonst doppelt). Der Attributname kann als Rollenname an das Linienende geschrieben werden.

So gehst du vor: Klassendiagramm aus einem Text

1. Substantive sammeln: Was eigene Daten und eine eigene Identität hat, wird eine Klasse (Kunde, Bestellung); einfache Werte werden Attribute (Name, Datum, Preis).
2. Attribute mit Datentypen eintragen, Sichtbarkeit - (Kapselung), sofern nichts anderes verlangt.
3. „ist ein / ist eine Art von“ → Vererbung. Gemeinsame Attribute in die Oberklasse; „es gibt nur diese Arten“ → Oberklasse abstrakt.
4. Beziehungen: „hat / gehört zu / besteht aus“ → Assoziation, Aggregation oder Komposition (Prüffragen oben). Gibt die Beziehung selbst Daten her (z. B. Anmeldedatum), wird daraus eine eigene Klasse (oder Assoziationsklasse).
5. Multiplizitäten an beiden Enden aus Zahlwörtern ableiten: „genau ein“, „mindestens ein“, „mehrere“, „kann … haben“ (→ 0..).
6. Methoden nur, wenn verlangt oder im Text genannt.

UML-04 · Zustandsdiagramm Oft

Vorkommen: 4/9 · Prüfungen: W22, S23, W24, W25 · 10–25 Punkte, zuletzt als ganze 25-Punkte-Aufgabe (W25)

Ein Zustandsdiagramm (Zustandsautomat, State Machine) beschreibt, wie sich ein einzelnes Objekt im Laufe seines Lebens verhält: In welchen Zuständen kann es sein, welche Ereignisse lassen es in einen anderen Zustand wechseln und was passiert dabei? Typische Objekte in der Prüfung: Geräte und Automaten (Ampel, Roboter, Sensor), Vorgänge mit Status (Buchung, Raum, Auftrag).

Begriffe

Beispiele für Beschriftungen: einschalten · münzeEingeworfen [betrag >= preis] / ticketDrucken · [sensorOk] (nur Bedingung, wird nach Abschluss des Zustands geprüft) · after(30 s) · / zähler := 0.

Arten von Ereignissen

Aktionen im Zustand: entry, do, exit

Reihenfolge beim Schalten: exit-Aktion des alten Zustands → Aktion an der Transition → entry-Aktion des neuen Zustands → do-Aktivität startet. Eine Selbsttransition (Pfeil vom Zustand zu sich selbst) verlässt den Zustand und betritt ihn neu: exit und entry werden ausgeführt und ein laufendes after beginnt von vorn. Eine interne Transition tut das nicht.

So liest man Abb. A-7: Eine neue Bestellung ist im Zustand Neu; beim Betreten wird eine Bestätigung gemailt. Geht eine Zahlung ein, die die Summe deckt, wechselt die Bestellung nach Bezahlt und es wird eine Rechnung erstellt. Reicht der Betrag nicht, bleibt sie in Neu (Selbsttransition) und der Rest wird angefordert – Achtung: Weil es eine Selbsttransition ist, wird dabei auch die entry-Aktion erneut ausgeführt (zweite Bestätigungsmail). Ist das nicht gewollt, trägt man die Zeile als interne Transition in den Zustand ein. Vergehen 14 Tage im Zustand Neu ohne vollständige Zahlung, wird storniert.

Zusammengesetzte Zustände (Unterzustände)

Gilt dieselbe Transition für viele Zustände (z. B. „Not-Aus“, „Störung“, „Abbrechen“), fasst man diese Zustände zu einem zusammengesetzten Zustand zusammen. Er enthält ein eigenes kleines Zustandsdiagramm mit Startzustand.

• Ein Pfeil in den zusammengesetzten Zustand hinein (auf den Rand) startet beim inneren Startzustand – hier „Mahlen“.
• Ein Pfeil, der vom Rand ausgeht, gilt für jeden Unterzustand: „wassertankLeer“ bricht die Zubereitung ab, egal ob gerade gemahlen, gebrüht oder ausgegeben wird. Ohne Unterzustände bräuchte man drei einzelne Pfeile.
• Erreicht der innere Ablauf den inneren Endzustand, ist der zusammengesetzte Zustand abgeschlossen; eine unbeschriftete Transition vom Rand (hier zurück nach „Bereit“) schaltet dann.
• Optional: Ein History-Zustand (Kreis mit H) merkt sich den zuletzt aktiven Unterzustand, um später dort fortzusetzen.

Unterzustände stehen nicht im Belegsatz – wenn sie gefragt sind, wird die Aufgabe sie meist ausdrücklich verlangen („… übersichtlich mit Unterzuständen modellieren“).

So gehst du vor

1. Objekt bestimmen („Zustände des Roboters“, „Status einer Buchung“). Nur dieses Objekt wird modelliert.
2. Zustände sammeln: Formulierungen wie „wechselt in den Zustand …“, „ist dann …“, „befindet sich …“. Oft sind die Namen im Text vorgegeben (in Anführungszeichen) – genau diese Namen verwenden.
3. Startzustand setzen („Nach dem Einschalten …“).
4. Für jeden Zustand fragen: Welche Ereignisse lassen ihn verlassen? Welche Bedingung gilt dabei? Was wird dabei getan (Aktion an der Transition) – oder geschieht es bei jedem Betreten (entry)?
5. Zeitangaben („nach 5 Sekunden“, „wenn innerhalb von 3 Tagen nicht …“) → after(…) am Ausgang des Zustands, in dem gewartet wird.
6. Endzustand, falls das Objekt sein Leben beendet (ausschalten, löschen).
7. Prüfen: Ist jeder Zustand erreichbar? Kommt man aus jedem Zustand (außer dem Endzustand) wieder heraus? Sind Bedingungen bei gleichem Ereignis eindeutig?

UML-05 · Use-Case-Diagramm Oft

Vorkommen: 4/9 · Prüfungen: W21, W23, S24, W25 · 6–18 Punkte, meist in Teil 1

Das Use-Case-Diagramm (Anwendungsfalldiagramm) zeigt, wer (Akteure) was (Anwendungsfälle) mit einem System tun kann. Es ist eine Außensicht ohne Reihenfolge und ohne technische Details – ideal für die Anforderungsanalyse und das Gespräch mit Auftraggebern.

Elemente

include oder extend?

In Abb. A-9 ist „Bezahlen“ eine Teilfunktion, die bei jeder Buchung abläuft (include), „Gutschein einlösen“ wird nur unter der Bedingung „Gutscheincode eingegeben“ an der Stelle „Bezahlung“ eingefügt (extend). Ein Stammkunde kann alles, was ein Kunde kann, und zusätzlich Bonuspunkte einlösen (Generalisierung der Akteure: Dreieck zeigt zum allgemeineren Akteur). Der Zahlungsdienstleister ist ein externes System und steht als Akteur außerhalb der Systemgrenze.

Use-Case-Beschreibung (textuell)

Das Diagramm zeigt nur die Namen. Den Ablauf eines Anwendungsfalls beschreibt man in einer Schablone:

User Stories aus Anwendungsfällen ableiten

Eine User Story beschreibt eine Anforderung aus Sicht eines Nutzers im Satzschema „Als <Rolle> möchte ich <Funktion>, damit <Nutzen>.“ Rolle = Akteur, Funktion = Anwendungsfall, Nutzen = Ziel des Akteurs. Ergänzt wird sie um Akzeptanzkriterien (prüfbare Bedingungen, wann die Story erfüllt ist). Beispiel: „Als Stammkunde möchte ich Bonuspunkte beim Ticketkauf einlösen, damit ich für häufige Kinobesuche belohnt werde.“ Akzeptanzkriterien: Punktestand wird vor dem Bezahlen angezeigt; 100 Punkte entsprechen 1 €; der Preis kann nicht negativ werden. (Mehr zu User Stories und INVEST in Block 04.)

So gehst du vor

1. Systemgrenze zeichnen und benennen.
2. Akteure sammeln (Personengruppen und externe Systeme), links und rechts außerhalb platzieren. „… kann alles, was … kann, und zusätzlich …“ → Generalisierung.
3. Anwendungsfälle sammeln: Was will ein Akteur erreichen? Substantiv + Verb.
4. Assoziationen zwischen Akteuren und ihren Fällen.
5. „immer“, „jedes Mal“, „wird geprüft“ bei mehreren Fällen → include. „optional“, „nur wenn“, „kann zusätzlich“ → extend mit Condition und Extension Point. „eine besondere Form von“ → Generalisierung von Anwendungsfällen.
6. Kontrolle: Pfeilrichtungen, keine Akteure in der Systemgrenze, keine Bedienschritte.

UML-06 · Sequenzdiagramm Wahrscheinlich

Vorkommen: 3/9 · Prüfungen: S22, W23, S24 · 9–25 Punkte (W23 eine ganze Aufgabe)

Das Sequenzdiagramm zeigt, wie Objekte (oder ganze Systeme wie App, Server, Datenbank) durch Nachrichten zusammenarbeiten – in zeitlicher Reihenfolge von oben nach unten. Es eignet sich, um eine Methode, eine Schnittstelle (REST-Aufrufe) oder einen Anwendungsfall technisch zu beschreiben.

Elemente

Kombinierte Fragmente

Im IHK-Belegsatz ist nur alt mit [else] abgebildet – opt, loop und par musst du selbst kennen.

Abb. A-10 gehört zu folgendem Code. Jede Methode, die aufgerufen wird, wird eine synchrone Nachricht an das Objekt, auf dem sie aufgerufen wird; jede Rückgabe eine Antwort:

public String bestellen(Warenkorb korb) {     // Aufruf aus der ShopApp
    boolean alleDa = true;
    for (Position p : korb.getPositionen()) { // loop [für jede Position]
        if (!lager.pruefeBestand(p.getArtNr(), p.getMenge())) {
            alleDa = false;
        }
    }
    if (alleDa) {                             // alt [alle Artikel verfügbar]
        Bestellung b = new Bestellung(korb);  // create
        b.speichern();                        // synchron mit Antwort
        mailService.sendeBestaetigung(b);     // asynchron (kein Warten)
        return b.getBestellNr();              // Antwort an die ShopApp
    }
    return "nicht lieferbar";                 // [else]
}

Quelltext → Sequenzdiagramm

So gehst du vor

1. Lebenslinien festlegen (vorgegeben? dann genau diese) – der Auslöser ganz links.
2. Den Ablauf Schritt für Schritt von oben nach unten eintragen: jede Nachricht mit Namen und Parametern, jede Antwort mit Rückgabewert.
3. Für jeden synchronen Aufruf einen Aktivierungsbalken beim Empfänger, der mit der Antwort endet.
4. Bedingungen und Wiederholungen mit Fragmenten umrahmen, Bedingung in eckigen Klammern an den Anfang des Bereichs.
5. Kontrolle: Gefüllte Spitze nur bei synchron; Antworten gestrichelt; kein Aufruf an ein Objekt vor seinem create.

UML-07 · Struktogramm / Programmablaufplan Sonstige

Vorkommen: 2/9 (als eigene Teilaufgabe) · Prüfungen: W21, S23 · bis 6 Punkte; außerdem ist die Darstellung von Algorithmen „in Pseudocode, als Struktogramm oder PAP“ oft freigestellt (S22, W22)

Struktogramme (Nassi-Shneiderman-Diagramme, DIN 66261) und Programmablaufpläne (PAP, DIN 66001) sind keine UML-Diagramme, sondern ältere Notationen für Algorithmen. In der AP2 kommen sie vor, wenn ein Algorithmus gelesen, korrigiert oder umgewandelt werden soll. Die Symbole stehen im Belegsatz (Teil B).

Bausteine im Vergleich

Kopf- oder fußgesteuert? Die kopfgesteuerte Schleife prüft vor dem ersten Durchlauf – der Rumpf läuft eventuell gar nicht. Die fußgesteuerte Schleife läuft mindestens einmal. Das ist ein beliebter Fehler: Wird eine fußgesteuerte Schleife verwendet, obwohl die Bedingung schon vor dem ersten Durchlauf falsch sein kann, passiert ein Schritt zu viel. Achtung bei „wiederhole … bis …“ (Abbruchbedingung) gegenüber „wiederhole … solange …“ (Laufbedingung) – die Bedingungen sind genau entgegengesetzt.

Abb. A-12 und A-13 zeigen denselben Algorithmus. Im Struktogramm gibt es keine Pfeile und keine Sprünge – jede Struktur hat genau einen Eingang (oben) und einen Ausgang (unten). Der PAP ist freier, die Schleife entsteht durch einen Rücksprung. Deshalb gelten Struktogramme als „strukturierter“, PAPs als anschaulicher, aber fehleranfälliger.

So gehst du vor: Pseudocode → Struktogramm

1. Äußeres Rechteck in voller Breite; Funktionsname mit Parametern darüber schreiben.
2. Pseudocode Zeile für Zeile übertragen: jede Anweisung ein Rechteck, jede Struktur das passende Symbol; Inneres einer Schleife/Verzweigung wird darin verschachtelt.
3. Bei Verzweigungen die Spalten so breit wählen, dass der Text passt; leere Zweige mit ∅ kennzeichnen.
4. rückgabe bzw. Ausgabe als eigene Anweisung am Ende (oder in den Zweigen).

Fehler finden mit dem Schreibtischtest

Für einen Testfall mit bekanntem Ergebnis wird eine Tabelle mit einer Spalte je Variable angelegt; nach jedem Schritt (oder Schleifendurchlauf) wird der aktuelle Wert eingetragen. Weicht das Ergebnis vom erwarteten ab, findet man die Stelle. Typische eingebaute Fehler: Initialisierung an der falschen Stelle (innerhalb statt vor der Schleife), Schleifengrenzen (eine Iteration zu viel/zu wenig), vertauschte Zweige einer Verzweigung, < statt <=, falsche Schleifenart.

B · Belegsatz

Enthält nur, was dir auch die IHK beilegen würde: die Notationshilfen (UML wie in den Belegsätzen S24/W25, Struktogramm wie W22, PAP wie S22, Pseudocode-Konventionen wie S24) und die Anlagen zur Ausgangssituation. Keine Erklärungen.

UML-Notation

Struktogramm und Programmablaufplan

Pseudocode, prozedurale Programmierung

wenn [ Bedingung ] dann
   [ Anweisung ]
sonst
   [ Anweisung ]
Ende wenn

zähle [ Variable ] von [ Startwert ] bis [ Endwert ]
   [ Schleifeninhalt ]
Ende zähle

solange [ Bedingung ]
   [ Schleifeninhalt ]
Ende solange

wiederhole
   [ Schleifeninhalt ]
solange [ Bedingung ]

:=

=; <; >; <=; >=; <>

integer
double
string
boolean
array

public interface Wartbar {
    void warten();
    int getBetriebsstunden();
}

public abstract class Foerdermodul {
    protected int modulNr;
    private boolean aktiv;

    public Foerdermodul(int modulNr) {
        this.modulNr = modulNr;
    }
    public abstract void starten();
    public boolean isAktiv() {
        return aktiv;
    }
    protected void setAktiv(boolean aktiv) {
        this.aktiv = aktiv;
    }
}

public class Foerderband extends Foerdermodul
                         implements Wartbar {
    private double geschwindigkeit;  // m/s
    private int betriebsstunden;

    public Foerderband(int modulNr,
                       double geschwindigkeit) {
        super(modulNr);
        this.geschwindigkeit = geschwindigkeit;
    }
    public void starten() {
        setAktiv(true);
    }
    public void warten() {
        betriebsstunden = 0;
    }
    public int getBetriebsstunden() {
        return betriebsstunden;
    }
}

public class Kiste {
    private int nummer;
    private int kapazitaet;
    private List<String> barcodes;

    public Kiste(int nummer, int kapazitaet) {
        this.nummer = nummer;
        this.kapazitaet = kapazitaet;
        this.barcodes = new ArrayList<>();
    }
    public boolean istVoll() {
        return barcodes.size() >= kapazitaet;
    }
    public void ablegen(String barcode) {
        barcodes.add(barcode);
    }
    void leeren() {
        barcodes.clear();
    }
}

public class Sortieranlage {
    private static int anzahlAnlagen = 0;
    private String standort;
    private Foerderband band;
    private List<Kiste> kisten;

    public Sortieranlage(String standort,
                         Foerderband band) {
        this.standort = standort;
        this.band = band;
        this.kisten = new ArrayList<>();
        for (int i = 1; i <= 6; i++) {
            kisten.add(new Kiste(i, 40));
        }
        anzahlAnlagen++;
    }
    public int sortiere(String barcode,
                        int zielKiste) {
        Kiste k = kisten.get(zielKiste - 1);
        k.ablegen(barcode);
        if (k.istVoll()) {
            return -1;
        }
        return zielKiste;
    }
    public static int getAnzahlAnlagen() {
        return anzahlAnlagen;
    }
}

public class Selbstverbucher {
    private BiblioNetClient server;
    private Drucker drucker;

    public Selbstverbucher(BiblioNetClient server, Drucker drucker) {
        this.server = server;
        this.drucker = drucker;
    }

    public void ausleihen(String leserNr, List<String> barcodes) {
        Leser leser = server.ladeLeser(leserNr);
        if (leser.istGesperrt()) {
            zeigeHinweis("Konto gesperrt - bitte an die Theke wenden");
        } else {
            Quittung q = new Quittung(leserNr);
            for (String code : barcodes) {
                LocalDate faellig = server.verbuche(leserNr, code);
                q.hinzufuegen(code, faellig);
            }
            drucker.drucke(q);
        }
    }

    private void zeigeHinweis(String text) {
        // Ausgabe auf dem Display des Terminals
    }
}

C · Aufgaben

Alle Aufgaben beziehen sich auf die Ausgangssituation in Anlage 1. Diagramme sind in UML-Notation (bzw. als Struktogramm/PAP nach DIN) zu zeichnen; nutzen Sie den Belegsatz. Wo eine Zeichenfläche vorgegeben ist, zeichnen Sie direkt hinein.

UML-01 · Verhaltensdiagramme allgemein / Diagrammwahl

UML-02 · Aktivitätsdiagramm

UML-03 · Klassendiagramm

UML-04 · Zustandsdiagramm

UML-05 · Use-Case-Diagramm

UML-06 · Sequenzdiagramm

UML-07 · Struktogramm / PAP

funktion faelligkeit(medientyp : string, ausleihTag : integer, geschlossen : boolean[]) : integer
  frist : integer
  wenn medientyp = "Buch" oder medientyp = "Hörbuch" dann
    frist := 28
  sonst
    wenn medientyp = "Film" oder medientyp = "Spiel" dann
      frist := 14
    sonst
      wenn medientyp = "Zeitschrift" dann
        frist := 7
      sonst
        frist := 21
      Ende wenn
    Ende wenn
  Ende wenn
  tag : integer := ausleihTag + frist
  solange geschlossen[tag] = wahr
    tag := tag + 1
  Ende solange
  rückgabe tag
Ende funktion

Originalaufgaben zum Üben

Diese echten Prüfungsaufgaben passen zu diesem Block (Dateien im Ordner Prüfungsvorbereitung). Lösungen gibt es nur für 2023 Sommer, 2023 Winter, 2024 Sommer und 2025 Winter (dort vom u-form-Verlag). Die Belegsätze mit den IHK-Notationen liegen für W21, S22, W22, S24 und W25 vor (z. B. 2024/sommer/AE Sommer 2024 Belegsatz.pdf).