CN114398030A - 用于任意软件逻辑建模的系统和方法 - Google Patents

Abstract

根据一些实施例，任意软件逻辑建模（“ASLM”）数据源可以存储与单元相关联的电子记录，各电子记录包括单元标识符、一个或更多个识别标签、上下文数据、单元参数、单元变量以及内部逻辑。ASLM平台可以表达逻辑块等级下的系统要求，并且，根据系统要求而建立作为自包含实体和连接的逻辑块（所建立的逻辑块用图形表示系统逻辑）。然后，ASLM平台可以自动地对系统逻辑显式地进行转换，以输出与语言无关的公共设计信息交换模型信息。ASLM平台还可以转化且维持系统要求、公共设计信息交换模型信息以及所生成的代码之间的可追踪性。

Description

用于任意软件逻辑建模的系统和方法

背景技术

在软件设计中，通常使用诸如函数、程序或例行程序之类的软件源代码来实现功能性。对于程序设计和面向对象的设计两者都是正确的，然而，在后者中，这些通常被称为“方法”。如本文中所使用的，这些实体统称为“函数”。可以使用函数，例如，以实现像单一的数学运算那么简单的低级功能性和对大型系统的构件进行控制的高级功能性。如本文中所使用的，术语“单元”可以指与函数相似的软件单元。注意到，单元不一定基于源代码，而是可能代之而基于模型，以表示类似的范围的功能性的分区。对单个单元和/或大量单元的任何给定的任意结构的内部逻辑（例如，算法）手动地进行建模的过程可能是耗时、易于出错且昂贵的任务。此外，可能难以保持对高级要求和低级要求以及那些要求如何映射到各种函数和/或单元的追踪。因此，存在对复杂的长期使用的系统（例如，诸如安全关键航空电子设备和地面系统软件）进行维持、逐步改进、增强、转换以及再创新的显著的困难及相关联的成本。

注意到，没有单个现有的基于模型的设计系统能有效地解决这些问题和挑战。一般而言，基于模型的设计工具分成两大类：1）用于反应式系统（诸如，实时控制系统）的工具和2）用于常规系统的工具。用于反应式系统的工具针对特定种类的应用。它们倾向于具有极其受约束和限制的建模构造，且因而，可能不适合用于复杂的交互式信息系统。用于常规系统的工具通常能够处置交互式系统，但其设计原理一般专注于面向对象的设计。因此，用于常规系统的工具缺乏全面地、高效地且有效地支持复杂的长期使用的安全关键系统的能力。注意到，复杂的长期使用的安全关键系统可以具有如下的特征：严格的认证要求和在生产线的整个寿命期间释放的变形，其在初始释放之后的多年仍然需要被维护。不存在为复杂的长期使用的安全关键系统中来自过去的知识的积累及积累和针对未来几年内的将来产品的变革性再创新搭建桥梁的能力。如常在基于统一建模语言（“UML”）的建模中使用的活动图仅在使用高度分散的类别来从头开始设计新的软件系统时才有用，并且，对于现有的任意逻辑，可能没有帮助。

因此，以自动且准确的方式促进任意软件逻辑建模将会是期望的。

发明内容

根据一些实施例，任意软件逻辑建模（“ASLM”）数据源可以存储与单元相关联的电子记录，各电子记录包括单元标识符、一个或更多个识别标签、上下文数据、单元参数、单元变量以及内部逻辑。ASLM平台可以表达逻辑块等级下的系统要求，并且，根据系统要求而建立作为自包含实体和连接的逻辑块（所建立的逻辑块用图形表示系统逻辑）。然后，ASLM平台可以自动地对系统逻辑显式地进行转换，以输出与语言无关（language agnostic）的公共设计信息交换模型信息。ASLM平台还可以转化且维持系统要求、公共设计信息交换模型信息以及所生成的代码之间的可追踪性。

一些实施例包含：用于访问ASLM数据源的部件，该ASLM数据源存储与单元相关联的电子记录，各电子记录包括单元标识符、一个或更多个识别标签、上下文数据、单元参数、单元变量以及内部逻辑；用于经由ASLM平台的计算机处理器而表达逻辑块等级下的系统要求的部件；用于根据系统要求而建立作为自包含实体和连接的逻辑块的部件，所建立的逻辑块用图形表示系统逻辑；用于自动地对系统逻辑显式地进行转换以输出与语言无关的公共设计信息交换模型信息的部件；以及用于转化且维持系统要求、公共设计信息交换模型信息以及所生成的代码之间的可追踪性的部件。

本文中所公开的一些实施例的一些技术优势是以自动且准确的方式促进任意软件逻辑建模的改进的系统和方法。

本发明提供一组技术方案，如下：

1．一种促进任意软件建模逻辑（“ASLM”）处理的系统，包含：

ASLM数据源，其存储与单元相关联的电子记录，各电子记录包括单元标识符、一个或更多个识别标签、上下文数据、单元参数、单元变量以及内部逻辑；以及

ASLM平台，其耦合至所述ASLM数据源，包括计算机，所述计算机被编程为：

（i）表达逻辑块等级下的系统要求；

（ii）根据系统要求而建立作为自包含实体和连接的所述逻辑块，所述所建立的逻辑块用图形表示系统逻辑；

（iii）自动地对所述系统逻辑显式地进行转换，以输出与语言无关的公共设计信息交换模型信息；以及，

（iv）转化且维持所述系统要求、公共设计信息交换模型信息以及所生成的代码之间的可追踪性。

2．根据技术方案1所述的系统，其中，系统要求包含低级要求和高级要求中的至少一个，并且，所述单元参数定义外部单元接口和对本体的追踪，以允许软件构件接口的自动转换。

3．根据技术方案1所述的系统，其中，所述ASLM数据源中的至少一个电子记录表示块实体，所述块实体包括块标识符、一个或更多个识别标签、变元、块参数、块变量以及动作。

4．根据技术方案1所述的系统，其中，所述系统逻辑包括以下项中的至少一项：控制节点、循环节点、合并节点、进入节点、退出节点以及空节点。

5．根据技术方案1所述的系统，其中，所述ASLM平台将进一步运行扩展过程。

6．根据技术方案5所述的系统，其中，所述扩展过程包括：

将父块实体的父块变量提升至单元变量；

针对嵌套子逻辑中的块实体和控制节点而对变元进行重新映射；

使嵌套子逻辑的进入节点和退出节点与单元内部逻辑中的控制节点合并；

将父块识别标签从高到低的可追踪性的映射注销；

将父块标识符从数据字典注销；以及

释放所述父块实体。

7．根据技术方案1所述的系统，其中，所述ASLM平台将进一步运行抽象化过程。

8．根据技术方案7所述的系统，其中，所述抽象化过程包括：

识别待抽象化的逻辑的子区段；

创建新的块实体，并且，在数据字典中注册块标识符；

嵌套逻辑的所述子区段，而作为所述新的块实体的动作；

将所述嵌套块实体连接至其中逻辑的所述子区段起初所连接的位置；

针对所述嵌套块实体而建立变元；

针对所述嵌套块实体而建立块参数；

针对所述嵌套块实体而建立块变量；以及

针对所述嵌套块实体而建立识别标签，并且，在高到低的可追踪性的映射中，注册所述块实体。

9．根据技术方案1所述的系统，其中，所述ASLM平台将进一步运行分裂过程。

10．根据技术方案9所述的系统，其中，所述分裂过程包括：

使嵌套块实体抽象化，以用于分裂成新的单元；

创建新的单元，并且，在数据字典中注册单元标识符；

针对所述新的单元而建立单元参数；

针对所述新的单元而建立单元变量；

将所述嵌套块实体的所述嵌套子逻辑转移至所述新的单元；

使封装于所述新的单元中的块实体和控制节点一般化；

针对所述新的单元而建立识别标签，并且，在高到低的可追踪性的映射中，注册所述新的单元；

引用所述新的单元而对所述嵌套块实体进行更新；

对所述嵌套块实体的识别标签进行更新，并且，对所述高到低的可追踪性的映射中的所述块实体进行更新，并且，针对原始单元而重复该更新过程。

11．根据技术方案1所述的系统，其中，所述ASLM平台将进一步运行合并过程。

12．根据技术方案11所述的系统，其中，所述合并过程包括：

识别引用待合并的单元的所述组合的单元中的块实体；

使父块实体的块变量扩展，以包括来自所述待合并的单元的单元变量；

将所述待合并的单元的内部逻辑转移至所述父块实体的嵌套子逻辑；

针对合并至所述嵌套子逻辑中的块实体和控制节点而对变元进行重新映射；

对所述嵌套父块实体的识别标签进行更新，且对高到低的可追踪性的映射中的父块标识符的注册进行更新，并且，针对所述组合的单元而重复该更新过程；

