CN110262795B - 一种应用系统部署体系结构建模和验证方法 - Google Patents

Abstract

本发明提出一种应用系统部署体系结构建模和验证方法，属于电子信息技术领域。包括：步骤一：分析应用系统体系结构的部署需求，形成应用系统访问路径规划列表和应用系统体系结构部署规划图；步骤二：自底向上对四层树形结构的应用系统部署体系结构进行建模；步骤三：由设备类型服务调用图自动生成期望性质公式；步骤四：对建立的应用系统部署体系结构模型的连通性进行验证；步骤五：对路径上相邻设备类型进行互操作性验证；步骤六：结合连通性验证和设备互操作性验证结果。本发明采用高阶类型化应用系统体系结构建模和验证语言，结合模型驱动的软件工程中已有的方法和工程技术，逐层建模，在建模过程中可即时反映需求的完整性。

Description

一种应用系统部署体系结构建模和验证方法

技术领域

本发明属于电子信息技术领域，涉及Web应用软件部署的应用系统，具体涉及一种应用系统部署体系结构建模和验证方法。

背景技术

Web应用软件作为当前“互联网+”应用系统的核心组成部分，通过部署于运行环境产生应用系统体系结构。在科技的快速发展下，Web应用软件需要进行大量的软硬件结合，应用系统体系结构的构成和互操作变得越来越复杂，对于软硬件的部署变得困难重重。在需求设计阶段对应用系统部署体系结构进行建模以及验证可避免由于需求设计所造成的错误。

在应用系统部署体系结构的设计和验证中，随着云计算技术的发展和支撑工具的不断成熟，产生了众多实用工具和方法。研究人员提出的Nix系列部署方法及其工具，通过分析应用软件中组件之间的依赖性，对即将部署的软件进行多级版本化管理，同时通过丰富的部署策略可描述原子升级和降级、安全依赖和异构环境等部署要素，实现了应用软件的安全部署和透明的字节码部署。基于Nix的Disnix，增加了可扩展结构并支持自定义模块的部署，使得部署过程更为便捷。采用容器化管理待部署应用软件和部署环境的DevOps方法目前已成为主要趋势，该方法通过将应用软件开发团队和运维团队紧密结合，缩短了软件系统开发到上线部署的时间，使得应用软件能够在预期较短时间内得到快速有效地升级和部署。尽管上述方法在效率和效果上都较为明显，但仍缺乏系统的方法论以支撑应用系统部署体系结构在设计阶段的验证，从工业化的视角仍处于自动化生产的初期。

对此，可采用形式化建模方法对体系结构庞杂的应用系统部署体系结构进行设计，采用形式化规约方法进行需求期望性质的刻画，采用形式化验证方法进行设计阶段的验证。但已有的形式化方法往往需要采用多种形式化工具，更适合于较小规模的验证问题。并且一些方法在建模中采用迁移系统、自动机或Petri网，而验证中采用时态逻辑公式刻画需求期望性质，从而由于在建模和验证中不使用统一规则的方法容易造成较大的误差，应用系统体系结构越复杂误差越明显。

发明内容

本发明针对如何提高应用系统部署体系结构建模和验证的完整性和准确性的问题，采用高阶类型化应用系统体系结构建模和验证语言，结合模型驱动的软件工程中已有的方法和工程技术，面向云计算环境中的应用系统主动运维，提出了一种应用系统部署体系结构建模和验证方法。

本发明的一种应用系统部署体系结构建模和验证方法，对面向部署的应用系统执行如下步骤：

步骤一：分析应用系统体系结构的部署需求，形成应用系统访问路径规划列表和应用系统体系结构部署规划图。应用系统体系结构部署规划图包括应用系统的构成设备以及设备之间的连线。将应用系统部署体系结构的需求自顶向下分为应用系统、设备、功能类型以及设备功能四层树形结构，并进行统一编码。将应用系统体系结构部署规划图生成设备类型服务调用图，并转化为相同语义的XML文件，解析为具体的设计要求。

步骤二：自底向上对四层树形结构的应用系统部署体系结构进行建模，依次为基本数据类型层、基本接口类型层、设备类型层和体系结构框架类型层；建模时，根据设备类型服务调用图，生成各层的类型以及类型关系，并自动生成相对应的类型规则。

在构建基本数据类型层时，遍历应用系统相关软硬件，获得数据类型、扩展的数据类型和带标签的类型映射，构建类型关系，自动生成类型规则；其中，每一个设备功能定义为一个带标签的类型映射，每一个带标签的类型映射由标签名称以及输入参数到输出参数的映射构成。层内数据类型与扩展的数据类型之间存在聚合关系和参数关联关系。

构建基本接口类型层时，将每一个功能类型定义成一个基本接口类型，每个基本接口类型由类型变量、成员变量类型和函数类型构成，函数类型是基本数据类型层中的一组带标签的类型映射，类型变量是指带标签的类型映射中包含的类型变量，成员变量类型是根据带标签的类型映射中的调用关系所添加的数据类型。根据定义生成基本接口类型，构建类型关系及对应的类型规则。

