一种基于中间件的组件系统性能预测方法和系统

摘要

本发明属于计算机网络和数据通信技术领域，具体涉及一种基于可嵌套模型的中间件性能预测方法，以模型转换分析为基础，通过嵌套分析的方法构建中间件完整性能模型，并最终生成预测结果。本发明通过采用性能分析与编排模块及中间件性能影响因素库，将原始模型将被转化为分层排队网模型，并构成该组件完整的性能模型，通过分析工具LQNS和模拟工具LQNSim进行求解，获得基于中间件的组件系统性能预测的数据。本发明支持多中间件类型、多中间件实现产品和多运行平台，将系统建模与性能预测过程统一，无须设计人员花费额外精力进行性能建模。

说明书

技术领域

本发明属于计算机网络和数据通信技术领域，具体涉及一种基于中间件的组件系统性能预测方法，以模型转换分析为基础，通过嵌套分析的方法构建中间件完整性能模型，并最终生成预测结果。

背景技术

中间件是位于平台(硬件和操作系统)和应用之间的通用服务，这些服务具有标准的程序接口和协议。分布式应用软件借助它在不同的技术之间共享资源，用于解决网络分布异构问题，帮助用户灵活、高效地开发和集成复杂的应用软件。已有大量中间件技术标准及其产品在业界得到广泛应用，比如CORBA、EJB等。

中间件技术为设计人员提供了一个统一的、高效的、简化的设计平台，为符合其标准的组件提供了位置透明性、语言独立性和事件驱动等特性，使应用程序在设计开发时无需考虑通信协作的实现细节。但与此同时，中间件技术也为组件性能带来影响，而性能又是一个软件系统关键的质量属性，是用户满意度的重要衡量指标，也是设计人员不可忽视的重要因素。

为解决这个问题，一个可行的方案是在系统设计初期预测系统性能。在系统尚未实现之前预见出设计中存在的性能缺陷，辅助设计人员尽早修改设计，从而减少后期修复所需要的大量人力和物力的投入，缩短系统性能调优周期。

然而，在预测中间件系统性能的时候，问题又变得异常复杂。系统性能不再是用户程序所能控制的代码逻辑，而是包括支持组件运行的中间件和第三方组件实现逻辑在内的复杂体系。这些影响因素可分为中间件自身的性能影响因素，中间件为组件自动加载的横切关注点执行逻辑的影响因素和由组件调用的其它服务或组件的影响因素等。对普通设计人员来说这些是透明的，他们并不关心底层中间件的具体实现。

已有一些研究针对如何构建软件自身的性能模型展开，另一些研究则进一步考虑到中间件性能影响因素，但是它们均未全面系统的为应用设计人员提供一种快捷高效的针对中间件系统的建模与分析方法。

Woodside提出了一种用于分析软件性能的数学模型(M.Woodside，“The StochasticRendezvous Network Model for Performance of Synchronous Client-Server Like DistributedSoftware”，IEEE Transactions on Computers，Vol.44，No.1，January 1995，pp.20-34)，并进一步将其演化为分层排队网模型(Layered Queuing Network)，之后又改进了他所提出的将软件体系结构转换为此数学模型的方法(M.Woodside，“From Annotated Softwae Designs(UMLSPT/MARTE)to Model Formalisms”，LNCS 4486，2007，p.429-467)。但上述方面并不适用于中间件系统。针对中间件影响，他提出了一种基于此数学模型设计的模版驱动的EJB组件性能预测方法(J.Xu，M.Woodside，“Template-Driven Performance Modeling of Enterprise JavaBeans”，Proc.Workshop on Middleware for Web Services，2005.pp.57-64.)，该方法最大的局限在与应用设计人员并不了解此数学模型，不便于根据需求调整或设计子模块的性能影响因素。同时，他又指出了研究一种自动分析设计人所不涉及部分性能影响因素的重要性(M.Woodside，“The Future of Software Performance Engineering”，IEEE Future of SoftwareEngineering，2007，pp.171-187)。

Shen提出了一种面向方面的性能建模方法(H.Shen，“Performance Analysis of UMLModels using Aspect Oriented Modeling Techniques”，LNCS 3713，2005，PP.156-170)，分析由面向方面技术构建的系统性能。但该方法只适用于通用软件的问题，而并未将中间件因素考虑在内。

Verdickt提出了一种为UML软件模型自动引入中间件性能属性的方法(T.Verdickt，“Automatic Inclusion of Middleware Performance Attributes into Architectural UML SoftwareModels”，IEEE Transactions on Software Engineering，Vol.31，No.8，August，2005，pp.695-711)。该方法，以模型驱动(J.Miller and J.Mukerji，“MDA Guide，Version 1.0.1，”June2003.)为基础，允许设计人员以声明式的方法将中间件影响因素和组合其它组件带来的影响因素考虑进来，但并未分析中间件自动加入组件的横切关注点执行逻辑，同时这种其声明的影响因素粒度较大，并不能精确的刻画影响因素。

发明内容

