UML (Unified Modeling Language) Anwendungsfalldiagramm

🎯 Lernziele

Nach dieser Einheit sind Sie in der Lage dazu

• Anwendungsfälle mittels UML-Anwendungsfalldiagramm
• und Use Case Template zu beschreiben

🧠 Anwendungsfall / Use Case

• Ebenfalls textuelle Beschreibung aus Perspektive einer Rolle
• Use Case Beschreibungen geben mehr Kontext zur Interaktion und stellen im Gegensatz zur User Story einen ganzen Ablauf dar, der zur erfolgreichen Anwendung des Produktes gehört
• Standardisierten Darstellung nach Alistair Cockburn (nächste Seiten)

🧠 UML (Unified Modeling Language) Anwendungsfalldiagramm

• UML ist eine Modellierungssprache zur Spezifikation, Konstruktion, Dokumentation und Visualisierung von Software-Teilen durch verschiedene Werkzeuge
• Anwendungsfalldiagramm stellt das erwartete Verhalten eines Systems dar (Wer kann was mit dem System machen?)

• Akteure z.B. Kund:innen oder Administrator:innen aber auch ein anderes System
• Anwendungsfälle als Ellipsen. Beschreibung z. B. in einem Kommentar oder als Tabelle
• Assoziationen zwischen Akteuren und Anwendungsfällen (Linien)
• Systemgrenzen werden durch Rechtecke gekennzeichnet.

Beispiel

• Benutzer:in ist an vier Anwendungsfällen interessiert, die ihrerseits in Beziehung stehen.
• Musik-CD erstellen besteht aus zwei anderen Anwendungsfällen <includes> und kann optional durch einem dritten erweitert werden <extends>

🧠 Unterschied <include> und <extends>

• <include> Teilaspekt eines Anwendungsfall, der immer umgesetzt werden muss, um den übergeordnetem Anwendungsfall zu erfüllen

• <extends> optionale Erweiterung eines Anwendungsfalls

• (Quizfrage auf Sakai beantworten) <-extends- (Antwort mit ChatGTP finden)

• (Quizfrage auf Sakai beantworten) -includes-> (Auf Sakai anmelden)

Fallstudie Leistungsdiagnostik

• Leistungstest zu Diagnose
  • Erbrachte Leistung z.B. getretene Watt
  • Physiologische Daten z.B. EKG, Herzrate, Hautleitwert, Luftsauerstoff
• Perspektiven: Beteiligte Personen
  • Diganostiker:in
  • Versuchsperson
• Beschränkungen
  • im Beispiel gesamte Steuerung des Ergometers vernachlässigt

🤓 Anwendungsfall Leistungsdiagnostik

🤓 Anwendungsfall Leistungsdiagnostik

🤓 Anwendungsfall Leistungsdiagnostik

🤓 Anwendungsfall Leistungsdiagnostik

Beschreibung der Funktionalen Anforderungen mittels User Stories:

Es soll eine Software entwickelt werden, die einen standardisierten Leistungstest (z.B. Stufentest) mittels Ergometer ermöglicht.

- Als Diagnostiker:in möchte ich Name und Geburtsdatum eingeben, um neue Patient:innen anzulegen
- Als Diagnostiker:in möchte ich zwischen zwei verschiedenen Tests auswählen um verschiedenen Programme zu starten
    - Konstante Leistung in Watt und Dauer (Manuelle Eingabe beider Werte)
    - Standardisierter Stufentest, bei dem die Leistung nach einer festen Zeit erhöht wird
- Als Diagnostiker:in möchte ich die automatisch erfassten Werte (Herzfrequenz, Leistung, Kadenz) angezeigt bekommen, 
um Auffälligkeiten zu erkennen
- Als Diagnostiker:in möchte ich (optional) gemessene Laktatwerte zu beliebigen Zeitpunkten eintragen, um diese mit dem Test zu verknüpfen
- Als Diagnostiker:in möchte ich bei Überschreiten eines Maximalpulses oder Abweichen von der vorgegeben Leistung eine Warnung angezeigt bekommen,
 um den Test abbrechen zu können
- Als Diagnostiker:in möchte ich den Durchlauf abbrechen (optional)
- Als Proband:in möchte ich eine Auswahl treffen, um die wahrgenommene Anstrengung an Ende des Tests mittels BORG-Skala zu bewerten

Borg Skala

✍️ Aufgabe 1: Use-Case Diagramm

• zeichnen Sie eine Use-Case Diagramm, welches die folgenden Anwendungsfälle abbildet:

  • UC 1.00 - Leistungsdiagnostik
    • UC 1.01 (Probandin anlegen),
    • UC 1.02 (Leistungstest anlegen),
    • UC 1.03 (Alarm bei zu hoher Herzfrequenz),
    • UC 1.04 (Alarm bei Leistungsabweichung),
    • UC 1.05 (Laktatmessung eingeben)
    • UC 1.06 (Anstrengungsbewertung mittels BORG-Skala durch Proband:in)
    • UC 1.07 (Abbruch des Leistungstests)

• Nutzen Sie dabei die includes und extends Syntax

• diagrams.net

