1. OORPT Object-Oriented Reengineering Patterns and Techniques 13. Model-Driven Development Prof. O. Nierstrasz

2. OORPT — Architecture Recovery 10.2 Roadmap  Introduction to Model Engineering —Models and metamodels —MDA —Models as graphs  Query/Views/Transformations —QVT languages: Relations, Core, Operational Mappings —Case study: flattening UML hierarchies

3. OORPT — Architecture Recovery 10.3 Sources  Introduction to Model Engineering —Jean Bézivin  Query/Views/Transformations —ATLAS group, INRIA & University of Nantes  Model Driven Development —Colin Atkinson, Universität Mannheim http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/ecesis-home/downloads/index.html

4. OORPT — Architecture Recovery 10.4 Roadmap  Introduction to Model Engineering —Models and metamodels —MDA —Models as graphs  Query/Views/Transformations

5. OORPT — Architecture Recovery 10.5 The Vision of MDA software developer Platform Independent Model automatic translation

6. OORPT — Architecture Recovery 10.6 procedural technology component technology object technology Objects, Classes, Smalltalk, C++,... Procedures, Pascal, C,... Packages, Frameworks, Patterns, … 19801995 2000 procedural refinement model technology Models, Metamodels, UML, OCL, MOF, XMI, SPEM, CWM … object composition model transformation A global view of software engineering evolution

7. OORPT — Architecture Recovery 10.7 Roadmap  Introduction to Model Engineering —Models and metamodels —MDA —Models as graphs  Query/Views/Transformations

8. OORPT — Architecture Recovery 10.8 Modeling is essential  Modeling is essential to human activity because every action is preceded by the construction (implicit or explicit) of a model.  The medical technique of bloodletting was based on an incorrect model of the body [1]. If the model is incorrect, the action may be inappropriate [2]. 1.Hippocrates and many others believed that the four crucial elements earth, air, water and fire were balanced within the human body as the four humors: blood, phlegm, and black and yellow bile. In this context, disease was due to an imbalance in the four humors and treatment involved restoring their balance through bloodletting. 2.Georges Washington died after heavy blood loss sustained in a bloodletting treatment for laryngitis.

9. OORPT — Architecture Recovery 10.9 http://poweredge.stanford.edu/BioinformaticsArchive/PrimarySite/NIHpanelModeling/RothenbergNatureModeling.pdf What is a model?  Modeling, in the broadest sense, is the cost-effective use of something in place of something else for some cognitive purpose. It allows us to use something that is simpler, safer or cheaper than reality instead of reality for some purpose. A model represents reality for the given purpose; the model is an abstraction of reality in the sense that it cannot represent all aspects of reality. This allows us to deal with the world in a simplified manner, avoiding the complexity, danger and irreversibility of reality. – “The Nature of Modeling.” Jeff Rothenberg. In Artificial Intelligence, Simulation, and Modeling, John Wiley and Sons, Inc., 1989, pp. 75-92

10. OORPT — Architecture Recovery 10.10 A model is a partial view of a system Respiratory model Other Models muscular, nervous, circulatory, digestive, endocrinous, etc. Skeleton model A system Several models of this system (partial views) repOf

11. OORPT — Architecture Recovery 10.11 Carpenter's view Mason's view Plumber's view Architect's view Landlord's view Renter's view Interior Designer's view Tax Collector's view Electrician's view Each view is expressed in a given domain language (DSL). Vocabularies of different corporations are different; However they allow talking about a common building. Model repOf System Multiples views and coordinated DSLs

12. OORPT — Architecture Recovery 10.12 Aspects of a system represented by models A given system may have plenty of different models. Each model represents a given aspect of the system. Ma S S isRepresentedBy M0M0 M1M1 Mb Mc

13. OORPT — Architecture Recovery 10.13 Don't confuse the model and the system

14. OORPT — Architecture Recovery 10.14 Percentage of places infested by termites in France. First round of political election in France in 2002. A model has no meaning when separated from its metamodel

15. OORPT — Architecture Recovery 10.15 The legend in the map is a metamodel basedOn

16. OORPT — Architecture Recovery 10.16 This is DSL X DDMM Model a Model b Model c Model d This is DSL Y This is DSL Z Definition: A DSL is a coordinated set of models DDMM = Domain Definition MetaModel Metamodels define Domain Specific Languages (DSLs)

17. OORPT — Architecture Recovery 10.17 What is a model? A model is a representation of a system —A model is written in the language of its unique metamodel —A metamodel is written in the language of its unique metametamodel – The unique MMM of the MDA is the MOF —A model is a constrained directed labeled graph —A model may have a visual graphical representation (sometimes)

18. OORPT — Architecture Recovery 10.18 Roadmap  Introduction to Model Engineering —Models and metamodels —MDA —Models as graphs  Query/Views/Transformations

19. OORPT — Architecture Recovery 10.19 Production of a system from a model S M Production of a system from a model. For example construction a building from its floor plans. M repOf S {postcondition}

20. OORPT — Architecture Recovery 10.20 M1M1 M2M2 M3M3 MDA in a nutshell - One unique Metametamodel (the MOF) - An important library of compatible Metamodels, each defining a DSL - Each of the models is defined in the language of its unique metamodel

