Introduction

1
Introduction à lingénierie dirigée par les
modèles
Merci à Jean Bézivin pour mettre à notre
disposition une partie de ses présentations !
2
Plan

• MDA
• MDE

• Motivations de lapproche par modèles
• Le MDA de lOMG (Model Driven Architecture)
• Le MDE (Model Driven Engineering)

3
Le développement de logiciels

• MDA
• MDE

• Systèmes de plus en plus complexes
• Volumineux
• Données
• Code
• Évolutifs
• La partie fonctionnelle
• La partie non fonctionnelle
• Hétérogènes
• Langages
• Stockage et gestion des données
• Plateformes

4
Technologies à complexité croissante

• MDA
• MDE

1980
1995
Technologie procédurale
Technologie des composants
Technologie des objets
Beans, Components, Containers, Packages, Interface
s, Use cases, Scenarii,Services, Frameworks, Appli
cations, Patterns, Aspects, etc.
Objets, Classes, Méthodes
Procédures
5
Une hypothèse fausse

• MDA
• MDE

Hypothèse Il y a correspondance exacte entre
les objets métier et les objets programme.
x
objet abstrait
analyse
Conséquence (fausse) il est possible de
"raffiner" les objets comme on raffinait
autrefois les procédures.
x'
conception
x''
objet concret
codage
6
Une hypothèse fausse

• MDA
• MDE

7
Les limites des objets

• MDA
• MDE

• On a pas réussi le  tout est objet 
• Les patrons de conception ne sont pas des objets.
• Les aspects ne sont pas des objets.
• Les applications ne sont pas des objets.
• Les services ne sont pas des objets.
• Les objets ont échoué dans la recherche de
  simplicité, dextensibilité, d'intégration.

8
Les technologies middleware

• MDA
• MDE

• Toujours en quête de portabilité,
  interopérabilité, séparation du code fonctionnel
  du non fonctionnel, etc.
• Prolifération des technologies middleware

• Sun
• J2SE, J2EE
• W3C
• Schéma XML, WSDL, etc.
• OMG
• Modèle à composants CORBA
• Microsoft
• COM, .NET
• Sun et OMG
• RMI et IIOP

Changement de plateforme de plus en plus
fréquent !
Aucune technologie na gagné !
9
MDA de lOMG(Model Driven Architecture)
10
(No Transcript)
11
OMG les membres

• Fondé à linitiative de 11 grandes sociétés
  états-uniennes BGV97 American Airlines,
  Canon, Data General, Gold Hill Hewlett-Packard,
  Philips, Prime, Sun, Soft-switch Unisys, 3Com.
• Actuellement plus de 700.
• Organisation indépendante et ouverte à tous.
• Cotisation de 500 à 75000 annuels selon
  linfluence.

12
OMG les objectifs

• Objectif fondamental interopérabilité
  dapplications à objets (intégration).
• Objectifs initiaux
• Interopérabilité des applications à objets
  hétérogènes.
• Mettre fin à la cacophonie des langages à objets
  (programmation, modélisation).
• Normaliser les systèmes, les langages à objets.
• Objectifs actuels
• Interopérabilité des développements à objets.
• Normaliser les processus de développement.
• Normaliser les modèles et leurs échanges.

13
OMG le processus de normalisation

• Identification du problème.
• Le Comité Technologique TC (Technology Committee)
  charge un groupe de travail TF (Task Force) de
  faire des recommandations dans un domaine
  technologique particulier. Seuls les membres
  influents peuvent les proposer.
• Creation de la RFP (Request For Proposal)
• Le TF élabore une RFP avec éventuellement et au
  préalable une étude RFI (Request For
  Information). La RFI viser à collecter des
  informations dans lindustrie. La RFP aboutit
  ensuite à lélaboration dune proposition de
  norme soumise à lOMG.
• Approbation de la RFP
• La RFP est soumise à lAB (Architecture Board),
  aux TFs et aux TC, qui après étude et
  modifications votent la recommandation de la
  spécification.

