"Klar zum Entern", Anwendungsfälle für Piraten?

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.

Letztes Jahr bin ich in einem Blogpost auf die 30 jährige Geschichte der Anwendungsfälle eingegangen. In einer kleinen Reihe von Blogposts möchte ich nun verschiedene Aspekte von Anwendungsfällen näher beleuchten.

Den Auftakt mache ich mit einem wenig beachteten Detail der Anwendungsfalldefinition in der UML 2.5:

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.

Das Ergebnis von Wert muss also nicht unbedingt für den Akteur vorteilhaft sein, sondern auch ein anderer Stakeholder kann davon profitieren!

Gestoßen bin ich auf dieses Detail durch eine Frage in meinem UML-Kurs: Ein Teilnehmer war beteiligt an der Entwicklung eines Piratenabwehrsystems für Handelsschiffe und wollte wissen, ob Piraten hier korrekt im Sinne der UML als Akteure eines Anwendungsfalls zu betrachten sind. Definitiv wird der Pirat die Ergebnisse des Anwendungsfalls "beobachten" – dafür wird das System ja gebaut. Er wird den Anwendungsfall sogar selbst auslösen – das System soll Angriffe automatisch abwehren. Aber, dass das Ergebnis von Wert für ihn ist, kann man nun wirklich nicht sagen. Wie also sollte das Anwendungsfalldiagramm aussehen?

Am Rande einer Konferenz hatte ich Gelegenheit Ivar Jacobson selbst zu diesem Thema zu befragen. Er erinnerte sich an ein ähnliches Beispiel aus seiner Praxis, bei dem es um ein System zur Störung der Radarerfassung von Flugzeugen durch feindliche Raketen ging. Hier ist der auslösende Akteur der Radar-Sender, während die profitierenden Stakeholder die Passagiere des Flugzeugs sind. Eine Notation dafür hatte er nicht, fand aber meinen Vorschlag, den ich im Folgenden darlegen werde, gut geeignet (Bild: Ivar Jacobson - Use-Case 2.0 from Ivar Jacobson International on Vimeo).

Bei der Benutzung eines Systems lassen sich vier Rollen unterscheiden:

• Initiator des Anwendungsfalls
• Beobachter des Ergebnisses
• Nutznießer des Ergebnisses
• Passiv Beteiligter

Im einfachsten Fall gibt es keine passiv Beteiligten und Initiator, Beobachter und Nutznießer sind dieselbe Person: "Zimmer reservieren" wird vom Hotelgast initiiert, er beobachtet die Reservierungsbestätigung und profitiert von der Reservierung.

Sollten es mehrere Akteure sein, schlage ich Folgendes vor:

• Initiator: navigierbare Assoziation (Pfeil zum Anwendungsfall)
• Beobachter: keine besondere Notation (kann Initiator oder passiv Beteiligter sein)
• Nutznießer: Abhängigkeit (gestrichelter Pfeil zum Stakeholder, der auch passiv Beteiligter sein kann)
• Passiv Beteiligter: bidirektionale Assoziation (kein Pfeil)

Sowohl der Initiator als auch die passiv Beteiligten interagieren mit dem System und beobachten dabei unter Umständen auch Ergebnisse. Wie das genau abläuft steht in der Anwendungsfallbeschreibung. Eine besondere Notation ist daher meines Erachtens nicht nötig. Der Nutznießer kann gleichzeitig Akteur dieses oder anderer Anwendungsfälle sein oder auch einfach nur ein Stakeholder des Systems. Wir brauchen also zusätzlich eine Notation für reine Stakeholder (alle Akteure sind natürlich auch Stakeholder). Diese Notation kann von der SysML übernommen werden: Ein Strichmännchen mit Stereotyp «stakeholder».

Mein Vorschlag sieht also vor, den Nutznießer eines Anwendungsfalls mittels einer Abhängigkeit mit dem Anwendungsfall zu verbinden, es sei denn er ist, wie häufig, aber eben nicht immer, der Initiator. Der Name des Anwendungsfalls sollte dann aus der Sicht des Nutznießers formuliert werden, also nicht "Schiff entern" sondern "Schiff gegen unbefugtes Entern sichern".

Was halten Sie von dieser Erweiterung?