Chapitre 2

Introduction et concepts de base de l’IDM

1
 Introduction
• De la programmation à la modélisation
– Taille et complexité des systèmes logiciels:
évolution exponentielle
– Besoin de maitriser les coûts et la qualité
– Solution: composants logiciels
• Nouveaux problèmes:
– Composants: interactions complexes
– Problèmes extra-fonctionnels: fiabilité, sécurité,
consommation d’énergie, etc

2
 Introduction
– Maitriser la complexité: Modélisation
– Modélisation: Utilisation efficace d’une
représentation simplifiée d’un aspect du monde
réel pour un objectif donné.
• Exp: Architecture logicielle (fin 1960) = Modèle des
composants d’un système informatique, de leurs
interrelations et leurs interactions.

3
 Introduction
– Aujourd’hui: un système complexe est modélisé selon
plusieurs points de vue
• Structurel, dynamique, fonctionnel, etc
• Ces points de vue peuvent varier en terme de:
– Abstraction: idées ou concepts, interfaces, composants abstraits,
composants logiciels physiques
– Précision: ébauche, solution à améliorer ou solution finale
– La modularité des développements peut alors être
abordée par la séparation explicite des
préoccupations et par l’utilisation pour chacune
d’entre elles d’un langage dédié (Domain Specific
Modeling Language) offrant des concepts spécifiques
ayant le meilleur niveau d’abstraction pour le
développeur.
4
 Introduction
• De la modélisation à l’Ingénierie Dirigée par
les Modèles (IDM)
– Enjeu: capitaliser les savoir-faire de conception et
de validation des systèmes logiciels
• Capturer et réutiliser les connexions entre les différents
points de vue de manière:
– Horizontale: par tissage de lien entre modèles
– Verticale: par transformation de modèle
– Télécom: longue expérience
– Généralisation à l’ensemble de l’industrie: début!

5
 Principes de l’IDM
• Capitalisation, réutilisation de (parties de) modèles :
logique métier, règles de raffinements, ...
• Abstraction: exp. abstraction des technologies de mise
en œuvre afin d'évoluer bien plus facilement vers de
nouvelles technologies
• Modélisation: La modélisation n'est pas une discipline
récente en GL, mais c’est l’usage de ces modèles qui
change.
– Passer d'une vision contemplative des modèles
(documentation, spécification, communication) à une
vision réellement productive afin de générer le code final
du logiciel pour une technologie de mise en œuvre donnée

6
 Principes de l’IDM
• Séparation des préoccupations: 2 principales
préoccupations:
– Métier : le cœur de l'application, sa logique
– Plate-forme de mise en œuvre
– Mais plusieurs autres préoccupations possibles
• Sécurité
• Interface utilisateur
• Qualité de service
• …
– Chaque préoccupation est modélisée par un modèle
• Intégration des préoccupations par transformation/fusion/tissage
de modèles
• Conception orientée aspect

7
 Principes de l’IDM
• Pour passer à une vision productive, il faut
que les modèles soient bien définis (notion de
méta-modèle) afin que l'on puisse les
manipuler et les interpréter via des outils et
langages de transformation et de génération
de code ainsi que des langages dédiés à des
domaines (DSL : Domain Specific Language).

8
 Les concepts
• Modèle
• Méta-modèle
• Transformation de modèle

9
 Les concepts
• Les années 80: approche objet
• Aujourd’hui: le GL s’oriente vers l’IDM
• Objet -> IDM: continuité ou rupture?
– En continuité: évolution objet -> modèle
• Classification des objets en fonction de leurs origines
(objets métiers, techniques, etc).
– En rupture: séparation des préoccupations
• Fournir un grand nombre de modèles pour exprimer
séparément chacune des préoccupations des
utilisateurs, des concepteurs, des architectes, etc.

10
 Modèle
• Approche objet: fondée sur les relations
d’instanciation et d’héritage
• Concept central de l’IDM: le modèle
• Modèle: pas de définition universelle
• Une définition: « Un modèle est un ensemble de
faits caractérisant un aspect d’un système dans
un objectif donné. Un modèle représente donc un
système selon un certain point de vue, à un
niveau d’abstraction facilitant par exemple la
conception et la validation de cet aspect
particulier du système. »
11
 Modèle
