1
INGENIERIE DES MODELES
CHAP 1 :
DES MODELES A l’IDM (MDE)
Introduction
I. Les modèles
Un modèle est une abstraction (une simplification de la réalité) de la réalité permettant de
mieux comprendre le système (ce n'est pas la réalité).
Les modèles ont été et sont d’une importance centrale dans de nombreux contextes
scientifiques.
En chimie : les modèles des molécules ;
En électricité : les modèles des circuits ;
Génie civil : modèle de bâtiments ;
Circulation routière : les panneaux
a- Natures de modèles
Un modèle peut être :
-Description d’un système existant. Exemple : L’image d’une maison
-Spécification partielle d’un système à construire. Exemple : le plan d’une maison
MANDA ABEGA DEA- GIA
2
INGENIERIE DES MODELES
-Ensemble réduit d’informations obtenues à partir d’un système nécessaire à un
traitement donné. Exemple : Une personne est un système et le codage {nom, identifiant,
dateNaissance, sexe} est un modèle pour cette personne.
Nom
Identifiant
dateNaissance
Sexe
-Vue subjective ou simplifiée d’un système. Exemple : le pictogramme est un modèle de la
personne.
b- Types de modèles
-Le modèle de contexte (modèle contextuel). C’est un modèle qui décrit un contexte, un
cas de figure. Il peut être rédigé dans un langage naturel informel. Exemple : Le modèle
pour décrire les besoins dans un système informatique.
-Les modèles d’interactions (modèles interactionnels) : Ils décrivent des activités, des
transitions, bref ce qui est dynamique. Exemples : diagramme de séquence, diagramme
d’activité, diagramme de cas d’utilisation.
-Les modèles de structures (modèles structurels). Ils décrivent une structure. Exemple :
Diagramme de classe, diagramme d’objets, diagramme de paquetages.
-Les modèles de comportements (modèles comportementaux). Pour prédire les
(changements de) comportements des individus, entre autres dans le domaine de la santé.
c- Pourquoi utiliser des modèles
-Faciliter et comprendre un système donné. Le système étant compliqué on a besoin d’un
modèle pour voir plus clair, pour bien expliquer le système ou une partie de ce système.
C'est-à-dire pour décrire la réalité d'un système ou d'un contexte (ex. les dessins à chaque
niveau d’un bâtiment ou d’un stade);
-Simuler un traitement réalisé par un système : Simuler ou reproduire une fonctionnalité
d’un système.
-Réaliser un système : C'est-à-dire pour déterminer et définir la manière dont un système
doit être mis en œuvre.
MANDA ABEGA DEA- GIA
3
INGENIERIE DES MODELES
II. Utilisation des modèles dans le génie logiciel
La nécessité de s'appuyer sur des modèles pour le développement de logiciels repose sur
quatre faits principaux.
1. Les artefacts logiciels deviennent de plus en plus complexes et ils doivent être
discutés à différents niveaux d’abstraction en fonction du profil des parties prenantes
impliquées, de la phase du processus de développement et objectifs du travail. On va
par conséquent modéliser tous ces éléments afin d’avoir une meilleure vue de notre
projet.
2. Le développement de logiciels n'est pas une activité autonome : il impose souvent
interactions avec des non-développeurs (par exemple, clients, gestionnaires,
commerciaux) parties prenantes, etc.) qui nécessitent une médiation dans la
description des aspects techniques du développement
3. Les logiciels sont de plus en plus omniprésents dans la vie des gens, et le besoin de
nouveaux logiciels ou l'évolution de ceux existants est en constante augmentation. La
modélisation permettra ainsi de développer plus rapidement afin de satisfaire à la
demande.
4. La modélisation vient automatiser le processus de développement logiciel
On constate que l'utilisation faite des modèles est diversifiée : Compréhension,
communication, rapidité de travail, automatisation.
Bien entendu, au cours d'un processus de développement, une équipe peut utiliser
modèles de plusieurs manières différentes. Par exemple, en discutant des décisions de
conception les modèles pourraient être utilisés comme croquis pour faciliter la discussion ;
et après, des modèles complets pourraient être définis dans le cadre du plan directeur du
système. Enfin, ces modèles de plans peuvent être affinés davantage pour créer le système à
l'aide de code techniques de génération pour minimiser les tâches de codage.
Au sein des processus de production, la modélisation nous permet d'étudier, de vérifier, de
documenter et de discuter des propriétés des produits avant leur fabrication. Dans de
nombreux cas, les modèles sont même utilisés pour automatiser directement la production
de biens. Il n’est donc pas surprenant que nous les utilisions dans le génie informatique.
III. Présentation de l’IDM (MDE)
L’IDM peut être défini comme une méthodologie permettant d’appliquer les avantages de la
modélisation aux activités du génie logiciel. En raison des différents besoins possibles
auxquels l’IDM répond son rôle devient celui de définir des approches d'ingénierie solides
basées sur les modèles, les transformations et de leurs combinaisons au sein d’un processus
de développement logiciel.
Comme toute méthodologie, l’IDM comprend les aspects suivants.
Concepts : les composants qui construisent la méthodologie
Notations : la manière dont les concepts sont représentés, c'est-à-dire les langages
utilisé dans la méthodologie
MANDA ABEGA DEA- GIA
4
INGENIERIE DES MODELES
Processus et règles : les activités qui mènent à la production du produit final.
Dans notre cas par on a les transformations des modèles.
Outils : applications qui facilitent l'exécution des activités ou leur coordination
en couvrant le processus de production et en accompagnant le développeur dans
l'utilisation les notations. C’est par exemple les framework (EMF, interface architect,
…), les bibliothèques (Atlas…)
3.1 Les concepts
-IDM (MDE : Model driven engineering). C’est une méthode d’ingénierie des systèmes
utilisant des modèles pour représenter à la fois un problème posé et sa solution. La
philosophie de l’IDM considère que "tout est modèle", c’est à dire que n’importe quel
élément de la réalité peut être représenté par un modèle.
Elle va au-delà des pures activités de développement et englobe d'autres tâches basées sur
des modèles d'un programme complet d'ingénierie logicielle processus (par exemple,
l'évolution du système basée sur un modèle ou la rétro-ingénierie d’un système existant).
-DDM (MDD: Model driven development). Le développement dirigé (piloté) par modèle est
un paradigme de développement qui utilise modèles comme artefact principal du processus
de développement. C’est l'application de l'ingénierie dirigée par les modèles au
développement logiciel. En fait elle s’arrête juste sur le développement.
-ADM (MDA : Model-Driven Architecture). L’architecture dirigée par les modèles est la
vision particulière du DDM proposée par l’Object Management Group (OMG) et s’appuie
ainsi sur l’utilisation des normes de l’OMG. Par conséquent, MDA peut être considéré
comme une application de MDD, où les langages de modélisation et les transformations sont
standardisés par OMG.
- IBM (MBE : model-base engineering). L’ingénierie basée sur les modèles » fait référence
à une version plus douce de IDM. Autrement dit, le processus MBE est un processus dans
lequel les modèles logiciels jouent un rôle important bien qu’ils ne soient pas
nécessairement les artefacts clés du développement (c'est-à-dire qu'ils ne « pilotent » PAS le
processus comme dans l’IDM).
3.2 Modélisation et non le dessin
Un point crucial qu’il faut comprendre est que l’IDM aborde la conception de logiciels avec
une approche de modélisation, par opposition à une approche de dessin. Dessiner consiste
simplement à créer de jolis images, éventuellement conformes à certaines règles
syntaxiques, pour décrire certains aspects de la conception. D’un autre côté, la modélisation
est une tâche beaucoup plus complexe. La modélisation, par opposition au simple dessin,
offre un vaste ensemble d’avantages supplémentaires, notamment : validation syntaxique,
vérification de modèle, simulation des modèles, transformations de modèles, exécution de
modèles (soit via la génération de code ou l’interprétation des modèle) et débogage du
modèle
MANDA ABEGA DEA- GIA
5
INGENIERIE DES MODELES
3.3 Méta modélisation
Étant donné que les modèles jouent un rôle omniprésent dans l’IDM, une étape naturelle est
de représenter les modèles eux-mêmes comme des « instances » de quelques modèles
plus abstraits. Par conséquent, exactement de la même manière que nous définissons un
modèle en tant qu'abstraction des phénomènes du monde réel, nous pouvons définir un
méta modèle comme encore une autre abstraction, mettant en évidence les propriétés du
modèle lui-même. D'une manière pratique Dans ce sens, les méta modèles constituent
essentiellement la définition d'un langage de modélisation, puisqu'ils fournissent un moyen
de décrire tous les modèles qui peuvent être représentés par ce langage.
On peut donc définir des modèles de la réalité, puis des modèles qui décrire des modèles
(appelés méta modèles) et de manière récursive des modèles qui décrivent méta modèles
(appelés méta-méta modèles). Alors qu'en théorie on pourrait définir l'infini niveaux de
méta modélisation, il a été montré, en pratique, que les méta-méta modèles peuvent être
définis en fonction d'eux-mêmes, et cela n'a donc généralement pas de sens dépasser ce
niveau d'abstraction.
On dit qu'un modèle est conforme à son métamodèle lorsque tous ses éléments peuvent
être exprimés comme des instances des classes du méta modèle (méta classes)
correspondantes.
La figure ci-dessous montre les 4 niveaux de modélisation selon OMG. On remarque que
le M3 est occupé par le MOF (Meta Object Facilities). Utilisé pour définir la syntaxe abstraite
des méta-modèles UML. Il définit aussi les éléments des méta-modèles et leurs relations.
Les niveaux de modélisation
MANDA ABEGA DEA- GIA
6
INGENIERIE DES MODELES
Détails du M2
3.5 Les relation dans l’IDM
- Le système : C’est le système réel qu’on veut simuler ou la solution qu’on cherche à réaliser
à la fin.
- Le modèle : Il représente le système. Donc un système est représenté par un modèle. Au
lieu de considérer le système tout entier, on considère juste le modèle.
- Le méta-modèle : Il est le descripteur de modèle. Le modèle est conforme à son méta-
modèle.
- Le méta-méta-modèle : Il est le descripteur de méta-modèle. Le méta-modèle est conforme
à son méta-méta-modèle. Le méta-méta-modèle est conforme à lui-même. Il est auto
définissable ; il est défini par lui-même.
On a donc deux types de relations :
La conformité : Le modèle est conforme à son méta-modèle qui est conforme à son méta-
méta-modèle qui est conforme à lui-même. A l’inverse on parle de définition (ou de
description). Le méta-méta-modèle se décrit lui-même et décrit le méta-modèle. Le méta-
modèle décrit le modèle.
La représentativité : Le modèle représente le système.
MANDA ABEGA DEA- GIA
7
INGENIERIE DES MODELES
3.6 Domaine, plateformes et espaces techniques
Le champ ou domaine d'expertise qui doit être examiné pour comprendre et définir un
problème est appelé espace du problème (également appelé domaine du problème).
L’espace problème est abordé par la phase d’analyse dans le processus développement. Le
modèle de domaine décrit les différentes entités, leurs attributs, rôles et relations, ainsi que
les contraintes et les interactions. Le but des modèles de domaine est de définir une
compréhension commune d’un domaine d’intérêt, à travers ses vocabulaire et concepts clés.
Au contraire, l’espace des solutions est l’ensemble des choix effectués lors de la
conception, implémentation et exécution, pour obtenir une application logicielle qui résout
le problème énoncé dans le domaine du problème.
Les espaces techniques représentent des contextes de travail pour la conception, la mise
en œuvre et l'exécution de ces applications logicielles. Ceux-ci impliquent des technologies
de mise en œuvre spécifiques et les langages. La notion d'espace technique est cruciale pour
l’IDM, car elle permet de décider de l'ensemble des outils techniques et des formats de
stockage des modèles, transformations et mises en œuvre. A noter qu'un local technique
peut soit couvrir à la fois les domaines du problème et de la solution ou ne couvre qu’un seul
de ces aspects.
3.7 outils de dessin vs outils de modélisation
Beaucoup de gens supposent que les outils de dessin et les outils de modélisation sont
deux concepts interchangeables mais c’est loin d’être vrai. En fait, seuls certains outils sont
outils de dessin et de modélisation en même temps.
Certains outils de modélisation utilisent une syntaxe textuelle concrète pour spécifier
les modèles (Tous les modèles ne doivent pas nécessairement être des modèles graphiques),
et par conséquent, il n'y a pas de support pour les dessiner, même si les outils peuvent être
capables de restituer la définition textuelle dans une sorte de format d'exportation
graphique à des fins de visualisation.
De plus, de nombreux outils de dessin ne sont pas des outils de modélisation appropriés.
Un outil de dessin ne peut être considéré comme un outil de modélisation que si l'outil
«comprend» les dessins, c'est-à-dire que l'outil ne s'occupe pas uniquement des formes, des
lignes, et des flèches, mais comprend qu'elles représentent, par exemple, des classes, des
associations ou d'autres concepts de modélisation. Cela devrait au moins suffire à valider un
modèle, c'est-à-dire vérifiez que le modèle est une instance correcte de son métamodèle.
Par exemple, un outil de dessin peut permettre au concepteur de dessiner quelque chose.
Les icônes et les formes peuvent être celles défini dans un langage donné (dans l'exemple, la
notation UML) mais le modèle n'a peut-être aucune signification, car la façon dont les
éléments sont utilisés brise les règles.
L’IDM recommande de toujours utiliser un outil de modélisation pour définir modèles
pour au moins trois raisons principales.
MANDA ABEGA DEA- GIA
8
INGENIERIE DES MODELES
Un outil de modélisation est capable d'exporter ou de manipuler les modèles à
l'aide de l’API fournies par les outils.
Un outil de modélisation garantit un niveau minimum de sens sémantique et
qualité du modèle, car il accorde l’alignement sur une sorte de métamodèle. Le
résultat étant un modèle (et pas seulement un dessin), il a beaucoup plus de valeur,
même si le modèle a été défini uniquement pour des fins de communication. En
fait, il est très possible que ce modèle soit utilisé pour le prototypage ou la
génération de code, dans le cadre d'une chaîne IDM.
Un outil de modélisation fournit généralement des fonctionnalités appropriées
pour la transformation des modèles.
MANDA ABEGA DEA- GIA
9
INGENIERIE DES MODELES
CHAP 2 :
APPORT DE l’ADM
(MDA)
Introduction
Il est essentiel d’acquérir de bonnes pratiques de modélisation afin de déterminer comment,
quand, quoi et pourquoi modéliser et d’exploiter pleinement les avantages des modèles.
L’OMG a défini MDA (Model Driven Architecture) en 2000 dans cet objectif. L’approche MDA
préconise l’utilisation massive des modèles et offre de premières réponses aux comment,
quand, quoi et pourquoi modéliser. En répertoriant toutes les bonnes pratiques, elle vise à
mettre en valeur les qualités intrinsèques des modèles, telles que pérennité, productivité et
prise en compte des plates-formes d’exécution. L’ADM inclut la définition de plusieurs
standards, notamment UML, MOF et XMI. Nous considérons l’ADM comme un bon cadre
IDM exemplaire pour deux raisons principales : premièrement, ADM est un cas parfait pour
expliquer les concepts de l’IDM introduits jusqu'à présent, étant donné que toutes les
phases standard d’un processus de développement logiciel tel que l'analyse, la conception et
la mise en œuvre sont soutenues de manière appropriée ; deuxièmement, compte tenu de
l’importance de l’OMG dans le industrie du logiciel, MDA est actuellement le cadre de
modélisation le plus connu dans l’industrie.
I- Les principes
Le principe clé de MDA consiste en l’utilisation de modèles aux différentes phases du cycle
de développement d’une application. Plus précisément, MDA préconise l’élaboration de
modèles d’exigences (CIM), d’analyse et de conception (PIM) et de code (PSM). L’objectif
majeur de MDA est l’élaboration de modèles pérennes, indépendants des détails
techniques des plates-formes d’exécution (J2EE, .Net, PHP ou autres), afin de permettre la
génération automatique de la totalité du code des applications et d’obtenir un gain
significatif de productivité.
I.1 Le modèle d’exigences CIM (Computation Independent Model)
La première chose à faire lors de la construction d’une nouvelle application est bien
entendu de spécifier les exigences du client. Bien que très en amont, cette étape doit
fortement bénéficier des modèles.
L’objectif est de créer un modèle d’exigences de la future application. Un tel modèle doit
représenter l’application dans son environnement afin de définir quels sont les services
offerts par l’application et quelles sont les autres entités avec lesquelles elle interagit.
La création d’un modèle d’exigences est d’une importance capitale. Cela permet
d’exprimer clairement les liens de traçabilité avec les modèles qui seront construits dans
les autres phases du cycle de développement de l’application, comme les modèles
d’analyse et de conception. Un lien durable est ainsi créé avec les besoins du client de
l’application.
MANDA ABEGA DEA- GIA
10
INGENIERIE DES MODELES
Les modèles d’exigences peuvent même être considérés comme des éléments
contractuels, destinés à servir de référence lorsqu’on voudra s’assurer qu’une application
est conforme aux demandes du client.
Il est important de noter qu’un modèle d’exigences ne contient pas d’information sur la
réalisation de l’application ni sur les traitements. C’est pourquoi, dans le vocabulaire MDA,
les modèles d’exigences sont appelés des CIM (Computation Independent Model),
littéralement « modèle indépendant de la programmation ».
Avec UML, un modèle d’exigences peut se résumer à un diagramme de cas d’utilisation.
Ces derniers contiennent en effet les fonctionnalités fournies par l’application (cas
d’utilisation) ainsi que les différentes entités qui interagissent avec elle (acteurs) sans
apporter d’information sur le fonctionnement de l’application.
I.2 Le modèle d’analyse et de conception abstraite PIM (Platform Independent Model)
Une fois le modèle d’exigences réalisé, le travail d’analyse et de conception peut
commencer. Dans l’approche MDA, cette phase utilise elle aussi un modèle.
L’analyse et la conception sont depuis plus de trente ans les étapes où la modélisation est
la plus présente, d’abord avec les méthodes Merise puis avec les méthodes objets, OMT,
OOSE et Booch. Ces méthodes proposent toutes leurs propres modèles. Aujourd’hui, le
langage UML s’est imposé comme la référence pour réaliser tous les modèles d’analyse et
de conception.
Par conception, il convient d’entendre l’étape qui consiste à structurer l’application en
modules et sous-modules. L’application des patrons de conception, ou Design Patterns,
l’architecture font partie de cette étape de conception. Par contre, l’application de
exigences techniques, propres à certaines plates-formes, correspond à une autre étape.
Nous ne considérons donc ici que la conception abstraite, c’est-à-dire celle qui est
réalisable sans connaissance aucune des techniques d’implémentation.
I.3 Le modèle de code ou de conception concrète PSM (Platform Specific Model)
Une fois les modèles d’analyse et de conception réalisés, le travail de génération de code
peut commencer. Cette phase, la plus délicate du MDA, doit elle aussi utiliser des modèles.
Elle inclut l’application des patrons de conception techniques.
MDA considère que le code d’une application peut être facilement obtenu à partir de
modèles de code. La différence principale entre un modèle de code et un modèle d’analyse
ou de conception réside dans le fait que le modèle de code est lié à une plate-forme
d’exécution. Dans le vocabulaire MDA, ces modèles de code sont appelés des PSM (Platform
Specific Model).
Les modèles de code servent essentiellement à faciliter la génération de code à partir d’un
modèle d’analyse et de conception. Ils contiennent toutes les informations nécessaires à
l’exploitation d’une plate-forme d’exécution, comme les informations permettant de
manipuler les systèmes de fichiers ou les systèmes d’authentification. L’autre caractéristique
importante des modèles de code est qu’ils font le lien avec les plates-formes d’exécution.
MANDA ABEGA DEA- GIA
11
INGENIERIE DES MODELES
Cette notion de plate-forme d’exécution est très importante dans MDA car c’est elle qui
délimite la fameuse séparation des préoccupations.
Pour élaborer des modèles de code, MDA propose, entre autres, l’utilisation de profils
UML. Un profil UML est une adaptation du langage UML à un domaine particulier. Par
exemple, le profil UML pour EJB est une adaptation d’UML au domaine des EJB. Grâce à ce
profil, il est possible d’élaborer des modèles de code pour le développement d’EJB.
Exemple :
MANDA ABEGA DEA- GIA
