La complexit� des syst�mes logiciels ne cesse de cro�tre avec, notamment, l?explosion des besoins et la diversit� des contraintes techniques. Par cons�quent, leur d�veloppement devient de plus en plus complexe, co�teux et difficile et requiert de nouvelles approches m�thodologiques. Dans ce contexte, la structuration en vues introduit un m�canisme de d�composition souple, capable de r�duire la taille et la complexit� d'un probl�me. L'int�r�t de cette notion de vue pour l?ing�nierie des syst�mes logiciels a �t� soulign� par de nombreux chercheurs dans diff�rents domaines (Shaw et al., 1996) et confirm� en pratique par des industriels (Kruchten, 1995).

La notion de vue est apparue simultan�ment et ind�pendamment dans plusieurs domaines tels que les bases de donn�es, les sp�cifications formelles, les architectures logicielles ou les m�thodes de conception. Cette simultan�it� se refl�te dans la vari�t� des appellations�: vue, perspective, aspect, r�le, facette, sujet, pr�occupation, etc. L?id�e commune est d?identifier des utilisations diff�rentes d?un m�me artefact et de les repr�senter de mani�re s�par�e afin que, dans chaque contexte, on puisse consid�rer l?artefact d?une mani�re plus simple et correspondant aux pr�occupations de ce contexte. Ces pr�occupations se distinguent par une vari�t� de crit�res�tels que le d�coupage fonctionnel, la cat�gorie d?utilisateurs, le niveau d?abstraction ou la phase du cycle de vie (Dijkman et al., 2008).

Bien que les propositions diff�rent, elles sont confront�es aux m�mes probl�mes : s�parer les pr�occupations, mod�liser les vues et offrir des op�rateurs de manipulation ou de composition, �tablir des relations entre vues et garantir une forme de coh�rence des vues entre elles ou vis-�-vis d'un mod�le de r�f�rence.

Nous pr�sentons dans cet article une revue des travaux relatifs � la notion de points de vue en insistant sur les utilisations, d�finitions et repr�sentations dans une perspective d?ing�nierie des syst�mes d?information. Dans les sections deux � six, nous avons distingu� les disciplines informatiques suivantes : la repr�sentation des connaissances, les bases de donn�es orient�es objets, la programmation par objets, les architectures logicielles et l?ing�nierie des exigences. La derni�re section commence par la conclusion de cette r�flexion, ensuite nous introduisons notre approche originale de prise en compte d?une mod�lisation multivue, enfin nous d�gageons des perspectives � ce travail de recherche.

C'est en repr�sentation de connaissances que la notion de point de vue ou perspective a tout d'abord �t� consid�r�e dans des mod�les � objets. Elle r�f�re � la capacit� d'un syst�me � mod�liser une m�me entit� selon des points de vue diff�rents, refl�tant les diverses perceptions que des concepteurs ou utilisateurs ont de cette entit�.

Une des premi�res r�f�rences au terme perspective se trouve dans le travail de Minsky (Minsky, 1975) avec une connotation spatiale. Pour lui, un objet peut �tre vu par des observateurs diff�rents � partir de divers points de vue�; ces observateurs regardent tous les m�mes attributs mais chacun peut les voir avec des valeurs diff�rentes selon ses propres points de vue. Bien que diff�rentes, ces valeurs sont unifiables par des op�rations de transformation spatiale (Mari�o, 1993).

Dans les sections suivantes nous r�sumons quatre syst�mes qui illustrent la repr�sentation explicite des perspectives dans les repr�sentations des connaissances par objets : KRL, LOOPS, TROPES et ROME.

Knowledge Representation Language, KRL, est l?un des premiers langages destin� � repr�senter des connaissances avec Frames (Masini et al., 89) et � reconna�tre qu?un objet peut �tre consid�r� de plusieurs fa�ons, selon le point de vue de l?observateur. Chaque point de vue est repr�sent� dans un objet s�par�, appel� perspective, de sorte que l'objet tout entier apparaisse comme agr�gation de toutes ses perspectives. Les perspectives servent dans KRL comme une simulation de la sp�cialisation multiple. Le mod�le de KRL poss�de un m�ta niveau qui d�crit l?ensemble des concepts du mod�le (classe, objet, �v�nement, relation, etc.) par des m�taclasses appel�es cat�gories. Trois des sept types de cat�gories permettent le traitement de perspectives.

Les cat�gories Basic sont des racines des graphes des diff�rentes familles d?objets. Elles servent � partitionner le monde r�el en des familles disjointes d?objets tels que Personne et Ecole, et �tablissent une premi�re partition de l?univers du discours. Les cat�gories Abstract�sont utilis�es pour factoriser des informations � la mani�re des classes abstraites. Les cat�gories Specialization sp�cialisent les cat�gories Basic ou Specialization. Les cat�gories Individuals d�crivent des entit�s r�elles du monde (des individus).

Les perspectives sont des notions centrales � la repr�sentation des connaissances en KRL. Un objet peut �tre d�fini par plusieurs perspectives qui correspondent � autant de points de vue selon lesquels il peut �tre consid�r� (Bobrow et al., 1977). KRL les mod�lise avec le descripteur Perspective. Un individu a une premi�re Perspective qui est la classe la plus g�n�rale � laquelle il appartient, une unit� de type Basic et il peut avoir d?autres Perspectives parmi les unit�s de sp�cialisation de sa classe de base. Ainsi, en figure 1, la classe de base est la classe Membre qui peut �tre sp�cialis�e en diverses unit�s, telles que Professeur, Chercheur, Assistant, Droit, Science, etc. L?unit� individuelle, Pierre, est un membre qui, selon la perspective Assistant est un assistant de classe A et, selon la perspective Droit est un enseignant de Droit public.

Les perspectives dans KRL sont repr�sent�es au niveau des instances. Une instance est li�e � son unit� de base et � ses perspectives. Les attributs h�rit�s de chacune de ces unit�s sont organis�s dans des groupes d?attributs.

