# 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** | Diagramm / Modell | Wofür wird es benutzt? | Typische Signalwörter in Aufgaben | |---|---|---| | **ERM** | Daten, Entitäten und Beziehungen darstellen | Entität, Attribut, Beziehung, Kardinalität, Kunde, Bestellung, Produkt | | **Relationales Datenbankmodell** | ERM in Tabellen mit Schlüsseln umwandeln | Tabelle, Primärschlüssel, Fremdschlüssel, Datensatz, Normalisierung | | **UML-Klassendiagramm** | Klassen, Attribute, Methoden und Beziehungen planen | Klasse, Attribut, Methode, Vererbung, Objekt, Assoziation | | **Mock-up** | Benutzeroberfläche grob entwerfen | Oberfläche, Eingabemaske, Button, Formular, Benutzerführung | | **UML-Aktivitätsdiagramm** | Abläufe, Entscheidungen und Schleifen darstellen | Ablauf, Prozess, Entscheidung, wenn/dann, Reihenfolge, Bedingung | | **UML-Anwendungsfalldiagramm** | Benutzerrollen und Systemfunktionen darstellen | Akteur, Benutzer, System, Funktion, Use Case, Anwendungsfall | | **UML-Sequenzdiagramm** | Kommunikation zwischen Objekten zeitlich darstellen | Nachricht, Aufruf, Objekt, Reihenfolge, Rückgabe, Kommunikation | | **UML-Zustandsdiagramm** | Zustände und Zustandswechsel darstellen | Zustand, Ereignis, Übergang, Trigger, Statuswechsel | --- **Merksatz** Wenn du eine Aufgabe liest, frage dich zuerst: | Frage | Wahrscheinlich passendes Diagramm | |---|---| | Geht es um **Daten und Beziehungen**? | ERM | | Geht es um **Tabellen und Schlüssel**? | Relationales Datenbankmodell | | Geht es um **Klassen im Programmcode**? | UML-Klassendiagramm | | Geht es um **eine Benutzeroberfläche**? | Mock-up | | Geht es um **einen Ablauf mit Entscheidungen**? | UML-Aktivitätsdiagramm | | Geht es um **Benutzer und Funktionen**? | UML-Anwendungsfalldiagramm | | Geht es um **Nachrichten zwischen Objekten**? | UML-Sequenzdiagramm | | Geht es um **Zustände eines Objekts**? | UML-Zustandsdiagramm | --- **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: | Wenn gefragt wird nach ... | Dann eher ... | |---|---| | Entitäten und Beziehungen | ERM | | Tabellen, Primärschlüssel, Fremdschlüssel | Relationales Datenbankmodell | --- **2. Aufgabe spricht von Programmstruktur?** Beispiele: - Klasse - Attribut - Methode - Objekt - Vererbung - Produktverwaltung - Java-Klassen Dann denke zuerst an: **UML-Klassendiagramm** Typisch für Java: ```text Produkt - marke - modell - preis + toString() # Seite 2. Gesamttrainer – Diagramm-Auswahl --- **Interaktiver Trainer** Mit diesem Trainer kannst du üben, welche Diagrammart zu welcher Aufgabenstellung passt.
Diagramm-Auswahl-Trainer im Vollbild öffnen
# 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** ![ERM – Grundlagen](https://trainer.ulrich-wiki.com/assets/erm-grundlagen.svg) 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: ```text 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: | Signalwort / Formulierung | Hinweis | |---|---| | Entität | Es geht um ein Datenobjekt | | Attribut | Es geht um Eigenschaften | | Beziehung | Es geht um Verknüpfungen zwischen Datenobjekten | | Kardinalität | Es geht um 1:1, 1:n oder n:m | | Kunde, Bestellung, Produkt | Typische Entitäten | | „kann mehrere haben“ | Hinweis auf 1:n oder n:m | | „gehört zu genau einem“ | Hinweis auf 1:n | | „Datenmodell erstellen“ | ERM oder relationales Modell | | „fachlich modellieren“ | Meist zuerst ERM | --- **Grundbausteine eines ERM** | Baustein | Bedeutung | Beispiel | |---|---|---| | **Entität** | Wichtiges Datenobjekt | Kunde, Produkt, Bestellung | | **Attribut** | Eigenschaft einer Entität | Name, Preis, Datum | | **Beziehung** | Verbindung zwischen Entitäten | Kunde gibt Bestellung auf | | **Kardinalität** | Anzahl-Beziehung | 1:1, 1:n, n:m | | **Primärschlüssel** | Eindeutige ID | kunden_id | | **Zwischentabelle** | Auflösung einer n:m-Beziehung | Bestellposition | --- **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: ```text Ein Kunde bestellt ein Produkt. ``` Mögliche Entitäten: ```text Kunde Produkt Bestellung ``` --- **Attribut** Ein **Attribut** ist eine Eigenschaft einer Entität. Beispiel Entität **Kunde**: | Attribut | Bedeutung | |---|---| | kunden_id | eindeutige Kundennummer | | vorname | Vorname | | nachname | Nachname | | email | E-Mail-Adresse | | telefon | Telefonnummer | Beispiel Entität **Produkt**: | Attribut | Bedeutung | |---|---| | produkt_id | eindeutige Produktnummer | | bezeichnung | Name des Produkts | | preis | Preis | | lagerbestand | Anzahl im Lager | Merksatz: **Attribute beschreiben eine Entität genauer.** --- **Primärschlüssel** Ein **Primärschlüssel** identifiziert jeden Datensatz eindeutig. Beispiele: ```text kunden_id produkt_id bestellung_id ``` Warum braucht man Primärschlüssel? Weil Namen nicht eindeutig sein müssen. Beispiel: ```text Es kann mehrere Kunden mit dem Namen Müller geben. ``` Aber: ```text 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: ```text Kunde gibt Bestellung auf ``` Entitäten: ```text Kunde Bestellung ``` Beziehung: ```text gibt auf ``` Darstellung als einfache Textform: ```text Kunde -- gibt auf -- Bestellung ``` Weitere Beispiele: | Beziehung | Bedeutung | |---|---| | Kunde gibt Bestellung auf | Kunde und Bestellung hängen zusammen | | Bestellung enthält Produkt | Eine Bestellung besteht aus Produkten | | Mitarbeiter arbeitet in Abteilung | Mitarbeiter ist einer Abteilung zugeordnet | | Schüler belegt Kurs | Schüler nimmt an einem Kurs teil | --- **Kardinalität** Die **Kardinalität** beschreibt, wie viele Datensätze miteinander verbunden sein können. Die wichtigsten Kardinalitäten: | Kardinalität | Bedeutung | Beispiel | |---|---|---| | **1:1** | Genau ein Datensatz gehört zu genau einem anderen | Person hat Personalausweis | | **1:n** | Ein Datensatz kann mehrere andere Datensätze haben | Kunde hat mehrere Bestellungen | | **n:m** | Viele Datensätze können mit vielen anderen verbunden sein | Schüler belegen Kurse | --- **Grafik 2: ERM-Beispiel mit Kunde, Bestellung, Produkt und Bestellposition** ![ERM – Kunde Bestellung Produkt](https://trainer.ulrich-wiki.com/assets/erm-beispiel-bestellung.svg) 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: ```text Eine Person hat genau einen Personalausweis. Ein Personalausweis gehört genau zu einer Person. ``` Darstellung: ```text Person 1 --- 1 Personalausweis ``` Das ist eine **1:1-Beziehung**. --- **1:n-Beziehung** Beispiel: ```text Ein Kunde kann mehrere Bestellungen haben. Eine Bestellung gehört genau zu einem Kunden. ``` Darstellung: ```text 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: ```text Eine Bestellung kann mehrere Produkte enthalten. Ein Produkt kann in mehreren Bestellungen vorkommen. ``` Darstellung: ```text 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: ```text Bestellung Produkt Bestellposition ``` Die Zwischentabelle könnte heißen: ```text Bestellposition ``` Typische Attribute der Zwischentabelle: | Attribut | Bedeutung | |---|---| | bestellung_id | Verweis auf Bestellung | | produkt_id | Verweis auf Produkt | | menge | Wie oft wurde das Produkt bestellt? | | einzelpreis | Preis zum Zeitpunkt der Bestellung | --- **ERM-Beispiel: Kunde, Bestellung, Produkt** Fachliche Beschreibung: ```text 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: | Entität | Mögliche Attribute | |---|---| | Kunde | kunden_id, name, email | | Bestellung | bestellung_id, bestelldatum | | Produkt | produkt_id, bezeichnung, preis | | Bestellposition | bestellung_id, produkt_id, menge | Beziehungen: | Beziehung | Kardinalität | |---|---| | Kunde zu Bestellung | 1:n | | Bestellung zu Produkt | n:m | | Bestellung zu Bestellposition | 1:n | | Produkt zu Bestellposition | 1:n | Das n:m zwischen Bestellung und Produkt wird durch **Bestellposition** aufgelöst. --- **ERM vs. relationales Datenbankmodell** | ERM | Relationales Datenbankmodell | |---|---| | Fachliches Modell | Technischeres Tabellenmodell | | Zeigt Entitäten | Zeigt Tabellen | | Zeigt Beziehungen | Zeigt Primär- und Fremdschlüssel | | Nutzt Kardinalitäten | Nutzt Schlüsselbeziehungen | | Vorstufe zur Datenbank | Grundlage für echte Tabellenstruktur | 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: | Schritt | Frage | |---|---| | 1 | Welche Hauptwörter sind wichtig? | | 2 | Welche davon sind Entitäten? | | 3 | Welche Eigenschaften haben diese Entitäten? | | 4 | Welche Entität braucht welchen Primärschlüssel? | | 5 | Welche Entitäten stehen in Beziehung? | | 6 | Welche Kardinalität hat die Beziehung? | | 7 | Gibt es eine n:m-Beziehung? | | 8 | Muss eine Zwischentabelle entstehen? | --- **Typische IHK-Fehler beim ERM** | Fehler | Warum falsch? | |---|---| | Attribute als Entität darstellen | Nicht jede Eigenschaft ist eine eigene Entität | | n:m nicht auflösen | In Tabellen braucht man später eine Zwischentabelle | | Primärschlüssel vergessen | Jeder Datensatz muss eindeutig identifizierbar sein | | Kardinalitäten vertauschen | Die Beziehung wird fachlich falsch | | Beziehung zu technisch denken | ERM ist zuerst fachlich, nicht direkt SQL | | Fremdschlüssel schon zu früh überbewerten | Im ERM geht es zuerst um Entitäten und Beziehungen | --- **Prüfungs-Merksätze** ```text 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**
1. Was bedeutet ERM? **Entity-Relationship-Modell** Auf Deutsch: Entitäten-Beziehungs-Modell.
2. Wofür wird ein ERM verwendet? Ein ERM wird verwendet, um Datenobjekte, deren Eigenschaften und deren Beziehungen fachlich zu modellieren.
3. Was ist eine Entität? Eine Entität ist ein wichtiges Datenobjekt, über das Informationen gespeichert werden sollen. Beispiele: - Kunde - Bestellung - Produkt - Mitarbeiter
4. Was ist ein Attribut? Ein Attribut ist eine Eigenschaft einer Entität. Beispiel: ```text Kunde - kunden_id - name - email ```
5. Was ist eine n:m-Beziehung? Viele Datensätze der einen Entität können mit vielen Datensätzen der anderen Entität verbunden sein. Beispiel: ```text Eine Bestellung kann mehrere Produkte enthalten. Ein Produkt kann in mehreren Bestellungen vorkommen. ```
6. Was muss man bei einer n:m-Beziehung später machen? Man löst sie meistens über eine Zwischentabelle auf. Beispiel: ```text Bestellung n:m Produkt ``` wird zu: ```text Bestellung 1:n Bestellposition n:1 Produkt ```
--- **Nächste Seite** Danach kommt die eigene Trainer-Seite: ```text ERM-Trainer ``` Dort bauen wir den interaktiven ERM-Trainer mit Aufgaben zu: ```text 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: ```text ERM – Entity-Relationship-Modell ``` Hier übst du, aus kurzen Aufgabenstellungen die wichtigsten Bestandteile eines ERM zu erkennen: ```text Entität 1 Entität 2 Beziehung Kardinalität Zwischentabelle bei n:m-Beziehungen ``` --- **Was wird trainiert?** | Bereich | Bedeutung | |---|---| | **Entität erkennen** | wichtige Datenobjekte aus dem Text finden | | **Beziehung erkennen** | passende Verbindung zwischen den Entitäten formulieren | | **Kardinalität bestimmen** | 1:1, 1:n, n:1 oder n:m auswählen | | **Zwischentabelle erkennen** | bei n:m-Beziehungen eine passende Zwischentabelle nennen | | **Typische IHK-Formulierungen verstehen** | aus Textaufgaben das Datenmodell ableiten | --- **Interaktiver ERM-Trainer**
ERM-Trainer im Vollbild öffnen
--- **Merksatz für den Trainer** ```text 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: ```text Ein Schüler kann mehrere Kurse belegen. Ein Kurs kann von mehreren Schülern belegt werden. ``` Lösung: | Feld | Lösung | |---|---| | Entität 1 | Schüler | | Entität 2 | Kurs | | Beziehung | belegt | | Kardinalität | n:m | | Zwischentabelle | Belegung | Warum? ```text 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**
1. Was musst du im ERM-Trainer zuerst aus der Aufgabenstellung erkennen? Zuerst musst du die wichtigsten **Entitäten** erkennen. Entitäten sind meistens wichtige Hauptwörter aus der Aufgabenstellung. Beispiel: ```text Ein Kunde kann mehrere Bestellungen aufgeben. ``` Mögliche Entitäten: ```text Kunde Bestellung ```
2. Wann liegt meistens eine 1:n-Beziehung vor? Wenn ein Datensatz der einen Entität mit mehreren Datensätzen der anderen Entität verbunden sein kann. Beispiel: ```text Ein Kunde kann mehrere Bestellungen haben. Eine Bestellung gehört genau zu einem Kunden. ``` Das ist: ```text Kunde 1:n Bestellung ```
3. Wann liegt meistens eine n:m-Beziehung vor? Wenn viele Datensätze der einen Entität mit vielen Datensätzen der anderen Entität verbunden sein können. Beispiel: ```text Ein Schüler kann mehrere Kurse belegen. Ein Kurs kann von mehreren Schülern belegt werden. ``` Das ist: ```text Schüler n:m Kurs ```
4. Was passiert bei einer n:m-Beziehung später meistens? Die n:m-Beziehung wird durch eine **Zwischentabelle** aufgelöst. Beispiel: ```text Schüler n:m Kurs ``` wird zu: ```text Schüler 1:n Belegung n:1 Kurs ```
5. Warum ist die Zwischentabelle wichtig? Weil eine n:m-Beziehung in einer relationalen Datenbank nicht einfach direkt gespeichert wird. Die Zwischentabelle speichert die Verbindung zwischen beiden Entitäten. Beispiel: ```text Belegung - schueler_id - kurs_id - anmeldedatum ```
--- **Nächste Seite** Danach geht es weiter mit: ```text 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: ```text Tabellen Datensätze Attribute / Spalten Primärschlüssel Fremdschlüssel Beziehungen zwischen Tabellen ``` --- **Grafik 1: Grundlagen des relationalen Datenbankmodells** ![Relationales Datenbankmodell – Grundlagen](https://trainer.ulrich-wiki.com/assets/relationales-modell-grundlagen.svg) 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: ```text Kunde gibt Bestellung auf ``` Das relationale Modell macht daraus Tabellen: ```text Kunde Bestellung ``` Und legt fest: ```text 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: | Signalwort / Formulierung | Hinweis | |---|---| | Tabelle | Daten sollen tabellarisch dargestellt werden | | Datensatz | Es geht um Zeilen in einer Tabelle | | Attribut / Spalte | Es geht um Felder einer Tabelle | | Primärschlüssel | Eindeutige Kennzeichnung eines Datensatzes | | Fremdschlüssel | Verweis auf eine andere Tabelle | | Relation | Tabelle oder Beziehung zwischen Tabellen | | Normalisierung | Tabellen sollen sauber strukturiert werden | | n:m auflösen | Zwischentabelle wird benötigt | | ERM in Tabellen überführen | Relationales Modell ist gemeint | --- **Grundbegriffe** | Begriff | Bedeutung | Beispiel | |---|---|---| | **Tabelle** | Sammlung gleichartiger Datensätze | Kunde, Bestellung, Produkt | | **Datensatz** | Eine Zeile in einer Tabelle | ein bestimmter Kunde | | **Attribut / Spalte** | Eigenschaft eines Datensatzes | name, email, preis | | **Primärschlüssel** | eindeutige ID einer Tabelle | kunden_id | | **Fremdschlüssel** | Verweis auf Primärschlüssel einer anderen Tabelle | kunden_id in Bestellung | | **Relation** | Tabelle oder Beziehung zwischen Tabellen | Kunde 1:n Bestellung | --- **Tabelle** Eine Tabelle speichert gleichartige Daten. Beispiel Tabelle **Kunde**: | kunden_id | name | email | |---|---|---| | 1 | Müller | mueller@example.de | | 2 | Schmidt | schmidt@example.de | Die Tabelle hat: - Spalten - Zeilen - Datensätze - einen Primärschlüssel --- **Datensatz** Ein Datensatz ist eine einzelne Zeile in einer Tabelle. Beispiel: | kunden_id | name | email | |---|---|---| | 1 | Müller | mueller@example.de | 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**: ```text 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: ```text kunden_id produkt_id bestellung_id ``` Warum ist das wichtig? Namen sind nicht eindeutig. Beispiel: ```text Müller ``` kann mehrfach vorkommen. Aber: ```text 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**: | kunden_id | name | |---|---| | 1 | Müller | | 2 | Schmidt | Tabelle **Bestellung**: | bestellung_id | bestelldatum | kunden_id | |---|---|---| | 101 | 01.02.2026 | 1 | | 102 | 03.02.2026 | 1 | Hier ist: ```text kunden_id ``` in der Tabelle **Bestellung** ein Fremdschlüssel. Warum? Weil er auf die Tabelle **Kunde** verweist. ```text Bestellung.kunden_id → Kunde.kunden_id ``` --- **Grafik 2: Vom ERM zum relationalen Modell** ![Vom ERM zum relationalen Modell](https://trainer.ulrich-wiki.com/assets/relationales-modell-erm-zu-tabellen.svg) 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** | ERM | Relationales Datenbankmodell | |---|---| | fachliches Modell | tabellarisches Modell | | zeigt Entitäten | zeigt Tabellen | | zeigt Attribute | zeigt Spalten | | zeigt Beziehungen | zeigt Fremdschlüssel | | zeigt Kardinalitäten | zeigt Schlüsselbeziehungen | | eher Planung | näher an Datenbank / SQL | Merksatz: ```text ERM = Was gibt es fachlich? Relationales Modell = Wie wird es tabellarisch gespeichert? ``` --- **Aus Entitäten werden Tabellen** Im ERM hast du zum Beispiel: ```text Kunde Bestellung Produkt ``` Im relationalen Modell werden daraus Tabellen: ```text Tabelle Kunde Tabelle Bestellung Tabelle Produkt ``` Beispiel: ```text Entität Kunde ``` wird zu: ```text Kunde(kunden_id, name, email) ``` --- **Aus Attributen werden Spalten** ERM: ```text Kunde - kunden_id - name - email ``` Relationales Modell: | kunden_id | name | email | |---|---|---| Merksatz: **Attribute werden im relationalen Modell zu Spalten.** --- **1:1-Beziehung im relationalen Modell** Beispiel: ```text Person 1 --- 1 Personalausweis ``` Mögliche Tabellen: ```text 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: ```text Kunde 1 --- n Bestellung ``` Das bedeutet: ```text Ein Kunde kann mehrere Bestellungen haben. Eine Bestellung gehört genau zu einem Kunden. ``` Tabellen: ```text Kunde(kunden_id, name, email) Bestellung(bestellung_id, bestelldatum, kunden_id) ``` Wichtig: Der Fremdschlüssel kommt auf die **n-Seite**. Also: ```text kunden_id ``` steht in: ```text Bestellung ``` Merksatz: **Bei 1:n steht der Fremdschlüssel auf der n-Seite.** --- **n:m-Beziehung im relationalen Modell** Beispiel: ```text Bestellung n --- m Produkt ``` Das bedeutet: ```text 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: ```text Bestellung n:m Produkt ``` wird: ```text Bestellung 1:n Bestellposition n:1 Produkt ``` Tabellen: ```text Bestellung(bestellung_id, bestelldatum) Produkt(produkt_id, bezeichnung, preis) Bestellposition(bestellung_id, produkt_id, menge) ``` Die Tabelle **Bestellposition** enthält mindestens: | Spalte | Bedeutung | |---|---| | bestellung_id | Fremdschlüssel auf Bestellung | | produkt_id | Fremdschlüssel auf Produkt | | menge | Zusatzinformation zur Beziehung | --- **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: ```text 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: ```text Bestellposition ``` --- **Typische Umwandlung von ERM zu relationalem Modell** | ERM | Relationales Modell | |---|---| | Entität | Tabelle | | Attribut | Spalte | | Primärschlüssel | Primärschlüssel | | 1:n-Beziehung | Fremdschlüssel auf n-Seite | | n:m-Beziehung | Zwischentabelle | | Kardinalität | Schlüsselbeziehung | --- **Beispiel: Kunde und Bestellung** Fachliche Beschreibung: ```text Ein Kunde kann mehrere Bestellungen aufgeben. Eine Bestellung gehört genau zu einem Kunden. ``` ERM: ```text Kunde 1 --- n Bestellung ``` Relationales Modell: ```text Kunde(kunden_id, name, email) Bestellung(bestellung_id, bestelldatum, kunden_id) ``` Erklärung: ```text kunden_id ist Primärschlüssel in Kunde. kunden_id ist Fremdschlüssel in Bestellung. ``` --- **Beispiel: Schüler und Kurs** Fachliche Beschreibung: ```text Ein Schüler kann mehrere Kurse belegen. Ein Kurs kann von mehreren Schülern belegt werden. ``` ERM: ```text Schüler n --- m Kurs ``` Relationales Modell: ```text Schüler(schueler_id, vorname, nachname) Kurs(kurs_id, kursname) Belegung(schueler_id, kurs_id, anmeldedatum) ``` Erklärung: ```text 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: ```text PK = Primary Key = Primärschlüssel FK = Foreign Key = Fremdschlüssel ``` Beispiel: ```text Kunde( kunden_id PK, name, email ) Bestellung( bestellung_id PK, bestelldatum, kunden_id FK ) ``` Oder kompakt: ```text 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: ```text Belegung(schueler_id, kurs_id, anmeldedatum) ``` Hier könnten zusammen den Datensatz eindeutig machen: ```text schueler_id + kurs_id ``` Das nennt man einen **zusammengesetzten Primärschlüssel**. Alternative: Man kann auch eine eigene ID verwenden: ```text belegung_id ``` Dann sieht die Tabelle so aus: ```text Belegung(belegung_id PK, schueler_id FK, kurs_id FK, anmeldedatum) ``` Beides kann je nach Aufgabenstellung sinnvoll sein. --- **Normalisierung kurz erklärt** Normalisierung bedeutet: ```text Daten so strukturieren, dass Wiederholungen und Fehler vermieden werden. ``` Einfach gesagt: ```text Gleiche Informationen sollen nicht unnötig mehrfach gespeichert werden. ``` Schlechtes Beispiel: | bestellung_id | kundenname | kundenemail | produkt | |---|---|---|---| | 1 | Müller | mueller@example.de | Monitor | | 2 | Müller | mueller@example.de | Tastatur | Problem: ```text Kundendaten werden mehrfach gespeichert. ``` Besser: ```text 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: | Schritt | Frage | |---|---| | 1 | Welche Entitäten gibt es? | | 2 | Welche Tabellen entstehen daraus? | | 3 | Welche Attribute werden zu Spalten? | | 4 | Was ist der Primärschlüssel jeder Tabelle? | | 5 | Gibt es eine 1:n-Beziehung? | | 6 | Wo muss der Fremdschlüssel stehen? | | 7 | Gibt es eine n:m-Beziehung? | | 8 | Welche Zwischentabelle wird benötigt? | | 9 | Welche Zusatzattribute gehören in die Zwischentabelle? | --- **Typische IHK-Fehler** | Fehler | Warum problematisch? | |---|---| | Primärschlüssel vergessen | Datensätze sind nicht eindeutig erkennbar | | Fremdschlüssel auf falscher Seite | Beziehung wird falsch abgebildet | | n:m ohne Zwischentabelle | Relational unsauber | | Attribute doppelt speichern | führt zu Redundanz | | Entität und Attribut verwechseln | falsche Tabellenstruktur | | Zwischentabelle ohne Fremdschlüssel | Verbindung zwischen Tabellen fehlt | | Kardinalität nicht beachtet | falsche Modellierung | --- **Prüfungs-Merksätze** ```text 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: ```text Ein Kunde kann mehrere Bestellungen haben. Eine Bestellung gehört genau zu einem Kunden. ``` Lösung: ```text Kunde(kunden_id PK, name, email) Bestellung(bestellung_id PK, bestelldatum, kunden_id FK) ``` Begründung: ```text 1:n-Beziehung. Der Fremdschlüssel kunden_id steht auf der n-Seite, also in Bestellung. ``` --- **Mini-Beispiel 2** Aufgabe: ```text Ein Schüler kann mehrere Kurse belegen. Ein Kurs kann von mehreren Schülern belegt werden. ``` Lösung: ```text Schüler(schueler_id PK, vorname, nachname) Kurs(kurs_id PK, kursname) Belegung(schueler_id FK, kurs_id FK, anmeldedatum) ``` Begründung: ```text n:m-Beziehung. Deshalb braucht man eine Zwischentabelle. ``` --- **Mini-Beispiel 3** Aufgabe: ```text Eine Bestellung kann mehrere Produkte enthalten. Ein Produkt kann in mehreren Bestellungen vorkommen. ``` Lösung: ```text Bestellung(bestellung_id PK, bestelldatum) Produkt(produkt_id PK, bezeichnung, preis) Bestellposition(bestellung_id FK, produkt_id FK, menge) ``` Begründung: ```text n:m-Beziehung. Bestellposition löst die Beziehung auf und speichert zusätzlich die Menge. ``` --- **Mini-Testfragen**
1. Was ist eine Tabelle? Eine Tabelle speichert gleichartige Datensätze. Beispiel: ```text Kunde Produkt Bestellung ```
2. Was ist ein Datensatz? Ein Datensatz ist eine einzelne Zeile in einer Tabelle. Beispiel: ```text kunden_id = 1, name = Müller, email = mueller@example.de ```
3. Was ist ein Primärschlüssel? Ein Primärschlüssel identifiziert jeden Datensatz eindeutig. Beispiel: ```text kunden_id produkt_id bestellung_id ```
4. Was ist ein Fremdschlüssel? Ein Fremdschlüssel verweist auf den Primärschlüssel einer anderen Tabelle. Beispiel: ```text Bestellung.kunden_id verweist auf Kunde.kunden_id ```
5. Wo steht der Fremdschlüssel bei einer 1:n-Beziehung? Der Fremdschlüssel steht auf der **n-Seite**. Beispiel: ```text Kunde 1:n Bestellung ``` Dann steht: ```text kunden_id ``` in der Tabelle: ```text Bestellung ```
6. Was braucht man bei einer n:m-Beziehung? Eine n:m-Beziehung braucht eine **Zwischentabelle**. Beispiel: ```text Schüler n:m Kurs ``` wird zu: ```text Schüler 1:n Belegung n:1 Kurs ```
7. Warum ist eine Zwischentabelle bei Bestellung und Produkt sinnvoll? Weil eine Bestellung mehrere Produkte enthalten kann und ein Produkt in mehreren Bestellungen vorkommen kann. Außerdem können Zusatzinformationen gespeichert werden: ```text menge einzelpreis rabatt ``` Diese gehören zur Verbindung zwischen Bestellung und Produkt.
8. Was bedeutet Normalisierung ganz einfach? Normalisierung bedeutet, Daten so zu strukturieren, dass unnötige Wiederholungen und Fehler vermieden werden. Merksatz: ```text Informationen möglichst nur einmal speichern. ```
--- **Nächste Seite** Danach kommt die eigene Trainer-Seite: ```text Relationales-Datenbankmodell-Trainer ``` Dort bauen wir den interaktiven Trainer mit Aufgaben zu: ```text 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: ```text Relationales Datenbankmodell ``` Hier übst du, aus kurzen Aufgabenstellungen ein relationales Datenbankmodell abzuleiten. Im Fokus stehen: ```text Tabellen Primärschlüssel Fremdschlüssel 1:n-Beziehungen n:m-Beziehungen Zwischentabellen ``` --- **Was wird trainiert?** | Bereich | Bedeutung | |---|---| | **Tabellen ableiten** | Entitäten aus dem ERM werden Tabellen | | **Primärschlüssel bestimmen** | Jede Tabelle braucht eine eindeutige ID | | **Fremdschlüssel platzieren** | Bei 1:n steht der Fremdschlüssel auf der n-Seite | | **Beziehungen erkennen** | 1:1, 1:n, n:1 oder n:m | | **Zwischentabelle erkennen** | n:m-Beziehungen werden über eine Zwischentabelle gelöst | | **IHK-typische Aufgaben lösen** | Fachliche Beschreibung in Tabellenstruktur umwandeln | --- **Interaktiver Relationales-Datenbankmodell-Trainer**
Relationales-Datenbankmodell-Trainer im Vollbild öffnen
--- **Merksatz für den Trainer** ```text 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: ```text Ein Kunde kann mehrere Bestellungen aufgeben. Eine Bestellung gehört genau zu einem Kunden. ``` Relationales Modell: ```text Kunde(kunden_id PK, name, email) Bestellung(bestellung_id PK, bestelldatum, kunden_id FK) ``` Warum? ```text Kunde 1:n Bestellung ``` Der Fremdschlüssel steht auf der n-Seite. Also steht: ```text kunden_id ``` in der Tabelle: ```text Bestellung ``` --- **Beispiel 2: n:m-Beziehung** Aufgabenstellung: ```text Ein Schüler kann mehrere Kurse belegen. Ein Kurs kann von mehreren Schülern belegt werden. ``` Relationales Modell: ```text Schüler(schueler_id PK, vorname, nachname) Kurs(kurs_id PK, kursname) Belegung(schueler_id FK, kurs_id FK, anmeldedatum) ``` Warum? ```text Schüler n:m Kurs ``` Eine n:m-Beziehung braucht eine Zwischentabelle. Hier heißt sie: ```text Belegung ``` --- **Beispiel 3: Bestellung und Produkt** Aufgabenstellung: ```text Eine Bestellung kann mehrere Produkte enthalten. Ein Produkt kann in mehreren Bestellungen vorkommen. ``` Relationales Modell: ```text Bestellung(bestellung_id PK, bestelldatum) Produkt(produkt_id PK, bezeichnung, preis) Bestellposition(bestellung_id FK, produkt_id FK, menge) ``` Warum? ```text Bestellung n:m Produkt ``` Die Zwischentabelle **Bestellposition** löst die n:m-Beziehung auf. Zusätzlich kann dort gespeichert werden: ```text menge einzelpreis rabatt ``` --- **Typische Fehler im Trainer** | Fehler | Warum falsch? | |---|---| | Fremdschlüssel auf der falschen Seite | Bei 1:n muss der FK auf die n-Seite | | n:m ohne Zwischentabelle | n:m braucht im relationalen Modell eine eigene Tabelle | | Primärschlüssel vergessen | Datensätze sind nicht eindeutig | | Zwischentabelle ohne beide Fremdschlüssel | Verbindung ist nicht vollständig | | Attribute doppelt speichern | führt zu Redundanz | | Tabelle und Entität verwechseln | ERM ist fachlich, relationales Modell ist tabellarisch | --- **Mini-Testfragen**
1. Was wird aus einer Entität im relationalen Modell? Aus einer Entität wird meistens eine **Tabelle**. Beispiel: ```text Entität Kunde ``` wird zu: ```text Tabelle Kunde ```
2. Was wird aus einem Attribut im relationalen Modell? Aus einem Attribut wird meistens eine **Spalte**. Beispiel: ```text Attribut name ``` wird zu: ```text Spalte name ```
3. Was ist ein Primärschlüssel? Ein Primärschlüssel identifiziert jeden Datensatz eindeutig. Beispiel: ```text kunden_id produkt_id bestellung_id ```
4. Was ist ein Fremdschlüssel? Ein Fremdschlüssel verweist auf den Primärschlüssel einer anderen Tabelle. Beispiel: ```text Bestellung.kunden_id verweist auf Kunde.kunden_id ```
5. Wo steht der Fremdschlüssel bei einer 1:n-Beziehung? Der Fremdschlüssel steht auf der **n-Seite**. Beispiel: ```text Kunde 1:n Bestellung ``` Dann steht: ```text kunden_id ``` in der Tabelle: ```text Bestellung ```
6. Was braucht man bei einer n:m-Beziehung? Eine n:m-Beziehung braucht eine **Zwischentabelle**. Beispiel: ```text Schüler n:m Kurs ``` wird zu: ```text Schüler 1:n Belegung n:1 Kurs ```
7. Welche Fremdschlüssel enthält die Zwischentabelle bei Schüler und Kurs? Die Zwischentabelle enthält mindestens: ```text schueler_id FK kurs_id FK ``` Beispiel: ```text Belegung(schueler_id FK, kurs_id FK, anmeldedatum) ```
8. Warum ist Bestellposition eine sinnvolle Zwischentabelle? Weil eine Bestellung mehrere Produkte enthalten kann und ein Produkt in mehreren Bestellungen vorkommen kann. Außerdem kann die Tabelle **Bestellposition** Zusatzinformationen speichern: ```text menge einzelpreis rabatt ```
9. Was ist ein zusammengesetzter Primärschlüssel? Ein zusammengesetzter Primärschlüssel besteht aus mehreren Spalten. Beispiel: ```text Belegung(schueler_id, kurs_id) ``` Zusammen können beide Werte einen Datensatz eindeutig machen.
10. Was ist der häufigste Fehler bei n:m-Beziehungen? Der häufigste Fehler ist, keine Zwischentabelle zu erstellen. Falsch: ```text Schüler n:m Kurs direkt speichern ``` Besser: ```text Schüler 1:n Belegung n:1 Kurs ```
--- **Nächste Seite** Danach geht es weiter mit: ```text 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: ```text Klassen Attribute Methoden Sichtbarkeit Beziehungen zwischen Klassen Vererbung ``` --- **Grafik 1: UML-Klassendiagramm – Grundlagen** ![UML-Klassendiagramm – Grundlagen](https://trainer.ulrich-wiki.com/assets/uml-klassendiagramm-grundlagen.svg?v=3) 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: ```text 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: | Signalwort / Formulierung | Hinweis | |---|---| | Klasse | Es geht um OOP / Programmstruktur | | Attribut | Eigenschaft einer Klasse | | Methode | Funktion / Verhalten einer Klasse | | Objekt | konkrete Instanz einer Klasse | | Vererbung | Oberklasse / Unterklasse | | Assoziation | Beziehung zwischen Klassen | | Java-Klassen | meist UML-Klassendiagramm | | „modellieren Sie die Klassenstruktur“ | Klassendiagramm | | „stellen Sie Attribute und Methoden dar“ | Klassendiagramm | --- **Aufbau einer Klasse** Eine Klasse wird im UML-Klassendiagramm meistens als Rechteck mit drei Bereichen dargestellt: ```text ┌────────────────────────┐ │ Klassenname │ ├────────────────────────┤ │ Attribute │ ├────────────────────────┤ │ Methoden │ └────────────────────────┘ ``` Beispiel: ```text ┌────────────────────────┐ │ Produkt │ ├────────────────────────┤ │ - marke: String │ │ - modell: String │ │ - preis: double │ ├────────────────────────┤ │ + getPreis(): double │ │ + toString(): String │ └────────────────────────┘ ``` --- **Klassenname** Der Klassenname steht oben im Klassendiagramm. Beispiele: ```text Produkt Monitor Tastatur Kunde Bestellung Benutzer ``` Merksatz: **Klassennamen werden meistens großgeschrieben und stehen im Singular.** Also eher: ```text Produkt ``` nicht: ```text Produkte ``` --- **Attribute** Attribute beschreiben die Eigenschaften einer Klasse. Beispiel Klasse **Produkt**: ```text - marke: String - modell: String - preis: double ``` Das bedeutet: | Attribut | Datentyp | Bedeutung | |---|---|---| | marke | String | Marke des Produkts | | modell | String | Modellbezeichnung | | preis | double | Preis | Merksatz: **Attribute sind das, was ein Objekt speichert.** --- **Methoden** Methoden beschreiben, was ein Objekt tun kann. Beispiel: ```text + getPreis(): double + setPreis(preis: double): void + toString(): String ``` Aufbau einer Methode: ```text sichtbarkeit methodenname(parameter): rückgabetyp ``` Beispiel: ```text + setPreis(preis: double): void ``` Bedeutung: | Teil | Bedeutung | |---|---| | `+` | public | | `setPreis` | Methodenname | | `preis: double` | Parameter | | `void` | kein Rückgabewert | --- **Sichtbarkeit** Die Sichtbarkeit zeigt, von wo aus auf Attribute oder Methoden zugegriffen werden darf. | Zeichen | Bedeutung | Erklärung | |---|---|---| | `+` | public | öffentlich zugreifbar | | `-` | private | nur innerhalb der Klasse | | `#` | protected | Klasse und Unterklassen | | `~` | package | innerhalb des Pakets | Für IHK und Java-Grundlagen sind besonders wichtig: ```text + public - private # protected ``` Typisch in Java: ```text private String marke; public String toString() ``` UML: ```text - marke: String + toString(): String ``` --- **Attribute sind meistens private** In Java sind Attribute meistens private. Beispiel Java: ```java private String marke; private String modell; private double preis; ``` UML: ```text - 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: ```java public String toString() { return marke + " " + modell; } ``` UML: ```text + toString(): String ``` --- **Grafik 2: Beispiel Produktverwaltung** ![UML-Klassendiagramm – Beispiel Produktverwaltung](https://trainer.ulrich-wiki.com/assets/uml-klassendiagramm-beispiel-produktverwaltung.svg) 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: ```text Produkt - marke - modell - preis ``` Diese Attribute können für viele Produktarten gelten: ```text Monitor Tastatur Maus CPU ``` Deshalb gehören sie in die gemeinsame Oberklasse **Produkt**. --- **Vererbung** Vererbung bedeutet: ```text Eine Unterklasse übernimmt Eigenschaften und Methoden einer Oberklasse. ``` Beispiel: ```text Monitor erbt von Produkt. Tastatur erbt von Produkt. ``` Das bedeutet: ```text Monitor ist ein Produkt. Tastatur ist ein Produkt. ``` UML-Darstellung: ```text Monitor ─────▷ Produkt Tastatur ────▷ Produkt ``` Der Pfeil zeigt zur **Oberklasse**. Merksatz: **Der Vererbungs-Pfeil zeigt immer zur allgemeineren Klasse.** --- **Oberklasse und Unterklasse** | Begriff | Bedeutung | Beispiel | |---|---|---| | Oberklasse | allgemeine Klasse | Produkt | | Unterklasse | spezielle Klasse | Monitor | | Vererbung | Unterklasse übernimmt von Oberklasse | Monitor erbt von Produkt | Beispiel: ```text Produkt - marke - modell - preis Monitor - groesseZoll - aufloesung ``` Der Monitor hat dann fachlich: ```text marke modell preis groesseZoll aufloesung ``` --- **Assoziation** Eine Assoziation ist eine normale Beziehung zwischen Klassen. Beispiel: ```text Kunde gibt Bestellung auf ``` Als Klassendiagramm: ```text Kunde ───────── Bestellung ``` Eine Assoziation bedeutet: ```text Diese Klassen stehen miteinander in Beziehung. ``` --- **Multiplizität** Die Multiplizität zeigt, wie viele Objekte miteinander verbunden sein können. | Multiplizität | Bedeutung | |---|---| | `1` | genau eins | | `0..1` | kein oder eins | | `*` | beliebig viele | | `1..*` | mindestens eins | | `0..*` | beliebig viele oder keine | Beispiel: ```text Kunde 1 ───── 0..* Bestellung ``` Bedeutung: ```text 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: ```text 1:n n:m ``` Im UML-Klassendiagramm sieht man eher: ```text 1 0..* 1..* * ``` Beispiel: ```text Kunde 1 ───── 0..* Bestellung ``` entspricht ungefähr: ```text 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. | Beziehung | Symbol | Bedeutung | |---|---|---| | Aggregation | leere Raute | Teil-Ganzes-Beziehung, Teil kann auch ohne Ganzes existieren | | Komposition | gefüllte Raute | starke Teil-Ganzes-Beziehung, Teil gehört fest zum Ganzen | Einfacher Merksatz: ```text Aggregation = hat-Beziehung, Teil kann unabhängig existieren Komposition = besteht-aus-Beziehung, Teil ist stark abhängig ``` Beispiel Aggregation: ```text Team hat Mitarbeiter ``` Ein Mitarbeiter kann auch ohne dieses Team existieren. Beispiel Komposition: ```text Rechnung besteht aus Rechnungspositionen ``` Eine Rechnungsposition ergibt ohne Rechnung meist keinen Sinn. --- **Unterschied Klasse und Objekt** | Begriff | Bedeutung | Beispiel | |---|---|---| | Klasse | Bauplan | Produkt | | Objekt | konkrete Ausprägung | Produkt p1 = neuer Monitor | Beispiel: ```text Klasse: Produkt Objekt: monitor1 ``` Java: ```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** | UML-Klassendiagramm | ERM | |---|---| | zeigt Programmstruktur | zeigt Datenmodell | | Klassen | Entitäten | | Attribute | Attribute | | Methoden | keine Methoden | | Vererbung möglich | normalerweise keine Methoden/Vererbung | | wichtig für OOP / Java | wichtig für Datenbanken | Merksatz: ```text ERM = Daten fachlich modellieren UML-Klassendiagramm = Programmklassen modellieren ``` --- **Vorgehensweise in der Prüfung** Wenn du ein UML-Klassendiagramm erstellen sollst, gehe so vor: | Schritt | Frage | |---|---| | 1 | Welche Klassen gibt es? | | 2 | Welche Attribute gehören zu welcher Klasse? | | 3 | Welche Methoden sind sinnvoll oder vorgegeben? | | 4 | Gibt es gemeinsame Eigenschaften? | | 5 | Kann man eine Oberklasse bilden? | | 6 | Gibt es Vererbung? | | 7 | Gibt es Beziehungen zwischen Klassen? | | 8 | Welche Multiplizitäten sind sinnvoll? | | 9 | Welche Sichtbarkeit brauchen Attribute und Methoden? | --- **Beispiel: Produktverwaltung** Fachliche Beschreibung: ```text 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: ```text Produkt Monitor Tastatur ``` Oberklasse: ```text Produkt ``` Unterklassen: ```text Monitor Tastatur ``` Warum? ```text Monitor ist ein Produkt. Tastatur ist ein Produkt. ``` --- **Mögliches Klassendiagramm als Text** ```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** | Fehler | Warum problematisch? | |---|---| | Attribute und Methoden vermischen | Attribut speichert Daten, Methode führt Verhalten aus | | Sichtbarkeit vergessen | `+`, `-`, `#` sind wichtige UML-Informationen | | Attribute öffentlich machen | In Java sind Attribute meist private | | Vererbung falsch herum zeichnen | Pfeil zeigt zur Oberklasse | | Klassen im Plural schreiben | Klassennamen meist Singular | | ERM und Klassendiagramm verwechseln | ERM hat keine Methoden | | Methoden ohne Rückgabetyp schreiben | Rückgabetyp gehört häufig dazu | | Unterklasse enthält alle Oberklassenattribute doppelt | Gemeinsames gehört in die Oberklasse | --- **Prüfungs-Merksätze** ```text 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: ```text Ein Produkt hat eine Marke, ein Modell und einen Preis. ``` Lösung: ```text Produkt -------------------------------- - marke: String - modell: String - preis: double ``` Begründung: ```text marke, modell und preis sind Eigenschaften eines Produkts. Deshalb sind sie Attribute. ``` --- **Mini-Beispiel 2** Aufgabe: ```text Ein Monitor ist ein Produkt und hat zusätzlich eine Größe in Zoll. ``` Lösung: ```text Monitor erbt von Produkt. Monitor -------------------------------- - groesseZoll: double ``` Begründung: ```text Monitor ist eine spezielle Produktart. Deshalb ist Vererbung sinnvoll. ``` --- **Mini-Beispiel 3** Aufgabe: ```text Ein Kunde kann mehrere Bestellungen haben. ``` Mögliches UML-Klassendiagramm: ```text Kunde 1 ───── 0..* Bestellung ``` Begründung: ```text Ein Kunde kann mehrere Bestellungen haben. Eine Bestellung gehört zu einem Kunden. ``` --- **Mini-Testfragen**
1. Wofür wird ein UML-Klassendiagramm verwendet? Ein UML-Klassendiagramm wird verwendet, um die Struktur eines objektorientierten Programms darzustellen. Es zeigt: ```text Klassen Attribute Methoden Beziehungen Vererbung ```
2. Was ist eine Klasse? Eine Klasse ist ein Bauplan für Objekte. Beispiel: ```text Produkt Monitor Tastatur ```
3. Was ist ein Attribut? Ein Attribut ist eine gespeicherte Eigenschaft einer Klasse. Beispiel: ```text - marke: String - preis: double ```
4. Was ist eine Methode? Eine Methode beschreibt ein Verhalten oder eine Funktion einer Klasse. Beispiel: ```text + toString(): String + getPreis(): double ```
5. Was bedeutet `+` im UML-Klassendiagramm? `+` bedeutet: ```text public / öffentlich ``` Das Element ist von außen zugreifbar.
6. Was bedeutet `-` im UML-Klassendiagramm? `-` bedeutet: ```text private / privat ``` Das Element ist nur innerhalb der Klasse direkt zugreifbar.
7. In welche Richtung zeigt der Vererbungspfeil? Der Vererbungspfeil zeigt zur **Oberklasse**. Beispiel: ```text Monitor ───▷ Produkt ```
8. Warum gehören marke, modell und preis in die Klasse Produkt? Weil diese Attribute für mehrere Produktarten gemeinsam gelten können. Beispiele: ```text Monitor Tastatur Maus CPU ``` Alle können Marke, Modell und Preis haben.
9. Was ist der Unterschied zwischen Klasse und Objekt? Eine Klasse ist der Bauplan. Ein Objekt ist eine konkrete Instanz dieser Klasse. Beispiel: ```text Klasse: Produkt Objekt: monitor1 ```
10. Was ist der Unterschied zwischen ERM und UML-Klassendiagramm? ERM modelliert Daten fachlich. UML-Klassendiagramm modelliert die Programmstruktur. Wichtig: ```text Ein Klassendiagramm kann Methoden und Vererbung enthalten. Ein ERM normalerweise nicht. ```
--- **Nächste Seite** Danach kommt die eigene Trainer-Seite: ```text UML-Klassendiagramm-Trainer ``` Dort bauen wir den interaktiven Trainer mit Aufgaben zu: ```text 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: ```text UML-Klassendiagramm ``` Hier übst du, UML-Klassendiagramme richtig zu lesen und aus Aufgabenstellungen abzuleiten. Im Fokus stehen: ```text Klassen Attribute Methoden Sichtbarkeit Assoziation Vererbung Aggregation Komposition korrekte UML-Linienenden ``` --- **Was wird trainiert?** | Bereich | Bedeutung | |---|---| | **Klassen erkennen** | wichtige Programmobjekte aus der Aufgabe ableiten | | **Attribute zuordnen** | gespeicherte Eigenschaften in die richtige Klasse schreiben | | **Methoden eintragen** | Verhalten/Funktionen einer Klasse ergänzen | | **Sichtbarkeit beachten** | `+`, `-`, `#` korrekt selbst eintragen | | **Vererbung erkennen** | hohles Dreieck zeigt zur Oberklasse | | **Aggregation erkennen** | leere Raute steht am Ganzen | | **Komposition erkennen** | gefüllte Raute steht am Ganzen | | **Assoziation erkennen** | einfache Linie zwischen Klassen | --- **Interaktiver UML-Klassendiagramm-Trainer**
UML-Klassendiagramm-Trainer im Vollbild öffnen
--- **Merksatz für den Trainer** ```text 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: ```text Ein Kunde kann mehrere Bestellungen haben. Eine Bestellung gehört zu genau einem Kunden. ``` UML-Bedeutung: ```text Kunde ist mit Bestellung verbunden. ``` Darstellung: ```text Kunde ───── Bestellung ``` Wichtig: ```text Eine Assoziation ist eine normale Beziehung zwischen Klassen. Sie wird als einfache Linie dargestellt. ``` --- **Beispiel: Vererbung** Aufgabe: ```text Ein Monitor ist ein Produkt. ``` UML-Bedeutung: ```text Monitor erbt von Produkt. ``` Darstellung: ```text Monitor ─────▷ Produkt ``` Wichtig: ```text Das hohle Dreieck zeigt zur Oberklasse Produkt. ``` --- **Beispiel: Aggregation** Aufgabe: ```text Ein Team hat mehrere Mitarbeiter. Ein Mitarbeiter kann aber auch unabhängig vom Team existieren. ``` UML-Bedeutung: ```text Team aggregiert Mitarbeiter. ``` Darstellung: ```text Team ◇──── Mitarbeiter ``` Wichtig: ```text 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: ```text Eine Rechnung besteht aus Rechnungspositionen. Eine Rechnungsposition gehört fest zu genau einer Rechnung. ``` UML-Bedeutung: ```text Rechnung besteht aus Rechnungspositionen. ``` Darstellung: ```text Rechnung ◆──── Rechnungsposition ``` Wichtig: ```text 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** | Beziehung | Symbol | Bedeutung | Beispiel | |---|---|---|---| | **Aggregation** | leere Raute | schwache Teil-Ganzes-Beziehung | Team hat Mitarbeiter | | **Komposition** | gefüllte Raute | starke Teil-Ganzes-Beziehung | Rechnung besteht aus Positionen | Merksatz: ```text Leere Raute = Teil kann unabhängig existieren. Gefüllte Raute = Teil gehört fest zum Ganzen. ``` --- **Wichtiger Unterschied: Assoziation vs. Vererbung** | Beziehung | Symbol | Bedeutung | |---|---|---| | **Assoziation** | einfache Linie | Klassen stehen miteinander in Beziehung | | **Vererbung** | hohles Dreieck | Unterklasse erbt von Oberklasse | Beispiel Assoziation: ```text Kunde ───── Bestellung ``` Bedeutung: ```text Kunde und Bestellung hängen fachlich zusammen. ``` Beispiel Vererbung: ```text Monitor ─────▷ Produkt ``` Bedeutung: ```text Monitor ist ein spezielles Produkt. ``` --- **Sichtbarkeit im Trainer** Im Trainer musst du Sichtbarkeiten selbst eintragen. | Zeichen | Bedeutung | Typisch für | |---|---|---| | `+` | public / öffentlich | Methoden | | `-` | private / privat | Attribute | | `#` | protected / geschützt | Vererbung / Unterklassen | Beispiel: ```text - marke: String + toString(): String ``` Wichtig: ```text 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: ```text Vererbung: Monitor ist ein Produkt. Assoziation: Kunde hat Bestellungen. Aggregation: Team hat Mitarbeiter. Komposition: Rechnung besteht aus Rechnungspositionen. ``` --- **Typische Fehler** | Fehler | Warum falsch? | |---|---| | Raute auf der falschen Seite | Die Raute steht immer am Ganzen | | Vererbungsdreieck zeigt zur Unterklasse | Das Dreieck muss zur Oberklasse zeigen | | Aggregation und Komposition verwechseln | Leere Raute und gefüllte Raute haben unterschiedliche Bedeutung | | `+` und `-` vergessen | Sichtbarkeit ist Teil der UML-Notation | | Attribute und Methoden vermischen | Attribute speichern Daten, Methoden beschreiben Verhalten | | Oberklasse und Unterklasse vertauschen | Gemeinsame Eigenschaften gehören in die Oberklasse | --- **Mini-Testfragen**
1. Welche Linie zeigt eine normale Assoziation? Eine normale Assoziation wird durch eine einfache durchgezogene Linie dargestellt. Beispiel: ```text Kunde ───── Bestellung ```
2. Welche Pfeilspitze zeigt Vererbung? Vererbung wird mit einem **hohlen Dreieck** dargestellt. Wichtig: ```text Das hohle Dreieck zeigt zur Oberklasse. ``` Beispiel: ```text Monitor ─────▷ Produkt ```
3. Was bedeutet eine leere Raute? Eine leere Raute bedeutet **Aggregation**. Das ist eine schwächere Teil-Ganzes-Beziehung. Beispiel: ```text Team ◇──── Mitarbeiter ``` Der Mitarbeiter kann unabhängig vom Team existieren.
4. Was bedeutet eine gefüllte Raute? Eine gefüllte Raute bedeutet **Komposition**. Das ist eine starke Teil-Ganzes-Beziehung. Beispiel: ```text Rechnung ◆──── Rechnungsposition ``` Die Rechnungsposition gehört fest zur Rechnung.
5. Wo steht die Raute bei Aggregation oder Komposition? Die Raute steht am **Ganzen**. Beispiele: ```text Team ◇──── Mitarbeiter Rechnung ◆──── Rechnungsposition ```
6. Warum soll `+` oder `-` nicht schon im Eingabefeld stehen? Weil du selbst erkennen und eintragen sollst, ob ein Attribut oder eine Methode öffentlich oder privat ist. Typisch: ```text - attribut: Typ + methode(): Typ ```
7. Was bedeutet `- marke: String`? Das bedeutet: ```text private Attribut marke vom Typ String ``` In Java wäre das zum Beispiel: ```java private String marke; ```
8. Was bedeutet `+ toString(): String`? Das bedeutet: ```text public Methode toString mit Rückgabewert String ``` In Java wäre das zum Beispiel: ```java public String toString() ```
9. Was ist der wichtigste Unterschied zwischen Aggregation und Komposition? Aggregation: ```text Teil kann unabhängig existieren. ``` Komposition: ```text Teil gehört fest zum Ganzen. ```
10. Wohin zeigt der Vererbungspfeil? Der Vererbungspfeil zeigt immer zur **Oberklasse**. Beispiel: ```text Monitor ─────▷ Produkt ``` Produkt ist die Oberklasse.
--- **Nächste Seite** Danach geht es weiter mit: ```text 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: ```text Start Aktionen Entscheidungen Bedingungen Kontrollflüsse Merge-Knoten Ende ``` --- **Grafik 1: UML-Aktivitätsdiagramm – Grundlagen** ![UML-Aktivitätsdiagramm – Grundlagen](https://trainer.ulrich-wiki.com/assets/uml-aktivitaetsdiagramm-grundlagen.svg?v=1) Diese Grafik zeigt dir die wichtigsten Symbole: - **Startknoten** - **Aktion / Aktivität** - **Entscheidung** - **Merge-Knoten** - **Kontrollfluss** - **Endknoten** Wichtig für die Prüfung: ```text 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: ```text 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: ```text 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: | Signalwort / Formulierung | Hinweis | |---|---| | Ablauf | Schritte sollen dargestellt werden | | Prozess | Reihenfolge von Tätigkeiten | | Entscheidung | meistens Raute | | wenn / sonst | Verzweigung im Ablauf | | prüfen | häufig Entscheidung danach | | gültig / ungültig | typische Guard-Bedingungen | | ja / nein | Entscheidungsausgänge | | Schleife | Rücksprung im Ablauf | | Kontrollfluss | Pfeile zwischen Aktionen | | „stellen Sie den Ablauf dar“ | oft Aktivitätsdiagramm | --- **Grundsymbole** | Symbol | Bedeutung | Darstellung | |---|---|---| | **Startknoten** | Beginn des Ablaufs | gefüllter Kreis | | **Aktion / Aktivität** | auszuführender Schritt | abgerundetes Rechteck | | **Entscheidung** | Verzweigung im Ablauf | Raute | | **Merge-Knoten** | Zusammenführung alternativer Pfade | Raute | | **Kontrollfluss** | Ablaufreihenfolge | Pfeil | | **Endknoten** | Ende des Ablaufs | Kreis mit gefülltem Punkt | --- **Startknoten** Der Startknoten zeigt, wo der Ablauf beginnt. Darstellung: ```text ● ``` Merksatz: ```text Start = gefüllter Kreis ``` Ein Aktivitätsdiagramm hat meistens genau einen klaren Startpunkt. --- **Aktion / Aktivität** Eine Aktion ist ein konkreter Arbeitsschritt. Beispiele: ```text Produktdaten eingeben Eingabe prüfen Produkt speichern Fehler anzeigen Zurück ins Menü ``` Darstellung: ```text ( Produktdaten eingeben ) ``` Im Diagramm wird dafür normalerweise ein **abgerundetes Rechteck** verwendet. --- **Kontrollfluss** Ein Kontrollfluss zeigt die Reihenfolge der Schritte. Darstellung: ```text Aktion 1 → Aktion 2 ``` Wichtig: ```text Der Pfeil zeigt, welcher Schritt als Nächstes kommt. ``` --- **Entscheidung** Eine Entscheidung wird verwendet, wenn der Ablauf in verschiedene Richtungen gehen kann. Darstellung: ```text ◇ ``` Beispiel: ```text Eingabe gültig? ``` Danach gibt es meistens zwei Wege: ```text [ja] [nein] ``` Wichtig: ```text Die Bedingungen an den ausgehenden Pfeilen heißen Guards. ``` --- **Guards** Guards sind Bedingungen an Kontrollflüssen. Typische Schreibweise: ```text [ja] [nein] [gültig] [ungültig] [preis > 0] [eingabe leer] ``` Beispiel: ```text Eingabe gültig? [ja] → Produkt speichern [nein] → Fehler anzeigen ``` Für Prüfungen ist wichtig: ```text Bedingungen sollten an den Pfeilen stehen, nicht nur irgendwo im Diagramm. ``` --- **Merge-Knoten** Ein Merge-Knoten führt alternative Wege wieder zusammen. Darstellung: ```text ◇ ``` Wichtig: ```text Entscheidung und Merge benutzen beide eine Raute. ``` Der Unterschied: | Element | Bedeutung | |---|---| | **Entscheidung** | ein Eingang, mehrere Ausgänge | | **Merge-Knoten** | mehrere Eingänge, ein Ausgang | Beispiel: ```text [ja] → Produkt speichern ┐ ◇ → Zurück ins Menü [nein] → Fehler anzeigen ┘ ``` --- **Endknoten** Der Endknoten zeigt das Ende des Ablaufs. Darstellung: ```text ◎ ``` Merksatz: ```text Ende = Kreis mit gefülltem Punkt ``` --- **Grafik 2: Beispiel – Produkt speichern** ![UML-Aktivitätsdiagramm – Produkt speichern](https://trainer.ulrich-wiki.com/assets/uml-aktivitaetsdiagramm-beispiel-produkt-speichern.svg?v=1) Diese Grafik zeigt einen typischen Ablauf: ```text Produktdaten eingeben Eingabe prüfen Entscheidung: Eingabe gültig? [ja] → Produkt speichern [nein] → Fehler anzeigen Merge-Knoten Zurück ins Menü Ende ``` Wichtig: ```text 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: ```text 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: ```text Start ↓ Produktdaten eingeben ↓ Eingabe prüfen ↓ Eingabe gültig? ├─ [ja] → Produkt speichern └─ [nein] → Fehler anzeigen ↓ Merge ↓ Zurück ins Menü ↓ Ende ``` --- **Entscheidung vs. Merge** | Merkmal | Entscheidung | Merge | |---|---|---| | Symbol | Raute | Raute | | Eingänge | meistens 1 | mehrere | | Ausgänge | mehrere | meistens 1 | | Zweck | Ablauf verzweigt sich | alternative Wege kommen zusammen | | Beispiel | Eingabe gültig? | nach Speichern oder Fehleranzeige weiter | Merksatz: ```text 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: ```java if (eingabeGueltig) { produktSpeichern(); } else { fehlerAnzeigen(); } zurueckInsMenue(); ``` Passendes Aktivitätsdiagramm: ```text Eingabe prüfen ↓ Eingabe gültig? ├─ [ja] → Produkt speichern └─ [nein] → Fehler anzeigen ↓ Merge ↓ Zurück ins Menü ``` --- **Typische Kontrollstrukturen** | Kontrollstruktur | Darstellung im Aktivitätsdiagramm | |---|---| | Sequenz | Aktionen nacheinander | | Entscheidung | Raute mit Guards | | Alternative | [ja] / [nein] | | Schleife | Rückpfeil zu früherer Aktion | | Zusammenführung | Merge-Knoten | | Ende | Endknoten | --- **Schleifen im Aktivitätsdiagramm** Eine Schleife entsteht, wenn ein Ablauf zu einem früheren Schritt zurückführt. Beispiel: ```text Eingabe prüfen ↓ Eingabe gültig? ├─ [ja] → Speichern └─ [nein] → Fehler anzeigen → Eingabe erneut bearbeiten ``` Merksatz: ```text 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: | Schritt | Frage | |---|---| | 1 | Wo beginnt der Ablauf? | | 2 | Welche Aktionen passieren nacheinander? | | 3 | Gibt es eine Entscheidung? | | 4 | Welche Bedingungen stehen an den Ausgängen? | | 5 | Gibt es alternative Wege? | | 6 | Müssen Wege wieder zusammengeführt werden? | | 7 | Gibt es eine Schleife oder einen Rücksprung? | | 8 | Wo endet der Ablauf? | --- **Typische IHK-Fehler** | Fehler | Warum problematisch? | |---|---| | Startknoten vergessen | Ablauf hat keinen klaren Beginn | | Endknoten vergessen | Ablauf wirkt unvollständig | | Entscheidung ohne Bedingungen | nicht klar, welcher Weg wann gilt | | Guards nicht in eckigen Klammern | weniger UML-sauber | | Merge fehlt | alternative Wege werden unsauber zusammengeführt | | Aktion als Raute gezeichnet | Aktion ist keine Entscheidung | | Entscheidung als Rechteck gezeichnet | Verzweigung wird falsch dargestellt | | Pfeilrichtung falsch | Ablaufreihenfolge ist unklar | | Zu viel Text in einer Aktion | Aktionen sollten kurz und eindeutig sein | --- **Prüfungs-Merksätze** ```text 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: ```text Wenn ein Passwort korrekt ist, wird der Benutzer angemeldet. Sonst wird eine Fehlermeldung angezeigt. ``` Lösungsidee: ```text Start ↓ Passwort prüfen ↓ Passwort korrekt? ├─ [ja] → Benutzer anmelden └─ [nein] → Fehlermeldung anzeigen ↓ Ende ``` --- **Mini-Beispiel 2** Aufgabe: ```text Ein Preis wird eingegeben. Wenn der Preis größer als 0 ist, wird das Produkt gespeichert. Sonst wird eine Fehlermeldung angezeigt. ``` Lösungsidee: ```text Start ↓ Preis eingeben ↓ Preis > 0? ├─ [ja] → Produkt speichern └─ [nein] → Fehler anzeigen ↓ Ende ``` --- **Mini-Beispiel 3** Aufgabe: ```text 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: ```text 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**
1. Wofür verwendet man ein UML-Aktivitätsdiagramm? Ein UML-Aktivitätsdiagramm verwendet man, um Abläufe, Prozesse und Entscheidungen darzustellen. Beispiele: ```text Login prüfen Produkt speichern Bestellung bearbeiten ```
2. Wie wird der Startknoten dargestellt? Der Startknoten wird als gefüllter Kreis dargestellt. ```text ● ```
3. Wie wird eine Aktion dargestellt? Eine Aktion wird als abgerundetes Rechteck dargestellt. Beispiel: ```text Produkt speichern ```
4. Wie wird eine Entscheidung dargestellt? Eine Entscheidung wird als Raute dargestellt. Beispiel: ```text Eingabe gültig? ```
5. Was sind Guards? Guards sind Bedingungen an Kontrollflüssen. Beispiele: ```text [ja] [nein] [gültig] [ungültig] [preis > 0] ```
6. Was ist der Unterschied zwischen Entscheidung und Merge? Eine Entscheidung teilt den Ablauf in mehrere Wege. Ein Merge führt alternative Wege wieder zusammen. ```text Entscheidung = 1 Eingang, mehrere Ausgänge Merge = mehrere Eingänge, 1 Ausgang ```
7. Wie wird der Endknoten dargestellt? Der Endknoten wird als Kreis mit gefülltem Punkt dargestellt. ```text ◎ ```
8. Was zeigt ein Kontrollfluss? Ein Kontrollfluss zeigt die Reihenfolge der Aktionen. Er wird als Pfeil dargestellt.
9. Woran erkennt man eine Schleife? Eine Schleife erkennt man daran, dass ein Pfeil zu einem früheren Schritt zurückführt. Beispiel: ```text Fehler anzeigen → Daten erneut eingeben ```
10. Welcher häufige Fehler passiert bei Entscheidungen? Ein häufiger Fehler ist, die Bedingungen an den Ausgängen nicht zu beschriften. Besser: ```text [ja] [nein] ```
--- **Nächste Seite** Danach kommt die eigene Trainer-Seite: ```text UML-Aktivitätsdiagramm-Trainer ``` Dort bauen wir den interaktiven Trainer mit Aufgaben zu: ```text 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: ```text UML-Aktivitätsdiagramm ``` Hier übst du, aus einer Aufgabenbeschreibung ein korrektes UML-Aktivitätsdiagramm abzuleiten. Im Fokus stehen: ```text Startknoten Aktionen Entscheidungsraute Guards Kontrollflüsse Merge-Knoten Endknoten ``` --- **Was wird trainiert?** | Bereich | Bedeutung | |---|---| | **Start erkennen** | Der Ablauf beginnt mit einem gefüllten Kreis | | **Aktionen eintragen** | Arbeitsschritte als abgerundete Rechtecke | | **Entscheidung erkennen** | Verzweigung als Raute | | **Guards eintragen** | Bedingungen wie `[ja]` und `[nein]` an den Pfeilen | | **Merge-Knoten erkennen** | Alternative Wege werden wieder zusammengeführt | | **Ende erkennen** | Kreis mit gefülltem Punkt | | **Ablaufreihenfolge verstehen** | Pfeile zeigen den Kontrollfluss | --- **Interaktiver UML-Aktivitätsdiagramm-Trainer**
UML-Aktivitätsdiagramm-Trainer im Vollbild öffnen
--- **Merksatz für den Trainer** ```text 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: ```text 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: ```text 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. ```text Aktion = abgerundetes Rechteck Entscheidung = Raute Merge = Raute ``` Der Unterschied liegt im Ablauf: | Symbol | Bedeutung | |---|---| | **Entscheidung** | ein Eingang, mehrere Ausgänge | | **Merge** | mehrere Eingänge, ein Ausgang | --- **Warum stehen `[ja]` und `[nein]` an den Pfeilen?** Die Bedingungen heißen **Guards**. Sie beschreiben, wann ein bestimmter Weg genommen wird. Beispiel: ```text Eingabe gültig? ├─ [ja] → Produkt speichern └─ [nein] → Fehler anzeigen ``` Wichtig: ```text [ja] und [nein] gehören an die ausgehenden Kontrollflüsse der Entscheidung. ``` --- **Typische Aufgaben im Trainer** Der Trainer enthält Aufgaben zu: ```text Produkt speichern Login prüfen Preis prüfen ``` Dabei musst du jeweils erkennen: ```text 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** | Fehler | Warum falsch? | |---|---| | Entscheidung als Rechteck | Eine Entscheidung muss als Raute dargestellt werden | | Guards fehlen | Es ist nicht klar, welcher Pfad wann gilt | | `[ja]` und `[nein]` stehen an falscher Stelle | Guards gehören an die Kontrollflüsse | | Merge-Knoten fehlt | Alternative Wege werden unsauber zusammengeführt | | Pfeile zeigen in falsche Richtung | Ablaufreihenfolge wird falsch | | Aktion zu lang formuliert | Aktionen sollten kurz und eindeutig sein | | Start- oder Endknoten fehlt | Ablauf wirkt unvollständig | --- **Mini-Testfragen**
1. Wie wird der Startknoten dargestellt? Der Startknoten wird als gefüllter Kreis dargestellt. ```text ● ```
2. Wie wird eine Aktion dargestellt? Eine Aktion wird als abgerundetes Rechteck dargestellt. Beispiel: ```text Produkt speichern ```
3. Wie wird eine Entscheidung dargestellt? Eine Entscheidung wird als Raute dargestellt. Beispiel: ```text Eingabe gültig? ```
4. Was sind Guards? Guards sind Bedingungen an den Kontrollflüssen. Beispiele: ```text [ja] [nein] [gültig] [ungültig] ```
5. Was ist ein Merge-Knoten? Ein Merge-Knoten führt alternative Ablaufwege wieder zusammen. Er wird ebenfalls als Raute dargestellt. ```text mehrere Eingänge → Merge → ein Ausgang ```
6. Was ist der Unterschied zwischen Entscheidung und Merge? Eine Entscheidung teilt den Ablauf. Ein Merge führt alternative Wege wieder zusammen. ```text Entscheidung = ein Eingang, mehrere Ausgänge Merge = mehrere Eingänge, ein Ausgang ```
7. Wie wird der Endknoten dargestellt? Der Endknoten wird als Kreis mit gefülltem Punkt dargestellt. ```text ◎ ```
8. Wo gehören `[ja]` und `[nein]` hin? Sie gehören an die ausgehenden Pfeile der Entscheidungsraute. ```text Eingabe gültig? ├─ [ja] → Speichern └─ [nein] → Fehler anzeigen ```
9. Warum ist ein Merge nach einer Entscheidung sinnvoll? Wenn beide alternativen Wege danach wieder gemeinsam weiterlaufen, führt ein Merge-Knoten diese Wege sauber zusammen. Beispiel: ```text [ja] → Speichern ┐ Merge → Zurück ins Menü [nein] → Fehler ┘ ```
10. Was zeigt der Kontrollfluss? Der Kontrollfluss zeigt die Reihenfolge der Aktionen. Er wird als Pfeil dargestellt.
--- **Nächste Seite** Danach geht es weiter mit: ```text 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: ```text 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: ```text Ein Anwendungsfalldiagramm zeigt nicht den inneren Programmablauf. Es zeigt die Sicht von außen auf das System. ``` --- **Grafik 1: UML-Anwendungsfalldiagramm – Grundlagen** ![UML-Anwendungsfalldiagramm – Grundlagen](https://trainer.ulrich-wiki.com/assets/uml-anwendungsfalldiagramm-grundlagen.svg?v=1) 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: ```text 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: ```text 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: ```text 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: | Signalwort / Formulierung | Hinweis | |---|---| | Akteur | externe Rolle oder Person | | Benutzer | jemand nutzt das System | | System | Systemgrenze ist wahrscheinlich wichtig | | Funktion | Anwendungsfall / Use Case | | Anwendungsfall | Use Case direkt gemeint | | Anforderungen | oft Use-Case-Sicht | | Benutzer kann ... | Akteur + Use Case | | System soll ... ermöglichen | Use Case | | Kunde, Admin, Mitarbeiter | typische Akteure | | „stellen Sie die Nutzung des Systems dar“ | Anwendungsfalldiagramm | --- **Grundidee** Ein Anwendungsfalldiagramm zeigt die **Außensicht** auf ein System. Es zeigt nicht: ```text Welche Klasse welche Methode hat. Wie der Ablauf Schritt für Schritt funktioniert. Welche Datenbanktabellen entstehen. ``` Sondern es zeigt: ```text Welche Akteure gibt es? Welche Funktionen stellt das System bereit? Welche Akteure nutzen welche Funktionen? ``` Merksatz: ```text Anwendungsfalldiagramm = Wer nutzt welche Funktion des Systems? ``` --- **Akteur** Ein Akteur ist eine Rolle außerhalb des Systems. Beispiele: ```text Kunde Admin Mitarbeiter Lehrer Schüler Zahlungsdienst E-Mail-System ``` Wichtig: ```text Ein Akteur muss nicht immer ein Mensch sein. Auch ein externes System kann ein Akteur sein. ``` Beispiel: ```text 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: ```text Akteure außen. Use Cases innen. Systemgrenze als Rechteck. ``` Beispiel: ```text Kunde [ Shop-System ] (Artikel suchen) (Bestellung aufgeben) ``` --- **Anwendungsfall / Use Case** Ein Anwendungsfall beschreibt eine Funktion des Systems aus Sicht eines Akteurs. Darstellung: ```text ( Bestellung aufgeben ) ``` Also als **Ellipse**. Gute Use-Case-Namen sind meistens kurze Tätigkeiten: ```text Artikel suchen Bestellung aufgeben Zahlung durchführen Benutzer anmelden Artikel verwalten Passwort zurücksetzen ``` Wichtig: ```text Use Cases sollten einen Nutzen für einen Akteur haben. ``` Nicht ideal: ```text Datenbank speichern Methode ausführen SQL ausführen ``` Besser: ```text Bestellung speichern Kundendaten verwalten Rechnung erstellen ``` --- **Assoziation** Eine Assoziation verbindet einen Akteur mit einem Anwendungsfall. Darstellung: ```text Kunde ───── (Artikel suchen) ``` Bedeutung: ```text Der Akteur nutzt diesen Anwendungsfall. ``` Wichtig: ```text Eine Assoziation ist normalerweise eine einfache Linie. ``` --- **«include»** `«include»` bedeutet: ```text Ein Anwendungsfall enthält einen anderen Anwendungsfall immer als Pflichtbestandteil. ``` Beispiel: ```text Bestellung aufgeben «include» Zahlung durchführen ``` Bedeutung: ```text Wenn eine Bestellung aufgegeben wird, muss die Zahlung durchgeführt werden. ``` Typische Fälle für `«include»`: ```text Anmelden Zahlung durchführen Berechtigung prüfen Daten validieren ``` Wichtig: ```text «include» zeigt auf den eingebundenen Pflicht-Anwendungsfall. ``` Beispiel: ```text (Bestellung aufgeben) - - -«include»- - -> (Zahlung durchführen) ``` --- **«extend»** `«extend»` bedeutet: ```text Ein Anwendungsfall erweitert einen anderen Anwendungsfall optional. ``` Beispiel: ```text Rabatt prüfen «extend» Bestellung aufgeben ``` Bedeutung: ```text Rabatt prüfen passiert nur unter bestimmten Bedingungen. ``` Zum Beispiel: ```text wenn ein Rabattcode eingegeben wurde wenn der Kunde berechtigt ist wenn eine Sonderaktion aktiv ist ``` Wichtig: ```text «extend» zeigt vom optionalen Erweiterungsfall auf den Basis-Anwendungsfall. ``` Beispiel: ```text (Rabatt prüfen) - - -«extend»- - -> (Bestellung aufgeben) ``` --- **Unterschied «include» und «extend»** | Beziehung | Bedeutung | Beispiel | Merksatz | |---|---|---|---| | **«include»** | Pflichtbestandteil | Bestellung aufgeben enthält Zahlung durchführen | muss immer passieren | | **«extend»** | optionale Erweiterung | Rabatt prüfen erweitert Bestellung aufgeben | passiert nur manchmal | Merksatz: ```text include = immer dabei extend = optional / nur bei Bedingung ``` --- **Generalisierung** Generalisierung bedeutet: ```text Ein spezieller Akteur oder Use Case erbt von einem allgemeineren Akteur oder Use Case. ``` Beispiel bei Akteuren: ```text Admin ist ein spezieller Benutzer. ``` Darstellung: ```text Admin ─────▷ Benutzer ``` Wichtig: ```text Das hohle Dreieck zeigt zur allgemeineren Rolle. ``` Also: ```text Admin → Benutzer ``` nicht umgekehrt. --- **Grafik 2: Beispiel – Shop-System** ![UML-Anwendungsfalldiagramm – Beispiel Shop-System](https://trainer.ulrich-wiki.com/assets/uml-anwendungsfalldiagramm-beispiel-shop.svg?v=1) Diese Grafik zeigt ein Beispiel für ein Shop-System. Es enthält: ```text Akteure: Kunde Admin Use Cases: Anmelden Artikel suchen Bestellung aufgeben Zahlung durchführen Rabatt prüfen Artikel verwalten ``` Wichtig: ```text Kunde und Admin stehen außerhalb der Systemgrenze. Die Anwendungsfälle stehen innerhalb der Systemgrenze. ``` --- **Beispiel als Textbeschreibung** Aufgabe: ```text 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: ```text 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** | Akteur | Rolle | |---|---| | **Kunde** | nutzt den Shop, sucht Artikel, gibt Bestellungen auf | | **Admin** | verwaltet Artikel im Shop-System | Wichtig: ```text Akteure sind Rollen. Nicht jede konkrete Person wird einzeln gezeichnet. ``` Also: ```text Kunde ``` nicht: ```text Max Müller ``` --- **Use Cases im Beispiel** | Use Case | Bedeutung | |---|---| | **Anmelden** | Benutzer meldet sich im System an | | **Artikel suchen** | Kunde sucht Produkte | | **Bestellung aufgeben** | Kunde erstellt eine Bestellung | | **Zahlung durchführen** | Zahlung wird abgewickelt | | **Rabatt prüfen** | Rabattcode oder Rabattbedingung wird geprüft | | **Artikel verwalten** | Admin erstellt, ändert oder löscht Artikel | --- **Warum ist „Zahlung durchführen“ ein «include»?** Weil die Zahlung beim Aufgeben einer Bestellung ein notwendiger Bestandteil ist. ```text Bestellung aufgeben ``` enthält immer: ```text Zahlung durchführen ``` Darum: ```text 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: ```text Rabatt prüfen «extend» Bestellung aufgeben ``` Merksatz: ```text Rabatt = optional Zahlung = Pflicht ``` --- **Anwendungsfalldiagramm vs. Aktivitätsdiagramm** | Anwendungsfalldiagramm | Aktivitätsdiagramm | |---|---| | zeigt Funktionen aus Benutzersicht | zeigt Ablauf Schritt für Schritt | | Akteure außen | Start, Aktionen, Entscheidungen | | Use Cases als Ellipsen | Aktionen als abgerundete Rechtecke | | keine genaue Reihenfolge | genaue Ablaufreihenfolge | | gut für Anforderungen | gut für Prozesslogik | Merksatz: ```text Anwendungsfalldiagramm = Wer nutzt was? Aktivitätsdiagramm = Was passiert danach? ``` --- **Anwendungsfalldiagramm vs. Klassendiagramm** | Anwendungsfalldiagramm | Klassendiagramm | |---|---| | zeigt Systemfunktionen | zeigt Programmstruktur | | Akteure und Use Cases | Klassen, Attribute, Methoden | | Sicht von außen | technische Struktur | | Anforderungen | OOP-Modellierung | Merksatz: ```text Use Case = Funktion aus Nutzersicht Klasse = Bauplan im Programm ``` --- **Vorgehensweise in der Prüfung** Wenn du ein UML-Anwendungsfalldiagramm erstellen sollst, gehe so vor: | Schritt | Frage | |---|---| | 1 | Was ist das System? | | 2 | Wo liegt die Systemgrenze? | | 3 | Welche Akteure gibt es? | | 4 | Welche Funktionen nutzt jeder Akteur? | | 5 | Welche Use Cases gehören in das System? | | 6 | Welche Assoziationen gibt es? | | 7 | Gibt es Pflichtbestandteile? | | 8 | Gibt es optionale Erweiterungen? | | 9 | Gibt es allgemeinere und speziellere Akteure? | --- **Typische IHK-Fehler** | Fehler | Warum problematisch? | |---|---| | Akteur innerhalb der Systemgrenze | Akteure stehen außerhalb | | Use Case außerhalb der Systemgrenze | Use Cases gehören ins System | | technische Methoden als Use Cases | Use Cases sollen Nutzersicht zeigen | | `include` und `extend` verwechselt | Pflicht und Option werden falsch dargestellt | | Pfeilrichtung bei `include` falsch | `include` zeigt auf den eingebundenen Use Case | | Pfeilrichtung bei `extend` falsch | `extend` zeigt vom Erweiterungsfall zum Basisfall | | Systemgrenze vergessen | unklar, was zum System gehört | | Akteure als konkrete Personen benannt | Akteure sind Rollen | --- **Prüfungs-Merksätze** ```text 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: ```text Ein Benutzer kann sich anmelden. ``` Lösung: ```text Akteur: Benutzer Use Case: Anmelden Benutzer ─ (Anmelden) ``` --- **Mini-Beispiel 2** Aufgabe: ```text Ein Kunde kann eine Bestellung aufgeben. Dabei muss eine Zahlung durchgeführt werden. ``` Lösung: ```text Kunde ─ (Bestellung aufgeben) (Bestellung aufgeben) «include» (Zahlung durchführen) ``` Begründung: ```text Zahlung durchführen ist ein Pflichtbestandteil der Bestellung. ``` --- **Mini-Beispiel 3** Aufgabe: ```text Ein Kunde kann bei einer Bestellung optional einen Rabattcode verwenden. ``` Lösung: ```text (Rabatt prüfen) «extend» (Bestellung aufgeben) ``` Begründung: ```text Rabatt prüfen ist optional. Es passiert nur, wenn ein Rabattcode vorhanden ist. ``` --- **Mini-Testfragen**
1. Wofür verwendet man ein UML-Anwendungsfalldiagramm? Man verwendet es, um darzustellen: ```text Welche Akteure ein System nutzen und welche Funktionen das System anbietet. ``` Merksatz: ```text Wer nutzt was? ```
2. Wo stehen Akteure im Anwendungsfalldiagramm? Akteure stehen außerhalb der Systemgrenze. Sie gehören nicht zum System selbst.
3. Wie werden Use Cases dargestellt? Use Cases werden als Ellipsen dargestellt. Beispiel: ```text ( Bestellung aufgeben ) ```
4. Was zeigt die Systemgrenze? Die Systemgrenze zeigt, welche Anwendungsfälle zum betrachteten System gehören. Sie wird als Rechteck um die Use Cases dargestellt.
5. Was bedeutet «include»? `«include»` bedeutet: ```text Ein Use Case enthält einen anderen Use Case verpflichtend. ``` Beispiel: ```text Bestellung aufgeben «include» Zahlung durchführen ```
6. Was bedeutet «extend»? `«extend»` bedeutet: ```text Ein Use Case erweitert einen anderen Use Case optional. ``` Beispiel: ```text Rabatt prüfen «extend» Bestellung aufgeben ```
7. Was ist der wichtigste Unterschied zwischen include und extend? ```text include = Pflichtbestandteil extend = optionale Erweiterung ```
8. In welche Richtung zeigt «include»? `«include»` zeigt auf den eingebundenen Pflicht-Use-Case. Beispiel: ```text Bestellung aufgeben → Zahlung durchführen ```
9. In welche Richtung zeigt «extend»? `«extend»` zeigt vom optionalen Erweiterungsfall zum Basis-Use-Case. Beispiel: ```text Rabatt prüfen → Bestellung aufgeben ```
10. Was ist ein typischer Fehler bei Anwendungsfalldiagrammen? Ein typischer Fehler ist, technische Methoden als Use Cases zu zeichnen. Nicht gut: ```text saveOrder() ``` Besser: ```text Bestellung aufgeben ```
--- **Nächste Seite** Danach kommt die eigene Trainer-Seite: ```text UML-Anwendungsfalldiagramm-Trainer ``` Dort bauen wir den interaktiven Trainer mit Aufgaben zu: ```text 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: ```text UML-Anwendungsfalldiagramm ``` Hier übst du, aus einer Aufgabenbeschreibung ein korrektes UML-Anwendungsfalldiagramm abzuleiten. Im Fokus stehen: ```text Akteure Systemgrenze Use Cases Assoziationen <> <> Pfeilrichtung Pflichtbestandteil vs. optionale Erweiterung ``` --- **Was wird trainiert?** | Bereich | Bedeutung | |---|---| | **Akteure erkennen** | externe Rollen außerhalb des Systems | | **Systemgrenze verstehen** | Rechteck um die Use Cases | | **Use Cases benennen** | Funktionen des Systems als Ellipsen | | **Assoziationen erkennen** | einfache Linien zwischen Akteur und Use Case | | **<> erkennen** | Pflichtbestandteil eines Use Cases | | **<> erkennen** | optionale Erweiterung eines Use Cases | | **Pfeilrichtung prüfen** | include und extend zeigen in unterschiedliche fachliche Richtungen | --- **Interaktiver UML-Anwendungsfalldiagramm-Trainer**
UML-Anwendungsfalldiagramm-Trainer im Vollbild öffnen
--- **Merksatz für den Trainer** ```text 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 <> = Pflichtbestandteil <> = optionale Erweiterung include zeigt zum eingebundenen Pflicht-Use-Case extend zeigt zum Basis-Use-Case ``` --- **Beispiel: Shop-System** Aufgabenstellung: ```text 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: ```text 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 <> Zahlung durchführen Rabatt prüfen <> Bestellung aufgeben ``` --- **Warum ist „Zahlung durchführen“ ein <>?** ```text Bestellung aufgeben <> Zahlung durchführen ``` Das bedeutet: ```text Wenn eine Bestellung aufgegeben wird, muss die Zahlung durchgeführt werden. ``` Also ist die Zahlung ein **Pflichtbestandteil**. --- **Warum ist „Rabatt prüfen“ ein <>?** ```text Rabatt prüfen <> Bestellung aufgeben ``` Das bedeutet: ```text Rabatt prüfen erweitert Bestellung aufgeben nur optional. ``` Zum Beispiel: ```text nur wenn ein Rabattcode vorhanden ist nur wenn eine Aktion aktiv ist nur wenn der Kunde berechtigt ist ``` --- **Richtige Pfeilrichtung** | Beziehung | Richtung | |---|---| | **<>** | vom Basis-Use-Case zum eingebundenen Pflicht-Use-Case | | **<>** | vom optionalen Erweiterungs-Use-Case zum Basis-Use-Case | Merksatz: ```text include zeigt auf das, was immer gebraucht wird. extend zeigt auf das, was optional erweitert wird. ``` --- **Typische Fehler** | Fehler | Warum falsch? | |---|---| | Akteur innerhalb der Systemgrenze | Akteure stehen außerhalb | | Use Case außerhalb der Systemgrenze | Use Cases gehören ins System | | Pfeile bei Akteur-Verbindung | Akteur–Use Case ist normalerweise einfache Linie | | include und extend vertauscht | Pflicht und Option werden falsch dargestellt | | include-Pfeil falsch herum | include zeigt auf den Pflicht-Use-Case | | extend-Pfeil falsch herum | extend zeigt auf den Basis-Use-Case | | technische Methoden als Use Cases | Use Cases sollen Nutzersicht zeigen | --- **Mini-Testfragen**
1. Wo stehen Akteure im Anwendungsfalldiagramm? Akteure stehen außerhalb der Systemgrenze.
2. Wie werden Use Cases dargestellt? Use Cases werden als Ellipsen dargestellt. Beispiel: ```text ( Bestellung aufgeben ) ```
3. Wie wird eine Akteur–Use-Case-Beziehung dargestellt? Als einfache durchgezogene Linie ohne Pfeilspitze. Beispiel: ```text Kunde — Bestellung aufgeben ```
4. Was bedeutet <>? `<>` bedeutet Pflichtbestandteil. Beispiel: ```text Bestellung aufgeben <> Zahlung durchführen ```
5. Was bedeutet <>? `<>` bedeutet optionale Erweiterung. Beispiel: ```text Rabatt prüfen <> Bestellung aufgeben ```
6. In welche Richtung zeigt include? `<>` zeigt vom Basis-Use-Case zum eingebundenen Pflicht-Use-Case. ```text Bestellung aufgeben → Zahlung durchführen ```
7. In welche Richtung zeigt extend? `<>` zeigt vom optionalen Erweiterungs-Use-Case zum Basis-Use-Case. ```text Rabatt prüfen → Bestellung aufgeben ```
8. Warum ist Zahlung durchführen im Shop-Beispiel include? Weil die Zahlung ein notwendiger Bestandteil der Bestellung ist. ```text Ohne Zahlung ist die Bestellung nicht vollständig. ```
9. Warum ist Rabatt prüfen im Shop-Beispiel extend? Weil der Rabatt nur optional geprüft wird. ```text Nur wenn ein Rabattcode oder eine Rabattbedingung vorhanden ist. ```
10. Was zeigt ein Anwendungsfalldiagramm nicht? Es zeigt nicht den inneren Programmablauf. Nicht dargestellt werden: ```text if-Anweisungen Schleifen Methodenaufrufe Datenbanktabellen ``` Dafür wären andere Diagramme besser geeignet.
--- **Nächste Seite** Danach geht es weiter mit: ```text 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: ```text 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: ```text Ein Sequenzdiagramm zeigt einen konkreten Ablauf. Der Ablauf wird von oben nach unten gelesen. ``` --- **Grafik 1: UML-Sequenzdiagramm – Grundlagen** ![UML-Sequenzdiagramm – Grundlagen](https://trainer.ulrich-wiki.com/assets/uml-sequenzdiagramm-grundlagen.svg?v=1) Diese Grafik zeigt die wichtigsten Bestandteile: ```text 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: ```text 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: ```text 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: | Signalwort / Formulierung | Hinweis | |---|---| | Ablauf zwischen Objekten | Sequenzdiagramm wahrscheinlich | | Nachricht | Kommunikation zwischen Teilnehmern | | Aufruf | Methodenaufruf / Nachricht | | Rückgabe | gestrichelte Antwortlinie | | zeitliche Reihenfolge | von oben nach unten | | Benutzer klickt ... | Start eines Ablaufs | | GUI ruft Service auf | typische Sequenz | | Service fragt Datenbank ab | typische Objektkommunikation | | „stellen Sie den Nachrichtenaustausch dar“ | Sequenzdiagramm | --- **Grundidee** Ein Sequenzdiagramm zeigt einen konkreten Ablauf als Szenario. Beispiel: ```text 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: ```text Benutzer loginGUI:LoginGUI loginService:LoginService userRepository:UserRepository ``` --- **Teilnehmer / Objekte** Teilnehmer stehen im Sequenzdiagramm oben. Beispiele: ```text Benutzer loginGUI:LoginGUI loginService:LoginService userRepository:UserRepository ``` Wichtig: ```text Ein echter Benutzer kann als Akteur dargestellt werden. Objekte werden häufig als instanz:Klasse geschrieben. ``` Beispiele: ```text loginGUI:LoginGUI loginService:LoginService userRepository:UserRepository ``` --- **Lebenslinie** Unter jedem Teilnehmer verläuft eine Lebenslinie nach unten. Darstellung: ```text Teilnehmer | | | ``` In UML wird die Lebenslinie meistens gestrichelt dargestellt. Merksatz: ```text Lebenslinie = zeigt, dass ein Teilnehmer während des Ablaufs existiert. ``` --- **Zeitliche Reihenfolge** Ein Sequenzdiagramm wird von oben nach unten gelesen. ```text oben = früher unten = später ``` Merksatz: ```text 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: ```text loginGUI → loginService: pruefeLogin(name, passwort) ``` Typisch im Diagramm: ```text durchgezogene Linie mit Pfeilspitze ``` Beispiele: ```text loginDatenEingeben(name, passwort) pruefeLogin(name, passwort) findeBenutzer(name) ``` --- **Rückgabe** Eine Rückgabe zeigt das Ergebnis eines Aufrufs. Beispiel: ```text userRepository --> loginService: benutzer ``` Typisch: ```text gestrichelte Linie zurück ``` Beispiele: ```text benutzer loginStatus dashboardDaten benutzerKontext ``` Wichtig: ```text Rückgaben sind oft optional, aber in Lern- und Prüfungsdiagrammen sehr hilfreich. ``` --- **Aktivierungsbalken** Ein Aktivierungsbalken zeigt, dass ein Teilnehmer gerade aktiv ist. Beispiel: ```text loginService prüft gerade die Login-Daten. userRepository sucht gerade den Benutzer. ``` Darstellung: ```text schmaler senkrechter Balken auf der Lebenslinie ``` Merksatz: ```text Aktivierungsbalken = Teilnehmer verarbeitet gerade etwas. ``` --- **Grafik 2: Beispiel – Login prüfen** ![UML-Sequenzdiagramm – Beispiel Login prüfen](https://trainer.ulrich-wiki.com/assets/uml-sequenzdiagramm-beispiel-login.svg?v=5) Diese Grafik zeigt einen Login-Ablauf. Beteiligte Teilnehmer: ```text Benutzer loginGUI:LoginGUI loginService:LoginService userRepository:UserRepository dashboard:Dashboard ``` Ablauf: ```text 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: ```text Prozess A: Dashboard laden Prozess B: Benutzerkontext laden ``` Wichtig: ```text Parallel bedeutet: Die Prozesse müssen nicht streng nacheinander ablaufen. Sie können gleichzeitig oder unabhängig voneinander gestartet werden. ``` Merksatz: ```text Parallele Linien = paralleler Ablaufbereich ``` --- **Beispiel als Textablauf** Aufgabe: ```text 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: ```text 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** | Sequenzdiagramm | Aktivitätsdiagramm | |---|---| | zeigt Kommunikation zwischen Teilnehmern | zeigt Ablauf von Aktionen | | Teilnehmer oben | Start/Aktion/Entscheidung | | Lebenslinien | Kontrollfluss-Pfeile | | Nachrichten zwischen Objekten | Prozessschritte | | gut für Methodenaufrufe | gut für Geschäftsabläufe | | Zeit von oben nach unten | Ablauf meist entlang der Pfeile | Merksatz: ```text Sequenzdiagramm = Wer ruft wen wann auf? Aktivitätsdiagramm = Was passiert als nächstes? ``` --- **Sequenzdiagramm vs. Klassendiagramm** | Sequenzdiagramm | Klassendiagramm | |---|---| | dynamischer Ablauf | statische Struktur | | zeigt Nachrichten | zeigt Klassen | | zeigt Reihenfolge | zeigt Attribute und Methoden | | konkretes Szenario | allgemeines Modell | Merksatz: ```text Klassendiagramm = Bauplan Sequenzdiagramm = Ablauf zwischen den Bauteilen ``` --- **Typische IHK-Fehler** | Fehler | Warum problematisch? | |---|---| | Lebenslinien vergessen | Teilnehmer existieren im Ablauf nicht sichtbar | | Pfeile in falscher Reihenfolge | Ablauf wird falsch gelesen | | Rückgaben als normale Aufrufe gezeichnet | Ergebnis wirkt wie neuer Methodenaufruf | | Teilnehmer und Klassen verwechselt | Sequenzdiagramm zeigt konkrete Beteiligte | | zu viele technische Details | Diagramm wird unübersichtlich | | Zeitachse falsch verstanden | oben passiert vor unten | | parallele Prozesse nicht markiert | Gleichzeitigkeit wird nicht sichtbar | | Pfeile überlagern sich | Diagramm wird schlecht lesbar | --- **Vorgehensweise in der Prüfung** Wenn du ein Sequenzdiagramm erstellen sollst, gehe so vor: | Schritt | Frage | |---|---| | 1 | Welcher konkrete Ablauf wird beschrieben? | | 2 | Welche Teilnehmer oder Objekte sind beteiligt? | | 3 | Wer startet den Ablauf? | | 4 | Welche Nachricht kommt zuerst? | | 5 | Wer ruft wen auf? | | 6 | Welche Rückgaben gibt es? | | 7 | Gibt es parallele Abläufe? | | 8 | Ist die Reihenfolge von oben nach unten korrekt? | | 9 | Sind die Pfeile und Beschriftungen lesbar? | --- **Prüfungs-Merksätze** ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text Nach dem Login werden Dashboarddaten und Benutzerdaten parallel geladen. ``` Lösungsidee: ```text parallel: GUI → DashboardService: ladeDashboard() DashboardService --> GUI: dashboardDaten GUI → BenutzerService: ladeBenutzerDaten() BenutzerService --> GUI: benutzerDaten ``` Merksatz: ```text Wenn zwei Abläufe unabhängig voneinander starten können, kann ein paralleler Bereich sinnvoll sein. ``` --- **Mini-Testfragen**
1. Wofür verwendet man ein UML-Sequenzdiagramm? Man verwendet es, um den zeitlichen Nachrichtenaustausch zwischen Teilnehmern oder Objekten darzustellen. Merksatz: ```text Wer ruft wen wann auf? ```
2. Wie liest man ein Sequenzdiagramm? Von oben nach unten. ```text oben = früher unten = später ```
3. Was ist eine Lebenslinie? Eine Lebenslinie ist die gestrichelte Linie unter einem Teilnehmer. Sie zeigt, dass der Teilnehmer während des Ablaufs existiert.
4. Was zeigt ein Aktivierungsbalken? Ein Aktivierungsbalken zeigt, dass ein Teilnehmer gerade aktiv ist oder etwas verarbeitet.
5. Wie werden Rückgaben typischerweise dargestellt? Rückgaben werden meistens als gestrichelte Pfeile zurück dargestellt. Beispiel: ```text userRepository --> loginService: benutzer ```
6. Was ist der Unterschied zwischen Nachricht und Rückgabe? Eine Nachricht ruft eine Aktion oder Methode auf. Eine Rückgabe liefert ein Ergebnis zurück. ```text Nachricht = Aufruf Rückgabe = Ergebnis ```
7. Was bedeutet „Zeit läuft von oben nach unten“? Nachrichten weiter oben passieren früher. Nachrichten weiter unten passieren später.
8. Was zeigt ein paralleler Bereich? Ein paralleler Bereich zeigt, dass mehrere Prozesse unabhängig oder gleichzeitig ablaufen können. Beispiel: ```text Dashboard laden Benutzerkontext laden ```
9. Warum sollte man Pfeile nicht überlagern? Weil das Diagramm sonst schwer lesbar wird und die Reihenfolge oder Zuordnung der Nachrichten unklar werden kann.
10. Was ist ein typischer Fehler im Sequenzdiagramm? Ein typischer Fehler ist, die zeitliche Reihenfolge falsch darzustellen. Wichtig: ```text Der Ablauf wird von oben nach unten gelesen. ```
--- **Nächste Seite** Danach kommt die eigene Trainer-Seite: ```text UML-Sequenzdiagramm-Trainer ``` Dort übst du: ```text 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: ```text UML-Sequenzdiagramm ``` Hier übst du, aus einer Aufgabenbeschreibung ein korrektes UML-Sequenzdiagramm abzuleiten. Im Fokus stehen: ```text Teilnehmer Lebenslinien Nachrichten Rückgaben Reihenfolge Aktivierungsbalken parallele Prozessbereiche ``` --- **Was wird trainiert?** | Bereich | Bedeutung | |---|---| | **Teilnehmer erkennen** | beteiligte Akteure, Objekte oder Systemteile | | **Lebenslinien verstehen** | gestrichelte Linien unter den Teilnehmern | | **Nachrichten eintragen** | durchgezogene Pfeile als Aufrufe | | **Rückgaben unterscheiden** | gestrichelte Pfeile als Antworten | | **Reihenfolge prüfen** | Ablauf wird von oben nach unten gelesen | | **Parallelbereich erkennen** | zwei parallele Linien markieren parallele Abläufe | | **Beschriftungen sauber setzen** | Methodenaufrufe und Rückgaben eindeutig benennen | --- **Interaktiver UML-Sequenzdiagramm-Trainer** --- **Merksatz für den Trainer** ```text 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: ```text 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: ```text Du sollst erkennen: Hier laufen zwei Prozesse parallel oder unabhängig voneinander ab. ``` --- **Beispiel: Login prüfen** Aufgabenstellung: ```text 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: ```text Teilnehmer: Benutzer loginGUI:LoginGUI loginService:LoginService userRepository:UserRepository dashboard:Dashboard ``` Ablauf: ```text Benutzer → loginGUI: loginDatenEingeben(name, passwort) loginGUI → loginService: pruefeLogin(name, passwort) loginService → userRepository: findeBenutzer(name) userRepository --> loginService: benutzer loginService --> loginGUI: loginStatus ``` Parallelbereich: ```text Prozess A: loginGUI → dashboard: ladeDashboard() dashboard --> loginGUI: dashboardDaten Prozess B: loginGUI → loginService: ladeBenutzerKontext() loginService --> loginGUI: benutzerKontext ``` Abschluss: ```text loginGUI → Benutzer: startseiteAnzeigen() ``` --- **Nachricht oder Rückgabe?** | Darstellung | Bedeutung | |---|---| | **durchgezogener Pfeil** | Aufruf / Nachricht | | **gestrichelter Pfeil** | Rückgabe / Antwort | | **senkrechte gestrichelte Linie** | Lebenslinie | | **schmaler Balken auf Lebenslinie** | Aktivierungsbalken | | **zwei parallele Linien** | paralleler Ablaufbereich | --- **Teilnehmer richtig benennen** Ein Teilnehmer kann ein Akteur oder ein Objekt sein. Beispiele: ```text Benutzer loginGUI:LoginGUI loginService:LoginService userRepository:UserRepository dashboard:Dashboard ``` Wichtig: ```text Benutzer = Akteur loginGUI:LoginGUI = Objekt / Instanz mit Klasse ``` --- **Warum steht die Zeit von oben nach unten?** Ein Sequenzdiagramm wird vertikal gelesen. ```text oben = früher unten = später ``` Das bedeutet: ```text Die erste Nachricht steht oben. Spätere Nachrichten stehen weiter unten. ``` --- **Typische Fehler im Sequenzdiagramm** | Fehler | Warum falsch? | |---|---| | Teilnehmer fehlen | unklar, wer beteiligt ist | | Lebenslinien fehlen | Ablauf ist nicht als Sequenzdiagramm erkennbar | | Rückgaben als normale Nachrichten gezeichnet | Antwort wirkt wie neuer Aufruf | | Nachrichten in falscher Reihenfolge | Ablauf wird fachlich falsch | | Pfeile überlagern sich | Diagramm ist schlecht lesbar | | paralleler Bereich nicht markiert | Gleichzeitigkeit wird nicht sichtbar | | zu lange Texte auf Pfeilen | Diagramm wird unübersichtlich | | Klassen statt konkreter Teilnehmer falsch verwendet | Sequenzdiagramm zeigt konkrete Kommunikation | --- **Mini-Testfragen**
1. Wofür verwendet man ein UML-Sequenzdiagramm? Ein Sequenzdiagramm zeigt den zeitlichen Nachrichtenaustausch zwischen Teilnehmern oder Objekten. Merksatz: ```text Wer ruft wen wann auf? ```
2. Wie liest man ein Sequenzdiagramm? Von oben nach unten. ```text oben = früher unten = später ```
3. Was ist eine Lebenslinie? Eine Lebenslinie ist die gestrichelte senkrechte Linie unter einem Teilnehmer. Sie zeigt, dass der Teilnehmer während des Ablaufs existiert.
4. Wie wird eine normale Nachricht dargestellt? Als durchgezogener Pfeil zwischen zwei Teilnehmern. Beispiel: ```text loginGUI → loginService: pruefeLogin() ```
5. Wie wird eine Rückgabe dargestellt? Als gestrichelter Pfeil zurück. Beispiel: ```text loginService --> loginGUI: loginStatus ```
6. Was zeigt ein Aktivierungsbalken? Ein Aktivierungsbalken zeigt, dass ein Teilnehmer gerade aktiv ist oder etwas verarbeitet.
7. Was bedeuten zwei parallele Linien in unserem Trainer? Sie markieren einen parallelen Ablaufbereich. Das bedeutet: ```text Mehrere Prozesse können parallel oder unabhängig voneinander ablaufen. ```
8. Was ist der Unterschied zwischen Nachricht und Rückgabe? Eine Nachricht ruft etwas auf. Eine Rückgabe liefert ein Ergebnis zurück. ```text Nachricht = Aufruf Rückgabe = Antwort / Ergebnis ```
9. Warum dürfen Pfeile und Texte nicht überlappen? Weil sonst unklar wird, welcher Pfeil zu welcher Nachricht gehört. Ein Sequenzdiagramm muss sauber lesbar bleiben.
10. Was ist ein typischer IHK-Fehler? Ein häufiger Fehler ist, die zeitliche Reihenfolge falsch darzustellen. Wichtig: ```text Die Reihenfolge ergibt sich von oben nach unten. ```
--- **Nächste Seite** Danach geht es weiter mit: ```text 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: ```text 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: ```text 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** ![Mock-up – Grundlagen](https://trainer.ulrich-wiki.com/assets/mockup-grundlagen.svg?v=1) Diese Grafik zeigt die wichtigsten Bestandteile eines Mock-ups: ```text 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: ```text 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: ```text 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: | Signalwort / Formulierung | Hinweis | |---|---| | Benutzeroberfläche | Mock-up wahrscheinlich | | Oberfläche entwerfen | visuelle Darstellung gefragt | | Formular | Eingabefelder und Buttons | | Eingabemaske | UI-Entwurf | | Dialogfenster | Mock-up / GUI-Skizze | | Benutzerführung | Bedienlogik der Oberfläche | | Wireframe | einfache Mock-up-Form | | Entwurf | noch keine fertige Anwendung | | Skizzieren Sie die Maske | Mock-up-Aufgabe | | Fehlermeldung anzeigen | UI-Element berücksichtigen | --- **Grundidee** Ein Mock-up ist ein visueller Entwurf. Es zeigt nicht: ```text Java-Code SQL-Code Methodenaufrufe Datenbankstruktur UML-Beziehungen ``` Sondern es zeigt: ```text Oberflächenaufbau Felder Buttons Navigation Meldungen Anordnung Bedienbarkeit ``` Merksatz: ```text Mock-up = Wie sieht die Oberfläche für den Benutzer aus? ``` --- **Grafik 2: Beispiel – Produktformular** ![Mock-up – Beispiel Produktformular](https://trainer.ulrich-wiki.com/assets/mockup-beispiel-produktformular.svg?v=1) Diese Grafik zeigt ein typisches Mock-up für eine Produktverwaltung. Enthalten sind: ```text 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** | Bestandteil | Bedeutung | |---|---| | **Titel** | zeigt, worum es in der Oberfläche geht | | **Navigation** | Benutzer findet wichtige Bereiche | | **Eingabefelder** | Benutzer kann Daten eingeben | | **Pflichtfelder** | wichtige Eingaben werden markiert | | **Buttons** | Benutzer kann Aktionen auslösen | | **Fehlermeldungen** | Benutzer erkennt Probleme | | **Rückmeldung** | Benutzer sieht, ob etwas geklappt hat | | **Abbrechen / Zurück** | Benutzer kann die Aktion verlassen | | **klare Beschriftungen** | Benutzer versteht die Oberfläche | --- **Pflichtfelder** Pflichtfelder sind Felder, die ausgefüllt werden müssen. Typische Markierung: ```text Produktname * Preis * Kategorie * ``` Das `*` bedeutet: ```text Dieses Feld muss ausgefüllt werden. ``` Wichtig: ```text Pflichtfelder sollten klar erkennbar sein. ``` --- **Validierung und Fehlermeldungen** Validierung bedeutet: ```text Das System prüft, ob die Eingabe gültig ist. ``` Beispiele: ```text 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: ```text Preis * [ 0,00 € ] Preis muss größer als 0 sein. ``` Merksatz: ```text Fehlermeldung direkt dort anzeigen, wo der Fehler entsteht. ``` --- **Buttons** Buttons lösen Aktionen aus. Typische Buttons: | Button | Bedeutung | |---|---| | **Speichern** | Eingaben übernehmen | | **Abbrechen** | Vorgang verlassen | | **Zurück zur Liste** | zur Übersicht zurückkehren | | **Neu** | neuen Datensatz anlegen | | **Bearbeiten** | vorhandenen Datensatz ändern | | **Löschen** | Datensatz entfernen | Wichtig: ```text Buttons sollten eindeutig beschriftet sein. ``` Nicht ideal: ```text OK Weiter Klick Button 1 ``` Besser: ```text Speichern Abbrechen Zurück zur Liste Produkt löschen ``` --- **Benutzerführung** Benutzerführung bedeutet: ```text Der Benutzer erkennt, was er tun soll. ``` Eine gute Oberfläche hilft dem Benutzer durch: ```text klare Überschriften verständliche Feldnamen sinnvolle Reihenfolge der Felder sichtbare Pflichtfelder verständliche Fehlertexte logische Buttons Rückweg zur Übersicht ``` Merksatz: ```text Der Benutzer soll nicht raten müssen. ``` --- **Mock-up vs. UML-Diagramme** | Mock-up | UML-Diagramm | |---|---| | zeigt Oberfläche | zeigt Struktur oder Ablauf | | visuelle UI-Planung | Modellierung | | Felder, Buttons, Navigation | Klassen, Objekte, Prozesse | | Benutzerbedienung | Systemlogik | | nicht zwingend formal | UML hat festere Notation | Merksatz: ```text Mock-up = Oberfläche UML = Modell ``` --- **Mock-up vs. ERM** | Mock-up | ERM | |---|---| | zeigt Eingabemaske | zeigt Datenmodell | | Benutzer sieht Felder | Entwickler sieht Entitäten | | Beispiel: Produktformular | Beispiel: Produkt-Entität | | Oberfläche | Datenstruktur | Beispiel: ```text Mock-up-Feld: Produktname ERM-Attribut: produktname ``` --- **Mock-up vs. Aktivitätsdiagramm** | Mock-up | Aktivitätsdiagramm | |---|---| | zeigt Oberfläche | zeigt Ablauf | | Benutzer klickt Speichern | Ablauf nach dem Klick | | Felder und Buttons | Aktionen und Entscheidungen | | statische Ansicht | Prozesslogik | Beispiel: ```text 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: | Schritt | Frage | |---|---| | 1 | Welche Aufgabe soll die Oberfläche erfüllen? | | 2 | Wer benutzt die Oberfläche? | | 3 | Welche Daten müssen eingegeben werden? | | 4 | Welche Felder sind Pflichtfelder? | | 5 | Welche Buttons braucht der Benutzer? | | 6 | Welche Fehlermeldungen können auftreten? | | 7 | Wie kommt der Benutzer zurück oder weiter? | | 8 | Ist die Oberfläche übersichtlich? | | 9 | Sind Beschriftungen eindeutig? | --- **Typische IHK-Fehler** | Fehler | Warum problematisch? | |---|---| | Pflichtfelder nicht markiert | Benutzer weiß nicht, was nötig ist | | Fehlermeldung fehlt | Benutzer versteht den Fehler nicht | | Fehlermeldung an falscher Stelle | Fehler ist schwer zuzuordnen | | Buttons unklar beschriftet | Benutzer weiß nicht, was passiert | | kein Abbrechen / Zurück | Benutzer steckt fest | | zu viele Elemente auf einmal | Oberfläche wirkt unübersichtlich | | Felder ohne Beschriftung | Bedeutung ist unklar | | Oberfläche passt nicht zur Aufgabe | Anforderungen werden nicht erfüllt | --- **Prüfungs-Merksätze** ```text 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: ```text Entwerfen Sie eine Eingabemaske zum Anlegen eines Produkts. ``` Wichtige Elemente: ```text Produktname * Kategorie * Preis * Lagerbestand Aktiv-Checkbox Speichern Abbrechen Fehlermeldung bei ungültigem Preis ``` --- **Mini-Beispiel 2** Aufgabe: ```text Ein Benutzer soll sich anmelden können. ``` Wichtige Elemente: ```text Benutzername / E-Mail Passwort Anmelden-Button Passwort vergessen Fehlermeldung bei falschen Zugangsdaten ``` --- **Mini-Beispiel 3** Aufgabe: ```text Ein Kunde soll eine Bestellung abschließen können. ``` Wichtige Elemente: ```text Warenkorbübersicht Lieferadresse Zahlungsart AGB-Checkbox Bestellung abschließen Zurück zum Warenkorb Fehlermeldung bei fehlender Zahlungsart ``` --- **Mini-Testfragen**
1. Was ist ein Mock-up? Ein Mock-up ist ein visueller Entwurf einer Benutzeroberfläche. Es zeigt, wie die Oberfläche aussehen und bedient werden soll.
2. Ist ein Mock-up ein UML-Diagramm? Nein. Ein Mock-up ist kein UML-Diagramm. Es ist ein Oberflächenentwurf.
3. Was zeigt ein Mock-up typischerweise? Ein Mock-up zeigt zum Beispiel: ```text Felder Buttons Navigation Fehlermeldungen Layout Benutzerführung ```
4. Was bedeutet ein Sternchen `*` an einem Feld? Das Sternchen zeigt ein Pflichtfeld. Beispiel: ```text Preis * ``` Der Preis muss eingegeben werden.
5. Wo sollte eine Fehlermeldung stehen? Möglichst nah am betroffenen Feld. Beispiel: ```text Preis muss größer als 0 sein. ``` direkt unter dem Preisfeld.
6. Warum sind eindeutige Buttons wichtig? Weil der Benutzer erkennen muss, welche Aktion ausgelöst wird. Besser: ```text Speichern Abbrechen Zurück zur Liste ``` statt: ```text OK Weiter Button 1 ```
7. Was ist Benutzerführung? Benutzerführung bedeutet, dass die Oberfläche dem Benutzer klar zeigt, was er tun soll. Dazu gehören: ```text klare Beschriftungen sinnvolle Reihenfolge Fehlermeldungen Rückwege ```
8. Was ist der Unterschied zwischen Mock-up und Aktivitätsdiagramm? Ein Mock-up zeigt die Oberfläche. Ein Aktivitätsdiagramm zeigt den Ablauf. Beispiel: ```text Mock-up: Speichern-Button Aktivitätsdiagramm: Eingabe prüfen → speichern ```
9. Muss ein Mock-up programmierbar oder funktionsfähig sein? Nein. Ein Mock-up muss nicht funktionieren. Es zeigt die geplante Oberfläche.
10. Was ist ein häufiger Fehler bei Mock-ups? Ein häufiger Fehler ist, dass Pflichtfelder, Fehlermeldungen oder wichtige Buttons fehlen. Dadurch versteht der Benutzer die Oberfläche schlechter.
--- **Nächste Seite** Danach kommt die eigene Trainer-Seite: ```text Mock-up-Trainer ``` Dort übst du: ```text 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: ```text Mock-up / Benutzeroberflächen-Entwurf ``` Hier übst du, aus einer Aufgabenbeschreibung die wichtigsten Elemente einer Benutzeroberfläche abzuleiten. Im Fokus stehen: ```text Pflichtfelder Fehlermeldungen Validierung Buttons Hauptaktion Nebenaktion Benutzerführung Mock-up ≠ UML-Diagramm ``` --- **Was wird trainiert?** | Bereich | Bedeutung | |---|---| | **Pflichtfelder erkennen** | wichtige Felder mit `*` markieren | | **Fehlermeldungen platzieren** | Fehler direkt am betroffenen Feld anzeigen | | **Validierung verstehen** | Eingaben fachlich prüfen | | **Hauptaktion erkennen** | wichtigste Aktion, z. B. Speichern oder Anmelden | | **Nebenaktionen erkennen** | Abbrechen, Zurück, Zurück zur Liste | | **Benutzerführung bewerten** | Oberfläche soll verständlich und logisch sein | | **Mock-up einordnen** | Mock-up ist kein UML-Diagramm | --- **Interaktiver Mock-up-Trainer** --- **Merksatz für den Trainer** ```text 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: ```text 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: ```text 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: ```text 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: ```text Produktname * Kategorie * Preis * ``` Das Sternchen `*` zeigt: ```text Dieses Feld ist erforderlich. ``` --- **Fehlermeldungen** Fehlermeldungen sollten möglichst direkt beim betroffenen Feld stehen. Gut: ```text Preis * [ 0,00 € ] Preis muss größer als 0 sein. ``` Schlecht: ```text Irgendwo oben steht nur: Fehler. ``` Merksatz: ```text Der Benutzer muss sofort erkennen, was falsch ist und wo er es korrigieren muss. ``` --- **Validierung** Validierung bedeutet: ```text Das System prüft, ob die Eingabe gültig ist. ``` Beispiele: ```text 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: ```text Speichern Anmelden Bestellung abschließen Absenden ``` Im Produktformular ist die Hauptaktion: ```text Speichern ``` --- **Nebenaktionen** Nebenaktionen helfen dem Benutzer, den Vorgang zu verlassen oder zurückzugehen. Beispiele: ```text Abbrechen Zurück zur Liste Zurück zum Warenkorb Schließen ``` Wichtig: ```text 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: ```text Klassen Methoden Kardinalitäten Sequenzen Kontrollflüsse Datenbankbeziehungen ``` Dafür gibt es andere Diagramme. Merksatz: ```text Mock-up = Oberfläche UML = Modellierung ``` --- **Typische Fehler im Mock-up** | Fehler | Warum problematisch? | |---|---| | Pflichtfelder fehlen | Benutzer weiß nicht, was zwingend ist | | Fehlermeldung fehlt | Benutzer versteht den Fehler nicht | | Fehlermeldung steht zu weit weg | Fehler ist schwer zuzuordnen | | Button heißt nur „OK“ | Aktion ist nicht eindeutig | | Kein Abbrechen-Button | Benutzer kann Vorgang schlecht verlassen | | Kein Rückweg | Benutzerführung ist unvollständig | | Zu viele Elemente | Oberfläche wird unübersichtlich | | Technische Begriffe | Benutzer versteht die Oberfläche schlechter | --- **Mini-Testfragen**
1. Was trainiert dieser Mock-up-Trainer? Er trainiert das Erkennen wichtiger UI-Elemente: ```text Pflichtfelder Fehlermeldungen Validierung Buttons Benutzerführung ```
2. Was bedeutet ein Sternchen `*` an einem Feld? Das Sternchen bedeutet: ```text Pflichtfeld ``` Das Feld muss ausgefüllt werden.
3. Wo sollte eine Fehlermeldung stehen? Möglichst direkt am betroffenen Feld. Beispiel: ```text Preis muss größer als 0 sein. ``` direkt beim Preisfeld.
4. Was ist die Hauptaktion im Produktformular? Die Hauptaktion ist: ```text Speichern ```
5. Welche Nebenaktionen sind sinnvoll? Zum Beispiel: ```text Abbrechen Zurück zur Liste ```
6. Was bedeutet Validierung? Validierung bedeutet: ```text Das System prüft, ob eine Eingabe gültig ist. ``` Beispiel: ```text Preis muss größer als 0 sein. ```
7. Ist ein Mock-up ein UML-Diagramm? Nein. Ein Mock-up ist ein Oberflächenentwurf und kein UML-Diagramm.
8. Was zeigt ein Mock-up nicht? Ein Mock-up zeigt nicht: ```text Programmcode Datenbankbeziehungen Klassendiagramme Sequenzdiagramme Kontrollflüsse ```
9. Warum sind eindeutige Buttons wichtig? Weil der Benutzer erkennen muss, welche Aktion passiert. Besser: ```text Speichern Abbrechen Zurück zur Liste ``` statt: ```text OK Weiter Button 1 ```
10. Was ist Benutzerführung? Benutzerführung bedeutet: ```text Die Oberfläche zeigt dem Benutzer klar, was er tun soll. ``` Dazu gehören: ```text verständliche Feldnamen sichtbare Pflichtfelder klare Buttons Fehlermeldungen Rückwege ```
--- **Nächste Seite** Danach geht es weiter mit: ```text UML-Zustandsdiagramm ```