Erzeugung von Statecharts aus Sequence Charts

Inhaltsverzeichnis

1 Einleitung

2 Grundlagen
2.1 Sequence Charts
2.1.1 Sinn und Zweck von Sequence Charts
2.1.2 Klassifikation von Sequence Charts
2.2 Endliche Automaten und Statecharts
2.2.1 Endliche Automaten
2.2.2 Statecharts

3 ÜberblicküberTransformations-Verfahren
3.1 Transformation von Statecharts aus Message Sequence Charts
3.2 Transformation von Statecharts aus Life Sequence Charts
3.3 Vor- und Nachteile der Ansätze
3.4 Probleme und Lösungen

4 Transformation von Message Sequence Charts in State Charts
4.1 Einzelne Sequence Diagramme
4.1.1 Konfliktsuche
4.1.2 ÜbersetzunginendlicheAutomaten
4.2 Mehrere Sequence Diagramme
4.3 Erweiterung um Hierarchie

5 Zusammenfassung und Ausblick

Abstract

In dieser Ausarbeitung geht es um Verfahren zur Transformation von Sequence Charts in Statecharts. Es werden die Ansätze zur Transfor- mation von Statecharts aus Life Sequence Charts und Message Sequence Charts vorgestellt und Nachteile bei der Modellierung angesprochen. Der Schwerpunkt dieser Arbeit liegt dabei auf der Transformation aus Mes- sage Sequence Charts. Teilaspekte zur Transformation von Message Se- quence Charts zu Statecharts werden informell beschrieben und anhand von praktischen Beispielen vorgestellt.

1 Einleitung

