Anwendungsfall

Eine sehr einfache Anwendungsfalldiagramm von a Wiki System.

Im Software und Systemtechnik, der Satz Anwendungsfall ist ein Polysem mit zwei Sinne:

1. Ein Nutzungsszenario für ein Software -Stück; häufig im Plural verwendet, um Situationen vorzuschlagen, in denen eine Software nützlich sein kann.
2. Ein potenzielles Szenario, in dem ein System eine externe Anforderung (z. B. Benutzereingabe) erhält und darauf reagiert.

In diesem Artikel wird der letztere Sinn erörtert.

A Anwendungsfall ist eine Liste von Aktionen oder Ereignisschritten, die normalerweise die Wechselwirkungen zwischen einer Rolle definieren (bekannt in der Einheitliche Modellierungssprache (Uml) als Schauspieler) und ein System, um ein Ziel zu erreichen. Der Schauspieler kann ein menschliches oder anderes externes System sein. In Systemtechnik werden Anwendungsfälle auf einer höheren Ebene als innerhalb verwendet Softwareentwicklung, oft repräsentieren Missionen oder Interessengruppen Tore. Die detaillierten Anforderungen können dann in der erfasst werden Systemmodellierungssprache (Sysml) oder als vertragliche Aussagen.

Geschichte

In 1987, Ivar Jacobson präsentierte den ersten Artikel über Anwendungsfälle an der Oopsla'87 Konferenz.^[1] Er beschrieb, wie diese Technik bei verwendet wurde Ericsson Anforderungen eines Systems erfassen und angeben mithilfe von Text, strukturell und visuelle Modellierung Techniken zum antworten objektorientierten Analyse und Design.^[2] Ursprünglich hatte er die Begriffe benutzt Nutzungsszenarien und Nutzungsfall - letzteres eine direkte Übersetzung seines schwedischen Begriffs ANVAndningsfall - aber festgestellt, dass keiner dieser Begriffe in englischer Sprache natürlich klang, und schließlich entschied er sich weiter Anwendungsfall.^[3]

1992 hat er das Buch gemeinsam verfasst Objektorientiertes Software -Engineering - Ein Anwendungsfall -Ansatz,^[4] die die Grundlage der Grundlage der Oose System Engineering -Methode und half bei der Popularisierung von Anwendungsfällen für die Erfassung funktionale Anforderungen, besonders in Software-Entwicklung. 1994 veröffentlichte er ein Buch über Anwendungsfälle und objektorientierte Techniken, die auf angewendet wurden Geschäftsmodelle und Neuerstellung der Geschäftsprozesse.^[5]

Zur selben Zeit, Grady Booch und James Rumbaugh arbeitete darin, ihre zu vereinen Objektorientierte Analyse und Design Methoden, die Booch -Methode und Objektmodellierungstechnik (OMT) beziehungsweise. 1995 schloss sich Ivar Jacobson ihnen an und zusammen haben sie das geschaffen Einheitliche Modellierungssprache (UML), einschließlich Anwendungsfallmodellierung. UML wurde durch die standardisiert Objektverwaltungsgruppe (OMG) in 1997.^[6] Jacobson, Booch und Rumbaugh arbeiteten auch an einer Verfeinerung der Objektor Softwareentwicklungsprozess. Das resultierende Einheitlicher Prozess wurde 1999 veröffentlicht und förderte einen Anwendungsfall -Ansatz.^[7]

Seitdem haben viele Autoren zur Entwicklung der Technik beigetragen, insbesondere: Larry Constantine entwickelt 1995 im Kontext von Nutzungszentriertes Design, so genannte "wesentliche Anwendungsfälle", die darauf abzielen, Benutzerabzüge und nicht Sequenzen von Aktionen oder Szenarien zu beschreiben, die das Design der Benutzeroberfläche einschränken oder verzerrt können;^[8] Alistair Cockburn veröffentlicht im Jahr 2000 eine zielorientierte Anwendungsfallpraxis basierend auf Textnarrativen und tabellarischen Spezifikationen;^[9] Kurt Bittner und Ian Spence wurden 2002 erweiterte Praktiken zur Analyse der Funktionsanforderungen mit Anwendungsfällen entwickelt;^[10] Dean Leffingwell und Don Widrig schlugen vor, Anwendungsfälle für die Änderung des Managements und die Kommunikationsaktivitäten der Stakeholder anzuwenden.^[11] Gunnar Overgaard schlug 2004 vor, die Prinzipien der Entwurfsmuster auf Anwendungsfälle auszudehnen.^[12]

Im Jahr 2011 veröffentlichte Jacobson mit Ian Spence und Kurt Bittner The eBook Anwendungsfall 2.0 Um die Technik an einen agilen Kontext anzupassen, sie mit inkrementellen Anwendungsfall "Slices" zu bereichern und deren Verwendung über den gesamten Entwicklungslebenszyklus zu fördern^[13] Nachdem er den erneuten Ansatz auf dem Jahresansatz vorgelegt hatte Iiba Konferenz.^[14][15]

Allgemeines Prinzip

Anwendungsfälle sind eine Technik zur Erfassung, Modellierung und Angabe der Anforderungen eines Systems.^[10] Ein Anwendungsfall entspricht einer Reihe von Verhaltensweisen, die das System in der Interaktion mit seinen Akteuren durchführen kann und was zu einem beobachtbaren Ergebnis führt, das zu seinen Zielen beiträgt. Akteure repräsentieren die Rolle, die menschliche Benutzer oder andere Systeme in der Interaktion haben.

