Seite 1. Kapitel 8: UML - Dynamische Modellierung. 8.1 Dynamische Diagrammarten. 8.1 Dynamische Diagrammarten. 8.2 Zustandsdiagramme

Transkript

1 8.1 Dynamische Diagrammarten Kapitel 8: UML - Dynamische Modellierung 8.1 Dynamische Diagrammarten 8. Zustandsdiagramme Sed fugit terea, fugit reparabile tempus. Vergil, v. Chr. Bei der Problemanalyse beschreibt man eem Use-Case- Diagramm (deutsch: nwendungsfalldiagramm) die wichtigsten Leistungen des zu erstellenden Systems. Für die Darstellung der bläufe bei der Durchführung ees Use Case gibt es folgende, komplementäre Diagrammarten mit unterschiedlichen Darstellungsschwerpunkten: Sequenzdiagramme betonen die zeitliche bfolge. Kollaborationsdiagramme betonen die an Interaktionen beteiligten Objekte, ihr Zusammenspiel und den Datenfluss. ktivitätsdiagramme stellen Kontrollflüsse dar. Zustandsdiagramme betonen unterschiedliche Verhaltensweisen unterschiedlichen Zuständen im Objekt-Lebenszyklus. OCL dient der Spezifikation von Zuständen & Operationen. Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-1 Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8 - Begriffe zu nwendungsfällen Use-Case-Diagramm zur Termverwaltung Defition: E kteur ist die Beschreibung eer Rolle, die e Benutzer (oder e anderes System) spielt, wenn er/es mit dem System teragiert. Defition: Ee Interaktion ist der ustausch von Nachrichten unter Objekten zur Erreichung ees bestimmten Ziels. Defition: Ee Nachricht ist die Beschreibung eer Operation ees Objekts mit den notwendigen Parameterwerten, so daß die Operation durch das Objekt ausführbar ist (stellt auch Datenfluss dar). Defition: E nwendungsfall (synonym Use-Case, engl. use case) ist die Beschreibung eer Klasse von ktionsfolgen (eschließlich Varianten), die e System ausführen kann, wenn es mit kteuren teragiert. op(x, y) Organisator Raumverwalter Teammitglied Persönlichen Term eplanen Termverwaltung Ungenutzte Raumkapazität ermitteln Teambesprechung organisieren Teambesprechung Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-3 Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-4 Use-Case-Diagramm zum Monopoly-Spiel Etwas detaillierteres Use-Case-Diagramm Spieler ziehen Strasse kaufen Gehalt beziehen Monopoly Bank Spieler Miete zahlen Haus-Verkauf ziehen <<extends>> <<cludes>> Strasse kaufen Fanzierung Monopoly würfeln Miete zahlen Hier fehlt noch Vieles! Bank Hypothek Details siehe Literatur [Seemann] Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-5 Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-6 Seite 1

2 Szenarien (Varianten von nwendungsfällen) Defition: E Szenario beschreibt Interaktionen (von Objekten) des Systems, die bei usführung ees nwendungsfalls ablaufen (und von eem der kteure ausgelöst werden). Es gibt Szenarien für Normalfälle ('gut-fälle') und usnahmefälle. Beispiel: Ees der Normalfall-Szenarien für Teambesprechung organisieren Organisator erfährt Thema, Term, TeilnehmerInnen eer neu geplanten Teambesprechung. Zeitpunkt wird mit TeilnehmerInnen abgestimmt. Raum wird reserviert (falls gewünscht). Eladungen werden an die TeilnehmerInnen versandt. Sequenzdiagramme für Szenarien Organisator erzeugen bestätigt... Term bestätigen OK Term bestätigen OK Objekt-bezogen Senkrechte Lien: Leben eer Objektstanz ( swim lane ) Waagrechte Pfeile: (Synchrone) Nachrichten Gestrichelte Pfeile (optional): ntworten (Ergebnisrückgaben) Blöcke auf den senkrechten Lien: Steuerfokus (ktivierung) Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-7 Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-8 Sequenzdiagramm zu Monopoly-Zug ktivitätsdiagramm zu Monopoly-Zug :Spieler betreten() tb1:teambesprechung m3:teammitglied m5:teammitglied :Gemeschaftsfeld wählekarte() aktion() :Kartenstapel gutschrift(000) Gewnkarte :Karte nfang Miete zahlen [fremde] Würfeln [eigene] [verkauft] [ke Interesse] Vorrücken Strasse betreten [nicht verkauft] Ende [Interesse] auch aus [Seemann] entnommen Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-9 Strasse kaufen Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K UML - Zustandsdiagramme Defition: E Zustand ist ee Eigenschaft eer Gruppe von Objekten, die über een begrenzten Zeitraum besteht. Notation: Z Defition: E Ereignis ist e Geschehen von vernachlässigbarer Zeitdauer, das auf die betrachtete Gruppe von Objekten uswirkungen hat. E Ereignis wird durch den Namen und evtl. weitere Parameter beschrieben. Notation: E E (P1,..., Pn) rten von Ereignissen Globale Ereignisse: Empfang eer Nachricht von außen blaufen eer Zeitbedgung (time-out): after(5 m) Veränderung eer (laufend überwachten) zeitlichen Bedgung (change event): when(x > y) Objektspezifische Ereignisse: Etreffen eer Nachricht bei eem Objekt (ausgelöst von eem anderen Objekt)» Signal: rightbuttonclick()» Methodenaufruf: verebareterm(17:00) Erzeugen oder Löschen des Objekts Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-11 Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-1 Seite

