clearcaselt配置

bmccbj

103
更请求和生命周期模型。以下是详细描述。
a.环境管理
PowerFrame[13]是专为计算机辅助工程/设计领域而设计的系统。
对于用户，它实际上是把文件系统和配置管理底层的细节屏蔽起来。用
户只能够看见和他们特定工作领域相关的，一个电路设计的世界，而
PowerFrame 管理工作中的上下文。项目的数据不是隐藏在目录里而是显
式地用图形表示出来。贯穿整个工作过程的始终，PowerFrame 提供工作
流管理，来引导团队的成员。例如：工具—运行可能涉及电路的生成，
置电路有效，然后通过进行仿真来决定他们的性能特点。在这一串的动
作中，PowerFrame 自动根据工具—运行提取相关的上下文，诸如数据集，
命令文件和激活工具的选项等等。 等下一次，用户仅仅需要选择电路
设计和工具功能就能开展工作。用户所看到的是：针对特定任务的合适
的工具，特定的数据表示表格：如逻辑图和布局设计；与特定任务相关
的数据；和特定工作领域相关的命令表。用户可以在不同的尺度上执行
不同的动作：如上下文数据中一个简单的数据项或者到整个配置管理。
用户不必去操心象版本控制或文件之间的关系等这些任务，因为在屏幕
背后，系统知道如何从不同版本的电路设计提取数据，系统完成了这些
任务。从效果上来看，配置管理系统针对特定工作领域捕捉用户工作的
上下文，通过这样的方式减少了用户的工作，如记住如何到达某个具体
工作状态，所有的数据项和它们的关系是什么等。
b.约定
ISTAR[9]环境根据正式的约定提供对部分软件开发过程的建模。所
谓约定是指指定输入和输出条件下任务的执行。约定的产物被记录下来

bmccbj

104
作为配置项。一个约定把信息流，包括从任务的开始到完成，任务之间
结果的传递和产品中组件的传递，进行建模。并且，约定之间也是可交
换的。怎样来满足约定呢？约定的满足是根据一定的接受标准，把输出
传递给过程模型中的特定的元素，如生命周期的不同阶段，或人等。约
定的产物活动被随后记载下来。因为不同的约定产物（如通信）会被记
载下来，所以约定中的工作过程是被监视的。从效果来看，约定表示一
个工作团队在一个配置项下的正式计划和记录。
c.需求变更
在LIFESPAN中,软件需求变更表现在文档的需求变更和相关过程模
型的变更。LIFESPAN 通过一系列的表单来实现需求变更的建模,在通过
一系列状态,任务和角色来实现过程的变更。客户可以提交用来确认错
误或请求为组件版本升级的在线软件性能报告。这就允许此报告能被反
馈给那些可以诊断出此问题的原始设计和编程人员来研究。对于软件性
能报告和改变冲突分析的反应,一个在线的设计变更被提交表决。确切
的说这就详细到什么组件被改变和怎样改变的问题。LIFESPAN 分析了谁
将会被此变化影响。然后那些人就会被自动的选出组成控制变更委员
会。关于设计变更的报告将会通过电子邮件来通知他们，不管他们是否
同意这些变更，都必须在一定的时间内对此做出表决。一旦设计变更被
通过，一种可变更的代码的新开发版本就产生了。则设计变更就此开始
使用而那种代码的变更就被锁定。在变更完成后，新的版本形成了，需
要被提交给具有QA 特权的人来检测并批准。经过批准后代码变更就需
要一种确认状态，设计变更的状态也变为确认的，有关的用户就被通过
电子邮件来通知一种新的版本可以使用了。用户收到软件状态报告表，

bmccbj

