Activité de production

L'activité de production se concentre sur le logiciel à développer.

Elle constitue l'activité principale dans le développement d'un logiciel.

Pour cela, un environnement doit fournir une méthodologie comprenant des outils et des méthodes qui permettent de couvrir tout le cycle de vie du logiciel, et qui permettent aussi de contrôler et de garantir la qualité du produit par des méthodes de vérification et de validation.

De nombreux termes existent pour caractériser les environnements;

les plus usuels sont: environnement de développement de logiciel, environnement de programmation, environnement de génie logiciel ou encore atelier de génie logiciel. Traditionnellement, une distinction est faite entre les environnements de programmation et les environnements de développement de logiciel. Les premiers aident à l'implantation (la

programmation), alors que les seconds apportent aussi une aide plus conséquente aux autres phases du cycle de vie. Les autres termes sont difficilement différentiables. Comme toutes ces distinctions s'estompent, nous avons décidé d'unifier tous ces termes et nous emploierons indifféremment l'un ou l'autre.

3.2 CLASSIFICATION ET EXEMPLES

D'ENVIRONNEMENTS

3.2.l Classification des environnements

On distingue plusieurs types d'environnements selon les objectifs visés par ces environnements [Dar 87].

Les environnements basés sur un langage

Ces environnements sont conçus pour le support d'un langage particulier. Turbo-Pascal pour le langage Pascal, et Interlisp [Tei 81] pour le langage Lisp sont deux exemples de tels environnements. Ces environnements sont limités; ils ne fournissent un support que pour un seul langage et ne sont utiles, en général, que pour une petite partie du cycle de vie du logiciel: la phase d'implantation.

Historiquement, ce sont les premiers environnements qui ont été réalisés et que l'on appelait environnement de programmation. Ils fournissent des moyens puissants de programmation, en particulier de compilation, soit par un compilateur très rapide, soit par un compilateur incrémental ou encore par un interpréteur. En outre, ils fournissent les outils classiques liés à la programmation: éditeur de texte (qui peut être dirigé par la syntaxe des langages), éditeur de liens, débogueur et moniteur d'exécution.

Ce type d'environnement peut contenir aussi un éditeur syntaxique [Ebe 83, Eng 87], c'est-à-dire un éditeur dirigé par la syntaxe. Un tel éditeur vérifie la syntaxe au fur et à mesure de la construction du programme. L'utilisateur n'a plus à connaître par coeur tous les détails de Ja syntaxe du langage dans lequel il écrit, les structures du langage sont fournies automatiquement par l'éditeur. Dans un tel environnement, un programme n'est plus considéré comme un texte, mais comme une structure d'objets du langage. La représentation interne, normalement sous forme d'arbre, permet d'avoir plusieurs modes de représentation externe d'un programme (par exemple, le texte complet du programme ou seulement les structures de données, les procédures, etc ... ).

Les environnements boîte à outils

Les environnements boîte à outils forment un ensemble d'outils indépendants. Il est très facile d'ajouter, de modifier ou d'enlever wt outil sans nuire à l'énvironnement. Les environnements de ce type sont basés sur un système d'exploitation qui constitue le lien entre les outils. Le plus célèbre d'entre eux est certainement l'environnement Unix [Ker 84]. Ces environnements sont adaptés à la phase d'implantation du cycle de vie du' logiciel et sont indépendants du langage de programmation choisi. Leur principal inconvénient est l'absence de méthodologie qui se caractérise par l'absence de cohérence et d'uniformité entre les outils.

Les environnements basés sur une méthode

Ces environnements fournissent un outil supportant une méthode particulière pour aider au développement du logiciel. Les méthodes supportées peuvent se présenter sous deux formes: soit des méthodes applicables à des phases pa.rticulières du cycle de vie, soit des méthodes de gestion du développement du logiciel (basées sur des concepts de version, d'objet, ou de configuration). Les méthodes supportant les phases particulières du cycle de vie sont très nombreuses, on en verra quelques exemples au troisième paragraphe. Elles sont plus ou moins formelles, les moins formelles étant généralement plus faciles à utiliser car les méthodes plus formelles imposent un formalisme souvent difficile à lire et à maîtriser. Evidemment les méthodes peu formelles (portant généralement sur la phase d'analyse) ne permettent pas un bon contrôle du logiciel produit.

Les méthodes de gestion du développement du logiciel consistent en des méthodes de gestion d'obj~ts , tl~ g~i;LiuH ù~ ve.-sions, de gestion de configurations et de gestion de la communication entre les utilisateurs de l'environnement.

- La gestion d'objets consiste à gérer les éléments de base d'un logiciel et à favoriser Jeur réutilisation en permettant de travailler sur la sémantique de ces objets.

- La gestion de versions consiste à gérer et à conserver les états successifs d'un logiciel en développement.

- La gestion de configurations consiste à prendre une version définie des objets du projet pour composer une réalisation de ce projet. ·

- La gestion de la communication entre les utilisateurs d'un environnement est encore peu répandue, pourtant elle constitue un

élément indispensable dans le développement d'un projet par une équipe.

Par exemple, il existe des environnements basés sur la méthode SADT. L'outil principal d'un tel environnement doit permettre la création et la manipulation de diagrammes SADT tout en contrôlant leur cohérence.

Les environnements génériques

Ces environnements sont paramétrés par la description des objets mis en jeu dans l'environnement. Ils couvrent plus ou moins entièrement le cycle de vie et selon le degré de sophistication visé, ils nécessitent une description sémantique en plus d'une description syntaxique des objets à considérer. Un environnement contenant un éditeur syntaxique générique néCessite uniquement de connaître la syntaxe du langage désiré, alors que si l'on s'attaque à des problèmes de vérification ou validation des objets, il faut donner en plus une description sémantique de ces objets. On peut citer des exemples d'environnements basés sur ce principe: ALMA [Van 87) (dont la base de données est décrit dans le modèle entité-association), ASDL-GRASPIN [Chr 86) (dont les structures de données sont décrites dans un métalangage) et .MENTOR [Don 81).

. Ces différents types d'environnements représentent les principales directions d'étude des environnements. Ces catégories ne sont pas exclusives, certains environnements possèdent les caractéristiques de plusieurs catégories.

Le prototype EM2 est un environnement qui appartient à plusieurs catégories. En effet, il fait partie des environnements basés sur une méthode car il offre des méthodes de gestion du développement de logiciel. C'est aussi un environnement basé sur un langage puisqu'il offre un certain nombre de facilités pour le langage MODULA-2.

3.2.2 Stratégies de développement d'un environnement

Le développement des environnements semble s'effectuer de manière empirique sans suivre une stratégie de développement bien définie. Généralement, on développe un environnement à partir d'un point de départ concret, un langage ou une méthode, et ensuite on l'enrichit au fur et à mesure des besoins et des découvertes. En fait, le développement d'un environnement ne consiste que dans la phase d'implantation, il y a rarement des phases formelles d'analyse et de spécification. Le problème de ces environnements est qu'ils n'ont pas de structure et tout enrichissement ou toute extension constitue une verrue sur l'environnement. On a pris conscience de l'importance des

environnements et leur développement vise à respecter dorénavant toutes les phases du cycle de vie. Ainsi, pour le langage ADA on s'est rendu compte qu'un environnement très complet était indispensable, alors des phases d'analyse et de spécification ont eu lieu et ont abouti au rapport STONEMAN [Bux 80].

Certaines caractéristiques jouent un rôle important dans un environnement et font désormais partie de la stratégie de leur développement. Les principales caractéristiques sont: la base de données centrale, l'intégration des outils de l'environnement. l'interface utilisateur uniforme de ces outils et l'extensibilité. Les liens entre ces caractéristiques permettent de dégager un squelette de structure de l'environnement schématisé par la figure 3.1.

[Q

I 11 \ \\

~ 1

\ \ \ I Il

@]

Interface utilisateur

Outils

Base de données centrale

Figure 3 .1 : Schéma de la structure d'un environnement

- Base de données centrale [Obe 85]: elle permet de grouper les informations, obtenues lors du développement d'un projet, en un seul endroit. La base de données dispose d'une interface à travers laquelle interagissent tous les outils, ce qui garantit la cohérence des informations contenues. Un des principaux problèmes est de déterminer

ce que doit contenir cette base de données. Une première approche est de stocker toutes les infonnations propres à un projet (documents, code source, code objet, etc ... ). Cette approche aboutit à une base de données volumineuse et pénalisante en efficacité dans Je cas de développement de grands projets. Une deuxième approche consiste à stocker seulement les informations décrivant l'état du projet et les références aux programmes, mais les codes source et objet correspondants ne sont pas stockés. Cette approche permet de limiter la base de données à une taille raisonnable et ainsi de pouvoir traiter des projets plus importants.

- Intégration : l'intégration d'un ensemble d'outils consiste à regrouper ces outils autour d'un concept commun, la base de données centrale. De plus, les outils doivent être accessibles uniquement à l'intérieur de l'environnement à travers J'interface utilisateur, ce qui garantit rintégrité des données.

- Interface utilisateur uniforme : un environnement met à la disposition de l'utilisateur un certain nombre d'outils; si ces outils présentent des interfaces disparates, l'utilisateur doit non seulement se consacrer à son problème, mais aussi trouver comment fonctionnent ces outils. Si les outils présentent la même interface uniforme, alors l'utilisateur peut travailler plus facilement. De cette manière, les outils sont considérés comme appartenant au même environnement. L'uniformité ne consiste pas uniquement à présenter les mêmes moyens d'interaction (les fenêtres, les menus, etc ... ), mais aussi à fournir la même représentation conceptuelle des objets [Fol 83] (les objets sont vus de la même manière à travers les différents outils).

- Extensibilité : un environnement extensible offre une grande souplesse d'emploi tout en permettant l'intégration de nouveaux outils pour s'adapter à de nouvelles exigences. Par exemple, dans l'environnement ISTAR [Dow 87], il est facile d'intégrer des outils comme un éditeur ou un compilateur pour un langage. Les outils sont intégrés dans l'environnement, ils utilisent l'interface utilisateur de l'environnement et ils travaillent sur les mêmes données communes que les autres outils.

Il est difficile de définir un environnement idéal qui soit complet et qui satisfasse tous les critères précédents. En plus de ces critères, pour être complet, un environnement doit être efficace et doit proposer une méthodologie globale qui guide l'utilisateur à travers l'environnement.

Le prototype EM2 s'efforce de tenir compte de ces quatre principaux. critères. En effet, les informations propres aux projets sont stockées dans une base de données centrale, accédée par un ensemble intégré d'outils, qui sont sollicités par un utilisateur à travers une interface

uniforme. L'extensibilité est assurée par un certain nombre d'outils de base à partir desquels tout développement est facilement intégrable dans l' t:n v iruuut:men L.

Une approche, qui se répand actuellement, est d'élaborer un noyau d'environnement, par exemple le projet Alma [Van 87], ou une structure d'accueil, par exemple la structure Emeraude [Bou 86), qui comprend des composants de base, des outils et des structures génériques. A partir de ce noyau, il est plus facile de se concentrer sur le développement des outils appliquant les méthodes que l'on désire intégrer à l'environnement. Une approche parallèle à celle-ci consiste à réaliser un langage de définition d'environnements. Cette approche est adoptée par Graspin dans le projet Esprit.

3.2.3 Environnements existants

Voici quelques exemples pris parmi la multitude d'environnements existants: AIDES, ARCTURUS, ARGUS, CADES, CDL2, COSY, DELTA, DREAM, SRI, SDEM, SWB, GANDALF, UNJX, PCTE,

!ST AR, INTEGRAL-C, OVERSEE, ADELE, ST ARLITE, A WB-ADE, JASMINE, IDE, OOST, ALMA, MAESTRO, ASSPRO, HDM, STGL, CEDAR. Une description complète est donnée dans [Hun 81], [Bar 84] et [Sde 86]. Nous avons choisi de montrer quelques environnements caractéristiques. Nous présentons les aspects particuliers de chacun d'entre eux.

IDE

IDE [Was 86] est un environnement dont le but est de permettre le développement de logiciel en proposant des outils pour toutes les phases du développement. Pour la phase d'analyse, il fournit un ensemble de méthodes supportées par des outils graphiques.

Les méthodes supportées sont l'analyse par des diagrammes de flots de données (de Marco, Gane et Sarson), la conception par le modèle de données entité-association de Chen, la définition de structures de données selon Jackson, la conception structurée de Yourdon et Constantine, et les diagrammes de transition supportant la méthodologie USE pour le développement d'applications interactives (RAPID/USE). IDE fournit des outils de génération de squelette de code en ADA, C ou Pascal à partir de la conception structurée ainsi que des outils de génération de structure de données à partir des notations de Jackson. La description des projets est contenue dans une base de données. L'interface utilisateur de tous les outils est uniforme.

Un outil de l'environnement, USE, est destiné au développement de système d'information interactif. La phase d'analyse est implantée par une méthode décrivant les flots de données (SSA); le concepteur doit également définir un modèle conceptuel de la base de données. Les dialogues sont représentés par des diagrammes de transition qui permettent un prototypage précoce. La phase de spécification est réalisée au moyen des dialogues, d'une spécification de la base de doMées (Troll) ainsi que d'une spécification des actions du système d'information (formulation axiomatique). Un autre outil, RAPID, permet d'assembler les différentes parties de la spécification afin d'en faire un prototype.

ISTAR

ISTAR [Dow 87] est un environnement de développement de programmes en C, Pascal et Ada. Il permet de couvrir tout le cycle de vie du logiciel et sa principale caractéristique est son extensibilité. L'interface utilisateur est uniforme et graphique. Des outils permettent la spécification et la gestion de projet. L'environnement dispose aussi d'un éditeur générique dirigé par la syntaxe qui permet la programmation dans les langages C, Pascal, CHILL et Ada. ISTAR combine la spécification et la gestion de projet au moyen d'un concept de contrat entre le client et le concepteur. Ce concept est supposé être indépendant de la méthode de développement utilisée. Le système inclut des outils pour la méthode SADT mais d'autres méthodes peuvent être ajoutées.

ASSPRO

ASSPRO [Bid 84] est un environnement de développement de logiciel, interactif, intégré et basé sur une méthode de spécification formelle.

L'environnement ASSPRO comporte une base de connaissances à laquelle accèdent différents outils. Les informations communes à tous les outils sont des spécifications algébriques de types abstraits.

L'environnement est un prototype, ce qui explique que tous les aspects de la gestion du logiciel ne sont pas pris en compte (par exemple la gestion de module, la gestion de version, etc ... ).

La construction d'une spécification algébrique se réalise au moyen de l'outil ASSPEGIQUE. Cet outil permet la production de spécifications dans le langage PLUSS qui compose des spécifications au moyen de primitives d'enrichissement, de renommage, de paramétrisation et d'instanciation. Des outils tels que gestionnaire de bibliothèque, des outils de preuve, un compilateur et un éditeur dirigé par la syntaxe sont disponibles dans ASSPEGIQUE.

D'autres outils vont travailler à partir des spécifications produites par ASSPEGIQUE: SPADA est un outil qui produit un squelette de programme ADA à partir des spécifications. Ce squelette va être complété au moyen d'un éditeur par le programmeur afin de produire un programme ADA. CATY est un outil d'aide à la construction de programme, utilisant une méthode descendante. GATSA est un outil de validation des programmes par des jeux de tests fonctionnels. Cet outil produit des jeux de tests à partir des spécifications et s'assure que l'implantation les vérifie.

ALMA

ALMA [Van 87] est un noyau permettant la construction d'environnements supportant des méthodes spécifiques à l'utilisateur. Les environnements construits sont basés sur la notion de cycle de vie, celui ci étant aussi spécifique à l'utilisateur. ALMA est une collection d'outils indépendants, intégrés par une structure de données basée sur le modèle entité-association de Chen. Le système contient des interfaces qui permettent aux outils d'interagir avec l'utilisateur et la base de doJUlées, de manière uniforme. Des outils de manipulation d'arbres permettent de créer des outils spécifiques aux méthodologies contenues dans l'environnement ALMA est organisé en deux niveaux: le premier niveau, le méta-environnement, contient la description des modèles de cycle de vie et la description des langages dans lesquels les objets logiciels sont décrits, et le deuxième niveau, le niveau d'instance d'environnement, est construit spécifiquement pour des utilisateurs à partir des descriptions contenues dans le méta-environnement. Le méta-environnement décrit quelles sont les informations nécessaires aux outils dans le niveau d'instanciation de l'environnement, ainsi que les objets nécessaires à un cycle de vie

varli~ulit::r.

GANDALF

GANDALF [Hab 86) est un environnement de développement de logiciels en ADA. Il se compose de trois parties: un système de composition et de génération de logiciel, un système de construction incrémentale de programmes et un gestioMaire de projets.

. La philosophie de GANDALF admet que les utilisateurs partagent les infomlations concernant la conception, mais pas les détails de l'implantation. Ils partagent également les états des programmes à travers l'historique du développement. L'ènvironnement aide à la construction du système et procède au test de consistance de la description du système, génère automatiquement des versions, teste la correction syntaxique et

sémantique du logiciel, génère automatiquement le code et maintient la consistance des états du projet.

La création du système de composition et de génération est motivé par des considérations de conception de système, de versions multiples, d'interconnexions de composants, de contrôle des versions et de génération automatique.

Le système de contrôle des versions permet de décrire dans un langage les interconnexions qui existent entre les différents composants.

Les composants sont de deux catégories, les modules et les systèmes. les systèmes étant un ensemble de modules interconnectés. GANDALF contrôle la cohérence et la complétude des interconnexions.

PWB!UNIX

PWB/UNIX (the Programmer's Workbench) [Dol 84] est une adaptation d'UNIX faite dès 1974 chez Bell Laboratories, destinée à servir d'interface entre les utilisateurs et des gros ordinateurs type UNIV AC 1100 ou IBM 370. Sa fonction est d'assumer les tâches interactives de développement de programmes et de soumettre les programmes aux grosses machines. Le choix d'une telle corûiguration est parti de deux constatations: les gros ordinateurs de l'époque ont été conçus pour effectuer du traitement par lots, ils ne sont donc pas adaptés au développement de programmes qui est une activité très interactive. Cette activité demande d'apprendre l'utilisation des outils de développement en plus des particularités de l'environnement d'exécution propre à chaque machine cible. PWB/UNIX diffère du système UNIX traditionnel, entre autre, par une meilleure sécurité au niveau de la protection des fichiers et des fonctions de gestion du système.

Un logiciel de soumission de travaux indépendants de la machine cible est implanté dans PWB/UNIX. Il dispose, en outre, d'un gestionnaire de versions d'ensemble de fichiers (SCCS) ainsi que d'outils traditionnels de traitement de texte et de préparation de documents. Des changements ont été également entrepris dans le shell afin de permettre de créer des procédures de commandes plus complexes, ce qui permet aux utilisateurs de personnaliser PWB/UNIX à leurs besoins. Les auteurs qualifient leur expérience de très fructueuse étant donné le succès rencontré auprès des utilisateurs.

ADELE

ADELE [Est 83, Est 84] est un enviromiement dont le but est de maintenir des versions de programmes pour n'importe quel langage.

Les concepteurs d'ADELE ont pris en compte le fait que

Les concepteurs d'ADELE ont pris en compte le fait que