3 Verwendung von Zustandsmodellen Beispiel: Zustandsmodell ees Telefons Für steuernde Systeme, egebettete Systeme etc.: Zustandsmodelle verschiedener Detaillierungsgrade» Gesamt- oder Teilsysteme (nalyse)» Ezelklassen (Entwurf) Code-Erzeugung aus Zustandsmodellen möglich Für Informationssysteme, Datenbankanwendungen etc.: grobe Beschreibung des Zustandsmodells ausgewählter Klassen Beschreibung des Lebenszyklus von Objekten mit charakteristischen Zuständen Beschreibung von Prozessen durch utomaten mit Übergängen, z.b. von Transaktionen nmeldung abheben Wählbereit Modell stellt Lebenszyklus des Telefons dar Ziffer bereit Ziffer bmeldung auflegen Wählend nruf letzte Ziffer Gespräch Verbdung Verbdungsaufbau Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-13 Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-14 nfangs- und Endzustände Der Übergang vom nfangssymbol den nfangszustand gibt den Zustand zu Begn des Lebens der betrachteten Objektgruppe an. Er trägt keen Ereignisnamen (außer von Ereignissen, die mit der Erzeugung ehergehen). Die Übergänge zum Endesymbol geben an, welchen Zuständen und auf welche Weise das Leben der betrachteten Objektgruppe beendet werden kann. E E Zustandsdiagramm mit Bedgungen Zustände von Objekten der Klasse "Teambesprechung": [positiv, nicht letzte] eladen geplant abgestimmt Konflikt ke eladen egeladen abgelaufen Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-15 Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-16 Übergänge und Bedgungen Ee Zustandshierarchie Ereignis [Bedgung] Defition: E Übergangspfeil von Zustand nach Zustand B mit Ereignisnamen E besagt, daß im Zustand bei uftreten ees E- Ereignisses der neue Zustand B angenommen wird. Defition: Ee Bedgung (guard) ist ee Boolesche Bedgung, die zusätzlich bei uftreten des E-Ereignisses erfüllt se muß, damit der beschriebene Übergang etritt. Ee Bedgung wird der nalysephase meist noch textuell beschrieben. In formalerer Beschreibung (v.a. im Entwurf) kann ee Bedgung folgende Informationen verwenden: Parameterwerte des Ereignisses ttributwerte und ssoziationsstanzen der Objekte Beispiel: [best = true and anzbestätigg = anzteilnehmer - 1] statt B [positiv, nicht letzte] eladen Bearbeitung geplant abgestimmt egeladen Termkonflikt ke eladen abgelaufen Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-17 Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-18 Seite 3

