La mod�lisation conceptuelle (Mylopoulos, 1998) consiste � construire des repr�sentations abstraites de certains aspects des syst�mes physiques et sociaux et de leur environnement dans le monde qui nous entoure.

Des progr�s en mod�lisation conceptuelle consistent � d�finir des m�canismes d?abstraction de mod�lisation simples, puissants et de haut niveau, qui permettraient de r�duire la distance entre les concepts familiers aux acteurs dans les domaines d?application et leur repr�sentation dans les mod�les. Les associations g�n�riques (Dahchour et al., 2005) sont des exemples typiques de tels m�canismes d?abstraction. Les associations g�n�riques les plus connues sont l?association, la sp�cialisation/g�n�ralisation, la classification/instanciation, et l?agr�gation/d�composition. D?autres associations g�n�riques ont �t� identifi�es dans la litt�rature, telle que role-of (Dahchour et al., 2002) (Wieringa et al., 1995), (Gottlob et al., 1996), (Kristensen, 1996), (Wong et al., 1997), (Steimann, 2000(b))

L?association role-of associe une classe de r�les (par exemple, Employ�, Etudiant) � une classe de base dite classe d?objets (par exemple, Personne). Les instances de la classe de r�les repr�sentent des r�les jou�s par les instances de la classe d?objet. Par exemple, Ali, initialement instance de Personne peut devenir plus tard une instance de Etudiant et/ou une instance d?Employ�. Ainsi, pour role-of, il serait possible pour un objet, instance d?une classe, de changer d?�tat et de devenir, en s�quence ou simultan�ment, une instance d?une autre classe.

L?association role-of est proche de la g�n�ralisation associant une sous-classe (par exemple, Voiture, Bus) � une superclasse (par exemple, V�hicule) mais elle en diff�re par son aspect dynamique. En effet, contrairement � role-of, dans le contexte de la g�n�ralisation, un objet est une instance statique d?une classe. En effet, une instance de Voiture, ne peut jamais devenir une instance de la classe Bus.

Le mod�le de donn�es d?UML (OMG, 2004(a)), le standard de la mod�lisation objet, comprend trois associations g�n�riques principales�: l?association, la g�n�ralisation, et la d�pendance existentielle. A partir de ces trois associations de base, UML d�finit d?autres cat�gories d?associations par son m�canisme de st�r�otype.

Actuellement, il n?existe pas un �quivalent � l?association role-of dans UML. Par cons�quent, quand on utilise UML pour mod�liser une application, on se trouve contraint de repr�senter les aspects dynamiques des objets par les associations disponibles dans UML, notamment la g�n�ralisation. Ceci r�sulte en une mod�lisation incorrecte avec toutes les cons�quences que cela peut avoir sur les �tapes de conception et d?impl�mentation.

Notons que UML (OMG, 2004(a)) d�finit un concept de role, compl�tement diff�rent de celui associ� � l?association role-of. En effet, UML distingue entre les r�les statiques et les r�les dynamiques. Les premiers sont h�rit�s du mod�le entit�-association. Ils caract�risent la participation d?une classe dans une association (Chu et al., 1997) tandis que les seconds sont h�rit�s des m�thodes � base d?objets telle que OORAM (Reenskaug et al., 1996). Il s?agit d?objets qui participent dans les diagrammes de collaborations d?UML. Une �tude d�taill�e sur les r�les d?UML et les probl�mes qu?ils posent a �t� r�alis�e par (Steimann, 2000(a)). Elle est discut�e dans la section sur les travaux connexes.

L?objectif du pr�sent travail est d?�tendre UML par l?association role-of d�finie dans (Dahchour et al., 2002). Ce travail �tend celui pr�sent� dans (Dahchour et al., 2006).

Cet article est structur� comme suit. La section 2 pr�sente notre mod�le des r�les. La section 3 d�crit l?architecture � quatre couches d?UML. La section 4 d�crit le processus d?int�gration des r�les dans UML. La section 5 discute les travaux connexes. La section 6 conclut le travail.

