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.