Der Use Case: Verhalten modellieren

Use Cases (Anwendungsfälle) gehören zu den bekanntesten Modellierungstypen Das hat einen guten Grund: Wenn wir etwas beschreiben, interessiert uns das Verhalten ganz besonders. Und Use Cases erlauben uns, dies zu tun.

Es ist leicht, in kurzer Zeit mit Use Cases erfolgreich zu spezifizieren, wenn ein paar Grundkonzepte verinnerlicht und ein paar Regeln befolgt werden. Darum geht es in diesem Artikel.

Auch in ihrer grafischen Form sind Use Cases markant und haben einen hohen Widererkennungswert. Es sind Ovale, die mit einem Strich mit dem dazugehörigen Aktor verbunden sind.

Use Cases sind sowohl Teil der UML als auch der SysML. In der SysML gibt es zwar auch das Element „Actor“, allerdings wird empfohlen, statt dessen Blöcke zu benutzen. Da gibt es formale Gründe für, aber intuitiv ist dies wichtig, weil ein Aktor nicht unbedingt eine Person sein muss.

Das Bild ist (fast) nutzlos

Man kann es nicht oft genug sagen: Das Diagramm ist nicht das Modell, sondern lediglich eine Sicht auf das Modell. Daher sollte das Bild bestenfalls als eine Landkarte verstanden werden, die einen groben Überblick gewährt. Wichtiger sind die Informationen, die hinter dem Use Case stecken.

Das zeigt sich auch dadurch, dass es unzählige Vorlagen für das Formulieren von Use Cases gibt. Das sind typischerweise Tabellen mit mehr oder wenig vielen Einträgen. Wenn mit einem Modellierungswerkeug wie No Magic oder Enterprise Architect gearbeitet wird, dann stellt das Werkzeug über standardisierte hundert Attribute bereit.

Ein einfacher Use Case

Ein einfacher Use Case besteht lediglich aus Name, Aktor und Beschreibung. Damit ist vielleicht auch klar, warum man für das Arbeiten mit Use Cases auch ohne Modellierungswerkzeug auskommen kann. Hier ist ein einfaches Beispiel:

Ganz wichtig ist natürlich die Beschreibung, die einer Testschablone folgen kann, also bspw: „Als <Rolle> möchte ich <Aktivität>, damit <Ziel>“.

Detail hinzufügen

Das bisher gezeigte ist extremst minimal. Selbst wenn ohne Modellierungswerkzeug gearbeitet wird, so enthält eine typischer Use Case mehr als nur die drei oben aufgeführten Felder. Die oben verlinkte Bibliothek von Templates gibt dazu viele Anregungen. Wie in vielen anderen Situationen auch ist es allerdings empfehenswert, wirklich nur die Felder aufzunehmen, die auch wirklich gebraucht werden.

Nicht mehr Felder benutzen, als unbedingt notwendig ist.

Modellieren statt dokumentieren

Das bisher gezeigte könnte auch in einer Textverarbeitung realisiert werden. Doch auch in dieser Form haben wir es schon mit einem einfachen Modell zu tun. Konkret haben wir hier schon zwei Datentypen (Aktor und Use Case), die über eine Beziehung miteinander verbunden sind. Das allein kann schon hilfreich sein. Wenn bspw. ein Aktor mit keinem einzigen Use Case verknüpft ist sollten wir uns fragen, ob dieser Aktor wirklich ein Stakeholder ist.

Doch wirklich interessant wird es, wenn wir beginnen, den Use Case mit der Domäne zu verknüpfen. Denn um Verhalten zu beschreiben, brauchen wir auch eine Beschreibung des Teils der Welt, den wir betrachten. Und dafür benötigen wir das Domänenmodell, welches in der SysML mit Blöcken beschrieben wird. Um das Beispiel oben aufzugreifen: Unser Domänenmodell beschreibt hoffentlich, was wir mit System meinen, und was ein Konto ist.

Hier gibt es nun die Möglichkeit in der Detaillierung immer mehr in die Tiefe zu gehen. Im Extremfall geht dies so weit, dass das Verhalten des resultierende Modells simuliert werden kann, und das Softwarecode aus dem Modell heraus generiert werden kann. Wie das konkret vor sich geht (bspw über die Modellierung von Aktivitäten) ist nicht im Scope dieses Artikels.

Zu viel Formalität kann das Modell schnell unübersichtlich, unverständlich und schwer wartbar machen.

In einem längeren Artikel im RE-Magazin berichte ich von einer Case Study aus der Logistikbranche die zeigt, wie effektiv mit Use Cases spezifiziert werden kann.

Die richtige Methode wählen

Use Cases sind ein Sprachelement. Das bedeutet, wir müssen die Sprach verstehen und richtig anwenden. Es ist nicht ratsam, „einfach drauflos zu spezifizieren“. Ich hatte in diesem Blog bereits den ICONIX-Prozess beschrieben, der meiner Meinung nach einen guten Einstieg bietet. Aber es gibt auch viele andere Methoden, und vielleicht reicht es ja auch aus, eine einfache Methode selbst zu entwerfen und auf ein paar Seiten zusammenzuufassen. Aber gerade im Team ist es wichtig, dass es ein gemeinsames Regelwerk gibt.

Wenn diese einfachen Regeln beachtet werden, dann steht der erfolgreichen Use Case-Modellierung nichts mehr im Weg.

Photo by Agnieszka Boeske on Unsplash