CN1133456A - 自动程序生成器 - Google Patents

Abstract

本发明的自动程序生成器包括一个框架存储装置，其中存储处于半成品状态的源程序，一个设计文件存储器装置，存储处于半成品状态的设计文件，一个各种信息输入装置，通过对话来接收随每个应用程序改变的各个信息，一个程序最后加工装置，它根据接收的各个信息为每个应用程序生成源码，一个设计文件最后加工装置，它根据接收的各个信息完成一设计文件，还包括一个输出装置，用来打印源码清单和/或半成品应用程序的设计文件。

Description

自动程序生成器

本发明涉及一个自动程序生成系统，该系统完全对应所生成的程序，以一恒定的质量水平及标准化来设计文件，生成全部应用程序。

计算机的有效利用需要适合用户使用的合适的应用程序，但这种应用程序主要根据程序设计者的个性来写成。

当这种应用程序已被完成，通常用户得到的是程序的目标代码和操作手册，并根据操作手册操作应用程序。如果什么时间发现应用程序工作不正常，就形成为维护的访问，以便程序保持正常工作。

为程序的完善性，常常向用户提供源码清单和显示设计内容的文件，但这种文件必须手工完成，并且要化费很多时间使其完善，用户不需要被提供完整的文件。

同时，即使是一个正常工作的应用程序，用户通常希望在他的服务中随时间的进展和变化修改它的处理内容，而常规的硬件存在缺点是应用程序一旦完成后不容易修改。

此外，当程序源码清单缺乏或者由于源码清单与目标代码不符时，即使程序处理内容的很小的修改如程序维护也需要很长的时间。造成一个新的应用程序必须从一开始就重建，它正是以往往常发生的情况。

而且，即使可得到一完整的源码清单，每个程序起源于设计者的能力和技巧的个性，以使第三者不容易掌握处理内容，因此，为修改内容需要化费更多时间，在某些情况下，由于这种修改使整个程序失去正确的功能。

此外，虽从档案中可得到各种文件，常常实际处理内容并及正确反映在文件中，即使其内容已经正确的说明，所有说明使用不同格式，所以对第三者来说，要掌握程序的内容是十分困难的。

由于，随着时间的进展修改应用程序是必要的，提供给用户的程序应该便于今后修改和增加。尤其是应用程序应该有统一质量，不能根据设计者的个性。且提供给用户的任何程序的处理内容必须使任何人能正确了解它们。根据上面原理的开发，本发明对它的目标提供一自动程序生成器，该生成器能自动地产生怛定质量的应用程序。这些程序不取决于设计者的个性，本发明还输出规定设计内容的标准化的设计文件。

为了达到上面的目标，本发明的自动程序生成器包括(1)一个存储框架(skeleton)的框架存储器装置，该框架是半成品源程序，(2)一个存储半成品设计文件的设计文件存储装置，这个设计文件说明各个框架的处理内容，(3)一个独立信息输入装置，在每个应用程序的设计级，该装置通过对话去接收不同应用程序的各种不同的信息，(4)一个程序完善装置，它根据接收的各种信息，编辑上述框架，并为各自应用程序生成源码，(5)一个设计文件完善装置，它根据接收的各自信息，编辑所说的在半成品状态的设计文件，并根据每个应用程序完善设计文件，(6)一个输出装置，这个装置根据相应操作，去输出源码清单和/或成品应用程序的设计文件。

框架存储器装置存储半成品源程序(框架)以使不同类型应用程序可被完成，那些框架典型地分成：第一组程序，在那里寄存器数据在事务文件中；第二组程序，这组程序检索数据文件的数据并在终端屏幕上显示它；第3组程序，在那里寄存数据主文件中；第4组程序，这组程序检索数据文件的数据，并在终端屏幕的窗口中显示它；第5组程序，这组程序用来打印输出事务形式的数据文件的内容；及第6组程序，这组程序根据事务文件的数据来更新主文件和/或临时文件的内容。在本发明，用这第一组到第6组程序适当结合，所有应用程序都能形成。

在本发明中，对应于每个框架的设计文件以半成品状态被记录。并根据通过对话输入的各种信息，半成品状态的设计文件被编辑，以对应每个应用程序提供完全的设计文件，由于框架被主要分成6组，设计文件格式及记录的项目容易标准化，而且，因为设计文件已经标准化，它也就容易使第三者理解每个设计的内容。

图1显示了作为本发明的实施例的自动程序生成器的方框图；

图2显示了框架结构的示意图，

图3为表示设计模式1到设计模式7的差异；

图4显示了一张典型的购物收据形式。

图5显示了一典型的事务文件的形式，图4中说明的购物收据的数据被寄存在文件中。

图6显示了设计模式1和2的处理内容的流程图；

图7显示了为在运行方式中实现改变的一种典型的窗口显示形式；

图8显示了一曲型的事务文件的形式，图4中说明的购物收据的数据被寄存在文件中；

图9显示了设计模式3，4和5处理内容的流程图；

图10显示了编辑型数据的例子的图；

图11显示了一典型事务文件的形式，在文件中寄存编辑型数据；

图12显示了设计模式6和7的处理内容的流程图；

图13显示了框架SK010的处理内容流程图；

图14显示了框架SK010的处理内容流程图；

图15专门显示了框架SK010的处理内容的某些内容；

图16显示了设计模式11的处理内容的流程图；

图17显示了设计模式12，13和14的处理内容的流程图；

图18显示了典型的主文件；

图19显示了设计模式15-29的处理内容的流程图；

图20所示为对一拷贝功能进31的解释；

图21显示了框架WN010的处理内容的流程图；

图22显示了一个窗口显示的形式；

图23显示了框架LT020的处理内容图；

图24显示了骨架LT201的处理内容图；

图25显示了用框架LT021得到事务文件的内容的硬拷贝形式；

图26显示了框架LT010的处理内容图；

图27显示了框架LT030的处理内容图；

图28显示了框架LT040的处理内容图；

图29显示了框架BU020(设计模式35)的处理内容图；

图30显示了框架BU010的处理内容图；

图31显示了对一物理文件设计过程图；

图32显示了一个物理文件(数据基)设计文件的形式；

图33显示了有关物理文件原码清单的形式；

图34显示了对一屏幕文件设计过程的形式；

图35显示了屏幕文件一部分设计文件形式；

图36显示了屏幕文件的另一部分设计文件的形式；

图37显示了有关物理文件原码清单的形式；

图38显示程序的概略设计过程图(单元信息注册)；

图39显示了一程序的详细设计过程图；

