1. MDE Model Driven Engineering Xavier Blanc Université Pierre et Marie Curie Xavier.Blanc@lip6.fr

2. Agenda MDE Architecture Know-how capitalization Productivity Platform Case Study

3. MDE Architecture Global view

4. Models « Modeling is the future, so every company that’s working on this I think it’s great, and I think there are some real contributions that can be made » B. Gates « Companies that adopt the MDA gain the ultimate in flexibility: the ability to derive code from a stable model as the underlying infrastructure shifts over time. » R. Soley « Why building models ? At the end, we will write code ? » « A good diagram is better than a long speech… but from a UML diagram you can have many speeches ! » Need of best practices and clear objectives MDE Architecture

5. Practices & Objectives Best Practices Abstraction layers and Viewpoints (Matrix) Formalization of layers and viewpoints Formalization of abstraction layers / viewpoints relationships Objectives New systems Legacy systems Master platforms proliferation MDE Architecture

6. Approach MDE Architecture Requirement model: defines the system in its environment. Analysis and design model: defines the system architecture. Realization model: defines how the system is built. Code of the system and configuration artifacts.

7. Architecture MDE Architecture CIMPIMPSM Java Software system MOF M2QVT M2

8. Resources A standard for defining meta-models  The MOF standard is a language for defining meta- models A standard for importing and exporting models  The XMI standard defines a bridge with XML Model Manipulation  Frameworks (JMI/EMF) define APIs for manipulating models with OO languages. Model Transformation  The QVT standard defines a language for expressing model transformations. MDE Architecture

9. Goals Know-how capitalization  The goal is to build models (CIM, PIM) that will live forever.  The goal is also to model the transformation and to trace them.  Modeling language has to support abstraction ! Productivity  The goal is to automate operations on models (code generation, documentation generation, simulation, …).  Models should be manipulated by programming languages ! Platforms  The goal is to make platforms explicit within the software lifecycle.  Platforms has to be modeled ! MDE Architecture

10. Know-how capitalization Standards

11. Meta-model Capitalization A meta-model defines concepts and their relationships thanks to a class diagram. A meta-model only defines structure (no semantic). A model is an instance of a meta- model if it respects the structure defined by the meta-model. The UML meta-model defines the structure that all UML models must have.

12. Meta-meta-model MOF defines the language for defining meta-models MOF concepts are meta- class, meta-attribute, meta- association, etc. MOF concepts and their relationships can be defined by a class diagram. This diagram is also a meta- model (called the meta- meta-model) The meta-meta-model is self defined. Capitalization

13. Meta-layers Capitalization MOFUMLModèle Meta-meta-model UML Meta-model Model Mn+1 defines the structure of Mn Mn+1 is not an abstraction of Mn Meta-layer relationships are similar to grammar- layer relationships (BNF, or XML Schema)

14. UML2.0 UML2.0 is not a simple update of UML1.4, it is a central part of MDE. UML is the most used MDE meta-model. International experts have spent 3 years for designing it ! UML is the dedicated modeling language for defining software systems  UML2.0 is an instance of MOF2.0.  UML2.0 semantic is defined with natural language  UML2.0 diagrams are based on the meta-model UML2.0 supports abstraction and different viewpoints  Use case, Sequences, Sate Machine, etc. Capitalization

15. UML2.0 Component Capitalization UML2.0 can be used for specifying component based systems from analysis to deployment.

16. UML in MDE UML2.0 is used for specifying software systems without technical details (abstract analysis and design)  UML2.0 is a natural choice for building PIMs (Platform Independent Model) UML2.0 can also be used for specifying a system within its environment (use case diagram)  UML2.0 can be used for building CIM (Computational Independent Model) UML2.0 Profiles can be used for specifying platforms (ex: CORBA profile, EJB profile)  UML2.0 can be used for building PSM (Platform Specific Model) MDE can be applied with only UML2.0 Capitalization

17. Object Constraint Language OCL defines the structure of models expressing constraints  Invariant, Pre-post conditions OCL is a meta-model instance of the MOF OCL is highly coupled with UML The OCL semantic is defined with models (operation without side effect ) OCL defined a concrete syntax Capitalization PropertyCallExp > Literal -1000 ModelPropertyCall amount

18. Action Semantics AS defines the structure of models expressing sequences of actions AS was a meta-model and is now completely integrated in UML2.0 AS has no concrete syntax (UML diagram) The semantic of AS is not formally defined (an RFP is published) Capitalization

