"Es ist nicht genug zu wissen; man muss es auch anwenden.
Es ist nicht genug zu wollen, man muss es auch tun."
(Johann Wolfgang von Goethe)

Anwendungsfälle

Ivar Jacobson (heute IBM Rational [L7]) entwickelte das Konzept des Anwendungsfalls (Abk.: AF, engl.: Use Case [L12], Abk.: UC) seit 1967 und benutzte diese Bezeichnung erstmalig 1986. Über mehrere Jahre wurde das Konzept weiter entwickelt und fand dann Mitte der 90er rasante Verbreitung. Die Kernidee besteht in der Beschreibung eines "Stücks" der Software in einem sehr frühen Stadium des Projekts - möglichst noch vor den Prototypen, auf jeden Fall aber vor der Programmierung des Codes.

Definition "Anwendungsfall"   Der Ausdruck einer Vereinbarung zwischen Interessenten des Softwaresystems über das Verhalten des Systems unter bestimmten Bedingungen, insbesondere als Abfolge von Aktionen des Systems, die einem Akteur ein untersuchbares und bedeutendes Ergebnis liefert.

Damit zeigt ein Anwendungsfall auf, "wie" ein Ziel eines Akteurs erreicht wird oder fehlschlägt. Daraus wird auch ersichtlich, dass es etwas Erfahrung benötigt, Anwendungsfälle zu identifizieren und abzugrenzen. Und so lange man vor einem weißen Blatt Papier sitzt, ist es immer schwierig! Wenn man erst mal einige Anwendungsfälle stichwortartig oder sogar nur mit Überschriften vor sich liegen hat, dann ergeben sich auch schnell die weiteren Schritte.

Um es gleich zu sagen: die Anzahl der Anwendungsfälle hängt von sehr vielen Kriterien ab und muss sich ergeben. Es macht keinen Sinn, die Granularität danach auszurichten, wie viele Anwendungsfälle "man haben sollte". In der Regel haben auch wirklich große Projekte nicht mehr als 150 Anwendungsfälle; mein letztes Projekt von etwas mehr als drei Personenjahren Umfang hatte letztendlich 30 Anwendungsfälle, die implementiert wurden. Dies zeigt zumindest, dass sicherlich nicht jeder Button des Programms ein eigener Anwendungsfall ist. Andererseits sollte ein Anwendungsfall eine überschaubare Menge an Funktionalität widerspiegeln: Wenn Sie ein Dutzend verschiedene Anwenderrollen und sogar mehrere Applikationsschnittstellen in einem einzelnen Anwendungsfall wiederfinden, sind Sie wahrscheinlich zu grob unterwegs.

Ein Anwendungsfall hat in der Regel einen angenehmen Umfang, wenn sich die Abfolge seiner Aktionen gut in Prosa als Szenario beschreiben lässt. Damit sind auch bereits zwei wichtige Aspekte der Anwendungsfälle genannt, denn die Sicht beinhaltet Szenarien, die die Software unterstützt, d.h. Fälle, für die die Software angewandt werden soll. Diese sollte man in Prosa in der Sprache des Kunden beschreiben, denn in der Regel wird die Anwendungsfallsammlung als Leistungsbeschreibung zur Anlage des Angebots bzw. Auftrags. Damit sollte auch schon klar sein, dass die Anwendungsfälle Leistungsmerkmale aus Anwendersicht beschreiben. Da ein Anwendungsfall mehrere Leistungsmerkmale abdecken kann, werden auch die Merkmalschnittstellen beschrieben.

Anwendungsfälle sollten schon beschreiben, "wie" die Fachlichkeit hier unterstützt wird, also "wie" die Software dem Anwender bei der Lösung seines Problems hilft, aber nicht, wie die technische Realisierung des Anwendungsfalls aussieht. Dafür sollten begleitend (oder besser in der nachfolgenden Entwurfsphase) technische Spezifikationen erstellt werden

Anwendungsfallhierarchie

Im Buch [B14] zitiert Alistair Cockburn [M1] sehr passend ein kleines Gedicht des Iren Jonathan Swift:

Wenn Sie Anwendungsfälle schreiben, werden Sie nämlich eine Hierarchie erkennen, in der Sie diese Anwendungsfälle anordnen können: Wenn ein Akteur beispielsweise regelmäßig Wirtschaftsplananmeldungen erfasst, ein anderer jährlich einen Wirtschaftsplan erstellt und eine Controlling-Abteilung dessen Einhaltung kontinuierlich überwacht, so macht es Sinn, für alle drei Anwendungsfälle einen übergeordneten Anwendungsfall (oder im Sinne der UML ein "Paket") einzurichten, der Gemeinsamkeiten und detailliertere Beziehungen der drei Anwendungsfälle beschreibt. Dadurch entsteht auch eine Beziehung zum Gesamtgeschäftsprozess, die zum Test verwendet werden kann und stets auch weitere Aspekte mit ins Spiel bringt. Es kann sich sogar ergeben, dass es weitere wirtschaftliche Prozesse gibt, die Sie mit der zu erstellenden Software unterstützen sollen, so dass es hier vielleicht sogar noch einen weiteren, übergeordneten Anwendungsfall "Kostenverwaltung" gibt. Es kann auch sein, dass Sie einen Anwendungsfall bei weiterer Betrachtung als unhandlich groß empfinden und in zwei kleinere zerlegen, wodurch sich die Hierarchie ändern kann.

Ich versuche immer, nicht mehr als drei echte Hierarchieebenen aufzubauen: An die Wurzel setze ich den Namen des zu erstellenden Softwaresystems, darunter folgen die Anwendungsfälle, die ich gerne "Übersichtsanwendungsfälle" (ÜAF) nenne, weil sie eine sehr grobe Paketierung darstellen. Dann folgen die Anwendungsfälle, die ich gerne "Funktionsanwendungsfälle" (FAF) nenne, weil sie größere funktionale Pakete darstellen. Und schließlich folgen die Anwendungsfälle, die ich dann gerne "Detailanwendungsfälle" (DAF) nenne, weil sie die eigentlichen Szenarien detailliert beschreiben. Bei kleinen Projekten reichen sicherlich auch zwei Stufen und bei riesig großen benötigt man sicherlich eher vier oder gar fünf, aber ich komme mit drei meistens ganz gut hin. Im Buch [B14] beschreibt Alistair Cockburn [M1] eine Hierarchie mit fünf Stufen.

Wenn Sie die Anwendungsfälle als UML-Anwendungsfalldiagramm zur Darstellung Ihres Anwendungsfallmodells zeichnen, sehen Sie sehr schön die Hierarchie. Nebenstehend ein Beispiel aus einem Projekt von mir. Links unten in dem Fenster können Sie erkennen, dass hier nur ein kleiner Ausschnitt des Modells dargestellt wird. Die Farben kennzeichnen Versionen und Iterationen. Mit dem Anwendungsfallmodell erhalten Sie auch eine erste grobe Struktur Ihrer Applikation, die in weiteren Phasen und Iterationen zur ersten konzeptionellen Sicht auf das Business-Klassenmodell (logisches Modell) führen kann - doch dazu später mehr. Die Granularität des Modells kann von System zu System und damit auch von Projekt zu Projekt natürlich recht unterschiedlich ausfallen.

Entstehung

Sie beginnen bei der Arbeit mit den Anwendungsfällen eigentlich schon in der Geschäftsprozessanalyse, weil Sie im Zweck- und Tragweiten-Diagramm innerhalb der Systemgrenzen bereits Übersichtsanwendungsfälle (bzw. AF-Pakete) einzeichnen. In aller Regel führt nämlich eine Hauptanforderung auch zu einem zentralen Anwendungsfall, so dass Sie also bereits erste Anwendungsfälle vorliegen haben, bevor Sie konkret damit anfangen - Sie müssen sie nur noch als solche hinschreiben. Ausgangspunkt sind also tatsächlich die zu unterstütztenden Geschäftsprozesse und die zu erfüllenden Anforderungen, die Sie während der frühen Phasen des Projekts gesammelt haben. Je besser diese Vorarbeit war, desto sicherer kommen Sie zu guten Anwendungsfällen!