14
OMG le processus de normalisation

• Soumissions de la RFP
• Les membres peuvent répondre à la RFP par une
  lettre dintention LOI (Letter Of Intent) puis
  une soumission initiale. Ces soumissions sont
  ensuite revues jusquà obtenir une soumission
  finale votée.
• Finalisation de la RFP
• La finalisation est assurée par la FTF
  (Finalization Task Force) qui rend disponible la
  norme.
• Post-adoption de la RFP
• La révision est assurée par la RTF (revision task
  force) qui effectue des modifications mineures.

15
OMG les activités

• Deux grandes générations à lOMG
• Avant 2000 le modèle OMA Object Management
  Architecture interopérabilité entre applications
  à objets développées sur des réseaux hétérogènes
• CORBA 1.1 -gt CORBA 3.0
• IDL
• Progressivement le MDA
• Normalisation des langages UML, OCL, XMI
• Réflexion sur les langages MOF
• Adaptation et personnalisation CWM
• Réflexion sur les processus SPEM
• Multiplication des middleware (CORBA, EJB, SOAP,
  COM, .NET...)

16
Pourquoi le MDA ?

• Motivation
• MDE

• CORBA na pas complètement réussi.
• Les EJB et .NET sont également largement
  répandus.
• Toujours en quête de portabilité,
  interopérabilité, séparation du code fonctionnel
  du non fonctionnel, etc.
• Idée -gt Monter en niveau dabstraction !

L'initiative MDA de l'OMG vise à promouvoir
l'idée de la mise en œuvre de systèmes
distribués dirigée par les modèles.
17
Du centré code au centré modèle

• Motivation
• MDE

interface Compte attribute short
numéro attribute float solde
IDL sémantiquement léger par définition
UML (OCL) CORBA sémantiquement enrichi
18
Modèle

• Motivation
• MDE

• Un modèle est la représentation dun système.
• Lobjectif dun modèle est de répondre à
  certaines questions à la place du système quil
  représente.
• Avec MDA, le développement de systèmes est dirigé
  par les modèles.
• Les modèles doivent diriger la conception, la
  construction, le déploiement, la maintenance, etc.

19
Le MDA et les plateformes

• Motivation
• MDE

• MOF et UML constituent le cœur de la technologie
  MDA.
• Hypothèse Des modèles technologiquement
  neutres peuvent être mis en œuvre sur une grande
  variété de technologies de plates-formes.
• La transformation de modèles comme concept clé
  dans cette mise en œuvre.

Modèles neutres basés sur UML et MOF
Java EJB
COM DCOM
HTTP HTML
C DotNet
XML SOAP
20
Processus MDA

• Motivation
• MDE

• Séparer les besoins applicatifs dun système des
  détails de la plateforme utilisée.
• Spécification des systèmes indépendamment des
  plateformes
• Spécification des plateformes
• Choix dune plateforme en particulière
• Transformation de la spécification du système
  vers une autre en utilisant une plateforme
  spécifique

21
Les modèles MDA

• Motivation
• MDE

• PIM (Platform Independent Model)
• Spécification neutre d'un système (modèle de
  métier et de service) qui ignore tous les détails
  de mise en œuvre.
• Exemple système de facturation exprimé en UML .
• PSM (Platform Specific Model)
• Modèle de métier et de service lié à un modèle de
  plate-forme.
• Exemple Système de facturation exprimé en "UML
  profile pour CORBA".

22
Patron de comportement MDA

• Motivation
• MDE

• La transformation de modèles est le processus qui
  transforme un modèle en un autre modèle.
• La transformation du PIM vers PSM peut être
  complétée par dautres informations comme celles
  relatives au mapping entre le PIM et le PSM ou à
  la description de la plateforme (PDM).
• Le PIM doit persister à lapparition de nouveaux
  PSM.

PDM (Platform Description Models)
23
Interopérabilité entre les modèles
PIM
Transformation
Transformation
Ponts
Transformation
Transformation
Ponts
24
Du contemplatif au productif