针对上述问题，本发明依据中间件平台所具有的特性，设计出一种基于中间件的组件系统性能预测方法，将中间件性能影响因素和程序自身性能影响因素有机的组合起来。本发明吸取了几种已有的建模和预测方法的思想，并做出相应改进，精简冗余操作，使其更加适应中间件环境，为应用设计人员提供一种简捷高效的性能预测方法。

为了抽象出中间件性能影响因素，本发明提出了一种可嵌套模型。该套模型源于组件间的嵌套调用关系，而这种关系允许组件间无限次嵌套调用。以这种调用关系为基础，可嵌套模型定义为可被其它组件调用或调用其它组件的独立单元，描述了这部分操作的详细性能影响因素。性能分析也依据此嵌套关系设计，采用嵌套分析方法加载性能影响因素。原始输入模型将逐步被含有详细性能影响因素的可嵌套模型所拦截或替换，进而构造成一个完整的具有各种性能影响因素的性能模型。

另外，为了减轻设计人员的负担，本发明所设计的预测过程并不需要额外的性能建模工作，而是蕴含在系统建模过程中，利用建模的产出作为预测的输入。系统设计人员只需提供符合UML2.0规范的软件体系结构模型和相关声明信息，本发明将会自动查找、组织和分析各种影响因素信息，并最终生成性能预测结果。结果包括系统吞吐率、响应时间和资源利用率等性能相关数据。

本发明预测分析中间件性能的步骤如下：

1)载入软件体系结构原始模型，确定中间件平台，所述软件体系结构原始模型包括应用声明文件、部署图、协作图和活动图；

2)分割器分析原始模型，选取入度为0的节点作为当前待分析组件；

3)横切点分析器分析当前待分析组件是否存在未编织的横切关注点，若存在，编织横切关注点模板，并将原始模型转换为性能模型；

4)性能模板加载器分析当前待分析组件是否受中间件平台的影响，若是，加载中间件性能模板；

5)调度器分析当前节点所引用的其它组件是否存在未处理的，若存在转入步骤6)；否则判断当前节点是否存在父节点，若有父节点作为当前待分析节点重复步骤5)，否则转入步骤7)；

6)第三方组件引入器分析当前待分析组件是否为第三方组件，若是，则引入第三方组件模板，并调用分割器更新当前分析节点；否则直接更新当前分析节点，并返回步骤3)；

7)确定测试硬件环境，载入相关资源消耗数据，计算分析组件完整性能结果；

上述软件体系结构原始模型包括：

(1)UML部署图，描述组件的物理部署状态，以及它们之间的联系方式。

(2)UML协作图，描述不同组件间交互的请求模式。

(3)UML活动图，描述组件使用场景，并用SPT标注必须的性能影响因素。

本发明定义的可嵌套模型包括：

(1)通用方面模型，描述了横切关注点性能影响因素细节；

(2)中间件性能模型，描述了中间件自身性能影响因素细节；

(3)第三方组件模型库，描述了第三方组件性能影响因素细节；

上述预测方法使用了一个存储和查找可嵌套模型和系统资源消耗的数据库，包括：

(1)通用方面模型库，存放通用方面模型；

(2)中间件性能模型库，存放中间件性能模型；

(3)第三方组件模型库，存放第三方组件模型；

(4)平台相关资源库，存放平台相关系统资源消耗数据；

上述预测方法中步骤2、4、5是本发明的核心步骤，主要解决如下两方面问题：

(1)模型样式。设计恰当的模型结构和建模方法，使其既能刻画某类性能影响因素的细节，又便于设计人员理解和操作。本发明分别使用了通用方面模型、中间件性能模型和第三方组件模型。

(2)模型编排。编排的目的是将可嵌套模型组合到原始模型中，这里的原始模型指软件设计人员所提供的软件模型，构成一个完整的性能模型，从而将一个用户输入的原始模型转化为包含丰富信息的完整性能模型。分别采用了面向方面的编织技术，性能模型加载技术和第三方组件替换技术。

上述性能预测方法中在步骤4)中判断是否存在未引入的第三方组件是一个递归嵌套的过程，对每一个子服务或组件都会重复调用步骤2-4的步骤，直到当前分析的服务或组件不再调用其它服务或组件为止。

本发明提出了一种基于可嵌套模型的中间件性能预测方法，其优点如下：

1.支持多中间件类型、多中间件实现产品和多运行平台；

2.将系统建模与性能预测过程统一，无须设计人员花费额外精力进行性能建模；

3.统一考虑了中间件平台、横切关注点以及引用组件的性能影响因素。

4.各性能影响因素均以可嵌套模型形式存放，可在不同应用间复用；

5.预测结果可以辅助设计人员尽早发现设计缺陷，帮助他们筛选备选方案。

附图说明

图1为本发明性能预测的处理流程图。

图2为本发明总体结构图。

图3为本发明性能影响因素库的总体结构。

图4为模型转换算法的调度流程图。

图5为通用方面模型编织示意图。

图6为中间件性能模型加载示意图。

图7为第三方组件模型引入示意图。

具体实施方式

本节将介绍使用本发明预测中间件性能的具体实施方式。

