State of the Art and Future Directions in Model Management Research

Size: px

Start display at page:

Download "State of the Art and Future Directions in Model Management Research"

Penelope Chambers
5 years ago
Views:

State of the Art and Future Directions in Model Management Research Japan-Austria Joint Workshop on ICT, October 18-19, 2010 Gerti Kappel Business Informatics Group Institute of Software Technology

1 State of the Art and Future Directions in Model Management Research Japan-Austria Joint Workshop on ICT, October 18-19, 2010 Gerti Kappel Business Informatics Group Institute of Software Technology and Interactive Systems Vienna University of Technology Favoritenstraße 9-11/188-3, 1040 Vienna, Austria phone: +43 (1) (secretary), fax: +43 (1)

2 Introduction Model Versioning Model Co-Evolution Rèsumè Content Introduction Model-Driven Engineering and Model Management Model Management Use Case I: Model Versioning Model Management Use Case II: Model Co-Evolution Résumé 2

3 Content Introductio n Model Versioning Model Co-Evolution Rèsumè Introduction Model-Driven Engineering and Model Management Model Management Use Case I: Model Versioning Model Management Use Case II: Model Co-Evolution Résumé 3

4 Model-Driven Engineering (MDE) Models, Models, Models,... "Everything is a model" Analysis Model Design Model Diff Model Transformation Model Metamodel Weaving Model Metametamodel Change Model Test Model Jean Bézivin. On the Unification Power of Models. Software and System Modeling 4(2), pages ,

5 Model-Driven Engineering (MDE) Models, Models, Models,... System represents Model Mapping Feature Reduction Feature Pragmatic Feature A model is based on an original (=system) A model only reflects a (relevant) selection of an original s properties A model needs to be usable in place of an original with respect to some purpose Herbert Stachowiak. Allgemeine Modelltheorie. Springer, Wien,

defines Language «instanceof» expressed using Model represents System Thomas

6 Model-Driven Engineering (MDE) Building Block #1: Metamodeling Meta- Metamodel defines Meta- Language «instanceof» expressed using Metamodel defines Language «instanceof» expressed using Model represents System Thomas Kühne. Matters of (Meta-)Modeling. Software and System Modeling 5(4), pages ,

Transformatio n Engine writes Model Krzysztof Czarnecki, Simon Helsen.

7 Model-Driven Engineering (MDE) Building Block #2: Model Transformations Metamodel Transformatio n Specification Metamodel «instanceof» executes «instanceof» Model reads Transformatio n Engine writes Model Krzysztof Czarnecki, Simon Helsen. Feature-based survey of model transformation approaches. IBM Systems Journal 45(3), pages ,

8 Model-Driven Engineering (MDE) Building Block #3: Model Management "Everything is a model" "No model is an island" instanceof generatedfrom refinementof abstractionof sameas equivalentwith overlappingwith crosscuttingwith 8

9 Model-Driven Engineering (MDE) Building Block #3: Model Management Model of "No model is an island" Model 0..* dependencies 9

10 Model Management Old wine in new bottles? Origin: Data Engineering Research issue for decades since integration of heterogeneous databases (1970) Current Status: Model Management 2.0 Well-documented kinds of heterogeneities Global Model Management Operators Diff, Merge, Match, Compose, ModelGen, TransGen, Inverse, Much progress, but still many challenges Ongoing Work: Model Management 3.0 = Model Management Model Engineering Raising the level of abstraction Too many data models, formats, technologies, tools, Built on top of powerful model engineering technologies P. Bernstein, S. Melnik. Model Management 2.0: Manipulating Richer Mappings. ACM SIGMOD 2007 Keynote, China, June

11 Model Management Old wine in new bottles? M3 Data Engineering No explicit formalism Model Engineering MOF M2 Relational DataModel XMLSchema DataModel UML SysML M1 arelational Model anxmlschema Model auml Model asysml Model M0 o1 o1 o1 o1 Legend Correspondences Transformation InstanceOf 11

12 Model Management in a Nutshell Model Management 2.0 Predefined set of generic operators Act upon models and produce models Limited set of model types Models and Maps Model management scripts Composition of given model management operators 1. Extensions for Model Management 3.0 Scripts are object-oriented programs Models are typed based on their metamodels Operators are tied to metamodels Operators expect typed models as input and produce typed models as output Thomas Reiter, Kerstin Altmanninger, Werner Retschitzegger. Think Global, Act Local: Implementing Model Management with Domain-Specific Integration Languages. Revised Selected Papers of Workshops and Symposia at MoDELS 2006, Springer LNCS 4363, pages ,

