Block 03 · UML-Modellierung – Lösungen

a) Struktur oder Verhalten (2 P)

b) Geeignete Diagramme (3 P)

Erklärung: Häufigster Fehler: Das Anwendungsfalldiagramm wird für ein Strukturdiagramm gehalten, weil es keine Reihenfolge zeigt. Es beschreibt aber, was das System für seine Akteure tut, und gehört deshalb zu den Verhaltensdiagrammen.

a) Ablauf nach „Ausleihe verbuchen“ (2 P)

Nach dem Verbuchen sollen zwei Schritte unabhängig voneinander (parallel) ausgeführt werden: Die Diebstahlsicherung des Mediums wird deaktiviert und das Rückgabedatum wird angezeigt. Erst wenn beides erledigt ist, fragt das Terminal, ob weitere Medien ausgeliehen werden sollen. Bei „ja“ legt der Leser das nächste Medium auf und der Ablauf wiederholt sich ab dort; bei „nein“ wird eine Quittung gedruckt und der Vorgang endet.

b) Fehler, Auswirkung, Korrektur (8 P)

Erklärung: Mit dem Marken-Modell (Erklärungssatz UML-02) lassen sich alle vier Fehler begründen: Raute = ein Weg (ODER), Balken = alle Wege (UND). Eine Aktion mit zwei Eingängen wartet auf beide – deshalb laufen Schleifen immer über eine Zusammenführung.

a) Diagrammwahl (6 P)

b) Zustandsdiagramm eines Fachs (10 P)

• Die Abholfrist wird als Ereignis abholfristAbgelaufen modelliert, weil sie durch die Verlängerung verschoben werden kann. Die Verlängerung ist eine interne Transition im Zustand „Belegt“: Das Fach bleibt belegt, die entry-Aktion (neuer Abholcode) wird nicht erneut ausgeführt.
• „Geöffnet“ ist ein eigener Zustand, weil das Fach zwischen dem Entriegeln und dem Schließen der Tür weder belegt noch frei ist und das Ereignis türGeschlossen hier eine andere Wirkung hat als im Zustand „Reserviert“.

c) Zustands- statt Aktivitätsdiagramm (4 P)

• Ereignisgesteuertes Verhalten eines Objekts: Ein Fach „wartet“ die meiste Zeit in einem Zustand (frei, belegt) auf Ereignisse, die in beliebiger Reihenfolge eintreffen können (Sensor, Code, Fristablauf). Das Zustandsdiagramm zeigt genau das; ein Aktivitätsdiagramm beschreibt eine Folge von Tätigkeiten und kann dieses Warten nur umständlich darstellen.
• Gleiches Ereignis, unterschiedliche Wirkung: „Tür geschlossen“ führt im Zustand „Reserviert“ zu „Belegt“, im Zustand „Geöffnet“ zu „Frei“. Im Zustandsdiagramm ist das direkt ablesbar; im Aktivitätsdiagramm wären viele Verzweigungen nötig.
• (weiterer möglicher Grund) Zeitereignisse und entry-Aktionen lassen sich direkt notieren, und das Diagramm kann fast unverändert als Zustandsautomat (z. B. Aufzählungstyp + switch) programmiert werden.

a) Elemente (4 P)

b) Wann wird „Ausweis aushändigen“ ausgeführt? (2 P)

Erst wenn beide parallelen Aktionen „Ausweis drucken“ und „Zugangsdaten für die App senden“ abgeschlossen sind. Die Synchronisation ⑦ wartet, bis an allen eingehenden Kanten der Ablauf angekommen ist (UND-Verknüpfung), und setzt den Ablauf dann einmal fort.

Erklärung: Signalwörter: „gleichzeitig“ → Teilung, „sind beide Schritte abgeschlossen“ → Synchronisation, „in beiden Fällen“ → Zusammenführung der beiden Wege, „wiederholt sich ab dem Einlegen“ → Rückführung in eine Zusammenführung vor „Medium einlegen“, „sofern gewünscht“ → Entscheidung mit einem Weg ohne Aktion.

