• Aucun résultat trouvé

Partie II : Couplage par les connaissances métier

6.1 Définition de la réutilisation de cas

6.1.1 Définition du raisonnement à partir de cas

Le raisonnement à partir de cas (RàPC) s’inscrit bien souvent dans une boucle de retour d’expérience. « Le retour d’expérience est une démarche structurée de capitalisation et d’exploitation des connaissances issues de l’analyse d’évènements positifs et/ou négatifs. Elle met en œuvre un ensemble de ressources humaines et technologiques qui doivent être organisées pour contribuer à réduire les répétitions d’erreurs et à favoriser certaines pratiques performantes » [Beler, 2008] [Clermont et al., 2007] [Rakoto et al., 2002]. Le Raisonnement à Partir de Cas peut être considéré comme un sous-processus permettant de supporter cette démarche de retour d’expérience.

Nous rappelons que le RàPC est une méthodologie de résolution de problèmes basée sur l’exploitation des expériences passées. Les problèmes précédents et leurs solutions sont capitalisés dans une base d’expériences. Ces expériences constituent une base de cas (appelés cas sources) qui seront comparés à un nouveau problème (cas cible) afin de construire, par adaptation, une solution.

Le modèle classique de RàPC (ou Case-Based Reasoning – CBR) décrit dans [Kolodner, 1993] [Aamodt et Plaza, 1994] [Kolodner et Leake, 1996] est basé sur quatre activités : Recherche, Adaptation, Révision, Capitalisation. Dans ce modèle, le problème est considéré comme déjà défini. D’autres modèles plus récents considèrent une cinquième étape initiale de formalisation du problème (voir par exemple [Finnie et Sun, 2003] [Cortes Robles et al., 2009]). C’est ce dernier modèle que nous utilisons pour formaliser notre proposition.

Les cinq activités sont :

la définition du problème : il s’agit de formaliser le problème avec une sémantique claire afin de construire le cas cible ;

129

la recherche : il s’agit d’identifier, parmi les cas sources, ceux qui sont les plus similaires au cas cible afin d’être, le cas échéant, en mesure de les réutiliser pour bâtir la solution ;

l’adaptation : suite au choix d’un cas source évalué suffisamment similaire, celui-ci doit être modifié, adapté afin de proposer une solution. Soit le cas source choisi répond parfaitement au problème et l’adaptation est immédiate, soit il ne correspond que partiellement et, dans ce cas, il doit être modifié ;

la révision : la suggestion de solution issue de l’adaptation doit être révisée, réparée afin d’être cohérente, complète et pouvoir être ensuite capitalisée à son tour dans la base de cas. Souvent, la solution obtenue suite à l’adaptation est partielle et nécessite une analyse complémentaire afin d’être complétée puis vérifiée. Il ressort de cette étape un cas testé et/ou réparé ;

enfin, la capitalisation : cette étape consiste à enregistrer le nouveau cas dans la base de cas. Ceci nécessite un certain niveau d’expertise afin de décider si le cas peut alimenter la base d’expériences et constituer ainsi un atome supplémentaire de connaissance contextualisée. Dans le cas présent, nous intégrons la capitalisation à l’intérieur du projet car cela permet de ne pas réaliser cette étape en la repoussant indéfiniment.

6.1.2 Réutilisation de cas en conception et en planification

Concernant la réutilisation en conception de systèmes, de nombreux travaux ont été menés. La plupart proposent des approches de Raisonnement à Partir de Cas dont la définition du problème à résoudre est basé sur un ensemble de descripteurs et des valeurs attendues pour ces descripteurs. Nous pouvons citer, entre autres, [Maher et Gómez de Silva Garza, 1997] qui présentent les applications du RàPC pour la conception et commentent les deux aspects de la conception basée sur les cas : l’aide à la conception et l’automatisation de la conception. Des applications récentes du RàPC existent comme [Renaud et al., 2007] qui proposent un panorama actuel de l’utilisation du RàPC en conception et en configuration de produits.

Concernant le raisonnement à partir de cas pour la planification de projets, nous pouvons citer les travaux menés sur la mémoire de projet tels que ceux exposés dans [Matta et al., 2000] ou dans [Bekhti, 2004]. La mémoire de projet est définie par « les leçons et expériences provenant d’un projet donné ». Il s’agit de considérer l’objectif du projet et son contexte, l’organisation du projet (équipes, participants, tâches, etc.), les références associées (règles, méthodes, directives, etc.), la réalisation du projet (problèmes rencontrés, solutions apportées, etc.) afin de capitaliser la connaissance propre à ce projet et donc de guider la définition et la mise en œuvre de projets ultérieurs.

Dans le cadre du couplage de la conception de système et de la planification de projet de conception, il n’existe pas, à notre connaissance, de travaux mettant en œuvre la réutilisation. Nous proposons donc que la réutilisation concerne la conception de systèmes mais également les projets de conception.

Aussi, nous pouvons constater que peu de travaux font appel à la notion de concept (et par extension à la notion d’ontologie) à l’exception de quelques travaux tels ceux présentés dans [Wriggers et al., 2007] qui proposent d’utiliser les ontologies associées au raisonnement à partir de cas pour supporter l’analyse de systèmes ou [Lee et Liu, 2009] qui proposent une approche similaire pour la conception des services d’un robot. De plus, peu de travaux offrent la possibilité d’exprimer le problème de conception sous forme de contraintes, variables et domaines comme nous le proposons

130

dans la section 5.1. Nous citons toutefois les travaux présentés dans [Negny et Le Lann, 2008] ou dans [Yan-hong et Guang-xin, 2009] qui proposent une démarche assez similaire.

Enfin, il est difficile d’exprimer des exigences système en introduisant de la flexibilité afin d’élargir le spectre de recherche de cas dans le but d’exprimer des préférences pour le concepteur ou encore de tenir compte de la notion de similarité entre valeurs d’une même variable. Toutefois, [Negny et Le Lann, 2008] proposent de prendre en compte l’imprécision grâce à la logique floue.

6.1.3 Définition du couplage par réutilisation de cas

Nous proposons ici une définition du couplage par réutilisation de cas. Nous avons vu dans la première partie du mémoire que le couplage structurel permettait de fédérer des artefacts de conception avec ceux de planification. Le couplage par réutilisation de cas est mis en œuvre chaque fois qu’une alternative système est conçue. Il consiste, une fois que les exigences système ont été formalisées :

 à rechercher des alternatives système antérieurement conçues et compatibles avec les nouvelles exigences système dans la base de cas,

 pour chacune, à identifier la tâche de développement d’alternative au sein du projet associé (par exploitation du couplage structurel),

 lorsque la décision de réutilisation d’une alternative système est prise, d’adapter la tâche de développement d’alternative TD associée et de la réviser afin qu’elle soit mise en œuvre puis,

 d’adapter et réviser l’alternative système pour élaborer la nouvelle solution,

 de capitaliser l’ensemble dans la base de cas.

Bien entendu, les principes du couplage informationnel sont également suivis afin de synchroniser les tâches et de réaliser les analyses de faisabilité et de vérification. Quant au couplage décisionnel, les tableaux de bord permettent de suivre l’évolution du processus et de prendre les décisions en consultant les indicateurs.