将从所述待合并的单元的识别标签从所述高到低的可追踪性的映射注销；

将所述待合并的单元的单元标识符从数据字典注销；以及

释放已合并至所述组合的单元中的所述单元。

13．一种促进任意软件建模逻辑（“ASLM”）处理的计算机化方法，包含：

访问ASLM数据源，其存储与单元相关联的电子记录，各电子记录包括单元标识符、一个或更多个识别标签、上下文数据、单元参数、单元变量以及内部逻辑；

经由ASLM平台的计算机处理器而表达逻辑块等级下的系统要求；

根据所述系统要求而建立作为自包含实体和连接的所述逻辑块，所述所建立的逻辑块用图形表示系统逻辑；

自动地对所述系统逻辑显式地进行转换，以输出与语言无关的公共设计信息交换模型信息；以及

转化且维持所述系统要求、公共设计信息交换模型信息以及所生成的代码之间的可追踪性。

14．根据技术方案13所述的方法，其中，系统要求包含低级要求和高级要求中的至少一个。

15．根据技术方案13所述的方法，其中，所述ASLM数据源中的至少一个电子记录表示块实体，所述块实体包括块标识符、一个或更多个识别标签、变元、块参数、块变量以及动作。

16．根据技术方案13所述的方法，其中，所述系统逻辑包括以下项中的至少一项：控制节点、循环节点、合并节点、进入节点、退出节点以及空节点。

17．根据技术方案13所述的方法，其中，所述ASLM平台将进一步运行以下项中的至少一项：扩展过程、抽象化过程、分裂过程以及合并过程。

18．一种非暂时性计算机可读介质，其存储指令，所述指令在由计算机处理器运行时，促使所述计算机处理器以执行用于促进任意软件建模逻辑（“ASLM”）处理的方法，所述方法包含：

访问ASLM数据源，其存储与单元相关联的电子记录，各电子记录包括单元标识符、一个或更多个识别标签、上下文数据、单元参数、单元变量以及内部逻辑；

经由ASLM平台的计算机处理器而表达逻辑块等级下的系统要求；

根据所述系统要求而建立作为自包含实体和连接的所述逻辑块，所述所建立的逻辑块用图形表示系统逻辑；

自动地对所述系统逻辑显式地进行转换，以输出与语言无关的公共设计信息交换模型信息；以及

转化且维持所述系统要求、公共设计信息交换模型信息以及所生成的代码之间的可追踪性。

19．根据技术方案18所述的介质，其中，所述系统要求包含低级要求和高级要求中的至少一个。

20．根据技术方案18所述的介质，其中，所述ASLM数据源中的至少一个电子记录表示块实体，所述块实体包括块标识符、一个或更多个识别标签、变元、块参数、块变量以及动作。

21．根据技术方案18所述的介质，其中，所述系统逻辑包括以下项中的至少一项：控制节点、循环节点、合并节点、进入节点、退出节点以及空节点。

22．根据技术方案18所述的介质，其中，所述ASLM平台将进一步运行以下项中的至少一项：扩展过程、抽象化过程、分裂过程以及合并过程。

附图说明

图1是可以根据一些实施例而提供的系统的高级框图。

图2是根据一些实施例的促进任意软件逻辑建模的方法。

图3图示根据一些实施例的单元。

图4图示根据一些实施例的块实体。

图5是根据一些实施例的控制节点和控制流网络。

图6是根据一些实施例的发放安全通行证的示例。

图7是根据一些实施例的内部逻辑模型。

图8图示根据一些实施例发放具有嵌套逻辑的安全通行证。

图9是根据一些实施例的针对嵌套块实体的扩展和抽象化的示例。

图10是根据一些实施例的用于使嵌套块实体扩展的方法。

图11是根据一些实施例的用于使嵌套块实体抽象化的方法。

图12是根据一些实施例的使单元分裂和合并的示例。

图13是根据一些实施例的用于使单元分裂的方法。

图14是根据一些实施例的用于使单元合并的方法。

图15是根据一些实施例的连锁的模型单元过程。

图16是根据一些实施例的设备或平台的框图。

图17是根据一些实施例的任意软件逻辑建模数据库的表格部分。

图18是根据一些实施例的显示。

具体实施方式

在下文的详述中，陈述许多具体细节，以便提供对实施例的透彻理解。然而，本领域普通技术人员将理解到，可以不利用这些具体细节来实践实施例。在其他实例中，尚未详细地描述众所周知的方法、程序、构件以及电路，以便不使实施例难理解。

图1是根据一些实施例的系统100的高级体系结构。系统100包括任意软件逻辑建模（“ASLM”）数据源110，ASLM数据源110给ASLM平台150提供信息。ASLM数据源110中的数据可以包括例如关于软件构件的信息、应用、高级要求（“HLR”）文档、低级要求（“LLR”）文档、软件代码等。

根据一些实施例，ASLM平台150可以访问ASLM数据源110，并且，促进软件元素的创建和/或操纵。根据一些实施例，ASLM平台150的图形用户界面（“GUI”）155可以与远程用户装置170交互，以自动地对这些软件构件执行操作。如本文中所使用的，术语“自动地”可以指例如能够几乎无人为干预地执行的动作。

如本文中所使用的，装置（包括与系统100相关联的装置和本文中所描述的任何其他装置）可以经由可以作为以下的通信网络中的一个或更多个的任何通信网络而交换信息：局域网（“LAN”）、城域网（“MAN”）、广域网（“WAN”）、专有网络、公用交换电话网络（“PSTN”）、无线应用协议（“WAP”）网络、蓝牙网络、无线LAN网络以及/或诸如互联网、内联网或外联网之类的互联网协议（“IP”）网络。注意到，本文中所描述的任何装置都可以经由一个或更多个这样的通信网络而通信。

ASLM平台150可以将信息存储至诸如计算机ASLM数据源110和/或用户平台170之类的各种数据源中，且/或从各种数据源检索信息。各种数据源可以被本地存储，或存在于远离ASLM平台150的位置。虽然在图1中示出单个ASLM平台150，但可以包括任何数量的这样的装置。此外，可以根据本发明的实施例而使本文中所描述的各种装置组合。例如，在一些实施例中，ASLM平台150和一个或更多个数据源可以包含单个设备。可以由一组网络化设备（诸如，与基于云或分布式处理的体系结构相关联的那些网络化设备）执行ASLM平台150的功能。

系统100的元件可以运行以实现本文中所描述的任何实施例。例如，图2图示促进任意软件逻辑建模的方法，可以由关于图1而描述的系统100的元件中的一些或全部执行任意软件逻辑建模。本文中所描述的流程图并非意指对于步骤的固定顺序，以及本发明的实施例可以按可行的任何顺序实践。注意到，本文中所描述的任何方法都可以由硬件、软件、手动地通过GUI或这些途径的任何组合执行。例如，计算机可读存储介质可以在其上存储的指令，当由机器运行时，这些指令引起根据本文中所描述的任何实施例的性能。

在S210，ASLM平台可以访问ASLM数据源，该ASLM数据源存储与单元相关联的电子记录，各电子记录包括单元标识符、一个或更多个识别标签、上下文数据、单元参数、单元变量以及内部逻辑。根据一些实施例，ASLM数据源中的至少一个电子记录可以表示块实体，块实体包括块标识符、一个或更多个识别标签、变元、块参数、块变量以及动作。根据一些实施例，ASLM数据源可能既不存储本文中所描述的所有的信息元素，也不全面地存储系统构件或完整系统的所有单元。

在S220，系统可以经由ASLM平台的计算机处理器而表达逻辑块等级下的系统要求。系统要求可以表示例如低级要求（“LLR”）和/或高级要求（“HLR”）。在S230，系统可以根据系统要求而建立作为自包含实体和连接的逻辑块，所建立的逻辑块用图形表示系统逻辑。如本文中所使用的，短语“系统逻辑”可以与例如控制节点、循环节点、合并节点、进入节点、退出节点以及/或空节点相关联。

在S240，系统可以自动地对系统逻辑显式地进行转换，以输出与语言无关的公共设计信息交换模型（“CDIM”）信息。例如，可以使用CDIM标准，以提供关于与所追踪到的本体、所追踪到的HLR、数据类型、变量以及/或接口相关联的构件或功能元件的公共设计信息。在S250，系统可以转化且维持系统要求、公共设计信息交换模型信息以及所生成的代码之间的可追踪性。

