Diagramme & Modelle für die IHK

• Seite 1. Überblick – Welches Diagramm wofür?
• Seite 2. Gesamttrainer – Diagramm-Auswahl
• Seite 3. ERM – Entity-Relationship-Modell
• Seite 4. ERM-Trainer
• Seite 5. Relationales Datenbankmodell
• Seite 6 Relationales-Datenbankmodell-Trainer
• Seite 7. UML-Klassendiagramm
• Seite 8. UML-Klassendiagramm-Trainer
• Seite 9. UML-Aktivitätsdiagramm
• Seite 10. UML-Aktivitätsdiagramm-Trainer
• Seite 11. UML-Anwendungsfalldiagramm
• Seite 12. UML-Anwendungsfalldiagramm-Trainer
• Seite 13. UML-Sequenzdiagramm
• Seite 14. UML-Sequenzdiagramm-Trainer
• Seite 15: Mock-up / Benutzeroberflächen-Entwurf
• Seite 16: Mock-up-Trainer

Seite 1. Überblick – Welches Diagramm wofür?

Ziel dieser Seite ist nicht, jedes Diagramm sofort vollständig zu können.
Das Ziel ist zuerst: schnell erkennen, welches Diagramm zu welcher Aufgabenstellung passt.

Warum sind diese Diagramme wichtig?

In IHK-Aufgaben wird oft nicht direkt gefragt:
„Erstelle ein UML-Aktivitätsdiagramm.“

Stattdessen steht dort eher eine Situation wie:

• „Stellen Sie den Ablauf dar.“
• „Modellieren Sie die Datenstruktur.“
• „Zeigen Sie die Beziehungen zwischen Klassen.“
• „Entwerfen Sie eine Benutzeroberfläche.“
• „Stellen Sie die Kommunikation zwischen Objekten dar.“

Dann musst du erkennen, welches Modell oder Diagramm gemeint ist.

Die wichtigsten Diagrammarten im Überblick

Merksatz

Wenn du eine Aufgabe liest, frage dich zuerst:

Schnellentscheidung für die Prüfung

1. Aufgabe spricht von Daten?

Beispiele:

• Kunde
• Bestellung
• Produkt
• Rechnung
• Kurs
• Schüler
• Beziehung
• Kardinalität

Dann denke zuerst an:

ERM oder relationales Datenbankmodell

Unterschied:

2. Aufgabe spricht von Programmstruktur?

Beispiele:

• Klasse
• Attribut
• Methode
• Objekt
• Vererbung
• Produktverwaltung
• Java-Klassen

Dann denke zuerst an:

UML-Klassendiagramm

Typisch für Java:

Produkt
- marke
- modell
- preis
+ toString()

Seite 2. Gesamttrainer – Diagramm-Auswahl

Interaktiver Trainer

Mit diesem Trainer kannst du üben, welche Diagrammart zu welcher Aufgabenstellung passt.

Seite 3. ERM – Entity-Relationship-Modell

ERM – Entity-Relationship-Modell

Diese Seite erklärt das ERM so, dass du es schnell für IHK-Aufgaben anwenden kannst.

ERM bedeutet:

Entity-Relationship-Modell

Auf Deutsch:

Entitäten-Beziehungs-Modell

Ein ERM wird benutzt, um Daten und deren Beziehungen zu planen, bevor daraus später Tabellen in einer Datenbank entstehen.

Grafik 1: ERM-Grundlagen im Überblick

Diese Grafik zeigt dir die wichtigsten Bausteine des ERM auf einen Blick:

• Entität
• Attribut
• Beziehung
• Kardinalität
• die wichtigsten Kardinalitäten 1:1, 1:n und n:m
• typische Signalwörter, an denen du in einer IHK-Aufgabe erkennst, dass ein ERM gemeint ist

Wofür braucht man ein ERM?

Ein ERM hilft dir, aus einer fachlichen Beschreibung ein Datenmodell zu bauen.

Beispiel:

Ein Kunde kann mehrere Bestellungen aufgeben.
Eine Bestellung gehört immer zu genau einem Kunden.
Eine Bestellung enthält mehrere Produkte.
Ein Produkt kann in mehreren Bestellungen enthalten sein.

Daraus erkennt man:

• Es gibt Datenobjekte.
• Diese Datenobjekte haben Eigenschaften.
• Diese Datenobjekte stehen miteinander in Beziehung.
• Manche Beziehungen haben bestimmte Anzahlen, zum Beispiel 1:n oder n:m.

Genau dafür ist ein ERM da.

Woran erkenne ich in einer Aufgabe, dass ein ERM gemeint ist?

Typische Signalwörter:

Grundbausteine eines ERM

Entität

Eine Entität ist ein wichtiges Datenobjekt, über das Informationen gespeichert werden sollen.

Beispiele:

• Kunde
• Bestellung
• Produkt
• Rechnung
• Mitarbeiter
• Kurs
• Raum
• Gerät

Merksatz:

Entitäten sind meistens Hauptwörter.

Beispiel:

Ein Kunde bestellt ein Produkt.

Mögliche Entitäten:

Kunde
Produkt
Bestellung

Attribut

Ein Attribut ist eine Eigenschaft einer Entität.

Beispiel Entität Kunde:

Beispiel Entität Produkt:

Merksatz:

Attribute beschreiben eine Entität genauer.

Primärschlüssel

Ein Primärschlüssel identifiziert jeden Datensatz eindeutig.

Beispiele:

kunden_id
produkt_id
bestellung_id

Warum braucht man Primärschlüssel?

Weil Namen nicht eindeutig sein müssen.

Beispiel:

Es kann mehrere Kunden mit dem Namen Müller geben.

Aber:

kunden_id = 1001

ist eindeutig.

Merksatz:

Jede Entität braucht einen eindeutigen Primärschlüssel.

Beziehung

Eine Beziehung beschreibt, wie zwei Entitäten zusammenhängen.

Beispiel:

Kunde gibt Bestellung auf

Entitäten:

Kunde
Bestellung

Beziehung:

gibt auf

Darstellung als einfache Textform:

Kunde -- gibt auf -- Bestellung

Weitere Beispiele:

Kardinalität

Die Kardinalität beschreibt, wie viele Datensätze miteinander verbunden sein können.

Die wichtigsten Kardinalitäten:

Grafik 2: ERM-Beispiel mit Kunde, Bestellung, Produkt und Bestellposition

Diese Grafik zeigt ein typisches vollständiges ERM-Beispiel:

• Kunde gibt Bestellung auf → 1:n
• Bestellung enthält Produkt → fachlich n:m
• Die n:m-Beziehung wird durch Bestellposition aufgelöst
• Dadurch entstehen später sauberere Tabellen für die Datenbank

1:1-Beziehung

Beispiel:

Eine Person hat genau einen Personalausweis.
Ein Personalausweis gehört genau zu einer Person.

Darstellung:

Person 1 --- 1 Personalausweis

Das ist eine 1:1-Beziehung.

1:n-Beziehung

Beispiel:

Ein Kunde kann mehrere Bestellungen haben.
Eine Bestellung gehört genau zu einem Kunden.

Darstellung:

Kunde 1 --- n Bestellung

Das ist eine 1:n-Beziehung.

Merksatz:

Wenn ein Objekt mehrere andere haben kann, ist es meistens 1:n.

n:m-Beziehung

Beispiel:

Eine Bestellung kann mehrere Produkte enthalten.
Ein Produkt kann in mehreren Bestellungen vorkommen.

Darstellung:

Bestellung n --- m Produkt

Das ist eine n:m-Beziehung.

Wichtig:

Eine n:m-Beziehung kann man in einer relationalen Datenbank nicht direkt einfach speichern.

Deshalb wird daraus später eine Zwischentabelle.

Beispiel:

Bestellung
Produkt
Bestellposition

Die Zwischentabelle könnte heißen:

Bestellposition

Typische Attribute der Zwischentabelle:

ERM-Beispiel: Kunde, Bestellung, Produkt

Fachliche Beschreibung:

Ein Kunde kann mehrere Bestellungen aufgeben.
Eine Bestellung gehört immer zu genau einem Kunden.
Eine Bestellung kann mehrere Produkte enthalten.
Ein Produkt kann in mehreren Bestellungen enthalten sein.

Entitäten:

Beziehungen:

Das n:m zwischen Bestellung und Produkt wird durch Bestellposition aufgelöst.

ERM vs. relationales Datenbankmodell

Merksatz:

ERM plant die Daten fachlich. Das relationale Modell macht daraus Tabellen.

Vorgehensweise in der Prüfung

Wenn du eine ERM-Aufgabe bekommst, gehe so vor:

Typische IHK-Fehler beim ERM

Prüfungs-Merksätze

Entität = wichtiges Datenobjekt
Attribut = Eigenschaft einer Entität
Beziehung = Verbindung zwischen Entitäten
Kardinalität = Wie viele gehören zusammen?
1:n = einer zu vielen
n:m = viele zu vielen
n:m braucht später eine Zwischentabelle
Primärschlüssel = eindeutig
ERM = fachliches Datenmodell
Relationales Modell = Tabellenmodell

Mini-Testfragen

Kunde
- kunden_id
- name
- email

Eine Bestellung kann mehrere Produkte enthalten.
Ein Produkt kann in mehreren Bestellungen vorkommen.

Bestellung n:m Produkt

Bestellung 1:n Bestellposition n:1 Produkt

Nächste Seite

Danach kommt die eigene Trainer-Seite:

ERM-Trainer

Dort bauen wir den interaktiven ERM-Trainer mit Aufgaben zu:

Entität erkennen
Attribute zuordnen
Beziehung bestimmen
Kardinalität wählen
n:m-Zwischentabelle erkennen

Seite 4. ERM-Trainer

ERM-Trainer

Dieser interaktive Trainer gehört zur Theorie-Seite:

ERM – Entity-Relationship-Modell

Hier übst du, aus kurzen Aufgabenstellungen die wichtigsten Bestandteile eines ERM zu erkennen:

Entität 1
Entität 2
Beziehung
Kardinalität
Zwischentabelle bei n:m-Beziehungen

Was wird trainiert?

Interaktiver ERM-Trainer

Merksatz für den Trainer

Entität = wichtiges Datenobjekt
Beziehung = Verbindung zwischen Entitäten
Kardinalität = Wie viele gehören zusammen?
1:n = einer zu vielen
n:m = viele zu vielen
n:m = meistens Zwischentabelle nötig

Beispiel

Aufgabenstellung:

Ein Schüler kann mehrere Kurse belegen.
Ein Kurs kann von mehreren Schülern belegt werden.

Lösung:

Warum?

Viele Schüler können viele Kurse belegen.
Deshalb ist es eine n:m-Beziehung.
Eine n:m-Beziehung braucht später meistens eine Zwischentabelle.

Mini-Testfragen

Ein Kunde kann mehrere Bestellungen aufgeben.

Kunde
Bestellung

Ein Kunde kann mehrere Bestellungen haben.
Eine Bestellung gehört genau zu einem Kunden.

Kunde 1:n Bestellung

Ein Schüler kann mehrere Kurse belegen.
Ein Kurs kann von mehreren Schülern belegt werden.

Schüler n:m Kurs

Schüler n:m Kurs

Schüler 1:n Belegung n:1 Kurs

Belegung
- schueler_id
- kurs_id
- anmeldedatum

Nächste Seite

Danach geht es weiter mit:

Relationales Datenbankmodell

Seite 5. Relationales Datenbankmodell

Relationales Datenbankmodell

Diese Seite erklärt das relationale Datenbankmodell so, dass du es schnell für IHK-Aufgaben anwenden kannst.

Das relationale Datenbankmodell beschreibt, wie Daten in Tabellen gespeichert werden.

Dabei sind besonders wichtig:

Tabellen
Datensätze
Attribute / Spalten
Primärschlüssel
Fremdschlüssel
Beziehungen zwischen Tabellen

