L'approche Model-Driven Architecture, cr edible pour d evelopper un progiciel de gestion int egr e - ECOLE DOCTORALE SYST'EMES
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
ÉCOLE DOCTORALE SYSTÈMES
L’approche Model-Driven
Architecture, crédible pour
développer un progiciel de
gestion intégré
Mémoire de DEA – Systèmes Industriels
Tuteur : Paul Gaborit
Xavier Moghrabi
— Année universitaire : 2002-2003 —
Remerciements
Je tiens à exprimer mes plus vifs remerciements à mon tuteur Franck Darras, docto-
rant à l’École des Mines d’Albi–Carmaux, pour m’avoir aidé à réaliser mon DEA. Il m’a
permis de trouver un sujet intéressant et m’a fourni une partie des documents pour la
bibliographie.
Je remercie Paul Gaborit et Hervé Pingaud, enseignant-chercheurs au centre génie
industriel de l’École des Mines d’Albi–Carmaux, pour leurs conseils, le suivi de mon travail
et les remarques formulées sur ce document.
Je tenais à remercier Thomas Van Oudenhove de Saint Géry, camarade de classe
à l’École des Mines en option Génie des Systèmes d’Information et futur doctorant dans
cette école. Il m’a fournit son modèle de document et son aide pour rédiger ce mémoire de
DEA sous LATEX.
Pour finir, je souhaite remercier la structure d’accueil de mon stage qui m’a donné
l’opportunité et libéré du temps pour la réalisation de ce travail. Pour des raisons de confi-
dentialité, j’ai préféré ne pas citer son nom mais les intéressés se reconnaı̂tront.
Xavier Moghrabi — Année universitaire : 2002-2003 — i
Résumé
Les systèmes d’information sont de plus en plus complexes. Avec la multitude des tech-
nologies, les décideurs ne savent plus laquelle adoptée. Le Model-Driven Architecture est
issu d’un constat que chaque nouvelle évolution technologique entraı̂ne un coût significatif.
Proposée par l’OMG, cette approche permet de pérenniser les systèmes d’information en
séparant les modèles métiers de ceux d’implémentation. Des mécanismes de transforma-
tions sont prévus pour automatiser le passage et la construction. Cette approche, de plus
haut niveau d’abstraction, réduira les coûts de développement, facilitera les migrations
technologiques, améliorera l’interopérabilité entre les systèmes. . .
Le MDA est conçu pour des systèmes à base de composants fonctionnant sur un midd-
leware. L’étude envisage la possibilité de l’appliquer pour réaliser un progiciel de gestion
d’entreprise. Les problèmes de réalisation et d’exploitation sont les mêmes que ceux énumé-
rés précédemment. Le MDA est adapté car il dispose de méta-modèles verticaux adaptés
à chaque domaine. De plus, des méthodes de développement permettent d’intégrer cette
démarche. Des applications expérimentales ont déjà été développées en utilisant le MDA
et des outils “compatibles MDA“ apparaissent.
Pour prouver l’efficacité du MDA en terme de productivité lors du développement,
une société a réalisé une étude. Elle consistait à mettre en concurrence deux équipes de
développement. Il s’est avéré que l’équipe utilisant MDA a mis 34 % de temps en moins.
Cette norme pourra devenir un nouveau standard. Elle propose de nombreux atouts mais
comporte encore des lacunes. Toutefois, le MDA n’est pas encore finalisé. Les transforma-
tions de modèles et les générations de code ne sont pas encore entièrement automatisées.
Xavier Moghrabi — Année universitaire : 2002-2003 — ii
Table des matières
Remerciements i
Résumé ii
Table des matières iv
Introduction 1
1 Une nouvelle approche dans la conception logicielle 2
1.1 Sujet de l’étude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 La problèmatique des ERP . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 Un ERP à base de composants . . . . . . . . . . . . . . . . . . . . . 3
1.2 Présentation du MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Séparation entre la logique métier et la technologie . . . . . . . . . . 6
1.2.2 L’abandon de la concurrence des middleware . . . . . . . . . . . . . 6
1.2.3 Une montée en abstraction . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.4 Détail de l’architecture du MDA . . . . . . . . . . . . . . . . . . . . 8
1.3 L’importance des modèles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.1 Les différents modèles du MDA . . . . . . . . . . . . . . . . . . . . . 10
1.3.2 La transformation des modèles . . . . . . . . . . . . . . . . . . . . . 11
1.3.3 Les profils UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4 Qu’attendre de l’approche MDA ? . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4.1 Les forces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4.2 les faiblesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.5 Les standards de l’OMG utilisés . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.5.1 MOF : Meta Object Facility . . . . . . . . . . . . . . . . . . . . . . . 16
1.5.2 UML : Unified Modeling Language . . . . . . . . . . . . . . . . . . . 16
1.5.3 CWM : Common Warehouse Metamodel . . . . . . . . . . . . . . . . 17
1.5.4 XMI : XML Metadata Interchange . . . . . . . . . . . . . . . . . . . 17
2 L’utilisation du MDA 18
2.1 L’approche MDA est-elle adaptée à la réalisation d’un ERP . . . . . . . . . 18
2.1.1 Le MDA peut s’appliquer à l’ensemble de l’industrie logicielle . . . . 18
2.1.2 Le MDA demande des moyens adaptés . . . . . . . . . . . . . . . . . 20
2.1.3 Le MDA répond aux besoins de création et d’intégration des ERP . 22
2.2 La méthode de développement . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.1 La MDA face aux méthodes agiles . . . . . . . . . . . . . . . . . . . 23
2.2.2 La révision du cycle en Y . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.3 Une nouvelle implémentation du processus unifié : EUP . . . . . . . 26
Xavier Moghrabi — Année universitaire : 2002-2003 — iii
2.3 Détail d’un système d’information utilisant la philosophie du MDA . . . . . 27
2.3.1 Le système d’information de la banque Wells Fargo . . . . . . . . . . 27
2.3.2 L’environnement des traitements . . . . . . . . . . . . . . . . . . . . 28
2.3.3 Le développement à base de modèles . . . . . . . . . . . . . . . . . . 29
2.3.4 Le MDA fournit une passerelle pour le futur . . . . . . . . . . . . . . 31
3 Les perspectives de cette approche logicielle 32
3.1 Étude de productivité de la démarche MDA . . . . . . . . . . . . . . . . . . 32
3.1.1 Les différences entre les approches MDA et traditionnelle . . . . . . 32
3.1.2 Description de l’objectif de l’étude . . . . . . . . . . . . . . . . . . . 33
3.1.3 L’analyse architecturale du système . . . . . . . . . . . . . . . . . . 34
3.1.4 Les résultats quantitatifs . . . . . . . . . . . . . . . . . . . . . . . . 36
3.1.5 Conclusion de l’étude de productivité . . . . . . . . . . . . . . . . . 36
3.2 Vers un nouveau standard de développement logiciel . . . . . . . . . . . . . 37
3.2.1 L’approche MDA, évolution ou révolution ? . . . . . . . . . . . . . . 37
3.2.2 Une approche de modélisation d’un ERP où le MDA a sa place . . . 38
3.2.3 Le MDA présente des atouts pour s’imposer comme un nouveau
standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Conclusion 43
Glossaire 44
Table des figures 46
Bibliographie 47
A Une architecture stratifiée 50
B Évolution hebdomadaire de l’étude 52
C Glossaire des design pattern utilisés 56
Xavier Moghrabi — Année universitaire : 2002-2003 — iv
Introduction
Depuis maintenant quelques années, de nouvelles architectures logicielles à base de
composants émergent régulièrement. Ce qui à l’origine devait permettre une réutilisabilité
extrêmement importante se voit aujourd’hui soumis aux modes et à des évolutions très im-
portantes. Les entreprises ne veulent plus investir des sommes colossales pour suivre cette
incessante remise en cause de leur système d’information existant. Elles veulent pérenniser
leurs architectures.
L’omg a mis à contribution son expérience dans les middleware avec Corba et dans
la modélisation avec notamment uml pour élaborer une norme de méta-modélisation des
architectures à base de composants : le Model-Driven Architecture - mda.
Il définit une nouvelle approche orientée modèle dans laquelle les composants révèlent
une sémantique indépendante de toute plateforme, permettant ainsi de mieux se concen-
trer sur la logique métier. Le mda définit des abstractions de services et de comportements
communs aux middleware. Sachant que le mda se base sur des standards (uml, xmi,. . .)
ou des travaux déjà très largement adoptés comme références (Profils uml, mof,. . .), la
mise au point d’un méta-modèle spécifié suivant cette norme permettra d’automatiser la
transformation vers des modèles spécifiques à des plate-formes particulières et la généra-
tion de code.
La présente étude tente d’appréhender cette nouvelle démarche dans la conception
logicielle pour déterminer si elle est applicable pour réaliser d’un progiciel de gestion inté-
gré, également appelé erp. Pour cela, nous présenterons les principes du mda, examineront
s’il est adapté au développement d’un erp et finirons par évoquer les perspectives du mda.
NB : Les termes en petite majuscule (erp) sont définis dans le glossaire.
Xavier Moghrabi — Année universitaire : 2002-2003 — 1
Chapitre 1
Une nouvelle approche dans la
conception logicielle
Cette première partie sert à présenter le sujet de l’étude et l’approche mda. L’étude
fera un état de l’art sur cette approche pour présenter le mda.
1.1 Sujet de l’étude
La présente étude s’intéresse au développement d’un erp par une approche mda. Le
développement de ce type de produit est un projet à long terme et conséquent pour une
entreprise d’une centaine d’employés.
1.1.1 La problèmatique des ERP
Le cycle de réalisation d’un erp est un travail, de plusieurs dizaines d’années.hommes,
complexe car doit couvrir l’ensemble des besoins de gestion des PME/PMI. Les technologies
orientées objet seront sollicitées pour réaliser un produit bien conçu, évolutif, adaptable et
maintenable. La recherche de ces caractéristiques est motivée par la longue durée de vie
du progiciel et le souhait de répondre aux besoins de gestion spécifiques des clients. En
effet, un erp a une durée d’exploitation moyenne par le client de 8 ans. L’éditeur souhaite,
quant à lui, pouvoir vendre son produit aussi longtemps possible ce qui nécessite un be-
soin d’évolutivité de la part du produit. De plus, l’éditeur désire créer une seule version du
progiciel qui pourra être spécialisée pour chaque client par la réalisation de programmes
spécifiques et le paramétrage.
Pour garantir cette évolutivité, le logiciel doit être indépendant des technologies. À
l’heure actuelle, pour réaliser un important projet logiciel avec des technologies orientées
objet, trois plateformes technologiques de type middleware sont majoritairement uti-
lisées : j2ee, .net et Corba. Ces technologies permettent de réaliser des applications
complexes, flexibles et distribuées. Lors de la création d’un produit, l’équipe de dévelop-
pement doit choisir la technologie de l’infrastructure. Ce choix est crucial pour la bonne
finition du projet. Il se résume souvent à adopter une technologie dont la pérennité est
fortement probable. En effet, la migration d’une application vers une nouvelle technologie
est très coûteuse.
L’approche mda a pour but de pallier à ce problème en proposant des modèles indé-
pendants de la plate-forme technique qui permettront de générer rapidement et facilement
Xavier Moghrabi — Année universitaire : 2002-2003 — 2
L’approche Model-Driven Architecture, crédible pour développer un progiciel de gestion intégré
des modèles spécifiques. Ensuite à partir de ces derniers, le code de l’application serait
créé. La possibilité d’automatiser les opérations de transformation et génération se traduit
par l’apparition d’outils.
1.1.2 Un ERP à base de composants
Comme le concept de “componentisation” [1] est commun à diverses disciplines d’in-
génierie et aux industrie, Kumar et al. [2] ont proposé de concevoir un erp à base de
composants pour répondre aux problématiques de variété et de complexité des fonctionna-
lités. Ce concept peut être utilisé pour concevoir les différents domaines fonctionnels d’un
erp comme des composants logiciels [3].
Définition de composant
Selon la norme uml, un composant est une partie physique remplaçable d’un système
qui fournit la réalisation d’un ensemble d’interfaces et s’y conforme. Dans un développe-
ment orienté composant, une application monolithique est découpée en un ensemble de
composants, ce qui favorise sa réutilisation. Il suffit de modifier ou d’ajouter un compo-
sant pour introduire une nouvelle fonction dans une application. L’objectif est donc de
réduire le coût du cycle de vie du logiciel. Les composants communiquent au moment de
leur exécution pour concourir à l’application utilisée, sur une même machine ou à travers
un système distribué. Un composant logiciel se représente comme une brique réutilisable
disponible sous forme binaire. Un système à base de composants est un assemblage de
composants qui collaborent dans une architecture commune pour un objectif unique.
Un composant est :
– un ou plusieurs objets (avec ses propriétés, méthodes et évènements) composés d’in-
terfaces,
– un ou plusieurs objets compilés et binaires,
– un ou plusieurs objets qui adhèrent à un modèle,
– utilisable indépendamment du langage, de sa localisation et de l’application l’utili-
sant,
– géré par le système.
La caractéristique principale de l’approche orientée composant est la collaboration
des composants nommée par le concept d’interopérabilité. L’architecture est alors un réel
assemblage avec des outils de haut niveau sans le souci du détail de l’implémentation.
L’orb est le bus logiciel qui permet aux composants de collaborer sur l’ensemble d’un
réseau. En fait, les composants ne collaborent pas directement en invoquant des méthodes
à distance, ils le font par l’intermédiaire de l’orb. Le modèle de composant apporte un
ensemble d’objets et de méthodes (les transactions, la sécurité, la concurrence d’accès,
l’indépendance à la localisation) sans ajout de code. Ainsi le développeur se concentre sur
la partie métier car les services techniques sont pris en charge par l’infrastructure.
Intérêt d’un progiciel à base de composants
Le concept d’erp à base de composants doit permettre de répondre et d’améliorer les
quatre critères définis par Sprott [1] soient :
– l’intégration,
– l’adaptabilité,
Xavier Moghrabi — Année universitaire : 2002-2003 — 3
L’approche Model-Driven Architecture, crédible pour développer un progiciel de gestion intégré
– la facilité de mise à jour,
– la facilité de mise en œuvre.
Un système à composants complètent les intérêts des techniques orientées objet clas-
siques. Il les généralise en proposant :
– une encapsulation parfaite des objets, permettant d’accroı̂tre la maintenabilité et
l’indépendance des différents composants ;
– une réutilisation complète des composants, qui permet un accès sans en avoir le code
source et sans avoir à les intégrer dans le processus de compilation et d’édition de
liens.
Mais les possibilité vont encore plus loin sur l’indépendance des composants. Elle est
telle que qu’il est réalisable de :
– mettre à jour un composant dynamiquement, sans remettre en cause l’ensemble du
progiciel. En effet, les composants sont dans des processus séparés. Il est possible de
mettre à jour l’un d’entre eux sans avoir à compiler, diffuser et réinitialiser l’ensemble
du progiciel.
– accroı̂tre les fonctionnalités d’un progiciel dynamiquement, en y ajoutant des com-
posants polymorphiques avec des composants déjà utilisés. Comme le système ne
manipule les objets répartis que par l’intermédiaire de leurs interfaces, tout objet
respectant ces interfaces peut être utilisé indifféremment. L’adjonction de nouveaux
composants respectant ces interfaces peut donc élargir le champ d’action du système.
Elle lui permet de manipuler des objets dont l’existence n’était a priori même pas
connue lors de la création du progiciel.
– répartir les composants sur différentes machines, et les faire communiquer de manière
transparente via le réseau. Les objets répartis se placent donc au plus haut niveau
de la programmation réseau, et permettent une abstraction complète de la notion
d’appel de méthode d’un objet. Par ailleurs, la répartition des objets fournit une
solution élégante au problème d’équilibrage des charges dans un système complexe.
Certains orb vont jusqu’à autoriser le rééquilibrage des charges dynamiquement, en
phase d’exploitation.
– bénéficier de tous les avantages des architectures client/serveur. Cependant, les pro-
giciels à composants vont plus loin, car ils permettent une finesse incroyable dans
ce type d’architecture. En effet, chaque objet est considéré comme un serveur par
les programmes qui l’utilisent. Inversement, un objet peut très bien être client d’un
autre objet. Il est donc tout à fait possible de centraliser les données dans des objets
dédiés à cette tâche, et d’assurer les services complexes comme la cohérence de ces
données et leur redondance pour les systèmes à défaillance de panne.
– construire un erp de façon modulaire. L’indépendance des composants permet de
concevoir un progiciel où chacun des composants correspondrait à un module.
– assembler des composants hétérogènes interopérables. Des technologies permettent
d’assembler des composants hétérogènes (de langage et système d’exploitation dif-
férents) permettent de construire un système d’information d’entreprise par assem-
Xavier Moghrabi — Année universitaire : 2002-2003 — 4
L’approche Model-Driven Architecture, crédible pour développer un progiciel de gestion intégré
blage de composants provenant de différents éditeurs. L’utilisateur pourrait choisir
les composants les mieux adaptés à son besoin et les faire fonctionner ensemble.
Tous ces avantages sont déjà très significatifs. Mais l’étendu des possibilités des sys-
tèmes à composants est encore plus vaste que ces simples possibilités techniques. En effet,
les services additionnels fournis par les orb permettent virtuellement de réaliser des sys-
tèmes très différents et d’étendre les orb.
Inconvénients d’un progiciel à base de composants
Si les avantages précédents sont issus de l’aboutissement des principes objets, les in-
convénients le sont hélas aussi. Ils sont classés en deux catégories :
– l’utilisation exclusive des interfaces pour manipuler les objets répartis implique la dé-
finition et l’implémentation complète de ces interfaces, donc une forte augmentation
des frais de conception et de développement des programmes ;
– l’augmentation du risque de faire une “usine à gaz” si la conception n’est pas faite
dans les “règles de l’art”.
Ces deux inconvénients relèvent de la conception, et montrent donc clairement qu’il ne
faut pas se lancer à l’aveugle dans les technologies à composants. D’autre part, d’autres
problèmes additionnels peuvent survenir. Leur importance relative est propre à chaque
orb, mais on peut généralement signaler que :
– la réalisation d’un composant est nettement plus compliquée que l’écriture d’une
classe. Ce constat se traduit par un besoin d’analystes et de développeurs expéri-
mentés.
– les programmes sont plus lents à l’exécution, en raison de l’intervention de l’orb
dans la communication inter-objets. La localisation des différents objets doit être
prise en compte dans la conception d’une application, afin de réduire le temps des
communications.
– la gestion des problèmes de communication peut être soit peu souple, si elle est
complètement masquée par l’orb, soit complexe, si l’orb ne la prend pas du tout
en charge. Il faut s’attendre au fait que les communications peuvent être coupées.
Ceci est vrai même lorsque les objets sont exécutés sur une même machine, car il
suffit qu’un processus se termine (volontairement ou non) pour que tous les objets
qui sont dedans deviennent inaccessibles. Pour certaines applications, l’abstraction
fournie par l’orb est suffisante, mais pour d’autres, il est impératif de maı̂triser les
pertes de connexion au plus bas niveau. Tous les orb ne sont pas égaux quant à la
capacité de personnalisation des traitements d’erreurs.
Sur ce dernier point, ce problème relève du choix technologique. Par ailleurs, les pro-
blèmes de communication entre objets soulignent plus une qualité qu’un défaut des objets
répartis. En effet, si un processus fait une faute, il n’est responsable que de la mort de ses
propres objets, pas de celle des objets des autres processus. Par conséquent, un système
à composants est globalement plus stable qu’une application monolithique, pour laquelle
l’ensemble des opérations se serait arrêté.
Xavier Moghrabi — Année universitaire : 2002-2003 — 5L’approche Model-Driven Architecture, crédible pour développer un progiciel de gestion intégré
1.2 Présentation du MDA
La naissance du mda a été motivée par la complexification des systèmes d’information
et des forts coûts de migration technologique. L’omg propose ainsi de monter le niveau
d’abstraction pour s’affranchir des contraintes technologiques.
1.2.1 Séparation entre la logique métier et la technologie
L’histoire des systèmes d’information a connu de nombreuses évolutions que ce soit au
niveau des langages de programmation (procéduraux et fonctionnels, évènementiels, orien-
tés objet, services web...), des middleware (propriétaires, Corba, DCOM/COM+,
RMI...) ou des méthodes de conception (SADT, Merise, les méthodes orientées objet...).
De plus, la diversité des solutions pour résoudre un même problème ne cesse d’augmenter
[4].
Dans ce contexte, les chefs d’entreprise ne veulent plus investir dans un middleware
dont la pérennité est courte. Avec Corba, l’omg pensait fournir une norme suffisamment
puissante et ouverte pour répondre à tous les besoins. Le consortium pensait que Corba
deviendrait ainsi le middleware standard universel à l’instar d’uml comme formalisme
de modélisation. Cependant des architectures différentes se succédèrent, obligeant les en-
treprises à former leurs ingénieurs et à remettre à jour leurs applications.
Lors d’une migration d’une infrastructure vers une nouvelle technologie, la logique mé-
tier de l’application reste globalement la même. Il est donc évident de tenter de différencier
l’architecture technique dépendant de la technologie utilisée de celle de la logique métier.
L’intérêt est de favoriser l’évolutivité, la réduction de coût et l’interopérabilité.
Pour aller dans ce sens, les grandes compagnies informatiques ont ressenti le besoin de
standardiser les différentes tentatives. Elles ont donc logiquement chargé le consortium de
l’omg de la mission de définir une norme indépendante d’un middleware particulier.
1.2.2 L’abandon de la concurrence des middleware
La nouvelle orientation de l’omg, le mda, a été rendue publique en novembre 2000.
Il s’agit d’un constat réalisé douze ans après la création de l’omg. La recherche de l’in-
teropérabilité entre systèmes d’information ne peut être atteinte uniquement grâce à la
standardisation des infrastructures de middleware, mais par une approche beaucoup
plus globale où la notion de modèle devient essentielle et centrale [5].
Pour résumé, on serait tenté de dire que l’omg déclare terminée la guerre des midd-
leware. Des acteurs divers proposent des middleware hétérogènes auxquels ils sont at-
tachés. Par conséquent, il ne servirait à rien d’essayer d’imposer un ultime middleware.
Cette analyse de la situation n’est pas nouvelle puisque l’omg avait défini des ponts pour
passer de Corba vers d’autres plate-formes. Toutefois, selon ce groupe, cette solution ne
pouvait représenter un objectif réaliste de long terme, ni être à la base d’une stratégie [6].
Xavier Moghrabi — Année universitaire : 2002-2003 — 6L’approche Model-Driven Architecture, crédible pour développer un progiciel de gestion intégré
1.2.3 Une montée en abstraction
Aujourd’hui la nouvelle stratégie mda se démarque de l’ancienne, Object Management
Architecture - oma, en se positionnant clairement à un niveau d’abstraction supérieur et
en mettant le projecteur non plus sur les approches à objets mais sur les approches à
modèles de composants [7]. Le but est de favoriser l’élaboration de modèles de plus haut
niveau d’abstraction et les approches de transformation vers les plate-formes techniques.
Ceci signifie qu’il sera possible de définir un modèle métier totalement indépendant des
plate-formes techniques et de générer du code spécifique à la plate-forme d’implémentation.
L’iniative mda repose sur un changement de paradigme important dans le domaine du
génie logiciel. La rapidité de cette évolution s’explique par trois facteurs au moins.
Le premier facteur est la nécessité de découpler les éléments considérés stables dans
la logique métier, de l’évolution des supports technologiques informatiques. Cette évolu-
tion dont on a accepté le caractère non conjoncturel, inéluctable et perpétuel ne va pas
se ralentir. Toutefois, elle ne doit pas pénaliser la capitalisation logicielle du savoir et du
savoir-faire de l’entreprise. L’objectif est donc clair même si les stratégies pour l’atteindre
ne sont pas totalement explicitées.
Le deuxième facteur concerne la relative incapacité de la technologie orientée objet
à tenir ses promesses. La complexité croissante des déploiements logiciels basés sur les
formes modernes de composants comme les ejb est contraire aux espoirs de simplification
conceptuelle des promesses de la technologie. Le recours à des expédients technologiques
(cas d’utilisation, patterns de conception, programmation orientée aspect,. . .) ne fait que
renforcer le constat que la technologie orientée objet n’est pas le remède miracle du génie
logiciel [8].
Le troisième facteur est l’urgence de stopper l’empilement des technologies. Les sys-
tèmes d’information sont parfois composés d’une mosaı̈que hétéroclite de technologies,
pour lesquelles il est nécessaire de conserver des compétences associées pour des raisons de
maintenance. Cette situation s’étend au fur et à mesure que les systèmes s’agrandissent.
La parade à cette accumulation de surcouches technologiques consiste à remplacer les ap-
proches interprétatives par des approches transformationnelles capables de générer des
systèmes plus légers, moins gourmands en ressources et plus finement adaptés aux besoins
réels des applications. L’approche interprétative reconnaı̂t que les individus ont un rôle
très actif dans la construction des systèmes informatiques alors que l’approche transfor-
mationnelle réduit leur rôle grâce à une automatisation de la construction.
Desmond D’Souza [9] a identifié trois dimensions dans l’architecture des modèles re-
présentant une entreprise :
– la dimension horizontale : au sein d’une même entreprise cohabitent différentes
vues partielles du système. Chacune correspond à un domaine différent avec ses
objectifs propres et sa terminologie particulière. Chacune se traduit par des modèles
particuliers, et éventuellement des méta-modèles spécifiques.
– le dimension verticale : au sein d’un même domaine, on peut trouver différents
niveaux d’abstraction.
– la dimension des variantes : au sein de cette architecture peuvent cohabiter diffé-
rentes versions de modèles. Elles représentent le système tel qu’il a été, tel qu’il est,
tel qu’il sera ou tel qu’il pourrait être.
Xavier Moghrabi — Année universitaire : 2002-2003 — 7L’approche Model-Driven Architecture, crédible pour développer un progiciel de gestion intégré
Fig. 1.1 – Description du méta-modèle mda
Une problèmatique du mda concerne l’organisation des modèles et donc des méta-
modèles. En effet, les différents domaines ne sont pas totalement disjoints. Il existe de
nombreuses relations entre eux. Il est donc nécessaire d’expliciter ces relations, et ce de
plus haut niveau d’abstraction afin de faciliter l’interopérabilité.
1.2.4 Détail de l’architecture du MDA
Le mda est un méta-modèle de composants. Comme précisé auparavant, il ne spécifie
pas une nouvelle architecture middleware mais définit une représentation de l’archi-
tecture abstraite et indépendante de la plate-forme technique, tout en lui associant une
multitude de services métiers. La figure 1.1, à la page 8, présente une description du méta-
modèle du mda [10].
Les termes pim, psm, expliqués dans le section suivante, représentent des modèles res-
pectivement indépendant et spécifique à la plate-forme technique. Le pim, le psm et les
techniques de mappage sont basés sur un méta-modèle représenté de préférence avec les
standards définis par l’omg (uml, mof, cwm et xmi).
L’objectif du mda est la création d’une représentation uml de la logique métier et de
lui associer des caractéristiques mda. Des outils devraient permettre de générer automati-
quement des composants en fonction de l’architecture à composants choisie (ejb, Corba,
.net ou services web). Un travail de finalisation sera nécessaire pour affiner le modèle
obtenu en fonction du contexte choisi.
La migration d’une application d’une infrastructure à une autre consiste ainsi à de-
mander, du modèle mda de la logique métier, une génération du modèle spécifique à la
nouvelle infrastructure cible. L’automatisation de la génération devra permettre de réduire
la durée et les coûts de migration. De plus, un éditeur pourra envisager plus facilement
d’éditer un logiciel pour les plate-formes techniques supportées par le mda.
Xavier Moghrabi — Année universitaire : 2002-2003 — 8L’approche Model-Driven Architecture, crédible pour développer un progiciel de gestion intégré
Fig. 1.2 – Vue globale de l’achitecture du mda
La figure 1.2, de la page 9, représente une vision globale du mda [11].
Le noyau de l’architecture de mda est basé sur des standards de l’omg tels que uml,
mof, cwm et xmi. Plusieurs modèles types du noyau existent et l’omg les nomme des pro-
fils uml. Chaque profil répond à un besoin précis. Par exemple, l’un d’entre eux représente
le système de l’entreprise avec sa structure de composants et des interactions transac-
tionnelles ; un autre, un système en temps réel avec des besoins spéciaux de contrôle de
ressources... Grâce aux technologies du noyau, les architectes pourront représenter les mo-
dèles du système.
L’anneau autour représente les technologies middleware. Nous y retrouvons les stan-
dards actuels tels que les ejb, Corba, .net et les Services Web. L’architecture technique
doit contenir des composants. Un modèle spécifique à la plateforme doit être réalisé. Il est
également représenté par le formalisme uml mais selon un profil spécifique à la plate-forme
cible.
L’anneau extérieur au cercle représente les services. Ceux-ci permettent de gérer les
fonctionnalités de base du système comme les transactions, la persistance, la sécurité, les
évènements ou les répertoires.
Enfin, une couche spécifique au domaine d’application se situe à la périphérie du noyau
en englobant le tout. Ce sont les profils uml qui permettent de définir cette couche et
proposent des frawework spécifiques au domaine d’application du système.
Xavier Moghrabi — Année universitaire : 2002-2003 — 9L’approche Model-Driven Architecture, crédible pour développer un progiciel de gestion intégré
1.3 L’importance des modèles
1.3.1 Les différents modèles du MDA
L’omg définit dans son guide sur le mda quatre modèles standards [12].
CIM
Le cim est l’abréviation anglaise de Computation Independent Model. Les exigences du
système sont modélisées dans ce modèle qui décrit la situation dans laquelle le système sera
utilisé. Un tel modèle est parfois appelé Business Model ou Domain Model (c’est-à-dire
un modèle de l’entreprise). Il ne montre pas les détails de la structure du système. Typi-
quement ce modèle est indépendant de l’implémentation du système. Le cim correspond
à la modélisation de l’entreprise sans parler encore de système informatique.
Il montre le système au sein de l’environnement dans lequel il opèrera. Il aide ainsi
pour représenter ce que le système devra exactement faire. Il se révèle utile, non seulement
comme une aide pour comprendre le problème, mais aussi comme une source du vocabulaire
partagé avec d’autres modèles. Dans la spécification mda, les exigences du cim doivent
pouvoir est suivies à la construction des autres modèles (pim et psm) qui les implémentent
et vice versa.
Le cim est constitué de deux modèles uml, des points de vue de l’entreprise et des
informations. Le cim joue un rôle important pour combler le fossé entre les experts, du
métier et des exigences, et les experts de la conception des artéfacts, qui ensemble satisfont
les exigences métier.
PIM
Le terme pim est l’acronyme de l’anglissisme Platform Independent Model soit le modèle
indépendant de la plate-forme. Cela signifie que ce type de modèle n’a pas de dépendance
avec la plate-forme technique. Il décrit le système mais ne montre pas les détails de son uti-
lisation sur la plate-forme. Le pim représente ainsi la logique métier, spécifique au système,
mais indépendant de la technique et de la technologie. Le pim correspond à la modélisation
du système de manière indépendante à la plate-forme.
Ce modèle est concrètement représenté par un diagramme de classes en uml. Le pim
donne une sémantique aux classes à l’aide de stéréotypes selon le méta-modèle mda et les
profils uml.
PSM
Le psm, pour Platform Specific Model, est, quant à lui, un modèle dépendant de la
plate-forme technique. Ce type de modèle sert essentiellement de base à la génération de
code exécutable.
Ce modèle, produit à partir d’une transformation du pim, est un modèle du même
système que le pim mais spécifié par rapport à la plate-forme. Il décrit aussi comment ce
système utilisera la plate-forme choisie.
Un psm peut fournir plus ou moins de détails selon son but. Un psm peut être une im-
plémentation, s’il fournit toutes les informations utiles pour construire le système. D’autre
part, un psm peut ressembler à un pim pour définir un niveau d’abstraction intermédiaire
entre le pim et le psm d’implémentation.
Xavier Moghrabi — Année universitaire : 2002-2003 — 10L’approche Model-Driven Architecture, crédible pour développer un progiciel de gestion intégré
Fig. 1.3 – Exemple d’utilisation des modèles du mda pour réaliser une application
Un psm d’implémentation fournit un large éventail d’informations tels que le code du
programme, les types pour l’implémentation, les programmes liés et les spécifications, les
descripteurs de déploiement, et d’autres formats de spécification.
PDM
Ce modèle est désigné par l’acronyme pdm pour Plateform Description Model. Il cor-
respond à un modèle de transformation du pim vers un psm d’implémentation. L’architecte
doit choisir une ou plusieurs plate-formes pour l’implémentation du système avec les qua-
lités architecturales désirées.
Ce modèle propre à la plate-forme est utile pour la transformation du pim en psm. La
démarche mda est ainsi basée sur le détail des modèles dépendant de la plate-forme. Il
représente les particularités de chaque plate-forme. Il devrait être fourni par le créateur de
la plate-forme.
La figure 1.3, de la page 11, représente un ordre d’intervention de ces modèles dans la
création d’une application. L’annexe A organise et structure tous ces modèles grâce à une
”Architecture à quatre niveaux” définie par l’omg.
1.3.2 La transformation des modèles
Le mappage est utilisé pour les transformations suivantes [11].
Xavier Moghrabi — Année universitaire : 2002-2003 — 11L’approche Model-Driven Architecture, crédible pour développer un progiciel de gestion intégré
PIM vers PIM
Ces transformations interviennent quand un modèle est agrandi, réduit ou spécialisé
pendant le cycle de développement sans aucune information dépendante de la plate-forme.
Le fait de masquer quelques éléments afin de s’abstraire de détails fonctionnels est typi-
quement une transformation pim vers pim. Un des mappages les plus évidents est la trans-
formation du modèle d’analyse à celui de conception. Ces mappages sont généralement
reliés à un affinage du modèle. Ces transformations ne sont pas toujours automatisables.
PIM vers PSM
Ces transformations s’effectuent quand le pim est suffisamment défini pour être trans-
posé dans l’infrastructure d’exécution. La projection est basée sur les caractéristiques de
la plate-forme technique. La description des caractéristiques doit être réalisée par le pdm
(et éventuellement un profil pour décrire les concepts de la plate-forme). La transposition
d’un modèle de composants logiques à un modèle de composants existants (tels que les ejb
du framework j2ee ou CCM de Corba) est un mappage de pim vers psm. L’opération
consiste à ajouter des informations propres à la plate-forme technique. Ces transformations
ont donc pour but d’être fortement automatisées.
PSM vers PSM
Ces transformations sont utilisées lors des phases de déploiement, d’optimisation ou de
reconfiguration. Une fois empaquetés, l’intégration des composants peut être réalisée en
spécifiant l’initialisation des données, les machines cibles, la génération du conteneur et la
configuration. . . Ces mappages sont généralement dus à un affinage du modèle.
PSM vers PIM
Ces transformations s’effectuent pour construire un modèle d’abstraction pim à partir
d’un système existant dépendant d’une plate-forme. Cette procédure correspond ainsi à
du reverse engineering. Elle est assez difficile à réaliser et est difficilement entièrement
automatisable. Cette transformation est pourtant nécessaire pour toute migration d’un
système existant vers l’approche mda.
1.3.3 Les profils UML
Les profils uml jouent un rôle important dans le mda du fait des mappages entre mo-
dèles. Pour implémenter le mappage, le mécanisme a besoin de connaı̂tre les méta-modèles
d’entrée, ceux de sortie et les règles de mappage. Les règles de transformation peuvent
être réalisées à l’intérieur des outils uml (par exemple en utilisant un système de script)
ou par des outils externes (par exemple en travaillant sur des fichiers xmi).
La figure 1.4, page 13, présente un exemple de mappage de pim vers psm en utilisant le
profil de l’omg de l’Enterprise Distributed Object Computing - EDOC [11]. Ce profil doit
permettre de définir un système d’information d’entreprise à base de composants distri-
bués. C’est grâce à ce profil que les composants d’entreprise doivent être définis. D’autres
profils sont en cours de définition. Le profil Enterprise Application Integration - EAI per-
mettra de concevoir des systèmes fortement couplés. Le profil permet de représenter les
communications asynchrones et les envois de messages, quelque soit la plate-forme (pim).
Le profil Scheduling - SCH servira à l’ordonnancement. Il est typiquement utilisé pour la
Xavier Moghrabi — Année universitaire : 2002-2003 — 12L’approche Model-Driven Architecture, crédible pour développer un progiciel de gestion intégré
Fig. 1.4 – Un exemple de méta-modèle en mda
modélisation des applications temps réels, quelque soit la plate-forme (pim).
Une architecture à base de composants est décrite en utilisant le profil EDOC sur la
figure 1.4, de la page 13. Ce profil spécifie également les règles de mappages standards entre
EDOC et les modèles de composants standards comme les ejb. Le mappage de EDOC à
ejb n’est pas un profil en lui-même, mais peut être associé à la notion de profil car on
connaı̂t les modèle et méta-modèle d’entrée et de sortie. Les règles et techniques standards
de spécification pour aller d’un modèle à un autre sont ainsi définies.
Actuellement, un effort important est à fournir pour transformer complètement le pim
vers un psm. Nous pouvons espérer que l’intégralité de cette phase sera automatisée dans
les années à venir (2008) [13].
1.4 Qu’attendre de l’approche MDA ?
Cette approche constitue un pas majeur dans le domaine du génie logiciel. Le principal
intérêt des chefs d’entreprise est de savoir la valeur ajoutée apportée par le mda.
1.4.1 Les forces
Une multitude d’avantages est attendue par les entreprises et les organisations de stan-
dardisation qui travaillent sur le mda. Dans les paragraphes suivants, nous en illustrerons
trois.
Xavier Moghrabi — Année universitaire : 2002-2003 — 13L’approche Model-Driven Architecture, crédible pour développer un progiciel de gestion intégré
Des systèmes interopérables favorisant l’hétérogénéité des plate-formes
Aujourd’hui, les groupes industriels essayent de créer des systèmes d’information ou
d’autres applications informatiques sur une seule plate-forme particulière. Bien que beau-
coup d’industriels possèdent un middleware dominant leur système informatique, chez
aucun d’entre eux une unique plate-forme ne peut gérer l’ensemble de l’interopérabilité du
réseau.
Ainsi, dans le but d’accroı̂tre leur cible, les éditeurs de logiciels peuvent rendre rapide-
ment disponible leurs produits pour différentes plate-formes et en développant l’interopé-
rabilité avec les systèmes existants grâce à la démarche de mda.
De plus, comme le mda prévoit des passerelles favorisant l’interopérabilité d’une plate-
forme à une autre, les industries peuvent combiner plus facilement des systèmes hétéro-
gènes. Cela permettra à toutes les entreprises d’utiliser des standards pour à la fois les
transactions internes ou interentreprises [14].
Le choix de la plate-forme technique la mieux adaptée
Les logiciels du marché sont le plus souvent destinés à une plate-forme technique don-
née. L’utilisateur doit ainsi se soumettre à cette contrainte ou refuser d’utiliser le logiciel.
Les éditeurs adoptant le mda pourraient proposer à leurs clients ce choix. Par exemple,
des logiciels de conception et réalisation assistées par ordinateur (CAD/CAM : Computer
Aided Design/Manufacturing) et de gestion des données produits (PDM : Product Data
Management) nécessitent un couplage fort. L’utilisateur décide qu’ils fonctionneront sur
Corba, la plate-forme pour laquelle ils ont déjà été conçus.
De l’autre côté, il souhaite ajouter une application qui concerne l’ensemble de l’en-
treprise, la gestion de la chaı̂ne logistique (SCM : Supply Chain Management). Il choisit
de l’implémenter en services web pour l’avantage de cette technologie en terme d’inter-
opérabilité avec des applications externes. En effet, cette plate-forme fournit la possibilité
d’intégrer cette application dans d’autres. En utilisant le mda, un tel environnement ne
pose pas de problèmes à être implémenté et déployé. En fait, beaucoup d’industries auront
besoin d’exposer une partie de leurs applications à des partenaires extérieurs qui ne pos-
sèdent pas le même système informatique. Les services web représentent une technologie
intéressante sur ce point et le mda fournira l’architecture qui convient [14].
Un développement plus rapide et des logiciels de meilleure qualité
Le modèle pim du mda spécifie seulement les fonctionnalités métier et le comportement
de l’application, sans se soucier de l’aspect spécifique à la plate-forme. En travaillant dans
cette optique, les architectes et les concepteurs peuvent se focaliser exclusivement sur le
détail de la logique métier. Ils travailleront le modèle jusqu’à obtenir exactement ce qui est
spécifié dans le cahier des charges. Ils mettront ainsi une charge de travail conséquente sur
la production de ce modèle car il est à la base de la génération des modèles spécifiques à la
plate-forme technique. Si un aspect de l’implémentation ne fonctionne pas correctement, il
est facile de savoir s’il s’agit d’une erreur comportementale sur le modèle métier ou d’une
faute dans le code.
De plus, l’approche de l’omg vise automatiser la production de code à partir des
Xavier Moghrabi — Année universitaire : 2002-2003 — 14L’approche Model-Driven Architecture, crédible pour développer un progiciel de gestion intégré
modèles psm. Le processus de développement est accéléré par l’utilisation d’outils. Ces
derniers permettent de réaliser automatiquement les mappages du pim vers le psm, laissant
aux concepteurs le soin de s’attacher sur les détails. Ensuite, ils permettent de générer
automatiquement le code à partir du psm. La migration vers une autre technologie est
ainsi plus aisée et rapide [14].
1.4.2 les faiblesses
Bien que cette approche soit intéressante, il existe plusieurs défis potentiels auxquels
l’omg devra s’attaquer. L’utilisateur actuel du mda doit en être conscient.
La question sur les outils
L’idée de mda est de générer (presque) automatiquement les modèles psm depuis les
pim. Toutefois, ceci ne pourrait être possible seulement pour quelques rares environnements
techniques. Le problème est que la technologie sous-jacente change trop rapidement, mais
le temps que les mappages automatiques soient en place pour une plate-forme, la tech-
nologie risque de changer. De plus, la démarche mda devrait être adaptée à plusieurs
plate-formes. Les vendeurs ne pourront fournir des outils pour toutes les plateformes et
ils devront en choisir quelques unes. Ainsi, un utilisateur qui acquérrait un outil mda se
limiterait à travailler sur les plate-formes supportées. Il ne serait pas possible d’intégrer
des plate-formes hétérogènes.
Chaque éditeur d’outil respectera le mda à sa propre manière à l’instar des outils
Corba. La norme Corba est très complète pour bâtir une architecture distribuée, toute-
fois beaucoup d’outils supportant Corba n’étaient pas aussi complets et les éditeurs im-
plémentaient leur propre version de la norme. Le résultat était que différents orb Corba
fonctionnaient mal ensemble. Ainsi le même scénario peut se répéter avec les outils mda.
Les outils seront hétérogènes et le passage d’un modèle d’un outil à un autre pourrait être
délicat malgré l’utilisation de xmi. Ce type de problème est d’ailleurs souvent favorisé par
le leader du marché. Dans le passé, de nombreuses stratégies d’intégration d’outils ont
échoué lamentablement, pourquoi en serait-il différent avec le mda [15] ?
Le MDA est trop compliqué
Une hypothèse fondamentale de la démarche mda est que les développeurs aient des
compétences significatives en modélisation. Toutefois cette vision idéaliste reste loin de la
réalité. La plupart des développeurs créent rarement et difficilement des diagrammes uml.
Ils ne savent pas forcément ce que représentent les neuf diagrammes d’uml [15].
La difficulté d’une approche par modèles ne permettra qu’à un faible pourcentage
des développeurs d’avoir les compétences pour modéliser complètement des systèmes. Le
mda nécessite l’implication de professionnels de la modélisation. Ces personnes sont rares
dans les petites structures ou chez les industriels. Cette limitation risque de définir le
mda comme une approche destinée aux gros projets. Cette remarque peut faire penser à
l’évolution de Corba, une norme complète pour bâtir des systèmes distribués. Toutefois
cette norme est très compliquée à mettre en œuvre et la répartition des implémentations
Corba diminue au profit de technologies plus simples tels que .net ou j2ee.
Xavier Moghrabi — Année universitaire : 2002-2003 — 15L’approche Model-Driven Architecture, crédible pour développer un progiciel de gestion intégré
La distinction des modèles
Le mda distingue les objets liés à la plate-forme de ceux qui en sont indépendants.
Ce concept d’indépendance de la plate-forme reste aujourd’hui un objectif plus qu’une
définition opérationnelle. Derrière cette notion se cache une réalité complexe. On est en
droit de se poser la question où se trouve la limite entre les modèles ? L’omg n’a pas défini
le terme plate-forme qui n’est pas seulement un middleware. La limite entre les modèles
pim/psm n’est pas franche tant que l’ensemble des termes n’est pas spécifié.
Pour le moment, on précise la notion de pim en disant que ce n’est pas un psm. La notion
de pdm pour Platform Description Model (modèle de description de la plate-forme) aide à
affiner cette définition. Des propositions comme le cim sont apparues mais l’objectif reste
d’identifier ce qui est stable au travers de différentes mises en oeuvres si la logique métier
est conservée [20]. L’avancée du mda ne permet pas à n’importe qui de l’appliquer. Son
utilisation reste encore au stade expérimental et est réalisée par le monde de la recherche
ou par les sociétés impliquées dans la définition de cette norme.
1.5 Les standards de l’OMG utilisés
L’omg a défini plusieurs standards pour le mda. Ci-après nous dressons une liste des
plus importants, attachés d’une note explicative [11].
1.5.1 MOF : Meta Object Facility
Le mof définit la structure de tous les méta-modèles comme uml, cwm et SPEM.
L’intérêt principal du mof est surtout qu’il permet la définition d’opérations globales non
spécifiques applicables à tous les méta-modèles. L’exemple le plus significatif est xmi qui
propose l’échange de modèles quel que soit leur méta-modèle ou ocl qui permet de com-
pléter des éléments arbitraires des modèles avec des assertions logiques. Un autre exemple
est la fourniture d’API définis en idl permettant la manipulation par programmation des
modèles.
1.5.2 UML : Unified Modeling Language
uml est devenu le standard de modélisation des logiciels à objets. Il permet la modéli-
sation d’architectures, de structure d’objets, d’interactions entre ces objets, de données, de
composants, de framework,. . . Le mda préconise l’utilisation d’uml pour l’élaboration
des modèles. À l’heure actuelle, la version 2.0 est sortie et validée. Cette version contient
entre autre une évolution du langage d’expression de contrainte ocl [16], des concepts
renforcés pour les composants et s’intègrera plus facilement dans le mda grâce notamment
à un rapprochement avec le mof. Le noyau d’uml (infrastructure) et les extensions (su-
perstructure) sont aussi redéfinis.
Un des aspects intéressants d’uml est le concept de profils. Ces derniers permettent
d’adapter uml à un domaine qui était souvent mal couvert. Comme uml est un forma-
lisme, les profils représentent alors des dialectes de ce langage. Ces dialectes sont fortement
utilisés dans le mda. Par exemple le profil ejb permet l’élaboration de psm pour la plate-
forme ejb. À l’heure actuelle l’omg définit entre autre un profil pour l’EAI, un profil pour
les composants d’entreprise (EDOC), un profil pour les tests, un profil pour le temps réel,
Xavier Moghrabi — Année universitaire : 2002-2003 — 16L’approche Model-Driven Architecture, crédible pour développer un progiciel de gestion intégré
un profil pour Corba et un profil pour ejb. Ces deux derniers profils permettront d’au-
tomatiser la transformation du pim en psm de la plate-forme respective.
Enfin, la dernière partie d’uml 2.0 correspond à la séparation du contenu logique de
la présentation physique. Ce problème assez important est ainsi résolu en fournissant un
méta- modèle séparé de présentation (Diagram Interchange) qu’il sera possible de modifier
ou d’exploiter en utilisant des standards du W3C (xslt et svg notamment).
1.5.3 CWM : Common Warehouse Metamodel
cwm est le standard de l’omg qui traite des entrepôts de données. Il couvre toutes
les étapes nécessaires à l’élaboration, à la création et à la transformation des entrepôts de
données. L’approche préconisée par ce standard pour la migration est une approche mda.
C’est-à-dire la création de modèles et leurs transformations. cwm définit les méta-modèles
des principaux types d’entrepôts de données (Relationnel, Objet, xml,. . .) et propose des
règles de transformation entre ceux-ci.
1.5.4 XMI : XML Metadata Interchange
xmi est le standard de l’omg qui fait la jonction entre le monde des modèles et le
monde xml. xmi se base sur le mof. Il permet la génération de dtd et de schémas xml
à partir de méta-modèles. L’application la plus connue de xmi est celle qui a permis la
construction de la dtd uml. Cette dernière permet la représentation des modèles uml sous
forme de documents xml et assure ainsi les échanges de modèles uml entre les différents
outils du marché. Le standard xmi de sérialisation des modèles compatibles avec mof est
en cours de stabilisation et son utilisation devient incontournable dans les outils industriels.
Le mda propose une démarche privilégiant plus les modèles et méta-modèles de haut
niveau d’abstration que le codage de l’application et est ainsi plus pérenne. Il dispose d’un
certain nombre d’avantages comme l’automatisation des transformations de modèles et de
génération de code accélère le développement logiciel.
Xavier Moghrabi — Année universitaire : 2002-2003 — 17Chapitre 2
L’utilisation du MDA
Le développement mda se focalise d’abord sur les fonctionnalités et le comportement
d’une application ou d’un système distribué, sans se préoccuper de la technologie sur la-
quelle le logiciel sera implémenté. Ainsi il n’est pas nécessaire de recommencer la modé-
lisation des fonctionnalités et du comportement du système chaque fois qu’une nouvelle
technologie est adoptée. Les autres approches lient généralement les architectures à une
technologie particulière.
2.1 L’approche MDA est-elle adaptée à la réalisation d’un
ERP
Cette partie montrera que l’approche mda n’est pas destinée à un domaine particulier
de l’industrie logicielle mais transversale à l’ensemble de cette industrie. Nous essayerons
de montrer ce qu’apporterait le mda pour le développement et l’intégration d’un erp.
2.1.1 Le MDA peut s’appliquer à l’ensemble de l’industrie logicielle
Le mda semble destiné à une large partie de l’industrie logicielle. Toutefois, il se montre
naturellement efficace pour les applications dont les fonctionnalités et comportements mé-
tiers sont primordiaux et pour les éditeurs qui souhaitent développer leurs produits pour
différentes plate-formes. Ainsi les éditeurs de logiciel de gestion ont tout intérêt à prendre
conscience de l’approche mda.
Le fait que le mda soit défini par le consortium de l’omg est un gage de qualité qui
permettra de réaliser un standard neutre des outils et des entreprises. Les groupes Domain
Task Forces - dtf de l’omg ont pour but de standardiser les modèles de domaines. L’objec-
tif est de spécifier des architectures communes à des catégories particulières d’applications.
En effet, les applications d’un même domaine d’activité (par exemple : la comptabilité, le
commerce électronique, les banques, etc.) ont des caractéristiques communes. La factorisa-
tion de celles-ci aboutirait à des architectures pré-cablées. On évite ainsi aux développeurs
de travailler “from scratch” (autrement dit à partir de zéro) et de réinventer à chaque fois
la roue.
Depuis 1996, une partie des membres de l’omg se rencontre dans ces communautés
pour standardiser les services et les mécanismes spécifiques à un marché vertical. Jusqu’en
2000, ces spécifications consistaient à écrire des interfaces pour Corba accompagnées d’une
sémantique. Un service ou un mécanisme bien conçu est toujours basé sur un modèle de
Xavier Moghrabi — Année universitaire : 2002-2003 — 18Vous pouvez aussi lire
