Programmiertechnik

• 1 - 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
• 2 – APIs, SaaS-Systeme und Prozessautomatisierung
• 2.1 Überblick – SaaS-Systeme, APIs und Prozessautomatisierung
• 2.2 SaaS-, CRM-, Projektmanagement- und Kollaborationssysteme
• 2.3 API-Grundlagen – Client, Server, Endpoint, Request und Response
• 2.4 REST-APIs, HTTP-Methoden und CRUD
• 2.5 HTTP-Statuscodes und Fehlermeldungen
• 2.6 JSON – Aufbau und Verarbeitung strukturierter Daten
• 2.7 API-Authentifizierung – API-Key, Bearer-Token und OAuth 2.0
• 2.8 Webhooks, Polling, Trigger und Zeitpläne
• 2.9 Prozessautomatisierung mit n8n
• 2.10 Bedingungen, Datenmapping und Verzweigungen*
• 2.11 Fehlerbehandlung, Logging, Retry und Rate Limits
• 2.12 Sicherheit, Datenschutz und Least Privilege
• 2.13 Praxisprojekt – Automatisiertes Onboarding und Offboarding
• 2.14 Fehlersuche und Dokumentation von Schnittstellen
• 2.15 Prüfungsvorbereitung
• 2.16 Gesamttrainer – APIs, SaaS und Automatisierung

1 - Diagramme & Modelle für die IHK

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

2 – APIs, SaaS-Systeme und Prozessautomatisierung

2.1 Überblick – SaaS-Systeme, APIs und Prozessautomatisierung

Unternehmen nutzen häufig mehrere unterschiedliche Anwendungen, zum Beispiel:

• Google Workspace für E-Mail, Kalender und Dateien
• Slack für die interne Kommunikation
• Zoho CRM für Kunden und Vertriebsprozesse
• Asana oder Zoho Projects für Aufgaben und Projekte
• n8n für automatisierte Abläufe

Damit Daten nicht immer manuell zwischen diesen Systemen übertragen werden müssen, können sie über APIs, Webhooks und Automatisierungsplattformen miteinander verbunden werden.

Lernziele

Nach dieser Seite solltest du erklären können:

• was SaaS, CRM und Projektmanagement-Systeme sind
• was eine API ist
• was Request und Response bedeuten
• wofür JSON verwendet wird
• was Webhooks und Polling sind
• wie ein automatisierter Workflow aufgebaut ist

SaaS-System

SaaS bedeutet:

Software as a Service

Die Software wird als Onlinedienst bereitgestellt und meistens über einen Browser oder eine App verwendet.

Beispiele:

• Google Workspace
• Slack
• Microsoft 365
• Zoho
• Asana

Der Anbieter übernimmt normalerweise den Betrieb und die Aktualisierung der Plattform.

Das Unternehmen bleibt unter anderem verantwortlich für:

• Benutzerkonten
• Gruppen und Rollen
• Zugriffsrechte
• Multi-Faktor-Authentifizierung
• Datenschutz
• Onboarding und Offboarding

SaaS beschreibt, wie eine Software bereitgestellt wird.

CRM-System

CRM bedeutet:

Customer Relationship Management

Ein CRM-System verwaltet Informationen über:

• Kunden und Interessenten
• Ansprechpartner
• Gespräche
• Angebote
• Verträge
• Verkaufschancen
• offene Aufgaben und Termine

Beispiel:

Ein CRM-System ist eine zentrale digitale Kunden- und Vertriebsakte.

Projektmanagement-System

Ein Projektmanagement-System organisiert:

• Projekte
• Aufgaben
• Verantwortliche
• Termine
• Prioritäten
• Bearbeitungsstände
• Dokumente
• Abhängigkeiten

Beispiel:

Ein Projektmanagement-System organisiert Aufgaben, Zuständigkeiten und Termine.

Unterschied der Begriffe

Ein CRM- oder Projektmanagement-System kann gleichzeitig ein SaaS-System sein.

API

API bedeutet:

Application Programming Interface

Auf Deutsch:

Programmierschnittstelle

Eine API ermöglicht es unterschiedlichen Programmen, Daten auszutauschen oder Funktionen eines anderen Systems aufzurufen.

Beispiel:

n8n
  |
  | API-Anfrage
  v
Google Workspace
  |
  | API-Antwort
  v
n8n

Eine API legt unter anderem fest:

• welche Funktionen verfügbar sind
• welche Daten gesendet werden müssen
• welche Berechtigungen benötigt werden
• welches Ergebnis zurückgegeben wird

Eine Benutzeroberfläche ist für Menschen gedacht. Eine API ist für die Kommunikation zwischen Programmen gedacht.

Request und Response

Ein Request ist eine Anfrage.

Beispiel:

Lege einen neuen Benutzer an.

Eine Response ist die Antwort des Systems.

Beispiel:

Benutzer wurde erfolgreich angelegt.

Grundablauf:

Client
  |
  | Request
  v
Server
  |
  | Response
  v
Client

Request bedeutet Anfrage. Response bedeutet Antwort.

Endpoint

Ein Endpoint ist eine konkrete Adresse innerhalb einer API.

Beispiele:

https://api.example.com/users

https://api.example.com/projects

Die Adresse /users könnte Benutzer verwalten. Die Adresse /projects könnte Projekte verwalten.

Ein Endpoint ist eine konkrete API-Adresse für eine Ressource oder Funktion.

JSON

JSON bedeutet:

JavaScript Object Notation

JSON ist ein textbasiertes Format für strukturierte Daten.

Beispiel:

{
  "name": "Max Mustermann",
  "department": "IT",
  "active": true
}

