RGPS支持的面向方面网络式软件演化方法＊

田 刚，何克清，孙承爱，崔焕庆，彭珍连，3

（1.山东科技大学信息学院，山东 青岛266590；2.武汉大学软件工程国家重点实验室，湖北 武汉430072；3.湖南科技大学计算机学院，湖南 湘潭411201）

1 引言

软件演化是指在软件系统的生命周期内软件维护和软件更新的行为和过程。在现代软件系统的生命周期内，演化是一项贯穿始终的活动，包括需求演化、设计演化、运行时演化等。如何使开发的软件能够在运行时根据用户的需求变化实时演化，一直是研究的焦点。

网络式软件需求演化建模关注的问题是如何在重用领域共性需求模型的基础上，针对个性化需求的变化，利用演化建模方法在原始需求的基础上建立满足新需求的模型。其中，需要用到的关键技术包括：支持情景感知的角色－目标－流程－服务RGPS（Role-Goal-Process-Service）需求元模型框架［1］；基于本体-RGPS O-RGPS（Ontology-RGPS）的领域模型库；支持人网交互模式，捕获用户个性化需求的面向服务的需求获取语言SORL（Services-Oriented Requirement Language）［2］。

2 软件演化研究

面向方面和基于反射结构的软件演化方法是当前实现软件演化的两大主流方法。

2.1 面向方面的演化方法

面向方面的软件演化方法的基本思想是将方面织入到需要演化的软件系统中，快捷地支持软件演化。Cazzola W［3］指出了在代码演化中如何应用方面，使用UML模型定义了连接点模型来增进方面的可重用性。尽管该方法对于程序员来说清楚易懂，但是如何将高层的设计信息转换到低层的代码和如何保证转换的一致性仍然是未解决的难题。Anis Charfi［4］提出了一种称为 AO4BPEL的语言，通过扩展BPEL并在Web服务执行过程中动态地织入一些新的方面，实现 Web服务组合的演化。这种方法同本文的方法类似，但是其切入点的定义并不是基于RGPS需求元模型，因此无法和本文方法无缝对接。

2.2 基于反射体系结构的软件演化方法

反射系统基层描述系统被期望进行的计算；元层描述系统怎样执行计算。运行时的系统作为基层，元层管理演化的规则、演化的操作以及演化事件的截取等。Cazzola W在文献［5，6］提出了一种反射式中间件 RAMSES（Reflective and Adaptive Middleware for Software Evolution of Systems）。它能够根据系统的设计信息在运行时改变基层系统的结构和行为，从而实现实时的演化。Edmond D［7］提出了一种基于反演的柔性工作流和反射对象知识库 ROK（Reflective Object Knowledge）来支持对工作流结构各类特征的处理。这个框架支持工作流的运行时反射，但不能覆盖整个软件生命周期。

2.3 RGPS支持的面向方面网络式软件演化方法及其问题

面向方面的软件演化方法覆盖整个软件生命周期［8，9］，所以何克清等［10］采用了面向方面的网络式软件运行时反射的框架，如图1所示。该框架把运行时的 Web服务组合具体化为以OWL-SA（Ontology Web Language-Service Aspect）呈现的描述，然后通过解析目标变更需求规格来调用相应的动作对呈现的描述进行修改，并将这种修改反馈给基层的Web服务组合实例，使之动态演化，从而满足用户的个性化需求。

Figure 1 Runtime reflection framework of network software图1 网络式软件运行时反射的演化框架

文献［10］提出的网络式软件演化框架中，需求规格是以流程资产的形式呈现，而流程资产满足RGPS流程元模型的约束，RGPS元模型定义如图2所示。

Figure 2 RGPS process meta-model图2 RGPS中的流程元模型

该框架的演化过程是：首先，在RGPS元模型指导下形成演化的初始需求模型。其次，当需求发生变化的时候，在以领域模型为元模型、目标模型为基本模型的反射机理支撑下，动态形成目标需求模型，并以OWL-SA表示，如图3a所示，其中以切入点（Pointcut）描述插入方向，通知（Advice）描述需求演化内容。为便于比较，图3给出了改进后的元模型，其改进内容在3.1节中详细介绍。