Grafik 1: Grundlagen des relationalen Datenbankmodells

Diese Grafik zeigt dir die wichtigsten Grundbegriffe:

• Tabelle
• Datensatz
• Primärschlüssel
• Fremdschlüssel
• Zusammenhang zwischen Zeilen, Spalten und Schlüsseln

Wofür braucht man das relationale Datenbankmodell?

Das relationale Datenbankmodell wird benutzt, um ein fachliches Datenmodell technisch näher an eine echte Datenbank zu bringen.

Ein ERM zeigt zuerst fachlich:

Kunde gibt Bestellung auf

Das relationale Modell macht daraus Tabellen:

Kunde
Bestellung

Und legt fest:

Welche Spalten gibt es?
Was ist der Primärschlüssel?
Wo wird ein Fremdschlüssel benötigt?
Wie hängen die Tabellen zusammen?

Woran erkenne ich in einer Aufgabe, dass ein relationales Datenbankmodell gemeint ist?

Typische Signalwörter:

Grundbegriffe

Tabelle

Eine Tabelle speichert gleichartige Daten.

Beispiel Tabelle Kunde:

Die Tabelle hat:

• Spalten
• Zeilen
• Datensätze
• einen Primärschlüssel

Datensatz

Ein Datensatz ist eine einzelne Zeile in einer Tabelle.

Beispiel:

Dieser eine Kunde ist ein Datensatz.

Merksatz:

Datensatz = eine vollständige Zeile einer Tabelle

Attribut / Spalte

Ein Attribut ist im relationalen Modell eine Spalte.

Beispiel Tabelle Kunde:

kunden_id
name
email
telefon

Diese Spalten beschreiben den Kunden genauer.

Merksatz:

Attribut im ERM wird meistens zur Spalte in der Tabelle.

Primärschlüssel

Ein Primärschlüssel identifiziert jeden Datensatz eindeutig.

Beispiel:

kunden_id
produkt_id
bestellung_id

Warum ist das wichtig?

Namen sind nicht eindeutig.

Beispiel:

Müller

kann mehrfach vorkommen.

Aber:

kunden_id = 1

ist eindeutig.

Merksatz:

Jede Tabelle sollte einen Primärschlüssel haben.

Fremdschlüssel

Ein Fremdschlüssel verweist auf den Primärschlüssel einer anderen Tabelle.

Beispiel:

Tabelle Kunde:

Tabelle Bestellung:

Hier ist:

kunden_id

in der Tabelle Bestellung ein Fremdschlüssel.

Warum?

Weil er auf die Tabelle Kunde verweist.

Bestellung.kunden_id → Kunde.kunden_id

Grafik 2: Vom ERM zum relationalen Modell

Diese Grafik zeigt:

• Aus der Entität Kunde wird die Tabelle Kunde
• Aus der Entität Bestellung wird die Tabelle Bestellung
• Die 1:n-Beziehung wird durch einen Fremdschlüssel auf der n-Seite abgebildet
• In der Tabelle Bestellung steht deshalb kunden_id als Fremdschlüssel

ERM vs. relationales Datenbankmodell

Merksatz:

ERM = Was gibt es fachlich?
Relationales Modell = Wie wird es tabellarisch gespeichert?

Aus Entitäten werden Tabellen

Im ERM hast du zum Beispiel:

Kunde
Bestellung
Produkt

Im relationalen Modell werden daraus Tabellen:

Tabelle Kunde
Tabelle Bestellung
Tabelle Produkt

Beispiel:

Entität Kunde

wird zu:

Kunde(kunden_id, name, email)

Aus Attributen werden Spalten

ERM:

Kunde
- kunden_id
- name
- email

Relationales Modell:

Merksatz:

Attribute werden im relationalen Modell zu Spalten.

1:1-Beziehung im relationalen Modell

Beispiel:

Person 1 --- 1 Personalausweis

Mögliche Tabellen:

Person(person_id, name)
Personalausweis(ausweis_id, ausweisnummer, person_id)

Hier kann person_id in Personalausweis als Fremdschlüssel gespeichert werden.

Wichtig:

Bei 1:1 ist fachlich zu prüfen, ob man beide Tabellen wirklich getrennt braucht.

1:n-Beziehung im relationalen Modell

Beispiel:

Kunde 1 --- n Bestellung

Das bedeutet:

Ein Kunde kann mehrere Bestellungen haben.
Eine Bestellung gehört genau zu einem Kunden.

Tabellen:

Kunde(kunden_id, name, email)

Bestellung(bestellung_id, bestelldatum, kunden_id)

Wichtig:

Der Fremdschlüssel kommt auf die n-Seite.

Also:

kunden_id

steht in:

Bestellung

Merksatz:

Bei 1:n steht der Fremdschlüssel auf der n-Seite.

n:m-Beziehung im relationalen Modell

Beispiel:

Bestellung n --- m Produkt

Das bedeutet:

Eine Bestellung kann mehrere Produkte enthalten.
Ein Produkt kann in mehreren Bestellungen vorkommen.

Eine n:m-Beziehung kann man nicht sauber direkt mit nur einem Fremdschlüssel abbilden.

Deshalb braucht man eine Zwischentabelle.

Aus:

Bestellung n:m Produkt

wird:

Bestellung 1:n Bestellposition n:1 Produkt

Tabellen:

Bestellung(bestellung_id, bestelldatum)

Produkt(produkt_id, bezeichnung, preis)

Bestellposition(bestellung_id, produkt_id, menge)

Die Tabelle Bestellposition enthält mindestens:

Warum braucht man bei n:m eine Zwischentabelle?

Beispiel:

Eine Bestellung enthält mehrere Produkte.

Ein Produkt kann in mehreren Bestellungen vorkommen.

Zusätzlich muss man speichern:

Wie oft wurde ein Produkt bestellt?
Welcher Preis galt zum Bestellzeitpunkt?
Gab es Rabatt?

Diese Informationen gehören nicht nur zur Bestellung und nicht nur zum Produkt.

Sie gehören zur Verbindung zwischen Bestellung und Produkt.

Deshalb braucht man:

Bestellposition

Typische Umwandlung von ERM zu relationalem Modell

Beispiel: Kunde und Bestellung

Fachliche Beschreibung:

Ein Kunde kann mehrere Bestellungen aufgeben.
Eine Bestellung gehört genau zu einem Kunden.

ERM:

Kunde 1 --- n Bestellung

Relationales Modell:

Kunde(kunden_id, name, email)

Bestellung(bestellung_id, bestelldatum, kunden_id)

Erklärung:

kunden_id ist Primärschlüssel in Kunde.
kunden_id ist Fremdschlüssel in Bestellung.

Beispiel: Schüler und Kurs

Fachliche Beschreibung:

Ein Schüler kann mehrere Kurse belegen.
Ein Kurs kann von mehreren Schülern belegt werden.

ERM:

Schüler n --- m Kurs

Relationales Modell:

Schüler(schueler_id, vorname, nachname)

Kurs(kurs_id, kursname)

Belegung(schueler_id, kurs_id, anmeldedatum)

Erklärung:

Belegung ist die Zwischentabelle.
schueler_id ist Fremdschlüssel auf Schüler.
kurs_id ist Fremdschlüssel auf Kurs.

Primärschlüssel und Fremdschlüssel markieren

In der Prüfung kannst du Schlüssel zum Beispiel so kennzeichnen:

PK = Primary Key = Primärschlüssel
FK = Foreign Key = Fremdschlüssel

Beispiel:

Kunde(
  kunden_id PK,
  name,
  email
)

Bestellung(
  bestellung_id PK,
  bestelldatum,
  kunden_id FK
)

Oder kompakt:

Kunde(kunden_id PK, name, email)

Bestellung(bestellung_id PK, bestelldatum, kunden_id FK)

Zusammengesetzter Primärschlüssel

Bei Zwischentabellen kann der Primärschlüssel aus mehreren Spalten bestehen.

Beispiel:

Belegung(schueler_id, kurs_id, anmeldedatum)

Hier könnten zusammen den Datensatz eindeutig machen:

schueler_id + kurs_id

Das nennt man einen zusammengesetzten Primärschlüssel.

Alternative:

Man kann auch eine eigene ID verwenden:

belegung_id

Dann sieht die Tabelle so aus:

Belegung(belegung_id PK, schueler_id FK, kurs_id FK, anmeldedatum)

Beides kann je nach Aufgabenstellung sinnvoll sein.

Normalisierung kurz erklärt

Normalisierung bedeutet:

Daten so strukturieren, dass Wiederholungen und Fehler vermieden werden.

Einfach gesagt:

Gleiche Informationen sollen nicht unnötig mehrfach gespeichert werden.

Schlechtes Beispiel:

Problem:

Kundendaten werden mehrfach gespeichert.

Besser:

Kunde(kunden_id, name, email)

Bestellung(bestellung_id, kunden_id)

Dann stehen die Kundendaten nur einmal in der Tabelle Kunde.

Vorgehensweise in der Prüfung

Wenn du ein relationales Datenbankmodell erstellen sollst, gehe so vor:

Typische IHK-Fehler

Prüfungs-Merksätze

Tabelle = Sammlung gleichartiger Datensätze
Datensatz = eine Tabellenzeile
Attribut = Spalte
Primärschlüssel = eindeutige ID
Fremdschlüssel = Verweis auf andere Tabelle
1:n = Fremdschlüssel auf der n-Seite
n:m = Zwischentabelle nötig
ERM = fachliche Sicht
Relationales Modell = Tabellen- und Schlüssel-Sicht

Mini-Beispiel 1

Aufgabe:

Ein Kunde kann mehrere Bestellungen haben.
Eine Bestellung gehört genau zu einem Kunden.

Lösung:

Kunde(kunden_id PK, name, email)

Bestellung(bestellung_id PK, bestelldatum, kunden_id FK)

Begründung:

1:n-Beziehung.
Der Fremdschlüssel kunden_id steht auf der n-Seite, also in Bestellung.

Mini-Beispiel 2

Aufgabe:

Ein Schüler kann mehrere Kurse belegen.
Ein Kurs kann von mehreren Schülern belegt werden.

Lösung:

Schüler(schueler_id PK, vorname, nachname)

Kurs(kurs_id PK, kursname)

Belegung(schueler_id FK, kurs_id FK, anmeldedatum)

Begründung:

n:m-Beziehung.
Deshalb braucht man eine Zwischentabelle.

Mini-Beispiel 3

Aufgabe:

Eine Bestellung kann mehrere Produkte enthalten.
Ein Produkt kann in mehreren Bestellungen vorkommen.

Lösung:

Bestellung(bestellung_id PK, bestelldatum)

Produkt(produkt_id PK, bezeichnung, preis)

Bestellposition(bestellung_id FK, produkt_id FK, menge)

Begründung:

n:m-Beziehung.
Bestellposition löst die Beziehung auf und speichert zusätzlich die Menge.

Mini-Testfragen

Kunde
Produkt
Bestellung

kunden_id = 1, name = Müller, email = mueller@example.de

kunden_id
produkt_id
bestellung_id

Bestellung.kunden_id verweist auf Kunde.kunden_id

Kunde 1:n Bestellung

kunden_id

Bestellung

Schüler n:m Kurs

Schüler 1:n Belegung n:1 Kurs

menge
einzelpreis
rabatt

Informationen möglichst nur einmal speichern.

Nächste Seite

Danach kommt die eigene Trainer-Seite:

Relationales-Datenbankmodell-Trainer

Dort bauen wir den interaktiven Trainer mit Aufgaben zu:

Tabellen ableiten
Primärschlüssel bestimmen
Fremdschlüssel richtig platzieren
1:n-Beziehungen umsetzen
n:m-Beziehungen mit Zwischentabelle auflösen

Seite 6 Relationales-Datenbankmodell-Trainer

