资料下载
×
基于构件的软件版本管理系统详解
消耗积分:1 |
格式:rar |
大小:0.3 MB |
2017-10-19
背后的看客
分享资料个
1 引言
配置管理系统［ 3， 9］是软件开发的关键支撑工具之一，是一种管理软件开发和维护过程以及其中各中间软件产品的系统，是ISO与CMM质量保证体系的核心支持工具。配置管理研究怎样在不同时刻标识软件系统的配置，以便系统化地控制配置的改变，并在整个软件系统的生命周期内维护配置的完整性和可追踪性［ 1］ 。其中，版本管理是基础和核心。传统的版本管理系统以文件作为管理的基本粒度。版本管理系统记录、维护每个文件的演化历史。在大型软件开发中，系统往往包含较多文件，这使得传统方式版本管理的工作量很大，而且不易于描述文件间内在的组合关系。目前，基于构件的软件开发方法已成为发展趋势［ 7， 8］ 。构件作为系统的有机构成成分，在物理上可以表现为多个文件的集合体，而在开发过程中是作为一个原子单位使用的。系统的开发者关心的是构件整体的开发、演化，组装和维护。这种大粒度的开发方法，对版本管理提出了新的要求［ 3］ 。这些要求包括：
#应能有效存储和管理构件演化历史。
#操作模型应有利于体现构件的整体性， 降低系统开发的复杂程度。
#需要保证并行开发构件时的正确性， 同时不减少项目组协同工作的灵活性。
本文研究了构件的版本控制策略，提出了基于构件的版本管理模型。针对并行开发问题，又提出了分别在构件和文件粒度上进行版本管理和并发控制的方法。在此基础上，设计实现了一个产品化的配置管理系统JBCM.该系统既提升了管理的粒度，又能确保团队开发具有较好的并行性。
2 以构件为粒度的版本管理
2.1 版本管理系统中的构件定义
在基于构件复用的青鸟软件生产线中，软件构件定义如下： /构件是可以被多个软件系统复用的具有独立功能的系统构成成分0 ［8］ 。构件在实际形态上可表现为通过目录结构组织起来的一些文件的集合，并且是系统中可以明确辨识的构成成分。需要指出的是，在以前许多有关版本管理的文献中都出现了构件的概念［ 4］ ，但其中的构件一般指的就是文件。本文中的构件则是应用系统中多个相关文件构成的一个逻辑整体，例如一个类的定义及其实现，一个完整的功能模块等。构件版本是构件组成文件版本的集合。构件版本的变化不仅体现了组成文件的版本变化，同时也反映了构件中文件组成的变化。也就是说，组成文件发生版本演化，或者增加和删除构件中的文件，都会引起构件版本的演化。在基于构件的系统中，文件版本由系统内部控制，用户只关注构件版本，从而提升了管理层次。图1反映了构件版本与文件版本的关系：
图 中虚线箭头表示构件和文件与其不同版本的关系， 实线箭头表示构件版本由文件版本组成的关系。从图中可以看出构件的版本2 比版本1 增加了一个文件3， 而且文件版本也发生了演化。 构件版本的演化与文件版本的演化同步进行， 并且随着文件的版本演化自动产生。基于上述构件与文件关系模型， 提出并实现了基于构件的软件版本管理系统。
2.2 构件的版本管理
（1） 以构件为粒度的版本管理特点
与 基于文件的版本管理相比， 基于构件的版本管理有以下主要特点： ¹ 构件的抽象级别比文件高。 构件是应用系统中可以明确辨识的构成成分。 记录、维护构件的版本比文件的版本管理更有意义。 º 构件的粒度可以比文件大很多。 一个项目中可能有诸多分布的逻辑单元， 这些逻辑单元与构件相对应。构件的数量较少， 而且整体逻辑意义明显， 可以更清晰地体现项目的演化历史。 » 在构件基础上， 可以体现出系统的层次性、构造性等特征。 同时， 构件版本管理也可以满足对文件版本的管理需求， 使版本管理既有大粒度， 又有灵活性。
（2） 构件版本管理的基本模式
基 于构件的版本管理系统采用/ 检出（ Check Out） 、修改、检入（ Check In）0 的基本操作模型， 操作的基本单位是构件。 使用者需要先将构件从版本库检出到工作区， 随后在工作区中完成对构件的修改， 最后将修改的结果检入版本库。 构件组成文件的增删以及其中任何一个文件的修改都被视为对整个构件的修改。 因此， 作为检入操作的结果， 版本管理系统会自动生成构件的一个新版本。 以构件版本为粒度的版本管理系统记录和管理了开发人员对构件修改的历史。
配置管理系统［ 3， 9］是软件开发的关键支撑工具之一，是一种管理软件开发和维护过程以及其中各中间软件产品的系统，是ISO与CMM质量保证体系的核心支持工具。配置管理研究怎样在不同时刻标识软件系统的配置，以便系统化地控制配置的改变，并在整个软件系统的生命周期内维护配置的完整性和可追踪性［ 1］ 。其中，版本管理是基础和核心。传统的版本管理系统以文件作为管理的基本粒度。版本管理系统记录、维护每个文件的演化历史。在大型软件开发中，系统往往包含较多文件，这使得传统方式版本管理的工作量很大，而且不易于描述文件间内在的组合关系。目前，基于构件的软件开发方法已成为发展趋势［ 7， 8］ 。构件作为系统的有机构成成分，在物理上可以表现为多个文件的集合体，而在开发过程中是作为一个原子单位使用的。系统的开发者关心的是构件整体的开发、演化，组装和维护。这种大粒度的开发方法，对版本管理提出了新的要求［ 3］ 。这些要求包括：
#应能有效存储和管理构件演化历史。
#操作模型应有利于体现构件的整体性， 降低系统开发的复杂程度。
#需要保证并行开发构件时的正确性， 同时不减少项目组协同工作的灵活性。
本文研究了构件的版本控制策略，提出了基于构件的版本管理模型。针对并行开发问题，又提出了分别在构件和文件粒度上进行版本管理和并发控制的方法。在此基础上，设计实现了一个产品化的配置管理系统JBCM.该系统既提升了管理的粒度，又能确保团队开发具有较好的并行性。
2 以构件为粒度的版本管理
2.1 版本管理系统中的构件定义
在基于构件复用的青鸟软件生产线中，软件构件定义如下： /构件是可以被多个软件系统复用的具有独立功能的系统构成成分0 ［8］ 。构件在实际形态上可表现为通过目录结构组织起来的一些文件的集合，并且是系统中可以明确辨识的构成成分。需要指出的是，在以前许多有关版本管理的文献中都出现了构件的概念［ 4］ ，但其中的构件一般指的就是文件。本文中的构件则是应用系统中多个相关文件构成的一个逻辑整体，例如一个类的定义及其实现，一个完整的功能模块等。构件版本是构件组成文件版本的集合。构件版本的变化不仅体现了组成文件的版本变化，同时也反映了构件中文件组成的变化。也就是说，组成文件发生版本演化，或者增加和删除构件中的文件，都会引起构件版本的演化。在基于构件的系统中，文件版本由系统内部控制，用户只关注构件版本，从而提升了管理层次。图1反映了构件版本与文件版本的关系：
图 中虚线箭头表示构件和文件与其不同版本的关系， 实线箭头表示构件版本由文件版本组成的关系。从图中可以看出构件的版本2 比版本1 增加了一个文件3， 而且文件版本也发生了演化。 构件版本的演化与文件版本的演化同步进行， 并且随着文件的版本演化自动产生。基于上述构件与文件关系模型， 提出并实现了基于构件的软件版本管理系统。
2.2 构件的版本管理
（1） 以构件为粒度的版本管理特点
与 基于文件的版本管理相比， 基于构件的版本管理有以下主要特点： ¹ 构件的抽象级别比文件高。 构件是应用系统中可以明确辨识的构成成分。 记录、维护构件的版本比文件的版本管理更有意义。 º 构件的粒度可以比文件大很多。 一个项目中可能有诸多分布的逻辑单元， 这些逻辑单元与构件相对应。构件的数量较少， 而且整体逻辑意义明显， 可以更清晰地体现项目的演化历史。 » 在构件基础上， 可以体现出系统的层次性、构造性等特征。 同时， 构件版本管理也可以满足对文件版本的管理需求， 使版本管理既有大粒度， 又有灵活性。
（2） 构件版本管理的基本模式
基 于构件的版本管理系统采用/ 检出（ Check Out） 、修改、检入（ Check In）0 的基本操作模型， 操作的基本单位是构件。 使用者需要先将构件从版本库检出到工作区， 随后在工作区中完成对构件的修改， 最后将修改的结果检入版本库。 构件组成文件的增删以及其中任何一个文件的修改都被视为对整个构件的修改。 因此， 作为检入操作的结果， 版本管理系统会自动生成构件的一个新版本。 以构件版本为粒度的版本管理系统记录和管理了开发人员对构件修改的历史。
声明：本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人，不代表电子发烧友网立场。文章及其配图仅供工程师学习之用，如有内容侵权或者其他违规问题，请联系本站处理。 举报投诉
评论(0)
发评论
- 相关下载
- 相关文章
