Diplomarbeit ModelltransformationsansätzeimKontextModellgetriebenerSoftwareentwicklung

Modelltransformationsansätze

im Kontext Modellgetriebener Softwareentwicklung

Diplomarbeit

vorgelegt von Kerstin Falkowski falke@uni-koblenz.de

Betreuer:

Prof. Dr. Jürgen Ebert Dr. Andreas Winter

November 2005

Studierende der Computervisualistik an der Universität Koblenz-Landau, dass ich diese Arbeit eigenständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe.

Kerstin Falkowski Kerstin Falk Koblenz, November 2005

ihre kompetente Betreuung bedanken. Ihre Fragen, Anregungen und vor allem die konstruktive Kritik haben viel zu dieser Arbeit beigetragen.

Außerdem möchte ich mich bei meinen Eltern für ihre Unterstützung und ihr Ver- ständnis bedanken, und dafür, dass sie mir mein Studium ermöglicht haben.

1.1 Ziel der Arbeit . . . 12

1.2 Inhalte und Struktur der Arbeit . . . 12

1.3 Formatierung . . . 13

2 Modelgetriebene Softwareentwicklung 15 2.1 Einordnung von MD* in die Softwaretechnik . . . 15

2.2 MD*-Artfakte . . . 16

2.2.1 Modell . . . 16

2.2.2 Metamodell . . . 17

2.2.3 Modelltransformation . . . 18

2.3 MD*-Ansätze . . . 19

2.3.1 Model Driven Architecture . . . 19

2.3.2 Model Driven Engineering . . . 20

2.3.3 Model Driven Software Development . . . 22

2.3.4 Bewertung und Vergleich der Ansätze . . . 23

3 Eigenschaften von Modelltransformationsansätzen 27 3.1 Eigenschaften von Sprachen . . . 28

3.1.1 Datenstruktur . . . 29

3.1.2 konkrete Syntax . . . 29

3.1.3 abstrakte Syntax . . . 29

3.1.4 Chomsky-Typ . . . 30

3.1.5 Paradigma . . . 31

3.2 Eigenschaften von Modelltransformationssprachen . . . 31

3.2.1 Modelltransformation . . . 31

3.2.2 Anfragen . . . 32

3.2.3 Sichten . . . 32

3.3 Eigenschaften von Transformationen . . . 33

3.3.1 Modell-Beziehung . . . 33

3.3.2 Ursprung . . . 33

3.3.3 Richtung . . . 34

3.3.4 Umfang . . . 34

3.4 Eigenschaften von Transformationsregeln . . . 35

3.4.1 Parametrisierung . . . 35

3.5 Eigenschaften von Transformationsstrategien . . . 35

3.5.1 Reihenfolge . . . 35

3.5.2 Inkrementalität . . . 36

3.6 Qualitätseigenschaften für Modelltransformationsansätze . . . 36

3.6.1 Verfolgbarkeit . . . 36

4 Modelltransformationsansätze 39

4.1 ATLAS Transformation Language . . . 39

4.2 Bidirectional Object-oriented Transformation Language . . . 42

4.3 FUJABA . . . 45

4.4 Multi-Domain Integration . . . 48

4.5 ASF+SDF . . . 50

4.6 Stratego . . . 52

4.7 Turing eXtender Language . . . 54

4.8 Vergleich der Modelltransformationsansätze . . . 56

5 Benchmarking im Allgemeinen 61 5.1 Benchmark . . . 62

5.1.1 Zweck und Ergebnis eines Benchmarks . . . 62

5.1.2 Benchmarking als wissenschaftliche Methode . . . 63

5.2 Bedingungen für die Erstellung eines Benchmarks . . . 63

5.3 Schritte für die Erstellung eines Benchmarks . . . 64

5.4 Komponenten eines Benchmarks . . . 65

5.4.1 Vergleichskriterien . . . 65

5.4.2 Aufgaben . . . 66

5.4.3 Leistungsmessung . . . 67

5.5 Anforderungen an einen Benchmark . . . 67

6 Eine Benchmark-Aufgabe für Modelltransformationsansätze 71 6.1 Präsentation von Benchmark-Ergebnissen . . . 71

6.1.1 Allgemeine Informationen für einen Modelltransformations- ansatz . . . 72

6.2 Benchmark-Aufgabe . . . 73

6.2.1 Beschreibung der Modelle . . . 76

6.2.2 Beschreibung der Aufgabe . . . 77

7 Bearbeitung der Benchmark-Aufgabe mit ATL 83 7.1 Allgemeine Informationen zu ATL . . . 83

7.1.1 Die Installation von ADT . . . 83

7.1.2 Die Benutzeroberfläche von Eclipse und ADT . . . 84

7.1.3 ATL-Modelle . . . 86

7.1.4 Die Sprache ATL . . . 89

7.1.5 Vorbereiten einer neuen ATL-Transformation . . . 93

7.2 Bearbeitung der Benchmark-Aufgabe . . . 95

7.2.1 Aufgabe 1.1 . . . 97

7.3.1 Die Sprache ATL . . . 108

7.3.2 ADT und dessen Einbettung in Eclipse . . . 109

7.3.3 ATL-Dokumentation . . . 111

7.3.4 Fazit . . . 112

7.4 Bewertung der Benchmark-Aufgabe . . . 112

8 Zusammenfassung 115 8.1 Ausblick . . . 116

A Zusätzliche Informationen 117 A.1 Inhalt der beiliegenden CD . . . 117

A.2 Installation von ADT . . . 117

A.3 Vorbereitungen für die Nutzung der Beispiele . . . 118

Literatur 121

Abbildungsverzeichnis

2 Model Driven Engineering . . . 21

3 Model Driven Software Development . . . 22

4 Vergleich derMD*-Ansätze . . . 25

5 Modell und Metamodell . . . 30

6 BOTL Beispiel-Transformation . . . 43

7 FUJABA Storydiagramm . . . 46

8 MDI Beispiel-Transformationsrege . . . 49

9 Stratego Beispiel-Transformationsspezifikation . . . 53

10 TXL Beispiel-Transformationsregel . . . 55

11 Refactoring Extract Superclass Original . . . 75

12 Quellmodell für Extract Superclass . . . 77

13 Metamodell für Extract Superclass . . . 78

14 Gemeinsame Oberklasse für Attribute . . . 79

15 Gemeinsame Oberklasse für Operationen . . . 80

16 Gemeinsame Oberklasse für Beziehungen . . . 81

17 Gemeinsame Oberklasse für gemeinsame Elemente . . . 82

18 Eclipse mit ATL-Perspektive . . . 85

19 Das Ecore-Modellmetamodell . . . 87

20 Erstellung eines Ecore-konformem Modells . . . 89

24 ExtractSuperclass für Attribute . . . 104

25 ExtractSuperclass für Operationen . . . 105

26 ExtractSuperclass für Beziehungen . . . 107

27 Konfiguration eines ATL-Moduls . . . 119

Tabellenverzeichnis

2 Eigenschaften von ATL . . . 41

3 Eigenschaften von BOTL . . . 44

4 Eigenschaften von FUJABA . . . 47

5 Eigenschaften von MDI . . . 50

6 Eigenschaften von ASF+SDF . . . 52

7 Eigenschaften von Stratego . . . 54

8 Eigenschaften von TXL . . . 56

9 Eigenschaften der Modelltransformationsansätze 1 . . . 58

10 Eigenschaften der Modelltransformationsansätze 2 . . . 59

1 Einleitung

Zurzeit liest und hört man in der Informatik und ganz besonders im Bereich der Soft- waretechnik immer häufiger Begriffe mit den Präfixen „modellgetrieben“ im Deut- schen bzw. „model driven“ im Englischen. Es gibt Konferenzen, die sich mit modell- getriebener Softwareentwicklung beschäftigen, neue Werkzeuge und Entwicklungs- ansätze bezeichnen sich selbst als model driven und es existiert bereits einiges an Literatur zu diesem Thema. In der vorliegenden Arbeit werden Artefakte und Vor- gehensweisen, die mit modellgetriebener Softwareentwicklung zu tun haben, unter dem BegriffModel Driven * (MD*)zusammengefasst.

Leider haben der Begriff und dadurch auch das gesamte ThemengebietMD*bei vie- len bereits einen negativen Beigeschmack, weil häufig versucht wird, beliebige Arte- fakte und Vorgehensweisen unter dem Deckmantel vonMD*zu verkaufen. Darüber hinaus versprechen die modellgetriebenen Softwareentwicklungsansätze sehr viel, können bei genauerem Hinsehen aber (noch) nicht viel Konkretes bieten. Doch was genau steckt wirklich hinterMD*?

MD* beschreibt Ansätze für die Softwareentwicklung, bei denen die Erstellung und Nutzung sowie die (halbautomatische oder automati- sche) Transformation von Modellen in den Vordergrund gestellt wird.

Nicht mehr und nicht weniger.MD*ist kein Wundermittel, mit dem sich sämtliche Probleme der Softwaretechnik lösen lassen. Darüber hinaus befindet sich die mo- dellgetriebene Entwicklung entgegen ihrem Bekanntheitsgrad noch im Anfangssta- dium. Trotzdem oder gerade deswegen ist das Thema ein interessanter Forschungs- bereich, wenn es wissenschaftlich und weniger plakativ betrachtet wird.

Die vorliegende Arbeit beschäftigt sich mitMD*im Allgemeinen und mitModell- transformationensowieModelltransformationsansätzenim Besonderen.