Dieser interaktive Trainer gehört zur Theorie-Seite:

Relationales Datenbankmodell

Hier übst du, aus kurzen Aufgabenstellungen ein relationales Datenbankmodell abzuleiten.

Im Fokus stehen:

Tabellen
Primärschlüssel
Fremdschlüssel
1:n-Beziehungen
n:m-Beziehungen
Zwischentabellen

Was wird trainiert?

Interaktiver Relationales-Datenbankmodell-Trainer

Merksatz für den Trainer

Entität im ERM      → Tabelle im relationalen Modell
Attribut im ERM     → Spalte in der Tabelle
Primärschlüssel     → eindeutige ID einer Tabelle
Fremdschlüssel      → Verweis auf eine andere Tabelle
1:n-Beziehung       → Fremdschlüssel auf der n-Seite
n:m-Beziehung       → Zwischentabelle mit Fremdschlüsseln

Beispiel 1: 1:n-Beziehung

Aufgabenstellung:

Ein Kunde kann mehrere Bestellungen aufgeben.
Eine Bestellung gehört genau zu einem Kunden.

Relationales Modell:

Kunde(kunden_id PK, name, email)

Bestellung(bestellung_id PK, bestelldatum, kunden_id FK)

Warum?

Kunde 1:n Bestellung

Der Fremdschlüssel steht auf der n-Seite.

Also steht:

kunden_id

in der Tabelle:

Bestellung

Beispiel 2: n:m-Beziehung

Aufgabenstellung:

Ein Schüler kann mehrere Kurse belegen.
Ein Kurs kann von mehreren Schülern belegt werden.

Relationales Modell:

Schüler(schueler_id PK, vorname, nachname)

Kurs(kurs_id PK, kursname)

Belegung(schueler_id FK, kurs_id FK, anmeldedatum)

Warum?

Schüler n:m Kurs

Eine n:m-Beziehung braucht eine Zwischentabelle.

Hier heißt sie:

Belegung

Beispiel 3: Bestellung und Produkt

Aufgabenstellung:

Eine Bestellung kann mehrere Produkte enthalten.
Ein Produkt kann in mehreren Bestellungen vorkommen.

Relationales Modell:

Bestellung(bestellung_id PK, bestelldatum)

Produkt(produkt_id PK, bezeichnung, preis)

Bestellposition(bestellung_id FK, produkt_id FK, menge)

Warum?

Bestellung n:m Produkt

Die Zwischentabelle Bestellposition löst die n:m-Beziehung auf.

Zusätzlich kann dort gespeichert werden:

menge
einzelpreis
rabatt

Typische Fehler im Trainer

Mini-Testfragen

Entität Kunde

Tabelle Kunde

Attribut name

Spalte name

kunden_id
produkt_id
bestellung_id

Bestellung.kunden_id verweist auf Kunde.kunden_id

Kunde 1:n Bestellung

kunden_id

Bestellung

Schüler n:m Kurs

Schüler 1:n Belegung n:1 Kurs

schueler_id FK
kurs_id FK

Belegung(schueler_id FK, kurs_id FK, anmeldedatum)

menge
einzelpreis
rabatt

Belegung(schueler_id, kurs_id)

Schüler n:m Kurs direkt speichern

Schüler 1:n Belegung n:1 Kurs

Nächste Seite

Danach geht es weiter mit:

UML-Klassendiagramm

Seite 7. UML-Klassendiagramm

UML-Klassendiagramm

Diese Seite erklärt das UML-Klassendiagramm so, dass du es schnell für IHK-Aufgaben und Java/OOP-Aufgaben anwenden kannst.

Ein UML-Klassendiagramm wird benutzt, um die Struktur eines Programms darzustellen.

Es zeigt:

Klassen
Attribute
Methoden
Sichtbarkeit
Beziehungen zwischen Klassen
Vererbung

Grafik 1: UML-Klassendiagramm – Grundlagen

Diese Grafik zeigt dir die wichtigsten Bausteine eines UML-Klassendiagramms:

• Klassenname
• Attribute
• Methoden
• Sichtbarkeit mit +, - und #
• Assoziation
• Vererbung

Wofür braucht man ein UML-Klassendiagramm?

Ein UML-Klassendiagramm hilft dir, die Struktur eines objektorientierten Programms zu planen.

Beispiel:

Es soll eine Produktverwaltung erstellt werden.
Ein Produkt hat eine Marke, ein Modell und einen Preis.
Monitore und Tastaturen sind spezielle Produkte.

Daraus erkennt man:

• Es gibt Klassen.
• Klassen haben Attribute.
• Klassen haben Methoden.
• Manche Klassen hängen miteinander zusammen.
• Manche Klassen können von anderen Klassen erben.

Woran erkenne ich in einer Aufgabe, dass ein UML-Klassendiagramm gemeint ist?

Typische Signalwörter:

Aufbau einer Klasse

Eine Klasse wird im UML-Klassendiagramm meistens als Rechteck mit drei Bereichen dargestellt:

┌────────────────────────┐
│ Klassenname            │
├────────────────────────┤
│ Attribute              │
├────────────────────────┤
│ Methoden               │
└────────────────────────┘

Beispiel:

┌────────────────────────┐
│ Produkt                │
├────────────────────────┤
│ - marke: String        │
│ - modell: String       │
│ - preis: double        │
├────────────────────────┤
│ + getPreis(): double   │
│ + toString(): String   │
└────────────────────────┘

Klassenname

Der Klassenname steht oben im Klassendiagramm.

Beispiele:

Produkt
Monitor
Tastatur
Kunde
Bestellung
Benutzer

Merksatz:

Klassennamen werden meistens großgeschrieben und stehen im Singular.

Also eher:

Produkt

nicht:

Produkte

Attribute

Attribute beschreiben die Eigenschaften einer Klasse.

Beispiel Klasse Produkt:

- marke: String
- modell: String
- preis: double

Das bedeutet:

Merksatz:

Attribute sind das, was ein Objekt speichert.

Methoden

Methoden beschreiben, was ein Objekt tun kann.

Beispiel:

+ getPreis(): double
+ setPreis(preis: double): void
+ toString(): String

Aufbau einer Methode:

sichtbarkeit methodenname(parameter): rückgabetyp

Beispiel:

+ setPreis(preis: double): void

Bedeutung:

Sichtbarkeit

Die Sichtbarkeit zeigt, von wo aus auf Attribute oder Methoden zugegriffen werden darf.

Für IHK und Java-Grundlagen sind besonders wichtig:

+ public
- private
# protected

Typisch in Java:

private String marke;
public String toString()

UML:

- marke: String
+ toString(): String

Attribute sind meistens private

In Java sind Attribute meistens private.

Beispiel Java:

private String marke;
private String modell;
private double preis;

UML:

- marke: String
- modell: String
- preis: double

Warum?

Damit nicht jeder direkt von außen auf die Daten zugreifen kann.

Das nennt man Kapselung.

Methoden sind oft public

Methoden, die von außen genutzt werden sollen, sind meistens public.

Beispiel Java:

public String toString() {
    return marke + " " + modell;
}

UML:

+ toString(): String

Grafik 2: Beispiel Produktverwaltung

Diese Grafik zeigt ein typisches UML-Klassendiagramm für eine Produktverwaltung:

• Produkt ist die Oberklasse
• Monitor ist eine spezielle Produktart
• Tastatur ist eine spezielle Produktart
• gemeinsame Attribute gehören in die Oberklasse
• spezielle Attribute gehören in die Unterklassen

Beispiel: Produkt als Oberklasse

Wenn mehrere Produktarten gemeinsame Eigenschaften haben, kann man eine Oberklasse verwenden.

Beispiel:

Produkt
- marke
- modell
- preis

Diese Attribute können für viele Produktarten gelten:

Monitor
Tastatur
Maus
CPU

Deshalb gehören sie in die gemeinsame Oberklasse Produkt.

Vererbung

Vererbung bedeutet:

Eine Unterklasse übernimmt Eigenschaften und Methoden einer Oberklasse.

Beispiel:

Monitor erbt von Produkt.
Tastatur erbt von Produkt.

Das bedeutet:

Monitor ist ein Produkt.
Tastatur ist ein Produkt.

UML-Darstellung:

Monitor ─────▷ Produkt
Tastatur ────▷ Produkt

Der Pfeil zeigt zur Oberklasse.

Merksatz:

Der Vererbungs-Pfeil zeigt immer zur allgemeineren Klasse.

Oberklasse und Unterklasse

Beispiel:

Produkt
- marke
- modell
- preis

Monitor
- groesseZoll
- aufloesung

Der Monitor hat dann fachlich:

marke
modell
preis
groesseZoll
aufloesung

Assoziation

Eine Assoziation ist eine normale Beziehung zwischen Klassen.

Beispiel:

Kunde gibt Bestellung auf

Als Klassendiagramm:

Kunde ───────── Bestellung

Eine Assoziation bedeutet:

Diese Klassen stehen miteinander in Beziehung.

Multiplizität

Die Multiplizität zeigt, wie viele Objekte miteinander verbunden sein können.

Beispiel:

Kunde 1 ───── 0..* Bestellung

Bedeutung:

Ein Kunde kann keine, eine oder mehrere Bestellungen haben.
Eine Bestellung gehört zu genau einem Kunden.

Unterschied Kardinalität und Multiplizität

In ERM sagt man oft:

1:n
n:m

Im UML-Klassendiagramm sieht man eher:

1
0..*
1..*
*

Beispiel:

Kunde 1 ───── 0..* Bestellung

entspricht ungefähr:

Kunde 1:n Bestellung

Aggregation und Komposition kurz erklärt

Diese beiden Beziehungen können in UML vorkommen, sind aber für den schnellen IHK-Einstieg nicht immer der Schwerpunkt.

Einfacher Merksatz:

Aggregation = hat-Beziehung, Teil kann unabhängig existieren
Komposition = besteht-aus-Beziehung, Teil ist stark abhängig

Beispiel Aggregation:

Team hat Mitarbeiter

Ein Mitarbeiter kann auch ohne dieses Team existieren.

Beispiel Komposition:

Rechnung besteht aus Rechnungspositionen

Eine Rechnungsposition ergibt ohne Rechnung meist keinen Sinn.

Unterschied Klasse und Objekt

Beispiel:

Klasse: Produkt
Objekt: monitor1

Java:

Produkt monitor1 = new Produkt("Dell", "U2723QE", 499.99);

Die Klasse beschreibt, welche Attribute und Methoden ein Objekt haben kann.

Das Objekt ist eine konkrete Instanz dieser Klasse.

UML-Klassendiagramm vs. ERM

Merksatz:

ERM = Daten fachlich modellieren
UML-Klassendiagramm = Programmklassen modellieren

Vorgehensweise in der Prüfung

Wenn du ein UML-Klassendiagramm erstellen sollst, gehe so vor:

Beispiel: Produktverwaltung

Fachliche Beschreibung:

Es soll eine Produktverwaltung erstellt werden.
Jedes Produkt hat eine Marke, ein Modell und einen Preis.
Ein Monitor hat zusätzlich eine Größe in Zoll und eine Auflösung.
Eine Tastatur hat zusätzlich ein Layout und die Information, ob sie mechanisch ist.

Mögliche Klassen:

Produkt
Monitor
Tastatur

Oberklasse:

Produkt

Unterklassen:

Monitor
Tastatur

Warum?

Monitor ist ein Produkt.
Tastatur ist ein Produkt.

Mögliches Klassendiagramm als Text

Produkt
--------------------------------
- marke: String
- modell: String
- preis: double
--------------------------------
+ toString(): String


Monitor extends Produkt
--------------------------------
- groesseZoll: double
- aufloesung: String
--------------------------------
+ toString(): String


Tastatur extends Produkt
--------------------------------
- layout: String
- mechanisch: boolean
--------------------------------
+ toString(): String

