Richtlinie: Anwendungsfall
Ein Anwendungsfall beschreibt, was das System tut, um eine Anforderung zu erfüllen. Diese Richtlinie erläutert, wie Sie Anwendungsfälle identifizieren und entwickeln.
Beziehungen
Hauptbeschreibung

Erläuterung

Diese Definition enthält mehrere Schlüsselwörter:

  • Anwendungsfallinstanz. Die Reihenfolge, auf die in der Definition verwiesen wird, ist eigentlich ein spezifischer Ablauf von Ereignissen im System oder einer Instanz. Es sind viele Ereignisabläufe möglich, und viele können ähnlich sein. Zum besseren Verständnis eines Anwendungsfallmodells sollten Sie ähnliche Ereignisabläufe zu einem Anwendungsfall zusammenfassen. Das Identifizieren und Beschreiben eines Anwendungsfalls bedeutet im Grunde, eine Gruppe zusammengehöriger Ereignisabläufe zu identifizieren und zu beschreiben.
  • System führt aus. Das bedeutet, dass das System einen Anwendungsfall bereitstellt. Ein Akteur kommuniziert mit einer Anwendungsfallinstanz des Systems.
  • Ein wahrnehmbares Ergebnis von Wert. Sie können einen erfolgreich ausgeführten Anwendungsfall aufwerten. Ein Anwendungsfall muss sicherstellen, dass ein Akteur eine Aufgabe ausführen kann, die einen identifizierbaren Wert hat. Dies ist sehr wichtig, um die korrekte Granularitätsstufe für einen Anwendungsfall zu bestimmen. Korrekte Stufe meint, Anwendungsfälle zu erstellen, die nicht zu klein sind. Unter bestimmten Umständen können Sie einen Anwendungsfall als Planungseinheit in einer Organisation verwenden, zu der Personen gehören, die Akteure im System sind.
  • Aktionen. Eine Aktion ist eine rechenbetonte oder algorithmische Prozedur. Sie wird aufgerufen, wenn der Akteur ein Signal an das System sendet oder wenn das System ein Zeitereignis empfängt. Eine Aktion kann Signalübertragungen an den aufrufenden Akteur oder andere Akteure beinhalten. Eine Aktion ist atomar, d. h. sie wird entweder vollständig oder gar nicht ausgeführt.
  • Bestimmter Akteur. Der Akteur ist der Schüssel für das Aufspüren des richtigen Anwendungsfalls, insbesondere weil der Akteur Ihnen hilft, Anwendungsfälle zu vermeiden, die zu umfangreich sind. Stellen Sie sich als Beispiel ein Tool für visuelle Modellierung vor. An dieser Anwendung sind zwei Akteure beteiligt: ein Entwickler, der Systeme entwickelt und das Tool zur Unterstützung verwendet, und ein Systemadministrator, der das Tool verwaltet. Jeder diese Akteure hat seine eigenen Anforderungen an das System und benötigt deshalb eigene Anwendungsfälle.

Die Funktionalität eines Systems wird durch unterschiedliche Anwendungsfälle definiert, von denen jeder einen speziellen Ereignisablauf darstellt. Die Beschreibung eines Anwendungsfalls definiert, was im System passiert, wenn die Anwendungsfall ausgeführt wird.

In der Überschrift genannte Abbildung

Bei einem Geldautomaten kann der Client beispielsweise Geld von einem Konto abheben, Geld auf ein Konto einzahlen oder seinen Kontostand prüfen. Diese Funktionen entsprechen Abläufen, die Sie mit Anwendungsfällen darstellen können.

Jeder Anwendungsfall hat eine eigene Aufgabe, die er ausführen muss. Die gesammelten Anwendungsfälle sind alles Wege zur möglichen Verwendung des Systems. Sie bekommen eine Idee von der Aufgabe eines Anwendungsfalls, indem Sie sich einfach seinen Namen ansehen.

Anwendungsfälle finden

Die folgenden Fragen sind hilfreich bei der Ermittlung von Anwendungsfällen:

  • Wie lauten die Aufgaben für jeden identifizierten Akteur, an denen das System beteiligt sein könnte?
  • Muss der Akteur über bestimmte Vorkommnisse im System informiert werden?
  • Muss der Akteur das System über plötzliche, externe Änderungen informieren?
  • Liefert das System dem Geschäft das erforderliche Verhalten?
  • Können alle Funktionen von den identifizierten Anwendungsfällen ausgeführt werden?
  • Welche Anwendungsfälle unterstützen und pflegen das System?
  • Welche Informationen müssen im System geändert oder erstellt werden?

Anwendungsfälle, die häufig übersehen werden, weil sie nicht die typischen primären Funktionen des Systems darstellen, können den folgenden Kategorien zugeordnet werden:

  • Systemstart und -stopp.
  • Wartung des Systems, z. B. neue Benutzer hinzufügen und Benutzerprofile einrichten.
  • Pflege der im System gespeicherten Daten. Das System kann beispielsweise so entworfen sein, dass es parallel mit einen traditionellen System arbeiten muss und die Daten zwischen den beiden Systemen synchronisiert werden müssen.
  • Funktionalität, die erforderlich ist, um das Verhalten im System zu ändern. Ein Beispiel hierfür ist Funktionalität für das Erstellen neuer Berichte.