Modelltransformationen sind neben Modellen und Metamodellen wichtige Ar- tefakte in MD*¹. Die Verwendung von Modellen und Metamodellen hat sich in der Softwaretechnik etabliert, und es gibt anerkannte Standardsprachen, um sie zu beschreiben. Die Durchführung von Modelltransformationen ist weniger verbrei- tet und, obwohl unterschiedliche Modelltransformationsansätze existieren, gibt es (noch) keine anerkannte Standardsprache zur Spezifikation von Modelltransforma- tionen.

1Eine Modelltransformation ist eigentlich kein Artefakt. Die Bezeichnung Modelltransformation steht im Zusammenhang mit dem Ausdruck Artefakt in dieser Arbeit für die Beschreibung ei- ner Modelltransformation.

1.1 Ziel der Arbeit

Das Ziel dieser Arbeit ist die Untersuchung von modellgetriebene Softwareentwick- lungansätzen im Allgemeinen und Modelltransformationsansätze im Besonderen.

Besonders wichtig ist dabei der Vergleich bestehender Modelltransformationsansät- ze.

1.2 Inhalte und Struktur der Arbeit

In dieser Arbeit werden zunächst vier Teilthemen vorgestellt. Die Inhalte haben im weitesten Sinne mit modellgetriebener Softwareentwicklung zu tun und tragen auf unterschiedliche Art und Weise zum Erreichen des spezifizierten Ziels bei. Da jedoch alle Themen auch für sich alleine stehen können, wird jedes von ihnen in einem eige- nen Kapitel beschrieben (siehe Kapitel 2, 3,??und 5), wobei Kapitel 3 und??etwas enger miteinander verknüpft sind. Wichtige Querbezüge der Themen untereinander werden bereits innerhalb der beschriebenen Kapitel erläutert. Wirklich zusammen- gebracht werden alle Teilthemen jedoch erst in den Kapiteln 6, 7 und 8 bei der prak- tischen Nutzung des zuvor gesammelten Wissens und der Zusammenfassung und Bewertung des Gesamtergebnisses.

Kapitel 2beschäftigt sich mit der modellgetriebenen Softwareentwicklung im All- gemeinen. Zunächst wird das Thema in die Softwaretechnik eingeordnet. Danach werden wichtige Artefakte fürMD*vorgestellt sowie unterschiedlicheMD*-Ansätze erläutert und miteinander verglichen.

InKapitel 3werden diverse Eigenschaften erläutert, die ein Modelltransformations- ansatz besitzen kann und mit deren Hilfe sich unterschiedliche Modelltransformati- onsansätze untersuchen und klassifizieren lassen.

Kapitel ?? werden sieben verschiedene Modelltransformationsansätze vorgestellt und es wird versucht, sie anhand der in Kapitel 3 beschriebenen Eigenschaften zu kategorisieren.

Kapitel 5 behandelt das Thema Benchmarking. Zunächst wird der Begriff Bench- mark erläutert. Danach werden verschiedene Aspekte der Erstellung und Nutzung eines Benchmarks näher betrachtet und es werden Anforderungen an einen guten Benchmark vorgestellt.

In Kapitel 6 wird das zuvor gesammelte Wissen dazu genutzt, eine beispielhafte Benchmark-Aufgabe für Modelltransformationsansätze zu erstellen.

In Kapitel 7 wird die Benchmark-Aufgabe mit einem der in Kapitel ??beschriebe- nen Modelltransformationsansätze bearbeitet. Auf diese Weise werden sowohl die Aufgabe als auch der Modelltransformationsansatz validiert.

Kapitel 8fasst die Teilergebnisse der Arbeit zusammen und bewertet das Gesamter- gebnis.

1.3 Formatierung

Der normale Fließtext ist in der vorliegenden Arbeit für eine gute Lesbarkeit in ei- ner Schrift mit Serifen geschrieben. Für strukturierende Elemente wie Überschriften, Kopf- und Fußzeilen sowie Bild- und Tabellenunterschriften wird hingegen einese- rifenlose Schriftverwendet. Sourcecode- und Modellkomponenten sowie Verzeich- nisnamen werden durch eineTypewriter-Schriftgekennzeichnet. Für wichtige Begriffe wird in dieser Arbeit Fettdruckbenutzt und Abkürzungen werden durch einekursive Schriftbetont.

2 Modelgetriebene Softwareentwicklung

Dieses Kapitel beschäftigt sich mit dem Thema modellgetriebene Softwareentwick- lung. Zunächst wirdMD*in die Softwaretechnik im Allgemeinen eingeordnet (sie- he Abschnitt 2.1). Danach werden die drei wichtigsten Artefakte für MD* vorge- stellt: Modelle, Metamodelle und Modelltransformationen (siehe Abschnitt 2.2). Au- ßerdem werden drei unterschiedlicheMD*-Ansätze kurz erläutert und miteinander verglichen (siehe Abschnitt 2.3). So entsteht eine Beschreibung des State of the Art in der modellgetriebenen Softwareentwicklung.

2.1 Einordnung von MD* in die Softwaretechnik

Die Erstellung von Modellen hat in der Softwaretechnik eine lange Tradition und die Bedeutung der Modellierung wächst stetig. Besonders durch dieObjektorientierte Entwicklungsind Modelle verbreitet und allgemein anerkannt. Doch es gibt immer noch Softwareentwicklungen, bei denen keine Modellierung verwendet wird. Au- ßerdem werden bei vielen Entwicklungen zwar zu Anfang Modelle erstellt, diese werden aber in späteren Phasen nicht wirklich genutzt und spielen nur eine unter- geordnete Rolle.

Im Laufe eines Softwareentwicklungsprozesses entstehen verschiedene Arten von Modellen. In den meisten Fällen wird zunächst die Realität in Form eines Anfor- derungsmodells abstrahiert. Danach wird das Anforderungsmodell nach und nach wieder konkretisiert, über diverse Konstruktionsmodelle bis hin zum fertigen Pro- grammcode². In den meisten Fällen verlieren die Modelle ihre Bedeutung jedoch mit dem Beginn der Implementierung. Sobald mit der Programmierung angefangen wird, gilt der Code als wichtigstes Artefakt. Es existieren zwar häufig noch konkrete Modelle des Programmcodes, diese sind jedoch meistens wenig abstrakt und bil- den den Code eins zu eins ab. Dadurch dienen sie lediglich als Dokumentation. Au- ßerdem werden selbst diese Modelle nach Änderungen im Sourcecode häufig nicht angepasst und veralten.

Auch Transformationen im Allgemeinen und Modelltransformationen im Beson- deren sind in der Softwaretechnik nichts Neues. Besonders Programmtransforma- tionen werden seit langem erforscht und teilweise auch erfolgreich eingesetzt. Sie werden allerdings in den meisten Fällen auf einem sehr konkreten Level durchge- führt.

MD* wird von Modellen angetrieben, d.h. Modelle und deren Transformation bil- den den Kern der Entwicklung. Die modellgetriebene Softwareentwicklung betont

2Programmcode wird in diese Arbeit ebenfalls als Modell angesehen.

daher nicht nur die Erstellung, sondern auch die Nutzung von Modellen, was im- pliziert, dass Modelle ständig aktualisiert und konsistent gehalten werden. BeiMD*

sind Modelle nicht nur Dokumentation, sondern über alle Phasen hinweg ein wichti- ger Bestandteil der Software. Außerdem sind die Modelle bei der modellgetriebenen Softwareentwicklung häufig sehr abstrakt und betreffen eher die Funktionen und das Verhalten einer Software. Dadurch können die Modelltransformationen inMD*

ebenfalls auf einer abstrakteren Ebene durchgeführt werden. Der Abstraktionsgrad misst hierbei den Abstand vom jeweiligen Modell zum Programmcode – je näher ein Modell am Code ist, umso weniger abstrakt ist es.

MD*ist keine bahnbrechende neue Erfindung, sondern verbindet lediglich verschie- dene bereits bekannte Vorgehensweisen auf neue Art miteinander und spricht Mo- dellen und Modelltransformationen eine wesentlich höhere Bedeutung zu als ande- re Entwicklungsansätze. Die modellgetriebene Softwareentwicklung ist also keine Revolution, sondern eher ein evolutionärer Schritt oder anders formuliert „die na- türliche Fortsetzung der Programmierung, wie wir sie heute kennen“ [SV05].

2.2 MD*-Artfakte

In diesem Unterkapitel werden die drei wichtigsten Artefakte für die modellgetrie- bene Entwicklung kurz vorgestellt. Leider haben die Begriffe in verschiedenen tech- nologischen Bereichen jeweils unterschiedliche, etwas abgewandelte Bedeutungen.

Im Folgenden wird daher versucht, Definitionen für die Artefakte zu präsentieren, die sowohl für diese Arbeit als auch fürMD*im Allgemeinen passend und eindeutig sind.

2.2.1 Modell

Das wichtigste Artefakt bei der modellgetriebenen Softwareentwicklung sind Mo- delle. Die folgende Definition bietet eine Erklärung des BegriffsModell:

„Ein Modell ist ein zielgerichtetes Abbild eines Systems, das zum einen ähnliche Beobachtungen und Aussagen ermöglicht wie dieses System und zum anderen diese Realität durch Abstraktion auf die je- weils problembezogen relevanten Aspekte vereinfacht.“ [Win00]

Ein Modell beschreibt also im Allgemeinen einen Teil der Realität aus einer bestimm- ten Perspektive. Konkretisiert für MD* heißt das, ein Modell beschreibt einen Teil einer Software oder einen Teil eines Anwendungsbereichs, für den eine Software er- stellt werden soll, aus einer bestimmten Perspektive.

Die Perspektive für ein Modell setzt sich aus verschiedenen Aspekten zusammen.