Pour d�finir une unit� individuelle de plusieurs points de vue, on lui associe plusieurs descripteurs de type Perspective parmi lesquels un seul poss�de un prototype de type Basic alors que les autres poss�dent des prototypes de type Specialization. Les attributs sont group�s selon la perspective � partir de laquelle ils d�crivent l?objet.

Alors que dans le mod�le de KRL, une perspective d?un objet est un sous-ensemble d?attributs, dans le mod�le LOOPS (Stefik et al., 1985), une perspective est un objet � part enti�re qui peut recevoir directement des messages. Pour traiter les perspectives, LOOPS utilise deux classes abstraites (mixin) : Node et Perspective. Une classe qui d�crit des objets ayant des points de vue, est une sous-classe de Node, alors qu?une classe d�crivant des objets qui sont des perspectives d?autres objets, est une sous-classe de Perspective. En figure 2, la classe Membre est une sous-classe du mixin Node � laquelle on associe des sous-classes de Perspective (Assistant et Droit) qui d�crivent les perspectives d?un objet instance de Membre.

Les perspectives d?un objet LOOPS sont des objets ind�pendants, instances des sous-classes du mixin Perspective. L?objet m�me est membre d?une sous-classe du mixin Node. Un objet et ses perspectives sont une sorte d?objet composite, les composants �tant les diff�rentes perspectives. Chaque perspective est un objet ind�pendant pouvant recevoir des messages, ce qui autorise d?avoir des attributs de m�me nom avec des sens diff�rents dans plusieurs perspectives.

Les perspectives sont toutes li�es � l?objet. Le lien entre perspectives est un lien conceptuel. En reprenant l?exemple pr�c�dent, l?individu Pierre est li� � ses deux perspectives : Pierre comme un assistant de classe A et Pierre comme un enseignant de droit public. A la diff�rence des objets composites, les perspectives sont cr��es dynamiquement � la demande. Ainsi, pourrait-on ajouter ensuite une perspective Genre, divisant les membres en deux classes, et consid�rer Pierre comme Homme.

Tropes est un mod�le de repr�sentation des connaissances � objets multipoints de vue. TROPES partitionne la base de connaissances en familles disjointes appel�es Concepts. Un Concept peut �tre vu et manipul� selon des points de vue diff�rents. Chaque point de vue donne lieu � une structuration particuli�re de la connaissance du Concept dans un graphe de classes. L?aspect pluridisciplinaire d?une base de connaissances se refl�te dans l?ensemble de points de vue. Ceux-ci peuvent �tre reli�s par une ou plusieurs passerelles.

Les passerelles permettent de d�finir les liens s�mantiques existant entre deux points de vue d?une m�me instance et par cons�quent de g�rer leur coh�rence. Une instance satisfaisant les contraintes d�finies dans un point de vue respecte forc�ment celles qui ont �t� d�finies dans un point de vue faisant partie de la m�me passerelle. Les passerelles permettent d?�tablir des relations d?inclusion ensembliste entre des classes de points de vue diff�rents et refl�tent l?aspect interdisciplinaire d?une base de connaissances.

Dans TROPES, un individu du monde est repr�sent� par une instance d?un Concept qui est rattach�e � sa classe la plus sp�cialis�e dans chacun des points de vue du Concept. De plus, TROPES permet la manipulation d?objets composites qui sont d�composables diff�remment selon les points de vue de son concept (Mari�o, 1993).

La figure 3 repr�sente la d�composition du concept de Membre en trois points de vue, � savoir Enseignement, Recherche et Statut, et deux passerelles, l?une reliant les racines des hi�rarchies des points de vue et l?autre reliant les classes repr�sentant les membres temporaires et les membres � temps partiel.

Une instance est reli�e par un lien ��est un�� � une classe participant � un point de vue donn� et ��appartient�� (Gensel, 1993) alors � toutes les classes de la hi�rarchie d?h�ritage situ�es entre la racine de l?arborescence et la classe d?instanciation. Un point de vue d�finit des masques de visibilit� des attributs d�finis dans le Concept, dans la mesure o� les attributs sont d�finis dans le Concept, mais peuvent aussi avoir des d�finitions diff�rentes dans les classes. Le Concept TROPES est en fait un ensemble d?instances potentielles ayant des repr�sentations en fonction du point de vue auquel elles appartiennent.

Les travaux concernant le projet ROME, ��Repr�sentation d'Objet Multiple et Evolutive��, (Carr�, 1989) et ses �volutions FROME, ��Frame en ROME��, (Dekker, 1994) et CROME, ��Contextes en ROME�� (Debrauwer, 1998) (Vanwormhoudt, 1999) traitent de l?int�gration des points de vue dans une repr�sentation objet de connaissances. Le concept de repr�sentation multiple et �volutive est propos� pour combler les lacunes des langages orient�s objet dans la repr�sentation de l'�volution des objets et de leur appartenance � plusieurs points de vue.

ROME reprend la notion d?instanciation des langages � objets : une classe a des m�thodes pour cr�er des instances (appel�es I-CLASSE) qui sont d�finitivement attach�es � cette classe par le lien d?instanciation. Pour repr�senter les instances, ROME introduit la notion de classe de repr�sentation ou R-CLASSE qui, par opposition � une classe d?instanciation, n?a pas la fonctionnalit� d?instanciation. Les classes de repr�sentation sont des sp�cialisations d?une classe d?instanciation�; elles d�crivent des sous-ensembles d?individus ayant des propri�t�s sp�cifiques. De cette fa�on, un objet est instance d?une unique classe et peut �tre repr�sentant de plusieurs classes, c?est-�-dire avoir plusieurs points de vue. Ceci constitue la repr�sentation multiple.