In dem AnforderungsanalyseBei ihrer Identifizierung wird ein Anwendungsfall nach dem spezifischen Benutzerziel benannt, das er für seinen primären Akteur darstellt. Der Fall wird mit einer Textbeschreibung oder zusätzlichen grafischen Modellen, die die allgemeine Abfolge von Aktivitäten und Ereignissen sowie Varianten wie besondere Bedingungen, Ausnahmen oder Fehlersituationen erläutert, weiter beschrieben.

Laut dem Software -Engineering -Karosserie (Swebok),^[16] Anwendungsfälle gehören zum szenariobasierten Erfordernis Erklärung Techniken sowie die Modellbasierte Analyse Techniken. Die Anwendungsfälle unterstützen jedoch auch narrativbasierte Anforderungen an die Erfassung von Anforderungen, die Erfassung von Anforderungen, die Systemdokumentation und die Akzeptanzprüfung.^[1]

Variationen

Es gibt verschiedene Arten von Anwendungsfällen und Variationen in der Technik:

• Systemanwendungsfälle geben die Anforderungen eines zu entwickelnden Systems an.^[2] Sie identifizieren in ihrer detaillierten Beschreibung nicht nur die Interaktionen mit den Akteuren, sondern auch die Unternehmen, die an der Verarbeitung beteiligt sind. Sie sind der Ausgangspunkt für weitere Analysemodelle und Designaktivitäten.
• Unternehmensnutzungsfälle konzentrieren sich auf eine Unternehmensorganisation anstelle eines Softwaresystems. Sie werden verwendet, um Geschäftsmodelle und Geschäftsprozessanforderungen im Kontext von Initiativen zur Reengineering von Geschäftsprozessen zu spezifizieren.^[5]
• Wesentliche Anwendungsfälle, auch abstrakte Anwendungsfälle, beschreiben die potenziellen Absichten der Akteure und wie das System diese anspricht, ohne eine Sequenz zu definieren oder ein Szenario zu beschreiben.^[8] Diese Praxis wurde mit dem Ziel entwickelt, das benutzerzentrierte Design zu unterstützen und zu vermeiden, eine Verzerrung der Benutzeroberfläche in der frühen Phase der Systemspezifikationen zu induzieren.^[7]
• Anwendung Fall 2.0 passt die Technik für den Kontext agiler Entwicklungsmethoden an.^[1] Diese Technik bereichert die Erfordernis, die Praxis zu sammeln, mit Unterstützung von Erzählungen der benutzergeschriebenen Erzählungen. Es bietet auch Anwendungsfall "Slices", um eine inkrementelle Erhebung der Anforderungen zu erleichtern und eine inkrementelle Implementierung zu ermöglichen.

Zielfernrohr

Der Umfang eines Anwendungsfalls kann durch Subjekt und Ziele definiert werden:

• Das Subjekt identifiziert das System, das Subsystem oder die Komponente, die die Wechselwirkungen liefert.^[17]
• Die Ziele können hierarchisch strukturiert werden, unter Berücksichtigung der Organisationsstufe, die an dem Ziel (z. B. Unternehmen, Abteilung, Benutzer) und der Zerlegung des Ziels des Benutzers in Sub-Goals interessiert ist.^[9] Die Zersetzung des Ziels erfolgt aus Sicht der Benutzer und unabhängig vom System, das sich von der traditionellen funktionellen Zersetzung unterscheidet.^[10]  

Verwendungszweck

Anwendungsfälle sind in den folgenden Kontexten bekannt:

• Objektorientiertes Software -Engineering (Oose)als Fahrelement;^[4]
• Einheitliche Modellierungssprache (UML) als Verhaltensmodellinstrument;^[17]
• Einheitlicher Softwareentwicklungsprozess (UP) und sein Vorgänger, die IBM Rational Unified Process (RUP);^[7]
• Vorabdokumentation von Softwareanforderungen (SRS) als alternative Struktur für die funktionalen Anforderungen;^[18]
• Abfertigung des Designs von den Anforderungen mit der Entitätskontroll- und Gradstunde sich nähern;^[7]
• und agile Entwicklung.^[1][19]

Vorlagen

Es gibt viele Möglichkeiten, einen Anwendungsfall in Text zu schreiben, von Anwendungsfall Brief, zwanglos, Gliederung, zu voll angezogen usw. und mit unterschiedlichen Vorlagen. Das Schreiben von Anwendungsfällen in Vorlagen, die von verschiedenen Anbietern oder Experten entwickelt wurden, ist eine gängige Branchenpraxis, um qualitativ hochwertige funktionale Systemanforderungen zu erhalten.

Cockburn -Stil

Die Vorlage definiert von Alistair Cockburn in seinem Buch Schreiben effektiver Anwendungsfälle schreiben war einer der am häufigsten verwendeten Schreibstile von Anwendungsfällen.

Designbereiche

Cockburn schlägt vor, jeden Anwendungsfall mit einem Symbol zu kommentieren, um den "Design Scope" anzuzeigen, der möglicherweise Black-Box (internes Detail ist versteckt) oder Weißbox (interne Details wird gezeigt). Fünf Symbole sind verfügbar:^[20]

Zielfernrohr	Symbol
Organisation (Black-Box)	Gefülltes Haus
Organisation (White-Box)	Unbesetztes Haus
System (Black-Box)	Gefüllte Schachtel
System (White-Box)	Ungefüllte Schachtel
Komponente	Schraube oder Schraube

