15. Eine Sprache für Modell-Transformationen in der MOF-Architektur Schwerpunkte

Transkript

1 15. Eine Sprache für Modell-Transformationen in der MOF-Architektur Schwerpunkte der Modelltransformation 1/20 1

2 Klaas van den Berg Assistant Professor Software Engineering Group Department of Computer Science University of Twente Address PO Box AE Enschede the Netherlands phone: +31-(0) fax: +31-(0) URL: 2/20 Kurze Biographie -geb in Zwolle, Niederlande - 'Christelijk Lyceum' bis Studienbeginn an der neugegründeten Technischen Hochschule Twente B.Sc. (vermutlich Bachelor) M.Sc. (vermutlich Master) beide in Elektrotechnik - bis 1975 Dozent und Forscher in der Gruppe Elektrotechnik unter Prof. Jonker Dozent in der Abteilung von Elektrotechnik an der Universität von Sambia in Lusaka (Projekt Netherlands Universities Foundation for International Co-operation) Dozent in der Abteilung Elektrotechnik an der Universität von Dar-es Salaam in Tansania Dozent beim Polytechnic Enschede, Abt. Computer Engineering Assistant Professor der Abt. Informatik an der Universität Twente - verband die Gruppen Rechner-Architektur und Software - arbeitete an einem Projekt für intelligent tutor systems for computer programming in Zusammenarbeit mit dem Department of Educational Science and Technology neuer Schwerpunkt Softwaremessung Ph.D in Informatik Projekt TRESE software engineering, mit Schwerpunkt process modeling Universität von Sheffield Semantik von UML, use cases u. roundtrip engineering - Gegenwärtige Forschungen: XML-basierte Applicationen und deren Ausführung auf XML- Technologien, sowie UML-Semantik im Kontext der Model Driven Architektur - Publikationen: A Language for Model Transformations in the MOF Meta-modeling Architecture (Ivan Kurtev, Klaas van den Berg) Proceedings of Model-Driven Architecture: Foundations and Applications 2004, 2004 Declarative Aspect Composition (Istvàn Nagy, Lodewijk Bergmans, Mehmet Aksit), 2004 Principles and Design Rationale of Composition Filters (Lodewijk Bergmans, Mehmet Aksit) Aspect-Oriented Software Development, 2004 Software Metrics as Class Graph Properties (Harmen Kastenberg) MSc thesis, University of Twente, 2004 Towards Semantic Composition in Aspect-Oriented Programming (Istvàn Nagy, Lodewijk Bergmans) 1st European Interactive Workshop on Aspects in Software, 2004 Unifying Approach for Model Transformations in the MOF Metamodeling Architecture (Ivan Kurtev, Klaas van den Berg) Model-Driven Architecture with Emphasis on Industrial Applications, 2004 u.v.m. 2

3 und deren Idee Ivan Kurtev PhD Associate Software Engineering Group Faculty of Electrical Engineering, Mathematics and Informatics University of Twente Address: P.O. Box AE Enschede The Netherlands Office:INF 5063Phone: Fax: Home Page: 3/20 Kurze Biographie - geb.??? M.Sc. für Informatik an der Universität Sofia, Bulgarien junior researcher an der Universität Sofia - seit 2001 PhD-student in der Software Engineering Group, Universität Twente - Forschung: - techniques for XML processing with OO languages and composition of XML languages - model transformation and model composition problems in the context of the Model Driven Architecture -Publikationen: Kurtev, I., van den Berg, K. Unifying Approach for Model Transformations in the MOF Metamodeling Architecture. Proceedings of the 1st European MDA Workshop, MDA-IA, University of Twente, the Nederlands, March 2004 Kurtev, I., van den Berg, K. Model Driven Architecture based XML Processing. Proceedings of the ACM Symposium on Document Engineering, Grenoble, November 2003 Kurtev, I., van den Berg, K., Aksit, M. UML to XML-Schema Transformation: a Case Study in Managing Alternative Model Transformations in MDA. Forum on specification and Design Languages FDL2003, Frankfurt, September 2003 Kurtev, I., van den Berg, K. A Synthesis-Based Approach to Transformations in an MDA Software Development Process. In A. Rensink, Model Driven Architecture: Foundations and Applications, CTIT Technical Report TR-CTIT-03-27, University of Twente, June Kurtev, I., Bézivin, J., Aksit, M. Technological Spaces: An Initial Appraisal. CoopIS, DOA'2002 Federated Conferences, Industrial track, Irvine, 2002 Stoyanov, S., Aroyo, L., Kommers, P., Kurtev, I. SMILE Maker: A Web-Based Tool for Problem Solving. WebNet