构建设备类型层时，每个设备类型由一组基本接口类型聚合得到，与需求设计中的设备相对应，构建类型关系，自动生成类型规则。设备类型层中存在的类型关系有：设备类型与基本接口类型的聚合关系，包含同一个基本接口类型的设备类型之间的关联关系。设备类型的类型表达式与类型关系构成了设备类型层。

构建应用系统体系结构框架类型层时，每个结构框架类型包含一组设备类型，与需求设计中的应用系统相对应，自动生成类型关系和规则，应用系统体系结构框架类型层中存在的类型关系有：结构框架类型与设备类型的聚合关系，包含同一个设备类型的结构框架类型之间的关联关系。应用系统体系结构框架类型是由设备类型聚合而成的类型，应用系统体系结构框架类型的类型表达式与类型关系构成了应用系统体系结构框架类型层。

在对应用系统部署体系结构建模后，使用类型化判定算法TCA和关系判定算法RCA分别对类型以及类型规则进行正确性验证。

步骤三：由设备类型服务调用图自动生成可达路径上的设备类型序列及其关系，作为模型所需满足的期望性质公式。通过使用设备类型序列正确性判定方法来验证应用系统部署体系结构模型是否满足需求。

步骤四：对建立的应用系统部署体系结构模型的连通性进行验证。使用设备类型序列正确性判定算法，对期望性质公式里每个逻辑单元中的连通关系能否满足进行判定，通过输出结果，判断所创建的应用系统部署结构模型是否具备部署的连通性需求。

步骤五：对路径上相邻设备类型进行互操作性验证，使用设备类型序列正确性判定方法，对期望性质公式里每个逻辑单元中的可调用关系能否满足进行判定，通过输出结果，判断所创建的应用系统部署体系结构模型是否具备部署的互操作性需求。

针对系统级操作及其一组可达路径，进行λ求值，从而判定所创建的应用系统部署体系结构模型是否满足实际部署需求。

步骤六：结合连通性验证和设备互操作性验证结果，判定所设计的应用系统部署体系结构模型是否能够满足该应用系统面向实际部署的需求，如不能，根据验证过程找出错误节点以及原因，对模型进行调整。

本发明与现有技术相比，具有以下明显优势：

(1)本发明提出一种通用的面向部署的应用系统体系结构建模方法：本发明用形式化的方法描述应用系统体系结构的部署，使用类型定义将应用系统体系结构分成四层，并定义其类型间的关系，通用于各形式复杂的应用系统体系结构部署建模。

(2)本发明提出了一种面向部署的应用系统体系结构的需求满足验证方法：本发明基于高阶类型化应用系统体系结构建模和验证语言，结合模型驱动的软件工程中已有的方法和工程技术，逐层建模，在建模过程中可即时反映需求的完整性。建模完成后，可通过类型规则对连通性以及可互操作性进行验证，减少在后续开发中的损失。

(3)本发明可扩展性强：鉴于一个应用软件可运行环境的多样性，在构造接口类型时使用存在量词

修饰基本数据类型中的类型变量，即类型映射中包含类型变量，有助于进一步扩展其建模能力。

(4)本发明适用性强：使用类型系统对应用系统的软硬件进行统一描述，在建模和验证中使用同一个方法，对各应用系统均可适用。

附图说明

图1为本发明应用系统部署体系结构建模和验证方法总体构造图；

图2为本发明某案例的应用系统的体系结构部署规划图；

图3为本发明某案例的应用系统部署体系结构的设备类型服务调用图；

图4为本发明应用系统部署体系结构模型图；

图5为本发明TCA算法流程图；

图6为本发明RCA算法流程图；

图7为本发明设备类型序列正确性判定的流程图。

具体实施方式

为了便于本领域普通技术人员理解和实施本发明，下面结合附图对本发明作进一步的详细描述。

本发明为了提高应用系统部署体系结构建模和验证的完整性和准确性，可在建模和性质规约中采用类型、类型规则和求值规则进行刻画，在验证中利用模型中的规则可通过类型检查方法进行推理，并通过求值规则进行演算。所以，高阶类型化应用系统部署体系结构建模和验证语言通过定义类型和项的语法和语义，描述构成应用系统部署体系结构的类型和对象的结构，通过定义类型规则及其类型检查方法，判定类型关系是否成立，并使用存在量词

进一步扩展其建模能力，能够对各式复杂的应用系统体系结构进行建模和验证。

本发明基于高阶类型化应用系统体系结构建模和验证语言，设计基于模型驱动的应用系统部署体系结构建模和验证方法，在设计阶段有效地验证应用系统部署体系结构是否满足用户需求和服务质量要求。如图1所示，为本发明进行应用系统部署体系结构建模和验证的总体构架实现，本发明方法从需求出发，主要包括建模和验证两部分。根据需求对应用系统的部署环境进行设计，生成应用系统体系结构的部署规划图以及应用系统访问路径规划列表。将不同类型的软硬件设备及其功能经过多维度分类并进行编码生成设备类型服务调用图。根据设备类型服务调用图逐层进行应用系统体系结构建模，包括四层，自底向上依次为基本数据类型层、基本接口类型层、设备类型层以及应用系统体系结构框架层。建模结束后，由设备类型服务调用图生成期望性质公式，并以此验证该环境是否满足应用系统部署的连通性和互操作性的实际要求。下面说明本发明方法的各实现步骤。