本发明以软件体系结构为基础，使用模型驱动逐步求精的方法引入各种性能影响因素，并最终生成性能预测数据。软件体系结构采用UML模型描述，仅包含了设计人员所关注的系统基本结构及其调用关系，详细性能影响因素将在嵌套分析过程中逐步给出。预测过程涉及的关键技术包括面向方面的横切关注点性能影响因素分析技术，基于性能模型的中间件性能影响因素分析技术和申明式第三方组件引入技术。这些技术稍后将逐一介绍。

预测流程从软件体系结构的起始节点开始。首先分析中间件平台自动加载到组件的横切关注点(可配置服务，如事务、安全和监控等)的性能影响因素，并将其转换为性能模型。接着分析中间件平台自身给组件带来的额外性能开销(如通信、数据转换和资源竞争等)。之后判断当前组件是否引用了其它服务或组件，如果有则判断该节点是否为第三方组件，若是则引入第三方组件模板。然后根据调用关系更新当前带分析节点，并对当前节点继续嵌套分析，直到所有引用服务和组件分析结束。此时，整个嵌套调用关系中的组件、服务、横切关注点和中间件自身性能因素均包含在生成的完整性能模型当中。通过模型实例化与运行硬件环境相关的资源消耗参数，即可得到一个可计算的分层排队网模型。最后，使用分层排队网求解工具便可求解出最终性能预测的结果，包括系统吞吐率、响应时间、处理器利用率等数据。整个流程如图1所示。

为实现以上流程，本发明采用了如图2所示的总体结构。主要模块有UML模型载入模块、中间件性能影响因素库模块、性能分析与编排模块和分析计算模块四个部分。其中，性能分析与编排模块是整个算法的核心，负责分析组装各种性能影响因素。

一、UML模型载入模块

UML模型载入模块的主要任务是读取设计人员提供的UML模型和相关声明信息。考虑到不同UML工具所产生的UML模型存在的差异性，该模块由多个不同的载入器组成，每个载入器负责读取某种特定工具生成的UML图。这些载入器必须实现了同一个载入器接口，并返回具有相同结构的数据结构。该数据结构与UML模型一一对应，包含了UML模型最基本信息(如节点类型、节点名称、标注信息和关联关系等)，而不包含特定的与工具相关的细节。整个读取过程可以看作是一个文件读取和数据映射过程，除了需要过滤与工具相关的无用数据外，基本不需要作复杂转化工作。

该模块所需读取的数据包括应用声明文件、UML部署图、UML协作图和UML活动图等，在预测前由系统设计人员给出。

应用声明文件用于说明预测过程中需要的信息，使用XML格式文件定义，包括组件的类型、运行平台、横切关注点和引用其它服务与组件等信息。如下声明文件片断描述了用于阐述本发明的实施例所声明的信息。该实施例是一个运行在JBOSS应用服务器上的有状态会话Bean组件，配置了横切关注点，引用了第三方组件，并运行在指定的运行平台上。

除申明文件外，剩下的三项输入数据——部署图、协作图和活动图，组合在一起描述了本发明所需的软件体系结构，而系统资源消耗数据则由符合SPT规范(UML Profile forSchedulability，Performance and Time)的标注信息给出。

部署图描述了运行软件系统的物理硬件，以及如何将软件部署到硬件上。部署图通常包含节点以及节点之间的关系。节点是定义运行时的物理对象的类，它一般用于对执行处理或计算机的资源建模。给定一个部署图也就确定了组件的基本属性和物理部署结构，包括组件的类型以及组件与硬件的物理部署状态和连接方式等。

协作图是一种类图，它包含类元角色和关联角色，而不仅仅是类元和关联。类元角色和关联角色描述了对象的配置和当一个协作的实例执行时可能出现的连接。关联角色也可以被各种不同的临时连接所担当。为了提供组件间交互或通信模式，图中进一步给出了组件间通过何种方式交互，比如说“客户机/服务器”风格的同步方式或消息通信的异步方式等。标准的UML规范尚不支持这种交互方式的定义，但可采用其扩展机制或注释解决这个问题。

活动图是一种特殊形式的状态机，用于对计算流程和工作流程建模。活动图中的状态表示计算过程中所处的各种状态，而不是普通对象的状态。活动图具体给出了组件内部执行的过程，以及和其它组件间协作的形式。图中代表请求和响应事件的边要和协作图中定义的交互模式保持一致。比如有A和B两个组件，采用“客户机/服务器”方式交互，如果A有一个请求B的事件，那么B则需有返回A的事件。

通过组合这三种UML模型，可获得组件的内部行为、外部行为以及硬件环境。SPT则给出了各个活动所需要的系统资源，比如处理器运算消耗时间等。不同的UML图之间的元素通过命名关联。同一个组件在不同的图中须具有相同的名称，在部署图里表示了一个组件实例，在协作图里表示为一个分类器，而在活动图里表示为一个泳道。

本实施例所采用的原始模型包括三个组件和两台主机，组件分别是Client、Facade和Service；主机为ClientPC和ServerStation。