L?objet �tant li� � plusieurs classes, B. Carr� propose une m�thode pour faire �voluer cette repr�sentation multiple en rajoutant ou en enlevant des liens de repr�sentation dynamiquement. L?�volution n?affecte pas l?unique lien d?instanciation de l?objet puisqu?elle ne d�truit ou ne rajoute que des liens de repr�sentation et permet ainsi de g�rer le partage des objets dans le syst�me. La repr�sentation �volutive consiste � faire �voluer les liens de repr�sentation d?un objet.

Une instance de ROME a une classe fixe d?instanciation mais elle peut avoir plusieurs classes de repr�sentation, sous-classes de sa classe d?instanciation. Les liens de repr�sentation peuvent changer lors de l?�volution de l?instance. La Figure 4 d�finit la I-Classe Membre et six R-Classes�: Prof, Mc, Ater, Enseignant, Chercheur, EnsChercheur. Elles d�crivent des r-objets. Soit Pierre un r-objet instance de Membre, le lien d?instanciation qui lie Pierre � Membre est permanent tout au long de l?existence de Pierre. En revanche, Pierre peut �voluer dans le treillis de racine Membre. Ainsi, si Pierre, initialement Ater, devient Ma�tre de conf�rences, le lien de repr�sentation qui le relie � la classe Ater est remplac� par un autre le reliant � la classe MC. Cette �volution de la repr�sentation est r�alis�e gr�ce aux op�rations r+ et r- de la classe R-Object. Ainsi, l?op�ration (Pierre r- Ater) supprime le lien de repr�sentation qui lie Pierre � la classe Ater tandis que l?op�ration (Pierre r+ MC) instaure un lien de repr�sentation entre Pierre et la classe MC. Cette id�e d?avoir une classe d?instanciation pour l?information de base de l?objet et plusieurs classes de repr�sentation pour ses perspectives a �t� propos�e �galement par le syst�me PINOL (Nguyen et al., 1992) qui distingue le type d?une instance contenant son information structurelle de base, de ses classes qui repr�sentent les diff�rentes perspectives.

ROME offre une autre facilit� pour la manipulation des points de vue, � savoir la possibilit� de parcourir un sous-graphe du graphe incluant certaines classes sp�cifiques.

Les approches KRL, LOOPS, TROPES et ROME illustrent diff�rentes solutions apport�es � la gestion des points de vue, dans le domaine de la repr�sentation des connaissances. Ces mod�les reposent sur l?hypoth�se qu?un point de vue est une repr�sentation partielle d?un ensemble coh�rent d?objets.

Nous pouvons comparer ces approches en fonction d?un ensemble de caract�ristiques�:

• La port�e d?un point de vue. Dans la plupart des mod�les de repr�sentation de connaissances tels que LOOPS, KRL, ROME, une perspective est uniquement consid�r�e sur un objet. Dans le mod�le TROPES, la notion de point de vue porte sur un objet et aussi sur une classe.

• Le type de repr�sentation. Dans le langage KRL, la repr�sentation multiple n?est pas compl�tement d�centralis�e. En effet, si les attributs d?un objet sont r�partis dans des groupes tels que chaque groupe est relatif � une perspective, il n?est n�anmoins pas possible d?acc�der � une perspective ind�pendamment de l?objet. Par contre, dans LOOPS, nous pouvons consid�rer que la repr�sentation multiple des objets est d�centralis�e, car une perspective d?un objet est un objet � part enti�re. Dans le mod�le TROPES, la repr�sentation multiple des objets n?est pas d�centralis�e�; l?�tat de l?objet contient l?union des attributs d�crivant l?entit� dans tous les points de vue.

Le tableau ci-dessous, r�sume les principales caract�ristiques des mod�les en repr�sentation des connaissances �tudi�s dans cette section.

Le m�canisme de vue dans les bases de donn�es a suscit� plusieurs travaux aussi bien dans le contexte relationnel (Barsalou, 1990) (Sheth et al., 1988), (Motro, 1987) que dans le contexte objet (Heiler et al., 1988) (Heiler et al., 1990) (Scholl et al., 1991) (Bertino, 1992).

Dans le mod�le relationnel, une vue est une relation virtuelle (non stock�e physiquement) d�finie par une requ�te sur une ou plusieurs relations stock�es ou autres vues. Comme les langages relationnels sont ferm�s (i.e. le r�sultat d?une requ�te exprim�e dans un langage relationnel est une relation), la relation retourn�e par une telle requ�te repr�sente le contenu de la vue. Ainsi, les vues relationnelles peuvent-elle �tre utilis�es (en g�n�ral) dans n?importe quel contexte dans lequel une relation peut appara�tre.

Les vues apportent des facilit�s d?interrogation, de restructuration et d'int�gration de donn�es, tout en permettant l'adaptation des structures de donn�es aux besoins des applications. Elles ont �t� propos�es initialement pour les SGBD relationnels. Dans le contexte orient� objet, outre la restructuration des donn�es, elles permettent l'adaptation du comportement des objets. Les caract�ristiques du monde objet sont, bien entendu, int�gr�es au m�canisme de vues et y jouent un r�le important. Notre �tude de l?int�gration des concepts de vues dans les bases de donn�es OO est faite � travers les approches O2Views, COCOON, Multiview et Chimera.

O2Views est un outil permettant la d�finition et l?utilisation des vues dans le syst�me de gestion de bases de donn�es � objets O2 (O2Views, 1995), (Bancilhon et al., 1992). Une fois d�finie, une vue peut �tre employ�e dans l?expression des requ�tes et mettre � jour la base de donn�es par des applications. L'outil a �t� impl�ment� avec le langage de programmation O2 C, le langage natif d?O2.

Les vues dans O2Views sont d�finies � trois niveaux�: sch�mas virtuels, classes virtuelles et attributs virtuels (Souza dos Santos et al., 1994) (Souza dos Santos, 1995).

