Spezifikationsmodule - Software and Systems Engineering - TUM

Modellbasierte
Entwicklung:
Spezifikationsmodule
Diplomarbeit
Florian Hölzl

Technische Universität München
Fakultät für Informatik
Modellbasierte
Entwicklung:
Spezifikationsmodule
Diplomarbeit
Aufgabensteller:
Betreuer:
Bearbeiter:
Prof. Dr. Dr. h.c. Manfred Broy
Dr. Bernhard Schätz
Florian Hölzl
Abgabedatum: 13. Mai 2005

Ich versichere, dass ich diese Diplomarbeit selbständig verfasst und nur die angegebenen
Quellen und Hilfsmittel verwendet habe.
Unterschleissheim, den 12. Mai 2005
(Florian Hölzl)

”Nimm an hier ist eine Aussage. Wir wissen nicht, ob sie zu der einen Kategorie
oder der anderen gehört. Aber wenn wir die verschiedenen Kategorien in
eine zusammenwerfen, hören die Unterschiede der Kategorien auf zu existieren.
Das muss ich erklären. Wenn es einen Anfang gibt, dann gibt es eine Zeit vor
diesem Anfang und eine Zeit vor der Zeit, welche vor der Zeit dieses Anfangs
war. Wenn es das Vorhandensein gibt, musste es auch das Nicht-Vorhandensein
gegeben haben. Und wenn es eine Zeit gab zu der nichts existierte, dann muss
es auch eine Zeit gegeben haben, zu der nicht mal das Nichts existierte. Ganz
plötzlich, gab es dann das Nichts. Kann dann wirklich jemand sagen, ob es zur
Kategorie des Vorhandenseins oder des Nicht-Vorhandenseins gehört? Sogar diese
Worte die ich gerade sagte - ich kann nicht sagen, ob sie etwas bedeuten oder
nicht.”
(Chuang Tzu, 2. Kapitel: Über das Ebnen aller Dinge) 1
1
http://www.panlatrevo.com/texts/chuangtzu/
ins Englische: Yutang Lin
ins Deutsche: Florian Hölzl

Zusammenfassung
Im Bereich eingebetteter Systeme findet sich vor allem im Automobilbau eine
zunehmende Anzahl variantenreicher Einzelkomponenten. Neben anwendungsspezifischen
Teilfunktionen beinhalten sie auch allgemeine bzw. systemweit einheitliche
Funktionen, beispielsweise einen Modus zum Auslesen von Fehlerspeichern
oder systemweit einheitliche Nachrichten des Powermanagements.
Die Vereinigung von allgemeinem und speziellem Verhalten innerhalb einer
Funktionskomponente ist bisher noch kaum durch Werkzeuge unterstützt,
sondern geschieht häufig auf Ebene des Anwendungscodes. Modellbasierte Entwicklung
in Verbindung mit Modelltransformationstechniken scheinen hier ein
möglicher Weg zur Verbesserung der Situation zu sein.
In dieser Diplomarbeit wird gezeigt, wie, mit Hilfe der Transformationssprache
ODL und Spezifikationsmodellen in AutoFocus2, eine Spezifikationsvereinigung
interaktiv durch den Entwickler, durchgeführt werden kann. Die Nutzerinteraktion
ist notwendig, da zwar allgemeine Lösungen des Vereinigungsproblems
existieren, aber nicht effizient berechnet werden können. Durch die Automatisierung
und Formalisierung einzelner Teilschritte auf Spezifikationsebene kann
gegenüber der rein manuellen Durchführung auf Codeebene eine Verbesserung
der Qualität erzielt werden, indem die Fehleranfälligkeit reduziert wird.
Neben der konkreten Umsetzung anhand einer Beispielkomponente wird
auch der theoretische Hintergrund, eine allgemeinere Form des aus der Prädikatenlogik
bekannten Unifikationsverfahrens betrachtet. Die Unifikation stellt den
roten Faden dieser Arbeit dar.
In dieser Arbeit wird rein die technische Umsetzung samt der theoretischen
Grundlagen aus Sicht der Informatik betrachtet. Die Nutzung und Einbindung
solch komplexer Modelltransformationen in den Entwicklungsprozess und die
sich daraus möglicherweise ergebenden betriebswirtschaftlichen Vorteile sind
nicht mehr Teil dieser Arbeit.

Inhaltsverzeichnis
1 Einführung 3
1.1 Modellbasierte, bausteinorientierte Softwareentwicklungsprozesse 3
1.2 Konkrete Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . 4
1.3 Struktur des vorliegenden Dokuments . . . . . . . . . . . . . . . 5
2 Modelltransformationen, Werkzeuge und Beispielproblem 6
2.1 Begriffsbestimmung: Modelltransformation . . . . . . . . . . . . . 6
2.2 Das Modellierungswerkzeug AutoFocus 2 . . . . . . . . . . . . . 7
2.3 Die Transformationssprache Operation Definition Language . . . 12
2.4 Modelltransformation: AutoFocus 2 Spezifikationsvereinigung . . 14
2.5 Einschränkungen für die Modellierungselemente . . . . . . . . . . 18
2.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3 Einführungsbeispiel: Typunifikation 20
3.1 AutoFocus 2 Datentypen und Metamodell . . . . . . . . . . . . . 20
3.2 Unifikation und Typvereinbarkeit . . . . . . . . . . . . . . . . . . 23
3.3 Typvereinbarkeitsprädikat in ODL . . . . . . . . . . . . . . . . . 24
3.4 Interaktive Typvereinigung . . . . . . . . . . . . . . . . . . . . . 26
3.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4 Spezifikationsvereinigung aus theoretischer Sicht 32
4.1 Definition des Lösungsraumes . . . . . . . . . . . . . . . . . . . . 32
4.2 Unifikationsrelationen . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3 Abhängigkeiten der Modellelemente . . . . . . . . . . . . . . . . 35
4.4 Lösungsverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.5 Komplexitätsbetrachtung . . . . . . . . . . . . . . . . . . . . . . 38
4.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5 Interaktive Spezifikationsvereinigung 40
5.1 Übergang zum interaktiven Ablauf . . . . . . . . . . . . . . . . . 40
5.2 Festlegung der Dialogführung . . . . . . . . . . . . . . . . . . . . 41
5.3 Alternative Interaktionsabläufe . . . . . . . . . . . . . . . . . . . 47
5.4 Umsetzung der Dialogführung in ODL . . . . . . . . . . . . . . . 48
5.5 Konstruktion der Vereinigungskomponente . . . . . . . . . . . . . 53
5.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . 57
1

6 Fazit und Ausblick 58
6.1 Einordnung dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . 58
6.2 Ansätze zur Weiterentwicklung der ODL . . . . . . . . . . . . . . 59
6.3 ODL für andere Modellierungssprachen und -werkzeuge . . . . . 59
6.4 ODL-unterstützter Entwicklungsprozess . . . . . . . . . . . . . . 61
A ODL Programm der Spezifikationsvereinigung 62
A.1 Anmerkungen zum Programm . . . . . . . . . . . . . . . . . . . . 62
A.2 ODL Programm . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
2

Kapitel 1
Einführung
1.1 Modellbasierte, bausteinorientierte Softwareentwicklungsprozesse
Modelle spielen in vielen Bereichen der Wissenschaft und Wirtschaft eine wichtige
Rolle. Angefangen bei den Wirtschaftswissenschaften, über die Wettervorhersage
bis hin zu den Ingenieursdisziplinen, dienen Modelle zum vertieften
Verständnis der Abläufe von sozialen, natürlichen oder technischen Systemen.
Der Einsatz von Modellen hat darüber hinaus den Vorteil, dass die Eigenschaften
oder das Verhalten des betrachteten Systems bzw. Endprodukts durch Simulation
getestet oder vorhergesagt werden können.
Modellen und Modellierungstechniken kommt auch bei der Softwareentwicklung
eine tragende Rolle zu. Insbesondere sind sie hierbei nicht nur dazu geeignet,
das Problem zu veranschaulichen oder Teileigenschaften zu simulieren
oder bei formalen Modellen nachzuweisen. Vielmehr sollen diese Beschreibungen
von Softwaresystemen auch dazu dienen, einzelne Systemteile automatisch
zu erzeugen.
Aus betriebswirtschaftlicher Sicht hat modellbasiertes Vorgehen Auswirkungen
auf Kosten, Termin und Qualität. Kostenersparnisse können sich direkt
aus dem Zeitgewinn ergeben, den Softwareentwickler durch automatisierte Entwicklungsschritte
erzielen. Eine Qualitätssteigerung kann dadurch erzielt werden,
dass automatische Transformationsschritte viele Fehlerquellen manuell ausgeführter
Entwicklungsschritte schließen. Dazu trägt insbesondere der Einsatz
von formalen Methoden bei, wodurch die Korrektheit der Automatisierungen
und Transformationen mathematisch nachgewiesen werden kann.
Neben diesem innerhalb eines Softwareprojektes vorhandenen Gewinnpotential
ist für hochspezialisierte und auf einen kleinen Problembereich fokussierte
Unternehmen ein weiterer Aspekt der Softwareentwicklung interessant,
nämlich die Wiederverwendung von Einzelkomponenten und Funktionsbausteinen
in mehreren, ähnlich gelagerten Projekten oder Softwareprodukten. Diese
Bausteinorientierung hat im optimalen Fall zur Folge, dass neue Softwarelösungen
aus einem vorhandenen Satz von Einzel- oder Teillösungen schnell und kosteneffizient
zusammengesetzt werden können.
Diese Idealvorstellung ist in dieser Pauschalität für die Softwareentwicklungsbranche
kaum umsetzbar. Nichts desto trotz kann eine Überprüfung des
3

Entwicklungsprozesses und der Einzeltätigkeiten, im Hinblick auf die Wiederverwendung
von Einzelbausteinen und den Einsatz von Modelltransformationen,
Kostenersparpotentiale zu Tage fördern.
In der vorliegenden Arbeit werden wir zeigen, wie Modelltransformationen
als effiziente Entwicklungsschritte eingesetzt werden können um die Zusammensetzung
einer Gesamtlösung aus Einzelbausteinen bereits auf der Ebene der
Spezifikation durchzuführen. Wir interessieren uns hierbei weniger für das aneinander
Koppeln fertiger Komponenten, soondern wollen vielmehr die Spezifikation
von zwei Softwarekomponenten konsistent zusammenführen. Wir illustrieren
dieses Prinzip der Spezifikationsvereinigung anhand eines kleinen, aber
durchaus praxisrelevanten Beispiels. Die hier vorgestellte Transformation zeigt
die Verschmelzung der Spezifikation eines anwendungsspezifischem Moduls, der
Steuereinheit einer Presse, mit der Spezifikation eines allgemeinen Moduls für
Fehlerbehandlung.
Die vorliegende Arbeit konzentriert sich auf die theoretische Fundierung und
die technische Umsetzung der Spezifikationsvereinigung als ein Beispiel für komplexe
Modelltransformationen. Besonderes Augenmerk liegt hierbei auf der Korrektheit
der Transformation, sowie einer möglichst hohen Arbeitsersparnis des
Entwicklers durch weitestgehende Automatisierung einzelner Teilschritte. Die
Interaktion mit dem Entwickler wird allerdings zentraler Bestandteil unserer
Betrachtungen sein. Wir haben nicht zum Ziel den Entwickler zu ersetzen, sondern
ihn vielmehr bei zeitintensiven Systementwicklungsschritten optimal zu
unterstützen.
Das weiterführende Ziel des hier technisch untersuchten Vorgehens ist die
Zusammenstellung von Einzeltransformationen zu prozessrelevanten Arbeitsschritten.
Dies ist Inhalt einer weiteren Diplomarbeit ist, die parallel zu der
vorliegenden Arbeit erstellt wurde. Wir geben einen kurzen Ausblick auf deren
Inhalt im letzten Kapitel.
Die Einsetzbarkeit und die betriebswirtschaftlichen Auswirkungen im Softwareentwicklungsprozess
sind hier nicht Teil unserer Betrachtungen. Dazu sind
zunächst entsprechende Fallstudien notwendig, wofür wir mit dieser Arbeit die
technische Basis schaffen wollen.
1.2 Konkrete Aufgabenstellung
Im Rahmen der Diplomarbeit soll das bestehende AQuA-System (AutoFocus/Quest
Framework) 1 eingesetzt werden, um praxisrelevante Analyse- und
Transformationsschritte in einem modellbasierten Entwicklungsprozess zu unterstützen.
Solche Schritte unterstützen den Softwareentwickler, effizient hochwertige
Systeme zu konstruieren. Im Zentrum der DA steht die Unterstützung
von (verhaltens-) bausteinorientierter Entwicklung mittels Spezifikationsmodulen.
Hierbei sollen Standardmodule (z.B. Konfiguration, Fehlerbehandlung, Reinitialisierung)
durch Übernahme der Schnittstellen-, Daten-, und Verhaltensbeschreibung
in spezifische Applikationsmodelle eingebunden werden.
Teilaufgaben sind dabei:
• Analyse der Typenverträglichkeit von Datenbeschreibungen (generelle und
1 Statt des AutoFocus/Quest-Systems wurde nach Ausschreibung der DA dessen Nachfolger,
das AutoFocus 2 System, als Demonstrationsplattform gewählt
4

interaktive Unifizierbarkeit von Datentypen)
• Konstruktion von kombinierten Typen (Unifikation von Datentypen und
interaktive Verschmelzung)
• Schnittstellenunifikation (Kombination von Schnittstellen abhängig von
der Typenverträglichkeit)
• Verhaltenskombination (Einbindung von Verhaltensbeschreibung und Konstruktion
von zugehörigen Transitionen)
• Bausteinorientierte Entwicklung: Modulisolation (Herauslösen von anwendbaren
Verhaltensbausteinen mittels Vervollständigung von Teilmodulen)
Neben der Realisierung der Funktionalität umfasst die Aufgabenstellung die
Ausarbeitung geeigneter Standardmodule zur Demonstration der Tauglichkeit
des Ansatzes.
1.3 Struktur des vorliegenden Dokuments
In Kapitel 2 werden wir die gestellte Aufgabe der Spezifikationsvereinigung einer
genauen Problemanalyse unterziehen. Hier werden wir, neben der Klärungen
des Begriffs Modelltransformation, das Modellierungswerkzeug AutoFOCUS 2
und die zugehörige Transformationssprache ODL erläutern, sowie das Anwendungsbeispiel
genau darstellen.
Als Grundlage für die weiteren Betrachtungen, werden wir in Kapitel 3 das
Thema Unfikation genau untersuchen. Vom Unifikationsverfahren der Prädikatenlogik
werden wir zur Unifikation von Typdefinitionen übergehen. Für die
weiteren Betrachtungen dieser Diplomarbeit ist das Verständnis der Unifikation
von zentraler Bedeutung, da die einzelnen Verfahren sich auf dieses Prinzip
zurückführen lassen.
In Kapitel 4 untersuchen wir das Transformationsproblem aus theoretischer
Sicht und entwickeln einen allgemeinen, formalen Lösungsansatz. Dieser stützt
sich dabei einerseits auf die Unifikation, andererseits auf ein aussagenlogischen
Belegungsproblem. Abschließend unterziehen wir das Berechnungsverfahren der
Lösungen einer Komplexitätsbetrachtung.
Die Spezifikationsvereinigung werden wir in Kapitel 5 mit der theoretischen
Fundierung in ein praktisch anwendbares Transformationsverfahren übertragen.
Wir befassen uns hier mit den Themen verschiedenartiger Benutzerführungen
und der technischen Umsetzung in ODL. Die Interaktion mit dem Nutzer ist in
diesem ein wichtiger Punkt, da sie die Nutzung von Modelltransformationen im
Modellierungsalltag der Softwareentwickler erlaubt.
Den Abschluß dieser Diplomarbeit bildet das Kapitel 6. Wir werden hier
die Ergebnisse zusammenfassen und in einen Ausblick münden lassen, der sowohl
die technische Basis vertiefen und verbreitern, wie auch die praktische
Weiterführung beleuchten wird.
5

Kapitel 2
Modelltransformationen,
Werkzeuge und
Beispielproblem
Dieses Kapitel beschäftigt sich mit den Grundlagen und Werkzeugen der vorliegenden
Diplomarbeit.
Wir werden als erstes den Modelltransformationsbegriff näher beleuchten
und für uns eine Definition dieses Begriffs treffen.
Als nächstes untersuchen wir ausführlich die zum Einsatz kommenden Werkzeuge,
AutoFocus 2 und die darin implementierte Transformationssprache Transformationssprache
ODL (Operation Definition Language, [Sch01]). Wir zeigen
hier auch schon Beispiele für einfache Modelltransformationen.
Die letzten beide Abschnitte dieses Kapitels führen schließlich die Spezifikationsvereinigung
exemplarisch vor und fassen die Einschränkungen des Vereinigungsproblems
im Hinblick auf die AutoFocus 2-Modellierungsfähigkeiten
zusammen.
2.1 Begriffsbestimmung: Modelltransformation
Der Begriff Modelltransformation erfährt seit einiger Zeit gesteigertes Interesse.
Er ist jedoch nicht eindeutig festgelegt und wird in unterschiedlichen Kontexten
verwendet.
Im Zusammenhang mit der Model-Driven-Architecture (MDA) der Object
Management Group (OMG) finden sich Modelltransformationen als Übergang
von plattform-unabhängigen (platform independet model, PIM) zu plattformabhängigen
(platform dependent model, PDM) Modellen, beispielsweise die
Realisierung einer PIM Komponente für Webapplikationen als Enterprise Java
Bean. Ziel ist hier eine Automatisierung, also bspw. Codegenerierung, und die
Flexibilität aus einem PIM die jeweiligen PDMs zu erhalten. Die Modelltransformationen
sind somit Verfeinerungen, die aus einem abstrakten ein konkretes
Modell, oder Abstraktionen, die aus einem konkreten ein abstrakteres Modell,
erzeugen.
Modelltransformationen können aber auch auf einer einzigen Abstraktions-
6

ebene stattfinden, indem beispielsweise ein Modell in eine andere Modellierungssprache
übertragen wird. Die Übertragung von AutoFocus-Modellen in die Modellierungssprache
Promela, zum Zwecke des Model-Checking mit SPIN (vgl.
[Str05]), ist hierfür ein Beispiel.
Auch die Transformationssprache XSLT ([W3C99]) bringt eine Variante für
Modelltransformationen. Sie definiert eine Sprache zur Umsetzung von XML Dokumenten
in anders strukturierte XML Dokumente. In diesem Zusammenhang
kann man auch von einer Transformation in ein anderes Metamodell sprechen.
Metamodelle beschreiben die Struktur von Modellen oder Datenmengen.
Da der Begriff Modelltransformation sehr unterschiedlich interpretiert wird,
wollen wir hier die folgende Festlegung für diese Arbeit treffen. Eine Modelltransformation
ist eine Beschreibung einer modellverändernden Berechnung,
wobei sich diese auf eine Instanz, also ein Modell, für ein festgelegtes Metamodell
bezieht. Sie stellt gewissermaßen eine Relation zwischen Modellen dieses
Metamodells dar. Wir sprechen also weder von der Umsetzung eines Modells
zwischen verschiedenen Abstraktionsebene noch von der Übertragung des Modells
in andere Metamodelle. Somit stellt für uns bereits die Umbenennung eines
Modellelements eine Modelltransformation dar. Allerdings gilt unser Interesse
hier wesentlich komplexeren Transformationen, die sich aus verschiedenen primitiven
Einzelveränderungen des Modells zusammensetzen und eine Vielzahl
von Modellelementen gleichzeitig verändern, sowie neue Elemente erzeugen und
in das Modell einfügen.
2.2 Das Modellierungswerkzeug AutoFocus 2
AutoFocus 2 ist der Prototyp eines Modellierungswerkzeuges zur Entwicklung
und Simulation eingebetteter Systeme, das am Lehrstuhl für Software & Systems
Engineering entwickelt und zu Wissenschaftszwecken eingesetzt wird. Es
stellt eine Weiterentwicklung des AutoFocus-Werkzeugs ([TUM02]) dar. Wie
die meisten modernen CASE-Werkzeuge 1 bietet es zur Modellierung graphische
Editoren und verschiedene Sichten auf das modellierte System an.
Wir werden zunächst einen Blick auf die für das später folgende Beispiel
relevanten Modellierungssichten werfen und im zweiten Schritt das AutoFocus 2
Metamodell (Beschreibung der Struktur von Modellen) beleuchten, da dieses
besondere Bedeutung für die Transformationssprache ODL hat.
2.2.1 Sichten und Editoren
Die Modellierungssichten von AutoFocus 2 sind für die weitere Arbeit wichtig,
da wir unsere Erläuterungen immer wieder an deren Aufteilung orientieren
werden. Die konkreten Editoren und deren Benutzung sind dagegen kaum von
Interesse. Der Leser sei hier auf die Dokumentation von AutoFocus und AutoFocus
2 verwiesen ([TUM02], [TUM05]).
Struktursicht
Die Struktursicht beschreibt den Aufbau von eingebetteten Systemen in AutoFocus
2. Systeme bestehen aus einzelnen Komponenten, die eigenständige
1 CASE: computer-aided software engineering, computer-unterstützte Softwareentwicklung
7

Recheneinheiten bzw. -funktionen darstellen. Sie können über ihre Schnittstelle,
die sogenannten Ports, Nachrichten empfangen und versenden. Mehrere Komponenten
können miteinander über Kanäle verbunden werden und darüber kommunizieren.
So entstehen aus Einzelkomponenten durch Komposition größere
Systemteile und schließlich das Gesamtsystem.
In der vorliegenden Arbeit konzentrieren wir uns allerdings auf einzelne, atomare
Komponenten, d.h. Komponenten, die eine Verhaltensbeschreibung besitzen
und selbst nicht wieder aus Subkomponenten bestehen.
Verhaltenssicht
In AutoFocus 2 wird das Verhalten von atomaren Komponenten durch Zustandsmaschinen
beschrieben. Die Komponente besteht aus einer Menge von
Zuständen und Zustandsübergängen, den Transitionen, zwischen diesen Zuständen.
Transitionen können dabei mit Vorbedingungen und Eingabemuster, sowie
Ausgabemuster und Nachbedingungen (Aktionen) erweitert sein.
Die Erfüllung der Vorbedingung und das Auftreten passender Eingangsnachrichten
an den Eingabeports führt zu einem Zustandsübergang mit der Ausgabe
der festgelegten Nachrichten auf den Ausgabeports und der Ausführung der Aktionen.
Ausgabe nehmen Einfluß auf die Umgebung einer Komponente, wohingegen
Aktionen lokale Variablen und somit den internen Komponentenzustand
verändern. Der Komponentenzustand ist durch den aktuellen Automatenzustand
und die Belegung der lokalen Variablen festgelegt.
Bei Zuständen gibt es, wie bei Komponenten, ebenfalls einen hierarchische
Struktur, d.h. ein Zustand kann wiederum Unterzustände, also einen Teilautomaten,
enthalten. Im Beispiel kapseln wir die Anwendungsfunktionalität des
Pressesteuermoduls in einem eigenen Zustand.
Datensicht
Benutzerdefinierte Datentypen werden über einen einfachen einem Texteditor
ähnlichen Editor festgelegt. Die dazu verwendete Definitionssyntax betrachten
wir in Kapitel 3. Aus der textuellen Repräsentation wird durch einen Parser das
zugehörige Modell der Datendefinitionen erzeugt.
Für unsere Betrachtungen ist die Datensicht zentral, da sie zum einen sehr
komplexe Modellstrukturen aufweist und zum anderen wir hier den Entwickler
möglichst weitgehend unterstützen wollen. In Kapitel 5 werden wir die Spezifikationsunifikation
auf der Datensicht voll automatisieren.
Weitere Sichten
Das AutoFocus 2 Werkzeug besitzt noch eine Reihe weiterer Sichten, die für
unsere Betrachtungen nicht von Bedeutung sind, der Vollständigkeit halber aber
nicht unerwähnt bleiben sollen.
Für die Definition von Beispielabläufen einzelner Komponenten stehen Sequenzdiagramme
(Message Sequence Charts) zur Verfügung. Im AutoMode-
Projekt wurden diese in Verbindung mit den Komponentenmodussicht zur Definition
von datenflussorientiertem Verhalten benutzt (siehe hierzu [TUM04a]).
Im AutoRaid-Projekt wurde AutoFocus 2 mit Modellierungselementen und
entsprechenden Sichten bzw. Editoren für die Anforderungsdefinition ausgestattet
(vgl. hierzu [TUM04b]).
8

2.2.2 Das AutoFocus 2-Metamodell
Gegenüber der ersten Version des AutoFocus-Werkzeugs, das die Datenspeicherung
den Sichten entspreched vornahm, wurde die Architektur von AutoFocus 2
so konstruiert, das sämtliche Modelldaten zusammen abgelegt werden. Zur Zeit
geschieht dies in Form von XML-Dateien, konzeptuell ist die persistente Speicherung
von Modellen aber auch in einer Datenbank möglich. Die Struktur der
Daten, und somit der jeweiligen Speicherungsform, ist im Metamodell festgelegt.
Das Metamodell beschreibt in Form von Klassendiagrammen, welche Modellelemente
es gibt und wie diese miteinander verknüpft sind bzw. sein können. Ein
Metamodellelement beschreibt also eine ganze Klasse von Modellelementen.
In den mit ODL formulierten Transformationen treten die Metamodellelemente
als Bezeichner für Mengen, der jeweils im bearbeiteten Modell vorhandenen
Elemente auf. So repräsentiert Component die Menge aller Komponenten
innerhalb eines AutoFocus 2-Projekts. Zum Verständnis der Modelltransformationen
und -analysen, die wir im Folgenden betrachten werden, ist die Kenntnis
des Metamodells notwendig. Wir haben die relevanten Teile als Klassendiagramme
dargestellt.
Das Metamodell basiert selbst wieder auf einem Meta-Metamodell, was mit
Blick auf die Portierbarkeit der Transformationssprache von Bedeutung ist. Diesen
Aspekt beleuchten wir in Abschnitt 6.3 für die Anbindung von ODL an
UML-Werkzeuge genauer.
Wir wollen nun für die drei für uns relevanten Sichten die jeweiligen Metamodellteile
betrachten. Dabei zeigen wir nur die für die folgenden Ausführungen
relevanten Teile und lassen manche Spezialität, der besseren Verständlichkeit
wegen, weg.
Struktursicht
Die Struktursicht beschreibt den Sytemaufbau und umfasst im Wesentlichen
drei Klassen von Modellelementen. Wie Abbildung 2.1 zeigt sind dies die Metamodellelemente
für Komponenten (Component), Schnittstellen (Port) und Kommunikationskanäle
(Channel).
SubComponents
0..*
Component
Name: String
Port
Ports
0..*
Name: String
DefinedType: MIFType
Direction: Direction
SuperComponent
SourcePort
DestinationPort
OutChannels 0..*
InChannel 0..1
Channel
Name: String
DefinedType: MIFType
Direction
Channels
0..*
IsEntry: boolean
Abbildung 2.1: Metamodell für Komponenten
Die Klasse Direction kapselt die Information, ob ein Port-Element eine Ein-
9