Andere Autoren rufen manchmal Anwendungsfälle auf Organisationsebene "Business -Anwendungsfälle" an.^[21]

Zielniveaus

Hierarchie der Zielebenen

Cockburn schlägt vor, jeden Anwendungsfall mit einem Symbol zu kommentieren, um die "Zielebene" zu zeigen.^[22] Die bevorzugte Ebene ist "Benutzer-Goal" (oder umgangssprachlich "Meeresspiegel"^{[23]: 101}).

Zielniveau	Symbol	Symbol
Sehr hohe Zusammenfassung	Wolke	++
Zusammenfassung	Fliegender Drachen	+
Benutzerziel	Wellen auf See	!
Unterfunktion	Fische	-
Zu niedrig	Meeresboden Muschelschale	--

Manchmal ist ein Anwendungsfallname im Textschreiben, gefolgt von einem alternativen Textsymbol (!, +, -usw.) eine prägnantere und bequemere Möglichkeit, die Ebenen zu bezeichnen, z. eine Bestellung aufgeben!, Anmeldung-.

Voll angezogen

Cockburn beschreibt eine detailliertere Struktur für einen Anwendungsfall, ermöglicht jedoch, dass sie vereinfacht werden, wenn weniger Details erforderlich sind. In seiner vollbezogenen Anwendungsfallvorlage listet die folgenden Felder auf:^[24]

• Titel: "Ein Active-Verb-Zielphrase, der das Ziel des Hauptdarstellers nennt"^[25]
• Hauptdarsteller
• Ziel im Kontext
• Zielfernrohr
• Eben
• Stakeholder und Interessen
• Voraussetzung
• Minimale Garantien
• Erfolgsgarantien
• Abzug
• Haupt Erfolgsszenario
• Erweiterungen
• Liste der Technologie- und Datenvariationen

Darüber hinaus schlägt Cockburn vor, zwei Geräte zu verwenden, um die Art jedes Anwendungsfalls anzuzeigen: Symbole für Designumfang und Zielniveau.

Der Ansatz von Cockburn hat andere Autoren beeinflusst. Zum Beispiel verallgemeinern Alexander und Beus-Dukic Cockburns "vollständig gekleidete Anwendungsfall" -Scham von Software auf Systeme aller Art, wobei die folgenden Felder von Cockburn unterscheiden:^[26]

• Variationsszenarien "(vielleicht abzweigen und vielleicht zum Hauptszenario zurückkehren)"
• Ausnahmen "d. H. Ausnahmeereignisse und deren Ausnahmebehandlung" -Szenarien "

Zwanglos

Cockburn erkennt an, dass Projekte möglicherweise nicht immer detaillierte "vollständig gekleidete" Anwendungsfälle benötigen. Er beschreibt einen lässigen Anwendungsfall mit den Feldern:^[24]

• Titel (Ziel)
• Hauptdarsteller
• Zielfernrohr
• Eben
• (Geschichte): Der Körper des Anwendungsfalls ist einfach ein oder zwei Absätze von Text, was informell beschreibt, was passiert.

Fowler -Stil

Martin Fowler Staaten "Es gibt keine Standardmethode, um den Inhalt eines Anwendungsfalls zu schreiben, und verschiedene Formate funktionieren in verschiedenen Fällen gut."^{[23]: 100} Er beschreibt "einen gemeinsamen Stil, den man nutzen kann" wie folgt:^{[23]: 101}

• Titel: "Ziel Der Anwendungsfall versucht zu befriedigen"^{[23]: 101}
• Haupt Erfolgsszenario: nummerierte Liste der Schritte^{[23]: 101}
  • Schritt: "Eine einfache Aussage der Interaktion zwischen dem Schauspieler und einem System"^{[23]: 101}
• Erweiterungen: separat nummerierte Listen, eine pro Erweiterung^{[23]: 101}
  • Erweiterung: "Eine Bedingung, die zu unterschiedlichen Interaktionen von .. dem Haupt -Erfolgszenario führt". Eine Erweiterung aus dem Hauptschritt 3 ist nummeriert 3A usw.^{[23]: 101}

Der Fowler -Stil kann auch als vereinfachte Variante der Cockburn -Vorlage angesehen werden. Diese Variante wird a genannt Benutzer Geschichte.

Alistair Cockburn erklärte:^[27]

Stellen Sie sich eine Benutzergeschichte als Anwendungsfall mit 2 Präzisionsbits vor. Bit 1 der Präzision nennt das Ziel des Anwendungsfalles, Bit 2 fügt das Hauptszenario hinzu. Bit 3 fügt die Fehlerbedingungen hinzu, Bit 4 fügt die Fehleraktionen hinzu. Bit 5 fügt Datenbeschreibung der In/Out -Daten hinzu. Ich würde Katalyse auf ein 6. Präzision einstellen, da sie ein Modell des Empfängers der Nachricht enthält. Verwenden Sie in der Crystalmethodology -Familie unterschiedlich gegründete Projekte Anwendungsfälle auf verschiedenen Genauigkeitsniveaus. Ein methodisch leichter Projekt verwendet Benutzergeschichten, ein methodisch schwereres Projekt verwendet Anwendungsfälle bis 4 Präzisionsbits, und die Katalyse verwendet 6 Bit Genision.

Martin Fowler erklärte:^[28]

Es geht darum, wie Menschen Anwendungsfälle verwenden. Ich habe gesehen, wie viele Menschen Anwendungsfälle sehr formalisiert verwenden. Kent macht seine Usstors viel zugänglicher. Ich mache Anwendungsfälle so, wie Kent Benutzergeschichten macht. Ich nenne sie Anwendungsfälle, um besser mit anderen Entwicklern zu kommunizieren und sie zu beeinflussen, um einen leichten Ansatz zu verwenden.