• Un modèle est une description, une
spécification partielle d'un système
– Abstraction de ce qui est intéressant pour un
contexte et dans un but donné
– Vue subjective et simplifiée d'un système
• But d'un modèle
– Faciliter la compréhension d'un système
– Simuler le fonctionnement d'un système

12
Modèle

13
Modèle

14
 Modèle
• Relation entre un système et un modèle:
ReprésentationDe (notée µ)

15
 Modèle
• Un modèle représente un système modélisé
– De manière générale, pas que dans un contexte de
GL ou d'informatique
– Un modèle peut aussi avoir le rôle de système
modélisé dans une autre relation de
représentation
<MAP name=‘’Bejaia’’
taille=‘’30x30’’>
<daira>
<commune>
…
</daira>

16
 Modèle
• Une carte est un modèle (une représentation) de
la réalité, avec une intention particulière (carte
routière, administrative, des reliefs, etc)
• Question: qu’est ce qu’un bon modèle?
• Réponse: principe de substituabilité
– Un modèle doit capturer les informations nécessaires
et suffisantes pour permettre de répondre aux
questions que l’on se pose sur un aspect du système
qu’il représente, exactement de la même façon que le
système lui-même aurait répondu.

17
 Modèle
• En ingénierie, un système complexe est
décomposé en autant de modèles que
nécessaire pour aborder efficacement toutes
les préoccupations pertinentes.
• Ces modèles peuvent être exprimés avec:
– Un langage de modélisation généraliste comme
UML
– Des langages de modélisation spécifiques à des
domaines DSML (Domain Specific Modeling
Language)
18
 Modèle
• Modélisation = séparation des préoccupations
dans le domaine du problème (Analyse)
• Si les solutions à ses préoccupations peuvent
être décrites comme des aspect, le processus
de conception peut alors être caractérisé
comme le tissage (Weaving) de ces aspects
dans un modèle de conception détaillée
(espace de la solution).

19
 Modèle

Modéliser plusieurs aspects

20
 Modèle

• Le défi abordé n’est pas comment concevoir un

système pour prendre en compte un aspect
particulier, il existe en effet dans l’industrie
d’importants savoir-faire, souvent capturés sous
la forme de patrons de conception.
• Le vrai défi est plutôt lié au besoin fréquent de
s’adapter au changement des exigences.
• Changement = nouveau choix de variante ou de
version d’une variante par aspect du système.
21
 Modèle

• Nécessite une recomposition des aspect

• Résultat = nouvelle configuration = nouveau
produit dans une ligne de produit.
• Ce nouveau produit doit être obtenu
rapidement, de manière fiable, et à bon
marché.
• Problème: difficile de faire la composition
manuelle de chaque aspect.

22
 Modèle

• L’IDM ne propose pas de résoudre ce problème

directement, mais simplement de mécaniser et
de reproduire le processus que les concepteurs
expérimentés suivent à la main.
• L’idée est alors que lorsqu’une nouvelle variante a
besoin d’etre dérivée dans une ligne de produits,
on peut automatiquement rejouer la plus grosse
partie de ce processus de conception, en
apportant juste quelques petites modifications.

23
 Modèle

• Usuellement en sciences, un modèle a une

nature différente de la réalité qu’il modélise
(par exp. le plan d’une maison Vs la maison
elle-même).
• En GL par contre, un modèle a la même nature
que la réalité qu’il modélise.
• Ceci ouvre la possibilité de dériver
automatiquement du logiciel depuis un
modèle.

24
 Modèle

• Il s’agit de rendre les modèles « productifs » en

automatisant ce processus de tissage.
• Cette automatisation devient possible que si les
modèles ne soient plus informels.
• Cela implique que le processus de tissage soit lui-
même décrit comme un programme manipulant
ces modèles pour produire une conception
détaillée.
• Cette conception pourra être finalement
transformée en code, en configuration de logiciel,
en suite de tests,etc.
25
 Modèle

Concevoir revient à tisser des modèles

26
 Métamodèle