Dans cette section nous pr�sentons de mani�re tr�s succincte la s�mantique de l?association role-of. Les d�tails de cette s�mantique sont d�finis dans (Dahchour et al., 2002), (Dahchour et al., 2004).

L?association role-of (sch�matis�e par O ?? R) relie une classe, appel�e classe d?objet (O), et une autre classe, appel�e classe de r�les (R), qui d�crit les r�les dynamiques pour la classe d?objets O. On dit que les instances de la classe d?objets O gagnent des r�les (ou jouent des r�les), lesquels sont des instances de la classe de r�les R. Les classes d?objet sont utilis�es pour repr�senter les propri�t�s statiques des entit�s alors que les classes de r�les sont utilis�es pour mod�liser leurs aspects dynamiques. Une entit� non �volutive est repr�sent�e comme une instance permanente et exclusive d'une classe. Une entit� �volutive, en plus d'�tre une instance permanente et exclusive d'une classe d?objet, est repr�sent�e par un ensemble d?instances de la classe de r�les. Quand une entit� gagne un nouveau r�le, une nouvelle instance de la classe des r�les appropri�e est cr��e. Si elle perd un r�le, l?instance de la classe des r�les correspondante est supprim�e. Par la suite, les instances de la classe d?objets s?appellent des objets, tandis que les instances de la classe des r�les s?appellent des r�les.

La Figure 1 montre deux associations role-of qui relient la classe d?objets Personne aux classes de r�les Etudiant et Employ�. La classe Personne d�finit les propri�t�s permanentes des objets personne: nom, adresse, et t�l�phone. La classe Etudiant d�finit quelques propri�t�s transitoires en tant qu?�tudiants : univ, etud#, sp�cialit�, et cours qui est un attribut multi-valu�. De la m�me fa�on, la classe Employ� d�finit quelques propri�t�s transitoires en tant qu?employ�s: Dept, emp#, fonction, et salaire.

Notre mod�le de r�les supporte �galement l?instanciation multiple de la m�me classe. En effet, un objet peut devenir une instance plus qu'une fois de la m�me classe, tout en perdant ou maintenant son appartenance � la classe. Par exemple, un �tudiant peut �tre inscrit dans deux universit�s diff�rentes. Il jouera donc deux r�les diff�rents.

Soit une classe d?objets O en relation avec les classes des r�les R₁ et R₂. Les objets peuvent changer leur classification selon les diff�rents cas d�crits ci-dessus.

• L'�volution not�e R₁?^ev R₂ pour les classes de r�les R₁ et R₂, avec R₁ distincte de R₂ : cette notation indique qu'un objet jouant le r�le r1 (instance de R₁) peut perdre r1 et gagner le r�le r2 (instance de R₂). En plus, les r�les de R₂ ne peuvent pas �tre cr��s ind�pendamment des r�les de R_1. Une instance de R₂ est cr��e n�cessairement par �volution d?une instance de R₁. Les �volutions peuvent �tre bidirectionnelles ou unidirectionnelles selon que le r�le perdu par R₁ peut �tre r�cup�r� plus tard ou pas. Des exemples d'�volutions bidirectionnelles sont "C�libataire ?^ev Mari�" et "Employ� ?^ev Ch�meur". Des exemples d'�volution unidirectionnelle sont " Employ� ?^ev Retrait�" et "Etudiant ?^ev Laur�at".

• L'extension not�e R₁ ?^ext R_2, avec R₁ non n�cessairement distincte de R₂, indique que l?objet qui joue le r�le r1 de R₁ peut gagner un nouveau r�le r2 de R₂ en retenant r1. Des exemples de ce type de transition sont�"Etudiant ?^ext Employ�" et "Professeur ?^ext ChefDept". Lorsque la classe source R et la classe cible sont les m�mes, cela autorise l?objet qui joue le r�le r1 de R de gagner un nouveau r�le r2 de la m�me classe R, tout en retenant r1. Les exemples suivants montrent cet aspect�: "Etudiant ?^ext Etudiant" quand une personne est simultan�ment �tudiant dans plus d'une universit�, et "Employ� ?^ext Employ�" quand une personne est simultan�ment employ�e dans plus d'une compagnie.

