Ein Anwendungsfalldiagramm ist eine Ansicht, die zur Beschreibung von Systemfunktionen verwendet wird, die aus Akteuren, Anwendungsfällen und der Beziehung zwischen ihnen bestehen. Es ist für externe Benutzer sichtbar und wird als Modelldiagramm der Systemfunktionalität bezeichnet. Anwendungsfalldiagramme werden häufig während der Anforderungsanalysephase verwendet.
Vor der Entwicklung eines Systems besteht die wichtigste Aufgabe darin, die Benutzeranforderungen zu ermitteln. Die wichtigsten Benutzeranforderungen sind die von den Benutzern vorgeschlagenen funktionalen Anforderungen des Systems. Wir können Anwendungsfalldiagramme verwenden, um Benutzeranforderungen visuell auszudrücken.
Visuelles Anwendungsfalldiagramm
Zu den Hauptelementen in einem Anwendungsfalldiagramm gehören Akteure, Anwendungsfälle und die Beziehungen zwischen Elementen. Darüber hinaus können Anwendungsfalldiagramme auch Anmerkungen und Einschränkungen enthalten.
1. Teilnehmerkonzept
Akteure sind externe Einheiten, die mit dem Hauptsystem interagieren. Teilnehmer können Personen, Subsysteme, andere Systeme usw. außerhalb des Systems sein.
Jeder Schauspieler ist eigentlich ein Rollensatz. In UML wird ein Akteur grafisch durch eine menschliche Gestalt dargestellt und mit einem Namen versehen. Wie im Bild unten dargestellt, ist der „Leser“ Teilnehmer am Bibliotheksausleihsystem.
Anwendungsfalldiagramm-Akteure
Akteure sollten sich außerhalb der Systemgrenzen befinden und nicht Teil des Systems sein.
2. So identifizieren Sie Teilnehmer
Bei der Modellierung von Anwendungsfällen ist die Identifizierung der Akteure der erste Schritt bei der Modellierung von Anwendungsfalldiagrammen. Wie kann man also die Teilnehmer des Systems bestimmen ? Wir können aus folgenden Ideen darüber nachdenken:
(1) Die Serviceobjekte des Systems – wie z. B. Leser im Bibliotheksleihsystem;
(2) Personen, die bei der Fertigstellung der Arbeit Unterstützung leisten – etwa Bibliotheksmitarbeiter im Bibliotheksausleihsystem, die das System nutzen müssen, um den Lesern bei der Ausleihe, der Rückgabe von Büchern und bei Erinnerungen zu helfen;
(3) Systembetreuer: die Person, die für die Installation, Wartung und Verwaltung des Systems verantwortlich ist. In diesem Fall muss das System relevante Funktionen bereitstellen, um dieses Personal bei der Durchführung der Installations-, Wartungs- und Verwaltungsarbeiten zu unterstützen.
(4) Externe Geräte: müssen Informationen an externe Geräte übertragen oder von diesen lesen, z. B. Kartenleser;
(5) Andere Systeme oder Subsysteme: wie das Finanzsystem im Kreditsystem. Das Finanzsystem ist keine Funktion des Kreditsystems, aber das Kreditsystem muss ihm Informationen übermitteln, um die überfällige Feinarbeit abzuschließen.
(6) Zeit: Zu einem geplanten Zeitpunkt tritt automatisch ein bestimmtes Ereignis ein, z. B. eine automatische Sicherung, eine regelmäßige Erinnerung usw.;
(7) Spezifische Ereignisse: Beispielsweise wird der automatische Bestelleingang im Takeout-System durch Ereignisse zur Auftragsgenerierung gesteuert.
Beachten Sie bei der Identifizierung der Teilnehmer Folgendes:
(1) Die Teilnehmer befinden sich außerhalb des Systems und sind nicht Teil des Systems.
(2) Teilnehmer interagieren mit dem System über Systemgrenzen hinweg;
(3) Obwohl die Symbole der Teilnehmer durch menschlich geformte Symbole dargestellt werden, handelt es sich bei den Teilnehmern nicht unbedingt um Menschen, sondern es können sich auch um andere Subsysteme, andere Systeme, Zeit, Temperatur und andere Faktoren handeln.
3. Beziehungen zwischen den Teilnehmern
Die Hauptbeziehung zwischen den Teilnehmern ist die Verallgemeinerung. Die Generalisierung wird durch einen durchgezogenen, offenen dreieckigen Pfeil dargestellt, der auf allgemeinere Teilnehmer zeigt und am „spezifischen“ Teilnehmerende endet. Eine Generalisierungsbeziehung ist eine Beziehung zwischen dem Allgemeinen und dem Besonderen (Konkreten). In einer Generalisierungsbeziehung kann eine abstrakte Beschreibung eines Teilnehmers von einem oder mehreren konkreten Teilnehmern geteilt werden. Die folgende Abbildung zeigt die allgemeinen Beziehungen zwischen Teilnehmern eines Bibliotheksleihsystems:
Generalisierungsbeziehung zwischen Teilnehmern am Bibliotheksleihsystem
pensionierte Fakultät usw. unter dem Leser sind „spezifische“ Teilnehmer. Die Verallgemeinerung von Teilnehmern kann wie folgt verstanden werden: Ein „spezifischer“ Teilnehmer ist ein „allgemeiner“ Teilnehmer, beispielsweise ein Fakultätsmitglied, das eine Art Leser ist. Bei der Akteurgeneralisierung werden Anwendungsfälle, die von einem „allgemeinen“ Akteur ausführbar sind, als von einem „konkreten“ („speziellen“) Akteur ausführbar dargestellt.
1. Das Konzept der Anwendungsfälle
Ein Anwendungsfall ist ein Systemdienst oder eine Funktionseinheit, die für Teilnehmer erlebbar ist. Es definiert ein Ziel, das das System erreichen soll. Ein Anwendungsfall definiert lediglich ein Verhalten des Systems, offenbart jedoch nicht die interne Struktur des Systems.
Der größte Vorteil von Use Cases besteht darin, dass sie Systemfunktionen aus der Sicht des Benutzers beschreiben. Grafisch wird ein Anwendungsfall durch eine durchgezogene Ellipse dargestellt, wobei der Name des Anwendungsfalls innerhalb oder unterhalb der Ellipse liegt:
Anwendungsfall zum Ausleihen von Büchern
2. Identifizieren Sie Anwendungsfälle
Anwendungsfälle können anhand der folgenden Punkte identifiziert werden:
(1) Welche Funktionen benötigt der Teilnehmer vom System zur Unterstützung seiner Arbeit?
(2) Müssen die Teilnehmer einige Informationen im System abfragen?
(3) Müssen Teilnehmer einige Informationen im System ändern, z. B. Erstellungs-, Änderungs- und Löschvorgänge?
(4) Müssen die Teilnehmer über bestimmte Ereignisse oder Statusänderungen des Systems informiert werden?
(5) Welche externen Ereignisse im System veranlassen das System, als Reaktion darauf relevante Funktionen auszuführen?
(6) Bietet das System relevante Funktionen, um das Wartungspersonal bei der Wartung des Systems zu unterstützen?
3. Kernpunkte der Anwendungsfallidentifizierung
(1) Die identifizierten Anwendungsfälle sollten die Ziele des Systems widerspiegeln, d. h. „was zu tun ist“ und nicht „wie es zu tun ist“, was bedeutet, dass Anwendungsfälle keine Details der Systemimplementierung sind;
(2) Definieren Sie Anwendungsfälle aus der Perspektive der Teilnehmer (Benutzer) und nicht aus der Perspektive des Systems;
(3) Anwendungsfälle sollten den Teilnehmern wertvolle Ergebnisse liefern und nicht eine Sammlung von Aktionen;
(4) Vermeiden Sie es, in die funktionale Zersetzung und die Stufenzerlegung zu verfallen.
(5) Jeder Teilnehmer sollte über einen ausführbaren Anwendungsfall verfügen und jeder Anwendungsfall sollte mindestens einem Teilnehmer zugeordnet sein.
4. Anwendungsfälle benennen
Nachdem Sie die Anwendungsfälle des Systems ermittelt haben, müssen Sie jeden Anwendungsfall benennen. Die Benennung von Anwendungsfällen muss die von den Teilnehmern erreichten Ziele aus Benutzersicht beschreiben. Folgende Benennungsmethoden können verwendet werden:
Verb + Objekt
Das heißt, der Name des Anwendungsfalls sollte in Form einer Verb-Objekt-Phrase vorliegen. Zum Beispiel Kurse auswählen, Bücher ausleihen, Waren bestellen und mit Kreditkarten bezahlen.
5. Granularität des Anwendungsfalls
Die Granularität eines Anwendungsfalls bezieht sich auf den Grad, in dem ein Anwendungsfall Systemfunktionen verfeinert oder integriert. Man kann auch sagen, dass es sich um die Anzahl der in einem Anwendungsfall enthaltenen Systemdienste oder Funktionseinheiten handelt. Wenn die Granularität des Anwendungsfalls zu grob oder zu groß ist, enthält der Anwendungsfall mehr Systemfunktionen und umgekehrt. Wenn die Granularität der Anwendungsfälle zu grob ist, wird es schwierig, das System zu verstehen. Wenn die Granularität zu fein ist, wird das Anwendungsfallmodell zu groß, was zu Schwierigkeiten beim Entwurf führt. Wenn der Anwendungsfall zu feinkörnig ist, kann es zu einer funktionalen Zerlegung kommen, wie zum Beispiel:
Anfängliche Granularität des Anwendungsfalls
Tatsächlich umfassen viele Unternehmen im System solche Vorgänge zum Hinzufügen, Löschen, Ändern und Überprüfen. Dies kann den Benutzern keine sinnvollen Ziele bieten, sondern ignoriert den tatsächlichen Zweck der Benutzer.
Das obige „Hinzufügen, Löschen, Ändern und Überprüfen“ ist nichts anderes als die Benutzerverwaltung, die der eigentliche Zweck der Teilnehmer ist. Es könnte besser sein, den oben genannten Anwendungsfall folgendermaßen zu behandeln:
Reduzierung der Granularität von Anwendungsfällen
Der Anwendungsfall Benutzer verwalten stellt ein Ziel oder eine Aufgabe für Systemadministratoren dar. Wenn Sie Hinzufügungen, Löschungen, Änderungen und Abfragen hinzufügen müssen, ist es besser, dies folgendermaßen auszudrücken.
Nach der Granularitätsoptimierung des Anwendungsfalls
Ein weiterer Fehler, der bei der Modellierung von Anwendungsfällen häufig gemacht wird, besteht darin, Schritte als Anwendungsfälle zu behandeln. Das Folgende scheint beispielsweise perfekt zu sein, aber es ist offensichtlich, dass die Betriebsschritte als Anwendungsfälle betrachtet werden:
Bedienschritte als Anwendungsfälle, Fehlerbeispiele
Die oben genannten Schritte sind nichts anderes als die Verwirklichung des Ziels des Benutzers als Teilnehmer: die Registrierung. Daher sollte es wie folgt geändert werden:
Nach der Anwendungsfalloptimierung
Der dritte häufige Fehler bei der Anwendungsfallmodellierung besteht darin, Systemaktivitäten als Anwendungsfälle zu behandeln. Im folgenden Anwendungsfalldiagramm sind das Herstellen von Verbindungsobjekten, das Erstellen von Befehlsobjekten und das Ausführen von SQL-Anweisungen Aktivitäten innerhalb des Systems, die für den Benutzer nicht wahrnehmbar sind. Sie sind nicht der Zweck des Benutzers und es ist ihm egal. Daher ist dieses Anwendungsfalldiagramm ungenau:
Beispiel für einen Systemaktivitäts-Anwendungsfallfehler
Der vierte häufige Fehler bei der Modellierung von Anwendungsfällen besteht darin, Anwendungsfälle aus einer Systemperspektive zu benennen.
Verwenden Sie die Systemperspektive, um Anwendungsfall-Fehlerbeispiele zu benennen
Welches der beiden oben genannten Anwendungsfalldiagramme ist besser? Offensichtlich ist der rechte besser als der linke, da der Anwendungsfall auf der rechten Seite aus der Perspektive des Benutzers benannt ist, während der Anwendungsfall auf der linken Seite aus der Perspektive des Systems benannt ist und die Benutzer danach verwirrt sein werden es sehen.
6. Spezifikation des Anwendungsfalls
Das Anwendungsfalldiagramm beschreibt im Allgemeinen die funktionalen Anforderungen des Benutzers (vom System bereitgestellte Funktionen oder Dienste), aber jeder Anwendungsfall muss detailliert beschrieben werden, damit die Benutzer wissen, was der Anwendungsfall konkret tun soll. Dies ist die Anwendungsfallspezifikation. Mit anderen Worten besteht das Use-Case-Modell im Wesentlichen aus einem Use-Case-Diagramm und einer detaillierten Beschreibung jedes Use-Cases (Use-Case-Spezifikation).
Eine Use-Case-Spezifikation sollte folgenden Inhalt enthalten:
(1) Die Identifikation und der Name des Anwendungsfalls;
(2) am Anwendungsfall beteiligte Teilnehmer;
(3) Eine kurze Beschreibung des Anwendungsfalls;
(4) Andere verwandte Anwendungsfälle;
(5) Voraussetzungen für die Ausführung eines Anwendungsfalls
(6) Grundlegender Ereignisablauf;
(7) Alternativer Ereignisfluss;
(8) Nachbedingungen für die Ausführung des Anwendungsfalls;
(9) Sonstige Informationen, wie z. B. nicht funktionale Anforderungen, Designbeschränkungen, Status der Anwendungsfallüberprüfung, Ersteller, Änderungsaufzeichnungen usw.
Die Beziehungen zwischen Anwendungsfällen umfassen hauptsächlich drei Arten: Generalisierung, Inklusion und Erweiterung.
Wenn mehrere Anwendungsfälle ähnliche Attribute oder Verhaltensweisen aufweisen, können wir ihre Gemeinsamkeiten in einen übergeordneten Anwendungsfall und andere Anwendungsfälle als untergeordnete Anwendungsfälle einer Generalisierungsbeziehung abstrahieren. Die untergeordneten Anwendungsfälle erben die Attribute und Verhaltensweisen im übergeordneten Anwendungsfall. Unter der Generalisierungsbeziehung von Anwendungsfällen können unterschiedliche Implementierungspfade für denselben Geschäftszweck verstanden werden.
Die Generalisierungsbeziehung wird grafisch durch eine Implementierung mit einem hohlen Dreieckspfeil dargestellt, der vom untergeordneten Anwendungsfall zum übergeordneten Anwendungsfall zeigt.
Anwendungsfalldiagramm-Verallgemeinerungsbeziehung
Im obigen Beispiel sind „Zahlungsart 1 “ und „Zahlungsart 2 “ Unteranwendungsfälle von „Zahlung“. Der übergeordnete Anwendungsfall „Zahlung“ stellt keine spezifischen Zahlungsmethoden zur Verfügung, sondern lediglich die für die Zahlung notwendigen Attribute und Schnittstellen und implementiert in seinen untergeordneten Anwendungsfällen bestimmte Zahlungsfunktionen.
Während des Systemmodellierungsprozesses müssen einige Funktionen in verschiedenen Geschäftsszenarien wiederholt verwendet werden. Diese wiederholt verwendeten Funktionen können getrennt werden, um einen separaten Anwendungsfall zu bilden, und bei der Ausführung verwandter Funktionen können die getrennten öffentlichen Funktionen in den Hauptprozess einbezogen werden. Die Inklusionsbeziehung von Anwendungsfällen kann diese Situation beschreiben. Wenn ein grundlegender Anwendungsfall zu viele Funktionen hat, kann er außerdem in mehrere kleine Anwendungsfälle zerlegt werden. Die enthaltenen Anwendungsfälle werden als Anbieter-Anwendungsfälle bezeichnet, und die Anwendungsfälle, die andere Anwendungsfälle enthalten, werden als Client-Anwendungsfälle bezeichnet.
In UML wird die Include-Beziehung durch einen gepunkteten Pfeil mit dem Stereotyp <<include>> dargestellt. Der Pfeil zeigt vom Basisanwendungsfall (einschließlich Anwendungsfall/Kundenanwendungsfall) zum eingeschlossenen Anwendungsfall (Anbieteranwendungsfall).
Das Anwendungsfalldiagramm enthält Beziehungen
Das Folgende ist ein konkretes Beispiel: Der Leser muss den Anwendungsfall „Abfragebuch“ ausführen, bevor er das Buch vorab ausleihen kann Gleichzeitig muss der Leser beim Vorausleihen von Büchern beim System angemeldet sein und das System muss seinen Anmeldestatus gespeichert haben, bevor er den Vorausleihvorgang durchführen kann Der Anwendungsfall der Identitätsüberprüfung wird auch im Anwendungsfall „Buch vor der Ausleihe“ enthalten sein. Das Abfragen von Büchern ist nicht nur eine Grundfunktion, die ein Leser benötigt, sondern auch ein notwendiger Vorgang für andere Funktionen. Die Identitätsüberprüfung wird nicht nur bei der Vorausleihe von Büchern verwendet, sondern auch bei der Durchführung von Funktionen wie der Abfrage von Ausleihunterlagen und der Zahlung von Bußgeldern. Es ist sinnvoller, die Identitätsüberprüfung separat vorzuschlagen, um einen Anwendungsfall zu bilden:
Bucheinbeziehungsbeziehung des Lesers zur Vorabausleihe
Basisanwendungsfälle stellen Erweiterungspunkte bereit, in denen neue Verhaltensweisen hinzugefügt werden können. Erweiterungsanwendungsfälle stellen eine Reihe von Einfügefragmenten bereit, die in die Erweiterungspunkte des Basisanwendungsfalls eingefügt werden können.
· Der Basisanwendungsfall stellt nur Erweiterungspunkte bereit, ohne dass Einzelheiten des Erweiterungsanwendungsfalls bekannt sind.
· Im Gegensatz zu einer Inklusionsbeziehung ist ein Basisanwendungsfall auch ohne einen erweiterten Anwendungsfall vollständig.
· Ein Anwendungsfall kann mehrere Erweiterungspunkte bereitstellen und jeder Erweiterungspunkt kann mehrmals auftreten.
· Unter normalen Umständen umfasst die Ausführung des Basisanwendungsfalls nicht den erweiterten Anwendungsfall. Die Funktionen des erweiterten Anwendungsfalls werden nur ausgeführt, wenn bestimmte Bedingungen oder Ereignisse eintreten.
In UML wird eine Erweiterungsbeziehung durch einen gestrichelten Pfeil mit dem Stereotyp <<extend>> dargestellt. Pfeile zeigen von erweiterten Anwendungsfällen zu grundlegenden Anwendungsfällen.
Anwendungsfalldiagramm-Erweiterungsbeziehung
Das folgende Beispiel ist ein Anwendungsfalldiagrammfragment in einem Bibliotheksleihsystem:
Leser zahlen Geldstrafen, um Beziehungen auszubauen
In diesem Beispiel ist die Zahlung einer Geldbuße ein grundlegender Anwendungsfall für den Leser und ein erweiterter Anwendungsfall für die Rückgabe des Buchs. „Geld bezahlen“ als erweiterter Anwendungsfall von „Bücher zurückgeben“ wird nur unter folgenden Bedingungen ausgeführt:
(1) Die Bücher des Lesers sind überfällig oder aus anderen Gründen in Ordnung und wurden nicht vollständig bezahlt;
(2) Der Leser entscheidet sich dafür, die Geldbuße gleichzeitig mit der Rückgabe des Buches zu zahlen.
Das Obige ist der relevante Inhalt zu UML-Anwendungsfalldiagrammen. Alle oben genannten Anwendungsfalldiagramme werden mit ProcessOn gezeichnet.
Kostenlose Online-Zusammenarbeit für Mind Maps und Flussdiagramme 