4 In der MetaObject Facility (MOF) Metamodellierungsarchitektur gibt es eine Reihe von Transformationsszenarien. Es könnte erwartet werden, dass eine Metamodellierungsarchitektur von einer einheitlichen Umwandlungstechnologie begleitet wird. Tatsache ist, dass die gegenwärtigen Umwandlungssprachen zwar Ähnlichkeiten besitzen, aber üblicherweise nur auf ganz spezielle Umwandlungen fokussiert sind. Das Problem in der MOF ist, dass keine allgemeinen Instantions- Mechanismen definiert sind und die Generalisierung in unterschiedlichen Modelierungssprachen stattfindet. Das führt zu einer Verkopplung der Umwandlungssprache an die Instationsmechanismen der entsprechenden Stufe der MOF-Architektur. 4/20 Intra-Level-Transformationen Fig. a zeigt die spezielletransformation der beiden MOF Metamodellen UML und JAVA Auf dem Level M2 wird die Transformation spezifiziert/definiert und auf dem Level M1 ausgeführt. Fig. b Die beiden Phasen werden um ein Level gesenkt. Die Transformation erfolgt zwischen einem konkreten Document Type Definition (DTD) und einem konkreten alen Schema. Die Ausführung konvertiert ein XML-Dokument in eine relationale Datenbank. Dieses Szenario gehört zum Common Warehouse Metamodell (CWM). 4

5 Ziel: Umorganisation der MOF-Architektur basierend auf einer einheitlichen Repräsentation aller Modellelemente, egal auf welchem Level sie definiert sind. Unterschiedliche Instantions- und Generalisierungsmechanismen werden als Gruppe von Funktionen dargestellt. Präsentation einer Umwandlungssprache unabhänig von den spezifischen Instantions- und Generalisierungsmechanismen eines gegebenen Modells 5/20 5

6 15.5 Meta Object Facility (MOF) ist ein Standard der OMG. Die MOF-Spezifikation beschreibt eine abstrakte Sprache und ein Framework zur Verwaltung plattformunabhängiger Metamodelle, z.b UML, Common Warehouse Metamodel (CWM) und sowohl MOF selbst. MOF ist eine entscheidende Grundlage der Model Driven Architekture (MDA). 4-Schichten-Architektur 6/20 M0 Objekte-Schicht, sind eine Instanz von M1 und beschreiben die Ausprägungen eines bestimmten Modells (z.b. Buch: UML2.0, Autor: OMG, usw.) M1 Modell-Schicht, enthält alle Arten von Modellen und ist eine Instanz des M2 und definiert die Sprache zur Beschreibung der Domäne (z.b. Klasse:Buch, Klasse:Autor, usw.) M2 MetaModell-Schicht, ist eine Instanz von M3 und definiert die Sprache zur Beschreibung der Modelle (z.b. Klasse, Attribut, Operation). Diese Schicht ist das zentrale Element der UML und die Konzepte werden bei der UML-Modellierung ver-wendet (z.b: UML Class, UML Association, UML Attribute, UML State, usw) M3 Schicht ist MOF. Es ist die Infrastruktur der Metamodellarchitektur und definiert die Sprache zur Beschreibung von Metamodellen, z.b. die Menge der Konstrukte die zur Definition von Metamodellen genutzt wird (MOF Class, MOF Attribute, MOF Assoziation usw.) Vorteil von MOF MOF wurde 1997 von der OMG ratifiziert. Bis heute hat MOF mit XML und Java gut kooperiert. Und in Zukunft wird MOF bestimmt auch mit z.b. C# gut kooperieren. Der Erfolg von MOF verknüpft sich eng mit seinem Vorteil: Plattforunabhängigkeit. Das bedeutet, dass MOF unabhängig von: 1. Informationsformatierungstechnologien wie XML-DTD oder XMLSchema 2. 3 oder 4GL Programmiersprachen wie Java, C++, C#, VB 3. Component/messaging Middleware wie J2EE, CORBA,.NET Durch standarisierte Abbildung (Mapping) kann ein auf MOF basisierende Generator die Abstraktsprache von Metamodell ins Format von z.b XML DTD, Java oder CORBA umwandeln. Bei Generierungen im Detail existieren verschiendene MOF-Mappings, z.b: 1. MOF zu CORBA 2. MOF zu XML (sogenannte XMI) 3. MOF zu Java (sogenannte Java Metadata Interface, JMI) 6