• L'acquisition, not�e ?R, indique qu'un objet peut acqu�rir librement un r�le de R. Par exemple, "?Etudiant" signifie que les personnes peuvent devenir des �tudiants. Remarquez que "?Etudiant" pourrait �tre not� comme "Personne ?^ext Etudiant", o� la classe Personne est la classe d?objets pour la classe des r�les Etudiant.

• La perte, not�e R?, indique qu'un objet peut perdre librement un r�le de R. Par exemple, "Etudiant?" signifie que les personnes cessent d?�tre des �tudiants. Remarquez que "Etudiant?" pourrait �tre not� comme "Etudiant?^ev Personne", o� la classe Personne est la classe d?objets pour la classe des r�les Etudiant.

Soit une classe d?objets O en relation avec les classes des r�les R₁ et R₂. Un pr�dicat de transition est associ� � R₁ pour d�crire les conditions n�cessaires et/ou suffisantes sur la fa�on dont les objets jouant des r�les de R₁ peuvent explicitement ou automatiquement acqu�rir des r�les dans R₂. La classe source R₁ peut �tre une classe des r�les (dans une �volution ou une extension) ou une classe d?objets (dans une acquisition).

Les pr�dicats de transition sont d�crits en utilisant le langage d�claratif formel OCL (Object Constraint Language) d?UML (Clark et al., 2002). Dans ce qui suit, nous donnons quelques exemples de pr�dicats de transition�:

• Employ� ?^ev Retrait�: le pr�dicat �ge ? 55 ? TempsTravail ? 20 associ� aux employ�s qui deviennent des retrait�s.

• Employ� ?^ev Ch�meur�: le pr�dicat contractExpirDate ? DateCourante associ� aux employ�s qui perdent automatiquement leur emploi lorsque la date de contrat est expir�e. Un autre pr�dicat associ� aux ch�meurs qui peuvent devenir employ�s en signant un nouveau contrat de travail.

• Professeur?^ext ChefDept�: le pr�dicat grade=Professeur de l?Enseignement Sup�rieur ? exp�rience = 6 ans associ� aux professeurs qui deviennent des chefs de d�partements.

• Etudiant ?^ext Etudiant�: le pr�dicat nbProgs ? max d�clare le maximum de programmes auxquels un �tudiant peut s?inscrire.

• ? Employ�: le pr�dicat �ge ? 18 attach� aux personnes, montre que seuls les adultes peuvent �tre des employ�s.

Cette section d�crit l?architecture � quatre couches d?UML, les paquetages logiques permettant d?organiser les diff�rents m�tamod�les du langage et le formalisme de sp�cification du m�tamod�le d?UML.

L'architecture d?UML est bas�e sur une structure � quatre niveaux d?abstraction: M0 (objets ou donn�es utilisateurs), M1 (mod�le), M2 (m�ta-mod�le) et M4 (m�ta-m�ta-mod�le) (OMG, 2004(a)). Chaque niveau Mi est vu comme ?instance? du niveau sup�rieur Mi+1 (cf. figure 2). Certains chercheurs parlent plut�t de conformit� entre les niveaux Mi et Mi+11.

• M0 (objet) : C?est la couche o� r�side les objets factuels souvent appel�s ��donn�es utilisateurs��. Cette couche d?abstraction est utilis�e pour formaliser des expressions sp�cifiques � un objet donn�.

• M1 (mod�le) : C?est la couche qui h�berge les mod�les UML d�velopp�s pour sp�cifier un domaine d?application donn�. Elle d�crit la structure de la couche M0.

