Tutorial zur Anwendungsfallanalyse

Was ist ein Anwendungsfalldiagramm?

UML – Anwendungsfalldiagramme sind die primäre Form von System-/Softwareanforderungen für neue Softwareprogramme, die sich in der Entwicklung befinden. Der Zweck eines Anwendungsfalldiagramms besteht darin, zu visualisieren, was das System tun soll (was); In diesem Stadium wird nicht darüber nachgedacht, wie (wie) es zu tun ist.

Sobald ein Anwendungsfall spezifiziert ist, kann er in einer textuellen und visuellen Darstellung (dh einem Falldiagramm) dargestellt werden. Ein Schlüsselkonzept der Anwendungsfallmodellierung besteht darin, dass sie uns hilft, das System aus der Perspektive des Endbenutzers zu entwerfen. Es ist eine effektive Technik, um das Systemverhalten in Benutzerbegriffen zu kommunizieren, indem alle extern sichtbaren Systemverhalten angegeben werden.

Mit anderen Worten, die Nutzung des Systems muss von außen betrachtet werden, das heißt, das System sollte nicht von innen betrachtet werden, sondern von einer höheren Ebene, um die Funktionalität zu bestimmen, die das System den externen Akteuren bieten soll.

Zweck von Anwendungsfalldiagrammen

Anwendungsfalldiagramme werden normalerweise in den frühen Phasen der Entwicklung entwickelt, und Menschen verwenden die Anwendungsfallmodellierung häufig für die folgenden Zwecke.

• Geben Sie den Kontext eines Systems an
• Erfassen Sie die Anforderungen eines Systems
• Validierung der Architektur eines Systems
• Treiben Sie die Implementierung voran und generieren Sie Testfälle
• Entwickeln Sie gemeinsam mit Analysten, Domänenexperten und gezielten Endbenutzern

Eine Standardform von Anwendungsfalldiagrammen ist in der Unified Modeling Language definiert, wie im Beispiel eines Anwendungsfalldiagramms unten gezeigt.

BEARBEITEN SIE DIESES BEISPIEL FÜR EIN ANWENDUNGSFALLDIAGRAMM

Elemente des Anwendungsfalldiagramms

Schauspieler

Jeder Anwendungsfall wird mindestens einen Akteur haben, der als mindestens ein Teilnehmer (Rolle) verstanden werden kann, der nicht unbedingt eine Person sein muss, sondern ein anderes System oder Gerät sein kann. Ein Akteur kann mit mehr als einem Anwendungsfall interagieren, und ein Anwendungsfall kann mit mehr als einem Akteur interagieren.

Akteure sind nicht notwendigerweise Menschen, dh Benutzer, aber sie können tatsächlich Nicht-Personen, dh Systeme oder Zeit sein.

Meistens handelt es sich bei den Benutzern um Personen, die am Anwendungsfalldiagramm beteiligt sind, wie z. B. Kunden, Mitarbeiter, Vorgesetzte usw.

Menschliche vs. nichtmenschliche Akteure

Von Zeit zu Zeit wird das System von verschiedenen Ereignissen beeinflusst, um bestimmte Funktionen in einer gegebenen Situation auszuführen. Wenn zum Beispiel ein Audit bestanden wird, sendet das System proaktiv einen Brief, um die Leute zu benachrichtigen; Wird der Briefversand also automatisch vom System durchgeführt? Dieser Anwendungsfall wird tatsächlich durch die Zeit ausgelöst, dann ist der Akteur Timer; B. als „jeden Tag um 5:00 Uhr automatisch einen Brief versenden“ angesehen werden, dann ist der Akteur, der dieses Ereignis – das Versenden eines Briefes – auslöst, nicht das System, sondern tatsächlich der Timer-Akteur

Primäre vs. sekundäre Akteure

Ein primärer Akteur ist ein Akteur, der das System nutzt, um ein Ziel zu erreichen. Anwendungsfälle dokumentieren die Interaktionen zwischen dem System und den Akteuren, um die Ziele des primären Akteurs zu erreichen. Sekundäre Akteure sind die Akteure, die das System unterstützen muss, um die Ziele des primären Akteurs zu erreichen.

• Akteure können primär oder sekundär sein. Primärakteure initiieren Interaktionen mit dem System.
• Sekundäre Akteure werden typischerweise vom System um Hilfe gebeten, und ein sekundärer Akteur initiiert niemals den Anwendungsfall.

