Rubriques

Introduction Haut de la page

Dans RUP, nombre d'artefacts sont considérés comme des modèles, définis comme abstractions ou descriptions de systèmes à partir de perspectives spécifiques ; la construction de modèles, en particulier de modèles visuels, constitue également une pratique recommandée dans RUP (voir Pratique recommandée : Modélisation visuelle (UML)). Cependant, même si RUP identifie de nombreux modèles et décrit comment (en tant qu'éléments d'entrée et de sortie) ceux-ci jouent un rôle de médiateur entre les activités, il ne recommande aucune forme précise de modèle (excepté via une notation) et ne requiert aucune méthode particulière en ce qui concerne la transformation des modèles. Il est donc possible d'instancier et de déployer RUP dans le cadre d'un développement de logiciel de telle sorte qu'une fois générés, les modèles servent uniquement de mécanismes de découverte, de documentation et de communication et n'influent sur le code développé que sur l'intervention de développeurs humains.

Le développement dirigé par modèle (Model-Driven Development ou MDD) implique un niveau d'abstraction supérieur. Cette approche exige une certaine rigueur dans la description des modèles et ne conçoit pas simplement ces derniers comme des artefacts de développement intermédiaire, mais plutôt comme des descriptions précises à partir desquelles des systèmes opérationnels peuvent être générés. Le MDD repose évidemment sur des outils plus perfectionnés et propose un éventail de possibilités allant de la production de canevas à la création d'un code complet.

L'architecture dirigée par modèle (Model-Driven Architecture® ou MDA®) est une initiative du groupe OMG (Object Management Group) qui décrit un cadre complet pour la diffusion du MDD. Fondée sur les travaux de standardisation effectués par le passé, tels que les standards UML ou MOF, la MDA introduit une terminologie et des concepts spécifiques, et définit une approche du processus de transformation rigoureuse liée au développement de logiciels ainsi qu'une base pour l'automatisation au moyen d'outils.

Développement dirigé par modèle (MDD) Haut de page

Modèles et modélisationHaut de page

Dans Rational Unified Process, les modèles constituent une catégorie d'artefacts importante et sont généralement exprimés par le biais du langage UML et de façon neutre en termes d'environnement et d'outils, de sorte que RUP puisse être déployé et diffusé avec plusieurs jeux d'outils et dans divers environnements. La rubrique "Pratique recommandée : Modélisation visuelle" justifie le recours à la modélisation en soulignant notamment les points suivants :

  • elle contribue à une meilleure compréhension des systèmes complexes ;
  • elle permet de rechercher et de comparer à moindre coût les alternatives de conception ;
  • elle fournit une base pour l'implémentation ;
  • elle permet d'identifier précisément les exigences ;
  • elle permet de communiquer les décisions sans ambiguïté.

Les modèles sont considérés comme un instrument de réflexion sur le comportement (souhaité ou réalisé) et la structure des systèmes, et comme une moyen de communiquer les résultats de ces délibérations aux parties prenantes concernées. Le MDD met en évidence le rôle des modèles en tant qu'éléments fondamentaux de l'implémentation, dans le but d'en faire bien plus que des plans sur lesquels les développeurs s'appuient pour écrire les codes, mais des éléments pouvant être déployés et exécutés à un niveau défini par les capacités des outils de support. Cette démarche s'inscrit dans une tendance de longue date visant à élever le niveau d'abstraction auquel les développeurs travaillent. Ceci met non plus l'accent sur le code tel que nous le connaissons, mais sur les modèles exprimés dans un langage plus élaboré, voire graphique.

RUP, en identifiant certains artefacts comme des modèles et non comme des documents contenant des images de modèles (identifiant les exigences et la conception, par exemple) soutient implicitement cette approche.

Points de vue et vuesDébut de page

Un point de vue, comme son nom l'indique, renvoie à un position imaginaire d'où sont visibles certains aspects ou problèmes liés au système (ou aux modèles représentant le système), supposant l'application d'une série de concepts et de règles pour créer un filtre conceptuel. Le terme "perspective" est également employé et décrit la façon de voir et de comprendre les modèles qui répondent le mieux aux nombreuses orientations et difficultés des diverses parties prenantes.

Les vues sont des projections de modèles qui mettent en évidence les entités les plus significatives à partir d'une perspective ou d'un point de vue donné.