• M2 (m�ta-mod�le) : C?est la couche qui d�finit les �l�ments syntaxiques et s�mantiques des mod�les du niveau M1. Les concepts UML, ?Class?, ?Attribute?, ?Instance?, etc., sont d�finis � ce niveau.

• M3 (m�ta-m�tamodel)�: Cette couche d�finit un langage de haut niveau pour sp�cifier les m�tamod�les. Elle est instance d?elle m�me. Le m�tamod�le d?UML (niveau M2) en est une instance particuli�re. Ce langage est aussi connu sous le nom de MOF (Meta Object Facility) (OMG, 2004 (c)).

Nous nous int�ressons dans ce travail � la couche M2 (m�ta-mod�le) qui sera d�taill�e dans la sous-section suivante.

La complexit� du m�tamod�le d?UML (niveau M2) est g�r� en organisant celui-ci en des paquetages logiques.

Ces paquetages regroupent des m�taclasses qui repr�sentent une forte coh�sion interne et un faible couplage avec les m�taclasses d?autres paquetages. Cette couche comprend, entre autres, le paquetage Foundation. Ce paquetage est l'infrastructure du langage UML qui d�finit la structure statique des mod�les du niveau M1. Il est compos� de trois sous-paquetages�: Core, Extension Mechanisms et Data Types (cf. figure 3).

Le paquetage Core d�finit les concepts de base pour la construction d?un mod�le objet. On y distingue deux types de constructions, abstraites et concr�tes. Les constructions abstraites ne sont pas instanciables et sont g�n�ralement employ�es pour r�ifier les constructions de base et organiser le m�ta-mod�le d?UML. Les constructions abstraites d�finies dans le paquetage Core incluent ModelElement, Relationship et Classifier. Un �l�ment quelconque du mod�le est une sous-classe directe ou indirecte de ModelElement, h�ritant de lui l'attribut name, qui conf�re un nom � n'importe quel �l�ment existant dans UML. Les constructions concr�tes sont, par contre, instanciables. Elles incluent Class, Attribute, Operation et Association.

Le paquetage Extension Mechanisms offre des m�canismes permettant d?ajouter de nouveaux �l�ments dans UML sans devoir changer sa structure de mani�re substantielle.

Le paquetage Data Types d�finit les types de donn�es de base utilis�s dans la sp�cification des autres paquetages.

Une extension substantielle d?UML affecte le paquetage Core. Dans le cadre de notre travail, la plupart des concepts requis pour la d�finition des r�les seront incorpor�s dans ce paquetage.

Nous rappelons ci-dessous les �l�ments du formalisme de sp�cification du m�tamod�le d?UML que nous respectons dans nos d�finitions. Dans UML, un m�ta-mod�le est d�crit d'une fa�on semi-formelle en utilisant les trois vues suivantes�:

• Syntaxe�abstraite (Abstract syntax),

• R�gles de bonne conception (Well-formedness rules)

• S�mantique (Semantics).

La syntaxe abstraite est pr�sent�e � l?aide d?un diagramme de classes UML. Elle d�finit les constructions et leurs liens avec d?autres constructions. Elle peut �tre accompagn�e d?une description non formelle en langage naturel d�crivant chaque m�ta-classe et chaque association du diagramme.

Il s?agit d?un ensemble de r�gles d�finissant la s�mantique statique des diff�rentes constructions du diagramme de classes d�fini dans ��la syntaxe abstraite�� ci-dessus. Chacune de ces r�gles est d�finie par une expression logique en OCL (Object Constraint Language) (Clark et al., 2002), (OMG, 2004(b)) accompagn�e �ventuellement de clarifications exprim�es en langage naturel.

Elle d�crit la s�mantique dynamique des diff�rentes constructions d�finies dans ��la syntaxe abstraite��. Elle est d�crite principalement en langage naturel, mais peut inclure une certaine notation additionnelle, selon le mod�le d�crit.

