Un système interactif d'aide à la conception de programmes

Thesis

Reference

Un système interactif d'aide à la conception de programmes

PELLEGRINI, Christian

Abstract

Les recherches menées au Centre universitaire d'informatique (C.U.I) de l'Université de Genève sont axées avant tout sur l'amélioration des communications homme-machine. Cette thèse constitue donc dans le domaine des techniques de programmation une nouvelle réalisation s'inscrivant dans ce thème général. Après un exposé de la méthodologie de la programmation avec un développement particulier des méthodes récentes de la programmation structurée et de la programmation systématique, ce rapport décrit en détails le système conçu et réalisé à l 'Université de Genève. Le système interactif d'aide à la conception de programmes développé au C.U.I exploite les ressources d'un terminal graphique relié à un mini-ordinateur NOVA 1200 et composé d'un écran à plasma, d'un clavier alphanumérique et d'un système électronique de repérage. Avec ce dernier il est possible ou bien de déterminer les coordonnées d'un point désigné sur l'écran, ou bien de suivre la trajectoire d'un objet se déplaçant à sa surface et de relever celle-ci avec une fréquence de mesures variable. La souplesse [...]

PELLEGRINI, Christian. Un système interactif d'aide à la conception de programmes. Thèse de doctorat : Univ. Genève, 1976, no. Sc. 1724

DOI : 10.13097/archive-ouverte/unige:105876

Available at:

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

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

1 / 1

UNIVERSITE DE GENEVE CENTRE UNIVERSITAIRE D'INFORMATIQUE

FACULTE DES SCIENCES

UN SYSTEME INTERACTIF D'AIDE A LA CONCEPTION DE PROGRAMMES

THESE

PROFESSEUR J.HARMS

présentée à la Faculté des Sciences de l'Université de Genève

pour obtenir le grade de docteur ès sciences mention informatique

par

Christian PELLEGRINI de

Genève

THESE No. 1724

Genève

Imprimerie de Champel 1976

La faculté des sciences, sur le préavis de Messieurs J. Harms, professeur ordinaire et directeur de thèse, B. Levrat, professeur ordinaire et L. Bolliet, professeur (Université de Grenoble), autorise l'impression de la présente thèse, sans exprimer d'opinion sur les propositions qui y sont énoncées.

GENEVE, le 25 novembre 1975 Le Doyen: Jean MULLER

Thèse No. 1724

Résumé

Les recherches menées au Centre universitaire d'informatique (C.U.I) de l'Université de Genève sont axées avant tout sur l'amélioration des communications homme-machine. Cette thèse constitue donc dans le domaine des techniques de programmation une nouvelle réalisation s'inscrivant dans ce thème général. Après un exposé de la méthodologie de la programmation avec un développement particulier des méthodes récentes de la programmation structurée et de la programmation systématique, ce rapport décrit en détails le système conçu et réalisé à l'Université de Genève.

Le système interactif d'aide à la conception de programmes développé au C.U.I exploite les ressources d'un terminal graphique relié à un mini-ordinateur NOVA 1200 et composé d'un écran à plasma, d'un clavier alphanumérique et d¹un système électronique de repérage. Avec ce dernier il est possible ou bien de déterminer les coordonnées d'un point désigné sur l'écran, ou bien de suivre la trajectoire d'un objet se déplaçant à sa surface et de relever celle-ci avec une fréquence de mesures variable.

La souplesse d'utilisation de la surface d'affichage (écriture et effacement sélectifs) et la simplicité du système de repérage (pas d'instrument encombrant du genre light-pen, un doigt seul permet la désignation dlune région de l'écran), font que ce terminal graphique est d'un emploi très agréable et naturel.

Le système de programmation tel qu'il existe actuellement permet ^à son utilisateur de développer et de modifier des programmes en manipulant directement leur structure logique. Celle-ci est visualisée sur le terminal graphique sous la forme d'un organigramme permettant de construire des programmes éiaborés en respectant les concepts de la programmation structurée. Par le jeu de commentaires associés aux symboles de l'organigramme, l'utilisateur peut facilement se souvenir des actions que ceux-ci représentent. Pour permettre la génération automatique du progranune, il faut compléter chaque symbole par des instructions (exprimées dans le langage PASCAL) ou du moins par la partie de l'instruction qui ne peut pas être déduite de la nature même du symbole (par exemple, il faut fournir ! 'expression logique sur laquelle porte le test if ••• then).

du système permettent de développer des modules (ou procédures) comptant chacun 70 permet 1¹élaboration de programmes de taille instructions).

