一种基于面向对象编程的软件自适应改造方法与流程

本发明属于软件工程的软件设计方法领域，具体涉及一种基于面向对象编程的软件自适应改造技术。

背景技术：

软件自适应技术是为了降低软件维护压力、增强软件自身容错和应对变化的能力而提出的一种软件设计技术，运用软件自适应技术构造的软件拥有对环境和需求变化的自适应能力，这样的软件叫做自适应软件。自适应软件在运行过程中遵循“监测”-“分析”-“计划”-“执行”的自适应环路，具体表现为：自适应软件在运行过程中实时收集并分析上下文信息，参照知识库中相应的策略，执行自适应行为。上下文表示一种在对象激活时被创建的属性的有序序列，上下文信息包含上下文事件、上下文状态，上下文约束。知识库是多组策略的集合，为自适应软件进行决策提供依据，策略是一种基于eca规则，用以表明自适应软件调整自身行为时机以及方式的语言，eca规则是一种由事件触发、判断条件满足、执行动作的动作触发规则。自适应行为是指自适应软件通过动态重配置实现对自身参数、结构或行为的自发调整的过程，动态重配置即自适应软件在运行过程中更改自身代码结构或者属性的过程。

运用软件自适应技术，针对现存软件进行自适应化改造时，主要的技术难题在于实现非自适应软件的动态重配置。传统的自适应技术在实现软件动态重配置时，主要有两种方式：第一种方式倾向于直接修改现存软件的源代码，使现存软件匹配中间件系统，这种方式需要开发人员对非自适应软件源代码有透彻的理解，完全把握代码的功能作用，并且需要花费较长时间。第二种方式倾向于修改中间件系统，让中间件系统匹配非自适应软件，这种思路依赖于开源的中间件系统，因此限制了应用范围，灵活性差。这两种方式都依赖于中间件系统，中间件系统种类繁多，配置复杂，使用时对整个系统的影响较大。中间件是位于平台和应用之间的通用服务，这些服务具有标准的程序接口和协议，高效、可靠、灵活的传输功能，优秀的事件代理机制等优点，采用中间件系统对现存软件的运行过程加以管理可以实现软件系统的自适应改造。目前行业中普遍使用的中间件系统有jboss、jms等，jboss中间件系统拥有优秀的响应速度以及支持aop扩展，运用jboss中间件系统进行自适应改造的软件具有高度模块化的和松耦合，但由于复杂的配置方式，需要开发人员投入大量时间和精力，使得jboss中间件在应对轻量级软件自适应改造时显得臃肿麻烦。jms中间件系统通过提供标准的产生、发送、接收消息的接口来访问并管理消息的收发，运用jms中间件系统进行自适应改造的软件具有松耦合，异步性特点，但jms使用范围小，目前jms未考虑出java以外的开发环境。aop即面向切面编程，是通过预编译方式和运行期动态代理实现程序功能的统一维护的一种规范，运用aop技术可以对业务逻辑的各个部分进行隔离，从而使得业务逻辑各部分之间的耦合度降低，提高程序的可重用性，同时提高了开发的效率。

技术实现要素：

本发明的目的在于克服现有技术的不足，提供一种基于面向对象编程的软件自适应改造技术。本发明通过运用面向对象编程中策略模式，代理模式等设计模式以及面向切面编程aop中提取业务逻辑的思想来对软件进行自适应改造。

本发明一种基于面向对象编程的软件自适应改造方法，具体包括以下步骤：

步骤一：构建知识库,提供多组策略的存储结构；

多组策略的存储结构包括对应上下文事件的类，对应上下文状态的类，对应上下文约束的类，对应约束元素或逻辑关系的类，对应策略条件的类，对应自适应行为的类，对应策略的类，对应策略组的类；

步骤二：梳理原软件系统的业务逻辑，根据需要组织相应的策略；

梳理出待修改软件原有业务逻辑，明确自适应软件需求，将这些需求抽象表示为事件ce，状态cs，约束cr，调整ac，按照eca规则形式描述的策略；

步骤三：给出策略细节，并进行规范化，以xml文件形式进行存储；