21. OORPT — Architecture Recovery 10.21 The OMG/MDA Stack the UML MetaModel ClassAttribute * 1 a UML Model Client Name : String M2M2 M1M1 the MOF Class Association source destination M3M3 c2     metamodel model "the real world" meta-meta model The MOF The UML metamodel ++ Some UML Models ++ Various usages of these models M0M0 M1M1 M2M2 M3M3  

22. OORPT — Architecture Recovery 10.22 CORBA Java/EJB C#/DotNet Web/XML/SOAP PIM etc. Platform-Independent Model Multi-target code generation + SVG, GML, Delphi, ASP, MySQL, PHP, etc. data grid computing pervasive computing cluster computing SMIL/Flash Write Once, Run Anywhere Model Once, Generate Anywhere

23. OORPT — Architecture Recovery 10.23 Forward and reverse engineering PSM Platforms of yesterday Platforms of tomorrow Platforms of today Legacy, Cobol, ADA, etc. Java, EJB, J2EE, etc. ???? Grid, Cluster, P2P architectures PIM

24. OORPT — Architecture Recovery 10.24 Roadmap  Introduction to Model Engineering —Models and metamodels —MDA —Models as graphs  Query/Views/Transformations

25. OORPT — Architecture Recovery 10.25 Structural definition of a model  Definition 1. A directed multigraph G = (N G, E G,  G ) consists of a finite set of distinct nodes N G, a finite set of edges E G and a mapping function  G : : E G  N G x N G  Definition 2. A model M = (G, ,  ) is a triple where: —G = (N G, E G,  G ) is a directed multigraph —  is itself a model, called the reference model of M, associated to a graph G  = (N , E ,  ) —  : N G  E G  N  is a function associating elements (nodes and edges) of G to nodes of G  (metaElements)

26. OORPT — Architecture Recovery 10.26 Each model conforms to its reference model

27. OORPT — Architecture Recovery 10.27 There are several kinds of models

28. OORPT — Architecture Recovery 10.28 Definitions  Definition 3. A metametamodel is a model that is its own reference model (i.e. it conforms to itself).  Definition 4. A metamodel is a model such that its reference model is a metametamodel.  Definition 5. A terminal model is a model such that its reference model is a metamodel.

29. OORPT — Architecture Recovery 10.29 Utilization definition  The objective here is to define the possible usages of a model. Consequently model will mean here "terminal model". —Definition 6. A system S is a delimited part of the world considered as a set of elements in interaction. —Definition 7. A model M is a representation of a given system S, satisfying the substitutability principle (see below). —Definition 8. (Principle of limited substitutability). A model M is said to be a representation of a system S for a given set of questions Q if, for each question of this set Q, the model M will provide exactly the same answer that the system S would have provided in answering the same question.

30. OORPT — Architecture Recovery 10.30 Roadmap  Introduction to Model Engineering  Query/Views/Transformations —QVT languages: Relations, Core, Operational Mappings —Case study: flattening UML hierarchies

31. OORPT — Architecture Recovery 10.31 Overview  QVT stands for Query/Views/Transformations  OMG standard language for expressing queries, views, and transformations on MOF models —OMG QVT Request for Proposals (QVT RFP, ad/02-04-10) issued in 2002 —Seven initial submissions that converged to a common proposal —Current status (June, 2006): final adopted specification, OMG document ptc/05-11-01

32. OORPT — Architecture Recovery 10.32 Roadmap  Introduction to Model Engineering  Query/Views/Transformations —QVT languages: Relations, Core, Operational Mappings —Case study: flattening UML hierarchies

33. OORPT — Architecture Recovery 10.33 QVT Operational Context  Abstract syntax of the language is defined as MOF 2.0 metamodel  Transformations (Tab) are defined on the base of MOF 2.0 metamodels (MMa, MMb)  Transformations are executed on instances of MOF 2.0 metamodels (Ma)

34. OORPT — Architecture Recovery 10.34 QVT Architecture  Layered architecture with three transformation languages: —Relations —Core —Operational Mappings  Black Box is a mechanism for calling external programs during transformation execution

35. OORPT — Architecture Recovery 10.35 QVT Languages  Relations —Declarative transformation language —Specification of relations over model elements  Core —Declarative transformation language —Simplification of Relations language  Operational Mappings —Imperative transformation language —Extends Relations language with imperative constructs QVT is a set of three languages that collectively provide a hybrid “language”.

36. OORPT — Architecture Recovery 10.36 Roadmap  Introduction to Model Engineering  Query/Views/Transformations —QVT languages: Relations, Core, Operational Mappings —Case study: flattening UML hierarchies

37. OORPT — Architecture Recovery 10.37 Case Study  Flattening UML class hierarchies: —given a source UML model transform it to another UML model in which only the leaf classes (classes not extended by other classes) in inheritance hierarchies are kept.  Rules: —Transform only the leaf classes in the source model —Include the inherited attributes and associations —Attributes with the same name override the inherited attributes —Copy the primitive types

