Acquisition à partir de textes

Dans cette thèse, nous nous intéressons essentiellement aux trois premiers types d’ou-tils proposés par le MDA (notamment pour le CIM et les passages CIM à CIM et CIM à PIM) sur l’acquisition des règles métier. Cela a fait l’objet de plusieurs travaux de recherche [Bajec and Krisper, 2005,Halle et al., 2006] qui se sont intéressés en particulier au cycle de vie des règles entre le CIM et le PIM. Ce cycle correspond à l’évolution des règles d’un état initial où elles sont incluses dans les documents de spécification (textes réglementaires) du système d’information, à un état final où elles sont automatisées et mise en œuvre dans le SGRM. Les travaux s’interrogent alors sur un certain nombre de points à savoir 1) l’acquisition des règles à partir des textes réglementaires, 2) leur modélisation dans un langage formel afin de faciliter leur automatisation, 3) leur intégration dans le SGRM (stockage, exploitation, maintenance).

Nous nous concentrons essentiellement sur l’acquisition et la modélisation des règles. Au-trement dit sur la question de la prise en compte des documents pour acquérir et modéliser les règles qu’ils contiennent. Cette question, déjà soulevée dans [BRG, 2000,Halle et al., 2006, Dubauskaite and Vasilecas, 2009], pose un problème de transformation de connaissances de l’in-formel au l’in-formel c’est-à-dire de traduction des règles contenues dans des documents rédigés en langage humain en des règles formalisées. Les recherches montrent que ce passage ne peut être effectué de façon automatique, du fait de l’écart entre la complexité de la langue et l’expressivité fournie par les langages formels.

[Dubauskaite and Vasilecas, 2009] inventorie différents éléments qui peuvent intervenir dans le processus d’élicitation tel qu’il est pratiqué : 1) l’identification des règles à partir de dialogues ou de documents et l’écriture de spécifications en langage naturel 2) l’utilisation de langages naturels contrôlés et de patrons de règles pour écrire des spécifications 3) la modélisation graphique des spécifications, par exemple en UML ou OCL 4) leur implantation en code exé-cutable. On retrouve les trois niveau du MDA, mais 1) et 2) constituent une alternative et non des processus parallèles.

II.2.2.1 Identification des règles métier

L’identification consiste à sélectionner les fragments de texte qui expriment les règles dans les textes réglementaires.

Les fragments sélectionnés correspondent très souvent à des phrases. Pour marquer qu’elles ne sont pas encore validées, elles sont appelées dans [Tobon and Franco, 2010], « phrases can-didates de règles métier » (’business rule cancan-didates’ sentences). L’appellation devient « règles candidates » (RC) une fois qu’elles sont validées règles métier. Leur identification est une

Chapitre II. Les règles métier

tâche classiquement allouée aux analystes ou aux experts de règles métier. Ils les filtrent ra-pidement à la main mais cette tâche devient très vite complexe du fait des gros volumes de textes à consulter. Pour assister les experts, des outils de détection automatique sont proposés [Tobon and Franco, 2010]. Ce sont des outils de traitement automatique de la langue (TAL) qui reposent sur des méthodes d’extraction automatique basées sur des analyses syntaxiques et sémantiques de textes. Ces outils tentent de détecter les phrases candidates suivant des caractéristiques linguistiques. [Tobon and Franco, 2010] ont distingué deux approches pour la détection automatique :

l’approche Statistique est très peu utilisée. Elle repose sur des calculs statistiques basés sur la fréquence des mots dans le texte. Il s’agit alors de considérer les mots les plus fréquents jusqu’à un certain seuil et ceux-là sont appelés clés candidates. Des outils TAL sont utilisés pour l’analyse syntaxique et sémantique afin de structurer les textes et supprimer les ambiguïtés et affinités lexicales dans la liste des clés candidates. Ensuite toutes les phrases contenant les clés candidates sont considérées comme phrases candidates et devront être validées par l’analyste métier ;

l’approche linguistique est l’approche la plus utilisée. Elle consiste à repérer les phrases candidates à partir d’un ensemble de patrons linguistiques de règles métier. Un patron est une règle d’extraction ou une expression régulière qui est appliquée sur un texte et qui en extrait tous les fragments textuels vérifiant le patron. Chaque patron (Tableau II.1) est défini à partir des mots clés caractéristiques ou descriptifs de règles métier qui sont proposés par exemple dans SBVR [OMG, 2008], RuleSpeak [Ross, 2009b], mais aussi à partir d’heuristiques grammaticales (HG) portant sur les structures de la langue. Les patrons sont alors appliqués sur les arbres syntaxiques¹⁰ des phrases du texte, obtenus après l’analyse syntaxique du texte. Le résultat est un ensemble de phrases candidates.

Tobon et al. [Tobon and Franco, 2010] proposent un outil de détection automatique de règles métier à partir de textes réglementaires rédigés en langage naturel. Le BRElicita-tionTool utilise l’outil de TAL Stanford Parser pour effectuer l’analyse linguistique des textes. Il utilise aussi l’outil Tregex¹¹ pour appliquer les patrons linguistiques sur l’en-semble des arbres syntaxiques(chacun correspondant à une phrase des textes) résultant de l’analyse syntaxique. Les patrons sont définis sur la base de la structure d’une phrase, de la catégorie syntaxique de chaque mot de la phrase et sur un ensemble de mots clés caractéris-tiques de règles métier. Les mots-clés sont proposés dans SBVR [OMG, 2008], RuleSpeak

10. http ://fr.wikipedia.org/wiki/Arbre_syntaxique 11. The Stanford Natural Language Processing Group

II.2 Acquisition et maintenance des règles métier

each...

SBVR ...at least one...

if p then q ...must...

may...only if

