Presentation is loading. Please wait.

Presentation is loading. Please wait.

From Principles to Implementation:

Similar presentations

Presentation on theme: "From Principles to Implementation:"— Presentation transcript:

1 From Principles to Implementation:
Some Lessons Learned in the Building of the AMMA Model Engineering Platform Jean Bézivin Jean.Bezivin{noSpamAt} ATLAS Group (INRIA & LINA), University of Nantes, France

2 Model Driven Engineering
Schedule Scope & Applicability Principles Deployment (AMMA) Credits Modelware Microsoft IBM TNI Sodifrance

3 System Model Basic entities repOf
Technical Space: a representation system for models and a set of technical solutions to handle them. Technical Space System: a group of interacting, interrelated, or interdependent elements forming a complex whole. repOf System Model Systems Models 3) There is a very large variety of models. We can regroup them in Technical Spaces. Model: an abstract representation of a system created for a specific purpose.

4 Principles Tools Standards Teaching
The playground sNets, 1990 UML, 1995 Principles Tools Standards MOF, 2000 today, AMMA tomorrow Teaching

5 Principles, standards and tools
Model-Driven Engineering (MDE) MDA™ Model-Driven Architecture (OMG) Eclipse EMF GMF MIC Model Integrated Computing GME Software Factories (MS) Microsoft Visual Studio Team system DSL Tools Other Standards Tools Principles Standards Tools

6 IBM on MDA : Three complementary ideas
Direct representation Automation Standards Direct representation => multiple languages Danger of fragmentation Need coordination How to coordinate? Short answer: metametamodel But what is a metametamodel?

7 Agenda Scope

8 Introduction The industrial evolution (OMG MDA™, IBM EMF, Microsoft Software Factories) and the MDE trend The need for sound principles (models as first class entities) Technical spaces or why MDE is not sufficient. Multiple Technical Spaces inside MDE Introduction to model engineering MDA™ and software factories From object composition to model transformation The OMG three level stack and the Meta-Object Facility Guided tour of OMG standards Microsoft Software factories and DSL–based approach The Eclipse Modeling Framework (EMF) The notion of technical spaces Basic operations on models including transformation and weaving An ideal model management platform The future of model-driven engineering: challenges and perspectives EMF?

9 The initial move: from Middleware to Modelware

10 Latest tentative to define MDA

11 Steve Cook (OOPSLA 2004 panel)
Suggests that MDA proponents fall into the following three camps: The UML PIM camp: MDA involves the use of UML to build Platform Independent Models (PIMs) which are transformed into Platform Specific Models (PSMs) from which code is generated. The MOF camp: MDA does not involve the use of UML, but instead the crucial technology is MOF, and the definition of modelling languages and language transformations using MOF. The Executable UML camp: MDA involves building a UML compiler, making it a first class programming language. Ref: Steve Cook

12 MDA in a nutshell : PSM = f(PIM)
- 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 M1

13 The initial MDA conjecture : PSM = f(PIM)
PIM branch PDM branch PIMs (Platform Independent Models) weaving ? M Merging phase PSMs (Platform Specific Models) PDMs (Platform Description Models) PSM branch

14 Two missing links in the OMG architecture
PIM PDM PSM = f(PIM, PDM) or after currying: PSM = fPDM(PIM) “numeric” values: PDM = DotNet PDM = EJB PSM

15 Microsoft Software Factories
SDK (Team System) released in late 2004 First presentation at OOPSLA, Vancouver, Oct. 2004 See S. Cook, S. Kent, J. Greenfield and K. Short Blogs Aims to be closer to a metaCASE tool than Eclipse (however follow GMF Borland) Not UML-based (nor MOF, nor XMI) Models strongly tied to code Reverse engineering/synchronization Reliance on Microsoft’s platforms (Visual studio) … Modeling is the future … Bill Gates

16 Microsoft is releasing a suite of tools to make it easy to construct graphical designers hosted in Visual Studio for editing domain specific languages (DSL).

17 Creating a Petri net DSL
Metamodel: a couple of logical and visual definitions