Typische IHK-Fehler beim UML-Klassendiagramm

Prüfungs-Merksätze

Klasse = Bauplan für Objekte
Objekt = konkrete Instanz einer Klasse
Attribut = gespeicherte Eigenschaft
Methode = Verhalten / Funktion
+ = public
- = private
# = protected
Vererbungspfeil zeigt zur Oberklasse
Gemeinsame Attribute gehören in die Oberklasse
Spezielle Attribute gehören in die Unterklasse
ERM zeigt Daten, Klassendiagramm zeigt Programmstruktur

Mini-Beispiel 1

Aufgabe:

Ein Produkt hat eine Marke, ein Modell und einen Preis.

Lösung:

Produkt
--------------------------------
- marke: String
- modell: String
- preis: double

Begründung:

marke, modell und preis sind Eigenschaften eines Produkts.
Deshalb sind sie Attribute.

Mini-Beispiel 2

Aufgabe:

Ein Monitor ist ein Produkt und hat zusätzlich eine Größe in Zoll.

Lösung:

Monitor erbt von Produkt.

Monitor
--------------------------------
- groesseZoll: double

Begründung:

Monitor ist eine spezielle Produktart.
Deshalb ist Vererbung sinnvoll.

Mini-Beispiel 3

Aufgabe:

Ein Kunde kann mehrere Bestellungen haben.

Mögliches UML-Klassendiagramm:

Kunde 1 ───── 0..* Bestellung

Begründung:

Ein Kunde kann mehrere Bestellungen haben.
Eine Bestellung gehört zu einem Kunden.

Mini-Testfragen

Klassen
Attribute
Methoden
Beziehungen
Vererbung

Produkt
Monitor
Tastatur

- marke: String
- preis: double

+ toString(): String
+ getPreis(): double

public / öffentlich

private / privat

Monitor ───▷ Produkt

Monitor
Tastatur
Maus
CPU

Klasse: Produkt
Objekt: monitor1

Ein Klassendiagramm kann Methoden und Vererbung enthalten.
Ein ERM normalerweise nicht.

Nächste Seite

Danach kommt die eigene Trainer-Seite:

UML-Klassendiagramm-Trainer

Dort bauen wir den interaktiven Trainer mit Aufgaben zu:

Klassen erkennen
Attribute zuordnen
Methoden eintragen
Sichtbarkeit bestimmen
Vererbung erkennen
Beziehungen zwischen Klassen darstellen

Seite 8. UML-Klassendiagramm-Trainer

UML-Klassendiagramm-Trainer

Dieser interaktive Trainer gehört zur Theorie-Seite:

UML-Klassendiagramm

Hier übst du, UML-Klassendiagramme richtig zu lesen und aus Aufgabenstellungen abzuleiten.

Im Fokus stehen:

Klassen
Attribute
Methoden
Sichtbarkeit
Assoziation
Vererbung
Aggregation
Komposition
korrekte UML-Linienenden

Was wird trainiert?

Interaktiver UML-Klassendiagramm-Trainer

Merksatz für den Trainer

Einfache Linie       = Assoziation
Hohles Dreieck       = Vererbung / Generalisierung
Leere Raute          = Aggregation
Gefüllte Raute       = Komposition
Raute steht am Ganzen
Vererbungsdreieck zeigt zur Oberklasse
- bedeutet private
+ bedeutet public

Beispiel: Assoziation

Aufgabe:

Ein Kunde kann mehrere Bestellungen haben.
Eine Bestellung gehört zu genau einem Kunden.

UML-Bedeutung:

Kunde ist mit Bestellung verbunden.

Darstellung:

Kunde ───── Bestellung

Wichtig:

Eine Assoziation ist eine normale Beziehung zwischen Klassen.
Sie wird als einfache Linie dargestellt.

Beispiel: Vererbung

Aufgabe:

Ein Monitor ist ein Produkt.

UML-Bedeutung:

Monitor erbt von Produkt.

Darstellung:

Monitor ─────▷ Produkt

Wichtig:

Das hohle Dreieck zeigt zur Oberklasse Produkt.

Beispiel: Aggregation

Aufgabe:

Ein Team hat mehrere Mitarbeiter.
Ein Mitarbeiter kann aber auch unabhängig vom Team existieren.

UML-Bedeutung:

Team aggregiert Mitarbeiter.

Darstellung:

Team ◇──── Mitarbeiter

Wichtig:

Die leere Raute steht am Ganzen, also bei Team.
Aggregation ist eine schwächere Teil-Ganzes-Beziehung.
Der Teil kann unabhängig vom Ganzen existieren.

Beispiel: Komposition

Aufgabe:

Eine Rechnung besteht aus Rechnungspositionen.
Eine Rechnungsposition gehört fest zu genau einer Rechnung.

UML-Bedeutung:

Rechnung besteht aus Rechnungspositionen.

Darstellung:

Rechnung ◆──── Rechnungsposition

Wichtig:

Die gefüllte Raute steht am Ganzen, also bei Rechnung.
Komposition ist eine starke Teil-Ganzes-Beziehung.
Der Teil ist fest vom Ganzen abhängig.

Wichtiger Unterschied: Aggregation vs. Komposition

Merksatz:

Leere Raute = Teil kann unabhängig existieren.
Gefüllte Raute = Teil gehört fest zum Ganzen.

Wichtiger Unterschied: Assoziation vs. Vererbung

Beispiel Assoziation:

Kunde ───── Bestellung

Bedeutung:

Kunde und Bestellung hängen fachlich zusammen.

Beispiel Vererbung:

Monitor ─────▷ Produkt

Bedeutung:

Monitor ist ein spezielles Produkt.

Sichtbarkeit im Trainer

Im Trainer musst du Sichtbarkeiten selbst eintragen.

Beispiel:

- marke: String
+ toString(): String

Wichtig:

Das + oder - soll nicht schon im Feld stehen.
Du sollst es selbst erkennen und eintragen.

Typische Aufgaben im Trainer

Der Trainer enthält Aufgaben zu:

Vererbung:
Monitor ist ein Produkt.

Assoziation:
Kunde hat Bestellungen.

Aggregation:
Team hat Mitarbeiter.

Komposition:
Rechnung besteht aus Rechnungspositionen.

Typische Fehler

Mini-Testfragen

Kunde ───── Bestellung

Das hohle Dreieck zeigt zur Oberklasse.

Monitor ─────▷ Produkt

Team ◇──── Mitarbeiter

Rechnung ◆──── Rechnungsposition

Team ◇──── Mitarbeiter
Rechnung ◆──── Rechnungsposition

- attribut: Typ
+ methode(): Typ

private Attribut marke vom Typ String

private String marke;

public Methode toString mit Rückgabewert String

public String toString()

Teil kann unabhängig existieren.

Teil gehört fest zum Ganzen.

Monitor ─────▷ Produkt

Nächste Seite

Danach geht es weiter mit:

UML-Aktivitätsdiagramm

Seite 9. UML-Aktivitätsdiagramm

Diese Seite erklärt das UML-Aktivitätsdiagramm so, dass du es schnell für IHK-Aufgaben und Programmierlogik anwenden kannst.

Ein UML-Aktivitätsdiagramm wird benutzt, um Abläufe darzustellen.

Es zeigt:

Start
Aktionen
Entscheidungen
Bedingungen
Kontrollflüsse
Merge-Knoten
Ende

Grafik 1: UML-Aktivitätsdiagramm – Grundlagen

Diese Grafik zeigt dir die wichtigsten Symbole:

• Startknoten
• Aktion / Aktivität
• Entscheidung
• Merge-Knoten
• Kontrollfluss
• Endknoten

Wichtig für die Prüfung:

Eine Entscheidung hat meistens einen Eingang und mehrere Ausgänge.
Ein Merge-Knoten führt mehrere alternative Wege wieder zusammen.

Wofür braucht man ein UML-Aktivitätsdiagramm?

Ein Aktivitätsdiagramm zeigt einen Ablauf Schritt für Schritt.

Typische Beispiele:

Login prüfen
Bestellung bearbeiten
Produktdaten speichern
Eingabe validieren
Fehler anzeigen
Zurück ins Menü

Es ist besonders hilfreich, wenn ein Ablauf Entscheidungen enthält.

Beispiel:

Wenn die Eingabe gültig ist, wird gespeichert.
Wenn die Eingabe ungültig ist, wird eine Fehlermeldung angezeigt.

Woran erkenne ich in einer Aufgabe, dass ein UML-Aktivitätsdiagramm gemeint ist?

Typische Signalwörter:

Grundsymbole

Startknoten

Der Startknoten zeigt, wo der Ablauf beginnt.

Darstellung:

●

Merksatz:

Start = gefüllter Kreis

Ein Aktivitätsdiagramm hat meistens genau einen klaren Startpunkt.

Aktion / Aktivität

Eine Aktion ist ein konkreter Arbeitsschritt.

Beispiele:

Produktdaten eingeben
Eingabe prüfen
Produkt speichern
Fehler anzeigen
Zurück ins Menü

Darstellung:

( Produktdaten eingeben )

Im Diagramm wird dafür normalerweise ein abgerundetes Rechteck verwendet.

Kontrollfluss

Ein Kontrollfluss zeigt die Reihenfolge der Schritte.

Darstellung:

Aktion 1 → Aktion 2

Wichtig:

Der Pfeil zeigt, welcher Schritt als Nächstes kommt.

Entscheidung

Eine Entscheidung wird verwendet, wenn der Ablauf in verschiedene Richtungen gehen kann.

Darstellung:

◇

Beispiel:

Eingabe gültig?

Danach gibt es meistens zwei Wege:

[ja]
[nein]

Wichtig:

Die Bedingungen an den ausgehenden Pfeilen heißen Guards.

Guards

Guards sind Bedingungen an Kontrollflüssen.

Typische Schreibweise:

[ja]
[nein]
[gültig]
[ungültig]
[preis > 0]
[eingabe leer]

Beispiel:

Eingabe gültig?
  [ja]   → Produkt speichern
  [nein] → Fehler anzeigen

Für Prüfungen ist wichtig:

Bedingungen sollten an den Pfeilen stehen, nicht nur irgendwo im Diagramm.

Merge-Knoten

Ein Merge-Knoten führt alternative Wege wieder zusammen.

Darstellung:

◇

Wichtig:

Entscheidung und Merge benutzen beide eine Raute.

Der Unterschied:

Beispiel:

[ja]   → Produkt speichern ┐
                            ◇ → Zurück ins Menü
[nein] → Fehler anzeigen  ┘

Endknoten

Der Endknoten zeigt das Ende des Ablaufs.

Darstellung:

◎

Merksatz:

Ende = Kreis mit gefülltem Punkt

Grafik 2: Beispiel – Produkt speichern

Diese Grafik zeigt einen typischen Ablauf:

Produktdaten eingeben
Eingabe prüfen
Entscheidung: Eingabe gültig?
[ja] → Produkt speichern
[nein] → Fehler anzeigen
Merge-Knoten
Zurück ins Menü
Ende

Wichtig:

Die Verzweigung wird mit einer Entscheidungsraute dargestellt.
Die Zusammenführung wird mit einem Merge-Knoten dargestellt.
Die Bedingungen stehen als [ja] und [nein] an den Kontrollflüssen.

Beispiel als Textablauf

Aufgabe:

Ein Benutzer gibt Produktdaten ein.
Das System prüft die Eingabe.
Wenn die Eingabe gültig ist, wird das Produkt gespeichert.
Wenn die Eingabe ungültig ist, wird eine Fehlermeldung angezeigt.
Danach kehrt das System ins Menü zurück.

Daraus entsteht:

Start
↓
Produktdaten eingeben
↓
Eingabe prüfen
↓
Eingabe gültig?
├─ [ja]   → Produkt speichern
└─ [nein] → Fehler anzeigen
↓
Merge
↓
Zurück ins Menü
↓
Ende