Wenn Sie ein Geschäftsanwendungsfallmodell und ein Geschäftsanalysemodell entwickelt haben, sind diese Artefakte ein guter Ausgangspunkte für die Identifizierung von Anwendungsfällen.

Entwicklung eines Anwendungsfalls

In frühen Iterationen in der Ausarbeitungsphase werden nur einige wenige Anwendungsfälle (die als architektonisch relevant erachtet werden) detailliert beschrieben. Sie sollten zuerst eine Skizze des Anwendungsfalls (schrittweise) entwickeln, bevor Sie in die Details gehen. Diese schrittweise Skizze sollte der erste Versuch sein, die Struktur des Ereignisablaufs des Anwendungsfalls zu definieren (siehe Ereignisablauf -Struktur). Beginnen Sie immer mit dem Basisablauf des Anwendungsfalls. Sobald eine Vereinbarung über die Skizze des Basisablaufs getroffen wurde, können Sie alternative Abläufe hinzufügen.

Gegen Ende der Ausarbeitung müssen alle Anwendungsfälle, die Sie detailliert beschreiben möchten, abgeschlossen sein.

Sind alle Anwendungsfälle detailliert beschrieben?

Es gibt häufig Anwendungsfälle in Ihrem Modell, die so einfach sind, dass sie keiner detaillierten Beschreibung des Ereignisablaufs bedürfen, und für die eine einfache schrittweise Skizze ausreicht. Die Kriterien für diese Entscheidung sind Folgende: 1. Unter den Benutzern besteht keine Uneinigkeit in Bezug auf die Bedeutung des Anwendungsfalls. 2. Die Designer und Tester sind mit dem Detaillierungsgrad der schrittweisen Skizze zufrieden. Beispiele hierfür sind Anwendungsfälle, die die einfache Eingabe von Daten oder den Abruf von Daten aus dem System beschreiben.

Umfang eines Anwendungsfalls

Es ist häufig schwierig zu entscheiden, ob eine Gruppe von Interaktionen zwischen Benutzer und System (oder ein Dialog) in einem oder mehreren Anwendungsfällen verwendet wird. Stellen Sie sich die Verwendung einer Recycling-Maschine vor. Der Kunde wirft Pfandartikel wie Dosen, Flaschen und Fässer in die Recycling-Maschine ein. Wenn der Kunde alle Pfandartikel eingeworfen hat, drückt er eine Taste, und es wird ein Beleg gedruckt. Diesen Beleg kann er an der Kasse gegen Geld eintauschen.

Ist es nun ein Anwendungsfall, einen Pfandartikel einzuwerfen, und ein anderer, den Beleg anzufordern? Oder ist alles zusammen ein Anwendungsfall? Es gibt zwei Aktionen, aber die eine Aktion stellt ohne die andere keinen Wert für den Kunden dar. Es ist vielmehr der vollständige Dialog (Einwurf der Pfandartikel bis hin zum Anfordern des Belegs), der für den Kunden einen Wert darstellt und für ihn Sinn macht. Deshalb ist der komplette Dialog, angefangen mit dem Einwurf des ersten Pfandartikels bis hin zum Drücken der Taste zum Anfordern des Belegs ein vollständiger Anwendungsfall.

Außerdem möchten Sie die beiden Aktionen zusammenhalten, um in der Lage zu sein, sie später zur gleichen Zeit zu prüfen, zu ändern, zu testen, Handbücher für sie zu schreiben und sie allgemein als Einheit zu verwalten. Dies wird in größeren Systemen ganz klar.

Wie werden Anwendungsfälle realisiert?

Ein Anwendungsfall beschreibt, was im System passiert, wenn ein Akteur mit dem System interagiert, um den Anwendungsfall auszuführen. Der Anwendungsfall definiert nicht, wie das System seine Aufgaben unter Verwendung kollaborierender Objekte ausführt. Dies wird den Anwendungsfallrealisierungen überlassen.

Beispiel:

Im Telefonbeispiel zeigt der Anwendungsfall neben anderen Dingen, dass das System ein Signal absetzt, wenn der Hörer abgenommen wird, und dass das System Ziffern empfängt, den empfangenden Teilnehmer sucht, sein Telefon klingeln lässt, die Verbindung herstellt, Sprache überträgt usw.

In einem ausführenden System entspricht eine Instanz eines Anwendungsfalls keinem bestimmten Objekt im Implementierungsmodell (z. B. einer Instanz einer Klasse im Code). Stattdessen entspricht die Instanz einem spezifischen Ereignisablauf, der von einem Akteur aufgerufen und neben anderen Objekten als Abfolge von Ereignissen ausgeführt wird. Anders ausgedrückt, Instanzen von Anwendungsfällen entsprechen kommunizierenden Instanzen implementierter Objekte. Dies wird als Realisierung des Anwendungsfalls bezeichnet. Häufig sind an Realisierungen mehrerer Anwendungsfälle dieselben Objekte beteiligt. Beispielsweise können die Anwendungsfälle "Einzahlen" und "Abheben" in einem Banksystem ein bestimmtes Kontoobjekt in ihren Realisierungen verwenden. Dies bedeutet nicht, dass die beiden Anwendungsfälle miteinander kommunizieren, sondern nur, dass sie dasselbe Objekt in ihren Realisierungen verwenden.

