Concept: Développement guidé par modèle (MDD) et architecture guidée par modèle (MDA)
Ces conseils introduisent les concepts de développement guidé par modèle (MDD) et d'architecture guidée par modèle (MDA), dont la fonction principale est de mettre en valeur le rôle des modèles dans le génie logiciel.
Relations
Eléments connexes
Description principale

Introduction

Les modèles, qui constituent une catégorie de produits jouant un rôle de premier plan dans RUP (Rational Unified Process), sont généralement exprimés (dans RUP) à l'aide du langage UML, sans référence à un outil ou un environnement spécifique, de façon à pouvoir déployer et activer RUP au moyen de diverses boîtes à outils et dans divers environnements. Le matériel de support : Modélisation visuelle permet d'étudier certaines situations appelant une modélisation ; par exemple :

  • Aide à la compréhension de systèmes complexes,
  • Etude et comparaison de différentes options de conception à coût bas servant de base à l'implémentation,
  • Enregistrement précis des exigences,
  • Transmission sans ambiguïté de décisions.

On considère les modèles comme un moyen de réfléchir sur le comportement d'un système (comportement attendu et comportement obtenu) et sa structure, et de transmettre les résultats de ces réflexions aux parties prenantes concernées. Les MDD et MDA mettent en valeur le rôle des modèles comme éléments fondateurs de l'implémentation, dans l'espoir qu'ils seront plus qu'un simple plan à partir desquels les développeurs humains écriront du code, mais sont eux-mêmes activables ou exécutables à un niveau dépendant des fonctionnalités de la boîte à outils de support. Cela permet de rester conforme à une tendance déjà ancienne, qui consiste à augmenter le niveau d'abstraction auquel travaillent les développeurs. L'accent n'est plus mis sur les codes tels que nous les connaissons, mais sur les modèles exprimés dans un langage encore plus évolué, éventuellement graphique. RUP, en identifiant certains artefacts en tant que modèles plutôt que comme des documents (via l'enregistrement des exigences et de la conception, par exemple) contenant des représentations graphiques de modèles, prend en charge cette possibilité de manière implicite.

Points de vue et vues Début de page

Comme son nom l'indique, un point de vue est une position théorique à partir de laquelle peuvent être étudiés certains aspects ou préoccupations relatifs au système (ou à l'ensemble des modèles représentant le système), ce qui implique l'application d'un ensemble de concepts et de règles permettant de constituer un filtre conceptuel. Le terme "perspective" est employé de manière similaire pour décrire une façon de voir et de comprendre les modèles qui offre la meilleure prise en charge des nombreuses orientations et préoccupations des différentes parties prenantes.

Les vues sont des projections de modèles qui affichent les entités pertinentes d'un point de vue donné ou dans une perspective spécifique.

Dans le cas du développement guidé par modèle, les points de vue et les vues sont utilisés pour classer les préoccupations, par exemple afin de manipuler la structure logique indépendamment de la structure physique et de la structure de traitement. Plus les modèles sont proches du domaine du problème, plus les points de vue ou les perspectives traitent des préoccupations métier des parties prenantes ; plus les modèles sont développés dans un format proche du format exécutable, plus les préoccupations d'ordre informatique sont nombreuses. Dans chaque cas, l'objectif n'est pas simplement de produire des illustrations passives, mais des modèles qui, au moins potentiellement, génèrent des implémentations satisfaisant les différents types de préoccupations.

Elaboration et traduction (transformation) Début de page

Ces termes sont souvent employés de façon informelle afin d'établir une distinction entre les changements apportés au modèle à la main (élaboration) ou par un outil (traduction). Dans RUP, la signification formelle du terme "élaboration" est assez différente puisqu'il s'agit du nom d'une phase du cycle de vie ; dans cette section, nous l'utiliserons cependant de manière informelle pour illustrer des approches apparemment différentes de l'évolution des modèles.