Les capacités actuelles progranunes composés de 10 symboles au maximum; ceci moyenne (environ 1000-1200

Les extensions futures offriront à l'utilisateur la possibilité de programmer en FORTRAN, d'autre part la connection de ce système en tant qu'entrée directe à un compilateur PASCAL permettrait d'en augmenter l'efficacité et surcout d'en faire un véritable système de programmation.

R E M E R C I E M E N T S

Je tiens tout d'abord à remercier le professeur J. Harms, qui a dirigé cette thèse, pour les encouragements qu'il m'a prodigués tout au long de la réalisation de ce travail. Lors de nos discussions, j•ai particulièrement apprécié ses suggestions et ses critiques toujours judicieuses.

Je veux ensuite exprimer toute ma reconnaissance au professeur B.

Levrat, directeur du Centre Universitaire d'Informatique, pour le vif intérêt qu'il a toujours porté à mon travail, pour sa stimulation constante et pour tous les moyens qu'il a mis à ma disposition.

Je remercie le professeur L. Bolliet, qui a accepté de faire partie du jury de thèse.

Mes remerciements vont également à tous mes camarades du C.U.I.

pour leur aide et leurs conseils amicaux, à MM. M. Wenger, A. Meier et J.F. L'Haire pour la réalisation du système de repérage et la mise au point du terminal graphique, ainsi qu'à M. M. Sarret pour le développement du logiciel de base.

Enfin je remercie tout particulièrement Mme. L. Noël pour le soin qu'elle a apporté à la dactylographie de ce texte et son édition sur mini-ordinateur.

Cette recherche a été partiellement subventionnée par le Fonds National Suisse pour la Recherche Scientifique.

INTRODUCTION

La conception de programmes assistée par ordinateur n'est pas une idée nouvelle. Dès l'apparition des grands systèmes et plus particulièrement de ceux exploités en temps partagé, les utilisateurs ont bénéficié de facilités de plus en plus sophistiquées pour les aider dans l'élaboration et la mise au point de leurs progranuaes.

Les plus perfectionnés parmi ces systèmes d'aide à la progrannnation sont ceux dont l'utilisation se fait en mode conversationnel. Ils offrent à leurs utilisateurs un large éventail de ressources comprenant des interpréteurs interactifs, des compilateurs incrémentaux et des éditeurs de progranrnes; mais presque tous reposent sur l'aspect séquentiel de l'écriture de programmes. Rares sont donc ceux qui font efficacement ressortir la structure interne du progranune et plus rares encore sont ceux qui en fournissent une représentation concrète sous quelque forme que ce soit.

D'autre venues encore programme et habituellement

part les nouvelles méthodes de programmation sont accentuer l'importance de la notion de structure d'un ont passablement modifié l'approche qui était faite de la programmation.

Par conséquent nous avons décidé de développer, au Centre Universitaire d'Informatique (C.U.I.) de l'Université de Genève, un système d'aide à la programmation qui s'écarte fondamentalement de l'aspect séquentiel de l'écriture de programmes.

tJous nous sommes fixés comme objectifs principaux d'une part de présenter à l'utilisateur une image de la structure de son programme en cours de développement et, d'autre part, de lui permettre de l'élaborer en respectant les principes fondamentaux de la programmation structurée. Le. système interactif que nous avons réalisé visualise la structure logique du programme en empruntant la notation symbolique des organigrammes et repose sur l'emploi par le programmeur du langage PASCAL. Ce dernier nous a séduits par sa simplicité et sa parfaite adaptation à l'écriture de programmes structurés; de plus, il renferme de grandes facilités concernant la définition et la manipulation de structures de données particulièrement élaborées.

Summary

Recent research efforts (C.U.I) of the University man-machine communication.

progranuning, represents one

at the "Centre Universitaire d'Informatique"

of Geneva have focused on the improvement of This thesis, which discussed a new system for aspect of this general research environment.

The introduction provides a brief overview of programming methodology with special emphasis on the methods of structured and systematic programming. The remaining sections discuss the details of an interactive system which has been designed to aid persons writing programs. This system has been implemented and is being used at the University of Geneva.

The system is comprised of a graphical terminal linked to a mini-computer (Data General NOVA 1200). The terminal bas been espacially designed to facilitate man-machine interaction. It consists of three components: (1) an alphanumeric keyboard, (2) a plasma panel, and (3) a specially constructed input device which is attached to the plasma display ("finger input device"). The finger input device makes it possible for the user to point to any part of the screen or to track an object (for example his finger) moving on it's surface. Coupling the finger input device with the plasma display provides the users with a powerful and flexible tool which allows them to easily communicate with the system.

Using this hardware configuration a software system has been developed which enable users to design and to modify programs by working directly with the logical structure (e.g. the flowchart). The user can then make

changes, insertions and/or deletions to the current flowchart shown on the screen. These additions/replacements must conform to some general rules of structured and systematic programming plus some specific system contraints (e.g. only two levels of nesting of control structures). The user can remember what action is represented by a symbol since connnents can be attached to the flowchart symbols.

When the user bas finished restructuring the flowchart, he requests the "automatic" program generation feature. The system then generates prograrrming language instructions (in PASCAL) for each flowchart symbols.

For symbols reflecting a control structure (like if ••• then, repeat ••• until, etc.) the user only needs to provide the boolean expression on which the test is made, the rest of the instruction is deduced from the shape of the symbol. The end product of this step is a working program.

With the currently available system a user can develop programs of medium size (1000-12000 instructions) with each program limited to a maximum of 10 modules (procedures). Each procedure is in turn limited to

a maximum of 70 symbols.

Plans for future additions to this system include: (1) automatic generation of FORTRAN instructions, (2) converting the system soit can be directly linked to the PASCAL compiler. This second objective will increase the power of the system, as well as provide the user with a completely interactive environment.

TABLE DES MATIERES

Introduction

Premier chapitre : Pratique de la progrannnation 1.1 La programmation

1.2 Démarches de la programmation 1.2.1 Phase d'analyse

1.2.2 Phase de réalisation 1.3 Pratique de la programmation

Deuxième chapitre : Méthodologie de la programmation 2.1 Les. langages de programmation

2.2 La programmation structurée

2.3 La programmation systématique et la conception descendante

2.3.l La prosrammation systématique 2.3.2 Assertions et invariants 2.3.3 La conception descendante 2.4 Trois technologies particulières

2.4.l Le pseudo-code 2.4.2 HIPO

2.4.3 "Chief Progrannner Teams"

Troisième chapitre : Introduction au système SPIDO 3.1 Algorithmes et progranunes

3.2 Les organigrammes 3.3 Le système SPIDO

3.3.1 Les symboles 3.3.2 Le module 3.3.3 Le programme

3.3.4 Organigramme structuré

3.4 Fonctions principales du système SPIDO 3.4.1 Etape de conception

3.4.2 Etape d'interprétation et de production de programmes

Quatrième chapitre : Le dialogue honune-machine 4.1 Introduction

4.2 Les facteurs humains 4.2.l Aspect fonctionnel 4.2.2 Aspect méthodologique 4.2.3 Aspect relationnel 4.2.4 Temps de réponse 4.3 Le dialogue

4.3.l Quelques catégories de dialogues 4.3.2 Cdntingences matérielles

4.3.3 Problème de logiciel

1

3 3 4 4 6 8

11 11 13 17 17 17 19 21 22 22 23

27 27 29 31 32 37

39 40 42 43 45

49 49 49 50 50 51 51 52 53 54 55

Cinquième chapitre: Les terminaux interactifs 5.1 Les dispositifs de visualisation

5.1.1 Le tube à rayon cathodique 5.1.2 Le tube à mémoire

5.1.3 L'écran à plasma

5.2 Les dispositifs de communication 5.2.1 Le clavier alphanumérique 5.2.2 Le photostyle

5.2.3 Les tablettes

5.2.4 Le système de repérage 5.3 Le terminal graphique du

c.u.r.

57 57 57 58 59 61 61 62 62 64 66

Sixième chapitre: La programmation d'un terminal graphique 71 6.1 Introduction

6.2 L'image

6.2.1 Relation fenêtre-hublot de vision 6.2.2 Clôture de l'image

6.3 Les structures de données 6.3.1 Les structures de base

6.3.2 Les structures arborescentes

Septième chapitre: Organisation et gestions des informations

71 72 72 74 76 76 78

dans le système SPIDO 83

7.1 Langages d'implantation du système SPIDO 7.2 Mise en oeuvre du dialogue

7.2.1 Sélection sur "menu"

7.2.2 Utilisation du clavier alphanumérique 7.3 Construction et gestion de l'image

7.3.1 Construction de l'image 7.3.2 Gestion de l'image 7.4 L'information fondamentale

7.4.1 L'information structurelle 7.4.2 Les informations associées 7.5 Format des fichiers de transfert

Conclusion

83 84 84 86 87 87 89 90 90 92 94

97

CHAPITRE PREMIER

PRATIQUE DE LA PROGRAMMATION

1.1 La progrannnation.

Le sujet de cette thèse étant très fortement lié à la technique et à la méthodologie de la programmation nous ferons tout d'abord le point sur l'activité intellectuelle que recouvre le terme de "progrannnation".

"La programmation est une activité dans laquelle une personne décrit une action complexe sous la forme d'une combinaison d'actions élémentaires en suivant certaines règles".

Nous pouvons donc assigner deux buts à cette activité:

- provoquer l'accomplissement de dispositif capable d'interpréter

leurs règles de combinaison,

1' action complexe par un les actions élémentaires et

- permettre ^à toute personne connaissant la signification des actions élémentaires et leurs règles de combinaison de comprendre l'action complexe.

Nous avons introduit dans cette définition. en plus de la notion d'exécution,la notion de conununication d'un progrannne, en effet à une époque où les projets informatiques prennent une importance si grande, il est nécessaire que toute personne puisse communiquer et échanger des programmes. La faculté de communication ne doit pas se limiter à l'échange du produit final, mais elle doit aussi animer tous ceux qui sont concernés par la réalisation du programme.

Nous savons, d'expérience, qu'un programme n'est jamais exempt d'erreurs, que celles-ci peuvent être mises en évidence longtemps après que le progrannne soit entré en exploitation et qu'elles seront souvent corr1gees par d'autres personnes que son auteur; un programme ne sera parfaitement transmissible que s'il est documenté et nous considérerons que la documentation fait partie intégrante de la prograrrnnatiion.

Il faut donc dès le début mettre à la disposition des informaticiens certains outils d¹ analyse et de programmation qui soient précis dans leurs définitions et efficaces dans leur emploi.

4 Pratique de la programmation.

Cë ~/IC J.A MISE AIIPowr A Fltrr CG f11'11. FA t.l.AtT

Figure 1.1 Est-ce la réalité?

1.2 Démarches de la programmation.

La conception d'un programme est une entreprise longue et délicate dans laquelle il faut à plusieurs reprises mettre l'ouvrage sur le métier. De plus dans ce processus évolutif, où il faut souvent reprendre des points considérés comme acquis , il est difficile de maîtriser à la fois la structure logique du programme et de faire face aux difficultés inhérentes à un langage de programmation. C'est pourquoi nous diviserons l'activité de la programmation en deux phases: d'une part l'analyse et d'autre part la réalisation du programme. Il faudra alors distinguer les démarches propres à la ·première phase de celles spécifiques à la seconde.

1.2.1 Phase d'analyse

L'activité de la phase d'analyse se déroule au niveau du problème à résoudre; le vocabulaire utilisé dans cette phase est celui du domaine auquel appartient ce problème et l'analyste établit la démarche logique devant amener la solution en termes du problème;

tout se passe donc au niveau d'abstraction le plus élevé.

Pratique de la programmation.

l)ans cette phase nous pouvons distinguer plusieurs étapes - la définition du problème;

