de l’approche Model-Driven Architecture et
des méthodes de conduite de projet
Martin Fowler20 :
You should use iterative development only on projects that you want to succeed (Larman, 2002b).
Le chapitre précédent présentait les méthodes et formalismes pour la conception des Systèmes d’Information Géographique et comparait la capacité d’expression de ces méthodes et formalismes. Cette étude bibliographique s’intégrait dans objectif élémentaire de réaliser un outil d’aide à la conception de Systèmes d’Information Géographique.
La capitalisation des connaissances étant un autre objectif élémentaire de la recherche, nous nous sommes intéressés aux idées de séparation de spécifications préconisées par l’approche Model Driven Architecture. L’approche MDA présentant certaines insuffisances, nous avons cherché une solution dans les méthodes de conduite de projet qui organise le développement d’une application.
Le présent chapitre est donc consacré à l’étude bibliographique de l’approche MDA et d’un certain nombre de méthodes de conduite de projet.
Le paragraphe I décrit les concepts majeurs de l’approche MDA, présente un panorama succinct des recherches en cours et une étude comparative du développement d’une application suivant un processus traditionnel et suivant l’approche MDA.
Le paragraphe II présente les premières méthodes de conduite de projet mise en œuvre pour le développement d’applications informatiques et quelques unes des méthodes récentes qui ont alimentées notre réflexion.
Le paragraphe III conclut ce chapitre en présentant les points que nous avons cherchés à résoudre dans ce travail de recherche.
Sommaire détaillé
I Approche Model Driven Architecture (MDA™)... 40
I.1 Généralités ... 40 I.2 Description ... 40 I.3 Panorama succinct des recherches en cours ... 41 I.4 Comparaison d’un processus de développement traditionnel et d’un processus de développement appliquant l’approche MDA... 44II Méthodes de conduite de projet : Panorama succinct ... 45
II.1 Les méthodes traditionnelles ... 45 II.1.1 Cycle en cascade - Cycle en V ... 45 II.1.2 Cycle en spirale ... 46 II.1.3 Méthode Rapid Application Development (RAD) (Extrait de l’Annexe II-I) ... 47 II.1.4 Méthode Processus Unifié (UP) (Extrait de l’Annexe II-II)... 48 II.1.5 Méthode 2 Track Unified Process (2TUP) ... 51 II.2 Les méthodes agiles ... 52 II.2.1 Généralités ... 52 II.2.2 Méthode eXtreme Programming (XP) (Extrait de l’Annexe II-III)... 53
III Conclusion ... 54
III.1 Approche MDA ... 54 III.2 Méthode de conduite de projet... 55
I
APPROCHE MODEL DRIVEN ARCHITECTURE (MDA™)
I.1Généralités
En 2001, l'Object Management Group (OMG) a formalisé un ensemble de préconisations dans l’objectif de résoudre les problèmes de productivité, de portabilité, d'intégration et d’interopérabilité rencontrés au cours du développement des applications informatiques (Kleppe et al., 2003). Ces préconisations doivent aussi faciliter le développement d’applications en remobilisant les connaissances métiers et/ou techniques existantes.
De ces réflexions est issue l’approche Model Driven Architecture qui fixe le cadre d’utilisation des modèles lors du développement d’une application (Miller et al., 2001). Le respect des préconisations de cette approche doit faciliter le développement, la maintenance et l’évolution de toute nouvelle application mais aussi minimiser l’impact de l’évolution des plates-formes matérielles et/ou logicielles.
En 2003, un guide de la démarche MDA est édité par l’OMG (Miller et al., 2003). Ce document décrit comment mettre en œuvre l’approche MDA et introduit quelques nouveaux concepts.
Afin de promouvoir l’approche MDA, l’OMG prône qu’un développement effectué suivant cette approche permet de réaliser des gains de productivité.
I.2Description
L’approche MDA préconise la séparation des spécifications métiers propre à un domaine de celles d’implémentation. Pour réaliser cette séparation, l’approche MDA propose de mettre en œuvre deux types de modèles (cf. figure 24) :
Les modèles indépendants des plates-formes (modèle PIM21). Les modèles spécifiques à une plate-forme (modèle PSM22).Ces modèles constituent une architecture. D’après la figure 24, les modèles PIM et PSM peuvent être décrits avec un ou plusieurs métamodèles.
<<Independant of>>
Infrastructure <<depends on>>
<<based on>>
PIM Mapping Technique
PSM Mapping Technique
Refactoring from PSM to PIM Mapping from PIM to PSM
1..*
1..*
PIM
1..* Mapping from PIM to PIM
PSM 1..* Mapping from PSM to PSM Metamodel 1..* 1..* 1..* 1..* <<based on>>
<<are described with>>
<<are described with>> <<Independant of>>
Infrastructure Infrastructure <<depends on>>
<<based on>>
PIM Mapping Technique
PSM Mapping Technique
Refactoring from PSM to PIM Mapping from PIM to PSM
1..*
1..*
PIM
1..* Mapping from PIM to PIM
PSM 1..* Mapping from PSM to PSM Metamodel 1..* 1..* 1..* 1..* <<based on>>
<<are described with>> <<are described with>>
<<based on>>
PIM Mapping Technique PIM Mapping Technique
PSM Mapping Technique PSM Mapping Technique
Refactoring from PSM to PIM Mapping from PIM to PSM
1..*
1..*
PIM
1..* Mapping from PIM to PIM
PSM
1..* Mapping from PSM to PSM
Refactoring from PSM to PIM Mapping from PIM to PSM
1..*
1..*
PIM
1..* Mapping from PIM to PIM
PIM PIM PIM PIM
1..* Mapping from PIM to PIM
PSM 1..* Mapping from PSM to PSM PSM PSM PSM 1..* Mapping from PSM to PSM Metamodel 1..* 1..* 1..* 1..* Metamodel Metamodel Metamodel 1..* 1..* 1..* 1..* <<based on>>
<<are described with>> <<are described with>>
Figure 24Extrait du métamodèle de l’approche MDA (Miller et al., 2001).
En 2003, un nouveau type de modèle a été défini et ajouté à l’architecture MDA afin de combler le fossé existant entre les experts du domaine thématique et les experts de la conception et de la construction de l’application (Miller et al., 2003). Cette nouvelle typologie de modèles est appelée modèle indépendant de la programmation (Blanc, 2005) plus couramment qualifiée CIM23. Selon Xavier blanc, les modèles CIM sont destinés à décrire les exigences des acteurs du domaine.
Une caractéristique importante du modèle CIM est que le vocabulaire familier des acteurs du domaine est utilisé pour sa spécification (Miller et al., 2003). En outre, il est explicitement mentionné dans ce guide que ce modèle est utile, non seulement comme aide à la compréhension du problème, mais aussi comme source de vocabulaire partagé à utiliser dans d’autres modèles. Dans la communauté base de données, le dictionnaire de données joue le rôle de source de vocabulaire du modèle CIM.
L’approche MDA introduit aussi la notion de transformation de modèles qui permet de faire évoluer les modèles au cours du développement. Formellement les transformations peuvent être manuelles ou automatiques (Miller et al., 2001, 2003). Cependant, les recherches actuelles sont principalement axées sur l’automatisation des transformations afin d’augmenter la productivité du développement.
La figure 24 met aussi en exergue l’existence de transformations dont le modèle source est du même type24 que le modèle issu de la transformation. Ces transformations sont appelées transformations PIM/PIM ou PSM/PSM. Cette même figure montre qu’il y a aussi des transformations dont les modèles avant et après transformation sont de types différents. Ce sont les transformations qualifiées de PIM/PSM ou PSM/PIM.
Il faut signaler que le métamodèle de la figure 24 fait apparaître un autre intérêt important de l’approche MDA qui est de pouvoir dériver plusieurs modèles PSM d’un même modèle PIM grâce à plusieurs transformations PIM/PSM.
I.3Panorama succinct des recherches en cours
Dans l’approche MDA, les transformations étant l’objet technique permettant l’évolution automatique des modèles, l’effort de recherche depuis la formalisation de l’approche MDA a été concentré sur cet objet technique. Les recherches portent plus spécialement sur la conception de langages de transformation. Les
22 PSM : Platform Specific Model 23
Computation Independent Model
tableaux 2 et 3 donnent un aperçu du nombre de langages actuellement étudiés et dont certains ont été implémentés.
Tableau 2Langages et outils de transformation (extrait (Grønmo et al., 2005)).
Tableau 3Propositions OMG (extrait (Grønmo et al., 2005)).
Percevant l’importance stratégique, l’OMG a cherché à « unifier » les langages de transformation en lançant un l'appel à proposition en 2002 (OMG, 2002b). L’objectif suivi par l’OMG est, comme pour le langage UML, de définir un langage de transformation de modèles adopté par la majorité de la communauté informatique. Cet appel d’offre a suscité un grand intérêt puisque sept propositions ont été soumises (Belaunde, 2004 ; Belaunde et
al., 2004). L’une d’entre-elles est issue d’un consortium25, d’industriels et universitaires français, appelé OpenQVT.
L’union européenne a pris toute la mesure de l’importance stratégique des recherches autour de l’approche MDA. Aussi, afin de soutenir le secteur informatique considéré comme vital pour l’économie européenne, la Commission Européenne a fiancé le projet intégré ModeLWare (European Commission, Non daté). Le but était, pour la Commission Européenne, de soutenir la compétitivité et l’innovation du secteur informatique.
L’objectif principal du projet ModeLWare était de développer une solution basée sur l’Ingénierie Dirigé par les Modèles permettant d’augmenter de 15 à 20 % la productivité du développement logiciel. Ce projet avait aussi comme objectifs secondaires d’une part, d’aboutir à une solution industrielle et, dautre part, de garantir l’adoption de cette solution par l’industrie. Le consortium était constitué de 19 partenaires industriels et universitaires.
L’un des principaux résultats de ce projet est la conception et l’implémentation de la plate-forme MODELWARE Open MDD. Elle est destinée à assurer un service d’interopérabilité entre ateliers de génie logiciel, outils de langages de transformations, etc. Le schéma de la figure 25 présente une vue d’ensemble de cette plate-forme.
Le service d’interopérabilité s’appuie sur un modèle pivot appelé ModelBus qui assure l’interconnexion des plates-formes informatiques. Pour ce faire, des adaptateurs entre le langage de la plate-forme et le langage pivot ModelBus ont été conçus et développés.
Enfin au niveau français, les recherches autour de l’approche MDA sont soutenues par les pouvoirs publics au travers de :
Soit des actions spécifiques comme l’AS MDA, Action Spécifique du CNRS sur l’Ingénierie Dirigée par les Modèles. Soit au travers de projets RNTL : ACCORD (Carrez, 2003), MoDAthéque (2004-2005), ModeFact, etc. L’AS MDA a permis de mettre en place un dispositif de veille technologique et de travaux de recherche (Bézivin et al., 2005) regroupant sept organismes de recherche français. L’un des objectifs des coordinateurs de cette AS étaient de ne pas se limiter à des avancées technologiques guidées par l'OMG, mais au contraire s’élargir pour tenter d'établir une synergie entre les travaux de recherche présents et passés manipulant eux aussi des modèles (Bézivin et al., 2005).Figure 25Vue générale de la plate-forme MODELWARE Open MDD (extrait (European
Commission, Non daté)).
25
Partenaires industriels : France Télécom, Thalès, Softeam et TNI-Valiosys – Partenaires universitaires : INRIA, LIP6 et LIFL (Belaunde
Ce groupe a rédigé un rapport faisant la synthèse des réflexions suscitées par l’approche MDA, rapport structuré en plusieurs chapitres. Chacun des chapitres traite d’une thématique particulière de l’Ingénierie Dirigée par les Modèles (Bézivin et al., 2005 ; Blay-Fornarino et al., 2005 ; Bouzeghoub, 2005 ; Favre et al., 2005 ; Gérard et al., 2005 ; Jézéquel et al., 2005 ; Marvie et al., 2005).
Les principaux langages de transformation de modèles actuellement développés par la recherche française sont : ATL26, MTL27 et TRL28. Le premier est un langage développé par l’équipe de recherche ATLAS qui implique l’INRIA, l’université de Nantes et TNI-Software. Ce langage permet la « manipulation » de métadonnées et la transformation de modèles en s’appuyant sur une technique de tissage (Bézivin et al., 2003 ; Jouault et al., 2006). Le deuxième est un langage développé par l’équipe TRISKELL regroupant le CNRS, l'Université Rennes I, l'INRIA et l'INSA de Rennes. C’est un langage permettant l’écriture de programmes de transformations de modèles. Grâce à ce langage, les transformations peuvent être décrites dans un métamodèle pivot (Macedo de Amorim, 2004 ; Silaghi et al., 2004). Le troisième est une contribution à l’effort de standardisation des langages de transformations (QVT Project, Non Daté ; Sriplakich, 2003).
Ce rapide panorama des travaux internationaux de standardisation, des projets de recherche européens et français autour de l’approche MDA montre d’une part, l’intérêt de la communauté scientifique française pour ces thèmes et, d’autre part, l’importance stratégique et économique des transformations de modèle et des langages permettant de les écrire.
I.4Comparaison d’un processus de développement traditionnel et d’un processus de
développement appliquant l’approche MDA
Afin de confirmer ou démentir les allégations de l’OMG concernant le gain de productivité attendu avec l’approche MDA (cf. I.1), la société américaine Compuware Corporation a demandé au cabinet de conseil The Middleware Company de faire une étude comparative pour vérifier ces affirmations (The Middleware Company, 2003).
Pour ce faire, le cabinet conseil a demandé à deux équipes de niveau de compétences équivalent de développer une application de commerce électronique d'animaux domestiques PetStore : la première en mettant en œuvre un processus de développement traditionnel et la seconde en utilisant l’approche MDA. Le cahier des charges transmis aux deux équipes était le même. Le tableau 4 montre les durées planifiées et réalisées par ces équipes.
Durée
Équipe Planifiée Réalisée
Traditionnelle 499 h 507 h
MDA 442 h -11% 330 h -35%
Tableau 4Comparaison du processus de développement traditionnel / approche MDA.
Les résultats parlent d’eux mêmes. Initialement évalué à 11%, le gain de productivité de l’équipe MDA a
été triplé. Selon l’un des programmeurs de l’équipe MDA, ce gain aurait pu être plus élevé car le temps de la
réalisation aurait pu être réduit de 10 à 20 %. En effet, au démarrage du projet l’équipe MDA n’avait aucune expérience de cette approche et a dû, dans un premier temps, se former aux principes et acquérir la maîtrise des outils MDA.
Un autre résultat ressort de cette étude : l’équipe traditionnelle, tout au long du développement, a été
amenée à corriger des bogues alors que l’équipe MDA n’a pas eu ce problème. Les analystes du cabinet
conseil encadrant l’étude attribuent cette absence de bogue à l’utilisation intensive de la génération
automatique de code.
26 ATLAS Transformation Language
27
Model transformation language
II
METHODES DE CONDUITE DE PROJET :PANORAMA SUCCINCT
Lorsque les trois amigos, Grady Booch, James Rumbaugh et Ivar Jacobson, ont conçu le langage UML, ils ont délibérément distingué le langage de modélisation de la méthode permettant de mener à bien le projet de développement d'une application (Fayet, 2002) afin de laisser libre chaque concepteur d’adopter la méthode la plus adaptée à son environnement professionnel.
Actuellement, il existe de nombreuses méthodes de conduite de projet qui sont classées en deux grandes familles : les méthodes dites traditionnelles et les méthodes agiles.
II.1Les méthodes traditionnelles
Les méthodes traditionnelles dérivent le plus souvent des méthodes de gestion de projet éprouvées en ingénierie industrielle ou dans le secteur du Bâtiment et des Travaux Public (Larman, 2002a). Il existe une multitude de méthodes traditionnelles pour développer une application informatique mais la plupart reposent sur quelques méthodes de référence :
Cycle en cascade et cycle en V. Cycle en spirale. RAD (Rapid Application Development). UP (Unified Process).Dans les paragraphes suivants, nous allons décrire quelques caractéristiques intéressantes de ces méthodes dont nous avons besoin pour la compréhension de notre contribution. Nous avons aussi décrit la méthode 2TUP qui est une méthode dérivée de la méthode Processus Unifié dont certains aspects rappellent l’approche MDA.
II.1.1Cycle en cascade - Cycle en V
Ce ne sont pas des méthodes de conduite de projet au sens défini par (Jacobson et al., 1999) car seul le cycle du processus de développement est décrit. La gestion du projet, la composition de l’équipe, le rôle des membres au sein de l’équipe, les relations entre l’équipe et le client, etc. ne sont pas pris en compte. Bien que très anciens, ces cycles de développement sont toujours utilisés car ils sont simples à mettre en œuvre dans des projets de taille modeste.
Le cycle de développement en cascade a été formalisé par Winston Royce en 1970 (Royce, 1970). Le processus de développement est linéaire au cours du temps comme peut l’être la construction du gros œuvre d’une maison où les fondations sont coulées avant de monter les murs et de poser la toiture. Selon Winston Royce, l’analyse et le codage sont deux phases incontournables qu’elle que soit la taille de l’application à développer. Elles constituent le cœur du processus de développement. Les autres phases deviennent indispensables lorsque la taille de l’application devient conséquente.
Selon ce cycle, les phases de développement se succèdent l’une après l’autre (cf. figure 26) sans aucun mécanisme formel de rétroaction pour prendre en compte l’évolution des besoins des utilisateurs (Guimond, 2005). Program Design Coding Testing Analysis System Requirements Software Requirements Operations Program Design Coding Testing Analysis System Requirements Software Requirements Operations
L’inconvénient majeur lié à ce cycle est que la totalité de l’analyse est effectuée au début du projet et qu’ensuite le développement est réalisé étape après étape jusqu’à la livraison de l’application et ce sans aucune validation intermédiaire de la part des acteurs. Le risque sous-jacent est que l’analyse peut être accomplie de façon approximative ou imparfaite. Les développeurs sont alors en possession d’informations ou de consignes incomplètes ou erronées qui vont êtres utilisées au cours du développement. L’application a alors de fortes chances de dériver et de ne plus correspondre aux attentes des acteurs.
Cette situation n’est pas un cas d’école puisque, dans 49% des développements, l’application finale ne correspond pas aux attentes les acteurs ou ne répond pas aux besoins exprimés par ces derniers (cf. Introduction- II).
Selon (Muller et al., 2000), le cycle en V est une représentation différente du cycle en cascade qui permet d’exprimer le fait que le développement des tests et le développement du logiciel sont effectués de manière synchrone. Tests fonctionnels Tests d’intégration Tests unitaires Codage Analyse Conception Validé par Application Tests fonctionnels Tests d’intégration Tests unitaires Codage Analyse Conception Tests fonctionnels Tests d’intégration Tests unitaires Tests fonctionnels Tests d’intégration Tests unitaires Codage Analyse Conception Codage Analyse Conception Validé par Application
Figure 27Cycle de développement en V (Muller et al., 2000).
Ces deux cycles de développement sont les plus connus car historiquement ceux sont les premiers à avoir été utilisés pour le développement d’applications conséquentes. Ils sont également connus car les méthodes traditionnelles conçues à postériori avaient pour but essentiel de résoudre les inconvénients inhérents à ces cycles.
II.1.2Cycle en spirale
Le cycle de développement en spirale a été introduite par Barry Boehm en 1988 (Boehm, 1988). L’objectif visé en adoptant le cycle en spirale (cf. figure 28) était de diriger le développement par les risques et non plus par la documentation ou le code comme c'était le cas jusqu'alors.Avec ce cycle, Barry Boehm adoptait le concept de modèle évolutif de (McCracken et al., 1982) et proposait un processus en quatre itérations nommées Round. Ce cycle se caractérise par une succession de quatre phases :
La définition des objectifs ainsi que l’identification des alternatives d’implémentation possibles et des contraintes. L’évaluation des risques induits par l’alternative d’implémentation. Le prototypage est un des moyens d’évaluation possible. La conception et le développement incluant au dernier Round les tests unitaires, d’intégration et fonctionnels. La validation du produit de la phase par les acteurs du domaine et la planification du Round suivant. L’année suivante, (Boehm et al., 1989) proposaient une théorie de gestion du développement des applications informatiques. Cette théorie, appelée Théorie-W, avait pour objectif que tous les partenaires d’un projet soient gagnants.La fusion du cycle en spirale et de la Théorie-W ne sera effective qu’en 1994 (B. W. Boehm et al., 1994). La méthode Next Generation Process Model (NGPR) issue de cette fusion est présentée comme une extension au cycle de développement en spirale. La méthode NGPR sera affinée en 1998 et renommée WinWin Spiral Model (Boehm et al., 1998).
Le but poursuivit par Barry Boehm avec ces travaux de recherche était de maximiser le degré de satisfaction de l'ensemble des acteurs impliqués dans un projet de développement et en particulier de prendre en compte les exigences des acteurs.
Figure 28Cycle de développement en spirale (extrait (Boehm, 1988)).
II.1.3Méthode Rapid Application Development (RAD) (Extrait de l’Annexe II-I)
Le fondateur de cette méthode est James Martin auteur de nombreux ouvrages dont celui portant le même