Entscheidung vs. Merge

Merksatz:

Entscheidung teilt den Ablauf.
Merge führt alternative Wege wieder zusammen.

Aktivitätsdiagramm vs. Programmcode

Ein Aktivitätsdiagramm passt gut zu if-Anweisungen.

Beispiel Code-Logik:

if (eingabeGueltig) {
    produktSpeichern();
} else {
    fehlerAnzeigen();
}

zurueckInsMenue();

Passendes Aktivitätsdiagramm:

Eingabe prüfen
↓
Eingabe gültig?
├─ [ja]   → Produkt speichern
└─ [nein] → Fehler anzeigen
↓
Merge
↓
Zurück ins Menü

Typische Kontrollstrukturen

Schleifen im Aktivitätsdiagramm

Eine Schleife entsteht, wenn ein Ablauf zu einem früheren Schritt zurückführt.

Beispiel:

Eingabe prüfen
↓
Eingabe gültig?
├─ [ja]   → Speichern
└─ [nein] → Fehler anzeigen → Eingabe erneut bearbeiten

Merksatz:

Schleifen erkennt man an einem Rückpfeil im Ablauf.

Vorgehensweise in der Prüfung

Wenn du ein UML-Aktivitätsdiagramm erstellen sollst, gehe so vor:

Typische IHK-Fehler

Prüfungs-Merksätze

Start = gefüllter Kreis
Aktion = abgerundetes Rechteck
Entscheidung = Raute
Merge = Raute zum Zusammenführen
Ende = Kreis mit gefülltem Punkt
Kontrollfluss = Pfeil
Guards stehen an Pfeilen
Guards schreibt man oft in eckigen Klammern
[ja] und [nein] sind typische Guards
Entscheidung teilt Wege
Merge führt Wege zusammen

Mini-Beispiel 1

Aufgabe:

Wenn ein Passwort korrekt ist, wird der Benutzer angemeldet.
Sonst wird eine Fehlermeldung angezeigt.

Lösungsidee:

Start
↓
Passwort prüfen
↓
Passwort korrekt?
├─ [ja]   → Benutzer anmelden
└─ [nein] → Fehlermeldung anzeigen
↓
Ende

Mini-Beispiel 2

Aufgabe:

Ein Preis wird eingegeben.
Wenn der Preis größer als 0 ist, wird das Produkt gespeichert.
Sonst wird eine Fehlermeldung angezeigt.

Lösungsidee:

Start
↓
Preis eingeben
↓
Preis > 0?
├─ [ja]   → Produkt speichern
└─ [nein] → Fehler anzeigen
↓
Ende

Mini-Beispiel 3

Aufgabe:

Ein Benutzer gibt Daten ein.
Wenn die Daten ungültig sind, soll er sie erneut eingeben.
Wenn sie gültig sind, werden sie gespeichert.

Lösungsidee:

Start
↓
Daten eingeben
↓
Daten gültig?
├─ [ja]   → Speichern → Ende
└─ [nein] → Fehler anzeigen → Daten eingeben

Hier entsteht eine Schleife, weil der Ablauf bei ungültigen Daten zurück zur Eingabe geht.

Mini-Testfragen

Login prüfen
Produkt speichern
Bestellung bearbeiten

●

Produkt speichern

Eingabe gültig?

[ja]
[nein]
[gültig]
[ungültig]
[preis > 0]

Entscheidung = 1 Eingang, mehrere Ausgänge
Merge = mehrere Eingänge, 1 Ausgang

◎

Fehler anzeigen → Daten erneut eingeben

[ja]
[nein]

Nächste Seite

Danach kommt die eigene Trainer-Seite:

UML-Aktivitätsdiagramm-Trainer

Dort bauen wir den interaktiven Trainer mit Aufgaben zu:

Startknoten erkennen
Aktionen eintragen
Entscheidungen setzen
Guards [ja]/[nein] ergänzen
Merge-Knoten verwenden
Endknoten korrekt platzieren

Seite 10. UML-Aktivitätsdiagramm-Trainer

UML-Aktivitätsdiagramm-Trainer

Dieser interaktive Trainer gehört zur Theorie-Seite:

UML-Aktivitätsdiagramm

Hier übst du, aus einer Aufgabenbeschreibung ein korrektes UML-Aktivitätsdiagramm abzuleiten.

Im Fokus stehen:

Startknoten
Aktionen
Entscheidungsraute
Guards
Kontrollflüsse
Merge-Knoten
Endknoten

Was wird trainiert?

Interaktiver UML-Aktivitätsdiagramm-Trainer

Merksatz für den Trainer

Startknoten = gefüllter Kreis
Aktion = abgerundetes Rechteck
Entscheidung = Raute
Guard = Bedingung am Pfeil
Merge = Raute zur Zusammenführung
Endknoten = Kreis mit gefülltem Punkt
Kontrollfluss = Pfeilrichtung im Ablauf

Beispiel: Produkt speichern

Aufgabenstellung:

Ein Benutzer gibt Produktdaten ein.
Das System prüft die Eingabe.
Wenn die Eingabe gültig ist, wird das Produkt gespeichert.
Wenn die Eingabe ungültig ist, wird eine Fehlermeldung angezeigt.
Danach kehrt das System ins Menü zurück.

Mögliche Lösung:

Start
↓
Produktdaten eingeben
↓
Eingabe prüfen
↓
Eingabe gültig?
├─ [ja]   → Produkt speichern
└─ [nein] → Fehler anzeigen
↓
Merge
↓
Zurück ins Menü
↓
Ende

Warum ist die Raute wichtig?

Eine Entscheidung wird im UML-Aktivitätsdiagramm als Raute dargestellt.

Nicht als Rechteck.

Aktion       = abgerundetes Rechteck
Entscheidung = Raute
Merge        = Raute

Der Unterschied liegt im Ablauf:

Warum stehen [ja] und [nein] an den Pfeilen?

Die Bedingungen heißen Guards.

Sie beschreiben, wann ein bestimmter Weg genommen wird.

Beispiel:

Eingabe gültig?
├─ [ja]   → Produkt speichern
└─ [nein] → Fehler anzeigen

Wichtig:

[ja] und [nein] gehören an die ausgehenden Kontrollflüsse der Entscheidung.

Typische Aufgaben im Trainer

Der Trainer enthält Aufgaben zu:

Produkt speichern
Login prüfen
Preis prüfen

Dabei musst du jeweils erkennen:

Welche Aktion kommt zuerst?
Welche Prüfung folgt?
Wie lautet die Entscheidungsfrage?
Welche Guards gehören an die Pfeile?
Welche Aktion gehört zum Ja-Zweig?
Welche Aktion gehört zum Nein-Zweig?
Wo werden die Wege wieder zusammengeführt?

Typische Fehler

Mini-Testfragen

●

Produkt speichern

Eingabe gültig?

[ja]
[nein]
[gültig]
[ungültig]

mehrere Eingänge → Merge → ein Ausgang

Entscheidung = ein Eingang, mehrere Ausgänge
Merge = mehrere Eingänge, ein Ausgang

◎

Eingabe gültig?
├─ [ja]   → Speichern
└─ [nein] → Fehler anzeigen

[ja]   → Speichern ┐
                   Merge → Zurück ins Menü
[nein] → Fehler   ┘

Nächste Seite

Danach geht es weiter mit:

UML-Anwendungsfalldiagramm

Seite 11. UML-Anwendungsfalldiagramm

UML-Anwendungsfalldiagramm

Diese Seite erklärt das UML-Anwendungsfalldiagramm so, dass du es schnell für IHK-Aufgaben und Software-Analyse anwenden kannst.

Ein UML-Anwendungsfalldiagramm zeigt:

Wer benutzt ein System?
Welche Funktionen bietet das System?
Welche Akteure stehen mit welchen Anwendungsfällen in Verbindung?
Welche Anwendungsfälle hängen voneinander ab?

Wichtig:

Ein Anwendungsfalldiagramm zeigt nicht den inneren Programmablauf.
Es zeigt die Sicht von außen auf das System.

Grafik 1: UML-Anwendungsfalldiagramm – Grundlagen

Diese Grafik zeigt die wichtigsten Bestandteile:

• Akteur
• Systemgrenze
• Anwendungsfall / Use Case
• Assoziation
• «include»
• «extend»
• Generalisierung

Wofür braucht man ein UML-Anwendungsfalldiagramm?

Ein UML-Anwendungsfalldiagramm wird verwendet, um die Anforderungen an ein System aus Benutzersicht darzustellen.

Es beantwortet Fragen wie:

Wer nutzt das System?
Welche Funktionen braucht der Benutzer?
Welche Systemfunktionen gehören zusammen?
Welche Funktion ist Pflichtbestandteil einer anderen Funktion?
Welche Funktion ist nur eine optionale Erweiterung?

Beispiel:

Ein Kunde kann Artikel suchen.
Ein Kunde kann eine Bestellung aufgeben.
Beim Aufgeben einer Bestellung muss eine Zahlung durchgeführt werden.
Optional kann ein Rabatt geprüft werden.

Daraus entstehen:

Akteur: Kunde
Use Case: Artikel suchen
Use Case: Bestellung aufgeben
Use Case: Zahlung durchführen
Use Case: Rabatt prüfen

Woran erkenne ich in einer Aufgabe, dass ein Anwendungsfalldiagramm gemeint ist?

Typische Signalwörter:

Grundidee

Ein Anwendungsfalldiagramm zeigt die Außensicht auf ein System.

Es zeigt nicht:

Welche Klasse welche Methode hat.
Wie der Ablauf Schritt für Schritt funktioniert.
Welche Datenbanktabellen entstehen.

Sondern es zeigt:

Welche Akteure gibt es?
Welche Funktionen stellt das System bereit?
Welche Akteure nutzen welche Funktionen?

Merksatz:

Anwendungsfalldiagramm = Wer nutzt welche Funktion des Systems?

Akteur

Ein Akteur ist eine Rolle außerhalb des Systems.

Beispiele:

Kunde
Admin
Mitarbeiter
Lehrer
Schüler
Zahlungsdienst
E-Mail-System

Wichtig:

Ein Akteur muss nicht immer ein Mensch sein.
Auch ein externes System kann ein Akteur sein.

Beispiel:

Zahlungsdienst
E-Mail-Server
Versanddienstleister

Ein Akteur steht normalerweise außerhalb der Systemgrenze.

Systemgrenze

Die Systemgrenze wird als Rechteck dargestellt.

Innerhalb der Systemgrenze stehen die Anwendungsfälle.

Außerhalb der Systemgrenze stehen die Akteure.

Merksatz:

Akteure außen.
Use Cases innen.
Systemgrenze als Rechteck.

Beispiel:

Kunde        [ Shop-System ]
             (Artikel suchen)
             (Bestellung aufgeben)

Anwendungsfall / Use Case

Ein Anwendungsfall beschreibt eine Funktion des Systems aus Sicht eines Akteurs.

Darstellung:

( Bestellung aufgeben )

Also als Ellipse.

Gute Use-Case-Namen sind meistens kurze Tätigkeiten:

Artikel suchen
Bestellung aufgeben
Zahlung durchführen
Benutzer anmelden
Artikel verwalten
Passwort zurücksetzen

Wichtig:

Use Cases sollten einen Nutzen für einen Akteur haben.

Nicht ideal:

Datenbank speichern
Methode ausführen
SQL ausführen

Besser:

Bestellung speichern
Kundendaten verwalten
Rechnung erstellen

Assoziation

Eine Assoziation verbindet einen Akteur mit einem Anwendungsfall.

Darstellung:

Kunde ───── (Artikel suchen)

Bedeutung:

Der Akteur nutzt diesen Anwendungsfall.

Wichtig:

Eine Assoziation ist normalerweise eine einfache Linie.

«include»

«include» bedeutet:

Ein Anwendungsfall enthält einen anderen Anwendungsfall immer als Pflichtbestandteil.

Beispiel:

Bestellung aufgeben «include» Zahlung durchführen

Bedeutung:

Wenn eine Bestellung aufgegeben wird, muss die Zahlung durchgeführt werden.

Typische Fälle für «include»:

Anmelden
Zahlung durchführen
Berechtigung prüfen
Daten validieren

Wichtig:

«include» zeigt auf den eingebundenen Pflicht-Anwendungsfall.

Beispiel:

(Bestellung aufgeben) - - -«include»- - -> (Zahlung durchführen)

«extend»

«extend» bedeutet:

Ein Anwendungsfall erweitert einen anderen Anwendungsfall optional.

Beispiel:

Rabatt prüfen «extend» Bestellung aufgeben

Bedeutung:

Rabatt prüfen passiert nur unter bestimmten Bedingungen.

Zum Beispiel:

wenn ein Rabattcode eingegeben wurde
wenn der Kunde berechtigt ist
wenn eine Sonderaktion aktiv ist

Wichtig:

«extend» zeigt vom optionalen Erweiterungsfall auf den Basis-Anwendungsfall.

Beispiel:

(Rabatt prüfen) - - -«extend»- - -> (Bestellung aufgeben)

Unterschied «include» und «extend»

Merksatz:

include = immer dabei
extend = optional / nur bei Bedingung

Generalisierung

Generalisierung bedeutet:

Ein spezieller Akteur oder Use Case erbt von einem allgemeineren Akteur oder Use Case.

Beispiel bei Akteuren:

Admin ist ein spezieller Benutzer.

Darstellung:

Admin ─────▷ Benutzer

Wichtig:

Das hohle Dreieck zeigt zur allgemeineren Rolle.

Also:

Admin → Benutzer

nicht umgekehrt.

Grafik 2: Beispiel – Shop-System

Diese Grafik zeigt ein Beispiel für ein Shop-System.

Es enthält:

Akteure:
Kunde
Admin

Use Cases:
Anmelden
Artikel suchen
Bestellung aufgeben
Zahlung durchführen
Rabatt prüfen
Artikel verwalten

Wichtig:

Kunde und Admin stehen außerhalb der Systemgrenze.
Die Anwendungsfälle stehen innerhalb der Systemgrenze.

Beispiel als Textbeschreibung

Aufgabe:

Ein Kunde kann Artikel suchen und eine Bestellung aufgeben.
Beim Aufgeben einer Bestellung muss eine Zahlung durchgeführt werden.
Vor der Bestellung kann optional ein Rabatt geprüft werden.
Ein Admin kann Artikel verwalten.

Daraus entsteht:

Akteur Kunde
Akteur Admin

Kunde ─ Artikel suchen
Kunde ─ Bestellung aufgeben
Admin ─ Artikel verwalten

Bestellung aufgeben «include» Zahlung durchführen
Rabatt prüfen «extend» Bestellung aufgeben

Akteure im Beispiel

Wichtig:

Akteure sind Rollen.
Nicht jede konkrete Person wird einzeln gezeichnet.

Also:

Kunde

nicht:

Max Müller

Use Cases im Beispiel

Warum ist „Zahlung durchführen“ ein «include»?

Weil die Zahlung beim Aufgeben einer Bestellung ein notwendiger Bestandteil ist.

Bestellung aufgeben

enthält immer:

Zahlung durchführen

Darum:

Bestellung aufgeben «include» Zahlung durchführen

Warum ist „Rabatt prüfen“ ein «extend»?

Weil ein Rabatt nicht immer geprüft werden muss.

Nur wenn zum Beispiel ein Rabattcode vorhanden ist, wird dieser zusätzliche Fall relevant.

Darum:

Rabatt prüfen «extend» Bestellung aufgeben

Merksatz:

Rabatt = optional
Zahlung = Pflicht

Anwendungsfalldiagramm vs. Aktivitätsdiagramm

Merksatz:

Anwendungsfalldiagramm = Wer nutzt was?
Aktivitätsdiagramm = Was passiert danach?

Anwendungsfalldiagramm vs. Klassendiagramm

Merksatz:

Use Case = Funktion aus Nutzersicht
Klasse = Bauplan im Programm

Vorgehensweise in der Prüfung

Wenn du ein UML-Anwendungsfalldiagramm erstellen sollst, gehe so vor:

Typische IHK-Fehler

Prüfungs-Merksätze

Akteur = externe Rolle
Use Case = Funktion des Systems
Systemgrenze = Rechteck um die Use Cases
Akteure stehen außerhalb
Use Cases stehen innerhalb
Use Cases werden als Ellipsen gezeichnet
Assoziation = einfache Linie
include = Pflichtbestandteil
extend = optionale Erweiterung
include zeigt auf den eingebundenen Use Case
extend zeigt auf den Basis-Use-Case

Mini-Beispiel 1

Aufgabe:

Ein Benutzer kann sich anmelden.

Lösung:

Akteur: Benutzer
Use Case: Anmelden

Benutzer ─ (Anmelden)

Mini-Beispiel 2

Aufgabe:

Ein Kunde kann eine Bestellung aufgeben.
Dabei muss eine Zahlung durchgeführt werden.

Lösung:

Kunde ─ (Bestellung aufgeben)

(Bestellung aufgeben) «include» (Zahlung durchführen)

Begründung:

Zahlung durchführen ist ein Pflichtbestandteil der Bestellung.

Mini-Beispiel 3

Aufgabe:

Ein Kunde kann bei einer Bestellung optional einen Rabattcode verwenden.

Lösung:

(Rabatt prüfen) «extend» (Bestellung aufgeben)

Begründung:

Rabatt prüfen ist optional.
Es passiert nur, wenn ein Rabattcode vorhanden ist.

Mini-Testfragen

Welche Akteure ein System nutzen
und welche Funktionen das System anbietet.

Wer nutzt was?

( Bestellung aufgeben )

Ein Use Case enthält einen anderen Use Case verpflichtend.

Bestellung aufgeben «include» Zahlung durchführen

Ein Use Case erweitert einen anderen Use Case optional.

Rabatt prüfen «extend» Bestellung aufgeben

include = Pflichtbestandteil
extend = optionale Erweiterung

Bestellung aufgeben → Zahlung durchführen

Rabatt prüfen → Bestellung aufgeben

saveOrder()

Bestellung aufgeben

Nächste Seite

Danach kommt die eigene Trainer-Seite:

UML-Anwendungsfalldiagramm-Trainer

Dort bauen wir den interaktiven Trainer mit Aufgaben zu:

Akteure erkennen
Use Cases benennen
Systemgrenze verstehen
Assoziationen eintragen
include und extend unterscheiden
Pfeilrichtung prüfen

Seite 12. UML-Anwendungsfalldiagramm-Trainer

UML-Anwendungsfalldiagramm-Trainer

Dieser interaktive Trainer gehört zur Theorie-Seite:

UML-Anwendungsfalldiagramm

Hier übst du, aus einer Aufgabenbeschreibung ein korrektes UML-Anwendungsfalldiagramm abzuleiten.

Im Fokus stehen:

Akteure
Systemgrenze
Use Cases
Assoziationen
<<include>>
<<extend>>
Pfeilrichtung
Pflichtbestandteil vs. optionale Erweiterung

Was wird trainiert?

Interaktiver UML-Anwendungsfalldiagramm-Trainer

Merksatz für den Trainer

Akteur = externe Rolle außerhalb des Systems
Use Case = Funktion des Systems
Systemgrenze = Rechteck um die Use Cases
Akteur–Use Case = einfache Linie ohne Pfeil
<<include>> = Pflichtbestandteil
<<extend>> = optionale Erweiterung
include zeigt zum eingebundenen Pflicht-Use-Case
extend zeigt zum Basis-Use-Case

Beispiel: Shop-System

Aufgabenstellung:

Ein Kunde kann Artikel suchen und eine Bestellung aufgeben.
Beim Aufgeben einer Bestellung muss eine Zahlung durchgeführt werden.
Vor der Bestellung kann optional ein Rabatt geprüft werden.
Ein Admin kann Artikel verwalten.

Mögliche Lösung:

System:
Shop-System

Akteure:
Kunde
Admin

Use Cases:
Artikel suchen
Bestellung aufgeben
Zahlung durchführen
Rabatt prüfen
Artikel verwalten

Beziehungen:
Kunde — Artikel suchen
Kunde — Bestellung aufgeben
Admin — Artikel verwalten

Bestellung aufgeben <<include>> Zahlung durchführen
Rabatt prüfen <<extend>> Bestellung aufgeben

Warum ist „Zahlung durchführen“ ein <>?

Bestellung aufgeben <<include>> Zahlung durchführen

Das bedeutet:

Wenn eine Bestellung aufgegeben wird,
muss die Zahlung durchgeführt werden.

Also ist die Zahlung ein Pflichtbestandteil.

Warum ist „Rabatt prüfen“ ein <>?

Rabatt prüfen <<extend>> Bestellung aufgeben

Das bedeutet:

Rabatt prüfen erweitert Bestellung aufgeben nur optional.

Zum Beispiel:

nur wenn ein Rabattcode vorhanden ist
nur wenn eine Aktion aktiv ist
nur wenn der Kunde berechtigt ist

Richtige Pfeilrichtung

Merksatz:

include zeigt auf das, was immer gebraucht wird.
extend zeigt auf das, was optional erweitert wird.

Typische Fehler

Mini-Testfragen

( Bestellung aufgeben )

Kunde — Bestellung aufgeben

Bestellung aufgeben <<include>> Zahlung durchführen

Rabatt prüfen <<extend>> Bestellung aufgeben

Bestellung aufgeben → Zahlung durchführen

Rabatt prüfen → Bestellung aufgeben

Ohne Zahlung ist die Bestellung nicht vollständig.

Nur wenn ein Rabattcode oder eine Rabattbedingung vorhanden ist.

if-Anweisungen
Schleifen
Methodenaufrufe
Datenbanktabellen

Nächste Seite

Danach geht es weiter mit:

UML-Sequenzdiagramm

Seite 13. UML-Sequenzdiagramm

UML-Sequenzdiagramm

Diese Seite erklärt das UML-Sequenzdiagramm so, dass du es schnell für IHK-Aufgaben und Programmierlogik anwenden kannst.

Ein UML-Sequenzdiagramm zeigt:

Welche Objekte oder Teilnehmer beteiligt sind
welche Nachrichten zwischen ihnen ausgetauscht werden
in welcher zeitlichen Reihenfolge die Kommunikation abläuft
welche Rückgaben erfolgen
welche Prozesse nacheinander oder parallel ablaufen

Wichtig:

Ein Sequenzdiagramm zeigt einen konkreten Ablauf.
Der Ablauf wird von oben nach unten gelesen.

Grafik 1: UML-Sequenzdiagramm – Grundlagen

Diese Grafik zeigt die wichtigsten Bestandteile:

Teilnehmer / Objekte
Lebenslinien
Aktivierungsbalken
Nachrichten
Rückgaben
Zeitachse

Wofür braucht man ein UML-Sequenzdiagramm?

Ein Sequenzdiagramm wird verwendet, um die Kommunikation zwischen Objekten oder Systemteilen darzustellen.

Typische Beispiele:

Login prüfen
Bestellung aufgeben
Produkt speichern
Datenbankabfrage ausführen
Benutzeroberfläche ruft Service auf
Service ruft Datenbank auf

Es zeigt also nicht nur, was passiert, sondern vor allem:

wer mit wem spricht
in welcher Reihenfolge
welche Antwort zurückkommt

Woran erkenne ich in einer Aufgabe, dass ein Sequenzdiagramm gemeint ist?

Typische Signalwörter:

Grundidee

Ein Sequenzdiagramm zeigt einen konkreten Ablauf als Szenario.