Ein Aspekt für die Perspektive ist der Abstraktionsgrad. Modelle können unter- schiedlich abstrakt sein. Ob ein Modell abstrakt ist bzw. wie abstrakt es ist, kann man laut Stuart Kent [Ken02] nur in Bezug auf ein anderes Modell feststellen. Ein UML-Modell, das den Programmcode relativ genau abbildet, ist z.B. abstrakter als der Programmcode selbst, aber weniger abstrakt als einUML-Modell das lediglich grob das Verhalten des Systems beschreibt. Weitere Aspekte für die Perspektive ei- ner Software sind z.B. derAnwendungsbereich, aus dem die Software kommt, oder dieSicht, aus der die Software beschrieben wird, z.B. Datenfluss, Kontrollfluss, Zu- standsübergänge, . . .

Stuart Kent veranschaulicht den Begriff der Perspektive mit einem Punkt in einem n-dimensionalen Raum. Ein Modell hat verschiedene Dimensionen (= Aspekte) und in jeder dieser Dimensionen hat das Modell eine bestimmte Position. Die Kombi- nation dieser Positionen bilden einen Punkt im n-dimensionalen Raum und das ist die Perspektive des Modells. Wenn man ein Modell einer Software erstellen möchte, muss man also zunächst einmal die Perspektive des Modells festlegen, indem man bestimmt, mit welchen Dimensionen sich das Modell befasst und wo in den einzel- nen Dimensionen sich das Modell befindet. Eine Perspektive, die die drei im vorigen Abschnitt beschriebenen Aspekte beinhaltet, hätte z.B. die Dimensionn = 3.

Ein Modell kann prinzipiell in einer beliebigen Modellierungssprache beschrieben werden. Im Rahmen von modellgetriebener Softwareentwicklung werden zwar oft grafische Modelleverwendet, es sind jedoch auch textuelle Modelle möglich. Die Auswahl der Sprache sollte sich idealerweise nach ihrer Eignung für die zu beschrei- bende Perspektive richten. In der Praxis wird diese Frage aber oft davon bestimmt, ob für die Modellierungssprache geeignete Werkzeuge zur Verfügung stehen oder welche Modellierungssprache der momentane Standard in diesem Bereich ist. Der anerkannte Standard zur Beschreibung von visuellen Modellen ist zurzeit dieUni- fied Modelling Language (UML)[UML05], insbesondereUML-Klassendiagramme undUML-Objektdiagramme, aber auch dynamische Diagrammarten. Zur Beschrei- bung von textuellen Modellen gibt es keinen speziellen Standard, aber zumindest anerkannte Sprachen.

2.2.2 Metamodell

Ein weiteres wichtiges Artefakt beiMD*sind Metamodelle. Die folgende Definition erläutert den BegriffMetamodell:

„Ein Metamodell ist die Beschreibung einer Modellierung, die die ver- wendeten Modellierungskonzepte, d.h. die zur Modellierung verwen- deten Sprachmittel, unabhängig von ihrer konkreten Notation, durch ihre abstrakte Syntax, verdeutlicht.“

Diese Definition stammt aus der Dissertation von Andreas Winter [Win00], wurde aber etwas abgewandelt.Winterunterscheidet bei einem Metamodell zwei Teile, das Meta-Aktivitätsmodell und das Metaschema. In dieser Arbeit meint Metamodell je- doch nur den zweiten Teil Metaschema, daher wird die Definition des Begriffs Me- taschema hier als Definition für den Begriff Metamodell benutzt.

Ein Metamodell ist ein Modell für ein Modell. Es beschreibt, aus welchen Bestand- teilen ein Modell besteht und welche Beziehungen diese Bestandteile zueinander haben können. Das Metamodell beschreibt jedoch nicht, wie diese Bestandteile und die jeweiligen Beziehungen dargestellt werden. Metamodell und Modell stehen in einer Klasse-Instanz-Beziehung zueinander, d.h. jedes Modell ist die Instanz eines Metamodells. Ein Modell hat in der Regel nur ein Metamodell, aus einem Metamo- dell können jedoch beliebig viele Modelle entstehen.

Metamodelle können genau wie Modelletextuelloder visuellbeschrieben werden.

Der Standard zur Beschreibung von visuellen Metamodellen ist momentan dieMe- ta Object Facility (MOF)[MOF05]. Die MOFbeschreibt eine Metadatenarchitektur und spezifiziert das FormatXML Metadata Interchange (XMI) für den Austausch von Metadaten. Zur Beschreibung von textuellen Metamodellen gibt es zwar keinen festen Standard, aber anerkannte Sprachen.

Für ausführlichere Informationen zum Artefakt Metamodell siehe Kapitel 3.1.3.

2.2.3 Modelltransformation

Das letzte wichtige Artefakt für die modellgetriebene Entwicklung sind Modell- transformationen. Die folgende Definition erklärt den Begriff Modelltransforma- tion:

„A transformation is the [. . . ] generation of a target model from a source model, according to a transformation definition.“ [KWB03]

Eine Modelltransformation transformiert ein Quellmodell auf der linken Seite (left-hand side, LHS)nach bestimmten, festgelegten Vorgaben in einZielmodell auf der rechten Seite (right-hand side, RHS). Transformationen können aus mehreren Transformationsschritten bestehen und manuell, halbautomatisch oder automatisch durchgeführt werden.

Bei einigen MD*-Ansätzen wird zwischen Modell-zu-Modell-Transformationen (Model2ModelTransformation) und Modell-zu-Code- bzw. Modell-zu-Plattform- Transformation (Model2Platform)unterschieden. In der vorliegenden Arbeit wird diese Unterscheidung nicht gemacht.

Obwohl verschiedene Ansätze mit unterschiedlichen Leistungsmerkmalen existie- ren, gibt es noch keine wohldefinierte Standardsprache für die Beschreibung von Modelltransformationen. Allerdings gibt es einen Request for Proposal (RFP)der OMGfür eine Modelltransformationssprache, genanntQuery/View/Transformation (QVT)[Obj02].

Für weiterführende Informationen zum Artefakt Modelltransformation siehe Kapi- tel 3.

2.3 MD*-Ansätze

Es existieren verschiedene modellgetriebene Softwareentwicklungsansätze, die alle sehr unterschiedlich an das Thema herangehen. Drei dieser Ansätze werden in die- sem Unterkapitel erläutert und miteinander verglichen.

2.3.1 Model Driven Architecture

Model Driven Architecture (MDA)war der erste und ist wohl auch der bekanntes- te Ansatz für modellgetriebene Softwareentwicklung. Er ist eine Vision derObject Management Group (OMG)[Obj02].

Bei der MDA wird zunächst ein plattformunabhängiges Modell (Platform Inde- pendent Model, PIM)erstellt. DasPIMhat einen hohen Abstraktionsgrad und be- schreibt das System aus Sicht des Anwenders – unabhängig von der Implementie- rung. Danach werden aus demPIMein oder mehrereplattformabhängige Modelle (Platform Specific Model, PSM) generiert – eines für jede unterstützte Zielplatt- form. EinPSMhat einen geringeren Abstraktionsgrad als dasPIMund berücksich- tigt die Details der verwendeten Technologie. Sowohl die Transformation von einem PIM in einPSM (PIM2PSM) als auch die Transformation von einem PSMin Code (PSM2Code) soll automatisch von Tools durchgeführt werden. Und auch eine auto- matische Rücktransformation vom Programmcode in einPSM(Code2PSM) und von einemPSMin einPIM(PSM2PIM) soll möglich sein. Außerdem sollen Transforma- tionen zwischen verschiedenenPSMs und unterschiedlichen Sourcecodes mit Hilfe von so genannten Brücken (bridges) ebenfalls unterstützt werden. Eine Bridge ist eine Transformation, die ein Artefakt in der MDA automatisch in ein anderes Arte- fakt der gleichen Ebene überführt. Die MDAwill also ein Roundtrip Engineering ermöglichen. Abbildung 1 verdeutlicht die zuvor beschriebenen Möglichkeiten. In neueren Ansätzen spricht dieOMGnur noch von Transformationen, nicht mehr von PIMundPSM. Bekannt ist der Ansatz im Moment allerdings noch mit genau diesen Schlagworten.

Abbildung 1: Model Driven Architecture [KWB03]

Durch das beschriebene Vorgehen will die MDA die Funktionalität eines Systems von der Implementierung trennen. Fachliche und technische Aspekte können so an- geblich unabhängig voneinander weiterentwickelt werden, und es sollen plattform- unabhängige Systeme entstehen. Hauptziele der MDA sind dementsprechend die Portabilität und Interoperabilität der zu entwickelnden Software. Es wird ein Fra- mework beschrieben, das so allgemein gehalten sein soll, dass es für jede beliebige Softwareentwicklung eingesetzt werden kann.

Als Modellierungssprache für Modelle setzt dieMDAdieUMLein, für Metamodel- le dieMOF. Für die Spezifikation von Modelltransformationen gibt es noch keinen Standard. Das RFPder OMG (siehe Abschnitt 2.2.3) wird hier aber bestimmt noch eine Rolle spielen.

Viele Teile derMDA-Vision sind in der Praxis (noch) nicht umsetzbar. Es gibt zwar bereits Tools, die in der Lage sind, automatisch Programmcode aus einemPSMzu generieren. DiesesPSMist dann jedoch häufig wenig abstrakt, und außerdem ist oft noch manuelles Eingreifen erforderlich. Der komplizierteste Schritt bei derMDAist jedoch die automatische Transformation von einem PIM in ein PSM. Obwohl ver- schiedene Ansätze existieren, gibt es noch keinen Standard zur Spezifikation der Transformationen, geschweige denn Tools, die diese Transformation automatisch durchführen können.

