Es gibt zwei häufige Missverständnisse bezüglich der Use-Case-Modellierung:
Ein Missverständnis ist, dass das Use-Case-Diagramm zu einfach sei, da es nichts Wichtiges erkläre und nicht einmal zeichnenswert sei.
Ein weiteres Missverständnis ist genau das Gegenteil des ersten. Einige Menschen glauben, dass das Use-Case-Diagramm so mächtig sei, dass es viele verschiedene Aspekte einer Software darstellen könne, von der Beschreibung von Systemanforderungen bis hin zur Modellierung der internen Verhaltensweisen des Systems.
Was ist ein Use-Case?
Was ist ein Use-Case-Diagramm
Ist die Use-Case-Modellierung einfach oder mächtig?
A Use-Caseist eine Liste von Aktionen oder Ereignisschritten, die typischerweise die Interaktion zwischen einem Akteur (im Unified Modeling Language (UML) als Akteur bezeichnet) und einem System zur Erreichung eines Ziels definieren. Akteure können Personen oder andere externe Systeme sein. In der Systemtechnik werden Use-Cases auf einer höheren Ebene eingesetzt als in der Softwaretechnik und stellen in der Regel Aufgaben- oder Interessengruppenziele dar.
Was ist ein Use-Case-Diagramm?
Ein Use-Case-Diagramm ist in der Regel einfach. Es zeigt nicht die Details der Use-Cases:
- Es fasst nur zusammeneinige der Beziehungenzwischen Use-Cases, Akteuren und Systemen.
- Es tutnicht die Reihenfolgein der die Schritte ausgeführt werden, um die Ziele jedes Use-Cases zu erreichen.