Dans le MDD, les points de vue et les vues permettent de cloisonner les problèmes, par exemple de traiter la structure logique indépendamment de la structure physique et de la structure de processus. Plus les modèles sont proches du domaine, plus les perspectives correspondent étroitement aux préoccupations des parties prenantes ; plus le développement des modèles progresse vers une exécutable, plus les problèmes informatiques entrent en ligne de compte. Dans les deux cas, l'objectif n'est pas de produire de simples illustrations passives mais des modèles qui puissent générer, au moins potentiellement, des implémentations permettant de répondre à ces problèmes distincts.

Elaboration et translation (transformation) Début de page

Ces deux termes sont souvent employés de façon informelle pour faire la distinction entre les modifications de modèles effectuées manuellement (élaboration) et celles réalisées par le biais d'un outil (translation). Dans RUP, le terme "élaboration" a une signification formelle relativement différente puisqu'il correspond au nom d'une phase du cycle de vie. Cependant, dans cette section, nous l'emploierons dans son acception générale pour illustrer les approches visiblement divergentes de l'évolution des modèles.

Les termes "translation" et "élaboration" impliquent également des étapes de longueur différente, par exemple, un modèle est élaboré en plusieurs petites étapes jusqu'à ce qu'il contienne suffisamment de détails (relatifs au langage, à l'infrastructure ou au système d'exploitation) pour qu'un code puisse être généré, manuellement ou au moyen d'un outils. "Manuellement" signifie qu'un être humain peut consulter le modèle et écrire un code en langage Java, C++ ou autre, et éventuellement l'élaborer davantage au cours du processus. En revanche, dans une translation, le modèle (qui se situe toujours à un niveau d'abstraction non entaché par les questions liées au langage, à l'infrastructure, ou aux systèmes d'exploitation) est transformé puis s'exécute et produit le résultat escompté sans aucune élaboration supplémentaire (ou du moins une élaboration minime). Il convient de noter que ces résultats incluent la performance et d'autres caractéristiques non-fonctionnelles. Cette approche suppose donc implicitement que les questions architecturales d'ordre général sont traitées en fonction de la façon dont le modèle est construit et dont les exigences des ressources sont décrites.

Un autre terme, "transformation", est couramment employé pour décrire le processus de génération d'un modèle cible à partir d'un modèle source en fonction d'un ensemble de règles et de paramètres. Il faut souligner toutefois que nous entendons ici le mot ""modèle"" tel qu'il est usité dans RUP, autrement dit le modèle cible peut renvoyer à des éléments d'implémentation, par exemple du code ou du texte. Bien entendu, la transformation peut être réalisée manuellement. Le cas échéant, les transformations successives (ajout de détails) s'apparentent à une élaboration. En outre, les règles applicables peuvent s'avérer très complexes et reposer sur une solide expérience de la technologie et du domaine concernés. Au sens strict, une transformation suppose cependant d'être réalisée automatiquement. Cette question est abordée dans la prochaine section, consacrée à l'architecture dirigée par modèle (Model-Driven Architecture®).

L'idée de transformation implique uniquement un modèle source et un modèle cible. En règle générale, le modèle cible est moins abstrait que le modèle source, autrement dit la cible est un peu plus spécifique que la source, néanmoins ceci n'est pas implicite dans la notion de transformation. La transformation permet aussi d'inclure des détails supplémentaires dans un modèle, créant ainsi un modèle cible plus affiné, bien que globalement situé au même niveau d'abstraction dans la mesure où aucune information associée à un autre domaine n'est introduite. Nous pouvons comparer ceci à une transformation produisant un code à partir d'un modèle UML, dans le cadre de laquelle de nombreux éléments ne concernant pas les parties prenantes métier sont introduits, à condition que le comportement requis et les caractéristiques non fonctionnelles soient maintenues.

La capacité à obtenir la translation idéale dépend du potentiel de l'outil et de la capacité à codifier, capturer et réutiliser les connaissances auxquelles fait appel un être humain expérimenté. Le volume de connaissances qui doit être capturé et codifié dépend du niveau d'abstraction auquel intervient l'étape de la translation : en général, plus le niveau est élevé, plus le volume de connaissances et le degré de dépendance envers le domaine sont importants.

Dans le MDD, l'objectif est d'élever le niveau d'abstraction auquel il est possible de générer automatiquement un système opérationnel. Un modèle est élaboré jusqu'à ce qu'il permette une génération, aussi, il est nettement préférable que le résultat d'une élaboration ne nécessite aucune élaboration supplémentaire et puisse être exécuté. Un autre challenge consiste à réaliser, autant que faire ce peut, cette élaboration via plusieurs transformations automatiques successives. En ce sens, les deux approches convergent : la translation est elle-même le résultat d'une succession d'étapes de transformation (automatiques dans la mesure du possible). L'ultime transformation en système d'exécution intervient à un niveau d'abstraction élevé, avec la description du modèle, l'encodage des sélections liées à la technologie, à l'infrastructure et au langage cibles dans le moteur de transformation, et la soumission des règles et des données à ce moteur.

Grâce au MDD, on peut espérer pouvoir réutiliser les transformations, notamment en permettant le codage des connaissances relatives aux plateformes et aux domaines et des pratiques recommandées, via des créations réalisées par des spécialistes dans les domaines correspondants. Cette pratique permettrait à des développeurs moins expérimentés de réutiliser facilement le travail effectué, et éviterait de reprendre la création du début à chaque nouveau développement d'application.

Définition d'un niveau d'abstraction élevéDébut de page

Ce concept peut être abordé dans divers contextes ; tout d'abord, du point de vue du spectre du langage : nous assistons à l'émergence de formes de langage UML exécutables, par exemple. On peut également retrouver cette notion dans le cadre de l'ingénierie de domaines, où les concepts de langage et de modélisation peuvent être spécifiques à un domaine donné. Par exemple, UML est un langage général en complément duquel sont proposés des profils UML permettant une utilisation plus spécialisée de l'UML. Enfin, l'idée de niveau d'abstraction élevé peut aussi être liée à la nécessité d'éviter les modèles spécifiques au fournisseur ou à l'infrastructure afin de rester ouvert aux autres technologies.

En termes d'expression des dynamiques détaillées, le travail réalisé sur UML Action Semantics a fait des formes exécutables du langage d'UML une possibilité, mais aucune syntaxe ni aucune notation concrète n'est encore standardisée et le niveau d'Action Semantics reste équivalent aux autres langages orientés objets. Ainsi, l'association de l'UML et d'Action Semantics ne constitue certainement pas une fin en soit, mais elle indique au moins la direction dans laquelle les choses tendent.

Nous en concluons donc qu'un modèle exprimé en langage UML, ou par le biais d'un profil UML, ne contenant aucun élément spécifique au fournisseur, indépendant de toute plateforme d'infrastructure particulière (comme J2EE ou Microsoft® .NET), présentant une sémantique complète du point de vue de la structure et du comportement et ne faisant appel à aucun langage procédural spécifique (tel que Java ou C#) se situe à un niveau d'abstraction élevé par définition, même si la question du niveau d'Action Semantics reste posée.

Du point de vue du domaine, c'est-à-dire de l'utilisateur ou du client, la formulation de langages de modélisation spécifiques au domaine peut représenter une solution potentielle attrayante. Il s'agit de langages abstraits (en ce sens qu'ils incluent des termes et des concepts avec lesquels les personnes travaillant dans le domaine concerné sont familiarisés), mais complets du point de vue de leur capacité à exprimer les dynamiques de modélisation, et toujours basés sur le langage UML.

