Use Case: Webshop abgeschlossen

❌ Die Notation beherrschst du in Teilen schon (Systemgrenze, «include»-Richtung), aber du hast ein anderes Szenario modelliert. Lies die Aufgabe genau und zeichne den Webshop mit Interessent, Kunde (Generalisierung mit hohlem Dreieck), »Artikel suchen«, »Waren bestellen« und »Bestellung ansehen« jeweils mit «include» zu »Einloggen«.

Geschätzt in der Prüfung: keine Punkte

✅ Korrekt

• Systemgrenze vorhanden und beschriftet, Akteure außerhalb der Systemgrenze
• Use Cases als Ellipsen, überwiegend nach dem Muster Objekt + Verb benannt
• Akteur-Assoziationen als einfache Linien
• «include» gestrichelt und in der richtigen Richtung vom Basis-Use-Case (Informationen bearbeiten) zum eingebundenen Use Case (einloggen)
• Generalisierung zwischen den Akteuren in der richtigen Richtung (speziell → allgemein)

❌ Fehlt

• Das Diagramm modelliert ein Krankenhaus-Informationssystem statt des geforderten Webshops; alle Elemente der Aufgabe fehlen
• Systemgrenze »Webshop«
• Akteure »Interessent« und »Kunde«
• Generalisierung Kunde → Interessent
• Use Case »Artikel suchen« mit Assoziation zum Interessenten
• Use Cases »Waren bestellen« und »Bestellung ansehen« mit Assoziation zum Kunden
• Use Case »Einloggen« mit «include» von »Waren bestellen« und »Bestellung ansehen« zu »Einloggen«

⚠️ Vorhanden, aber falsch

• Falsches Szenario bearbeitet: Die Lösung passt nicht zur gestellten Aufgabe und wäre in der Prüfung nicht wertbar
• Generalisierung mit offener Pfeilspitze gezeichnet; richtig ist ein hohles Dreieck am allgemeineren Akteur
• «extend»-Pfeil zeigt von »einloggen« zu »Informationen ansehen« und bedeutet damit, dass das Einloggen das Ansehen optional erweitert; fachlich gemeint ist, dass das Ansehen den Login voraussetzt, also «include» von »Informationen ansehen« zu »einloggen«
• »Informationen ansehen« hat keine direkte Assoziation zu einem Akteur

✅ Sehr saubere Lösung: Alle Anforderungen sind abgedeckt und die extend-Notation inklusive Extension Points und Conditions ist korrekt. Als Übung lohnt sich die gleichwertige Alternative, bei der der Kunde direkt mit 'Waren bestellen' und 'Bestellung ansehen' verbunden ist und beide per «include» den Login einbinden.

Geschätzt in der Prüfung: volle Punktzahl

✅ Korrekt

• Systemgrenze vorhanden und mit 'Webshop' beschriftet
• Akteure 'Interessent' und 'Kunde' benannt und außerhalb der Systemgrenze
• Generalisierung Kunde → Interessent korrekt mit hohlem Dreieck zum allgemeineren Akteur; Kunde erbt damit 'Artikel suchen'
• Interessent nur mit 'Artikel suchen' verbunden, wie gefordert
• Assoziationen Akteur–Use Case als einfache Linien
• 'Waren bestellen' und 'Bestellung ansehen' als optionale Erweiterungen des Logins modelliert: «extend» gestrichelt, Pfeil von der Erweiterung zum Basis-Use-Case
• Extension Points im Basis-Use-Case 'In Benutzerkonto einloggen' angegeben und in Notizen mit Condition referenziert
• Use Cases nach dem Muster Objekt + Verb benannt; kein Use Case ohne Verbindung

✅ Sehr saubere Lösung: Alle Anforderungen sind abgedeckt, und Generalisierung sowie «include» sind richtig notiert. Achte in der Prüfung nur darauf, dass Durchgestrichenes, auch die zugehörigen Linien, eindeutig als ungültig erkennbar ist.

Geschätzt in der Prüfung: volle Punktzahl

✅ Korrekt

• Systemgrenze als Rechteck mit der Beschriftung „Webshop“
• Akteure „Kunde“ und „Interessent“ benannt und außerhalb der Systemgrenze
• Generalisierung Kunde → Interessent mit hohlem Dreieck an der Seite des Interessenten, also richtig herum
• Interessent ist nur mit „Artikel suchen“ verbunden; der Kunde erbt diesen Use Case über die Generalisierung
• Kunde ist über einfache Linien mit „Ware bestellen“ und „Bestellung einsehen“ verbunden
• Login als eigener Use Case „im Webshop einloggen“ modelliert
• «include» gestrichelt mit offener Pfeilspitze, jeweils vom Basis-Use-Case zum Login, also richtig herum
• Use Cases als Ellipsen, sinnvoll nach Objekt + Verb benannt

🟡 Akteure, Generalisierung und Systemgrenze sind sauber umgesetzt. Übe vor allem den Unterschied zwischen «include» und «extend»: Ein Schritt, der immer nötig ist wie hier der Login, wird mit «include» vom Basis-Use-Case aus eingebunden. Den Akteur verbindest du direkt mit seinen eigentlichen Zielen wie Bestellen und Ansehen.

