Anwendungsfälle (Use Cases) – Einleitung
Anwendungsfälle (engl. Use Cases) dienen dazu, die nach außen hin sichtbaren Anforderungen an ein System zu beschreiben.1 Hierbei wird die Perspektive der sogenannten Akteure eingenommen, also der Stakeholder, die mit dem System interagieren. Jeder Anwendungsfall beschreibt eine Funktionalität, die das System den beteiligten Akteuren bereitstellen muss, um diesen einen bestimmten Nutzen zu bringen.2
Im Anschluss an die Identifikation der für das DREAM-Projekt relevanten Anwendungsfälle wurden diese in Form von Use-Case-Diagrammen3 dokumentiert. Dieser Diagrammtyp ist insbesondere geeignet, um Use Cases zu organisieren und das Verhalten des zu entwickelnden Systems zu modellieren.
Bei den Use-Case-Diagrammen in DREAM wurden folgende Elemente verwendet:
- Systemkontext: Durch Systemgrenzen in Form von Rechtecken wird der Systemkontext definiert. Das im Folgenden betrachtete System ist jeweils die bzw. eine „DREAM-Lösung“.
- Akteur: Die Akteure – dargestellt als „Strichmännchen“ – interagieren mit dem System. Beteiligte Akteure können sowohl Personen als auch andere Systeme sein.
- Anwendungsfall: Die Anwendungsfälle, die die Interaktion zwischen Akteuren und System beschreiben, werden in den Use-Case-Diagrammen als Ellipsen dargestellt. Alle in AP 2.1 identifizierten Anwendungsfälle sind unterhalb des jeweiligen Diagramms kurz beschrieben.
- Assoziation: Die Verbindung zwischen Akteur und Anwendungsfall wird als Assoziation bzw. Kommunikation bezeichnet. In der Regel ist der Akteur aktiv und stößt den jeweiligen Anwendungsfall an.
- Include-Beziehung: Ein inkludierter Anwendungsfall (gekennzeichnet durch die Beschriftung «einschließen») wird immer ausgeführt, wenn der einbindende Anwendungsfall ausgeführt wird.
- Generalisierung: Anwendungsfälle können – ebenso wie Akteure in einem Use-Case-Diagramm – generalisiert werden, wobei die spezielleren Anwendungsfälle bzw. Akteure alle Eigenschaften vom generelleren Element „erben“. Diese Art der Verbindung, dargestellt durch einen Pfeil wird daher auch „ist-eine-Art-Beziehung“ genannt.
Geri Schneider & Jason P. Winters (1998), Applying Use Cases: A Practical Guide. Addison-Wesley. ↩︎
Martin Glinz (2025), Glossar der Requirements Engineering Terminologie. Version 2.2.0. IREB. ↩︎
Grady Booch, James Rumbaugh, Ivar Jacobson (1999), The Unified Modeling Language User Guide. Addison-Wesley. ↩︎