Anwendungsfallmodellierung

Ein  UML –  Anwendungsfalldiagramm  ist die primäre Form von System-/Softwareanforderungen für ein neues Softwareprogramm, das gerade entwickelt wird. Anwendungsfälle spezifizieren das erwartete Verhalten (was) eines Systems und nicht die genaue Methode, um es zu realisieren (wie). Ein vollständiger Satz von Anwendungsfällen spezifiziert alle unterschiedlichen Möglichkeiten zur Verwendung des Systems und definiert daher alle erforderlichen Verhaltensweisen des Systems, die den Umfang des Systems begrenzen.

Ein Schlüsselkonzept der Anwendungsfallmodellierung besteht darin, dass es uns hilft, ein System aus der Perspektive des Endbenutzers zu entwerfen. Es ist eine effektive Technik zum Kommunizieren des Systemverhaltens in den Begriffen des Benutzers, indem das gesamte extern sichtbare Systemverhalten angegeben wird.

Anwendungsfalldiagramm auf einen Blick

Eine Standardform von Anwendungsfalldiagrammen ist in der Unified Modeling Language definiert, wie im folgenden Anwendungsfalldiagramm-Beispiel gezeigt:

Was ist ein Anwendungsfall?

• Ein Anwendungsfall ist eine Sammlung möglicher Abfolgen von Interaktionen zwischen dem betrachteten System und seinen externen Akteuren, die sich auf ein bestimmtes Ziel beziehen.
• Jeder Anwendungsfall ist ein vollständiger Ablauf im System aus Benutzersicht.
• Einmal spezifizierte Anwendungsfälle können sowohl als textuelle als auch als visuelle Darstellung (dh Anwendungsfalldiagramm) bezeichnet werden.
• Anwendungsfälle sind die von der Komponenten- und Objekt-Community bevorzugte Methode, um Anforderungen zu spezifizieren und den gesamten Softwareentwicklungsprozess voranzutreiben.
• Anwendungsfälle beschränken sich normalerweise auf ziemlich große Aufgaben; Sie müssen nicht für jede Aktion geschrieben werden, die der Benutzer ausführen kann.

Vorteile des Use-Case-Ansatzes

Anwendungsfälle bieten viele Vorteile, die über die Definition von Benutzeranforderungen hinausgehen. Anwendungsfälle können verwendet werden, um:

• Anwendungsfallhilfe zur Erfassung der funktionalen Anforderungen eines Systems.
• Anwendungsfälle sind nachvollziehbar.
• Anwendungsfälle können als Grundlage für die Schätzung, Planung und Validierung des Aufwands dienen.
• Der Anwendungsfall kann sich bei jeder Iteration von einer Methode zur Erfassung von Anforderungen über Entwicklungsrichtlinien für Programmierer bis hin zu einem Testfall und schließlich zu einer Benutzerdokumentation entwickeln.
• Alternative Pfade für Anwendungsfälle erfassen zusätzliches Verhalten, das die Robustheit des Systems verbessern kann.
• Anwendungsfälle haben sich für Geschäftsanwender als leicht verständlich erwiesen und haben sich somit als hervorragende Brücke zwischen Softwareentwicklern und Endbenutzern erwiesen.
• Identifizieren Sie Geschäftsdomänenklassen und ihre Mitarbeiter

Schauspieler

• Jemand interagiert mit Anwendungsfall (Systemfunktion).
• Benannt nach Substantiv.
• Schauspieler spielt eine Rolle im Geschäft
• Ähnlich dem Konzept des Benutzers, aber ein Benutzer kann verschiedene Rollen einnehmen
• Zum Beispiel:
• Ein Prof. kann Dozent und auch Forscher sein
• spielt 2 Rollen mit zwei Systemen
• Akteur löst Anwendungsfall(e) aus.
• Der Akteur hat Verantwortung gegenüber dem System (Inputs) und der Akteur hat Erwartungen an das System (Outputs).

Anwendungsfall

• Systemfunktion (Prozess – automatisiert oder manuell)
• Benannt nach Verb + Substantiv (oder Nominalphrase).
• dh etwas tun
• Jeder Akteur muss mit einem Anwendungsfall verknüpft sein, während einige Anwendungsfälle möglicherweise nicht mit Akteuren verknüpft sind.

Kommunikationsverbindung

• Die Beteiligung eines Akteurs an einem Anwendungsfall wird durch die Verbindung eines Akteurs mit einem Anwendungsfall durch einen festen Link angezeigt.
• Akteure können durch Assoziationen mit Anwendungsfällen verbunden werden, was anzeigt, dass der Akteur und der Anwendungsfall unter Verwendung von Nachrichten miteinander kommunizieren.

Grenze des Systems

• Die Systemgrenze ist potenziell das gesamte System, wie es im Anforderungsdokument definiert ist.
• Bei großen und komplexen Systemen kann jedes Modul die Systemgrenze darstellen.
• Zum Beispiel für ein ERP-System für eine Organisation, jedes der Module wie Personal, Gehaltsabrechnung, Buchhaltung usw.
• kann eine Systemgrenze für Anwendungsfälle bilden, die für jede dieser Geschäftsfunktionen spezifisch sind.
• Das Gesamtsystem kann alle diese Module umfassen, die die Gesamtsystemgrenze darstellen

Anwendungsfallanalyse in 6 Schritten

Bei der Entwicklung von Anwendungsfällen sollten Sie mit einer Funktionsaufteilung beginnen – einer Auflistung der wichtigsten Funktionskategorien des Zielsystems. Dies hilft zu erkennen, auf welche Bereiche man sich konzentrieren muss.

Schritt 1 – Identifizieren Sie Akteure: Identifizieren Sie, wer das System direkt verwenden wird. Das sind die Schauspieler.