步骤一：分析应用系统体系结构的部署需求，构造设备类型服务调用图作为应用系统部署体系结构的设计要求。应用系统部署体系结构由网络设备、硬件设备、基础软件和应用软件及其相关配置组成。其中，网络设施、硬件设备应根据行业实际需求采购并根据应用系统体系结构要求进行实施和配置，基础软件和应用软件则根据应用系统体系结构要求进行安装或部署。步骤一的实现包括如下步骤1.1～1.4。

步骤1.1：分析应用系统的应用软件组成和应用系统部署需求，根据需求列出应用系统体系结构的构成要素，一般包括网络设备、硬件设备、基础软件和部署或运行于基础软件上的应用软件及其相关配置组成；网络设备和硬件设备包括：防火墙、路由器、应用服务器、数据库服务器、文件服务器和存储服务器；基础软件包括操作系统、应用中间件、数据库管理软件。

步骤1.2：分析用户角色及其访问路径需求。不同类型的用户经由一些必要的设备到达应用系统区域后，根据其访问应用软件的不同，有不同的访问路径需求。

步骤1.3：根据上述分析刻画应用系统的体系结构部署规划图，并列出应用系统访问路径规划列表。如图2所示，应用系统的体系结构部署规划图包括应用系统的构成设备以及设备之间的连线。根据访问路径需求以及部署规划图的连线，得到应用系统的访问路径规划列表，为后续验证提供依据。

步骤1.4：在步骤1.3的基础上，将应用系统部署体系结构的需求自顶向下分为应用系统、设备、功能类型和功能的四层树形结构，并进行编码。例如，将系统类型编码为AFW_i，软硬件设备顺序编码为Dev_r，功能类型编码为T_j ^intf，各项功能编码为M_k，i、r、j、k均为正整数，用来进行编号。同时将部署规划图生成设备类型服务调用图G_ASA，一个设备类型服务调用图G_ASA如图3所示，得到应用系统体系结构间的调用关系，以此作为应用系统部署体系结构的设计要求。

如图3所示，设备类型服务调用图G_ASA是一个有向图，其中每个节点标记为“设备类型编号！功能类型编号.功能1,功能2,…”形式，每一条边标记为“功能类型编号.功能1；功能2…”形式分别表示访问路径上每个相关设备以及跳转至下一个节点所要触发的功能。例如，图中的节点Dev₅！T₉ ^intf.M₂₅,M₂₆,M₂₇,M₂₈有一条指向节点Dev₆！T₁₁ ^intf.M₃₆,M₃₇,M₃₈,M₃₉的边T₉ ^intf.M₂₅；M₂₆；M₂₇，这表示设备Dev₅通过功能类型T₉ ^intf的功能M₂₅；M₂₆；M₂₇可到达Dev₆！T₁₁ ^intf.M₃₆,M₃₇,M₃₈,M₃₉节点。将设备类型服务调用图转化为相同语义的XML文件，输入系统进行解析，即可以得到具体的设计要求。

由设备类型服务调用图G_ASA可得到具体设计要求

其中

为应定义的接口类型，S^M为应定义的接口类型方法，S^entry表示开始节点集合，

S^terminate表示终止节点集合，

R为接口类型方法之间的调用关系和设备类型服务调用关系集合。

设备类型服务调用图G_ASA为应用系统部署体系结构各层建模和验证提供了依据。如图3所示，将每一条基本功能对应到带标签的类型映射，将每个功能类型对应到基本接口类型，将一组功能类型对应到相应的设备类型，则可逐层构建应用系统部署体系结构。在验证部分，可由设备类型服务调用图自动生成可达路径上的类型序列及其关系，作为模型所需满足的期望性质公式。

步骤二：逐层对应用系统部署体系结构建模。应用系统部署体系结构细分为基本数据类型、基本接口类型、设备类型和体系结构框架类型。

如图4所示，对应应用系统部署体系结构的需求的四层树形结构，自底向上建模，依次为基本数据类型层M_bd、基本接口类型层M_bti、设备类型层M_dev和应用系统体系结构框架类型层M_frwk，每层建模包括定义类型、层内与相邻层之间类型关系，并自动生成所对应的类型规则，作为后续验证的凭证。下面说明对四层结构依次建模的过程，包括步骤2.1～2.4。

步骤2.1：根据设备类型服务调用图，对基本数据类型层建模。基本数据类型层包括数据类型、扩展的数据类型和带标签的类型映射，以及该层的类型关系集合。所建立的基本数据类型模型M_bd如下：

其中，T₁,…,T_m表示基本数据类型，R_i(T_j,T_k)表示类型T_j和T_k的关系。m为该层的基本数据类型个数，R¹为基本数据类型层中的基本数据类型关系集合，L_bd为该层类型关系个数。

进行基本数据类型层建模时，可分为如下步骤2.1.1～步骤2.1.2的过程执行。

步骤2.1.1：根据应用系统相关软硬件，定义数据类型、扩展的数据类型和带标签的类型映射。