按照事件ce对应上下文事件，状态cs对应上下文状态，约束cr对应上下文约束,调整ac对应自适应行为的方式按照知识库存储所提供的属性，对策略进行细化和规范化，并将这些策略存储在xml文件中；

步骤四：根据需要对原软件系统的业务逻辑进行分离提取，封装到目标对象中；

运用面向对象编程中的代理模式将原软件系统的业务逻辑进行再封装，得到目标对象；

步骤五：统一目标对象的接口，形成自适应构件；

步骤六：设计连接子，初始化连接子属性指向，形成自适应模块；自适应模块包括一个连接子以及可供其连接的多个自适应构件；

所述的连接子具有两个指向自适应构件的属性，其中一个用于协调属性所指向的自适应构件运行的方法，一个用于更改属性的指向的方法；

步骤七：重复步骤四到步骤六得到多个自适应模块；

步骤八：将得到的自适应模块和知识库用于扩展原软件，完成软件自适应改造。

作为优选，步骤八中的自适应模块为将多个自适应模块整合得到的。

本发明较传统技术来说有以下显著优点

(1)对软件系统原有的代码改动较少，结构保存完好。

(2)使用过程中开发人员只需集中精力于修改主要业务逻辑部分，减少开发人员工作量。

(3)不依赖第三方中间件系统，使用更加灵活。

本发明采用的具体实现方法是：

(1)构建知识库，提供多组策略的存储结构。

(2)梳理原软件系统的业务逻辑，根据需要组织相应的策略。

(3)给出策略细节，并进行规范化，以xml文件形式进行存储。

(4)根据需要对原软件系统的业务逻辑进行分离提取，封装到目标对象中。

(5)将目标对象进行标准化，包括统一接口，加入事务逻辑等操作，形成自适应构件。

(6)设计连接子，初始化连接子属性指向，形成自适应模块。

(7)重复步骤(4)到步骤(6)完成多个自适应模块的设计，并根据需要整合相应的自适应模块。

(8)将得到的自适应模块和知识库用扩展原软件，完成软件自适应改造。

有益效果：由本发明改造得到的自适应软件，可以响应自身属性和复杂环境变化，并且由于改造基于面向对象的设计理念，为软件维护带来了极大的便利，同时本发明对原软件系统代码结构破坏小，改造后的软件系统代码逻辑清晰，可扩展性好。

附图说明

图1是本发明知识库uml类图；

图2是本发明策略的上下文约束的xml存储描述语言；

图3是本发明自适应模块示例图；

图4是本发明多个连接子联立的示例图；

图5是本发明改造后的软件系统示例图。

具体实施方式

下面结合实例附图进行进一步详细说明本发明的具体实现方法：

(1)构建知识库,提供多组策略的存储结构。

为原软件构建用以存储策略的知识库，此过程中需要构建多个类：用以存储上下文事件的contextevent类、用以存储上下文状态的contextstate类、用以存储上下文约束contextrestriction类、用以存储约束元素或逻辑关系的restriction类、用于存储条件的condition类、用以存储自适应行为的action类、用以存储策略的strategy类、用以存储策略组并提供执行“监测”步骤、“分析”步骤、“计划”步骤、“执行”步骤方法的knowledgebase类等。

由contextevent类存储的上下文事件是一个四元组contextevent:＝{supe,attre,rele,vale}，其中supe代表上下文提供者，attre代表由supe提供的上下文，rele代表关系运算符，vale代表临界值.

由contextstate类存储的上下文状态是一个四元组contextstate：＝{sups,state,rels,vals}，其中sups代表上下文状态的提供者，state代表sups所提供上下文的状态，rels代表关系运算符，vals代表临界值。

由contextrestriction类存储的上下文约束是由多个restriction类实例以后缀表达式的顺序存储。以此来表达由多个约束组成的上下文约束。