因而，本文中所描述的一些实施例可以提供方法和计算机程序工具，以使用块实体来在单个编程单元内且/或跨多个编程单元对任意软件逻辑进行建模。块实体是基本软件构建块，其旨在实行一个动作或多个动作，以满足软件中赋予的目的。可以定义至少一个块实体，从而：实现一个动作或多个动作、表达一个低级要求或多个低级要求的至少一个第一方面、维持对更高级的要求的可追踪性、以及提供与其他块实体交互的接口。可以通过控制流网络而将一个块实体或多个块实体连接，从而：控制块实体当中的动作、表达一个低级要求或多个低级要求的至少一个第二方面。此外，可以维持对更高级的要求和软件测试的可追踪性，从而针对一个单元或大量单元而形成任何给定的任意结构的软件逻辑。然后，可以用所选择的编程语言从模型生成软件代码。

本文中所描述的一些实施例可以与诸如图3中所图示的单元300之类的单元相关联。注意到，除了可以针对具体应用而使用的任何传统元素（诸如，未在图3中示出的注释）之外，图3还示出可以组成单元的一些基本元素。可以遵循在定义的软件设计标准下指定的命名约定而识别所有的基本元素，其中，定义的软件设计标准特定于问题域或作为对于工具的通用标准。

单元标识符310可以表示用于显式地识别单元300的预期的功能性的描述性名称。只要针对单元的单元标识符310在将当前单元封装的体系结构元素的范围内是唯一的，则它不必是全局唯一的。定义的软件设计标准可以对标识符唯一性强加额外的要求。一个或更多个识别标签320可以显式地维持单元标识符310及单元300本身对更高级的要求（包括推导出的要求）的可追踪性。识别标签320可以全局地唯一，或在它所追踪的要求的等级的范围内唯一（如果如此指定在定义的软件设计标准中）。单元300还可以包括上下文数据330，上下文数据330用于显式地指定对本单元的外部的实体的依赖性。上下文数据还可以包括单元所属的类别或包的数据成员或变量或全局变量等等。

单元300还可以包括单元参数332，单元参数332用于表示预计将要被单元300接收且输出的形式数据项。注意到，单元参数332可以与针对函数而定义的参数相似。单元参数332可以定义外部单元接口。因而，单元参数332的个体参数可以按与识别标签320用于显式地维持单元标识符310对更高级的要求的可追踪性的方式类似的方式对本体追踪（未示出）。对于作为软件构件的外部接口而暴露的软件单元，对本体的单元参数的可追踪性可能是重要的。在维持可读性（针对人类）、接口完备性以及软件完整性的同时，该可追踪性可以允许软件构件接口的转换（例如，自动地）。单元变量334（包括任何相关联的单元声明）可以表示仅旨在用于在单元300内使用的变量。单元变量334可以在以下这点上与单元参数332类似：它们在单元300内的任何位置可以是可访问的。单元300还可以包括内部逻辑340，内部逻辑340表示旨在由单元300实行的特定功能性。内部逻辑340可以由连接对于单元300的块实体的控制流网络表示。

单元标识符310、一个或多个识别标签320以及内部逻辑340可以表示单元300的必需元素。不具有显式上下文数据330的单元300可以具有隐式“空”上下文。对于单元参数332和单元变量334，可能是一样正确的。如果源代码用作主档案，则可以根据设计标准而使用语言特征，以表示单元300及其元素的定义。

本文中所描述的一些实施例可以与诸如图4中所图示的块实体400之类的块实体相关联。除了能够针对具体应用而使用的任何传统元素（诸如，未在图4中示出的注释）之外，图4还示出可以组成块实体的基本元素。可以遵循在定义的软件设计标准下指定的命名约定而识别所有的基本元素，其中，定义的软件设计标准特定于问题域或作为对于工具的通用标准。

块实体400可以包括块标识符410，块标识符410是用于显式地识别块实体400的预期的功能性的描述性名称。针对块单元的块标识符410只要在将当前单元封装的体系结构元素的范围内是唯一的，就可能不需要是全局唯一的。这意指着，通常，当前单元内的唯一性是不足的。定义的软件设计标准可以对标识符唯一性强加额外的要求。

块实体400可以包括一个或更多个识别标签420, 识别标签420用于显式地维持块标识符410及块实体400本身对更高级的要求（包括推导出的要求）的可追踪性。从概念上讲，针对块的识别标签420可能并非与针对单元的识别标签不同。可以使用块变元430来表示传递至块实体400和从块实体400传递的具体数据项。具体数据项是实质上从单元上下文、单元参数以及单元变量的所选择项，以满足块实体400的需要。变元430能够被输入、输出或同时输入输出。可以使用块参数432来表示预计将要被块实体400接收且输出的形式数据项。块参数432可以与针对函数而定义的参数相似。使用块变元430和块参数432的组合的目的可以是，使块动作440与环境上下文隔离，使得动作的实现方案能够更一般化。该一般化可以允许自动化模型转换。在源代码（手动地写或从模型生成）中，模型参数432能够隐式地嵌入在块动作中。注意到，可以在块变元430与参数432之间建立映射。多个参数432可以被映射到单个变元430（由单个变元430实现），但仅单个变元430能够映射到（实现）单个参数432。即，多个变元430不能映射到单个参数432。块变量434（包括任何相关联的块声明）表示仅旨在用于在块实体400的范围内使用的变量，而不管单元中的变量的声明的实际位置。

动作440表示旨在由块实体400实行的功能性。根据一些实施例，常规块实体400不能仅具有决策控制动作440（除了充当控制流网络中的节点的块实体以外）。常规块实体400中的任何决策控制动作440都必须伴随有非决策控制动作，其中，非决策控制动作受决策控制动作440控制。可以按照块参数432和块变量434而表达动作440。可以仅使用块参数432来实行数据交换。注意到，诸如单元参数和单元变量之类的外部数据项可能对块动作440不可见。不具有任何给定的种类的显式元素的块实体400具有相同种类的隐式空元素（除了必须提供的块标识符410和必须提供至少一个的识别标签420之外）。如果源代码用作主档案，则可以根据设计标准而使用语言特征，以表示块实体400的边界和块元素。注意到，按照定义，块实体400不可能是单元，且反之亦然。即使元素为隐式的，块实体400也可以始终具有变元430的种类的元素，而单元不具有任何变元。

图5图示500根据一些实施例的控制节点（包括节点标识符510、识别标签520、变元530、节点参数532、节点变量534以及决策控制动作540）和控制流网络。除了常规块实体（未示出）和诸如能够针对具体应用而使用的注释（未示出）之类的任何传统元素之外，图5还示出可以组成控制流网络本身的基本元素。可以遵循在定义的软件设计标准下指定的命名约定而识别所有的基本元素，其中，定义的软件设计标准特定于问题域或作为对于工具的通用标准。控制流网络存在于单元内。控制流网络可以暴露于单元上下文、单元参数以及单元变量。这意味着，单元上下文、单元参数以及单元变量由控制流网络内的实体可见。注意到，控制流网络可以包含有方向图，其中，各边缘具有常规块实体，并且，各节点控制下游块实体的运行。控制流网络中的节点能够被视为特殊种类的块实体。因而，节点包含组成块实体的所有的元素。针对块实体的相同的唯一性要求适用于控制流网络中的节点。在控制流网络中的节点与常规块实体之间的差异是动作元素。节点能够仅具有决策控制动作，而常规块实体不能仅具有决策控制动作。

控制流网络具有单个进入节点550和单个退出节点590。基于该定义的本文中所描述的实施例允许在跨单元边界的模型转换中使用高效自动化。该定义是出于软件逻辑建模的目的，该定义未将实际源代码、目标代码或可运行的目标代码中的软件的实现限制于单个进入点和单个退出点，即使定义的软件设计标准可能强加这样的要求或指导。进入节点550是其仅有的动作将要启动对单元的控制的特殊种类的节点。退出节点590是其仅有的动作将要结束对单元的控制的特殊种类的节点。按照定义，使输出参数返回至调用方的函数中的语句不能整体地被包括在退出节点590中。参数返回功能性可能代之而作为常规块实体的动作元素的部分而被包括。仅用于结束对单元的控制的动作能够被包括在对于单元的退出节点590中。该方法允许将具有多个返回语句的函数建模为具有单个退出节点590的单元。

控制节点是在边缘联接在一起且向外分支的位置。虽然节点的联接不一定受控制节点控制，但从节点伸出的分支始终由控制节点通过其决策控制动作而控制。除了诸如能够针对具体应用而使用的未示出的注释之类的任何传统元素之外，还在图5的左边以钻石形实体示出可以组成控制节点的元素。虽然许多不同种类的决策控制动作可能是可用的，但具体应用可能根据在定义的软件设计标准下指定的规则而限制能够使用的决策控制动作的种类。各控制节点能够仅具有一种决策动作。在图5中所示出的实施例中，描绘了三个控制节点560、570、580。控制节点A 560描绘与选择控制结构相似的一种决策控制动作。控制节点B 570描绘一种迭代控制结构。控制节点C 580描绘具有隐式决策控制动作的专用的合并节点；即，仅存在从该控制节点伸出的一个分支，因而不需要显式决策控制动作。其他决策控制动作可以包括开关控制结构，但不限于此。在并行化分支的情况下，可以由相同控制节点选择多个分支。注意到，必须通过合并节点而使控制结构封闭。这能够通过专用的合并节点（诸如，控制节点C 580）或通过循环控制节点本身（诸如，控制节点B 570）而满足。控制节点的局部变量依然维持在沿着其指定的分支的范围内，直到使控制结构封闭为止。注意到，控制流网络可以允许对单元的复杂性的直接分析。可以计算各种基于控制结构的复杂性度量。