13 Model Management Motivating example: Exogenous merge merge A FullEquiv 3 4 Ecore AB* 5 6 merge a a? a' b' b? b ab' ab? FullEquiv 3 4 B Exogenous Merge Script 1 A.mark(); Ecore A = B.mark(); Ecore B = 1 Model A.mark(); a = Model B.mark(); b = 2 Ecore AB = A.merge(B); 3 FullEquiv wmap a a = = AB.FE_match(A AB.Fe_match(A ); ); FullEquiv wmapb b = = AB.Fe_match(B AB.FE_match(B ); ); 4 Transformation tt a = a = map = wwa.gentrafo(); ȧa.generate(); Transformation t t b b = = map w b b.gentrafo();.generate(); 5 AB a? a' = a.t a (); AB b? b' = b.t b (); 6 AB ab?= ab' = a?.merge(b?); a'.merge(b'); 13

14 Introduction Model Versioning Model Co-Evolution Rèsumè Content Introduction Modeling, Model-Driven Engineering, and Model Management Model Management Use Case I: Model Versioning Model Management Use Case II: Model Co-Evolution Résumé 14

15 Model Management Use Case I: Model Versioning Motivation Some definitions of Software Engineering (SE) SE is defined as the multi-person construction of multi-version software David LorgeParnas SE deals with the building of software systems that are so large or so complex that they are built by teams of engineers Carlo Ghezzi, Mehdi Jazayeri, and Dino Mandrioli Implication for Model Engineering: Models must be built in teams! Precise Conflict Detection Supportive Conflict Resolution 15

16 The Model Versioning Process Revised A C A A C A A A A A C A A A A 16

17 Example 1: Contradicting Change Person Person Person getname() 17

18 Example 2: Equivalent Change Person Person Person Person Employee Employee Employee 18

19 Example 2: Equivalent Change Harder than we thought!? UML Metamodel V1 UML Metamodel V2 Metamodel Class name:string 0..* superclasses o1, o2 o1.id = o2.id o1 Class, o2 Class o1.name = o2.name Class name:string superclass * subclasses Generalization Model (AS) c1:class name= Person c2:class name= Employee Sally Harry c1:class name= Person c3:class name= Employee c1:class name= Person g1:generalization c2:class name= Employee Sally Harry c1:class name= Person g2:generalization c3:class name= Employee Model (CS) Person Employee Person Person Employee Employee Person Employee Person Person Employee Employee 19

20 Example 3: Syntactic Inconsistency Car has Engine Car has 1 Engine Car * has 1 Engine Car * has 1 Engine 20

The AMOR Approach Overview Adaptable Versioning Framework www.modelversioning.

21 The AMOR Approach Overview Adaptable Versioning Framework Precise Conflict Detection Supportive Conflict Resolution Gerti Kappel et al. Adaptable Model Versioning in Action. In Proc. of Modellierung 2010, GI, LNI 161, pages ,

22 Versioning Example State-based and generic merging V0 hang_up Idle lift hang_up DialTon e Dialing V0 V0 Idle lift Active DialTon hang_up e Dialing cancel cancel lift DialTon Idle e cancel Dialing Connect valid V1 22

hang_up Dialing Delete / Update cancel cancel lift DialTon Idle e cancel

23 Versioning Example State-based and generic merging V0 hang_up Idle lift hang_up DialTon e Dialing V0 V0 Active lift Idle DialTon hang_up e Update / Update hang_up Dialing Delete / Update cancel cancel lift DialTon Idle e cancel Dialing Connect valid V1 cancel Idle Connect lift cancel valid Active Dialing DialTon e 23

24 Versioning Example State-based and generic merging V0 hang_up Refactoring: -Introduce Composite State Idle lift hang_up DialTon e Dialing Atomic changes: -Addition Connect -Rename of hang_up s V0 V0 Active lift Idle DialTon hang_up e Update / Update hang_up Dialing Delete / Update cancel cancel lift DialTon Idle e cancel Dialing Connect valid V1 cancel Idle Connect lift cancel valid Active Dialing DialTon e 24