18 Creating a Petri net DSL
Mapping on DotNet standard tools (C#, CLS, CLR, etc.) We are far from the initial OMG PIM/PSM naive separation However this is really MDE in 2005

19 A first attempt to reverse engineer the DSL Metametamodel

20 Microsoft DSI (Dynamic System Initiative) March 2005
System Definition Model is a language, or a meta-model, that is used to create models of distributed systems. A distributed system is a set of related software or software and hardware resources running on one or more computers that are working together to accomplish a common function A system model captures an entire system's composition in terms of all interrelated software and hardware components. A system model captures knowledge as prescriptive configurations and best practices, allowing the effects of changes to the system to be tested before the changes are implemented. Administrators do not need to operate directly on real-world systems but rather can model changes before committing to them. In this way, “what if” scenarios can be tried without impact to a business. A system model becomes the point of coordination and consistency across administrators who have separate but interdependent responsibilities.

21 The notion of TS (Technology Space) as a tool for collaboration
Description logic Prolog A Technology Space corresponds to: A uniform representation system Syntactic trees XML trees Sowa graphs UML graphs MOF graphs Categories Graph Grammars A working context A set of concepts A shared knowledge and know how etc. It is usually related to a given community with an established expertise, know-how and research problems It has a set of associated tools and practices, etc. Protégé, Rational Rose, … Java C++ Corba XML documentware WWW Corba MDA Modelware Ontologies Linux RDBMS Graph Theory OOBMS Semantic WEB Grammarware etc.

22 Abstract Syntax Systems Compared
Technology #1 (formal grammars attribute grammars, etc.) Technology #2 (MOF + OCL) M3 EBNF MOF M2 Pascal Language Grammar etc. The UML meta-Model M1 A specific Pascal Program A Specific UML Model A specific execution of a Pascal program A Specific phenomenon corresponding to a UML Model

23 A technical space is organized around a set of concepts
TSpaces may be connected via bridges TSpaces are often similarly organized Program Grammar Data Schema Model Meta-Model Document Ontology Top Level O. Syntax XML MDA DBMS engineering File FileFormat Drawing Stencil Model Meta-Model ToolFormat Tool Content Form FSMngt XML MDA Visio InfoPath But also…

24 Technical Spaces and Working Contexts
Examples: MDE, MDA, MS/SF, EBNF, XML, DBMS, ontologies, etc. Conjecture: Each TS is represented by a metametamodel Each TS is organized in a 3 metalevel architecture Working contexts Local MM specific Global TS specific, MM independent Universal Across several TSs (extended MIME notation) Mof1.4/UML/mymodel MicrosoftDSL/PetriNet/MyNet ECORE/PetriNet/MyNet EBNF/Pascal/MyProg XML/MusicML/MyMusic M3/M2/M1

25 Distinguish between intra-space and inter-space operations
Models revisited Everything is a model A -model  meaning any specific TSpace An XML document is an XML-model A Java source program is a Java-model An UML model is a MDA-model etc. Each TSpace is rooted in a metametamodel (M3) defining a representation scheme and basic type system. Distinguish between intra-space and inter-space operations

26 Model transformation across Technical Spaces
A TS B TS C TS D TS There is a need for inter-TS model transformation.

27 Agenda Applicability

28 Some examples of transformations
Classical UML2Java UML2RDBMS But also tool to tool (more important) UML Activity Diagrams to MS Project

29 The KM3 metamodel (simplified)

30 KM3 definition of the KM3 metamodel
NOT XMI (Emfatic-like) package KM3 { abstract class ModelElement extends LocatedElement { attribute name : String; reference "package" : Package oppositeOf contents; } class Package extends ModelElement { reference contents[*] ordered container : ModelElement oppositeOf "package"; class Classifier extends ModelElement {} class DataType extends Classifier {} class Class extends Classifier { attribute isAbstract : Boolean; reference supertypes[*] : Class; reference structuralFeatures[*] ordered container : StructuralFeature oppositeOf owner; -- continued on next slide

31 Java to Excel Transformation (call graph) public class FirstClass { public void fc_m1(){ } public void fc_m2(){ this.fc_m1(); public class SecondClass { public void sc_m1(){ FirstClass a = new FirstClass(); a.fc_m1(); public void sc_m2(){ this.sc_m1();

32 Java and Table Metamodels


34 Tool Interoperability
Build a metamodel of each tool Write a transformation Two kinds of Metamodels Data stream oriented Event oriented AMMA ATL AMW AM3 ATP Tool X Tool Y

35 Agenda Principles

36 What about the stability of MDA?
Missing foundations may cause big problems ahead

37 Just an academic issue anyway?

38 Enter the "metamuddle"

39 Model of a model

40 The MDA metamuddle A very rapidly growing industrial application field since november 2000, … but … We badly need a unifying theory of models

41 Credits and MDA compliance
Language engineering MDE Ontology engineering

42 The "representation" relation
? repOf System and System elements Model and Model elements Simple set interpretation of the repOf relation is probably as correct as simple set interpretation of the instanceOf relation in object technology.

43 The "conformance" relation
meta the MOF c2 metamodel model "the real world" meta-meta The MOF The UML metamodel Some UML Models Various usages of these models M0 M1 M2 M3 M3 source Class Association meta destination c2 meta meta meta the UML MetaModel Class Attribute * 1 a UML Model Client Name : String M2 c2 meta meta M1

44 Summary: a Petri Net model
conformsTo Metametamodel meta Link inCom inCom outGo outGo Link meta Node Node Link inCom Link outGo M3 outGo inCom conformsTo Metamodel inCom Link arcTP outGo Node Place Node Trans Link arcPT outGo inCom M2 System Classical representation Let us represent the system on the right with the Model Engineering Technical Space. This system is a Petri Net. Note that it is also a model of another Technical Space. We have three nodes: P1, P2, T1 and two edges: arcPT and arcTP. We have two node types: Place and Trans(ition). We have two edge types: arcPT from Place to Trans and arcTP from Trans to Place. There are meta links between the model and the metamodel elements. Therefore, there is a conformsTo relation between the model and the metamodel. The metametamodel is composed of… There are meta links between the metamodel and the metametamodel elements. Therefore, there is a conformsTo relation between the metamodel and the metametamodel. There are meta links from the metametamodel elements to other metametamodel elements. Therefore, there is a conformsTo relation from the metametamodel to the metametamodel. conformsTo P1 Model repOf T1 Place P1 arcPT Trans T1 arcTP Place P2 P2 M1

45 M3 M2 System M1 Metametamodel: XML Schema for XML Schema Metamodel:
conformsTo <xs:element name=“element"> <xs:complexType> <xs:attribute name=“name“ type=“xs:string"/> </xs:complexType> </xs:element> Metametamodel: XML Schema for XML Schema meta M3 conformsTo <xs:element name=“place"> <xs:complexType> <xs:attribute name=“name“ type=“xs:string"/> </xs:complexType> </xs:element> Metamodel: a Petri Net XML Schema M2 System Classical representation conformsTo P1 Model: an XML document <petrinet> <place name=“P1”/> <place name=“P2”/> <transition name=“T1”/> <arcPT source=“P1” target=“T1”/> <arcTP source=“T1” target=“P2/> </petrinet> repOf T1 P2 M1

46 Agenda Deployment

47 AMMA: A Lightweight Architectural Style for for Generic Model Management Platforms
ATLAS Model Management Architecture Build around a minimal set of sound principles Defines the conventions for the various connected tools to interoperate Lightweight : Not reinventing CORBA (Model-based interoperability and not Middelware-based interoperability) Four basic blocks: AMMA ATL AMW AM3 ATP M. Transformation M. Composition M. Global Management Inter TSpaces Bridge

48 Atlas Model Management Architecture
Modeling in the small Working at the level of model and metamodel elements Modeling in the large Working with models and metamodels as global entities, for what they represent, and their mutual relations, independently of their content A megamodel is a model which elements represents models, metamodels and other global entities (ako model registry with metadata on models and metamodels). A megamodel has a metamodel.

49 ATL: a model transformation language, engine and IDE
ATL: a MOF/QVT like model transformation language For more info see:

50 Model Transformation with ATL
Metametamodel Node conformsTo conformsTo conformsTo ATL MMa Green Node Red MMb Blue Node Pink Rule Node MMa2MMb.atl We have a model Ma. We want to create a model Mb from Ma. This is a transformation. Elements of Mb (target elements) are created from elements of Ma (source elements). 4, 5, 6) Let us look at the metamodels. Ma conforms to MMa and Mb to MMb. Both MMa and MMb conform to the metametamodel. For simplicity, the meta relations between elements of Ma and Mb and their meta elements in MMa and MMb is represented by a color code. 6) The relations between source elements and target elements can be grouped and associated to transformation rules. 7) Let us repreent These rules as a model elements of a MMa2MMb.atl transformation model. 8) The transformation model conforms to a transformation metamodel: ATL. R 2 B Rule G 2 P Rule conformsTo conformsTo Ma Mb

51 ATL editor (part of ATL Integrated Development Environment)

52 ATL Development Tools: source-level debugger

53 The standard OMG model transformation language
ATL is a QVT-like language If QVT is the solution, then what was the problem?

54 The Model Weaver: principles
Stub MM extends Left MM Weaving MM Right MM OperationPort mapsTo OperationType c2 - Fixed mapping metamodels are not sufficient - We need support for extensible variable metamodels Weaving model

55 Models isA isA Model set of elements and associations
Associations (intra model relationships) Model Composition (inter model relationships) Model hasA inherits Semantic defined in the metamodel E2 E1 E4 references E3 Model 1 Model 2 isA E2 E2 E1 E1 isA E3 E4 E3 Undefined line semantics

56 Metamodel extensions Several possible mapping DSLs (Domain Specific Languages) Adding extra semantics Concatenation, foreign keys, nested, ordered, equals, containment, supplier/consumer, etc. Model 2 Model 1 Equals E2 E1 E1 E2 Concat E4 E3 E2 String

57 AMW example: RDBMS to XML
Semantics XML schema represented in Ecore SQL schema represented in Ecore

58 Weaving metamodel Visualization (DSL tools and EMF)

59 Weaving metamodel Minimal weaving metamodel links and correspondences
extended to be used in different applications

60 AM3: ATLAS MegaModel Management Tool
Megamodel: a model with elements corresponding to models, metamodels, services, tools and more generally to any global resource available in the scope of an AMMA session. A registry for model engineering resources as well as a metadata repository Megamodel with different metamodels Megamodels beyond typing systems versionOf MM MM’ extensionOf typeOf M MM’ typeOf input Service Parameter output output implements M T Tool intput etc.

61 Representing zones with Megamodels
Metamodel c2 c2 Megamodel MgA Megamodel MgB repOf repOf ZoneA ZoneB Fred ATL Nantes Ivan Mistral Enschede

62 Representing zones with Megamodels
Metamodel c2 c2 Megamodel MgB  MgC Megamodel MgA repOf repOf ZoneBC ZoneA ZoneB ZoneC

63 Initial Metamodel Proposal for AMMA Megamodel Components

64 Megamodel Resource Navigator for model components
Technology Preview

65 π1 π2 π3 MS/Office Simulink Matlab XMI etc. JMI ATLAS CMI Technical
ATP: TS and projectors MS/Office Simulink Matlab etc. XMI JMI CMI etc. ATLAS Technical Projectors TSpace #2 EBNF grammar π1 TSpace #4 SQL program dataSchema TSpace #1 MDA data mmodel TSpace #3 XML π2 model π3 Java Corba SVG NLP, etc. XMLschema document

66 Examples of projections from ME to XML and EBNF TSs
XML TS ME TS EBNF TS M3 XSD MOF EBNF M2 MMa.xsd MMa KM3.g M1 Ma.xmi Ma MMa.km3 XMI KM3

67 Conclusions Transformations are models
Weavings (correspondences) are models Megamodels are models (meta-)Models everywhere A file format A tool internal data A Visio stencil An Infopath Form An API etc. Pragmatics of model transformation are important EMF and MS/DSL may be considered as two TSpaces, based on different M3

68 Conclusions: AMMA on top of Eclipse and MS/DSL tools
Visual Studio Team System AMMA Eclipse EMF AMMA ATL MTF Emfatic KM3 etc. etc.

69 How adaptable is MDA? MDA™ already evolved a lot in the last five years. MDA will have to evolve much more rapidly in the near future if OMG wants to meet the real needs of the user community. Strong competition will be coming from other technical spaces like XML, Microsoft DSLs, EMF, etc. End users are no more accepting huge, approximatively defined and committee-driven standards; they are asking for an available, adapted and agile set of small standards similar to XML. If MDA does not evolve rapidly, it will become one small niche in the MDE landscape; it will be quoted as the first historical one; many competing families of model engineering technologies will emerge and develop. What is important is assessing the basic principles of MDE; The decisions of OMG, W3C, OASIS, Microsoft, IBM and others on how to map these principles on implementation frameworks (e.g. Java, C#, XML, etc.) or on paper recommendations is only the responsibility of these organizations; the end user will be the final judge.

70 Thanks Questions?

Download ppt "From Principles to Implementation:"

Similar presentations

Ads by Google