Richtlinie: Anwendungsfallmodell
Ein Anwendungsfallmodell ist ein Modell der geplanten Funktionen des Systems und der Systemumgebung und dient als Vertrag zwischen dem Kunden und den Entwicklern. Diese Richtlinie ist eine Roadmap für die Entwicklung eines Anwendungsfallmodells.
Beziehungen
Hauptbeschreibung

Erläuterung

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.

In der Überschrift genannte Abbildung

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.

So entwickelt sich das Anwendungsfallmodell

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.

Funktionale Dekomposition vermeiden

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?

Nicht funktionale Anforderungen

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.

Das Dilemma zwischen Was und Wie

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:

In der Überschrift genannte Abbildung

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:

In der Überschrift genannte Abbildung

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.

Anwendungsfallmodell strukturieren

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.

In der Überschrift genannte Abbildung

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.

In der Überschrift genannte Abbildung

Diese Abbildung zeigt die Hierarchie des Anwendungsfallmodells. Die Pfeile weisen auf mögliche Eigentumsrechte hin.

Stehen Anwendungsfälle immer mit Akteuren in Beziehung?

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.

Übersichtsbeschreibung

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.