Neulinge fragen immer sofort nach der Anzahl und der Größe der Anwendungsfälle und hoffen, durch formale Zerstückelung nach irgendeiner Regel zu den Anwendungsfällen kommen zu können. Ich habe diese Seite bewusst mit Aussagen zu der Anzahl und der Größe eingeleitet, um gleich aufzuzeigen, dass es diese Regel nicht gibt - Sie können da nicht nach Schema F vorgehen. Es muss klar werden, dass Sie in den ersten Vertriebsgesprächen, Vorgesprächen, Interviews, Präsentation, etc. immer über die Ziele und Anforderungen gesprochen haben und sich damit auf der Problemebene bewegt haben. Es geht ja zuerst darum, genau die Probleme zu verstehen, bei deren Lösung die zu erstellende Software helfen soll. Wenn das schon daneben geht, kann nichts auf der Welt mehr das Projekt retten.

Mit den Anwendungsfällen kommt endgültig der Wechsel in die Lösungsebene. Damit geht die Verantwortung des Projektverlaufs auch endgültig auf den Anbieter über, denn dieser muss jetzt Vorschläge zur Konstuktion liefern. Der Anbieter hat die Fachlichkeit und das Problem des Kunden jetzt genug verstanden, um Lösungen anbieten zu können, d.h. dem Kunden präsentieren zu können, "wie" die Software ihn bei der Lösung seiner Probleme unterstützen kann. Während die fachliche Fehlerfreiheit in der Kundenverantwortung liegt, sollte der Anbieter die Verantwortung für die Implementierbarkeit der vorgeschlagenen Lösungen an sich ziehen, denn genau ist sein Job! Zum Test ist es aber sehr wichtig, zunächst noch in Prosa zu formulieren und das System möglichst vollständig aus Anwendersicht beschreiben, denn diese Dokumentation bildet die Grundlage des Systems, das später dem Kunden geliefert wird. Anhand dieser Beschreibungen kann der Kunde also prüfen, ob ihn sein Lösungsanbieter auch wirklich richtig verstanden hat.

Greifen Sie möglichst auf die erstellten Diagramme der Teilprozesse des betrachteten Geschäftsmodellausschnitts zurück und identifizieren Sie Blöcke und Grenzen. Informationen entstehen oft zu einem dedizierten Zeitpunkt, werden für eine kurze Zeit genutzt und werden dann wieder "losgelassen". Danach werden ggf. andere Informationen betrachtet. Damit haben Sie wahrscheinlich schon einen Anwendungsfall erkannt und gegen einen nachfolgenden Anwendungsfall des Teilprozesses abgegrenzt. Gemäß dem Spruch oben auf der Seite "Problemzerlegung" kann also das Geschäftsmodell in Prozesse, Teilprozesse und schließlich Anwendungsfälle zerlegt werden.

In den letzten Jahren sind so nette Formulierungen wie "Business Process Choreography" oder "Use Case Orchestration" oder "Storyboard" aufgekommen, die alle auf Zerlegung mit anschließendem "Zusammenspiel" abzielen - ich hoffe, Sie verzeihen mir die Verwendung eines deutschen Begriffs! Letztendlich geht es darum, die erkannten Abläufe so in handliche Portionen zu zerlegen, dass sie danach wieder nahtlos zu den Abläufen zusammengesetzt werden können. Dabei gehen Sie als Anbieter typischerweise erheblich systematischer vor als der Kunde ursprünglich bei der Erstellung seines Fachkonzepts (sofern es sowas in dem Projekt überhaupt mal gegeben hat). Letztendlich werden beide Dokumente tatsächlich die gleiche inhaltliche Aussage enthalten - nur ist der Anwendungsfallkatalog erheblich implementierungssicherer als das Fachkonzept. Wer schon länger in der Softwareentwicklung unterwegs ist, kennt noch die Begriffe "Lastenheft" und "Pflichtenheft". Das Lastenheft (es beschreibt grob die Lasten, die die Software zu tragen hat) entspricht hier dem Fachkonzept und das Pflichtenheft (es beschreibt präzise die Pflichten, die die Software zu erfüllen hat) entspricht hier der Leistungsbeschreibung, deren wesentliche Bestandteile heutzutage die Anwendungsfallbeschreibungen und die Prototypen sind.