105
这就取消了原始的软件性能报告。因此，软件性能报告，设计变更和软
件状态报告不仅为用户和维护人员提供了一种交流的方式，而且体现了
这种特殊变更需求的历史变更；在过程中变更的状态报告；变更完成的
最终审计结果；改变冲突分析的机制和确保相关人员按时完成任务。结
果需求变更就促成了那种变更的过程。
d.生命周期模型
变更和配置控制提供了对一种特殊的生命周期模型的理解，此模型
在某种程度上支持一个生命周期中的各阶段及人员之间的转变，而那些
任务和数据管理能在那些阶段被执行。他通过把这些阶段分为对产品的
开发，测试，鉴定和推出来实现。这种划分允许象软件工程师和测试员
这样不同种类的使用者能够在同样的代码下同步的实行他们的工作。阶
段和独立工作的划分及其间的转变通过贯穿于代表每一阶段的独立配
置的代码来实现。就是说，产品作为一系列的基线被开发。每一基线存
在四种配置：开发，测试，鉴定和生产。配置是组件的一个层次。每一
基线包括一种特殊的方法。代码的开发就是开发配置，通过反复对配置
进行的测试，然后确认配置，最后生产顾客使用的配置产品。为了顺利
到达下一阶段，交互作用的草案必须要被不同的用户（例如项目经理和
测试经理）批准这一转变。任何时候，对于一组件所通过的标准是由他
所属的配置体现的。结果，生命周期模型经过不同的配置状态被实现。
D. 结构和解释的概念
所要了解的概念是：选择一种结构的组件；获得一组件和其结构的
变更；描述一产品的结构；存取这种结构；构造这种产品以及保持这种
结构的各个部件的一致性称之为变化集，系统建模，子系统，对象池，

bmccbj

106
属性和一致性维修。见下述。
a.修改集合
ADC 把在数据库中的一个基本概念 — 各部件之间的版本的不同
— 抽象成一种不同的关系，这种关系对于用户是可以访问的。这样不
同的关系伴随着与之相匹配的文件以及其它变化的细节组成了变化集。
ADC 把变化构造成变化集中的配置，变化集可用来构造某种配置的定制
外形。这种变化集有一个名字，这意味着它可用在操作中，用户制定一
个公式来创建某个配置的特殊实例。这个公式指定一个被选中的变化集
都适应的基本线。一个变化集可视为与以前的变化集是相联系的（即版
本的历史的延续）或是相互独立的（即历史版本的可选部分被应用），
特别是变化集。 因此，用户要么从最延版本中工作，要么在一种配置
定制版本下工作。由于某些变化以及谁，何时引起的这些变化等细节，
这个变化集可以捕获对在某个配置中所有文件的变化。用户指定这种变
化的范围，ADC 自动的纪录这些变化的细节。例如，由于一个错误用户
想使主要变化适合某种配置。用户指出一个变化集，对这些文件做出许
多变化。在这个变化集中被捕获的：由于对在配置中所有文件做出的变
化所有原代码都得改变（在这个配置中对每个文件来说是不同的）；所
有有关文件的改变；以及谁，何时做出的改变。当用户浏览每个文件或
变化集时可以看见很多信息。总之，变化集表示对某种产品和创建一个
配置的各种版本方式的逻辑变化。此配置不必依赖于本配置的最新版本
信息。
b.系统模型
系统建模用来描述软件产品—软件产品的结构﹑组件和如何组建

bmccbj

107
它。Jasmine 系统建模就是用户能变更的文本描述以及一些工具可以用
这些描述来存取完成他们的任务。Jasmine 系统建模是由体现以下四类
信息的集和函数来描述的：（1）组件产品的关系，（2 ）绑定的信息版本，
（3）构造规则，（4）验证规则。关系描述为象子组件等级的产品模块
的分解，产品的独立性（比如模块组建的顺序）和基于属性的组件组（比
如各种资源和对象模块的分组）。通过关系描述的产品称之为模板且获
得它的结构。通过这些函数操作和关系用户可以使用简单关系定义复杂
关系。这就能使Jasmine 工具来解决用户定义的查询，比如：通过改变
一个特定的组件来影响那个组件。系统建模包括进一步了解该产品系列
的历史。此系列产品描述了该产品的后续版本。某种产品的用户指定的
版本构成了一个产品系列。和每一版本关联的是创建日期﹑作者等属
性。构造规则记录了现有的组件是如何生成的和将来的组件是如何构造
的。比如记录编译器﹑版本和所需的编译选项 。验证规则指定合和记
录对产品的结构和组织的限制比如资源和绑定模块必须匹配（意思是所
有的绑定模块都是由那些资源模块编译而成的）为了选择一种组件版
本，用于系列的选择方式是避免使用体现查找模块路径的内容来评估
的。被选定的结果模块易把图像的数据对象当作一种模块。象浏览器﹑
模块查看器﹑调试器和模块间的分析器等工具能引用和处理系统建模。
最终，系统建模是来自于实例产品的抽象，为了全面描述产品，系统建
模用工具来维护产品的完整性。
c.子系统
Rational环境提供了把一个很大的Ada产品分成多个小模块以及限
制变更影响范围的功能。这些小模块被称为子系统，子系统包括接口说

