Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "DHBW Stuttgart, SW-Engineering Oktober 2011 Seite 1 Verhaltensmodellierung mit UML2 Übersicht."—  Präsentation transkript:

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

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

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

4 DHBW Stuttgart, SW-Engineering Oktober 2011 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: – >-Beziehung, – >-Beziehung (ersetzt die >-Beziehung aus der UML1.1) – Generalisierungsbeziehung (seit UML 1.3).

5 DHBW Stuttgart, SW-Engineering Oktober 2011 Seite 5 Kommunikationsbeziehungen (einfache Striche) werden nicht benannt >Beziehung sagt, daß der Use Case Anmelden durch den Use Case Kontozugang sperren (unter bestimmten Umständen, siehe [ ] im Diagramm) erweitert wird (extension point) >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 Verhaltensmodellierung mit UML2 Use Case Diagramm Beispiel mit dem Case-Tool Innovator: Paket Verwaltung dient zur Gruppierung (Systemgrenze)

6 DHBW Stuttgart, SW-Engineering Oktober 2011 Seite 6 Christoph Riewerts 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.

7 DHBW Stuttgart, SW-Engineering Oktober 2011 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. Verhaltensmodellierung mit UML2 Use Case Diagramm

8 DHBW Stuttgart, SW-Engineering Oktober 2011 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. Verhaltensmodellierung mit UML2 Use Case Diagramm

9 DHBW Stuttgart, SW-Engineering Oktober 2011 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): …….. 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.

10 DHBW Stuttgart, SW-Engineering Oktober 2011 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 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 DHBW Stuttgart, SW-Engineering Oktober 2011 Seite 11 Beispiele für verbesserungsfähige Use Cases: Verhaltensmodellierung mit UML2 Use Case Beschreibungen

12 DHBW Stuttgart, SW-Engineering Oktober 2011 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

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

14 DHBW Stuttgart, SW-Engineering Oktober 2011 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)

15 DHBW Stuttgart, SW-Engineering Oktober 2011 Seite 15 Verhaltensmodellierung mit UML2 Aktivität(sdiagramm) Elemente einer Aktivität:

16 DHBW Stuttgart, SW-Engineering Oktober 2011 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 Verhaltensmodellierung mit UML2 Aktivität(sdiagramm)

17 DHBW Stuttgart, SW-Engineering Oktober 2011 Seite 17 Neuer Typ von Endknoten: Ablaufendknoten Verhaltensmodellierung mit UML2 Aktivität(sdiagramm)

18 DHBW Stuttgart, SW-Engineering Oktober 2011 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) Verhaltensmodellierung mit UML2 Aktivität(sdiagramm)

19 DHBW Stuttgart, SW-Engineering Oktober 2011 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 Verhaltensmodellierung mit UML2 Aktivität(sdiagramm)

20 DHBW Stuttgart, SW-Engineering Oktober 2011 Seite 20 Notationen für asynchrone Kopplungen: Verhaltensmodellierung mit UML2 Aktivität(sdiagramm) 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.

21 DHBW Stuttgart, SW-Engineering Oktober 2011 Seite 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 DHBW Stuttgart, SW-Engineering Oktober 2011 Seite 22 Objektfluss: ist gekennzeichnet durch Objektknoten (Rechtecke mit Namen und optional Zustand des Objekts), z.B. die Ein- und Ausgabeparameter oder durch Pins bei den Verhaltensaufrufen mit derselben Benennung Objektflüsse müssen stets bezeichnet sein Verhaltensmodellierung mit UML2 Aktivität(sdiagramm)

23 DHBW Stuttgart, SW-Engineering Oktober 2011 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 Verhaltensmodellierung mit UML2 Aktivität(sdiagramm)

24 DHBW Stuttgart, SW-Engineering Oktober 2011 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. Verhaltensmodellierung mit UML2 Aktivität(sdiagramm)