Schauspieler

Ein Anwendungsfall definiert die Wechselwirkungen zwischen externen Akteuren und dem betrachteten System, um ein Ziel zu erreichen. Akteure müssen in der Lage sein, Entscheidungen zu treffen, müssen jedoch nicht menschlich sein: "Ein Akteur könnte eine Person, ein Unternehmen oder eine Organisation, ein Computerprogramm oder ein Computersystem sein - Hardware, Software oder beides."^[29] Schauspieler sind immer Stakeholder, aber nicht alle Beteiligten sind Akteure, da sie möglicherweise "niemals direkt mit dem System interagieren, auch wenn sie das Recht haben, sich zu kümmern, wie sich das System verhält".^[29] Zum Beispiel könnten "die Eigentümer des Systems, der Verwaltungsrat des Unternehmens und die Aufsichtsbehörden wie der Internal Revenue Service und das Department of Insurance" alle Stakeholder sein, aber es ist unwahrscheinlich, dass sie Akteure sind.^[29]

In ähnlicher Weise kann eine Person, die ein System verwendet, aufgrund von unterschiedlichen Rollen als unterschiedliche Schauspieler dargestellt werden. Zum Beispiel könnte der Benutzer "Joe" die Rolle eines Kunden spielen, wenn sie eine automatisierte Teller -Maschine verwendet Bank.

Akteure arbeiten oft im Namen von jemand anderem. Cockburn schreibt, dass "heutzutage ich" Vertriebsmitarbeiter für den Kunden "oder" Angestellter für die Marketingabteilung "schreibe, um festzustellen, dass der Benutzer des Systems für jemand anderen handelt." Dies zeigt dem Projekt, dass die "Benutzeroberfläche und Sicherheitsüberprüfungen" für den Vertriebsmitarbeiter und den Angestellten konzipiert werden sollten, aber dass die Kundin und Marketingabteilung die Rolle der Ergebnisse sind.^[30]

Ein Stakeholder kann sowohl eine aktive als auch eine inaktive Rolle spielen: Beispielsweise ist ein Verbraucher sowohl ein "Massenmarktkäufer" (nicht mit dem System interagieren) als auch ein Benutzer (ein Akteur, der aktiv mit dem gekauften Produkt interagiert).^[31] Ein Benutzer ist wiederum sowohl ein "normaler Operator" (ein Akteur, der das System für seinen beabsichtigten Zweck verwendet) als auch ein "funktionaler Begünstigter" (ein Stakeholder, der von der Verwendung des Systems profitiert).^[31] Wenn der Benutzer "Joe" beispielsweise Bargeld von seinem Konto abhebt, betreibt er die automatisierte Teller -Maschine und erhält ein Ergebnis in seinem eigenen Namen.

Cockburn rät, nach Akteuren unter den Interessengruppen eines Systems, der primären und unterstützenden (sekundären) Akteure eines Anwendungsfalls, des Systems in Design (SUD) und schließlich unter den "internen Akteuren", nämlich die Komponenten des Systems, zu suchen im Design.^[29]

Geschäftsgebrauchsfall

Auf die gleiche Weise wie ein Anwendungsfall beschreibt eine Reihe von Ereignissen und Interaktionen zwischen einem Benutzer (oder anderen Art von Akteur) und einem System, um ein Ergebnis von Wert (Ziel) zu erzielen zwischen einem Geschäftssystem und den Benutzern/Akteuren dieses Systems, um geschäftliche Wertergebnisse zu erzielen. Der Hauptunterschied besteht darin, dass das in einem Unternehmensgebrauchsmodell berücksichtigte System zusätzlich zu technologischen Systemen Personen enthalten kann. Diese "Menschen im System" werden als Business -Mitarbeiter bezeichnet. In dem Beispiel eines Restaurants muss eine Entscheidung getroffen werden, ob jede Person (damit außerhalb des Systems) oder eines Geschäftsangestellten (innerhalb des Systems) die Person behandelt werden soll. Wenn ein Kellner als Schauspieler betrachtet wird, wie im folgenden Beispiel gezeigt, enthält das Restaurantsystem nicht den Kellner, und das Modell enthält die Interaktion zwischen dem Kellner und dem Restaurant. Eine Alternative wäre es, den Kellner als Teil des Restaurantsystems (einen Geschäftspersonal) zu betrachten, während der Kunde außerhalb des Systems (ein Akteur) liegt.^[32]

Ein Geschäft Anwendungsfalldiagramm zeigt ein Modell von mehreren Geschäftsanwendungsfälle (Ziele), die die Interaktionen zwischen einem Restaurant (dem Geschäftssystem) und seinen primären Stakeholdern darstellen (Wirtschaftsakteure und Wirtschaftsarbeiter).

Visuelle Modellierung

Anwendungsfälle sind nicht nur Texte, sondern auch bei Bedarf Diagramme. In dem Einheitliche ModellierungsspracheDie Beziehungen zwischen Anwendungsfällen und Akteuren sind in vertreten Anwendungsfalldiagramme ursprünglich basierend auf Ivar Jacobson's Objektor Notation. Sysml Verwendet dieselbe Notation auf Systemblockebene.

