Klare und effektive visuelle Modelle zu erstellen, ist ein Eckpfeiler einer robusten Systemgestaltung. Wenn Stakeholder und Entwickler ein Diagramm betrachten, müssen sie die Funktionalität des Systems ohne Zweifel verstehen können. Ein Use-Case-Diagramm erfüllt diesen Zweck, indem es die Interaktionen zwischen Akteuren und dem System erfasst. Allerdings führt die Erstellung dieser Diagramme oft zu Verwirrung, wenn die zugrundeliegende Logik nicht stimmig ist. Diese Anleitung bietet einen strukturierten Ansatz, um sicherzustellen, dass Ihre Diagramme genau, lesbar und wertvoll sind.
🛠️ Phase 1: Festlegen der Systemgrenze
Bevor Sie ein einziges Rechteck oder eine Strichfigur zeichnen, müssen Sie den Umfang festlegen. Die Systemgrenze definiert, was innerhalb des Systems und was außerhalb des Systems liegt. Diese Unterscheidung ist entscheidend, da sie bestimmt, welche Elemente Teil der funktionalen Anforderungen sind und welche externen Einflüssen unterliegen.
- Identifizieren Sie das Kernsystem:Beschreiben Sie das Rechteck, das das System darstellt, deutlich. Vermeiden Sie vage Bezeichnungen wie „Das System“. Verwenden Sie spezifische Namen, wie beispielsweise „Zahlungsverarbeitungsmodul“ oder „Lagerverwaltungssystem“.
- Markieren Sie externe Entitäten:Alles, was außerhalb des Rechtecks liegt, ist ein Akteur oder ein externes System. Stellen Sie sicher, dass diese nicht innerhalb der Grenze gezeichnet werden, es sei denn, es handelt sich um Untersysteme.
- Klären Sie den Datenfluss:Obwohl Use-Case-Diagramme den Datenfluss nicht explizit darstellen, deutet die Grenze an, wo Daten in die funktionale Logik eintreten und diese verlassen.
Ohne eine klare Grenze können Akteure so erscheinen, als würden sie mit internen Details interagieren, anstatt mit bereitgestellten Diensten. Dies führt zu einem Modell, das zu detailliert und schwer zu pflegen ist.
👥 Phase 2: Korrektes Identifizieren von Akteuren
Akteure stellen die Rollen dar, die von Personen oder Systemen gespielt werden, die mit dem Use-Case-System interagieren. Sie sind die Auslöser von Aktionen oder die Empfänger von Ausgaben. Die korrekte Identifizierung der Akteure ist oft die häufigste Fehlerquelle bei der Erstellung von Diagrammen.
Was ist ein Akteur?
Ein Akteur ist eine Rolle, nicht unbedingt eine bestimmte Person. Eine Person kann mehrere Rollen übernehmen, und eine Rolle kann von mehreren Personen ausgeübt werden. Zum Beispiel ist ein „Manager“ ein Akteur, nicht „John Smith“. Außerdem kann ein Akteur auch ein anderes System sein, beispielsweise eine externe API oder eine veraltete Datenbank.
- Primäre Akteure: Sie initiieren die Interaktion, um ein bestimmtes Ziel zu erreichen. Sie sind die Benutzer des Systems.
- Sekundäre Akteure: Es handelt sich um Systeme oder Dienste, mit denen das Hauptsystem interagiert, um eine Aufgabe abzuschließen. Sie liefern Daten oder Dienste, initiieren aber nicht den Use-Case.
- Generisch vs. Spezifisch: Vermeiden Sie die Auflistung spezifischer Personen. Verwenden Sie rollenbasierte Bezeichnungen wie „Kunde“, „Admin“ oder „Drittanbieterdienst“.
Häufige Fehler bei der Akteuridentifikation
| Falscher Ansatz | Richtiger Ansatz |
|---|---|
| Beschriftung mit „John Doe“ | Beschriftung mit „Registrierter Benutzer“ |
| Platzieren von Akteuren innerhalb der Systemgrenze | Platzieren von Akteuren außerhalb der Systemgrenze |
| Erstellen von Akteuren für jeden Bildschirm | Erstellen von Akteuren für funktionale Rollen |
| Vergessen von systemübergreifenden Akteuren | Einbeziehung externer APIs als Akteure |
Durch Einhaltung der rollenbasierten Benennung und korrekter Platzierung bleibt das Diagramm stabil, selbst wenn das Personal wechselt.
🎯 Phase 3: Definieren von Use Cases
Ein Use Case stellt eine vollständige Funktionalitätseinheit dar, die einem Akteur Wert bietet. Es handelt sich nicht um eine einzelne Aktion, sondern um eine Folge von Aktionen, die ein Ziel erreicht. Die Namenskonvention für Use Cases ist für Klarheit entscheidend.
Namenskonventionen
Use Case-Namen sollten Verbalphrasen sein, die die Aktion aus der Perspektive des Akteurs beschreiben. Sie sollten präzise sein, aber dennoch ausreichend beschreibend, um selbstständig verständlich zu sein.
- Verbal-Objekt-Format:Beispiele sind „Auftrag verarbeiten“, „Bericht generieren“ oder „Profil aktualisieren“. Vermeiden Sie Nomen wie „Auftragsverarbeitung“, es sei denn, es bezieht sich auf ein bestimmtes Dokument und nicht auf eine Aktion.
- Zielgerichtet:Frage dich: „Was möchte der Akteur erreichen?“ Wenn die Antwort „Die Rechnung bezahlen“ lautet, ist der Use Case „Rechnung bezahlen“, nicht „Rechnung bezahlen – Bildschirm“.
- Konsistenz des Umfangs:Stellen Sie sicher, dass alle Use Cases auf der gleichen Abstraktionsstufe liegen. Mischen Sie keine hochwertigen Ziele („Konto verwalten“) mit niedrigstufigen Schritten („Passwort eingeben“).
Überprüfung der Feinheit
Wenn ein Use Case zu breit ist, wird er ungenau. Ist er zu schmal, entsteht Überlastung. Eine gute Faustregel ist, dass ein Use Case von einem Akteur in einer einzigen Sitzung durchführbar sein sollte oder eine eindeutige geschäftliche Transaktion darstellen sollte. Komplexe Workflows sollten in kleinere Use Cases aufgeteilt werden, die durch Beziehungen miteinander verknüpft sind.
🔗 Phase 4: Abbildung von Beziehungen
Die Stärke eines Use Case-Diagramms liegt in den Beziehungen zwischen Akteuren und Use Cases sowie zwischen Use Cases selbst. Diese Linien vermitteln die Logik des Systems.
Assoziation
Die durchgezogene Linie, die einen Akteur mit einem Use Case verbindet, zeigt an, dass der Akteur mit dieser Funktionalität interagiert. Jeder Akteur sollte mindestens eine Assoziation haben, und jeder Use Case sollte mindestens einen Akteur haben.
- Richtung: Obwohl sie oft bidirektional gezeichnet werden, beginnt der logische Fluss in der Regel beim Akteur, der die Anfrage initiiert.
- Mehrere Akteure: Ein einzelner Use Case kann mit mehreren Akteuren verknüpft sein. Zum Beispiel könnte „Bericht anzeigen“ mit „Manager“ und „Prüfer“ verknüpft sein.
Einbeziehungsbeziehung
Eine Einbeziehungsbeziehung zeigt an, dass ein Use Case immer das Verhalten eines anderen Use Cases beinhaltet. Der eingeschlossene Use Case ist notwendig, damit der Basis-Use Case sein Ziel erreichen kann. Denken Sie daran wie eine Unterprogramm-Aufruf.
- Wann verwenden:Verwenden Sie dies für gemeinsame Funktionalitäten, die über mehrere Use Cases hinweg geteilt werden. Zum Beispiel könnte „Benutzer authentifizieren“ in „Anmelden“, „Passwort zurücksetzen“ und „Anmeldeinformationen ändern“ eingeschlossen werden.
- Notation: Typischerweise dargestellt als gestrichelte Pfeil mit der Beschriftung „<<include>>“, der vom Basis-Use Case zum eingeschlossenen Use Case zeigt.
Erweiterungsbeziehung
Eine Erweiterungsbeziehung zeigt optionales Verhalten an. Der erweiternde Use Case fügt dem Basis-Use Case unter bestimmten Bedingungen Funktionalität hinzu. Dies ist nützlich für Fehlerbehandlung oder optionale Funktionen.
- Wann sollte es verwendet werden: Verwenden Sie dies für Ausnahmen oder Variationen. Zum Beispiel könnte „Benachrichtigung senden“ nur dann „Bestellung aufgeben“ erweitern, wenn die Zahlung fehlschlägt.
- Bedingtheit: Definieren Sie den Erweiterungspunkt oder die Bedingung immer klar. Der Basis-Use Case funktioniert auch ohne die Erweiterung.
Generalisierung
Generalisierung wird für Vererbung verwendet. Ein spezialisierter Akteur oder Use Case erbt das Verhalten eines allgemeineren. Dadurch wird Redundanz im Diagramm reduziert.
- Akteurvererbung: Wenn „Premium-Benutzer“ von „Registrierter Benutzer“ erbt, müssen Sie alle Assoziationen für „Registrierter Benutzer“ nicht erneut zeichnen.
- Use-Case-Vererbung: Wenn „Monatlichen Bericht generieren“ eine spezifische Art von „Bericht generieren“ ist, können Sie die Generalisierung verwenden, um die Hierarchie darzustellen.
🚫 Phase 5: Vermeidung häufiger Fehler
Selbst erfahrene Modellierer machen Fehler. Unten finden Sie eine Checkliste mit häufigen Fehlern und deren Lösungen, um die Diagrammqualität zu gewährleisten.
| Fehlerquelle | Auswirkung | Lösung |
|---|---|---|
| Überlappende Akteure | Verwirrung darüber, wer was tut | Trennen Sie Akteure klar voneinander; verwenden Sie Generalisierung, wenn die Rollen ähnlich sind |
| Zirkuläre Abhängigkeiten | Logische Schleifen, die die Fließrichtung unterbrechen | Überprüfen Sie die Include/Extend-Logik; stellen Sie sicher, dass Basis-Use Cases selbstständig sind |
| Zu viele Beziehungen | Das Diagramm wird unleserlich | Konsolidieren Sie gemeinsame Verhaltensweisen; verwenden Sie Anmerkungen für detaillierte Logik |
| Fehlende Akteure | Unvollständige Systemansicht | Überprüfen Sie alle funktionalen Anforderungen; stellen Sie sicher, dass jeder Use Case einen Auslöser hat |
| Interface-Verwirrung | UI mit Logik vermischen | Halten Sie Diagramme auf Funktionalität fokussiert, nicht auf Bildschirmlayout |
| Nicht verwendete Use Cases | Toter Code im Modell | Überprüfen Sie regelmäßig; entfernen Sie Use Cases ohne Akteure oder Abhängigkeiten |
🔍 Phase 6: Die Überprüfungsliste
Bevor Sie das Diagramm abschließen, durchlaufen Sie diese Überprüfungsliste. Dadurch wird sichergestellt, dass das Modell robust ist und für Entwicklungsteams bereit ist.
- Vollständigkeit: Hat jeder Use Case mindestens einen Akteur?
- Konsistenz: Sind alle Akteurnamen konsistent mit dem Glossar?
- Klarheit: Ist die Systemgrenze eindeutig beschriftet?
- Genauigkeit: Stimmen die Beziehungen (include/extend) logisch mit den Anforderungen überein?
- Lesbarkeit: Ist die Anordnung sauber? Kreuzen sich Linien unnötigerweise?
- Skalierbarkeit: Können neue Use Cases hinzugefügt werden, ohne die bestehende Struktur zu stören?
- Ausrichtung: Stimmt das Diagramm mit den übergeordneten Geschäftszielen überein?
- Dokumentation: Sind komplexe Use Cases mit Notizen oder Beschreibungen dokumentiert?
🔄 Phase 7: Verwaltung von Änderungen im Laufe der Zeit
Anforderungen entwickeln sich weiter. Software ist selten statisch. Ein Use-Case-Diagramm muss als lebendiges Dokument behandelt werden, das den aktuellen Zustand des Systems widerspiegelt. Die Pflege dieses Dokuments ist ebenso wichtig wie seine Erstellung.
Versionskontrolle
Verfolgen Sie Änderungen. Wenn ein Use Case hinzugefügt, geändert oder entfernt wird, aktualisieren Sie die Diagrammversion. Dies hilft bei der Überprüfung und beim Verständnis der Entwicklung des Systems.
Auswirkungsanalyse
Wenn sich eine Anforderung ändert, analysieren Sie, wie sich dies auf das Diagramm auswirkt. Wenn ein neuer Akteur eingeführt wird, prüfen Sie, ob bestehende Use Cases geändert werden müssen. Wenn ein Use Case entfernt wird, stellen Sie sicher, dass keine anderen Use Cases über eine include-Beziehung davon abhängen.
Überprüfung durch Stakeholder
Überprüfen Sie das Diagramm regelmäßig mit den Stakeholdern. Sie können erkennen, ob das Modell weiterhin ihrem mentalen Modell des Systems entspricht. Diese Rückkopplungsschleife stellt sicher, dass das Diagramm aktuell bleibt.
📏 Phase 8: Sicherstellung von Klarheit und Konsistenz
Visuelle Konsistenz unterstützt das Verständnis. Wenn das Diagramm unordentlich wirkt, könnte die dahinterliegende Logik als unordentlich wahrgenommen werden.
- Ausrichtung: Richten Sie Akteure und Use Cases aus. Verwenden Sie Gitterlinien oder Abstände, um eine strukturierte Anordnung zu schaffen.
- Farbverwendung: Während die Vermeidung von CSS-Stilen für rohes HTML erforderlich ist, sollten Sie in echten Modellierungstools Farben verwenden, um primäre und sekundäre Akteure zu unterscheiden oder veraltete Use Cases hervorzuheben.
- Beschriftungen: Stellen Sie sicher, dass alle Beschriftungen lesbar sind. Vermeiden Sie Abkürzungen, es sei denn, sie sind Standardbegriffe der Branche.
- Abstand: Lassen Sie ausreichend Platz um Elemente, um zu verhindern, dass Linien Text überlappen.
🧩 Integration mit anderen Modellen
Ein Use-Case-Diagramm wird selten isoliert verwendet. Es funktioniert am besten, wenn es mit anderen Modellierungstechniken integriert wird.
- Sequenzdiagramme: Verwenden Sie Sequenzdiagramme, um den Interaktionsablauf innerhalb eines bestimmten Use Cases detailliert darzustellen.
- Klassendiagramme: Verwenden Sie Klassendiagramme, um die Objekte zu definieren, die an den Use Cases beteiligt sind.
- Zustandsdiagramme: Verwenden Sie Zustandsdiagramme, um den Lebenszyklus eines Objekts darzustellen, das an einem Use Case beteiligt ist.
Durch die Verknüpfung dieser Modelle schaffen Sie eine umfassende Sicht auf das System, ohne das Use-Case-Diagramm selbst zu überladen. Das Use-Case-Diagramm bleibt der Einstiegspunkt zum Verständnis der Funktionalität, während andere Diagramme die Implementierungsdetails liefern.
🏁 Endgültige Überprüfungs-Schritte
Führen Sie vor der Verteilung des Diagramms eine letzte Sinnhaftigkeitsprüfung durch.
- Lesen Sie jede Beschriftung laut vor, um sicherzustellen, dass sie grammatikalisch sinnvoll ist.
- Stellen Sie sicher, dass kein Akteur isoliert ohne Verbindung ist.
- Überprüfen Sie, ob include/extend-Beziehungen nicht verwechselt werden.
- Stellen Sie sicher, dass die Systemgrenze alle vorgesehenen Funktionen umfasst.
- Bestätigen Sie, dass das Diagramm auf einer Seite passt oder logisch paginiert ist.
Durch die Einhaltung dieses strukturierten Checklists stellen Sie sicher, dass Ihre Diagramme nicht nur Bilder sind, sondern funktionale Kommunikationsmittel. Sie schließen die Lücke zwischen geschäftlichen Anforderungen und technischer Umsetzung. Indem Sie sich auf Rollen, Ziele und Beziehungen konzentrieren, erstellen Sie Modelle, die der Zeit und Veränderungen standhalten.
Denken Sie daran, das Ziel ist Klarheit. Wenn ein Stakeholder das Diagramm betrachtet und versteht, was das System tut, haben Sie Erfolg. Behalten Sie den Fokus auf Wert, halten Sie die Struktur logisch und pflegen Sie das Diagramm, während sich die Anforderungen entwickeln.