Ein Ereignisablauf setzt sich aus mehreren untergeordneten Abläufen zusammen. Sie können die Beschreibung eines untergeordneten Ablaufs in den Ereignisabläufen anderer Anwendungsfälle wiederverwenden. Untergeordnete Abläufe in der Beschreibung eines Ereignisablaufs eines Anwendungsfalls können auch in denen anderer Anwendungsfälle vorkommen. Im Design muss dieses gemeinsame Verhalten für alle relevanten Anwendungsfälle von denselben Objekten ausgeführt werden, d. h. dieses Verhalten darf nur von einer Gruppe von Objekten ausgeführt werden, egal in welchem Anwendungsfall.

Beispiel:

In einem Geldautomatensystem ist der erste untergeordnete Ablauf in den Anwendungsfällen "Bargeld abheben" und "Kontostand prüfen" derselbe. Der Ereignisablauf beider Anwendungsfälle beginnt mit der Überprüfung der Kartenidentität und des persönlichen Zugriffscodes des Clients.

Ein Anwendungsfall hat viele mögliche Instanzen

Eine Anwendungsfallinstanz kann einer nahezu unbegrenzten, aber einzeln benennbaren Anzahl von Pfaden folgen. Diese Pfade stellen die Optionen dar, die der Anwendungsfallinstanz in der Beschreibung ihrer Ereignisabläufe offen stehen. Der ausgewählte Pfad ist von Ereignissen abhängig. Zu den Ereignistypen gehören:

  • Eingaben eines Akteurs. Ein Akteur kann beispielsweise zwischen mehreren Optionen entscheiden, was als nächstes zu tun ist.

Beispiel:

Im Anwendungsfall "Artikel recyceln" im Recycling-Maschinensystem hat der Kunde immer zwei Möglichkeiten: einen weiteren Pfandartikel einwerfen oder den Beleg anfordern.

  • Überprüfung der Werte oder Typen eines internen Objekts oder Attributs. Der Ereignisablauf kann variieren, wenn ein Wert größer oder kleiner als ein bestimmter Wert ist.

Beispiel:

Im Anwendungsfall "Bargeld abheben" in einem Geldautomatensystem variiert der Ereignisablauf, wenn der Client mehr Geld abheben will, als auf seinem Konto verfügbar ist. Deshalb verfolgt die Anwendungsfallinstanz anderen Pfaden.

Parallelität von Anwendungsfallinstanzen

Instanzen mehrerer Anwendungsfälle und mehrere Instanzen desselben Anwendungsfalls können parallel ausgeführt werden, falls dies vom System unterstützt wird. Bei der Anwendungsfallmodellierung können Sie davon ausgehen, dass Instanzen von Anwendungsfällen parallel und ohne Konflikte ausgeführt werden können. Vom Designmodell wird erwartet, dass es diese Probleme löst, da die Anwendungsfallmodellierung nicht beschreibt, wie Dinge funktionieren. Eine Möglichkeit ist, davon auszugehen, dass jeweils nur eine Anwendungsfallinstanz aktiv ist und dass die Ausführung dieser Instanz eine atomare Aktion ist. Bei der Anwendungsfallmodellierung wird davon ausgegangen, dass die "interpretierende Maschine" eine unbegrenzte Kapazität hat, so dass die Serialisierung der Anwendungsfallinstanzen kein Problem darstellt.

Name

Jeder Anwendungsfall muss einen Namen haben, der Aufschluss darüber gibt, was durch die Interaktionen mit den Akteuren erreicht wird. Der Name kann zum besseren Verständnis aus mehreren Wörtern bestehen. Es ist nicht zulässig, denselben Namen für zwei Anwendungsfälle zu verwenden.

Beispiel:

Im Folgenden finden Sie Beispiele für Namensvarianten für den Anwendungsfall "Artikel recyceln" im Recycling-Maschinenbeispiel:

  • Pfandartikel entgegennehmen
  • Entgegennahme von Pfandartikeln
  • Pfandartikel zurückgegeben
  • Pfandartikel

Kurzbeschreibung

Die Kurzbeschreibung des Anwendungsfalls muss den Zweck des Anwendungsfalls widerspiegeln. Verwenden Sie für die Beschreibung die an dem Anwendungsfall beteiligten Akteure, das Glossar und definieren Sie bei Bedarf neue Konzepte.

Beispiel:

Im Folgenden finden Sie Beispiele für Kurzbeschreibungen für die Anwendungsfälle "Artikel recyceln" und "Neuen Flaschentyp hinzufügen" im Recycling-Maschinensystem:

Artikel recyceln: Der Benutzer verwendet diese Maschine, um alle zurückgegebenen Artikel (Flaschen, Dosen und Fässer) automatisch zählen zu lassen, und erhält anschließend einen Beleg. Gegen diesen Beleg erhält der Benutzer an der Kasse (Maschine) Kassenbeleg.

Neuen Flaschentyp hinzufügen: Neue Flaschentypen können der Maschine hinzugefügt werden, indem die Maschine im "Lernmodus" gestartet wird und 5 Exemplare des neuen Typs in die Maschine eingeworfen werden. Dabei kann die Maschine die Flaschen abmessen und lernen, sie zu identifizieren. Der Manager gibt den Pfandwert für den neuen Flaschentyp an.

Ereignisablauf - Inhalt

Der Ereignisablauf eines Anwendungsfalls enthält die wichtigsten Informationen, die von der Anwendungsfallmodellierung abgeleitet werden. Der Ereignisablauf des Anwendungsfalls muss so klar beschrieben werden, dass er für einen Ausstehenden leicht verständlich ist. Denken Sie daran, dass der Ereignisablauf vorstellen muss, was das System tut, und nicht, wie das System entworfen wird, um das erforderliche Verhalten zu erbringen.

