Brevet FR2729773A1 — publié le 19960726

La présente invention concerne un système automatique de génération de programmes qui peut produire tous les programmes d'application à un niveau de qualité constant et un document de réalisation standardisé en correspondance parfaite avec le programme produit. L'utilisation effective d'un ordinateur nécessite un programme d'application convenable, adapté au service de l'utilisateur, mais ce programme d'application a jusqu'ici été préparé principalement en fonction de la personnalité du concepteur de programme. Lorsqu'un tel programme d'application a été achevé, l'utilisateur reçoit généralement les codes résultants et le manuel de fonctionnement pour le programme et fait fonctionner le programme d'application en conformité avec le manuel. Si l'on trouve que le programme d'application ne fonctionne pas normalement, une demande de maintenance est faite de manière à ce que le programme puisse avoir un fonctionnement normal. Lors de l'achèvement du programme, l'utilisateur reçoit parfois une liste de codes-source et un document montrant les contenus de l'étude mais ce document doit être préparé manuellement et comme il faut consacrer beaucoup de temps pour son achèvement, l'utilisateur ne reçoit pas nécessairement un document complet. Par ailleurs, même si le programme d'application fonctionne normalement, l'utilisateur peut souvent souhaiter modifier les contenus de son traitement pour rester au courant de l'évolution du temps et des changements dans son service, mais le matériel traditionnel souffre de l'inconvénient qu'un programme d'application une fois achevé ne peut être modifié facilement. Ainsi, dans le cas o la liste des codes- source du programme est absente ou que la liste des coudes-source a perdu sa correspondance avec les codes résultants à cause, par exemple, de la maintenance du 2 2729773 programme, même une modification mineure des contenus de traitement du programme nécessite énormément de temps, avec le résultat qu'un nouveau programme d'application doit être reconstruit depuis le début comme cela a été souvent le cas dans le passé. En outre, même lorsqu'on dispose d'une liste complète de codes-source, chaque programme a une personnalité ayant son origine dans l'aptitude et l'habileté du concepteur de sorte qu'une troisième personne ne peut facilement saisir les contenus du traitement. Par conséquent, il faut beaucoup de temps pour qu'il modifie les contenus et dans certains cas l'ensemble du programme cesse de fonctionner correctement par suite de telles modifications. En outre, dans le cas o les divers documents sont mis à disposition à partir des archives, les contenus réels du traitement ne sont pas exactement reflétés dans les documents, et même si les contenus ont été décrits avec précision, tous sont indiqués en utilisant des formats différents de sorte qu'il est assez difficile pour une troisième personne de saisir les contenus du programme. Etant donné qu'il est essentiel de modifier les programmes d'application au cours du temps, le programme fourni à l'utilisateur doit permettre une révision et une addition aisées à des moments ultérieurs. Pour être spécifiques, les programmes d'application doivent avoir une qualité uniforme, ne dépendant pas de la personnalité du concepteur et des contenus de traitement d'un programme fourni à l'utilisateur doivent être tels qu'une personne quelconque puisse les comprendre avec précision. Ayant été développée en fonction de l'analyse raisonnée ci- dessus, la présente invention a pour objet de fournir un générateur automatique de programmes qui puisse produire automatiquement des programme d'application de qualité constante qui ne dépendent pas de la personnalité du 3 2729773 concepteur et sortent des documents de réalisation standardisés exposant les contenus de la conception. Pour exécuter l'objet précédent, le générateur automatique de programmes de la présente invention comprend (1) un moyen de mémoire stockant les squelettes qui sont des programmes-source semi-finis, (2) un moyen de mémoire stockant les documents de réalisation semi-finis qui décrivent les contenus du traitement des squelettes respectifs, (3) un moyen d'entrée d'information individuelle qui fonctionne au stade de l'étude de chaque programme d'application pour recevoir une information individuelle variant avec les différents programmes d'application par dialogue, (4) un moyen d'exécution de programme qui, sur la base de l'information individuelle reçue, édite lesdits squelettes et génère des codes-source pour les programmes d'application respectifs, (5) un moyen d'exécution de document de réalisation qui, sur la base de l'information individuelle reçue, édite ledit document de réalisation à l'état semi-fini et exécute un document de réalisation correspondant à chaque programme d'application, et (6) un moyen de sortie qui agit en réponse à une manipulation approximative pour sortir la liste des codes-source et/ou un document de réalisation du programme d'application terminé. Le moyen de mémoire de squelette stocke des programmes-source semi-finis (squelettes) de façon que plusieurs sortes de programmes d'application puissent être mises en oeuvre. Ces squelettes sont classés généralement en programmes d'un premier groupe qui enregistrent les données dans un fichier de transactions, en programmes d'un second groupe qui recherchent la donnée d'un fichier de données, et l'affiche sur l'écran d'un terminal, en programmes d'un troisième groupe qui enregistrent les données dans un fichier-maître, en programmes d'un quatrième groupe qui recherchent la donnée d'un fichier de données et l'affiche dans la fenêtre de l'écran d'un terminal, en 4 2729773 programmes d'un cinquième groupe pour l'impression des contenus du fichier des données sous une forme commerciale, et en programmes d'un sixième groupe qui mettent à jour les contenus d'un fichier maître et/ou d'un fichier temporaire en fonction de la donnée d'un fichier de transactions. Dans la présente invention, les programmes d'application sont produits en utilisant ces programmes du premier au sixième groupes dans des combinaisons appropriées. Dans la présente invention, un document de réalisation correspondant à chaque squelette est mémorisé à l'état semi-fini. Sur la base de l'information individuelle entrée par dialogue, le document de réalisation à l'état semi-fini est édité pour fournir un document de réalisation correspondant complètement à chaque programme d'application. Comme les squelettes sont classés en six groupes principaux, le format du document de réalisation et les articles d'entrée peuvent être facilement standardisés. En outre, comme les documents de réalisation ont été standardisés, il est également facile pour un tiers de comprendre les contenus de chaque réalisation. La présente invention sera bien comprise lors de la description suivante faite en liaison avec les dessins ci-joints, dans lesquels: La figure 1 est un schéma sous forme de blocs du générateur automatique de programme comme mode de réalisation de la présente invention; La figure 2 est un schéma de la construction d'un squelette; La figure 3 est un schéma montrant des différences parmi les configurations de réalisation 1 à 7; La figure 4 est une vue d'un justificatif typique d'achat; La figure 5 est une vue représentant un fichier typique de transactions dans lequel les données 2729773 du justificatif d'achat illustré en figure 4 sont enregistrées; La figure 6 est un organigramme représentant les contenus du traitement des configurations de réalisation 1 et 2; La figure 7 est une vue représentant un affichage typique d'une fenêtre pour mettre en oeuvre un changement dans le mode action; La figure 8 est une vue représentant un fichier typique de transactions dans lequel les données du justificatif d'achat illustré en figure 4 sont enregistrées; La figure 9 est un organigramme représentant les contenus du traitement des configurations de réalisation 3, 4 et 5; La figure 10 est un schéma représentant un exemple de données du type édition; La figure 11 est une vue représentant un fichier typique de transactions dans lequel sont enregistrées les données du type édition; La figure 12 est un organigramme représentant les contenus du traitement des configurations de réalisation 6 et 7; La figure 13 est un organigramme représentant les contenus du traitement d'un squelette SKOlO; La figure 14 est un organigramme représentant les contenus du traitement d'un squelette SKOlO; La figure 15 est une vue représentant spécifiquement une partie des contenus du traitement d'un squelette SKOlO; La figure 16 est un organigramme représentant les contenus du traitement de la configuration de réalisation 11; La figure 17 est un organigramme représentant les contenus du traitement des configuration de réalisation 12, 13 et 14; 6 2729773 La figure 18 est une vue représentant un fichier maître typique; La figure 19 est un organigramme représentant les contenus du traitement des configurations de réalisation 15-29; La figure 20 est une vue permettant d'expliquer une fonction de reproduction; La figure 21 est un organigramme représentant les contenus du traitement du squelette du type WNO10; La figure 22 est une vue représentant un affichage de fenêtre; La figure 23 est un schéma représentant les contenus du traitement du squelette LTO20; La figure 24 est un schéma représentant les contenus du traitement du squelette LTO21; La figure 25 est une vue représentant une copie sur papier des contenus d'un fichier de transactions telle quelle est obtenue avec le squelette du type LTO21; La figure 26 est un schéma représentant les contenus du traitement du squelette LTOlO; La figure 27 est un schéma représentant les contenus du traitement du squelette LT030; La figure 28 est un schéma représentant les contenus du traitement du squelette LTO40; La figure 29 est un schéma représentant les contenus du traitement du squelette BU020 (configuration de réalisation 35); La figure 30 est un schéma représentant les contenus du traitement du squelette BUOlO; La figure 31 est un schéma représentant la procédure de réalisation pour un fichier physique; La figure 32 est une vue représentant un document de réalisation d'un fichier physique (base de données); La figure 33 est une vue représentant la liste des codes-source appartenant au fichier physique; 7 2729773 La figure 34 est une vue représentant la procédure de réalisation pour un fichier d'écran; La figure 35 est une vue représentant une partie du document de réalisation du fichier d'écran; La figure 36 est une vue représentant une autre partie du document de réalisation du fichier d'écran; La figure 37 est une vue représentant la liste des codes-source appartenant au fichier physique; La figure 38 est un schéma représentant la procédure pour la réalisation brute d'un programme (enregistrement des informations unitaires); La figure 39 est un schéma représentant la procédure pour la réalisation détaillée d'un programme; La figure 40 est une vue représentant une partie d'un squelette MMOll; La figure 41 est une vue représentant une partie de la liste des codes-source pour un programme d'application produit automatiquement. La figure 1 représente un générateur automatique de programmes comme premier mode de réalisation de l'invention, générateur qui est constitué essentiellement d'un corps 1 de système et de stations de travail WSl-WSn. Alors que le générateur de la figure 1 peut être constitué d'un système IBM AS/400, on peut également construire un générateur similaire en utilisant une autre marque d'ordinateur. Le corps 1 du système comprend un processeur central 2, un moyen 3 de mémoire sur disque et un moyen de mémoire principale 4, et en option, une imprimante 5 connectée opérationnellement au corps 1. La station de travail WS est un terminal d'entrée/sortie équipé d'un élément d'affichage cathodique 6 et d'un clavier 7 entre autres choses, et si nécessaire, une imprimante 8 est reliée au terminal. Dans le générateur automatique de programmes de la figure 1, les codessource et résultants d'un programme d'application sont automatiquement produits 8 2729773 simplement alors que l'utilisateur passe par les procédures de réalisation du fichier physique, du fichier d'écran, du fichier des formules commerciales et la réalisation des programmes par manipulation par dialogue à la station de travail WS. Cependant, la liste des codes-source correspondant fidèlement aux codes résultants engendrés, et divers documents de réalisation correspondant fidèlement auxdits codes résultants (document de réalisation de la base de données, document de réalisation du fichier d'écran, document de réalisation des programmes) sortent également comme des copies sur papier. Incidemment, le langage de programme qui peut être utilisé n'est pas particulièrement limité. Ainsi, divers langages, tels que le langage RPG, le langage C, le langage COBOL, etc. peuvent être employés. Cependant, dans la description suivante du mode de réalisation, on explique la génération d'un programme d'application dans le langage GPE (générateur de programme d'édition). Avec le générateur automatique de programmes représenté en figure 1, pour la mise en oeuvre des traitements ci-dessus, tous les traitements informatiques sont groupés en 36 solutions différentes et les programmes pour la mise en oeuvre de ces solutions sont stockés sous forme de 34 programmes différents de squelettes dans le moyen 3 de mémoire sur disque. Chacun des 34 squelettes différents est un programme-source à l'état semi-fini et est constitué d'une portion individuelle B qui est changée pour chaque traitement et d'une portion de corps A qui n'est pas changée (figure 2). La portion individuelle B est déterminée en fonction de l'information entrée à partir du clavier 7 dans l'étage de réalisation d'un fichier physique, d'un fichier d'image, d'un fichier de livre ou d'un programme. Comme chaque squelette est un programme de haute qualité préparé par un programmeur spécialisé et que la réalisation du programme d'application est mise 9 2729773 en oeuvre par dialogue dans la station de travail WS, le générateur automatique de programme de la présente invention permet même à un novice de compléter facilement et rapidement un programme d'application de haute qualité. En outre, comme tous les programmes sont construits par des combinaisons diverses des 34 squelettes différents, le format des divers documents de réalisation peut être standardisé et, de plus, divers documents de réalisation peuvent être mémorisés à l'état semi-fini dans le moyen 3 de mémoire sur disque. Pour ces raisons, dès qu'un programme d'application est achevé, les divers documents de réalisation correspondant finalement au programme peuvent être imprimés. En outre, étant donné que ces documents ont été standardisés en matière de format, n'importe qui peut saisir facilement et précisément les contenus de traitement du programme d'application. Dans le passé, ces divers documents de réalisation n'étaient pas fournis à l'utilisateur ou s'ils étaient fournis, ne correspondaient pas parfaitement au programme. Etant donné qu'avec le générateur de programme de la présente invention, les documents de réalisation correspondant fidèlement au programme d'application sont fournis, n'importe qui peut revoir ou modifier aisément le programme d'application de sorte que la valeur du programme d'application fourni à l'utilisateur est encore augmentée. Ainsi, dans le dispositif de la présente invention, le programme d'application désiré peut être constitué de l'une quelconque des 36 solutions différentes ou d'une combinaison de celles-ci. Les 36 solutions différentes sont classées en gros dans les catégories suivantes: 1. le traitement du système d'entrée (configurations de réalisation 1-7); 2. le traitement du système d'interrogation (configurations de réalisation 8-14); 3. le traitement du système de maintenance maître (configurations de réalisation 15- 2729773 22); 4. le traitement de système d'interrogation de fenêtre (configurations de réalisation 23-26); 5. le traitement du système d'impression de justificatif d'achat (configurations de réalisation 2734); et 6. le traitement du système de mise à jour par lots (configurations de réalisation 35-36). 1. Traitement du système d'entrée (configurations de réalisation 1-7). L'expression "traitement du système d'entrée" signifie un traitement concernant un fichier de transactions qui accumule les données pour la mise à jour d'un fichier maître. Selon les caractéristiques des données traitées, ce traitement du système d'entrée est classé en 7 sortes de traitements (configurations de réalisation 1-7) et ces traitements des configurations de réalisation 1-7 sont mis en oeuvre par les squelettes des types ET010, ETOl1, ET050, ET051, ET052, ET150 et ETl53, respectivement (figure 3). Comme représenté en figure 3, le traitement du système d'entrée est divisé en configurations de réalisation 1-5 et configurations de réalisation 6-7. Les configurations 1-5 sont des solutions convenant au traitement des données du type justificatif d'achat, alors que les configurations 6- 7 sont des solutions convenant à la manipulation des données du type édition. L'expression 'données du type justificatif signifie un groupe de données désigné par un numéro de justificatif, et de façon que les données dans la partie spécification soient affectées à des numéros de ligne et enregistrées dans le fichier des transactions. Un cas est donné par les données du justificatif d'achat 11 représenté en figure 4. Le justificatif d'achat 11-1 1-3 est constitué d'une partie spécification llb indiquant l'"article d'achat", le "prix d'achat unitaire et la "quantité de l'achat" et une partie en-têtes lla contenant une information commune aux données de la 11 2729773 partie spécification llb. Dans le cas de la figure 4, les informations dans la partie en-têtes lla comprennent le "fournisseur", la "date d'achat" et la personne en charge de l'achat". Le numéro du justificatif et le numéro de ligne sont maintenant expliqués plus en détail. Les trois justificatifs d'achat représentés en figure 4 sont identifiés par les numéros de justificatif 0001-0003 et les données dans la partie spécification llb de chaque justificatif sont affectées avec les numéros de ligne et enregistrées dans le fichier des transactions. Par conséquent, ces donnés peuvent être traitées pour le même "article d'achat" même si elles sont différentes quant au "prix d'achat unitaire". Si l'on prend le justificatif d'achat 11 de la figure 4 à titre d'exemple, on décrira maintenant les configurations de réalisation 1 à 5. [Confiaurations de réalisation 1. 21 Sauelettes ETO1,. ET011 Le programme des configurations de réalisation 1, 2 est complété en établissant la portion individuelle B (figure 2) des squelettes types ETO10 et ETOll par entrée de l'information provenant de la station de travail WS. Pour enregistrer les données du type justificatif dans le fichier des transactions, l'emploi des configurations 1 à 5 est préféré et les configurations particulières 1, 2 sont convenables lorsque la quantité des informations dans la portions en-têtes lia est grande. De plus, comme représenté en figure 5A, les données dans la partie en- têtes lla sont enregistrées dans un fichier d'en-têtes 12, et les données dans la partie spécification llb sont enregistrées dans un fichier de spécifications 13 (figure 5B). Si l'on prend le fichier en-têtes 12 de la figure 5A comme exemple, le justificatif d'achat 11 de 12 2729773 la figure 4 comporte les champs de numéro de justificatif 12a, la date du justificatif 12b, le nom du fournisseur 12c, la personne en charge de l'achat 12d, la somme des prix d'achat 12e. De plus, par exemple, le "numéro du justificatif", la "date du justificatif" et le "nom du fournisseur" sont utilisés comme clés pour la recherche des données. D'autre part, le fichier spécification 13 a, par exemple, les champs du numéro de justificatif 13a, de la date du justificatif 13b, du nom du fournisseur 13c, du numéro des lignes du justificatif 13d, l'article d'achat 13e, le prix d'achat unitaire 13f, et la quantité achetée 13g. En outre, par exemple, le "numéro de justificatif", la "date du justificatif", le "nom du fournisseur" et le "nombre de lignes du justificatif" sont utilisés comme clés de recherche des données. Comme le "nombre de lignes du justificatif" est enregistré et est une clé pour la recherche des données, il est possible de spécifier chaque enregistrement équivalent des données par le numéro de ligne et exécuter la suppression et la reproduction sur la base ligne par ligne. En liaison maintenant avec l'organigramme de la figure 6, le traitement de la configuration 1 (squelette ETOlO) sera maintenant décrit brièvement. Alors que cette configuration 1 met en oeuvre les traitements d'enregistrement, révision ou élimination des données du type justificatif, les actions d'un "programme de traitement du justificatif d'achat" relatives aux données du justificatif d'achat 11 de la figure 4, comme mode de réalisation de la configuration 1, sont maintenant expliquées. Lorsque le "programme de traitement du justificatif d'achat" est choisi dans le menu (ST1), un écran pour l'entrée des données clés pour le fichier d'en-têtes 12 est affiché à la station de travail WS (ST2). Comme le mode action initiale du "programme de traitement du justificatif d'achat" est le mode 13 2729773 enregistrement, le traitement pour l'enregistrement frais des données du justificatif d'achat 11 sera maintenant expliqué. Dans l'étape ST2, l'écran pour l'entrée de l'information contenue dans le numéro du justificatif, la date du justificatif, et les colonnes 12a, 12b et 12c du nom du fournisseur est affiché. Par conséquent, l'opérateur entre l'information correspondante (qu'on désigne ci-après par codes ID) en utilisant des chiffres et des symboles. En fonction de la réalisation de la portion individuelle du squelette ETO10O, le "numéro du justificatif" est automatiquement sélectionné et dans ce cas, l'entrée du "numéro de justificatif n'est pas nécessaire. Alors que "la date du justificatif le "nom du fournisseur", etc. sont entrés à la station de travail, un écran pour l'entrée d'une information autre que la donnée de clé du fichier à en-têtes 12 est affiché (ST3). Comme, dans cet exemple, la "personne chargée de l'achat" doit être entrée, l'opérateur entre le code ID correspondant pour la "personne chargée de l'achat". Incidemment, si une touche de fonction F12 est pressée dans l'étape ST3, la séquence revient à l'étape ST2 de sorte que l'écran pour l'entrée de la donnée de clé du fichier d'en-têtes 12 est affiché. D'autre part, la touche "Entrée" de la station de travail est pressée dans l'étape ST3, la séquence passe à l'étape (ST4) pour l'entrée de la donnée de la partie spécification llb du justificatif d'achat 11, de sorte que l'opérateur entre les codes ID correspondants pour "article d'achat", "prix d'achat unitaire" et "quantité achetée". A l'issue de l'entrée de la donnée de la partie spécification llb du justificatif d'achat 11, l'opération pour la multiplication du "prix unitaire d'achat" par la "quantité achetée" et l'opération pour l'addition des produits et les résultats des opérations respectives sont affichées à la station de travail (ST5). En même 14 2729773 temps, un message recommandant à l'opérateur de confirmer les données d'entrée est affiché (ST5). Alors que l'opérateur appuie sur la touche "Entréen, les données affichées sur l'écran sont enregistrées dans le fichier d'en- têtes 12 et dans les zones correspondantes du fichier des spécifications 13 (ST6). Si nécessaire, les contenus du fichier maître (par exemple, un fichier maître d'inventaire) sont mis à jour (ST7). Si une touche de fonction F12 est pressée dans l'étape de traitement pour l'entrée des données de la spécification (ST4) ou le traitement d'affichage d'un message de confirmation (ST5), la séquence revient au traitement de l'étape ST3. Si une touche de fonction F3 est pressée pendant le traitement de l'étape ST2-ST5, l'affichage du menu de l'étape ST1 reprend. Dans le cas du programme de la configuration 1, comme d'autres configurations de réalisation, le traitement de la fenêtre peut être effectué. L'expression traitement de la fenêtre" signifie un traitement qui supporte le traitement de l'étape ST2-ST5 par utilisation d'une partie (zone W de la fenêtre) de l'écran cathodique EC à la station de travail (figure 7). Le traitement de fenêtre est constitué d'un traitement essentiel et d'un traitement en option et le traitement en option est sélectivement adopté ou omis lors de l'établissement de la portion individuelle des squelettes ETOlO, ET011. Les traitements de fenêtre qui ont été choisis en option ont été préparés par les squelettes WNOlO, WNOll, WN012 et WN20 qu'on décrit ci- après. Dans les configurations 1, 2, le traitement du changement de mode avec une touche de fonction F5 et le traitement des lignes avec une fonction F9 sont des opérations essentielles, alors que le traitement de recherche d'un code avec une touche de fonction F4 est un traitement optionnel choisi lors de l'établissement de la portion individuelle du squelette. 2729773 L'expression "traitement du changement de mode" signifie un traitement pour changer le mode action courante du programme pour le faire passer au mode enregistrement des données, au mode révision ou au mode suppression, et alors qu'une touche de fonction F5 est pressée dans le stade de traitement de l'étape ST2, il y a exécution du changement de mode par le traitement W de la fenêtre. Par exemple, si l'on suppose que '2' est entré dans l'état indiqué en figure 7, le mode action du "programme de traitement du justificatif d'achat" est changé en mode révision, et par les traitements de l'étape ST2-ST5, les données enregistrées dans les fichiers de transactions 12 et 13 sont révisées (ST6). Lors du mode révision, les données du justificatif d'achat qui ont été enregistrées dans les fichiers des transactions 12, 13 sont affichées à la station de travail pendant les traitements de l'étape ST2 et de l'étape ST4. Si l'on suppose que "3" est entré dans l'état représenté en figure 7, le mode action du "programme de traitement du justificatif d'achat" est changé en mode suppression et les données du justificatif d'achat spécifiées par le traitement à l'étape ST2 sont supprimées du fichier des transactions 12, 13 (ST6). Dans le mode suppression, seules les données enregistrées du justificatif d'achat sont affichées dans le stade de traitement de l'étape ST4, et le traitement de l'étape ST5 n'est pas exécuté mais sauté. L'expression "traitement des lignes* avec la touche de fonction F9 signifie un traitement exécuté sous la gestion de chaque enregistrement équivalent des données dans le fichier des spécifications 13 par "numéro de ligne" et généralement une opération de reproduction de données sur une ligne donnée à une position ayant un numéro de ligne différent correspond à ce traitement. 16 2729773 L'expression "traitement de recherche de code" avec la touche de fonction F4 signifie un traitement pour récupérer les codes ID qui doivent être entrés. Comme on l'a mentionné ci-dessus, toutes les informations nécessaires dans l'étape ST2-ST5 doivent être entrées en utilisant les codes ID. Par conséquent, si les codes ID pour "ABC Industrial Co.", "panneau d'imprimante" et "Mr Sato" ne sont pas connus, les codes ID correspondants peuvent être recherchés en pressant la touche de fonction F4. Alors que les contenus de l'opération du "programme de traitement du justificatif d'achat" constitué par le squelette ETOlO (configuration 1) sont tels que décrits ci-dessus, sensiblement la même chose s'applique au squelette ET011 (configuration 2) et la seule différence est que l'opération d'addition n'est pas exécutée dans l'étape ST5. Par conséquent, le squelette ET011 (configuration 2) convient pour traiter l'enregistrement, la révision ou la suppression des données du type justificatif et dans le cas o cela n'est pas nécessaire pour l'affichage de la somme totale, etc à la station de travail. [Confiqurations de réalisation 3-51 Sauelettes ETO50,. ET051,. ET052 Les configurations de réalisation 3-5 sont caractérisées en ce qu'aucun fichier d'en-têtes n'est fourni. Elles conviennent pour l'enregistrement tant des données de la partie en-têtes lla que des données de la partie spécification llb du fichier des spécifications 14, typiquement dans le cas des données du type justificatif représentées en figure 4. Un cas est représenté en figure 8. Ainsi, le fichier spécification 14 est constitué d'une partie en-têtes 14A et d'une partie spécification 14B, avec la partie en-têtes 14a ayant les champs discrets du numéro de justificatif 14A1, de la date du justificatif 14A2, du nom du 17 2729773 fournisseur 14A3, et de la personne chargée de l'achat 14A4 et la partie spécification 14B ayant les champs discrets du numéro de ligne 14B1, de l'article acheté 14B2, du prix d'achat unitaire 14B3, de la quantité achetée 14B4 et de la valeur totale 14B5. Le traitement de la configuration de réalisation 3 (squelette ET050) est tel que représenté dans l'organigramme de la figure 9. La comparaison de la figure 9 et de la figure 6 indique clairement que les traitements aux étapes ST1'- ST6' de la figure 9 sont sensiblement identiques aux traitements effectués aux étapes ST1-ST6 de la figure 6, et la configuration de réalisation 3 est différente de la configuration 1 en ce sens qu'un fichier d'en-têtes n'est pas fourni. La configuration de réalisation 4 (squelette ETO51) exécute presque les mêmes traitements que ceux de la configuration 3 représentée en figure 9, mais ce squelette ET051 est différent du squelette ET050 en ce sens qu'aucune opération d'addition n'est exécutée dans le traitement à l'étape ST5' de la figure 9. La configuration de réalisation 5 (squelette ET052) exécute aussi presque les mêmes traitements que la configuration 3 représentés en figure 9, mais ce squelette ET052 est différent du squelette ET050 en ce sens que le traitement effectué à l'étape ST3' de la figure 9 est absent. Ainsi, la configuration 5 est le traitement dans le cas o toutes les données de la partie en-têtes 14A du fichier spécifications 14 sont des clés. Un cas à souligner est celui o, en liaison avec la partie spécifications 14A représentée en figure 8, le numéro de justificatif 14A1, la date du justificatif 14A2 et le nom du fournisseur 14A3 sont utilisés comme clés pour la recherche des données et le champ de la personne chargée de l'achat 14A4 n'est pas fourni. 18 2729773 [Confiauration de réalisation 6-71 Squelettes ET150. ET153 Les configurations de réalisation 6-7 conviennent à l'édition (enregistrement et révision) ou la suppression des données du type édition. L'expression "données du type édition" signifie les données non affectées d'un numéro de justificatif ou d'un numéro de ligne, c'est-à-dire que des données telles que les données de spécification sont utilisées comme clés pour la recherche des données. Un exemple typique de données du type édition est celui de données appartenant au cas dans lequel l'enregistrement quotidien de la maintenance et de l'inspection effectuées par un technicien de service est enregistré dans un fichier de transactions. Comme illustré en figure 10, alors que "Mr Nakao", technicien de service, rend des services tels que "inspection et "maintenance pour "RCC", "NTT et d'autres clients, un enregistrement de son activité quotidienne doit être effectué dans un fichier de transactions, les charges pour chaque mois sont totalisées pour chaque client et une note de débit est préparée. Dans ces cas, la donnée de service devant être enregistrée dans le fichier des transactions ne nécessite pas un numéro de justificatif, etc., il n'est pas nécessaire que les données de la spécification soient accompagnées des numéros de ligne. Par conséquent, l'utilisation des configurations 6 et 7 a la préférence. La figure 11 représente un fichier de transactions 15 pour enregistrer les services effectués par un technicien de service. Ce fichier 15 est constitué d'une partie en-tête 15A et d'une partie spécification 14B, avec la partie 15A ayant les champs des données du service 15A1, du technicien de service A2, et la partie spécification 15B ayant les champs du nom du client 15B1, du contenu du service 15B2, du temps du service en heures 15B3, de la charge unitaire du 19 2729773 service 15B4 et de la valeur totale 15B5. La date du service 15A1, le technicien de service 15A2 et le nom du client 15B1 sont supposés ici être des clés pour la recherche des données. Les contenus de l'action dans un programme d'enregistrement des articles de service" constitué par la configuration 6 (squelette ET150) sont maintenant décrits en liaison avec l'organigramme de la figure 12. Lorsque le "programme d'enregistrement des articles de service" est sélectionné dans le menu (ST10), un écran pour l'entrée des données de clés de la partie en-tête 15A est affiché à la station de travail (STll). Etant donné que "date du service" et "technicien de service" sont des clés dans l'exemple ci- dessus, l'opérateur entre les nombres correspondants et le code ID. Si l'on suppose que l'enregistrement du service du 24 septembre qui s'applique au technicien de service "Nakao" est entré (STll), un écran pour l'entrée de l'information autre que les clés de la partie en-tête 15A est affiché (ST12). Dans cet exemple, il n'y a aucune information à entrer lors de l'étape ST12, mais le nom de la section à laquelle "Nakao" appartient peut être entré. Si une touche de fonction F12 est pressée dans l'étape ST12, la séquence retourne à l'étape STll pour l'entrée de "date de service" et "technicien de service". D'autre part, si la touche "Entréew est pressée dans l'étape ST12, un écran pour l'entrée de la donnée de la partie spécification 15B du fichier des spécification 15 est affiché. Dans cet exemple, comme les enregistrements de service entre le 21 septembre et le 23 septembre ont déjà été enregistrés pour le technicien de service "Nakao", cette information enregistrée est affichée au poste de travail. Par conséquent, à la suite de l'affichage de cette information, l'opérateur entre les codes ID et les chiffres correspondant à "nom du client", "contenu du service", "durée du servie en heures" et "charge 2729773 unitaire du service" (ST13). Si l'on désire réviser ou supprimer les données enregistrées, leur correction est effectuée à cette jonction. A l'issue de l'entrée des données de la partie spécification 15B, l'opération de la multiplication de la "charge unitaire de service" par la "durée du service en heures" et l'opération d'addition des produits sont exécutées et les résultats des opérations respectives sont affichés à la station de travail (ST14). En même temps, un tri est exécuté dans l'ordre des codes ID pour le "nom du client", et l'information sur le service entre le 21 septembre et le 24 septembre pour le technicien de service "Nakao" est triée par client et affichée à la station de travail. Et un message recommandant à l'opérateur de confirmer les données entrées est affiché (ST14). Alors que l'opérateur presse la touche "Entrée", les données sont enregistrées dans le fichier des spécifications (ST15). S'il existe un fichier maître qui a besoin d'être mis à jour, les contenus du fichier maître sont par conséquent mis à jour (ST16). Dans le traitement de l'entrée des données de la spécification (ST13), et le traitement de l'affichage du message de confirmation (ST14), si l'on appuie sur une touche de fonction F12 la séquence revient au traitement à l'étape ST12. Si la touche de fonction F3 est pressée pendant le traitement aux étapes STll-ST14, la séquence revient au traitement de l'écran du menu (STlO). Les contenus de l'action du "programme d'enregistrement des articles de service" dans le mode édition ont été décrits. Lorsque le mode d'action est le mode suppression, les données de "la date de service spécifiées pour le "technicien de service" correspondant sont supprimées en bloc. Le traitement de la fenêtre est ici identique à celui de la configuration 1. Ainsi, le traitement du changement de mode avec la touche de fonction F5 et le traitement des lignes avec la touche 21 2729773 de fonction F9 sont des traitements essentiels, alors que le traitement de la recherche d'un code avec la touche de fonction F4 est un traitement optionnel qui est sélectionné lors de l'établissement de la portion individuelle du squelette. La configuration 7 (squelette ET153) est sensiblement identique à la configuration 6, les seules différences étant que le traitement à l'étape ST12 est absent et que l'opération d'addition à l'étape ST14 n'est pas exécutée. Ainsi, dans le cas o toutes les données de la partie en-tête 15A sont des données de clé et que l'opération d'addition pour la partie spécification 15B n'est pas nécessaire, l'utilisation de la configuration 7 constitue un choix judicieux. 2. Traitement du système d'interrogation (configurations de réalisation 8-14) Les configurations de réalisation 8-14 sont des traitements appartenant aux cas dans lesquels un ordre pour la récupération de l'information est effectué entre la station de travail WS et le moyen 3 de mémoire sur disque. Ces configurations sont classées en deux groupes principaux, à savoir les configurations 8-11 qui sont utiles pour les situations dans lesquelles les données à rechercher ne peuvent être spécifiées clairement et les configurations 12-14 qui sont utiles pour les situations dans lesquelles les données interrogées peuvent être spécifiées d'une façon pratiquement claire. Les configurations 8-11 sont constituées par la combinaison squelette SKOl0 avec les squelettes SKO20, SK021, SKO40 et SKO41, alors que les configurations de réalisation 12-14 sont constituées des squelettes SK050, SK051 et SK060, respectivement. Ainsi, Configuration de réalisation 8 = SK010 + SKO20 Configuration de réalisation 9 = SK010 + SKO21 Configuration de réalisation 10 = SK010 + SK040 22 2729773 Configuration de réalisation 11 = SKO10 + SKO41 Configuration de réalisation 12 = SK050 Configuration de réalisation 13 = SK051 Configuration de réalisation 14 = SKO60. Ici, les squelettes SKO20, SKO21, SK050 et SK051 conviennent pour interroger les données du fichier des transactions, alors que les squelettes SKO40, SKO41 et SK060 conviennent pour interroger les données du fichier maître. [Configuration de réalisation 8, configuration de réalisation 91 Squelettes SKO10 + SK020o. SK021 Comme représenté en figure 13, le squelette SKOlO est un squelette comprenant un traitement (ST22) pour entrer les conditions pour les données interrogées et les traitements (ST23-ST25) pour spécifier le programme d'interrogation. Alors que les configurations 8, 9 sont des combinaisons du squelette SKOlO avec les squelettes SK020, SK021, les squelettes SK020 et SKO21 conviennent pour afficher les données du fichier des transactions enregistrées par les programmes des configurations 1-7. En supposant qu'un "programme d'interro- gation des justificatifs d'achat" est constitué des squelettes SKO10 et SK020 en combinaison, les actions de la configuration 8 et de la configuration 9 sont maintenant décrites brièvement (figure 13). On suppose aussi que les données du justificatif d'achat (figure 4) ont déjà été enregistrées dans le fichier des en-têtes 12 et le fichier des spécifications 13 comme représenté en figure 5. Alors que le "programme d'interrogation du justificatif d'achat" est choisi dans le menu (ST21), un écran pour l'entrée de la condition est tout d'abord affiché à la station de travail (ST22). Dans cet état, l'opérateur doit entrer la condition pour les données interrogées. On suppose que l'opérateur entre la gamme 23 2729773 de données, par exemple, "3 octobre-10 octobre de l'année 1994" (ST22). Alors, le fichier d'en-têtes 12 est recherché avec la gamme des données ci-dessus utilisée comme clé et, comme résultat, toutes les données correspondantes sont affichées sur l'écran cathodique à la station de travail (ST23; figure 14). Comme représenté en figure 14, la liste affichée à la station de travail contient une colonne "code action". L'expression "code action" signifie un code qui détermine lequel des programmes d'interrogation sortant un affichage des données interrogées doit être utilisé dans la mise en oeuvre du traitement des interrogations. Ici, les codes action "1" et "2" correspondent aux programmes d'interrogation PRG1 " et "PRG2", respectivement. Dans cet exemple, on suppose que le programme d'interrogation "PRG1" est constitué du squelette SK020 alors que le programme d'interrogation "PRG2" comprend le squelette SK021. En réponse à la désignation d'un code action, le traitement soit du programme d'interrogation "PRGl" soit du programme d'interrogation "PRG2" est démarré (ST25). On suppose que la seconde ligne de l'écran de la figure 14 est choisie en déplaçant le curseur et le programme d'interrogation "PRG1" est sélectionné avec le code action. Alors, avec le numéro de justificatif "1", la date du justificatif "3/10/1994" et "ABC Industrial Co." utilisés comme clés de recherche, le fichier 13 des spécifications est recherché et les données du type justificatif correspondantes sont affichées à la station de travail. Les points ci-dessus sont les contenus du traitement de la configuration 8. La même chose d'applique sensiblement lorsque le programme d'interrogation "PRG2" est sélectionné avec le code action. La seule différence est que l'opération de multiplication du prix unitaire d'achat par la quantité achetée pour chaque article d'achat et l'opération pour l'addition des produits sont 24 2729773 exécutées et les résultats sont affichés à la station de travail. Ce qui précède sont les contenus du traitement de la configuration 9. Ce squelette SK021 (configuration 9) est différent du squelette SKO20 (configuration 8) seulement en ce que lesdites opérations sont exécutées et que les résultats sont affichés. [Confiauration de réalisation 101 Sauelettes SKO10 + SK040 La configuration 10 est constituée des squelettes SKOlO et SK040 en combinaison. Le squelette SK040 convient pour afficher les données du fichier maître enregistrées par les configurations 15-22. Par exemple, dans le cas o un "fichier maître des clients" du type illustré en figure 18 est interrogé, en supposant que la condition d'interrogation est le code client "0020-0030" (ST22 en figure 13), une liste des noms des sociétés correspondantes est affichée comme représenté en figure 15 (ST23). Par conséquent, le curseur est déplacé jusqu'à la position du client interrogé et le code action est entré (ST24), à la suite de quoi le traitement du programme d'interrogation spécifié par le code action est démarré et l'information correspondante est affichée à la station de travail (ST25). Dans la configuration 10, ce programme d'interrogation est constitué par le squelette SKO40, alors que le squelette SK040 met en oeuvre le traitement pour afficher les données du fichier maître à la station de travail. [Confiauration de réalisation 111 Sauelettes SK010 + SK041 La configuration 11 est une configuration constituée des squelettes SK010 et SKO41 en combinaison et exécute sensiblement le même traitement que la configuration 10 pour afficher les données du fichier 2729773 maître à la station de travail. La figure 16 est un organigramme représentant une esquisse du traitement du squelette SKO41. La différence de ce squelette avec le squelette SK040 est que les données sont affichées sur deux écrans à la station de travail. Par conséquent, la configuration 11 est efficace dans les cas o un enregistrement est abondant en données et ne peut être accueilli dans un seul écran. Comme représenté en figure 16, les touches de fonction F8 et F7 sont utilisées pour le passage entre un premier écran et un second écran. rConfiaurations de réalisation 12. 13. 141 Sauelettes SK050. SKO51,. SK060 Les configurations 12-14 sont caractérisées en ce qu'un traitement d'affichage de liste, tel qu'il est effectué par le squelette SKO0lO, n'est pas exécuté. Ainsi, alors que les configurations 8-11 sont utiles pour les situations o les données à rechercher ne peuvent être spécifiées de manière précise, les configurations 12-14 sont utiles pour les situations dans lesquelles les données interrogées peuvent être spécifiées de façon plus ou moins précise. De plus, les configurations 12 et 13 sont sensiblement identiques aux configurations 8 et 9 sauf que les données correspondantes ne sont pas affichées sous la forme d'une liste, et conviennent comme référence aux contenus du fichier des transactions. La configuration 14 est presque identique à la configuration 10 et convient comme référence aux contenus du fichier maître. Dans le cas du programme de la configuration 12 (squelette SKO50), un écran pour l'entrée par touche est tout d'abord affiché à la station de travail (ST42) comme représenté en figure 17. On suppose, par exemple, qu'en ce qui concerne le fichier de spécifications 14 de la figure 8, le "numéro du justificatif", la "date du justificatif et le code ID du "fournisseur" sont entrés. Alors, le fichier 14 est recherché en les 26 2729773 utilisant comme clés et les données de spécification du numéro du justificatif correspondant sont affichées à la station de travail. Si dans le cas o les données de spécification recherchées sont sur l'écran (ST43), une touche de fonction F12 est pressée, la séquence revient à l'étape ST42 avec les données entrées par touche sont sauvegardées. Quels que soient les états, le fait d'appuyer sur la touche de fonction F3 efface l'affichage et le menu (ST41) reprend. Le traitement de la recherche de code avec la touche de fonction F4 est un traitement de fenêtre choisi de manière facultative et avec n'importe quel programme d'application avec ce traitement choisi, des codes ID peuvent être recherchés au stade de traitement de l'étape ST42. Le squelette SK051 (configuration 13) exécute sensiblement le même programme que le squelette SK050 mais est différent de ce dernier en ce sens qu'une opération d'addition de données interrogées est exécutée et que le résultat est affiché. Le squelette SK060 (configuration 14), qui est sensiblement identique au squelette SKO40, convient pour afficher des données du fichier maître enregistrées par les configurations 15-22. Par exemple, lors de l'entrée par touches, l'information correspondante est récupérée dans le fichier maître et un enregistrement équivalent de données est affiché à la station de travail. 3. Traitement du système de maintenance maître (configurations de réalisation 15-22) L'expression "traitement du système de maintenant maître" signifie un traitement pour l'enregistrement, la révision, la suppression ou l'affichage d'un enregistrement équivalent des données dans le fichier maître. Pour le traitement du système de maintenance maître, des configurations de réalisation -22 sont disponibles pour un emploi sélectif en 27 2729773 fonction de la quantité d'un enregistrement équivalent de données et les squelettes MM010, MMOll, MMO20, MMO21, MM030, MM031, MM050 et MM051 correspondent à ces configurations, respectivement. Ainsi, les squelettes MMO10 et MM01l sont utilisés pour afficher un enregistrement équivalent des données pour lequel un écran suffit. Les squelettes MMO20 et MMO21 sont utilisés pour afficher un enregistrement équivalent de données qui nécessite deux écrans, les squelettes MM030 et MMO31 pour un enregistrement équivalent de données qui nécessite trois écrans, et les squelettes MMO50 et MM051 pour un enregistrement équivalent de données qui nécessite quatre écrans. Maintenant, on donne une autre explication en prenant le "fichier maître des clients" de la figure 18 comme exemple dudit fichier maître. Ce fichier maître des clients comporte les champs code client 16a, nom des sociétés 16c, type de société 16c, adresse 16d, numéro de téléphone 16e, et numéro de FAX 16f, avec le code client désigné comme clé pour la recherche des données. [Confiauration de réalisationtion 151 Squelette MMO10 On décrira maintenant, en liaison avec l'organigramme de la figure 19, les contenus d'action du "programme de maintenance maître de client" constitué par le squelette MMOlO. Incidemment, ce programme est conçu pour enregistrer un article équivalent de données dans le fichier maître client 17 représenté en figure 18. Lorsque le "programme de maintenance maître de client" est sélectionné dans le menu (ST51), un affichage d'écran pour l'entrée des clés apparaît dans la station de travail (ST52). Par conséquent l'opérateur entre le code ID des clients (ST52). Le mode action du programme est supposé être le "mode d'enregistrement". Alors, un écran pour l'entrée du "nom de la société", du "type de société", 28 2729773 de l'"adresse", du "numéro de téléphone" et du "numéro de FAX" apparaît à la station de travail. Par conséquent, l'opérateur entre l'information nécessaire (ST53) et appuie alors sur la touche "Entrée". Là- dessus, un message de confirmation est affiché (ST54) et lorsqu'on presse de nouveau la touche "Entrée", la donnée juste entrée est ajoutée au fichier maître des clients (ST55). Le "mode d'enregistrement" a été décrit ci- dessus. Si la touche de fonction F5 est pressée au stade de l'étape ST52, le mode action du programme peut être changé par traitement de la fenêtre. Si la clé est entrée (ST52) après que le mode action du programme ait été changé en "mode révision", l'enregistrement équivalent des données est affiché sur l'écran et, par conséquent, la position correspondante peut être revue (ST53). De plus, si la touche wEntréew" est pressée alors qu'un message de confirmation est affiché (ST54), les contenus du fichier maître clients sont révisés (ST55). Dans le "mode suppression", l'enregistrement désigné qui est l'équivalent des données est totalement supprimé lors de l'entrée par touche. Dans le "mode affichage", l'enregistrement désigné qui est l'équivalent des données est simplement affiché dans la station de travail et les traitements aux étapes ST54 et ST55 sont sautés. [Confiauration de réalisation 161 Sauelette MMOll La configuration 16 est caractérisée en ce qu'une fonction de reproduction peut être utilisée au stade du traitement à l'étape ST52 de la figure 19 et par ailleurs est identique à la configuration 15. L'expression "fonction de reproduction" est une fonction dans laquelle un enregistrement équivalent des données déjà enregistrées peut être reproduit dans un nouvel enregistrement. Plus spécifiquement, dans la configuration 16, un écran pour l'entrée de 29 2729773 l'"enregistrement original à reproduire apparaît dans le stade de traitement de l'étape ST52 (figure 20). Lorsque le code client, par exemple "0001", est entré dans la colonne d'entrée de l'"enregistrement original à reproduire", un enregistrement équivalent des données "ABC Industrial Co." est affiché sur l'écran à la station de travail. Par consequent, cette configuration est commode lorsque la donnée à ajouter ressemble à la donnée "ABC Industrial Co.", pour seulement la portion différant des données "ABC Industrial Co." devant être entrée. [Configurations de réalisation 17. 181 Sauelettes MMO20. MMO21 La configuration 17 convient pour être employée lorsque l'entrée d'un enregistrement équivalent des données nécessite deux écrans et est caractérisée en ce que les traitements aux étapes ST53 et ST54 de la figure 19 sont répétés deux fois. La configuration 18 est caractérisée en ce qu'une fonction de reproduction peut être utilisée et par ailleurs est identique à la configuration 17. [ Configurations de réalisation 19, 201 Sauelettes MMO30. MM031 La configuration 19 convient pour les situations dans lesquelles l'entrée d'un enregistrement équivalent des données nécessite trois écrans à la station de travail, et est caractérisée en ce que les traitements aux étapes ST53 et ST54 de la figure 19 sont répétés pour un total de 3 fois. La configuration 20 a pour caractéristique une fonction de reproduction et est par ailleurs identique à la configuration 19. 2729773 rConfigcurations de réalisation 21. 221 Sauelettes MMO50, MMO51 La configuration 21 convient pour les situations dans lesquelles l'entrée d'un enregistrement équivalent de données nécessite cinq écrans à la station de travail, et est caractérisée en ce que les traitements aux étapes ST53 et ST54 de la figure 19 sont répétés pour un total de 5 fois. La configuration 22 a comme caractéristique une fonction de reproduction et * est par ailleurs identique à la configuration 21. 4. Traitement du système d'interrogation de fenêtre (configurations 23-26). L'expression "traitement du système d'interrogation de fenêtre" signifie un traitement de recherche utilisant la fenêtre W (figure 7) et pour mettre en oeuvre les solutions des configurations 23-26, des squelettes WNOlO, WNOll, WN012 et WNO20 sont fournis. Les traitements des configurations 22-26 sont invariablement des traitements de recherche de données qui fonctionnent lorsque la touche de fonction F4 est pressée dans l'exécution d'un programme d'appel, et alors que les squelettes WN010, WNOll et WN012 sont adaptés à des situations dans lesquelles les données enregistrées dans le fichier maître sont recherchées, le squelette WN020 est adaptée aux situations dans lesquelles la donnée enregistrée dans le fichier des transactions est recherchée. [Configcuration de réalisation 231 Scuelette WNO10 Le programme de configuration 23 est, par exemple, tel que, lorsque la touche de fonction F4 est pressée au cours de l'étape ST52 du "programme de maintenance maître clients" (figure 19), le "fichier maître clients" est recherché pour récupérer le code ID 31 2729773 du "client". Dans le "programme de maintenance maître clients", le code ID du client doit être entré à l'étape ST52. Que la touche de fonction F4soit pressée avec la colonne entrée du code ID laissée vierge ou que la touche de fonction F4 soit pressée avec la colonne entrée d'ID remplie avec le code (ST52 et ST60), le squelette WNOlO commence à fonctionner (figure 21). Dans le squelette WN010, on fait d'abord une interrogation sur l'existence d'un paramètre (ST61), et si celui-ci n'existe pas, la séquence de traitement passe à l'étape ST62 et s'il existe, la séquence avance jusqu'à l'étape ST63. Le terme "paramètre" est utilisé dans le contexte précédent pour vouloir dire un code de départ de recherche établi en pressant sur la touche de fonction F4 dans le fonctionnement d'un programme d'appel et, dans le présent exemple, le code ID du client entré dans l'étage de traitement de l'étape ST52 du "programme de maintenance maître clients" correspond au code de commencement de la recherche. Dans le "programme de maintenance maître clients", en supposant que la touche de fonction F4 soit pressée sans entrer le code ID du client, la décision à l'étape ST61 est exécutée et, alors, un affichage de fenêtre pour l'entrée de la condition de commencement de la recherche apparaît (ST62). Comme le code ID client est maintenant recherché dans le présent exemple, l'affichage représenté en figure 22, par exemple, correspond à l'affichage de la fenêtre pour l'entrée de la condition de commencement de la recherche. Comme représenté en figure 22, dans le programme de la configuration 23, une colonne 17a pour l'entrée du code ID du client et une colonne 17b pour l'entrée du nom du client en caractère kana) sont affichées. Il suffit d'entrer soit le code ID soit le caractère kana dans la colonne correspondante. En supposant, par exemple, que le code ID "0010" est entré dans la colonne 17a, le code ID et le nom du client correspondant sont affichés côte à côte pour tous les 32 2729773 codes y compris, et à la suite le code ID "0010" (ST63). D'autre part, le caractère kana GKAY est entré dans la colonne 17b, tous les noms des clients avec leurs initiales à la suite de "KA" sont affichés en même temps que leurs codes ID (ST63). Dans le "programme de maintenance maître clients", o le code ID du client a déjà été entré, le traitement à l'étape ST62 est sauté et les codes ID suivant le code ID entré sont affichés en correspondance avec les noms des clients (ST63). Comme, dans chaque cas, une multitude de noms de clients et de codes ID correspondants apparaissent dans l'affichage W de la fenêtre, l'opérateur peut déplacer le curseur jusqu'à la position correspondante et appuyer sur la touche 'Entréee (ST63). En supposant que le code ID du client correspondant est "0005", la séquence revient au "programme de maintenance maître clients" avec le code ID sauvegardé (ST64), ce qui se traduit par le fait que "0005" a déjà été entré dans la colonne d'entrée du code ID des clients lorsque l'écran du programme d'appel est affiché. Si la touche de fonction F3 ou la touche de fonction F12 sont pressées dans l'étage de traitement de l'étape ST62 ou de l'étape ST63, le programme d'appel reprend spontanément. Ainsi, lorsque le programme d'appel est affiché, sa colonne d'entrée du code d'entrée du code ID du client reste vierge. rConficnuration de réalisation 241 Souelette WNOll La configuration 24 (squelette WNOll) est souvent identique à la configuration 23 (squelette WNO10), la seule différence étant que la condition de commencement de la recherche ne peut être désignée en utilisant un caractère kana dans l'étage de traitement de l'étape ST 62. Par conséquent, la configuration 24 est utile pour les situations dans lesquelles le fichier 33 2729773 maître n'employant pas des caractères kana est recherché. rConfiacuration de réalisation 251 Squelette WN012 La configuration 25 (squelette WNO12) comme les configurations 23 et 24, est un traitement pour rechercher les données du fichier maître dans la fenêtre de l'écran. Les contenus de l'action sont similaires à ceux de la configuration 24 (squelette WNOl1), mais cette configuration est caractérisée en ce qu'une valeur fixe de la recherche peut être désignée, dans l'étage de traitement de l'étape ST62, indépendamment du code de commencement de la recherche. La valeur fixe de la recherche est une valeur fixant l'une des conditions de la recherche. Prenons comme exemple la recherche d'un nfichier maître d'employés" contenant des données individuelles sur les employés, la configuration 25 est efficace quand seulement le personnel employé dans un département donné, par exemple un Département Affaires, est recherché. Ce qui précède peut être expliqué spécifiquement comme suit. Dans le cas de la configuration 25 (squelette WN012), lorsque le code ID du Département Affaires qui est une valeur fixe recherchée et le code des employés "0020" qui est un code de commencement de la recherche sont entrés (ST62), toutes les données des employés appartenant au Département Affaires et affectées à des codes employés suivant "0020" sont affichées à la station de travail (ST63). [Confiauration de réalisation 261 Sacruelette WN020 La configuration 26 (squelette WNO20) convient à la recherche d'un fichier de transactions, c'est-à-dire des données enregistrées par les programmes des configurations 1-7. 34 2729773 Son action, représentée dans l'organigramme de la figure 21, est caractérisée en ce qu'une multitude de conditions de recherche peuvent être entrées à l'étape ST62. Par exemple, lorsque le code ID et du nom du fournisseur nABC Industrial Co.' et que la date du justificatif "3/10" sont entrés dans la recherche du fichier des spécifications 14 de la figure 8 (ST62), toutes les données satisfaisant les conditions sont affichées dans la fenêtre (ST63). 5. Traitement du système d'impression des justificatifs (configurations de réalisation 27-34) Les configurations 27-34 sont les traitements pour l'impression des justificatifs. Ces configurations sont constituées de combinaisons suivantes de squelettes LTO20, LTO21, LTO30 et LTO40. Configuration 27 = LYO20 Configuration 28 = LT021 Configuration 29 = LTOlO + LT020 Configuration 30 = LT010 + LTO21 Configuration 31 = LTOlO + LT030 + LT020 Configuration 32 = LTOlO + LTO30 + LTO21 Configuration 33 = LT040 + LT020 Configuration 34 = LTO40 + LTO21 [Confiauration de réalisation 271 Sauelette LTO20 L'esquisse du traitement de la configuration 27 (squelette LT020) est représentée dans l'organigramme de la figure 23. Cette configuration convient pour sortir une copie sur papier des contenus d'un fichier ne présentant aucune démarcation des données, tels qu'un fichier maître. Tout d'abord, un enregistrement est lu dans le fichier correspondant (ST71) et dans le cas d'une fin de fichier, le traitement se termine (ST72) et sinon (s'il ne s'agit pas d'une fin de fichier), une procédure 2729773 d'édition pour impression est effectuée (ST73). La procédure d'édition pour impression est un traitement pour établir une position d'impression appropriée, etc. pour un enregistrement équivalent aux données lues. Ensuite, il y a interrogation quant à savoir si une page équivalente de l'impression a été achevée ou non (ST75) et si la réponse est affirmative, une ligne d'en-tête pour la page suivante est imprimée (ST75). Dans le cas o une ligne d'en-tête pour une autre page est inutile car seule une page suffit, une page équivalente des données éditées est imprimée telle quelle (ST76), 1' enregistrement suivant, équivalent des données, est alors lu (ST77) et la séquence revient au traitement de l'étape ST72. [Conficuration de réalisation 281 Sauelette LT021 L'esquisse du traitement de la configuration 28 (squelette LTO21) est représentée dans l'organigramme de la figure 24. Cette configuration est caractérisée en ce qu'un traitement (ST76') pour l'impression d'une en- tête de spécification HD est interposée entre le traitement de l'étape ST75 et le traitement de l'étape ST76. L'expression "en-tête de spécification HD" signifie par exemple les contenus du numéro de justificatif 14 A1, la date du justificatif 14A2, le nom du fournisseur 14A3 et la personne en charge 14A4 dans le fichier des spécifications 14 de la figure 8, et chaque fois que les contenus d'un justificatif ont été imprimés, les contenus de la partie en-tête 14A sont imprimés (ST76'). L'organigramme de la figure 24 est maintenant décrit en liaison avec la copie sur papier représentée en figure 25. Tout d'abord, un enregistrement est lu dans le fichier correspondant (ST71), et s'il s'agit d'une fin de fichier (FDF), le traitement se termine (ST72), et sinon (pas de fin de fichier), une procédure d'édition pour impression est 36 2729773 exécutée (ST73). Ensuite, il y a interrogation du fait qu'une page équivalente de l'impression a été achevée (ST74) et si la réponse est affirmative, et que le changement de page a été fait, la ligne de l'entêtes pour une autre page est imprimée (ST75). Lorsque la procédure pour le changement de page est inutile, une question est posée quant au fait qu'un justificatif équivalent des données a été imprimé et si la réponse est affirmative, les contenus de la partie en-tête 14A ainsi que l'en-tête sont imprimés (ST76'). De plus, un enregistrement équivalent des données éditées est imprimé (ST76). Alors, l'enregistrement suivant équivalent des données est lu (ST77) et la séquence revient au traitement de l'étape ST72. [Confiaurations de réalisation 29. 301 Sauelettes LTOlO + LTO20, LT0211 Les configurations 29 et 30 sont constituées de façon que les traitements des squelettes LTO20 et LT021 soient respectivement précédés par le traitement du squelette LTOlO. Comme représenté en figure 26, le squelette LTO10 met en oeuvre un traitement pour désigner la gamme du justificatif à imprimer. Tout d'abord, un écran pour l'entrée de la condition d'impression apparaît à la station de travail (ST81). Alors, la configuration 29 est décrite en prenant l'impression des contenus du "fichier maître clients" de la figure 18 par exemple. L'opérateur entre, par exemple, le code ID "0001-0010" comme condition d'impression (ST81), à la suite de quoi un message pour confirmation est affiché (ST82). Alors un message "en impression" apparaît (ST83) et le traitement de, par exemple, un "programme d'impression de justificatif" constitué du squelette LTO20 commence à fonctionner (ST84). 37 2729773 Alors que la configuration 29 vient juste d'être décrite, la configuration 30 est différente de la configuration 29 seulement en ce que le programme d'impression de justificatif appelé à l'étape 84 est constitué du squelette LT021. [Confiauration de réalisation 31. 321 LT010 + LTO30 + LT020,. LT021 Les configurations 31 et 32 sont telles que le traitement du squelette LT030 est inclus au cours du traitement des configurations 29 et 30. Le traitement du squelette LT030, comme représenté en figure 27, est caractérisé en ce que le fichier principal est entièrement lu une fois et que le fichier des travaux est mis à jour. Le fichier des travaux mentionné ci- dessus est généralement un fichier pour l'opération d'addition. Si l'on prend l'impression des contenus du fichier 14 des spécifications de la figure 8 comme exemple, un enregistrement équivalent des données est lu dans le fichier 14 des spécifications (ST91), et s'il ne s'agit pas d'une fin de fichier (FDF), les données lues sont éditées pour impression (ST93). Alors, l'opération d'addition est exécutée pour les produits prix d'achat unitaire" multiplié par "quantité achetée" (ST94). Ensuite, l'enregistrement suivant équivalent des données est lu (ST95) et la séquence revient au traitement de l'étape ST92. Après le traitement du squelette LTO30, une impression réelle est mise en oeuvre par le traitement soit du squelette LTO20 soit du squelette LTO21. [Conficruration de réalisation 33. 341 LTO40 + LT020, LTO21 Les configurations 33 et 34 sont telles que le traitement du squelette LTO40 est exécuté avant celui 38 2729773 des configurations 27 et 28. Comme représenté en figure 28, le traitement du squelette LT040, comme celui du squelette LTOlO, désigne la condition pour les données à imprimer. La différence entre les squelettes LTO10 et LT040 est que, dans le cas du squelette LT040, une liste des données satisfaisant la condition est affichée. Maintenant, on explique l'organigramme de la figure 28 en prenant l'impression des contenus des fichiers des transactions 12, 13 représentés en figure 5 comme exemple. Tout d'abord, un affichage pour l'entrée de la condition d'impression apparaît à la station de travail. On suppose maintenant que l'opérateur désigne la condition "1/10/1994 -- 5/10" (STlO1). Alors, toutes les données satisfaisant la condition ci-dessus sont affichées comme représenté en figure 14 (ST102). En même temps, la colonne d'entrée du code action apparaît aussi sur l'écran à la station de travail, et par conséquent, l'opérateur entre un code action approprié (ST103). Là-dessus, un message pour confirmation est affiché (ST104). Alors, un message indiquant "en impression" apparaît (ST105) et le programme des fiches affaires est appelé (ST106). Le programme des fiches affaires a été préparé soit avec le squelette LTO20 soit avec le squelette LT021, et la sélection de la configuration 33 ou de la configuration 34 dépend sur celui des squelettes LTO20 et LTO21 qui est utilisé. 6. Traitement du système de mise à jour discontinu (configurations 35, 36). [Conficuration de réalisation 351 Squelette BUO20 La configuration 35 (squelette BU020) est un traitement pour les situations dans lesquelles un fichier est mis à jour sans dialogue à la station de travail. Généralement, le cas dans lequel les données du 39 2729773 fichier des transactions sont lues, un enregistrement équivalent l'un après l'autre pour la mise à jour des contenus d'un fichier maître correspond à ce traitement. En outre, la procédure de construction d'un fichier temporaire (fichier de travail) correspondant à une image d'impression de justificatif (par exemple, figure ) avant l'impression des données accumulées dans le fichier des transactions correspond aussi à ce traitement. Le traitement ci-dessus est maintenant expliqué en liaison avec l'organigramme de la figure 29. Tout d'abord, l'enregistrement initial du fichier des transactions est lu (STlll) et, s'il ne s'agit pas d'une fin de fichier, l'édition de la spécification est exécutée (ST113). L'édition de la spécification signifie un traitement pour éditer un enregistrement équivalent de la lecture des données de spécification dans le format du fichier maître, du fichier temporaire ou analogue qui doit être mis à jour. Alors, sur la base d'un enregistrement équivalent des données éditées, le fichier maître, le fichier temporaire etc. sont mis à jour (ST114). Alors, l'enregistrement suivant, équivalent des données est lu dans le fichier des transactions (ST15) et la séquence revient au traitement de l'étape ST112. rConfiauration de réalisation 361 Squelettes BU010 + BU020 La configuration 36 est un traitement dans lequel la condition de mise à jour est entrée avant le traitement de la configuration 35. Comme représenté en figure 30, un affichage pour l'entrée de la condition de mise à jour apparaît d'abord sur l'écran (ST121). Ici, la mise à jour d'un fichier maître pour préparer une note de débit sur la base des données entre le 21 septembre et 20 octobre parmi les données enregistrées dans le fichier de 2729773 transactions de la figure 11 est prise comme exemple. Par exemple, l'opérateur entre la condition de mise à jour "21/9 -- 20/10" à la station de travail (ST121). Alors, un message pour confirmation apparaît (ST122). Alors que l'opérateur appuie sur la touche "Entrée", un message indiquant "mise à jour" apparaît (ST123) et le programme de mise à jour constitué par le squelette BU020 est appelé (ST124). Ensuite, selon la procédure de la configuration 35, seul l'enregistrement correspondant du fichier des transactions de la figure 11 est lu et les contenus du fichier maître sont mis à jour. Les configurations 1-36 ont été décrites en détail. Maintenant, la procédure pour la génération automatique d'un programme par dialogue fera l'objet d'une description. A titre d'exemple, les contenus du traitement jusqu'à l'achèvement d'un "programme de maintenance maître pour employés" seront décrits. Le "programme de maintenance maître pour employés" est un programme d'application qui est mis en oeuvre par le système informatique de la figure 1. Il s'agit d'un programme grâce auquel le "fichier maître des employés" stocké dans la mémoire à disque 3 est accédé à partir des stations de travail WSl-WSn pour enregistrer, réviser ou supprimer des données sur les employés individuels. La génération automatique du programme selon la présente invention est divisée entre les étapes de traitement de (la) la réalisation physique du fichier (lb), la réalisation du fichier d'image d'écran, (lc), la réalisation du fichier des fiches affaires, (2) l'enregistrement de l'information unitaire, et (3) la réalisation détaillée du programme. Cependant, dans le cas d'un programme de maintenance maître pour employés" o aucun processus d'impression de justificatif n'est impliqué, la génération automatique du "programme de maintenance maître des employés" est achevée seulement par la réalisation physique du fichier (figure 31), la 41 2729773 réalisation du fichier des images d'écran (figure 34), l'enregistrement de l'information unitaire (figure 38) et la réalisation détaillée du programme (figure 39). (la) Réalisation phvsiaue du fichier (fiaure 31) Lorsque l'ordinateur placé sur le mode action de la réalisation physique du fichier, la réalisation d'un fichier physique est exécutée par dialogue. Comme la tâche est dans cet exemple de concevoir un "fichier maître des employés", il est séquentiellement décidé des champs qui doivent être fournis pour un enregistrement, comment plusieurs multiplets doivent être utilisés pour la zone allouée à chaque champ et le champ qui doit être sélectionné pour les données à utiliser comme clé de recherche des données, etc. (ST131). A l'achèvement de l'entrée de toutes les informations, un document de réalisation de base de données est imprimé en réponse à une manipulation pertinente (ST132). La figure 32 représente un document de réalisation de base de données. Comme le "nom du champ" 20a, l'nID du champ" 20c, "le type de champ" 20b, "le nombre de chiffres du champ" 20d, le "type de données" 20e, etc. sont affichés conformément à un format prédéterminé, on peut s'assurer des contenus de la réalisation d'un coup d'oeil. En outre, tant que ce document de réalisation de la base de données est stocké, n'importe qui peut connaître facilement les contenus du "fichier maître des employés". A l'achèvement de la réalisation du fichier physique par dialogue, les codes-source du fichier physique sont automatiquement introduits (ST133). De plus, en réponse à une manipulation appropriée, une liste-source du fichier physique est imprimée (ST134). La figure 33 représente la liste-source. Ainsi, une copie sur papier d'une liste des sources en 42 2729773 correspondance parfaite avec le document de réalisation de la figure 32 est obtenue. Alors, les codes-source sont compilés et une zone pour le "fichier maître des employés" est assurée dans la mémoire 3 à disque (ST135). Dans cet exemple, ID du "fichier maître des employés" est uRCMEMPP", et les champs ID "EMPCDE"--"EMPUDT" sont définis. (lb) Réalisation du fichier image de l'écran (figure 34) Alors que l'ordinateur est placé dans le mode action de réalisation du fichier image de l'écran, la réalisation d'un fichier image d'écran est exécutée par dialogue (ST141). Dans cette réalisation, le squelette à utiliser doit être déterminé en premier. Dans cet exemple, le "programme de maintenance maître des employés" est préparé en utilisant le squelette MMOll (configuration 16). Comme représenté en figure 19, le squelette MMOll (configuration 16) nécessite un écran pour l'entrée des clés (ST52), un écran pour l'entrée des données de la spécification (ST53) et un écran affichant un message pour confirmation avec un affichage concurrent des données de la spécification (ST54). Par conséquent, ceux-ci sont déterminés pas par pas. Après l'achèvement de toutes les réalisations des images de l'écran, par le traitement de l'étape ST141, une manipulation appropriée est faite, à la suite de quoi, un document de réalisation de fichier d'images d'écran est imprimé (ST142). Ce document indique des informations détaillées sur tous les affichages d'écran (ST62, ST53, ST54), les contenus de la réalisation des images d'écran peuvent être constatés avec précision à partir de ce document. Les figures 35 et 36 représentent des "dispositions d'image comme parties du document. Il est clair qu'à l'étape ST52 de la figure 19, l'écran à la station de travail est tel que représenté en figure 35 (FMTO1 + FMT91), et qu'aux 43 2729773 étapes 53 et 54 de la figure 19, l'écran à la station de travail est tel qu'illustré en figure 36 (FMTO2 + FMTO1 + FMT91). A l'issue de la réalisation du fichier images d'écran, les codes-source pour le fichier d'images-écran sont automatiquement engendrés (ST143). De plus, en réponse à une manipulation appropriée, une liste-source de fichier physique est imprimée (ST144). La figure 37 représente une partie de la liste-source du fichier des images d'écran. Plus particulièrement, les 17ème à 52ème lignes indiquent une liste-source concernant l'image d'écran (FMTO1) pour l'entrée des données clés à l'étape ST52 (figure 19). Ensuite, les codes-source sont compilés et les codes résultants du fichier des images d'écran sont engendrés (ST145). Le nom de ce fichier des images d'écran est maintenance maître des employés" et l'ID du fichier est "RCOODOOl". (2) Enreaistrement de l'information unitaire (figure 38) Maintenant, l'ordinateur doit être placé dans le mode d'enregistrement des informations unitaires par une manipulation appropriée. Dans le mode enregistrement des information unitaire, une esquisse du "programme de maintenance du fichier maître des employés" est obtenue par dialogue. Comme représenté en figure 38, le nom du programme à préparer et le squelette à utiliser doivent être spécifiés en premier lieu (STl51). Ici, un programme appelé "maintenance maître des employés" est engendré en utilisant le squelette MMOll comme on l'a mentionné ci- dessus. Par conséquent, ces informations peuvent être simplement entrées à partir de la station de travail ST151). Alors, si le programme d'application à engendrer est appelé à partir d'un programme différent, le paramètre à recevoir en provenance de l'autre 44 2729773 programme est déterminé (STl52). Dans cet exemple, il n'y a aucun paramètre à recevoir en provenance d'un autre programme. Alors, les fichiers à utiliser par le "programme de maintenance maître des employés" sont déterminés (ST153). Dans cet exemple, le "programme maître des employés (RCMEMPP)" est utilisé comme fichier physique et le programme de maintenance maître des employés (RCOODOOl)" est désigné comme fichier des images d'écran. Enfin, un programme externe à appeler pendant le fonctionnement du programme "maintenance maître des employés" est déterminé (ST154). Dans cet exemple, le traitement pour la recherche du code avec la touche de fonction F4 (figure 19) est utilisé, et par conséquent, un programme externe pour recherche de code est désigné. On suppose que le programme pour la recherche du code a déjà été préparé en utilisant l'un quelconque des squelettes WNOlO, WNOll et WN012. (4) Réalisation détaillée d'un Droqramme (figure 39) L'achèvement de l'enregistrement des informations unitaires est suivi par le traitement pour la conception détaillée des programmes représentée dans la figure 39. Ici, l'information détaillée variant avec les traitements individuels est entrée par dialogue (STl61). Ainsi, comme le squelette MMOll est divisé en la portion A du corps et la portion individuelle B (figure 2) de façon qu'une variété de traitements puisse être faite conformément à la procédure de la figure 19, la partie intrinsèque du programme de maintenance maître des employés" est établie en détail au stade de l'étape ST161. A l'issue du traitement ci-dessus, le document de réalisation du programme est imprimé en réponse à une manipulation pertinente (ST162). Dans le générateur automatique de programme qui est représenté 2729773 en figure 1, un document de réalisation de programme pour chacune des configurations 1-36 est stocké à l'état semi-fini dans la mémoire 3. Par conséquent, à l'achèvement de la réalisation détaillée ci-dessus du programme (ST161), un document de réalisation de programme en correspondance parfaite avec le programme particulier peut être rendu disponible comme copie sur papier. En outre, lorsque la réalisation détaillée du programme (ST161) a été achevée, les codes-source du "programme de maintenance maître des employés" sont automatiquement produits (ST163) en combinant les informations entrées jusqu'ici avec le programme source du squelette MMOll qui a été préalablement enregistré. De plus, les codes-source sont compilés et un programme résultant est produit (ST165). En outre, en réponse à une manipulation pertinente, une liste-source de programmes est imprimée (ST164). La figure 40 représente une partie du programme-source du squelette MMOll et la figure 41 les codes-source, en partie, du "programme de maintenance maître des employés" imprimé. Alors que les codes-source du "programme de maintenance maître des employés" ont des colonnes remplies avec les repères "//" ou "/", la ligne avec le repère "//" est une ligne représentant une copie directe du programme- source du squelette MMOll et la ligne avec le repère n /" ou laissé vierge est une ligne représentant la génération automatique sur la base de l'entrée des informations par dialogue. La ligne désignée "PLIST COMMON" en figure 40 est un élément rapporté des lignes 136-143 de la figure 41, et les lignes désignées "KLIST COMMON" et "MAKING NG" sont des éléments rapportés provenant des lignes 150-155 de la figure 41. En outre, la ligne désignée "COPYRIGHT" de la figure 40 correspond à la ligne 159 de la figure 41. Dans le générateur automatique de programmes de la figure 1, tous les programmes d'application sont générés en combinant des squelettes qui sont des 46 2729773 programmes-source à l'état semi-fini. Ces squelettes sont des programmes de haute qualité préparés par des programmeurs experts dans le langage de programmation particulier, et la réalisation du programme s'effectue par dialogue. Par conséquent, même un novice peut mettre en oeuvre une génération automatique des programmes d'application de totalité constante d'une façon facile et rapide. En outre, comme un document complet de réalisation est en correspondance parfaite avec le programme d'application fini devient disponible sous la forme d'une copie sur papier, n'importe qui peut saisir avec précision les contenus du traitement du programme. Par conséquent, même lorsqu'un changement se produit dans le fonctionnement ou le service de l'organisation, n'importe quelle personne peut réviser aisément le programme d'application ou lui apporter des additions. La présente invention n'est pas limitée aux exemples de réalisation qui viennent d'être décrits, elle est au contraire susceptible de modifications et de variante qui apparaîtront à l'homme de l'art. 47 2729773 REVENDICATIONS 1 - Générateur automatique de programmes, caractérisé en ce qu'il comprend: - un moyen de mémoire stockant des squelettes qui sont des programmes-source à l'état semi- fini, - un moyen de mémoire stockant des documents de réalisation à l'état semi-fini qui décrivent les contenus du traitement des squelettes, - un moyen d'entrée d'information individuelle qui fonctionne dans la réalisation des programmes d'application pour recevoir l'information individuelle qui varie avec les différents programmes d'application par dialogue, - un moyen de finition de programme qui édite les squelettes sur la base de l'information individuelle reçue et génère des codes-source pour les programmes respectifs d'application, - un moyen de finition de document de réalisation qui édite les documents de réalisation à l'état semi-fini sur la base de l'information individuelle reçue et finit les documents de réalisation correspondant aux programmes respectifs d'application, et - un moyen de sortie qui fonctionne en réponse une manipulation pertinente pour imprimer une liste de codes-source et/ou un document de réalisation de chaque programme d'application fini. 2 - Générateur automatique de programmes selon la revendication 1, caractérisé en ce que le moyen de mémoire de squelette stocke, à l'état semi-fini, au moins les programmes d'un premier groupe qui enregistrent les données dans un fichier de transactions, les programmes d'un second groupe pour rechercher la donnée d'un fichier de données et l'afficher sur un écran de terminal, les progranmmes d'un troisième groupe pour enregistrer des données dans un 48 2729773 fichier maître, les programmes d'un quatrième groupe pour rechercher la donnée d'un fichier de données et l'afficher dans la fenêtre d'un écran de terminal, les programmes d'un cinquième groupe pour imprimer les contenus d'un fichier de données sur une formule commerciale, et les programmes d'un sixième groupe pour mettre à jour les contenus d'un fichier maître ou d'un fichier temporaire en utilisant les données d'un fichier de transactions. 3 - Générateur automatique de programmes selon la revendication 1, caractérisé en ce que le moyen de mémoire pour document de réalisation stocke au moins un document de réalisation physique de fichier, un document de réalisation de fichier d'images d'écran, un document de réalisation de fichier de formules commerciales et un document de réalisation de programme, chacun à l'état semi-fini. 4 - Générateur automatique de programmes selon la revendication 2, caractérisé en ce que les programmes du premier groupe sont classés en programmes qui traitent des données du type justificatif comportant un numéro de justificatif et un numéro de ligne et en programmes qui traitent des données du type édition comportant ni numéro de justificatif ni numéro de ligne. 5 - Générateur automatique de programmes selon la revendication 2, caractérisé en ce que les programmes du second groupe sont classés en programmes ayant la fonction de recommander à l'opérateur d'entrer la condition de données interrogées et d'afficher une liste de toutes les données satisfaisant cette condition et en programmes n'ayant pas la fonction d'afficher ladite liste. 6 - Générateur automatique de programmes selon la revendication 2, caractérisé en ce que les programmes du troisième groupe sont classés en une multitude de programmes basés sur la relation quantitative d'un enregistrement équivalent à des 49 2729773 données et de la quantité des données qui peuvent être affichées sur un seul écran de terminal. 7 - Générateur automatique de programmes selon la revendication 2, caractérisé en ce que les programmes du quatrième groupe sont classés en programmes pour rechercher un fichier maître et en programmes pour rechercher un fichier de transactions. 8 - Générateur automatique de programmes selon la revendication 2, caractérisé en ce que les programmes du sixième groupe sont classés en programmes ayant la fonction de recommander à l'opérateur d'entrer la condition de données à imprimer et d'afficher une liste de toutes les données satisfaisant cette condition et en programmes n'ayant pas la fonction d'afficher ladite liste. 9 - Générateur automatique de programmes selon la revendication 1, dans lequel le langage de programmation des programmes d'application est l'un quelconque du langage GPE, du langage C et du langage COBOL.