Environnement proposé

Le projet EM2 comprend une proposition pour un projet d'atelier construit sur le noyau décrit précédemment. Cet atelier supporte trois phases de développement d'un projet: l'analyse, la spécification et l'implantation. Pour chacune de ces phases, l'atelier dispose d'une méthodologie adap*. Ce sont les suivantes: décomposition fonctionnelle à l'aide de SADT pour la phase d'analyse, une méthode de spécification basée sur les types abstraits et sur le dialogue de l'utilisateur pour la phase de spécification, et une méthode de décomposition modulaire pour Ja phase d'implantation .

5.2.1 Phase d'analyse

La méthodologie adoptée pour la phase d'analyse est une décomposition fonctionnelle réalisée à l'aide de la méthode SADT [Ros 77a, Ros 77b]. Cette méthode pennet de décomposer les fonctionnalités d'un projet en une hiérarchie d'actigrammes. Les actigrammes constituent les objets de cette phase, et les dépendances hiérarchiques entre les actigrammes constituent les liens internes à une phase qui serviront à la vérification. Le vérificateur d'objet vérifie que la syntaxe d'un actigramrne est respectée par rapport aux actigrammes liés.

5.2.2 Phase de spécification

La méthodologie adoptée pour cette phase repose principalement sur l'utilisation des types abstraits algébriques. Cette méthodologie vise la spécification de logiciels interactifs et satisfait différents points:

- Définir une méthodologie basée sur le dialogue, permettant la construction des différentes parties du logiciel.

- Etablir la correspondance entre les objets externes (visibles à l'utilisateur) et les objets internes, ainsi que garantir la cohérence entre eux.

- Satisfaire à des considérations ergonomiques, telles que l'adaptation du type de dialogue aux utilisateurs du logiciel, le parallélisme des actions, la gestion des erreurs, ...

- Avoir la possibilité d'exécuter des prototypes (spécifications exécutables) [Cho 85].

Un logiciel interactif peut être décomposé en plusieurs niveaux d'abstraction [Fol 83). Chacun de ces niveaux est associé à une partie du logiciel, chacun~ de ces parties ayant sa propre description. La partie application est constituée d'une hiérarchie de types abstraits qui modélisent données et traitements, décrivant le niveau sémantique de l'interaction. La partie dialogue gère le niveau syntaxique de l'interaction, et est décrite par des Réseaux de Petri. Le niveau lexical de l'interaction, c'est-à-dire les entrées/sorties au niveau des supports physiques, est géré par la partie lexicale. Dans ce modèle, l'interaction constitue un langage, et le logiciel correspondant est un analyseur de ce langage.

- Partie application

Pour spécifier l'application, nous avons utilisé une méthode formelle classique: les types abstraits algébriques [Gut 78). Ceux-ci permettent de réaliser une spécification bien structurée en couches successives de niveau d'abstraction de plus en plus élevé [Lis 74). La méthode algébrique a l'avantage d'exprimer de façon très simple les relations entre les opérations au moyen d'équations, et de permettre la vérification des propriétés de ces opérations.

Les spécifications sont développées sur une couche de base de types abstraits. Citons par exemple, les types logique, entier, naturel, chaîne de caractère, des types constructeurs (tels que liste, ensemble, produit cartésien, etc ... ) et un type objet graphique (définissant les objets et les opérations graphiques de bases utilisés pour construire les représentations des objets de l'application [Mal 82)).

- Partie dialogue

Pour modéliser la partie dialogue. nous utilisons le formalisme des réseaux de Petri [Bra 82] dans lequel les places peuvent contenir des marques typées (par les types de l'application) et les transitions déclenchent des opérations de l'application. Ces réseaux de Petri représentent le flot des données du dialogue, chaque marque est un objet de l'appHcation et chaque transition est tirée par un événement déterminé par la partie lexicale. Ces réseaux de Petri sont structurés en modules, ce qui permet de réaliser une décomposition structurée des dialogues. Le formalisme des réseaux de Petri permet d'exprimer facilement les caractéristiques séquentielles et parallèles des dialogues.

- Partie lexicale

La partie lexicale permet de i:pécifier pour chaque événement les types de périphériques utilisés: (souris, entrée caractère, objets désignables) et pour chaque type de l'application, sa représentation

graphique. Les fenêtres et leurs contenus sont également gérés par la partie lexicale.

Cette méthode de _spécification nécessite d'avoir des librairies de types abstraits servant d'outils de base à l'utilisateur. Si ces éléments de librairie sont implantés en modules, alors la traduction des spécifications devient aisée.

5.2.3 Phase d'implantation

Pour cette phase, la méthodologie consiste, à partir des types abstraits fournis par la phase de spécification, à créer des représentations de types abstraits en fonction de types de base. Ces types de base constituent une librairie et sont écrits dans le langage d'implantation.

L'ensemble des représentations des types abstraits constitue une ébauche du logiciel, qu'il faut ensuite raffiner. Le code est écrit dans un langage modulaire (MODULA-2). Les objets considérés dans cette phase sont les modules. Les liens entre les objets de cette phase sont constitués des liens d'importation entre modules. La vérification d'objet correspond au contrôle des irpportations dans la compilation. La validation consiste à vérifier que chaque implantation de type est bien équivalente à sa spécification. Ceci peut être réalisé par des jeux de tests construits de façon appropriée [Bau 85].

Lors de cette phase, on procède à une évaluation de la qualité en mesurant la complexité du logiciel modulaire. Dans certains cas, on peut être obligé de procéder à une restructuration de ce logiciel. la restructuration porte sur les types abstraits qui .constituent le logiciel. Elle est effectuée au niveau des modules, mais on peut concevoir de l'effectuer aussi au niveau des spécifications. Son but est d'augmenter la cohésion à l'intérieur des modules.

5.3 PERSPECTIVES D'IMPLANTATION