Le but de l?ing�nierie des exigences est d?obtenir un ensemble complet et coh�rent de sp�cifications. Ce r�sultat se construit tout au long du processus�; au d�part, les sp�cifications sont opaques, informelles et s?expriment uniquement par des vues personnelles. Ces vues refl�tent les comp�tences, objectifs et r�les de chaque participant. L?activit� de sp�cification est donc une activit� collective. Autoriser l?expression de vues multiples permet notamment une meilleure �licitation des besoins (Nuseibeh et al., 1994) (Clarke, 2001) et ne pourra �tre que b�n�fique au processus de sp�cification.

La notion de points de vue a �t� abord�e dans plusieurs travaux en ing�nierie des exigences, en tant que moyen de formulation des sp�cifications de logiciel (Darke et al, 1996) (Kotonya et al., 1992) (SE Journal, 1996) (Dubois et al., 1988) (Leite et al., 1991). Parmi les approches propos�es, nous distinguons celles bas�es sur des extensions de la m�thode SA (Structured Analysis), comme la m�thode CORE (Mullery, 1979), celles qui utilisent les points de vue en tant que moyen d?int�gration de multiples perspectives dans le d�veloppement de syst�mes (Finkelstein et al., 1992) et celles qui utilisent les points de vue comme moyen de d�finition et de structuration des sp�cifications (Kotonya et al., 1996). Le d�veloppement de techniques de m�ta-point de vue a �t� �galement abord�, par exemple dans Preview (Sommerville et al., 1997). Dans la suite, nous d�taillerons SADT, CORE, VOSE, VORD.

Les points de vue ont �t� introduits pour la premi�re fois dans la m�thode SADT (Structured Analysis and Design Technique) d�velopp�e vers la fin des ann�es 70 par Ross (Lissandre 990) (Marca et al., 1987) (Kotonya et al., 1998).

SADT est une m�thode de mod�lisation des donn�es et des activit�s d?un syst�me, descendante, modulaire, hi�rarchique et structur�e. Elle consid�re que la sp�cification d?un syst�me est fortement li�e � la fa�on dont on le per�oit. Elle impose au concepteur de choisir son point de vue d�s le d�part et de sp�cifier son syst�me enti�rement selon ce point de vue. Plusieurs mod�les d?un m�me syst�me peuvent ainsi �tre �tablis selon des points de vue diff�rents. Dans ce cas, les �l�ments d�crits dans les diff�rents mod�les SADT sont identiques, mais l?importance de chaque �l�ment, la terminologie utilis�e et le niveau de d�tails n�cessaires diff�rent. Le point de vue repr�sente donc la perspective selon laquelle l?ensemble du probl�me est �tudi�.

Ainsi, obtient-on des mod�les ind�pendants, chacun fortement li� aux points de vue choisis. Par exemple, ��Construire un programme de formation�� peut �tre d�crit selon quatre points de vue (responsable p�dagogique, formateur, auditeur, directeur de l?organisme de formation) et donner lieu � quatre mod�les SADT, puisque les activit�s sont pr�sent�es diff�remment dans chaque mod�le et que les donn�es communes ne se retrouvent pas au m�me niveau de d�tails dans chacun des mod�les.

Cependant, cette m�thode ne propose pas de m�canisme de corr�lation entre ces diff�rents mod�les, et on obtient une mod�lisation en multimod�les cloisonn�s. De plus, on note une absence de mapping des sp�cifications fonctionnelles � la conception de logiciels. Les sp�cifications d'analyse et de conception n'ont aucune relation directe et par cons�quent la tra�abilit� est perdue. De meilleures transitions de l'analyse de sp�cifications � la conception de logiciels rendent les techniques orient�es objet plus attrayantes pour les projets industriels de grande taille (Wortmann, 2001).

CORE, Controlled Requirements Expression, est la premi�re m�thode orient�e points de vue (Mullery, 1979) (Mullery, 1985), d�velopp�e en fin des ann�es 70 pour British Aerospace. Elle�est fond�e sur la d�composition fonctionnelle et adopte explicitement les points de vue pour formuler les sp�cifications.

La m�thode d�finit deux types de points de vue : Defining viewpoints est relatif aux sous-processus du syst�me, trait�s selon une approche descendante et Bounding viewpoints est relatif aux entit�s interagissant indirectement avec le syst�me � analyser (Kotonya et al., 1998).

