L`approche Model-Driven Architecture, crédible pour développer un

Transcription

ÉCOLE DOCTORALE SYSTÈMES
L’approche Model-Driven
Architecture, crédible pour
développer un progiciel de
gestion intégré
Mémoire de DEA – Systèmes Industriels
Tuteur : Paul Gaborit
Xavier Moghrabi
— Année universitaire : 2002-2003 —
Remerciements
Je tiens à exprimer mes plus vifs remerciements à mon tuteur Franck Darras, doctorant à l’École des Mines d’Albi–Carmaux, pour m’avoir aidé à réaliser mon DEA. Il m’a
permis de trouver un sujet intéressant et m’a fourni une partie des documents pour la
bibliographie.
Je remercie Paul Gaborit et Hervé Pingaud, enseignant-chercheurs au centre génie
industriel de l’École des Mines d’Albi–Carmaux, pour leurs conseils, le suivi de mon travail
et les remarques formulées sur ce document.
Je tenais à remercier Thomas Van Oudenhove de Saint Géry, camarade de classe
à l’École des Mines en option Génie des Systèmes d’Information et futur doctorant dans
cette école. Il m’a fournit son modèle de document et son aide pour rédiger ce mémoire de
DEA sous LATEX.
Pour finir, je souhaite remercier la structure d’accueil de mon stage qui m’a donné
l’opportunité et libéré du temps pour la réalisation de ce travail. Pour des raisons de confidentialité, j’ai préféré ne pas citer son nom mais les intéressés se reconnaı̂tront.
Xavier Moghrabi
i
Résumé
Les systèmes d’information sont de plus en plus complexes. Avec la multitude des technologies, les décideurs ne savent plus laquelle adoptée. Le Model-Driven Architecture est
issu d’un constat que chaque nouvelle évolution technologique entraı̂ne un coût significatif.
Proposée par l’OMG, cette approche permet de pérenniser les systèmes d’information en
séparant les modèles métiers de ceux d’implémentation. Des mécanismes de transformations sont prévus pour automatiser le passage et la construction. Cette approche, de plus
haut niveau d’abstraction, réduira les coûts de développement, facilitera les migrations
technologiques, améliorera l’interopérabilité entre les systèmes. . .
Le MDA est conçu pour des systèmes à base de composants fonctionnant sur un middleware. L’étude envisage la possibilité de l’appliquer pour réaliser un progiciel de gestion
d’entreprise. Les problèmes de réalisation et d’exploitation sont les mêmes que ceux énumérés précédemment. Le MDA est adapté car il dispose de méta-modèles verticaux adaptés
à chaque domaine. De plus, des méthodes de développement permettent d’intégrer cette
démarche. Des applications expérimentales ont déjà été développées en utilisant le MDA
et des outils “compatibles MDA“ apparaissent.
Pour prouver l’efficacité du MDA en terme de productivité lors du développement,
une société a réalisé une étude. Elle consistait à mettre en concurrence deux équipes de
développement. Il s’est avéré que l’é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 finalisé. Les transformations de modèles et les générations de code ne sont pas encore entièrement automatisées.
Xavier Moghrabi
ii
Table des matières
Remerciements
i
Résumé
ii
Table des matières
iv
Introduction
1
1 Une nouvelle approche dans la conception logicielle
1.1 Sujet de l’étude . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1 La problèmatique des ERP . . . . . . . . . . . . .
1.1.2 Un ERP à base de composants . . . . . . . . . . .
1.2 Présentation du MDA . . . . . . . . . . . . . . . . . . . .
1.2.1 Séparation entre la logique métier et la technologie
1.2.2 L’abandon de la concurrence des middleware . . .
1.2.3 Une montée en abstraction . . . . . . . . . . . . .
1.2.4 Détail de l’architecture du MDA . . . . . . . . . .
1.3 L’importance des modèles . . . . . . . . . . . . . . . . . .
1.3.1 Les différents modèles du MDA . . . . . . . . . . .
1.3.2 La transformation des modèles . . . . . . . . . . .
1.3.3 Les profils UML . . . . . . . . . . . . . . . . . . .
1.4 Qu’attendre de l’approche MDA ? . . . . . . . . . . . . . .
1.4.1 Les forces . . . . . . . . . . . . . . . . . . . . . . .
1.4.2 les faiblesses . . . . . . . . . . . . . . . . . . . . .
1.5 Les standards de l’OMG utilisés . . . . . . . . . . . . . . .
1.5.1 MOF : Meta Object Facility . . . . . . . . . . . . .
1.5.2 UML : Unified Modeling Language . . . . . . . . .
1.5.3 CWM : Common Warehouse Metamodel . . . . . .
1.5.4 XMI : XML Metadata Interchange . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
2
2
3
6
6
6
7
8
10
10
11
12
13
13
15
16
16
16
17
17
2 L’utilisation du MDA
2.1 L’approche MDA est-elle adaptée à la réalisation d’un ERP . . . . . . . .
2.1.1 Le MDA peut s’appliquer à l’ensemble de l’industrie logicielle . . .
2.1.2 Le MDA demande des moyens adaptés . . . . . . . . . . . . . . . .
2.1.3 Le MDA répond aux besoins de création et d’intégration des ERP
2.2 La méthode de développement . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 La MDA face aux méthodes agiles . . . . . . . . . . . . . . . . . .
2.2.2 La révision du cycle en Y . . . . . . . . . . . . . . . . . . . . . . .
2.2.3 Une nouvelle implémentation du processus unifié : EUP . . . . . .
.
.
.
.
.
.
.
.
18
18
18
20
22
23
23
24
26
Xavier Moghrabi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
iii
2.3
Détail
2.3.1
2.3.2
2.3.3
2.3.4
d’un système d’information utilisant la philosophie du MDA
Le système d’information de la banque Wells Fargo . . . . .
L’environnement des traitements . . . . . . . . . . . . . . .
Le développement à base de modèles . . . . . . . . . . . . .
Le MDA fournit une passerelle pour le futur . . . . . . . . .
.
.
.
.
.
27
27
28
29
31
3 Les perspectives de cette approche logicielle
3.1 Étude de productivité de la démarche MDA . . . . . . . . . . . . . . . . . .
3.1.1 Les différences entre les approches MDA et traditionnelle . . . . . .
3.1.2 Description de l’objectif de l’étude . . . . . . . . . . . . . . . . . . .
3.1.3 L’analyse architecturale du système . . . . . . . . . . . . . . . . . .
3.1.4 Les résultats quantitatifs . . . . . . . . . . . . . . . . . . . . . . . .
3.1.5 Conclusion de l’étude de productivité . . . . . . . . . . . . . . . . .
3.2 Vers un nouveau standard de développement logiciel . . . . . . . . . . . . .
3.2.1 L’approche MDA, évolution ou révolution ? . . . . . . . . . . . . . .
3.2.2 Une approche de modélisation d’un ERP où le MDA a sa place . . .
3.2.3 Le MDA présente des atouts pour s’imposer comme un nouveau
standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
32
32
33
34
36
36
37
37
38
Conclusion
43
Glossaire
44
Table des figures
46
Bibliographie
47
A Une architecture stratifiée
50
B Évolution hebdomadaire de l’étude
52
C Glossaire des design pattern utilisés
56
Xavier Moghrabi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
41
iv
Introduction
Depuis maintenant quelques années, de nouvelles architectures logicielles à base de
composants émergent régulièrement. Ce qui à l’origine devait permettre une réutilisabilité
extrêmement importante se voit aujourd’hui soumis aux modes et à des évolutions très importantes. Les entreprises ne veulent plus investir des sommes colossales pour suivre cette
incessante remise en cause de leur système d’information existant. Elles veulent pérenniser
leurs architectures.
L’omg a mis à contribution son expérience dans les middleware avec Corba et dans
la modélisation avec notamment uml pour élaborer une norme de méta-modélisation des
architectures à base de composants : le Model-Driven Architecture - mda.
Il définit une nouvelle approche orientée modèle dans laquelle les composants révèlent
une sémantique indépendante de toute plateforme, permettant ainsi de mieux se concentrer sur la logique métier. Le mda dé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 déjà très largement adoptés comme références (Profils uml, mof,. . .), la
mise au point d’un méta-modèle spécifié suivant cette norme permettra d’automatiser la
transformation vers des modèles spécifiques à des plate-formes particulières et la génération de code.
La présente étude tente d’appréhender cette nouvelle démarche dans la conception
logicielle pour déterminer si elle est applicable pour réaliser d’un progiciel de gestion intégré, également appelé erp. Pour cela, nous présenterons les principes du mda, examineront
s’il est adapté au développement d’un erp et finirons par évoquer les perspectives du mda.
NB : Les termes en petite majuscule (erp) sont définis dans le glossaire.
Xavier Moghrabi
1
Chapitre 1
Une nouvelle approche dans la
conception logicielle
Cette première partie sert à présenter le sujet de l’étude et l’approche mda. L’étude
fera un état de l’art sur cette approche pour présenter le mda.
1.1
Sujet de l’étude
La présente étude s’intéresse au développement d’un erp par une approche mda. Le
développement de ce type de produit est un projet à long terme et conséquent pour une
entreprise d’une centaine d’employés.
1.1.1
La problèmatique des ERP
Le cycle de réalisation d’un erp est un travail, de plusieurs dizaines d’années.hommes,
complexe car doit couvrir l’ensemble des besoins de gestion des PME/PMI. Les technologies
orientées objet seront sollicitées pour réaliser un produit bien conçu, évolutif, adaptable et
maintenable. La recherche de ces caractéristiques est motivée par la longue durée de vie
du progiciel et le souhait de répondre aux besoins de gestion spécifiques des clients. En
effet, un erp a une durée d’exploitation moyenne par le client de 8 ans. L’éditeur souhaite,
quant à lui, pouvoir vendre son produit aussi longtemps possible ce qui nécessite un besoin d’évolutivité de la part du produit. De plus, l’éditeur désire créer une seule version du
progiciel qui pourra être spécialisée pour chaque client par la réalisation de programmes
spécifiques et le paramétrage.
Pour garantir cette évolutivité, le logiciel doit être indépendant des technologies. À
l’heure actuelle, pour réaliser un important projet logiciel avec des technologies orientées
objet, trois plateformes technologiques de type middleware sont majoritairement utilisées : j2ee, .net et Corba. Ces technologies permettent de réaliser des applications
complexes, flexibles et distribuées. Lors de la création d’un produit, l’équipe de développement doit choisir la technologie de l’infrastructure. Ce choix est crucial pour la bonne
finition du projet. Il se résume souvent à adopter une technologie dont la pérennité est
fortement probable. En effet, la migration d’une application vers une nouvelle technologie
est très coûteuse.
L’approche mda a pour but de pallier à ce problème en proposant des modèles indépendants de la plate-forme technique qui permettront de générer rapidement et facilement
Xavier Moghrabi
2
L’approche Model-Driven Architecture, crédible pour développer un progiciel de gestion intégré
des modèles spécifiques. Ensuite à partir de ces derniers, le code de l’application serait
créé. La possibilité d’automatiser les opérations de transformation et génération se traduit
par l’apparition d’outils.
1.1.2
Un ERP à base de composants
Comme le concept de “componentisation” [1] est commun à diverses disciplines d’ingénierie et aux industrie, Kumar et al. [2] ont proposé de concevoir un erp à base de
composants pour répondre aux problématiques de variété et de complexité des fonctionnalités. Ce concept peut être utilisé pour concevoir les différents domaines fonctionnels d’un
erp comme des composants logiciels [3].
Définition de composant
Selon la norme uml, un composant est une partie physique remplaçable d’un système
qui fournit la réalisation d’un ensemble d’interfaces et s’y conforme. Dans un développement orienté composant, une application monolithique est découpée en un ensemble de
composants, ce qui favorise sa réutilisation. Il suffit de modifier ou d’ajouter un composant pour introduire une nouvelle fonction dans une application. L’objectif est donc de
réduire le coût du cycle de vie du logiciel. Les composants communiquent au moment de
leur exécution pour concourir à l’application utilisée, sur une même machine ou à travers
un système distribué. Un composant logiciel se représente comme une brique réutilisable
disponible sous forme binaire. Un système à 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 propriétés, méthodes et évènements) composés d’interfaces,
– un ou plusieurs objets compilés et binaires,
– un ou plusieurs objets qui adhèrent à un modèle,
– utilisable indépendamment du langage, de sa localisation et de l’application l’utilisant,
– géré par le système.
La caractéristique principale de l’approche orientée composant est la collaboration
des composants nommée par le concept d’interopérabilité. L’architecture est alors un réel
assemblage avec des outils de haut niveau sans le souci du détail de l’implémentation.
L’orb est le bus logiciel qui permet aux composants de collaborer sur l’ensemble d’un
réseau. En fait, les composants ne collaborent pas directement en invoquant des méthodes
à distance, ils le font par l’intermédiaire de l’orb. Le modèle de composant apporte un
ensemble d’objets et de méthodes (les transactions, la sécurité, la concurrence d’accès,
l’indépendance à la localisation) sans ajout de code. Ainsi le développeur se concentre sur
la partie métier car les services techniques sont pris en charge par l’infrastructure.
Intérêt d’un progiciel à base de composants
Le concept d’erp à base de composants doit permettre de répondre et d’améliorer les
quatre critères définis par Sprott [1] soient :
– l’intégration,
– l’adaptabilité,
Xavier Moghrabi
3
– la facilité de mise à jour,
– la facilité de mise en œuvre.
Un système à composants complètent les intérêts des techniques orientées objet classiques. Il les généralise en proposant :
– une encapsulation parfaite des objets, permettant d’accroı̂tre la maintenabilité et
l’indépendance des différents composants ;
– une réutilisation complète des composants, qui permet un accès sans en avoir le code
source et sans avoir à les intégrer dans le processus de compilation et d’édition de
liens.
Mais les possibilité vont encore plus loin sur l’indépendance des composants. Elle est
telle que qu’il est réalisable de :
– mettre à jour un composant dynamiquement, sans remettre en cause l’ensemble du
progiciel. En effet, les composants sont dans des processus séparés. Il est possible de
mettre à jour l’un d’entre eux sans avoir à compiler, diffuser et réinitialiser l’ensemble
du progiciel.
– accroı̂tre les fonctionnalités d’un progiciel dynamiquement, en y ajoutant des composants polymorphiques avec des composants déjà utilisés. Comme le système ne
manipule les objets répartis que par l’intermédiaire de leurs interfaces, tout objet
respectant ces interfaces peut être utilisé indifféremment. L’adjonction de nouveaux
composants respectant ces interfaces peut donc élargir le champ d’action du système.
Elle lui permet de manipuler des objets dont l’existence n’était a priori même pas
connue lors de la création du progiciel.
– répartir les composants sur différentes machines, et les faire communiquer de manière
transparente via le réseau. Les objets répartis se placent donc au plus haut niveau
de la programmation réseau, et permettent une abstraction complète de la notion
d’appel de méthode d’un objet. Par ailleurs, la répartition des objets fournit une
solution élégante au problème d’équilibrage des charges dans un système complexe.
Certains orb vont jusqu’à autoriser le rééquilibrage des charges dynamiquement, en
phase d’exploitation.
– bénéficier de tous les avantages des architectures client/serveur. Cependant, les progiciels à composants vont plus loin, car ils permettent une finesse incroyable dans
ce type d’architecture. En effet, chaque objet est considéré comme un serveur par
les programmes qui l’utilisent. Inversement, un objet peut très bien être client d’un
autre objet. Il est donc tout à fait possible de centraliser les données dans des objets
dédiés à cette tâche, et d’assurer les services complexes comme la cohérence de ces
données et leur redondance pour les systèmes à défaillance de panne.
– construire un erp de façon modulaire. L’indépendance des composants permet de
concevoir un progiciel où chacun des composants correspondrait à un module.
– assembler des composants hétérogènes interopérables. Des technologies permettent
d’assembler des composants hétérogènes (de langage et système d’exploitation différents) permettent de construire un système d’information d’entreprise par assem-
Xavier Moghrabi
4
blage de composants provenant de différents éditeurs. L’utilisateur pourrait choisir
les composants les mieux adaptés à son besoin et les faire fonctionner ensemble.
Tous ces avantages sont déjà très significatifs. Mais l’étendu des possibilités des systèmes à composants est encore plus vaste que ces simples possibilités techniques. En effet,
les services additionnels fournis par les orb permettent virtuellement de réaliser des systèmes très différents et d’étendre les orb.
Inconvénients d’un progiciel à base de composants
Si les avantages précédents sont issus de l’aboutissement des principes objets, les inconvénients le sont hélas aussi. Ils sont classés en deux catégories :
– l’utilisation exclusive des interfaces pour manipuler les objets répartis implique la définition et l’implémentation complète de ces interfaces, donc une forte augmentation
des frais de conception et de développement des programmes ;
– l’augmentation du risque de faire une “usine à gaz” si la conception n’est pas faite
dans les “règles de l’art”.
Ces deux inconvénients relèvent de la conception, et montrent donc clairement qu’il ne
faut pas se lancer à l’aveugle dans les technologies à composants. D’autre part, d’autres
problèmes additionnels peuvent survenir. Leur importance relative est propre à chaque
orb, mais on peut généralement signaler que :
– la réalisation d’un composant est nettement plus compliquée que l’écriture d’une
classe. Ce constat se traduit par un besoin d’analystes et de développeurs expérimentés.
– les programmes sont plus lents à l’exécution, en raison de l’intervention de l’orb
dans la communication inter-objets. La localisation des différents objets doit être
prise en compte dans la conception d’une application, afin de réduire le temps des
communications.
– la gestion des problèmes de communication peut être soit peu souple, si elle est
complètement masqué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 être coupées.
Ceci est vrai même lorsque les objets sont exécutés sur une mê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 impératif de maı̂triser les
pertes de connexion au plus bas niveau. Tous les orb ne sont pas égaux quant à la
capacité de personnalisation des traitements d’erreurs.
Sur ce dernier point, ce problème relève du choix technologique. Par ailleurs, les problèmes de communication entre objets soulignent plus une qualité qu’un défaut des objets
ré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 conséquent, un système
à composants est globalement plus stable qu’une application monolithique, pour laquelle
l’ensemble des opérations se serait arrêté.
Xavier Moghrabi
5
1.2
Présentation du MDA
La naissance du mda a été motivée par la complexification des systèmes d’information
et des forts coûts de migration technologique. L’omg propose ainsi de monter le niveau
d’abstraction pour s’affranchir des contraintes technologiques.
1.2.1
Séparation entre la logique métier et la technologie
L’histoire des systèmes d’information a connu de nombreuses évolutions que ce soit au
niveau des langages de programmation (procéduraux et fonctionnels, évènementiels, orientés objet, services web...), des middleware (propriétaires, Corba, DCOM/COM+,
RMI...) ou des méthodes de conception (SADT, Merise, les méthodes orientées objet...).
De plus, la diversité des solutions pour résoudre un même problème ne cesse d’augmenter
[4].
Dans ce contexte, les chefs d’entreprise ne veulent plus investir dans un middleware
dont la pérennité est courte. Avec Corba, l’omg pensait fournir une norme suffisamment
puissante et ouverte pour répondre à tous les besoins. Le consortium pensait que Corba
deviendrait ainsi le middleware standard universel à l’instar d’uml comme formalisme
de modélisation. Cependant des architectures différentes se succédèrent, obligeant les entreprises à former leurs ingénieurs et à remettre à jour leurs applications.
Lors d’une migration d’une infrastructure vers une nouvelle technologie, la logique métier de l’application reste globalement la même. Il est donc évident de tenter de différencier
l’architecture technique dépendant de la technologie utilisée de celle de la logique métier.
L’intérêt est de favoriser l’évolutivité, la réduction de coût et l’interopérabilité.
Pour aller dans ce sens, les grandes compagnies informatiques ont ressenti le besoin de
standardiser les différentes tentatives. Elles ont donc logiquement chargé le consortium de
l’omg de la mission de définir une norme indépendante d’un middleware particulier.
1.2.2
L’abandon de la concurrence des middleware
La nouvelle orientation de l’omg, le mda, a été rendue publique en novembre 2000.
Il s’agit d’un constat réalisé douze ans après la création de l’omg. La recherche de l’interopérabilité entre systèmes d’information ne peut être atteinte uniquement grâce à la
standardisation des infrastructures de middleware, mais par une approche beaucoup
plus globale où la notion de modèle devient essentielle et centrale [5].
Pour résumé, on serait tenté de dire que l’omg déclare terminée la guerre des middleware. Des acteurs divers proposent des middleware hétérogènes auxquels ils sont attachés. Par conséquent, il ne servirait à rien d’essayer d’imposer un ultime middleware.
Cette analyse de la situation n’est pas nouvelle puisque l’omg avait défini des ponts pour
passer de Corba vers d’autres plate-formes. Toutefois, selon ce groupe, cette solution ne
pouvait représenter un objectif réaliste de long terme, ni être à la base d’une stratégie [6].
Xavier Moghrabi
6
1.2.3
Une montée en abstraction
Aujourd’hui la nouvelle stratégie mda se démarque de l’ancienne, Object Management
Architecture - oma, en se positionnant clairement à un niveau d’abstraction supérieur et
en mettant le projecteur non plus sur les approches à objets mais sur les approches à
modèles de composants [7]. Le but est de favoriser l’élaboration de modèles de plus haut
niveau d’abstraction et les approches de transformation vers les plate-formes techniques.
Ceci signifie qu’il sera possible de définir un modèle métier totalement indépendant des
plate-formes techniques et de générer du code spécifique à la plate-forme d’implémentation.
L’iniative mda repose sur un changement de paradigme important dans le domaine du
génie logiciel. La rapidité de cette évolution s’explique par trois facteurs au moins.
Le premier facteur est la nécessité de découpler les éléments considérés stables dans
la logique métier, de l’évolution des supports technologiques informatiques. Cette évolution dont on a accepté le caractère non conjoncturel, inéluctable et perpétuel ne va pas
se ralentir. Toutefois, elle ne doit pas pénaliser la capitalisation logicielle du savoir et du
savoir-faire de l’entreprise. L’objectif est donc clair même si les stratégies pour l’atteindre
ne sont pas totalement explicitées.
Le deuxième facteur concerne la relative incapacité de la technologie orientée objet
à tenir ses promesses. La complexité croissante des déploiements logiciels basés sur les
formes modernes de composants comme les ejb est contraire aux espoirs de simplification
conceptuelle des promesses de la technologie. Le recours à des expédients technologiques
(cas d’utilisation, patterns de conception, programmation orientée aspect,. . .) ne fait que
renforcer le constat que la technologie orientée objet n’est pas le remède miracle du génie
logiciel [8].
Le troisième facteur est l’urgence de stopper l’empilement des technologies. Les systèmes d’information sont parfois composés d’une mosaı̈que hétéroclite de technologies,
pour lesquelles il est nécessaire de conserver des compétences associées pour des raisons de
maintenance. Cette situation s’étend au fur et à mesure que les systèmes s’agrandissent.
La parade à cette accumulation de surcouches technologiques consiste à remplacer les approches interprétatives par des approches transformationnelles capables de générer des
systèmes plus légers, moins gourmands en ressources et plus finement adaptés aux besoins
réels des applications. L’approche interprétative reconnaı̂t que les individus ont un rôle
très actif dans la construction des systèmes informatiques alors que l’approche transformationnelle réduit leur rôle grâce à une automatisation de la construction.
Desmond D’Souza [9] a identifié trois dimensions dans l’architecture des modèles représentant une entreprise :
– la dimension horizontale : au sein d’une même entreprise cohabitent différentes
vues partielles du système. Chacune correspond à un domaine différent avec ses
objectifs propres et sa terminologie particulière. Chacune se traduit par des modèles
particuliers, et éventuellement des méta-modèles spécifiques.
– le dimension verticale : au sein d’un même domaine, on peut trouver différents
niveaux d’abstraction.
– la dimension des variantes : au sein de cette architecture peuvent cohabiter différentes versions de modèles. Elles représentent le système tel qu’il a été, tel qu’il est,
tel qu’il sera ou tel qu’il pourrait être.
Xavier Moghrabi
7
Fig. 1.1 – Description du méta-modèle mda
Une problèmatique du mda concerne l’organisation des modèles et donc des métamodèles. En effet, les différents domaines ne sont pas totalement disjoints. Il existe de
nombreuses relations entre eux. Il est donc nécessaire d’expliciter ces relations, et ce de
plus haut niveau d’abstraction afin de faciliter l’interopérabilité.
1.2.4
Détail de l’architecture du MDA
Le mda est un méta-modèle de composants. Comme précisé auparavant, il ne spécifie
pas une nouvelle architecture middleware mais définit une représentation de l’architecture abstraite et indépendante de la plate-forme technique, tout en lui associant une
multitude de services métiers. La figure 1.1, à la page 8, présente une description du métamodèle du mda [10].
Les termes pim, psm, expliqués dans le section suivante, représentent des modèles respectivement indépendant et spécifique à la plate-forme technique. Le pim, le psm et les
techniques de mappage sont basés sur un méta-modèle représenté de préférence avec les
standards définis par l’omg (uml, mof, cwm et xmi).
L’objectif du mda est la création d’une représentation uml de la logique métier et de
lui associer des caractéristiques mda. Des outils devraient permettre de générer automatiquement des composants en fonction de l’architecture à composants choisie (ejb, Corba,
.net ou services web). Un travail de finalisation sera nécessaire pour affiner le modèle
obtenu en fonction du contexte choisi.
La migration d’une application d’une infrastructure à une autre consiste ainsi à demander, du modèle mda de la logique métier, une génération du modèle spécifique à la
nouvelle infrastructure cible. L’automatisation de la génération devra permettre de réduire
la durée et les coûts de migration. De plus, un éditeur pourra envisager plus facilement
d’éditer un logiciel pour les plate-formes techniques supportées par le mda.
Xavier Moghrabi
8
Fig. 1.2 – Vue globale de l’achitecture du mda
La figure 1.2, de la page 9, représente une vision globale du mda [11].
Le noyau de l’architecture de mda est basé sur des standards de l’omg tels que uml,
mof, cwm et xmi. Plusieurs modèles types du noyau existent et l’omg les nomme des profils uml. Chaque profil répond à un besoin précis. Par exemple, l’un d’entre eux représente
le système de l’entreprise avec sa structure de composants et des interactions transactionnelles ; un autre, un système en temps réel avec des besoins spéciaux de contrôle de
ressources... Grâce aux technologies du noyau, les architectes pourront représenter les modèles du système.
L’anneau autour représente les technologies middleware. Nous y retrouvons les standards actuels tels que les ejb, Corba, .net et les Services Web. L’architecture technique
doit contenir des composants. Un modèle spécifique à la plateforme doit être réalisé. Il est
également représenté par le formalisme uml mais selon un profil spécifique à la plate-forme
cible.
L’anneau extérieur au cercle représente les services. Ceux-ci permettent de gérer les
fonctionnalités de base du système comme les transactions, la persistance, la sécurité, les
évènements ou les répertoires.
Enfin, une couche spécifique au domaine d’application se situe à la périphérie du noyau
en englobant le tout. Ce sont les profils uml qui permettent de définir cette couche et
proposent des frawework spécifiques au domaine d’application du système.
Xavier Moghrabi
9
1.3
1.3.1
L’importance des modèles
Les différents modèles du MDA
L’omg définit dans son guide sur le mda quatre modèles standards [12].
CIM
Le cim est l’abréviation anglaise de Computation Independent Model. Les exigences du
système sont modélisées dans ce modèle qui décrit la situation dans laquelle le système sera
utilisé. Un tel modèle est parfois appelé Business Model ou Domain Model (c’est-à-dire
un modèle de l’entreprise). Il ne montre pas les détails de la structure du système. Typiquement ce modèle est indépendant de l’implémentation du système. Le cim correspond
à la modélisation de l’entreprise sans parler encore de système informatique.
Il montre le système au sein de l’environnement dans lequel il opèrera. Il aide ainsi
pour représenter ce que le système devra exactement faire. Il se révèle utile, non seulement
comme une aide pour comprendre le problème, mais aussi comme une source du vocabulaire
partagé avec d’autres modèles. Dans la spécification mda, les exigences du cim doivent
pouvoir est suivies à la construction des autres modèles (pim et psm) qui les implémentent
et vice versa.
Le cim est constitué de deux modèles uml, des points de vue de l’entreprise et des
informations. Le cim joue un rôle important pour combler le fossé entre les experts, du
métier et des exigences, et les experts de la conception des artéfacts, qui ensemble satisfont
les exigences métier.
PIM
Le terme pim est l’acronyme de l’anglissisme Platform Independent Model soit le modèle
indépendant de la plate-forme. Cela signifie que ce type de modèle n’a pas de dépendance
avec la plate-forme technique. Il décrit le système mais ne montre pas les détails de son utilisation sur la plate-forme. Le pim représente ainsi la logique métier, spécifique au système,
mais indépendant de la technique et de la technologie. Le pim correspond à la modélisation
du système de manière indépendante à la plate-forme.
Ce modèle est concrètement représenté par un diagramme de classes en uml. Le pim
donne une sémantique aux classes à l’aide de stéréotypes selon le méta-modèle mda et les
profils uml.
PSM
Le psm, pour Platform Specific Model, est, quant à lui, un modèle dépendant de la
plate-forme technique. Ce type de modèle sert essentiellement de base à la génération de
code exécutable.
Ce modèle, produit à partir d’une transformation du pim, est un modèle du même
système que le pim mais spécifié par rapport à la plate-forme. Il décrit aussi comment ce
système utilisera la plate-forme choisie.
Un psm peut fournir plus ou moins de détails selon son but. Un psm peut être une implémentation, s’il fournit toutes les informations utiles pour construire le système. D’autre
part, un psm peut ressembler à un pim pour définir un niveau d’abstraction intermédiaire
entre le pim et le psm d’implémentation.
Xavier Moghrabi
10
Fig. 1.3 – Exemple d’utilisation des modèles du mda pour réaliser une application
Un psm d’implémentation fournit un large éventail d’informations tels que le code du
programme, les types pour l’implémentation, les programmes liés et les spécifications, les
descripteurs de déploiement, et d’autres formats de spécification.
PDM
Ce modèle est désigné par l’acronyme pdm pour Plateform Description Model. Il correspond à un modèle de transformation du pim vers un psm d’implémentation. L’architecte
doit choisir une ou plusieurs plate-formes pour l’implémentation du système avec les qualités architecturales désirées.
Ce modèle propre à la plate-forme est utile pour la transformation du pim en psm. La
démarche mda est ainsi basée sur le détail des modèles dépendant de la plate-forme. Il
représente les particularités de chaque plate-forme. Il devrait être fourni par le créateur de
la plate-forme.
La figure 1.3, de la page 11, représente un ordre d’intervention de ces modèles dans la
création d’une application. L’annexe A organise et structure tous ces modèles grâce à une
”Architecture à quatre niveaux” définie par l’omg.
1.3.2
La transformation des modèles
Le mappage est utilisé pour les transformations suivantes [11].
Xavier Moghrabi
11
PIM vers PIM
Ces transformations interviennent quand un modèle est agrandi, réduit ou spécialisé
pendant le cycle de développement sans aucune information dépendante de la plate-forme.
Le fait de masquer quelques éléments afin de s’abstraire de détails fonctionnels est typiquement une transformation pim vers pim. Un des mappages les plus évidents est la transformation du modèle d’analyse à celui de conception. Ces mappages sont généralement
reliés à un affinage du modèle. Ces transformations ne sont pas toujours automatisables.
PIM vers PSM
Ces transformations s’effectuent quand le pim est suffisamment défini pour être transposé dans l’infrastructure d’exécution. La projection est basée sur les caractéristiques de
la plate-forme technique. La description des caractéristiques doit être réalisée par le pdm
(et éventuellement un profil pour décrire les concepts de la plate-forme). La transposition
d’un modèle de composants logiques à un modèle de composants existants (tels que les ejb
du framework j2ee ou CCM de Corba) est un mappage de pim vers psm. L’opération
consiste à ajouter des informations propres à la plate-forme technique. Ces transformations
ont donc pour but d’être fortement automatisées.
PSM vers PSM
Ces transformations sont utilisées lors des phases de déploiement, d’optimisation ou de
reconfiguration. Une fois empaquetés, l’intégration des composants peut être réalisée en
spécifiant l’initialisation des données, les machines cibles, la génération du conteneur et la
configuration. . . Ces mappages sont généralement dus à un affinage du modèle.
PSM vers PIM
Ces transformations s’effectuent pour construire un modèle d’abstraction pim à partir
d’un système existant dépendant d’une plate-forme. Cette procédure correspond ainsi à
du reverse engineering. Elle est assez difficile à réaliser et est difficilement entièrement
automatisable. Cette transformation est pourtant nécessaire pour toute migration d’un
système existant vers l’approche mda.
1.3.3
Les profils UML
Les profils uml jouent un rôle important dans le mda du fait des mappages entre modèles. Pour implémenter le mappage, le mécanisme a besoin de connaı̂tre les méta-modèles
d’entrée, ceux de sortie et les règles de mappage. Les règles de transformation peuvent
être réalisées à l’intérieur des outils uml (par exemple en utilisant un système de script)
ou par des outils externes (par exemple en travaillant sur des fichiers xmi).
La figure 1.4, page 13, pré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 définir un système d’information d’entreprise à base de composants distribués. C’est grâce à ce profil que les composants d’entreprise doivent être définis. D’autres
profils sont en cours de définition. Le profil Enterprise Application Integration - EAI permettra de concevoir des systèmes fortement couplés. Le profil permet de représenter les
communications asynchrones et les envois de messages, quelque soit la plate-forme (pim).
Le profil Scheduling - SCH servira à l’ordonnancement. Il est typiquement utilisé pour la
Xavier Moghrabi
12
Fig. 1.4 – Un exemple de méta-modèle en mda
modélisation des applications temps réels, quelque soit la plate-forme (pim).
Une architecture à base de composants est décrite en utilisant le profil EDOC sur la
figure 1.4, de la page 13. Ce profil spécifie également les règles de mappages standards entre
EDOC et les modèles de composants standards comme les ejb. Le mappage de EDOC à
ejb n’est pas un profil en lui-même, mais peut être associé à la notion de profil car on
connaı̂t les modèle et méta-modèle d’entrée et de sortie. Les règles et techniques standards
de spécification pour aller d’un modèle à un autre sont ainsi définies.
Actuellement, un effort important est à fournir pour transformer complètement le pim
vers un psm. Nous pouvons espérer que l’intégralité de cette phase sera automatisée dans
les années à venir (2008) [13].
1.4
Qu’attendre de l’approche MDA ?
Cette approche constitue un pas majeur dans le domaine du génie logiciel. Le principal
intérêt des chefs d’entreprise est de savoir la valeur ajoutée apportée par le mda.
1.4.1
Les forces
Une multitude d’avantages est attendue par les entreprises et les organisations de standardisation qui travaillent sur le mda. Dans les paragraphes suivants, nous en illustrerons
trois.
Xavier Moghrabi
13
Des systèmes interopérables favorisant l’hétérogénéité des plate-formes
Aujourd’hui, les groupes industriels essayent de créer des systèmes d’information ou
d’autres applications informatiques sur une seule plate-forme particulière. Bien que beaucoup d’industriels possèdent un middleware dominant leur système informatique, chez
aucun d’entre eux une unique plate-forme ne peut gérer l’ensemble de l’interopérabilité du
réseau.
Ainsi, dans le but d’accroı̂tre leur cible, les éditeurs de logiciels peuvent rendre rapidement disponible leurs produits pour différentes plate-formes et en développant l’interopérabilité avec les systèmes existants grâce à la démarche de mda.
De plus, comme le mda prévoit des passerelles favorisant l’interopérabilité d’une plateforme à une autre, les industries peuvent combiner plus facilement des systèmes hétérogènes. Cela permettra à toutes les entreprises d’utiliser des standards pour à la fois les
transactions internes ou interentreprises [14].
Le choix de la plate-forme technique la mieux adaptée
Les logiciels du marché sont le plus souvent destinés à une plate-forme technique donnée. L’utilisateur doit ainsi se soumettre à cette contrainte ou refuser d’utiliser le logiciel.
Les éditeurs adoptant le mda pourraient proposer à leurs clients ce choix. Par exemple,
des logiciels de conception et réalisation assistées par ordinateur (CAD/CAM : Computer
Aided Design/Manufacturing) et de gestion des données produits (PDM : Product Data
Management) nécessitent un couplage fort. L’utilisateur décide qu’ils fonctionneront sur
Corba, la plate-forme pour laquelle ils ont déjà été conçus.
De l’autre côté, il souhaite ajouter une application qui concerne l’ensemble de l’entreprise, la gestion de la chaı̂ne logistique (SCM : Supply Chain Management). Il choisit
de l’implémenter en services web pour l’avantage de cette technologie en terme d’interopérabilité avec des applications externes. En effet, cette plate-forme fournit la possibilité
d’intégrer cette application dans d’autres. En utilisant le mda, un tel environnement ne
pose pas de problèmes à être implémenté et déployé. En fait, beaucoup d’industries auront
besoin d’exposer une partie de leurs applications à des partenaires extérieurs qui ne possèdent pas le même système informatique. Les services web représentent une technologie
intéressante sur ce point et le mda fournira l’architecture qui convient [14].
Un développement plus rapide et des logiciels de meilleure qualité
Le modèle pim du mda spécifie seulement les fonctionnalités métier et le comportement
de l’application, sans se soucier de l’aspect spécifique à la plate-forme. En travaillant dans
cette optique, les architectes et les concepteurs peuvent se focaliser exclusivement sur le
détail de la logique métier. Ils travailleront le modèle jusqu’à obtenir exactement ce qui est
spécifié dans le cahier des charges. Ils mettront ainsi une charge de travail conséquente sur
la production de ce modèle car il est à la base de la génération des modèles spécifiques à la
plate-forme technique. Si un aspect de l’implémentation ne fonctionne pas correctement, il
est facile de savoir s’il s’agit d’une erreur comportementale sur le modèle métier ou d’une
faute dans le code.
De plus, l’approche de l’omg vise automatiser la production de code à partir des
Xavier Moghrabi
14
modèles psm. Le processus de développement est accéléré par l’utilisation d’outils. Ces
derniers permettent de réaliser automatiquement les mappages du pim vers le psm, laissant
aux concepteurs le soin de s’attacher sur les détails. Ensuite, ils permettent de générer
automatiquement le code à partir du psm. La migration vers une autre technologie est
ainsi plus aisée et rapide [14].
1.4.2
les faiblesses
Bien que cette approche soit intéressante, il existe plusieurs défis potentiels auxquels
l’omg devra s’attaquer. L’utilisateur actuel du mda doit en être conscient.
La question sur les outils
L’idée de mda est de générer (presque) automatiquement les modèles psm depuis les
pim. Toutefois, ceci ne pourrait être possible seulement pour quelques rares environnements
techniques. Le problè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 technologie risque de changer. De plus, la démarche mda devrait être adaptée à 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 acquérrait un outil mda se
limiterait à travailler sur les plate-formes supportées. Il ne serait pas possible d’intégrer
des plate-formes hétérogènes.
Chaque éditeur d’outil respectera le mda à sa propre manière à l’instar des outils
Corba. La norme Corba est très complète pour bâtir une architecture distribuée, toutefois beaucoup d’outils supportant Corba n’étaient pas aussi complets et les éditeurs implémentaient leur propre version de la norme. Le résultat était que différents orb Corba
fonctionnaient mal ensemble. Ainsi le même scénario peut se répéter avec les outils mda.
Les outils seront hétérogènes et le passage d’un modèle d’un outil à un autre pourrait être
délicat malgré l’utilisation de xmi. Ce type de problème est d’ailleurs souvent favorisé par
le leader du marché. Dans le passé, de nombreuses stratégies d’intégration d’outils ont
échoué lamentablement, pourquoi en serait-il différent avec le mda [15] ?
Le MDA est trop compliqué
Une hypothèse fondamentale de la démarche mda est que les développeurs aient des
compétences significatives en modélisation. Toutefois cette vision idéaliste reste loin de la
réalité. La plupart des développeurs créent rarement et difficilement des diagrammes uml.
Ils ne savent pas forcément ce que représentent les neuf diagrammes d’uml [15].
La difficulté d’une approche par modèles ne permettra qu’à un faible pourcentage
des développeurs d’avoir les compétences pour modéliser complètement des systèmes. Le
mda nécessite l’implication de professionnels de la modélisation. Ces personnes sont rares
dans les petites structures ou chez les industriels. Cette limitation risque de définir le
mda comme une approche destinée aux gros projets. Cette remarque peut faire penser à
l’évolution de Corba, une norme complète pour bâtir des systèmes distribués. Toutefois
cette norme est très compliquée à mettre en œuvre et la répartition des implémentations
Corba diminue au profit de technologies plus simples tels que .net ou j2ee.
Xavier Moghrabi
15
La distinction des modèles
Le mda distingue les objets liés à la plate-forme de ceux qui en sont indépendants.
Ce concept d’indépendance de la plate-forme reste aujourd’hui un objectif plus qu’une
définition opérationnelle. Derrière cette notion se cache une réalité complexe. On est en
droit de se poser la question où se trouve la limite entre les modèles ? L’omg n’a pas défini
le terme plate-forme qui n’est pas seulement un middleware. La limite entre les modèles
pim/psm n’est pas franche tant que l’ensemble des termes n’est pas spécifié.
Pour le moment, on précise la notion de pim en disant que ce n’est pas un psm. La notion
de pdm pour Platform Description Model (modèle de description de la plate-forme) aide à
affiner cette définition. Des propositions comme le cim sont apparues mais l’objectif reste
d’identifier ce qui est stable au travers de différentes mises en oeuvres si la logique métier
est conservée [20]. L’avancée du mda ne permet pas à n’importe qui de l’appliquer. Son
utilisation reste encore au stade expérimental et est réalisée par le monde de la recherche
ou par les sociétés impliquées dans la définition de cette norme.
1.5
Les standards de l’OMG utilisés
L’omg a défini plusieurs standards pour le mda. Ci-après nous dressons une liste des
plus importants, attachés d’une note explicative [11].
1.5.1
MOF : Meta Object Facility
Le mof définit la structure de tous les méta-modèles comme uml, cwm et SPEM.
L’intérêt principal du mof est surtout qu’il permet la définition d’opérations globales non
spécifiques applicables à tous les méta-modèles. L’exemple le plus significatif est xmi qui
propose l’échange de modèles quel que soit leur méta-modèle ou ocl qui permet de compléter des éléments arbitraires des modèles avec des assertions logiques. Un autre exemple
est la fourniture d’API définis en idl permettant la manipulation par programmation des
modèles.
1.5.2
UML : Unified Modeling Language
uml est devenu le standard de modélisation des logiciels à objets. Il permet la modélisation d’architectures, de structure d’objets, d’interactions entre ces objets, de données, de
composants, de framework,. . . Le mda préconise l’utilisation d’uml pour l’élaboration
des modèles. À l’heure actuelle, la version 2.0 est sortie et validée. Cette version contient
entre autre une évolution du langage d’expression de contrainte ocl [16], des concepts
renforcés pour les composants et s’intègrera plus facilement dans le mda grâce notamment
à un rapprochement avec le mof. Le noyau d’uml (infrastructure) et les extensions (superstructure) sont aussi redéfinis.
Un des aspects intéressants d’uml est le concept de profils. Ces derniers permettent
d’adapter uml à un domaine qui était souvent mal couvert. Comme uml est un formalisme, les profils représentent alors des dialectes de ce langage. Ces dialectes sont fortement
utilisés dans le mda. Par exemple le profil ejb permet l’élaboration de psm pour la plateforme ejb. À l’heure actuelle l’omg dé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 réel,
Xavier Moghrabi
16
un profil pour Corba et un profil pour ejb. Ces deux derniers profils permettront d’automatiser la transformation du pim en psm de la plate-forme respective.
Enfin, la dernière partie d’uml 2.0 correspond à la séparation du contenu logique de
la présentation physique. Ce problème assez important est ainsi résolu en fournissant un
méta- modèle séparé de pré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 entrepôts de données. Il couvre toutes
les étapes nécessaires à l’élaboration, à la création et à la transformation des entrepôts de
données. L’approche préconisée par ce standard pour la migration est une approche mda.
C’est-à-dire la création de modèles et leurs transformations. cwm définit les méta-modèles
des principaux types d’entrepôts de données (Relationnel, Objet, xml,. . .) et propose des
rè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 modèles et le
monde xml. xmi se base sur le mof. Il permet la génération de dtd et de schémas xml
à partir de méta-modèles. L’application la plus connue de xmi est celle qui a permis la
construction de la dtd uml. Cette dernière permet la représentation des modèles uml sous
forme de documents xml et assure ainsi les échanges de modèles uml entre les différents
outils du marché. Le standard xmi de sérialisation des modèles compatibles avec mof est
en cours de stabilisation et son utilisation devient incontournable dans les outils industriels.
Le mda propose une démarche privilégiant plus les modèles et méta-modèles de haut
niveau d’abstration que le codage de l’application et est ainsi plus pérenne. Il dispose d’un
certain nombre d’avantages comme l’automatisation des transformations de modèles et de
génération de code accélère le développement logiciel.
Xavier Moghrabi
17
Chapitre 2
L’utilisation du MDA
Le développement mda se focalise d’abord sur les fonctionnalités et le comportement
d’une application ou d’un système distribué, sans se préoccuper de la technologie sur laquelle le logiciel sera implémenté. Ainsi il n’est pas nécessaire de recommencer la modélisation des fonctionnalités et du comportement du système chaque fois qu’une nouvelle
technologie est adoptée. Les autres approches lient généralement les architectures à une
technologie particulière.
2.1
L’approche MDA est-elle adaptée à la réalisation d’un
ERP
Cette partie montrera que l’approche mda n’est pas destinée à un domaine particulier
de l’industrie logicielle mais transversale à l’ensemble de cette industrie. Nous essayerons
de montrer ce qu’apporterait le mda pour le développement et l’intégration d’un erp.
2.1.1
Le MDA peut s’appliquer à l’ensemble de l’industrie logicielle
Le mda semble destiné à une large partie de l’industrie logicielle. Toutefois, il se montre
naturellement efficace pour les applications dont les fonctionnalités et comportements métiers sont primordiaux et pour les éditeurs qui souhaitent développer leurs produits pour
différentes plate-formes. Ainsi les éditeurs de logiciel de gestion ont tout intérêt à prendre
conscience de l’approche mda.
Le fait que le mda soit défini par le consortium de l’omg est un gage de qualité qui
permettra de réaliser un standard neutre des outils et des entreprises. Les groupes Domain
Task Forces - dtf de l’omg ont pour but de standardiser les modèles de domaines. L’objectif est de spécifier des architectures communes à des catégories particulières d’applications.
En effet, les applications d’un même domaine d’activité (par exemple : la comptabilité, le
commerce électronique, les banques, etc.) ont des caractéristiques communes. La factorisation de celles-ci aboutirait à des architectures pré-cablées. On évite ainsi aux développeurs
de travailler “from scratch” (autrement dit à partir de zéro) et de réinventer à chaque fois
la roue.
Depuis 1996, une partie des membres de l’omg se rencontre dans ces communautés
pour standardiser les services et les mécanismes spécifiques à un marché vertical. Jusqu’en
2000, ces spécifications consistaient à écrire des interfaces pour Corba accompagnées d’une
sémantique. Un service ou un mécanisme bien conçu est toujours basé sur un modèle de
Xavier Moghrabi
18
Fig. 2.1 – Modèles uml de framewroks pour des mécanismes verticaux
sémantique indépendant de la plate-forme cible.
Aujourd’hui l’omg dispose de 10 dtf. Des modèles pour les domaines suivants sont en
cours de réalisation : le transport, l’espace, la production, la finance, le commerce électronique, les télécommunications, la santé. . . Ces groupes produisent des framework pour
standardiser des fonctionnalités pour un domaine d’application. Par exemple, le dtf Finance standard pour un mécanisme de comptes doit contenir un model uml pim et des
modèles uml psm (un modèle spécifique Corba avec des interfaces idl, un modèle spécifique Java avec des interfaces Java). Des dtd xml ou des schémas générés via xmi peuvent
être inclus pour les règles de mappage. Tous ces artefacts sont normalisés. Comme un standard doit avoir un impact large, le pim est utile même pour construire des applications
utilisant un environnement middleware autre que ceux des modèles psm fournis.
Un autre exemple, le dtf production crée des modèles uml normalisés, des interfaces idl, des interfaces Java, des dtd xml . . . pour l’intéropérabilité entre les logiciels
de conception et réalisation assistées par ordinateur (CAD/CAM), la gestion des données
produits (PDM) et un mécanisme d’intégration de la chaı̂ne logistique (Supply Chain).
Une fois les modèles mda complétés et adoptés, leur implémentation peut être partiellement automatisée pour les plate-formes middleware supportées par le mda.
Ces trois mécanismes cités pour cet exemple, de la figure 2.1 à la page 19, démontre
un avantage que fournit le mda. Les deux premières (CAD/CAM et PDM) applications
sont fortement intégrées et seront implémentées par des entreprises individuelles ou des
éditeurs de logiciels en Corba ou ejb. La chaı̂ne logistique est un mécanisme interentreprises qui peut être préférable d’implémenter avec les services web (xml sur SOAP). Il
est ainsi essentiel qu’il existe une interopérabilité entre ces trois applications. En utilisant
le mda, il sera possible de générer une partie significative de l’implémentation pour chaque
plate-forme mais aussi les passerelles permettant à chaque application d’être interopérable
avec les deux autres [5].
Ces modèles de services et de mécanismes normalisés pour des marchés verticaux
montrent que le mda pourra s’appliquer assez facilement à un large éventail de d’activités. Pour concevoir un erp, il est utile d’utiliser les modèles standards qui seront fournis
par l’omg pour les domaines intéressés (production, finance, commerce électronique. . .).
Xavier Moghrabi
19
2.1.2
Le MDA demande des moyens adaptés
Des compétences
L’adoption du mda demande aux entreprises de réorganiser leurs ressources en privilégiant bien entendu les phases de modélisation. L’architecture mda favorise une répartition
des tâches au sein du projet selon les compétences disponibles. Chacun des acteurs travaillant avec le mda doit obligatoirement savoir modéliser en utilisant le formalisme uml.
Dans les entreprises, les nombreux développeurs connaissent et comprennent le diagramme
de classes. Toutefois, ils ne savent pas vraiment les concevoir et connaissent encore moins
les autres diagrammes uml. L’approche mda vise à automatiser la génération de code pour
cette raison la charge de programmation est diminuée.
Cette montée en abstraction privilégie les analystes métiers pour concevoir les modèles
métiers cim et les architectes fonctionnels pour les modèles de conception pim. Les spécialistes techniques (architectes, concepteur de base de données, concepteurs. . .) restent
encore indispensables car les transformations de modèle sont loin d’être entièrement automatisées. Cette montée en abstraction oblige les entreprises à maı̂triser les modèles et les
architectures pour améliorer la conception, le développement et l’implémentation.
Des outils
Depuis le début, nous faisons allusion à des outils pour faciliter l’approche mda. Le
principal intérêt de ces outils est la transformation des modèles (pim vers psm principalement) et la génération du code. Ces produits doivent automatiser au maximum les étapes
de transformation.
L’adoption du mda par l’industrie logicielle se fera une fois la démarche complètement
normalisée et quand des outils performants verront le jour. Sur le site de l’omg, le visiteur peut s’apercevoir qu’il existe un peu moins d’une trentaine d’outils “mda compliant”.
Parmi eux, on retrouve un grand nombre de générateurs de code à partir de modèles tels
que XDE d’IBM Rational ou Codagen de Codagen Technologies. . .. D’autres éditeurs s’attaquent à une démarche plus globale à l’instar d’Objecteering de Softeam, de
Model-In-Action de SodiFrance ou encore d’OptimalJ de Compuware [17]. Ces outils
ne sont qu’à une étape embryonnaire du mda, ils ne proposent pas de réaliser les transformations ou générations entièrement de manière automatique. Certes, ils accélèrent le
travail des analystes et des développeurs mais un important travail reste à faire pour obtenir des produits en adéquation avec les objectifs du mda.
En effet, la norme mda n’est pas encore définie et ainsi l’omg a spécifié ses objectifs sans
présenter les moyens pour les atteindre. D’autant plus, que les termes ne sont pas spécifiés
et les mécanismes de transformation ne sont qu’au stade expérimental. Des groupes de
recherchent mènent des travaux parallèles sur des transformations en utilisant des profils
uml, des pattern ou encore des transformations de modèles uml codés en xmi par xslt.
Le mda deviendra une architecture viable, une fois que ces tranformations seront
concrétisées et intégrées dans des outils. Cette automatisation est indispensable pour atteindre les objectifs de l’architecture mda.
Un grand nombre d’entreprises utilise actuellement des outils de modélisation compatibles mda au niveau des processus métier. Cependant, la plupart d’entre elles considèrent
Xavier Moghrabi
20
toujours la modélisation comme un exercice théorique. Cela engendre un problème de synchronisation entre le modèle d’application et l’application elle-même dans la mesure où
l’application est mise à jour alors que le modèle ne l’est pas. L’architecture mda résout ce
problème en fusionnant les processus de modélisation et de codage. Néanmoins, la plupart
des transformations pim en psm et psm en code s’effectuent, pour l’instant, en partie manuellement.
La standardisation des transformations automatiques au sein d’une structure mda est
actuellement assurée par certains des principaux membres de l’omg, tels que Compuware
et Sun Microsystems.
Les pattern pourraient constituer la clé de l’automatisation des transformations entre
les modèles. Ils garantissent que l’application incorpore les meilleures pratiques, les normes
et les directives de façon cohérente et fiable, ce qui optimise la qualité et réduit les risques.
On distingue deux catégories générales de patterns :
– les pattern technologiques qui transforment un pim en un psm,
– les pattern de mise en œuvre qui transforment le psm en un code réel en implémentant la spécification.
Avant de choisir un jeu d’outils compatible mda, il incombe à l’utilisateur final de
déterminer globalement, et non élément par élément, le niveau de conformité de l’organisation avec l’architecture mda. Il doit, en particulier, rechercher les organisations qui
recourent à une solution basée sur des patterns pour automatiser les transformations entre
les modèles. Le développement fondé sur des pattern constitue, pour l’instant, la meilleure
méthode d’automatisation des transformations, un élément fondamental de l’implémentation complète de l’architecture mda, et le seul moyen de tirer pleinement partie des
avantages de celle-ci.
Toutefois, d’autres types de transformation sont en cours d’élaboration. Nous avons
mentionné auparavant les profils uml dont certains devraient être utilisés pour cette automatisation (profils Corba, ejb, .net, services web . . .). Toutefois, les partisans d’xml
ont émis l’idée de transformer automatiquement un modèle uml codé en xmi par l’intermédiaire d’un transformateur xslt. Le travail sur les transformations vient à peine de
commencer et pour l’instant le mda ne dispose d’aucune méthode pour y répondre. La
définition des méthodes de transformation figurera dans la norme mda qui n’est toujours
pas établie.
Le projet MoDAthèque
Par ailleurs en janvier 2003, un consortium français réunissant industriels (Thales,
France Telecom, EDF), éditeurs d’outils (Softeam, SodiFrance, Omondo, W4) et
organismes de recherche (INRIA, CEA-List, LIP6, CNAM, IMAG) a présenté le projet
MoDAthèque. Le but est de bâtir une plate-forme mda libre qui puisse résoudre les problèmes relevés [18]. Ce travail serait financé par les industriels, par les éditeurs et ,à moitié,
par le Ministère de la Recherche pour un coût estimé à 8,5 millions d’euros.
Parmi les freins à la mise en place des approches de développement, le consortium
identifie deux verrous conceptuels :
– La définition du concept de composant méthodologique mda, unité de structuration
et de déploiement des règles et techniques de modélisation, permettant la constitution
Xavier Moghrabi
21
d’une chaı̂ne méthodologique mda au-dessus des outils de modélisation.
– La capacité d’identifier et gérer le rôle de composants mda dans un processus de
développement logiciel.
À ceux-ci s’ajoutent trois verrous technologiques :
– L’interopérabilité des outils supportant le chaı̂ne méthodologique mda.
– La maı̂trise du mda.
– Le pilotage assisté des processus de développement dans le mda.
La nature de ces verrous technologiques (interopérabilité, capitalisation et orchestration) nécessite d’aborder le problème en largeur et de manière très ouverte. La forme d’un
projet commun, plutôt qu’un ensemble de projets techniques ciblés, a été préféré. En effet,
cette approche permet de garantir plus facilement la cohérence et l’interaction.
Les résultats attendus sont les suivants :
– Une plate-forme technologique assurant l’interopérabilité des outils et offrant les
concepts et mécanismes nécessaires à la constitution de chaı̂nes méthodologiques
mda.
– La complétude de la plate-forme par un ensemble d’outils couvrant les aspects d’un
développement mda.
– l’expérimentation d’approches mda qui instancient la plate-forme dans des contextes
applicatifs et méthodologiques divers.
Ce projet dont la durée est prévue à deux ans, doit permettre aux industriels de disposer
d’une plate-forme libre qui interconnectera les outils entre eux et proposera une alternative
aux logiciels de compagnies américaines très dominantes. La démarche pourra également
crédibiliser l’approche mda en général.
2.1.3
Le MDA répond aux besoins de création et d’intégration des ERP
Le mda semble parfaitement bien adapté pour produire un erp. Cette approche peut
être utile à la fois pour la réalisation du progiciel et pour son intégration dans le système d’information de l’entreprise. En effet, pour la conception du progiciel la phase de
modélisation se montre indispensable pour donner à l’équipe de travail toutes les chances
de créer un produit de qualité et répondant aux besoins exigés. Le mda peut faciliter
cette approche puisqu’un progiciel de gestion d’entreprise comprend une logique métier
très forte. En effet, le mda préconise la séparation de la modélisation métier de la modélisation de l’implémentation du système. Le mappage d’un modèle à l’autre permettra
d’économiser du temps pour réduire les coûts de développement et favoriser l’analyse et
la modélisation. Les profils uml déterminés par les dtf peuvent apporter un avantage
quant à la standardisation des règles métier. Comme nous l’avons vu précédemment, il est
prévu de créer des profils pour les domaines de la production, finance, du commerce électronique. . . qui seraient intéressants de mettre en œuvre pour la réalisation d’un erp complet.
Le mappage automatique d’un pim vers des psm spécifiques à chaque plate-forme d’implémentation permettrait de développer un produit pour plusieurs middleware. L’entreprise pourra ainsi fournir différentes versions du produit selon le choix du middleware
par le client. Habituellement, un système de gestion d’entreprise fonctionne sur un nombre
très limité de plate-formes. Si le client dispose déjà d’un système informatique à base de
Xavier Moghrabi
22
middleware, il souhaiterait sûrement utiliser sa plateforme, qu’il maı̂trise, pour son erp.
Une société éditant un erp pour plusieurs plate-formes élargit par ailleurs sa cible de marché. De plus, la méthodologie mda disposera de moyens pour rendre interopérable l’erp
avec des systèmes d’information développés sur d’autres plate-formes. En effet, le mda
prévoit de générer une solution aux collaborations entre les middleware. Cette fonctionnalité permettra de répondre aux problèmes techniques d’interopérabilité entre erp. De
plus, une entreprise qui souhaite utiliser des produits modulables provenant de différents
éditeurs pourra plus facilement les intégrer.
La transformation de pim en pim évoquée dans le premier chapitre pourrait être utile
pour adapter un modèle générique aux besoins métiers spécifiques d’une entreprise. Cette
approche permettrait, à partir d’une solution logicielle générique, d’établir le système d’information spécifique à une entreprise.
La mda propose des avantages pour la construction et l’intégration de l’erp au sein du
système d’information de l’entreprise. L’approche mda permet d’ouvrir le progiciel vers
des systèmes extérieurs.
2.2
La méthode de développement
Le mda ne décrit pas une méthodologie de développement logiciel ou de suivi d’exploitation. Pour qu’il soit applicable, il lui faut une méthode qui puisse lui être couplée.
2.2.1
La MDA face aux méthodes agiles
Philippe Saint Martin montre le décalage entre une des méthodes “agiles”, l’eXtrem
Programming (XP) et l’approche mda [19]. L’examen plus poussé des caractéristiques de
cette famille de méthodes incite à la circonspection. La frénésie entourant les projets de
la nouvelle économie a fait le lit de l’XP et de ses consœurs. Le raz-de-marée du Web a
triomphé des dernières réticences méthodologiques, faisant allègrement sauter les verrous
de la sûreté de développement logiciel. Une fois cette tendance aseptisée, le concept s’est
avéré fertile que sur une minorité de projets.
L’XP est d’une efficacité remarquable pour autant que le projet présente un ensemble
spécifique de facteurs de réussite, aisément réunis sur les projets à faibles contraintes
contractuelles et de taille raisonnable, beaucoup plus difficilement sur les autres. La première génération des applications Internet respectaient ce cahier des charges. Les applications Web, cantonnées au rôle de vitrine commerciale, ne nécessitaient pas le recours à une
méthodologie stricte, d’autant plus que les utilisateurs pouvaient difficilement établir des
besoins précis. Aujourd’hui, les utilisateurs ont pris la mesure du phénomène et réclament
l’intégration du système d’information dans les projets. Ces nouvelles ambitions affichées
par les donneurs d’ordre, bouleversent profondément la nature des projets, invalidant ainsi
la pertinence du recours aux méthodes agiles.
Mais faisons abstraction des conditions optimales requises sur les projets agiles et poussons plus avant l’examen des fondements théoriques sur lesquels s’appuient ces méthodes.
Nous ne pouvons alors nous empêcher d’éprouver une pointe de scepticisme. En fait d’agilité, elles requièrent de véritables talents d’acrobates de la part d’un développeur. À l’aise,
aussi bien dans le recueil des besoins, que dans la modélisation conceptuelle, ou encore
Xavier Moghrabi
23
dans la maı̂trise des dernières technologies à la mode et des nombreux outils y afférents, le
programmeur allie qualités communicationnelles avec esprit d’analyse et logique programmatique. Un grand écart disciplinaire qui nous fait penser que ce mouton à cinq pattes
n’est pas très largement répandu dans le landernau du Génie Logiciel. On n’est guère surpris d’apprendre que les fondements de l’XP reposent sur douze principes fondamentaux
dont certains relèvent de l’épreuve de force. En fait, on constate dans la pratique que cette
méthode requiert de la part du programmeur une agilité implicite, qui lui fait souvent
défaut à ses débuts professionnels. Ceci illustre un paradoxe ! La méthode censée suppléer
au manque d’expérience du programmeur exige au contraire, de sa part, une compétence
pré-requise. D’ailleurs, les mieux armés pour le maniement de ces méthodes sont d’ailleurs
les anciens utilisateurs des méthodes traditionnelles.
L’XP participe d’une nouvelle génération de méthodes, plus proches des attentes du
développeur, ce qui la rend plus productive. Le succès d’une telle entreprise implique une
confiance aveugle dans le professionnalisme des développeurs et dans leurs réelles motivations à appliquer les principes de l’agile. Tout repose sur les capacités des programmeurs
à s’imprégner de la démarche. On attend qu’ils programment simplement, efficacement,
proprement, en duo et produisent la documentation qu’ils jugent suffisante. Ils ne doivent
pas hésiter pas à casser le code pour l’améliorer. C’est reléguer la psychologie comportementale au second plan et oublier un peu la rétivité naturelle dont nous faisons tous
preuve, à l’idée de modifier du code qui fonctionne.
Cette position prend le contre-pied des intentions originelles du Génie Logiciel pour
qui l’activité de développement devait être cadrée et canalisée. Plus grave, que dire de
l’approche mda dans un tel cadre organisationnel ? Comment espérer l’émergence d’un
consensus de règles de transformation dans un tel contexte ? Le programmeur, livré à luimême, ne sera pas enclin naturellement à produire les pim sur lesquels repose toute la mise
en œuvre des processus de transformation. En laissant un large champ de manœuvre aux
développeurs, ne risque-t-on pas de retomber dans les travers de l’informatique des années
1970 ?
Il se dégage de cette analyse que les méthodes agiles, trouvent un terrain d’expression
favorable dans une frange limitée de projets informatiques : les projets à taille raisonnable,
soumis à des conditions idylliques de coopération entre utilisateurs et développeurs. Dans
tout autre contexte, comme celui du forfait par exemple, l’application scrupuleuse des
principes de l’agile serait illusoire et aboutirait à un échec retentissant. Dans des conditions de projets extrêmes, la dénomination de méthodes “fragiles” semble mieux convenir
à cette catégorie de démarches. Toutefois, certains principes exposés par ces méthodes
restent pertinents, pour peu qu’ils soient intégrés à une approche plus globale telle qu’une
implémentation de l’Unified Process - UP.
2.2.2
La révision du cycle en Y
La proposition mda donne l’occasion de revisiter le cycle en Y de développement, dans
un contexte plus normatif. C’est un corollaire des objectifs du mda. C’est l’aboutissement
des promesses faites lors de l’arrivée des technologies orientées objet où l’on avait annoncé
la mutation du travail de l’ingénieur informaticien vers un travail d’assemblage de deux
types d’entités :
– les composants métiers issus d’une analyse neutre du domaine et
Xavier Moghrabi
24
Fig. 2.2 – Le cycle Y dans le mda
– les composants plate-formes issus de la technologie informatique de mise en œuvre.
Le fait que ces deux types de composants puissent être modélisés par le même formalisme (uml) et implémentés dans le même langage de programmation (Java par exemple)
facilite leur séparation puis leur assemblage. L’existence d’une base de composants réutilisables et validés, pour la plate-forme aussi bien que pour le domaine, est maintenant
bien acceptée. Le principe du cycle en Y s’est lui-même progressivement imposé, séparant
les spécifications fonctionnelles de l’architecture logicielle et applicative. Valtech a créé à
partir du cycle en Y la méthode 2 Track UP.
Le pari de l’omg avec le mda consiste à dire que le cap de l’intuition dans le déploiement du cycle en Y est maintenant en cours d’être dépassé et que l’on est en mesure de
commencer à penser à l’automatisation. Les problèmes de formalismes étant à peu près
maı̂trisés avec les méta-modèles et les profils. Il est maintenant envisageable des automatisations partielles de la synthèse des deux branches du Y. L’expérience acquise, avec la
culture des design pattern, doit pouvoir commencer à alimenter les outils industriels. La
figure 2.2, de la page 25, illustre le cycle en Y dans le mda.
Les modèles cim et pim se situent sur la branche de gauche qui constitue la logique
métier et l’implémentation fonctionnelle de cette logique. La branche de droite est propre
à la plate-forme cible. Elle correspond au pdm. En fait, ce modèle sert à décrire les caractéristiques de la technologie utilisée. Ce modèle devrait être fournit par le créateur de la
plate-forme. Le professeur Bézivin [20] a identifié un modèle qu’il a nommé DDM pour
Design Decision Model correspond plus à un modèle intermédiaire construit à partir d’une
opération de mélange des modèles pim de pdm. Le passage du DDM au psm serait alors
une étape de configuration et finition. De ce modèle, le code d’implémentation est généré.
Même si les trois branches du Y sont parsemées de modèles basés sur des méta-modèles
sémantiquement très précis, elles doivent être encore étudiées pour que l’on puisse annoncer
une avancée des pratiques industrielles. Cependant, il est fort souhaitable de remarquer
que l’initiative ne se situe pas en rupture avec les pratiques de production logicielle. Elle
constitue une évolution en continuité et en consolidation.
Xavier Moghrabi
25
Fig. 2.3 – Le cycle de vie de l’EUP
2.2.3
Une nouvelle implémentation du processus unifié : EUP
L’EUP, pour Enterprise Unified Process, (Ambler 2001) est une instanciation de l’UP
(Jacobson, Booch et Rumbaugh 1999), à l’instat du RUP, Rational UP, (Kruchten
2000). Comme on peut le voir sur la figure 2.3, de la page 26, représentant les phases
de l’EUP, il n’est qu’une extension du RUP. Ce dernier se focalise sur le processus de
développement logiciel alors que l’EUP inclut une phase de production pendant laquelle
l’application fonctionne et est suivie par la maintenance. Plus important encore, l’EUP
inclut une discipline de gestion de l’infrastructure qui comprend des activités transversales
telle que la gestion de la réutilisation, la gestion de programme, la gestion du processus
logiciel et l’architecture de l’entreprise pour n’en citer que quelques-uns. En rétrospection,
un nom qui convient plus à cette discipline est la gestion de l’entreprise.
La plus importante force de l’EUP est qu’il apporte explicitement les thèmes de l’architecture d’entreprise et de l’administration d’entreprise au RUP. Ceci est important car
le RUP est le plus populaire et rigoureux processus logiciel de l’industrie des technologies
de l’information. Ainsi l’EUP a un potentiel d’impact fort dans cette industrie. Il montre
comment inclure des problèmes d’entreprise dans les activités de développement logiciel,
un sujet sur lequel beaucoup d’organisations travaillent [15].
Toutefois, il faut émettre quelques réserves concernant l’EUP. Cette méthode dérivée
de l’UP est largement moins répandue que le RUP et manque de soutien de la part de
l’industrie logicielle. Bien que le RUP a gagné une reconnaissance suffisante de l’industrie,
l’EUP doit encore séduire. Cela est dû à plusieurs raisons. Tout d’abord, l’entreprise IBM
Rational ne soutient pas l’EUP car ne le considère pas comme une extension valide. La
société le ferait peut-être un jour en développement des extensions avec ses outils. Ensuite,
de nombreuses organisations sont en train de lutter pour réussir le développement de systèmes uniques. Elles ne souhaitent pas s’attaquer aux problèmes au niveau de l’entreprise
mais se limitent au système.
Xavier Moghrabi
26
L’EUP est typiquement instancié comme un processus normatif et rigoureux, mais pas
comme un processus agile. Sa force est qu’il s’agit d’un processus bien défini et rigoureux.
Bien qu’il soit possible de l’adapter tel un processus agile, cette démarche est rarement réalisée en pratique avec le RUP. Les organisations qui s’intéressent aux processus rigoureux
tendent vers l’adoption du RUP. Celles qui sont intéréssées pour être agiles tendent vers
les processus agiles tels que XP, FDD (Feature-Driven Developpement) ou encore DSDM
(Dynamic System Development Method). En conséquence, comme l’EUP est une extension du RUP, il est très probable qu’il soit également instancié d’une manière normative.
Cela aboutit sur un processus doté d’une lourde documentation qui ne correspond pas bien
aux efforts des entreprises pour bâtir une architecture agile. Une instanciation de l’EUP
de manière agile pourrait résoudre ce problème.
L’EUP est plus adapté pour adopter une démarche mda du fait de la présence des
phases d’exploitation et de retrait. En fait, ces phases permettent de gérer l’ensemble du
cycle de vie d’une application. Le mda est une approche qui consiste à fournir un modèle
métier pérenne ainsi qu’un modèle technique dont l’espérance d’exploitation dépend de la
technologie sous-jacente. Pour un même modèle métier, plusieurs modèles techniques sont
réalisés selon l’avancée des technologies. De ce fait, un travail est demandé en exploitation
sur la plupart des disciplines hormis la modélisation métier afin d’accompagner l’évolution
des technologies.
2.3
Détail d’un système d’information utilisant la philosophie du MDA
Sur le site de l’omg, il est possible de trouver une page relatant des “success story”. L’une d’entre elle concerne le système d’information de la banque américaine Wells
Fargo. Elle est détaillée par Paul Harmon, un consultant senior d’architectures distribuées de Cutter Consortium [21].
2.3.1
Le système d’information de la banque Wells Fargo
La banque Wells Fargo a été classée par le Business Week comme la quatrième
plus grande banque des États Unis d’Amérique. Pendant ces dix dernières années, cette
banque s’est faite la réputation d’avoir une stratégie agressive du fait d’avoir acquis et intégré d’autres banques pour créer une organisation de services financiers croissante. Cette
stratégie a généré un challenge pour le système d’information de la compagnie. En effet,
chaque année le système d’information a été modifié pour incorporer les applications existantes et les bases de données des sociétés absorbées à l’architecture logicielle complexe du
groupe. Ce dernier s’est établi une réputation méritée d’être sophistiqué dans son approche
d’intégration de systèmes.
Le service informatique du groupe utilise Corba depuis une dizaine d’années et a
récolté des résultats significatifs dans son approche middleware. Récemment, il a commencé à développer une nouvelle approche architecturale pour assurer l’intégration de son
middleware avec les nouvelles technologies et approches d’intégration. L’équipe BOS
(Business Object Services) est responsable de la maintenance de tous les middleware
et des serveurs utilisés pour lier les applications aux systèmes existants et aux données.
La figure 2.4, de la page 28, montre l’architecture du système que l’équipe BOS crée et
Xavier Moghrabi
27
Fig. 2.4 – L’architecture logicielle de Wells Fargo et le rôle du BOS
maintient.
L’équipe BOS s’occupe de la partie middleware et des applications permettant de
faire le lien entre les systèmes hétérogènes et les applications clientes. Pour affronter la
complexité du système, l’équipe BOS utilise la philosophie du mda. Elle a créé un model métier unique, équivalent du pim. Il est maintenu en utilisant des outils classiques
de modélisation qui permettent aux développeurs de Wells Fargo de générer le code
d’implémentation. En maintenant ce modèle indépendamment des technologies d’une plateforme spécifique, l’équipe peut intégrer plusieurs technologies ou changer de technologie
sans impacter les modèles d’abstraction.
2.3.2
L’environnement des traitements
La figure 2.5, de la page 29, illustre la complexité physique de l’environnement métier
des traitements avec les différentes plate-formes. Un orb Corba, l’ObjectBroker de BEA,
est utilisé pour gérer les interactions entre les composants et les applications tournant sur
les différentes plate-formes.
Wells Fargo a de nombreuses applications basées sur des mainframe et de nombreuses applications clientes basées sur des environnements Windows, Linux ou Unix. La
société dispose de systèmes Unix pour les SGBD, Oracle et Informix, et un système d’intégration du téléphone. Par dessus tout, la société nécessite que tous ses systèmes soient
capables de manipuler un grand volume de processus, soient très fiables et aient des temps
de réponse très courts.
Xavier Moghrabi
28
Fig. 2.5 – L’environnement de traitement du BOS de Wells Fargo
Pour répondre à ces exigences, la banque a choisi Corba pour relier les mainframe
aux clients. L’ensemble de l’architecture du système est hétérogène. Le milieu du système
encapsule des systèmes différents et fournit un environnement distribué pour les applications clientes. Il s’agit d’un framework objet qui normalise les différents systèmes dans
un modèle d’entreprise commun. Ce modèle d’entreprise est décrit selon le mda. Il est
également exprimé en interfaces Corba pour les développeurs de l’application. Le framework est indépendant de la plate-forme, du langage et basé sur le mda et Corba.
Le modèle métier est représenté à l’aide du logiciel de modélisation Rational Rose. Ce
modèle métier objet fournit une spécification logique détaillée des composants et de la
façon dont ils interagissent, incluant les messages échangés. Wells Fargo peut générer
le code des interfaces idl pour des modèles. En d’autres mots, l’équipe BOS a fournit
des interfaces flexibles pour faire communiquer des systèmes inflexibles. Cela permet de
rapidement et facilement changer la technologie sur-jacente.
2.3.3
Le développement à base de modèles
Des applications en ligne de la société sont créées par les équipes de développement
divisées en trois groupes : le groupe client qui développe la partie Internet, le groupe BOS
et l’organisation du systèmes qui maintient les systèmes de données. Le groupe BOS contribue au modèle métier uml, qui définit les objets métiers, les interfaces et l’infrastructure
du middleware pour le projet. L’application actuelle est créée par réutilisation d’objets
définis dans l’infrastructure du BOS et, dans certains cas, par extension de ces objets.
Xavier Moghrabi
29
Fig. 2.6 – Création et maintenance de l’environnement middleware à partir du modèle
Les développeurs créent les diagrammes uml qui décrivent l’application spécifique. Ensuite, ils génèrent le code des messages en idl, qui sont utilisés pour générer l’adressage
dynamique de Corba pour la transmission de messages entre les composants.
Le travail réalisé donne un bon exemple d’une approche mda au développement logiciel.
L’équipe BOS s’est spécialisée dans la maintenance du modèle objet métier. L’équipe de
développement utilise ce modèle pour obtenir l’architecture générale pour concevoir leurs
applications. Plus tard, elle utilise le modèle de conception pour générer les messages pour
les composants qui seront utilisés. Les architectes du BOS et les développeurs dépendent
tous les deux des modèles uml pour joindre leurs efforts et communiquer avec un même
langage.
L’environnement de développement a été divisé pour supporter une approchée centrée
sur le modèle. Tout d’abord, l’équipe BOS définit le cim dénommé aussi modèle métier.
L’équipe de développement crée le pim ou modèle de conception. Duquel, est généré le
modèle d’implémentation psm. Ce dernier est utilisé pour générer le code de l’application.
Du code supplémentaire doit être incorporé pour implémenter complètement la logique
métier. La figure 2.6, de la page 30, illustre l’utilsation les modèles uml pour générer et
maintenir son environnement middleware.
Dans cet exemple, un modèle uml définit les relations entre les applications clientes, le
serveur et le support de données. Il décrit les appels et les réponses entre ces trois parties
Xavier Moghrabi
30
du système. Une fois créé ou modifié, l’outil uml génère le code pour l’utilisation dans un
environnement middleware. Depuis que la banque utilise Corba, le modèle génère du
code Corba, soit des interfaces idl et l’adressage, aussi bien que les objets utiles pour
supporter les liaisons entre les systèmes.
2.3.4
Le MDA fournit une passerelle pour le futur
Cette expérience comparable à la philosophie du mda a montré que quelques programmeurs ont résisté à cette approche. La plupart des acteurs impliqués se rendent compte
que le processus de développement est plus rapide en utilisant l’éditeur de modèle au lieu
de la faire manuellement. Le temps de programmation est significativement réduit, entre
50 et 80 %, grâce à la génération d’une partie du code par les outils.
D’un autre côté, la phase de spécification est plus longue, d’environ 20 %, puisque le
développeur est forcé d’identifier totalement et précisément tous les attributs et relations
des entités du modèle et de les définir. . . Une fois familiarisés avec l’outil, les développeurs
deviennent productifs. Un long chemin est à parcourir pour qu’ils aient le sentiment qu’il
s’agit d’un moyen naturel pour exprimer leurs idées.
Les réels bénéfices de l’approche apparaissent lorsque les équipes commencent à étendre
ou améliorer l’application. Comme l’application est une transformation du modèle, et vice
versa, cela limite les problèmes de synchronisation. Les analystes commencent les prochains
projets en utilisant les informations de la conception du précédent projet. Ils obtiennent
ainsi une description précise des fonctionnalités du système pensé par les précédents développeurs.
Parallèlement, Wells Fargo expérimente des technologies Java avancées (ejb, RMI)
et les services web. La société étude la possibilité de migrer technologiquement. Cette
option est motivée par le fait que l’environnement middleware est déjà décrit en uml
sans être lié à une plate-forme particulière et que ces technologies se répandent largement
grâce à leur facilité relative de mise en œuvre face à Corba.
Le mda rend plus accessible la migration technologique d’un système ou la construction de systèmes mélangeant plusieurs technologies. Le système des données n’est pas prêt
d’être changé et beaucoup de liaisons resteront, même si une nouvelle technologie est ajoutée. Le mda fournit, des ponts entre plusieurs technologies et assure qu’ils peuvent être
gérés par un modèle commun.
Le vice président en charge du projet BOS affirme que l’approche mda est validé par
leur direction. Il croit qu’une norme ouverte sur l’industrie comme le mda sera bénéfique à
l’ensemble des industries. Celles-ci l’adopteront fortement pour l’imposer comme un standard.
La mda paraı̂t adapter pour la construction et l’intégration de systèmes de gestion. Naturellement, il peut être utilisé pour développer un erp. Il demande toutefois l’acquisition
d’outils et la réorganisation du personnel. Le cycle en Y semble adapté mais sans soutien
d’un acteur puissant, il ne sera pas facile à utiliser. L’expérience de la Wells Fargo
montre que le mda résout des problèmes d’hétérogénéité du système d’information.
Xavier Moghrabi
31
Chapitre 3
Les perspectives de cette approche
logicielle
Ce chapitre tentera de prédire les perspectives du mda et l’engouement de l’industrie
logicielle. Pour cela, nous utiliserons une étude sur la productivité du mda face au développement traditionnel pour avoir une idée de l’ampleur du gain. Ensuite, nous déterminerons
si le mda pourra s’imposer comme un standard dans l’approche par modèles.
3.1
Étude de productivité de la démarche MDA
Cette étude vise établir la vérité sur le gain de productivité prôné par l’omg. Pour cela,
deux équipes ont développé la même application mais avec des approches divergentes.
3.1.1
Les différences entre les approches MDA et traditionnelle
Nous avons mentionné à diverses reprises que le mda génère le code d’implémentation
à partir des modèles uml. Ceci existait déjà avant le mda. L’outil Rational Rose peut, par
exemple, générer des classes Java à partir du diagramme de classes. L’avantage majeur
de l’approche mda est qu’elle se base sur une abstraction indépendante de la plate-forme
pour créer complètement le code spécifique à la plate-forme.
Plusieurs différences sont à mettre en valeur comme :
– Le mda débute sur un plus haut niveau d’abstraction que les méthodes traditionnelles. Le modèle cim est le plus haut niveau d’abstraction représentant le logique
métier et le pim, le fonctionnement des entités et des services.
– Le psm est une description complète de l’application sous la forme de méta-données.
À ce niveau, le modèle est enrichi de parties spécifiques à la technologie.
– Le code, généré à partir du psm, est proche de l’application finale. Beaucoup d’outils
génèrent du code de quelques types de modèle, mais ils ne donnent que des morceaux
de l’application. Ils sont inutilisables directement car ils ne sont pas basés sur un
méta-modèle complet.
– Les algorithmes qui transforment le pim en psm et le psm en code sont configurables
par l’architecte grâce à l’utilisation de méta-modèles.
Les organisations de l’omg pensent que cette nouvelle directive aura des retombées
bénéfiques pour l’industrie logicielle concernant :
Xavier Moghrabi
32
– l’accélération du développement logiciel : Grâce à l’automatisation des transformations et des générations de code, le travail du développeur est réduit.
– les avantages architecturaux : Le mda se focalise sur la modélisation en uml tout
au long de la chaı̂ne méthodologique. Cette démarche force à penser correctement
l’architecture et le modèle objet derrière le système. Actuellement certains développements négligent la phase de modélisation et laissent au soin des développeurs la
réalisation d’un code qui fonctionne.
– l’amélioration de la maintenabilité et de la consistance du code : En utilisant
la génération de code par l’outil, le codage est ainsi plus homogène. Lors d’un développement classique, certains développeurs utilisent des design pattern et d’autres
non. Ce point améliore la maintenance du code car les développeurs comprennent
plus facilement le code généré que celui qu’ils n’ont pas écrit. De plus, les modèles
facilitent le suivi du système.
– l’amélioration de la portabilité entre middleware : Le changement d’un middleware à un autre est facilité grâce au pim et aux outils de transformation. Ceci
est d’autant plus vrai que le mda fournira des passerelles entre les plate-formes.
L’attente des industries se situe principalement sur le premier point cité. Le mda se
focalise sur la productivité et la maintenabilité. L’omg montre que les gains attendus par
l’adoption du mda sont la réduction des coûts de fonctionnement, du temps de développement, l’augmentation du retour sur investissement et l’intégration rapide de nouvelles
technologies dans un système existant.
3.1.2
Description de l’objectif de l’étude
Pour vérifier la prétention d’accélérer le développement logiciel avec le mda, le société américaine Compuware Corporation a commissionné le cabinet de conseil The
Middleware Company pour réaliser une étude de cas. Deux équipes équivalentes ont
développé la même application. L’une a respecté une démarche mda, l’autre non. Cette
étude a été faite sérieusement et de manière objective selon les deux sociétés impliquées
[22].
Les deux entités ont choisi de développer l’application mondialement connue, “Petstore” en j2ee. Initialement réalisée par Sun Microsystems, cette application illustrait
l’utilisation des composants ejb. “Petstore” présente l’avantage d’être une application assez
simple et connue par l’ensemble de la communauté de développeurs Java. Pour le lecteur
qui n’est pas forcément familier avec “Petstore”, il s’agit d’un simple système de commerce
électronique d’animaux domestiques.
Sans détailler les 46 pages de spécifications, le “Petstore” implémenté disposera les
fonctionnalités suivantes :
– la sécurité et la gestion des utilisateurs : les utilisateur s’inscrivent dans le
système et peuvent gérer leur compte ;
– le catalogue des produits : les utilisateurs peuvent naviguer sur le catalogue des
animaux du site (oiseaux, poissons, reptiles,. . .) ;
– les fonctionnalités du panier : les utilisateurs peuvent ajouter des articles dans
leur panier et le gérer ;
– les fonctionnalités de commande : les utilisateurs peuvent commander le contenu
de leur panier ;
Xavier Moghrabi
33
– les services web : les utilisateurs peuvent suivre leurs commandes via un Service
Web. Le “Petstore” original a été étendu pour inclure cette technologie, émergente
et intéressante.
Pour une perspective des technologies utilisées, l’application inclut :
– un client léger, un navigateur Web interprétant le HTML pour l’interface utilisateur,
– des pages jsp pour générer le code HTML sur le serveur Web,
– un accès aux données basé sur sql et jdbc,
– des composants ejb pour les contrôles et les entités,
– la recherche dans la base de données,
– des transactions à la base de données pour éviter les erreurs d’enregistrement,
– la gestion des sessions clientes,
– des services web et
– un formulaire d’authentification.
L’application “Petstore” originale ne proposait pas de spécifications mais n’était qu’un
exemple d’utilisation de la plate-forme j2ee. Le développement de l’application ne s’inspirera pas de celle existante car cette dernière ne présentait pas une architecture bien conçue.
En plus des résultats, l’annexe B décrit le déroulement du projet pour chacune des deux
équipes.
3.1.3
L’analyse architecturale du système
Les deux équipes ont créé des diagrammes uml pour les modèles. En fait, il s’est avéré
que ces modèles étaient assez similaires. Chacun avait des classes d’abstraction pour les
comptes clients, les informations des clients, les produits, les catégories de produits, les
fournisseurs, le panier, les commandes et ses lignes.
L’équipe traditionnelle a créé des modèles uml strictement pour la conception et la
communication. Elle n’a pas généré automatiquement le code j2ee de ces modèles. Toutefois, elle a utilisé les “wizards” (outil d’aide à la réalisation) d’un environnement de
développement intégré pour les méthodes de base des ejb, les composants, l’adressage, le
traitement des exceptions et les interfaces.
L’équipe mda a créé les modèles pim et psm. Le code généré automatiquement était
plus important que celui de l’équipe précédente grâce à un outil supportant le mda. Ce
code inclut les jsp, l’ensemble des composants ejb, l’adressage, le traitement des exceptions et les interfaces.
La partie Web des deux équipes comprenait des servlet et jsp. Elles se sont appuyées
sur le framework Struts d’Apache Jakarta pour la navigation. Il s’agit d’un framework libre répandu pour bâtir des applications Web j2ee. Elles ont utilisé le paradigme
de conception MVC (Model-View-Controller) qui automatise la construction du code.
D’un point de vue architectural, la différence entre les deux équipes concerne les pattern utilisés. Le tableau de la figure 3.1, de la page 35, présente les design pattern mis
en œuvre. Les deux équipes ont des bonnes notions pour utiliser ces design pattern j2ee.
Bien que ces pattern n’aient pas été utilisés dans l’application originale, leur utilisation
place ce projet dans un développement concret. Ainsi la comparaison de productivité sera
Xavier Moghrabi
34
Pattern
Session-entity wrapper
Génération de clefs primaires des EJB
Business delegate
Data Transfert Objects (DTO)
Custum DTO
DTO Factory
Service locator
JDBC for Reading via Data Access Objects (DAO)
Business interface
Model-Driven Architecture
Équipe trad.
Oui
Oui
Oui
Oui
Oui
Oui
Oui
Oui
Oui
Non
Équipe MDA
Oui
Oui
Oui
Oui
Oui
Non
Non
Non
Non
Oui
Fig. 3.1 – Liste des design pattern utilisés par chaque équipe
plus pertinente. L’annexe C détaille plus précisément chacun de ces pattern.
L’équipe traditionnelle a utilisé plus de pattern que celle mda. On peut naturellement
penser que le code développé par la première équipe prendra plus de temps, en fonction
du nombre de pattern utilisés. Pour valider cette idée, il est intéressant de se préoccuper
de chaque pattern supplémentaire. Après avoir réaliser des recherches, le groupe chargé de
l’étude conclut que, même en utilisant plus de pattern, la comparaison reste toujours valide.
Pour comprendre cette conclusion, il est judicieux de détailler le travail engendré par
chaque pattern supplémentaire :
– Le pattern service locator ne demande pas à l’équipe traditionnelle du travail
supplémentaire. En fait, cela leur a fait économiser du temps. En effet, il simplifie
l’écriture du code pour la communication entre jsp/ejb et ejb/ejb. Le nombre
de lignes a été réduit par rapport à une implémentation classique d’une unique
classe avec des méthodes statiques. Tous les accès aux ejb ont été réalisés avec cette
méthode.
– Le pattern JDBC for Reading via DOA a nécessité du temps à l’implémentation.
Toutefois, sans l’utiliser, l’équipe aurait dû écrire des ejb entités au lieu de générer
des DOA. En contrepartie, l’équipe mda a écrit du code pour trier les données
manuellement, fonction réalisée par ce pattern.
– Le pattern business interface ne fût pas une source de travail supplémentaire. Selon l’équipe traditionnelle, cela prend approximativement dix minutes par interface.
L’équipe mda doit également créer ses interfaces, d’un niveau d’abstraction plus
élevé.
– Le pattern DTO Factory n’a demandé qu’une faible durée d’implémentation et de
test. Il économise du temps car le code est réduit.
L’utilisation de pattern accélère en fait le développement tout en améliorant l’architecture logique. En fait, l’utilisation d’un nombre de pattern plus élevé par l’équipe traditionnelle peut se comprendre par le fait qu’elle comprend un expert des pattern j2ee,
Owen Taylor.
En grande partie, les deux applications étaient très proches. La franche divergence est
observable au niveau de la sécurité. L’équipe traditionnelle a utilisé des filtres d’accès. Ce
Xavier Moghrabi
35
Équipe
Équipe traditionelle
Équipe MDA
Temps prévu
499 h
442 h
Temps réel
507,5 h
330 h
Fig. 3.2 – Temps de développement consommé par chaque équipe
système vérifie si la page restreinte et si l’utilisateur est enregistré. L’équipe a développé
entièrement ce filtre.
L’équipe mda a utilisé son outil mda pour développer la sécurité. Plusieurs framework sont disponibles permettant de choisir parmi différentes méthodes d’authentification.
3.1.4
Les résultats quantitatifs
Le tableau de la figure 3.2, de la page 36, contient le nombre d’heures de développement
dépensées par chacune des équipes.
Comme vous pouvez le voir, l’équipe mda est clairement le vainqueur de cette étude de
productivité. Le gain par rapport à un développement classique est de 34 %. L’équipe mda
a même surperformé ses estimations sur le temps initialement prévu. Le gain relatif semble
augmenté proportionnellement à la taille du projet. Les analystes de The Middleware
Company attribuent cette constatation au fait que les développeurs doivent avoir une
période pour se familiariser avec les outils mda, puisqu’il s’agit d’un nouveau paradigme.
Ainsi un programmeur de l’équipe mda pense qu’il aurait pu réaliser son travail de 10 à
20 % plus rapidement avec plus d’expérience puisqu’il s’agissait de son premier projet mda.
Toutefois dans cette étude, il n’a pas été mentionné le point récurrent à la programmation : la recherche de bogues. Des tests à partir de scénarii ont été réalisés. Plusieurs
bogues ont été trouvés pour l’application développée par l’équipe traditionnelle et aucun
pour celle mda. Les analystes pensent que cela est dû à la cohérence du code généré par
les outils mda.
3.1.5
Conclusion de l’étude de productivité
En se basant sur les résultats de cette étude, les analystes de The Middleware Company ont été impressionnés par le gain de productivité de l’équipe qui a expérimenté le
mda. Ils encouragent les organisations qui souhaitent améliorer la productivité des analystes et développeurs d’évaluer les outils mda pour leurs projets. Les organisations visées
sont principalement les entreprises qui développent des applications à base d’objets, de
composants et de services web. Un temps d’adaptation est nécessaire aux acteurs pour
comprendre et maı̂triser cette approche. Les gains de productivité demande un effort significatif mais louable pour les applications ultérieures.
L’approche mda a également d’autres vertus. Par exemple, le pim a une durée de vie
très longue ce qui rentabilise le travail sur ce modèle. Lors du développement, il incombe
aux acteurs de créer les modèles d’objets métiers qui survivent aux successions technologiques et durent de nombreuses années. Le suivi du modèle pim permet de modifier les
fonctionnalités ou la logique métier de l’application. Ce modèle est un moyen indéniable
Xavier Moghrabi
36
pour bâtir un support commun de communication entre les développeurs qui utilisent des
outils ou des technologies différents.
Un autre avantage du mda est qu’il permet aux architectes de s’assurer que les programmeurs utilisent des design pattern j2ee. Les architectes peuvent réaliser cela grâce
aux outils mda qui génèrent automatiquement le code des pattern. De cette manière l’utilisation de pattern devient une part naturelle du travail des programmeurs.
Les analystes de l’étude arrivent toutefois au constat que le mda est bien utilisé si des
architectes expérimentés conduisent les projets. L’équipe doit obligatoirement connaı̂tre
et maı̂triser les pattern et les bonnes pratiques du développement orienté objet. Le fort
engagement d’architectes est indispensables.
Finalement, en ce qui concerne la qualité du code, il s’est avéré que les résultats de
l’équipe mda surpassaient ceux du développement traditionnel. Le code généré automatiquement via les pattern ne demandaient pas des phases de correction de bogues et de
nouveaux tests.
Il est intéressant de noter que le mda possède d’autres intérêts qui n’ont pas été mis en
valeur par cette étude, comme la maintenabilité et les performances de l’application. Les
analystes ont procédé à quelques tests de performances basiques pour déterminer que les
deux applications étaient assez comparables. Pour la maintenabilité, les analystes ont expérimenté la modification du code de l’application utilisant le mda. En fait, ce changement
se répercute sur les modèles uml par reverse engineering puis le mda régénère le code à
partir des modèles modifiés. Le suivi de l’application est ainsi facilité. Concernant l’analyse
des différences entre les codages manuel et automatique, The Middleware Company
nous promet une deuxième étude qui s’attaquera aux contextes de la performance, de la
maintenabilité et d’autres aspects de l’application.
Le mda propose ainsi des avantages indéniables face aux méthodes traditionnelles mais
nécessite une équipe de développement expérimentée sur la conception de modèles et l’utilisation de design pattern. Les nombreuses entreprises ne possèdent pas ces compétences
en interne. La plupart du temps, elles sont composées de beaucoup de développeurs non familiarisés avec ces concepts. Pour elles, suivre une approche mda est compliquée en raison
du manque de compétences dans l’architecture et l’approche par modèle. Pour prouver que
le gain de productivité est général en abordant une approche mda d’autres études doivent
être menées sur plusieurs types d’applications.
3.2
Vers un nouveau standard de développement logiciel
Le mda semble prometteur même si l’approche est loin d’être finalisée. Mais il nous
semble que l’engouement actuel vers les techniques de modélisation peut jouer en faveur
de celui-ci.
3.2.1
L’approche MDA, évolution ou révolution ?
L’approche mda est un important changement de paradigme, des objets aux modèles,
d’une approche interprétative vers une approche générative. Comme Monsieur Jourdain
qui découvrait qu’il faisait toujours de la prose sans le savoir, beaucoup de gens découvrent
Xavier Moghrabi
37
ou déclarent qu’ils appliquent les principes du mda depuis une dizaine d’années. Toutefois,
avec ce récent engouement pour le mouvement d’ingénierie des modèles, il semble important de clairement exprimer l’essentiel de ce nouveau moyen de conception de systèmes
d’information. Le principal avantage est de proposer aux organisations stables de pérenniser leur système information pour faciliter les phases de construction, d’exploitation et
de maintenance. Les travaux du professeur Bézevin cherchent à identifier les composants
du mda [23] et à définir précisément ce framework [24].
Le mda oblige les concepteurs à expliciter beaucoup d’habitudes de travail dans l’intention d’améliorer le processus de développement. Des démarches de développement débutent
avec la définition d’un modèle métier abstrait pour progressivement descendre au niveau
de l’application. En identifiant, la façon dont les concepteurs transposent ce modèle à celui
de l’application, il sera possible de définir des mécanismes de transformation de modèles.
La transformation de modèles existe bien avant le mda mais la norme tente de l’automatiser.
L’idée qu’un modèle est associé à un méta-modèle spécifique est un concept d’une importance primordiale. Il permet de dire que chaque modèle représente exactement un aspect
du système et de le construire à partir d’une solide base. La bonne conception d’un système
repose sur son architecture. En fournissant un méta-modèle, sa définition est alors facilitée.
Deux opérations importantes dans l’ingénierie des modèles sont la capture de l’environnement et la transformation. La capture de l’environnement représente la capture des
détails des systèmes externes dans un modèle mda précis. Cette étape est essentielle pour
l’interopérabilité du système développé avec le système d’information. Une fois ce modèle
construit, les outils de transformations automatiques ou semi-automatiques prennent le
relais pour définir les modèles successifs. La figure 3.3, de la page 39, illustre un processus
de conception avec le mda en mettant en évidence les transformations. Ce point concerne
la vraie révolution du mda.
La transformation peut être vue comme une évolution des techniques de génération de
code. Comme un programme est un modèle (son méta-modèle correspond à la grammaire),
la génération de code est un cas spécial de transformation. Il existe toutefois beaucoup plus
de sources d’inspiration lorsqu’il s’agit de transformation de modèles dans le sens mda.
La majeure partie du travail restant se trouve dans la transformation de mda et l’adaptation de cette méthode à chaque domaine particulier. Une fois arrivée à ce stade, le mda
sera plus facile à mettre en œuvre pour les industriels. Il s’agit d’une révolution dans la
conception logicielle du fait qu’un consortium tel que l’omg choisit de normaliser cette
approche. Des démarches similaires existaient auparavant mais sans norme forte, elles ne
pourront pas avoir le même impact que le mda.
3.2.2
Une approche de modélisation d’un ERP où le MDA a sa place
Face à la complexité croissante des systèmes d’information, le constat est le suivant :
– il est de plus en plus difficile d’appréhender l’univers du réel et de structurer la
connaissance,
– le risque de fossé sémantique entre l’univers réel et ses modèles est de plus en plus
Xavier Moghrabi
38
Fig. 3.3 – Capture de l’environnement et transformation de modèles
important,
– la variété des acteurs participant à la réalisation des tâches d’une entreprise et la
variété des postes de travail et des outils utilisés provoquent nécessairement une rupture sémantique tout au long de la réalisation de ces tâches.
Les travaux de recherche de Richard Lemesle [25]montrent que les techniques de modélisation et méta-modélisation répondent aux problèmes précédents. Par exemple, une
approche telle que le mda apporte un certain nombre de réponses ou tout au moins d’éléments de réponse :
– il joue le rôle de solution unifiée de représentation de modèles,
– il permet de structurer ces modèles et d’en réduire ainsi la complexité,
– il apporte une structuration modulaire de la sémantique des modèles et permet la
spécialisation de ces univers sémantiques,
– il propose des facilités de navigation, de manipulation et par conséquent de réactivité
pour les usagers,
– il propose également des facilités de transformation de modèles et d’élaboration de
ponts pour assurer la continuité sémantique et ainsi rapprocher les différents acteurs
de ces processus.
Des leurs sujets de recherche, Valérie Botta-Genoulaz [26] et Pascal Boutin [27]
ont montré l’importance de la modélisation métier dans la conception d’un erp. La modélisation d’entreprise propose de comprendre et d’analyser les processus opérationnels du
“système entreprise” grâce à un cadre de conception représenté sur la figure 3.4, de la page
40. La démarche repose sur l’aboutissement d’un modèle référence, correspondant à une
représentation conceptuelle et générique de la solution, et d’un modèle entreprise propre
au flux d’informations et processus de l’application.
Xavier Moghrabi
39
Fig. 3.4 – Architecture de modélisation d’un système d’information
Dans ses travaux de thèse, Franck Darras [3] propose de représenter ces deux modèles
avec uml. En utilisant ce formalisme commun, il compte mettre en évidence les dépendances entre les modèles. Cette démarche a pour intérêt de configurer la solution aux
besoins de l’entreprise. La représentation de la figure 3.4, de la page 40, présente l’intérêt
de décrire une méthode issue de ces travaux de conception sous la forme d’un cheminement
particulier.
Le mda peut être perçu comme une spécialisation d’une logique métier vers une plateforme d’implémentation alors que Franck Darras nous propose une double spécialisation
d’un modèle générique vers un modèle particulier à une entreprise et d’un modèle de
haut niveau d’abstraction vers une application. Toutefois, nous pouvons comparer cette
spécialisation métier à la transformation d’un pim en un second pim. Malheureusement,
cette transformation n’est a priori pas automatisable comme la transformation du pim en
psm. La spécification d’un modèle de haut niveau vers un modèle de conception peut être
comparée à une transformation d’un pim en psm. Le passage du modèle de conception à
l’implémentation correspondrait à la génération de code à partir de ce psm. Le mda peut
s’intégrer dans ce processus de développement.
En lisant l’article précité, on se rend compte que le mda permet la réalisation d’un système d’information d’entreprise à partir d’un progiciel erp générique. La tendance montre
que les systèmes de configuration des erp sont actuellement insuffisants ou coûteux en
ressources. Le concept de proposer un pim générique implémenté par plusieurs pim particuliers facilite cette étape. Le modèle générique décrit les flux d’informations et toutes
les variantes des processus couverts par l’application. La spécialisation s’appuie sur l’hypothèse qu’il existe un certain nombre de gestions d’entreprise types auxquelles chaque
entreprise cible correspond. Le mda n’est pas la solution miracle car n’automatise pas ses
transformations mais peut convenir à cette approche.
Xavier Moghrabi
40
Fig. 3.5 – Le bus logiciel et le bus de connaissances
3.2.3
Le MDA présente des atouts pour s’imposer comme un nouveau
standard
La chaı̂ne méthodologique mda est perçue par une partie de la communauté logicielle
comme une norme qui s’imposera pour devenir un nouveau standard de développement
logiciel. Mais pour devenir un standard, Le mda doit se répandre dans l’industrie logicielle.
Pour l’instant, le sentiment est que les éditeurs d’outils mda valorisent cette approche pour
proposer de nouveaux produits.
Sur le papier, le mda a de sérieuse chance de s’imposer les années à venir comme un
standard. Tout d’abord, il fait appel à des standards pour la méta-modélisation et la modélisation comme mof, xmi, uml et cwm. Ces derniers se sont imposés pour la conception
de logiciels à base des technologies objet. Ils fournissent un support robuste pour le mda et
permettent l’interopérabilité de modèles et méta-modèles. On peut comparer cet ensemble
de standard à un bus de connaissances comme le montre la figure 3.5, de la page 41, avec
le bus logiciel Corba.
Ensuite, le mda est conçu pour générer des applications sur les plate-formes qui prennent
de plus en plus d’importance au sein des systèmes d’information : Corba, j2ee, .net et
les services web. L’interopérabilité entre ces systèmes est d’ailleurs prévue. C’est un
point essentiel car l’industrie logicielle tente depuis de nombreuses années à améliorer la
capacité de différents systèmes informatiques à coopérer pour la réalisation de traitements
en commun. L’omg a essayé avec Corba de fournir un bus logiciel avec des passerelles
vers d’autres technologies [3]. Mais la pérennité de cette solution suite aux mises à jour
des applications ne pouvait être assurée. En positionnant un modèle commun, le pim, l’interopérabilité a ainsi été montée d’un niveau d’abstraction.
Les travaux de thèse de Erwan Breton [28] tendent à démontrer la pertinence des
techniques de méta-modélisation dans le domaine des processus. Cela a pu être tout particulièrement mis en évidence par des réalisations industrielles. Même si la solution développée au cours de ces travaux est basée sur un méta-modèle propriétaire répondant aux
besoins des experts métier de SofiFrance, l’auteur reconnaı̂t que le mda saura ajouter
la reconnaissance et la pérennité à son approche. Il lui semble évident qu’une des premières suites de ses travaux consiste à prendre acte de l’émergence de ce standard et à
Xavier Moghrabi
41
étudier son intégration dans l’outillage développé. De plus, avec l’utilisation importante
des méthodes basées sur le processus unifié, le mda apportera un gain à tous les utilisateurs.
Un des points qui peut rendre le mda crédible est son soutien par l’omg qui est un
consortium de 472 sociétés. Ces dernières vont mettre, plus ou moins, en avant cette approche. D’ailleurs l’omg travaille sur la conception de méta-modèles pour un large éventail
de domaines d’applications. Cette vision est beaucoup plus ouverte que si une société tentait seule de démocratiser cette démarche.
Toutefois l’expérience de Corba a montré que malgré une norme ouverte et complète,
il n’était pas évident d’imposer ce middleware à l’ensemble de l’industrie logicielle. Des
modèles concurrents sont apparus ultérieurement et ont fait de l’ombre à Corba grâce
à leur simplicité d’utilisation bien qu’elle cloisonnait le système d’information à des technologies particulières. Le mda n’est pas à l’abri de l’émergence de nouvelles approches
concurrentes. Les approches traditionnelles sont de mieux en mieux maı̂trisées par les entreprises et le changement de méthodologie demande un temps d’adaptation.
Un des problèmes de Corba est que les implémentations du marché étaient très hétérogènes. Il se passe pour l’instant la même chose pour les produits compatibles mda. Le
produit libre OpenMDA se limite pour l’instant à la génération de code alors que OptimalJ
réalise une partie de la transformation de modèles.
Finalement, le mda se limite aux middleware précités et les systèmes d’information
basés sur des middleware propriétaires hérités de d’applications existant depuis quelques
années sont laissés pour compte.
Le mda a des chances pour convaincre l’industrie logicielle de ses qualités. Il permet
de réduire le développement logiciel de façon significatif. Toutefois, d’autres études doivent
évaluer chacun des avantages mis en avant par le mda. Pour devenir un nouveau standard,
il lui reste encore quelques points à surmonter.
Xavier Moghrabi
42
Conclusion
Les entreprises sont lassées d’investir dans les technologies pour suivre les évolutions
des middleware. Elle souhaite pérenniser l’architecture de leur système d’information
et évoluer à leur rythme. Dans ce contexte, l’omg travaille sur une spécification robuste,
ouverte et parfaitement adaptée à l’évolution des technologies et des méthodes de travail :
le Model-Driven Architecture.
Cette approche apporte un gain indéniable à l’ensemble des acteurs des systèmes informatiques. Le mda aide :
– les architectes à pérenniser les architectures,
– les développeurs à générer automatique des éléments récurrents et fastidieux,
– les managers à identifier les tâches de chaque expert dans le processus,
– et les chefs d’entreprise à réduire leur investissement et à minimiser les risques d’engagement dans une technologie.
Le mda a toutes ses chances de devenir le nouveau paradigme de développement logiciel et un standard reconnu par l’ensemble de la communauté. À l’instar d’uml qui est
devenu le formalisme standard de modélisation à base des technologies objet, le mda apporte un besoin de normalisation d’approches de modèles et méta-modèles qui existaient
déjà. Toutefois la norme n’est pas encore définie, les transformations et les outils sont au
stade embryonnaire. Cette situation devrait s’arranger avec le temps et le mda devrait
être entièrement finalisé à l’horizon 2008.
Pour le développement d’un erp, l’approche mda peut se révéler encore plus intéressante. Tout d’abord avec le concept d’erp à base de composants, le mda va encore plus loin
en proposant une normalisation pour les domaines verticaux (la production, la finance,. . .)
Ensuite, il permettra de construire, à partir d’une solution logicielle générique, le système
d’information d’une entreprise.
Toutefois, le mda demande des compétences pointues en architecture et modélisation
que les entreprises n’ont pas forcément. Le manque de visibilité sur les outils mda dû à la
liberté d’implémentation freine également l’adoption du mda.
En s’inpirant des phrases promotionnelles de Java telle que la fameuse expression“Write
once, run everywhere”, Jean Bézivin propose “Model once, Generate everywhere” pour
illustrer la montée en abstraction de la portabilité. Nous restons tout de même dubitatifs
quant à l’atteinte de l’ensemble des objectifs du mda.
Xavier Moghrabi
43
Glossaire
.NET : Framework de Microsoft pour constuire des applications orientées Web
15, 21, 41
CIM : Computation Independent Model
2, 8, 9,
10, 16, 20, 25, 30, 32
CWM : Common Warehouse Metamodel, standard d’entrepôts de données 8, 9, 16, 17,
41
Corba : Common Object Request Broker Architecture, architecture normalisée d’ORB 2,
6, 8, 9, 12, 14, 15, 17–19, 21, 27–31, 41, 42
DTD : Document Technical Description, structures types de documents qui décrivent les
éléments composant les textes et les règles qui les régissent, utilisé pour XML 17, 19
DTF : Domain Task Force, groupes de l’OMG qui s’occupent de la standardisation de
domaines verticaux
18, 19, 22
EJB : Enterprise Java Beans, composants de la plate-forme J2EE
19, 21, 31, 33–35
7–9, 12, 13, 16, 17,
ERP : Enterprise Resource Planning, progiciel de gestion intégré 1–4, 18, 19, 22, 23, 31,
39, 40, 43
Framework : Ensemble d’outils et de composants qui aident au développement d’application, pour un contexte donné
12, 16, 19, 29, 34, 36,
38
IDL : Interface Definition Language, Langage de définition d’interfaces permettant de
spécifier des opérations sur les objets, proposé comme standard par l’OMG 16, 19,
29–31
J2EE : Java 2 Enterprise Edition, framework de l’environnement Java composé de nombreuses API et composants destinés à une utilisation ”côté serveur” au sein du système d’information de l’entreprise
2, 12, 15, 33–35, 37,
41
JDBC : Java DataBase Connectivity, ensemble d’API permettant à un programme Java
l’accès aux bases de données
34
JSP : Java Server Page, technologie Java qui s’insère dans les pages en HTML pour
ajouter des fonctionnalités dynamiques
34, 35
MDA : Model-Driven Architecture, norme d’approche des modèles
1, 2, 6–25, 27–43
MOF : Met Object Facility, standard d’échange de métadonnées entre contenants de
données distribuées
1, 8, 9, 16, 17, 41
Middleware : Couche logicielle assurant la communication entre une application et le
réseau en architecture client-serveur ou distribuée
1, 2, 6, 8, 9, 14, 16, 19, 22, 23,
27–31, 33, 42, 43
Xavier Moghrabi
44
OCL : Object Constraint Language, méthode d’expression de contraintes entre les objets,
fait partie d’uml
16
OMA : Object Management Architecture, désigne une activité de l’OMG
7
OMG : Object Management Group, consortium d’entreprises dont l’objectif est de développer des spécifications techniques favorisant l’émergence d’un marché de composants logiciels orientés objet
1, 6, 8–12, 14–21, 25, 27, 32, 33, 38,
41–43
ORB : Object Request Broker, bus logiciel pour faire collaborer des objets et des composants
3–5, 15,
28
PDM : Platform Description Model
11, 12, 16, 25
PIM : Platform Independent Model
8, 10–17, 19–25, 28, 30, 32–34, 36, 40, 41
PSM : Platform Specific Model
8, 10–13, 15–17, 19–22, 25, 30, 32, 34, 40
SQL : Structured Query Language, langage structuré de requête que l’on réserve à l’interrogation de bases de données importantes
34
SVG : Scalable Vector Graphics, norme pour créer des dessins vectoriels à partir d’XML 17
Services Web : Norme pour faire collaborer des applications Web à base de XML sur le
protocole SOAP
6, 8, 14, 19, 21, 31, 34, 36, 41
Servlet : Programme Java qui s’exécute sur un serveur pour créer dynamiquement des
pages en HTML
34
UML : Unified Modeling Language, méthode de modélisation orientée objet
8–10, 12, 15–17, 19–22, 25, 29–34, 37, 40, 41, 43
1, 3, 6,
XMI : XML Metadata Interchange, projet visant à associer MOF, UML et XML pour
créer un standard d’échange de contenant de données 1, 8, 9, 12, 15–17, 19–21, 41
XML : eXtended Markup Language, méta-langage extensible dérivé permettant de structurer des données
17, 19,
21
XSLT : eXtensible Style Language Transformation, langage sous-ensemble de XSL, qui
permet d’effectuer des traitements et des transformations sur les données XML 17,
20, 21
Xavier Moghrabi
45
Table des figures
1.1
1.2
1.3
1.4
Description du méta-modèle mda . .
Vue globale de l’achitecture du mda
Exemple d’utilisation des modèles du
Un exemple de méta-modèle en mda
. . .
. . .
mda
. . .
. . .
. . .
pour
. . .
. . . . . . .
. . . . . . .
réaliser une
. . . . . . .
2.1
2.2
2.3
2.4
2.5
2.6
Modèles uml de framewroks pour des mécanismes verticaux . . . . . . . . .
Le cycle Y dans le mda . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Le cycle de vie de l’EUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L’architecture logicielle de Wells Fargo et le rôle du BOS . . . . . . . . .
L’environnement de traitement du BOS de Wells Fargo . . . . . . . . . . .
Création et maintenance de l’environnement middleware à partir du modèle
19
25
26
28
29
30
3.1
3.2
3.3
3.4
3.5
Liste des design pattern utilisés par chaque équipe . . . .
Temps de développement consommé par chaque équipe . .
Capture de l’environnement et transformation de modèles
Architecture de modélisation d’un système d’information .
Le bus logiciel et le bus de connaissances . . . . . . . . . .
35
36
39
40
41
.
.
.
.
.
. . . . . . .
. . . . . . .
application
. . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 8
. 9
. 11
. 13
.
.
.
.
.
A.1 L’architecture à quatre niveaux . . . . . . . . . . . . . . . . . . . . . . . . . 51
Xavier Moghrabi
46
Bibliographie
[1] Sprott D., Componentizing the enterprise application packages, Communications
of the ACM volume 43, 2000.
[2] Kumar K. et van Hillegersberg J.,ERP : Experiences and Evolution, Communications of the ACM, volume 43, 2000.
[3] Darras F., Gaborit P. et Pingaud H., Gestion de la configuration lors de
l’intégration d’un ERP, article École des Mines d’Albi–Carmaux.
[4] Oya M., MDA and System Design, présentation aux MDA Information Days, Avril
2002, disponible sur :http://www.omg.org/mda/presentations.htm.
[5] Soley R. et l’OMG Staff Strategy Group, Model-Driven Architecture, Version 3.2,
27 novembre 2000, disponible sur : http://www.omg.org/mda/presentations.htm.
[6] Bézivin J. et Blanc X., MDA : Vers un important changement de paradigme
en génie logiciel, Développeur référence v2.16, 15 juillet 2002, disponible sur :
http://www.sciences.univ-nantes.fr/info/lrsg/Pages perso/JB/Jean 2002.htm.
[7] R. Dirckze et al., A Metamodel-Based Approach to Model Engineering Using the
MOF, FIWME, Nice, 13 juin 2000, disponible sur : http://www.metamodel.com.
[8] Bézivin J., From Object Composition to Model Transformation with the MDA,
publié dans TOOLS’USA, Volume OEEE TOOLS-39, Santa Barbara, août 2001.
[9] D’Souza D., Model-Driven Architecture and Integration : Opportunities and Challenges, Version 1.1, février 2001, disponible sur : http://www.kinetium.com.
[10] Miller J. et Mukerji J., Model Driven Architecture - A technical perspective, 9
juillet 2001, disponible sur : http://www.omg.org/mda/presentations.htm.
[11] OMG, Model-Driven Architecture, A Techncal Perspective, 14 février 2001, disponible
sur : http://www.omg.org/mda/presentations.htm.
[12] OMG, MDA Guide Version 1.0.1,
//www.omg.org/mda/.
47
1
juin
2003,
disponible
sur
:
http:
[13] Juliot E., Présentation de MDA : Model Driven Architecture, DESS Génie Informatique, Université de Nantes, 10 juin 2002, disponible sur : http://www.toutmda.fr.st.
[14] Siegel J. et l’OMG Staff Strategy Group, Developing in OMG’s ModelDriven Architecture, Version 2.6, novembre 2001, disponible sur : http:
//www.omg.org/mda/presentations.htm.
[15] Ambler S. W., Architecture and Architecture Modeling Techniques, 2002, disponible
sur : http://www.agiledata.org/essays/enterpriseArchitectureTechniques.html.
[16] Malenfant J., Modélisation de la sémantique formelle des langages de programmation en UML et OCL, Rapport de recherche n◦ 4499, juillet 2002, disponible sur :
http://www.inria.fr/rrrt/rr-4499.html.
[17] OMG, Committed Companies and Their Products, disponible sur : http:
//www.omg.org/mda/committed-products.htm.
[18] Parigot D., MoDathèque, Plate-forme MDA, janvier 2003, disponible sur :
http://www-sop.inria.fr/oasis/Didier.Parigot/MDA/resumer.html.
[19] Saint Martin P., UML, le retour en grâce, Développeur référence 2.20 et 2.21, 6
et 22 novembre 2002, disponible sur : http://devreference.net.
[20] Bézivin J. et Blanc X., Promesses et Interrogations de l’Approche MDA, Développeur référence 2.17 et 2.18, 5 septembre et 2 octobre 2002.
[21] Harmon P., Wells Fargo’s Business Object Services : A Case Study in Model-Driven
Architecture, octobre 2001, disponible sur : http://e-serv.ebizq.net/obj/harmon 1.html.
[22] The Middleware Company, Model Driven Development for J2EE Utilizing a
Model-Driven Architecture (MDA) Approach – Productivity Analysis, juin 2003,
http://www.omg.org/mda/mda files/MDA Comparison-TMC final.pdf.
[23] Bézivin J. et Gérard S., A Preliminary Identification of MDA Components, présentation à OOPSLA 2002, 4-8 novembre 2002, disponible sur :
http://www.softmetaware.com/oopsla2002/bezivinj.pdf.
[24] Bézivin J. et Gerbé O., Towards a Precise Definition of the OMG/MDA Framework, présentation à ASE’01, San Diego (USA), 26-29 novembre 2001, disponible
sur : http://www.sciences.univ-nantes.fr/info/lrsg/Pages perso/Publications/ASE01.
OG.JB.pdf.
[25] Lemesle R., Techniques de Modélisation et de Méta-modélisation, Thèse, Université
de Nantes, 26 octobre 2000, disponible sur : http://www.sciences.univ-nantes.fr/info/
lrsg/Pages perso/RL/Richard 2001.htm.
Xavier Moghrabi
48
[26] Botta-Genoulaz V., Millet P.-A. et Neubert G., The role of enterprise
modelling in ERP implementation, IEPM pp 220-231, 2001.
[27] Boutin P., Définition d’une méthode de mise en œuvre et de prototypage d’un
progiciel de gestion d’entreprise (ERP), Thèse, École des Mines de Saint-Étienne,
2001.
[28] Breton E., Contribution à la représentation de processus par des techniques
de méta-modélisation, Thèse, Université de Nantes, juin 2002, disponible sur :
http://www.sciences.univ-nantes.fr/info/lrsg/Pages perso/EB/Erwan.htm.
Xavier Moghrabi
49
Annexe A
Une architecture stratifiée
La distinction entre les PIMs et les PSMs est plutôt d’ordre méthodologique. Il est
important de noter que cette distinction n’est pas la seule. En effet, les modèles manipulés
dans le MDA sont de natures très diverses. Il y a bien sûr les modèles d’objets métier,
les modèles de processus ou de workflow, les modèles de règles mais aussi les modèles de
service, de qualité de service, les modèles de plate-forme, les modèles de transformation,
les modèle de tests, les modèles de mesure, etc. . . Derrière le recensement en cours de tous
ces modèles (la cartographie générale du MDA) se profile un projet ambitieux et à long
terme de définition d’un cadre générique de conception et de maintenance des systèmes
d’information.
Afin d’organiser et de structurer tous ces modèles, l’OMG a défini une architecture
appelée : “Architecture à quatre niveaux” représenté sur la figure A.1, de la page 51.
Ces quatre niveaux sont :
– Le niveau M0 qui est le niveau des données réelles, est composé des informations que
l’on souhaite modéliser. Ce niveau est souvent considéré comme étant le monde réel.
– Le niveau M1 est composé de modèles d’information. Lorsque l’on veut décrire les
informations de M0, le MDA considère que l’on fait un modèle appartenant au niveau M1. Typiquement, un modèle UML appartient au niveau M1. Tout modèle
est exprimé dans un langage unique dont la définition est fournie explicitement au
niveau M2.
– Le niveau M2 est donc composé de langages de définition des modèles d’information,
appelés aussi méta-modèles. Typiquement, le méta-modèle UML qui est décrit dans
le standard UML appartient au niveau M2 ; il définit la structure interne des modèles UML. Notons au passage que le concept de profil UML qui permet d’étendre le
méta-modèle UML est aussi considéré comme appartenant au niveau M2. Un métamodèle définit donc un langage de modélisation spécifique à un domaine et un profil
définit un dialecte (une variante) de ce langage.
– Le niveau M3 qui est composé d’une unique entité qui est le langage unique de définition des métamodèles, aussi appelé le méta-méta-modèle ou le MOF (Meta-Object
Facility). Le MOF définit lastructure de tous les méta-modèles qui se trouvent au
niveau M2. Le MOF est réflexif, c’est-à-dire que la description du MOF s’applique
au MOF lui-même, ce qui permet de dire que le niveau M3 est le dernier niveau
Xavier Moghrabi
50
Fig. A.1 – L’architecture à quatre niveaux
de l’architecture. Le niveau M3 correspond donc aux fonctionnalités universelles de
modélisation logicielle, alors que le niveau M2 correspond aux aspects spécifiques
des différents domaines, chaque aspect particulier étant pris en compte par un métamodèle spécifique.
Dans cette architecture, les PIM et les PSM appartiennent au niveau M1. Leurs structures sont définies par des méta-modèles (ou profils) qui appartiennent au niveau M2. Le
MOF permet de définir de façon homogène, tous ces méta-modèles. Le MDA ne traite pratiquement pas du niveau M0. Il faut enfin insister sur le fait que les niveaux qui viennent
d’être décrits n’ont rien à voir avec des niveaux d’abstraction ou de machines virtuelles
comme on peut en trouver dans les piles ISO/OSI ou TCP/IP par exemple. Ce sont des
niveaux de méta-modélisation (également différents de ce que l’on nomme parfois la métaprogrammation).
Xavier Moghrabi
51
Annexe B
Évolution hebdomadaire de l’étude
Cette annexe en anglais décrit l’évolution du projet de chacune des équipes au fil des
semaines.
Traditional Team
Traditionnal Team – Week 1
The traditional team adopted an iterative prototyping style development process. In
the first week, they built a simple prototype that allowed them to architect their design
patterns basis for their project. It was a fairly involved process for them to establish a
comfortable development environment, and they ran into a few challenges getting StarTeam version control to collaborate effectively with their IDE. They used workarounds to
sidestep this issue, which was largely resolved by week 2. They also spent a good amount
of time during week 1 architecting the object model for their system, deciding on a package
structure, and other environment-related issues.
From the productivity perspective, they were impressed by the capabilities of their
IDE that first week. They found the IDE to integrate well with their chosen application
server, as well as have good code generation capabilities. It helped that each of the team
members had experience with the IDE in the past.
Their productivity challenges this week related to sharing files, communication issues,
performing code reviews, and maintaining a consistent package structure.
In week two, the traditional development team began to specialize in their various development roles. One team member owned the model (EJB) layer, another team member
owned the view (web) layer, while a third team member added value through providing
helper classes and interfaces between layers to keep the team members productive.
The team decided to build their system in a use-case fashion, by focusing on each
use-case in turn. This week they worked on user account maintenance use-cases, such as
sign-in, sign-out, user creation and user preference maintenance.
Xavier Moghrabi
52
From the productivity perspective, what they found good this week was leveraging
the Struts framework. They found Struts coding to be very efficient. Furthermore, they
decided to use a strategy of decoupling their web tier and business tier by allowing “stub”
implementation code to be plugged in for code that was not fully built yet. They switched
between “stub” and “real” code through properties files and the business delegate design
pattern described in the next appendix.
The productivity challenges this week were the typical ones a development team first
encounters, such as consistent use of source control. They also had some challenges with
their IDE, in that if they tried to generate J2EE components from their IDE, and needed to modify them later, the components did not round-trip back into the IDE very easily.
This week, the traditional team continued their development by working on product
catalog browsing, as well as some shopping cart functionality.
From the productivity perspective, what they found good this week was that they had
resolved their version control collaboration issues. They also reduced build-time dependencies by building libraries of interfaces that team members could use. At this stage in
development, each team member was very productive and the project was well partitioned
so that each team member had his own area of development. Furthermore, their IDE had
been providing them value in code generation capabilities.
The only challenges this week were clarifications required for the PetStore specification,
and some minor refactoring they needed to perform on their shopping cart.
Traditionnal Team – Week 4 and 5
In their final weeks, the traditional development team wrapped up their application by
coding the final use cases, performing testing, and debugging. Also, they integrated their
team members’ code together, abandoning the stub implementations that had served their
purpose.
Productivity gains these weeks included several items. They received a continual benefit from the stub implementation architecture they chose. Very little team communication
was required given the interfaces they had authored that allowed them to collaborate
efficiently. Also, their web service implementation was built very quickly, as their IDE
provided capabilities enabling them to do this – specifically, code generation capabilities
in the form of automated WSDL generation and SOAP server deployment.
The challenges this week included some re-factoring and re-analysis of code, such as in
their data access layer, which had several flaws. The fact that their application had many
layers also caused challenges when things broke, since it was not always clear where the
issue was until they delved into the layers. They also had some other minor issues related
to Struts and property files.
Xavier Moghrabi
53
MDA Team
MDA Team – Week 1
In the first week, the MDA team performed many of the typical steps project teams
go through at the onset of their project. They created a detailed design of their object
model using their MDA tool’s UML modeling capabilities. They set up their source control
system, and began to partition the project tasks so that each team member could remain
efficient. They also set up a project directory structure and began some initial development.
What was good this week from the productivity perspective was they noticed that
they didn’t need to build very many components, because the MDA tool was capable of
generating the code for them. In fact, they noticed the tool could generate not only the
components, but also much of the ’scaffolding’ code that links the components together,
generating the application end-to-end. The team anticipated 50 to 90 percent of their
application could be generated, including web pages, Struts actions, EJB entity beans,
EJB session bean facades, J2EE design pattern scaffolding code and database tables. The
key challenge this week was to grasp mentally the new paradigm that the MDA approach
represents.
The approach was a departure from things they had been doing traditionally, and the
tool they used provided many layers and structure that required ramp-up time.
MDA Team – Week 2
In week 2, the MDA team was knee-deep in development. They had completed many
parts to their site, including their UML object model, their framework for components,
the site navigation system, JSP templates (made in Dreamweaver) that have some code
common to all pages, their home page, a good portion of the EJB shopping cart functionality and minor user account management functionality.
What had been good this week from the productivity perspective was that they were
able to generate EJB session/entity bean code, web tier code, and a DDL model from their
UML object model. It was also very easy to create a test data set. Finally, the end-to-end
application framework provided by their MDA tool allowed them to integrate their components together quickly.
The challenges this week were similar to those of the traditional team. They had environment challenges, including getting used to their source control system in a collaborative
development environment. They spent quite a bit of time getting their product configured.
They also underestimated the learning curve required to embrace their MDA tool, and had
to continually learn throughout the week to get used to the paradigm shift from traditional development. Finally, they realized that the code generation capabilities of MDA are
sometimes overkill, in that it generated heavier code than they needed. They did want to
note, however, that it was possible to modify the algorithms used by the tool to generate
code, and in a real project that would be done to alleviate this problem, however this fell
outside the scope of this case study.
Xavier Moghrabi
54
MDA Team – Week 3
During week 3, the MDA team finished several more use-cases for their system, including shopping cart, order processing, account management, and a sign-in module.
From the productivity perspective, several good things happened this week. Their security system was built very easily since the MDA tool assisted them in this code generation.
Their idea of using JSP templates also was beneficial, since their JSPs in essence “inherited” common code from other JSPs, so common code could be updated in a centralized place.
One developer was starting to see the benefits of the MDA process this week, and felt
compelled to make the following statement :
The value of MDA is analogous to the value of OO in general. It requires more of you in
the design phase, and the payoff comes in the implementation phase. And once you’ve built
one or two apps, you really start to get the benefit from it.
They also had several challenges this week. They ran into some Struts nuances that
bogged them down temporarily. They also had a minor issue relating to using session identifiers and cookies with web browsers. Their final challenge this week was MDA-related.
They noticed that with the MDA process, you may run into development potholes due to
a mismatch between the code that you thought would be generated, and the code that
was actually generated. Their MDA tool sometimes generated code they didn’t need, or
too much code, which did not help productivity. What the team realized was that their
own inexperience with MDA and code generation was the cause of this problem, since they
were inexperienced in anticipating what code would be generated. They believe this would
be solved with experience and time with using their MDA tool, and the more they used it,
the more productive they became. But the shortterm unfamiliarity with their MDA tool
did cost them a few minor delays.
MDA Team – Week 4
In week 4, the MDA team finished their development, testing and debugging.
From the productivity perspective, their positive gains this week were due to MDAbased code generation, as well as the value of the Struts framework and authentication
framework that came with their MDA tool. Also, the integration process they used ran
very smoothly.
The challenge this week was that sometimes the code that was generated was a liability.
They would either have to materially modify it, or abandon it. They did note, however,
that the code they wrote manually was patterned after what the MDA tool generated, and
that gave them a leg up from the implementation perspective. They also had challenges
with source control integration of the MDA tool. The takeaway point they wanted to note
is that when you’re using a complex product like an MDA tool, you need to understand
what’s going on and be careful about how you mesh it with version control. First-time
users may stumble a couple of times before getting it right.
Xavier Moghrabi
55
Annexe C
Glossaire des design pattern
utilisés
Dans cette annexe, nous avons repris le document qui détaille chacun des design pattern utilisés par les équipes. Il s’agit du document original dans la langue de Shakespear détaillé par les annalystes de The Middleware Company. Ce document est technique et demande au lecteur une connaissance de la programmation avec J2EE. Pour
plus d’information, un livre sur les design pattern est disponible au téléchargement sur :
http://www.theserverside.com/.
Session-Entity Wrapper
When client code (such as JSP code or servlet code) accesses an EJB, it’s important
to reduce the number of network round trips and transactions to a bare minimum. You
can achieve this by wrapping entity beans with a session bean wrapper. The client code
calls the session beans, which then delegate to entity beans. Thus the session beans serve
as a network façade and a transactional façade on behalf of the entity beans. This is also
a natural fit, since a session bean models an action while an entity bean models data.
Actions use data.
Primary Key Generation in EJB Components
A primary key is a unique identifier for a database record. Traditionally primary keys
have been generated at the database-level by using database features (such as Oracle’s
sequences). This approach is perfectly valid, however it is not portable across databases.
This is problematic for independent software vendors (ISVs) and other groups that need
to support a wide variety of databases.
You can generate primary keys in a portable fashion by using EJB components. There
are several strategies you can use to achieve this. For example, you can use an algorithmic
primary key generator to generate keys in-memory (note that the precision of such primary
keys is limited due to limitations in the Java Virtual Machine). You can also create a
database table dedicated to creating primary keys, and increment a counter that is cached
in-memory via EJB components for performance reasons. These strategies are discussed
in more detail in the EJB Design Patterns book or our J2EE Patterns course.
Xavier Moghrabi
56
Business Delegate
One of the challenges with EJB development is coordinating a team to be productive.
Often times team members are waiting on each other for code, twiddling their thumbs.
The business delegate design pattern solves this problem. The idea behind business
delegates is to create a layer of plain Java classes that hide EJB API complexity by encapsulating code required to call EJB components. The client code (in this case, the web
layer) calls the business delegates, which then access EJB components on their behalf. This
allows you to “plug in” stub implementations for code that is not yet developed, keeping
team members productive.
Business delegates have other minor benefits as well. They effectively shield your client
code from EJB completely, allowing you to use another technology at a later date if you
see fit. They can also cache data locally, and retry failed transactions in a transparent
manner to client code.
Data Transfer Objects (DTOs)
Data Transfer Objects (DTOs), also known as Value Objects (VOs), are classes that
hold data that is marshaled across tiers. They are useful for aggregating large amounts of
data that would normally take many network roundtrips to retrieve. By using DTOs you
can reduce the number of network roundtrips required to your EJB layer. Rather than
calling 10 entity bean getter methods, you would retrieve a single DTO that contained all
10 fields. Generally speaking, a DTO maps to an entity bean.
Custom Data Transfer Objects
Custom DTOs are a specialization of the generic DTO design pattern. The best way to
understand the need for Custom DTOs is to think about an entity bean that has hundreds
of attributes. Most of the time, client code will only want to retrieve a small fraction of
this data from the entity bean. Thus it doesn’t make sense to populate and marshal a
DTO that embodies the complete entity bean. A Custom DTO can represent a subset of
an entity bean, thus solving this problem.
DTO Factory
A typical J2EE application will require a plethora of DTOs. DTOs may be needed for
each use-case of the system, and DTOs may need change as the domain model changes. A
DTO Factory is responsible for creating and consuming DTOs. It can create a DTO and
populate it based on a primary key of an entity bean. It can look up an entity bean, make
local calls to retrieve data, populate a DTO, and return that DTO to a session bean. This
saves from having to rewrite this basic population code over and over again in the session
beans. The purpose of the DTO factory is to shield the application from the high velocity
of change DTOs experience. It can increase maintainability, reuse, and even performance.
Service Locator
The Service Locator pattern was invented by John Crupi’s team at Sun Microsystems
who wrote the J2EE Patterns book. It is a Java class with static methods that EJB client
code uses to obtain references to EJB homes via the Java Naming and Directory Interface
Xavier Moghrabi
57
(JNDI). The Service Locator pattern enhances performance since it can cache JNDI homes,
and reduces the need to write redundant JNDI code in clients. Client code doesn’t need to
know JNDI, deal with EJB exceptions, or narrow references. Think of the Service Locator
pattern as a helper class that contains common JNDI code needed to be written many
times.
Business Interface
One of the best-practices established in EJB development is that an enterprise bean
class should not implement its own remote interface, since a remote interface contains
methods that a bean should not implement, such as those defined in javax.ejb.EJBObject.
However, the idea of a class implementing an interface is a nifty way to enforce compile-time
checking that the method signatures for an implementation match those of an interface,
and we would still like to retain this value.
A solution to this is the business interface pattern for EJB components. A business
interface contains your EJB business methods. The remote interface extends this interface,
and the enterprise bean class implements this interface.
JDBC for Reading via Data Access Objects (DAOs)
The JDBC for Reading pattern encourages you to use JDBC to read database data,
rather than go through an entity bean layer. There are many reasons for this, such as
inflexibility in the EJB query language, the ability to hand-tune SQL, and the granularity
constraints that you have when performing SQL with entity beans.
Data Access Objects (DAOs) are lightweight persistent Java classes that are a valid
substitute for entity beans. In this project, the traditional team used them as an implementation of the JDBC for Reading pattern, in that they used them purely for reading
purposes. They had entity beans as well, for writing purposes, primarily because entity
beans were easily generated using the IDE.
DAOs for reading perform well since they can release database connections quickly.
Also DAOs allow you to perform order-by operations on queries, which you can’t do with
entity beans in the current EJB specification’s query language. This ordering helps in sorting data to be presented in the user interface. By way of comparison, the MDA team
used entity beans to go directly to the database and didn’t use the “JDBC for reading”
pattern or DAOs. They sorted data by pushing them into special Java classes called Form
Beans and then wrote a routine to sort them. Thus, both teams achieved the same result
in different ways.
Xavier Moghrabi
58

L`approche Model-Driven Architecture, crédible pour développer un

Transcription

Documents pareils

télécharger en pdf

R O T A R Y C L U B D E N I C E

www.poles-ressources

S´EMINAIRE du GROUPE TH´EORIE Etude des états

Coordinateur administratif MDA 49

magen david adom

R O T A R Y C L U B D E N I C E

Ingénieur Java/J2EE

La lettre d`informations de la Maison des Associations du 3ème