Software Engineering. 7. Sequenz- und Zustandsdiagramme. Franz-Josef Elmer, Universität Basel, HS 2012

Transkript

1 Software Engineering 7. Sequenz- und Zustandsdiagramme Franz-Josef Elmer, Universität Basel, HS 2012

2 Software Engineering: 7. Sequenz- und Zustandsdiagramme 2 Sequenzdiagramme Häufigstes Verhaltensdiagramm Modelliert den Ablauf der Interaktionen zwischen Objekten, Komponenten, Akteuren etc. Sequenzdiagramme zeigen typische Abläufe von Interaktionsszenarien Analogie zu Use Cases: Kommunikationspartner: Use Case: Akteur(e) und System Sequenzdiagramme: Akteur(e) und/oder Teile des Systems Metapher: Aufruf einer Operation Senden einer Nachricht Funktion im Designprozess: Verantwortlichkeiten von Klassen ermitteln Klassenoperationen definieren

3 Software Engineering: 7. Sequenz- und Zustandsdiagramme 3 Sequenzdiagramme: Grundelemente Kommunikationspartner Web Browser Web Server Zeitverlauf GET URL HTML Antwort Nachricht Aktivierung Lebenslinie Rückkehr mit Rückgabewert

4 Software Engineering: 7. Sequenz- und Zustandsdiagramme 4 Sequenzdiagramme: Grundelemente Kommunikationspartner (eng. participants): Akteur: oder Benutzer «actor» Benutzer Namenloses Objekt: :Klasse Objekt mit Namen: name:klasse Wenn unspezifisch kein Doppelpunkt: Web Server

5 Software Engineering: 7. Sequenz- und Zustandsdiagramme 5 Sequenzdiagramme: Grundelemente Aktivierung: Beginn: Eintreffen der Nachricht; Bearbeitung beginnt. Ende: Nachrichtenbearbeitung beendet. Optional:

6 Software Engineering: 7. Sequenz- und Zustandsdiagramme 6 Sequenzdiagramme: Grundelemente Nachricht (eng. message): Notation: Text: Freier Text Name einer Operation der Empfängerklasse. Beispiel: get() Parameter der Operation können aber müssen nicht angegeben werden. Beispiele: get( ) get(url= ) Optionale Nummerierung (mit ':') vor der Nachricht. Beispiel: 1: get(url) Rückkehr (eng. return): Notation: Optional Text: Optionaler Rückgabewert

7 Software Engineering: 7. Sequenz- und Zustandsdiagramme 7 Sequenzdiagramme: Beispiel f:inputfield :Validator 1: validate(f) 2: gettext() false 3: showtextinred()

8 Software Engineering: 7. Sequenz- und Zustandsdiagramme 8 Sequenzdiagramme: Erzeugen und Löschen Objekt erzeugen: Notation: Nachrichtenpfeil zeigt auf Objektrechteck Text: new, create(), Konstruktor mit Parametern, «create» Objekt löschen: Notation: Grosses X beendet die Lebenslinie Ohne Nachrichtenpfeil oder Rückkehrpfeil: Selbstlöschung Mit Nachrichtenpfeil: Löschung durch ein anderes Objekt Text: delete, close, «destroy» Semantik in Sprachen mit Garbage Collection: Objekt wird nicht mehr benötigt Es gibt keine Referenz mehr auf das Objekt new delete

9 Software Engineering: 7. Sequenz- und Zustandsdiagramme 9 Sequenzdiagramme: Nachrichtentypen Synchrone Nachricht (eng. call): Notation: Sender wartet bis Empfänger die Nachricht abgearbeitet hat. Asynchrone Nachricht: Notation: UML 1.x: UML 2: Sender macht nach dem Absenden der Nachricht gleich weiter. Vorgefundene Nachricht (eng. found message): Notation: Sender ausserhalb des Sequenzdiagramms. Nachricht mit Polymorphismus: Notation: MyInterface Sender kennt Empfänger als Interface MyInterface Achtung: Inoffizielles UML Sprachkonstrukt

10 Software Engineering: 7. Sequenz- und Zustandsdiagramme 10 Sequenzdiagramme: Nachrichtentypen Beispiel: :ForestFireModel :ForestView next() datachanged() DataChangedListener repaint() «Interface» DataChangedListener +datachanged() JPanel +repaint() getdata() data paint() ForestView +paint(g: Graphics) ForestFireModel +next() +getdata(): Tree[*]

11 Software Engineering: 7. Sequenz- und Zustandsdiagramme 11 Sequenzdiagramme: Ablaufsteuerung Typisch: Ablauf ohne Verzweigungen Ablaufsteuerung in UML 1.x verschieden von UML 2 UML 1.x: Wächterbedingung vor der Nachricht: Nachricht wird nur gesendet wenn Bedingung erfüllt. Beispiel: [valid == false] showtextinred() Verzweigung: [x>0] calculate() [x<=0] error() Schleife: '*' vor Wächterbedingung bzw. Aufzählung: Nachricht wird mehrmals mit wechselndem Argument gesendet. Beispiel: * [i=0..10] calculate(i)

