Diagrammtyp
Verhaltensdiagramm.
Anwendungsfälle
-
Sequenz von Transaktionen innerhalb eines Systems
-
erzeugt für einzelnen Anwender einen identifizierbaren Nutzen
-
Transaktionen implizieren, dass dem User die Kommunikation mit dem System möglich ist.
-
messbarer Nutzen ⇒ Ausführung einer Transaktion hat Auswirkung auf Dinge außerhalb des Systems (speziell dem Akteur)
Notationselemente
System
Was wird beschrieben?
Abgrenzung von der Umwelt
Akteur
Wer benutzt das System?
- repräsentiert Rolle eines Benutzers des Systems
- ==ist niemals selbst im System==, sondern klar außerhalb
- Interaktionsmöglichkeiten
- Akteur benutzt das System (steht links) → aktiv
- Akteur wird vom System benutzt (steht rechts im Diagramm) → passiv
mehrere Akteure gleichen Typs können mit Multiplizitätsnummer an Akteurssymbol gekennzeichnet werden
Klassifikation der Akteure
- menschlich
- nicht-menschlich
- primär
- sekundär
- aktiv
- passiv
Anwendungsfall
Was machen die Akteure?
- beschreibt Verhalten, welches vom System erwartet wird
- Notation: Ellipse mit Text
- Kurzbeschreibung als Notiz möglich
Beziehungen
Best Practice
Bei include- und extends-Beziehung wird der Akteur nur mit dem Haupt-Use-Case verbunden
<<include>> Beziehung
Einbindung
Das Verhalten des benutzten Anwendungsfalls wird zwingend in den aktuellen Anwendungsfall eingebunden.
Example
- B ist unbedingt notwendig, um die Funktionalität von A sicher zu stellen
- B kann seperat ausgeführt werden
<<extends>> Beziehung
Einbindung
Das Verhalten des benutzten Anwendungsfalls kann in den aktuellen Anwendungsfall eingebunden werden.
Example
- B kann von A aktiviert werden, muss aber nicht
- A bzw. B können seperat ausgeführt werden
Generalisierung
- B erbt das Verhalten von A und kann dieses überschreiben oder ergänzen
- B erbt alle Beziehungen von A
- B benötigt A (übernimmt Grundfunktionalität von A)
- B entscheidet, was von A ausgeführt bzw. geändert wird
- Modellierung abstrakter Anwendungsfälle möglich: {abstract} abstrakte Anwendungsfälle sind nicht ausführbar!
- Akteur A erbt von Akteur B
- A kann mit den Anwendungsfällen X und Y kommunizieren
- B kann nur mit Y kommunizieren
- Mehrfachvererbung ist erlaubt
Aufgabe: Use Case Puzzle
03.04.2025
Anwendungsfallbeschreibung
Identifikation von Akteuren
- Wer benutzt die wesentlichen Anwendungsfälle?
- Wer braucht Systemunterstützung für die tägliche Arbeit?
- Wer ist für die Systemadministration zuständig?
- Mit welchen externen Geräten / (Software-)Systemen muss das System kommunizieren können?
- Wer oder was interessiert sich für die Ergebnisse des Systems?
Identifikation von Anwendungsfällen
- Nach der Identifikation der Akteure
- Trigger für Anwendungsfälle suchen
- Trigger = Ereignisse, die eintreten müssen, damit das System veranlasst wird ein Ergebnis zu produzieren.
- Der Aufruf des Systems erfolgt oft durch einen Akteur, der damit Akteur des Anwendungsfalles wird.
- Es werden folgende Trigger unterschieden: interne, externe und zeitliche Trigger.
Regeln zur Anwendungsfallmodellierung
Die wichtigsten funktionalen Anforderungen müssen in den Anwendungsfällen festgehalten werden
Iteratives Vorgehen
- zunächst sind Anwendungsfälle bei der Anforderungserhebung entstehend Grundlage für Folgeentwicklung, aber können dann im Laufe des Prozesses bei Bedarf angepasst bzw. erweitert werden
Typische Modellierungsfehler
- Akteur “Mitarbeiter” ist im System
- System fehlt, Use Cases sind zu detailliert beschrieben
- “Kalender aktualisieren” und “Teilnehmer verstaendigen” hängen nicht per include zusammen, da nicht mit jeder Aktualisierung eine Benachrichtigung der Teilnehmer mit einher geht
- Diagramm kann durch abstrakte Klassen/Generalsierung vereinfacht werden
- Anwendungsfälle sind zu detailliert und können zusammengefasst werden
- Einezelschritte eines Anwendungsfalls einzeln modelliert, richtig wäre die Zusammenfassung in einem Anwendungsfal
Modellierungsfehler in Use Case Diagramm finden - Schema
- System vorhanden?
- Akteur außerhalb des Systems?
- UseCase innerhalb des Systems?
- Detailgrad des Diagramms angemessen?
Weiterführend