图40显示了框架MM011的一部分形式；

图41显示了为了自动地生成应用程序的原码清单的一部分形式；

图1显示了一个作为本发明的实施例的自动程序生成器，这生成器实质上包括一个系统体1和工作站WS1-WSn。而图1的自动程序生成器可以用IBM AS/400系统构成，类似的生成器亦可用其它牌号的计算机构成。

系统体1包括一个中央处理器2，磁盘存贮器装置3及主存贮器装置4，选件打印机5当工作时连到所说的机体1。工作站WS是一个装备有CRT显示器6和键盘7的输入/输出终端，另外，有需要时打印机8可连到终端上。

在图1所示的自动程序生成器中，应用程序的源和目标代码可以在工作站WS上，简单地由用户经物理文件设计，屏幕文件设计，事务格式文件设计和程序设计的设计过程，通过对话操作自动生成。而且，源码清单正确地对应所生成的目标代码，各种设计资料正确地对应所说的目标代码(数据库设计资料，屏幕文件设计资料，程序设计资料)，亦可用硬拷贝输出。顺便说一下，可用的程序设计语言无特殊限制，因此，可以用各种语言，如RPG语言，C语言，COBOL语言等。在下面实施例的说明中，应用程序的生成用RPG(报表程序生成器)语言来解释。

为了实现上述的处理，利用图1说明的自动程序生成器，把所有计算机处理分成36种不同解法，而实现这些解的程序存储在磁盘存储装置3中的34个不同框架程序中，这34个不同框架中的每个是处于半成品状态的源程序，并由独立部分B和机体部分A组成，在每次处理中B被改变，A不变(见图2)，独立部分B在物理文件设计，图象文件设计，卷文件设计或程序设计的设计级中，根据键盘7输入的信息决定。

由于每个框架是由熟练的程序员准备的高质量的程序且应用程序设计是在工作站WS上由对话完成，本发明的自动程序生成器甚至能使初学者容易和很快地完成高质量程序。

而且，由于所有程序通过34种框架的不同组合而成，不同设计资料的格式可以被标准化，此外，不同设计资料可以以半成品状态存储在磁盘存储器装置3中。由于这个原因，一次可完成一个应用程序，正确地对应于程序的各种设计文件能打印输出，且由于这些资料在格式上已经被标准化，任何人都能容易和正确地理解应用程序的处理内容。过去，这些不同设计文件是不提供给用户的，或者如果提供给用户，也不是完美地对立于程序的。然而，利用本发明的程序生成器，所提供的设计资料正确地对应于应用程序，任何人能容易地改变或修改应用程序，以使提供给用户的应用程序的财富价值进一步增加。

因此，在本发明的装置中，所需应用程序可以用36种不同解的任何一种或它们的组合而构成，36种不同解被概略地分成，1.输入系统处理(设计模式1-7)，2.查询系统处理(设计模式8-14)，

3.主维护系统处理(设计模式15-22)，4.窗口查询系统处理(设计模式23-26)，5.收据打印系统处理(设计模式27-34)及6.批作业更新系统处理(设计模式35-36)。

1.输入系统处理(设计模式1-7)

“输入系统处理”项意味有关事务文件的处理，事务文件累加更新主文件数据。根据数据处理的特性，这个输入处理系统分成7种处理(设计模式1-7)，设计模式1-7的这些处理分别由框架ET010，E011，ET050，ET051，ET052，ET150和ET153实现(图3)。

如图3所示，输入处理系统分成设计模式1-5和设计模式6-7，设计模式1-5适合于操作收据型数据求解，而设计模式6-7适合于操作编辑型数据求解。

“收据型数据”项意味由收据号设计数据的组，这样做使得说明部分的数据用行号赋值并寄存到事条文件中，所提及的一种情况是显示在图4购买收据11的数据。购买收据11-1到11-3由表示“购物项”，“单位购物价格”和“购量”的说明部分11b及包含说明部分11b中数据公共信息的标头部分11a组成。在图4情况中，在标头部分11a中信息包括“供货方”，“购物日期”及“负责购物者”。

收据号和行号现在再作进一步详细解释。显示在图4中的3个购买收据用收据号0001-0003标识而每个收据的说明部分11b中的数据用行号赋值并寄存在事务文件中。因此，这些数据，即使当它们在“单位购物价格”中是不同时，还要对相同“购物项”处理，作为例子，如图4中的购物收据11，现在来说明设计模式1到设计模式5。

[设计模式1，2]框架ET010，ET011

通过从工作站WS输入信息，建立框架ET010和ET011的独立部分B(图2)完成设计模式1，2的程序。在事务文件中寄存的收据类型数据，设计模式1到设计模式5的使用是推荐的，而当在标头部分11a中信息量大时特别适合模式1，2。并且如图5A所示，在标头部分11a中的数据被寄存在标头文件12中而说明部分11b中的数据被寄存在说明文件13(图5B)中。

作为一个例子，如图5A的标头文件12，图4的购物收据11具有收据号12a，收据日期12b，供货方名12c，负责购物者12d，购买价格和12e等字段。并且例如“收据号”，“收据日期”和“供货方名”用作检索数据的关键字。

另一方面，说明文件13具有如收据号13a，收据日期13b，供货方名13c，收据行号13d，购物项13e，单位购物价格13f及购物量139等字段。并且例如“收据号”，“收据日期，“供应方名”，及“收据行号”用作检索日期关键字。由于“收据行号”被寄存且作为数据检索的关键字，可以通过行号指定数据的每个记录等值项并逐行为基础实现删除和拷贝。

现在，参考图6的流程图，简要说明设计模式1(框架ET010)的处理，当设计模式1实现收据型数据的寄存，修改和删除处理时，图4的处理购物收据11的数据的“购物收据处理程序”的作用如设计模式1的实施例现在被解释。

当在菜单ST1中选择了“购物收据处理程序”，在工作站WS(ST2)上显示一屏标头文件12的输入关键数据。由于“购物收据处理程序”的起始工作方式是登入方式，对购买收据11的数据的刷新登入的处理现在被解释。

在步ST2中，屏幕上的输入收据号，收据日期，和供应名的列12a，12b，12c的信息被显示。因此，操作者用数字和字符输入相应信息(在本文的后面称为ID码)，根据框架ET010的各个部分的设计，“收据号”是自动选择的，此时，“收据号”的输入是不需要的。