Erklärung: Die Schleife ist der schwierigste Teil: Der Text sagt „wähle die nächste Partnerbibliothek aus und sende die Bestellung dorthin“ – deshalb führt der Rückweg vor „Bestellung absenden“ und nicht vor die Teilung (die Gebühr wird nur einmal gebucht). Die Entscheidung „weitere Partnerbibliothek vorhanden?“ trifft die Fernleihstelle und steht deshalb in deren Bahn.

a) Multiplizitäten (3 P)

1. Leser – Ausleihe: Ein Leser hat beliebig viele (auch keine) Ausleihen (0..*). Jede Ausleihe gehört zu genau einem Leser (1).
2. Medium – Exemplar: Ein Medium hat mindestens ein Exemplar (1..*). Jedes Exemplar gehört zu genau einem Medium (1); als Komposition werden die Exemplare mit ihrem Medium gelöscht.
3. Leser – Leser: Ein Leser kann als Hauptkonto bis zu vier Mitleser haben (0..4 an der Rolle mitleser). Ein Leser hat höchstens ein Hauptkonto (0..1 an der Rolle hauptkonto) – er ist also entweder eigenständig oder Mitleser genau eines Familienkontos.

b) Notationen (3 P)

1. # = protected: Auf titel dürfen die Klasse Medium und ihre Unterklassen (Buch, Film) zugreifen (in Java zusätzlich Klassen im selben Paket), andere Klassen nicht.
2. Unterstrichen = statisch (Klassenattribut): Der Wert gehört der Klasse, nicht dem einzelnen Objekt; alle Ausleihen teilen sich denselben Wert 2 (hier eine Konstante).
3. Kursiv = abstrakt: Von Medium können keine Objekte erzeugt werden, nur von den Unterklassen. getLeihfrist() hat in Medium keine Implementierung und muss in Buch und Film überschrieben werden.

a) Klassendiagramm (9 P)

• Foerdermodul ist abstrakt (Name kursiv bzw. {abstract}), ebenso die Methode starten(). Wartbar ist ein Interface.
• anzahlAnlagen und getAnzahlAnlagen() sind static → unterstrichen (oder {static}). leeren() hat keinen Modifizierer → Sichtbarkeit package ~.
• Die Attribute band und kisten werden als Beziehungen dargestellt (Rollennamen am Linienende), nicht zusätzlich als Attribute. barcodes ist eine Liste von Strings und bleibt ein Attribut.
• Multiplizität der Kisten: Der Konstruktor erzeugt genau 6 Kisten → 6; 1..* oder * wird ebenfalls akzeptiert.

b) Aggregation oder Komposition? (3 P)

• Sortieranlage – Kiste: Komposition. Die Sortieranlage erzeugt ihre Kisten selbst im Konstruktor (new Kiste(i, 40)) und gibt keine Referenzen nach außen. Die Kisten existieren nur als Teil dieser Anlage und werden mit ihr gelöscht.
• Sortieranlage – Foerderband: Aggregation. Das Förderband wird außerhalb erzeugt und dem Konstruktor übergeben. Es existiert unabhängig von der Sortieranlage und kann an eine andere Anlage übergeben werden.

a) Klassendiagramm (16 P)

b) Reihenfolge der Anmeldungen (2 P)

Am Assoziationsende bei Anmeldung (Beziehung Termin – Anmeldung) steht die Eigenschaft {ordered}: Die Anmeldungen eines Termins bilden eine geordnete Liste (Reihenfolge des Eingangs), z. B. umgesetzt als List<Anmeldung>.

c) Gewählte Beziehungsarten (4 P)

• Standort – Raum: Komposition (gefüllte Raute am Standort). Räume sind existenzabhängig: Wird ein Standort aufgegeben, werden seine Räume gelöscht. Ein Raum gehört zu genau einem Standort.
• Veranstaltung – Referent: Aggregation (hohle Raute an der Veranstaltung). Referenten existieren unabhängig, können bei mehreren Veranstaltungen mitwirken (0..* am Ganzen) und bleiben beim Löschen einer Veranstaltung erhalten.

a) Folgezustand und Aktionen (2 P)

Der Saldo steigt auf 10,50 €. Das Ereignis gebuehrGebucht trifft auf die Transition mit [saldo >= 10] → Folgezustand Gesperrt. Reihenfolge: (Aktiv hat keine exit-Aktion) → Aktion an der Transition „Sperrhinweis senden“ → entry-Aktion von Gesperrt „Ausleihe sperren“.

