WikiDer > Anwendungsfall

Usecase

EIN Anwendungsfall im Softwareentwicklung und Systemtechnik ist eine Beschreibung des Verhaltens eines Systems, das auf eine Anforderung von außerhalb des Systems antwortet. Mit anderen Worten, der Anwendungsfall beschreibt, „wer“ „was“ mit dem jeweiligen System machen kann. Die Use-Case-Technik wird bei der Ermittlung der Anforderungen das Verhalten eines bestimmten Systems.

Überblick

Ein Anwendungsfall beschreibt ein System aus der Sicht des Benutzers. Es beschreibt die Darsteller, dem Initiator der Interaktion, und das System selbst als Abfolge einfacher Schritte. Akteure können etwas oder jemand sein, der außerhalb des untersuchten Systems existiert und an den aufeinanderfolgenden Aktivitäten in einem Dialog mit dem System teilnimmt, um ein bestimmtes Ziel zu erreichen. Schauspieler können endenBenutzer, andere Systeme oder Hardware- (Ausrüstung). Jeder Anwendungsfall ist eine komplette Reihe von sogenannten "Veranstaltungen“, beschrieben aus der Sicht des Schauspielers.[1]

Nach Bittner und Spence (2002) sind Use Cases einfach eine Beschreibung einer Reihe von Ereignissen, die zusammen dem System ermöglichen, etwas Nützliches zu tun.[2] Jeder Anwendungsfall beschreibt, wie sich der Akteur gegenüber dem System verhält, um ein Ziel zu erreichen. Aus einem einzigen Anwendungsfall mehrere Szenarien generiert werden, entsprechend jedem Weg, um ein Ziel zu erreichen. Bei der Erstellung von Use Cases wird generell auf Fachjargon verzichtet und die Sprache der Endnutzer angepasst. Sie werden oft in Zusammenarbeit zwischen einem Systemanalysten und dem Endbenutzer erstellt. In dem Einheitliche Modellierungssprache können Anwendungsfalldiagramme kann verwendet werden, um die Anwendungsfälle eines bestimmten Systems grafisch darzustellen.

Im Systemtechnik Anwendungsfälle werden oft auf einer höheren Abstraktionsebene definiert als innerhalb von Softwareentwicklung, um die Missionen eines Systems oder die Ziele eines Interessengruppen Anzeige. Ausführlich Anforderungen kann hiermit angezeigt werden in SysMLAnforderungDiagramme oder ähnliche schematische Techniken.

Ursprung

Der Begriff „Usecase“ wurde Mitte der 1980er Jahre geprägt von Ivar Jacobson und stammt vom älteren Konzept ab"Nutzungsszenario", oder Nutzungsszenario. Jacobson begann 1967 bei Ericsson mit dem Schreiben von Nutzungsszenarien, um die Architektur von Ericssons AX-System zu beschreiben. In den 1980er Jahren begann Jacobson über seine Arbeitsweise nachzudenken und entwickelte das schwedische Konzept "anvenendningsfall", was grob für "Nutzungssituation" steht. Direkt ins Englische übersetzt wäre dies "Anwendungsfall“, fand aber, dass beide Begriffe nicht selbstverständlich klangen. Am Ende gab er sich mit dem Konzept des „Usecase“ zufrieden. 1986 formulierte Jacobson auch die erste visuelle Modellierungstechnik zur Spezifikation von Use Cases.[3]

Seit Jacobson es Anwendungsfallmodell viele haben zur Verbesserung dieser Technik beigetragen, darunter Kurt Bittner, Alistair Cockburn, Gunnar Overgaard und Geri Schneider. In den 1990er Jahren wurde der Use Case zu einer der gängigen Methoden zur Erfassung funktionaler Anforderungen. Dies war vor allem in der objektorientierten Community, aber die Anwendbarkeit der Methode ist nicht auf objektorientierte Systeme beschränkt, da Anwendungsfälle selbst nicht objektorientierter Natur sind.

Themen der Anwendungsfälle

Fokus Anwendungsfall

Jeder Anwendungsfall konzentriert sich auf die Beschreibung, wie ein Ziel erreicht oder eine Aufgabe ausgeführt wird. Für die meisten Softwareprojekte bedeutet dies, dass mehrere, manchmal dutzende Anwendungsfälle benötigt werden, um den Umfang eines neuen Systems zu definieren. Der Formalisierungsgrad eines bestimmten Softwareprojekts und der Entwicklungsstand bestimmen den Detaillierungsgrad, der für jeden Anwendungsfall erforderlich ist. Use Cases sollten nicht mit den Eigenschaften des zu entwickelnden Systems verwechselt werden. Ein Anwendungsfall als verwendetes Szenario kann sich auf eine oder mehrere Eigenschaften beziehen und eine Eigenschaft auf einen oder mehrere Anwendungsfälle.