On note également que la taille des étapes est différente dans le cadre de la traduction et de l'élaboration ; ainsi, l'élaboration d'un modèle s'effectue en plusieurs petites étapes jusqu'à obtention d'un niveau de détail suffisant (y compris des détails concernant le langage, l'infrastructure ou le système d'exploitation) afin de l'utiliser comme base de génération de code au moyen d'un outil ou par intervention manuelle. Par "intervention manuelle", on entend qu'une personne peut observer le modèle et écrire en Java, C++ ou employer d'autres langages, en poursuivant éventuellement l'élaboration du processus. Dans le cas de la traduction, au contraire, le modèle, toujours situé à un niveau d'abstraction non encore affecté par des préoccupations de langage, d'infrastructure ou de système d'exploitation, est converti pour exécuter et produire le résultat attendu sans poursuivre, ou de manière très limitée, l'élaboration. Notez que le résultat attendu concerne entre autres les performances et d'autres caractéristiques non fonctionnelles. C'est pourquoi, comme cette approche l'exige implicitement, les préoccupations transverses d'ordre architectural doivent être traitées dans la façon dont le modèle est construit et dans la façon dont il décrit les besoins en actifs.

Un autre terme, transformation, est de plus en plus usité pour décrire le processus de génération d'un modèle cible à partir d'un modèle source en suivant un ensemble de règles et en travaillant en fonction d'un ensemble de paramètres. Notez que le sens du terme "modèle" est ici le même que dans RUP ; le modèle cible peut donc correspondre aux éléments d'implémentation, par exemple, du code ou du texte. La transformation peut bien sûr s'effectuer à la main ; une série de transformations successives (ajout de détails) revient alors à une élaboration. Les règles peuvent être très complexes et fondées sur une très grande connaissance pratique de la technologie disponible et du domaine. Par défaut, on considère cependant que la transformation est réalisée de manière automatique, ce dont nous reparlerons dans la section consacrée à l'architecture guidée par modèle .

Notez que le concept de transformation implique simplement un modèle source et un modèle cible. En général, le modèle cible est moins abstrait que le modèle source, c'est-à-dire que le modèle cible est en quelque sorte plus spécifique que le modèle source, mais cela n'est pas inhérent au concept de transformation. Notez également qu'une transformation peut ajouter des détails à un modèle, générant ainsi un modèle cible plus affiné, mais qui reste en général au même niveau d'abstraction, dans le sens où aucune information relative à un autre domaine n'y est introduite. Dans le cas d'un autre type de transformation, très différent, qui génère du code à partir d'un modèle UML, de nombreux éléments n'ayant aucun intérêt pour la partie prenante métier sont intégrés au modèle cible, à condition que le comportement et les caractéristiques non fonctionnelles requis soient gérés.

Pour réaliser une traduction parfaite, il faut disposer d'outils dotés de fonctionnalités pertinentes et être capable de codifier, d'enregistrer et de réutiliser les connaissances mises en oeuvre par une personne expérimentée. Le volume de connaissances à enregistrer et codifier dépend du niveau d'abstraction à partir duquel se déroule l'étape de traduction : en général, plus ce niveau est élevé, plus il faut posséder de connaissances et d'expérience dans le domaine.

Dans le cas du développement guidé par modèle, notre objectif est d'augmenter le niveau d'abstraction à partir duquel la génération d'un système opérationnel peut être automatisée. L'élaboration d'un modèle se poursuit jusqu'au moment où il peut être utilisé pour réaliser des générations. Nous préférons ensuite de beaucoup éviter de poursuivre l'élaboration du résultat pour qu'il s'exécute. De plus, notre ambition est de procéder à l'élaboration précédente, dans la mesure du possible, via une succession de transformations automatisées. Les deux approches se rejoignent donc : la traduction est en effet réalisée par une série de transformations successives, automatisées dans la mesure du possible. La transformation finale d'un système d'exécution se déroule alors que la description du modèle se trouve encore à un haut niveau d'abstraction et que les choix en matière de technologie, d'infrastructure et de langage cible sont encodés dans le moteur de transformation, les règles et données lui étant transmises.

Autre avantage du développement guidé par modèle : nous espérons être capable de réutiliser les transformations en leur faisant codifier des connaissances relatives à la plateforme et au domaine, ainsi que les bonnes pratiques, via la création de ces éléments par des experts dans les domaines correspondants. De cette façon, nous simplifions la réutilisation des transformations par des développeurs moins expérimentés ; cela permet également de ne pas recommencer de zéro à chaque nouvelle application.

Qu'est-ce qu'un haut niveau d'abstraction ? Début de page

