30 Jahre Anwendungsfälle

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

Die Geschichte der Anwendungsfälle ist eine Geschichte voller Missverständnisse. Dabei hat die Geschichte schon so einen langen Bart: Auf der OOPSLA 1987 (Object-Oriented Programming, Systems, Languages, and Applications) in Orlando, Florida hat Ivar Jacobson seinen bahnbrechenden Vortrag zu "Object Oriented Development in an Industrial Environment" gehalten. Wie er mir selbst bestätigte, hat er darin erstmals Anwendungfälle öffentlich vorgestellt (natürlich hat er sie vorher schon lange in eigenen Projekten verwendet). Auch heute noch wird das Paper gelesen, in den letzten sechs Wochen wurde es immerhin sechs mal heruntergeladen. Dieses Diagramm stammt aus diesem Paper und ist damit das wohl älteste veröffentlichte Anwendungsfalldiagramm.

Trotz dieser langen Erfahrung werden leider immer noch Fortsetzungen von "The Case of the Useless Use Cases" geschrieben. Dabei hat sogar Klein-Fritzchen schon das Wesentliche erkannt, als er sich o.b.-Tampons zum Geburtstag wünschte: Es geht nicht um ihre Funktion, sondern darum, was man damit machen kann, nämlich, wie in alten Werbespots angepriesen, Reiten, Schwimmen und Tennis spielen - OK, vielleicht sollte man Klein-Fritzchen mal die Basis-Architektur erklären.

Die Definition in diesem Paper lautet übrigens:

Ein Anwendungsfall ist eine spezielle Abfolge von Transaktionen, durchgeführt durch einen Benutzer und ein System im Dialog.

Vielleicht ist das der Geburtsfehler der Anwendungsfälle: Es fehlt die Forderung, dass das Ergebnis von fachlichem Wert sein muss. Das gilt auch noch für Ivar Jacobsons Buch "Object Oriented Software Engineering" (die Ähnlichkeit zu unserem Firmennamen ist kein Zufall). Erst Alistair Cockburn hat das in seinem ebenso empfehlenswerten Buch "Writing effective Use Cases" klar gestellt:

Ein Anwendungsfall beschreibt das Verhalten und die Interaktionen eines Systems [...] während es auf eine Anforderung im Namen eines der Stakehoder reagiert [... und] zeigt wie das Ziel des Akteurs erreicht oder verfehlt wird.

Dennoch finde ich in der freien Wildbahn immer noch "Anwendungsfälle" wie "Log in", "Waschmaschinentür öffnen" oder "Sitzhöhe einstellen". Ja, damit lässt sich ein aktuelles Bedürfnis des Benutzers befriedigen. Aber deswegen hat er nicht die Waschmaschine oder den Autositz gekauft. Das Problem damit ist, dass das simple Verpacken von Funktionen in Anwendungsfälle ("Funktion benutzen") den Aufwand nicht wert ist. Auch deswegen sind Anwendungsfälle als unagil in Veruf geraten. Erst seit der UML 2.5 heißt es unmissverständlich:

Ein Anwendungsfall spezifiziert eine Menge von Aktionen ausgeführt durch seine Subjekte, die in einem beobachtbaren Ergebnis resultiert, das von Wert für einen oder mehrere Akteure oder andere Stakeholder jedes Subjekts ist.

Letzlich geht es darum, Funktionen zu finden und ihnen einen Kontext zu geben. Das ist in jedem, auch im agilen Fall sinnvoll, was Alistair Cockburn in "Why I still use use cases" begründet. Dass Anwendungsfälle sich gut mit agilem Projektmanagement verbinden lassen, hat Ivar Jacobson mit Use Case 2.0 gezeigt.

Eine andere Baustelle ist die Einbindung von Anwendungsfälle in die UML. Irgendwie fühlen sie sich nach wie vor wie Fremdkörper an, mit wenig Verbindungen zu anderen Modellelementen. Sind Anwendungsfälle wirklich Strukturen mit Verhalten (BehavioredClassifier), wie in der UML, oder doch eigentlich nur Verhalten (Behavior)? Wie genau beschreibt man sie? Was genau sind Erweiterungspunkte. Offenbar war das im Sinne Ivar Jacobsons, da für ihn das Erzählen einer Geschichte im Vordergrund steht - was ich richtig finde - und nicht die formale Beschreibung - was aber dennoch möglich sein sollte. Jedenfalls hat er mit seiner ganzen Autorität interveniert, als das UML 2 Team das ändern wollte. Wie mir Øystein Haugen, eines der Mitglieder, beim gemeinsamen Verspeisen eines Kuckucks erzählte, sollten Anwendungsfälle "Behavior" werden und die Akteure "Properties" dieses Verhaltens (der Mechelner Kuckuck ist eine belgische Haushuhnrasse). Dadurch könnte man bei Bedarf Anwendungsfälle zu Sequenzdiagrammen weiter entwickeln und die Akteure als Lebenslinien in ihnen auftreten. Ich kann dem einiges abgewinnen und wundere mich, dass Ivar Jacobson dagegen war. Schließlich ist seine "Abfolge von Transaktionen" ein Verhalten und keine Struktur. Mal sehen wie das SysML 2.0 Einreichungsteam, das sich eben gegründet hat, Anwendungsfälle definieren wird.

Mein Fazit nach 30 Jahren: Anwendungsfälle wurden nicht erfunden, sondern gefunden. Es gab sie immer und wird sie immer geben.

Use Cases forever!

P.S. Einigen Leser wird die konsequente Verwendung des deutschen Worts "Anwendungsfall" verwundern. Tatsächlich habe ich von bekannten Konferenzsprechern die Aussage gehört, dass "Use Case" doch ein feststehender und wohldefinierter Begriff ist, der mit "Anwendungsfall" nur unzureichend übersetzt wird. Nun, "wohldefiniert" wage ich zu bezweifeln - allein in diesem Artikel zitiere ich drei Definitionen. Ich gebe zudem zu bedenken, dass Ivar Jacobson selbst sie früher "Användningsfall" nannte - er ist Schwede.

Literatur

Ivar Jacobson (1987): Object-oriented development in an industrial environment. In Conference proceedings on Object-oriented programming systems, languages and applications (OOPSLA '87), Norman Meyrowitz (Ed.). ACM, New York, NY, USA, 183-191. DOI=http://dx.doi.org/10.1145/38765.38824

Ivar Jacobson (1992): Object-oriented software engineering. a use case driven approach. Reno (ACM Press).

Alistair Cockburn (2000): Writing Effective Use Cases. Boston: Addison-Wesley Professional.

Ivar Jacobson, Ian Spence, Kurt Bittner (2011): Use Case 2.0, eBook,  https://www.ivarjacobson.com/publications/white-papers/use-case-ebook

Umfassende Erklärung von Use Case 2.0 im Rahmen der Essence Practice Library: https://practicelibrary.ivarjacobson.com/content/use-case-20-essentials-publication (Anmeldung erforderlich)