Systeme mit Hilfe von Modellierungs-Sprachen zu beschreiben ist heutzutage ein gängiges und bewährtes Verfahren. Sequence Charts sind eine grafische Beschrei- bungssprache zur Darstellung von Nachrichtenaustausch zwischen Objekten. State- charts beschreiben ein System anhand seiner Zustände. Sequence Charts und State- charts sind damit Werkzeuge für Entwickler, die das Verhalten von Systemen anhand zweier völlig unterschiedlicher Aspekte, den Nachrichtenaustausch zwischen Objek- ten und Zustände im System, darstellen. Sequence Charts wurden 1993 von der International Telecommunication Union (ITU ) standardisiert[7]. Diese ursprüngli- chen Sequence Charts enthalten nicht genug Informationen, um aus ihnen Zustände innerhalb des modellierten Systems abzuleiten und damit Statecharts zu erzeugen. Daher werden die ursprünglichen Sequence Charts durch verschiedene Standards erweitert. Die für diese Ausarbeitung wichtigsten Erweiterungen sind durch die Ob- ject Constraints Language erweiterte Message Sequence Charts und Life Sequence Charts. Diese Erweiterungen werden in Kapitel 2 vorgestellt. Die Transformation von Statecharts aus Message Sequence Charts bzw. Life Sequence Charts werden in [11, 10 bzw. [6], 4eingehend beschrieben. Kapitel 3 gibt eine Übersicht über diese Verfahren und geht auf einige Vor- und Nachteile bei der Modellierung ein. In Kapitel 4 werden einzelne Teilaspekte bei der Transformation von Statecharts aus Message Sequence Charts erläutert und anhand von Beispielen erklärt.

2 Grundlagen

2.1 Sequence Charts

2.1.1 Sinn und Zweck von Sequence Charts

Sequence Charts sind hoch intuitiv und gut zu verstehen. Sie sind weitestgehend als grafische Sprache zur Beschreibung von Szenarien akzeptiert. Insbesondere bei der Entwicklung reaktiver Systeme ist es wichtig das dynamische Verhalten hinreichend genau abzubilden. So haben sich Sequence Charts zunächst im Telekommunikati- onsbereich als eine wichtige Modellierungssprache zur Darstellung von Kommuni- kation zwischen Systemkomponenten und Ihrer Umgebung etabliert. Später wurden Sequence Charts in Form von Message Sequence Charts (MSC ) von der ITU stan- dardisiert[7] und von verschiedenen Institutionen weiterentwickelt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Sequence Chart

Das grundlegende Konzept aller Sequence Charts ist es, den Austausch von Nachrich- ten in der zeitlichen Abfolge darzustellen. Abbildung 1 zeigt ein einfaches Sequence Chart mit zwei Objekten - einem User und einem Bankautomat (ATM, engl. au- tomated teller machine). Objekte werden als vertikale Linien und Nachrichten als horizontale Pfeile dargestellt. Die Reihenfolge der Pfeile zeigt dabei den Zeitverlauf im Nachrichtenaustausch.

2.1.2 Klassifikation von Sequence Charts

Die von der ITU 1993 spezifizierten MSC sind geeignet um ausgewählte BeispielSzenarien zu spezifizieren, nicht jedoch für eine allgemein gültige Spezifikation. So spezifiziert z.B. das in Abbildung 1 angegebene Beispiel nicht was passiert, wenn zweimal Chancel aufgerufen wird oder sich bereits von Anfang an eine Karte im ATM befindet. Um das Verhalten komplexer Systeme darzustellen scheint es sinnvoll mehrere Sequence Charts zu kombinieren.

Die ITU hat in späteren Versionen mehrere neue Konstrukte eingeführt, die es erlauben MSC zu kombinieren und so das Verhalten von Systemen vollständig darzustellen. In[8] wird eine formale Semantik der zu Hight-Level MSC (HMSC ) erweiterten MSC gegeben. Unter HMSC werden Graphen, deren Knoten Sequence Charts oder HMSC sind, verstanden. Ein Beispiel ist in Abbildung 2 zu sehen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: High-Level MSC

[5] erweitert ebenfalls die MSC um die M¨oglichkeit mehrere Sequence Charts zukombinieren und f¨uhrt Konstrukte ein, mit deren Hilfe spezifiziert werden kann was in einem Sequence Chart passieren muss im Gegensatz zu dem was passieren kann. Diese erweiterten MSC heißen Life Sequence Charts (LSC) - MSC erweitert um lifeness. Ein Beispiel ist im Abbildung 3 angegeben. LSC unterscheiden Universale und Existentielle Diagramme. Universale Diagramme geben an was in einem System passieren muss (3.3 und 3.4) und Existentielle Diagramme was in einem System passieren kann (3.1 und 3.2). Universale Diagramme werden mit einem Kasten und Existentielle Diagrammer mit einem gestrichelten Kasten umrahmt. Zum Beispiel m¨ussen nach den Nachrichten Insert card und Request passwd die Nachrichten

Enter passwd und Eject card vorkommen. Nach Enter passwd m¨ussen entweder Display passwd not ok und Eject card oder Enter amount und Chancel versandt werden. Das Beispiel akzeptiert unter anderem das in Abbildung 1 angegebene MSC. Eine Kollektion aus Universalen und Existentiellen Diagrammen spezifiziert das Systemverhalten allgemein g¨ultig und nicht nur beispielhaft.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Existentielle (3.1,3.2) und Universale (3.3,3.4) Life Sequence Charts — Es muss entweder 3.1 oder 3.2 erf¨ullt werden. Ist in 3.3 der IF-Fall erf¨ullt, so m¨ussen die Nachrichten im THEN-Fall versandt werden. Insert card erzwingt in 3.4 die Nachrichten Eject card und Take card .

Die OMG hat ebenfalls den Ansatz der ITU aufgegriffen und die MSC in Form der Sequence Diagramme in den UML-Standard[2] aufgenommen und mit der Object Constraint Language (OCL)[1] die Möglichkeit geschaffen Sequence Diagramme um Guards sowie Vor- und Nachbedingungen von Nachrichten zu erweitern.

2.2 Endliche Automaten und Statecharts

Im Folgenden werden Statecharts als eine weitere Möglichkeit das Verhalten eines Systems zu beschreiben vorgestellt. Während Sequence Charts Interaktionen zwischen Objekten beschreiben, eignen sich Statecharts um das interne Verhalten eines einzelnen Objektes anhand seiner Zustände darzustellen.

2.2.1 Endliche Automaten

Die Statecharts haben sich aus den s.g. Mealy-Automaten entwickelt. Mealy-Automaten sind eine Form der Endlichen Automaten (FSM, engl. finite state machine). Formal lassen sich endliche Automaten M beschreiben durch M = (X, Y, Z, δ, λ), wobei

- X die endliche Menge der Eingabewerte,
- Y die endliche Menge der Ausgabewerte,
- Z die endliche Zustandsmenge angeben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Mealy-Automat

Die Ausgabewerte eines Mealy-Automaten hängen von der Eingabe und dem Zu- stand des Automaten ab, somit ergeben sich folgende Zustandfunktionen für Mea- ly-Automaten:

- δ : Z × X → Z Zustandsüberführungsfunktion,

- λ : Z × X → Y Ausgabefunktion

Die Zustandsüberführung in einem Mealy-Automaten lassen sich als gerichtete Graphen, dessen Knoten Zustände und dessen Kanten Zustandsüberführungen darstellen, beschreiben. Die Kanten werden mit Paaren aus Eingabe- und zugehörigem Ausgabewert beschriftet. Abbildung 4 zeigt das ATM -Beispiel aus Abbildung 1, darstellt durch einen Mealy-Automaten.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Statechart

2.2.2 Statecharts

Statecharts entstehen durch Erweiterung der Mealy-Automaten um die Konzepte Hierarchie, Orthogonalität und Broadcast. In Abbildung 5 ist das ATM -Beispiel als Statechart zu sehen.

Die Konzepte werden im Folgenden kurz umrissen:

Hierarchie (oder auch Tiefe): In Abbildung 4 kann an jedem beliebigen Knoten die Eingabe Chancel erfolgen. Dies führt zu einer Vielzahl von Kanten. Durch Hierarchiebildung lässt sich das Zustandsdiagramm vereinfachen.

Orthogonalität (oder auch Nebenläufigkeit): Beim Zusammenfassen mehrere end- liche Automaten in einem Diagramm kann sich aufgrund von Nebenläufigkeit ein exponentieller Zuwachs von Zuständen ergeben. In Statecharts werden zwei unabhängige Zustandsdiagramme durch ein AND-Statement, welches in Form einer gestrichelte Linie dargestellt wird, in einem Diagramm zusammengefasst.

Broadcast: Alle zu einem System gehörigen Komponenten sehen sich untereinander, somit ist es möglich, dass die Ausgabe der einen Komponente die Eingabe einer anderen Komponente ist.

Das nächste Kapitel gibt einenÜberblick über Verfahren zur Transformation von Sequence Charts in Statecharts.

[5] erweitert ebenfalls die MSC um die Möglichkeit mehrere Sequence Charts zu kombinieren und führt Konstrukte ein, mit deren Hilfe spezifiziert werden kann was in einem Sequence Chart passieren muss im Gegensatz zu dem was passieren kann. Diese erweiterten MSC heißen Life Sequence Charts (LSC ) - MSC erweitert um lifeness. Ein Beispiel ist im Abbildung 3 angegeben. LSC unterscheiden Universale und Existentielle Diagramme. Universale Diagramme geben an was in einem Sys- tem passieren muss (3.3 und 3.4) und Existentielle Diagramme was in einem System passieren kann (3.1 und 3.2). Universale Diagramme werden mit einem Kasten und Existentielle Diagrammer mit einem gestrichelten Kasten umrahmt.

[...]