oder Ausgabeschnittstelle der Komponente darstellt. Sie wird ausserdem für
die Richtung von Verbindungspunkten bei den Zuständen der Verhaltenssicht
benötigt.
Verhaltenssicht
Die Zustandsmaschinen zur Verhaltensbeschreibung finden sich im Metamodell
als Automaton-Klasse wieder. Jede Komponente kann anstatt einer Subkomponentenstruktur
mit einem Automaten verknüpft sein, wobei ein Automat als
Verhaltensbeschreibung für mehrere Komponenten dienen kann.
Ein Automat besteht aus einem Zustand, der das eigentliche Verhalten als
Netz von Unterzuständen und Transitionssegmenten zwischen diesen enthält.
Diese Unterzustände können ihrerseits wieder Zustände und Transitionen enthalten.
Abbildung 2.2 zeigt den relevanten Ausschnitt des Metamodells.
Automaton
Name: String
SubStates
0..*
State
Name: String
0..*
InterfacePoint
Name: String
Direction: Direction
SuperState
SourcePoint
DestinationPoint
OutSegments 0..*
InSegments
0..*
0..*
TransitionSegment
Name: String
0..* 0..* 0..*
Condition
Input
Output
Action
Port: MIFPort
Pattern: MIFTerm
Port: MIFPort
Expression: MIFTerm
Abbildung 2.2: Metamodell für Automaten
Die InterfacePoint-Elemente haben im Zusammenhang mit hierarchischen
Zuständen eine weitergehende Bedeutung, weil ein hierarchischer Zustand eine
Aussen- und eine Innenansicht hat. Sie stellen die Verbindungspunkte für Transitionssegmente
dar. Durch diese Elemente ist dabei möglich Transitionen über die
Hierarchieebenen hinweg zu definieren, indem Transitionssegmente über diese
Verbindungsstellen gekoppelt werden. Wir verwenden in unserem Beispiel zwar
einen Unterzustand für die Pressesteuerung, wollen die Verbindungspunkte für
unsere Betrachtungen aber zunächst als einfache Zwischenelementen von Zustand
und Transitionssegment ansehen. Im Programm in Anhang A, in dem wir
10

auch den Unterautomaten kopieren, werden wir sie dann voll berücksichtigen.
Ein Transitionssegment kann eine Vorbedingung (Condition) und mehrere
Aktionen (Action) besitzen, die wir im Beispiel aber nicht weiter betrachten werden,
sondern erst im Anhang A. Für die Spezifikationsvereinigung unterscheiden
sich diese beiden nicht wesentlich von den Ein- und Ausgangsnachrichten (Input
und Output), bringen uns also nichts konzeptuell Neues.
Die Metamodellklassen MIFPort und MIFTerm folgen im nächsten Abschnitt.
Datensicht
Datentypen Mit Datentypen und deren Definition beschäftigen wir uns ausführlich
in Kapitel 3. Wir belassen es hier bei der dem Hinweis, dass die Struktur
und der Aufbau von Typdefinitionen in Abschnitt 3.1 im Zusammenhang mit der
Typunifikation genau erläutert wird und wenden uns hier den mit Datentypen
eng in Verbindung stehenden Termelementen zu.
Terme Für unser Unifikationsvorhaben sind die Terme der Ein- bzw. Ausgabeausdrücke
von Transitionen von besonderem Interesse. In Abschnitt 5.4.5
werden wir mit ihnen eine Strukturunifikation durchführen. Daher wollen wir
uns hier noch den Ausschnitt des Metamodells ansehen. Die Metamodellelemente
Constructor und Selector werden ebenfalls im Kapitel 3 genau eingeführt.
Args 1..*
Term
Appl
Head
Const
Name: String
Constructor
Selector
Abbildung 2.3: Metamodell für Terme
Abbildung 2.3 zeigt, dass ein Term entweder ein Konstruktor oder eine
Funktionsapplikation (Appl) sein kann. Letztere besteht aus einer angewandten
Funktion (Head-Assoziation) und einer geordneten Menge von Parametertermen
(Args-Assoziation). Syntaktisch ist es daher auch möglich, Selektorfunktionen
als angewandte Funktion in Termen zu verwenden. Da dies aber unser Vereinigungsproblem
nur um gleichartige Fälle ausdehnt, werden wir Terme auf die
Anwendung von Konstruktoren beschränken (siehe Abschnitt 2.5).
Die Konstruktion von zulässigen Termen übernimmt in AutoFocus 2 ein
entsprechender Parser. Aus ODL heraus ist ein Zugriff auf diese Funktion allerdings
nicht möglich, weshalb wir selbst die Konstruktion übernehmen müssen.
Wir haben uns dabei aber auf den für Beispiel relevanten Fälle beschränkt und
keine Unifikation für alle in AutoFocus 2 möglichen Terme implementiert.
11

Modellschnittstellen Datentypen, Terme und Ports sind manchmal über eine
weitere Abstraktionsschicht, der Modellschnittstelle (Model InterFace, MIF)
mit den übrigen Modellelementen verknüpft. Abbildung 2.4 zeigt die entsprechenden
Metamodellelemente. Durch diese Abstraktion ist es möglich unvollständige
AutoFocus 2-Modelle zu erstellen, d.h. zum Beispiel Modelle die Ports
enthalten, deren Datentypen noch nicht definiert sind. Für das MIF-Element
wäre in diesem Falle die Model-Assoziation nicht gesetzt, sondern nur das Text-
Attribut belegt.
MIFType
text: String
MIFTerm
text: String
MIFPort
text: String
Model
Model
Model
Type
Term
Port
Abbildung 2.4: Metamodell für Modellschnittstellen
Bei unseren Betrachtungen werden wir diese Möglichkeit nicht weiter beachten.
Wir gehen von vollständigen Modellen aus, d.h. alle MIF-Elemente besitzen
ein entsprechende Model-Repräsentation.
2.3 Die Transformationssprache Operation Definition
Language
Die Transformationssprache Operation Definition Language (ODL) ist in [Sch01]
definiert und durch mehrere Studentenarbeiten in AutoFocus/Quest und AutoFocus
2 implementiert worden. Sie erlaubt ähnlich, wie die Object Constraint
Language (OCL, [OMG03b]), die Definition von Modellnebenbedingungen
(Constraints), aber auch von Modelltransformationen. Besonderheit der ODL ist
dabei die Integration einer Nutzerschnittstelle, sodass Analysen und Transformationen
interaktiv durchgeführt werden können.
2.3.1 Grundlagen
Die Operation Definition Langauge ist ein typbasierter Relationenkalkül mit
den Mengen der Modellelemente eines Metamodells als Typen und den Assoziationen
und Attributen als Relationen. Sie ähnelt, in ihrer Anlehnung an die
Prädikatenlogik erster Stufe, der aus dem Bereich der Datenbanken bekannten
Structured Query Language.
Die Auswertung von ODL Ausdrücken geschieht immer in Verbindung mit einer
Metamodellinstanz, also mit einem konkreten Modell. Die Konzeption stellt
dabei sicher, dass alle Ausdrücke garantiert terminieren. Ein eigenes Typsystem
erlaubt aus den Modellelementmengen komplexere Typen, wie beispielsweise
Produkttypen, aufzubauen. Dieses Typsystem wird in [Höl05] genau erläutert.
12

ODL Ausdrücke stellen, analog zur Prädikatenlogik erster Stufe, Formeln mit
Quantoren dar. Neben den Existenz- und Allquantoren besitzt sie zusätzlichen
einen Interaktionsquantor (context), der die Variablenbindung nicht iterativ
vornimmt, sondern dem Benutzer die iterierte Menge in einem Dialog anzeigt
und eine Auswahl verlangt.
Neben dem Analysieren von Modellen und Überprüfen von Nebenbedingungen
ist eine wichtige Fähigkeit der ODL neue Modellelemente und Verknüpfungen
zwischen Modellelementen schaffen zu können. Wir beschäftigen uns damit
ausführlich im Abschnitt 5.5.
2.3.2 Beispiele
Einige kurze Beispiele sollen hier einen Eindruck der ODL vermitteln.
Überprüfung aller Porttypen auf Definiertheit
Wir wollen Überprüfen, ob für alle Port-Elemente entsprechende Type-Elemente
existieren. Wir betrachten also für jedes Schnittstellenelement, ob das zugehörige
Modellschnittstellenelement (MIFType) mit einem Type-Element verknüpft ist.
forall p:Port . exists t:Type . p.DefinedType.Model = t
Interaktives Umbenennen einer Komponente
Der Nutzer wird um die Eingabe einer Komponente und eines Strings gebeten,
worauf diese Komponente entsprechend umbenannt wird.
context tupel:(comp:Component, name:String) .
result has Name(tupel.comp, tupel.name)
Erzeugen eines neuen Ports
In diesem Beispiel erzeugen wir ein neues Port-Element und fügen es der vom
Benutzer gewählten Komponente hinzu. Wir setzen auch die Richtung des Ports
und seinen Typ, indem wir die entsprechenden Kapselelemente generieren und
mit den Nutzereingaben verknüpfen. Als Porttyp erlauben wir nur Typkonstanten
(TConst).
context data:(c:Component, s:String, dir:Boolean) .
context dtd:DTDModule .
context t:(dtd.TConsts) .
exists np:new Port . (
exists nd:new Direction . (
result has IsEntry(nd, data.dir) and
result has Direction(np, nd)
) and
exists nmt:new MIFType . (
result has DefinedType(np, nmt) and
result has Text(nmt, t.Name) and
result has Model(nmt, t)
) and
13

)
result has Name(np, data.s) and
result has Ports(data.c, np)
2.4 Modelltransformation: AutoFocus 2 Spezifikationsvereinigung
Zum Aufbau größerer Modelle wird meist Komposition eingesetzt, d.h. eine
größere Komponente besteht ihrerseits aus einer Anzahl von miteinander kooperierender
und kommunizierender Subkomponenten. Hin und wieder kann es
aber notwendig sein, eine Komponente als Verschmelzung von zwei oder mehr
bereits spezifizierten Komponenten zu konstruieren. Insbesondere die Kombination
von anwendungsspezifischen Spezifikationen mit generellen, möglicherweise
systemweiten, Spezifikationen ist hier von Interesse. Bisher ist die Durchführung
solcher Verschmelzungen auf Spezifikations- und Modellebene wenig untersucht.
Gängige Praxis ist jedoch die Zusammenführung auf Codeebene durch die Entwickler,
was zeitaufwändig und fehleranfällig ist.
In dieser Arbeit entwickeln wir eine Modelltransformation mit ODL, die für
die Vereinigung von einfachen AutoFocus 2-Komponenten eingesetzt werden
kann. Wir wollen zum Abschluß dieses Kapitels unser Vorhaben anhand eines
konkreten Modells exemplarisch vorführen. Dabei beschreiben wir die Vereinigung
zweier Komponenten aus den drei, hierfür wesentlichen, schon bekannten
AutoFocus 2-Sichten: der Struktursicht, der Verhaltenssicht und der Datensicht.
2.4.1 Struktursicht
Als Beispiel betrachten wir die Komponente Press, die die Funktionalität einer
Presse modelliert. Wir wollen sie mit der Komponente ErrorTreatment, die ein
allgemeines Fehlerverhalten modelliert, verschmelzen. Abbildung 2.5 zeigt aus
Sicht der Systemstruktur diese beiden Komponenten, sowie das Ergebnis der
Vereinigung, die Komponente MergedController.
Cntrl : Control
ErrorTreatment
Sts : Status
Cmd : Command
CntrlCmd : ControlCommand
SnsUp : SensorValue
Press
SnsUp : SensorValue
MergedController
Sts : Status
SnsDn : SensorValue
Act : ActorValue
SnsDn : SensorValue
SnsPc : SensorValue
SnsPc : SensorValue
Act : ActorValue
Abbildung 2.5: Spezifikationsvereinigung der Struktursicht
Die Komponente für das Fehlerverhalten besitzt einen Eingabeport Cntrl
zur Steuerung und einen Ausgabeport Sts für Statusnachrichten.
Die Komponente für die Pressefunktionalität hat neben dem Steuereingang
14

(Cmd), drei Signalleitungen zu Sensoren und eine Signalleitung zu einem Aktuator.
Sie haben die folgenden Bedeutungen:
• SnsUp - Sensorsignal, das anzeigt, dass die Presse gehoben ist.
• SnsDn - Sensorsignal, das anzeigt, dass die Presse gesenkt ist.
• SnsPc - Sensorsignal, das anzeigt, ob sich ein Werkstück in der Presse
befindet.
• Act - Aktuatorsignal, zum Ansteuern des Motors, der die Presse bewegt.
Die vereinigte Komponente MergedController hat ebenfalls die drei Sensorports,
den Status- und den Aktuatorport. Sie wurden als Kopie von den beiden
Quellkomponenten übernommen. Die Besonderheit ist allerdings der neue
Steuerport CntrlCmd, der die Vereinigung der beiden Steuerports Cntrl von
ErrorTreatment und Cmd von Press darstellt. Insbesondere muss für diesen neuen
Port auch der kombinierte Typ ControlCommand generiert werden (siehe unten).
2.4.2 Verhaltenssicht
Die Abbildung 2.6 zeigt die Automaten der beiden Quellkomponenten und der
verschmolzenen Komponente. Das dargestellte Ergebnis ist nur eines von mehreren
syntaktisch korrekten Ergebnissen. Wir haben hier die sinnvolle Variante
gewählt, die möglichst viele Elemente vereinigt.
Es werden die Zustandspaare (Operate, Operate) und (Stop, Off) vereingt.
Die Benennung der neuen Zustände erfolgt durch Konkatenieren der Quellzustandsnamen.
Die Transitionen werden entsprechend dem Verlauf in der Abbildung unifiziert.
Besonders sei angemerkt, dass die Vereinigung der beiden Transitionen
von Stop nach Operate und von Off nach Operate erzwingt, dass das Eingabesignal
für die Transition zwischen Init und Operate ebenfalls angepasst wird.
Siehe hierzu auch die unten gezeigte Vereinigung der Typen.
Die mit (D) gekennzeichneten Zustände zeigen an, dass diese Zustände Unterautomaten
bzw. Unterzustände besitzen. In unserem Beispiel ist die Steuerungslogik
der Presse hier als Unterautomat gekapselt. Abbildung 2.7 zeigt diese
Steuerung.
Nach dem Start wird die Presse zunächst gehoben (Zustand Up). Dies geschieht
für maximal 100 Zeitschritte oder bis der Sensor SnsUp das vollständige
Heben anzeigt. Danach wartet die Presse auf ein Werkstück (Zustand Wait).
Sobald das Vorhandensein eines Werkstücks durch den Sensor SnsPc erkannt
wurde, wird die Presse gesenkt (Zustand Down). Auch dies geschieht wieder
für 100 Zeiteinheiten oder bis die volle Senkung erreicht wurde. Für die Zustandsübergänge,
die die Presse in Bewegung setzen, sind Sensorsignale absolut
notwendig. Wir wollen nicht, dass Zustandsübergänge aufgrund von Zeitbedingungen
geschehen. Sollte nach 100 Zeiteinheiten kein Signal eingetroffen sein, so
bleibt die Steuerung im entsprechenden Zustand und muss abgeschaltet werden.
Man sieht an diesem Fall, das die Vereinigung dieser Steuerungslogik mit der
Fehlerbehandlungslogik praktische Bedeutung hat. Auch wenn die verschmolzene
Anwendungslogik noch unvollständig ist und angepasst werden muss, können
15

ErrorTreatment Verhalten
:Cntrl?Start:
Sts!Started:
Operate
Press Verhalten
Operate
Init
:Cntrl?Stop:
Sts!Stopped:
::Sts!Error:
errCode=1
errCode=0:Cntrl?Start:Sts!Started:
D
:Cmd!Off::
:Cntrl?Reset:
Sts!Initial:
errCode=0
Stop
Off
MergedController Verhalten
:CntrlCmd?StartOn:
Sts!Started:
Operate
Operate
D
Init
:CntrlCmd?StopOff:
Sts!Stopped:
::Sts!Error:
errCode=1
errCode=0:
CntrlCmd!StartOn:
Sts!Started:
:CntrlCmd?Reset:
Sts!Initial:
errCode=0
StopOff
:Cmd!On::
Abbildung 2.6: Spezifikationsvereinigung der Verhaltenssicht
Press.Operate Verhalten
Wait
:SnsPc?Signal:
Act!Lower:
timer = 0
:Cmd!Off::
timer

doch schon viele Anpassungen im Modell konsistent und automatisch durchgeführt
werden. Der Entwickler muss nur noch die Ergebniskomponente vervollständigen.
Für die Vereinigung definieren wir, dass Zustände nur auf der obersten Ebene
eines hierarchischen Automaten unifiziert werden können. Unterautomaten
werden nur einkopiert. Daher darf nur einer der jeweils miteinander unifizierten
Zustände Unterzustände haben, wie das für unser Beispiel der Fall ist. Das Kopieren
werden wir jedoch nur für die erste Unterebene ausprogrammieren, da es
für die vollständige Hierarchie im Wesentlichen dem Kopieren einer Komponentenhierarchie,
wie in [Höl05], entspricht.
Wir können durch zusätzliche vorgeschaltete Transformationen die hierarchische
Struktur eines Automaten verändern, d.h. sozusagen Zustände in einen
hierarchischen Zustand verpacken bzw. sie daraus entpacken. Somit lässt die
Spezifikationsvereinigung leicht auf zusätzliche Anwendungsfälle erweitern, indem
wir diese Verhaltensbeschreibungen auf die hier verlangte Form bringen.
Siehe hierzu auch die Ausführungen über alternative Unifikationsrelationen in
Abschnitt 4.2.
2.4.3 Datensicht
In Kapitel 3 untersuchen die Datentypdefinitionen, insbesondere die Datenmodellierung
nach dem Konstruktor-Selektorprinzip. Hier wollen wir nur die zu
unserem Beispiel gehörenden Datentypen auflisten.
// ErrorTreatment Datentypen //
data Control = Start | Stop | Reset;
data Status = Initial | Started | Stopped | Error;
// Press Datentypen //
data Command = On | Off;
data SensorValue = Signal;
data ActorValue = Raise | Lower;
// MergedController Datentypen //
data ControlCommand = StartOn | StopOff | Reset;
Abbildung 2.8: Spezifikationsvereinigung der Datensicht
Abbildung 2.8 zeigt die Datentypen der beiden Quellkomponenten Error-
Treatment und Press, sowie die neu hinzugekommenen Ergebnisdatentypen nach
der Vereinigung, MergedController. Bei unserem einfachen Beispiel haben wir
auf die Verwendugn von Selektoren verzichtet. Diese werden wir jedoch im Folgenden
sehr wohl berücksichtigen, da sie einige Besonderheiten im Hinblick auf
die Unifikation erfordern.
Die Namen der neuen Datendefinition und der Konstruktoren ergeben sich
wieder durch Konkatenation der Quellelementnamen.
17

2.5 Einschränkungen für die Modellierungselemente
AutoFocus 2 bietet eine breite Palette von Modellierungsmöglichkeiten für komponentenbasierte
Systeme. In dem dargestellten Beispiel haben wir auf einige
dieser Möglichkeiten verzichtet, da diese eine Vielzahl von Sonderfällen erzeugen.
Unser Anspruch ist hier nicht den perfekten Ablauf der Spezifikationsvereinigung
zu präsentieren, sondern das Grundprinzip zu verdeutlichen und
zu zeigen, dass solch komplexe Modelltransformationen durchführbar sind. Eine
einsatzfähige Transformation muss im Kontext eines Entwicklungsprozesses
massgeschneidert werden. Wir legen hier den Fokus auf die theoretische Fundierung
sowie die technische Umsetzung als Konzeptbeweis.
Im Einzelnen haben wir folgende Einschränkungen benutzt:
• Die zu vereinigenden Komponenten besitzen keine hierarchische Struktur.
Wir verwenden nur Einzelkomponenten zur Vereinigung, deren Verhalten
durch einen Automaten beschrieben ist.
• Die Unifikation von lokalen Variablen führen nur im Programmlisting in
Anhang A durch.
• Die Vereingung der Automaten ist flach, d.h. wir gehen davon aus, dass die
Automaten keine hierarchischen Zustände besitzen. Für solche Zustände
müsste zusätzlicher Aufwand betrieben werden, um die Struktur rekursiv
abzuarbeiten. Unterautomaten werden erst im Programm miteinbezogen,
dort jedoch auch nur kopiert, nicht unifiziert.
• Automaten haben keine ausgezeichneten Zustände, wie Start- und Endzustände.
• Die Zustandsübergänge besitzen keine Vorbedingungen und keine Aktionen,
da hierzu zunächst die Definition entsprechender Terminterpretationen
notwendig ist, um über die Vereinigung von Vorbedingungen zu sprechen.
• Zahlreiche Modellattribute wurden der Übersichtlichkeit wegen weggelassen,
insbesondere Comment und Ähnliches.
• Ausschließliche Verwendung von nutzerdefinierten Datentypen; alle Werte
sind als Konstruktoren vorhanden. Wir verzichten auch auf den Einsatz
primitiver Datentypen, da sie nur zusätzliche zu berücksichtigende
Fälle erzeugen, die keine neuen Konzepte mit sich bringen und somit dem
Verständnis nur abträglich sind.
• Funktionsapplikationen in Termen müssen als Funktion einen Konstruktor
haben. Selektoren sind nicht zugelassen. Die Begründung ist die selbe wie
eben.
• Polymorphe Datentypen sind nicht Teil unserer Betrachtungen, da sie eine
zusätzliche Abstraktionsebene einführen, die eigene Vereinigungsverfahren
erfordert.
18

• Viele Modellelemente müssen bezüglich eines Attributs (meist Name) im
gesamten Modell eindeutig sein. Diese Auflage überprüfen wir bei der
Konstruktion nicht, da sie jeweils sehr leicht durch Iteration über alle
vorhanden Elemente und bei Namensgleichheit durch Nutzerinteraktion
behoben werden kann. Wir verwenden der Einfachheit halber mittels der
ODL-Funktion concat zusammengesetzte Namen.
2.6 Zusammenfassung
In diesem Kapitel haben wir uns dem Thema Modelltransformation gewidmet.
Nach der Begriffsklärung haben wir die Grundlagen des Modellierungswerkzeuges
AutoFocus 2 dargestellt. Anhand der Modellierungssichten haben wir
die Datenarchitektur von AutoFocus 2-Modellen, das Metamodell, betrachtet.
Dieses Wissen ist die notwendige Grundlage für das Verständnis der Transformationssprache
ODL, welche wir anhand einfacher Beispiele eingeführt haben.
Nachdem wir nun sowohl das Modellierungswerkzeug als auch die Implementierungssprache
für die Modelltransformationen betrachtet haben, gingen wir
zur exemplarischen Erläuterung der Modelltransformation Spezifikationsunifikation
über. Für die weiteren Ausführungen dieser Arbeit haben wir abschließend
die Beschränkungen für Modelle zur Nutzung unserer Transformation erklärt.
Das Programmlisting im Anhang A wird einige dieser Beschränkungen wieder
aufheben. Zur Erläuterung des Konzeptes ist diese Aufhebung jedoch nicht notwendig,
da keine wesentlichen neuen Aspekte auftreten. Das Grundprinzip der
Unifikation ist entscheidend, nicht wie viele Metamodellelemente in sie miteinbezogen
werden. Deshalb werden wir im nächsten Kapitel die Unifikation genau
erläutern.
19

Kapitel 3
Einführungsbeispiel:
Typunifikation
Bevor wir uns der Lösung des Spezifikationsvereinigung zuwenden werden, wollen
wir an einem Teilbeispiel, der Typdefinitionsvereinigung, das Grundprinzip
aufzeigen. Wir werfen zunächst einen genaueren Blick auf die Modellierungsmöglichkeiten
von AutoFocus 2 im Bereich Datentypen. Insbesondere werden
wir den Zusammenhang zwischen modellierten Datentypen und dem Metamodell
beleuchten. Im folgenden Teil werden wir das aus der Prädikatenlogik bekannte
Verfahren der Unifikation auf die Typvereinigung übertragen. Die beiden
letzten Abschnitte dieses Kapitels beschäftigen sich mit der Umsetzung in ODL.
Zunächst beschränken wir uns auf die prädikative Form, d.h. wir überprüfen zwei
Datentypdefinitionen auf Vereinbarkeit. Danach gehen wir über zu einer interaktiven
ODL-Abfrage, die es dem Nutzer erlaubt seine Vereinigungswünsche
direkt anzugeben.
3.1 AutoFocus 2 Datentypen und Metamodell
3.1.1 Benutzerdefinierte Datentypen
In AutoFocus 2 werden benutzerdefinierte Typen nach einem einfachen Konstruktor-Selektor-Prinzip
festgelegt. Ein Datentyp besteht aus einer Liste von
Konstruktorfunktionen. Diese besitzen beliebig viele Parameter, die Selektoren.
Ein einfacher Datentyp MySignal, der ein Signal modelliert, dass entweder
abwesend (Absent) ist oder bei Vorhandensein (Present) einen Ganzzahlwert
überträgt, wird folgendermaßen definiert:
data MySignal = Absent | Present( value:Int );
Der im Beispiel verwendete Typ Int gehört zu einer Reihe von Grundtypen,
die AutoFocus 2 vorgibt, und die keine Datendefinition besitzen. Diese
Grundtypen sind jedoch von besonderer Bedeutung, da sie die Fundierung des
rekursiven Verfahrens, wie unten beschrieben, bilden. Abbildung 3.1 zeigt das
zugehörige Objektdiagramm, das für AutoFocus 2 aus obiger Festlegung entsteht.
Links finden sich die Definitionsobjekte für die Typdefinition (DataDef),
20