Für weitere Informationen zuMDAsiehe [Fra03, KWB03, MSUW04].

2.3.2 Model Driven Engineering

Model Driven Engineering (MDE) ist eher ein konzeptionelles Framework. Ver- schiedene Personen beschreiben eine Sammlung von Ideen für die modellgetriebene Softwareentwicklung. Sie diskutieren, welche Grundlagen es gibt, was heute bereits möglich ist und was es noch geben müsste, um dieMDA-Vision zu verwirklichen.

Abbildung 2: Model Driven Engineering

Ein bekannter Vertreter desMDEsist Jean-Marie Favre aus Frankreich. Er beschreibt in Bezug aufMDEverschiedeneTechnological Spaces (TSs), wie z.B. die Graphen- theorie oder den Bereich der Datenbanken (siehe hierzu Abbildung 2). Angelehnt an MOF[MOF05] visualisiert er dieTSs in Form von Pyramiden. Alle von ihm beschrie- benen TSs arbeiten mit den Konzepten Modell, Metamodell und Transformation.

Allerdings haben die Begriffe in den verschiedenen Bereichen teilweise unterschied- liche Bedeutungen.

DieMDAist für Favre lediglich ein weitererTS. Aufgabe derMDEist es seiner Mei- nung nach, alleTSs zu unterstützen und die verschiedenen Bereiche miteinander zu verbinden. Eine Transformation ist laut Favre eine Brücke zwischen verschiedenen TSs, bezogen auf seine Analogie also eine Verbindung von einer Pyramide zu einer anderen: „An important aspect of MDE ist the emphasis it puts on bridges between technological spaces, and on the integration of bodies of knowledge developed by different research communities.“[Fav04] Die verschiedenen Bereiche haben zwar alle ein Austauschformat bzw. eine Transformationssprache – es fehlt jedoch ein gemein- sames generelles Austauschformat.

Die Ideen derMDEsind wesentlich umfassender als die derMDA, die Informatio- nen bleiben jedoch sehr abstrakt. Es werden eigentlich nur Grundlagen aus verschie- denen Bereichen zusammengefasst und erläutert. Einen festgelegten MDE-Prozess gibt es nicht.

Ein weiterer bekannter MDE-Vertreter ist Stuart Kent aus Großbritannien. Kent be- schreibt in seinem Papier „Model Driven Engineering“ viele Grundlagen zu den Themen Modelle, Metamodelle und Transformationen [Ken02]. Teile des Unterka- pitels 2.2 stammen aus diesem Papier.

Für mehr Informationen zuMDEsiehe [MDE05].

2.3.3 Model Driven Software Development

Model Driven Software Development (MDSD)ist ein eher praxisorientierter Soft- wareentwicklungsansatz. Eine weitere gängige, aber auch ungenauere Bezeichnung hierfür ist Model Driven Development (MDD), in dieser Arbeit wird jedoch der BegriffMDSDverwendet.

MDSD verbindet Teile der MDA-Vision mit verschiedenen anderen Ansätzen zur Softwareentwicklung. Seinen Ursprung hat der Ansatz in der Entwicklung von Soft- warefamilien/Produktlinien (product line engineering) und dies ist auch der Be- reich, in dem der Entwicklungsansatz heute hauptsächlich eingesetzt wird. Neu im Vergleich zum klassischen Vorgehen ist hier jedoch eine Agile Softwareentwicklung (agile software engineering) –MDSD versucht Software zu entwickeln, die so früh wie möglich vom Anwender validiert werden kann. Der Ansatz setzt darüber hin- aus auf eine Domänenspezifische Entwicklung (domain specific engineering), d.h.

Ausgangspunkt für die Modellierung beiMDSDist immer eine Domäne.

DerMDSD-Ansatz geht die modellgetriebene Entwicklung sehr praxisorientiert an.

Der Programmcode einer Software wird in drei verschiedene Teile geteilt:generier- ter,schematischerundindividueller Sourcecode(siehe hierzu auch Abbildung 3).

Der generierte Code ist der Teil einer Software, der für alle Mitglieder einer Software- familie identisch ist und automatisch aus der Entwicklungsumgebung erzeugt wird.

Der schematische Sourcecode ist der Anteil, der zwar nicht für alle Mitglieder der Softwarefamilie identisch, aber zumindest semantisch gleich ist. Der Code ist an- wendungsspezifisch verschieden und wird per Hand erstellt.

Abbildung 3: Model Driven Software Development

Modellgetrieben entwickelt wird lediglich der schematische Teil des Programmco- des. Dieser schematische Teil der Software soll automatisch aus einem domänenspe-

zifischen Anwendungsmodell in die Programmiersprachenkonstrukte der Zielplatt- form transformiert werden (= Model-zu-Code-Transformation). Es wird also nicht automatisch der gesamte Programmcode aus einem oder mehreren Modellen gene- riert, sondern nur der Teil, der sich heutzutage auch schon zuverlässig automatisch generieren lässt. Darüber hinaus verlangtMDSDlediglich ein Forward Engineering und kein Roundtrip Engineering, da es im Allgemeinen nicht möglich ist, nach einer manuellen Änderung am generierten Code das Modell automatisch konsistent zu halten.

BeiMDSD wird von derMDA-Vision einiges weggelassen, um einen in der Praxis tauglichen Ansatz zu erhalten. Angeblich entsteht durch diese Art der Entwicklung ein hohes Potential für die Automatisierung der Softwareentwicklung, wodurch sich die Produktivität steigern lässt und darüber hinaus Wartbarkeit und Qualität verbes- sert werden.

Die treibenden Personen hinterMDSDsind unter anderem Jorn Bettin aus Neusee- land [Sof05] und Markus Völter aus Deutschland [Voe05, SV05].

Für weiterführende Informationen zuMDSDsiehe auch [MDS05].

2.3.4 Bewertung und Vergleich der Ansätze

Das Bild vonMD*in der Öffentlichkeit wird hauptsächlich von derMDAgeprägt, da sie der erste modellgetriebene Entwicklungsansatz war und vergleichsweise schnell einen hohen Bekanntheitsgrad erreicht hat. Leider überschattet die MDA dadurch andere existente Ansätze. Allerdings beziehen sich alle anderen Entwicklungsansät- ze in irgendeiner Form auf die MDA, und wenn es nur dazu dient, sich von ihr abzugrenzen. Tabelle 1 stellt die unterschiedlichen Eigenschaften der verschiedenen MD*-Ansätze noch einmal gegenüber.

In der Einleitung für diese Arbeit wurdeMD*folgendermaßen definiert:

MD* beschreibt Ansätze für die Softwareentwicklung, bei denen die Erstellung und Nutzung sowie die (halbautomatische oder automati- sche) Transformation von Modellen in den Vordergrund gestellt wird.

Im Folgenden werden die drei vorgestellten Ansätze in Bezug auf diese Definition bewertet und miteinander verglichen.

DieMDAist auf jeden Fall ein modellgetriebener Ansatz, da sie Modelle und deren Transformation in den Mittelpunkt der Entwicklung stellt. Sie betrachtet das Thema MD* top-down und beschreibt, wie eine modellgetriebene Entwicklung aussehen könnte. Doch leider ist dieMDAzurzeit nur eineVision, da dem Ansatz einfach zu viele Grundlagen fehlen und lediglich Teile davon umgesetzt werden können.

NameMDAMDEMDSD ArtvisionärerAnsatzkonzeptionellerAnsatzpraktischerAnsatz HerkunftOMGJean-MarieFavre,StuartKentProduktlinienentwicklung BekannteVertreterOMGJean-MarieFavre,StuartKentJornBettin,MarkusVölter HauptzieleInteroperabilität,PortabilitätnichtfestgelegtProduktivitätssteigerung,bessere QualitätundWartbarkeit ModellePIM,PSM(evtl.mehrere), ProgrammcodenichtfestgelegtAnwendungsmodell(PIM), Programmcode Modellierungssprache fürModelleUMLnichtfestgelegtnichtzwingendfestgelegt Modellierungssprache fürMetamodelleMOFnichtfestgelegtnichtzwingendfestgelegt TransformationenPIM2PSM,PSM2Code, PSM2PIM,Code2PSMBrückenzwischenTSsPIM2Code SprachefürModell- transformationenkeinekonkreteAngabe, skizziertdurchQVTkeineAngabekeineAngabe EngineeringRoundtripEngineeringnichtfestgelegtForwardEngineering

Tabelle 1: Übersicht über die MD*-Ansätze

Der Kern desMDE-Ansatzes sind ebenfalls die Erstellung, Nutzung und Transfor- mation von Modellen. Er betrachtet die modellgetriebene Entwicklung allerdings genau andersherum, d.h.bottom-up. Durch die Erforschung von Grundlagen wird nach und nach ein Konzept für die modellgetriebene Softwareentwicklung aufge- baut. MDE ist zurzeit allerdings ebenfalls nur teilweise einsetzbar, da bisher nur Grundlagenwissen existiert und noch keine präzise Vorgehensweise.

MDSDist nach der Definition in dieser Arbeit eigentlich gar kein wirklicher modell- getriebener Softwareentwicklungsansatz. Es werden zwar Modelle erstellt und auch in eingeschränktem Maße transformiert, die Modelle treiben die Entwicklung jedoch nicht wirklich an. Positiv ist beiMDSDallerdings der Gedanke, neue Techniken, die noch nicht fertig sind, so schnell wie möglich trotzdem teilweise einzusetzen.