Concept fondamental dans CORE, un point de vue repr�sente une entit� physique ou fonctionnelle qui m�morise ou traite l'information. Les fonctions, les sous-parties, les composants d'un syst�me ainsi que son environnement et les op�rateurs peuvent tous �tre mod�lis�s comme des points de vue diff�rents.

La m�thode identifie les points de vue le plus t�t et explicitement dans le processus d'�licitation et de sp�cification des besoins. Les points de vue dans CORE repr�sentent des entit�s de traitement de l'information qui sont syst�matiquement analys�es lors du d�roulement de la m�thode. L?orthogonalit� des points de vue (non chevauchement) dans CORE est peu r�aliste et limitatif si des perspectives multiples d?un syst�me r�el doivent �tre support�es (Nuseibeh, 1994).

La d�marche CORE comporte sept �tapes it�ratives et utilise quatre notations diff�rentes de diagrammes avec des annotations textuelles structur�es pour d�finir et analyser les sp�cifications d?un syst�me. La m�thode identifie les activit�s de chaque �tape ainsi que les contr�les � appliquer. Les sept �tapes sont�: viewpoint identification, viewpoint structuring, tabular collection, data structuring, single viewpoint modelling, combined viewpoint modelling et constraint analysis.

Toutes les �tapes de CORE utilisent des annotations textuelles structur�es. Elles sont d�velopp�es � l'aide de directives et d'heuristiques. Bien que les �tapes soient pr�sent�es d?une fa�on s�quentielle, l'analyse des sp�cifications en utilisant la m�thode CORE est un processus it�ratif.

ViewPoint Oriented System Engineering, VOSE, a �t� d�velopp� � ��Imperial College�� � Londres, au d�but des ann�es 90 par Finkelstein, Nuseibeh et al. (1992) comme un framework pour l?int�gration des m�thodes de d�veloppement dans les syst�mes compos�s (composite systems). Ce sont des syst�mes qui n�cessitent la combinaison de diff�rentes technologies et exigent le travail d?experts dans diff�rents domaines d'application, chacun d?eux ayant son propre int�r�t pour le syst�me. In�vitablement ces int�r�ts se recouvrent, demandant un grand effort pour la gestion et la coordination des sp�cifications. Cependant, ces domaines de recouvrement ne sont pas facilement identifiables. Une fois que la connaissance dans chaque domaine technologique est repr�sent�e de diff�rentes mani�res, plusieurs strat�gies pour le d�veloppement sont adopt�es. Pour �tre compar�s, les travaux des domaines distincts peuvent ne pas �tre dans la m�me �tape de d�veloppement.�

La m�thode utilise les points de vue pour diviser les activit�s et la connaissance des participants concernant le syst�me (Kotonya et al., 1998). Chaque point de vue est d�fini en tant qu?acteur (ou r�le dans le contexte de d�veloppement du syst�me) et son point de vue sur le syst�me, repr�sent� par sa connaissance partielle du syst�me (ses responsabilit�s). Cette information est organis�e dans un point de vue et repr�sent�e par un arrangement (scheme) de cinq dimensions : style, domain, specification, work plan et work record.

• La dimension Style d�crit le mod�le de repr�sentation utilis� par le point de vue.

• La dimension Work plan sp�cifie les actions de d�veloppement, le processus et la strat�gie du point de vue.

• La dimension Domain d�crit le sujet de pr�occupation du point de vue dans le syst�me global en cours de d�veloppement.

• La dimension Specification pr�cise le domaine du point de vue dans la notation d�crite dans la dimension Style�et d�velopp�e en utilisant la strat�gie d�crite dans la dimension Work plan.

• La dimension Work record enregistre l'�tat de d�veloppement et l'historique des sp�cifications du point de vue. C'est le moyen d?assurer la tra�abilit� des sp�cifications.

La dimension Work Plan constitue le noyau du point de vue. On y sp�cifie les actions de contr�le contenant des actions disponibles au d�veloppeur pour v�rifier la coh�rence des sp�cifications. Les actions de contr�le sont de deux natures : intra ou inter points de vue (in/out-viewpoint checks). Les premiers consistent � v�rifier la coh�rence des sp�cifications � l'int�rieur du point de vue tandis que les seconds contr�lent la coh�rence des sp�cifications d?un point de vue avec celles des autres.