4 Hierarchische und nebenläufige Zustände Hierarchische Zustände: Zustände dürfen geschachtelt werden. Dabei gilt: Übergänge (von außen oder nen) zum Rand ees Zustands ergeben een spontanen Übergang zum Startzustand des neren utomaten. Übergänge vom Rand des utomaten gelten für alle Zustände des neren utomaten => bkürzung, brgt Übersichtlichkeit!! Übergänge quer über Ränder sd möglich. beim Telefon? Nebenläufige Zustände: Spezielle hierarchische Zustände, bei denen zwei oder mehr parallele Subautomaten durch gestrichelte Lien getrennt sd. lle neren utomaten starten gleichzeitig. Sd alle neren utomaten fertig, geht es weiter (vom Rand). Nebenläufige Teilzustände [positiv,nicht letzte] Planung ke freier Raum Bearbeitung Termkonflikt eladen egeladen when date > (begn+dauer) Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-19 Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-0 ktionen Ereignis [Bedgung] / ktion Defition: Ee ktion ist die Beschreibung eer ausführbaren nweisung. Die Dauer der usführung ist vernachlässigbar. ktionen sd nicht unterbrechbar, können aber Folgen von Ezelaktionen se. Mögliche rten von ktionen: Lokale Änderung ees ttributwerts Versenden eer Nachricht an e anderes Objekt (bzw. ee Klasse) => löst dort Ereignis aus!! Erzeugen oder Löschen ees Objekts Rückgabe ees Ergebniswertes für ee früher empfangene Nachricht Ee ktion wird der nalysephase meist textuell beschrieben. In formalerer Beschreibung werden ktionssprachen verwendet, die ähnlich zu Programmiersprachen (und ausführbar) sd. B ktionen (Verbale Beschreibung) / anfordern; freien Raum suchen / Meldung( Termkonflikt ) Planung [positiv,nicht letzte] ke / Meldung( ) Termkonflikt Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-1 Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8 - ktionen (Formale Beschreibung) (best) [best = true and anzbestätigg < anzteilnehmer-1] / anzbestätigg := anzbestätigg + 1 anzbestätigg := 0 (best) [best=false] / Meldung( Termkonflikt ) (best) [best=true and anzbestätigg = anzteilnehmer-1] / anzbestätigg := anzbestätigg + 1 Interne Übergänge Defition: E terner Übergang ees Zustands S beschreibt een Übergang, der stattfdet, während das Objekt im Zustand S ist. Es gibt folgende rten von ternen Übergängen: Etrittsübergang (entry transition) ustrittsübergang (exit transition) Fortlaufende ktivität (do transition) Unterdiagrammaufruf (clude transition) Notation: Zustand label / terner Übergang label = entry, exit, do oder clude Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-3 Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-4 Seite 4

5 Spezialfall: Unterdiagramm clude / alle Teilnehmer abfragen / ersterteiln.termbestätigen alle Teilnehmer abfragen bfrage / nächsterteiln.termbestätigen [negativ or letzter Teiln] Der blauf des Unterdiagramms wird von externen Ereignissen nicht unterbrochen. Spezialfall: ktivität do/ alle Teilnehmer abfragen ktivitäten sd ähnlich zu Unterdiagrammaufrufen, wobei aber von den Details des Unterdiagramms abstrahiert wird. ktivität: fdet statt, solange der betreffende Zustand besteht => dauert! kann kontuierlich se oder aus eer Folge von ternen ktionen bestehen kann direkt Zustandsübergänge (des eigenen Objekts) auslösen durch Beendigung der ternen ktivität (Übergänge ohne Ereignismarkierung) ktion: von vernachlässigbarer Zeitdauer kann direkt Zustandsübergange auslösen, allerdgs der Regel bei fremden Objekten Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-5 Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-6 Zustandsdiagramm mit llem Planung do/ alle Teilnehmer abfragen / Raumbesprechung.freienRaumSuchen Bearbeitung [positiv] [positiv] Termkonflikt eladen egeladen when date > (begn+dauer) Beispiel: Warenausgabe - Prozess nächste Pos [noch nicht alle geprüft] Warenegang [noch nicht alle geprüft] Prüfung do / Pos prüfen [jede Pos geprüft && manche Waren fehlen] Warten [jede Pos geprüft && alle Waren vorhanden] Warenegang [alle Waren vorhanden] uslieferung do / Ware verpacken an Kurier ausgeliefert Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-7 Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-8 Exkurs: Object Constrat Language 1 Die OCL ist ee UML-spezifische Notation, mit der u.a. Invarianten von Klassen und Systemen sowie Vor- und Nachbedgungen von Methoden formalisiert werden können. Hier am Beispiel folgendem Kontext: ngestellter Name : Strg lter : Integer Gehalt : Real steigere(um : Real) :Real bearbeitet Personal Projekt Name : Strg Budget : Real bteilung Name : Strg 1.. Ort : Strg Budget : Real Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-9 hat 1 Exkurs: Object Constrat Language Zwei Invarianten für die Klasse bteilung : context bteilung v: Bitte self.budget >= 0 terpretieren! context bteilung v: self.personal -> forll( e1,e e1.bearbeitet.size() > e.bearbeitet.size() implies e1.gehalt > e.gehalt ) Die Spezifikation der Methode steigere : context ngestellter::steigere(um:real):real pre: um > 0 post: self.gehalt = self.gehalt@pre + um Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-30 Seite 5