Abbildung 4 visualisiert noch einmal die Positionen der verschiedenen MD*- Ansätze.

Abbildung 4: Vergleich derMD*-Ansätze

Leider gibt es noch kein wohldefiniertes und allgemein anerkanntes Vorgehensmo- dell für die modellgetriebene Softwareentwicklung. Die bekannten MD*-Ansätze werden meistens in natürlicher Sprache beschrieben und enthalten höchstens noch einige Diagramme. Die wenigen existenten präziseren Beschreibungen, beziehen sich auf sehr spezielle Konzepte, sind aber nicht allgemein gültig.

Was man bräuchte, wäre eine Mischung aus den bereits bestehenden Ansätzen. Die- ser Entwicklungsansatz müsste Erkenntnisse vonMDAundMDEkombinieren, d.h.

die Vision derMDAmit Hilfe der Grundlagen derMDEnach und nach in die Rea- lität umsetzen. Wünschenswert wäre es auch, wenn der jeweils aktuelle Stand des Ansatzes in der Praxis einsetzbar wäre. Der fettgedruckte Kreis in Abbildung 4 vi- sualisiert die Position dieses Ansatzes.

3 Eigenschaften von

Modelltransformationsansätzen

Das Artefakt Modelltransformation allgemein gültig zu beschreiben ist nicht ein- fach. Die einzige generelle Aussage, die man über eine Modelltransformation ma- chen kann, ist, dass sie „ein Quellmodell in ein Zielmodell transformieren können soll“. Da es verschiedenste Anforderungen an sowie Vorgehensweisen und Ziele für Modelltransformationsansätze gibt, wäre jede genauere Aussage schon zu speziell und würde die Möglichkeiten für solch einen Ansatz einschränken. Daher wird das Artefakt Modelltransformation in dieser Arbeitinduktiverläutert, indemverschie- dene Eigenschaften für Modelltransformationsansätze beschrieben werden. Ein konkreter Modelltransformationsansatz besteht aus einer ganz bestimmten Kombi- nation dieser Eigenschaften. Im nächsten Kapitel werden dann verschiedene konkre- te Modelltransformationsansätze auf diese Eigenschaften hin untersucht und mitein- ander verglichen.

Die erläuterten Eigenschaften stammen zum Teil aus den im Folgenden kurz vorge- stellten Papieren. Teilweise stammen sie auch aus den in Kapitel??zitierten, spezi- fischen Arbeiten zu den jeweils betrachteten Ansätzen.

Krysztof Czarneckiund Simon Helsenerstellen in ihrem Papier „Classification of Model Transformation Approaches“ [CH03] eine Taxonomie zur Klassifikation ver- schiedener Modelltransformationsansätze. Sie beschreiben Eigenschaften von Trans- formationen und erarbeiten eine Kategorisierung für Transformationsansätze. Czar- necki und Helsen zählen zu Anfang die Modelltransformationsansätze auf, auf de- nen ihre Untersuchung basiert, diese werden jedoch nicht genauer vorgestellt. Zu den Eigenschaften und Kategorien werden beispielhaft konkrete Ansätze genannt.

Eine vollständige Abbildung zwischen Transformationsansätzen sowie Eigenschaf- ten und Kategorien gibt es jedoch nicht.

Jonne van Wijngaarden und Eelco Visser beschreiben in ihrem Papier „Program Transformation Mechanics. A Classification of Mechanisms for Program Transforma- tion with a Survey of Existing Transformation Systems“ [WV03] zunächst verschie- dene Eigenschaften von Transformationsansätzen. Sie beziehen sich hierbei speziell auf Programmtransformationen, die Eigenschaften lassen sich jedoch auf Modell- transformationen im Allgemeinen übertragen³. Danach untersuchen sie verschiede- ne Transformationsansätze auf die zuvor beschriebenen Eigenschaften. Van Wijn- gaarden und Visser gehen dabei ebenfalls von Programmtransformationen aus. Hier lassen sich jedoch nicht alle Ansätze für Modelltransformationen im Allgemeinen

3Programmcode wird in diese Arbeit zwar als Modell angesehen, eine Modelltransformation ist jedoch meistens genereller als eine Programmtransformation.

verwenden, da einige von ihnen zu speziell sind. Im Rahmen dieser Arbeit werden daher nur die Ansätze beachtet, die für Modelltransformationen einsetzbar sind.

Der bereits erwähnte Request for Proposal derOMG„Request for Proposal: MOF 2.0 Query / Views / Transformations RFP“ [Obj02] beschreibt sowohl verbindliche als auch optionale Anforderungen an einen möglichen Modelltransformationsansatz.

Alexander KönigundAndy Schürr vergleichen in ihrer Arbeit „Multi-Domain In- tegration with MOF and extended Triple Graph Grammars“ [KS05] verschiedene Ansätze in Bezug auf genau diese Anforderungen. Sie führen ihre Ergebnisse jedoch nur kurz aus und beschreiben sie hauptsächlich in Form einer Tabelle.

Die Eigenschaften können sich auf unterschiedliche Teile des Artefakts Modelltrans- formation beziehen. Daher werden die Eigenschaften kategorisiert und jede dieser Kategorien in einem eigenen Unterkapitel erläutert. Da ein Modelltransformations- ansatz eine Sprache darstellt, werden zunächst Eigenschaften erläutert, die sich auf Sprachen im Allgemeinen beziehen (siehe Abschnitt 3.1). Daraufhin folgen Eigen- schaften von Modelltransformationssprachen im Besonderen (siehe Abschnitt 3.2).

Eine Transformation kann aus mehreren Schritten bestehen, wobei ein Schritt die Anwendung einer Transformationsregeln ist. Daher werden sowohl Eigenschaften von kompletten Transformationen beschrieben (siehe Abschnitt 3.3), als auch Eigen- schaften von einzelnen Transformationsregeln (siehe Abschnitt 3.4). Die Transfor- mationsstrategie beschäftigt sich damit, wie oft und in welcher Reihenfolge Trans- formationsschritte durchgeführt werden. Eigenschaften der Kategorie Transforma- tionsstrategie werden in Abschnitt 3.5 beschrieben. Zuletzt folgen Qualitätseigen- schaften für Modelltransformationsansätze (siehe Abschnitt 3.6), sowie deren zuge- hörige Tools (siehe Abschnitt 3.7).

Zu jeder Eigenschaft gibt es zunächst eine Erläuterung. Außerdem werden in Klam- mern mit einem Pfeil die Werte angegeben, die später für die möglichen Optionen in die Eigenschaftstabellen in Kapitel??eingetragen werden (→Wert). Danach wird be- merkt, ob es imRFPfürQVT[Obj02] eine Aussage über die behandelte Eigenschaft gibt oder nicht bzw. welche Aussage der RFP über die entsprechende Eigenschaft macht.

3.1 Eigenschaften von Sprachen

In diesem Abschnitt werden einige grundlegende Eigenschaften von Sprachen im Allgemeinen vorgestellt, die für das Verständnis von Modelltransformationsansät- zen sowie den Vergleich verschiedener Ansätze hilfreich sind.

Man muss sich klar machen, dass man es bei einer Modelltransformation mit bis zu drei Sprachen gleichzeitig zu tun hat: der Transformationssprache selbst, der

Quellmodellsprache und der Zielmodellsprache. Daher müssen die Eigenschaften in diesem Unterkapitel für alle drei Sprachen untersucht werden.

3.1.1 Datenstruktur

Eine Sprache operiert auf einerDatenstruktur. Die meisten Sprachen operieren auf Strings(→String) oder aufGraphen(→Graph). Diese beiden Datenstrukturen bil- den die Grundlage für zwei verschiedene Technological Spaces (vergleiche Kapitel 2.3.2). Ein String besteht aus einer Menge von Symbolen. Ein Graph besteht aus einer Menge von Knoten, die durch Kanten miteinander verbunden sind. Strings eignen sich gut, um Programmiersprachen zu beschreiben. Graphen sind hingegen gut ge- eignet, um Diagramme darzustellen.

DerRFP fürQVT macht keine Aussage über die Datenstruktur einer Modelltrans- formationssprache oder die der Quell- und Zielmodellsprache. [Obj02]

3.1.2 konkrete Syntax

Diekonkrete Syntaxeiner Sprache, auchNotationgenannt, beschreibt, wie die Ele- mente der Sprache repräsentiert werden. Die konkrete Syntax einer Sprache ist in den meisten Fällentextuell(→textuell) odervisuell(→visuell). Textuelle Sprachen operieren im Allgemeinen auf Strings, visuelle auf Graphen. Eine Sprache kann aber auch einehybride(→hybrid) konkrete Syntax besitzen, d.h. eine Mischung aus tex- tuellen und visuellen Anteilen. Außerdem kann eine Sprache auch mehrere konkrete Syntaxen haben, z.B. eine textuelle und eine visuelle (→textuell+visuell).

DerRFPfürQVTsagt nichts über die konkreten Syntaxen eines Modelltransforma- tionsansatzes sowie der Quell- und der Zielmodellsprache aus. [Obj02]

3.1.3 abstrakte Syntax

Eine Sprache wird durch eineabstrakte Syntaxdefiniert, d.h. mit Hilfe der abstrak- ten Syntax kann man alle gültigen Elemente einer Sprache erzeugen. Ein gültiges Element einer Sprache bezeichnet man als Ableitung oder Modell. Die abstrakte Syntax wird auch alsMetamodellbezeichnet (siehe hierzu Kapitel 2.2.2).