b) Bestandteile der Beschriftung (2 P)

• gebuehrGebucht – Ereignis (Auslöser): löst die Transition aus.
• [saldo >= 10] – Bedingung (Guard): muss beim Eintreten des Ereignisses erfüllt sein, sonst schaltet diese Transition nicht (dann greift die Selbsttransition mit [saldo < 10]).
• / Sperrhinweis senden – Aktion (Effekt): wird beim Schalten der Transition ausgeführt.

c) entry und exit (1 P)

entry wird bei jedem Betreten des Zustands Gesperrt ausgeführt (Ausleihe sperren), exit bei jedem Verlassen (Ausleihe freigeben) – unabhängig davon, über welche Transition der Zustand betreten oder verlassen wird.

• Die Selbsttransition an „Zurückgelegt“ ist gewollt: Sie verlässt den Zustand und betritt ihn neu, dadurch wird die entry-Aktion erneut ausgeführt und automatisch der nächste Leser benachrichtigt („bei jedem Zurücklegen“).
• Für das Verlängern ist auch eine interne Transition im Zustand „Ausgeliehen“ korrekt (der Zustand hat keine entry-Aktion, das Verhalten ist gleich).

a) Zustandsdiagramm (19 P)

b) entry statt Transitionsaktion (2 P)

„Bereit“ wird über viele Transitionen betreten (nach dem Selbsttest, nach dem Auswurf, nach dem Transport, nach dem Kistentausch). Mit entry wird die Klappe bei jedem Betreten entriegelt, ohne die Aktion an jede eingehende Transition schreiben zu müssen. Das Diagramm bleibt übersichtlich, und bei neuen Transitionen nach „Bereit“ kann die Aktion nicht vergessen werden.

c) Not-Aus mit zusammengesetztem Zustand (4 P)

Die fünf Zustände werden zu einem zusammengesetzten Zustand „Betrieb“ zusammengefasst; sein innerer Startzustand führt zu „Bereit“. Eine einzige Transition notAus geht vom Rand des zusammengesetzten Zustands nach „Störung“ und gilt damit für jeden Unterzustand. Vorteil: eine Transition statt fünf, übersichtlicher und weniger fehleranfällig; ein später ergänzter Unterzustand erhält das Not-Aus automatisch. Der Pfeil kisteGetauscht endet am Rand von „Betrieb“: Der Automat beginnt dann wieder beim inneren Startzustand, also in „Bereit“.

a) include und extend (2 P)

«include»: Der Basis-Anwendungsfall bindet einen anderen Anwendungsfall immer ein (Pflichtbestandteil, oft von mehreren Fällen gemeinsam genutzt). Pfeil vom Basisfall zum eingebundenen Fall.
«extend»: Ein erweiternder Anwendungsfall wird nur optional, unter einer Bedingung und an einem Erweiterungspunkt, in den Basisfall eingefügt; der Basisfall ist auch ohne ihn vollständig. Pfeil vom erweiternden Fall zum Basisfall.

b) Zuordnung (2 P)

c) Systemgrenze (1 P)

Das Rechteck um die Anwendungsfälle grenzt das betrachtete System (seinen Funktionsumfang) von der Umgebung ab: Was innerhalb liegt, leistet das System; die Akteure stehen außerhalb und nutzen es.

a) Fehler und Korrekturen (6 P, vier von sechs genügen)

b) Use-Case-Beschreibung „Medien abholen“ (4 P)

a) Use-Case-Diagramm (16 P)

• Leser erben von Besucher (Generalisierung, Dreieck beim Besucher) und dürfen deshalb auch den Katalog durchsuchen, ohne dass eine eigene Linie nötig ist. Ebenso erbt das Fernleihpersonal vom Thekenpersonal.
• „Gebühren bezahlen“ hat eine eigene Assoziation zum Leser („unabhängig davon jederzeit“) und erweitert „Ausleihe verlängern“ am Erweiterungspunkt „Kontosperre“.
• „Leserkonto prüfen“ wird von „Medium vormerken“ und „Ausleihe verlängern“ eingebunden (include – „immer“).
• PayFix und der Verbundkatalog sind externe Systeme und stehen als Akteure außerhalb der Systemgrenze. Die Anmeldung wird laut Anlage nicht modelliert.