为了描述用于对任意软件逻辑进行建模的方法，考虑如由在图6中示出的过程600所图示的关于发放安全通行证的样本问题。可以假设存在两个场景：1）针对个体而发放安全通行证，以及2）针对组而发放安全通行证。另外，个体可以被归纳在“一般”个体或“特殊”个体的分类下（例如，对于特殊个体的权限可能被限制）。注意到，未在图6中明确示出一般个体与特殊个体之间的区别。进一步假设，安全通行证具有用于识别个体是否属于组且用于使安全管理简化的特征，组内的个体并非根据其自身的分类而区分。例如，组里的所有成员都被视为具有特殊分类。继在610开始之后，过程600确定是否应当在620启动个体或组工作流。如果个体工作流为合适的，则在630，发放通行证，并且，在690，过程结束。在结束690之前，如果组工作流为合适的，则在640，过程600循环通过组里的各成员，在650，当合适时，发放通行证。

在图7中，图示该过程的另一视图，该视图阐述在软件设计中的低级要求的方面的“Issue_Pass”单元700的内部逻辑。由将块实体连接的控制流网络对单元Issue_Pass 700的内部逻辑进行建模。注意到，控制流网络包含进入节点710、退出节点790以及三个控制节点。Select_Cat控制节点720具有下文的显式元素：标签（“HLR_010”）、变元、参数以及选择将采取的分支的决策控制动作。注意到，Select_Cat控制节点720具有隐式空节点变量元素（因为，选择控制通常不要求局部变量）。Loop_Member是可以使所有的元素作为显式的循环控制，其包括表示迭代程序的节点变量。Merge_3是隐式联接（合并）控制节点（意味着，除了其标识符和至少一个标签之外，所有的其他元素都为隐式）。在图7中，未示出Loop_Member和Merge_3的元素，以减少杂乱。控制流网络中的各边缘具有块实体，并且，总共存在六个块实体。Issue_Ind_Pass 730和Issue_Grp_Pass 750使所有的元素作为显式。另外四个块实体具有隐式空动作元素。这四个块实体被命名为Null_Block_0、Null_Block_2、Null_Block_4以及Null_Block_5。

如图7中所图示，低级要求可以由所要求的功能性表达，抽象化为块实体（由其显性描述性标识符表示）和逻辑行为（抽象化为控制流网络），逻辑行为由对于各控制节点和将控制节点连接的网络拓扑结构的显式描述性标识符表示。如果期望如此，则能够包括注释元素，以提供对各显式描述性标识符的进一步描述（但不要求这样的注释）。相反，可以使用数据字典机制来追踪标识符，并且，在中央数据库中或以分布式方式提供对各标识符的另外的描述。由定义的软件设计标准指导，如果实体的功能性或行为改变成不同的范围，则还可以改变其显式描述性标识符。在这样的情况下，定义的软件配置管理标准可能要求从旧的实体创建或推导的新的实体以及否决旧的实体。

根据一些实施例，封装于各实体内的动作细节的细化可以反映出实现方案细节。如果要求不受这样的实现方案细节影响，则由模型表达的低级要求维持相同。因而，模型的粒度可以与低级要求一致，以便准确地反映出对要求产生影响的改变。考虑到例如与其中模型粒度遍及单元内的所有块实体而维持处于相同等级的平坦逻辑结构的差异，嵌套块实体能够用于维持模型粒度与低级要求之间的一致性，且同时用于提高抽象化的等级。在嵌套块实体中，其动作元素包含嵌套逻辑。嵌套逻辑与上述的正常逻辑相同。除了嵌套块实体的进入节点与当前块实体的上游控制节点相符，且嵌套块实体的退出节点与当前块实体的下游控制节点相符之外，还通过将常规块实体连接的控制流网络而对嵌套块实体进行建模。可以使嵌套块实体之内的块实体进一步嵌套。

应当注意到，嵌套块实体的嵌套逻辑仍然是当前单元的内部逻辑的部分。这与由块实体调用的函数的内部逻辑不同。由块实体调用的函数的内部逻辑可能代之而被认为是属于单独的单元。使嵌套块实体的嵌套逻辑扩展成父单元的内部逻辑的过程可能不对由模型表达的低级要求或对软件系统的体系结构造成影响。相反地，使单元的内部逻辑的子部分抽象化且将其封装至嵌套块实体中的过程也可能不对由模型表达的低级要求或对软件系统的体系结构造成影响。

注意可以如何使用图7的Issue_Pass单元700的识别标签来维持对更高级的要求的可追踪性。具体地，可以将对更高级的要求的可追踪性维持于块实体等级和控制节点等级下。例如，块实体Issue_Ind_Pass具有维持对高级要求011和高级要求030的可追踪性的两个标签，HRL_011和HLR_030。块实体Issue_Grp_Pass具有维持对高级要求013和高级要求030的可追踪性的两个标签，HLR_013和HLR_030。类似地，控制节点Select_Cat具有维持对高级要求010的可追踪性的一个标签，HLR_010。Null_Block_0、Null_Block_2、Null_Block_4以及Null_Block_5具有维持对高级要求006的可追踪性的一个标签，HLR_006。理念是，具有隐式空动作元素的块实体还对于更高级的要求是可追踪的。出于模拟和测试的目的，这样的具有隐式空动作元素的块实体还将允许模型覆盖和结构覆盖仪器将并入所生成的代码中。根据一些实施例，单元Issue_Pass的识别标签既不提供与单元中所包含的块实体和控制节点的识别标签无关的信息，也不提供复制信息。单元Issue_Pass的识别标签仅仅是对来自单元内部逻辑中的块实体和控制节点的所有的识别标签的引用。相同规则可以适用于嵌套块实体，其中，父块实体的识别标签可以仅包含对来自嵌套逻辑中的块实体和控制节点的所有的识别标签的引用。

使用该方法，使嵌套块实体的嵌套逻辑扩展到父单元的内部逻辑中（且因此，消除父嵌套块实体本身）不影响对更高级的要求的可追踪性，并且，不要求对由嵌套逻辑中的块实体和控制节点所维持的可追踪性作出任何调整。相反地，使单元的内部逻辑的子部分抽象化且将其封装至嵌套块实体中的过程不影响对更高级的要求的可追踪性，并且，不要求对由待封装至嵌套逻辑中的块实体和控制节点所维持的可追踪性作出任何调整。

根据一些实施例，通过追踪实现任何给定的更高级的要求的所有的实体（块实体和控制节点）的索引或映射方法而维持更高级的要求与低级要求及低级设计之间的双向的可追踪性。该途径可以采用两种机制来维持高到低的可追踪性索引或映射。可以采用“注册”机制，以用于实现针对个体实体的映射的高效而可靠的建立。可以采用“搜索和索引”机制，以用于诸如在主系统更新或体系结构改变之后，周期性地或在事件驱动的基础上建立或刷新索引或映射。

本文中所描述的一些实施例可以提供用于使嵌套块实体扩展且抽象化的方法。为了图示这样的-特征，使图6中所描绘的软件逻辑中的块“针对个体而发放通行证”扩展，以示出如图8的过程800所描绘的嵌套逻辑。嵌套逻辑根据个体的分类而区分个体，并且，基于分类而发放安全通行证。如以前那样，继在810开始之后，过程800确定是否应当在820启动个体或组工作流。如果个体工作流为合适的，则在830、832发放一般通行证，或在830、834发放特殊通行证，并且，在890，过程结束。在结束 890之前，如果组工作流为合适的，则在840，过程800循环通过组里的各成员，在850，当合适时发放通行证。针对组里的个体的安全通行证可以基于组策略，因而可能没必要区分是否应当根据其个体分类而区别对待组里的个体。

图9图示与扩展过程和抽象化过程相关联的“Issue_Pass”单元910、920。如本文中所使用的，术语“扩展”可以指如下的模型转换：去除由嵌套块实体所提供的抽象化和封装，并且，使其嵌套逻辑直接地并入当前单元的内部逻辑中（在图9中，从左到右）。抽象化指将逻辑的多个部分封装至新的嵌套块实体中的逆向过程（在图9中，从右到左，创建“Issue_Ind_Pass”912）。

