CN107851001A - 用于基于设计规格显示软件型应用程序的计算机应用的方法 - Google Patents

Abstract

本发明涉及一种系统和方法，该方法基于在由存储器和处理器形成的电子装置中的逻辑信息结构的输入而在视觉装置中自动产生输出，该视觉装置可操作以创建关于业务流程的信息，从而替换通常依靠在软件工业中已知的传统编程开发出的软件应用程序。给定与软件设计的逻辑结构对应的信息，将该信息引入到机器中，该机器将该信息以模型的形式存储在存储器中。所述模型由在视觉装置中自动产生结构的系统(100)解释，从而允许替换软件。本发明涉及由系统(100)用来引入、存储、解释和产生替换软件的结构性逻辑和视觉结构的过程。

Description

用于基于设计规格显示软件型应用程序的计算机应用的方法

相关申请的交叉参考

本申请要求由与本申请相同的发明人提交于2015年5月13日的标题为“Métodoimplementado por computador que expone las aplicaciones tipo software apartirde especificación de ”(由计算机用以基于设计规格显露软件型应用程序的方法(Method employed by a computer for exposing software-type applications basedon design specifications))的美国临时专利申请第62/161,216号的优先权。上述临时专利申请内容以其全部内容通过引用并入本文，如同其在本文档中公开。

技术领域

本发明是一种由计算机实行以基于软件设计规格自动产生全操作软件型应用程序的系统和方法。

该系统使得用户能够通过输入/输出装置录入类设计和屏幕设计(软件设计规格)。处理器应用两个协议以自动创建存储在存储器数据库中的功能和视觉模型。然后，处理器将这些模型与图形组件组合，并在不生成可编译代码的情况下将该软件型应用程序实例化。这些应用程序展现给用户以被操作并产生作为结果的信息。

背景技术

软件工业提出一系列活动作为产生解决方案的机制，在这些解决方案之中可以找到数据库的构造和计算机程序的编码。这些活动在将允许所得的软件在多个用户环境中操作的架构的框架内工作。此类任务由有资格理解软件设计的人员执行，并从这些任务开发程序。这些任务的性质确定制作软件由以下专业简档突出的队伍实：

-架构师：考虑终端用户环境定义应用程序层架构。架构的示例为SOA(面向服务的架构)、客户服务器等。

-数据库程序员：构建其中当使用应用程序时用户生成的数据将被存储的结构。存在称为数据库引擎的工具，该工具基于不同的但在共同的已建立标准下同时工作的技术。