b) User Stories (4 P)

• Als Leser möchte ich eine Ausleihe in der App verlängern, damit ich das Medium länger nutzen kann, ohne in die Bibliothek zu kommen.
  Akzeptanzkriterien: Eine Verlängerung ist höchstens zweimal möglich und nur, wenn keine Vormerkung vorliegt. Nach der Verlängerung wird das neue Fälligkeitsdatum angezeigt. Bei gesperrtem Konto erscheint ein Hinweis mit der Möglichkeit, die Gebühren direkt zu bezahlen.
• Als Besucher möchte ich ein Buch per Barcode-Scan im Katalog suchen, damit ich schnell sehe, ob die Bibliothek es hat.

a) synchron und asynchron (2 P)

verlaengern(exemplarNr) ist eine synchrone Nachricht (gefüllte Pfeilspitze): Die App wartet, bis der KontoService die Verlängerung bearbeitet hat und das neue Datum bzw. „abgelehnt“ zurückgibt. sendeBestaetigung(leserNr) ist asynchron (offene Spitze): Der KontoService beauftragt den PushDienst und arbeitet sofort weiter, ohne auf eine Antwort zu warten.

b) Fragment alt (1 P)

Von den beiden Bereichen wird genau einer ausgeführt: Ist das Konto nicht gesperrt, wird die Fälligkeit aktualisiert, eine Bestätigung gesendet und das neue Datum zurückgegeben; andernfalls ([else]) wird „abgelehnt“ zurückgegeben.

c) Rechtecke und gestrichelte Pfeile (1 P)

Die Rechtecke sind Aktivierungsbalken (das Objekt führt gerade eine Methode aus); die gestrichelten Pfeile sind Antworten (Rückgabewerte) auf synchrone Nachrichten.

d) Fragmente (1 P)

(1) opt, (2) loop.

• leser:Leser ist das Objekt, das ladeLeser() zurückgibt; istGesperrt() wird an dieses Objekt geschickt.
• if/else → alt; zeigeHinweis() ist eine eigene Methode → Selbstaufruf.
• new Quittung(leserNr) → create-Pfeil auf den Kopf der Lebenslinie q:Quittung, die erst dort beginnt.
• for (String code : barcodes) → loop mit zwei Nachrichten pro Durchlauf.

a) Sequenzdiagramm (16 P)

b) speichere() asynchron (2 P)

Der KatalogService braucht vom Cache keine Antwort, um weiterzuarbeiten – laut Anlage 10 wartet er nicht auf eine Bestätigung. Das Speichern im Cache soll die Antwortzeit für den Leser nicht verlängern; deshalb wird die Nachricht asynchron (offene Pfeilspitze, keine Antwort) modelliert.

c) opt und alt (2 P)

opt hat einen Bereich mit einer Bedingung, der nur ausgeführt wird, wenn sie zutrifft – sonst passiert nichts. alt hat mehrere Bereiche mit Bedingungen, von denen genau einer ausgeführt wird. Für die Schritte 4/5 wurde opt [treffer = null] verwendet, weil bei einem Cache-Treffer keine Nachrichten anfallen. Ein alt mit leerem Bereich [treffer vorhanden] und [else] ist gleichwertig.

a) Rückgabewerte (2 P)

b) Strukturblöcke (1 P)

Sequenz (Folge von Anweisungen), Verzweigung (zweiseitig bzw. einseitig mit leerem Zweig ∅), Zählschleife.

c) Strukturblock für den Medientyp (1 P)

Fallauswahl (Mehrfachverzweigung) über den Medientyp.

Java · Aufgabe_UML_07_1.java (Auszug)

static double gebuehrGesamt(int[] tage, boolean istKind) {
    double summe = 0.00;
    if (istKind) {
        // leerer Zweig
    } else {
        for (int i = 0; i <= tage.length - 1; i++) {
            double g = tage[i] * 0.50;
            if (g > 5.00) {
                g = 5.00;
            }
            summe = summe + g;
        }
    }
    return summe;
}

Ausgabe

gebuehrGesamt([4, 15, 0, 9], falsch)   ->  11,50  (erwartet  11,50) OK
gebuehrGesamt([12], wahr)              ->   0,00  (erwartet   0,00) OK
gebuehrGesamt([10, 11], falsch)        ->  10,00  (erwartet  10,00) OK
gebuehrGesamt([], falsch)              ->   0,00  (erwartet   0,00) OK

