Im zweiten Teil der vierteiligen Serie zu UML geht es heute um das Anwendungsfalldiagramm, welches auch unter dem Namen Use-Case-Diagramm bekannt ist. Hierin wird dieser Diagrammtyp aus Sicht eines Amateurprogrammierers beschrieben und die Aufgabe genannt, für welche das Anwendungsfalldiagramm eine Hilfe sein kann. Nach einigen einführenden Worten erkläre ich die Grundlagen eines Anwendungsfalldiagramms anhand eines eigenen Beispiels. Dann werde ich auf die einzelnen Elemente und Besonderheiten eines Anwendungsfalldiagramms eingehen.
Im ersten Teil der UML-Serie ging es vorrangig um die Erläuterung, warum ich in diesem Weblog über UML schreibe und was die Leser zu erwarten haben. Heute geht es ans Eingemachte mit dem ersten Diagrammtyp für Anwendungsfälle.
Was ist ein Anwendungsfalldiagramm und was kann ich damit tun?
In einem Satz zusammengefasst, zeigt das Anwendungsfalldiagramm den strukturellen Zusammenhang und die Abhängigkeiten zwischen sogenannten Akteuren und den Anwendungsfällen. Dabei werden weder das Verhalten der Akteure noch irgendwelche Abläufe beschrieben, sondern nur das Zusammenwirken der Elementen (Akteure und Anwendungsfälle). Was Akteure und Anwendungsfälle sind, dazu komme ich etwas später im Text.
Jeder, der schon einmal etwas komplexeres programmiert hat und dabei einfach drauflos geschrieben hat, musste am Ende wahrscheinlich feststellen, dass hier eine Funktion fehlt und da noch eine Schnittstelle wünschenswert wäre, damit das Gesamtprogramm sinnvoll ist und funktioniert, wie zu Beginn angedacht. Davon abgesehen, dass es meist kein guter Rat ist, ein Programm einfach anfangen zu schreiben, ohne sich zumindest eine grobe Struktur in Gedanken anzulegen, kann ich jedem nur ans Herz legen, die Anforderungen an ein Programm schriftlich oder grafisch festzuhalten. In solchen Fällen eignet sich das Anwendungsfalldiagramm. Im professionellen geschäftlichen Bereich kann es sogar soweit gehen, dass ein Anwendungsfalldiagramm die Grundlage eines Vertrages zwischen einem Softwarehersteller und seinem Kunden wird. Daraus kann eine ganz wichtige Eigenschaft des Anwendungsfalldiagramms heraus gelesen werden: Meist interessiert es den Kunden nicht, wie ein Programm funktioniert, er gibt nur vor, was es leisten soll. Aus dieser Tatsache folgt die Aussage über das Ziel eines Anwendungsfalldiagramms:
Das Anwendungsfalldiagramm hat zum Einen das Ziel den Funktionsumfang des Programms zu definieren und dabei möglichst die Kosten für nachträgliche Veränderungen zu minimieren und zum Anderen eine zielgerichtete, problemorientierte Entwicklung zu unterstützen.
Ein sehr einfaches Beispiel ist im folgenden Bild gezeigt.
Beispiel: Anwendungsfalldiagramm eines Blogs
Das Diagramm soll ein einfaches Modell eines Weblogs darstellen, wobei folgende Anwendungsfälle vorhanden sind:
- Artikel schreiben
- Artikel modifizieren
- Artikel kommentieren
- Artikel lesen
Also beschreiben Anwendungsfälle die Wechselwirkung zwischen den Akteuren und dem System.
Akteure sind die Besucher und der Administrator, folglich in diesem Fall Leute, die vor dem Rechner sitzen und am Blog etwas machen.
Viele weitere Beispiele kannst du mit der Google Bildersuche finden, indem du nach “Anwendungsfalldiagramm” suchst.
Elemente eines Anwendungsfalldiagramms
Die zwei wichtigsten Elemente haben wir schon kennen gelernt: die Anwendungsfälle und die Akteure. Wie im obigen Beispiel dargestellt, werden die Anwendungsfälle mit Ellipsen und einer Bezeichnung symbolisiert. Ein vernünftiger Anwendungsfall besteht meist aus zwei Wörtern, einem Substantiv und einem Verb. Ist das nicht der Fall, dann kann das Diagramm vielleicht noch optimiert werden.
Die Akteure werden als Strichmännchen dargestellt und die Bezeichnung unter das Männchen geschrieben. In der Fachliteratur sind noch weitere Details zum richtigen Darstellen von besonderen Akteuren, worauf ich hier jedoch nicht eingehen möchte.
Die Verbindungslinien zwischen den einzelnen Elementen stehen für die Beziehungen. Eine wichtige Beziehung ist die include-Beziehung. Damit wird ein Anwendungsfall in einen anderen eingebunden. Eine Unterteilung der Anwendungsfälle ist jedoch nur sinnvoll, wenn der ausgegliederte Anwendungsfall mehr als einmal eingebunden wird. Die include-Beziehung wird mit einer gestrichelten Linie und einer Pfeilrichtung hin zum einzugliederndem Anwendungsfall dargestellt.
Würde ich nun in dem Beispiel meiner eigenen Erklärung der include-Beziehung folgen, dürfte ich den Anwendungsfall “Freischaltung anfragen” nicht auslagern. Jedoch kann es an dieser Stelle wichtig sein, um zu verdeutlichen, dass nicht alle Kommentare wahllos zugelassen werden. Es könnte ja Spam dazwischen sein.
Eine ähnliche Funktion hat auch die extend-Beziehung, welche einen Anwendungsfall erweitert, aber im Gegensatz zu include ihn nicht zum Bestandteil des Anwendungsfalls macht.
Zwischen den Akteuren und einem Anwendungsfall können auch besondere Beziehungen gelten. Wie in dem Beispiel gezeigt, können an beiden Enden der Beziehung sogenannte Multiplizitäten angegeben werden. Diese bedeuten so viel, wie: “Ein Administrator kann einen oder viel Artikel schreiben” oder “Ein Besucher kann keinen oder viele Artikel kommentieren”. Anders herum könnte man auch sagen: “Ein Artikel kann von keinem oder vielen Besuchern kommentiert werden”. Dann müsste noch “0..*” an der Beziehungslinie zwischen “Besucher” und “Artikel kommentieren” beim Besucher stehen. Ich denke, dass es klar wird, was es mit der Multiplizität auf sich hat.
Ein weiteres wichtiges Element des Anwendungsfalldiagramms ist die Systemgrenze, welche mit einem rechteckigen Rahmen um alle Anwendungsfälle gekennzeichnet wird.
Es gibt noch einige weitere Elemente, welche an dieser Stelle genannt werden können, aber ich denke, dass es für die Verwendung hier im Blog ausreicht, was ich bisher vorgestellt habe. Sollte es im einen oder anderen Fall nicht reichen, dann werde ich direkt im entsprechenden Artikel darauf näher eingehen. Die Ausführungen hier sollten aber für das Grundverständnis ausreichen.
Besonderheiten eines Anwendungsfalldiagramms
Unter den Besonderheiten des Anwendungsfalldiagramms führe ich die Punkte auf, welche beim Erstellen zu beachten sind:
- Beschreibung aus Sicht des Systems
- Beschreibung, was für Anwender sichtbar ist
- kein Verhalten oder Ablauf, nur Interaktion
- Was soll das System leisten?
- Nicht: Wie soll das System die Anforderung erfüllen?
- an jedem Anwendungsfall soll mindestens ein Akteur beteiligt sein
- Bezeichnung von Anwendungsfällen: Substantiv + Verb
Wo hast du bereits ein Anwendungsfalldiagramm gebraucht?
Ja, jetzt ist es wieder soweit: Du, lieber Leser, bist nun an der Reihe deine Erfahrungen darzulegen und etwas aus dem Nähkästchen zu plaudern. Hast du schonmal ein derartiges UML-Diagramm erstellt, hat es dir geholfen oder dich eher bei deiner Arbeit gestört? Kannst du eine Verbesserung vorschlagen?
Zwischen den Akteuren und einem Anwendungsfall können auch besondere Beziehungen gelten. Wie in dem Beispiel gezeigt, können an beiden Enden der Beziehung sogenannte Multiplizitäten angegeben werden. Diese bedeuten so viel, wie: “Ein Administrator kann einen oder viel Artikel schreiben” oder “Ein Besucher kann keinen oder viele Artikel kommentieren”. Anders herum könnte man auch sagen: “Ein Artikel kann von keinem oder vielen Besuchern kommentiert werden”. Dann müsste noch “0..*” an der Beziehungslinie zwischen “Besucher” und “Artikel kommentieren” beim Besucher stehen. Ich denke, dass es klar wird, was es mit der Multiplizität auf sich hat.
Ein weiteres wichtiges Element des Anwendungsfalldiagramms ist die Systemgrenze, welche mit einem rechteckigen Rahmen um alle Anwendungsfälle gekennzeichnet wird.
Es gibt noch einige weitere Elemente, welche an dieser Stelle genannt werden können, aber ich denke, dass es für die Verwendung hier im Blog ausreicht, was ich bisher vorgestellt habe. Sollte es im einen oder anderen Fall nicht reichen, dann werde ich direkt im entsprechenden Artikel darauf näher eingehen. Die Ausführungen hier sollten aber für das Grundverständnis ausreichen.
Besonderheiten eines Anwendungsfalldiagramms
Unter den Besonderheiten des Anwendungsfalldiagramms führe ich die Punkte auf, welche beim Erstellen zu beachten sind:
- Beschreibung aus Sicht des Systems
- Beschreibung, was für Anwender sichtbar ist
- kein Verhalten oder Ablauf, nur Interaktion
- Was soll das System leisten?
- Nicht: Wie soll das System die Anforderung erfüllen?
- an jedem Anwendungsfall soll mindestens ein Akteur beteiligt sein
- Bezeichnung von Anwendungsfällen: Substantiv + Verb
Wo hast du bereits ein Anwendungsfalldiagramm gebraucht?
Ja, jetzt ist es wieder soweit: Du, lieber Leser, bist nun an der Reihe deine Erfahrungen darzulegen und etwas aus dem Nähkästchen zu plaudern. Hast du schonmal ein derartiges UML-Diagramm erstellt, hat es dir geholfen oder dich eher bei deiner Arbeit gestört? Kannst du eine Verbesserung vorschlagen?
-->Artikel aus der selben Kategorie:
Meinungsfreiheit für alle!
Es gibt noch keine Kommentare zu “UML: Anwendungsfalldiagramm (Teil 2)”.
Jede Meinung ist willkommen!