Rapport avec RUP Début de page

La relation existant entre les modèles d'implémentation, de conception et d'analyse RUP illustrent les notions suivantes : les modèles d'analyse constituent une vue préliminaire de la façon dont le comportement exprimé dans les cas d'utilisation va être réalisé ; ils sont naturellement orientés vers le domaine du problème à traiter, et les classes d'analyse qu'ils comprennent sont considérées comme des regroupements conceptuels des responsabilités et des comportements requis. Les modèles d'analyse sont en général trop incomplets pour être exécutés (excepté peut-être dans le cadre d'une expérience impliquant un être humain qui lirait et compléterait le modèle) car ils comportent trop d'éléments non spécifiés. En revanche, les modèles d'analyse doivent être soumis à un processus d'affinage permettant d'ajouter des détails et débouchant sur les modèles de conception.

RUP autorise les projets à gérer des modèles d'analyse distincts ou à considérer ces modèles d'analyse comme des éléments pouvant évoluer au sein des modèles de conception. Le processus d'affinage est décrit de façon relativement détaillée dans les activités RUP, sur la base de l'hypothèse selon laquelle les architectes logiciels et les concepteurs mènent à bien le processus d'évolution avec l'aide considérable d'outils. Notons que l'affinage peut être considéré comme une série de transformations de modèle, dont certaines peuvent être automatiques, par exemple dans le cadre de l'application de patterns d'analyse et de conception dans les activités RUP Analyse de l'architecture et Identification des mécanismes de conception.