Die abstrakte Syntax für textuelle Sprachen wird im Allgemeinen als Grammatik bezeichnet. Eine Ableitung einer textuellen Sprache heißtWortund besteht aus einer Menge von Strings. Das Metamodell für eine visuelle Sprache heißt Schema. Eine Ableitung eines Schemas heißtModellund besteht aus einer Menge von Graphen.

Abbildung 5: Modell und Metamodell

Ein konkretes Beispiel für eine Grammatik wäre dieJAVA-Sprachbeschreibung, ein JAVA-Programm wäre in diesem Fall ein Wort. Ein konkretes Beispiel für ein Schema wäre die UML-Spezifikation, ein UML-Diagramm wäre in diesem Fall ein Modell.

Doch auch dieJAVA-Sprachbeschreibung und die UML-Spezifikation haben wieder- um ein Metamodell: dieEBNFbzw. dieMOF. In Bezug auf dasJAVA-Programm und dasUML-Diagramm sind es Meta-Meta-Modelle. Abbildung 5 visualisiert noch ein- mal den Zusammenhang zwischen den genannten Begriffen in Bezug auf dieMOF Meta Data Architecture.

Der Zusammenhang zwischen Modell und Metamodell ist kompliziert und die Be- griffe lassen sich verschiedenen Artefakten auf unterschiedliche Arten zuordnen.

Teilweise kann man in einer Gegenüberstellung mehrerer Artefakte noch ein oder mehrere Ebenen nach unten und in den meisten Fällen beliebig viele Ebenen nach oben ergänzen.

Sofern die abstrakte Syntax eines Transformationsansatzes bekannt ist, wird sie in den Tabellen in Kapitel??vermerkt.

DerRFPfürQVT verlangt, dass sowohl die abstrakte Syntax einer Modelltransfor- mationssprache als auch die abstrakten Syntaxen der Quell- und der Zielmodellspra- che alsMOF-Metamodelle definiert sind. [Obj02]

3.1.4 Chomsky-Typ

Die Chomsky-Hierarchie unterscheidet abstrakte Syntaxen formaler Sprachen an- hand der Sprachen, die sie erzeugen. Es gibt vier verschiedene Typen:

• unbeschränkteabstrakte Syntax (→Typ 0)

• kontextsensitiveabstrakte Syntax (→Typ 1)

• kontextfreieabstrakte Syntax (→Typ 2)

• reguläreabstrakte Syntax (→Typ 3)

DerRFPfürQVT sagt nichts über den Chomsky-Typ einer Modelltransformations- sprache oder den der Quell- und Zielmodellsprache aus. [Obj02]

3.1.5 Paradigma

EinParadigma bezeichnet das Prinzip, das einer Sprache zugrunde liegt. Man un- terscheidet dabei deklarativ(→ deklarativ) und imperativ(→ imperativ). Eine de- klarative Sprache beschreibt, was zu tun ist. Eine imperative Sprache beschreibt, wie etwas zu tun ist. Es existieren auchhybride (→hybrid) Ansätze, d.h. Mischformen mit deklarativen und imperativen Anteilen.

Wichtige Ausprägungen des deklarativen Ansatzes sind das funktionale und das logischeParadigma, wichtige Ausprägungen des imperativen Ansatzes dasobjek- torientierteund dasprozedurale Paradigma. Diese Unterteilung kann noch weiter verfeinert werden. Die Transformationsansätze werden in den Eigenschaftentabellen nur in deklarativ, imperativ und hybrid unterschieden. Sofern genauere Informatio- nen über das Paradigma vorhanden sind, werden diese jedoch in den konkreten Beschreibungstexten genannt.

DerRFPfürQVTverlangt eine deklarative Modelltransformationssprache. Über die Paradigmen der Quell- und Zielmodellsprache sagt es nichts. [Obj02]

3.2 Eigenschaften von Modelltransformationssprachen

Eine Transformationssprache operiert auf Sprachen, d.h. sie transformiert ein Mo- dell einer Sprache in ein Modell einer anderen Sprache. Indirekt operiert die Mo- delltransformationssprache natürlich auf den Datenstrukturen der Quell- und Ziel- modellsprache. Im Folgenden werden Eigenschaften für Modelltransformationss- prachen im Besonderen beschrieben.

3.2.1 Modelltransformation

Damit eine Modelltransformationssprache ein Quellmodell in ein Zielmodell trans- formieren kann, muss sie eine Modelltransformation durchführen. Dies kann auf verschiedene Arten passieren: mit Hilfe eines Algorithmus (→ Algorithmus), mit Hilfe von Transformationsregeln (→ Regeln) oder mit einer Metamodelltransfor- mation (→ Metamodell), d.h. die abstrakte Syntax der Quellmodellsprache in die abstrakte Syntax der Zielmodellsprache überführen.

Eine Metamodelltransformation kannimplizit(→implizit) oder explizit(→expli- zit) passieren. Bei einer impliziten Vorgehensweise ist die Metamodelltransformati- on nicht auf den ersten Blick zu erkennen und versteckt sich hinter konkreten Trans- formationsregeln. Bei einer expliziten Vorgehensweise ist die Schematransformation deutlich zu erkennen. Der Übergang zwischen einer impliziten und einer expliziten Schematransformation ist fließend.

DerRFPfür QVT sagt nichts über die Art der Modelltransformation bei einer Mo- delltransformationssprache aus. [Obj02]

3.2.2 Anfragen

Eine Modelltransformationssprache sollte es ermöglichen, Anfragen an Modelle und/oder Modellelementezu stellen, um Informationen aus Modellen zu selektie- ren und zu filtern (→ja|nein). Das Ergebnis einer Anfrage kann ein einfacher Wert, aber auch ein (Teil-)Modell bzw. die Sicht auf ein Modell sein (siehe Abschnitt 3.2.3).

Der Übergang ist hier ebenfalls fließend.

Diese Eigenschaft muss sowohl für Quell- und Zielmodell als auch für Quell- und Zielmetamodell untersucht werden, da ein Modelltransformationsansatz für die Me- tamodelltransformation irgendwie an Informationen über Quell- und Zielmetamo- dell kommen muss.

DerRFP fürQVT verlangt, dass bei einem Modelltransformationsansatz Anfragen an ein Modell möglich sind. Er verlangt sogar eine spezielle Anfragesprache, deren abstrakte Syntax als MOF-Metamodell definiert sein muss. [Obj02]

3.2.3 Sichten

Ein Transformationsansatz sollte die Kreation von Sichten auf Modelle ermögli- chen, um Informationen zu filtern (→ ja|nein). Dies kann mit Hilfe einer Anfrage (siehe Abschnitt 3.2.2) passieren, aber auch durch eine Transformation.

Diese Eigenschaft muss sowohl für das Quell- als auch für das Zielmodell untersucht werden.

DerRFPfürQVT verlangt, dass die Kreation einer Sicht auf Modelle mit Hilfe des Modelltransformationsansatzes möglich ist. [Obj02]

3.3 Eigenschaften von Transformationen

In diesem Abschnitt werden Eigenschaften von Transformationen erläutert, d.h. Ei- genschaften, die sich auf die Anwendung einer oder mehrerer Transformationsre- geln beziehen.

3.3.1 Modell-Beziehung

Die Modell-Beziehung beschreibt, welchen Bezug das Quell- und das Zielmodell bei einer Transformation zueinander haben.

Wenn Quell- und Zielmodell in derselben Sprache geschrieben sind, so kann eine Transformation auch direkt auf dem Quellmodell ausgeführt werden. D.h. es gibt kein neues Zielmodell, sondern das Quellmodell ist gleichzeitig das Zielmodell (→ Quelle = Ziel). Wenn Quell- und Zielmodell in derselben Sprache geschrieben sind, braucht man eigentlich keine Metamodelltransformation.

Es kann aber auch zwei verschiedene Modelle geben (→ Quelle6=Ziel), d.h. das Quellmodell wird nicht verändert und die Änderungen werden an einem anderen Zielmodell vorgenommen. Hier gibt es zwei Möglichkeiten: Entweder die Transfor- mation erzeugt aus einem Quellmodell ein neues Zielmodell (→ neu). Oder die Transformation überträgt die Informationen aus dem Quellmodell in ein bereits be- stehendes Zielmodell, d.h. dasZielmodell wird verändert(→alt).

DerRFPfürQVTgeht generell davon aus, dass ein Modelltransformationsansatz auf zwei verschiedenen Modellen operiert. Die Fähigkeit, zusätzlich Transformationen direkt auf einem Quellmodell auszuführen, ist optional. [Obj02]

3.3.2 Ursprung

Nach van Wijngaarden und Visser beschreibt der Ursprung einer Transformation (von ihnen Richtung genannt), ob der Ausgangspunkt einer Transformation das Quellmodell oder das Zielmodell ist. Wenn das Quellmodell der Ursprung ist, han- delt es sich um einequellmodellgetriebenen(→Quelle) Transformation, wenn das Zielmodell der Ursprung ist, ist es einezielmodellgetriebenen(→Ziel) Transforma- tion. [WV03]

Bei einer quellmodellgetriebenen Transformation wird das Quellmodell traversiert und dabei werden Transformationsregeln angewandt, um das Zielmodell zu erstel- len oder zu verändern. Bei einer zielmodellgetriebenen Transformation wird das Zielmodell erstellt oder verändert, indem Anfragen an das Quellmodell gestellt wer- den, wenn es notwendig ist. Für quellmodellgetriebene Transformationen braucht

man definierte Transformationsregeln, für zielmodellgetriebene Transformationen Anfragen.

Der RFP für QVT sagt nichts Konkretes über den Ursprung einer Transformation aus. Es verlangt jedoch sowohl eine Sprache zur Definition von Transformationsre- geln als auch eine Sprache zur Spezifikation von Anfragen an Modelle. [Obj02]