Une vue est un sch�ma virtuel d�riv� d'un autre sch�ma (r�el ou virtuel), appel� le sch�ma racine de la vue. Les vues peuvent �tre compos�es � n'importe quel degr�. Une base virtuelle correspond � l'image d'une base r�elle (une base instanci�e du sch�ma de base) � travers la vue. La figure 5 illustre la relation entre les entit�s virtuelles et leurs bases correspondantes pour une d�rivation d?une base virtuelle donn�e.

Un sch�ma virtuel est une collection de classes virtuelles telles qu'un sch�ma virtuel appliqu� � une base (de donn�es) r�elle donnera comme r�sultat une base virtuelle. Les sch�mas virtuels pr�servent l'identit� de l?objet, c?est-�-dire qu?un objet dans une vue a la m�me identit� que l?objet dans la base r�elle. Des sch�mas virtuels sont dynamiquement activ�s et d�sactiv�s�; l?activation commute le contexte pour la structure et le comportement d'objets d'une base r�elle � la base virtuelle d�riv�e.

Une classe virtuelle est d�finie par une requ�te sur la base de donn�es r�elle, ou relativement � un type existant par une fonction caract�ristique et fournit un ensemble nomm� contenant ces objets : l?extension de la classe virtuelle. Ainsi, conceptuellement, l?extension d'une classe virtuelle est d�finie relativement � l?extension d'une classe de base. D'ailleurs, puisque c'est une classe, son interface peut �tre modifi�e par les primitives de vue pour cacher ou ajouter des attributs (modification de structure) et (re)d�finir des m�thodes (modification de comportement). Les instances de classes virtuelles (objets virtuels) sont les objets pr�sents dans la base de donn�es r�elle avec une interface �ventuellement diff�rente dans la vue.

Une classe imaginaire choisit et restructure par une requ�te des donn�es de la base de donn�es r�elle ou de la vue et les transforme en de nouveaux objets. L'identifiant d'un objet imaginaire est une fonction de ses attributs de base. Les instances d'une classe imaginaire (objets imaginaires) existent seulement dans la base virtuelle pendant l'activation de la vue.

Un attribut virtuel est une propri�t� d'une classe virtuelle qui est sp�cifi�e par une fonction de d�rivation. Il attache des donn�es � un objet dans la vue, par une requ�te sur la base de donn�es r�elle ou sur la vue. Il augmente l'interface originale des objets (virtuels). Il attache �galement aux objets imaginaires des donn�es non impliqu�es par leur identit� (attributs diff�rents des attributs de base). Les attributs cach�s limitent l'interface des objets virtuels dans la vue et permettent �galement de cacher des attributs de base des objets imaginaires qui sont cens�s �tre utilis�s seulement comme cl�s internes.

Le mod�le propos� dans COCOON COCOON, Cocoon Complex-Object-Orientation based on Nested Relations (Scholl et al., 1991) et son langage associ� COOL vise l?extension des concepts du mod�le relationnel aux SGBD orient�s objet. Le mod�le COCOON est bas� sur les propri�t�s objet suivantes :

• L?objet est d�crit de fa�on multiple par plusieurs intensions.

• Les objets ne sont pas encapsul�s. L?acc�s � l?intension des classes est donc libre pour permettre l?expression des requ�tes.

• La relation d?h�ritage est multiple. Une instance peut appartenir � plusieurs classes, m�me si celles-ci sont ind�pendantes.

• La classification des instances dans les classes et dans les classes-vues est r�alis�e de fa�on automatique et dynamique. Elle est bas�e sur l?h�ritage multiple.

COCOON dispose d?op�rateurs pour manipuler les types attribu�s aux instances. Les types peuvent �tre ajout�s ou retir�s dynamiquement de la description d?une instance. La notion de vue dans COCOON est �troitement li�e � celle de classe et de requ�te. Une vue est une classe d�finie � partir d?une requ�te portant sur d?autres classes du syst�me. C?est une classe d�riv�e dont les types des membres et l?extension sont d�finis implicitement par l?expression de la requ�te (Scholl et al., 1991). Ainsi, l?extension de la vue est-elle habituellement non stock�e explicitement, mais calcul�e par la requ�te d�finissant la vue.

Les vues fournissent une interface sp�cialis�e � quelques objets de base. Un utilisateur ou un programmeur d?applications travaille en g�n�ral sur une petite partie du sch�ma global, un sous-sch�ma, qui est ajust� � ses besoins. Un tel sous-sch�ma se compose d'une collection de classes de base et/ou de vues ainsi que les fonctions d�finies sur elles.

Le m�canisme de vue de COCOON permet simplement � des requ�tes de servir de d�finitions de vues, exactement comme dans les SGBD relationnels. Contrairement au mod�le relationnel, les vues peuvent �tre utilis�es comme arguments pour des requ�tes et des mises � jour, comme les classes ordinaires. Seules quelques restrictions doivent �tre impos�es. En fait, tous les op�rateurs de mise � jour ont le m�me effet que s?ils avaient �t� appliqu�s � une classe de base puisque les extensions des vues sont d�riv�es des classes de base.

MultiView poss�de un m�canisme de construction de sch�mas de vues (Rundensteiner, 1992). Un sch�ma de vues est un ensemble de classes et de classes de vues n�cessaires aux utilisateurs de la base de donn�es. Ceux-ci ne per�oivent et ne manipulent ainsi que les informations pertinentes � leur utilisation de la base de donn�es, informations regroup�es dans le sch�ma de vues qui correspond exactement au niveau externe du mod�le de l?architecture ANSI/X3/SPARC (Debrauwer, 1998). On peut consid�rer un sch�ma de vues comme �tant un sous-graphe du sch�ma global. Plusieurs sch�mas de vues peuvent �tre d�finis sur la m�me base de donn�es et proposent autant de points de vue diff�rents sur celle-ci.

