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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
'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.
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.
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.
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.
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.
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"
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.
|