Il existe plusieurs façons d'envisager ce concept. On peut tout d'abord s'intéresser au spectre du langage ; on remarque par exemple l'émergence de formes d'UML exécutables. Une deuxième approche consiste à partir de la perspective de l'ingénierie de domaine, dans lequel le langage et les concepts de modélisation peuvent être rendus spécifiques au domaine. Par exemple, le langage UML est polyvalent ; dans cette optique, vous utilisez donc le profil UML pour spécialiser l'utilisation du langage UML. Vous pouvez enfin décider d'éviter les modèles spécifiques à un fournisseur ou à une infrastructure, de façon à n'exclure aucune innovation technologique.

En termes d'expression de la dynamique détaillée, le travail accompli sur la sémantique d'action UML a rendu possible l'apparition de formes exécutables du langage UML, mais la syntaxe et la notation concrètes ne sont pas standardisées et le niveau de la sémantique d'action s'apparente à celui d'autres langages orientés objet. C'est pourquoi le langage UML plus la sémantique d'action ne constituent probablement pas la solution définitive, mais elle donne une idée de la façon dont les choses vont évoluer à l'avenir.

Nous en concluons qu'un modèle exprimé en langage UML, ou utilisant un profil UML, qui ne contient pas d'éléments spécifiques à un fournisseur, qui ne dépend pas d'une plateforme d'infrastructure donnée, comme J2EE ou Microsoft .NET, et dont la structure et le comportement sont complets d'un point de vue sémantique, sans avoir recours à un langage procédural spécifique (Java, C#, etc.), se situe à un haut niveau d'abstraction selon cette définition, même si la question du niveau de la sémantique d'action reste en suspens.

Du point de vue du domaine du problème, c'est-à-dire du point de vue de l'utilisateur ou du client métier, la formulation de langages de modélisation spécifiques au domaine constitue une solution réalisable et intéressante. Ces langages sont abstraits, dans le sens où ils sont formulés au moyen de termes et de concepts connus des travailleurs d'un domaine donné, mais ils sont tout de même complets par leur capacité à exprimer une dynamique de modèle, alors qu'ils ont toujours une base UML.

Quel est le lien avec RUP ? Début de page

Les relations des modèles RUP d'analyse, de conception et d'implémentation illustrent les idées développées ci-dessus : le modèle d'analyse représente une vue précoce de la façon dont le comportement exprimé dans des cas d'utilisation sera réalisé ; il est naturellement orienté de manière descriptive vers le domaine du problème métier en cours de traitement et les classes d'analyse qu'il contient sont considérées comme des regroupements conceptuels des responsabilités et du comportement requis. Le modèle d'analyse n'est en général pas assez complet pour être exécuté, sauf peut-être, dans le cadre d'un essai minutieusement conçu, par une personne lisant le modèle et comblant les lacunes, car trop d'éléments sont encore inexprimés. Le modèle d'analyse doit plutôt subir un processus d'amélioration, qui lui ajoute des détails et augmente sa précision, pour devenir un modèle de conception.

RUP permet à un projet de gérer un modèle d'analyse distinct ou de considérer le modèle d'analyse comme un élément évoluant pour devenir le modèle de conception. Le processus d'amélioration est décrit assez longuement dans les tâches de RUP, l'interprétation par défaut étant que les personnes jouant les rôles d'architecte logiciel et de concepteur accompliront cette évolution, probablement à l'aide d'un grand nombre d'outils. Notez que cette amélioration peut être considérée comme une séquence de transformations de modèle, dont certaines peuvent éventuellement être automatisées, par exemple dans l'application du pattern d'analyse et du pattern de conception dans les tâches RUP Analyse architecturale et Identifier les mécanismes de conception.

A quel moment le modèle de conception est-il complet ? Début de page

Le modèle de conception évolue tout au long du cycle de vie du projet, via plusieurs itérations ; on peut donc se demander à quel moment le modèle de conception (ou une partie du modèle) peut être converti en code, c'est-à-dire à quel moment peuvent commencer la production des éléments d'implémentation et leur intégration dans des constructions pertinentes du système. RUP propose des conseils relatifs au mappage de la conception au code, mais il n'existe aucune réponse absolue. Passez à l'implémentation lorsque vous jugez, en vous fondant par exemple sur les résultats d'une revue, que le moment est venu, moment qui peut varier considérablement d'une organisation à l'autre ou d'un projet à l'autre. RUP propose différentes façons de passer de la conception au code ; deux d'entre elles sont présentées ici afin d'illustrer la manière dont sont prises les décisions concernant l'exhaustivité de la conception :

1. Esquisse et code
Pour RUP, "une approche courante consiste à esquisser la conception à un niveau assez abstrait, puis à passer directement au code. La maintenance du modèle de conception se fait manuellement."