3.3.3 Richtung

Czarnecki und Helsen unterscheiden in Bezug auf dieRichtung einer Transforma- tion zwischen unidirektional(→ unidirektional) und bidirektional (→ bidirektio- nal). Eine unidirektionale Transformation kann nur in eine Richtung ausgeführt wer- den, eine bidirektionale Transformation in beide Richtungen. Für eine bidirektiona- le Transformation können entweder direkt bidirektionale Transformationsregeln (→ 1Regel) oder jeweils zwei komplementäre unidirektionale Transformationsregeln (→ 2Regeln) aufgestellt werden. [CH03]

Bidirektionalität ist lediglich eine optionale Anforderung an QVT. Allerdings ver- langt der RFP für QVT eine deklarative Sprache und deklarative Regeln können meistens auch in der umgekehrten Richtung verwendet werden. [Obj02]

3.3.4 Umfang

Der Umfang einer Transformation beschreibt, welche(r) Teil(e) eines Modells von dieser Regel betroffen ist/sind. [WV03, CH03]

Van Wijngaarden und Visser beschreiben verschiedene Möglichkeiten für den Um- fang einer Transformationsregel. Der Transformationsumfang eines Modells kann entweder lokal (→ lokal) oder global (→ global) sein. Bei einem lokalen Umfang bezieht sich die Transformationsregel auf einen bestimmten Teil eines Modells, bei einem globalen Umfang bezieht sie sich auf mehrere Teile eines Modells oder sogar das ganze Modell.

Diese Eigenschaft muss sowohl für das Quellmodell als auch für das Zielmodell untersucht werden.

DerRFPfürQVTmacht keine Aussage über den Umfang des Quell- und Zielmodells bei einer Transformation. [Obj02]

3.4 Eigenschaften von Transformationsregeln

In diesem Abschnitt werden Eigenschaften beschrieben, die sich auf einzelne Trans- formationsregeln beziehen.

3.4.1 Parametrisierung

Parametrisierung heißt, dass einer Transformationsregelein oder mehrere externe Werte mitgegeben werden können, die bei der Transformation berücksichtigt wer- den (→ja|nein). Dies kann per Hand durch einen Benutzer (→manuell) oder auto- matisch (→automatisch) durch ein Tool geschehen. Zusätzliche Parameter erlauben die Konfiguration und das Tuning einer Transformationsregel. [CH03]

FürQVTist die Parametrisierung von Transformationsregeln optional. [Obj02]

3.5 Eigenschaften von Transformationsstrategien

Es gibt verschiedene Strategien zur Durchführung von Transformationen. Unter- schiedliche Ansätze haben diverse Kombinations- und Ausführungsmöglichkeiten für einzelne Transformationsregeln und komplette Transformationen. In diesem Ab- schnitt werden einige Eigenschaften vorgestellt, die mit dieser Transformationsstra- tegie zusammenhängen. Diese sind jedoch bei jedem Modelltransformationsansatz individuell verschieden und meistens sehr komplex. Außerdem hängen sie teilweise voneinander ab. Die komplexeren Zusammenhänge werden daher, soweit bekannt, bei der Beschreibung des jeweiligen Ansatzes erläutert.

3.5.1 Reihenfolge

EineReihenfolgeder Anwendung der Transformationsregeln kanndeterministisch (→deterministisch) oder nicht-deterministisch (→nicht deterministisch) sein. Bei einer deterministischen Sprache ist die Reihenfolge, in der die Transformationsre- geln ausgeführt werden, völlig egal – bei der Transformation kommt immer dasselbe Ergebnis heraus. Bei einer nicht-deterministischen Sprache ändert sich das Ergebnis, wenn die Reihenfolge der Transformationsregeln verändert wird.

DerRFPfür QVTmacht keine Aussage über eine Reihenfolge für die Anwendung von Transformationsregeln. [Obj02]

3.5.2 Inkrementalität

Inkrementalität meint, dass ein Benutzer Änderungen im Quellmodell schrittweise in ein bereits erstelltes Zielmodell transformieren kann (→ja|nein). D.h. der Benut- zer erstellt ein Quellmodell, transformiert es in ein Zielmodell, nimmt Änderungen am Quellmodell vor und kann diese wiederum in das Zielmodell transformieren.

Im RFP für QVT ist Inkrementalität lediglich eine optionale Anforderung für Mo- delltransformationsansätze. [Obj02]

3.6 Qualitätseigenschaften für Modelltransformationsansätze

Abgesehen von den zuvor beschriebenen konkreten Eigenschaften, besitzen die verschiedenen Modelltransformationssprachen auch Qualitätseigenschaften. Einige von ihnen werden im Folgenden beschrieben.

3.6.1 Verfolgbarkeit

Verfolgbarkeit bei einer Transformation meint, dass man nach Durchführung einer Transformation (oder sogar mehrerer Transformationen) nachvollziehen kann, was verändert wurde.

Transformationen können Verfolgbarkeit bieten, indem sieVerbindungen zwischen Quell- und Zielmodell speichern, die nach der Transformation abgerufen werden können (→ja|nein). Die entsprechenden Links können manuell(→manuell) oder automatisch(→automatisch) gesetzt werden.

Verfolgbarkeit ist für inkrementelle Transformationen (siehe Abschnitt 3.5.1) und für die Synchronisation zwischen Modellen notwendig. [CH03]

Verfolgbarkeit von Transformationen ist lediglich eine optionale Anforderung im RFPfürQVT. [Obj02]

3.6.2 Verifikation

Verifikationmeint die Prüfung einer Transformation auf Korrektheit. Ein Transfor- mationsansatz kann es dem Benutzer in gewissem Maße ermöglichen, eine Transfor- mationsspezifikation bereits während des Erstellens zu verifizieren (→ja|nein). D.h.

beispielsweise zu überprüfen, ob eine Transformation konform zu ihrer abstrakten Syntax ist und/oder ob sie ausführbar ist.

DerRFPfürQVTmacht keine Aussage über die Verifikation von Transformationen.

[Obj02]

3.6.3 Automatisierung

Automatisierung meint hier nicht die Nutzung von Tools, sondern eher, ob ein Transformationsansatz eine Transformation nach Eingabe aller benötigten Einga- ben automatisch durchführen kann, ohne Einwirkung von außen (→ja|nein). Dafür wird natürlich ein Tool benötigt, es ist aber nicht die Nutzung eines Tools im Allge- meinen gemeint.

Der RFP für QVT verlangt die Automatisierung von Transformationen. Dadurch verlangt er implizit auch nach einem Tool für einen Modelltransformationsansatz.

[Obj02]

3.7 Qualitätseigenschaften für Modelltransformationstools

Typische Qualitätsmaße für Software im Allgemeinen sind die Qualitätseigenschaf- ten aus der DIN ISO 9126 [DIN91]. Sie sollten auch für die Tools zu den Modell- transformationsansätzen gelten.

DieDIN-Normnennt folgende Qualitätseigenschaften für Software:

• Funktionalität

• Zuverlässigkeit

• Benutzbarkeit

• Effizienz

• Wartbarkeit

• Änderbarkeit

• Portabilität

Da die Bewertung dieser Eigenschaften sehr kompliziert ist, werden sie nicht in die Eigenschaftentabellen in Kapitel??übernommen.

DerRFPfürQVTsagt über diese Qualitätseigenschaften nichts aus. [Obj02]

4 Modelltransformationsansätze

In diesem Abschnitt werden sieben verschiedene Ansätze für Modelltransforma- tionen kurz vorgestellt. Die Modelltransformationsansätze wurden nach ihrem Be- kanntheitsgrad und ihrer derzeitigen Präsenz auf Konferenzen sowie in Artikeln und Büchern ausgewählt. Vier dieser Ansätze sind visuell und basieren auf Graphen:

ATL (siehe Abschnitt 4.1), BOTL (siehe Abschnitt 4.2), FUJABA (siehe Abschnitt 4.3) und MDI (siehe Abschnitt 4.4). Drei sind textuell und operieren auf Strings:

ASD+SFD(siehe Abschnitt 4.5),Stratego(siehe Abschnitt 4.6) undTXL(siehe Ab- schnitt 4.7). Die Ansätze werden auf die im vorigen Kapitel vorgestellten Eigenschaf- ten hin untersucht und miteinander verglichen.

Die Informationen hierzu stammen aus den in Kapitel 3 vorgestellten Papieren so- wie aus spezifischen Papieren für jeden Ansatz, die in den folgenden Abschnitten zitiert werden. Leider sind die Untersuchung der Ansätze auf die verschiedenen Ei- genschaften sowie deren Gegenüberstellung manchmal nicht vollständig, da viele Informationen aus den beschriebenen Quellen nicht ersichtlich waren.

Jeder Modelltransformationsansatz wird zunächst in Fließtext näher beschrieben.

Insofern eine aufschlussreiche Abbildung zu diesem Modelltransformationsansatz gefunden wurde, wird diese ebenfalls eingefügt und erläutert. Darüber hinaus gibt es zu jedem Transformationsansatz eine tabellarische Auflistung der in Kapitel 3 be- schriebenen Eigenschaften in Bezug auf den jeweiligen Ansatz. Die möglichen Werte für die Eigenschaften wurden ebenfalls im vorigen Kapitel beschrieben.

