DHBW Stuttgart, SW-Engineering Oktober 2011 Seite 1 Verhaltensmodellierung mit UML2 Übersicht

DHBW Stuttgart, SW-Engineering Oktober 2011

Seite 1

Verhaltensmodellierung mit UML2 Übersicht


Seite 2



Seite 3



Seite 4

Verhaltensmodellierung mit UML2 Use Case Diagramm

Use Cases (Anwendungsfälle) • zeigen die benötigten Interaktionen zwischen dem System und den Akteuren, die mit

dem System kommunizieren• sind die Grundlage für die Erstellung des Systems (müssen daher vollständig sein!)• sind die Grundlage für das Testen des Systems nach der Erstellung• Zu jedem Anwendungsfall gibt es eine Beschreibung in Textform• Anwendungsfälle können hierarchisch geschachtelt werden.

• 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).


Seite 5

• 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)


Seite 6Christoph 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.


Seite 7

Ü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.



Seite 8

Ü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.



Seite 9

Verhaltensmodellierung mit UML2 Use Case Beschreibung

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 ein Use Case ausreichend beschrieben?

Antwort: Wenn zu jedem Use Case (Funktion) folgende Angaben gemacht werden:

– Auslöser einer Funktion– Input zu einer Funktion– Output einer Funktion– (bei komplexen Inhalten) einzelne

Funktionsschritte– Durchführender

Erweiterung: Statt einzelne Funktionsschritte in Textform anzugeben, kann man auch ein Aktivitätsdiagramm zeichnen.


Seite 10

Verhaltensmodellierung mit UML2 Use Case Beschreibung

Beispiel für einen Use Case

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

Kurzbeschreibung (Ziel): Ware an Kunde geliefertAkteure: Kundensachbearbeiter, Lagersachbearbeiter, BuchhaltungAuslösendes Ereignis: Bestellung des Kunden liegt vorVorbedingung: BestellungNachbedingung (bei Erfolg): Ware ausgeliefert (auch Teillieferungen), Rechnungskopie bei BuchhaltungNachbedingung (bei Fehlerfall): Mitteilung an Kunden, dass nicht lieferbarStandardablauf: 1. Kundendaten abrufen

2. Lieferbarkeit prüfen3. Rechnung erstellen4. Auftrag vom Lager ausführen lassen5. Rechnungskopie an Buchhaltung geben

Erweiterungen: 1a. Kundendaten aktualisierenAlternativen: 1a. Neukunden erfassen

3a. Rechnung mit Nachnahme erstellen3b. Rechnung mit Bankeinzug erstellen


Seite 11

Beispiele für verbesserungsfähige Use Cases:

Verhaltensmodellierung mit UML2 Use Case Beschreibungen


Seite 12

Hier sind die verbesserten Use Cases:- Keine Lösungen (Oberflächen)

beschreiben- Hauptablauf (mit Alternativen)

kennzeichnen- Detaillierung der Daten (Attribute) ins

Klassendiagramm übernehmen

Verhaltensmodellierung mit UML2 Use Case Beschreibungen


Seite 13



Seite 14

Darstellung eines dynamischen Ablaufs

Aufgabe im Projekt:• Geschäftsprozeßmodellierung

• Beschreibung von Use Cases

• Dokumentation der Implementierung einer Operation

Änderungen durch UML 2:

• Aktivitäten unabhängig von Zustandsautomaten

• Petri-Netz-ähnliche Semantik

• Diagrammtyp wird als Aktivität bezeichnet

• Vor- und Nachbedingungen

• Notation der Aktion und des Zustandes vereinheitlicht

• Multiple Startknoten

• Verschiedene End(-knoten)-Semantiken

• Neue Notationselemente

Verhaltensmodellierung mit UML2 Aktivität(sdiagramm)


Seite 15


Elemente

einer

Aktivität:


Seite 16

• Diagrammtyp heißt Aktivität

• Eine Aktivität kann Ein- und Ausgangsparameter besitzen

• Aktionen sind Verhaltensaufrufe

• Summe der Aktionen realisiert die Aktivität

• Beachte: Unterschied zwischen Kontroll- und Objektfluss



Seite 17

Neuer Typ von Endknoten: Ablaufendknoten



Seite 18

Tokenkonzept

• aus den Petri-Netzen übernommen

• Tokenfluss steuert Ablauf einer Aktivität

• Ermöglicht die präzise Beschreibung des Verhaltens

• nur gedankliches Konstrukt (keine explizite Modellierung)