由restriction类所存储的实例既可以是约束元素，也可以是逻辑关系，可以表示为一个七元组restriction:＝{type,rev,relr,supr,attrr,rela,valr}，其中type根据不同的取值来区分当前实例代表的是约束元素还是逻辑关系。rev和relr共同用来表示“与”“或”“非”三种运算关系，rev取值决定“非”关系，“与”关系和“或”关系由relr的取值决定。supr代表该restriction的上下文的提供者，attrr代表所提供的上下文，rela表示关系运算符，valr代表临界值。当restriction类实例表示约束元素时，依赖的属性有type,rev,supr,attrr,rela,valr。当restriction类实例表示逻辑关系时，依赖的属性有type,relr。多个restriction实例以后缀形式存储时，运用栈结构进行分析，可以得到完整的上下文约束关系式，这样的方式避免了约束关系式中括号的影响，从而消除了策略存储xml文件的嵌套结构。

由condition类存储的条件con可以表示为一个三元组con:＝{contextevent,contextstate,contextrestriction}。其中contextevent对应上下文事件，contextsate对应上下文状态，contextrestriction对应上下文约束。

由action类存储的自适应行为是一个三元组act:＝{obj,op,active}，其中obj代表该自适应行为的执行者，op代表执行构件obj所要执行的操作，active代表当前自适应行为是否处于运行中。

由strategy类存储的策略是一个四元组strategy:＝{con,act,id,pr}，其中con表示条件，act表示自适应行为，id是策略的标识，应对同一上下文事件的策略id值相同，pr代表策略的执行优先级。

knowledgebase类提供一个将策略根据标记值id和优先级pr进行分组存储结构。这种存储方式让策略的查询更加快速，当某一上下文事件触发时，只要查询拥有相同标识id的一组策略，并按照优先级顺序对比策略就能完成相应策略的检索。

本发明构造的知识库，为自适应软件的“监测”步骤提供了上下文事件，存储于contextevent类中，指定了所监视的上下文attre和上下文的提供者supe，并且表明当上下文与临界值vale存在关系rele时，视为上下文事件触发。

本发明构造的知识库结构，为自适应软件的“分析”步骤提供了上下文状态，存储于contextstate类中，指定了在上下文事件触发之后，分析由提供者sups提供的上下文状态state，并且表明当上下文状态与临界值vals存在关系rels时，认为需要进行“计划”步骤和“执行”步骤。

本发明构造的知识库结构，为自适应软件的“计划”步骤提供了上下文约束。在经过“分析”步骤后确定需要进行自适应调整时，解析contextrestriction类实例中存储的以后缀表达式顺序组合的多个restriction类实例对象，得到上下文约束关系式。比较约束关系式中各个约束元素是否满足，即由提供者supr提供的上下文attrr是否和临界值valr之间存在rela关系，并且是否满足对应的逻辑关系relr。如果均满足，则认为可以进行当前策略指定的自适应行为。

本发明构造的知识库结构，为自适应软件的“执行”步骤提供了自适应行为，存储于action类中,当前策略上下文约束满足时，判断当前自适应行为是否处于活动状态，即active是否为真，如果为真代表当前自适应行为处于激活状态则不需要再次激活此自适应行为。如果为假，则通过自适应行为代理构件obj，实施操作op，并置该自适应行为的active为真。