本发明中将应用系统初始环境中所涉及到的不同类、对象、参数、变量、基本操作定义为数据类型或扩展的数据类型，对数据类型进行编号为B_i，i为数据类型编号。例如：将IP地址看成一个数据类型，命名为IPAddress，编号为B₂；将交换机端口号看成一个数据类型，命名为PortNo，编号为B₇₉；将协议名看成一个数据类型，命名为Protocol，编号为B₁；将枚举真假值看成一个数据类型，命名为Boolean，编号为B₇₈。

有一些数据类型是由几个数据类型聚合而成的，将其定义为扩展的数据类型，分别编号为BE_i，i为数据类型编号。因为是由已定义的数据类型聚合而成，系统自动生成其表达式。例如，远程连接参数，是由IP地址、交换机端口号和协议名组成的，将这个类型命名为IPAddress×PortNo×Protocol，编号为BE₆₉，并自动生成其表达式IPAddress×PortNo×Protocol。

遍历应用系统的软硬件，获得的数据类型B_i和扩展的数据类型BE_i组合成基本数据类型T₁,…,T_m，获得的带标签的类型映射反映了所涉及的类型关系。将步骤一得到的每一个设备功能M_k定义为一个带标签的类型映射，每一个类型映射由标签名称以及输入参数到输出参数的映射构成，并将其与需求中的对应功能相关联，得到需求与类型映射之间的关系。

例如，编号为M₇₃的设备功能是远程连接命令功能，定义其所带标签remoteConnect，输入为远程连接参数，输出为枚举真假值，是远程连接参数到枚举真假值类型的映射。根据该功能的定义生成带标签的类型表达式为remoteConnect:IPAddress×PortNo×Protocol→Boolean，同时生成对应的关系类型规则为remoteConnect:BE₆₉→B₇₈。

步骤2.1.2：根据类型定义，自动生成相应的类型关系及类型规则，供后续验证使用。基本数据类型层的类型关系以聚合关系和输入输出参数关联关系为主。其中，层内数据类型与扩展的数据类型之间存在聚合关系，例如，远程连接参数类型，表达式为IPAddress×PortNo×Protocol为聚合类型，聚合类型关系数为2。层内数据类型与扩展的数据类型之间还存在参数关联关系，例如，扩展的数据类型IPPacket→TCPPacket存在的参数关联关系为2，IPPacket是指IP(网际协议)包，TCPPacket是指TCP(传输控制协议)包。除此之外，还存在层内数据类型与扩展的数据类型与带标签的类型映射之间的参数关联关系。例如，带标签的类型远程连接命令功能M₇₃，其输入为扩展的基本数据类型远程连接参数BE₆₉，所以生成输入参数关联关系为

其输出为基本数据类型枚举真假值B₇₈，所以输出参数关联关系为

其中，in/<<param>>表示输入参数关系，out/<<param>>表示输出参数关系。

由步骤2.1.1得到基本数据类型T₁,…,T_m，由步骤2.1.2得到类型关系R_i(T_j,T_k)，建立模型M_bd。

步骤2.2：在基本数据类型层的基础上，根据树形需求结构中的功能类型需求，对基本接口类型进行建模，生成基本接口类型以及关系。所构建的基本接口类型模型M_bti如下：

其中，

为第j个基本接口类型，

为层内的基本接口类型

与

的关系，R_j(T_i ^intf,T_k)为基本接口类型

与基本数据类型T_k的层间关系；n表示基本接口类型层中基本接口类型的个数；

为层内的基本接口类型关系个数，

为层间的基本接口类型与基本数据类型关系个数；R²表示基本接口类型层的类型关系集合，包括层内与层间的类型关系。对于一个基本接口类型，

{[l:X]^*,[l:T₁]^*,[l:T₂]^*methods:{[l:T₁→T₂]^*}}}表示T^intf属于基本接口类型层，X为类型变量，l:T₁→T₂表示一个带标签的类型映射，l为标签，T₁和T₂是两个不同的基本数据类型，[l:X]表示l在类型X的值域中，[l:X]*表示[l:X]的集合幂集，

为存在量词。[l:T₁]表示l在类型T₁的值域中，[l:T₁]^*表示[l:T₁]的集合幂集，[l:T₂]表示l在类型T₂的值域中，[l:T₂]^*表示[l:T₂]的集合幂集。

本发明实施例进行基本接口类型层建模的过程包括如下步骤2.2.1和2.2.2。

步骤2.2.1：由于应用系统体系结构依赖于应用软件的部署过程，因此在抽象过程中主要面向部署，不考虑和部署无关的部分。将每一个功能类型定义成一个基本接口类型，每个基本接口类型由类型变量、成员变量类型和函数类型构成。其中，函数类型源于基本数据类型层中的一组带标签的类型映射，即所包含的功能；类型变量是指带标签的类型映射中包含的类型变量；成员变量类型是根据带标签的类型映射中的调用关系添加的数据类型。并且由于应用系统体系结构存在多样性，在建模中使用存在量词

修饰类型变量，抽象软硬件。

在添加基本接口类型到模型中时，要选择添加其可调用的其它接口类型以及所包含的基本数据类型，并将其与需求中的对应功能类型相关联，得到需求与类型映射之间的关系。

例如用户服务功能类型，命名为基本接口类型UserInterfaceService，其编号为T₃ ^intf，定义其包含带标签的类型映射：启动网络M₉、关闭网络M₁₀、网络连通性检查M₁₁、远程连接命令M₇₃和启动执行命令M₇₄。由上得出基本接口类型UserInterfaceService T₃ ^intf的函数类型和类型变量表示如下：

