内容：
前言
每晚构建的定义和作用
需求定义
系统分析
文档书写辅助工具
关于作者
1、前言
本文有两个目的：实现每晚构建平台和探讨一个软件从需求文档到设计文档的书写规范。
每晚构建是软件研发管理中极具价值的手段，对于加快发现和改正缺陷，降低集成风险，提高产品质量，加强成员沟通与协作，缩短产品上市时间，增加项目开发透明度，提高项目组成员信心和斗志有着非常重要的作用和意义。本文从软件工程过程：需求定义，分析，设计出发描述了实战每晚构建平台的大部分过程。
软件工程中文档有着极其重要的地位，良好的文档风格和习惯是一个团队成熟的重要标志。目前有些软件研发人员特别是刚刚走上岗位的研发人员对文档书写没有一个统一的概念，他们不知道需要写那些文档，他们不知道每个文档需要写到什么地步，一提到写文档就抓耳扰腮。本文试图在这个方面提供一个文档样例，我不认为我的文档写的很好，只希望能起到抛砖引玉之功效。
为了实现这两个目的，本文首先解释了每晚构建,让读者对这个术语有个比较清楚的认识；然后借助于《编写有效用例》中的用例编写技术编写了每晚构建平台的用例并附加了其他相关需求形成了一个相对使用的需求定义文档；接着用面向对象的系统分析方法对需求定义进行了问题空间分析，构造出分析模型；为了读者更好更快地理解设计，后面是一整节的相关开源或第三方技术介绍，有类似于"Hello
world"的入门介绍，也有精髓内容解析，还有注意点提醒；接着是平台两大系统的设计。
整个每晚构建平台包括两大子系统：构建系统和构建信息显示系统。构建系统用ANT构建脚本实现；构建信息显示系统是个典型的web应用。两者都采用了面向对象的分析和设计技术。
需求定义的阅读应该以用户为主，文档撰写者为辅，需求定义完成的标志是两者达成了一致；分析章节的阅读应是文档撰写者帮助用户阅读，使用户理解并相信分析模型是能解决用户的问题的；设计章节的阅读主要是系统实现者，除了要求可实现性外，设计模型还要和分析模型有很强的继承性和一致性。
整个文档分为上中下三篇，上篇主要讲述需求定义和分析模型。
2、每晚构建的定义和作用
构建是从代码库中取出一个开发中的软件项目的所有最新代码，放在一个干净的环境下面，编译源代码文件，连接，安装和测试，并记录整个过程中所有日志的动作系列。
构建平台是一个构建和构建信息展示的系统。
每晚构建主要是指在开发活动不太激烈的情况下，尽量不要干扰开发者的正常开发工作，保证每天执行构建一次。
在《cvs和nightlybuild技术》一书中提到了每晚构建的作用：
每个模块有一部分成果集成一部分成果可以大大地降低集成风险，加强模块间协作性错误的诊断，降低整个系统的不确定性，可以更好地定位错误从而加快开发速度，促使模块间的接口规范而增强团队合作，每天都有新系统新成绩是对每位项目组成员的一个重要激励。
除了这些作用之外，我们还可以从每晚构建中为项目管理提供额外的信息：
每晚构建的产品，每晚构建过程的记录，每晚构造过程中的测试记录，分析测试质量的测试覆盖率分析，构建对象中项目组成员的贡献和项目组成情况分析（本文称为项目度量）。
3、需求定义
关于需求定义的文档我们一般称之为《需求规格说明书》，这个文档的任务在于比较明确地确定项目的目的和范围，提出功能需求和非功能需求，功能需求也叫行为需求，一般可以用用例来描述，如果所有需求的全集我们称为问题域，则功能需求我们可以称之为问题域的本质。软件研发公司一般都有《需求规格说明书》的框架，规定了书写需求定义文档的"纲"，下面就普遍格式对需求进行描述。
目的和范围
每晚构建平台是提供一个自动化的信息系统，用来辅助构建者构建系统，尽量做到自动化，最大化地减轻构建者的工作负担；记录构建过程的详细记录，给项目经理、组织层次的软件开发过程改进人员评估和管理软件开发项目提供相关数据，为项目成员和组织领导增加软件项目开发的透明度。
术语
构建信息关心者是关心构建过程的记录信息的人员，包括项目经理、过程改进人员、项目成员和组织领导。
用例
根据我们前面的构建平台的定义，实现这样的系统主要有两个用例和两种角色。如下图：
用例一：构建
名称：构建
级别：user goal
范围：每晚构建平台
主要角色：构建者
前提：主要角色已登录
成功场景：
构建者要求系统从代码库中取出某个项目的所有源代码
构建者编译连接所有源代码，系统产生项目软件
构建者要求安装构建出的项目软件，系统安装软件
构建者测试软件，系统测试并记录测试信息
扩展：
* 系统出错:
*.1系统保存出错信息
用例二：浏览构建信息
名称：浏览构建信息
级别：user goal
范围：每晚构建平台
主要角色：构建信息关心者
前提：已执行构建
成功场景：
构建信息关心者进入构建信息地址
系统显示所有的构建信息的目录
相应信息选择感兴趣的构建信息
系统显示相应的信息
扩展：
* 系统出错:
*.1系统保存出错信息
技术
要求用web技术，采用j2ee体系；
采用cvs open souce系统作为项目源代码版本控制工具；
数据字典
构建信息：
构建出的产品；单元测试日志（成功与否，失败则要提供相应失败原因）；单元测试的覆盖率；构建过程的日志；项目组成员的工作量（代码行数）和项目源代码树中各个目录和非二进制文件的行数；项目源代码树。
其他需求
尽量采用第三方开源代码软件；
尽量使构建用例自动化；
能构建多个项目；
实现用java 语言写的项目的构建，但要考虑未来对c,c++程序的构建的扩展。
4、系统分析
系统分析要对问题空间的本质进行分析造模，形成"要做什么"的深刻了解，尽可能地和用户达成共识。我这里既使用了传统的造模工具也利用了面向对象分析的方法学来产生文档。这一节中我首先对这些需求所涉及的子系统进行定位，看看他们之间的关系，这里我把这种分析称为上下文分析；然后看看我们关心的子系统数据流如何，得出数据流图；最后我分析每晚构建平台的"类"模型。本节所有内容的全体构成了对需求的分析模型。
系统上下文分析
通过分析，我们可以看出整个每晚构建平台的运作由6个实体构成，它们之间的关系如系统关系图所示。
构建系统完成需求定义中的软件项目的构建工作，它从CVS系统中获取项目源代码，并对源代码进行编译连接安装和测试工作，产生的构建信息通知给构建信息展示系统，构建信息关心者通过构建信息展示系统浏览构建信息。用蓝色标记表示的为本平台的组成部分。
数据流程图
下面的数据流程图更好地更详细地理解了需求，从这个流程图可知，构建系统主要和CVS系统打交道，并会生成构建信息供构建信息展示系统使用。构建系统由取出项目代码、产生项目度量数据、编译连接安装测试删除和编译连接安装（发布版）四个任务组成；构建信息展示系统和构建信息关心者打交道，主要完成浏览构建信息的任务。用黄色线条表示的存储单元"项目源代码目录"是个临时存储单元。
最后需指出的是本分析模型实现的用例一为全自动版本，是比较符合"最大化的减轻构建者工作负担"的需求的。
类模型
类关系
类BuildAdmin，ProjectBuild是project类的子类，因为从某种意义上来说，它们两者都是项目，不把OSScheduler类列为project类的子类是因为OSScheduler类很简单，可能是操作系统的一行脚本或者一行配置。
另外BuildAdmin负责所有ProjectBuild服务execute方法的执行，所以它和ProjectBuild的关系为一个复合关系；OSScheduler类要启动BuildAdmin的execute方法，所以OSScheduler和BuildAdmin有单向关系。
另外构建信息存放的位置是本平台的关键，为了让所有的类对这些位置有一个共同的视图，BuildInfoLog类是其它类的父类。
类描述
经过分析不难知道，所有的构建信息用非结构化数据来描述比较合适。在这里可以做一个决策：要求他们是独立的，也就是说进入相应的信息地址，它们可以自我显示；需求定义要求用www的方式浏览这些信息，所以同时要求他们对普通的browser是可浏览的。我们没必要用类来描述这些信息。
构建显示信息系统只有一个类来显示构建信息目录：每晚构建显示类（NightlyBuild）
另外从上下文图和数据流程图，我们可以得到我们构建系统的类：操作系统定时服务（OSScheduler），构建管理服务(BuildAdmin)，应用项目构建服务(ProjectBuild)。
两个系统之间有一个定义构建信息存放位置的类BuildInfoDir，这个类定义了两个系统之间的协议。
注意书写约定：
${变量名}为取变量名所代表的值的含义。
构建信息存放位置类 类名 构建信息存放位置类 类英文名 BuildInfoDir
成员变量
变量名 变量说明
nightly_Build_Tags 保存所有的构建标签，是构建标签列表
logTopDir 保存构建管理服务运行的日志的目录
statCVSTopDir 保存了所有应用项目的项目度量结果的顶层路径
projectLogTopDir 保存了所有应用项目构建服务实例运行日志的顶层路径
testCoverTopDir 保存了所有应用项目的测试覆盖率计算结果的顶层路径
distTopDir 保存了所有应用项目的发布版的顶层路径
testTopDir 保存了所有应用项目的测试结果的顶层路径
方法
方法名 参数 执行步骤 方法说明
每晚构建显示类
类名 每晚构建显示类 类英文名 NightlyBuild
成员变量
变量名 变量说明
方法
方法名 参数 执行步骤 方法说明
list_ Buildinfo_table （1）读取nightly_Build_Tags内容，格式化显示每个构建标签指示的构建信息目录。
操作系统定时服务
类名 操作系统定时服务 类英文名 OSScheduler
成员变量
变量名 变量说明
方法
方法名 参数 执行步骤 方法说明
excute 利用系统当前时间形成日志文件名；
执行BuildAdmin的excute()方法，并把BuildAdmin的正常输出和错误输出记录到日志文件名中；
保存日志文件到${logTopDir}指定的目录中。
启动构建管理服务并记录日志
构建管理服务
类名 构建管理服务 类英文名 BuildAdmin
成员变量
变量名 变量说明
cvsroot 保存了cvsroot环境变量
buildDir 保存了临时存放应用项目源代码的路径
方法
方法名 参数 执行步骤 方法说明
cvs_check_out 应用项目cvs系统中的名字 利用cvsroot 登录cvs系统；
执行cvs co指令，把参数制定的应用项目源代码取出并放在成员变量${buildDir}指定的目录/项目名字/目录下。
从cvs中取出项目源代码
statcvs module:应用项目cvs系统中的名字；
project_Build_Tag:每个项目的当前构建标签
(1) 对源代码进行项目度量，并把结果放在${statCVSTopDir}目录下的${project_Build_Tag}目录下。
对源代码进行度量execute 对每一个应用项目执行：
cvs_check_out
statcvs
执行ProjectBuild的execute（）方法
应用项目构建服务
类名 构建管理服务 类英文名 BuildAdmin
成员变量
变量名 变量说明
project_Build_Tag 保存了当前正在构建的项目由项目名称和当前系统时间组成的构建标签
方法
方法名 参数 执行步骤 方法说明
test_project 为测试而编译连接源代码；
安装测试版产品；
测试产品；
计算测试覆盖率；
输出测试结果到${testTopDir}指定目录下的${project_Build_Tag}目录下；
输出测试覆盖率结果到${testCoverTopDir}指定目录下的${project_Build_Tag}目录下；
dist_project 编译连接源代码；
安装发布版产品到${distTopDir}指定目录下的${project_Build_Tag}目录下。
execute 执行test_project方法
执行dist_project方法
把两个方法的日志合并成一个日志文件，命名为${project_Build_Tag}.txt，并把其放在${ projectLogTopDir
}指定的目录下。
执行场景
构建场景
1.操作系统定时服务类开始执行；
1. 1启动BuildAdmin对象的execute方法
针对每个被管理的项目，执行下列步骤：
#begin
1.1.1根据当前系统时间和项目名称生成该项目的构建标签，并记录构建标签
1.1.3以构建标签为参数生成项目的ProjectBuild对象
1.1.2调用cvs_check_out方法，从cvs系统中取出该项目的源代码
1.1.3执行statcvs方法，生成项目度量数据并保存到相应的位置
1.1.4调用该ProjectBuild对象的execute方法，完成项目的测试和安装，并产生相应的构建信息
#end
浏览构建信息场景
我们已经说过，各个构建信息能实现在browser中的自我展示，所以Nightlybuild对象只需通过某种格式显示各个构建信息的目录，构建信息请求者可以通过这些目录请求各个构建信息。
1.NightlyBuild对象接到浏览构建信息的请求，通过对自己保存的构建信息目录和构建标签列表组织构建信息目录。
5、文档书写辅助工具
word 文档书写排版工具
powerpoint，图片组织绘画工具
visio 绘制数据流图，ER图等的工具
rational rose，绘制UML图形的工具
windows 附件中的画图来截取图片
操作系统的全屏打印功能
关于作者：
龚永生 (gongys@legend.com)
北京市海淀区上地信息产业基地开拓路7号联想大厦
|