APIs verwenden JSON häufig für Requests und Responses.

JSON überträgt strukturierte Daten zwischen Anwendungen.

Webhook und Polling

Ein Webhook meldet automatisch ein Ereignis.

Beispiel:

Ein neuer Mitarbeiter wurde angelegt.

Das System sendet die Information sofort an n8n und startet dadurch einen Workflow.

Beim Polling fragt n8n dagegen regelmäßig:

Gibt es neue Daten?

Beim Webhook wird ein Ereignis gemeldet. Beim Polling wird regelmäßig danach gefragt.

Automatisierter Workflow

Ein Workflow ist eine festgelegte Folge von Schritten.

Beispiel:

Neuer Mitarbeiter
      |
      v
Daten prüfen
      |
      v
Benutzerkonto anlegen
      |
      v
Gruppen zuweisen
      |
      v
IT-Aufgabe erstellen
      |
      v
Ergebnis protokollieren

Typische Bestandteile:

Praxisbeispiel: Mitarbeiter-Onboarding

Ein neuer Mitarbeiter wird im Personalsystem freigegeben.

1. Das Personalsystem sendet einen Webhook.
2. n8n empfängt die Mitarbeiterdaten.
3. Die Daten werden geprüft.
4. Über eine API wird ein Benutzerkonto angelegt.
5. Gruppen und Rollen werden zugewiesen.
6. Eine Aufgabe für die Laptop-Einrichtung wird erstellt.
7. Die IT erhält eine Slack-Nachricht.
8. Das Ergebnis wird protokolliert.

Beteiligte Systeme könnten sein:

• Personalsystem
• n8n
• Google Workspace
• Slack
• Projektmanagement-System
• Ticketsystem

Vorteile der Automatisierung

• Zeitersparnis
• weniger manuelle Übertragungsfehler
• einheitliche Abläufe
• bessere Dokumentation
• schnellere Reaktion
• bessere Skalierbarkeit

Risiken der Automatisierung

• falsche Eingabedaten
• fehlende Berechtigungen
• abgelaufene Zugangstoken
• nicht erreichbare Systeme
• doppelte Ausführung
• unvollständige Prozesse
• Datenschutzprobleme
• fehlende Fehlerbehandlung

Eine Automatisierung ist erst professionell, wenn auch Fehler und Ausnahmefälle behandelt werden.

Aufgaben der internen IT

• Benutzer und Gruppen verwalten
• Rollen und Rechte vergeben
• MFA konfigurieren
• SaaS-Systeme administrieren
• API-Zugänge absichern
• Workflows überwachen
• Logs kontrollieren
• Fehler analysieren
• Onboarding und Offboarding durchführen
• technische Abläufe dokumentieren

Systematische Fehlersuche

Wenn ein Workflow nicht funktioniert:

1. Wurde der Workflow ausgelöst?
2. Sind die Eingabedaten vollständig?
3. Ist das Zielsystem erreichbar?
4. Ist der Endpoint korrekt?
5. Ist die Authentifizierung gültig?
6. Sind ausreichende Berechtigungen vorhanden?
7. Welche Fehlermeldung oder welcher Statuscode wurde zurückgegeben?
8. Welcher Schritt ist fehlgeschlagen?
9. Kann der Schritt sicher erneut ausgeführt werden?
10. Muss ein Administrator informiert werden?

Wichtige Begriffe

Gesamtmerksatz

SaaS-Systeme stellen Anwendungen als Onlinedienst bereit. APIs verbinden unterschiedliche Systeme. JSON überträgt strukturierte Daten. Webhooks melden Ereignisse und Automatisierungsplattformen wie n8n führen daraus festgelegte Workflows aus.

Kontrollfragen

Was beschreibt SaaS?

SaaS beschreibt die Bereitstellung einer Software als Onlinedienst.

Was ist ein CRM-System?

Ein System zur Verwaltung von Kunden, Kontakten und Vertriebsprozessen.

Was ermöglicht eine API?

Sie ermöglicht die Kommunikation und den Datenaustausch zwischen Programmen.

Was ist der Unterschied zwischen Request und Response?

Der Request ist die Anfrage. Die Response ist die Antwort.

Was ist JSON?

Ein textbasiertes Format für strukturierte Daten.

Was ist der Unterschied zwischen Webhook und Polling?

Ein Webhook meldet ein Ereignis aktiv. Beim Polling wird regelmäßig nach Änderungen gefragt.

Was startet einen Workflow?

Ein Trigger, beispielsweise ein Webhook, Zeitplan oder manueller Start.

Quellen

• NIST – The Definition of Cloud Computing
• IETF – HTTP Semantics
• IETF – JSON Data Interchange Format
• n8n-Dokumentation – Workflows
• n8n-Dokumentation – Webhook Node

2.2 SaaS-, CRM-, Projektmanagement- und Kollaborationssysteme

Unternehmen verwenden verschiedene Softwarearten für unterschiedliche Aufgaben.

Typische Systeme sind:

• SaaS-Systeme für online bereitgestellte Anwendungen
• CRM-Systeme für Kunden und Vertriebsprozesse
• Projektmanagement-Systeme für Aufgaben und Termine
• Kollaborationssysteme für Kommunikation und Zusammenarbeit

Eine Anwendung kann mehreren Kategorien gleichzeitig angehören.

Lernziele

Nach dieser Seite solltest du erklären können:

• was SaaS bedeutet
• was CRM-, Projektmanagement- und Kollaborationssysteme unterscheiden
• welche Aufgaben die interne IT übernimmt
• wie Benutzer, Rollen und Lizenzen verwaltet werden
• welche Vorteile und Risiken Cloud-Anwendungen besitzen
• warum verschiedene Systeme über APIs verbunden werden