协议Protocol为类型变量，函数类型methods为包含的一组带标签的类型映射。

步骤2.2.2：根据对基本接口类型的定义，由给定环境直接识别出基本接口类型层的类型关系，并自动生成对应的类型规则。基本接口类型层的类型关系以本层方法关联关系和成员关联关系为主。

例如基本接口类型UserInterfaceService T₃ ^intf含有方法关联个数5个，即为启动网络M₉、关闭网络M₁₀、网络连通性检查M₁₁、远程连接命令M₇₃和启动执行命令M₇₄，生成的类型规则如下：

同时，含有成员变量类型有9个，即为InterfaceId、IPAddress、Boolean、PingResult、PortNo、Protocol、executeCMD、FileName和Option，对应的数据类型编号分别为B₇₇、B₂、B₇₈、B₄₉、B₇₉、B₁、B₁₁₈、B₁₁₇、B₁₁₉，生成的类型规则如下：

上面表示中，箭头上面的“member”表示成员关联关系，“methods”表示方法关联关系。

每个基本接口类型对应于设计要求中某个设备的一个功能类型，而根据设备类型服务调用图，每个功能类型对应一组功能，因此在基本接口类型建模过程中系统会提示当前接口类型还需聚合哪些功能，即带标签的映射类型。

步骤2.3：对设备类型层建模，定义设备类型，自动生成类型规则。并将建立的设备类型与需求设计树形结构中的对应设备相关联。所构建的设备类型层M_dev表示如下：

其中，D_i表示第i个设备类型，x表示设备类型总数；R_i(D_j,D_k)表示层内的设备类型D_j和D_k之间的类型关系，

表示层间的设备类型D_i与基本接口类型

之间的类型关系，R³表示设备类型层的类型关系集合，包括层内与层间的类型关系；

表示设备类型层内的类型关系个数，

表示设备类型层与基本接口类型层间的类型关系个数；

表示设备类型D_i所包含的k个基本接口类型。

构建设备类型层的过程包括如下步骤2.3.1和2.3.2。

步骤2.3.1：如图4所示，每个设备类型由一组基本接口类型聚合而成。定义设备类型，包括定义名称、所含基本接口类型及其所对应的需求设计中的设备。例如，定义一个名为Web服务器的设备类型，设编号为Dev₅，包括：IP服务接口类型IPNWService，编号为T₁ ^intf；以太网服务接口类型ETHService，编号为T₂ ^intf；用户服务接口类型UserInterfaceService，编号为T₃ ^intf；Web服务器管理接口类型WSServerManager，编号为T₈ ^intf；以及HTTP协议处理接口类型HTTPProtocolHandler，编号为T₉ ^intf；并将其与需求设计中的Web服务器相关联。

步骤2.3.2：根据定义自动生成类型间的关系及其类型规则。设备类型层的类型关系以类型关联和层间聚合关系为主。例如，Web服务器设备类型Dev₅，由五个接口类型聚合而成，聚合关系数为5，五个功能对应的接口类型T₁ ^intf、T₂ ^intf、T₃ ^intf、T₈ ^intf、T₉ ^intf与这一设备对应的类型Dev₅之间存在聚合关系，生成的关系类型规则为

箭头上的“_◇”表示聚合关系。在设备类型层中，存在几个设备类型包含同一个基本接口类型的情况，他们之间就存在了类型关联关系。例如，有7个设备类型聚合了编号为T₃ ^intf的用户服务接口类型UserInterfaceService，由此产生的设备类型关联关系为7*(7-1)/2，即为21个。

每个设备类型对应于设计要求中的某个设备，若某个设备的建模中没有聚合足够多的接口类型，则因缺少对应的聚合类型关系，而使得该设备相关的验证不能通过。

步骤2.4：设备类型层是构造应用系统部署体系结构框架的基础，有了完整的设备类型后，可对应用系统体系结构框架类型层建模。所构建的应用系统部署体系结构框架类型层模型M_frwk如下：

其中，AFW_i是第i个应用系统体系结构框架类型，每个结构框架类型AFW_i包含一组设备类型，D_i1,…,D_ik表示属于框架类型AFW_i的k个设备类型，v是结构框架类型层中的结构框架类型个数，R_ij(AFW_i,D_k)是层间结构框架类型AFW_i与设备类型D_k的关系，R⁴是应用系统体系结构框架类型层与设备类型层的层间关系集合，L_frwk是应用系统体系结构类型层与设备类型层之间的层间关系个数。

构建应用系统体系结构框架类型层的一个实现过程如步骤2.4.1和2.4.2所述。

步骤2.4.1：应用系统体系结构框架类型是由设备类型聚合而成的类型。定义应用系统体系结构框架类型包括定义其名称、所含设备类型和所对应的需求设计中的应用系统。例如定义一个名为A的应用系统体系结构框架类型，编码为Frwk₁，定义其由万兆交换机Dev₂、光纤交换机Dev₃、Soc服务器Dev₄、Web服务器Dev₅、应用服务器Dev₆、认证服务器Dev₇、存储服务器Dev₈、数据库服务器Dev₉、堡垒机Dev₁₀、防火墙Dev₁₁以及数据库审计Dev₁₂聚合而成，并将其与需求设计中的A应用系统相关联。