Nous pr�sentons ci-dessous le processus d?int�gration de l?association role-of dans UML en respectant les �l�ments du formalisme de sp�cification pr�sent�s dans la Section 3.

Nous d�finissons ici le m�tamod�le de l?association role-of pr�sent�e dans la section 2.

Nous d�finissions role-of comme sous-classe directe de Relationship et ObjectRoleElement comme sous-classe directe de ModelElement. La m�taclasse ObjectRoleElement repr�sente les classes d?objets et les classes de r�les impliqu�es dans une association role-of. Notre m�tamod�le est report� � la Figure 4. Nous allons d�tailler dans la suite chacun de ses �l�ments. Pour mieux clarifier les �l�ments du m�tamod�le de la figure 4, la figure 5 pr�sente une association role-of reliant deux classes A et B.

Les classes A et B sont des instances de la m�taclasse ObjectRoleElement. Par abus de langage on dira que A et B sont des ObjectRoleElement avec les pr�cisions suivantes�:

• A (la classe d?objets) est un ObjectRoleElement avec l?attribut isObject=True et isRole=False.

• B (la classe de r�les) est un ObjectRoleElement avec l?attribut isRole=True et isObject=False.

Donc A et B de la figure 5 repr�sentent, respectivement, les qualificateurs object et role de la figure 4. L?association role-of entre A et B, peut �tre d�compos�e en deux sous-liaisons�: objectLink (reliant un r�le � un objet) et roleLink (reliant un objet � un r�le) comme le montre la figure 4.

• 1 du c�t� du qualificateur object�: un seul ObjectRoleElement de type classe d?objects (c-�-d un ObjectRoleElement avec les attributs isObject=true) participe dans l?association role-of.

• 1 du c�t� du qualificateur role�: un seul ObjectRoleElement de type classe de r�les (c-�-d un ObjectRoleElement avec les attributs isRole=true) participe dans l?association role-of.

• 1 du c�t� du qualificateur objectLink�: un ObjectRoleElement ne peut avoir qu?une seule liaison envers la classe d?objets.

• * du c�t� du qualificateur roleLink�: un ObjectRoleElement peut avoir plusieurs liaisons envers des classes de r�les.

C?est une sous-classe de ��ModelElement�� qui peut participer dans une association role-of. Un ObjectRoleElement est une m�ta-classe abstraite.

Attributs�:

• isObject�: il est de type Bool�en. Il a la valeur True pour une classe d?objets.

• isRole�: il est de type Bool�en. Il a la valeur True pour une classe de r�les.

Pour les classes interm�diaires telle que R₁ dans la composition de role-ofs R₂ ?? R₁ ?? O, les attributs isObject et isRole�auront tous les deux la valeur ��vrai��, puisque R₁ est � la fois une classe d?objets et une classe de r�les.

Associations�:

• RoleLink�: c?est la liaison partant de la classe d?objets vers la classe de r�les.

• ObjectLink�: c?est la liaison partant de la classe de r�les vers la classe d?objets.

Dans le m�ta-mod�le, role-of est une sous classe directe de Relationship. Elle repr�sente le lien entre une classe d?objets et une classe de r�les.

Attributs�:

• discriminateur�: indique la partition � la quelle le lien de role-of�appartient. Il d�signe tous les liens de role-of qui partagent la m�me classe d?objets. Chaque partition repr�sente une dimension orthogonale qui regroupe un ensemble de classes de r�les correspondant � une classe d?objets. Les classes de r�les de la m�me partition ont tous le m�me nom de discriminateur.

• lossPredicate�: une assertion d�crivant les conditions n�cessaires et/ou suffisantes sur la fa�on dont les objets peuvent explicitement ou automatiquement perdre des r�les.

• acquisPredicate�: une assertion d�crivant les conditions n�cessaires et/ou suffisantes sur la fa�on dont les objets peuvent explicitement ou automatiquement gagner des r�les.

Associations�:

• object�: d�signe un ObjectRoleElement qui peut jouer un r�le.

