基于Petri网的面向动态演化的软件体系结构建模

基于Petri网的面向动态演化的软件体系结构建模
谢仲文;李彤;代飞;秦江龙;张璇;莫启;朱锐
【摘要】10.3969/j.issn.1000-386x.2012.10.011% 为了应对软件动态演化面临的挑战，应提高所建立的软件体系结构模型的动态演化性。

以扩展的Petri网为形式化工具，对面向动态演化的软件体系结构进行建模。

首先，将Petri网扩展成为构件网结构，并设计有效支持软件动态演化的构件模型和连接件模型；其次，建立软件体系结构的静态视图和动态视图，为软件动态演化的分析和实施奠定基础；最后，通过案例研究表明：该方法是有效的，并可显著提高所建立的软件体系结构模型的动态演化性。

【期刊名称】《计算机应用与软件》
【年(卷),期】2012(000)010
【总页数】5页(P36-39,127)
【关键词】软件动态演化;软件体系结构;Petri网;构件;连接件
【作者】谢仲文;李彤;代飞;秦江龙;张璇;莫启;朱锐
【作者单位】云南大学软件学院云南昆明650091; 云南省软件工程重点实验室云南昆明650091;云南大学软件学院云南昆明650091; 云南省软件工程重点实验室云南昆明650091;云南大学软件学院云南昆明650091; 云南省软件工程重点实验室云南昆明650091;云南大学软件学院云南昆明650091; 云南省软件工程重点实验室云南昆明650091;云南大学软件学院云南昆明650091; 云南省软件工程重点实验室云南昆明650091;云南大学软件学院云南昆明650091;云南大学软件学院云南昆明650091
【正文语种】中文
【中图分类】TP311.5
0 引言
构造性和演化性是软件的两个基本特性［1］。

随着软件工程学科的飞速发展，软件演化的重要性和普适性越来越强［2］。

软件演化包括静态演化和动态演化:对于静态演化，已有相对完整的理论和可行的技术;与它相比，动态演化的相关理论、
方法和技术还处于起步阶段［3］。

因此，动态演化已逐渐成为软件工程领域的研究热点［4］。

动态演化的目标在于支持系统在运行时刻以尽可能小的代价进行软件的动态配置和更新，即系统中不受动态演化实施影响的部分仍可以继续提供服务，而受影响的部分则须暂停服务而无法正常工作［3，5］。

目前，动态演化仍面临
多方面的挑战［3，5－9］，为了应对这些挑战，本课题组拟提出一种面向动态演化的建模和分析方法，该方法在需求分析、软件体系结构SA(software architecture)设计、可演化性分析、动态演化实施分析等多个阶段管理和支持动
态演化:以解决软件动态演化面临的若干挑战为导向，以需求模型为驱动，以SA
为视图，以支持动态演化的平台为支撑，以形式化方法为工具。

在整个研究框架内，本文的前期成果是已完成的面向软件动态演化的需求建模［7］。

因此，本文将在文献［7］的基础上，讨论面向动态演化的SA建模。

区别于传统的SA建模，本
文在SA建模时重点关注如何使得SA能有效支持动态演化，并提高所建立的SA
模型的动态演化性。

1 建模要求和建模思路
1.1 建模要求
针对动态演化，本文的SA建模特别关注以下要求:(1)SA作为动态演化分析、实施
的视图，不仅应能直观表达软件系统的结构，而且应具有精确的语义。

(2)动态演
化作为执行期的演化，需要对系统的执行状态进行描述。

因此，SA不仅应能表达系统的静态结构，而且应可反映系统的动态行为和状态的动态变化。

(3)作为整个
研究框架一个组成部分，SA建模应与上游的需求建模［7］之间建立良好的追踪
机制，即文献［7］中需求建模对动态演化的支持机制应在SA建模中得到继承和
保持。

1.2 建模思路
SA是软件系统的模型。

考虑到元模型是用来定义模型的工具，是建模的主要依据。