die Konstruktoren (Constructor) und den Selektor (Selector). Die Objekte in
der rechten Hälfte bilden die interne Typstruktur des Selektors.
:DataDef
:AbstractType
:AbstractType
Name = "MySignal"
TConst
Name = "MySignal"
Name = "Int"
TArgs [0]
TArgs [1]
Constructors [0] Constructors [1]
:Constructor
Name = "Absent"
:Constructor
Name = "Present"
Selectors [0]
:Selector
Type
:TAppl
THead
:AbstractType
Name = "value"
Name = "->"
Abbildung 3.1: Objektdiagramm einer einfachen Typdefinition
Dieser Typstruktur von Selektoren müssen wir besondere Aufmerksamkeit
widmen. Selektoren stellen im eigentlichen Sinne Funktionen dar, die aus einer
Instanz des Datentyps die entsprechende Teilinformation extrahiert. Der im Beispiel
verwendet Selektor value hat demzufolge nicht den Typ Int, wie Definitionssyntax
nahelegt, sondern den Funktionsapplikationstyp MySignal -> Int. Im
Objektdiagramm findet sich dieser Typ als TAppl-Objekt mit der ->-Funktion als
angewandte Funktion (THead) und den entsprechenden AbstractType-Objekten
als Parameter (TArgs) wieder.
Abbildung 3.2 zeigt den hier wesentlichen Ausschnitt aus dem AutoFocus 2-
Metamodell. Neben den organisatorischen Klassen, DTD und DTDModule, finden
sich sämtliche im Objektdiagramm der Datentypdefinition vorkommenden Klassen.
Die Oberklassen sind nur der Vollständigkeit halber angegeben. ODL musste
im Verlauf dieser Diplomarbeit erweitert werden, um mit Vererbungsbeziehungen
im Metamodell korrekt umgehen zu können.
3.1.2 Sonderbehandlung von Selektortypen
ODL ist bisher nur auf ungeordneten Mengen definiert und kann daher im Prinzip
mit Assoziationen, die im Metamodell den Stereotyp haben,
nicht mehr anfangen als mit herkömmlichen Assoziationen. Allerdings muss bei
den Typen der Selektoren die Argumentliste korrekt interpretiert werden. Für
einen Typvergleich müssen wir aus der Argumentliste der Funktionsapplikation
den Ergebnistyp, also das zweite Argument der geordneten Relation, extrahieren.
Hierfür wurde ODL um die Funktion indexOf(listElem, baseElem,
relName) erweitert. listElem ist das assoziierte Element, dessen Index wir bestimmen
wollen, baseElem das Ausgangselement und relName der Name der zu
durchsuchenden Relation. Diese Erweiterung, die sich auf das in [Höl05] eingeführte
Funktionsframework stützt, war die einfachste Alternative den Spezialfall
geordneter Assoziationen zu handhaben.
Um die Überprüfung eines Selectors auf einen bestimmten Ergebnistyp zu
erleichtern, verwenden wir das folgende benamte Prädikat. Es nimmt mit Hilfe
21

DTD
0..*
DTDModule
0..*
TypeDef
0..*
Type
Type
Term
Name: String
TArgs 1..*
0..*
TConst
TConst
Name: String
THead
TAppl
Const
Name: String
AbstractType
Constructors
Selectors
DataDef Constructor Selector
1..*
0..*
Abbildung 3.2: AutoFocus 2 Metamodell: Datentypdefinitionen
der ODL-Funktion indexOf die Extraktion des Ergebnistyps, also des zweiten
TArgs-Parameter mit Index 1, der Funktionsapplikation vor und vergleicht dann
diesen mit dem Parameter t des Prädikats.
define testSelectorType (
sel:Selector,
t:Type
) := (
/* find the functionapplication */
exists ta:TAppl . (
sel.Type = ta and
exists ta_arg:(ta.TArgs) . (
/* find the second argument (its index is 1) */
indexOf(ta_arg, ta, "TArgs") = 1 and
ta_arg = t
))) .
Die Verwendung des benamten Prädikats ist sinnvoll, da zum einen die ODL-
Ausdrücke im folgenden besser lesbar und strukturiert sind; zum anderen benötigen
wir die Überprüfung des Selektortyps an mehreren Stellen innerhalb eines
Ausdrucks, wodurch sich eine kompaktere Form ergibt. Sei s eine ODL-Variable
vom Typ Selector und t eine Variable vom Typ Type, können wir nun obiges
Prädikat mit
call testSelectorType(s, t)
22

aufrufen und müssen nicht jeweils den kompletten Prädikatsausdruck an den
entsprechenden Stellen einfügen.
3.1.3 Rekursive und polymorphe Typen
AutoFocus 2 erlaubt es auch rekursive Typen, wie Listen, zu definieren. Ein
Anwendungsbeispiel hierfür sind die folgenden beiden Listen:
IntList = Empty | Append(i:Int, rest:IntList)
AnotherList = Empty | Append(i:Int, rest:AnotherList);
Rekursive Typen unterscheiden sich nur geringfügig bei der Konstruktion der
Fixpunktmenge. In Abschnitt 3.3, wenn wir das Vereinbarkeitsprädikat definieren,
weisen wir an entsprechender Stelle darauf hin.
Das Metamodell lässt bei Typfestlegungen ebenfalls polymorphe Typen zu.
Ein Beispiel hierfür ist der Typ des polymorphen Baumes:
T ree α = EmptyT ree | Grow(left : T ree α, value : α, right : T ree α);
Diese AutoFocus 2-Spezifikationsmöglichkeit verfolgen wir an dieser Stelle nicht
weiter, da hierzu kompliziertere Mechanismen festgelegt werden müssen, wie
die Instanziierung polymorpher Typen und die Unifikation bei Typen höherer
Ordnung.
3.2 Unifikation und Typvereinbarkeit
Die Unifikation sollte dem Leser beispielsweise aus [Sch00] oder anderen Quellen
über Lösungsverfahren der Prädikatenlogik bekannt sein. Hier soll nur das
Grundprinzip aufgezeigt werden, um dann den Zusammenhang der Typvereinbarkeit
mit der Unifikation verdeutlichen zu können.
3.2.1 Unifikation in der Prädikatenlogik
Zwei prädikatenlogische Formeln F 1 und F 2 zu unifizieren bedeutet, sie durch eine
geeignete Ersetzung (Substitution) σ der freien Bezeichner auf eine identische
Form zu bringen.
Sei P ein Prädikat, f eine Funktion, x, y Variablenbezeichner, a, b Konstanten
so können
mittels einer der Substitutionen
F 1 = P (f(x))
F 2 = P (y)
σ 1 = [f(x)/y]
σ 2 = [f(a)/y, a/x]
unifiziert werden. Hierbei ist σ 1 der allgemeinste Unifikator.
Der zugehörige Unifikationsalgorithmus untersucht die beiden Formeln Zeichen
für Zeichen bis er auf unterschiedliche trifft. Es kann dann ein Teil des
allgemeinsten Unifikators ermittelt werden, vorausgesetzt dass folgende beiden
Bedingungen erfüllt sind:
23

1. eines der beiden Zeichen ist ein Variablenbezeichner
2. sei x dieser Bezeichner und t der Term in der zweiten Formel, so kommt
x nicht in t vor.
Daher ist weder P (a) mit P (b) noch P (x) und P (f(x)) miteinander unifizierbar.
Wir werden gleich sehen, dass sich ähnliche Fälle auch bei der Typvereinbarkeit
ergeben.
3.2.2 Typunifikation in AutoFocus 2
Wir definieren nun die Typvereinbarkeit über dem AutoFocus 2-Metamodell,
wie es eben vorgestellt wurde.
Zwei Typen T 1 und T 2 sind vereinbar, wenn
1. T 1 = T 2 , oder
2. für alle namensgleichen Konstruktoren und darin enthaltenen namensgleichen
Selektoren gilt, dass die Selektortypen vereinbar sind.
Zwei Typen sind also vereinbar, wenn sie identisch sind oder keine bezüglich
des Selektortyps widersprüchliche, namensgleiche Konstruktor-/Selektor-Paare
enthalten. Hier sehen wir die Ähnlichkeit zur Unifikation. Statt einer zeichenweisen
Überprüfung beruht die Typvereinbarkeit auf der Überprüfung der Konstruktor-Selektor-Struktur.
Die in AutoFocus 2 vordefinierten Grundtypen (Boolean, Int, etc.) sind nur
mit sich selbst vereinbar, da sie gar keine Konstruktor-Selektor-Struktur besitzen.
Sie stellen jedoch die Fundierung für die rekursive Definition des Typvereinbarkeitprädikats
dar.
Erweitern wir die anfangs dargestellte Typdefinition um einen zusätzlichen
Datentyp für Systemzustände,
data MySignal = Absent | Present( value:Int );
data AnotherSignal = Present( value:Int ) | Error;
so erhalten wir durch die Unifikation mit Namensgleichheit den folgenden Ergebnistyp:
data MySignal_AnotherSignal =
Absent | Present( value:Int ) | Error;
3.3 Typvereinbarkeitsprädikat in ODL
Nachdem wir nun das Metamodell untersucht und die Typvereinbarkeitsprüfung
theoretisch erläutert haben, können wir nun zur Praxis wechseln und das ODL-
Prädikat programmieren.
Da ODL für rekursive Berechnungen bisher nur die Konstruktion von Fixpunktmengen
zulässt, beschränken wir uns hier auf den analytischen Fall, d.h.
wir wollen die Frage beantworten können, ob zwei gegebene Typdefinitionen
miteinander vereinbar sind. Der konstruktive Fall wäre dann die Berechnung
und Erzeugung des Vereinigungstyps. Diese Berechnung beinhaltet das ermitteln
eines Unifikators, der angibt welche Konstruktoren und Selektoren jeweils
24