Pour obtenir de bons résultats en adoptant cette approche, le développeur doit être capable de combler la différence d'abstraction entre les niveaux de conception et d'implémentation. La maintenance du modèle de conception est souvent considérée comme une préoccupation secondaire, tandis que le code passe au premier plan !

2. Ingénierie aller-retour impliquant un modèle de conception évolutif unique
Pour RUP, "cette approche fait intervenir un seul et unique modèle de conception. Les esquisses initiales des éléments de conception évoluent jusqu'à ce qu'elles puissent être synchronisées avec le code."

A ce stade, les développeurs comblent la différence d'abstraction au moyen d'une séquence d'étapes de modélisation. La différence entre cette approche et la précédente (esquisse et code) consiste dans le fait que, dans cette nouvelle approche, les étapes intermédiaires sont évidentes et qu'à la fin la version abstraite du modèle de conception a disparu.

Dans les deux cas, la valeur potentielle d'un modèle de conception abstrait est perdue : dans "esquisse et code", parce qu'en général on ne procède pas à la maintenance du modèle de conception abstrait et qu'il finit par ne plus être en lien avec le code ; dans "modèle de conception évolutif unique", parce que la version abstraite disparaît. Même si une version initiale est conservée, elle connaît souvent le même destin que le modèle de conception de type "esquisse et code". Notez que le point limite du modèle de conception en ingénierie aller-retour correspond à la visualisation du code ; on pourrait d'ailleurs, pour obtenir une visualisation similaire, procéder à une ingénierie inverse à partir du code généré par application de l'approche "esquisse et code" au moyen des outils appropriés. Dans RUP, la perte du modèle de conception abstrait est compensée dans une certaine mesure par l'enregistrement à des moments cruciaux de vues d'architecture significatives et de la justification de la conception dans le document d'architecture logicielle.

Le développement guidé par modèle permet d'espérer que le modèle de conception abstrait deviendra absolument essentiel à la génération de code et perdurera. Il devient le premier (voire le seul) fondement de la maintenance. Il offre également une définition claire du point limite de la conception, c'est-à-dire du moment auquel, du point de vue du moteur de transformation, le modèle est complet, cohérent et exempt d'ambiguïtés et peut être converti en système exécutable. Le niveau d'abstraction du modèle dépend de la technologie et de la boîte à outils disponibles (un exemple est présenté dans la rubrique de l'aide intitulée icône manuel d'aide Visite guidée : Présentation de Rational Software Architect) et peut également dépendre du domaine. Notez que du point de vue du développement guidé par modèle, il s'agit simplement d'une nouvelle transformation (de la conception au code), qui a tout de même une relative importance puisqu'elle traverse les niveaux d'abstraction.

La section suivante décrit un nouveau standard d'infrastructure pour le développement guidé par modèle (MDD), initié par le groupe OMG et appelé Architecture guidée par modèle (MDA ).

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

Pourquoi ce nouveau standard ? Début de page

L'architecture guidée par modèle est une création du groupe OMG, consortium industriel comptant quelque 800 membres ayant pour mission d'établir des instructions et spécifications standard afin de fournir une infrastructure commune non spécifique à un fournisseur pour le développement d'application et d'encourager l'interopérabilité entre les principales plateformes d'infrastructure matérielle et logicielle. Le langage UML est un exemple de produit développé par le groupe OMG. Aujourd'hui, le groupe OMG promeut l'architecture guidée par modèle en tant que spécification phare ; étant donné le succès du langage UML et l'implication du groupe dans la diffusion de standards pratiques conçus pour être pris en charge par le capital intellectuel, les pratiques, les produits et les outils d'un secteur d'activité, ce nouveau concept d'architecture guidée par modèle mérite qu'on s'y intéresse. De très nombreuses informations sont disponibles sur ce type d'architecture, notamment le très récent Guide de l'architecture guidée par modèle (MDA Guide), [OMG03], publié sur le site Web du groupe OMG. Il existe également un grand nombre d'ouvrages sur le sujet, par exemple [FRA03], [KLE03] et [MEL04], ainsi que des articles, comme "An MDA Manifesto" par Grady Booch, Alan Brown, Sridhar Iyengar, James Rumbaugh et Bran Selic, publié dans The MDA Journal en mai 2004.

Concepts centraux de l'architecture guidée par modèle Début de page