Wenn ein Ansatz eine bestimmte Fähigkeit nicht hat, wird dies in der Tabelle expli- zit vermerkt. Ein leeres Feld bedeutet, dass für diesen Modelltransformationsansatz keine Informationen über die betreffende Eigenschaft vorliegen. Sollten bei einem Transformationsansatz für eine Eigenschaft sämtliche Optionen möglich sein, steht in der Tabelle der Begriffe optional (→optional) bei einer ja/nein-Eigenschaft oder alles möglich (→ alles möglich) bei einer vielschichtigeren Eigenschaft. Wenn ein Modelltransformationsansatz eine Eigenschaft nur unter bestimmten Bedingungen hat, wird dies mit dem Begriff „bedingt“ hinter dem Wert deutlich gemacht.

4.1 ATLAS Transformation Language

DieATLAS Transformation Language (ATL)[BDJ⁺03, AI04] ist ein Modelltransfor- mationsansatz, der sich stark nach derMDAbzw. demRFPfürQVTrichtet und sich auch an der Idee der Technological Spaces orientiert (siehe hierzu Kapitel 2.3.2).ATL

wird von zwei Parteien entwickelt. Das Projektteam ATLantic dAta Systems (AT- LAS)derUniversität Nantesentwickelt eine freie Software für ATL, der Hauptver- treter ist hierJean Bézivin. DieTNI-Valiosys Companyentwickelt eine industrielle Version derATL-Software.

ATLwird durch die EntwicklungsumgebungATL Development Tooling (ADT)un- terstützt. ADT basiert auf demEclipse Modelling Framework (EMF) [EMF05], ei- nem Modellierungsframework und Codegenerator, mit dem sich aus strukturierten Modellen Quellcode generieren lässt.ADTbietet eine komplette Umgebung für die Entwicklung, das Testen und das Benutzen vonATL-Transformationen. Es ist Open- Source und steht auf der offiziellen Webseite von ATL[ATL05] zum Download be- reit.

ATL-Transformationsregeln werden in einer OCL-ähnlichen Schreibweise notiert.

Die abstrakte Syntax der Transformationsregeln ist alsMOF-Metamodell spezifiziert.

Es gibt zwei konkrete Syntaxen, eine textuelle und eine visuelle. Generell werden ATL-Transformationsregeln textuell notiert. Deklarative Regeln können jedoch zu- sätzlich grafisch repräsentiert werden. Alle Quell- und Ziel-(Meta-)Modelle müssen Instanzen vonMOF- oder Ecore-Metamodellen (einem Modelltyp des EMF) sein.

ATL-Transformationen bestehen aus drei Teilen, einem Header, Helfern und Regeln.

Der Header deklariert generelle Informationen, wie den Modulnamen, das Quell- Metamodell, das Ziel-Metamodell und potentielle Bibliotheken, die importiert wer- den müssen. Helfer sind Subroutinen, die benutzt werden um Redundanzen im Code zu vermeiden. Die Regeln bilden das Herz einer ATL-Transformation, sie be- schreiben wie aus den Quellmodell das Zielmodell erzeugt wird.

In ATL gibt es verschiedene Arten von Regeln: imperative und deklarative so- wie Mischformen, d.h. hybride Regeln. Sie unterscheiden sich in der Art, wie sie aufgerufen werden und wie sie ihr Ergebnis präsentieren. Eine Regel kann ein Quellmodell-Pattern (= InPattern), ein Zielmodell-Pattern (= OutPattern) und/oder einen imperativen Block (= ActionBlock) enthalten. Ein Quellmodell-Pattern bein- haltet eine Menge von Knoten des Quellmodells mit bestimmten Beziehungen zu- einander, d.h. eine Menge von Typen des Quellmodells verbunden mit Variablen- namen. Ein Zielmodell-Pattern beinhaltet eine Menge von Knoten aus dem Zielm- odell mit bestimmten Beziehungen zueinander, d.h. eine Menge von Typen des Zielmodells verbunden mit Variablennamen. Ein imperativer Block in einer ATL- Transformationsregel spezifiziert eine Sequenz von Instruktionen die nach der Er- stellung des Zielmodell-Patterns ausgeführt werden. Eine Regel kann entweder explizit aufgerufen werden (= called-rule) oder implizit durch einen Match eines Quellmodell-Patterns auf ein Fragment des Quellmodells (= matched-rule). Das Ergebnis der Ausführung einer Regel kann ein Zielmodell-Pattern sein oder der Aufruf einer imperativen Sektion oder beides zusammen. Eine Regel mit einem Quellmodell-Pattern und einem Zielmodell-Pattern wird deklarative Regel genannt,

Datenstruktur String + Graph

Konkrete Syntax textuell + visuell

Abstrakte Syntax MOF

Chomsky-Typ

Paradigma hybrid

Datenstruktur Quelle Konkrete Syntax Quelle

Abstrakte Syntax Quelle MOF

Chomsky-Typ Quelle Paradigma Quelle Datenstruktur Ziel Konkrete Syntax Ziel

Abstrakte Syntax Ziel MOF

Chomsky-Typ Ziel Paradigma Ziel

Modelltransformation Regeln

Anfragen Quelle ja

Anfragen Ziel ja, bedingt

Anfragen Quellmetamodell Anfragen Zielmetamodell

Sichten Quelle ja

Sichten Ziel ja

Modell-Beziehung Quelle6=Ziel, neu

Ursprung Quelle

Richtung unidirektional

Umfang Quelle alles möglich

Umfang Ziel alles möglich

Parametrisierung Reihenfolge

Inkrementalität nein

Verfolgbarkeit ja, automatisch

Verifikation Automatisierung

Tabelle 2: Eigenschaften von ATL

wenn sie keine imperative Sektion hat sogar voll deklarative Regel. Eine Regel mit ei- ner imperativen Sektion und ohne Zielmodell-Pattern ist eine imperative Regel bzw.

eine Prozedur. Alle anderen Kombinationen sind hybride Regeln. Eine Regel kann eine andere Regel beinhalten. Die neue Regel kann zusätzliche Elemente spezifizie- ren oder das Quellmodell-Pattern einschränken.

Die Ausführung einer ATL-Transformation erfordert mehrere Schritte. Wenn das Quellmodell als Text vorliegt wird es zunächst geparst und in ein anderes Modell transformiert, dass nach dem ATL-Metamodell definiert ist. Danach wird das neu entstandene Modell auf semantische Fehler überprüft und compiliert bzw. inter- pretiert. Daraufhin werden die Transformationsregeln ausgeführt, zuerst die called- Regeln, danach die matched-Regeln. Dann werden die Ziel-Elemente instanziiert und Bindings angebracht. Zum Schluss werden die imperativen Blöcke der Regel ausgeführt.

Während der Ausführung einer Transformation kann mit Hilfe vonOCL über das

Quellmodell sowie das Quell- und das Ziel-Metamodell navigiert werden. Eine Na- vigation über das Zielmodell ist erst nach Beendigung der Transformation möglich.

Anfragen sind in ATL ebenfalls möglich. Anfragen sind hier OCL-Ausdrücke, die primitive Datentypen, Modellelemente, Collections, Tupel oder eine Kombination dieser Artefakte zurückgeben können. Eine Anfrage kann über die Modellelemente navigieren und Anfrageoperationen auf sie stellen. Die Operationen können im Me- tamodell oder in der Anfrage definiert werden. Sichten sind in ATLnichts anderes als spezielle Transformationen. Sie können erzeugt werden, indem ein Quellmodell- Fragment durch einen boolschen Ausdruck gefiltert wird. Sichten können mit Hilfe von Verfolgbarkeitsinformationen aktualisiert werden.

Der Ursprung einer ATL-Transformation ist das Quellmodell und es entsteht eine neues Zielmodell. Die Transformationen sind unidirektional. Der Umfang für Quell- und Zielmodell kann sowohl lokal als auch global sein. Inkrementelle Transforma- tionen sind nicht möglich. Verfolgbarkeit wird in ATLdadurch erreicht, dass Lauf- zeitinformationen in einem weiteren Modell gespeichert werden, das auf einem spe- ziellen Metamodell basiert.

4.2 Bidirectional Object-oriented Transformation Language

Die Bidirectional Object-oriented Transformation Language (BOTL) [BM03a, BM03b, MB03] ist eine Sprache zur Spezifikation von Transformationen für objek- torientierte Modelle. Sie wird vonPeter Braunan derTU Münchenentwickelt.

BOTL-Transformationen können mit dem Tool ARgoUML4BOTL spezifiziert wer- den. ARgoUML [ARg05] ist ein in Java geschriebenes Open-Source CASE-Tool, mit dem man UML-Diagramme erstellen kann. ARgoUML4BOTL ist ein an BOTL angepasstes ArgoUML mit dem man BOTL-Metamodelle, -Modelle und - Transformationsregeln spezifizieren kann. ARgoUML4BOTL ist auf der offiziellen Webseite vonBOTL[BOT05] frei verfügbar.

Eine Transformationsregeln in BOTL besitzt ein Quellmodell-Pattern und ein Zielmodell-Pattern. Das Quellmodell-Pattern beschreibt wie ein Fragment des Quellmodells aussehen muss auf das die Transformationsregeln angewandt wer- den kann. Das Zielmodell-Pattern beschreibt, wie ein korrespondierendes Fragment im Zielmodell auszusehen hat. Bei Anwendung einer Transformationsregel wird im Quellmodell nach dem Quellmodell-Pattern gesucht und bei einem Match wird das gefundene Fragment im Quellmodell in ein Zielmodell-Fragment transformiert.

Die Suche nach einem Quellmodell-Fragment entspricht einer Teilgraphensuche auf einem Graphen. Anders als Graphtransformationen im eigentlichen Sinne ersetzt BOTLjedoch nicht in einem Graphen einen Teilgraphen durch einen anderen, son- dern erzeugt einen neuen Graphen.