-应用程序程序员：以特定语言(Java、C#、Vbnet等)编写程序代码，该程序代码然后被编译以获得计算机将执行的对象代码，从而产生用户将访问的最终应用程序。

-用户界面设计师：设计屏幕、视觉组件和图形样式模板，它们使得计算机程序能够在外观上用户友好并且易于使用。

为创建软件，必需依靠类似于上述队伍的专业队伍，因为通常需要创建软件的人员不具有需要学习若干年的上述技能。

在软件工业中出现的问题具有不同维度，诸如：

i.对解决方案的需求在世界范围内以比训练该领域中的专业人员所需更快的速率增长。因此，可观察到大量未满足的开发需求。

ii.编写软件的过程是昂贵的并消耗大量时间，这暗示需求其的部门将不能高效且方便地满足所有其需要。

iii.以快节奏演进的各种技术(数据库、编程语言、架构、用户界面)在已开发的应用程序中产生技术陈旧的问题。这意味着当软件在操作时，通常新技术出现，由工业专业人员采用。此软件的更新暗示与其初始创建时一样重要的重组努力。

iv.在不稳定的全球经济中的商业运作规则的不断变化需要对软件应用程序的适配和改善，这由于金钱/时间因素与技术陈旧的组合而因此通常是不可行的。为此，软件应用程序不供应适时且灵活的演进。

现有技术揭示无数种用于自动生成软件以便减小在软件应用程序开发寿命周期中的时间和成本的系统和方法。US2006/0015839公开了一种基于两个可能的源、数据库生成J2EE可编译源代码的系统和方法，在该数据库中，待开发的系统的所有参数、图表和架构被明确规定，这意味着需要技术设计的详细知识作为输入。基于该详细定义，并且编写XML文件，且该XML文件可由用户更改以调整设计。最终XML文档由自动生成J2EE代码的框架工具和系统架构进行处理。形式工具也基于在XML源文档内明确定义的结构自动产生用户界面形式。系统部署工具将源数据库和程序代码整合成可编译结构，从而产生软件应用程序。

不同于本发明，US2006/00115839生成了J2EE可编译代码，并且需要程序的计算架构及其数据库结构、对象参数和表字段的现有知识。而且，需要XML的详细知识并且在一些情况下需要直接代码注入以执行不由所提到的配置和编辑程序执行的一些任务。

类似地，US2002/0077823公开了一种创建软件应用程序的方法和系统，该软件应用程序可在多个客户端平台(特别包括语音操作平台)上运行，这暗示一种用于将语音解释为输入数据的语音识别方法。例如，具有受限的屏幕或键盘访问的蜂窝电话用户可在网页上得到音频格式的信息，并可通过说出而不是书写的单词和句子转而与网站交互。上述文档将其自身限于话音识别、将语音识别转换成文本，该文本随后作为任何其它应用程序输入数据被处理。不同于本发明，此文档不自动开始构建软件模型，也不自动构建其架构文档或规格。此文档基于VoiceXML，即用于语音成分规格的标准语言。为解释所接收的命令，其使用可人工修改的语音会话模板，该模板为由程序员使用以映射所接收的命令流和应用程序应提供的应答的人工脚本。为定义应用程序可在由用户发声时识别的话音识别动词短语，开发者应创建“语法”，该“语法”为预期说出的命令的明确表征并且用于将输入限于此类命令，该命令为少量的所允许词序列。

在该专利中展示的系统还包括用于程序员定义“自然语言语法”的机制，该“自然语言语法”允许基于具有与它们自己的短语的模板而容易地针对预期应答类型训练应用程序。此后，程序员必需将用应用程序变量鉴别的说话成分人工映射以便随后处理。最终，为确保此类口语成分被适当鉴别，必需具有声波图和发音的数据库。此文档提供以下机制：获得语音命令并将它们变换成应用程序的输入变量，并因此供应相反情况从而以自生成的语音命令的形式显露输出变量。为此，应用程序依靠“自然语言语法”和“语言模型”的规格，但不同于本发明，其未公开以自由和详尽的方式直接分析自然语言输入以用于自动推断软件模型或应用程序的功能或设计组件的能力。

类似地，US2012/0210296公开了一种创建BPM型(业务过程管理)软件应用程序的方法。该方法使用表示不同的过程相关功能的预先构建的软件模块。这些软件模块被汇编以基于用户选择使用与元数据中的模块相关联的预定义自然语言词语产生所得的软件应用程序。用户可从由系统展现和控制、链接到可用模块的项目的列表中选择过程。用户也可实施列表中初始不可用但被定义为现有模块的组合并且可添加到项目列表的功能。

不同于US2012/0210296，本发明不使用预先构建的过程功能。本发明允许使用自由自然语言，通过创建可实例化作为软件应用程序的模型而从该自由自然语言构建功能性，不仅用于BPM解决方案，而且用于可用自然语言描述的所有种类的解决方案。本发明不暗示一种用于可编译代码生成的方法，也不将结果限于特征的有限列表。US2012/0210296不从语言结构操作；相反，其使用语言促进用户选择功能程序的技术组件。

根据上述内容，并且不论涉及自动开发活动的现有技术如何，仍存在涉及开发寿命周期专家的需要，特别是用于错误调试。以此方式，本发明用基于表示待编写的给定作为过程输入的软件型应用程序情况的类和屏幕的设计自动产生软件的机器来代替编程过程。本发明如下解决工业问题的主要方面：

-其允许在不执行典型的工业任务(诸如构建数据库、将可编译代码编程和形成特定架构)的情况下创建软件应用程序；所有这些通过从规格生成程序代码的那些工具人工或自动地同时执行。本发明在不生成程序代码的情况下，从存储在数据库存储器中的通过将本发明的协议应用到由用户作为输入提供的类和屏幕设计而获得的功能和视觉模型自动产生结果。

-其减小在时间和金钱、技术陈旧、需求短缺方面的高成本，并允许产品灵活且方便地演进。

现有技术报告了是解释器的发明。在软件工业中，解释器不同于编译器或汇编器在于，后者将程序从其以编程语言的描述翻译成系统的机器代码，而解释器仅在必要时翻译，典型地逐条指令翻译并且通常不将此翻译的结果存储为代码。本发明是模型实例化器，因为其不解决来自单独程序指令的实时编译的软件。在本发明中，不需要程序指令，因为程序指令由存储在数据库中的模型代替，该模型在由模型实例化器引擎要求时，通过执行作为引擎一部分编译的各种程序指令，在存储器中创建由这些模型表示的功能。程序流在用户控制下，和模型与其它的反复调用一样，这基于被编译到引擎中的指令发生。

由于本发明的模型实例化器引擎不特别限于解决任何情况，因此其能够将来自任何组的相关模型的任何功能实例化。修改此功能通过向数据库添加模型或从数据库移除模型来完成，无需修改任何已编译程序。这比为新功能创建新程序更容易且更快，并且其不需要程序测试。当使用解释器或编译器解决功能性时，必需测试程序，该活动对每次迭代具有影响，直到产生高质量软件。

词汇表

为使得容易理解在本专利申请中公开的概念，以下是指示在本发明中使用的此类概念中的一些的范围的术语的列表。

最终用户：最后通过所提供的用户界面使用解决方案的活动者。

用户界面：用户可通过其与机器、装置或计算机沟通的媒介。该媒介涵盖用户和系统之间的所有接触点。

软件应用程序：其由两部分构成：描述业务并确定解决方案的功能行为规则的概念模型的集合，以及使得能够在用户将与之交互的用户界面中实质化此功能性的显示模型的集合。

编程：计算机编程应理解为编码、调试和维护计算机程序源代码的过程。源代码以编程语言编写。编程的目的是创建展现出期望行为的程序。除精通待使用的语言、专用算法和形式逻辑之外，编写代码的过程通常需要在不同领域中的知识。编程不必涉及其它任务，诸如应用程序分析和设计(尽管其涉及代码设计)，即使这些任务通常在小型应用程序的开发中融合在一起。

面向对象编程(OOP)范式：其为当前最多使用的编程范式。其中心核心是在称为“对象”的单个实体中数据和处理的组合，因此与其它“对象”实体相关联。传统上，数据和处理已在除设计和软件实施方案之外的领域中被分类。这使得大型开发在可靠性、维护、变化适应和可扩展性方面有问题。在面向对象和特征诸如封装性、多态性或继承的情况下，在任何生产规模中在软件开发方面实现了显著进步。

元类：在OOP范式中，元类是其实例为类的类。在本发明中，该概念以一些特质应用于功能规格协议。

程序代码：其为待由计算机处理、以计算机可解释和执行的语言编写的指令和数据的集合。计算代码可以是以上级语言编写的二进制代码或源代码。

过程语言：其为以结构化编程格式生成的程序代码的名称。该格式基于在接收流程、子例程或功能的名称的组件中的结构化程序代码。

解释器：在计算机科学中，解释器为能够分析和执行其它程序的计算机程序。解释器不同于编译器或汇编器，因为后者将程序从其编程语言形式的描述翻译成系统的机器代码，而解释器仅在必要时翻译，典型地逐条指令翻译并通常它们不存储此翻译。

编译器：编译器为将以编程语言编写的程序翻译成机器语言的计算机程序。该翻译过程称为编译。

系统：在本发明中，应理解为彼此交互以在视觉装置中基于设计规格显露软件应用程序的电子或光电元件的集合。

UI组件：它们是用于给出视觉形式以在屏幕型或类似装置上展现信息的代码部分(HTML或其它)。这些组件称为第三方组件组，并用于软件工业作为软件应用程序开发中的补充。

发明内容

本发明公开一种系统和方法，该方法基于到包括存储器和处理器的电子装置中的逻辑信息结构的输入，在视觉装置中自动产生输出。这些可操作以创建业务过程信息，从而替换通常通过在软件工业中已知的传统编程开发的软件应用程序。

由计算机使用的方法基于设计规格解释并显示软件型应用程序，该设计规格包括这些阶段：

a.通过输入/输出装置120加载功能规格协议(PEF)、视觉规格协议(PEV)和UI资源并将它们存储在数据库存储器130中；

b.基于数据库存储器140中的软件设计规格，验证阶段a的协议并存储功能设计组件和视觉设计组件；

c.基于来自阶段b的功能和视觉设计组件自动创建功能模型和视觉模型，并分别在数据库存储器130、模型MF 135和模型MV 134逻辑结构中存储此类模型；以及

d.通过配置为模型实例化器153的处理器150，遵循在阶段A中存储的协议的规范，来读取、实例化并在输入/输出装置120、应用程序界面123上自动显露与UI资源组合的在阶段c中创建的功能和视觉模型。

另外，本发明包括一种系统，其基于软件设计规格实例化并显露操作软件应用程序，该系统包括：

a.输入/输出装置120，其配置为CDF界面121、CDV界面122、应用程序界面123以输入软件设计规格并展现所得的软件应用程序。

b.连接到输入/输出装置120的中央处理单元(CPU)110，其包括：

-与输入/输出装置120配对的通用存储器140，其与处理器150交互，经配置以易失性方式存储视觉组件、功能组件和UI组件；以及

-经配置通过输入/输出装置120接收至少一个软件设计规格的处理器150；此处理器配置为模型验证器151以针对阶段A的协议验证软件规格，并鉴别所得的软件型应用程序，从而整合功能和视觉模型与UI资源，以及，

此处理器配置为模型实例化器153以在应用程序界面123中显示所得的软件型应用程序；

以及

c.数据库存储器130，其连接到CPU 110，与处理器150配对，经配置将规格视觉协议PEV静态存储到逻辑结构PEV 131中，将功能规格协议PEF静态存储到逻辑结构PEF 132中，并将UI资源静态存储到UI资源逻辑结构133中，而且还经配置将视觉模型动态存储到逻辑结构模型MV 134中，将功能模型动态存储到逻辑结构模型MF 135中，并将对象动态存储到逻辑结构对象136中。

附图说明

图1示出本发明的系统的结构。

图1A示出功能规格PEF协议。

图1B示出视觉规格PEV协议。

图1C示出模型MF的数据库存储器的逻辑结构。

图1D示出模型MV的数据库存储器的逻辑结构。

图1E示出对象的数据库存储器的逻辑结构。

图2示出本发明的方法的阶段。

图2A详细示出阶段A的子阶段。

图2B详细示出阶段B的子阶段。

图2B1示出功能组件和OO型鉴别的示例。

图2C详细示出阶段C的子阶段。

图2C1示出协议PEF在类图中的应用的示例。

图2C2示出协议PEV在屏幕图中的应用的示例。

图2D详细示出阶段D的子阶段。

图3A示出本发明的方法的阶段的附加模式。

图3B示出本发明的方法的阶段的附加模式。

具体实施方式

本发明是一种系统和由计算机应用的方法，该方法允许在数据库存储器中存储表示软件应用程序的详细设计的类模型，并通过实例化此类模型来显露所得的软件型应用程序。如图2所描述，过程通过在数据库存储器中存储软件设计开始，然后使用先前存储在系统中的协议定义来鉴别此设计的组件以解决模型实例化，这最终构成软件型应用程序。在本发明中，模型表示在数据库存储器中实质化的功能或视觉设计组件。

为运行该方法，将与图1中描述的系统类似的系统用于在输入/输出装置120中录入类设计和屏幕。录入的设计被传送到通用存储器并且然后由处理器150处理。该处理器经配置验证、组合和实例化数据库存储器134和135中的现有模型。每个处理功能的结果在输入/输出装置120的屏幕中显示。

图1的系统100的组件如下描述：

1.输入/输出装置120：这是藉以录入软件设计的装置。该装置允许处理器在视觉媒介(尤其为屏幕、投影仪、电视机、打印机、监视器、移动装置)上显示结构，其中在该结构中，用户可录入类和屏幕设计(类似于在图2B中显示的类和屏幕设计)，并依靠以下配置查看所得的软件型应用程序：

a.CDF界面121：其为允许用户基于类图在模型MF 135的逻辑配置中录入软件应用程序的功能设计组件的视觉结构，该功能设计组件存储在数据库存储器130中。

b.CDV界面122：其为允许用户基于与类图相关联的屏幕图在模型MV 134的逻辑配置中加载软件应用程序的视觉设计组件的视觉结构，该视觉设计组件将存储在数据库存储器130中。

c.应用程序界面123：一旦处理器150已将数据库存储器130中可用的功能和视觉模型实例化，该界面向用户示出所得的软件应用程序的视觉结构。

2.CPU 110：其为处理系统100的装置。该装置经结构化以针对对应协议来验证功能和视觉模型，组合UI资源并基于先前步骤实例化软件型应用程序。其包括容许系统的功能和其它组件之间的交换的通用处理器。

a.通用存储器140：其为用作数据库存储器、处理器和输入/输出装置之间的交换装置的手段的易失性存储系统，其根据其配置执行以下功能：

i.MF矩阵142：其为通用存储器的配置，该配置使得能够通过配置为模型实例化器153的与存储在数据库存储器131和132中的协议匹配的处理器150来处理驻留在数据存储器135中的功能模型；

ii.MV 143矩阵：其为通用存储器的配置，该配置使得能够通过配置为模型实例化器153的与存储在数据库存储器131和132中的协议匹配的处理器150来处理驻留在数据存储器134中的视觉模型。

b.处理器150：其为在其中实行所有处理和交换任务的装置。其根据其配置执行以下功能：

i.模型验证器151：其为处理器的配置，主要负责针对驻留在数据库存储器131和132中的协议验证由用户录入的功能模型，并且一旦验证，则分别存储在数据库存储器134和135中。

ii.UI组合器152：其为处理器的配置，主要负责在实例化过程之前组合驻留在数据库存储器133中的UI资源与存储在数据库存储器130中的视觉模型。

iii.模型实例化器153：其为处理器的配置，主要负责实例化已与驻留在通用存储器142和143中的逻辑配置中的UI资源组合的功能和视觉模型，以便在应用程序的界面123中自动显露所得的软件型应用程序。

3.数据库存储器130：其为存储由用户录入和由处理器150在其不同配置中生成的数据的永久性存储器。该存储器包含两个存储配置，即静态配置和动态配置。静态配置存储录入一次以用于处理并且不属于“该情况”的数据。动态配置存储属于“该情况”的在每个情况下录入的数据。

a.静态存储器：

i.PEF 131：数据库存储器130配置，其包含处理器150用来基于视觉规格协议(PEV)验证和实例化在该存储器中定义和录入的功能模型的规则。

ii.PEV 132：数据库存储器130配置，其包含处理器150用来基于视觉规格协议(PEV)验证和实例化在该存储器中定义和录入的功能模型的规则。

iii.UI资源133：数据库存储器130配置，其包含允许处理器150在由用户控制的屏幕上在应用程序的界面123中显示模型的软件组件。

b.动态存储器：

i.模型MV 134：数据库存储器130配置，其包含由用户依靠CDV界面122录入并由处理器150针对视觉规格协议(PEV)验证的功能模型。该存储器由与图1B所示的视觉规格协议的概念相关联的以下逻辑结构构成：

1.与概念ActionLink相关联的配置

a.逻辑结构RenderAction

b.逻辑结构RenderActionEditor

c.逻辑结构RenderAttributeBaseAction

d.逻辑结构RenderBaseViewAction

2.与应用程序(Application)的概念相关联的配置

a.逻辑结构应用程序

3.与AttributeRenderInfo的概念相关联的配置

a.逻辑结构RenderAttribute

b.逻辑结构RenderAttributeBase

c.逻辑结构RenderDiagramView

d.逻辑结构RenderMapView

e.逻辑结构RenderNavBarView

f.逻辑结构RenderObjectReferenceAttribute

g.逻辑结构RenderPivotView

h.逻辑结构RenderReportView

i.逻辑结构RenderWidgetAttribute

4.与ColumnViewModel的概念相关联的配置

a.逻辑结构RenderColumn

5.与Container的概念相关联的配置

a.逻辑结构RenderContainer

6.与ListViewModel的概念相关联的配置

a.逻辑结构RenderFindView

b.逻辑结构RenderGridAggregateColumn

c.逻辑结构RenderGridAttribute

d.逻辑结构RenderGridColumn

e.逻辑结构RenderGridColumnAction

f.逻辑结构RenderGridView

7.与菜单(Menu)的概念相关联的配置

a.逻辑结构Menu

8.与MenuGroup的概念相关联的配置

a.逻辑结构MenuGroup

9.与TreeViewModel的概念相关联的配置

a.逻辑结构RenderRelationView

b.逻辑结构RenderRelationViewAction

c.逻辑结构RenderTreeView

10.与ViewModel的概念相关联的配置

a.逻辑结构PopUpEditor

b.逻辑结构PrintConfiguration

c.逻辑结构RenderBaseView

d.逻辑结构RenderBaseViewInheritance

ii.MF模型135：数据库存储器130配置，其包含由用户依靠界面CDF 121录入的由处理器150针对功能规格协议(PEF)验证的功能模型。该存储器由与图1A所示的功能规格协议概念更多-类(More-Class)象限相关联的以下逻辑结构构成：

1.与域(Domain)的概念相关联的配置

a.逻辑结构Domain

2.与公式(Formula)的概念相关联的配置

a.逻辑结构Fx

b.逻辑结构MatchAttribute

c.逻辑结构MatchFieldStrategy

d.逻辑结构MatchInfo

e.逻辑结构MatchValue

f.逻辑结构MatchValueStrategy

3.与FxCallArgument的概念相关联的配置

a.逻辑结构FxCall

4.与ModelAttribute的概念相关联的配置

a.逻辑结构MoreClassAttribute

5.与ModelClass的概念相关联的配置

a.逻辑结构MoreClass

b.逻辑结构MoreClassInheritance

6.与ModelRelationClass的概念相关联的配置

a.逻辑结构MoreRelationClass

iii.对象136：数据库存储器130配置，其包含用户基于通过软件型应用程序由配置为模型实例化器153的处理器150实例化的模型生成的对象。该存储器由与图1A所示的功能规格协议概念对象-类象限相关联的以下逻辑结构构成：

1.与AttributeValue的概念相关联的配置

a.逻辑结构MoreObjectAttributeValue

b.逻辑结构MoreObjectAttributeValueFileExtended

c.逻辑结构MoreRelationObjectMoreObjectAttributeRelation

2.与Object的概念相关联的配置

a.逻辑结构MoreObject

3.与RelationObject的概念相关联的配置

a.逻辑结构MoreRelationObject

本发明包括所描述的系统和由计算机应用的方法，该方法基于设计规格解释并显露软件型应用程序。参考图2，本发明的方法包括以下阶段：

阶段A、通过输入/输出装置120在逻辑结构PEF 132中加载功能规格协议(PEF)，并在逻辑结构PEV 131中加载具有其对应的UI资源的视觉规格协议(PEV)，并加载来自数据库存储器130的UI资源133。

阶段B、基于类设计，通过界面CDF 121鉴别并存储在类图中详述的功能设计的组件，并在逻辑结构MF矩阵142中将它们临时存储在通用存储器140中。基于与类设计相关联的屏幕设计，鉴别并加载通过界面CDV 122详述的视觉设计组件，并在逻辑结构MV矩阵143中将它们临时存储在通用存储器140中。

阶段C、使用在其作为模型验证器151的配置中的处理器150验证在阶段B中创建的功能和视觉模型，以从存储在通用存储器140中的每个模型创建可以用在阶段A中存储的驻留在数据库存储器130中的协议PEF和PEV编译的模型。将所得的功能模型130在数据库存储器130中分别在其逻辑配置模型MF 134和模型MV 133中存储。

阶段D、从数据库存储器130重获在阶段C中创建的功能和视觉模型以及在阶段A中存储的UI资源，并使用配置为UI组合器152的处理器150将它们存储在通用存储器140中。组合存储在通用存储器140中的UI资源与功能和视觉模型，并使用配置为模型实例化器153的处理器150将编译的模型实例化并在输入/输出装置120、应用程序界面123上显示软件型应用程序的屏幕。通过应用程序界面123获得用户请求，并在数据库存储器140、对象逻辑结构136中添加来自处理器150对应用程序操作的应答的所得对象。

过程中的阶段如下详述：

阶段A、加载协议到存储器中

在该阶段中，如图2A所示，定义两个被称为协议的规范，将该协议加载到数据库存储器130中仅一次。处理器150在所有过程期间以其不同配置使用这些协议：i)功能规格协议(PEF)；以及ii)视觉规格协议(PEV)。

