In der Software und Systemtechnik ist ein Gebrauch-Fall (hat/jus/, ein Fall im Gebrauch eines Systems ausgesprochen), eine Liste von Schritten, normalerweise Wechselwirkungen zwischen einer Rolle (bekannt in UML als ein "Schauspieler") und einem System definierend, um ein Ziel zu erreichen. Der Schauspieler kann ein Mensch oder ein Außensystem sein.

In der Systemtechnik werden Gebrauch-Fälle an einem höheren Niveau verwendet als innerhalb der Softwaretechnik, häufig Missionen oder Miteigentümer-Absichten vertretend. Die ausführlichen Voraussetzungen können dann in SysML oder als vertragliche Behauptungen gewonnen werden.

Geschichte

1986 hat Ivar Jacobson zuerst und modellierende Textstruktursehtechniken formuliert, um Gebrauch-Fälle anzugeben. 1992 hat sein Co-Authored-Buch geholfen, die Technik zu verbreiten, um funktionelle Voraussetzungen besonders in der Softwareentwicklung zu gewinnen. Ursprünglich hat er die Begriff-Gebrauch-Drehbücher und den Gebrauch-Fall - das letzte Wesen eine direkte Übersetzung seines schwedischen Begriffes användningsfall verwendet - aber hat gefunden, dass keiner dieser Begriffe natürlich in Englisch geklungen hat, und schließlich er sich auf dem Gebrauch-Fall niedergelassen hat. Seitdem haben andere zu Besserung dieser Technik namentlich einschließlich Alistair Cockburns beigetragen.

Verwenden Sie Fall-Struktur

Martin Fowler

Martin Fowler stellt fest, dass "Es keine Standardweise gibt, den Inhalt eines Gebrauch-Falls und die verschiedene Format-Arbeit gut in verschiedenen Fällen zu schreiben." Er beschreibt "einen allgemeinen Stil", wie folgt zu verwenden:

• Titel: "Absicht der Gebrauch-Fall versucht", zu befriedigen
• Haupterfolg-Drehbuch: numerierte Liste von Schritten
• Schritt: "eine einfache Behauptung der Wechselwirkung zwischen dem Schauspieler und einem System"
• Erweiterungen: getrennt numerierte Listen, ein pro Erweiterung
• Erweiterung: "Eine Bedingung, die auf verschiedene Wechselwirkungen davon hinausläuft.. das Haupterfolg-Drehbuch". Eine Erweiterung vom wichtigen Schritt 3 wird 3a usw. numeriert.

Alistair Cockburn

Alistair Cockburn beschreibt eine ausführlichere Struktur für einen Gebrauch-Fall, aber erlaubt ihm, vereinfacht zu werden, wenn weniger Detail erforderlich ist. Seine "völlig angekleidete" Gebrauch-Fall-Struktur ist:

Völlig angekleidete Gebrauch-Fall-Struktur

Die völlig angekleidete Gebrauch-Fall-Schablone von Cockburn verzeichnet die folgenden Felder:

• Titel: "Ein Absicht-Ausdruck des aktiven Verbs, der die Absicht des primären Schauspielers" nennt
• Primärer Schauspieler
• Absicht im Zusammenhang
• Spielraum
• Niveau
• Miteigentümer und Interessen
• Vorbedingung
• Minimale Garantien
• Erfolg versichert
• Abzug
• Haupterfolg-Drehbuch
• Erweiterungen
• Technologie & Datenschwankungsliste
• Zusammenhängende Information.

Außerdem schlägt Cockburn vor, zwei Geräte zu verwenden, um die Natur jedes Gebrauch-Falls anzuzeigen: Ikonen für das Designspielraum und Absicht-Niveau.

Die Annäherung von Cockburn hat andere Autoren beeinflusst; zum Beispiel verallgemeinern Alexander und Beus-Dukic die "völlig angekleidete Gebrauch Fall" Schablone von Cockburn von der Software bis Systeme aller Arten mit den folgenden Feldern, die sich von Cockburn unterscheiden:

• Schwankungsdrehbücher" (vielleicht sich verzweigend von von und vielleicht zum Hauptdrehbuch zurückkehrend)"

,

• Ausnahmen "d. h. Ausnahme-Ereignisse und ihre Ausnahme behandelnden Drehbücher"

Zufällige Gebrauch-Fall-Struktur

Cockburn erkennt an, dass Projekte ausführlich berichtete "völlig angekleidete" Gebrauch-Fälle nicht immer brauchen können. Er beschreibt einen Zufälligen Gebrauch-Fall mit den Feldern:

• Titel (Absicht)

Primärer Schauspieler Spielraum Niveau

• (Geschichte): Der Körper des Gebrauch-Falls ist einfach ein Paragraf oder zwei des Textes, informell beschreibend, was geschieht.

Designspielraum-Ikone

