基于软件体系结构的版本管理模型的研究

《基于软件体系结构的版本管理模型的研究》由会员分享，可在线阅读，更多相关《基于软件体系结构的版本管理模型的研究（115页珍藏版）》请在装配图网上搜索。

1、第一章 引言 传统的软件配置管理建立在文件版本控制的根底之上，现代大型软件系统的开发要求在更大粒度上进行版本控制。同时，基于软件体系结构的软件开发是当前的开展趋势，也需要适应其特点的版本管理模型的支持。1.1 版本管理模型概述1.1.1 配置管理概念随着软件开发规模的不断增大，一个工程中的中间软件产品的数目也越来越大，中间软件产品之间的关系也越来越复杂，对中间产品的管理也越来越困难，有效的配置管理那么有助于解决这一问题。现在人们逐渐认识到，配置管理是适应软件开发需求的一种非常有效和现实的技术1。配置管理是软件过程的关键要素。它是一种按规那么实施的管理软件开发和维护过程及其软件产品的方法。软件配

2、置管理系统在软件质量管理中也起着重要作用，它不仅是CMM的核心内容之一，是绝大多数软件过程工程和管理过程不可缺少的局部，也是国际标准化组织IS09000质量管理体系的核心内容之一。IEEE定义了软件配置管理SCM的标准2，在这个标准中，SCM应该定义四个主要方面：1配置标识configuration identification：产品、产品结构和产品中组件的标识及其类型；2配置控制configuration control：控制配置项及其组件的演化；3配置状态统计configuration status accounting：记录报告产品状态和变更请求，收集组件统计信息；4审计、审查audit

3、s and reviews：维护产品完整性和一致性。后来，随着异质平台开发、团队协作的出现，配置管理的定义得到进一步的扩展。SCM还包括：5生产manufacture：管理产品组装和构建；6过程管理process management：执行组织的过程、策略和生命周期模型；7团队合作team work：支持开发者间的协作。1.1.2 版本管理概念版本管理是SCM的核心功能3，版本管理的根本任务就是同时管理一个数据元素的多个版本4。版本管理应该具备以下的根本功能：1创立新本版；2通过某种选择机制来访问特定的版本；3对版本添加用户定义的名字或标识；4删除版本；5维护版本间的关系；6修改已存在的版本，

4、这个操作一般是不允许的，至少不能是直接的；7锁定特定版本；8版本合并；9赋给版本状态值和属性值；10允许用户自定义数据对象间的关系。为支持版本管理，需要一个适宜的版本模型。该模型需要定义进行版本化的元素，版本的标识及其组织，版本的查询，版本的创立等等。版本模型可因版本化的元素，版本的组织结构、版本的粒度、面向状态的版本或者面向变更的版本、版本的选择规那么的不同而不同。5中定义了组成版本模型的根本术语，如图1.1所示：图1.1 版本模型根本术语1版本、版本元素、配置项版本v代表着演化元素i的某一个状态。版本v可以通过表达式v = (ps, vs)来表示，ps、vs分别代表版本v在产品空间和版本空

5、间中的状态。版本元素指由版本库维护其演化的元素。配置是指一个复杂对象的某一版本，例如：软件系统的一个配置是由需求文档、软件体系结构、程序源代码的某一版本组成。2增量两个版本之间的差异称之为增量。一个版本通过对基版本使用一组变更来创立新版本就是直接增量存储。而对于内嵌增量和选择增量存储，某一元素的所有的版本是存储在一起的，因此各版本间的共同局部可以共享。内嵌增量方式通过指针指向其片断来组成一个版本，选择增量方式通过可见性表达式来决定一个版本。3版本演化各版本沿着时间轴方向顺序演化称之为修订。这样的演化一般是指修改前一版本的错误。而对于各版本需要并行演化的称之为分支。4版本描述面向状态的版本管理是

6、指只关心版本元素的状态的版本管理。面向状态的版本管理通过修改和分支来描述一个版本。面向变更的版本管理通过对基线版本使用一组变更来描述一个版本。这样就可以跟踪每个版本到底执行了那些变更。面向变更的版本管理有许多的优点：j允许基于规那么的版本查询，而非以枚举的方式浏览版本树；k可以容易的获取各文件的一致性版本，而无须以手工的方式创立；l非常容易比拟两个版本间的差异。但面向变更的版本管理也存在问题：j变更的选项是线性增长的。中选项的数量超过一定值时，用户将面对繁多的选项而无法进行选择；k选项的命名一旦被确定将无法改变，这将导致以后假设有类似的选项将非常难于命名；例如：假设已经存在一个“fill的选项

7、，如果以后需要增加一个新的“fill选项，其命名可能就只能是“newfill；l由于选项是属于布尔型的，其取值只能是TRUE，FALSE和UNSET。那么在某些情况下，会导致大量的选项出现。例如：假设需要管理一个操作系统的属性，那么对每种操作系统都需要增加一个选项DOS，WINDOWS，UNIX等等；m面向变更的版本管理中版本之间没有什么明显的关系，每个版本都可以作为一个分支，缺乏一个版本的演化历史。n选项间并不是独立的，有可能存在多种关系；例如：互斥关系，一组选项中只有一个能取值为TRUE；依赖关系，选项的设置依赖于其他选项的设置，比方我们不会设置SunOS选项，除非我们已经将UNIX选项设

8、置为TRUE；面向状态的版本模型的优点：j可以清楚地看到版本的演化历史；k完整的保存各版本实体的内容；l可以容易的创立基线，配置等等。面向状态的版本模型存在的问题：j每个版本只代表一个状态信息，所以不能确定每个版本具体进行了哪些修改。k对一个版本描述一般来说只包含该版本与其父版本之间的差异，这样的描述既不精确也不全面。l版本之间的差异不能量化，难以实现自由版本查询。m版本选择大体是通过手工的方式进行。5版本空间 分支和修订来组成一个版本图来代表一个版本空间。而网格通过将版本放置入一个n维的空间中来代表一个版本空间，空间中每一维代表了一个需要选择的属性。6版本集 一个版本元素的所有版本定义为集合

9、V。V可以通过精确枚举或隐含版本谓语方式来定义。对于外延版本，V通过枚举方式进行定义：V = v1,vn。基于外延版本的版本管理支持检出之前创立的版本vi，然后再检入新版本vi+1。内沿版本支持灵活的创立一致的版本。对于内延版本，V通过一个逻辑的约束进行定义：V = v|con(v)。所有满足约束con的版本都属于V。通过一个选择谓语evd来选择集合V中的一个特定版本：evd(v)con(v)，然后创立新版本。7版本规那么 内沿版本是建立在版本规那么的根底上。约束定义了合法性规那么，偏好定义了用户优先选择的规那么，默认定义了在没有指定的情况下的规那么。8粒度从用户的角度，版本的粒度可以是组件、

10、完全、产品粒度：对于组件粒度，只有原子组件是在版本管理之下的，每个原子组件都有其自身的版本空间，可以将组件的特定版本组合成配置；对于完全粒度，不仅仅是原子组件，而是所有的组件包括配置都是在版本管理之下的；对于产品粒度，所有组件包括配置都在一个统一的全局的版本空间之下，例如：所有的面向变更的版本模型都采用这种版本粒度。9工作区 为进行开发和维护工作，用户必须在版本库之外建立一个工作区，在工作区可以进行编辑、编译操作。工作区可以通过检出版本库中的数据至文件系统来创立，也可以通过选择谓语evd选择某一版本来提供一个虚拟的工作区。1.2 版本管理模型分类1.2.1 按术语集分类使用1.1节中定义的术语

11、，可以对现有的配置管理工具的版本模型进行分类。图1.2中将13种配置管理工具的版本模型按照版本描述和版本粒度分为四类。该分类从术语的角度进行分类，而不关心每个术语功能的实现程度。每一类中各个配置管理工具按照出现的年代及其继承关系排列。图1.2 基于术语的分类1面向状态-组件粒度版本模型SCCS6是一个简单的管理文本文件的配置管理工具，版本通过版本树的形式进行存储。用户将一个版本检出到工作区中，当完成变更任务后，他将修改后的版本检入到SCCS版本库中。在SCCS中，文件的组织结构是不可见的。RCS7继承于SCCS，在许多方面进行了改良。RCS使用直接增量进行存储，主分支上的最新版本可以直接访问，

12、其他版本通过向后和向前增量进行创立。此外，RCS提供一组内嵌的属性集用以标记版本状态和助记名，助记名可以用来标记一个由所有组件的一致性版本组成的配置。RCS还能简单的支持内延版本检出操作中可以包含属性规那么。但操作时RCS还是必须要先选择产品结构，并且不能对产品结构的版本进行建模。2面向状态-完全粒度版本模型DSEE8整合了Make和SCCS/RCS的功能，支持基于规那么的配置创立和网络的并行开发。DSEE使用一个系统模型来描述配置，系统模型描述了软件系统中的对象及其它们之间的关系。系统模型中不包含各实体的版本，它们是通过配置规那么来进行选择的。用户首先选择系统模型中的产品结构，然后再通过配置

13、规那么选择进行版本的绑定。ClearCase9继承于DSEE，它不仅对文件进行版本化，也对目录进行版本化，所有版本对象都统一称为元素。与DSEE不同，ClearCase像访问其他元素一样访问系统模型。3面向变更-产品粒度版本模型Aide-de-Camp10通过一组变更集和基线来描述产品的版本。全局变更可以同时影响多个文件。在Aide-de-Camp中，变更集是完全顺序的，如果变更集c1先于变更集c2创立。那么某一个产品的版本如果包含c2，那么首先必须先包含c1。每一个变更集可以看作一个开关：或者开或者关。但Aide-de-Camp不支持关系。在COV4中，版本数据库由一组片断组成，而每个片段都

14、有一个逻辑的表达式称之为可见性visibility。可见性是一组全局的布尔选项option，这组布尔选项组成了n-维的版本网格。COV通过选择choice和目标ambition规那么来进行版本的读取和修改，选择中指定了所要选择版本的选项绑定，而目标通过选项绑定决定了修改会影响到的版本空间。4面向变更-完全粒度版本模型 Asgard11实现在ClearCase之上，在版本图之上提供了面向变更的版本管理。每一个组件的版本通过活动activity进行标记，工作区通过基线和一组活动进行定义。从上面的比拟可以看出，版本模型从面向状态向面向状态和面向变更相结合的方向开展；从面向组件的粒度向面向完全的粒度方

15、向开展。同时还可以看出虽然很多的版本管理模型实现的功能是相似的，但实现的程度却相差非常之大。因此在本文中实现的版本管理模型应该从实现功能的通行性方面和实现的程度方面来增强改良。1.2.2 按概念集分类还可以从版本管理模型提供的概念集，将版本管理模型分为以下四类12：检入/检出模式CheckIn/CheckOut Model这个模式提供单系统组件的版本管理。这样版本管理模型有两个独立的工具组成：版本库工具和创立工具。版本库工具负责存储文件的各个版本以及提供创立新版本的机制。创立工具提供一个文件描述用于生成应用及自动生成导出文件。在版本库中的文件不能直接访问，只能通过检出操作，检出后的文件被保存至

16、文件系统，从而能对其进行读写。版本库的并发控制机制可以协调多用户的读写活动。文件系统是用户真正的工作区。版本库工具没有提供对工作区的支持，而是依赖于文件系统来提供用户一个互斥的写访问工作区。用户按照寻常方式来使用创立工具等工具，文件的版本对于这些工具来说是透明的。创立工具通过解释文件系统中的文件描述来创立一个系统。这些文件描述可以存储在仓库中并像一般文件那样进行版本化。RCS13就属于这种类型的版本管理模型。组合模式Composition Model组合模式通过版本选择来创立系统配置，组合模型是检入/检出模式的开展，它同样采用了版本库和工作区的概念，使用文件锁来进行并发控制。其主要的改良是支持

17、创立配置，维护配置的历史。在该模式中，配置作为版本管理模型的实体。一个配置由一个系统模型和版本选择规那么组成。系统模型列出了组成系统所需的所有组件，版本选择规那么指明每个组件的版本。组合和选择的过程可以通过一个AND/OR图来表示。首先将组件组合成一个配置AND节点，然后为每个元素选择适宜的版本OR节点，当然这个元素还可以是一个配置。DSEE14是属于这种类型的版本管理模型。长事务模式Long Transaction Model长事务模式将系统的演化描述为一系列的配置项版本和一系列并发的活动。系统的演化过程一系列原子变更的过程，通过开发者来协调系统的这些变更。开发者对配置进行操作而不是对单个组

18、件。选择一个配置作为变更的起点，对该配置所进行的修改外界是看不到的直到该事务提交。多个事务间通过并发控制进行协调。一系列变更的结果是一组顺序的配置版本，称之为开发路径。配置版本可以从已有的开发路径分支。在长事务模型中，开发者首先选择系统配置的一个版本，然后再关注系统的结构。组件的版本隐含的由配置决定。长事务由两个根本的概念组成：工作区和并发控制模式。工作区取代了文件系统，支持开发者在工作区内执行变更活动序列。通过将工作区中的配置进行提交，从而使得变更变得可见，同时这个配置将会添加到最初的配置版本之后。此时一个事务结束。NSE15是属于这种类型的版本管理模型。变更集模式Change Set Mo

19、del变更集模式关注于版本的逻辑变更，对于文件而言，变更集代表两个文件版本间的差异。对于配置而言，变更集代表两个配置间的差异。在这种模式中，配置由基线和变更集共同组成。如对系统发布版本的补丁程序就可以看成是一种变更集。变更集用来对逻辑变更进行跟踪，通过在逻辑变更的根底上定义新的配置。变更集模式本身不提供锁机制来进行并发控制，而是通常与检入/检出模式共同使用。Aide-De-Camp16就是属于这种类型的配置管理系统。 但以这种方式进行的分类存在一个缺点就是各种分类不是正交的，其中的某一分类可能同时也属于另一分类。本文中的版本管理模型的目标应该在概念集上包含以上各种分类，因此在版本模型的设计上应

20、该从不同的层次上对以上的概念集进行支持。1.3 软件体系结构概述1.3.1 软件复用复用是成熟的工程领域的一个根本特征，例如，土木工程、化学工程、计算机硬件工程等，通过大量复用经过实践检验的系统体系结构和标准化的构件，使得对于常规的设计问题都可以直接利用现成的解决方案，防止了系统开发时不断地重复设计，从而可以大幅度地降低开发本钱、提高生产效率和产品质量。同样，复用也是软件工程走向成熟的必由之路,将为软件危机的解决提供一条现实可行的途径。基于构件的软件复用作为一种提高软件生产率和软件质量的有效途径，是近几年软件工程界研究的重点之一，被认为是继面向对象方法之后的一个新的技术热潮17。通过基于构件的

21、软件复用，在应用系统开发中可以充分地利用已有的构件，消除了在分析、设计、编码、测试等方面的许多重复劳动，可以提高软件开发的效率；同时，通过复用高质量的已有的构件，防止了重新开发可能引入的错误，可以提高软件的质量。因此，基于构件的软件复用可以大大降低软件开发的费用，并显著地提高生产率和产品质量。与软件复用相关的两个根本开发活动是面向复用的构件开发和基于构件复用的开发，前者是生产可复用构件的过程，后者是利用现有的可复用构件生产新系统的过程。可复用构件为有方案地、系统地进行复用提供了手段，是实现软件复用的基石。软件复用最终表达为在软件体系结构的指导下对可复用构件的组装。1.3.2 软件体系结构概念自

22、20世纪90年代初期开始，软件体系结构(software architecture，简称SA)的研究受到了广泛的关注和重视，并被认为将会在软件开发中发挥十分重要的作用。它将大型软件系统的总体结构作为研究的对象，认为系统中的计算元素和它们之间交互的高层组织是系统设计的一个关键方面18。其研究和实践旨在将一个系统的体系结构显式化,以在高抽象层次处理诸如全局组织和控制结构、功能到计算元素的分配、计算元素间的高层交互等设计问题19。SA是对软件总体结构的描述，即对其构件和构件间交互的高层组织的描述18。它作为一种高层的设计，对系统开发发挥着重要的影响，基于构件的SA的设计已成为软件系统设计中的核心问题

23、。一个好的SA设计成为大型软件系统成功的重要因素。SA的最重要的一个奉献是将构件之间的交互显式的表示为连接器(Connector)，并将连接器视为和构件同等重要的一阶实体。构件通过接口定义了同外界的信息传递以及所承当的系统责任，构件接口包括了构件同周围环境的全部交互内容，也是构件同外界唯一的交互途径。除此之外，环境不应对构件作任何其他与接口无关的假设，例如实现细节等。连接器在构件请求接口与其他构件提供的接口之间搭建一座桥梁，起到了代理作用。在SA的设计过程中，人们针对不同的需求采用了不同的软件构架风格。体系结构风格定义了一系列系统的结构组织的模式20，它是对一类具有相似结构的系统体系结构的抽象

24、。体系结构风格既定义了构件及连接方式的各种属性, 又规定了它们的组合规那么和限制18。近十年中人们设计了许多SA风格：1管道-过滤器风格每个过滤器都有输入端口和输出端口，从输入端口读入数据流，进行局部的数据变换(计算或处理) 以后，在输出端口输出新生成的数据；管道那么负责数据的传输，把数据从一个过滤器的输出端口传送到另一个过滤器的输入端口。这个过程是顺序渐增的过程，而且过滤器必需是相互独立的实体。这里的过滤器是指体系结构中的构件，管道是体系结构中的连接器。2面向抽象和面向对象组织风格这种风格中，数据表示和与之相连的原语操作被封装在一个抽象数据类型或对象中。这种风格的构件是对象，也可称为抽象数据

25、类型的实例。对象通过函数和过程调用进行交互。这种风格可以细分为三种风格：j对象连接式风格：在这种类型的体系结构中,构件的接口只定义了其对外提供的效劳，而没有定义构件对外要求的效劳，其中以面向对象中的对象接口为典型代表。这种接口定义的非对称性使得构件在集成时，构件对外要求的效劳被隐藏在代码的实现细节中，即构件之间的连接关系无法直接在接口处定义，只能是从一个构件的实现到另一个构件的接口。k接口连接式风格：在这种类型的体系结构中，构件的接口不但定义了其对外提供的功能，而且定义了其要求的外部功能，从而显式地表达了构件对环境的依赖，提高了构件接口规约的表达能力。构件的接口定义了所有对外交互的信息，构件在

26、实现时不是直接使用其他构件提供的功能，而是使用它在接口处定义的对外要求的功能。构件之间的连接是在所要求的功能和所提供的功能之间进行匹配，因此，通过接口就可以定义系统中构件之间的所有连接。l插头插座式体系风格：当接口定义的功能数量很大时，带来了规模上的问题。在这种体系结构风格中，通过把这样的彼此间关系紧密的功能(包括提供的功能和要求的功能)组织成组，并封装为效劳，使得接口中直接包含的内容减少，降低了接口中功能的规模。3基于事件的隐式调用风格这种风格与面向对象结构风格类似，不同的是，在这种风格中，部件之间的交互不是直接调用，而是通过一种称之为“隐式调用(implicit invocation) 的

27、方式来实现的，每个部件提供假设干进程及它感兴趣的事件，并把每个事件与一个过程联系在一起，当某个部件产生一个事件时，假设其它部件定义了这个事件，那么与该事件联系在一起的过程将被自动调用，从而间接地完成了过程的调用。4分层系统风格 一个分层系统就是把整个系统组织成层次结构，每一层都提供假设干效劳给上一层使用，并且它也使用其下一层所提供的效劳。可以将这种风格细分为两种：j基于层次消息总线的结构风格：消息总线是系统的连接器，负责消息的分派、传递和过滤以及处理结果的返回。各个构件挂接在消息总线上，向总线登记感兴趣的消息类型，构件根据需要发出消息，由消息总线负责把该消息分配到系统中所有对此消息感兴趣的构件

28、，消息是构件之间通讯的唯一方式。构件接收到消息后，根据自身状态对消息进行响应，并通过总线返回处理结果。kC2风格：C2构架中的根本元素是构件、连接器。每个构件定义有一个顶端接口和一个底端接口，构件通过这两个接口连接到构架中，这使得构架中构件的增加、删除、重组更为简单方便。每个连接器也定义有顶端接口和底端接口，但接口的数量与连接在其上的构件和连接器的数量有关，这也有利于实现在运行时的动态绑定。构件之间不存在直接的通信手段，构架中各元素构件、连接器之间的通信只有通过连接器传递消息来实现。处于低层的构件向高层的构件发出效劳请求消息，消息经由连接器送到相应的构件。各种不同的SA风格的设计均是基于不同类

29、型的连接器20。文献21中，连接器被划分成8种类型：过程调用类型(Process Call)、事件类型(Event)、流类型(Stream)、分布者类型(Distributor)、数据接入类型(Data Access)、仲裁者类型(Arbitrator)、适配器类型(Adaptor)、联接类型(Linkage)。文献22中，非功能属性(如保密性，效劳质量等)被认为是连接器描述中的重要组成局部。1.4 软件体系结构描述语言1.4.1 软件体系结构描述语言概述SA研究的主要成果表现为体系结构描述语言(architecture description language,简称ADL)。从构件组装的角度

30、来看，ADL可以视为对构件描述语言(CDL)的进一步扩展。构件描述语言的根本思想是将构件看成是一个黑盒，通过描述构件接口的语法和语义，使得复用者不必过多地涉及构件代码细节，就可以在构件描述这一抽象层次之上进行构件组装。而ADL除了描述构件接口的语法和语义之外，还负责描述：系统中包括的构件和连接子以及它们之间的交互关系、构件的非功能类性质以及构件间协议，从而为构件组装提供了更为有力的支持。体系结构描述语言(ADL) 是为软件系统的体系结构提供具体的语法和概念框架的一种形式化符号。迄今为止，研究者已经从不同的角度出发，针对不同的目标，提出了各种通用的和专用的ADL：1Rapide2324：一种事件

31、驱动的ADL，它以体系结构定义作为开发框架，支持基于构件的开发。该语言提供了建模、分析、仿真和代码生成的能力，但是没有将连接器显式化为一阶实体。2Wright25：具有代表性的ADL之一。其主要特点是将通信顺序进程26Communicating Sequential Processes，简称CSP用于不同风格软件体系结构的描述，从而完成对体系结构描述的某些形式化推理(包括相容性检查和死锁检查等)。3UniCon27：将一组预定义的连接器映射到具体实现，从而提供了从模块到可执行代码、从体系结构设计生成应用的可能性。但是目前它只支持一组已选定的连接器，存在一定的局限。4Aesop28：支持精确的编

32、码并能够定义一个新的体系结构的风格，然后通过加上某些约束和利用它们的所有性质来使用这个风格。5xArch29：一种基于XML的ADL。它使用XML 定义了描述体系结构的核心元素,可以作为其他更高级的基于XML的ADL的根底。也可以用做体系结构描述的交换机制。6ACME30：支持ADL之间映射及工具集成的体系结构互交换语言。其目标是作为体系结构设计的一个共同的互交换格式,将现有的各种ADL在这个框架下统一起来。1.4.2 Wright构架描述语言Wright ADL是基于CSP的形式化构架描述语言。CSP26中使用的根本记号如下所示：1进程process：使用一系列事件序列来表示一个进程实体，例

33、如上文中提到的各个role、port均是一个进程。STOP是一个特殊进程，表示什么事都不做的进程。2字母表alphabet：进程所能执行的事件的总和；特殊事件：事件“代表进程成功结束。进程P的字母表表示为aP。3前缀prefix：设有一事件为x，有一进程为P，那么另一进程先执行事件x，然后按照进程P的说明进行动作；用xP表示。4非确定性选择non-deterministic choice：进程A或者按照P动作，或者按照Q动作，而这种选择是进程自发做出的。用PQ表示。5确定性选择deterministic choice：进程A或者按照P动作，或者按照Q动作，而这种选择是环境做出的。用PQ表示。6

34、通信communication：使用二元对c.v来描述的一个事件，c是发生通信的通道channel的名字，v是通道传递的消息message。使用“？表示接受消息，“！表示发送消息。7屏蔽concealment：设C是进程P需要屏蔽掉的事件的集合，用PC表示，它代表了一个似P动作的进程，只是在C中的任何事件的发生都被屏蔽掉了。8并发parallel：进程P和Q的并发表示为P|Q，它代表P，Q字母表中共有的事件需要同步执行，非共有事件不需要同步。9进程标记process labeling：标记为l的进程P表示为l:P。那么进程中所有的事件也标记上与其所属进程相同的名字。在进程表达式中的优先级高于，

35、|操作符。所以efP|gQ=efP|gQ。对于其他操作符，未定义显示的优先级，所以在使用时用括号来确定优先级。有了CSP的根本记号，我们就可以对客观事物描述其动态行为，从而为推理、验证事物行为提供了强有力的工具。如图1.3所示，Wright ADL描述的软件体系结构一共由三局部组成：1构件及连接器类型定义：构件类型由一组端口port描述和构件功能描述组成，每一个端口是构件与其他构件交互的逻辑单位；连接器类型由一组角色role和一个粘接器组成，角色描述了连接器所期待构件的行为，粘接器描述了各角色行为之间的同步。图1.3 Wright构架描述语言2一组构件和连接器的实例定义。3构件实例与连接器实例

36、间交互定义，将构件实例的端口绑定到连接器实例的角色上，从而完成构件间的交互。图1.4 仓库风格的Wright ADL描述图1.5 管道过滤器风格的Wright ADL描述Wright ADL可以用来描述各种软件体系风格的软件构架。如图1.4所示的仓库风格，图1.5所示的管道过滤器风格。1.5 相关工作配置管理中的版本管理模型一直是软件工程界研究的热点。在31中提出了版本管理模型的根本概念：软件对象、版本图、系统创立、基于AND/OR图的版本选择，并试图统一版本模型术语。之后版本模型不仅仅支持保存单文件的版本，而且支持创立一致性的配置32。随着不同版本模型的不断出现，12中根据版本模型概念集将版

37、本管理模型分为四类：检入/检出模型、组合模型、长事务模型、变更集模型，但是这四种分类结果并不是正交的，一般的版本模型包含一个或多个以上的模型。在33中将版本管理模型分为以下几个方面：版本集的组织、动态配置机制、层次组合、版本族机制、变更传播、对象共享。但这些版本管理模型缺乏一个高层视图的支持，虽然在版本模型中可以用户自定义配置，但所有的配置按照何种规格以及以何种规那么进行组织在这些版本模型中都没有讨论。随着软件工程技术的不断开展，新技术不断的涌现，人们将配置管理技术同其他技术结合，从而开展出新的版本管理模型。软件过程建模技术343536同传统版本管理模型结合产生支持过程建模的版本管理模型373

38、8，该版本模型中定义的产品空间被扩展用以包含过程建模，同时须对产品空间与过程建模间的交互进行设计。将基于构件的软件开发技术同传统的版本管理模型结合，开展为基于构件的软件版本管理模型3940。但当前的基于构件的版本管理模型主要关心的是原代码模块间的依赖关系，缺乏管理软件对象间关系的能力。同时基于构件的开发没有在一个软件构架的支持下进行。1.5 存在的问题随着CBSE的开展，当前CBSE的版本管理模型中存在如下问题：未能与CBSE结合，对基于构件开发的支持非常有限，很多系统只是简单的将构件作为一系列文件的集合，而对于构件拥有的语义、构件间的依赖关系、构件中各组成局部的依赖关系的定义非常缺乏，未有支

39、持SA的版本管理模型；在粒度管理方面只是通过简单的组合来创立一个版本管理的粒度，未能按照用户的自定义来定制版本管理的粒度；未能将版本模型和数据模型分开，所有功能模块交错在一起。为此，本文提出一个分层的基于构架的版本管理模型SAVM，在版本模型层上，同时支持面向状态和面向变更的版本操作，以统一的方式对待所有的数据元素，从而实现了一个通用的版本引擎；在版本引擎之上，将数据模型层分为两个子层，一个子层实现数据元素及数据元素间关系的组合，一个子层负责基于软件体系结构的数据模型，使得版本管理模型能够支持基于软件体系结构的开发。在数据模型层之上进行事务管理和过程管理，从而为软件组织提供了并行开发的控制和支

40、持软件开发模型的支持。第二章 SAVM的体系结构版本管理模型SAVM针对上面的这些问题提出了解决方法，它是一个主要实现了版本管理、数据管理、过程管理、并发控制以及支持基于软件体系结构面向构件的软件开发方法等功能，从而实现了比拟全面的软件版本管理模型。2.1 SAVM设计的根本要求作为一个基于软件体系结构的版本管理模型应该具备两个方面的功能：1通用版本管理模型所拥有的功能；2支持基于软件体系结构的开发所拥有的功能。因此在设计该模型时，需对这两方面功能的要求进行定义。2.1.1 根本要求根据1.1.2节中对版本管理模型术语的一个分类，可以对SAVM所要满足的要求定义如下：1一般性要求：SAVM必须

41、满足版本空间和产品空间的根本要求。用户可以在产品空间中自由的设定需进行版本管理的版本元素；也可以自由的设定版本元素的版本空间。从而为用户提供一个足够通用的版本引擎，使得用户可以自定义的将其转化为任何一种特定的版本模型。2增量的选择要求：在增量的选择上，需要对存储效率和执行效率进行考量。由于这属于物理实现层面上，因此SAVM版本模型不对此进行设计。3版本演化的要求：版本的演化应该同时支持分支和修订，而且分支和修订对于不同粒度的版本元素应该按照一个统一的方式进行，即在版本空间中，应该统一对待所有的数据元素。4版本描述的要求：需要同时支持面向状态和面向变更的版本管理方式。面向状态和面向变更这两种方式

42、间应该是正交的，即它们之间不存在互相的关系。5版本空间表示的要求：对于面向变更的版本管理适用于使用n维网格进行表示，而面向状态的版本管理适合使用版本图来进行描述，因此需要将这两种描述方式有机的结合在一起。6版本集定义的要求：面向状态的版本管理自然的支持外延版本，而面向变更的版本管理自然的支持内延版本；但面向状态的版本管理应该同时能支持内延版本，而面向变更的版本管理也能支持外延版本。7版本规那么的要求：对于内延版本而言，需要有版本规那么的支持。而对于外延版本而言，使用版本规那么可以定义基线、配置等概念。8选择粒度的要求：版本模型应该能够提供产品、各组成成分的选择粒度，以满足用户在不同时刻的不同要

43、求。9工作区管理的要求：工作区应该同外部工具版本在一起，从而实现版本模型与工具间的集成。2.1.2 基于SA的要求SAVM是支持基于软件体系结构开发的版本管理模型，因此在版本模型中需要对SA的根本概念提供支持，并且支持基于构件的软件开发方法。版本模型应满足的要求如下：1支持构件定义：构件包括构件接口和构件实体两局部。同时构件接口同构件实体间存在着互相依赖关系，一方的改变可能导致另一方的改变。而且构件接口中应该包含语义信息用以描述构件的行为，接口类型可以根据SA风格的不同而不同。构件实体可以是一组相关的目录、文件，文件间存在着依赖关系、包含关系等多种关系。2支持连接器定义：连接器包括角色和粘接器

44、两局部组成。连接器作为构件实体间的连接代理，连接器的角色和构件的端口应该满足相容的关系25。角色和端口都应该包含语义信息。3支持SA定义：SA由构件、连接器以及它们之间的连接关系组成。版本管理模型不仅需要将构件、连接器作为实体来对待，而且需要将连接关系作为实体来看待。SA是版本管理模型中的最大粒度，用户可以根据不同的需求按照各种不同的粒度来查看整个SA。这里不仅需要设计构件、连接器、SA版本演化规那么，而且需对它们之间在演化过程中的相互影响进行定义。4支持基于软件体系结构的软件开发方法：17中提出了一个基于体系结构、面向构件的软件开发方法，方法中定义了一个开发的流程。版本管理模型中需要设计一个

45、新型的过程管理定义语言对所有通用的软件开发模型进行定义，从而支持基于构件的软件开发的过程管理。5支持基于软件体系结构的并行开发：当前的软件开发的规模已经不是仅仅靠一个人就能完成的了的，需要一个团队合作完成。版本管理模型需要提供并发控制机制和用户权限管理功能。以上SA中的所有元素将通过Wright描述语言定义，版本模型应该提供将描述语言自动的转化为适合版本管理模型管理的实体的能力，同时不应丧失语言中描述的任何信息。2.2 SAVM结构设计根据2.1节中定义的SAVM的根本要求，我们可以看到SAVM版本管理模型涉及版本空间、产品空间和过程管理。首先遇到的问题是如何将版本空间、产品空间、过程管理这些

46、概念有机的组合在一起来提供一个高效、通用的版本管理模型。我们可以正交的对待版本、产品和过程，从而实现一个分层的版本管理模型。这样有利于对版本模型的修改和扩展，当发生修改时也可以使修改范围定位的足够小；同时当版本模型需要进行扩展功能时，非常容易定位增加功能所处的层次，只需扩展该层就可实现整体功能的扩展。为决定一个系统的构架，并按分层的方式把以上三个概念组合起来，SAVM版本模型必须对以下几个问题做出决定：1数据模型和版本模型之间的关系这决定了产品空间与版本空间之间的关系，数据模型定义了产品数据的根本概念如构架、构件、简单文件。版本模型定义了版本标识及其组织，同时还定义了查询和创立一个新版本的操作

47、等等。数据模型和版本模型的关系可以有以下几种方式：j版本模型位于数据模型之上；k版本模型和数据模型结合在一起；l数据模型位于版本模型之上。SAVM版本模型是一个层次模型，因此应该将版本模型和数据模型分开放置在不同的层。同时根据用户可以选择不同粒度的版本，因此数据模型应该位于版本模型之上。2选择一个增量表示 增量可以分为三类：直接增量、内嵌增量、选择增量。作为一个物理层面上的是实现，应当考虑存储效率和执行效率问题。SAVM只是一个基于软件体系结构的版本管理模型原型，因此不对增量存储进行定义。3定义根本的版本概念 版本模型中需要定义一个根本的概念，高层的其它概念必须可以通过这个根本的概念组合而成。

48、为使版本模型足够的通用，所有在版本模型中的元素都是原子的，称之为片段fragment。片段之间可以在数据模型层组合形成数据元素，而对片段的管理是既允许进行面向状态的版本管理也允许面向变更的版本管理。4外延版本和内延版本的关系大局部面向状态的版本管理具有外延版本的特点；而大局部面向变更的版本管理具有内延版本的特点。内延版本和外延版本的关系可以分为三种：j内延版本位于外延版本之上；k外延版本位于内延版本之上；l外延版本正交与内延版本。为满足通用型，用户可以选择面向状态的版本管理也可以选择面向变更的版本管理，或者兼而有之。因此SAVM提供外延版本与外延版本正交。5定义数据模型根本对象集数据模型中需要

49、定义一个根本概念集，同时允许扩充该概念集。例如在软件对象的生命周期中，软件对象如需求定义、设计、构件、文档、测试数据等等均可定义为根本概念。其它概念必须可以通过这个根本的概念组合而成，例如构架就由构件和连接器组合而成。数据模型中的所有元素均可由版本模型中的片段组成。对数据模型层进行分解：底层为基于ER模型的数据模型，定义所有的数据元素；高层为基于SA的数据模型。6定义并发控制 SAVM中通过事务管理来进行并发控制，定义了一系列的根本变更传播规那么来控制不同用户间的一致性工作，同时针对每种数据类型可以增加特有的传播规那么。SAVM没有采用锁机制，因此不会产生死锁或者特定版本被锁定除非用户自己锁定

50、。当发生冲突时，SAVM可以选择多种解决方式进行冲突解决。7定义过程管理模式过程管理不仅支持基于软件体系结构的过程模型，同时还应该支持允许用户自定义过程模型。SAVM中提供一个过程管理模式，将过程模型中的一系列阶段和活动使用过程模式进行分解，将每一特定的阶段同相关的软件产品关联，以活动来驱动整个软件过程的执行。根据以上的决定，可以得出SAVM的分层版本管理模型的总体结构，如图2.1所示：这些层可以整合成两大类，即版本引擎和版本管理仓库。1版本引擎版本引擎提供根本的版本功能而不包含任何的产品空间。这仅仅假定版本元素的元素标识是由数据模型层提供。版本模型与数据模型正交，这意味着版本引擎可以应用于任

51、何数据模型。对于一个对象元素，都有一组不同的片段，每个片段都包含一个对象标识和一个可见性visibility。对象标识说明该片断所属的对象元素；可见性即数据元素的版本标识，是一个由选项option组成的逻辑表达式，每个选项的值可以是TRUE，FALSE，UNSET。全部选项组成了一个面向变更的版本空间。在每一个可见性下，都存在一个面向状态的版本空间。因此版本引擎既提供了面向变更的版本管理也可以提供面向状态的版本管理。图2.1 SAVM分层版本管理模型版本模型由面向变更的版本模型和面向状态的版本模型组成。面向变更的版本模型和面向状态的版本模型有机的结合在一起，统一的定义了修订、分支、版本图和网格

52、、外延版本和内延版本等版本模型中的根本术语。2版本管理仓库在版本引擎之上，版本管理仓库提供了数据模型层、事务模型层、过程模型层。数据模型层由两个子层组成：1基于ER模型的数据模型；2基于SA的数据模型。基于ER模型的数据模型负责提供根本的数据模型给它以上的各层，同时屏蔽它以下的各层。在这一层上，客户端完成查询和更新操作，但他却感受不到数据元素是经过版本标识的。基于SA的数据模型负责提供软件体系结构及其语义信息。事务层提供了协作、并发控制、长事务模型，所有的软件开发或维护的活动都包含在某一个事务中。每一个事务被限制在产品空间和版本空间的子集上。过程模型负责定义用户开发的一个过程。工作区支持那么为

53、用户的操作提供接口。SAVM版本管理仓库由两个局部组成：一个是用于保存片段集的内容数据库，一个是包含选项定义、全局版本规那么、版本图的元数据库。元数据库包括两个局部：j选项定义：选项可以表示一个变更、一个特定的属性等等。n个选项可以组成一个n维的网格。选项使用名字进行过行标识，例如：GUI：设置成TRUE表示程序版本有一个图形的用户界面；Linux：设置成TRUE表示程序版本运行在Linux操作系统上；SpeedOpt：表示版本是否经过优化。k全局版本规那么：根据选项的取值，可得n个选项可有3n种组合，但只有其中一些可以认为是合法的。为了管理这些复杂的版本选择，我们需要一个全局的版本规那么库。

54、而且，可以将用户描述的高层版本描述基于用户自身偏好会自动转化为低层的版本描述基于选项的描述。全局版本规那么可以分为五类：一般性约束：定义了选项间的依赖关系，即只有当某一选项设置为TRUE时，另一选项才能进行设置。选项族：族内的选项必须互斥，即族内之多一个选项的值可以设置为TRUE。合法性检查：有效性表达了某些版本是被锁定的，从而有效的支持了基线的存在。偏爱：允许用户设定自己的偏好。默认：用于解决二义性的选择。l版本图：每一个可见性下都对应着一个面向状态的版本空间。版本图中保存着每个版本元素在相同可见性下的版本演化历史。2.3 SAVM总结可以看出SAVM模型具有以下的优点：1是在统一的框架中定

55、义的版本模型，因此SAVM模型可以使不同版本模型之间的比拟更加容易；2SAVM是建立在少量根本概念之上，通过这些根本的概念可以表述各种类型的版本模型；3版本引擎作为一个可复用的核心构件来构建版本管理模型；4统一版本模型的一个重要特点就是版本模型和数据模型正交；数据模型用于代表软件元素和他们之间的关系；5版本引擎支持基于规那么的软件配置项的创立。6非常方便的进行扩展，支持基于软件体系结构的开发以及过程管理。SAVM的总体结构中应该实现以下几个方面的功能：1类型和结构SAVM根本功能就是提供存储和管理配置的能力。构件可以是任何类型的软件对象，例如：源文件、对象文件，设计文档、测试用例。SAVM必须

56、提供一个通用的类型系统，这样子才可以对不同的构件进行区分并能完成：j控制配置的组合；k对某种类型的对象嵌入一些语义知识；l对于不同类型的对象使用不同的语义和管理规那么；m类型系统应该可以扩展，以便参加用户定义的类型和描述。同时应该提供某种方式来将构件组合成更大的结构。2持久性数据需要持久的存储以便进行管理。3构件标识j对象标识OID是由系统提供的，唯一且不变的键值。该标识独立于对象的其他属性。k对象标识是SAVM的根本要求。但同时还存在面向值系统，在这种模型中，对象通过值来进行标识，而该值既不唯一也不恒不变。4变更控制软件配置不是一个静态元素；变更会贯穿其整个生命周期，不仅仅在初期的开发阶段，

57、更重要的是在后期的维护和再开发。SAVM一个很重要方面是管理这样的变更。它包括两个方面：记录执行的变更和执行变更。j变更记录与传统的数据库不同，变更记录不仅仅是执行这些变更那么简单。在SCM中，每一个数据元素不仅仅只有一个版本，但一个变更被执行时，我们不是去完全替换老版本，而是同时保存未变更和变更的版本。这样子就可以方便的取回先前的版本。k变更处理过程控制变更的处理过程，它至少包括以下几个方面：生成一个变更请求；存储变更请求并对其进行作用：将正式的变更请求记录到数据库中，并寻找出受该变更影响的构件及相应的负责人；处理变更请求的规那么依赖于当前产品的状态：产品在生命周期的所处的阶段及所影响到软件

58、对象的类型；存在某种方式来确认相应变更的负责人；变更处理后的结果应该和变更请求链接在一起以便可以跟踪；应该有相应的方针来指导测试、证实、分布完成后的变更；访问控制规那么保证只有经核准的人才能对相应得软件对象进行修改。5一致性控制软件开发者所面临的一个问题是通过适宜的准那么来保证新创立的配置的一致性。简单的说，我们可以说一个配置是一致性的如果它的构件能恰到好处的组合在一起，例如：一个接口和实现该接口的功能就是一致的。当用户请求一个配置时，系统应该保证其一致性。因此一致性与版本问题是紧密联系在一起的。在技术上，一致性与事务的关系非常密切。6创立当一个完整的软件系统需要交付、内部使用或者测试时，SA

59、VM应该能从所有必须的构件中创立它。在创立过程中，我们不仅仅要收集所需的构件，还需要通过编译、链接来生成一些构件。因此SAVM应该具备以下功能：j自动的寻找所有必须的构件，并且自动调用所需的工具编译器、链接器等来完成创立工作。k以一种高效的方式来创立配置。l保证根据用户提供的参数来创立配置。7状态统计我们应该为版本元素的不同版本指定一个状态，这样子可以控制版本元素的演化过程。对于每一个状态值，可能会有一定的规那么与之绑定。例如：用户可以拿到的构件必须是“经确认状态。我们可以将构件的状态修改为“已交付来记录这个事实。8长事务使用长事务的概念来封装一个长期的活动天、星期甚至年。软件系统的升级可能会

60、花费很长一段时间，并包含大量的变更，因此我们须将它定义成一个逻辑实体。9协作支持与协作相关的一些技术问题：j合作协议的描述。每一个事务人对变更及其传播都有不同的需求和参数要求。k在不同事务间变更的传播。l合并冲突的变更。10过程建模和管理定义软件过程活动及其结构的框架。允许用户自定义的设定软件过程模型，过程模型可以在版本演化的过程中不断的演化。以上的功能既可以说是SAVM的功能要求，也可以说是一般的版本管理模型的根本功能要求，在后面的章节中我们会对具体每个功能的实现进行详细的设计，以使每个根本功能具有很好的通用性和可扩展性。第三章 版本模型层版本引擎作为一个可复用的核心构件来构建版本管理模型，

61、版本模型需要记录和存储各个版本，维持不同对象版本间的关系，根据规那么描述创立新版本，必要时进行合并。在版本模型层上，版本模型需要定义修订、分支、面向状态和面向变更版本、版本图和网格，外延版本和内延版本。SAVM结合面向状态版本模型和面向变更版本模型的优点，提供面向状态和面状变更两种版本视图，支持版本的根本操作：修订、分支、合并等等；同时使用版本图和网格来分别存储状态空间下的版本和变更空间下的版本。从而在SAVM的版本模型层实现了一个统一的版本模型。3.1 版本模型的根本要求3.1.1 功能要求版本管理是同时管理一个数据元素的多个版本。SAVM的版本模型应该和其它所有版本模型一样应该具备版本控制

62、的根本功能：1按某种机制创立新版本；2通过某种选择机制来访问特定的版本；3对版本添加用户定义的名字或标识；4删除版本，对于面向状态的版本模型，这个操作一般是不允许的，至少不能是直接的；5维护特定版本间的关系，如修订或分支；6修改已存在的版本，这个操作一般是不允许的，至少不能是直接的；7锁定特定版本；8版本合并；9创立基线；10将状态值和属性赋给版本；11允许用户自定义对象间的关系，如AND/OR模型。3.1.2 修订与分支根据版本演化的规律，可以将版本模型中各版本的关系分为两种：1修订：对前一个版本进行修改而产生出一个新的版本。修订是沿着时间轴顺序增加的。创立一个新版本最简单和最古老的方法就是

63、对最近的一个版本进行修订。从前一个版本到另一个版本的改变可能有不同的意思。例如：31中将修订关系分成三种类型：j修正型：修改之前版本的漏洞；k适应型：将之前版本转移到另一个平台上；l加强性：提高之前版本的性能或者增加某些功能。版本空间中每一个版本必须被标识，最常用的方法是用数字来标识。数字ID会随着顺序的修订而不断升高。2分支：修订是严格顺序的，只能提供一个最新的版本，但分支可以提供最新版本的可替代产品。使用分支而不使用修订的原因有可能有以下几种31：j临时的调整：当需要对不是最新的版本进行修改，那么我们需要为该版本产生出一个分支，这样子就不会与之前的版本发生冲突。之后还要对该分支进行合并。k分布开发：用户的局部修改应该独立于开发的主线。l同时开发：偶尔，两个开发者可能需对相同的对象进