当“收据日期”，“供应方名”等在工作站上输入时，除了标头文件12的关键数据外为输入信息的屏幕被显示(ST3)。因此，在本例中，“负责购物者”是打算输入的，操作员对“负责购物者”输入相应ID码，顺便说一下，如果在步ST3中按下功能键F12，则返回到步ST2，屏幕显示要求输入标头文件12的关键数据。

另一方面，工作站的输入键在ST3步按下，则其序列进到步ST4为输入购物收据11的说明部分的数据，所以操作者对“购买项目”“单位购物价格”及“购物量”输入相应ID码。在购买收据11的说明部分11b的数据的输入完成后立即作“单位购物价”乘“购物量”的操作及加乘积的操作，而各自操作的结果被显示在工作站(ST5)上。同时，催促操作者去确认被显示的(ST5)输入数据信息。

当操作者按下输入键时，显示在屏幕上的数据被寄存在标头文件12和说明文件13的相应区(ST6)，需要时，主文件的内容(如文件存货单)相应地被更新(ST7)。若在说明数据(ST4)的输入处理步中或在确认信息显示处理步中按下功能键F12，则返回到步ST3，若在步ST2-ST5的处理过程中按下功能键F3，重新开始步ST1的菜单显示。

在设计模式1的程序的情况中，如同其它设计模式一样，窗口处理能被实现。“窗口处理”项意味着用在工作站(图7)上CRT屏幕的部分(窗口区W)支持步ST2-ST5的处理的一种处理，窗口处理包括基本处理和选择处理，而选件处理在框架ET010，ET011的各自部分建立时可适当选择或者省略。可选择性地选择的窗口处理通过下文说明的框架WN010，WN011，WN012和WN020已作好准备。

在设计模式1，2中，功能键F5的方式改变处理及用功能键F9的行处理是基本操作，而功能键F4的代码检索处理是在建立框架的各个部分时可任选的处理选择。

“方式改变处理”项表示为改变程序的当前动作方式到数据登入方式，修改方式或删除方式进行处理，并当按下功能键F5，在步ST2的处理阶段，方式改变通过窗口W处理而实现。例如，假定在图7所示状态中输入“2”，“购物收据处理程序”的动作方式变为修改方式，通过步ST2-ST5的处理，在事务文件口和13中寄存的数据被修改(ST6)。在修改方式中，在事务文件12，13中已寄存的购物收据的数据在步ST2和步ST4的处理时期，在工作站上被显示。

假设在图7中的状态说明中输入“3”，“购物收据程序”的动作方式被变为删除方式，在步ST2处理指定的购物收据数据从事务文件12，13(ST6)中被删除。在删除方法，仅寄存的购物收据数据在步ST4的处理阶段被显示，而步ST5的处理不被执行而被跳过。

用功能键F9的术语“行处理”意味着由行号来执行处理，这处理是在说明文件13中相当的每个记录管理下完成的。一般拷贝给定行号上的数据到对应这种处理的具有不同行号的位置上。

用功能键F4的“代码检索处理”表示对必须输入的ID码的检索处理，如上所述，在步ST2-ST5中所需信息用ID码输入。因此，若对“ABC工业公司”，“打印机板”及“sato先生”的ID码是不知道，通过接下功能键F4可以检索相应的ID码。

而由框架ET010(设计模式1)构成的“购物收据处理程序”的操作内容如上所述，实质上，同样适合于框架ET011(设计模式2)而唯一的不同是在步ST5中不执行加操作。因此，框架ET011(设计模型2)，对收据型数据的登入，修改或删除处理是合适的，且不需要像在工作站上那样显示总和。

[设计模式3-5]框架ET050，ET051，ET052

设计模式3-5其特点在于提供无标头文件。它们适合于在说明文件14中寄存标头部分11a的数据和说明部分11b的数据这两者。典型地显示在图4中收据型数据的情况中，所提及情况被说明在图8中，因此，说明文件14由标头部分14A和说明部分14B组成。标头部分14A具有分离字段收据号14A1，收据日期14A2，供货方名14A3及负现购物的人14A4，而说明部分14b具有分离字段行号14B1，购物项14B2，单位购买价格14B3，购物量14B4和总值14B5。

设计模型3(框架ET050)的处理示于图9的流程图中。比较图9和图6清楚的表示在图9的步ST1’-ST6’的处理实际上同图6的步ST1-ST6处理相同，设计模式3与设计模式1的不同，在于设计模式1中无标头文件被提供。

设计模式4(框架ET051)执行接近在图9中所示的设计模式3的那些相同处理，但框架ET051不同于框架ET050，在于框架ET050中不执行在图9的步ST5’处理中的加法操作。

设计模式5(框架ET052)亦执行接近在图9所示的设计模式3的那些相同的处理，但框架ET052不同于框架ET050，在于框架ET050中图9的步ST3’的处理是没有的。因此，设计模式5是在说明文件14的标头部分14A中的所有数据为关键字的情况下的处理。值得注意的是，参考图8所示的说明部分14A，收据号14A1，收据日期14A2及供货方名字14A3被用作数据检索的关键字，而负责购买者14A4字段并不提供。

[设计模式6-7]框架ET150，ET153

设计模式6-7对编辑(登入和修改)或对编辑型数据的删除是合适的。“编辑型数据”术语表示数据不是用收据号或行号赋给，亦就是说，说明数据被用来作为数据检索的关键字，编辑型数据的典型例子是同由服务人员形成的每日维护和检查记录相关的数据被寄存到事务文件中，如图10所说明，当“Nakao先生”，一个服务人员，对“RCC”，“NTT”和其它客户行施如“检查”和“维护”服务时，他的每天活动的记录必须寄存在事务文件中，对每个客户，每一个月为周期的费用被累加并准备好借方收据。在这种情况中，寄存在事务文件中的服务记录的数据不需要收据号或其它类似的东西，亦不需要用行号提供说明数据，因此，设计模式6和7的使用被优先。

图11显示的事务文件15，用来寄存由服务人员形成的服务记录，说明文件15包括标头部分15A和说明部分15B，所用标头文件15A具有服务日期15A1和服务人员15A2字段，而说明部分15B具有客户名15B1，服务内容15B2，以小时为单位的服务时间15B3，单位服务费用15B4和总值15B5字段，而服务日期15A1，服务人员15A2和客户名15B1在此被认为是数据检索的关键字。

“服务记录登入程序”的动作内容由设计模式6构成(框架ET150)，现在参考图12的流程图说明。