Beachten Sie Folgendes: Das Symbol für einen Akteur unterscheidet nicht zwischen einem primären Akteur und einem sekundären Akteur; der Unterschied muss den Anwendungsfallbeschreibungen (auch Anwendungsfallerzählungen genannt) entnommen werden.

Zum Beispiel:

Ein Kreditsachbearbeiter einer Bank möchte den Kreditantrag eines Kunden prüfen, und ein Teil des Prozesses umfasst eine Bonitätsprüfung in Echtzeit.

BEARBEITEN SIE DIESES BEISPIEL FÜR EIN ANWENDUNGSFALLDIAGRAMM

• Name des Anwendungsfalls. Überprüfen Sie einen Kreditantrag
• Hauptdarsteller. Kreditsachbearbeiter
• Nebendarsteller. Bonitätsbewertungssystem

Wie identifiziere ich Schauspieler?

Da ein Akteur nicht unbedingt eine Person sein kann, sondern ein externes System, eine Vorrichtung oder ein Timer sein kann, finden wir einen spezifischeren Akteur, indem wir die folgenden Fragen stellen

• Wer wird das System nach der Entwicklung nutzen?
• Von wem oder welchen anderen Systemen muss das System Daten erhalten?
• Für wen oder welche anderen Systeme soll das System Daten bereitstellen?
• Mit welchen anderen Systemen wird das System verbunden?
• Wer wird das System warten und verwalten?

Diese Fragen helfen uns, die Akteure des Systems zu abstrahieren. Am Beispiel von Geldautomaten erlaubt uns die Beantwortung dieser Fragen, mehr Akteure zu finden, d.h

• Der Betreiber ist für die Wartung und Verwaltung des ATM-Systems verantwortlich
• Geldautomaten müssen auch mit Back-End-Servern kommunizieren , um Informationen über Benutzerkonten zu erhalten.

Anwendungsfall

Ein Anwendungsfall stellt eine Funktionalität (normalerweise eine Anforderung) dar, die vom System implementiert werden soll. Die Details eines Anwendungsfalls, abgesehen von seinem eindeutigen Namen, werden im Diagramm nicht visuell dargestellt; diese Details werden in der Erzählung (textliche Beschreibung) des Anwendungsfalls angegeben.

Ein Anwendungsfall ist eine Liste von Aktionen oder Ereignisschritten, die typischerweise die Interaktionen zwischen den Rollen der Akteure und dem System definieren, um ein Ziel zu erreichen. Anwendungsfälle sind eine nützliche Technik zum Identifizieren, Klären und Organisieren von Systemanforderungen. Ein Anwendungsfall besteht aus einer Reihe von Sequenzen möglicher Interaktionen zwischen dem System und dem Benutzer, die die zu erreichende Funktionalität und die Lösungen für eventuell auftretende Fehler definieren.

Wie identifiziere ich Anwendungsfälle?

Sobald wir die Akteure gefunden haben, können wir die Anwendungsfälle des Systems basierend auf den Akteuren bestimmen, wobei wir uns hauptsächlich ansehen, welche Dienste jeder Akteur vom System benötigt oder wie die Akteure das System verwenden. Die Identifikation von Anwendungsfällen kann mit den folgenden Fragen beginnen (für jeden Teilnehmer).

• Warum nutzen die Akteure das System?
• Erstellt, ändert, löscht, greift der Teilnehmer zu und speichert er Daten im System? Wenn ja, wie führt der Akteur diese Operationen durch?
• Benachrichtigt der Akteur das System über bestimmte externe Ereignisse?
• Benachrichtigt das System den Akteur über bestimmte interne Ereignisse?

Zusammengenommen kann das Anwendungsfalldiagramm des ATM-Systems wie folgt dargestellt werden.

Use Case wird durch Ellipsen dargestellt, von etwas Statischem oder Dynamischem oder von einer Aufgabe oder einem System.

Systemgrenze

Systemgrenzen beschreiben das System, indem Anwendungsfälle in rechteckigen Grenzen gruppiert werden, und die Systemgrenzen in Visual Paradigm stellen das Anwendungsfalleingrenzungsverhalten bereit.

Akteure sind Rollen (menschliche oder nichtmenschliche Akteure), die mit dem zu entwickelnden System interagieren. Daher sollten Akteure außerhalb der Systemgrenzen platziert werden und mit Anwendungsfällen interagieren, die innerhalb der Systemgrenzen platziert sind.

Beachten Sie, dass: 

Ein Akteur wird durch die Grenzen des Systems definiert. Wenn die zu definierende Systemgrenze auf den Geldautomaten selbst beschränkt ist, dann ist der Backend-Server ein externes System und kann als Akteur abstrahiert werden.

