Transformation erweiterter Zustandsmaschinen aus UML-Statecharts unter Verwendung von XMI
©2005
Diplomarbeit
87 Seiten
Zusammenfassung
Inhaltsangabe: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 […]
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 […]
Leseprobe
Inhaltsverzeichnis
ID 8683
Böddeker, Rudolf: Transformation erweiterter Zustandsmaschinen aus UML-Statecharts
unter Verwendung von XMI
Hamburg: Diplomica GmbH, 2005
Zugl.: FernUniversität - Gesamthochschule Hagen, Diplomarbeit, 2005
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2005
Printed in Germany
Erklärung
Ich versichere, dass ich die vorliegende Diplomarbeit selbständig verfasst und keine anderen Quellen
und Hilfsmittel als die angegebenen benutzt habe. Die Stellen, die anderen Werken dem Wortlaut
oder Sinn nach entnommen wurden, habe ich unter der Angabe der Quelle als Zitat kenntlich ge-
macht.
Paderborn, den 24.01.2005
________________________
Rudolf Böddeker
I
Kurzfassung
Da die Verifikation von UML-Statecharts aufgrund der Komplexität der UML-Objekte sehr aufwändig
ist, wird in der vorliegenden Arbeit eine Transformationsregel für nicht konkurrierend arbeitende UML-
Statecharts dargestellt. Die Transformation erfolgt auf der Basis eines XMI-Dokumentes des UML-
Statecharts, welches in eine erweiterte endliche Zustandsmaschine umgewandelt wird und wieder als
UML-Statechart visualisiert werden kann.
II
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
III
Literaturverzeichnis...53
Anhang 1 ...55
IV
Abbildungsverzeichnis
Abb. 1: Zusammenwirken der verwendeten IT-Methoden für die Transformation ...3
Abb. 2: Klassendiagramm entsprechend der UML-Definition, Abbildung 2-
24 ,,State Machines Main"
...6
Abb. 3: Klassendiagramm entsprechend der UML-Definition, Abbildung 2-
25 ,,State Machines
Events"
...7
Abb. 4: Beispiel eines zusammengesetzten Zustandes ...8
Abb. 5: Beispiel eines XML-Dokumentes...19
Abb. 6: Beispiel einer XML-Elementdefinition ...20
Abb. 7: Beispiel einer XML-Attributdefinition...21
Abb. 8: Die OMG 4-Ebenen-Metamodell-Architektur - Meta-Object Facility (MOF)...22
Abb. 9: Darstellung des reduzierten UML-Statechart-Klassendiagramms auf Basis der verwendeten
EFSM ...33
Abb. 10: Darstellung des UML-Statechart-Klassendiagramms auf Basis der transformierten UML-
Objekte ...35
Abb. 11: UML-Statechart mit einer Unterzustandsmaschine in einem Unterzustandsmaschinenzustand
...40
Abb. 12: Verschachtelung von zusammengesetzten Zuständen und Zuständen im XMI-Dokument ...40
Abb. 13: Ergebnis der Extrahierung des zusammengesetzten Zustandes...41
Abb. 14: Transformation eines Startzustandes ...41
Abb. 15: Transformation eines Endzustandes ...42
Abb. 16: Transformation eines statischen Verzweigungspunktes...43
Abb. 17: Transformation eines statischen Verzweigungspunktes mit ELSE-Anweisung in einer
Wächterbedingung...43
Abb. 18: Transformation eines dynamischen Verzweigungspunktes ...44
Abb. 19: UML-Darstellung eines flachen Historyzustands in Rhapsody...45
Abb. 20: Darstellung der Transformation eines flachen Historyzustands ...45
Abb. 21: Beispiel für die Verflachung einer Unterzustandsmaschine...48
Abb. 22: Ergebnis der Verflachung einer Unterzustandsmaschine...48
V
Tabellenverzeichnis
Tabelle 1: Operationen für die Angabe von Elementinhalten...20
Tabelle 2: Zuordnung UML-Definition
XMI-Metamodellbeschreibung der DTD. ...22
Tabelle 3: Zuordnung der UML-Pseudozustandsdefinition
XMI-Metamodellbeschreibung der DTD.23
Tabelle 4: Umgesetzte UML-Objekte...35
Tabelle 5: Extrahierte Elemente eines Zustandes...38
Tabelle 6: Extrahierte Elemente einer Transition ...39
Tabelle 7: Extrahierte Elemente eines Signalereignisses...39
Tabelle 8: Extrahierte Elemente eines Signals...39
VI
Abkürzungsverzeichnis
AGEDIS Automated Generation and Execution of Test Suites for Distributed Component-based
Software
DTD
Document Type Definition
EBNF Erweiterte Backus-Naur Form
EDV
Elektronische Datenverarbeitung
EFSM
Extended Finite State Machine
EIOLTS Extended Input Output Labeled Transition System
IF
Intermediate Format
ISO
International Organization for Standardization
MOF
Meta Object Facility
OCL
Object Constraint Language
OMG
Object Management Group
OMT
Object Modeling Technique
OOSE Object-Oriented Software Engineering
PI
Processing Instructions
SGML Standard Generalized Markup Language
UML
Unified Modeling Language
W3C
World Wide Web Consortium
XMI
XML Metadata Interchange
XML
Extensible Markup Language
1
1.
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 Software-
systeme hat sich bei der Softwareentwicklung immer mehr die Kommunikation zwischen den Beteilig-
ten 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 zu-
sammengetragen 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 Pro-
grammcode 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 Prob-
lem der Fehlererkennung weg von der Codeerstellungsebene hin auf die höhere, abstraktere Ebene
der grafischen Modellbeschreibung. Es ist demzufolge notwendig, dass die zugrunde liegende Be-
schreibungssprache 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ückli-
cher verfolgt wird, ist die automatische Verifizierung. Hierbei sollen Testsequenzen automatisch an-
hand der erstellten Modelle generiert werden, die eine vollständige Verifizierung des Modells ermögli-
chen.
1.1.
Aufgabenstellung
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 Darstel-
lung 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 hin-
terlegten 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 Transformati-
onsergebnis wieder als UML-Statechart dargestellt.
2
1.2.
Aufbau der Arbeit
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 wer-
den. Darauf folgt eine Übersicht des Transformationsprozesses und der zugrunde liegenden Verfah-
ren und Komponenten. Im Kapitel 2 erfolgt eine Einführung in die UML-Zustandsdiagramme und de-
ren Elemente, wobei ein kurzer Überblick über die Entwicklung der UML gegeben wird. Darauf auf-
bauend wird die XMI-Transformation auf Basis der XML angerissen, um im Kapitel 6 die Transformati-
on 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 Ergeb-
nisse.
1.3.
Literaturvergleich zur Testfolgenableitung aus UML-Spezifikationen
Um das Ergebnis der Arbeit mit bestehenden Arbeiten vergleichen zu können, werden nachfolgend
verschiedene Ansätze in der Literatur dargestellt. Eine Suche verschiedener Bibliothekensuchmaschi-
nen führte nur zu einer Angabe [UH01], die leider nicht verfügbar ist. Eine weitere Suche über das
Internet führte zu einer größeren Anzahl von Treffern. Es erfolgt eine stichpunktartige Zusammenfas-
sung, wobei der Focus auf dem Vergleich der verwendeten Transformationsverfahren liegt.
David Lugato et al. [LBV02] beschreiben die Transformation einer UML-Spezifikation mit dem Ziel, das
Transformationsergebnis mit der Testumgebung AGATHA zu testen. AGATHA ist eine Testumgebung
zur Validierung kommunizierender nebenläufiger Einheiten. Hierzu wird der EIOLTS-Algorithmus (Ex-
tended Input Output Labeled Transition System) verwendet, welcher eine symbolische Ausführung
von Operationen verwendet. Die beschriebene Transformation der UML-Spezifikation lässt keine Ein-
schränkung von zusammengesetzten und hierarchischen Zuständen, keine Pseudozustände außer
dem Startzustand und keine Aktionen oder Aktivitäten in Zuständen zu.
In [RPG02] stellen Riebisch et al. eine Testgenerierung basierend auf der Verfeinerung der UML-
Spezifikation dar. Hierzu werden UML-Use-Case-Diagramme nach der im Dokument beschriebenen
Methode genauer definiert, um darauf aufbauend UML-Statecharts zu erstellen, die wiederum in ein
Anwendungsdiagramm umgewandelt werden. Bei dieser Transformation werden die hierarchischen
Strukturen der UML-Statecharts aufgelöst, wobei eine Behandlung der UML-spezifischen Objekte
nicht beschrieben wird. Das erstellte Anwendungsdiagramm dient als Grundlage für die Generierung
eines Anwendungsmodells, aus dem die Testfälle erstellt werden.
C. Crichton et al. beschreiben [CCD01] die Transformation eines UML-Modells in die Toolsprache
Intermediate Format (IF). IF ist so konzipiert, dass deren Dokumente in andere Hochsprachen
übersetzbar sind und als Basis für weitere Tools, zum Beispiel Testgenerierungsprogramme, nutzbar
sind. Da IF als Eingangsformat eine eigene, auf XML beruhende, Auszeichnungssprache nutzt, ist es
notwendig, ein UML-Modell als XMI-Dokument zu exportieren. Dieses XMI-Dokument wird nun durch
ein weiteres Tool in das IF-Eingangsformat übersetzt. Bei dieser Transformation werden einfache
Zustände, Startzustände, Endzustände und Unterzustandsmaschinen, die über keine Transitionen mit
Zuständen außerhalb der Unterzustandsmaschine verbunden sind, transformiert. Dieses Dokument
3
wurde im Rahmen des AGEDIS-Projektes (Automated Generation and Execution of Test Suites for
Distributed Component-based Software) der europäischen Union erstellt.
Einen ähnlichen Ansatz beschreibt Michael Meisinger in [MM00], wo UML-Statecharts mittels eines
Transformationsalgorithmus für den Siemens Testfallgenerator TDE aufbereitet werden. Auch hier
wird die Transformation von einfachen Zuständen, Startzuständen, Endzuständen und Unterzu-
standsmaschinen, die über keine Transitionen mit Zuständen außerhalb der Unterzustandsmaschine
verbunden sind, unterstützt.
In ,,UML
-
based Test Generation and Execution" [HV
FR04] von J. Hartmann et al. wird ebenfalls eine
Transformation eines UML-Modells vorgenommen, um bestehende Testgenerierungs- und Testaus-
wertungswerkzeuge zu benutzen. Als Besonderheit ist zu bemerken, dass die Anforderungen an die
Testerstellungen in UML-Diagrammen als Text hinterlegt werden können. Diese Texte werden im
weiteren Verlauf der Testerstellung verwendet, um den Testablauf zu spezifizieren. Einzelheiten zu
den transformierten UML-Statechart-Objekten werden nicht angegeben.
Lionel Van Aertryck und Thomas Jensen beschreiben mit ,,
UML-CASTIN
G"
[AJ03] eine Methode, die
einfache Testfälle für jeden booleschen und arithmetischen Ausdruck einer UML-Klasse ermittelt. Auf
diesen Testfällen aufbauend werden Testsequenzen generiert, die zum Ziel haben, alle Testfälle für
alle Ausdrücke einer UML-Klasse zu durchlaufen. Der Vorteil dieser Methode ist die direkte Anwend-
barkeit auf UML-Klassen, wobei auf die Umsetzung der einzelnen UML-Statechart-Objekte nicht ein-
gegangen wird.
1.4.
Darstellung des Transformationsprozesses
Abb. 1: Zusammenwirken der verwendeten IT-Methoden für die Transformation
UML-Statechart
XMI-Dokument
UML-
Meta-Modell
XMI
XML
EFSM-
Darstellung
XMI > EFSM-
Transformations-
vorschrift
EFSM-
Modell
MOF
4
Um das Ziel, die Transformation von UML-Zustandsdiagrammen zu einer EFSM durchzuführen, zu
erreichen, wurden verschiedene IT-Methoden verwendet. Da die einzelnen Schritte auf komplexen
Definitionen und Umsetzungsvorschriften beruhen, ist der Einsatz von EDV-Programmen für die effek-
tive Erstellung und Umwandlung unerlässlich. In dieser Arbeit wurden hierzu folgende Programme
benutzt:
Rhapsody in C, Version 5.0.1
,,Rhapsody in C" ist ein Programm der I
-Logix Inc., Massachusetts, USA, welches die grafische
Modellierung entsprechend den UML-Definitionen erlaubt. Die UML-Modelle können über die
Transformation in ein C-Programm zu einem ausführbaren Programm umgewandelt werden. Das
Programm basiert vorwiegend auf der UML-Version 1.5, es sind aber auch schon Elemente der
UML-Version 2.0 implementiert. Genauere Informationen sind in der Releasedokumentation
[RH50] enthalten. Leider entspricht die grafische Darstellung der UML-Objekte nicht immer dem
UML-Standard, wie zum Beispiel bei der Darstellung von statischen oder dynamischen Verzwei-
gungspunkten.
XMI Toolkit for Rhapsody, Version 1.6.7
,,XMI Toolkit for Rhapsody" ist eine Erweiterung des Programms ,,Rhapsody in C"
, welches den
Ex- und Import von in Rhapsody erstellen UML-Modellen erlaubt. Dieses Tool verwendet die XMI-
Definition Version 1.0 [XMI10].
Für diese Arbeit wurden die Versionen 1.5 für UML [UML15] und 1.0 für XMI [XMI10] verwendet. An-
gaben zu UML- oder XMI-Definitionen ohne nähere Angaben beziehen sich auf diese Versionen.
2.
Die Grundlagen von UML
2.1.
Die Entwicklung von UML
Nachdem in den späten 80er Jahren objektorientierte Programmiersprachen in vielen Bereichen weite
Verbreitung fanden, wurde Anfang der 90er Jahre der objektorientierte Ansatz auf den
Softwareentwicklungsprozess übertragen. Es entstanden verschiedene Methoden, wobei als
wichtigste OMT [RLEBP93], Booch [BOOCH94] und OOSE [JCJÖ92] zu nennen sind. Der
Unterschied der verschiedenen Methoden war der gesetzte Schwerpunkte, der zum Teil auf das
dynamische, prozessorientierte Verhalten gelegt war, bei anderen Verfahren lag das Ziel hingegen
eher bei der Erweiterung bestehender Datenverwaltungsanwendungen oder bei der Modellierung. Bis
Mitte der 90er Jahre war nicht klar, welche der Modellierungsmethoden sich durchsetzen würden.
Daher wurde das Zusammenkommen der Begründer der drei bekanntesten Entwurfsmethoden Grady
Booch (Booch), Jim Rumbaugh (OMT) und Ivar Jacobson (OOSE) von vielen begrüßt, welche nun
allgemein als
,,
die drei Amigos
"
bekannt sind. Diese arbeiteten unter dem Dach der Firma Rational
gemeinsam weiter und veröffentlich
ten 1996 ihre Methode unter dem Namen UML ,,Unified Modeling
Language". 1997 wurden de
r OMG (Object Management Group) neben diversen Vorschlägen anderer
5
Organisationen auch die Version 1.0 der UML von Rational vorgelegt, woraus dann die UML-Version
1.1 als offizieller OMG-Standard hervorging. In diesem Standard sind weitere Einflüsse zum Tragen
gekommen, wie zum Beispiel im Bereich der Zustandsdiagramme von D. Harel [HAREL87] oder im
Bereich Aktivitätsdiagramme von Martin/Odell [MO92]. Seitdem befindet sich der offizielle UML-
Standard in stetiger Weiterentwicklung und hat als aktuelle Version den Stand 2.0, der im November
2004 als Standard verabschiedet wurde. Aufgrund der verwendeten Programme wurde die Version
1.5 vom 01.03.2003 als Basis für diese Arbeit genutzt.
2.2.
Eine Einführung in UML-Statecharts
Eng verbunden mit dem Begriff des Statecharts in UML ist das Konzept der Zustandsmaschine von
David Harel [HAREL87]. Unter UML stellt ein Statechart eine Zustandsmaschine dar, die durch ein
Zustandsdiagramm definiert wird und das Verhalten eines UML-Objektes beschreibt. Eine Zustands-
maschine befindet sich immer in einem Zustand, der auch aktiver Zustand genannt wird. Eine Aus-
nahme bilden hierbei Zustandsmaschinen in zusammengesetzten Zustandsmaschinen. Zustände
stellen Situationen innerhalb eines Objektes dar, welche durch Transitionen, die zwei Zustände mit-
einander verbinden, verknüpft sind. Inhaltlich stellen Zustände länger anhaltende Positionen eines
Objektes dar, während Transitionen Reaktionen des Objektes auf ein Ereignis wiedergeben. Aller-
dings müssen nicht alle Zustände auf alle Ereignisse reagieren. Die Ausführung einer Transition kann
durch eine Wächterbedingung (guard) verhindert werden. Diese Wächterbedingung ist ein boolescher
Ausdruck, dessen Wahrheitswert eine zusätzliche Voraussetzung für das Triggern oder Schalten einer
Transition ist. Bei der Ausführung einer Transition kann eine Ausgangsaktion des zu verlassenden
Zustandes ausgeführt werden, ebenso wie eine Eingangsaktion des zu erreichenden Zustandes. Akti-
onen (actions) sind im Gegensatz zu Aktivitäten (activities) nicht durch Ereignisse unterbrechbare
Vorgänge. Aktivitäten hingegen sind Vorgänge, die innerhalb von Zuständen über einen längeren
Zeitraum bearbeitet werden.
6
2.2.1.
Beschreibung der in UML 1.5 definierten Statechart-Objekte als UML-
Klassendiagramm
Abb. 2: Klassendiagramm entsprechend der UML-Definition [UML15: Abbildung 2-
24 ,,State Mach
ines
Main"
]
ModelElement
StateMachine
context
+
0..1
behavior
+
*
StubState
Guard
StateVertex
State
Procedure
Transition
SynchState
SimpleState
FinalState
ComposteState
PseudoState
SubmachineState
Event
0..1
*
trigger
+
0..1
*
deferrableEvent
+
*
0..1
entry
+
0..1
0..1
exit
+
0..1
0..1
doActivity
+
0..1
0..1
top
+
0..1
transition
+
*
0..1
effect
+
0..1
source
+
incoming
+
*
target
+
outgoing
+
*
0..1
internalTransition
+
*
submachine
+
*
container
+
0..1
subvertex
+
*
7
Abb. 3: Klassendiagramm entsprechend der UML-Definition [UML15: Abbildung 2-
25 ,,State Machines
E
vents"
]
2.3.
Beschreibung der UML-Statechart-Objekte
Um eine eindeutige Grundlage für die Transformation zu legen, werden die UML-Statechart-Objekte
nachfolgend einzeln dargestellt. Dies erfolgt auch aufgrund der Feststellung, dass die UML-Definition
nicht immer eindeutig ist oder oft nicht klar erkennbar ist, welche UML-Definition von einem Programm
verwendet wird. Diese Problematik wird in der Zusammenfassung näher dargelegt. Die Transformati-
on basiert auf der Beschreibung der UML-Statechart-Objekte in der UML-Definition im Kapitel 2.12,
welche die Semantik der UML-Statechart-Objekte beschreibt. Für jedes Element der Definition wird
eine kurze Erläuterung mit der UML-Kapitelangabe angeführt. Falls eine visuelle Repräsentation für
das UML-Statechart existiert, wird diese dargestellt.
2.3.1.
Aufrufereignis
Kapitel: 2.12.2.1
Name laut UML-Definition:
CallEvent
Dieses Ereignis ist mit einer Operation verbunden, wobei das Ereignis mit dem Aufrufen der Operation
generiert und versendet wird. Eine Operation ist ein UML-Objekt, welches Methoden bereitstellt, die
für die Bearbeitung von UML-Objekten benötigt werden.
8
2.3.2.
Änderungsereignis
Kapitel: 2.12.2.2
Name laut UML-Definition:
ChangeEvent
Ein Änderungsereignis basisiert auf einem booleschen Ausdruck, der laufend überwacht wird. Ergibt
die Auswertung dieses Ausdruckes WAHR, wird unverzüglich ein Ereignis erstellt. Ein weiteres Ereig-
nis kann erst wieder generiert werden, wenn der boolesche Ausdruck zuvor den Zustand FALSCH
angenommen hatte. Das generierte Ereignis ist nach seiner Erstellung unabhängig von seinem auslö-
senden Vorgang.
2.3.3.
Zusammengesetzter Zustand
Kapitel: 2.12.2.3
Name laut UML-Definition:
CompositeState
Ein zusammengesetzter Zustand ist ein Zustand, der aus verschiedenen anderen Zuständen besteht.
Weiterhin kann er auch konkurrierend ablaufende Zustandsmaschinen enthalten, welche dann Regio-
nen (UML-
Syntax ,,regions") genannt werden. In dem Beispiel
der Abbildung 4 sind zwei konkurrierend
ablaufende Zustandsmaschinen ,,Substatemachine1" und ,,Substatemaschine2" abg
ebildet, der Name
des zusam
mengesetzten Zustandes ist ,,state_1".
state_1
Substatemachine1
Substatemachine2
state_1
state_3
state_2
state_5
state_4
state_1
Substatemachine1
state_3
state_2
Substatemachine2
state_5
state_4
Abb. 4: Beispiel eines zusammengesetzten Zustandes
2.3.4.
Ereignis
Kapitel: 2.12.2.4
Name laut UML-Definition:
Event
Ein Ereignis soll eine Reaktion der Zustandsmaschine auslösen. Das UML-Obj
ekt ,,Ereignis" ist eine
übergeordnete Klasse, welche die UML-Objekte Aufrufereignis, Änderungsereignis, Signalereignis
und zeitgesteuertes Ereignis zusammenfasst. In diesem UML-Modell wird davon ausgegangen, dass
Ereignisse zu einem bestimmten Zeitpunkt ohne zeitliche Ausdehnung generiert werden.
9
2.3.5.
Endzustand
Kapitel: 2.12.2.5
Name laut UML-Definition:
FinalState
Symbol :
Der Endzustand gibt an, dass der zugehörige zusammengesetzte Zustand oder die Zustandsmaschi-
ne abgearbeitet wurde. Ein Endzustand kann keine ausgehenden Transitionen haben. Wenn der End-
zustand in einer Unterzustandsmaschine liegt, wird die Bearbeitung der Unterzustandsmaschine be-
endet und, falls vorhanden, eine spontane gehende Transition des Oberzustandes aufgeführt. Hierbei
wird die Ausgangsaktion des Oberzustandes ausgeführt, wenn diese definiert ist.
2.3.6.
Wächterbedingung
Kapitel: 2.12.2.6
Name laut UML-Definition:
Guard
Die Wächterbedingung ist Teil der Beschreibung einer Transition. Sie ist ein boolescher Ausdruck, der
neben einer Triggerbedingung erfüllt sein muss, um eine Transition auszulösen. Ist keine Wächterbe-
dingung angegeben, ergibt die Auswertung der Wächterbedingung immer WAHR. Neben den boole-
schen Ausdrücken ist die ELSE-Anweisung definiert, die WAHR wird, wenn die Wächterbedingungen
aller sonstigen von einem Zustand ausgehenden Transitionen FALSCH sind.
2.3.7.
Pseudozustand
Kapitel: 2.12.2.7
Name laut UML-Definition:
PseudoState
Pseudozustände sind eine Klasse von verschiedenen Zuständen mit speziellen Eigenschaften, die nur
als Durchgangszustände arbeiten. Daher muss sichergestellt sein, dass eine Transition, die über
Pseudozustände verläuft, in einem Zielzustand endet, der kein Pseudozustand ist. Falls dies nicht
eintritt, wird die Transition nicht gefeuert.
Folgende Pseudozustände sind definiert:
10
2.3.8.
Startzustand
Name laut UML-Definition:
Initial
Symbol :
Ein Startzustand führt über eine sp
ontane Transition zum ,,default"
-Zustand der Zustandsmaschine. Er
wird automatisch ausgeführt, wenn eine Zustandsmaschine realisiert oder zum ersten Mal aufgerufen
wird. Eine Ausnahme können Transitionen auf Historyzustände bilden. Startzustände treten auch in
Unterzustandsmaschinen und zusammengesetzten Zuständen auf. Jede Zustandsmaschine, Unter-
zustandsmaschine und zusammengesetzter Zustand können jeweils nur einen Startzustand haben.
Besteht ein zusammengesetzter Zustand aus verschieden Regionen, ist für jede Region ein Startzu-
stand anzugeben. Der Startzustand kann eine Aktion ausführen, die zu Initialisierungszwecken der
Zustandsmaschine genutzt werden kann.
2.3.9.
Historyzustände
Tiefer Historyzustand
Name laut UML-Definition:
deepHistory
Symbol:
Flacher Historyzustand
Name laut UML-Definition:
shallowHistory
Symbol:
Ein Historyzustand merkt sich den zuletzt belegten Zustand in einer Zustandsmaschine. Wird die Un-
terzustandsmaschine über eine Transition, die zu einem Historyzustand führt, aufgerufen, wird der
zuletzt belegte Zustand der Unterzustandsmaschine aktiviert. Von einem Historyzustand geht eine
Transition zum Startzustand der Unterzustandsmaschine, der ausgeführt wird, wenn der History-
zustand aufgerufen wird, ohne dass die Unterzustandsmaschine vorher benutzt wurde. Der Unter-
schied zwischen einem tiefen und einem flachen Historyzustand ist, dass bei einem tiefen History-
Details
- Seiten
- Erscheinungsform
- Originalausgabe
- Jahr
- 2005
- ISBN (eBook)
- 9783832486839
- ISBN (Paperback)
- 9783838686837
- DOI
- 10.3239/9783832486839
- Dateigröße
- 623 KB
- Sprache
- Deutsch
- Institution / Hochschule
- FernUniversität Hagen – Elektrotechnik und Informationstechnik
- Erscheinungsdatum
- 2005 (April)
- Note
- 1,3
- Schlagworte
- rhapsody efsm softwareentwicklung poseidon