由部署图可以确定Client组件部署在ClientPC主机上，而Facade组件和Service组件则部署在ServerStation主机上。ClientPC主机和ServerStation主机通过网络连接。

由协作图可以确定Client组件和Facade组件，以及Facade组件和Service组件均是通过“客户机/服务器”风格的同步方式交互。

由活动图可以确定Client组件是一个客户组件，作为整个活动图的起始节点。它向Facade组件发出请求。Facade组件在接受到Client组件请求之前一直等待执行时机，在接受到Client请求后会执行准备操作(prepare)，然后请求Service组件的业务方法(doBusiness)，并等待结果。直到在接受到Service组件的返回结果，执行处理操作(process)，最后返回结果给Client组件，自身再次进入等待状态。

为了使模型可适应多种硬件环境，资源消耗需求采用参数化的形式给出(首字母以“$”标示)，实际值可在计算最终性能模型时赋值。考虑到用户组件实现可以非常简单，只是组合使用了其它系统服务或第三方组件，其自身并不消耗系统资源。因此，这种情况下设计人员此处可以不指定性能标注信息(SPT)。

总的来说UML模型载入模块可看作一个输入模块，负责读取不同来源的输入信息，并将这些信息统一转化为后续模块可操作的形式。

二、中间件性能影响因素库模块

中间件性能影响因素库模块用于存放了性能分析过程中需要的模型信息和运行平台信息，主要由一系列的通用方面模型库、中间件性能模型库、第三方组件模型库和平台相关资源库组成。

中间件性能影响因素库的总体结构如图3所示。因为不同类型的中间件平台之间，甚至是不同厂商实现的中间件产品之间均存在差异。所以，本发明采用树形结构组织整个库结构，应对这种差异性。顶层根节点代表整个库，其下按中间件种类分为中间件库，中间件库又进一步按照不同的实现产品和版本分为与特定运行平台对应的产品库。与产品库位同级的有一个共享库，它存放了可在不同中间件产品间共享的资源。产品库和共享库具有相同的库结构，即均包括四个子库：通用方面模型库、中间件性能模型库、第三方组件模型库和平台相关资源库。

通用方面模型库存放了分析横切关注点所需的UML方面模型信息；中间件性能模型库存放了中间件性能影响因素的性能模型信息和系统资源消耗数据；第三方组件模型库存放了被引用的第三方组件的模型信息和相关声明信息。所谓第三方组件，可以是中间件提供的服务，也可以是其它可用组件。其声明信息的内容和应用声明信息内容一致，用于说明第三方组件的类型等属性。而所谓平台相关资源库是一个存放组件活动对系统资源消耗的数据库，比方说处理器执行时间和线程池大小等。

库中的模型以命名方式加以区别，同一个子库中的模型不允许同名，但不同子库之间的模型允许同名。因为，对于同一个服务或者组件，在不同的中间件产品上可以有不同的具体实现。查找资源时从起始节点出发，首先搜索相应的中间件平台的子节点，接着选择对应的中间件产品，之后会在该产品的子库中搜索所需的信息，最后如果未查找到数据则转到公用库查找。因此，公用库中的数据可以被具体中间件产品所提供的数据所覆盖。

本发明存储在中间件性能影响因素库中的可嵌套模型，分别是通用方面模型、中间件性能模型和第三方组件模型。本发明的这些模型刻画了设计人员在描述系统体系结构时不曾考虑的，由中间件引起的，对系统产生显著性能影响的底层实现细节。与其它普通符合规范的图相比，本发明的这些模型必须指定输入与输出接口和必要的参数化数据，以便性能分析过程中将模型实例化并关联到设计人员提供的原始模型中。本实施例中，模型中各个活动对资源的消耗以参数形式给出(首字母用“$”标示)，实际值则根据硬件平台的不同存放在平台相关资源库中。

1.通用方面模型也是一个UML模型，刻画了横切关注点的性能影响因素，由部署图、协作图和活动图组成。本实施例中，与上下文相关的组件名和活动名采用了参数化的方式(首字母用“|”标示)预留，实际值将在方面模型编织到原始模型时指定。通用方面模型中活动图有一条输入边和一条输出边，它们的一端不与任何活动节点相连，在编织时才会与具体节点关联，分别代表着输入和输出接口。另外，它还具有一个连接点，由一个参数化的活动定义。所谓连接点就是横切关注点将要拦截的目标组件，默认情况下可以不给出部署图或协作图定义。

本实施例采用的通用方面模型只包含一个活动图，由|GenericAspect和|Target两个组件组成。|GenericAspect组件是一个代表横切关注点的方面，拥有一条输入边和一条输出边，分别对应着接受请求和返回结果事件。输入边的起点尚未与任何活动关联，终点则是该组件自身的一个活动，在完成所需操作之后将会请求|Target组件的|JoinPoint活动。|JoinPoint活动是一个连接点，但此时并不代表具体的操作逻辑，而是一个占位空间。当|JoinPoint活动所需操作完成之后，将返回|GenericAspect组件。此时|GenericAspect组件根据返回执行处理，之后会调用输出边所对应的事件，将请求返回给该方面的调用者。输出边的终点此时也尚未与具体的活动关联，起点则关联在上述活动上。