在图10中，描绘用于使嵌套块实体扩展的方法。该图示出在转换的期间如何处置嵌套子逻辑中的块实体和控制节点的各元素以及父块实体的各元素。该转换的主要作用是，在转换之后，父块实体的嵌套子逻辑现在暴露于单元参数和单元变量（并且，这可能需要适当地处理）。在S1002，将父块实体中的块变量提升至单元变量。通过修改提升后的变量的名称，从而解决在该过程中识别到的任何名称冲突。名称冲突是可能的，因为块变量被假设在块的外侧是不可见的。在S1004，将嵌套子逻辑中的块实体和控制节点的变元重新映射到现有的单元参数和单元变量以及从父块实体的块变量提升的那些新的单元变量。通过经由起初由父块实体的块参数维持的关系而直接地将那些变元连接至现有的单元参数和单元变量，从而实现到现有的单元参数和单元变量的映射。一旦该映射完成，就绕过父块实体的块参数，而不再需要父块实体的块参数。通过仅仅保持原始关系而实现到从父块实体的块变量提升的新的单元变量的映射。注意到，嵌套子逻辑中的块实体和控制节点的识别标签、块参数、块变量以及动作或决策控制动作维持相同而不需要改变。因而，在维持模型中所表达的低级要求和对更高级的要求的可追踪性的同时，本文中所描述的一些实施例可以允许在转换中使用高效自动化。在S1006，使嵌套子逻辑的进入节点与父块实体的最接近的上游控制节点合并。使嵌套子逻辑的退出节点与父块实体的最接近的下游控制节点合并。由于嵌套子逻辑的进入节点和退出节点是实质上虚拟的控制节点，通过仅仅将嵌套子逻辑连接至单元内部逻辑而实现合并。在S1008，将父块实体的识别标签从高到低的要求的可追踪性的映射注销。由于可追踪性维持于块实体控制节点等级下，因而该步骤不对可追踪性产生影响。在S1010，如果使用数据字典来追踪块标识符，则将父块标识符从数据字典注销。由于由嵌套子逻辑表示的功能性成为单元的内部逻辑的直接部分，因而不再需要父块实体的块标识符。在S1012，可以释放父块实体。

在图11中，描绘用于使嵌套块实体抽象化的方法，图11示出在转换的期间如何处置新的嵌套块实体的各元素和待转换成嵌套子逻辑的单元内部逻辑的子区段。在S1102，识别单元内部逻辑的子区段，以用于抽象化。这实质上是专用决策。要求逻辑的子区段具有到控制流网络的剩余部分的唯一的连入连接和唯一的连出连接。连入边缘和连出边缘应当作为子区段的部分而被包括。在S1104，创建新的块实体。基于待嵌套于新的块实体中的预期的功能性而创建显式描述性块标识符。新的块实体将充当待嵌套的功能性的抽象化。如果使用数据字典来追踪块标识符，则将新的块标识符注册于数据字典中。在S1106，单元内部逻辑的所识别出的子区段嵌套至新的块实体中作为其动作。逻辑的子区段的连入边缘的起点和连出边缘的终点分别成为嵌套子逻辑的进入节点和退出节点。注意到，嵌套子逻辑中的块实体和控制节点的识别标签、块参数、块变量以及动作或决策控制动作维持相同，因而不需要改变。因而，在维持模型中所表达的低级要求和对更高级的要求的可追踪性的同时，本文中所描述的一些实施例可以允许在转换中使用高效自动化。在S1108，嵌套块实体连接至最接近的上游控制节点和最接近的下游控制节点，其中，嵌套子逻辑起初连接至单元内部逻辑的剩余部分。在S1110，通过使嵌套子逻辑中的块实体和控制节点的变元聚合，从而建立嵌套块实体的变元。在S1112，通过在先前的步骤中建立的变元的直接一对一映射而建立嵌套块实体的块参数。这可以帮助保持嵌套子逻辑的接口在转换的期间不变。在S1114，使仅旨在用于供嵌套子逻辑使用，因而仅被嵌套子逻辑引用的单元变量降级至嵌套块的块变量。由于与降级后的块变量相对应的嵌套块的块变元和块变量实体不再满足任何目的，因而将它们去除。另外，可以启动后转换设计活动，从而进一步调整或修改嵌套块实体。作为用于尝试不同的抽象化选项的临时转换，或如果期望如此，在该过程的期间，可以跳过该单元块变量降级步骤。能够采用使过程降级的专用的后转换单元变量来实现相同效果。在S1116，可以通过对嵌套子逻辑中的块实体和控制节点的识别标签引用，从而建立嵌套块实体的识别标签。针对每个所追踪到的要求而将嵌套块实体注册于高到低的要求的可追踪性的映射中，以确保针对最近创建的嵌套块实体的最新的双向的可追踪性。

注意到，抽象化还能够应用于控制节点，从而对任何任意控制结构（包括不被现有的编程语言支持的那些控制结构）进行建模。在这种情况下，嵌套控制节点的动作元素不再限制于控制决策动作。可以使用涉及除了决策控制动作之外的动作的使用的复杂的控制决策逻辑。

图12图示与分裂过程和合并过程相关联的“Issue_Pass”单元1210、1220。注意到，可以使用用于以并行或序列的方式将单个单元建模为单独的过程的相同方法来对多个单独的个体单元进行建模。图12示出如何能够将相关单元建模为单个过程，更具体地，如何能够将单个单元转换成多个单元以及如何能够将多个单元转换成单个单元（例如，与“Issue_Sts_Pass”1222相关联）。如本文中所使用的，术语“分裂”可以指将单个单元分成两个或更多个单元的模型转换（从左到右，如图12中所示出）。术语“合并”可以指使两个或更多个单元组合成单个单元的逆向过程（在图12中，从右到左）。按照定义，这些过程可能引起体系结构变化。最近创建的单元可能在原始单元的外侧变成可访问的。组合成组合的单元的旧的单元可能不再是从组合的单元的外侧可访问的。可以通过关于用于使嵌套块实体扩展和抽象化的方法而构建的另外的步骤来实现分裂和合并。

在图13中，描绘使单元分裂的方法，图13示出如何在转换的期间处置从原始单元分裂的新的单元的各单元元素。在S1302，如果针对待分裂成新的单元的逻辑的子区段不存在嵌套块实体，则遵循早前描述的用于抽象化的方法，在原始单元中使嵌套块实体抽象化。在S1304，创建新的单元。基于待封装于新的单元中的预期的功能性而创建显式描述性单元标识符。单元标识符是嵌套块实体标识符的更一般化的衍生，其中应当对嵌套块标识符的环境上下文进行去识别化。例如，如果嵌套块实体的块标识符是计算窗口面积（Calculate_Area_of_Window），则单元标识符能够是计算矩形面积（Calculate_Area_of_Rect），这意指着，单元能够用于计算在形状上呈矩形的任何平面物体的面积。如果转换的意图是将子逻辑作为整体而重新使用，以支持多个单元，则仅需要一般化。如果使用数据字典来追踪单元标识符，则将新的单元标识符注册于数据字典中。在S1306，通过填充嵌套块实体的块参数而建立新的单元的单元参数。在S1308，通过填充嵌套块的块变量实体而建立新的单元的单元变量。在S1310，将嵌套块实体的嵌套子逻辑转移至新的单元，以作为其内部逻辑。嵌套块实体的嵌套子逻辑的进入节点和退出节点成为新的单元的进入节点和退出节点。在S1312，针对新的单元的所转移的内部逻辑中的块实体和控制节点，而对识别标签进行重新映射，以及使块标识符一般化。如果转换的意图是将子逻辑作为整体而重新使用，以支持多个单元，则仅需要一般化和重新映射。如果确实是该情况，则一般化和重新映射的目的是，去除对特定于已被去识别化的环境上下文的更高级的要求的引用。如果已通过充分1利用块变元和块参数，以使块动作与环境上下文隔离，从而使原始嵌套子逻辑中的块实体和控制节点中的每个都已经被一般化，则当前步骤变得不必要（这可能是标准实践）。因而，在维持模型中所表达的低级要求和对更高级的要求的可追踪性的同时，本文中所描述的一些实施例可以允许在转换中使用高效自动化。注意到，新的单元的所转移的内部逻辑中的块实体和控制节点的块参数、块变量以及动作或决策控制动作可以维持相同，不需要改变。然而，可以启动后转换设计活动，以调整或修改这些元素的命名，连同任何其他期望的改变。如果在该步骤中需要人为干预，则可以自动地对相关的元素进行注释，以确保采取一致的动作。在S1314，通过对内部逻辑中的块实体和控制节点的识别标签的引用而建立新的单元的识别标签。针对每个所追踪到的要求，在高到低的要求的可追踪性的映射中，注册单元，以针对最近创建的单元而建立双向的可追踪性。在S1316，由于不再需要原始单元中的嵌套块的块变量实体，因而将它们去除。嵌套块实体的动作被替换为对新的单元的引用。嵌套块实体的变元维持相同。在S1318，对嵌套块实体的识别标签进行更新，以反映出封装于新的单元中的功能性的授权。同时，对原始单元的识别标签进行更新，以反映出封装于新的单元中的功能性的授权。具体地，仅保持环境上下文特定要求。对高到低的要求的可追踪性的映射中的嵌套块实体的条目（entries）进行更新。