L'architecture guidée par modèle implique l'utilisation de concepts et de termes spécifiques qui la distinguent d'approches plus générales du développement guidé par modèle ; ils sont définis et commentés dans les sections suivantes.

Construire sur des standards existants Début de page

L'architecture guidée par modèle est fondée sur des standards OMG existants, notamment :

  • la fonction méta-objet : elle définit non seulement un langage pour la construction de métamodèles, par exemple UML et CWM, mais également une infrastructure préfabriquée pour l'implémentation de référentiels pour les modèles et métamodèles, ce qui permet d'envisager de manière cohérente la manipulation de ces modèles en cas d'utilisation de l'architecture guidée par modèle. Cette fonction constitue donc une technologie essentielle pour ce type d'architecture.
  • le langage UML : les modèles indépendants de la plateforme (PIM), modèles de plateforme (PM) et modèles spécifiques à la plateforme (PSM) sont définis en langage UML, qui constitue la notation de base de l'architecture guidée par modèle.
  • XML Metadata Interchange (XMI) : XMI définit un format d'échange de modèle UML basé sur XML.
  • le métamodèle Common Warehouse Metamodel (CWM) : ce qu'UML est à la modélisation d'application, CWM l'est à la modélisation des données.

Indépendance par rapport à une plateformeDébut de page

Intuitivement, on considère qu'une plateforme prend en charge une couche architecturale supérieure au moyen de services qui offrent un ensemble d'interfaces bien défini destiné à dissimuler les détails de l'implémentation. Le groupe OMG propose (dans le MDA Guide) la définition suivante de la plateforme :

"Ensemble de sous-systèmes/technologies fournissant un jeu cohérent de fonctionnalités à travers des interfaces et des patterns d'utilisation définis qui peuvent être utilisés par tout sous-système dépendant de la plateforme sans se préoccuper de la manière dont est implémentée la fonctionnalité fournie par la plateforme."

Cette définition rappelle le concept de couche tel qu'il est utilisé dans RUP.

La notion d'indépendance par rapport à la plateforme est assez délicate à définir : il s'agit d'une qualité ou caractéristique d'un modèle ; on peut par exemple dire qu'un modèle est indépendant d'une plateforme donnée lorsqu'il ne contient aucune référence à des services ou fonctionnalités fournis par cette plateforme. Cette formulation doit cependant être relativisée car il est difficile d'envisager une forme absolue d'indépendance par rapport à une plateforme. Le MDA Guide reconnaît cette réalité et admet également la possibilité de l'existence de différents niveaux d'indépendance par rapport à une plateforme, par exemple dans le cas d'une plateforme donnée dans laquelle un modèle utilise une forme généralisée d'une fonction.

L'avènement du concept d'indépendance par rapport à la plateforme a été rendu possible par l'évolution de plateformes telles que J2EE, .NET et WebSphere, à des niveaux d'abstraction toujours plus élevés en termes d'éléments exposés aux applications. L'identification des constructions neutres en termes de plateforme est devenue ainsi beaucoup plus aisée, tout comme l'écriture des transformations spécifiques à une plateforme qui les convertissent a gagné en simplicité.

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

Nous pouvons donc dire qu'un modèle est de type PIM par rapport à une plateforme donnée lorsque son utilisation n'est pas nécessairement liée à cette plateforme, mais qu'il peut être utilisé avec n'importe quelle plateforme de ce type. Plus haut dans ce document, nous avons introduit la notion de haut niveau d'abstraction et conclu qu'un modèle exprimé en langage UML (ou utilisant un profil UML) qui ne contient pas d'éléments spécifiques à un fournisseur, ne dépend pas d'une plateforme d'infrastructure donnée et dont la structure et le comportement sont complets d'un point de vue sémantique, sans avoir recours à un langage procédural spécifique, était exécutable au moins en théorie et à un haut niveau d'abstraction. Ce type de modèle est-il dépendant d'une plateforme ? Oui et non. Non, si l'on considère une machine virtuelle UML potentiellement imaginaire, mais oui, si l'on considère une classe entière de plateformes dont une telle machine virtuelle dépendrait.

Modèle de plateforme Début de page

Le modèle de plateforme correspond à l'ensemble de concepts (représentant des pièces et des services), de spécifications, de définitions d'interface et de contrainte et de toute autre exigence nécessaire à une application pour utiliser une plateforme donnée. Dans le cas de l'architecture guidée par modèle, les modèles de plateforme sont détaillés et formalisés, par exemple en langage UML, et mis à disposition dans un référentiel compatible MOF (fonction méta-objet). Des modèles de plateforme peuvent ainsi être construits, entre autres, pour J2EE ou .NET.

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