RuleSpeak must be computed as must be considered...if

When + phrase + then/implies + phrase HG Subject + will + verbal phrase

If + phrase + then/implies + phrase

Tableau II.1 –Patrons linguistiques basés sur des mots-clés et des heuristiques grammaticales.

[Ross, 2009b]. Tregex applique alors un patron du genre ”NP...can...only...VB...if...NP”

et extrait toute les phrases comme celle dont l’arbre syntaxique est représenté dans la figure.

Figure II.4– Un exemple d’arbre syntaxique de phrase relatant une règle métier.

BRElicitationTool [Tobon and Franco, 2010] a été appliqué sur un exemple de texte régle-mentaire qui a aussi été analysé par des étudiants et professeurs, qui ne sont pas forcément des analystes métier, et qui ont détecté manuellement les règles métier candidates sur la base des mots clés SBVR et RuleSpeak¹². Dans cette expérience, les règles candidates détectées manuellement avaient un rappel de 28,42% et une précision 68,44%. Ce résultat est de loin moins bon que celui de l’outil qui fournit un rappel de 72,97% et 71,05% de précision. Ces résultats ne sont pas forcément interprétables sur tous les types de textes règlementaires mais ils montrent la valeur ajoutée de la détection automatique.

Toutefois, suivant la complexité et le caractère ambigu de la langue cette méthode né-cessite une intervention humaine (souvent celle de l’analyste) pour valider si une règle

12. Le fragment de texte est un extrait des documents réglementaires du projet "The SHARING Project" qui vise à développer un système d’information traitant des prêts hypothécaires d’une organisation, ING, basée aux Pays-Bas.

Chapitre II. Les règles métier

candidate extraite est une règle métier ou pas. L’identification aboutit à un ensemble de règles candidates valides.

II.2.2.2 Formalisation des règles métier

La formalisation a fait l’objet de plusieurs travaux [Lovrencic et al., 2006,Braye et al., 2006].

Elle est une étape intermédiaire dans l’automatisation des règles afin de faciliter leur passage du langage humain à leur forme implémentée.

Concrètement, la formalisation des règles [Aidas and Olegas, 2009] consiste en leur traduc-tion dans des langages formels (LF) ou dans des modèles conceptuels. Parmi ces derniers on peut citer les modèles entités-associations (BIER (Behaviour Integrated Entity-Relationship) [Eder et al., 1986]), les modèles orientés objets [Lukichev and Jarrar, 2009] (UML¹³(Unified Modeling Language), OCL¹⁴ (Object Constraint Language), ORM¹⁵ (Object Role Modeling)) et les langages formels définis pour le Web et le Web sémantique (OWL, SWRL, RuleML, RIF, F-logic, etc) [Cisternino et al., 2009].

Toutefois, lorsque les règles existent initialement en langue naturelle, leur traduction formelle ne peut se réaliser de façon directe du fait de l’écart. Nous nous sommes intéressé à cette problématique du passage du langage naturel au langage formel dans la littérature. Selon les travaux de Bajec et Krisper dans [Bajec and Krisper, 2005], la traduction formelle des règles fait intervenir deux types d’acteurs, l’expert métier et l’ingénieur système. L’expert est du domaine et il est chargé de spécifier les besoins de l’entreprise sous formes de règles métier.

L’expert rédige ces règles sous forme textuelle en langue naturelle. Et ensuite, les règles sont formalisées avant d’être implémentées en code machine par l’ingénieur afin de permettre leur automatisation dans les SGRM. L’analyse de Bajec et Krisper fusionne donc les rôles d’ingénieur de la connaissance et d’ingénieur système.

Ces travaux ont aussi montré que le passage des règles du langage naturel au langage formel est complexe et qu’il n’est pas automatique, ce qui a des conséquences dans le suivi et la maintenance des règles :

– le manque d’expertise du domaine métier et la complexité de la langue naturelle rendent l’écriture formelle des règles très difficile pour l’ingénieur. La manipulation des textes nécessite une certaine connaissance du domaine ; leur variabilité syntaxique et le caractère informel de leur sémantique complique la formalisation et encore plus l’automatisation de celle-ci ;

13. http ://www.uml.org

14. http ://www.omg.org/cgi-bin/doc ?formal/2006-05-01/

15. http ://fr.wikipedia.org/wiki/Mapping_objet-relationnel

II.2 Acquisition et maintenance des règles métier

– les experts qui rédigent ces règles sont très fidèles aux besoins de l’entreprise et ne prennent souvent pas en compte leur utilisation par le SGRM. Cela pose problème à l’ingénieur qui peut difficilement concilier les règles fournies par l’expert et la mise en œuvre des règles au niveau système ;

– une fois formalisées, les règles sont écrites dans un langage formel de règles métier. Dès lors, elles deviennent incompréhensibles par l’expert qui éprouve à son tour des difficultés pour les valider, les expliquer, vérifier leur conformité avec ses règles ou pour les modifier quand les besoins de l’entreprise évoluent.

Les langages contrôles ont été proposés [BRG, 2000, Halle et al., 2006],

[Dubauskaite and Vasilecas, 2009] comme une solution à mi-chemin entre langage naturel et langage formel, surtout pour améliorer la collaboration entre les experts et les ingénieurs. Un langage contrôlé [Schwitter, 2005] restreint la grammaire et le vocabulaire utilisés par la langue naturelle afin de réduire son caractère ambigu et complexe. Il est surtout connu pour améliorer la lisibilité du langage naturel en fournissant une version simplifiée et facilement compréhensible de celui-ci. Le langage contrôle offre des structures linguistiques qui permettent d’écrire les règles sous une forme syntaxiquement structurée, précise au niveau lexical et non ambiguë dans son ensemble.