在图14中，描绘用于使单元合并的方法，图14示出如何可以使一个单元组合至另一单元中，以作为另一单元中的嵌套块实体。第一单元被称为待合并的单元，并且，第二单元被称为组合的单元。如果直接一对一合并不满足建模需要，则通过使用一对一合并，连同使父单元分裂，以创建全新的组合的单元而将任意合并封装的必要的步骤，从而能够始终实现任意合并。在S1402，识别引用待合并的单元的组合的单元中的块实体。该块实体被称为父块实体。在下文中所描述的转换步骤之后，该块实体成为嵌套块实体。如果待合并的单元被多个块实体引用，则该方法能够应用于每个这样的块实体、每个父块实体。在S1404，使父块实体的块变量扩展，以包括来自待合并的单元的单元变量。通过修改合并的单元变量的名称，从而解决在该过程中识别出的任何名称冲突。由于假设块变量和单元变量在这些实体本身的外侧是不可见的，因而名称冲突是可能的。在S1406，将待合并的单元的内部逻辑转移至组合的单元中的父块实体，以作为嵌套子逻辑。这通过以该单元的内部逻辑替换对待合并的单元的引用而实现。使进入节点和退出节点连结至最近组合的嵌套子逻辑。在S1408，将嵌套子逻辑中的块实体和控制节点的变元重新映射到父块实体的现有的块参数和块变量。经由起初在合并之前传递至待合并的单元的变元且经由在块变量名称冲突解决的期间作出的任何调整而实现该映射。嵌套子逻辑中的块实体和控制节点的块参数、块变量以及动作或控制决策动作维持相同，因为，它们已借助于其变元而与环境上下文隔离。由合并至父块实体中的块实体和控制节点表达的低级要求和低级设计也维持相同。在S1410，对嵌套父块实体的识别标签进行更新，以包括对合并至嵌套子逻辑中的块实体和控制节点的识别标签的引用。现在，嵌套父块实体的识别标签包括对上下文特定要求和先前由单元处理而现在合并至嵌套块实体中的要求两者的可追踪性。在高到低的要求的可追踪性的映射中，对父块标识符的注册进行更新，以维持双向的可追踪性的完整性。同时，还对合并的单元的识别标签和注册进行更新。在S1412，如果遵循上文的步骤而对组合的单元以及任何其他单元中的所有的所识别出的父块实体进行转换，则将待合并的单元的识别标签从高到低的要求的可追踪性的映射注销。在S1414，如果使用数据字典来追踪单元标识符，则将待合并的单元的单元标识符从数据字典注销。由于由待合并的单元表示的功能性成为组合的单元的内部逻辑中的嵌套父块实体的部分，因而不再需要待合并的单元的单元标识符。在S1416，可以释放已合并至组合的单元中的单元。通过这些步骤，将待合并的单元转换成嵌套父块实体的嵌套子逻辑的部分。如果期望如此，则能够根据早前描述的方法而进一步使嵌套父块实体扩展，以作为组合的单元的内部逻辑的直接部分。对于具体的父块实体，可能曾经横贯待合并的单元（第一单元）中的逻辑流网络的仅一部分。因而，步骤S1404，S1406以及S1408可能仅涉及与第一单元中的逻辑流网络的部分相关的那些项。软件设计决策可以是，将单元合并至一些父块实体中，而不合并至其他父块实体中。因而，由于已合并至一些块实体中的单元仍然被一些其他块实体引用，因而可以跳过步骤S1412、S1414、S1416。

在图15中，图示通过用于扩展、抽象化、分裂以及合并的方法而描述的连锁的模型单元转换过程。尤其，图15图示单元1510，其被抽象化成另一单元1520，且然后，分裂成又两个其他单元1530和1536。同样地，可以使该单元1530和1536合并，以创建1520，且然后，使该单元1530和1536扩展，以返回至原始单元1510。

图3、图4、图5、图7、图9以及图12提供根据本文中所描述的实施例的模型实体和完整模型的模范图形表示。体现这样的实施例的系统和计算机工具可以使用各种各样的样式和不同等级的抽象化来用图形表示在建模过程的不同阶段的模型。还使用除了图形之外的显式模型符号来表示模型，从而将模型设计信息作为软件开发人工制品、作为最终产品、作为在实时建模过程期间的中间数据或作为将在网络化分布式建模环境中交换的消息而存储。注意到，本文中所描述的一些实施例可以与用于以不同的格式表示模型的方法相关联。模型可以例如由元类表示，元类用于表示块实体的完整信息、控制节点以及逻辑流网络链路。可以通过直接地访问元类性质而对模型进行直接地分析，以检查潜在误差或一致性。图形表示（例如逻辑流程图）可以由人类开发者呈现以用于观察底层模型。可以生成软件代码，并且，将软件代码编译成目标对象代码，从而用于运行且/或供人类开发者审查或测试。

备选地，如果预先选择编程语言，则模型可以直接地由遵循严格地预定义的编码标准的软件代码表示。通过示例方式，块实体可以由下文的Ada代码块表示：

Issue_Gen_Pass：

--| 针对一般个体而发放通行证

--| 要求满足：：HLR_011；HLR_30

声明

Pass_Buffer ：General_Pass_Type

开始

Pass_Buffer.Name ：= Visitor_Name；

Pass_Buffer.Date ：= Clock.Current_Date；

Pass_Buffer.Expiration ：= Expiration_Time；

Issue_Pass（Pass_Buffer）；

结束 Issue_Gen_Pass；

在本示例中，块标识符是“Issue_Gen_Pass”。识别标签HLR_011和HLR_30用于显式地维持对更高级要求的可追踪性。块输入变元包括Visitor_Name和Expiration_Time。在本示例中，块参数成为隐式（即，块参数通过块变元而短路），以避免额外赋值语句。关于该短路的一个问题是与自动化模型转换相关联的额外开销。注意到，仅存在一个块变量Pass_Buffer。块动作包括设立通行证缓冲的块动作，以及调用函数Issue_Pass，以使实际通行证被发放。与块实体的=示例类似，控制节点还可以直接地由遵循严格地定义的软件标准的软件代码表示。

作为另一示例，下文可以将遗留代码块映射到块实体：

--| 收集机场信息

Data_Base.Read

（ 索引 => Airport_Index，

-- 作为输入的先前识别的索引

数据 => Airport_Data）；

-- 作为输出的所获得的机场信息

--| 基于跑道对跑道进行搜索

--| 标识符和机场信息。

Runway_Buffer := 对跑道进行搜索

（ Runway_Record => Airport_Data.Runway_Record，

-- 作为输入的机场跑道记录

密钥 => Runway_ID ）；

-- 作为输入的先前提供的ID

--| 提取跑道信息，如果找到跑道，则

--| 对于具体的机场。

if Runway_Buffer.Found，then

Data_Base.Read

（ 索引 => Runway_Buffer.Index，

-- 作为输入的跑道索引

数据 => Runway_Data）；

-- 作为输出的所获得的跑道信息

end if；

注意到，在上文的示例中，由特殊序列“--|”所指示的注解行开始的代码块的各部分可以包含块实体。由标准序列“--”所指示的注解行可以充当块实体内的常规注释。可以基于由特殊序列“--|”（例如，“收集机场信息”、“对跑道的搜索”、“提取跑道信息”）所指示的注解而创建描述性块实体标识符。可以根据单元的要求可追踪性而建立对于这些块实体的识别标签，如果必要的话采用人为干预。可以遵循先前的示例而建立块实体的其他项。注意到，从示例中的最后一个代码块直接地映射的块实体“提取跑道信息”将是嵌套块实体，因为它包含嵌套逻辑流。可以使该块实体扩展，以建立平坦逻辑单元。如果在映射（即，模型提取）之后，尚未改变模型单元中的逻辑流，则从模型至最近生成的代码的逆向映射将产生实现相同逻辑的代码块。然而，将以适当的块实体项生成各代码块，除了其他项之外，还包括不在遗留代码中的识别标签。