Seite 19

Kontrollelemente

• steuern den Ablauf der Aktivität

• starten und beenden Abläufe

• ermöglichen Nebenläufigkeit

• dienen der Synchronisation

• lassen alternative Abläufe zu

• Kanten haben Kontrollfluß-

Charakter, sie machen keine

Aussage über Datentransport



Seite 20

Notationen für asynchrone Kopplungen:


Exception-Handler:

• Ermöglicht die Beschreibung von Ausnahmen

• Substituiert eine Aktion

Unterbrechungsbereich:

• Beinhaltet eine Menge von Aktionen

• Kann über Unterbrechungskante verlassen werden,

alle Aktionen im Bereich werden dann beendet.


Seite 21


Übung (WebBrokerage):

In einem Anwendungsfalldiagramm zum Thema WebBrokerage ist ein Use case „Auftrag anlegen“ spezifiziert worden. Für den Standardablauf soll ein Aktivitätsdiagramm (Aktivität) modelliert werden, das folgende Aktionen enthält:

„Auftragstyp auswählen“ dient u.a. dazu, zwischen Kauf und Verkauf zu unterscheiden: wenn „Verkauf“ gewählt ist, dann werden die Aktionen „Depotliste anzeigen“ und „Verkaufsobjekt auswählen“ durchgeführt; wenn „Kauf“ ausgewählt ist, dann wird „Kaufobjekt auswählen“ durchgeführt.

Die beiden Kontrollflüsse werden in der Aktion „Stückzahl eingeben“ zusammengeführt.

Wir definieren die eben genannten 5 Aktionen zu einem unterbrechbaren Bereich mit einer Empfangsaktion „Dateneingabe unterbrechen“. Diese dient dazu, den unterbrechbaren Bereich verlassen zu können; dazu muss man einen Kontrollfluss von der Empfangsaktion zum Endknoten „Abbruch“ zeichnen.

Nach der Aktion „Stückzahl eingeben“ folgt die Aktion „Börsenplatz auswählen“, die entweder auf den Endknoten „Auftrag angelegt“ führt oder als zweiter unterbrechbarer Bereich auf den Knoten „Abbruch“ führt. Dazu ist auch hier eine Empfangsaktion zu definieren („Börsenauswahl abbrechen„).


Seite 22

Objektfluss:

• ist gekennzeichnet durch Objektknoten (Rechtecke mit Namen und optional Zustand des Objekts), z.B. die Ein- und Ausgabeparameter

• oder durch Pin‘s bei den Verhaltensaufrufen mit derselben Benennung

• Objektflüsse müssen stets bezeichnet sein



Seite 23

Mengenverarbeitung (Objektfluss)

• Einzelne Betrachtung der Elemente, welche in der restlichen Aktivität nur als Sammlung

betrachtet werden, z.B. Listen, Vektoren, ..

• Elemente werden als Objektknoten (Pin) übergeben:

• Beinhaltet eine Menge von Aktionen



Seite 24

Aktivitätsbereiche

• Teilung des Diagramms

logisch gruppierte Partitionen

• Hierarchische und

mehrdimensionale

Partitionierung möglich

• Beim Wechsel von einem

in den anderen Bereich

sollten die wesentlichen

Objektflüsse eingetragen

werden.



Seite 25


Beispiel aus der Literatur (.):

• “Geldabheben über einen Bankomat.“

• swimlanes Kunde, Automat und Bank, zur Spezifikation der verantwortlichkeiten.

• debit account = Konto belasten


Seite 26


Übung (Online-Banking):

Folgender Ablauf ist in einem Aktivitätsdiagramm mit dem Titel “Dauerauftrag einrichten” darzustellen: Nachdem der Benutzer die Empfängerdaten: Name, Kontonummer und BLZ eingegeben hat, wird vom System geprüft, ob die BLZ korrekt ist; ist die BLZ falsch, muß sie nochmals eingegeben werden, ist sie richtig, gibt der Benutzer den Betrag ein und das Ausführungsintervall. Danach übernimmt das System diesen “neuen” Dauerauftrag und vervollständigt ihn, indem die Daten des Benutzers (Kontonummer und BLZ) dazugefügt werden. Der Benutzer muß dann noch die TAN eingeben, damit der Dauerauftrag, nachdem er vom System abgespeichert wird, in den Zustand aktiv überführt werden kann.