因此，本文设计了一种面向动态演化的SA元模型 DEAM(Dynamic-Evolution-Oriented Architecture Meta-model)。

DEAM作为SA元模型，是用来定义SA
的工具，依据上文的建模要求，DEAM的设计思路如下:(1)选取Petri网作为SA
建模的主形式化工具。

考虑到Petri网既具有直观的图形表示，又具有严格的数学基础，因此，基于Petri网建立的SA既能直观表达系统的结构，又具有精确的语义。

(2)DEAM包括静态和动态两个视图。

静态视图表达SA的静态结构，动态视
图以静态视图为基础，反映系统的行为导致的SA状态变化。

其中，静态视图以Petri网的网结构表示，动态视图以网系统表示，构件之间的交互就相应地以Petri 之间的交互和熔合展示出来，软件系统的动态行为以Petri网中变迁点火引起的网系统的动态运行来展示。

(3)为了建立与文献［7］中的需求建模之间良好的追踪机制，需在DEAM中对需求元模型中的一些特殊机制加以映射和表达。

因此，通过
变迁的分类来映射稳定和易变需求，通过库所的分类来映射主动和被动需求，通过区分端口和接口来映射计算和交互的相对隔离等机制，从而在SA建模中继承和保持需求建模对动态演化的支持机制。

2 构件和连接件建模
IEEE Std1471-2000标准把构件和构件之间的关系作为SA的核心［10］。

连接
件一般被用于描述构件之间的交互行为。

因此，构件和连接件建模是SA建模的重要组成部分。

为了使Petri网满足建模要求，首先，将Petri网扩展为构件网结构。

2.1 构件网结构
为了保持与文献［7］中需求建模的相关部件和相应机制的追踪性，本文提出的构件网结构在传统的Petri网基础上，做出以下三点限制和区分:(1)考虑与文献［7］中需求建模对稳定需求和易变需求的区分机制相对应:在构件网结构中，通过对变
迁的分类来对应稳定需求和易变需求，把变迁分为稳定变迁和易变变迁，易变变迁往往是一个较复杂子网结构的抽象，并且子网的结构经常需要动态演化。

(2)考虑
与文献［7］中需求建模对主动需求和被动需求的区分机制相对应:在构件网结构中，通过对库所的分类来对应主动需求和被动需求，主动特征对应的库所拥有一定的行为(将在动态视图中进一步阐述);而被动特征对应的库所，其状态完全由其局部环境(即前后集)决定。

(3)考虑与文献［7］中需求建模对计算行为和交互行为相分离机
制对应:考虑到计算行为包括顺序组合、选择组合、迭代组合等，而交互行为由一
组交互动作确定。

因此，为了实现两者的分离，在构件网结构中也相应地区分接口和端口，用接口之间的连接来实现计算行为的组合，用端口之间的协议来实现交互。

为了保证构件网结构的组合之后依然具有良好的结构，规定每个网结构有一个入接口和一个出接口，而端口数量则由需求建模中的交互协议确定。

定义1(构件网结构) 满足以下条件的六元组N=(P，T;F;E，A，C)称作一个构件网
结构:(1)P∪T≠φ且P∩T
=φ;(2)F⊆(P×T)∪(T×P);(3)dom(F)∪ran(F)=P∪T;(4)E⊆T;A⊆P;C⊆T;(5)N存在一个输入源(简称“源”)i∈P∪T，使得˙i=φ(i的前集为空);同时，N存在一个输出槽(简称“槽”)o∈P∪T，使得o*=φ(i的后集为空); (6)任意一个节点x∈P∪T，都
属于从i到o的一个路径上;其中:P是N的库所集，T是N的变迁集;F是N的有
向弧集，称为N的流关系;E是易变变迁集，A是主动库所集，C是交互变迁
集;dom(F)={x∈P∪T|∃y∈P∪T，(x，y)∈F};ran(F)= {x∈P∪T|y∈P∪T，(y，x)∈F}。

2.2 构件建模
要完整和精确描述构件很困难，所以目前关于构件的定义都比较抽象。

