6.1 Statecharts in Rhapsody / UML 2.0

Transkript

1 Statecharts in UML 2.0 Das Prinzip von Statecharts ist unter dem Namen Zustandsautomat (StateMachine) Bestandteil von UML 2.0. Ein Ausschnitt aus dem UML Metamodell: Zustandsautomat - StateMachine Region - Region Transition - Transition Knoten - Vertex Zustand - State 1 Unterschiede StateMachines Statecharts Im folgenden einige Unterschiede zwischen den bisher bekannten Statecharts und den StateMachines von UML 2.0 Default Transition Condition Connector Statecharts C Default Transition, Endzustand Terminator-Zustand Fallunterscheidung StateMachines Transitionen ohne Event: Transition ist aktiv, wenn der Guard wahr ist. Transitionen ohne Event: Vollständigkeitsereignis (CompletionEvent) Transition wird genommen, wenn der Ursprungszustand vollständig ist Ein- und Austrittspunkte (Entry-, Exit-Points) Separater Ein-, bzw. Ausgang aus komplexen Zuständen. 2

2 Ausschnitt aus der UML 2.0 Semantik AcceptEventAction Semantics [ ] Event occurrences are detected by objects independently of actions and the occurrences are stored by the object. The arrangement of detected event occurrences is not defined, but it is expected that extensions or profiles will specify such arrangements. [ ] In a system with concurrency, several actions or other behaviors might contend for an available event occurrence. Unless otherwise specified by an extension or profile, only one action accepts a given occurrence, even if the occurrence would satisfy multiple concurrently executing actions. [ ] 3 Was ist Rhapsody Eine Umsetzung der UML 2.0 Semantik. Modellgetriebene Entwicklung von Echtzeitanwendungen eingebetteter Systeme. Objektorientierter Ansatz. Wird von I-Logix entwickelt. Ausführbare Diagramme. Erzeugt einsetzbare Programme. 4

3 Grundsätzliches zu Rhapsody Rhapsody folgt dem objektorientierten Ansatz. Das Verhalten von Objekten wird durch Statecharts beschrieben. Jedes Objekt kann eine Instanz eines Statecharts haben. Objekte, und damit Statecharts, können zur Laufzeit erzeugt und zerstört werden. Aktionen und Bedingungen werden in der zugrunde liegenden Programmiersprache verfasst. Rhapsody unterstützt das Vorhandensein verschiedener Threads innerhalb eines reaktiven Systems. 5 Nachrichten Ereignis (wie bisher) Asynchronous communication triggered operation Synchronous communication null transition Transition ohne Trigger primitive operation ruft eine Methode in der zugrunde liegenden Programmiersprache auf. 6

4 Operationelle Semantik (wie bisher) Die möglichen Verhalten eines Systems werden als Menge von Läufen definiert. Jeder Lauf ist eine Abfolge von Status. Der erste Status eines Laufes ist immer der Initial Status. Der Übergang von einem Status zu dem folgendem Status wird als Schritt bezeichnet. Lauf Status (initial) Schritt Schritt Schritt Schritt Status Status Status Status 7 Operationelle Semantik (neu) Die möglichen Verhalten eines Systems werden als Menge von Läufen definiert. Jeder Lauf ist eine Abfolge von Status. Der erste Status eines Laufes ist immer der Initial Status. Der Übergang von einem Status zu dem folgendem Status wird als Schritt bezeichnet. Jeder Schritt besteht aus einer Abfolge von Mikroschritten. Lauf Status (initial) Schritt Status Schritt Status Schritt Status Schritt Status Mikroschritt Mikroschritt 8

5 Status (wie bisher) Schnappschuss des Systems die Zustände, in denen sich die Statecharts im Moment befinden (eine Konfiguration) Werte von Bedingungen und Daten History-Informationen 9 Status (neu) Schnappschuss des Systems Das Verhältnis (Aggregation, Komposition) aller Objekte untereinander die Zustände, in denen sich die Objekte im Moment befinden (eine Konfiguration) Werte von Bedingungen und Daten History-Informationen Queue der Ereignisse 10

