Brevet FR2882837A1 — publié le 20060908

PROCEDE ET DISPOSITIF DE CONSTRUCTION D'UN DIALOGUE VOCAL La présente invention concerne le domaine des dialogues pour les applications vocales, encore appelés dialogues vocaux. Un telle application vocale est par exemple un service rendu à l'usager d'un terminal téléphonique, dans lequel le service communique avec l'usager en diffusant des messages vocaux, pré-enregistrés ou élaborés par synthèse vocale. L'usager communique à l'aide des touches du terminal, par exemple les touches DTMF ( dual tone multifrequency ) et/ou par l'intermédiaire de commandes vocales comprenant des mots-clefs reconnus par un moteur de reconnaissance vocale. L'ensemble des interactions possibles entre l'usager et l'application constitue le dialogue vocal, qui est lui-même fréquemment décomposé en sous-dialogues (parmi les sous-dialogues classiques, on trouve le sous-dialogue de saisie de numéro, le sousdialogue d'accueil...). La construction d'une application vocale comprend généralement l'élaboration d'une spécification fonctionnelle du dialogue vocal. La spécification décrit d'une part les enchaînements des interactions usager/service (la logique de dialogue), et d'autre part les éléments manipulés lors de ces interactions: événements déclencheurs tels que les mots-clés significatifs dans le dialogue, messages vocaux diffusés par l'application, données manipulées, invocations de services externes (par exemple. connexion à un système d'information). Aujourd'hui, notamment avec l'arrivée de nouveaux standards comme VoiceXML, les dialogues vocaux deviennent de plus en plus complexes, ce qui engendre un accroissement des besoins de validation de ces dialogues. Il existe aujourd'hui plusieurs outils de construction de services vocaux, par exemple Audium Builder de Audium Corporation, VoiceObjects Factory, Microsoft Speech Application Software Development Kit (SASDK) ou Voice Toolkit 5.0 d'IBM. Ces outils présentent l'inconvénient que la technique employée pour la spécification et celle adoptée pour l'implémentation ne sont pas indépendantes. Ce sont en fait des chaînes complètes de développement, allant de l'atelier logiciel de conception jusqu'à la plate-forme d'exécution du service final. Par exemple, l'atelier VoiceObjects Factory est totalement dépendant du moteur d'exécution VoiceObjects Server. SASDK permet de valider le comportement de l'application avant son déploiement à travers un mode de débogage (en anglais debug ) qui travaille directement sur le code de l'application: l'étude du comportement dépend donc de l'implémentation du système. Or il est souhaitable que certaines étapes de validation, notamment la validation de la spécification fonctionnelle au moins, puissent être appréhendées indépendamment des solutions techniques d'implémentation finalement retenues pour offrir ces fonctionnalités. En effet, les services de télécommunication étant des systèmes à cycle de vie assez long, une spécification devrait idéalement être une source d'étude générique, indépendante des implémentations, de sorte que les validations et tests obtenus à partir de la spécification soient applicables sur plusieurs implémentations de la spécification. L'approche CRESS, de Bellcore, est également utilisée dans l'art antérieur. Elle propose une transformation de la spécification initiale dans un langage de modélisation formelle comme SDL ou LOTOS, dans le but d'appliquer des techniques d'analyse éprouvées sur ces formalismes. Toutefois, l'approche CRESS reste très dépendante des possibilités du formalisme proposé. Le formalisme CHISEL par exemple, initialement conçu pour la description de systèmes de télécommunication ne permet pas la description de fonctionnalités spécifiques aux dialogues vocaux (par exemple la création de dialogue, c'est-à-dire l'expression de comportements dont l'existence est dynamique dans le temps). La présente invention vise à proposer une solution pour construire un dialogue vocal de telle sorte qu'une étape de validation pourra être mise en oeuvre indépendamment de la technologie retenue pour l'implémentation finale du dialogue vocal. A cet effet, suivant un premier aspect, l'invention propose un procédé de construction d'un dialogue vocal comprenant les étapes suivantes: on définit dans le dialogue vocal une pluralité de sous-dialogues; on détermine des enchaînements entre certains au moins desdits sousdialogues; et - on élabore une spécification du dialogue vocal en transformant au moins lesdits sous-dialogues et enchaînements en éléments d'un modèle formel de bas-niveau. On nomme modèle formel, un modèle entièrement défini à partir de théories mathématiques éprouvées (cf. Introduction aux méthodes formelles , de JF Monin, éditions Hermes, Collection Technique et Scientifique des Télécommunications), c'est-à-dire construit selon un ensemble de règles dont le formalisme varie suivant la nature des modèles (règles logiques, structurelles, de réécritures, de déductions...) et associant à un élément de définition ou d'action d'un modèle un élément correspondant de la théorie mathématique. Les théories mathématiques usuelles servant de fondement aux modèles formels sont par exemple la théorie des ensembles, la logique de Hoare, les théories de spécifications algébriques, les systèmes de transitions (ou LTS pour Labelled Transition System ), la théorie des systèmes de déduction. Les modèles IF, pi-calcul, UNITY et CCS comptent parmi les modèles formels définis à partir de la théorie mathématique des systèmes de transitions. A l'opposé, le langage UML ( Unified Modeling Language ) n'est pas un modèle formel, mais un formalisme de description dont la plupart des constructions n'ont pas de fondement mathématique. On nomme modèle formel de bas niveau un modèle formel dont toutes les constructions sont décrites directement par des constructions du formalisme mathématique servant de fondement. Par exemple, IF est un modèle formel de bas niveau basé sur la théorie des systèmes de transitions. Prolog est un modèle formel de bas niveau basé sur la théorie des systèmes de déduction. Par opposition, on nomme modèle formel de haut niveau un modèle formel dont les constructions de base reposent sur des théories mathématiques, mais qui propose, en plus, plusieurs constructions de haut niveau fondées par association de constructions basiques se rapportant à des fondements mathématiques respectifs différents. Les règles d'association sont par exemple du type Héritage, Polymorphysme, etc. SDL est un exemple de modèle formel de haut niveau. Le choix d'un modèle de bas niveau pour la représentation de la spécification d'un dialogue permet d'obtenir une représentation canonique de la spécification, indépendante des choix finalement retenus pour la spécification. A partir d'une telle spécification vont donc pouvoir être directement mises en oeuvre des étapes de validation du dialogue, par exemple des étapes de simulation et/ou de tests de conformité qui ne sont donc pas dépendantes de l'implémentation. Dans un mode de mise en oeuvre de l'invention, le modèle formel de bas niveau est un modèle de système de transitions à entrée/sortie, encore appelé IOLTS ( Input Output Labelled Transition System en anglais). Ce modèle est une extension des LTS dans lequel on distingue trois types d'actions observables: les entrées, les sorties et les éléments internes (états, transitions entre états). Un tel modèle va permettre de faciliter la mise en oeuvre de tests de conformité. Les transitions vont être activées suite à l'envoi ou la réception de données au cours de l'exécution du dialogue. Un dialogue comporte généralement, comme indiqué plus haut, plusieurs sous-dialogues. Un premier sous-dialogue peut être défini de telle sorte qu'il peut faire appel, au cours de son exécution à un second sousdialogue. A la fin du second sous-dialogue, l'exécution du premier sousdialogue peut par exemple être poursuivie ou au contraire être stoppée. Ces comportements sont traduits par des règles d'entrelacements (ou enchaînements) entre sous-dialogues, qui comportent des règles d'appels, de continuation et de terminaison relatives à ces sous-dialogues. Avantageusement on définit les enchaînements en fonction d'au moins un ensemble de règles parmi les règles d'appel, les règles de continuation et les règles de terminaison relatives à des sous-dialogues en fonction de transitions du modèle IOLTS et d'activation de ces transitions. Cette disposition permet de contribuer à spécifier la logique d'exécution d'un dialogue vocal. Dans un mode de mise en oeuvre du procédé, dans le cas où le modèle choisi est tel que la spécification décrit des transitions entre états, on met en oeuvre un processus algorithmique d'animation de la spécification, comprenant des étapes successives d'activation et de désactivation de transitions de la spécification, pour réaliser au moins une étape de validation parmi une étape de simulation du dialogue défini par la spécification et une étape de génération de cas de tests de validation destinés à tester une implémentation du dialogue. La simulation est une méthode de calcul qui, à chaque étape, décrit l'état du système simulé, les états accessibles depuis cet état, et les états précédents. L'étape de simulation du dialogue selon l'invention est effectuée à partir de la spécification du dialogue modélisée. Le fait que la spécification soit définie à l'aide d'un modèle formel de bas niveau et que la simulation soit construite à partir de la spécification va permettre de vérifier la conformité de la spécification avec les exigences requises relatives au dialogue ayant servis de base à l'écriture des spécifications, et ce indépendamment de tout choix d'implémentation du dialogue. Les simulations ne garantissent toutefois pas la vérification d'une implémentation du dialogue par rapport à la spécification du dialogue. Pour ce faire, l'étape de validation du dialogue doit en outre comprendre la réalisation de tests de conformité de l'implémentation du dialogue par rapport à la spécification. La réalisation d'un test de conformité consiste à exécuter sur l'implémentation un cas de test défini soit manuellement, soit à l'aide d'outils standards de génération de tests. Un cas de test est un programme destiné à s'exécuter sur un dispositif testeur interfacé au moment du test avec l'implémentation du dialogue et comprenant des instructions relatives à des actions réalisées par le testeur vis-à-vis de l'implémentation et à des mémorisations des comportements de l'implémentation suite à ces actions. Une comparaison est ensuite effectuée entre ces comportements mémorisés et les comportements attendus selon la spécification, qui produit des verdicts sur la conformité entre l'implémentation et la spécification. Le modèle IOLTS permet de distinguer les événements observés qui vont correspondre aux résultats fournis par l'implémentation du dialogue une fois sous test, et les événements contrôlés, qui vont correspondre aux données fournies en entrée (choisies par le testeur) à l'implémentation sous test. Le fait de générer les cas de test à partir de la spécification telle que définie selon l'invention garantit que les cas de tests sont indépendants de l'implémentation choisie pour le dialogue. Par ailleurs, les dialogues mettent classiquement en oeuvre des opérations de saisie de données (numéro de téléphone, code pin, ...) pouvant revêtir un nombre très important de combinaisons. La génération de tests de comportement pour de tels dialogues possédant une forte combinatoire est une étape difficile à maîtriser. Les outils de génération de tests existant se contentent généralement d'énumérer un à un les états du système par rapport aux données d'entrées. Cette énumération engendre une explosion des cas de tests générés. Avantageusement, l'étape de génération de cas de tests de validation comprend la modification de la spécification obtenue selon l'invention en remplaçant une pluralité d'entrées (par exemple l'ensemble des entrées par appui touches DTMF) par une unique entrée abstraite, le processus algorithmique d'animation de la spécification étant mis en oeuvre sur la spécification ainsi modifiée. Ainsi des signaux fournis en entrée, en provenance de l'usager ou d'applications extérieures sont représentés sous forme d'abstractions qui regroupent l'ensemble des occurrences auxquelles un dialogue vocal réagit, par exemple les entrées DTMF d'un clavier téléphonique, ou des messages produit par le service. Par exemple, le signal ville peut représenter l'abstraction d'une entrée d'un dialogue correspondant à l'énoncé d'une ville quelconque par l'utilisateur du dialogue. Cette opération d'abstraction permet de raisonner en domaine fini par rapport à des entrées réelles en nombre infini. Suivant un second aspect, l'invention propose un dispositif de construction de dialogue vocal comprenant des moyens pour mettre en oeuvre un procédé selon l'invention. Suivant un troisième aspect, l'invention propose un programme informatique comprenant des instructions pour mettre en oeuvre un procédé selon le premier aspect de l'invention. D'autres caractéristiques et avantages de l'invention apparaîtront encore à la lecture de la description qui va suivre. Celle-ci est purement illustrative et doit être lue en regard des dessins annexés sur lesquels: - la figure unique représente un organigramme indiquant des étapes d'un procédé selon l'invention. Il va être à présent décrit un mode de réalisation de l'invention utilisant un modèle formel à bas niveau nommé IF, entièrement défini sur la base des systèmes IOLTS. Pour plus d'informations sur ce modèle IF, on pourra se référer aux informations figurant à l'adresse URL http://wwwverimaq.imaq.fr/DIST SYS/IF/ ou au document IF: An Intermediate Representation and Validation Environment for Timed Asynchronous Systems , de M. Bozga, J.C. Fernandez, L. Ghirvu, S. Graf, J.P. Krimm, L. Mounier, ln proceedings of FM'99 (Toulouse, France), September 1999. Les éléments de syntaxe du modèle IF utilisé selon l'invention pour décrire les modèles de dialogues vont tout d'abord être succinctement présentés. Un système IF est constitué d'un ensemble d'objets actifs définis à base d'automates qui s'exécutent en parallèle et communiquent de manière asynchrone par des messages transportés par des canaux de communications. Un système IF est ainsi composé de processus, de canaux de communication, de données, types et signaux. Chacun des processus IF est défini à partir de machines à état fini identifiées par un nom unique (PID, en anglais Processus Identifier). Une instance de processus est la copie d'un modèle défini d'un processus. L'instanciation permet de créer plusieurs processus à partir d'un même modèle, en leur donnant un nom et sans avoir à en redéfinir le contenu. Chaque instance de processus possède une file de réception FIFO des messages en entrée transportés par les canaux définis dans le système IF attachés au processus. La réaction d'un processus aux messages reçus se traduit par des transitions entre états. La description d'un processus IF inclut le nombre d'instances initiales du processus, une liste de paramètres formels liés à l'initialisation du processus, un ensemble de variables locales représentant la mémoire interne du processus et un ensemble d'états/transitions définissant le comportement du processus. Le concept d'état est l'élément principal de structuration de comportement du processus IF. A tout moment, un processus est dans un état et suivant des événements internes ou externes, il peut passer dans un autre état de son comportement. Les états possèdent des caractéristiques de comportement qui permettent de définir si l'état en cours est l'état initial et si cet état est stable ou instable. L'état initial d'un processus est l'état qui est actif lors de son instanciation. La notion d'état stable ou instable est liée à l'atomicité des séquences de transitions. Intuitivement une transition atomique entre états est définie entre deux états stables, mais peut inclure des sous transitions de traitement et de décisions entre états instables. Ainsi, le pas atomique d'exécution d'un processus IF est la séquence de transitions entre états stables. Un processus ne peut être interrompu par d'autres processus lorsqu'il est dans un état instable. Enfin, à chaque état, on peut associer des actions de filtrages sur les canaux d'un processus qui permettent de retarder la consommation d'un message pour des états ultérieurs en sauvegardant les messages. Les transitions définissent en IF la réaction d'un processus en réponse aux stimulus. Les stimulus d'une transition peuvent être regroupés en deux types: - la présence d'un signal en entrée dans un des canaux du processus; - l'évaluation d'une expression booléenne qui conditionne l'activation d'une transition. Les réactions associées aux stimulus définissent des ensembles d'actions élémentaires composées en séquences à partir d'instructions de traitements classiques conditionnels du type si , alors , sinon et de boucle tant que <>, <> . Une transition doit définir l'état cible de la transition ou déterminer la terminaison du processus, qui signifie la destruction de l'instance exécutée). On peut également prioriser une transition par rapport à d'autres activables dans le même état en associant à chaque transition un degré de priorité. Plusieurs déclarations locales de types, de constantes ou de procédures manipulés par le processus peuvent venir s'ajouter à la définition d'un processus. La communication entre des processus est mise en oeuvre à l'aide de signaux et de canaux de communication. Les signaux (ou messages) sont des objets transportés de manière asynchrone à travers les canaux de communication du système IF et sont utilisés pour décrire la communication entre les processus. La déclaration d'un signal comporte respectivement son nom et la liste de types des paramètres transportés. Un canal de communication définit les chemins de communication entre deux processus. Comme les processus, les canaux de communication peuvent être multi-instances et dynamiques. Chaque instance d'un canal est nommée et identifiée par un PID. La déclaration d'un canal inclut le nombre d'instances initiales du canal, la source et la destination des signaux transportés ainsi que la liste des signaux transportés. Les données manipulées comportent les types, les constantes, les variables et les expressions. Il existe en IF cinq types de bases prédéfinis: boolean, integer, float, pid, et dock, et des mécanismes de construction de types tels l'énumération, la définition d'intervalles, les tableaux et les enregistrements. De plus il est possible de définir des abstractions de type. Cette fonctionnalité est exploitée dans un mode de mise en oeuvre particulièrement avantageux de l'invention. Les constantes sont utilisées pour nommer des valeurs représentatives d'un système, et sont ainsi généralement utilisées dans les expressions. On peut aussi utiliser les constantes pour paramétrer la configuration d'un système, comme par exemple le nombre d'instances d'un processus ou la taille d'un tableau. Il existe en IF deux constantes particulières self et nil, qui représentent respectivement le PID d'une instance, et une valeur de PID nulle. Les variables et les paramètres formels sont identifiés par un nom unique et sont typés. Les variables peuvent être globales au système ou locales aux processus. Les expressions sont construites au-dessus des variables et des constantes à partir d'opérateurs standards sur les types manipulés en IF. De plus, il est introduit les opérateurs '.' et '[ ]' qui permettent d'accéder respectivement aux champs d'un type record et aux éléments d'un tableau. II existe aussi un opérateur de conversion, qui permet de transformer des valeurs de types PID ou énumérées en entier, et réciproquement. Selon l'invention, on construit la spécification d'un dialogue vocal à l'aide de systèmes de transitions sous forme de processus IF. Les principes de cette construction sont décrits ci-après, en référence à la figure unique. Un dialogue décrit la logique des interactions entre un service et son utilisateur dans le but de remplir un objectif. En particulier, à chaque fonctionnalité du dialogue est associé un sous-dialogue qui permet à l'utilisateur l'accomplissement de l'objectif de la fonctionnalité. Un dialogue est composé de sous-dialogues et est organisé à partir d'un sous-dialogue spécifique (le dialogue principal), dont l'objectif est de fournir une vue globale du service en fournissant les accès aux différentes fonctionnalités du services représentées par des sousdialogues et qui ordonne l'exécution des sous-dialogues. Selon l'invention, on représente un dialogue, comme un sous-dialogue, comme un enchaînement d'états, l'enchaînement étant défini au moyen de transitions. Ainsi l'état global d'un service dynamique est défini par l'ensemble des états des sous-dialogues actifs. Deux instances d'un sous-dialogue avec des contextes différents peuvent cohabiter à un instant T du service. Chaque sous dialogue sdi d'un service vocal selon l'invention inclut le dialogue principal, c'est-à-dire le dialogue initial du service, qui est actif au début de toute exécution. Selon l'invention, dans une étape a) de construction d'un modèle IF de la spécification, pour chaque sous dialogue sdi identifié, un processus IF Psdi est construit à l'aide des éléments de syntaxe IF décrit plus haut. Le processus Psdi, peut déclarer en plus des éléments indiqués plus haut: - un paramètre de type PID destiné à faire le lien avec un processus appelant du sous-dialogue sdi (c'est-à-dire un processus qui lors de son exécution fait appel au sous-dialogue sdi, qui s'exécute alors); on nomme ce paramètre, paramètre de continuation; - un paramètre de type booléen destiné à caractériser l'appel du sous-dialogue: synchrone ou asynchrone; cette caractérisation est explicité plus loin; - un paramètre de type contexte qui englobe les déclarations globales du service. En outre, le service vocal peut utiliser en outre des objets métier du système d'information tel que par exemple: un catalogue, un annuaire, un agenda, etc. En IF et particulièrement dans un formalisme à base de système de transition, cette notion d'objet métier n'a pas de représentation directe. On représente l'invention un objet comme la composition d'une partie données et de plusieurs parties opérations déclarées par l'objet, et on transforme chacune de ces parties en un processus IF. selon le principe suivant: On crée un processus IF lié aux données de l'objet (l'instance de ce processus représente l'objet luimême). On crée pour chaque opération un processus qui décrit le comportement dynamique de l'opération. La référence de l'objet dans le système IF correspond au PID du processus "données". L'invocation d'un objet est traduit par la création dynamique du processus "opération" correspondant, avec comme paramètres, en plus de ceux définis pour le processus opération : - le PID du processus données ; - le PID du processus appelant afin de retourner le résultat de l'exécution. Enfin, pour permettre la continuation de l'appel d'un processus opération , ainsi que le transfert des résultats, chaque processus "opération" envoie à son appelant un signal de retour défini en fonction de la méthode traduite. Par ailleurs, selon l'invention, on distingue deux types d'états d'un sous-dialogue. - les états stables qui représentent l'attente d'un signal observable, fourni par l'utilisateur; - les états instables qui représentent des repères dans le flot de contrôle du dialogue (séquence d'actions non contrôlables par l'utilisateur) Une transition décrit un passage possible d'un état à un autre. II s'agit concrètement du flot de contrôle séparant deux états d'un dialogue. De l'extérieur, un utilisateur ne perçoit que les "extrémités stables" des transitions, c'est-à-dire les états où le service marque une pause et lui donne la main. Ainsi, entre deux interventions de l'utilisateur, le service passe d'un état stable à un autre noeud stable (les seuls perceptibles de l'extérieur), en franchissant éventuellement plusieurs états instables, auxquels cas plusieurs transitions sont enchaînées. Le service quitte un état stable en réagissant à l'un des signaux observables attendus dans cet état, par exemple, une action de la part de l'utilisateur (appui touche DTMF ou prononciation d'un mot-clef). En l'absence de tels événements, le service est suspendu. L'invention permet de définir les entrelacements des différents sousdialogues d'un dialogue, définissant les liens entre les sous-dialogues appelants et les sous-dialogues appelés. Elle permet à partir d'un élément de base des systèmes de transitions qu'est l'activation de transition entre états, de définir des règles d'appel, de continuation et de terminaison des sous-dialogues. Ces règles sont créées dans un système IF par la définition d'un processus gestionnaire et par l'ajout de transition de continuation à l'ensemble des processus modélisant un sous-dialogue. Le rôle du processus gestionnaire est d'activer le dialogue principal et de stopper le service (l'ensemble des sous-dialogues actifs). Les transitions de continuation permettent à partir de l'échange de signaux entre processus, l'ordonnancement des dialogues du service. Différents flots d'entrelacement sont définis selon l'invention: flot asynchrone aveugle, flot asynchrone de détournement, flot synchrone et terminaison. Un flot asynchrone aveugle définit la fin d'un sous-dialogue, et la restitution de la main au sous-dialogue appelant. Le flot asynchrone de détournement est un entrelacement qui décrit la fin du dialogue appelant, avec un passage explicite forcé de la main au dialogue désigné dans la clause de détournement asynchrone. Le sous-dialogue appelant ne récupère pas la main et est terminé, alors que le sous-dialogue cible du détournement est activé. Un flot asynchrone de détournement est une forme d'invocation de dialogue, et à ce titre peut préciser des paramètres effectifs. Le flot d'entrelacement synchrone est un entrelacement qui définit un appel de sous-dialogue tel que le sous-dialogue appelant suspend son exécution pour donner la main au sous-dialogue appelé. Lorsque le sousdialogue appelé se termine, le sous-dialogue appelant reprend la main et poursuit son exécution. Ce mode d'invocation se caractérise donc par le fait que le dialogue appelant reste actif pendant l'exécution du sous-dialogue (par opposition au flot asynchrone). Pour représenter ces flots d'entrelacement des sous-dialogues, on définit les signaux suivant: vt_next() : signal de continuation envoyé par les processus qui terminent leur exécution vers un processus actif leur succédant; vt_stop() : envoyé par le processus qui décide la terminaison du service au processus gestionnaire; return_dialogeName(arg1, argN) : signal de continuation envoyé par le processus qui termine son exécution dans un flot synchrone, vers l'appelant du processus. Le retour asynchrone aveugle décrit plus précisément la fin du processusdialogue actif, et la restitution de la main au dernier dialogue père actif. Pour le représenter en modélisation IF, on envoie le signal "vt_next" au PID du dernier père actif. Notons qu'il existe toujours au moins un processus actif qui est le gestionnaire du dialogue. Si le sous-dialogue a été lui-même créé par un appel de type flot synchrone, alors le sous-dialogue retourne son signal de continuation à son créateur, avant de d'envoyer le signal "vt_next". L'état vt_next doit exister dans l'ensemble des processus IF représentant un dialogue. La traduction du flot asynchrone de détournement est réalisée par la création dynamique du processus définissant le dialogue invoqué. Comme le dialogue appelant est détruit lors de l'appel, le paramètre de continuation des appels passés au dialogue invoqué est le PID père (dernier père actif) connu par l'appelant. Par ce mécanisme, si le dialogue détourné contient une clause de retour "aveugle", et qu'il n'existe plus de processus père (ce qui est le cas uniquement si le dialogue principal réalise un détournement), alors le dernier appelant connu est le gestionnaire du service. Ainsi, d'une part la sémantique de détournement n'est pas limitée, et d'autre part, on peut soulever un avertissement d'exécution si le processus gestionnaire reçoit la fin d'un détournement (sortie de dialogue non prévue explicitement par une terminaison). Si le sous-dialogue qui réalise le détournement a fait l'objet d'un appel de type flot synchrone, alors le dialogue retourne à son créateur son signal de continuation (dans l'exemple: return_Dialog_Name) qui peut éventuellement contenir des paramètres. Le flot d'entrelacement synchrone est traduit selon l'invention en IF suivant le principe de détournement, à l'exception que l'appelant se dirige vers un état d'attente du signal de continuation du dialogue appelé suivi du signal vt_next qui sera diffusé par le dialogue appelé ou un de ces détournements. La terminaison définit l'interruption de la communication de la part du service, et donc explicitement la fin de tous les dialogues actifs. Pour traduire cette sémantique en IF, il faut que tous les processus du système soient capables de se détruire et à tout moment. Pour réaliser ce mécanisme, il est considéré : - un signal de terminaison "killall()"; des transitions au processus gestionnaire dont le rôle (en autre) est de diffuser le message killall(), s'il reçoit un message stop d'un processus quelconque; - une transition de réception du signal killall(), qui est ajoutée à tous les états d'un processus de sous-dialogue qui définit l'attente de la fin d'un dialogue (soit par vt_next soit par le signal de retour de procédure); - un signal "vt_stop()", qui est envoyé par le processus qui décide la terminaison du service au processus gestionnaire. Ainsi la spécification d'un dialogue vocal peut être représentée selon l'invention dans un modèle IF, où les entrelacements entre sous-dialogues sont représentés à l'aide de transitions et d'activation de transition par l'intermédiaire de signaux déterminés. Avantageusement, dans une étape b, un processus d'animation de la spécification ainsi obtenue est ensuite défini. Ce processus consiste à explorer dynamiquement (calculer les successions d'états de) la spécification modélisée. Il comprend des séquences d'activation/désactivation des transitions de la spécification. Il peut se traduire selon le schéma algorithmique suivant: Initialiser le système // création du processus gestionnaire Empiler l'état initial du système Répéter Tant qu'il existe des états instables faire S'il existe au moins une transition activable d'un état instable alors Tirer au hasard une transition activable d'un état instable Sinon Sortir Fin si Fin tant que S'il existe au moins un état stable alors calculer l'ensemble des transitions activables depuis les états stables choisir une transition calculée ou choisir un retour arrière Si choix d'une transition alors Empiler l'état du système Tirer la transition choisie Sinon Dépiler l'état du système //désactivation des transitions depuis le dernier empilement Fin si Jusqu'à qu'il n'y est plus de processus actifs dans le système Ce processus d'animation de la spécification peut être mis en oeuvre pour constituer une simulation de la spécification (étape c) , qui pourra être utilisée pour valider la spécification par rapport aux exigences de fonctionnement du dialogue vocal requises. Ce processus pourra également être mise en oeuvre pour générer des cas de tests (étape d), qui pourront être mis en oeuvre lors de la validation d'une implémentation du dialogue vocal. Lorsque que ce processus est utilisé dans le cadre d'une étape de simulation, le choix de la transition à partir d'un état stable est réalisé par l'utilisateur qui dirige la simulation. Un processus d'animation ainsi défini permet la possibilité d'un retour arrière dans l'animation. Les transitions internes du service (à partir d'un état instable) étant automatiquement actionnées, la mise en oeuvre du processus permet de simuler le service tel qu'il est perçu par un utilisateur externe. Ce processus d'animation de la spécification peut en outre être utilisé dans le cadre d'une étape de génération de cas de tests. Dans ce cas, le choix des transitions est effectué par le dispositif testeur en fonction des cas de tests souhaités. Les propriétés de retour arrière et de choix, externe au processus, des transitions activables depuis les états stables permettent en outre d'utiliser le processus d'animation à des fins de générations de tests à partir d'outils standards (cf. Test Generation with Inputs, Outputs and Quiescence , J. Tretmans. In T. Margaria and B. Steffen, editors, Second International Workshop on Tools and Algorithms for the Construction and Analysis of Systems, TACAS'96, Passau, Germany. Springer Verlag, LNCS 1055, March 1996, ou encore Testing Labelled Transition Systems with Inputs and Output , J. Tretmans, ln 8th International Workshop on Protocols Test Systems, Evry - France, September 1995). Fin si Le procédé de génération de tests utilisant la spécification selon l'invention se décompose dans un mode de réalisation en trois étapes détaillées ci-après. La première étape consiste à abstraire les comportements combinatoires des spécifications, typiquement les fonctions de saisie de données, par des entrées génériques. L'objectif de cette étape est de transformer des comportements potentiellement infinis sur des entrées des spécifications en comportements dont les entrées sont finies et dénombrables. Cette disposition permet d'apporter une solution à un problème majeur de la génération de cas de tests, relatif à la sélection d'entrées de tests pertinentes. Par exemple, dans le cas d'un service vocal d'annuaire inversé, la spécification du service décrit un dialogue de saisie d'un numéro sur 10 chiffres, et l'objet des tests sur le service est de vérifier suivant les numéros composés, la réponse du service. L'ensemble des entrées valides pour la saisie d'un numéro contient 1010 solutions. Hors, naturellement, il n'est pas envisageable de tester le service avec l'ensemble des solutions. De plus, les solutions sont obtenues en fonction des attentes du service, mais ne sont pas liées à des propriétés fonctionnelles du service. Concrètement, un sous- ensemble de solutions correspond à des entrées invalides, un autre sous-ensemble à des entrées correspondant à des professionnels dans l'annuaire un autre sous-ensemble à des entrées correspondant à des particuliers dans l'annuaire, etc. L'opération d'abstraction permet de tester l'ensemble des fonctionnalités du service en fonction d'un représentant de chaque sous-ensemble. L'abstraction consiste à abstraire des entrées en une entrée abstraite, telle que chaque entrée abstraite appliquée à un même état de la spécification distingue un ensemble de comportements uniformes et uniques vis à vis des autres abstractions de comportement de l'état. Par exemple, dans le service d'annuaire inversé, dans l'état de saisie d'un numéro, des abstractions possibles sont: - une entrée abstrayant une séquence de DTMFs ayant comme propriété fonctionnelle la représentation de numéros invalides; - une entrée abstrayant une séquence de DTMFs ayant comme propriété fonctionnelle la représentation de numéros existant dans l'annuaire; - une entrée abstrayant une séquence de DTMFs ayant comme propriété fonctionnelle la représentation de numéros inexistant dans l'annuaire. Le choix des abstractions doit être guidé par l'ingénieur chargé de la validation suivant les propriétés du service qu'il désire tester. La deuxième phase du procédé de génération de tests consiste à interfacer un générateur de test et un dispositif mettant en oeuvre le processus d'animation de la spécification décrit ci-dessus. Le générateur de tests va définir les entrées observées, c'est-à-dire choisir les transitions auxquelles va réagir le processus d'animation. Dans cette étape du procédé, on suppose que la spécification a fait l'objet d'abstractions sur l'ensemble des séquences d'entrées combinatoires, et qu'elle est totalement contrôlable, i.e: quel que soit l'état de la spécification, il n'existe pas deux entrées contrôlables identiques telle que l'activation de l'une ou l'autre entraîne un comportement observable différent (on parle de spécification dont le contrôle est déterministe). L'outil de génération de tests est par exemple celui décrit dans Test generation derived from model-checking , de T. Jéron and P. Morel, in Nicolas Halbwachs and Doron Peled editors, CAV'99, Trento, ltaly, volume 1633 of LNCS, pages 108-122, Springer-Verlag, juillet 1999. Dans l'étape de génération de test, on paramètre dans cet outil les entrées qui sont contrôlables et les sorties qui sont observables. Dans le cas des dialogues vocaux, les entrées contrôlables sont les abstractions définies par l'ingénieur validation et éventuellement des appuis touche DTMFs particuliers, et, quant aux sorties observables, ce sont les messages produis par le service. Enfin, la production de cas de tests est réalisée en sélectionnant des comportements observables du service, tel que chaque comportement ait une trace d'exécution dont la première action est l'initialisation du service, et la dernière action la fin du service. Suivant ce principe, le comportement en entrée du service étant fini, il est possible de produire un ensemble de cas de tests couvrant de manière exhaustive, l'ensemble des branches du service. Les cas de tests produits lors de phase de génération de tests contiennent des séquences de comportements incluant les abstractions indiquées précédemment et réalisées sur la spécification. Afin de rendre ces cas de tests exécutables sur une implémentation d'un service, il convient, dans une dernière étape, de concrétiser les cas de tests obtenus. L'étape de concrétisation consiste d'une part à remplacer les entrées abstraites par des séquences d'entrées concrètes (par exemple remplacer l'entrée abstraite représentant un faux numéro, par une série de DTMFs correspondant), et d'autre part à traduire le test dans un langage exécutable. La traduction en langage exécutable consiste à faire correspondre les entrées logiques des tests aux entrées physiques du service. Pour réaliser cette traduction il est possible d'utiliser le langage de test TTCN3 qui est spécialement dédié à cette problématique. Dans un mode de mise en oeuvre de l'invention, l'ensemble des étapes d'un procédé sont automatisées, et mises en oeuvre par l'exécution d'un programme informatique. Dans un mode de mise en oeuvre, un procédé selon l'invention est mis en oeuvre par un dispositif comprenant des moyens pour cette mise en oeuvre. L'invention permet donc de produire une spécification d'un dialogue vocal, d'en déterminer, indépendamment de l'implémentation réalisée, une simulation du dialogue spécifié et des cas de tests pour ce dialogue tout en permettant de résoudre la problématique d'explosion combinatoire rencontrée habituellement dans de tels cas de tests. REVENDICATIONS 1. Procédé de simulation d'interactions entre une application vocale et un terminal d'utilisateur, comprenant les étapes suivantes: on définit une pluralité de sous-dialogues dans un dialogue vocal déterminé; - on détermine des enchaînements entre certains au moins desdits sousdialogues; et - on élabore une spécification du dialogue vocal en transformant au moins lesdits sous-dialogues et enchaînements en éléments d'un modèle formel de bas-niveau. 2. Procédé selon la revendication 1, selon lequel le modèle formel de bas niveau est un modèle de système de transitions à entrée/sortie. 3. Procédé selon la revendication 2, selon lequel on définit les enchaînements en fonction d'au moins un ensemble de règles parmi des règles d'appel, des règles de continuation et des règles de terminaison relatives à des sous-dialogues compris dans le dialogue en fonction de transitions du modèle et d'activation desdites transitions. 4. Procédé selon la revendication 2, selon lequel, la spécification décrivant des transitions entre états, on met en oeuvre un processus algorithmique d'animation de la spécification, comprenant des étapes successives d'activation et de désactivation de transitions de la spécification, pour réaliser au moins une étape de validation parmi une étape de simulation du dialogue défini par la spécification et une étape de génération de cas de tests de validation destinés à tester une implémentation du dialogue. 5. Procédé selon la revendication 4, selon lequel l'étape de génération de cas de tests de validation comprend la modification de la spécification en remplaçant une pluralité d'entrées par une unique entrée abstraite, le processus algorithmique d'animation de la spécification étant mis en oeuvre sur la spécification ainsi modifiée. 6. Dispositif de simulation de dialogue vocal, comprenant des moyens pour mettre en oeuvre les étapes d'un procédé selon l'une des revendications précédentes. 7. Programme informatique de simulation de dialogue vocal, comprenant des instructions pour mettre en oeuvre un procédé selon l'une des revendications 1 à 5.