Implémentation d’un démonstrateur

Structure logicielle du démonstrateur

Cette partie présente le démonstrateur de CACDA, notamment les choix de développement et l’architecture logicielle retenue. Il est à noter que ces choix sont avant tout techniques, d’autres outils ou langages de programmation pourraient être utilisés à des fins similaires. Le démonstrateur est développé en Python15, langage bien connu et disposant d’une large communauté et de nombreuses bibliothèques. L’utilisation de ces bibliothèques spécialisées facilite le développement, en particulier pour la communication du démonstrateur avec plusieurs ressources externes, notamment des outils de traitement du langage naturel et une base de données orientée graphe. Python sert donc de langage pivot entre les différentes couches spécialisées du logiciel (Figure 35). 15 https://www.python.org/ Figure 34 : Développement d’un démonstrateur technique Implémentation d’un démonstrateur 76 La première couche spécialisée est l’interface web de l’application, permettant l’interaction avec le concepteur. Elle est réalisée avec une bibliothèque Python nommée Dash16 qui fournit une infrastructure pour créer des interfaces web. L’interface du démonstrateur est présentée dans la suite de ce chapitre (Figure 43). La deuxième couche contient les outils spécialisés nécessaires au traitement du langage naturel. Il s’agit de Stanford CoreNLP 17 pour les algorithmes d’analyse, de l’ontologie ConceptNet18 et du thésaurus WordNet19 pour l’enrichissement sémantique. Ces outils sont utilisés lors de l’écriture du sous-contexte sémantique et de l’enrichissement sémantique du graphe. Ce processus est détaillé dans la partie 3.2.1. La troisième couche est appelée DAO pour “Direct Access Object” et permet l’interaction de l’assistant avec la base de données. Nous utilisons py2neo, une API Python, pour manipuler directement les nœuds et relations de la base de données. La dernière couche logicielle est celle de notre base de données. Nous utilisons la base de données orientée graphe NEO4J [97]. Comme mentionné dans l’état de l’art, NEO4J permet la modélisation d’un graphe de connaissances essentiel au raisonnement sur les données. Ce choix est tout d’abord justifié par la souplesse de NEO4J sur la structure des données, nous permettant d’améliorer notre modèle de données au fur et à mesure de l’avancée du développement du démonstrateur. L’outil permet également une interface simple avec des programmes externes, ce qui facilite le développement.

Fonctionnalités du démonstrateur

Lors de l’analyse fonctionnelle de CACDA, nous avons identifié 3 services permettant d’améliorer la maîtrise des règles de conception. Notre démonstrateur apporte une réponse technique à chacun de ces services. Notre objectif est de réaliser un démonstrateur de CACDA afin que sa pertinence, son principe de fonctionnement et son utilisabilité puissent être testés. 3.2.1 Ecriture des sous-contextes sémantique et technique Le premier service de l’assistant est de structurer les règles de conception et le contexte de conception dans un graphe de connaissances. Comme présenté dans l’état de l’art, plusieurs approches existent pour extraire des règles de conception de documents en langage naturel [43]. Cependant, cette technologie est encore complexe à mettre en part et ne constitue pas le cœur de notre apport. En conséquence, nous considérerons pour notre démonstrateur, que l’ensembles des règles utilisées sont stockées dans des documents semi-structurés, listant les documents sources de ces règles, les chapitres auxquels elles appartiennent ainsi que leurs énoncés principaux (Tableau 11). Numéro de règle Enoncé principal Document source Numéro de chapitre 1 All milling element should be modeled with respect to cutter diameter. When possible, always select a standard dimension for milling cutters to minimize cost. Design Rules for Metallic Parts 4.2.2 2 The maximum cutting height of a milling cutter determines the maximum depth of a pocket that can be machined. This value depends on the cutter diameter Design Rules for Metallic Parts 4.2.2 3 It is necessary to have between wall corners a radius higher than the milling cutter radius Design Rules for Metallic Parts 4.2.3 Tableau 11 : Extrait du document source semi-structuré Avec ces données d’entrée, le processus de création du graphe se déroule en 4 étapes (Figure 36) : Etape 1 : L’ensemble des règles de conception sont extraites des documents semistructurés. Le démonstrateur peut ainsi créer les nœuds qui correspondent aux règles, documents et chapitres. Les énoncés des règles sont récupérés afin d’en réaliser l’analyse. Etape 2 : Les mots-clés issus de l’énoncé principal des règles de conception sont extraits et rajoutés au graphe. Ils passent ensuite par un processus de désambiguïsation et d’enrichissement sémantique. Ces procédés permettent d’ajouter des éléments sémantiques proches du mot d’origine (synonymes, concepts, etc.) afin de faciliter la recherche des règles. Les détails techniques de ces procédés ainsi qu’un exemple représentatif sont donnés ci- 78 Figure 36 : Architecture logicielle pour l’écriture du graphe de connaissances dessous. Les nœuds contenant du texte (documents, chapitres, définitions etc.), à l’exception des règles, sont rattachés aux mots-clés contenus dans leurs énoncés. Etape 3 : Une liste de mots-clés, représentatifs de notre domaine d’étude, est extraite du graphe de connaissances pour servir de référence au processus de désambiguïsation. Cette étape, où l’assistant récupère des données dans le graphe est simultanée avec l’étape 2. Etape 4 : Les éléments techniques sont ensuite identifiés dans le graphe à partir d’un dictionnaire de termes techniques. L’assistant leur associe alors les labels appropriés et les relie entre eux pour former le sous-contexte technique. Afin de détailler les procédés de désambiguïsation et d’enrichissement sémantique évoqués plus tôt, considérons la règle suivante : It is necessary to have between wall corners a radius a bit higher than the milling cutter radius to avoid an engagement of the tool in the part corner Lors de la première étape, le démonstrateur lit la règle dans le document semi-structuré. Les outils de traitement du langage naturel de Stanford CoreNLP permettent au démonstrateur d’isoler les mots-clés (i.e. noms, verbes, adjectifs et adverbes) de la règle et de les réduire à leur base lexicale, appelée lemme. Ces lemmes sont ajoutés au graphe et reliés à la règle (Figure 37).