VII-Von-der-Analyse-zum-Entwurf-Teil-3
VII-Von-der-Analyse-zum-Entwurf-Teil-3
VII-Von-der-Analyse-zum-Entwurf-Teil-3
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
Vorlesung Software Engineering<br />
<strong>VII</strong>. <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong><br />
<strong>Entwurf</strong> – <strong>Teil</strong> 3<br />
Email<br />
SoftwEng (SS 06)<br />
Prof. Dr. Jens Grabowski<br />
Tel. 39 14 690<br />
grabowski@cs.uni-goettingen.de<br />
<strong>VII</strong>(3)-1<br />
Übersicht<br />
Planung<br />
Anfor<strong>der</strong>ungen<br />
(Lastenheft, Kapitel V)<br />
<strong>Analyse</strong><br />
<strong>Entwurf</strong><br />
Konzep. Datenmodell<br />
(Class Diagrams,<br />
Kapitel VI-2)<br />
Feines Klassenmodell<br />
(Class Diagrams mit Ops.,<br />
Kapitel <strong>VII</strong>)<br />
Anwendungsfälle<br />
(UML Use Cases,<br />
Kapitel VI-1)<br />
„Workflow“-Modell<br />
(Activity Diagrams,<br />
Kapitel VI-2)<br />
Feines Verhaltensmodell<br />
(Interaction Diagrams,<br />
Kapitel <strong>VII</strong>)<br />
Reaktives Verhalten<br />
(State Machines,<br />
Kapitel <strong>VII</strong>)<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-2<br />
Inhalt<br />
Objektzustände und -<br />
reaktionen<br />
<strong>Teil</strong> 1<br />
• Verfeinerung von Klassendiagrammen<br />
<strong>Teil</strong> 2<br />
• Verfeinerte Verhaltensbeschreibung<br />
<strong>Teil</strong> 3<br />
• Objektzustände und reaktives<br />
Verhalten<br />
• Aufgabe:<br />
• Beschreibung <strong>der</strong> Verhaltens <strong>der</strong> Objekte einer Klasse<br />
• Es werden hierarchische Zustandsdiagramme benutzt<br />
• Vorgehensweise:<br />
• Identifikation semantisch sinnvoller Objektzustände<br />
• Zuordnung von Operationen zu Zuständen<br />
• Welche Operationen können in welchem Zustand bearbeitet werden?<br />
• Bestimmung des "Objektlebenszyklus" als zulässige<br />
Zustandsfolgen<br />
• Operationsaufrufe/Signale als Ereignisse lösen Zustandsübergänge<br />
aus<br />
• [ vollständige "Ausprogrammierung" <strong>der</strong> Objektimplementierung ]<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-3<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-4<br />
Endliche Automaten 1(4)<br />
• Zustandsdiagramme = grafische Darstellung<br />
endlicher Automaten<br />
• Definition "endlicher deterministischer Automat"<br />
• Englisch: Finite State Machine<br />
• FSM = <br />
• Q endliche, nichtleere Menge von Zuständen<br />
• Σ endliches, nichtleeres Alphabet von Signalen<br />
(Ereignis)<br />
• δ : Q x Σ Q (partielle) Übergangsfunktion<br />
• q 0 ∈ Q Startzustand<br />
• F ⊆ Q Menge <strong>der</strong> Endzustände<br />
Endliche Automaten 2(4)<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-5<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-6<br />
1
Endliche Automaten 3(4)<br />
• Erklärung zu Folie 6<br />
• Q = new, Initial, WithClient, WithPeriod,<br />
WithCategory, Complete, Confirmed,<br />
destroyed<br />
• Σ = create, setClient, setPeriod, setCategory,<br />
confirm, fulfill, cancel<br />
• δ (new, create) = Initial …<br />
• q0 = new<br />
• F = destroyed<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-7<br />
Endliche Automaten 4(4)<br />
• Anmerkungen zur FSM:<br />
• die Rechtecke sind die Zustände <strong>der</strong> FSM<br />
• es gibt immer einen Anfangszustand und meist genau einen<br />
Endzustand<br />
• die Pfeile definieren die Übergangsfunktion von einem<br />
Zustand <strong>zum</strong> nächsten, sie werden Transitionen genannt<br />
und sind mit Signalen beschriftet<br />
• die Übergangsfunktion ist partiell, da man nicht mit jedem<br />
Signal (Ereignis) aus einem Zustand in einen an<strong>der</strong>en kommt<br />
• die FSM ist deterministisch, da für jedes Paar aus Zustand<br />
und Signal die Übergangsfunktion maximal einen möglichen<br />
neuen Zustand festlegt<br />
• die FSM ist "finite" = endlich, da sie nur eine endliche Menge<br />
von Zuständen besitzt<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-8<br />
Zustandsdiagramme 1(3)<br />
• Deutungen von Zustandsdiagrammen als Lebenszyklus:<br />
Zustandsdiagramme 2(3)<br />
• Deutung des Zustandsdiagramms als Klassenimplementierung:<br />
• Diagramm beschreibt, in welcher Reihenfolge die Operationen <strong>der</strong> Klasse<br />
ReservationContract aufgerufen werden dürfen.<br />
• Das Diagramm ist keine Implementierung <strong>der</strong> Klasse.<br />
• Man spricht von Lebenszyklus o<strong>der</strong> Protokoll <strong>der</strong> Klasse.<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-9<br />
• Bedeutung <strong>der</strong> Tranisionsbeschriftung:<br />
• wenn signal1 eintrifft schaltet Transition<br />
• falls condition erfüllt ist<br />
• und führt dabei ununterbrechbare action aus<br />
• und verschickt schließlich signal2<br />
• an ein bekanntes Objekt<br />
• Merke:<br />
• Viele CASE-Tools können aus solchen<br />
Zustandsdiagrammen guten Code generieren<br />
• Alle <strong>Teil</strong>e <strong>der</strong> Aufschrift sind optional:<br />
• Transition ohne Aufschrift feuert sofort<br />
• Transition nur mit Bedingung feuert, sobald die<br />
Bedingung erfüllt ist<br />
• Transition mit Signal feuert, sobald das Signal eintrifft<br />
• Transition mit Signal und Bedingung feuert, sobald<br />
Signal eintrifft, falls die Bedingung dann erfüllt ist<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-10<br />
Zustandsdiagramme 3(3)<br />
• Erweiterte Zustandsdiagramme<br />
• Problem: Zustandsdiagramme werden in realistischen Anwendungen<br />
groß!<br />
• Lösung: Hierarchisierung <strong>der</strong> Zustandsdiagramme<br />
• Harel, D.: Statecharts: A visual formalism for complex systems, Science of<br />
Computer Programming, vol. 8, Elsevier Science Publ. (1987), 231-274<br />
• UML State Machines (≈ Statecharts von Harel):<br />
• erweiterte Zustandsdiagramme<br />
• Zusammengesetzte Zustände<br />
• "nebenläufige" <strong>Teil</strong>diagramme<br />
• ein Diagramm wird immer genau einer Klasse zugeordnet<br />
• jede Klasse besitzt höchstens ein Diagramm<br />
• sie werden oft zur "Implementierung" von Objektverhalten benutzt<br />
• werden interpretativ ausgeführt o<strong>der</strong> in Quellcode übersetzt<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-11<br />
Hierarchische<br />
Zustandsdiagramme 1(16)<br />
• Statechart mit<br />
zusammengesetztem<br />
Zustand:<br />
• Lebenszyklus eines ReservationContract-Objektes mit Oberzustand Imcomplete,<br />
<strong>der</strong> Unterzustände besitzt. Immer genau einer <strong>der</strong> Unterzustände von<br />
Incomplete ist aktiv (deshalb wird <strong>der</strong> Zustand xor-Zustand genannt).<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-12<br />
2
Hierarchische<br />
Zustandsdiagramme 2(16)<br />
• Elimination von Anfangsund<br />
Endzuständen in<br />
xor-Zuständen:<br />
Hierarchische<br />
Zustandsdiagramme 3(16)<br />
• Elimination von Transitionen<br />
mit xor-Zustand als Quelle:<br />
• Die Transition in den Anfangszustand wurde auf den ersten<br />
"richtigen" Zustand umgelenkt, die Transition aus dem Endzustand<br />
geht nun vom letzten "richtigen" Zustand aus.<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-13<br />
• Die Transition mit Ereignis clear (alle Datenfel<strong>der</strong> wie<strong>der</strong> löschen)<br />
wurde durch eine entsprechende Transition von jedem Unterzustand<br />
aus ersetzt. Jetzt kann man den Oberzustand Incomplete entfernen<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-14<br />
Hierarchische<br />
Zustandsdiagramme 4(16)<br />
• Zu hierarchischem<br />
Statechart äquivalenter<br />
"flacher" Automat:<br />
Hierarchische<br />
Zustandsdiagramme 5(16)<br />
• Abstraktes Beispiel mit xor-Oberzustand:<br />
• Jedes "normale" hierarchische Statechart lässt sich in einen normalen<br />
(flachen) Automaten übersetzen.<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-15<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-16<br />
Hierarchische<br />
Zustandsdiagramme 6(16)<br />
• Übersetzung von Statecharts in einfache Zustandsdiagramme<br />
Hierarchische<br />
Zustandsdiagramme 7(16)<br />
• Übersetzung von Statecharts (cont.)<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-17<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-18<br />
3
Hierarchische<br />
Zustandsdiagramme 8(16)<br />
• and-Zustände (Concurrent States) in Together - Variante 1:<br />
Hierarchische<br />
Zustandsdiagramme 9(16)<br />
• and-Zustände (Concurrent States) in Together - Variante 2:<br />
• Incomplete wird verlassen, wenn entwe<strong>der</strong> Period.Defined o<strong>der</strong><br />
Category.Defined erreicht wurde und ok-Event (Operation) auftritt.<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-19<br />
• Incomplete wird verlassen, sobald ok-Event (Operation) auftritt.<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-20<br />
Hierarchische<br />
Zustandsdiagramme 10(16)<br />
• and-Zustände (Concurrent States) in Together - Variante 3:<br />
• Incomplete wird verlassen, wenn sowohl Period.Defined o<strong>der</strong><br />
Category.Defined erreicht wurde und ok-Event (Operation) auftritt.<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-21<br />
Hierarchische<br />
Zustandsdiagramme 11(16)<br />
• Erläuterung von and-Zuständen:<br />
• ein and-Zustand enthält beliebig viele Unterautomaten<br />
• beim Betreten des and-Zustandes geht je<strong>der</strong> Unterautomat in<br />
seinen Anfangszustand über<br />
• je<strong>der</strong> Unterautomat ist für sich aktiv (wie ein normaler Automat)<br />
und kann seinerseits wie<strong>der</strong> xor- und and-Zustände enthalten<br />
• kommt ein Signal an, so wird dieses Signal von jedem<br />
Unterautomaten abgearbeitet (theoretisch gleichzeitig, in <strong>der</strong><br />
Praxis in beliebiger Reihenfolge)<br />
• kann ein Unterautomat mit einem Signal nichts anfangen, bleibt er<br />
einfach im aktuellen Zustand<br />
• ein Unterautomat wird entwe<strong>der</strong> durch Transition nach "außen"<br />
mit explizitem Ereignis verlassen o<strong>der</strong> wenn alle Unterautomaten<br />
ihre Endzustände erreicht haben<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-22<br />
Hierarchische<br />
Zustandsdiagramme 12(16)<br />
• Abstraktes Beispiel mit and-Oberzustand:<br />
Hierarchische<br />
Zustandsdiagramme 13(16)<br />
• Übersetzung von and-Oberzustand in Produktautomaten:<br />
• Die Unterautomaten A und D schalten immer gleichzeitig (bei<br />
passendem Ereignis)<br />
• Querbezüge auf Zustand des "Nachbarautomaten" sind möglich<br />
mit "[in X]" als Transitionsbedingung (aber kein guter<br />
Modellierungsstil)<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-23<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-24<br />
4
Hierarchische<br />
Zustandsdiagramme 14(16)<br />
• Regeln für die Gestaltung von Statecharts:<br />
• Objekteigenschaften mit größerem Wertebereich nicht in Zuständen halten<br />
• Alter eines Autos, Gehalt einer Person, …<br />
• <strong>Teil</strong>diagramme mit mehr als 5 bis 7 Zuständen vermeiden<br />
• Hierarchisierung<br />
• nie Zustände verwenden, die Informationen zu mehreren Eigenschaften<br />
repräsentieren<br />
• z.B. Zustand "Auto ausgeliehen und Inspektion fällig"<br />
• Kopplung <strong>der</strong> <strong>Teil</strong>diagramme eines and-Zustandes über [in State]-<br />
Bedingungen (Wächter) nur überlegt einsetzen<br />
• führt oft zu schwer verständlichen Diagrammen<br />
• anstelle eines Objektes mit and-Zustand oft lieber mehrere Objekte mit<br />
einfachen Statecharts verwenden (die über Schnittstellenoperationen<br />
kommunizieren)<br />
• an die Verwendung ereignisloser Transitionen denken, die bei Erfüllung<br />
einer Bedingung schalten<br />
• z.B. Kilometerstand eines Autos größer als …<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-25<br />
Hierarchische<br />
Zustandsdiagramme 15(16)<br />
• <strong>Von</strong> sequentiellen Zustandsautomaten zu parallelen Statecharts:<br />
• Zustandsdiagramme beschreiben sequentielle Abläufe in einem Objekt:<br />
• zu einem Zeitpunkt löst ein Ereignis maximal einen Zustandsübergang aus<br />
• ein Event löst maximal eine Aktion aus<br />
• and-Zustände "normaler" Statecharts beschreiben (fast) nebenläufige<br />
Abläufe:<br />
• zu einem Zeitpunkt löst ein Ereignis maximal eine Transition im<br />
Produktautomaten aus (und damit gleichzeitig eine Menge von <strong>Teil</strong>transitionen)<br />
• Aktionen <strong>der</strong> <strong>Teil</strong>transitionen werden in beliebiger Reihenfolge ausgeführt<br />
• UML-Statecharts erlauben auch echt parallele Abläufe (mit fork/join):<br />
• während Aktionsausführung zu einem Ereignis in <strong>Teil</strong>automat A können bereits<br />
neue Ereignisse in an<strong>der</strong>em <strong>Teil</strong>automat B behandelt werden<br />
• je<strong>der</strong> <strong>Teil</strong>automat hat eine eigene (Kopie <strong>der</strong>) Warteschlange mit eingetroffenen<br />
Ereignissen (die noch abzuarbeiten sind)<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-26<br />
Hierarchische<br />
Zustandsdiagramme 16(16)<br />
• Komplexe = echt parallele Zustandsübergänge:<br />
Beispiel - Lebenszyklus von<br />
ReservationContract-Objekten<br />
• Die and-Zustände mit fork/join Konstrukt lassen sich<br />
nicht mehr in Produktautomaten übersetzen. Man hat<br />
in einem Objekt mehrere "threads of control"<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-27<br />
• fast schon UML-Aktivitätsdiagram ≈ Erweiterung von UML-<br />
Statecharts<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-28<br />
Weitere Sprachelemente von<br />
UML-Statecharts 1(2)<br />
• History-Mechanismus in komplexen Zuständen:<br />
bei Wie<strong>der</strong>eintritt in einen Zustand wird nicht <strong>der</strong> Anfangszustand<br />
aktiviert, son<strong>der</strong>n <strong>der</strong> letzte Unterzustand aus dem das Diagramm<br />
beim letzten Mal verlassen wurde (für Ausnahmebehandlungen).<br />
• entry/exit-Aktionen von Zuständen:<br />
nicht nur Transitionen sind mit Aktionen verbunden, son<strong>der</strong>n auch<br />
Eintritt in o<strong>der</strong> Austritt aus einem Zustand kann Aktionen auslösen<br />
• Schnittstellen (ports) komplexer Zuständen:<br />
Weitere Sprachelemente von<br />
UML-Statecharts 2(2)<br />
• Beispiel für<br />
History-<br />
Mechanismus:<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-29<br />
• Wenn man mit undoClear den Zustand Incomplete wie<strong>der</strong><br />
betritt, landet man in dem Unterzustand, von dem aus man<br />
mit clear den Zustand verlassen hatte, sonst im<br />
Anfangszustand WithClient.<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-30<br />
5
Zusammenfassung<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-31<br />
Übersicht (revisited)<br />
Planung<br />
Anfor<strong>der</strong>ungen<br />
(Lastenheft, Kapitel V)<br />
<strong>Analyse</strong><br />
<strong>Entwurf</strong><br />
Konzep. Datenmodell<br />
(Class Diagrams,<br />
Kapitel VI-2)<br />
Feines Klassenmodell<br />
(Class Diagrams mit Ops.,<br />
Kapitel <strong>VII</strong>)<br />
Anwendungsfälle<br />
(UML Use Cases,<br />
Kapitel VI-1)<br />
„Workflow“-Modell<br />
(Activity Diagrams,<br />
Kapitel VI-2)<br />
Feines Verhaltensmodell<br />
(Interaction Diagrams,<br />
Kapitel <strong>VII</strong>)<br />
Reaktives Verhalten<br />
(State Machines,<br />
Kapitel <strong>VII</strong>)<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-32<br />
Konsistenzbedingungen zwischen<br />
UML-Diagrammen<br />
• Klassendiagramm ↔ Objektdiagramm<br />
• jedes Objektdiagramm ist zulässige Instanz <strong>der</strong> Klassendiagramme<br />
• Klassendiagramm ↔ Interaktionsdiagramm<br />
• jede Operation muss bei <strong>der</strong> richtigen Klasse deklariert sein<br />
• Sequenzdiagramm ↔ Kollaborationsdiagramm<br />
• lassen sich wechselweise auseinan<strong>der</strong> generieren (im wesentlichen)<br />
• Interaktionsdiagramm ↔ Zustandsdiagramm<br />
• Operationsfolgen des Interaktionsdiagramms sind zulässig im<br />
Zustandsdiagramm<br />
• Klassendiagramm ↔ Zustandsdiagramm<br />
• jede Klasse besitzt maximal ein eigenes Zustandsdiagramm, Ereignisse sind<br />
Operationen <strong>der</strong> Klasse<br />
• wie Vererbung von Zustandsdiagrammen handhaben?<br />
• Aktivitätsdiagramm ↔ ???<br />
• ziemlich unklar<br />
SoftwEng (SS 06) <strong>Von</strong> <strong>der</strong> <strong>Analyse</strong> <strong>zum</strong> <strong>Entwurf</strong> – <strong>Teil</strong> 3 <strong>VII</strong>(3)-33<br />
6
Change language