Verhaltensdiagramm
Use-Case-Diagramm
Wer nutzt das System und wofür?
Am Anfang eines Projekts steht meist eine unsortierte Wunschliste, und niemand weiß, welche davon das System selbst erfüllen soll. Das Use-Case-Diagramm ordnet diese Liste, indem es für jede Rolle außerhalb des Systems festhält, welches Ziel sie mit dem System erreichen will. In der Prüfung erkennst du diese Aufgabe daran, dass nach Nutzern und deren Zielen gefragt wird und nicht nach einem Ablauf.
Beziehungen im Vergleich.
Durchgezogene Linie ohne Pfeil zwischen Akteur und Use Case.
Du hast einen Akteur und einen Use Case notiert und willst zeigen, dass beide etwas miteinander zu tun haben. Genau dafür ist die Assoziation da: Sie sagt, dass dieser Akteur an diesem Use Case beteiligt ist, ihn also auslöst oder daran mitwirkt. Die Linie bekommt keine Pfeilspitze, weil sie keine Richtung und keinen Datenfluss beschreibt. Multiplizitäten an den Enden sind nach UML 2.5.1, Kapitel 18 erlaubt, in Prüfungsaufgaben aber selten nötig.
Gestrichelter Pfeil vom Basis-Use-Case zum eingebundenen Use Case.
Ein Teilschritt taucht in mehreren Use Cases auf, zum Beispiel das Prüfen der PIN. Statt ihn überall neu zu beschreiben, lagerst du ihn als eigenen Use Case aus und bindest ihn mit «include» ein. Der eingebundene Use Case läuft dann bei jeder Ausführung des Basis-Use-Case mit, er ist ein Pflichtteil. Der gestrichelte Pfeil startet beim Basis-Use-Case und zeigt auf den Teil, der eingebunden wird.
Gestrichelter Pfeil von der Erweiterung zum Basis-Use-Case.
Manche Schritte passieren nur manchmal, etwa das Einlösen eines Gutscheins beim Bestellen. Solche Fälle hängst du mit «extend» an, statt sie in den Basis-Use-Case hineinzuschreiben. Hat die Erweiterung eine Bedingung, läuft sie nur, wenn diese erfüllt ist. Ohne Bedingung läuft sie beim Erreichen des Erweiterungspunkts immer. Ohne sie funktioniert der Basis-Use-Case vollständig. Der Pfeil geht von der Erweiterung aus und zeigt auf den erweiterten Use Case, also genau andersherum als bei «include».
Extension Point im Use Case, Bedingung in einer Notiz am Pfeil.
Eine Erweiterung allein sagt noch nicht, wann und wo sie greift. Deshalb nennt der Basis-Use-Case im Kompartiment "extension points", also in einem eigenen Abschnitt der Ellipse, die Stelle im Ablauf, an der erweitert werden darf. An der extend-Beziehung steht dann die Bedingung, unter der die Erweiterung tatsächlich läuft. UML 2.5.1, Kapitel 18 sieht dafür eine gestrichelt am Pfeil befestigte Notiz vor. Die Darstellung der Notiz ist optional; ohne modellierte Bedingung wird am Erweiterungspunkt immer erweitert.
Hohles Dreieck am allgemeinen Akteur.
Zwei Rollen unterscheiden sich nur in wenigen Punkten, etwa Kunde und Premiumkunde. Damit du nicht alle Linien doppelt ziehst, verbindest du beide mit einer Generalisierung: Der spezielle Akteur erbt sämtliche Assoziationen des allgemeinen und bekommt nur seine zusätzlichen Use Cases eigens angebunden. Das hohle Dreieck sitzt am allgemeinen Akteur, genau wie bei der Vererbung im Klassendiagramm.
Hohles Dreieck am allgemeinen Use Case.
Ein Ziel lässt sich auf mehreren Wegen erreichen, zum Beispiel Bezahlen per Karte oder per Rechnung. Wenn jeder Weg für sich ein vollwertiges Ziel ist, zeichnest du ihn als eigenen Use Case und generalisierst ihn auf das gemeinsame Ziel. Der spezielle Use Case übernimmt das Verhalten des allgemeinen und darf es spezialisieren, muss aber weiterhin als dessen Variante verwendbar sein. Anders als bei «extend» gibt es hier keine Bedingung, sondern eine eigenständige Variante.
Symbole und Notation.
13 Elemente
Akteur
Strichmännchen mit Rollenname
Ein Akteur ist eine Rolle außerhalb des Systems, die mit ihm zusammenarbeitet. Das kann eine Person, eine Organisation, ein Fremdsystem oder ein Zeitgeber sein. Gemeint ist immer die Rolle, nie eine konkrete Person und nie ein Teil des Systems selbst.
Akteur als System
Rechteck mit «actor»
Wenn ein anderes System der Akteur ist, wirkt das Strichmännchen irreführend. UML 2.5.1, Kapitel 18 erlaubt deshalb ein Rechteck mit dem Schlüsselwort «actor» als gleichwertige Schreibweise. Inhaltlich bleibt es ein Akteur mit allen Regeln, die für Akteure gelten.
Use Case
Ellipse mit Verb und Objekt
Ein Use Case ist ein abgeschlossenes Ziel, das ein Akteur mit Hilfe des Systems erreicht. Der Name enthält deshalb ein Verb und sein Objekt, also "Bestellung aufgeben" statt "Bestellung". Ein einzelner Klick oder Eingabeschritt ist kein Use Case.
Systemgrenze
Rechteck mit Systemname
Die Systemgrenze legt fest, worüber das Diagramm überhaupt spricht. Alles, was das System leistet, steht als Use Case innerhalb des Rechtecks, alle Akteure stehen außerhalb. Beschriftet wird das Rechteck mit dem Namen des betrachteten Systems.
Assoziation
Durchgezogene Linie ohne Pfeil
Die Assoziation verbindet einen Akteur mit einem Use Case, an dem er beteiligt ist. Sie hat keine Pfeilspitze, weil sie weder eine Richtung noch einen Datenfluss beschreibt. Sie sagt nur, dass diese Rolle dieses Ziel verfolgt.
«include»
Gestrichelt, Pfeil zum Pflichtteil
Mit «include» bindet ein Basis-Use-Case einen anderen Use Case ein, der bei jeder Ausführung mitläuft. So beschreibst du einen gemeinsamen Pflichtteil nur einmal. Der gestrichelte Pfeil geht vom Basis-Use-Case aus und zeigt auf den eingebundenen.
«extend»
Gestrichelt, Pfeil zum Basis-Use-Case
Mit «extend» ergänzt du Verhalten an einem Erweiterungspunkt, bei Bedarf unter einer Bedingung. Ohne Bedingung wird dort immer erweitert. Der Basis-Use-Case bleibt ohne die Erweiterung vollständig und weiß nichts von ihr. Der gestrichelte Pfeil geht von der Erweiterung aus und zeigt auf den erweiterten Use Case.
Bedingung
Notiz am extend-Pfeil
Die Bedingung sagt, wann eine Erweiterung tatsächlich ausgeführt wird. UML 2.5.1, Kapitel 18 zeigt sie als Notiz, die gestrichelt am extend-Pfeil hängt. Auch die Erweiterungspunkte können dort stehen. Ohne Bedingung wird am Erweiterungspunkt immer erweitert.
Extension Point
Kompartiment "extension points"
Der Extension Point benennt die Stelle im Ablauf, an der eine Erweiterung ansetzen darf. Er steht in einem eigenen Abschnitt der Ellipse unter dem Namen des Use Case. Die extend-Beziehung verweist dann auf genau diesen Punkt.
Akteur-Generalisierung
Hohles Dreieck am allgemeinen Akteur
Die Generalisierung zeigt, dass eine Rolle eine besondere Form einer anderen Rolle ist. Der spezielle Akteur erbt alle Assoziationen des allgemeinen und bekommt nur seine zusätzlichen Use Cases eigens angebunden. Das hohle Dreieck sitzt am allgemeinen Akteur.
Use-Case-Generalisierung
Hohles Dreieck am allgemeinen Use Case
Der spezielle Use Case ist eine eigenständige Variante des allgemeinen, zum Beispiel Bezahlen per Karte gegenüber Bezahlen. Er übernimmt dessen Verhalten und darf es spezialisieren, muss aber weiterhin als Variante des allgemeinen Use Case verwendbar sein. Anders als bei «extend» hängt das nicht an einer Bedingung.
Multiplizität
Zahl oder Bereich am Linienende
Die Multiplizität an einem Linienende sagt, wie viele Akteure oder Ausführungen an einer Beziehung beteiligt sind. Bei einer Partie mit zwei bis vier Spielern hältst du das so fest. In Prüfungsaufgaben ist die Angabe erlaubt, aber selten verlangt.
Notiz
Rechteck mit Eselsohr, gestrichelt angehängt
Eine Notiz nimmt Freitext auf, der sich mit den Symbolen nicht ausdrücken lässt, etwa eine Annahme oder eine offene Frage. Sie wird mit einer gestrichelten Linie an das Element gehängt, zu dem sie gehört. Nach UML 2.5.1, Kapitel 7 ist ein solcher Kommentar an jedes Element erlaubt.
So liest und zeichnest du ein Use-Case-Diagramm.
Wozu das Diagramm da ist
In der Prüfung bekommst du einen Text über eine Bibliothek oder einen Onlineshop und sollst zeigen, wer das System benutzt und wozu. Genau das hält ein Use-Case-Diagramm fest: Für jede Rolle außerhalb des Systems steht darin, welche Ziele sie mit dem System erreichen kann. Im Projektalltag hilft dasselbe Bild dabei, sich mit Kunden auf den Umfang eines Systems zu einigen, bevor jemand über Masken oder Datenbanken spricht.
Woher die Notation kommt
UML wird von der Object Management Group standardisiert, einem Gremium, das technische Standards pflegt. Die aktuelle Fassung ist UML 2.5.1, und Use-Case-Diagramme stehen dort in Kapitel 18. Die Spezifikation legt fest, welche Symbole es gibt und was sie bedeuten. Wie du das Diagramm anordnest, welche Farben du nimmst und mit welchem Werkzeug du zeichnest, ist nicht geregelt.
So liest du es
Beginne beim Rechteck: Sein Name sagt, über welches System das Diagramm spricht. Innerhalb des Rechtecks liegen die Use Cases als Ellipsen, jeweils mit Verb und Objekt beschriftet, außerhalb stehen die Akteure. Üblich, aber nicht vorgeschrieben, ist die Anordnung mit den auslösenden Rollen links und den Fremdsystemen rechts. Eine Linie ohne Pfeilspitze heißt: Dieser Akteur ist an diesem Ziel beteiligt. Gestrichelte Pfeile zwischen zwei Ellipsen tragen «include» oder «extend»: Sie kennzeichnen eingebundenes Verhalten oder eine Erweiterung an einem Erweiterungspunkt. Eine optionale Bedingung in einer Notiz am extend-Pfeil schränkt ein, wann erweitert wird.
Eine Sache zeigt das Diagramm bewusst nicht: die Reihenfolge. Aus den Linien lässt sich nicht ablesen, was zuerst passiert, was danach kommt oder was bei einem Fehler geschieht. Auch der gestrichelte include-Pfeil ist keine Ablaufrichtung, sondern nur die Aussage "dieser Teil gehört immer dazu". Den Ablauf hält stattdessen die Use-Case-Beschreibung fest, ein kurzer Text pro Ellipse mit Auslöser, Vorbedingung, Standardablauf in nummerierten Schritten, Abweichungen und Ergebnis. Erst beide zusammen ergeben ein vollständiges Bild. Wenn dir das Diagramm zu wenig sagt, fehlen meistens diese Beschreibungen und nicht weitere Ellipsen.
So zeichnest du es in der Prüfung
- 1Markiere im Aufgabentext, welches System gemeint ist, und zeichne dafür ein Rechteck mit diesem Namen. Alles, was dieses System nicht selbst tut, bleibt draußen.
- 2Sammle die Rollen, die mit dem System zu tun haben, und setze sie als Akteure außen an das Rechteck. Notiere Rollennamen wie Kunde oder Bibliothekar, keine Personennamen. Fremdsysteme darfst du als Rechteck mit «actor» zeichnen.
- 3Schreibe die Ziele als Ellipsen in das Rechteck, jeweils mit Verb und Objekt, zum Beispiel "Medium ausleihen". Wenn ein Eintrag nur ein einzelner Eingabeschritt wäre, gehört er in die Beschreibung und nicht ins Diagramm.
- 4Verbinde jeden Akteur mit den Use Cases, an denen er beteiligt ist, mit einer durchgezogenen Linie ohne Pfeilspitze.
- 5Prüfe, ob ein Teilschritt in mehreren Use Cases vorkommt, etwa "Ausweis prüfen". Lagere ihn als eigene Ellipse aus und ziehe einen gestrichelten «include»-Pfeil vom Basis-Use-Case dorthin.
- 6Nimm dir die Fälle vor, die nur manchmal passieren. Zeichne sie als eigene Ellipse und ziehe einen gestrichelten «extend»-Pfeil von dieser Erweiterung auf den Basis-Use-Case. Notiere die Bedingung in einer Notiz am Pfeil. Ohne modellierte Bedingung wird am Erweiterungspunkt immer erweitert.
- 7Gehe zum Schluss die Rollen und Ziele durch: Unterscheiden sich zwei Rollen nur durch zusätzliche Rechte, verbinde sie mit einer Generalisierung. Ist ein Use Case nur eine Variante eines anderen, gilt dasselbe.
Prüfe dich selbst: In einem Ticketsystem meldet ein Mitarbeiter eine Störung, und dabei wird immer eine Ticketnummer erzeugt. Wenn die Störung als kritisch eingestuft ist, geht zusätzlich eine Benachrichtigung an die Rufbereitschaft. Welche der beiden Verbindungen zeichnest du als «include», welche als «extend», und in welche Richtung zeigen die Pfeile?
Typische Prüfungsfehler.
6 Paare
Pfeilrichtung bei include vertauscht.
Viele lesen den Pfeil als Ablauf und zeichnen ihn in Richtung dessen, was danach passiert. «include» beschreibt aber keine Reihenfolge, sondern eine Abhängigkeit: Der Basis-Use-Case braucht den anderen. Der Pfeil startet deshalb bei Bestellen und zeigt auf Bezahlen.
Pfeilrichtung bei extend vertauscht.
Wer sich «include» gemerkt hat, zeichnet «extend» oft in dieselbe Richtung. Bei extend ist es genau umgekehrt, weil der Basis-Use-Case nichts von seiner Erweiterung wissen muss. Der Pfeil startet bei der Erweiterung Gutschein und zeigt auf Bestellen.
Akteur steht in der Systemgrenze.
Der Kunde gehört gefühlt zum Shop, also landet er beim Zeichnen leicht mit im Rechteck. Ein Akteur ist aber definitionsgemäß eine Rolle außerhalb des Systems, sonst würde das System sich selbst bedienen. Innerhalb der Systemgrenze stehen nur die Use Cases, Akteure daneben.
Use Cases als Ablaufschritte verkettet.
Aus dem Aktivitätsdiagramm ist der Gedanke vertraut, einen Ablauf in Schritte zu zerlegen, und die Ellipsen laden dazu ein. Ein Use-Case-Diagramm zeigt jedoch keine Reihenfolge, sondern nur Ziele. Einzelschritte wie Name eingeben und Passwort eingeben gehören in die Use-Case-Beschreibung von Anmelden, nicht in eigene Ellipsen.
Akteure direkt miteinander verbunden.
Wenn Kunde und Support im Alltag miteinander sprechen, wirkt eine Linie zwischen beiden naheliegend. Im Diagramm geht es aber nur um die Zusammenarbeit mit dem System, deshalb laufen alle Verbindungen über einen Use Case. Die einzige erlaubte Linie direkt zwischen zwei Akteuren ist die Generalisierung.
Optionales als include statt extend.
«include» wird oft als "gehört dazu" gelesen, und ein Gutschein gehört ja irgendwie zum Bestellen. «include» bedeutet aber jedes Mal, ohne Ausnahme. Da nur manche Bestellungen einen Gutschein enthalten, ist es eine Erweiterung mit Bedingung, also «extend» von Gutschein auf Bestellen.
Zwei vollständige Beispiele.
Geldautomat: Akteur-Generalisierung, Fremdsystem, include und extend mit Bedingung.
Links stehen die Rollen, rechts das Bankensystem für PIN-Prüfung, Buchung, Kontostand und Limitänderung. Premiumkunde übernimmt die Beteiligungen von Kunde. Für dieses Beispiel gilt als zusätzliche Geschäftsregel: Nur Premiumkunden dürfen am Automaten ihr Limit erhöhen. Alle drei Kundenfunktionen schließen die PIN-Prüfung ein. Die Quittung erweitert Geld abheben nur auf Wunsch. Das Diagramm beschreibt Ziele und Beteiligte; die Reihenfolge von PIN-Prüfung, Buchung und Auszahlung gehört in die Ablaufbeschreibung.
Bibliothek: Use-Case-Generalisierung, externer Zeitgeber als Akteur, mehrere Rollen.
Fernleihe ausleihen spezialisiert hier die tatsächliche Ausleihe eines bereits eingetroffenen Mediums einer anderen Bibliothek. Das bloße Bestellen einer Fernleihe wäre ein anderes Ziel und keine Spezialisierung von Medium ausleihen. Die Ausweisprüfung gilt auch für die spezialisierte Ausleihe. Ein externer Zeitgeber stößt den Mahnungsversand über das Mahnsystem an; die abstrakte Zeit selbst ist kein Akteur. Die Rolle Student spezialisiert Nutzer. Medium erfassen ist dem Bibliothekar zugeordnet; Zugriffsrechte müssen zusätzlich als Geschäftsregeln festgelegt werden.