25 Versioning Example Operation-based and refactoring-aware merging V0 hang_up Idle lift hang_up DialTon e Dialing Atomic changes: -Addition Connect -Rename of hang_up s cancel cancel lift Idle cancel Connect DialTon e Dialing valid Refactoring: -Introduce Composite State Idle lift cancel valid Active DialTon e Dialing Connect 25

Versioning Example Operation-based and refactoring-aware merging V0 hang_up Idle lift hang_up DialTon e Dialing V0 V0 Idle lift Active DialTon

26 Versioning Example Operation-based and refactoring-aware merging V0 hang_up Idle lift hang_up DialTon e Dialing V0 V0 Idle lift Active DialTon hang_up e Dialing cancel cancel lift DialTon Idle e cancel Dialing Connect valid V1 Idle lift cancel valid Active DialTon e Dialing Connect 26

27 Summary: Status Quo in Model Versioning Research»Pre-Knowledge«Implicit Knowledge Explicit Knowledge Community Knowledge Few initial approaches No common terminology No common problem definition No exactly formulated research goals No test cases for comparison of model versioning systems Gerti Kappel et al. Why Model Versioning Research is needed!?. In Proc. of the Joint MoDSE- MCCM ModELS'09,

28 Content Introduction Model Versioning Model Co-Evolution Rèsumè Introduction Model-Driven Engineering, and Model Management Model Management Use Case I: Model Versioning Model Management Use Case II: Model Co-Evolution Résumé 28

29 Model Management Use Case II: Model Co-Evolution Motivation Term Co-Evolution borrowed from Biology Biological co-evolution is the change of a biological entity triggered by the change of a related entity One-to-one Relationships: Predator/Prey, Host/Symbiont, Host/Parasite, Diffuse Relationships: An entity evolves in response to a number of other entities, each of which is also evolving in response to a set of entities Co-Evolution in MDE Co-evolution is the change of a model triggered by the change of a related model Current View Relationship: r(a,b) a Δ a' a a b b r(a,b ) Challenge: Relationship Reconciliation b Δ b' Current research focus is on one-to-one relationships 29

30 Metamodeling Level Metamodels are the central artefacts Textual Concrete Syntax Graphical Concrete Syntax Model 2 Model Transformations Model 2 Code Transformations Metamodel Models Simulators OCL Constraints 30

31 Metamodeling Level Only models, i.e., instances of metamodels, are currently co-evolved! Textual Concrete Syntax Graphical Concrete Syntax Model 2 Model Transformations Model 2 Code Transformations Metamodel Models Simulators OCL Constraints 31

32 Metamodel/Model (Co-)Evolution Example A D B Δ rename(b, C) A D C Metamodel D1 D2 D1 D2 conformsto Metamodel A Metamodel A Instance of Metamodel A Instance of Metamodel A Models a1: A b1: B Δ cast(b:b, c:c) a1: A c1:c a2: A b2: B a2:a c2:c Assumption: Renamed Class does not represent a new modeling concept! Gerti Kappel et al. On using Inplace Transformations for Model Co-Evolution. In Proc. of the 2nd International Workshop on Model Transformations with ATL ICMT 10,

33 Metamodel/Transformation (Co-)Evolution Initial example Source Metamodel MMa t 1 Targte Metamodel MMb t 1 Forward Transformation 33

34 Metamodel/Transformation (Co-)Evolution Target metamodel evolution Source Metamodel MMa t 1 Targte Metamodel MMb v2.0 t 2 Evolution MMb v3.0 t 1 t 2 Forward Transformation Migration Transformation 34

35 Metamodel/Transformation (Co-)Evolution Transformation composition for evolving existing transformations Source Metamodel MMa t 1 Targte Metamodel MMb v2.0 t 3 = t 1 t 2 MMb t 2 Evolution v3.0 t 1 t 2 Forward Transformation Migration Transformation 35

36 Metamodel/Transformation (Co-)Evolution First initial results for composing graph transformations Source Metamodel MMa t 1 Targte Metamodel MMb v2.0 t 3 = t 1 t 2 MMb t 2 Evolution v3.0 Requirements on t 3 (1)Soundness and completeness (2)Elimination (3)Transitivity Manuel Wimmer et al. Towards Transformation Rule Composition. In Proc. of the 4th International Workshop on Multi-Paradigm Modeling MoDELS 10,

