Utilisation

L'environnement EM2 a été implanté et fonctionne de manière satisfaisante, mais une utilisation productive reste encore à effectuer. Les principales raisons en sont les suivantes: difficulté de trouver des équipes qui jouent le rôle de cobayes, et difficulté pour une petite équipe d'assurer la maintenance d'un tel système, à moins que tous les membres se lancent dans le support.

Par contre, les différents outils de base ont été utilisés de nombreuses fois par les étudiants dans le cadre, soit dans des travaux de licence et de diplôme, soit des travaux pratiques associés aux cours. Ces différents outils forment une couche au dessus de la couche de librairie et permettent de définir une machine abstraite d'un niveau supérieur. Ainsi, l'interface utilisateur d'un logiciel est facilement réalisable à l'aide des outils de gestion de fenêtre, de menu et de liste dans une fenêtre.

Finalement, il est dommage de n'avoir pas pu disposer du personnel de maintenance et des équipes cobaye nécessaires à l'évaluation de EM2, mais toutefois nous considérons comme très positif l'utilisation qui a été faite des divers composants.

EVOLUTION DU PROJET EM2

5.1 LE NOYAU EM2 5.1.1 Introduction

La réalisation du prototype EM2 nous a permis d'acquérir une certaine expérience et, surtout, de prendre conscience des différents problèmes attenants aux environnements de développement de logiciel.

L'intégration de nouvelles méthodes et de nouveaux outils constitue un des problèmes majeurs. Nous avons donc décidé d'orienter nos travaux vers la conception d'un noyau d'environnement, constituant une structure de base à partir de laquelle il est relativement aisé de construire un environnement complet en ajoutant les outils qui nous intéressent. Un objectif de ce noyau est de permettre l'évolution d'un environnement.

Il est nécessaire de préciser maintenant quelles sont les différences entre les notions suivantes: projet EM2, prototype EM2 et noyau EM2. Le projet EM2 englobe toutes les recherches du groupe, le prototype EM2 concerne le prototype d'environnement réalisé et décrit dans les pages précédentes, et le noyau EM2 caractérise une nouvelle étape dans nos travaux: celle d'un noyau d'environnement.

Selon notre nouvelle approche [Buc 88a], un atelier de geme logiciel est généré à partir d'un noyau, auquel on associe un certain nombre d'éléments de base. Ces éléments de base sont, par exemple, des outils et des objets, spécifiques aux méthodologies que l'on désire appliquer avec cet atelier. Le but d'un noyau est de minimiser le nombre des éléments extérieurs (au noyau), pour arriver à générer un atelier à l'aide uniquement de la description syntaxique et sémantique des objets que l'on désire traiter dans l'atelier, tout en permettant une certaine généralité. Un noyau facilite donc la réalisation d'un atelier mais impose certains choix. Notre noyau est structuré en trois parties: l'interface utilisateur, la base de données et les outils génériques de ce noyau. Il hérite de la structure générale du prototype EM2, dont il conserve la structure projet-version.

Interface Utilisateur

Outils et données spécifiques à un atelier

Figure 5.1 : Organisation et description des constituants d'un atelier

La figure 5.1 donne l'organisation et la description de ces différents éléments. Une approche similaire est utilisée dans la structure d'accueil Emeraude [Bou 86].

Ce noyau permet de supporter les différentes phases du cycle de vie, ainsi que la cohérence du passage d'une phase à l'autre (figure 5.1).

L'utilisateur doit donner les règles de vérification et de validation d'un objet, le noyau s'occupe ensuite de les appliquer à tous les objets d'une version d'une phase. On restreint les différents types d'objets possibles en supposant que les objets, d'une version de projet pour une phase, sont organisés hiérarchiquement.

5.1.2 Objet

. La notion d'objet est une généralisation de celle présentée dans le paragraphe précédent (le prototype EM2) avec toutefois une petite modification. Un objet est un élément logique de base d'un atelier.

Différents types d'objets sont nécessaires pour les différentes phases supportées par l'atelier (par exemple, des diagrammes SADT, des types abstraits, des modules, etc ... ). Les objets peuvent être constitués de sous-objets, par exemple, un type abstrait est constitué d'un certain nombre d'opérateurs, ou encore un module peut contenir un certain nombre de procédures. Suivant les cas, nous nous intéresserons au seul ensemble des objets, ou à l'ensemble des objets plus l'ensemble des sous-objets. Dans le prototype EM2 décrit au chapitre précédent, on ne faisait pas de distinction entre objet et sous-objet, les deux notions étaient confondues dans la notion d'objet.

5.1.3 Liens entre objets

Il existe des relations entre les objets, que nous appelons liens.