Un modèle PIM est transformé en un ou plusieurs modèles PSM par l'ajout d'informations qui le rendent spécifiques à une/des plateforme(s) donnée(s). Ces deux types de modèle définissent le même système, mais le modèle PSM est limité à une technologie donnée et peut contenir des éléments spécifiques à la plateforme. Notez qu'on ne peut pas déterminer dans l'absolu l'ampleur d'une étape de transformation (passage d'un modèle PIM à un modèle PSM ou sa plateforme associée). Une transformation impliquant l'application d'un ensemble réduit de patterns améliore le modèle et, en un sens, le rend plus spécifique, ce qui met en exergue la nature relative des termes "modèle indépendant" et "modèle spécifique".

Points de vue et vues Début de page

Ces termes ont le même sens dans le contexte de l'architecture guidée par modèle que dans celui du développement guidé par modèle :

  • Un point de vue, comme son nom l'indique, est une position théorique à partir de laquelle peuvent être étudiés certains aspects ou préoccupations relatifs au système, ce qui implique l'application d'un ensemble de concepts et de règles permettant de constituer un filtre conceptuel. Etant donné que des informations relatives au système sont éliminées, il s'agit d'une forme d'abstraction. Le terme perspective a la même signification.
  • A partir d'un point de vue, vous pouvez examiner des vues, qui sont des projections de modèles montrant les entités pertinentes dans le cadre de ce point de vue.

L'architecture guidée par modèle définit trois points de vue sur un système : un point de vue indépendant de la programmation (Computation Independent Model - CIM), 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 programmation Début de page

Dans le cadre du point de vue indépendant de la programmation, l'accent est mis sur le contexte du système, les exigences et contraintes devant présider à son fonctionnement, ainsi que sur les éléments de son environnement avec lesquels il doit interagir. Ce point de vue ne permet pas d'examiner les caractéristiques de la structure ou le comportement du système.

Le modèle indépendant de la programmation (modèle CIM) est une vue du système actuel ou futur à partir du point de vue du même nom. Le modèle CIM correspond à une combinaison du modèle de domaine de RUP (ensemble d'artefacts, dont le glossaire métier et le modèle d'analyse métier, résultant de la Tâche : Développer un modèle de domaine (en modélisation métier)) et du modèle de cas d'utilisation (description indépendante de la programmation du comportement du système). Le modèle indépendant de la programmation, exprimé dans un langage propre aux experts techniques ou du domaine, constitue un lien important pour l'identification, au cours des phases d'analyse et de conception, des abstractions clés du futur système.

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

Le point de vue indépendant de la plateforme dépend d'une plateforme donnée. A partir de ce point de vue, vous pouvez examiner la structure et le comportement d'un système sans disposer des caractéristiques de cette plateforme. Le modèle indépendant de la plateforme (modèle PIM) est une vue du système à partir du point de vue du même nom.

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

A partir du point de vue spécifique à la plateforme, qui dépend également, comme son nom l'indique, d'une plateforme donnée, vous pouvez examiner les mêmes éléments que dans le cas du point de vue indépendant de la plateforme, mais en ayant cette fois accès aux caractéristiques d'utilisation de la plateforme. Le modèle spécifique à la plateforme (modèle PSM) est une vue du système à partir du point de vue du même nom.

Automatisation de la transformation Début de page

La transformation est une notion fondamentale de l'architecture guidée par modèle et la transformation de modèle se définit simplement comme suit :"processus de conversion d'un modèle en un autre du même système". Ce type d'architecture définit également un pattern de taille réduite permettant de visualiser la conversion et d'illustrer l'utilisation de certains termes déjà évoqués :

Pattern MDA montrant le modèle PIM et d'autres informations utilisés en tant qu'entrée pour la transformation et le modèle PSM et l'enregistrement de la transformation en sortie.

Pattern MDA

L'objectif de ce diagramme est de montrer que la transformation est un élément de première importance : elle utilise le modèle PIM et l'associe à d'autres informations pour générer le modèle PSM.

Une transformation de modèle peut bien entendu être réalisée manuellement. La procédure est très proche de la façon dont la conception logicielle s'est toujours déroulée. Même dans ce contexte, l'architecture guidée par modèle permet de définir et de formaliser la notion de transformation, le processus associé et les informations supplémentaires à utiliser. L'architecture guidée par modèle propose également de générer un enregistrement de la transformation, ce qui permet de procéder à un suivi solide du modèle PIM vers le modèle PSM, car il doit inclure le mappage des éléments du modèle PIM aux éléments du modèle PSM. La plus grande avancée réside dans la possibilité d'automatiser les transformations, même partiellement. Elle offre les mêmes avantages que ceux qui sont obtenus lorsque la programmation par assemblage est remplacée par des langages évolués.

Comment réalise-t-on une transformation ? Début de page

L'architecture guidée par modèle n'impose pas une méthode unique de transformation : un mappage, guidé par le choix d'une plateforme, est préparé afin de fournir des indications sur la façon dont le modèle PIM doit être transformé en modèle PSM ; ce mappage produit une définition de la transformation (éventuellement exprimée sous la forme d'un ensemble de règles de transformation), contenant parfois des paramètres de transformation, écrite dans un langage propre à la définition de transformation. Notez que le groupe OMG a publié une demande de proposition (demande de proposition "MOF 2.0 Query/Views/Transformations") dans le but de standardiser (pour la fonction méta-objet - MOF) les langages permettant de créer des vues de modèle, de demander des modèles et d'écrire des définitions de transformation. Le MDA Guide présente plusieurs approches de la transformation, notamment :

  • Transformation de métamodèle : cette approche suppose qu'il existe un métamodèle MOF de niveau PIM (modèle indépendant de la plateforme) exprimé dans le langage utilisé pour construire le modèle PIM. De même, pour la plateforme choisie, il existe un métamodèle de niveau PSM (modèle spécifique à la plateforme) exprimé dans le langage permettant de construire un modèle PSM. Vous pouvez procéder à un mappage des deux métamodèles pour construire une définition de la transformation ; il sera ensuite utilisé pour transformer le modèle PIM en modèle PSM.
  • Marquage : un mappage de la plateforme choisie est préparé. Ce mappage est utilisé pour construire une définition de la transformation, qui contient un ensemble de marques à appliquer sur des éléments du modèle indépendant de la plateforme, ce qui produit un "modèle PIM marqué", ainsi qu'une définition indiquant ce que deviennent les éléments marqués. La transformation du modèle PIM marqué se poursuit ensuite pour générer le modèle PSM. Le marquage est en général réalisé manuellement, mais la transformation qui le suit peut être automatisée.
  • Transformation de modèle : le modèle PIM est construit à l'aide de types indépendants de la plateforme, également définis dans un modèle ; les éléments du modèle PIM constituent alors des sous-types des types indépendants. Une plateforme est choisie et associée à un ensemble de types spécifiques à la plateforme. Un mappage est réalisé entre ces deux ensembles de types, ce qui génère une définition de la transformation, appliquée au modèle PIM, créant un modèle PSM exprimé en sous-types de types spécifiques à la plateforme. Cette approche est assez semblable à la transformation de métamodèle, à la différence que, dans ce cas, la transformation concerne des types d'un modèle plutôt que des concepts issus d'un métamodèle MOF.
  • Application de pattern : le modèle PIM est construit à l'aide d'un ensemble de types et de patterns abstraits indépendants de la plateforme. Il existe un ensemble de types et de patterns spécifiques à la plateforme choisie. Un mappage est réalisé entre les ensembles de types et de patterns, ce qui permet d'obtenir une définition de la transformation devant être appliquée au modèle PIM. Le modèle PSM en résultant contient des patterns abstraits spécifiques à la plateforme.