bmccbj

108
明书和实现主体并指出配置项目，因此，他们可被看为一个整体并通过
他们的名称被评价。在一个子系统内的组件不可被其他子系统内的组件
所访问除非为了被输出而通过接口说明书将这些组件指明。Rational 环
境检查实现主体完全匹配上接口说明书所需的运行时间。结果是，工作
可以在实现主体上展开而独立于当用户想用时就可以被改变的接口说
明书，到接口被改变时仅针对那个子系统中的组件会发生二次编译。这
时使用了这个接口产品的任何模块都将进行二次编译。对一个接口说明
书所作的更改可能需要整个产品进行二次编译。子系统对其组件进行了
版本控制，子系统本身可以是一个特定版本。用户可以用过组合匹配系
统的版本来形成该品的一个特殊产品。概括的说，子系统为用户指示了
一种方法，它限制了变化和二次编译所带来的影响，并提供了检查一个
产品的各组成部分的有效性的环境。
d.对象池
运用系统建模的概念，DSEE 已拥有一切必须的信息，此信息能够确
认产生一个生成对象的特殊版本需要些什么。生成的对象被放置在用户
们共享的对象池中。一旦用户暗示了对对象属性的需求DSEE 就能够共
享。被产生的对象池包括一个由转换工具生成的二进制代码和其它对象
组成的集合。每一个被产生的对象和其所有的信息有联系,而这些信息
是关于其包括原始版本的系统建模和与转换项一起使用的转换工具,被
包括的用户注释的出处﹑日期﹑时间﹑人员和引出的位置.这个信息被
认为是一个BCT.当DSEE构建一个系统时,会为系统中每一个组件计算需
要得到的BCT 数。DSEE 在对象池中查找来看生成的对象和所需的一个已
存在的对象是否匹配。如果匹配，它就被用；如果不匹配，它被构建。

bmccbj

109
因此，任何时候一个用户需要一个特殊的生成对象时（或是一个一致的
对象）。DSEE 能够从对象池中再使用从而消除了生成这个对象的需要。
用户不需要知道生成现存对象要做的；DSEE作了全部的检测。一旦池中
的对象成为死亡的（基于一阶段无作用）DSEE 能够删除他们，从而释放
空间。这就节省了大量的编译时所需的时间和空间，再使用的工作已经
在进行。DSEE 也提供了各种不同的对象池，例如从源文件中得到的对象
仍是对提供给特殊用户的库的检测。结果，CM 系统使再生成组件的需求
最佳化且最大数量的分享生成对象。
e.属性
Adele 系统通过用一个有数据建模能力的关系数据库实体来普及库
和系统的建模。产品在一个数据模型方面被描述，Adele 基于那个模型
进行它的运算。产品的组件被描绘为拥有属性和关系的数据库对象。属
性和每一对象及那个对象的特性相关。属性有一个名字和一个值。一个
例子是名为delta 的用于描绘对象是否存在于ASCΠ表中从而能够被理
解的属性;它可以有一个为真或为假的值。有两种属性被区别：预先确
定和用户确定。前者被Adele 管理而后者被用户定义和声明。一个预先
确定，特殊的属性是“类型“。这个命令属性是强制的且对每一对象都
是不可变的。它在Adele 中表现为主要的的CM 实体（例如对象的组成，
文献，修改和元素）。关系在对象间独立定义，例如对象B源自对象A。
用户能够按照对象的特性而不是按照一系列对象的特殊版本来描述一
个配置。Adele 例示和构建一个配置用来选取规则和强制围绕属性和关
系为中心。用户能够按照所需特性对一产品定义任何结构。从而用户能
在一经由其特性的抽象的高水平描述一产品，其优于按照冗长的文件列

bmccbj

110
表的组成来描述。
f.一致性维护
CMA 提供了配置的释义和确认，其是基于一个对于产品的抽象描述
也是基于有关形成配置的组件的使用用法成功或不成功的信息。数据建
模便利的包括预先确定用户所描述的配置的属性和关系。基于那些属性
和关系的语义，CMA 能够决定一配置（就是一系列组件的实例）是否是
可用的。成为可用的，一配置必须是完全的，无歧义的，一致的和没有
歪斜的版本。这意味着一个配置必须有全部组件所需的实例组成且不必
包括多重的一个组件的实例。属性的等级描述了象约束，类型和版本这
样的用户定义的特性。关系的等级表现了各种依赖性，例如，合理性，
兼容性，构成，实例和可继承的独立性。每次一个新的配置被组建，CMA
就利用经由先前对形成配置的组件的使用在数据库中积累的信息。这
样，CMA 预见配置是否可用。这种新的配置为了将来分析可用性而加入
数据库。从而，用户能够依靠系统来识别任何不一致以及在构建和重复
使用用配置时保护此不一致。
E. 团队概念
描述工作在一个工程项目上的软件工程团队间的独立、合作、同步
的术语是工作区，透明检查和协调。描述如下：
a.工作空间
工作空间为开发人员提供独立的工作空间。
在“形状”中的工作空间是被设计用来防止用户之间的相互干扰。
它提供了在配置管理下的能在可调对象上持续的工作空间。工作空间是

bmccbj

111
通过版本状态模型来获得的。这就意味着属性“状态”是和构件的版本
相连系的。依靠那种状态（例如状态“忙”或“冻结”），构件或者被认
为是一个私有的工作区或者被认为是一个公有的库。“忙”构件是可调
的并且不能被其他人所使用，象“冻结”就是一个对公共使用来说能获
得的但不可调的例子。构件被提交给公共库的同时使得它们在被适当的
用户证明后，对公共用途来说是可获得的。在效力上，工作区提供工作
的独立性且建立在一个全局的、长期的为不可调对象的库和一个为可调
对象且私有的短期的库之间的区别。
b.透明视图
透明视图提供从主配置库到工作区的访问机制，该机制具有防止非
法存取的功能。
软件管理系统通过使工作区成为一个透明（清晰）的对象和提供在
那个工作区的库的透明检查来增强了工作区的术语。这就意味着仅仅用
户感兴趣的文件版本能在工作区中看到，所有其他的版本都不可见（尽
管它们在物理上是存在的）。例如，任何对最新公有版本的变化都不需
在工作区里显示出来，用户从公有变化中分离出来，并且工作区提供给
用户一个特定库的外表。相关工作区版本计数的版本控制提供在工作区
中。新版本是私有的并且在从工作区中释放出来之前是不可能被公共用
户所见的。一个配置从公有库中检测出来提供给工作区。用户访问分配
给自己的工作区。工作区里的组件有效地属于那个工作区而非一个用
户。仅仅在那个工作区已登记的用户才能改变配置，且仅有那个工作区
的构件能被访问。总的来说透明检查通过防止对一个配置的非授权访问
而提供了一个检查机制。

bmccbj

112
c.协调控制
协调控制协调开发组成员对同一配置项的修改。
网络软件环境（NSE）[12]协调控制代表了一个工作协调单元。它
反应了工程的结构并且支持工作的独立性、用户间的相互影响和合并变
化。一个协调包含一个环境和一系列命令。环境提供了类似于工作区和
透明检查的术语。它显示了用来存储资源和派生对象的目录结构。那些
命令，例如“获得”、“退后”、“重新同步”和“解决”，在不同环境中
提供相互活动。它们代表了用来协调和同步用户间活动的协议，也代表
了实际变化的通信。用户独立地工作在他们自己的环境里，改变相同的
或不同的配置。用户用配置的新版本来更新库。网络软件环境支持将变
化合并到库里。但是它检查什么已存在于库里（可能被其他用户放置在
那儿）而且不和正在进行的变化产生冲突。假如有冲突，网络软件环境
提示用户注意合并问题，同时提供减少冲突的帮助。对于任何库的变化，
用户能请求进入他们自己的工作区。总而言之，协调同步和协作团队们
改变工程产品的相同或不同部份。
F. 光谱摘要和分析
图2 代表了一个不同配置管理系统的配置管理术语光谱。这些术语
和它们的目标是：捕获不可调文件历史的库；在配置管理下数据分布的
已分布构件；一个工作单元计划的合同；一套捕获配置变化和允许最新
版本独立配置选项；增强一个组织软件进化过程变化的生命周期模型；
完整地描述和记录结构和建立工程的系统建模；使得重使用的派生对象
的对象池能优化产品构建；允许基于特性的配置选择属性而非一长串文
件列表；支持持续的自动检查和配置组件之间非持续的预测；分离可调