Dans Multiview, les classes de base sont d�finies pendant la d�finition du sch�ma initial et leurs instances objet sont explicitement stock�es en tant qu?objets de base. Par contre, les classes virtuelles sont d�finies pendant la vie de la base de donn�es en utilisant des requ�tes orient�es objet, donc leurs d�finitions sont dynamiquement ajout�es au sch�ma existant. La classe virtuelle a une fonction associ�e de d�rivation d?adh�sion qui d�terminera son adh�sion bas�e sur l?�tat de la base de donn�es. Le contenu d?une classe virtuelle n'est g�n�ralement pas explicitement stock�, mais plut�t calcul� sur demande. MultiView divise la sp�cification de vues en trois t�ches ind�pendantes�: la personnalisation des classes virutelles, l?int�gration de ces classes et la sp�cification des sch�mas-vues.

La personnalisation des classes virtuelles est effectu�e en utilisant des requ�tes orient�es objet. Multiview utilise des m�canismes de d�rivation de classes pour diff�rents buts tels que pour personnaliser les types, limiter l?acc�s aux fonctions de propri�t�s, rassembler des instances d?objets dans des groupes pertinents pour la t�che en cours, etc.

L?int�gration des classes virtuelles dans un sch�ma global coh�rent (Rundensteiner, 1992) prend soin de la maintenance de relations explicites entre les classes stok�es et les classes d�riv�es. Ceci est utile pour partager des fonctions de propri�t�s et des instances d?objets entre classes de fa�on coh�rente, sans duplication inutile. L?int�gration des classes assure �galement la coh�rence de toutes les vues avec le sch�ma global et entre elles.

Quant � la sp�cification de sch�mas de vues compos�s de classes de base et de classes virtuelles, MultiView utilise le sch�ma global augment� pour la s�lection des classes de base et virtuelles et pour arranger ces classes de vues dans une hi�rarchie de classes coh�rentes. Ceci supporte la restructuration virtuelle des hi�rarchies de g�n�ralisation et de d�composition de propri�t�s, en permettant de cacher et d'exposer des classes dans un sch�ma-vue.

Cette approche de s�paration du processus de conception de vues en t�ches bien d�finies a plusieurs avantages. D'abord, elle simplifie la sp�cification de vues puisque chacune des t�ches peut �tre r�solue ind�pendamment des autres. En second lieu, elle augmente le niveau du support en tenant compte de l'automatisation de certaines t�ches. Des algorithmes automatisent la deuxi�me et la troisi�me t�che (Rundensteiner, 1992).

Nous concluons la pr�sentation du concept de vue pour les syst�mes de base de donn�es orient�es objet par un mod�le qui est riche en terme de fonctionnalit�s mais aussi fond� sur une d�finition formelle (Guerrini et al., 1994) (Guerrini et al., 1997). Chimera est fond� sur trois mod�les de programmation : un mod�le de donn�es orient� objet, un langage de requ�tes d�claratif bas� sur des r�gles d�ductives (Bertino et al., 2000) et un langage de r�gles actives.

Les vues dans Chimera peuvent �tre des vues pr�servant l'objet (object-preserving views) qui contiennent une s�lection d?objets existants maintenant leur identit� originale, des vues g�n�ratrices d?objets (object-generating views) qui cr�ent de nouveaux objets persistants et des vues (set?tuple views) contenant des donn�es d�riv�es temporaires sans identit� persistante.

Comme pour MultiView, les classes de vues introduisent des attributs additionnels non d�riv�s. � la diff�rence de MultiView, Chimera garde les hi�rarchies d?h�ritage des classes et des vues distinctes. Les deux hi�rarchies sont reli�es par une hi�rarchie de d�rivation de vues. La diff�rence entre l?h�ritage de relations et la d�rivation de vues est clairement �nonc�e : pour l?h�ritage, le sous-typage de signatures doit concorder avec la formation des sous-ensembles d'extensions. Cette contrainte n'est pas impos�e pour la relation de d�rivation de vues.

L?h�ritage multiple et l'instanciation multiple de classes sont support�s. Un objet peut �tre membre de plusieurs classes plus sp�cifiques comprenant des classes de vues non reli�es par h�ritage, ce qui facilite la s�paration des hi�rarchies d?h�ritage.

Deux niveaux des vues sont con�us : les vues et les sch�mas de vues. Les vues sont des classes virtuelles et sont utilisables dans n'importe quel contexte o� des classes peuvent �tre utilis�es. De m�me que les classes sont combin�es en sch�mas, les vues sont combin�es en sch�mas de vues. Les sch�mas de vues permettent de restructurer des sch�mas pour satisfaire les besoins d?applications sp�cifiques. Un sch�ma de vues �tant un sch�ma virtuel, les applications op�rent indiff�remment sur des sch�mas de vues, des vues, des sch�mas ou des classes.

Pour choisir la facette appropri�e d?un objet, Chimera consid�re le contexte d'une r�f�rence. Ainsi, un m�me objet appara�t-il dans diff�rents r�les, comme instance de plusieurs vues sans retourner aux r�gles de priorit� comme dans O2.

Le m�canisme de vues est un sujet important pour les syst�mes de BD orient�es objet afin de fournir certaines caract�ristiques cruciales au d�veloppement d?applications avanc�es. En raison de la complexit� du mod�le de donn�es, le paradigme Objet introduit de nouveaux probl�mes dans la d�finition du m�canisme de vues. Plusieurs approches ont �t� d�finies, chacune d�finissant un m�canisme de vues particulier, con�u pour r�pondre � un ensemble de fonctionnalit�s que le m�canisme de vues doit supporter.