VORD a �t� propos� par Sommerville et Kotonya (1996). C?est une m�thode pour la validation pr�alable des sp�cifications, principalement d�di�e aux syst�mes interactifs et � la r�solution de points de vue. VORD introduit des points de vue focalis�s sur les probl�mes utilisateur et les pr�occupations d?ordre organisationnel. Le mod�le adopt� pour les points de vue est orient� service�; les points de vue jouent un r�le analogue aux clients dans un syst�me client-serveur. Les points de vue de VORD sont regroup�s en deux classes :

1. Les Points de vue directs correspondent directement aux clients du fait qu?ils re�oivent des services du syst�me et lui envoient des informations de contr�le et des donn�es. Ce sont des op�rateurs/utilisateurs du syst�me ou des sous-ensembles connect�s au syst�me � analyser.

2. Les points de vue indirects�ont un ��int�r�t�� sur une partie ou sur tous les services qui sont fournis par le syst�me mais qui n'interagissent pas directement avec lui. Les points de vue indirects produisent des sp�cifications qui contraignent les services fournis aux points de vue directs.

Les points de vue sont structur�s dans une hi�rarchie de classification pour satisfaire les variations des sp�cifications des utilisateurs. Un point de vue de VORD encapsule un ensemble d?attributs qui aident � d�finir et structurer les sp�cifications (Kotonya et al., 1996). Bri�vement, un template point de vue comporte les composants suivants :

• Identifier attribue un num�ro de r�f�rence unique � chaque point de vue.

• Label et description d�crivent le nom et le r�le du point de vue.

• Type trace l'origine du point de vue � un point de vue indirect ou direct.

• Attributes caract�risent le point de vue dans le domaine de probl�me.

• Requirements dressent la liste des conditions du point de vue.

• Event scenarios d�crivent l'interaction entre le point de vue et le syst�me.

• History d�crit l'�volution des sp�cifications du point de vue.

Un exemple d?�tude de cas pratique plus d�taill� est pr�sent� par Kotonya (1999).

Le tableau suivant r�capitule la notion de point de vue propos�e dans les approches �tudi�es, Les crit�res consid�r�s traitent la classification de ces m�thodes en ing�nierie des exigences et le niveau d?int�gration du concept de point de vue dans la m�thode.

Dans cette section, nous pr�sentons un aper�u des frameworks d�di�s � la conception multipoint de vue. Nous regardons plus particuli�rement les relations et la coh�rence entre diff�rents points de vue.

Le but du framework GRAAL, Guidelines Regarding Architecture Alignment, (Eck et al., 2004) (Wieringa et al., 2003) est d?aligner les parties de conception globale d?un syst�me. � cet effet, il pr�sente les dimensions selon lesquelles les points de vue dans une conception de syst�me peuvent �tre classifi�s. Le framework GRAAL se compose de quatre dimensions orthogonales (aspect, agr�gation, raffinement, cycle de vie) illustr�es en figure 8. La quatri�me dimension (cycle de vie) est dessin�e s�par�ment pour surmonter les difficult�s d?un sch�ma quadridimensionnel.

La dimension �aspects� classe les points de vue selon les propri�t�s ext�rieures observables du syst�me trait�es par les points de vue. Elle consid�re qu'un syst�me offre des services avec une certaine qualit� et classe les points de vue selon ces deux aspects et plus encore en sous-aspects. Elle aborde des sous-aspects comme l'aspect comportement qui pr�sente les ordres possibles des offres de service et la qualit� de service attendue par l'utilisateur.

La dimension �niveau d'agr�gation� ordonne les points de vue selon le niveau d'agr�gation (des parties du syst�me) consid�r� par ces points de vue. � chaque niveau d'agr�gation quelques parties inter-agissantes du syst�me sont repr�sent�es. Ces parties inter-agissantes du syst�me fournissent des services au niveau plus �lev� d?agr�gation. Parmi les niveaux d'agr�gation abord�s par le framework, nous citons�:

• le niveau d'infrastructure physique qui se compose des parties physiques du syst�me (par exemple PC, r�seau) et fournit des services qui permettent � des niveaux plus �lev�s d'agr�gation de s'ex�cuter ;

• le niveau m�tier compos� des parties m�tiers (par exemple acteurs, r�les) qui fournit des services m�tier � un environnement de clients.