Richtlinien für den Inhalt des Ereignisablaufs:

  • Beschreiben Sie, wie der Anwendungsfall beginnt und endet.
  • Beschreiben Sie, welche Daten zwischen dem Akteur und dem Anwendungsfall ausgetauscht werden.
  • Beschreiben Sie keine Details der Benutzerschnittstelle, sofern sie nicht erforderlich sind, um das Verhalten des Systems verstehen zu können. Beispielsweise empfiehlt es sich häufig, eine begrenzte webspezifische Terminologie zu verwenden, wenn vorab bekannt ist, dass die Anwendung eine webbasierte Anwendung sein wird. Andernfalls laufen Sie Gefahr, dass der Anwendungsfalltext als zu abstrakt beurteilt wird. Beispiele für Wörter, die in Ihrer Terminologie enthalten sein sollten, sind "navigieren", "durchsuchen", "Hyperlink" "Seite", "Übergeben" und "Browser". Es ist jedoch nicht ratsam, Referenzen auf "Rahmen" oder "Webseiten" zu verwenden, in der Annahmen bezüglich der Grenzen zwischen diesen Elementen getroffen werden. Dies ist eine kritische Designentscheidung.  
  • Beschreiben Sie den Ereignisablauf, nicht nur die Funktionalität. Beginnen Sie deshalb jede Aktion mit "Wenn der Akteur...".
  • Beschreiben Sie nur die Ereignisse, die zum Anwendungsfall gehören, und nicht, was in anderen Anwendungsfällen oder außerhalb des Systems passiert.
  • Vermeiden Sie vage Terminologie.
  • Beschreiben Sie den Ereignisablauf detailliert. Alle "Was"-Fragen müssen beantwortet werden. Denken Sie daran, dass Testdesigner diesen Text für die Identifizierung von Anwendungsfällen verwenden.

Wenn Sie bestimmte Begriffe in anderen Anwendungsfällen verwendet haben, müssen Sie sicherstellen, dass dieselben Begriffe auch in diesem Anwendungsfall verwendet werden und ihre Bedeutung dieselbe ist. Allgemeine Begriffe sollten zur besseren Verwaltung in ein Glossar aufgenommen werden.

Ereignisablauf - Struktur Seitenanfang

Die beiden Hauptteile des Ereignisablaufs sind der Basisereignisablauf und alternative Ereignisabläufe. Der Basisereignisablauf muss die Ereignisse abdecken, die "normalerweise" eintreten, wenn der Anwendungsfall ausgeführt wird. Die alternativen Ereignisabläufe decken optionales oder außergewöhnliches Verhalten in Bezug auf das normale Verhalten und Varianten des normalen Verhaltens ab. Sie können sich die alternativen Ereignisabläufe als "Umleitungen" vorstellen, von denen einige zum Basisereignisablauf zurückkehren und andere die Ausführung des Anwendungsfalls beenden.

In der Überschrift genannte Abbildung

Die typische Struktur des Ereignisablaufs. Der gerade Pfeil stellt den Basisereignisablauf dar und die Kurven alternative Pfade zum normalen. Einige Alternativpfade kehren zum Basisereignisablauf zurück und andere beenden den Anwendungsfall.

Der Basisereignisablauf und die alternativen Ereignisabläufe müssen weiter in Schritte oder untergeordnete Ereignisabläufe strukturiert werden. Dabei muss Ihr oberstes Ziel die Lesbarkeit des Textes sein (siehe auch Ereignisablauf - Stil). Eine Faustregel ist, dass ein untergeordneter Ablauf ein Segment des Verhaltens im Anwendungsfall sein sollte, das einen klaren Zweck hat und in dem Sinne "atomar" ist, dass Sie entweder alle oder keine der beschriebenen Aktionen ausführen. Sie müssen möglicherweise mehrere Ebenen von untergeordneten Abläufen anlegen, was sie jedoch sofern möglich vermeiden sollten, weil es den Text komplexer macht und die Verständlichkeit beeinträchtigt. Sie können die Struktur des Ereignisablaufs mit einem Aktivitätsdiagramm darstellen. Informationen hierzu finden Sie in Richtlinie für Arbeitsergebnis: Aktivitätsdiagramm im Anwendungsfall.

Dieser Typ geschriebenen Textes, der in aufeinander folgende Abschnitte gegliedert ist, vermittelt dem Leser aufgrund seiner Strukturierung gleich, dass es eine Reihenfolge bei den untergeordneten Abläufen gibt. Um Missverständnisse zu vermeiden, sollten Sie immer aufzeigen, ob die Reihenfolge der untergeordneten Abläufe fest ist oder nicht. Überlegungen dieser Art beziehen sich häufig auf folgende Aspekte:

  • Geschäftsregeln. Beispielsweise muss der Benutzer erst berechtigt werden, damit das System bestimmte Daten zur Verfügung stellen kann.
  • Benutzerschnittstellendesign. Beispielsweise darf das System eine bestimmte Verhaltensabfolge nicht umsetzen, die für manche Benutzer intuitiv ist, aber für andere nicht.