✍️ Aufgabe 2: Aktivitätsdiagramm oder Flow Chart

• Fertigen Sie ein Aktivitätsdiagramm des UC 1.00 - Leistungsdiagnostik an. Hierbei sollen UC 1.01, UC 1.02, UC 1.05, UC 1.06, und UC 1.07 abgedeckt werden
• Der Start kann durch eine Box Neuer Patient gekennzeichnet werden
• Das Die möglichen Endzustände können durch die beiden Boxen Test abgeschlossen und Test abgebrochen beschrieben werden
• mermaid.live

✔️ Lösungen

graph TD
    A[Neuer Patient] --> B(Patient anlegen)
    B(Patient anlegen) --> C(Leistungstest anlegen)
    C(Leistungstest anlegen) --> D(Leistungstest startet)
    D(Leistungstest startet) --> E{Leistungstest überwachen}
    E{Leistungstest überwachen} --> F(Laktatwert eingeben)
    F(Laktatwert eingeben) --> E{Leistungstest überwachen}
    E{Leistungstest überwachen} -->|Zeit abgelaufen| G[Aufzeichnung abgeschlossen]
    E{Leistungstest überwachen} -->|Test abbrechen| H[Test abgebrochen]
    G[Aufzeichnung abgeschlossen] --> I(Intensität eingeben)
    I(Intensität eingeben) --> K[Test abgeschlossen] 

Quelle

🏆 Sakai-Aufgabe 2: Beschreibung im Use Case Template

• Folgende Aufgabe können Sie zu zweit bearbeiten, laden Sie jedoch dennoch beide das Ergebnis (Link zum Repository) in Sakai hoch
• beschreiben Sie einen der Anwendungsfälle UC 1.01 - UC 1.07 mithilfe des Use Case Templates
• Sie müssen hierfür keine Tabelle anlegen, sondern können die einzelnen Abschnitte in einem Text mit Überschriften zusammenfassen
• Legen Sie sich dazu einen github-Account an, wenn sie sich als Studierende registrieren, können Sie später auch GitHub Copilot nutzen
• Eine Personen erstellt dann ein neues Repository und lassen Sie dieses public und setzen Sie ein Häkchen bei Add a README file
• fügen das andere Gruppenmitglied unter Settings, Collaborators: https://github.com///settings/access) hinzu

• Editieren Sie die README.md und fügen Sie die Beschreibung ein
• Die Datei ist eine Markdown-Datei, die Sie mit dieser Anleitung formatieren können
• Gehen Sie auf Projects und Link a project erstellen Sie ein neues Team Planning Projekt
• Legen Sie drei User Stories für den Use Case als Karte auf dem Kanban-Board an und weisen Sie diesen einer Person zu

• Legen Sie auch eine Text-Datei leistungstest.py an und kopieren Sie den Code aus der letzten Aufgabe hinein
• Als Abgabe reichen Sie den Link zu Ihrem Repository ein
• Wenn Sie sich bei github als Studierende registrieren, können Sie später z.B. auch GitHub Copilot nutzen

🤓 Appendix

🤓 Aufbau Lastenheft

• DIN-Vorschrift 69905 (Begriffe der Projektabwicklung).
• IEEE-Standard Software Requirements Specification

🤓 Aufbau Pflichtenheft

• DIN 69901-5: "vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts"
  • Ein- und Ausschlussprinzip
  • Abnahmekriterien
  • Entwurf:
    • Technische Umsetzung
    • Softwarearchitektur

🤓 Discussion Summary

• Anstelle eines Lasten und Pflichtenhefts
• Gemeinsames Dokument von Auftragnehmer und -geber:in
• Vorgehen macht vor allem auch dann Sinn, wenn es keine Auftraggeber:in gibt (eigene Projekte)

Discussion Summary outline
1. Project background
    a) Purpose of project                       # Zielbeschreibung
    b) Scope of project                         # Abgrenzung und Zielerreichungskriterien
    c) Other background information             # Bestehende System, Vorgeschichte, etc.
2. Perspectives
    a) Who will use the system?                 # Rollen und Persona
    b) Who can provide input about the system?  # Gesprächspartner mit Kontaktdaten
3. Project Objectives
    a) Known business rules                     # Bestehende Abläufe mit denen das System interagiert
    b) System information and/or diagrams       # Anwendungsfälle, Systemarchitektur
    c) Assumptions and dependencies             # Unsicherheiten und Abhängigkeiten (z.B. Einsatz bestimmter Hard und Software)
    d) Design and implementation constraints    # Bestimmte Technologien, Must-Haves, etc.
4. Risks                                    # Mögliche Risiken
5. Known future enhancements                # Sammlung von Ideen außerhalb des System Scopes
6. References                               # Quellensammlung
7. Open, unresolved or TBD issues           # Alternative auf Kanban Board o.ä.

Werkzeuge zum Beschreiben der Softwarearchitektur im Entwurf

• häufig nicht formalisiert
• Whiteboard, Stift, Papier
• Inklusion verschiedener Stakeholder wichtiger als Formalismus
• häufig ausgehend vom Nutzerinterface

Quelle