步骤2.4.2：由定义可自动生成层内以及与设备类型层之间的关联关系，并生成类型关系和规则，供后续验证使用。应用系统体系结构框架类型是由设备类型聚合而成的，所以应用系统体系结构框架类型层与设备类型层之间存在聚合关系。同时，若几个应用系统体系结构框架类型包含同一个设备类型，那么这几个应用系统体系结构框架类型之间存在类型关联关系。

应用系统体系结构框架类型对应于完整的设计要求，若在建模中没有聚合足够多的设备类型，则因缺少对应的聚合类型关系，而使得相关的验证不能通过。

至此，完成了应用系统部署体系结构的逐层建模。

为保证定义的类型以及类型规则的正确性，如图5和图6所示，使用类型化判定算法TCA和关系判定算法RCA分别对类型和类型规则进行正确性验证。

如图5所示，对于给定的任意一个系统、设备、功能类型以及设备功能，利用TCA递归验证该项是否在已定义的类型中，若在，属于哪一种类型。首先遍历所有类型规则集合S_Types，检查给定项t是否与某条规则TR_i分母中的项通过合一代换进行匹配，若找不到与t匹配的项，验证不通过；若匹配则进一步检查这条类型规则是否存在分子，若存在则依次检查每一个分项t_k的类型；若TR_i没有分子，说明类型检查已经到了直接判断项t_k所属类型，并判断是否属于类型集合S_Types，若属于则说明t_k得到匹配；若所有的t_k得到匹配说明t的类型可以确定，并且属于S_Types。此处的类型规则中，分母是指结果，分子是指条件，即规则中满足分子则分母成立。

类似地，如图6所示，利用RCA递归验证给定的两个类型T₁和T₂及相关可能的关系R。此处的T₁和T₂是四层树形结构模型中任一类型。为此，首先遍历所有关系类型规则集合

检查R(T₁,T₂)是否与某条规则TR_i的分母可以通过合一代换进行匹配，若匹配则进一步检查这条类型规则是否存在分子，若存在则依次检查分子中的每一个前提C_k(t_k,T_k1,T_k2)是否满足，每个C_k(t_k,T_k1,T_k2)形如t_k或者形如R(T_k1,T_k2)；若TR_i没有分子，则说明满足TR_i分母所示类型关系，直接判断R(T₁,T₂)的所属类型；若所有的C_k(t_k,T_k1,T_k2)均得到满足，说明R(T₁,T₂)可以确定，并且属于S_relational。其中，S_relational是所有关系类型规则集合，S_TypeRules是所有的类型规则集合，是关系类型规则和结构类型规则的集合。对于C_k(t_k,T_k1,T_k2)，其中的t_k是指类型T_k1和T_k2存在类型关系的条件。

步骤三：由设备类型服务调用图反映的调用关系，将应用系统的访问路径规划列表中的路径对应为一组设备类型序列。得到的所有的设备类型序列及其类型关系即为应用系统部署体系结构模型所需满足的期望性质公式，通过使用设备类型序列正确性判定方法来验证应用系统部署体系结构模型是否满足需求。由于本发明考虑的是部署环境，在实际的检测中也是检查设备级的连接和操作，所以此处考虑使用设备类型序列进行验证。

如图7所示，设备类型序列正确性判定方法的输入为设备类型序列，输出布尔值作为判断结果。设输入设备类型序列为T₁,T₂,…,T_m，其类型关系集合为R₁,T₂,…,R_k，m为设备类型个数，k为类型关系个数。对设备类型序列中的任意两个设备类型T_j,T_k，得到两设备类型的关系R(T_j,T_k)，通过RCA对关系R(T_j,T_k)进行验证，遍历整个设备类型序列，直到完成对序列中任意两个设备类型及其类型关系的验证。当验证不通过时，代表设备类型序列正确性有问题，应用系统部署体系结构模型不满足需求，则需要根据验证不通过的设备关系来对模型进行调整，当验证通过时，代表应用系统部署体系结构模型满足需求。

部署需求包括连通性需求和互操作性需求两部分，所以本发明要对应用系统部署体系结构模型的连通性和设备互操作性进行验证。应用系统部署体系结构模型中的类型序列，需满足以下类型关系：

(1)类关联关系：

此处表示T_i,T_j存在类关联关系R；

(2)对象关联关系：

此处表示T_i,T_j存在对象关联关系a：R；

(3)参数关联关系：

表示T_i是T_j的输入参数，或

表示T_i是T_j的输出参数；

(4)子类型关联关系：S＜:T，其中S,T∈{T₁,…,T_n}；此处表示S是T的子类型；

(5)方法关联关系：

此处表示T_i与T_j存在方法关联关系；

(6)成员类型关联关系：

此处表示T_i是属于T_j的成员member；

(7)方法可调用关系：

此处表示T_j可调用T_i，invokable表示可调用的；

(8)可传参调用关系：

此处表示T_j可传递参数来调用T_i；

(9)接口类型可调用关系：

其中T_i ^intf,

此处表示两个接口类型T_i ^intf,和

M_k是T_i ^intf,的方法，M_l是