Wie gesagt, sollte ein Use-Case-Diagramm einfach sein und nur wenige Formen enthalten. Wenn Ihr Diagramm mehr als 20 Use-Cases enthält, nutzen Sie das Use-Case-Diagramm vermutlich falsch.
Was ist Use-Case-Modellierung?
Die Use-Case-Modellierung ist eine einfache Antwort auf die Frage „Was möchte der Benutzer (Kunde)?“ Sie ermöglicht es Ihnen, visuell darzustellen, was der Benutzer erreichen möchte, indem er das Endprodukt nutzt, das ein System, eine Software, ein Programm usw. sein kann. Die Use-Case-Modellierung ist eine nützliche Technik, die Softwareentwicklern eine solide Grundlage für die Entwicklung von Software-Systemen bietet, die den Kundenbedürfnissen entsprechen.
Obwohl die in Use-Case-Diagrammen verwendete Notation einfach erscheinen mag und nicht viele Details vermittelt, beeinflusst die Art und Weise, wie Use-Cases gesammelt, organisiert und ausgearbeitet werden, stark die Richtung des Softwareentwicklungslebenszyklus und damit die Qualität des endgültigen Softwareprodukts.
10 praktische Tipps für die Use-Case-Modellierung
In diesem Artikel werden wir zehn Tipps durchgehen, um die Wirksamkeit des Zeichnens von Use-Case-Diagrammen zu maximieren. Wir werden nicht im Detail erklären, was ein Use-Case ist, sondern einige zentrale Konzepte zur UML-Modellierung, Use-Case-Diagrammen und Anforderungserfassung behandeln.
1. Denken Sie von der Perspektive des Endbenutzers aus
Es ist klar, dass Sie die Erwartungen der Benutzer kennen müssen, um ein funktionierendes Software-System zu erstellen, und dieses Prinzip ist besonders wichtig bei der Use-Case-Modellierung. Viele Menschen behandeln die Use-Case-Modellierung fälschlicherweise als Prozess zur Modellierung von Systemfunktionen, was falsch ist. Genauer gesagt ist die Use-Case-Modellierung eine Methode, um zu modellieren, was die Benutzer wollen. Jeder Use-Case in einem Use-Case-Diagramm sollte ein beobachtbares Ziel durch die Interaktion des Benutzers mit der endgültigen Software oder dem System erzeugen. Manchmal ist ein Benutzerziel dasselbe wie eine Systemfunktion, aber das ist nicht immer der Fall. Zum Beispiel ist „Anmelden“ eine Systemfunktion, aber definitiv kein Benutzerziel – Niemand startet ein Programm, meldet sich an und geht weg! Je mehr Systemfunktionen Sie in einem Use-Case-Diagramm zeichnen, desto weniger effektiv kann das Use-Case-Modell verwendet werden, um die echten Erwartungen der Benutzer während des gesamten Softwareentwicklungsprozesses auszudrücken. Daher sollten Sie beim Erstellen eines Use-Case-Modells versuchen, alles zunächst von der Perspektive des Endbenutzers aus zu betrachten.
2. Vermeiden Sie lange Use-Case-Namen
Wenn Sie ein Use-Case-Diagramm für ein Geldautomatensystem lesen, welchen der folgenden Use-Cases möchten Sie in dem Diagramm sehen? „Geld abheben“ und „Geld abheben und Kontostand aktualisieren“. Der zweite Use-Case scheint eher beschreibend zu sein, oder? Was ist mit 50 oder mehr verschiedenen Use-Cases mit einem so langen Namen? Sie möchten das Diagramm vermutlich nicht mehr lesen und Ihre Augen könnten sogar schmerzen.
Einer der Gründe, warum wir Modellierung benötigen, ist, dass wir ein komplexes Software-System auf einfache und übersichtliche Weise verstehen möchten. Deshalb hat die UML uns viele verschiedene Notationen zur Verfügung gestellt, wobei jede eine spezifische Perspektive bei der Beschreibung eines kompletten Software-Systems darstellt. Dieses „Geist“ gilt auch für die Benennung von Use-Cases. Wenn wir Use-Cases mit detaillierter Beschreibung benennen, warum verwenden wir dann nicht einfach eine Textdatei? Um ein Use-Case-Diagramm leicht verständlich zu machen, ist es wichtig, die Namen der Use-Cases kurz zu halten, gleichzeitig aber beschreibend zu sein. Halten Sie die Namen kurz und überlassen Sie die detaillierte Beschreibung dem Beschreibungsteil der Use-Cases.
3. Ein Akteur ist eine Rolle, keine echte Person
Einige Menschen versuchen, Mitarbeiter in einer Organisation als Akteure in einem Use-Case-Diagramm darzustellen, was dazu führt, dass das Diagramm Personen wie Peter, Mary, Daisy usw. enthält. Denken Sie daran, dass ein Akteur eine eindeutige Rolle darstellt, die aus Personen, Sub-Systemen oder anderen Entitäten mit eindeutigen Eigenschaften besteht und die gleichen Ziele und Erwartungen verfolgt.
4. Modellieren Sie gemeinsame Use-Cases mit Beziehungen
Ein Use-Case stellt ein Benutzerziel dar, das durch eine Reihe von Schritten erreicht werden kann. Wenn genau dieselben Schritte in mehreren Use-Cases auftreten, können Sie optional einen neuen Use-Case für die gemeinsamen Schritte erstellen und diesen mit den Use-Cases verbinden, die die Schritte auslösen. Durch die Verwendung eines eingeschlossenen Use-Cases wird deutlich, dass die einschließenden Use-Cases tatsächlich dieselben Schritte teilen, wie sie durch den eingeschlossenen Use-Case dargestellt werden, ohne jegliche Unsicherheit.
5. Modellieren Sie außergewöhnliches Verhalten
Die Extend-Beziehung kann verwendet werden, um anzugeben, wann und wie das Verhalten eines Use-Cases durch einen anderen Use-Case ausgelöst werden kann. Die Erweiterung erfolgt an Erweiterungspunkten, die im erweiterten Use-Case definiert sind. Der erweiternde Use-Case definiert die Schritte, die der erweiterte Use-Case unter bestimmten Bedingungen ausführen kann.
6. Modellieren Sie Szenarien mit Ablauf von Ereignissen
Ein Use-Case stellt ein Benutzerziel dar, das durch eine Folge von Schritten erreicht werden kann. Einige Menschen versuchen, die Schritte direkt im Use-Case-Diagramm zu modellieren, indem sie Akteur und Use-Case mit vielen Verbindungen verbinden, als ob dies die Schritte darstellen würden – was definitiv falsch ist. Stattdessen können die Schritte eines Use-Cases gut im Use-Case-Ablauf der Ereignisse-Editor.
Der Ablauf der Ereignisse-Editor ist tabellarisch gestaltet, wobei jede Zeile einen Schritt des Use-Cases darstellt. Dort können Sie die Schritte aufschreiben, mit oder ohne bedingten Ablauf. Sie können auch Formatierungen auf den Text anwenden, um wichtige Ideen hervorzuheben.
7. Nutzen Sie Stereotypen sinnvoll zur Kategorisierung
Ein Stereotyp ist ein Mechanismus, der es Ihnen ermöglicht, domänenspezifische Notation zusätzlich zu den Standardnotationen einzuführen. Ein Stereotyp wird in spitzen Klammern (Guillemets) über dem Namen der Form angezeigt, wenn das Stereotyp angewendet wird. Die richtige Verwendung von Stereotypen hilft den Lesern, die Unterschiede zwischen Use-Cases leichter zu erkennen.
8. Modellieren Sie den detaillierten Systemablauf mit einem Sequenzdiagramm
SequenzdiagrammErmöglicht Ihnen, das Systemverhalten durch die Darstellung der Kommunikation und des Nachrichtenaustauschs zwischen Objekten über die Zeit zu modellieren. Aber wo soll man anfangen? Anstatt zu raten, welche Interaktion zu modellieren ist, können Sie stattdessen mit der Berücksichtigung der Benutzerbedürfnisse beginnen, was genau das ist, was ein Use-Case-Modell darstellen soll.
Wir wissen, dass jeder einzelne Use-Case ein einzigartiges Benutzerziel darstellt. Ein Sequenzdiagramm aus einem Use-Case zu zeichnen bedeutet, dass Sie modellieren, was das Computersystem tun sollte, um das Benutzerziel zu erfüllen. Idealerweise gibt es keine redundanten Entwürfe, da alle Sequenzdiagramme aus Use-Cases erstellt werden, die darstellen, was der Benutzer möchte.
9. Wenden Sie bei Bedarf die gleiche Breite auf Use-Cases an
Da die Namen von Use-Cases unterschiedlich lang sind, ist es normal, dass die Use-Cases unterschiedliche Breiten haben. Um das Diagramm ansprechender und leichter lesbar zu gestalten, wäre es schön, sie auf die gleiche Breite anzupassen.
10. Platzieren Sie Akteure und Use-Cases sinnvoll
Ein Use-Case-Diagramm mit zufällig platzierten Akteuren und Use-Cases ist definitiv eine Qual für die Leser. Man muss das Diagramm sorgfältig untersuchen, um die gewünschten Informationen aus den verstreuten Akteuren und Use-Cases zu entnehmen. Es wäre schön, die Formen ordentlich anzuordnen. Sie können Use-Cases gegebenenfalls auch mit Paketformen gruppieren.
Referenzen:
- Was ist ein Use-Case-Diagramm?
- Arten von Akteuren im Use-Case-Modell
- Benutzeranforderungen mit Use-Case-Diagrammen identifizieren
- Was ist eine Anwendungsfalldokumentation?
- Ein praktischer Leitfaden zur Robustheitsanalyse
- Benutzerstory im Vergleich zum Anwendungsfall für agile Softwareentwicklung
- Anwendungsfall-getriebener Ansatz für agile Entwicklung




