use case diagram - dhbw stuttgartrie/aswe/aswe31 usecases.pdf · struktur und dynamisches verhalten...

DHBW Stuttgart, Informatik, Advanced SW-Engineering Sep 2016

Seite 1

UMLUse Case Diagram

• Einführung

• Anforderungen an die UML-Diagramme

• Use Case Diagram

• Activity Diagram

• State Diagram

• Use-Case-Diagramm

• Use Casses


Seite 2

In der Systemanalyse wird aus den

fachspezifischen Anforderungen das

Systemmodell erstellt; im

Systemmodell ist spezifiziert, was das

System leisten soll, d.h. statische

Struktur und dynamisches Verhalten

sind vollständig beschrieben.

In der Systementwicklung wird aus

dem Systemmodell und den IT-

spezifischen Anforderungen das

Software-System erstellt; das

Software-System beschreibt, wie die

Anforderungen umgesetzt wurden

UMLUse Case Diagram


Seite 3

Methodische Gliederung Komponenten Diagramm (UML 2)

Verhaltensmodellierung

(dynamisch)

Ereignisse

Kontrollfluss (Ablauf)

Zustandsübergänge

Use-Case-Diagramm

Aktivitätsdiagramm

Zustandsautomat

Strukturmodellierung

(statisch)

Daten (–Strukturen)

Schnittstellen (Kontext)

Funktionen

Datenfluss

Klassendiagramm

Aktivitätsdiagramm (nur

Parameter/Objektfluß)

UML ist die Notation für die OOA. Mit den UML-Diagrammen gliedert sich das

Systemmodell in zwei Aspekte: (dynamische) Verhaltensmodellierung und (statische)

Strukturmodellierung, für deren Beschreibung vier UML-Diagramme zuständig sind.

UMLUse Case Diagram


Seite 4

Anforderungen an die UML-Diagramme für die SW-Entwicklung:

Vollständigkeit der OOA

• Kontext, d.h. externe Schnittstellen

• Funktionshierarchie

Konsistenz zwischen den Diagrammen

• Aktoren und Swimlanes

• Parameter und Klassen

• Ereignisse und Klassen

• Use Cases und Aktionen bzw Aktivitäten

Verständlichkeit für die unterschiedlichen Nutzer

• Komplexität einer Aktivität

• Beschreibungsmöglichkeiten in einem Diagramm

UMLUse Case Diagram


Seite 5

UMLUse Case Diagram


Seite 6

UMLUse Case Diagram


Seite 7

UMLUse Case Diagram


Seite 8

Anwendung im Projekt

• Use Case Diagramm liefert die funktionelle Gliederung in form von Anwendungsfällen in der 1.

Gliederungsebene; weitere Gliederungsebenen werden durch Aktivitätsdiagramme visualisiert

• Use Cases liefern den Kontext, d.h. sie beschreiben alle Systemgrenzen (externe Schnittstellen)

• Use Cases stellen keine objektorientierte Sicht auf das System dar, sondern beschreiben die

funktionellen Anforderungen aus Anwendersicht (was statt wie) (und Entwicklersicht)

• Verständlichkeit wird erreicht durch:

– Sparsame Verwendung der include- und extend-Beziehungen

– Vorgabe eines Templates zur textuellen Beschreibung der Use Cases

Zu beachten

• Akteure (actors) werden nur dann eingeführt, wenn sie direkt mit dem System (inter-)agieren, d.h.

aktiv beteiligt sind; es gibt somit nicht nur menschliche Akteure!

• Schnittstellen nach außen werden in den Aktivitätsdiagrammen als Ein- und Ausgabeparameter

spezifiziert

• Für eine detaillierte(re) Spezifikation der Daten steht das Klassendiagramm zur Verfügung

• Bei einem gleichwertigen Auftreten von Abfolgen und Ereignissen im Use Case empfiehlt es sich,

einen Zustandsautomaten zur Beschreibung hinzuzufügen

UMLUse Case Diagram


Seite 9

• Das Use Case Diagramm hält fest, was Akteure/Aktoren, die sich außerhalb des

Systems befinden) vom System erwarten. Es bildet des externe Verhalten des System

ab. Es enthält die grafische Darstellung der Use Cases (Anwendungsfälle).

• Use Cases helfen, das System in logische Teile (planbare Einheiten) zu gliedern und

liefern die Schnittstellen, so dass sie auch als Grundlage für das Testen des Systems

nach der Erstellung bieten

• Notation: Anwendungsfälle werden durch Ellipsen, die den Namen des

Anwendungsfalles - möglichst als Verb - tragen, und einer Menge von beteiligten

Objekten (Akteure, häufig als Strichmännchen gezeichnet), die den Namen ihrer Rolle

tragen. dargestellt. Zwischen den Anwendungsfällen existieren Kommunikations-

Beziehungen, die durch Linien dargestellt werden, spezielle Beziehungen sind:

– <<extend>>-Beziehung,

– <<include>>-Beziehung (ersetzt die <<uses>>-Beziehung aus der UML1.1)

– Generalisierungsbeziehung (seit UML 1.3).

UMLUse Case Diagram


Seite 10

• Kommunikationsbeziehungen

(einfache Striche) werden

nicht benannt

• <<extend>>Beziehung sagt,

daß der Use Case