图1给出了本发明构造的一个知识库存储结构的uml示例图：在图1中一共有八个类：contextevent类、contextstate类、contextrestriction类、restriction类、condition类、action类、strategy类和knowledgebase类。其中contextevent类代表上下文事件，属性supplier对应上下文事件四元组中的supe，属性attribute对应上下文事件四元组中的attre，属性relationtype对应上下文事件四元组中的rele，属性value对应上下文四元组中的vale。contextstate类代表上下文状态，属性supplier对应上下文状态四元组中的sups，属性state对应上下文状态四元组中的state，属性relationtype对应上下文状态四元组中的rels，属性value对应上下文状态四元组中的vals。contextrestriction类代表了上下文约束，属性primres是一个数组，存储元素为restriction类实例。restriction类代表了上下文约束中的约束元素或逻辑关系，属性type对应上下文约束七元组中的type，属性reverse对应上下文约束七元组中的rev，属性relationforrestriction对应上下文约束七元组中的relr，属性supplier对应上下文约束七元组中的supr，属性attribute对应上下文约束七元组中的attrr，属性relation对应上下文约束七元组中的rela，属性value对应上下文约束七元组中的valr。condition类指代eca规则中的条件，由contextevent、contextstate、contextrestriction三者组合而来，对应了策略四元组的con,属性event是一个一维数组，存储元素为contextevent类实例。属性state是一个一维数组，存储元素为contextstate类实例，属性restriction是一个contextrestriction的实例对象，代表上下文约束。action类指代自适应行为，对应了策略四元组中的act，属性objection对应action三元组的obj，属性operation对应action三元组的op，属性active对应action三元组的active。strategy类代表策略，属性condition对应策略四元组中的con，属性action对应策略四元组中的act，属性id对应策略四元组中的id，属性priority对应策略四元组中的pr。knowledgebase类用来存储所有strategy类实例，并提供处理方法，strategy类实例根据属性id和属性priority存储于strategyarray中。方法monitor用来监测上下文事件，根据返回值不同，代表不同的监视结果。方法analysis用来对比上下文状态，根据返回值不同，代表不同的分析结果。方法plannerandexecuter用来对比上下文约束，并根据返回值不同，调动不同的自适应行为。run方法用来联立monitor、analysis、plannerandexecuter三个方法，对策略进行检索完成整个知识库的作用。

(2)梳理原软件系统的业务逻辑，根据需要组织相应的策略。

首先需要明确待修改软件需要进行自适应调整的功能，以及原软件所能提供的调整算法，也就是一些业务逻辑。在此步骤中，需要梳理出这些业务逻辑，这是实现自适应改造的前提。在明确了原软件自适应调整需求以及原软件业务逻辑后，根据需要组织相应策略，策略的构建需要考虑四个因素：事件ce，状态cs，约束cr，调整ac。事件ce表示软件在运行过程中可能出现的影响软件正常运行的事件，表现为软件系统自身或者当前环境的某个属性超出临界值，这个属性应该是软件能够感知的。状态cs表示软件运行时所处的不同状态，软件系统自身的某个属性可以表示该状态。调整ac表示软件系统在应对事件ce发生时能够做到的调整行为，此行为能够让软件系统重新正常运行，这种行为往往有多种。约束cr表示在做出调整ac所需要关注的软件自身或者环境属性，在不同的约束cr下往往有最优的调整ac可以执行。通过对以上四个因素的综合考虑，可以总结出多组按照eca规则"ifconditionthenaction"形式描述的策略。

(3)给出策略细节，并进行规范化，以xml文件形式进行存储。

给出策略的细节，并进行规范化，按照事件ce对应上下文事件contextevent，状态cs对应上下文状态contextstate，调整ac对应自适应行为action,约束cr对应上下文约束contextrestriction的方式按照知识库存储所提供的八个类的属性，对策略进行细化和规范化。并将这些策略存储在xml文件中。xml指可扩展标记语言，易于存储和读取，目前行业中技术十分成熟，在此不做详细介绍。

本发明上下文约束表达式中的元素和逻辑关系以后缀表达式形式存储，这种形式避免了xml文件中的嵌套结构，让xml文件调理更加清晰。

图2为上下文约束表达式a&&(b||c)&&！d的xml描述语言：

上下文约束a&&(b||c)&&！d中一共有四个约束元素a、b、c、d和三种逻辑关系“与”关系，“或”关系和“非”关系。首先提取出约束元素中的“非”关系，将d中rev值记为true。然后将整个表达式化为后缀表达式形式，即abcoranddand：