Unterlegen Sie die Aktivitäten mit den zwei Rollen Benutzer und System und tragen Sie zusätzlich in das Aktivitätsdiagramm (als Objektfluss) das Objekt Dauerauftrag (incl. [Zustand]) als Schnittstelle zwischen Benutzer und System ein.


Seite 27



Seite 28

Zustandsdiagramm (STD = state transition diagram) als endlicher Automat:

Alle Ausgangsgrößen lassen sich durch die derzeitigen und vergangenen Eingangsgrößen

herleiten; der somit erforderliche Speicher definiert die Zustände des Automaten.

Verhaltensmodellierung mit UML2 Zustandsautomat allgemein

Zustandsdiagramm enthält vier Basis-Komponenten:• Zustand, repräsentiert durch ein Rechteck (mit abgerundeten Ecken), das den Namen

des Zustands enthält; der Anfangszustand eines STD's ist extra gekennzeichnet.• Zustandsübergang, repräsentiert durch einen Pfeil, dessen Spitze die Richtung des

Übergangs zeigt.• Ereignis, das den Zustandsübergang auslöst• Aktion, die beim Zustandsübergang ausgeführt wird

Folgendes ist möglich:• Ein Zustandsübergang führt wieder zu sich selbst, wenn beim Auftreten des

Ereignisses eine Aktion ausgeführt wird, aber kein Zustandswechsel stattfinden soll.• Ein Zustand wird beim Auftreten des Ereignisses gewechselt, ohne dass eine Aktion

ausgeführt wird.

Syntax: Ereignis / Aktion

oder Ereignis

Aktion


Seite 29

Mit Hilfe des Zustandsdiagramms visualisiert man die verschiedenen Zustände eines Objekts, die es im Laufe seines Lebens einnehmen kann, und die Funktionen, die zu Zustandsänderungen des Objektes führen.

Ein Zustandsdiagramm besteht aus Zuständen (einer davon dient als Anfangszustand) und Zustandsübergängen (Transitionen), die durch ein Ereignis (auch Trigger genannt) - gegebenenfalls mit einer (Wächter-) Bedingung (engl. Guards) kombiniert - ausgelöst werden und selber Aktionen auslösen können:

Ereignis [Bedingung] / Aktion.

Verhaltensmodellierung mit UML2 Zustandsautomat

Zustand3

entry / Aktivität5exit / Aktivität6

Zustand0

Zustand2

Ereignis1 / Aktion1

Ereignis3 [Bedingung]

Ereignis2 / Aktion4

Ereignis4

Implizites Ereignis

Anfangs-zustand

Endzustand (optional) Transition

Zustand1

entry / Aktivität2do / Aktivität3


Seite 30

Beschreibung von Zuständen:

Zustände werden durch Zustandsvariable und (Zustands-)Aktivitäten beschrieben

– Zustandsvariable (Attribute der Klasse) haben das Format: variable : klasse = initialwert {merkmal} {zusicherung}

– Zustandsaktivitäten (interne Aktivitäten) können sein:• Entry-Aktivität: nichtunterbrechbare Aktivität beim

Eintreten in den Zustand• Exit-Aktivität: nichtunterbrechbare Aktivität beim

Verlassen des Zustands• Do-Aktivität: unterbrechbare Aktivität mit und ohne

definiertem Ende; das Beenden einer do-Aktivität kann zu einem Zustandswechsel führen, so dass bei der Transition ein Ereignis nicht explizit angegeben werden muss (implizites Ereignis).

• Verzögerte Ereignisse• defer gibt an, dass ein Ereignis nicht im aktuellen

Zustand verarbeitet werden kann, jedoch im nachfolgenden Zustand eine Rolle spielen könnte.



Seite 31

Zusammengesetzter Zustand: Setzt sich aus Zuständen, Pseudozuständen und Transitionen zusammen, steht stellvertretend für einen vollständigen Zustandsautomaten und kann Ein- und Austrittspunkte besitzen



Seite 32

• Zustände können in verschiedene sequentielle oder parallele Unterzustände aufgeteilt werden, wenn es nötig ist, Ereignisse innerhalb eines Zustandes eines Objektes näher zu untersuchen (Die Notation von Unterzuständen ist gleich denen von Zuständen):



Seite 33

Beschreibung von Zustandsübergängen:

Es existieren verschiedene Formen von Ereignissen:– Empfangsereignis (signal/call event): Empfang von (Aufruf)Nachrichten

(Operationsrufe) als asynchrone/synchrone Signale, zumeist mit Übername von Parametern

