Eine Kurzanleitung zur Modellierung von Anwendungsfällen

Mit der Veröffentlichung von Ivar Jacobsons (1991) Buch Object-Oriented Software Engineering, A Use-Case-Driven Approach wurde die Use-Case-Modellierung effektiv zu einer praktischen Analysetechnik.“ Heute fördert Jacobson diesen Ansatz der Systemanalyse weiter und hat ihn zum Anwendungsfall 2.0 ausgebaut, der offiziell einer der 14 Typen von UML-Diagrammen ist .

Da das Anwendungsfallmodell in Konzept und Erscheinungsbild einfach ist, ist es relativ einfach, seine Korrektheit mit nicht-technischem Personal (z. B. Kunden) zu diskutieren.

Ein Anwendungsfall ist keine Prozedur, kein Prozess oder keine Funktion.

Die Elemente des Anwendungsfalldiagramms

Die Elemente eines Anwendungsfalldiagramms sind die Akteure (externe Entitäten) und der Anwendungsfall selbst. Grob gesagt ist ein Anwendungsfall eine funktionale Einheit (Anforderung) oder ein Dienst in einem System.

Schauspieler

Ein Akteur ist jede Entität außerhalb des Designsystems, unabhängig davon, ob es sich um eine Person oder eine andere nichtmenschliche Entität handelt. Ein Benutzer eines Systems ist ein typisches Beispiel für einen Akteur. Andere Arten von Akteuren umfassen Softwaresysteme, die in das aktuelle System integriert werden (z. B. ein Datenbanksystem), externe Hardware wie etwa ein Sensor und so weiter.

In der UML-Spezifikation gibt es zwei Notationen :

Die Verwendung von Stickman für Schauspieler ist ausdrucksstärker, kann jedoch zu Verwirrung führen, wenn der Schauspieler nicht wirklich eine Person, sondern eine Maschine oder ein externes Gerät ist. Das Rechtecksymbol ist die UML -Standardnotation für eine Klasse .

Ein Schauspieler ist eher eine Rolle als eine reale Person 

Ein Akteur repräsentiert die Rolle der Entität, die mit dem aktuellen System interagiert, nicht eine Instanz. Die Akteursnotation zeigt an, dass die Entität eine Klasse und keine Leseinstanz ist (dh ein echter Benutzer John oder Mary). Der Grund, warum ein Schauspieler eine Art Klasse ist, liegt darin, dass es nicht der Schauspieler selbst ist, sondern die Rolle, die er spielt.

Beispielsweise kann ein Akteur die Kunden einer Bank repräsentieren, anstatt für jeden Kunden einen separaten Akteur anzugeben. Ebenso kann es einen anderen Akteur geben, der den Bankmanager vertritt. Interessanterweise kann der Manager einer Bank in der realen Welt auch Kunde derselben Bank sein. Mit anderen Worten, dieselbe Person spielt sowohl die Rolle des Kunden als auch die des Managers.

Primäre vs. sekundäre Akteure

Primärer Akteur eines Anwendungsfalls ist der Stakeholder, der das System benötigt, um seine Dienste bereitzustellen. Es hat ein mit dem System verbundenes Ziel – ein Ziel, das durch den Betrieb des Systems erfüllt werden kann. Der primäre Akteur ist normalerweise, aber nicht immer, der Akteur, der den Anwendungsfall auslöst.

Sekundärakteure werden vom System verwendet, interagieren jedoch nicht selbst mit dem System. Mit anderen Worten, sekundäre Akteure initiieren keine Anwendungsfälle.

Use Cases werden in der Regel von den primären Akteuren initiiert. Das System verwendet einen sekundären Akteur wie eine Datenbank durch eine Reihe von Anwendungsfällen. Die Assoziation zwischen Anwendungsfällen und Teilnehmern stellt eine wechselseitige Kommunikation dar.

Somit muss für jeden Anwendungsfall, der von einem primären Akteur initiiert wird, auf den verbundenen Anwendungsfall reagiert werden. In ähnlicher Weise beginnt die Kommunikation für jede Assoziation zwischen einem sekundären Akteur und einem Anwendungsfall mit dem Anwendungsfall, und der sekundäre Akteur sollte auf die Initiierung reagieren.