Définition du stade d'achèvement d'un modèle de conception Début de page

Le modèle de conception évolue tout au long du cycle de vie du projet par le biais d'itérations multiples ; aussi la question est de déterminer à quel stade le modèle de conception (où une partie de celui-ci) peut être changé en code, autrement dit de savoir à quel moment il est possible de produire des éléments d'implémentation et de les intégrer dans les constructions intéressantes du système. RUP met à votre disposition quelques indications à ce sujet dans la rubrique Mappage conception-code mais il n'existe fondamentalement aucune réponse claire et définitive à cette question. Vous passez à la phase d'implémentation, dès lors que vous jugez que vous en avez la possibilité (à l'issue d'une révision, par exemple) ; ceci peut sensiblement varier en fonction des organisations et des projets. RUP propose un ensemble de méthodes permettant de passer de la conception au code. Nous détaillerons ici deux d'entre elles afin d'illustrer le processus décisionnel relatif à l'aboutissement de la conception :

1. Esquisse et code
Dans RUP, "une approche courante de la conception consiste à faire l'esquisse de la conception à un niveau relativement abstrait, et à passer ensuite directement au code. La gestion du modèle de conception s'effectue manuellement."

Pour que cette approche soit efficace, le développeur doit être capable de combler les écarts d'abstraction entre la conception et l'implémentation. La maintenance du modèle de conception est souvent recalée au second plan alors que le code devient la préoccupation centrale.

2. Ingénierie aller-retour avec évolution d'un seul modèle de conception
Selon RUP : "Dans cette approche, un seul modèle de conception est utilisé. Les premières esquisses des éléments de conception évoluent jusqu'à ce que ces derniers puissent être synchronisés avec le code."

Dans ce cas, les développeurs comblent l'écart d'abstraction via une série de phases de modélisation. La différence entre cette approche et la méthode "esquisse-code" réside dans le fait que les étapes intermédiaires sont évidentes et que la version abstraite du modèle de conception disparaît à terme.

Dans les deux hypothèses, il y a perte de la valeur potentielle du modèle de conception abstrait : dans l'approche "esquisse-code" le modèle de conception abstrait n'est généralement pas maintenu et s'éloigne au fur et à mesure du code ; dans l'approche "évolution d'un modèle de conception unique" la version abstraite disparaît. Même si une version initiale est conservée, celle-ci évolue généralement de la même manière que les modèles de conception traités dans une approche esquisse-code. Il convient de noter que, dans le cadre d'une ingénierie aller-retour, le stade final d'un modèle de conception est véritablement la visualisation du code ; dans une approche esquisse-code, cette visualisation peut également être obtenue au moyen d'une rétro-ingénierie du code produit, à condition de disposer des outils appropriés. Dans RUP, la perte du modèle de conception abstrait est atténuée, dans une certaine mesure, par la capture de vues d'architecture pertinentes et de justifications de conception à des points critiques dans le document d'architecture logicielle.

Le MDD permet d'espérer que les modèles de conception abstraits sont en passe de devenir fondamentaux en termes de génération de code et qu'un bel avenir s'ouvre à eux. Le MDD devient la principale base de maintenance et pourrait bien, en fait, se transformer en l'unique base de maintenance. Cette technologie propose également une définition claire du point final de la conception, c'est-à-dire le stade auquel, du point de vue du moteur de transformation, le modèle est considéré comme terminé, cohérent et sans ambiguïté et est en mesure d'être converti en système exécutable. Le niveau d'abstraction du modèle dépend de la technologie et des outils disponibles (voir l'exemple proposé dans la rubrique Visite guidée : Présentation de Rational Software Architect) et peut également varier en fonction du domaine. En ce qui concerne le MDD, il s'agit d'une simple transformation (de la conception vers le code) qui constitue néanmoins une étape importante permettant de dépasser les niveaux d'abstraction.

La section suivante traite d'un nouveau cadre d'application standard destiné au MDD, une initiative de l'Object Management Group (groupe OMG) : l'architecture dirigée par modèle (Model-Driven Architecture® - MDA®).

Architecture dirigée par modèle (MDA) Début de page

Motivation Début de page