Figure 3 OWL-SA meta-model图3 OWL-SA元模型

该框架实现了运行时网络式软件的在线演化，但是仍然存在如下问题：

（1）在 OWL-SA元模型中，evolutionOrder属性值有四个：before，after，around，parallelTo，分别表示通知与切入点所在的过程之间的关系为在前、在后、替换或并行。该定义并未严格遵守RGPS中流程元模型控制结构的定义，导致织入的新流程与原流程的关联关系定义不清楚，容易引起某些流程无法演化。例如，图4中在节点p5前插入方面，因为没有定义控制结构，因此p2、p3和p1、p6的关系无法确定，导致该方面无法织入。

Figure 4 Problems in evolution图4 演化中出现的问题

类似地，图4中与p5并行及图4下半部分图中p1之后插入通知都是无法用OWL-SA元模型准确描述的。

（2）确定演化的位置方法可操作性差。正如（1）所述，因为切入点和原流程采用不同的控制结构定义方法，导致切入点的织入不够平滑，原框架采用XPath定位OWL-SA中的演化位置，技术上是可行的，但是普通用户使用起来十分困难。

3 方法的改进

3.1 改进的流程形式化定义

由图3可知，每个通知对应一个流程。又根据图2所示的流程元模型可知，每个流程又分成原子流程和组合流程。所以，当通知需要执行多个操作时可以用组合流程来替代，因此每个通知可以完全用流程来代替。流程元模型利用控制结构来表示流程之间的逻辑顺序，直接将该控制逻辑引入方面中作为切入点在流程中位置定义的描述是合适的。因此，本文对OWL-SA元模型进行修改，将演化顺序合并到流程中，将通知和流程一对一合并形成图3所示的修改后元模型，并给出RGPS流程元模型指导下的流程模型，其形式化定义如图5所示。

Figure 5 Formal definition of process图5 流程形式化定义

图5 中各个元素的含义如下：

（1）Title：流程场景名称。

（2）ProcessTitle：流程中包含的流程的名称，如｛（p1，“订飞机票”）｝。

（3）AllElements：包含的所有元素，包括通知（Advice）、子流程（SubProcess）、分支开始（SplitOn）、分支汇聚（SplitJoin）、条件分支（Choice）。这些元素遵从RGPS元模型指导，并且与RGPS元模型中的元素建立对应关系，如表1所示。

Table 1 Process model and the corresponding RGPS meta-model表1 新定义的流程模型与RGPS元模型的对应

（4）Sequence：两个 Elements之间的顺序关系。

（5）InitialElements和 Terminators：开始和结束的元素集合，可以是子流程（SubProcess）、分支开始（SplitOn）、分支汇聚（SplitJoin）、条件分支（Choice）和方面（Advice）。

（6）Superior：元素所属的父流程或者父方面。

（7）Pre和Post：方面执行的前置和后置条件。

（8）Localvariable：流程中使用到的参数。

（9）Inputs和Outputs：某个流程的输入和输出参数。

（10）ChoiceRules：选择分支的条件。

（11）APCall：原子流程可以调用的 Web服务。

（12）Expectations、Actor、Goal：对应元模型中流程对期望、角色和目标的调用。

Figure 6 Process invariant图6 流程不变式

元素之间的约束放在不变式中，如图6所示，其含义为：

（1）流程中包含的元素有子流程（SubProcess）、分支开始（SplitOn）、分支汇聚（SplitJoin）、条件分支（Choice）和通知（Advice），它们是各不相同的。

（2）终止点必须满足一定的条件。

（3）每个元素都有自己的名称。

（4）顺序反映了流程图中的顺序结构，连接了两个元素。

（5）每个原子流程都属于一个流程。

（6）每个输入或输出必须属于一个流程。

（7）每个分支条件必须属于一个分支。

流程模型与RGPS流程元模型的对应关系。

从表1中可以看到，每一种流程元素都可以在元模型中找到对应的元素，这表示新建立的模型是遵循RGPS元模型指导的，完全可以用元模型来表示。在RGPS元模型中还有一种控制结构是Loop结构，虽然在流程模型中没有一种元素和它对应，但是它代表的控制完全可以用Choice和SubProcess的组合来替代。