通常，一个构件应该包括两个部分:接口和实现。

本文用构件网结构描述构件的实现。

为了体
现计算与交互分离的思想，把接口和端口区别对待:接口用于构件之间的组合，端
口用于构件之间的交互;接口包括一个输入接口和一个输出接口，端口则由交互协
议规定;接口可以是库所也可以是变迁，端口则只能是变迁。

构件模型如图1所示。

图1 构件模型
定义2 (构件) 构件是SA中承担计算功能的单元，用五元组Com=(N，I，O，C，S)表示，其中:(1)N=(P，T;F;E，A，C)是一个构件网结构，描述了构件的实现;(2)I 是N的输入源i，表示构件的输入接口;(3)O是N的输出槽o，表示构件的输出接口;(4)C是N的交互变迁集，表示构件的端口集; (5)接口和端口统称为构件的接触点;(6)S是构件的依赖规约，用一个进程项表示(来源于文献［7］中的需求建模)，是从构件外部对构件的观察描述:表达构件必须实现的功能，否则构件将无法满足
与环境之间的交互要求。

构件也可直接以九元组Com=(P，T;F;E，A，I，O，C，S)的形式表示。

在不考虑因依赖规约而导致的一致性问题时，也可简化为八元组(P，T;F;E，A，I，O，C)或四元组(N，I，O，C)的形式。

可见，本文所提出的构件模型拥有一个输入接口和
一个输出接口，用于构件之间的组合;拥有n(n≥0)个端口，用于构件之间的交互。

此外，构件模型继承了构件网结构之中对易变变迁和稳定变迁的区分、主动库所和被动库所的区分。

正是这些特色的引入，使得该构件模型能更有效地支持动态演化。

需要说明的是，构件的接口可以是库所也可以是变迁，在构件之间通过接口进行组合的时候，若对构件的接口有类型要求，可以通过引入虚结点，在不改变构件的计
算功能的前提下，实现构件的接口类型的变换。

定义3 (虚结点) 虚结点是指没有实际意义的结点，它只能作为构件网结构中输入源的前提或输出槽的后提被添加进网结构，从而成为构件的输入或输出接口。

引入虚结点是为了建模方便，以便于构件之间的组合。

虚结点本身不代表任何实质的计算，虚结点的类型包括虚库所和虚变迁。

引入虚结点之后的网结构必须满足定义1的要求。

2.3 连接件建模
连接件是实现构件之间联系和交互的特殊部件。

在SA中，构件并非孤立地存在着的，而需要通过连接件建立并维持关系:静态地看，通过连接件的连接，把多个构件连接成为一个整体;动态地看，连接件为构件之间的信息传递、交互和协作提供了途径，并维持了构件之间的行为关联关系。

为了体现计算与交互分离的思想，本文把接口和端口区别对待，因此，连接件也相应地分为接口连接件和端口连接件，其中:接口连接件用于构件之间接口的连接，端口连接件用于端口之间的连接。

需注意的是，接口和端口不直接相连，因为接口用于构件之间的组装，而端口体现构件之间的交互协议。

Petri网中的网结合技术有四种基本类型:库所熔合、正向弧添加、逆向弧添加、变迁熔合，分别对应以下四类连接件。

定义4 (库所熔合连接件CP) 设两个构件，其构件网结构为Nk=(Pk，Tk;Fk;Ek，Ak，Ck)，Nk中各存在一个熔合库所pk∈(ik∪ok)，其中k=1，2，将p1和p2熔合成为一个库所p，则称Net=((P1∪P2－{p1，p2})∪{p}，T1∪T2;(F1－
Fp1)∪(F2－Fp2)∪Fp;E1∪E2，A1∪A2，C1∪C2)为N1和N2基于库所熔合连接件CP的(p1，p2)连接，记为Net=(N1，p1)CP(N2，p2)，其中:Fp1和Fp2分别是与p1和p2直接相连的弧，Fp是用p分别代替p1和p2产生的弧。