Wenn sich die Systemgrenze, die wir definieren wollen, auf das gesamte Bankensystem erstreckt, wo sowohl Geldautomaten als auch Backend-Server Teil des gesamten Bankensystems sind, dann wird der Backend-Server nicht länger als Akteur abstrahiert.

Beziehung

Nachdem Sie diese drei Schlüsselsymbole kennengelernt haben, fahren Sie mit dem Wissen über Beziehungen und dem Zeichnen von Anwendungsfalldiagrammen fort. Eine direkte Beziehung zwischen einem Teilnehmer und einem Benutzerfall wird gezeichnet, und die Beziehung wird als Linie ohne Pfeile verwendet, die eine Zwei-Wege-Beziehung anzeigt, die als Verbindungslinie bezeichnet wird.

Ein Anwendungsfall kann in mehrere Anwendungsfälle unterteilt werden, die durch <<include>>-, <<extend>>- oder <<generalization>>-Beziehungen (weiter unten in diesem Beitrag beschrieben) verbunden sind.

Kommunikationsverbindungsbeziehung

Dies stellt eine bidirektionale Kommunikation zwischen einem Akteur und einem Anwendungsfall dar und ist daher eine binäre Beziehung.

BEARBEITEN SIE DIESES BEISPIEL FÜR EIN ANWENDUNGSFALLDIAGRAMM

<<Einschließen>> Beziehung

Eine Include- Beziehung bedeutet, dass der Anwendungsfall andere Anwendungsfälle einschließt. Der Zweck von „Beziehung einschließen“ besteht darin, „Beziehung einschließen“ zu verwenden, um die Wiederholung des erneuten Beschreibens desselben Anwendungsfalls zu reduzieren. Wenn viele Fälle dieselbe Portionsfunktion teilen, kann die Funktion herausgetrennt und andere Anwendungsfälle in den Fall aufgenommen werden.

Zum Beispiel muss der Bibliothekar den Code lesen, um das ausgeliehene Buch zu registrieren, wenn das Buch ausgeliehen wird, und muss auch den Code lesen, um das zurückgegebene Buch zu registrieren, wenn das Buch zurückgegeben wird, da das Lesen des Codes ein sich wiederholender Teil der Aktion ist , kann es zu einem separaten Anwendungsfall gemacht werden und das ausgeliehene Buch und das zurückgegebene Buch diesen Fall enthalten lassen.

BEARBEITEN SIE DIESES BEISPIEL FÜR EIN ANWENDUNGSFALLDIAGRAMM

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.

<<Erweitern>> Beziehung

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. Abhängig von den beschriebenen Bedingungen kann A jedoch B benötigen. In diesem Fall ist B von B abhängig. Abhängig von den beschriebenen Bedingungen kann A jedoch B benötigen In diesem Fall ist B von A abhängig und kann nicht alleine existieren. Aus diesem Grund kann B nicht auf mehr als einen Anwendungsfall erweitert werden. Die Anwendungsfallbeschreibung von A enthält die Ausführungsschritte, die von B verlangt werden; Dieser Punkt wird als Erweiterungspunkt bezeichnet.

BEARBEITEN SIE DIESES BEISPIEL FÜR EIN ANWENDUNGSFALLDIAGRAMM

Schauen wir uns ein weiteres Beispiel an, bei dem das System Waren automatisch bestellt, wenn kein Bestand vorhanden ist, sodass der Manager die Bestellung nicht direkt ausführen muss. Siehe das Anwendungsfalldiagramm unten:

BEARBEITEN SIE DIESES BEISPIEL FÜR EIN ANWENDUNGSFALLDIAGRAMM

Generalisierungsbeziehung

Die verallgemeinerte Beziehung ähnelt der verallgemeinerten Beziehung der objektorientierten Sprache in Klassendiagrammen und kann auf die Verallgemeinerung von Rollen (Akteuren) und Anwendungsfällen angewendet werden.

Im Buchungssystem gibt es beispielsweise zwei Arten von Buchungsmethoden: „Fahrkarte per Telefon buchen“ und „Fahrkarte online buchen“ und den Basisanwendungsfall „Buchticker“, sodass Sie die Verallgemeinerung verwenden können, um den Fall zu formen. und fügen Sie <<essential>> zum übergeordneten Anwendungsfall (Buchung) hinzu, um die generalisierte Beziehung anzugeben.

BEARBEITEN SIE DIESES BEISPIEL FÜR EIN ANWENDUNGSFALLDIAGRAMM

Diskutieren Sie die Zusammenhänge im Anwendungsfalldiagramm