La MDA est une initiative du groupe OMG, un consortium industriel qui comprend 800 membres et dont la mission est de définir des spécifications et des recommandations standard visant à établir un cadre de neutre pour le développement d'applications. Ce groupe encourage en outre l'interopérabilité entre les principales plateformes d'infrastructure matérielle et logicielle. Le langage UML est un produit du groupe OMG. Ce dernier promeut actuellement la MDA comme sa spécification phare. Au vu du rôle de l'OMG dans la promulgation des standards pratiques destinés à être pris en charge aux divers niveaux de l'industrie informatique (IC, pratiques, produits et outils) et du succès du langage UML, l'architecture MDA mérite d'être étudiée. Il existe de nombreuses ressources documentaires sur MDA, notamment le guide le plus récent concernant la MDA [OMG03], disponible sur le site Web du groupe OMG. Vous pouvez également consulter divers ouvrages, tels que [FRA03], [KLE03], et [MEL04] ainsi que de nombreux articles, par exemple "An MDA Manifesto" de Grady Booch, Alan Brown, Sridhar Iyengar, James Rumbaugh et Bran Selic, disponible dans le numéro de mai 2004 de The MDA Journal.

Notions fondamentales de la MDADébut de page

La MDA introduit une terminologie et des concepts spécifiques qui la distingue des approches plus générales relatives au MDD. Ces aspects sont détaillés dans la section suivante.

Approche fondée sur des standards existants Début de page

Les standards de l'OMG sous-tendent l'architecture MDA :

  • Le standard Meta-Object Facility (MOF) - En plus de définir un langage pour la construction de métamodèles, par exemple UML et CWM, le langage MOF définit un cadre d'application pour la mise en oeuvre des référentiels associés aux modèles et aux métamodèles, permettant un approche cohérente de la manipulation de ces modèles dans le cadre de l'utilisation du MDA. Le langage MOF constitue donc une technologie essentielle pour MDA.
  • Le langage de modélisation unifié (UML) - Les PIM, les PM et les PSM sont définis en langage UML, notation de base de la MDA.
  • Le format XML Metadata Interchange (XMI) - XMI définit le format d'échange des modèles UML basé sur le langage XML.
  • Le standard Common Warehouse Metamodel (CWM) - CWM est à la modélisation des données ce qu'UML est à la modélisation d'applications.

Indépendance de la plateforme Début de page

La définition intuitive du terme plateforme tend à décrire cette dernière comme un élément prenant en charge une couche architecturale supérieure par le biais de prestations de services et grâce à un jeu d'interfaces bien définies masquant les détails d'implémentation. La définition du terme "plateforme" donnée par l'OMG (dans le guide MDA) est la suivante :

"Ensemble de sous-systèmes/technologies proposant un jeu cohérent de fonctionnalités via des interfaces et des patterns d'usage spécifiés auxquels tout sous-système rattaché à la plateforme peut faire appel, indépendamment de la façon dont la fonctionnalité proposée par la plateforme est mise en oeuvre."

Cette définition s'apparente au concept de couche tel qu'il est utilisé dans RUP.

Toutefois, la notion d'indépendance de plateforme est légèrement glissante : il s'agit d'une qualité ou d'une caractéristique d'un modèle. Par exemple, on peut dire qu'un modèle est indépendant d'une plateforme donnée lorsqu'il ne comprend aucune référence aux services ou ne fait appel à aucune des fonctionnalités fournies par cette plateforme. Néanmoins, ce prédicat reste relatif car il est difficile d'envisager une forme absolue d'indépendance de plateforme. Le guide MDA admet cette réserve et reconnaît l'existence de divers degrés d'indépendance vis-à-vis de la plateforme, notamment dans les cas où le modèle emploie une forme généralisée d'une fonction proposée par la plateforme.

L'indépendance de plateforme est encouragée par l'évolution de plateformes telles que J2EE, .NET et WebSphere, vers des niveaux d'abstraction toujours plus élevés par rapport à ce qui est exposé aux applications. Ceci facilite considérablement l'identification des constructions neutres du point de vue des plateformes et simplifie l'écriture des transformations spécifiques aux plateformes qui convertissent ces constructions.

Modèle indépendant de la plateforme (PIM) Début de page

Un modèle peut être considéré comme un PIM vis-à-vis d'une plateforme donnée dès lors qu'il n'existe aucune obligation pour ce modèle de faire appel à la plateforme en question et qu'il peut être utilisé avec n'importe quelle plateforme du même type. Dans une section précédente, nous avons abordé le concept de niveau d'abstraction élevé. Nous sommes arrivés à la conclusion qu'un modèle exprimé en langage UML (ou par le biais d'un profil UML), ne contenant aucun élément spécifique au fournisseur, ne dépendant d'aucune plateforme d'infrastructure particulière et complet d'un point de vue sémantique, était exécutable (du moins potentiellement) et présentait un niveau d'abstraction élevé. La question est de savoir si un tel modèle peut être considéré comme étant indépendant de la plateforme . La réponse est oui et non. Non, en raison de l'hypothèse d'une machine virtuelle UML peut-être imaginaire, oui si l'on suppose une classe entière de plateformes dont dépendrait cette machine virtuelle.