Beispiel:

Benutzer gibt Login-Daten ein.
Die Oberfläche sendet die Daten an den LoginService.
Der LoginService fragt die Datenbank ab.
Die Datenbank gibt einen Benutzer zurück.
Der Service gibt den Loginstatus zurück.
Die Oberfläche zeigt eine Meldung an.

Daraus entsteht ein zeitlicher Ablauf zwischen:

Benutzer
loginGUI:LoginGUI
loginService:LoginService
userRepository:UserRepository

Teilnehmer / Objekte

Teilnehmer stehen im Sequenzdiagramm oben.

Beispiele:

Benutzer
loginGUI:LoginGUI
loginService:LoginService
userRepository:UserRepository

Wichtig:

Ein echter Benutzer kann als Akteur dargestellt werden.
Objekte werden häufig als instanz:Klasse geschrieben.

Beispiele:

loginGUI:LoginGUI
loginService:LoginService
userRepository:UserRepository

Lebenslinie

Unter jedem Teilnehmer verläuft eine Lebenslinie nach unten.

Darstellung:

Teilnehmer
    |
    |
    |

In UML wird die Lebenslinie meistens gestrichelt dargestellt.

Merksatz:

Lebenslinie = zeigt, dass ein Teilnehmer während des Ablaufs existiert.

Zeitliche Reihenfolge

Ein Sequenzdiagramm wird von oben nach unten gelesen.

oben = früher
unten = später

Merksatz:

Die Reihenfolge der Nachrichten ergibt sich aus ihrer Höhe im Diagramm.

Nachricht / Methodenaufruf

Eine Nachricht zeigt, dass ein Teilnehmer einen anderen Teilnehmer aufruft.

Beispiel:

loginGUI → loginService: pruefeLogin(name, passwort)

Typisch im Diagramm:

durchgezogene Linie mit Pfeilspitze

Beispiele:

loginDatenEingeben(name, passwort)
pruefeLogin(name, passwort)
findeBenutzer(name)

Rückgabe

Eine Rückgabe zeigt das Ergebnis eines Aufrufs.

Beispiel:

userRepository --> loginService: benutzer

Typisch:

gestrichelte Linie zurück

Beispiele:

benutzer
loginStatus
dashboardDaten
benutzerKontext

Wichtig:

Rückgaben sind oft optional, aber in Lern- und Prüfungsdiagrammen sehr hilfreich.

Aktivierungsbalken

Ein Aktivierungsbalken zeigt, dass ein Teilnehmer gerade aktiv ist.

Beispiel:

loginService prüft gerade die Login-Daten.
userRepository sucht gerade den Benutzer.

Darstellung:

schmaler senkrechter Balken auf der Lebenslinie

Merksatz:

Aktivierungsbalken = Teilnehmer verarbeitet gerade etwas.

Grafik 2: Beispiel – Login prüfen

Diese Grafik zeigt einen Login-Ablauf.

Beteiligte Teilnehmer:

Benutzer
loginGUI:LoginGUI
loginService:LoginService
userRepository:UserRepository
dashboard:Dashboard

Ablauf:

1. Benutzer gibt Login-Daten ein.
2. LoginGUI ruft den LoginService auf.
3. LoginService fragt UserRepository ab.
4. UserRepository gibt Benutzer zurück.
5. LoginService gibt Loginstatus zurück.
6. Danach laufen zwei Prozesse parallel:
   Prozess A: Dashboard laden
   Prozess B: Benutzerkontext laden
7. Danach wird die Startseite angezeigt.

Parallele Prozesse

In der IHK-nahen Darstellung können parallele Abläufe durch zwei parallele Linien markiert werden.

In unserem Beispiel:

Prozess A: Dashboard laden
Prozess B: Benutzerkontext laden

Wichtig:

Parallel bedeutet:
Die Prozesse müssen nicht streng nacheinander ablaufen.
Sie können gleichzeitig oder unabhängig voneinander gestartet werden.

Merksatz:

Parallele Linien = paralleler Ablaufbereich

Beispiel als Textablauf

Aufgabe:

Ein Benutzer gibt seine Login-Daten ein.
Die Oberfläche sendet Name und Passwort an den LoginService.
Der LoginService sucht den Benutzer über das UserRepository.
Das UserRepository gibt den Benutzer zurück.
Der LoginService gibt den Loginstatus zurück.
Nach erfolgreichem Login werden Dashboarddaten und Benutzerkontext geladen.
Danach wird die Startseite angezeigt.

Daraus entsteht:

Benutzer → loginGUI: loginDatenEingeben(name, passwort)
loginGUI → loginService: pruefeLogin(name, passwort)
loginService → userRepository: findeBenutzer(name)
userRepository --> loginService: benutzer
loginService --> loginGUI: loginStatus

parallel:
loginGUI → dashboard: ladeDashboard()
dashboard --> loginGUI: dashboardDaten

loginGUI → loginService: ladeBenutzerKontext()
loginService --> loginGUI: benutzerKontext

loginGUI → Benutzer: startseiteAnzeigen()

Sequenzdiagramm vs. Aktivitätsdiagramm

Merksatz:

Sequenzdiagramm = Wer ruft wen wann auf?
Aktivitätsdiagramm = Was passiert als nächstes?

Sequenzdiagramm vs. Klassendiagramm

Merksatz:

Klassendiagramm = Bauplan
Sequenzdiagramm = Ablauf zwischen den Bauteilen

Typische IHK-Fehler

Vorgehensweise in der Prüfung

Wenn du ein Sequenzdiagramm erstellen sollst, gehe so vor:

Prüfungs-Merksätze

Teilnehmer stehen oben.
Lebenslinien laufen nach unten.
Zeit läuft von oben nach unten.
Nachrichten sind horizontale Pfeile.
Synchrone Aufrufe werden durchgezogen gezeichnet.
Rückgaben werden gestrichelt gezeichnet.
Aktivierungsbalken zeigen Verarbeitung.
Parallele Prozesse müssen erkennbar markiert werden.
Ein Sequenzdiagramm zeigt ein konkretes Szenario.

Mini-Beispiel 1

Aufgabe:

Ein Benutzer klickt auf Speichern.
Die Oberfläche sendet die Daten an den Controller.
Der Controller speichert die Daten in der Datenbank.
Die Datenbank gibt eine Bestätigung zurück.

Lösungsidee:

Benutzer → GUI: speichernKlicken()
GUI → Controller: speichern(daten)
Controller → Datenbank: insert(daten)
Datenbank --> Controller: ok
Controller --> GUI: gespeichert
GUI → Benutzer: bestätigungAnzeigen()

Mini-Beispiel 2

Aufgabe:

Ein Kunde gibt eine Bestellung auf.
Die Oberfläche sendet die Bestellung an den BestellService.
Der BestellService prüft den Lagerbestand.
Danach wird die Bestellung gespeichert.

Lösungsidee:

Kunde → ShopGUI: bestellungAufgeben()
ShopGUI → BestellService: bestellungPruefen()
BestellService → LagerService: bestandPruefen()
LagerService --> BestellService: bestandOK
BestellService → BestellungRepository: speichern()
BestellungRepository --> BestellService: gespeichert
BestellService --> ShopGUI: bestellungOK

Mini-Beispiel 3: Paralleler Ablauf

Aufgabe:

Nach dem Login werden Dashboarddaten und Benutzerdaten parallel geladen.

Lösungsidee:

parallel:
GUI → DashboardService: ladeDashboard()
DashboardService --> GUI: dashboardDaten

GUI → BenutzerService: ladeBenutzerDaten()
BenutzerService --> GUI: benutzerDaten

Merksatz:

Wenn zwei Abläufe unabhängig voneinander starten können,
kann ein paralleler Bereich sinnvoll sein.

Mini-Testfragen

Wer ruft wen wann auf?

oben = früher
unten = später

userRepository --> loginService: benutzer

Nachricht = Aufruf
Rückgabe = Ergebnis

Dashboard laden
Benutzerkontext laden

Der Ablauf wird von oben nach unten gelesen.

Nächste Seite

Danach kommt die eigene Trainer-Seite:

UML-Sequenzdiagramm-Trainer

Dort übst du:

Teilnehmer erkennen
Nachrichten richtig beschriften
Rückgaben unterscheiden
Reihenfolge beachten
parallele Prozesse erkennen
Sequenzdiagramme aus Textaufgaben ableiten

Seite 14. UML-Sequenzdiagramm-Trainer

Dieser interaktive Trainer gehört zur Theorie-Seite:

UML-Sequenzdiagramm

Hier übst du, aus einer Aufgabenbeschreibung ein korrektes UML-Sequenzdiagramm abzuleiten.

Im Fokus stehen:

Teilnehmer
Lebenslinien
Nachrichten
Rückgaben
Reihenfolge
Aktivierungsbalken
parallele Prozessbereiche

Was wird trainiert?

Interaktiver UML-Sequenzdiagramm-Trainer

Merksatz für den Trainer

Teilnehmer stehen oben.
Lebenslinien laufen nach unten.
Zeit läuft von oben nach unten.
Nachrichten sind durchgezogene Pfeile.
Rückgaben sind gestrichelte Pfeile.
Aktivierungsbalken zeigen Verarbeitung.
Parallele Abläufe müssen sichtbar markiert werden.

Wichtige fachliche Einordnung

Im Trainer verwenden wir für den parallelen Bereich eine IHK-nahe vereinfachte Darstellung mit zwei parallelen Linien.

Das bedeutet:

zwei parallele Linien = paralleler Ablaufbereich

Streng nach UML kann Parallelität auch als par-Combined-Fragment mit Rahmen dargestellt werden.

Für dein IHK-Lernen ist wichtig:

Du sollst erkennen:
Hier laufen zwei Prozesse parallel oder unabhängig voneinander ab.

Beispiel: Login prüfen

Aufgabenstellung:

Ein Benutzer gibt Login-Daten ein.
Die LoginGUI ruft den LoginService auf.
Der LoginService fragt das UserRepository ab.
Danach werden Dashboarddaten und Benutzerkontext parallel geladen.
Zum Schluss wird die Startseite angezeigt.

Mögliche Lösung:

Teilnehmer:
Benutzer
loginGUI:LoginGUI
loginService:LoginService
userRepository:UserRepository
dashboard:Dashboard

Ablauf:

Benutzer → loginGUI: loginDatenEingeben(name, passwort)
loginGUI → loginService: pruefeLogin(name, passwort)
loginService → userRepository: findeBenutzer(name)
userRepository --> loginService: benutzer
loginService --> loginGUI: loginStatus

Parallelbereich:

Prozess A:
loginGUI → dashboard: ladeDashboard()
dashboard --> loginGUI: dashboardDaten

Prozess B:
loginGUI → loginService: ladeBenutzerKontext()
loginService --> loginGUI: benutzerKontext

Abschluss:

loginGUI → Benutzer: startseiteAnzeigen()

Nachricht oder Rückgabe?

Teilnehmer richtig benennen

Ein Teilnehmer kann ein Akteur oder ein Objekt sein.

Beispiele:

Benutzer
loginGUI:LoginGUI
loginService:LoginService
userRepository:UserRepository
dashboard:Dashboard

Wichtig:

Benutzer = Akteur
loginGUI:LoginGUI = Objekt / Instanz mit Klasse

Warum steht die Zeit von oben nach unten?

Ein Sequenzdiagramm wird vertikal gelesen.

oben = früher
unten = später

Das bedeutet:

Die erste Nachricht steht oben.
Spätere Nachrichten stehen weiter unten.

Typische Fehler im Sequenzdiagramm

Mini-Testfragen

Wer ruft wen wann auf?

oben = früher
unten = später

loginGUI → loginService: pruefeLogin()

loginService --> loginGUI: loginStatus

Mehrere Prozesse können parallel oder unabhängig voneinander ablaufen.

