Anwendungsfall
aus Wikipedia, der freien Enzyklopädie
SMS verschicken und Fotomessage verschicken eines Mobilfunkbetreibers sind spezifiziert.Ein Anwendungsfall, auch im Deutschen eher unter dem englischen Ausdruck Use Case bekannt, definiert die Interaktionen zwischen Akteuren und dem betrachteten System, die stattfinden, um ein bestimmtes fachliches Ziel (engl. business goal) zu erreichen. Anwendungsfälle beschreiben immer nur genau einen Ablauf oder einen Prozess.
Anwendungsfall und Geschäftsprozess werden oft verwechselt. Der Bezug zur Systemtheorie zeigt jedoch, dass Use Cases und (Geschäfts-)Prozesse jeweils eine andere Sicht auf das zu modellierende System beschreiben: Use Cases beschäftigen sich mit der Frage, was die Umwelt vom System erwartet, (Geschäfts-)Prozesse zeigen, wie das System intern operiert, um die Anforderungen der Umwelt zu erfüllen. Diese Abgrenzung gilt unabhängig von der Art des zu modellierenden Systems insbesondere für Unternehmen und Software gleichermaßen.
"Ein Use Case beschreibt eine abgeschlossene, ununterbrochene Abfolge von Aktionen eines Akteurs am System mit Ergebnis von fachlichem Wert"
Die Granularität kann verschieden sein. Auf sehr hohem Niveau beschreibt ein Anwendungsfall lediglich sehr grob und abstrakt, was passiert. Die Technik des Anwendungsfall-Schreibens kann jedoch bis auf Ebene von IT-Prozessen verfeinert werden, sodass das Verhalten einer Anwendung detailliert beschrieben wird. Dies widerspricht der ursprünglichen Intention von Use Cases, ist aber manchmal zweckmäßig.
Anwendungsfälle wurden bereits vor Etablierung der UML eingesetzt. Zusammenhängende Anwendungsfälle können in einem Anwendungsfalldiagramm dargestellt werden.
[Bearbeiten] Aufbau eines Anwendungsfalls
Der Aufbau eines Anwendungsfalls kann nach A.Cockburn etwa so aussehen:
- Name und Identifier
- Anwendungsfälle haben einen Namen und werden nach Sachgruppen geordnet durchnummeriert, z.B. UC 2.01.
- Beschreibung (description)
- Hier erfolgt eine kurze Beschreibung, was im Anwendungsfall passiert. Kurz bedeutet, dass es zwei oder drei Zeilen sind, selten mehr.
- Beteiligte Akteure (actors)
- Akteure sind beteiligte Personen oder Systeme. Z.B. Anwender, eingeloggter Anwender, Kunde, System, Abrechnungsprozess. Die Akteure werden zuvor in einem eigenen Abschnitt dargestellt.
- Status
- Der Status sagt aus, wie weit die Arbeit an dem Anwendungsfall gediehen ist. In Arbeit, bereit zum Review, im Review, abgelehnt und abgenommen sind die üblichen Stati.
- Verwendete Anwendungsfälle (includes)
- Wenn der Anwendungsfall auf andere Anwendungsfälle zurückgreift, werden diese Fälle hier aufgezählt. Aufzuzählen sind Name und Identifikationsnummer. Ggf. ist es eine gute Idee, den Verweis interaktiv zu gestalten, d.h. einen Link (bzw. interaktiven Querverweis) einzufügen.
- Auslöser (rationale)
- Der Grund bzw. die Gründe dafür, dass dieser Anwendungsfall ausgeführt wird.
- Vorbedingungen (preconditions)
- Alle Bedingungen, die erfüllt sein müssen, damit dieser Anwendungsfall ausgeführt werden kann. Gibt es keine Vorbedingungen, so steht hier "keine".
- Nachbedingung / Ergebnis (postconditions)
- Das Ergebnis, das nach einem erfolgreichen Durchlauf des Anwendungsfalls erwartet wird.
- Ablaufschritte (normal flow)
- Hier wird der eigentliche normale Ablauf dargestellt. Mit normal ist der Geradeausflug gemeint, also der Idealfall bzw. häufigster regulärer Ablauf. Die Ablaufschritte werden nummeriert und meist in strukturiertem Deutsch bzw. Englisch beschrieben. Ablaufpläne können jedoch ebenfalls benutzt werden, wenn es angebracht erscheint. Mittels der UML können diese Ablaufschritte in Aktivitätsdiagrammen oder Anwendungsfall-orientierten Sequenzdiagrammen dargestellt werden.
- Alternative Ablaufschritte (alternative flow)
- Dies sind Abläufe außerhalb des Geradeausflugs. Sie stellen Abweichungen oder Verzweigungen der normalen Ablaufschritte dar.
- Ausnahmen (exceptions)
- Dies sind die harten Ausnahmen, die allerdings noch immer auf fachlicher Ebene formuliert werden. Z.B. wird an Stelle von "Datenbank nicht verfügbar" zu schreiben eher "Kundenobjekt nicht verfügbar" geschrieben.
- Erweiterungspunkte (extensions)
- Diese ermöglichen die Formulierung von Erweiterungen der Funktionalität eines Anwendungsfalles unter bestimmten Bedingungen. Beim Eintreten der jeweiligen Bedingung wird dann die Funktionalität eines weiteren Anwendungfalles in Anspruch genommen (der natürlich ebenfalls modelliert sein muss).
- Hinweise
- kurze Erklärungen zum besseren Verständnis, Hinweise zu Nebeneffekten, Mengengerüsten soweit erforderlich und alles andere, das nicht weiter oben dargestellt werden kann.
- Änderungsgeschichte (use case history)
- Versionierung, Name des Autors, Datum
[Bearbeiten] Methodische Hinweise
Ein Anwendungsfall beschreibt die Serie von Interaktionen zwischen Nutzer und System, die notwendig sind, ein fachliches Ziel des Nutzers zu verwirklichen. Dabei dürfen die beschriebenen Abläufe nicht zu komplex werden. Als Anhaltspunkt kann der von Cockburn beschriebene Kaffeepausen-Test dienen: Solange der Anwendungsfall nicht zu komplex ist, wird die Frage „Würde der Nutzer während der Interaktionen eine Kaffeepause einlegen?“ mit "Nein" beantwortet.
[Bearbeiten] Literatur
- Alistair Cockburn: Use Cases effektiv erstellen. MITP Verlag, 2003 ISBN 3-8266-1344-9
- Daryl Kulak, Eamonn Guiney: Use cases: requirements in context. 2. Auflage. ACM Press, New York 2004, ISBN 0-201-65767-8
- Kurt Bittner, Ian Spence: Use Case Modeling. Addison-Wesley Pearson Education, Boston 2003, ISBN 0-201-70913-9
- Hartmut Umbach, Pierre Metz: Use Cases vs. Geschäftsprozesse Informatik-Spektrum, Springer Berlin/Heidelberg, ISSN 0170-6012 (Print) 1432-122X (Online)