Modèle de plateforme Début de page

Un modèle de plateforme renvoie à l'ensemble des concepts (représentant des composants et des services), spécifications, définitions d'interfaces, définitions de contraintes et autres exigences dont une application a besoin pour utiliser une plateforme donnée. Dans la MDA, les modèles de plateforme sont détaillés et formalisés en langage UML, par exemple, et enregistrés dans un référentiel compatible MOF. Les modèles de plateforme peuvent notamment être construits en vue d'une utilisation avec J2EE ou .NET.

Modèle spécifique à la plateforme (PSM) Début de page

Un PIM se convertit en un ou plusieurs PSM dès lors que des informations le rendant davantage spécifique à une ou plusieurs plateformes lui sont associées. Le PIM et le PSM définissent toujours le même système, mais le PSM est associé à une technologie particulière et peut contenir des éléments spécifiques à la plateforme. Notons en outre, qu'il n'existe aucune spécification quant à l'importance de la phase de transformation (du PIM en PSM ou les plateformes qui lui sont associées). Une transformation qui suppose l'application de quelques patterns permet d'affiner le modèle et, en un sens, le rend plus spécifique ; ceci souligne la relativité des termes PIM et PSM.

Points de vue et vues Début de page

Ces termes ont dans la MDA la même définition que dans le MDD :

  • Un point de vue, comme son nom l'indique, renvoie à un position imaginaire d'où sont visibles certains aspects ou problèmes liés au système, supposant l'application d'une série de concepts et de règles pour constituer un filtre conceptuel. Etant donné que certaines informations relatives au système sont supprimées, il s'agit d'une forme d'abstraction. Le terme perspective est également employé.
  • A partir d'un point de vue, vous accédez à des vues qui sont en fait des projections de modèles, et qui mettent en évidence les entités intéressantes par rapport au point de vue en question.

La MDA distingue trois points de vue sur le système : un point de vue indépendant de la représentation informatique, un point de vue indépendant de la plateforme et un point de vue spécifique à la plateforme.

Point de vue indépendant de la représentation informatique Début de page

Le point de vue indépendant de la représentation informatique s'intéresse au contexte du système, aux exigences et aux contraintes qui régissent son fonctionnement et aux éléments environnementaux avec lesquels il doit interagir. A partir de ce point de vue, les détails relatifs à la structure et au comportement du système ne sont pas visibles.

