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