L'analyse de toute application vocale complexe révèle rapidement que les mêmes structures de dialogue, petites et grandes, se retrouvent partout à travers l'application. Il est donc évident que le design et l'implantation d'applications vocales devraient en principe pouvoir bénéficier d'un niveau élevé de réutilisation. Malheureusement, le fait que tout dialogue doit être adapté au contexte dans lequel il est utilisé a fait en sorte que, jusqu'à présent, réaliser ce potentiel de réutilisation s'est avéré beaucoup plus difficile qu'il n'y paraissait à prime abord.

Même si différentes solutions à ce problème ont été proposées dans le passé (notamment sous la forme de « composantes de dialogue réutilisables », par exemple, une composante de dialogue utilisée pour obtenir un numéro de carte de crédit, qui encapsule un dialogue complet, incluant les segments vocaux et les grammaires), celles-ci n'offrent qu'un potentiel de réutilisation très limité. Par exemple, il n'y a généralement aucune façon de développer — par héritage ou par composition — de nouvelles composantes réutilisables à partir de composantes existantes. De plus, les mécanismes de configuration de ces composantes sont très limités. Par exemple, le dialogue ne peut être modifié qu'à travers un ensemble limité de paramètres (la structure elle-même du dialogue restant toujours fixe).

Une conséquence importante de ces limitations est que la très grande majorité des applications vocales contemporaines sont développées avec une quantité impressionnante de « copier-coller », avec tous les problèmes que cela entraîne au niveau du design, du développement, des tests et de la maintenance.

Le Nü Echo Dialog BuilderTM, un environnement graphique de développement d'applications vocales basé sur Eclipse a été conçu spécifiquement pour finalement apporter une réelle solution à ce problème.

Un environnement graphique de design de dialogues

Le Nü Echo Dialog Builder^TM transforme complètement le processus de design et d'implantation de dialogues en le bâtissant autour de l'identification, la définition et la réutilisation de structures communes de dialogues. Un fort niveau de réutilisation est ainsi rendu possible grâce aux mécanismes d'héritage et de composition offerts par l'environnement graphique. En particulier :

• Grâce à l'héritage, un dialogue peut être défini à partir d'un dialogue existant. Il hérite ainsi automatiquement les comportements et propriétés du dialogue parent.
• Un puissant mécanisme de composition et de configuration permet l'agrégation de dialogues dans le but de former un dialogue plus complexe, tout en modifiant localement les propriétés des dialogues utilisés.
• N'importe quel nœud d'un dialogue — souvent lui-même un dialogue — peut être modifié. On peut par exemple remplacer la stratégie de navigation de liste utilisée dans un dialogue par une nouvelle stratégie. Ceci fournit un mécanisme puissant d'adaptation des dialogues.

Cette approche de design de dialogues offre plusieurs avantages très importants. En particulier :

• Elle encourage un processus de design dans lequel les structures communes de dialogue sont identifiées et factorisées de sorte qu'elles puissent être réutilisées n'importe où dans l'application.
• L'utilisation de l'héritage comme remplacement du «copier-coller» permet d'obtenir une application compacte qui est moins sujette aux erreurs, plus facile à tester et plus facile à maintenir.
• Modifier le comportement d'une structure réutilisable de dialogue change son comportement partout où elle est utilisée dans l'application.
• L'environnement graphique permet de facilement voir les différences entre différents dialogues qui héritent d'un même dialogue parent.

Environnement d'exécution Java

Le Nü Echo Dialog Builder^TM produit une spécification du dialogue en DSXML (Dialog Specification XML). Cette spécification est utilisée par l'environnement d'exécution de la plateforme applicative Nü Echo afin d'exécuter le dialogue. Le code de support requis par l'application — par exemple, pour la logique d'affaires, l'accès aux systèmes transactionnels, ou pour de l'analyse sémantique évoluée — peut être développé en Java et appelé directement à partir de la spécification du dialogue par l'intermédiaire de scripts ECMAScript.

Chacune des ressources requises par l'application (grammaires, segments vocaux) est spécifiée dans le dialogue avec un identifiant unique, lequel est ensuite converti en une ressource physique en fonction de différents attributs de l'appel (langue, persona, mode, etc.).