2.中间件性能模型是一个分层排队网模型，刻画了中间件自身性能影响因素和系统资源消耗数据。如图6所示，模型中的小圆圈代表接口，在组合过程中这些接口将于实际任务的请求关联。各任务对处理器资源的消耗以首字母为“$”的参数表示。这样，同一个模板便可以适用于不同的运行平台。原始模型在与方面模型进行编织后，将被转化为分层排队网模型，并与此性能模型组合构成该组件完整的性能模型。

本实施例采用的中间件性能模型由一个接口、四个任务(Task)和一个方面子模型(Aspect Submodel)组成。接口是中间件性能模型请求的入口，由外部任务调用。这四个任务分别是Container、ContServ、Bean thread Pool和CallBack任务。Container任务具有无限实例个数，表示该对象可以在不同请求间并发执行，不会受到同步操作的影响。ContServ任务只有一个实例，是关键区域竞争的抽象，模拟同步处理操作。Bean thread Pool模拟了实例池的大小，由参数$M控制池的规模。Bean实例的挂起与激活操作则由CallBack任务进行模拟，参数$p_s用于申明挂起与激活的概率。当接口被触发后，首先会调用Container的invokeMethod入口(Entry)，该入口又会调用Bean thread pool的getThread入口。getThread入口会调用方面子模型的接口和ContServ任务的prepareBean入口。prepareBean入口又会以$p_s的概率调用CallBack的passive/activate入口。方面子模型是为UML方面模型预留的占位空间，此处仅保留了一个接口的位置，实际模型是组件及其横切关注点转化而来的性能模型。

3.第三方组件模型也是一个UML模型，刻画了被组件引用的第三方组件所带来的性能影响因素，由部署图、协作图和活动图组成。与方面模型类似，活动图定义了输入和输出接口，但没有连接点的定义。因为第三方组件只需描述出调用者与被调者之间的嵌套调用关系，而不必刻画横切关注点这类插入到调用者与被调者之间的因素。默认情况下也不需要给出部署图和协作图的定义。在本发明中第三方组件被看作是具有独立的第三方组件模型的组件，声明信息中定义了原始模型中的使用到的第三方组件。若声明文件中指定了原始某行中某组件对应于某个特定的第三方组件模型，则该组件在分析时便作为第三方组件看待。

本实例采用的第三方组件模型由两个组件组成：Service和DataAccess组件。Service组件与原始模型中的Service组件对应，所不同的是在原始模型中Service组件只是一个抽象的描述，仅有doBusiness活动，而此处的Service组件则详细刻画了该组件的完整执行过程。与通用方面模型类似，该模型也具有一条输入边和一条输出边。输入边的终点关联着一个准备操作，执行完该操作后，将调用DataAccess组件的读取数据库数据活动。待读取操作完成将会返回到Service组件，并根据读取结果继续处理，处理结束将会调用DataAccess组件的保存活动进行保存。保存完毕会再次返回Service组件，此时该组件将出发输出边，将请求返回给调用者。

总的来说，中间件性能影响因素库主要用于存储各种可嵌套模型和系统资源消耗数据。可以看作预测算法的数据辅助模块，存储了不同类型中间件产品的性能影响因素。

三、整个算法的核心模块——性能分析与编排模块

性能分析与编排模块负责编排各个不同性能影响因素，构造一个完整的，包含中间件自身、横切关注点以及引用服务和组件的性能模型。由嵌套调度器、分割器、转换器、横切点分析器、性能模型加载器和第三方组件引入器组成。

1.嵌套调度器负责管理嵌套关系，关联其它模块，承担着协调者的角色。主要的功能是控制图1所示的算法流程，保证分析过程的正确性。另外它还负责保存转换过程中所需的上下文数据，包括原始性能模型、当前节点相关的数据、已转化出的性能模型等。

2.分割器用于分割组件间的原始关联关系，以便逐个对组件加入必要的性能影响因素。它从入度为0的节点开始，逐步遍历整个活动图，保证任何情况下只有入度为0的节点才被访问。因此我们使用拓扑排序的方法分割组件。

对一个有向无环图G进行拓扑排序，将G中所有顶点排成一个线性序列，使得图中任意一对顶点u和v，若<u，v>∈E(G)，则u在线性序列中出现在v之前。通常，这样的线性序列称为满足拓扑次序的序列，简称拓扑序列。

使用拓扑排序算法进行分割实质上是一个循环访问图中节点的过程，每次取出一个入度为0的节点作为当前节点，删除与其它节点的关联边，并将关联节点的入度减1。当前节点既是当前被访问节点，继续分割时如果图中仍有节点未取出则重复上述过程，否则算法结束。

3.转换器负责将UML模型转化为分层排队网的数学模型，本发明采用了一种基于中间模型的转换算法(Gordon P.Gu，”From UML to LQN by XML algebra-based modeltransformations”，WOSP’05，July 12-14，2005，P99-110)。它的作用是将三种UML图表示的软件体系结构原始模型转化为用数学模型表示的性能模型，便于与中间件性能模型组合并计算出最后的预测结果。转换过程以中间模型为基础，UML模型首先将被转化为中间模型，然后再由中间模型转化为数学模型。