Um klar herauszuarbeiten, wo ein alternativer Ereignisablauf in die Struktur eingefügt werden kann, müssen Sie Folgendes für jede "Umleitung" des Basisereignisablaufs beschreiben:

  • Wo das alternative Verhalten im Basisereignisablauf eingefügt werden kann.
  • Die Bedingung, die erfüllt sein muss, damit das alternative Verhalten gestartet werden kann.
  • Wie und wo der Basisereignisablauf wiederaufgenommen werden kann und wie der Anwendungsfall endet.

Beispiel:

Dies ist ein alternativer untergeordneter Ablauf im Anwendungsfall "Artikel zurückgeben" im Recycling-Maschinensystem.

2.1. Flasche klemmt

Wenn in Abschnitt 1.5 "Einlegen des Pfandartikels" eine Flasche in der Öffnung stecken bleibt, erkennen die Sensoren an der Öffnung und an der Abmessungsvorrichtung dieses Problem. Das Förderband wird gestoppt, und die Maschine setzt einen Alarm an den Operator ab. Die Maschine wartet, bis der Operator meldet, dass das Problem behoben ist. Anschließend fährt die Maschine mit Abschnitt 1.9 des Basisablaufs fort.

Im vorherigen Beispiel wird der alternative Ereignisablauf an einer bestimmten Position im Basisereignisablauf eingefügt. Es gibt auch alternative Ereignisabläufe, die an mehreren Positionen eingefügt werden können, einige sogar an einer beliebigen Position im Basisereignisablauf.

Beispiel:

Dies ist ein alternativer untergeordneter Ablauf im Anwendungsfall "Artikel zurückgeben" im Recycling-Maschinensystem.

2.2. Vordere Abdeckung ist entfernt

Wenn irgend jemand die vordere Abdeckung der Recycling-Maschine entfernt, wird die Dosenverdichtung inaktiviert. Es ist nicht möglich, die Dosenverdichtung zu starten, wenn die vordere Abdeckung entfernt ist. Das Entfernen der vorderen Abdeckung löst außerdem einen Alarm beim Operator aus. Wenn die vordere Abdeckung wieder angebracht wird, nimmt die Maschine den Betrieb an der Stelle im Basisereignisablauf wieder auf, an der sie zuvor gestoppt wurde.

Wenn der alternative Ereignisablauf sehr einfach ist, ist es verführerisch, ihn einfach (mit einem formlosen "if-then-else"-Konstrukt) im Basisereignisablauf zu beschreiben. Dieser Weg sollte jedoch vermieden werden. Wenn zu viele Alternativen beschrieben werden, ist das normale Verhalten schwerer erkennbar. Außerdem wird der Text durch das Einfügen alternativer Pfade in den Basisereignisablauf "pseudocodeähnlich" und schwieriger zu lesen.

Im Allgemeinen gilt, dass durch Extrahieren von Teilen des Ereignisablaufs und getrennte Beschreibung dieser Teile die Lesbarkeit des Basisereignisablaufs und die Struktur des Anwendungsfalls und des Anwendungsfallmodells verbessert werden können. Sie können extrahierte Teile wie folgt modellieren:

  • Als alternativen Ereignisablauf im Basisanwendungsfall, wenn es sich um eine einfache Variante, Option oder Ausnahme vom Basisereignisablauf handelt.
  • Als expliziten Einschluss im Basisanwendungsfall (siehe Richtlinie für Arbeitsergebnis: Einschlussbeziehung), wenn es sich um Verhalten handelt, das Sie kapseln möchten, um es in anderen Anwendungsfällen wiederverwenden zu können.
  • Als impliziten Einschluss im Basisanwendungsfall (siehe Richtlinie für Arbeitsergebnis: Erweiterungsbeziehung), wenn der Basisereignisablauf des Basisanwendungsfalls vollständig ist, d. h. einen definierten Anfang und ein definiertes Ende hat. Der erweiternde Ablauf muss von der Natur her so gestaltet sein, dass es vorzuziehen ist, ihn in der Beschreibung des Basisanwendungsfalls zu verbergen, damit dieser weniger komplex erscheint.
  • Als untergeordneten Ablauf im Basisereignisablauf, wenn keine der oben genannten Alternativen angewendet werden kann. Im Anwendungsfall "Mitarbeiterdaten verwalten" kann es beispielsweise separate untergeordnete Abläufe für das Hinzufügen, Löschen und Ändern von Mitarbeiterdaten geben.

Ereignisablauf - Stil Seitenanfang

Sie können Anwendungsfälle in vielen verschiedenen Stilen beschreiben. Im folgenden Beispiel wird der Basisereignisablauf des Anwendungsfalls "Auftrag verwalten" gezeigt, der in drei verschiedenen Stilen beschrieben wird, die sich primär in ihrer Formalität unterscheiden. Der erste Stil im Beispiel 1 wird empfohlen, weil er einfach zu verstehen ist und weil die Reihenfolge, in der die Ereignisse aufeinander folgen, klar ersichtlich ist. Der Text ist in nummerierte und benannte Unterabschnitte eingeteilt. Die Nummerierung vereinfacht die Referenz auf einen Unterabschnitt. Die Namen von Unterabschnitten geben dem Leser eine Kurzübersicht über den Ereignisablauf, wenn er durch den Text blättert und einfach nur die Überschriften liest.

In der Beschreibung des Ereignisablaufs in Beispiel 2 ist die Reihenfolge, in der die Ereignisse aufeinander folgen, nicht klar erkennbar. Wenn Sie diesen Stil wählen, können Ihnen und anderen wichtige Aspekte des Systems nicht auffallen.

