Un autre modèle de relation d association pour améliorer la réutilisation de composants de

Transcription

1 Eric Mendizabal Université de Montpellier II DEA d Informatique Année 2002 / 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

2 TABLE DES MATIÈRES Table des matières 1 Introduction 3 2 Relation d association et composants conceptuels en UML La relation d association La propriété de réciprocité La propriété de dépendance Les composants conceptuels Production de composants pour la réutilisation Production de composants par réutilisation Vers une modification du méta-modèle Les concepts d association unidirectionnelle et de rôle Une approche par composition Une approche par héritage Le modèle proposé Mise en oeuvre du modèle Implémentation dans NSUML Le modèle de relation d association dans NSUML Implémentation du modèle Intégration dans ArgoUML Conclusion 23 1

3 TABLE DES FIGURES Table des figures 1 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

4 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

5 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

6 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 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

7 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

8 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 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

9 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 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

10 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 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

11 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

12 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

13 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

14 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

15 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

16 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 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

17 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

18 3 VERS UNE MODIFICATION DU MÉTA-MODÈLE ModelElement Relationship GeneralizableElement UnroledAssociationEnd Classifier 0..* AssociationEnd UnidirectionnalAssociation Association 0..* 0..* 2..* RoledAssociationEnd Class 1..* Role AssociationClass Fig. 8 Le modèle retenu 17

19 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

20 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 Le modèle de relation d association dans NSUML Nous nous intéressons à la version 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é 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 : 7. au sens de Java, par l intermédiaire du mot-clé implements 19

21 4 MISE EN OEUVRE DU MODÈLE Fig. 9 Modèle de l implémentation des relations d association dans NSUML 20

22 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