Use Case

UseCase ist ein Begriff der Objektorientierten Analyse, der mit Anwendungsfall nur sehr unzureichend übersetzt ist. IvarJacobson? definiert einen UseCase als ein Szenario, das damit beginnt, dass ein Anweder eines Systems eine Transaktion oder eine Folge von zusammenhängenden Ereignissen auslöst.

Der Nutzen einer Analyse, die auf solchen Szenarien beruht, liegt zuerst einmal darin, dass durch die Szenarien ein Gerüst vorgegeben ist. Es ist möglich, sich schon bei der Anforderungsanalyse an solchen Anwendungsfällen entlangzuhangeln. Damit ist bei einem Gespräch zwischen Benutzern, Fachleuten aus dem Anwendungsbereich und Entwicklern ein Rahmen für das gesteckt, um was es bei diesem Gespräch gehen soll.

Eine Methode zum Auffinden von solchen Szenarien bietet die hierarchische Aufgabengliederung (REFA). Dabei wird der Zweck eines Systems in einem einfachen Satz (mit 'einem' Verb) formuliert. Die so formulierte Aufgabe des Systems wird dann schrittweise in Teilaufgaben zerlegt. Immer dann, wenn solchen Teilaufgaben in einer bestimmten Reihenfolge ablaufen müssen, ist deren Vorgänger-Knoten im Aufgabenbaum ein erster Kandidat für ein Szenario (und die Verfeinerung in Teilaufgaben ist vermutlich nicht sachlich gerechtfertigt).

Jeder UseCase hat einen oder mehrere Abläufe, die die Grundlage für die Beschreibung der Arbeitsweise eines Softwaresystems bilden.

Bei der objektorientierten Analyse werden die Szenarien oder UseCases oft nicht nur aufgezählt. Auch Vererbungsbeziehungen und Komposition zwischen UseCases werden betrachtet.

Weil ein UseCase in der objektorientierten Analyse ein Szenario in Form einer Abfolge von Aktivitäten und einer Zusammenarbeit zwischen Benutzern und Objekten des Systems darstellt, findet sich ein Abbild der Vererbung von UseCases normalerweise nicht in der Vererbungshierarchie des entworfenen Systems.

Die Komposition von UseCases geschieht, indem andere UseCases entweder auf eine im zusammengesetzten UseCase vorgesehene Art und Weise oder durch nachträgliche Erweiterung von vorhandenen UseCases zusammengefügt werden. Zumindest der erste Fall kann im entworfenen System durch das StrategyPattern abgebildet werden.

Diskussion

MatthiasBohlen provoziert mal ein wenig: (Kommentare willkommen)

• UseCaseDiagramme? ("Männchen und Eier") sind weniger nützlich als die einzelnen Use-Case-Beschreibungen. Sie dienen nur dem Überblick und sind erst ab einer gewissen Anzahl Use Cases wirklich lohnend. Außerdem haben manche Kunden etwas gegen diese Diagramme, weil sie sie erstens nicht sofort verstehen und zweitens die Männchen einen etwas lächerlichen Eindruck machen.
• <<include>> zwischen zwei Use Cases ist sinnvoll, versteht man eigentlich sofort.
• <<extend>> zwischen zwei Use Cases begreifen Leute erst auf den zweiten Blick. Oder hättest Du (lieber Leser) auf Anhieb gedacht, dass folgendes gilt: "Ungültige Kreditkarte verarbeiten" <<extend>> "Ware bezahlen" ? Mit Pfeilrichtung von U.K.v. nach W.b. ? Ich habe damals eine ganze Weile dazu gebraucht und mich anschließend gefragt, wem <<extend>> wirklich etwas bringt. Daher verwende ich <<extend>> nur extrem sparsam.
• Vererbung von Use Cases ist höchst zweifelhaft. Was bedeutet es denn, wenn man sagt: "Use Case B ist ein spezieller Use Case A"? Gestatten - wie bitte? Mir sagt das nichts, jedenfalls nicht so viel wie bei Vererbung zwischen zwei Klassen.
• Zitat von weiter oben: Komposition von UseCases ... kann im entworfenen System durch das StrategyPattern abgebildet werden. Nö, eben nicht! Ich finde, das StrategyPattern ist so feinkörnig, dass es mit Use Cases nichts zu tun hat. Eine Strategy ist etwas, das sich auf Ebene von einzelnen Methoden in Objekten abspielt. Die Ebene eines Use Cases dagegen liegt so weit oben, dass dazwischen noch Kilometer von Designtransformationen liegen.

Zudem geht es bei UseCases um das Problem, während das Design die Lösung für das Problem abbildet. Eine allgemein gültige mechanische Transformation vom einen zum anderen gibt es nicht.

Im InformatikStudium an der TU Wien gibt es eine sehr interessante zwei-semestrige Veranstaltung zu SoftwareEngineering?, in der unter anderem UseCaseDiagramme? gebracht werden. In den Gruppen wo ich war (insgesamt ca. 10 Leute) hat keiner <<extends>> kapiert oder beschreiben (inklusive den Tutoren). Außerdem wird das Diagramm ab 10 "Eiern" Sowieso so unübersichtlich, daß eine tabellarische Darstellung mit primären und sekundären Vorgangen wahrscheinlich geeigneter wäre. --DavidSchmitt

Die grafische Darstellung im Diagramm ist wirklich recht zweifelhaft. Lediglich die Navigation in Tools wird dadurch vereinfacht. Vererbungsbeziehungen verwende ich bei einem Use|Case auch nicht, aber bei Akteuren. Insbesondere wenn es darum geht Rollen zu modellieren. -- BerndEckenfels

Zur Vererbung: ich finde schon, dass der UseCase "Einkaufen beim Gemüsehändler" ein spezieller UseCase "Einkaufen beim Einzelhändler" ist. -- PitHauge

Ressourcen

• http://www.usecases.org/
• AnforderungsGeschichte
• "Use Cases"-Kapitel aus "UML for Java Programmers", RobertCMartin
• http://www.foruse.com/articles/structurestyle2.htm -- In diesem Artikel von Larry Constantine geht es um eine besonders konzentrierte Art und Weise, Use Cases zu schreiben ("essential use cases"). Gefällt mir sehr gut, der Schreibstil dabei nennt sich "suitably vague", also "angemessen vage". Ich benutze ihn gerne zusammen mit meinen Kunden - er ist nur ganz wenig komplexer als eine AnforderungsGeschichte aber nicht so formalistisch wie ein "Original-Ivar-Use Case". -- MatthiasBohlen