38. OORPT — Architecture Recovery 10.38 Source and Target Metamodel: SimpleUML

39. OORPT — Architecture Recovery 10.39 Example Input Model

40. OORPT — Architecture Recovery 10.40 Example Output Model

41. OORPT — Architecture Recovery 10.41 transformation SimpleUML2FlattenSimpleUML(in source : SimpleUML out target : SimpleUML); ………………………………………………………………… main() {} ………………………………………………………………… …helpers…………………………………………… …mapping operations……………… transformation SimpleUML2FlattenSimpleUML(in source : SimpleUML out target : SimpleUML); ………………………………………………………………… main() {} ………………………………………………………………… …helpers…………………………………………… …mapping operations……………… Overall structure of a transformation program: Signature: Declares the transformation name and the source and target metamodels. in and out keywords indicate source and target model variables. Signature: Declares the transformation name and the source and target metamodels. in and out keywords indicate source and target model variables. Entry point: The execution of the transformation starts here by executing the operations in the body of main Entry point: The execution of the transformation starts here by executing the operations in the body of main Transformation elements: Transformation consists of mapping operations and helpers. They form the transformation logic. Transformation elements: Transformation consists of mapping operations and helpers. They form the transformation logic. Model Transformation expressed in Operational Mappings Language

42. OORPT — Architecture Recovery 10.42 Mapping Operations  A mapping operation maps one or more source elements into one or more target elements —Always unidirectional —Selects source elements on the base of a type and a Boolean condition (guard) —Executes operations in its body to create target elements —May invoke other mapping operations and may be invoked —Mapping operations may be related by inheritance

43. OORPT — Architecture Recovery 10.43 mapping Class::leafClass2Class(in model : Model) : Class when {not model.allInstances(Generalization)->exists(g | g.general = self)} { name:= self.name; abstract:= self.abstract; attributes:= self.derivedAttributes()->map property2property(self)->asOrderedSet(); } mapping Class::leafClass2Class(in model : Model) : Class when {not model.allInstances(Generalization)->exists(g | g.general = self)} { name:= self.name; abstract:= self.abstract; attributes:= self.derivedAttributes()->map property2property(self)->asOrderedSet(); } Operation body Signature and guard Mapping Operations: Example (1)  Consider the rule that transforms only leaf classes —Selects only classes without subclasses —Collects all the inherited properties —Creates new class in the target model

44. OORPT — Architecture Recovery 10.44 mapping Class::leafClass2Class(in model : Model) : Class when {not model.allInstances(Generalization)->exists(g | g.general = self)} mapping Class::leafClass2Class(in model : Model) : Class when {not model.allInstances(Generalization)->exists(g | g.general = self)} Operation name Source element type An optional sequence of input/output parameters Target element type Guard The Guard is an OCL expression used to filter source elements of a given type. The mapping operation is executed only on elements for which the guard expression is evaluated to true. Mapping Operations: Example (2) Operation Signature and Guard

45. OORPT — Architecture Recovery 10.45 name:= self.name; abstract:= self.abstract; attributes:= self.derivedAttributes()->map property2property(self)->asOrderedSet(); name:= self.name; abstract:= self.abstract; attributes:= self.derivedAttributes()->map property2property(self)->asOrderedSet(); Operation Body The predefined variable self refers to the source element on which the operation is executed The left-hand side of the assignments denotes properties of the target element Invocation of helper derivedAttributes The keyword map is used to invoke another mapping operation named property2property over the elements returned by the helper derivedAttributes The mapping operation body contains initialization expressions for the properties of the target element. When an operation is executed over a source element the self variable is bound to it and an instance of the target type is created. Then the operation body is executed. Mapping Operations: Example (3)

46. OORPT — Architecture Recovery 10.46 Conclusions (1)  QVT: Query/Views/Transformations – the OMG standard language for model transformations in MDA/MDE  The issue of Views over models is not addressed  Query language based on OCL  A family of three transformation languages: —Relations: declarative language —Core: declarative language, simplification of Relations —Operational Mappings: imperative transformation language that extends relations  Collectively QVT languages form a hybrid language

47. OORPT — Architecture Recovery 10.47 Conclusions (2)  Tool support is still insufficient (at the time of preparing of this lecture – June 2006)  QVT is not proved yet in non-trivial industrial like scenarios  Many issues need further exploration: —Performance —Testing —Scalability of transformations —Ease of use —Handling change propagation —Incremental transformations —Adequacy of the reuse mechanisms

48. OORPT — Architecture Recovery 10.48 License  The present courseware has been elaborated in the context of the MODELWARE European IST FP6 project (http://www.modelware-ist.org/).  Co-funded by the European Commission, the MODELWARE project involves 19 partners from 8 European countries. MODELWARE aims to improve software productivity by capitalizing on techniques known as Model-Driven Development (MDD).  To achieve the goal of large-scale adoption of these MDD techniques, MODELWARE promotes the idea of a collaborative development of courseware dedicated to this domain.  The MDD courseware provided here with the status of open source software is produced under the EPL 1.0 license. http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/ecesis-home/downloads/index.html