7 Darstellung v. Idee: Jedes Modell der MOF-Architektur wird als eine Menge von dargestellt, welche durch ein Generic Model instanziert werden. Dabei ist es egal auf welchem Level ein Modellelement liegt. Generic Model 7/20 Das generic model wird in Fig. b gezeigt. Jedes Modellelement hat eine identity und eine Anzahl benannter Slots. Einfache Werte (strings, numbers,usw.) sind Literale. Slots werden benötigt um Modellelemente zu verbinden oder Werte von Literalen darzustellen. Fig. b ist nur der besseren Lesbarkeit in UML dargestellt. Das Generic Model ist außerhalb des MOF-Modells definiert und kann auch in jeder anderen Notation (z.b. mathematischen Mengen-en-Konzepten) veranschaulicht werden. 7

8 MOF Modells Das MOF Modell kann als ein Fall des Generic Model dargestellt werden. Dabei wurden folgende Regeln genutzt: -Alle Instanzen der MOF werden als Klassen konstruiert. - Attributen und Assoziationen werden als slots, die die Modellelemente verbinden dargestellt. - Das Diagramm stellt einen Teil der abstrakten Klasse ModelElement der MOF dar. Der Slot InstanceOfMOF zeigt die instantiation-beziehung zur MOF-class Konstruktion an. 8/20 Im Artikel werden noch weitere Darstellungen der MOF vorgestellt. Z.B. vereinfachtes MOF Modell Präzise Notation des MOF Modells als Graph von generic model Elementen 8

9 Darstellung eines smodells als Fall des Generic Model -Eigentlich gibt es in der MOF-Architektur mehrere instanceof- en, jeweils von Level zu Level. -Idee: smodel und sein Instance-Modell, beide definiert auf Level M2 die instanceof-en auf einem Level zu vereinigen. Dies führt dazu, dass ein Modellelement zu verschiedenen Meta-Konstrukten konform sein kann. 9/20 Ein Teil eines alschemas und relationaler Daten, beide auf Level M1, dargestellt als genericmodel Elemente Die Daten-die Modellelemente atuple, f1 und f2- die normalerweise zum Level M0 gehören, sind hier im Level M1 und könnten über Tuple und Field abgefragt werden. Beim Zugriff auf den Wert des Feldes B mit atuple.fieldæselect(name= B ).value würde man true erhalten. 9

10 Operationen In der Einleitung wurden verschiedene Transformationsszenarien dargestellt. Es erfolgt eine Transformation eines Input-Modells in ein Output-Modell. Beide Modelle haben Meta-Modelle. Bei der Transformation treten folgende Operationen auf: Selektion eines Modellelementes auf der Basis seiner Metakonstruktion Instantiation von von einer Metakonstruktion Zugriff auf slot-werte eines Elements Wertsetzen eines slots Jede dieser Operationen wird vom spezifischen Instantions- und Generalisierungsmechanismen des jeweiligen Meta-Modells beeinflußt. 10/20 10

