Un autre mod`ele de relation d`association pour

Eric Mendizabal
Université de Montpellier II
DEA d’Informatique
Année 2002 / 2003 - Mémoire de DEA
Un autre modèle de relation d’association pour
améliorer la réutilisation de composants de
modèles UML
Sujet proposé par S. Vauttier
et C. Urtado
TABLE DES MATIÈRES
Table des matières
1 Introduction
3
2 Relation d’association et composants conceptuels en
2.1 La relation d’association . . . . . . . . . . . . . . . . .
2.1.1 La propriété de réciprocité . . . . . . . . . . . .
2.1.2 La propriété de dépendance . . . . . . . . . . .
2.2 Les composants conceptuels . . . . . . . . . . . . . . .
2.2.1 Production de composants pour la réutilisation
2.2.2 Production de composants par réutilisation . .
UML
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
5
7
7
8
9
3 Vers une modification du méta-modèle
3.1 Les concepts d’association unidirectionnelle et
3.2 Une approche par composition . . . . . . . .
3.3 Une approche par héritage . . . . . . . . . . .
3.4 Le modèle proposé . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
12
14
15
. . . . .
NSUML
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
19
19
19
21
4 Mise en oeuvre du modèle
4.1 Implémentation dans NSUML . . . . . . .
4.1.1 Le modèle de relation d’association
4.1.2 Implémentation du modèle . . . .
4.2 Intégration dans ArgoUML . . . . . . . .
5 Conclusion
de rôle
. . . . .
. . . . .
. . . . .
. . .
dans
. . .
. . .
23
1
TABLE DES FIGURES
Table des figures
1
2
3
4
5
6
7
8
9
Les quatre niveaux de modélisation standard de l’OMG (source [Bez01])
Une relation d’association unidirectionnelle . . . . . . . . . . . . . . . .
Une relation d’association bidirectionnelle . . . . . . . . . . . . . . . . .
Décomposition de composants : distribeur automatique de billets . . . .
Assemblage de composants : pilote automatique sur avion de ligne . . .
L’approche avec composition . . . . . . . . . . . . . . . . . . . . . . . .
L’approche avec héritage . . . . . . . . . . . . . . . . . . . . . . . . . . .
Le modèle retenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modèle de l’implémentation des relations d’association dans NSUML . .
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
6
6
9
10
13
14
17
20
1 INTRODUCTION
1
Introduction
Le monde de l’industrie porte un intérêt tout particulier à l’ingénierie des logiciels et
des systèmes d’information basés sur les composants. En effet, ces derniers permettent un
développement rapide et à moindre coût de logiciels de qualité. Après avoir consisté à intégrer
des composants logiciels lors de la phase d’implémentation, notamment par l’intermédiaire
d’infrastructures telles que CORBA [OMG02a], J2EE [Sun03a] ou encore .NET, une nouvelle
tendance se dessine : celle des approches dirigées par les modèles. Ces nouvelles approches se
fondent sur un constat simple. Devant l’évolution rapide des architectures, les composants
logiciels doivent fréquemment et rapidement migrer vers de nouvelles plates-formes. Les
composants logiciels ne tiennent donc pas toutes leurs promesses en matière de réutilisation.
Il apparaı̂t alors que seuls les modèles conceptuels produits lors des étapes de spécification ou
de conception peuvent être pérennisés et capitalisables au cours du cycle de développement
d’un logiciel ou d’un système d’information. Il est alors légitime de penser que les vrais
composants ne sont pas les composants logiciels mais ceux de modèle.
En se basant sur ces constats, les approches dirigées par les modèles proposent de réaliser
l’intégration des logiciels non plus lors de la phase d’implémentation mais lors de la phase
de conception. L’intégration consiste alors à assembler des composants de modèles décrits
de manière conceptuelle dans un langage de modélisation standard et technologiquement
neutre. Le passage des composants conceptuels aux composants logiciels s’effectue ensuite
par l’intermédiaire de générateurs de code fournis par la plate-forme cible. Cela a pour effet
de permettre la migration des composants vers de nouvelles plates-formes à moindre coût.
L’OMG a lancé une initiative afin de bâtir une approche dirigée par les modèles appelée
MDA (Model Driven Architecture). Cette démarche s’appuie sur le standard de modélisation
orientée objet à quatre niveaux défini par l’OMG [OMG02b, Bez01] (figure 1):
– le niveau méta-méta (niveau M3), qui définit le MOF en tant que méta-méta-modèle
standard permettant de décrire un méta-modèle standard.
– le niveau méta (niveau M2), dans lequel tout méta-modèle est une instance du MOF
afin de permettre l’échange et l’interopérabilité des méta-modèles. On trouve à ce
niveau le méta-modèle du langage standard de modélisation objet, UML (Unified Modeling Language) [OMG03].
– le niveau classe (niveau M1), où les modèles sont des instances du niveau méta (M2).
Nous trouvons par exemple à ce niveau les modèles UML, instances du méta-modèle
d’UML.
– le niveau instance (niveau M0), niveau des données du monde réel, où des instances
particulières des modèles du niveau M1 sont créées.
Au sein de MDA, deux types de relations interviennent entre modèles [Bez01]. Il existe
d’une part des relations de transformation permettant de décrire la transformation d’un
modèle en un autre modèle. Ces transformations s’effectuent par l’intermédiaire de règles
formelles. Ces règles de transformations entre modèles sont en cours de standardisation et
permettront à terme la description de la génération automatique du code d’implantation
d’un composant conceptuel pour une plate-forme technique donnée. D’autre part, il existe
également des relations d’intégration décrivant l’assemblage de modèles dans le but de produire de nouveaux modèles. Les travaux exposés dans ce document portent sur ce type de
3
1 INTRODUCTION
Fig. 1 – Les quatre niveaux de modélisation standard de l’OMG (source [Bez01])
relations entre modèles. Nous nous intéressons aux mécanismes de réutilisation et d’assemblage de composants conceptuels élémentaires afin de produire de nouveaux modèles.
Le langage UML ne dispose pas, dans sa version actuelle, d’un concept de relation
d’association supportant les mécanismes de décomposition / recomposition. Nous souhaitons donc introduire un concept de relation permettant de disposer de composants conceptuels construits par et pour la réutilisation. Pour cela, il convient de s’intéresser au métamodèle d’UML afin de chercher à combler les différents défauts déjà recensés par des
méthodologistes. Après avoir évoqué la relation d’association et les composants conceptuels
en UML, nous présenterons les faiblesses du méta-modèle d’UML au niveau de la gestion des
composants conceptuels conçus par et pour la réutilisation. Nous introduirons ensuite une
solution pratique à ce problème en proposant un méta-modèle de relations d’associations
s’inscrivant dans la démarche MDA. Nous présenterons alors la mise en oeuvre de ce modèle
dans une implémentation en langage Java ainsi que son intégration dans le méta-modèle
NSUML, base de l’atelier de génie logiciel ArgoUML. Enfin, nous conclurons en évoquant
les perspectives de ces recherches.
4
2 RELATION D’ASSOCIATION ET COMPOSANTS CONCEPTUELS EN UML
2
Relation d’association et composants conceptuels en
UML
Nous présentons tout d’abord la relation d’association dans le langage UML. Nous
précisons ensuite le lien existant entre la relation d’association et les composants conceptuels,
que nous introduisons.
2.1
La relation d’association
Nous nous intéressons ici aux travaux ayant été menés sur la relation d’association en
UML, ainsi que sur l’utilisation de composants conceptuels dans ce langage.
De manière générale [OMG03, Ste01], une relation d’association est une relation n-aire
liant un ensemble de classes d’objets et définissant les rôles relatifs joués par les instances
de ces classes, lorsqu’elles sont mises en relation par des instances de cette relation d’association. Une instance d’une relation d’association est appelée un lien d’association. Un
lien d’association lie n objets, instances des n classes liées par la relation d’association dont
il est une instance.
La relation d’association a été au centre de nombreuses recherches. Ces dernières se poursuivent toujours notamment grâce à l’intérêt actuel porté par la communauté à l’approche
MDA. Cette dernière place les modèles au premier plan dans le cadre du développement logiciel. Par sa position centrale au niveau des modèles pour permettre l’association de classes,
la relation d’association est au coeur de la problématique.
La sémantique de la relation d’association et sa modélisation reste un domaine scientifiquement actif. De nombreux travaux sont menés sur cette problématique [Civ98, Bez01,
Ste01, GBHS97]. Nous pouvons identifier deux propriétés sémantiques importantes de la
relation d’association dans le cadre de notre problématique : la réciprocité et la dépendance.
2.1.1
La propriété de réciprocité
Une première propriété sémantique de la relation d’association est la propriété de réciprocité. Nous distinguons alors deux types de relations d’association [HS98] :
– les relations d’association unidirectionnelles (figure 2) sont des relations d’associations
ne possédant qu’un seul sens de lecture. Ainsi, un seul rôle est défini dans cette association. Lors de la mise en relation par une association unidirectionnelle de deux objets
O1 et O2, seul O1 joue un rôle pour l’objet O2. L’objet O2 ne joue pas de rôle pour
l’objet O1 : nous avons dans ce cas une unidirectionnalité de la relation d’association.
– les relations d’association bidirectionnelles (figure 3), par opposition, définissent les
rôles réciproques des deux classes liées. L’association de deux objets O1 et O2 par un
lien bidirectionnel permet de spécifier le rôle joué par l’objet O1 pour l’objet O2, et
réciproquement le rôle joué par l’objet O2 pour l’objet O1. Le langage UML propose
ce type de relation d’association bidirectionnelle de manière native.
Divers points de vue s’affrontent pour la détermination des avantages et inconvénients
de chacune de ces approches.
Certains méthodologistes [GBHS97, HS98] considèrent que seules les relation d’association unidirectionnelles doivent être utilisées pour la modélisation de systèmes à objets.
5
2 RELATION D’ASSOCIATION ET COMPOSANTS CONCEPTUELS EN UML
Fig. 2 – Une relation d’association unidirectionnelle
Fig. 3 – Une relation d’association bidirectionnelle
Cette approche présente une économie de concepts au niveau d’UML : seules des relations
unidirectionnelles sont utilisées. Une relation bidirectionnelle se modélise dans ce cas par
un couple de relations d’associations unidirectionnelles et un ensemble de contraintes sur
ces associations afin de gérer la réciprocité. Nous pouvons voir ici un inconvénient : si une
économie de concepts est effectuée au niveau du modèle d’UML, la modélisation de la relation d’association bidirectionnelle s’en trouve complexifiée. De plus, cette approche va à
l’encontre du principe objet d’encapsulation dans la représentation des relations d’association. Il n’est ainsi pas possible de déterminer à quelles entités doivent être associées les règles
ou contraintes gérant la réciprocité des relations.Plusieurs solutions de stockage s’offrent lors
de la mise en relation de classes A et B :
– l’information est stockée dans la classe A (resp. B ), ce qui pose un problème dans la
mesure où B (resp. A) ne dispose plus de cette information.
– l’information est stockée dans la classe A et la classe B, nous avons alors un problème
de maintenance de deux copies identiques de l’information.
– l’information est stockée ailleurs que dans A ou B, ce qui n’est pas une solution satisfaisante puisqu’elle pourrait alors se perdre, la sémantique de la relation d’association
disparaı̂ssant.
La gestion de la relation d’association bidirectionnelle par l’intermédiaire uniquement
d’associations unidirectionnelles présente donc certains inconvénients.
Inversement, certains spécialistes proposent de n’utiliser que des relations d’association
bidirectionnelles. La définition d’une association bidirectionnelle entraı̂ne alors la définition
de deux rôles. C’est le cas du modèle de relations d’association tel que défini dans la
spécification d’UML [OMG03]. Ce dernier associe à toute extrémité d’association un rôle.
Si, en théorie, ce modèle interdit de définir des relations d’associations unidirectionnelles,
cette difficulté se trouve contournée en pratique par un artifice. Il s’agit alors de définir un
rôle factice pour l’extrémité d’association ne jouant pas de rôle. Ces rôles sont alors vides de
sens mais permettent néanmoins de respecter la contrainte d’utilisation de relations bidirectionnelles uniquement. Nous obtenons ainsi des relations unidirectionnelles par utilisation de
relations bidirectionnelles. Cette approche permet de conserver la simplicité du méta-modèle
et assure de plus le respect des principes objet.
Il apparaı̂t donc que la solution consistant à ne considérer que des associations bidirectionnelles permette d’obtenir un compromis intéressant entre l’expressivité des relations
6
2 RELATION D’ASSOCIATION ET COMPOSANTS CONCEPTUELS EN UML
et l’efficacité du méta-modèle. Cependant, une troisième vision intervient. Elle consiste à
considérer au sein d’un même méta-modèle les relations unidirectionnelles et les relations
bidirectionnelles [Civ98]. Cette approche offre l’avantage d’éviter les compromis effectués
dans les deux autres approches et permet d’effectuer une gestion satisfaisante des composants conceptuels.
Nous nous intéressons à présent à la propriété de dépendance.
2.1.2
La propriété de dépendance
La seconde propriété à laquelle il convient de s’intéresser est la propriété de dépendance.
Nous distinguons les relations d’association intrinsèques des relations extrinsèques, selon
qu’elles expriment ou non un rôle qui affecte la définition d’une classe.
Les relations d’association intrinsèques participent directement à la description ou au
fonctionnement d’une classe. Elles permettent de traduire les besoins existentiels ou fonctionnels. On appelle besoin existentiel la description d’une partie d’un objet par un autre
objet. Un besoin fonctionnel se traduit par des appels aux méthodes des autres objets pour
réaliser ses méthodes. Un besoin existentiel conduit à la définition d’une relation de composition (au sens d’UML, soit une relation de composition, soit une relation d’agrégation)
[OMG03, BPLB02] tandis qu’un besoin fonctionnel entraı̂ne la définition d’une association
exprimant la collaboration entre les deux classes. Une relation intrinsèque est définie au
moment de la définition des classes. Cette forme d’association se caractérise par la présence
d’attributs au sein des classes qui l’utilisent [BPLB02, Ste01]. Une relation intrinsèque est
donc définie a priori et ne peut être modifiée ou supprimée indépendamment de la classe
d’objets qui en dépend. Il apparaı̂t un lien entre le cycle de vie de la relation intrinsèque et
ceux des objets qui en dépendent.
Les relations d’association extrinsèques sont des relations permettant de décrire le contexte
environnant des objets dans le modèle. Elles ne traduisent donc pas les besoins des objets.
Les classes liées par des relations extrinsèques n’ont pas connaissance de ces relations. On
ne trouve donc pas de dépendance au niveau de leur cycle de vie, contrairement aux relations intrinsèques : de telles associations peuvent donc être ajoutées ou retirées du modèle
sans effet sur la définition des classes mises en jeu. La gestion de cette relation est donc
mise au niveau de la relation elle-même, ce qui la place alors comme concept de première
classe. Nous appelons dès lors cela une classe d’objets relationnels. Un concept comparable est proposé au niveau du langage UML [OMG03] sous le nom de classe-association.
Cependant, ce concept ne dispose ni d’une définition ni d’un usage défini précisément au
niveau de la spécification du langage. Ce concept est important dans le contexte de l’assemblage de composants conceptuels. En effet, il permet de définir des relations d’associations
indépendamment des classes associées.
Après avoir exposé les différents types de relations d’association pouvant exister entre
classes d’objets, nous nous intéressons à présent aux composants conceptuels en UML.
2.2
Les composants conceptuels
Selon la définition générale d’un composant [Szy99], il s’agit d’une entité indépendante
en interaction avec les autres entités du système dans lequel il est impliqué. Dans le cadre
7
2 RELATION D’ASSOCIATION ET COMPOSANTS CONCEPTUELS EN UML
de composants conceptuels, nous avons donc des entités de modèles indépendantes en interaction avec d’autres entités de modèles (d’autres composants conceptuels). Un composant
conceptuel peut donc être vu comme un fragment de modèle autonome, pouvant exprimer
des besoins et offrant des services. Ainsi, un composant conceptuel C peut offrir les services
S1 et S2, tout en nécessitant la compétence B d’un autre composant conceptuel. La base de
cette interaction et de ces relations entre composants conceptuels est la relation d’association qui permet de définir les liens existants entre entités. Cette dernière a été présentée en
section 2.1. Elle est également à la base du développement orienté composants. Ce mode de
développement repose sur deux principes : la production de composants pour la réutilisation
et par la réutilisation. Nous abordons à présent ces deux aspects.
2.2.1
Production de composants pour la réutilisation
Il s’agit ici de produire des composants dans le but de les réutiliser dans d’autres modèles.
La principale qualité d’un composant (logiciel ou conceptuel) est sa capacité à être réutilisé.
Par conséquent, il se doit d’être défini indépendamment de son contexte. En effet, toute
liaison contextuelle limiterait alors sa réutilisation pour d’autres utilisations.
La définition d’un composant contextuel doit fournir un ensemble de définitions afin de
pouvoir offrir un bon niveau de réutilisabilité. Tout d’abord, les classes constituant le composant doivent être définies. Ce sont les structures de données interne au composant permettant
son fonctionnement. Les relations structurelles 1 entre les classes d’objet du composant sont
également explicitées. Enfin, les collaborations, exprimées par des relations d’association,
entre les classes d’objets au coeur du composant conceptuel sont définies. Ces différents
points constituent une définition interne du composant conceptuel. Cependant, un composant est créé dans le but d’offrir un service à d’autres composants. Il propose donc ses
services aux autres composants par l’intermédiaire d’une interface fournie par le composant
[CR03]. Enfin, le composant nécessite également les services d’autres composants. Il déclare
alors une interface requise pour exprimer ses besoins pour son fonctionnement [CR03]. Cet
ensemble de définitions mène à la création de composants disposant d’un haut degré de
réutilisabilité. Afin d’isoler la définition d’un composant de tout contexte d’utilisation, le
langage de modélisation (plus exactement le méta-modèle de celui-ci) se doit de posséder
deux concepts que nous indiquons ici.
D’une part, le langage de modélisation doit proposer le concept d’interface au sens de
la définition abstraite d’une classe d’objets. Lors de la spécification des besoins et services
d’un composant, il convient d’indiquer quels sont les objets qui pourront être associés au
composant. Cette spécification se fait par l’intermédiaire d’un rôle sur la relation d’association représentant le lien entre objets. Afin de disposer d’une généricité nécessaire dans le
cadre de la réutilisation, le type de ce rôle ne doit pas être une classe d’objets mais plutôt
une interface. La limitation consistant à représenter le type du rôle par une classe d’objets n’autorise qu’à associer des objets instances des classes ou des sous-classes du type. La
spécification du type du rôle par une interface permet d’associer à ce rôle tous objets instances de classes implémentant le type de l’interface indiquée. Cette solution conduit alors à
éviter la limitation des possibilités d’associations entre ce composant et d’autres composants
du système.
1. liées à la propriété de dépendance
8
2 RELATION D’ASSOCIATION ET COMPOSANTS CONCEPTUELS EN UML
Fig. 4 – Décomposition de composants : distribeur automatique de billets
D’autre part, le méta-modèle du langage de modélisation doits fournir le concept d’association unidirectionnelle. Une relation unidirectionnelle permet de spécifier les besoins d’un
composant conceptuel. Ce concept est nécessaire car l’utilisation d’une relation d’association
bidirectionnelle implique la définition d’un rôle réciproque. Or la définition de ce dernier va
à l’encontre de la définition du composant indépendamment de son contexte si la définition
de ce rôle n’est pas nécessaire pour le composant. Par conséquent, l’utilisation de relations
unidirectionnelles pour la spécification des besoins d’un composant est primordiale. Ainsi,
afin d’assurer la meilleure généricité au composant conceptuel, la définition de ce dernier ne
spécifie que des relations unidirectionnelles en indiquant le rôle attendu des classes partenaires. Les concepts de rôle et d’associations unidirectionnelles sont abordés d’une manière
plus approfondie en section 3.1.
Nous voyons dès lors ici une faiblesse du langage UML. Malgré le fait qu’il dispose
du concept d’interface, il ne propose pas ce type de relations dans son méta-modèle. La
définition de composants conceptuels disposant d’un haut degré de réutilisabilitédevient
alors plus complexe. De plus, il faut noter que la production de composants conceptuels doit
également pouvoir être effectuée par désassemblage de modèles (figure 4). Il faut alors éclater
les relations bidirectionnelles du modèle en relations unidirectionnelles. Ce mécanisme ne
peut non plus être réalisé au sein du langage UML puisque le concept de relation d’association
unidirectionnelle n’est pas présent. Afin de supporter ces mécanismes, le méta-modèle d’UML
se doit donc de subir des modifications.
2.2.2
Production de composants par réutilisation
Il s’agit ici de produire des composants conceptuels par réutilisation de composants
conceptuels déjà existants (figure 5). Les composants conceptuels sont sélectionnés selon
leurs fonctions, adaptés à leurs nouveaux contextes puis assemblés. On peut distinguer
deux approches pour l’assemblage de composants contextuels. D’une part, il existe un assemblage par connecteurs. Ces connecteurs sont alors des relations d’association entre les
9
2 RELATION D’ASSOCIATION ET COMPOSANTS CONCEPTUELS EN UML
Fig. 5 – Assemblage de composants : pilote automatique sur avion de ligne
différentes classes d’objets. Ce type d’assemblage de composants aboutit à la construction de
modèles par juxtaposition de classes. D’autre part, la seconde méthode d’assemblage consiste
à construire des objets composites. L’assemblage s’effectue alors par création de nouvelles
classes d’objets composites à partir des différents composants. Cela offre l’avantage de disposer d’une vision abstraite et hiérarchisée des objets composites. Le composant créé est dans
ce cas manipulable comme une classe d’objets. Cette approche par objet composite place
l’objet composite comme entité centrale, notion d’objet racine que l’on retrouve notamment
dans [Civ98]. Il faut noter que ces deux approches nécessitent une fonctionnalité du langage de modélisation. En effet, le méta-modèle du langage de modélisation doit supporter
la production de relations d’association lors de l’assemblage. Le langage de modélisation
doit donc permettre de créer des relations d’association au moment de l’assemblage des
composants conceptuels à partir des relations d’association définies dans le contexte de ces
composants. Ces mécanismes de gestion ici présentés ne sont pas disponibles au niveau du
méta-modèle d’UML. Ainsi, il n’est pas possible d’effectuer ces manipulations sur des composants conceptuels. Une amélioration du méta-modèle est donc nécessaire afin de disposer
de tels mécanismes.
Les relations d’association jouent un rôle clef au niveau de la modélisation à l’aide du
langage UML. Elles sont ainsi au coeur du problème des composants conceptuels que nous
posons ici. Cependant, nous avons souligné certaines faiblesses du méta-modèle d’UML pour
la gestion de ces composants conceptuels. Nous proposons donc un nouveau méta-modèle
afin d’améliorer la gestion, la production et l’assemblage des composants conceptuels dans
ce langage.
10
3 VERS UNE MODIFICATION DU MÉTA-MODÈLE
3
Vers une modification du méta-modèle
Le modèle de relation d’association proposé dans le langage de modélisation UML ne permet pas de gérer convenablement les mécanismes liés aux composants contextuels (décomposition, recomposition, assemblage). Nous souhaitons définir un nouveau modèle de relation
d’association. Après avoir présenté les concepts de relation d’association et de rôle, nous exposons deux premières approches pour la modélisation de la relation d’association en UML.
Ces approches n’étant pas entièrement satisfaisantes, nous nous orientons alors vers une
troisième solution présentant les qualités souhaitées dans notre problématique.
3.1
Les concepts d’association unidirectionnelle et de rôle
Afin de disposer de la capacité à décomposer et à assembler des composants de modèle,
nous devons introduire la notion d’association unidirectionnelle. Dans la version actuelle
d’UML, une association se présente comme une relation bidirectionnelle disposant de deux
rôles. Par conséquent, afin de modéliser une relation ne disposant que d’un seul rôle, un
artifice est utilisé : l’extrémité ne portant pas de rôle significatif se voit attribuer un rôle
factice. Nous souhaitons pouvoir utiliser des associations ne disposant que d’un seul rôle,
pour pouvoir exprimer, par exemple, les besoins d’un composant. Or nous souhaitons éviter
l’utilisation de rôles dépourvus de sens. Nous introduisons pour cela le concept d’association
unidirectionnelle.
Une association unidirectionnelle est définie comme une relation d’association ne portant un rôle qu’à une de ses extrémités. Nous pouvons alors modéliser uniquement les rôles
présentant un intérêt et éviter ainsi l’introduction de rôles factices. Ce type d’association
permet également de découpler des parties de modèles et de créer ainsi des composants de
modèles. En effet, lors de la mise en relation de deux parties de modèles par une relation
d’association, la décomposition est rendue difficile par la présence de la relation d’association bidirectionnelle, le lien entre les deux objets étant trop fort. Supposons maintenant
que l’on utilise des associations unidirectionnelles pour modéliser ce lien. Chaque classe
présente alors une ”demie-association” vers l’autre classe. Le même lien 2 est donc modélisé
par ces deux associations unidirectionnelles. La décomposition du modèle pour créer deux
composants est alors simplifiée, chaque composant conservant une association unidirectionnelle spécifiant son besoin d’être lié à un autre composant remplissant une fonction donnée 3 .
La définition d’un second concept fait également partie de notre approche : celui de rôle.
Ce dernier est induit par l’apparition du concept d’association unidirectionnelle. Dans la version actuelle d’UML, un rôle est placé au niveau d’un objet AssociationEnd qui représente
une extrémité d’association. Nous souhaitons disposer de la sémantique de la relation d’association au sein d’un concept indépendant, le rôle.
Nous définissons donc au niveau d’un Role l’ensemble des propriétés séman-tiques d’une
relation d’association. L’ensemble des propriétés sémantiques d’une association (navigabilité, multiplicité, etc.) migre alors vers le Role, ne laissant aux AssociationEnds que leur
fonction de liaison entre une classe et une association. L’introduction de ce nouveau concept
nous permet de modéliser clairement l’aspect sémantique d’une relation d’association en
2. d’un point de vue sémantique
3. celle spécifiée par le rôle présent sur la demie-association
11
3 VERS UNE MODIFICATION DU MÉTA-MODÈLE
tant qu’élément de modèle. De plus, nous souhaitons conserver la sémantique de la relation
d’association proche des classes mises en jeu dans celle-ci. Le placement de cette sémantique
dans les objets Role facilite alors la mise en oeuvre de ce point. Enfin, par l’introduction de
ce concept, la modélisation des relations d’association unidirectionnelles peut être réalisée
en n’attachant qu’un seul objet Role à une association unidirectionnelle.
Ces deux nouveaux concepts ayant été posés, nous présentons à présent une première
proposition de modèle pour la relation d’association basée sur la composition.
3.2
Une approche par composition
Une première approche consiste à considérer une relation bidirectionnelle comme la composition de deux relations unidirectionnelles. Ce concept de relation unidirectionnelle (UnidirectionnalAssociation), présenté en section 3.1, est introduit dans notre proposition de
modèle. Cette nouvelle classe hérite de la classe Relationship, une relation unidirectionnelle
étant une relation au même titre qu’une relation bidirectionnelle. Grâce à ce concept, les
aspects de décomposition et de recomposition de composants de modèle sont simplifiés. En
effet, à partir de composants liés par une relation d’association bidirectionnelle, on peut
alors découper cette relation en deux parties, chaque composant gardant avec lui une relation unidirectionnelle, exprimant ses besoins. Inversement, à partir de deux composants
de modèle indépendants et remplissant chacun les besoins de l’autre, l’assemblage s’effectue
par liaison des composants au travers des associations unidirectionnelles. Le concept de rôle
présenté précédemment est ici utilisé afin de modéliser les associations unidirectionnelles.
Nous pouvons cependant noter que le Role est rattaché à une association unidirectionnelle. Dans le modèle d’UML actuellement en vigueur, cette notion est présente dans un objet
AssociationEnd. Il existe donc une divergence entre ces deux points de vue. Nous avons déjà
noté la nécessité, dans le cadre de notre approche, de définir un concept indépendant Role.
Nous souhaitons de plus pouvoir effectuer des compositions de relations unidirectionnelles
pour obtenir des relations bidirectionnelles. En supposant que le Role soit attaché à un
objet AssociationEnd, nous devons spécifier, via des contraintes formelles 4 , qu’une association unidirectionnelle ne doit posséder qu’un seul et unique Role. Cela signifie alors qu’une
seule de ses deux AssociationEnds ne doit être liée à un objet Role. Par l’apparition de
contraintes textuelles, la composition de relations d’association unidirectionnelles devient
alors plus difficile à mettre en oeuvre. Ainsi, le choix de l’attachement du Role aux objets
UnidirectionnalAssociation se trouve justifié : à tout objet instance de cette classe, on associe
un unique objet instance de la classe Role. La composition a lieu de la manière suivante :
chaque association unidirectionnelle apportant son Role, la composition produit une association bidirectionnelle disposant d’exactement deux rôles. Ces différents aspects se trouvent
résumés dans la proposition de modèle de relation d’association de la figure 6.
L’approche présentée dispose d’un ensemble d’atouts que nous énumérons ici.
Tout d’abord, dans l’optique d’une décomposition / recomposition de modèles UML,
cette approche présente un grand intérêt. En effet, une relation bidirectionnelle se définissant
comme deux relations unidirectionnelles, la création de la première se conçoit comme la
4. en OCL par exemple
12
3 VERS UNE MODIFICATION DU MÉTA-MODÈLE
Association
0
2
UnidirectionnalAssociation
2..*
AssociationEnd
1..*
on met l’ensemble
desattributs de l’AE
dans le role!!
Role
Fig. 6 – L’approche avec composition
réunion au sein d’une même entité de ces deux relations unidirectionnelles. Au niveau
d’UML, cela se traduit par une composition. De la même manière, disposant d’une relation bidirectionnelle, nous pouvons la découper en deux relations unidirectionnelles, puisque
ces dernières la composent.
De plus, nous souhaitons, au cours des différentes phases d’assemblage et de décomposition
de composants conceptuels, conserver la traçabilité des actions entreprises. Ce type de
modèle autorise ceci puisqu’il est possible de déterminer, pour toute association bidirectionnelle, de quel assemblage d’associations unidirectionnelles elle provient. En effet, au
niveau de l’objet composite, nous pouvons déterminer ses composants.
Nous pouvons également noter que cette approche peut se généraliser. Elle fonctionne
pour les relations binaires 5 , mais son principe de fonctionnement pourra être éventuellement
étendu aux relations n-aires. Cette généralisation peut s’envisager en tant que composition
de n relations unidirectionnelles pour former une relation n-aire.
Un autre avantage de cette approche basée sur la composition est le fait que le modèle
composite dispose d’une bonne dynamique. En effet, lors de la création d’une relation bidirectionnelle par composition de relations unidirectionnelles, on peut observer au niveau
des instances des classes la présence des deux objets UnidirectionnalAssociation. Il est alors
possible de travailler sur le modèle en remplaçant le lien unidirectionnel existant entre les
deux classes par un autre lien avec une autre classe. Nous retrouvons alors une relation
bidirectionnelle entre deux autres classes, sans avoir dû affecter la totalité du modèle. Cette
approche permet donc la recomposition des modèles créés.
Enfin, le dernier argument est pour sa part davantage informel. En ne s’attachant qu’à
la représentation graphique de ce modèle, nous pouvons lire qu’une relation bidirectionnelle
5. composition de deux relations unidrectionnelles
13
3 VERS UNE MODIFICATION DU MÉTA-MODÈLE
Role
1..*
UnidirectionnalAssociation
AssociationEnd
2..*
on met l’ensemble
desattributs de l’AE
dans le role!!
Association
Fig. 7 – L’approche avec héritage
est composée d’au moins deux relations unidirectionnelles. L’idée sous-jacente du modèle
s’en retrouve donc résumée graphiquement.
Ce modèle présente cependant des inconvénients. Tout d’abord, il est rendu plus complexe par cette relation de composition. En effet, afin de créer une relation bidirectionnelle,
nous devons spécifier que deux relations unidirectionnelles sont utilisées. Par conséquent, les
relations bidirectionnelles ne peuvent exister de manière autonome et leur existence est liée à
celle des relations unidirectionnelles. L’inconvénient le plus notable réside cependant dans le
fait qu’il est impossible de déterminer à quelle extrémité un rôle est attaché. En effet, le rôle
est ici attaché aux objets UnidirectionnalAssociation, et non à l’extrémité à laquelle il est lié.
Cela pose un problème de sémantique, puisqu’il n’est plus possible d’identifier l’extrémité
d’association jouant un rôle donné. Cet aspect ne permet donc pas de valider complètement
le modèle proposé.
3.3
Une approche par héritage
Nous présentons alors une seconde approche. Il s’agit à présent de considérer une relation bidirectionnelle comme résultat de l’héritage de deux relations unidirectionnelles.
Cette approche place donc la relation bidirectionnelle comme une sous-classe de la relation
unidirectionnelle. Notons dès à présent que, afin de mettre en place la propriété d’unidirectionnalité, nous utilisons comme précédemment le concept de rôle. Ce dernier est lié de la
même manière à la classe représentant une association unidirectionnelle, à savoir UnidirectionnalAssociation. Nous exposons cette solution dans la proposition de modèle représentée
dans le diagramme de classe de la figure 7.
Ce modèle présente l’avantage de disposer d’une notation épurée. En effet, lors de sa comparaison avec le modèle précédent, nous constatons ici qu’une association bidirectionnelle
devient une entité autonome. Elle existe donc indépendamment de relations unidirectionnelles. Nous nous plaçons ainsi à un niveau d’abstraction élevé à partir duquel le mode de
14
3 VERS UNE MODIFICATION DU MÉTA-MODÈLE
création d’une association bidirectionnelle est transparent au lecteur du diagramme.
Nous pouvons cependant souligner quelques difficultés inhérentes à cette approche.
Tout d’abord, nous remarquons qu’une relation d’héritage multiple est utilisée. Ceci peut
s’avérer difficile à mettre en oeuvre au moment de l’implémentation du modèle, certains
langages ne proposant pas cette structure. Il ne s’agit pas réllement d’un obstacle, mais cela
peut tout de même pénaliser cette proposition.
Nous pouvons également remarquer qu’il est nécessaire de pouvoir spécifier qu’une relation bidirectionnelle hérite de deux relations unidirectionnelles. Or une relation d’héritage
ne permet a priori pas cette spécification.
De plus, l’approche utilisant l’héritage est de nature statique, contrairement à l’approche
par composition. En effet, lors de la mise en relation de deux objets, nous avons un objet de
type Association qui réalise le lien. Ce lien est donc figé : il lie deux objets et ne peut être
utilisé dans un autre cadre. On n’a ici qu’une seule association, l’association bidirectionnelle,
qui ne peut lier que les objets présents. Il n’est ensuite pas possible de réutiliser une partie
de l’association pour mettre en relation un des objets avec un autre. Nous perdons donc la
dynamique existante dans l’approche par composition.
Nous pouvons également noter, comme dans la proposition présentée en section 3.2,
que l’attachement du rôle à l’association unidirectionnelle ne permet pas de déterminer à
quelle extrémité un rôle appartient. Cela pose le même problème de sémantique que dans la
première approche.
Enfin, nous pouvons dès à présent noter que la modélisation utilisant la notion d’héritage
peut manquer de clarté par le fait que deux aspects distincts ( à savoir les deux associations
unidirectionnelles appartenant chacune à une entité) vont se trouver modélisés par une seule
relation d’héritage.
Cette approche ne propose donc pas un modèle facilement manipulable dans une optique
de décomposition / recomposition de modèles, ni de conserver toute la sémantique emportée
par une relation d’association. Devant les inconvénients de ces deux modèles, nous aboutissons alors à une nouvelle approche, basée sur la composition, intégrant de nouveaux concepts
et permettant de conserver la sémantique de la relation tout en supportant les mécanismes
de décomposition / recomposition. Cette nouvelle approche est présentée en section 3.4.
3.4
Le modèle proposé
Devant les inconvénients des propositions précédentes, nous sommes amenés à considérer
une nouvelle proposition de modèle. Nous avons vu que l’approche utilisant la composition
présente de nombreux avantages. Cependant, certains manques se font sentir, notamment
l’impossibilité de déterminer l’appartenance d’un rôle à une extrémité d’association. Nous
reprenons les idées de cette approche, tout en la complétant pour aboutir à une proposition
de modèle complète et pouvant s’insérer dans la version actuelle du modèle du langage UML.
Nous cherchons à déterminer comment spécifier le rattachement d’un Role à une extrémité
d’association dans le modèle à base de composition. Nous pouvons constater que, pour une
association donnée, il existe deux sortes d’extrémités (AssociationEnd ) : des extrémités portant un rôle, d’autres n’en portant pas. Ce constat nous pousse alors à considérer deux
15
3 VERS UNE MODIFICATION DU MÉTA-MODÈLE
types d’AssociationEnds distincts, à savoir les RoledAssociationEnds et les UnroledAssociationEnds. Les premières portent un rôle tandis que les secondes n’en portent pas. Nous
considérons la classe AssociationEnd comme une classe abstraite définissant le concept
général d’extrémité d’association, les deux classes précédemment introduites étant des sousclasses de celle-ci. La classe RoledAssociationEnd (respectivement, UnroledAssociationEnd )
présente alors la spécificité de posséder (respectivement, ne pas posséder) de rôle lié.
Il nous faut ensuite spécifier une association unidirectionnelle à partir de ces nouvelles
classes. Nous rappelons pour cela qu’une association unidirectionnelle est une relation d’association ne portant qu’un seul rôle à une de ses extrémités. Nous pouvons alors en déduire
une spécification des relations unidirectionnelles : une relation unidirectionnelle possède donc
une UnroledAssociationEnd et une RoledAssociationEnd. Ceci lui garantit la présence d’un
seul rôle sur une de ses extrémités.
Nous définissons également une relation d’association bidirectionnelle présentant un rôle
à chacune de ses extrémités. Comme posé précédemment, une relation bidirectionnelle se
définit comme la composition de deux relations unidirectionnelles. Nous conservons cette
approche dans le cadre de cette proposition. En effet, le modèle proposé garantit que, pour
une relation unidirectionnelle, un seul rôle puisse apparaı̂tre sur une des deux extrémités de
la relation. Par composition de deux relations unidirectionnelles, nous obtenons une relation
bidirectionnelle possédant exactement deux rôles. De même, dans le cas d’une relation n-aire,
cette dernière se définit comme la composition de n relations unidirectionnelles.
Nous pouvons cependant noter qu’un ensemble de règles doit être défini pour assurer la
composition des relations unidirectionnelles de manière correcte. En effet, lors de la composition de deux relations unidirectionnelles pour former une relation bidirectionnelle, ces
dernières ne peuvent pas présenter un rôle sur une même extrémité. Ces règles de composition doivent encore être définies, afin de garantir la cohérence des modèles obtenus par
assemblage de composants de modèle.
Enfin, il convient de placer les classes associatives dans notre proposition de modèle.
Nous rappelons qu’une classe associative est une association à laquelle un comportement
est ajouté par l’intermédiaire des méthodes d’une classe. Dans le cadre de nos objectifs,
nous pouvons souligner une utilisation possible des classes associatives. Disposant de deux
composants distincts, nous pouvons les assembler à l’aide d’une classe associative. Cette
dernière permet alors de gérer les échanges et les interactions entre les deux classes afin de
mettre en oeuvre leur collaboration dans le système.
Une classe associative est une classe disposant de méthodes afin de gérer le comportement
des objets mis en relation. Elle agit sur une relation d’association tout en étant une classe au
même titre que toute autre classe d’un système. De plus, cette dernière manipule l’association
et la contrôle de manière bidirectionnelle. Elle doit donc avoir un lien direct avec la classe
Association pour pouvoir accéder aux objets mis en jeu. Une classe associative est donc à
la fois une association et une classe. Par conséquent, nous la spécifions comme étant une
sous-classe d’Association et de Class afin de marquer son double rôle. Cela permet à cet
objet d’accéder à l’association bidirectionnelle dont il hérite pour effectuer un contrôle sur
les interactions entre les objets mis en relation.
L’ensemble des propositions présentées ci-dessus nous permet d’aboutir à la proposition
de modèle de relation d’association en figure 8.
16
3 VERS UNE MODIFICATION DU MÉTA-MODÈLE
ModelElement
Relationship
GeneralizableElement
UnroledAssociationEnd
0..*
Classifier
AssociationEnd
UnidirectionnalAssociation
0..*
0..*
Association
2..*
RoledAssociationEnd
Class
1..*
Role
AssociationClass
Fig. 8 – Le modèle retenu
17
3 VERS UNE MODIFICATION DU MÉTA-MODÈLE
Nous pouvons noter que ce nouveau modèle de relation d’association est proche du
modèle actuel défini par l’OMG. Cela nous permet en effet de nous fondre parfaitement
dans le modèle actuel tout en proposant des améliorations à ce dernier.
18
4 MISE EN OEUVRE DU MODÈLE
4
Mise en oeuvre du modèle
Suite au modèle proposé dans ce document, nous le mettons en oeuvre en l’implémentant.
Nous utilisons une implémentation libre du méta-modèle UML, NSUML. Cette dernière subit
ainsi des modifications pour l’adapter au nouveau méta-modèle de la relation d’association
exposé en section 3.4. Nous présentons l’implémentation du modèle au sein de NSUML, puis
nous évoquons la possibilité d’intégrer ce modèle dans l’atelier de génie logiciel ArgoUML.
4.1
Implémentation dans NSUML
Afin de démontrer la faisabilité d’une implémentation du modèle de relations d’association, nous utilisons l’implémentation réalisée dans NSUML, que nous adaptons à notre
modèle. Cette implémentation est libre et open-source 6 , ce qui nous permet alors d’en disposer pour effectuer des tests sur notre modèle. Elle est réalisée en langage Java [Sun03b].
Nous présentons à présent la version officielle de NSUML puis les modifications que nous lui
apportons.
4.1.1
Le modèle de relation d’association dans NSUML
Nous nous intéressons à la version 0.4.19 de NSUML et plus particulièrement à sa
représentation de la relation d’association. Afin de présenter le modèle de relation, nous
utilisons le modèle UML fourni en figure 9.
Nous constatons qu’une relation d’association se compose d’au moins deux entités nommées AssociationEnd. Ces objets représentent les extrémités de la relation d’association. Ils
portent la sémantique de la relation par l’intermédiaire des attributs dont ils disposent. Une
Association, ainsi qu’une AssociationEnd, sont des éléments de modèle UML (ModelElement)
et peuvent donc à ce titre apparaı̂tre dans des diagrammes UML.
Nous nous fondons sur ce modèle pour implémenter notre proposition. Nous remarquons
que son implémentation s’effectue par l’intermédiaire d’une hiérarchie de types à base d’interfaces. Ces dernières sont ensuite implémentées par des classes d’objets. Soit X un type
intervenant dans la hiérarchie de types du modèle représenté par une interface Java. Ce type
est réalisé par une classe XImpl, implémentant 7 l’interface X.
Nous souhaitons nous insérer de manière fluide dans ce modèle, sans pour autant effectuer de concessions sémantiques. Nous présentons maintenant l’implé-mentation du modèle
proposé.
4.1.2
Implémentation du modèle
Nous présentons ici l’implémentation du modèle fourni en figure 8. Afin de s’insérer
dans l’architecture globale de NSUML, nous conservons les types et classes existants en ne
s’attachant qu’à :
– remplacer ceux ne présentant pas les fonctionnalités suffisantes pour notre modèle,
– ajouter de nouveaux types et classes pour créer de nouveaux concepts.
6. elle est disponible à l’adresse : http://nsuml.sourceforge.net
7. au sens de Java, par l’intermédiaire du mot-clé implements
19
4 MISE EN OEUVRE DU MODÈLE
Fig. 9 – Modèle de l’implémentation des relations d’association dans NSUML
20
4 MISE EN OEUVRE DU MODÈLE
Nous créons tout d’abord le concept de Role à la base de l’utilisation de composants
conceptuels dans notre modèle. Comme présenté précédemment (cf. section 3.1), ce dernier
dispose de toute la sémantique de la relation d’association, qui est donc déplacée du concept
d’AssociationEnd vers celui-ci.
Nous souhaitons également disposer de deux types distincts d’Association-Ends. Nous
modifions le type et la classe représentant l’AssociationEnd, pour les remplacer par une
classe abstraite, disposant de deux sous-types : une extrémité d’association disposant d’un
Role (RoledAssociationEnd ), et une extrémité en étant dépourvue (UnroledAssociationEnd ).
Nous lions ensuite les objets de type Role aux objets RoledAssociationEnd par l’intermédiaire
d’attributs et de références internes à ces objets.
La création de ces nouveaux concepts de Role, de RoledAssociationEnd et d’UnroledAssociationEnd au niveau de l’implémentation nous mène alors à la définition de la relation
d’association unidirectionnelle (UnidirectionnalAssociation). Cette dernière est liée à une
extrémité d’association disposant d’un rôle (RoledAssociationEnd ) et à une extrémité n’en
proposant pas (UnroledAssociationEnd ). Ces liens s’effectuent par utilisation de références à
l’intérieur des classes implémentant ces concepts. Nous précisons que le concept de relation
d’association unidirectionnelle s’intègre dans la hiérarchie de types au même niveau qu’une
relation d’association. A ce titre, il s’agit donc d’un sous-type de Relationship représentant
les relations dans le langage UML.
Enfin, la définition au niveau du code du type UnidirectionnalAssociation nous mène
également à la redéfinition du type d’association bidirectionnelle en langage UML (Association). Nous conservons cette dénomination pour faciliter l’intégration de notre proposition dans l’existant. Une relation d’association bidirectionnelle se compose donc d’au moins
deux relations d’association unidirectionnelles. Une relation d’association est également un
sous-type de Relation, au même titre qu’une relation d’association unidirectionnelle. Nous
disposons ici d’une dépendance sur le cycle de vie des objets de type Association et UnidirectionnalAssociation. En effet, la destruction d’une Association implique la destruction
des UnidirectionnalAssociation la composant. Cette notion de durée de vie se verra mise en
oeuvre au cours de l’utilisation de ce modèle de relation au sein d’un AGL lors de l’instanciation et de la suppression des objets figurant dans le modèle en cours de réalisation. Il est
à noter que l’ensemble des modifications effectuées sur les différentes classes et interfaces
entraı̂nent des modifications sur le type AssociationClass. Celui-ci dispose toujours de fonctionnalités analogues à celles définies dans le modèle UML, mais une adaptation est produite
pour permettre son intégration dans le modèle ici réalisé.
L’implémentation de notre modèle se réalise en s’intégrant idéalement dans l’existant.
Aucune concession au niveau de notre proposition de modèle n’est réalisée. L’implémentation
fournie représente donc le modèle de relation d’association proposé. Cette implémentation
au sein de NSUML montre également la faisabilité d’un tel modèle au niveau de son
implémentation. De plus, cette implémentation au sein d’une librairie mettant en oeuvre
le modèle d’UML montre que le modèle de relation d’association proposé se place dans la
ligne donnée au langage UML par l’OMG [OMG03].
4.2
Intégration dans ArgoUML
La librairie NSUML étant à la base de l’atelier de génie logiciel ArgoUML, l’intégration
de la librairie modifiée peut être réalisée dans cet AGL. Il s’agit alors de réaliser l’interface
21
4 MISE EN OEUVRE DU MODÈLE
graphique adaptée aux concepts présentés dans ce document, puis de gérer les cycles de
vie des objets représentant les entités du modèle en mettant en oeuvre les mécanismes
adéquats. Un maquette de cette intégration est actuellement en cours d’élaboration. Elle
devrait aboutir rapidement à une adpatation d’ArgoUML à notre modèle. Une seconde phase
consistera alors, après validation de la maquette, à implémenter la totalité des fonctionnalités
du modèle dans ArgoUML afin de disposer de la mise en oeuvre du modèle de relation
d’association proposé dans ce mémoire.
22
5 CONCLUSION
5
Conclusion
Nous avons étudié dans ce mémoire la relation d’association dans le langage UML. Un
ensemble de propriétés lui permettent d’être un support pour la gestion de composants
conceptuels : la réciprocité, exprimée par les relations bidirectionnelles et la dépendance, exprimé par les relations intrinsèques. Nous avons alors souligné les faiblesses du méta-modèle
d’UML pour la gestion des composants conceptuels. Il en a découlé la proposition d’un
ensemble de caractéristiques pour un modèle de relation d’association permettant la mise
en oeuvre du développement à base de composants conceptuels selon une approche dirigée
par les modèles (MDA). Nous avons ensuite proposé un nouveau méta-modèle disposant de
ces caractéristiques : support de relations d’associations unidirectionnelles afin de permettre
la spécification des besoins des composants, support de mécanismes de construction de relations d’association bidirectionnelles à partir de relations d’association unidirectionnelles,
support de mécanisme permettant la décomposition de relations bidirectionnelles en associations unidirectionnelles. Une implémentation de ce modèle a alors été réalisée conformément
à ces principes. De nombreuses perspectives s’ouvrent dans la continuité de ces travaux. Il
reste tout d’abord à intégrer le méta-modèle implémenté dans un atelier de génie logiciel
tel qu’ArgoUML à fin d’expérimentation. Une seconde perspective s’ouvrant à ces travaux
est une étude exhaustive des formes de constructions d’associations à partir d’autres associations. Une troisième perspective consiste à intégrer dans les composants conceptuels un
aspect dynamique afin de disposer d’une évolution des rôles au cours du cycle de vie du composant conceptuel. Cette évolution pourrait également permettre de disposer d’un service
de trading au niveau des composants conceptuels. De tels services sont d’ores et déjà prévus
dans les futurs bus de connaissances MDA [Bez01]. Ainsi, par l’utilisation d’un tel service,
un composant donné pourrait se voir proposer des assemblages permettant de le mettre en
oeuvre tout en satisfaisant ses besoins. De plus, un échange de compétences pourrait alors
s’établir entre deux composants souhaitant coopérer. Enfin, une sémantique plus importante
pourra être intégrée dans les rôles afin que les contrôles de validité des collaborations entre
composants ne se limitent plus à des vérifications syntaxiques mais évoluent vers des tests
intégrés (scénarios d’appels de fonctionnalités devant être supportés [BBB02].
23
RÉFÉRENCES
Références
[BB02a]
[BB02b]
[BBB02]
[Bez01]
[BPLB02]
[Civ98]
[CR03]
[Fra99]
[GBHS97]
[HS98]
[MCCV03]
[OMG02a]
[OMG02b]
[OMG03]
[Poo01]
[QL03]
[Rum96]
[Ste01]
Jean Bézivin and Xavier Blanc. Promesses et interrogations de l’approche MDA.
Développeur Référence v2.17, Septembre 2002.
Jean Bézivin and Xavier Blanc. MDA : vers un important changement de paradigme en génie logiciel. Développeur Référence v2.16, Juillet 2002.
Nicolas Belloir, Jean-Michel Bruel, and Franck Barbier. Intégration du test dans
les composants logiciels. In Workshop : OCM dans l’ingénierie des SI, during
INFORSID 2002, Juin 2002.
Jean Bezivin. From object composition to model transformation. Tools’USA,
Août 2001.
Franck Barbier, Annig Le Parc-Lacayrelle, and Jean-Michel Bruel. Agrgation
et composition dans UML révision basée sur la théorie tout-partie. TSI (Techniques et Sciences Informatiques), 21(10):1343–1370, Novembre 2002.
Franco Civello. Rooted class diagrams : A notation for context-independent
models. JOOP, 11(2):55–69, Mai 1998.
Philippe Collet and Roger Rousseau. Contrôle d’admission de composants avec
des contrats comportementaux. In Langages et Modèles Objets : LMO’2003,
volume 9, pages 31–44, Septembre 2003.
Robert B. France. A problem-oriented analysis of basic UML static requirements
modeling concepts. ACM SIGPLAN Notices, 34(10):57–69, 1999.
Ian Graham, Julia Bischof, and Brian Henderson-Sellers. Associations considered
a bad thing. JOOP, 9(9):41–48, Février 1997.
Brian Henderson-Sellers. Open relationships - associations, mappings, dependencies, and uses. JOOP, 10(9):49–57, Février 1998.
Alexis Muller, Olivier Caron, Bernard Carré, and Gilles Vanwormhoudt.
Réutilisation d’aspects fonctionnels : des vues aux composants. L’Objet, 9(12):241–255, Septembre 2003.
OMG.
Common Object Request Broker Architecture: Core specification,
Décembre 2002. http://www.corba.org.
OMG.
Meta Object Facility (MOF) Specification, Avril 2002.
http://www.omg.org.
OMG.
OMG Unified Modeling Language Specification, Mars 2003.
http://www.omg.org.
John D. Poole. Model driven architecture : Vision, standards and emeerging
technologies, Avril 2001.
Laurent Quintian and Philippe Lahire. Vers une meilleure intégration des composants sur l’étagère. In Actes de la journée OCM 2003, 2003.
James Rumbaugh. Model for design : Generating code for associations. JOOP,
8(9):13–17, Février 1996.
Perdita Stevens. On associations in the unified modelling language. In Martin Gogolla and Cris Kobryn, editors, UML 2001 - The Unified Modeling Language. Modeling Languages, Concepts, and Tools. 4th International Conference,
24
RÉFÉRENCES
[Sun03a]
[Sun03b]
[Szy99]
[VU]
Toronto, Canada, October 2001, Proceedings, volume 2185 of LNCS, pages 361–
375. Springer, 2001.
Sun. Java 2 Platform Entreprise Edition Specification, v 1.4, Avril 2003.
http://java.sun.com/j2ee.
Sun.
Java 2 Platform Standard Edition Documentation, Avril 2003.
http://java.sun.com.
Clemens Szyperski. Component Software : Beyond Object-oriented Programming.
Addison-Wesley, 1999.
Sylvain Vauttier and Christelle Urtado. Une approche pratique de la réutilisation
de composants conceptuels avec UML.
25
RÉFÉRENCES
Résumé
Après avoir principalement porté sur les composants logiciels, une nouvelle tendance se dessine actuellement dans le domaine du développement orienté composant.
Il s’agit de changer le niveau d’abstraction et de consi-dérer des approches dirigées
par les modèles. Les composants logiciels jusqu’à présent décrits par leur codage dans
un langage de programmation donné sont alors remplacés par des composants conceptuels. Ces derniers sont des entités de modèles réellement pérennisables dans le cycle
de vie des logiciels. Ils sont donc considérés comme des composants de premier ordre.
Si l’on peut définir le développement à base de composants comme la réutilisation et
l’intégration de modèles décrivant des composants, l’avancée actuelle des recherches ne
permet pas encore de manipuler ces entités de manière efficace. Il n’est pas possible
d’effectuer des décompositions et recompositions de composants de modèle UML, suite
à des limitations inhérentes au méta-modèle de ce dernier. Ce mémoire présente les
recherches dans ce domaine en soulignant les faiblesses des relations d’associations en
UML dans la gestion de la conception pour et par la réutilisation de tels composants.
Un nouveau méta-modèle de relations d’associations est alors proposé, ainsi qu’une
implémentation de celui-ci au sein de NSUML.
Abstract
Component-based software engineering is moving to a new trend. Abstraction level
is moving and leads to consider model-driven approaches. Software components described by their code in a given programming language are replaced by conceptual
components. These components are parts of models with a high level of reusability
in software life cycle. Component-based software engineering consists in reusing and
integrating models describing components, but up to now researches don’t allow to
manage efficiently these entities. Due to UML meta-model limitations, UML component models decompositions and recompositions are not yet allowed. This report
presents research done in this domain and shows the weakness of association relationships in UML for management of conception by and for reuse. A new meta-model for
association relationships is then proposed, and its implementation in NSUML.
Mots-clés : approche dirigée par les modèles, composants conceptuels, réutilisation de
composants, assemblage de composants, relations d’association, méta-modélisation, UML,
MDA, MOF
Keywords : model-driven approaches, conceptual components, component reuse, component assembling, association relationships, metamodeling, UML, MDA, MOF
26