PARAPHRASER pour VALIDER

Paraphraser pour valider, tel peut être résumée l'activité de recherche qui nous occupe. Vous trouverez ci-après quelques explications complémentaires. Si vous n'avez pas le temps de les lire, en voici sous forme graphique :

Supposez que vous soyez un utilisateur et que vous ayiez dépensé 100K euros pour étudier la mise en place d'un nouveau système logiciel. L'analyste a terminé son travail et vous remet un épais dossier composé de textes et de schémas. Que faites-vous ?

Si vous choisissez la première solution, ne venez pas vous plaindre après que le logiciel ne corresponde pas à ce que vous vouliez.

Si, par contre, vous voulez "voir", il vous faut pouvoir comprendre des schémas qui peuvent ressembler à çà :

ou à ça :

C'est bien cela que vous vouliez, non ?

NB : Si vous n'y comprenez rien, cliquez sur n'importe quel point du schéma. Un texte apparaîtra, que vous n'aurez aucun mal à interprêter.

PARAPHRASER une spécification, c'est passer d'un schéma à un texte. Vous pouvez partir tranquille. Vous en savez suffisamment, compte-tenu du temps dont vous disposez. Vous voulez-en lire davantage ? Choisissez un des mots-clés ci-dessous.

MOTS-CLES : Génie logiciel, Spécifications, Paraphrasage, Validation

Validation

Un logiciel passe par plusieurs étapes, depuis le moment où il apparaît sous forme d'un besoin jusqu'à celui où il est installé, comme produit, chez l'utilisateur. Ce cheminement du besoin au produit correspond à ce qu'on appelle le cycle de vie du logiciel. Il en existe plusieurs perceptions. Modèle de la cascade, cycles en V, en W, en spirale, ... , les propositions sont nombreuses. Voir, par exemple, le chapitre consacré à ce sujet dans l'ouvrage de J. MOREJON et J.R. RAMES [22] ou bien le chapitre 2,Contrôle et Test dans un projet logiciel, pp. 29 à 44, du livre collectif sur les Test et Contrôle des logiciels [23]. Tous ces modèles, à un instant ou à un autre, intègrent l'étape de validation :

Le travail entrepris prend place dans la couche haute de ces cycles et se préoccupe d'acquisition (une partie du travail de spécification, que celui-ci s'appelle Définition des besoins ou Rédaction du cahier des charges) et de validation.

Voici comment B.W. BOEHM [24] définit la validation et la distingue de la vérification :

Verification and Validation in the software life cycle

Definitions. The recent IEEE Standard Glossary of Software Engineering Terminology (voir [25]) defines "verifiaction" and "validation" as follows:

Verification: The process of determining wheter or not the products of a given phase of the software development cycle fulfill the requirements established during the previous phase.

Validation: The process of evaluating software at the end of the software.

Informally, we might define these termes via the following questions:

Verification: Am I building the product right?

Validation: Am I building the right product?

Ces deux dernières questions peuvent être traduites en :

Vérification : Suis-je en train de construire correctement le produit ?

Validation : Suis-je en train de construire le bon produit ? (voir note 16)

Traditionnellement, durant les premières étapes du cycle de vie d'un logiciel, deux catégories de personnes collaborent : l'utilisateur final et l'analyste-spécifieur. Le second doit assimiler une partie des connaissances du premier pour en bâtir une réplique informatique.

Cette réplique devra, pour ce qui concerne le problème à traiter, se "comporter comme" l'utilisateur. Dans la plupart des cas, cependant, la réplication n'est pas totale. L'utilisateur final garde le contrôle d'un outil qui possède, par certains côtés, des caractéristiques qui en font une copie de lui-même. La situation la plus courante est celle dans laquelle l'outil prend en charge le cas général, tous les cas particuliers restant du ressort de l'utilisateur. A l'outil la routine, à l'utilisateur les exceptions, en quelque sorte.

Pour assimiler ces connaissances, l'analyste-spécifieur procède par interview, collecte de documents - la phase de prospection, d'enquête - puis par synthèse, modélisation - la phase de rédaction, de formalisation -. Les données sur lesquelles il travaille sont composées de textes (écrits dans une langue plus ou moins naturelle, oraux dans le cas d'interviews enregistrés) et de schémas (des documents manipulés par l'utilisateur - tels que des bons de commande, des factures, ... - ou des croquis faits par l'utilisateur ou par l'analyste-spécifieur).