Le modèle indépendant de la représentation informatique (CIM) est une vue du système ou du futur système obtenue à partir du point de vue indépendant de la représentation informatique. Dans le concept, le modèle CIM s'apparente à l'association du modèle de domaine RUP (ensemble d'artefacts), du glossaire métier et du modèle d'analyse métier, qui résulte du détail de l'enchaînement des activités Développer un modèle de domaine (dans Modélisation métier) et Modèle de cas d'utilisation, et offre la description indépendante de la représentation informatique du comportement du système. Le modèle CIM, rédigé dans le langage des spécialistes du domaine ou du sujet abordé, représente un lien important dans l'identification des abstractions clés du futur système, au cours de la phase d'analyse et de conception.

Point de vue indépendant de la plateforme Début de page

Le point de vue indépendant de la plateforme est défini par rapport à une plateforme donnée. Depuis ce point de vue, vous pouvez visualiser la structure et le comportement du système sans aucun détail relatif à la plateforme. Le PIM est une vue du système obtenue à partir du point de vue indépendant de la plateforme.

Point de vue spécifique à la plateforme Début de page

A partir du point de vue spécifique à la plateforme, également défini par rapport à une plateforme donnée, vous pouvez non seulement visualiser ce qui était déjà visible depuis le point de vue indépendant de la plateforme, mais aussi accéder aux détails liés à l'utilisation de la plateforme. Le PSM est une vue du système obtenue à partir du point de vue spécifique à la plateforme.

Automatisation de la transformation Début de page

Dans la MDA, la transformation est un concept fondamental. La transformation de modèle y est définie comme le "processus de conversion d'un modèle en un autre modèle associé au même système.". La MDA propose également un petit pattern permettant de visualiser cette conversion et d'illustrer une partie de la terminologie que nous avons abordée précédemment :

Pattern MDA décrivant les éléments de base de la transformation (PIM et informations) et le résultat obtenu (PSM et enregistrement des informations)

Pattern MDA

L'objectif de ce diagramme est de démontrer que la transformation constitue une étape primordiale : elle associe le PIM et les informations complémentaires pour générer le PSM.

Bien entendu, la transformation de modèles peut aussi être réalisée manuellement ; néanmoins, le procédé est légèrement différent de ce que l'on avait l'habitude de faire jusqu'alors en matière de conception de logiciels. Dans ce cas aussi, la MDA sert à définir et formaliser le concept de transformation, le processus et les informations complémentaires à prendre en considération. La MDA suggère également la création d'un enregistrement de la transformation afin d'assurer le suivi du PIM en PSM grâce au mappage des éléments du PIM avec les éléments du PSM. Enfin, l'automatisation des transformations (même partielle) est la meilleure façon de tirer parti de cette technologie et présente les mêmes avantages que le remplacement des programmations en assembleur par des langages de haut niveau.

Modalités d'exécution de la transformation Début de page

La MDA ne préconise pas de méthode unique quant à la réalisation des transformations : dans un premier temps, un mappage, établi en fonction du choix de la plateforme, est effectué en vue de déterminer la façon dont le PIM va être transformé en PSM pour la plateforme en question. On obtient, à l'issue de ce mappage, une définition de la transformation (éventuellement exprimée sous la forme d'une série de règles de transformation), incluant probablement des paramètres de transformation, rédigée dans un langage de définition de transformation. Il convient de souligner que le groupe OMG a publié une spécification (MOF 2.0 Query/Views/Transformations) afin de standardiser (pour le MOF) les langages utilisés dans la création de vues de modélisation, les interrogations de modèles et la rédaction des définitions de transformation. Le guide MDA décrit différentes approches de la transformation, parmi lesquelles :

  • La transformation de métamodèle - Cette approche suppose que le langage dans lequel le PIM est construit comprend un métamodèle MOF de niveau PIM. De même, en ce qui concerne la plateforme choisie, le langage dans lequel le PSM est construit doit inclure un métamodèle de niveau PSM. Vous pouvez créer une définition de transformation par le biais d'un mappage entre les deux métamodèles ; cette définition permet ensuite de transformer le PIM en PSM.
  • Le marquage - Un mappage est effectué pour la plateforme sélectionnée. Celui-ci permet de créer une définition de transformation qui inclut un ensemble de marques permettant de repérer les éléments du PIM. Il en résulte un "PIM marqué" ainsi qu'une définition contenant les instructions relatives à la manipulation des éléments ainsi identifiés. Le PIM marqué est ensuite transformé en PSM. Le marquage est une opération manuelle, mais les transformations qui s'ensuivent peuvent être automatiques.
  • La transformation de modèle - Le PIM est construit au moyen de types indépendants de la plateforme, également spécifiés dans le modèle, dans lequel les éléments du PIM sont des sous-types des types indépendants de la plateforme. Une fois sélectionnée, la plateforme est associée à un ensemble de types spécifiques à la plateforme. Un mappage est effectué entre les deux ensembles de types ; celui-ci débouche sur une définition de transformation qui est appliquée au PIM et permet de générer un PSM exprimé en sous-types des types spécifiques à la plateforme. Cette approche est similaire à la transformation de métamodèles, à la différence près que, dans ce cas, la transformation se limite aux types inclus dans un modèle et aux concepts associés à un métamodèle MOF.
  • L'application de pattern - Le PIM est construit à l'aide d'un ensemble de types et de patterns abstraits non liés à la plateforme. La plateforme sélectionnée comporte un ensemble de types et de patterns qui lui sont spécifiques. Un mappage entre les deux ensembles de types et de patterns est réalisé. Celui-ci génère une définition de transformation à appliquer au PIM. Le résultat obtenu est le PSM dans lequel les patterns abstraits sont devenus des patterns spécifiques à la plateforme.

Pour de plus amples détails, voir le guide MDA [OMG03].

Modalités d'application de la transformation Début de page

Le scénario le plus simple pour l'application de la MDA est le suivant :

  1. Préparation d'un PIM.
  2. Sélection d'une plateforme.
  3. Préparation d'un mappage, s'il n'en existe pas déjà un.
  4. Application de la transformation pour générer le PSM.
  5. Conversion du PSM en code. Si le PSM n'a pas besoin d'être affiné davantage et s'il peut être mis en oeuvre directement, il s'agit d'une implémentation, telle que nous la définissons dans la prochaine section.