Beispiel 3 zeigt einen weiteren Stil, der hilfreich sein kann, wenn Sie Schwierigkeiten haben, die Reihenfolge der Ereignisse klar zu formulieren. Dieser pseudocodeähnliche Stil ist präziser, aber der Text ist für Personen, die nicht aus dem technischen Bereich kommen, schwieriger zu lesen und zu erfassen, insbesondere wenn der Ereignisablauf schnell erfasst werden muss.

Beispiel 1:
1.1. Beginn des Anwendungsfalls

Dieser Anwendungsfall beginnt, wenn der Akteur Operator das System auffordert, einen Auftrag "Messungen" zu erstellen. Das System ruft daraufhin alle Akteure Netzelemente, ihre Messobjekte und die entsprechenden Messfunktionen ab, die für diesen Operator verfügbar sind. Verfügbare Netzelemente sind die Elemente, die in Betrieb sind und auf die der Operator zugreifen darf. Die Verfügbarkeit der Messfunktionen richtet sich danach, was für einen bestimmten Messobjekttyp konfiguriert wurde.

1.2. Auftrag "Messung" konfigurieren

Das System erlaubt dem Akteur Operator, die Netzelemente auszuwählen, die gemessen werden sollen, und zeigt dann an, welche Messobjekte für die ausgewählten Netzelemente verfügbar sind. Das System erlaubt dem Operator, die gewünschten Messobjekte und anschließend die Messfunktionen auszuwählen, die für jedes einzelne Messobjekt konfiguriert werden sollen.

Das System erlaubt dem Operator, im Auftrag "Messung" einen Kommentar einzufügen.

Der Operator weist das System an, den Auftrag "Messung" auszuführen. Das System antwortet, indem es einen eindeutigen Namen für den Auftrag "Messung" generiert und Standardwerte dafür konfiguriert, wann, wie oft und wie lange die Messung durchgeführt werden soll. Die Standardwerte sind für jeden Operator eindeutig. Das System erlaubt dem Operator anschließend, diese Standardwerte zu bearbeiten.

1.3. Auftrag initialisieren

Der Operator weist das System an, den Auftrag "Messung" zu initialisieren. Das System zeichnet daraufhin die Identität des erstellenden Operator, das Erstellungsdatum und den "geplanten" Status des Auftrags "Messung" auf.

1.4. Ende des Anwendungsfalls

Das System bestätigt dem Operator die Initialisierung des Auftrags "Messung", und der Auftrag "Messung" wird anderen Akteuren zur Ansicht zur Verfügung gestellt.


Einen Anwendungsfall beschreiben: Mit diesem Stil lässt sich der Text leicht lesen und der Ereignisablauf problemlos verfolgen. Sie sollten diesen Stil in Ihren Beschreibungen anstreben.

Beispiel 2:
Auftraggeber können Aufträge erstellen, um Messdaten aus den Netzelementen zu sammeln.

Das System ordnet dem Auftrag einen eindeutigen Namen sowie Standardwerte zu, die die Dauer und den Zeitpunkt der Messung und die Anzahl der Wiederholungen festlegen. Der Auftraggeber kann diese Werte ändern.

Der Auftraggeber muss außerdem angeben, welche Messfunktion, welches Netzelement und welche Messobjekte gültig sind. Der Auftraggeber kann auch einen persönlichen Kommentar zum Auftrag hinzufügen.

Nachdem die erforderlichen Informationen definiert wurden, wird ein neuer Auftrag mit den definierten Attributen, dem Namen des Erstellers und dem Erstellungsdatum erstellt und initialisiert. Der Status des Auftrags wird auf "Geplant" gesetzt. (Die möglichen Werte für den Status sind: Geplant, Ausführung, Abgeschlossen, Abgebrochen und Fehlerhaft.)

Anschließend wird die Benutzerschnittstelle benachrichtigt, dass ein neuer Auftrag erstellt wurde. Sie erhält eine Referenz auf den neuen Auftrag, damit er angezeigt werden kann.


Einen Anwendungsfall beschreiben: Dieser Stil ist lesbar, aber der Ereignisablauf ist nicht klar ersichtlich.

Beispiel 3:

'Auftrag verwalten' (Benutzeridentität)
REPEAT
<= 'Menü Auftrag verwalten anzeigen'
IF ( =>  'Auftrag erstellen' (Messfunktion,
Netzelement, Messobjekt)) THEN
   Das System findet einen eindeutigen Namen, Standardwerte für Zeitpunkt und
   Dauer der Messung.
<= 'Auftrag anzeigen' (Standardattribute)
REPEAT
    => 'Auftrag bearbeiten' (Zu änderndes Attribut, Neuer Wert des Attributs)
    <= 'Anzeige aktualisieren' (Neue Attribute)
UNTIL (Alle Attribute sind definiert)
REPEAT
    IF ( => 'Auftrag bearbeiten' (Zu änderndes Attribut, Neuer Wert des Attributs))
THEN <= 'Anzeige aktualisieren' (Neue Attribute)
ELSIF ( => 'Auftrag speichern' (Auftragsidentität, Attribute)) THEN
    Der Auftrag wird im System mit den definierten Attributen, dem Namen
    des Erstellers, dem Erstellungsdatum und dem Status 'Geplant'
    erstellt und initialisiert.
    <= 'Neuer Auftrag erstellt' (Der Auftrag)