La dimension �raffinement� ordonne les points de vue selon le niveau de d�tail avec lequel les points de vue d�crivent le syst�me. L?ajout de d�tail � un point de vue revient � raffiner ce point de vue. Le framework ne consid�re pas la d�composition comme une forme de raffinement, parce que la dimension agr�gation traite la d�composition d'un syst�me en parties. En revanche, chaque partie du syst�me peut �tre raffin�e ind�pendamment, en la d�crivant avec plus d'informations. Par exemple, nous pouvons d�crire chaque partie en d�crivant son but et nous pouvons la raffiner en d�crivant comment la partie r�alise son but (Eck et al., 2004).

La dimension �cycle de vie� ordonne les points de vue selon l?�tape du cycle de vie du syst�me abord� par les points de vue. Cette dimension consid�re les �tapes comme : la conception du syst�me, l'utilisation et la maintenance du syst�me.

Le but d'ArchiMate (Lankhorst, 2005) est de d�crire les relations entre diff�rents points de vue, appel� aussi domaines dans ArchiMate (Lankhorst, 2005) dans une conception de syst�me. � cet effet il pr�sente les concepts qui peuvent �tre utilis�s dans la conception � partir de ces diff�rents points de vue. Il pr�sente �galement les relations qui peuvent �tre utilis�es pour relier (des instances de) des concepts du m�me ou de diff�rents points de vue. ArchiMate classe les points de vue par cat�gorie selon le niveau (m�tier, application ou technologie) et les aspects qu?ils abordent. La Figure 8 montre les diff�rents aspects et couches dans la conception de syst�me avec ArchiMate.

Semblable au framework GRAAL, ArchiMate distingue des niveaux d?agr�gation, appel�s couches, telles que chaque couche fournit des services aux couches sup�rieures. Cette architecture distingue trois couches : m�tier, application et technologie.

ArchiMate distingue les aspects abord�s dans chaque couche. Il distingue les aspects structuraux et comportementaux. Les aspects structuraux sont aussi classifi�s dans des aspects structuraux actifs et passifs. L'aspect structural actif repr�sente les parties qui prennent l'initiative dans l'ex�cution des activit�s (par exemple des acteurs m�tier ou des composants logiciel actifs). L'aspect structural passif repr�sente les parties qui ne prennent pas d'initiative (par exemple des objets d'information). Dans les aspects structuraux et comportementaux nous pouvons distinguer des aspects externes et internes. Les aspects externes repr�sentent les aspects qui sont observables par les utilisateurs d'une couche. Les aspects internes repr�sentent les aspects qui ne le sont pas.

ArchiMate pr�sente des concepts abstraits et des relations (Lankhorst, 2005) utilis�s pour construire une conception en couches. Les concepts abstraits et les relations ne peuvent �tre utilis�s que pour la conception � un haut niveau d'abstraction. Pour construire des conceptions plus d�taill�es, ArchiMate se base sur des langages sp�cifiques aux points de vue. Ceci est en conformit� avec la philosophie d'ArchiMate, dans laquelle les participants utilisent leurs propres langages et outils afin de construire des conceptions, selon leurs points de vue. Les conceptions des diff�rents points de vue peuvent �tre import�es dans ArchiMate � un haut niveau d'abstraction, abr�geant en cons�quence des d�tails qui sont repr�sent�s dans les langages sp�cifiques de points de vue. Par exemple, une conception de processus m�tier peut �tre import�e dans ArchiMate. Le r�sultat est une conception qui repr�sente des activit�s et un flux de relations entre ces activit�s, mais sans d�tails sur le flux de relations.

Nous pouvons utiliser ArchiMate pour relier les activit�s de processus m�tier aux services d'application qui les supportent, qui sont import�s d'autres langages et outils.

Le mod�le de r�f�rence RM-ODP, Reference Model for Open Distributed Processing, (ISO, 2008), pr�sente un mod�le de r�f�rence qui permet de d�finir des normes pour la conception et le d�veloppement des syst�mes distribu�s ouverts (ODP). Il consiste en un ensemble de concepts et fonctions qui peuvent �tre utilis�s pour d�finir des normes conformes � RM-ODP.