19. XMI Principles XMI (XML Metadata Interchange) provides a bridge between models and XML documents XMI defines rules for building XML Schema from meta-models Then, models instances of a meta-model can be represented in XML documents. XMI and UML There are more than 6 XMI versions of and more than 4 UML versions  Lots of combinations  That’s why exchanging UML models between tools is not trivial. XMI and diagram DI (Diagram Interchange) is an XMI extension that defines how to represent diagrams in XML. Capitalization

20. Synthesis MOF is the only standard for defining meta-models  MOF meta-models can be compared and linked ! Today, the UML meta-model is the best meta-model for specifying software systems. OCL et AS are meta-models for specifying behaviors XMI can be used to represent any models in XML documents => Everything seems to be there to capitalize know-how Capitalization

21. Productivity Frameworks and tools

22. Model Manipulation APIs MDE frameworks define principles for generating model manipulation API For each meta-model, one model manipulation API (tailored) can be generated Frameworks also define one reflective API that stands for any meta- model Productivity Meta-Model Model Java Interface Java Objets

23. Eclipse Modeling Framework Creation of a meta-model (instance of Ecore) Generation of the API  Interfaces for model manipulation  Classes integrated within Eclipse  Graphical Editor (Tree view) Can be directly used within a new Eclipse workbench Productivity

24. Model Transformations Model transformations are a central part of MDE  CIM to PIM, PIM to PSM, PSM to code. Model transformation are based on meta-models  Any UML component gives an EJB component. Platform providers should provide model transformation for their platform  UML to EJB Companies should be able to customize those transformations  Ex: Do not use entity bean! Today, there are three approaches for writing model transformations  Program, Template, Model Productivity

25. Program Model transformation is a program that makes use of model manipulation APIs Productivity PetStore EJB UMLEJB API UML API EJB Java Program read write

26. Template Model transformation is a template written in a dedicated language Productivity PetStore EJB UMLEJB Template Interpretor UML2EJB Template

27. Model Productivity PetStore EJB UMLEJB Program QVT Model QVT Model transformation is a model instance of QVT

28. Tools Today a lot of tools claim to be MDE compliant. There is no definition of what should be a MDE tool but it is interesting to see so much enthusiasm. We try:  RSA (Rational Software Architecte) that offers a UML2.0 modelers and some transformations (Java Code Generation).  Objecteering MDA Modeler that offers powerful mechanisms for packaging profiles. Productivity

29. Synthesis Thanks to MDE, models are now productive assets (no more contemplative) Model manipulation APIs are fully used in industrial contexts Model transformations are becoming more and more stable Tool providers enthusiasm has to be stressed! => Productivity is here! Productivity

30. Plateforms Frameworks and middleware

31. Y Cycle and platform Platform PIM PSM Code Requirement Analysis Design (Abstract) Design (concrete) Production (fine) PM Technical Requirements Technical Architecture PM Platform integration Platform description

32. Profile or meta-model There is no platform meta-model but only meta- models that define how to use a platform. Those meta-models are called PSM meta-models  EJB meta-model defines the structure of systems that make use of EJB platform As there is no PM (Platform Model), the Y transformation is between the PIM meta-model and the PSM meta-model Platform

33. PSM Profil vs Meta-Model Profile  PSM meta-model is a UML profile  The platform has to be close to UML (OO)  PIM to PSM transformations can be UML to UML transformations if UML is used for making the PIMs (more simple) Meta-model  PSM meta-model is a MOF meta-model  The platform can be anything (not OO)  Transformations are complex Platform

34. Synthesis Platforms are integrated partially in MDE They are represented within the PSMs It is not possible to define, within a PIM, the needed properties of a platform It is not possible to compare platforms No PIM to PSM transformations are defined by platforms providers =>More works should be done in this area!

35. Conclusion

36. MDE MDE enters an industrial phase  Know-how can be fully capitalized thanks to MOF, UML, OCL, AS and XMI  Productivity is here! MOF2.0 QVT should bridge the gap between productivity and know-how capitalization.  Platform needs more attention

37. 3 axes Know-how Productivity Platform XMI2.1 JMI UML2.0 EJB Profile QVT UML->Java MOF2.0 EMF UML1.4 MOF1.4 Corba Profile QoS Profile GenDoc UML/EJB->J2EE Applying MDE needs to fix priorities: UML2.0 is not yet productive. EMF should not be use to capitalize know-how. Platform cannot be yet totally modeled.