ENDIF
UNTIL (=> 'Verlassen')
    ENDIF
UNTIL 'Auftrag verwalten verlassen'

Einen Anwendungsfall beschreiben: Hier hat der Autor einen formalen Stil mit Pseudocode gewählt. Bei diesem Stil lassen sich die Prozessschritte nicht so einfach erfassen, aber dieser Stil kann hilfreich sein, wenn sich der Ereignisablauf nur sehr schwer präzise beschreiben lässt.

Ereignisablauf - Beispiel

Die vollständige Beschreibung des Ereignisablaufs des Anwendungsfalls "Auftrag verwalten" einschließlich seiner alternativen Abläufe könnte wie folgt aussehen:

1. Basisereignisablauf

1.1. Beginn des Anwendungsfalls

Dieser Anwendungsfall beginnt, wenn der Akteur Operator das System auffordert, einen Auftrag "Messungen" zu erstellen. Das System ruft daraufhin alle Akteure Netzelemente, ihre Messobjekte und die entsprechenden Messfunktionen ab, die für diesen Operator verfügbar sind. Verfügbare Netzelemente sind die Elemente, die in Betrieb sind und auf die der Operator zugreifen darf. Die Verfügbarkeit der Messfunktionen richtet sich danach, was für einen bestimmten Messobjekttyp konfiguriert wurde.

1.2. Auftrag "Messung" konfigurieren

Das System erlaubt dem Akteur Operator, die Netzelemente auszuwählen, die gemessen werden sollen, und zeigt dann an, welche Messobjekte für die ausgewählten Netzelemente verfügbar sind. Das System erlaubt dem Operator, die gewünschten Messobjekte und anschließend die Messfunktionen auszuwählen, die für jedes einzelne Messobjekt konfiguriert werden sollen.

Das System erlaubt dem Operator, im Auftrag "Messung" einen Kommentar einzufügen.

Der Operator weist das System an, den Auftrag "Messung" auszuführen. Das System antwortet, indem es einen eindeutigen Namen für den Auftrag "Messung" generiert und Standardwerte dafür konfiguriert, wann, wie oft und wie lange die Messung durchgeführt werden soll. Die Standardwerte sind für jeden Operator eindeutig. Das System erlaubt dem Operator anschließend, diese Standardwerte zu bearbeiten.

1.3. Auftrag initialisieren

Der Operator weist das System an, den Auftrag "Messung" zu initialisieren. Das System zeichnet daraufhin die Identität des erstellenden Operator, das Erstellungsdatum und den "geplanten" Status des Auftrags "Messung" auf.

1.4. Ende des Anwendungsfalls

Das System bestätigt dem Operator die Initialisierung des Auftrags "Messung", und der Auftrag "Messung" wird anderen Akteuren zur Ansicht zur Verfügung gestellt.

2. Alternative Ereignisabläufe

2.1. Keine Netzelemente verfügbar

Wenn sich in 1.1, "Beginn des Anwendungsfalls", herausstellt, dass keine Netzelemente verfügbar sind, die für diesen Operator gemessen werden können, informiert das System den Operator. Der Anwendungsfall ist damit beendet.

2.2. Keine Messfunktionen verfügbar

Wenn sich in 1.2, "Auftrag "Messung" konfigurieren", herausstellt, dass keine Messfunktionen für die ausgewählten Netzelemente verfügbar sind, informiert das System den Operator und erlaubt dem Operator, andere Netzelemente auszuwählen.

2.3. Auftrag "Messung" abbrechen

Das System erlaubt dem Operator, alle Aktionen jederzeit während der Ausführung des Anwendungsfalls abzubrechen. Daraufhin kehrt das System in den Zustand zurück, den es vor Beginn des Anwendungsfalls hatte, und beendet den Anwendungsfall.

Sonderanforderungen Seitenanfang

In den Sonderanforderungen für einen Anwendungsfall beschreiben Sie alle Anforderungen an den Anwendungsfall, die vom Ereignisablauf nicht abgedeckt werden. Dies sind die nicht funktionalen Anforderungen, die sich auf das Designmodell auswirken. Weitere Informationen zu nicht funktionalen Anforderungen finden Sie in Richtlinie für Arbeitsergebnis: Anwendungsfallmodell. Sie können diese Anforderungen in Kategorien wie Benutzerfreundlichkeit, Zuverlässigkeit, Leistung und Ersetzbarkeit einteilen, aber normalerweise sind die Sonderanforderungen so gering, dass eine solche Gruppierung nicht sehr wertvoll ist.

Beispiel:

Im Recycling-Maschinensystem könnte Folgendes eine Sonderanforderung an den Anwendungsfall "Pfandartikel zurückgeben" sein:

Die Maschine muss in der Lage sein, Pfandartikel mit einer Zuverlässigkeit von mehr als 95 Prozent zu erkennen.

Vorbedingungen und Nachbedingungen

Es kann hilfreich sein, mit Vorbedingungen und Nachbedingungen zu arbeiten, um Beginn und Ende des Ereignisablaufs deutlich zu machen. Verwenden Sie dieses Mittel jedoch nur, wenn es für die Zielgruppe des Anwendungsfalls einen Nutzen hat.

In der Überschrift genannte Abbildung