37 Modeling Level using UML Question 1: Are class diagrams in the centre of the development process? Use Case Diagram Object Diagram Activity Diagram Sequence Diagram Class Diagram Composite Structure Diagram Component Diagram State Diagram OCL Constraints 37

38 Modeling Level using UML Question 1: Are class diagrams in the centre of the development process? Use Case Diagram Object Diagram Activity Diagram Composite Structure Diagram Sequence Diagram Class Diagram Component Diagram State Diagram OCL Constraints 38

39 Modeling Level using UML Question 2: Do we have one-to-one relationships or diffuse relationships? Use Case Diagram Object Diagram Activity Diagram Composite Structure Diagram Sequence Diagram Class Diagram Component Diagram State Diagram OCL Constraints 39

40 Modeling Level using UML Question 2: Do we have one-to-one relationships or diffuse relationships? Use Case Diagram Object Diagram Activity Diagram Composite Structure Diagram Sequence Diagram Class Diagram Component Diagram State Diagram OCL Constraints 40

41 Modeling Level using UML Question 2: Do we have one-to-one relationships or diffuse relationships? Use Case Diagram Object Diagram Activity Diagram Sequence Diagram «component» Change Propagator Composite Structure Diagram Component Diagram State Diagram Class Diagram OCL Constraints 41

42 Modeling Level using UML Question 3: Who is the host and who is the parasite? Traditional Database Engineering View Use the schema for populating the instances! Consequence Each change in the Class Diagram has to be propagated to the Object Diagram Class Diagram Object Diagram 42

43 Modeling Level using UML Question 3: Who is the host and who is the parasite? Prototype-based Engineering View Abstract the schema from the instances! Consequence Some changes in the Object Diagram have to be to propagated to the Class Diagram Object Diagram Class Diagram 43

44 Summary: Status Quo in Model Co-Evolution Research»Pre-Knowledge«Implicit Knowledge Explicit Knowledge Community Knowledge Several initial approaches Metamodel/model (co-)evolution has been solved for syntactical issues Huge number of different co-evolution scenarios Often no exactly formulated relationships between models No publicly accessible model repositories for studying model coevolution 44

45 Content Introduction Model Versioning Model Co-Evolution Rèsumè Introduction Modeling, Model-Driven Engineering, and Model Management Model Management Use Case I: Model Versioning Model Management Use Case II: Model Co-Evolution Résumé 45

46 Résumé Model management infrastructure is the prerequisite for tackling evolution issues Find a basic set of model management operators Diff, Merge, Patch, Explore variations and properties of these operators Extend existing tools with model management capabilities Provide a set of predefined operators Provide a common programming model for script development Based on these scripting languages, provide tool support for Versioning, Co-evolution, Merging, Users should be enabled to adapt predefined scripts 46

47 Résumé Model management: lessons learned Provides terminology for evolution concerns Allows to reason on a high-level of abstraction Variations of operators are a must Says nothing about implementation of operators Some operators seem to be magical (e.g., match, merge, ) No approved programming model for script development 47

48 Résumé Future work needed! Many research questions remain open in the field of MDE What are the most important model management/evolution scenarios? What is the sufficient set of model management operators? What is an appropriate programming model for model management scripts? How to implement model management operators? How to verify model management operators? Is a generic model management approach feasible? 48

49 Résumé Model Management in Model-Driven Engineering Still enough to do :-! State of the Art in MDÉ 2010»Pre-Knowledge«Implicit Knowledge Explicit Knowledge Community Knowledge Practice of MDE Research in MDE Consolidation, Verification and Industrialization Appropriateness of some standards questionable (QVT, UML2) not yet adopted CASE-tool vendors jump on the MDE bandwagon Many different proposals, application areas and goals E.g., Model Management, Mega-Modeling, Runtime Models, AOM, MDWE, DSM, 49

50 Thanks to Petra Brosch Horst Kargl Philip Langer Thomas Reiter Werner Retschitzegger Wieland Schwinger Martina Seidl Konrad Wieland Manuel Wimmer and many more 50

Current trends and frameworks for modeldriven approaches to software development

1 Current trends and frameworks for modeldriven approaches to software development Trial Lecture Odd Petter Nord Slyngstad Trondheim, 1 st April 2011 Anita Gupta 28/05/2009 2 Overview What is a model-driven