Transcript Use Cases - DHBW Stuttgart

DHBW Stuttgart, SW-Engineering
Oktober 2011
Verhaltensmodellierung mit UML2
Übersicht
Seite 1
DHBW Stuttgart, SW-Engineering
Oktober 2011
Verhaltensmodellierung mit UML2
Übersicht
Seite 2
DHBW Stuttgart, SW-Engineering
Oktober 2011
Verhaltensmodellierung mit UML2
Übersicht
Seite 3
DHBW Stuttgart, SW-Engineering
Oktober 2011
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 KommunikationsBeziehungen, 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 4
DHBW Stuttgart, SW-Engineering
Oktober 2011
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”
Seite 5
DHBW Stuttgart, SW-Engineering
Oktober 2011
Verhaltensmodellierung mit UML2
Use Case Diagramm
Beispiel für eine Generalisierung (Innovator):
Es existieren drei (konkrete) Anwendungsfälle, die eine
Spezialisierung des abstrakten Anwendungsfalles Kfz
reservieren darstellen.
Christoph Riewerts
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 CallCenter-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).
Seite 6
DHBW Stuttgart, SW-Engineering
Oktober 2011
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.
Seite 7
DHBW Stuttgart, SW-Engineering
Oktober 2011
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.
Seite 8
DHBW Stuttgart, SW-Engineering
Oktober 2011
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.
……..
Seite 9
DHBW Stuttgart, SW-Engineering
Oktober 2011
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
Seite 10
DHBW Stuttgart, SW-Engineering
Oktober 2011
Verhaltensmodellierung mit UML2
Use Case Beschreibungen
Beispiele für verbesserungsfähige Use Cases:
Seite 11
DHBW Stuttgart, SW-Engineering
Oktober 2011
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
Seite 12
DHBW Stuttgart, SW-Engineering
Oktober 2011
Verhaltensmodellierung mit UML2
Übersicht
Seite 13
DHBW Stuttgart, SW-Engineering
Oktober 2011
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
Seite 14
DHBW Stuttgart, SW-Engineering
Oktober 2011
Verhaltensmodellierung mit UML2
Aktivität(sdiagramm)
Elemente
einer
Aktivität:
Seite 15
DHBW Stuttgart, SW-Engineering
Oktober 2011
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
Seite 16
DHBW Stuttgart, SW-Engineering
Oktober 2011
Verhaltensmodellierung mit UML2
Aktivität(sdiagramm)
Neuer Typ von Endknoten: Ablaufendknoten
Seite 17
DHBW Stuttgart, SW-Engineering
Oktober 2011
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)
Seite 18
DHBW Stuttgart, SW-Engineering
Oktober 2011
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
Seite 19
DHBW Stuttgart, SW-Engineering
Oktober 2011
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
Seite 20
DHBW Stuttgart, SW-Engineering
Oktober 2011
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„).
Seite 21
DHBW Stuttgart, SW-Engineering
Oktober 2011
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
Seite 22
DHBW Stuttgart, SW-Engineering
Oktober 2011
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
Seite 23
DHBW Stuttgart, SW-Engineering
Oktober 2011
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.
Seite 24
DHBW Stuttgart, SW-Engineering
Oktober 2011
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
Seite 25
DHBW Stuttgart, SW-Engineering
Oktober 2011
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.
Seite 26
DHBW Stuttgart, SW-Engineering
Oktober 2011
Verhaltensmodellierung mit UML2
Übersicht
Seite 27
DHBW Stuttgart, SW-Engineering
Oktober 2011
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.
Syntax: Ereignis / Aktion
•
Ereignis, das den Zustandsübergang auslöst
•
Aktion, die beim Zustandsübergang ausgeführt wird
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.
Seite 28
DHBW Stuttgart, SW-Engineering
Oktober 2011
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.
Anfangszustand
Ereignis1 / Aktion1
Zustand0
Endzustand
(optional)
Zustand1
entry / Aktivität2
do / Aktivität3
Transition
Ereignis4
Zustand3
entry / Aktivität5
exit / Aktivität6
Ereignis3
[Bedingung]
Zustand2
Implizites
Ereignis
Ereignis2
/ Aktion4
Seite 29
DHBW Stuttgart, SW-Engineering
Oktober 2011
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.
Seite 30
DHBW Stuttgart, SW-Engineering
Oktober 2011
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
Seite 31
DHBW Stuttgart, SW-Engineering
Oktober 2011
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):
Seite 32
DHBW Stuttgart, SW-Engineering
Oktober 2011
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).
Seite 33
DHBW Stuttgart, SW-Engineering
Oktober 2011
Verhaltensmodellierung mit UML2
Zustandsautomat
Beispiele von Zustandsübergängen:
Seite 34
DHBW Stuttgart, SW-Engineering
Oktober 2011
Verhaltensmodellierung mit UML2
Zustandsautomat
Pseudozustände:
Seite 35
DHBW Stuttgart, SW-Engineering
Oktober 2011
Verhaltensmodellierung mit UML2
Zustandsautomat
Pseudozustände:
Seite 36
DHBW Stuttgart, SW-Engineering
Oktober 2011
Verhaltensmodellierung mit UML2
Zustandsautomat
Beispiele
für
Pseudozustände:
Seite 37
DHBW Stuttgart, SW-Engineering
Oktober 2011
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
Seite 38
DHBW Stuttgart, SW-Engineering
Oktober 2011
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.
Seite 39
DHBW Stuttgart, SW-Engineering
Oktober 2011
Verhaltensmodellierung mit UML2
Zustandsautomat
Lösung der Übungsaufgabe
Seite 40
DHBW Stuttgart, SW-Engineering
Oktober 2011
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.
Seite 41
DHBW Stuttgart, SW-Engineering
Oktober 2011
Verhaltensmodellierung mit UML2
Zustandsautomat
Lösung der Übung Digitale Armbanduhr
Seite 42
DHBW Stuttgart, SW-Engineering
Oktober 2011
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.
Seite 43
Tipp: Die Bedingung in <name> prüft, ob der Zustand <name> aktiv ist.
DHBW Stuttgart, SW-Engineering
Oktober 2011
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
Seite 44
DHBW Stuttgart, SW-Engineering
Oktober 2011
Verhaltensmodellierung
Zustandsautomat
Übung:
Seite 45
DHBW Stuttgart, SW-Engineering
Oktober 2011
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.
Seite 46