Kapitel 8: UML - Dynamische Modellierung 8.1 Dynamische Diagrammarten 8.2 Zustandsdiagramme Sed fugit interea, fugit inreparabile tempus. Vergil, 70-16 v. Chr. Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-1
8.1 Dynamische Diagrammarten Bei der Problemanalyse beschreibt man in einem Use-Case- Diagramm (deutsch: Anwendungsfalldiagramm) die wichtigsten Leistungen des zu erstellenden Systems. Für die Darstellung der Abläufe bei der Durchführung eines Use Case gibt es folgende, komplementäre Diagrammarten mit unterschiedlichen Darstellungsschwerpunkten: Sequenzdiagramme betonen die zeitliche Abfolge. Kollaborationsdiagramme betonen die an Interaktionen beteiligten Objekte, ihr Zusammenspiel und den Datenfluss. Aktivitätsdiagramme stellen Kontrollflüsse dar. Zustandsdiagramme betonen unterschiedliche Verhaltensweisen in 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-2
Begriffe zu Anwendungsfällen Definition: Ein Akteur ist die Beschreibung einer Rolle, die ein Benutzer (oder ein anderes System) spielt, wenn er/es mit dem System interagiert. Definition: Eine Interaktion ist der Austausch von Nachrichten unter Objekten zur Erreichung eines bestimmten Ziels. Definition: Eine Nachricht ist die Beschreibung einer Operation eines Objekts mit den notwendigen Parameterwerten, so daß die Operation durch das Objekt ausführbar ist (stellt auch Datenfluss dar). op(x, y) Definition: Ein Anwendungsfall (synonym Use-Case, engl. use case) ist die Beschreibung einer Klasse von Aktionsfolgen (einschließlich Varianten), die ein System ausführen kann, wenn es mit Akteuren interagiert. Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-3
Use-Case-Diagramm zur Terminverwaltung Terminverwaltung Organisator Persönlichen Termin einplanen Ungenutzte Raumkapazität ermitteln Teambesprechung organisieren Teambesprechung verschieben Raumverwalter Teammitglied Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-4
Use-Case-Diagramm zum Monopoly-Spiel Monopoly ziehen Strasse kaufen Spieler 2 Gehalt beziehen Bank Miete zahlen Hier fehlt noch Vieles! Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-5
Etwas detaillierteres Use-Case-Diagramm ziehen <<includes>> Monopoly 2 Miete zahlen würfeln Spieler 2 Strasse kaufen Finanzierung Haus-Verkauf <<extends>> Bank Hypothek Details siehe Literatur [Seemann] Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-6
Szenarien (Varianten von Anwendungsfällen) Definition: Ein Szenario beschreibt Interaktionen (von Objekten) des Systems, die bei Ausführung eines Anwendungsfalls ablaufen (und von einem der Akteure ausgelöst werden). Es gibt Szenarien für Normalfälle ('gut-fälle') und Ausnahmefälle. Beispiel: Eines der Normalfall-Szenarien für Teambesprechung organisieren Organisator erfährt Thema, Termin, TeilnehmerInnen einer neu geplanten Teambesprechung. Zeitpunkt wird mit TeilnehmerInnen abgestimmt. Raum wird reserviert (falls gewünscht). Einladungen werden an die TeilnehmerInnen versandt. Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-7
Sequenzdiagramme für Szenarien Organisator erzeugen tb1:teambesprechung m3:teammitglied m5:teammitglied Termin bestätigen OK Termin bestätigen OK bestätigt... Objekt-bezogen Senkrechte Linien: Leben einer Objektinstanz ( swim lane ) Waagrechte Pfeile: (Synchrone) Nachrichten Gestrichelte Pfeile (optional): Antworten (Ergebnisrückgaben) Blöcke auf den senkrechten Linien: Steuerfokus (Aktivierung) Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-8
Sequenzdiagramm zu Monopoly-Zug :Spieler :Gemeinschaftsfeld :Kartenstapel Gewinnkarte :Karte betreten() wählekarte() aktion() gutschrift(2000) auch aus [Seemann] entnommen Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-9
Aktivitätsdiagramm zu Monopoly-Zug Würfeln Vorrücken Anfang [fremde] [verkauft] Strasse betreten Miete zahlen [eigene] [kein Interesse] [nicht verkauft] Ende [Interesse] Strasse kaufen Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-10
8.2 UML - Zustandsdiagramme Definition: Ein Zustand ist eine Eigenschaft einer Gruppe von Objekten, die über einen begrenzten Zeitraum besteht. Notation: Z Definition: Ein Ereignis ist ein Geschehen von vernachlässigbarer Zeitdauer, das auf die betrachtete Gruppe von Objekten Auswirkungen hat. Ein Ereignis wird durch den Namen und evtl. weitere Parameter beschrieben. Notation: E E (P1,..., Pn) Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-11
Arten von Ereignissen Globale Ereignisse: Empfang einer Nachricht von außen Ablaufen einer Zeitbedingung (time-out): after(5 min) Veränderung einer (laufend überwachten) zeitlichen Bedingung (change event): when(x > y) Objektspezifische Ereignisse: Eintreffen einer Nachricht bei einem Objekt (ausgelöst von einem anderen Objekt)» Signal: rightbuttonclick()» Methodenaufruf: vereinbaretermin(17:00) Erzeugen oder Löschen des Objekts Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-12
Verwendung von Zustandsmodellen Für steuernde Systeme, eingebettete Systeme etc.: Zustandsmodelle verschiedener Detaillierungsgrade» Gesamt- oder Teilsysteme (Analyse)» Einzelklassen (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 Automaten mit Übergängen, z.b. von Transaktionen Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-13
Beispiel: Zustandsmodell eines Telefons Abmeldung Anmeldung Anruf bereit Gespräch abheben auflegen Verbindung Wählbereit Modell stellt Lebenszyklus des Telefons dar Ziffer Ziffer Wählend letzte Ziffer Verbindungsaufbau Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-14
Anfangs- und Endzustände Der Übergang vom Anfangssymbol in den Anfangszustand gibt den Zustand zu Beginn des Lebens der betrachteten Objektgruppe an. Er trägt keinen Ereignisnamen (außer von Ereignissen, die mit der Erzeugung einhergehen). A Die Übergänge zum Endesymbol geben an, in welchen Zuständen und auf welche Weise das Leben der betrachteten Objektgruppe beendet werden kann. E Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-15
Ein Zustandsdiagramm mit Bedingungen Zustände von Objekten der Klasse "Teambesprechung": Terminbestätigung [positiv, nicht letzte] Terminbestätigung [negativ] Terminbestätigung [positiv, letzte] geplant abgestimmt verschieben in Konflikt kein freier Raum gefunden einladen freier Raum gefunden fixiert einladen absagen absagen absagen absagen eingeladen abgelaufen Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-16
Übergänge und Bedingungen Ereignis [Bedingung] A B Definition: Ein Übergangspfeil von Zustand A nach Zustand B mit Ereignisnamen E besagt, daß im Zustand A bei Auftreten eines E- Ereignisses der neue Zustand B angenommen wird. Definition: Eine Bedingung (guard) ist eine Boolesche Bedingung, die zusätzlich bei Auftreten des E-Ereignisses erfüllt sein muß, damit der beschriebene Übergang eintritt. Eine Bedingung wird in der Analysephase meist noch textuell beschrieben. In formalerer Beschreibung (v.a. im Entwurf) kann eine Bedingung folgende Informationen verwenden: Parameterwerte des Ereignisses Attributwerte und Assoziationsinstanzen der Objekte Beispiel: [best = true and anzbestätigg = anzteilnehmer - 1] statt [positiv, letzte] Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-17
Eine Zustandshierarchie verschieben Terminbestätigung [positiv, nicht letzte] in Bearbeitung geplant Terminbestätigung [negativ] Terminkonflikt Terminbestätigung [positiv, letzte] kein freier Raum gefunden abgestimmt Raumproblem einladen freier Raum gefunden fixiert absagen einladen eingeladen abgelaufen Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-18
Hierarchische und nebenläufige Zustände Hierarchische Zustände: Zustände dürfen geschachtelt werden. Dabei gilt: Übergänge (von außen oder innen) zum Rand eines Zustands ergeben einen spontanen Übergang zum Startzustand des inneren Automaten. Übergänge vom Rand des Automaten gelten für alle Zustände des inneren Automaten => Abkürzung, bringt Übersichtlichkeit!! Übergänge quer über Ränder sind möglich. beim Telefon? Nebenläufige Zustände: Spezielle hierarchische Zustände, bei denen zwei oder mehr parallele Subautomaten durch gestrichelte Linien getrennt sind. Alle inneren Automaten starten gleichzeitig. Sind alle inneren Automaten fertig, geht es weiter (vom Rand). Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-19
Nebenläufige Teilzustände in Bearbeitung in Abstimmung in Planung Terminbestätigung [positiv,nicht letzte] Terminbestätigung [negativ] Terminbestätigung [positiv, letzte] Terminkonflikt fixiert einladen verschieben absagen in Raumplanung freier Raum gefunden eingeladen when date > (beginn+dauer) kein freier Raum gefunden Raumproblem Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-20
Aktionen Ereignis [Bedingung] / Aktion A B Definition: Eine Aktion ist die Beschreibung einer ausführbaren Anweisung. Die Dauer der Ausführung ist vernachlässigbar. Aktionen sind nicht unterbrechbar, können aber Folgen von Einzelaktionen sein. Mögliche Arten von Aktionen: Lokale Änderung eines Attributwerts Versenden einer Nachricht an ein anderes Objekt (bzw. eine Klasse) => löst dort Ereignis aus!! Erzeugen oder Löschen eines Objekts Rückgabe eines Ergebniswertes für eine früher empfangene Nachricht Eine Aktion wird in der Analysephase meist textuell beschrieben. In formalerer Beschreibung werden Aktionssprachen verwendet, die ähnlich zu Programmiersprachen (und ausführbar) sind. Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-21
Aktionen (Verbale Beschreibung) Terminbestätigung [negativ] / Meldung( Terminkonflikt ) Terminkonflikt / Terminbestätigung anfordern; freien Raum suchen Terminbestätigung [positiv,nicht letzte] in Abstimmung in Raumplanung in Planung Terminbestätigung [positiv, letzte] freier Raum gefunden kein freier Raum gefunden / Meldung( Raumproblem ) Raumproblem Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-22
Aktionen (Formale Beschreibung) Terminbestätigung(best) [best = true and anzbestätigg < anzteilnehmer-1] / anzbestätigg := anzbestätigg + 1 anzbestätigg := 0 in Abstimmung Terminbestätigung(best) [best=false] / Meldung( Terminkonflikt ) Terminbestätigung(best) [best=true and anzbestätigg = anzteilnehmer-1] / anzbestätigg := anzbestätigg + 1 Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-23
Interne Übergänge Definition: Ein interner Übergang eines Zustands S beschreibt einen Übergang, der stattfindet, während das Objekt im Zustand S ist. Es gibt folgende Arten von internen Übergängen: Eintrittsübergang (entry transition) Austrittsübergang (exit transition) Fortlaufende Aktivität (do transition) Unterdiagrammaufruf (include transition) Notation: Zustand label / interner Übergang label = entry, exit, do oder include Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-24
Spezialfall: Unterdiagramm in Abstimmung include / alle Teilnehmer abfragen / ersterteiln.terminbestätigen alle Teilnehmer abfragen in Abfrage / nächsterteiln.terminbestätigen [negativ or letzter Teiln] Der Ablauf des Unterdiagramms wird von externen Ereignissen nicht unterbrochen. Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-25
Spezialfall: Aktivität in Abstimmung do/ alle Teilnehmer abfragen Aktivitäten sind ähnlich zu Unterdiagrammaufrufen, wobei aber von den Details des Unterdiagramms abstrahiert wird. Aktivität: findet statt, solange der betreffende Zustand besteht => dauert! kann kontinuierlich sein oder aus einer Folge von internen Aktionen bestehen kann indirekt Zustandsübergänge (des eigenen Objekts) auslösen durch Beendigung der internen Aktivität (Übergänge ohne Ereignismarkierung) Aktion: von vernachlässigbarer Zeitdauer kann indirekt Zustandsübergange auslösen, allerdings in der Regel bei fremden Objekten Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-26
Zustandsdiagramm mit Allem in Bearbeitung in Planung Terminkonflikt verschieben in Abstimmung do/ alle Teilnehmer abfragen [negativ] [positiv] fixiert einladen absagen in Raumplanung / Raumbesprechung.freienRaumSuchen [positiv] [negativ] eingeladen when date > (beginn+dauer) Raumproblem Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-27
Beispiel: Warenausgabe - Prozess nächste Pos [noch nicht alle geprüft] Prüfung do / Pos prüfen [jede Pos geprüft && alle Waren vorhanden] Auslieferung do / Ware verpacken [jede Pos geprüft && manche Waren fehlen] an Kurier Wareneingang [noch nicht alle geprüft] Warten Wareneingang [alle Waren vorhanden] ausgeliefert Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-28
Exkurs: Object Constraint Language 1 Die OCL ist eine UML-spezifische Notation, mit der u.a. Invarianten von Klassen und Systemen sowie Vor- und Nachbedingungen von Methoden formalisiert werden können. Hier am Beispiel in folgendem Kontext: Angestellter Name : String Alter : Integer Gehalt : Real steigere(um : Real) :Real * bearbeitet * * Personal Projekt Name : String Budget : Real 1..* * Abteilung Name : String Ort : String Budget : Real hat 1 Lothar Schmitz UniBwM (teils nach Prof. Hußmann TUD) Objektoiertierte Programmierung K8-29
Exkurs: Object Constraint Language 2 Zwei Invarianten für die Klasse Abteilung : context Abteilung inv: self.budget >= 0 context Abteilung inv: self.personal -> forall( e1,e2 e1.bearbeitet.size() > e2.bearbeitet.size() implies e1.gehalt > e2.gehalt ) Bitte interpretieren! Die Spezifikation der Methode steigere : context Angestellter::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