- le choix de la méthode et des algorithmes;

5

- le choix du langage de programmation et des structures de données;

- l'établissement de la structure logique du processus devant fournir la solution

Ces quatre étapes ne constituent pas une subdivision rigide, ma~s sont au contraire dépendantes les unes des autres et l'ordre dans le que 1 nous les avons citées correspond à ce lui le plus généralement admis. D'autre part, il est clair que les options prises à un certain niveau conditionneront celles à prendre aux niveaux suivants mais elles peuvent également influencer les options définies précéderranent.

Décrivons brièvement les étapes les plus importantes de cette phase.

Choix de la méthode et des algorithmes

Une fois le problème posé, il faut déterminer la ou les méthodes qui permettront d'en obtenir la solution. Nous avons volontairement dissoci6 le choix des méthodes de celui du langage, car nous supposons implicitement que le problème à résoudre est d'ordre général et que la détermination de la méthode ne présuppose pas l'emploi d'un langage particulier. Il est cependant évident que pour des applications très spécifiques, le choix de la méthode et celui du langage sont très fortement dépendants l'un de l'autre. Une fois les méthodes et les algorithmes choisis, il faut en transcrire les énoncés et les exposés pour les appliquer au problème à résoudre.

Sélection d,u langa&e et des structures de donnée.s

Dès les années cinquante, on assiste au développement croissant des langages de programmation orientés vers un type de problème et non plus vers un type de machine; l'avantage évident est que des solutions élaborées sur un ordinateur deviennent "portables"

sur un autre; par contre, la multiplicité des langages rend le choix difficile. Cependant un certain nombre de critères peut diriger ou influencer le progranuneur dans sa sélection. Tout d'abord, et en fonction du problème à résoudre, les données à partir desquelles la solution devra être obtenue possèdent certaines caractéristiques qui favorisent une structure plutôt qu'une autre. On choisira alors parmi les langages celui qui permettra de manipuler cette structure.

Comme c'était le cas pour le choix de la méthode, l'expérience de l'analyste et du programmeur peut jouer un rôle considérable dans le choix du langage, car dans le domaine de la programmation plus qu'ailleurs la connaissance sans expérience et sans pratique ne

constitue pas un bagage suffisant.

Structure logique du processus de solution

A

engagées tâche à prévoir

ce ni.veau de l'analyse les opérations sont déjà très et la majeure partie du travail de réflexion est faite. La accomplir dans cette étape consiste essentiellement à et ^à préciser l'organisation définitive du programme et son

6 Pratique de la progranunation.

découpage logique. Ce dernier fera apparaître une division modulaire qui doit correspondre aux différentes phases du programme final;

chacune de ces phases peut à son tour être l'objet d'une division en sous-phases. Ces divisions successives doivent aboutir, conune le suggère F.T. Baker (1), à un ensemble de modules dont la grandeur optimale, environ une page, est celle qu'il est possible de maîtriser intellectuellement. Il faut si possible écarter la

tentation de la complexité, car il arrive que les constructions péniblement élaborées échappent à tout contrôle intellectuel, et selon l'expression de E.Dijkstra, nous avons "une petite tête" qui ne nous permet de maîtriser simultanément qu'un nombre limité d'objets.

La recherche de la solution par niveaux de détails successifs est appelée progranunation descendante (2) (3) (4), développement par raffinements successifs (5). Cette technique d'approche de la solution est en fait plus qu'une simple méthode de travail, elle s'inscrit dans un large ensemble de nouveaux concepts qui sont décrits plus en détails au chapitre deuxième.

A la fin des étapes de la phase d'analyse que nous venons de décrire, l'ensemble du problème est défini; il s'agit alors de réaliser le programme en traduisant dans le langage choisi les différents algorithmes sélectionnés et de donner à tout cela une forme acceptable pour le système informatique utilisé afin de résoudre le problème. C'est la phase de réalisation.