Pour plus d'informations, reportez-vous au Guide de l'architecture guidée par modèle (MDA Guide) [OMG03].

Comment applique-t-on une transformation ? Début de page

Le scénario d'application de l'architecture guidée par modèle le plus simple est le suivant :

  1. Préparez un modèle indépendant de la plateforme.
  2. Sélectionnez une plateforme.
  3. Préparez un mappage s'il n'en existe pas.
  4. Appliquez la transformation pour générer un modèle spécifique à la plateforme.
  5. Convertissez le modèle PSM en code. Si le modèle spécifique peut être directement implémenté sans nécessiter d'améliorations supplémentaires, il s'agit d'une implémentation, comme expliqué à la section suivante.

Des modèles PSM peuvent être générés de la même façon pour d'autres plateformes.

Application répétée du pattern MDA Début de page

Le pattern MDA peut cependant être appliqué de façon répétée : un modèle PSM généré à un niveau devient le modèle PIM du niveau suivant, c'est-à-dire pour le choix de plateforme suivant, plus spécialisé. Notez que dans le cas du développement guidé par modèle, tel qu'il est décrit dans RUP et pris en charge par la boîte à outils IBM Rational, nous préférons limiter le nombre d'étapes d'amélioration pour passer de la façon la plus directe possible d'une représentation proche du problème rapporté par le client à une forme exécutable.