• Eine der Hauptkomponenten der Anwendungsfallentwicklung sind Akteure.
• Ein Akteur ist eine spezifische Rolle, die von einem Systembenutzer gespielt wird, und stellt eine Kategorie von Benutzern dar, die ähnliche Verhaltensweisen zeigen, wenn sie das System verwenden.
• Die Akteure können Menschen oder Computersysteme sein.
• Ein primärer Akteur ist einer, der ein Ziel hat, das die Unterstützung des Systems erfordert.
• Ein sekundärer Akteur ist einer, von dem das System Unterstützung benötigt, um sein Ziel zu erreichen.
• Einer der Akteure wird als das diskutierte System bezeichnet.
• Eine Person kann mehrere Rollen einnehmen und somit mehrere Akteure repräsentieren, wie zum Beispiel Computersystembetreiber oder Endbenutzer.

Schritt 2: Wählen Sie einen dieser Akteure aus.

• Um den Anwendungsfall eines Zielsystems zu identifizieren, identifizieren wir die Systemakteure.
• Ein guter Ausgangspunkt ist, das Systemdesign zu überprüfen und festzustellen, wem es helfen soll.

Schritt 3 – Anwendungsfälle identifizieren: Definieren Sie, was dieser Akteur mit dem System machen möchte. Jedes dieser Dinge, die der Akteur mit dem System machen möchte, wird zu einem Anwendungsfall.

• Die Dinge, die die Akteure mit dem System machen wollen, werden zu Zielen.
• Das Ziel ist das Endergebnis der Aktionen des Benutzers. Es gibt zwei Arten von Zielen. Der erste Typ ist ein starres Ziel.
• Dieses Ziel muss vollständig erfüllt werden und beschreibt die Mindestanforderung an ein Zielsystem.
• Um Anwendungsfälle zu identifizieren, können wir die Anforderungsspezifikation aus der Perspektive eines Akteurs lesen und mit denjenigen Benutzern diskutieren, die als Akteur fungieren werden.
• Indem alles definiert wird, was jeder Akteur im Zusammenspiel mit dem System tun kann, wird die vollständige Funktionalität des Systems definiert.

Schritt 4 – Identifizieren Sie das normale Anwendungsfall-Szenario: Entscheiden Sie sich für jeden dieser Anwendungsfälle für die üblichste Vorgehensweise, wenn dieser Akteur das System verwendet. Was normalerweise passiert.

• Ein Anwendungsfall hat einen Grundkurs und mehrere Alternativkurse.
• Der Grundkurs ist der einfachste Kurs, bei dem eine Anfrage problemlos geliefert wird.
• Eventuell gibt es Alternativkurse, die Varianten des Grundkurses und die dabei auftretenden Fehler beschreiben.
• Diese werden als Erweiterungen des Anwendungsfalls dokumentiert.

Schritt 5 – Anwendungsfallbeschreibung entwickeln: Beschreiben Sie diesen grundlegenden Kurs in der Beschreibung für den Anwendungsfall.

• Das Anwendungsszenario ist aus Sicht des Benutzers in leicht verständlicher Sprache geschrieben.
• Die Schritte, die notwendig sind, um das identifizierte Ziel zu erreichen, werden aufgeschrieben, bekannt als Ereignisfluss.

Schritt 6 – Entwickeln Sie alternative Pfade für Anwendungsfälle: Wenn Sie mit dem Grundkurs zufrieden sind, betrachten Sie nun die Alternativen und fügen Sie diese als erweiterte Anwendungsfälle hinzu.

Alternative Szenarien eines Anwendungsfalls

Ein Anwendungsfall beschreibt auch, wie das System reagieren soll, wenn die Dinge entweder  nicht  richtig laufen oder  richtig  laufen, aber  nicht  so, wie wir es im Haupterfolgsszenario beschrieben haben. Wir nennen diese Situationen  Erweiterungen .

• Es gibt zwei Varianten:  Exceptions  und  Alternates .
• Ausnahmen sind Fehlerbedingungen (etwas ist schief gelaufen).
• Alternativen sind einfach ein anderer Weg, damit die Dinge richtig laufen.

Anwendungsfall-Detailebenen

Die Granularität von Anwendungsfällen bezieht sich auf die Art und Weise, wie Informationen innerhalb von Anwendungsfallspezifikationen organisiert sind, und bis zu einem gewissen Grad auf die Detailebene, auf der sie geschrieben werden. Das Erreichen der richtigen Granularität der Anwendungsfälle erleichtert die Kommunikation zwischen Stakeholdern und Entwicklern und verbessert die Projektplanung.

Alastair Cockburn in  Writing Effective Use Cases  gibt uns eine einfache Möglichkeit, verschiedene Ebenen der Zielebene zu visualisieren, indem wir in Bezug auf das Meer denken:

Beachten Sie, dass:

• Während ein Anwendungsfall selbst viele Details zu jeder Möglichkeit aufzeigen kann, wird ein Anwendungsfalldiagramm oft für eine übergeordnete Ansicht des Systems als Blaupause verwendet.
• Es ist vorteilhaft, Anwendungsfälle auf einer gröberen Granularitätsebene mit weniger Details zu schreiben, wenn dies nicht erforderlich ist.

Ich hoffe, Sie können jetzt beantworten, was ein Anwendungsfalldiagramm ist, und Anwendungsfälle in Ihrem Projekt anwenden. Wenn Sie mehr über andere UML-Diagrammtypen erfahren möchten, lesen Sie bitte den UML-Leitfaden:  Übersicht über die 14 UML-Diagrammtypen .

Verweise

• So zeichnen Sie ein Anwendungsfalldiagramm
• Anwendungsfalldiagramm-Tutorial
• Beschreibung des Anwendungsfalls