Cockburn schlägt vor, jeden Gebrauch-Fall mit einem Symbol zu kommentieren, um das "Designspielraum" zu zeigen, das schwarzer Kasten sein kann (inneres Detail wird verborgen), oder weißer Kasten (wird inneres Detail gezeigt). Fünf Symbole sind verfügbar:

• Organisation (schwarzer Kasten), eine gefüllte Ikone eines Hauses
• Organisation (weißer Kasten), eine ungefüllte Ikone eines Hauses
• System (schwarzer Kasten), eine gefüllte Ikone eines Kastens
• System (weißer Kasten), eine ungefüllte Ikone eines Kastens
• Bestandteil, eine Ikone einer Schraube oder Bolzens.

Andere Autoren nennen manchmal Gebrauch-Fälle an Organisation Niveau "Geschäftsgebrauch-Fällen".

Absicht-Niveau-Ikone

Cockburn schlägt vor, jeden Gebrauch-Fall mit einem Symbol zu kommentieren, um das "Absicht-Niveau" zu zeigen; das bevorzugte Niveau ist "Benutzerabsicht" (oder umgangssprachlich "Meeresspiegel").

• Sehr hohe Zusammenfassung, eine Ikone einer Wolke
• Zusammenfassung, eine Ikone eines fliegenden Flugdrachen
• Benutzerabsicht, eine Ikone von Wellen auf See
• Subfunktion, eine Ikone eines Fisches
• Zu niedrig, eine Ikone einer Meeresboden-Muschel-Schale.

Schauspieler

Ein Gebrauch-Fall definiert die Wechselwirkungen zwischen Außenschauspielern und dem System unter der Rücksicht, um eine Absicht zu vollbringen. Schauspieler müssen im Stande sein, Entscheidungen zu treffen, aber brauchen nicht menschlich zu sein: "Ein Schauspieler könnte eine Person, eine Gesellschaft oder Organisation, ein Computerprogramm oder ein Computersystem - Hardware, Software oder beide sein." Schauspieler sind immer Miteigentümer, aber viele Miteigentümer sind nicht Schauspieler, da sie "nie direkt mit dem System aufeinander wirken, wenn auch sie das Recht haben sich zu sorgen, wie sich das System benimmt." Zum Beispiel, "die Eigentümer des Systems, konnten der Verwaltungsrat der Gesellschaft und Durchführungskörper wie das US-Finanzamt und die Abteilung der Versicherung" alle Miteigentümer sein, aber werden kaum Schauspieler sein.

Ähnlich kann eine Person, die ein System verwendet, als verschiedene Schauspieler vertreten werden, weil er verschiedene Rollen spielt. Zum Beispiel konnte Benutzer "Joe" die Rolle eines Kunden spielen, als er eine Automatisierte Erzähler-Maschine verwendet hat, um Bargeld von seiner eigenen Rechnung zurückzuziehen, oder die Rolle eines Bankerzählers gespielt hat, als er das System verwendet hat, um die Kassenschublade im Auftrag der Bank wieder auf Lager zu nehmen.

Schauspieler arbeiten häufig im Auftrag jemandes anderen. Cockburn schreibt, dass "An diesen Tagen ich 'Handelsvertreter für den Kunden' oder 'Büroangestellten für die Marktabteilung' schreibe, um das zu gewinnen, handelt der Benutzer des Systems für jemanden anderen." Das sagt dem Projekt, dass die "Benutzerschnittstelle und Sicherheitsabfertigungen" für den Handelsvertreter und Büroangestellten entworfen werden sollten, aber dass der Kunde und die Marktabteilung die über die Ergebnisse betroffenen Rollen sind.

Ein Miteigentümer kann sowohl einen aktiven als auch eine untätige Rolle spielen: Zum Beispiel ist ein Verbraucher beide ein "Massenmarkt-Käufer" (mit dem System nicht aufeinander zu wirken) und ein Benutzer (ein Schauspieler, aktiv mit dem gekauften Produkt aufeinander wirkend). Der Reihe nach ist ein Benutzer beide ein "normaler Maschinenbediener" (ein Schauspieler, der das System zu seinem beabsichtigten Zweck verwendet) und ein "funktioneller Begünstigter" (ein Miteigentümer, der aus dem Gebrauch des Systems einen Nutzen zieht). Zum Beispiel, wenn Benutzer "Joe" Bargeld von seiner Rechnung zurückzieht, operiert er die Automatisierte Erzähler-Maschine und erhält ein Ergebnis in seinem eigenen Interesse.

Cockburn empfiehlt, um nach Schauspielern unter den Miteigentümern eines Systems, den primären und unterstützenden (sekundären) Schauspielern eines Gebrauch-Falls, das System unter dem Design (SuD) selbst, und schließlich unter den "inneren Schauspielern", nämlich die Bestandteile des Systems unter dem Design zu suchen.

Verwenden Sie Fall-Notation