• Motivation
• MDE

Du compréhensible pour lhomme au compréhensible
pour les machines
25
Questions

• Motivation
• MDE

• Un seul type de modèle ?
• NON
• Modèle de données relationnel (tables, colonnes,
  ), workflow (activités, exécuteur, transition,
  split, join, ), class UML (class, attribut,
  opération, association, ), interfaces CORBA
  (interface, types, méthodes, ), etc.
• Un seule langage de modélisation ?
• NON
• DSL (Domain Specific Language).
• Comment organiser les modèles ?
• Comment échanger de modèles ?
• Comment relier les modèles ?

26
Architecture à 4 niveaux

• Motivation
• MDE

Architecture égyptienne
27
MOF (Meta Object Facility)

• Motivation
• MDE

• Constitue la fondation de larchitecture de
  métamodélisation de lOMG.
• Est un métamétamodèle général de base qui permet
  la définition de modèles et de métamodèles.
• A emprunté le cœur du diagramme de class dUML
  (package, class, association, type de données,
  référence, etc.).
• Rend possible léchange de modèles,
  linteropérabilité, etc.

28
Métamodèle MOF
29
Principales entités du MOF
Package
Contient
Class
MOFAttribute
Définie par
Operation
Déclenche
Reference
Association
Définie par
Exception
Data Type
30
Les associations du MOF

• Generalizes
• Définie une relation dhéritage applicable aux
  éléments de type de classes et de type de
  packages. Même si les types de données et les
  associations sont des sous-types de
  GeneralizableElement, le MOF ne permet pas
  lhéritage pour ces entités.
• Contains
• Permet de rattacher les classes, associations et
  autres entités MOf pouvant être définis dans un
  paquetage à un autre paquetage. Elle permet
  également de rattacher les attributs et
  opérations à leur classe ou encore les paramètres
  à leur opération.
• DependsOn
• Permet de représenter les dépendances entre les
  éléments de modélisation.
• IsTypeOf
• Permet de relier un élément de modélisation typé
  (un attribut, un paramètre, une constante) à son
  type (une classe ou un type de données).

31
Les associations du MOF

• Exposes et RefersTo
• Permettent de faire le lien entre une référence
  et les deux extrémités de lassociation liées à
  cette référence (lextrémité exposée et
  lextrémité référencée).
• CanRaise
• Permet de relier une opération aux exceptions
  quelle est susceptible de lever.
• Aliases
• Permet de relier un objet import à lélément
  quil permet dimporter.
• Constraints
• Permet de relier un élément de modélisation aux
  contraintes qui le référencent.
• AttachesTo
• Permet dassocier un élément de modélisation aux
  tags qui le référencent.

32
Modèle -gt Métamodèle

• Motivation
• MDE

MM UML
Relation de conformitéentité ? métaentité
1
Class
Attribute

Relation de conformitémodèle ? métamodèle
metameta model
M3
M2
metamodel
M1
model
33
Métamodèle -gt Métamétamodèle

• Motivation
• MDE

Relation de conformitéentité ? métaentité
Relation de conformitémodèle ? métamodèle
metameta model
M3
M2
metamodel
M1
model
34
Métamétamodèle -gt Métamétamodèle

• Motivation
• MDE

Relation de conformitéentité ? métaentité
MOF
Relation de conformitémodèle ? métamodèle
source
Class
Association
destination
metameta model
M3
M2
metamodel
M1
model
35
Les trois niveaux de modélisation

• Motivation
• MDE

Niveau M3
Niveau M2
Niveau M1
Niveau M0
36
La pile de modélisation MDA

• Motivation
• MDE

• Un métamétamodèle unique conforme à lui même.
• Une importante bibliothèque de métamodèles
  compatibles conformes au MOF.
• Chaque modèle est défini dans le langage de son
  unique métamodèle.

37
MDA

• Motivation
• MDE