图2中第1行到第5行代表了约束元素a,其中supplier＝"classa"对应七元组中的supr，表示该元素的提供者为classa；attribute＝"a"对应七元组中的attrr，表示classa提供的上下文为"a"；type＝"0"对应了七元组中的type，表示当前restriction表示一个约束元素；reverse＝"false"对应了七元组中的rev，表示当前约束元素不存在一个“非”关系；第2行到第4行用来表示该约束元素a的上下文与临界值对比，以此辨别约束是否满足，第2行的relationforattr＝"is"对应了七元组中的rela，代表了关系运算符为"is"，第3行的＜value＞true＜/value＞对应了七元组中的valr，表示临界值为true。整个约束元素a表示了当由classa所提供的上下文"a"值为true时满足约束。第6行到第10行代表了约束元素b，同上。第11行到第15行表示约束元素c，同上。第16行到第17行表示约束元素b和约束元素c之间存在“或”关系，第16行中的type＝"1"对应了七元组中的type，表示当前restriction代表了一个约束元素之间的关系。relationforrestriction＝"or"对应了七元组中的relr，表示约束元素b和约束元素c之间存在“或”关系。与第16行到第17行相似，第18行到第19行，代表了约束元素a和b||c之间存在着“与”关系。第20行到第24行表示约束元素d，和约束元素a、b、c存在不同点，在第20行中reverse＝“true”对应了七元组中的rev，表示当前约束元素d存在“非”关系，即在d值不为真时满足该约束。与第18行到第19行相似，第25行到第26行，代表了约束元素a&&(b||c)与约束元素d之间存在“与”关系

(4)根据需要对原软件系统的业务逻辑进行分离提取，封装到目标对象中。

在此步骤中，将原软件系统中可以用来完成自适应行为的业务逻辑从源代码中提出，并封装到目标对象中。此步骤中将待处理代码抽象成一个切面，代码的每个执行步骤抽象成关注点，这些关注点中的主要业务逻辑抽象成连接点，并将连接点以面向对象编程设计模式中的代理模式将业务逻辑提出封装形成目标对象。具体做法为：

第一步，确定连接点，原软件系统代码中的业务逻辑往往会被各种诸如写日志、读日志等事务逻辑代码层层包围，此步骤要确定业务逻辑即连接点所在。

第二步，关注点分离，整理代码，使业务逻辑和其他事务逻辑分离，并明确连接点周围的其他事务逻辑执行情况。

第三步，业务逻辑的再封装，使用面向对象编程设计模式中的代理模式，将业务逻辑封装到代理类中形成目标对象。

此步骤中得到的目标对象可以在软件运行时动态的代理原有算法的执行，实现原有业务逻辑。对得到的目标对象进行修改可以做到动态的修改原有业务逻辑并且不会对源代码造成破坏。

(5)将目标对象进行标准化，包括统一接口，加入事务逻辑等操作，形成自适应构件。

对目标对象进行标准化，包括统一接口，加入事务逻辑等操作形成自适应构件。自适应软件在应对同一上下文事件时往往要根据自身状态或属性的不同而触发不同的自适应行为，这些自适应行为对应了之前步骤提取出的不同目标对象，此步骤中运用面向对象编程设计模式中的策略模式为不同目标对象统一接口，根据需要加入原软件中连接点周围事务逻辑，或新建事务逻辑等完成目标对象的标准化。标准化后的目标对象已具备了完成相应调整行为的功能，此步骤得到的目标对象作为自适应构件。

(6)设计连接子，初始化连接子属性指向，形成自适应模块。

此步骤中，通过运用面向对象编程特点来设计连接子,连接子拥有两个属性和两个方法，两个属性指向连接子所连接的两个自适应构件，连接子的第一个方法给出了两个属性所指代的自适应构件的运行逻辑，连接子的第二个方法可以分析传入参数并更改自身属性指向。本发明中的自适应构件和自适应连接子拥有同样的接口，因此连接子两个属性所指向的既可以是自适应构件，也可以是连接子。

如图3为一个自适应模块示例图：