3.2 流程演化

在网络式软件演化框架［10］中，首先在RGPS元模型指导下形成演化的初始需求模型。只有当需求发生变化的时候，才会把变化的需求以OWLSA形式表示并将其织入到以流程资产形式表示的需求模型中，因此流程的演化只涉及到模式级别。这种演化主要包括三类情况：流程元素的插入、删除和替换，而替换又可以看成是先删除再插入，所以本文主要讨论两种情况：流程元素的插入和删除，如图7所示。

Figure 7 Process elements insertion and deletion图7 流程元素插入与删除

流程元素的插入主要包含插入顺序结构、插入分支开始、插入分支汇合、插入子流程、插入选择分支。插入顺序结构的时候，如果是从一个选择节点之后插入，那么还需要插入选择分支的条件。流程元素的删除主要包含删除顺序结构、删除分支开始、删除分支汇合、删除子流程、删除选择分支。删除过程容易造成某些节点失效，因此需要进行清理。

3.2.1 插入元素

（1）如图8所示，插入子流程（InsertSubProcess）的操作将一个新的子流程节点插入到流程结构中。子流程名称和它所属的父流程作为操作的输入，该操作会产生一个输出pro作为新子流程的流程编号。输入的父流程（Parent）必须属于Superior，产生的新id号pro不属于已有的AllElements。该操作将pro加入到SubProcess，把子流程名称processTitle加入到Process。其中，“’”操作表示某个属性被执行操作以后的新值，例如，AllElements’表示在执行了InsertSubProcess操作之后AllElements的新值。

Figure 8 Process elements insertion图8 插入元素

（2）插入顺序结构（InsertSequence）的操作将一个新的顺序结构插入到流程结构中。顺序结构作为操作的输入。该操作将新的顺序结构seq加入到Sequence。因为Sequence的定义为（From，To），当执行插入一个顺序结构的时候，将会把两个节点连接起来。

（3）插入规则（InsertRule）操作将一个新的规则插入到流程结构中。选择节点和流程节点以及两个节点连线上的条件构成操作的输入。该操作将新的规则加入到ChoiceRules。对于插入分支开始（SplitOn）、分支汇合（SplitJoin）和选择节点（Choice）三个操作，其操作方式同插入子流程类似，文中不再赘述。

3.2.2删除元素

（1）如图 9 所示，删除子流程 （DropSub-Porcess）操作将一个子流程从流程结构中删除。Sequence’的值将发生变化：所有到待删除节点的顺序结构和所有从待删除节点发出的顺序结构将连接起来，同时待删除节点的定义域和值域要从顺序结构中删除，即连接到待删除节点或从待删除节点发连线都将被删除。然后从子流程中将待删除节点删除，从父流程中将与待删除节点相关的节点删除。

Figure 9 Process elements deletion图9 删除元素

（2）删除顺序（SropSequence）操作将一个顺序结构从流程结构中删除；从父流程中将与待删除节点相关的节点删除。因为删除顺序结构容易造成某些节点不再和其他节点关联，因此需要在删除结构执行之后进行清理工作，这也是图7中Clean节点要做的工作。

（3）删除选择（DropChoice）操作将一个选择结构从流程结构中删除；从父流程中将与待删除节点相关的节点删除。因为选择结构还和选择结构上的条件相关，所以在ChoiceRule中将与待删除节点相关的所有条件规则删除。

（4）删除分支开始（DropSplitOn）操作将一个分支开始结构从流程结构中删除；从父流程中将与待删除节点相关的节点删除。同时Sequence’中做同删除子流程一样的操作，即将打断的顺序结构依次连接起来。删除分支汇合（DropSplitJoin）的操作同删除分支开始。

4 演化实例

