Finansal araçlardan kaynaklanan risklerin niteliği ve düzeyi

L’un des premiers systèmes à base de rôle était celui de Bachman et Daya [7] qui étendait l’expres- sivité d’un modèle réseau avec la notion de rôle. Par la suite, les propositions autour de la notion de rôle se sont orientées davantage vers les systèmes à objets et notamment les SGBD à objets.

Dans le modèle E/A et ses extensions (UML et ORM notamment), le terme rôle désignait uniquement un emplacement nommé pour une association. C’est un autre sens que nous lui attribuons ici.

5.2.1 La notion de rôle

La plupart des modèles à objets considèrent qu’un objet ne peut être instance que d’une classe à la fois (en dehors de la généralisation) et qu’il ne peut pas en changer. Ces hypothèses ne sont cependant pas adaptées à la modélisation de certaines situations dynamiques du monde réel. L’exemple le plus repris dans la littérature [100, 47, 64, 28] est celui d’un étudiant devenant un employé. Dans un modèle objet classique, les classesÉTUDIANT etEMPLOYÉ ont la même super-classe PERSONNE, mais une instance

CHAPITRE 5 — Modèles à base de rôles 57

créée en tant qu’étudiant ne peut devenir ensuite un employé. Dans un modèle à base de rôles,ÉTUDIANT etEMPLOYÉsont des rôles qu’une personne peut jouer parmi d’autres. Ils permettent de voir la personne sous un point de vue particulier.

Le concept de rôle répond donc à deux besoins particuliers apparaissant lorsque l’on veut modéliser des entités évolutives avec des modèles à objets :

• le changement dynamique de type,

• un accès dépendant du contexte (utilisation d’une perspective particulière).

Dahchour et al. ajoutent un troisième besoin à cette liste [28] : l’instanciation multiple du même type (ex. : un étudiant peut être enregistré dans deux universités, un chef de projet peut diriger plusieurs projets). Toutes les approches à base de rôles ne permettent cependant pas cette multi-instanciation.

Tout type n’est cependant pas considéré comme un rôle : indépendamment du rôle qu’une personne peut tenir à un moment donné (ex. : étudiant ou employé), elle restera toujours une personne. Guarino présente ainsi une distinction entre les types de rôles et les types naturels [49]. Pour qu’un concept soit un type de rôles, il faut que ses instances soient en relation avec d’autres instances et qu’elles puissent entrer ou sortir du domaine du concept sans perdre leur identité. Au contraire, les instances de types naturels ne peuvent pas perdre leur type sans perdre leur identité et il n’est pas requis qu’elles soient en relation avec d’autres instances. PERSONNE, par exemple, est un type naturel car ses instances seront toujours des personnes et que leur existence est indépendante de la présence d’associations. D’un autre côté, ÉTUDIANT est un type de rôle puisque pour être étudiant, une inscription dans une université est nécessaire et que la fin des études n’entraîne pas la perte d’identité. On notera que cette définition laisse de côté certains types comme ENFANT par exemple : une personne peut passer de enfant à adulte sans perdre son identité alors qu’aucune association n’est nécessaire pour son existence. Ces types sont alors considérés comme des états d’une instance.

Pour plus de simplicité, nous préférons la définition de classes d’objets et de classes de rôles donnée par Wieringa et de Jonge [100] :

• une instance d’une classe d’objets ne peut exister sans être instance de cette classe,

• il existe des états possibles du monde pour lesquelles une instance d’une classe de rôles peut exister, en tant qu’objet, sans être instance de cette classe de rôles.

Cette définition ne force pas un rôle à apparaître dans une association.

5.2.2 Identité d’objet et identité de rôle

Si toutes les approches considèrent qu’un objet conserve toujours son identité lorsqu’il acquiert ou perd des rôles, elles sont en désaccord quant à la notion d’identité de rôle (RID pour Role IDentity, à opposer à la notion de OID pour Object IDentity).

La littérature se divise ainsi entre les propositions qui refusent aux rôles une identité distincte de leur objet associé [2, 102, 89, 27] et celles qui les identifient indépendamment [100, 47, 64, 28]. Considérons, par exemple, que la personne Pierre devienne un étudiant puis un employé. Dans la première approche, Pierre est représenté par un seul OID, alors que dans la deuxième, il est représenté par un OID, celui de son premier état en tant que PERSONNE, et par deux RID indépendants qui correspondent à Pierre respectivement en tant qu’étudiant et en tant qu’employé.

La notion d’identité de rôle a été introduite dans [100] et est généralement couplée à une relation particulière « joué-par ». Cette association entre un objet et ses rôles permet d’identifier à partir d’un rôle quel est l’objet qui le joue. L’utilisation de RID a trois avantages directs :

• Elle facilite la multi-instanciation de classes de rôles. Pour indiquer que Pierre est inscrit dans deux universités différentes, il suffit d’instancier deux fois la classe de rôles ÉTUDIANT, chaque

instance ayant son RID propre et étant jouée par le même objet (un seul OID).

• La relation « joué-par » peut être facilement étendue pour qu’un rôle puisse aussi être joué par un rôle, créant ainsi une arborescence dont la racine est toujours un objet. Pierre en tant qu’employé peut par exemple jouer le rôle deCHEF DE PROJET.

