Klasse 11 · GK Informatik · Lernbereich 2 · Einheit 2

Von der Realität
zum Modell

Wie entsteht ein informatisches Modell? Welches Werkzeug für welche Aufgabe — und wo stoßen Modelle an ihre Grenzen?

Modellbildungsprozess Werkzeugwahl Ampel-Fallstudie ER-Schritt-für-Schritt Grenzen
01 · Prozess

Schrittfolge der Modellbildung

Die Erstellung eines informatischen Modells folgt einem strukturierten Prozess. Klicke einen Schritt an, um Details und ein durchgängiges Beispiel (Ampelsteuerung) zu sehen.

1 Problem­analyse
→
2 Abstraktion
→
3 Modell­konstruktion
→
4 Verifikation
→
5 Validierung
→
6 Einsatz & Pflege

⚠ Wichtig

Der Prozess ist iterativ, nicht linear. Fehler in der Verifikation führen zurück zur Konstruktion. Validierungsprobleme können sogar eine neue Problemanalyse erfordern. In der Praxis durchläuft man den Zyklus oft mehrmals.

02 · Werkzeugwahl

Welches Modell für welchen Zweck?

Die Wahl des richtigen Modellierungswerkzeugs hängt vom Modellierungsziel ab. Hier sind die vier zentralen Werkzeuge im Vergleich — und ein interaktiver Entscheidungsbaum.

Struktogramm
Einsatz
  • Algorithmen grafisch entwerfen
  • Sequenz, Auswahl, Schleifen darstellen
  • Sprachunabhängig — vor dem Coden
  • Unterricht & Prüfungen

Wann NICHT?

Nicht geeignet für
  • Datenstrukturen und -beziehungen
  • Systemzustände und Übergänge
  • Objektorientierte Klassen
  • Sehr lange, komplexe Algorithmen
Merksatz: Struktogramm = Algorithmus-Ablauf. Immer wenn es um „Wie läuft ein Programm ab?" geht.
ER-Diagramm
Einsatz
  • Datenbankstrukturen konzeptuell planen
  • Entitäten, Attribute, Beziehungen
  • Kardinalitäten (1:1, 1:n, m:n)
  • Kommunikation mit Nicht-Technikern

Wann NICHT?

Nicht geeignet für
  • Algorithmen und Programmabläufe
  • Systemverhalten und Zustände
  • Klassen und Methoden (OOP)
  • Prozessabläufe
Merksatz: ER-Diagramm = Datenstruktur. Immer wenn es um „Welche Daten werden gespeichert und wie hängen sie zusammen?" geht.
UML-Klassendiagramm
Einsatz
  • Objektorientierte Softwarestruktur
  • Klassen, Attribute, Methoden
  • Vererbung, Assoziation, Komposition
  • Softwarearchitektur planen

Wann NICHT?

Nicht geeignet für
  • Datenbankdesign (→ ER-Diagramm)
  • Algorithmische Abläufe
  • Systemverhalten / Zustände
  • Nicht-OOP-Programmierung
Merksatz: UML-Klassen = OOP-Struktur. Immer wenn es um „Welche Klassen hat mein Programm und wie hängen sie zusammen?" geht.
Zustandsdiagramm
Einsatz
  • Reaktive Systeme (Ampel, UI, Protokolle)
  • Alle möglichen Systemzustände
  • Übergangsbedingungen (Ereignisse)
  • Eingebettete Systeme

Wann NICHT?

Nicht geeignet für
  • Datenbankstrukturen
  • Algorithmen mit vielen Berechnungen
  • Klassenhierarchien (OOP)
  • Systeme ohne klar definierte Zustände
Merksatz: Zustandsdiagramm = Systemverhalten. Immer wenn es um „In welchem Zustand kann mein System sein und was löst einen Wechsel aus?" geht.
Flussdiagramm
Einsatz
  • Prozesse und Algorithmen dokumentieren
  • Entscheidungsabläufe mit Ja/Nein-Zweigen
  • Breiter Einsatz auch außerhalb der Informatik
  • Normierte Symbole (DIN 66001 / ISO 5807)

Wann NICHT?

Nicht geeignet für
  • Datenbankstrukturen (→ ER-Diagramm)
  • Klassenstrukturen / OOP (→ UML)
  • Systemzustände und Übergänge (→ Zustandsdiagramm)
  • Sehr komplexe, verschachtelte Algorithmen
Merksatz: Flussdiagramm = Prozessablauf. Immer wenn es um „Welche Schritte und Entscheidungen durchläuft ein Ablauf?" geht.
🔍 Entscheidungshilfe: Welches Werkzeug?
03 · Fallstudie

Schritt für Schritt: Ampelsteuerung

Wir modellieren eine Ampelsteuerung als Zustandsdiagramm — vom Problem bis zum fertigen Modell. Arbeite die 5 Schritte nacheinander durch.

04 · Fallstudie II

ER-Modell: Schülerverwaltung

Ausgangssituation: Eine Schule will eine Datenbank für Schüler, Klassen und Lehrer entwickeln. Erarbeite Schritt für Schritt das ER-Diagramm — jeder Schritt baut auf dem vorherigen auf.

05 · Kritisch denken

Grenzen der Modellbildung

Modelle sind mächtige Werkzeuge — aber sie haben Grenzen. Hier sind vier Bereiche, in denen Modelle regelmäßig versagen.

⚡ Komplexitäts­explosion

Manche Systeme sind so komplex, dass jedes Modell sie nur unzureichend abbildet.