• role�: d�signe un ObjectRoleElement qui repr�sente un �tat possible d?un objet.

L?association Migration est une classe-association r�cursive qui relie une classe d?ObjectRoleElement appel�e classe source et une classe d?ObjectRoleElement appel�e classe cible (target). Elle permet de sp�cifier les notions d?�volution et d?extension (voir section�2.2) ainsi que les pr�dicats de transition d?objets (voir section�2.3).

Attributs�:

• mode�est un type �num�r�, le r�le de cet attribut est de d�finir le mode de migration, il peut prendre une des deux valeurs�: ��evolution���ou ��extension��.

• transitionPredicate�est de type Assertion. Il d�crit les conditions pour qu?une instance de la classe source puisse migrer vers la classe destination.

Associations�:

• source d�signe une classe de r�les (c-�-d une classe ObjectRoleElement avec l?attribut isRole=true) qui va subir les r�gles de l?�volution ou d?extension.

• target d�signe la classe des r�les destination apr�s la v�rification des conditions de transition sur la classe source.

En plus des op�rations pr�d�finies dans OCL, nous d�finissons quelques autres op�rations qui seront utilis�es dans les r�gles OCL ci-dessous.

• object�: fonction qui retourne l?object de ObjectRoleElement qui l?a appel�.

• object = self.objectLink.object

• role�: fonction qui retourne l?ensemble de r�les de ObjectRoleElement qui l?a appel�.

• role = self.roleLink.role

• getId()�: fonction qui retourne l?identifiant de ObjectRoleElement concern�.

• destroy()�: fonction qui d�truit l?ObjectRoleElement qui l?a appel�.

• make()�: fonction qui cr�e un r�le pour l?ObjectRoleElement qui l?a appel�.

Cardinalit�s�: chaque instance de la classe des r�les est en relation avec exactement une instance de chaque classe d?objets.

De m�me, chaque instance de la classe d?objet peut �tre en relation avec plusieurs instances de la classe des r�les, ceci n?exprime aucune contrainte � devoir �crire avec OCL.

• Identit� de l?objet�: une instance de la classe des r�les a son propre rid (role-identity), diff�rent de toutes les autres instances de la classe des r�les et aussi de toutes les instances de la classe d?objets.

• Un ObjectRoleElement qui est racine (c.�.d isObject=true et isRole=false) ne peut avoir aucun objectLink.

• Un ObjectRoleElement qui est Leaf (c.�.d isObject=false et isRole=true) ne peut avoir aucun roleLink.

• On ne peut pas cr�er un r�le sans avoir cr�er au pr�alable l?objet correspondant.

• Des changements (suppression, cr�ation) dans la classe des r�les n?affecte pas la classe d?objets, mais l?inverse n?est pas vrai, notamment dans le cas o� on supprime l?objet tous les r�les de cet objet sont automatiquement supprim�s.

• La perte d?un r�le est contr�l�e par l?attribut lossPredicate du mod�le
  role-of.�Quand l?assertion lossPredicate est satisfaite, on d�truit le r�le de cette liaison. La r�gle exprimant cette action est comme suit.

• L?acquisition d?un r�le est contr�l�e par l?attribut acquisPredicate du mod�le role-of.�Quand l?assertion acquisPredicate est satisfaite on construit un nouveau r�le pour cette liaison. La r�gle exprimant cette action est la suivante:

L?attribut Mode de la classe migration est de type Mode, qui est un st�r�otype du type Enumeration. Il d�finit l?ensemble des modes de transition entre la classe source et la classe destination, il y a deux cas possibles�: �volution et extension (cf. Figure 6).

R�gles associ�es aux modes ���volution�� et ��extension��.

A la classe Migration nous associons deux r�gles r�gissant les modes ���volution�� et ��extension�� des r�les d�finis dans la section 2.2.

Pour l?�volution, la r�gle doit v�rifier les conditions suivantes�:

• Le mode de migration est ?�volution?.