Geschätzt in der Prüfung: etwa die Hälfte der Punkte

✅ Korrekt

• Systemgrenze als Rechteck mit der Beschriftung „Webshop“
• Akteure „Interessent“ und „Kunde“ benannt und außerhalb der Systemgrenze
• Generalisierung Kunde → Interessent mit hohlem Dreieck in Richtung Interessent, also korrekt
• Interessent ist per einfacher Linie mit „Artikel suchen“ verbunden; der Kunde erbt diesen Use Case
• Alle geforderten Use Cases als Ellipsen vorhanden: Artikel suchen, Login, Waren bestellen, Bestellungen ansehen
• «extend»-Beziehungen gestrichelt mit offener Pfeilspitze; Stereotyp angegeben

❌ Fehlt

• Direkte Assoziationen vom Kunden zu „Waren bestellen“ und zu „Bestellungen ansehen“; das sind die eigentlichen Anwendungsfälle des Kunden

⚠️ Vorhanden, aber falsch

• Beziehung zwischen „Waren bestellen“/„Bestellungen ansehen“ und „Login“ falsch modelliert: Laut Aufgabe ist der Login eine Voraussetzung, die immer stattfindet. Richtig wäre «include», gestrichelt vom Basis-Use-Case (Waren bestellen bzw. Bestellungen ansehen) zu „Login“.
• Mit der gezeichneten «extend»-Beziehung wären Bestellen und Ansehen nur optionale Erweiterungen des Logins. Der Login wäre damit fälschlich der Hauptanwendungsfall des Kunden.
• „Login“ folgt nicht dem Muster Objekt + Verb; besser z. B. „Einloggen“ oder „Am System anmelden“ (Kleinigkeit)

🟡 Akteure, Generalisierung und Systemgrenze sind sauber umgesetzt. Achte als Nächstes auf Formulierungen wie „nach dem Login“ in der Aufgabenstellung: Sie deuten fast immer auf einen eigenen Use Case hin, der per «include» eingebunden wird.

Geschätzt in der Prüfung: etwa zwei Drittel der Punkte

✅ Korrekt

• Systemgrenze als Rechteck, beschriftet mit „Webshop“
• Akteure „Interessent“ und „Kunde“ benannt und außerhalb der Systemgrenze
• Generalisierung „Kunde ist ein Interessent“ korrekt: hohles Dreieck zeigt auf den allgemeineren Akteur Interessent
• Use Cases als Ellipsen und nach dem Muster Objekt + Verb benannt: „Artikel suchen“, „Waren bestellen“, „Bestellung ansehen“
• Interessent über einfache Linie mit „Artikel suchen“ verbunden; durch die Generalisierung darf auch der Kunde Artikel suchen
• Kunde über einfache Linien mit „Waren bestellen“ und „Bestellung ansehen“ verbunden

❌ Fehlt

• Use Case für den Login (z. B. „Kunde einloggen“) fehlt, obwohl die Aufgabe ihn für beide Kundenfunktionen ausdrücklich verlangt
• «include»-Beziehungen von „Waren bestellen“ und „Bestellung ansehen“ zum Login-Use-Case fehlen; richtig wären gestrichelte Pfeile mit offener Spitze vom Basis-Use-Case zum Login, beschriftet mit «include»

✅ Sehr gute Lösung: Generalisierung, Systemgrenze und «include»-Beziehungen sind fachlich und notationell korrekt umgesetzt. Achte in der Prüfung nur darauf, Korrekturen eindeutig zu kennzeichnen, damit keine durchgezogene Linie als falsche Notation gewertet wird.

Geschätzt in der Prüfung: fast alle Punkte

✅ Korrekt

• Systemgrenze als Rechteck mit der Beschriftung „Webshop“ vorhanden
• Akteure „Interessent“ und „Kunde“ benannt und außerhalb der Systemgrenze platziert
• Generalisierung Kunde → Interessent korrekt mit hohlem Dreieck an der Oberklasse (Interessent)
• „Artikel suchen“ per einfacher Linie mit dem Interessenten verbunden; der Kunde erbt diesen Use Case über die Generalisierung
• „Waren bestellen“ und „Bestellungen ansehen“ per einfacher Assoziation mit dem Kunden verbunden
• Login als eigener Use Case „Einloggen“ ausgelagert
• «include» von „Waren bestellen“ und „Bestellungen ansehen“ zu „Einloggen“ in richtiger Richtung (vom Basis-Use-Case zum eingebundenen Use Case), gestrichelt mit offener Pfeilspitze und Stereotyp
• Kein Use Case ohne Verbindung

⚠️ Vorhanden, aber falsch

• Die «include»-Beziehung zwischen „Bestellungen ansehen“ und „Einloggen“ ist doppelt gezogen (durchgezogene und gestrichelte Linie). Sie sollte eindeutig nur gestrichelt sein, die durchgezogene Linie sauber durchstreichen.
• Kleinigkeit: „Einloggen“ hat kein Objekt im Namen, besser „Im Shop einloggen“ nach dem Muster Objekt + Verb (wird meist akzeptiert).