1.2.2 Phase de réalisation

Cette seconde phase peut se décomposer en certaines étapes qui sont :

- la codification;

- le test et la correction d'erreurs;

- l'entretien du programme.

Codification

Cette étape consiste essentiellement à écrire le programme en se basant sur les spécifications de l'analyse et sur le découpage logique du processus en modules, tâches et sous-tâches qui conditionnent la subdivision du programme en sous-programmes. Quant bien même le programmeur serait la seule personne à relire le programme, ce qui n'est pas toujours le cas, il faut que celui-ci soit conçu d'une maniere aussi claire que possible et que la structure du processus définie lors de l'analyse se traduise par une structure logique apparente dans le programme.

Il y a cependant un point sur lequel nous voudrions insister, c'est l'écriture d'un code trop "intelligent". Il faut prohiber l'écriture d'instructions qui ne sont pas claires quant à leurs actions ou dont l'effet n'est pas facilement compréhensible. La figure 1.2 donne un exemple de telles instructions empruntées à un programme fortran et dont l'exécution, impliquant la particularité des divisions entières, a pour simple résultat d'initialiser la diagonale de la matrice X à 1.

Pratique de la programmation. 7

Figure 1.2

DO 1 I = l ,N DO 1 J = l ,N

X(I,J) = (I/J) *(J/I) 1 CONTINUE

Instructions trop -intelligentes"

L'expression "Ce qui se conçoit bien, s'énonce clairement"

est également valable en programmation et G.M. Weinberg (6) a cerné les défauts de programmation et a tenté d'en donner une explication tant du point de vue technique que du point de vue psychologique.

Test et correction d'erreurs

Suivant l¹expression de E. Dijkstra : "Le test systématique de programmes ne peut être utilisé que pour mettre en évidence la présence d'éventuelles erreurs, mais en aucun cas pour prouver leurs absences" {7), nous pensons qu'un programme ne peut jamais être considéré comr.ie achevé. Nous laisserons de côté les erreurs triviales de codification, de syntaxe ou de préparation d'instructions (fautes de frappe ou de perforation) pour nous intéresser davantage aux erreurs de logique propres ^à l'analyse ou dues à une mauvaise interprétation de sa structure. Dans ce cas, il est nécessaire de disposer de ce que nous appellerons un cas type d'essai. Les données constituant ce cas type seront choisies avec soin, elles illustreront l'ensemble des possibilités offertes par le programme et le résultat de leur traitement sera déterminé préalablement avec une bonne précision. La comparaison du résultat fourni par le programme avec celui déjà déterminé dira si

! 'exécution du prograr:uue est conforme ou non, Cependant, il ne faut pas oublier qu'un programme ayant correctement réagi au traitement d'un cas type, n'est pas nécessairement exempt d'erreurs de conception ou de logique.

Eutret ien du er~rarome

Comme nous l'avons mentionné ci-dessus, l'apparition d'une erreur due à un concours de circonstances particulières et inhabituel les nécessiter a 1' intervention d'un progranuneur pour la recherche d'une correction. Si la personne requise n'est pas l'auteur du progranu:ne, il faut qu'elle dispose d'une documentation prec1se et ^à jour, sans quoi sa tâche sera particulièrement difficile. En plus de ces activités de dépannage, il faut introduire les améliorations ou les modifications demandées par l'utilisateur du programr.1e, qui est éventuellement une personne différente de celle qui était à l'origine du problème. Ces changements venant modifier la structure du programme, il faut faire alors subir ^à celui-ci un nouveau test de façon à prouver sa validité et être tout aussi attentif que lors de l'étape de test et correction d'erreurs.

8 Pratique de la programmation.

1.3 Pratique de la progranunation

Au vu des quelques notions énoncées et décrites aux paragraphes précédents, nous pouvons maintenant définir ce qu'est une "bonne programmation". La bonne progranunation commence par une

"bonne conununication" entre les personnes impliquées dans son processus (analystes, progrannneurs et utilisateurs). Elle se poursuit par une analyse complète et rigoureuse pour aboutir à la codification d'un progrannne qui s'exécute sans faille et pas seulement sur des cas triviaux ou bien connus, mais sur tous les cas envisageables.

Bien des fois la démarche de la programmation est confondue avec la codification d'un programme d'ordinateur; nous venons de voir que cette activité n'entre que pour une partie ( ••• modeste) dans l'ensemble du processus et que la codification ne peut aboutir à un bon programme si l'ensemble des phases qui la précède n'a pas contribué à bien en définir les caractéristiques.

Cependant que l'on ne déduise pas de ce qui précède que la programmation est une discipline cartésienne où la solution s'obtient par l'application d'un raisonnement rigoureux et immuable.

Car, comme pour les autres sciences, il faut qu'il y ait, en plus de la rigueur scientifique, une part d'intuition et d'imagination qu'il est parfois difficile de traduire immédiatement en termes de programme. C'est pourquoi l'approche de la solution d'un problème par étapes et à des niveaux d'abstraction successifs est particulièrement efficace.

Pratique de la progranmiation.

Références

(1) Baker, F. T.

Chief Progranuner Team Management of Production Programming. lllM System Journal, vol. 11, no. 1, pp. 56-73, 1972.

(2) Mills, H.D.

Top-Down Prograrmning in Large Systems.

In Debugging Techniques in Large Systems, R. Rustin (Ed.).

Prentice-Hall Inc., Englewood Cliffs, New Jersey, 1971.

(3) Miller, E.F. et Lindamood, G.E.

Structured Programming : Top-Down Approach.

In Datamation, vol. 19, no. 12, décembre 1973, pp. 50-52.

(4) Mc Gowan, C.L. et Kelly, J.R.

Top-Down Structured Prograrraning Techniques.

Mason/Charter Inc., New York, 1975.

(5) Wirth, l~.

Progrannn Deve lopment by Stepwise Refinement

9

Communications of ACM, vol. 14, no. 4, avril 1971, pp. 221-227.

(6) Weinberg, G.M.

The Psychology of Computer Programming Van Nostrand Reinhold Co .• , New York• 1971.

(7) Dijkstra, E.W.

Notes on Structured Programming

ln Structured Programming. Dah 1/Dijkstra/Hoare.

Academic Press Inc., Londres, 1972.

11

CHAPITRE DEUXIEME

METHODOLOGIE DE LA PROGRAMP'iATION

Avant l'apparition des langages de haut niveau, la programmation consistait essentiellement à codifier directement la séquence d'instructions-machine qui allait permettre d'obtenir la solution d'un problème donné. Ce genre d'activité favorisait le développement d'une grande quantité de "trucs" qui avaient pour but de pouvoir économiser des instructions ou du temps dans la préparation de ces programmes rudimentaires. C'était l'ère de la