该自适应模块由一个接口block和五个类：gcs_failsafe_connecter类、preaction类、continue_mission类、loiter类、rtl类等。五个类都是接口block的实现类，都实现接口block的run方法和change方法，并且在各自的run方法中都封装有不同的方法。gcs_failsafe_connecter是自适应模块的连接子，拥有两个属性b1和b2，以及两个方法run方法和change方法，属性b1初始指向接口block的实现preaction类，属性b2初始指向接口block的实现类continue_mission类，run方法给出了两个属性所指向的自适应构件的运行逻辑，运行连接子gcs_failsafe_connecter类的run方法就能按照逻辑运行属性b1，b2指向的自适应构件的run方法，change方法根据传入参数不同，调整连接子gcs_failsafe_connecter类属性b1，b2的指向。preaction类作为该自适应模块的保留类，在多个自适应模块联立时将会被替换，或者根据源代码的逻辑被替换。continue_mission类，loiter类和rtl类为自适应构件，分别代理了原软件的相关业务逻辑并在自身的run方法中有着不同程度的扩展。在这个自适应模块中，当gcs_failsafe_connecter类b2属性指向的自适应构件发生改变就会引起系统自适应行为的改变。

(7)重复步骤(4)到步骤(6)完成多个自适应模块的设计，并根据需要整合相应的自适应模块。

在此步骤中，重复步骤(4)到步骤(6)完成多个自适应模块的设计，并根据需要可以对多个自适应模块进行整合。使得各个自适应模块的连接更加紧密。具体做法：新建一个连接子，由于每个连接子只能连接两个自适应构件或者连接子，整合n个自适应模块需要n+1个连接子。将每个自适应模块的连接子的一个属性指向自适应构件，另一个属性指向下一个连接子就可以整合不同的自适应模块。经过整合的自适应模块的连接子成一个二叉树状结构，自适应构件相当于这个二叉树的叶子节点，并且依照每个连接子方法中的运行逻辑运行自适应构件和下一个连接子的方法。因此经过整合的自适应模块可以通过只运行根节点的连接子方法就能按照顺序运行所有的自适应构件方法。如果不同的自适应构件操作之间有大量的事务逻辑需要处理，也可以不进行整合，让自适应模块单独运行，这保证了扩展时的灵活性。

如图4给出了多个连接子联立的结构示例图：

图4由一个接口block和五个类：preaction类、start_connecter类、batteryevent_adaptive类、nogcs_adaptive类、endaction类等，其中preaction类和endaction是保留类，在此自适应模块作为扩展编织进源代码中时根据非自适应软件的原有逻辑进行考虑完善。start_connecter类是在整合自适应模块时添加的连接子，本发明在整合n个自适应行为时需要n+1个连接子，start_connecter类就是扩展出来的连接子,属性b1指向preaction类，属性b2指向batteryevent_adaptive类。batteryevent_adaptive为第一个自适应模块的连接子属性b1指向为完成该自适应行为的自适应构件，图中未给出，属性b2指向下一个自适应模块的连接子nogcs_adaptive类。nogcs_adaptive类为第二个模块的自适应连接子，属性b1指向为完成该自适应行为的自适应构件，图中未给出，属性b2指向endaction类。整个系统通过运行start_connecter的run方法，可以依次运行preaction类、batteryevent_adaptive类、nogcs_adaptive类、endaction类的run方法。

(8)将得到的自适应模块和知识库用扩展原软件，完成软件自适应改造。

此步骤将此前构建的知识库和自适应模块作为扩展编织进原有软件的源代码中。需要注意的是，在本发明中，知识库的作用是调节连接子的属性所指向的自适应构件，以此达到更改系统的行为，因此知识库的运行应该在自适应模块的运行之前。在此前提下，调整已经自适应化的业务逻辑和不需要自适应化的业务逻辑之间的关系，确保非自适应软件经过自适应改造后各个业务逻辑运行正常。图5为经过本发明改造后的非自适应软件示例图：图5可以分为3个部分知识库部分，非自适应软件部分和自适应模块部分。图中uav类指代原软件。知识库部分同图1，包括contextevent类、contextstate类、contextrestriction类、restriction类、condition类、action类、strategy类、knowledgebase类。剩余部分为自适应模块结构，同图4。统一接口block以组合关系整合到软件uav中，参与软件uav的运行过程，同时软件uav依赖于知识库knowledgebase类。当改造后的软件uav在运行时会先调用knowledgebase类中的run方法，完成整个“监测”-“分析”-“计划”-“执行”的自适应环路得到经过自适应调整的系统结构，之后再运行自适应模块。