12 Software Engineering: 7. Sequenz- und Zustandsdiagramme 12 Sequenzdiagramme: Ablaufsteuerung UML2 Interaktionsrahmen (eng. interaction frame): Rechteck mit Operatorbezeichner oben links Fragmente: Durch horizontale gestrichelte Linien abgetrennte Abschnitte eines Interaktionsrahmens Jedes Fragment hat eine Wächterbedingung in eckigen Klammern Beispiel: Operator Interaktionsrahmen alt [x>0] calculate() Fragment 1 Wächterbedingung [x<=0] error() Fragment 2

13 Software Engineering: 7. Sequenz- und Zustandsdiagramme 13 Sequenzdiagramme: Ablaufsteuerung UML 2 Operatoren: opt: Option: Wird ausgeführt wenn die Wächterbedingung erfüllt ist. alt: Alternative: Es wird das Fragment ausgeführt welches die Wächterbedingung erfüllt. loop: Schleife: Wird für jedes Element einer Menge ausgeführt. Die Menge ist in der Wächterbedingung definiert. par: Parallel: Fragmente werden parallel ausgeführt. region: Kritischer Abschnitt: Darf nur von einem Thread gleichzeitig ausgeführt werden. ref: Referenz: Verweis auf ein anderes Sequenzdiagramm. Interaktionsrahmen ist undurchsichtig und enthält nur Name Eingabeparameter (optional) Ausgabeparameter (optional) sd <name>['('<parameters>')'][':'<return value>]: Sequenzdiagramm: Rahmen um ein referenziertes Sequenzdiagramm.

14 Software Engineering: 7. Sequenz- und Zustandsdiagramme 14 Sequenzdiagramme: Ablaufsteuerung UML 2 Beispiel: Blog Eintrag für HTML darstellen render(text) :Renderer new :TextBuffer loop [for each word in text] sd makelink(word) alt [word starts with ] :Renderer :TextBuffer renderaslink(word) :LinkRenderer ref makelink(word) link [else] add(link) add(word) gettext() rendered text rendered text

15 Software Engineering: 7. Sequenz- und Zustandsdiagramme 15 Zustandsdiagramme Diagramme von Zustandsautomaten (eng. state machines) Zustandsautomat: Endliche viele Zustände Zu jedem Zeitpunkt in genau einem Zustand Zustandsübergang (eng. state transition): getriggert durch Ereignis (z.b. Eingabe) führt optional Aktion aus (z.b. Ausgabe) Initialzustand (Pseudozustand) Optionaler Endzustand (Pseudozustand) Beispiel: Buch einer Bibliothek Initialzustand ausleihbar ausgeliehen vorbestellt Zustandsübergang Zustand Endzustand

16 Software Engineering: 7. Sequenz- und Zustandsdiagramme 16 Zustandsdiagramme: Übergang Beschriftung des Zustandsübergang: 1. Ereignis (optional) 2. Wächterbedingung (optional) 3. Aktivität (optional) Syntax: [<Ereignis>] ['[' <Wächterbedingung> ']'] ['/' <Aktivität>] Beispiel: neues Buch [Buch eingebunden] / Buch erfassen Semantik: ausleihbar Wächterbedingung ist wahr oder falsch. Übergänge aus demselben Zustand bei gleichem Ereignis: Wächterbedingungen müssen sich gegenseitig ausschliessen. Aktivität wird ausgeführt bevor der neue Zustand eingenommen wird. Aktivität kann nicht durch neues Ereignis unterbrochen werden.

17 Software Engineering: 7. Sequenz- und Zustandsdiagramme 17 Zustandsdiagramme: Interne Aktivitäten Beliebige interne Aktivität: Zustandsübergang mit Ausgangsgleich Endzustand: warte auf Geld Geld eingeworfen [reicht nicht] / Restbetrag anzeigen Alternative Notation, die internen Charakter betont: warte auf Geld Geld eingeworfen [reicht nicht] / Restbetrag anzeigen Spezielle interne Aktivitäten (nur innerhalb des Kastens): Entry-Aktivität: Nichtunterbrechbare Aktivität beim Eintreten in den Zustand. Syntax: entry / <Aktivität> Exit-Aktivität: Nichtunterbrechbare Aktivität beim Verlassen des Zustands. Syntax: exit / <Aktivität> Do-Aktivität: Unterbrechbare Aktivität mit oder ohne definiertem Ende. Syntax: do / <Aktivität>