这些协议建立其中处理器150将组合软件类设计图(OO)和屏幕设计图中的所有功能组件以便自动获得操作软件应用程序的模式。

在本发明中，具有其对应的屏幕设计图的类图被视为“该情况”。类设计图表示软件应用程序功能性(由一组功能组件组成)，并且屏幕图表示向其用户显示软件型应用程序的视觉结构(由一组视觉组件组成)。两个协议都如下描述：

子阶段A1、加载功能规格协议(PEF)

该协议是定义处理器150将基于类设计图从现在起在PEF组件上向用户加载的功能组件分配行为的规则，PEF组件确定用于系统100的操作的逻辑结构。定义该协议的功能的架构可在图1A中观察。

根据OO，PEF协议定义指代其实例为类的类的元类(Metaclass)。在该协议中，作为元类的实例的类被称为模型(图1A的实例-类象限)。

通过使用PEF协议，通过一方面将类设计中的隐形语言的意义实例化并另一方面将数学逻辑实例化，获得所得的软件型应用程序的功能性。在“该情况”的语义部分中，通过协议在类图中鉴别的方法(OO)变为类，并且在数学运算中，表示数学功能性的方法(OO)变为公式。在功能规格协议PEF中，如图1A的象限模型-类中展现，存在用于解决语义的三个组件(ModelClass、ModelRelationClass和ModelAttribute)和用于解决数学运算的四个组件(Domain、外部域(External Domain)、Formula和FxCall)。