Une philosophie orientée-test

Les tests devraient occuper une place très importante dans tout projet de développement logiciel et les applications vocales ne font pas exception. C'est pourquoi les tests sont au cœur de l'approche Nü Echo de développement d'applications vocales.

Pour cette raison, le Nü Echo Dialog Builder^TM, de même que l'environnement d'exécution, sont bâtis sur un modèle de dialogue dont le support complet pour l'introspection permet entre autre au développeur d'implanter des tests unitaires complets de dialogue (en utilisant le framework JUnit). Ces tests, qui peuvent être roulés d'une façon complètement autonome, sans plateforme VoiceXML et sans serveur web, peuvent être intégrés directement dans le processus de construction de l'application, assurant ainsi l'intégrité de l'application à chaque fois qu'elle est reconstruite. L'infrastructure de tests unitaires peut vérifier la couverture de tous les tests et identifier quels états ou quelles transitions du dialogue n'ont pas été couverts.

Parmi les autres caractéristiques orientées-tests, on peut mentionner

• Validation automatique des segments vocaux — S'assure qu'aucun segment vocal ne manque dans l'application packagée. Cette validation est faite de façon systématique lors du packaging de l'application.
• Outil web de tests interactifs — Avec l'aide de n'importe quel fureteur web, l'application complète peut être interactivement testée sans faire intervenir plateforme VoiceXML. L'outil permet de simuler toutes sortes d'événements pouvant se produire en cours d'appel (noinput, nomatch, un score de confiance spécifique, un raccrochage, etc.), permettant ainsi de tester un ensemble de conditions qu'il serait très difficile de reproduire en utilisant un téléphone.
• Mode compatible au générateur d'appel — Des séquences de synchronisation DTMF peuvent être associées à des nœuds spécifiques dans les composantes de dialogue, permettant ainsi l'implantation de tests fonctionnels ou de tests de charge automatisés.
• Générateur d'appels (Nü Bot) — Le générateur intelligent d'appels Nü Bot est utilisé afin de s'assurer que l'application se comporte tel que spécifié. Une variété infinie de scripts de tests peuvent être utilisés pour tester une large gamme de scénarios de tests. Ces scripts peuvent être développés manuellement ou encore automatiquement à partir de journaux d'appels avec l'application.

Caractéristiques principales

Réutilisation à base d'héritage — Pouvoir systématiquement utiliser l'héritage de comportement de dialogues est unique dans l'industrie. Cela maximise la réutilisabilité, minimise le « copier-coller », et produit des applications compactes qui sont moins sujettes aux erreurs, plus faciles à tester et plus faciles à maintenir.

Environnement de développement graphique — La plupart des outils de développement VoiceXML offrent une certaine forme de support pour le design graphique de dialogues et le Nü Echo Dialog Builder^TM ne fait pas exception. Cependant, le Nü Echo Dialog Builder^TM se démarque de tous les autres outils en permettant la visualisation et la manipulation de l'héritage et de la composition.

Support pour l'initiative mixte — Les « listeners » sont un type particulier de dialogue qui « écoutent » les énoncés des utilisateurs en parallèle avec le dialogue normal. Ils sont particulièrement utilisés pour implanter des comportements globaux — par exemple les commandes universelles — ou des dialogues à initiative mixte.

Packages — Afin d'aider à organiser de grandes quantités de fichiers DSXML, les dialogues peuvent être organisés en « packages », de manière similaire aux packages de Java.

Indépendance par rapport aux plateformes — Les spécifications de dialogues en DSXML sont complètement indépendantes de toute plateforme ou système d'exploitation et peuvent cibler aussi bien des plateformes VoiceXML que SALT, ou encore des plateformes RVI natives.

Intégration complète avec Java — Le code de support requis par l'application peut être développé en Java et appelé directement à partir de la spécification du dialogue par l'intermédiaire de scripts ECMAScript.

Journaux et rapports — L'environnement d'exécution du DSXML produit nativement des journaux détaillés et est supporté par un outil sophistiqué d'analyse d'appels ainsi que par des outils de rapports.