• In einem allgemeinen Anwendungsfalldiagramm stellen wir nur die Beziehungen zwischen Akteuren und Anwendungsfällen dar, dh die Kommunikationszusammenhänge zwischen ihnen.
• Darüber hinaus können wir auch die Verallgemeinerung zwischen Teilnehmern und Akteuren sowie die Einbeziehungs-, Erweiterungs- und Verallgemeinerungsbeziehungen zwischen Anwendungsfällen beschreiben.
• Wir verwenden diese Beziehungen, um das vorhandene Anwendungsfallmodell anzupassen und einige gemeinsame Informationen zur Wiederverwendung zu extrahieren, wodurch das Anwendungsfallmodell einfacher zu pflegen ist.
• Allerdings müssen wir bei der Auswahl dieser Beziehungen in der Anwendung vorsichtig sein. Im Allgemeinen erhöhen diese Beziehungen die Anzahl der Anwendungsfälle und Beziehungen und erhöhen somit die Komplexität des Anwendungsfallmodells.
• Darüber hinaus wird das Use-Case-Modell in der Regel nach seiner Fertigstellung angepasst, so dass es nicht nötig ist, die Beziehungen zwischen Use-Cases in der frühen Phase der Use-Case-Modellierung zu abstrahieren.

Anwendungsfall – der Ablauf von Ereignissen

Das Anwendungsfalldiagramm gibt uns einen Gesamtüberblick über die Systemfunktionalität, wir können wissen, welche Teilnehmer mit dem System interagieren werden und welche Dienste jeder Akteur vom System erhalten muss.

Der Anwendungsfall beschreibt die Konversation zwischen den Akteuren und dem System, aber die Details dieser Konversation werden nicht im Anwendungsfalldiagramm dargestellt, sodass wir für jeden Anwendungsfall die Details dieser Konversation in Form eines Ereignisstroms beschreiben können.

Anwendungsszenarien und Ereignisablauf – ATM Geld abheben

Beispielsweise kann der Fall „Abheben“ in einem Geldautomatensystem durch einen Ereignisfluss wie folgt dargestellt werden:

Normales Szenario – Auszahlung von Geldern – grundlegender Ablauf der Ereignisse:

1. Benutzer führt Kreditkarte ein
2. Geben Sie die PIN ein
3. Auszahlungsbetrag eingeben
4. Bargeld abheben
5. Verlassen Sie das System und rufen Sie die Kreditkarte ab

Dies beschreibt jedoch nur das normale Szenario des Auszahlungsanwendungsfalls. Als echtes ATM-System müssen wir auch verschiedene andere Szenarien berücksichtigen, die auftreten können, wie zum Beispiel:

• ungültige Kreditkarten,
• falsche Passwörter,
• unzureichendes Guthaben auf dem Konto des Benutzers usw.

Alle diese möglichen Situationen (sowohl normale als auch anormale) werden Szenarien des Anwendungsfalls genannt, und Szenarien werden auch Instanzen des Anwendungsfalls genannt. Szenarien werden auch als Instanzen von Anwendungsfällen bezeichnet. Unter den verschiedenen Szenarien eines Anwendungsfalls wird das häufigste Szenario durch den Basisprozess beschrieben, während andere Szenarien durch alternative Prozesse beschrieben werden.

Alternative Szenarien

Für den Anwendungsfall „Auszahlung“ in einem Geldautomatensystem können wir einige alternative Prozesse wie folgt erhalten.

Rücktritt – alternative Ereignisabläufe.

1. Alternatives Szenario I: Der Benutzer kann sich in jedem Schritt des Basisverfahrens abmelden und zu Schritt 5 des Basisverfahrens gehen.
2. Alternatives Verfahren II: In Schritt 1 des Basisverfahrens führt der Benutzer eine ungültige Kreditkarte ein, das System zeigt einen Fehler an und verlässt die Kreditkarte, und der Anwendungsfall endet.
3. Alternatives Verfahren III: In Schritt 2 des Basisverfahrens gibt der Benutzer ein falsches Passwort ein, das System zeigt einen Fehler an und fordert den Benutzer auf, das Passwort erneut einzugeben und zu Schritt 2 des Basisverfahrens zurückzukehren; nach dreimaliger falscher Passworteingabe wird die Kreditkarte vom System eingezogen und der Use Case beendet.
4. …

Durch die Kombination des Basisszenarios und der Alternativszenarien lassen sich alle möglichen Situationen, die in einem Anwendungsfall auftreten können, anschaulich beschreiben. Bei der Beschreibung des Ablaufs eines Anwendungsfalls wollen wir möglichst alle möglichen Szenarien beschreiben, um die Vollständigkeit der Anforderungen zu gewährleisten.

