Ein Anwendungsfallmodell ist ein Modell der geplanten Funktionen des Systems und der Systemumgebung und dient als
Vertrag zwischen dem Kunden und den Entwicklern. Anwendungsfälle dienen als einheitlicher Leitfaden für die gesamte
Systementwicklung. Dasselbe Anwendungsfallmodell ist das Ergebnis der Disziplin Anforderungen und wird als Eingabe für
die Disziplinen Analyse & Design und Test verwendet.
Die folgende Abbildung zeigt einen Teil eines Anwendungsfallmodells für die Recycling-Maschine.
Ein Anwendungsfalldiagramm, das ein Beispiel für einen Anwendungsfallmodell mit Akteuren und Anwendungsfällen zeigt.
Es gibt viele Methoden für die Modellierung eines Systems, und jede dient einem anderen Zweck. Primär wird ein
Anwendungsfallmodell jedoch verwendet, um dem Kunden oder Benutzer das Verhalten des Systems zu vermitteln. Deshalb
muss das Modell leicht verständlich sein.
Die Benutzer und alle anderen Systeme, die möglicherweise mit dem System interagieren, sind die Akteure. Da sie
Systembenutzer darstellen, helfen sie, das System einzugrenzen und tragen zu einem klareren Bild bei, was das System zu
leisten hat. Anwendungsfälle werden auf der Basis der Anforderungen von Akteuren entwickelt. So wird sichergestellt,
dass das System den Erwartungen der Benutzer entspricht.
Für die Ermittlung der Akteure und Anwendungsfälle werden die Anforderungen von Kunden und potenzieller Benutzer als
elementare Informationen herangezogen. Die ermittelten Anwendungsfälle und Akteure müssen kurz beschrieben werden.
Bevor die Anwendungsfälle detailliert beschrieben werden, muss das Anwendungsfallmodell vom Kunden geprüft werden, um
sicherzustellen, dass alle Anwendungsfälle gefunden wurden und zusammen das liefern, was der Kunde erwartet.
In einer iterativen Entwicklungsumgebung wählen Sie jeweils einen Teil der Anwendungsfälle aus, die in einer Iteration
detailliert beschrieben werden. Weitere Informationen hierzu finden Sie in Aufgabe:
Anwendungsfälle nach Priorität sortieren.
Nachdem die Akteure und Anwendungsfälle ermittelt wurden, werden die Ereignisabläufe jedes Anwendungsfalls detailliert
beschrieben. Diese Beschreibungen zeigen, wie das System mit den Akteuren interagiert und was das System in jedem
einzelnen Fall tut.
Das fertig gestellte Anwendungsfallmodell (einschließlich der Beschreibungen der Anwendungsfälle) wird abschließend
geprüft, und die Entwickler und Kunden verwenden es, um die erwartete Funktionsweise des Systems zu vereinbaren.
Es ist nicht ungewöhnlich, dass das Anwendungsfallmodell in eine funktionale Dekomposition des Systems ausartet. Um
dies zu verhindern, sollten Sie auf folgende Symptome achten:
-
"Kleine" Anwendungsfälle, d. h. die Beschreibung der Ereignisabläufe besteht aus nur einem oder einigen wenigen
Sätzen.
-
"Viele" Anwendungsfälle, d. h. die Anzahl der Anwendungsfälle geht in die Hunderte.
-
Anwendungsfallnamen wie "Diese Operation mit diesen Daten ausführen" oder "Diese Funktion mit diesen Daten
ausführen". "Persönliche Identifikationsnummer an einem Geldautomaten eingeben" sollte beispielsweise nicht als
gesonderter Anwendungsfall für den Geldautomaten modelliert werden, da niemand das System ausschließlich für diesen
Zweck verwenden würde. Ein Anwendungsfall ist ein vollständiger Ablauf von Ereignissen, der insgesamt einen Wert
für einen Akteur darstellt.
Zur Vermeidung funktionaler Dekomposition müssen Sie sicherstellen, dass das Anwendungsfallmodell hilft, Fragen wie die
folgenden zu beantworten:
-
Wie ist der Kontext des Systems?
-
Warum wird das System erstellt?
-
Was will der Benutzer mit der Verwendung des Systems erreichen?
-
Welchen Wert hat das System für den Benutzer?
Es ist relativ einfach zu verstehen, dass Anwendungsfälle ein probates Mittel sind, um die funktionalen Anforderungen
eines Systems zu erfassen. Aber wie steht es mit den nicht funktionalen Anforderungen? Was sind sie und wie werden sie
erfasst?
Nicht funktionale Anforderungen werden häufig in die Kategorien Benutzerfreundlichkeit, Zuverlässigkeit, Leitung und
Ersetzbarkeit eingestuft (siehe auch Konzept:
Anforderungen). Es sind häufig Anforderungen, die den Bedarf an Konformität mit gesetzlichen Bestimmungen zum
Ausdruck bringen. Es können auch Designvorgaben sein, die auf das verwendete Betriebssystem, die Plattformumgebung,
Kompatibilitätsanforderungen oder geltende Anwendungsstandards zurückzuführen sind. Im Allgemeinen lässt sich sagen,
dass jede Anforderung, die maximal eine Designoption zulässt, als Designvorgabe betrachtet werden muss.
Viele nicht funktionale Anforderungen gelten für einen einzelnen Anwendungsfall und werden in den Eigenschaften dieses
Anwendungsfalls erfasst. In diesem Fall werden sie im Ereignisablauf des Anwendungsfalls oder als Sonderanforderung des
Anwendungsfalls erfasst (siehe Richtlinie:
Anwendungsfall).
Beispiel:
Beispiel für eine nicht funktionale Anforderung im Anwendungsfall "Pfandartikel zurückgeben" in einem System für eine
Recycling-Maschine:
Die Maschine muss in der Lage sein, Pfandartikel mit einer Zuverlässigkeit von mehr als 95 Prozent zu erkennen.
Häufig gelten die nicht funktionalen Anforderungen für das gesamte System. Solche Anforderungen werden in den
ergänzenden Spezifikationen erfasst (siehe Arbeitsergebnis: Ergänzende Spezifikationen).
Beispiel:
Beispiel für eine das gesamte System betreffende nicht funktionale Anforderung im System für eine Recycling-Maschine:
Die Maschine kann jeweils nur einen Benutzer bedienen.
Eines der schwierigeren Dinge, die man lernen muss, ist, wie man bestimmt, auf welcher Detailebene die Anwendungsfälle
"beginnen und enden" sollen. Wo beginnen Features und wo beginnen Anwendungsfälle und wo enden Anwendungsfälle und wo
beginnt das Design? Anwendungsfälle und Softwareanforderungen sollten beschreiben, "was" das System tut und nicht
"wie". Schauen Sie sich den folgenden Graphen an:
Das Ziel einer Person ist der Ausgangspunkt einer anderen Person.
Je nach Hintergrund verwenden Sie einen anderen Kontext, um zu entscheiden, was Sie für das "Was" und was für das "Wie"
halten. Dies muss berücksichtigt bei der Entscheidung darüber, ob ein bestimmtes Detail in das Anwendungsfallmodell
aufgenommen werden soll oder nicht, berücksichtigt werden.
Es gibt eine Unterscheidung zwischen konkreten und abstrakten Anwendungsfällen. Ein konkreter Anwendungsfall
wird von einem Akteur eingeleitet und stellt einen vollständigen Ereignisablauf dar. "Vollständig" bedeutet, dass eine
Instanz des Anwendungsfalls die gesamte, vom Akteur angeforderte Operation ausführt.
Ein abstrakter Anwendungsfall wird selbst nicht instanziert. Abstrakte Anwendungsfälle sind in anderen
Anwendungsfällen enthalten (siehe Richtlinie
für Arbeitsergebnis: Einschlussbeziehung), erweitern andere Anwendungsfälle (siehe Richtlinie für Arbeitsergebnis: Erweiterungsbeziehung) oder generalisieren andere
Anwendungsfälle (siehe Richtlinie: Anwendungsfallgeneralisierung). Wenn ein konkreter Anwendungsfall
eingeleitet wird, wird eine Instanz dieses Anwendungsfalls erstellt. Diese Instanz zeigt unter anderem das Verhalten,
das in den zugeordneten abstrakten Anwendungsfällen spezifiziert ist. Deshalb werden keine separaten Instanzen aus
abstrakten Anwendungsfällen erstellt.
Die Unterscheidung zwischen diesen beiden Arten von Anwendungsfällen ist wichtig, weil Akteure nur die konkreten
Anwendungsfälle "sehen" und im System einleiten.
Zur Kennzeichnung von abstrakten Anwendungsfällen wird der Name in Kursivschrift angegeben.
Beispiel:
Der Anwendungsfall "Aufgabe erstellen" ist im Anwendungsfall "Auftrag erfassen" enthalten. "Aufgabe erstellen" ist ein
abstrakter Anwendungsfall.
Im Lagerverwaltungssystem ist der abstrakte Anwendungsfall "Aufgabe erstellen" im Anwendungsfall "Auftrag erfassen"
enthalten. Wenn der Anwendungsfall "Auftrag erfassen" eingeleitet wird, wird eine Instanz von "Auftrag erfassen"
erstellt, die neben dem Ereignisablauf von "Auftrag erfassen" auch dem Ablauf der Ereignisse folgt, die im enthaltenen
Anwendungsfall "Aufgabe erstellen" beschrieben sind. "Aufgabe erstellen" wird nie eigenständig ausgeführt, sondern nur
im Rahmen von "Auftrag erfassen" (oder einem der anderen Anwendungsfälle, in denen er enthalten ist). Deshalb ist
"Aufgabe erstellen" ein abstrakter Anwendungsfall.
Es gibt drei wichtige Gründe für die Strukturierung des Anwendungsfallmodells:
-
Verständnis der Anwendungsfälle vereinfachen.
-
Allgemeines Verhalten absondern, das in vielen Anwendungsfällen beschrieben wird.
-
Verwaltung des Anwendungsfallmodells vereinfachen.
Die Strukturierung steht jedoch nicht an erster Stelle. Es gibt keinen Grund, die Anwendungsfälle zu strukturieren,
bevor Sie nicht ein bisschen mehr über ihr Verhalten wissen als das, was aus einer Kurzbeschreibung in einem Satz
hervorgeht. Sie müssen zumindest eine schrittweise Skizze des Ereignisablaufs im Anwendungsfall erstellt haben, um
sicher sein zu können, dass Ihre Entscheidungen auf einem genauen Verständnis des Verhaltens beruhen.
Für die Strukturierung der Anwendungsfälle stehen drei Arten von Beziehungen zur Verfügung. Sie verwenden diese
Beziehungen, um die Teile von Anwendungsfällen herauszufiltern, die in anderen Anwendungsfällen wiederverwendet werden
können oder die Spezialisierungen oder Optionen des Anwendungsfalls sind. Der Anwendungsfall, der die Änderung
darstellt, ist ein so genannter Additionsanwendungsfall. Der Anwendungsfall, der geändert wird, ist der
Basisanwendungsfall.
-
Wenn ein Teil eines Basisanwendungsfalls eine Funktion darstellt, deren Ergebnis allein für den Anwendungsfall von
Bedeutung ist und nicht die Methode für die Ergebnisherleitung, können Sie diesen Teil in einen
Additionsanwendungsfall extrahieren. Die Addition wird explizit über die Einschlussbeziehung in den
Basisanwendungsfall eingefügt. Weitere Informationen hierzu finden Sie auf der Seite Richtlinie: Einschlussbeziehung.
-
Wenn ein Teil eines Basisanwendungsfalls optional ist oder nicht erforderlich ist, um den primären Zweck des
Anwendungsfalls verstehen zu können, können Sie diesen Teil in einen Additionsanwendungsfall auslagern, um die
Struktur des Basisanwendungsfalls zu vereinfachen. Die Addition wird implizit über die Erweiterungsbeziehung in den
Basisanwendungsfall eingefügt. Weitere Informationen hierzu finden Sie auf der Seite Richtlinie: Erweiterungsbeziehung.
-
Wenn es Anwendungsfälle gibt, die Gemeinsamkeiten in Verhalten und Struktur sowie Ähnlichkeiten im Zweck aufweisen,
können diese gemeinsamen Teile in einen Basisanwendungsfall (übergeordnet) ausgelagert werden, der von
Additionsanwendungsfällen (untergeordnet) geerbt wird. Die untergeordneten Anwendungsfälle können in der Struktur,
die sie vom übergeordneten Anwendungsfall erben, neues Verhalten einfügen und vorhandenes Verhalten ändern. Weitere
Informationen hierzu finden Sie in Richtlinie für Arbeitsergebnis: Anwendungsfallgeneralisierung.
Mit Akteurgeneralisierung können Sie zeigen, dass Akteure spezialisierte Versionen eines anderen sein können. Weitere
Informationen hierzu finden Sie auf der Seite Richtlinie:
Akteurgeneralisierung.
Beispiel:
Schauen Sie sich diesen Teil des Anwendungsfallmodells für ein Auftragsverwaltungssystem an.
Es ist sinnvoll, den herkömmlichen Kunden vom Internetkunden zu trennen, da sie geringfügig andere Eigenschaften haben.
Da der Internetkunde jedoch alle Eigenschaften eines Kunden hat, können Sie sagen, dass der Internetkunde eine
spezialisierte Version des Kunden ist, die durch eine Akteurgeneralisierung angezeigt wird.
Die konkreten Anwendungsfälle in diesem Diagramm sind "Telefonische Bestellung" (eingeleitet vom Akteur Kunde) und
Internetbestellung (eingeleitet vom Internetkunden). Diese Anwendungsfälle sind Varianten des allgemeineren
Anwendungsfalls "Bestellung aufgeben", der in diesem Beispiel abstrakt ist. Der Anwendungsfall "Katalog anfordern" ist
ein optionales Segment des Verhaltens, das nicht zum primären Zweck des Anwendungsfalls "Bestellung aufgeben" gehört.
Er wurde in einen abstrakten Anwendungsfall abgesondert, um den Anwendungsfall "Bestellung aufgeben" zu vereinfachen.
Der Anwendungsfall "Kundendaten bereitstellen" stellt ein Segment des Verhaltens dar, das abgesondert wurde, weil es
eine separate Funktion ist, die sich nur in Bezug auf ihr Ergebnis auf den Anwendungsfall "Bestellung aufgeben"
auswirkt. Der Anwendungsfall "Kundendaten bereitstellen" kann in anderen Anwendungsfällen wiederverwendet werden.
"Katalog anfordern" und "Kundendaten bereitstellen" sind in diesem Beispiel abstrakt.
Dieses Anwendungsfalldiagramm zeigt einen Teil des Anwendungsfallmodells für ein Auftragsverwaltungssystem.
Die folgende Tabelle enthält einen detaillierten Vergleich zwischen den drei unterschiedlichen
Anwendungsfallbeziehungen:
Frage
|
Erweiterung
|
Einschluss
|
Generalisierung
|
Welche Richtung hat die Beziehung?
|
Der Additionsanwendungsfall referenziert den Basisanwendungsfall.
|
Der Basisanwendungsfall referenziert den Additionsanwendungsfall.
|
Der Additionsanwendungsfall (untergeordnet) referenziert den Basisanwendungsfall (übergeordnet).
|
Hat die Beziehung Multiplizität?
|
Ja, auf der Additionsseite.
|
Nein. Wenn Sie dasselbe Verhaltenssegment mehrfach einschließen möchten, muss dies im
Basisanwendungsfall beschrieben werden.
|
Nein.
|
Ist die Beziehung an eine Bedingung geknüpft?
|
Ja.
|
Nein. Wenn Sie eine Bedingung für den Einschluss ausdrücken möchten, müssen Sie dies explizit im
Basisanwendungsfall angeben.
|
Nein.
|
Ist der Additionsanwendungsfall abstrakt?
|
Häufig ja, aber nicht zwingenderweise.
|
Ja.
|
Häufig nein, ist aber möglich.
|
Wird der Basisanwendungsfall durch die Addition geändert?
|
Die Erweiterung ändert das Verhalten des Basisanwendungsfalls implizit.
|
Der Einschluss ändert das Verhalten des Basisanwendungsfalls explizit.
|
Wenn der Basisanwendungsfall (übergeordnet) instanziert wird, hat der untergeordnete Anwendungsfall
keine Auswirkung. Erst wenn der Additionsanwendungsfall (untergeordnet) instanziert wird, wirkt er sich
auf den Basisanwendungsfall aus.
|
Muss der Basisanwendungsfall vollständig und aussagekräftig sein?
|
Ja.
|
Zusammen mit den Additionen ja.
|
Wenn er abstrakt ist, nein.
|
Muss der Additionsanwendungsfall vollständig und aussagekräftig sein?
|
Nein.
|
Nein.
|
Zusammen mit dem Basisanwendungsfall (übergeordnet) ja.
|
Kann der Additionsanwendungsfall auf die Attribute des Basisanwendungsfalls zugreifen?
|
Ja.
|
Nein. Der Einschluss ist gekapselt und "sieht" nur sich selbst.
|
Ja, durch die normalen Vererbungsmechanismen.
|
Kann der Basisanwendungsfall auf die Attribute des Additionsanwendungsfalls zugreifen?
|
Nein. Der Basisanwendungsfall muss auch ohne die Addition korrekt formuliert sein.
|
Nein. Der Basisanwendungsfall kennt nur die Auswirkungen der Addition. Die Addition ist gekapselt.
|
Nein. Der Basisanwendungsfall (übergeordnet) muss in diesem Sinne auch ohne die Addition
(untergeordnet) korrekt formuliert sein.
|
Ein weiterer Aspekt bei der Organisation des Anwendungsfallmodells für bessere Verständlichkeit ist die Gruppierung der
Anwendungsfälle in Pakete. Das Anwendungsfallmodell kann als Hierarchie von Anwendungsfallpaketen aufgebaut werden, in
der Akteure und Anwendungsfälle "Blätter" darstellen. Weitere Informationen finden Sie in Richtlinie: Anwendungsfallpaket.
Diese Abbildung zeigt die Hierarchie des Anwendungsfallmodells. Die Pfeile weisen auf mögliche Eigentumsrechte hin.
Die Ausführung jedes Anwendungsfalls beinhalt Kommunikation mit einem oder mehreren Akteuren. Eine
Anwendungsfallinstanz wird immer von einem Akteur eingeleitet, der das System zu irgendeiner Aktion auffordert. Dies
impliziert, dass jeder Anwendungsfall gerichtete Kommunikationsbeziehungen mit Akteuren haben muss. Der Grund für diese
Regel ist der, das System dazu anzuhalten, nur die vom Benutzer geforderte Funktionalität zu erbringen und nichts
anderes. Anwendungsfälle ohne Anforderungen sind ein Hinweis darauf, dass ein Fehler im Anwendungsfallmodell oder in
den Anforderungen vorliegt.
Es gibt jedoch Ausnahmen von dieser Regel:
-
Wenn ein Anwendungsfall abstrakt (nicht eigenständig instanzierbar) ist, muss sein Verhalten keine Interaktion mit
einem Akteur beinhalten. In diesem Fall gibt es keine gerichtete Kommunikationsbeziehung zu Akteuren in diesem
abstrakten Anwendungsfall.
-
Ein untergeordneter Anwendungsfall ist eine Generalisierungsbeziehung, der nicht unbedingt ein Akteur zugeordnet
sein muss, wenn der übergeordnete Anwendungsfall die gesamte Kommunikation mit Akteuren beschreibt.
-
Einem Basisanwendungsfall in einer Einschlussbeziehung muss kein Akteur zugeordnet sein, wenn der
Einschlussanwendungsfall die gesamte Kommunikation mit den Akteuren beschreibt.
-
Ein Anwendungsfall kann nach einem Zeitplan (z. B. einmal pro Woche oder einmal pro Tag) eingeleitet werden, d. h.
die Systemuhr ist der Initiator. Die Systemuhr ist eine interne Komponente des Systems, und der Anwendungsfall wird
nicht von einem Akteur, sondern durch ein internes Systemereignis eingeleitet. Wenn keine anderen
Akteurinteraktionen im Anwendungsfall stattfinden, hat der Anwendungsfall keine Assoziationen zu Akteuren. Für die
Übersichtlichkeit können Sie jedoch einen fiktiven Akteur "Zeit" verwenden, um in Ihren Anwendungsfalldiagrammen zu
zeigen, wie der Anwendungsfall eingeleitet wird.
Die Übersichtsbeschreibung des Anwendungsfallmodell muss
-
die primären Anwendungsfälle des Systems beschreiben (der Grund für die Erstellung des Systems),
-
wichtige technische Fakten zum System zusammenfassen,
-
die Einschränkungen des Systems herausarbeiten, d. h. Dinge, die das System nicht erbringen muss,
-
die Systemumgebung, Zielplattformen und vorhandene Software zusammenfassen,
-
alle Sequenzen beschreiben, in denen Anwendungsfälle normalerweise im System ausgeführt werden,
-
Funktionalität beschreiben, die vom Anwendungsfallmodell nicht behandelt wird.
Beispiel:
Im Folgenden sehen Sie eine Beispielübersichtsbeschreibung für as Anwendungsfallmodell der
Recycling-Maschine:
Dieses Modell enthält drei Akteure und drei Anwendungsfälle. Der primäre Anwendungsfall ist "Artikel recyceln", der
auch den Hauptzweck der Recycling-Maschine zum Ausdruck bringt.
Die unterstützenden Anwendungsfälle sind:
-
"Tagesbericht drucken", der einem Operator ermöglicht, einen Bericht darüber zu generieren, wie viele Artikel
recycelt wurden.
-
"Pfandartikel verwalten", der einem Operator ermöglicht, den Pfandwert für einen bestimmten Typ von
Pfandartikel zu ändern oder neue Typen von Pfandartikeln hinzuzufügen.
|