Transformation erweiterter Zustandsmaschinen aus UML-Statecharts unter Verwendung von XMI
- Art: Diplomarbeit
- Autor: Rudolf Böddeker
- Abgabedatum: Januar 2005
- Umfang: 87 Seiten
- Dateigröße: 529,0 KB
- Note: 1,3
- Institution / Hochschule: FernUniversität in Hagen Deutschland
- ISBN (eBook): 978-3-8324-8683-9
-
ISBN (Paperback) :
978-3-8324-8683-9 P - ISBN (CD) :978-3-8324-8683-9 CD
- Sprache: Deutsch
- Prämierung:
- Arbeit zitieren: Böddeker, Rudolf Januar 2005: Transformation erweiterter Zustandsmaschinen aus UML-Statecharts unter Verwendung von XMI, Hamburg: Diplomica Verlag
- Schlagworte: XML, Rhapsody, EFSM, Softwareentwicklung, Poseidon
In den Warenkorb
98,00 €
Diplomarbeit von Rudolf Böddeker
Einleitung:
Durch das rapide Anwachsen der technischen Möglichkeiten im Bereich der EDV-Anwendungen ist parallel die Komplexität der Softwaresysteme angewachsen. Mit steigender Komplexität der Softwaresysteme hat sich bei der Softwareentwicklung immer mehr die Kommunikation zwischen den Beteiligten und die Koordination der Softwareentwicklung als Hauptproblem herausgestellt. Zur Lösung dieser Situation konnte sich in den letzten Jahren die Softwareentwicklung über Modellierung als hilfreicher Ansatz erweisen.
Bei der Modellierung wird ein Modell über das umzusetzende Problem zuerst in einer abstrakten Form dargestellt und analysiert, wozu statische und dynamische Informationen zusammengetragen werden. Da sich im Entwicklungsbereich in vielen Fällen grafische Präsentationen als vorteilhaft für den Informationsaustausch zwischen den beteiligten Gruppen erwiesen haben, hat sich als Sprache für die Modellierung objektorientierter Systeme die Unified Modeling Language (UML) etabliert. Durch die Darstellungsmöglichkeiten der UML ist es möglich, die vielfältigen Aspekte von komplexen Programmen grafisch abzubilden. Ein weiterer Vorteil hat sich durch die Entwicklung von CASE-Programmen ergeben, die UML-Diagramme und -Objekte direkt in ausführbaren Programmcode umwandeln. Als verbreitete Programme für diesen Bereich sind RATIONAL, RHAPSODY und POSEIDON zu nennen.
Ein Vorteil der automatischen Umsetzung von grafischen Darstellungen in ausführbaren Programmcode ist eine verminderte Fehleranfälligkeit des Umsetzungsprozesses und des erzeugten Programmcodes, da auf Umsetzungsprogramme zurückgegriffen werden kann, die durch die breite Nutzung gut getestet und anwendungserprobt sind. Hierdurch verlagert sich das Problem der Fehlererkennung weg von der Codeerstellungsebene hin auf die höhere, abstraktere Ebene der grafischen Modellbeschreibung. Es ist demzufolge notwendig, dass die zugrunde liegende Beschreibungssprache eindeutig und einheitlich definiert ist. Für die Syntax der UML ist dies der Fall, da sich die UML teilweise über ihr Metamodell selber definiert. Da aber die Semantik der UML-Objekte in natürlicher Sprache ausgedrückt wird, verbirgt sich hier die Gefahr von Missverständnissen in der Interpretation der UML-Objekte. Eine weitere Forderung, die in den letzten Jahren immer nachdrücklicher verfolgt wird, ist die automatische Verifizierung. Hierbei sollen Testsequenzen automatisch anhand der erstellten Modelle generiert werden, die eine vollständige Verifizierung des Modells ermöglichen.
Diese Arbeit soll im begrenzten Bereich der UML-Statecharts einen Ansatz finden. Die Transformation eines UML-Statecharts mit seinen komplexen Elementen soll auf eine einfachere äquivalente Darstellung mittels erweiterter endlicher Zustandsmaschinen (EFSM) für die Analyse und Erstellung einer Testumgebung vereinfacht werden. Somit ist die Aufgabenstellung für diese Arbeit die Erstellung einer Transformationsvorschrift, welche, basierend auf der Auswertung eines in einem XMI-Dokument hinterlegten UML-Statecharts, eine gleichwertige, erweiterte endliche Zustandsmaschine erstellt. Um das Ergebnis der Transformation für die UML-Gemeinde zur Verfügung zu stellen, wird das Transformationsergebnis wieder als UML-Statechart dargestellt.
Die Arbeit beginnt mit einer Literaturrecherche für Testfolgenableitungen aus UML-Spezifikationen. Durch die Literaturrecherche soll ein Vergleich der Arbeit mit bestehenden Lösungen ermöglicht werden. Darauf folgt eine Übersicht des Transformationsprozesses und der zugrunde liegenden Verfahren und Komponenten.
Im Kapitel 2 erfolgt eine Einführung in die UML-Zustandsdiagramme und deren Elemente, wobei ein kurzer Überblick über die Entwicklung der UML gegeben wird.
Darauf aufbauend wird die XMI-Transformation auf Basis der XML angerissen, um im Kapitel 6 die Transformation der UML-Statecharts in eine erweiterte endliche Zustandsmaschine, kurz EFSM (Extended Finite State Machines), darzustellen. Aufgrund der ermittelten Transformationsvorschriften wird an einem einfachen Beispiel die Umsetzung aufgezeigt. Abschließend erfolgt die Zusammenfassung der Ergebnisse.
Inhaltsverzeichnis:
| Kurzfassung | I | |
| Inhaltsverzeichnis | II | |
| Abbildungsverzeichnis | IV | |
| Tabellenverzeichnis | V | |
| Abkürzungsverzeichnis | VI | |
| 1. | Einleitung | 1 |
| 1.1 | Aufgabenstellung | 1 |
| 1.2 | Aufbau der Arbeit | 2 |
| 1.3 | Literaturvergleich zur Testfolgenableitung aus UML-Spezifikationen | 2 |
| 1.4 | Darstellung des Transformationsprozesses | 3 |
| 2. | Die Grundlagen von UML | 4 |
| 2.1 | Die Entwicklung von UML | 4 |
| 2.2 | Eine Einführung in UML-Statecharts | 5 |
| 2.3 | Beschreibung der UML-Statechart-Objekte | 7 |
| 2.4 | Spezielle Formen von Transitionen | 16 |
| 2.5 | Transitionskonflikte | 16 |
| 2.6 | Ereignisverarbeitung | 17 |
| 3. | Die Grundlagen von XML | 17 |
| 3.1 | Die Metasprache XML | 17 |
| 3.2 | Die XML-Syntax | 18 |
| 4. | Die Grundlagen von XMI | 21 |
| 4.1 | XMI-Darstellung der verwendeten UML-Statecharts-Elemente | 22 |
| 4.2 | Programmbedingte Abweichungen bei der Transformation von UML nach XMI | 23 |
| 4.3 | Auflistung der aus einem XMI-Dokument für die Transformation extrahierten UML-Objekte | 24 |
| 5. | Erweiterte endliche Zustandsmaschinen | 30 |
| 5.1 | Formale Beschreibung der verwendeten erweiterten endlichen Zustandsmaschine | 30 |
| 5.2 | Darstellung der EFSM als reduziertes UML-Statechart-Klassendiagramm | 32 |
| 6. | Transformationsbeschreibung | 34 |
| 6.1 | Einschränkung der transformierten UML-Objekte | 34 |
| 6.2 | Übersicht der transformierten UML-Objekte | 34 |
| 6.3 | Voraussetzungen für die Transformation | 36 |
| 6.4 | Ablauf der Transformation | 37 |
| 6.5 | Beschreibung der einzelnen Transformationsschritte | 40 |
| 6.6 | Verifikation des Transformationsalgorithmus | 50 |
| 6.7 | Bewertung der Ergebnisse des Transformationsalgorithmus | 50 |
| 7. | Zusammenfassung | 51 |
| 7.1 | Kritik der UML-Definition | 51 |
| 7.2 | Kritik des Transformationsalgorithmus | 52 |
| 7.3 | Ausblick | 52 |
| Literaturverzeichnis | 53 | |
| Anhang | 55 |
Eine erweiterte endliche Zustandsmaschine soll das Verhalten eines Objektes in seiner Umgebung beschreiben. Die wesentlichen Komponenten einer Zustandsmaschine sind Zustände und Transitionen, die Übergänge zwischen zwei Zuständen definieren. Ein Zustand stellt eine Situation dar, in der die Zustandsmaschine auf eine Eingabeaktion wartet, wobei immer nur ein Zustand aktiv sein kann. Eine Zustandsmaschine hat einen definierten Startzustand. Bei einer auftretenden Eingabeaktion wird überprüft, ob eine vom aktiven Zustand ausgehende Transition von der Eingabeaktion aktiviert wird. Für diesen Vorgang wird auch der Begriff „gefeuert“ oder „getriggert“ verwendet. Da immer nur eine Transition aktiviert werden kann, ist dies bei der Erstellung der Zustandsmaschine zu beachten, was durch die geeignete Wahl der Eingabeaktionen und Wächterbedingungen pro Zustand zu erfolgen hat. Wird bei einer Transition keine Eingabeaktion definiert, bedeutet dies, dass die Transition, ohne auf eine Eingabeaktion zu warten, triggert. Die Wächterbedingungen werden durch eine boolesche Verknüpfung von Variablen und von Funktionen der Variablen definiert, welche bei einer wahren Aussage das Feuern der zugehörigen Transition nicht behindern. Ist eine leere Wächterbedingung angegeben, ergibt die Auswertung WAHR. Weiterhin kann nach der Aktivierung einer Transition eine Ausgabeaktion abgearbeitet werden. [...]
Bei der Verwendung der Programme zur Erstellung von UML-Modellen und deren Export als XMIDokument wurde festgestellt, dass es Differenzen zwischen den Definitionen von UML und XMI und den Ausgaben der Programme gibt. Für die Umsetzung der Transformation spielen diese Einschränkungen keine Rolle, nur beim Testen der Transformation ergaben sich Einschränkungen, da nicht der volle Umfang der UML-Definition verifiziert werden konnte. UML-Pseudoobjekt „junction“ UML-Pseudoobjekt „junction“ wird beim Export aus Rhapsody eliminiert und die Transitionen werden direkt mit den Zuständen verbunden, so dass eine äquivalente Beschreibung entsteht. Weiterhin gibt es in „Rhapsody in C“ die Einschränkung, dass nur eine vom Pseudoelement „junction“ ausgehende Transition erlaubt ist. In den Transformationsregeln wird dieser Pseudozustand entsprechend der UML-Definition umgesetzt. UML-Pseudoobjekt „choise“ Das UML-Pseudoobjekt „choise“ wird in das XMI-Element „Behavioral_Elements.State_Machines. Pseudostate.kind“ mit dem Attribut „branch“ transformiert. Auch hier besteht im UML-Tool eine Einschränkung der Art, dass nur eine eingehende Transition zugelassen wird. Für die Transformation wird davon ausgegangen, dass im XMI-Dokument der Pseudozustand „branch“ einem Pseudozustand „choise“ im UML-Dokument entspricht. XMI-Pseudoobjekt Attribut „final“ Dieses Attribut wird in der UML-Definition für Pseudozustände nicht verwendet. [...]
Da UML eine grafische Modelldarstellung ist, ist es sehr aufwändig, diese grafischen Modelle automatisch zwischen EDV-Systemen auszutauschen. Um diesem Problem zu begegnen, wurde eine textuelle Austauschsprache auf Basis von XML definiert. Da eine einführende Beschreibung von XML in dem vorherigen Kapitel gegeben wurde, konzentriert sich dieser Abschnitt auf die XMI-DTD und den daraus entstehenden XML-Dokumenten, wobei der Fokus auf der Generierung von Statechart-Modellen liegt. In der XMI-Definition der OMG (Object Management Group) wurde festlegt, wie ein UML-Modell durch eine auf XML basierende Auszeichnungssprache textuell dargestellt werden kann. XMI transformiert dabei nicht nur das UML-Modell, sondern gibt die vom UML-Modell verwendeten Komponenten des UML-Metamodells mit an. Dies basiert auf der vierstufigen Metamodell-Architektur (MOF), die ebenfalls vom OMG definiert wurde und dient dazu, Metadaten zu definieren und als CORBA-Objekte ([TC98], [HV99]) darzustellen. Da es verschiedene Lösungsmöglichkeiten für die Definition eines XMIDTD gibt, können sich die entstehenden XMI-Dokumente sehr stark unterscheiden, so dass die Auswertung eines XMI-Dokumentes nur unter Benutzung des zugehörigen DTD-Dokumentes vollzogen werden kann. [...]
In den Warenkorb
98,00 €
Link zur Arbeit:
http://www.diplom.de/ean/9783832486839
Arbeit zitieren:
Böddeker, Rudolf Januar 2005: Transformation erweiterter Zustandsmaschinen aus UML-Statecharts unter Verwendung von XMI, Hamburg: Diplomica Verlag
Schlagworte:
XML, Rhapsody, EFSM, Softwareentwicklung, Poseidon