传统上，在函数或单元头中，注解常常用于以自然语言描述逻辑流。关于传统的途径的一个问题是逻辑描述与实际代码行之间的物理距离。该距离加大了对于保持描述和代码同步的困难。该距离还加大了对于审查代码设计及对于分析代码设计的困难。这些困难往往倾向于导致逻辑描述与实现逻辑的实际代码之间的偏离。在使用软件代码来表示模型中，实施例可以通过将逻辑描述放置于实际代码的位置处而处理该问题。然后，代码编辑工具可以示出代码的细节的不同等级。例如，开发者可以完全地隐藏将会与常规的文件头逻辑描述相似的代码（且仅示出注解和标签）。要求的规范可以从规范模型拉出，并且，在代码视图中示出，但不存储于代码文件中，或要求的规范可以自动地插入代码文件中，以作为代码文件内容的部分。然后，仅示出对于控制实体的代码（连同加标签的注解），其将与某种伪代码相似。正如常规的代码文件，还可以使得所有的代码行可见。对高级要求的可追踪性始终嵌入块实体和控制节点中。另一方法是，仅示出代码，而无任何注解。这对于希望手动地使代码优化的有经验的程序员可以是有利的。虽然以软件代码表示模型是可能的，但考虑到与直接模型分析和模型转换相关联的另外的开销，当有可能时，元类表示可以是优选的模型表示。

用于将模型表示为元类和软件代码的方法可以提供维持表示为元类和软件代码的模型之间的映射的方式。这能够扩展，从而自动地从遗留软件源代码提取模型。可以建立列表（利用搜索树的映射），从而对代码语言语法进行搜索，以识别块实体和控制节点。该提取方法能够通过建立统配列表结构而以新的特征或针对不同的编程语言来被扩展，且然后被推导或示例化，以创建针对特定编程语言或应用代码库的映射。

一旦提取模型并将其存储于数据库中，然后，就能够直接地分析且增强该模型，以形成对于软件系统的新的底层模型。根据本文中所描述的一些实施例，逻辑流可以由块实体和控制流网络显式地表示。如此，能够显式地维持模型元素与软件代码之间的可追踪性。这允许通过利用各块实体（包括空块实体）的模拟运行的模拟而实现的全模型覆盖测试。可以同时实现代码结构覆盖测试和模型覆盖测试。

对于块实体和控制节点的形式参数与实际变元之间的区分允许在单元中改变变量名称，而不改变模型中的逻辑的表示。例如，在给定的问题域中，算法通常由使用所建立的命名的方程表示。主要地由于尝试避免变量命名冲突而不能如在软件代码中那样容易地使用这样的命名法。在仍然维持形式参数与实际变元两者之间的显式可追踪性的同时，对形式参数和实际变元的区分对模型表示和软件代码进行解耦。该区分还允许代码块与函数之间的容易转换。或者，该区分可以允许具有由一个代码生成配置中的块实体和逻辑流控制网络以及另一代码生成配置中的一批小而简单的单元表示的单元的内部逻辑的单元。这两个不同的软件代码配置中的每个都可以在不同的情形下具有其优点。这可以适合于具有在仍然需要维持的生产线的整个历史中释放的多个产品差异的长期使用的生产线。

注意到，能够在所生成的代码中，实现通过使嵌套块实体扩展且抽象化而实现的单元分裂和合并，以作为语句块至函数/程序、内嵌函数以及/或局部函数之间的转化。

图9、图10以及图11中所描绘的用于使嵌套块实体扩展且抽象化的方法和图12、图13以及图14中所描绘的用于对多个单元进行建模的方法能够在模型提取和代码生成的期间用作如下的方式：对单元或块实体等级局部变量进行重新组织，以致于能够重新布置它们，从而匹配特定编程语言特征和样式。例如，无论在哪些块实体内使用局部变量，都能够在单元的开始声明所有的局部变量，或者，在首次使用局部变量的情况下，能够声明局部变量。

如本文中所使用的，术语“构件”可以指实现所要求的逻辑的方法（其能够被实现为硬件系统中的计算机软件）。然而，描述在这个问题上不必划分为构件的具体的实现方案。注意到，本文中所描述的实施例可以实现为由单个计算机或通过网络互连的分布式计算机托管的基于模型的软件设计计算机系统。在一些实施例中，方法提供基于模型的设计的一组功能性。各方法可以构建为总体计算机系统的构件，并且，组装且连接为在相同计算机上或通过多个分布式计算机上运行的软件，以形成系统。行业标准（诸如，统一建模语言（“UML”）、对象管理组（“OMG”）元对象设施、OMG可扩展标记语言（“XML”）元数据交换连同其他）可以用于与不同的软件工程工具接口连接。

此外，本文中所描述的实施例可以实现为基于模型的软件设计计算机工具。在这样的实施例中，一个或更多个方法可以提供针对独立式构件工具的功能性。能够运行这样的构件工具，从而在本地或网络化计算机存储介质中，读取、处理且保存模型信息。能够运行这样的构件工具，从而从其他在本地托管或远程地托管的工具检索，处理这些工具，且分配给这些工具，以实现完整基于模型的设计任务。行业标准（诸如，UML、OMG元对象设施、OMGXML元数据交换连同其他）可以用于与存储介质或其他基于模型的设计工具接口连接。备选地，如果合理，则可以使用专有接口。

可以使用任何数量的不同的硬件配置来实现本文中所描述的实施例。例如，图16是ASLM平台1600的框图，例如，ASLM平台1600可以与图1的系统100相关联。ASLM平台1600包含处理器1610（诸如，采取单个-芯片微处理器的形式的一个或更多个市面上可得到的中央处理单元（“CPU”）），处理器1610耦合至通信装置1620，通信装置1620配置成经由通信网络（未在图16中示出）而通信。可以使用通信装置1620来与例如一个或更多个远程管理方终端、用户平台等通信。ASLM平台1600还包括输入装置1640（例如，输入建模或代码信息的计算机鼠标和/或键盘）和/或输出装置1650（例如，呈现显示、创建报告等的计算机监视器）。根据一些实施例，可以使用移动装置和/或PC来与ASLM平台1600交换信息。

处理器1610还与存储装置1630通信。存储装置1630可以包含任何合适的信息存储装置，包括磁存储装置（例如，硬盘驱动器）、光存储装置、移动电话以及/或半导体存储器装置的组合。存储装置1630存储用于控制处理器1610的程序1612和/或ASLM引擎1614。处理器1610执行程序1612、1614的指令，且由此根据本文中所描述的任何实施例而操作。例如，处理器1610可以访问ASLM数据源，ASLM数据源包含与单元相关联的电子记录，各电子记录包括单元标识符、一个或更多个识别标签、上下文数据、单元参数、单元变量以及内部逻辑。处理器1610可以表达逻辑块等级下的系统要求，并且，根据系统要求而建立作为自包含实体和连接的逻辑块（所建立的逻辑块用图形表示系统逻辑）。然后，处理器1610平台可以自动地对系统逻辑显式地进行转换，以输出与语言无关的公共设计信息交换模型信息。处理器1610平台还可以转化且维持系统要求、公共设计信息交换模型信息以及所生成的代码之间的可追踪性。

可以按压缩、未编译且/或加密的格式存储程序1612、1614。此外，程序1612、1614可以包括其他程序元素，诸如，操作系统、剪贴板应用、数据库管理系统以及/或供处理器1610使用以与外设装置接口连接的装置驱动器。

如本文中所使用的，信息可以例如：（i）从另一装置由ASLM平台1600“接收”或“传输”到ASLM平台1600；或（ii）从另一软件应用、模块或任何其他来源由ASLM平台1600内的软件应用或模块“接收”或“传输”到ASLM平台1600内的软件应用或模块。

在一些实施例（诸如，图16中所示出的实施例）中，存储装置1630进一步存储ASLM数据库1700、HLR数据库1660（例如，包含必须满足的一组高级要求）以及单元库1670（例如，包含可以供其他开发者再使用的软件单元）。现在，将针对图17而详细地描述可以关于ASLM平台1600而使用的数据库的示例。注意到，本文中所描述的数据库仅仅是示例，并且，可以将另外且/或不同的信息存储于其中。此外，可以根据本文中所描述的任何实施例而使各种数据库分裂或组合。

参考图17，示出表示ASLM数据库1700的表格，ASLM数据库1700可以存储于根据一些实施例的ASLM平台1600处。表格可以包括例如识别与电功率网格相关联的构件的条目。表格还可以针对各条目而定义字段1702、1704、1706、1708、1710。字段1702、1704、1706、1708、1710可以根据一些实施例而指定：ASLM标识符1702、识别标签1704、上下文 1706、单元参数和变量1708以及内部逻辑1710。可以创建ASLM数据库1700，并且对ASLM数据库1700进行更新（例如，当启动用于实现高级要求的新项目时）。