本发明采用的转换算法需要在调度策略上做一定的改进，原有的转换算法是针对一个固定的UML模型转化为与之对应的性能模型，而本发明需要逐一转换出当前分析组件的性能模型，并且UML模型会在分析过程中不断被更新。所以当有更新发生时，需要重新转换模型，并遍历该模型选选取出新增的任务(task)包括调用它的请求(call)加入已转化性能模型。已转化性能模型存放在嵌套调度器中，后续操作均针对次已转化性能模型。因为当前节点已经稳定，不会再有变化，所以转化的出的结果也将稳定，从起始任务到当前任务之间结构便可以确定。转换的流程图如图4所示，转换算法仍采用原有方法。

横切关注点编织和第三方组件加载过程中均会使用到参数绑定技术，参数绑定的目的是将应用无关的模型转化为与特定应用上下文相关的模型，以便将其可以与目标组件编织在一起。绑定规则可以描述为如下形式的值对“(参数化元素名，实际元素集)”。

实际元素集可以是一个单一的元素名也可以是一个有“->”符号连接的元素集。如A->B，A是该集合的起始活动，B是该集合最后执行的活动，它们之间可以存在诸多复杂活动。被一个方面所拦截的活动可能比较复杂，不是一个简单的单一活动，该集合所定义的元素集合需要涵盖被拦截请求的所有活动。本实施例采用如下绑定规则。

通过使用上述绑定规则，通用方面模型中各个参数的在实际应用中的值将被指定。在本实施例里，绑定前方面模板并不知道它所拦截哪个目标组件，但在绑定后AspectModel组件将拦截Facade组件prepare到process之间的操作。

4.性能分析与编排模块的三个关键子模块，分别为横切点分析器、性能模型加载器和第三方组件引入器。它们各自负责分析不同方面对系统性能影响，并将这些影响因素通过不同的形式组合到原始模型中。

(a)横切点分析器负责分析由中间件动态加载的横切关注点所引起的性能影响因素，用到面向方面的横切关注点性能影响因素分析技术。该模块以面向方面的建模技术为基础，采用模型编织技术算法，将对应的方面模型织入到不同的应用中。本发明对常规编织和建模方法做出相应简化，只需考虑调用链的编织，而不需考虑组件的静态结构等情况，所需支持的连接点也只有方法调用一种。

编织是将不同的方面模型织入原始模型，从而引入横切关注点的性能影响因素。编织需要对三种不同类型的UML模型分别进行，而所需要的模型信息则从UML方面模型库中查询获得。

对于部署图和协作图的编织过程相对简单，在实行参数绑定后，只需要在原始模型添加方面模型新增的组件。这些新增组件将被部署到指定的主机，同时建立与其它组件协作的方式。值得注意的是部署图和协作图中只描述了新增组件，并没有描述调用者和横切关注点之间的关系，而是沿用原始输入模型中的描述。默认情况下新增的组件将与目标组件分配到同一台主机，并采用“客户机/服务器”请求模式与目标组件协作。经过编织，部署图中具有了四个组件，分别是Client、GenericAspect、Facade和Service组件。除了Client组件部署在ClientPC主机上之外，其它组件均部署在ServerStation上。协作图此时也有四个组件，它们的协作关系是，Client到GenericAspect，GenericAspect到Facade，Facade到Service均通过“客户机/服务器”交互。

活动图编织需要将方面模型插入到原始模型指定的位置，并重新建立调用关系。整个过程由参数绑定和模型关联组成，参数绑定过程如前所述，此处模型关联的步骤如下：

第一步：确定连接点。连接点位置由绑定规则给出，本实施例中连接点定义为Facade组件从prepare到process之间的活动。

第二步：确定连接点的输入与输出边。输入边和输出边给出了其它组件对目标组件嵌套调用的范围，连接点必须全部位于这一组边所构成的区域之内。

第三步：重新关联输入边与输出边。由于横切关注点先于目标组件之前被调用，所以原始模型中其它组件对目标组件的请求将会被横切关注点拦截。关联首先需要断开原有请求和响应事件的对应边，记录下与这两条边关联的节点的四个位置。然后，将通用方面模板中的输入输出边未与节点关联的两个端点关联到请求组件对应的两个位置，再将请求连接点的两条边与连接点关联的两个位置关联到目标组件的对应位置。

图5给出了一个编织后的示意图，图中的小圆点代表重新关联的四个位置。编织前，请求组件的请求活动直接调用目标组件的接受活动，而返回活动也是直接返回给响应活动。在编织后，通用方面模型被织入，原有的请求响应边断开，通用方面模型则关联在请求组件和目标组件之间。关联过程只与边与活动的连接位置相关，而与活动无关，也就是说目标组件的接受活动和返回活动可以是一个活动，也可以是更加复杂的结构。