当在菜单(ST10)中选择“服务记录登入程序”，标头部分15A的关键输入数据的一屏显示于工作站(ST11)上。由于，在上面例子中“服务日期”和“服务人员”是关键字，操作者输入相应的数字和ID码，假设，9月24日的服务记录，那里，合适的服务人员“Nakao”被输入(ST11)，那么，除了标头部分15A的关键字之外的信息输入屏被显示(ST12)。在本例中，在步ST12中没有信息在步ST12输入，但选择的名字“Nakao”属于可被输入的。若在步ST12中，功能键F12按下，则返回到步ST11对“服务日期”和“服务人员”的输入。

另一方面，若在步ST12中，接下输入键，为输入说明文件15的说明部分15B的数据的一屏被显示。在本例中，由于从9月21日到9月23日的服务记录对服务人员“Nakao”已经登入，这登入信息被显示在工作站上，这样，为了继续地显示信息，操作者输入相应的“客户名字”，“服务内容”，“以小时为单位服务时间”及“单位服务费用”(ST13)。如果需要修改或删除登入的数据，在这时形成数据的校正。

在完成说明部分15B数据的输入后，作“单位服务费用”乘“以小时为单位服务时间”的乘法操作，并作加乘积的操作，并把各个操作结果显示在工作站(ST14)上。同时，以ID码为次序对“客户名”执行排序，且对服务人员“Nakao”从9月21日到9月24日的信息按客户排序并在工作站上显示。且一个信息督促操作者确认被显示(ST14)的输入数据。

当操作者按下输入键时，数据被寄存在说明文件15中(ST15)、若有一个文件需要更新，主文件的内容相应地被更新(ST16)。

在说明数据输入处理(ST13)和确认信息显示处理(ST14)中，如果按下功能键F12，返回到步ST12的处理。如果在步ST11-ST14处理期间按下功能键F3，返回到菜单屏幕处理(ST10)。

“服务记录登入程序”的动作内容在编辑方式中已经说明。当动作方式是删除方式，所指令的对应于“服务人员”的“服务日期”的数据被全部删除。此处的窗口处理和设计模式1的处理相同。因此，随功能键F5的方式改变处理和随功能键F9的行处理进行基本处理。而随功能键F4的代码检索处理在建立框架的各个部分时选择一任选的处理。

设计模式7(框架ET153)实质上同设计模式6相同，所不同的只是缺少步ST12处理和不执行在步ST14的加操作。因此，在这种情况下在标头部分15A中的所有数据是关键字数据且对说明部分15B的加操作是不需要的，设计模式7的使用是一种明智的选择。

2.查询系统处理(设计模式8-14)

设计模式8-14是作同这种情况有关的处理，在那里信息检索命令由工作站WS形成，到盘存储装置3。这些模式分成2个主要组，即设计模式8-11是用在这种状况，在这种状况下被检索的数据不能清楚确定，而设计模式12-14是用在这种状况，在这种状况下查询的数据实质上能清楚的确定。

设计模式8-11由框架SK010同框架SK020，SK021，SK040和SK041结合而成。而设计模式12-14分别由框架SK050，SK051，SK060构成。因此，设计模式8＝SK010＋SK020

             设计模式9＝SK010＋SK021

             设计模式10＝SK010＋SK040

             设计模式11＝SK010＋SK041

             设计模式12＝SK050

             设计模式13＝SK051

             设计模式14＝SK060

在此，框架SK020，SK021，SK050和SK051适合查询事务文件数据。而框架SK040，SK041和SK060适合查询主文件数据。

[设计模式8，设计模式9]框架SK010＋SK020，SK021

如图13所示，框架SK010是一个框架，它包括对查询数据的输入条件的处理(ST22)和对指定的查询程序的处理(ST23-ST25)。而设计模式8，9把框架SK010同框架SK020，SK021结合起来，框架SK020和SK021适用于由设计模式1-7的程序寄存的事务文件数据的显示。

假设，“购物收据查询程序”由框架SK010和SK020组合而成，设计模式8和设计模式9的作用现作简要说明(图13)。再假设购物收据11(图4)已如图5所示的寄存在标头文件12和说明文件13中。

而“购物收据查询程序”从菜单中选择(ST21)，对条件的输入屏首先被显示在工作站上(ST22)。在这状态中操作者必须输入数据查询条件，假定操作者输入日期范围，例如“1994年10月3日到10月10日(ST22)。

然后，标头文件12用上面数据范围作为关键字被检索，结果相应的所有数据被显示在工作站上的显示屏上(ST23，图14)。如图14所示，在工作站上显示的表包括一个“作用码”列。这“作用码”术语意味一个码，它决定输出查询数据的显示的查询程序的哪一个用来实现查询处理。在此，作用码“1”和“2”分别对应于查询程序“PRG1”和“PRG2”。在本例中，假设，查询程序“PRG1”包括框架SK020而查询程序“PRG2”包括框架SK021。根据作用码的规定，是查询程序“PRG1”的处理或是查询程序“PRG2”的处理被启动(ST25)。

假定，图14的第2行用活动光标被选定，查询程序“PRG1”用动作码被选择。那末，用收据号“1”，收据日期“1994/10/3”和“ABC Industrial Co.”作为检索的关键字。说明文件13被检索且相应收据类型数据被显示在工作站上。以上是设计模式8的处理内容。

实质上，用动作码选择查询程序“PRG2”时同样适合的。唯一的不同是对每个购买项的单位购买价乘购买量的操作及乘积相加的操作被实现，且结果被显示在工作站上。以上是设计模式9的处理内容。框架SK021(设计模式9)同框架SK020(设计模式8)的不同仅在实现操作和显示结果上。

[设计模式10]框架SK010＋SK040

设计模式10由框架SK010和框架SK040结合而成。框架SK040适合显示由设计模式15-22寄存的主文件数据。例如，在图18中表示的“客户主文件”被查询的情况下，假定查询条件是客户码“0020-0030”(图13的ST22)，相应的厂商名的清单如图15(ST23)被显示。因此，光标被移到查询客户的位置，动作码被输入(ST24)，由动作码指定的查询程序的处理被启动，相应的信息被显示在工作站上(ST25)。在设计模式10中，查询程序由框架SK040构成，而框架SK040在工作站上执行主文件数据的显示处理。

[设计模式11]框架SK010＋SK041

设计模式11是一种设计模式，它由框架SK010和框架SK041组合而成。实质上执行同工作站上显示主文件数据显示的设计模式10相同的处理。图16是显示框架SK041的处理略图的流程图。这个框架同框架SK040的不同是这里数据显示在工作站上的二屏上。因此，设计模式11在这些情况下是有用的，这时一个记录数据甚多，不能在一屏内容下。图16中所示的功能键F8和F7用来作第一屏和第二屏之间的切换。