Eine Vorbedingung ist der Zustand des Systems und seiner Umgebung, der erforderlich ist, damit der Anwendungsfall gestartet werden kann. Eine Nachbedingung beschreibt die Zustände, die ein System nach dem Ende des Anwendungsfalls haben kann.

Berücksichtigen Sie Folgendes:

  • Die Zustände, die durch Vor- und Nachbedingungen beschrieben werden, müssen Zustände sein, die der Benutzer wahrnehmen kann. "Der Benutzer hat sich am System angemeldet" oder "Der Benutzer hat das Dokument geöffnet" sind Beispiele für wahrnehmbare Zustände.
  • Eine Vorbedingung ist eine Vorgabe für den Start eines Anwendungsfalls. Es ist nicht das Ereignis, das den Anwendungsfall startet.
  • Eine Vorbedingung für einen Anwendungsfall ist keine Vorbedingung für ausschließlich einen untergeordneten Ablauf, obwohl Sie auch Vorbedingungen und Nachbedingungen für untergeordnete Abläufe definieren können.
  • Eine Nachbedingung für einen Anwendungsfall muss wahr sein, egal welche alternativen Abläufe ausgeführt wurden. Sie gilt nicht nur für den Hauptablauf. Wenn eine Aktion scheitern kann, sollten Sie dies in der Nachbedingung wie folgt formulieren: "Die Aktion ist abgeschlossen bzw., wenn eine Aktion gescheitert ist, wurde die Aktion nicht ausgeführt". Die Formulierung "Die Aktion ist abgeschlossen" wäre nicht ausreichend.
  • Wenn Sie Nachbedingungen zusammen mit Erweiterungsbeziehungen verwenden, müssen Sie darauf achten, dass der erweiternde Anwendungsfall keinen untergeordneten Ablauf einfügt, der gegen die Nachbedingung im Basisanwendungsfall verstößt.
  • Nachbedingungen können ein wirkungsvolles Tool für die Beschreibung von Anwendungsfällen sein. Sie definieren zuerst, was vom Anwendungsfall erwartet wird - die Nachbedingung. Anschließend können Sie beschreiben, wie diese Bedingung erreicht wird - den erforderlichen Ereignisablauf.

Beispiel:

Eine Vorbedingung für den Anwendungsfall "Bargeld abheben" in der Geldautomatenmaschine: Der Kunde hat eine Karte, die in den Kartenleser passt, er hat eine PIN und er ist beim Banksystem registriert.

Eine Nachbedingung für den Anwendungsfall "Bargeld abheben" in der Geldautomatenmaschine: Am Ende des Anwendungsfalls sind alle Konten- und Transaktionsprotokolle ausgeglichen, die Kommunikation mit dem Banksystem wird erneut initialisiert, und der Kunde erhält seine Karte zurück.

Erweiterungspunkte

Ein Erweiterungspunkt ist eine Möglichkeit, einen Anwendungsfall zu erweitern. Er hat einen Namen und eine Liste von Referenzen auf eine oder mehrere Positionen im Ereignisablauf des Anwendungsfalls. Ein Erweiterungspunkt kann auf eine einzelne Position zwischen zwei wichtigen Schritten im Anwendungsfall verweisen. Er kann auch auf eine Gruppe eindeutiger Positionen verweisen.

Mit benannten Erweiterungspunkten können Sie die Spezifikation des Verhaltens des erweiternden Anwendungsfalls von den internen Details des Basisanwendungsfalls trennen. Der Basisanwendungsfall kann geändert oder umgeordnet werden. Solange die Namen der Erweiterungspunkte dieselben bleiben, hat dies keine Auswirkung auf den erweiternden Anwendungsfall. Gleichzeitig überladen Sie die Beschreibung des Ereignisablaufs des Basisanwendungsfalls nicht mit Details zu den Positionen, an denen Verhalten eingefügt werden kann. Weitere Informationen hierzu finden Sie in Richtlinie für Arbeitsergebnis: Erweiterungsbeziehung.

Beispiel:

In einem Telefonsystem kann der Anwendungsfall "Anruf tätigen" mit dem abstrakten Anwendungsfall "Anruferidentität anzeigen" erweitert werden. Dieser optionale Service, häufig auch "Anrufer-ID" genannt, kann vom empfangenden Teilnehmer vorausgesetzt werden. Eine Beschreibung des Erweiterungspunkts im Anwendungsfall "Anruf tätigen" könnte wie folgt aussehen:

Name: Identität anzeigen

Position: Nach Abschnitt 1.9 "Telefon des Empfangsteilnehmers klingeln lassen"

Anwendungsfalldiagramme

In welchem Zusammenhang ein Anwendungsfall mit Akteuren und anderen Anwendungsfalldiagrammen steht, können Sie in einem Anwendungsfalldiagramm darstellen (in seltenen Fällen auch mehreren Diagrammen), dessen Eigner der Anwendungsfall ist. Dies kann hilfreich sein, wenn an dem Anwendungsfall viele Akteure beteiligt sind oder der Anwendungsfall Beziehungen zu vielen anderen Anwendungsfällen hat. Ein Diagramm dieser Art hat "lokalen" Charakter, da es das Anwendungsfallmodell nur aus der Perspektive eines Anwendungsfalls zeigt und nicht dazu bestimmt ist, allgemeine Fakten über das gesamte Anwendungsfallmodell zu erläutern. Weitere Informationen finden Sie in Richtlinie zum Arbeitsergebnis: Anwendungsfalldiagramm.