Programmiertechnik 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: 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 Diese Grafik zeigt dir die wichtigsten Bausteine des ERM auf einen Blick: Entität Attribut Beziehung Kardinalität die wichtigsten Kardinalitäten 1:1, 1:n und n:m typische Signalwörter , an denen du in einer IHK-Aufgabe erkennst, dass ein ERM gemeint ist Wofür braucht man ein ERM? Ein ERM hilft dir, aus einer fachlichen Beschreibung ein Datenmodell zu bauen. Beispiel: Ein Kunde kann mehrere Bestellungen aufgeben. Eine Bestellung gehört immer zu genau einem Kunden. Eine Bestellung enthält mehrere Produkte. Ein Produkt kann in mehreren Bestellungen enthalten sein. Daraus erkennt man: Es gibt Datenobjekte. Diese Datenobjekte haben Eigenschaften. Diese Datenobjekte stehen miteinander in Beziehung. Manche Beziehungen haben bestimmte Anzahlen, zum Beispiel 1:n oder n:m . Genau dafür ist ein ERM da. Woran erkenne ich in einer Aufgabe, dass ein ERM gemeint ist? Typische Signalwörter: 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: Ein Kunde bestellt ein Produkt. Mögliche Entitäten: Kunde Produkt Bestellung Attribut Ein Attribut ist eine Eigenschaft einer Entität. Beispiel Entität Kunde : 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: kunden_id produkt_id bestellung_id Warum braucht man Primärschlüssel? Weil Namen nicht eindeutig sein müssen. Beispiel: Es kann mehrere Kunden mit dem Namen Müller geben. Aber: kunden_id = 1001 ist eindeutig. Merksatz: Jede Entität braucht einen eindeutigen Primärschlüssel. Beziehung Eine Beziehung beschreibt, wie zwei Entitäten zusammenhängen. Beispiel: Kunde gibt Bestellung auf Entitäten: Kunde Bestellung Beziehung: gibt auf Darstellung als einfache Textform: Kunde -- gibt auf -- Bestellung Weitere Beispiele: 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 Diese Grafik zeigt ein typisches vollständiges ERM-Beispiel: Kunde gibt Bestellung auf → 1:n Bestellung enthält Produkt → fachlich n:m Die n:m-Beziehung wird durch Bestellposition aufgelöst Dadurch entstehen später sauberere Tabellen für die Datenbank 1:1-Beziehung Beispiel: Eine Person hat genau einen Personalausweis. Ein Personalausweis gehört genau zu einer Person. Darstellung: Person 1 --- 1 Personalausweis Das ist eine 1:1-Beziehung . 1:n-Beziehung Beispiel: Ein Kunde kann mehrere Bestellungen haben. Eine Bestellung gehört genau zu einem Kunden. Darstellung: Kunde 1 --- n Bestellung Das ist eine 1:n-Beziehung . Merksatz: Wenn ein Objekt mehrere andere haben kann, ist es meistens 1:n. n:m-Beziehung Beispiel: Eine Bestellung kann mehrere Produkte enthalten. Ein Produkt kann in mehreren Bestellungen vorkommen. Darstellung: Bestellung n --- m Produkt Das ist eine n:m-Beziehung . Wichtig: Eine n:m-Beziehung kann man in einer relationalen Datenbank nicht direkt einfach speichern. Deshalb wird daraus später eine Zwischentabelle . Beispiel: Bestellung Produkt Bestellposition Die Zwischentabelle könnte heißen: Bestellposition Typische Attribute der Zwischentabelle: 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: 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 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: 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: 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: Bestellung n:m Produkt wird zu: Bestellung 1:n Bestellposition n:1 Produkt Nächste Seite Danach kommt die eigene Trainer-Seite: ERM-Trainer Dort bauen wir den interaktiven ERM-Trainer mit Aufgaben zu: Entität erkennen Attribute zuordnen Beziehung bestimmen Kardinalität wählen n:m-Zwischentabelle erkennen Seite 4. ERM-Trainer ERM-Trainer Dieser interaktive Trainer gehört zur Theorie-Seite: ERM – Entity-Relationship-Modell Hier übst du, aus kurzen Aufgabenstellungen die wichtigsten Bestandteile eines ERM zu erkennen: Entität 1 Entität 2 Beziehung Kardinalität Zwischentabelle bei n:m-Beziehungen Was wird trainiert? 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 Entität = wichtiges Datenobjekt Beziehung = Verbindung zwischen Entitäten Kardinalität = Wie viele gehören zusammen? 1:n = einer zu vielen n:m = viele zu vielen n:m = meistens Zwischentabelle nötig Beispiel Aufgabenstellung: Ein Schüler kann mehrere Kurse belegen. Ein Kurs kann von mehreren Schülern belegt werden. Lösung: Feld Lösung Entität 1 Schüler Entität 2 Kurs Beziehung belegt Kardinalität n:m Zwischentabelle Belegung Warum? Viele Schüler können viele Kurse belegen. Deshalb ist es eine n:m-Beziehung. Eine n:m-Beziehung braucht später meistens eine Zwischentabelle. Mini-Testfragen 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: Ein Kunde kann mehrere Bestellungen aufgeben. Mögliche Entitäten: 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: Ein Kunde kann mehrere Bestellungen haben. Eine Bestellung gehört genau zu einem Kunden. Das ist: 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: Ein Schüler kann mehrere Kurse belegen. Ein Kurs kann von mehreren Schülern belegt werden. Das ist: 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: Schüler n:m Kurs wird zu: 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: Belegung - schueler_id - kurs_id - anmeldedatum Nächste Seite Danach geht es weiter mit: Relationales Datenbankmodell Seite 5. Relationales Datenbankmodell Relationales Datenbankmodell Diese Seite erklärt das relationale Datenbankmodell so, dass du es schnell für IHK-Aufgaben anwenden kannst. Das relationale Datenbankmodell beschreibt, wie Daten in Tabellen gespeichert werden. Dabei sind besonders wichtig: Tabellen Datensätze Attribute / Spalten Primärschlüssel Fremdschlüssel Beziehungen zwischen Tabellen Grafik 1: Grundlagen des relationalen Datenbankmodells Diese Grafik zeigt dir die wichtigsten Grundbegriffe: Tabelle Datensatz Primärschlüssel Fremdschlüssel Zusammenhang zwischen Zeilen, Spalten und Schlüsseln Wofür braucht man das relationale Datenbankmodell? Das relationale Datenbankmodell wird benutzt, um ein fachliches Datenmodell technisch näher an eine echte Datenbank zu bringen. Ein ERM zeigt zuerst fachlich: Kunde gibt Bestellung auf Das relationale Modell macht daraus Tabellen: Kunde Bestellung Und legt fest: Welche Spalten gibt es? Was ist der Primärschlüssel? Wo wird ein Fremdschlüssel benötigt? Wie hängen die Tabellen zusammen? Woran erkenne ich in einer Aufgabe, dass ein relationales Datenbankmodell gemeint ist? Typische Signalwörter: 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 : kunden_id name email telefon Diese Spalten beschreiben den Kunden genauer. Merksatz: Attribut im ERM wird meistens zur Spalte in der Tabelle. Primärschlüssel Ein Primärschlüssel identifiziert jeden Datensatz eindeutig. Beispiel: kunden_id produkt_id bestellung_id Warum ist das wichtig? Namen sind nicht eindeutig. Beispiel: Müller kann mehrfach vorkommen. Aber: kunden_id = 1 ist eindeutig. Merksatz: Jede Tabelle sollte einen Primärschlüssel haben. Fremdschlüssel Ein Fremdschlüssel verweist auf den Primärschlüssel einer anderen Tabelle. Beispiel: Tabelle Kunde : 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: kunden_id in der Tabelle Bestellung ein Fremdschlüssel. Warum? Weil er auf die Tabelle Kunde verweist. Bestellung.kunden_id → Kunde.kunden_id Grafik 2: Vom ERM zum relationalen Modell Diese Grafik zeigt: Aus der Entität Kunde wird die Tabelle Kunde Aus der Entität Bestellung wird die Tabelle Bestellung Die 1:n-Beziehung wird durch einen Fremdschlüssel auf der n-Seite abgebildet In der Tabelle Bestellung steht deshalb kunden_id als Fremdschlüssel ERM vs. relationales Datenbankmodell 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: ERM = Was gibt es fachlich? Relationales Modell = Wie wird es tabellarisch gespeichert? Aus Entitäten werden Tabellen Im ERM hast du zum Beispiel: Kunde Bestellung Produkt Im relationalen Modell werden daraus Tabellen: Tabelle Kunde Tabelle Bestellung Tabelle Produkt Beispiel: Entität Kunde wird zu: Kunde(kunden_id, name, email) Aus Attributen werden Spalten ERM: Kunde - kunden_id - name - email Relationales Modell: kunden_id name email Merksatz: Attribute werden im relationalen Modell zu Spalten. 1:1-Beziehung im relationalen Modell Beispiel: Person 1 --- 1 Personalausweis Mögliche Tabellen: Person(person_id, name) Personalausweis(ausweis_id, ausweisnummer, person_id) Hier kann person_id in Personalausweis als Fremdschlüssel gespeichert werden. Wichtig: Bei 1:1 ist fachlich zu prüfen, ob man beide Tabellen wirklich getrennt braucht. 1:n-Beziehung im relationalen Modell Beispiel: Kunde 1 --- n Bestellung Das bedeutet: Ein Kunde kann mehrere Bestellungen haben. Eine Bestellung gehört genau zu einem Kunden. Tabellen: Kunde(kunden_id, name, email) Bestellung(bestellung_id, bestelldatum, kunden_id) Wichtig: Der Fremdschlüssel kommt auf die n-Seite . Also: kunden_id steht in: Bestellung Merksatz: Bei 1:n steht der Fremdschlüssel auf der n-Seite. n:m-Beziehung im relationalen Modell Beispiel: Bestellung n --- m Produkt Das bedeutet: Eine Bestellung kann mehrere Produkte enthalten. Ein Produkt kann in mehreren Bestellungen vorkommen. Eine n:m-Beziehung kann man nicht sauber direkt mit nur einem Fremdschlüssel abbilden. Deshalb braucht man eine Zwischentabelle. Aus: Bestellung n:m Produkt wird: Bestellung 1:n Bestellposition n:1 Produkt Tabellen: Bestellung(bestellung_id, bestelldatum) Produkt(produkt_id, bezeichnung, preis) Bestellposition(bestellung_id, produkt_id, menge) Die Tabelle Bestellposition enthält mindestens: 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: Wie oft wurde ein Produkt bestellt? Welcher Preis galt zum Bestellzeitpunkt? Gab es Rabatt? Diese Informationen gehören nicht nur zur Bestellung und nicht nur zum Produkt. Sie gehören zur Verbindung zwischen Bestellung und Produkt. Deshalb braucht man: Bestellposition Typische Umwandlung von ERM zu relationalem Modell 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: Ein Kunde kann mehrere Bestellungen aufgeben. Eine Bestellung gehört genau zu einem Kunden. ERM: Kunde 1 --- n Bestellung Relationales Modell: Kunde(kunden_id, name, email) Bestellung(bestellung_id, bestelldatum, kunden_id) Erklärung: kunden_id ist Primärschlüssel in Kunde. kunden_id ist Fremdschlüssel in Bestellung. Beispiel: Schüler und Kurs Fachliche Beschreibung: Ein Schüler kann mehrere Kurse belegen. Ein Kurs kann von mehreren Schülern belegt werden. ERM: Schüler n --- m Kurs Relationales Modell: Schüler(schueler_id, vorname, nachname) Kurs(kurs_id, kursname) Belegung(schueler_id, kurs_id, anmeldedatum) Erklärung: Belegung ist die Zwischentabelle. schueler_id ist Fremdschlüssel auf Schüler. kurs_id ist Fremdschlüssel auf Kurs. Primärschlüssel und Fremdschlüssel markieren In der Prüfung kannst du Schlüssel zum Beispiel so kennzeichnen: PK = Primary Key = Primärschlüssel FK = Foreign Key = Fremdschlüssel Beispiel: Kunde( kunden_id PK, name, email ) Bestellung( bestellung_id PK, bestelldatum, kunden_id FK ) Oder kompakt: Kunde(kunden_id PK, name, email) Bestellung(bestellung_id PK, bestelldatum, kunden_id FK) Zusammengesetzter Primärschlüssel Bei Zwischentabellen kann der Primärschlüssel aus mehreren Spalten bestehen. Beispiel: Belegung(schueler_id, kurs_id, anmeldedatum) Hier könnten zusammen den Datensatz eindeutig machen: schueler_id + kurs_id Das nennt man einen zusammengesetzten Primärschlüssel . Alternative: Man kann auch eine eigene ID verwenden: belegung_id Dann sieht die Tabelle so aus: Belegung(belegung_id PK, schueler_id FK, kurs_id FK, anmeldedatum) Beides kann je nach Aufgabenstellung sinnvoll sein. Normalisierung kurz erklärt Normalisierung bedeutet: Daten so strukturieren, dass Wiederholungen und Fehler vermieden werden. Einfach gesagt: Gleiche Informationen sollen nicht unnötig mehrfach gespeichert werden. Schlechtes Beispiel: bestellung_id kundenname kundenemail produkt 1 Müller mueller@example.de Monitor 2 Müller mueller@example.de Tastatur Problem: Kundendaten werden mehrfach gespeichert. Besser: Kunde(kunden_id, name, email) Bestellung(bestellung_id, kunden_id) Dann stehen die Kundendaten nur einmal in der Tabelle Kunde . Vorgehensweise in der Prüfung Wenn du ein relationales Datenbankmodell erstellen sollst, gehe so vor: 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 Tabelle = Sammlung gleichartiger Datensätze Datensatz = eine Tabellenzeile Attribut = Spalte Primärschlüssel = eindeutige ID Fremdschlüssel = Verweis auf andere Tabelle 1:n = Fremdschlüssel auf der n-Seite n:m = Zwischentabelle nötig ERM = fachliche Sicht Relationales Modell = Tabellen- und Schlüssel-Sicht Mini-Beispiel 1 Aufgabe: Ein Kunde kann mehrere Bestellungen haben. Eine Bestellung gehört genau zu einem Kunden. Lösung: Kunde(kunden_id PK, name, email) Bestellung(bestellung_id PK, bestelldatum, kunden_id FK) Begründung: 1:n-Beziehung. Der Fremdschlüssel kunden_id steht auf der n-Seite, also in Bestellung. Mini-Beispiel 2 Aufgabe: Ein Schüler kann mehrere Kurse belegen. Ein Kurs kann von mehreren Schülern belegt werden. Lösung: Schüler(schueler_id PK, vorname, nachname) Kurs(kurs_id PK, kursname) Belegung(schueler_id FK, kurs_id FK, anmeldedatum) Begründung: n:m-Beziehung. Deshalb braucht man eine Zwischentabelle. Mini-Beispiel 3 Aufgabe: Eine Bestellung kann mehrere Produkte enthalten. Ein Produkt kann in mehreren Bestellungen vorkommen. Lösung: Bestellung(bestellung_id PK, bestelldatum) Produkt(produkt_id PK, bezeichnung, preis) Bestellposition(bestellung_id FK, produkt_id FK, menge) Begründung: n:m-Beziehung. Bestellposition löst die Beziehung auf und speichert zusätzlich die Menge. Mini-Testfragen 1. Was ist eine Tabelle? Eine Tabelle speichert gleichartige Datensätze. Beispiel: Kunde Produkt Bestellung 2. Was ist ein Datensatz? Ein Datensatz ist eine einzelne Zeile in einer Tabelle. Beispiel: 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: 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: 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: Kunde 1:n Bestellung Dann steht: kunden_id in der Tabelle: Bestellung 6. Was braucht man bei einer n:m-Beziehung? Eine n:m-Beziehung braucht eine Zwischentabelle . Beispiel: Schüler n:m Kurs wird zu: 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: 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: Informationen möglichst nur einmal speichern. Nächste Seite Danach kommt die eigene Trainer-Seite: Relationales-Datenbankmodell-Trainer Dort bauen wir den interaktiven Trainer mit Aufgaben zu: Tabellen ableiten Primärschlüssel bestimmen Fremdschlüssel richtig platzieren 1:n-Beziehungen umsetzen n:m-Beziehungen mit Zwischentabelle auflösen Seite 6 Relationales-Datenbankmodell-Trainer Dieser interaktive Trainer gehört zur Theorie-Seite: Relationales Datenbankmodell Hier übst du, aus kurzen Aufgabenstellungen ein relationales Datenbankmodell abzuleiten. Im Fokus stehen: Tabellen Primärschlüssel Fremdschlüssel 1:n-Beziehungen n:m-Beziehungen Zwischentabellen Was wird trainiert? 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 Entität im ERM → Tabelle im relationalen Modell Attribut im ERM → Spalte in der Tabelle Primärschlüssel → eindeutige ID einer Tabelle Fremdschlüssel → Verweis auf eine andere Tabelle 1:n-Beziehung → Fremdschlüssel auf der n-Seite n:m-Beziehung → Zwischentabelle mit Fremdschlüsseln Beispiel 1: 1:n-Beziehung Aufgabenstellung: Ein Kunde kann mehrere Bestellungen aufgeben. Eine Bestellung gehört genau zu einem Kunden. Relationales Modell: Kunde(kunden_id PK, name, email) Bestellung(bestellung_id PK, bestelldatum, kunden_id FK) Warum? Kunde 1:n Bestellung Der Fremdschlüssel steht auf der n-Seite. Also steht: kunden_id in der Tabelle: Bestellung Beispiel 2: n:m-Beziehung Aufgabenstellung: Ein Schüler kann mehrere Kurse belegen. Ein Kurs kann von mehreren Schülern belegt werden. Relationales Modell: Schüler(schueler_id PK, vorname, nachname) Kurs(kurs_id PK, kursname) Belegung(schueler_id FK, kurs_id FK, anmeldedatum) Warum? Schüler n:m Kurs Eine n:m-Beziehung braucht eine Zwischentabelle. Hier heißt sie: Belegung Beispiel 3: Bestellung und Produkt Aufgabenstellung: Eine Bestellung kann mehrere Produkte enthalten. Ein Produkt kann in mehreren Bestellungen vorkommen. Relationales Modell: Bestellung(bestellung_id PK, bestelldatum) Produkt(produkt_id PK, bezeichnung, preis) Bestellposition(bestellung_id FK, produkt_id FK, menge) Warum? Bestellung n:m Produkt Die Zwischentabelle Bestellposition löst die n:m-Beziehung auf. Zusätzlich kann dort gespeichert werden: menge einzelpreis rabatt Typische Fehler im Trainer 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: Entität Kunde wird zu: Tabelle Kunde 2. Was wird aus einem Attribut im relationalen Modell? Aus einem Attribut wird meistens eine Spalte . Beispiel: Attribut name wird zu: Spalte name 3. Was ist ein Primärschlüssel? Ein Primärschlüssel identifiziert jeden Datensatz eindeutig. Beispiel: 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: 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: Kunde 1:n Bestellung Dann steht: kunden_id in der Tabelle: Bestellung 6. Was braucht man bei einer n:m-Beziehung? Eine n:m-Beziehung braucht eine Zwischentabelle . Beispiel: Schüler n:m Kurs wird zu: 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: schueler_id FK kurs_id FK Beispiel: 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: menge einzelpreis rabatt 9. Was ist ein zusammengesetzter Primärschlüssel? Ein zusammengesetzter Primärschlüssel besteht aus mehreren Spalten. Beispiel: 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: Schüler n:m Kurs direkt speichern Besser: Schüler 1:n Belegung n:1 Kurs Nächste Seite Danach geht es weiter mit: UML-Klassendiagramm Seite 7. UML-Klassendiagramm UML-Klassendiagramm Diese Seite erklärt das UML-Klassendiagramm so, dass du es schnell für IHK-Aufgaben und Java/OOP-Aufgaben anwenden kannst. Ein UML-Klassendiagramm wird benutzt, um die Struktur eines Programms darzustellen. Es zeigt: Klassen Attribute Methoden Sichtbarkeit Beziehungen zwischen Klassen Vererbung Grafik 1: UML-Klassendiagramm – Grundlagen Diese Grafik zeigt dir die wichtigsten Bausteine eines UML-Klassendiagramms: Klassenname Attribute Methoden Sichtbarkeit mit + , - und # Assoziation Vererbung Wofür braucht man ein UML-Klassendiagramm? Ein UML-Klassendiagramm hilft dir, die Struktur eines objektorientierten Programms zu planen. Beispiel: Es soll eine Produktverwaltung erstellt werden. Ein Produkt hat eine Marke, ein Modell und einen Preis. Monitore und Tastaturen sind spezielle Produkte. Daraus erkennt man: Es gibt Klassen. Klassen haben Attribute. Klassen haben Methoden. Manche Klassen hängen miteinander zusammen. Manche Klassen können von anderen Klassen erben. Woran erkenne ich in einer Aufgabe, dass ein UML-Klassendiagramm gemeint ist? Typische Signalwörter: 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: ┌────────────────────────┐ │ Klassenname │ ├────────────────────────┤ │ Attribute │ ├────────────────────────┤ │ Methoden │ └────────────────────────┘ Beispiel: ┌────────────────────────┐ │ Produkt │ ├────────────────────────┤ │ - marke: String │ │ - modell: String │ │ - preis: double │ ├────────────────────────┤ │ + getPreis(): double │ │ + toString(): String │ └────────────────────────┘ Klassenname Der Klassenname steht oben im Klassendiagramm. Beispiele: Produkt Monitor Tastatur Kunde Bestellung Benutzer Merksatz: Klassennamen werden meistens großgeschrieben und stehen im Singular. Also eher: Produkt nicht: Produkte Attribute Attribute beschreiben die Eigenschaften einer Klasse. Beispiel Klasse Produkt : - marke: String - modell: String - preis: double Das bedeutet: 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: + getPreis(): double + setPreis(preis: double): void + toString(): String Aufbau einer Methode: sichtbarkeit methodenname(parameter): rückgabetyp Beispiel: + 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: + public - private # protected Typisch in Java: private String marke; public String toString() UML: - marke: String + toString(): String Attribute sind meistens private In Java sind Attribute meistens private. Beispiel Java: private String marke; private String modell; private double preis; UML: - marke: String - modell: String - preis: double Warum? Damit nicht jeder direkt von außen auf die Daten zugreifen kann. Das nennt man Kapselung . Methoden sind oft public Methoden, die von außen genutzt werden sollen, sind meistens public. Beispiel Java: public String toString() { return marke + " " + modell; } UML: + toString(): String Grafik 2: Beispiel Produktverwaltung Diese Grafik zeigt ein typisches UML-Klassendiagramm für eine Produktverwaltung: Produkt ist die Oberklasse Monitor ist eine spezielle Produktart Tastatur ist eine spezielle Produktart gemeinsame Attribute gehören in die Oberklasse spezielle Attribute gehören in die Unterklassen Beispiel: Produkt als Oberklasse Wenn mehrere Produktarten gemeinsame Eigenschaften haben, kann man eine Oberklasse verwenden. Beispiel: Produkt - marke - modell - preis Diese Attribute können für viele Produktarten gelten: Monitor Tastatur Maus CPU Deshalb gehören sie in die gemeinsame Oberklasse Produkt . Vererbung Vererbung bedeutet: Eine Unterklasse übernimmt Eigenschaften und Methoden einer Oberklasse. Beispiel: Monitor erbt von Produkt. Tastatur erbt von Produkt. Das bedeutet: Monitor ist ein Produkt. Tastatur ist ein Produkt. UML-Darstellung: Monitor ─────▷ Produkt Tastatur ────▷ Produkt Der Pfeil zeigt zur Oberklasse . Merksatz: Der Vererbungs-Pfeil zeigt immer zur allgemeineren Klasse. Oberklasse und Unterklasse Begriff Bedeutung Beispiel Oberklasse allgemeine Klasse Produkt Unterklasse spezielle Klasse Monitor Vererbung Unterklasse übernimmt von Oberklasse Monitor erbt von Produkt Beispiel: Produkt - marke - modell - preis Monitor - groesseZoll - aufloesung Der Monitor hat dann fachlich: marke modell preis groesseZoll aufloesung Assoziation Eine Assoziation ist eine normale Beziehung zwischen Klassen. Beispiel: Kunde gibt Bestellung auf Als Klassendiagramm: Kunde ───────── Bestellung Eine Assoziation bedeutet: Diese Klassen stehen miteinander in Beziehung. Multiplizität Die Multiplizität zeigt, wie viele Objekte miteinander verbunden sein können. Multiplizität Bedeutung 1 genau eins 0..1 kein oder eins * beliebig viele 1..* mindestens eins 0..* beliebig viele oder keine Beispiel: Kunde 1 ───── 0..* Bestellung Bedeutung: Ein Kunde kann keine, eine oder mehrere Bestellungen haben. Eine Bestellung gehört zu genau einem Kunden. Unterschied Kardinalität und Multiplizität In ERM sagt man oft: 1:n n:m Im UML-Klassendiagramm sieht man eher: 1 0..* 1..* * Beispiel: Kunde 1 ───── 0..* Bestellung entspricht ungefähr: Kunde 1:n Bestellung Aggregation und Komposition kurz erklärt Diese beiden Beziehungen können in UML vorkommen, sind aber für den schnellen IHK-Einstieg nicht immer der Schwerpunkt. 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: Aggregation = hat-Beziehung, Teil kann unabhängig existieren Komposition = besteht-aus-Beziehung, Teil ist stark abhängig Beispiel Aggregation: Team hat Mitarbeiter Ein Mitarbeiter kann auch ohne dieses Team existieren. Beispiel Komposition: Rechnung besteht aus Rechnungspositionen Eine Rechnungsposition ergibt ohne Rechnung meist keinen Sinn. Unterschied Klasse und Objekt Begriff Bedeutung Beispiel Klasse Bauplan Produkt Objekt konkrete Ausprägung Produkt p1 = neuer Monitor Beispiel: Klasse: Produkt Objekt: monitor1 Java: Produkt monitor1 = new Produkt("Dell", "U2723QE", 499.99); Die Klasse beschreibt, welche Attribute und Methoden ein Objekt haben kann. Das Objekt ist eine konkrete Instanz dieser Klasse. UML-Klassendiagramm vs. ERM 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: 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: Es soll eine Produktverwaltung erstellt werden. Jedes Produkt hat eine Marke, ein Modell und einen Preis. Ein Monitor hat zusätzlich eine Größe in Zoll und eine Auflösung. Eine Tastatur hat zusätzlich ein Layout und die Information, ob sie mechanisch ist. Mögliche Klassen: Produkt Monitor Tastatur Oberklasse: Produkt Unterklassen: Monitor Tastatur Warum? Monitor ist ein Produkt. Tastatur ist ein Produkt. Mögliches Klassendiagramm als Text Produkt -------------------------------- - marke: String - modell: String - preis: double -------------------------------- + toString(): String Monitor extends Produkt -------------------------------- - groesseZoll: double - aufloesung: String -------------------------------- + toString(): String Tastatur extends Produkt -------------------------------- - layout: String - mechanisch: boolean -------------------------------- + toString(): String Typische IHK-Fehler beim UML-Klassendiagramm 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 Klasse = Bauplan für Objekte Objekt = konkrete Instanz einer Klasse Attribut = gespeicherte Eigenschaft Methode = Verhalten / Funktion + = public - = private # = protected Vererbungspfeil zeigt zur Oberklasse Gemeinsame Attribute gehören in die Oberklasse Spezielle Attribute gehören in die Unterklasse ERM zeigt Daten, Klassendiagramm zeigt Programmstruktur Mini-Beispiel 1 Aufgabe: Ein Produkt hat eine Marke, ein Modell und einen Preis. Lösung: Produkt -------------------------------- - marke: String - modell: String - preis: double Begründung: marke, modell und preis sind Eigenschaften eines Produkts. Deshalb sind sie Attribute. Mini-Beispiel 2 Aufgabe: Ein Monitor ist ein Produkt und hat zusätzlich eine Größe in Zoll. Lösung: Monitor erbt von Produkt. Monitor -------------------------------- - groesseZoll: double Begründung: Monitor ist eine spezielle Produktart. Deshalb ist Vererbung sinnvoll. Mini-Beispiel 3 Aufgabe: Ein Kunde kann mehrere Bestellungen haben. Mögliches UML-Klassendiagramm: Kunde 1 ───── 0..* Bestellung Begründung: Ein Kunde kann mehrere Bestellungen haben. Eine Bestellung gehört zu einem Kunden. Mini-Testfragen 1. Wofür wird ein UML-Klassendiagramm verwendet? Ein UML-Klassendiagramm wird verwendet, um die Struktur eines objektorientierten Programms darzustellen. Es zeigt: Klassen Attribute Methoden Beziehungen Vererbung 2. Was ist eine Klasse? Eine Klasse ist ein Bauplan für Objekte. Beispiel: Produkt Monitor Tastatur 3. Was ist ein Attribut? Ein Attribut ist eine gespeicherte Eigenschaft einer Klasse. Beispiel: - marke: String - preis: double 4. Was ist eine Methode? Eine Methode beschreibt ein Verhalten oder eine Funktion einer Klasse. Beispiel: + toString(): String + getPreis(): double 5. Was bedeutet `+` im UML-Klassendiagramm? + bedeutet: public / öffentlich Das Element ist von außen zugreifbar. 6. Was bedeutet `-` im UML-Klassendiagramm? - bedeutet: private / privat Das Element ist nur innerhalb der Klasse direkt zugreifbar. 7. In welche Richtung zeigt der Vererbungspfeil? Der Vererbungspfeil zeigt zur Oberklasse . Beispiel: 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: 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: Klasse: Produkt Objekt: monitor1 10. Was ist der Unterschied zwischen ERM und UML-Klassendiagramm? ERM modelliert Daten fachlich. UML-Klassendiagramm modelliert die Programmstruktur. Wichtig: Ein Klassendiagramm kann Methoden und Vererbung enthalten. Ein ERM normalerweise nicht. Nächste Seite Danach kommt die eigene Trainer-Seite: UML-Klassendiagramm-Trainer Dort bauen wir den interaktiven Trainer mit Aufgaben zu: Klassen erkennen Attribute zuordnen Methoden eintragen Sichtbarkeit bestimmen Vererbung erkennen Beziehungen zwischen Klassen darstellen Seite 8. UML-Klassendiagramm-Trainer UML-Klassendiagramm-Trainer Dieser interaktive Trainer gehört zur Theorie-Seite: UML-Klassendiagramm Hier übst du, UML-Klassendiagramme richtig zu lesen und aus Aufgabenstellungen abzuleiten. Im Fokus stehen: Klassen Attribute Methoden Sichtbarkeit Assoziation Vererbung Aggregation Komposition korrekte UML-Linienenden Was wird trainiert? 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 Einfache Linie = Assoziation Hohles Dreieck = Vererbung / Generalisierung Leere Raute = Aggregation Gefüllte Raute = Komposition Raute steht am Ganzen Vererbungsdreieck zeigt zur Oberklasse - bedeutet private + bedeutet public Beispiel: Assoziation Aufgabe: Ein Kunde kann mehrere Bestellungen haben. Eine Bestellung gehört zu genau einem Kunden. UML-Bedeutung: Kunde ist mit Bestellung verbunden. Darstellung: Kunde ───── Bestellung Wichtig: Eine Assoziation ist eine normale Beziehung zwischen Klassen. Sie wird als einfache Linie dargestellt. Beispiel: Vererbung Aufgabe: Ein Monitor ist ein Produkt. UML-Bedeutung: Monitor erbt von Produkt. Darstellung: Monitor ─────▷ Produkt Wichtig: Das hohle Dreieck zeigt zur Oberklasse Produkt. Beispiel: Aggregation Aufgabe: Ein Team hat mehrere Mitarbeiter. Ein Mitarbeiter kann aber auch unabhängig vom Team existieren. UML-Bedeutung: Team aggregiert Mitarbeiter. Darstellung: Team ◇──── Mitarbeiter Wichtig: Die leere Raute steht am Ganzen, also bei Team. Aggregation ist eine schwächere Teil-Ganzes-Beziehung. Der Teil kann unabhängig vom Ganzen existieren. Beispiel: Komposition Aufgabe: Eine Rechnung besteht aus Rechnungspositionen. Eine Rechnungsposition gehört fest zu genau einer Rechnung. UML-Bedeutung: Rechnung besteht aus Rechnungspositionen. Darstellung: Rechnung ◆──── Rechnungsposition Wichtig: Die gefüllte Raute steht am Ganzen, also bei Rechnung. Komposition ist eine starke Teil-Ganzes-Beziehung. Der Teil ist fest vom Ganzen abhängig. Wichtiger Unterschied: Aggregation vs. Komposition 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: 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: Kunde ───── Bestellung Bedeutung: Kunde und Bestellung hängen fachlich zusammen. Beispiel Vererbung: Monitor ─────▷ Produkt Bedeutung: Monitor ist ein spezielles Produkt. Sichtbarkeit im Trainer Im Trainer musst du Sichtbarkeiten selbst eintragen. Zeichen Bedeutung Typisch für + public / öffentlich Methoden - private / privat Attribute # protected / geschützt Vererbung / Unterklassen Beispiel: - marke: String + toString(): String Wichtig: Das + oder - soll nicht schon im Feld stehen. Du sollst es selbst erkennen und eintragen. Typische Aufgaben im Trainer Der Trainer enthält Aufgaben zu: Vererbung: Monitor ist ein Produkt. Assoziation: Kunde hat Bestellungen. Aggregation: Team hat Mitarbeiter. Komposition: Rechnung besteht aus Rechnungspositionen. Typische Fehler 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: Kunde ───── Bestellung 2. Welche Pfeilspitze zeigt Vererbung? Vererbung wird mit einem hohlen Dreieck dargestellt. Wichtig: Das hohle Dreieck zeigt zur Oberklasse. Beispiel: Monitor ─────▷ Produkt 3. Was bedeutet eine leere Raute? Eine leere Raute bedeutet Aggregation . Das ist eine schwächere Teil-Ganzes-Beziehung. Beispiel: 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: Rechnung ◆──── Rechnungsposition Die Rechnungsposition gehört fest zur Rechnung. 5. Wo steht die Raute bei Aggregation oder Komposition? Die Raute steht am Ganzen . Beispiele: 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: - attribut: Typ + methode(): Typ 7. Was bedeutet `- marke: String`? Das bedeutet: private Attribut marke vom Typ String In Java wäre das zum Beispiel: private String marke; 8. Was bedeutet `+ toString(): String`? Das bedeutet: public Methode toString mit Rückgabewert String In Java wäre das zum Beispiel: public String toString() 9. Was ist der wichtigste Unterschied zwischen Aggregation und Komposition? Aggregation: Teil kann unabhängig existieren. Komposition: Teil gehört fest zum Ganzen. 10. Wohin zeigt der Vererbungspfeil? Der Vererbungspfeil zeigt immer zur Oberklasse . Beispiel: Monitor ─────▷ Produkt Produkt ist die Oberklasse. Nächste Seite Danach geht es weiter mit: UML-Aktivitätsdiagramm Seite 9. UML-Aktivitätsdiagramm Diese Seite erklärt das UML-Aktivitätsdiagramm so, dass du es schnell für IHK-Aufgaben und Programmierlogik anwenden kannst. Ein UML-Aktivitätsdiagramm wird benutzt, um Abläufe darzustellen. Es zeigt: Start Aktionen Entscheidungen Bedingungen Kontrollflüsse Merge-Knoten Ende Grafik 1: UML-Aktivitätsdiagramm – Grundlagen Diese Grafik zeigt dir die wichtigsten Symbole: Startknoten Aktion / Aktivität Entscheidung Merge-Knoten Kontrollfluss Endknoten Wichtig für die Prüfung: Eine Entscheidung hat meistens einen Eingang und mehrere Ausgänge. Ein Merge-Knoten führt mehrere alternative Wege wieder zusammen. Wofür braucht man ein UML-Aktivitätsdiagramm? Ein Aktivitätsdiagramm zeigt einen Ablauf Schritt für Schritt. Typische Beispiele: Login prüfen Bestellung bearbeiten Produktdaten speichern Eingabe validieren Fehler anzeigen Zurück ins Menü Es ist besonders hilfreich, wenn ein Ablauf Entscheidungen enthält. Beispiel: Wenn die Eingabe gültig ist, wird gespeichert. Wenn die Eingabe ungültig ist, wird eine Fehlermeldung angezeigt. Woran erkenne ich in einer Aufgabe, dass ein UML-Aktivitätsdiagramm gemeint ist? Typische Signalwörter: 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: ● Merksatz: Start = gefüllter Kreis Ein Aktivitätsdiagramm hat meistens genau einen klaren Startpunkt. Aktion / Aktivität Eine Aktion ist ein konkreter Arbeitsschritt. Beispiele: Produktdaten eingeben Eingabe prüfen Produkt speichern Fehler anzeigen Zurück ins Menü Darstellung: ( Produktdaten eingeben ) Im Diagramm wird dafür normalerweise ein abgerundetes Rechteck verwendet. Kontrollfluss Ein Kontrollfluss zeigt die Reihenfolge der Schritte. Darstellung: Aktion 1 → Aktion 2 Wichtig: Der Pfeil zeigt, welcher Schritt als Nächstes kommt. Entscheidung Eine Entscheidung wird verwendet, wenn der Ablauf in verschiedene Richtungen gehen kann. Darstellung: ◇ Beispiel: Eingabe gültig? Danach gibt es meistens zwei Wege: [ja] [nein] Wichtig: Die Bedingungen an den ausgehenden Pfeilen heißen Guards. Guards Guards sind Bedingungen an Kontrollflüssen. Typische Schreibweise: [ja] [nein] [gültig] [ungültig] [preis > 0] [eingabe leer] Beispiel: Eingabe gültig? [ja] → Produkt speichern [nein] → Fehler anzeigen Für Prüfungen ist wichtig: Bedingungen sollten an den Pfeilen stehen, nicht nur irgendwo im Diagramm. Merge-Knoten Ein Merge-Knoten führt alternative Wege wieder zusammen. Darstellung: ◇ Wichtig: Entscheidung und Merge benutzen beide eine Raute. Der Unterschied: Element Bedeutung Entscheidung ein Eingang, mehrere Ausgänge Merge-Knoten mehrere Eingänge, ein Ausgang Beispiel: [ja] → Produkt speichern ┐ ◇ → Zurück ins Menü [nein] → Fehler anzeigen ┘ Endknoten Der Endknoten zeigt das Ende des Ablaufs. Darstellung: ◎ Merksatz: Ende = Kreis mit gefülltem Punkt Grafik 2: Beispiel – Produkt speichern Diese Grafik zeigt einen typischen Ablauf: Produktdaten eingeben Eingabe prüfen Entscheidung: Eingabe gültig? [ja] → Produkt speichern [nein] → Fehler anzeigen Merge-Knoten Zurück ins Menü Ende Wichtig: Die Verzweigung wird mit einer Entscheidungsraute dargestellt. Die Zusammenführung wird mit einem Merge-Knoten dargestellt. Die Bedingungen stehen als [ja] und [nein] an den Kontrollflüssen. Beispiel als Textablauf Aufgabe: Ein Benutzer gibt Produktdaten ein. Das System prüft die Eingabe. Wenn die Eingabe gültig ist, wird das Produkt gespeichert. Wenn die Eingabe ungültig ist, wird eine Fehlermeldung angezeigt. Danach kehrt das System ins Menü zurück. Daraus entsteht: Start ↓ Produktdaten eingeben ↓ Eingabe prüfen ↓ Eingabe gültig? ├─ [ja] → Produkt speichern └─ [nein] → Fehler anzeigen ↓ Merge ↓ Zurück ins Menü ↓ Ende Entscheidung vs. Merge 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: Entscheidung teilt den Ablauf. Merge führt alternative Wege wieder zusammen. Aktivitätsdiagramm vs. Programmcode Ein Aktivitätsdiagramm passt gut zu if -Anweisungen. Beispiel Code-Logik: if (eingabeGueltig) { produktSpeichern(); } else { fehlerAnzeigen(); } zurueckInsMenue(); Passendes Aktivitätsdiagramm: Eingabe prüfen ↓ Eingabe gültig? ├─ [ja] → Produkt speichern └─ [nein] → Fehler anzeigen ↓ Merge ↓ Zurück ins Menü Typische Kontrollstrukturen 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: Eingabe prüfen ↓ Eingabe gültig? ├─ [ja] → Speichern └─ [nein] → Fehler anzeigen → Eingabe erneut bearbeiten Merksatz: Schleifen erkennt man an einem Rückpfeil im Ablauf. Vorgehensweise in der Prüfung Wenn du ein UML-Aktivitätsdiagramm erstellen sollst, gehe so vor: 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 Start = gefüllter Kreis Aktion = abgerundetes Rechteck Entscheidung = Raute Merge = Raute zum Zusammenführen Ende = Kreis mit gefülltem Punkt Kontrollfluss = Pfeil Guards stehen an Pfeilen Guards schreibt man oft in eckigen Klammern [ja] und [nein] sind typische Guards Entscheidung teilt Wege Merge führt Wege zusammen Mini-Beispiel 1 Aufgabe: Wenn ein Passwort korrekt ist, wird der Benutzer angemeldet. Sonst wird eine Fehlermeldung angezeigt. Lösungsidee: Start ↓ Passwort prüfen ↓ Passwort korrekt? ├─ [ja] → Benutzer anmelden └─ [nein] → Fehlermeldung anzeigen ↓ Ende Mini-Beispiel 2 Aufgabe: Ein Preis wird eingegeben. Wenn der Preis größer als 0 ist, wird das Produkt gespeichert. Sonst wird eine Fehlermeldung angezeigt. Lösungsidee: Start ↓ Preis eingeben ↓ Preis > 0? ├─ [ja] → Produkt speichern └─ [nein] → Fehler anzeigen ↓ Ende Mini-Beispiel 3 Aufgabe: Ein Benutzer gibt Daten ein. Wenn die Daten ungültig sind, soll er sie erneut eingeben. Wenn sie gültig sind, werden sie gespeichert. Lösungsidee: Start ↓ Daten eingeben ↓ Daten gültig? ├─ [ja] → Speichern → Ende └─ [nein] → Fehler anzeigen → Daten eingeben Hier entsteht eine Schleife, weil der Ablauf bei ungültigen Daten zurück zur Eingabe geht. Mini-Testfragen 1. Wofür verwendet man ein UML-Aktivitätsdiagramm? Ein UML-Aktivitätsdiagramm verwendet man, um Abläufe, Prozesse und Entscheidungen darzustellen. Beispiele: Login prüfen Produkt speichern Bestellung bearbeiten 2. Wie wird der Startknoten dargestellt? Der Startknoten wird als gefüllter Kreis dargestellt. ● 3. Wie wird eine Aktion dargestellt? Eine Aktion wird als abgerundetes Rechteck dargestellt. Beispiel: Produkt speichern 4. Wie wird eine Entscheidung dargestellt? Eine Entscheidung wird als Raute dargestellt. Beispiel: Eingabe gültig? 5. Was sind Guards? Guards sind Bedingungen an Kontrollflüssen. Beispiele: [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. 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. ◎ 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: 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: [ja] [nein] Nächste Seite Danach kommt die eigene Trainer-Seite: UML-Aktivitätsdiagramm-Trainer Dort bauen wir den interaktiven Trainer mit Aufgaben zu: Startknoten erkennen Aktionen eintragen Entscheidungen setzen Guards [ja]/[nein] ergänzen Merge-Knoten verwenden Endknoten korrekt platzieren Seite 10. UML-Aktivitätsdiagramm-Trainer UML-Aktivitätsdiagramm-Trainer Dieser interaktive Trainer gehört zur Theorie-Seite: UML-Aktivitätsdiagramm Hier übst du, aus einer Aufgabenbeschreibung ein korrektes UML-Aktivitätsdiagramm abzuleiten. Im Fokus stehen: Startknoten Aktionen Entscheidungsraute Guards Kontrollflüsse Merge-Knoten Endknoten Was wird trainiert? 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 Startknoten = gefüllter Kreis Aktion = abgerundetes Rechteck Entscheidung = Raute Guard = Bedingung am Pfeil Merge = Raute zur Zusammenführung Endknoten = Kreis mit gefülltem Punkt Kontrollfluss = Pfeilrichtung im Ablauf Beispiel: Produkt speichern Aufgabenstellung: Ein Benutzer gibt Produktdaten ein. Das System prüft die Eingabe. Wenn die Eingabe gültig ist, wird das Produkt gespeichert. Wenn die Eingabe ungültig ist, wird eine Fehlermeldung angezeigt. Danach kehrt das System ins Menü zurück. Mögliche Lösung: Start ↓ Produktdaten eingeben ↓ Eingabe prüfen ↓ Eingabe gültig? ├─ [ja] → Produkt speichern └─ [nein] → Fehler anzeigen ↓ Merge ↓ Zurück ins Menü ↓ Ende Warum ist die Raute wichtig? Eine Entscheidung wird im UML-Aktivitätsdiagramm als Raute dargestellt. Nicht als Rechteck. Aktion = abgerundetes Rechteck Entscheidung = Raute Merge = Raute Der Unterschied liegt im Ablauf: 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: Eingabe gültig? ├─ [ja] → Produkt speichern └─ [nein] → Fehler anzeigen Wichtig: [ja] und [nein] gehören an die ausgehenden Kontrollflüsse der Entscheidung. Typische Aufgaben im Trainer Der Trainer enthält Aufgaben zu: Produkt speichern Login prüfen Preis prüfen Dabei musst du jeweils erkennen: Welche Aktion kommt zuerst? Welche Prüfung folgt? Wie lautet die Entscheidungsfrage? Welche Guards gehören an die Pfeile? Welche Aktion gehört zum Ja-Zweig? Welche Aktion gehört zum Nein-Zweig? Wo werden die Wege wieder zusammengeführt? Typische Fehler 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. ● 2. Wie wird eine Aktion dargestellt? Eine Aktion wird als abgerundetes Rechteck dargestellt. Beispiel: Produkt speichern 3. Wie wird eine Entscheidung dargestellt? Eine Entscheidung wird als Raute dargestellt. Beispiel: Eingabe gültig? 4. Was sind Guards? Guards sind Bedingungen an den Kontrollflüssen. Beispiele: [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. 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. 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. ◎ 8. Wo gehören `[ja]` und `[nein]` hin? Sie gehören an die ausgehenden Pfeile der Entscheidungsraute. 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: [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: UML-Anwendungsfalldiagramm Seite 11. UML-Anwendungsfalldiagramm UML-Anwendungsfalldiagramm Diese Seite erklärt das UML-Anwendungsfalldiagramm so, dass du es schnell für IHK-Aufgaben und Software-Analyse anwenden kannst. Ein UML-Anwendungsfalldiagramm zeigt: Wer benutzt ein System? Welche Funktionen bietet das System? Welche Akteure stehen mit welchen Anwendungsfällen in Verbindung? Welche Anwendungsfälle hängen voneinander ab? Wichtig: Ein Anwendungsfalldiagramm zeigt nicht den inneren Programmablauf. Es zeigt die Sicht von außen auf das System. Grafik 1: UML-Anwendungsfalldiagramm – Grundlagen Diese Grafik zeigt die wichtigsten Bestandteile: Akteur Systemgrenze Anwendungsfall / Use Case Assoziation «include» «extend» Generalisierung Wofür braucht man ein UML-Anwendungsfalldiagramm? Ein UML-Anwendungsfalldiagramm wird verwendet, um die Anforderungen an ein System aus Benutzersicht darzustellen. Es beantwortet Fragen wie: Wer nutzt das System? Welche Funktionen braucht der Benutzer? Welche Systemfunktionen gehören zusammen? Welche Funktion ist Pflichtbestandteil einer anderen Funktion? Welche Funktion ist nur eine optionale Erweiterung? Beispiel: Ein Kunde kann Artikel suchen. Ein Kunde kann eine Bestellung aufgeben. Beim Aufgeben einer Bestellung muss eine Zahlung durchgeführt werden. Optional kann ein Rabatt geprüft werden. Daraus entstehen: Akteur: Kunde Use Case: Artikel suchen Use Case: Bestellung aufgeben Use Case: Zahlung durchführen Use Case: Rabatt prüfen Woran erkenne ich in einer Aufgabe, dass ein Anwendungsfalldiagramm gemeint ist? Typische Signalwörter: 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: Welche Klasse welche Methode hat. Wie der Ablauf Schritt für Schritt funktioniert. Welche Datenbanktabellen entstehen. Sondern es zeigt: Welche Akteure gibt es? Welche Funktionen stellt das System bereit? Welche Akteure nutzen welche Funktionen? Merksatz: Anwendungsfalldiagramm = Wer nutzt welche Funktion des Systems? Akteur Ein Akteur ist eine Rolle außerhalb des Systems. Beispiele: Kunde Admin Mitarbeiter Lehrer Schüler Zahlungsdienst E-Mail-System Wichtig: Ein Akteur muss nicht immer ein Mensch sein. Auch ein externes System kann ein Akteur sein. Beispiel: Zahlungsdienst E-Mail-Server Versanddienstleister Ein Akteur steht normalerweise außerhalb der Systemgrenze . Systemgrenze Die Systemgrenze wird als Rechteck dargestellt. Innerhalb der Systemgrenze stehen die Anwendungsfälle. Außerhalb der Systemgrenze stehen die Akteure. Merksatz: Akteure außen. Use Cases innen. Systemgrenze als Rechteck. Beispiel: Kunde [ Shop-System ] (Artikel suchen) (Bestellung aufgeben) Anwendungsfall / Use Case Ein Anwendungsfall beschreibt eine Funktion des Systems aus Sicht eines Akteurs. Darstellung: ( Bestellung aufgeben ) Also als Ellipse . Gute Use-Case-Namen sind meistens kurze Tätigkeiten: Artikel suchen Bestellung aufgeben Zahlung durchführen Benutzer anmelden Artikel verwalten Passwort zurücksetzen Wichtig: Use Cases sollten einen Nutzen für einen Akteur haben. Nicht ideal: Datenbank speichern Methode ausführen SQL ausführen Besser: Bestellung speichern Kundendaten verwalten Rechnung erstellen Assoziation Eine Assoziation verbindet einen Akteur mit einem Anwendungsfall. Darstellung: Kunde ───── (Artikel suchen) Bedeutung: Der Akteur nutzt diesen Anwendungsfall. Wichtig: Eine Assoziation ist normalerweise eine einfache Linie. «include» «include» bedeutet: Ein Anwendungsfall enthält einen anderen Anwendungsfall immer als Pflichtbestandteil. Beispiel: Bestellung aufgeben «include» Zahlung durchführen Bedeutung: Wenn eine Bestellung aufgegeben wird, muss die Zahlung durchgeführt werden. Typische Fälle für «include» : Anmelden Zahlung durchführen Berechtigung prüfen Daten validieren Wichtig: «include» zeigt auf den eingebundenen Pflicht-Anwendungsfall. Beispiel: (Bestellung aufgeben) - - -«include»- - -> (Zahlung durchführen) «extend» «extend» bedeutet: Ein Anwendungsfall erweitert einen anderen Anwendungsfall optional. Beispiel: Rabatt prüfen «extend» Bestellung aufgeben Bedeutung: Rabatt prüfen passiert nur unter bestimmten Bedingungen. Zum Beispiel: wenn ein Rabattcode eingegeben wurde wenn der Kunde berechtigt ist wenn eine Sonderaktion aktiv ist Wichtig: «extend» zeigt vom optionalen Erweiterungsfall auf den Basis-Anwendungsfall. Beispiel: (Rabatt prüfen) - - -«extend»- - -> (Bestellung aufgeben) Unterschied «include» und «extend» 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: include = immer dabei extend = optional / nur bei Bedingung Generalisierung Generalisierung bedeutet: Ein spezieller Akteur oder Use Case erbt von einem allgemeineren Akteur oder Use Case. Beispiel bei Akteuren: Admin ist ein spezieller Benutzer. Darstellung: Admin ─────▷ Benutzer Wichtig: Das hohle Dreieck zeigt zur allgemeineren Rolle. Also: Admin → Benutzer nicht umgekehrt. Grafik 2: Beispiel – Shop-System Diese Grafik zeigt ein Beispiel für ein Shop-System. Es enthält: Akteure: Kunde Admin Use Cases: Anmelden Artikel suchen Bestellung aufgeben Zahlung durchführen Rabatt prüfen Artikel verwalten Wichtig: Kunde und Admin stehen außerhalb der Systemgrenze. Die Anwendungsfälle stehen innerhalb der Systemgrenze. Beispiel als Textbeschreibung Aufgabe: Ein Kunde kann Artikel suchen und eine Bestellung aufgeben. Beim Aufgeben einer Bestellung muss eine Zahlung durchgeführt werden. Vor der Bestellung kann optional ein Rabatt geprüft werden. Ein Admin kann Artikel verwalten. Daraus entsteht: Akteur Kunde Akteur Admin Kunde ─ Artikel suchen Kunde ─ Bestellung aufgeben Admin ─ Artikel verwalten Bestellung aufgeben «include» Zahlung durchführen Rabatt prüfen «extend» Bestellung aufgeben Akteure im Beispiel Akteur Rolle Kunde nutzt den Shop, sucht Artikel, gibt Bestellungen auf Admin verwaltet Artikel im Shop-System Wichtig: Akteure sind Rollen. Nicht jede konkrete Person wird einzeln gezeichnet. Also: Kunde nicht: 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. Bestellung aufgeben enthält immer: Zahlung durchführen Darum: Bestellung aufgeben «include» Zahlung durchführen Warum ist „Rabatt prüfen“ ein «extend»? Weil ein Rabatt nicht immer geprüft werden muss. Nur wenn zum Beispiel ein Rabattcode vorhanden ist, wird dieser zusätzliche Fall relevant. Darum: Rabatt prüfen «extend» Bestellung aufgeben Merksatz: Rabatt = optional Zahlung = Pflicht Anwendungsfalldiagramm vs. Aktivitätsdiagramm 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: 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: 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 Akteur = externe Rolle Use Case = Funktion des Systems Systemgrenze = Rechteck um die Use Cases Akteure stehen außerhalb Use Cases stehen innerhalb Use Cases werden als Ellipsen gezeichnet Assoziation = einfache Linie include = Pflichtbestandteil extend = optionale Erweiterung include zeigt auf den eingebundenen Use Case extend zeigt auf den Basis-Use-Case Mini-Beispiel 1 Aufgabe: Ein Benutzer kann sich anmelden. Lösung: Akteur: Benutzer Use Case: Anmelden Benutzer ─ (Anmelden) Mini-Beispiel 2 Aufgabe: Ein Kunde kann eine Bestellung aufgeben. Dabei muss eine Zahlung durchgeführt werden. Lösung: Kunde ─ (Bestellung aufgeben) (Bestellung aufgeben) «include» (Zahlung durchführen) Begründung: Zahlung durchführen ist ein Pflichtbestandteil der Bestellung. Mini-Beispiel 3 Aufgabe: Ein Kunde kann bei einer Bestellung optional einen Rabattcode verwenden. Lösung: (Rabatt prüfen) «extend» (Bestellung aufgeben) Begründung: Rabatt prüfen ist optional. Es passiert nur, wenn ein Rabattcode vorhanden ist. Mini-Testfragen 1. Wofür verwendet man ein UML-Anwendungsfalldiagramm? Man verwendet es, um darzustellen: Welche Akteure ein System nutzen und welche Funktionen das System anbietet. Merksatz: 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: ( 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: Ein Use Case enthält einen anderen Use Case verpflichtend. Beispiel: Bestellung aufgeben «include» Zahlung durchführen 6. Was bedeutet «extend»? «extend» bedeutet: Ein Use Case erweitert einen anderen Use Case optional. Beispiel: Rabatt prüfen «extend» Bestellung aufgeben 7. Was ist der wichtigste Unterschied zwischen include und extend? include = Pflichtbestandteil extend = optionale Erweiterung 8. In welche Richtung zeigt «include»? «include» zeigt auf den eingebundenen Pflicht-Use-Case. Beispiel: Bestellung aufgeben → Zahlung durchführen 9. In welche Richtung zeigt «extend»? «extend» zeigt vom optionalen Erweiterungsfall zum Basis-Use-Case. Beispiel: 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: saveOrder() Besser: Bestellung aufgeben Nächste Seite Danach kommt die eigene Trainer-Seite: UML-Anwendungsfalldiagramm-Trainer Dort bauen wir den interaktiven Trainer mit Aufgaben zu: Akteure erkennen Use Cases benennen Systemgrenze verstehen Assoziationen eintragen include und extend unterscheiden Pfeilrichtung prüfen Seite 12. UML-Anwendungsfalldiagramm-Trainer UML-Anwendungsfalldiagramm-Trainer Dieser interaktive Trainer gehört zur Theorie-Seite: UML-Anwendungsfalldiagramm Hier übst du, aus einer Aufgabenbeschreibung ein korrektes UML-Anwendungsfalldiagramm abzuleiten. Im Fokus stehen: Akteure Systemgrenze Use Cases Assoziationen <> <> 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 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: Ein Kunde kann Artikel suchen und eine Bestellung aufgeben. Beim Aufgeben einer Bestellung muss eine Zahlung durchgeführt werden. Vor der Bestellung kann optional ein Rabatt geprüft werden. Ein Admin kann Artikel verwalten. Mögliche Lösung: System: Shop-System Akteure: Kunde Admin Use Cases: Artikel suchen Bestellung aufgeben Zahlung durchführen Rabatt prüfen Artikel verwalten Beziehungen: Kunde — Artikel suchen Kunde — Bestellung aufgeben Admin — Artikel verwalten Bestellung aufgeben <> Zahlung durchführen Rabatt prüfen <> Bestellung aufgeben Warum ist „Zahlung durchführen“ ein < >? Bestellung aufgeben <> Zahlung durchführen Das bedeutet: Wenn eine Bestellung aufgegeben wird, muss die Zahlung durchgeführt werden. Also ist die Zahlung ein Pflichtbestandteil . Warum ist „Rabatt prüfen“ ein < >? Rabatt prüfen <> Bestellung aufgeben Das bedeutet: Rabatt prüfen erweitert Bestellung aufgeben nur optional. Zum Beispiel: nur wenn ein Rabattcode vorhanden ist nur wenn eine Aktion aktiv ist nur wenn der Kunde berechtigt ist Richtige Pfeilrichtung Beziehung Richtung < > vom Basis-Use-Case zum eingebundenen Pflicht-Use-Case < > vom optionalen Erweiterungs-Use-Case zum Basis-Use-Case Merksatz: 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: ( Bestellung aufgeben ) 3. Wie wird eine Akteur–Use-Case-Beziehung dargestellt? Als einfache durchgezogene Linie ohne Pfeilspitze. Beispiel: Kunde — Bestellung aufgeben 4. Was bedeutet < >? <> bedeutet Pflichtbestandteil. Beispiel: Bestellung aufgeben <> Zahlung durchführen 5. Was bedeutet < >? <> bedeutet optionale Erweiterung. Beispiel: Rabatt prüfen <> Bestellung aufgeben 6. In welche Richtung zeigt include? <> zeigt vom Basis-Use-Case zum eingebundenen Pflicht-Use-Case. Bestellung aufgeben → Zahlung durchführen 7. In welche Richtung zeigt extend? <> zeigt vom optionalen Erweiterungs-Use-Case zum Basis-Use-Case. Rabatt prüfen → Bestellung aufgeben 8. Warum ist Zahlung durchführen im Shop-Beispiel include? Weil die Zahlung ein notwendiger Bestandteil der Bestellung ist. 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. Nur wenn ein Rabattcode oder eine Rabattbedingung vorhanden ist. 10. Was zeigt ein Anwendungsfalldiagramm nicht? Es zeigt nicht den inneren Programmablauf. Nicht dargestellt werden: if-Anweisungen Schleifen Methodenaufrufe Datenbanktabellen Dafür wären andere Diagramme besser geeignet. Nächste Seite Danach geht es weiter mit: UML-Sequenzdiagramm Seite 13. UML-Sequenzdiagramm UML-Sequenzdiagramm Diese Seite erklärt das UML-Sequenzdiagramm so, dass du es schnell für IHK-Aufgaben und Programmierlogik anwenden kannst. Ein UML-Sequenzdiagramm zeigt: Welche Objekte oder Teilnehmer beteiligt sind welche Nachrichten zwischen ihnen ausgetauscht werden in welcher zeitlichen Reihenfolge die Kommunikation abläuft welche Rückgaben erfolgen welche Prozesse nacheinander oder parallel ablaufen Wichtig: Ein Sequenzdiagramm zeigt einen konkreten Ablauf. Der Ablauf wird von oben nach unten gelesen. Grafik 1: UML-Sequenzdiagramm – Grundlagen Diese Grafik zeigt die wichtigsten Bestandteile: Teilnehmer / Objekte Lebenslinien Aktivierungsbalken Nachrichten Rückgaben Zeitachse Wofür braucht man ein UML-Sequenzdiagramm? Ein Sequenzdiagramm wird verwendet, um die Kommunikation zwischen Objekten oder Systemteilen darzustellen. Typische Beispiele: Login prüfen Bestellung aufgeben Produkt speichern Datenbankabfrage ausführen Benutzeroberfläche ruft Service auf Service ruft Datenbank auf Es zeigt also nicht nur, was passiert, sondern vor allem: wer mit wem spricht in welcher Reihenfolge welche Antwort zurückkommt Woran erkenne ich in einer Aufgabe, dass ein Sequenzdiagramm gemeint ist? Typische Signalwörter: 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: Benutzer gibt Login-Daten ein. Die Oberfläche sendet die Daten an den LoginService. Der LoginService fragt die Datenbank ab. Die Datenbank gibt einen Benutzer zurück. Der Service gibt den Loginstatus zurück. Die Oberfläche zeigt eine Meldung an. Daraus entsteht ein zeitlicher Ablauf zwischen: Benutzer loginGUI:LoginGUI loginService:LoginService userRepository:UserRepository Teilnehmer / Objekte Teilnehmer stehen im Sequenzdiagramm oben. Beispiele: Benutzer loginGUI:LoginGUI loginService:LoginService userRepository:UserRepository Wichtig: Ein echter Benutzer kann als Akteur dargestellt werden. Objekte werden häufig als instanz:Klasse geschrieben. Beispiele: loginGUI:LoginGUI loginService:LoginService userRepository:UserRepository Lebenslinie Unter jedem Teilnehmer verläuft eine Lebenslinie nach unten. Darstellung: Teilnehmer | | | In UML wird die Lebenslinie meistens gestrichelt dargestellt. Merksatz: Lebenslinie = zeigt, dass ein Teilnehmer während des Ablaufs existiert. Zeitliche Reihenfolge Ein Sequenzdiagramm wird von oben nach unten gelesen. oben = früher unten = später Merksatz: Die Reihenfolge der Nachrichten ergibt sich aus ihrer Höhe im Diagramm. Nachricht / Methodenaufruf Eine Nachricht zeigt, dass ein Teilnehmer einen anderen Teilnehmer aufruft. Beispiel: loginGUI → loginService: pruefeLogin(name, passwort) Typisch im Diagramm: durchgezogene Linie mit Pfeilspitze Beispiele: loginDatenEingeben(name, passwort) pruefeLogin(name, passwort) findeBenutzer(name) Rückgabe Eine Rückgabe zeigt das Ergebnis eines Aufrufs. Beispiel: userRepository --> loginService: benutzer Typisch: gestrichelte Linie zurück Beispiele: benutzer loginStatus dashboardDaten benutzerKontext Wichtig: Rückgaben sind oft optional, aber in Lern- und Prüfungsdiagrammen sehr hilfreich. Aktivierungsbalken Ein Aktivierungsbalken zeigt, dass ein Teilnehmer gerade aktiv ist. Beispiel: loginService prüft gerade die Login-Daten. userRepository sucht gerade den Benutzer. Darstellung: schmaler senkrechter Balken auf der Lebenslinie Merksatz: Aktivierungsbalken = Teilnehmer verarbeitet gerade etwas. Grafik 2: Beispiel – Login prüfen Diese Grafik zeigt einen Login-Ablauf. Beteiligte Teilnehmer: Benutzer loginGUI:LoginGUI loginService:LoginService userRepository:UserRepository dashboard:Dashboard Ablauf: 1. Benutzer gibt Login-Daten ein. 2. LoginGUI ruft den LoginService auf. 3. LoginService fragt UserRepository ab. 4. UserRepository gibt Benutzer zurück. 5. LoginService gibt Loginstatus zurück. 6. Danach laufen zwei Prozesse parallel: Prozess A: Dashboard laden Prozess B: Benutzerkontext laden 7. Danach wird die Startseite angezeigt. Parallele Prozesse In der IHK-nahen Darstellung können parallele Abläufe durch zwei parallele Linien markiert werden. In unserem Beispiel: Prozess A: Dashboard laden Prozess B: Benutzerkontext laden Wichtig: Parallel bedeutet: Die Prozesse müssen nicht streng nacheinander ablaufen. Sie können gleichzeitig oder unabhängig voneinander gestartet werden. Merksatz: Parallele Linien = paralleler Ablaufbereich Beispiel als Textablauf Aufgabe: Ein Benutzer gibt seine Login-Daten ein. Die Oberfläche sendet Name und Passwort an den LoginService. Der LoginService sucht den Benutzer über das UserRepository. Das UserRepository gibt den Benutzer zurück. Der LoginService gibt den Loginstatus zurück. Nach erfolgreichem Login werden Dashboarddaten und Benutzerkontext geladen. Danach wird die Startseite angezeigt. Daraus entsteht: Benutzer → loginGUI: loginDatenEingeben(name, passwort) loginGUI → loginService: pruefeLogin(name, passwort) loginService → userRepository: findeBenutzer(name) userRepository --> loginService: benutzer loginService --> loginGUI: loginStatus parallel: loginGUI → dashboard: ladeDashboard() dashboard --> loginGUI: dashboardDaten loginGUI → loginService: ladeBenutzerKontext() loginService --> loginGUI: benutzerKontext loginGUI → Benutzer: startseiteAnzeigen() Sequenzdiagramm vs. Aktivitätsdiagramm 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: 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: 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 Teilnehmer stehen oben. Lebenslinien laufen nach unten. Zeit läuft von oben nach unten. Nachrichten sind horizontale Pfeile. Synchrone Aufrufe werden durchgezogen gezeichnet. Rückgaben werden gestrichelt gezeichnet. Aktivierungsbalken zeigen Verarbeitung. Parallele Prozesse müssen erkennbar markiert werden. Ein Sequenzdiagramm zeigt ein konkretes Szenario. Mini-Beispiel 1 Aufgabe: Ein Benutzer klickt auf Speichern. Die Oberfläche sendet die Daten an den Controller. Der Controller speichert die Daten in der Datenbank. Die Datenbank gibt eine Bestätigung zurück. Lösungsidee: Benutzer → GUI: speichernKlicken() GUI → Controller: speichern(daten) Controller → Datenbank: insert(daten) Datenbank --> Controller: ok Controller --> GUI: gespeichert GUI → Benutzer: bestätigungAnzeigen() Mini-Beispiel 2 Aufgabe: Ein Kunde gibt eine Bestellung auf. Die Oberfläche sendet die Bestellung an den BestellService. Der BestellService prüft den Lagerbestand. Danach wird die Bestellung gespeichert. Lösungsidee: Kunde → ShopGUI: bestellungAufgeben() ShopGUI → BestellService: bestellungPruefen() BestellService → LagerService: bestandPruefen() LagerService --> BestellService: bestandOK BestellService → BestellungRepository: speichern() BestellungRepository --> BestellService: gespeichert BestellService --> ShopGUI: bestellungOK Mini-Beispiel 3: Paralleler Ablauf Aufgabe: Nach dem Login werden Dashboarddaten und Benutzerdaten parallel geladen. Lösungsidee: parallel: GUI → DashboardService: ladeDashboard() DashboardService --> GUI: dashboardDaten GUI → BenutzerService: ladeBenutzerDaten() BenutzerService --> GUI: benutzerDaten Merksatz: Wenn zwei Abläufe unabhängig voneinander starten können, kann ein paralleler Bereich sinnvoll sein. Mini-Testfragen 1. Wofür verwendet man ein UML-Sequenzdiagramm? Man verwendet es, um den zeitlichen Nachrichtenaustausch zwischen Teilnehmern oder Objekten darzustellen. Merksatz: Wer ruft wen wann auf? 2. Wie liest man ein Sequenzdiagramm? Von oben nach unten. 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: 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. 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: 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: Der Ablauf wird von oben nach unten gelesen. Nächste Seite Danach kommt die eigene Trainer-Seite: UML-Sequenzdiagramm-Trainer Dort übst du: Teilnehmer erkennen Nachrichten richtig beschriften Rückgaben unterscheiden Reihenfolge beachten parallele Prozesse erkennen Sequenzdiagramme aus Textaufgaben ableiten Seite 14. UML-Sequenzdiagramm-Trainer Dieser interaktive Trainer gehört zur Theorie-Seite: UML-Sequenzdiagramm Hier übst du, aus einer Aufgabenbeschreibung ein korrektes UML-Sequenzdiagramm abzuleiten. Im Fokus stehen: Teilnehmer Lebenslinien Nachrichten Rückgaben Reihenfolge Aktivierungsbalken parallele Prozessbereiche Was wird trainiert? 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 UML-Sequenzdiagramm-Trainer im Vollbild öffnen Merksatz für den Trainer Teilnehmer stehen oben. Lebenslinien laufen nach unten. Zeit läuft von oben nach unten. Nachrichten sind durchgezogene Pfeile. Rückgaben sind gestrichelte Pfeile. Aktivierungsbalken zeigen Verarbeitung. Parallele Abläufe müssen sichtbar markiert werden. Wichtige fachliche Einordnung Im Trainer verwenden wir für den parallelen Bereich eine IHK-nahe vereinfachte Darstellung mit zwei parallelen Linien . Das bedeutet: zwei parallele Linien = paralleler Ablaufbereich Streng nach UML kann Parallelität auch als par -Combined-Fragment mit Rahmen dargestellt werden. Für dein IHK-Lernen ist wichtig: Du sollst erkennen: Hier laufen zwei Prozesse parallel oder unabhängig voneinander ab. Beispiel: Login prüfen Aufgabenstellung: Ein Benutzer gibt Login-Daten ein. Die LoginGUI ruft den LoginService auf. Der LoginService fragt das UserRepository ab. Danach werden Dashboarddaten und Benutzerkontext parallel geladen. Zum Schluss wird die Startseite angezeigt. Mögliche Lösung: Teilnehmer: Benutzer loginGUI:LoginGUI loginService:LoginService userRepository:UserRepository dashboard:Dashboard Ablauf: Benutzer → loginGUI: loginDatenEingeben(name, passwort) loginGUI → loginService: pruefeLogin(name, passwort) loginService → userRepository: findeBenutzer(name) userRepository --> loginService: benutzer loginService --> loginGUI: loginStatus Parallelbereich: Prozess A: loginGUI → dashboard: ladeDashboard() dashboard --> loginGUI: dashboardDaten Prozess B: loginGUI → loginService: ladeBenutzerKontext() loginService --> loginGUI: benutzerKontext Abschluss: loginGUI → Benutzer: startseiteAnzeigen() Nachricht oder Rückgabe? 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: Benutzer loginGUI:LoginGUI loginService:LoginService userRepository:UserRepository dashboard:Dashboard Wichtig: Benutzer = Akteur loginGUI:LoginGUI = Objekt / Instanz mit Klasse Warum steht die Zeit von oben nach unten? Ein Sequenzdiagramm wird vertikal gelesen. oben = früher unten = später Das bedeutet: Die erste Nachricht steht oben. Spätere Nachrichten stehen weiter unten. Typische Fehler im Sequenzdiagramm 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: Wer ruft wen wann auf? 2. Wie liest man ein Sequenzdiagramm? Von oben nach unten. 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: loginGUI → loginService: pruefeLogin() 5. Wie wird eine Rückgabe dargestellt? Als gestrichelter Pfeil zurück. Beispiel: 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: 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. 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: Die Reihenfolge ergibt sich von oben nach unten. Nächste Seite Danach geht es weiter mit: Mock-up / Benutzeroberflächen-Entwurf Seite 15: Mock-up / Benutzeroberflächen-Entwurf Diese Seite erklärt den Mock-up / Benutzeroberflächen-Entwurf so, dass du ihn schnell für IHK-Aufgaben anwenden kannst. Ein Mock-up zeigt: Wie eine Benutzeroberfläche aussehen soll welche Felder und Buttons vorhanden sind wie die Navigation aufgebaut ist wo Fehlermeldungen erscheinen wie der Benutzer durch die Oberfläche geführt wird Wichtig: Ein Mock-up ist kein UML-Diagramm. Ein Mock-up zeigt keine Programmlogik. Ein Mock-up zeigt die geplante Bedienoberfläche. Grafik 1: Mock-up – Grundlagen Diese Grafik zeigt die wichtigsten Bestandteile eines Mock-ups: Fenster / App-Rahmen Titelbereich Navigation Inhaltsbereich Formularfelder Buttons Fehlermeldung Benutzerführung Wofür braucht man ein Mock-up? Ein Mock-up wird benutzt, um eine Oberfläche vor der Programmierung zu planen. Typische Ziele: Benutzeroberfläche sichtbar machen Bedienung planen Felder und Buttons festlegen Fehler- und Erfolgsmeldungen berücksichtigen Benutzerführung prüfen Missverständnisse vor der Programmierung vermeiden Ein Mock-up beantwortet also Fragen wie: Welche Eingabefelder braucht der Benutzer? Welche Buttons sind notwendig? Wo steht die Fehlermeldung? Wie kommt der Benutzer zurück? Was passiert nach dem Speichern? Woran erkenne ich in einer Aufgabe, dass ein Mock-up gemeint ist? Typische Signalwörter: 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: Java-Code SQL-Code Methodenaufrufe Datenbankstruktur UML-Beziehungen Sondern es zeigt: Oberflächenaufbau Felder Buttons Navigation Meldungen Anordnung Bedienbarkeit Merksatz: Mock-up = Wie sieht die Oberfläche für den Benutzer aus? Grafik 2: Beispiel – Produktformular Diese Grafik zeigt ein typisches Mock-up für eine Produktverwaltung. Enthalten sind: Toolbar Formularbereich Produktname Kategorie Preis Lagerbestand Aktiv-Checkbox Speichern-Button Abbrechen-Button Zurück-zur-Liste-Button Fehlermeldung am Preisfeld Wichtige Bestandteile eines guten Mock-ups 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: Produktname * Preis * Kategorie * Das * bedeutet: Dieses Feld muss ausgefüllt werden. Wichtig: Pflichtfelder sollten klar erkennbar sein. Validierung und Fehlermeldungen Validierung bedeutet: Das System prüft, ob die Eingabe gültig ist. Beispiele: Preis muss größer als 0 sein. Produktname darf nicht leer sein. Kategorie muss ausgewählt werden. E-Mail-Adresse muss gültig sein. Passwort muss lang genug sein. Gute Fehlermeldungen stehen möglichst nah am betroffenen Feld. Beispiel: Preis * [ 0,00 € ] Preis muss größer als 0 sein. Merksatz: Fehlermeldung direkt dort anzeigen, wo der Fehler entsteht. Buttons Buttons lösen Aktionen aus. Typische Buttons: 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: Buttons sollten eindeutig beschriftet sein. Nicht ideal: OK Weiter Klick Button 1 Besser: Speichern Abbrechen Zurück zur Liste Produkt löschen Benutzerführung Benutzerführung bedeutet: Der Benutzer erkennt, was er tun soll. Eine gute Oberfläche hilft dem Benutzer durch: klare Überschriften verständliche Feldnamen sinnvolle Reihenfolge der Felder sichtbare Pflichtfelder verständliche Fehlertexte logische Buttons Rückweg zur Übersicht Merksatz: Der Benutzer soll nicht raten müssen. Mock-up vs. UML-Diagramme 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: 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: 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: 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 Mock-up = visueller Oberflächenentwurf Mock-up ist kein UML-Diagramm Mock-up muss nicht funktionieren Mock-up zeigt Felder, Buttons und Benutzerführung Pflichtfelder klar markieren Fehlermeldungen direkt am Feld anzeigen Buttons eindeutig benennen Benutzer soll die Oberfläche ohne Raten verstehen Mini-Beispiel 1 Aufgabe: Entwerfen Sie eine Eingabemaske zum Anlegen eines Produkts. Wichtige Elemente: Produktname * Kategorie * Preis * Lagerbestand Aktiv-Checkbox Speichern Abbrechen Fehlermeldung bei ungültigem Preis Mini-Beispiel 2 Aufgabe: Ein Benutzer soll sich anmelden können. Wichtige Elemente: Benutzername / E-Mail Passwort Anmelden-Button Passwort vergessen Fehlermeldung bei falschen Zugangsdaten Mini-Beispiel 3 Aufgabe: Ein Kunde soll eine Bestellung abschließen können. Wichtige Elemente: Warenkorbübersicht Lieferadresse Zahlungsart AGB-Checkbox Bestellung abschließen Zurück zum Warenkorb Fehlermeldung bei fehlender Zahlungsart Mini-Testfragen 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: Felder Buttons Navigation Fehlermeldungen Layout Benutzerführung 4. Was bedeutet ein Sternchen `*` an einem Feld? Das Sternchen zeigt ein Pflichtfeld. Beispiel: Preis * Der Preis muss eingegeben werden. 5. Wo sollte eine Fehlermeldung stehen? Möglichst nah am betroffenen Feld. Beispiel: 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: Speichern Abbrechen Zurück zur Liste statt: 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: 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: 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: Mock-up-Trainer Dort übst du: Pflichtfelder erkennen Fehlermeldungen richtig platzieren notwendige Buttons auswählen Benutzerführung bewerten Mock-up-Elemente aus einer Aufgabenstellung ableiten Seite 16: Mock-up-Trainer Dieser interaktive Trainer gehört zur Theorie-Seite: Mock-up / Benutzeroberflächen-Entwurf Hier übst du, aus einer Aufgabenbeschreibung die wichtigsten Elemente einer Benutzeroberfläche abzuleiten. Im Fokus stehen: Pflichtfelder Fehlermeldungen Validierung Buttons Hauptaktion Nebenaktion Benutzerführung Mock-up ≠ UML-Diagramm Was wird trainiert? 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 Mock-up-Trainer im Vollbild öffnen Merksatz für den Trainer Mock-up = geplanter Oberflächenentwurf Mock-up ist kein UML-Diagramm Pflichtfelder müssen erkennbar sein Fehlermeldungen gehören nah an das betroffene Feld Buttons müssen eindeutig beschriftet sein Benutzerführung muss logisch und verständlich sein Beispiel: Produktformular Aufgabenstellung: Ein Produkt soll angelegt werden. Produktname, Kategorie und Preis sind Pflichtfelder. Der Preis muss größer als 0 sein. Der Benutzer soll speichern, abbrechen oder zurück zur Liste gehen können. Mögliche Lösung: Pflichtfelder: Produktname Kategorie Preis Fehlermeldung: Direkt am Preisfeld Hauptaktion: Speichern Sinnvolle Nebenaktionen: Abbrechen Zurück zur Liste Validierung: Preis muss größer als 0 sein Einordnung: Mock-up ist kein UML-Diagramm Warum ist das fachlich richtig? Ein Mock-up soll zeigen, wie eine Oberfläche aufgebaut ist und wie der Benutzer sie bedient. Bei einem Produktformular muss der Benutzer erkennen: Welche Daten muss ich eingeben? Welche Felder sind Pflicht? Was ist falsch, wenn eine Eingabe ungültig ist? Wie speichere ich? Wie breche ich ab? Wie komme ich zurück? Pflichtfelder Pflichtfelder sind Felder, die ausgefüllt werden müssen. Typische Darstellung: Produktname * Kategorie * Preis * Das Sternchen * zeigt: Dieses Feld ist erforderlich. Fehlermeldungen Fehlermeldungen sollten möglichst direkt beim betroffenen Feld stehen. Gut: Preis * [ 0,00 € ] Preis muss größer als 0 sein. Schlecht: Irgendwo oben steht nur: Fehler. Merksatz: Der Benutzer muss sofort erkennen, was falsch ist und wo er es korrigieren muss. Validierung Validierung bedeutet: Das System prüft, ob die Eingabe gültig ist. Beispiele: Preis muss größer als 0 sein E-Mail-Adresse muss gültig sein Passwort darf nicht leer sein Produktname muss ausgefüllt sein Kategorie muss ausgewählt werden Hauptaktion Die Hauptaktion ist die wichtigste Aktion im Formular. Beispiele: Speichern Anmelden Bestellung abschließen Absenden Im Produktformular ist die Hauptaktion: Speichern Nebenaktionen Nebenaktionen helfen dem Benutzer, den Vorgang zu verlassen oder zurückzugehen. Beispiele: Abbrechen Zurück zur Liste Zurück zum Warenkorb Schließen Wichtig: Der Benutzer soll nicht in der Oberfläche feststecken. Mock-up ist kein UML-Diagramm Ein Mock-up zeigt eine Benutzeroberfläche. Es zeigt nicht: Klassen Methoden Kardinalitäten Sequenzen Kontrollflüsse Datenbankbeziehungen Dafür gibt es andere Diagramme. Merksatz: Mock-up = Oberfläche UML = Modellierung Typische Fehler im Mock-up 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: Pflichtfelder Fehlermeldungen Validierung Buttons Benutzerführung 2. Was bedeutet ein Sternchen `*` an einem Feld? Das Sternchen bedeutet: Pflichtfeld Das Feld muss ausgefüllt werden. 3. Wo sollte eine Fehlermeldung stehen? Möglichst direkt am betroffenen Feld. Beispiel: Preis muss größer als 0 sein. direkt beim Preisfeld. 4. Was ist die Hauptaktion im Produktformular? Die Hauptaktion ist: Speichern 5. Welche Nebenaktionen sind sinnvoll? Zum Beispiel: Abbrechen Zurück zur Liste 6. Was bedeutet Validierung? Validierung bedeutet: Das System prüft, ob eine Eingabe gültig ist. Beispiel: 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: Programmcode Datenbankbeziehungen Klassendiagramme Sequenzdiagramme Kontrollflüsse 9. Warum sind eindeutige Buttons wichtig? Weil der Benutzer erkennen muss, welche Aktion passiert. Besser: Speichern Abbrechen Zurück zur Liste statt: OK Weiter Button 1 10. Was ist Benutzerführung? Benutzerführung bedeutet: Die Oberfläche zeigt dem Benutzer klar, was er tun soll. Dazu gehören: verständliche Feldnamen sichtbare Pflichtfelder klare Buttons Fehlermeldungen Rückwege Nächste Seite Danach geht es weiter mit: UML-Zustandsdiagramm