Anwendungsfall

Anwendungsfälle stellen die Funktionen (normalerweise Anforderungen) dar, die vom System implementiert werden sollen. Die Details des Anwendungsfalls, mit Ausnahme seines eindeutigen Namens, werden im Diagramm nicht intuitiv ausgedrückt; Diese Details sind in der Anwendungsfallbeschreibung angegeben.

Use Cases werden in der Regel von Schlüsselakteuren initiiert. Das System verwendet Datenbanken und andere Hilfsteilnehmer durch eine Reihe von Anwendungsfällen.

Die Assoziation zwischen Anwendungsfällen und Akteuren stellt eine wechselseitige Kommunikation dar. Daher muss für jeden vom Hauptakteur initiierten Anwendungsfall auf diesen reagiert werden. In ähnlicher Weise beginnt die Kommunikation für jede Assoziation zwischen dem sekundären Akteur und dem Anwendungsfall mit dem Anwendungsfall, und der sekundäre Akteur sollte auf die Initiierung reagieren.

Systemgrenze

Die Systemgrenze definiert das interessierende System in Bezug auf die Welt um es herum.

Beispiel eines Anwendungsfalldiagramms: Flugbuchungssystem

Anwendungsfälle definieren Interaktionen zwischen externen Akteuren und dem System, um bestimmte Ziele zu erreichen. Ein Anwendungsfalldiagramm enthält vier Hauptkomponenten

Im Anwendungsfalldiagramm eines Ticketbuchungssystems wird das System durch Kästen dargestellt, die viele verschiedene Anwendungsfälle enthalten. Der primäre Akteur ist der Kunde und der sekundäre Akteur der Administrator. Der Kunde initiiert die Anwendungsfälle wie das Buchen, Durchsuchen und Stornieren von Flügen, während der Administrator die Anwendungsfälle wie das Aktualisieren von Flugaufzeichnungen initiiert, aber im Anwendungsfall „Flug stornieren“ als sekundärer Akteur betrachtet wird, da er nur beim Abschließen hilft die vom Kunden initiierten Anwendungsfälle.

BEARBEITEN SIE DIESES BEISPIEL FÜR EIN UML-ANWENDUNGSFALLDIAGRAMM

Anwendungsfälle strukturieren

Je nach Anwendungsbereich und Wahl des Designers kann ein Use Case in mehrere Use Cases zerlegt werden, die durch Beziehungen < < include > > oder < < extend > > verbunden sind.

Association Link stellt eine bidirektionale Kommunikation zwischen einem Akteur und einem Anwendungsfall dar und ist daher eine binäre Beziehung. Da es sich um eine bidirektionale Kommunikation handelt, muss dieser Akteur für jeden von einem primären Akteur initiierten Anwendungsfall eine Antwort von dem Anwendungsfall erhalten.

In ähnlicher Weise muss der sekundäre Akteur für jede Kommunikation zwischen einem Anwendungsfall und einem sekundären Akteur (initiiert durch den Anwendungsfall) eine Antwort an den Anwendungsfall zurücksenden.

Verallgemeinerung

Die Verallgemeinerung stellt die Beziehung zwischen dar

• Rollen bzw
• Anwendungsfälle.

BEARBEITEN SIE DIESE UML-ANWENDUNGSFALLDIAGRAMMVORLAGE

Wenn zwei Akteure durch diese Beziehung verbunden sind, dann ist der Akteur (oder Anwendungsfall) am Ende des Pfeils (verbunden mit dem unteren Ende des Dreiecks) eine spezialisierte Version des Akteurs (oder Anwendungsfalls) am anderen Ende.

Typischerweise wird der Akteur (oder Anwendungsfall) am unteren Ende (verbunden mit der Unterseite des Dreiecks) als spezialisierte Version des Akteurs (oder Anwendungsfalls) am anderen Ende bezeichnet.