Darüber hinaus andere Verhaltens -UML -Diagramme wie z. Aktivitätsdiagramme, Sequenzdiagramme, Kommunikationsdiagramme und Zustandsmaschinendiagramme kann auch verwendet werden, um Anwendungsfälle entsprechend zu visualisieren. Insbesondere a Systemsequenzdiagramm (SSD) ist ein Sequenzdiagramm, das häufig verwendet wird, um die Wechselwirkungen zwischen den externen Akteuren und dem System in Design (SUD) zu zeigen, in der Regel zur Visualisierung eines bestimmten Szenarios eines Anwendungsfalles.

Die Anwendungsfallanalyse beginnt normalerweise mit dem Zeichnen von Anwendungsfalldiagrammen. Für agile Entwicklung, ein Anforderungsmodell vieler UML -Diagramme, die Anwendungsfälle darstellen, plus einige Textbeschreibungen, Notizen oder Anwendungsfalluntersuchungen wäre sehr leicht und gerade genug für kleine oder einfache Projektgebrauch. Als gute Ergänzungen zu Anwendungsfalltexten sind die Vict -Diagramm -Darstellungen von Anwendungsfällen auch wirksame Erleichterungsinstrumente für das bessere Verständnis, die Kommunikation und das Design komplexer Systemverhaltensanforderungen.

Beispiele

Im Folgenden finden Sie ein Beispiel-Anwendungsfall mit einer leicht modifizierten Version der Vorlage im Cockburn-Stil. Beachten Sie, dass es in der grundlegenden Anwendungsfallbeschreibung keine Schaltflächen, Steuerelemente, Formulare oder andere UI -Elemente und -Operationen gibt, bei denen nur Benutzerziele, Unterläufe oder Absichten in jedem Schritt des Grundflusses oder der grundlegenden Erweiterungen ausgedrückt werden. Diese Praxis macht die Anforderungspezifikation klarer und maximiert die Flexibilität des Designs und der Implementierung.

Anwendungsfall: Bearbeiten Sie einen Artikel

Hauptdarsteller: Mitglied (Registrierter Nutzer)

Zielfernrohr: a Wiki System

Eben:! (Benutzerziel oder Meeresspiegel)

Knapp: (äquivalent zu a Benutzer Geschichte oder ein Epos)

Das Mitglied bearbeitet jeden Teil (den gesamten Artikel oder nur einen Abschnitt) eines Artikels, den sie lesen. Vorschau und Änderungenvergleich sind während der Bearbeitung zulässig.

Stakeholder

...

Postconditions

Minimale Garantien:

Erfolgsgarantien:

• Der Artikel wird gespeichert und eine aktualisierte Ansicht angezeigt.
• Ein Bearbeitungsdatensatz für den Artikel wird vom System erstellt, sodass Beobachter des Artikels später über das Update informiert werden können.

Voraussetzungen:

Der Artikel mit aktivierter Bearbeitung wird dem Mitglied präsentiert.

Löst aus:

Das Mitglied ruft eine Bearbeitungsanforderung (für den vollständigen Artikel oder nur einen Abschnitt) im Artikel auf.

Grundfluss:

1. Das System bietet einen neuen Editor -Bereich/-box mit allen relevanten Inhalten des Artikels mit einer informativen Bearbeitungszusammenfassung für das Mitglied zum Bearbeiten. Wenn das Mitglied nur einen Abschnitt des Artikels bearbeiten möchte, wird nur der ursprüngliche Inhalt des Abschnitts angezeigt, wobei der Abschnittstitel automatisch in der Zusammenfassung bearbeiten wird.
2. Das Mitglied ändert den Inhalt des Artikels, bis das Mitglied erfüllt ist.
3. Das Mitglied füllt die Bearbeitungszusammenfassung aus, teilt dem System mit, ob es sich diesen Artikel ansehen möchte, und legt die Bearbeitung vor.
4. Das System speichert den Artikel, protokolliert das Bearbeitungsereignis und beendet die erforderliche Nachbearbeitung.
5. Das System präsentiert die aktualisierte Ansicht des Artikels an das Mitglied.

Erweiterungen:

2–3.

a. Vorschau zeigen:

1. Das Mitglied wählt Vorschau zeigen was den geänderten Inhalt unterbrochen.
2. Das System leistet Schritt 1 mit Hinzufügen des gerenderten aktualisierten Inhalts für die Vorschau wieder und informiert das Mitglied darüber, dass seine Änderungen noch nicht gespeichert wurden, und setzt sich dann fort.

b. Änderungen zeigen:

1. Das Mitglied wählt Änderungen zeigen was den geänderten Inhalt unterbrochen.
2. Das System leistet Schritt 1 erneut aus, wobei die Ergebnisse des Vergleichs der Unterschiede zwischen den aktuellen Änderungen des Mitglieds und der neuesten gespeicherten Version des Artikels angezeigt werden, und wird dann fortgesetzt.

c. Die Bearbeitung abbrechen:

1. Das Mitglied wählt Absagen.
2. Das System verwirft jede Änderung, die das Mitglied vorgenommen hat, und geht dann zu Schritt 5.

4a. Auszeit:

...

Vorteile

Seit Beginn der agilen Bewegung die Benutzer Geschichte Technik von Extremes Programmieren war so beliebt, dass viele der Meinung sind, dass es die einzige und beste Lösung für agile Anforderungen aller Projekte ist. Alistair Cockburn listet fünf Gründe auf, warum er noch Anwendungsfälle schreibt agile Entwicklung.^[33]