– Zeitereignis (time event) definiert mittels eines relativen (after) oder absoluten (when) Zeitpunkts, zu dem die Transaktion ausgelöst werden soll

– Zustandsereignis (change event) als Änderung von beobachteten Datenwerten (logischer Ausdruck, z.B. [number < 10]), im englischen „guard“ (Wächter).

Aktionen beinhalten in der Regel das Senden von Nachrichten („Ausgangsereignisse“) an andere Klassen

Eine Transition feuert nur dann, wenn das zugehörende Ereignis eintritt UND die im Wächter spezifizierte Bedingung erfüllt ist (in den Zustand TRUE wechselt)

Bei einem impliziten Ereignis wird die Transition ausgeführt, wenn die dem Zustand verbundene Verarbeitung beendet ist (i.d.R. eine do-Aktivität).



Seite 34

Beispiele von Zustandsübergängen:



Seite 35

Pseudozustände:



Seite 36

Pseudozustände:



Seite 37

Beispiele

für

Pseudo-

zustände:



Seite 38

Beispiel:• Trigger (Ereignis) und

Guard (Wächterbedingung) können gemeinsam oder alleine stehen

• Kreuzungspunkte ermöglichen das Hintereinanderschalten verschiedener Transitionen ohne verbindende Zustände

• Interne Aktivitäten können durch Bedingungen erweitert werden

• Interne Aktivitäten werden häufig als „Zustandsverhalten“ bezeichnet



Seite 39

Aktivitäten und Ereignisse sind nicht streng unterschieden.

An den Transitionen fehlen Ereignisse (ggfs. mit Wächtern)


Nebenstehendes Zustandsdiagramm hat Fehler.

Übung: Korrigieren sie bitte.


Seite 40


Lösung der Übungsaufgabe


Seite 41


Übung: Zustandsautomat für eine Digitale Armbanduhr

Eine einfache digitale Armbanduhr hat eine Anzeige und zwei Knöpfe, um die Uhr

zu stellen (Knopf A und Knopf B). Die Uhr hat zwei Betriebsarten:

Zeit anzeigen und Zeit einstellen.

Im Modus Zeit anzeigen werden die Stunden und Minuten angezeigt.

Sie sind durch einen blinkenden Doppelpunkt voneinander getrennt.

Im Modus Zeit einstellen gibt es die Untermodi Stunden einstellen und Minuten einstellen. Mit Knopf A

werden die Modi gewählt. Mit jedem Drücken des Knopfes wird der nächste Modus eingeschaltet.

Dabei gilt die Reihenfolge: anzeigen, Stunden einstellen, Minuten einstellen, anzeigen, usw.

In den Untermodi werden durch Drücken von Knopf B die Stunden oder Minuten jeweils um eine Einheit

vorgestellt. Die Knöpfe müssen losgelassen werden, bevor sie ein anderes Ereignis veranlassen können.

Zeichnen Sie ein Zustandsdiagramm der Uhr, indem Sie die drei Zustände

Zeit anzeigen, Stunden einstellen und Minuten einstellen verwenden.


Seite 42

Lösung der Übung Digitale Armbanduhr



Seite 43

Übung: Der Automat soll gestartet werden und anschließend, nach dem Betreten von Links.Zustand1, schrittweise die Eingabesequenz

A,B,C,B,A,X,Y,Z,Y,X,P,Q verarbeiten. Vollziehen Sie die Ausführung des Automaten nach und notieren Sie die Ausgaben,

die während der Ausführung produziert werden, in der korrekten Reihenfolge.

Tipp: Die Bedingung in <name> prüft, ob der Zustand <name> aktiv ist.

VerhaltensmodellierungZustandsautomat


Seite 44


Lösung der Übung „Pizzeria“:

00:00:00 Margerita00:00:00 Roma00:00:00 Hawaii00:00:03 Tonno00:00:07 Funghi00:00:09 Hawaii00:00:12 Tonno00:00:15 Salami00:00:15 Diavolo00:00:21 Speciale00:00:23 Calzone00:00:26 FruttiDiMare00:00:26 Margerita00:00:26 Roma


Seite 45


Übung:


Seite 46


Lösung der Übung flaches Diagramm:

Ein Oberzustand wird verlassen, wenn in jeder Region ein Endzustand erreicht ist oder wenn eine Transition direkt nach außen führt.

Documents

DHBW Stuttgart, SW-Engineering Oktober 2011 Seite 1 Verhaltensmodellierung mit UML2 Übersicht