该协议还定义对象类(来自图1A的象限对象-类)。对象ModelObject和ModelAttributeValue的这些类是系统100用来存储来自实例-对象象限的模型的实例的组件。

PEF组件为属于象限模型-类和对象-类的那些组件。在象限模型-类内存在：ModelClass、ModelRelationClass、ModelAttribute、Formula、Domain和FxCall。它们是一组源于在逻辑结构模型MF 135中存储于数据库存储器130中的功能模型的元类。在象限对象-类内存在：ModelObject和ModelAttribute值。它们是一组产生存储在数据库存储器130、对象逻辑结构136中的系统对象的类。以下是PEF组件的描述：

i.源于软件应用程序功能模型的元类(象限模型-类)

·ModelClass

其为元类组件，因为其实例为模型。该组件模型设计作为OO设计图中的类的结构。Modelclass可得自另一个Modelclass。

示例：我们可创建元类人类实体(Human Entity)(Modelclass)、另一元类人(Person)(得自ModelClass Human Entity的ModelClass)。Person实例可以是自然人(Physical Person)或法人(Legal Person)。Physical Person和Legal Person都是构成元类Person的实例的模型。

·ModelRelationClass

其为从Modelclass继承的元类组件。使Modelclass延伸的功能性向该元类给出将两个Modelclass关联的能力，该能力可为两个类型：相关联(Association)或组成(composition)，如由OO定义。

例如：如果我们取得ModelClass Physical Person和ModelClass Legal Person，则我们可认为Physical Person实例(Juan Pérez)可为Legal Person实例(谷歌公司)的雇员。在此情况下，存在称为“与…相关(is related with)”的ModelRelationClass，其将ModelClass Person与其自身在元模型级链接。该链接可用来表示Physical person和Legal Person之间的雇佣关系，或其也可在ModelClass Physical person和Legal Person中将ModelClass Person特殊化，以便然后创建将从ModelRelationClass“is relatedwith”继承的特殊ModelRelationClass“是…的雇员(is an employee of)”。

·ModelAttribute

其为组成ModelClass的元类组件。ModelClass具有ModelAttribute的列表。ModelAttribute是作为ModelClass的实例创建的模型所包含的属性的表示。

ModelAttribute尤其定义正在产生的属性数据的类型。

协议为ModelAttribute定义三个类型的数据。

·简单ModelAttribute：简单类型为其值实例不涉及ModelObject实例的那些类型。例如：数字数据、文本数据、图像数据。

·ModelAttribute RelationObject：这些属性在其参与ModelRelationClass的ModelClass产物中存在。该类型的属性在其值实例中并根据关系可具有关系对象的一个或多个实例。这确定关系的基数。示例：如果我们具有ModelClass“Person”和ModelClass“条款(Article)”之间的ModelRelationClass，则在ModelClass Person中存在类型RelationObject的ModelAttribute，其将具有作为实例的与Article相关的人；以及相反地：ModelClass Person具有RelationObject型ModelAttribute，其将具有作为实例的与Person相关的条款。

·ModelAttribute ObjectReference：该类型数据类似于先前数据，但其不作为其所属的ModelClass参与关系的产物而得到。属性自身为这样的属性：其知道将适时为其自身组成值的实例的对象的性质。示例：当创建ModelAttribute作为ModelClass的一部分时，其宣告ObjectReference。

·Formula

公式为具有表达式和一组参数以接收来自调用其的模型的信息的独立模型。该公式在执行时将总是向调用其的模型返回值。所得的值可以是作为阵列或多维阵列的一部分的单个实例或多个实例。

功能规格协议定义用来解决在功能上需要执行数学运算的此逻辑的公式组件，该数学运算使用模型实例作为自变量。公式为代数、矩阵和集合运算提供所有数学运算符，并且其允许使用现有自变量作为来自源于图1A的模型-实例象限的模型的实例而定义表达式。使用元类Formula实施暗示数学解的功能性，这不同于其中该类型功能在来自OO模型的类中实施为方法的传统软件设计。例如：计算销售交易总值的公式具有将销售的单位累计并在ModelAttribute实例中返回单个值的代数表达式，其中销售的单位为ModelAttribute实例的集合。

·Domain

Domain是宣告允许选择模型实例的子组的(多组之中的操作)条件的组件。模型实例可在已由处理器150基于PEF协议验证和结构化的数据库存储器130中的对象逻辑结构136中发现，或在未根据协议结构化的外部存储器中发现。因此，Domain如下分类：

内部域(Internal Domain)

这些域在数据库存储器130上在对象136逻辑结构中解析，获得可由其它模型通过公式进行处理的实例的集合。例如：如果存在ModelClass客户端(Client)，则检索存储在数据库中的必须使用Internal Domain的其实例，该检索仅通过ModelClass名称和待检索的实例应符合的任何条件来调用。

External Domain

External Domain是在未根据PEF协议结构化的存储器上解析的域(外部文件中的数据)。在这些情况下，外部域组件具有对对象实例的访问，并且处理器150基于协议将它们结构化，因此它们形成可由内部域访问的空间的一部分。例如，如果存在具有带数据的三个列：名称(name)、年龄(age)和公司(company)的外部文件，为重获它们，必须创建外部域，其规定此类字段属于客户端，以及带有对应的ModelAttribute的列之间的匹配(名称列：ModelAttribute Name，年龄列：ModelAttribute Age，公司列：ModelAttribute Company)。ModelAttribute公司是其中Client与公司相关的RelationObject的类型。

·Fxcall

该组件负责当ModelAttribute实例的值来自Formula时将任何ModelAttribute实例与Formula实例相关联。其为解决公式表达式的估计并向调用其的模型返回结果的模型，从而发送待处理的数学运算符和自变量至处理器150。FxCall更新实例的自变量的值，因此调用的公式请求来自处理器150的解。

ii.产生软件应用程序对象的类(象限对象-类)

·ModelObject

从ModelClass实例化的类的实例称为ModelObject。ModelObject是将用ModelClass建模的对象的实例实质化的具体类。例如：Model Article，其为继而具有具体实例ModelObject“牛奶(milk)”的ModelClass实例。该对象同时为ModelObject实例的实质化。

·ModelAttributeValue

用ModelAttribute建模的模型的实例称为ModelAttributeValue。ModelAttributeValue是其实例表示ModelObject实例的值的具体类。例如：ModelObject“milk”，其用于ModelAttribute名称的ModelAttributeValue为“milk”。

子阶段A2、加载视觉规格协议(PEV)

如图1B所示，该协议定义处理器150将基于屏幕设计图从现在起在PEV组件上向用户加载的视觉组件给予行为的规则。这些组件将确定将在输入/输出装置120、应用程序界面123中显示以操作系统100的视觉结构。定义该协议的视觉展现的架构在图1B中示出。

