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?
Nette Zusammenfassung, die Einzelheiten kann jeder bei Bedarf im ECSS-E-HB-40A Kapitel 6.1 [http://www.ecss.nl/wp-content/uploads/handbooks/ecss-e-hb/ECSS-E-HB-40A11December2013.doc] nachlesen.
Beste Grüße,
Carsten Pitz
Hallo Herr Pitz,
ich habe mir das Dokument mal angeschaut. Eine Beschreibung von Anwendungsfällen, deren Nutznießer nicht der Initiator ist, fand ich dort aber nicht. Die Beispiele kommen mir auch seltsam vor: „Telemetrie Acquisition“ oder „Decommutation“ scheinen eher Funktionen eines „Monitoring & Control“ Systems zu sein, die im Rahmen des Anwendungsfalls „monitor satellite“ benötigt werden. Aber ich habe ja auch keine Erfahrung im Satellitenbau.
Viele Grüße
Axel Scheithauer
ist unter
INTERACTION WITH OTHER USE CASES AND ACTORS
Identification of interactions with other use cases and actors. Illustrated by an excerpt of the principle use case diagram detailing the main aspects specific to this use case. The diagram can show actors and use cases of lesser importance not described within the main diagram.
versteckt.
Das was ich an dieser Beschreibung besonders schätze ist, die implizite Forderung, dass jeder Teilaspekt getrennt dargestellt wird. SRP (Single Responsibility Principle) auf use case Ebene. Und ein „Nutznießer der nicht Initiator ist“, ist nunmal ein „actor of lesser importance not described within the main diagram.“
Beste Grüße,
Carsten Pitz
Hm, „actors of lesser importance“ sind aber immer noch Akteure. Mit meinem Vorschlag führe ich eine Beziehung von Anwendungsfällen zu Stakeholdern ein, die nicht einmal Akteure des Systems sein müssen.
Das Single Responsibility Principle birgt bei Anwendungsfällen die Gefahr, zu einer vorzeitigen funktionalen Zerlegung einzuladen. Meiner Erfahrung nach kann man nicht genug vor dieser Zerlegung warnen, weil sie den eigentlichen Zweck der Anwendungsfallanalyse ad absurdum führt. Richtig ist, dass ein Anwendungsfall genau ein Ziel bennen sollte. Bei der Analyse aller Wege die zu seiner Erreichung oder zum Scheitern führen, können aber Funktionen aus mehreren Verantwortlichkeitsbereichen gefunden werden.
Viele Grüße
Axel Scheithauer
Der Nutznießer in Ihrem Beispiel ist ein Actor mit dem Stereotyp <> somit auch ein Akteur als Übersetzung von Actor in das Deutsche.
Um nicht aneinander vorbei zu diskutieren: Ich trenne strikt zwischen Modell und Diagramm. Für mich ist ein Modell kein Loseblattsammlung von Bildchen. Ein einzelner Anwendungsfall kann und durch mehrere Anwendungsfalldiagramm illustriert werden. Jedes Anwendungsfalldiagramm beschreibt nach meinem Vorgehen genau einen Aspekt eines Anwendungsfalls. Jeder einzelne Anwendungsfall beschreibt dabei einen in sich geschlossenen, nicht sinnvoll teilbaren Vorgang. Dieser Vorgang kann aber muss nicht zwingend von einer natürlichen Person initiiert werden. Auch ein technisches System kann einen Anwendungsfall initiieren. An einem Anwendungsfall können sowohl natürliche Personen (z.B. Nutznießer) als auch technische Systeme (z.B. Monitoring Systeme) partizipieren. Entsprechend verwende ich seit gut 10 Jahren neben Stereotypen zum sub-typing von Actor auch Stereotypen zum sub-typing des Communication Path.
Was einen „in sich geschlossenen, nicht sinnvoll teilbaren Vorgang“ darstellt bestimmen die Anwender und nicht der Entwickler. Entsprechend gibt es keine “ vorzeitige funktionale Zerlegung“. Es geht rein um die Definition und Beschreibung von Vorgängen und nicht um mögliche technische Umsetzungen. Entsprechend darf ich als Moderator keine Technik einbringen. Gut dazu musste ich mir hin und wieder selbst auf die Zunge beißen, aber es geht.
Nette Nebeneffekte dieses Vorgehens sind, dass anhand dieser Anwendungsfälle
* die Anwender Testfälle und Abnahmekriterien definieren können
* eine sinnvolle Struktur des Nutzerhandbuchs bereits vorliegt
* Change Management unterstützt wird
Gut ein äußerst verbreitetes, der Hersteller nennt es Modellierungswerkzeug unterstützt dieses Vorgehen nur unzureichend. Dieses „Modellierungswerkzeug“ ermöglicht es z.B. nicht, Kommentare an mehrere Elemente zu binden. Zudem stellt dieses „Modellierungswerkzeug“ nicht einmal die referentielle Integrität des Modells sicher. So verbleibt beim Löschen eines Assozialionsendes die Assoziation im Modell ;-)
Beste Grüße,
Carsten Pitz
Soll heißen: Mit dem Stereotyp stakeholder ;-)
Eine Ergänzung: SysML 1.4 definiert im Profil SysML::ModelElements den Stereotyp Stakeholder mit den Attributen.
concernList: Comment [*] The interests of this stakeholder.
/concern: String [*] The interests of this stakeholder displayed as the body of the comments from concernList.
Beste Grüße,
Carsten Pitz
Hallo Herr Pitz,
welche Aspekte eines Anwendungsfalls beschreiben Sie denn im Anwendungsfalldiagramm? Der Standard gibt da ja nicht allzuviel her. Die Assoziationen mit Stereotypen näher zu spezifizieren finde ich gut.
„Nicht sinnvoll teilbarer Vorgang“ ist meines Erfahrung nach nicht ausreichend um zu fruchtbaren Anwendungsfällen zu kommen. Über dem Ganzen muss immer das Ziel des Nutznießers stehen. Nur so komme ich auf wichtige Funktionen, die sonst übersehen werden und beim ersten Einsatz des Systems dann schmerzlich vermisst werden.
Viele Grüße
Axel Scheithauer
Die Beschränkung der Formulierung des Anwendungsfalls auf den Nutznießers (im Beispiel der Kapitän) wirft in meinen Augen auch ein Blickwinkel-Problem auf. Bei gleichen Aktivitäten kann es zwei unterschiedliche Nutznießer geben.
Aus Sicht des Piraten wäre der Auslöser das Erscheinen des Schiffes und das positive Ergebnis die Erbeutung desselben.
Aus Sicht des Kapitäns wäre der Auslöser, wie beschrieben, das Erscheinen des Piraten und das positive Ergebnis dessen Abwehr.
Zu diskutieren wäre also, ob dies zwei unterschiedliche Anwengsfälle (Schiff entern vs. Piraten abwehren) im gleichen Systemkontext sind. Weiterhin interessant wäre aus meiner Sicht, zu diskutieren, ob die Berücksichtigung des Zwecks beteiligter Systeme (hier: Piraten erfolgreich abwehren) eine Hilfe bei der Formulierung von Anwendsfällen bietet.
Das interessante an den beiden Anwendungsfällen ist, sie sind komplementär. Jeder der beiden Anwendungsfälle stellt einen Testfall des jeweils anderen Anwendungsfalls dar.
So beschreibt „Schiff entern“ eine Sammlung von Tests um „Piraten abwehren“ zu testen. Anders herum beschreibt „Piraten abwehren“ eine Sammlung von Tests um „Schiff entern“ zu testen.
Gut, welcher im Sinne des systems under construction der Anwendungsfall und welcher der Testfall ist hängt von der Interessenlage des Auftraggebers ab.
Beste Grüße,
Carsten Pitz
Hallo Herr Pitz,
das ist für mich eine sehr interessante Herangehensweise, die komplementären Anwengsfälle als Paare von Anwengsfall und Testfall zu betrachten.
Das werde ich zukünftig in meinen Analysen mit einbeziehen.
Beste Grüße
Volkmar Berg
Ja, der Ansatz einen komplementären Anwendungsfall als Testfall zu nehmen ist interessant. Aber leider gibt es in der Praxis eher selten komplementäre Anwendungsfälle. Was sind sollen als Beispiel die komplementäre Anwendungsfälle zu
* Datensatz erfassen
* Datensatz suchen
* Datensatz ändern (uses Datensatz suchen)
* Datensatz löschen (uses Datensatz suchen)
sein?
Das hier genannte Beispiel ist insofern ein kleiner Edelstein, von denen es aber in der Praxis nicht so viele gibt. Somit im Grunde genommen die Kategorie interessant, aber nicht relevant ;-)
Beste Grüße,
Carsten Pitz
Hallo Herr Berg,
ich stimme zu, dass eine bestimmte Funktion/Aktivität eines Systems von verschiedenen Nutznießern zu unterschiedlichen Zwecken eingesetzt werden kann. Genau diese Zwecke will ich mit Anwendungsfällen dokumentieren. Oft werden von den verschiedenen Nutznießern nämlich noch weitere Funktionen benötigt, die dann durch die Analyse der Anwendungsfälle gefunden werden. Die verschiedenen Blickwinkel sind nicht das Problem, sondern wenn ich vergesse alle relevanten Blickwinkel zu berücksichtigen. Möglich ist aber auch, dass andere Nutznießer nichts neues hinzufügen: Die Crew und der Reeder haben wahrscheinlich die gleiche Interessen wie der Kapitän, so dass es ausreicht, die Anwendungsfälle des Kapitäns zu beschreiben.
„Schiff entern“ ist meines Erachtens kein sinnvoller Anwendungsfall für ein Piratenabwehrsystem (nur um dieses geht es ja hier). Das mag das Interesse des Piraten sein – der Zweck des Systems ist aber gerade ihn daran zu hindern.
Der Zweck des zu bauenden Systems steht für mich im Mittelpunkt der Anwendungsfallanalyse. Alistair Cockburn hat das in seinem Buch „Writing effective Use Cases“ sehr deutlich gemacht: „a use case contains the set of possible scenarios for achieving a goal”. Daher sehe ich gar keine andere Quelle für die Formulierung von Anwendungsfällen.
Ich habe nicht verstanden, was Sie mit beteiligten Systemen meinen. Das könnte das Radarsystem sein, aber sein Zweck steht ja bei der Analyse des Piratenabwehrsystems nicht zur Debatte. Über dieses System muss ich nur wissen, was es liefert oder von meinem System erwartet.
Viele Grüße
Axel Scbeithauer
Und ich gehöre zu denen, die mit dann den stolzen Erstellern von Tapeten erklären dürfen: Alistair Cockburn Aussage „a use case contains the set of possible scenarios for achieving a goal” ist zu hinterfragen.
Nach meiner Praxis führt diese Aussage häufig dazu, sämtliche use cases auf ein Diagramm zu quetschen. Ich habe bereits etliche solcher Tapeten, die mit 6pt Schriftgrad so gerade auf DIN A0 passten erlebt. Der Rekordhalter hatte fast 700 use case icons auf einem Diagramm. Das Diagramm benötigte dann aber auch 2x DIN A0, dafür ging noch 8pt Schriftgrad ;-)
Beste Grüße,
Carsten Pitz
Hallo Herr Pitz,
hm, welches technische System hat denn 700 Anwendungsfälle? Das scheint mir eher ein Beispiel für „The case of the useless use cases“ zu sein (siehe meinen ersten Blogpost zum Thema).
Wie dem auch sei – selbst 20 Anwendungsfälle würde ich nicht im gleichen Diagramm zeigen. Oft verzichte ich sogar ganz auf Diagramme, weil das Anwendungsfalldiagramm eh nicht besonders aussagekräftig ist. In einer Workshopsituation an der Pinwand funktioniert es gut – im Modell tut es oft auch eine Tabelle.
Ich verstehe nicht, wie die Aussage von Cockburn zu mehr Anwendungsfällen führt. Sie bezieht sich doch auf Szenarien und die sind im Anwendungsfalldiagramm gar nicht darstellbar. Und da in jedem Anwendungsfall mehrere Szenarien enthalten sind, müssten doch sogar weniger Anwendungsfälle entstehen.
Viele Grüße
Axel Scheithauer
Sie glauben nicht wozu „Architekten“ fähig sind. Mit solche Tapeten bin ich sowohl im öffentlichen Dienst als auch in der freien Wirtschaft, inklusive Tier 1 Automotive Supplier konfrontiert worden.
Richtig nett sind auch DIN A0 Klassendiagrammtapeten bei denen so 40 bis 50 Assoziationen als Band im mit jeweils etwa 1mm Abstand laufen. Diese dann 4 bis 5 cm grauen Balken mit etlichen Kreuzungen sind richtig übersichtlich.
Beste Grüße,
Carsten Pitz
PS Wer Ironie findet, darf diese behalten.
Hallo Herr Scheithauer,
mit „beteiligte Systeme“ meinte ich tatsächlich soetwas wie das Schiffsradar. Die legen dann den vorangegangenen Überlegungen folgend in ihrem Primärzweck auch den Blickwinkel für die zu analysierenden Anwendungsfälle fest.
Ich finde die Gedanken von Herr Pitz in diesem Zusammenhang sehr spannend, den komplementären Anwengsfall als Testfall zu formulieren.
Ich sehe nicht, dass die beiden Anwendungsfälle komplementär sind. Der eine ist für ein Piratenabwehrsystem und der andere könnte für einen Enterhaken sein. Der Enterhakenanwendungsfall eignet sich nicht wirklich als Testfall für „Piraten abwehren“, weil die meisten Details für das Piratenabwehrsystem völlig unerheblich wären. Natürlich könnte im Anwendungsfallszenario von „Piraten abwehren“ der Versuch einen Enterhaken anzubringen enthalten sein. Dafür lohnt es sich aber wohl nicht, zuerst die Anwendungsfälle von Enterhaken zu analysieren.
Kann sein, dass man eine Analyse der Angriffszenarien machen muss, insbesondere wenn man mit noch unbekannten Herangehensweisen rechnen muss. Entwickler von Firewalls können davon ein Lied singen. Diese Analyse würde aber nicht dazu führen, die Anwendungsfälle von Hackersoftware zu erheben. Bei Piraten genügt es zudem momentan noch die sattsam bekannten Entermethoden einzubeziehen. Erst wenn die abgewehrt werden können, werden sich die Piraten was neues überlegen.
Viele Grüße
Axel Scheithauer
@Axel Scheithauer
> welche Aspekte eines Anwendungsfalls beschreiben Sie denn im Anwendungsfalldiagramm?
Im Wesentlichen beschreibe ich in einem Anwendungsfalldiagramm die abstrakten Kollaborationsbeziehungen zwischen den Akteuren bezüglich eines Aspekts eines Anwendungsfalls.
Nehmen wir als Beispiel einen so spannenden Anwendungsfall wie „Datensatz erfassen“:
Ein Anwendungsfalldiagramm würde den Aspekt Standardfall „alles läuft wie vorgesehen“ beschreiben. Ein weiteres Anwendungsfalldiagramm den Aspekt „es tritt ein Fehler auf“.
Im Standardfall wird höchstwahrscheinlich der Sachbearbeiter als alleiniger Akteur auf dem Anwendungsfalldiagramm verewigt sein. Im Fehlerfall eventuell zusätzlich ein First Level Supporter.
Ein Anwendungsfalldiagramm zeigt nur Beziehungen zwischen Akteuren bezüglich eines Anwendungsfalls. Entsprechen gehören für mich textuelle Beschreibungen, häufig user stories genannt zu einem Anwendungsfall. Die user stories sind von den Endanwendern in der Sprache der Endanwender geschrieben. Eine user story ist somit ein owned comment eines Anwendungsfalls. Auch macht es aus meiner Praxis häufig Sinn zusätzlich die Beziehungen in der Sprache der Endanwender zu beschreiben. Diese Beschreibungen sind dann owned comments der Assoziationen. Auch die Aktoren haben einen owned comment, welcher die Rollenbeschreibung in der Sprache der Endanwender enthält.
Einem Anwendungsfall kann über das Assoziationsende subject Classifier zugewiesen werden. Bei mir ist dies in aller Regel ein BehavioredClassifier in der Ausprägung Collaboration. Dies ist der Übergang von der auf Endanwender zugeschnittenen eher informellen Beschreibung in die formale Welt.
Beste Grüße,
Carsten Pitz
Hallo Herr Pitz,
die textuellen Elemente mit ownedComments an die jeweiligen Elemente zu hängen ist auch meine Praxis. In meinem Tool kann ich dafür sogar den normalen Eigenschaftendialog verwenden, der im Hintergrund einen solchen Kommentar anlegt. Eine Kollaboration als Subjekt zu verwenden ist ungewöhnlich. Ich werde über den Zusammenhang zwischen Anwendungsfällen und Kollaborationen vermutlich in einem weiteren Blogpost schreiben.
Viele Grüße
Axel Scheithauer
Hallo Herr Scheithauer,
Sind in ihrem Tool Kommentare im Model Explorer sichtbar?
Kann mit ihrem Tool ein owned comment eines Elementes als applied comment an ein anderes Element gebunden werden?
Werden in ihrem Tool in Kommentaren verwendete Namen von Elementen nach Umbenennen dieser Elemente im Kommentar auch automatisch entsprechend umbenannt?
Beste Grüße,
Carsten Pitz
Hallo Herr Pitz,
ein UML-Tool das diese Bezeichnung wert ist, kann das.
Das Umbenennen hat allerdings weniger mit UML zu tun, als mit toolspezifischen Konventionen. Das will ich auch nicht in jedem Fall haben, da die Zuordnung ja nur über den Namen geht.
Viele Grüße
Axel Scheithauer
Nein, nicht über Namensgleichheit, sondern über Referenzen in den Kommentaren auf die Elemente ;-)
Beste Grüße,
Carsten Pitz
Das ist definitiv ein cooles Feature, aber halt nicht im UML-Standard definiert und daher leider toolabhängig.
Viele Grüße
Axel Scheithauer
Cooler finde ich die, wie die ArchiMate Spezifikation es nennt Magic Connectors. Bei einem mouse over werden an einem Element outgoing und incoming handles angezeigt. Wird ein handle auf ein anderes Element gezogen, erscheint neben dem Mauszeiger eine Liste von erlaubten Assoziationstypen. Wird ein Assoziationstyp gewählt, wird die entsprechende Assoziation korrekt gerichtet angelegt.
Aber mein Tool, so behaupten einige Ihrer OOSE Kollegen hat eine extrem schlechte UX ;-)
Beste Grüße,
Carsten Pitz