构件自适应及其在基于构件的软件工程中的重要性

97《理论计算机科学电子札记》66卷第4期（2002）网址：http://www.elsevier.nl/locate/entcs/volume66.html17页系统成分适应Andrea Bracciali1Dipartimento diInformaticaUniversit`adiPisa意大利安东尼奥·布罗吉2Dipartimento diInformaticaUniversit`adiPisa意大利卡洛斯运河3马拉加大学计算机语言与科学研究所西班牙摘要构件自适应是基于构件的软件工程的关键问题之一。我们提出了一个正式的方法来适应组件不匹配的交互行为。该方法的四个主要方面是：（1）在组件接口中包含行为规范，（2）用于表达适配器规范的简单高级符号，（3）从给定的高级规范导出具体适配器的全自动过程，以及（4）用于验证适配器属性的有效技术。1 电子邮件地址：braccia@di.unipi.it2 电子邮件地址：brogi@di.unipi.it3电子邮件：canal@lcc.uma.es2002年由ElsevierScienceB出版。 诉 操作访问根据C CB Y-NC-N D许可证进行。BRACCIALI，BROGIAND CANAL981介绍构件自适应被广泛认为是基于构件的软件工程（CBSE）中的关键问题之一[4，16，14]。应用程序构建者能够轻松地调整现成的软件组件，使其在应用程序中正常工作，这是创建真正的组件市场和组件部署的必要条件[3]。可用的面向组件的平台（例如，CORBA [25]、COM [7]、Jav-aBeans[26]、VisualStudio.NET [20]）通常通过使用接口描述语言（IDL）来解决软件互操作性。提供一个IDL接口来定义一个组件所使用（可能需要）的方法的签名，这IDL接口突出了组件之间的签名不匹配，以适应或包装它们来克服这种差异。然而，即使可以克服签名问题，也不能保证组件将适当地互操作。事实上，由于交换消息的顺序和阻塞条件[27]，也就是说，由于所涉及的组件的行为的差异，失配也可能发生在协议级别虽然可以执行基于案例的测试来检查软件组件的兼容性，但需要更严格的技术来将组件集成从手工制作提升到工程活动。软件组件交互行为的形式化描述的可用性是必要的，以便严格验证由大量动态交互的组件组成的系统的属性[9]。例如，应用程序构建者希望能够预先确定包含第三方组件是否会在开发中的应用程序中引入死锁可能性在本文中，我们专注于适应组件，可能表现出不匹配的行为的问题在过去的几年里，组件自适应的问题许多面向实践的研究致力于分析当应用程序构建者必须（手动）调整第三方组件以在（可能根本上）不同的上下文中使用它时所面临的不同问题见[13，11，17]）。Yellin和Strom在他们的开创性论文[28]中为组件适配建立了正式的基础 他们使用有限状态机指定组件行为，并正式引入了适配器的概念，适配器是一个软件实体，能够让两个组件不匹配行为互操作。本文的目的是提出一个正式的方法来适应组件可能不匹配的交互行为。该方法的四个主要方面如下：BRACCIALI，BROGIAND CANAL99(i) 组件接口。我们扩展了传统的IDL接口的组件的行为的描述。因此，组件接口由两部分组成：签名定义（描述组件所需的功能）和行为规范（描述组件遵循的交互协议）。在语法上，签名以传统IDL的风格表示，而行为则使用π演算的子集表示[22]。- 一个进程代数，已被证明是特别适合于指定的动态和不断发展的系统。(ii) 适配器规格。我们提出了一个简单的符号来表达适配器的规范，该适配器旨在实现具有不匹配行为的两个组件的互操作适配器规范通过简单地陈述两个组件的动作和参数之间的一组对应关系来给出。该符号的区别在于它产生了适配器的高级部分规范(iii) 适配器推导。一个具体的适配器组件，然后自动生成，给定其部分规格和两个组件的接口。这个完全自动化的过程尝试构建一个适配器，允许组件在满足给定规范的同时进行互操作分离适配器规范和派生的优点是自动化生成正确适配器的详细实现的易出错、耗时的任务，从而简化（人类）软件开发人员的任务。(iv) 适配器属性。所述方法的一个重要部分是适配器应满足的特性的正式规范和验证我们展示了由适配器规范定义的约束以及适配器的其他有趣属性如何自然地由一组表征有效适配器行为的过程表示还说明了验证具体适配器是否满足一组属性的有效方法论文的其余部分组织如下。扩展组件接口介绍了节。2，而适配器规格的符号描述在节。3.第三章。节图4描述了从规范中自动生成适配器的过程节5展示了如何表达和验证适配器的属性。最后，第6节专门讨论相关工作，并提出一些结论性意见。2组件接口接口将根据角色进行描述[5]。通常，角色是一个组件与任何其他相关组件之间交互的抽象描述。因此，组件接口将由一组角色表示，每个角色都致力于组件行为的特定方面。BRACCIALI，BROGIAND CANAL100{||角色的具体化分为两个部分。第一个在签名级别描述组件，它类似于传统的IDL描述（例如CORBA）。相反，第二部分将使用从进程代数导出的符号来描述与角色签名roleName=签名输入输出动作行为交互模式}组件角色的签名接口声明了一组输入和输出操作。这些动作可以看作是角色发送和接收的消息集（代表组件操作和调用的方法请注意，通常IDL只表示组件向其环境提供的服务（即，其输出操作集），而我们还显式地表示组件所需的服务，作为一组输入操作。输入和输出动作都可以具有参数，表示在通信中交换的数据。可以键入参数以允许类型检查。行为界面是通过我们称之为交互模式的方式来描述的.直观地说，交互模式描述了组件可能（重复）向外部环境显示的有限交互行为的基本方面。我们用来描述这些模式的语言是同步π演算的一个加糖子集。由于微积分允许链接名称作为值发送和接收，它已被证明是一个非常有表现力的符号，用于描述应用程序中的软件组件的行为与不断变化的互连拓扑（如那些生活在开放系统中）。特别地，我们使用了π演算的多元版本[21]，其中元组，而不仅仅是单个名称，可以沿着链接发送行为表达式集的形式定义如下：E：：= 0|a. E|㈩ E|[x= y] E|E ||E|E + E a：：= tau|x？(d)|x! (d)特殊过程0表示不作为，而内部动作用τ表示。输入和输出动作分别用x？(d) 还有X！(d)其中x是执行动作所沿的链接，d是沿x发送或接收的名称元组（链接或数据）。限制，如（x）E，表示在表达式E中创建一个新的链接名称x。还有一个匹配运算符，用于指定条件行为。因此，如果x=y，模式[x=y]E表现为E，否则表现为0。最后，还定义了非确定性选择（+）和并行（）运算符求和E + E另一方面，只允许在属于不同BRACCIALI，BROGIAND CANAL101|||件.因此，E E尽管如此，完整的π演算也有一个允许同步的并行运算符（），但我们不使用它来描述交互模式。请注意，交互模式不包含递归。原因是它们旨在将交互的有限片段指定为表示组件行为的抽象方式。为了说明这个选择的含义，我们考虑一个按顺序读取文件的组件Reader 文件项将通过读取操作接收？(x)- 文件结束条件由一个特殊值表示。假设组件可以决定在任何时候通过发送一个动作中断来中断传输！（）中选择。用完整的（递归的）π演算表示的组件的行为将是：读者=阅读？（十）. （[x！=阅读器+[x=] 0）+ τ的突破！（）. 0表明该组件将重复地呈现读取的事实？动作，直到接收到一个ACK，或者它决定（通过执行一个tau动作）中断传输。然而，表示该特定组件的（非递归）交互模式P1P1 =读取？（十）. 0 + tau。突破！（）. 0在哪些方面的行为类似递归和替代后读？操作-已经通过将它们随着时间的推移进行投影，并通过将重复的操作折叠成单个操作来抽象。事实上，试图一次性描述分布式系统行为的所有方面必然会导致实际可用性低的复杂公式相反，我们专注于描述软件组件的有限并发行为，使属性的验证更容易处理。在某种意义上，选择考虑简单的非递归交互模式类似于在传统编程语言中引入类型 虽然类型检查一般不能保证程序的正确性，但它确实消除了绝大多数编程错误。类似地，虽然一组交互模式的兼容性不能保证并发系统的正确性，但它可以消除系统组装过程中的许多错误[2]。一个组件可以由多个角色或模式表示现在考虑我们的阅读器组件使用动作fwrite将接收到的文件复制到磁盘！然后关闭！.同样，它在递归π演算中的行为是：读者'=读？（十）. （[x！=快写！（十）. 读者+ [x=] fclose！（）. 0个）+ τ的突破！（）.关闭！（）. 0BRACCIALI，BROGIAND CANAL102现在，我们不再编写一个（但实际上更复杂）模式来表示组件，而是将其行为划分为两个独立的角色：一个用于描述它如何读取文件（即前面定义的模式P1），另一个用于描述它与文件系统的交互，由模式表示：P2= tau。fwrite！（数据）。 0 + tau。关闭！（）. 0因此，我们允许一个模块化的表示和分析的行为。每个角色都代表从该角色所连接到的组件的角度来看的读取器。因此，虽然决定发送一个fwrite！或者是一个关闭！在读者中，动作是由接收数据或文件结束而激发的，角色P2成功地表达了文件系统的观点，为此，读者组件似乎可以自由地决定发送任何一个动作。3适配器规格适应，在其一般性，是一个困难的问题，涉及大量的领域知识，并可能需要复杂的推理。 因此，我们的方法的目的是提供一种方法来指定所需的适应之间的两个组件在一个一般的和抽象的方式。此外，必要的适配的描述将用于自动构造第三个组件，我们称之为适配器，它负责在可能的情况下调解两个组件的交互，以便它们可以成功地互操作。在本节中，我们将说明一种简单而抽象的语言，用于描述两个组件的功能之间的预期映射我们首先观察到，适应并不简单地等同于替换链接名称。例如，考虑一个组件P通过url请求一个文件，服务器Q首先接收url，然后返回相应的文件。它们的行为接口分别是：P =请求！（网址）。回复？（第页）。 0Q = 查询？（地址）。快回来！（文件）。 0请求之间的连接！ 查询？，在回答？ 和快回来！可以用替换σ来定义：σ={t1/请求，t1/查询，t2/回复，t2/返回}这允许两个组件的互操作然而，在应用替换之后，Pσ和Qσ之间的通信将是直接和无过滤的，因为它们将共享链接名称。不幸的是，这与封装原则相反，因为一般来说，人们既不想修改组件，也不想让它们绕过适配器直接通信。此外，这种适应只能解决非常相似行为的基于重命名的不匹配总的来说，人们对适应感兴趣BRACCIALI，BROGIAND CANAL103减少不重要的不匹配，例如，需要重新排序和记住消息因此，我们通过一个映射来表示适配器规范，该映射建立了一些与两个组件的操作和数据相关的规则例如，表达针对先前示例的预期适配的映射被写为：M ={request！(url) <>query？(url)回复？（文件）<>返回！（file）;}M的第一条规则的含义是，每次P都会执行一个请求！输出动作时，Q必须执行相应的查询吗？输入动作。映射中的参数url和file显式地声明了数据之间参数在映射中有一个全局作用域，因此，即使在不同的规则中，所有相同名称的出现都引用同一个参数。直观地说，映射提供了一个适配器的最小规范，它将在两个组件P和Q之间扮演“中间组件”的角色这样的适配器将负责根据给定的规范介导P和Q之间的相互作用重要的是要注意，由映射定义的适配器规范抽象了组件行为的许多细节处理这些细节的负担留给了适配器构造的（自动）过程，这将在下一节中描述例如，适配器A的行为接口满足映射M给出的规范：A =请求？（网址）。查询！（网址）。返回？（文件）。回复！（文件）。 0这个适配器将保持P和Q的名称空间分离，并防止两者在没有它的中介的情况下相互作用观察到引入这样的适配器来连接P和Q具有将它们的通信从同步改变为异步的效果。实际上，适配器的任务就是将P和Q适配在一起，而不是充当它们之间的透明通信媒介。我们通过概述映射的语法和用法来总结本节，以指定两个重要的自适应示例• 多个动作对应。虽然前面的示例处理组件中的动作之间的一对一对应关系例如，考虑认证过程中涉及的两个分量P和Q假设P通过首先发送其用户名，然后发送密码来认证自己。相反，Q准备在一次射击中接受两个数据：P =用户！（我）。passwd！（pwd）。0 Q =登录？(usr，word）。 0BRACCIALI，BROGIAND CANAL104{所需的适配可以通过映射来指定M ={user！(me)，passwd！(pwd)>登录？(me（）;}其将由P执行的两个输出动作与由Q执行的单个输入动作相关联。映射还显示了参数的使用（即，ME和PWD）来指定要由适配器执行的所需数据记忆• 没有通讯员的行动 适应还必须处理一个组件的动作在另一个组件中没有对应动作的情况。例如，考虑一个对自身进行认证的组件P（actionusr！），查找存储库中存在的文件列表（目录？然后删除其中的两个（del！）.另一方面，仓库服务器Q不需要登录阶段，它提供文件列表（ls！），但需要客户端的标识才能删除（rm？）：P =用户！（同上）。dir？（列表）。del！（f1）。del（f2）。 0Q = ls！（d）. rm？(file、usr）。rm？(file、usr）。 0从Q的角度来看，认证关注点仅限于删除操作（rm）。为了明确地表示这两个组成部分之间的概念不对称性，从而便于设计和推理映射的高级规范，我们引入了关键字none。一个组件的动作如果在另一个组件中没有对应者，则可以不与任何动作相关联。因此，以下映射表明P的识别阶段在Q中不具有对应性，并且必须记录参数id以供后续使用。M=用户！(id)<> none;dir？(d)<>ls！(d);del！(f)<>rm？（f，id）;}4衔接子推导在本节中，我们将从两个角色的协议P和Q以及映射M开始，概述如何自动生成两个角色的具体适配器。适配器推导是由我们开发的用于检查组件的开放上下文的正确性的算法（的扩展版本）实现的[2]。直观地说，算法的目标是构建一个进程A，使得：(i) P|一|Q是成功的（即所有的痕迹都导致成功），(ii) A满足给定的映射M，也就是说，M指定的所有动作对应和数据依赖都在P的任何迹中得到尊重。|一|Q.BRACCIALI，BROGIAND CANAL105LFDF该算法通过尝试逐步消除在P的进化中可能发生的所有可能的死锁来逐步构建适配器A|一|Q.非正式地，虽然P的派生树|一|Q包含一个死锁，al-租m用一个动作α扩展A，它将触发一个死锁状态：• 选择这样的动作α，以便与P或Q被阻断的双重动作α相匹配。请注意，适配器只能匹配其中的一部分操作。例如，如果它还没有收集到足够的信息来构建满足M中指定的数据依赖关系的相应动作α，则它无法匹配输入动作α。• 由于可能有不止一个如果没有可执行的操作，则算法（实例）失败。• 每个实例维护通过匹配输出动作获取的一组数据、根据映射M的规则要最终匹配的一组动作、以及一组链接对应，以便保证两个角色之间的名称空间的分离• 每个算法实例在P的派生树|一|Q不包含死锁。如果要匹配的动作集为空，则算法实例成功终止，并返回完成的适配器。否则就会失败。如果所有实例都失败，则整个算法失败否则，它非确定性地返回找到的适配器之一再次考虑最后一个例子节。关于文件储存库服务器，该算法可以构造例如以下适配器A：A =用户？（同上）。ls？（d）. dir！（d）.del？（f1）。rm！(f1，id）。del？（f2）。rm！(f2，id）。 0容易观察到，组合物P|一|Q是无死锁的，并且A满足映射的“预期含义”，无论是在动作对应性还是数据依赖性方面。(For例如，A仅在从P接收到值id之后才将其转发给Q。现在是时候提供一个精确的特征，什么是映射的“预期含义”，以便能够正式声明适配器这是下一节的范围5适配器的可编程特性在本节中，我们将展示如何形式化和验证适配器是否满足映射的预期含义以及其他要求。BRACCIALI，BROGIAND CANAL106{5.1映射的语义如Sect中所述3、映射规则在被适配的两个组件中的动作之间建立对应再次考虑映射：M=用户！(id)<>none; dir？(d)<>ls！(d);del！(f)<>rm？（f，id）;}例如，它的第二条规则指出如何将列出目录的命令从DOS语法“翻译”为Unix语法。规则规定，每次一个动作！(d)是由一个组件执行的，适配器最终必须与一个动作目录同步。(d)另一个组件。因此，任何满足规则的适配器都必须适当地匹配动作对ls！(d) 而dir？(d).为了表示映射规则的语义，我们使用属性，属性描述映射对适配器施加的约束，独立于被适配组件的实际协议每个属性都表示为一个π演算过程，它执行规则中的操作任意次数。动作是从适配器的角度来表示的，并根据相应映射规则隐式声明的数据依赖关系进行组合例如，上述映射M的第二映射规则由以下属性表示：R2=（ls？（d）. dir！（d）. 0 ||R2）+tau。 0也就是说， 终止或执行操作的进程？(d) 然后dir！(d)，与自身的递归实例并行。根据映射规则中的参数引起的数据依赖性，属性R2确定适配器不应该执行输出操作dir！(d) 直到使用操作ls读取文件列表d为止？(d). 属性R2还指出，如果适配器执行ls？(d)动作，那么它最终将不得不执行一个目录！(d)行 动 上同样，对于M的第三个规则，我们有：R3 =（del？（f）. rm！（f，id）||R3）+tau。0然而，属性R3并不表示第三规则中的所有数据依赖性事实上，为了执行动作rm！（f，id），适配器必须使用先前在action user？(id)（其以不同的规则出现在映射中）。因此，有必要添加一个新的属性来反映这种隐式依赖关系：R4 =（用户？（同上）。R4a||R4）+tau。0 R4a = rm！（f，id）。R4a +tau。0请注意，最后一个属性与前面的属性R2和R3有何不同。因为行动用户？(id) RM！（f，id）来自不同的映射规则，它们之间不存在一一对应关系，但仍然成立BRACCIALI，BROGIAND CANAL107⊆σ。至少是个行动派吧(id)- 读取用户标识-必须在执行（任意次数）操作rm之前完成！（f，id）。最后，为了完成这个例子，让我们考虑M的第一条规则，它映射了用户的动作。(id) 变成零由于该规则没有在动作或数据之间建立任何依赖性，因此我们简单地推导出该过程：R1 =（用户？（同上）。0 ||R1）+tau。0这说明适配器可以执行用户操作？(id)任意次数。5.2性能验证正如我们所看到的，映射中的每个规则都让位于一个或多个π演算过程，表示适配器必须满足的属性为了验证它们，我们一次获取一个属性，并验证适配器执行的跟踪是否“包含”在属性的跟踪中因此，映射的含义被分解为简单的、“正交”的属性，这些属性每个属性指的是在映射规则中发生的动作，从映射规则中导出该属性，而适配器通常还包含其他动作（发生在映射的其他规则中）。因此，为了验证属性，我们将适配器投射到与正在考虑的属性相关的动作上这是通过隐藏运算符“/”来完成的，该运算符将任何与属性不相关的再次考虑第3节和第4节中描述的文件服务器的例子对于适配器：A =用户？（同上）。ls？（d）. dir！（d）.del？（f1）。rm！(f1，id）。del？（f2）。rm！(f2，id）。 0以及我们分别具有的性质R1，R2，R3，R4A/R1 =用户？（同上）。τ的τ的τ的τ的τ的τ的0 A/R2 =τ。ls？（d）. dir！（d）.τ的τ的τ的τ的0A/R3 = tau。τ的τ的del？（f1）。rm！（f1）。del？（f2）。rm！（f2）。 0A/R4 =用户？（同上）。τ的τ的τ的rm！(f1，id）。τ的rm！(f2，id）。 0为了检查适配器的轨迹（一旦投射）是否包含在属性的轨迹中，包含是根据弱模拟定义的给定两个π-演算过程A和R，A包含在R中，记为A R，i ∈ R1) 如果A=−→aA2) 如果A=100，则R=100。（其中= τ代表零或更多τ动作）。包含的定义确定，对于包含在R中的A，首先R必须能够执行A可能执行的任何操作a（在BRACCIALI，BROGIAND CANAL108这两种情况都是由一定数量的沉默行动造成的）;第二，如果A可以终止，通过达到不作为，R也必须能够终止最后，我们说一个适配器A满足一个性质Ri，（A/R）重要的是要注意，财产核查的过程总是会终止。事实上，由于行为是由有限的（非递归的）交互模式描述的，对行为（A/R）的痕迹的直接探索推动了对递归过程R的痕迹的有限探索。例如，回到前面的例子，很容易检查适配器A是否满足属性R1，R2，R3和R4。5.3附加属性在前面的部分中，我们已经展示了如何将映射的含义形式化地表达为一组（有限的）属性，以及如何有效地验证适配器是否满足一组属性。映射意义的精确表征的可用性使我们能够正式建立第4节中描述的算法的可靠性另一方面，表达和验证适配器的属性的可能性允许验证不是由算法产生的适配器，以及验证适配器的附加属性。从映射中获得的属性确保适配器中动作之间的足够的事实上，这可能是适配器的一个有趣的能力，即能够充当遵循不同协议的两个组件之间的临时缓冲然而，例如，可能希望检查规则中的所有动作是否在再次使用相同的规则。例如，考虑两个分量P和Q交换两个数的序列假设它们对应的协议是：P =写！（n1）。写！（n2）。 0Q 读？（m1）。阅读？（m2）。0由于动作在两个协议中的命名不同，我们在它们之间放置了一个适配器，由映射指定：M ={write！(n) <>阅读？(n);}从其导出以下适配器属性R1 =（写？（n）。读！（n）。0 ||R1）+tau。 0然而，值得注意的是，由于适配器的异步特性，数据可能不会以正确的顺序接收，就像下面的适配器一样：一= 写什么？（n1）。写什么？（n2）。 读！（n2）。读！（n1）。0BRACCIALI，BROGIAND CANAL109{{{满足R。为了确保数据以正确的顺序交换，我们可以要求给定的适配器满足以下附加属性：R2 =（写？（n）。读！（n）。R2）+tau。0另一个可能需要指定的有趣属性是，某些数据值应该只被适配器使用一次例如，考虑一种编辑服务，客户必须付费才能打印或拼写检查他们的文档：角色EditingService =签名打印？(Data doc，Data money）;spell？(Data doc，Data money）;.}还考虑一个客户组件，该组件被设计为将支付与打印和拼写检查请求分开发送：客户角色=签名pagar！(Datadinero）;imprimir！(Data fichero）;corregir！(Datafichero ）;.}所需的适配器可以通过映射指定M=pagar！(m) <> none;imprimir！(d) <> print？（d，m）;corregir！(d)<>咒语？（m）;}其中参数m的使用说明了三个映射规则中的动作之间的依赖性。如前面的例子所示，从这些规则中派生的属性将确保要向编辑服务发送打印或拼写请求，适配器必须首先从客户那里收到付款，但这并不阻止同一笔付款用于多个请求。为了确保每个不同的请求之前都有不同的支付，可以强制有效的适配器满足以下附加属性：R =（pagar？（m）。（打印！（d，m）。0 +法术！（d，m）。0) ||R）+tau。0更一般地，人们可能希望还验证给定的适配器是否满足其中一个组件的某些要求例如，考虑一个组件，它通过封装方法集来封装变量以支持临时数据存储。快去！.还考虑第二个组件，它希望根据映射使用第一个组件提供的服务：M ={write！(x) <> set？(x);阅读？(y)<>get！(y);}人们可能希望检查，在引入适配器之后，第二个组件以一致的方式使用，在变量初始化之前不读取变量这可以通过引入额外的BRACCIALI，BROGIAND CANAL110属性：R =设置？（十）. Ra + tau。 0Ra =设置？（十）. Ra + get！（十）. Ra + tau。 0总而言之，在本节中，我们已经展示了如何在适配器上指定不同的属性，以及在开发适配器后如何检查这些属性我们目前正在努力在派生算法本身中考虑它们，因此它们可以在适配器的构建过程中进行验证。6总结发言一些作者已经提出了扩展当前的IDL，以处理组件接口的行为方面使用有限状态机来描述软件组件的行为例如在[8，19，28]中提出。有限状态机的主要优点是它们的简单性支持协议兼容性的简单而有效的验证另一方面，这样的简单性是一个严重的表现力约束建模复杂的开放分布式系统。进程代数具有更有表现力的协议描述，能够对并发系统进行更复杂的分析[1，23，24]，并支持系统模拟和安全性和活性属性的形式化推导。特别是π演算的有用性已经被说明用于描述组件模型，如COM [12]和CORBA [15]，以及架构描述语言，如Darwin [18]和LEDA [5]。然而，将进程代数用于软件规范的主要缺点与分析的固有复杂性有关。为了管理这种复杂性，作者以前的工作已经描述了模块化和部分规范的使用，通过在空间（角色）[6]和时间（有限交互模式）[2]上投影行为[11，13]中报告了组件互连、失配和自适应，而[1，6，10]中给出了检测交互失配的正式方法。Yellin和Strom [28]的工作专门解决了软件适配的问题，这构成了我们工作的起点它们使用有限状态语法来指定组件之间的交互协议，定义兼容性关系，并解决（半）自动适配器生成的任务他们的方法的一些重要限制与所使用的符号的表达能力例如，不可能代表内部选择、行为的平行组合或新过程的创建。此外，所描述的系统的架构是静态的，并且它们不处理诸如重新组织系统的通信拓扑之类的问题，当使用π演算时，这种可能性立即变得可用。此外，非对称意义BRACCIALI，BROGIAND CANAL111他们给输入和输出的行动使得有必要使用ex machina控制系统演化的仲裁者。本文的主要目的是有助于定义一种方法，用于自动开发能够解决异构交互组件之间的我们的工作属于研究流，提倡应用正式的方法，特别是进程代数，来描述软件系统。如[2，6]所示，采用π演算扩展组件接口为自动验证交互系统的属性铺平了道路，例如系统组件遵循的协议的兼容性在为适配器的系统开发奠定基础之后，我们打算将我们未来的活动投入到开发一个用户友好的环境中，以便于在实际CBSE应用中试验所提出的方法。引用[1] R. Allen和D.加兰架构连接的正式基础。ACM Trans. on SoftwareEngineering and Methodology，6（3）：213[2] A. Bracciali，A.Brogi和F.图里尼协调互动模式。在ACM Symposium on Applied Computing（SACACM Press，2001.[3] A.W.布朗和H.C.沃尔瑙CBSE的现状。IEEE软件，1998年。[4] G. H.坎贝尔适应性强的组件。ICSE 1999，第685 - 686页。IEEE Press，1999.[5] C. Canal，E. Pimentel和J.M.特洛伊动态软件架构的规范和细化。软件架构，第107-126页。Kluwer Academic Publishers，1999.[6] C. Canal，E. Pimentel和J.M.特洛伊软件体系结构中的兼容性和继承性。计算机程序设计科学，41：105[7] D.查普尔 了解ActiveX和OLE。 中国科学院出版社，1996年.[8] I. Cho，J.McGregor，and L.克劳斯一种基于协议的方法，用于指定对象之间的互操作性。在工具'26的程序IEEE Press，1998.[9] E. Clarke，O. Grumberg和D.久了有限状态并发系统的验证工具。在十年的Springer-Verlag，1994.[10] D.比较P.Inverardi和A. L.狼发现组件行为中的架构不匹配。Science ofComputer Programming，33（2）：101BRACCIALI，BROGIAND CANAL112[11] S. Ducasse和T.里奇纳可执行连接器：面向可重用设计元素。在ACM软件工程基础（ESEC/FSESpringer Verlag，1997年。[12] LMG 费斯建模 微索夫 COM使用π演算。在FormalMethodsSpringer Verlag，1999年。[13] D.加兰河Allen，andJ. Ockerbloom.架构失配：为什么重用如此困难。IEEESoftware，12（6）：17[14] D. Garlan和B.施梅尔普适计算环境中基于协同的软件工程2001年，第四届ICSE基于代理的软件工程研讨会[15] M. Gaspari和G.萨瓦塔罗新的异步CORBA消息服务的进程代数规范。在ECOOP？99，LNCS第1628号，第495-518页。Springer，1999年。[16] George T.海涅曼 组件适配技术的评估。在1999年，第二届ICSE基于代理的软件工程。[17] S.希萨姆湾Wallnau和R. Seacord 从商业组件构建系统。软件工程中的SEI系列，2001年。[18] J. Magee，S. Eisenbach，and J. Kramer. 在π演算中模拟达尔文。 分布式系统的理论与实践，LNCS第938期，第133-152页。Springer Verlag，1995年。[19] J. Magee、J. Kramer和D. Giannakopoulou软件体系结构的行为分析。软件架构，第35-49页。Kluwer Academic Publishers，1999.[20] Microsoft Corporation. .NET编程Web。http://msdn.microsoft.com的网站。[21] R.米尔纳多进π-演算：教程。技术报告，爱丁堡大学，1991年10月。[22] R. Milner，J.Parrow，and D.沃克移动过程的演算。信息与计算杂志，100：1[23] A. P. Moore，J.E. Klinker和D. M.米赫尔契奇如何构造说服证明者的形式论证。在工业强度正式方法在实践中。Springer Verlag，1999年。[24] E. Najm，A.尼穆尔和JB史蒂芬妮分布式对象接口的无限类型。 第三届IFIP正式方法会议论文集开放式基于对象的分布式系统- FMOODS'99。Kluwer Academic Publishers，1999.[25] OMG. 公共对象请求代理：体系结构和规范。 对象管理组。 http：//www.omg.org。BRACCIALI，BROGIAND CANAL113[26] 太阳微系统公司JavaBeans API规范。http://java.sun.com/beans/docs的网站。[27] A. Vallecillo，J.Hern'andez和J. M. 好的。对象互操作性的新问题。面向对象技术：ECOOP 2000 Workshop Reader，LNCS第1964期，第256-269页。Springer Verlag，2000年。[28] D. M. Yellin 和 R.E. Strom. 协 议 规 范 和 组 件 适 配 器 。 ACM Trans. onProgramming Languages and Systems，19（2）：292-333，March 1997.