Trois applications répétées du pattern MDA, pour trois différentes plateformes

Application répétée du pattern MDA

L'objectif du diagramme ci-dessus est de montrer les trois applications du pattern MDA : le modèle initial PIM devient un modèle PSM qui dépend de la plateforme 1, et subit deux autres transformations pour être également dépendant de la plateforme 2, puis des plateformes 1, 2 et 3.

Transformation générale de modèle à modèle Début de page

Les mêmes concepts peuvent s'appliquer à une transformation générale, c'est-à-dire de modèle à modèle. S'il existe par exemple deux métamodèles dont les langages sont utilisés pour exprimer les modèles, alors vous pouvez en principe réaliser un mappage, qui génère une définition de la transformation. La procédure d'application est la même que pour la transformation d'un modèle PIM en modèle PSM.

Implémentation Début de page

Dans le MDA Guide, le concept d'"implémentation" est semblable à celui développé dans le contexte du modèle d'implémentation de RUP. Il s'agit de 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 modèle PSM peut être une implémentation en lui-même ou nécessiter des améliorations supplémentaires avant de pouvoir être converti en code. Notez que la génération d'un modèle PSM d'implémentation peut faire l'impasse sur l'étape de manifestation du modèle PSM pour passer directement au code. Dans ce cas, le modèle PIM, plus abstrait, peut être converti directement en code par le moteur de transformation. Une visualisation du code peut être fournie au développeur pour l'aider à comprendre la situation, mais il est possible de procéder à une ingénierie inverse à partir du code.

Avantages potentiels Début de page

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

Avec l'architecture guidée par modèle, on espère pouvoir contrôler les coûts et les perturbations liés aux innovations technologiques en permettant le reciblage d'un ensemble relativement stable de modèles PIM vers n'importe quelle nouvelle technologie requise. On espère ainsi que, plus le concept d'architecture guidée par modèle se répandra, plus les développeurs de nouvelles technologies fourniront également des mappages, de façon à pouvoir réaliser les transformations rapidement.

En étendant les mappages des modèles PIM à PSM à deux plateformes, l'architecture guidée par modèle suggère que des "ponts" peuvent être construits entre les deux modèles PSM et par la suite entre les deux implémentations, afin de pouvoir distribuer un modèle PIM sur toutes les plateformes. La plupart des entreprises doivent faire face à la nécessité de développer des environnements hétérogènes au moyen de technologies à la fois anciennes et nouvelles ; cette aptitude à réaliser l'interopérabilité peut donc représenter pour elles un formidable avantage.

Réduction des coûts de cycle de vie Début de page

Productivité Début de page

Le développement au moyen de l'architecture guidée par modèle se concentre à présent sur le modèle PIM, plus abstrait. Si l'on dispose d'une boîte à outils conséquente permettant de générer un modèle PSM (ou du code), ce type d'environnement doit être plus productif, de la même façon qu'un langage évolué est plus productif qu'une programmation par assemblage, d'autant qu'un modèle PIM, ou un élément semblable, est souvent développé de toute façon, par exemple pour faire office de modèle de conception dans RUP. Le gain de productivité dépend dans une très large mesure des interventions manuelles nécessaires au cours du processus de transformation.

Qualité Début de page

Idéalement, dans le cadre de l'architecture guidée par modèle, la cible de la maintenance est le modèle PIM. Par conséquent, sous réserve que l'architecture du modèle PIM soit correcte, il devrait se produire moins d'incidents dans le cycle de vie du produit, car les interventions humaines sont plus limitées, et la résolution des incidents détectés devrait être moins onéreuse, grâce à l'automatisation de la transformation. Le fait de se concentrer sur le modèle PIM permet de prendre en compte de manière plus précise les préoccupations liées au domaine ; la satisfaction des besoins des clients devrait donc s'en trouver améliorée.