programmation (suite)

Une fois tous les algorithmes décrits, le problème est ramené à un ensemble ordonné de « traitements formels explicites de quantités d’information » (phases). En outre, pour chacune de ces phases, il a été nominalement défini l’ensemble des informations qu’elle doit utiliser, que ce soit en entrée, en cours d’exécution ou en sortie. Jusqu’à présent, l’ensemble E des données (ou informations) à manipuler au cours de ces phases a été considéré comme formant un tout. Cependant, pour simplifier les explicitations des algorithmes et en faciliter la réalisation, il apparaît naturel de différencier nominativement les éléments de cet ensemble, ceci en tenant compte de toutes les informations précédemment acquises (nature de l’information, mode d’utilisation, etc.). Pour cela, il faudra reconnaître les sous-ensembles de l’ensemble E caractéristiques d’un traitement et les munir de la structure qui soit la mieux adaptée, c’est-à-dire définir les fichiers associés au problème. Fréquemment, un même sous-ensemble A de l’ensemble E doit être muni de plusieurs structures distinctes, et chaque couple [A, structure] définira un nouveau fichier.

L’analyse fonctionnelle

À ce stade de l’étude, le traitement du problème est entièrement explicité sous l’angle de la logique, donc indépendamment de toutes considérations relatives à un ordinateur particulier. Or, l’utilisation d’un ordinateur donné va introduire d’une part des contraintes hardware (taille de la mémoire centrale, nombre et capacité des unités périphériques disponibles, temps de traitement d’une instruction, temps d’accès aux mémoires auxiliaires, etc.) et d’autre part des contraintes software, liées à l’existence de systèmes généraux d’exploitation (contraintes qui viennent de ce que le système utilise, lui aussi, les ressources hardware). En fonction de ces restrictions et compte tenu des besoins du problème formel, on procède à une étude, dite analyse fonctionnelle, destinée à vérifier si l’ordinateur dont on dispose est capable de traiter le problème, et, si oui, on choisit au mieux entre les ressources disponibles de façon à préciser fonctionnellement son énoncé.

En premier lieu, il faut vérifier que les formes matérielles sous lesquelles seront fournies les données externes du problème sont compatibles avec le hardware dont on dispose. Au cas où il n’y aurait pas compatibilité directe, on prévoira la réalisation (ou l’achat) d’interfaces hardware (par exemple dans le cas d’arrivée d’informations analogiques sur un calculateur digital) ou software (par exemple écriture d’un programme de traduction d’informations digitales fournies en un certain code en informations digitales codées différemment).

Ensuite, il faut s’occuper des possibilités d’implantation des fichiers du problème. Pour cela, dans un premier temps, on classe ceux-ci en fonction de leur utilisation prévue : on sépare ceux qui seront utilisés de façon séquentielle et qui donc pourront, éventuellement, être physiquement implantés sur bande magnétique, feuillet magnétique, etc., de ceux qui, pouvant être utilisés de façon sélective, devront, au moment de leur utilisation, en tant que tels, être mis sur support adressable (mémoire centrale, disques magnétiques, etc.). Cette distinction faite, on choisit, en fonction de leurs performances, les supports des fichiers séquentiels. Le problème est beaucoup plus délicat pour les fichiers de type sélectif. En effet, la nature et la fréquence des questions qui peuvent leur être posées vont influer de façon sensible sur leur structuration interne, et ce par le biais des méthodes d’accès. Par suite, pour un fichier sélectif, c’est seulement en connaissant le nombre maximal des articles qu’il est susceptible de contenir, la dimension de ceux-ci et la méthode d’accès qui lui est relative que l’on peut déterminer sa taille réelle ; finalement, c’est en fonction de cette taille, des facilités d’implantation et performances possibles de la méthode d’accès que l’on pourra définir le support de ces fichiers. Cette dernière étude est fondamentale, sa conclusion pouvant être l’impossibilité de traiter ce problème sur cet ordinateur.

Une fois cette étape franchie, on estime la taille qu’aura, une fois réalisé, le programme associé au problème, et, en fonction de la place encore disponible en mémoire centrale, on détermine la structure qu’il convient de lui donner. S’il y a suffisamment de place, le programme pourra être réalisé d’un seul tenant, sinon il devient nécessaire de le morceler. Dans ce dernier cas, s’il reste de la place en mémoire auxiliaire, on prévoira la réalisation d’un overlay (structuration du programme en maillons logiquement indépendants stockés en mémoire auxiliaire et appelés en mémoire centrale, au fur et à mesure des besoins, dans un ordre déterminé par un maillon directeur) ; autrement, on sera amené à réaliser un chaînage. Cette structure, moins souple que la précédente, consiste à découper le programme global en une suite de programmes indépendants ordonnés une fois pour toutes, le programme n + 1 ne pouvant être chargé en machine que lorsque l’exécution du programme n est terminée, les résultats des programmes étant stockés dans des fichiers résidant en machine pendant l’exécution de la chaîne entière, les résultats des programmes 1, ..., n servant éventuellement de données au programme n + 1. Cette dernière analyse, ainsi qu’une partie de celle qui précède, était, la plupart du temps, indispensable lorsqu’on ne disposait que d’un « petit » ordinateur classique. À l’avenir, il est fort vraisemblable qu’elle tendra à disparaître et ne sera plus effectuée que dans quelques cas très particuliers : lorsqu’on souhaitera rendre les programmes, résidant fréquemment en mémoire centrale, très optimaux quant à leur encombrement (cas de certaines parties du système d’exploitation par exemple).

En effet, les ordinateurs récents sont maintenant munis de générateurs-simulateurs de mémoire virtuelle qui permettent à l’utilisateur de faire comme si la mémoire centrale à laquelle il a accès avait une capacité pratiquement illimitée.