Die Verallgemeinerung bedeutet, dass die spezialisierte Version alle Funktionen der allgemeinen Version und möglicherweise mehr aufweist.

Include   ist eine spezielle Art von Beziehung zwischen zwei Anwendungsfällen. Wenn ein Anwendungsfall A einen anderen Anwendungsfall B enthält, dann erfordert die Implementierung von A die Implementierung von B, um seine Aufgabe zu erfüllen. B ist jedoch von sich selbst unabhängig. Das heißt, B muss nichts über A wissen. B kann auch in jeden anderen Anwendungsfall einbezogen werden.

BEARBEITEN SIE DIESES BEISPIEL FÜR EIN ANWENDUNGSFALLDIAGRAMM

Extend ist eine weitere spezielle Art von Beziehung zwischen zwei Anwendungsfällen. Wenn ein Anwendungsfall B einen anderen Anwendungsfall A erweitert, kann die Implementierung von A die Implementierung von B bedingt beinhalten, um seine Aufgabe zu erfüllen. Das heißt, in einigen Fällen kann A seine Aufgabe ohne B erledigen. Allerdings abhängig von den beschriebenen Bedingungen.

BEARBEITEN SIE DIESES BEISPIEL FÜR EIN ANWENDUNGSFALLDIAGRAMM

Notationen von Anwendungsfalldiagrammen

BEARBEITEN SIE DIESES ANWENDUNGSFALLDIAGRAMM-BEISPIEL ONLINE

9 einfache Schritte zur Durchführung einer Anwendungsfallanalyse

1. Legen Sie fest, wer das System direkt nutzen wird. Diese Leute sind die Schauspieler.
2. Wählen Sie einen dieser Schauspieler aus.
3. Definieren Sie, was dieser Akteur mit dem System machen möchte. Jede Sache, die der Akteur mit dem System machen möchte, wird zu einem Anwendungsfall.
4. Wiederholen Sie die Schritte 2–3 für alle anderen Anwendungsfälle.
   Identifizieren Sie die sekundären Rollen und die Unterstützung nichtmenschlicher Rollen für die von Ihnen identifizierten Anwendungsfälle.
5. Zeichnen Sie die erste Version des Anwendungsfalls, verkomplizieren Sie die Anwendungsfallbeziehungen an dieser Stelle nicht
6. Diskutieren und überprüfen Sie mit den Benutzern, um die Ziele der einzelnen Anwendungsfälle zu validieren (Vorteile der vorgeschlagenen Funktionalität).
7. Entscheiden Sie für jeden Anwendungsfall den häufigsten Prozess, dem der Akteur folgen wird, wenn er das System verwendet. Was normalerweise passieren würde.
8. Beschreiben Sie diesen grundlegenden Prozess in der Beschreibung des Anwendungsfalls.
9. Wenn Sie mit dem grundlegenden Prozess zufrieden sind, überlegen Sie sich nun alternative Szenarien und fügen Sie diese als erweiterte Anwendungsfälle hinzu.

Anwendungsfallmodell und Spezifikation

Es reicht nicht aus, nur das Anwendungsfalldiagramm in UML-Notation darzustellen. Jeder Anwendungsfall wird von einem Text begleitet, der den Zweck des Anwendungsfalls und die Funktionalität erklärt, die erreicht wird, wenn der Anwendungsfall ausgeführt wird.

Ein Anwendungsfall beschreibt eine Aufgabe, die von einem Akteur ausgeführt wird und einen Geschäftswert für das Unternehmen erzeugt. Ein Anwendungsfall kann als Anwendungsfalldiagramm und/oder in einem strukturierten Textspezifikationsformat visualisiert werden.

Anwendungsszenarien

Ein Anwendungsfall besteht aus einer Reihe von Szenarien, die jeweils eine bestimmte Instanz des Anwendungsfalls darstellen, die bestimmten Eingaben des Akteurs oder bestimmten Bedingungen in der Umgebung entsprechen. Jedes Szenario beschreibt eine alternative Verhaltensweise des Systems oder kann Fehler oder Ausnahmen beschreiben.