视觉规格协议PEV定义PEF和PEV组件相关的方式。PEV组件通过输入/输出装置120、应用程序界面123显示一个或多个PEF组件的功能性。

该协议的定义确定可以在视觉装置上生成显示，该视觉装置可操作以产生业务过程信息而不使层架构的设计对每个情况特别，因为该架构嵌入在PEF组件内。

在本发明的另一实施例中，创建与PEF组件无关的PEV组件。例如：包含网站链接的视觉模型。

PEV组件为：应用程序(Application)、ActionLink、AbmViewModel、ListViewModel、TreeViewModel、ReportViewModel。

·Application

Application组件将软件应用程序在视觉上结构化。协议定义Application组件为模型以规定应用程序。应用程序定义菜单(Menu)为将使用户能够访问展现的功能性的最重要方面。Menu为MenuGroup模型和MenuItem模型在树中的集合，其中MenuGroup可同时包含其它MenuGroup或MenuItem。MenuItem在用户点击其时链接待采取的动作。条目与以下可视化模型(ViwModel)中的任一个相关联：AbmViewModel、ListViewModel、TreeViewModel。当用户执行MenuItem时，系统100的处理器150通过应用程序界面123接收此请求，并在同一界面中返回结构，其使得用户能够执行由与MenuItem相关联的PEV组件调用的组件PEF的功能。

·ViewModel

ViewModel组件帮助在视觉装置上显露ModelObject实例。ViewModel组件由使得ViewModel能够根据ModelClass模型(其为来自该模型的实例)和其涉及的ViewModel的类执行动作的ActionLink组件组成。

PEV组件基于ViewModel及其特性定义将在输入/输出装置120、应用程序界面123上显示的布局(模板或视觉布局结构)。

为显示模型实例，存在ViewModel的三个类：AbmViewModel、ListViewModel和TreeViewModel，它们具有不同的特性和布局设置。

(1)AbmViewModel

协议将AbmViewModel组件定义为规定屏幕的呈现的方法，其允许创建、删除或更新ModelObject模型。屏幕呈现根据对应的ModelClass模型显示Modelobject实例的ModelAttributeValue中的全部或部分。

AbmViewModel由ActionLink组件组成，因为其为ViewModel并且其通过ControlViewType组件和AbmViewModel的特殊特性延伸其功能性。

ControlViewType组件根据属性数据的类型显露ModelAttributeValue。这里有用于本发明的实施例的属性类型的列表：

-TextEditor：显露文件类型ModelAttributeValue。

-NumericEditor：显露数字类型ModelAttributeValue。

-DateTimeEditor：显露日期类型ModelAttributeValue。

-ObjectReferenceComboEditor：显露ModelObject选择器类型ModelAttributeValue。

-ObjectReferenceListEditor：显露ModelObject选择器类型ModelAttributeValue。

构成AbmViewModel的ActionLink组件为：

-保存：在交易数据库内保存ModelObject实例。

-取消：关闭由AbmViewModel显示的视觉结构并放弃由用户在modelObject的实例中完成的改变。

-保存和新建：保存ModelObject实例并创建新实例，因此用户填充属性的值，将其在AbmViewModel的视觉结构上展现。

-打印：打印来自正在修改的实例的属性值。

-在本发明的一些实施例中，存在调用其它ViewModel的添加的动作。

AbmViewModel的特殊特性：

·AttributeRenderInfo：该模型用来指示控件的呈现特殊性，该控件表示ModelObject的某个实例属性的值。

·ControlTemplate：控制选择器以呈现ModelAttribute。根据属性数据类型，这可以根据类型的性质以各种方式表示。ControlTemplate为允许指示属性将有效呈现的所有可能选项的概念。

·容器(Container)：在AbmViewModel内，存在容器的结构以便管理视觉装置内的控件布局。在视觉上显示属性的组件中的每个称为控件。容器的该结构采用树的形式，即，容器可包括其它容器。

·ColumnViewModel：在容器内，控件设置在列下面，并且这些控件具有用于它们所包含的控件的内部顺序。

(2)ListViewModel

该协议将ListViewModel组件定义为模型以规定列出ModelObject实例的集合的屏幕呈现。对于在表中示出的ModelObject实例的收集(其中每个ModelAttributeValue配合在单元中)，该屏幕的呈现展现出此ModelObject根据ModelClass模型(其为该模型的实例)具有的ModelAttributeValue，在表中行对应于实例并且列对应于ModelAttribute。

ListViewModel组件由ActionLink组件组成，因为其为ViewModel并且其通过组件SearchViewModel、ColumnViewModel、ObjectReferenceListGridEditor和ListViewModel的特殊特性延伸其功能性。

符合ListViewModel的ActionLink组件为：新建(New)；剪切(Cut)；编辑(Edit)；打印(Print)；执行公式(Execute Formula)。

另外，对于RelationObject列表，出现以下动作：

·NewMTarget：调用指定为关系目标的模型的新ModelObject的创建。

·NewMTarget&Associate：调用指定为关系目标的模型的新ModelObject的创建，并将与关系属性的ModelObject拥有者的关系实质化。

·DeleteMTarget：在关系的实例中，其消除相关的ModelObject以及关系的实例。

·EditMtarget：调用相关的ModelObject的编辑屏幕。

ListViewModel的特殊特性：

·层级视图：其涉及依靠ModelRelationClass模型而相关的对象的图表的层级结构表示。

·线内编辑：支持修改在列表的同一条线中的对象的属性。

(1)TreeViewModel

该协议将TreeViewModel组件定义为模型以指定依靠RelationObject相关的ModelObject树的呈现。该屏幕的呈现基本上为此RelationObject从其相关的ModelClass调用的ModelAttributeValue中的全部或部分的显露。

在TreeNodeModel组件中表示的树节点表示ModelObject的实例和RelationObject的实例，树节点为讨论中的节点及其父节点之间的现有关系。因此，树中的第一级节点将不由RelationObject的任何实例表示，因为它们不涉及任何父节点。

TreeViewModel组件由ActionLink组件组成，因为其为ViewModel并且其通过TreeViewModel的特殊特性延伸其功能性。

符合TreeViewModel的ActionLink组件为：

·New：其根据用于其中正在调用动作的节点的树的显示模型，基于对应的ModelRelationClass，创建新的RelationObject实例。

·删除(Delete)：其消除将当前节点与其父节点链接的RelationObject实例。

·Edit：其编辑将当前节点与其父节点链接的RelationObject实例。

·NewMTarget：其根据用于其中正在调用动作的节点的树的显示模型，调用对应于对应ModelRelationClass模型的关系目标的新ModelObject实例的创建。

·NewMTarget&Associate：与NewMTarget相同，加上其然后创建RelationObject实例以将新ModelObject与由其中调用动作的节点所表示的ModelObject链接。

·EliminateMTarget：其消除由当前节点表示的ModelObject实例。

·EditMtarget：编辑由当前节点表示的ModelObject实例。

TreeViewModel的特殊特性：

·LoadOnDemand：其指示当用户交互使树扩展时树是否应发现并加载其节点。

·ShowExpanded：其指示当使树可视化时，应显示所有的树扩展节点。

·EditOnClick：其指示应在用户点击其时调用由节点表示的对象的编辑。

(4)ActionLink

ActionLink组件定义在ViewModel中可用于针对ModelObject的实例执行的动作。

每个ViewModel子类具有关于在视觉装置上显露的功能的不同的ActionLink列表。

(5)ReportViewModel

ReportViewModel包含必需的规格，使得配置为模型实例化器153的处理器150可与类似于例如报告服务的任何报告递送服务交互。

上述行为是可行的，因为ModelObject实例存储库可与这些服务所实施的查询方法兼容，以此方式使用来自这些技术的显示组件，可以容易地生成并嵌入具有所有必须的报告特征的报告。

子阶段A3、加载UI源

视觉规格协议PEV以这样的方式设计：处理器150可组合视觉组件与UI源。该组合的目的是处理器可迅速使得这些组件可用于对用户界面建模。通过在子阶段A2中加载的PEV协议的ControlViewType的概念这是可能的，该概念与UI源直接链接并来自ViewModel，其指示哪个UI源将在输入/输出装置、应用程序界面123上表示用户界面的特定部分。