需注意的是:通过连接件连接之后得到的网Net满足Petri网的定义，但不一定满
足构件网结构的定义。

库所熔合连接件的实质是:连接件的两端分别是两个不同构件的库所接口，通过连
接件的作用，使得它们就像是一个库所的两个分身一样，共享库所的状态。

因此，连接件两端的库所状态是动态一致的:若其中一端的库所中产生一个托肯，另一端
的库所中也相应增加一个托肯;若其中一端的库所中消耗一个托肯，另一端的库所
中也相应减少一个托肯;若库所中只有一个托肯，当对应的两个构件中该托肯都可
以被其后集变迁点火消耗时，则将导致选择和竞争。

定义5 (正向弧添加连接件CPT) 设两个构件，其构件网结构为Nk=(Pk，Tk;Fk;Ek，Ak，Ck)，其中k=1，2，对于N1的一个接口库所p1∈(i1∪o1)，N2的一个接
口变迁t2∈(i2∪o2)，添加一条从p1到t2的弧，则称Net=(P1∪P2，
T1∪T2;F1∪F2∪F*;E1∪E2，A1∪A2，C1∪C2)为N1和N2基于正向弧添加连接件CPT的(p1，t2)连接，记为Net=(N1，p1)CPT(N2，t2)，其中:F*为连接时
添加的正向弧，即由接口库所p1指向接口变迁t2的弧。

正向弧添加连接件的作用是:用连接件的始端构件控制连接件的末端构件，即连接
件的末端变迁的点火条件由末端构件内部的前提库所集和始端库所共同决定。