[设计模式12，13，14]框架SK050，SK051，SK060

设计模式12-14其特点在于并不执行如框架SK010所作的清单显示处理。因此，设计模式8-11是用于所检索的数据不能明确定义的情况，而设计模式12-14用于查询的数据能或多或少被定义的情况。设计模式12及13实质上同设计模式8及9是相同的。所不同的是相应数据不用表的形式显示。并且它适合访问事务文件的内容。设计模式14近似同设计模式10相同，且适合访问主文件的内容。

在设计模式12的程序的状况中(框架SK050)，对关键字输入的一屏如图17所示首先显示在工作站上(ST42)。假定，例如根据图8的说明文件14，“收据号”，“收据日期”及“供应方”的ID码被输入。那么，说明文件14用它们作关键字被检索而对应收据号的说明数据被显示在工作站上。如果在这个状态，那里检索的说明数据是在显示器上(ST43)，按下功能键F12，则保存输入的关键字数据并返回到步ST42。不考虑这个状态，按下功能键F3清除显示，菜单(ST41)重新开始。用功能键F4的代码检索处理是一个任选的选择窗口处理，用对任何应用程序用这处理选择，ID码可在步ST42的处理级内被检索。

框架SK051(设计模式13)实质上执行同框架SK050相同的处理，但在对查询数据的加操作的实现和结果显示上不同于后者。

框架SK060(显示框架14)，实质上同框架SK040相同，它适合显示由设计模式15-22寄存的主文件数据。例如，在关键字的输入时相应的信息从主文件上被检索，相当于一个记录数据被显示在工作站上。

3.主维护系统处理(设计模式15-22)

“主维护系统处理”意味着在主文件上对相当于一个记录的数据的登入，修改，删除或显示，对主维护系统处理，设计模式15-22对根据相当一个记录数据的数量选择使用是可能的，而框架MM010，MM011，MM020，MM021，MM030，MM031，MM050和MM051分别相应于这些设计模式。因此，框架MM010和MM011用来显示相当一个记录的数据，这些数据要一显示屏。框架MM020和MM021用来显示相当一个记录的数据，这些数据需要2个显示屏。框架MM030和MM031用来显示相当一个记录的数据，这些数据需要3个显示屏，而框架MM050和MM051用来显示相当一个记录的数据，这些数据需要4个显示屏。

现在，进一步解释取自图18的“客户主文件”作为所说主文件的例子。客户主文件具有字段客户码16a，厂商名16b，厂商类型16c，地址16d，电话号码16e，传真号16f，而客户码作为数据检索的关键字来表示。

[设计模式15]框架MM010

现在，参考图19的流程图来说明由框架MM010构成的“客户主文件维护程序”的动作内容。顺便提一下，这程序表示如图18所示在客户主文件中寄存一个相当一个记录的数据。

当“客户主维护程序”在菜单中被选择(ST51)，要求关键字输入的一屏在工作站上显示(ST52)，因此，操作员输入客户ID码(ST52)。

程序的动作方式是假定为“登入方式”。然后，一屏“厂商名”，“厂商类型”，“地址”，“电话号”和“传真号”的内容显示在工作站上。因此，操作员输入所需信息(ST53)，然后按下“输入”键。于是，为了确认的信息被显示(ST54)，而当再按下“输入(enter)键”，刚刚输入数据被加到客户主文件(ST55)。

上面已说明“登入方式”，如果在步ST52级按下功能键F5，程序的动作方式可通过窗口处理改变。如果在程序的动作方式已改变成“修改方式”后此键被输入(ST52)，则在屏幕上显示相应相当一个记录的数据。因此相应位置被修改(ST53)。如果在显示器上确认信息时，按下输入键(ST54)，客户主文件的内容被修改(ST55)。

在“删除方式”，在键输入时，指明的一个相当一个记录的数据被彻底删降。在“显示方式”，指明的一个相当一个记录的数据被简单显示在工作站上，而步ST54和ST55的处理被跳过。

[设计模式16]框架MM011

设计模式16其特点在于一个拷贝功能被用于图19的步ST52处理级，而其它方面它同设计模式15相同。“拷贝功能”是这样的功能，通过它已经寄存的相当一个记录数据能被拷贝成一新的记录。特别是在设计模式16中，要求输入“拟拷贝的原始记录”的一屏出现在步ST52(图10)的处理级。当客户码，如“0001”输入到“拟拷贝的原始记录”的输入列，在“ABC Industrial Co.”上相当一个记录的数据，在工作站屏幕上显示，因此，当被加的数据类似“ABC In-dustrial Co.”上的数据时，这个设计模型是方便的。因为仅仅部分数据不同于“ABC Industrial Co.”上的数据，需要被输入。

[设计模式17，18]框架MM020，MM201

当相当一个记录的数据内容需要二屏时，设计模式17的使用是合适的。而设计模式17的特点在于图19的在步ST53和ST54上处理是重复两次。设计模式18的特点在于能使用拷贝功能。而其它功能同设计模式17相同。

[设计模式19，20]框架MM030，MM031

当相当一个记录的数据的内容需要在工作站上有3屏时，对这种状况设计模式19是合适的，设计模式19的特点在于图19的步ST53和ST54上处理总的重复3次。设计模式20具有拷贝功能而其它同设计模式19相同。

[设计模式21，22]框架MM050，MM051

当相当一个记录的数据的内容在工作站上需要5屏时，设计模式21是合适的。设计模式21的特点在于图19的步ST53和ST54总的重复5次。设计模式22具有拷贝功能而其它功能同设计模式21相同。

4.窗口查询系统处理(设计模式23-26)

“窗口查询系统处理”术语表示用窗口W(图7)检索处理。为了执行设计模式23-26提供了框架WN010，WN011，WN012和WN020。设计模式22-26的处理是固定的数据检索处理，当在执行一调用程序中按下功能键F4起作用。而框架WN010，WN011，和WN012在对检索主文件中寄存的数据时是合适的。框架WN020在对检索事务文件中寄存的数据时是合适的。

[设计模式23]框架WN010

设计模式23的程序，例如在“客户主维护程序”(图19)的步ST52步中当按下功能键F4“客户主文件”被检索以检索出客户的ID码。“在客户主维护程序”中，客户的ID码必须在步ST52输入。无论何时，当ID码输入列保持空白时按下功能键F4或当ID码输入列字段有码时(ST52和ST60)时按下功能键F4，框架WN010开始起作用(图21)。