25 DHBW Stuttgart, SW-Engineering Oktober 2011 Seite 25 Verhaltensmodellierung mit UML2 Aktivität(sdiagramm) Beispiel aus der Literatur (.): Geldabheben über einen Bankomat. swimlanes Kunde, Automat und Bank, zur Spezifikation der verantwortlichkeit en. debit account = Konto belasten

26 DHBW Stuttgart, SW-Engineering Oktober 2011 Seite 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 DHBW Stuttgart, SW-Engineering Oktober 2011 Seite 27 Verhaltensmodellierung mit UML2 Übersicht

28 DHBW Stuttgart, SW-Engineering Oktober 2011 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

29 DHBW Stuttgart, SW-Engineering Oktober 2011 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ät5 exit / Aktivität6 Zustand0 Zustand2 Ereignis1 / Aktion1 Ereignis3 [Bedingung] Ereignis2 / Aktion4 Ereignis4 Implizites Ereignis Anfangs- zustand Endzustand (optional) Transition Zustand1 entry / Aktivität2 do / Aktivität3

30 DHBW Stuttgart, SW-Engineering Oktober 2011 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. Verhaltensmodellierung mit UML2 Zustandsautomat

31 DHBW Stuttgart, SW-Engineering Oktober 2011 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 Verhaltensmodellierung mit UML2 Zustandsautomat

32 DHBW Stuttgart, SW-Engineering Oktober 2011 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): Verhaltensmodellierung mit UML2 Zustandsautomat

33 DHBW Stuttgart, SW-Engineering Oktober 2011 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). Verhaltensmodellierung mit UML2 Zustandsautomat

34 DHBW Stuttgart, SW-Engineering Oktober 2011 Seite 34 Beispiele von Zustandsübergängen: Verhaltensmodellierung mit UML2 Zustandsautomat

35 DHBW Stuttgart, SW-Engineering Oktober 2011 Seite 35 Pseudozustände: Verhaltensmodellierung mit UML2 Zustandsautomat

36 DHBW Stuttgart, SW-Engineering Oktober 2011 Seite 36 Pseudozustände: Verhaltensmodellierung mit UML2 Zustandsautomat

37 DHBW Stuttgart, SW-Engineering Oktober 2011 Seite 37 Beispiele für Pseudo- zustände: Verhaltensmodellierung mit UML2 Zustandsautomat

38 DHBW Stuttgart, SW-Engineering Oktober 2011 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 Verhaltensmodellierung mit UML2 Zustandsautomat

39 DHBW Stuttgart, SW-Engineering Oktober 2011 Seite 39 Aktivitäten und Ereignisse sind nicht streng unterschieden. An den Transitionen fehlen Ereignisse (ggfs. mit Wächtern) Verhaltensmodellierung mit UML2 Zustandsautomat Nebenstehendes Zustandsdiagramm hat Fehler. Übung: Korrigieren sie bitte.

40 DHBW Stuttgart, SW-Engineering Oktober 2011 Seite 40 Verhaltensmodellierung mit UML2 Zustandsautomat Lösung der Übungsaufgabe

41 DHBW Stuttgart, SW-Engineering Oktober 2011 Seite 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 DHBW Stuttgart, SW-Engineering Oktober 2011 Seite 42 Lösung der Übung Digitale Armbanduhr Verhaltensmodellierung mit UML2 Zustandsautomat

43 DHBW Stuttgart, SW-Engineering Oktober 2011 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 prüft, ob der Zustand aktiv ist. Verhaltensmodellierung Zustandsautomat

44 DHBW Stuttgart, SW-Engineering Oktober 2011 Seite 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 DHBW Stuttgart, SW-Engineering Oktober 2011 Seite 45 Verhaltensmodellierung Zustandsautomat Übung:

46 DHBW Stuttgart, SW-Engineering Oktober 2011 Seite 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.


Herunterladen ppt "DHBW Stuttgart, SW-Engineering Oktober 2011 Seite 1 Verhaltensmodellierung mit UML2 Übersicht."

Ähnliche Präsentationen


Google-Anzeigen