• Différencier les OID des RID permet de compter séparément les objets et leurs rôles. Prenons l’exemple de la classe d’objetsPERSONNEet de la classe de rôlesPASSAGER et intéressons-nous au nombre de passagers prenant le métro en une journée. À chaque fois qu’une personne prend le métro, elle acquiert un nouveau rôle passager avec un RID unique. Ainsi, nous pouvons facilement différencier le nombre de passagers du nombre de personnes réelles ayant pris le métro.

Les rôles d’un objet concerne toujours le même objet qui apparaît dans différents contextes. Ainsi, d’autres propositions considèrent que les instances des classes de rôles ne doivent pas avoir d’identité distincte. La relation « joué-par » devient alors inutile. L’implémentation en est plus simple et potentiel- lement plus performante, mais la multi-instanciation de rôles et les rôles sur rôles sont alors beaucoup plus complexes à modéliser.

Albano et al. [2], ainsi que Coulondre et Libourel [27] n’autorisent simplement pas ces notions. Quant à Steimann [89], il permet la multi-instanciation mais avec une approche complexe, s’appuyant sur un modèle dynamique où chaque rôle n’existe que dans le cadre d’une association. Enfin, le modèle DOOR [102] (Dynamic Object-Oriented database programming language with Roles) évite l’utilisation de références sur les rôles en les identifiant par le nom de leur classe et leurs valeurs. Quand un objet n’a qu’un rôle d’un certain type, ses valeurs peuvent être omises (ex. :pierre!Étudiant.iddésigne le numéro d’étudiant de Pierre). Dans le cas contraire, un critère booléen sur les valeurs est ajouté pour contrôler le résultat (ex. :pierre!(Étudiant|université=“Nantes”).id). DOOR permet aussi aux rôles de jouer eux-mêmes des rôles. Dans ce cas, l’identification d’un rôle part forcément de l’ob- jet racine (ex. :pierre!Employé!ChefDeProjetdésigne le rôle CHEF DE PROJET joué par le rôle EMPLOYÉ de Pierre). Il est impossible de référencer directement un rôle.

5.2.3 Hiérarchie de rôles

Comme les classes d’objets, les classes de rôles peuvent être organisées dans une hiérarchie de spé- cialisation. La classe de rôles DOCTORANT peut, par exemple, être vue comme une sous-classe de la classe de rôlesÉTUDIANT. Un objet ayant le rôle DOCTORANTa donc automatiquement le rôle ÉTU- DIANT. De plus, comme pour les objets, chaque sous-classe hérite des propriétés et valeurs de sa super- classe.

Si les différentes approches convergent sur la notion de hiérarchie de classes de rôles, elles diffèrent par contre quant à la relation que doit avoir cette hiérarchie avec les classes d’objets (et leur hiérarchie). Dans le modèle proposé par Albano et al. [2], chaque classe d’objets est associée à une hiérarchie de classes de rôles. Les modèles de Coulondre et Libourel [27], Dahchour et al. [28] et Gottlob et al. [47], vont plus loin : une sous-classe d’objets hérite de la hiérarchie de classes de rôles de sa super-classe. Cette approche a cependant une limite : les notions de classes d’objets et de classes de rôles, à rapprocher des types naturels ou de rôles, sont orthogonales. Par exemple, aussi bien desPERSONNEs que des ENTRE- PRISEs peuvent jouer les rôles d’ACTIONNAIRE ou deCLIENT. Ici, ces rôles doivent être dédoublés, ou une super-classe d’objets généralisantPERSONNEetENTREPRISEdoit être créée1.

Pour éviter cet écueil, d’autres approches définissent des hiérarchies de classes d’objets et de rôles indépendantes. Dans ce cas, une relation doit lier les classes d’objets aux classes de rôles qu’elles peuvent jouer (ex. : played-by dans [100], role-filler dans [89]). DOOR [102] utilise une autre approche consistant

1

CHAPITRE 5 — Modèles à base de rôles 59

à qualifier les rôles : la définition d’un rôle inclut la liste des classes (d’objets et de rôles), dont les instances peuvent le jouer.

Il existe deux types possibles d’héritage entre une classe et ses sous-classes : la spécialisation ou la

délégation. L’héritage par spécialisation est l’héritage traditionnel entre classes : une sous-classe (d’ob-

jets ou de rôles) peut être utilisée partout où sa super-classe est demandée et hérite de toutes ses proprié- tés. L’héritage par délégation fait le pont entre les objets et leurs rôles. Si un rôle est interrogé pour une propriété qu’il n’a pas, il peut déléguer la question à l’objet qui le joue. Albano et al. [2] suivent une approche particulière du fait qu’ils ne distinguent pas l’implémentation des classes d’objets de celles de rôles : seul l’héritage par spécialisation est utilisé et un objet n’est manipulé que via ses rôles.

5.2.4 Contraintes sur les rôles

Si l’utilisation d’une hiérarchie de classes de rôles permet d’exprimer naturellement certaines contraintes (ex. : le fait que tout chef de projet est un employé est simplement exprimé par une relation de spécialisa- tion entre les classes de rôles respectives), d’autres sont plus difficiles à spécifier. Aucune des approches étudiées ne permet par exemple d’indiquer simplement qu’il est impossible à un objet de jouer en même temps les rôlesEMPLOYÉetCHÔMEUR.

Quelques approches [47, 91, 89, 28] proposent d’autre part de définir des règles de transition qui permettent de définir les séquences permises d’acquisition ou de perte de rôle.