• Les classes source et destination sont des classes de r�les.

• Satisfaction du pr�dicat transitionPredicate de la classe migration.

• Le r�sultat de la r�gle est�la destruction du r�le de la classe source et la cr�ation du r�le de la classe destination.

La r�gle OCL exprimant ces contraintes est la suivante�:

Pour l?extension, la r�gle doit v�rifier les conditions suivantes�:

• Le mode de migration est ?extension?.

• Les classes source et destination sont des classes de r�les.

• Satisfaction du pr�dicat transitionPredicate de la classe migration.

• Le r�sultat de la r�gle est la cr�ation du r�le de la classe destination. La r�gle OCL exprimant ces contraintes est la suivante�:

Dans ce paragraphe on pr�sentera le nouveau type de donn�es qu?on a d�j� utilis� dans notre mod�le qui est Assertion (cf. Figure 7).

Ce type est utilis� pour d�finir les pr�dicats tels que acquisPredicate, lossPredicate et transitionPredicate. Ce type est constitu� par l?attribut condition et la m�thode isSatisfied()�:

• condition�: est une expression �crite en OCL compos�e par un ensemble de clauses d�finissant les conditions d?acquisition ou de perte d?un r�le, ainsi que les contraintes li�es � la migration vers une autre classe de r�les.

• isSatisfied()�: fonction qui v�rifie le respect de l?attribut condition, et qui retourne les deux valeurs true ou false.

Nous ne traitons pas dans cette section des travaux, tr�s nombreux, concernant les r�les et les concepts similaires. Nous les avons largement discut�s dans (Dahchour et al., 2004). La plupart des travaux visant � �tendre UML par de nouveaux concepts recourent aux m�canismes des st�r�otypes (Gogolla et al., 2002). A titre d?exemple, cette approche a �t� utilis�e par (Luj�n-Mora et al., 2002) pour �tendre UML par les concepts relatifs � la mod�lisation multidimensionnelle.

Notons que les st�r�otypes ne permettent pas de changer les caract�ristiques fondamentales des �l�ments auxquels ils sont appliqu�s. A titre d?exemple, si nous appliquons un st�r�otype � une classe, l'�l�ment r�sultant reste toujours une classe, avec la s�mantique et tous les aspects structuraux attribu�s aux classes. On peut, n�anmoins, ajouter de nouvelles restrictions aux �l�ments du mod�le. Par exemple, nous pourrions cr�er un st�r�otype applicable � une classe et d�finir une restriction ne permettant pas l'instantiation des classes auxquelles le st�r�otype est appliqu�. Dans ce cas-ci, l'�l�ment r�sultant serait une classe abstraite.

Ainsi les st�r�otypes ne devraient �tre utilis�s que pour �tendre UML par des concepts dont la s�mantique est l�g�rement diff�rente des �l�ments pr�d�finis dans le m�tamod�le d?UML. Pour les concepts qui sont substantiellement diff�rents de ces derniers, il y a de plus en plus de travaux qui, au lieu d?utiliser les st�r�otypes, proposent d?�tendre le m�tamod�le m�me d?UML. C?est le cas par exemple de (Hachani et al., 2005) qui �tend UML par les concepts relatifs � la programmation par aspects, (Filho et al., 2002) qui �tend UML par un mod�le de propri�t�s (Features Model) ou encore (Clarke et al., 2002) qui �tend UML par un mod�le de composition. Notre approche pour int�grer l?association role-of dans UML s?inspire de ces derniers travaux.

Nous discutons dans la suite les travaux, tr�s limit�s, qui traitent de l?int�gration des r�les dans UML.

Nous nous accordons avec (Depke et al., 2000) sur le fait que les r�les associ�s aux diagrammes de collaboration d?UML ne sont pas appropri�s pour capturer la s�mantique sous-jacente aux r�les de l?association role-of ainsi que sur les limites des st�r�otypes � int�grer ces derniers dans UML. Nous divergeons sur les points suivants.