Il doit les synthétiser, en extraire des modèles (une description, formalisée dans un certain langage, de ce qu'il a perçu) et une connaissance personnelle du fonctionnement de ce qu'il a étudié. Ces schémas achevés, il doit se retourner vers l'utilisateur et lui demander s'il n'a pas fait d'erreurs d'interprétation. Pour cela, il peut mettre en oeuvre plusieurs techniques. Il peut, par exemple, construire un prototype. L'utilisateur jugera de la validité de la réplique en observant le comportement du prototype. Il peut aussi procéder par preuves de propriétés à partir de la spécification. Il peut aussi procéder par tests. L'utilisateur lui fournit un ensemble de données réelles, un jeu d'essai, et les résultats attendus. Si ces données sont correctement traitées, la réplique sera estimée correcte.

Il peut, enfin, paraphraser le modèle qu'il a construit. Cette technique consiste à récrire d'une autre façon ce qu'il a déjà écrit. Elle repose sur l'hypothèse que le modèle récrit est plus intelligible que le modèle original. L'utilisateur lit le texte produit, l'interprête et valide (ou non) la spécification au vu du texte.

A notre avis, le paraphrasage n'a de sens que si ce n'est pas l'analyste qui s'en charge. Nous croyons, en effet, que s'il a commis une erreur d'interprétation en passant du monde réel à son modèle, il risque de commettre l'erreur exactement symétrique en effectuant la démarche inverse et ainsi faire disparaître toute trace de sa "faute".

Un paraphrasage automatique nous paraît infiniment plus sûr, sur ce plan-là. C'est toutefois une technique assez délicate à mettre en oeuvre, du fait de la langue naturelle. Le médium de communication privilégié de l'utilisateur, c'est avant tout sa propre langue maternelle. Le paraphraseur automatique se doit donc de produire des phrases les plus naturelles possible. Ce n'est pas aussi simple qu'il y paraît.

Paraphrasage

Paraphraser, c'est "exprimer sous une autre forme, en amplifiant, mais sans rien ajouter au sens ;" c'est "traduire en amplifiant". Paraphraser, c'est passer d'un schéma Niam (par exemple) à un texte. Le résultat, même s'il présente quelques défauts, est plus lisible que le graphisme. Pour nous, l'adage "un dessin vaut mieux qu'un long discours" est faux. L'utilisateur ne sait pas bien lire le dessin.

Il existe plusieurs équipes qui travaillent dans le domaine du paraphrasage de spécifications. Citons C. ROLLAND, avec le système OICSI [29], E. METAIS et son système KHEOPS [30] en France ou, à l'étranger, H. DALIANIS [31] (Université de Stockolm, Suède), T. HALPIN [32] (Université du Queensland, Australie) ou bien encore C.F. DERKSTEN, T.P. VAN DER HEIDE [33] (Université de Nimègue, Hollande).

D'une façon générale, elles adoptent une démarche en deux ou trois passes, pour produire, à partir d'une spécification, un texte plus ou moins naturel. Prenons, pour illustrer notre présentation, un exemple de spécification. Il s'agit d'une modélisation "à la Merise" d'un cas de commande-facturation.

Nous supposons (peut-être à tort) que le lecteur est à même de lire un tel schéma et ne le commenterons pas davantage, sauf pour signaler que nous sommes conscients du fait qu'il présente une légère erreur. Le couple de cardinalités liant Commande et Produit étant de (1, 1) - nous avons donc une fonction de commande vers produit -, l'attribut Qté_cdée devrait migrer dans Commande. Nous assumons cette erreur ; elle a en effet l'avantage de nous permettre d'illustrer le traitement que nous faisons subir à une association n-aire porteuse d'informations. Un coup d'oeil sur le résultat du paraphrasage (cf infra) permettra de le comprendre aisément, si besoin est.

La première étape consiste à extraire de la spécification ce qui est appelé sa structure profonde (voir note 17). Dans le cas d'un schéma entités-associations-propriétés, celle-ci sera composée d'entités, d'attributs, d'associations, de cardinalités, ... On isole, durant cette phase, les concepts essentiels en faisant abstraction de la notation. Il est à noter que, dans bien des systèmes, cette extraction est inutile, la structure profonde ayant été créée directement durant la phase d'acquisition des connaissances.

Différents formalismes sont employés pour décrire cette structure profonde, les plus employés semblant être les graphes conceptuels [34] ou les réseaux sémantiques [35] :

Ce réseau comprend trois noeuds-entités (CLIENT, COMMANDE et PRODUIT), un noeud-association non porteur d'informations (passe) et un noeud-association porteur (contient). Il peut être décrit de la façon suivante :

(ENTITE, CLIENT, N° Client, (Nom))
(ENTITE, COMMANDE, N° Commande, (Date))
(ENTITE, PRODUIT, N° Produit, (Libellé, Qté_en_stock))
(ASSOCIATION_N, passe, CLIENT, (0, n), ((COMMANDE, (1, 1)))) (voir note 18)
(ASSOCIATION_P, contient, COMMANDE, (1, n), ((PRODUIT, (0, n))), (Qté_cdée))

Tel qu'il est, ce réseau ne permet pas de produire un texte de qualité. Il doit être enrichi d'informations linguistiques (comme le genre des mots, leur pluriel, ...) et opératoires (comme le sens de lecture des associations). Regardons ce que cela donne sur la partie du réseau qui corrrespond à l'association passe :

On peut distinguer le noeud-association des noeuds-entités grâce à l'absence de liaison d'identification (Id.). Pour le traduire, on a deux solutions. Soit on produit une phrase du genre " --- CLIENT est lié à --- COMMANDE par passe " (la phrase inverse est facile à obtenir : " --- COMMANDE est liée à --- CLIENT par passe "), soit on essaye d'améliorer la naturalité du texte et on envisage " --- CLIENT passe --- COMMANDE " et " --- COMMANDE est passée par --- CLIENT ". La production de telles phrases nécessite de connaître le sens de lecture (de CLIENT vers COMMANDE), la forme inverse de passe (est passée par) et le genre des mots CLIENT et COMMANDE (notamment pour exprimer les ---).

Ces informations seront saisies avec les autres ou bien recherchées dans un dictionnaire associé. Ce dernier correspond en partie à ce qu'E. METAIS, dans KHEOPS, appelle des connaissances linguistiques générales. Un tel outil dispense l'utilisateur de saisie complémentaire. Il risque, toutefois, par son ampleur de freiner un peu la production du texte.

La forme utile du réseau sémantique doit donc être la suivante :

La deuxième étape consiste à mettre en évidence les structures de surface. Celles-ci correspondent aux éléments de phrases à produire. Sujets, verbes, compléments, éléments linguistiques exprimant les cardinalités sont les composants essentiels de ces structures. Le passage des structures profondes à des structures de surface se fait par application de règles de transformation.

Grâce à la règle suivante :

Si (ENTITE, A, B, (C, D, ... , F)) alors finsi

on peut passer de la description (ENTITE, CLIENT, N° Client, (Nom)) aux deux ci-après :

(ENTITE,"Tout", CLIENT, "a", (Nom))
(ENTITE, "Tout", CLIENT, "est identifié(e) par", N° Client)

que l'on peut (par application de la règle précédente et d'autres non décrites ici) complèter par :