RM-ODP d�finit de mani�re abstraite, et donc adaptable � un contexte d?application, une architecture qui supporte les aspects distribution, r�seaux, interop�rabilit�, portabilit�. Ce mod�le doit permettre d?organiser en un tout coh�rent, les diff�rentes parties d?un syst�me, c?est-�-dire, la portabilit� d?une application sur des plates-formes h�t�rog�nes, l?�change d?informations et l?utilisation de fonctionnalit�s h�berg�es et offertes par diff�rents syst�mes ouverts dans un environnement distribu�, et une transparence de la distribution des applications et utilisateurs.

La sp�cification compl�te de tout syst�me r�parti complexe implique une tr�s grande quantit� d?information. Pour bien appr�hender cette complexit�, le syst�me est consid�r� � partir de diff�rents points de vue, chacun refl�te un ensemble particulier de pr�occupations. De cette fa�on une s�paration normale des pr�occupations est obtenue (Putman, 2000).

RM-ODP propose cinq points de vue pour sp�cifier des syst�mes ODP, chacun se concentrant sur un sujet de pr�occupation particulier. Selon l?ISO, les points de vue RM-ODP forment un ensemble n�cessaire et suffisant pour satisfaire les besoins de standards de syst�mes r�partis ODP. Les points de vue peuvent �tre appliqu�s, � un niveau appropri� d'abstraction, pour la sp�cification d'un syst�me complet ODP ou pour la sp�cification de diff�rents composants d'un syst�me ODP.

Chaque point de vue a un langage de points de vue associ� d�finissant des concepts et des r�gles pour sp�cifier des syst�mes ODP � partir des point de vue correspondants. Les langages de points de vue sont des langages abstraits dans le sens qu'ils n'impliquent aucune syntaxe ou notation particuli�re. En principe, n'importe quel langage existant peut �tre utilis� pour la sp�cification d'un syst�me d'un point de vue particulier, � condition que ces sp�cifications puissent �tre interpr�t�es en termes de concepts du langage de points de vue et adh�re aux r�gles d�finies (Putman, 2000).

Les concepts de RM-ODP sont structur�s selon cinq points de vue :

• Le point de vue entreprise qui d�finit des concepts et des relations entre concepts pour sp�cifier le r�le d'un syst�me ODP dans un environnement�;

• Le point de vue traitement qui d�finit des concepts et des relations entre concepts pour sp�cifier une d�composition fonctionnelle d'un syst�me ODP�;

• Le point de vue information qui d�finit des concepts et des relations entre concepts pour sp�cifier la structure d'information dans un syst�me ODP et les op�rations de base qui peuvent �tre appliqu�es sur cette information�;

• Le point de vue ing�nierie qui d�finit des concepts et des relations entre concepts pour sp�cifier les m�canismes et les fonctions qui supportent les interactions distribu�es entre les parties du syst�me ODP�;

• Le point de vue technologie qui d�finit des concepts et des relations entre concepts pour sp�cifier la technologie sur laquelle un syst�me ODP est impl�ment�.

La sp�cification compl�te du syst�me est alors constitu�e de l'ensemble des sp�cifications �tablies dans chaque point de vue avec leurs r�gles de correspondance. RM-ODP d�finit des r�gles de coh�rence qui aident � garder les sp�cifications de points de vue coh�rentes. Les r�gles de coh�rence consistent en des correspondances qui sp�cifient � quels concepts d'un point de vue correspondent des concepts d'un autre point de vue. Si les concepts d'un point de vue correspondent aux concepts d'un autre point de vue, alors les sp�cifications de ces points de vue doivent avoir des relations de correspondances. Les relations de correspondances sp�cifient ainsi les correspondances entre des instances de concepts d?une sp�cification d?un point de vue et des instances de concepts d'une sp�cification d?un autre point de vue.

ViewPoints Framework (Finkelstein et al., 1994) est l'un des premiers travaux les plus influents sur la conception et la coh�rence multipoints de vue. C'est le premier travail qui a chang� l'id�e des vues en tant qu?abstractions d'informations existantes aux vues qui sont d�velopp�es s�par�ment par diff�rents stackeholders.

Dans ViewPoints Framework, chaque point de vue est d�fini par cinq �l�ments :

• un domaine qui indique l'univers de discours du point de vue ;

• un style qui d�finit le langage de mod�lisation utilis� pour la conception du point de vue ;

