Die im Deutschen so genannten Anwendungsfalldiagramme (Spezifikation: Use Cases)
zeigen den Nutzen eines Systems, also das, was ein System dem Nutzer an Funktionalität
bereitstellt. Somit sind die Anwendungsfalldiagramme insbesondere dazu geeignet,
die Funktionalität der zu programmierenden Software genau darzustellen.
Die so genannte Use-Case-Beschreibung ist zunächst rein textuell und wird
nicht mit UML-2.0-Notationselementen beschrieben. Diese rein textuelle Beschreibung
ist damit nicht Gegenstand der Prüfung, sondern vielmehr die UML-Variante,
die nachfolgend beschrieben wird.
Bei den im Folgenden beschriebenen Notationselementen dreht sich im Grunde alles um die Akteure und den Use Case. Der Akteur ist sozusagen der Außenstehende, der den Use Case nutzt. Es muss sich dabei nicht unbedingt um einen Menschen handeln, der das System nutzt; es kann sich bei dem Akteur auch um ein Fremdsystem handeln, das die Dienste eines anderen Systems nutzt. Der Use Case (also der Geschäftsanwendungsfall) ist die Funktionalität, die ein System sozusagen dem Akteur bereitstellt. Der Akteur nutzt also aktiv einen Use Case. Zum Beispiel nutzt ein Passagier am Flughafen den Check-In. Wobei der Passagier in diesem Beispiel der Akteur wäre und der Vorgang des Check-In der eigentliche Use Case.
Use Cases werden oft benutzt, um mit dem Kunden, der eine Software in Auftrag gibt, genauer zu kommunizieren und die Funktionalität zunächst einmal zu bestimmen. Hier geht es im Prinzip noch nicht um die genaue Konzeption der Software, sondern eher darum, wirklich herauszuarbeiten, welche kundenspezifischen Wünsche an sie gestellt werden. Oftmals weiß der Kunde oder Auftraggeber eher nur schemenhaft und relativ unkonkret, wie die genauen Probleme beschaffen sind, die er mit der zu entwickelnden Software lösen möchte. Für den Programmierer, beziehungsweise meistens den Projektleiter, gibt es zunächst die Aufgabe, den Kunden genau zu befragen und für ihn zu skizzieren, welches Geschäftsmodell die Software als Dienstleistung enthalten soll und welcher Vorteil dadurch erreicht werden kann.
Auf diese Weise soll der Kunde durch das Use-Case-Diagramm der UML 2.0 die Möglichkeit erhalten, mit dem Programmierer eine gemeinsame Sprache zu finden und sich auszudrücken. Dies ist natürlich auch der Hauptgrund, warum die Anzahl der Notationselemente sehr eingeschränkt ist. Es ist ja notwendig, auf einem sehr niedrigen Abstraktionsgrad zu beginnen und erst einmal eine gemeinsame Sprache zu sprechen, mit der alles Notwendige geklärt und ggf. auch ein Angebot und eine Lösung vorgeschlagen werden kann. Wichtig ist es auch, dass Sie gar nicht erst versuchen sollten, hier schon ins Detail zu gehen. Bedenken Sie, dass die Use Cases grundsätzlich eher in der ersten Phase eines Projektes, der so genannten Analysephase, stehen und einen Überblick über die Funktionalität schaffen sollen.
Die Abhängigkeiten der Pakete des Use Cases sind in Abbildung 2.1: Abhängigkeiten
von UseCases-Paketen aus der Spezifikation beschrieben. Die Use Cases sind dabei
ein Teil aus dem Paket BasicBehaviors.
In Abbildung 2.2: Metamodell Use Cases sehen Sie zunächst einen Überblick über das Metamodell zu den Use Cases.
Der Akteur (Spezifikation: Actor) interagiert mit dem System. Er steht
allerdings außerhalb des Systems und nutzt die durch den Use Case beschriebene
Funktionalität. Untereinander dürfen die Akteure keine Beziehungen
beispielsweise in Form einer Assoziation besitzen. Erlaubt ist allerdings die
Generalisierung von Akteuren. Somit kann ein Akteur von einem anderen Akteur
alle Eigenschaften erben. Der Erblasser darf in diesem Falle auch abstrakt sein,
was bedeutet, dass von ihm keine Objekte instanziert werden dürfen und
er ein reines Konzept darstellt.
Es gibt unterschiedliche Darstellungsformen des Akteurs, wie man in Abbildung 2.3: Akteur ersehen kann.
In Abbildung 2.3: Akteur wäre es auch erlaubt, den Namen des Akteurs, also hier in diesem Falle selbst Akteur genannt, über dem Kopf anzubringen.
Alternativ gilt die Notation, die den Akteur als Classifier darstellt. Diese nutzt man eher, wenn man Fremdsysteme darstellt, die diese Funktionalität nutzen. Das Strichmännchen symbolisiert eine Notation dafür, dass es sich um einen menschlichen Akteur handelt. In Abbildung 2.5: Darstellung des Akteurs als Classifier könnte beispielsweise eine Bank ein Akteur sein, indem sie etwas kauft, also ein System nutzt.
Es gibt noch eine Notationsmöglichkeit, bei der direkt klar wird, dass ein Akteur ein ganz anderes System darstellen soll, das einen Use Case nutzt. In diesem Fall wäre dies beispielsweise ein Webservice oder eine andere Software, die Teile der zu erstellenden Logik nutzt. Dies zeigt Abbildung 2.6: Ein anderes System, das ein Akteur darstellt .
Ein Use Case beschreibt in Deutsch übersetzt einen Anwendungsfall, der
die Funktionalität eines Teilaspektes in einem System darstellt. Zum Beispiel
wären dies einzelne Funktionalitäten, die in einem Software-Programm
zur Verfügung gestellt werden müssen. Die Use Cases zeigen nicht das
benötigte Verhalten auf, dafür wäre beispielsweise das Aktivitätsdiagramm
zuständig. Es soll lediglich dazu dienen, die Funktionalität aufzuzeigen,
die ein System zur Verfügung stellen soll.
Ein typisches Beispiel für einen Anwendungsfall ist der Eintrag eines neuen Kunden in ein Software-System.
Ein Anwendungsfall, der selbst den Namen Use Case hat, sieht wie in Abbildung 2.7: Anwendungsfall gezeigt aus.
Natürlich gibt es auch hier eine Alternativnotation, wobei in dieser Notation auch Attribute und Operationen dargestellt werden können. Es ist z.B. erlaubt, den Namen eines Anwendungsfalls in der Ellipse anzugeben (siehe Abbildung 2.7: Anwendungsfall), oder unterhalb wie in Abbildung 2.8: Der Name des Use Cases kann auch unterhalb des Use Cases notiert werden.
Im Gegensatz zum Akteur ist es hier nicht erlaubt, den Namen oberhalb der Ellipse zu notieren. Die Darstellung als Classifier ist auch noch möglich, dies zeigt Abbildung 2.9: Classifier-Darstellung
Ein Use Case darf gleichzeitig mehrfach instanziert werden. Dies heißt, dass er mehrfach genutzt werden darf. Dabei stellt ein Use Case immer eine abgeschlossene Einheit dar, die eine Funktionalität zur Verfügung stellt.
Eine Reihenfolge bei der Abarbeitung der Use Cases wird nicht beschrieben, auch wenn mehrere Use Cases untereinander angeordnet sind. Später werden Sie sehen, dass die Use Cases auch in einer Beziehung zueinander stehen können.
Die Verbindung zwischen einem Akteur und einem Use Case geschieht über
die so genannte einfache Assoziation (Spezifikation: Binary Association).
Ähnlich wie bei der Assoziation im Klassendiagramm können hier natürlich
auch Multiplizitäten angegeben werden, die auf der Seite des Anwendungsfalls
angeben, wie oft er gleichzeitig ausgeführt werden darf. Standardmäßig,
wenn also nichts anderes angegeben ist, gilt hier die Angabe 0..1.
Anders herum gibt die Multiplizität auf der Seite des Akteurs an, wie viele Akteure in derselben Rolle den Anwendungsfall nutzen können. Standardmäßig ist der Wert 1.
In seltenen Fällen nutzt man gerichtete Assoziationen, die darstellen, wer von beiden die Kommunikation anstößt. Im Falle einer Assoziation zwischen einem Akteur und einem Use Case verläuft die gerichtete Assoziation wie in Abbildung 2.10: Gerichtete Assoziation fast immer vom Akteur zum Use Case.
Anwendungsfälle sind meistens in Subsystemen untergebracht, die wiederum
benannt werden können. Die entsprechenden Akteure befinden sich –
wie bereits erwähnt – außerhalb der Subsysteme, wie man in
Abbildung 2.11: Subsystem ersieht.
Das Subsystem ist vom Prinzip her eine Komponente mit dem so genannten Stereotyp "subsystem", das ein spezieller Classifier ist:
<<subsystem>>
Ein Anwendungsfall kann auch in einem Classifier selbst dargestellt sein. Somit gibt es zum Beispiel den Fall, dass eine Komponente Anwendungsfälle bereitstellt.
Die Enthält-Beziehung wird zwischen zwei Anwendungsfällen angewendet.
Sie drückt aus, dass ein entsprechender Anwendungsfall einen anderen Anwendunsgfall
einbindet und ihn prinzipiell mit einbezieht. Somit ist in Abbildung 2.12: Include-Beziehung
zwischen zwei Anwendungsfällenzu sehen, dass der Use Case 2 ein Teil von
Use Case 1 ist. Er kann auch an anderer Stelle als Teilfunktionalität aufgerufen
werden, genauso wie er hier innerhalb von Use Case 1 aufgerufen werden. Ein
Beispiel wäre die Neuregistrierung von Kunden auf einer Webseite, die entweder
als eigenständige Aktion oder kurz vor dem Kassenbesuch ausgeführt
werden kann und sogar notwendig ist, wenn man noch kein Kunde bei diesem Online-Shop
ist.
Natürlich können Anwendungsfälle auch generalisiert werden.
Bei einer Erweiterungsbeziehung bindet ein Anwendungsfall einen anderen unter
bestimmten Bedingungen ein. Diese Bedingungen lassen sich in einem Kommentar
unterbringen. Ein Anwendungsfall kann hierbei durchaus beliebig viele Erweiterungspunkte
definieren; wenn es sehr viele sind, sollte man jedoch die Notation des Classifiers
vorziehen. Im Beispiel der Abbildung 2.13: Erweiterungsnotation wird Use Case
2 entsprechend reagieren, wenn die Bedingung eintritt, die für den Extension
Point angegeben ist.
Es kann beliebig viele Erweiterungspunkte von Use Cases geben, wie Sie aus obigem Metamodell durch die Angabe der Multiziplität erkennen können. Für die Erweiterungspunkte müssen nicht unbedingt Akteure verbunden sein, während dies für die Enhält-Beziehung verpflichtend ist. In der Prüfung werden häufig Beispiele genannt, bei denen dies abgefragt wird.
comelio.com