Software as a Service

SaaS bedeutet:

Software as a Service

Eine Software wird vom Anbieter betrieben und über das Internet bereitgestellt.

Die Nutzung erfolgt meistens über:

• Webbrowser
• Desktop-Anwendung
• Smartphone-App
• API

Typische SaaS-Beispiele:

• Google Workspace
• Microsoft 365
• Slack
• Asana
• Zoho CRM
• Salesforce
• Dropbox

Das Unternehmen muss normalerweise keine eigenen Anwendungsserver betreiben.

Aufgaben des SaaS-Anbieters

Der Anbieter übernimmt typischerweise:

• Betrieb der Plattform
• Wartung der Server
• Softwareaktualisierungen
• technische Verfügbarkeit
• Absicherung der Anbieterinfrastruktur
• Fehlerbehebung innerhalb der Plattform

Aufgaben des verwendenden Unternehmens

Die interne IT bleibt unter anderem verantwortlich für:

• Benutzerkonten
• Gruppen
• Rollen und Berechtigungen
• Multi-Faktor-Authentifizierung
• Lizenzen
• sichere Konfiguration
• Freigaben
• Datenschutz
• Onboarding und Offboarding
• Kontrolle der Zugriffsprotokolle
• Integration mit anderen Systemen

Der Anbieter betreibt die Plattform. Das Unternehmen verwaltet seine Benutzer, Daten und Zugriffsrechte.

CRM-System

CRM bedeutet:

Customer Relationship Management

Ein CRM-System verwaltet Kundenbeziehungen und Vertriebsprozesse.

Typische Inhalte:

• Unternehmen
• Ansprechpartner
• Kontaktdaten
• Gespräche
• Angebote
• Verträge
• Verkaufschancen
• Aufgaben
• Termine
• Projektstatus

Beispiel:

Ein CRM-System ist eine zentrale Kunden- und Vertriebsakte.

Typischer CRM-Ablauf

Neuer Interessent
      |
      v
Kontaktdaten erfassen
      |
      v
Beratungsgespräch dokumentieren
      |
      v
Angebot erstellen
      |
      v
Auftrag gewinnen oder ablehnen
      |
      v
Kundenbeziehung weiter betreuen

CRM-Systeme helfen dabei, dass Informationen nicht nur in persönlichen E-Mails oder einzelnen Dateien gespeichert werden.

Projektmanagement-System

Ein Projektmanagement-System organisiert Projekte und Aufgaben.

Typische Funktionen:

• Projekte anlegen
• Aufgaben erstellen
• Verantwortliche zuweisen
• Termine festlegen
• Prioritäten vergeben
• Bearbeitungsstände anzeigen
• Abhängigkeiten verwalten
• Kommentare erfassen
• Dokumente verknüpfen
• Fortschritt überwachen

Beispiel:

Ein Projektmanagement-System organisiert Aufgaben, Zuständigkeiten, Fristen und Fortschritte.

Kollaborationssystem

Kollaboration bedeutet Zusammenarbeit.

Ein Kollaborationssystem unterstützt Mitarbeiter bei:

• Nachrichten
• Gruppenchats
• Videokonferenzen
• gemeinsamer Dateibearbeitung
• Kommentaren
• Kalendern
• Benachrichtigungen
• Informationsaustausch

Typische Beispiele:

Slack als Beispiel

Slack ist eine Kommunikationsplattform für Unternehmen.

Die Kommunikation erfolgt unter anderem über:

• Direktnachrichten
• Gruppennachrichten
• öffentliche Kanäle
• private Kanäle
• Threads
• Sprach- und Videoanrufe

Beispiele für Kanäle:

#it-support
#projekt-solar
#allgemein
#vertrieb
#product-tech

Ein Kanal bündelt Nachrichten zu einem bestimmten Team oder Thema.

Slack kann außerdem Benachrichtigungen anderer Systeme anzeigen.

Beispiel:

Ein n8n-Workflow sendet eine Nachricht an den Kanal #it-support, wenn ein automatisierter Prozess fehlschlägt.

Unterschied der Systemarten

Eine Anwendung kann mehrere Funktionen besitzen.

Beispiele:

SaaS beschreibt die Bereitstellung. Die anderen Begriffe beschreiben den Einsatzzweck.

Benutzerkonten

Für jeden Mitarbeiter wird normalerweise ein persönliches Benutzerkonto angelegt.

Ein Benutzerkonto kann enthalten:

• Name
• E-Mail-Adresse
• Abteilung
• Rolle
• Gruppenmitgliedschaften
• Lizenzen
• Zugriffsrechte
• Spracheinstellungen
• Sicherheitsinformationen

Gemeinsam verwendete Benutzerkonten sollten möglichst vermieden werden.

Nachteile gemeinsamer Konten:

• Aktionen sind nicht eindeutig zuordenbar
• Passwörter müssen geteilt werden
• Zugriffe lassen sich schwer entziehen
• Protokolle verlieren ihre Aussagekraft
• Sicherheitsvorfälle sind schwerer nachzuvollziehen

Gruppen und Rollen

Benutzer werden häufig anhand ihrer Aufgaben in Gruppen oder Rollen eingeordnet.

Beispiele:

Rollenbasierte Rechtevergabe wird auch als RBAC bezeichnet.

RBAC bedeutet:

Role-Based Access Control

Dabei werden Rechte anhand einer Rolle vergeben und nicht für jeden Benutzer einzeln zusammengestellt.

Least Privilege

Least Privilege bedeutet:

Jeder Benutzer erhält nur die Rechte, die er für seine Aufgaben benötigt.

Beispiele:

• Ein Vertriebsmitarbeiter benötigt keinen vollständigen Administratorzugriff.
• Ein Praktikant benötigt nicht automatisch Zugriff auf alle Kundendaten.
• Ein Automatisierungsworkflow sollte nur die benötigten API-Rechte besitzen.
• Ein ausgeschiedener Mitarbeiter darf keine aktiven Zugänge behalten.

Vorteile:

• geringeres Sicherheitsrisiko
• weniger versehentliche Änderungen
• bessere Nachvollziehbarkeit
• einfachere Rechtekontrolle

Lizenzen

Viele SaaS-Systeme werden pro Benutzer und Monat bezahlt.

Die interne IT muss daher prüfen:

• Wer benötigt eine Lizenz?
• Welche Lizenzstufe wird benötigt?
• Welche Konten werden nicht mehr verwendet?
• Wurden Konten ausgeschiedener Mitarbeiter deaktiviert?
• Werden unnötige Kosten verursacht?

Beispiel:

Ein Mitarbeiter verlässt das Unternehmen.

Die IT sollte:

1. den Zugang sperren
2. aktive Sitzungen beenden
3. Daten sichern oder übertragen
4. Gruppenmitgliedschaften entfernen
5. Lizenzen freigeben
6. den Vorgang dokumentieren

Onboarding

Onboarding bezeichnet die technische Einrichtung eines neuen Mitarbeiters.

Typische Aufgaben:

• Benutzerkonto anlegen
• E-Mail-Adresse erstellen
• Gruppen zuweisen
• Rollen vergeben
• Lizenzen aktivieren
• MFA einrichten
• Laptop vorbereiten
• benötigte Software installieren
• Zugänge dokumentieren
• Einführung bereitstellen

Ein standardisierter Ablauf verhindert, dass wichtige Schritte vergessen werden.

Offboarding

Offboarding bezeichnet die technische Bearbeitung eines Mitarbeiteraustritts.

Typische Aufgaben:

• Benutzerkonto deaktivieren
• aktive Sitzungen beenden
• Passwörter oder Tokens widerrufen
• Zugriffsrechte entfernen
• Daten an zuständige Personen übertragen
• Geräte zurücknehmen
• Lizenzen freigeben
• automatische Weiterleitungen prüfen
• Vorgang dokumentieren

Ein nicht vollständig durchgeführtes Offboarding kann ein erhebliches Sicherheitsrisiko darstellen.

Multi-Faktor-Authentifizierung

Bei der Multi-Faktor-Authentifizierung werden mindestens zwei unterschiedliche Faktoren benötigt.

Mögliche Faktoren:

• Wissen: Passwort oder PIN
• Besitz: Smartphone oder Sicherheitsschlüssel
• biometrisches Merkmal: Fingerabdruck oder Gesichtserkennung

Beispiel:

Passwort
   +
Bestätigung über eine Authenticator-App

MFA schützt Konten zusätzlich, wenn ein Passwort gestohlen wurde.

Single Sign-on

SSO bedeutet:

Single Sign-on

Ein Benutzer meldet sich zentral an und kann anschließend mehrere verbundene Anwendungen verwenden.

Beispiel:

Zentrale Anmeldung
       |
       v
Google Workspace
   /    |    \
  v     v     v
Slack  CRM  Projektmanagement

Vorteile:

• weniger separate Passwörter
• zentrale Benutzerverwaltung
• schnellere Sperrung von Zugängen
• vereinfachtes Onboarding und Offboarding

Risiko:

Fällt das zentrale Konto aus oder wird es übernommen, können mehrere Systeme betroffen sein.

Audit-Logs

Audit-Logs protokollieren sicherheitsrelevante Aktionen.

Beispiele:

• Benutzer wurde angelegt
• Rolle wurde geändert
• Anmeldung ist fehlgeschlagen
• MFA wurde deaktiviert
• Datei wurde freigegeben
• API-Token wurde erstellt
• Administratorrechte wurden vergeben

Audit-Logs helfen bei:

• Fehlersuche
• Sicherheitsanalysen
• Nachvollziehbarkeit
• Datenschutzprüfungen
• internen Kontrollen

Vorteile von SaaS-Systemen

• schnelle Bereitstellung
• Zugriff über verschiedene Geräte
• automatische Aktualisierungen
• geringe eigene Serververwaltung
• einfache Erweiterbarkeit
• häufig gute Integrationsmöglichkeiten
• flexible Lizenzmodelle
• zentrale Zusammenarbeit

Risiken von SaaS-Systemen

• Abhängigkeit vom Anbieter
• mögliche Ausfälle
• laufende Lizenzkosten
• Datenschutzanforderungen
• falsche Freigaben
• zu umfangreiche Berechtigungen
• unvollständiges Offboarding
• unkontrollierte Schatten-IT
• eingeschränkte Kontrolle über die Infrastruktur
• Änderungen an Funktionen oder Schnittstellen

Schatten-IT

Schatten-IT bezeichnet Software oder Dienste, die ohne Freigabe der IT verwendet werden.

Beispiel:

Ein Mitarbeiter erstellt selbstständig ein Konto bei einem Onlinedienst und lädt dort Unternehmensdaten hoch.

Mögliche Risiken:

• unbekannte Datenspeicherung
• fehlende Sicherheitsprüfung
• keine zentrale Benutzerverwaltung
• fehlendes Offboarding
• zusätzliche Kosten
• Datenschutzverletzungen

Die IT sollte deshalb klare Prozesse für die Auswahl und Freigabe neuer SaaS-Anwendungen besitzen.