Ein Anwendungsfall definiert die Interaktion zwischen externen Akteuren und einem bestimmten System, um ein Ziel zu erreichen. Ein Akteur gibt eine Rolle an, die eine Person oder Sache spielt, die mit dem System interagiert.[4] Dieselbe Person, die das System nutzt, kann mit verschiedenen Akteuren repräsentiert werden, wenn die Person mehrere Rollen erfüllt. Zum Beispiel kann eine Person "John" die Rolle des Kunden spielen, wenn sie Geld von einem Geldautomaten abhebt, und kann die Rolle eines Bankangestellten spielen, der den Geldautomaten auffüllt.

Anwendungsfälle behandeln das System als Flugschreiber, und Interaktionen mit dem System, einschließlich der Systemantwort, werden als von außerhalb des Systems kommend verstanden. Dies ist eine bewusste Entscheidung, damit sich der Analytiker auf das konzentrieren kann, was das System tun soll, und nicht darauf, wie es gemacht wird. Dies verhindert, dass Menschen Annahmen über die Funktionalität des Systems treffen, um seine Aufgaben zu erfüllen. Use Cases können auf abstrakter Ebene, auch „Business Use Case“ oder „Essential Use Case“ genannt, und auf Systemebene als „System Use Case“ beschrieben werden. Der Unterschied liegt hier im Umfang:

  • Das Geschäftsanwendungsfall wird in einer nicht-technischen Terminologie beschrieben, die Systeme als Blackboxen betrachtet, und beschreibt den Geschäftsprozess, der von seinen Geschäftsakteuren (Personen oder Systemen außerhalb des Prozesses) verwendet wird, um ihren Zweck zu erreichen (z Immobilien des Unternehmens). Der Geschäftsanwendungsfall beschreibt einen Prozess, der dem Geschäftsakteur einen Mehrwert bietet, und beschreibt, was der Prozess tut. Eine andere Methode der Geschäftsbeschreibung auf dieser Ebene ist beispielsweise Notation der Geschäftsprozessmodellierung (BPMN)
  • Das Systemanwendungsfall beschreibt ein System, das einen Geschäftsanwendungsfall oder -prozess auf einer Systemfunktionalitätsebene automatisiert (z. B. 'Zugangskarte erstellen') und die Funktion oder den Dienst spezifiziert, den das System dem Endbenutzer bereitstellt. Ein Systemanwendungsfall beschreibt, was das System als Reaktion auf den Akteur tut. Aus diesem Grund empfiehlt es sich, die Spezifikation dieses Anwendungsfalls mit einem Verb zu beginnen (z. B. Zugangskarte erstellen, Zahlung auswählen, Zahlung durchführen, Zugangskarte sperren).

Im Allgemeinen sollte ein Anwendungsfall:

  • Beschreiben Sie, was ein System leisten muss, damit ein Akteur ein bestimmtes Ziel erreicht.
  • in einer implementierungsunabhängigen Spezifikationssprache verfasst sein
  • einen angemessenen Detaillierungsgrad haben
  • Keine Details enthalten über Benutzeroberfläche oder Imageaufbau. Dies geschieht nur mit dem Design der Benutzeroberfläche.

Detaillierungsgrad

Cockburn (2001) hat drei Granularitätsstufen in schriftlichen Anwendungsfällen identifiziert:[5]

  • Kurzer Anwendungsfall (Anwendungsfall für Briefe): besteht aus wenigen Sätzen, die den Anwendungsfall zusammenfassen. Dies würde in eine Tabellenkalkulationszelle passen, wobei die anderen Spalten Dinge wie Priorität, technische Komplexität, Anzahl usw. angeben.
  • Häufiger Anwendungsfall (Beiläufiger Anwendungsfall): besteht aus wenigen Textabsätzen, die den Anwendungsfall zusammenfassen.
  • Vollständig abgeschlossener Anwendungsfall (Vollständig gekleideter Anwendungsfall): Dies ist ein formales Dokument, das auf einem detaillierten Modell mit Feldern für verschiedene Abschnitte basiert. Dies ist die häufigste Bedeutung der Use-Case-Idee.

Anwendbares Detail

Manche Softwareentwicklungsprozesse benötigen nur wenige einfache Anwendungsfälle, um die Anforderungen zu definieren. Andere Entwicklungsprozesse erfordern jedoch detaillierte Anwendungsfälle, um diese Anforderungen zu definieren. Je größer und komplexer das Projekt ist, desto wahrscheinlicher sind detaillierte Anwendungsfälle.