11 Operationen 11/20 1.Selektion eines Modellelementes auf der Basis seiner Metakonstruktion Idee: Mit jedem Meta-Modell wird eine Funktion, meta benannt, assoziiert. Diese ist definiert über der Menge der Modellelemente des Input- Modells. Die Funktion gibt ein Element des Meta-Modells zurück, welches instantiiert ist. meta(me:modelelement):modelelement Eine andere Art der Selektion erfolgt über die Instanzierung von Spezialisierungen. Diese Selektion nutzt die Generalisierungsspezialisationen-Hierachie im Meta-Modell (z.b. Ableitungen bei Restriktionen und Extension im XML Schema, Extention in Klassen und interfaces in Java) Mit jeder wird eine Funktion,getSpecializedConstructs, assoziiert. Diese Funktion gibt für ein gegebenes Element des meta-modells alle spezialisierten Elemente zurück. getspecializedconstructs(me:modelelement): Set of ModelElement Zu 1. Eine Implementation der meta Funktion im Kontext des MOF-Modells wird den Wert des slots instanceofmof zurückgeben 11

12 Operationen Instantiation von einer Metakonstruktion Der Instantiationsmechanismus wird als eine Funktion, welche ein Konstrukt des Meta-modells nimmt und daraus ein Modellelement mit leeren slots erzeugt, definiert. instantiate(meta-construct:modelelement):modelelement Die Implementierung dieser Funktion ist abhänig vom Generalisations- Mechanismus des gegebenen Meta-Modells, da es die Vererbung von Features eines allgemeineren constructs definiert. 3. Zugriff auf slot-werte eines Elements Die slots eines Modellelements leiten sich von seinem Metaconstruct basierend auf dem Instantiations-Mechanismus ab. Unterschiedlich Instantiations-Mechanismen führen zu unterschiedlichen slots. Æ 2 Fragen 12/20 12

13 Operationen 1.Welcher Instantiations-Mechanismus wird zu Generation der slot- Repräsentatin des Modellelements genutzt? 2.Wie erhält man die slot-werte aus anderen Instantiations-Mechanismen, die nicht dem generic model entsprechen? zu1. Es wird einfach ein Instantiations-Mechanismus als Vorgabe gewählt, hier instanceofmof. zu2.definieren ein Übersetzungsmechanismus mit dem man die slots- Werte einer gegebenen Instantiation, unterschiedlich zur Vorgabe, erhält. Die Übersetzung ist als eine Funktion definiert, die Modellelemente und den Namen eines slots als Funktionswerte nutzt. Sie gibt den Wert des slots wieder, der eine Menge von ist. getslotvalue(me:modelelement,slotname:string):set of ModelElement 13/20 13

14 4.Wertsetzen eines slots Operationen Ähnlich wie Punkt 3. 2 Fälle Wenn der slot in der Repräsentation eines Elementes existiert, wird der Wert direkt auf den slot gelegt. 2. Wenn der slot aus einem anderen Instantiations-Mechanismus als der Vorgabe kommt, muß ein Übersetzungsmechanismus definiert werden. Dazu werden 2 Funktionen definiert: Die erste Funktion stellt den Wert des slots ein, wobei man berücksichtigt, wie der slot entstanden ist. setvalue(me:modelelement,slotname:string,slotvalue:set of ModelElement) Die zweite Funktion prüft, ob 2 Modellelemente kompatible Typen repräsentieren. iscompatible(expectedtype:modelelement,actualtype:modelelement):boolean 14/20 14

15 Operationen Die Menge der eingeführten Funktionen wird als Configuration bezeichnet. Die Funktionen der Configuration können in jeder Sprache implementiert werden. Sie können in einer externen library verwaltet werden. Zum Zwecke der Illustration wird im weiteren Verlauf gezeigt, wie die Implementation der Funktionen als Transformationsregeln, geschrieben in einer Transformationssprache, erfolgt. 15/20 15