Ab einer gewissen Systemgröße steigt die Anzahl möglicher Zustände und Interaktionen exponentiell. Ein Zustandsdiagramm für das gesamte Verhalten eines Betriebssystems wäre unbrauchbar — zu viele Zustände, zu viele Übergänge.

Lösung: Hierarchische Modellierung (Teilsysteme getrennt modellieren), Abstraktion erhöhen, Fokus auf den relevanten Bereich.

Beispiel: Ein Schachcomputer kann nicht alle 10^120 möglichen Spielverläufe modellieren — er nutzt Heuristiken.

↓ Details anzeigen

⏱ Zeitabhängigkeit

Modelle bilden einen Zeitpunkt ab — die Realität ändert sich ständig.

Ein ER-Diagramm, das heute korrekt ist, kann morgen veraltet sein, wenn sich die Anforderungen ändern. Datenbankschemata, Klassendiagramme und Protokolle müssen aktiv gepflegt werden.

Problem: Wenn das Modell und die Implementierung auseinanderdriften, verliert das Modell seinen Dokumentationswert — man kann ihm nicht mehr trauen.

Praxis: Versionierung von Modellen, Living Documentation, modellgetriebene Entwicklung (das Modell erzeugt den Code).

↓ Details anzeigen

📏 Messbarkeits­probleme

Nicht alles, was wichtig ist, lässt sich formal modellieren.

Modelle in der Informatik arbeiten mit formalen, messbaren Größen. Aber viele wichtige Aspekte eines Systems sind nicht formal erfassbar: Benutzerfreundlichkeit, ästhetische Qualität, Vertrauen, Akzeptanz.

Beispiel: Ein UML-Diagramm einer App sagt nichts darüber aus, ob Nutzer die App intuitiv finden werden. Ein ER-Schema sagt nichts über die Performance bei 1 Million gleichzeitigen Zugriffen.

Konsequenz: Modelle müssen durch Tests, Nutzerstudien und Messungen ergänzt werden.

↓ Details anzeigen

🧠 Menschliches Verhalten

Menschen verhalten sich nicht nach formalen Regeln — sie sind das größte Modellierungsproblem.

Informatische Modelle setzen oft voraus, dass Nutzer sich „korrekt" verhalten: alle Pflichtfelder ausfüllen, gültige Eingaben machen, Anweisungen folgen. In der Realität tun sie das nicht.

Beispiel: Ein Zustandsdiagramm für ein Login-System modelliert typischerweise „korrekte" Abläufe. Aber was passiert, wenn jemand 100 Mal falsch tippt? Das Passwort per Copy-Paste einfügt? Den Browser-Zurück-Button nutzt?

Lösung: Robustheitstests, Fehlerszenarien explizit modellieren, Nutzerforschung.

↓ Details anzeigen
06 · Aufgabe

Schritte in die richtige Reihenfolge

Bringe die Schritte des Modellbildungsprozesses in die korrekte Reihenfolge. Ziehe und drop die Elemente.

07 · Wissenstest

Quiz: Modellbildung & Werkzeuge

20 Fragen in 4 Schwierigkeitsstufen.

● Grundwissen (1–5)
● Verständnis (6–10)
● Anwendung (11–15)
● Kritisches Denken (16–20)
0 / 20
Punkte erreicht
08 · Glossar

Begriffe zum Aufdecken

Modellbildung
→ Klicken
Strukturierter Prozess der Erstellung eines Modells: Problemanalyse → Abstraktion → Konstruktion → Verifikation → Validierung → Einsatz.
Abstraktion
→ Klicken
Weglassen irrelevanter Details und Hervorheben der für den Modellzweck wesentlichen Eigenschaften des Originals.
Verifikation
→ Klicken
Prüfung: Wurde das Modell korrekt konstruiert? (Ist das Modell intern konsistent und fehlerfrei?) — „Bauen wir das System richtig?"
Validierung
→ Klicken
Prüfung: Ist das richtige Modell konstruiert worden? (Bildet das Modell das Original korrekt ab?) — „Bauen wir das richtige System?"
Iteration
→ Klicken
Der Modellbildungsprozess ist nicht linear, sondern iterativ: Fehler führen zum Rücksprung in frühere Phasen. Mehrere Durchläufe sind normal und erwünscht.
Transition
→ Klicken
Übergang zwischen zwei Zuständen in einem Zustandsdiagramm, ausgelöst durch ein Ereignis unter einer bestimmten Bedingung.
Kardinalität
→ Klicken
Anzahlbeziehung zwischen Entitäten im ER-Modell: 1:1, 1:n (ein zu viele), m:n (viele zu viele). Bestimmt die Tabellenstruktur in der Datenbank.
Modellierungswerkzeug
→ Klicken
Formalisierte Notation zur Erstellung von Modellen: z.B. UML, ER-Modell, Struktogramm, Zustandsdiagramm. Jedes Werkzeug ist für bestimmte Aspekte eines Systems optimiert.
„Ein Modell ist nur so gut wie die Fragen, für die es gebaut wurde."
Ihr habt heute Ampelsteuerung als Zustandsdiagramm modelliert. Welche Aspekte einer echten Ampel wurden bewusst weggelassen? War das richtig?
Verifikation vs. Validierung: Erklärt den Unterschied an einem selbst gewählten Beispiel aus dem Alltag.
Könnte man eine Schüler-Datenbank auch als UML-Klassendiagramm modellieren? Was wäre der Unterschied zum ER-Diagramm — und wann wäre welches besser?
Wo im Modellbildungsprozess passieren in der Praxis die meisten Fehler — und warum?
×