Use-Case-Diagramm

Wozu ein Use-Case-Diagramm?

Das Use-Case-Diagramm (use case diagram, auf Deutsch auch Anwendungsfalldiagramm) steht am Anfang eines Projekts. Es beantwortet zwei Fragen: Wer arbeitet mit dem System, und was will diese Person oder dieses System damit erreichen? Wie das technisch umgesetzt wird, spielt hier noch keine Rolle. Genau darin liegt der Wert: Ein Auftraggeber ohne IT-Kenntnisse kann das Diagramm lesen und sagen, ob etwas fehlt.

In der Prüfung ist es deshalb oft die erste Teilaufgabe einer Modellierung: Aus einem Gesprächsprotokoll oder einer Anforderungsliste sollst du Akteure und Anwendungsfälle herausarbeiten. Die Elemente auf einen Blick:

Akteure, Anwendungsfälle und Systemgrenze

Akteure

Ein Akteur (actor) ist eine Rolle, keine konkrete Person. Frau Yilmaz aus dem Kundenservice ist kein Akteur, „Mitarbeiter“ schon. Eine Person kann mehrere Rollen haben: Wer im Verleih arbeitet und privat ein Rad bucht, ist einmal Mitarbeiter und einmal Kunde. Akteure stehen immer außerhalb der Systemgrenze.

Auch ein anderes System kann Akteur sein, etwa ein Zahlungsanbieter, ein SMS-Dienst oder ein Warenwirtschaftssystem. Es wird ebenfalls als Strichmännchen gezeichnet; alternativ ist ein Rechteck mit dem Schlüsselwort «actor» erlaubt, das Fremdsysteme optisch von Menschen abhebt. Beides gibt in der Prüfung volle Punkte, solange du innerhalb eines Diagramms bei einer Form bleibst.

Anwendungsfälle

Ein Anwendungsfall (use case) beschreibt ein Ziel mit erkennbarem Nutzen für den Akteur. Du benennst ihn mit Objekt und Verb im Infinitiv: „Lastenrad buchen“, „Rechnung bezahlen“, „Termin verschieben“. Ein guter Test ist die Frage: Würde der Akteur nach diesem Schritt zufrieden aufhören? Nach „Lastenrad buchen“ ja, nach „Button klicken“ oder „Formular öffnen“ nicht. Solche Einzelschritte gehören in ein Aktivitätsdiagramm (Lektion 5).

Systemgrenze und Assoziation

Die Systemgrenze (system boundary) ist ein Rechteck, oben links steht der Name des Systems. Alle Anwendungsfälle liegen innen, alle Akteure außen. Eine durchgezogene Linie, die Assoziation (association), verbindet einen Akteur mit jedem Anwendungsfall, an dem er beteiligt ist. Pfeilspitzen brauchst du dort nicht; wer den Fall anstößt, geht aus dem Text hervor und nicht aus der Linie.

include und extend: der Klassiker für Fehler

Zwei Beziehungen verbinden Anwendungsfälle untereinander. Beide sind gestrichelte Pfeile mit offener Spitze und einem Stereotyp in französischen Anführungszeichen. Den Unterschied machen die Bedeutung und vor allem die Pfeilrichtung.

include: immer dabei

Bei «include» (einbinden) führt der Basisfall den anderen Fall jedes Mal mit aus. Wer ein Lastenrad bucht, bezahlt immer. Der Pfeil zeigt vom Basisfall zum eingebundenen Fall, denn der Basisfall „ruft“ ihn auf, ähnlich wie eine Methode eine andere aufruft. Sinnvoll ist include vor allem, wenn mehrere Fälle denselben Teil brauchen: „Rad buchen“ und „Buchung verlängern“ binden beide „Bezahlen“ ein, und du beschreibst das Bezahlen nur einmal.

extend: nur unter einer Bedingung