在框架WN010中，首先询问是否参数存在(ST61)，如果不存在，处理顺序进行到步ST62；如果存在，处理到步ST63。在上文中用的术语“参数”表示在调用程序工作中，在按下功能键F4时，设置检索起始码。在本发明例子中，在“客户主维护程序”的级ST52的处理级中输入客户ID码对应于检索起始码。

在“客户主维护程序”中，假定没有客户ID码的输入而按下功能键F4，在步ST61的判断被实现，然后，窗口显示输入检索起始条件出现(ST62)。由于在本例中，客户ID码现在被检索。在图22中所显示，举例来说相应于输入的检索起始条件的窗口显示。

如图22所示，在设计模式23的程序中，为输入客户ID码的列17a及输入客户名字(首字母)的列17b用假名字符显示。在相应列中输入ID码或假名字符是足够的。假定例如ID码为“0010”，在输入列17a处输入，ID码和相应客户名并排显示，对所有包含的码在ID码“0010”之后(ST63)。另一方面，假名字符“KA”在输入列17b输入，所有包括首字母的客户名在“KA”之后同他的ID码并排显示(ST63)。

在“客户主维护程序”中，那里客户的ID码已经被输入，步ST62的处理被跳过，包含的ID码和随后输入的ID码同客户各一起(ST63)显示。由于在何种情况下，在窗口显示屏上都出现大量客户名和相应的ID码，操作者能够移动光标到相应位置并按下“输入”键(ST63)。

假定相应的客户ID码是“0005”，保存ID码且序列返回到“客户主维护程序”(ST64)。结果“0005”在当调用程序屏幕被显示时，已经进入到客户ID码的输入列。如果在步ST62或步ST63的处理级中按下功能键F3或功能键F12调用程序重新自发地开始。因此，当调用被显示时，它的客户ID码输入列保持空白。

[设计模式24]框架WN011

设计模式24(框架WN011)实质上同设计模式23(框架WN010)相同，所不同的是在步ST62的处理级中，不能用的假名字符来指明检索起始条件。因此，设计模式24对主文件不利用假名字符检索的状态是有用的。

[设计模式25]框架WN012

设计模式25(框架WN012)同设计模式23和24一样是为了在屏幕窗口上处理检索主文件数据的。其动作内容类似于设计模式24(框架WN011)，而这种设计模式其特点在于在步ST62的处理级中，检索固定的值能被指明，而它与检索的起始码无关。检索固定值是检索条件之一的固定值以检索包含雇员的各种数据的雇员主文件为例，当仅仅是人员配借部门，例如，业务部被检索时，设计模式25是有作用的。

以上情况可以专门如下解释。在设计模式25的情况下(框架WN102)，当事业部门的ID码是一个固定值的检索，且雇员码“0020”是输入的检索起始码(ST62)，属于事业部门的雇员的全部数据并用包括的雇员码赋给，在工作站上跟随在“0020”后面被显示。

[设计模式26]框架WN020

设计模式26(框架WN020)对检索事务文件是合适的。亦就是说通过设计模式1-7的程序寄存数据。

其作用在图21的流程图中说明。其特点在于大量检索条件能在步ST62被输入。例如，在图8的检索说明文件14中，当供应方名“ABC Industrial Co.”和收据日期“10/3”被输入时(ST62)，满足条件的所有数据被显示在窗口中(ST63)。

5.收据打印系统处理(设计模式27-34)

设计模式27-34是处理打印收据或SliPs。

这些设计模式包括下述框架LT020，LT021，LT030和LT040的组合。

设计模式27＝LT020

设计模式28＝LT021

设计模式29＝LT010＋LT020

设计模式30＝LT010＋LT021

设计模式31＝LT010＋LT030＋LT020

设计模式32＝LT010＋LT030＋LT021

设计模式33＝LT040＋LT020

设计模式34＝LT040＋LT021

[设计模式27]框架LT020

图23的流程图中显示了设计模式27(框架LT020)的处理略图。该设计模式适合输出不包括数据划分的文件的内容的硬拷贝，如主文件。

首先，一个记录从相应文件(ST71)中读出，万一遇到EOF(文件尾)处理结束(ST72)，否则(如果不是EOF)执行打印编辑过程(ST73)。为了打印的编辑过程是一种处理，这种处理是对相当一个记录的读数据建立一适合的打印位置或类似事，然后询问相当一页的打印是否已经完成或未完成(ST74)，如果回答是肯定的，打印下一页的标头行(ST75)。

在另一页的标头行是不需要的情况下，因为仅一页已足够。相当于一页的编辑数据被打印(ST76)的同时，相当下一个记录的数据被读出(ST77)，且程序返回到步ST72处理。

[设计模式28]框架LT021

图24的流程图显示了设计模式28(框架LT021)的处理略图。该设计模式的特点在于对打印一个说明标头HD的处理(ST76′)，是插在步ST75的处理和步ST26的处理之间。这个“说明标头HD”表示例如在图8的说明文件14中收据号14A1，收据日期14A2，供应方名14A3和主管人14A4的内容，且每次一个收据的内容已被打印完，标头部分14A的内容被打印(ST76′)。

现在，参考图25所示的硬拷贝进一步说明图24的流程图。首先，从相应文件中读出一个记录(ST71)，如果遇到EOF(文件尾)，处理结束(ST72)，否则(不是EOF)执行打印的编辑过程(ST73)。然后询问是否相当一页的打印已经完成(ST74)，如果回答是肯定的且页改变已经完成，另一页的标头行被打印(ST75)。

页改变的过程是不需要的。它询问相当一收据的数据是否已经打印完，若回答是肯定的，标头部分14A的内容同标题一起被打印(ST76′)。且相当一个记录的编辑数据被打印。然后，相当下一个记录的数据被读出(ST77)且程序返回到步ST72的处理。

[设计模式29，30]框架LT010＋LT020，LT021

设计模式29和30是这样构成的，以使框架LT010的处理分别在框架LT020和LT021的处理之前。

如图26中所示，框架LT010执行一种处理以表明所打印的收据的范围。首先，要求输入打印条件的一屏显示在工作站上(ST81)。立刻，设计模式29说明取图18的“客户主文件”的内容打印为例。操作者例如输入ID码“0001-0010”作为打印条件(ST81)，在那里为确认的信息被显示(ST82)。然后，所读“在打印”的信息显示(ST83)且例如框架LT020构成的“收据打印程序”启动操作处理。

设计模式29刚刚已经说明，设计模式30同设计模式29的不同仅仅是在步84调用的收据打印程序由框架LT021构成。