Der Detaillierungsgrad eines Anwendungsfalls ändert sich häufig im Laufe des Projekts. Die ersten Anwendungsfälle können kurz sein, werden aber im Verlauf des Entwicklungsprozesses detaillierter. Dies spiegelt sich auch in den sich ändernden Anforderungen des Anwendungsfalls wider. Zu Beginn müssen sie sich nur kurz fassen, um die Geschäftsanforderungen aus Anwendersicht zusammenzufassen. Im weiteren Verlauf des Prozesses benötigen Entwickler spezifischere und detailliertere Richtlinien.

In dem Rationaler einheitlicher Prozess Entwickler sind eingeladen, kurze Anwendungsfälle in . einzureichen Anwendungsfalldiagramme Beschreibung, mit einer einfachen Beschreibung als Kommentar und einer detaillierten Beschreibung des Ereignisablaufs in einer Textanalyse. All dies kann in der Regel in ein Use-Case-Tool (zum Beispiel ein UML-Tool oder SysML-Tool) eingegeben oder in einem separaten Textverarbeitungsprogramm ausgearbeitet werden.

Use-Case-Notation

In dem Einheitliche Modellierungssprache die Beziehung zwischen allen Anwendungsfällen und Akteuren wird in Anwendungsfalldiagramme, oder in Diagrammen basierend auf Ivar Jacobson's Objectory-Notation. SysML, ein UML-Profil, verwendet dieselbe Notation auf Systemanwendungsfallebene.

Anwendungsfälle und der Entwicklungsprozess

Die konkrete Verwendung von Use Cases in einem Entwicklungsprozess hängt auch von der verwendeten Entwicklungsmethodik ab. Bei bestimmten Methoden ist nur eine kurze Use-Case-Exploration vorgeschrieben. Bei anderen Methoden ändern sich Anwendungsfälle mit dem Charakter des Entwicklungsprozesses. Bei anderen Methoden kann die Anwendungsfallbeschreibung einfach beginnen und in eine sehr detaillierte Beschreibung der erforderlichen Testverfahren münden.

Usecase-Vorlagen

Für die Dokumentation detaillierter Anwendungsfälle gibt es keine Standardvorlagen. Es gibt eine Reihe von konkurrierenden Systemen. Einzelpersonen werden ermutigt, Anwendungsfallvorlagen zu verwenden, die für sich selbst oder das Projekt gut funktionieren. Die Standardisierung innerhalb eines Projekts ist wichtiger als die Details einer bestimmten Vorlage. Bei den zentralen Abschnitten herrscht jedoch weitgehende Einigkeit. Neben unterschiedlichen Terminologien und Ordnungsprinzipien gibt es grundlegende Ähnlichkeiten zwischen den meisten Anwendungsfällen. Verschiedene Vorlagen verwenden oft zusätzliche Abschnitte, zum Beispiel Annahmen, Ausnahmen, Empfehlungen, technische Anforderungen. Es gibt auch oft branchenspezifische Abschnitte. Häufige Bausteine ​​in Anwendungsfällen sind:

  • Anwendungsfallname: Ein Anwendungsfallname stellt eine eindeutige Kennung für den Anwendungsfall bereit.
  • Version: Eine Version ist wichtig, um dem Leser einen Einblick in das Stadium zu geben, das der Anwendungsfall erreicht hat.
  • Ziel: Ein Ziel beschreibt kurz, was der Nutzer mit dem Use Case erreichen möchte
  • Zusammenfassung: Dieser Abschnitt enthält die Essenz des Anwendungsfalls und bietet einen Überblick.
  • Akteure: Ein Akteur ist jemand oder etwas außerhalb des Systems, das mit dem System interagiert.
  • Vorbedingungen: Ein Abschnitt, der alle Bedingungen definiert, die erfüllt sein müssen.
  • Auslöser: Ein Abschnitt beschreibt die Ereignisse, die den Anwendungsfall auslösen
  • Grundlegender Ablauf der Ereignisse: ein primäres Szenario oder ein Ablauf von Ereignissen
  • Alternative Straßen: Nebenstraßen oder alternative Szenarien
  • Nachbedingungen: Beschreibung des Endzustands des Systems nach Ablauf des Anwendungsfalls.
  • Geschäftsregeln: Geschriebene oder ungeschriebene Regeln oder Richtlinien, die bestimmen, wie eine Organisation auf einen bestimmten Anwendungsfall reagieren soll.
  • Hinweise: Wichtige Hinweise, die nicht in das vorgefasste Format passen.
  • Autor und Datum

Siehe auch

Externe Links