Nachricht = Aufruf
Rückgabe = Antwort / Ergebnis

Die Reihenfolge ergibt sich von oben nach unten.

Nächste Seite

Danach geht es weiter mit:

Mock-up / Benutzeroberflächen-Entwurf

Seite 15: Mock-up / Benutzeroberflächen-Entwurf

Diese Seite erklärt den Mock-up / Benutzeroberflächen-Entwurf so, dass du ihn schnell für IHK-Aufgaben anwenden kannst.

Ein Mock-up zeigt:

Wie eine Benutzeroberfläche aussehen soll
welche Felder und Buttons vorhanden sind
wie die Navigation aufgebaut ist
wo Fehlermeldungen erscheinen
wie der Benutzer durch die Oberfläche geführt wird

Wichtig:

Ein Mock-up ist kein UML-Diagramm.
Ein Mock-up zeigt keine Programmlogik.
Ein Mock-up zeigt die geplante Bedienoberfläche.

Grafik 1: Mock-up – Grundlagen

Diese Grafik zeigt die wichtigsten Bestandteile eines Mock-ups:

Fenster / App-Rahmen
Titelbereich
Navigation
Inhaltsbereich
Formularfelder
Buttons
Fehlermeldung
Benutzerführung

Wofür braucht man ein Mock-up?

Ein Mock-up wird benutzt, um eine Oberfläche vor der Programmierung zu planen.

Typische Ziele:

Benutzeroberfläche sichtbar machen
Bedienung planen
Felder und Buttons festlegen
Fehler- und Erfolgsmeldungen berücksichtigen
Benutzerführung prüfen
Missverständnisse vor der Programmierung vermeiden

Ein Mock-up beantwortet also Fragen wie:

Welche Eingabefelder braucht der Benutzer?
Welche Buttons sind notwendig?
Wo steht die Fehlermeldung?
Wie kommt der Benutzer zurück?
Was passiert nach dem Speichern?

Woran erkenne ich in einer Aufgabe, dass ein Mock-up gemeint ist?

Typische Signalwörter:

Grundidee

Ein Mock-up ist ein visueller Entwurf.

Es zeigt nicht:

Java-Code
SQL-Code
Methodenaufrufe
Datenbankstruktur
UML-Beziehungen

Sondern es zeigt:

Oberflächenaufbau
Felder
Buttons
Navigation
Meldungen
Anordnung
Bedienbarkeit

Merksatz:

Mock-up = Wie sieht die Oberfläche für den Benutzer aus?

Grafik 2: Beispiel – Produktformular

Diese Grafik zeigt ein typisches Mock-up für eine Produktverwaltung.

Enthalten sind:

Toolbar
Formularbereich
Produktname
Kategorie
Preis
Lagerbestand
Aktiv-Checkbox
Speichern-Button
Abbrechen-Button
Zurück-zur-Liste-Button
Fehlermeldung am Preisfeld

Wichtige Bestandteile eines guten Mock-ups

Pflichtfelder

Pflichtfelder sind Felder, die ausgefüllt werden müssen.

Typische Markierung:

Produktname *
Preis *
Kategorie *

Das * bedeutet:

Dieses Feld muss ausgefüllt werden.

Wichtig:

Pflichtfelder sollten klar erkennbar sein.

Validierung und Fehlermeldungen

Validierung bedeutet:

Das System prüft, ob die Eingabe gültig ist.

Beispiele:

Preis muss größer als 0 sein.
Produktname darf nicht leer sein.
Kategorie muss ausgewählt werden.
E-Mail-Adresse muss gültig sein.
Passwort muss lang genug sein.

Gute Fehlermeldungen stehen möglichst nah am betroffenen Feld.

Beispiel:

Preis *
[ 0,00 € ]

Preis muss größer als 0 sein.

Merksatz:

Fehlermeldung direkt dort anzeigen, wo der Fehler entsteht.

Buttons

Buttons lösen Aktionen aus.

Typische Buttons:

Wichtig:

Buttons sollten eindeutig beschriftet sein.

Nicht ideal:

OK
Weiter
Klick
Button 1

Besser:

Speichern
Abbrechen
Zurück zur Liste
Produkt löschen

Benutzerführung

Benutzerführung bedeutet:

Der Benutzer erkennt, was er tun soll.

Eine gute Oberfläche hilft dem Benutzer durch:

klare Überschriften
verständliche Feldnamen
sinnvolle Reihenfolge der Felder
sichtbare Pflichtfelder
verständliche Fehlertexte
logische Buttons
Rückweg zur Übersicht

Merksatz:

Der Benutzer soll nicht raten müssen.

Mock-up vs. UML-Diagramme

Merksatz:

Mock-up = Oberfläche
UML = Modell

Mock-up vs. ERM

Beispiel:

Mock-up-Feld: Produktname
ERM-Attribut: produktname

Mock-up vs. Aktivitätsdiagramm

Beispiel:

Mock-up:
Button „Speichern“

Aktivitätsdiagramm:
Eingabe prüfen → gültig? → speichern oder Fehler anzeigen

Vorgehensweise in der Prüfung

Wenn du ein Mock-up erstellen sollst, gehe so vor:

Typische IHK-Fehler

Prüfungs-Merksätze

Mock-up = visueller Oberflächenentwurf
Mock-up ist kein UML-Diagramm
Mock-up muss nicht funktionieren
Mock-up zeigt Felder, Buttons und Benutzerführung
Pflichtfelder klar markieren
Fehlermeldungen direkt am Feld anzeigen
Buttons eindeutig benennen
Benutzer soll die Oberfläche ohne Raten verstehen

Mini-Beispiel 1

Aufgabe:

Entwerfen Sie eine Eingabemaske zum Anlegen eines Produkts.

Wichtige Elemente:

Produktname *
Kategorie *
Preis *
Lagerbestand
Aktiv-Checkbox
Speichern
Abbrechen
Fehlermeldung bei ungültigem Preis

Mini-Beispiel 2

Aufgabe:

Ein Benutzer soll sich anmelden können.

Wichtige Elemente:

Benutzername / E-Mail
Passwort
Anmelden-Button
Passwort vergessen
Fehlermeldung bei falschen Zugangsdaten

Mini-Beispiel 3

Aufgabe:

Ein Kunde soll eine Bestellung abschließen können.

Wichtige Elemente:

Warenkorbübersicht
Lieferadresse
Zahlungsart
AGB-Checkbox
Bestellung abschließen
Zurück zum Warenkorb
Fehlermeldung bei fehlender Zahlungsart

Mini-Testfragen

Felder
Buttons
Navigation
Fehlermeldungen
Layout
Benutzerführung

Preis *

Preis muss größer als 0 sein.

Speichern
Abbrechen
Zurück zur Liste

OK
Weiter
Button 1

klare Beschriftungen
sinnvolle Reihenfolge
Fehlermeldungen
Rückwege

Mock-up: Speichern-Button
Aktivitätsdiagramm: Eingabe prüfen → speichern

Nächste Seite

Danach kommt die eigene Trainer-Seite:

Mock-up-Trainer

Dort übst du:

Pflichtfelder erkennen
Fehlermeldungen richtig platzieren
notwendige Buttons auswählen
Benutzerführung bewerten
Mock-up-Elemente aus einer Aufgabenstellung ableiten

Seite 16: Mock-up-Trainer

Dieser interaktive Trainer gehört zur Theorie-Seite:

Mock-up / Benutzeroberflächen-Entwurf

Hier übst du, aus einer Aufgabenbeschreibung die wichtigsten Elemente einer Benutzeroberfläche abzuleiten.

Im Fokus stehen:

Pflichtfelder
Fehlermeldungen
Validierung
Buttons
Hauptaktion
Nebenaktion
Benutzerführung
Mock-up ≠ UML-Diagramm

Was wird trainiert?

Interaktiver Mock-up-Trainer

Merksatz für den Trainer

Mock-up = geplanter Oberflächenentwurf
Mock-up ist kein UML-Diagramm
Pflichtfelder müssen erkennbar sein
Fehlermeldungen gehören nah an das betroffene Feld
Buttons müssen eindeutig beschriftet sein
Benutzerführung muss logisch und verständlich sein

Beispiel: Produktformular

Aufgabenstellung:

Ein Produkt soll angelegt werden.
Produktname, Kategorie und Preis sind Pflichtfelder.
Der Preis muss größer als 0 sein.
Der Benutzer soll speichern, abbrechen oder zurück zur Liste gehen können.

Mögliche Lösung:

Pflichtfelder:
Produktname
Kategorie
Preis

Fehlermeldung:
Direkt am Preisfeld

Hauptaktion:
Speichern

Sinnvolle Nebenaktionen:
Abbrechen
Zurück zur Liste

Validierung:
Preis muss größer als 0 sein

Einordnung:
Mock-up ist kein UML-Diagramm

Warum ist das fachlich richtig?

Ein Mock-up soll zeigen, wie eine Oberfläche aufgebaut ist und wie der Benutzer sie bedient.

Bei einem Produktformular muss der Benutzer erkennen:

Welche Daten muss ich eingeben?
Welche Felder sind Pflicht?
Was ist falsch, wenn eine Eingabe ungültig ist?
Wie speichere ich?
Wie breche ich ab?
Wie komme ich zurück?

Pflichtfelder

Pflichtfelder sind Felder, die ausgefüllt werden müssen.

Typische Darstellung:

Produktname *
Kategorie *
Preis *

Das Sternchen * zeigt:

Dieses Feld ist erforderlich.

Fehlermeldungen

Fehlermeldungen sollten möglichst direkt beim betroffenen Feld stehen.

Gut:

Preis *
[ 0,00 € ]
Preis muss größer als 0 sein.

Schlecht:

Irgendwo oben steht nur:
Fehler.

Merksatz:

Der Benutzer muss sofort erkennen, was falsch ist und wo er es korrigieren muss.

Validierung

Validierung bedeutet:

Das System prüft, ob die Eingabe gültig ist.

Beispiele:

Preis muss größer als 0 sein
E-Mail-Adresse muss gültig sein
Passwort darf nicht leer sein
Produktname muss ausgefüllt sein
Kategorie muss ausgewählt werden

Hauptaktion

Die Hauptaktion ist die wichtigste Aktion im Formular.

Beispiele:

Speichern
Anmelden
Bestellung abschließen
Absenden

Im Produktformular ist die Hauptaktion:

Speichern

Nebenaktionen

Nebenaktionen helfen dem Benutzer, den Vorgang zu verlassen oder zurückzugehen.

Beispiele:

Abbrechen
Zurück zur Liste
Zurück zum Warenkorb
Schließen

Wichtig:

Der Benutzer soll nicht in der Oberfläche feststecken.

Mock-up ist kein UML-Diagramm

Ein Mock-up zeigt eine Benutzeroberfläche.

Es zeigt nicht:

Klassen
Methoden
Kardinalitäten
Sequenzen
Kontrollflüsse
Datenbankbeziehungen

Dafür gibt es andere Diagramme.

Merksatz:

Mock-up = Oberfläche
UML = Modellierung

Typische Fehler im Mock-up

Mini-Testfragen

Pflichtfelder
Fehlermeldungen
Validierung
Buttons
Benutzerführung

Pflichtfeld

Preis muss größer als 0 sein.

Speichern

Abbrechen
Zurück zur Liste

Das System prüft, ob eine Eingabe gültig ist.

Preis muss größer als 0 sein.

Programmcode
Datenbankbeziehungen
Klassendiagramme
Sequenzdiagramme
Kontrollflüsse

Speichern
Abbrechen
Zurück zur Liste

OK
Weiter
Button 1

Die Oberfläche zeigt dem Benutzer klar, was er tun soll.

verständliche Feldnamen
sichtbare Pflichtfelder
klare Buttons
Fehlermeldungen
Rückwege

Nächste Seite

Danach geht es weiter mit:

UML-Zustandsdiagramm