"trucologie".

Avec l'avènement des langages tels que FORTRAN, COBOL, ALGOL et autres, ainsi qu'avec l'élaboration de véritables méthodes de programmation (le "software engeneering"), nous avons en main de véritables outils techniques et nous sommes entrés dans la période

"technologique" de la programmation. Cependant il faut admettres que si les infonnaticiens ont favorablement acceuilli ces nouvP-lles techniques, ils n'ont pas pour autant changé d'habitudes, principalement en ce qui concerne les mauvaises qui se sont simplement adaptées aux nouvelles méthodes.

2.1 Les langages de prograrrnnation

L'évolution des langages de programmation s'est faite avec certaines contraintes dues aux machines sur lesquelles ces langages devaient ~tre implantés. Cependant, cette évolution a toujours tenté de libérer le programmeur de ces contraintes et de lui offrir des langages faciles à utiliser; cette remarque est particulièrement vraie pour les langages que l'on enseigne, BASIC, APL,PASCAL qui constituent de bons compromis entre l'efficacité et la simplicité.

Les langages de programmation, qui sont les principaux outils de 1¹ informatique, ont été conçus pour décrire avec précision la séquence d'actions à faire exécuter par une machine; comme nous l'avons évoqué au chapitre précédent, le processus de programmation ne se limite pas i définir cette séquence, il englobe toute une démarche intellectuelle parfois très complexe, pour laquelle nous allons essayer d'élaborer une méthodologie. Le problème qui se pose alors est de proposer de nouvelles techniques ou de concevoir de nouveaux langages qui soient mieux adaptés à la démarche définie précédemment et qui contribuent à faciliter le processus humain dans

la recherche de solutions automatisées (1).

12 Méthodologie de la programmation.

L'étude d'un progrannne démontre très clairement que ce dernier possède essentiellement une structure hi-dimensionnelle; cette structure n'est que très imparfaitement dégagée par les langages de progranunation dont l'écriture est purement séquentielle. Il faut alors développer une technologie qui, jusqu'au moment de codifier le programme, permette de conserver la structure à deux dimensions du processus de progrannnation. Certaines techniques existent déjà et sont à répartir en deux grandes catégories :

- celles qui influencent la intellectuelle du progranuneur, d'analyse jusqu'à la réalisation

totalité de la depuis le début de du programme;

démarche la phase

- celles qui interviennent dans la progrannnation, à savoir la conception programme.

dernière phase de la et la codification du

La première catégorie regroupe certainement les approches les plus prometteuses comme par exemple la programmation structurée (cf.

2.2), la programmation systématique et la technique du raffinement successif (cf. 2.3), les méthodes d'analyse et les diagrannnes logiques (cf. 2.4). Dans la seconde catégorie, nous retrouvons des techniques qui touchent de plus près à la définition de nouveaux langages, ces derniers peuvent répercuter dans leur syntaxe la structure hi-dimensionnelle d'un programme.

Ces langages sont appelés les langages-2D; nous allons très brièvement en énumérer les principales caractéristiques. De nombreuses études ont été faites récemment sur la définition de ces nouveaux outils de programmation (2), mais elles se sont limitées à des applications très particulières. Un langage symbolique à deux dimensions consiste en deux parties :

- définition d'une syntaxe orientée vers l'emploi de symboles hi-dimensionnels dont la signification dépend des positions relatives des uns par rapport aux autres;

- construction d'un processus de reconnaissance de la représentation topologique du langage et transformation de celle-ci en une suite séquentielle d'instructions acceptable par une machine.

De toutes les tentatives effectuées dans ce domaine nous voulons en citer deux, il s'agit de celle de R.Anderson de l'Université de Californie (3) et celle de J.Gros et J.P. Maroy de l'IRIA (4).

Nous constatons donc, qu'à part certains langages très spécifiques ou dont le développement n'est pas achevé, les langages existants et très répandus ne permettent pas de donner au programme une forme qui soit à la fois acceptable par la machine et qui soit l'image de la structure logique qu'a voulu lui donner le programmeur. A ce sujet, il est d'ailleurs significatif de voir quelqu'un apporter des corrections à un programme : sans élaborer une structure complète et bien définie, le programmeur encadre ses corrections ou ses modifications par de petites boîtes qu'il relie entre elles et qu'il insère dans les instructions par des flèches;

ce procédé démontre que la réflexion se fonde sur une certaine structure et qu'il est difficile de linéariser le résultat de cette

Méthodologie de la prograr.1I11ation. 13

démarche intellectuelle en trans1t1on constante entre programme ne fait qu'augmenter

une séquence d'instructions; la le niveau réflexion et le niveau la difficulté.

2.2 La programmation structurée

Une lettre à l'éditeur de E.W. Dijkstra parue dans les

"Communications of the ACM" en 1968 (5) déclencha une controverse à

propos de l'instruction "GO TO" à laquelle de nombreuses personnes prirent part et dont le principal mérite fut d'amener les inforraaticiens à réfléchir sur ce qu'était réellement la programmation.

Le principal résultat de ces réflexions c'est encore à Dijkstra qu'on le doit, résultat qui est à la base de ce que l'on appelle aujourd'hui. la .e,rogrammation structurée (6). Dès ce moment d'autres personnes se sont prononcées en faveur de cette nouvelle tendance et certaines ont activement contribué à en exposer les méthodes fondamentales et à en définir les lignes directrices; parmi celles-ci nous citerons N. Wirth, sur les travaux duquel nous aurons l'occasion de revenir (cf. 2.3) et C.A.R. Hoare, pour leurs contributions théoriques (10), (11), ainsi que F.T. Baker et H.D. Mills, pour les applications et les réalisations pratiques qu'ils ont développées à partir des concepts de la programmation structurée (7), (8), (9).

En quoi consistent les concepts de programmation structurée?

Au début cette notion était assimilée

- à la suppression des instructions du type

.22!.2,;

- à l'abolition des organigrammes;

- à une discipline rigide dont les règles ne devaient pas être transgressées.

Toutes ces interprétations, à notre sens, sont abusives. Il est évident que la controverse du GOTO est à l'origine de certains concepts, quoique ce n'est pas---i-'"instruction GOTO qu'il faille prohiber, mais ses utilisations excessives ou anarchiques. Si la conception classique du rôle des organigrammes est imparfaite ou mal adaptée, il ne faut pas définitivement les rejeter. Quand à ceux qui n'y voient qu'une discipline aux règles strictes, qu'ils se rassurent, chacun est libre d'y prendre, et d'y apporter, ce qu'il veut. En effet la programmation structurée est plus qu'un ensemble de conventions arbitraires qui pern~ttent de juger les performances d'un programmeur et plus qu'une simple technique de codification de prograrames, c'est une méthodologie qui, actuellement, met l'accent principalement sur 1 'aspect constructif de la progranunation et ne prétend pas à une rigueur absolue.