Deux types sont utilisés: les liens entre objets d'une même phase pour la vérification de cette phase, et les liens entre objets de phases différentes pour la validation [Adr 82]. Par exemple, les dépendances relatives aux importations entre modules Modula-2 constituent les liens entre objets pour la phase d'implantation. Pour obtenir les liens du premier type, on utilise un analyseur de liens d'objets qui identifie les dépendances entre les objets d'une même phase. Cet analyseur est un outil générique du noyau paramétré par la syntaxe des types d'objets.

Pour les liens du deuxième type, on doit disposer d'un analyseur de liens entre phases, qui cherche les dépendances entre les objets d'une phase avec ceux de la phase précédente. Ce deuxième type de lien est plus délicat à identifier car il fait intervenir la sémantique des objets, et l'analyseur correspondant doit être fourni lors de la construction de l'atelier. Les dépendances entre les objets de la phase d'analyse et la phase de

spécification sont les plus difficiles à identifier. On peuc imaginer que l'utilisateur joue un rôle important dans l'analyseur correspondant.

Figure 5.2 : Graphe des versions (exemple du projet EM2)

5.1.4 Outils génériques

Lc:i outil& générique& constituent le centre de l'atelier, ils assurent l'incerface avec tous les autres éléments. L'interface utilisateur, par exemple, communique uniquement avec eux, ee qui permet d'avoir une interface uniforme pour tous les outils et aussi pour les différents ateliers construits autour de ce noyau. De même, la base de données et les outils spécifiques à un atelier sont interfacés uniquement avec les outils du noyau. La généricité de ces outils s'exprime par le fait qu'ils sont utilisés pour construire différents ateliers et aussi par le fait qu'ils doivent permettre de traiter les différentes phases d'un projet. Nous allons voir maintenant ces différents outils plus en détail.

5.1.5 Gestionnaire de versions

Le gestionnaire de versions gère les différentes versions d'un projet pour toutes les phases de développement (figure 5.2). Il permet de créer des liens entre différentes versions, que ce soit avec une nouvelle version

ou avec une version librairie. Il assure aussi le rôle de gestionnaire de configuration puisque nous avons préféré l'approche versions de projet à celle de versions d'objet. Les versions d'objet consistent à développer les objets indépendamment les uns des autres, et la constitution d'une version se réalise en prenant telle version de cet objet, telle version de cet autre objet, et ainsi de suite. Chaque objet est géré séparément. Avec les versions de projet, on gère en même temps tous les objets qui constituent une version. Notre approche est un peu moins souple mais elle pennet de gagner en simplicité.

Le graphe de versions possède une structure relativement complexe, à chaque noeud d'une version d'une phase est associé le graphe des versions de la phase suivante. Ainsi, dans le projet EM2 (figure 5.2), à chaque version des spécifications est associé le graphe des versions d'implantation obtenues à partir de cette version de spécification. Lorsque l'on définit une version courante dans une phase, on accède alors au gestionnaire d'objets qui pem1et les fonctions classiques suivantes: la création, la destruction, la modification et la consultation d'objets. Dans l'environnement proposé, ce sont des outils génériques paramétrés par le type des objets qui réalisent ces fonctions. Par exemple, l'éditeur doit être guidé par la syntaxe du langage de description des objets. Chaque phase implique un type d'objet particulier, l'éditeur est donc adapté à chacune d'entre elles.

Les outils liés à la vérification et à la validation sont des outils moins classiques d'un atelier, ce sont eux qui vont assurer et garantir la cohérence du développement d'un projet à l'intérieur d'une phase mais aussi entre les phases.

Avec les objets d'une version et les liens entre ces objets, on construit un graphe orienté, le graphe des liens. Ce graphe n'est pas utilisé globalement. On en extrait un certain nombre de sous-graphes, en fonction du type de lien considéré, tels que le graphe de dépendances des objets internes à une phase, ceci pour chaque phase (figure 5.3), ainsi que le graphe de dépendances entre objets de phases successives (figure 5.4).

Le premier graphe est utilisé pour Ja vérification alors que le deuxième l'est pour la validation.

Les différents symboles des figures 5.3 et 5.4 représentent simplement le type des objets propre à chaque phase. Par exemple, les boîtes rectangulaires au premier plan pourraient être des diagrammes SADT, les cercles et les triangles du deuxième plan pourraient être des types abstraits, et les cercles au troisième plan pourraient être des modules.

Figure 5.3 : Graphe des liens dans une phase

Figure 5.4 : Graphe des liens entre phases

5.1.6 Méta-base

La méta-base de données, spécifique à un atelier, sert à générer la base de données de cet atelier. Elle contient la description de la nature des objets et des liens entre eux, propres à chaque phase (figure 5.5). La méta-base doit être fournie lors de la conception d'un atelier. Elle pennet d'adapter différentes méthodologies, ainsi que leurs outils, dans un atelier.

Relations

Phase (nom phase, nurnéro_phase)

Classe_objet (nom phase, type objet, exécution, syntaxe)

Lien (nom phase 1 . type objet l, nom lien, nom phase 2, t}lle objet 2, vérification, validation)

Figure 5.5: Méta-base de données d'un atelier et description relationnelle

5.1. 7 Vérification

La vérification de phase consiste à garantir que tous les objets constituant une version d'un projet pour cette phase soient passés par une action de vérification d'objet. Pour cela, il faut créer un vérificateur d'objet, spécifique à chaque atelier et à chaque phase. On utilise aussi l'hypothèse (restrictive) de départ selon laquelle tous les objets, d'une version de projet pour une phase, sont organisés hiérarchiquement. Cette hypothèse est correcte, par exemple, pour une phase d'analyse dont les objets sont des diagrammes SADT. Elle est correcte aussi pour des phases de spécification et d'implantation dont les objets sont, respectivement, des types abstraits et des modules. Le vérificateur d'objet dépend fortement de la nature de l'objet, c'est un outil qui doit être fourni à l'atelier.

Le vérificateur d'objet vérifie que la combinaison d'un objet donné, avec l'ensemble des objets qui lui sont liés, est bien cohérente. Par

exemple, considérons que les objets de la phase de spécification sont des types abstraies. Un type abstrait peut être construit à partir d'autres types abstraits. Pour vérifier ce type abstrait, il faut vérifier que les opérateurs qu'il utilise correspondent bien avec ceux définis dans les types abstraits sous-jacents.

Le graphe des liens étant un arbre orienté (résultant de la hiérarchie entre objets), la vérification est régie par la règle suivante: un objet ne peut être vérifié que si les objets qui lui sont liés sont vérifiés, lié signifiant qu'il existe un lien pour la vérification, du type spécifié dans la méta-base.

La modification d'un objet nécessite une vérification de cet objet ainsi qu'une vérification de tous les objets auxquels il est lié. Chaque objet, dans la base de données, possède un indicateur de vérification. L'algorithme utilisé pour effectuer la vérification de phase est relativement simple, on commence par regarder l'état (vérifié ou non vérifié) des objets, et, pour chaque objet non vérifié, on propage cet état selon les arcs. Ensuite, on effectue la vérification d'objet dans l'ordre topologique détenniné par les liens.

5.1.8 Validation

La validation [Bau 85, Ber 87] consiste à garantir qu'une phase soit cohérente par rapport à la phase précédente. De la même manière que pour la vérification, la validation de phase consiste à garantir que tous les objets (d'une version d'un projet) d'une phase ont subi une validation d'objet par rapport aux.objets (de la même version d'un projet) de la phase précédente. Par contre, les dépendances d'objets entre phases sont des liens sémantiques et il est difficile d'en dégager une structure. Le cas idéal serait d'avoir des liens d'objet à objet entre des phases différentes et de pouvoir les valider isolément. Si on considère des diagrammes SADT (objets de la phase d'analyse) et que l'on regarde les liens qui exililt:ul avt:l:

des types abstraits (objets de la phase de spécification), on remarque que l'on ne peut pas lier directement un diagramme SADT avec un type abstrait. On est donc obligé de regarder les liens entre des ensembles d'objets de chaque phase. Le cas le moins intéressant correspond à lier globalement l'ensemble de tous les objets d'une phase avec l'ensemble de ceux de la phase précédente. Dans notre modèle de cycle de vie composé de trois phases, il y a deux validations de phase à effectuer. Elles doivent être différenciées car la validation entre la phase d'analyse et la phase de spécification est plus complexe que la validation entre les deux phases suivantes. Le problème de la validation est fortement lié au problème de la traduction entre phases. Plus le niveau d'abstraction est élevé, plus la sémantique contenue dans chaque objet est importante et plus la traduction est difficile. Dans certains cas, la traduction est impossible car la sémantique des objets n'est pas suffisamment bien décrite: il n'y a donc pas

de modèle de transformation, ce qui implique un processus créatif de traduction de la part de l'utilisateur.

5.1.9 Base de données

vérificalion

Figure 5.6: Base de données d'un atelier (exemple du projet EM2) La base de données contient la description des différents projets développés dans un atelier. Elle comprend deux relations de base, les relations utilisateur et projet, ainsi que des relations de base construites sur les notions de version et d'objet. Ces deux relations existent pour chaque phase du modèle de développement L'exemple de la figure 5.6 montre la base de données du projet EM2. Pour créer la base de données, on a besoin des informations, entre autre, la description des différentes

phases, contenues dans la méta-base de données (figure 5.5). Donc, la génération de la base de données d'un atelier est réalisée à partir d'une base de données générique (appartenant au noyau) paramétrée par le contemt de Ja méta-base de données.

5.2 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

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