定义6 (逆向弧添加连接件CTP) 设两个构件，其构件网结构为Nk=(Pk，Tk;Fk;Ek，Ak，Ck)，其中k=1，2，对于N1的一个接口变迁t1∈(i1∪o1)，N2的一个接
口库所p2∈(i2∪o2)，添加一条从t1到p2的弧，则称Net=(P1∪P2，
T1∪T2;F1∪F2∪F#;E1∪E2，A1∪A2，C1∪C2)为N1和N2基于逆向弧添加连接件CTP的(t1，p2)连接，记为Net=(N1，t1)CTP(N2，p2)，其中:F#为连接时添加的逆向弧，即由接口变迁t1指向接口库所p2的弧。

逆向弧添加连接件的作用是:连接件的始端变迁的点火将导致其末端库所中增加一
个托肯。

因此，该连接件起到从始端构件向末端构件传递信号或消息的作用。

定义7 (变迁融合连接件CT) 设两个构件，其构件网结构为Nk=(Pk，Tk;Fk;Ek，
Ak，Ck)，Nk中各存在一个熔合变迁tk∈Ck，其中k=1，2，将t1和t2熔合成
为一个变迁t，则称Net= (P1∪P2，(T1∪T2－{t1，t2})∪{t};(F1－Ft1)∪(F2－
Ft2)∪Ft;E1∪E2，A1∪A2，C1∪C2)为N1和N2基于变迁熔合连接件CT的(t1，t2)连接，记为Net=(N1，t1)CT(N2，t2)，其中:Ft1和Ft2分别是与t1和t2直
接相连的弧，Ft是用t分别代替t1和t2产生的弧。

变迁融合连接件的作用是:只有连接件两端的变迁都可以点火时，这两个变迁才可
以同时发生;只要有其中一个变迁的点火条件没有得到满足，则连接件两端的变迁
都不能执行。

由定义易知，库所熔合、正向弧添加、逆向弧添加连接件是接口连接件，而变迁熔合连接件是端口连接件。

定义8 (连接件) 连接件是SA中承担连接和交互功能的单元，用三元组
Con=(Type，Cf，Cb)表示，其中:(1)Type表示连接件的类型，其取值范围为{CT，CP，CTP，CPT};(2)Cf表示连接件的源，Cb表示连接件的槽，Cf和Cb统称为连接件的角色。

四种基本类型的连接件是由网结合的四种基本技术导出，由于这四种网结合的技术对于两两连接是完备的，因此，其它复杂的网结合方式可以由这四种基本连接方式组合而成。

3 静态视图和动态视图建模
3.1 静态视图建模
静态视图描述了SA的静态结构，其基本部件除了构件和连接件之外，还包括构件与连接件之间的连接关系;进一步，对于复杂系统而言，构件之间通过连接件的作
用还可以形成粒度更大的构件或子系统，从而形成SA的多层次结构。

定义9 (连接关系) 连接关系确定了SA中构件和连接件之间的关联关系，用二元组l=(Com.touch，Con.role)表示，其中:(1)Com.touch表示构件Com的一个接触
点;(2)Con.role表示连接件Con的一个角色;(3)连接关系表明构件的接触点Com.touch和连接件的角色Con.role相连接。

在建立连接关系时，必须注意连接件的Type的匹配，即:CT类型的角色都必须和端口变迁相连接，CP则必须都和接口库所相连接，CTP的源必须连接接口变迁、槽必须连接接口库所，CPT的源必须连接接口库所、槽必须连接接口变迁。

定义10(静态视图) 接下来以递归形式定义静态视图SAS。

(1)一个构件是一个静态视图。

(2)四元组(COM，CON，L，C)是一个静态视图，满足条件:①COM是一个构件的集合，其中至少包含一个构件;②CON是一个连接件的集合，其中任意一个连接件的两个角色都参与连接关系;③L是一个连接关系的集合;④C是静态视图的端口集合;⑤以COM中构件为顶点，CON中连接件为边，依据L建立连接关系，得到的是一个连通图。

(3)四元组(SA，CON，L，C)是一个静态视图，满足条件:①SA是一个静态视图的集合，其中至少包含一个静态视图;②CON、L、C同上;③以SA中元素为顶点，CON中连接件为边，依据L建立连接关系，得到的是一个连通图。

连接件不但可以用于连接构件，也可用于连接静态视图，从而形成更加复杂的静态视图。

静态视图的递归定义使得SA的构造具有层次性。

3.2 动态视图建模
动态视图建立在静态视图的基础上，考虑SA的动态运行和行为导致的状态变化。

动态视图以静态视图为基础，进一步加入标识(即托肯)之后，根据Petri网的点火规则运行。

动态视图采用的网系统是原型Petri网，即所有的弧的权值都为1，所有的库所容量为无穷大。

定义11(构件的状态) 对于构件Com=(P，T;F;E，A，I，O，C)，映射M:P→{0，1，2，…}称为构件的一个状态，记为状态s。

与经典Petri网类似，在图形表达构件状态时，对于p∈P，若M(p)=k，则在库
所p中以k个小黑点表示p中有k个托肯。

在动态视图中，需要进一步描述构件的动态行为，以动态构件系统的形式表现。

定义12 (动态构件系统) 动态构件系统是九元组ComD =(P，T;F;E，A，I，O，C，M)，其中:(1)Com=(P，T;F; E，A，I，O，C)是一个静态的构件网结构，称为动态构件系统的基网;(2)M是动态构件系统的一个状态。

定义13 (主动库所运行规则) 在动态构件系统ComD中，对于A中的任意一个元
素pa，pa是一个主动库所，pa的每次运行将使得其库所中的托肯个数加1，即M’(pa)=M(pa)+1。

主动库所对应文献［7］中需求建模的主动需求，是引起行为相关性的“源头元素”。

它们主动地创建“任务”或者接受系统外部提交的“任务”。

每创建一个任务，其对应的库所中就增加一个托肯。

主动库所是系统与系统外部交互的接口。

除了主动库所能主动添加托肯之外，动态构件系统的其它状态变化都依据原型Petri
网的运行规则。

变迁的接连点火、主动库所的运行导致了构件状态的不断变化，展示了构件系统的运行。

SA的动态视图中往往包含许多相互连接和协作的构件，每个构件有其自己的状态，它们共同构成了SA的状态。

定义14 (SA的状态) 对于一个静态视图SAS的构件集合COM，COM中每一个构件的状态记为M1，M2，M3，…，Mn，则M=M1∪M2∪M3∪…∪Mn称为
SA的一个状态，M1，M2，M3，…，Mn分别称为SA的一个构件子状态。

SA的任意的构件子状态的改变都将导致SA状态的变化。

定义15 (动态视图) 动态视图是相对于静态视图而言的，是二元组SAD=(SAS，M)，满足以下条件:(1)SAS是对应的静态视图;(2)M是SA的一个状态;(3)SA的状
态在构件的运行规则和连接件的动态作用下，由于主动库所的执行、变迁的点火而
不断改变其自身的状态。

动态视图是软件系统状态的动态运行和变化的抽象表示。

4 案例研究
为了说明本文提出的方法之可行性，以文献［7］的案例为基础进行案例研究。

该案例是一个简化的网上银行系统。

要求系统实现用户信息管理、余额查询、历史记录查询、网上转账等功能;对于转账功能，要求执行转账之前，系统自动向客户手
机发送验证码，验证成功后才执行转账;此外，目前银行正与该市电力营销系统商
讨通过网上银行代收电费事宜，但尚未确认和签约。

文献［7］已建立了该案例的需求模型，接下来，将进一步对其进行面向动态演化的SA建模。

作为示例，有必要从网上银行系统中选择典型构件，建模其内部的构件网结构。

接下来，对短信验证转账构件进行建模。

从文献［7］的需求建模知:短信验证转账构件对应的进程
项:(t0·(t1+(t2·(t3·(t4+t5)))))‖［C］((e0+e1)*)，其中C={＜0.01，t2，e0＞，＜0.02，t3，e1＞}。

因此，该构件可细分为两个子构件:转账构件(对应进程项为
t0·(t1+(t2·(t3· (t4+t5))))))和验证构件(对应进程项为(e0+e1)*)，并通过两个子构
件的并行组合和交互构成父构件(也可看成一个子系统，在此视为构件)。