对于本实施例，当分析到Facade组件时，发现声明文件中定义了该组件的横切关注点信息，于是通过对中间件性能影响因素库的查找，找到了如前所述的方面模型。再对方面模型实施绑定规则和模型绑定操作，即可得到一个织入横切关注点信息的软件模型。如果存在多个横切关注点，织入过程会一直循环下去，直到所有横切关注点均织入到原始模型中。之后，嵌套调度器将调度转换器将包括所有横切关注点和目标组件构成的整体转化为性能模型，再交由给性能模型加载器继续处理。此时，中从初始任务到当前任务的性能模型已经转化成功，保存在嵌套调度器中，其中目标组件和它所拥有的横切关注点作为一个方面子模型看待。

经过编织，本实施例的原始模型中由Client到Facade的请求则改由GenericAspect方面中转。原来Client到Facade的请求边则和GenericAspect的输入边结合，而由Facade返回Client的返回边则与GenericAspect的输出边结合。通用方面模型中的连接点则替换为Facade组件在接受Client组件调用后执行的操作。织入横切关注点的过程可以看为横切关注点在原先的请求关系之上，添加了一些额外的操作，使请求并不直接到达目标组件，而是通过横切关注点中转。

(b)性能模型加载器用于分析中间件自身对组件性能的影响，用到基于性能模型的中间件性能影响因素分析技术。一个请求在到达组件服务器后，服务器会做出一系列繁琐而重复的处理，直到完成所有操作，才会将请求转发到相应的组件。这一系列的操作会为组件带来明显的性能影响，同时又考虑到系统设计人员不会关注于这些影响因素的细节，所以我们采用分层排队网模型的性能模型进行中间件自身影响因素的建模。

加载中间件性能模型的步骤如下：

第一步：分析组件类型。根据运行环境以及组件类型从中间件性能模型库中查找相应的中间件性能模型。

第二步：组合由UML模型转换而来的方面子模型和中间件性能模型。中间件性能模型预留了组件性能模型的空间，方面子模型则是当前组件和其横切关注点的集合。断开性能子模型中原有关联方面子模型占位空间的请求，关联到转化后的实际方面子模型。

第三步：重新建立调用者与该组件间的联系。断开原有请求方面子模型调用的请求，关联到组合后的性能模板接口上。

图6给出了一个加载示后的示意图，图中的小圆点代表重新关联的两个位置。加载前请求者任务(task)将会直接请求方面子模型。加载后包含了中间件性能模型则，请求经过中间件任务后才会到达方面子模型。此示意图里中间件只包含了一个任务，方面子模型也包含了一个横切关注点，实际情况将比这复杂。

在我们的实施例中Facade组件是一个有状态会话Bean组件，中间件加载模块会使用如前所述的中间件性能模型加载中间件性能影响因素。该模型包含了中间件处理有状态会话Bean组件的关键操作，并为目标组件预留了一个方面子模型。加载后Client组件的请求首先经过该模型描述的一系列操作，如线程池，共享区域等。然后才由中间件转发到方面子模型，经过GenericAspect横切关注点后才最终到达Facade组件。

(c)第三方组件引入器负责分析当前组件使用其它组件的情况，并在该组件分析结束之后，引入被该组件引用的其它组件。通过与嵌套调度模块的交互，对服务和组件的分析便会一直递归嵌套下去，直到组件不再引用其它组件为止。该模块用到了申明式第三方组件引入技术。

被调用的组件可以是设计人员自己提供的，也可以是由服务器提供的第三方组件。对于设计人员自己设计的组件，所有必要的信息都可以直接获取，直接进行嵌套分析，不需要额外的引入操作细化实现细节；而对于应用的其它服务则需要额外的信息辅助分析，这些信息存放在第三方组件模型库中。

第三方组件引入过程分为两大步骤：一是确定组件引用方式，查找相应第三方组件模型；二是替换原始模型中被引用组件。

确定组件引用方式需要结合声明信息确定是否对中间件性能影响因素库进行查找。

首先要确定第三方组件的调用关系，可从UML图中获取；接着在声明信息中查找第三方组件信息，如果发现有调用发生且调用的是第三方组件，则从库中查找相应的第三方组件模型，否则该组件为用户自定义组件，不需要对其进行替换操作。

此处替换操作目的是用第三方组件模型替换原始模型中对该组件的调用，使原始模型中抽象调用关系替换为拥有详细性能影响因素的第三方模型，从而构造出完整的调用图，并引入相关影响因素。

对于部署图和协作图的替换方法与编织过程类似，这里不再赘述。本实施例中，处理完部署图和协作图后，原先部署图和协作图中的组件会增加到五个，两幅图中均增加了一个DataAccess组件，该组件部署在ServerStation主机上，与Server组件采用“客户机/服务器”方式交互。

对于绍活动图的替换有如下的步骤：

第一步：确定替换位置。被替换的节点在原始模型中仅是一个活动，抽象描述该调用过程，第三方组件模型将被替换到此处。

第二步：断开原有关联。断开原始模型中调用与被调用组件间的关联关系，即断开原有输入边和输出边关联的活动。

第三步：关联第三方组件。将第三方组件的输入与输出边对应的活动关联到原始模中，建立起新的调用关系。

