CN1240522A - 用于计算机应用程序开发和执行的方法、***和数据结构 - Google Patents

Abstract

对软件开发和执行的一个方法、***和数据结构包括一个实时事件管理器和一组模型。一个模型是一类数据结构,它们不包含程序码,而是一个有序的参照组,参照其他模型、方法或其他对象。一旦满足一组条件,将模型登录,它们就能被实时事件管理器访问。在本发明的一个实施例中,实时事件管理器是一个用程序代码执行的调入－执行循环,它在每个循环中操作一组模型,校验外部输入/输出状态,且在这种条件下可以处理不同的或变种的模型,而不是具有默认条件的标准的或规范的模型。且按本发明可以实现一个弹性数据库,以允许动态地扩展数据库的功能。

Description

用于计算机应用程序开发和执行的方法、***和数据结构

                            发明领域

本发明与计算机编程有关，特别地与计算机软件应用开发和执行有关。

                            背景

计算机应用软件的开发和修改需要使用编程规范编写代码或软件目标(“对象”)，例如使用第三代语言(“3GL”)、***语言(“4GL”)或面向对象的开发(“OOD”)方法。这些传统方法的关键限制之一是它们在软件开发和修改中使用时需要开发者实际修改代码。不仅从编码涉及的劳动力观点看，还是从软件开发和测试过程中有关的协调计划看这都是一种麻烦的限制。

近年来出现的面向对象的主导编程方法通过提供高度模块化、自然且可重新使用的编程结构促进了软件开发计算。作为背景，术语“对象”，正如被面向对象软件和编程领域技术人员所使用的那样，是指以数据结构形式出现的软件组成部分，通过从一个向另一个发送消息它们能互相通信或调用。相应于相同消息的对象被说成具有一个共同的“类”。对象的“类”描述并实现捕捉该类的“实例”(即对象)行为的所有方法。一个类的实例的状态或结构由模板所规定，模板可以规定：一个对象的状态包括了其它对象、由OOD引入的模块性有助于用分治法解决问题，能较容易调试，允许对现实世界问题或环境有效高的保真模型并能产生可重复使用的代码。但还是要求编写和测试代码。

一个计算机“应用”就是一个程序，计算机用户用该程序交互地执行一项任务，并且有别于***软件其它软件(它们为设计的应用软件创建运行的功能环境)。然后，计算机应用软件的开发者参预对用户接口的支持和达到用户的目标。

在许多应用环境中，特别是基于用户开发的软件环境中，用户的需求在更新。想满足这些需要的应用软件最好能跟着更新。然而，用现有的方法修改应用软件--即使由OOD方式提供了模块方法--需要编写或修改计算机代码，调试代码，且进行中要对应用的使用造成最小的干扰。然而，这一目标已证明难以把握。