的方法，若

则接口类型

可调用T_i ^intf,。

(10)设备类型可连通关系：

或<D_s|D_t>_T，其中D_s,D_t,T∈{T₁,…,T_n}；此处表示D_s和D_t为两个设备类型，他们之间可连通；

(11)设备类型服务可调用关系：

其中D_s,D_t∈{T₁,…,T_n}。此处表示若两个设备类型D_s和D_t，以及D_s的接口类型T_i ^intf,和D_i的

接口类型，并且若

则D_s和D_t之间可以通过指定的服务可访问。

步骤四：对创建应用系统部署体系结构模型的连通性进行验证。可选择一条或多条已生成的设备类型序列进行连通性判定，通过设备类型序列正确性判定方法输出判定结果以及不通过原因，从而判断所创建的应用系统部署体系结构模型是否具备部署的连通性需求。

步骤五：对路径上相邻两个设备类型的互操作性进行验证。

步骤5.1：可选择一条或多条已生成的设备类型序列或者任意选择两个设备类型进行互操作性判定，通过设备类型序列正确性判定方法输出判定结果以及不通过原因，从而判断所创建的应用系统部署体系结构模型是否具备部署的互操作性需求。

步骤5.2：求值验证。选择某条设备类型序列或者路径上两个相邻设备类型，给出所含参数和输入参数，通过λ演算模拟执行，验证能否得到期望的值。λ演算是一套从数学逻辑中发展，以变量绑定和替换的规则，来研究函数如何抽象化定义，函数如何被应用以及递归形式系统。

步骤六：若每一条路径的连通性验证和互操作性验证均通过，则可判定该路径满足需求。若所有的路径都满足需求，则可判定所设计的应用系统部署体系结构模型能够满足该应用系统面向实际部署的需求。反之，有一项不通过，则应用系统部署体系结构建模过程存在错误，不能满足需求，根据验证的过程找出错误节点以及原因，对模型进行调整。

通过上述过程，本发明在面向部署的基础上，采用了应用系统体系结构模型，根据自底向上的顺序，逐次构建基本数据类型层M_bd、基本接口类型层M_bti、设备类型层M_dev和应用系统体系结构框架类型层M_frwk四层，以及自动生成层内与层间类型之间关系对应的类型规则。使用设备类型服务调用图G_ASA用以刻画部署要求，生成类型序列用以刻画需求期望的性质，并给出了相应的基于类型检查的验证方法。之后，将应用系统体系部署结构模型所期望的性质P，利用高阶类型化应用系统部署体系结构建模和验证语言中设备类型序列正确性判定算法，验证P是否成立，以支持在设计阶段对应用系统部署体系结构进行需求满足验证，支持因需求变更和环境变化引起的应用系统部署体系结构重构和演化，支持应用系统部署体系结构基本组成部分及其关系的检索和查询，并支持测试和评测，从而实现在需求设计阶段，对应用系统部署体系结构的建模和验证，避免了由于需求设计所造成的错误。

Claims (9)

1.一种应用系统部署体系结构建模和验证方法，其特征在于，对面向部署的应用系统执行如下步骤：

步骤一：分析应用系统体系结构的部署需求，形成应用系统的访问路径规划列表和体系结构部署规划图；应用系统的体系结构部署规划图包括应用系统的构成设备以及设备之间的连线；将应用系统部署体系结构的需求自顶向下分为应用系统、设备、功能类型以及设备功能四层树形结构，并进行统一编码；将应用系统体系结构部署规划图生成设备类型服务调用图，并转化为相同语义的XML文件，得到设计要求；

步骤二：自底向上对四层树形结构的应用系统部署体系结构进行建模，依次为基本数据类型层、基本接口类型层、设备类型层和体系结构框架类型层；建模时，根据设备类型服务调用图，生成各层的类型以及类型关系，并自动生成相对应的类型规则；

构建基本数据类型层时，遍历应用系统的软硬件，获得数据类型、扩展的数据类型和带标签的类型映射，构建类型关系，自动生成类型规则；其中，每一个设备功能定义为一个带标签的类型映射，每一个带标签的类型映射由标签名称以及输入参数到输出参数的映射构成；

构建基本接口类型层时，将每一个功能类型定义成一个基本接口类型，每个基本接口类型由类型变量、成员变量类型和函数类型构成，函数类型是基本数据类型层中的一组带标签的类型映射，类型变量是指带标签的类型映射中包含的类型变量，成员变量类型是根据带标签的类型映射中的调用关系所添加的数据类型；根据定义自动生成基本接口类型，构建类型关系及对应的类型规则；

构建设备类型层时，每个设备类型由一组基本接口类型聚合得到，与需求设计中的设备相对应，自动生成类型间的关系及类型规则，设备类型层中存在的类型关系有：设备类型与基本接口类型的聚合关系，包含同一个基本接口类型的设备类型之间的关联关系；

构建应用系统体系结构框架类型层时，每个结构框架类型包含一组设备类型，与需求设计中的应用系统相对应，自动生成类型关系和规则，应用系统体系结构框架类型层中存在的类型关系有：结构框架类型与设备类型的聚合关系，包含同一个设备类型的结构框架类型之间的关联关系；