UI源是以任何UI语言(例如HTML5)宣称并且其外观可用层叠样式表(css)调整的局部部分。这些资源存储在数据库存储器130、逻辑结构UI资源133中。然后，当设置为UI组合器152的处理器150执行其功能时，其将这些UI资源与驻留在数据库存储器130、逻辑结构模型MV 134中的逻辑结构ControlViewType的实例链接，留下这些可用于展现软件型应用程序的融合模型。

阶段B、鉴别并存储设计组件

描述设计，因为其作为到由本发明涵盖的过程中的输入是重要的。

如图2B所示的设计文档特别涉及两个类型的已知图，以定义功能性和视觉结构，该功能性和视觉结构定义软件型应用程序：

·表示功能设计的类图(220)。这些设计将用于创建功能模型。

·表示所需的视觉设计的屏幕图(221)。这些设计将用于创建视觉模型。

自从功能和屏幕设计的该阶段，以下子阶段发生：

子阶段B1、鉴别功能设计组件

基于表示待解决的逻辑的类设计(220)，列出图中存在的类。基于类图，考虑组件类型是根据OO范式定义来鉴别它们的组件，并根据由在子阶段A1中加载的PEF协议所建立的内容使该组件类型对应于ModelClass组件。如每个组件在图2B1中的示例中所示鉴别每个所鉴别组件的名称，并正如其可在图2C1中的示例中观察来确定对应的PEF组件，类似于这样：

如果图示展现类，则鉴别功能组件类型OO类并确定PEF ModelClass组件对应于该OO类。

如果图示展现类内的属性，则鉴别功能组件类型OO属性并确定PEFModelAttribute对应于该OO属性。

如果图示展现关系，则鉴别功能组件类型OO关系并确定PEFModelRelationClass对应于该OO关系。

如果图示展现类内的方法，则鉴别功能组件类型OO方法并确定：

·如果方法涉及代数数学计算，则其对应于PEF的Formula组件。

·如果方法涉及等效于集合论的数学函数，则其对应于PEF域组件，在其涉及系统外部的数据的情况下该PEF域组件可在外部。

如果图示显露继承，则鉴别功能组件类型OO继承，并确定两个ModelClass之间的继承关系对应于该OO继承，如由PEF协议在象限模型-类中定义。

通过输入/输出装置120、CD界面121，用户加载已鉴别的PEF组件，并且配置为模型验证器151的处理器150将该已鉴别的PEF组件存储在通用存储器140、逻辑结构MF矩阵142中。

阶段B2、鉴别视觉设计组件

参考表示人们希望查看将由配置为模型实例化器153的处理器150自动构建的软件型应用程序并与其交互的方式的屏幕设计，将执行以确定应被创建以对“该情况”显露软件型应用程序的视觉模型的步骤如下描述。

基于PEF组件列表，视觉规格协议在阶段A中加载以鉴别ModelClass类型概念，并创建定义协议PEV的视觉模型(Application、AbmViewModel、ListViewModel、TreeViewModel)，如下：

a.对于每个ModelClass，应创建以下ViewModel：AbmViewModel、ListViewModel。

b.对于每个modelRelationClass，应创建以下ViewModel：ListViewModel、TreeViewModel。

c.为显示所有PEF组件，应为在先前步骤中创建的每个ViewModel创建以下模型：Application模型、MenuViewModel模型、MenuGroup模型和ItemGroup模型。

在本发明的另一实施例中，系统100允许编辑被创建以实现最接近的相似度的视觉模型，其可具有与可用作过程输入的“该情况”对应的屏幕设计。

通过输入/输出装置120、界面CDV 122，用户加载已鉴别的PEF组件，并且配置为模型验证器151的处理器150将它们存储在通用存储器140、逻辑结构MV矩阵143中。

阶段B’、从自然语言生成CF和CD

在本发明的实施例中，阶段B’代替阶段B，如图3A所示。

在该阶段中，用户从自然语言生成CF和CD。例如，使用如在专利申请第15/141,748号中描述，该专利申请的标题为“用于从自然语言自动生成功能架构文档和软件设计和分析规格文档的过程和系统(PROCESS AND SYSTEM FOR AUTOMATIC GENERATION OFFUNCTIONAL ARCHITECTURE DOCUMENTS AND SOFTWARE DESIGN AND ANALYSISSPECIFICATION DOCUMENTS FROM NATURAL LANGUAGE)”，其全部内容作为参考而提出。

在该实施例中，接下来的子阶段如下：

子阶段B’1、获得功能组件

处理器150连接到在专利申请第15/141,748号中鉴别的数据库存储器、逻辑结构172，从“该情况”获得功能组件并将它们存储在MF矩阵142中。

子阶段B’2、识别视觉组件

处理器150浏览在子阶段B’1期间获得的功能组件的列表，并应用在子阶段A2中定义的视觉规格协议PEF。其从每个功能组件获得一个或多个视觉组件，如图2C2所示，并将它们存储在MV矩阵143中。

阶段C、创建功能和视觉模型

在该阶段中，处理器150从通用存储器140、逻辑结构MF矩阵142提取在子阶段B1中创建的PEF组件，并且接下来的子阶段如下：

子阶段C1、鉴别PEF组件并创建功能模型

在该子阶段中，如图2C所示，处理器150鉴别通用存储器140中可用的在子阶段B1中创建的PEF组件，并根据在子阶段A1中加载的协议规定PEF组件。然后，其创建功能模型，该功能模型规定处理器150将用来对用于“该情况”的软件型应用程序实例化的功能。处理器150遵循以下步骤：

1.浏览列表以鉴别应基于用于设计组件的每个OO类型的规格协议创建什么PEF概念，如在子阶段B1中确定的。

2.对于其相关联PEF概念为公式的那些设计概念，处理器150创建以下附加PEF组件：

a.处理器150创建PEF组件FxCall类型，并将其链接到在同一类内使用该Formula的ModelAttribute。

b.如果公式逻辑暗示使用不属于该方法的设计组件拥有者的属性，则处理器150创建PEF概念的Domain类型以定位将充当该Formula的自变量的数据。

处理器150将所存储的功能模型存储在数据库存储器130、逻辑结构模型MF 135中。

当应用功能规格协议PEF时，过程的类设计输入的转换得自该组模型中，然后该组模型由配置为模型实例化器153的处理器150解释。

子阶段C2、鉴别PEF组件并创建视觉模型

在该子阶段中，如图2C2所示，处理器150鉴别通用存储器140中可用的在子阶段B2中创建的PEF组件，并根据在子阶段A2中加载的协议规定PEV概念。此后，其创建视觉模型，该视觉模型规定处理器150将用来使用于“该情况”的软件型应用程序的的展现信息结构在输入/输出装置120、应用程序界面123中显示的功能性。处理器150遵循这些接下来的步骤：

1.浏览基于在视觉规格协议(PEV)中所建立的内容而在子阶段B2中创建的PEF概念的列表。

2.对于在先前阶段中鉴别的每个PEV概念，处理器150根据在PEV协议中所建立的内容创建视觉模型。

3.创建具有表示“该情况”的名称的视觉模型Application类型。

4.创建具有每个设计组件一个的代表性名称和菜单组的视觉模型Menu类型，向该组分配设计组件名称。

5.在每个菜单组内创建两个菜单条目，由设计组件创建的每个视觉模型一个条目。例如：对于类组件1，创建名称为“类(Class)”的Menu组和然后两个Menu条目：一个称为“ABM类1(ABM Class 1)”并且另一个称为“列表类1(List Class 1)”。将每个菜单条目与对应于其名称的视觉模型链接。

编辑视觉模型而不修改视觉模型和功能模型之间的链接。当编辑视觉模型时，根据在阶段A中加载的协议中所建立的内容，在输入/输出装置120中改变布局组件的尺寸和位置，而不更改在相应的视觉模型和功能模型之间存在的链接。

处理器150将视觉模型存储在数据库存储器130、逻辑结构MV模型134中。

阶段C’、结合功能和视觉模型

在本发明的实施例中，阶段C’代替阶段C，如图3B所示。

在该阶段中，人工应用在子阶段A1和A2中定义的协议的准则，结合由用户创建的功能和视觉模型。

依靠输入/输出装置120，用户加载人工创建的功能模型到数据库存储器130、逻辑结构模型MF 135中。

依靠输入/输出装置120，用户加载人工创建的功能模型到数据库存储器130、逻辑结构模型MV 134中。

阶段D、读取功能和视觉模型并将它们实例化为可操作的软件型应用程序