unifziert werden. Der Unifikator kann dann benutzt werden um die unifzierte
Typdefinition automatisch zu erzeugen. In Abschnitt 3.4 führen wie die Definition
eines solchen Unifikators interaktiv durch, d.h. der Nutzer wird festgelegen,
welche Konstruktoren und Selektoren unifziert werden sollen, wobei die
Namensgleichheit nicht mehr erforderlich ist.
Um die Frage der Vereinbarkeit zweier Typdefinitionen zu beantworten, konstruieren
wir mit Hilfe eines Fixpunktes die Menge aller vereinbarbaren Typtupel
über zwei Typmodulen (DTDModule im Metamodell). Durch Prüfen, ob ein
gegebenes Paar von Typen in dieser Menge enthalten ist, kann die Frage der
Vereinbarkeit dieser beiden entschieden werden.
In diesem Beispiel lassen wir zu Demonstrationszwecken den Benutzer bestimmen,
von welchen beiden DTD-Modulen (den Sammelbehältern für Datentypdefinitionen)
eine Vereinbarkeitsmenge berechnet werden soll und zeigen ihm
diese am Ende an.
Wir beginnen also mit der Auswahl der beiden DTDModule-Instanzen.
context module1:DTDModule . context module2:DTDModule .
Wir nutzen nun den Fixpunktoperator für die rekursive Mengenkonstruktion.
Die Elemente der Menge sind dabei Tupel aus zwei TConst-Instanzen, je eine
aus einem der beiden DTD-Module. TConst ist die MM-Superklasse, die atomare
Typdefinitionen zusammenfasst (vgl. hierzu Abbildung 3.2).
exists eqTypeSet: lfp fp1 set
fp1_it:(mod1Type:(module1.TConsts), mod2Type:(module2.TConsts))
with (
In die Fixpunktmenge nehmen wir als erstes die identischen Tupel auf.
Dies sind hier nur die AutoFocus 2-Grundtypen (also (Int, Int) und (Boolean,
Boolean), usw.). Die Grundtypen sind in jedem DTD-Modul automatisch eingefügt.
fp1_it.mod1Type = fp1_it.mod2Type or (
Der zweite Teil der Konstruktionsvorschrift für den Fixpunkt übernimmt
nun die Überprüfung, ob zwei nutzerdefinierte Datentypen vereinbar sind. Hierzu
suchen wir die zu dem betrachteten Tupel gehörenden Datendefinitionen
(DataDef-Instanzen). Für Grundtypen existieren, wie bereits gesagt keine Datentypdefinitionen,
weshalb sie auch nur mit sich selbst vereinbar sind.
exists mod1dd:DataDef . (
mod1dd = fp1_it.mod1Type.TypeDef and
exists mod2dd:DataDef . (
mod2dd = fp1_it.mod2Type.TypeDef and
Konnten wir entsprechende DataDef-Instanzen für beide Tupelteile finden,
überprüfen wir nun sämtliche Konstruktorkombinationen, ob es namensgleiche
Konstruktoren gibt.
forall con1:(mod1dd.Constructors) .
forall con2:(mod2dd.Constructors) . (
(con1.Name = con2.Name) implies (
25

Haben wir namensgleiche Konstruktoren gefunden, müssen wir überprüfen,
ob diese namensgleiche Selektoren besitzen.
forall sel1:(con1.Selectors) .
forall sel2:(con2.Selectors) . (
(sel1.Name = sel2.Name) implies (
Sollten auch namensgleiche Selektoren existieren, ist für diese nun zu prüfen,
ob deren Typen vereinbar sind, d.h. wir müssen nachsehen, ob unsere Fixpunktmenge
ein entsprechendes Tupel enthält.
exists fp1_elem:fp1 . (
call testSelectorType(sel1, fp1_elem.mod1Type) and
call testSelectorType(sel2, fp1_elem.mod2Type)
)
or (
call testSelectorType(sel1, fp1_it.mod1Type) and
call testSelectorType(sel2, fp2_it.mod2Type)
)
... /* lots of ) */
) .
Das Disjunktionsglied benötigen wir für den Fall, der sich ergibt, wenn wir
rekursive Datentypen untersuchen, wenn also die Selektoren den in der Fixpunktiteration
gerade betrachteten Typ besitzen. In diesem Fall muss die Überprüfung
der Vereinbarkeit der Selektortypen dahingehend erweitert werden, dass
auch das aktuell betrachtete Typtupel überprüft wird.
Nachdem nun die Fixpunktmenge der vereinbaren Typen konstruiert ist (Variable
eqTypeSet), lassen wir an dieser Stelle den Benutzer ein Element der Menge
auswählen, um das Ergebnis in einem entsprechenden Dialog darzustellen.
context elem:eqTypeSet . true
3.4 Interaktive Typvereinigung
Bisher haben wir die Unifikation von Typdefinitionen auf die Namensgleichheit
bei Konstruktoren und Selektoren gestützt. Für die Praxis ist dieses Vorgehen
meist unzureichend, da wir mehr an der Struktur, die durch die Typdefinition
festgelegt wird, interessiert sind als an den Bezeichnern in der Definition. Oft
kommt es sogar vor, dass Typdefinitionen strukturell identisch sind, während
der Entwicklungsarbeit allerdings mit unterschiedlichen Bezeichnern versehen
wurden.
Beispielsweise kann man
data Command = Start | Stop | Reset;
und
data State = On | Off | Init;
26

als unterschiedlich bezeichnete Sichten auf den strukturell gleichen Datentyp ansehen.
Der Fokus liegt im ersten Fall auf den Bezeichnungen der Kommandos,
im zweiten Fall auf den Systemzuständen. Treten beide Typen in einer Spezifikation
auf, so könnte sich der Entwickler entscheiden diese zu vereinheitlichen
und durch eine entsprechende Modelltransformation die gesamte Spezifikation
auf den kombinierten Typ
data CommandState = StartOn | StopOff | ResetInit;
umzustellen.
Um den Entwickler somit bereits auf Spezifiationsebene optimal zu unterstützen,
wollen wir in diesem Abschnitt die Typvereinigung interaktiv durchführen
und wie gerade gesehen insbesondere die Einschränkung der Namensgleichheit
aufheben. Für den eben dargestellten Spezialfall (ohne Selektoren)
kann eine einfache ODL-Transformation verwendet werden.
Zunächst wählt der Entwickler aus, welche Datentypdefinitionen vereinigt
werden sollen. Danach gibt er an, wie die Konstruktoren zu kombinieren sind.
/* select datadefs */
context datadefMap:(one:DataDef, two:DataDef) .
/* define unique constructor unification set */
context constructorMap:{testConMap: set (
one:(datadefMap.one.Constructors),
two:(datadefMap.two.Constructors)) |
forall c1:testConMap . forall c2:testConMap . (
c1.one = c2.one equiv c1.two = c2.two
)
} .
Mit diesen Informationen kann nun eine neue Datendefinition erzeugt werden.
Dies geschieht mit dem folgenden ODL-Ausdruck, wobei wir nur die Assoziationen
wie in Abbildung 3.2 erstellen. Wir erzeugen zuerst eine neues DataDef-
Objekt, benennen und verknüpfen es. Danach kreieren wir das zugehörige AbstractType-Objekt,
welches ebenfalls benannt und entsprechend verknüpft wird.
Wir verzichten an dieser Stelle darauf das Ersetzen der ursprünglichen Objekte
in der gesamten Spezifikation durch das neue Objekt darzustellen.
/* create new datadefinition */
exists nd:new DataDef . (
result has DTDModule(nd, datadefMap.one.DTDModule) and
result has Name(nd,
concat(datadefMap.one.Name, datadefMap.two.Name)) and
/* create new abstract type */
exists nat:new AbstractType . (
result has Name(nat,
concat(datadefMap.one.Name, datadefMap.two.Name)) and
result has TConst(nd, nat) and
result has TConsts(datadefMap.one.DTDModule, nat) and
/* replace old abstract types with the unified one*/
...
) and
27

Abschließend erzeugen wir die Konstruktoren, wobei wir hier darauf verzichten
die nicht-unifizierten Konstruktoren in den neuen Datentyp zu kopieren und
die Änderungen im Modell vorzunehmen.
)
exists newConMap: map orig:constructorMap
to copy:new Constructor . (
forall ncm1:newConMap . forall ncm2:newConMap . (
ncm1.orig = ncm2.orig equiv ncm1.copy = ncm2.copy
) and
forall nc:newConMap . (
/* create new constructors */
result has Name(nc.copy,
concat(nc.orig.one.Name, nc.orig.two.Name)) and
result has DataDef(nc.copy, nd) and
/* replace old constructors with the unified ones */
...
)
) and
/* copy constructors not unified and replace old references */
...
Im Folgenden wollen wir nun noch die Selektoren mitberücksichtigen. In
diesem Fall muss es möglich sein mehrere Datendefinitionen gleichzeitig zu unifizieren,
da Selektoren nur unifziert werden können, wenn sie den selben Ergebnistyp
haben oder die Ergebnistypen ebenfalls vereinigt werden. Letzteres
bedeutet, dass die entsprechenden Datendefinitionen vereinigt werden müssen.
context datadefTupel:{
tupel:(datadefMap : set (one:DataDef, two:DataDef),
constructorMap : set (one:Constructor, two:Constructor),
selectorMap : set (one:Selector, two:Selector)
) |
forall sme:(tupel.selectorMap) . (
/* constructor dependency */
exists sme_con:(tupel.constructorMap) . (
sme.one.Constructor = sme_con.one and
sme.two.Constructor = sme_con.two
) and (
/* selector types are equal */
call selectorTypeEqual(sme.one, sme.two) or
/* their datadefs are unified */
exists sme_dd:(tupel.datadefMap) . (
call testSelectorType(sme.one, sme_dd.one.TConst) and
call testSelectorType(sme.two, sme_dd.two.TConst)
)
)
) and
forall cme:(tupel.constructorMap) . (
/* datadef dependency */
exists cme_dd:(tupel.datadefMap) . (
28

cme.one.DataDef = cme_dd.one and
cme.two.DataDef = cme_dd.two
)
)
} . true
Diese interaktive Typunifikation über sämtliche Typdefinitionen eines Modells
wird, wie in Abbildung 3.4, bereits bei einer Handvoll Datendefinitionen
praktisch nicht mehr nutzbar. Die ausgewählten zu unifizierenden Typdefinitionen
zeigen die rekursive Abhängigkeit zwischen Datendefinitionen, Konstruktoren
und Selektoren. Sie basieren auf folgenden Typdefinitionen:
data Type1 = NoArg1 | Arg1( a1:Int );
data Type2 = NoArg2 | Arg2( a2:Int );
data RecursiveTestType1 = MyTest1( mt1:Type1 );
data RecursiveTestType2 = MyTest2( mt2:Type2 );
Nur der Vollständigkeit wegen, geben wir hier noch das benamte Prädikat
selectorTypeEqual an. Es überprüft zwei Selektoren, ob deren Ergebnistyp gleich
ist. Die verwendeten ODL Mechanismen sind aus Abschnitt 3.1.2 bekannt.
define selectorTypeEqual (
sel1:Selector,
sel2:Selector
) := (
sel1 = sel2 or
/* search function applications */
exists ta:{ta_test:(one:TAppl, two:TAppl) |
ta_test.one = sel1.Type and
ta_test.two = sel2.Type
} .
exists ta_arg1:(ta.one.TArgs) . (
indexOf(ta_arg1, ta.one, "TArgs") = 1 and
exists ta_arg2:(ta.two.TArgs) . (
indexOf(ta_arg2, ta.two, "TArgs") = 1 and
/* compare result types */
ta_arg1 = ta_arg2
)
)
).
3.5 Zusammenfassung
In diesem Kapitel haben wir uns intensiv mit Datentypdefinitionen in AutoFocus
2 und der Typvereinbarkeit bzw. -vereinigung befasst. Wir haben gesehen,
wie Datentypen spezifiziert werden und wie sie gemäß dem AutoFocus 2-
Metamodell in Objektstrukturen umgesetzt werden. Nachdem wir die Unifikation
der Prädikatenlogik auf Datentypen übertragen haben, begannen wir erste
komplexere ODL-Ausdrücke zu formulieren. Wir haben gesehen, wie mit ODL
29

30
Abbildung 3.3: Eingabedialog zur Typunifikation

zwei Datentypen auf Vereinbarkeit geprüft werden. Anhand eines einfachen Beispiels
haben wir die interaktive Typvereinigung auch konstruktiv durchgeführt
und schließlich noch die allgemeine Version der interaktiven Vereinigung von
Datentypen, Konstruktoren und Selektoren programmiert. Dieses Wissen wird
uns im Weiteren helfen ein Lösungskonzept für die gestellte Gesamtaufgabe aus
theoretischer Sicht zu entwickeln. Bei der konkreten Umsetzung eines auf diesem
Konzept beruhenden interaktiven Ablaufs werden wir Teile der hier definierten
ODL-Ausdrücke wiederverwenden.
31

Kapitel 4
Spezifikationsvereinigung
aus theoretischer Sicht
Nachdem wir in Kapitel 3 einen ersten Eindruck gewonnen haben, wie mit ODL
das Teilproblem der Typunifikation gelöst wird, wenden wir uns nun wieder
dem Gesamtproblem der Spezifikationsvereinigung zu. In diesem Kapitel werden
wir hierfür ein Lösungskonzept entwickeln und formal fundieren. Wir erläutern
zunächst geeignete Lösungsstrukturen. Über diesen werden wir, ausgehend vom
AutoFocus 2-Metamodellstruktur, Prädikate definieren, welche uns die Lösung
des Vereinigungsproblems als Variablenbelegungsproblem ermöglichen. Eine Betrachtung
des notwendigen Berechnungsaufwandes des beschriebenen Verfahrens
schließt dieses Kapitel ab.
Die hier gezeigte theoretische Fundierung ist für das Anwendungsbeispiel aus
Kapitel 2 um viele Modellelemente vereinfacht worden. In Anhang A finden sich
die für das Anwendungsbeispiel relevanten, zusätzlichen Theorieüberlegungen,
die aber im Wesentlichen den hier beschriebenen entsprechen.
4.1 Definition des Lösungsraumes
Im Einführungsbeispiel (siehe Kapitel 3) zu ODL haben wir gesehen, wie die Typunifikation
realisiert wurde. Das Problem der Spezifikationsvereinigung werden
wir ebenfalls mit Hilfe eines der Unifikation ähnlichen Ablaufs lösen.
In Abschnitt 3.4 haben wir gesehen, wie die Typvereinigung mit ODL interaktiv
durchgeführt wird. Die Eingabe des Benutzers waren dabei Mengen
von 2-Tupeln über den Modellelementmengen der Datendefinitionen DataDef,
Konstruktoren Constructor und Selektoren Selector. Verallgemeinern wir diese
Strukturen, so kommen wir zu Relationen von zu unifizierenden Modellelementen,
die wir im folgenden als Unifikationsrelationen bezeichnen.
Wir erhalten jeweils eine Unifikationsrelation für jedes Metamodellelement,
also für jede Klasse von Modellelementen. Für unser Beispiel sind dies die folgenden
Relationen:
componentMap ∈ P( Component × Component )
portMap ∈ P( P ort × P ort )
32

stateMap ∈ P( State × State )
transitionMap ∈ P( T ransitionSegment × T ransitionSegment )
inputMap ∈ P( Input × Input )
outputMap ∈ P( Output × Output )
datadefMap ∈ P( DataDef × DataDef )
constructorMap ∈ P( Constructor × Constructor )
selectorMap ∈ P( Selector × Selector )
Wählen wir für jede Unifikationsrelation eine konkrete Instanz, so bildet
das Tupel dieser Instanzen einen Unifikator, wenn es die in Abschnitt 4.3 beschriebenen
Abhängigkeiten erfüllt. Der Unifikator bildet die Grundlage für den
zweiten Schritt der Spezifikationsvereinigung, die Konstruktion, die wir in Kapitel
5 weiter ausführen. Die Relationen geben dabei an, aus welchen bestehenden
Modellelementen die neu erzeugten Modellelemente entstehen.
Ein einfacher Unifikator ist das Tupel der Identitätsrelationen. Jedes Modellelement
würde hierbei mit sich selbst vereinigt, was bei der konstrutiven
Durchführung eine Kopie des Produktmodells erzeugt. Wählten wir für jede Unifikationsrelation
hingegen jeweils die leere Relation, so würde das AutoFocus 2-
Produktmodell überhaupt nicht verändert. In beiden Fällen handelt es sich also
um in der Theorie korrekte Lösungen bzw. Unifikatoren, welche mit ODL auch
technisch umsetzbar sind, aber keine praktische Relevanz haben.
4.2 Unifikationsrelationen
Die im letzten Abschnitt eingeführten Unifikationsrelationen können im Hinblick
auf die Konstruktion einer Vereinigungsspezifikation unterschiedlich interpretiert
werden. Im Einzelfall bieten sich alternative Definitionen für die Unifikation
der betrachteten Modellelemente an. Wir werden beides hier anhand
von Beispielen sehen und am Ende dieses Abschnitts eine Festlegung für die
konstruktive Durchführung der Spezifikationsvereinigung in Kapitel 5 treffen.
4.2.1 Alternative Relationsdefinition
Am Beispiel der Automatenbeschreibungen wollen wir aufzeigen, dass es auch
möglich ist andere Definitionen für die Unifikationsrelationen zu verwenden.
Abbildung 4.1 zeigt eine andere Vereinigung der Spezifikationen des Verhaltens
unserer Beispielkomponenten. Wir vereinigen jetzt zwei Zustände der Komponente
ErrorTreatment mit einem Zustand der Komponente Press, nämlich
Init und Stop mit Off.
Hierfür definieren wir die Unifikationsrelation, wie folgt, über den Potenzmengen
der Modellelementmengen:
stateMap ∈ P ( P(State) × P(State) )
Die dem Beispiel entsprechende konkrete Unifikationsrelation hat dann folgende
Form:
{ ({Initial, ) }
stateMap = Stop}, {Off}
33

ErrorTreatment Verhalten
:Cntrl?Start:
Sts!Started:
Operate
Press Verhalten
Operate
Init
:Cntrl?Stop:
Sts!Stopped:
::Sts!Error:
errCode=1
errCode=0:Cntrl?Start:Sts!Started:
D
:Cmd!Off::
:Cntrl?Reset:
Sts!Initial:
errCode=0
Stop
Off
MergedController Verhalten
Operate
Operate
:CntrlCmd?StopOff:
Sts!Stopped:
D
::Sts!Error:
errCode=1
errCode=0:
CntrlCmd!StartOn:
Sts!Started:
StopInitOff
:CntrlCmd?Reset:
Sts!Initial:
errCode=0
:Cmd!On::
Abbildung 4.1: Alternative Vereinigung der Automatenzustände
Da bei dieser Definition die in Abschnitt 4.3 eingeführten Abhängigkeiten
und die in Abschnitt 5.5 gezeigte Konstruktion ebenfalls auf die Potenzmengenbetrachtung
angepasst werden müssen und dadurch zusätzliche Iterationen und
Quantifizierungen notwendig sind, die das Verständnis erschweren, bleiben wir
an dieser Stelle bei der einfachen Variante.
4.2.2 Nutzung zusätzlicher Transformationsschritte
Wir können auch die Modellierungsmöglichkeiten von AutoFocus 2 nutzen und
die Zustände Initial und Stop aus Abbildung 4.1 zu einem hierarchischen Zustand
zusammenfassen. Dieser einzelne neue Zustand kann dann wiederum mit
einem einelnen Zustand unifiziert werden. Dies entspricht also wieder der Definition
der Unifikationsrelationen in Abschnitt 4.1.
Wir ändern bei dieser Variante also nicht die Definition der Relationen,
sondern nutzen zusätzliche Transformationsschritte um das Modell vorher in
eine entsprechende Form zu transformieren.
Diese Variante werden wir in dieser Arbeit allerdings nicht weiter verfolgen.
Es sei aber angemerkt, dass bei der Zusammenfassung von Zuständen zu einem
hierarchischen Zustand auch beachtet werden muss, wie die ein- und ausgehenden
Transitionen transformiert werden. Sie müssen in entsprechende Segmente
zerlegt werden oder umgekehrt zusammengefasst werden.
4.2.3 Interpretation der Unifikationsrelation
Für das Konstruktionsverfahren haben wir verschiedene Möglichkeiten die Unifikationsrelationen
zu interpretieren. Betrachten wir die folgende Relation über
Komponenten:
componentMap = { (CompA, CompB), (CompB, CompC) }
Es ergeben sich nun die folgenden zwei Interpretationen:
34

1. Es werden zwei neue Komponenten erzeugt, wobei die erste durch Vereinigung
von CompA und CompB, die zweite durch Vereinigung von CompB
und CompC entsteht.
2. Vom Konstruktionsverfahren könnte genauso erwartet werden, dass die
angegebene Relation unvollständig ist und zunächst mittels der Bildung
der transitiven Hülle vervollständigt werden muss. Somit könnte obige
Relation also auch dafür stehen, dass nur eine neue Komponente erzeugt
wird, die aus der Vereinigung von CompA, CompB und CompC entsteht.
Dieser Fall entspricht der vorher erläuterten alternativen Möglichkeit mit
Potenzmengen zu arbeiten.
In Kapitel 5 verwenden wir die zusätzliche Bedingung, dass Unifikationsrelationen
partielle, ein-eindeutige Funktionen sein müssen. Auch wenn dadurch die
in Abbildung 4.1 gezeigte Spezifikationsvereinigung nicht mehr möglich ist, denn
jeder Zustand der ersten Komponente kann nur mit höchstens einem Zustand
der zweiten Komponente unifiziert werden und vice versa. Diese Vereinfachung
ist aus Gründen der Verständlichkeit der ODL-Ausdrücke zur Definition der
Unifikationsrelationen und der Generierungsausdrücke notwendig.
4.3 Abhängigkeiten der Modellelemente
Die Assoziationen und Beziehungen der Modellelemente, wie sie durch das Metamodell
festgelegt werden, haben auch eine Bedeutung in Bezug auf das Vereinigungsproblem.
Sie stellen genau die Abhängigkeiten der Modellelemente dar, die
bei der Unifikation beachtet werden müssen. Abbildung 4.2 zeigt den Abhängigkeitsgraphen,
der sich aus dem Metamodell ergibt. Die gerichteten Kanten lassen
sich hierbei nach ihrem Verlauf in interne Abhängigkeiten (Kanten mit gleichem
Start- und Zielknoten) und externe Abhängigkeiten (Kanten mit verschiedenen
Start- und Zielknoten) einteilen.
4.3.1 Interne Abhängigkeiten
Wir sprechen von einer (unifikationsrelations-)internen Abhängigkeit, wenn die
zwei zu unifizierenden Modellelemente bezüglich eines Attributwerts gleich sein
müssen, damit die Unifikation aus semantischer Sicht sinnvoll ist. Solche Abhängigkeiten
beziehen sich auf eine einzelne Modellelementklasse. In Abbildung
4.2 sind sie als gestrichelte Kanten eingezeichnet.
Eine interne Abhängigkeit ist ein Prädikat, dass von allen Tupeln einer Unifikationsrelation
erfüllt werden muss und insbesondere nicht von anderen Unifikationsrelationen
abhängt. Im Abhängigkeitsgraph sind dies reflexive Kanten.
Solche Prädikate haben folgende Grundstruktur (one ist das erste, two das zweite
Element der Tupel in u):
∀u ∈ UnifRel : u.one.SomeAttribute = u.two.SomeAttribute
Im Beispiel ist dies bei der Unifikationsrelation von Port der Fall. Es können
nur solche Ports miteinander unifiziert werden, die die gleiche Richtung aufweisen,
d.h. in Bezug auf das Direction-Attribut äquivalent sind. Die Unifikation
eines Eingabeports mit einem Ausgabeport ist syntaktisch möglich, denn beide
35

DataDefinition
Component
Constructor
Port
State
Selector
Transition
Input / Output
Abbildung 4.2: Abhängigkeitsgraph der Metamodellelemente
gehören zur Metamodellklasse Port. Dies hat aber keine sinnvolle Bedeutung,
da AutoFocus 2-Modelle keine bidirektionalen Schnittstellen an Komponenten
haben.
Das Beispiel setzen wir direkt in ODL um. Wir erhalten folgenden Teilausdruck:
forall pme:portMap .
pme.one.Direction.IsEntry = pme.two.Direction.IsEntry
Mit portMap ist hier die Unifikationsrelation bezüglich Port bezeichnet; im
ODL Typsystem hat portMap den Typ set (Port, Port). Direction ist lediglich
das Kapselobjekt, das den boolschen Wert IsEntry umschließt. Letzterer zeigt
die Richtung, also Ein- oder Ausgabe, an.
4.3.2 Externe Abhängigkeiten
Im Gegensatz zu internen Abhängigkeiten stellen die externen Abhängigkeiten
Bedingungen zwischen verschiedenen Modellelementklassen dar (nicht-reflexive
Kanten des Abhängigkeitsgraphen). Diese Prädikate sind Bedingungen zwischen
zwei Unifikationsrelationen mit folgender Struktur:
∀u 1 ∈ UnifRel 1 : ∃u 2 ∈ UnifRel 2 :
u 1 .one.AssociatedEntity = u 2 .one ∧ u 1 .two.AssociatedEntity = u 2 .two
Die gerichteten Kanten des Graphen in Abbildung 4.2 sind so zulesen, dass
der Startknoten der allquantifizierten Tupelmenge UnifRel 1 und der Zielknoten
der existenzquantifizierten Tupelmenge UnifRel 2 entspricht.
36

Betrachten wir nun die im Beispiel vorhandene externe Abhängigkeit zwischen
Port und Component. Diese sagt aus, dass es für alle Tupel in der Unifikationsrelation
von Port ein Tupel in der Unifikationsrelation von Component geben
muss, so dass die unifizierten Ports zu unifizierten Komponenten korrespondieren.
Auch diese Abhängigkeit kann wieder direkt in ODL formuliert werden:
forall pme:portMap .
exists cme:componentMap . (
pme.one.Component = cme.one and pme.two.Component = cme.two)
Mit componentMap ist hier die Unifikationsrelation bezüglich Component bezeichnet.
Der Selektorausdruck .Component entspricht der Navigation im Metamodell
von Port entlang der Aggregation zu Component.
4.4 Lösungsverfahren
Nachdem wir nun die Interpretation der Kanten des Abhängigkeitsgraphen
erläutert haben, wenden wir uns der Interpretation der Knoten zu.
Wie in Abschnitt 4.1 gezeigt, suchen wir für jedes relevante Metamodellelement
eine Unifikationsrelation. Jeder Knoten im Abhängigkeitsgraph liefert
uns hierbei ein Prädikat, dass diese Relation, im Hinblick auf eine korrekte Gesamtlösung,
erfüllen muss. Das Prädikat ergibt sich aus den jeweiligen Abhängigkeiten
(ausgehende Kanten) durch deren Verknüpfung mit logischem Und.
Die Umsetzung in ODL optimieren wir, indem wir die identischen Allquantoren
zusammenfassen und nur die Unterausdrücke mit and verknüpfen. Hier
wieder das Beispiel von Port:
forall pme:portMap . (
/* component dependency */
exists cme:componentMap . (
pme.one.Component = cme.one and pme.two.Component = cme.two
) and
/* data definition dependency */
exists dme:datadefMap . (
/* equivalence is quite complex here */
/* due to class hierarchies */
pme.one.DefinedType.Model = dme.one.TConst and
pme.two.DefinedType.Model = dme.two.TConst
) and
/* internal dependency */
pme.one.Direction.IsEntry = pme.two.Direction.IsEntry
)
Mit Hilfe dieser Prädikate können wir nun alle Lösungen des Vereinigungsproblems
berechnen. Die zu evaluierende Formel besteht aus der Existenzquantifizierung
aller Unifikationsrelationen und der Und-Vernüpfung der Knotenprädikate.
exists componentMap:set (Component, Component) .
exists portMap:set (Port, Port) .
37

...
exists constructorMap: set (Constructor, Constructor) .
exists datadef:set (DataDef, DataDef) . (
forall pme:portMap . ( ... ) and
forall come:constructorMap . ( ... ) and
...
)
Die Relationen (im Beispiel portMap, datadefMap, componentMap, usw.) sind also
die Variablen eines Belegungsproblems. Leicht zu folgern ist, dass für dieses
Problem eine triviale Lösung (die leere Relation für alle Unifikationsrelationen)
existiert.
4.5 Komplexitätsbetrachtung
Am Ende dieses Kapitels wenden wir uns der Frage zu, mit welchem Berechnungsaufwand
das hier gezeigte Lösungsverfahren funktioniert. Wir werden sehen,
dass der Aufwand bereits für sehr kleine AutoFocus 2-Modelle exponentiell
groß wird.
Um alle möglichen Lösungen des Vereinigungsproblems zu finden müssen wir
sämtliche Unifikatorkandidaten auf ihre Sinnfälligkeit prüfen, d.h. die im vorherigen
Abschnitt gezeigten Prädikate bezüglich dieser Kandidaten evaluieren.
Die Anzahl solcher Kandidaten lässt sich mit dem Wissen über den Aufbau des
Lösungsraumes (siehe Abschnitt 4.1) leicht ermitteln. Für jede Unifikationsrelation
gibt es
2 (u·u)
Möglichkeiten. u ist dabei die Anzahl der Modellelemente dieser Relation, also
bspw. die Anzahl der Modell vorhandenen Komponenten.
Aufgrund der Abhängigkeiten müssen wir zusätzlich alle Kombinationen von
konkreten Unifikationsrelationen ausprobieren. Dies entspricht genau der Existenzquantifizierung
der Unifikationsrelationen, wie im vorherigen Abschnitt dargestellt.
Insgesamt erhalten somit
2 u2 1 +u2 2 +...+u2 k
Unifikatorkandidaten. In unserem Beispiel ist k = 9 wegen der neun Modellelementklassen.
Hieraus ergibt sich, dass selbst für die kleinsten praxisnahen Modelle
die Berechnung sämtlicher Unifikatoren nicht effizient durchgeführt werden
kann.
4.6 Zusammenfassung
In diesem Kapitel haben wir das Problem der Spezifikationsvereinigung aus
theoretischer Sicht untersucht. Wir haben zunächst passende Lösungsstrukturen
definiert, die Unifikationsrelationen. Daraufhin erfolgte eine genauere Betrachtung
dieser Relationen, insbesondere ihre Interpretation im Hinblick auf
die konstruktive Vereinigung von Spezifikationen und alternative Definitionen
für diese Relationen.
38

Ausgehend vom AutoFocus 2-Metamodell haben wir dann Abhängigkeiten
zwischen den einzelnen Unifikationsrelationen untersucht und jeweils ein Schema
zur Umsetzung in ODL angegeben. Somit standen uns die notwendigen
Hilfsmittel zur Verfügung um das Lösungsverfahren festzulegen, welches wir
abschließend auf den Berechnungsaufwand hin untersuchten. Es muss hierzu
angemerkt werden, dass eine Erweiterung der Unifikation auf komplexere Ein-
/Ausgabeterme und die Hinzunahme der Vorbedingungen und Aktionen von
Transitionen, eine Erweiterung der hier beschriebenen Abhängigkeiten auf polymorphe
Fälle erfordert, d.h. wir müssen auch die andere mögliche Unterklassen
von Termen berücksichtigen und können nicht wie hier von Konstruktoren allein
ausgehen. Wir gehen hierauf auch kurz bei den Anmerkungen zum ODL
Programm im Anhang A ein.
Wie wir gesehen haben, ist der Berechnungsaufwand aller Lösungen bereits
für kleine Modelle sehr hoch. Ausserdem sind viele der Lösungen für die praktische
Umsetzung nicht relevant. Im folgenden Kapitel wollen die hier eingeführte
theoretische Grundlage für ein interaktive Unterstützung des Entwicklers nutzen,
um somit ein methodisch sinnvolles und effizientes Transformationsverfahren
zu erhalten und insbesondere die Brücke in die praktische Anwendung
schlagen.
39

Kapitel 5
Interaktive
Spezifikationsvereinigung
Nachdem wir nun formal gezeigt haben, wie das Problem der Spezifikationsvereinigung
gelöst werden kann, wenden wir uns nun einer konkreten Umsetzung
in AutoFocus 2 und ODL zu.
Zunächst werden wir das interaktive Vorgehen motivieren und die Brücke
von der Theorie in die Praxis schlagen. Der interaktive Ablauf besteht aus zwei
Phasen, die wir getrennt voneinander darstellen werden. Als Erstes wird der analytische
Teil des interaktiven Ablaufs in eine Folge von einzelnen Dialogschritten
gegliedert, wobei wir ebenfalls alternative Abläufe beleuchten. Danach werden
wir die wesentlichen Dialoge dieses Teils mit ODL formulieren und verschiedene
Varianten illustrieren.
Im letzten Abschnitt dieses Kapitels erläutern wir die technische Umsetzung
des zweiten, konstruktiven Teils der Spezifikationsvereinigung in ODL.
5.1 Übergang zum interaktiven Ablauf
In Kapitel 4 interessierten wir uns für die Berechnung aller Lösungen der Spezifikationsunifkation
für ein gegebenes Modell. Aus Sicht des Entwicklers ist
es allerdings nicht relevant, alle diese Lösungen zu berechnen. Er möchte vielmehr
die Unterstützung in Form von Einzelschritten, sodass er durch mehrere
Einzelentscheidungen die Gesamtlösung zusammensetzt. Wir werden daher die
Erkenntnisse aus der Theorie nutzen, um einen interaktiven Unifikationsablauf
zu erstellen. Ein möglicher Anfang und ein Beispiel für Einzelschritte wäre hier
zuerst die Auswahl welche beiden Komponenten vereinigt werden sollen, gefolgt
von der Entscheidung wie die Schnittstelle zu unifizieren ist.
Das interaktive Vorgehen ist aus methodischer Sicht besser, da wir gezielt
nur auf die Lösung hinarbeiten, die der Nutzer auch möchte, anstatt alle möglichen
Lösungen zu berechnen. Gleichzeitig erhalten wir durch die Einführung der
Interaktion ein effizientes Verfahren, da jeweils nur die Einzelentscheidungen im
Kontext der vorhergehenden Entscheidungen auf ihre Durchführbarkeit geprüft
werden müssen und nicht eine erschöpfende Suche über alle Unifikationsrelationen
durchgeführt werden muss.
40

Für die interaktive Spezifikationsvereinigung nutzen wir die Dialogfähigkeiten
von ODL und gliedern den Ablauf in mehrere Dialogeinzelschritte. In jedem
wird der Entwickler nach einzelnen Teilen des aus dem Theorieteil bekannten
Unifikators gefragt, wobei ständig die Zulässigkeit seiner Entscheidungen überprüft
wird. Es ist ihm nur erlaubt von einem Dialog aus fortzufahren, wenn die
von ihm definierte Unifikationsrelation bezüglich der Abhängigkeiten mit seinen
früheren Entscheidungen verträglich ist. Andernfalls wird eine Fortsetzung des
interaktiven Ablaufs verhindert bis die Korrektheit gemäß den Abhängigkeiten
hergestellt ist oder abgebrochen wird.
Bei der Definition des Ablaufs mittels ODL könnten wir sehr schematisch
vorgehen und für jedes Metamodellelement bzw. jede Unifikationsrelation einen
gleichartigen Abfragedialog definieren. Da wir jedoch maximalen Nutzen aus
den Entscheidungen des Nutzers ziehen wollen, werden wir hier eine nichtschematische
Variante des ODL-Ablaufs aufbauen und für jeden Teil des Unifikators
einen möglichst nutzerfreundlichen Dialog konstruieren, indem wir gewisse
Vorberechnungen vornehmen. Die interne Abhängigkeit bei Port bietet sich
hierfür beispielsweise an.
Desweiteren werden wir einige Unifikationsrelationen automatisch bestimmen,
indem wir die Abhängigkeiten und die getroffenen Festlegungen zur Berechnung
nutzen. Dies gilt im folgenden für den Bereich der Datendefinitionen,
obwohl auch hier eine interaktive Variante denkbar ist (vgl. Abschnitt 3.4).
5.2 Festlegung der Dialogführung
In Abbildung 4.2 auf Seite 36 haben wir die für die Spezifikationsvereinigung
relevanten Metamodellelemente und deren Abhängigkeiten gesehen. Für jedes
Element ergab sich dabei genau eine Unifikationsrelation. Diese werden wir nun
nicht durch existenzielle Quantifizierung, wie in Abschnitt 4.4, berechnen, sondern
interaktiv durch den Entwickler bestimmen lassen. Die Forderung, dass
Unifikationsrelationen partielle ein-eindeutige Funktionen sein müssen halten
wir aufrecht. Wie in Abschnitt 4.2 gezeigt, ist dies eine Hilfsforderung um den
Konstruktionsteil nicht zu verkomplizieren.
Die naheliegende Umsetzung, nämlich jede Relation vom Nutzer aus allen
vorhandenen Modellelementen auszuwählen, liefert zwar ein effektives, interaktives,
aber kaum praktikables und auch nicht effizientes Verfahren. Wir werden daher
der Reihe nach alle Unifikationsrelationen durchgehen und eine jeweils günstige
Dialogvariante erläutern. Insbesondere möchten wir die Auswahlmöglichkeiten
eines Dialogs auf das zulässige Minimum beschränken. Wir nutzen dazu
die festgelegten Abhängigkeiten. Bei der Reihenfolge der Einzelschritte orientieren
wir uns an den Modellierungssichten von AutoFocus 2. Beginnend mit der
Struktursicht, kommen wir über die Verhaltenssicht schließlich zur Datensicht.
Die hier beschriebene Dialogführung entspricht dem Programmlisting in Anhang
A. Sie erhebt nicht den Anspruch absolut zu sein, sondern stellt vielmehr
eine Möglichkeit dar, die Spezifikationsvereinigung interaktiv umzusetzen. An
den entsprechenden Stellen geben wir jeweils den Hinweis auf alternative Dialogvarianten,
die meist auch eine Anpassung des in Abschnitt 5.5 beschriebenen
Konstruktionsteils erfordern.
41

5.2.1 Struktursicht
Die Struktursicht umfasst die Metamodellelemente Component und Port.
Component
Der Entwickler trifft als erstes die Entscheidung, welche beiden Komponenten
er vereinigen möchte. Im Gegensatz zur allgemeinen Definition in Kapitel 4,
verwenden wir anstatt der Unifikationsrelation also nur ein Tupel von Komponenten.
Sollen mehrere Komponenten vereinigt werden, ist der Gesamtablauf
mehrmals durchzuführen. Als Dialogansicht verwenden wir die Darstellung zweier
Listen der im Modell vorhandenen Komponenten, wie in Abbildung 5.1.
Abbildung 5.1: Dialog für Komponenten (Component)
Port
Aufgrund der Abhängigkeiten können wir die Entscheidungsmöglichkeiten des
Entwicklers bei der Schnittstellenvereinigung unter zu Hilfenahme der vorangegangenen
Entscheidung über die Komponenten schon einschränken. Wir bieten
nur die Port-Elemente zur Auswahl an, die der ersten bzw. zweiten Komponente
entsprechen. Desweiteren führen wir eine Vorberechnung durch und lassen den
Entwickler die von ihm gewünschten aus der Menge der Port-Tupel auswählen,
wobei diese Tupel bezüglich der internen Abhängigkeit von Port über das Richtungsattribut
bereits zulässig sind. Abbildung 5.2 zeigt den Dialog mit der Liste
der berechneten Tupel.
Eine Dialogvariante wäre die Aufteilung der Port-Vereinigung in zwei Dialogschritte,
jeweils einer für die Ein- und für die Ausgabeschnittstellen. Als Darstellung
könnten wir dabei die Ansicht wie für die Zustandsvereinigung (siehe
42

Abbildung 5.2: Dialog für Schnittstellen (Port)
nächster Abschnitt) wählen. Um den im Programmlisting verwendeten Konstruktionsteil
weiter verwenden zu können, müssten die Ergebnisse der beiden
Dialoge allerdings erst zu einer Menge zusammengefasst werden. Alternativ kann
natürlich auch die Konstruktion angepasst werden.
5.2.2 Verhaltenssicht
Die Verhaltenssicht umfasst die Metamodellelemente State, Transition, Input
und Output.
State
Bei der Vereinigung der Zustände sind wir voll auf die Entscheidungen des Benutzers
angewiesen. Wir bieten ihm daher, wie in Abbildung 5.3 ersichtlich, die
Möglichkeit die Unifikationsrelation vollständig selbst zu definieren. Die einzige
Einschränkung, die wir bereits angewandt haben, ist der Inhalt der beiden
Zustandslisten, die die Zustände der jeweiligen Komponenten, wie sie im ersten
Schritt gewählt wurden, enthält.
Transition
Wie in Abbildung 5.4 zu sehen, haben wir den Dialog für die Zustandsübergänge
mit einer Vorberechnung vereinfacht. Der Nutzer bekommt nur die Transitionspaare
zur Auswahl, die garantiert mit seiner Entscheidung über die Unifikation
von Zuständen im vorherigen Dialogfenster vereinbar sind. Eine Dialogform
analog der vorherigen, erscheint nicht günstiger, da es für Transitionen ja gleich
43

Abbildung 5.3: Dialog für Zustände (State)
44

zwei Abhängigkeiten zu der Zustandsrelation gibt (Start- und Zielzustand der
Transition). Durch die Vorberechnung der möglichen Tupel, erhöhen wir die
Übersichtlichkeit und Verwendbarkeit dieses Dialogschrittes erheblich.
Abbildung 5.4: Dialog für Zustandsübergänge (Transition)
Input / Output
Die Verschmelzung von Ein- und Ausgabeausdrücken führen wir nicht mehr
interaktiv durch, sondern berechnen die entsprechende Unifikationsrelation unter
Verwendung der Relationen von Transition und Port. Es werden also die
Input- bzw. Output-Elemente vereinigt, die zu unifizierten Transitionen gehören
und sich auf unifizierte Schnittstellen beziehen. Den dritten für die Vereinigung
relevanten Wert, das Ein-/Ausgabesignal (Constructor), beachten wir an dieser
Stelle noch nicht, sondern verwenden die hier berechneten Unifikationsrelationen
später als Bedingung für die Berechnung der Constructor-Relation.
5.2.3 Datensicht
Die Verhaltenssicht umfasst die Metamodellelemente DataDef, Constructor, und
Selector. In Kapitel 3 haben wir gesehen, wie ein Dialog für die Unifikation
von Datentypdefinition aussehen könnte. Hier wollen wir nun die sich aus den
vorherigen Entscheidungen ableitenden, unifzierten Typdefinitionen berechnen
und somit die Datensicht bei der Spezifikationsvereinigung vollständig automatisieren.
Constructor
Wir beginnen die Berechnungen für die Datensicht mit der Konstruktorunifikation.
Aus den zuvor berechneten Unifikationsrelationen für Input und Output
45

leiten wir die zu vereinigenden Konstruktorpaare ab. Dazu betrachten wir die
Termstruktur der Ein-/Ausgabeausdrücke.
Wir erhalten drei Fälle die sich aus der Termstruktur ergeben:
1. Die Ausdrücke sind parameterlose Konstruktorterme, d.h. wir können direkt
ableiten, dass diese Konstruktoren vereinigt werden müssen. Im Beispiel
tritt nur dieser Fall auf.
2. Die zwei Konstruktoren treten als angewandte Funktionen in den Applikationstermen
auf, beispielsweise Const-One(...) und Const-Two(...).
3. Die zwei Konstruktoren treten als Parameterwerte in den Applikationstermen
auf.
Der zweite und dritte Fall kann bei komplexeren Termen mehrmals geschachtelt
auftreten, beispielsweise wenn als Parameter für eine Konstruktorapplikation
wieder eine parametrierte Konstruktorapplikation verwendet wird. Deshalb
werden wir die Konstruktoranalyse mittels einer Fixpunktmenge durchführen.
Wir untersuchen alle unifizierten Ein-/Ausgabeausdrücke ihrer Struktur nach
rekursiv auf Applikationselemente und leiten aus diesen die zu unifzierenden
Konstruktoren ab. Hierfür ist zusätzlich die Berechnung der Unifikationsrelation
für Appl-Elemente, also Funktionsapplikationen, notwendig.
DataDef
Die Unifikationsrelation für DataDef-Elemente leitet sich aus zwei bisherigen
Entscheidungen ab. Erstens ist für jedes Paar von unifizierten Port-Elementen
deren Typen zu unifizieren. Zweitens müssen für zwei unifizierte Konstruktoren
auch deren Datendefinitionen vereinigt werden.
Da wir die Berechnung der Konstruktorunifikation vorgezogen haben, können
wir die Unifikationsrelation für DataDef nun leicht berechnen.
Selector
Selektoren stellen keine Teile der Terme für Ein- und Ausgaben dar, wie die
Konstruktoren. Aus Sicht der Datendefinitionen müssen wir sie jedoch auch einer
Unifikation unterziehen, damit die generierten Terme auch der generierten
Datendefinition entsprechen. In dem hier vorgestellten Ablauf wird die Selektorunifikation
ebenfalls berechnet und nicht dem Benutzer übertragen.
Für die Berechnung stehen uns bei Selektoren verschiedene Möglichkeiten
zur Verfügung die Vereinigung durchzuführen. Zunächst können wir die Namensgleichheit,
wie in Kapitel 3, als Vereinigungskriterium heranziehen. Desweiteren
können wir den Ergebnistyp des Selektors benutzen, um zu unifzierende Selektoren
zu identifizieren. Dabei treten allerdings sehr leicht Mehrdeutigkeiten
auf, die wir eventuell wieder mit Hilfe des Nutzers lösen können. An dieser
Stelle wollen wir die dritte Möglichkeit verwenden, nämlich die Struktur der
Datendefinitionen. Wir unifizieren die Selektoren also nach ihrer Position in der
jeweiligen Konstruktordefiniton.
Als Grundlage für die Berechnung verwenden wir die Unifikationsrelationen
von DataDef und Constructor. Es werden die Selektoren vereinigt, die zu vereinigten
Konstruktoren gehören. Per Definition der Constructor-Relation muss
46

es mindestens einen Term geben, der die Vereinigung der beiden Selektoren erzwingt.
Wir müssen nur noch die Selektorindizes innerhalb ihres definierenden
Konstruktors und die Vereinigung ihrer Ergebnistypen in der DataDef-Relation
prüfen, falls die Typen nicht identisch sind.
5.3 Alternative Interaktionsabläufe
Die Auswahl der einzelnen Schritte der Dialogführung ist so getroffen worden,
dass sie eine möglichst breite Palette von Entscheidungsvarianten und ODL
Techniken präsentiert. Der vorgestellte Ablauf stellt keinesfalls den einzig möglichen
oder gar den passendsten dar. Welche Variante zum Einsatz kommt, muss
im Kontext des konkreten Anwendungsszenarios und des Entwicklungsprozesses
festgelegt werden.
Abhängig von den Anforderungen des Einsatzgebietes und den Entwicklern
muss jeweils im konkreten Fall die passende Variante der Spezifikationsunifikation
ermittelt werden. Wir geben hier nur eine Übersicht, welche Aspekte einer
Prüfung unterzogen werden müssen.
Die ersten beiden Fragen, die abgewogen werden müssen, sind der Grad der
Interaktion, d.h. welche Elemente interaktiv und welche automatisch nach bestimmten
Regeln und Verfahren unifziert werden, und die Reihenfolge, in der die
Einzeldialoge zur Bearbeitung angeboten werden. Wir können zum Beispiel die
Entscheidungen in Bezug auf die Datensicht nach vorne ziehen und diese nach
der Schnittstellenunifikation interaktiv durch den Nutzer durchführen lassen.
Als Folge würden die Entscheidungen über die Unifikation von Zuständen und
Transitionen durch die dann bereits festgelegte Datensicht beschränkt werden.
Zu Demonstrationszwecken wählten wir hier jedoch die automatisierte Variante
für die Datentypdefinitionen.
Wie bereits angesprochen, gibt es im Bereich der Datentypdefinitionen unterschiedliche
Varianten die Konstruktoren und Selektoren zu vereinigen, insbesondere
wenn wir die entsprechenden Unifikationsrelationen automatisch berechnen
wollen. Neben dieser Betrachtung ist auch Einbeziehung der Frage, inwieweit
Selektoren in den Termen auftreten, wichtig, da bei einfachen Komponenten
häufig auch nur einfache Datentypen (also nur parameterlose Konstruktoren)
auftreten. Dies hat zur Folge, dass die Selektorunifikation nicht mehr notwendig
ist und der Gesamtablauf somit beschleunigt werden kann. Die Beantwortung
dieser Frage kann aber nur im konkreten Entwicklungsumfeld erfolgen.
Neben der Reihenfolge der Einzelschritte der Dialogführung können auch
andere Definitionen der Unifikationsrelation zum Einsatz kommen, wie wir in
Abschnitt 4.2 gesehen haben. Entsprechende Anpassungen in der Dialogführung
und den Einzeldialogen, sowie dem Konstruktionsteil, sind hierfür notwendig,
was wir hier nur anmerken wollen.
Es sei noch einmal hervorgehoben, dass ein konkreter Interaktionsablauf an
einen Entwicklungsprozess angepasst werden muss. Wir konzentrieren uns hier
auf die Darstellung der derzeitigen Fähigkeiten und Möglichkeiten von ODL,
noch nicht jedoch mit der Evaluierung in einem spezifischen Entwicklungsprozess.
47

5.4 Umsetzung der Dialogführung in ODL
Nachdem wir nun den Ablauf der Dialogführung illustriert und beschrieben,
und die für das Ablaufdesign relevanten Fragen skizziert haben, wenden wir uns
nun der technischen Seite zu. In diesem Abschnitt werden wir die Dialogschritte
als ODL Ausdrücke formulieren. Dabei konzentrieren wir uns hier nur auf die
Besonderheiten ausgewählter Schrittes. Das komplette Programmlisting findet
sich im Anhang A. Es ist gegenüber den hier gemachten Ausführungen noch
erweitert worden, damit es zu dem Beispiel aus Kapitel 2 passt.
5.4.1 Komponentendialog
Der Komponentendialog ist durch einen sehr einfachen ODL-Ausdruck definiert:
context component_pair:(one:Component, two:Component) .
Wir erhalten vom Benutzer ein 2-Tupel von Komponenten, dessen Elemente
wir über die Tupelselektoren one und two erreichen. Diese Konvention für Tupelselektoren
werden wir im Folgenden auch für die anderen Datenstrukturen
beibehalten.
5.4.2 Vorberechnung für Schnittstellendialog
Für den Dialog zur Vereinigung der Schnittstellen (Port-Elemente) führen wir
eine Vorberechnung durch. Dazu definieren wir zunächst ein Prädikat, das die
externe Abhängigkeit von Port zu Component und die interne Abhängigkeit in
Bezug auf das Direction-Attribut, wie in Kapitel 4 gezeigt, kapselt.
define Consistent_Component_Port(
component_pair:(one:Component, two:Component),
pm_elem:(one:Port, two:Port)
) := (
pm_elem.one.Direction.IsEntry =
pm_elem.two.Direction.IsEntry and
component_pair.one = pm_elem.one.Component and
component_pair.two = pm_elem.two.Component
) .
Mit diesem Prädikat können wir nun alle Kombinationen von Port-Elementen
der zwei gewählten Komponenten auf Vereinbarkeit mit den Abhängigkeiten
prüfen. Wir setzen hier den Fixpunktoperator ein, um die entsprechenden Tupel
in der Menge port map possible aufzusammeln.
exists port_map_possible: lfp FP1 set
fp1_it:(one:(component_pair.one.Ports),
two:(component_pair.two.Ports)
) with (
call Consistent_Component_Port(component_pair, fp1_it)
) .
48

Nach den Vorberechnungen lassen wir den Benutzer nun eine Teilmenge der
eben berechneten Menge port map possible auswählen. Durch das Beschränkungsprädikat
erzwingen wir, dass die somit nutzerdefinierte Unifikationsrelation
für die Schnittstelle, wie in Abschnitt 4.2 festgelegt, eine partielle ein-eindeutige
Funktion darstellt. Wie dort beschrieben kann diese Forderung entfallen, was
aber zur Folge hat, dass die Konstruktion der neuen Komponente entsprechend
angepasst werden muss.
context port_map:{pm_test:set port_map_possible |
forall pm1:pm_test . forall pm2:pm_test . (
(pm1.one = pm2.one) equiv (pm1.two = pm2.two)
)
} .
Die Ein-Eindeutigkeitsforderung werden wir im Folgenden durch den Ausdruck
call Unique(XYZmap) abkürzen, wobei XYZmap durch die jeweils gemeinte
Unifikationsrelation ersetzt wird. Die Abkürzung dient hier nur der Übersichtlichkeit
und ist im Programmlisting im Anhang als korrekter ODL-Ausdruck
jeweils ausprogrammiert 1 .
5.4.3 Dialog für Zustände
Der Dialog für die Zustandsunifikation erlaubt dem Benutzer ohne Vorberechnungen
die Vereinigung der State-Elemente festzulegen. Durch die Beschränkung
fordern wir zum einen wieder die Ein-Eindeutigkeit, zum anderen die Tatsache,
dass mindestens ein Zustand der beiden Automaten unifiziert sein muss,
damit im Ergebnis zumindest ein zusammenhängender Automat entsteht.
context state_map:{
sm_test:set (
one:(component_pair.one.Automaton.State.SubStates),
two:(component_pair.two.Automaton.State.SubStates)
) |
call Unique(state_map) and exists sm0:sm_test . true
} .
Wir haben an dieser Stelle von Einbeziehung der internen Abhängigkeit bei
Zuständen, nämlich die Unterscheidung nach der Art des Zustandes (Start-,
Zwischen- und Endzustand), abgesehen.
5.4.4 Berechnung der Ein-/Ausgabevereinigungen
Die Berechnung der Unifikationsrelationen für Input und Output realisieren wir
in dem wir die externen Abhängigkeiten zu Transition und Port nutzen. Das
Codebeispiel zeigt den Fall der Eingabeausdrücke.
exists input_map: lfp FP3 set fp3_it:(one:Input, two:Input)
with (
exists tm_fp3:transition_map . (
1 ODL fehlen zur Zeit noch die Mechanismen und Konzepte polymorphe Prädikate für
Eindeutigkeit, Bijektivität, etc. zu formulieren
49

tm_fp3.one = fp3_it.one.TransitionSegment and
tm_fp3.two = fp3_it.two.TransitionSegment
) and
exists pm_fp3:port_map . (
fp3_it.one.Port.Model = pm_fp3.one and
fp3_it.two.Port.Model = pm_fp3.two
)) .
Die so berechneten Vereinigungen werden wir sogleich einsetzen um die notwendigen
Vereinigungen von Konstruktoren zu berechnen.
5.4.5 Unifikation der Datendefinitionen
Als letzten Teil setzen wir die Unifikation der Datendefinitionen in ODL um. Wir
werden dazu die Ein-/Ausgaberelationen verwenden. Für deren Terme führen
wir eine Strukturunifikation, ähnlich der prädikatenlogischen Unifikation, wie
wir sie in Kapitel 3 gesehen haben, durch. Wie in Abschnitt 2.5 festgelegt bestehen
Terme nur aus Konstruktoren, die aus Datendefinitionen stammen. Wir
beginnen daher die Termunifikation mit ihnen.
Berechnung der Konstruktorenvereinigungen
Für die Vereinigung der Konstruktoren sammeln wir zunächst alle Paare von
Termelementen (Appl), die Funktionsapplikationen von Konstruktoren darstellen
auf. Diese Paare erhalten wir entweder direkt aus den Termen der unifizierten
Ein- bzw. Ausgabeausdrücke (Input/Output) oder rekursiv als Parameter
aus bereits gefundenen Paaren. Deshalb verwenden wir einen Fixpunktausdruck
um diese rekursive Suche durchzuführen. Die resultierende Menge stellt
gewissermaßen wieder eine Unifikationsrelation dar, denn sie enthält die Paare
von Appl-Elementen, die durch die Termstruktur und die unifizierten Ein-
/Ausgabeausdrücke zueinander korrespondieren.
exists appl_fixpoint: lfp FP_Appl set
fpappl_it:(one:Appl, two:Appl)
with (
exists im_fpa:input_map . (
im_fpa.one.Pattern.Model = fpappl_it.one and
im_fpa.one.Pattern.Model = fpappl_it.two
) or
exists om_fpa:output_map . (
om_fpa.one.Expression.Model = fpappl_it.one and
om_fpa.one.Expression.Model = fpappl_it.two
) or
exists fpa_elem:FP_Appl . (
is Args(fpa_elem.one, fpappl_it.one) and
is Args(fpa_elem.two, fpappl_it.two) and
indexOf(fpappl_it.one, fpa_elem.one, "Args") =
indexOf(fpappl_it.two, fpa_elem.two, "Args")
)
) .
50

Konstruktoren können in den Applikationselementen an zwei Stellen auftreten:
als applizierte Funktion (Head-Assoziation) oder als ein Parameter (Args-
Assoziation). Im zweiten Fall muss natürlich zusätzlich der Index des Parameters
beachtet werden.
Mit dem folgenden Prädikat überprüfen wir ein Paar von Applikationen und
ein Paar von Konstruktoren, ob die Unifikation der Konstruktoren durch die
strukturelle Übereinstimmung der Applikationen impliziert wird.
define testApplForConstructor(
appl:(one:Appl, two:Appl),
con:(one:Constructor, two:Constructor)
) := (
/* applied function case */
( appl.one.Head = con.one and
appl.two.Head = con.two
) or
/* parameter case */
( is Args(appl.one, con.one) and
is Args(appl.two, con.two) and
indexOf(con.one, appl.one, "Args") =
indexOf(con.two, appl.two, "Args")
)
) .
Mit dieser Vorberechnung der Applikationselemente und der Definition des
Testprädikats können wir nun die Vereinigungsrelation der Konstruktoren berechnen.
Wir sammeln ein Paar von Konstruktoren in der Fixpunktmenge auf,
wenn es, entweder durch ein Element der Ein- bzw. Ausgaberelation oder durch
ein Paar von Applikationen, als zu unifizierend bestimmt wird.
exists constructor_map: lfp FP4 set
fp4_it:(one:Constructor, two:Constructor)
with (
/* single signal in input pattern */
exists im_fp4:input_map . (
fp4_it.one = im_fp4.one.Pattern.Model and
fp4_it.two = im_fp4.two.Pattern.Model
)
or
/* single signal in output expression */
exists om_fp4:output_map . (
fp4_it.one = om_fp4.one.Expression.Model and
fp4_it.two = om_fp4.two.Expression.Model
)
/* unification implied by application element */
or exists fp4_ap:appl_fixpoint .
call testApplForConstructor(fp4_ap, fp4_it)
) .
Die beiden in diesem Abschnitt berechneten Unifikationsrelationen müssen
noch dahingehend überprüft werden, ob die Input- und Output-Relation die
51

Abhängigkeiten bezüglich dieser beiden Relationen erfüllen. Wir wissen zwar,
dass aufgrund der Konstruktion der beiden Relationen für jedes Konstruktor
bzw. Applikationspaar ein Ein- oder Ausgabepaar existiert, nicht jedoch ob für
alle Ein-/Ausgabepaare die Terme unifiziert werden konnten. Wir müssen also
überprüfen, ob es für alle Ein- und Ausgabeterme entsprechende Konstruktoroder
Applikationsunifikationen gibt. Da Konstruktorenpaare auch durch Applikationspaare
entstanden sein können, sind auch letztere in Bezug auf erstere
zu prüfen. Nur dadurch können wir sicherstellen, dass die unifizierten Terme
strukturäquivalent sind.
Ein Beispiel soll Notwendigkeit dieser Zusatzprüfungen verdeutlichen. Abbildung
5.5 zeigt die Termstruktur von drei Eingabeausdrücken. Die erste und
der zweite Term, sowie der erste und der dritte, können nicht unifiziert werden,
weil die obersten Elemente der Baumdarstellung ein Konstruktor und eine
Applikation sind. Hierfür reicht die Überprüfung der Abhängigkeit zwischen
Eingaberelation und Konstruktorrelation.
p?Con1
q?Con2(Con3)
r?Con4(Con5(Con6))
Con1
Appl
Appl
Con2
Con3
Con4
Appl
Head
Args
Con5
Con6
Abbildung 5.5: Nicht-unifizierbare Termstrukturen
Dass der zweite Term und dritte Term nicht unifiziert werden können, kann
allerdings nur durch die Überprüfung der Applikationsrelation bewiesen werden,
denn die Eingaberelation bezieht die Strukturäquivalenz nur auf das oberste
Element des Terms. Bei der Überprüfung der Applikationsrelation tritt dann
der Fehler im ersten Parameter zutage.
Die genannten Abhängigkeiten können mit dem aus Kapitel 4 bekannten
ODL Standardausdrücken überprüft werden, weshalb wir hier auf eine Wiederholung
des ODL Codes verzichten.
Im Hinblick auf das Konstruktionsverfahren fordern wir wieder die Ein-Eindeutigkeit
von den berechneten Relationen.
Berechnung der Datentypvereinigungen
Vorteil der verherigen umfangreichen Berechnung ist, dass wir nun die Datentyprelation
sehr leicht ableiten können. Zwei Datentypdefinitionen sind zu unifizieren,
wenn es ein Paar von vereinigten Schnittstellen oder vereinigten Konstruktoren
gibt. Dies können wir, wie schon bekannt, durch die Standardausdrücke
für Abhängigkeiten bewerkstelligen.
exists typedef_map:lfp FP_TDef set
fp_tdef_it:(one:DataDef, two:DataDef)
with (
52

call Consistent_Port_TypeDef(port_map, fp_tdef_it) or
call Consistent_Const_TypeDef(constructor_map, fp_tdef_it)
) .
Strukturunifkation der Selektoren
Auch für die Selektorunifikation ist durch die obige Berechnung der Konstruktorrelation
die meiste Arbeit erledigt. Wir müssen lediglich die indexgleichen
Selektorenpaare für die Konstruktorenpaare zusammensuchen. Anders gesagt,
es werden zwei Selektoren unifiziert, wenn die definierenden Konstruktoren vereinigt
sind und sie den gleichen Index haben.
exists selector_map: lfp FP6 set
fp6_it:(one:Selector, two:Selector)
with (
exists cm_fp6:constructor_map . (
fp6_it.one.Constructor = cm_fp6.one and
fp6_it.two.Constructor = cm_fp6.two and
indexOf(fp6_it.one, cm_fp6.one, "Selectors") =
indexOf(fp6_it.two, cm_fp6.two, "Selectors")
))) .
5.4.6 Zusammenfassung
In Abschnitt 5.4 haben wir gesehen, wie die Unifikationsrelationen im Bereich
der Datensicht berechnet wurden. Wir nutzten dafür ein Unifikationsverfahren
für die Terme der Ein-/Ausgabeelemente, das auf der Struktur der Terme beruht.
Wie für die Eingaben des Nutzers in interaktiven Dialogen, mussten auch
die berechneten Ergebnisse auf Konformität mit dem im Folgenden erläuterten
Konstruktionsteil der Spezifikationsvereinigung überprüft werden.
5.5 Konstruktion der Vereinigungskomponente
Bisher haben wir nur den analytischen Teil der Spezifikationsvereinigung betrachtet.
Wir haben geeignete Datenstrukturen, die Unifikationsrelationen, in
ODL definiert und erzeugen durch Nutzerinteraktion konkrete Datenobjekte.
Wir werden diese nun nutzen, um aus den dort enthaltenen Informationen das
Ergebnis der Spezifikationsunifikation zu erstellen, wie wir als erstes erläutern
werden. Wir geben dann zunächst eine kurze Einführung in die konstruktiven
Fähigkeiten von ODL, d.h. das Erzeugen von neuen Elementen und das Erstellen
bzw. Auflösen von Assoziationen im Modell. Danach greifen wir einige Teile
des Konstruktionsverfahrens heraus und erläutern sie. Wir besprechen nicht den
gesamten Konstruktionsausdruck, da er in weiten Teil strukturell identisch ist
und sich nur auf unterschiedliche Teile des Modells bezieht.
5.5.1 Konstruktionsprinzip
Die Konstruktion der verschmolzenen Komponente folgt für die einzelnen Modellelemente
immer dem gleichen Prinzip. Dieses Prinzip ist bis auf die verwen-
53

deten Quellstrukturen identisch zum Vorgehen beim Kopieren einer Komponentenhierarchie,
wie sie in [Höl05] entwickelt wurde.
Jede Instanz einer Unifikationsrelation definiert für uns eine ein-eindeutige
Abbildung zwischen zu unifzierenden Elementmengen. Für konstruieren daher
für jedes Element einer konkreten Unifikationsrelation ein entsprechendes neues
Modellelement, wobei wir uns zusätzlich eine Tabelle erstellen, die das unifizierte
Tupel mit dem neuen Element verknüpft.
Anschließend analysieren wir für jede Modellelementklasse die relevanten
Assoziationen, wie sie in den Ausgangsspezifikationen existieren, und bauen die
entsprechende Struktur mit den neu erzeugten Elementen nach.
Das Konstruktionsverfahren muss dabei auch beachten, dass es nicht nur
unifzierte Modellelemente, sondern auch kopierte Elemente gibt. Der Strukturaufbau
wird diese Unterscheidung entsprechend beachten. Wir konstruieren
hierfür ebenfalls eine Tabelle, die die kopierten Elemente in Beziehung zu neuen
Elementen setzt. Wir führen dies in Abschnitt 5.5.5 vor.
Bezieht sich beispielsweise eine Eingabe im Quellmodell auf einen unifzierten
Port, so verknüpfen wir das das neue Eingabeelement mit dem entsprechenden
neuen Portelement aus der oben als erstes genannten Tabelle, andernfalls suchen
wir uns das Portelement aus der Tabelle für kopierte Portelemente.
5.5.2 Erzeugung neuer Modellelemente mit ODL
Zur Erzeugung von neuen Modellelementen stellt die ODL im Wesentlichen zwei
Mechanismen bereit. Einzelne neue Elemente können durch den Typmodifikator
new in Verbindung mit einem Existenzquantor erzeugt werden. Ein Beispiel
hierfür sehen wir gleich, wenn wir für die beiden zu vereinigenden Komponenten
eine neue erzeugen werden. Neu erzeugte Elemente müssen mit entsprechenden
”result has”-Anweisungen an das bestehende Modell gekoppelt werden, da sie
sonst am Ende der Ausführung wieder verworfen werden 2 .
Das Erzeugen von einzelnen Modellelementen ist allerdings häufig nicht ausreichend
um komplexere Modellstrukturen anzulegen. Im Beispiel ist dies der
Fall, wenn wir die Eingabeausdrücke (Input) konstruieren. Wir benötigen dazu
gleichzeitig Zugriff auf alle neu erzeugten Schnittstellenelemente (Port) und alle
neu erzeugten Konstruktoren (Constructor). Ein ähnlich gelagerter Fall wurde
bereist in [Höl05] erkannt und durch den speziellen ODL-Typ map für Abbildungen
gelöst.
Der Abbildungstyp map dient uns dazu, eine Zuordnungstabelle zu erstellen,
die jeweils einem Element einer Unifikationsrelation bijektiv ein neu erzeugtes
Element gleicher Modellelementklasse zuordnet. Wir haben damit gleichzeitig
Zugriff auf alle neuen Elemente diesen Typs und können sie über die Bijektivität
der Abbilung auch eindeutig identifizieren. Die genaue Funktionsweise des
Abbildungstyps in ODL wird in [Höl05] ausführlich erläutert. Im übernächsten
Abschnitt zeigen wir den Einsatz von map anhand der Konstruktion der Schnittstellenobjekte.
2 Sie gelten wie bestehende Elemente, deren Assoziationen mit result not has entfernt
wurden, als gelöscht.
54

5.5.3 Konstruktion der Komponente
Da wir im interaktiven Ablauf nur ein Paar von Komponenten betrachten, gestaltet
sich das Generieren der Vereinigungskomponente denkbar einfach.
exists new_comp: new Component . (
context new_comp_name:String .
result has Name(new_comp, new_comp_name)
and result has
SubComponents(component_pair.one.SuperComponent, new_comp)
and ...
Über den Namen der neuen Komponente lassen wir den Nutzer durch den
entsprechenden context-Ausdruck entscheiden. Die neue Komponente wird anschließend
parallel zur ersten unifzierten Komponente in das Modell eingefügt.
5.5.4 Konstruktion der Schnittstellenelemente
Für die Konstruktion der Port-Elemente benutzen wir den map-Operator. Wir erzeugen
eine bijektive Abbildung, sodass zu jedem Tupel von unifizierten Schnittstellenelementen
genau ein neues Element entsteht.
exists new_port_map:map orig:port_map to copy:new Port . (
/* bijective mapping */
forall npm1:new_port_map . forall npm2:new_port_map . (
npm1.orig = npm2.orig equiv npm1.copy = npm2.copy
) and
/* build associations */
run makePorts(new_comp, new_port_map, new_tconst_map) and
...
Die Anbindung und Verknüpfung der neuen Elemente haben wir hier der
Übersichtlichkeit halber in ein Unterprogramm ausgelagert. Hier wird für jedes
neue Schnittstellenelement die Anbindung an die neue Komponente, die Namensgebung
und das Setzen der Port-Attribute durchgeführt. Im Gesamtablauf
müssen wir die Datentypdefinitionen bereits generiert haben, da wir sie, wie im
folgenden Programmausschnitt ersichtlich, korrekt verknüpfen müssen.
define makePorts(
new_comp:Component,
new_port_map:set(orig:(one:Port, two:Port),copy:Port),
new_tconst_map:set (
orig:(one:DataDef, two:DataDef),
copy:AbstractType
)
) as (
forall mk_prt:new_port_map . (
/* link port to new component */
result has Ports(new_comp, mk_prt.copy) and
/* generate name for the port */
55

esult has Name(mk_prt.copy,
concat(mk_prt.orig.one.Name, mk_prt.orig.two.Name)) and
/* set direction attribute */
exists mk_nd:new Direction . (
result has Direction(mk_prt.copy, mk_nd) and
result has
IsEntry(mk_nd, mk_prt.orig.one.Direction.IsEntry)
) and
/* set port type */
exists mk_prt_mt:new MIFType . (
result has DefinedType(mk_prt.copy, mk_prt_mt) and
exists ntm_elem_port:new_tconst_map . (
mk_prt.orig.one.DefinedType.Model =
ntm_elem_port.orig.one.TConst and
mk_prt.orig.two.DefinedType.Model =
ntm_elem_port.orig.two.TConst and
result has Model(mk_prt_mt, ntm_elem_port.copy)
)))) .
Hier sehen wir auch, dass bei vielen Modellelementen zusätzliche Elemente
erzeugt werden müssen, die meist nur als Kapselobjekte für primitive Datentypen
(Direction) oder zur Flexibilisierung der Modellierungsfähigkeiten (MIFType
für unvollständige Modelle) von AutoFocus 2 benutzt werden.
5.5.5 Konstruktion nicht-unifizierter Elemente
Da die Unifikationsrelationen hier partielle Funktionen sein dürfen, müssen wir
nicht-unifizierte Elemente der jeweiligen Modellelementklasse ebenfalls behandeln.
Für sie erstellen wir jeweils eine Kopie und verknüpfen sie entsprechend
mit den restlichen neuen Elementen. Hier zeigen wir die Umsetzung wieder am
Beispiel der Port-Elemente.
Wir konstruieren dazu zunächst die Menge der nicht-unifizierten Port-Elemente.
Sie besteht aus allen Elementen, die zu einer der beiden Komponenten
gehören und nicht in der portmap-Menge auftauchen.
exists copy_port_set: lfp FP7 set fp7_it:Port
with (
(
fp7_it.Component = component_pair.one or
fp7_it.Component = component_pair.two
) and
neg exists sm_fp7:port_map . (
sm_fp7.one = fp7_it or
sm_fp7.two = fp7_it
)
).
Für diese Menge erzeugen, wie eben, eine bijektive Abbildung auf neue Port-
Elemente und bauen für diese die Assoziationen mit einer Subroutine auf, die
56

im Wesentlichen makePorts() entspricht.
define copyPorts(
new_comp:Component,
new_copy_port_map:set(orig:Port,copy:Port)
) as (
forall mk_prt:new_copy_port_map . (
result has Ports(new_comp, mk_prt.copy) and
result has Name(mk_prt.copy, mk_prt.orig.Name) and
exists mk_nd:new Direction . (
result has Direction(mk_prt.copy, mk_nd) and
result has IsEntry(mk_nd, mk_prt.orig.Direction.IsEntry)
) and
exists mk_prt_mt:new MIFType . (
result has DefinedType(mk_prt.copy, mk_prt_mt) and
result has Model(mk_prt_mt, mk_prt.orig.DefinedType.Model)
))) .
5.6 Zusammenfassung
In diesem Kapitel haben wir einen möglichen interaktiven Ablauf der Spezifikationvereinigung
illustriert und in ODL umgesetzt. Unser Ziel war die Darstellung
der Fähigkeiten von ODL zur Definition interaktiver Modelltransformationen.
Für solch komplexe Transformationen gibt es meist mehrere alternative
Dialogführungen und Dialogformen, sodass eine genaue Betrachtung im jeweils
konkreten Fall notwendig ist.
Wir haben die Spezifikationsunifikation in zwei wesentliche Teile gegliedert.
Der analytische Teil lieferte interaktiv oder, wie im Falle der Datentypen und der
Termunifikation, automatisch berechnete Datenstrukturen für die Unifikationsrelationen.
Wir haben auf die Darstellung der Berechnung für nicht-unifzierte
Elemente, d.h. Elemente, die in die erzeugte Spezifikation nur einkopiert werden
müssen, verzichtet. Der Leser sei hierfür auf den Programmtext in Anhang A
verwiesen.
Diese vom Nutzer eingegebenen oder berechneten Daten bilden, so sie konsistent
sind, die Grundlage für den konstruktiven Teil. Er erzeugt die vereinigte
Komponente. Wir haben gesehen, dass beide Teile aufeinander abgestimmt sein
müssen, wobei die Forderung der Ein-Eindeutigkeit hier wesentliche Vereinfachungen
gebracht hat. Unsere Darstellungen begrenzten wir auf die Vorführung
der wichtigsten Teile. Das vollständige Programm findet sich in Anhang A.
57

Kapitel 6
Fazit und Ausblick
Abschließend unterziehen wir die in dieser Arbeit dargestellten Ergebnisse einer
kritischen Einordnung. Danach wenden wir uns dem Ausblick zu und geben
einige motivierende Ideen für weiterführende Betrachtungen und Arbeiten.
6.1 Einordnung dieser Arbeit
Diese Arbeit befasste sich mit komplexen Modellanalysen und -transformationen
in ODL und AutoFocus 2. Vorangegangene Arbeiten für ODL dienten bisher
dem Zweck die Transformationssprache mit zusätzlichen Fähigkeiten, wie
der interaktiven Schnittstelle ([Tra03]) und der Fixpunktmengenkonstruktion
([Höl05]), zu erweitern. Somit stellt die vorliegende Arbeit einen ersten Konzeptnachweis
dar, dass sich mit ODL auch umfangreichere, interaktive Transformationen
konstruieren lassen.
Das Thema Unifikation war für unsere Beispielmodelltransformation unser
roter Faden . Wir haben es an mehreren Stellen in verschiedenen Formen angetroffen.
Zunächst haben wir die prädikatenlogischen Unifikation auf die Datentypdefinitionen
von AutoFocus 2 übertragen, wobei wir hier als Äquivalenzmerkmal
die Namensgleichheit verwendet haben. Im nächsten Schritt erarbeiteten
wir uns ein Konzept für die Vereinigung von Spezifikationen, das zusätzlich
zur Datensicht noch die Struktur- und Verhaltenssicht von AutoFocus 2-Komponenten
miteinbezog. Als Teil des interaktiven Ablaufs haben wir schließlich
noch die Termunifikation behandelt.
Als Fazit dieser Arbeit lässt sich sagen, dass ODL ein mächtiges Werkzeug
für Definition von Modelltransformationen ist, allerdings mit einer hohen Einstiegsbarriere,
da komplexere Transformationen sehr schnell zu umfangreichen
ODL Ausdrücken führen. Im Hinblick auf Verständlichkeit haben regel- oder
musterbasierte Ansätze für Modelltransformation, wie sie im Umfeld der UML
und der MDA zur Zeit verbreitet sind, Vorteile. Diese werden allerdings durch
die Ausdrucksmächtigkeit bei komplexen Transformationen, insbesondere solche
mit rekursiven Strukturen und Fixpunktberechnungen, wettgemacht. Der Übergang
zu interaktiven Modelltransformationen ist dann hilfreich, wenn manche
Datenstrukturen, wie in Kapitel 4 sehr große Suchräume erzeugen.
Es hat sich gezeigt, dass die Fundierung von ODL als ein relationaler Kalkül
sehr wertvoll ist, da Konzepte, wie die Abhängigkeiten und Unifikationsrela-
58

tionen aus Kapitel 4, schnell und leicht umsetzbar sind. Die enge Beziehung
von ODL zur Prädikatenlogik erleichtert zudem den Nachweis der Korrektheit
von Transformationen und die Integration in Entwicklungsabläufe, da Vor- und
Nachbedingungen ebenfalls mit ODL formuliert und für Modelle überprüft werden
können.
Es zeigten sich im Verlauf dieser Diplomarbeit aber auch kleine Schwachstellen
von ODL, zu denen wir im nächsten Abschnitt Denkansätze und Vorschläge
machen.
6.2 Ansätze zur Weiterentwicklung der ODL
Im Verlauf dieser Arbeit zeigten sich einige Verbesserungsmöglichkeiten für die
Transformationssprache ODL. Insbesondere im Hinblick auf die nachfolgend
dargelegte Möglichkeit ODL auf andere Modellierungssprachen zu übertragen,
sollten noch weitergehende Konzepte integriert werden.
Folgende Ansätze und Erweiterungen scheinen sinnvoll:
• Die Nutzerschnittstelle wird bei komplexeren Strukturen schnell unübersichtlich
und wenig intuitiv. Insbesondere bei rekursiven Abfragen, wie wir
sie im Kapitel 3 gesehen haben, ist eine Verbesserung wünschenswert. Es
sind zeigen sich hier zwei Möglichkeiten. Zum einen könnte die Ausdehnung
des context-Quantors auf Fixpunktmengen erfolgen; zum anderen
könnte ein spezieller Sammlungstyp für context-Ausdrücke das Problem
unhandlicher, rekursiver und interaktiver Mengenkonstruktionen lösen.
Beide Möglichkeiten sind dabei eingehend auf die ODL Evaluationssemantik
hin zu untersuchen.
• Es kann in manchen Situationen nützlich sein, eine Transformation in mehrere
Einzelschritte zu unterteilen. Hierzu könnte ODL mit Konzepten für
Transaktionen, wie sie im Bereich von Datenbanken schon alltäglich sind,
erweitert werden, um die Zusammenfassung von einzelnen ODL Transformationen
zu größeren, in der Wirkung atomaren Transformationen zu
ermöglichen.
• Als langfristige Evolution ist die Untersuchung und Integration von Techniken
anderer Modelltransformationsansätze, insbesondere aus dem Bereich
der leichter zu erlernenden regel- und musterbasierten Ansätze, ein
Ziel, dass für ODL eine weitere Leistungssteigerung bringen kann.
Bevor diese Erweiterungen umgesetzt werden, sollte allerdings das Ziel sein,
die bisherigen Einzelarbeiten zu einer Kernversion der ODL zusammenführen
und zu optimieren. Parallel dazu scheint ein ODL Tutorialdokument sinnvoll,
um einerseits den Einstieg für Interessierte zu erleichtern und den aktuellen
Entwicklungsstand der ODL zu dokumentieren.
6.3 ODL für andere Modellierungssprachen und
-werkzeuge
Der Einsatz von ODL für Transformationen in anderen Modellierungssprache ist
sowohl durch die mengenorientierte Sichtweise prinzipiell möglich, wie auch tech-
59

nisch umsetzbar, da die bisherigen Arbeiten an der Implementierung eine klare
Schnittstelle zum verwendeten Metamodell nutzen. Die Hauptarbeit zur Anpassung
von ODL an weitere Entwicklungswerkzeuge betrifft diese Schnittstelle.
Wir werden die Portierung anhand der Unified Modeling Language (UML)
motivieren.
Wie wir gesehen haben, ist ODL als Transformationssprache für Modelle mit
diesen über das Metamodell verbunden. ODL ist im Falle von AutoFocus 2 über
eine generische Schnittstelle mit dem AutoFocus 2-Metamodell gekoppelt, d.h.
die durch das Metamodell vorgegebenen Assoziationen zwischen Modellelementen
werden zur Laufzeit ermittelt. Sie sind also nicht fester Bestandteil des ODL-
Moduls. Diese lose Bindung zwischen ODL und dem Metamodell ermöglicht eine
leichte Adaption der Transformationssprache für andere Modellierungssprachen.
In [HS05] wird neben der hier vorgestellten Modelltransformation für AutoFocus
2, auch ein Beispiel für eine Modelltransformation für UML-Modelle
gegebenen. Sowohl die AutoFocus 2-Modellierungssprache als auch die UML
(vgl. [OMG03a]) sind mit Hilfe eines Metamodells beschrieben. Beide Metamodelle
können dabei als Instanzen eines Meta-Metamodells angesehen werden, wie
es die MetaData Architektur in der MetaObject Facility Specification [OMG04]
definiert. Diese Ähnlichkeit der Metamodelle ermöglicht es, dass ODL auch als
Transformationssprache in UML-Werkzeuge integriert werden kann, wenn die
entsprechende ODL-Metamodell-Schnittstelle angepasst wird.
Die Integration von ODL in UML-Werkzeuge könnte dabei ohne große Zusatzarbeiten
durchgeführt werden, weil in einem Systementwicklungsprojekt am
Lehrstuhl eine einheitliche Schnittstelle zu mehreren UML-Werkzeugen (Rational
Rose Enterprise 2003, argoUML 0.16.1, . . . ) geschaffen wurde (vgl. [Dun05]).
Dennis Dungs hat hierbei für seine Schnittstelle eine Implementierung des
UML Metamodells geschaffen. Diese ist im Gegensatz zum AutoFocus 2-Metamodell
allerdings nicht zur Laufzeit als Instanz des Meta-Metamodells vorhanden.
Die Kopplung von ODL über diese generische Schnittstelle sollte aber
möglich sein und daher einer genaueren Betrachtung, möglicherweise in Form
eines Systementwicklungsprojekts, unterzogen werden.
Nach einer ersten Analyse zeigten sich folgende Arbeitspakete:
• Spezifikation und Implementierung der Schnittstelle zwischen ODL und
dem UML Metamodell, wobei die analytischen Fähigkeiten von Java (Reflection-API)
Anwendung finden könnten um die fehlende Beschreibung
der Meta-Metamodell-Instanz zu ersetzen. Alternativ kann das Metamodell
möglicherweise auch mit ArgoUML reverse-engineered werden, um
dann mit dem in AutoFocus 2 verwendeten MMGen-Verfahren eine Laufzeitinstanz
des Metamodells zu erhalten, was die Kopplung von ODL erheblich
vereinfachen würde.
• Nutzung der UML Schnittstelle zur Integration des ODL Editors in die
UML Werkzeuge. Besonderes Augenmerk richtet sich hier auf die Integration
in den GUI des jeweiligen UML-Werkzeugs.
• Nachweis der Funktionsfähigkeit durch Umsetzung der in [HS05] beschriebenen
Modelltransformation für UML Modelle (MoveUpFeature-Transformation).
60

6.4 ODL-unterstützter Entwicklungsprozess
Zum Abschluß betrachten wir noch kurz die Ansätze und Ziele der Parallelarbeit
von David Pasch (vgl. [Pas05]). Fokus seiner Arbeit ist der Einsatz von ODL in
den verschiedenen Phasen des Softwareentwicklungsprozesses.
Wie wir gesehen haben, ist die konkrete Festlegung des Ablaufs der Spezifikationsvereinigung
stark von den verwendeten Modellierungsmöglichkeiten
ab, insbesondere im Bereich der Datentypen. Daher können komplexe Modelltransformationen
erst in Zusammenhang mit weiteren Betrachtungen des Gesamtentwicklungsprozesses
die volle Wirkung erlangen, indem sie für die jeweils
betrachtete Software und die aktuelle Entwicklungsphase, als auch für die Arbeitsweise
einzelner Entwickler oder -teams massgeschneidert werden.
David Pasch hat sich in seiner Arbeit mit dem Problem der Prozessunterstützung
befasst und AutoFocus 2 um einen entsprechenden Mechanismus
erweitert. Dieser erlaubt für AutoFocus 2-Projekte die Festlegung von Entwicklungsphasen,
wobei jede Phase durch entsprechende ODL Eintrittsbedingungen
charakterisiert werden kann. Desweiteren ist es möglich für jede Phase
ODL-Transformationen vorzudefinieren, die dem Entwickler für typische Bearbeitungsschritte
des Modells in den entsprechenden Phasen zur Verfügung
stehen sollen.
Die Arbeit von David Pasch schlägt für ODL also die Brücke zur Evaluierung
im Kontext des Software Engineerings und von Entwicklungsprozessen.
Die vorliegende Arbeit zeigte eine erste sehr komplexe Modelltransformation
und schaffte somit eine Grundlage für vertiefte Betrachtungen des Themas Modelltransformation.
Die Relevanz und Portierbarkeit von ODL für andere Modellierungssprachen
haben wir oben motiviert, sodass insgesamt eine theoretische,
wie technische Basis für weitere Betrachtungen des Themas Modelltransformation
geschaffen ist.
61

Anhang A
ODL Programm der
Spezifikationsvereinigung
A.1 Anmerkungen zum Programm
A.1.1
Erweiterte Abhängigkeiten
In diesem Anhang stellen wir die ODL-Umsetzung der Spezifikationsunifikation
vor. Wir verwenden hierzu ein erweitertes Abhängigkeitsnetz, wie in Abbildung
A.1 gezeigt. Neben den aus Kapitel 4 bekannten Modellelementklassen und
Abhängigkeiten (letztere wieder als durchgezogene Pfeile dargestellt), finden sich
nun auch die Modellelemente für lokale Variablen (LocVariable) und deren Repräsentation
in Termen (LocVariableConst) , Funktionsapplikation (Appl), Selektoren,
Terme und konstante Ausdrücke (Const), Transitionsverbindungspunkte
(InterfacePoint), sowie Aktionen (Action) und Vorbedingungen (Condition).
Desweiteren zeigt die Abbildung die Klassenhierachie des Metamodells für Terme
und konstante Ausdrücke.
Das bisher noch nicht beachtete Modellierungselement LocVariable für lokale
Variablen unterscheidet sich nicht von den Elementen für Port. Beide haben
als Attribute einen Namen und einen definierten Typ und sind mit einer n:1-
Beziehung an Component geknüpft. Die Assoziation zwischen LocVariable und
LocVariableConst ist eine 1:1-Beziehung, d.h. mit jeder lokalen Variablen ist ein
eindeutiges Repräsentationsobjekt für die ihre Verwendung als Term vorhanden.
Die gekennzeichnete Vererbungshierarchie von Term und Const bedarf einer
besonderen Behandlung. Alle Abhängigkeiten, die auf Oberklassen verweisen,
müssen die Unterklassen mitberücksichtigen, d.h. die Abhängigkeit ist erfüllt,
wenn es in einer der Unifikationrelationen der Unterklassenelemente ein entsprechend
vereinigtes Elementtupel gibt. Der in Kapitel 4 eingeführte Formalismus
zur Beschreibung einer Unifikationsrelation muss für Klassenhierarchien folgendermaßen
angepasst werden:
62

Component
DataDefinition
DefinedType.Model
Port
State
LocVariable
Port.Model
LocVariable.Model
(+)
InterfacePoint
(*)
TransitionSegment
Term
Pattern.Model /
Expression.Model
Input / Output
Condition
Action
Const
Head
Expression
Constructor
Appl
Args
0..*
Selector
LocVariableConst
(*) SourcePoint und DestinationPoint
(+) Selector.DefinedType = DataDef.TConst
Abbildung A.1: Abhängigkeiten für erweiterte Unifikation
∀ur ∈ UnifRel : (
∃usc1 ∈ UnifRelSubClass1 :
ur.one.AssociatedEntity = usc1.one ∧ ur.two.AssociatedEntity = usc1.two
∨
∃usc2 ∈ UnifRelSubClass1 :
ur.one.AssociatedEntity = usc2.one ∧ ur.two.AssociatedEntity = usc2.two
∨
. . .)
Die Relation zwischen Selector und DataDef besteht nicht in einem einzelnen
Attribut, sondern hier muss die Verbindung über das entsprechende TConst-Element
hergestellt werden.
Die Abhängigkeit der Elemente TransitionSegment und InterfacePoint ist
gestrichelt dargestellt, da hier ebenfalls eine Besonderheit gibt. Für alle unifizierten
Transitionen müssen sowohl die Quellpunkte als auch die Zielpunkte
unifiziert sein. Die Abhängigkeit stellt somit genau genommen zwei Abhängigkeiten
dar, die beide erfüllt sein müssen.
A.1.2
Problembeschränkungen
Für die bisherigen Ausführungen haben wir eine Reihe von Einschränkungen
festgelegt (vgl. Abschnitt 2.5. Unsere Vereinfachungen reduzierten dabei die
Anzahl der Unifikationsrelationen.
63

Das im nächsten Abschnitt abgedruckte Programm wurde, wie oben gesagt,
um einige Relationen erweitert. Für die Nutzerinteraktion kam nur der Dialog
für die lokalen Variablen hinzu. Die anderen Relationen werden berechnet, wie
bisher die Datentypen und Konstruktoren.
Das Programm verlangt von den zu unifizierenden Modulen noch die Erfüllung
der folgenden Bechränkungen:
• Polymorphe Datentypen sind weiterhin ausgeschlossen.
• Der Typ lokaler Variablen muss identisch sein; wir beziehen sie hier nicht
in die Unifikation der Datentypdefinitionen ein, obwohl dies prinzipiell
möglich ist.
• Die Unifikation von Automatenzuständen geschieht nur auf der obersten
Hierarchieebene; Subautomaten werden nur kopiert.
• Höchstens einer von zwei unifzierten Zuständen darf Unterzustände besitzen.
• Für die Ausdrücke von Ein-/Ausgaben, Vorbedingungen und Aktionen
verlangen wird die Strukturäquivalenz der Terme für die Vereinigung.
A.2 ODL Programm
define setUnifiedMIFTerm(
orig_one:MIFTerm, orig_two:MIFTerm, copy: MIFTerm,
new_constructor_map:set(
orig:(one:Constructor, two:Constructor), copy:Constructor),
new_appl_map:set(orig:(one:Appl, two:Appl), copy:Appl),
new_lvcn_map:set(
orig:(one:LocVariableConst, two:LocVariableConst),
copy:LocVariableConst)
) as (
exists ncon:new_constructor_map . (
orig_one.Model = ncon.orig.one and
orig_two.Model = ncon.orig.two and
result has Model(copy, ncon.copy)
) or
exists napp:new_appl_map . (
orig_one.Model = napp.orig.one and
orig_two.Model = napp.orig.two and
result has Model(copy, napp.copy)
) or
exists nlvar:new_lvcn_map . (
orig_one.Model = nlvar.orig.one and
orig_two.Model = nlvar.orig.two and
result has Model(copy, nlvar.copy)
) or
( orig_one.Model = orig_two.Model and
result has Model(copy, orig_one.Model)
)).
64

define setCopiedMIFTerm(
orig:MIFTerm, copy: MIFTerm,
new_constructor_map:set(
orig:(one:Constructor, two:Constructor), copy:Constructor),
new_copy_constructor_map:set(
orig:Constructor, copy:Constructor),
new_appl_map:set(orig:(one:Appl, two:Appl), copy:Appl),
new_copy_appl_map:set(orig:Appl, copy:Appl),
new_lvcn_map:set(
orig:(one:LocVariableConst, two:LocVariableConst),
copy:LocVariableConst),
new_copy_lvcn_map:set(
orig:LocVariableConst, copy:LocVariableConst)
) as (
exists ncon:new_constructor_map . (
( orig.Model = ncon.orig.one or orig.Model = ncon.orig.two
) and result has Model(copy, ncon.copy)
) or
exists nccon:new_copy_constructor_map . (
orig.Model = nccon.orig and result has Model(copy, nccon.copy)
) or
exists napp:new_appl_map . (
( orig.Model = napp.orig.one or orig.Model = napp.orig.two
) and result has Model(copy, napp.copy)
) or
exists ncapp:new_copy_appl_map . (
orig.Model = ncapp.orig and result has Model(copy, ncapp.copy)
) or
exists nlvr:new_lvcn_map . (
( orig.Model = nlvr.orig.one or orig.Model = nlvr.orig.two
) and result has Model(copy, nlvr.copy)
) or
exists nclvr:new_copy_lvcn_map . (
orig.Model=nclvr.orig and result has Model(copy,nclvr.copy)
) or
result has Model(copy, orig.Model)
).
define testSelectorType (
sel:Selector, t:Type
) := (
exists ta:TAppl . (
sel.Type = ta and
exists ta_arg:(ta.TArgs) . (
indexOf(ta_arg, ta, "TArgs") = 1 and
ta_arg = t
))).
define selectorTypeEqual (
65

sel1:Selector, sel2:Selector
) := (
sel1 = sel2 or
/* search function applications */
exists ta:{ta_test:(one:TAppl, two:TAppl) |
ta_test.one = sel1.Type and ta_test.two = sel2.Type
}
exists ta_arg1:(ta.one.TArgs) . (
indexOf(ta_arg1, ta.one, "TArgs") = 1 and
exists ta_arg2:(ta.two.TArgs) . (
indexOf(ta_arg2, ta.two, "TArgs") = 1 and
/* compare result types */
ta_arg1 = ta_arg2
))).
define testApplForConstructor(
appl:(one:Appl, two:Appl),
con:(one:Constructor, two:Constructor)
) := (
(appl.one.Head = con.one and
appl.two.Head = con.two
) or
(is Args(appl.one, con.one) and
is Args(appl.two, con.two) and
indexOf(con.one, appl.one, "Args") =
indexOf(con.two, appl.two, "Args")
)).
define Consistent_Component_Port(
component_pair:(one:Component, two:Component),
pm_elem:(one:Port, two:Port)
) := (
pm_elem.one.Direction.IsEntry =
pm_elem.two.Direction.IsEntry and
component_pair.one = pm_elem.one.Component and
component_pair.two = pm_elem.two.Component
).
define Consistent_Component_LocVar(
component_pair:(one:Component, two:Component),
lvm_elem:(one:LocVariable, two:LocVariable)
) := (
/* interne Abhängigkeit: Typgleichheit */
lvm_elem.one.DefinedType.Model =
lvm_elem.two.DefinedType.Model and
/* externe Abhängigkeit zu Component */
component_pair.one = lvm_elem.one.Component and
component_pair.two = lvm_elem.two.Component
).
66

define Consistent_State_Transition(
state_map:set (one:State, two:State),
tm_one:TransitionSegment,
tm_two:TransitionSegment
) := (
exists sm_elem_source:state_map . (
tm_one.SourcePoint.State = sm_elem_source.one and
tm_two.SourcePoint.State = sm_elem_source.two
) and
exists sm_elem_destin:state_map . (
tm_one.DestinationPoint.State = sm_elem_destin.one and
tm_two.DestinationPoint.State = sm_elem_destin.two
)).
define Consistent_Port_TypeDef(
port_map:set(one:Port, two:Port),
tdm_elem:(one:DataDef, two:DataDef)
) := (
exists pm_elem:port_map . (
tdm_elem.one.TConst = pm_elem.one.DefinedType.Model and
tdm_elem.two.TConst = pm_elem.two.DefinedType.Model
)).
define Consistent_Const_TypeDef(
con_map:set(one:Constructor, two:Constructor),
tdm_elem:(one:DataDef, two:DataDef)
) := (
exists cm_elem:con_map . (
tdm_elem.one = cm_elem.one.DataDef and
tdm_elem.two = cm_elem.two.DataDef
)).
/* Component */
context component_pair:(one:Component, two:Component) .
/* Port */
exists port_map_possible:
lfp FPPRTMP set fpprtmp_it:(
one:(component_pair.one.Ports),
two:(component_pair.two.Ports)
) with (
call Consistent_Component_Port(component_pair, fpprtmp_it)
) .
context port_map:{pm_test:set port_map_possible |
forall pm1:pm_test . forall pm2:pm_test . (
(pm1.one = pm2.one) equiv (pm1.two = pm2.two)
)
}.
67

* LocVariable */
exists lvar_map_possible:
lfp FPLVRMP set fplvrmp_it:(
one:(component_pair.one.LocVariables),
two:(component_pair.two.LocVariables)
) with (
call Consistent_Component_LocVar(component_pair, fplvrmp_it)
).
context lvar_map:{lvm_test:set lvar_map_possible |
forall lvm1:lvm_test . forall lvm2:lvm_test . (
(lvm1.one = lvm2.one) equiv (lvm1.two = lvm2.two)
)
}.
/* LocVariableConst */
exists lvarconst_map:
lfp FPLVCM set fplvcm_it:(
one:LocVariableConst,
two:LocVariableConst
) with (
exists lvm_fplvcm:lvar_map . (
fplvcm_it.one.LocVariable = lvm_fplvcm.one and
fplvcm_it.two.LocVariable = lvm_fplvcm.two
)
).
/* State */
context state_map:{sm_test:set (
one:(component_pair.one.Automaton.State.SubStates),
two:(component_pair.two.Automaton.State.SubStates)) |
/* at least one state must be unified, */
/* otherwise the automaton would not be connected */
exists sm0:sm_test . true and
forall sm1:sm_test . (
forall sm2:sm_test . (
(sm1.one = sm2.one) equiv (sm1.two = sm2.two)
) and (
/*at most one state may have a substates */
neg exists sm_one_sub:(sm1.one.SubStates) . true or
neg exists sm_two_sub:(sm1.two.SubStates) . true
))
}.
/* TransitionSegment */
exists transition_map_possible:
lfp FPTSGMP set fptsgmp_it:(
one:(component_pair.one.Automaton.State.TransitionSegments),
two:(component_pair.two.Automaton.State.TransitionSegments)
) with (
call Consistent_State_Transition(state_map,
68

fptsgmp_it.one, fptsgmp_it.two)
) .
context transition_map:{tm_test:set transition_map_possible |
forall tm1:tm_test . forall tm2:tm_test . (
(tm1.one = tm2.one) equiv (tm1.two = tm2.two)
)
}.
/* Input */
exists input_map: lfp FPINPM set fpinpm_it:(one:Input, two:Input)
with (
exists tm_fpinpm:transition_map . (
tm_fpinpm.one = fpinpm_it.one.TransitionSegment and
tm_fpinpm.two = fpinpm_it.two.TransitionSegment
) and
exists pm_fpinpm:port_map . (
fpinpm_it.one.Port.Model = pm_fpinpm.one and
fpinpm_it.two.Port.Model = pm_fpinpm.two
)
).
/* Output */
exists output_map: lfp FPO set fpoutm_it:(one:Output, two:Output)
with (
exists tm_fpoutm:transition_map . (
tm_fpoutm.one = fpoutm_it.one.TransitionSegment and
tm_fpoutm.two = fpoutm_it.two.TransitionSegment
) and
exists pm_fpoutm:port_map . (
fpoutm_it.one.Port.Model = pm_fpoutm.one and
fpoutm_it.two.Port.Model = pm_fpoutm.two
)).
/* Condition */
exists condition_map: lfp FPCNDM set
fpcndm_it:(one:Condition, two:Condition)
with (
exists tm_fpcndm:transition_map . (
tm_fpcndm.one = fpcndm_it.one.TransitionSegment and
tm_fpcndm.two = fpcndm_it.two.TransitionSegment
)).
/* Action */
exists action_map: lfp FPACTM set
fpactm_it:(one:Action, two:Action)
with (
exists tm_fpactm:transition_map . (
tm_fpactm.one = fpactm_it.one.TransitionSegment and
tm_fpactm.two = fpactm_it.two.TransitionSegment
) and
69

exists lvm_fpactm:lvar_map . (
fpactm_it.one.LocVariable.Model = lvm_fpactm.one and
fpactm_it.two.LocVariable.Model = lvm_fpactm.two
)).
/* InterfacePoint */
exists interfacepoint_map: lfp FPIFPM set
fpifpm_it:(one:InterfacePoint, two:InterfacePoint)
with (
exists tm_fpifpm:transition_map . (
(tm_fpifpm.one.SourcePoint = fpifpm_it.one and
tm_fpifpm.two.SourcePoint = fpifpm_it.two
) or
(tm_fpifpm.one.DestinationPoint = fpifpm_it.one and
tm_fpifpm.two.DestinationPoint = fpifpm_it.two
))).
/* Appl */
exists appl_map: lfp FPAPPM set fpappm_it:(one:Appl, two:Appl)
with (
exists im_fpappm:input_map . (
im_fpappm.one.Pattern.Model = fpappm_it.one and
im_fpappm.two.Pattern.Model = fpappm_it.two
) or
exists om_fpappm:output_map . (
om_fpappm.one.Expression.Model = fpappm_it.one and
om_fpappm.two.Expression.Model = fpappm_it.two
) or
exists cndm_fpappm:condition_map . (
cndm_fpappm.one.Expression.Model = fpappm_it.one and
cndm_fpappm.two.Expression.Model = fpappm_it.two
) or
exists actm_fpappm:action_map . (
actm_fpappm.one.Value.Model = fpappm_it.one and
actm_fpappm.two.Value.Model = fpappm_it.two
) or
exists fpappm_elem:FPAPPM . (
is Args(fpappm_elem.one, fpappm_it.one) and
is Args(fpappm_elem.two, fpappm_it.two) and
indexOf(fpappm_it.one, fpappm_elem.one, "Args") =
indexOf(fpappm_it.two, fpappm_elem.two, "Args")
)).
/* Constructor */
exists constructor_map: lfp FPCONM set
fpconm_it:(one:Constructor, two:Constructor)
with (
exists im_fpconm:input_map . (
fpconm_it.one = im_fpconm.one.Pattern.Model and
fpconm_it.two = im_fpconm.two.Pattern.Model
70

) or
exists om_fpconm:output_map . (
fpconm_it.one = om_fpconm.one.Expression.Model and
fpconm_it.two = om_fpconm.two.Expression.Model
) or
exists am_fpconm:appl_map .
call testApplForConstructor(am_fpconm, fpconm_it)
).
/* DataDef */
exists typedef_map:lfp FPTDF set
fp_tdef_it:(one:DataDef, two:DataDef)
with (
call Consistent_Port_TypeDef(port_map, fp_tdef_it) or
call Consistent_Const_TypeDef(constructor_map, fp_tdef_it)
).
/* Selector */
exists selector_map: lfp FPSELM set
fpselm_it:(one:Selector, two:Selector)
with (
exists cm_fpselm:constructor_map . (
fpselm_it.one.Constructor = cm_fpselm.one and
fpselm_it.two.Constructor = cm_fpselm.two and
indexOf(fpselm_it.one, cm_fpselm.one, "Selectors") =
indexOf(fpselm_it.two, cm_fpselm.two, "Selectors")
)).
/* START OF consistency tests on generated mappings */
/* checks consistency of appl unification relation against
itself, constructor, locvariable unification relation or
subexpression equality.
*/
define checkApplHeadArgsConsistency(
a_map:set (one:Appl, two:Appl),
c_map:set (one:Constructor, two:Constructor),
l_map:set (one:LocVariableConst, two:LocVariableConst)
) := (
forall ae:a_map . (
/* check function application */
(
/* applied function is equal */
ae.one.Head = ae.two.Head
or
/* constructor */
exists ce1:c_map . (
ae.one.Head = ce1.one and ae.two.Head = ce1.two
)
) and
71

forall ap1:(ae.one.Args) . exists ap2:(ae.two.Args) . (
indexOf(ap1,ae.one,"Args") = indexOf(ap2,ae.two,"Args") and
(
/* unified Constructor */
exists ce2:c_map . (ap1 = ce2.one and ap2 = ce2.two) or
/* unified Appl */
exists ae2:a_map . (ap1 = ae2.one and ap2 = ae2.two) or
/* unified LVar */
exists le2:l_map . (ap1 = le2.one and ap2 = le2.two) or
/* some other equal Const */
ap1 = ap2
)))).
/* checks consistency of input unification relation against
appl, constructor, locvariable unification relation.
*/
define checkInputPatternConsistency(
i_map:set (one:Input, two:Input),
a_map:set (one:Appl, two:Appl),
c_map:set (one:Constructor, two:Constructor),
l_map:set (one:LocVariableConst, two:LocVariableConst)
) := (
forall ie:i_map . (
exists ce:c_map . (
ie.one.Pattern.Model=ce.one and ie.two.Pattern.Model=ce.two
) or
exists ae:a_map . (
ie.one.Pattern.Model=ae.one and ie.two.Pattern.Model=ae.two
) or
ie.one.Pattern.Model=ie.two.Pattern.Model
)).
/* checks consistency of output unification relation against
appl, constructor, locvariable unification relation.
*/
define checkOutputExpressionConsistency(
o_map:set (one:Output, two:Output),
a_map:set (one:Appl, two:Appl),
c_map:set (one:Constructor, two:Constructor),
l_map:set (one:LocVariableConst, two:LocVariableConst)
) := (
forall oe:o_map . (
exists ce:c_map . (
oe.one.Expression.Model = ce.one and
oe.two.Expression.Model = ce.two
) or
exists ae:a_map . (
oe.one.Expression.Model = ae.one and
oe.two.Expression.Model = ae.two
) or
72

oe.one.Expression.Model = oe.two.Expression.Model
)).
(
/* check appl for consistency */
call checkApplHeadArgsConsistency(appl_map,
constructor_map, lvarconst_map) and
/* check inputs for consistency */
call checkInputPatternConsistency(input_map, appl_map,
constructor_map, lvarconst_map) and
/* check outputs for consistency */
call checkOutputExpressionConsistency(output_map, appl_map,
constructor_map, lvarconst_map) and
/* uniqueness test for datadef */
forall tdm1tst:typedef_map . forall tdm2tst:typedef_map . (
tdm1tst.one = tdm2tst.one equiv tdm1tst.two = tdm2tst.two
) and
/* uniqueness test for interfacepoint */
forall ifpm1tst:interfacepoint_map .
forall ifpm2tst:interfacepoint_map . (
ifpm1tst.one = ifpm2tst.one equiv ifpm1tst.two = ifpm2tst.two
) and
/* uniqueness test for constructor */
forall cm1tst:constructor_map .
forall cm2tst:constructor_map . (
cm1tst.one = cm2tst.one equiv cm1tst.two = cm2tst.two
) and
/* Port Copy */
exists copy_port_set: lfp FP_CPS set fpcps_it:Port
with (
neg exists pm_fpcps:port_map . (
fpcps_it = pm_fpcps.one or fpcps_it = pm_fpcps.two
) and (
fpcps_it.Component = component_pair.one or
fpcps_it.Component = component_pair.two
)).
/* LocVariable Copy */
exists copy_lvar_set: lfp FP_CLVRS set fpclvrs_it:LocVariable
with (
neg exists lvrm_fpclvrs:lvar_map . (
fpclvrs_it = lvrm_fpclvrs.one or fpclvrs_it = lvrm_fpclvrs.two
) and (
fpclvrs_it.Component = component_pair.one or
73

fpclvrs_it.Component = component_pair.two
)).
/* LocVariableConst Copy */
exists copy_lvarconst_set: lfp FPCLVCS set
fpclvcs_it: LocVariableConst
with (
neg exists lvcm_fpclvcs:lvarconst_map . (
fpclvcs_it = lvcm_fpclvcs.one or
fpclvcs_it = lvcm_fpclvcs.two
) and (
fpclvcs_it.LocVariable.Component = component_pair.one or
fpclvcs_it.LocVariable.Component = component_pair.two
)).
/* State Copy */
exists copy_state_set: lfp FP_CSS set fpcss_it:State
with (
neg exists sm_fpcss:state_map . (
fpcss_it = sm_fpcss.one or fpcss_it = sm_fpcss.two
) and (
(fpcss_it.SuperState = component_pair.one.Automaton.State or
fpcss_it.SuperState = component_pair.two.Automaton.State
) or
exists css_fpcss:FP_CSS . (
fpcss_it.SuperState = css_fpcss
) or
exists sm2_fpcss:state_map . (
fpcss_it.SuperState = sm2_fpcss.one or
fpcss_it.SuperState = sm2_fpcss.two
))).
/* TransitionSegment Copy */
exists copy_transition_set: lfp FP_CTS set
fpcts_it:TransitionSegment
with (
neg exists tm_fpcts:transition_map . (
fpcts_it = tm_fpcts.one or fpcts_it = tm_fpcts.two
) and (
(fpcts_it.State = component_pair.one.Automaton.State or
fpcts_it.State = component_pair.two.Automaton.State
) or
exists css_fpcts:copy_state_set . (
fpcts_it.State = css_fpcts
) or
exists sm_fpcts:state_map . (
fpcts_it.State = sm_fpcts.one or
fpcts_it.State = sm_fpcts.two
))).
74

* Input Copy */
exists copy_input_set: lfp FP_CIS set fpcis_it:Input
with (
neg exists im_fpcis:input_map . (
fpcis_it = im_fpcis.one or
fpcis_it = im_fpcis.two
) and (
exists cts_fpcis:copy_transition_set . (
fpcis_it.TransitionSegment = cts_fpcis
) or
exists tm_fpcis:transition_map . (
fpcis_it.TransitionSegment = tm_fpcis.one or
fpcis_it.TransitionSegment = tm_fpcis.two
))).
/* Output Copy */
exists copy_output_set: lfp FP_COS set fpcos_it:Output
with (
neg exists om_fpcos:output_map . (
om_fpcos.one = fpcos_it or
om_fpcos.two = fpcos_it
) and (
exists cts_fpcos:copy_transition_set . (
fpcos_it.TransitionSegment = cts_fpcos
) or
exists tm_fpcos:transition_map . (
fpcos_it.TransitionSegment = tm_fpcos.one or
fpcos_it.TransitionSegment = tm_fpcos.two
))).
/* Condtion Copy */
exists copy_condition_set: lfp FP_CCNDS set fpccnds_it:Condition
with (
neg exists cndm_fpccnds:condition_map . (
fpccnds_it = cndm_fpccnds.one or
fpccnds_it = cndm_fpccnds.two
) and
(
exists cts_fpccnds:copy_transition_set . (
fpccnds_it.TransitionSegment = cts_fpccnds
) or
exists tm_fpccnds:transition_map . (
fpccnds_it.TransitionSegment = tm_fpccnds.one or
fpccnds_it.TransitionSegment = tm_fpccnds.two
)
)
) .
/* Action Copy */
75

exists copy_action_set: lfp FP_CACTS set fpcacts_it:Action
with (
neg exists actm_fpcacts:action_map . (
fpcacts_it = actm_fpcacts.one or
fpcacts_it = actm_fpcacts.two
) and
(
exists cts_fpcacts:copy_transition_set . (
fpcacts_it.TransitionSegment = cts_fpcacts
) or
exists tm_fpcacts:transition_map . (
fpcacts_it.TransitionSegment = tm_fpcacts.one or
fpcacts_it.TransitionSegment = tm_fpcacts.two
)
)
) .
/* InterfacePoint Copy */
exists copy_interfacepoint_set: lfp FP_CIFPS set
fpcifps_it:InterfacePoint
with (
neg exists ifpm_fpcifps:interfacepoint_map . (
fpcifps_it = ifpm_fpcifps.one or
fpcifps_it = ifpm_fpcifps.two
) and (
(fpcifps_it.State = component_pair.one.Automaton.State or
fpcifps_it.State = component_pair.two.Automaton.State
) or
exists css_fpcifps:copy_state_set . (
fpcifps_it.State = css_fpcifps
) or
exists sm_fpcifps:state_map . (
fpcifps_it.State = sm_fpcifps.one or
fpcifps_it.State = sm_fpcifps.two
))).
/* Appl Copy */
exists copy_appl_set: lfp FPCAPPS set fpcapps_it:Appl
with (
neg exists appm_fpcapps:appl_map . (
fpcapps_it = appm_fpcapps.one or
fpcapps_it = appm_fpcapps.two
) and (
exists cis_fpcapps:copy_input_set . (
fpcapps_it = cis_fpcapps.Pattern.Model
) or
exists cos_fpcapps:copy_output_set . (
fpcapps_it = cos_fpcapps.Expression.Model
) or
exists ccnds_fpcapps:copy_condition_set . (
76

fpcapps_it = ccnds_fpcapps.Expression.Model
) or
exists cacts_fpcapps:copy_action_set . (
fpcapps_it = cacts_fpcapps.Value.Model
) or
exists im_fpcapps:input_map . (
im_fpcapps.one.Pattern.Model = fpcapps_it or
im_fpcapps.two.Pattern.Model = fpcapps_it
) or
exists om_fpcapps:output_map . (
om_fpcapps.one.Expression.Model = fpcapps_it or
om_fpcapps.two.Expression.Model = fpcapps_it
) or
exists cndm_fpcapps:condition_map . (
cndm_fpcapps.one.Expression.Model = fpcapps_it or
cndm_fpcapps.two.Expression.Model = fpcapps_it
) or
exists actm_fpcapps:action_map . (
actm_fpcapps.one.Value.Model = fpcapps_it or
actm_fpcapps.two.Value.Model = fpcapps_it
) or
exists fpcapps_elem:FPCAPPS . (
is Args(fpcapps_elem, fpcapps_it)
))).
/* Constructor Copy */
exists copy_constructor_set: lfp FPCCS set fpccs_it:Constructor
with (
neg exists cm_fpccs:constructor_map . (
cm_fpccs.one = fpccs_it or cm_fpccs.two = fpccs_it
) and
exists tm_fpccs:typedef_map . (
fpccs_it.DataDef = tm_fpccs.one or
fpccs_it.DataDef = tm_fpccs.two
)).
/* Selector Copy */
exists copy_selector_set: lfp FPCSS set fpcss_it:Selector
with (
exists ccm_fpcss:copy_constructor_set . (
fpcss_it.Constructor = ccm_fpcss
)
) .
/* new component name */
context new_comp_name:String .
/* START of building */
exists new_dtd_module: new DTDModule .
77

exists new_automaton:new Automaton .
exists new_root_state: new State .
exists new_comp: new Component . (
result has Name(new_comp, new_comp_name) and
result has SubComponents(component_pair.one.SuperComponent,
new_comp) and
result has Name(new_dtd_module,
concat("created_dtd_module_", new_comp_name)) and
result has Name(new_automaton, "Automaton") and
result has Name(new_root_state, "rootState") and
result has DTDModules(component_pair.one.SuperComponent.DTD,
new_dtd_module) and
result has Automaton(new_comp, new_automaton) and
result has State(new_automaton, new_root_state) and
/* build datadefs */
exists new_typedef_map:map orig:typedef_map
to copy:new DataDef . (
forall ntm1:new_typedef_map . forall ntm2:new_typedef_map . (
ntm1.orig = ntm2.orig equiv ntm1.copy = ntm2.copy
) and
forall mk_tdef:new_typedef_map . (
result has TypeDefs(new_dtd_module, mk_tdef.copy) and
result has Name(mk_tdef.copy,
concat(mk_tdef.orig.one.Name, mk_tdef.orig.two.Name))
) and
/* build corresponding abstract_types */
exists new_tconst_map:map orig:typedef_map
to copy:new AbstractType . (
forall ntm3:new_tconst_map . forall ntm4:new_tconst_map . (
ntm3.orig = ntm4.orig equiv ntm3.copy = ntm4.copy
) and
forall mk_tcon:new_tconst_map . (
result has TConsts(new_dtd_module, mk_tcon.copy) and
result has Name(mk_tcon.copy,
concat(mk_tcon.orig.one.Name,mk_tcon.orig.two.Name)) and
exists ntm_elem_tcon:new_typedef_map . (
mk_tcon.orig = ntm_elem_tcon.orig and
result has TConst(ntm_elem_tcon.copy, mk_tcon.copy)
)) and
/* build ports */
exists new_port_map:map orig:port_map to copy:new Port . (
forall npm1:new_port_map . forall npm2:new_port_map . (
npm1.orig = npm2.orig equiv npm1.copy = npm2.copy
) and
forall mk_prt:new_port_map . (
result has Ports(new_comp, mk_prt.copy) and
result has Name(mk_prt.copy,
78

concat(mk_prt.orig.one.Name, mk_prt.orig.two.Name)) and
exists mk_prt_nd:new Direction . (
result has Direction(mk_prt.copy, mk_prt_nd) and
result has IsEntry(mk_prt_nd,
mk_prt.orig.one.Direction.IsEntry)
) and
exists mk_prt_mt:new MIFType . (
result has DefinedType(mk_prt.copy, mk_prt_mt) and
exists ntm_elem_port:new_tconst_map . (
mk_prt.orig.one.DefinedType.Model =
ntm_elem_port.orig.one.TConst and
mk_prt.orig.two.DefinedType.Model =
ntm_elem_port.orig.two.TConst and
result has Model(mk_prt_mt, ntm_elem_port.copy)
))) and
/* copy ports */
exists new_copy_port_map:map orig:copy_port_set
to copy:new Port . (
forall ncpm1:new_copy_port_map .
forall ncpm2:new_copy_port_map . (
ncpm1.orig = ncpm2.orig equiv ncpm1.copy = ncpm2.copy
) and
forall cp_prt:new_copy_port_map . (
result has Ports(new_comp, cp_prt.copy) and
result has Name(cp_prt.copy, cp_prt.orig.Name) and
exists cp_prt_nd:new Direction . (
result has Direction(cp_prt.copy, cp_prt_nd) and
result has IsEntry(cp_prt_nd, cp_prt.orig.Direction.IsEntry)
) and
exists cp_prt_mt:new MIFType . (
result has DefinedType(cp_prt.copy, cp_prt_mt) and
result has Model(cp_prt_mt, cp_prt.orig.DefinedType.Model)
)) and
/* build constructors */
exists new_constructor_map:map orig:constructor_map
to copy:new Constructor . (
forall ncm1:new_constructor_map .
forall ncm2:new_constructor_map . (
ncm1.orig = ncm2.orig equiv ncm1.copy = ncm2.copy
) and
forall mk_cons:new_constructor_map . (
result has Name(mk_cons.copy,
concat(mk_cons.orig.one.Name,mk_cons.orig.two.Name)) and
result has Consts(new_dtd_module, mk_cons.copy) and
exists ntm_elem_cons:new_typedef_map . (
mk_cons.orig.one.DataDef = ntm_elem_cons.orig.one and
mk_cons.orig.two.DataDef = ntm_elem_cons.orig.two and
result has Constructors(ntm_elem_cons.copy, mk_cons.copy)
79

)) and
/* copy constructors not merged */
exists new_copy_constructor_map:map orig:copy_constructor_set
to copy:new Constructor . (
forall nccm1:new_copy_constructor_map .
forall nccm2:new_copy_constructor_map . (
nccm1.orig = nccm2.orig equiv nccm1.copy = nccm2.copy
) and
forall cp_cons:new_copy_constructor_map . (
result has Name(cp_cons.copy, cp_cons.orig.Name) and
result has Consts(new_dtd_module, cp_cons.copy) and
exists ntm_elem_ccons:new_typedef_map . (
(cp_cons.orig.DataDef = ntm_elem_ccons.orig.one or
cp_cons.orig.DataDef = ntm_elem_ccons.orig.two
) and
result has Constructors(ntm_elem_ccons.copy, cp_cons.copy)
)) and
/* build selectors */
exists new_selector_map:map orig:selector_map
to copy:new Selector . (
forall nselm1:new_selector_map .
forall nselm2:new_selector_map . (
nselm1.orig = nselm2.orig equiv nselm1.copy = nselm2.copy
) and
forall mk_sels:new_selector_map . (
result has Name(mk_sels.copy,
concat(mk_sels.orig.one.Name,mk_sels.orig.two.Name)) and
result has Consts(new_dtd_module, mk_sels.copy) and
exists ncm_elem_sels:new_constructor_map . (
mk_sels.orig.one.Constructor = ncm_elem_sels.orig.one and
mk_sels.orig.two.Constructor = ncm_elem_sels.orig.two and
result has Selectors(ncm_elem_sels.copy, mk_sels.copy,
indexOf(mk_sels.orig.one,
mk_sels.orig.one.Constructor, "Selectors"))
) and
exists ntappl1:new TAppl . (
exists tcnst1:TConst . (
tcnst1.Name = "->" and
result has THead(ntappl1, tcnst1)
) and
exists ntcm1_elem_sels:new_tconst_map . (
mk_sels.orig.one.Constructor.DataDef =
ntcm1_elem_sels.orig.one and
mk_sels.orig.two.Constructor.DataDef =
ntcm1_elem_sels.orig.two and
result has TArgs(ntappl1, ntcm1_elem_sels.copy, 0)
) and
exists ntcm2_elem_sels:new_tconst_map . (
80

call testSelectorType(mk_sels.orig.one,
ntcm2_elem_sels.orig.one.TConst) and
call testSelectorType(mk_sels.orig.two,
ntcm2_elem_sels.orig.two.TConst) and
result has TArgs(ntappl1, ntcm2_elem_sels.copy, 1)
)
and result has DefinedType(mk_sels.copy, ntappl1)
)) and
/* copy selectors */
exists new_copy_selector_map: map orig:copy_selector_set
to copy:new Selector . (
forall cselm1:new_copy_selector_map .
forall cselm2:new_copy_selector_map . (
cselm1.orig = cselm2.orig equiv cselm1.copy = cselm2.copy
) and
forall cp_sels:new_copy_selector_map . (
result has Name(cp_sels.copy, cp_sels.orig.Name) and
result has Consts(new_dtd_module, cp_sels.copy) and
exists nccm_elem_sels:new_copy_constructor_map . (
cp_sels.orig.Constructor = nccm_elem_sels.orig and
result has Selectors(nccm_elem_sels.copy, cp_sels.copy,
indexOf(cp_sels.orig,
cp_sels.orig.Constructor, "Selectors"))
) and
exists ntappl2:new TAppl . (
exists tcnst2:TConst . (
tcnst2.Name = "->" and
result has THead(ntappl2, tcnst2)
) and
exists ntcm3_elem_sels:new_tconst_map . (
(cp_sels.orig.Constructor.DataDef =
ntcm3_elem_sels.orig.one or
cp_sels.orig.Constructor.DataDef =
ntcm3_elem_sels.orig.two
) and
result has TArgs(ntappl2, ntcm3_elem_sels.copy, 0)
) and
exists tcnst3:TConst . (
call testSelectorType(cp_sels.orig, tcnst3) and
result has TArgs(ntappl2, tcnst3, 1)
) and
result has DefinedType(cp_sels.copy, ntappl2)
)) and
/* build states */
exists new_state_map:map orig:state_map to copy:new State . (
forall nsm1:new_state_map . forall nsm2:new_state_map . (
nsm1.orig = nsm2.orig equiv nsm1.copy = nsm2.copy
) and
81

* merged states are part of root state only */
forall mk_stt:new_state_map . (
result has Name(mk_stt.copy,
concat(mk_stt.orig.one.Name, mk_stt.orig.two.Name)) and
result has SubStates(new_root_state, mk_stt.copy)
) and
/* copy states not merged */
exists new_copy_state_map:map orig:copy_state_set
to copy:new State . (
forall ncsm1:new_copy_state_map .
forall ncsm2:new_copy_state_map . (
ncsm1.orig = ncsm2.orig equiv ncsm1.copy = ncsm2.copy
) and
forall cp_stt:new_copy_state_map . (
result has Name(cp_stt.copy, cp_stt.orig.Name) and (
exists nsm_elem_cpstt:new_state_map . (
(is SubStates(nsm_elem_cpstt.orig.one, cp_stt.orig) or
is SubStates(nsm_elem_cpstt.orig.two, cp_stt.orig)
) and
result has SubStates(nsm_elem_cpstt.copy, cp_stt.copy)
) or
exists ncsm_elem_cpstt:new_copy_state_map . (
is SubStates(ncsm_elem_cpstt.orig, cp_stt.orig) and
result has SubStates(ncsm_elem_cpstt.copy, cp_stt.copy)
) or
result has SubStates(new_root_state, cp_stt.copy)
)) and
/* build transitionsegments */
exists new_transition_map:map orig:transition_map
to copy:new TransitionSegment . (
forall ntm5:new_transition_map .
forall ntm6:new_transition_map . (
ntm5.orig = ntm6.orig equiv ntm5.copy = ntm6.copy
) and
forall mk_tsg:new_transition_map . (
result has TransitionSegments(new_root_state, mk_tsg.copy)
) and
/* copy transitionssegments */
exists new_copy_transition_map:map orig:copy_transition_set
to copy:new TransitionSegment.(
forall nctm5:new_copy_transition_map .
forall nctm6:new_copy_transition_map . (
nctm5.orig = nctm6.orig equiv nctm5.copy = nctm6.copy
) and
forall cp_tsg:new_copy_transition_map . (
exists nsm_elem_cptsg:new_state_map . (
(is TransitionSegments(nsm_elem_cptsg.orig.one,
82

cp_tsg.orig) or
is TransitionSegments(nsm_elem_cptsg.orig.two,
cp_tsg.orig)
) and
result has TransitionSegments(nsm_elem_cptsg.copy,
cp_tsg.copy)
) or
exists ncsm_elem_cptsg:new_copy_state_map . (
is TransitionSegments(ncsm_elem_cptsg.orig, cp_tsg.orig) and
result has TransitionSegments(ncsm_elem_cptsg.copy,
cp_tsg.copy)
) or
result has TransitionSegments(new_root_state, cp_tsg.copy)
) and
/* build interfacepoints */
exists new_ifpoint_map:map orig:interfacepoint_map
to copy:new InterfacePoint . (
forall nifpm5:new_ifpoint_map .
forall nifpm6:new_ifpoint_map . (
nifpm5.orig = nifpm6.orig equiv nifpm5.copy = nifpm6.copy
) and
forall mk_ifp:new_ifpoint_map . (
result has Name(mk_ifp.copy,
concat(mk_ifp.orig.one.Name, mk_ifp.orig.two.Name)) and
exists new_dir:Direction . (
result has Direction(mk_ifp.copy, new_dir) and
result has IsEntry(new_dir, mk_ifp.orig.one.Direction.IsEntry)
) and (
exists nsm_elem_mkifp:new_state_map . (
(mk_ifp.orig.one.State = nsm_elem_mkifp.orig.one or
mk_ifp.orig.two.State = nsm_elem_mkifp.orig.two
) and
result has InterfacePoints(nsm_elem_mkifp.copy, mk_ifp.copy)
)
) and
forall ntsgm_mkifp:new_transition_map . (
((ntsgm_mkifp.orig.one.SourcePoint = mk_ifp.orig.one or
ntsgm_mkifp.orig.two.SourcePoint = mk_ifp.orig.two
) and
result has SourcePoint(ntsgm_mkifp.copy, mk_ifp.copy)
) or
((ntsgm_mkifp.orig.one.DestinationPoint = mk_ifp.orig.one or
ntsgm_mkifp.orig.two.DestinationPoint = mk_ifp.orig.two
) and
result has DestinationPoint(ntsgm_mkifp.copy, mk_ifp.copy)
) or true /* nothing to do for this transitionsegment */
) and
forall nctsgm_mkifp:new_copy_transition_map . (
((nctsgm_mkifp.orig.SourcePoint = mk_ifp.orig.one or
83

nctsgm_mkifp.orig.SourcePoint = mk_ifp.orig.two
) and
result has SourcePoint(nctsgm_mkifp.copy, mk_ifp.copy)
) or
((nctsgm_mkifp.orig.DestinationPoint = mk_ifp.orig.one or
nctsgm_mkifp.orig.DestinationPoint = mk_ifp.orig.two
) and
result has DestinationPoint(nctsgm_mkifp.copy, mk_ifp.copy)
) or true /* nothing to do for this transitionsegment */
)) and
/* copy interfacepoints */
exists new_copy_ifpoint_map:map orig:copy_interfacepoint_set
to copy:new InterfacePoint . (
forall ncifpm5:new_copy_ifpoint_map .
forall ncifpm6:new_copy_ifpoint_map . (
ncifpm5.orig = ncifpm6.orig equiv ncifpm5.copy = ncifpm6.copy
) and
forall cp_ifp:new_copy_ifpoint_map . (
result has Name(cp_ifp.copy, cp_ifp.orig.Name) and
exists new_dir2:Direction . (
result has Direction(cp_ifp.copy, new_dir2) and
result has IsEntry(new_dir2, cp_ifp.orig.Direction.IsEntry)
) and (
exists nsm_elem_cpifp:new_state_map . (
(cp_ifp.orig.State = nsm_elem_cpifp.orig.one or
cp_ifp.orig.State = nsm_elem_cpifp.orig.two
) and
result has InterfacePoints(nsm_elem_cpifp.copy, cp_ifp.copy)
) or
exists ncsm_elem_cpifp:new_copy_state_map . (
cp_ifp.orig.State = ncsm_elem_cpifp.orig and
result has InterfacePoints(ncsm_elem_cpifp.copy, cp_ifp.copy)
)
) and
forall ntsgm_cpifp:new_transition_map . (
((ntsgm_cpifp.orig.one.SourcePoint = cp_ifp.orig or
ntsgm_cpifp.orig.two.SourcePoint = cp_ifp.orig
) and
result has SourcePoint(ntsgm_cpifp.copy, cp_ifp.copy)
) or
((ntsgm_cpifp.orig.one.DestinationPoint = cp_ifp.orig or
ntsgm_cpifp.orig.two.DestinationPoint = cp_ifp.orig
) and
result has DestinationPoint(ntsgm_cpifp.copy, cp_ifp.copy)
) or true /* nothing to do for this transitionsegment */
) and
forall nctsgm_cpifp:new_copy_transition_map . (
(nctsgm_cpifp.orig.SourcePoint = cp_ifp.orig and
result has SourcePoint(nctsgm_cpifp.copy, cp_ifp.copy)
84

) or
(nctsgm_cpifp.orig.DestinationPoint = cp_ifp.orig and
result has DestinationPoint(nctsgm_cpifp.copy, cp_ifp.copy)
) or true /* nothing to do for this transitionsegment */
)) and
/* build locvariables */
exists new_lvar_map:map orig:lvar_map to copy:new LocVariable . (
forall nlvm1:new_lvar_map . forall nlvm2:new_lvar_map . (
nlvm1.orig = nlvm2.orig equiv nlvm1.copy = nlvm2.copy
) and
forall mk_lvar:new_lvar_map . (
result has LocVariables(new_comp, mk_lvar.copy) and
result has Name(mk_lvar.copy,
concat(mk_lvar.orig.one.Name, mk_lvar.orig.two.Name)) and
exists mk_lvar_mt:new MIFType . (
result has DefinedType(mk_lvar.copy, mk_lvar_mt) and
exists ntm_elem_lvar:TConst . (
mk_lvar.orig.one.DefinedType.Model = ntm_elem_lvar and
mk_lvar.orig.two.DefinedType.Model = ntm_elem_lvar and
result has Model(mk_lvar_mt, ntm_elem_lvar)
))) and
/* copy locvariables */
exists new_copy_lvar_map:map orig:copy_lvar_set
to copy:new LocVariable . (
forall nclvm1:new_copy_lvar_map .
forall nclvm2:new_copy_lvar_map . (
nclvm1.orig = nclvm2.orig equiv nclvm1.copy = nclvm2.copy
) and
forall cp_lvar:new_copy_lvar_map . (
result has LocVariables(new_comp, cp_lvar.copy) and
result has Name(cp_lvar.copy, cp_lvar.orig.Name) and
exists cp_lvar_mt:new MIFType . (
result has DefinedType(cp_lvar.copy, cp_lvar_mt) and
result has Model(cp_lvar_mt, cp_lvar.orig.DefinedType.Model)
)) and
/* build locavariableconsts */
exists new_lvcn_map:map orig:lvarconst_map
to copy:new LocVariableConst . (
forall nlvcm1:new_lvcn_map .
forall nlvcm2:new_lvcn_map . (
nlvcm1.orig = nlvcm2.orig equiv nlvcm1.copy = nlvcm2.copy
) and
forall mk_lvc:new_lvcn_map . (
result has Name(mk_lvc.copy,
concat(mk_lvc.orig.one.LocVariable.Name,
mk_lvc.orig.two.LocVariable.Name)) and
exists nlvm_elem_lvcnm:new_lvar_map . (
85

nlvm_elem_lvcnm.orig.one = mk_lvc.orig.one.LocVariable and
nlvm_elem_lvcnm.orig.two = mk_lvc.orig.two.LocVariable and
result has LocVariable(mk_lvc.copy, nlvm_elem_lvcnm.copy)
)) and
/* copy locvariableconsts */
exists new_copy_lvcn_map:map orig:copy_lvarconst_set
to copy:new LocVariableConst . (
forall nclvcm1:new_copy_lvcn_map .
forall nclvcm2:new_copy_lvcn_map . (
nclvcm1.orig = nclvcm2.orig equiv nclvcm1.copy = nclvcm2.copy
) and
forall cp_lvc:new_copy_lvcn_map . (
result has Name(cp_lvc.copy, cp_lvc.orig.LocVariable.Name) and
exists nclvm_elem_clvcnm:new_copy_lvar_map . (
nclvm_elem_clvcnm.orig = cp_lvc.orig.LocVariable and
result has LocVariable(cp_lvc.copy, nclvm_elem_clvcnm.copy)
)) and
/* build appls */
exists new_appl_map:map orig:appl_map
to copy:new Appl . (
forall nappm1:new_appl_map .
forall nappm2:new_appl_map . (
nappm1.orig = nappm2.orig equiv nappm1.copy = nappm2.copy
) and
forall mk_app:new_appl_map . (
((mk_app.orig.one.Head = mk_app.orig.two.Head and
result has Head(mk_app.copy, mk_app.orig.one.Head)
) or
exists ncon_head:new_constructor_map . (
mk_app.orig.one.Head = ncon_head.orig.one and
mk_app.orig.two.Head = ncon_head.orig.two and
result has Head(mk_app.copy, ncon_head.copy)
)) and
forall param1:(mk_app.orig.one.Args) .
exists param2:(mk_app.orig.two.Args) . (
indexOf(param1, mk_app.orig.one, "Args") =
indexOf(param2, mk_app.orig.two, "Args") and
(exists ncon_arg:new_constructor_map . (
ncon_arg.orig.one = param1 and
ncon_arg.orig.two = param2 and
result has Args(mk_app.copy, ncon_arg.copy,
indexOf(param1, mk_app.orig.one, "Args"))
) or
exists napp_arg:new_appl_map . (
napp_arg.orig.one = param1 and
napp_arg.orig.two = param2 and
result has Args(mk_app.copy, napp_arg.copy,
indexOf(param1, mk_app.orig.one, "Args"))
86

) or
exists nlvar_arg:new_lvcn_map . (
nlvar_arg.orig.one = param1 and
nlvar_arg.orig.two = param2 and
result has Args(mk_app.copy, nlvar_arg.copy,
indexOf(param1, mk_app.orig.one, "Args"))
) or
(param1 = param2 and
result has Args(mk_app.copy, param1,
indexOf(param1, mk_app.orig.one, "Args"))
)))) and
/* copy appls */
exists new_copy_appl_map:map orig:copy_appl_set
to copy:new Appl . (
forall ncappm1:new_copy_appl_map .
forall ncappm2:new_copy_appl_map . (
ncappm1.orig = ncappm2.orig equiv ncappm1.copy = ncappm2.copy
) and
forall cp_app:new_copy_appl_map . (
(exists ncon_head2:new_constructor_map . (
(cp_app.orig.Head = ncon_head2.orig.one or
cp_app.orig.Head = ncon_head2.orig.two
) and
result has Head(cp_app.copy, ncon_head2.copy)
) or
/* normal const */
result has Head(cp_app.copy, cp_app.orig.Head)
) and
forall param:(cp_app.orig.Args) . (
exists ncapp_arg:new_copy_appl_map . (
ncapp_arg.orig = param and
result has Args(cp_app.copy, ncapp_arg.copy,
indexOf(param, cp_app.orig, "Args"))
) or
exists ncon_arg2:new_constructor_map . (
(ncon_arg2.orig.one = param or
ncon_arg2.orig.two = param
) and
result has Args(cp_app.copy, ncon_arg2.copy,
indexOf(param, cp_app.orig, "Args"))
) or
exists nlvar_arg2:new_lvcn_map . (
(nlvar_arg2.orig.one = param or
nlvar_arg2.orig.two = param
) and
result has Args(cp_app.copy, nlvar_arg2.copy,
indexOf(param, cp_app.orig, "Args"))
) or
exists nlvarcopy_arg:new_copy_lvcn_map . (
87

nlvarcopy_arg.orig = param and
result has Args(cp_app.copy, nlvarcopy_arg.copy,
indexOf(param, cp_app.orig, "Args"))
) or
/* other Const incl. not-unified Constructors */
result has Args(cp_app.copy, param,
indexOf(param, cp_app.orig, "Args"))
)) and
/* build inputs */
exists new_input_map:map orig:input_map to copy:new Input . (
forall nim1:new_input_map . forall nim2:new_input_map . (
nim1.orig = nim2.orig equiv nim1.copy = nim2.copy
) and
forall mk_inp:new_input_map . (
exists ntm_elem:new_transition_map . (
ntm_elem.orig.one = mk_inp.orig.one.TransitionSegment and
ntm_elem.orig.two = mk_inp.orig.two.TransitionSegment and
result has TransitionSegment(mk_inp.copy, ntm_elem.copy)
) and
exists npm_elem_inp:new_port_map . (
npm_elem_inp.orig.one = mk_inp.orig.one.Port.Model and
npm_elem_inp.orig.two = mk_inp.orig.two.Port.Model and
exists new_port_inp:new MIFPort . (
result has Port(mk_inp.copy, new_port_inp) and
result has Model(new_port_inp, npm_elem_inp.copy)
)) and
exists nmt_inp:new MIFTerm . (
result has Pattern(mk_inp.copy, nmt_inp) and
run setUnifiedMIFTerm(mk_inp.orig.one.Pattern,
mk_inp.orig.two.Pattern, nmt_inp, new_constructor_map,
new_appl_map, new_lvcn_map)
))) and
/* copy inputs */
exists new_copy_input_map:map orig:copy_input_set
to copy:new Input . (
forall ncim1:new_copy_input_map .
forall ncim2:new_copy_input_map . (
ncim1.orig = ncim2.orig equiv ncim1.copy = ncim2.copy
) and
forall cp_inp:new_copy_input_map . (
(exists ntm_elem_inp2:new_transition_map . (
(ntm_elem_inp2.orig.one = cp_inp.orig.TransitionSegment or
ntm_elem_inp2.orig.two = cp_inp.orig.TransitionSegment
) and
result has TransitionSegment(cp_inp.copy, ntm_elem_inp2.copy)
) or
exists nctm_elem_inp:new_copy_transition_map . (
nctm_elem_inp.orig = cp_inp.orig.TransitionSegment and
88

esult has TransitionSegment(cp_inp.copy, nctm_elem_inp.copy)
)) and (
exists npm_elem_inp2:new_port_map . (
(npm_elem_inp2.orig.one = cp_inp.orig.Port.Model or
npm_elem_inp2.orig.two = cp_inp.orig.Port.Model
) and
exists new_port_cinp:new MIFPort . (
result has Port(cp_inp.copy, new_port_cinp) and
result has Model(new_port_cinp, npm_elem_inp2.copy)
)) or
exists ncpm_elem_inp:new_copy_port_map . (
ncpm_elem_inp.orig = cp_inp.orig.Port.Model and
exists new_port_inp2:new MIFPort . (
result has Port(cp_inp.copy, new_port_inp2) and
result has Model(new_port_inp2, ncpm_elem_inp.copy)
))) and
exists nmt_cinp:new MIFTerm . (
result has Pattern(cp_inp.copy, nmt_cinp) and
run setCopiedMIFTerm(cp_inp.orig.Pattern, nmt_cinp,
new_constructor_map, new_copy_constructor_map, new_appl_map,
new_copy_appl_map, new_lvcn_map, new_copy_lvcn_map)
))) and
/* build outputs */
exists new_output_map:map orig:output_map to copy:new Output . (
forall nom1:new_output_map . forall nom2:new_output_map . (
nom1.orig = nom2.orig equiv nom1.copy = nom2.copy
) and
forall mk_outp:new_output_map . (
exists ntm_elem_outp:new_transition_map . (
ntm_elem_outp.orig.one=mk_outp.orig.one.TransitionSegment and
ntm_elem_outp.orig.two=mk_outp.orig.two.TransitionSegment and
result has TransitionSegment(mk_outp.copy, ntm_elem_outp.copy)
) and
exists npm_elem_outp:new_port_map . (
npm_elem_outp.orig.one = mk_outp.orig.one.Port.Model and
npm_elem_outp.orig.two = mk_outp.orig.two.Port.Model and
exists new_port_outp:new MIFPort . (
result has Port(mk_outp.copy, new_port_outp) and
result has Model(new_port_outp, npm_elem_outp.copy)
)
) and
exists nmt_outp:new MIFTerm . (
result has Expression(mk_outp.copy, nmt_outp) and
run setUnifiedMIFTerm(mk_outp.orig.one.Expression,
mk_outp.orig.two.Expression, nmt_outp, new_constructor_map,
new_appl_map, new_lvcn_map)
))) and
/* copy outputs */
89

exists new_copy_output_map:map orig:copy_output_set
to copy:new Output . (
forall ncom1:new_copy_output_map .
forall ncom2:new_copy_output_map . (
ncom1.orig = ncom2.orig equiv ncom1.copy = ncom2.copy
) and
forall cp_outp:new_copy_output_map . (
(exists ntm_elem_outp2:new_transition_map . (
(ntm_elem_outp2.orig.one = cp_outp.orig.TransitionSegment or
ntm_elem_outp2.orig.two = cp_outp.orig.TransitionSegment
) and
result has
TransitionSegment(cp_outp.copy, ntm_elem_outp2.copy)
) or
exists nctm_elem_outp:new_copy_transition_map . (
nctm_elem_outp.orig = cp_outp.orig.TransitionSegment and
result has
TransitionSegment(cp_outp.copy, nctm_elem_outp.copy)
)) and (
exists npm_elem_outp2:new_port_map . (
(npm_elem_outp2.orig.one = cp_outp.orig.Port.Model or
npm_elem_outp2.orig.two = cp_outp.orig.Port.Model
) and
exists new_port_coutp:new MIFPort . (
result has Port(cp_outp.copy, new_port_coutp) and
result has Model(new_port_coutp, npm_elem_outp2.copy)
)) or
exists ncpm_elem_outp:new_copy_port_map . (
ncpm_elem_outp.orig = cp_outp.orig.Port.Model and
exists new_port_outp2:new MIFPort . (
result has Port(cp_outp.copy, new_port_outp2) and
result has Model(new_port_outp2, ncpm_elem_outp.copy)
))) and
exists nmt_coutp:new MIFTerm . (
result has Expression(cp_outp.copy, nmt_coutp) and
run setCopiedMIFTerm(cp_outp.orig.Expression, nmt_coutp,
new_constructor_map, new_copy_constructor_map, new_appl_map,
new_copy_appl_map, new_lvcn_map, new_copy_lvcn_map)
))) and
/* build actions */
exists new_action_map:map orig:action_map to copy:new Action . (
forall nactm1:new_action_map . forall nactm2:new_action_map . (
nactm1.orig = nactm2.orig equiv nactm1.copy = nactm2.copy
) and
forall mk_act:new_action_map . (
exists ntm_elem_act:new_transition_map . (
ntm_elem_act.orig.one = mk_act.orig.one.TransitionSegment and
ntm_elem_act.orig.two = mk_act.orig.two.TransitionSegment and
result has TransitionSegment(mk_act.copy, ntm_elem_act.copy)
90

) and
exists npm_elem_act:new_lvar_map . (
npm_elem_act.orig.one = mk_act.orig.one.LocVariable.Model and
npm_elem_act.orig.two = mk_act.orig.two.LocVariable.Model and
exists new_lvcn_act:new MIFLocVariable . (
result has LocVariable(mk_act.copy, new_lvcn_act) and
result has Model(new_lvcn_act, npm_elem_act.copy)
)) and
exists nmt_act:new MIFTerm . (
result has Value(mk_act.copy, nmt_act) and
run setUnifiedMIFTerm(mk_act.orig.one.Value,
mk_act.orig.two.Value, nmt_act, new_constructor_map,
new_appl_map, new_lvcn_map)
))) and
/* copy actions */
exists new_copy_action_map:map orig:copy_action_set
to copy:new Action . (
forall ncactm1:new_copy_action_map .
forall ncactm2:new_copy_action_map . (
ncactm1.orig = ncactm2.orig equiv ncactm1.copy = ncactm2.copy
) and
forall cp_act:new_copy_action_map . (
(exists ntm_elem_act2:new_transition_map . (
(ntm_elem_act2.orig.one = cp_act.orig.TransitionSegment or
ntm_elem_act2.orig.two = cp_act.orig.TransitionSegment
) and
result has TransitionSegment(cp_act.copy, ntm_elem_act2.copy)
) or
exists nctm_elem_act:new_copy_transition_map . (
nctm_elem_act.orig = cp_act.orig.TransitionSegment and
result has TransitionSegment(cp_act.copy, nctm_elem_act.copy)
)) and (
exists npm_elem_act2:new_lvar_map . (
(npm_elem_act2.orig.one = cp_act.orig.LocVariable.Model or
npm_elem_act2.orig.two = cp_act.orig.LocVariable.Model
) and
exists new_lvcn_cact:new MIFLocVariable . (
result has LocVariable(cp_act.copy, new_lvcn_cact) and
result has Model(new_lvcn_cact, npm_elem_act2.copy)
)) or
exists ncpm_elem_act:new_copy_lvar_map . (
ncpm_elem_act.orig = cp_act.orig.LocVariable.Model and
exists new_lvcn_act2:new MIFLocVariable . (
result has LocVariable(cp_act.copy, new_lvcn_act2) and
result has Model(new_lvcn_act2, ncpm_elem_act.copy)
))) and
exists nmt_cact:new MIFTerm . (
result has Value(cp_act.copy, nmt_cact) and
run setCopiedMIFTerm(cp_act.orig.Value, nmt_cact,
91

new_constructor_map, new_copy_constructor_map, new_appl_map,
new_copy_appl_map, new_lvcn_map, new_copy_lvcn_map)
))) and
/* build conditions */
exists new_condition_map:map orig:condition_map
to copy:new Condition . (
forall ncondm1:new_condition_map .
forall ncondm2:new_condition_map . (
ncondm1.orig = ncondm2.orig equiv ncondm1.copy = ncondm2.copy
) and
forall mk_cond:new_condition_map . (
exists ntm_elem_cond:new_transition_map . (
ntm_elem_cond.orig.one=mk_cond.orig.one.TransitionSegment and
ntm_elem_cond.orig.two=mk_cond.orig.two.TransitionSegment and
result has TransitionSegment(mk_cond.copy, ntm_elem_cond.copy)
) and
exists nmt_cond:new MIFTerm . (
result has Expression(mk_cond.copy, nmt_cond) and
run setUnifiedMIFTerm(mk_cond.orig.one.Expression,
mk_cond.orig.two.Expression, nmt_cond, new_constructor_map,
new_appl_map, new_lvcn_map)
))) and
/* copy conditions */
exists new_copy_condition_map:map orig:copy_condition_set
to copy:new Condition . (
forall nccondm1:new_copy_condition_map .
forall nccondm2:new_copy_condition_map . (
nccondm1.orig=nccondm2.orig equiv nccondm1.copy=nccondm2.copy
) and
forall cp_cond:new_copy_condition_map . (
(exists ntm_elem_cond2:new_transition_map . (
(ntm_elem_cond2.orig.one = cp_cond.orig.TransitionSegment or
ntm_elem_cond2.orig.two = cp_cond.orig.TransitionSegment
) and
result has
TransitionSegment(cp_cond.copy, ntm_elem_cond2.copy)
) or
exists nctm_elem_cond:new_copy_transition_map . (
nctm_elem_cond.orig = cp_cond.orig.TransitionSegment and
result has
TransitionSegment(cp_cond.copy, nctm_elem_cond.copy)
)) and
exists nmt_ccond:new MIFTerm . (
result has Expression(cp_cond.copy, nmt_ccond) and
run setCopiedMIFTerm(cp_cond.orig.Expression, nmt_ccond,
new_constructor_map, new_copy_constructor_map, new_appl_map,
new_copy_appl_map, new_lvcn_map, new_copy_lvcn_map)
)))
))))))))))))))))))))))
92

Literaturverzeichnis
[Dun05] Dennis Dungs. Design and implementation of a unique interface
and object model for the integration of supplementary tools in common
UML modeling tools. Systementwicklungsprojekt, Technische
Universität München, 2005.
[Höl05]
[HS05]
Florian Hölzl. Erweiterung und Optimierung des AQuA-Systems.
Systementwicklungsprojekt Projektbericht, Technische Universität
München, 2005.
Florian Hölzl and Bernhard Schätz. Adding interaction and transformation
to constraint languages. Zur Zeit der Erstellung, eingereicht
bei der Konferenz MoDELS 2005, 2005.
[OMG03a] OMG. OMG Unified Modeling Language Specification.
http://www.omg.org, March 2003.
[OMG03b] OMG. UML 2.0 OCL Specification. http://www.omg.org, 2003.
[OMG04] OMG. MetaObject Facility (MOF) Specification.
http://www.omg.org, Apr. 2004.
[Pas05]
David Pasch. Modellbasierte Prozessunterstützung für AutoFocus.
Diplomarbeit, Technische Universität München, 2005.
[Sch00] Uwe Schöning. Logik für Informatiker. Spektrum Akademischer
Verlag, 2000.
[Sch01]
[Str05]
[Tra03]
Bernhard Schätz. The ODL Operation Definition Language and the
AutoFocus/Quest application framework AQuA. Technical Report
TUM-I0111, Technische Universität München, 2001.
Markus Strohmeier. Modellbasierte Validierung verteilter Komponenten:
Kopplung von AutoFOCUS und SPIN. Diplomarbeit, Technische
Universität München, 2005.
David Trachtenherz. Erweiterung des AQuA-Systems: ODL Sprachkonstrukte
und interaktive Benutzerschnittstelle. Diplomarbeit,
Technische Universität München, 2003.
[TUM02] AutoFocus. http://autofocus.in.tum.de/, 2002.
[TUM04a] AutoMode. http://www4.in.tum.de/∼automode, 2004.
93

[TUM04b] AutoRaid. http://www4.in.tum.de/∼autoraid, 2004.
[TUM05] AutoFocus 2. http://www4.in.tum.de/∼af2, 2005.
[W3C99] W3C. XSL Transformation (XSLT) Version 1.0.
http://www.w3c.org, November 1999.
94