Chapitre 4 Réutilisation d’acquis pour aider l’ingénierie système
4.2 La formalisation et l’exploitation de connaissances métier
4.2.1 Problématique détaillée de la formalisation et de l’exploitation de connais-
La connaissance métier est selon China [China, 1997] « constituée de la somme des connaissances nécessaires pour faire fonctionner le système, en vue d’atteindre des objectifs technico-économiques donnés et ce compte tenu des contraintes liées à l’environnement». La formalisation de la connaissance métier permet, d’une part une meilleure efficacité dans la réalisation des processus et, d’autre part, fa- cilite la transmission du savoir et de l’expertise des personnels [Béler, 2008]. L’utilisation de la notion d’ontologie (voir définition chapitre 1) est très répandue (un panorama est proposé par exemple dans [Richards and Simoff, 2001, Brandt et al., 2008]). Ainsi, nous proposons dans cette section de détailler la formalisation de connaissances métier (nous nous intéressons à des connaissances explicites directe- ment exploitables de manière opérationnelle) à l’aide d’une ontologie de concepts afin de guider les décideurs dans leurs prises de décisions. L’ application de ces travaux permet de faciliter le couplage entre conception de systèmes et planification de projets au sein de la plate-forme logicielle ATLAS.
Le domaine de l’ingénierie système utilise fréquemment les ontologies, notamment en ingénierie concourante et collaborative où il s’agit de permettre à plusieurs équipes de conception de com- muniquer grâce à un langage commun [Roche, 2000, Kim et al., 2006]. Dans ce cas, les ontologies permettent de garantir une interopérabilité sémantique, c’est-à-dire la capacité de deux ou plusieurs concepteurs à se comprendre mutuellement [Zhang et al., 2003]. Une ontologie peut être un guide pour les concepteurs qui vont, à un niveau abstrait, initier la conception en recherchant dans l’on- tologie les concepts s’appliquant le mieux au système à concevoir. L’ontologie doit donc permet- tre de faciliter l’utilisation d’un langage commun et la compréhension commune de ce qui doit être conçu. Ceci doit permettre d’améliorer la communication entre les différentes parties prenantes du processus d’ingénierie système. Par exemple, cela peut s’appliquer dans un contexte d’ingénierie concourante où les travaux sont distribués sur plusieurs équipes, ou encore entre les acteurs du pro- cessus de conception, de l’identification des exigences à la définition/mise en œuvre des solutions. Dans [Zhang et al., 2003, Lau et al., 2009], les ontologies sont utilisées dans un processus de con- 88
4.2. La formalisation et l’exploitation de connaissances métier figuration de produits. On rencontre également leur emploi pour l’expression de préférences dans [Cao et al., 2011].
Les ontologies en conception sont souvent orientées « taxonomie », c’est-à-dire qu’un cadre est fourni par une hiérarchie de concepts avec, au mieux, la sémantique de chaque concept. Dans [Furtado et al., 2001] [Wriggers et al., 2007], les auteurs ajoutent des règles reflétant les dépendances entre les propriétés d’un concept. D’autres comme [Simoff et Maher, 1998], [Yang et al., 2008] ou [Mao et al., 2010] intègrent des contraintes au sein des concepts permettant ainsi de comprendre les contraintes inhérentes au système à concevoir mais pas de guider leur utilisation.
Dans cette section, notre problématique détaillée est exprimée ainsi : dans le cadre de nos travaux, il est nécessaire de disposer d’un référentiel afin de formaliser des connaissances métier en conception de systèmes et en planification de projets grâce à des concepts, des variables, leurs domaines et des contraintes sur ces variables dans le but de :
– fournir un cadre facilitant l’expression des exigences système et des solutions au sein des alter- natives système,
– fournir un cadre à la définition des tâches dans une structure de projet avec des concepts adaptés ainsi que leurs variables, domaines et contraintes.
Ainsi, nous abordons les propositions faites au regard de cette problématique détaillée de formali- sation et d’exploitation de connaissances métier dans la section 4.2.2.
4.2.2
Développements
Les développements ont été réalisés dans le cadre de la thèse de Joël Abeille (PhD.2) et du projet ANR ATLAS.
A) Formalisation des connaissances métier
Dans nos travaux, nous avons proposé une ontologie dont les concepts sont hiérarchisés selon une loi de type généralisation/spécialisation sans héritage multiple. L’ontologie est représentée à l’aide d’une arborescence dont la racine est le concept Universel le plus général et les feuilles sont les concepts les plus spécialisés. Chaque concept est caractérisé par :
– un ou plusieurs modèles de variables. Les modèles seront réutilisés, par recopie, afin de carac- tériser chacune des entités,
– un ou plusieurs modèles de domaines, propre à chaque variable et décrivant le domaine admissi- ble (par exemple : R, N, {Bleu, Rouge, Blanc}, etc.),
– un ou plusieurs modèles de contraintes afin de capitaliser des connaissances particulières à un concept donné. Chaque modèle de contrainte lie un ou plusieurs modèles de variables.
Ainsi, un concept Ck est caractérisé, outre son nom et sa sémantique propre, par un modèle de problème de satisfaction de contraintes [Montanari, 1974], c’est-à-dire par le triplet (VCk, DCk, ΣCk)
avec :
– VCk : l’ensemble des modèles de variables du concept Ck,
– DCk : l’ensemble des modèles de domaines du concept Ck,
– ΣCk : l’ensemble des modèles de contraintes du concept Ck.
Un modèle de contrainte permet de préciser les valeurs autorisées ou interdites, les associations de valeurs possibles, des règles logiques, des formules mathématiques impliquant des modèles de vari-
Chapitre 4. Réutilisation d’acquis pour aider l’ingénierie système
ables. Les modèles de domaine précisent les domaines de définitions des modèles de variables, ceux ci pouvant être continus, discrets, temporels, etc.
Au sein de l’ontologie, si un concept Cf ilsa pour concept père Cpere, alors le concept Cf ilshérite du concept Cpere l’ensemble des modèles de variables, l’ensemble des modèles de domaines et l’ensem- ble des modèles de contraintes. En outre, le concept Cf ils possède ses propres modèles de variables, domaines et contraintes qui le spécialisent.
Dans notre application au couplage de la conception système avec la planification de projets, l’on- tologie comporte des concepts propres aux systèmes à concevoir mais également des concepts propres aux projets et à leurs tâches. La création d’un système, d’un projet ou d’une tâche au sein d’un projet va être guidée par le concept approprié dans l’ontologie. Nous donnons un exemple d’ontologie utilisée pour illustrer les travaux de la thèse de Joël abeille [Abeille, 2011] (PhD.2).
– Universel (Ø, Ø, Ø) – Système (
. VSysteme= {Cout(C), M asse(M ), Risque(R)} ; . DSysteme= {DC : [0, +∞[, DM : [0, +∞[, DR : [0, 1]} ; . ΣSysteme= {∅})
– Longeron (
. VLongeron= {C, M, R, Longueur(Lo), Section(S)} ;
. DLongeron= {DC : [0, +∞[, DM : [0, +∞[, DR : [0, 1], DLo : [0, +∞[, DS : {U, I, T }} ; . ΣLongeron= {∅})
– Longeron_U (
. VLongeron_U = {C, M, R, Lo, S} ;
. DLongeron_U = {DC : [0, +∞[, DM : [0, +∞[, DR : [0, 1], DLo : [0, +∞[, DS : {U, I, T }} ; . ΣLongeron_U = {S = U })
– Projet (
. VP rojet= {Duree(Du), Debut(Dd), F in(Dt), T ype ressources(T ype_Ress), Quantite ressouces(Qte_Ress), Cout(C), Risque(Risk)} ;
. DP rojet= {DDu : [0, +∞[, DDd : [0, +∞[, DDt : [0, +∞[, DT ype_Ress : {Inge_Calcul, Inge_Structure, Inge_Elec}, DQte_Ress : [0, +∞[, DC : [0, +∞[, DRisk : [0, 1]} ; . ΣP rojet= {Dt ≤ Du + Dd})
– Tâche (
. VT ache= {Duree(Du), Debut(Dd), F in(Dt), T ype ressources(T ype_Ress), Quantite ressources(Qte_Ress), Cout(C), Risque(Risk)} ;
. DT ache= {DDu : [0, +∞[, DDd : [0, +∞[, DDt : [0, +∞[, DT ype_Ress : {Inge_Calcul, Inge_Structure, Inge_Elec}, DQte_Ress : [0, +∞[, DC : [0, +∞[, DRisk : [0, 1]} ; . ΣT ache{Dt ≤ Du + Dd})
Dans nos travaux, nous considérons que le travail de construction, mise à jour et maintien de l’on- tologie est dédié à la fonction de gestion des connaissances dans l’entreprise et doit être réalisé par des experts métiers. Nous n’abordons pas cet aspect dans nos travaux.
B) Exploitation des connaissances métier L’ontologie proposée permet :
– d’associer un concept à chaque système à concevoir afin de le caractériser à un niveau conceptuel (concept), ainsi qu’à un niveau détaillé (variables),
– d’associer un concept à chaque alternative système (ou solution) afin de la caractériser et ainsi faciliter sa formalisation en précisant les variables à renseigner,
– d’associer un concept à chaque projet afin de le caractériser et ainsi faciliter sa définition en 90
4.2. La formalisation et l’exploitation de connaissances métier précisant les variables à renseigner,
– d’associer un concept à chaque tâche afin de la caractériser et ainsi faciliter sa définition en précisant les variables à renseigner de même que sa planification au sein du projet.
Ainsi, suite à la réalisation de l’activité de Définition du système, le concepteur doit choisir un concept CS (Concept Système) qu’il associe aux informations sur le système à concevoir. Dès lors, l’ensemble des modèles de variables, domaines et contraintes inhérents au concept sont copiés dans les exigences système. Cela permet au concepteur de connaître les caractéristiques essentielles du système pour lequel il doit recenser les exigences. Ces exigences sont formalisées à l’aide des contraintes issues du concept, d’autres pouvant ensuite être rajoutées pour correspondre aux besoins exprimés par les différentes parties prenantes. Une illustration d’exigences systèmes construites à partir d’un concept de l’ontologie est donnée sur la figure 4.1.
FIGURE 4.1 – Exemple d’exigences système construites à partir d’un concept CS de l’ontologie [Abeille, 2011]
Lorsque les exigences systèmes ont été formalisées, le choix de développement d’alternatives sys- tèmes est mené de la même manière en choisissant, pour chaque alternative Ai envisagée, un concept CAi qui soit un descendant du concept CS dans l’ontologie, ou bien le concept CS lui-même. Ceci permet au concepteur d’être guidé dans l’élaboration des solutions, les variables à renseigner, leurs domaines ainsi que les contraintes à respecter étant connues. Une illustration d’alternative système construite à partir d’un concept CA (descendant de CS dans l’ontologie) est donnée sur la figure 4.2.
L’élaboration des projets associés aux systèmes est réalisée en suivant la même démarche : le con- cept adéquat est choisi dans l’ontologie et la connaissance qu’il contient est utilisée pour bâtir l’entité correspondante (un projet ou une tâche). Cette démarche d’ingénierie guidée par les connaissances de l’ontologie a également été développée dans le logiciel ATLAS. Le diagramme de classes correspon- dant à l’ontologie et aux informations de conception et de planification de projet est illustré sur la figure 4.3 (la classe Concept est dupliquée sur la figure).
Chapitre 4. Réutilisation d’acquis pour aider l’ingénierie système
FIGURE 4.2 – Exemple d’alternative système construite à partir d’un concept CA de l’ontologie
[Abeille, 2011]
FIGURE4.3 – Diagramme de classes correspondant aux concepts de l’ontologie et aux entités de projets et de systèmes [Abeille, 2011]
4.2. La formalisation et l’exploitation de connaissances métier