[设计模式31，32]LT010＋LT030＋LT020，LT021

设计模式31和32是这样的以致于框架LT030的处理被包括在设计模式29和30的处理期间。图27所示的框架LT030的处理其特点在于主文件是完全地读一次而工作文件被更新。刚才上面所说的工作文件是一个典型的用作为加操作的文件。

以图8的说明文件14的内容打印为例，从说明文件14中读出相当一个记录的数据(ST91)。如果读出不是EOF，为了打印读数据被编辑(ST93)。然后，对“单位购买价格”同“购买量”相乘的乘积执行加操作(ST94)。因此，相当下一个记录的数据被读出(ST95)而程序返回到步ST92的处理。

在框架LT030的处理之后，由框架LT020或LT021的处理实现实际打印。

[设计模式33，34]LT040＋LT020，LT021

设计模式33和34是这样的以致于在设计模式27和28的处理之前实现框架LT040的处理。如图28所示，框架LT040的处理同框架LT010一样指明将被打印数据的条件。框架LT010和LT040之间的不同是在框架LT040的情况下，满足条件的数据表被显示。现在，此图5所示的事务文件12，13内容的打印作为例子，解释图28的流程图。

首先，在工作站上显示输入打印条件的内容。现在，假设操作者指明“1994/10/1-10/5”(ST101)的条件。

那么，所有满足上述条件的数据，显示在图14中(ST102)。同时，作用码输入列亦显示在工作站的屏幕上。因此，操作员输入相应作用码(ST103)。

因此，为确定的信息被显示(ST104)。然后，读作“在打印”的信息显现(ST105)事务格式程序被调用(ST106)。事务格式程序已被准备好或者用框架LT020，或者用框架LT021。而设计模式33或设计模式34的选择是取决所用框架LT020和框架LT021中的哪一个。

6.批作业更新系统处理(设计模式35，36)

[设计模式35]框架BU020

设计模式35(框架BU020)是用于处理在工作站上不对话的文件更新的那种场所。典型地，在这种情况下事务文件数据被读出一相当记录，接着更新相应于这种处理的主文件的内容。而且，在打印输出累加在事务文件中的数据之前，对应于收据打印图象(如图25)构成临时文件(工作文件)的过程亦对应于这种处理。

对上面的处理，现在参考图29的流程图来解释。首先，读出事务文件的开始的一个记录(ST111)，若不是EOF，执行说明编辑(ST113)。这说明编辑表示一种处理，用来编辑相当一个记录的读说明数据成为主文件，临时文件或类似的被更新文件的格式。

然后，基于相当一个记录的编辑数据主文件，临时文件及相似文件被更新(ST114)。然后，从事务文件(ST115)中读出相当下一个记录的数据，且程序返回到步ST112的处理。

[设计模式36]框架BU010＋BU020

设计模式36是一种处理，在这种处理中，输入更新条件输入优先于设计模式35的处理。

如图30所示，输入更新条件的显示首先出现在屏幕上(ST121)。这里，作为一个例子，取图11的事务文件中，以寄存的数据中从9月21日到10月20日的数据为基础，更新主文年为准备供方票据，例如，操作员在工作站上(ST121)输入“9/21-10/20”的更新条件。

然后，一个用来确认的信息出现(ST122)。当操作员按下输入键，读“更新”信息出现(ST123)。由框架BU020组成的更新程序被调用(ST124)。此后，根据设计模式35的过程仅读出图11的事务文件的相应记录且更新主文件的内容。

设计模式1-36已详细说明。现在说明通过对话的自动程序生成过程。例如，现在来说明，直到一个“雇员主维护程序”结束的处理内容。“雇员主维护程序”是一个应用程序，这程序通过图1的计算机系统工作。通过这个程序，在磁盘存储器3内存储的“雇员主文件”从工作站WS1-WSn存取以登入，修改或删除各个雇员的数据。

根据本发明的自动程序生成可分成下面n个处理阶段(1a)物理文件设计(1b)屏幕图象文件设计(1c)事务格式文件设计，(2)单位信息登入及(3)详细的程序设计。然而，遇到一个“雇员主维护程序”，其中不包括收据打印处理的情况，“雇员主维护程序”的自动生成仅通过物理文件设计(图31)，屏幕图象文件设计(图34)，单位信息的注册(图38)和详细的程序设计(图39)完成。(1a)物理文件设计(图31)

用计算机设置物理文件设计的作用方式。物理文件的设计通过对话执行。由于在本例中的任务是设计一个“雇员主文件”，它顺序的决定一个记录提供什么字段，分配给每个字段的区域用多少字节及对数据选择什么样字段用作数据检索关键等等(ST131)。

在完成所有信息输入后，根据有关操作数据库设计文件被打印输出(ST132)。图32显示一个数据库设计文件。由于“字段名”20a，“字段ID”20c，“字段类型”20b，“字段数字号”20d，“数据类型”20e等根据预定格式被显示。设计的内容一看就能确定。而且，只要这个数据库设计文件被存贮，任何人能很容易知道“雇员主文件”的内容。

通过对话完成了物理文件设计后，物理文件的源码就自动生成(ST133)。且根据适当操作，一个物理文件源清单被打印(ST134)。图33显示了这个源清单。因此，完美符合图32的设计文件的源清单的硬拷贝被得到。

然后，源码被编译且在盘存贮器3内“雇员主文件”区域被获得。在本例中，“雇员主文件”的ID是“RCMEMPP”，且“EMPCDE”-“EMPUDT”的ID字段被定义。(1b)屏幕图象文件设计(图34)

此外，当计算机被设置到屏幕图象文件设计的作用方式，屏幕图象文件的设计通过对话实现。在屏幕图象文件设计中，所用的框架必须首先确定。在本例中，“雇员主维护程序”利用框架MM011制备(设计模式16)。

正如图19所示，框架MM011(设计模式16)需要一屏为关键字输入(ST52)，一屏为说明数据输入(ST53)及一屏显示信息，这些信息用来核实说明数据的当前显示(ST54)。因此，这些是逐步被确定的。

通过步ST141处理，完成了全部屏幕图象设计以后，一个合适操作被形成。随后，一屏图象文件设计文件被打印输出(ST142)。这屏图象文件设计文件，在所有屏幕显示器上(ST52，ST53，ST54)设定以下详细信息，这屏图象设计的内容可以从这屏幕图象设计文件中正确的确定。图35和36显示“图象布置”作为屏幕图象文件设计文件的一部分。很显然，在图19的步ST52中，在工作站上显示屏如图35中所示(FMT01＋FMT91)，而在图19的步53和54中，在工作站上的屏幕正如图36所示(FMT02＋FMT01＋FMT91)。