Verbindung verschiedener Systeme

SaaS-Systeme können über APIs miteinander verbunden werden.

Beispiel:

Zoho CRM
    |
    | neuer Kunde
    v
   n8n
  /   \
 v     v
Asana  Slack

Möglicher Ablauf:

1. Im CRM wird ein neuer Kunde angelegt.
2. Das CRM startet einen Webhook.
3. n8n empfängt die Kundendaten.
4. In Asana wird ein Projekt erstellt.
5. In Slack wird das zuständige Team informiert.
6. Das Ergebnis wird protokolliert.

Aufgaben der internen IT

Die interne IT übernimmt bei SaaS-Systemen unter anderem:

• Benutzerverwaltung
• Gruppenverwaltung
• Rollen- und Rechtevergabe
• Lizenzverwaltung
• Onboarding und Offboarding
• MFA und SSO
• Integration verschiedener Systeme
• API-Zugänge
• Überwachung von Audit-Logs
• Support
• Dokumentation
• Datenschutz und Sicherheit
• Kontrolle von Schatten-IT

Systematische Fehlersuche

Wenn ein Benutzer keinen Zugriff auf ein SaaS-System besitzt:

1. Ist das Benutzerkonto aktiv?
2. Ist die richtige Lizenz zugewiesen?
3. Ist der Benutzer in der richtigen Gruppe?
4. Besitzt die Rolle ausreichende Rechte?
5. Funktioniert die zentrale Anmeldung?
6. Ist MFA korrekt eingerichtet?
7. Wurde das Passwort oder Token geändert?
8. Ist nur ein Benutzer oder das gesamte System betroffen?
9. Gibt es eine bekannte Störung beim Anbieter?
10. Welche Meldung steht im Audit-Log?

Wichtige Begriffe

Gesamtmerksatz

SaaS beschreibt die Bereitstellung einer Anwendung als Onlinedienst. CRM-Systeme verwalten Kunden, Projektmanagement-Systeme organisieren Aufgaben und Kollaborationssysteme unterstützen die Zusammenarbeit. Die interne IT bleibt für Benutzer, Rollen, Lizenzen, Sicherheit und Integrationen verantwortlich.

Kontrollfragen

Was bedeutet SaaS?

Software as a Service. Die Software wird als Onlinedienst bereitgestellt.

Was ist die Hauptaufgabe eines CRM-Systems?

Die Verwaltung von Kunden, Interessenten und Vertriebsprozessen.

Was verwaltet ein Projektmanagement-System?

Projekte, Aufgaben, Zuständigkeiten, Termine und Bearbeitungsstände.

Was ist ein Kollaborationssystem?

Eine Anwendung für Kommunikation und digitale Zusammenarbeit.

Was bedeutet RBAC?

Berechtigungen werden anhand einer Rolle vergeben.

Was bedeutet Least Privilege?

Benutzer und Anwendungen erhalten nur die tatsächlich benötigten Rechte.

Was ist Onboarding?

Die technische Einrichtung eines neuen Mitarbeiters.

Was ist Offboarding?

Das kontrollierte Entfernen von Zugängen und Berechtigungen beim Austritt.

Warum sind Audit-Logs wichtig?

Sie machen Änderungen, Zugriffe und sicherheitsrelevante Ereignisse nachvollziehbar.

Was ist Schatten-IT?

Software oder Dienste, die ohne Freigabe und Kontrolle der IT verwendet werden.

Quellen

• NIST – The Definition of Cloud Computing
• NIST – Software as a Service
• Google Workspace Admin Help
• Slack Help Center
• Zoho CRM Help
• Asana Guide

2.3 API-Grundlagen – Client, Server, Endpoint, Request und Response

Eine API ermöglicht es verschiedenen Programmen, Daten auszutauschen oder Funktionen eines anderen Systems aufzurufen.

API bedeutet:

Application Programming Interface

Auf Deutsch:

Programmierschnittstelle

APIs werden beispielsweise verwendet, um:

• Benutzerkonten anzulegen
• Kundendaten abzurufen
• Aufgaben zu erstellen
• Nachrichten zu versenden
• Dateien hochzuladen
• Statusinformationen auszulesen
• automatisierte Workflows auszuführen

Lernziele

Nach dieser Seite solltest du erklären können:

• was eine API ist
• was Client und Server bedeuten
• was ein Endpoint ist
• wie Request und Response zusammenhängen
• wozu Header und Body verwendet werden
• was Path- und Query-Parameter sind
• wie eine typische API-Kommunikation abläuft
• wie API-Fehler systematisch eingegrenzt werden

Benutzeroberfläche und API

Ein Mensch verwendet meistens eine grafische Benutzeroberfläche.

Beispiel:

Benutzer
   |
   v
Webbrowser
   |
   v
Schaltfläche „Benutzer anlegen“

Ein Programm verwendet dagegen häufig eine API.

Beispiel:

n8n
  |
  | API-Anfrage
  v
Google Workspace
  |
  | API-Antwort
  v
n8n

Die API ermöglicht den Zugriff auf bestimmte Funktionen, ohne dass ein Mensch jede Aktion manuell über die Benutzeroberfläche ausführen muss.

Eine Benutzeroberfläche ist für Menschen gedacht. Eine API ist für die Kommunikation zwischen Programmen gedacht.

Client und Server

Bei einer API-Kommunikation gibt es normalerweise einen Client und einen Server.

Client

Der Client sendet eine Anfrage.

Beispiele:

• n8n
• Webbrowser
• Smartphone-App
• PowerShell-Skript
• Verwaltungssoftware
• anderes SaaS-System