18 Software Engineering: 7. Sequenz- und Zustandsdiagramme 18 Zustandsdiagramme: Unterzustände Ein Zustand kann selber ein Diagramm aus Unterzuständen enthalten (Zusammengesetzter Zustand). Beispiel: Fernseher An/Aus-Taste gedrückt [Fernseher hat Strom] aus An/Aus-Taste gedrückt standby an Programtaste gedrückt Standby-Taste gedrückt läuft Semantik: Der Zustand ist immer genau in einem der Unterzustände. Beim Eintritt in den Zustand wird beim Initialzustand gestartet. Alternative: Direkt auf den Unterzustand zeigen. Ein Übergang zu einem anderen Zustand ist identisch mit Übergang aus jedem Unterzustand.

19 Software Engineering: 7. Sequenz- und Zustandsdiagramme 19 Zustandsdiagramme: Unterzustände An/Aus-Taste gedrückt [Fernseher hat Strom] aus An/Aus-Taste gedrückt standby an Programtaste gedrückt Standby-Taste gedrückt läuft An/Aus-Taste gedrückt [Fernseher hat Strom] standby aus An/Aus-Taste gedrückt Programtaste gedrückt Standby-Taste gedrückt An/Aus-Taste gedrückt läuft

20 Software Engineering: 7. Sequenz- und Zustandsdiagramme 20 Zustandsdiagramme: History Zustand History Zustand ist ein Pseudozustand innerhalb eines zusammengesetzten Zustandes: Notation: H Semantik: Bei Ersteintritt: Wie Initialzustand. Bei Wiedereintritt: Es wird der letzte Unterzustand eingenommen. Beispiel: An/Aus-Taste gedrückt [Fernseher hat Strom] aus An/Aus-Taste gedrückt an Programtaste gedrückt H standby läuft Standby-Taste gedrückt Mögliche Sequenz: aus, standby, läuft, aus, läuft, standby, aus, standby

21 Software Engineering: 7. Sequenz- und Zustandsdiagramme 21 Zustandsdiagramme: Orthogonale Zustände Zusammengesetzter Zustand mit mehreren Zustandsdiagrammen: Beispiel: Notation: Einzelne Diagramme durch gestrichelte Linien getrennt Semantik: Jeder Teilzustandsautomat in genau einem Zustand. Gesamtzustand: Menge der Zustände aller Teilautomaten. Zustandsübergänge in den Teilautomaten geschehen parallel und unsynchronisiert. Ton an Uhr nicht sichtbar Fernseher läuft Mute Taste gedrückt Mute Taste gedrückt Uhr-Taste gedrückt Uhr-Taste gedrückt Ton aus Uhr sichtbar

22 Software Engineering: 7. Sequenz- und Zustandsdiagramme 22 Fallstudie: Blog Service Server 1. Zwei Schichten Architektur: BlogServiceImpl mit folgenden Verantwortlichkeiten: Authentifizierung Session Management Liest Daten von dem PersistenceLayer Arbeitet Daten auf. Schreibt Daten in den PersistenceLayer PersistenceLayer mit folgenden Verantwortlichkeiten: Liefert angefordete Daten Speichert Daten BlogServiceImpl 1 «Interface» PersistenceLayer DatabasePersistenceLayer FilePersistenceLayer 2. Kommunikation via Data Transfer Objects (DTOs): Reine Datenobjekte Kein Verhalten Keine Logik

23 Software Engineering: 7. Sequenz- und Zustandsdiagramme 23 Fallstudie: Blog Service Server 3. DTO's aus Anforderungen (Use Cases) ableiten: «DTO» Blogger «DTO» Blog «DTO» BlogEntry name: String bloggername: String password: String String blocked: boolean 0..1 id: String title: String description: String * {ordered} id: String title: String date: Date content: String 1 «DTO» Comment * date: Date text: String * {ordered}

24 Software Engineering: 7. Sequenz- und Zustandsdiagramme 24 Fallstudie: Blog Service Server 4. Use Cases durch Sequenzdiagramme spezifizieren: Beispiel aus UC3 (Benutzerauthentifizerung): 3. Benutzer gibt Blogger Name und Passwort ein. BlogServerImpl :SessionManager :PersistenceLayer login(name, password) getbloggers() bloggers:blogger[*] alt [matching blogger found] createsession() session null [else] 5. Aus allen Sequenzdiagrammen die Operationen des Interfaces PersistenceLayer extrahieren.

25 Software Engineering: 7. Sequenz- und Zustandsdiagramme 25 Fallstudie: Blog Service Server 6. Implementierung PersistenceLayer: Beispiel DatabasePersistenceLayer: :DatabasePersistenceLayer Database getbloggers() SELECT... FROM... WHERE... result set create list:list loop [For each entry in result set] create add(blog) blogger:blogger list