• Pour qu’un modèle soit « productif », il doit
pouvoir être manipulé par une machine.
• Le langage dans lequel ce modèle est exprimé
doit donc être explicitement défini.
• De manière naturelle, la définition d’un
langage de modélisation a pris la forme d’un
modèle, appelé « métamodèle ».

27
 Métamodèle
• Définition: Un métamodèle est un modèle qui
définit le langage d’expression d’un modèle
*OMG+, c’est-à-dire le langage de
modélisation.
• La notion de métamodèle conduit à
l’identification d’une relation liant le modèle
et le langage utilisé pour le construire,
appelée: conformeA et nommée 

28
 Métamodèle
Légende

représentationDe

conformeA

Relations entre système, modèle, métamodèle et langage

29
 Métamodèle
• En cartographie, il est indispensable d’associer
à chaque carte la description du « langage »
utilisé pour la réaliser. Ceci se fait notamment
sous la forme d’une légende.
• Pour être utilisable, la carte doit être
conforme à cette légende.
• Plusieurs cartes peuvent être conformes à une
même légende.

30
 Métamodèle
• La légende est alors considérée comme un
modèle représentant cet ensemble de cartes 
et à laquelle chacune d’entre elles doit se
conformer  .
• C’est sur ces principes de base que s’appuie
l’OMG pour définir l’ensemble de ses
standards, en particulier UML (Unified
Modeling Language) dont le succès industriel
est largement reconnu.

31
• Cette relation de conformité est essentielle
• Mais pas nouvelle
– Un texte écrit est conforme à une orthographe et une
grammaire
– Un programme Java est conforme à la syntaxe et la
grammaire du langage Java
– Un fichier XML est conforme à sa DTD
– Une carte doit être conforme à une légende
– Un modèle UML est conforme au méta-modèle UML