Server

Der Server verarbeitet die Anfrage und sendet eine Antwort zurück.

Beispiele:

• CRM-System
• Google Workspace
• Slack
• Projektmanagement-System
• Webserver
• Datenbankdienst

Grundablauf:

Client
  |
  | Request
  v
Server
  |
  | Response
  v
Client

Der Client stellt eine Anfrage. Der Server verarbeitet sie und antwortet.

Request

Ein Request ist eine Anfrage an einen Server.

Ein Request kann beispielsweise bedeuten:

• Daten abrufen
• neue Daten anlegen
• vorhandene Daten ändern
• Daten löschen
• eine bestimmte Aktion ausführen

Beispiel:

Rufe den Benutzer mit der ID 15 ab.

Ein Request enthält häufig:

• HTTP-Methode
• URL beziehungsweise Endpoint
• Header
• Parameter
• Body
• Authentifizierungsinformationen

Response

Eine Response ist die Antwort des Servers.

Sie enthält häufig:

• HTTP-Statuscode
• Header
• Daten
• Erfolgsbestätigung
• Fehlermeldung

Beispiel:

Benutzer wurde gefunden.

Oder:

Benutzer wurde nicht gefunden.

Grundprinzip:

Endpoint

Ein Endpoint ist eine konkrete Adresse innerhalb einer API.

Beispiel:

https://api.example.com/users

Dieser Endpoint könnte für Benutzer zuständig sein.

Weitere Beispiele:

https://api.example.com/projects

https://api.example.com/customers

https://api.example.com/messages

Ein einzelner Benutzer könnte über seine ID angesprochen werden:

https://api.example.com/users/15

Ein Endpoint ist eine konkrete API-Adresse für eine Ressource oder Funktion.

Ressource

Eine Ressource ist ein Objekt oder Datentyp, der über eine API verwaltet wird.

Beispiele:

• Benutzer
• Kunde
• Projekt
• Aufgabe
• Nachricht
• Datei
• Rechnung

Typische Zuordnung:

Aufbau einer API-Adresse

Beispiel:

https://api.example.com/v1/users/15

Die Adresse besteht aus mehreren Teilen:

Die API-Version ist wichtig, weil Anbieter ihre Schnittstellen weiterentwickeln können.

Beispiel:

/v1/users

/v2/users

Eine neue Version kann andere Funktionen oder Datenstrukturen besitzen.

HTTP-Methode

Die HTTP-Methode beschreibt, welche Aktion ausgeführt werden soll.

Typische Methoden:

Beispiel:

GET /users/15

Bedeutung:

Rufe den Benutzer mit der ID 15 ab.

Beispiel:

DELETE /users/15

Bedeutung:

Lösche den Benutzer mit der ID 15.

Die Methoden werden auf der nächsten Seite genauer behandelt.

Header

Header enthalten zusätzliche Informationen über den Request oder die Response.

Typische Header:

Beispiel:

Authorization: Bearer abc123

Content-Type: application/json

Der erste Header übermittelt ein Zugangstoken.

Der zweite Header teilt dem Server mit, dass die gesendeten Daten im JSON-Format vorliegen.

Header enthalten Steuerungs- und Zusatzinformationen.

Body

Der Body enthält die eigentlichen Nutzdaten eines Requests oder einer Response.

Beispiel für einen Request-Body:

{
  "name": "Max Mustermann",
  "department": "IT",
  "active": true
}

Diese Daten könnten verwendet werden, um einen Benutzer anzulegen.

Nicht jeder Request benötigt einen Body.

Beispiele:

• Ein GET-Request besitzt häufig keinen Body.
• Ein POST-Request enthält häufig neue Daten.
• Ein PATCH-Request enthält häufig die zu ändernden Werte.

Der Header beschreibt die Anfrage. Der Body enthält häufig die eigentlichen Daten.

Path-Parameter

Ein Path-Parameter ist direkt Bestandteil des Endpoints.

Beispiel:

/users/15

Die Zahl 15 ist die ID eines bestimmten Benutzers.

Allgemeine Schreibweise:

/users/{id}

Weitere Beispiele:

/projects/25

/customers/107

/tasks/42

Path-Parameter werden häufig verwendet, um eine bestimmte Ressource eindeutig anzusprechen.

Query-Parameter

Query-Parameter stehen hinter einem Fragezeichen in der URL.

Beispiel:

/users?department=IT

Bedeutung:

Rufe alle Benutzer aus der Abteilung IT ab.

Mehrere Query-Parameter werden häufig mit & getrennt.

Beispiel:

/users?department=IT&active=true

Bedeutung:

Rufe alle aktiven Benutzer aus der Abteilung IT ab.

Typische Anwendungen:

• Filtern
• Sortieren
• Suchen
• Seitennavigation
• Begrenzen der Ergebnisse

Path- und Query-Parameter im Vergleich

Merksatz:

Path-Parameter bestimmen häufig, welche Ressource gemeint ist. Query-Parameter verändern oder begrenzen die Abfrage.

Beispiel eines vollständigen Requests

GET https://api.example.com/v1/users/15

Authorization: Bearer abc123
Accept: application/json

Bedeutung:

• GET ruft Daten ab.
• Der Endpoint verweist auf Benutzer 15.
• Das Token authentifiziert den Client.
• Die Antwort soll im JSON-Format zurückgegeben werden.

Beispiel einer erfolgreichen Response

Status: 200 OK

{
  "id": 15,
  "name": "Max Mustermann",
  "department": "IT",
  "active": true
}

Die Response enthält:

• Statuscode 200
• Erfolgsstatus OK
• Benutzerdaten im JSON-Format