步骤三：由设备类型服务调用图，将应用系统的访问路径规划列表中的路径对应为一组设备类型序列，得到的所有的设备类型序列及其类型关系作为模型所需满足的期望性质公式；

步骤四：通过对期望性质公式里每个逻辑单元中的连通关系进行判定，来对构建的应用系统部署体系结构模型的连通性进行验证；

步骤五：对期望性质公式里每个逻辑单元中的可调用关系进行判定，来对路径上相邻设备类型进行互操作性验证，进而判断所构建的应用系统部署体系结构模型是否具备部署的互操作性需求；

步骤六：结合连通性验证和设备互操作性验证结果，若每一条路径的连通性验证和互操作性验证均通过，则判定所构建的应用系统部署体系结构模型满足该应用系统面向实际部署的需求，如果存在验证不通过的路径，则根据验证过程找到错误结点以及原因，对模型进行修改。

2.根据权利要求1所述的方法，其特征在于，所述的步骤一中，所述的设备类型服务调用图表示如下：

G_ASA＝{S^Tintf,S^M,S^entry,S^terminate,R}

其中，G_ASA为设备类型服务调用图，S^Tintf为应定义的接口类型，S^M为应定义的接口类型方法，S^entry表示开始节点集合，

S^terminate表示终止节点集合，

R为接口类型方法之间的调用关系和设备类型服务调用关系集合。

3.根据权利要求1所述的方法，其特征在于，所述的步骤二中，在构建基本数据类型层时，将应用系统初始环境中所涉及到的类、对象、参数、变量、基本操作作为数据类型或扩展的数据类型；扩展的数据类型由已定义的数据类型聚合而成；基本数据类型层的类型关系包含有：数据类型与扩展的数据类型之间的聚合关系及输入输出参数关联关系；构建的基本数据类型层表示为M_bd如下：

其中，基本数据类型层中的基本数据类型表示为T₁,…,T_m，包括所述的数据类型和扩展的数据类型；基本数据类型T_j和T_k的关系表示为R_i(T_j,T_k)；m为基本数据类型层的基本数据类型个数，R¹为基本数据类型层的类型关系集合，L_bd为基本数据类型层的类型关系个数。

4.根据权利要求1或3所述的方法，其特征在于，所述的步骤二中，构建的基本接口类型层表示为M_bti，如下：

其中，

为第j个基本接口类型，n表示基本接口类型层中基本接口类型的个数；

为层内的基本接口类型

与

的关系，

为基本接口类型

与基本数据类型T_k的层间关系；R²表示基本接口类型层的所有的类型关系集合，

为层内的基本接口类型关系个数，

为层间的基本接口类型与基本数据类型关系个数；使用存在量词

修饰类型变量X，抽象软硬件，l:T₁→T₂表示一个带标签的类型映射，l为标签，T₁和T₂表示两个不同的基本数据类型，[l:X]表示l在类型X的值域中，[l:X]*表示[l:X]的集合幂集。

5.根据权利要求1或3所述的方法，其特征在于，所述的步骤二中，构建的设备类型层M_dev表示如下：

其中，D_i表示第i个设备类型，x表示设备类型总数；

表示设备类型D_i所包含的k个基本接口类型；R_i(D_j,D_k)表示层内的设备类型D_j和D_k之间的类型关系，

表示层间的设备类型D_i与基本接口类型

之间的类型关系，R³表示设备类型层的类型关系集合，包括层内与层间的类型关系；

表示设备类型层内的类型关系个数，

表示设备类型层与基本接口类型层间的类型关系个数；n表示基本接口类型层中基本接口类型的个数。

6.根据权利要求1或3所述的方法，其特征在于，所述的步骤二中，所构建的体系结构框架层表示为M_frwk，如下：

其中，AFW_i是第i个应用系统体系结构框架类型，每个结构框架类型AFW_i包含一组设备类型，D_i1,…,D_ik表示属于框架类型AFW_i的k个设备类型，v是结构框架类型层中的结构框架类型个数；R_ij(AFW_i,D_k)是层间结构框架类型AFW_i与设备类型D_k的关系，R⁴是应用系统体系结构框架类型层与设备类型层的层间关系集合，L_frwk是应用系统体系结构类型层与设备类型层之间的层间关系个数。

7.根据权利要求1所述的方法，其特征在于，所述的步骤二中，在对应用系统部署体系结构建模后，使用类型化判定算法TCA和关系判定算法RCA分别对类型以及类型规则进行正确性验证。

8.根据权利要求1所述的方法，其特征在于，所述的步骤三中，通过使用设备类型序列正确性判定方法来验证应用系统部署体系结构模型是否满足需求，遍历整个设备类型序列的任意两个设备类型，对两设备类型的关系通过RCA进行验证，直到验证完整个设备类型序列中所有两设备类型的关系，当都通过RCA验证时，表示建立的应用系统部署体系结构模型满足需求，否则表示应用系统部署体系结构模型不满足需求。

9.根据权利要求1所述的方法，其特征在于，所述的步骤五中，选择某条设备类型序列或者路径上两个相邻设备类型，给出所含参数和输入参数，通过λ演算模拟执行，验证能否得到期望的值，从而判定所构建的应用系统部署体系结构模型是否满足实际部署需求。

Images