Verhaltensmodellierung mit UML2 Übersicht

Präsentation zum Thema: "Verhaltensmodellierung mit UML2 Übersicht"—  Präsentation transkript:

1 Verhaltensmodellierung mit UML2 Übersicht

2 Verhaltensmodellierung mit UML2 Übersicht

3 Verhaltensmodellierung mit UML2 Übersicht

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

5 Verhaltensmodellierung mit UML2 Use Case Diagramm
Beispiel mit dem Case-Tool Innovator: Paket “Verwaltung” dient zur Gruppierung (Systemgrenze) 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”

6 Verhaltensmodellierung mit UML2 Use Case Diagramm
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. Christoph Riewerts

7 Verhaltensmodellierung mit UML2 Use Case Diagramm
Ü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.

8 Verhaltensmodellierung mit UML2 Use Case Diagramm
Ü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.

9 Verhaltensmodellierung mit UML2 Use Case Beschreibung
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. Use case Titel: ___________________ Nummer: ……… Kurzbeschreibung (Ziel): ……… Akteure: ……… Auslösendes Ereignis: ……… Vorbedingung: ……… Nachbedingung (bei Erfolg / bei Fehlerfall): Standardablauf (Abfolge der Aktionen): 1. 2. 3. ……..

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

11 Verhaltensmodellierung mit UML2 Use Case Beschreibungen
Beispiele für verbesserungsfähige Use Cases:

12 Verhaltensmodellierung mit UML2 Use Case Beschreibungen
Hier sind die verbesserten Use Cases: Keine Lösungen (Oberflächen) beschreiben Hauptablauf (mit Alternativen) kennzeichnen Detaillierung der Daten (Attribute) ins Klassendiagramm übernehmen

13 Verhaltensmodellierung mit UML2 Übersicht

14 Verhaltensmodellierung mit UML2 Aktivität(sdiagramm)
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

15 Verhaltensmodellierung mit UML2 Aktivität(sdiagramm)
Elemente einer Aktivität:

16 Verhaltensmodellierung mit UML2 Aktivität(sdiagramm)
• 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

17 Verhaltensmodellierung mit UML2 Aktivität(sdiagramm)
Neuer Typ von Endknoten: Ablaufendknoten

18 Verhaltensmodellierung mit UML2 Aktivität(sdiagramm)
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)

19 Verhaltensmodellierung mit UML2 Aktivität(sdiagramm)
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

20 Verhaltensmodellierung mit UML2 Aktivität(sdiagramm)
Notationen für asynchrone Kopplungen: Unterbrechungsbereich: • Beinhaltet eine Menge von Aktionen • Kann über Unterbrechungskante verlassen werden, alle Aktionen im Bereich werden dann beendet. Exception-Handler: • Ermöglicht die Beschreibung von Ausnahmen • Substituiert eine Aktion

21 Verhaltensmodellierung mit UML2 Aktivität(sdiagramm)
Ü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„).

22 Verhaltensmodellierung mit UML2 Aktivität(sdiagramm)
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

23 Verhaltensmodellierung mit UML2 Aktivität(sdiagramm)
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

24 Verhaltensmodellierung mit UML2 Aktivität(sdiagramm)
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.

25 Verhaltensmodellierung mit UML2 Aktivität(sdiagramm)
Beispiel aus der Literatur (.): “Geldabheben über einen Bankomat.“ swimlanes Kunde, Automat und Bank, zur Spezifikation der verantwortlichkeiten. debit account = Konto belasten

26 Verhaltensmodellierung mit UML2 Aktivität(sdiagramm)
Ü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.

27 Verhaltensmodellierung mit UML2 Übersicht

28 Verhaltensmodellierung mit UML2 Zustandsautomat allgemein
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. 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 Syntax: Ereignis / Aktion oder Ereignis Aktion 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.

29 Verhaltensmodellierung mit UML2 Zustandsautomat
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. Anfangs-zustand Zustand1 entry / Aktivität2 do / Aktivität3 Ereignis1 / Aktion1 Zustand0 Implizites Ereignis Endzustand (optional) Transition Zustand3 entry / Aktivität5 exit / Aktivität6 Ereignis3 [Bedingung] Ereignis4 Zustand2 Ereignis2 / Aktion4

30 Verhaltensmodellierung mit UML2 Zustandsautomat
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.

31 Verhaltensmodellierung mit UML2 Zustandsautomat
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

32 Verhaltensmodellierung mit UML2 Zustandsautomat
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):

33 Verhaltensmodellierung mit UML2 Zustandsautomat
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).

34 Verhaltensmodellierung mit UML2 Zustandsautomat
Beispiele von Zustandsübergängen:

35 Verhaltensmodellierung mit UML2 Zustandsautomat
Pseudozustände:

36 Verhaltensmodellierung mit UML2 Zustandsautomat
Pseudozustände:

37 Verhaltensmodellierung mit UML2 Zustandsautomat
Beispiele für Pseudo- zustände:

38 Verhaltensmodellierung mit UML2 Zustandsautomat
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

39 Verhaltensmodellierung mit UML2 Zustandsautomat
Nebenstehendes Zustandsdiagramm hat Fehler. Aktivitäten und Ereignisse sind nicht streng unterschieden. An den Transitionen fehlen Ereignisse (ggfs. mit Wächtern) Übung: Korrigieren sie bitte.

40 Verhaltensmodellierung mit UML2 Zustandsautomat
Lösung der Übungsaufgabe

41 Verhaltensmodellierung mit UML2 Zustandsautomat
Ü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.

42 Verhaltensmodellierung mit UML2 Zustandsautomat
Lösung der Übung Digitale Armbanduhr

43 Verhaltensmodellierung Zustandsautomat
Ü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.

44 Verhaltensmodellierung Zustandsautomat
Lösung der Übung „Pizzeria“: 00:00:00 Margerita 00:00:00 Roma 00:00:00 Hawaii 00:00:03 Tonno 00:00:07 Funghi 00:00:09 Hawaii 00:00:12 Tonno 00:00:15 Salami 00:00:15 Diavolo 00:00:21 Speciale 00:00:23 Calzone 00:00:26 FruttiDiMare 00:00:26 Margerita 00:00:26 Roma

45 Verhaltensmodellierung Zustandsautomat
Übung:

46 Verhaltensmodellierung Zustandsautomat
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.