Beispiel einer fehlerhaften Response

Status: 404 Not Found

{
  "error": "User not found"
}

Bedeutung:

• Der Server wurde erreicht.
• Die Anfrage wurde verarbeitet.
• Der Benutzer wurde jedoch nicht gefunden.

Typischer API-Ablauf

1. Der Client erstellt einen Request.
2. Der Request wird an einen Endpoint gesendet.
3. Der Server prüft die Anfrage.
4. Die Authentifizierung wird kontrolliert.
5. Die Berechtigungen werden geprüft.
6. Der Server führt die gewünschte Aktion aus.
7. Der Server erstellt eine Response.
8. Der Client wertet Statuscode und Daten aus.
9. Das Ergebnis wird weiterverarbeitet oder protokolliert.

Darstellung:

Client
  |
  | Request
  v
API-Endpoint
  |
  v
Authentifizierung prüfen
  |
  v
Berechtigung prüfen
  |
  v
Aktion ausführen
  |
  v
Response erstellen
  |
  v
Client

API-Dokumentation

Eine API-Dokumentation beschreibt, wie eine Schnittstelle verwendet wird.

Sie enthält normalerweise:

• verfügbare Endpoints
• erlaubte HTTP-Methoden
• benötigte Parameter
• Datenformate
• Authentifizierungsverfahren
• Beispiel-Requests
• Beispiel-Responses
• Statuscodes
• Fehlermeldungen
• Rate Limits
• API-Versionen

Vor der Nutzung einer API sollte zuerst die offizielle Dokumentation geprüft werden.

Eine API sollte nicht durch Vermutungen verwendet werden, sondern anhand ihrer Dokumentation.

Authentifizierung und Autorisierung

Authentifizierung beantwortet die Frage:

Wer greift auf das System zu?

Beispiele:

• API-Key
• Bearer-Token
• OAuth 2.0
• Benutzername und Passwort

Autorisierung beantwortet die Frage:

Was darf dieser Client tun?

Beispiel:

Ein API-Token darf Benutzer lesen, aber keine Benutzer löschen.

API-Schlüssel und Tokens

API-Zugangsdaten müssen sicher behandelt werden.

Sie dürfen nicht:

• öffentlich veröffentlicht werden
• direkt in Dokumentationen stehen
• unverschlüsselt weitergegeben werden
• in öffentlich zugänglichen Git-Repositories gespeichert werden
• in Screenshots sichtbar sein

Sicherer sind:

• geschützte Credential-Speicher
• Umgebungsvariablen
• Secret-Management-Systeme
• eingeschränkte Berechtigungen
• regelmäßiger Austausch der Tokens

Praxisbeispiel mit n8n

Ein n8n-Workflow soll einen Benutzer aus einem CRM-System abrufen.

Ablauf:

n8n
  |
  | GET /users/15
  v
CRM-API
  |
  | Response mit Benutzerdaten
  v
n8n
  |
  v
Daten prüfen und weiterverarbeiten

n8n benötigt dafür:

• Endpoint
• HTTP-Methode
• Authentifizierung
• mögliche Parameter
• erwartetes Antwortformat
• Fehlerbehandlung

Mögliche Fehlerquellen

Eine API-Anfrage kann aus verschiedenen Gründen fehlschlagen.

Typische Ursachen:

• falscher Endpoint
• falsche HTTP-Methode
• ungültiges Token
• fehlende Berechtigung
• falscher Header
• fehlerhafter JSON-Body
• fehlender Pflichtparameter
• falsche Benutzer-ID
• nicht erreichbarer Server
• veraltete API-Version
• Rate Limit erreicht

Systematische Fehlersuche

Wenn ein API-Aufruf nicht funktioniert:

1. Ist die URL korrekt?
2. Ist der Endpoint noch gültig?
3. Wird die richtige HTTP-Methode verwendet?
4. Ist das Token gültig?
5. Sind die benötigten Berechtigungen vorhanden?
6. Sind alle Pflichtparameter enthalten?
7. Ist der Content-Type korrekt?
8. Ist der JSON-Body gültig?
9. Welcher Statuscode wird zurückgegeben?
10. Welche Fehlermeldung enthält die Response?
11. Funktioniert die Anfrage mit Testdaten?
12. Wurde die API-Dokumentation geprüft?

Wichtige Begriffe

Gesamtmerksatz

Der Client sendet einen Request an einen API-Endpoint. Der Server prüft Authentifizierung, Berechtigungen und Daten, führt die gewünschte Aktion aus und sendet anschließend eine Response zurück.

Kontrollfragen

Was ist eine API?

Eine Programmierschnittstelle, über die Anwendungen Daten austauschen oder Funktionen aufrufen können.

Was ist ein Client?

Ein Programm oder System, das eine Anfrage sendet.

Was ist ein Server?

Ein System, das eine Anfrage verarbeitet und eine Antwort zurücksendet.

Was ist ein Endpoint?

Eine konkrete Adresse innerhalb einer API.

Was ist eine Ressource?

Ein Objekt, das über eine API verwaltet wird, beispielsweise ein Benutzer oder Projekt.

Was enthält ein Header?

Zusätzliche Informationen wie Datenformat, Authentifizierung oder gewünschtes Antwortformat.

Was enthält ein Body?

Die eigentlichen Nutzdaten eines Requests oder einer Response.

Was ist der Unterschied zwischen Path- und Query-Parameter?

Ein Path-Parameter identifiziert häufig eine bestimmte Ressource. Ein Query-Parameter filtert oder verändert die Abfrage.

Was ist der Unterschied zwischen Authentifizierung und Autorisierung?