D?abord, les mod�les de r�les respectifs que nous proposons d?int�grer dans UML ne sont pas les m�mes. Le travail de (Depke et al., 2000) se base essentiellement sur les travaux (Gottlob et al., 1996) et (Kristensen, 1996) que nous avons d�j� discut� dans (Dahchour et al., 2004). Par cons�quent, les m�tamod�les correspondant ne sont pas les m�mes. A titre d?exemple, dans le m�tamod�le de la Figure 6 nous d�finissons les notions de lossPredicate, aquisPredicate et tansitionPredicate relatives aux contraintes d?abandon et d?acquisition des r�les totalement absentes dans le m�tamod�le des r�les de (Depke et al., 2000).

Par ailleurs, (Depke et al., 2000) d�finit la m�taclasse Role-of relationship comme sous classe de la m�taclasse Association et consid�re ainsi role-of comme un cas particulier de l?association. Cela cr�e une ambigu�t� inutile similaire � celle induite en consid�rant l?agr�gation/composition comme un cas particulier de l?association. Cette approche a �t� largement critiqu�e dans la litt�rature (voir par exemple (Bruel et al., 2001)). Notre m�tamod�le des r�les d�finit la m�taclasse Role-of comme sous classe de la m�taclasse Relationship et consid�re ainsi role-of comme association g�n�rique � part enti�re au m�me titre que la g�n�ralisation et l?agr�gation telle qu?elle a �t� red�finie dans (Bruel et al., 2001).

�(Steimann, 2000(a)) critique s�v�rement le concept des r�les adopt� par UML et sugg�re de le remplacer par son propre mod�le de r�les (Steimann, 2000(b)) en agissant sur le m�tamod�le d?UML. N�anmoins, (Steimann, 2000(a)) donne juste la syntaxe abstraite de son m�tamod�le de r�les. Il n?aborde pas les deux autres parties du formalisme de sp�cification d?UML. Ainsi, aucune r�gle OCL n?a �t� d�finie pour exprimer la s�mantique des r�les. Le m�me auteur discute dans (Steimann, 2001) une version de r�les qui peut �tre confondue avec la notion d?interfaces d?UML. Par ailleurs, l?auteur propose dans (Steimann et al., 2002) un noyau de langage de mod�lisation objet beaucoup plus r�duit que la version actuelle d?UML. Dans la liste des concepts de base constituant ce noyau figure le concept de type qui peut �tre un type naturel appel� classe ou type de r�le appel� r�le. Ce dernier repr�sente la version des r�les propos�e dans (Steimann, 2001).

�(Guizzardi et al., 2004), de son c�t�, propose un profile ontologique bien fond� autour des classeurs2 d?UML. Il propose notamment un ensemble de st�r�otypes (kind, phase, role, mixin) de la classe Class permettant une analyse tr�s fine des diff�rents types de classeurs. Dans le m�me ordre d?id�e (Li, 2005) propose dans son projet de th�se de revoir compl�tement les fondements ontologiques des constructeurs d?UML notamment le concept du r�le qu?il propose de red�finir � la lumi�re des nombreux travaux traitant de ce concept. L?objectif vis� �tant de proposer une version d?UML plus appropri�e pour la mod�lisation conceptuelle.

Dans cet article, nous avons pr�sent� l?int�gration d?un mod�le de r�les dans le langage UML. Tout d?abord, nous avons pr�sent� l?association role-of sur laquelle se base ce travail. Ensuite, nous avons pr�sent� la structure et l?architecture du langage UML notamment les paquetages de base qui sont affect�s par l?int�gration de notre association role-of. Enfin, nous avons pr�sent� notre approche pour �tendre UML par le concept de r�les en suivant la m�me d�marche utilis�e par UML lui-m�me pour d�finir ses propres m�ta-mod�les. Cette extension permettra d?utiliser l?association role-of dans la phase de mod�lisation au m�me titre que les associations g�n�riques d�j� offertes par UML.