为了检验提出的网络式软件演化方法的可行性和有效性，本文基于Flex4开发了一个演示系统。考虑一个旅行规划的场景：Rick先生希望定制一个行程规划预订到北京的机票，帮他在北京预订酒店并提供当地名胜的浏览介绍。根据文献［10］，Rick将在领域模型中获得满足自己需求的需求模板，简化形式如图10中上面流程所示。当他到中国以后发现中国是一个铁路交通非常发达的国家，乘坐火车可能比飞机性价比更高，因此上述旅行规划中的初始需求需要进行演化，增加部分需求，从而变成图10下面的流程。

4.1 演化方面定义

图11中代表需求演化的方面为Aspect1，它主要包含：一个choice节点（P8974）、一个订火车票的advice节点（P8826）和一个splitJoin节点（P4899）。它们各自的定义符合RGPS流程元模型的标准，以3.1节中的定义形式给出。

4.2 切入点位置定义

Figure 10 Original requirements and evolutionary requirements of travel planning图10 旅行规划的原始需求和演化需求

Figure 11 Evolutionary process source code图11 演化后的流程代码

切入点的位置定义和织入原流程的方式通过Sequence能够清楚地表示：choice节点（P8974）、advice节点（P8826）和splitJoin节点（P4899）属于同一方面（superior＝“Aspect1”）。其中，choice节点在Start节点（P1397）之后，advice节点在choice节点（P8974）之后，splitJoin节点在订机票（P6295）和订火车票（P8826）之后。advice同订机票节点（P6295）都连接自choice节点（P8974）。从上面的代码中可以看出，演化后的需求方面切入点的位置不需要显式地定义，它们的定义隐式地包含在了流程控制结构中，这样的方式保证了演化需求可以无缝织入原过程。

5 结束语

本文针对现有网络式软件演化框架中存在的问题，提出了新的面向方面网络式软件演化方法。新的演化方法使用RGPS流程元模型定义流程，用流程元模型中的控制结构定义切入点位置，从而精确定义了切入点位置并提供图形化操作界面，方便了切入点插入操作。新方法除了保持了网络式软件运行时演化的特点之外，还能够使切入点的定义符合RGPS元模型的要求，但是新方法仍然没有解决演化中的不一致问题，这也将是下一步的主要工作。

［1］ Wang Jian，He Ke-qing，Li Bing，et al.Meta-models of domain modeling framework for networked software［C］∥Proc of the 6th International Conference on Grid and Cooperative Computing，IEEE Computer Society，2007：878-885.

［2］ Liu Wei.Research on services-oriented software requirements elicitation and analysis［D］.Wuhan：Wuhan University，2008.（in Chinese）

［3］ Cazzola W，Pini S，Ancona M.AOP for software Evolution：A design oriented approach［C］∥Proc of the 2005ACM Symposium on Applied Computing，2005：1346-1350.

［4］ Charfi A，Mezini M.AO4BPEL：An aspect-oriented extension to BPEL［J］.World Wide Web，2007，10（3）：309-344.

［5］ Cazzola W，Ghoneim A，Saake G.RAMSES：A reflective middleware for software evolution［C］∥Proc of the 35th Annual Meeting of the ACL and the 8th Conference of the EA CL，2004：56-63.

［6］ Cazzo W，Pini S，Ghoneim A，et al.Co-evolving application code and design models by exploiting metadata［C］∥Proc of SAC’07，2007：1275-1279.

［7］ Edmond D，Der Hofstede A H M.A reflective infrastructure for workflow adaptability［J］.Data＆Knowlage Engineering，2004，34（3）：271-304.

［8］ Kellens A，Mens K，Brichau J，et al.Managing the evolution of aspect-oriented software with model-based point-cuts［C］∥Proc of the 20th European Conference on Object-Oriented Programming（ECOOP’06），2006：501-525.

［9］ Demeyer R，Assche M V，Vanhoof W.Declarative workflows to efficiently manage flexible and advanced business processes［C］∥Proc of PPDP’10，2010：209-218.

［10］ He Ke-qing，Peng Rong，Liu Wei，et al.Network Software［M］.Beijing：Science Press，2008.（in Chinese）

附中文参考文献：

［2］ 刘伟.面向服务的软件需求获取与分析研究［D］.武汉：武汉大学，2008.

［10］ 何克清，彭蓉，刘玮，等.网络式软件［M］.北京：科学出版社，2008.