首先，将子构件当成原子构件，即构件Com表示为Com= Com1‖［C］Com2，其中Com1对应进程项为t0·(t1+(t2·(t3· (t4+t5)))))，Com2对应进程项为
(e0+e1)*。

建模短信验证转账构件的框架，如图2所示，其中:构件Com1和Com2以变迁熔合连接件连接起来，并通过引入的两个虚变迁，组成父构件;两个
虚变迁分别被提升为构件的输入和输出接口。

图2 短信验证转账构件的框架
接下来，详细建模转账子构件的内部结构:Com1对应进程项为
t0·(t1+(t2·(t3·(t4+t5)))))，建模得到其内部结构，如图3所示，由于t0是主动特
征，因此建模得到的库所p1是主动库所;p1和p5分别被提升为输入和输出接口，t2和t3被提升为端口。

图3 转账子构件
进一步，给出转账子构件的形式化定义，Com1=(P1，T1;F1; E1，A1，I1，O1，C1，S1)，其中:P1={p1，p2，p3，p4，p5};T1={t0，t1，t2，t3，t4，
t5};F1={(p1，t0)，(t0，p2)，(p2，t1)，(p2，t2)，(t1，p5)，(t2，p3)，(p3，
t3)，(t3，p4)，(p4，t4)，(p4，t5)，(t4，p5)，(t5，
p5)};E1=φ;A1={p1};I1={p1};O1={p5};C1={t2，t3};S1=t0·(t1+(t2·(t3·(t4+t5)))))。

限于篇幅，其它构件或子构件不再详细建模。

接下来，为了建立系统的全貌，对SA及其子系统的视图进行建模。

根据文献［7］的需求建模，知系统的行为特征模型对应的进程项
为:(i·((((a+b)+x)+7.00)*))·o。

将系统划分为三个构件(或子系统):登录构件(对应进程项i)、登出构件(对应进程项o)和业务处理构件(对应进程项(((a+b)+x)+ 7.00)*)，其中业务处理构件较为复杂，可以看成业务处理子系统，并进一步进行分解。