• un plan de travail qui d�finit le processus selon lequel une conception peut �tre construite � partir du point de vue ;

• une sp�cification qui repr�sente la conception du point de vue, en utilisant le langage de mod�lisation d�fini par le style ;

• un enregistrement de travail qui repr�sente les informations sur l'�tat courant et l'historique d?une sp�cification.

La conception compl�te du syst�me consiste en un ensemble de points de vue et des r�gles qui d�finissent des conditions pour la coh�rence entre ces points de vue. Chaque r�gle d�finit une condition qui doit �tre maintenue dans une sp�cification coh�rente et d�finit une action qui doit �tre prise si cette condition est viol�e. Les r�gles sont sp�cifi�es comme des requ�tes sur la base de donn�es qui contient la conception.

Pour v�rifier la coh�rence, ViewPoints Framework suppose que les sp�cifications de points de vue et les r�gles de coh�rence sont d�finies dans une base de donn�es qui supporte le raisonnement avec la logique de premier ordre. La base de donn�es ex�cutera alors le contr�le de coh�rence.

OpenViews (Boiten et al., 2000) pr�sente une approche pour maintenir la coh�rence dans des conceptions bas�es sur RM-ODP, bien qu'il puisse �tre appliqu� dans un contexte plus g�n�ral.

OpenViews d�finit que deux vues sont coh�rentes si on peut trouver une conception qui est un raffinement des deux vues. Les vues peuvent �tre mod�lis�es en utilisant diff�rents langages de mod�lisation, dans ce cas l?une des vues doit �tre transform�e, de telle sorte que les vues soient repr�sent�es dans le m�me langage. Plus sp�cifiquement, OpenViews d�crit en d�tail comment associer les vues repr�sent�es dans Lotos (Eijk et al., 1989) et Object-Z (Smith, 2000). Pour ce but, (Derrick et al., 1999) d�finissent comment transformer une vue repr�sent�e dans Lotos en vue repr�sent�e dans Object-Z.

OpenViews diff�re des approches pr�c�dentes qui se fondent sur des relations entre vues et des r�gles de coh�rence. Il diff�re de ces approches parce qu'il d�finit quand deux vues sont dites coh�rentes (i.e. quand un raffinement coh�rent commun peut �tre trouv�). Les approches ci-dessus d�finissent que deux vues ne sont pas coh�rentes si les r�gles de coh�rences ne sont pas satisfaites.

Le Tableau 5 illustre les niveaux de support que les frameworks �tudi�s retiennent pour d�finir des relations entre vues et pour contr�ler la coh�rence entre ces vues. Le tableau classe le support selon deux crit�res : l?expressivit� des relations entre vues et le support conceptuel.

Le crit�re d?expressivit� distingue les frameworks selon le support qu'ils ont pour d�finir des r�gles de coh�rence. Au plus bas niveau, un framework supporte la d�finition des relations entre vues et ne d�finit pas les r�gles de coh�rence qui s'appliquent � ces relations. Au niveau suivant, le framework supporte la d�finition des r�gles de coh�rence. Cependant, des r�gles avanc�es de coh�rence telles que le raffinement, ne sont pas support�es. Au niveau le plus �lev�, le framework supporte pleinement la d�finition des r�gles de coh�rence.

Un framework supporte conceptuellement des relations entre vues, s?il fournit des concepts pour les vues consid�r�es dans le framework. Ces concepts fournissent un cadre de r�f�rence qui aide les concepteurs � penser aux relations entre vues. D'abord, les concepteurs doivent d�finir les relations entre les concepts sp�cifiques aux points de vue et les concepts du framework. En second lieu, ils doivent d�finir la relation entre concepts de diff�rents points de vue, en utilisant les relations entre les concepts du framework. Un framework peut fournir le support conceptuel � un degr� variable.

Les concepts abstraits fournissent des abstractions des concepts qui peuvent �tre utilis�s dans chacune des vues (couvertes par le framework). Puisqu'ils sont des abstractions, ils ne peuvent pas couvrir toutes les propri�t�s de conception en d�tail. Les concepts abstraits communs ont la propri�t� suppl�mentaire qu'ils sont partag�s entre vues, l� o� les concepts abstraits standard sont diff�rents pour chacune des vues. Les concepts de base (communs) couvrent toutes les propri�t�s de conception en d�tail.