1. Die Liste der Zielnamen enthält die kürzeste Zusammenfassung dessen, was das System bietet (auch als Benutzergeschichten). Es bietet auch ein Projektplanungsskelett, das zum Aufbau von anfänglichen Prioritäten, Schätzungen, der Teamzuweisung und dem Zeitpunkt verwendet wird.
2. Das Haupt -Erfolgsszenario jedes Anwendungsfalls bietet allen Beteiligten eine Vereinbarung darüber, was das System im Grunde genommen tut und was es nicht tun wird. Es liefert den Kontext für jede bestimmte Werbemittelanforderung (z. B. feinkörnige Benutzergeschichten), einen Kontext, der sehr schwierig ist, irgendwo anders zu bekommen.
3. Die Verlängerungsbedingungen jedes Anwendungsfalls bieten einen Rahmen für die Untersuchung all der kleinen, nigmenden Dinge, die 80% der Entwicklungszeit und des Budgets in Anspruch nehmen. Es bietet einen Ausblicksmechanismus, sodass die Stakeholder Probleme erkennen können, die wahrscheinlich lange dauern werden, um Antworten zu erhalten. Diese Probleme können und sollten dann vor dem Zeitplan gestellt werden, damit die Antworten fertig sein können, wenn das Entwicklungsteam an ihnen arbeitet.
4. Das Anwendungsfall -Erweiterungsszenario -Fragmente liefert Antworten auf die vielen detaillierten, oft schwierigen und ignorierten Geschäftsfragen: "Was sollen wir in diesem Fall tun?" Es handelt sich um ein Denk-/Dokumentationsrahmen, das der IF ... dann ... sonst ... sonst den Programmierern hilft, Probleme zu überdenken. Außer dass es zu Ermittlungszeiten und nicht zur Programmierzeit geschehen ist.
5. Der vollständige Anwendungsfall zeigt, dass die Ermittler die Bedürfnisse jedes Benutzers, jedes Ziel in Bezug auf das System und jede Unternehmensvariante durchdacht haben.

Zusammenfassend hat die Angabe der Systemanforderungen in Anwendungsfällen diese offensichtlichen Vorteile im Vergleich zu herkömmlichen oder anderen Ansätzen:

Benutzer fokussiert

Anwendungsfälle sind ein leistungsstarkes, benutzerzentriertes Tool für den Prozess der Softwareanforderungen.^[34] Anwendungsfallmodellierung beginnt normalerweise mit der Identifizierung der wichtigsten Stakeholder -Rollen (Schauspieler) Interaktion mit dem System und ihren Zielen oder Zielen, die das System erfüllen muss (eine externe Perspektive). Diese Benutzerziele werden dann zu den idealen Kandidaten für die Namen oder Titel der Anwendungsfälle, die die gewünschten funktionalen Funktionen oder Dienste des Systems darstellen. Dieser benutzerzentrierte Ansatz stellt sicher, dass der eigentliche geschäftliche Wert und der Benutzer wirklich entwickelt wird, nicht die trivialen Funktionen, die aus einer Entwickler- oder System-Perspektive (innen) spekuliert sind.

Anwendungsfallautoring war ein wichtiges und wertvolles Analyse -Instrument im Bereich von Benutzerzentriertes Design (UCD) jahrelang.

Bessere Kommunikation

Anwendungsfälle werden häufig in natürlichen Sprachen mit strukturierten Vorlagen geschrieben. Diese narrative Textform (lesbare Anforderungen Geschichten), die von fast jedem verständlich ist, ergänzt durch visuelle UML-Diagramme eine bessere und tiefere Kommunikation zwischen allen Beteiligten, einschließlich Kunden, Endbenutzern, Entwicklern, Tester und Managern. Eine bessere Kommunikation führt zu Qualitätsanforderungen und damit zu Qualitätssystemen.

Qualitätsanforderungen durch strukturierte Exploration

Eines der leistungsstärksten Dinge an Anwendungsfällen liegt in den Formaten des Anwendungsfalls Vorlagen, insbesondere das wichtigste Erfolgsszenario (Basisfluss) und die Fragmente des Erweiterungsszenario (Erweiterungen, außergewöhnliche und/oder alternative Strömungen). Analyse eines Anwendungsfalls Schritt für Schritt von Voraussetzungen zu Post -Conditions, untersucht und untersucht jeden Aktionsschritt der Anwendungsfallflüsse, von Basic über Erweiterungen, um die schwierigen, normalerweise versteckten und ignorierten, scheinbar trivialen, aber realistisch oft kostspieligen Anforderungen zu identifizieren (wie der erwähnte Cockburn erwähnt oben) ist eine strukturierte und vorteilhafte Möglichkeit, um systematisch klare, stabile und Qualitätsanforderungen zu erhalten.

Minimierung und Optimierung der Aktionsschritte eines Anwendungsfalls, um das Benutzerziel zu erreichen Interaktionsdesign und Benutzererfahrung vom System.

Erleichterung von Tests und Benutzerdokumentation

Mit Inhalten, die auf einer Aktion oder Ereignisflussstruktur basieren Vorab. Es gibt offensichtliche Verbindungen zwischen den Durchflusspfaden eines Anwendungsfalls und seinen Testfällen. Das Abfertigung von Funktionstestfällen aus einem Anwendungsfall durch seine Szenarien (ausführende Instanzen eines Anwendungsfalls) ist unkompliziert.^[35]

Einschränkungen

Einschränkungen der Anwendungsfälle umfassen:

• Anwendungsfälle sind nicht gut geeignet, um nicht interaktionsbasierte Anforderungen eines Systems zu erfassen (z. B. Algorithmus oder mathematische Anforderungen) oder Nicht-funktionale Anforderungen (wie Plattform, Leistung, Timing oder sicherheitskritische Aspekte). Diese sind besser an anderer Stelle deklarativ angegeben.
• Da es keine vollständig Standard -Definitionen von Anwendungsfällen gibt, muss jedes Projekt eine eigene Interpretation bilden.
• Einige Anwendungsfallbeziehungen, wie z. erweitert, sind mehrdeutig in der Interpretation und können für die Stakeholder schwierig sein, wie Cockburn festgestellt zu verstehen (Problem Nr. 6)^[36]
• Anwendungsfallentwickler finden es häufig schwierig, das Niveau von zu bestimmen Benutzeroberfläche (UI) Abhängigkeit, die in einen Anwendungsfall einbezogen werden soll. Während die Anwendungsfalltheorie darauf hindeutet, dass UI in Anwendungsfällen nicht reflektiert werden kann, kann es unangenehm sein, diesen Aspekt des Designs abzuwehren, da die Anwendungsfälle schwierig zu visualisieren erschwert. In der Software -Engineering wird diese Schwierigkeit durch Bewerbung behoben Rückverfolgbarkeit der Anforderungenzum Beispiel mit a Rückverfolgbarkeitsmatrix. Ein anderer Ansatz zur Zusammenarbeit mit UI -Elementen mit Anwendungsfällen besteht darin, jedem Schritt im Anwendungsfall ein UI -Design anzubringen. Dies nennt man ein Anwendungs ​​-Case -Storyboard.
• Anwendungsfälle können überbetont werden. Bertrand Meyer Erörtert Probleme wie das Fahren des Systems zu wörtlich aus Anwendungsfällen und Verwendung von Anwendungsfällen unter Ausschluss anderer potenziell wertvoller Anforderungenanalyse -Techniken.^[37]
• Anwendungsfälle sind ein Ausgangspunkt für das Testdesign.^[38] Da jeder Test seine eigenen Erfolgskriterien benötigt, müssen möglicherweise Anwendungsfälle geändert werden, um separate Postkonditionen für jeden Pfad bereitzustellen.^[39]
• Gebrauchsfälle umfassen zwar Ziele und Kontexte, ob diese Ziele und Motivationen hinter den Zielen (Anliegen der Stakeholder und deren Bewertungen einschließlich Nicht-Interaktion) Konflikt BMM, ICH*, Kaos und Archimate RÜSTUNG).

Missverständnisse

Häufige Missverständnisse über Anwendungsfälle sind:

Benutzergeschichten sind agil; Anwendungsfälle sind nicht.

Agil und Gedränge sind neutral bei den Anforderungstechniken. Als Scrum Primer^[40] Zustände,

Produkt -Rückstandsgegenstände werden in jeder Hinsicht klar und nachhaltig artikuliert. Im Gegensatz zu beliebten Missverständnissen enthält das Produkt -Rückstand nicht "Benutzergeschichten". Es enthält einfach Elemente. Diese Elemente können als Benutzergeschichten, Anwendungsfälle oder anderer Anforderungen für die Gruppe ausgedrückt werden, die die Gruppe nützlich empfindet. Unabhängig vom Ansatz sollten sich die meisten Elemente darauf konzentrieren, den Kunden einen Mehrwert zu bieten.

Anwendungsfall -Techniken haben sich entwickelt, um agile Ansätze zu berücksichtigen, indem Anwendungsscheiben verwendet werden, um einen Anwendungsfall inkrementell anzureichern.^[13]

Anwendungsfälle sind hauptsächlich Diagramme.

Craig Larman betont, dass "Anwendungsfälle keine Diagramme sind, sie sind Text".^[41]

Anwendungsfälle haben zu viel UI-bezogene Inhalte.

Wie einige es ausdrückten,^[wer?]

Anwendungsfälle enthalten häufig eine Detailgenauigkeit (d. H. Die Benennung von Etiketten und Schaltflächen), wodurch es nicht gut geeignet ist, die Anforderungen für ein neues System von Grund auf zu erfassen.

Anfänger Missverständnisse. Jeder Schritt eines gut geschriebenen Anwendungsfalls sollte vorhanden sein Schauspieler Ziele oder Absichten (die Essenz der funktionalen Anforderungen), und normalerweise sollte es keine Benutzeroberflächendetails enthalten, z. Benennung von Etiketten und Tasten, UI -Operationen usw., was a ist Schlecht Praxis und wird das Schreiben von Anwendungsfall unnötig erschweren und seine Implementierung einschränken.

Wie die Erfassung von Anforderungen für ein neues System von Grund auf neu erfassen, Anwendungsfalldiagramme Plus Anwendungsfalluntersuchungen werden oft als praktische und wertvolle Tools verwendet, zumindest so leicht wie Benutzergeschichten.

Das Schreiben von Anwendungsfällen für große Systeme ist mühsam und Zeitverschwendung.

Wie einige es ausdrückten,^[wer?]

Das Format des Anwendungsfalles macht es schwierig, ein großes System (z. B. CRM -System) auf weniger als mehreren hundert Seiten zu beschreiben. Es ist zeitaufwändig und Sie werden Zeit damit verbringen, eine unnötige Menge an Nacharbeiten zu erledigen.