A ce point nous aimerions faire une parenth~se nous considérons que la façon de démontrer l'efficacité des méthodes de la programmation structurée en faisant figurer côte à côte deux versions A et B d'un même programme, la version A étant structurée et la version B ne l'étant pas, est une erreur. En effet ce n'est pas le produit fini qu'il faut comparer c'est la démarche complète, la totalité du processus qui a abouti à la version A du

14 Méthodologie de la programmation.

programme qu'il est important de mettre en évidence; de plus, les deux versions sont souvent aussi obscures l'une que l'autre et il est impossible d'y déceler une structure sans une longue observation.

La programmation structurée a pour but d'élaborer des méthodes permettant de développer des programmes vastes et complexes en toute sûreté intellectuelle; pour ce faire elle se fonde sur deux idées principales, à savoir:

les structures et l'abstraction.

Les structures constituent l'outil principal qui permet de maîtriser efficacement la complexité d'un problème et de rendre compréhensible une grande masse d'informations qui était confuse et apparemment sans signification. La faculté d'abstraction constitue l'autre instrument permettant de maîtriser la complexité. Un problème quelconque, dont on veut élaborer une solution automatisée, ne doit pas être d'emblée considéré en termes de progranune (instructions, mots-machine ou bits) mais en terme qui lui sont propres, donc abstraits. De cette réflexion sort un "programme"

abstrait manipulant des données abstraites et formulé dans un langage abstrait {par rapport à la machine organigrammes ou langage naturel par exemple). Ce programme sera alors l'objet de transformations successives qui lui donneront en définitive une forme acceptable par la machine. Pour que ce processus de programmation soit efficace et pour que les niveaux d'abstraction découlent facilement les uns des autres, la programmation structurée introduit ce que nous appellerons les schémas élémentaires de programmes qui disciplinent la pensée tout en des facilités de structures.

Les méthodes proposées par la programmation structurée offrent donc une solution au problème de la maîtrise intellectuelle sans que cette alternative soit la seule possible; cependant, à notre point de vue elle constitue une approche originale et les programmes conçus et développés selon ses principes ont une forme (structurée) qui en facilite la lecture, la compréhension, les corrections et les modifications. Nous venons d'évoquer là un point, à notre sens très important, que trop de personnes ignorent ou éludent, qui est la lisibilité et la clarté d'un programme.

Après avoir situé l'idée de la progranunation structurée dans le contexte historique et méthodologique, voyons quels sont les schémas élémentaires proposés et sur quelle base théorique ils se fondent.

La base de toute l'idée de structure est constituée par un

"théorème" énoncé par C. Bohm et G. Jacopini (12) qui affirme que toute démarche logique peut être exprimée par un nombre limité de structures simples qui sont :

- la séquence d'opérations élémentaires;

- l'exécution conditionnelle d'une ou deux opérations;

la répétition d'une opération tant qu'une condition est satisfaite.

Méthodologie de la programmation. 15

La figure 2.1 illustre ces trois structures simples à l'aide de symboles empruntés à la notation des organigrammes.

Ces trois structures fondamentales ont toutes la particularité de ne posséder qu'une seule entrée et qu'une seule sortie. ainsi peut-on regarder la ¹¹boîte", représentée en pointillés, comme une action qui se compose d'un nombre fini de sous-actions. Cette decomposition existant au niveau élémentaire, il est des lors permis de la généraliser à l'ensemble d'une démarche de programmation et en définitive de la répercuter au niveau du produit final, le progra1.1me. Ainsi tout programme complexe peut être développé en assemblant de façon appropriée ces trois structures de contrôle. On peut comparer cette procédure de programmation à celle qu'utilisent les ingenieurs électroniciens lorsqu'ils conçoivent un circuit digital; pour ce faire ils se fondent sur l'algèbre de Boole et ont recours aux trois éléments fondamentaux, à savoir les "portes" ET et OU, le circuit inverseur NON et ils ne font intervenir les composants définitifs (transistors, résistances, capacités, circuits intégrés, etc.) qu'au dernier stade de la réalisation pratique. La démarche du programmeur est donc identique à celle de l'ingénieur:

- conception à un niveau d'abstraction élevé,

- emploi de méthodes permettant de schématiser et de structurer sa pensée,

- traduction du résultat de ses réflexions en un programme. A cette étape des instructions du type GOTO seront peut-être nécessaires, mais leurs espaces de validité étant limités en raison de l'emploi des structures de contrôle simples, elles ne perturberont pas l'arrangement de ce programme.

Aux trois constructions élémentaires de la figure 2.1, nous pouvons en ajouter deux nouvelles sans pour autant modifier les concepts de la programmation structurée (cf. figure 2.2), ce sont:

- la boucle; l'exécution à conditionnelle

~ - . • 2!_ ..• ).