在该阶段中，配置为模型实例化器153的处理器150以构建通用存储器140存储的组合模型为目标而具有对数据库存储器130的访问。组合模型为组合了功能模型MF(基于PEF协议定义)与视觉模型MV(基于每个协议定义)的模型。因此，其表示与任何UI资源133相关联的在应用程序界面123中显示为可由用户访问和操作的软件型应用程序的单个模型中组合的视觉模型的功能性和定义。

由配置为模型实例化器153的处理器150产生的结果依靠用于软件型应用程序的解释和递送服务来显示。当用户在该服务中授权时，首先看到的是用其开始交互的应用程序界面。

在本发明中，解释是作为服务执行并依靠读取组合模型(模型MF+模型MV+UI资源)执行的过程，其解决由用户在输入/输出装置120、应用程序界面123上显示的软件型应用程序中执行的动作。

作为执行系统100的主要结果，可获得：

·在应用程序界面123上显示的软件型应用程序。

·一组用户生成的信息，通过与软件型应用程序交互而创建，通常称为“用户数据”，处理器150将其存储在数据库存储器130、逻辑结构对象136上。

为符合该结果，配置为模型实例化器153的处理器150遵循以下子阶段：

子阶段D1、读取并解释视觉模型MV

模型(功能和视觉模型两者)为结构，该结构涉及在阶段A加载的在数据库存储器130中分别存储在逻辑结构PEF 132和PEV 131中的协议。

在该子阶段中，配置为模型实例化器153的处理器150从数据库存储器130、逻辑结构模型MV 134重获视觉模型，这些视觉模型根据来自在子阶段A2中加载的PEV协议的定义被存储并验证。

一旦已读取视觉模型100，则系统100构造在布局中布置ModelObject和ActionLink的排列的布局结构，并将此结构存储在通用存储器140、逻辑结构UI组件矩阵141中。

子阶段D2、读取并解释功能模型MF

在该子阶段中，作为模型实例化器153的处理器150读取数据库存储器130、逻辑结构模型135的功能模型，该功能模型根据在子阶段A1期间加载的PEF协议上的定义被存储并验证。

来自系统100的处理器150处理三个类型的功能模型：计算模型、数据持久性模型和交互式数据模型：

计算模型：处理来自在运送表达式到解决该表达式的服务的MF储存库中发现的公式类的表达式，通过FxCall以ModelAttribute的实例的形式返回结果。

数据持久性模型：处理由作用于对象储存库136内的域类提供的到数据库存储器130的访问表述，从而执行在储存库MF中发现的那些。

交互式数据模型：依靠用户与其交互的每个ViewModel的ActionLink交互地处理来自应用程序界面123的用户录入数据。

一旦读取功能模型，则系统100的处理器150解释并实例化商业型结构，并将其存储在通用存储器140、逻辑结构UI组件矩阵中，该结构链接到在子阶段D1中创建的视觉结构，其中在实例化的视觉和功能模型之间的链接响应于来自在阶段A中加载的协议的逻辑。

子阶段D3、选择并组合UI资源

UI资源为预先存储在数据库存储器130、UI资源逻辑结构中的软件组件，其在基于视觉模型执行时在应用程序界面123内在屏幕上呈现图形。存在用于处理视觉模型的定义。在软件工业中，不同的UI资源集是可用的，其可结合到系统，如子阶段A3中所示，以便为所得的软件型应用程序供应不同的可视化模型。

为完成每个融合模型，系统100选择来自矩阵MF 142的组件、来自矩阵MV 143的其对应组件以及与所选的MV的类型兼容的UI资源133。配置为UI组合器152的处理器150组合所选的组件，并递送组件需要起作用的组合模型(模型MF+相关联的模型MV)的部分作为用于UI资源的函数的自变量。

以此方式，处理器150在输入/输出装置120上展现组合组件，为针对“该情况”创建的组件中的每个重复过程。显示的组件构成软件型应用程序的操作屏幕，其显示动作按钮、数据捕获单元和在组合模型中包括的其它特征。例如，具有ModelAttribute名称的ModelClass Article在定义具有TextEditor的屏幕以编辑ModelAttribute名称的实例的AbmViewModel中显示。该屏幕定义来自ModelView的每个ActionLink的功能。

视图模型规定其将使用称为“控件文本框(control TextBox)3d”的UI组件以示出名称，并且处于该原因，处理器150组合在UI资源存储器133中存储的已提到的组件以完成组合模型。根据“control TextBox 3d”组件的特性，此组合允许名称文本字段在输入/输出装置120上以3d和彩色外观显示。组件类型TextEditor与UI资源texbox3D组合，并且其链接到ModelAttribute功能，以供处理器150在应用程序界面123上将其中用户可添加具有三维外观的文本并支持文本捕获的框实例化，因此数据可存留到数据库存储器130、逻辑结构对象136中。

子阶段D4、解决调用的ModelClass实例

一旦组合在子阶段D3中完成，则可在通用存储器140、逻辑结构UI组件矩阵中发现将形成所得的软件型应用程序的组合模型。配置为模型实例化器153的处理器150获得来自与向用户展现的组合模型相关联的ModelObject的实例(ModelClass-ViewModel-UI资源)。根据在组合模型中定义的布局，对应于所选实例的AttributeValue发送到输入/输出装置120、应用程序界面123，并且以此方式，软件型应用程序的可操作屏幕向用户展现。

子阶段D5、接收并解决用户请求

一旦在输入/输出装置120、应用程序界面123上显示，则用户通过按压任何按钮、在单元的一个中录入任何数据，或打开任何选项列表，或访问可用的视觉结构中的任一个来进行交互。当这发生时，根据在子阶段A1中加载的协议PEF中定义的内容，配置为模型实例化器153的处理器150通过ActionLink或现有功能性中的任一个执行对应于形成组合模型的功能模型的功能，其中用户对该组合模型进行操作。

子阶段D6、显示更新的ModelClass实例

一旦解决组合模型，设置为模型初始化器153的处理器150产生显露于输入/输出装置120、应用程序界面123的实例更新。处理器150采取新实例并用产生的改变更新输入/输出装置120。

方法应用示例：

给定情况，该情况由与图2C1所示的类图类似的类图和与图2D所示的屏幕图类似的屏幕图构成，该方法的阶段如下运行：

·阶段A、加载协议到存储器中

该阶段被认为是系统的开始，因为其仅是加载协议和最终将UI资源添加到系统的时间。

·阶段B、鉴别并存储设计组件

在该阶段中，采取用于“该情况”的类设计和屏幕设计，并且以下子阶段发生：

(i)子阶段B1、鉴别功能设计组件

对于类图内每个组件，如此应用在子阶段A1中加载的功能规格协议PEF来鉴别对应的PEF组件：

表1

用户通过输入/输出装置120、界面CDF 121从表1录入该列表，列1、2和3(设计组件、OO类型和名称)，并且处理器150将它们存储在通用处理器140、逻辑结构MF矩阵142中。然后，设置为模型验证器151的处理器150读取在子阶段A1中加载的功能规格协议PEF，完成表1的列3和4(PEF概念和待创建的模型的名称)，并用这些数据更新通用存储器140、逻辑结构MF矩阵142。

(ii)子阶段B2、鉴别视觉设计组件

按照屏幕设计中的每个，应用在子阶段A2中加载的视觉规格协议鉴别对应PEV组件，如下：

表2

设置为模型验证器151的处理器150获取驻留在通用存储器140、逻辑结构矩阵MF142上的功能组件的列表，并将其在输入/输出装置120、CDV界面122上显露，正如在表2中的列1和2(功能组件、概念PEF)中所示。处理器150读取在子阶段A2中加载的视觉规格协议PEV，并完成列3和4(PEF概念、待创建的视觉模型)，并用这些数据更新通用存储器140、逻辑结构MV矩阵143。

·阶段C、创建功能和视觉模型

对于来自该示例的阶段B中鉴别的功能和视觉组件，发生以下子阶段：

(iii)子阶段C1、鉴别PEF组件并创建功能模型

处理器150鉴别对应于表1中的列3和4(PEF概念和待创建的模型的名称)的在通用存储器140、MF矩阵142上可用的PEF组件，并且根据在子阶段A1中加载的协议规定PEF概念。其浏览列表、鉴别PEF概念并创建在根据PEF协议定义需要其的那些方法中为数学定义的组件。该规格暗示以鉴别PEF概念和数据库存储器130中的其对应逻辑结构，以便创建功能模型并将它们存储在逻辑结构模型MF 135中。