6 Mikroschritt In Folge eines externen Ereignisses wird eine Sequenz von Mikroschritten ausgeführt, die zum endgültigen Status für diesen Schritt führen. Null-Transitionen können dabei spontan ausgeführt werden, wodurch prinzipiell Endlosschleifen entstehen können (mehr dazu später). Invarianten des Systems gelten am Anfang und Ende eines Schrittes aber nicht unbedingt innerhalb der Mikroschritte, z.b: In einem OR-Zustand zu sein bedeutet, in genau einem Unterzustand zu sein. 11 Grundsätzliche Prinzipien der Rhapsody Semantik Veränderungen, die innerhalb eines Schrittes stattfinden, können auch innerhalb dieses Schrittes bemerkt werden (keine doppelte Datenhaltung wie bisher). Es ist möglich, dass viele Schritte zwischen dem Absenden und dem Ausführen einer Nachricht vergehen. Insbesondere kann das Zielobjekt aufgehört haben, zu existieren. In diesem Fall wird die Nachricht ignoriert. Für einen Mikroschritt wird zunächst die Menge der relevanten Transitionen berechnet und erst dann ausgeführt. Da es keine doppelte Datenhaltung gibt, kann die Berechnung Effekte auf das System haben, wenn die Berechnung einer Bedingung Seiteneffekte hat. Bedingungen, die Seiteneffekte haben, werden als schlechter Stil betrachtet. Berechungen für einen Mikroschritt werden sequenziell in einer vorgegebenen Reihenfolge ausgeführt. Durch die fehlende doppelte Datenhaltung können hier Seiteneffekte, aber keine read-write oder write-write racings auftreten. greediness property (wie bisher), solange wir nur einen Thread betrachten. Da Aktionen Aufrufe von Methoden in der zugrunde liegenden Programmiersprache sein können, können Transitionen Zeit verbrauchen. In Rhapsody gibt es zwei Arten von Zeit: Echtzeit und simulierte Zeit. Aktionen werden garantiert in der Reihenfolge ausgeführt, wie sie aktiviert werden. Die nächste Aktion wird erst ausgeführt, nachdem die vorherige beendet wurde. Daher gibt es an dieser Stelle keine racing condition, solange wir nur einen Thread betrachten. 12

7 Run-to-completion [OMG-UML, v1.4] Events are dispatched and processed by the state machine, one at a time. The order of dequeuing is not defined, leaving open the possibility of modelling different prioritybased schemes. The semantics of event processing is based on the run to completion assumption, interpreted as run-to-completion processing. Run-to-completion processing means that an event can only be dequeued and dispatched if the processing of the previous event is fully completed. 13 Vergleich von Rhapsody und der bisherigen Semantik Sequenzielle Abarbeitung der Veränderungen innerhalb eines Schrittes greediness property Rhapsody Veränderungen an Daten können innerhalb eines Schrittes bemerkt werden Es können viele Schritte zwischen dem erzeugen eines Ereignisse und dem verarbeiten liegen; Sequenzielle Abarbeitung erzeugter Ereignisse Schritte unterteilt in Mikroschritte Sequenzielle Abarbeitung von Aktionen Transitionen können Zeit verbrauchen (Echtzeit, Simulierte Zeit) Ereignisse werden im nächsten Schritt wirksam Schritt erst vollständig berechnet und dann ausgeführt Write-write und read-write Races Parallele Ausführung aller Veränderungen innerhalb eines Schrittes greediness property Bisherige Semantik Veränderungen werden erst im nächsten Schritt wirksam Synchrony hypothesis (Schritt benötigt keine Zeit) 14

8 Einfache Transition A m/act B (a) A m/act B (b) Das System reagiert auf die Nachricht m: - exit action von A wird ausgeführt - action act wird ausgeführt (kann z.b. von der Form act1;...;actn sein) - entry action von B wird ausgeführt - neue Konfiguration (Objekt ist dann im Zustand B) m kann entweder ein Ereignis oder eine triggered operation sein. 15 Sequenzielle Ausführung <-> Racing (ein Vergleich) /x=0 >ex x=5 /x=x+1 B Bisherige Interpretation: Nichtdeterminismus (write-write racing): x ist entweder 1 oder 5 Rhapsody: 1. Exit-Aktionen ausführen -> x=5 2. Aktionen an Transitionen ausführen -> x=5+1=6 Genauere Ausführungen zu der Ausführungsreihenfolge innerhalb eines Mikroschritts behandeln wir später. 16