屏幕图象文件的设计完成后，屏幕图象文件的源码自动生成(ST143)。根据相应的操作，一个物理文件源清单被打印输出(ST144)。图37显示了屏幕图象文件源清单的一部分。尤其是第17行到第52行显示了有关屏幕图象(EMT01)的源清单为在步ST52输入关键字数据(图19)。

然后，编译源码，形成屏幕图象文件的目标码(ST145)。这屏幕图象文件的名字是“雇号主维护”而文件的ID是“RC00 D001”。

(2)单位信息的登入(图38)

现在，用适当操作，计算机应该设置单位信息登入方式。在单位信息登入方式中，用对话指定“雇员主文件维护程序”的轮廓。

如图38所示，将被准备的程序名和所用框架必须在开始时指定(ST151)。在此，程序调用的“雇员主维护”用如上所述的框架MM011生成。因此，这些信息可以简单地从工作站上输入(ST151)。

然后，如果所生成的应用程序被不同程序调用，从其它程序接收的参数被确定(ST152)。在本例中，没有参数打算从其它任何程序接收。

然后，由“雇员主维护程序”所用的文件被确定(ST153)。在本例中，“雇员主(RCMEMPP)”用作物理文件而“雇员主维护(RC00D001)”被指明为屏幕图象文件。

最后，在“雇员主维护”程序的操作期间一个外部调用程序被确定(ST154)。在本例中，用功能键F4的码检索处理(图19)被使用。因此，为码检索的外部程序被指明。假定，为了码检索的程序已经用框架WN010，WN011和WN012的任何一个准备好。(4)详细的程序设计(图39)

单位信息登入完成后，下面是如图39的详细程序设计处理。在此，通过对话输入随各个处理变化的详细信息(ST161)。因此，由于框架MM011分成整体部分A和个体部分B(图2)，以使多样化的处理能按照图19的过程形成。而“雇员主维护程序”的实质部分在步ST161阶段详细建立。

在完成了上面处理后，程序设计部分根据有关操作被打印(ST162)。在图1所示的自动程序生成器中，对设计模式1-36的每个程序设计文件，以半成品状态存到磁盘存储器3中。因此，在完成了上述详细程序设计后(ST161)，完美对应于特殊程序的一个程序设计文件作为硬拷贝可以形成。

而且，当详细程序设计(ST16)完成后，“雇员主维护程序”的源码通过输入信息结合自动生成，至此所用框架MM011的源程序事先已存储。源码被编译和目标程序被生成(ST165)。而且，根据有关操作，一程序源码清单被打印(ST164)。

图40显示了框架MM011的源程序的一部分，而图41显示了，打印“雇员主维护程序”的部分源码。而“雇员主维护程序”的源码所用列用标志“//”或“/”填充。用标志“//”的行是表示从框架MM011的源程序直接拷贝，而用标志“/”或保留空白的行表示根据输入对话信息自动生成的行。在图40中“PLIST COMMON”指明的行是从图41的行136-143插入的“KLIST COMMON”和“MAK-ING NG”所示是从图41的行150-155插入。而且，图10的“COPY-RIGHT”指明的行对应于图41的行159。

在图1的自动程序生成器中，所有应用程序由框架结合而生成，这些框架是处于半成品状态下的源程序。这些框架用特殊程序设计语言由熟练的专职程序员编制的高质量程序，并通过对话进行程序设计。因此，即使是初学者能容易地快速自动生成恒定质量的应用程序。

而且，因为一完成的设计文件，可以以硬拷贝的形式完美对应于一个成品的应用程序。任何人能正确掌握程序处理的内容。因此，即使当构成的操作或机能发生变化，任何人能容易地对应用程序修改或形成初充。

Claims (9)

1.一个自动程序生成器包括：

一个框架存储装置，它存储的框架是半成品状态的源程序；

一个设计文件存储装置，它存贮半成品状态的设计文件，这种半成品状态说明所说框架的处理内容；

一个各自的信息输入装置，该装置在应用程序设计中的作用是接收通过对话随不同应用程序变化的各个信息；

一个程序最后加工装置，它根据所接收的各个信息，编辑所说的框架以产生各种应用程序的源码；

一个设计文件最后加工装置，它根据所接收的各个信息，编辑所说的处于半成品状态的设计文件，并最后加工分别对应于应用程序的设计文件；

一个输出装置，它根据各种操作功能去打印输出源码清单和/或各种成品的应用程序的设计文件。

2.根据权利要求1的自动程序生成器，其中所述的框架存贮装置存储半成品状态的至少第一组程序，这组程序是在事务文件中寄存数据；第二组程序，用来检索数据文件的数据并在终端屏上显示它；第三组程序，用来在主文件中寄存数据；第四组程序，用来检索数据文件的数据并在终端屏上的窗口中显示数据；第五组程序，用来打印事务格式的数据文件的内容和第六组程序，用来更新所用事务文件的数据的主文件或临时文件的内容。

3.根据权利要求1的自动程序生成器，其中所说的设计文件存贮装置至少存储一个物理文件设计文件，一个屏幕图象文件设计文件，一个事务格式文件设计文件及处于完成品状态的每个程序设计文件。

4.根据权利要求2的自动程序生成器，其中所说的第一组程序分成多个程序，这些程序处理用收据号和行号提供的收据型数据，有些程序处理既不用收据号也不用行号提供的编辑型数据。

5.根据权利要求2的自动程序生成器，其中所说的第二组程序分成很多程序，这些程序具有催促操作员去输入查询数据的条件并显示满足所说条件的所有数据的清单，这些程序不具备显示所说清单的功能。

6.根据权利要求2的自动程序生成器，其中所说的第3组程序根据相当一个记录数据量的关系分成大量程序，且这大量数据能在单个终端屏上被显示。

7.根据权利要求2的自动程序生成器，其中所说的第4个组程序可以分成用来检索主文件的程序和用来检索事务文件的程序。

8.根据权利要求2的自动程序生成器，其中所说的第6组程序可分成二种程序，一种程序具有催促操作员去输入将被打印数据的条件，并显示满足条件的所有数据的清单的功能，另一种程序不具有显示所说清单的功能。

9.根据权利要求1的自动程序生成器，其中所说的应用程序的程序设计语言是RPG语言，C语言和COBOL语言中的任何一种。

Images