面向构件的动态构件演化

理论计算机科学电子札记189（2007）21-34www.elsevier.com/locate/entcs一种面向构件的动态构件演化是的，卡洛是卡纳，Javier Cuboa和Juan Manuel MurillobaDep t。计算系统，Ma′laga、Spain的统一信息。电子邮件：jcamara@lcc.uma.es，canal@lcc.uma.es，网址：cubo@lcc.uma.esb部 计算机科学，埃斯特雷马杜拉大学，西班牙。电子邮件地址：juanmamu@unex.es摘要本文简要描述了一个动态适应管理框架的设计，它利用了面向对象软件开发（AOSD），特别是面向对象编程（AOP）提供的概念。该框架使用反射和自适应技术来支持COTS通过解决与签名和协议互操作性相关的问题来实现组合和演进。这提供了一个基本的基础设施，为非侵入性的，半自动的方法，语法和行为的适应。关键词：动态适应，进化，框架，CBSD，AOP，重构1介绍软件开发领域最重要的趋势之一是构建包含预先存在的软件组件的系统，通常称为商用现货（COTS）[18]。这些都是独立的产品，它们具有更大的系统所需的特定功能。使用COTS的目的是通过利用现有的和经过良好测试的产品来降低总体开发成本，缩短开发时间。然而，由于这些组件的黑盒性质，开发团队无法控制它们的功能、性能和发展。大多数情况下，这些组件的设计并不能实现互操作，需要定制1这项工作得到了西班牙教育和科学部（MEC）资助的项目TIN 2004 -07943-C 04 -01、安达卢西亚地方政府资助的项目P06-TIC-02250和埃克塞特地方政府资助的项目PRI 2 PR 04 B 011的1571-0661 © 2007 Elsevier B. V.在CC BY-NC-ND许可下开放访问。doi：10.1016/j.entcs.2007.03.02622J. 卡马拉等人/理论计算机科学电子笔记189（2007）21当团队面对系统演化过程中的组件集成时，必须重复执行的适应。这些活动要求很高，消耗时间和资源，否则这些时间和资源可以用于增强或开发新功能。此外，某些类型的系统不能关闭（即，银行或机场交通控制系统）。发展这样的系统而不停止它们（例如，用新版本替换组件）是这是一个具有挑战性的操作，包括许多不同的问题。自动化上述适配任务的需求推动了软件适配的发展[4]，这是一个以高度动态的运行时过程为特征的领域，当设备和应用程序从一个网络移动到另一个网络时，修改或扩展其行为。 软件适配促进了软件适配器的使用[19]，软件适配器是用于解决软件实体之间的互操作性问题的特定计算实体（即，组件、服务等）。这些问题可以分为四个不同的层次：• 签名级别：此级别的接口描述指定实体提供或需要的方法或这些接口提供名称、参数类型和返回值，或异常名称。这种适应意味着解决语法上的问题，如方法名称，参数排序和数据转换和合成。• 协议级别：该级别的接口指定描述组件遵循的交互行为的协议由于交换消息的顺序和阻塞条件，在此协议级别也可能发生不匹配。在这一层面上可以解决的问题是，例如，行为的兼容性（即，组件在组合时是否死锁）。• 语义级别：这个级别描述了组件实际上做了什么（即，其功能特性）。即使两个组件提供完全匹配的签名接口并遵循兼容的协议，我们也必须确保组件的行为符合预期。• 服务级别：即使我们能够在签名、协议和语义级别上找到组件之间的完美匹配，仍然存在广泛的不匹配源，这些不匹配源与非功能性属性（如时间要求、安全性、可靠性、准确性、成本等）相关，使得组合不可能。虽然签名级别是适应的最新技术（例如，CORBA尽管如此，这种不匹配的解决方案意味着先前对组件接口的增强，并描述了它们的协议[3，2，12]。这项工作的重点是在一个框架的设计，软件自适应技术的基础上，以及如何可以应用这些技术，以支持动态软件演化，特别是在签名和协议级别。考虑到前面提到的COTS组件的不透明性，为开发该框架提供的技术必须是非侵入性的。从这个意义上说，奥里方面-J. 卡马拉等人/理论计算机科学电子笔记189（2007）2123面向方面编程（AOP）[15]是一个合适的候选者，它提供了扩展和修改组件行为的机制，而不直接改变它们（即，代码）。 还需要自动和动态程序， 以便在组件加入系统的上下文（或在系统运行时被替换）的时刻实现自适应。 使用这种的框架，可以减少集成件的支持，通过（半）自动组件自适应在非基于COTS的系统的发展。在本文中，第2节提供了面向方面编程的概述。第3节简要介绍了一个小例子，将用于说明我们的建议在整个后续章节。第4节描述了一个基于AOP的动态适配管理框架的设计，自动协议适配器推导，并使用AOP J [9]说明了关键的实现问题。第5节将我们的建议与软件适配和AOP领域的相关工作进行了最后，第6节提出了结论和未决问题。2面向方面编程概述面向对象编程（AOP）是基于这样一种思想，即通过分别指定系统的不同关注点（属性或感兴趣的领域）和它们之间关系的描述，然后依靠底层环境中的机制将它们编织或组合在一起成为一个连贯的程序，系统可以更好地编程。 看看系统的模块化结构，可以观察到，虽然一些关注点整齐地定位在特定的结构模块中，但其他关注点则跨越多个元素。AOP关注于简化这种横切关注点的实现的机制（例如，安全）。AOP提供方面作为机制，为横切关注点的表达提供显式结构，将其压缩为单个结构行为，否则这些行为将分散在系统中的其余代码中（并与之纠缠在一起AOP还提供了将方面和基本代码编织到一个一致的工作系统中的机制。这个编织过程可以在开发的不同阶段执行，从编译时到运行时（动态编织）[13]。动态方法意味着虚拟机或解释器必须知道方面并控制织入过程，尽管考虑到方面可以在运行时应用和删除，它代表了显着的优势。这允许在系统执行期间以透明的方式修改应用程序行为在传统的编程技术中，程序员必须显式地调用其他组件这种隐式调用是通过连接点实现的。这些是应用程序的动态控制流程中的区域（方法调用或执行，异常处理，字段设置等）。它可以被AOP程序通过使用切入点（允许24J. 卡马拉等人/理论计算机科学电子笔记189（2007）21连接点的量化）以匹配它们。一旦连接点被匹配，AOP程序就可以运行对应于新的或注入的行为（建议）的代码，通常是在匹配的连接点之前、之后、代替或周围（之前和之后）由于连接点是动态的，因此可以将运行时信息（如方法的调用方或被调用方）从连接点公开给匹配的切入点。特别是，组件通信可以被看作是一个横切问题，其行为可以使用AOP进行修改因此，组件可以被能够通过切入点捕获所有传入/传出消息的方面包装，并通过通知的应用方便地修改3运行实例为了说明我们的方法，我们描述了一个企业信息系统，其中业务规则，而不是隐含的（即，不作为规则编写，而是嵌入在应用逻辑中）是显式的，并且嵌入在集中式引擎上以供执行。因此，任何业务策略都可以在一个点进行更改，并通过企业网络进行访问。以这种方式使业务规则明确，便于使用COTS产品，降低公司这个用于业务规则执行的集中式规则引擎（RulesEngineComp组件）最初并不包含要执行的规则集。每当业务规则被更新并需要重新加载时，引擎就请求RuleSetProvider组件，该组件以适当的格式提供要执行的规则集。 必须首先查询此组件，规 则 提 供 程 序 （ getProvider ） ， 接 下 来 将 使 用 它 来 创 建 规 则 集 （ RuleRuleSet）。 规则集最终存储在RuleSetProvider组件（executeQuery）查询的数据库中，然后在最终请求时提供（getRuleSet）。然而，当前的RulesEngineComp组件在性能上受到限制，因此开发团队希望用更高效的第三方解决方案来替代它这个新的规则引擎组件（RulesEngine）旨在通过loadRules直接从数据库检索规则集。系统-TEM必须连续工作，因此不能为了执行组件替换而停止TEM。此外，从两个组件接口的描述中可以看出（如图2所示），RulesEngine和RuleSetProvider组件不是为协同工作而构建的，匹配签名和协议• 关于协议级别，如果特定接口上的消息在对应方的接口中没有等价物，则给出独立演进。仔细观察组件接口，可以发现setMode具有RuleSetProvider接口上没有对应关系。• 关于签名级别，如果特定组件期望特定的输入消息，而接收到的消息具有不同的名 称 （ 例 如 ： ， RulesEngine 发 送 loadRules ， 而 RuleSetProvider 需 要getProvider）。此外，可以承认，预期的功能-J. 卡马拉等人/理论计算机科学电子笔记189（2007）2125加载规则的有效性！对应于其对应接口上的多个消息，并且这些消息所需的参数需要类型转换、重命名和重新排序。在以下各节中，我们介绍了我们的框架，以解决上述不同的不匹配情况。4动态适应管理框架适配器是根据如何解决组件或服务之间的不匹配的抽象描述自动构建的（即，适应映射），基于组件接口的描述。实现适应的第一步是获得这种映射。无论如何，它的构造不在本文的讨论范围之内。在给出映射描述的情况下，本节重点讨论基于方面的适配管理框架的设计，该框架能够解决协议和签名级别组件之间的不匹配4.1系统架构需要来自被适配的组件的签名和协议信息以在它们的这是使用元数据合并技术（特别是注释）从组件中获得的[7]。然而，值得注意的是，可用量信息可能会因执行适配的特定平台而异，因此对元数据合并的需求可能会相应变化如图1所示，系统的架构包含三个基本功能模块，用于实现适应所包含的不同关注点(i) 接口管理器：收集有关组件接口的信息(ii) 适配器管理器：使用[1]中提出的算法导出适配器，用于组件之间的交互，利用上述映射。(iii) 协调管理器（Coordination Manager）：协调组件之间的交互，根据先前派生的适配器描述翻译消息。这些任务的实现，基于AOP的原则，利用连接点模型，它可以实现干净的消息转换，因为组件不需要内部修改，切入点定义提供了一种紧凑的方式来拦截相关事件（组件初始化和方法调用是特别感兴趣的）。虽然这个框架依赖于标准的连接点定义语言（通常意味着从基本代码中消除结构和语法依赖的后果[6，10]），但这并不影响不同管理器的操作方式，因为使用的切入点定义是微不足道的将这些关注点作为方面来实现，将协调与诸如适配器之类的关注点26J. 卡马拉等人/理论计算机科学电子笔记189（2007）21Fig. 1.框架架构图。生成或接口描述管理允许框架的清晰模块化。4.1.1界面管理器它在组件加入系统的上下文时检查组件的接口，并将它们的描述保存在接口存储库中，以便以后在生成映射时使用它们。为此，我们使用反射技术。在初始化C类的组件c时，管理器检查存储库中是否存在C的条目，如果不存在，则为它创建一个条目由于组件通常以客户端-服务器方式交换消息，因此需要对它们的操作和所需接口（即分别由组件接收和发送的消息集）是必需的。例如，在Java的特定情况下，唯一可用的信息是属于被操作接口Mo（通过反射）的消息的描述，因此组件必须补充其所需接口Mr的签名的描述。两个接口的完整描述必须包括每个方法的最低信息集，包括：- 消息（即，方法）名称。- 有序的参数名称和类型。- 返回值类型。- 提高。组件接口也通过在其描述中包含协议信息而得到扩展。组件的行为接口可以通过标记转换系统（LTS）[5]轻松指定。定义4.1[行为接口]组件的行为接口是一个元组（M，S，I，F，T），其中：M=Mo<$Mr是一个字母表（消息或事件的集合），S是一组状态，I∈S是初始状态，F<$S是最终状态，T<$S×M×S是转换函数。J. 卡马拉等人/理论计算机科学电子笔记189（2007）2127getProvider？规则集？executeQuery！getRuleSet？initSession？setMode！endSession？loadRules！endSession？消防规则？[RulesSetProvider][提供]：int getProvider（String Provider）;boolean findDuplicate（String name，int name）;String getDuplicate（String name）;[必填]：boolean executeQuery（String语句）引发SQLException;[RulesEngine][提供]：public voidfireRules（）;public voidfireRules（）;[必填]：String setMode（Stringmode）; String loadRules（String setID）引发IOException;图二、 与接口存储库中RulesEngine和RuleSetProvider组件的接口描述条目对应的组件签名和LTS。注意，发射和接收在LTS中表示为！ 然后呢？，分别。两个接口中与协议重叠部分对应的消息以斜体字键入。从图2中可以看出，接口存储库中的每个条目都包含对所需接口和所需接口的描述，以及指定组件所遵循协议的自动机。4.1.2适配器管理器它根据系统的条件生成新的适配器。一旦类S的组件加入上下文，它就可以向/从其他组件生成或接收一个或多个消息。每当生成或接收到这些消息中的一个时，管理器都会拦截它，并检查它是否是映射中类T的目标组件委托或接收的第一个消息如果是这种情况，则会使用[1]中描述的算法在源和目标组件类之间自动生成该适配器存储在存储库中，它将用于类（S，T）的任何组件对之间的交互管理。一旦生成，这些适配器允许提供消息和参数名称转换、数据转换和参数重新排序的语法适配。它们还提供了一种机制来执行协议适配，在需要延迟交付时存储消息，并在它们之间建立一对一和一对多的对应关系。映射使来自源组件的出站消息能够映射到系统范围内的其他组件的不同调用。此映射包含初始声明部分，其中可以定义和修改不同的值，例如常量或基于源消息的不同参数的合成值。然后，源消息被映射到对其他组件的调用序列中，其中参数的实际值可以直接从源消息的列表或参数中获取在图3中，我们可以观察到两个与我们的示例相对应的消息绑定：28J. 卡马拉等人/理论计算机科学电子笔记189（2007）21...<消息绑定><参数名称=“mode”type=“String”>XML_SERIALIZED/return><消息绑定><参数名称=“setID”type=“String”><异常名称=“IOException”> [call3.return]/return>org.jsr94.RuleServiceProviderImpl<联系我们 [src.setID]/callParameter> [call1.return]/callParameter><联系我们 [src.setID]/callParameter><联系我们...图3.第三章。RulesEngine和RuleSetProvider组件之间的映射 可以承认沟通方向是如何逆转的。图2中描述的协议描述。• 第一个使适配器接受由RulesEngine组件，并返回常量字符串XMLSERIALIZED，是调用的预期返回值，尽管在系统范围内没有执行有效调用。这解决了第3节中描述的独立进化情况。• 第二个绑定使RulesEngine组件能够在接受loadRules消息时检索给定的规则集：· 首先，适配器使用默认的提供程序实现值（org.jsr94.RuleServiceProviderImpl）调用getProvider。· 接下来，调用SQLRuleSet，将源消息提供的setID值（引用为[src.setID]）和上一次调用，标识提供程序（对应于[call1.return]）。请注意，所有调用都由id属性标识，以便能够从映射的其他部分引用其返回值· 最后，适配器调用getRuleSet，并将其结果规则集（[call3.return]）返回给RulesEngine组件。可以观察到如何在sourceMessage元素的声明中分配结果值，包括返回元素。所得衔接子的方案如图4所示。通过访问适配器管理器，工程师可以通过编辑映射来监督和调整组件的行为，以适应特定的需求。这种能力支持一种半自动的方法，在这种方法中，工程师可以很容易地发展组件，而主要是担心粗粒度的问题。J. 卡马拉等人/理论计算机科学电子笔记189（2007）2129setMode？loadRules？getProvider！取消规则集！getRuleSet！见图4。 图3中表示的映射的适配器协议。4.1.3协调管理器编译并转换组件之间的所有消息每当组件si向组件ti发送消息时，管理器利用存储在适配器库中的（S，T在此管理器中建立了会话信息存储库，以存储有关组件状态及其交互的特定信息。对于每一对交互组件（si，ti），在si第一次向ti发送消息时，在存储库中创建一个会话（图5.C）。具体来说，每个会话条目包含一组信息，包括：• 映射中声明的所有变量的实例• 组件接口中的实际参数和返回值。• 交互的当前状态（两个行为界面中的协议状态如果需要，此会话信息将随组件之间的每个消息而更新。会话信息可用于协调管理器中的机制，因为组件之间的某些交互可能会影响其他组件。4.2执行问题为了说明与我们的pro-task的实现相关的一些问题，使用了ANOJ。这是一个语言级别的Java AOP扩展，它高度代表了当前使用的AOP系统。本节重点介绍了为实现适应管理框架的功能而提供的一些关键结构和机制。4.2.1扩展组件接口元数据在组件中的合并已经使用Java注释实现。这些在运行时通过反射是可读的，因此使框架所需的关于组件的所有信息在运行时可用。具体来说，我们使用多值类型的Java注释，它有多个数据成员。我们通过包含自定义的注释类型（行为接口描述）来注释每个组件。 使用运行时RetentionPolicy允许在运行时读取注释。 如图6所示，接口描述包含所需方法的集合和协议描述。30J. 卡马拉等人/理论计算机科学电子笔记189（2007）21a）、RulesEngineComp RuleSetProvider#1<<数据库>>RulesDBb）、RulesEngineComp RuleSetProvider#1RulesEngine#1<<数据库>> RulesDB接口代表适配器代表会议代表接口代表适配器代表会议代表规则集提供程序规则数据库规则引擎组件规则集提供程序规则引擎规则数据库规则引擎组件c）、RulesEngineComp RuleSetProvider#1loadRules！RulesEngine#1<<数据库>> RulesDBd）、RulesEngineComp RuleSetProvider#1getProvider！取消规则集！getRuleSet！RulesEngine#1<<数据库>> RulesDB接口代表适配器代表会议代表接口代表适配器代表会议代表RuleSetProvider（RulesEngine，（RulesEngine#1，RulesEngineRuleSetProvider）RuleSetProvider#1）RulesDBRulesEngineCompRuleSetProvider（RulesEngine，（RulesEngine#1，RulesEngine RuleSetProvider）RuleSetProvider#1）RulesDBRulesEngineComp图五.简单的组件交互示例：初始系统上下文。接口RulesEngineComp、RulesDB和RuleSetProvider#1存储在接口存储库（a）中。组件RulesEngine#1加入上下文（b）。RulesEngine#1发送loadRules！.适配器（ RulesEngine ， RuleSetProvider ） 在 适 配 器 存 储 库 中 生 成 ， 并 且 组 件 （ RulesEngine#1 ，RuleSetProvider#1）的会话条目在会话存储库中创建（c）。请注意，为了清晰起见，该图表示交互的不同阶段的接口依赖关系，而不是@BID（states={“i：rpA”，“rpB”，“rpC”，“rpD”，“f：rpE”}，transitionf={@transition（s1=“rpA”，m=“getProvider”，s2=“rpB”），@transition（s1=“rpB”，m=“executeQuery”，s2=“rpC”），@transition（s1=“rpC”，m=“executeQuery”，s2=“rpD”），@transition（s1=“rpD”，m=“getRuleSet”，s2=“rpE”）}，required={@required（name=“executeQuery”，parameterNames={“statement”}，parameterTypes={“String”}，returnType=“boolean”，exceptions={“SQLException”}）}）public class Uncategorized {int getProvider（String provider）{.}boolean unique（String name，int name）{.} StringgetRuleSet（String name）{.}}图六、RuleSetProvider组件的带注释的接口说明协议中的初始状态和最终状态分别由i/f前 缀 。（LTS）。请注意，BID中省略了与操作接口相关的信息，因为它已经可以通过标准反射API获得。4.2.2框架实施关于框架的设计，为了提供所需的功能，需要定义的最小切入点J. 卡马拉等人/理论计算机科学电子笔记189（2007）2131示例切入点定义组件初始化pointcut函数（）：初始化（*.*. component. new（..）;组件调用pointcut pccentInvocation（）：call（**.*.component.*.* (..));API结构和机制组件识别org.aspectj.lang.JoinPointthisJoinPoint（getThis（）和getTarget（））参数值org.aspectj.lang.JoinPointSystem. out. println（）;方法信息org.aspectj.lang.JoinPoint.StaticPartorg.aspectj.lang.Signature（thisJoinPointStaticPart.getSignature（））类别识别和接口检查java.lang.reflect.Classjava.lang.reflect.Method表1切入点定义和用于框架的主要API类• 组件初始化：每当一个新的组件进入系统的上下文时，它就被满足了。接口管理器将使用它来存储接口相关信息。• 组件调用：指定系统上下文中从一个组件发送到另一个组件的所有消息。由适配器管理器用于适配器生成，由协调管理器用于会话创建、消息转换和会话信息更新。值得一提的是，由于系统中存在多个方面，因此对应于每个管理器的不同方面中的建议可以应用于单个连接点。在这种情况下，必须明确定义将通知应用于连接点这就是组件调用的情况为了遵守这一顺序，AEOJ使用优先级规则来确定应用建议的顺序。具有较高优先级的方面在具有较低优先级的方面之前执行其关于连接点的before通知。 当组件的方法被调用时，遵循的顺序是：（a）适配器管理器检查是否需要生成适配器。（b）协调管理器检查是否必须创建会话条目，以及（c）协调管理器翻译消息并更新会话信息。这种转换由映射驱动 这提供了一种优雅且非侵入性的方式来执行消息翻译。ADMJ还提供了源和目标组件标识机制，使用thisJoinPoint的getThis（）和getTarget（）方法。方法监视方法调用中的参数值getArguments（）方法也是由thisJoinPoint提供的。为了获得与方法相关的信息 ， 如 异 常 、 返 回 和 参 数 类 型 ， 以 及 参 数 和 方 法 名 称 ， 使 用thisJoinPointStaticPart提供的getSignature（）表1总结了框架中使用的主要API类。32J. 卡马拉等人/理论计算机科学电子笔记189（2007）21组件类识别和接口检查是使用Java Refraction API执行的。通过这个API，可以获得每个组件的类，以及来自它的信息，如名称，公共属性和方法签名描述。值得注意的是，参数名信息并不存储在标准的Java.class文件中，因此无法使用标准Java检索建议。但是，AIBRJ编译器确实使用以下内容丰富了已编译的类：信息.我们将认为我们有这些信息随时可供我们使用。5相关工作将AOSD应用于自适应并不是一个新的想法[11，17]，目前许多关于自适应和动态软件演化的工作都是基于它。David和Ledoux提出了一个架构来管理非功能性关注点的适应[8]。可适应关注点被赋予方面的形状。所提出的架构支持动态适应。在[14]中，Rashid和Ko- rtuem展示了面向方面的技术如何帮助适应普适计算环境。同样，这个想法是将系统的那些可以适应的方面在我们的方法中，主要关注的是使用方面来实现适应框架本身，而不是将系统的某些方面化。在我们的建议中，几个预编译的方面管理适应，分组在不同的管理人员，能够检索和解释适应所需的动态信息Redmond和Cahill在[16]中提出了Iguana/J架构和编程模型，以支持意外的动态适应。这里，每个功能类与包含适配代码的适配类的集合相关联。该关联也在单独的实体中被指定，以实现改进的可扩展性。相比之下，在我们的建议中，不同的适配器是专门为组件之间的每次交互构建和管理的，因为它们加入了系统的上下文。因此，适配代码被封装到方面中，尽管不是以静态的方式。相反，方面充当从组件收集的设计信息的解释者和组件之间交互的协调者6结论和未决问题在本文中，我们已经讨论了我们的方法，以支持动态组件演化的面向对象的动态组件自适应。我们提出了一个适应管理框架的设计，突出其优势作为一个潜在的工具，以支持组件的进化过程。然后，我们说明了我们的建议与相关工作的比较的基本困难为了测试这种方法，目前正在开发一个原型在As- pectJ。尽管该平台不支持动态织入，但它能够执行加载时织入，这足以证明其可操作性。J. 卡马拉等人/理论计算机科学电子笔记189（2007）2133框架的基础。我们关于未来工作的主要观点，旨在使用允许动态编织的中间件（如PROSE [13]）改进此原型。动态组件自适应已被证明是一个重要的问题，它需要大量的信息组件，他们成功地适应在生产环境。在我们看来，适应COTS产品的最明智的选择虽然我们目前的方法successies的要求，在简单的情况下执行适应，这是必要的，以探索替代方案，如动态方面的生成，其中适配器将被实现的方式方面的生成，应用和删除在运行时的要求。 这种方法将增加执行所需的基础设施的复杂性，需要对其进行一些重要的修改，例如包含新功能（例如，运行时方面代码生成和编译）。虽然目前的技术水平并没有使动态方面生成一个可行的方法，这是一个很有前途的选择，以考虑未来的研究，以扩大问题，以更复杂的情况下（特别是在开放系统的情况下）。引用[1] A. Bracciali，A. B.和C. Canal，A formal approach to component adaptation，The Journal of Systemsand Software74（2005），pp. 45-54，关于自动化基于代理的软件工程的特刊。[2] 艾 伦 河 ， 巴 西 - 地 和 D. Garlan ， A formal basis for architectural connection ， ACM Transactions onSoftware Engineering and Methodology6（1997），pp. 213-249[3] 运河角，L. Fuentes，E. Pimentel，J. M. Troya和A. Vallecillo，Adding Roles to CORBA Objects，IEEE Transactions on Software Engineering29（2003），pp.242-260[4] 运河角，J. M. Murillo和P. Poizat，软件适应，9[5] 卡纳，卡纳， P. 波伊扎坦和G。Salau？n，Synchronizingbeh avioramis atchinsoftacompin，in：R. Gorrieri和H. Wehrheim，editors，FMOODS，Lecture Notes in Computer Science4037（2006）. 63-77.[6] Cazzola ， J. J. ， W. 和 A. Rashid ， Semantic join point models ： Motivations ， notifications andrequirements ， in ： Proceedings of the Software Engineering Properties of Languages and AspectTechnologies Workshop（SPLAT[7] Cazzola，S. P.，W.和M. Ancona，The role of design information in software evolution，Proceedings ofthe Second ECOOP Workshop on Reconstruction ， AOP ， and Meta-Data for Software Evolution（RAMSE'05）（2005）。[8] David ， P.andT.Ledoux ， Towardsaframeworkforself-adaptivecomponent-basedapplications，Distributed Applications and Interoperable Systems。LNCS2893（2003），pp. 1-14号。[9] Kiczales ， G. ， E. Hilsdale ， J.Hugunin ， M.Kersten ， J. 棕 榈 和 W.G. Griswold ， An Overview ofANOJ，in：Proc. of the 15th European Conference on Object-Oriented Programming（ECOOP），LNCS2072（2001），pp.327-353[10] 科 彭 角 和 M. Strzer ， Pcdi ， Attacking the Fragile Pointcut Problem ， Proceedings of the EuropeanInteractive Workshop on Aspects in Software（EIWAS[11]M. Aksit，G. T. L.Bergmans，通过关注点的分离和组合实现适应性，面向对象程序设计中的特殊问题（1996），pp. 12比2334J. 卡马拉等人/理论计算机科学电子笔记189（2007）21[12] 马吉·J K. K.和D. Giannakopoulou，软件体系结构的行为分析，软件体系结构（1999），pp. 35比49[13] Popovici A.，A. F.和G.陈建民，一种面向移动计算的主动式中间件平台，第四届ACM/IFIP/USENIX国际中间件会议（2003）。[14] Rashid ， A. 和 G. Kortuem ， Adaptation as an aspect in pervasive computing ， Workshop onBuilding Software for Pervasive Computing at OOPSLA（2004）。[15] R.E.，F. 和D.Friedman，[16] 雷 德 蒙 湾 和 v.Cahill ， 支 持 应 用 程 序 行 为 的 非 预 期 动 态 适 应 ， 欧 洲 面 向 对 象 编 程 会 议（ECOOPLNCS2374（2002），pp. 205- 230[17] 你好，弗， J. 他是个好人，J。 MurilloanddE. 张文，“面向对象的程序设计方法”，北京大学出版社，1998年。（1998年）。[18] Szyperski ， C. ， “ComponentSoftware:BeyondObject-OrientedProgramming,”Adisson-Wesley,2003, 2[19] Yellin，D. M.和R. E. Strom，Protocol specifications and component adaptors，ACM Transactions onProgramming Languages and Systems2（1997），pp. 292-333。