choix multiple (généralisation de l'exécution due à C.A. R. Ho are et connue sous le nom de

r---- ---, ^r - - - - --- , r - ---

1 1

1 1

'

'

1 1

S1

1 1 1

'

1

s 2

1 L. - - - - - - - - _.J

L ---- --- -' '

séquence exécution conditionnelle

Figure 2.1 Structures simples de contrôle

1 1

1

1

'

L_

répétition

1

1 1

16 Méthodologie de la programmation.

Les méthodes de la programmation structurée reposent donc sur trois sortes de schémas de programme

- schéma séquentiel;

- schéma itératif (boucle et répétition);

- schéma de choix (action conditionnelle et à choix multiple).

A ceux-ci viennent s'ajouter un certain nombre de conventions qui prennent effet au moment de la conception du programme et qui sont

- la segmentation du programme en un nombre adéquat de modules constituant des entités logiques intectuellement maîtrisables (cette notion est à rapprocher de celle de la programmation descendante, cf. 2.3). Chaque module étant lui-même conçu et élaboré selon les concepts de la prograrranation structurée, il est ainsi possible de définir des niveaux de profondeur qui s'apparentent à la notion de "blocs" propre à certains langages

(ALGOL par exemple);

- la visualisation de la structure propre à chaque module par des procédés de mise en page du code du progrannne.

En résumé nous dirons que le terme de programmation structurée recouvre un ensemble de méthodes permettant de développer des projets informatiques complexes, mais maîtrisés par une subdivision en niveaux, ceux-ci étant formés par un nombre restreint de schémas simples dont les propriétés sont bien comprises; ces méthodes s'appliquent à la phase d'analyse et de conception aussi bien qu'à la phase de réalisation.

r - - - - - - -- -,

1

1

1

1

1 + 1

L - - - - - - - - _r

boucle

1 1

S1 S2

L---

S3

1

1

Sn 1 1 1

- ^-- - ....

exécution

à

Méthodologie de la programmation. 17

Pour conclure nous citerons D. Mc Cracken qui a dit de la programmation structurée (13) :

"C'est une découverte intellectuelle d'importance au même titre quel'a été le concept de 'sous-routine' ou celui de 'programme enregistré'".

2.3 La progranunation systématique et la conception descendante Le processus de conception et de formulation d'algorithmes est complexe, il requiert souvent l 1emploi de techniques nombreuses et diverses; de plus la solution n'est fréquemment pas unique et le choix d'un programme efficace n'est pas facile à faire en fonction du langage et de l'ordinateur d'implantation. Il est donc nécessaire de procéder systématiquement en ayant recours à des techniques propres à la programmation mais ne dépendant pas de l'application à

réaliser; il faut aussi retarder le choix du langage de progranunation de manière à ne pas lier la solution à quelques particularités attrayantes d'un langage.

2.3.1 La progrannnation systématique

Les méthodes de la programmation structurée sont donc une base solide pour la progrannnation systématique (14). ^{Celle- ci} inclut, en plus de ces méthodes, certaines notions et techniques propres à la codification des programmes, car le programmeur doit pouvoir démontrer que son produit s'exécute conformément aux spécifications et ceci en toutes circonstances; de plus, tout programme doit posséder la propriété de se terminer après un nombre fini de répétitions.

2.3.2 Assertions et invariants.

Les techniques utilisées en programmation systématique pour s'assurer qu'une action est correcte sont fondées sur les notions d'invariants et d'assertions.

On appelle assertions les propositions énoncées avant et après une action et qui doivent obligatoirement être vérifiées (cf. figure 2.3) et invariant une assertion qui, figurant dans une répétition, n'est pas modifiée quel que soit le nombre de répétitions effectuées.

assertion antécédente P action

assertion conséquente

Q

Figure 2.3 Assertions

18

La appliquée permet de

Méthodologie de la programmation.

technique combinée des assertions et des invariants aux schémas fondamentaux de la programmation structurée, formuler les idées directrices de la vérification de programmes.

Appliquons la notion d'assertions à un exemple simple.

Soient P un invariant de l'action A, et B une condition représentée comrae :

' A

. p

on en déduit que A peut modifier B.

Si nous appliquons ce qui précède à la répétition AA, nous obtenons:

r----

,

1 1 1

1 1 1

1 L _ _ _ p

1 1 1 1 1

- - - -'

P A

i

De même si nous construisons deux assertions telles que

p

'

A A

'

Q Q

Méthodologie de la programmation.

nous obtenons en les appliquant à la répétition AAA p

r

- - - -,

1 1

1

1

1 1 1 1

1 + ¹

L.. - - - - - - - _ ,

19

Dans le cas de l'exécution conditionnelle nous avons la combinaison d'assertions suivante :

p

+

Que les quelques indications qui précèdent ne fassent pas croire que la preuve de programme est une activité simplep car les exemples ci-dessus sont purement formels et la recherche d'invariants pour chaque répétition ou exécution conditionnelle d'un programmme constitue la grande difficulté de cette méthode, néanmoins, lorsqu'elle est applicable, elle permet d'éviter un grand nombre d'erreurs. L'exemple donné par la figure 2.4 est extrait de

la référence (14).

La programmation systématique reprend donc les concepts de la programmation structurée auxquels elle ajoute ses propres notions assurant une grande sécurité et une bonne fiabilité au programme généré.

2. 3. 3 La conception descendante ("Top-down")

La conception descendante, ainsi que l'analyse pas-à-pas ("stepwise refinement" (15)), est plus une stratégie qu'une méthode de progranunation; elle consiste à exprimer ce que l'on veut faire, non pas immédiatement en termes de langage de programmation, mais en décomposant le processus en une succession d'étapes intermédiaires.

Ces étapes sont développées individuellement selon les méthodes de la progranunation structurée, ce qui confère en définitive à l'ensemble du prograr.m1e une structure telle qu'il est possible de le lire et de le comprendre de haut en bas sans se perdre dans des ramifications compliquées.

20 Méthodologie de la progrannnation.

---1>

0

Z::

0

U:: X

---z=O; U=l

Z:: Z +

y

U::U-1

Z+U*Y= l*Y;

u,.. D

z

+

*Y=

* ^y

+

* y

= D

Figure 2. 4 : Applications des assertions et des invariants (algorithme de division de deux nombres entiers)

La programmation descendante correspond à la démarche naturelle pour la conception d'un système, elle débute par le développement d'un cadre général (niveau de contrôle) et la mise en place des structures de données générales, pour inclure ensuite les unités de niveaux inférieurs (niveaux de détails successifs). Ce procédé de programmation offre une chronologie de développement qui permet une intégration continuelle des différents modules; conserver une vue d'ensemble sur tout le système, corriger à temps les erreurs de conception ou de structure et maintenir la complexité à un degré intellectuellement assimilable est donc possible. Le programme développé selon une conception descendante et structurée prend alors la forme d'une hiérarchie de segments dont les connexions correspondent à la démarche logique qui lui a donné naissance (cf.

figure 2.5).

Le langage de programmation, utilisé lors de la codification du programme, doit:

- permettre de refléter clairement la structure du progrannne;

- être capable d'exprimer les structures de données utilisées de façon simple et explicite.

lnversément à la conception descendante, il est possible de concevoir une approche ascendante qui s'élabore à partir d'actions élémentaires regroupées au sein de procédures primitives (appelées également "action clusters"), qui seront à leur tour intégrées dans des modules de niveau supérieur.

La figure 2.5 considérée à schématiquement la démarche ("bottom-up").

partir des éléments H-I-J illustre de la progrannnation ascendante

r

1 l- i 1

1 1

1 1

L

-

-

- - ^-

- -

1 E

- -

Méthodologie de la progranunation.

A

1

B

- - - - ^{- - - - - -} i

- - - + ^{- - - - - - -,}

^r

C 1

1

1

1 1

'

'

F 1

'

'

--'

- - - - -- - - ^{- -}

1

- ^{- -} - ^{- -} - - ^- - ^{- -} - ^-

,---·---

.

• •

.

.

.

21

- - ^{- - - - -} - -l- ^-- -- ^{- -} -

D

G

-

- - -- - ----·-··--·-·

1

I

- --,

' .

•

.

~

.. ---·--- ---···

L--- - - - - - - ^{_ ,}

1

L

- - - - - - - - - - -

Figure 2.5 Conception descendante et conception ascendante

Pratiquement l'élaboration d'un programme ne suit pas rigoureusement ni la voie descendante ni la direction ascendante, mais se fait selon une conception mixte. Celle-ci confère au programme une structure hiérarchique bien prec1se (issue du

"top-down") tout en permettant la définition d'un certain nombre de fonctions élémentaires qui lui assureront des bases solides ( démarche "bot tom-up").

Cependant le regroupement des étapes intermédiaires issues du

"bottom-up" et du "top-clown" peut être conditionné par des aspects techniques qu'il est parfois difficile de surmonter.

Les stratégies de l'approche descendante et de la conception ascendante de la programmation ont fait l'objet de plusieurs études et applications dont les principales sont décrites dans les références (7), (15), (16) et {17).

2.4. Trois technologies particulières

Après l'exposé des principales méthodes (progranunation structurée et systématique, conception descendante ou ascendante) qui constituent les bases de l'approche utilisée dans ce travai 1, voyons trois techniques liées à la progrannnation, à la documentation et ^à l'organisation du travail - illustrées par les exemples suivants.

22 Méthodologie de la programmation.

2.4.1 Le pseudo-code

Cette technique repose sur la notion d'une programmation descendante. Cependant, contrairement à la méthode qui consiste à visualiser graphiquement l'évolution du processus d'élaboration par une notation d'organigrarmne, la technique du pseudo-code introduit un pseudo-langage de programmation constitué d'un mélange d'instructions et de langage naturel; c'est donc un langage non compilable (cf. figure 2.6).

Assignation des fichiers d'entrée;

initialisation du processus;

LOOP;

lecture des données;

EXITIF (fin des données);

validation;

IF donnée valide THEN traitement;

ELSE erreur;

ENDLOOP;

fin du processus;

Figure 2.6: Exemple d'un programme écrit en pseudo-code (à un haut niveau d¹abstraction)

L'utilisateur qui élabore un programme avec la technique du pseudo-code a la possibilité d'inclure des commentaires en langage naturel ce qui écarte toute ambiguïté. Dans l'exemple de la figure 2.6 la ligne "THEN traitement" recouvre en réalité la plus grande partie du processus et, lors des étapes suivantes, elle sera explicitée jusqu'à ce que le niveau le plus bas soit atteint.

2.4.2 HIPO

Tout programme, conçu selon les méthodes de la programmation structurée ou non, doit être documenté. Le système HIPO développé par IBM (19) propose une technique de documentation adaptée à ces nouvelles méthodes de programmation. Contrairement aux organigrammes, qui ne symbolisent que la structure logique d'un programme, le système HIPO permet également de visualiser le cheminement des données. Une documentation organisée avec HIPO est divisée en trois parties :

- une table des matières visualisée;

- des diagrammes généraux;

- des diagrammes de détail.

La table des matières décrit l'organisation générale de la documentation. Les diagranunes représentent la structure du programme et des modules qui le composent, ils contiennent une information plus détaillée que celle de la table des matières. Les diagranunes de détail décrivent les fonctions des différents modules auxquels a

Méthodologie de la prograr.unation. 23

abouti l'analyse descendante, fonctions elles-mêmes décrites selon les principes de la programmation structurée. Les diagrammes généraux donnent une vue d'ensemble de l'organisation du programme et renvoient à ceux de détail pour les informations spécifiques à chaque niveau de décomposition.

La figure 2.7 donne un exemple d'une documentation structurée selon les conventions et avec la notation de HIPO.

2.4 • .3 :S:hief Programmer Teams··

Alors que les deuA techniques exposées avant avaient pour but de faciliter la démarche même de la programmation, celle connue sous le noms de ''chief programmer teams" ( 17) consiste en une "théorie"

visant à mieux organiser et à m1eux répartir le travail à l'intérieur du groupe composé de :

- chef programmeur;

- programmeur adjoint;

- secrétaire de programnation;

- prograr.uneur(s) associé(s).

10... .... 0....,.

D D

Figure 2.7 Exemple de diagranunes HIPO

24 Méthodologie de la programmation.

Le chef progranuneur est l'analyste responsable de toute l'équipe et supervise tout le travail, il se réserve les modules du haut de la structure dont la codification, parfois délicate, demande beaucoup de doigté et d'expérience. Le progranuneur adjoint est le principal collaborateur du chef progrannneur, il dirige l'équipe des progranuneurs associés dont il planifie le travail. Le secrétaire de la programmation est en sorte le "bibliothécaire" de l'équipe, c'est lui qui rassemble les programmes et qui intègre leur documentation dans un vaste système automatisé qui fait partie de l'organisation elle-même.

Ces organisations d'équipes alliées aux méthodes de la programmation structurée et descendante ont été expérimentées avec succès dans la conception et la production de très grands projets {par exemple l'établissement d'une banque d'informations pour "The New York Times" (18)).