系统顶层的SA静态视图，如图4所示。

图4 系统顶层SA的静态视图
业务处理子系统的静态视图如图5所示。

图5 业务处理子系统
图5建模过程如下:考虑业务处理子系统对应的进程项为(((a+b)+x)+7.00)*，由于选择算子满足结合律和交换律，因此通过公理系统将其变为等价的形式如
下:(a+b+x+7.00)*。

易见，业务处理子系统由四个构件选择组合之后，再进行迭
代组合。

四个构件分别为:账户信息管理构件(对应进程项a)、余额和历史记录查询构件(对应进程项b)，代缴电费构件(对应进程项x)、短信验证转账构件(对应标识
符7.00)，其中:7.00=(t0·(t1+(t2·(t3·(t4+t5)))))‖［C］((e0+ e1)*)。

将各个构件
当做原子构件，得到业务处理子系统的静态视图如图5所示。

在图5中，四个构件选择组合之后，再迭代组合，并通过引入虚变迁使之符合上
一层的连接要求，这样，业务处理子系统被抽象成为业务处理构件，并与顶层SA 中的连接件之间保持类型的匹配。

另外，图中构件7.00的部分子构件(转账子构件)的详细模型已在前文完成。

需要说明的是，限于篇幅，案例中大部分的构件的详细内部结构无法在文中描述，因此，许多连接件的类型无法确定。

随着各个构件和子构件的详细模型的不断被建立，各种连接件的类型也将被确定。

最终，随着建模的不断细化，将最终得到完整、精确、详细和层次化的SA视图。

通过案例研究可见:(1)本文建立的SA模型与文献［7］的需求建模保持很高的可追踪性，考虑到动态演化本质上是需求变化驱动的，为从源头上支持动态演化提供了支持。

(2)本文提出的构件模型区分了主动库所和被动库所，并通过区分接口和端
口机制对计算和交互进行了相对隔离，通过变迁分类封装了易变特征和稳定特征;
这些机制一方面提高了SA模型的动态演化性，另一方面为动态演化的分析和实施奠定基础。

5 结语
针对软件动态演化面临的挑战，以需求建模为基础，本文提出面向动态演化的SA 元模型DEAM，设计了构件、连接件、静态视图和动态视图等基本部件，使得SA 建模能够有效支持软件动态演化:一方面，提高了所建立的SA模型的动态演化性;
另一方面，建模结果作为动态演化的分析和实施的视图，为可演化性分析、一致性分析等工作奠定了基础。

参考文献
［1］杨芙清.软件工程技术发展思索［J］.软件学报，2005，16(1):1-7.
［2］Li Tong.An Approach to Modelling Software Evolution Processes
［M］.Springer-Verlag，Berlin，2008.
［3］李长云.基于体系结构的软件动态演化研究［D］.杭州:浙江大学计算机科学
与技术学院，2005.
［4］徐洪珍，曾国荪，陈波.软件体系结构动态演化的条件超图文法及分析［J］.
软件学报，2011，22(6):1210-1223.
［5］Mens T，Buckley J，Zenger M，et al.Towards a Taxonomy of Software Evolution［C］//Proceeding of International Workshop on Unanticipated Software Evolution，Warsaw，Poland，2003:1-18.
［6］Moazami-Goudarzi K.Consistency preserving dynamic reconfiguration of distributed systems［D］.Ph.D.thesis，Imperial College，London.1999.
［7］谢仲文，李彤，代飞，等.面向软件动态演化的需求建模及其模型规范化［J］.计算机科学与探索，2012，6(6):557-576.
［8］谢仲文.一种需求驱动、以体系结构为视图的面向软件动态演化的模型与方法［D］.昆明:云南大学软件学院，2012.
［9］王映辉，刘瑜，王立福.基于不动点转移的SA动态演化模型［J］.计算机学报，2004，27(11):1451-1456.
［10］IEEE.IEEE recommended practice for architectural description of software-intensive systems［R］.IEEE，IEEE Std1471-2000，2000.。