programmation (suite)

Parmi les implications qu’apportent les contraintes hardware, il convient de prévoir les incidences que pourrait avoir une panne de l’ordinateur au cours de l’exécution du programme. Dans de nombreux cas, un tel incident ne posera pas de problème : une fois la panne réparée, il suffira de restaurer le programme et l’ensemble de ses fichiers pour pouvoir en relancer l’exécution. Néanmoins, cette solution simple n’est pas toujours souhaitable (par exemple dans le cas d’une exploitation de longue durée), ni même possible s’il s’agit d’une panne intervenant au cours de la modification d’un fichier sélectif évolutif : il est difficilement acceptable qu’un compte bancaire soit débité par erreur deux fois de suite de la même quantité parce qu’il s’est produit une panne au cours de la transmission de l’information relative à ce débit ! Il est donc nécessaire de prévoir dans un programme des points de contrôle dont le rôle sera de préparer d’éventuelles reprises du programme en cours d’exécution. Si, dans un programme comportant plusieurs phases comprenant chacune des fonctions de « mise à jour » et de traitement de fichiers, on désire, en cas d’incident, pouvoir recommencer l’exécution des opérations à partir du début de la phase au cours de laquelle une défectuosité s’est manifestée, il suffit, par exemple :
— à chaque fin de phase, d’avoir noté sur un fichier permanent qu’elle s’est correctement terminée ;
— à chaque début de phase, d’avoir stocké sur un fichier permanent, mais d’utilisation temporaire au niveau de la phase, l’état initial des fichiers permanents sur lesquels elle va opérer, ainsi que l’ensemble des données externes qu’elle doit recevoir ;
— finalement, de prévoir une section spéciale de programme destinée à être attaquée en cas de reprise du travail et permettant, à partir des données précédentes, de retrouver la phase qui s’est mal exécutée, de restaurer les fichiers que cette phase utilise et de recommencer l’exécution à partir du début de ladite phase.

Dans ce domaine, les systèmes d’exploitation modernes tendent, dans la mesure du possible, à se substituer à l’analyste dans la prévision de cette tâche de protection. Néanmoins, toutes les techniques développées à cette fin de protection ne permettent de pallier que les incidents liés au fonctionnement des processeurs, et il est impossible de parer sur-le-champ un incident du type détérioration du support de l’information (comme l’étirement d’une bande magnétique), incident auquel on ne pourra remédier que si l’on a pris la précaution d’avoir stocké en double les informations contenues sur ledit support.

La structuration modulaire du programme

À la suite de toutes les analyses précédentes, la structure complète du traitement du problème est entièrement déterminée ; en particulier, l’ordonnancement des phases est connu, et, pour chacune de celles-ci, les diverses sous-sections de traitement, ainsi que les fichiers qu’elles utilisent ont été explicités. Pour terminer de transformer la structure formelle de ce schéma de traitement et préparer son adaptation au codage, il ne reste plus qu’à effectuer les tâches suivantes.
1. On vérifie qu’il n’y a pas deux sous-sections de traitement formellement semblables. S’il y en a, pour économiser du travail de codage et de la place mémoire, il convient de modifier s’il y a lieu leur logique de traitement de façon à les munir d’une même structure de procédure (partie de programme logiquement autonome, définissant elle-même ses propres fichiers de travail et ne communiquant avec le reste du programme que par des fichiers externes dont seules les caractéristiques [nom, structure, taille, etc.] lui sont fournies en entrée). Cette possibilité explique l’intérêt que présente pour un même traitement la disposition de plusieurs algorithmes.
2. On dresse, dans l’ordre chronologique de leur utilisation, la liste des fichiers temporaires (c’est-à-dire définis et utilisés seulement au cours de certaines sous-sections de traitement), en notant à partir de quel instant on les crée et quand leur existence n’est plus nécessaire : le but de cette opération est de créer ces fichiers le plus tard possible et de les faire disparaître le plus tôt possible de façon à minimiser la place occupée par le programme.
3. En fonction de toutes les informations précédentes, on découpe le programme en modules, un module étant dans un traitement formel donné la plus petite sous-section logiquement indépendante.
4. On définit de façon explicite les conditions sous lesquelles un module quelconque peut être exécuté, puis on construit les variables logiques associées respectivement à chacun de ces conditionnements en utilisant par exemple la technique des tables de décision.
5. On en déduit le chaînage de l’ensemble des modules, c’est-à-dire l’ordre dans lequel ceux-ci devront ou pourront, en fonction du conditionnement, être traités.

Une fois toutes ces opérations réalisées (ce qui, en pratique, représente un très gros travail), le programme formel peut être représenté au moyen d’un ordinogramme fonctionnel, dans lequel chaque rectangle représente un module, chaque losange un contrôle de conditionnement (c’est-à-dire le test d’une variable logique) et chaque trait fléché le chaînage des modules. À chaque module est associé un descriptif mentionnant en particulier son algorithme de traitement formel, les fichiers permanents qu’il utilise ainsi que les fichiers temporaires qu’il crée et/ou détruit.

Le choix du langage de programmation

Le seul langage compris par l’ordinateur est son langage propre, le langage binaire, mais, étant donné la difficulté mnémonique que celui-ci présente et le très grand risque d’erreurs de codification qu’il introduit, on n’écrit pratiquement jamais un programme dans ce langage. Pour faciliter la tâche du programmeur et réduire les risques d’erreurs, on a créé de nombreux langages « symboliques », langages qui, pour être compris par l’ordinateur, doivent être traduits en langage binaire par l’intermédiaire d’un compilateur, programme qui fait partie des principaux éléments du software de base de la machine. À part les langages de type assembleur, qui sont en général des traductions sous forme aisément mémorisable du langage binaire, les langages symboliques sont presque toujours syntaxiques, c’est-à-dire construits de façon à être assez proches du langage propre à certaines familles d’applications. Par exemple, ALGOL est un langage très spécifique de la description des algorithmes ; FORTRAN est applicable aux problèmes scientifiques ; COBOL est dirigé vers les tâches de gestion ; PL/1 recouvre FORTRAN et COBOL avec quelques facilités supplémentaires, et, de ce fait, tend à devenir un langage universel ; FORMAC est spécifique des traitements formels d’expressions mathématiques ; LISP et SNOBOL sont spécialisés dans les traitements de listes ; etc., la seule exception ayant un caractère général étant AP4, langage de type universel, conçu de façon à pouvoir être interprété et non compilé, ce qui l’apparente de ce fait aux langages de type assembleurs traditionnels.