Ein Anwendungsfall hat:

• Nur ein Ziel
• Ein einziger Ausgangspunkt
• Ein einziger Endpunkt
• Mehrere Wege, um vom Anfang bis zum Ende zu gelangen
  • dh Verhalten für eine Vielzahl möglicher Bedingungen festlegen
  • Jede Bedingung kann bestimmte Maßnahmen erfordern

Zum Beispiel – Kunde zahlt Rechnung:

Es gibt mehrere Wege zum  Ziel :

• Telefonische Zahlung
• Per Mail
• Persönlich
• per Scheck
• per Bargeld usw.

Ein Weg,  der nicht zum Ziel führt:

• Kreditkarte wird abgelehnt

Anwendungsfälle mit Paketen gruppieren

Sie können auch: Pakete für die logische Kategorisierung von Anwendungsfällen in verwandte Subsysteme zeichnen.

BEARBEITEN SIE DIESES BEISPIEL FÜR EIN ANWENDUNGSFALLDIAGRAMM

Detaillierte Anwendungsfallspezifikation

Ein detaillierter Anwendungsfall ist eine Textdarstellung, die einen Ablauf von Ereignissen und andere zugehörige Anwendungsfallinformationen in einem bestimmten Format beschreibt. Eine Standardanwendungsfallvorlage wird häufig verwendet, um die Details eines Anwendungsfalls zu dokumentieren

Was ist eine Anwendungsfallbeschreibung

Eine Anwendungsfallbeschreibung ist eine schriftliche Beschreibung der Abfolge von Schritten, die ein Analyst ausführt, um eine vollständige Systemtransaktion abzuschließen. Es wird von einem Akteur initiiert, bietet diesem Akteur einen Mehrwert und ist das Ziel der im System arbeitenden Akteure.

Akteur – Jede Person oder jedes System außerhalb des Systems, das das System verwendet oder mit ihm interagiert, um ein Ziel zu erreichen. Jedem Akteur wird eine Rolle zugewiesen, um seine Interaktion mit der Lösung darzustellen. Personenakteure sollten in Form von Rollen benannt und nicht mit echten Namen versehen werden. Akteure werden im Allgemeinen als primäre, sekundäre oder Stakeholder kategorisiert

Primärer Akteur – Der Akteur, der den Anwendungsfall initiiert.
Sekundärer Akteur – Der Akteur, der auf die vom primären Akteur ausgeführten Aktionen reagiert oder reagiert.
Stakeholder – Akteure außerhalb der Bühne, die nicht direkt mit dem Anwendungsfall interagieren, aber ein Interesse am Ergebnis des Anwendungsfalls haben.

Ereignisfluss (Pfad) – die Abfolge von Schritten, die Akteure und Lösungen ausführen müssen, um einen Anwendungsfall auszuführen. Im Allgemeinen besteht ein Anwendungsfall aus einem primären Erfolgspfad (auch Basis oder primär genannt), einem alternativen Pfad und einem Ausnahmepfad.

Der normale Pfad – die Eingabe des Akteurs und die Antwort des Systems – stellt den häufigsten Erfolgspfad dar, um die Ziele des Akteurs zu erreichen.

Alternative Pfade – Eingaben des Akteurs und Systemantworten, die die anderen, weniger verbreiteten Pfade darstellen, um das Ziel des Akteurs zu erreichen

Außergewöhnliche Pfade – Eingaben des Akteurs und Systemreaktionen, die erfolglose Pfade darstellen, wenn das Ziel des Akteurs nicht erreicht werden kann.

verwandte Links

1. Was ist Unified Modeling Language?
2. Use Case Slide / Vorlesungsnotizen
3. Die Rolle von Anwendungsfällen in der Anforderungs- und Analysemodellierung
4. Eine Liste von UML-Tools
5. Probieren Sie Visual Paradigm KOSTENLOS aus
6. Anwendungsfall – Hinweise für den Schulungskurs
7. Wie schreibe ich effektive Use Cases?
8. Buchkapitel – PDF – Anwendungsfallmodell: Schreibanforderungen im Kontext