32
• Exemple avec un langage de programmation
– Un programme Java modélise/simule un système (le
programme à l'exécution)
– Un programme Java est conforme à la grammaire du
langage Java
– La grammaire de Java modélise le langage Java et
donc tous les programmes valides
– Le programme Java appartient à cet ensemble
• Exemple avec UML
– Un diagramme UML modélise un système
– Un diagramme UML est conforme au méta-modèle UML
– Le méta-modèle UML définit l'ensemble des modèles
UML valides
– Un modèle UML appartient à cet ensemble

33
 Les concepts de l'IDM en une image
«One and Three Chairs, Joseph Kosuth, 1965»

34
 Principales normes de modélisation
OMG
• MOF : Meta-Object Facilities
– Langage de définition de méta-modèles
• UML : Unified Modelling Language
– Langage de modélisation
• CWM : Common Warehouse Metamodel
– Echange de métadonnées à travers un entrepôt de données,
un système décisionnel, un système d'ingénierie des
connaissances (Gestion des connaissances), ou des technologies
de portail.
• OCL : Object Constraint Language
– Langage d’expression de contraintes sur modèles
• XMI : XML Metadata Interchange
– Standard pour échanges de modèles et méta-modèles
entre outils

35
 Hiérarchie de modélisation à 4
niveaux
• L'OMG définit 4 niveaux de modélisation
– M0 : système réel, système modélisé
– M1 : modèle du système réel défini dans un certain
langage
– M2 : méta-modèle définissant ce langage
– M3 : méta-méta-modèle définissant le méta-modèle
• Le niveau M3 est le MOF
• Dernier niveau est méta-circulaire : il peut se définir par lui-
même
• Le MOF est pour l'OMG le méta-méta-modèle
unique servant de base à la définition de tous les
méta-modèles
36
Pyramide de modélisation de l’OMG

37
 Exemple
• Exemple de système réel à modéliser (niveau M0)
– Une pièce possède 4 murs, 2 fenêtres et une porte
– Un mur possède une porte ou une fenêtre mais pas
les 2 à la fois
– Deux actions sont associées à une porte ou une
fenêtre : ouvrir et fermer
– Si on ouvre une porte ou une fenêtre fermée, elle
devient ouverte
– Si on ferme une porte ou une fenêtre ouverte, elle
devient fermée

38
• Pour modéliser ce système, il faut définir 2
diagrammes UML : niveau M1 (Spec du système)
– Un diagramme de classe pour représenter les
relations entre les éléments (portes, murs, pièce)
– Un diagramme d'état pour spécifier le comportement
d'une porte ou d'une fenêtre (ouverte, fermée)
– On peut abstraire le comportement des portes et des
fenêtres en spécifiant les opérations d'ouverture
fermeture dans une interface
– Le diagramme d'état est associé à cette interface
– Il faut également ajouter des contraintes OCL pour
préciser les contraintes entre les éléments d'une pièce

39
40
• M2 : Méta-modèle UML (une partie simplifée)

41
• Chaque élément du modèle
– Est une « instance » d'un élément du méta-
modèle (d'un méta-élément)
– En respectant les contraintes définies dans le
méta-modèle

42
43
Extrait méta-modèle UML 2.0 pour les
machines à états

44
 Méta-modélisation UML
• Le méta-modèle UML doit aussi être précisément
défini
– Il doit être conforme à un méta-modèle
– C'est le méta-méta-modèle UML (Niveau M3)
• Qu'est ce que le méta-modèle UML ?
– Un diagramme de classe UML (avec contraintes OCL)
• Comment spécifier les contraintes d'un diagramme de
classe UML ?
– Via la partie du méta-modèle UML spécifiant les
diagrammes de classes
• Méta-méta-modèle UML = copie partielle du
métamodèle UML

45
M3 : Méta-méta-modèle UML
(simplifié)

46
 Méta-modélisation UML
• Méta-méta-modèle UML doit aussi être clairement défini
– Il doit être conforme à un méta-modèle
• Qu'est ce que le méta-méta-modèle UML ?
– Un diagramme de classe UML
• Comment spécifier les contraintes d'un diagramme de
classe ?
– Via la partie du méta-modèle UML spécifiant les diagrammes
de classe
• Cette partie est en fait le méta-méta-modèle UML
• Le méta-méta-modèle UML peut donc se définir lui-même
– Méta-circulaire
– Pas besoin de niveau méta supplémentaire

47
Hiérarchie de modélisation

48
 Définition de méta-modèles
• But : définir un type de modèle avec tous ses types
d'éléments et leurs contraintes de relation
• Plusieurs approches possibles:
– Définir un méta-modèle nouveau à partir de « rien », en se
basant sur un méta-méta-modèle existant (MOF ou Ecore)
– Modifier un méta-modèle existant : ajout, suppression,
modification d'éléments et des contraintes sur leurs
relations
– Spécialiser un méta-modèle existant en rajoutant des
éléments et des contraintes (sans en enlever)
• Correspond aux profils UML

49
Transformations de modèles

50
• Une transformation est une opération qui
– Prend en entrée des modèles (source) et fournit en sortie des
modèles (cibles)
– Généralement un seul modèle source et un seul modèle cible
• 2 types:
– Transformation endogène
• Dans le même espace technologique
• Les modèles source et cible sont conformes au même métamodèle
– Ex : transformation d'un modèle UML en un autre modèle UML
– Transformation exogène
• Entre 2 espaces technologique différents
• Les modèles source et cible sont conformes à des méta-modèles
différents
– Ex : transformation d'un modèle UML en programme Java
– Ex : transformation d'un fichier XML en schéma de BDD

51
• Autre classification:
– Model-to-Text
• Edition du modèle pour impression/diffusion
– Mise en forme du modèle
• Rapport d’évaluation
– Analyse du modèle
• Génération de code
– Modèle de conception ou de programmation
– Traduction vers un langage cible
Mise en œuvre:
 Analyse syntaxique du modèle
 Génération de fichiers (.txt, .doc, .xmi, .html, .java …)

52
– Model-to-Model
• Abstraction : extraire un point de vue
– Modèle de la structure, modèle de QoS, …
• Fusion de modèles : intégration de divers aspects
– Intégration de politiques de sécurité, …
• Refactoring : améliorer la structure du modèle
– Renommage
– Application de design pattern
– Simplifications (factorisation d’attributs dans une classe mère, …)
• Raffinement : enrichir et préciser le modèle
– Intégration d’aspects technologique (MDA)
» Plateformes d’exécution et de communication
• Traduction et interprétation : passage d’un monde à un autre
– Changement de version, …
 Mise en œuvre:
 Analyse syntaxique et sémantique du modèle
 Génération d’un nouveau modèle défini lui-même par un méta-modèle

53
 Transformations : types d'outils
• Langage de programmation « standard »
– Ex : Java
– Pas forcément adapté pour tout
– Sauf si interfaces spécifiques
• Ex : JMI (Java Metadata Interface) ou framework Eclipse/EMF
• Langage dédié d'un atelier de génie logiciel
– Ex : J dans Objecteering
– Souvent propriétaire et inutilisable en dehors de l'AGL
• Langage lié à un domaine/espace technologique
– Ex: XSLT dans le domaine XML, AWK pour fichiers texte ...
• Langage/outil dédié à la transformation de modèles
– Ex : standard QVT de l'OMG, ATL
• Atelier de méta-modélisation avec langage d'action
– Ex : Kermeta

54
• 3 grandes familles de modèles et outils associés
– Données sous forme de séquence
• Ex : fichiers textes (AWK)
– Données sous forme d'arbre
• Ex : XML (XSLT)
– Données sous forme de graphe
• Ex : diagrammes UML
• Outils
– Transformateurs de graphes déjà existants
– Nouveaux outils du MDE et des AGL (QVT, J, ATL, Kermeta ...)

55
 Techniques de transformations
• 3 grandes catégories de techniques de transformation
– Approche déclarative
• Recherche de certains patrons (d'éléments et de leurs relations)
dans le modèle source
• Chaque patron trouvé est remplacé dans le modèle cible par une
nouvelle structure d'élément
• Ecriture de la transformation « assez » simple mais ne permet pas
toujours d'exprimer toutes les transformations facilement
– Approche impérative
• Proche des langages de programmation usuels
• On parcourt le modèle source dans un certain ordre et on génère le
modèle cible lors de ce parcours
• Ecriture transformation peut être plus lourde mais plus adaptée aux cas
comlexes
– Approche hybride : à la fois déclarative et impérative
• La plupart des approches déclaratives offrent de l'impératif en complément
car plus adapté dans certains cas

56
 Transformations en EMF
• Plusieurs langages pour le framework EMF/Ecore
– Directement via le framework Java EMF
• Chaque élément du méta-modèle Ecore correspond à une classe Java
avec ses interfaces d'accès aux éléments de modèles
• Pb : reste de la programmation en Java, pas totalement adapté à la
manipulation de modèles
– Langages de plus haut niveau:
• ATL : approche déclarative
– Une règle de transformation sélectionne un élément dans le source et
génère un (ou plusieurs) élément(s) dans le cible
– La sélection se fait par des query OCL
• Kermeta : approche impérative
– Langage de programmation orienté-objet
– Primitives dédiées pour la manipulation de modèles
– Ajout d'opérations/attributs sur méta-éléments par aspect
– Intègre aussi un langage de contraintes similaire à OCL

57
 Techniques de transformations
• M2T
– Basé sur des parseurs existants
• XML/XSLT
– Basé sur des langages de programmation
• API Java d’EMF
– Basé sur des templates de transformations
• JET/Acceleo sous EMF
• M2M
– Basé sur des langages de transformations
• QVT (Query-View-Transformation) / ATL/ Kermeta, …

58
 Technique M2T : templates
• Un template = une structure à base de textes à générer et de meta-
données
• Structure proche de la structure du code généré
• Syntaxe Acceleo:

– file : fichier généré

– rc possède un attribut name
– Si l’attribut name de la EClassRoot s’appelle a1 pour le modèle considéré
=> Création du fichier report_a1.txt qui contient la ligne « texte»

59
• Utilisations possibles des templates
– Génération de code
• Modèle de programmation vers un langage cible
• Modèle de conception vers un langage cible
– Génération de documentation
• Edition du modèle
• Mais l’utilisation reste limitée à la génération
de texte
– Comment rester au niveau des modèles ?
60
• M2M
– Meta-model(modelA) to meta-model(modelB)
– Exp.

61
 ATL
ATLAS Transformation Language

62
• ATL : Langage de transformation de modèles
inspiré par le standard QVT
• Développé par OBEO et INRIA
• Disponible en tant que plugin dans le
projet Eclipse
• Hybride

63
• Principe:

64
 Structure d’une transformation
• Déclaration du module
– Header section
• Import de librairies
– Import section
• Opérations
– Helpers
• Règles de transformation
– Rules

65
 Header section
• Header Section
– Le nom du module est obligatoirement le même
que le nom du fichier

• Import librairies

66
• Opération : helper
– Défini pour un context donné
• Opération pour une EClass donnée

• Exp

67
• Exp

68
• Données : helper
– Pas de paramètre
– Référence à la donnée dans les opérations
• Si pas de contexte : thisModule.dataName

– Exp

69
 Expressions et données
• Données
– Types OCL
• Boolean : true, false
– and , or , xor, not
• Integer et Real
– * + - / max(), min(), div(), abs()
– Pour exprimer –x : 0 – x
– Opérations ATL sur Real
» cos() sin() tan() atan() asin() exp() log() sqrt() toDegrees()
toRadians()
• String : ‘Hello’
– size() + concat() substring(lower,upper) toInteger …

70
• Expressions
– Expression OCL
• Différent : <>
• Opérations ATL spécifiques de retour pour String
– chaine.writeTo(fileName) -- écriture de chaine dans le fichier
fileName
– chaine.println() -- affichage de chaine sur la console

71
• Déclaration de variable dans une expression
– OCL déclaration

– Exp: SetNumber renvoie l’attribut number pour un

élément de type C s’il est défini et non nul, le
paramètre id sinon

72
 L’opération élémentaire de
transformation : la règle ATL
• Un programme de transformation ATL est
composé de règles.
• Règles: spécifient comment les éléments du
modèle source sont reconnus et parcourus
pour créer et initialiser les éléments du
modèle cible.

73
 Règles de génération
• Règle de génération (1 -> 1)

74
• Initialisation des attributs
– Directement à partir des attributs de inVar
– Par appel d’un helper

75
• Principes des règles de transformations:
– Langage déclaratif
• Règle appliquée à chaque élément de type
EClassNameIn, vérifiant condition
– Mise en œuvre des règles
• Une règle pour chaque élément à considérer
• Remplir tous les attributs de outVar à initialiser
– Ordre de déclaration des règles
• Libre
– Statements : partie impérative

76
• ForExample est le nom de la règle de transformation.
• i (resp. o) est le nom de la variable qui dans le corps de la règle va représenter l’élément
source identifié (resp. l’élément cible créé).
• InputMetaModel (resp. OutputMetaModel) est le métamodèle auquel le modèle source
(resp. le modèle cible) de la transformation est conforme.
• InputElement désigne la métaclasse des éléments du modèle source auxquels cette règle va
s’appliquer.
• OutputElement désigne la métaclasse à partir de laquelle la règle va instancier les éléments
cibles.
• Le point d’exclamation permet de spécifier à quel métamodèle appartient une métaclasse en
cas d’homonymie.
• attributeA et attributeB sont des attributs de la métaclasse OutputElement
• Leur valeur est initialisée à l’aide des valeurs des attributs i.attributeB,
i.attributeC et i.attributeD de la métaclasse InputElement. 77
• Exp1:

78
• Exp2:

79
• Partie impérative:
– Statements
• Opérations effectuées après chaque application de la règle
– Affectation target <- source;
– Conditionnelle if( condition) { statements} [else { statements}]
– Répétition for( iterator in collection) { statements }
– Exp:

80
• Règle de génération (0 -> 1)
– Génération par création d’élément
– Appel via la partie impérative d’une règle (1-1) ou
via une autre règle (0-1)
• thisModule.ruleName()
– Exp:

81
 Modes d’exécution des modules
• Le moteur d’exécution ATL définit 2 modes
d’exécution pour les différents modules:
– Le mode normal
• Spécifie la manière dont les éléments du modèle cibles
doivent être générés à partir des éléments du modèle
source
• Spécifié par le mot clé from dans le header
• Utilisé dans le cas de transformations exogènes
– Le mode raffinage
• Spécifié par le mot clé refining dans le header
• Transformations endogènes

82