Anwendungsfallmodell vs. Anwendungsfalldiagramme

Es ist wichtig, das Missverständnis zu vermeiden, dass ein Anwendungsfalldiagramm, das aus Akteuren und Anwendungsfällen besteht, ein Anwendungsfallmodell ist, da ein Anwendungsfalldiagramm nur eine visuelle Darstellung der Dienste ist, die das System bereitstellen kann, und uns eine allgemeine Vorstellung davon vermittelt Funktionalität des Systems.

Das Anwendungsfallmodell besteht aus einem Anwendungsfalldiagramm und einer detaillierten Beschreibung jedes Anwendungsfalls, der Anwendungsfallspezifikation, die als Vorlage im RUP bereitgestellt wird.

Kurzbeschreibung
Eine kurze Beschreibung der Rolle und des Zwecks des Anwendungsfalls.

Ereignisfluss 
Der Ereignisfluss sollte alle Szenarien darstellen, einschließlich grundlegender und alternativer Szenarien.

Anwendungsszenarien
umfassen Erfolgsszenarien und Fehlerszenarien, und Szenarien sind hauptsächlich eine Kombination aus grundlegenden und alternativen Abläufen.

Spezielle Anforderungen
Beschreiben Sie die nichtfunktionalen Anforderungen (einschließlich Leistung, Zuverlässigkeit, Verfügbarkeit, Skalierbarkeit usw.) und Designeinschränkungen (Betriebssystem, Entwicklungstools usw.), die mit dem Anwendungsfall verbunden sind.

Vorbedingung
Der Zustand, in dem sich das System befinden muss, bevor der Anwendungsfall ausgeführt werden kann.

Nachbedingungen
Der Satz von Zuständen, in denen sich das System befinden kann, nachdem der Anwendungsfall ausgeführt wurde.

Eine Anwendungsfallspezifikation ist im Wesentlichen eine Textdarstellung mit der Option, Zustandsdiagramme, Aktivitätsdiagramme oder Sequenzdiagramme zu verwenden, um den Ablauf von Ereignissen klarer zu beschreiben. Jede grafische Darstellung von Benutzerschnittstellen und Prozessen oder andere Grafiken, dh Wireframes, können an den Anwendungsfall angehängt werden, solange sie dazu beitragen, die Klarheit der Darstellung zu verbessern.

Zum Beispiel:

• Aktivitätsdiagramme sind nützlich, um komplexe Entscheidungsprozesse zu beschreiben,
• Zustandsübergangsdiagramme sind nützlich, um zustandsbezogenes Systemverhalten zu beschreiben, und
• Sequenzdiagramme eignen sich zur Beschreibung von zeitbasiertem Messaging.

Anwendungsfall-Tools

Online Version

Die kostenlose Version des kostenlosen Zeichentools Visual Paradigm Online (VP Online) unterstützt UML, ERD und Organigramme. Mit dem intuitiven UML-Zeichnungseditor können Sie schnell Anwendungsfalldiagramme zeichnen. Dieses kostenlose UML-Tool hat keine Werbung, keine begrenzte Zugriffszeit und keine Einschränkungen wie Anzahl der Diagramme, Anzahl der Formen usw. Zeichnen Sie UML frei. Zeichnen Sie UML frei. Sie besitzen die Diagramme, die Sie für persönliche und nicht kommerzielle Zwecke erstellen.

Desktop-Version

Die seit 2004 erhältliche Visual Paradigm Community Edition bietet eine kostenlose UML-Software nur für nicht-kommerzielle Zwecke und unterstützt Benutzer, die ihre ersten Schritte in der UML-Modellierung unternehmen, sowie diejenigen, die eine kostenlose, plattformübergreifende UML-Modellierungssoftware benötigen persönlichen Gebrauch, wie z. B. die Anwendung von UML in Studentenprojekten.

Verweise

• Was ist ein Anwendungsfalldiagramm?
• Akteurstypen im Anwendungsfallmodell
• Identifizieren Sie Benutzeranforderungen mit Anwendungsfalldiagrammen
• Was ist eine Anwendungsfallspezifikation?
• User Story vs. Use Case für agile Softwareentwicklung
• Anwendungsfallgesteuerter Ansatz für die agile Entwicklung

UML-Ressourcen

• Was ist UML?
• Warum UML-Modellierung?
• Überblick über die 14 UML-Diagrammtypen