Datei: java\03_UML\Aufgabe_UML_07_1.java

a) Struktogramm (6 P)

b) Warum kopfgesteuert? (2 P)

Ist der berechnete Tag bereits ein Öffnungstag, darf er nicht verändert werden – der Schleifenrumpf darf also gar nicht ausgeführt werden. Eine kopfgesteuerte Schleife prüft die Bedingung vor dem ersten Durchlauf. Eine fußgesteuerte Schleife führt den Rumpf mindestens einmal aus; die Fälligkeit läge dann immer mindestens einen Tag zu spät (Beispiel: Buch, ausgeliehen an Tag 100 → richtig 128, fußgesteuert 129).

Java · Aufgabe_UML_07_2.java (Auszug)

static int faelligkeit(String medientyp, int ausleihTag, boolean[] geschlossen) {
    int frist;
    switch (medientyp) {                        // Fallauswahl
        case "Buch", "Hörbuch" -> frist = 28;
        case "Film", "Spiel" -> frist = 14;
        case "Zeitschrift" -> frist = 7;
        default -> frist = 21;
    }
    int tag = ausleihTag + frist;
    while (geschlossen[tag]) {                  // kopfgesteuert
        tag = tag + 1;
    }
    return tag;
}

Ausgabe (Testdaten: Tage 114, 115 und 121 geschlossen)

Film, ausgeliehen an Tag 100        -> 116 (erwartet 116)
Buch, ausgeliehen an Tag 100        -> 128 (erwartet 128)
Zeitschrift, ausgeliehen an Tag 114 -> 122 (erwartet 122)
Noten, ausgeliehen an Tag 100       -> 122 (erwartet 122)
fußgesteuert, Buch an Tag 100       -> 129 (falsch: 129 statt 128, ein Tag zu spät)

Datei: java\03_UML\Aufgabe_UML_07_2.java

a) Schreibtischtest des fehlerhaften Struktogramms mit 40517287 (4 P)

Richtig wäre: 4·1 + 0·3 + 5·1 + 1·3 + 7·1 + 2·3 + 8·1 = 33 → pz = (10 − 3) mod 10 = 7 = letzte Ziffer → wahr.

b) Fehler und Korrekturen (6 P)

c) PAP des korrigierten Algorithmus (4 P)

Java · Aufgabe_UML_07_3.java (korrigierte Fassung)

static boolean pruefeAusweis(String nr) {
    if (nr.length() != 8) {
        return false;
    }
    int summe = 0;                       // Korrektur 2: vor der Schleife
    int gewicht;
    for (int i = 0; i <= 6; i++) {       // Korrektur 1: nur sieben Ziffern
        if (i % 2 == 0) {
            gewicht = 1;                 // Korrektur 3: Gewichte 1, 3, 1, ...
        } else {
            gewicht = 3;
        }
        summe = summe + ziffer(nr, i) * gewicht;
    }
    int pz = (10 - summe % 10) % 10;
    return pz == ziffer(nr, 7);
}

Ausgabe

Schreibtischtest fehlerhafte Fassung mit 40517287:
  i=0  gewicht=3  ziffer=4  summe=12
  i=1  gewicht=1  ziffer=0  summe=0
  i=2  gewicht=3  ziffer=5  summe=15
  i=3  gewicht=1  ziffer=1  summe=1
  i=4  gewicht=3  ziffer=7  summe=21
  i=5  gewicht=1  ziffer=2  summe=2
  i=6  gewicht=3  ziffer=8  summe=24
  i=7  gewicht=1  ziffer=7  summe=7
  pz=3  ziffer(nr,7)=7
  Rückgabe: false  (erwartet laut Spezifikation: true)

korrigiert: pruefeAusweis("40517287") = true  OK
korrigiert: pruefeAusweis("40517280") = false  OK
korrigiert: pruefeAusweis("12345678") = true  OK
korrigiert: pruefeAusweis("1234567") = false  OK
korrigiert: pruefeAusweis("00000000") = true  OK

Datei: java\03_UML\Aufgabe_UML_07_3.java (enthält die fehlerhafte und die korrigierte Fassung)