9 Ereignisse Ereignisse beschreiben asynchrone Kommunikation, daher muss das sendende Objekt nicht auf das konsumierende Objekt warten. Jede Klasse definiert die Ereignisse, die sie akzeptiert. Ereignisse werden über einen speziellen Methodenaufruf bei dem empfangenden Objekt realisiert: O -> GEN(event(p 1,p 2,...,p n )) (C++) p 1...p n sind Parameter GEN(event(p 1,p 2,...,p n )) (Ereignis wird für das eigene Objekt generiert) GEN erzeugt eine Eventinstanz und reicht sie an die Queue des entsprechenden Threads weiter. 17 Beispiel mit zwei Objekten C1 A e/getitsc2->gen(f) e/getitsc2->gen(f) B Objektdiagramm O1:C1 O2:C2 C2 A f/getitsc1->gen(e) f/getitsc1->gen(e) B 1 1 Wird einmal das Ereignis e oder f erzeugt, zum Beispiel vom Benutzer, wechseln beide Statecharts immer abwechselnd von Zustand A in den Zustand B und wieder zurück. 18

10 Beispiel für Parameter B /GEN(e(1)) A e C [params->p1 > 2] [params->p1 <= 2] C Wenn das Ereignis e verarbeitet wird, beinhaltet das Objekt params die Parameter, die diesem Objekt zugeordnet sind. In diesem Fall wird die Transition, die durch e ausgelöst wird, in den Zustand C führen. 19 Hierarchie von Ereignissen Ereignisse sind als Klassen implementiert. Es ist möglich, ein Ereignis von einem anderen abzuleiten. Wenn zum Beispiel e2 von e abgeleitet wurde, kann e2 als Auslöser für das Ereignis e gesehen werden: /GEN(e2) A e/act B 20

11 Triggered operations Synchrone Kommunikation Triggered Operations sind das Äquivalent zu einem Methodenaufruf Triggered Operations werden wie Methoden in der zugrunde liegenden Programmiersprache aufgerufen: result = O->t(p 1,p 2,...,p n ) Es kann Rückgabewerte geben: t/reply(17) Eine Transition mit einer triggered operation wird erst zu Ende geführt, wenn die triggered operation abgearbeitet wurde. 21 Probleme mit triggered operations /GEN(e) A e/t() t B Es gibt verschiedene Ansätze dieses Problem zu behandeln: Deadlock Transition abschließen lassen und den Zustand B betreten, um dann t abzuarbeiten Rhapsody: Ein Objekt, das gerade inmitten einer Transition ist, ignoriert triggered operations und es wird der Wert null (undefiniert) zurückgegeben. Im obigen Beispiel würde das Statechart also in den Zustand B wechseln und dort bleiben. 22

12 join- und fork- Konnektor (wie bisher) Alle Segmente nehmen jeweils an der CT teil. Wenn irgendein Segment eines join- oder fork- Konnektors an einer CT beteiligt ist, dann sind alle Segmente beteiligt. 23 or-, switch-, junction-, split- Konnektoren (wie bisher) Gegeben sei ein solcher Konnektor. Sei T 1 (T 2 ) die Menge der Transitionssegmente, die in den Konnektor hinein- bzw. herausführen. Eine CT enthält jeweils genau ein Segment aus T 1 und aus T 2, falls sie irgendein Segment aus T 1 T 2 enthält. Diagramm-Konnektor wird ebenfalls so interpretiert. Alle Auftreten als ein einziger Knoten. 24

13 Transitionen - Berechnung und Ausführung /x=1;gen(e) B A e/x=2 C [x==1] [x==2] C Als erstes werden alle Bedingungen ausgewertet und erst danach die Aktionen ausgeführt. Nach Verarbeitung des Ereignisses e wird der Zustand B aktiv sein. 25 Default Transitionen /x=0 C A e/x=1 C [x>0] [x<=0] D Default Transitionen werden als Mikroschritt betrachtet. Durch die fehlende doppelte Datenhaltung werden die Werte nach dem letzten Mikroschritt betrachtet. In diesem Beispiel ist nach Ausführung von e der Zustand C aktiv. 26

