MDE Model Driven Engineering

1
MDE Model Driven Engineering

• Xavier Blanc
• Université Pierre et Marie Curie
• Xavier.Blanc_at_lip6.fr

2
Agenda

• MDE Architecture
• Know-how capitalization
• Productivity
• Platform
• Case Study

3
MDE Architecture

• Global view

4
Models
MDE Architecture

•  Modeling is the future, so every company thats
  working on this I think its 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

5
Practices Objectives
MDE Architecture

• 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

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
MOF
M2
QVT
M2
Software system
8
Resources
MDE Architecture

• 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.

9
Goals
MDE Architecture

• 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 !

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
Capitalization

• 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.

13
Meta-layers
Capitalization

• Mn1 defines the structure of Mn
• Mn1 is not an abstraction of Mn
• Meta-layer relationships are similar to
  grammar-layer relationships (BNF, or XML Schema)

Meta-meta-model
Meta-model
Model
14
UML2.0
Capitalization

• 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.

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

• 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

17
Object Constraint Language
Capitalization

• 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

18
Action Semantics
Capitalization

• 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)

19
XMI
Capitalization

• 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
• Thats 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.

20
Synthesis
Capitalization

• 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
• gt Everything seems to be there to capitalize
  know-how

21
Productivity

• Frameworks and tools

22
Model Manipulation APIs
Productivity

• 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

Meta-Model
Java Interface
Java Objets
Model
23
Eclipse Modeling Framework
Productivity

• 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

24
Model Transformations
Productivity

• 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

25
Program
Productivity

• Model transformation is a program that makes use
  of model manipulation APIs

APIUML
APIEJB
write
read
Java Program
26
Template
Productivity

• Model transformation is a template written in a
  dedicated language

UML2EJBTemplate
Template Interpretor
27
Model
Productivity

• Model transformation is a model instance of QVT

QVT Model
Program
28
Tools
Productivity

• 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.

29
Synthesis
Productivity

• 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!
• gt Productivity is here!

30
Plateforms

• Frameworks and middleware

31
Y Cycle and platform
Platform
Technical Requirements
Requirement
Analysis
Technical Architecture
Design (Abstract)
Platform description
Design (concrete)
Platform integration
Production (fine)
Code
32
Profile or meta-model
Platform

• 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

33
PSM Profil vs Meta-Model
Platform

• 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

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
• gtMore 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

• 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.

UML2.0
QVT
MOF2.0
XMI2.1
GenDoc
QoS Profile
UML1.4
EMF
MOF1.4
EJB Profile
JMI
Corba Profile
Productivity
UML-gtJava
UML/EJB-gtJ2EE
Platform