Les PSM associés aux autres plateformes sont générés de façon similaire.

Application répétée du pattern MDA

Le pattern MDA est susceptible d'être appliqué à plusieurs reprises : un PSM généré à un premier niveau devient le PIM du niveau suivant, et suppose une sélection de plateforme plus spécifique. Notons que dans le MDD, comme nous l'avons déjà évoqué dans RUP et comme l'atteste l'utilisation des outils IBM Rational, il est préférable de limiter au maximum le nombre d'étapes d'affinage, autrement dit, il est recommandé de passer le plus directement possible d'une représentation proche du problème formulé par le client à une forme exécutable.

Représentation de trois applications du pattern MDA : le PIM initial devient un PSM lié à la plateforme 1, celui-ci est ensuite transformé de façon à dépendre également de la plateforme 2, puis il est à nouveau transformé pour être rattaché aux plateformes 1, 2 et 3.

Application répétée du pattern MDA

Transformation générale modèle-modèle

Les mêmes concepts peuvent être appliqués aux transformation générales, c'est-à-dire à la transformation d'un modèle en un autre modèle, quel que soit son type. Si, par exemple, les langages associés à deux métamodèles sont utilisés pour exprimer les modèles en question, il est en principe possible d'effectuer un mappage afin d'obtenir une définition de transformation. Cette dernière est ensuite employée de la même façon que dans le cadre d'une transformation PIM-PSM.

Implémentation Début de page

Le guide MDA emploie le terme "implémentation" tel qu'il est entendu dans les modèles d'implémentation de RUP. L'implémentation renvoie à la spécification de tous les éléments d'implémentation nécessaires à la construction, au déploiement, à l'installation et au fonctionnement du système.

Un PSM peut lui-même être une implémentation ou peut nécessiter un affinage supplémentaire avant d'être converti en code. Il convient de noter que la génération d'un PSM d'implémentation peut permettre d'ignorer l'étape de manifestation du PSM et de passer directement au code. Le cas échéant, même le PIM le plus abstrait peut être directement changé en code par le moteur de transformation. Le développeur a toujours la possibilité de visualiser ce code pour une meilleure compréhension, toutefois ceci peut supposer un rétro-ingénierie du code.

AvantagesDébut de page

Portabilité et interopérabilité Début de page

L'architecture MDA représente un espoir de pouvoir contrôler les dépenses et les bouleversements technologiques par le biais d'un jeu relativement stable de PIM destinés à être modelés en fonction de toute nouvelle exigence imposée par les nouvelles technologies. On espère également que, parallèlement à la généralisation du standard MDA, les développeurs travaillant avec les nouvelles technologies réaliseront les mappages requis de sorte que les transformations puissent être réalisées rapidement.

En étendant les mappages PIM-PSM à deux plateformes, la MDA suggère la construction de "ponts" entre les deux PSM générés et, à terme, entre les deux implémentations afin qu'un PIM puisse être réparti entre les plateformes. De nombreuses entreprises doivent aujourd'hui mener à bien des développements dans des environnements hétérogènes en composant avec des technologies nouvelles et anciennes ; aussi l'interopérabilité de la MDA représente un avantage non négligeable.

Réduction du coût de cycle de vie Début de page

Productivité Début de page

L'objectif du développement via la MDA est d'obtenir le PIM le plus abstrait possible. Utilisé conjointement à des outils de génération de PSM (ou de code) puissants, un tel environnement devrait être plus productif (de la même manière qu'un langage de haut niveau est plus productif que le langage assembleur), en particulier si l'on part du principe que, dans la plupart des cas, un PIM ou tout autre élément de même nature, est de toute façon développé (par exemple, pour servir de modèle de conception RUP). Le gain en productivité dépend essentiellement du degré d'intervention manuelle nécessaire au niveau de la transformation.

Qualité Début de page

Idéalement, dans la MDA, l'objectif de maintenance est le PIM. Par conséquent, sous réserve que le PIM repose sur une architecture de qualité, le produit devrait présenter moins de défauts tout au long de sa vie (car la probabilité qu'un humain les y injecte est moindre), et la restauration de ces défauts devrait s'avérer moins onéreuse grâce à la transformation automatique. Le PIM est en outre davantage concentré sur les problèmes liés au domaine et est donc plus à même de répondre aux besoins du client.

RUP (Rational Unified Process)   2003.06.15