Ces techniques supposent souvent l'existence de moyens considérables qui les rendent inaccessibles à la plupart des utilisateurs. C'est pourquoi nous avons décidé de développé un système exploitable sur un mini-ordinateur, offrant tout de même des facilités succeptibles de le rendre attractif et qui s¹inspire très fortement des principes fondamentaux exposés dans ce chapitre.

Méthodologie de la programmation. 25

Références

(l) Dijkstra, E.W.

The Humble Programmer.

Communications of the ACM, vol. 15, no. 10, pp. 859-866, octobre 1972.

(2) Symposium on two Dimensional Man-Machine Communication.

University of California. Los Alamos Scientific Laboratory.

ACM-Sigplan notices, vol. 7 no. 10, 1972.

(3) Anderson, R.H.

Programming on a Tablet: A Proposai for a New Notation.

In University of California. Los Alamos Scientific Laboratory.

ACM-Sigplan notices, vol. 7 no. 10, 1972.

(4) Gros, J. et Maroy, J.P.

An Axiomatic Representation for On-line Recognition of a Two Dimensional Programming Language.

IRIA-LABORIA. Rapport de recherche no. 51, janvier 1974.

(5) Oijkstra, E.W.

GO TO Statement Considered Harrnful.

Communications of the ACM, vol. 11 no. 3, Mars 1968, pp.

147-148.

(6) Dijkstra, E.W.

iJotes on Structured Programming.

In Structured Programming. Dahl/Dijkstra/Hoare.

Academic Press. Londres 1972.

(7) Mills, H.D.

Top-Dawn Progrannning in Large Systems.

In Debugging Tecl1niques in Large Systems. Rustin, R. (ed.) Prentice-Hall, Englewood Cliff s, New Jersey, 1971.

(8) Baker, F.T.

System Quality through Structured Prograrraning.

Proc. AFIPS 1972 FJCC, vol. 41, pp. 339-343.

AFIPS Press, Montvale, New Jersey.

(9) Baker, F. T. and l1i lls, H. D.

Chief Programming Teams.

Datamation, vol. 19, no. 12, décembre 1973.