Viel Zeit mit mühsamen Anwendungsfällen verbringen, die keinen oder wenig Wert verleihen und zu viel Nacharbeiten führen, ist a schlechter Geruch Dies zeigt an, dass die Autoren nicht gut geschickt sind und wenig Kenntnis haben, wie sie sowohl effizient als auch effektiv Qualitätsnutzungsfälle schreiben. Anwendungsfälle sollten in einem iterativen, inkrementellen und evolutionären (evolutionären () verfasst werden (agil) Weg. Anwenden von Anwendungsfallvorlagen bedeutet nicht, dass alle Felder einer Anwendungsfallvorlage verwendet und umfassend von oben oder während einer speziellen dedizierten Stufe ausgefüllt werden sollten, d. H. Die Anforderungsphase in der traditionellen Wasserfall Entwicklungsmodell.

In der Tat die Anwendungsfallformate von formuliert von Diese beliebten Vorlagenstile, z.B. Die Rups und die Cockburns (ebenfalls übernommen von Die OUM -Methode) usw. wurden in der Praxis als wertvolle und hilfreiche Instrumente zur Erfassung, Analyse und Dokumentation komplexer Anforderungen großer Systeme erwiesen. Die Qualität einer guten Anwendungsfalldokumentation (Dokumentation (Modell) sollte nicht weitgehend oder nur nach seiner Größe beurteilt werden. Es ist auch möglich, dass sich ein qualitativ hochwertiges und umfassendes Anwendungsfallmodell eines großen Systems endgültig zu Hunderten von Seiten entwickeln kann, hauptsächlich aufgrund der inhärenten Komplexität des Problem in der Hand, nicht wegen der schlechten Schreibfähigkeiten seiner Autoren.

Werkzeug

Textredakteure und/oder Textverarbeitungen Mit Vorlagenunterstützung werden häufig verwendet, um Anwendungsfälle zu schreiben. Für große und komplexe Systemanforderungen sind dedizierte Anwendungs ​​-Fall -Tools hilfreich.

Einige der bekannten Anwendungsfall-Tools umfassen:

• CASECOMPLETETE
• Enterprise Architect
• Magicdraw
• Rationale Software's RequisitePro - eines der frühen, bekannten Anwendungs- und Anforderungsmanagement -Tools in den 1990er Jahren.
• Software -Ideen Modeler
• Wiki -Software - Gute Tools für Teams, mit denen Anwendungsfälle zusammenarbeiten und verwalten können.

Die meisten UML -Werkzeuge Unterstützen Sie sowohl das Textschreiben als auch die visuelle Modellierung von Anwendungsfällen.

Siehe auch

• Missbrauchsfall
• Business Case
• Entitätskontroll- und Gradstunde
• Ereignispartitionierung
• Feature
• Liste der UML -Tools
• Missbrauchsfall
• Erfordernis
• Anforderungen Auslösen
• Szenario
• Storyboard
• Testfall
• Anwendungsfallpunkte

Verweise

Weitere Lektüre

• Alexander, Ian und Beus-Dukic, Ljerka. Anforderungen entdecken: So spezifizieren Sie Produkte und Dienstleistungen. Wiley, 2009.
• Alexander, Ian und Maiden, Neil. Szenarien, Geschichten, Anwendungsfälle. Wiley 2004.
• Rüstung, Frank und Granville Miller. Erweiterte Anwendungsfallmodellierung: Softwaresysteme. Addison-Wesley, 2000.
• Kurt Bittner, Ian Spence, Anwendungsfallmodellierung, Addison-Wesley Professional, 20. August 2002.
• Cockburn, Alistair. Schreiben effektiver Anwendungsfälle. Addison-Wesley, 2001.
• Larry Constantine, Lucy Lockwood, Software zur Verwendung: Ein praktischer Leitfaden für die wesentlichen Modelle und Methoden des nutzungszentrierten Designs, Addison-Wesley, 1999.
• Denney, Richard. Erfolgsfälle mit Anwendungsfällen: intelligent arbeiten, um Qualität zu liefern. Addison-Wesley, 2005.
• Fowler, Martin. Uml destilliert (dritte Ausgabe). Addison-Wesley, 2004.
• Jacobson Ivar, Chrierson M., Jonsson P., Övergaard G.,, Objektorientiertes Software -Engineering - Ein Anwendungsfall -Ansatz, Addison-Wesley, 1992.
• Jacobson Ivar, Spence I., Bittner K. Anwendungsfall 2.0: Die Anleitung zum Erfolg mit Anwendungsfällen, Iji SA, 2011.
• Dean Leffingwell, Don Wirig, Verwaltung der Softwareanforderungen: Ein Anwendungsfallansatz, Addison-Wesley Professional. 7. Dezember 2012.
• Kulak, Daryl und Eamonn Guiney. Anwendungsfälle: Anforderungen im Kontext. Addison-Wesley, 2012.
• Meyer, Bertrand. Objektorientierte Softwarekonstruktion. (2. Auflage). Prentice Hall, 2000.
• Schneider, Geri und Winters, Jason P. Anwenden von Anwendungsfällen 2. Auflage: Ein praktischer Leitfaden. Addison-Wesley, 2001.
• WAZLAWICK, RAUL S. Objektorientierte Analyse und Design für Informationssysteme: Modellierung mit UML, OCL und IFML. Morgan Kaufmann, 2014.

Externe Links

• Anwendungsfallspalte und Grundlegende Anwendungsfallvorlage durch Alistair Cockburn
• Anwendungsfälle bei GSAUsability.gov
• Anwendung von Anwendungsfällen für die Stakeholder -Analyse "Projekt Icarus" bei Academia.edu
• Suche nach "Anwendungsfall" bei IBM -Entwickler