（计算机应用技术专业论文）支持需求跟踪的版本控制技术的研究.pdf

摘要 摘要 经过多年的发展，软件开发的质量及效率有了较大的提升，但同时，软件开 发过程变得越来越复杂，因此开发中所产生的大量中间产品也越来越难以管理。 解决此问题的关键就在于加强软件配置管理，特别是作为软件配置管理核心的版 本管理，这也是软件业面临的挑战之一。经过多年理论和实践上的研究，版本管 理目前已建立起许多理论模型，并且在多年经验积累的基础上，产业界总结出许 多“最佳实践，这些“最佳实践在软件企业中得到了广泛的应用。 目前已提出的版本管理方法主要分成两大类：支持构件的版本控制机制和可 变粒度的版本控制机制。人们提出上述方法的目的是为了使版本管理能够更好的 适应软件开发模式的变化。但是，对于软件开发人员而言，除了需要使用版本管 理工具实现系统开发过程的重现，同时还需要获取需求、设计、代码问的关联关 系，以确保需求变更、调试软件、修改b u g 等过程中，能正确维护软件开发产品 间的一致性。但是，对这些需求可跟踪性的支持恰恰是当前的版本管理工具无法 提供的，因此软件开发人员只能借助其它专业需求管理工具的帮助来获取所需的 关联信息，大大增加了工作的复杂度，减低了开发效率。 本文通过对版本管理技术和需求跟踪技术的研究，提出了一个支持需求跟踪 的版本管理模型v c f m 。该模型的最大特色是将需求跟踪技术融入到版本管理机 制中，解决了传统版本管理工具无法跟踪需求关联信息的问题，为软件一致性维 护提供了更好的支持。利用所研究成果，实现了一个支持需求跟踪的版本控制工 具v c f q ，并给出了v c f q 的总体结构，各模块的设计，及原型实现。 v c f q 的设计特点是从软件开发人员的角度出发，维护其所需程度的需求可跟 踪性信息。具体表现为软件开发人员使用v c f q 对项目文档进行版本管理的过程 中，系统将自动记录功能需求、功能设计、代码文档间的版本关联关系，从而提 供关联信息的双向跟踪。 本论文关于支持需求跟踪的版本管理模型的研究将为提高软件开发效率和软 件可维护性提供理论与技术支持。 关键词：软件配置管理，版本管理，需求管理，需求跟踪 a b s t r a c t a r e r 也ed e v e ：i o p m e n tf 1 0 rm 锄y ”；a r s ，圮q u a l i 哆a i l de 简c i e n c yo fs o f t l a r e d e v e l o p m e n th a v eb e e n 黟e a n yi n l p r o v e d b u t ，m ep r o c 骼so f r w a r cd e 、r e l o p m e n ti s b e c 锄口血gm o r ea n dm o 舱咖p l e x a sar 刚t ，i t i sm o 陀d i 街c u l t 幻m a n a g e i n t e m l e d i a t ep i 山c t sp r o d l l c e di nt h ed e v e l 唧e n tp r o c e s s t h ek e yt 0s o l v em i s p b l 锄i se n l l a 埘：i n gs o r w a 舱c o n f i g u r a t i o nm a n a 差；e m 锄t ，e s 耐a u yi t sk e m e lv 习葛i o n m 纽a g e m e 武1 1 l i si sa l s o0 n eo fm ec h a l l g e so fs o f h a r ci l l d l i s 仃y b 勰e do nm e r e s e a r e hr l rm a i l yy e a 瑙，al o to fm o d e l s 雒l dp e r f b c t 枷c 岱h a v eb 嘲跚m m a r i z e d a 1 1t h e s e 砌c 、旧m 锄t sh 孙，eb 嘲w i d d ya p p l i e d _ i ns o 脚a r ee n t e f p r i s 铭 a tp f e s 即：t 岫a t w 0m a i n r t so f 俐o nm a n a g 锄衄to n ci st h em ec _ h a i l i s m 砌c h 刚p 9 叫s 唧n e n t 锄d 锄o t l l 盯i s 也em 洲s m 奶mv 碰a b l e 黟剃l 赫够 p e o p l ep i i tf o n 憎r dt h e m e t h o d st 0m a l 【ev e r s i o nm 趾a g e m e n ta d a p tm ec ：h a n g 髓o f t h es o f t w a r ed e 、同o p l n 髓tb e t t 贸。mf a c t ，f 1 0 rd e v e l o p e f s ，t 1 1 e y1 1 0 t0 1 1 l yu v t 习蛋i o n m a n a ；e m tt o o l st 0r c p d u c et l l es y s t 锄d e 、，e l o p 】 n tp r o c c s s ，b u ta l s on e e dt 0 a c q u i r e 硒s o c i a ：t i o n s 锄o n gm er e q i l i r e l n e n t s ，d 髓i 孕塔a 1 1 dc o d e s t 0e n s em e p r o d u c t s c o n s i s t e n c y b u ta 珊他n tv t 玎s i o nm 强a 净n e n tt o o l sc a n t 双l p p o r tr c ：q u i r e m e n t s 仃a c i 芏l g d e 、，e l o p e r sh a v et 0u o m 贫p r o f 醅s i o n a lr e q l l i 崩n e n tm a n 楚膨m 础t o o l st 0a c q u i r e 吐1 e s e 部s o c i 撕o nr e l a n o n 出p s s o 也ec c 舡l p l 嘲够o f l ed e v e l o p 懿w o f ki s 目e a t l y i i l c r e a s e da n dm ee 伍c i 饥c yo fs o 脚a r cd c v c l o p m 锄ti sd e c l m e da1 0 t b 嬲e do nt h er c 骶a r e ho f 也ev e 瑙i o nm 龇忸g e m e n tt e c h o l o g y 锄d l er e q l j i r e m e n t 缸a d n gt e c ：h i l o l o g 弘t b i sm 鼯i sp i l t s 姗a r dan e w v e r s i o nm 锄a 星；e m e n tm o d dv c f m ， 、) l ，_ kc ：hs i 唧p o n sr o q l l i l 叼m 钮t s 仃a c i n g i ti n 缸o d u c o dr c q u i r e m e n t 缸a c ：i i 坞i n t 0 l e 、r e r s i o n m 砒l a g e m e n tp r o c 鹪st 0s o l v e l ep 俩b l e mm a t 位狙i 石o n a lv e 稻i o nm a n a g e m e n tt o o l s c a i l tt r a l c em e 嬲s o c i 撕o no f p r o d u c t s n l i si s 廿l em o s ta 廿m c t i v ec o n t r i b u t i o no f v c f m m o d e la n da l s 0 缸圮近l o v 撕0 no fn l i s 出e s i s av e f s i o nc o n 昀lt o o lv c f qb 嬲e d0 n v c f mh 弱b e 饥r e a l 娩e d a n d 也i st h 鼯i sa l s op r e s 锄t sm eg e f a l 灿c t u r eo fv c f q ， t l l ed c s i 朗o f 嗍m o d l l l e 鹤w d l 弱m ep r o t o t ) ，p ei i n p l e m 删o n t h ec 0 i 蛐砸0 no f v c f qi st 1 1 a ti t 啪m a i 芏l t a i l l 的血gi 芏而咖撕o na c c o 幽gt 0 d e v e l o p e r s r a a u i 】瓶呦：t s w 1 1 i l ed e v c l o p e 璐u s i l l gv c f q t 0m a i l a g ep r o j e c td o c 啪e 1 1 t s ， n v c f qr e c o r d sm ea s s o c i a t i o i l s 锄o n g 劬甜o nr e q 洳e i l t s ，d e s i 印s 锄dc o d 锱a tm e s 锄et i i l l et os l l p p o r tb i d i r e c t i o n a l 台a c i l l 吕 t h er e s e a r c ho fv 习葛i o nm a n a g e m e n tm o d e lw i m r e q u i r c l n 伽她仃a c i l l gi nt h i sn l e s i s p r o m o t e sm ee 街c i e n c yo f t h es o r w a r ed e v e l o p m e n t 锄ds o r w a r cm a i n t a i l l a ：b i l i t ) rf r o m l em e o r ya n d t e 6 i l l l o l o g yp 唧c c t i v e k e y w o r d ：s o 胁a r ec o n f i 舀l r a t i o nm 孤豫g e m e n t ，v e r s i o nm 锄蜓；e i i l e n t ， r e q u i f e m 踮tm a n a g e m e n t ，r e 叩l i r 鼬e n t 缸a c i n g i i i 缩略词 缩略词 英文缩写英文全称中文释义 c i c oc h e c 蠹i i l c h e c ko u t 检入检出 c 删 c a p a b i l i 够m a t 嘣t ) rm o d e l 能力成熟度模型 c s f sc r i 6 c a ls u c ( 圮鹳e t 0 鹉 关键成功因素 ( 、伊s c 0 m p i i 锄眵v 酬f i c 撕o qp r o c e d i 】他 遵从验证过程 c v sc o n a l r r 锄tv 斑i 伽峪s y s t e m 并发版本系统 d a g d i r e c t a c y c l i cg n p h 有向无环图 e b te 、瑚s e d1 m c e a b i l i t ) r 基于事件可跟踪性 g g 1 邳h i c a lu s e rk t a f a c c 图形用户接口 h s t i t u t co fe l e c t r i c a l 觚de 1 仃o i l i 锚 e e 电气电子工程师协会 e n g i n 墙 r c si o nc o n 缸d ls y s t 锄 变更控制系统 r t 酗岫e n t s1 阳c e a ：b i l i 哆 需求可跟踪性 s c c ss o u r c e c o d ec 0 n 仃0 ls y s t e m 源代码控制系统 s c is o f h 唧r cc o n f i g l l r 撕o ni t e m 软件配置项 s c m s o n w a 心c o n f i g l l r a t i o nm a 姐g e m e n t 软件配置管理 v o b 、，酗i 蛆o b j e c tb a l s 铭版本对象库 v s s剐i a ls o i l r c es a f e 可视化源控制系统 v i 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工 作及取得的研究成果。据我所知，除了文中特别加以标注和致谢的地 方外，论文中不包含其他人已经发表或撰写过的研究成果，也不包含 为获得电子科技大学或其它教育机构的学位或证书而使用过的材料。 与我一同工作的同志对本研究所做的任何贡献均已在论文中作了明 确的说明并表示谢意。 签名： 窒! l 垒日期：沙易年多月刁日 关于论文使用授权的说明 本学位论文作者完全了解电子科技大学有关保留、使用学位论文 的规定，有权保留并向国家有关部门或机构送交论文的复印件和磁 盘，允许论文被查阅和借阅。本人授权电子科技大学可以将学位论文 的全部或部分内容编入有关数据库进行检索，可以采用影印、缩印或 扫描等复制手段保存、汇编学位论文。 ( 保密的学位论文在解密后应遵守此规定) 签名： 塑j 堕导师签名：霪刍豳 日期：即多年岁月刃日 第一章引言 1 1选题的背景及意义 第一章引言 近年来，软件开发的规模不断增长，开发周期越来越长，这使得开发过程中 产生的中间产品越来越多，产品间的关联关系越来越复杂。软件开发机构若想从 初始的混乱状态，过渡到可重用、可管理的有序化状态，进而上升到更高的成熟 度水平，有效的软件配置管理是最有力的支持之一【1 1 【2 】。 早在七十年代初期加利福利亚大学的l d 饥p r 嘲掰教授就提出控制变更和配 置的概念【3 1 ，之后又开发了自己的配置管理工具：c c c ，这也是最早的配置管理工 具之一【4 】。随着软件开发规模的逐渐增大，越来越多的公司和团队意识到了软件配 置管理的重要性，而相应的各种软件配置管理工具也纷纷涌现。这些软件配置管 理工具通过在特定的时刻标识一个软件系统的配置，即一组中间软件产品及描述， 系统地控制对配置的更改，在整个软件生命周期中很好地实现了维护配置的完整 性和可跟踪性【5 j 。 版本管理是配置管理的基础和核心【6 】【7 1 ，主要是对变更配置项的软件开发行为 和开发结果提供一个可跟踪的手段，避免软件行为在不受控制或出现混乱的情况 下进行，便于软件开发工作以基线渐进方式完成。目前已提出的版本管理方法主 要分成两大类： 1 ) 支持构件的版本控制机制【8 】：该方法提出了一种以构件为粒度的版本管理 方案，用于支持基于构件的软件开发过程中的资源管理和维护。 2 ) 可变粒度的版本控制机制 9 】：提出了将配置项分为实体配置项、复合配置 项的方法，用户可以根据需要合理组合配置项，解决了不同规模的软件开 发过程对软件配置项粒度有不同需求的问题。 人们提出上述方法的目的是为了使版本控制机制能够更好的适应软件开发模 式的变化，但是在这些方法都没有提供对需求可跟踪性( r e q u i r 锄e 1 1 t s t r a c e a b i l i 坝r t ) 的支持【l o 】，这使得开发人员无法通过版本控制工具获取软件产品间 的关联信息，增加了产品一致性维护的难度。 为此本论文在国家“8 6 3 刀项目面向家电的嵌入式系统公共技术平台研究 的支持下，提出了一种支持需求跟踪的版本管理模型，在传统的版本管理模型中 电子科技大学硕士学位论文 引入需求跟踪技术，它使开发人员在对需求文档、设计文档、代码进行版本控制 的同时还可以双向跟踪这三类软件产品间的版本关联关系。该模型即确保了开发 人员能够正确获取所需程度的需求跟踪信息，又避免了使用专业化需求跟踪工具 额外增加的复杂性，增强软件可维护性的同时，提高了开发效率。 1 2国内外研究现状 1 2 1 版本控制机制 版本管理的研究是基于软件配置管理的。 国外软件产业界在软件配置管理这个专题上已经进行了多年理论和实践上的 研究。建立了许多的理论模型，并且在多年经验积累的基础上，产业界总结出了 许多“最佳实践”e s tp r a c t i c e s ) ，这些“最佳实践”在软件企业中得到了广泛的 应用。 目前市场上有上百种配置管理工具，其中比较流行的有m i c r o s o f t s u a ls o u r c c s 娟。i s s ) 、c o n c l 盯即tv e r s i o n ss y s t e m ( c v s ) 、r a t i o n a lc l e a 疋a s e 等。 这些配置管理工具面向软件规范化、工程化、自动化的需要，解决实际工作 中的问题，帮助开发团队提高科学管理水平，从而提高工程效率，降低工程成本。 在国内，对软件配置管理的研究还很少。由于起步晚，很多企业没有实施软 件配置管理，或者是仅仅实施了非常简单的代码管理。即使是实施了软件配置管 理的企业，也没有把它放在一个很重要的位置。 不过，这一状况正在改善。随着软件配置管理的重要性逐渐地被认识到，许 多机构都已开始着手对其进行研究。北大软件工程研究所正在研究基于构件的配 置管理并开发了相应的软件配置管理系统j b c m 【8 】：华中理工大学正在进行集成的 配置管理系统的研究并开发软件配置管理系统h s c m s 【l l 】；上海复旦大学正在开发 的可变粒度配置管理工具w 聪g c m 【9 】【1 2 1 。虽然目前国内掌握软件配置管理要领的 人不多，尚无真正建立起有效的管理体系的企业，但随着越来越多的企业实施 c m m ( c a p a b i l 时m a n l r i 锣m o d e l ) 或者是其它软件工程标准【1 3 】，软件配置管理正在 成为下一个软件业的热点。国内软件企业也越来越多地实施了规范的软件配置管 理。 软件配置管理工具的发展总共经历了三代【l 】【1 2 】，与第一代、第二代配置管理系 统相比，第三代配置管理系统在版本控制机制的研究上取得了新的进展。具有代 2 第一章引言 表性的主要有两种：支持构件的版本控制机制和可变粒度的版本控制机制。 1 2 1 1支持构件的版本控制机制 支持构件的版本控制机制提出了一种以构件为粒度的版本管理方案，用于支 持基于构件的软件开发过程中的资源管理和维护。传统的版本管理是以文件作为 管理的基本粒度，版本管理系统记录、维护每个文件的演化( e v o l u d o n ) 历史，而在 大型的软件开发中，系统往往包含很多文件，这使得传统方式版本管理的工作量 很大，效率低，而且不易于描述文件问内在的组合关系。而在基于软件的构件开 发中，构件作为系统的有机构成成分，在物理上可以表现为多个文件的集合体， 而在开发过程中作为一个基本开发单位使用。系统的开发者关心的是构件整体的 开发、演化、组装和维护。根本不用考虑到文件这个层次，用更高的抽象层次降 低了复杂性，使问题变得易于管理。 与基于文件的版本管理相比，基于构件的版本管理有以下主要特点【1 4 1 5 】： 1 ) 构件的抽象级别比文件高。构件是应用系统中可以明确辨识的构成成分。 记录、维护构件的版本比文件的版本管理更有意义。 2 ) 构件的粒度可以比文件大很多。一个项目中可能有诸多分布的逻辑单元， 这些逻辑单元与构件相对应。构件的数量较少，而且整体逻辑意义明显， 可以更清晰地体现项目的演化历史。 3 ) 在构件基础上，可以体现出系统的层次性、构造性等特征。同时，构件版 本管理也可以满足对文件版本的管理需求，使版本管理既有大粒度，又有 灵活性。 1 2 1 2可变粒度的版本控制机制 可变粒度的版本控制机制【1 6 1 提出了将配置项【6 】分为实体配置项、复合配置项的 方法，用户可以根据需要合理组合配置项，解决了不同规模的软件开发过程对软 件配置项粒度有不同需求的问题。 该机制的特点在于提升了管理粒度。配置项是对最基本的项目组成元素( 各 种文档、源文件、文件夹等) 进行的初次封装。将项目组成元素检入到资源库中 时，就将其封装成为配置项。将配置项划分为原子配置项和组合配置项，通过创 建配置以及对特定配置进行标识，在更高粒度级别上，对特定配置中所有配置项 进行管理。 当开发过程的某阶段达到成熟时，可以设立特定配置的组合一基线【5 】( 阶段里 3 电子科技大学硕士学位论文 程碑) 对阶段开发的所有成果进行整合。一旦基线设立，则变更操作必须遵循已 定制的标准变更控制流程。开发结束后，可以通过版本发行( 基线的组合) ，对整 个项目产品进行整体管理。通过对项目组件不同粒度的多层次封装，来实现可变 粒度的软件配置管理。 1 2 2 需求跟踪 需求跟踪是需求管理的基础，同时也是需求变更控制的基础【1 7 1 8 】。对一个软 件项目来说，当需求确定下来以后，应该保证在软件设计过程中每个需求都能够 被实现。因此，一个比较好的方法就是建立一种跟踪机制来确认所有需求在每个 阶段是否已经实现，这就是所谓的“需求跟踪 。 需求跟踪是跟踪一个需求使用的全过程，也就是从最初的用户需求到设计实 现的整个生存期。需求跟踪的目标是获取系统开发过程中各阶段性产品间的关系， 从而加深对系统的理解以及提高系统生命周期中各项活动的效率。 但是，由于系统庞大的信息量和系统分析、设计和开发的阶段性产品之间错 综复杂的关系，以及系统的整个生命周期中需求的不断变化，使得收集、更新和 管理l 玎信息的工作既费时又费力，这些都对需求跟踪的实践增加了难度。 为了获得足够的r t 信息，并解决由于r t 信息不足带来的项目超支甚至失败 的问题，一些研究者提出了不同的跟踪用户需求的方法，包括i 玎参考模型，基于 事件的可跟踪性方法和r t 复原方法等【1 9 】，但这些方法都没有很好的解决以下3 方面的难题。 1 缺乏获取足够必要的i 玎信息的能力 不同的项目参与人员在系统开发的生命周期中需要不同的i 玎信息，由于目标 和优先权不同，因此他们对可跟踪性的要求也不同，经常从不同的角度获取和使 用r t 信息。但由于获取i 玎信息的项目参与人员可能不是实际使用它的人( 例如 系统维护人员) ，所以获取足够必要的r t 信息变得非常困难。 2 获取并管理可跟踪性关系既耗时又昂贵 获取大量的l 玎信息非常耗时而且代价昂贵。为了获取、记录、组织和管理必 要的信息，不同的职位需要分配不同的任务。另外，管理可跟踪性机制的最大挑 战是被跟踪的阶段性产品在系统开发过程中不断修改和变化，随着系统的规模和 复杂性的增加，各阶段性产品数量的增加，各种关联关系的数量将呈指数增长。 因此，那些管理r t 信息的人员不得不投入大量的时间和精力去更新这些不断变化 4 第一章引言 的关联关系。 3 必须使用专业化工具 因为获取和使用r t 信息不同于软件工程的其它任务，目前必须使用专业化的 工具记录、管理、跟踪和分析更新的影响。这些不同的专业工具带来了新的问题， 那就是人们不得不去参加培训以便懂得如何使用它们，这样就分散了人们从事r t 实践的精力。 1 3主要研究工作 本课题来源于广东托思软件科学园合作项目 l o c k 。即在某人检出使用该配置项 时，对该配置项加锁；当修改完成并检入到配置库之后，解锁。这样的过程一直 反复下去。图2 6 是访问和同步控制的流程图。 配置对象乏黔配置对象 氆参改版才窆u n l o c k 1 2 - 1 3 。 为每个文件打上的版本号 同一项目可以包含多条基 分支开发：在基线的基础上可以进行分支开发。如基于基线“1 2 建立的第 一条分支，其分支号为“1 2 1 ”，该分支中所有文件的初始版本号均为“1 2 1 1 ”， 若文件e d i t c 在基线“1 2 中的版本号为“1 6 ，则将“1 6 记录到e d i t c 的分支 版本“1 2 1 1 ”的参照版本属性中。可以基于同一基线创建多条分支，分支号的演 化方式为1 2 1 - 1 2 2 - 1 2 3 。 第四章基于v c f m 的版本控制工具的设计 4 3 1 2 版本检入 版本检入的主要功能是在文件内容更新后将其提交到仓库，并生成新的版本； 如果需要，可以为项目制定新的基线。 该部分主要包括3 个子功能：提交已有文件、提交新文件、制定基线。 1 提交已有文件 1 ) 完成的工作 a ) 对仓库中存在的文件更新后提交，并生成新的版本。 b ) 当用户完成对仓库中文件的更新后，在没有冲突的情况下提交此文 件，并生成该文件新的版本。主干开发时如文件当前最新版本为“1 3 ， 则在无冲突的情况下，更新后生成的版本为“1 4 。 2 ) 参数介绍 曲要提交版本的文件名 b ) 文件的功能标签 c ) 用户d d ) 提交的文件处于主干或分支开发的标识符( 根据用户d 查u s 甜i s t 表 获得) 主干开发的标识符：“l ；分支开发的标识符：分支号 2 提交新文件 1 ) 完成的工作 a ) 当用户提交一个仓库中不存在的新文件时，系统自动生成该文件的绝 对版本；如果提交的文件处于主干开发，则生成的版本号为“1 1 ， 如果处于分支“1 2 3 开发，则生成版本号“1 2 3 1 。 2 ) 参数介绍 a ) 该文件在用户机上存放的位置 b ) 文件的功能标签 用户d d ) 提交的文件处于主干或分支开发的标识符( 根据用户i d 查u s 甜i s t 表 获得) 主干开发的标识符：“l ；分支开发的标识符：分支号 提交文件的流程如图4 2 所示： 4 7 电子科技大学硕士学位论文 图4 - 2 文件提交流程图 3 制定基线 1 ) 完成的工作 a ) 先进行用户身份判断( 只有项目管理员用户才有此项操作的权限) 。 b ) 保存用户指定的主干文件版本的集合，其中同一个文件只能选择一个 版本。 c ) 生成一个新的基线号，并将用户指定的文件集合中所有文件的信息记 录到该新基线下。 第四章基于v c f m 的版本控制工具的设计 d ) 基线制定成功后，将所有基线下的文件信息显示给用户。 2 ) 参数介绍 a ) 用户在文件信息表中所选择的文件 4 3 1 3 版本检出 版本检出的主要功能包括3 个：提取单个版本、制定分支、提取初始分支。 1 提取单个版本 提取文件单个版本的流程如图4 - 3 所示： 1 ) 完成的工作 图4 3 文件单个版本提取流程图 4 9 电子科技大学硕士学位论文 a ) 检出单个文件。将用户指定的文件版本提取出来，并且存放到用户指 定的位置。 2 ) 参数介绍 a ) 文件版本号( 默认情况下为文件的当前最新版本) b ) 文件名 c ) 用户处于主干还是分支开发的标识符( 主干开发时为：l ；分支开发 为：分支号；通过查找1 l s 甜i s t 表获得) m 用户指定的文件存放路径 2 制定分支 1 ) 完成的工作 a ) 检出指定基线的副本 b ) 将用户指定基线的副本保存到仓库中指定位置处( 该位置由系统指 定) ，以供用户进行分支开发。如指定的基线为“1 3 ，则将基线“1 3 ” 下所有的特定版本文件提取出来存放到新建的分支目录中，以供用户 进行分支开发。 2 ) 参数介绍 a ) 项目名( 项目管理员提供) b ) 基线对应的版本号 c ) 给主干建立分支的标识符；标识符为：“1 ” 3 提取初始分支 1 ) 完成的工作 a ) 检出用户指定分支的基线副本。 b ) 将用户指定分支的基线副本检出到用户机上，如当前工作人员的开发 是基于主干“1 3 的分支“1 3 2 开发，则将该基线“1 3 ”的副本 下载到用户机上。 2 ) 参数介绍 a ) 用户机上用来存放基线副本的全路径 b ) 分支号( 根据用户i d 查找l l s 甜i s t 表获得) c ) 用户检出分支的标识符；标识符为：“2 4 3 1 4版本的创建与删除 完成配置项新版本的创建及任一版本的删除。 第四章基于v c f m 的版本控制工具的设计 版本的创建分3 类情况： 1 ) 创建新配置项的时候，版本就为绝对版本1 1 。 2 ) 配置项被检入时，版本可能朝纵向或横向演化。 演化规则是： a ) 如果配置项是被互斥写检出，版本朝纵向演化。 b ) 如果配置项是被共享写检出，版本朝横向演化。 c ) 如果配置项是被只读检出，版本不演化。 3 ) 在分支中，配置项的版本朝横向演化。 版本的删除：版本允许拥有一定权限的使用者手工删除，其它用户无权删除 版本。 4 3 1 5版本比较流程 基于创建的差量文件，v c f q 可以获取文档任意版本问的差异。 如比较某一文档x 的1 7 版本与1 3 版本间的差异，具体流程如下： 1 ) 获取版本1 3 的全文，另存为文档y ，在每一行的起始处打上标记：“$ $ 行号一。 2 ) 将版本1 3 到版本1 7 所需的更新次数4 记录到变量c y c l e 中。 3 ) 提取x 的差量文件。 4 ) 定位版本1 4 的更新记录，将变化的内容插入到y 中。假设更新记录为： $ c a n c e ll i l l es 眦： 2 ，2 i n t j = 0 ： 面n 圾”l ev a l u 馏o f ii s ：d ，i 勺) ； $ c a n c c m 锄d ； & a d d l i n e s t a r t ： | | 历岁 i n t j = 2 ； i _ j ； p r i r 呶竹t 量l ev a l u c so f ii s ：d ，i ) ； & a d d l i n e 伽d ； 则y 更新后的内容为： $ $ l ： 5 1 电子科技大学硕士学位论文 $ $ 4 ：； $ $ 5 ：； i i i t j = 2 ； i _ j ； p 血t 坟”m ev a l u 昭o fi i s ：d ”，i ) ； $ $ 6 ： $ $ 7 ： ； ； 5 ) 重复步骤4 ，直到将版本1 7 的更新记录插入到y 中。 6 ) 逐行读取并分析文档y 。分析规则包括以下两点： a ) 若读出来的行不是以“$ $ ”标记开头，则说明该行在版本1 7 中存在， 在版本1 3 中不存在，将该行内容输出。 b ) 若相邻两行“$ $ 标记后的行号分别m 、n ，当m n 的绝对值大于l 时，则说明版本1 3 中m + l 行到n 一1 行间的内容在版本1 7 中已被删 除，将此部分内容输出。 4 3 1 6分支合并管理 分支合并管理是用一定的策略来有效地控制由于并行开发产生的多分支问题 带来的版本维护问题。 分支合并操作是基于版本比较功能实现的。用户可以通过在不同分支上选择 不同版本来进行合并。系统为用户提供三类信息： 1 ) 分支一中所选版本独有的文件； 2 ) 分支二中所选版本独有的文件； 3 ) 两个分支中需要合并的文件及对应版本。 4 3 2 数据库表 1 c v s t a b l e 表 该表是系统中所有文件信息的集合，保存了文件的全部信息。 5 2 第四章基于v c f m 的版本控制工具的设计 表4 2c v s 龇表 列名 属性类型 长度说明 e d i t i o nd h a r1 0 文件的版本号：主键 f i l e n 锄ec i l a r2 5 文件名；主键 p a n l n 锄e v a f c h a r1 5 0 文件差量存放的全路径 c o m e d i t i o nc h a rl o 文件的参照版本号 b r m c hc h a f1 0 文件的分支标记( 主干开发时为o ； 分支开发时为分支号) u s e d dc h a f2 0 用户名 c o m p u t e r i d c h a r2 0 用户的计算机名 t i m e i dc _ h a f2 0 用户提交此文件版本的时间 t a g c ! h a r2 0 该文件版本的功能标签 差量文件包含的内容分两种不同情况： l ) 在主干上开发的文件，其差量文件包括源文件初始版本的全部内容和其后 继版本与它们对应父版本间的差异。 2 ) 在分支上开发的文件，其差量文件包括源文件的参照版本的全部内容和参 照版本在该分支上的后继版本与它们对应父版本间的差异。 源文件的任一版本都是通过差量文件推导得出的。 2 o f f s e t d i r 表 该表记录了仓库中项目的主干存放路径，以及各个分支目录的存放路径。 表4 3 0 伍沦t d i r 表 列名属性类型长度 说明 。丘e t c ：h a r1 5 分支号( 主干开发时为1 ) ；主键 a a i nc h a r1 0 分支所属的基线号( 主干开发时为 0 ) d i r c c t o r y v a r h a r1 0 0 主干分支目录的存放路径 3 n e w v 昌r i s o n 表 该表记录了主干和各个分支上的每个文件最新版本的信息。 表“n 郫i o n 表 列名属性类型长度说明 v e r s l o nc ：h a r2 0 文件最新的版本号；主键 f i l e n 锄ec h a r2 5 文件名；主键 b r 姐c hc h a r 2 0 文件所属的分支号( 主干为o ) p a m v a t b a r 1 5 0 文件最新版本的全文存放路径 4 a d 缸p r o j e c t 表 该表用于记录每条基线下的文件信息。 电子科技大学硕士学位论文 表4 5 舳蛔e c t 表 列名 属性类型 长度 说明 p r o j e c t i d c h a r2 0 基线号；主键 f i l 锄e c h a r 3 0 文件名；主键 丘l e v 粥i o nc ! h a f2 0 文件版本号 u p i d a t e p a m v a r c h a r1 5 0 文件差量的存放路径 l a t 嚣t p a t l l v 卸池瑟1 5 0 文件最新版本的全文存放路径 s d b d i r e ：t o 巧 v a r c h a rl o o 文件所属的子目录名 5 慨表 该表记录文件在每次提交时的文件信息，主要用来帮助项目用户回退。 表4 6 慨表 列名属性类型长度说明 v e l s l o nc h a r1 5 文件版本号 f i l a l 锄ec h a r3 0 文件名 u s e d d c h a r3 0 用户名 审a m o m 珞e r v a 砒a r1 0 0 文件在用户机上的存放路径 4 4需求跟踪模块 4 4 1 关联关系的建立与存储 在对文档进行版本管理的过程中，为了能使系统自动记录文档间的关联信息， 实现功能需求、功能设计、代码文档间的双向跟踪，需要设计数据库表，在文档 版本创建或更新提交时，将跟踪所需的关联信息自动记录到对应表格中。 1 表一：f u n 以0 n 嘲u n m e n t s 记录所有功能需求条目文档的版本信息。每一个功能需求条目文档在表中可以 对应多条记录，每条记录代表一个特定版本。 表4 - 7f u n c t i 锄r e q u i r e m t s 表 列名属性类型长度说明 缸嗍m v ar j c _ h a rl o 功能需求的d 号：主键 n mr e qn 锄ev a r c h a r5 0 功能需求条目文档的名称 f r u n 联目v e f s i o n v a r c h a r1 5 功能需求条目文档的版本号 a c 6 v ec _ h a r1 文件有效性标识符：为l 时文件有 效；为0 时文件无效 2 表二：f u n c t i o i l - j e s i g 衄 记录所有功能设计条目文档的版本信息。 第四章基于v c f m 的版本控制工具的设计 列名 属性类型长度说明 f i l n d 懿d v a 珧a r 1 0 功能设计的d 号；主键 矗盟d ；e 职m e v a r c h a r5 0 功能设计条目文档的名称 f i m ：d e $ ：、，e f s i o n v a “妇1 5 功能设计条目文档的版本号 a c d v ec h a rl 文件有效性标识符：为l 时文件有效； 为0 时文件无效 3 表三：r e q ! i r _ e m t s 狃dp 嘲g 陷 记录所有功能需求条目文档与功能设计条目文档间的版本关联信息。每一个 功能需求条目文档的任一版本可以关联一个或多个功能设计条目文档的特定版 本。同一个功能设计条目文档的某一特定版本也可以被多个功能需求条目文档的 特定版本所关联。二者是多对多的版本映射关系。 列名属性类型长度说明 舢搠d v a r c h a rl o 功能需求的d 号；主键 f h n = 蛔n 锄e v a r i 妇5 0 功能设计条目文档的名称；主键 f i l n 姬：、，懿i o n v a r c h a r1 5 功能设计条目文档的版本号 a c t i v ec h a rl 文件有效性标识符：为l 时文件有 效；为o 时文件无效 3 表四：d 确鲫s 锄d ! c o d e s 记录所有功能设计条目文档与代码文档间的版本关联信息。由该表可以获取 与任一功能设计条目文档任一版本相关联的所有代码文档的版本信息。反之亦然。 表禾1 0 d 商驴s 锄删髂表 列名属性类型长度说明 f i m d e sdv a r c h a f1 0 功能设计的d 号；主键 c o d e sp a m e v a r c h a r5 0 代码文档的名称；主键 c o l d 鹤v e 两o nv 砌a r1 5 代码文档的版本号 a c 帆c ：h a rl 文件有效性标识符：为1 时文件有效； 为0 时文件无效 数据库表间关联关系如图似所示： 5 5 电子科技大学硕士学位论文 f u n c t i o f u c q u i r 锄e n t sd e s i 印s _ a n d j ：o d c s 功能需求i d ：v a r c h a n l o ) 功能需求条目名称：v u 屺h a r ( 5 0 ) 功能需求条目版本号：v a r c h a r ( 1 5 ) a c t i v c ：c h a r ( 1 ) 功能设计i d ：v a r c h a r ( 1 0 ) 代码文档名称：v a r c h _ 戳5 0 ) 代码文档版本号：v a r c h 气r ( 1 5 ) a c t i v e ：c h a r ( 1 ) r c q u 眈m e n t s _ a n d e s i 印sf u n c t i o n j e s i g n s 功能需求i d ：v a r c 砘r ( 1o ) 功能设计条目名称：v a i 配 l 气r ( 5 0 ) 功能设计条目版本号：v j u 配h a r ( 1 5 ) a c t i v c ：c h a r ( 1 ) 功能设计d ：设c h a 剐l o ) 功能设计条目名称：v a r c h 气r ( 5 0 ) 功能设计条目版本号：u 屺删1 5 ) a c t i v c ：c h a r ( 1 ) 图4 4 数据库表属性映射关系图 1 、) 功能需求的每个版本对应表一中一条记录，功能设计的每个版本对应表三 中一条记录，每个代码文档对应表四中一条记录。 2 1 表一、表二由属性域功能需求l d 相关联，记录了与功能需求条目文档x 的版本n 相关联的所有功能设计条目文档名称及其版本号；表三、表四由 属性域功能设计i d 相关联，记录了与功能设计条目文档y 的版本n 相关 联的所有代码文档名称及其版本号。 数据库表的各条记录由命令驱动生成，命令选项与命令参数所表达的含义如 表4 1 1 所示。 表4 1 1 命令选项和命令参数含义 命令选项命令参数说明 一x 提交一个功能需求条目文档 一s 功能需求名：版本号提交一个功能设计条目文档 一c 功能设计名：版本号提交一个代码文档 系统自动记录关联信息的方式如下： 1 ) x ：提交一个功能需求条目文档。 a ) 首次提交文档：系统将在表一中为该功能需求条目文档新建一条记 录，文档版本号和功能需求i d 号由系统自动生成，a c t i v e 域的值默认 为1 ( 表示该文档可用) 。 b ) 更新文档：将一个功能需求条目文档x 的版本由n 更新到n + 1 的过程 如图4 5 所示。若查表二得到一条表示x 的版本n 与功能设计条目文 档y 间关联关系的记录a ，且a 中属性域功能设计条目文档版本号的 值为t ，则在表二中新生成一条表示x 的版本n + 1 与y 间关联关系的 5 6 第四章基于v c f m 的版本控制工具的设计 记录b 。新记录b 中，属性域功能需求i i ) 的值设置为x 的版本n + 1 在表一中获得的i d 号；属性域功能设计条目文档名称设置为y ；属 性域功能设计条目文档版本号设置为t ，a c t i v e 域的值默认为1 。 图铀文档更新过程图 2 ) 命令参数用于说明与该设计条目文档相关联的功能需求条目文档的名 称和版本号( 默认情况下为该功能需求当前最新版本) 。 操作流程如图4 6 所示： a ) 系统在表三中为该设计条目文档新建一条记录，该记录中功能设计d 和功能设计条目文档版本号的值由系统自动生成，a c t i v e 域的值默认 为1 。由于同一个设计条目文档可能与多个功能需求条目文档相关联， 则将所有的关联参数( 功能需求名：版本号