Le logiciel est devenu une partie complexe, sensible et essentielle dans la r�ussite de la majorit� des projets. Pour ma�triser le d�veloppement de syst�mes de qualit� et faire face � l'explosion des besoins en logiciels, il est n�cessaire d'�laborer des m�thodes de conception adapt�es � la complexit� des logiciels et � la diversit� des contraintes techniques � prendre en compte, le tout avec une exigence de coh�rence et un objectif de meilleure ad�quation aux diff�rentes perceptions des services � offrir.

Dans cet article, nous avons pass� en revue, plusieurs disciplines en informatique qui utilisent les notions de vue, point de vue ou perspective�: en repr�sentation de connaissances, en bases de donn�es, en programmation par objets, en phase d?ing�nierie des exigences et en architecture de syst�mes. L'attrait du recours au concept de vue est double.

D'une part, chaque vue peut �tre d�crite dans un formalisme d�di�, adapt� au domaine concern� et g�n�ralement bas� sur une notation graphique intuitive. Le choix de la notation associ�e � une vue est guid� par les soucis de clart�, de concision et privil�gie les abstractions utiles � chaque domaine. D'un point de vue m�thodologique, la s�paration en vues et les formalismes d�di�s simplifient les descriptions, facilitent la compr�hension et la communication entre les membres d'un projet.

D'autre part, la d�composition en vues favorise la s�paration des probl�mes puisque chaque vue se concentre sur un aspect du syst�me. Ce principe de d�composition fournit un puissant m�canisme de structuration.

Partant de cet �tat de l?art et de ces constats, nous avons �labor� un ensemble de propositions pour d�velopper une d�marche d?ing�nierie dirig�e par des points de vue et s?appuyant sur des composants multivues r�utilisables.

L?approche ViewPoint Oriented Design (VPOD) que nous pr�conisons (Lahna et al., 2005a), s?inscrit dans le cadre de la m�thode de conception par points de vue COPV (Conception Orient�e Points de vues) (Lahna et al., 2005b). Elle propose une d�marche d?ing�nierie adoptant le principe de r�utilisation et d?adaptation de composants multivues, offrant la possibilit� de voir le mod�le d?un syst�me selon diff�rentes facettes, refl�tant les visions des diff�rents acteurs du syst�me. Plus pr�cis�ment, VPOD propose une extension du m�tamod�le UML pour guider les concepteurs dans la mod�lisation de syst�me, en int�grant le concept de points de vues et propose des fragments de d�marche sous forme de patterns processus et de carte de processus.

VPOD permet d?allier le domaine de conception bas� sur les patterns et les approches par points de vue afin d?�laborer des composants multivues adaptables et r�utilisables et d?en proposer un formalisme de repr�sentation pour aider les concepteurs de SI dans leur t�che de mod�lisation, en favorisant la r�utilisation des composants quelque soit le m�tier.

L?objectif est d?aider � la r�utilisation et � la capitalisation de connaissances afin d?am�liorer et d?aider les concepteurs dans leur activit� de mod�lisation de syst�mes complexes selon une approche d?int�gration de vues. En d?autres termes, VPOD permet de d�finir un cadre conceptuel de d�finition d?une d�marche d'ing�nierie de syst�mes d'information � base de composants multivues.

Actuellement, l?approche VPOD est bas�e sur des contraintes OCL pour repr�senter les r�gles de coh�rences. Ces contraintes OCL informent le concepteur quand une r�gle de coh�rence n?est pas respect�e. Cependant, elles ne fournissent pas les raisons pour lesquelles cette r�gle de coh�rence est viol�e. Une telle information est utile pour r�soudre les incoh�rences. Nous proposons le d�veloppement de r�gles de coh�rence qui fournissent une telle information. On peut s?inspirer de travaux qui abordent les aspects de tra�abilit�.

D?un autre c�t�, nos propositions se sont limit�es � l?aspect structurel du syst�me � concevoir. Nous n'avons pas d�fini les concepts pour repr�senter la dynamique du syst�me (en termes d?extension du m�tamod�le UML). Une telle recherche n�cessite de s?appuyer non seulement sur des travaux de conceptualisation pour proposer de nouveaux mod�les, mais aussi sur des r�alisations d?environnements de conception indispensables pour op�rationaliser les propositions et en faciliter la validation sur des cas significatifs.