Vergleichen Sie dieses Vorgehen mit der Erstellung eines Zeichentrickfilms: Die Handlung wird zuerst in Prosa beschrieben. Dann werden einzelne Bilder zu den Schlüsselszenen gezeichnet. Als nächstes werden die Bilder für die Schnitte gezeichnet, mit denen eine neue Szene beginnt und zuletzt werden alle anderen Bilder der Szenen erstellt - und zwar von mehreren Zeichnern gleichzeitig (parallel). Wenn Sie dann die Szenen mit ihren Bildern zusammensetzen, ergibt sich der Film, der ursprünglich in Prosa beschrieben wurde (mehr dazu finden Sie beispielsweise im Movie-College der Firma "Allary Film"). So sollte der Anwender bei der Bedienung der fertigen Software in den Anwendungsfällen wie durch einen Assistenten von Fenster zu Fenster (oder im Inter-/Intra-/Extranet von Seite zu Seite) geführt werden und durch Ausführung mehrerer Anwendungsfälle nacheinander einen Teilprozess des Geschäfts unterstützen. Auf diese Art kann die Software den Anwender durch Geschäftsprozesse begleiten, gespeicherte Informationen zur Verfügung stellen und neue Informationen aufnehmen.

...

Spezial- & Sonderfälle festhalten
Abhängigkeiten festhalten
Kunde legt für Anwendungsfälle fest:
- Häufigkeit
- Priorität (hoch, mittel, niedrig)
Mit den Anwendungsfällen sollten sofort auch die Testfälle erstellt werden.
Basis für Aufwandsabschätzung
Elemente: Szenarien in Prosa, Ablaufdiagramm in UML, Beziehung zum Akteur, Abhängigkeiten zu anderen AF

Anwendungsfallbeschreibung (Download), iterativ inkrementelle Erstellung

Eine Vorlage

...	Ein Beispiel

Szenarien
casual, fully dressed, Sequenzdiagramm, Prototyp (s.u.)
Ich betone hier deutlich, dass ich aus meiner Erfahrung heraus NICHT mit Cockburn darin übereinstimme, dass es zwei Stile für die Beschreibung von Anwendungsfällen (nämlich casual und fully dressed) gibt und man sich im Projekt für einen der beiden Stile entscheiden wird (S. 9). Vielmehr habe ich festgestellt, dass es Sinn macht, für jede Anwendungsfallbeschreibung einzeln zu entscheiden, welche Form man wählt. Ich halte es manchmal für sehr sinnvoll, einen Anwendungsfall als Sequenzdiagramm oder als Screenshot aus dem Prototypen (s.u.) zu beschreiben. Das sagt manchmal viel mehr aus als jede fully dressed Beschreibung.
Rational-Template im RUP (Copyright)
CRUD

Zerlegung des AF in Seiten oder Dialogfenstern, allgemein "Flächen" zur Darstellung von Aspekten einer bestimmten Anwender-PC-Kommunikation. Diese Assistenten sorgen für gleichmäßige Fragmentierung der AF.

Akzeptanzkriterien für Anwendungsfälle [L9]
kann ein konkretes Beispiel sein
konkrete Ziele definieren
abnahmefähig (juristisch stabil)
s. auch "Systematische Tests"

Basis-Anwendungsfälle
Varianten-Anwendungsfälle
Geschäftsanwendungsfälle (Kunde, Ereignis)
Systemanwendungsfälle (Software)
Anwendungsfallfragmente zur Wiederverwendung von Fachlichkeiten
extends (erweitert), extension points
includes (enthält, auch uses)
Generalisierung

Ausblick: Eines Tages werden Anwendungsfälle direkt ausführbar sein. Der Analytiker von heute ist der Programmierer von morgen.

Fazit:
Schnittstelle von Fachlichkeit zu Technik
Basis für konzeptionelle Sicht auf das erste (logische) Klassendiagramm
Grundlage für Änderungsanforderungen
Inhaltsverzeichnis des Projekts

Aspektorientierte Programmierung (AOP)