图7给出了一个引入第三方组件后的示意图，图中的小圆点代表重新关联的两个位置；引入前目标组件只有一个活动，引入后目标组件的执行细节则描述出来。目标组件的执行过程定义在第三方组件模型当中，它可以调用其它一些原始模型中并未出现的组件。此时引入的第三方组件将作为新的当前分析节点，被该组件调用的其它组件则作为第三方组件处理。

对于本实施例替换过程如下：在分析完Facade组件时，引入模块开始分析被其调用的其它组件，由于此时会发现原始模型中的Service组件是一个第三方组件，所以需要接着查找该组件模型，将其替换到原始模型中，并重新建立调用关系。此时，一个完整的调用关系图就已构造出来。默认情况下第三方组件将被部署到与调用者相同的主机上，采用“客户机/服务器”的方式协作。嵌套分析器则调度分析嵌套顺序，对引入的第三方组件进行嵌套分析。

替换之后原始模型中Facade组件对Service组件的调用则从一个简单的活动，转换为由具有详细调用细节的活动组合。原始模型的doBusiness活动替换为第三方组件模型中定义的调用过程，并且引入了原始模型中不存在的DataAccess组件。此时，第三方组件的输入输出边与原始模型中对doBusiness活动的请求和响应边对应。

经过如上所述步骤，分析结束时，一个完整的性能就已构造完毕。对于本实施例，完整性能模型包含了从请求最初发起到最终结束的所有执行细节。在此模型中，客户端Client组件对服务器端Facade组件的请求首先需要经过中间件的相关处理，然后转发到相应的横切关注点，最后才会被转发到目标组件。该组件继而又调用了Service组件和DataAccess组件。在本实施例中Service组件和DataAccess组件均为简单组件，因而不像Facade组件加入了其它性能影响因素。

总的来说，性能分析与编排模块可看作性能影响因素的加载模块，其各个子模块在嵌套调度器的控制下，有序的对原始模型进行横切关注点分析，中间件影响因素分析和第三方组件分析，并最终生成一个完整的包含各种性能影响因素的性能模型。

四、分析计算模块

分析计算模块主要负责求解转化得来的完整性能模型，并得出最终需要的性能预测数据。该模块主要由系统资源消耗加载器和模型分析计算器组成。

1.资源消耗加载器负责根据不同的运行平台加载相应的系统资源消耗数据，这里主要考虑的是处理器运算时间、共享资源个数(比如说线程池大小和调度策略)等。考虑到目标系统可能运行在不同的硬件环境，库中存放了多种典型硬件环境下测试出的资源消耗量。模型中对资源的需求均以参数的形式给出，实际求解前先由设计人员选择运行平台，再由该加载器从平台相关资源库中查询数据赋予实际值。

实际预测的参数信息一部分从用户的声明文件中获取，比如服务器线程池的配置等；一部分从平台相关资源库中读取，比如某组件的处理器消耗时间。参数以“键/值”对的形式存放，模型中以首字母“$”作为标示。以下给出一段参数值片断。

2.模型分析计算器是一个求解分层排队网工具的计算工具，可以通过分析工具LQNS和模拟工具LQNSim进行求解(M.Woodside and G.Franks，“Tutorial Introduction to LayeredModeling of Software Perfromance”，http://www.sce.carleton.ca/rads/lqns/lqn-documentation)。该工具的输入是一个符合分层排队网模型的性能模型，输出则是性能预测的结果。结果包含了系统总的响应时间、吞吐率、处理器利用率和单个组件的使用率、总执行时间等数据。本实施例所收集的测试结果片断如下：

以上结果表示本实施例收集的数据，自左向右依次分别为并发用户数、系统吞吐率(c/ms)、响应时间(ms)、服务器处理器利用率(％)和横切关注点占用处理器的利用率(％)。可收集的数据不限于以上几种，求解工具允许用户自行定义。依据这些数据，设计人员可以清晰地了解不同负载下系统的性能状况，再参照最终系统的需求说明，便可判断当前设计是否满足需求。特别是在有若干备选方案的情况下，通过比较预测结果，可以从中选择相对最优的方案。

总的来说，分析计算模块可以看作一个计算输出模块。通过加载硬件相关的资源消耗需求数据并调用相关求解器求解，即可得出最终性能预测结果。

以上是完成本发明组件系统性能预测方法的四个主体模块，它们分工合作，有机的贯穿了预测的整个过程。各种相对固定，具有稳定结构的性能影响因素以可嵌套模型的形式独立存储在中间件性能影响因素库中。以这些模型为基础，一个抽象的不包含任何中间件平台信息的软件系统体系结构，便转化为包含详细性能影响因素的完整性能模型。结合已有的数学工具，即可求解出性能预测结果。

总而言之，本发明以简化预测过程为目标，以可嵌套模型为核心，以模型驱动为指导，以模型转换为具体实施策略，逐步将各种性能影响因素编排到原始输入模型，并最终计算出预测结果，辅助设计人员尽早发现设计缺陷，筛选备选方案，降低性能调优代价，缩短系统调优周期。