• Ce logo représente les différentes couches de la
  spécification MDA
• Le cœur UML, MOF et CWM
• Autour quelques unes des plateformes supportées
  CORBA, Services web, .NET, XMI/XML, etc.
• En surface les services systèmes Transactions,
  Événements, Sécurité, etc.
• A lextérieur les domaines pour lesquelles des
  composants fonctionnels doivent être définis
  Finance, Commerce électronique,
  Télécommunications, etc.

38
Les espaces technologiques
39
Généralisation de lapproche MDA

• Motivation
• MDA

• Est-il possible didentifier les niveaux à la MDA
  dans dautres contextes ?
• Contexte espace technologique
• Certains espaces technologiques sont clairement
  structurés, dautres sont moins structurés ou non
  structurés.

40
Grammarware (programmation)

• Motivation
• MDA

Conforms to
productionRule IDENT sequence sequence
alternative sequence? alternative rep
(alternative)? rep atom (? )? atom
terminal ( sequence ) terminal
STRING IDENT
M3
Conforms to
petrinet petrinet place
transition arcPT arcTP place
place IDENT transition transition
IDENT arcPT arcPT IDENT -gt
IDENT arcTP arcTP IDENT -gt IDENT
M2
Classical representation
Conforms to
petrinet place P1 place P2 transition
T1 arcPT P1 -gt T1 arcTP T1 -gt P2
P1
Rep of
T1
System
P2
M1
41
Docware (XML)

• Motivation
• MDA

ltxselement nameelement"gt
ltxscomplexTypegt ltxsattribute namename
typexsstring"/gt
lt/xscomplexTypegt lt/xselementgt
Conforms to
M3
Conforms to
ltxselement nameplace"gt ltxscomplexTypegt
ltxsattribute namename
typexsstring"/gt lt/xscomplexTypegt
lt/xselementgt
M2
Classical representation
Conforms to
ltpetrinetgt ltplace nameP1/gt ltplace
nameP2/gt lttransition nameT1/gt ltarcPT
sourceP1 targetT1/gt ltarcTP sourceT1
targetP2/gt lt/petrinetgt
P1
Rep of
T1
System
P2
M1
42
Espaces technologiques

• Motivation
• MDA

M3
M2
M1
Conforms to
Aucun espace technologique est une île !
43
Même concept différent espace technologique

• Motivation
• MDA

• Si la correspondance est exacte, il est possible
  de convertir les modèles dun espace
  technologique à un autre.

XML
EBNF
MOF
DTD JavaML
Grammaire Java
métamodèle Java
Document JavaML
Programme Java
Modèle Java
A suivre
Projections
44
Résumé sur lévolution du génie logiciel
45
Évolution des techniques de génie logiciel

• Procedural refinement (1950-1980)
• Top-down programming
• Architecture based on procedural refinement are
  very sensible to modifications (Jackson, Meyer)
• Object composition (1980-2000)
• The complexity of object architectures lies not
  inside the indivual objects, but in the complex
  relations between them
• Patterns, Components, etc.
• Model transformation (2000-?)
• Any artifact belongs to a specific model
• Models are first class entities in the software
  development
• Models are derived from other models by
  transformation operations

46
De lapproche procédurale à la transformation des
modèles
2000
1980
1995
Technologie procédurale
Technologie des composants
Technologie des objets
Technologie Des modèles
Objets, Classes, Smalltalk, C, ...
Procédures, Pascal, C, ...
Paquetages, Frameworks, Patrons,
Modèles, Méta-Modèles, UML, MOF, XML, XMI, XSLT,
Raffinement procédural
Composition d'objets
Transformation de modèles
47
Références

• David S. Frankel. Model Driven Architecture
  Applying MDA to Enterprise Computing. Wiley
  Publishers, ISBN 0-471-31920-1, 2003.
• http//www.omg.org/mda/
• Kadima, Hubert. MDA Conception Orientée Objet
  Guidée Par Les Modèles. Éditeur Dunod, 2005