<?xml version="1.0" standalone="yes"?>
<Paper uid="P98-1073">
  <Title>Vers l'utilisation des m thodes formelles pour le d veloppement de linguiciels</Title>
  <Section position="3" start_page="438" end_page="441" type="intro">
    <SectionTitle>
1 Introduction
</SectionTitle>
    <Paragraph position="0"> L'automatisation des langues naturelles a bdnkficik jusqu'k nos jours de nombreuses anndes de recherches et continue encore faire l'objet de plusieurs travaux, notamment dans le domaine du gknie linguistique pour le dkveloppement d'applications spkcifiques.</Paragraph>
    <Paragraph position="1"> L'ktude des approches de dkveloppement des applications likes au Traitement Automatique des Langues Naturelles (TALN), k tous ses niveaux (i.e., lexical, morphologique, syntaxique, skmantique et pragmatique), (Fuchs, 1993; Sabah, 1989) nous a permis de constater une quasi-absence de l'utilisation de mdthodologies de dkveloppement qui inthgrent toutes les phases du cycle de vie d'un logiciel. En particulier, au niveau des premihres dtapes, nous avons constatk l'absence quasi-totale de la phase de spkcification formelle.</Paragraph>
    <Paragraph position="2"> D'un autre c5t4, nous avons constatd une difficultk, voire absence de validation formelle des approches utilisdes dans le dkveloppement et par consdquent de garantie sur les performances des rksultats obtenus. De m~me, nous avons remarqu6 le non recours PS des mdthodes rigoureuses d'intkgration pour rksoudre le problhme de la dichotomie donn6es-traitements.</Paragraph>
    <Paragraph position="3"> L'utilisation des outils formels s'est limitke, dans la plupart des cas, k la description du langage (i.e., les grammaires) et k la spdcification des traitements r~duite, g@nkralement, k l'usage d'un langage algorithmique. Rares sont ceux qui ont utilisk un langage de spkcification formelle de haut niveau (Zajac, 1986; Jensen et al., 1993).</Paragraph>
    <Paragraph position="4"> Aprhs une prksentation des avantages qu'offrent les mkthodes formelles dans le processus de dkveloppement d'un logiciel, d'une manihre gknkrale, cet article essaye de mettre en relief les avantages specifiques au domaine de TALN partant d'une expkrience mende au sein de notre kquipe en utilisant la mkthode VDM (Dawes, 1991; Jones, 1986). I1 donne, ~ la fin, des crithres permettant le choix d'une mkthode formelle approprike.</Paragraph>
    <Paragraph position="5"> 2 Rappel des principaux avantages des mdthodes formelles L'int@gration des mkthodes formelles dans le processus de dkveloppement de certaines applications critiques comme les systhmes temps rdel et les systhmes distribu'ks a donnk ses preuves ces dernihres annkes (Barroca and Dermid, 1992; Dick and Woods, 1997; Ledru, 1993). C'est ce qui a motivk leur utilisation dans le ddveloppement de logiciels traitant des problhmes complexes au niveau industriel (Hui et al., 1997).</Paragraph>
    <Paragraph position="6"> Une mkthode formelle est considkrke comme une ddmarche de dkveloppement de logiciels baske sur des notations mathdmatiques et des preuves de validation formelles (Habrias, 1995). Cette dkmarche utilise un processus de raiTinement qui part d'une spkcification abstraite des besoins pour dkboucher sur une spkcification raffinke et exkcutable (ou directement codable en un langage de programmation). Les principaux avantages des mkthodes formelles peuvent ~tre rksumks dans les points suivants : La prdcision et la non ambiguitd : l'utilisation d'un langage bask sur des notations formelles et prkcises permet d'kviter toute ambiguitk et toute redondance dans la spkcification.</Paragraph>
    <Paragraph position="7"> La ddteetion d'erreurs conceptueUes le plus tSt possible : l'application de preuves de validation de la spkcification tout le long du processus de raffinement de cette dernihre, garanti la ddtection des erreurs de conception le plus tSt possible dans le processus de dkveloppement de l'application. En l'absence d'une telle validation, les erreurs de conception ne seront  d~tect4es qu'aprhs la phase d'impl4mentation ce qui engendrera un c6ut suppl~mentaire.</Paragraph>
    <Paragraph position="8"> La satisfaction de la conception (dventuellement de l'impldmentation ) par rapport aux besoins : elle est garantie grPSce au processus de raffinement qui part d'une sp4cification des besoins et applique des rhgles coh~rentes de transformation pour aboutir ~ la conception finale.</Paragraph>
    <Paragraph position="9"> Le contrble de la cohdrence donndestraitements : qui est directement pris en charge grPSce aux preuves de validation.</Paragraph>
    <Paragraph position="10"> La rdutilisation : le raffinement des specifications formelles et leurs d~compositions successives permettent de mettre en ~vidence des niveaux d'abstraction int~ressants pour la r~solution du probl~me et pour promouvoir la r~utilisation (des sp4cifications).</Paragraph>
    <Section position="1" start_page="439" end_page="439" type="sub_section">
      <SectionTitle>
3.1 Choix et d~marche utilis4e
</SectionTitle>
      <Paragraph position="0"> Pour mesurer l'impact de l'utilisation des m~thodes formelles dans le contexte du TALN, nous avons effectu~ la specification complhte et valid~e du systhme CORTEXA (Correction ORthographique des TEXtes Arabes) (Ben-Hamadou, 1993) d~velopp~ au sein de notre laboratoire. null Outre la disponibilit~ de la documentation, en mati~re de conception et d'impl~mentation, le choix du syst~me CORTEXA est aussi motiv~ par la diversit~ des approches utilis~es pour la representation des connaissances et des traitements. En effet, il se compose : * d'un module de d~tection des erreurs bas~ sur une analyse affixale qui utilise un systhme ~ 4tats finis (les r~seaux de transitions augment~es : ATN). L'analyse affixale effectue la d~composition d'un mot en ses composants premiers : pr~fixe, infixe, suffixe et racine en se r~f~rant PS un ensemble de lexiques et de structures de donn~es, * d'un module de correction des erreurs orthographiques qui utilise un systhme ~ base de rhgles et * d'un autre module de correction des erreurs typographiques qui se base sur un systbme mixte.</Paragraph>
      <Paragraph position="1"> Le choix de VDM pour la specification de CORTEXA est motive, d'une part, par le fait que cette m~thode se base sur les pr~dicats qui donnent un haut pouvoir expressif, et d'autre part, pour sa notation simple et riche. Aussi, VDM a fait ses preuves dans le d~veloppement de plusieurs systhmes d'information. Contrairement aux environnements de specification des donn~es linguistiques tels que D-PATR (Karttunen, 1986), EAGLES (Erbach et al., 1996), etc, VDM permet de specifier PS la fois des traitements et des donn~es (dans notre contexte des donn~es linguistiques) et offre une m~thodologie de d~veloppement d'applications se basant sur des raffinements et des transformations valid~es. Partant de la description informelle des besoins, nous avons d6velopp~ la spficification abstraite du systbme CORTEXA (appelfie aussi spgcification implicite) qui englobe, entre autres, la spficification formelle de ses fonctions, de ses actions et de ses rbgles de correction. Cette sp~cification a fit6, ensuite, validfie en utilisant des preuves formelles. Enfin, nous avons g~n~ralis~ la sp~cification de conception (appel~e aussi spficification explicite ou directe) partir de la sp~cification abstraite moyennant des rbgles relatives PS la m6thode VDM. Cette sp4cification de conception est facilemerit transform6e en code pour rfialiser la phase d'implfimentation.</Paragraph>
    </Section>
    <Section position="2" start_page="439" end_page="441" type="sub_section">
      <SectionTitle>
3.2 R~sultats obtenus
</SectionTitle>
      <Paragraph position="0"> L'utilisation de la m~thode formelle VDM pour la sp6cification complbte et valid~e du systbme CORTEXA a conduit, entre autres, aux constats suivants : InsuJfisance en r~gles : l'utilisation des preuves formelles nous a permis de mettre en relief, par rapport ~ \[a specification initiale, certaines situations non prises en compte. En particulier, les preuves qui permettent de s'assurer que pour chaque type d'erreur dolt exister au moins une rhgle de correction nous ont permis de constater que l'ensemble des rbgles de correction, initialement propos~, ne permet pas de prendre en charge toute la typologie d'erreurs.</Paragraph>
      <Paragraph position="1"> Exemple 1: preuve relative PS l'erreur de sup- null spdcification : en comparant la specification informelle du systhme CORTEXA, pr~sent~e dans la documentation, avec la specification formelle d~velopp~e, nous remarquons que eette dernihre est plus precise et plus concise. L'exemple 2, donn~ ci-aprhs, qui pr~sente la specification formelle de la fonction de g~n~ration des d~compositions affixales possibles d'un mot w, illustre ce constat.</Paragraph>
      <Paragraph position="3"> propri~t~ d'un infixe (respectivementd'un pr~fixe et d'un suffixe) pour une chaine.</Paragraph>
      <Paragraph position="4"> Facilitd du ddveloppement du code : la specification de conception obtenue est suffisamment explicite pour les donn~es et algorithmique pour les traitements. Elle est donc facilement codable en un langage de programmation.</Paragraph>
      <Paragraph position="5"> L'exemple 3, illustre l'usage d'une notation algorithmique dans la sp6cification des fonctions.</Paragraph>
      <Paragraph position="6"> Il pr~sente la fonction S-Radical de v~rification de la propri~t~ d'un radical (form6 par la racine et l'infixe).</Paragraph>
      <Paragraph position="7">  riO: une fonction VDM qui retournela s~quence en entree priv~e de sa t~te.</Paragraph>
      <Paragraph position="8"> Unicitd de la notation : les m~thodes formelles permettent d'utiliser la m~me notation pour d~crire aussi bien les donn~es que les traitements. En effet, avec le langage VDM-SL, associ~ k VDM, nous avons pu specifier toutes les fonctions et les donn~es de r~f~rence de COR-TEXA. Les exemples 4 et 5 illustrent cette unicit~ pour la representation des donn~es composdes et des fonctions.</Paragraph>
      <Paragraph position="9"> Exemple 4 : l'enregistrement relatif aux donn~es d'une d~composition d'un mot en un pr~fixe, un infixe, un suffixe et une racine.</Paragraph>
      <Paragraph position="10">  la notation, a permis d'appliquer des preuves formelles k la lois sur des donn~es et des traitements et par consequent de contr61er la coherence de ces derniers. L'exemple 1 illustre ce contr61e dans le cas d'un systhme ~ base de rhgles.</Paragraph>
      <Paragraph position="11">  La validation de chaque composant du syst~me : pour chaque composant ou module du systbme CORTEXA, nous avons appliqu6 les preuves de validation appropri6es, ce qui nous a permis de valider tousles r6sultats partiels du systbme. Le th6orbme de l'exemple 6, donn6 ci-aprbs, permet de prouver qu'PS la suite de l'application de la rbgle de correction d'une erreur de substitution, les propositions de correction obtenues appartiennent au lexique.  limit~e dans le temps (elle a dur~ une annie environ) et dans son contexte (elle s'est int6ress6 un seul systhme et non k plusieurs), elle nous a permis d'appr@cier PS juste titre l'int@r6t de recourir aux m6thodes formelles dans le processus de d6veloppement des applications li6es au TALN. Elle nous a aussi permis de d6gager certains avantages globaux d6di6s au domaine du TALN qui viennent consolider ceux que nous avons d4jPS cit6s dans un cadre g6n6ral de d6veloppement des Iogiciels. Ces avantages sp6cifiques peuvent ~tre r@sum6s et argument6s dans les points qui suivent.</Paragraph>
      <Paragraph position="12"> D'abord, au niveau de la specification des besoins, les applications du TALN sont g6n6ralement trhs ambitieuses au d6part. Or on connait aujourd'hui les limites des modbles linguistiques et des outils de repr6sentation des connaissances. L'utilisation d'outils formels dans les premibres 6tapes de d6veloppement (i.e., analyse) permet de mettre trbs vite en 6vidence les limites du systbme k d6velopper, en particulier, sur le plan de la couverture linguistique et par cons6quent de partir pour l'6tape de conception sur une version valid6e du systbme qui sera impl@ment6 et de pr4voir d'embl6 les possibilit6s d'extention et de r6utilisation.</Paragraph>
      <Paragraph position="13"> Par ailleurs, la complexit6 des traitements li6s au langage naturel et la diversit6 des donn6es linguistiques et des fortes int6ractions qui existent entre donn@es et traitements rendent la t~che de conception trbs difficile et pouvant engendrer des problbmes d'incoh6rence. L'utilisation des m6thodes formelles au niveau de la conception permet d'abord, de g6rer la dichotomie donn6es-traitements soit par l'int6gration (i.e., en utilisation l'approche objet), soit par le contrSle de coh6rence (i.e., par des preuves de validation) et ensuite de mettre en 6vidence, par des regroupements et des raffinements successifs, des abstractions int6ressantes r6utilisables telsque des modules ou des sous-systbmes pouvant ~tre disponibles dans une bibliothbque (Darricau et al., 1997).</Paragraph>
      <Paragraph position="14"> Ces abstractions correspondent par exemple des modules standards du TALN traitant le niveau phon6tique, morphologique, syntaxique, etc. Notons PS ce propos que, la r6utilisation de sp6cifications (i.e., de conception) peut se faire directement ou moyennant des adaptations. Les m6thodes formelles offrent des environnements qui facilitent ces adaptations (6diteurs,..) et qui permettent la validation des nouvelles sp6cifications.</Paragraph>
      <Paragraph position="15"> Enfin, l'utilisation d'une notation uniforme donne la possibilit6 d'int6grer dans la m@me application une vari6t@ de connaissances sur la langue sp6cifi@es avec des formalismes diff6rents (i.e., grammaires d'unification, HPSG, Grammaires Formelles, etc). Ce qui permettera d'avoir une meilleure coh6rence dans la sp6cification finale k produire.</Paragraph>
    </Section>
  </Section>
class="xml-element"></Paper>