为了开发和修改软件应用，除了与需要编写和集成新代码有关的问题外，现行的软件应用开发或修改方法的另一个问题是这些代码还必须适应外部事件的处理，例如用户的输入/输出(I/O)或其它事件的发生。然而，由于这种用户I/O或其它事件可以在一种用户环境和另一种用户环境之间变动很大(例如，与字符输入相对的图形用户接口(“GUI”)，用现有技术适应这种不同外部事件的能力要求或者(1)费时的客户软件开发、完成调试的过程，或者(2)开发一组具有足以处理意外事件能力的代码以能在各种当时所知的应用环境中能工作。在每一种情况下，对于每个应用环境要求大量的编码和测试过程，一旦这种外部事件条件变化发生时，只有或者与应用环境下要改进的软件缺点共存或者完成艰巨的再编码和测试过程。

                          发明概述

本发明是针对一种用于计算机应用软件的开发(包括设计、建立、测试、维护和修改)和执行的方法、***和数据结构，它能减轻由现行技术的用户所遇到的许多应用设计、测试和修改问题。

最值得注意的是，通过用下面将详述的运行时间事件管理器和以后连接、可重新使用的模块、方法或其它对象来替换代码可以排除对被编码应用程序的需要。代替用作应用的程序源代码或目标代码或者任何形式的以后连接或动态连接的运行时间应用代码，本发明的一个实施例提供了单个与应用无关的软件实体，这里称之为运行时间事件管理器(“RTEM”)并描述如下。RTEM是在按照本发明开发的任何应用的运行期间存在的单个控制实体。任何时候给定应用和输入/输出状态时RTEM继续确定通过调用任何可供使用的手段计算机所作的什么才是最合适的。然而，RTEM并不实际完成它所确定的合适的功能，仅是调用完成这功能所必须的手段-包括对象、应用专用对象及工具。(本文档中所用的“工具”这一术语，指的是允许或提供对低层或操作***功能访问的过程代码；例如，下述的数据库访问工具(“DBAC”)向数据库读写信息。本文档中所用术语“工具使用”指的是允许对工具访问的模型设计对象，即它为工具提供了接口定义，例如使用DBAC进行读或写的参数)。这些对象和工具(包括方法、I/O工具或其它能在计算机上实现功能性的软件结构)并不独立于RTEM的指导而工作。换句话说，它们最好由RTEM且仅由RTEM调用来实现RTEM调用它们所要作的功能。

为了由RTEM调用对象和工具以完成一种功能，按照登录过程对象和工具必须可供RTEM使用，示例如下所述。例如，根据本发明，没有对象和工具可以被登录而为包含了将控制从RTEM转移开的指令的RTEM所使用。因此，例如一个使用由RTEM运行的应用的操作者可受到保护不至于不适当地超越任何应有的特权，否则会因请求了禁用的动作而危及应用的整体性。此外，RTEM重复地检查诸如操作者的交互操作等外部事件且因而能立即与操作者交互对话，例如提供信息、接收指令、开始应用任务、跟踪时间或其它功能。

在本发明的一个实施例中，RTEM是一个模块，它管理所有的运行时间事件并实现与操作者的通信。一个“事件”可定义为任何计划发生的事情，最明显地包括了以预定的方式完成一个应用过程中所发生的事情。根据本发明，RTEM最好是应用的操作者直接与之通信的唯一软件，即使操作者要直接与应用通信时亦如此。RTEM将来自操作者的信息中转给要实现信息的应用事件。RTEM也把应用给出的信息返回中转给操作者。

除了在操作者和应用之间中介传递外，本发明实施例中的RTEM在运行时间任务期间中介传递所有的事件，这是由于如上所述(以下将详述)，对象或工具不能调用或与另一个对象通信。根据本发明，通过重复检验和处理“模型”以执行模型中所捕获的与应用有关的逻辑，RTEM能调用或与另一对象通信。每个模型指定了与应用有关的过程。模型最好只包括数据，即不可执行的对象(全部或部分均可)。模型中的数据向处理该模型的RTEM提供规则、工具、格式和RTEM必须调用的应用专用对象以使与应用处理有关的运行时间事件出现。

在本发明的实施例中，模型是对提出与应用有关的处理的对象和数据引用的列表；然而，如下所述，根据给定时刻的应用或外部条件的状态，RTEM在合适的时候可以对由模型表示的处理概要作全部或部分的忽略、更改和/或添加。在缺乏相关的、有效的认可的可替代信息时，在运行时间上模型后面绝对地跟随着RTEM。

根据本发明，由RTEM调用和检查的模型包括范例模型和与给定的范例模型有关的派生模型。范例模型描述了与应用有关的“标准”处理过程。派生模型描述了有关“标准”处理的各种变化。根据本发明，两种模型在经过评价以确定它们的形式(包括它们的构成数据)是否遵照由RTEM处理的有关的约束后必须被登录。虽然范例模型可以为应用的一部分提出了一组规则，派生模型则表示了一组子规则，指明在某种条件下标准的或范例的处理方式可由更改的变化的规则所替代。

在本发明的实施例中，派生模型仅指与它有关的范例模型有所不同或有变化的模型；如所述，RTEM10随后监视应用和外部运行时间事件，并且随着条件变化它识别和检验在这些条件下所应用的派生模型并调用所应用的这些派生模型。根据本发明，当按照预先条件把模型登录为可供RTEM使用，RTEM识别和存储在运行时间调用派生模型的逻辑时所处的一组条件。

另外，根据本发明，与范例模型有关的派生模型不用对范例模型或其它派生模型修改即可创建和登录以建立对派生模型在模型方面的任何引用。通过创建新模型而对应用进行修改使得对现行模型重新测试的需要最小化，也使在修改期间的扰动影响最小化。任何数目的另外派生模型均可独立地创建以取代相应的范例模型而不致于引入与每一模型有关的逻辑间的互相干扰的危险性。这一能力反过来又方便了测试；模型可被独立地测试而先前开发的模型的功能不必再重新测试。按照实际的软件开发，独立的开发/维护小组可以创建派生模型而不用知道其它此类小组正在工作的模型。另外，在已配置了该软件的本地站点上客户所作的工作也不会受到由原始(非本地)作者建立的升级而受到损害，且因而在升级时不必重作。还有，对于同一应用修改的多个有冲突的请求也能同时由非协调的开发或维护小组或个人来完成。因此，统一的测试可被减少或免去。

在本发明的实施例中，RTEM还用工具来对***输出和输入重新整形或重新格式化，包括持续的数据存储(数据库)、外部(I/O)媒体、例如屏幕或报表、以及电子数据交换处理(例常规的“EDI”)。为了这样做，RTEM使用了工具以及在这里称之为“超级工具套件”的工具组以处理这类***输入和输出：(1)数据库访问控制器(“DBAC”)(一个工具)以及(2)用户I/O(“UIO”)，两者将进一步描述于下。这里所用的术语“超级工具套件”指的是工具的集合。例如，RTEM访问UIO超级工具套件以执行所有对用户的表示，包括了经键盘从用户处检索信息的输入工具，并还包括了以不同的格式(即GUI或字符)的形式显示信息的表示工具。表示工具可以包括输入、显示文本和屏幕工具，它们可以根据本领域内技术人员所熟知的方法来实现。

在本发明实施例中，在一定意义上，RTEM也是一个工具，它加载模型和调用其它工具、模型及方法以执行特定应用所需的行动(即，它调用表示层工具以可视形式显示数据或调用数据库访问工具(DBAC)，以从数据库检索信息。

在本发明的实施例中，DBAC由RTEM调用以在使用RTEM的时期与任何持续数据库被调用之间以能逻辑存入和检索数据。在这样实施例中，持续存储作为表格被浏览，该表格每行可具有不同的数据元素组成部分(即，或多或少或不同的元素)，或甚至具有较多或较少的表格，这取决于给定应用时期的任何给定瞬间RTEM所工作的变异模型。这一持续存储的观点在这里称之为“弹性数据库”。

在本发明的一个实施例中的DBAC由RTEM调用以填补应用的逻辑“弹性”存储观点和实际RDBMS(非弹性)的行和列之间的间隙。DBAC管理有关跨越多个常规受RDBMS控制的表格的弹性数据行的存储和检索。相同的用于模型的登录过程(下述)还处理所有其它对象。登录过程能以常规RDBMS中不存在的方式定义弹性(或变化的)关系。出于效率的目的，DBAC的逻辑可以在客户和服务器任务器之间分配。预先存在的表格不必(最好不要)修改以适应随后的变化，例如通过逻辑上将变化的信息与表格的一些或全部行相连接。

根据本发明，变化的文件关系可以在运行中，实时地更新入数据库，不会破坏正常的生产。在RTEM控制下的DBAC用作中介传递应用和基于的数据库之间的所有交互作用。这意味着RTEM可以干预其它情况下为正常的应用和其弹性数据库间的交互作用并能改变该交互作用而不需用调节方式来修改应用或数据库。因此，例如，RTEM可以启动一“测试周期”，它将使用“现场”的生产数据库，同时进发运行的生产过程又在改动数据库，即使正被测试的应用包括了对它的数据库写入和更新也不会干扰和破坏当前运行的数据。

在本发明的实施例中，不管应用是否处在测试模式还是生产模式，RTEM都可以进行任选的确认或验证测试。具体说，RTEM可以在调用每个模型和方法前后，甚至在调用一个模型的每个步骤(即，元素)前后检查所有的变量和强制条件。

非破坏性测试要求新的对象是变异的或作为命名项目的部分而修改被登录为测试。这类测试对象只能在一段时期内被RTEM所调用，该段时期的运行状态已被指定为“测试”并在项目定义期间已与适当的项目标识相关联。除非已通过了登录测试期，新修改的对象最好不要在生产过程中被访问。

在本发明的实施例中，所有的“写”均被重定向到测试项目命名的测试目录数据库。所有的“读”首先试用测试目录(如必要，测试目录的表由DBAC在运行中设定)，然后再试用生产数据库。所有用于测试的只读生产记录也重新产生在测试目录中，即使这类记录要求按照测试的预先条件改变数据的格式也如此。这种方法能产生高保真的测试期记录并允许继续记录或化最小的力气从头开始重做。

在本发明的实施例中，UIO被RTEM用作在应用和其用户I/O之间传递交互作用。用户I/O包括的I/O不只限于计算机和有关网络的I/O，包括了屏幕格式，数据输入设备、电子数据交换(“EDI”)处理和其它I/O。

按照本发明的应用的设计和修改不必对I/O加以考虑，且不必包括任何与该功能性有关的逻辑。这种处置代表了对传统技术的一种改进，它更紧密地依赖于应用本身。例如，本方法作为特定时刻的条件的函数允许灵活的***，变化的I/O性态。

因此，本发明还提供了一种开发应用软件的新方法，它允许以最小的或不作代码变动而把新的能力加到现在使用的软件中，对与传统应用软件开发有关的用户活动干扰最小或不干扰。

本发明还根据软件运行的局部环境方面的要求提供具有极其不同处理性能的计算机软件和它处理的特殊数据。

根据本发明的计算机可存储数据结构和方法，以及它们允许的软件开发方法，按照本发明还允许把非统一的数据结构定义为一组逻辑数据结构，每个逻辑数据结构在常规的数据库中被归一化和定义了，在本发明的一个实施例中，在具有处理器、内存储器和存储媒体的计算机上实现的运行应用软件的***，包括了存储在存储媒体中的多个模型和一个运行时间事件管理器。每个模型包含的数据包括对一个或多个对象的引用，而运行时间事件管理器适用于将所选的多个模型之一从存储媒体加载到内存、读取所选模型的数据以及当对一个对象的引用被读取时，调用并执行合适的工具以提供该对象。

本发明为计算机的执行提供了运行时间事件管理器，它执行与指令有关的处理活动并响应通过外部输入和输出与计算机通信的计算机外部事件。计算机包括了用于存储可由运行时间事件管理器访问的一组模型的存储媒体。运行时间事件管理器包含了用于从模型库加载模型的装置、用于在给定计算机状态和运行时间事件管理器时确定模型是否被适当地调用的装置、在给定计算机状态和运行时间事件管理器时若确定为合适的话调用模型的装置、以及调用(即，实现其意图)模型的装置。

本发明还提供了利用运行时间事件管理器开发计算机应用软件的方法。该方法包含的步骤包括建议多个模型，其中每个这类模型包括至少下述之一：i.对模型的引用；ii.对方法的引用；iii.数据；以及iv.输入或输出指令。附加的步骤包括对模型测试以确保在模型中引用的方法没有一个能：(1)调用另一个对象，无论是模型、方法或工具；或(2)对屏幕、文件或任何其它设备或对象进行输入/输出(I/O)。另外在测试中合格的模型被登录以允许运行时间事件管理器访问。

本发明还提供对登录为被运行时间事件管理器使用的对象库的创建。登录过程包含的步骤为：根据模型的唯一标识符调用对象、扫描对象的内容看是否存在限制内容、以及只有当对象内容不包括限制内容时把对象作为库的一部分而登录。

本发明还提供了在具有处理器、内存储器和存储媒体的计算机上实现的数据库***，包含一个库文件和一个可变集，具有编程的***以实现可变集运行时间映射，适用于确定哪一个可变集用于库文件的特定基本记录。可变集包含的记录至少具有与基本记录对应的一个附加字段。

本发明还提供了一种方法，用于对具有一个库文件和一个可变集的数据库***进行操作。该方法包含的步骤包括加载基本记录、检查可变集运行时间映射是否存在与库文件对应的可变集、以及如果可变集存在则从可变集检索数据。

因此，本发明的一个目的是提供一种用于开发和修改应用软件的方法、***和数据结构，它免去了需要编写代码来实现与应用有关的功能性。

本发明的另一目的是提供一种利用运行时间事件管理器和一组有关模型开发、测试和执行应用软件的方法、***和数据结构。

本发明的另一目的是提供一种利用运行时间事件管理器和一组模型开发、测试和执行应用软件的方法、***和数据结构，其中模型已被登录为可供运行时间事件管理器根据一过程而访问，该过程排除了调用未登录对象或由另一方法调用一个方法的操作。

本发明的另一个目的是提供一种利用运行时间事件管理器和一组有关模型开发、测试和执行应用软件的方法、***和数据结构，其中该模型组包括了范例模型和派生模型。

本发明的另一个目的是提供一种用于实现“弹性数据库”的方法、***和数据结构，“弹性数据库”允许用变化集中的附加字段来扩展其库文件中的库记录。

本发明的另一个目的是提供一种利用运行时间事件管理器和一组有关模型开发、测试和运行应用软件的方法、***和数据结构，其中模型之一提供了将传统软件集成为一新开发的应用的手段。

本发明的其它目的和优点在阅读了下述描述后对于本领域的技术人员来说将是显然的。

                           附图简述

图1示出了根据本发明的一个***的实施例结构。

图2示出了根据本发明的应用接口和一组模型库或引擎例子的实施例。

图3示出了符合本发明实施例的运行时间事件管理器、模型、方法和数据的组织。

图4所示示例模板表示了根据本发明的模型的实施例的形式。

图4A示出了模型的另一个模板的示例，比图4更详细。

图4B进一步示出了模型数据结构的第一部分的定义，显示了对模型的详细处理信息。

图4C进一步示出了模型数据结构的第二部分的定义(续图4B)，显示了对模型附加的详细处理信息。

图5示出了根据本发明的用于实现一个应用菜单的模型的具体例子。

图5A示出了根据本发明的派生模型的具体示例。

图5B示出了保存派生模型信息的表格。

图6所示流程图用于在本发明的一个实施例中登录包括模型的对象。

图6A所示的流程图用于操作与图6所示登录过程有关的所用的模型设计工具。

图7A所示为流程图的第一部分，该流程用于在本发明的一个实施例中在应用开发或修改过程期间创建测试模型用的测试平台。

图7B示出了用于在本发明的一个实施例中在应用开发或修改过程期间创建测试模型用的测试平台的流程图的第二部分。

图8示出的流程图描述了本发明的一个实施例中的运行时间事件管理器的一个实施例的操作。

图9所示流程图描述了图8的运行时间事件管理器实施例的关于派生模型的处理部分。

图10所示的流程图描述了图8和图9的运行时间事件管理器实施例与加载和卸载派生模型有关的处理部分。

图11所示为对于弹性数据库的库文件和基本记录的解释性示例。

图12所示为对于弹性数据库的二个可变集定义的解释性示例。

图13A示出了描述关于在弹性数据库中定义一新可变集的步骤的流程图的第一部分。

图13B示出了描述关于在弹性数据库中定义一新可变集的步骤的流程图的第二部分。

图13C示出了描述关于在弹性数据库中定义一新可变集的步骤的流程图的第三部分。

图14所示流程图描述了在弹性数据库中打开一数据目录的过程。

图15所示流程图描述了在弹性数据库中打开一逻辑文件的过程。

图16A所示的流程图描述了确定把哪一个可变集加到弹性数据库中所选基本记录的过程的第一部分。

图16B所示的流程图描述了确定把哪一个可变集加到弹性数据库中所选基本记录的过程的第二部分。

图17A所示的流程图描述了与数据库访问工具的“读”功能有关的步骤的第一部分。

图17B所示的流程图描述了与数据库访问工具的“读”功能有关的步骤的第二部分。

图18A所示的流程图描述了与数据库访问工具的“提取”功能有关的步骤的第一部分。

图18B所示的流程图描述了与数据库访问工具的“提取”功能有关的步骤的第二部分。

图19所示流程图描述了与数据库访问工具的“证实”功能有关的步骤。

图20所示流程图描述了与数据库访问工具的“生成”功能有关的步骤。

图21A所示的流程图描述了与数据库访问工具的“写”功能有关的步骤的第一部分。

图21B所示的流程图描述了与数据库访问工具的“写”功能有关的步骤的第二部分。

图22所示的流程图描述了与数据库访问工具的“移去”功能有关的步骤。

图23所示的流程图描述了与数据库访问工具的“关闭”功能有关的步骤。

图24所示的流程图描述了与数据库访问工具的“关断”功能有关的步骤。

图25所示的流程图描述了与数据库访问工具的“取关键字”功能有关的步骤。

图26所示的流程图描述了与数据库访问工具的“取第一关键字”功能有关的步骤。

                           详细描述

图1示出了根据本发明的一个***的实施例结构。下面结合图8-10详细描述的运行时间事件管理器(“RTEM”)10是一组负责执行与应用有关的所有处理的过程。RTEM10可访问各种数据和对象，包括数据目录12、标准模型14、开发者的任选模型16、本地模型18和本地环境20。“标准”或“范例”模型14是由特定应用的作者提供的这些用作实现与该应用有关的处理的模型，并提供规定该应用如何完成的规则。标准或范例模型14提供为应用处理最终的默认值。由应用的作者提供的开发者的“任选”模型可作为标准或范例模型的全部或部分替代以考虑到应用将调用的处理，虽然它是对标准或范例的处理。作为例子，在后勤应用调配中，已提供产品调配模型，只是在某种条件下也可以提供附加的任选模型以执行捕获输入和更新不同的文件，例如若道路运输模块已接通。本地模型就是指定给已配置了应用软件的现场的那些模型，且应用软件已被唯一地配置成适合该现场的应用要求。例如，本地模型将包括与本地现场有关的处理，例如在该现场处的相关的装备、操作员等等。本地环境20代表了说明应用将工作的特定调整的数据和条件。

RTEM10也能对一组控制器访问。第一个这种控制器就是构架22，如下所述它按照由RTEM处理的模型实现数据处理。包括了应用(例模型、方法、数据、文本等)和所有支持对象，例如工具的所有登录的对象称之为“构架”。构架22提供了每个对象和与它有关的每个其它对象间的交叉引用，使对象能被开发者访问和理解它根据本领域技术人员熟知的方法而开发。

RTEM可访问的第二控制器是数据库访问控制器(“DBAC”)(客户侧)24。DBAC(客户侧)24允许RTEM10通过(如必要的话)中间件构成，例网络连路或共享存储器78获得对数据的访问。此外，DBAC(服务器侧)30如有必要则根据包含给定应用的模型允许与商用或者专用数据库互联。例如，RTEM DBAC(服务器侧)30可与开放数据库连接(“ODBC”)驱动器32和Oracle^RDBMS34，或与SQL3服务器38和Oracle^8面向对象数据库管理***(“OODBMS”)40，或与BASIC文件服务器42和BASIC文件***44、或与任何适当的数据库软件交互作用。通过上述数据库软件，RTEM10可访问驻留在文件服务器(未示出)上的数据36。代码和包含RTEM10和对象以及RTEM可访问的数据的数据的组织将结合图3描述如下。

本发明的解释实施例中RTEM10访问的第三个控制器是用户I/O(“UIO”)26，它较佳地是超级工具套件。UIO26被RTEM10用于中介传递应用和其“外部”输入和输出间的交互作用以使得构成应用的模型(或这些模型中引用的对象)不必做这工作。外部输入和输出这里想指的是包括屏蔽格式、数据输入设备和电子数据交换(“EDI”)处理等在内的计算机和有关网络的外部输入和输出。

根据本发明的解释实施例(其中，RTEM10可访问UIO26的功能)开发的应用和运行的设计和修改不需考虑，该应用的工作存储器数据从哪里检索以及送往哪里。例如，这类应用因而不需要包括把数据放在屏幕形式或报表文档或放入EDI处理的逻辑；也不需要和与应用交换数据的设备或处理过程交互作用。此外，根据本发明的数据结构最好不包含过程或宣称代码以使开发者能绕过这些规则。

例如，在本发明的实施例中，UIO26确定信息何时、何地在屏幕上刷新。它确定I/O是否应为图形模式或字符模式。它还确定使用何种人类语言。任何这类外部事件均由UIO26适当地处理。通过RTEM10使用UIO26对用户I/O的协调允许在特定的时刻作为条件的函数灵活地***各种不同的I/O特性，而不是死板地受应用的控制。

图2示出了根据本发明的应用接口和一组模型库或引擎示例的实施例。按本发明的术语，“模型”是一种软件对象，包含了为应用环境指定规则的数据，最好不包含代码。模型，换句话说，是一种数据分组，它列出了为与模型有关的应用的特定子集所发生的处理的列表。该处理包括了规则的说明，可包含事务或应用处理规则和机械规则。如下所述，当一个模型被运行时间事件管理器调用时将使自由待命的、可重复使用的、被登录的公共示例对象、包括“模型”、其它模型或工具被调用。例如，在后勤软件调配中，与读取对一个产品的所有保存情况有关的且确定该保存情况对产品可用性影响程度的模型可在其列表中包括：

1.在保存文件中将指针指向该产品的第一个记录；

2.如果当前记录是用于该产品；

3.读取当前记录；

4.累计对产品可用性的影响；

5.转到2。

如上面部分所述和下面要进一步描述的那样，模型可具有若干种变种，它能使用模型构成且由RTEM10运行的应用有最大的灵活性。

这里所用的术语“方法”是指用来完成特定目的所创建的过程代码块，类似于传统程序中的子例程。根据本发明，方法被用作为“自由待命的”、可重复使用的、被登录的、以及公共示例的。换句话说，每个方法独立位于库中，它的存在已在库中被登录。正如结合图6如下详述的那样，方法已被登录，使得它成为库的可访问的一部分，可由RTEM按照模型所指定在适当的时候被调用。根据本发明，诸如方法之类的对象可以包括父对象、预处理和后处理，将在下面进一步被详细定义。

图2示出了对于二个基本类型的模型的逻辑环境和它们之间的应用接口。模型包含两种基本类型：应用处理(或事务规则)模型和机械模型。这两种类型的不同在于它们所针对的抽象层次不同。应用处理或事务规则模型执行特定于应用的处理。例如，在后勤应用中，应用处理或事务规则模块可以规定为定单输入或接收货物的处理。与应用处理或事务规则模型有关的逻辑具体为只是一项应用作业，且一般在其它场合下是不可重复使用的。另一方面，机械模型一般在抽象的低层次上执行处理且在不同的应用场合下可重复使用。例如，在后勤调配中，在将存货从库房中位置A移动到位置B处时机械模型会计算可供使用的存货或记录。

这里所用的“库”是有组织的并可供RTEM10访问的一组对象。一个“引擎”就是以后连接的、可重复使用的模型和方法的库，特别地是指机械处理模型和一起工作的方法的集合。图2例子中，示出了与后勤应用有关的一组引擎(52-62，偶数)与该应用的接口50之间的关系。应急引擎52定义为对应急事件处理必须执行的一组机械处理模型。调度引擎54是调度所必须执行的一组机械处理模型。帐单引擎56以及活动引擎58、清单引擎60和其它引擎62分别是执行帐单功能等等必须完成的一组机械处理模型。

图2中仅显示了一个引擎的部分内容。具体说，帐单引擎56具有一机械模型70，该模型依次又包含了对方法1、72和方法2、74的引用，这两种方法都可调用过程代码块78的至少一个子集。机械模型70还包含了对另一机械模型76的引用，模型76本身又引用了二个方法、方法X(80)和方法(82)。结合图6将描述加于模型和方法形式上的约束。

图3所示是根据本发明的一个实施例的运行时间事件管理器、模型、方法和数据的组织。在该实施例中，内存储器包括四部分：任务存储器90、任务专用高速缓存100、服务器侧公共高速缓存器110及文件***120。任务存储器90包括了RTEM10的一部分对象代码92。另一部分中，任务存储器90包括了一个或多个变量表(“VTAB”)94，包含了预编译的数据排(“PCDB”)指针96和动态变量表98。根据本发明，如下述图4和5所示，每个模型包括数据且存储在RTEM10调用该模型时加载的预编译数据排中。格式化模型中的数据使得RTEM能根据该数据调用模型，数据最好预编译为使RTEM编程所用的语言能容易地理解其内容，且根据识别每个所引用对象的类型的扩展或其它数据从适当的位置检索出这类对象。任务专用高速缓存100包括一组模型102、模型库对象代码104以及客户机侧的专用数据文件高速缓存108。服务器侧公共高速缓冲110包括一组模型112、模型库对象代码114、以及公共数据文件高速缓存118。最后，文件***20包含了以预编译数据组122形式的模型122(由PCDB指针96所指向)、磁盘124上的对象代码及数据库表/文件126。

RTEM10(见图1所示)链接到任务的VTAB94的模型‘A’的存储器块(见参考号102)，它可位于客户机侧的专用高速缓存108内或位于服务器侧的公共数据文件高速缓存118内。模型‘A’中的数据是用PCDB指针的形式(见参考号96)，它是VTAB94的一个片段。因此，不管模型的大小和复杂性，只需几条机器指令即可有效地将它链接入VTAB94中。

例如，假设模型‘A’的步骤1(未图示)调用模型‘B’。设在任何特定时刻只有一个模型可被激活，如下所详述，RTEM10把模型‘A’“压入”(在堆栈机的意义上)且让它处于非活动链接。然后RTEM10活动地链接模型‘B’的PCDB指针(见参考号96)。

另外，设在模型‘B’的步骤1(未图示)在106处指令方法‘X’，(它是对象代码)被执行。在这一事件中，RTEM10把执行指针移到方法‘X’，方法‘X’或者在任务专用高速缓存100内或者在服务器侧的公共高速缓存110内。随后执行方法‘X’。

当完成模型‘B’的所有步骤时，RTEM10“弹出”模型‘B’，让模型‘A’活动链接并指针指向步骤2。

图4所示为模型模板140的示例，它示出了根据本发明的模型实施例的一种形式。模型模板140具有包含了模型(这里为示例一模板)唯一标识符(“ID”)的标头141，PCDB指针即指向它(见参考号96)。虽然未示出，但标头141后随着一组数据，主要形成了对象的列表，其后是非对象数据列表。一般来说，对象包括了方法、输入/输出指令、判决指令、工具和数据。模型模板140表中的每个元素可以包括方法的唯一ID，它用于从适当地库调用该方法，且它可以是一字符串(例32个字符)、提供对方法描述的唯一的语言名、以及在括号中的类型指示符(例(方法)、(输入)、(判决)、(数据)等等)。

每个元素根据模型功能而被调用的次序列出。例如，由模板140所规定的模型中，方法-1144和方法-2146首先被依次运行。当方法-3146完成后，运行输入-1148，接着是判决-1150、方法-n和工具-1154。过程按此顺序继续进行直到检测到EOL(列表结束)156。模型模块140中列出的数据元素如数据-1158、数据-2160、数据-3162和数据-4164可供模型中列出的方法或其它对象使用。

图4A示出另一个模型的模板1000A，比图4所示更详细。这里，模型标头信息1001包括了几个描述符：lvmodel$ 1002识别模型名字；lvmode_obj$ 1003识别模型唯一对象ID；sydescriphn$ 1004提供对模型的描述。模板1000A还包括各种控制信息1005：lvsequence$ 1006提供要被执行的父对象列表；lvexitobject$ 1007识别在退出模型前要执行的对象(当正要退出模型时，将用其后处理执行该对象)；lvtabarder$ 1008提供了以处理顺序从一个字段跳到另一个字段的字段号列表；lrfirstinput 1008提供了当完成最后输入时开始处理的字段号；lvlastinput 1010提供了把处置设回到第一输入前要处理的最后字段号；以及lvdata_list$ 1011提供了该模型上所用的所有数据变量列表。

图4B进一步示出了表明模型详细处理信息的数据结构第一部分1000B的定义。具体说，它提供了定义该模型的多个对象的识别：{objectid}.name$1012提供了对该模型的对象引用的名字；{objectid}.descriptn$ 1013提供了该对象的描述；{objectid}.condition$ 1014提出了RTEM10执行该对象必须满足的条件；{objectid}.objecttype1015通知RTEM10关于本对象的类型(1：方法；2：工具使用；或3：模型；{objectid}.module$ 1016识别用于工具使用、方法或模型的模块；{objectid}.repository 1017识别用于工具使用或方法的贮存库；{objectid}.method$ 1018识别要执行的方法；{objectid}.toolusage$ 1019识别要执行的工具使用；{objectid}.model$ 1020识别要执行的模型；{objectid}.performflg1021指令RTEM10如何访问这个对象(0指示该对象被调用，在由modelvars中指定的模型数据中传递，而1指示该对象被执行，在所有模型数据中传递)；{objectid}.modelvars$ 1021提供了被传递入方法、工具使用或模型中的模型变量列表；而{objectid}.obj_var$ 1023提出了从模型变量(在modelvars中指定的)中要被增加的对象变量的列表。

图4C进一步示出了模型数据结构的第二部分定义(续图4B)，表明了模型的附加详细处理信息。特别地，它包括了：{objectid}.{modelvariable}_{type ofvariable}.usage$ 1024，它识别这一变量在方法、工具使用或模型中被传递的用途、Model_variable规定了{objectid}.modelvar $中规定的数据变量；{type ofvariable}标识下列各项：C表示字符变量；N表示数值变量；用途：I表示仅表示传入变量；B表示传入并往回传出的变量；F表示作为规定的默认值传入并往回传出的变量。

{objectid}.{model_variable}_{type of varable}1025标识了传递到方法、工具使用或模型中的默认值。{objectid}.action$ 1026识别对这一对象所附的行动(1：预处理对象；2：父对象；或3：后处理对象)。{objectid}.parentname$ 1027识别父对象名字，若对象是预处理或后处理的话。{objectid}.parent_obj$ 1028规定了父对象的对象ID，若为预处理对象或后处理对象的话；{objectid}.designname$1029识别模型设计对象的类型；{objectid}.mandatory 1030表示如果对象是一个输入，则向输入指示输入项是否是强制性的(0，不是强制性的；1，是强制性的)；{objectid}.preprocs$ 1031识别对该父对象的预处理对象列表；而{objectid}.postprocs$ 1032识别对该父对象的后处理列表。

图5示出了根据本发明的用于实现应用菜单的模型(具体为范例模型)的一个具体例子170。菜单示例的标头171后跟着一组12个对象，包括8个方法，一个输入和一个退出。该模型中的一个对象，selectval，是一个“父”对象。在父对象前的对象(也用正斜杠(/)表示)叫做预处理；对父对象后的对象(由反斜杠(\)表示)叫做后处理。

当调用模型时，clr_select方法172被运行；它保存将被选的菜单项值的变量清零。menu_active模型173设置(在与后勤有关的应用场合下当前日期、操作员、终端、公司、用于跟踪菜单活动的***，此后menudflt174方法设置默认值，例如未作选择就显示初始菜单。方法menu-displ 175加载并显示菜单。方法save_vals176保存老的值，此后selectVal177读取并存储由用户选择的值。模型menuselect178确认由用户所作的菜单选择。模型中下一个被调用的对象是menusecure 179，它验证菜单的安全性。如果操作员用菜单输入了非法的选择或选择了另一个菜单显示，处理在方法cls_select 172处重复。这可由方法menusecure179向RTEM10传递一特殊请求(图8中参考号324)来完成。如果作了合法的选择(合法作业)，方法随后运行退出(对象)181，它设定控制变量以告诉RTEM10它已完成执行菜单模型(所有退出181的后处理将在RTEM10实际离开模型前被处理)。

如果操作员选择退出应用环境，他或她可在菜单选择输入处(Select Val 177)按动适当的预先指定键(本例中为F4键)。这就向退出181发送处理，它设定控制变量以告诉RTEMl0它已完成对菜单模型的处理(所有退出181的后处理将在RTEM10实际离开模型前被处理)。方法menuf4 182根据操作员按动的菜单选择输入中的F4键(select Val 177)有条件地出现。Menuf4 182检查***配置标记以了解菜单模型如果未在顶层时是否应返回到菜单显示的上一层，如果在顶层时退出菜单模型，或如果***配置标记设置为不用向上移动到菜单显示的前一层即可立即退出菜单模型则退出菜单模型。如果menuf4 182方法决定在菜单显示中上移一层，在退出181中设定的控制变量(用于告诉RTEM10它已完成执行菜单模型)被复位且选择的显示菜单设定为先前的菜单。处理然后在方法cls_ select 172处继续。

与模型菜单示例170有关的数据变量包括：动作184，存储菜单选择；空格_5 185，存储5个空格；cmdcompany 186，存储公司名字；公司187，存储公司代码；menu_desc 188，存储菜单说明；oldmenudsp 189，存储先前显示的菜单的标识；pagedisply 190，存储显示页面；selectval 191，存储菜单选择；短_名192，存储公司的简短名字；状态193，存储状态值；子菜单194；存储***子菜单；终端195，标识计算机终端；tilde 196；tilde 2 197；以及时间198，存储特定的时间。

图5A示出了基于图5的范例模型170的派生模型170A。派生模型170A几乎与范例模型170一样。然而，它包括了范例模型170中不存在的处理，具体说就是后处理，track_al 179A，它在验证了菜单安全性后将菜单交互作用写入一个日志文件中。派生模型170A的标头171A指示了该模型是派生的并用名字来标识。此外，标头列出了“应用”派生模型170A并被加载以供潜在的调用所必要的条件(本例中只有一个条件)。在这种情况下，track_al派生模型170A的必要条件是公司代码要等于A1。模型运行时间变化表(它也可称为是运行时间变化映射)与DBAC 24、30运行时间变化表结构相同，下面将结合弹性数据库予以讨论。

一个变化加于模型的表或映射如下所示：

变化	条件	评价代码
			track_al	当公司＝“A1”	1

相应的运行时间表示表如下：

(COMPANY$＝“A1”)其中当读取基本记录后在内存中的数据为：

COMPANY$＝“A1”使用运行时间表示表，运行时间评价代码被生成，本例中，这里当

(COMPANY$＝“A1”)运行时间评价代码将为“1”。这个运行时间评价代码与显示能确定哪些变化是活动的表相比较该活动变化就是与运行时间评价代码中相同位置上具有“1”的那些变化。

运行时间评估代码

变化

变化表

活动？

1

track_al

1

yes

变化表对应于模型运行时间信息。这变化表伴随文件存储了激活所有派生模型的所有条件的表。对于上例，变化表如下：

LVRTEM＞VAR_CHECK$＝“(COMPANY$＝“A1”)”

LVRTEM.VAR_TABLE$＝“1”

LVRYEM.VARIATION$＝“track_al”

这里要说明一下上述实施例中的命名规则：LV(直接用于开头)指的是局部变量类，其它前缀用作其它变量类，例如SY(***变量)；DD(数据字典)；DB(数据库)；LL(局部标记)；RT(例程)。

一个派生模型170A的详细的说明样子如图5B所示，表示当公司是“A1”时派生模型被加载且在每个菜单选择后它添加一个示例工具使用对象以将目期操作符、时间和SELECTVAL写入日志文件。在判决调用退出_菜单前该对象被执行。首先，派生模型170A包含了加入到范例模型的对象名。然后它指明把该对象***到该模型处理序列中那里。具体说，对象(“track_A1”)作为后处理连接到父对象“selectval”上(图5中参考号177及图5A中参考号177A)，并被***在退出_菜单处(图5中参考号180和图5A中参考号180A)。有关示例对象(“track_al”处理详述如下。首先，提供一说明(DESCRIPTN $)，它被设置为串“写入到日志文件”。对象类型设置的值指示为工具使用(本示例中，该值为2)。然后，规定父对象32字符ID(PARENTOBJ$)后随父对象名(PARENTNAME$)(如上所述为“selectval”)。进一步细节还包括：对象设计名(DESGNNAME$)是“工具使用”，及模块(MODULE$)是“模块”。详细的信息还包括对象驻留的存储库标识(REPOSITORY$)；这是一个数据库。另外，由于track-al向日志文件写入，由对象(TOOLUSAGE$)调用的方法被指定为“写”。

此外，派生模型包括了模型变量(MODEL-VARS $)列表，模型变量包括“Logfile”(在标识为“模块”的模块内的日志文件)、“写”(它表示操作)、其次派生模型还包括了当对对象(即，操作符(ZOPRINFO(1.6)))的必要条件满足时要写入的变量的列表、时间(TIME $)和菜单选择(SELECTVAL$)。派生模型还包括若干对象变量(OBJ_VARS)，它们是逻辑文件名、(SYLFN$)、请求的动作(SYREQUEST$)、操作符(OPERATOR$)、时间(TIME$)以及菜单选择(SELECTVAL$)。派生模型带有上述参数而调用DBAC以进行写操作。

图6是一个流程图，示出了对于包括模型的对象的登录过程的实施例。登录过程保证在应用软件开发项目过程中所有的对象遵守某些约束，这些约束允许它们由RTEM10调用，也允许它们合适的执行。登录过程200也方便了对象的测试，且最终方便了依赖于该登录的对象的应用软件的测试。被登录的对象可以由多于一个实用程序引用。登录过程200从步骤202开始，具有开发者提供的一列对象的数据。该数据包括一个唯一的对象识别码(“ID”)，如一个32字符的对象登录ID(未在图4的模型框中示出)。数据还包括一自然语言(如英语)名字，如上面与图4模型框140有关的上述“Example-template”。描述还包括一个唯一的语言名字(在图4的实例模型框140的中间列叙述)和图5中Menu_example模型，以及一类指示器，它指明该对象是模型、方法、工具、数据库元素、字段、元件或其他对象。对象中的数据也可包括一个开发项目控制单元(Development ProjectControl UNit-“DPCU”)识别码(ID)，对象的权主，替代或重新定义该对象的ID和自然语言名字，和一个状态标志，指明该对象是储存室(Repository)或者是库(Library)。

一个DPCU代表一个开发工作的逻辑块，可以是应用软件开发项目的任一个子集。按照本发明的应用软件开发方法的一个实施例，一个发明对象登录具有一个DPCU，在该登录成为可用以前给它赋值。DPCU的赋值使对象与一个特定的开发者或开发组相联系，保证该开发对象的完整性和质量。DPCU数据文件可以包含：

·该对象的权主或开发者表；

·该DPCU负责的开发对象表；

·该DPCU包括的工作命令表；

·对该对象的一个简短的工作描述；

·对该对象的一个长的工作描述；

·该对象的登录日期；

·该对象的开始日期；

·该对象的测试组(Suit)表；和

·与该对象结合的一个希望得到的波图(Wave)。

测试组本质上是一列DPCU，与其相联系的对象包括在给定的“测试会话”(“Test session”-将在后面叙述)中。这就允许多个应用程序开发项目(因而它们包含的对象)能被同时测试，即使它们涉及同样的软件处理。在本发明的一个实施例中，开发测试套件文件包括：

·一列DPCU，因而也隐含一列将包括在该测试套件中的对象；

·一列可能有的其他测试套件，它们与给定的测试套件在测试时相联合；

·一列登录的测试器，例如一个6字符的用户/相关码；

·一列已知的测试目录(在下面叙述)；和

·对该测试套件负责质量保证个人的识别符。

测试目录是持有测试会话输出的位置。一个测试会话实时被调用，且涉及任何给定的测试套件。由测试会话所更新的任何文件将被翻录到测试目录并更新在它内部而不在该文件的产品版本之中的记录/表。此过程结合图7叙述。在多个测试目录能应用到单个测试组的情况，各个测试人员可以独立于其他测试同一组的人员作出操作选择。在本发明的实施例的一个测试目录包括：

·一个测试目录ID；

·一个测试套件；和

·一个允许的测试员的清单。

在给定时间，如果只有一个测试目录对应于一个给定的测试会话，可以激活任意数量的测试目录。如下面结合图7解释，一个测试目录捕捉所有写操作并更新到一个数据库。即使在原始记录写在产品环境而不是测试环境，且通过规定测试会话是一个进程允许测试在产品环境中进行的情况下上述也是正确的。

数据库访问控制(图1的DBAC 24，30)将自动拷贝在测试会话中产品文件记录，只要其格式或元素定义不变。DBAC24，30总是首先阅图读测试目录，但是否则就读取从数据库的产品部分所要求的记录。使用测试目录防止在测试会话过程中更换产品数据。如果在测验会话过程中读出的产品文件记录改变其格式或元素定义，则读出或提取的任何产品记录只有在正常输出时被写入测试目录中去。

在实时运行过程中，开发应用软件的操作员在面对菜单时可能调用一个测试会话。从与该操作员相关的列表中选取测试套件。然后从与附属于该测试套件以及此操作员的列表中选出所希望的测试目录。在测试会话中，跟随着有各种数据，包括下列数据但不限于这些：

·已经运行的作业；

·已经在访问的数据库字段；

·操作员的敲击键；

·遇到的错误；

·由操作员输入的测试说明；和

·由操作员记录的测试记录。

测试目录在任何时刻能被清除，即擦掉或复位，但是为了保存记录的目的会话的结果最好保存在永久储存器中。

当所有对象被测试以后，它们能做成“产品波图(Production wave)”的部分，或在当地应用环境中简单地可以成为合法的使用。

当一个测试套件在测试以后被通过，则与此相关的所有对象被转到“产品状态(production status)”。在某些应用范围，适合于那些范围的另外的准则可以在将产品状态分派给与测试套件有关的对象以前强制加入。

参照图6，在步骤204开发者开始了按步骤206-216的过程构筑对象，建立具有合适格式的模型，它的例子结合图4和图5被说明。当对象被构筑，它可能成为开发登录的部分。在开发登录中的一个对象可称为“开发对象(DevelopmentObject)’以区别于在产品的储存室或库中登录的“产品对象(Product Object)’。

登录过程200的本质可以取决被登的对象的类型。模型(规范的和变种的)按照与方法及工具有些不同的考虑进行登录。

例如，模型(规范的和变种的)可以借助模型设计工具208建立和修改。如果对已登录的模型作了修改，改变将做成变种模型的形式。对应于一个给定的规范模型可以建立任意数量的变种模型。

对于模型设计工具208的一个实施例的逻辑，在图6A中示出一个流程图。模型设计工具208首先允许应用软件开发者在步骤2081从现有模型表中选择一个模型，或者建立一个新模型，后者被加到模型表中。如果选择一个现有的规范模型，此模型的改变作为该规范模型的变种模型而被储存。模型设计工具208然后就开始一个递归的循环，加上所有与所选模型相关的规则。此循环的第一步在步骤2082允许根据类型选择一个对象，作为被选模型的部分。对象可以从被登录的那些对象中选择，即那些对象必须如上所述由RTEM10处理过的。在步骤2083，应用软件开发者将该对象以及与所选对象相关的参数加到模型中去。记住，因为模型不包含程序代码，对象不是真正出现在模型中，而是模型包括对所选对象的参照，除了加一个对象到模型中以外，应用软件开发者可以修改或删除与该模型相关的对象。作为说明，应用软件开发者可以选择：

·数据定义-定义此模型中使用的数据并将此数据定义指向的元素输入到数据字典12中(即一个字段，指向哪个文件或哪个数据元素)；

·输入-确定用户输入，对用户输入储存的数据，对不同结果码采取的特殊操作(若有的话)；

·按键-确定按键的定义，显示的标记，对不同可能的结果码采取的特殊操作(若有的话)；

·方法-选择调用的方法和传递的参数(若有的话)；对不同可能的结果码输入特殊的操作(若有的话)；

·工具使用-选择调用的工具使用和传递的参数；对不同可能的结果码输入特殊的操作(若有的话)；

·模型-选择调用的模型及传递的参数(若有的话)；对不同可能的结果码输入特殊的操作(若有的话)；

·决定-输入此决定步骤的条件(若有的话)和完成的特殊操作(若有的话)；

·退出

·滚屏触发-输入使用的可视滚屏定义(滚屏是在数据输入自动滚动屏幕显示的功能，特别是涉及在相继的记录中重复的数据输入)；对不同的可能结果码输入特殊的操作(若有的话)；

·滚屏可视定义-定义滚动多少可视行；

·方框显示-输入方框的标题(若有的话)；

·文字显示-输入需显示的文字。

至今，步骤208处理的结果只是简单地做了一个与模型相关的对象的表。但在这里对象在表中的次序是简单地按照对象加到模型中的次序排列。下面在步骤2084，应用软件开发者可以在模型中放一个可视的对象。例如，如果设计对象选择的一个可得到的可视的组件(如一个屏幕按键)和应用软件开发者希望加一个屏幕按键或其他对象到模型中去，则设计该模型的应用软件开发者被提示将此对象以可视的形式“放置”(即指出显示按键的地方，或按键方框的大小及位置)。对象从一组已有的选项中选取，这些选项对本领域的专业人员是熟知的。

然后，应用软件开发者在步骤2085可以在模型中重新将对象排序成这样的序列，(RTEM10即是按此次序调用的)按此顺序执行就实现了与设计的模型相关的希望的过程。如果上面选择的对象是一个处理对象(即它调用一个方法)，设计此模型的应用软件开发者能将此对象移到相对于其他处理对象的另外位置。默认的是把所有新的处理对象加到父序列(Parent Sequence)的末端。如果正在设计该模型的应用软件开发者希望使(例如)一个方法成为对另一个对象的前处理，这在步骤2085中完成。因此，如果一个对象是一个方法，且是对一个特殊父对象的前处理或后处理，则在步骤2085就强迫加上适当的相对次序。步骤2085的处理结果是一个控制表。

当流程图中A部分的一个特殊模型设计过程已经对特殊模型完成，则模型设计工具208在流程图B部分按照已知的方法RTEM10调用一个模型，它建立预编译数据总库(Pre-compiled data bank)指针(见图3参照号96)，允许RTEM10访问实际模型。RTEM10在调用模型时将数据加载到预编译数据总库96，使得RTEM10在调用一个模型时能够完成在模型设计过程中所规定的规则。若被维护的模型是一个变种模型，只有变种模型信息被储存，并对于附在更新成变种模型的规范模型后的变种模型表作出修改。(即，说明存在一个变种模型，并在什么条件下调用它)。在模型设计工具208的每一个步骤的功能能根据已知的方法完成。

回到图6，如果在步骤210方法和工具被登录，对该方法或工具的源程序码的编辑和维护在步骤212进行。接着在步骤214码(无论是源程序码或目标程序码)被扫描，找出非正常操作。在本发明的实施例中，扫描非正常操作是读程序码，测试关键词的出现，后者是写此程序码的语言中非正常操作的名字。一般，当遇到执行控制转移或I/O操作(即一个调用或一个写语句等)语言代码时，这样的语言代码被识别为非正常，必须作出修改。例如在商业BASIC(Bussiness BASIC)中非正常操作包括：·CALL(调用)                    ·EXTRACT(提取)·PERFORM(完成)                 ·PRINT(打印)·WRITE(写)                     ·RUN(运行)·READ(读)                      ·INPUT(输入)·FIND(寻找)                    ·OBTAIN(获得)·CLOSE(关闭)                   ·OPEN(打开)

在步骤216，登录过程还识别在扫描过程引入的参数。任何赋值的变量将从方法中返回。所有其他变量则传递到方法中。

所有对象然后经过在步骤218开始的测试对象过程，其中确定对象的类型。对模型和变种(220)首先在步骤222建立测试床(Test Bed)。测试床允许模型使用真实的或“活动”的数据进行测试，但不影响该数据的真实文件。此外所有数据若需要时自动传送到测试床。

图7A示出测试床方法240的第一个流程图。在一个正在进行开发和测试的应用软件，或特别地一个作为应用软件的一部分正在建立或修改的模型，需要一个输入或输出(“I/O”)操作，就调用测试床方法240。在步骤242，测试床方法240确定请求是否为输入(读)，输出(写)或删除(移去)。

如果请求是读操作请求，则在步骤244中测试床方法确定，需要读入的数据是否在测试床中。若是，方法在步骤250提取所需的数据。此时，方法240完成若干步骤维持一个字段的并发性(concurrence)，该字段累计或总和多个记录的细目，能称之为“总计字段”(“Summary Field”)。这些步骤，252-258(偶数编号)，在方法240中从多于一个分支调用，将在下面详述。在步骤260过程回到应用软件。

若在步骤24A通过读操作寻找的数据确定不在测试床中，则测试床方法在步骤R01确定，需读入的数据是否在测试床删除文件(简单地称为“TestBedDeletion”)测试床删除文件储存在测试会话过程中由于下列原由已被删除的记录。一个“活动”数据库(包含真实的而非测试数据，那个数据库简称“活动”的)在一个测试会话中不变更。此外，只要记录不在测试床中，就从活动数据库中索取。因而需要一个机构，来知道在测试会话期间被删除的记录，防止在测试会话过程中被删除的记录重新出现在测试床中，防止其出现在活动的数据库中。那样的机构由测试床删除文件提供，它储存在测试会话期间被删除的记录。如果数据出现在测试床删除文件中，则认为所需的数据不存在。没有数据得到，在步骤254上处理过程回到应用软件。

如果在步骤R01，确定数据不在测试床删除文件中，则测试床方法在步骤R02确定，需读的文件是父(parent)文件、子(child)文件或独立(Stand alone)文件。一个父文件有相关联系信息在一个或多个子文件中。在后勤范围中一个例子是一个订货(“Order”)文件。订货的头部数据可以放在父文件中，而详细的产品行，注释行和专门的费用行可以放在与该父文件相关的一个或多个订货细节子文件中。父数据可以不需要子数据而存在，但子数据不能没有父数据而存在。独立文件是缺乏父子数据关系的文件。若在步骤R01上确定，此文件是父文件，处理过程进到R05。

在步骤R05父数据从“活动”文件中被取出，在R06步骤被写入并锁定在测试床中。每个子文件有它的与父数据相关的数据，在步骤R07从适当的“活动”文件取出，并写入适当的测试床文件。一旦此过程完成，父数据在步骤R08在测试床上打开，在步骤250需要的数据从测试床取出。在步骤252-258中维护总计字段数据的并发性(如下所讨论)，此后处理过程在步骤254回到应用软件。

如果在步骤R02文件被确定是独立的，则在步骤246所需的数据从适当的“活动”数据库取出。当数据取出时，所有总计字段(在下面叙述)在步骤247被清除。于是，在步骤248将取出的数据写入测试床来更新测试床。然后，在步骤250数据从测试床中取出，经过步骤252-258(偶数编号)在总计字段上维护活动数据与测试床数据之间的并发性以后，处理过程在步骤254回到应用软件。

如果在步骤R02确定，文件是子文件，则在步骤R03作出确定，在测试床是否存在父数据。若是，数据在步骤250从测试床取出。并且在步骤254-258(偶数编号)(如下面叙述)维护总计字段的数据并发性，在步骤254处理过程回到应用软件。若在步骤R03确定对此子文件的父数据不在测试床中，则在步骤R04作出确定是否父数据在测试床删除文件中。若在其中，则该数据认为不存在，在步骤254处理过程回到应用软件。否则，在步骤R05此父数据从“活动”文件中取出，且在步骤R06写入并锁定在测试床中。每个子文件有其与父数据相关的数据，而父数据在步骤R07从适当的“活动”文件取出并写入适当的测试床文件中。一旦此过程完成，在步骤R08父数据在测试床中打开，所需数据在步骤250从测试床中取出。处理过程在步骤254回到应用软件。

图7B示出测试床方法240的第二张流程图。如果请求是写数据，如步骤242确定的那样，则在步骤262与测试床中总计字段相关的值减去在活动数据库中总计字段值。被写入测试床数据库的数据被更新。接着在步骤R09，测试床删除数据库中的任意数据被清除。在步骤266，处理过程回到应用软件。

在步骤242，若I/O请求类型被确定是“清除”，在步骤-R10，数据更新到测试床删除文件。在步骤R11数据从测试床数据库中清除。最终，在步骤266处理过程返回到应用软件。

再回到图7A，步骤252-258(偶数编号)旨在按本发明维护在活动数据和测试床之间总计变量数据的并发性。在本发明这方面的一个实施例中，此变量是“总计字段”，它是个数值字段，保存多个包含细节数据记录的和。在涉及后勤的一个例子中，总计字段是“产品主导”(“Prodnct Master”)的一个记录，它储存给定产品的总量，即存货，也即“现货”(“On-Hand”)。现货的细目储存在与产品批量(Lot)有关的记录中，可能有成千上万个批量应用于一个产品记录。为了很块地确定在给定时刻现货的总量，数据设计成在产品主导记录中储存总的现货量。每当涉及一个产品批量的细目记录改变时，涉及此改变的差值加到产品主导记录的总计字段中。

当运行测试床时，在活动数据库中的细目记录可能改变，这就导致在活动数据库和测试床数据库中的总计字段失去平衡，或缺乏并发性。不正确地反映了不同的值。除非所有的细目记录拷贝到测试床中，否则就会发生此问题。但是这可能需要拷贝细目记录成千上万次来维护总计字段的完整性和并发性，这可能是极其无效率和耗时的。

为针对在活动数据库和测试床数据库的总计字节之间缺乏并发性的问题，测试床将在测试会话过程中发生的所有细目记录的差的总数记录在总计字段中。活动数据库的总计字段中的值加到测试床总计字段的此数值中。测试床仅储存在测试会话中作出的改变。若包含总计字段的记录被写到测试床中，在测试会话中对总计字段没有发生变化，则在测试床的总计字段值是0，而与对应活动数据库总计字段的值无关。

当测试会话请求读包括一个或多个总计字段的记录，这些总计字段将从活动数据库中取出。这些从活动数据库取出的值存入存储器，为在写请求时使用。在这样的请求下，将从测试床数据库中取出同样的记录，且测试床的总计字段的值加到活动数据库的相应总计字段中。这次相加产生了对测试会话的当前值，它替代现有的存储值。因此返回到应用软件的总计字段每次是测试床中总计字段和在活动数据库中相应总计字段之和。

当测试会话请求写一个包含总计字段的记录，在请求时刻的当前值从(以前是当前值)活动数据库的值减去，后者在读请求期间已被储存在存储器中。减法产生在测试会话中导致的差值。当包含总计字段的一个记录从活动数据库中取出，且首次更新到测试库中，总计字段设成0。所有未来的对总计字段的改变将只储存测试会话中作出的改变。

回到图7A，在上述达到步骤250的每种情况，完成与步骤252-258(偶数编号)的处理过程。在步骤252，确定是否存在总计字段。若不存在，处理过程在步骤260回到应用软件。若存在总计字段，则在步骤254从活动数据库中取出之。活动总计字段值在步骤256存入存储器，且活动总计字段值在步骤258被加到测试库总计字段值上。处理过程最终在步骤260回到应用软件。

回到图6的登录处理200，当在步骤222建立测试床，模型(或变种模型)在步骤224被测试。若在步骤224的模型测试过程中模型未能通过检验，则过程重复；开发者必须使用如模型设计工具208来修改模型，而且对象必须重新测试(步骤218到224)。

若在步骤218作出判断，当前在进行登录过程的对象是一个方法或工具(步骤226)，则在步骤228设置此方法或工具的参数。一旦参数被设定，就测试方法或工具。除RTEM10内部的子程序以外(RTEM10在下面叙述)，没有程序代码块(例如没有方法或工具)能直接调出任何另一个程序代码块。

此规则使得每个程序代码块能独立测试，即使程序代码在制作的期间也如此。

本发明的基本原则的破坏在登录过程中即被捕捉到，并通过实例说明予以预防。某些错误的方法在登录过程就被检测到并标志出来，一些例子包括：一个方法中包含修改受保护变量的程序代码；调用另一个方法的方法；一个采取离开取RTEM10的控制的方法；和一个企图交叉域(cross domain)(如数据库)表示和交叉处理域的方法。

若在进行登录过程的方法或工具不能通过测试过程，则控制回到步骤212，应用软件的开发者能编辑修改方法或工具的源代码纠正导致测试失败的缺陷，登录过程从此步骤重复开始。

如果对象在步骤224(对模型)或在步骤230(对方法或工具)通过测试，则该对象被做成“公共的”(“Public”)，它在运行一个应用软件过程中可以访问RTEM10。为将一个对象做成公共的，登录过程建立了链接意见，如“何处使用”(“where-used”)，“何时建立”(“when-created”)，“如何使用”(“how-used”)。“何时删除”(“when deleted”)。

图8示出一流程图300，叙述按照本发明一个RTEM10的实施例的操作。RTEM10可以用第三代编程语言(“3GL”)来实现，如商业BASIC，C，C⁺⁺或其他3GL语言。

RTEM10监视应用程序的运行，后者由一组根据如图6说明的登录过程登录的模型所规定。通过监视，RTEM10对应用软件加载一个初始模型定义初始操作，包括调用方法、工具和其他模型。当在每个模型中的对象表被读出，该对象定义的条件被检验判断其是否满足，如果满足，该对象被调用。已经知道，如上有关登录过程的说明，一个登录的对象不能够调用另外的对象，与当前处理的对象有关的执行完成以后控制总是返回到RTEM10。在每个对象处理之间，RTEM10能校验专门的作用或外部状态，并更新状态，使那些组成应用软件的模型能按照它们涉及的状态自由地被访问。

现参照流程图300，在步骤302第一个模型被加载到存储器。参照图6A，6B，6C中提供的一个用户界面应用菜单的模型的例子，模型菜单数据在步骤302集中存入当地存储器(即图1中的任务存储器90)。此过程可能涉及使用PCDB指针96(图3)读出模型。这也涉及将模型存储块的预编译数据总库指针96链接到任务存储器90的VTAB94。

在步骤310，RTEM10检查与刚加载的模型相关的变种模型的存在。与检验变种模型存在与否相关的过程310在图9中说明。本质上，RTEM10将检验相对于已加载模型的登录的所有变种模块的条件，确定在校验时，是否有任何模块当前在应用，给出数据的状态；若有一个变种模块当前在应用，它将被加载(通过写一个指向它的指针到PCDB96中)带着当前在存储器中的模型数据被合并。

图9示出对此过程的一些流程图400。当在流程图300中达到步骤310时，RTEM在步骤402取出第一个(或取决于迭代，取下一个)与该模型的变种模型有关的条件，该模型已在图8的步骤302上被加载。

条件是基于模型中的数据值。例如：

条件1：client$＝“ACME”and product$＝“BEACH-BALL”

条件2：product$＝“NET”

当在每个条件存在时，有一张表将条件与被调出的变种模型相联系。例如

Variant Model’A’and Variant Model‘B”are actived when client$＝“ACME”andproduct$＝“BEACH-BALL”product$＝“BEACH-BALL”

Variant Model’C”is activated when product$＝“NET”RTEM10将设被校验的“当前条件”为条件1，然后为条件2等等，直至针对该模型中数据的当前值校验完所有的条件。

在步骤404，取出的条件针对当前的数据值(如图1所示，存在任务存储器的动态变量表98中)进行校验，如

if checking condition 1 and

    client$＝“ACME”and prodnct$＝“BEACH-BALL”

    then Models‘A’and‘B’是活动的；

if client$ is not“ACM”或

if prodnct$ is not“BEACH BALL”

    then Models‘A’and‘B’are not active。

若在步骤404被校验的取出的条件满足，或“通过”(步骤406)，则当取出条件被满足时调出的所有变种模型在步骤404被加到由RTEM10处理并存在任务存储器10的活动变种模型表中。例如：

active variant Models＝‘A’and‘B’

若取出的条件在步骤404校验不通过，或当对应当前条件的所有变形模型已在步骤410加到表中，则RTEM10在步骤408检查对该当前模型是否还有另外条件必须校验。若有，RTEM10回到步骤402，取出表中的下一个条件。若没有，则在步骤412将所有在步骤410加到表中的变种模型按照上述加载方法予以加载。任何当前加载的变种模型，若不出现在流程图400过程中建立的活动变种模型表中就卸载，所以对当前规范模型的变种模型仅由活动变种模型组成。变种模型的加载和卸载过程更详细地在图10的流程图500上叙述。一旦建立了活动变种模型表(在流程图400的过程中)，它与在步骤502当前加载的变种模型表进行比较。此比较确定哪些变种模型需要激活(加载)，哪些变种模型需要使其不激活(卸载)。

在步骤504中完成检查，确定是否有任何当前加载的变种模型不在活动变种模型表中。如果没有当前加载的变种模型不在活动变种模型表中，则不需要使其不激活的工作，控制转到步骤514，如下所述。但是如果有一个或多个当前加载变种模型不在活动变种模型表中，则在步骤506，不激活的当前变种模型设成那些没有在活动变种模型表中的当前加载变种模型表中的下一个。

在步骤508，对变成不激活的当前变种模型的变种模型信息从控制变量组中去除。RTEM10使用一些那样的控制信息使能识别需处理哪些对象并以适当的顺序处理它们。控制变量主要是对象表。若在不激活的当前变形模型表中的任何对象在任何控制变量表中被识别，那些表被修改以除去对那些对象的标识。例如，若对象识别符是

’M020016TOR1--

0000000000400041(32个字符或其他合适的码)对应于不激活的当前变形模型，此识别符出现在父对象序列表(即控制变量)中，它将从此表中除去。

接着，所有变种模型的详细数据将在步骤510从实时事件管理器(Run TimeEvent manager)10的当地存储器(即任务存储器90)中除去。例如，若对于规范模型的一个变种模型包含一个不在该规范模型中的方法，有关此方法的信息(如模块、资源、方法名等)在变种模型数据中；若该变种模型未被激活，则有关此方法的信息借助于从任务存储器90取消变种模型PCDB指针(参照号96)的链接从存储器中除去。

在步骤512作出检验，确定是否还有更多的变形模型需要使其不激活。若有，RTEM10将控制返回到步骤506；否则，或者在步骤504确定没有变种模型需要使不激活，在步骤514再检查是否有任何活动的变种模型未在当前加载的变种模型表中。若结果是肯定的，则在步骤516需加载的当前变种模型设成需加载的变种模型表中下一个变种模型。

在步骤518作出一个测试，检查该当前变种模型是否已经加载。若该当前变种模型已经加载，则不需要做任何事。但是，若当前变种模型尚未加载，则在步骤522它将带着当前的控制数据被加载。RTEM10使用控制变量识别处理哪些对象和以什么样的顺序处理它们。任何由变种模型引入的新的对象需要与这些控制变量合并。合并发生在步骤524。为了使RTEM10能确定何时激活由变种模型引入的新的方法，将该新的方法的对象识别符加到控制变量中。若此方法是一个前处理，它被加到该对象的前处理表，此对象是该方法的父亲(例如，在图6A-6C的标记{parent object ID}.preprocs$)。一旦与变种模型相关的任何新对象已经与控制变量相合并，或者若在步骤518已经确定该当前变种模型已经加载，则RTEM10测试，是否有更多的活动变种模型需要处理。若是，RTEM10回到步骤516取出下一个变种模型。否则，或者若在步骤514已经确定不存在活动的变种模型，则在步骤526逻辑工作已完成，控制或返回到图8的步骤310，或返回到步骤322(在下面编址)，取决于逻辑转移最初发生的情况。

假设控制返回到图8顶层RTEM10循环的步骤310检查变种模型，识别当前对象的变量在步骤312设置到该模型的第一个对象。如上所述，对象可以是另一个模型，一个方法，一个工具或其他对象。RETM10从模型中的父对象表中取出第一个父对象。使用图6A-6C的Model_menu：

first_object＝lvsequence$(1，32)

               -First Parent Object(第一个父对象)RTEM10还检查对象上的前处理；例如：

pre_processes＝{first_object}.preprocs$

                -List of pre_process for First parent object(第一个父对象的前处理表)若存在任何前处理，第一个对象将设成前处理表中的第一个对象，否则它将仍然作为第一个父对象。例如：

first_object＝pro_processes(1，32)

               -First Pre_Process Object(第一个前处理对象)

Current_Object＝first_object

                 -setting the current object to the first object(将当前对象设成第一个对象)

在步骤314，任何相应当前对象的条件针对于当前数据检测，以确定对象是否可以执行。若无条件与当前对象有关，则RTEM10认为满足条件或通过。例如，使用图6A-C的menu_model例子：

evaluate{current_object}.condition$

     -check conditionof object(检查对象的状态)

若在步骤314对于当前对象的条件满足，则在步骤316 RTEM10加载并显示任何与当前对象需要的用户接口有关的信息，此步骤相应于“聚焦”(“GotFocus”)过程，此术语取在面向对象编程领域中的意义。例如，若当前对象(用记号current_object表示)是一个用户输入对象，如按键或输入域，RTEM10比较将当前显示的可视形式与当前对象显示的可视形式比较。如果它们是不同的，新的可视形式将被加载关显示。

当前对象在步骤318被调用，RTEM10检查对象的类型，且执行适当的逻辑来调用，或者在其他情况使用此对象。例如：

{current-object}.objecttype：

1＝method-set up parameters and invoke Method(设置参数并调用方法)

2＝Tool Usage-set up parameters and invoke Tool Usage(设置参数并调用工具使用)

3＝model_set up parameter and invoke Model(设置参数并调用模型)

因此，若当前对象是一个模型，则在步骤318a加载该模型。若当前对象是一个方法，则在步骤318b调用该方法。若当前对象是一个工具，则在步骤318c调用工具。

当对象(若是方法或工具)终止执行，若需要，在步骤320 RTEM10更新用户界面。RTEM10检查是否有任何当前表格上显示数据已经改变。在已经改变的当前表格上显示的数据将被显示。

如上述，有关数据的状态在该对象执行过程中可能改变，并且考虑到那些变种的条件，改变的数据可以影响到哪个变种被应用，RTEM10在步骤322再次根据流程图400的过程检查变种模型。若有任何数据改变，RTEM10完成一个详细的分析，确定当前加载的任何变种模型是否需要卸载且加载任何刚被激活的变种模型，如分别结合图9和图10的流程图400和500所说明的那样。

接着RTEM10在步骤324检查专门的作用。例如，若一个工具使用被调出从数据库中读信息，且该信息不存在，结果码将返回到RTEM10。专门作用能附于结果码之后，将下一个当前对象设置成为对于一个消息的对象识别码，此消息通知操作员，此信息在数据中不存在。例如：

{current_object}.result_code_000010＝“jump”

{current_object}.result_code_000010.resultobj$＝

      object ID of the message

{current_object}.result_code_000010.descriptn$＝“if record not on file，displaymessage”

此作用将设置当前对象到在变量{current_object}中规定的对象识别符：

resnlt_code 000010.resultobj$。

此时，步骤326将被跳过，控制转移到步骤314。

如果在步骤314检测当前对象的条件时，条件不满足，或如果在步骤324专门的作用没有已经设置该当前对象，将执行步骤326的逻辑。如果RTEM10当前正处理对父对象的前处理表，当前对象设成前处理表中的下一个对象。若没有更多的前处理对象，当前的对象设成父对象。因为在步骤328存在一个对象需处理意味着处理未完成，控制返回到步骤314。

若RTEM10当前处理一个父对象，对该对象的任何后处理作出检验(如{current_object}.postprocs$)。若对当前的对象没有后处理，RTEM10将当前对象识到父表中的下一个对象(lvsequence$)。检验该对象，确定是否有任何前处理与该对象相关。若有，当前对象设有前处理表中的第一个对象)例如，current_object＝preproc$(1，32))。

若没有，当前对象仍然作为下一个父对象。若RTEM10当前正处理一个父对象，且若此父对象有与它相关的后处理，则当前的对象将设置到这些后处理中的第一个。若RTEM10当前正在处理后处理，且无更多的后处理要执行，则当前的对象被设成下一个父对象，它被检测是否为前处理(如上所述)。若在任何时刻一个后处理返回一个正的结果码，没有一个专门的作用附属于该结果码(在图8的参考号324)，则当前的对象被设成当前对象的父对象。此对象然后被检测是否前处理。如果存在任何前处理，该当前对象被设成第一个前处理。并且，存在当前对象意味着在步骤328，无论过程是否已经完成检测的结果被判断是否定的，因此控制回到步骤314。

若在步骤326，不存在更多的对象要执行，或者若在步骤324一个专门的作用导致一条指令退出RTEM10，在步骤328的判断是肯定的且RTEM10在步骤330退出。

伴随着模型实时运行信息的一个伴随文件储存一张激活所有变种模型的所有条件的表。所有相对规范模型登录的变种模型更新此表。当操作员应用结合图6和6A描述的分类的模型设计工具时，在登录过程中变种模型相对于规范模型被登录。

该控制表的格式如下：

  LVRTEM.VAR_TABLE$这是对每个变种条件判断的表

LVRTEM.VARIATIONS$这是对应于lvrtrem.var_table$变种名称的表

例如，对给定的规范模型(未示出)三个变种模型每个都在下列条件下应用：

Variant Model‘variant1’：COUNTRY$＝“US”

Variant Model‘variant2’：COUNTRY$＝“CA”

Variant Model‘variant3’：COUNTRY$＝“ACME”

用于激活一个变种模型的每个条件的值被存入变量lvrtem.var table。对每个用于所有变种的条件有一个位置标志符(place holder)。在这里提供的例子中，有三个条件，因而在变种表中有三个位置标志符。

为了variant 1被激活，COUNTRY$＝“US”必须为真(用“1”代表)，COUNTRY$＝“CA”必须为假(用“0”代表)，而CLIENT$＝“ACME”可以是真或假，因为它不用于激活variant 1(用“0”代表)。

对variant 1的变化表如下述：

lvrtem.var_table$＝“100”

为了激活variant 2，COUNTRY$＝“US”必须为假(用“0”代表)，COUNTR$＝“CA”必须为真(用“1”代表)，而CLIENT$＝“ACME”可以是真或假，因为它不用于激活variant 2(用“0”代表)。

对variant 2的变化表如下述：

lvrtem.var_table$＝“010”

为了激活variant 3，COUNTRY$＝“US”可以是真或假，因为它不用于激活variant 3(用“0”代表)，COUNTRY$＝“CA”可以是真或假，因为它不用于激活variant 3(用“0”代表)，而CLIENT$＝“ACME”必须是真(用“1”代表)。

对variant 3的变化表如下述：

lvrtem.var_table$＝“001”

用于得知应用哪些变化的变化表通过将所有条件表加在一起构筑而成。变化表如下述

lvrtem.var_table$＝“100”+“010”+“001”或

lvrtem.var_table$＝“100010001”

此变种模型表存入变量lvrtem.variations中。变化的次序与条件表的次序相同。例如：

lvrtem.variction$＝“variant 1 variant 2 variant 3”

审视哪个变化是活动的条件存入变量lvrtem.var_check中。条件的次序与在条件表中值有相同次序。一个例子：

lvrtem.var_check$＝“(COUNTRY$＝“US”)+COUNTRY＝“CA”)

                     +“(CLIENT$＝“ACME”)

在实时运行中，设置一个变量与变化表比较，知道应用哪一个变化。变量使用lvrtem.var_check和变量在存储器中的当前状态来设置。下面提供一个例子。

在运行实时给定COUNTRY$＝“US”和CLIENT$＝“ACME”，将建立下面实时运行表：

lvrtem.varcurrent$＝str(lvrtem.var_check$)

针对变化表估计存储器中的变量如下：

(COUNTRY$＝“US”)-True用“1”代表

(COUNTRY$＝“CA”)-False用“0”代表

(CLIENT$＝“ACME”)-True用“1”代表给出下述实时运行表：

lvrtem.varcurrent$＝“101”

此实时运行表与每个存在lvrtem.var_table$中对此模型的每个表作比较。

已经知道，当前时间表的长度是3个字符，所以变化表三个一组地检测：

比较：

AND(lvrtem.var_table$，lvrtem.varcurrent$(1，3))是真，则在lvrtem.variations中的第一个变化(variant1)未被激活。

比较：

AND(lvrtem.var_table$，lvrtem.varcurrent$(4，3)是假，则在lvrtem.variations中的第二个变化(variant 2)未被激活。

比较：

AND(lvrtem.var_table$，lvrtem.varcurrent$(7，3))是真，则在lvrtem.variation中的第三个变化(variant3)是活动的。

在此例中，若在变化表lvrtem.var_table中的“1”与在实时运行当前变化表lvrtem.var current中相应位置的“1”相匹配，该变化认为是活动的。

术语“弹性数据库”用于本文件中试图涉及具有动态可扩性的一类数据库。在下面说明中使用传统的文件和记录的术语而不用关系数据库的术语。下面叙述的弹性数据库的实施例是提供那样数据库的一个方法的解释性例子(但不限于此)。在该例中，一个弹性数据库的库记录能扩展使包括额外的字段，且每个库记录能具有不同的扩展字段组。

一个弹性数据库包括一个传统数据文件形式的库文件。在传统的数据库中，库文件中的所有记录具有同样数量的字段，且在整个记录组中每个字段具有相同的特征。在弹性数据库中，这被称为库记录。对弹性数据库一个库文件和库记录的解释性例子示于图11之中。

一个弹性数据库的主要优点是它能允许用额外的字段扩展库记录，使每个库记录能有不同的扩展字段组。这些扩展字段组成“变化组(在下面详细说明)以便于维护与使用。任何库记录可以具有0个或多个变化组加到其上。加到给定库记录的变化组表可以在不同条件下动态地改变，就如在库记录中的数据那样。图12提供了2个变化组定义的例子的图示。库文件和所有应用到该库文件的变化组的集合称为“逻辑文件”(“Logical file”)。

一旦库文件在数据字典12(图1)中被定义，变化组可以加到逻辑文件定义中。这可以通过数据字典的维护做到。图13A、13B和13C示出定义新变化组的步骤。每个变化组由数据字典12赋予一个识别符。对于下面描述的在图12中图示的变化组识别符分别是“0001”和“0002”。每个变化组包括变化组所含的字段清单和每个那样字段的属性。此外，每个变化组可以具有一个与其相关的条件。此条件确定变化组应用的库记录。若一个变化组没有与其相关的条件，该变化组应用到所有库记录。

每个条件列出数据库的一个字段表，它们每个必须包含一个值，对此值应用变化组。例如，若库记录包含一个称为“client”(“顾客”)的字段，变化组可以具有一个条件，它指出，仅当字段“client”包含值“BENJAM”时应用该变化组。

图11和图12提供一个库文件和变化组的例子。在图11中，库文件相应于逻辑文件“sam_client”，此文件储存顾客名和地址，通过参照数据源表名“sam_dbclrent”(相应于图3的数据库表/文件126)访问。该库文件的库记录包括5个字段：顾客、姓名、国家、街道和城市，每个具有自己的描述、类型和长度。图12示出2个变化组的例子，相应于且附属于逻辑文件“sam_client”，如图11中示出。第一个例子是变化组0001，它具有描述“Canadian Information”(“加拿大信息”)。此变化组应用的条件需要库记录字段名“Country”(“国家”)具有值“CA”---指出加拿大。在此条件下，库记录不仅包括图11中列出的5个字段，还包括2个额外的字段：“postal_cd”(6位数字的邮政编码)和“province”(2个字符的省份码)。换言之，此变化组应用到所有满足此条件的库记录，此条件附在变化组后面，并与其相关。图12中变化组的第二个例子被识别为号0002，且具有描述“U.S.Information”(“美国信息”)。应用到此变化组的条件是库记录字段名“country”(“国家”)具有库记录字段值“US”。若是这样情况，则库记录扩展到包括2个新字段“zip_code”(美国的zip code，即邮政编码)和州代码(2字节的美国州代码或缩写)。此例说明了弹性数据库在不同数据条件下扩展建立新字段的能力。

每个变化组的数据存入库文件的伴随文件中。这些伴随文件由数据库存取控制器24，30(图1)被透明地维护(需要时创建)。每个伴随文件的主键等同于库文件的主键，因为从任何库记录到应用到该库记录的每个变形组记录存在一对一的关系。

DBAC24，30使用一个称为变化组实时运行映射(VRTM)的小表来确定在实时运行应用哪些变化组。DBAC24，30实时运行变化表与结合图5的叙述，上面引入RTEM10模型变化实时运行表具有同样的结构。

在3个变化应用到逻辑文件的地方，一个变化组实时运行映射例子如下所示：

变化(变化组表)	条件(条件字段表)	估值码(条件组表)
			0001	当COUNTRY＝US	100
0002	当COUNTRY＝CA	010
			0003	当CLIENT＝ACME	001

在此例中，所有估值码是二进制，其中只有一个数字为1。实时运行表达式表如下：

(COUNTRY$＝“US”+(COUNTRY$＝“CA”)+(CLIGNT$＝“ACME”)

作为一个例子，假设下列数据保存在存储器中库记录之后面：

CLIENT＝“ACME”

COUNTRY＝“US”

利用估值码表(Evaluation Code Table)对估值码获得一个现有的数据，并将得到的估值码***实时运行表达式表中：

(COUNTRY$＝“US”)+(COUNTRY$＝“CA”)+(CLIENT$＝“ACME”)产生一个实时运行估值码：“101”。为显示实际的二进制数学操作：

position 1：COUNTRY$＝“US”是真，表示成“1”

position 2：COUNTRY$＝“CA”是假，表示成“0”

给定结果：“101”。当表达式表中的一项不满足--例如此处国家不是加拿大(CA)--估值码为0。因为COUNTRY＝“CA”的估值是第二条件，此条件的估值存入二进制输出的第二位置，101。

最终的实时运行估值码与一个表进行比较，证明一个估值码和给出此码的活动变化之间的对应性。活动变化是在实时运行估值码同样位置上具有1的变化。下面是那样表的例子：

实时运行估值码	变化	变化表	活动否？
				101	0001	100	是
101	0002	010	否
				101	0003	001	是

一个那样表对应一个逻辑文件。变化组可以是二种状态之一：活动或不活动。新建立的变化组是不活动的，直到明确地使其活动。当一个变化组被激活，有关此变化组的信息加到VRTM，使DBAC 24，30知道此变化组并在适当时候使用它。当一个变化组使得成为不活动，有关此变化组的信息从VRTM中除去，使DBAC 24，30不再知道该变化组，因而对它不再做什么。

下面一段信息存入VRTM：

1)条件字段表(CFL)

涉及所有变化组条件的所有字段表。此表用于很快地产生一个包含涉及变化组条件所有字段的当前值的字符串。产生的字符串称为条件值字符串(ConditionValues String-CVS)。

2)条件组表(CGL)

表示可能的数据值或图案(pattern)的字符串组。在实时运行时，CVS转而与每个图案比较。若CVS与该图案吻合，则在CGL中图案的位置用作在变化组表中的索引(见下面)。

3)变化组表(VGL)

一个变化组号的组的表。检查此表和与CVS吻合的CGL，给出一张应用于当前在存储器内的库记录的变化组表。

VRTM也能包括其他的内部处理和状态信息。

在DBAC24，30能对任何逻辑文件完成任何功能之前，它必须访问数据字典12。DBAC24，30使用数据字典12的信息来寻找逻辑文件和它们的物理数据源。当DBAC24，30被调出来完成对逻辑文件的请求时，若数据字典12尚未打开，则DBAC24，30为此逻辑文件的模块打开此数据字典12。一旦库数据字典12被打开，DBAC24，30检查一个变化登录(variation registry)和变化组实时运行映射。上述打开数据字典的过程示于图15之中。

从弹性数据库中读出记录的过程如下进行：在实时运行中，DBAC24，30从库文件中读出库记录。一旦完成此事，就审视变化组实时运行映射以决定应用哪个变化组。图16A和16B示出DBAC24，30用于此任务的步骤。若存在应用的变化组，则对每个变化组从适当的伴随文件中读出数据。若在适当的伴随文件中找不到记录，则对该变化组的字段设成空字符(null)。这发生在变化组被加入以前已经存在库记录的情况。

因为应用到库记录的变化组当库记录中的数据发生变化时可以动态改变，DBAC24，30返回给应用软件的不仅是库记录与变化组数据，而且还有库记录中的字段表和变化组应用情况信息。这就允许应用软件来确定在逻辑记录中出现哪些字段，并当需要时将该信息提供给操作员。

写记录到弹性数据库的过程是如下进行：根据图16A和16B，在实时运行中DBAC24，30审视变化组实时运行映象，了解应用哪个变化组。然后DBAC24，30将变化组数据写入伴随文件中，再将库记录写入库文件。若在记录读出时应用的某些变化组在记录重写时不再应用，则DBAC24，30将那些过时的变化组数据从适当的伴随文件中除去。

在弹性数据库中的一个记录能用下列过程除去：在运行时间DBAC24，30读出并锁定要被除去的记录，并根据图16A和16B确定哪些(若有的话)变化组应用到该库记录中。该变化组数据被除去，该库记录也被除去。

一旦库文件中数据字典12中被定义，变化组可以加到逻辑文件定义中。这可以通过数据字典12的维护来做。每个变化组由数据字典12分配一个识别符。每个变化组定义包含一个变化组包含的字段表，和伴随的每个字段的属性。

在本发明的实施例中，参照图13A，一个变化组可以根据过程560定义，后者从步骤562开始。首先在步骤564规定一个逻辑文件。变量组的描述在步骤566输入，在步骤568输入注释。参照图13B，在步骤570作一测试，以确定对该变化组是否需要规定一个条件。若需要，则对该条件检测的库记录的字段在步骤572上输入。且在步骤574输入一个值到某字段，该字段是为了检测条件的符合及应用该变化组。在步骤574检查是否存在更多的条件字段。若存在，处理过程返回到步骤572。否则，或者在步骤570不需要指定条件的情况，处理过程进到图13C中步骤578。在步骤578输入字段信息到包括在当前变化组的下一个字段。然后在步骤580作出判断，是否包括有更多那样的字段。若是，处理过程返回到步骤578。若不是，变化组定义在步骤582被储存，过程560在步骤584结束。

在DBAC24，30能对任何逻辑文件完成任何功能以前，它必须访问数据字典12。DBAC24，30使用数据字典12信息寻找逻辑文件和它们的物理数据源。当DBAC24，30被调用来完成对逻辑文件的请求时，若数据字典尚未打开，则DBAC24，30将对该逻辑模块打开数据字典。一旦库字典被打开。如图14所示DBAC12检索变化登录和实时运行映象。

参照过程600，如图14所示在步骤602变化登录文件在步骤604被打开。接着在步骤606作一检查，是否存在那样的文件。若是，过程600在步骤608打开变化实时运行映象文件。然后在步骤610作一检查，是否存在变化实时运行映象文件。若是在步骤612设置一个标志，指示对此模块存在活动的变化。若在步骤606或步骤610检查结果为否定，过程600在步骤614结束。

在一个逻辑文件能读写访问以前必须首先打开。当一个逻辑文件被打开，如图15所示DBAC24，30立即将对于该逻辑文件的变化组实时运行映象加载到存储器中。参照此图，文件的打开能按照过程620从步骤622开始完成。在步骤624作出决定，是否对该逻辑文件存在任何活动变化。若是，在步骤626将与此逻辑文件相关的变化组实时运行映象的记录读出。如在步骤628所确定，若找到一个记录，则在步骤630对此文件的变化组实时运行映象被存入存储器。若在步骤628找不到记录，或如果在步骤624找不到对此逻辑文件存在的活动的变化，处理过程在步骤632停止。

在实时运行中，DBAC24，30从库文件中读出库记录。一旦完成此操作，它审视变化组实时运行映象以确定应用哪个变化组。如下面所述，图16A和16B示出DBAC用于完成此任务的步骤之例。

若应用任意的变化组，DBAC24，30对每个那样的变化组从适当的伴随文件中读出数据。若一个记录在适当地伴随文件中未找到，对该变化组的字段设成空(null)。对于在变化组加入以前已经存在库记录的情况就是这样的。

因为应用于一个库记录的变化组在库记录中的数据改变时可以动态地改变，DBAC24，30返回给应用软件的不仅是库记录和变化组数据，而且有在库记录中的字段表和变化组应用情况信息。这就允许应用软件确定在逻辑记录中出现哪些字段，并将此信息需要时提供给操作员。

在实时运行中，DBAC24，30审视变化组实时运行映象，了解要应用那些变化组。如下所述，图16A和16B提供该过程的一个例子。然后变化组数据写到适当的伴随文件，且库记录数据写入库文件。

当记录读出时应用的某些变化组如果在记录重写时不再应用，则DBAC24，30将该过时的变化组数据从适当的伴随文件中除去。

在实时运行时DBAC24，30读出并锁定需除去的记录，并决定哪些变化组(若有的话)应用于该库记录，如图16A及16B的例子中所说明。此变化组数据被除去，然后该库记录被除去。

现参照图16A，说明以前的过程640的例子。在步骤642开始后，过程640在步骤644清除应用的变化组表。接着，在步骤646从存储器中取出对当前文件的变化组实时运行映象。若在步骤648找到对当前文件的变化组实时运行映象，则在步骤650对库记录产生一个CVS(当前变化组)。CVS是条件的当前实时运行二进制映象估值，该条件用于决定应用什么变化。这类似于上述的lvrtem.varcurrent，但在此例中被称为lvdbac.varcurrent。换言之，CVS是当前数据的值，用于相对变化表进行检验，了解当前应用什么变化。接着，在步骤652当前CGL(条件组表)设到第一个CGL元素。CGL类似于上述lvrtem.var_table，在本例中称为lvdbc.var_table.CVS与此表比较，了解应用什么变化。

参照图16B，在步骤654在CVS和CGL的元素之间作出比较。若在步骤656中确定，比较是吻合的，则在步骤658，一个VGL(变化组表)元素被加到所应用的变化的表中。若在步骤656中发现不吻合，则在步骤660作出检验，以确定是否有其他的CGL元素。若有，则在步骤662当前CGL元素被设成下一个CGL元素，且处理过程回到步骤654。若在步骤660无其他CGL元素被找到，则处理过程在步骤664终止。

若在图16A中步骤648，未找到变化组实时运行映象，则对此逻辑文件无当前活动的变化。此时，处理过程也在步骤664终止。

结合图1上述的超级工具包(Supertoolkit)有若干入口点。每一个入口点相当于DBAC24，30提供的一个功能，和RTEM10调用DBAC24，30完成的功能。在一个实施例中，DBAC24，30有10个入口点；每个入口点的例子的逻辑将依次叙述。

功能：READ(读)READ1200从初始化1205与验证参数1208开始。READ然后查询是否有别名(Alias)已经打开1210。若别名已被打开，READ查询当前请求READ中的逻辑文件名是否与已经以别名打开的逻辑文件名吻合1215。若是，READ继续；否则READ退出，指出故障1218。若发现别名尚未打开，READ打开文件，如有需要打开并读数据字典12，1220。若打开成功，READ继续1225；否则退出，指示故障1228。若请求RTEM10从环境数据建立该记录的读的主键1230，则从环境数据产生一个键1235，若产生键成功1240则READ继续。若产生键失败，READ退出指示故障1242。若在上面不请求RTEM10从环境数据建立该记录的读的主键1230，则READ简单地继续。除非它提前退出，READ随后从盘中读出库记录信息1245。若该记录存在1250，READ继续。若读失败，且其原因不是“没有这样的记录”1260则READ退出，指示故障1262。若读未失败，它继续。一个数据变化实时运行映象被检验1265，若存在应用于该记录的数据变化组1270，则该变化数据从盘中读出1275。若不存在那样的数据变化组，则READ继续。若“no such record”(无那样的记录)指示器被设置1280，则READ继续；但是若不是，则READ从盘中读出任何适当二进制大对象(binary large object-“BLOB”或存储器字段数据1285。当此过程完成，READ退出1290，指出或者成功，或者“no such record”(无那样记录)。图17A和17B以图的形式表示上述的步骤。

功能：EXTRCT(提出)EXTRACT由初始化及验证参数1305，1308开始。EXTRACT然后询问是否已有别名打开1310。若别名已打开，EXTRACT询问，当前对EXTRACT请求的逻辑文件名是否与在别名上已经打开的逻辑文件名吻合1315。若是，EXTRACT继续；否则EXTRACT退出1318，指示故障。若发现别名尚未打开，EXTRACT打开文件且若有需要则打开并读数据字典12，1320。若打开成功，EXTRACT继续；否则退出1328，指出故障。若请求RTEM10从环境数据中建立该记录的读的主键1330，则一个键从环境数据中产生1335，且若该键产生成功1340，  EXTRACT继续。若该键产生不成功，则EXTRACT退出，指示故障1342。若在前面不要求RTEM10从环境数据建立该记录的读的主键1330，则EXTRACT直接继续。除非提前退出，EXTRACT随后从盘中读出库记录信息1345。若该记录存在1350，则EXTRACT继续；否则它设置“nosuch record”(无那样的记录)指示器1355并继续。若读失败，其原因不是“no suchrecord”1360，则EXTRACT退出，指示故障1362。若读并未失败，它继续。检验数据变化实时运行映象1365，若存在应用该记录数据变化组1370，则从盘中读出变化数据1375。若不存在那样的数据变化组，则EXTRACT继续。若已设置了“no such record”指示器1380，则EXTRACT继续；但是若未设，则EXTRACT从盘中读出适当的二进制大对象(“BLOB”)或存储器字段数据1385。若此过程完成，EXTRACT退出1390，指示或者成功或者“no suchrecord”。

EXTRACT和READ操作的不同是EXTRACT为写的目的锁定数据。在多用户应用软件中，同样的数据可同时由多个操作所请求。为保护数据库的崩溃，需更新的数据库首先EXTRACTED(锁定)。若当EXTRACT请求发生时数据已被EXTRACTED，DBAC24，30在继续处理过程以前等待数据成为未锁定状态。这可以在1秒以后再次试图作出EXTRACT请求。显示一个信息给操作员，警告此情况。操作员然后可以请求退出EXTRACT请求，送一个特殊结果码返回给RTEM10。

功能：VERIFY KEY(验证键)VERIFY KEY由初始化及验证参数1405，1408开始。VERIFY KEY然后询问是否已有别名打开1410。若别名已打开，VERIFY KEY询问，当前对VERIFY KEY请求的逻辑文件名是否与在别名上已经打开的逻辑文件名吻合1415。若是，VERIFY KEY继续；否则VERIFY KEY退出1418，指示故障。若发现别名尚未打开，VERIFY KEY打开文件，且若有需要则打开并读数据字典12，1420。若打开成功，VERIFY KEY继续；否则退出1428，指示故障。若请求RTEM10从环境数据中建立该记录的读的主键1430，则一个键从环境数据中产生1435，且若该键产生成功1440，VERIFY KEY继续。若该键产生不成功，则VERIFY KEY退出1442，指示故障。若在前面不寻求RTEM10建立记录的主键而从环境数据读出它，则VERIFY KEY直接继续。除非提前退出，VERIFY KEY随后带此键从数据库中读1445。若记录存在1450，VERIFY KEY继续；否则设置“no such record”指示器并继续1460。

功能：GENERATE KEY(产生键)GENERATE KEY1500由初始化及验证参数1505，1508开始。GENERATE KEY然后询问是否已有别名打开1510。若别名已打开，GENERATE KEY询问，当前对GENERATE KEY请求的逻辑文件名是否与在别名上已经打开的逻辑文件名吻合1515。若是，GENERATE KEY继续；否则GENERATE KEY退出1518，指示故障。若发现别名尚未打开，GENERATE KEY打开文件，且若有需要则打开并读出数据字典12，1520。若打开成功1525，GENERATE KEY继续；否则它退出，指示故障1528。GENERATE KEY随后从环境数据产生一个键1530。若键产生成功1535，则该功能退1540，指示成功。另外若键产生失败，功能退出1545，指示故障。

功能：WRITE(写)功能WRITE1600从初始化1605和参数验证1608开始。然后WRITE功能查询是否有别名已被打开1610，若别名已被打开，WRITE功能查询当前请求WRITE功能中的逻辑文件名是否与已经以别名打开的逻辑文件名吻合1615。若是，WRITE功能继续；否则WRITE功能退出，指示故障1618。若发现别名尚未打开，WRITE功能打开文件，若有必要打开并读数据字典12，1620。若打开成功1625，WRITE功能继续；否则退出1628，指示故障。若请求RTEM10从环境数据建立该记录的主键1630，WRITE功能试图这样做1635。若主键产生成功1640，则WRITE功能继续；否则退出，指示故障1642。但是如果RTEM10不请求从环境数据建立该记录的主键，WRITE功能继续。若存在一个非空主键1645，WRITE功能继续；否则退出1648，指示故障。假设WRITE功能继续，它在逻辑文件1650上设置写锁定1650。于是，如果在此别名上重写当前取出的记录1655，WRITE功能继续。若不是，检验要写的记录是否已经存在1660。若该记录存在，WRITE功能释放写锁定，退出并指示故障1665。若该记录不存在，WRITE功能继续。假设WRITE功能继续，它得到当前应用于现在记录的扩展表1670。它赋值给顺序符(sequencer)字段1675，它将任何适当的BLOB或Memo字段数据和任何适当的扩展组数据写到盘中1680。WRITE功能还将库记录数据写到盘上1685。然后，它校验，是否有在取出记录时应用，而现在已不再应用的扩展1690。若有，WRITE功能将它们除去1692；否则它继续，清除写锁定并退出1695。

功能：REMOVE(除去)REMOVE功能1700从初始化1705和参数验证1708开始。然后REMOVE功能查询是否有别名已被打开1710。若别名已被打开，REMOVE功能查询当前请求REMOVE功能中的逻辑文件名是否与已经以别名打开的逻辑文件名吻合1715。若是，REMOVE功能继续；否则REMOVE功能退出1718，指示故障。若发现别名尚未打开，REMOVE功能打开文件，若有必要打开并读数据字典12，1720。若打开成功1725，REMOVE功能继续；否则退出，指示故障1728。若请求RTEM10从环境数据建立该记录的主键1730，REMOVE功能试图这样做1735。若主键产生成功1740，则REMOVE功能继续；否则退出，1742，指示故障。但是，如果RTEM10不请求从环境数据建立该记录的主键，REMOVE功能继续。假如REMOVE功能继续，它检查是否除去当前从现在的别名中取出的记录1745。若是，REMOVE功能继续；但若不是，REMOVE功能取出库记录数据1750。若取出成功1755，则REMOVE功能继续。否则退出，指示故障1758。假如REMOVE功能继续，它从盘中除去库记录数据1760，从盘中除去任何适当的扩展数据组数据1765，并从盘中除去任何适当的BLOB或Memo数据，然后退出1775。

功能：CLOSE(关闭)CLOSE功能1800在初始化1805和参数验证1808以后查询，RTEM10是否请求关闭所有别名1810。若是，CLOSE功能取出所有别名的一个总表1815，否则带着RTEM10提供的别名表继续1820。对以前步骤中获得的清单中的每个别名，CLOSE功能关闭库记录物理文件，关闭任何可应用的扩展组记录文件，清除所有储存的有关此别名的状态信息1825且退出1830。指不成功。

功能：SHUTDOWN(停止)在初始化1855和参数验证1858以后，SHUTDOWN功能1850调用CLOSE功能1800且请求它关闭所有别名1860。SHUTDOWN功能随即关闭所有打开的数据字典1865并清除所有缓冲的数据字典信息1870，和退出1875，指示成功。

功能：GET KEY(取键)GET KEY功能1900初始化1905和参数验证1908，并查询别名是否已打开1910。若是，GET KEY功能查询，在现在的别名上的最近的操作是否为成功的EXTRACT 1915。若是，则GET KEY取出一当前键1920。若不是，GET KEY取出下一个键1925。若取出下一键的试图成功1930，则GETKEY退出1935，指示成功；否则，或若在此别名上的最近操作不理成功的取出，GET KEY退出1940，1942，指示故障。

功能：GET FIRST KEY(取首键)GET FIRST KEY功能1950在初始化和参数验证955，1958以后，查询该别名是否已打开1960。若是，GET FIRST KEY取出第一个键1965。若取出第一个键成功1970，则GET FIRST KEY退出1975，指示成功；否则退出1980，指示故障。若发现该别名尚未打开，GET FIRST KEY退出1985，指示错误。

若干其他功能，尤其是GET PREVIOUS KEY，GET CURRENT KEY，GETNEXT KEY，GET LAST KEY，其功能几乎等同于GET FIRST KEY功能，但差别在于它们返回的键。

本发明的一个优点是能与现存的传统(Legacy)程序码共同工作。“传统”是在本发明的教导以前存在的应用软件，并且它必须作些修改，为了能在RTEM/Model环境下与使用本发明专门开发的模型一起运行。

为了修改传统软件，程序码需转换成可以为DBAC24，30所接受。为实现从传统软件到混合传统软件(带有调用与RTEM10兼容的模型与方法的传统软件)的初始转换，所有数据库的访问改变成链接到DBAC24，30。可用性的校验用调用“写前文件元素可用性”(pre-write file-element validation)来替代，后者基于对数据字典12的字典段的预编译数据总库。写入一个文件借助于使用由有效测试程序编译的文件表的单个DBAC24，34访问来完成。所有表示性输入输出转换成使用UIO26。程序码也转换成使用数据字典12。文件使用信息(例如读、写、抽取或删除的文件)放在数据字典12中。传统程序码中的变量重新定义成在数据字典12中使用的字符识别符，例如32(二进制)位的识别符。参照到何处(例如程序/行)和如何(例如估值，打印(屏蔽值)，级联的，传送的，变暗的，输入，更新)。在传统软件转换的过程中，只允许对传统软件作出错误校正改变；不允许加上新的逻辑。

对RTEM10可以使用的文件逻辑对象建立一个传统软件引擎(库)。在从传统软件转换到与RTEM10应用的方法兼容的软件期间建立的“过程对象”可以耦合到传统程序码来建立“混合传统程序”。耦合通过使用“门-Gates”来实现。如上所述，门放在传统软件中在程序码语句的间隙中，如上述与传统软件转换过程相联系。假定没有新的逻辑可以加到传统程序码，按照本发明的实施例改变到涉及新逻辑的程序码必须借助于***门来调用，此门将使能或禁止那样的新逻辑。新逻辑本身体现在模型和/或方法中。对格式化用于RTEM10的逻辑的条件门的一个例子是：

nnnnn DPCU-123456；perform

“Get list_of_active_Gates”；

IF ACTIVE_GATE＞0 THEN PERFORM“Gate-Control”

调用“Get_list_of_active_gates”将构筑所有门的表(或“门控-gate_controlled”逻辑)这对当前用户有用；此估值将包括所有public(公共)和test(测试)对象，后者是该用户登录使用的。当逻辑修改对生产是可接受时，对象简单地做成公共的；不需要对应用软件作改变。

以前的方法允许混合传统软件在进行中分析和“修改”。例如，用此方法，能对混合传统软件作出下列改变。

·对数据字典12的修改，以实现固定；

·能建立变量屏蔽表；

·能完成2000年日期转换；

·能修改时间单位；

·能替换旧的屏蔽；

·潜在的叠印(例在修改的报告上)可以被提交。

此外，可以做出下列混合传统软件修改：

1.输入字段和它们相关的逻辑可以加入、忽视或默认，或者通过使用门，或者通过其他方法；

2.新字段可以加到现有的文件记录：

a.使用弹性数据库能力(结合DBAC24，30的功能描)；

b.在现存文件记录中的字段可被除去；例如过时的字段应借助DBAC24，30默认一个值，且不立即除去，而是在以后使用弹性数据库的能力来除去。

3.即使在使用条件调用的测试过程中可以加入新文件的读、写、抽取和其他操作(新文件定义作为新对象)；和

4.传统逻辑可以使用正常的条件测试逻辑截断，使无效或忽视和转移开。

上面说明了用于软件开发的方法、***和数据结构的一个实施例，它解释了本发明的原则。本发明的其他方面、特征和优点对那些熟悉本专业的人员是十分明确的。

Claims (24)

1.一个用于运行应用软件的计算机执行***，所述***具有一个处理器，一个存储器和一个存储介质，所述***包括：

储存在存储介质中的多个模型，每个模型包含的数据中包括对一个或多个对象的参照；和

一个实时运行事件管理器，用于将从多个模型中选定的一个从存储介质加载到存储器中，读出所述所选模型的数据，且当读入对一个对象的参照时，调用并执行所述对象。

2.如权利要求1所述的计算机执行***，其特征在于所述模型是按照登录过程建立的一组模型的部分，且实时运行事件管理器只能访问按照登录过程登录的模型。

3.如权利要求2所述的计算机执行***，其特征在于，模型只有在不包含对能够调用其他方法的方法的参照的情况才被登录。

4.如权利要求1所述的计算机执行***，其特征在于所述模型包含：

a.形成规范的第一类模型；和

b.第二类模型是规范模型的变种。

5.如权利要求4所述的计算机执行***，其特征在于，变种模型有一个或多个与其相关的条件，它们对于由实时运行事件管理处理的变种模型是必须满足的。

6.如权利要求5所述的计算机执行***，其特征在于，所述实时运行事件管理器进一步适应于：

a.当调用一个规范模型时，检验对所述规范模型是否存在变种模型；

b.若存在一个变种模型，取出所述模型；

c.检验对所述取出的变种模型的条件是否存在；且

d.若所述取出的变种模型的条件存在，处理所述变种模型。

7.如权利要求6所述的计算机执行***，其特征在于，所述实时运行事件管理器适应于重复步骤b-d，直至没有更多的变种模型与规范模型有关，并对于那些变种模型存在相关的条件。

8.如权利要求1所述的计算机执行***，其特征在于，所述实时运行事件管理器适应于在处理一个模型中的每个对象以后适应于处理所述模型外部的作用。

9.一种实时运行事件管理器，借助于计算机执行实现处理与指令相关的活动，处理在计算机外且通过外部输入、输出与计算机通信的事件的响应，所述计算机包括一个存储介质，其中储存一组对实时运行事件管理器可以访问的模型，管理器包含

从模型库中加载一个模型的装置；

给定计算机和实时运行事件管理器的状态确定一个加模型是否被适当调用的装置；和

给定计算机和实时运行事件管理器状态，若认定模型是适当的则调用所述模型的装置。

10.如权利要求9所述的实时运行事件管理器，其特征在于，执行模型的方法包括在使一个模型的一个给定元素有效以前检测和响应外部的事件的方法。

11.一个使用实时运行事件管理器开发计算应用软件的方法，其特征在于包括下列步骤：

a.建立多个模型，每个包括至少下列中之一：

    i.一个对模型的参照；

    ii.一个对方法的参照；

    iii.数据；和

    iv.输入或输出指令；

b.检验所述模型，保证没有由一个模型参照的方法能调用另外的方法；和

c.登录所述模型，使允许由所述实时运行事件管理器来访问。

12.开发如权利要求1的计算机应用软件的方法，其特征在于：所述步骤借助运行一个实时运行事件管理器结合一组模型来完成。

13.在计算机应用程序中使用且包含计算机可读介质中的一个软件模型，包括：

一个模型识别码；

对软件对象的多个参照；和

数据。

14.如权利要求13所述的软件模型，其特征在于，对软件对象的参照包括一个父对象和由前处理及后处理对象组成的组中选取的一个对象。

15.如权利要求13所述的软件模型，其特征在于，模型是一个规范模型的一个变种模型，它具有对软件对象的一组参照，且在变种模型中参照的软件对象不同于在规范模型中参照的对象。

16.如权利要求15所述的软件模型，其特征在于，仅当一组条件满足时，模型可以由实时运行事件管理器调用。

17.建立一个为实时运行事件管理器使用而登录的对象的库的方法，它包括步骤：

a.调用一个基于唯一模型识别符的对象；

b.扫描所述对象的内容，是否存在被限止的内容；和

c.仅当一个对象不包含被限止的内容，登录所述对象作为所述库的部分。

18.如权利要求17所述的方法，其特征在于，受限止的内容包括在一个对象中对一个尚未登录对象的参照。

19.如权利要求17所述的方法，其特征在于，受限止的内容包括对一个方法对象的参照，该方法对象又包括对另一个方法对象的参照。

20.一个计算机执行数据库***，所述***具有一个处理器，一个存储器，和一个存储介质，所述***包含：

一个存在存储介质中的库文件，所述库文件包含多个库记录，每个库记录具有一个或多个字段；

对应于所述库文件至少有一个变化组存在存储介质中；和

所述编程的***实现一变化组实时运行映象，适用于确定应用哪个变化组到特定的库记录中。

21.如权利要求20所述的计算机执行数据库***，其特征在于，所述变化组有一个或多个相关的条件，为了变化组应用到特殊的库记录，这些条件必须满足。

22.如权利要求21所述的计算机执行数据库***，其特征在于变化组实时运行映象包括一个条件字段表，一个条件组表，和一个变化组表。

23.一个运行数据库的方法包括步骤：

a.从库文件加载一个具有一个或多个字段的库记录；

b.检验一个变化组实时运行映象，是否存在相应于所述库文件的变化组；和

c.若一个变化组存在，从所述变化组取出数据。

24.运行权利要求23的一个数据库***的方法，其特征在于，从变化组中取出数据的步骤进一步包含步骤：

检测是否存在对所述变化组的条件；和

若对所述取出的变化组的所述条件存在且满足，从应用到库记录的所述变化组中取出数据。

Images