Software Engineering: Use Case Diagramm

< Softwaretechnik Der UML-Diagrammtyp Use Case Diagramm oder Anwendungsfalldiagramm (engl. use case diagram) wird benutzt, um den User-View des UML-Modells zu definieren. Diese Benutzer-zentrierte Sicht soll allen Beteiligten an einem Softwareprojekt einen ersten und sehr groben Eindruck darüber geben, welche Funktionalitäten das geplante Softwaresystem realisieren soll und welche Benutzergruppen später mit ihm arbeiten werden. Dabei werden die Hauptfunktionalitäten des Softwaresystems Anwendungsfälle (engl. use cases) genannt und die Benutzergruppen des Systems als Akteure (engl. actors) bezeichnet. Ein Use Case Diagramm erläutert grundsätzlich das Was (also die Funktionalitäten), aber niemals das Wie (also die technische Umsetzung) auf einem möglichst hohen Abstraktionslevel. Durch den hohen Abstraktionslevel und die einfache graphische Notation soll sichergestellt werden, dass nicht nur die Experten (meist Informatiker und Systemarchitekten) verstehen können, was das System können soll, sondern jeder Laie, der sich für das Softwaresystem interessiert, also z. B. Auftraggeber, Manager, Designer und nicht zuletzt auch die späteren Benutzer des Systems.

Bestandteile des Use Case Diagramms

Das Use Case Diagramm besteht aus nur vier verschiedenen Elementen, die durch einfache graphische Symbole repräsentiert werden:

• dem System (die Kiste)
• den Use Cases (die Ellipsen)
• Akteuren (die Strichmännchen)
• Assoziationen (die Verbindungslinien)

Das System ist eine große Kiste, die alle Use Cases enthält. In der Kiste befinden sich alle globalen Funktionalitäten (also Use Cases) in Form von Ellipsen. Use Cases können Beziehungen untereinander haben. Außerhalb der Kiste befinden sich die Benutzer des Systems (also Akteure). Akteure sind immer selbst aktiv ohne von außen angestoßen zu werden. Es ist auch möglich, dass Akteure nicht aus Fleisch und Blut, sondern selbstständige Computerprogramme sind. HAL9000 aus Stanley Kubricks 2001 - Odysee im Weltraum wäre ein solcher Akteur - ein Geldautomat hingegen nicht. Es ist sehr wichtig, zwischen Innen und Außen zu unterscheiden, da wir ja nicht die gesamte Welt modellieren wollen sondern ausschließlich die neuen Anwendungsfälle. Diese Unterscheidung ist auch sehr wichtig, da unser neues Softwaresystem oft Verbindungen zu anderen externen Systemen hat und man sich geeignete Schnittstellen (Interfaces) zu diesen externen Systemen überlegen muss.

Starten wir mit einem einfachen Beispiel. Wir modellieren eine vollautomatische Tankstelle (System Tankstelle) mit drei Anwendungsfällen und einem Akteur Kunde. Die Anwendungsfälle sind immer in sich abgeschlossene globale Funktionalitäten. In unserem Beispiel sind dies Auto waschen, Tanken und Zeitung kaufen. Die drei Funktionalitäten sind in sich abgeschlossen und haben keinerlei Abhängigkeiten zueinander. Der Akteur darf alle drei Funktionalitäten ausführen, darum führen drei Linien (Assoziationen) vom Akteur Kunde zu den Use Cases. Wie man auf der rechten Seite sieht kann man jedes UML Diagramm durch Kommentare (die Notiz mit dem Eselsohr) und eine entsprechende gestrichelte Assoziationslinie kommentieren.