ASLM标识符1702可以例如是唯一字母数字代码，其表示用于显式地识别单元的预期的功能性的描述性名称。一个或更多个识别标签1704可以显式地维持ASLM标识符1702以及单元本身对更高级要求（包括推导出的要求）的可追踪性。上下文1706可以显式地指定对ASLM标识符1702外部的实体的依赖性。单元参数和变量1708可以表示预计将要被ASLM标识符1702接收且输出的形式数据项。内部逻辑1710可以表示旨在将由ASLM标识符1702实行的特定功能性（且可以由将对于ASLM标识符1702的块实体连接的控制流网络表示）。

因而，本文中所描述的一些实施例可以提供显式地在块等级下对任意软件逻辑进行建模的方式。此外，实施例可以在充分扩展的平坦逻辑中，显式地转换软件模型（清楚地说明每个逻辑块），使嵌套逻辑抽象化且将嵌套逻辑封装，并且，使可重复使用的单元分裂，全部都自动地遵循合适的步骤。一些实施例可以显式地转化且维持不同形式的模型（例如，元类、图形表示以及软件代码）之间的可追踪性。可以提供对于完整的工具链的基础，从而从遗留代码提取模型，以高效地且有效地优化且转换模型，且/或生成代码，以用于对复杂的、长期使用的、安全关键航空电子设备（及地面系统）软件进行测试和最终发布。注意到，软件单元内部逻辑相当于分配给软件工程的大部分资源（关于工时和调度时间两者）。本文中所描述的实施例可以建立工具链，以处理软件单元内部逻辑等级设计，从而持续地对复杂的软件项目进行维持、逐步改进、增强、转换以及再创新。

下文图示本发明的各种另外的实施例。这些实施例不组成对所有的可能的实施例的定义，并且，本领域技术人员将理解到，本发明适用于许多其他实施例。此外，虽然为了清楚起见，简略地描述下文的实施例，但本领域技术人员将理解：如果必要的话，如何对上述的设备和方法作出任何改变，以适应这些及其他实施例和应用。

虽然在本文中已经描述了具体的硬件和数据配置，但注意到，可以根据本发明的实施例而提供任何数量的其他配置（例如，可以使与本文中所描述的数据库相关联的一些信息组合或存储于外部系统中）。此外，注意到，一些实施例可以与对开发者的信息的显示相关联。例如，图18图示交互式图形用户界面（“GUI”）显示1800，显示1800可以显示关于单元1810、1820的信息，其可以与扩展过程和/或抽象化过程相关联。计算机指针 1850的使用可能产生在显示1800（例如，弹出式窗口）上提供的更详细的信息、对单元1810、1820的调整等。

仅仅出于图示的目的，关于若干实施例而已经描述了本发明。本领域技术人员将从该描述认识到，本发明不限于所描述的实施例，而是可以通过仅受所附权利要求的精神和范围限制的修改和变更来实践。

零件表

编号 描述

100 系统

110 ASLM数据源

150 ASLM平台

155 GUI

170 远程用户平台

300 单元

310 单元标识符

320 识别标签

330 上下文

332 单元参数

334 单元变量

340 内部逻辑

400 块

410 块标识符

420 识别标签

430 上下文

432 块参数

434 块变量

440 动作

500 图示

510 节点标识符

520 识别标签

530 变元

520 节点参数

534 节点变量

540 决策控制和动作

550 进入节点

560 控制节点A

570 控制节点B

580 控制节点C

590 退出节点

600 过程

610 开始

620 选择

630 发放通行证

640 循环

650 发放通行证

690 结束

700 图示

710 进入节点

720 Select_Cat

730 Issue_Ind_Pass

750 Issue_Grp_Pass

790 退出节点

900 图示

910 发放通行证单元（扩展）

920 发放通行证单元（抽象化）

1200 图示

1210 发放通行证单元（合并）

1220 发放通行证单元（分裂）

1500 图示

1510 发放通行证单元（抽象化/合并）

1520 发放通行证单元（扩展）

1520 发放通行证单元（分裂）

1600 ASLM平台

1610 处理器

1612 程序

1614 数字孪生模型

1620 通信装置

1630 存储元件

1640 输入装置

1650 输出装置

1660 HLR数据库

1670 单元库

1700 ASLM数据库

1702 ASLM标识符

1704 识别标签

1706 上下文

1708 单元参数和变量

1710 内部逻辑

1800 显示

1850 计算机指针。

Claims (10)

1.一种促进任意软件逻辑建模“ASLM”处理的系统，包含：

ASLM数据源，其存储与单元相关联的电子记录，各电子记录包括单元标识符、一个或多个识别标签、上下文数据、单元参数、单元变量以及内部逻辑；以及

ASLM平台，其耦合至所述ASLM数据源，包括计算机，所述计算机被编程为：

（i）表达逻辑块等级下的系统需求；

（ii）根据所述系统需求而建立作为自包含实体和连接的所述逻辑块，所建立的所述逻辑块用图形表示系统逻辑；

（iii）自动地对所述系统逻辑显式地进行转换，以输出与语言无关的公共设计信息交换模型信息；

（iv）转化且维持所述系统需求、公共设计信息交换模型信息以及所生成的代码之间的可追踪性；以及

（v）运行合并过程，所述合并过程包括：

识别引用待合并的单元的组合的单元中的块实体；

使父块实体的块变量扩展，以包括来自所述待合并的单元的单元变量；

将所述待合并的单元的内部逻辑转移至所述父块实体的嵌套子逻辑；

针对合并至所述嵌套子逻辑中的块实体和控制节点而对变元进行重新映射；

在转移所述待合并的单元的内部逻辑并且扩展块变量之后，对所述父块实体的识别标签进行更新，且对包含层级的可追踪性的映射中的父块标识符的注册进行更新，并且，针对所述组合的单元而更新所述识别标签和可追踪性的映射；

将所述待合并的单元的识别标签从所述可追踪性的映射注销；

将所述待合并的单元的单元标识符从数据字典注销；以及

释放待合并的所述单元。

2.根据权利要求1所述的系统，其中，系统需求包含低级需求和高级需求中的至少一个，并且，所述单元参数定义外部单元接口和对本体的追踪，以允许软件构件接口的自动转换，其中所述低级需求低于层级中的所述高级需求。

3.根据权利要求1所述的系统，其中，所述ASLM数据源中的至少一个电子记录表示块实体，所述块实体包括块标识符、一个或多个识别标签、变元、块参数、块变量以及动作。

4.根据权利要求1所述的系统，其中，所述系统逻辑包括以下项中的至少一项：控制节点、循环节点、合并节点、进入节点、退出节点以及空节点。

5.根据权利要求1所述的系统，其中，所述ASLM平台进一步运行扩展过程。

6.根据权利要求5所述的系统，其中，所述扩展过程包括：

将父块实体的父块变量提升至单元变量；

针对嵌套子逻辑中的块实体和控制节点而对变元进行重新映射；

使嵌套子逻辑的进入节点和退出节点与单元内部逻辑中的控制节点合并；

将父块识别标签从包含层级的可追踪性的映射注销；

将父块标识符从数据字典注销；以及

释放所述父块实体。

7.根据权利要求1所述的系统，其中，所述ASLM平台进一步运行抽象化过程。

8.根据权利要求7所述的系统，其中，所述抽象化过程包括：

识别待抽象化的逻辑的子区段；

创建新的块实体，并且，在数据字典中注册块标识符；

对逻辑的所述子区段进行嵌套，而作为所述新的块实体的动作；

将所述新的块实体连接至其中逻辑的所述子区段起初所连接的位置；

利用逻辑的嵌套的所述子区段针对所述新的块实体而建立变元；

针对所述嵌套块实体而建立块参数；

针对所述嵌套块实体而建立块变量；以及

针对所述嵌套块实体而建立识别标签，并且，在包含层级的可追踪性的映射中，注册所述嵌套块实体。

9.根据权利要求1所述的系统，其中，所述ASLM平台进一步运行分裂过程。

10.根据权利要求9所述的系统，其中，所述分裂过程包括：

使嵌套块实体抽象化，以用于分裂成新的单元；

创建新的单元，并且，在数据字典中注册单元标识符；

针对所述新的单元而建立单元参数；

针对所述新的单元而建立单元变量；

将所述嵌套块实体的所述嵌套子逻辑转移至所述新的单元；

使封装于所述新的单元中的块实体和控制节点一般化；

针对所述新的单元而建立识别标签，并且，在高到低的可追踪性的映射中，注册所述新的单元；

引用所述新的单元而对所述嵌套块实体进行更新；

对所述嵌套块实体的识别标签进行更新，并且，对所述高到低的可追踪性的映射中的所述块实体进行更新，并且，针对原始单元而重复该更新过程。

Images