(ENTITE, "Tout", COMMANDE, "a", (Date))
(ENTITE, "Tout", PRODUIT, "a", (Libellé, Qté_en_stock))
(ENTITE , "Tout", COMMANDE, "est identifié(e) par", N° Commande)
(ENTITE, "Tout", PRODUIT, "est identifié(e) par", N° Produit)
(ASSOCIATION_P, "Tout", COMMANDE, contient, "un ou plusieurs", PRODUIT)
(ASSOCIATION_P, "L'ensemble", (N° Commande, N° Produit), "détermine de façon unique", Qté_cdée)

pour obtenir l'ensemble des structures de surface correspondant à l'exemple.

La dernière étape est celle de la linéarisation. Il s'agit de construire les phrases, à partir des ingrédients de base contenus dans les structures de surface. Expression des verbes dans le bon temps, accords en genre et en nombre, ellipses, regroupement de phrases, ... tous ces traitements sont dans la plupart des cas réalisés. C'est la partie linguistique du paraphrasage, qui vise à produire un texte comme celui-ci :

Tout CLIENT a un Nom et est identifié par N° Client. Toute COMMANDE a une Date et est identifiée par N° Commande. Tout PRODUIT a un Libellé et une Qté_en_stock. Tout PRODUIT est identifié par N° Produit. Toute COMMANDE contient un ou plusieurs PRODUIT(s). L'ensemble (N° Commande, N° Produit) détermine de façon unique Qté_cdée.