14 History Konnektor In Rhapsody verhält sich der History Konnektor wir der Deep-History Konnektor der bisherigen Semantik. Es gibt keinen history-clear(s) Operator, der die History-Informationen zurücksetzen kann. 27 Scope von Transitionen (wie bisher) Der Scope einer CT ist der niedrigste OR Zustand, der ein Vorfahre aller Quell- und Ziel- Zustände, die an der CT beteiligt sind, ist und während der Transition weder verlassen noch betreten wird. In allen Fällen ist der Scope U. U V U V U V W W 28

15 Konflikte zwischen Transitionen Wenn verschiedene Transitionen in Konflikt zueinander stehen, wird die Transition priorisiert, die den Ursprungszustand auf der niedrigsten Ebene hat. Transitionen haben Priorität über statische Reaktionen. Rhapsody Bisherige Semantik Transitionen haben Priorität von innen nach außen bezüglich des Ursprungszustands Transitionen haben Priorität von außen nach innen bezüglich des Scopes der Transition. 29 Schritt Algorithmus Pseudocode: Procedure StepCycle() begin loop forever while Event-Queue empty do ev <- Get-Event-From-Queue dest <- Get-Destination-Of-Event if dest still exists then dest -> takeevent(ev) else ignore ev end if end while end loop end 30

16 Take Event (1/2) Der Hauptteil des Schritt Algorithmus ist TakeEvent. An dieser Stelle wird festgelegt, wie ein Ereignis von einem Statechart verarbeitet wird. Ermitteln der CTs/SRs, die durch die Nachricht ausgelöst werden. Die aktiven Zustände werden vom niedrigsten Zustand innerhalb der Hierarchie aufwärts durchlaufen. Nachdem eine aktive CT/SR gefunden wurde, werden keine Zustände auf höheren Hierarchieebenen mehr betrachtet, orthogonale Komponenten werden weiter durchlaufen. Für die gefundenen CTs/SRs: Aktualisiere die Geschichte der zu verlassenden Zustände. Führe die exit Actions der zu verlassenen Zustände von innen nach außen aus. Führe die Aktionen an CTs/SRs in der sequenziellen Reihenfolge aus, wie sie angegeben sind. Führe die entry Action der zu betretenen Zustände von außen nach innen aus. Für die Zustände die betreten werden, die keine Basiszustände sind, führe die Default-Transitionen aus, bis das Statechart Basiszustände erreicht. Aktualisiere die aktive Konfiguration. Für CT s/srs in orthogonalen Zuständen gibt es keine vordefinierte Reihenfolge. 31 Take Event (2/2) Null-Transitionen Wenn eine Konfiguration erreicht wird, in der es aktive ausgehende Null-Transitionen gibt, müssen weitere Schritte ausgeführt werden, bis das Statechart eine stabile Konfiguration ohne ausgehende Null-Transitionen erreicht. An dieser Stelle können Endlosschleifen auftreten, die von Rhapsody zur Laufzeit erkannt werden, daraufhin wird die Ausführung angehalten. Alternativ kann auch eine maximale Zahl an Null-Transitionen pro Schritt eingestellt werden. Nachdem eine stabile Konfiguration erreicht wurde, ist der Schritt abgeschlossen, und die Kontrolle kann wieder an StepCycle abgegeben werden. 32

17 Zeit Real Time Die Zeit schreitet entsprechend der Systemzeit des zugrunde liegenden Betriebsystems voran. Simulated Time Der Benutzer kann das Voranschreiten der Zeit interaktiv beeinflussen und so effektiv das System testen. 33 Racing Conditions Wenn die Ausführung von Transitionen in zwei erlaubten, unterschiedlichen Reihenfolgen zu unterschiedlichen Konfigurationen führt, spricht man von Racing Conditions. Rhapsody versucht (im Gegensatz zu Statemate) nicht, Racing Conditions zu finden. Durch die Unterstützung von synchroner und asynchroner Kommunikation sowie Multithreading ist eine automatische Erkennung von Racing Conditions viel komplexer. 34

18 Motivation für Rhapsody Produktiver Code soll erzeugt werden Doppelte Datenhaltung erzeugt einen großen Overhead Sequenzielle Ausführung von Aktionen und Ereignisse ist eine natürliche Wahl für eine objektorientierte Programmiersprache. Es könne auch Klassen und Objekte ohne zugrunde liegendes Statechart erzeugt werden, wobei dann Statecharts auf entsprechende Methoden solcher Objekte zugreifen können (synchrone Kommunikation). 35