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

第一章 引言 传统的软件配置管理建立在文件版本控制的基础之上，现代大型软件系统的开发要求在更大粒度上进行版本控制。同时，基于软件体系结构的软件开发是当前的发展趋势，也需要适应其特点的版本管理模型的支持。1.1 版本管理模型概述1.1.1 配置管理概念随着软件开发规模的不断增大，一个项目中的中间软件产品的数目也越来越大，中间软件产品之间的关系也越来越复杂，对中间产品的管理也越来越困难，有效的配置管理则有助于解决这一问题。现在人们逐渐认识到，配置管理是适应软件开发需求的一种非常有效和现实的技术1。配置管理是软件过程的关键要素。它是一种按规则实施的管理软件开发和维护过程及其软件产品的方法。软件配置管理系统在软件质量管理中也起着重要作用，它不仅是CMM的核心内容之一，是绝大多数软件过程工程和管理过程不可缺少的部分，也是国际标准化组织IS09000质量管理体系的核心内容之一。IEEE定义了软件配置管理（SCM）的标准2，在这个标准中，SCM应该定义四个主要方面：1）配置标识（configuration identification）：产品、产品结构和产品中组件的标识及其类型；2）配置控制（configuration control）：控制配置项及其组件的演化；3）配置状态统计（configuration status accounting）：记录报告产品状态和变更请求，收集组件统计信息；4）审计、审查（audits and reviews）：维护产品完整性和一致性。后来，随着异质平台开发、团队协作的出现，配置管理的定义得到进一步的扩展。SCM还包括：5）生产（manufacture）：管理产品组装和构建；6）过程管理（process management）：执行组织的过程、策略和生命周期模型；7）团队合作（team work）：支持开发者间的协作。1.1.2 版本管理概念版本管理是SCM的核心功能3，版本管理的基本任务就是同时管理一个数据元素的多个版本4。版本管理应该具备以下的基本功能：1）创建新本版；2）通过某种选择机制来访问特定的版本；3）对版本添加用户定义的名字或标识；4）删除版本；5）维护版本间的关系；6）修改已存在的版本，这个操作一般是不允许的，至少不能是直接的；7）锁定特定版本；8）版本合并；9）赋给版本状态值和属性值；10）允许用户自定义数据对象间的关系。为支持版本管理，需要一个合适的版本模型。该模型需要定义进行版本化的元素，版本的标识及其组织，版本的查询，版本的创建等等。版本模型可因版本化的元素，版本的组织结构、版本的粒度、面向状态的版本或者面向变更的版本、版本的选择规则的不同而不同。5中定义了组成版本模型的基本术语，如图1.1所示：图1.1 版本模型基本术语1）版本、版本元素、配置项版本v代表着演化元素i的某一个状态。版本v可以通过表达式v = (ps, vs)来表示，ps、vs分别代表版本v在产品空间和版本空间中的状态。版本元素指由版本库维护其演化的元素。配置是指一个复杂对象的某一版本，例如：软件系统的一个配置是由需求文档、软件体系结构、程序源代码的某一版本组成。2）增量两个版本之间的差别称之为增量。一个版本通过对基版本使用一组变更来创建新版本就是直接增量存储。而对于内嵌增量和选择增量存储，某一元素的所有的版本是存储在一起的，因此各版本间的共同部分可以共享。内嵌增量方式通过指针指向其片断来组成一个版本，选择增量方式通过可见性表达式来决定一个版本。3）版本演化各版本沿着时间轴方向顺序演化称之为修订。这样的演化一般是指修改前一版本的错误。而对于各版本需要并行演化的称之为分支。4）版本描述面向状态的版本管理是指只关心版本元素的状态的版本管理。面向状态的版本管理通过修改和分支来描述一个版本。面向变更的版本管理通过对基线版本使用一组变更来描述一个版本。这样就可以跟踪每个版本到底执行了那些变更。面向变更的版本管理有许多的优点：j允许基于规则的版本查询，而非以枚举的方式浏览版本树；k可以容易的获取各文件的一致性版本，而无须以手工的方式创建；l非常容易比较两个版本间的差别。但面向变更的版本管理也存在问题：j变更的选项是线性增长的。当选项的数量超过一定值时，用户将面对繁多的选项而无法进行选择；k选项的命名一旦被确定将无法改变，这将导致以后若有类似的选项将非常难于命名；例如：假设已经存在一个“fill”的选项，如果以后需要增加一个新的“fill”选项，其命名可能就只能是“newfill”；l由于选项是属于布尔型的，其取值只能是TRUE，FALSE和UNSET。则在某些情况下，会导致大量的选项出现。例如：若需要管理一个操作系统的属性，则对每种操作系统都需要增加一个选项（DOS，WINDOWS，UNIX等等）；m面向变更的版本管理中版本之间没有什么明显的关系，每个版本都可以作为一个分支，缺乏一个版本的演化历史。n选项间并不是独立的，有可能存在多种关系；例如：互斥关系，一组选项中只有一个能取值为TRUE；依赖关系，选项的设置依赖于其他选项的设置，比如我们不会设置SunOS选项，除非我们已经将UNIX选项设置为TRUE；面向状态的版本模型的优点：j可以清楚地看到版本的演化历史；k完整的保存各版本实体的内容；l可以容易的创建基线，配置等等。面向状态的版本模型存在的问题：j每个版本只代表一个状态信息，所以不能确定每个版本具体进行了哪些修改。k对一个版本描述一般来说只包含该版本与其父版本之间的差别，这样的描述既不精确也不全面。l版本之间的差别不能量化，难以实现自由版本查询。m版本选择大体是通过手工的方式进行。5）版本空间 分支和修订来组成一个版本图来代表一个版本空间。而网格通过将版本放置入一个n维的空间中来代表一个版本空间，空间中每一维代表了一个需要选择的属性。6）版本集 一个版本元素的所有版本定义为集合V。V可以通过精确（枚举）或隐含（版本谓语）方式来定义。对于外延版本，V通过枚举方式进行定义：V = v1,vn。基于外延版本的版本管理支持检出之前创建的版本vi，然后再检入新版本vi+1。内沿版本支持灵活的创建一致的版本。对于内延版本，V通过一个逻辑的约束进行定义：V = v|con(v)。所有满足约束con的版本都属于V。通过一个选择谓语evd来选择集合V中的一个特定版本：evd(v)Ùcon(v)，然后创建新版本。7）版本规则 内沿版本是建立在版本规则的基础上。约束定义了合法性规则，偏好定义了用户优先选择的规则，默认定义了在没有指定的情况下的规则。8）粒度从用户的角度，版本的粒度可以是组件、完全、产品粒度：对于组件粒度，只有原子组件是在版本管理之下的，每个原子组件都有其自身的版本空间，可以将组件的特定版本组合成配置；对于完全粒度，不仅仅是原子组件，而是所有的组件包括配置都是在版本管理之下的；对于产品粒度，所有组件包括配置都在一个统一的全局的版本空间之下，例如：所有的面向变更的版本模型都采用这种版本粒度。9）工作区 为进行开发和维护工作，用户必须在版本库之外建立一个工作区，在工作区可以进行编辑、编译操作。工作区可以通过检出版本库中的数据至文件系统来创建，也可以通过选择谓语evd选择某一版本来提供一个虚拟的工作区。1.2 版本管理模型分类1.2.1 按术语集分类使用§1.1节中定义的术语，可以对现有的配置管理工具的版本模型进行分类。图1.2中将13种配置管理工具的版本模型按照版本描述和版本粒度分为四类。该分类从术语的角度进行分类，而不关心每个术语功能的实现程度。每一类中各个配置管理工具按照出现的年代及其继承关系排列。图1.2 基于术语的分类1）面向状态-组件粒度版本模型SCCS6是一个简单的管理文本文件的配置管理工具，版本通过版本树的形式进行存储。用户将一个版本检出到工作区中，当完成变更任务后，他将修改后的版本检入到SCCS版本库中。在SCCS中，文件的组织结构是不可见的。RCS7继承于SCCS，在许多方面进行了改进。RCS使用直接增量进行存储，主分支上的最新版本可以直接访问，其他版本通过向后和向前增量进行创建。此外，RCS提供一组内嵌的属性集用以标记版本状态和助记名，助记名可以用来标记一个由所有组件的一致性版本组成的配置。RCS还能简单的支持内延版本（检出操作中可以包含属性规则）。但操作时RCS还是必须要先选择产品结构，并且不能对产品结构的版本进行建模。2）面向状态-完全粒度版本模型DSEE8整合了Make和SCCS/RCS的功能，支持基于规则的配置创建和网络的并行开发。DSEE使用一个系统模型来描述配置，系统模型描述了软件系统中的对象及其它们之间的关系。系统模型中不包含各实体的版本，它们是通过配置规则来进行选择的。用户首先选择系统模型中的产品结构，然后再通过配置规则选择进行版本的绑定。ClearCase9继承于DSEE，它不仅对文件进行版本化，也对目录进行版本化，所有版本对象都统一称为元素。与DSEE不同，ClearCase像访问其他元素一样访问系统模型。3）面向变更-产品粒度版本模型Aide-de-Camp10通过一组变更集和基线来描述产品的版本。全局变更可以同时影响多个文件。在Aide-de-Camp中，变更集是完全顺序的，如果变更集c1先于变更集c2创建。则某一个产品的版本如果包含c2，则首先必须先包含c1。每一个变更集可以看作一个开关：或者开或者关。但Aide-de-Camp不支持关系。在COV4中，版本数据库由一组片断组成，而每个片段都有一个逻辑的表达式称之为可见性（visibility）。可见性是一组全局的布尔选项（option），这组布尔选项组成了n-维的版本网格。COV通过选择（choice）和目标（ambition）规则来进行版本的读取和修改，选择中指定了所要选择版本的选项绑定，而目标通过选项绑定决定了修改会影响到的版本空间。4）面向变更-完全粒度版本模型 Asgard11实现在ClearCase之上，在版本图之上提供了面向变更的版本管理。每一个组件的版本通过活动（activity）进行标记，工作区通过基线和一组活动进行定义。从上面的比较可以看出，版本模型从面向状态向面向状态和面向变更相结合的方向发展；从面向组件的粒度向面向完全的粒度方向发展。同时还可以看出虽然很多的版本管理模型实现的功能是相似的，但实现的程度却相差非常之大。因此在本文中实现的版本管理模型应该从实现功能的通行性方面和实现的程度方面来增强改进。1.2.2 按概念集分类还可以从版本管理模型提供的概念集，将版本管理模型分为以下四类12：检入/检出模式（CheckIn/CheckOut Model）这个模式提供单系统组件的版本管理。这样版本管理模型有两个独立的工具组成：版本库工具和创建工具。版本库工具负责存储文件的各个版本以及提供创建新版本的机制。创建工具提供一个文件描述用于生成应用及自动生成导出文件。在版本库中的文件不能直接访问，只能通过检出操作，检出后的文件被保存至文件系统，从而能对其进行读写。版本库的并发控制机制可以协调多用户的读写活动。文件系统是用户真正的工作区。版本库工具没有提供对工作区的支持，而是依赖于文件系统来提供用户一个互斥的写访问工作区。用户按照寻常方式来使用创建工具等工具，文件的版本对于这些工具来说是透明的。创建工具通过解释文件系统中的文件描述来创建一个系统。这些文件描述可以存储在仓库中并像一般文件那样进行版本化。RCS13就属于这种类型的版本管理模型。组合模式（Composition Model）组合模式通过版本选择来创建系统配置，组合模型是检入/检出模式的发展，它同样采用了版本库和工作区的概念，使用文件锁来进行并发控制。其主要的改进是支持创建配置，维护配置的历史。在该模式中，配置作为版本管理模型的实体。一个配置由一个系统模型和版本选择规则组成。系统模型列出了组成系统所需的所有组件，版本选择规则指明每个组件的版本。组合和选择的过程可以通过一个AND/OR图来表示。首先将组件组合成一个配置（AND节点），然后为每个元素选择合适的版本（OR节点），当然这个元素还可以是一个配置。DSEE14是属于这种类型的版本管理模型。长事务模式（Long Transaction Model）长事务模式将系统的演化描述为一系列的配置项版本和一系列并发的活动。系统的演化过程一系列原子变更的过程，通过开发者来协调系统的这些变更。开发者对配置进行操作而不是对单个组件。选择一个配置作为变更的起点，对该配置所进行的修改外界是看不到的直到该事务提交。多个事务间通过并发控制进行协调。一系列变更的结果是一组顺序的配置版本，称之为开发路径。配置版本可以从已有的开发路径分支。在长事务模型中，开发者首先选择系统配置的一个版本，然后再关注系统的结构。组件的版本隐含的由配置决定。长事务由两个基本的概念组成：工作区和并发控制模式。工作区取代了文件系统，支持开发者在工作区内执行变更活动序列。通过将工作区中的配置进行提交，从而使得变更变得可见，同时这个配置将会添加到最初的配置版本之后。此时一个事务结束。NSE15是属于这种类型的版本管理模型。变更集模式（Change Set Model）变更集模式关注于版本的逻辑变更，对于文件而言，变更集代表两个文件版本间的差别。对于配置而言，变更集代表两个配置间的差别。在这种模式中，配置由基线和变更集共同组成。如对系统发布版本的补丁程序就可以看成是一种变更集。变更集用来对逻辑变更进行跟踪，通过在逻辑变更的基础上定义新的配置。变更集模式本身不提供锁机制来进行并发控制，而是通常与检入/检出模式共同使用。Aide-De-Camp16就是属于这种类型的配置管理系统。 但以这种方式进行的分类存在一个缺点就是各种分类不是正交的，其中的某一分类可能同时也属于另一分类。本文中的版本管理模型的目标应该在概念集上包含以上各种分类，因此在版本模型的设计上应该从不同的层次上对以上的概念集进行支持。1.3 软件体系结构概述1.3.1 软件复用复用是成熟的工程领域的一个基本特征，例如，土木工程、化学工程、计算机硬件工程等，通过大量复用经过实践检验的系统体系结构和标准化的构件，使得对于常规的设计问题都可以直接利用现成的解决方案，避免了系统开发时不断地重复设计，从而可以大幅度地降低开发成本、提高生产效率和产品质量。同样，复用也是软件工程走向成熟的必由之路,将为软件危机的解决提供一条现实可行的途径。基于构件的软件复用作为一种提高软件生产率和软件质量的有效途径，是近几年软件工程界研究的重点之一，被认为是继面向对象方法之后的一个新的技术热潮17。通过基于构件的软件复用，在应用系统开发中可以充分地利用已有的构件，消除了在分析、设计、编码、测试等方面的许多重复劳动，可以提高软件开发的效率；同时，通过复用高质量的已有的构件，避免了重新开发可能引入的错误，可以提高软件的质量。因此，基于构件的软件复用可以大大降低软件开发的费用，并显著地提高生产率和产品质量。与软件复用相关的两个基本开发活动是面向复用的构件开发和基于构件复用的开发，前者是生产可复用构件的过程，后者是利用现有的可复用构件生产新系统的过程。可复用构件为有计划地、系统地进行复用提供了手段，是实现软件复用的基石。软件复用最终体现为在软件体系结构的指导下对可复用构件的组装。1.3.2 软件体系结构概念自20世纪90年代初期开始，软件体系结构(software architecture，简称SA)的研究受到了广泛的关注和重视，并被认为将会在软件开发中发挥十分重要的作用。它将大型软件系统的总体结构作为研究的对象，认为系统中的计算元素和它们之间交互的高层组织是系统设计的一个关键方面18。其研究和实践旨在将一个系统的体系结构显式化,以在高抽象层次处理诸如全局组织和控制结构、功能到计算元素的分配、计算元素间的高层交互等设计问题19。SA是对软件总体结构的描述，即对其构件和构件间交互的高层组织的描述18。它作为一种高层的设计，对系统开发发挥着重要的影响，基于构件的SA的设计已成为软件系统设计中的核心问题。一个好的SA设计成为大型软件系统成功的重要因素。SA的最重要的一个贡献是将构件之间的交互显式的表示为连接器(Connector)，并将连接器视为和构件同等重要的一阶实体。构件通过接口定义了同外界的信息传递以及所承担的系统责任，构件接口包括了构件同周围环境的全部交互内容，也是构件同外界唯一的交互途径。除此之外，环境不应对构件作任何其他与接口无关的假设，例如实现细节等。连接器在构件请求接口与其他构件提供的接口之间搭建一座桥梁，起到了代理作用。在SA的设计过程中，人们针对不同的需求采用了不同的软件构架风格。体系结构风格定义了一系列系统的结构组织的模式20，它是对一类具有相似结构的系统体系结构的抽象。体系结构风格既定义了构件及连接方式的各种属性, 又规定了它们的组合规则和限制18。近十年中人们设计了许多SA风格：1）管道-过滤器风格每个过滤器都有输入端口和输出端口，从输入端口读入数据流，进行局部的数据变换(计算或处理) 以后，在输出端口输出新生成的数据；管道则负责数据的传输，把数据从一个过滤器的输出端口传送到另一个过滤器的输入端口。这个过程是顺序渐增的过程，而且过滤器必需是相互独立的实体。这里的过滤器是指体系结构中的构件，管道是体系结构中的连接器。2）面向抽象和面向对象组织风格这种风格中，数据表示和与之相连的原语操作被封装在一个抽象数据类型或对象中。这种风格的构件是对象，也可称为抽象数据类型的实例。对象通过函数和过程调用进行交互。这种风格可以细分为三种风格：j对象连接式风格：在这种类型的体系结构中,构件的接口只定义了其对外提供的服务，而没有定义构件对外要求的服务，其中以面向对象中的对象接口为典型代表。这种接口定义的非对称性使得构件在集成时，构件对外要求的服务被隐藏在代码的实现细节中，即构件之间的连接关系无法直接在接口处定义，只能是从一个构件的实现到另一个构件的接口。k接口连接式风格：在这种类型的体系结构中，构件的接口不但定义了其对外提供的功能，而且定义了其要求的外部功能，从而显式地表达了构件对环境的依赖，提高了构件接口规约的表达能力。构件的接口定义了所有对外交互的信息，构件在实现时不是直接使用其他构件提供的功能，而是使用它在接口处定义的对外要求的功能。构件之间的连接是在所要求的功能和所提供的功能之间进行匹配，因此，通过接口就可以定义系统中构件之间的所有连接。l插头插座式体系风格：当接口定义的功能数量很大时，带来了规模上的问题。在这种体系结构风格中，通过把这样的彼此间关系紧密的功能(包括提供的功能和要求的功能)组织成组，并封装为服务，使得接口中直接包含的内容减少，降低了接口中功能的规模。3）基于事件的隐式调用风格这种风格与面向对象结构风格类似，不同的是，在这种风格中，部件之间的交互不是直接调用，而是通过一种称之为“隐式调用(implicit invocation) ”的方式来实现的，每个部件提供若干进程及它感兴趣的事件，并把每个事件与一个过程联系在一起，当某个部件产生一个事件时，若其它部件定义了这个事件，那么与该事件联系在一起的过程将被自动调用，从而间接地完成了过程的调用。4）分层系统风格 一个分层系统就是把整个系统组织成层次结构，每一层都提供若干服务给上一层使用，并且它也使用其下一层所提供的服务。可以将这种风格细分为两种：j基于层次消息总线的结构风格：消息总线是系统的连接器，负责消息的分派、传递和过滤以及处理结果的返回。各个构件挂接在消息总线上，向总线登记感兴趣的消息类型，构件根据需要发出消息，由消息总线负责把该消息分配到系统中所有对此消息感兴趣的构件，消息是构件之间通讯的唯一方式。构件接收到消息后，根据自身状态对消息进行响应，并通过总线返回处理结果。kC2风格：C2构架中的基本元素是构件、连接器。每个构件定义有一个顶端接口和一个底端接口，构件通过这两个接口连接到构架中，这使得构架中构件的增加、删除、重组更为简单方便。每个连接器也定义有顶端接口和底端接口，但接口的数量与连接在其上的构件和连接器的数量有关，这也有利于实现在运行时的动态绑定。构件之间不存在直接的通信手段，构架中各元素构件、连接器之间的通信只有通过连接器传递消息来实现。处于低层的构件向高层的构件发出服务请求消息，消息经由连接器送到相应的构件。各种不同的SA风格的设计均是基于不同类型的连接器20。文献21中，连接器被划分成8种类型：过程调用类型(Process Call)、事件类型(Event)、流类型(Stream)、分布者类型(Distributor)、数据接入类型(Data Access)、仲裁者类型(Arbitrator)、适配器类型(Adaptor)、联接类型(Linkage)。文献22中，非功能属性(如保密性，服务质量等)被认为是连接器描述中的重要组成部分。1.4 软件体系结构描述语言1.4.1 软件体系结构描述语言概述SA研究的主要成果表现为体系结构描述语言(architecture description language,简称ADL)。从构件组装的角度来看，ADL可以视为对构件描述语言(CDL)的进一步扩展。构件描述语言的基本思想是将构件看成是一个黑盒，通过描述构件接口的语法和语义，使得复用者不必过多地涉及构件代码细节，就可以在构件描述这一抽象层次之上进行构件组装。而ADL除了描述构件接口的语法和语义之外，还负责描述：系统中包括的构件和连接子以及它们之间的交互关系、构件的非功能类性质以及构件间协议，从而为构件组装提供了更为有力的支持。体系结构描述语言(ADL) 是为软件系统的体系结构提供具体的语法和概念框架的一种形式化符号。迄今为止，研究者已经从不同的角度出发，针对不同的目标，提出了各种通用的和专用的ADL：1）Rapide2324：一种事件驱动的ADL，它以体系结构定义作为开发框架，支持基于构件的开发。该语言提供了建模、分析、仿真和代码生成的能力，但是没有将连接器显式化为一阶实体。2）Wright25：具有代表性的ADL之一。其主要特点是将通信顺序进程26（Communicating Sequential Processes，简称CSP）用于不同风格软件体系结构的描述，从而完成对体系结构描述的某些形式化推理(包括相容性检查和死锁检查等)。3）UniCon27：将一组预定义的连接器映射到具体实现，从而提供了从模块到可执行代码、从体系结构设计生成应用的可能性。但是目前它只支持一组已选定的连接器，存在一定的局限。4）Aesop28：支持精确的编码并能够定义一个新的体系结构的风格，然后通过加上某些约束和利用它们的所有性质来使用这个风格。5）xArch29：一种基于XML的ADL。它使用XML 定义了描述体系结构的核心元素,可以作为其他更高级的基于XML的ADL的基础。也可以用做体系结构描述的交换机制。6）ACME30：支持ADL之间映射及工具集成的体系结构互交换语言。其目标是作为体系结构设计的一个共同的互交换格式,将现有的各种ADL在这个框架下统一起来。1.4.2 Wright构架描述语言Wright ADL是基于CSP的形式化构架描述语言。CSP26中使用的基本记号如下所示：1）进程（process）：使用一系列事件序列来表示一个进程实体，例如上文中提到的各个role、port均是一个进程。STOP是一个特殊进程，表示什么事都不做的进程。2）字母表（alphabet）：进程所能执行的事件的总和；特殊事件：事件“Ö”代表进程成功结束。进程P的字母表表示为aP。3）前缀（prefix）：设有一事件为x，有一进程为P，则另一进程先执行事件x，然后按照进程P的说明进行动作；用（xP）表示。4）非确定性选择（non-deterministic choice）：进程A或者按照P动作，或者按照Q动作，而这种选择是进程自发做出的。用PÕQ表示。5）确定性选择（deterministic choice）：进程A或者按照P动作，或者按照Q动作，而这种选择是环境做出的。用PQ表示。6）通信（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。则进程中所有的事件也标记上与其所属进程相同的名字。在进程表达式中的优先级高于，Õ，|操作符。所以efP|gQ=（efP）|（gQ）。对于其他操作符，未定义显示的优先级，所以在使用时用括号来确定优先级。有了CSP的基本记号，我们就可以对客观事物描述其动态行为，从而为推理、验证事物行为提供了强有力的工具。如图1.3所示，Wright ADL描述的软件体系结构一共由三部分组成：1）构件及连接器类型定义：构件类型由一组端口（port）描述和构件功能描述组成，每一个端口是构件与其他构件交互的逻辑单位；连接器类型由一组角色（role）和一个粘接器组成，角色描述了连接器所期待构件的行为，粘接器描述了各角色行为之间的同步。图1.3 Wright构架描述语言2）一组构件和连接器的实例定义。3）构件实例与连接器实例间交互定义，将构件实例的端口绑定到连接器实例的角色上，从而完成构件间的交互。图1.4 仓库风格的Wright ADL描述图1.5 管道过滤器风格的Wright ADL描述Wright ADL可以用来描述各种软件体系风格的软件构架。如图1.4所示的仓库风格，图1.5所示的管道过滤器风格。1.5 相关工作配置管理中的版本管理模型一直是软件工程界研究的热点。在31中提出了版本管理模型的基本概念：软件对象、版本图、系统创建、基于AND/OR图的版本选择，并试图统一版本模型术语。之后版本模型不仅仅支持保存单文件的版本，而且支持创建一致性的配置32。随着不同版本模型的不断出现，12中根据版本模型概念集将版本管理模型分为四类：检入/检出模型、组合模型、长事务模型、变更集模型，但是这四种分类结果并不是正交的，一般的版本模型包含一个或多个以上的模型。在33中将版本管理模型分为以下几个方面：版本集的组织、动态配置机制、层次组合、版本族机制、变更传播、对象共享。但这些版本管理模型缺乏一个高层视图的支持，虽然在版本模型中可以用户自定义配置，但所有的配置按照何种规格以及以何种规则进行组织在这些版本模型中都没有讨论。随着软件工程技术的不断发展，新技术不断的涌现，人们将配置管理技术同其他技术结合，从而发展出新的版本管理模型。软件过程建模技术343536同传统版本管理模型结合产生支持过程建模的版本管理模型3738，该版本模型中定义的产品空间被扩展用以包含过程建模，同时须对产品空间与过程建模间的交互进行设计。将基于构件的软件开发技术同传统的版本管理模型结合，发展为基于构件的软件版本管理模型3940。但当前的基于构件的版本管理模型主要关心的是原代码模块间的依赖关系，缺乏管理软件对象间关系的能力。同时基于构件的开发没有在一个软件构架的支持下进行。1.5 存在的问题随着CBSE的发展，当前CBSE的版本管理模型中存在如下问题：未能与CBSE结合，对基于构件开发的支持非常有限，很多系统只是简单的将构件作为一系列文件的集合，而对于构件拥有的语义、构件间的依赖关系、构件中各组成部分的依赖关系的定义非常不足，未有支持SA的版本管理模型；在粒度管理方面只是通过简单的组合来创建一个版本管理的粒度，未能按照用户的自定义来定制版本管理的粒度；未能将版本模型和数据模型分开，所有功能模块交错在一起。为此，本文提出一个分层的基于构架的版本管理模型SAVM，在版本模型层上，同时支持面向状态和面向变更的版本操作，以统一的方式对待所有的数据元素，从而实现了一个通用的版本引擎；在版本引擎之上，将数据模型层分为两个子层，一个子层实现数据元素及数据元素间关系的组合，一个子层负责基于软件体系结构的数据模型，使得版本管理模型能够支持基于软件体系结构的开发。在数据模型层之上进行事务管理和过程管理，从而为软件组织提供了并行开发的控制和支持软件开发模型的支持。第二章 SAVM的体系结构版本管理模型SAVM针对上面的这些问题提出了解决方法，它是一个主要实现了版本管理、数据管理、过程管理、并发控制以及支持基于软件体系结构面向构件的软件开发方法等功能，从而实现了比较全面的软件版本管理模型。2.1 SAVM设计的基本要求作为一个基于软件体系结构的版本管理模型应该具备两个方面的功能：1）通用版本管理模型所拥有的功能；2）支持基于软件体系结构的开发所拥有的功能。因此在设计该模型时，需对这两方面功能的要求进行定义。2.1.1 基本要求根据§1.1.2节中对版本管理模型术语的一个分类，可以对SAVM所要满足的要求定义如下：1）一般性要求：SAVM必须满足版本空间和产品空间的基本要求。用户可以在产品空间中自由的设定需进行版本管理的版本元素；也可以自由的设定版本元素的版本空间。从而为用户提供一个足够通用的版本引擎，使得用户可以自定义的将其转化为任何一种特定的版本模型。2）增量的选择要求：在增量的选择上，需要对存储效率和执行效率进行考量。由于这属于物理实现层面上，因此SAVM版本模型不对此进行设计。3）版本演化的要求：版本的演化应该同时支持分支和修订，而且分支和修订对于不同粒度的版本元素应该按照一个统一的方式进行，即在版本空间中，应该统一对待所有的数据元素。4）版本描述的要求：需要同时支持面向状态和面向变更的版本管理方式。面向状态和面向变更这两种方式间应该是正交的，即它们之间不存在互相的关系。5）版本空间表示的要求：对于面向变更的版本管理适用于使用n维网格进行表示，而面向状态的版本管理适合使用版本图来进行描述，因此需要将这两种描述方式有机的结合在一起。6）版本集定义的要求：面向状态的版本管理自然的支持外延版本，而面向变更的版本管理自然的支持内延版本；但面向状态的版本管理应该同时能支持内延版本，而面向变更的版本管理也能支持外延版本。7）版本规则的要求：对于内延版本而言，需要有版本规则的支持。而对于外延版本而言，使用版本规则可以定义基线、配置等概念。8）选择粒度的要求：版本模型应该能够提供产品、各组成成分的选择粒度，以满足用户在不同时刻的不同要求。9）工作区管理的要求：工作区应该同外部工具版本在一起，从而实现版本模型与工具间的集成。2.1.2 基于SA的要求SAVM是支持基于软件体系结构开发的版本管理模型，因此在版本模型中需要对SA的基本概念提供支持，并且支持基于构件的软件开发方法。版本模型应满足的要求如下：1）支持构件定义：构件包括构件接口和构件实体两部分。同时构件接口同构件实体间存在着互相依赖关系，一方的改变可能导致另一方的改变。而且构件接口中应该包含语义信息用以描述构件的行为，接口类型可以根据SA风格的不同而不同。构件实体可以是一组相关的目录、文件，文件间存在着依赖关系、包含关系等多种关系。2）支持连接器定义：连接器包括角色和粘接器两部分组成。连接器作为构件实体间的连接代理，连接器的角色和构件的端口应该满足相容的关系25。角色和端口都应该包含语义信息。3）支持SA定义：SA由构件、连接器以及它们之间的连接关系组成。版本管理模型不仅需要将构件、连接器作为实体来对待，而且需要将连接关系作为实体来看待。SA是版本管理模型中的最大粒度，用户可以根据不同的需求按照各种不同的粒度来查看整个SA。这里不仅需要设计构件、连接器、SA版本演化规则，而且需对它们之间在演化过程中的相互影响进行定义。4）支持基于软件体系结构的软件开发方法：17中提出了一个基于体系结构、面向构件的软件开发方法，方法中定义了一个开发的流程。版本管理模型中需要设计一个新型的过程管理定义语言对所有通用的软件开发模型进行定义，从而支持基于构件的软件开发的过程管理。5）支持基于软件体系结构的并行开发：当前的软件开发的规模已经不是仅仅靠一个人就能完成的了的，需要一个团队合作完成。版本管理模型需要提供并发控制机制和用户权限管理功能。以上SA中的所有元素将通过Wright描述语言定义，版本模型应该提供将描述语言自动的转化为适合版本管理模型管理的实体的能力，同时不应丢失语言中描述的任何信息。2.2 SAVM结构设计根据§2.1节中定义的SAVM的基本要求，我们可以看到SAVM版本管理模型涉及版本空间、产品空间和过程管理。首先遇到的问题是如何将版本空间、产品空间、过程管理这些概念有机的组合在一起来提供一个高效、通用的版本管理模型。我们可以正交的对待版本、产品和过程，从而实现一个分层的版本管理模型。这样有利于对版本模型的修改和扩展，当发生修改时也可以使修改范围定位的足够小；同时当版本模型需要进行扩展功能时，非常容易定位增加功能所处的层次，只需扩展该层就可实现整体功能的扩展。为决定一个系统的构架，并按分层的方式把以上三个概念组合起来，SAVM版本模型必须对以下几个问题做出决定：1）数据模型和版本模型之间的关系这决定了产品空间与版本空间之间的关系，数据模型定义了产品数据的基本概念（如构架、构件、简单文件）。版本模型定义了版本标识及其组织，同时还定义了查询和创建一个新版本的操作等等。数据模型和版本模型的关系可以有以下几种方式：j版本模型位于数据模型之上；k版本模型和数据模型结合在一起；l数据模型位于版本模型之上。SAVM版本模型是一个层次模型，因此应该将版本模型和数据模型分开放置在不同的层。同时根据用户可以选择不同粒度的版本，因此数据模型应该位于版本模型之上。2）选择一个增量表示 增量可以分为三类：直接增量、内嵌增量、选择增量。作为一个物理层面上的是实现，应当考虑存储效率和执行效率问题。SAVM只是一个基于软件体系结构的版本管理模型原型，因此不对增量存储进行定义。3）定义基本的版本概念 版本模型中需要定义一个基本的概念，高层的其它概念必须可以通过这个基本的概念组合而成。为使版本模型足够的通用，所有在版本模型中的元素都是原子的，称之为片段（fragment）。片段之间可以在数据模型层组合形成数据元素，而对片段的管理是既允许进行面向状态的版本管理也允许面向变更的版本管理。4）外延版本和内延版本的关系大部分面向状态的版本管理具有外延版本的特点；而大部分面向变更的版本管理具有内延版本的特点。内延版本和外延版本的关系可以分为三种：j内