Si les vues doivent �tre utilis�es comme les classes, il est essentiel que leurs instances soient des objets et, par cons�quent qu?elles aient des identificateurs persistants. En effet, il y a souvent besoin de mettre en r�f�rence des instances de vues. Deux sortes distinctes de vues peuvent cependant �tre identifi�es, selon qu?elles pr�servent ou g�n�rent l?objet. Les vues pr�servant l?objet (Object-preserving views) extraient seulement des objets � partir des classes existantes�; les instances de ces vues sont identifi�es par les identificateurs des objets de base extraits. Les vues g�n�rant l?objet (Object-generating views) cr�ent de nouveaux objets qui doivent donc disposer de nouveaux identifiants.

La plupart des approches (Ohori et al., 1994) (Scholl et al., 1991) (Shilling et al., 1989) consid�rent seulement les vues pr�servant l?objet. Ainsi, les vues fournissent-elles seulement diff�rentes vues d?objets existants. Cette approche est particuli�rement utilis�e pour supporter des objets avec des interfaces multiples et un comportement d�pendant du contexte. Dans ce sens, les vues pr�servant l?objet sont similaires aux r�les (Albano et al., 1993), (Gottlob et al., 1994), (Richardson et al., 1991). Cependant, ce type de vues n?est pas assez puissant pour supporter tous les types de r�organisation de bases de donn�es.

Comme indiqu� dans le tableau 2, O2 et Chimera consid�rent les deux types de vues. Ainsi, lorsque l?�valuation de la requ�te de vues invoque la cr�ation d?instances de vues pour peupler la classe-vue (ex. op�ration de jointure), de nouveaux identifiants sont g�n�r�s. Par contre, lorsque les vues sont peupl�es par l?extraction d?objets d?une classe, �ventuellement modifiant leur structure et comportement (ex. op�ration de s�lection ou projection), les instances de vues pr�servent les identifiants des objets de base.

L?une des premi�res approches qui reconna�t explicitement l'existence et le besoin de repr�senter des vues multiples en chevauchement dans le d�veloppement de programmes a �t� propos�e par Rich (1981). L'approche propose de mod�liser les programmes et les structures de donn�es en utilisant des ��points de vue�� multiples et sugg�re l'utilisation d'un formalisme appel� ��overlay�� pour supporter une telle approche. Un ��overlay�� est un triplet compos� de deux plans (chaque plan repr�sentant une vue) et un ensemble de correspondances (�galit�s logiques) entre ces deux plans. Les correspondances entre plans repr�sentent les relations entre vues et ne sont pas limit�es aux programmes et aux structures de donn�es.

En POO, de nombreux mod�les de programmation ont explor� le paradigme de point de vue d?un objet. Cette section discute la programmation par vues (Mili et al., 2002), la programmation orient�e sujet (Harrison et al., 1993), la programmation orient�e aspect (Kiczales et al., 1997), la s�paration multidimensionnelle des pr�occupations (Ossher et al., 2000), la programmation structur�e en contextes (Vanwormout, 1999) et la programmation avec les objets morcel�s (Bardou, 1998).

Dans la programmation par vues (Mili et al., 2002), chaque objet d'une application est appr�hend� comme un ensemble de fonctionnalit�s de base qui sont disponibles, directement ou indirectement, � tous les utilisateurs de l'objet, et un ensemble d'interfaces qui sont sp�cifiques � des utilisations particuli�res, et qui peuvent �tre ajout�es ou retir�es pendant l?ex�cution. Les interfaces correspondent � des types d'utilisateurs ayant des int�r�ts fonctionnels semblables ou � des utilisateurs ayant diff�rents int�r�ts fonctionnels. Cette approche fournit un support pour :

• l?acc�s simultan� d?un programme � plusieurs zones ou vues fonctionnelles,

• l'ajout et le retrait des vues (fonctionnelles) pendant l?ex�cution,

• l?�laboration d?un protocole coh�rent et non encombrant d?adressage des objets multivues.

La figure 6 montre une impl�mentation de cette id�e bas�e sur l?agr�gation. La bordure en pointill� de l?objet (rectangle) repr�sente l?abstraction d'un objet d'application : c?est la combinaison de l?instance de base et des vues. L'objet de base inclut deux variables d?�tats ('a' et 'b'), et supporte trois op�rations (f(), g() et h()). Les objets vues qui pointent sur l'objet de base peuvent ajouter l'�tat ('c' pour la vue 1 et 'd ' pour la vue 2), le comportement (i(...) pour la vue 1?), et d�l�guer les donn�es et comportement partag�s. En appelant l?op�ration f() sur la vue 1, la demande est transmise � l'objet de base, et l?op�ration f() est ex�cut�e dans le contexte de l'objet de base. Il en est de m�me pour les r�f�rences aux variables d?�tats partag�es comme 'a' pour la vue 2. Pratiquement, il y aura une copie simple de telles variables, enregistr�e dans l'objet de base, et les demandes de lecture/�criture seront transmises � l'objet de base. L'objet d'application est vu comme supportant l'union des comportements de l?instance de base et des vues actuellement attach�es.

Les programmations par r�les ou par points de vue (Kendall, 1999) sont deux paradigmes assez proches. Ils permettent de d�structurer la notion d?objet par l?introduction de vues subjectives : les r�les qu?ils jouent ou les points de vue qu?ils repr�sentent. Notons par exemple, qu?un syst�me comme Jiazzy (McDirmid et al., 2003) permet de programmer par r�les ou par points de vue.

La programmation orient�e sujets (SOP�ou Subject-Oriented Programming) propos�e dans (Harrisson et al., 1993) introduit les termes de subjectivit� (subjectivity) et sujet (subject) dans le paradigme objet et fournit un support pour g�rer les points de vue d?un objet.

Un sujet est la sp�cification d?une hi�rarchie de classes. Une m�me classe peut intervenir dans plusieurs sujets et y d�finir des variables et des m�thodes diff�rentes, refl�tant une vision particuli�re sur l?application. N?�tant qu?une abstraction, un sujet ne contient aucune donn�e.