在该示例中，获得存储在数据库存储器130、逻辑结构模型MF 135中的功能模型的以下列表作为该阶段的结果：

表3

功能模型创建的技术结构可在图2C1中观察，关于对应的PEF协议概念展现了表3中的每个组件。

(iv)子阶段C2、鉴别PEV组件并创建视觉模型

处理器150鉴别对应于表2中的列3和4(PEF概念、待创建的视觉模型)的在通用处理器140、MV矩阵142上可用的PEV组件，并根据在子阶段A2中加载的协议规定PEV概念。

在该示例中，获得存储在数据库存储器130、逻辑结构模型MV 134中的视觉模型的以下列表作为该阶段的结果：

表4

·阶段D、读取功能和视觉模型并将其实例化为软件型应用程序

子阶段D1、读取并解释视觉模型MV

在子阶段D1中指出的本发明的过程基于来自表4中的示例的列表执行。

子阶段D2、读取并解释功能模型MF。

在子阶段D2中指出的本发明的过程基于来自表3中的示例的列表执行。

子阶段D3、选择并编译UI资源

组合所选的UI资源以显示屏幕设计所需的屏幕，直到实现与图2D所示的视觉设计类似的视觉设计。

子阶段D4、解决调用的ModelClass实例

当用户操作应用程序界面时，系统通过执行来自本发明的在子阶段D4中列出的动作进行响应。

当用户与示例的所得应用程序交互时产生以下子阶段：

子阶段D5、接收并解决用户请求。

子阶段D6、显露更新的ModelClass实例。

必须理解，本发明不限于所描述和例示的实施例，因为对于本领域技术人员将明显的是，存在不背离仅由所附权利要求定义的本发明的实质的不同的变化和可能的修改。

Claims (11)

1.一种基于软件设计规格自动实例化并显示软件型应用程序的由计算机实现的方法，包括以下阶段：

a.依靠输入/输出装置120加载功能规格协议(PEF)、视觉规格协议(PEV)和UI资源，并将所述功能规格协议(PEF)、所述视觉规格协议(PEV)和所述UI资源存储在数据库存储器130中；

b.基于所述数据库存储器140上的软件设计规格，针对阶段a的协议鉴别、验证并存储功能和视觉设计组件；

c.基于在阶段b中鉴别的所述功能和视觉设计组件自动创建功能和视觉模型，并且分别在数据库存储器130、逻辑结构模型MF 135和模型MV 134中存储此类模型；以及

d.使用设置为模型实例化器153的处理器150，遵循来自在阶段A中存储的协议的规范，读取、实例化并在输入/输出装置120、应用程序界面123上自动显示与UI资源组合的在阶段c中创建的所述功能和视觉模型。

2.根据权利要求1所述的方法，其中阶段b包括以下子阶段：

a.基于从存储器或输入装置加载的类设计鉴别所述功能设计组件；以及

b.基于从存储器或输入装置加载的所述屏幕设计鉴别所述视觉设计组件。

3.根据权利要求1所述的方法，其中阶段c包括以下子阶段：

a.通过中央处理单元处理功能规格协议(PEF)以鉴别其组件；以及

b.通过中央处理单元处理视觉规格协议(PEV)以鉴别其组件并创建视觉模型，此类视觉模型将存储在数据库存储器中。

4.根据权利要求1所述的方法，其中阶段d包括以下子阶段：

a.通过中央处理单元读取并处理视觉模型；

b.通过中央处理单元读取并处理功能模型；

c.通过中央处理单元处理功能模型，以选择所述用户的界面组件并与所述界面组件组合；

d.通过中央处理单元处理功能模型的所述组件，以解决由所述用户通过与所述输入/输出装置交互而调用的所述元类的所述实例；

e.接收并解析通过所述输入/输出装置发送的用户请求，并依靠中央处理单元处理所述用户请求；以及

f.在显示装置上示出更新的元类实例。

5.根据权利要求2所述的方法，其中子阶段a包括以下步骤：

a.通过中央处理单元处理存储在所述存储器中的所述功能图，以鉴别包括在此图中的所述类；以及

b.鉴别每个类的所述名称并将所述名称存储在所述数据库存储器中。

6.根据权利要求2所述的方法，其中子阶段b包括以下步骤：

a.基于应用所述视觉规格协议鉴别的所述类来创建视觉模型，并将所述视觉模型存储在所述数据库存储器上；以及

b.在需要的情况下，使用所述输入/输出装置编辑所创建的所述视觉模型的外观并将所述视觉模型的所述外观存储在所述数据库存储器中。

7.根据权利要求3所述的方法，其中子阶段a包括以下步骤：

a.依靠中央处理单元处理功能模型的所述列表，以遵循加载到所述永久性存储器中的所述功能规格协议，为所述组件中的每个创建包括在此类功能模型中的所述对象；以及

b.依靠中央处理单元处理与数学公式相关联的所述功能图的所述组件，以创建使得能够执行此公式的额外组件，并将所述额外组件存储在所述数据库存储器中。

8.根据权利要求3所述的方法，其中子阶段b包括以下步骤：

a.依靠中央处理单元处理存储在所述数据库存储器中的功能概念的所述列表，以便为每个功能组件定义来自视觉规格协议(PEV)的概念；

b.为每个功能概念创建视觉模型并将所述视觉模型存储在所述数据库存储器中；

c.使用代表性情况名称为所述应用程序创建视觉模型，并将所述视觉模型存储在所述数据库存储器中；以及

d.使用代表性名称和菜单组为所述设计组件中的每个创建菜单型视觉模型，向所述组分配所述设计组件名称，并将所述菜单型视觉模型存储在所述数据库存储器中。

9.一种基于软件设计规格实例化并显露操作软件型应用程序的系统，包括：

a.输入/输出装置120，其设置为CDF界面121、CDV界面122和应用程序界面123以便录入软件设计规格并显示所述所得的软件型应用程序；

b.连接到所述输入/输出装置120的中央处理单元(CPU)110，所述中央处理单元(CPU)110包含：

-与输入/输出装置120通信的通用存储器140，所述通用存储器140与处理器150交互，设置成以易失性方式存储所述功能和视觉组件以及UI组件；以及

-设置成依靠输入/输出装置120接收至少一个软件设计规格的处理器150；此处理器设置为模型验证器151以针对来自阶段A的所述协议验证所述软件设计规格，并鉴别所述对应的功能和视觉模型；

此处理器设置为UI组合器152以组合所述所得的软件型应用程序，结合功能和视觉模型与UI资源；以及

此处理器设置为模型实例化器153以在所述应用程序界面123上显示所述所得的软件型应用程序；

以及

c.数据库存储器130，所述数据库存储器130连接到CPU 110，与处理器150配对，经配置将视觉规格协议PEV静态存储在逻辑结构PEF 132中并将UI资源静态存储在UI资源的逻辑结构133中，而且还设置成将视觉模型动态存储在逻辑结构模型MV 134内、将功能模型动态存储在逻辑结构模型MF 135中并将对象动态存储在逻辑结构对象136中。

10.根据权利要求9所述的系统，其中所述中央处理单元的特征在于：

a.重获存储在所述输入/输出装置中的所有设计模型，并针对在所述永久性存储器中加载的所述功能验证协议(PEF)处理此类设计模型的验证；

b.重获存储在所述输入装置中的用户界面的所述设计模型，并且针对在所述永久性存储器中加载的所述视觉验证协议(PEV)处理用户界面的此类设计模型的验证；

c.处理功能模型的所述解释并将所述功能模型的所述解释存储在所述数据库存储器中；

d.处理所述视觉模型的所述解释并将所述视觉模型的所述解释存储在所述数据库存储器中；

e.从所述数据库存储器重获所述功能模型和视觉模型，并在所述功能模型和视觉模型之间实行组合和交互处理，创建用户界面，在所述永久性存储器中存储此类界面，并在所述输入/输出装置上显示所述软件型应用程序。

11.根据权利要求9所述的系统，其中所述输入装置的特征在于：

a.允许将功能图录入到通用存储器中，所述功能图将由所述中央处理单元重获以创建功能模型；

b.允许将屏幕设计录入到通用存储器中，所述屏幕设计将由所述中央处理单元重获以创建视觉模型。