Auf der Vereinigten modellierenden Sprache, den Beziehungen zwischen allen (oder eine Reihe) werden die Gebrauch-Fälle und Schauspieler in einem Gebrauch-Fall-Diagramm oder Diagrammen vertreten, die ursprünglich auf der Objectory Notation von Ivar Jacobson gestützt sind. SysML, ein UML Profil, verwendet dieselbe Notation am Systemblock-Niveau.

Beschränkungen

Beschränkungen von Gebrauch-Fällen schließen ein:

• Gebrauch-Fällen wird dem Gefangennehmen von gestützten Voraussetzungen der Nichtwechselwirkung eines Systems (wie Algorithmus oder mathematische Voraussetzungen) oder nichtfunktionelle Voraussetzungen (wie Plattform, Leistung, Timing oder sicherheitskritische Aspekte) nicht gut angepasst. Diese werden Aussage-anderswohin besser angegeben.
• Gebrauch-Fall-Schablonen sichern Klarheit nicht automatisch. Klarheit hängt von der Sachkenntnis des Schriftstellers ab.
• Gebrauch-Fälle sind kompliziert, um zu schreiben und zu verstehen, sowohl für Endbenutzer als auch für Entwickler.
• Da es keine völlig normalen Definitionen von Gebrauch-Fällen gibt, muss jedes Projekt seine eigene Interpretation bilden.
• Einige Gebrauch-Fall-Beziehungen, solche, die sich ausstrecken, sind in der Interpretation zweideutig und können für Miteigentümer schwierig sein zu verstehen.
• Im Flinken, einfacheren Benutzer werden Geschichten bevorzugt, um Fälle zu verwenden.
• Verwenden Sie Fall-Entwickler häufig finden es schwierig, das Niveau der Abhängigkeit der Benutzerschnittstelle (UI) zu bestimmen, um sich in einem Gebrauch-Fall zu vereinigen. Während Gebrauch-Fall-Theorie darauf hinweist, dass UI nicht in Gebrauch-Fällen widerspiegelt werden, kann es zum Auszug dieser Aspekt des Designs ungeschickt sein, weil es die Gebrauch-Argumente vorbringt, die schwierig sind sich zu vergegenwärtigen. In der Softwaretechnik wird diese Schwierigkeit durch die Verwendung der Voraussetzungsrückverfolgbarkeit zum Beispiel mit einer Rückverfolgbarkeitsmatrix aufgelöst.
• Gebrauch-Fälle können überbetont werden. Bertrand Meyer bespricht Probleme wie das Fahren des Systemdesigns zu wörtlich von Gebrauch-Fällen und dem Verwenden von Gebrauch-Fällen zum Ausschluss anderer potenziell wertvoller Bedarfsanalyse-Techniken.
• Gebrauch-Fälle sind ein Startpunkt für das Testdesign, aber da jeder Test seine eigenen Erfolg-Kriterien braucht, müssen Gebrauch-Fälle eventuell modifiziert werden, um getrennte Postbedingungen für jeden Pfad zur Verfügung zu stellen.

Siehe auch

• Geschäftsfall
• Liste von UML Werkzeugen
• Missbrauch-Fall
• Drehbuch
• Benutzergeschichte

Bibliografie

: Alexander, Ian, und Beus-Dukic, Ljerka. Das Entdecken von Voraussetzungen: Wie man Produkte und Dienstleistungen Angibt. Wiley, 2009.

: Alexander, Ian, und Jungfrau, Neil. Drehbücher, Geschichten, Gebrauch-Fälle. Wiley 2004.

: Rüstung, Frank und Granville Miller. Das fortgeschrittene Gebrauch-Fall-Modellieren: Softwaresysteme. Addison-Wesley, 2000.

: Cockburn, Alistair. Das Schreiben Wirksamer Gebrauch-Fälle. Addison-Wesley, 2001.

: Denney, Richard. Das Folgen mit Gebrauch-Fällen: Das Arbeiten, das klug ist, um Qualität Zu liefern. Addison-Wesley, 2005.

: Fowler, Martin. UML Destilliert (die Dritte Ausgabe). Addison-Wesley, 2004.

: Jacobson Ivar, Christerson M., Jonsson P., Övergaard G., Objektorientierte Softwaretechnik - Ein Gebrauch-Fall Gesteuerte Annäherung, Addison-Wesley, 1992.

: Meyer, Bertrand. Wenden Sie Orientierten Softwareaufbau ein. (2. Ausgabe). Prentice Hall, 2000.

: Schneider, Geri und Winter, Jason P. Applying Use Cases 2. Ausgabe: Ein Praktischer Führer. Addison-Wesley, 2001.

Außenverbindungen

• Verwenden Sie Fälle (Usability.gov)
• Grundlegende Gebrauch-Fall-Schablone durch Alistair Cockburn
• "Ein akademischer Überblick auf der Rolle von Gebrauch-Fällen im UML"