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
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)
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 ?
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 ?
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 ?
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 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)
Pourquoi ce nouveau standard ?
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
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
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 plateforme
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)
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
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)
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
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
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
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
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
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
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 ?
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 ?
Le scénario d'application de l'architecture guidée par modèle le plus simple est le suivant :
-
Préparez un modèle indépendant de la plateforme.
-
Sélectionnez une plateforme.
-
Préparez un mappage s'il n'en existe pas.
-
Appliquez la transformation pour générer un modèle spécifique à la plateforme.
-
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
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.
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
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
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
Portabilité et
interopérabilité
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
Productivité
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é
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.
|