Grande Encyclopédie Larousse 1971-1976Éd. 1971-1976
P

programmation (suite)

Lorsqu’un informaticien décide d’aborder le stade de l’écriture d’un programme, il a à sa disposition au moins le langage assembleur de l’ordinateur qu’il utilise, mais, comme, en général, il en a beaucoup d’autres, il doit faire un choix. Compte tenu de toutes les analyses qu’il a précédemment effectuées, il lui est aisé de discerner les facilités que doit offrir un langage pour permettre un codage aussi simple et rapide que possible de son problème, ce qui lui permet d’effectuer très rapidement un premier tri. S’il reste alors plusieurs langages offrant, du point de vue de l’écriture, des avantages comparables, le choix final se fera d’une part en fonction de la connaissance de ces langages qu’a l’équipe de programmeurs chargée de l’analyse de programmation et du codage, d’autre part et surtout en fonction des taux d’efficacité respectifs des compilateurs. Néanmoins, si le choix final s’est porté sur un langage syntaxique globalement bien adapté au projet à réaliser, il arrive parfois que certains modules du programme ne puissent pas (ou n’aient pas intérêt à) être écrits dans ce langage ; par exemple, FORTRAN permet mal la réalisation des traitements de chaînes de caractères. Ces modules devront donc être réalisés dans un autre langage plus souple ou mieux adapté ; en général, on choisit de les coder en assembleur, mais c’est loin d’être une obligation. Il faut alors veiller à la compatibilité des diverses sections de programmes écrites dans des langages différents ; cette contrainte nécessite éventuellement la réalisation d’interfaces entre langages et définit de nouveaux modules à construire lors de la réalisation effective du programme.


L’analyse de programmation

Ce travail comprend trois tâches.

1. Adaptation de la description logique de tous les modules de traitement, de leur chaînage et des fichiers qu’ils utilisent aux formes de présentation imposées par le langage choisi pour les coder. Cette tâche impose l’écriture d’une abondante documentation, qui nécessite en particulier la rédaction :
— du rapport de méthode (descriptif de tous les travaux d’analyse précédemment effectués) ;
— du mode d’emploi du programme accompagné des spécifications externes de ce dernier ;
— d’un descriptif du découpage en phases de ce programme, du chaînage et des spécifications externes de ces phases ainsi que des fichiers communs à l’ensemble du programme ou à plusieurs phases ;
— pour chaque phase, d’un descriptif de son découpage en modules, du chaînage et des spécifications externes de ces modules ainsi que des fichiers communs à l’ensemble de la phase ou à plusieurs de ses modules ;
— pour chaque module, d’un descriptif de son algorithme de traitement ainsi que des fichiers internes qu’il utilise.

2. Définitions et description explicite des contrôles externes à faire subir au programme pour en vérifier l’exactitude et la fiabilité. Ce travail doit être fait respectivement pour chaque module, pour chaque phase et pour l’ensemble du programme. Cette dernière tâche est de très loin la plus difficile de toutes celles qui composent la programmation, et il est extrêmement délicat, pour ne pas dire presque impossible, de prévoir un contrôle du produit global sans aucune faille. Il est d’ailleurs souhaitable que ce travail de préparation de tests soit confié à une équipe distincte de celle qui a réalisé l’ensemble de toutes les analyses précédentes, ne serait-ce qu’à des fins de vérification autonome de l’ensemble du projet.

La difficulté de cette tâche de contrôle et les incidences financières qu’elle peut introduire lorsqu’elle est mal ou insuffisamment conçue expliquent qu’une part importante des recherches actuelles en informatique théorique soit consacrée au problème de la preuve automatique des programmes, qui, s’il était résolu, permettrait en quelque sorte aux programmes de se vérifier eux-mêmes (au prix d’une description parallèle du programme en un langage spécial de contrôle).

3. Préparation des cahiers des charges pour chaque module, pour chaque phase et pour le programme global. Ces documents définissent le travail à confier aux programmeurs et, comme tels, font le regroupement et la synthèse des descriptifs réalisés au cours des tâches précédentes.


Le codage et la réalisation matérielle du programme

Après avoir étudié le cahier des charges décrivant la section de programme qu’il doit réaliser, le programmeur, dans un premier temps, code ce programme, c’est-à-dire traduit en un ensemble de phrases du langage choisi tous les algorithmes qui lui ont été fournis. Puis il exécute les tâches suivantes.
1. Il documente ce programme c’est-à-dire il décrit, sous forme de commentaires, les lignes directrices, le plan et le découpage final choisis pour la rédaction du texte ainsi que l’explication détaillée de toutes les finesses de codage utilisées. (L’intérêt de cette opération est de faciliter la compréhension du texte et, par suite, de permettre d’y apporter plus aisément des modifications.)
2. Il définit et code un programme de test interne destiné à vérifier l’auto-cohérence du programme précédemment rédigé.
3. Il code l’ensemble des programmes de contrôle définis dans le cahier des charges.
4. Il présente l’ensemble de ces textes sous la forme requise pour les faire lire par l’ordinateur (cadrage, interlignage, etc.).
5. Il fait reporter sur cartes perforées les versions finales desdits textes, si, bien entendu, le support matériel choisi pour entrer le programme en machine est la carte perforée.

Quelques méthodes d’accès aux tables

L’accès à une table supposée implantée en mémoire centrale est la possibilité de retrouver en fonction d’une organisation « a priori » de cette table un ou plusieurs de ses éléments.

Un élément d’une table est identifiable au moyen de sa clef, et l’ensemble des clefs est totalement ordonné, c’est-à-dire que ces clefs peuvent être numérotées et que, si i et j sont deux tels numéros de clefs, la relation
i < j ⇒ clef (i) < clef (j)
est vraie.