实现软件架构协调的方法和应用：UML 2.0标准和形式化方法结合的实践指南.

理论计算机科学电子笔记127（2005）165-181www.elsevier.com/locate/entcs通过架构协调实现进化Paris Avgeriou1 Nicolas Guel fi2 Gilles Perrouin3软件工程能力中心科学、技术和通信卢森堡大学6，rue RichardCoudenhove-Kalergi卢森堡摘要系统演化周期中的一个可能场景是将一组新需求转化为软件体系结构设计，并随后更新系统实现。在本文中，我们认为，这种形式的前瞻性工程，即使解决了新的系统要求，往往忽略了实施的限制。 架构师还必须对系统进行反向工程，以便使这些约束明确。 因此，我们提出了一种方法，我们调和两个架构模型，一个是正向工程的要求，另一个是逆向工程的实现。最终的协调模型最佳地适应紧急的需求集和实际的系统实现。本文的贡献是双重的：在软件演化的背景下，架构协调的应用和一种方法来形式化的具体化和转换的架构模型。架构建模基于UML 2.0标准，而形式化方法基于集合论和一阶逻辑。关键词：软件架构，架构设计，模型转换，架构恢复，架构协调。1介绍现在已经很好地建立了软件的进化不应该掉以轻心，因为它可能相当于总生命周期成本的90%作为一个重新-1电子邮件：paris. uni.lu2电子邮件：nicolas. uni.lu3 电子邮件：gilles. uni.lu1571-0661 © 2005 Elsevier B. V.在CC BY-NC-ND许可下开放访问。doi：10.1016/j.entcs.2004.08.042166P. Avgeriou等人理论计算机科学电子笔记127（2005）165因此，软件演化已经成为软件工程的一个新的和有前途的领域，它解决了软件变更和软件维护的问题[16，38]。尽管对软件进化的研究已经进行了30多年，但直到最近才开始出现具体的结果，研究社区才开始理解其重要性。[15]《易经》：在过去的几年里，一些最重要的进展包括：进化的八个定律[14]，软件进化的现象学[4，12，16]，形式化软件进化的理论和实践[15，22]，分析和描述系统进化的工具[38，29，33]。软件进化的研究致力于回答“如何”涉及到系统演化的方法、实践和工具，特别是同步三个不同的实体：1）不断变化的现实世界的模型，例如电子商务系统的域模型，2）系统的规范The ‘what’ and ‘why’ observethe phenomenon of software evolution, trying to identify its causes and itsinternal本文讨论了软件演化的真实世界模型的范围可能从整个业务系统的完整域模型或业务模型到正在开发的软件系统的最小需求规范。然而，出于本文的目的，我们只对软件需求规范感兴趣，并认为需求确实定义良好。就系统规范而言，它是进化的关键因素，因为它形式化了要构建的系统的描述，并将抽象的现实世界领域模型和系统实现联系起来[15，27]。在我们的方法中，我们采用软件架构作为系统规范的一种形式，因为它已经被提出作为支持系统演化的理想抽象[2，10，11，32]。基于架构的演化的一个典型场景是设计系统这种正向工程方法的问题在于，体系结构设计只考虑了需求集，而没有考虑现有的系统实现。因此，在架构中忽略了实现约束，这反过来又不能正确地实现到代码中。显然，系统实现隐含地包含大量的设计决策，这些设计决策“隐藏”在代码中，并且可能与架构中出现的新设计决策集相 即使我们看了在系统中，并试图确定实施的限制，我们将探讨-P. Avgeriou等人理论计算机科学电子笔记127（2005）165167除非我们对系统进行反向工程，否则无法识别所有内容。本文提出了一种方法来解决这个问题，通过应用架构协调。特别是，用于开发下一个系统版本的体系结构模型是从协调两个体系结构模型中得出的，一个是从需求规范正向工程的，另一个是从系统实现反向工程的。从这个意义上说，协调的体系结构将不仅解决新的需求，而且还将考虑实现约束。软件架构的文档是基于UML 2.0标准和形式化方法。论文的其余部分组织如下：第2节提供了通过架构协调进行进化的方法的细节，包括用于架构描述的非正式和正式技术。第三节通过案例研究说明了该方法的应用，第四节介绍了建筑协调方面的一些相关研究工作最后，第5节总结了一些结论。2架构协调2.1和解进程在演进周期的开始，我们有一个现有的系统实现以及一组新的需求。 它们的核对过程由三个步骤组成，如图1所示。Fig. 1. 一个演化周期在第一阶段，我们检查实现代码，并对实现的系统进行反向架构，以恢复其架构，我们将其命名为反向架构模型或RAM。我们并没有规定一种特定的反向架构方法，尽管有一些这样的技术和工具被提出，例如[9，23，29，33，37，38]中的技术和RAM主要侧重于确定可能在以下过程中发挥重要作用的实施限制：168P. Avgeriou等人理论计算机科学电子笔记127（2005）165系统进化。这些约束通常以自然语言的形式表示，并伴随着UML图或形式化模型。在同一阶段，我们使用新的需求规范来设计系统的理想架构，我们将其命名为Forward Architectural Model或FAM。这种架构的前瞻性工程设计可以通过遵循任何架构驱动的软件开发过程来执行。必须强调的是，FAM明确地从需求方面派生，并努力理想地满足新的需求。执行方面的制约因素在此不受太多关注，因为这些问题将在下一阶段的和解过程中处理。第二个也是最关键的阶段是将RAM和FAM连接到联合架构模型（JAM）中，该模型必须满足新的需求集和实现约束。这是通过执行转换来实现的，该转换接受RAM和FAM作为输入，并产生JAM作为输出。具体来说，架构师必须完成以下步骤：(i) 确定与FAM相矛盾的实施限制这些实现约束来自架构师在前一个演进周期中做出的设计决策，并与FAM中做出的新设计决策相矛盾。约束可以以任何形式出现，尽管我们只是建议使用自然语言与UML或正式模型相结合。这是因为软件体系结构社区仍在试图解决精确表示局部或全局体系结构约束的问题[20]。(ii) 解决因实施制约而产生的问题为了解决每一个这样的问题，架构师需要决定以下操作之一或组合：(a) 保留FAM的部分，删除导致问题的RAM部分(b) 保留RAM的部分，删除FAM中导致问题的部分(c) 想出一个折衷的解决方案，混合这两个部分。在这种情况下，可以删除两个模型中的一些元素，保留其他元素，同时可以添加更多元素(iii) 完成JAM。这些问题的解决可能会对其他架构元素产生影响，而这些元素本身并不是问题的一部分。因此，架构师需要做出一些关于保留、删除或修改由协调操作所影响的FAM和RAM元素的P. Avgeriou等人理论计算机科学电子笔记127（2005）165169图二.几个演化周期这一过程的最后阶段涉及根据JAM构建新版本的系统，并更新要求，以图2描述了所提出的方法在几个演化周期中的情况，还显示了演化过程的其余细节最重要的是要强调，JAM始终会向下一个进化周期提供反馈。首先，如前所述，联合资产评估模型不仅用于开发系统的下一个实施版本，而且还用于根据核对结果更新需求其次，JAM作为系统唯一有效的体系结构模型，被用作FAM和RAM的起点。下一次迭代：从JAMi-1开始，通过考虑新的需求集Ri和实现Ii，设计FAMi和RAMi分别接下来的两个小节提出了两种不同的描述架构模型的方法：非正式地使用UML 2.0，以及正式地使用集合论和一阶逻辑。2.2UML中体系结构模型的描述架构描述由多个视图组成[6，10，11，13]。 为了减少调和两个复杂多视图170P. Avgeriou等人理论计算机科学电子笔记127（2005）165在架构模型中，我们关注的是被认为包含最重要的架构信息的视图：组件和连接器视图[6]。该视图通过显示组件和连接器来处理系统运行时，组件是运行时计算或数据存储的单元，连接器是组件之间的交互机制然而，同样的和解理论也同样适用于其他观点。软件体系结构的文档编制是在体系结构描述语言（ADL）的帮助下完成的，其目的是形式化地表示软件体系结构[21]。不幸的是，这些语言从未在行业中广泛使用，而且大多数都缺乏适当工具的支持。然而，最近的趋势是使用广泛接受的统一建模语言作为ADL，它已成为软件设计的我们已经采用了这种方法，并且我们一直致力于紧急UML 2.0标准[26]，该标准声称为建模软件架构提供了因此，我们的方法建议使用UML 2.0元素，特别是那些来自复合结构和组件包的元素来建模组件和连接器视图。具体而言，用于组件和连接器视图的元素包括：(i) 组件，是类的专门化，因此具有属性和操作，但也与所提供的和所需的接口相关联。组件还允许具有由属性组成的内部结构，这些属性反过来描述特定类的实例集。最后，组件可以拥有端口，这些端口将它们的交互点形式化，(ii) 连接器，是将一个组件的所需接口连接到另一个组件的所提供接口的组装连接器，或者是将组件的端口链接到其内部零件的委托连接器(iii) 接口，作为组件必须遵守的契约一个接口或者被提供来描述一个组件所提供的一组功能，或者被要求来描述一个组件期望从其环境中获得的一组功能(iv) 端口，指定拥有它的组件与其环境之间或组件（的行为）与其内部部件之间的不同交互点。端口可以指定拥有它们的组件的所需和所提供的接口。行为端口是端口的一种特殊情况，它将所有传入的请求发送给拥有该端口的分类器，而不是其内部部分。P. Avgeriou等人理论计算机科学电子笔记127（2005）165171(v) 类，表示实现组件内部结构的组成部分。这些不用于通用类图，但在复合结构图中，显示了组件的所需和所提供的接口如何通过相应的端口委托到其内部部件或从其内部部件委托。通常复合结构图不包含类本身，而是以属性的形式包含类的实例集。图3展示了组件和连接器视图的元模型，它是UML 2.0元模型的一个子集，特别是组件和复合结构包。为了简单起见，省略了一些元件和其他细节。图三. UML 2.0组件和连接器视图元素的元模型（改编自[26]）2.3建筑模型的形式化描述UML的语法和语义只是通过一个四层元建模架构[25，26]半正式地定义的，该架构使用UML、自然语言和OCL。形式化地指定语言语义的趋势源于对UML模型提供严格分析和自动转换的需求[17，34]。UML的不同方面（例如，用于建模系统结构的类/组件图、用于建模系统行为的活动/状态图过程代数[24]和Petri网[1]允许系统行为的形式化，而逻辑，集合和代数规范[5，3，8]用于形式化结构模型。图语法技术[31]也被用于形式化UML类和组件图[35，7]。我们已经集中于组件和连接器视图的形式化，172P. Avgeriou等人理论计算机科学电子笔记127（2005）165{||}它使用了UML 2.0结构模型。具体来说，我们使用集合论和一阶逻辑定义了一个正式的元模型这个正式的元模型基于Richters [30]的类似工作，它提供了对象模型（类，属性，操作，关联和泛化层次结构）的明确定义，并定义了OCL的语义。我们已经扩展了元模型，以定义组件和连接器视图的元素，即组件，端口，连接器，接口和属性，并指定它们的组成。因此，我们使用这个正式的元模型来形式化的rec-假设Re是满足一组逻辑公式的三个UML模型之间的关系，这些公式是从架构师的交易决策中推断出来的m，m=（FAM，RAM，JAM）m=0. 整个正式元模型can’t be included due to space restrictions, but a sample of these formulas aregiven3为例选 择 用 于 本 案 例 研 究 的 系 统 是 一 个 流 行 的 开 源 LearninggManagementSystem，namedGanesha[http：//www. anemalab. org/ganesha]，支持高等教育和培训机构的电子学习。选择该系统有两个原因：a）作为一个开放源代码项目，其代码可以随意检查，而不会出现商业系统的版权问题; b）其基于PHP的简单中型代码使其易于管理，适合此类实验。出于说明的目的，本节重点介绍该系统的特定组件（聊天组件）的协调，该组件允许基本的聊天功能，例如发送和接收消息，以及查看已连接用户的列表。 这个组件的逆向工程架构模型是基于上一次迭代的JAM和现有的系统实现设计的。如图4所示，聊天组件是通过许多PHP文件实现的，通过连接器进行通信，连接器只是它们之间的调用。这些组件“隐藏”了设计决策，这些决策可能在演化过程中充当实现约束。特别是(i) index.php创建了一个整体框架集，其中包括用于显示消息的框架、有关已连接用户的信息以及用于输入和格式化消息的GUI元素。(ii) title.php检查使用的浏览器，并使用正确的浏览器详细信息调用list.phpP. Avgeriou等人理论计算机科学电子笔记127（2005）165173见图4。 Chat组件(iii) footer.php是框架集底部的框架，它显示所有用于更改字体颜色和样式的GUI元素，并在发生此类更改时通知in-put.php。(iv) list.php为新连接的用户更新数据库，并显示已到达的用户和当前连接的成员集(v) input.php显示用于输入消息的GUI元素，根据footer.php将这些消息转换为正确的格式，并调用chat.php显示消息。(vi) 如果一条消息已经写入文本框中，则input.php会调用chat.php，并显示该消息以及有关发布者的信息。它还将消息存储到数据库中。在当前的发展周期中，新的需求要求实现多个聊天室，这些聊天室对应于不同的谈话主题，以及在用户之间交换文件的能力。因此，架构师从上一次迭代的JAM开始设计满足这些新需求的FAM。图5所示的正向架构模型自然与RAM非常相似，除了两个新添加的组件：(i) file.php实现了文件管理的功能，174P. Avgeriou等人理论计算机科学电子笔记127（2005）165图五. 聊天组件适当的图形用户界面。(ii) room.php实现了更改房间和显示用户位置的功能。它由index.php调用，它还访问数据库以检索和存储有关房间的信息为了执行协调，我们需要查看这两个模型，并尝试解决由实现约束引起的潜在问题。在这个特定的案例中，有三个实现约束导致了FAM的问题，架构师需要权衡如何最好地解决它们。我们用三种形式描述架构师对于OCL部分，我们考虑一个由包“evol”和三个子包组成的模型，这些子三个实施限制和相应的协调行动，导致联合模型（图6），如下所示P. Avgeriou等人理论计算机科学电子笔记127（2005）165175(i) 输入文本的GUI已经存在，并且包含在input.php中。理想情况下，我们希望将更衣室的GUI放在同一个地方。因此，room.php中的GUI代码应该移动到input.php中，input.php应该将此信息转发给前者，以实现应用程序逻辑。因此，这两个组件被修改为input2.php和room2.php，同时它们也通过连接器连接以进行信息交换。逻辑：room.php∈classFAM，input.php∈classRAM输入2.php∈classJAM输入pIn 2，pRo 3∈portsJAM输入c∈connsJAMwithconnends（c）={pIn 2，pRo 3}OCL：见图6。 Chat组件176P. Avgeriou等人理论计算机科学电子笔记127（2005）165--evol软件包context FAM：：chat inv：self.ownedMember->exists（c| c.oclIsTypeOf（类）和c.nameRAM：：chat.ownedMember->exists（c| c.oclIsTypeOf（Class）和c.name='input.php'）意味着JAM：：chat.ownedMember->exists（c1，c2| c1.oclIsTypeOf（Class）和c2.oclIsTypeOf（Class）以及c1.name'和c1.nameJAM：：chat.ownedMember->exists（c| c.oclIsKindOf（Connector）和c.end.role->size（）=2，c.end.role->includesAll（Set{pIn2，pRo3}））endpackage(ii) List.php在右侧框架中显示当前连接的用户，这也是我们想要显示用户所在房间的信息的地方。因此，room2.php需要通过连接器将此信息传递给list.php。logic：pLi 3，pRo 4∈portsJAM<$c∈connsJAM<$cconnends（c）=pLi 3，pRo 4OCL：evol软件包context JAM：：chat inv：self.ownedMember->exists（c| c.oclIsKindOf（Connector）和c.end.role->size（）=2，c.end.role->includesAll（Set{pLi3，pRo4}））endpackage(iii) Ganesha中已经有一个组件提供文件管理，例如上传和下载文件。这在聊天组件的RAM中不可见，但在整个系统的RAM中可见。从这个意义上说，file.php应该通过它的文件管理接口重用这个组件，而不是从头开始实现这个功能。因此，该组件被稍微修改为file2.php，并需要inter-facefile mgt来操作，这是作为聊天组件的必需接口添加的logic：file.php∈classFAMfile2.php∈classJAMpF i 2，pCChat 3∈portsJAMc∈connsJAM，connends（c）={pF i 2，pCChat 3}OCL：P. Avgeriou等人理论计算机科学电子笔记127（2005）165177evol软件包context JAM：：chat inv：FAM：：chat.ownedMember->exists（c| c.oclIsTypeOf（Class）和c.name='file.php'）意味着self.ownedMember->exists（c| c.oclIsTypeOf（类）和c.name和self.ownedMember->exists（c| c.oclIsKindOf（Connector）和c.end.role->size（）=2和c.end.role->includesAll（Set{pFi2，pCCat3}））和pCCat3.required->includes（file mgt）端包4相关工作本文所描述的方法是基于研究工作方面弥合系统的实施和它的要求之间的差距。Perry和Wolf在[28]中首先介绍了侵蚀和漂移的架构问题，它们表达了实现架构偏离理想架构的现象，无论是故意的还是由于差异。在[36]中，Tran等人引入了一种架构它们区分了正向修复和反向修复，前者是改变实现架构以匹配概念，后者则相反。尽管他们主要使用开放源码软件，在那里更有可能发生架构漂移，但他们声称他们的结果也可以推广到商业系统他们没有提出一种方法来执行概念架构的设计，但他们建议的工具，如[29，33]中的反向架构。大致上，在[18]中已经处理了相同的问题，其中Medvidovic等人提出了两个中间步骤的引入：a）根据需求设计“发现的”架构，以及b）根据实现设计“恢复的”架构。这两个体系结构模型可以更容易地桥接到系统的实际体系结构中。架构的The ‘recovery’178P. Avgeriou等人理论计算机科学电子笔记127（2005）165使用逆向工程代码并将派生类打包到体系结构元素中的技术的混合来执行体系结构。最终的桥接是手动执行的，方法是将架构样式应用到两个模型之一，然后将第二个模型映射到结果，或者首先集成两个模型，然后应用架构样式。我们自己的方法受到上述两种方法的影响，因为我们采用了FAM和RAM的中间步骤，[18]建议，我们已经设计了类似于正向和反向修复的架构和解行动[36]。我们的工作扩展了这些方法，因为我们为架构模型的定义提供了形式主义，并随后进行了转换，以导出最终模型。这种基于形式转换的过程只是我们哲学的一部分，我们的哲学认为，一切都可以被认为是不同工件之间的转换，这将在最后一节解释。5结论在本文中，我们已经论证了系统的演化不能以正向工程风格有效地执行，例如，将新的系统需求转换为体系结构，然后转换为代码。 问题是，现有系统的实施可能会对新的要求产生重大限制，因此必须加以考虑。 这些非显式的实现约束不能显式化，除非对它们进行反向工程。因此，我们建议设计两个架构模型，第一个基于需求，第二个基于现有的实现，然后通过基于逻辑的转换协调这两个模型。我们的方法的附加值涉及两个问题：通过架构和解的软件进化的背景下，以克服正向工程和形式化的架构模型和执行和解所需的转换的问题。这种方法构成了我们对基于模型的软件工程的整体看法的代表性部分。特别是，我们相信转换是整个开发生命周期中的关键机制，并且所有内容都可以放在将工件转换为其他工件的上下文中。这些转换可以发生：a）在不同的抽象级别，例如，从设计到代码：b）在相同的抽象层次，例如，从一个架构模型到另一个架构模型，以细化前者。转换非常重要，因为它们提供了所创建工件之间的关联;它们是概念上的P. Avgeriou等人理论计算机科学电子笔记127（2005）165179一切都在一个连贯的集合中。这种绑定机制可以通过向前或向后跟踪各种工件，为开发过程中所做的决策提供基本原理。我们目前正在详细阐述各种工件的其他类型的此类转换我们还打算为指定和随后分析正式模型提供工具支持。引用[1] 巴雷西湖用对象Petri网形式化uml的一些初步提示，于：集成设计与过程技术，2002年。[2] Bosch，J.，“软件架构的设计和使用：采用和发展产品线方法”，ACM出版社/Addison-Wesley出版公司，两千[3] 布鲁河，联合欣克尔角 霍夫曼角，澳-地 克莱因湾 帕希湾 Rumpe和V.Thurner，Towards aformalization of the unified modeling language ， Lecture Notes in Computer Science1241（1997）。[4] 巴克利，J.，T. Mens，M. Zenger，A. Rashid和G. Towards aTaxonomy of Software Change，Journal on Software Mainteance and Evolution：Research and Practice（2004）。[5] 克拉克，T.和A. Evans，统一建模语言，在：匿名，编辑，第二届北方正式方法研讨会（1998年）。[6] Clements，P.，F.巴赫曼湖Bass，D. Garlan，J. Ivers，R.利特尔河Nord和J. Sta Joreord，[7] Engels，G.和R. Heckel，Graph transformation as uniform formal framework for systemmodeling and model evolution ， in ： European Conference on Software MaintenanceandReengineering（CSMR 2001），International Special Session on Formal Foundations ofSoftware Evolution，Lisbon，Portugal，2001。[8] 法弗尔湖M.，UML静态模型和代数规范之间的正式映射，在：A.埃文斯河，巴西-地France ，A. Moreira和B. Rumpe ，editors，Practical UML-BasedRigorousDevelopmentMethods-WorkshopofthepUML-Group ， UML2001 ，Toronto，Canada，LNIP-7（2001），pp.113-127[9] Guo，G.是的，J. M. Atlee和R.Kazman，一种软件架构重建方法，在：WICSA-1，美国德克萨斯州圣安东尼奥，2001年。[10] Hofmeister，C.，R. Nord和D. Soni，股份有限公司、两千[11] IEEE，软件密集型系统体系结构描述的推荐实践，技术报告IEEE-std-1471-2000，IEEE（2000）。[12] 凯默勒角F. 和S.张文，软件演化的一种新的研究方法，北京大学出版社，2000。Eng.25（1999），pp. 493[13] Kruchten，P.，体系结构的4+1视图模型，IEEE Softw.12（1995），pp.42比50[14] Lehman，M. M.，软件演化定律的重新审视，在：第五届欧洲软件过程技术研讨会论文集（1996年），页。108-124[15] Lehman，M. M.和J. F. Ramil，An Approach to the Theory of Software Evolution，in：International Workshop on Principles of Software Evolution IWPSE 2001 ， Vienna ，Austria，2001.180P. Avgeriou等人理论计算机科学电子笔记127（2005）165[16] Lehman ， M. M. 和 J. F. Ramil ， Software Evolution ： Background ，Theory ， Practice ，Information Processing Letters88（2003），pp. 33比44[17] McUmber ， W. E. 和 B. H. C. Cheng ， A general framework for formalizing uml withformallanguages ， in ： Proceedings of the 23rd International Conference on Softwareengineering（2001），pp. 433-442[18] Medvidovic，N.，A. Egyed和P. Gruenbacher，通过耦合架构发现和恢复来阻止架构侵蚀，在：2003年：ICSE'03第二届国际软件需求架构研讨会，波特兰，OR，美国，2003年，第10061比68[19] Medvidovic，N.，A. Egyed和P. Gruenbacher，用中间模型描述软件需求和体系结构，软件和系统建模杂志（SoSyM）（2004）。[20] Medvidovic，N.，D. S. Rosenblum，D. F. Redmiles和J.E. Robbins，在统一建模语言中建模软件架构，ACM Trans.Softw。工程师，Methodol。11（2002），pp. 2-57[21] Medvidovic ， N. 和 R. N. Taylor ， 软 件 体 系 结 构 描 述 语 言 的 分 类 和 比 较 框 架 ， IEEETrans.Softw.2004。Eng.26（2000），pp. 70比93[22] Mens，T.和M. Wermelinger，软件演化的形式基础：研讨会报告，SIGSOFT Softw。Eng.Notes26（2001），pp. 27[23] Mikic-Rakic，M.，N. R. Mehta和N. Medvidovic，自修复系统的建筑风格要求，在：第一国际。2002年，查尔斯顿，自愈系统讲习班。[24] Ng，M. Y.和M. Butler，Towards formalizing UML state diagrams in CSP，in：A. Cerone和P. Lindsay，编辑，第一届IEEE软件工程和形式化方法国际会议，2003年，pp. 138-147[25] OMG，UML 2.0基础设施规范，技术报告ptc/03-09-15，对象管理组（2003）。[26] OMG，UML 2.0超结构最终采用规范，技术报告ptc/03-08-02，对象管理组（2003）。[27] Perry，D. E. ，Dimenionsofsoftwereevolution，in：H. A.MülleranddM. Georges编辑，软件维护国际会议论文集（维多利亚，不列颠哥伦比亚，加拿大; 1994年9月19日至23日），1994年，pp。296-303[28] 佩里，D。E. 和A.L. 吴文，软件体系结构的研究基础，北京：软件工程出版社，1992。[29] 便携式书架网站，http://www.swag.uwaterloo.ca/pbs/。[30] Richters ， M. ， “A Precise Approach to Validating UML Models and OCL Constraints” ，Ph.D. thesis，UniversitétBrememen，FachbeereichMathematikundIn formatik，LogosVerlag，Berlin，BISS Monographs，No. 14（2002）.[31] 罗森伯格，G.，图文法与图变换计算手册：第一卷。基金会，”98-102288-48，世界科学出版公司，股份有限公司、1997.[32] 肖，M。和D. Garlan，“软件架构：对新兴学科的展望”，Prentice Hall。一九九六年。[33] SHriMP网站，http://shrimp.cs.uvic.ca/。[34] 史密斯，J.，M. K. Kokar和K. Baclawsi，UML图的形式化验证：代码生成，在：A。埃文斯河，巴西 - 地 France ， A.Moreira 和 B.Rumpe ， editors ， Practical UML-Based RigorousDevelopment Methods-Workshop of the pUML-Group ， UML 2001 ， Toronto ，Canada，LNIP-7（2001），pp.224-240[35] Tenzer ， J. ， 基 于 转 换 系 统 的 UML 类 图 的 形 式 语 义 ， TechnicalReport2001/09 ，TechnischeUniversit？tBerlin（2001），MasterThesis出版物。P. Avgeriou等人理论计算机科学电子笔记127（2005）165181[36] Tran，J.B.，M. W. Godfrey，E. H. S. Lee和R. C.陈文，开放源代码软件的结构修复，载：第八届国际软件工程师大会（2000）.[37] Tran，J. B.和R. C.霍尔特，正向和反向建筑修复，在：CASCON15-24[38] 图湾，澳-地和M. W.戈弗雷，一个综合的方法来研究建筑的演变，在：国际机场2002年在法国巴黎举办的方案理解讲习班。