“Anmelden” durch den Use

Case “Kontozugang sperren”

(unter bestimmten

Umständen, siehe [ ] im

Diagramm) erweitert wird

(extension point)

• <<include>>Beziehung sagt,

daß der Use Case

“Abmelden” den Use Case

“BLZ überprüfen” enthält

• Der use case “BLZ

überprüfen“ gehört originär

zum Paket “Auskunft”

Beispiel mit dem Case-Tool Innovator:

• Paket “Verwaltung” dient zur Gruppierung (Systemgrenze)

UMLUse Case Diagram


Seite 11Christoph Riewerts

Beispiel für eine Generalisierung (Innovator):Ebenfalls ist die Generalisierung

zwischen den Akteuren

eingezeichnet. Für den Prozeß

der Reservierung bedeutet das,

daß entweder der

Reservierungswunsch direkt vom

Kunden im Anwendungsfall Kfz

online reservieren bearbeitet wird

oder daß der

Reservierungswunsch vom Call-

Center-Agenten (im Falle Kfz

telefonisch reservieren) oder vom

Niederlassungsmitarbeiter (im

Falle Kfz persönlich reservieren)

weitergeleitet wird (leider ist

diese Datenschnittstelle

Reservierungswunsch im

Diagramm nicht sichtbar).

Es existieren drei (konkrete) Anwendungsfälle, die eine

Spezialisierung des abstrakten Anwendungsfalles Kfz

reservieren darstellen.

UMLUse Case Diagram


Seite 12

Übung (Flugbuchung):

Der Anwendungsfall “Buchen eines Fluges” verwendet die zwei Use Cases “Beratung” und

“Rechnung ausdrucken”. Eine Beratung wird jedoch nur in Ausnahmefällen durchgeführt,

während der Anwendungsfall “Rechnung ausdrucken” von allgemeiner Natur sein soll

und somit auch von weiteren Use Cases benutzt werden kann.

Entwerfen Sie ein

Anwendungsfall-Diagramm.

UMLUse Case Diagram


Seite 13

Übung (Bibliothekssystem):

Für ein Bibliothekssystem sind folgende Anwendungsfälle zu spezifizieren: Buch ausleihen,

Buch vormerken, Buch zurückgeben, Buch inventarisieren, Buch suchen. Sollte ein

Kunde zur Benutzung der Bibliothek noch nicht berechtigt sein, müssen seine

Kundendaten aufgenommen werden.

Definieren Sie die notwendigen Akteure und stellen Sie ein Use Case Diagramm auf.

UMLUse Case Diagram


Seite 14

Use case Titel: ___________________

Nummer: ………

Kurzbeschreibung (Ziel): ………

Akteure: ………

Auslösendes Ereignis: ………

Vorbedingung: ………

Nachbedingung (bei Erfolg / bei Fehlerfall):

Standardablauf (Abfolge der Aktionen):

1.

2.

3.

……..

Wann ist eine Funktion ausreichend

beschrieben?

Antwort: Wenn zu jeder Funktion folgende Angaben

gemacht werden:

– Auslöser einer Funktion

– Input zu einer Funktion

– Output einer Funktion

– (bei komplexen Inhalten) einzelne

Funktionsschritte

– Durchführender

Der Standardablauf wird in der Regel als

Aktivitätsdiagramm gezeichnet, da wir bei

umfangreichen Use Cases die Ein- und

Ausgabeparameter der Aktionen explizit

benötigen.

UMLUse Case Diagram


Seite 15

Beispiel für einen Use Case

Use Case Titel: Auftrag ausführen Nummer: FREQ 21

Kurzbeschreibung (Ziel): Ware an Kunde geliefert

Akteure: Kundensachbearbeiter, Lagersachbearbeiter, Buchhaltung

Auslösendes Ereignis: Bestellung des Kunden liegt vor

Vorbedingung: Bestellung

Nachbedingung (bei Erfolg): Ware ausgeliefert (auch Teillieferungen), Rechnungskopie bei

Buchhaltung

Nachbedingung (bei Fehlerfall): Mitteilung an Kunden, dass nicht lieferbar

Standardablauf: 1. Kundendaten abrufen

2. Lieferbarkeit prüfen

3. Rechnung erstellen

4. Auftrag vom Lager ausführen lassen

5. Rechnungskopie an Buchhaltung geben

Erweiterungen: 1a. Kundendaten aktualisieren

Alternativen: 1a. Neukunden erfassen

3a. Rechnung mit Nachnahme erstellen

3b. Rechnung mit Bankeinzug erstellen

UMLUse Case Diagram


Seite 16

Beispiele für verbesserungsfähige Use Cases:

UMLUse Case Diagram


Seite 17

Hier sind die verbesserten Use Cases:

- Keine Lösungen (Oberflächen)

beschreiben

- Hauptablauf (mit Alternativen)

kennzeichnen

- Detaillierung der Daten (Attribute) ins

Klassendiagramm übernehmen

UMLUse Case Diagram


Seite 18

Übung Flugbuchung Seite 12:

UMLUse Case Diagram


Seite 19

Übung (Bibliothekssystem) Seite 13

UMLUse Case Diagram

use case diagram - dhbw stuttgartrie/aswe/aswe31 usecases.pdf · struktur und dynamisches verhalten...

Documents