Bei «extend» (erweitern) kommt der erweiternde Fall nur manchmal hinzu, nämlich wenn eine Bedingung erfüllt ist. Der Basisfall funktioniert auch ohne ihn und weiß nichts von ihm. Deshalb zeigt der Pfeil von der Erweiterung zum Basisfall: Die Erweiterung klinkt sich ein. Die Bedingung schreibst du in eine Notiz, die an der extend-Linie hängt. Die Stelle, an der sich die Erweiterung einklinkt, heißt Erweiterungspunkt (extension point) und darf unter dem Namen in der Ellipse stehen, etwa „extension points: Zusatzleistungen“. In Prüfungen wird er selten verlangt.

Generalisierung von Akteuren

Hat ein Akteur alle Rechte eines anderen und dazu weitere, zeichnest du eine Generalisierung (generalization): eine durchgezogene Linie mit hohlem Dreieck, das auf den allgemeineren Akteur zeigt. Die Stationsleitung ist ein Mitarbeiter mit Zusatzrechten. Sie darf alles, was ein Mitarbeiter darf, ohne dass du jede Linie doppelt ziehst, und zusätzlich Räder ausmustern.

Das Dreieck ist dasselbe Symbol wie bei der Vererbung im Klassendiagramm (Lektion 4). Auch zwischen Anwendungsfällen ist eine Generalisierung erlaubt, etwa „Bezahlen“ mit den Spezialfällen „Per Karte bezahlen“ und „Per Rechnung bezahlen“. In Prüfungen kommt sie aber fast nur bei Akteuren vor.

Beispiel Schritt für Schritt: Lastenrad-Verleih

Dasselbe Szenario wie im Klassendiagramm der Lektion 3, diesmal aus Sicht der Nutzer. Lies den Text einmal ganz, dann gehst du in drei Schritten vor.

Schritt 1: Akteure und Systemgrenze

Suche alle, die mit dem System arbeiten, und frage jeweils: Steht er innerhalb oder außerhalb? Kunde und Mitarbeiter sind Menschen außerhalb. Der Zahlungsanbieter ist ein fremdes System, mit dem der Verleih Daten austauscht, also ebenfalls ein Akteur. Die Stadtwerke sind nur der Auftraggeber; sie arbeiten nicht selbst mit dem System und werden kein Akteur. Das System bekommt einen kurzen Namen: Lastenrad-Verleih.

Schritt 2: Anwendungsfälle und Assoziationen

Jetzt sammelst du die Ziele. Aus den markierten Verben werden „Lastenrad buchen“, „Buchung stornieren“ und „Rad warten“. Das Anmelden des Mitarbeiters ist kein eigenständiger Anwendungsfall: Es ist eine Voraussetzung, kein Ziel. Niemand meldet sich an, um danach zufrieden aufzuhören. Als per «include» eingebundener Fall „Anmelden“ ist es dagegen üblich und wird in IHK-Lösungen akzeptiert. Jeder Fall bekommt eine Linie zu seinem Akteur.

Schritt 3: include, extend und die Fremdsysteme

Jetzt prüfst du jeden Nebensatz auf „immer“ oder „auf Wunsch“:

• „Zu jeder Buchung gehört die Bezahlung“: immer, also «include» von „Lastenrad buchen“ zu „Bezahlen“. Der Zahlungsanbieter hängt am Fall „Bezahlen“, denn nur dort ist er beteiligt.
• „Auf Wunsch Zubehör hinzubuchen“: nur manchmal und nur während einer Buchung, also «extend» von „Zubehör hinzubuchen“ zu „Lastenrad buchen“, mit der Bedingung in einer Notiz.
• Und das Stornieren? Es ist kein extend von „Lastenrad buchen“, obwohl es mit der Buchung zu tun hat. Der Kunde storniert später, in einem eigenen Vorgang mit eigenem Ziel. Darum ist „Buchung stornieren“ ein eigenständiger Anwendungsfall mit eigener Linie zum Kunden.

Zeichenaufgaben

Zeichne erst selbst, dann klapp die Musterlösung auf und vergleiche Punkt für Punkt. Die Punkte sind Richtwerte im Stil der IHK; die tatsächliche Verteilung legt jede Prüfung selbst fest.

Typische Fehler

Jetzt selbst testen

Fünf Fragen zur Notation. Du hast so viele Versuche, wie du willst.