Authentifizierung prüft die Identität. Autorisierung prüft die erlaubten Aktionen.

Quellen

• IETF – RFC 9110: HTTP Semantics
• MDN Web Docs – HTTP
• MDN Web Docs – HTTP Headers
• MDN Web Docs – URL Search Parameters
• n8n-Dokumentation – HTTP Request Node

2.4 REST-APIs, HTTP-Methoden und CRUD

REST ist ein häufig verwendetes Prinzip für Web-APIs.

REST bedeutet:

Representational State Transfer

REST-APIs stellen Ressourcen über eindeutige Adressen bereit und verwenden HTTP-Methoden, um Daten zu lesen, anzulegen, zu verändern oder zu löschen.

Typische Ressourcen sind:

• Benutzer
• Kunden
• Projekte
• Aufgaben
• Nachrichten
• Dateien

Lernziele

Nach dieser Seite solltest du erklären können:

• was eine REST-API ist
• was eine Ressource ist
• welche Aufgaben GET, POST, PUT, PATCH und DELETE besitzen
• was CRUD bedeutet
• wie HTTP-Methoden und CRUD zusammenhängen
• warum PUT und PATCH nicht dasselbe sind
• was Idempotenz bedeutet
• wie REST-Anfragen aufgebaut werden

Ressourcen in einer REST-API

Eine Ressource ist ein Objekt, das über die API verwaltet wird.

Beispiele:

Eine einzelne Ressource wird häufig über eine ID angesprochen.

Beispiel:

/users/15

Bedeutung:

Benutzer mit der ID 15

HTTP-Methoden

Die HTTP-Methode beschreibt, welche Aktion mit einer Ressource ausgeführt werden soll.

Die Kombination aus Methode und Endpoint bestimmt die gewünschte Aktion.

Beispiel:

GET /users/15

Bedeutung:

Benutzer 15 abrufen

Beispiel:

DELETE /users/15

Bedeutung:

Benutzer 15 löschen

GET – Daten lesen

GET wird verwendet, um Daten abzurufen.

Beispiele:

GET /users

Alle Benutzer abrufen.

GET /users/15

Benutzer 15 abrufen.

GET /users?department=IT

Alle Benutzer aus der Abteilung IT abrufen.

Eine GET-Anfrage besitzt normalerweise keinen Request-Body.

Mögliche Antwort:

{
  "id": 15,
  "name": "Max Mustermann",
  "department": "IT",
  "active": true
}

GET liest Daten und sollte keine Ressource verändern.

POST – Daten anlegen

POST wird häufig verwendet, um eine neue Ressource zu erstellen.

Beispiel:

POST /users

Request-Body:

{
  "name": "Max Mustermann",
  "department": "IT",
  "active": true
}

Mögliche Antwort:

Status: 201 Created

{
  "id": 15,
  "name": "Max Mustermann",
  "department": "IT",
  "active": true
}

Die ID wird häufig vom Server erzeugt.

POST erstellt normalerweise eine neue Ressource.

PUT – vollständig ersetzen

PUT wird verwendet, um eine bestehende Ressource vollständig zu ersetzen.

Beispiel:

PUT /users/15

Request-Body:

{
  "name": "Max Mustermann",
  "department": "Support",
  "active": true
}

Bei PUT erwartet die API häufig den vollständigen Datensatz.

Wird ein vorhandenes Feld nicht übertragen, kann es abhängig von der API entfernt oder auf einen Standardwert gesetzt werden.

Beispiel:

Der bisherige Benutzer besitzt zusätzlich eine Telefonnummer.

Wenn diese im PUT-Request fehlt, könnte sie verloren gehen.

PUT ersetzt normalerweise die vollständige Ressource.

PATCH – einzelne Werte ändern

PATCH wird verwendet, um nur bestimmte Felder einer Ressource zu verändern.

Beispiel:

PATCH /users/15

Request-Body:

{
  "department": "Support"
}

Nur die Abteilung wird geändert.

Andere Werte wie Name oder Aktivstatus bleiben erhalten.

PATCH verändert einzelne Teile einer Ressource.

PUT und PATCH im Vergleich

Merksatz:

PUT ersetzt vollständig. PATCH ändert teilweise.

DELETE – Daten löschen

DELETE wird verwendet, um eine Ressource zu entfernen.

Beispiel:

DELETE /users/15

Mögliche Antwort:

Status: 204 No Content

Der Statuscode 204 bedeutet, dass die Anfrage erfolgreich war, aber kein zusätzlicher Inhalt zurückgegeben wird.

In Unternehmenssystemen werden Benutzer häufig nicht endgültig gelöscht, sondern deaktiviert.

Beispiel:

PATCH /users/15

{
  "active": false
}

Das kann sinnvoll sein, wenn Daten oder Protokolle erhalten bleiben müssen.

DELETE entfernt eine Ressource. In der Praxis kann eine Deaktivierung sicherer sein.

CRUD

CRUD beschreibt vier grundlegende Datenoperationen.

CRUD bedeutet:

Zuordnung zu HTTP-Methoden:

Merksatz:

CRUD beschreibt die Datenoperation. Die HTTP-Methode beschreibt die technische Anfrage.

Beispiel: Benutzerverwaltung

Sammlungen und einzelne Ressourcen

Ein Endpoint ohne ID bezeichnet häufig eine Sammlung.

Beispiel:

/users

Bedeutung:

Sammlung aller Benutzer

Ein Endpoint mit ID bezeichnet eine einzelne Ressource.

Beispiel:

/users/15

Bedeutung:

einzelner Benutzer mit der ID 15

Typische Verwendung: