EM2: ateliers de génie logiciel et qualité du logiciel

Thesis

Reference

EM2: ateliers de génie logiciel et qualité du logiciel

LIGIER, Yves Raymond Louis

Abstract

Le développement et l'assurance qualité du logiciel constituent une importante préoccupation de l'informatique. Nos travaux ont porté sur la conception et la réalisation d'un atelier de génie logiciel, pour lequel nous avons développé des métriques permettant l'évaluation de la complexité et de la qualité du logiciel produit. L'atelier réalisé permet le développement de logiciels à l'aide d'un langage modulaire (MODULA-2), et il assure la gestion des différentes versions d'un logiciel. Cet atelier sert de base à la conception d'un noyau d'atelier qui facilite la réalisation de nouveaux ateliers plus complets. La modularité a marqué une étape importante dans la maîtrise de la complexité du code d'un logiciel, mais les dépendances entre les modules ont amené un nouveau type de complexité. Comme la complexité est un des principaux facteurs de la qualité, nous avons développé des métriques permettant son évaluation. Nous avons séparé ces métriques en deux catégories: intra-modulaires et inter-modulaires.

LIGIER, Yves Raymond Louis. EM2: ateliers de génie logiciel et qualité du logiciel . Thèse de doctorat : Univ. Genève, 1988, no. Sc. 2312

DOI : 10.13097/archive-ouverte/unige:155401

Available at:

http://archive-ouverte.unige.ch/unige:155401

Disclaimer: layout of this document may differ from the published version.

1 / 1

Cf}

N a: z !:!:! Q ~ <..9

1--

-

Cl w _J ~ w UJ ....__ - w u z - a: (.9 w _JO 0 0 LU_J ~ - U::J 1-- (50 a.. w u QLU z _Jr- 0 (/)LU ::J u w CC-<(

LUZ::> -LU i:rlc.9d !<(UJ 1-- Ow

---

--

EM2

ATELIERS DE GÉNIE LOGICIEL QUALITÉ DU LOGICIEL ET

THÈSE

PRÉSENTÉE A LA FACULTÉ DES SCIENCES DE L'UNIVERSITÉ DE GENÈVE

POUR OBTENIR LE GRADE DE DOCTEUR ES SCIENCES 1v1ENTION INFORMA TIQUE

par Yves LIGIER

France de

TIIESE NO 2312

Editée à Genève

LE CONCEPT MODERNE/EDITIONS 1988

professeur associé (Dpt d'Informatique) et /. WILLERS, docteur ès P.

sciences (CERN) autorise l'impression de la présente thèse, _sans exprimer d'opinion sur les propositions qui y sont énoncées.

Thèse NO 2312 Genève le 17août1988

Le Doyen:

Jean-Pierre IMHOF

Impression d'après le manuscrit de l'auteur Copyright by Le concept moderne/Editions Genève -1988

ISBN 2-88242-007-2

Je tiens à remercier le professeur J. Harms qui m'a accueilli au sein du CUI et qui a assuré la direction de ma thèse.

Mes remerciements vont également à I. Willers et P. Zanella qui m'ont fait l'honneur d'accepter d'être membres du jury.

Je tiens à exprimer ma plus sincère reconnaissance à P. Zanella pour les encouragements qu'il m'a prodigué tout au long de nombreux week-ends.

Je suis reconnaissant aux professeurs B. Levrat et C. Pellegrini pour leur attention bienveillante.

Je remercie les personnes (collègues et étudiants) qui ont participé au développement du projet EM2 et, en particulier, D. Buchs avec qui j'ai partagé ces années de travail.

Remerciements également aux membres du CUI, et plus spécialement à JJ. Snella, dont les discussions m'ont apporté un soutien certain.

Je remercie les membres de ma famille et mes amis qui ont su maintenir mon moral au beau fixe.

Merci à Dominique. Merci à Tom.

PARTIE 1

Chapitre 1 INTRODUCTION ... ... ... 2

Chapitre2 2.1 2.2 2.3 2.4 2.5 LE GENIE LOGICIEL ... 4

Introduction ... .... ... 4

Historique et évolution ... ... 6

Les buts du génie logiciel.. ... 9

Le cycle de vie ... ... 11

Notre modèle de cycle de vie ... 14

Chapitre 3 LES ENVIRONNEMENTS ET LES METHODES DE DEVELOPPEMENT DE LOGICIEL ... 20

3.1 Qu'est-ce qu'on attend d'un environnement? ... 20

3.1.1 Activité administrative ... 21

3.1.2 Activité de production ... 21

3 .2 Classification et exemples d'environnements ... 22

3.2.1 Classification des environnements ... 22

3 .2.2 Stratégies de développement d'un environnement ... 24

3.2.3 Environnements existants ... .. ... 27

3.3 Perspectives futures ... 31

3.3.1 Perspectives à moyen terme ... 32

3.3.2 Problèmes spécifiques ... 33

3.3.3 Problèmes de l'utilisation du génie logiciel ... 35

3.4 Concepts et méthodes de développement ... 36

3.4.1 Introduction ... 36

3.4.2 Les concepts ... ... 37

3.4.3 Exemples de méthodes semi-formelles ... 40

3.4.4 Exemples de méthodes formelles ... 43

4.2 Objectifs ... 47

4.2.1 Cohérence ... 47

4.2.2 Extensibilité ... 48

4.2.3 Interface utilisateur ... ... 48

4.2.4 Couverture du cycle de vie ... 48

4.3 Concepts de EM2 ... 49

4.3 .1 Structure et représentation des do!lllées ... ... 49

4.3.2 Objet ... ... ... 50

4.3.3 Modules ... 50

4.3.4 Versions ... 51

4.3.5 Projets ... ... 53

4.3.6 Utilisateurs ... 53

4.3.7 Graphe des dépendances modulaires ... 54

4.3.8 Principe de recompilation ... 56

4.4 Conception ... 56

4.4.1 Partie comprenant les outils et l'accès aux données .. 58

4.4.2 Gestion des données ... 59

4.4.3 Description d'un SGBD nécessaire à nos besoins ... 59

4.4.4 Interface utilisateur ... 62

4.5 Implantation ... 63

4.5.l Base de données ... 63

4.5.2 Gestionnaire de listes ... 66

4.5.3 Choix du langage MODULA-2 ... 66

4.5.3 Interface utilisateur. ... 69

4.6 Utilisation ... 71

Chapitre 5 EVOLUTION DU PROJET EM2 ... 72

5.1 Le noyau EM2 ... 72

5 .1.1 Introduction ... , .... ... ... 7?.

5.1.2 Objet .... ... 74

5.1.3 Liens entre objets ... 74

5.1.4 Outils génériques ... 75

5.1.5 Gestionnaire de versions ... 75

5.1.6 Méta-base ... 77

5.1.7 Vérification ... ... 78

5.1.8 Validation ... 79

5.1.9 Base de données ... 80

5.2 Environnement proposé ... ... 81

5.2.1 Phase d'analyse ... 81

5.2.2 Phase de spécification ... ... 81

5.2.3 Phase d'implantation ... ,., ... , ... 83

5.3 Perspectives d'implantation ... 84

5.3.l Implantation du noyau ... 84

5.3.2 Implantation de l'environnement du projet EM2 ... 84

Chapitre 6 6.1

6.2

Chapitre 7 7.1

7.2

Chapitre 8 8.1

8.2

8.3 8.4

EVALUATION DE LA QUALITE DU LOGICIEL.. ... 87

Qualité ... 87

6.1.1 Introduction ... 87

6.1.2 Définition ... 87

6.1.2 Evaluation de la qualité ... 89

6.1.3 La complexité ... 91

Qualité et modularité ... 92

6.2.1 Définition ... 92

6.2.2 Cohésion ... 96

6.2.3 Couplage ... 100

6.2.4 Graphe des modules ... 103

6.2.5 Critères de modularisation ... 104

6.2.6 Complexité et modularité ···:···106

QUALITE INTRA-MODULAIRE ... 107

Les métriques ... 107

7 .1.1 Introduction ... 107

7.1.2 Taille ... 108

7.1.3 Structures de contrôle ... 111

7.1.4 Flots et structures de données ... 124

7.1.5 Autres types de métriques ... .127

7.1.6 Synthèse ... 128

La métrique EM2/Complex ... 130

7 .2.1 EM2/Complex ... 130

7 .2.2 Implantation ... 136

7.2.3 Conclusion ... 138

QUALITE INTER-MODULAIRE ... 139

Les métriques ... 139

8.1.1 Introduction ... 139

8.1.2 Exemples de métriques ... 140

La métrique EM2/Complex ... 144

8.2.1 But de EM2/Complex ... 144

8.2.2 Liens entre deux modules ... 145

8.2.3 Structure du graphe des dépendances modulaires ... 149

Restructuration ... 160

Réalisation ... ... 162

8.4.l Matrice des dépendances ... 162

8.4.2 Base de données et interrogation ... 167

8.4.3 Restructuration ... 170

8.4.4 Conclusion ... 170

9 .1 Introduction ... 171

9.2 Exemples d'outils ... ... 171

9 .3 EM2/Complex .... : ... 173

9 .4 La notion de qualité dans EM2 ... 17 5 Oiapitre 10 CONCLUSION ... 178

BIBLIOGRAPHIE PARTIE I. ... 180

BIBLIOGRAPHIE PARTIE Il ... 187

ANNEXF. 1 ... ... ... ... 194

ANNEXE 2 ... 196

ANNEXE 3 ... 203

INTRODUCTION

EM2 est un projet de développement d'Atelier de Génie Logiciel réalisé au CUJ (Centre Universitaire d'Informatique) de l'Université de Genève. Ce projet a vu le jour en 1983 par la parution d'un article [Fal 83) de Falquet G., Guyot J. et Nerima L. ù1titulé EM2 : un environnement pour MODULA-2 .

Ce travail se base sur des considérations pragmatiques sur les besoins d'un environnement de programmation pour les langages modulaires et en particulier pour MODULA-2. A partir d'un premier prototype, nous avons approfondi les concepts de base ainsi que les caractéristiques architecturales d'un environnement, et nous avons développé des outils généraux pouvant faciliter l'implantation et l'évolution d'un environnement. Nous avons alors réalisé un nouveau prototype opérationnel de EM2 [Buc 85), pour lequel nous avons développé, entre autre, un petit outil de gestion de base de données en mémoire centrale, des outils génériques qui ont permis de réaliser un interface utilisateur agréable, et un système de gestion des utilisateurs. Le projet entier a gardé le nom EM2, bien que le domaine visé soit beaucoup plus large qu'au début du projet, la signification suivante du sigle EM2 étant plus réaliste: Environnement de développemem de logiciel pour langages Modulaires avec wze implantation pour MODULA-2.

Des travaux de Jicence et de diplôme ont apporté une contribution au développement de EM2. Ainsi, le premier prototype développant les stratégies de base, a été le sujet de mémoire d~ diplôme de D. Bucbs. On peut également citer d'autres travaux qui onr permis de réaliser un gestionnaire d'objets et un outil de mesure de complexité de modules.

Nos recherches en génie logiciel nous ont amenés à affiner les choix concernant les buts à atteindre par un tel environnement. Nous avons alors décidé de poursuivre des directions de recherche personnelles, ce qui permet de couvrir une plus large part du cycle de vie du logiciel, en tenant compte de l'analyse des besoins (L. Nerima), des spécifications (D. Buchs) et de la qualité des logiciels (Y. Ligier). Dans une phase ultérieure, l'intégration de ces différents travaux nécessitera la réalisation d'un nouveau prototype.

Le présent document se compose de deux parties. La première montre le projet EM2 dans son ensemble et décrit le prototype réalisé.

Cette partie est issue d'une collaboration entre D. Buchs et Y. Ligier: le texte résultant est donc commun aux deux rapports de thèse. La deuxième partie développe plus profondément un aspect de la qualité du logiciel: la complexité propre à un logiciel modulaire.

Cet ouvrage se compose de dix chapitres; les cinq premiers constituent la première partie et les cinq derniers la deuxième partie. Le premier et présent chapitre montre le contenu et la motivation de ce travail. Le deuxième donne un aperçu des différents aspects du génie logiciel. Le troisième traite des environnements et des méthodes prônées par ces environnements. Le quatrième présente le prototype du projet EM2: ses concepts et sa réalisation. Le cinquième chapitre montre l'évolution du projet EM2.

Avec le sixième chapitre, on aborde la seconde partie de cet ouvrage qui traite du problème de la qualité d'un logiciel modulaire. Le septième chapitre montre les métriques de EM2 peanettant d'évaluer la complexité intra-modulaire d'un logiciel. Le huitième chapitre aborde les métriques permettant d'évaluer la complexité inter-modulaire. Le neuvième chapitre montre la gestion de la qualité dans les environnemencs et en particulier dans EM2. La conclusion constitue le dixième et dernier chapitre.

LE GENIE LOGICIEL

2.1 INTRODUCTION

De tout temps, l'homme a essayé d'automatiser et de systématiser ses tâches, en développant des méthodes et en se créant des outils, généralement dans un but de rendement, mais aussi dans un but d'innovation ou de distraction. Un des derniers outils développés est l'ordinateur.

Pour pouvoir utiliser un ordinateur à notre convenance, on doit se fabriquer encore des outils qui sont les programmes. Après une phase où ces outils étaient créés artisanalement, on essaie maintenant de s'appuyer sur une approche méthodologique, ce qui a donné naissance au domaine du génie logiciel.

Le génie logiciel consiste à appliquer des méthodologies, c'est-à- dire à développer et à utiliser des méthodes et des outils dans le but de produire le meilleur logiciel possible à un moindre coût.

Dire d'un logiciel qu'il est le meilleur possible, sous-entend qu'on puisse le comparer à d'autres logiciels selon certains critères. Panni les critères les plus importants, on trouve l'adéquation, la fiabilité, l'efficacité et l'évolutivité. Dans la pratique, on a un problème pour représenter formelle.ment ces qualités, et il est très délicat de comparer deux logiciels car il est difficile d'évaluer l'application de ces critères. On connait donc les qualités que l'on aimerait trouver dans un logiciel, mais on ne sait pas encore comment y parvenir de manière systématique et on ne sait pas non plus comment évaluer précisément si un logiciel a de telles qualités.

Le développement d'une grande application est, sans nul doute, une affaire extrêmement complexe. Il suffit de regarder le nombre de personnes qui travaillent à maintenir des logiciels, ce qui traduit bien souvent le fait que le logiciel produit ne satisfait pas complètement les exigences initiales. C'est la phase de maintenance qui pennet l'ajustement.

Le développement d'une grande application est un processus complexe qui fait intervenir des aspects de gestion de personnel, de

gestion de planning et plus important, de gestion du développement proprement dit. Plusieurs problèmes, pour lesquels des méthodes adéquates n'ont pas encore été trouvées, rendent ardue la tâche de développer des grands logiciels:

- Comment peut-on diviser le travail et le répartir dans une équipe de personnes.

- Comment gérer la communication entre les personnes d'une équipe ou entre les équipes, avec entre autres, le problème de transfert des connaissances qui se pose lors de changements de personnes.

- Le problème de la relation entre client et concepteur est aussi un problème de langage, ce qui équivaut à essayer de trouver une transformation de l'infonnel vers le formel. On retrouve là le problème de base de l'informatique qui doit, à l'aide d'un langage rudimentaire, exprimer des idées.

- Il ne faut pas oublier le problème de l'éducation, car en une seule génération humaine, plusieurs générations d'ordinateurs et de logiciels ont vu le jour, offrant à chaque fois des capacités nouvelles que l'on ne maîtrise pas encore (il faut du temps pour assimiler).

- Le problème le plus complexe reste encore celui lié au développement du logiciel. Comment produire du logiciel fiable, de bonne qualité et à un moindre coût: c'est le problème fondamental pour lequel le génie logiciel essaye d'apporter des solutions.

La discipline dn génie logiciel est encore dans sa prime jeunesse, il lui reste énormément de méthodes à découvrir, d'outils à fabriquer jusqu'a ce que la producrlon de logiciel suit ùeveuut: w1 vrncessus automatique et systématique. Parmi les nombreux ouvrages traitant du génie logiciel, nous ne citerons que [Mac 87) et [Fre 77) qui pennettent de comprendre de manière satisfaisante ce qu'est le génie logiciel.

2.2 HISTORIQUE ET ÉVOLUTION

Le génie logiciel est un domaine encore peu exploré: la première conférence ayant eu pour thème le génie logiciel eut lieu en 1968. Le problème du génie logiciel se schématise sous la forme suivante: comment automatiser et sytématiser la traduction de la pensée humaine en code machine. Au début de l'ère des ordinateurs, l'homme se contentait de représenter des idées simples telles que des opérations arithmétiques. Puis il a essayé de développer des projets plus importants comportant des traitements et des données plus complexes, jusqu'à arriver aujourd'hui à des projets de très grande taille, tel que celui connu sous Je nom de projet de guerre des étoiles qui est estimé à environ 10 ou 100 millions de lignes de code source.

L'historique du génie logiciel peut être résumé de la façon suivante, en indiquant quels ont été les faits marquants au cours de ces quelques décennies.

- 1945: La programmation s'effectue en code binaire et ensuite en assembleur, mais seul celui qui développe est capable de comprendre et de maintenir son projet. Les projets sont alors de petite taille.

- 1955: Apparition et utilisation de langages évolués qui permettent de développer des projets plus importants.

- 1965: C'est la crise du logiciel. On se rend compte que l'intuition ne suffit plus pour développer correctement du logiciel.

- 1968: Première conférence sur le génie logiciel.

- 1970: Définition de la notion de programmation structurée: suppression de l'utilisation du GOTO, structuration du code en plusieurs niveaux hiérarchiques [Mil 86].

- 1972 : Développement des méthodes de preuves de programmes (difficiles à appliquer à de grands logiciels).

- 1975: On se rend compte que développer un projet ne consiste pas seulement à le coder mais à le comprendre, le spécifier et le concevoir en des étapes successives, d'où apparition de la notion de cycle de vie et essais de développement de méthodes adaptées à ces phases.

- 1980: Après avoir développé des méthodes et des outils de manière isolée, on les rassemble pour former des environnements homogènes. On prend aussi conscience de l'importance des premières phases dans le coût de développement d'un projet.

n

semble logique qu'une erreur de conception soit moins coûteuse à corriger lors de la conception que lors d'une phase suivante, comme l'implantation ou la maintenance.

1945

50

55

60

65

70 75 1

BO

85

XX

yy

Evolution

lrèu1lll .. 1lon absllnctlon typos absVaila modulatit6 g6n61lcl!6

'

langage mach~

1

1ymbollt.me

mécanisme d'inférence

Figure 2.1 : Illustration de l'évolution (passée, présente et future) du génie logiciel

Dans la figure 2.1, nous présentons l'évolution du génie logiciel sous fonne d'un graphe. Les noeuds de ce graphe correspondent à des outils (bien souvent des langages) qui ont marqué chaque grande étape de développement Les flèches indiquent les principaux problèmes et sujets de réflexions qui ont conduit à la création de ces nouveaux outils.

Cette figure montre les différentes approches qui ont eu lieu, qui ont lieu et qui auront (peut-être) lieu. On remarque d'abord les différences d'approche qui ont amené les premiers langages de haut niveau, et qui sont dûes principalement au domaine d'utilisation visé par chacun de ces langages. Les problèmes numériques scientifiques sont à l'origine du langage Fortran, les problèmes de manipulation de grands volumes de données sont à l'origine du langage Cobol et Jes problèmes de manipulation de connaissances sont à l'origine du langage Lisp. Les divergences entre ces trois approches se sont perpétuées au cours des quelques vingt années suivantes, chaque approche ayant ses propres problèmes. La première approche a donné lieu aux langages de programmation traditionnels, préoccupés principalement par des problèmes de rendement (en fonction du coût) et de qualité du logiciel.

Les principes de base de cette approche sont modularité et types abstraits.

La deuxième approche a donné lieu aux systèmes de gestion de base de données et plus généralement aux systèmes d'information, dont une des bases théoriques est le modèle relationnel. La troisième et dernière approche a donné lieu aux langages d'intelligence artificielle ayant pour base la logique et fournissant une sémantique plus riche que dans les autres langages, facilitant ainsi la réalisation d'outils tels que les systèmes experts.

Depuis quelques années apparaissent des tentatives de convergence entre ces approches [Gal 86), reflétant le fait que les projets actuels sont vastes et couvrent plusieurs domaines. Les bases de connaissances illustrent cette convergence puisqu'elles réunissent les principes des systèmes de gestion de bases de données (SGBD), le principe d'inférence des langages d'intelligence artificielle et les principes de modélisation et de structuration des langages de prngrammation traditionnels. Une autre convergence entre les langages de programmation traditionnels et les langages d'intelligence artificielle a permis à une nouvelle approche: les langages orientés objet.

La base théorique de ces domaines a donc tendance à s'unifier, par la logique selon [Gal 86]. La programmation conventionnelle va évoluer vers la programmation logique qui s'appuie sur la description de la structure logique des problèmes au lieu de la description de la façon dont l'ordinateur doit les résoudre. Ceci n'implique pas forcément l'existence d'un langage unique mais diminue les frontières existant entre les différentes approches. Le langage universel n'est certainement pas le but à

atteindre, il vaut mieux instruire les infonnaticiens de tous les principes de base et leur fournir des outils adaptés à leurs besoins et non pas un outil trop général difficilement utilisable. On peut noter que le couteau suisse est l'exception qui confirme cette règle.

Paralèllement à cette évolution, on assiste depuis peu à un développement de langages de conception et de langages de spécification qui devraient pennettre de diviser l'écart existant entre le langage humain et les langages de programmation existants. Ces langages devraient s'accompagner ensuite de compilateurs générant du code dans un langage de plus bas niveau, mais ceci fait encore partie du futur, ce qui prouve bien que le génie logiciel n'a pas résolu tous les problèmes.

2.3 LES BUTS DU GÉNIE LOGICIEL

La volonté d'utiliser l'informatique comme outil de tous les jours implique un besoin de production de logiciels. Cette production de logiciel était et reste encore, artisanale. Actuellement, face à la grande demande en logiciel fiable et peu coateux, le besoin de passer à une production industrielle se fait sentir. Les buts du génie logiciel vont dans le sens d'une réduction des coûts de production, de maintenance et d'utilisation du logiciel. Ces trois aspects sont différenciés selon un point de vue temporel.

Dans le paragraphe 2.4 nous traiterons de ces aspects selon un point de vue fonctionnel (le développement et la maintenance sont étroitement liés).

Pour maîtriser le développement et réduire les coûts, le génie logiciel propose des méthodes (façon de faire quelque chose), des outils (programmes, langages et formulaires de documentation qui peuvent aider à utiliser une méthode) et des méthodologies (gestion et application d'un ensemble de méthodes et d'outils). Chaque méthodologie est

applicahl~ à w1 ùumaioe d'utilisation particulier, ceci pnr ln nnture de &ec méthodes et des fonctionnalités offertes par les outils qui la composent. La nature de l'amélioration dépend du contexte d'utilisation du logiciel (par exemple: pour un logiciel peu utilisé on ne se préoccupera pas trop des coûts d'utilisation). La nature de la réduction des coûts va nécessiter de définir des objectifs pour la réalisation d'un logiciel (voir la figure 2.2).

La notion de coût doit être considérée dans un sens très général.

Exemple:

Si nous prenons l'exemple d'un logiciel tel qu'un tableur, nous pouvons admettre que ce logiciel doit avoir un coût d'utilisation faible, donc les objectifs lors du développement seront, qualité-fiabilité, ergonomie, efficacité, portabilité.

Les objectifs fixés sont atteints seulement si certains principes sont suivis (figure 2.2). Chaque méthodologie privilégie certains principes et

son choix va donc dépendre des objectifs visés. Ce choix sera certainement un compromis, car aucune méthodologie ne va couvrir tous les principes devant être suivis. L'évaluation de la qualité du logiciel se fera par la mesure des attributs de chacun des principes. L'évaluation du coût est aisée, par contre les prévisions de coût sont excessivement difficiles étant donné les très grandes interdépendances existant entre les principes, ce qui conduit à une forte non-linéarité des mesures. La prévision des coûts est néarunoins nécessaire pour décider si le projet est réalisable ou non.

~ ~ ~ ^Allrlbut1

Malnlenence

UllllH l lOl"I

Figure 2.2 : Relations entre coûts, objectifs, principes et attributs

Pour aider à comprendre le sens de la figure 2.2 nous donnons ici une définition succincte des termes utilisés [Hen 85).

concernant les objectifs: les termes utilisés sont largement répandus et leur interprétation est commune à tout un chacun.

concernant les principes:

Abstraction : mécanisme qui permet de présenter un contexte en exprimant les éléments pertinents et en omettant ceux qui ne le sont pas.

Documentation : gestion des documents incluant leurs identification, acquisition, production, stockage et distribution.

Généralisation : regroupement d'un ensemble de fonctionnalités semblables en une fonctionnalité paramétrable (généricité, héritage [Mey 86J).

Modularité : décomposition d'Wl logiciel en composants discrets.

Structuration : façon de décomposer le logiciel (utilisation d'une méthode top-down, bottom-up ).

Vérification : détermination du respect des besoins établis dans la phase précédente du cycle de vie.

- concernant les attributs :

Types abstraits : une classe de données caractérisée par les membres de

Cohésion:

Complexité : Couplage : Extensibilité : Lisibilité :

cette classe et les opérations qui peuvent y être appliquées.

mesure du degré de dépendance fonctionnelle entre les tâches rc>.a füées par un module.

degré de complication d'un système (Halstead, McCabe ... ) [Har 82).

mesure des interdépendances entre modules.

degré d'accomodation aux changements produits par une nouvelle exigence à satisfaire.

difficulté à comprendre un composant logiciel (lié à la complexité et à la documentation).

Visibilité du comportement : représente la possibilité de se rendre compte de façon aisée de ce que font les djfférentes fonctionnalités d'un programme.

2.4 LE CYCLE DE VIE

La notion de cycle de vie (datant de 1970) tBoe 82J résulte de la prise de conscience du fait que le développement de logiciel n'est pas simplement un processus de programmation variant de quelques heures à quelques jours. C'est un processus beaucoup plus complexe auquel on applique le vieil adage bien connu Divise, a.fin de régner, qui permet de le maîtriser en le divisant ^~n sous-processus.

La vie du processus de développement de logiciel débute à l'analyse du problème et dure tant que le logiciel est maintenu en exploitation.

Pendant l'étape de maintenance, le logiciel peut être amené à évoluer selon les besoins, auquel cas on recommence un petit processus de développement pour réaliser les modifications. L'expression cycle de vie est donc une bonne illustration du processus de développement d'un 'logiciel.

Le cycle de vie du logiciel est le processus complet du développement (création) et de l'utilisation (maintenance) du logiciel.

Selon un aspect temporel, le cycle de vie se décompose en deux grandes phases: la construction et la maintenance du logiciel. La maintenance permet une utilisation optimale du logiciel et donne lieu à des phases de construction de peu d'importance. Théoriquement, cette phase doit entraîner une tâche minime, constituée de petites modifications évolutives. Pratiquement, c'est la phase qui coûte le plus cher, non parce que c'est la plus longue, mais parce que les phases précédentes n'aboutissent pas toujours complètement à ce qu'elles devraient. La cause de ces inadéquations est le manque de méthodologies existantes adaptées à

ces phases. ·

La création d'un logiciel consiste à traduire en langage machine, des idées exprimées en langage naturel, ce qui est une tâche difficile vu la différence de niveau sémantique de ces deux langages. La méthodologie adoptée consiste à faire des étapes in.tennédiaires à l'aide de langages de niveau sémantique intermédiaire et ainsi d'effectuer des traductions entre des langages beaucoup moins distants sémantiquement, ce qui est illustré par la figure 2.3.

Langage nelurel

Niveau sémantique des langages

Spéclllcatlona

(code machine)

Figure 23 : Décomposition de la phase de construction d'un logiciel

La sémantique d'un projet doit être conservée tout au long de ces étapes, seule la quantité d'infonnation nécessaire à sa représentation augmente quand le niveau sémantique des langages diminue. Il existe des méthodologies pour les traductions des langages proches du langage machine. Elles comprennent des méthodes (par exemple, la programmation structurée) et des outils (par exemple, les compilateurs) adaptés, mais cette étape est la plus facile à réaliser. Chaque étape suivante est d'une complexité supérieure à l'étape précédente (à cause du niveau sémantique croissant).

Plusieurs modèles de cycle de vie existent, mais le plus couramment adopté [Boe 78) comporte les phases suivantes:

~ Analyse du problème et des besoins : dialogue entre le client et le concepteur pour produire l'ensemble des fonctionnalités désirées et les contraintes à respecter. On essaie d'arriver à une compréhension totale du problème.

-Spécification : étape de formalisation (à l'aide d'un langage formel) des données précédentes, les fonctionnalités et les contraintes.

-Conception: définition de l'architecture du logiciel (en modules par exemple) ainsi que des principales structures de données.

Etablissement des principaux algorithmes.

-Implantation : codage dans un langage de programmation.

-Validation : installation du logiciel et test d'acceptance par le client.

-Maintenance : phase consistant à corriger d'éventuelles erreurs et à effectuer des modifications au gré des nécessités.

Le modèle de cycle de vie proposé décrit l'aspect fonctionnel du développement du logiciel. D'autres aspects, tel que la gestion des membres d'une équipe, ont aussi une grande importance. En effet, une équipe est organisée hiérarchiquement et chaque membre doit assumer un certain nombre de tâches spécifiques. On trouve, par exemple, un chef de projet et des programmeurs. On peut noter que l'équipe doit comporter un responsable chargé de diviser et répartir les tâches entre les groupes, de vérifier leur avancement et de les coordonner. Elle doit comporter aussi un rapporteur qui assure la documentation de l'ensemble en participant à tous les groupes de travail.

2.5 NOTRE MODELE DE CYCLE DE VIE

Comme base de l'approche suivie dans le projet EM2, nous avons fonnalisé un modèle de cycle de vie, nous vous le présentons maintenant.

Ce modèle illustre bien comment s'effectue actuellement Je développement de logiciel (voir les figures 2.4 à 2.8). Les différentes étapes sont décrites à l'aide du formalisme SADT (Structured Analysis and Design Technique) [Ros 77a, Ros 77b], qui pennet de donner une description plus précise et plus claire qu'un long texte.

Pour le lecteur ne connaissant pas SADT, nous rappelons qu'un diagramme SADT se compose d'un certain nombre de boîtes représentant une activité pour laquelle on indique quelles sont les données d.'entrée (flèches de gauche), les données de sortie (flèches de droite), les contrôles qui s'exercent sur cette activité (flèches du haut) et les mécanismes qui permettent de la réaliser (flèches du bas). Une description plus approfondie est donnée dans le paragraphe 3.4.3.

Dialogue entre

concepteur et client Concepteur Désirs el

contraintes

client -+

Composants réutilisables

Développer un logiciel

f

Produit logiciel

Environnement de développement de logiciel

Noeud : A-0 Titre : Cycle de vie du logiciel

Figure 2.4: Activité générale du développement de logiciel

L'activité de développement d'un logiciel consiste à produire un logiciel à partir des désirs et des contraintes d'un client en essayant d'utiliser des composants réutilisables prévus à cet effet. Le développement s'effectue sous contrôle du concepteur et du dialogue avec le client. Pour s'aider, Je concepteur dispose d'un environnement de développement de logiciel fournissant des outils plus ou moins efficaces.

Dialogue enb'e Concepteur concepteur et

Désirs el contraintes

client

client ar

Fonctionnalités détaillées Sémantique informelle DosctloUon

ComplSants . . • I

réu1l11sablo• 1 ' 1 Maintenance

Maintenance

Contraîntos Principes

Perractiva 1 Archilecture lmplnma1lon

Environnement de d6viiloppemont du logiciel

Malnlilnanco adapta live évolutive perfec::tive

Noeud: AD Titre : Cycle de vie du logiciel Contexte :

Produit logiciel

Figure 2.5: Différentes phases de notre modèle de cycle de vie La figure 2.5 montre que le modèle de cycle de vie, adopté dans le cadre de notre travail, comporte essentiellement trois grandes phases:

l'analyse, la spécification et l'implantation. La différence majeure par rapport au modèle classique est l'absence vuluntaire ùe la pllase ùe conception. Ceci est dû au fait que la conception est une étape pouvant se décomposer en 2 sous-étapes consistant en une conception globale (servant à définir l'architecture du système logiciel) proche de la spécification et une conception détaillée proche de l'implantation. L'évolution des outils nous montre que la phase d'implantation sera de plus en plus automatisée ainsi que l'étape de conception détaillée, ce qui nous pousse à les regrouper en une seule et même phase. Le regroupement de la spécification et de l'analyse globale nous a paru de la même manière logique étant donné le caractère artisanal

La phase d'analyse (figure 2.6) est réalisée sous le contrôle du client et du concepteur qui n'ont comme aide que leurs propres expériences (monde client, monde informatique) avec toutes les difficultés de compréhension dues aux manques d'outils. Il existe néanmoins des outils tels que SADT qui permettent de transcrire le problème de manière un peu plus formelle.

Dialogue enlre

Concepteur client et concepteur

Maintenance

,

.Conlrainles ....

1

contre in tes _à)

' ~ '

CoOI

ri

1

Mainlenance r

11

Compléter et adapter

~ les fonctionnalités

J

Désirs

-

(foncllonnalll6s)

•

Base de connaissances

~ ~

Modèle de Langage d'analyse _

di!pendance Monde lnformatîque Vérifier

des coOts Monde client

Environnement Correcllon

•

matériel et loglelol

1 -

1

Environnement de développement de logiciel

Contexte :

~

Noeud: A1 Titre : Phase d'Analyae

du cycle de vie duloglciel AO

Figure 2.6: Phase d'Analyse du cycle de vie du logiciel

Tout au long de ces phases on applique le principe d'essai-erreur, qui consiste à essayer jusqu'à ce que le résultat soit validé. Evidenunent, les essais ne sont pas effectués à l'aveuglette, mais sont réalisés de façon optimale grâce aux méthodes utilisées (exemple: phase de construction de la spécification dans la figure 2.7 où l'on utfüse une méthode de spécification de types abstraits).

Dans la phase d'analyse, ceci se traduit par le raffinement des fonctionnalités qui peut entrainer aussi un raffinement des contraintes et des principes.

Composants réutilisables

Principes Contrainles

1

Concepteur

Maintenance _..., Construira IH Fonctfonnalhds--. spé clfl cati an•

Correction

Dialogue client concepteur

Spdclllcalions

Maintenance

'--+---11-l•IProtatypar 1 • ~

Noeud: A2

Langage de 1 Démonstrateur

spécllication formel ^Modèle de

validation ^Modèle d•ox&cu1ton

Envlroi111ur1111111 oo lltivuluppoment d8 logloiol Titra : Phase de Sp6clflcotlon Contexte :

du cycle da vie du loglclel AO

m-

Figure 2.7: Phase de Spécification du cycle de vie du logiciel Les phases de spécification et d'implantation (figures 2.7 et 2.8) sont construites sur le même modèle, la première étant réalisée de manière artisanale alors que la deuxième tend à devenir automatique. Les essais lors des phases de spécification ou d'implantation sont approuvés ou rejetés pendant l'étape de vérification (qui consiste à vérifier la construction interne à une phase) ou pendant l'étape de validation (qui consiste à vérifier que le produit correspond à la demande du client).

Maînlananoo corrective

Noeud: A3

Principes Contraintes Concepteur

1

LN.gage de programmation

Vérifier

Vérificalion de programme

Client

Produil logiciel

Malntenance adaptlva ou porleclfilo Environnement

-

d'exécullon

Envlromemenl de dôvoloppemont de logiciel

Titre : Phase d'lmplontallon du cycle de vie du loglclel

Contexte:~

AO ~

Figure 2.8: Phase d'implantation du cycle de vie du logiciel Deux aspects du développement du logiciel n'apparaissent pas ou peu sur ces différents diagrammes, et pourtant ils occupent une place importante. Ce sont le prototypage et la maintenance.

Prototypage

Le prototypage consiste à essayer de donner un aperçu du comportement du produit fmal en un temps relativement court permettant d'aider à la compréhension du problème et de décider de la faisabilité du produit. Deux types de prototypage sont possibles [Cho 85): soit on réalise un prototype implantant complètement un petit nombre de fonctionnalités (prototypage vertical), soit on essaie d'avoir une vue d'ensemble des fonctionnalités (prototypage horizontal). Ce qui se traduit sur le modèle de cycle de vie par deux possibilités: ou bien on effe.ctue toutes les phases pour un petit nombre de fonctionnalités, ou bien on n'effectue qu'un nombre limité de phases pour toutes les fonctionnalités. Un prototype peut

être réalisé très tôt dans le cycle de vie grâce aux méthodes produisant des spécifications exécutables.

Un prototype, très utile et facilement réalisable, est celui de l'interface utilisateur qui facilite grandement la communication entre Je concepteur et le client. En effet, l'interface utilisateur est le meilleur moyen de donner, au client, une idée du produit final. C'est certainement un des seuls moyens de communication; il n'est pas envisageable de doilller au client la spécification du produit en termes de spécifications algébriques, par exemple. De plus, ce prototype peut être réalisé très tôt dans le cycle de vie du logiciel, lors de la phase d'analyse.

Maintenance

Le modèle de cycle de vie correspond au développement (création+

maintenance) du logiciel, il est donc valable pendant toute la durée de vie du logiciel et on voit sur les différentes figures que la maintenance permet d'apporter des corrections, des modlfications ou des adaptations. Par conséquent, différents types de maintenance existent [Gia 83]: les maintenances corrective, adaptative, perfective et évolutive. La maintenance corrective consiste à corriger les éventuels défauts résiduels du logiciel. La maintenance adaptative consiste à modifier les interfaces du logiciel avec son environnement, pour tenir compte des évolutions de ce dernier. La maintenance perfective consiste à améliorer le fonctionnement du logiciel, sans toutefois modifier les missions spécifiées.

La maintenance évolutive consiste à modifier les missions spécifiées du logiciel.

LES ENVIRONNEMENTS ET LES METHODES DE DEVELOPPEMENT DE LOGICIEL

Dans ce chapitre, nous allons nous intéresser aux environnements et aux méthodes de développement de logiciel. Le premier paragraphe est consacré aux caractéristiques générales d'un environnement, le deuxième donne un aperçu général des environnements existants, le troisième nous montre les concepts et les méthodes généralement disponibJes dans ces environnements et le quatrième et dernier paragraphe est consacré à l'évolution des environnements.

3.1 QU'EST-CE QU'ON ATTEND D'UN

ENVIRONNEMENT?

Le rôle d'un environnement consiste à supporter et à guider le développement de logiciel. Le tenne de développement doit être pris dans un sens très large: c'est-à-dire de la création jusqu'à l'arrêt de la maintenance du logiciel.

Un environnement est un ensemble d'outils et de méthodes permettant de développer du logiciel de bonne qualité. Cet ensemble se caractérise, entre autre, par son domaine d'application et par les liens entre ses éléments. Nous allons étudier ces différentes caractéristiques dans ce chapitre.

Les premiers logiciels étaient réalisés par un seul homme qui ne disposait que de peu d'outils: il s'agissait principalement d'un assembleur ou d"un compila~eur. On ne parlait pas d'environnement à cette époque, mais on peut considérer que les premiers outils formaient déjà un environnement. Depuis, les logiciels permettent de résoudre des problèmes beaucoup plus complexes, et leur développement résulte d'un travail d'équipe. La panoplie d'outil~ disponibles s'est largement étoffée, et les environnements sont devenus indispensables au développement de logiciel.

Un environnement doit aider à la gestion et à la production de logiciel. On distingue deux grands types d'activités: une activité administrative et une activité de production.

3.1.1 Activité administrative

L'activité administrative comporte la gestion d'équipe et la planification.

La gestion d'équipe

La gestion d'équipe [Lie 85] consiste à définir les tâches et les responsabilités, c'est-à-dire le rôle de chaque membre de l'équipe. Une équipe se compose généralement d'un administrateur-superviseur, de chefs de projet, de programmeurs et d'un rapporteur. Cette équipe est structurée hiérarchiquement avec l'administrateur en tête, viennent ensuite les chefs de projet qui ont la responsabilité d'un sous-projet, chacun d'eux dirigeant un groupe de programmeurs. Le rapporteur a un rôle un peu particulier, puisqu'il s'occupe de la gestion des informations entre les groupes.

La planification

La planification [Fai 85] consiste en la création et le suivi des plannings des différentes tâches à effectuer. Ce travail est attribué à l'administrateur-superviseur. Il comporte des aspects administratifs tels que l'établissement d'un échéancier, l'organisation de l'équipe ainsi que des aspects plus techniques tels que le choix de la stratégie de résolution à adopter face au problème posé ainsi que la planification des processus de développement du logiciel.

3.1.2 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