16 Basis: Ableitung von XML processing 16/20 Ein Transformator transferiert ein Quellmodell in ein Zielmodell unter Nutzung einer Transformationsspezifikation. Die Transformationsspezifikation ist in der Transformationssprache geschrieben, die basiert auf dem Meta-Modell des Quell- u. Zielmodells, sowie der Configurationen dieser Modelle. Quell-u. Zielmodell müssen zu in einem Meta-Modell verbunden werden. Diese Anforderung wird immer erfüllt, da alle Modelle von generic model erzeugt werden können. Die Meta-Modelle und deren Configuration stellen den Input des Transformators. Der Transformator kann nur Instanzen aus constructs des generic model schaffen, z.b. Modellelemente,slots. Die Transformationsspezifikation ist eine Menge von Regeln: Modellelementeregeln erzeugt Modellelemente im Zielmodell Slots-Regeln werden genutzt um die Elemente durch setzen ihrer slot- Werte in Verbindung zu bringen Beide Regeln verwenden Elemente des Quellmodells. Als Beispiel wird die Configuration des MOF Models ausgeführt. 16

17 Modell-Element-Regel: Diese Regel erzeugt neue Elemente im Zielmodell oder modifiziert existierende Elemente des Quellmodells. 2 Wege: Instantiation des constructs durch das generic model Instantiation einiger Meta-constructs des Ziel-Meta-Modells Syntax in pseudo EBNF Notation, Nichtterminale sind kursiv rulenamemodelelementruleinput Parameters?{ RuleSource target[action+] SlotRule* } 17/20 Jede Modell-Element-Regel hat einen Namen, ein Ziel eine optionale Liste von Inputparametern und verbindet sich mit einer Reihe von slots-regeln. target enthält eine Menge von Actions update und Instantiation. Jede Instantiation spezifiziert ein meta-construct im Meta-Ziel-Modell. Die Elemente, die bei einer Instantiation erzeugt werden müssen mit einem Identifizierer gekennzeichnet werden. Update modifiziert die slot-werte der Modellelemente, die von der Quellregel ausgewählt wurden. Die Transformationssprache unterstützt einige Vererbungen unter den Model- Element-Regeln. Von der Elternregel wird die Quelle, das Ziel und die verbundenen slot-regeln vererbt. 17

18 Rule Source: Rule Source spezifziert die Merkmale der Elemente des Quellmodells, welche von der Transformation gewählt werden. source[component+,(condition{booleanexpressioninocl}]?] OCL Object Constraints Language Component kann ein eindeutiger Identifizierer eines Elementes im Quellmodell sein oder eine Variable, die an mehr als ein Quellelement gebunden werden kann. Slot Rules: Slot Rules sind immer mit Modell-Element-Regeln verbunden. Sie spezifizieren, wie man die werte der slots seiner Instantiation erhält. rulenamerulesourcetarget[(slotname=expression)+] 18/20 Jede slot rule hat einen Namen, eine Quelle und ein Ziel. target zählt die slots, die mit einem Wert belegt sind. RuleSource siehe oben 2 Arten von slots rules: Einzelform und Form mit Alternativen Einzelformen haben nur einen Quellausdruck Formen mit Alternativen können mehrere alternative Quellen haben. Um den Wert eines slots zu bestimmen wertet der Transformator zuerst den dem slot in der Instantiation zugewiesenen Ausdruck aus. Ist kein Ausdruck vorhanden, wird der Wert durch die Ausführung der verbundenen slot rules ermittelt. Alle Ergebnisse werden in einer Menge zusammengefaßt und als Wert des slots genutzt. 18

19 Verbindung zwischen Quell- und Zielelementen Wann immer eine Modell-Element-Regel ausgeführt wurde, etabliert die execution engine einen Verbindungs-Link zwischen dem genutzten Quellelement und Instantiationselement der Regel. Dieser Link kann dann wieder von anderen Regeln genutzt werden. z.b. DerivedConstructsForClass Regel Invoking Rules Es ist möglich eine Modell-Element-Regel durch die namentliche Übergabe eines bestimmten Quellelements hervorzurufen. 19/20 19

20 Ziel war es eine Transformationssprache zu definieren, die es erlaubt unabhänig von den Stufen der MOF Architektur Spezifizierungsumwandlungen vorzunehmen Syntax Die vorgestellte Sprache betrachtet die MOF Architektur als einen homogenen Modellierungsraum, der aus besteht, die durch ein und dieselbe generische Struktur entstanden sind. Primäres Ziel der Transformationssprache war es eine Entkopplung von Sprache und spezifischen Insantiations- und Generalisierungsmechanismen zu schaffen. 20/20 20