Les instances d?un sujet, appel�es activations de sujet, contiennent effectivement les donn�es des objets pr�sents dans le syst�me. Un m�me sujet est activable plusieurs fois et le lien entre ses activations est r�alis� au travers de la notion d'identit� de l?objet. Un m�me objet peut �tre instance de classes diff�rentes dans des sujets diff�rents (Bardou, 1998).

Les activations de sujets sont compos�es pour produire l?application finale. Cette composition de sujets est exprim�e par des r�gles de composition. Les sujets sont tous vus au m�me niveau, sans hi�rarchie entre eux. Au niveau d?un sujet, les objets sont d�crits de fa�on classique par un ensemble de classes organis�es selon la relation d?h�ritage.

La composition de sujets intervient � des niveaux de d�tails diff�rents et elle est r�alis�e de fa�on semi-automatique. Les r�gles de bas-niveau sp�cifient finement les correspondances entre les sujets � composer (Lahire, 2004) (Vanwormhoudt, 1999). Par d�faut, la composition utilise l?appariement de noms (name matching) pour composer les d�finitions des classes. Cet appariement peut �tre remplac� localement par des expressions de composition �crites dans un langage de composition (Ossher et al., 1995).

Un avantage important de la composition de classes dans la SOP est que la fusion des hi�rarchies de classes entra�ne la propagation de la composition � travers le graphe d?h�ritage ; c?est-�-dire quand deux classes sont fusionn�es, tous leurs descendants tireront b�n�fice de cette fusion (dans les deux hi�rarchies d'entr�e). Une r�gle de composition implique au moins deux sujets et s?exprime par des op�rations simples telles que la fusion, la red�finition ou le s�quencement.

Le paradigme de la POS a �volu� pour r�duire le couplage entre les sujets, permettant ainsi une meilleure s�paration des pr�occupations ; c?est la programmation par HyperSpace (Ossher et al., 2000) (HyperJ, 2003).

La programmation orient�e aspects (AOP ou Aspect-Oriented Programming) (Kiczales et al., 1997), (Kiczales, 2007) est une technique de structuration de programmes permettant la s�paration des pr�occupations dans les logiciels. Elle se fonde sur une s�paration claire entre les pr�occupations ��m�tiers�� (ou fonctionnelles) et non-fonctionnelles (ou techniques) pr�sentes dans les applications.

La d�composition d?une application fait appara�tre :

• un aspect de base qui d�finit l?ensemble des services (i.e. fonctionnalit�s) r�alis�s par l?application. Autrement dit, l?aspect de base correspond au ?Quoi? de l?application.

• plusieurs aspects compl�mentaires qui pr�cisent les m�canismes r�gissant l?ex�cution de l?application c?est-�-dire les aspects non-fonctionnels d�finissant le ?Comment? (par exemple la synchronisation, la persistance ou la s�curit�).

Les aspects sont utilis�s pour regrouper des choix d'impl�mentation qui ont un impact sur l'ensemble du syst�me et qui autrement seraient �parpill�s � travers tout le code. Chaque aspect est destin� � �tre d�velopp� de fa�on ind�pendante puis int�gr� � une application par un processus dit de tissage d'aspects (aspect weaving). La construction d?une application � partir de diff�rents aspects n�cessite une �tape ?d?assemblage?. En effet, les aspects �tant des modules d�finis s�par�ment les uns des autres, il faut d�finir leurs r�gles d?int�gration pour les composer afin de ?construire? l?application. D?o� le besoin d?un m�canisme de composition pour r�aliser cet assemblage.

La programmation orient�e aspects permet d?encapsuler les pr�occupations dans des modules r�utilisables (Kiczales et al., 2001). Kiczales et al. (1997) distinguent deux types de modules � savoir les composants et les aspects�:

• Un composant est un �l�ment encapsulable dans un objet ou dans un module. Les composants sont les unit�s fonctionnelles d'un syst�me.

• Un aspect n'est pas une unit� de d�composition d?un syst�me mais une propri�t� qui affecte la s�mantique des composants d'un syst�me. C'est une fonctionnalit� qui n?est pas encapsul�e � l?aide des moyens de structuration conventionnels. Les aspects correspondent aux exigences non-fonctionnelles d'un syst�me (Nassar, 2005).

Le but de l?AOP est de s�parer la programmation des composants de celle des aspects et de disposer de moyens de tissage pour composer le syst�me final � partir des modules et des r�gles d?int�gration.

L?existence d?un programme de base sur lequel le code aspect est tiss� est la diff�rence principale par rapport � l?approche de programmation orient�e sujet (Clarke, 2001). Dans cette derni�re, il n?y a pas de concept de programme de base, chaque code sujet est ind�pendant et fournit compl�tement le code pour l?unit� de d�composition particuli�re qu?il supporte.

Parmi les exp�rimentations les plus abouties de langages orient�s aspects, citons AspectJ (Kiczales et al., 2001), (Lopes et al., 1998), (Kiselev, 2003) d�velopp� par l'�quipe � l'origine de l?AOP et de JAC (Java Aspect Component).

C?est un sujet de recherches actif en g�nie logiciel pendant cette derni�re d�cennie. Elle se rapporte � la capacit� d'identifier, encapsuler et manipuler des parties de logiciels qui sont appropri�es � un concept, � un but, ou � un motif particulier. Les pr�occupations sont les moyens primaires d'organiser et de d�composer le logiciel en plus petites pi�ces plus faciles � g�rer et plus compr�hensibles. Plusieurs types de pr�occupations peuvent �tre appropri�s � des d�veloppeurs dans diff�rents r�les, et pour r�aliser diff�rents buts, ou � diff�rentes �tapes du cycle de vie du logiciel. Les pr�occupations fonctionnelles, m�tiers, r�gles de gestion, technologiques sont des exemples de dimensions.

La ��s�paration multidimensionnelle des pr�occupations�� implique les points suivants.

• L?existence de multiples types (ou dimensions) de pr�occupations.

• La s�paration simultan�e selon ces multiples pr�occupations c?est-�-dire que le d�veloppeur n'est pas forc� de choisir un petit nombre (habituellement r�duit � un) de dimensions "dominantes" de pr�occupations au d�pend des autres. Chaque acteur peut donc disposer de sa propre vision d'un syst�me avec ses pr�occupations dominantes. Au-del� de l'identification des pr�occupations, il est important que l'encapsulation soit suffisante pour limiter l'impact de l'activit� li� � l'ascendance d'une pr�occupation sur les autres pr�occupations. L'absence d'impact entre pr�occupations est consid�r�e comme impossible.

• Le chevauchement ou les interactions entre pr�occupations. Il est attractif de penser � plusieurs pr�occupations comme �tant ind�pendantes ou "orthogonales" mais c'est rarement le cas dans la pratique. Il est important de pouvoir supporter des pr�occupations interagissantes les unes sur les autres, tout en offrant toujours la s�paration utile.

Un exemple de programmation multidimensionnelle de pr�occupations�est la programmation par HyperSpace (Ossher et al., 2000), (HyperJ, 2003). Elle se place � la fois comme �volution de la programmation par sujets et une application du paradigme de s�paration multidimensionnelle des pr�occupations. Une pr�occupation est encapsul�e dans un HyperSlice et les r�gles de composition sont d�crites dans des HyperModules. Enfin, une phase de composition nomm�e int�gration r�unit tous les comportements pour former l?application finale.

Les trois activit�s li�es � la s�paration des pr�occupations sont assur�es par les HyperSpaces�:

• L?identification est la s�lection d?une pr�occupation, repr�sent�e par un HyperSpace. Elle contient les classes et les m�thodes qui lui sont pertinentes.

• Les pr�occupations sont ensuite encapsul�es pour �tre manipul�es comme des classes, dans diff�rents HyperSlices. Un HyperSlice contient une ou plusieurs pr�occupations.

• Finalement, pour int�grer correctement les pr�occupations, les HyperModules d�finissent les r�gles de composition.

Inspir�e de la programmation par sujets, la programmation structur�e en contextes vise � supporter la repr�sentation multiple et �volutive d'objets avec points de vue. La motivation principale est d'�tudier l'utilisation de r�f�rentiels d'objets intervenant dans des contextes applicatifs ou fonctionnels multiples ainsi que de proposer � la fois une d�composition orthogonale en objets de ces syst�mes et une d�composition transversale en fonction.

Le projet CROME (Vanwormout, 1999), �volution du projet ROME, repr�sente les objets selon des points de vues capturant les diff�rentes visions propres � chaque acteur du syst�me. En effet, chaque acteur attend une fonctionnalit� diff�rente du syst�me. CROME propose un cadre de programmation par objets structur�s en contextes fonctionnels, d�crits par des plans ou sch�mas.

Le plan de base contient les �l�ments communs � plusieurs points de vue. Il d�finit la structure du r�f�rentiel comme une hi�rarchie de classes. Les plans fonctionnels adaptent le plan de base � un contexte fonctionnel (une pr�occupation particuli�re) et ajoutent des �l�ments et des comportements propres � une fonctionnalit�. Chaque plan ��fonctionnel�� d�finit un point de vue sur les capacit�s de traitement du syst�me. Ce point de vue est d�di� � une activit� particuli�re.

La programmation structur�e en contextes s�pare les pr�occupations par la fourniture de points de vue d�di�s � des pr�occupations particuli�res. Contrairement � la programmation orient�e aspects, il n'y a pas de notion de tissage statique des pr�occupations. La s�paration des pr�occupations existe toujours � l'ex�cution dans le r�f�rentiel.

Cette approche r�pond notamment au probl�me de crosscutting entre objets et fonctions. En effet, l?approche objet identifie et d�coupe le syst�me en entit�s distinctes, mais ce d�coupage trop fin ne tient pas forc�ment compte du d�coupage fonctionnel du syst�me. Le m�canisme des contextes permet ce d�coupage du syst�me en fonctions ind�pendantes.

Les travaux pr�sent�s dans (Bardou et al., 1996) et (Malenfant, 1996) sur les objets morcel�s dans les langages � prototypes sont issus d?une rationalisation du lien de d�l�gation entre objets existant dans ces langages.

La notion d?objet morcel� vise � donner un statut aux objets en interpr�tant les morceaux comme des points de vue de celui-ci. Un objet morcel� se pr�sente comme l?agr�gation d?entit�s �l�mentaires, des morceaux (attributs et m�thodes) organis�s en hi�rarchies de partage d?attributs et de d�l�gation, selon les modalit�s assez fines offertes par ces langages.

Un morceau appartient toujours � un seul objet morcel�. Il est d�sign� par un nom unique � l?int�rieur de l?objet morcel� et n?a pas d?identit� � l?ext�rieur. Ce nom sert lorsqu?on veut envoyer un message � l?objet selon un point de vue particulier. Dans ce cas, le message est redirig� vers le morceau correspondant ou �ventuellement d�l�gu� au morceau parent dans la hi�rarchie si la m�thode n?y est pas trouv�e. Des op�rations pour ajouter ou supprimer dynamiquement des morceaux � l?objet morcel� sont �galement propos�es. Bardou (1998) aborde l?int�gration des objets morcel�s dans un langage � classes en respectant les notions sous-jacentes.

Nous avons appr�hend� les principaux langages de programmation utilisant le concept de vue. Chacun de ces langages propose sa propre solution et offre de nouveaux concepts et m�canismes. Nous comparons ces propositions selon les trois crit�res suivants�(Tableau 3) :

• Entit� principale�d�finit le niveau d?abstraction dans lequel la notion de vue est consid�r�e

• Composition de vues�d�finit la mani�re dont le partage de propri�t�s est sp�cifi� dans chacune des approches.

• Niveau d?abstraction�d�finit le niveau d?abstraction de la vue