Wie kann man Use Cases so schreiben, dass sie für den Kunden verständlich und gleichzeitig für Entwickler ausreichend informativ bleiben? Kann man Use Cases wieder verwenden? Kann man auf fremde Erfahrung zurückgreifen? Auf solche spannenden Fragen geben Gunnar Övergaard und Karin Palmkvist Antworten in ihrem neuen Buch "Use Cases: Patterns und Blueprints". Die Autoren haben sich mit mehr als 30 Jahren Erfahrung seit langem einen Namen im Bereich Use Cases gemacht.
Das Buch gliedert sich in fünf Teile mit insgesamt 44 Kapiteln. Da es für ein breites Spektrum von Lesern gedacht ist, haben sich die Autoren bemüht, für jede Leserkategorie einen eigenen Pfad durch die Kapitel vorzuschlagen. Der erste Teil erklärt kurz die wichtigsten Konzepte: Use Case Patterns und Use Case Blueprints und ihre Rolle in der Entwicklung von Use-Case-Modellen. Im zweiten Teil führen die Autoren den Leser ausführlich in Use Cases ein. Hier finden die Leser Lösungen für viele Probleme, mit denen sie sicher schon oft konfrontiert waren: Initialisieren und Beenden von Use Cases, interne Struktur von Use Cases und Navigation, Wiederverwendung und Erweiterung von Use Cases, Generalisierung von Use Cases und Akteuren, Arten der Use-Case-Dokumentierung und Abbildung von Use Cases in einem Klassenmodell. Echte Schätze sind im letzten Teil zu finden, in dem Use Case Patterns beschrieben werden. Für Konzeptionierer bzw. Systemanalytiker, die ständig Use Cases schreiben, haben die hier beschriebenen Patterns einen genauso hohen Wert wie berühmte Design Patterns für Software-Architekten und -Designer. Von den Patterns, die in diesem Abschnitt beschrieben werden, haben sich elf aus langjähriger persönlicher Erfahrung sowie aus umfassender Recherchearbeit der Autoren herauskristallisiert. Die fundamentale Bedeutung dieser Patterns zeigt sich auch darin, dass das Buch in der "Software Patterns Series" veröffentlicht wurde.
Trotz der großen Bedeutung von Use Case Patterns erwarten die Leser im vierten Teil einige Dinge, die für sie möglicherweise noch reizvoller sind: Use Case Blueprints. Blueprints sind so etwas wie Halb-Patterns – sie lassen sich zwar nicht so streng klassifizieren, strukturieren und beschreiben, weisen aber gerade deswegen eine höhere Flexibilität und manchmal mehr Power auf als Use Case Patterns. Wenn Leser die zehn beschriebenen Blueprints aufmerksam betrachten, finden sie dort Lösungen für zahlreiche Probleme, auf die sie bei der Definition von Software-Verhalten sicher schon oft gestoßen sind. Dazu zählen Probleme bei der Beschreibung von Zugriffskontrollreaktionen, die Anmelden/Abmelden-Problematik, Kommunikation mit Legacy-Systemen usw.
Im letzten Abschnitt werden typische Fehler von Use-Case-Schreibern analysiert. Ähnliches Material findet man im klassischen Buch von Alistair Cockburn "Use Cases effektiv erstellen", allerdings sind die dort beschriebenen Fehler eher der Kategorie "Regelverletzung beim Schreiben von Use Cases" zuzuordnen. Die in Paragraph fünf von Övergaard und Palmkvist beschriebenen Fehler sind von "feinerer" Natur und entstehen trotz der Bemühungen, alles richtig zu machen. Sie resultieren daraus, dass man einige Konzepte zu dogmatisch versteht und anwendet oder nicht merkt, dass bestimmte Use-Case-Konstrukte nicht zu den Rahmenbedingungen passen. Der Leser, die sich die Mühe macht, dieses Kapitel fleißig durchzuarbeiten, kann danach sicher viel Zeit und Nerven beim Erstellen von eigenen Use Cases sparen.
"Use Cases" eröffnet neue Dimensionen bei der Anwendung von selbigen und gehört definitiv zum unverzichtbaren Rüstzeug jedes Systemanalytikers und Konzeptionierers. Für Projektleiter, Architekten, Designer, Entwickler und Tester in Use-Case-zentrierten Projekten ist die Kenntnis dieses Buch auch sehr hilfreich.
