2、 靠自己

小蜗牛问妈妈：为什么我们从生下来，就要背负这个又硬又重的壳呢？
妈妈：因为我们的身体没有骨骼的支撑，只能爬，又爬不快。所以要这个壳的保护！
小蜗牛：毛虫姊姊没有骨头，也爬不快，为什么她却不用背这个又硬又重的壳呢？
妈妈：因为毛虫姊姊能变成蝴蝶，天空会保护她啊。
小蜗牛：可是蚯蚓弟弟也没骨头爬不快，也不会变成蝴蝶他什么不背这个又硬又重的壳呢？
妈妈：因为蚯蚓弟弟会钻土, 大地会保护他啊。
小蜗牛哭了起来：我们好可怜，天空不保护，大地也不保护。
蜗牛妈妈安慰他：「所以我们有壳啊！」我们不靠天，也不靠地，我们靠自己。

3、 鲨鱼与鱼

曾有人做过实验，将一只最凶猛的鲨鱼和一群热带鱼放在同一个池子，然后用强化玻璃隔开，最初，鲨鱼每天不断冲撞那块看不到的玻璃，耐何这只是徒劳，它始终不能过到对面去，而实验人员每天都有放一些鲫鱼在池子里，所以鲨鱼也没缺少猎物，只是它仍想到对面去，想尝试那美丽的滋味，每天仍是不断的冲撞那块玻璃，它试了每个角落，每次都是用尽全力，但每次也总是弄的伤痕累累，有好几次都浑身破裂出血，持续了好一些日子，每当玻璃一出现裂痕，实验人员马上加上一块更厚的玻璃。后来，鲨鱼不再冲撞那块玻璃了，对那些斑斓的热带鱼也不再在意，好像他们只是墙上会动的壁画，它开始等着每天固定会出现的鲫鱼，然后用他敏捷的本能进行狩猎，好像回到海中不可一世的凶狠霸气，但这一切只不过是假像罢了，实验到了最后的阶段，实验人员将玻璃取走，但鲨鱼却没有反应，每天仍是在固定的区域游着它不但对那些热带鱼视若无睹，甚至于当那些鲫鱼逃到那边去，他就立刻放弃追逐，说什么也不愿再过去，实验结束了，实 验人员讥笑它是海里最懦弱的鱼。

可是失恋过的人都知道为什么，它怕痛。

4、 神迹

法国一个偏僻的小镇，据传有一个特别灵验的水泉，常会出现神迹，可以医治各种疾病。有一天，一个拄着拐杖，少了一条腿的退伍军人，一跛一跛的走过镇上的马路，旁边的镇民带着同情的回吻说：「可怜的家伙，难道他要向上帝祈求再有一条腿吗??」这一句话被退伍的军人听到了，他转过身对他们说：「我不是要向上帝祈求有一条新的腿，而是要祈求祂帮助我，叫我没有一条腿后，也知道如何过日子。」
试想：学习为所失去的感恩，也接纳失去的事实，不管人生的得与失，总是要让自已的生命充满了亮丽与光彩，不再为过去掉泪，努力的活出自己的生命。

5、 钓竿

有个老人在河边钓鱼，一个小孩走过去看他钓鱼，老人技巧纯熟，所以没多久就钓上了满篓的鱼，老人见小孩很可爱，要把整篓的鱼送给他，小孩摇摇头，老人惊异的问道：「你为何不要？」小孩回答：「我想要你手中的钓竿。」老人问：「你要钓竿做什么？」小孩说：「这篓鱼没多久就吃完了，要是我有钓竿，我就可以自己钓，一辈子也吃不完。」我想你一定会说：好聪明的小孩。错了，他如果只要钓竿，那他一条鱼也吃不到。因为，他不懂钓鱼的技巧，光有鱼竿是没用的，因为钓鱼重要的不在＜钓竿＞，而在＜钓技＞有太多人认为自己拥有了人生道上的钓竿，再也无惧于路上的风雨，如此，难免会跌倒于泥泞地上。就如小孩看老人，以为只要有钓竿就有吃不完的鱼，像职员看老板，以为只要坐在办公室，就有滚进的财源。



http://community.csdn.net/Expert/topic/4144/4144028.xml?temp=.3016779

一些小朋友连婚都没有结，学什么项目管理！

世界上哪里见过全是Girl的软件公司？将来生了Baby，也要和儿子沟通嘛，所以每个Team里面必须要有1名Girl！（林老师规定的组建Team的要求之一）

××著名软件工程大师居然也去鼓吹XP，我们认为他应该呆在意大利唱Opear的，他却唱起了Rack&Roll！

有了Contract，就有了benefit和responsibility，啊，这个benefit和responsibility是相互的，比如说，我给我老婆爱，这是我的responsibility，我老婆就会给我烧菜吃，这就是我的benefit。（林老师解释Contract时作的比喻）

等上到CMM5，简直就是一位武林高手已经到了自废武功、无招胜有形的地步……（林老师对CMM5的无限敬仰）

这个weekly report就是你对你老板做的忏悔。

UP是正楷，XP是草书。先学好了UP，才能学好XP；先学XP再学UP就会乱套。

Martin Fowler原来约好在交大讲座，却突然生病给送进了中山医院。听说Martin Fowler前一天在西安，据我推测，他是在西安吃拉面吃坏了肚子……（梁阿磊老师评语：这是软件工程在中国水土不服的具体表现）

中国人上到黄山顶上想到的可能是李白的诗，德国人上到黄山顶上想到的可能是贝多芬的交响乐，一条狗爬到黄山顶上能想到什么！——它大概在找大便在哪里。（林老师在解释View概念时）

我想可能是中国人吃猪肉的原因，所以大家上课都在打瞌睡，而美国人吃的是牛肉，就从来没有见过美国人上课打瞌睡。——啊，等到考试那天，同学们都最好到学校外××牛肉面馆，饱饱的吃上一顿，这个精神就会很好！

软件工程好比是一个包子，技术是里面的馅，管理是外头的皮。小朋友们光爱吃馅不爱吃皮，我们大人就不同了，啊，我们要把馅和皮一起吃下去。

IT业界犹如一个台风，风暴眼中心站着的是Bill的MS，围绕着他激烈旋转的是IBM、SUN和Larry的Oracle(Alliance but ms)，其中IBM那~是黑帮老大，一个手势就能Kill掉SUN的技术成果，但是IBM也在搞婚外恋，和MS一起在推WebServices，另外王嘉廉的CA是MS的走狗。（林老师的青梅煮酒论英雄）

Jini技术是distributed object computing技术进化树上的猿猴，已经偏离了向人类进化的正确方向。

老爸拥有女儿，女儿叻就要向老爸提供：1.Cute函数(返回：30分钟的enjoyment)，2.每月交钱函数(返回：500块)，3.买酒给老爸喝函数(返回：1980酿上等女儿红)，4.女婿拍马屁函数(返回：void)。（林老师解释OO概念的核心比喻，随切入的话题有不同变化）

软件工作就像裁缝做西装，从设计、裁剪到缝制加工，细部要求非常精巧，体现着一种quality。

在我的感觉里，Larman是个打工仔，Pressman是个书呆子。

“印软经验”确实曾经给中国软件企业以很大的帮助和借鉴，但时至今日，面对已经变化良多的市场环境和竞争对手，中印软件企业之间更多的已经不是“学习与被学习”的简单关系，而是“羚羊与狮子竞跑”的残酷现实。

“我们没有达到原来的期望”。谈到MphasiS公司在中国IT服务市场的经营状况，其首席执行官杰瑞·拉奥(JerryRao)认真地说。MphasiS是第一波投资中国的印度信息技术(IT)服务公司之一，总部位于印度孟买。由于看好中国的软谐∏熬埃?002年10月，MphasiS从美国信用卡发行商CapitalOne手中买下了现在的上海运营中心。

事实上，MphasiS只是印度一家中等规模的高科技公司，如果说仅仅因为规模的原因导致其在华业务的增长比预期要慢的话，那么很难解释像印度的IT四巨头，即塔塔咨询服务(TataConsultancy)、InfoSys、Wipro以及Satyam在中国软件市场上的日子也不如意的事实。

不可否认，“印软经验”确实曾经给过中国软件企业以很大的帮助和借鉴，但在这块至今仍让印度软件企业“垂涎三尺”的市场上，中国本土软件企业已经具备足够的竞争力和杀伤力。对印度软件企业而言，学会中国软件市场的游戏规则也许是突破其市场瓶颈的第一关。

“借中国床，孵印度蛋”

近年来，“进军中国”对致力于国际化的印度软件企业来说似乎已经成为一种时尚，尤其是2002年，登陆上海浦东软件园的印度企业几乎可以用“蜂拥而至”来形容。

对于以软件外包闻名全球的印度软件企业来说，进入中国似乎并没有什么特殊意义，因为相对于欧美和日本，中国的软件外包市场并不大—2004年其规模也只有6.33亿美元，仅占全球外包市场的1.9%，显然这对于“印度象”的巨大胃口不会有太多的吸引力。

根据一般的看法，印度软件巨头们进入中国的原因与十多年前一些全球大的咨询公司和会计师事务所来华的情况有类似之处，那就是全球500强企业中有一大批都在华建立了分支机构，而这些企业多数是印度软件企业的客户或者合作伙伴。

除此之外，另外一种比较流行的解释是：印度软件企业期望通过中国作为跳板进入并拓展日韩市场。对于这样的说法，曾在印度做过数年软件外包培训，目前供职于安氏中国的宋雷对记者谈了一些不同看法。他认为，进入日韩市场并非印度软件企业进军中国的主因，这一点从印度软件企业在华分支机构的招聘启事就能看出来—几乎没有一家在招聘精通日语或者韩语的员工，倒是英语出色的程序员很受欢迎。在他看来，印度软件纷纷在华登陆，目的绝不仅仅是在日本或者韩国多占点外包份额那么简单，而是有着更长远的规划。

“成也外包，败也外包，外包在成就印度软件业的同时，也恰恰是它最大的软肋”，宋雷解释说：“外包的实质是劳务输出，这和国内民工进城打工从本质上来说是一样的，印度缺少自己的软件品牌和知识产权，对欧美的软件外包虽然给他们带来了利润，但IBM、微软、Oracle、SAP等全球巨头的强势也注定了那样的外包合作模式不可能扭转印度‘软件蓝领’的地位—尽管做了多年外包，但印度公司依然很少有机会做架构或者进入总包商行列。在树立自有的知识产权和品牌方面，印度并不比中国同行做得好多少”。

在他看来，印度软件企业目前最大的目标，恰恰是摆脱“外包专业户”的形象，在软件产业链上游有所作为，登陆中国，则是实现这一目标的重要环节。对于内需极度匮乏，几乎完全靠欧美外包支撑的印度软件业来说，中国市场拥有诸多优良条件：内需巨大，企业信息化和电子商务发展势头迅猛，质优价廉的人力资源，最重要的是，中国软件企业相对弱小。这些无疑都是期待“二次腾飞”的印度软件企业们最看重的。

“这好比一只狼，跟狮子合作只能吃到残羹剩饭，但跟没有反抗能力的肥羊打交道就不同了。凭借自身的相对优势，印度企业完全有机会在中国树立其强势地位，并且能从容地发展出自有品牌和知识产权—“借中国的温床，孵印度的蛋”。当然这仅仅是印度软件企业一方的如意算盘，实际发展有没有这么顺利就不一定了”。

陷入尴尬境地

现实似乎总是与理想有一定的差距。进军中国几年后，“印度象”们普遍遭遇到了市场发展瓶颈。

与IBM、SAP在中国大兴土木、建全球研发中心的意气风发相比，印度软件企业在华投资显得相当谨慎，基本上可以用“试水”来形容。根据统计数据，2004年前三个季度，有21家印度公司在中国直接投资，但投资总额仅为1700万美元，在同期外国IT企业在华直接投资中所占的比例小得可怜。考虑到从2002年起，印度前四名的软件企业塔塔、InfoSys、Wipro以及Satyam就已陆续在上海登陆，这一谨慎投资行为看起来只能理解为：“印度象”在华的旅途并不愉快！

实际情况也从不同角度佐证了这一点。除了2002年左右，媒体曾经大批量报道过关于印度软件企业争食中国市场之外，就很少见到其他新闻见诸报端，业内也基本上见不到塔塔、InfoSys们的大手笔。期间甚至出现曾经号称印度第二大软件公司的Zensar与亚洲物流科技有限公司合资的汉道科技咨询公司成为笑谈的事情：成立伊始，Zensar公司首席执行官曾放言“一年内员工总数超过2000，成为中国首屈一指的管理咨询与软件顾问公司”，而一年后的2003年，这一言论已被证明只是“放卫星”，甚至直到现在，也远没有达到当年预期的经营目标。

同样的事情也发生在MphasiS身上，拉奥认为在中国拥有一席之地非常重要，但眼下低迷的经营状况，也不得不让他考虑解决这一问题的途径。下一波正在拟订中国战略的印度中型IT服务企业中，有几家也持有MphasiS这样的谨慎态度。

事实上，包括塔塔、InfoSys在内的印度在华软件巨头都遭遇到了现实与理想的巨大落差。成立之初，这些印度软件企业基本上都将在华的分公司定位为软件或者IT咨询公司，目的就是想摆脱“外包”的固有印象，在大幅度扩张的基础上树立软件或者咨询品牌。然而从实际运营情况来看，这些独/合资公司最终都在规模扩张方面裹足不前，主要业务也仍然局限于外包领域。

难以突破的瓶颈？

那么究竟是什么原因导致了“印度象”们在中国软件市场上的集体失声？

专门从事软件外包的用友软件工程公司的某项目负责人一语道破天机：“印度软件企业的困境主要来自于内外两方面，内在的是印度公司固有的习惯和思维模式，外在则是中国软件市场的规则和激烈竞争。很多印度公司的想法过于理想化，也过于自信，以为软件工程做得好就可以在其他领域同样复制，这一点从很多印度软件公司在华机构都是独资就能看出来”。

在该项目负责人看来，创建一个软件品牌是一项繁复浩大的工作，并非“开发流程＋英文优势”的印度软件发展模式就能简单塑造的。“印度在外包领域还属于应用层面，介于以色列、爱尔兰等基础件外包商和中国这样的低端应用外包商之间，在往两端走的时候必然会遭遇两方面的竞争。比如他们要在国内做ERP或者MIS等管理软件品牌，就会遭遇到很多问题，SAP、Oracle、IBM等欧美企业在高端树立的壁垒已经很难逾越，而用友、金蝶在中低端特别是财务领域也已经比较稳固。此外，本土化的各个方面都需要外来者好好研究，中国独特的监管环境、渠道体系和中国企业狠劲十足的打单方式都容易让习惯了国际惯例的印度软件企业吃不消。”

另一方面，中国软件行业独特的潜规则和激烈的市场竞争显然也是印度软件企业的发展障碍。中国软件企业希望从印度企业身上学到国际外包方面的经验，但同时会牢牢掌控已经苦心经营多年的国内软件市场。品尝了十多年“技术换市场”酿成的苦果，中国企业目前在技术引进的心态上已经趋于成熟。而印度软件企业此时进入必然会遭遇前所未有的阻碍，通过常用的本土化手段渗透和打入中国的主流软件市场虽然机会天天有，但其操作难度已经不可同日而语。

对于上述的瓶颈，印度软件企业并非没有意识到，其中“先知先觉”者已经开始通过并购、合作等方式企图“突围”，但更多的印度软件企业选择了“静坐”的方式，在他们看来，在中国扩张的主要障碍在于中国缺乏大量国际外包经验丰富且使用双语的项目经理，而这方面的问题在中国加入WTO后将会逐步得到解决，显然仍旧对中国软件市场的游戏规则存在模糊认识。

但无论如何，当初放言“中国软件企业还没有能力帮助我们”的印软老总们开始意识到与国内软件企业合作的重要性，这毕竟就是一种进步。碰完钉子的人通常都会学聪明一点，曾经“牛气冲天”的塔塔、InfoSys们这两年明显感受到了力不从心—“本土化”这一门槛即使是IBM、Oracle等软件巨头也没法绕过，“印度象”们如果想和IBM一样的跳“中国舞”，低下骄傲的头颅看来是不可避免了。

中国软企：外包不是“万能药”

英语口语还不太熟练的“软件外包国家队员”们的远征计划也许是又一次“十字军东征”

钱钟书先生笔下的“围城”故事似乎一直在现实生活的不同场合被演绎出不同的版本。这一次，中国和印度的软件企业分别站在了围城的内外—就在印度公司极力想摆脱包工头形象转而塑造软件品牌的时候，不少走了十多年品牌路线的国内企业却把赌注押到了外包上……

当外包成为一种信仰

和“中小企业信息化”一样，“软件外包”同样是时下IT业界最热门的关键词之一，与前者浓重的本土特色不同，这一业务模式更像是舶来品。不过外包这一模式也的确让不少国内软件企业尝到了甜头。

以对日软件外包出身、号称国内最大软件企业的东软为例，其目前的三大业务营业额占整体的比率分别为：国内软件与服务占70%、数字医疗占20%、国际业务占10%。根据东软内部资料，2002年占公司收入比重超过70%的国内业务，净利润仅占到了7971万元净利润的5%左右，2003年则发生首次亏损。但公司软件外包业务利润率却一直保持在30%以上，高的项目甚至可达40%—软件外包几乎成为整个公司的救命稻草。

东软也许只是一个缩影，现实情况是，像东软这样靠外包过活的国内企业并不在少数，反而像中科红旗、永中这样走品牌路线的软件企业则举步维艰。具有自主品牌和知识产权的国内业务还不如为别人代工的业务赚钱，这已经成为中国软件产业的“特色”，或者说是“怪现象”。

对于这样的“中国特色”，东软一位做系统集成的员工这样解释：“做解决方案对国内企业来说盈利很难，一方面其中很大部分比重是利润非常薄的硬件销售，另一方面，在与国外竞争对手竞标的时候，我们常常需要用低很多的价码去冲才能拿下，但解决方案需要铺开，会消耗大量的人力财力。相比较而言，软件外包就没有这么麻烦，基本上是命题作文，回款也相对容易一点”。

在这种情况下，众多做项目起家的软件企业都趋之若骛，将箭头瞄准了软件外包业务。2004年“组建软件外包国家队”等一系列事件更是将这股“外包风”推向了高潮。

零食还是正餐？

对于炙手可热的软件外包和众多软件企业的蠢蠢欲动，中科院院士倪光南泼出了“学习印度，但不可照搬”的冷水。他认为，中国和印度国情的最大不同在于，印度没有很大的内需市场，而中国有很大的内需市场，这是中国软件企业的大本营，如果仅仅因为片面追求外包而将国内市场丢掉，无疑将会本末倒置。所以在相当长的时间内，外包应该作为中国软件业的“零食”而不是“正餐”。

“印度软件业目前仅仅是在外包领域称雄，还算不上是真正的软件强国，去年其在全球软件产业总额中只占1.6%，与第一位美国的42%相差极大，也远不及欧盟和日本。其次印度的外包模式存在明显缺陷：知识产权和品牌存在严重软肋，也不利于建立自主完整的软件体系。实际上印度软件企业几年前就已经意识到这一点，目前也在努力改变这种情况。而目前国内软件企业对于‘印软经验’的学习比较盲目，譬如过分追求和强调CMM认证，其实CMM认证有其局限性，并不能满足所有软件企业的需求，像微软、Oracle、Sun等软件巨头都没有做CMM认证，也能说明这一点”。

对上述看法，宋雷也表示了赞同，“印度的外包神话其实有点歪打正着的味道，因为当初印度国内没有内需，所以只能给语言体制相近的欧美做外包。但美国、欧洲和日本的软件发展都没有经过这样的阶段，因此中国软件企业完全没有必要效仿，也效仿不了。而且印度目前在全球外包领域也处于不上不下的尴尬境地，只有欧美应用外包这一根救命稻草”。

“打个不恰当的比喻，杨过断了一只手练成了绝世武功，但你不能因为这个也砍断自己的手才练功，更何况你就是砍断了也练不成。印度在软件外包方面的诸多优势和做法，我们大部分都能学，但语言优势是我们永远也没法模仿的，而这一点在极需要沟通的外包业务中是举足轻重的。此外，体制和文化上的差异短时间内也无法消除。反过来其实一样，印度一直无法进入日韩市场主要也是这方面的原因，所以我觉得，中国软件企图通过外包途径打入欧美主流市场只可能是‘邯郸学步’”。

最佳途径：“防守反击”

对于中国软件行业的发展方向，有业内人士认为，最佳途径应该是“防守反击”——即在创建自有软件品牌，巩固国内市场的前提下适当发展外包，在国际市场上有所作为。

尽管从全球角度而言，国内并没有一个知名的软件品牌，但十多年来的发展，国内多数软件企业走的还是品牌路线，考虑到中国巨大的内需市场，这不能不说是一个好习惯。

“在品牌创建和基础软件发展上，中国软件企业做的要比印度好”，对于中国软件业自身的优势，倪光南院士认为：“这些年国内软件企业还是出了不少品牌，比如金山、永中、红旗，尽管早期主要集中在应用领域，但近年在基础软件领域也有了一些突破。目前，中国已经有自己的Linux操作系统，其他数据库、中间件也都有一定的发展，而这些都是印度软件行业所欠缺的。今后占据软件产业链主导地位的，必然是以知识产权为核心，以品牌、产品和解决方案带动的企业，而目前一些国内的软件企业显然正在朝这个方向发展”。

有业内人士认为对于类似东软这样的国内软件企业，如果要在全球站稳脚根，归根结底还是要能在欧美市场上争雄，但在目前的竞争形式下，显然需要相当过硬的品牌来支持，毕竟从“虎口里拔牙”需要相当得力的“钳子”。

来源：互联网周刊

http://www.huihoo.com/development/fdd.html

功能驱动开发模式FDD

FDD（Feature-Driven Development）是由Peter Coad、Jeff de Luca 、Eric Lefebvre共同开发的一套针对中小型软件开发项目的开发模式。

FDD是一个模型驱动的快速迭代开发过程，它强调的是简化、实用、 易于被开发团队接受，适用于需求经常变动的项目。简单地说，FDD“是一个以Architecture为中心的，采用短迭代期，目期驱动的开发过程。它首先对整个项目建立起一个整体的模型，然后通过两周一次‘设计功能-实现功能’的迭代完成项目开发”。此处的“功能”是指“用户眼中最小的有用的功能”，它是可理解的、可度量的，并且可以在有限的时间内（两周）实现。在开发过程中，开发计划的制定、报告的生成、开发进度的跟踪均是以上述“功能”为单位进行的。在FDD中，它认为：只有良好定义的并且简单的过程才能被很好地执行。另外，由于在FDD中采用了短周期的迭代，最小化的功能划分法，所以可以对项目的开发进程进行精确及时地监控。

FDD的使用需要有相应工具的支持，Peter Coad等人开发出了一套扩展的UML（FDD UML Extensions），并在Together中实现有关的功能，详细内容可参见后文。

在FDD中，存在“主要功能集”、“功能集”、“功能”等概念，它们之间的关系及示例如下所示：

主要功能集 = 功能集1 + 功能集2 + …

功能集 = 功能1 + 功能2 + …

其中，主要功能集是在初始阶段根据用户的需求所制定出来的比较粗的，有待于细化的对开发项目所需要功能的描述；功能是在开发过程细化的结果，在每个迭代期中需要实现若一干个功能，这些功能的集合被称之为功能集。

在FDD中，它将开发过程划分为如下五个阶段：

l         制定整体的模型

l         根据优先级列出功能的详细列表

l         依据功能制定计划

l         依据功能进行设计

l         实现功能

每个阶段的定义又是通过被称之为：ETVX的方法从下面四个方面加以描述的：

l         Entry：Specify clear and well defined entry criteria for the process；

l         Task：列出所有要实现的任务列表，名称，是否需要实现，任务描述；

l         Verification：；制定对过程结果的评批标准；

l         eXit：过程结束时所需的结果；

FDD过程示意图

在FDD中主要存在三类人员：主要开发人员、类的所有者、功能团队，它们各自的含义如下：

l         主要开发人员：用于领导其它开发人员进行DBF/BBF的开发，对开发工作进行监督（例如对设计及代码进行审查）。主要开发人员的数量由项目整体的大小所决定，如果需要加快开发进度则可以再培养新的主要开发人员。与其它开发人员相比，主要开发人员具有更高的开发效率。Fred Brooks在几十年前就提出了：增加开发人员数量只会降低开发效率。但对于小型的，以用户功能驱动的轻量及的开发过程此原则并不适用。在此过程中采用增加人员的方法可以提高开发的并行效率。

l         类的所有者：一个类有且只有一个所有者，即一个类只能由一名开发人员进行设计及编码。采用这种方式是十分有效的，因为开发人员会感觉他拥有了部分属于自已的代码，他会以此为荣；此外，它还可以保证相关代码的一致性。如果此类中包含有复杂的算法，那么可以再增加一名专门负责算法的开发人员。虽然FDD是面向用户功能的，而不是面向类的，但用户最终关心的是那些他们需的功能，而并不关心在开发时采用何种框架模式，所以在此以类为单位进行人员分配与开发的宗旨并不矛盾。

l         功能团队：开发时功能会被分配给主要开发人员，再由主要开发人员根据实现此功能所需类的所有关系找到有关的开发人员从而构成一个临时的（最多两周）的团队。一名开发人员可以同时负责多个类的开发工作，即他可以在同一时刻处于多个功能团队中。因此在每个DBF/BBF中功能团队的人员均可能发生变化。在此团队中主要开发人员处于核心地位，团队内部的交流也是经及为中心的。采用这种方法可以加速开发进度，并且主要开发人员还可以对过程进行必要的监控，保证设计与实现的一致性。从更高的角度来看，主要的系统设计师又负责监控各功能团队中的主要开发人员。

采用FDD方式进行开发时，各阶段时间的分配关系大致如下所示：

l         Develop an overall model                     10% initial, 4% on-going

l         Build a features list                             4% initial, 1% on-going

l         Plan by feature                                          2% initial, 2% on-going

l         Design by feature, build by feature              77%（两周一个迭代期）

DBF/BBF中各阶段时间分配关系：

l         DBF

²        Walk through the domain              1%

²        Design                                40%

²        Inspect the design                3%

l         BBF

²        Code/test                             45%

²        Inspect the code                   10%

²        Promote to build                   1%

需要注意的是：上述Coding的过程中还包含有单元测试的内容。此外单从DBF/BBF的过程来看，设计所有的时间要比编码的时间长（40% : 45%），但考虑到FDD的整个实施过程（包括前期的建模过程），设计的时间还是比编码的时间要长的（45% : 35%）。

在FDD中另一个重要的，并且也是十分有特色的部分就是它的报告功能。每周Release经理要召开一次会议，会议一般限定于30分钟以内，在会上每个主要的开发人员全面地介绍其所做的工作，并标识出相应的项目状态图。通过这种口头上的交流，可以确保各主要开发人员能对项目的其它部分有一个充分的了解。会后，Release经理还要根据有关内容更新数据库中的信息并生成相应的报告，这个报告将发送给项目团队、用户以及主要的管理人员。

为跟踪项目开发状态需要使用数据库对有关内容加以保存，在数据库中应保存如下信息：

l         类型（问题域、人的交互活动、系统交互活动）

l         标识（功能集前缀+序列号）

l         状态（正在处理、不再需要、正常）

l         主要功能集

l         功能集

l         文档引用信息

l         活动事件

l         主要开发人员

l         问题域分析时的计划日期，实际日期

l         设计时的计划日期，实际日期

l         设计复查时的计划日期，实际日期

l         编码时的计划日期，实际日期

l         编码复查时的计划日期，实际日期

l         提交构造时的计划日期，实际日期

l         备注

项目计划表

功能详细列表

另外，有关类及类的所有者的信息保存在其它的表中。根据数据库可自动生成有关报告。

项目已完成功能统计表

FDD中扩展的UML

FDD 过程 #1: 开发总体模型

Entry Criteria:

客户已准备好建立一个系统。他已经有采用某种形式保存的需求列表。此时用户可能还不能完全分清楚什么是他“必面要的”，什么是他“想要的，最好有的”，但这没有关系。

Tasks:

Verification:

Exit:

结束过程时，团队必须提交如下内容，并且这些内容已经过开发经理以及系统设计师的审阅及批准：

-          类图，包括：类、类间关系、类的函数以及属性。类及类间关系建立起了模型的大致轮廓。根据最初的功能有列表以及非正式的序列图而来的函数展现出系统的功能，并且是后续开发过程中建立详细功能列表的前提。此外还应有非正式的序列图。

-          非正式的功能列表。

-          其它可供选择的模型信息。

FDD 过程 #2: 创建功能列表

在此阶段，团队标识出所有的功能，对其加以分组，为其设定优先级，并设置相应的权重。

在下面的活动中，小组工作的重点在于功能，因此领域专家可以不再需要。

Entry Criteria:

建模团队已成功地完成了FDD第一阶段的工作，开发出了系统的整体模型。

Tasks:

Verification:

Exit Criteria:

    本阶段结束时，详细的功能列表必需已经产生了，并且将功能进行分组形成主功能集以及功能集，此外这些内容已经过开发经理以及系统设计师的审阅及批准。

FDD 过程 #3: 根据功能制定计划

根据已制定的层次化的、具有优先级以及权重的功能列表，项目经理、开发经理以及主要开发人员一起制定出DBF/BBF阶段的里程碑。

Entry Criteria:

功能列表团队已成功地完成了FDD第二阶段的工作，并已形成详细的功能列表。

Tasks:

Verification:

Exit Criteria:

本阶段结束时，开发计划已经产生了，并且这些内容已经过开发经理以及主要设计师的审阅及批准。计划中应包括以下内容：

-          一个整体的开发日期

-          针对每个主要功能集、功能集、功能指定有关负责人（CP）以及完成时间

-          针对每个类，指定负责其完成的开发人

注意：

    为便于为功能设置优先级，可以创建一个称之为FFB（待实现功能板）。

FDD 过程 #4: 根据功能进行设计（DBF）

根据已制定的层次化的、具有优先级以及权重的功能列表，项目经理、开发经理以及主要开发人员一起制定出DBF/BBF阶段的里程碑。

Entry Criteria:

计划制定团队已成功地完成了FDD第三阶段的工作。

Tasks:

Verification:

Exit Criteria:

本阶段结束时，应已完成如下工作，并且这些工作已经过主要设计师的审阅及批准。计划中应包括以下内容：

-          功能及其相关参考资料（如果有的话）

-          详细的序列图

-          更新后的类图

-          更新后的类及其方法原型

-          开发团队认为有价值的其它实现方案

FDD 过程 #5: 根据功能进行设计（BBF）

在DBF工作的基础上，每个类的实现者完成类的各个方法。此外他还需完善基于类的测试方案并实现类一级的单元测试。根据主要开发人员的意见，功能实现团队可能还需在进行单元测试之前先进行源代码检查。当代码编写并检查后开发人员就将其放入配置管理系统中。在所有的类均已完成并Check-In之后，主要开发人员将代码提升以便进行构造。

Entry Criteria:

功能实现团队已成功地完成了FDD第四阶段的工作。

Tasks:

Verification:

Exit Criteria:

本阶段结束时，应已完成如下工作，并且这些工作已经过主要设计师的审阅及批准。计划中应包括以下内容：

-          实现了类的方法并对代码进行了检查和单元测试

-          按顺序针对每个类的方法的单元测试记录

-          类已被开发人员Check-In，主要开发人员已提升代码进行构造并同步更新功能状态。

说明：这些帖子都是在讨论工厂模式，容器配置，构造函数产生对象的方式各自优缺时的回帖。很不错！感谢potian！！！

除了静态方法对具体子类的直接依赖问题之外，对象的产生封装在对象内部也是一个很奇怪的想法，如果在不同情况下，例如需要同步或者需要lazy等等的话，你必须针对修改你的代码，实际上我们最关心的是能够在不同场合使用同一个对象的业务逻辑，而你这样做的话会紧紧因为我们需要不同的对象创建方法而修改对象的代码，这是非常不智的，这也是singleton被视作evil的重要原因之一。（例如singleton，有时候我们希望使用超类的实例，有时候希望使用子类的实例，有的时候我们希望产生单个，有的时候需要产生多个[取singleton单控制点的含义]，有的时候需要同步，有的时候不需要同步，在集群的情况我们甚至可能需要数据库来实现唯一化控制，有时候希望缓存，有的时候不需要缓存，有的时候希望增强，有的时候希望采用动态代理产生。所以一般来说，我们希望在一个系统内部最多只有一个入口的singleton，而我们也往往也不打算在其它不同的场合重用这个singleton）。

代码的重用是对他业务逻辑的重用，这正是对象的核心价值。所以如同charon所说的，相对而言，我们往往不在乎组装代码的重用性，而是追求业务代码本身可以被按照不同的组装方式使用，例如既可以在EJB下，也可以在普通的Java应用程序中，既可以作为远程传输的对象，因此，我们往往不会去强制对象构造和产生的方式（例如由EJB容器产生，由IOC容器产生、有抽象工厂产生，或者直接由new产生），相反，是把对象的产生交给外部负责，这样才能达到在不同场合下对象最大的可重用性。说个简单的，如果对象的构造方法是私有的，那么现在的很多框架（例如hibernate，JavaBean,EJB等等你就根本不能使用了).这也是现在认为POJO比有特殊要求的对象更好的原因，因为任何一种框架和技术都可以自由选择自己的方式来创建对象。

所有创建型设计模式和IoC容器的使用正是基于这样的假设的，只有对象把构造的责任交给外部来实现，那么我们才能有效地隐藏对象创建的时机、方式、方法，给不修改对象本身的代码而能够使用不同的对象创建方式（包括使用子类，替代类）提供了前提，从而提高对象实现业务逻辑的在不同场合的可重用性。所以不是说一定要用IOC容器或者用抽象工厂，而是可以用这些方法，也可以不用这种方法。而就抽象工厂和IoC容器本身而言，通过它们各自的封装，可以进一步实现对不同具体实现子类的解绑，就更加好了。如果有一天你不想用Pico或者不想用抽象工厂，你可以选择其他更加合适的方法来实现解绑。而这个责任不应该交给对象自己来实现，因为我们根本无法预料这个对象将会以什么样的方式被构造出来，在什么时候构造出来，需要依赖什么其它外部机制构造出来（例如可能依赖数据库，或者依赖串行化），这最好是有外部使用这个对象的环境来决定

最终，我们希望能够让对象的创建、对象的销毁完全脱离对象的使用，垃圾收集器已经为我们提供VM级别的支持，而抽象工厂和工厂方法以及其它构造型设计模式，IoC从模式和框架的角度给我们另一半。

你这个已经是每次返回一个新的对象了，我要每次得到同一对象，我该怎么办，你是不是叫我重新再在上面包一个类，把第一次取到的对象缓存起来，以后每次去取那个对象？这个时候你每次new一个还有什么意义，你说可以把它改成单个，那我原先在用的代码怎么办？

再复杂一点，如果是需要在集群的服务器之间保持singleton，有的时候我需要用数据库来持久对象状态，通过数据库来保持唯一性，那你这份代码需要依赖于JDBC，这个时候如果一个普通的应用程序是不是也要依赖于JDBC？

区别在于你的代码是放在本类里面的，你这个类构造会直接依赖于你的环境和当前的假设，别人根本没办法重用你的类

构造函数为什么没有这些缺陷，因为我们可以通过另外一个类来实现和不同环境的结合，而我们正在谈论的这个类本身可以在任何地方使用而不需要修改任何代码.这是非常重要的，这是重用的基础，从我们谈的范围内来说，如果对照OCP，那么它是C，一旦关闭，永不修改。构造函数为什么没有这个问题，因为他自己不对任何构造自己的方法作出额外的假设(构造函数是最最近基本的假设了），而把构造的方法、意图和时机完全交给了外部，如果对照OCP，那么它是O。除非你的静态方法永远等同于new，不然的话，你任何一种实现方式都是对可能的构造方式进行无意义的假设，会限制其他场合对你这份代码重用的可能性，而如果永远等于new，那你这个静态方法还有什么用。

举例来说，假设有3个应用，对一个对象需要三种不同的构造方法，一个需要proxy以实现拦截，一个需要普通的java类做测试，另一个需要从数据库里面读取以保持集群之间的唯一性，我只需要对不同的环境写不同的工厂，而不需要去改你那个嵌在业务代码中的静态方法，即使改了也不能同时重用于三个场合，你这个时候告诉我这是外部设计的决策. 和你的实现细节无关，我可以在外面去包一个类，那我要你那个静态方法干什么，这个静态方法里面到底是返回proxy还是普通java对象还是从数据库里面读取，任何一个都没有意义

总而言之，任何在本类内部假设自己将被如何、何时、以何种方式进行构造的代码是极其不利于重用的（例如singleton就是一种限制重用的方法,只不过它由他自己适合的环境，因为任何系统里面肯定有一些类是可以重用，而有一些是特定于某个应用的）。因为你适合了一种环境的构造，必然会产生对另一种状况的不适合，所以最好的方式是什么也不假设，把如何构造的责任传递给另外一个类或者框架，那个类可以结合具体的重用场合实现构造，缓存，单件化，动态代理等等它希望做的任何动作。

面向对象的中心点是职责分离和变化频率的分离，对一个希望被重用的对象来说，它的业务代码是它变化频率较低的部分（这是重用的基本假设），而由于目前各种不用容器、测试、分布式计算、事务处理等等场合的需要，它如何被构造的可能性则是一个比它本身业务逻辑变化率高得多的东西，这两种职责必须被分离。


至于你这种设计方法完全依赖于子类和继承上的困难就更不用谈了。你说你的大多数类不让继承，OO最重要的概念就是差异编程和增量编程，这是提高内外部质量、提高生产率的核心思想，如果没有记错的话，《面向对象软件构造》第一章里面就明确地提出了几个重要的内外部指标，也是整个OO思想的软件工程基础。

概述
本文基于我去年为客户开发一个实时控制系统的工作。

本文的目标是：第一，重点描述实时系统规格的确定和用例之间的关系；第二，描述我们如何开发用例模型以及应用用例给我们带来了哪些益处。

要说明的第一件事情是为什么我们需要类似这样的一篇文章，然后我们再说明用用例来描述实时系统有哪些特殊之处。

在叙述为什么需要本文之后，我将描述一个具体项目和它的用例模型。我将重点描述用例模型的一些有趣的和有意义的特性，然后看看它们是如何有益于项目的。最后，我将讨论一些经验学习，并给出一些建议。

为什么我们需要这篇文章？
有一种看法认为用例只对你描述高度交互的系统有用，这些系统以IT系统为代表，如银行系统。例如，在银行中你可能需要处理一个抵押应用，它会有大量的用户交互。对于实时系统来说，并不存在那么多的用户交互。但是，如果实时系统具有有意义的外部可视的行为，用用例描述仍然对定义它们的规格是有用的，即使在一些用例中用户只是选择一些设置以及告诉系统完成一些功能。

在为客户工作了这么多年来，我发现用例被广泛地误解。尽管有很多与之相关的书籍、文章和培训课程。可能这些书籍、文章和培训课程都只关注于问题，因此它们提供大量的不同的方法。在这些著作中经常提到的一个例子是自动柜员机(ATM)。类似这样的例子对于说明一些问题是有用的，但在处理很大而且很复杂的实际系统时却通常没有明显的帮助。在实时系统中你将怎样处理出现的问题？有一些实际的例子可以对你有所帮助，本文恰恰可以给你提供这样一个实际的例子。

什么是实时系统的特点？
实时系统就是时间是最关键因素的系统。如果一个系统不理会它的时间需求，将可能导致生命危险，例如造成飞机失事。简单来说，对于这样的系统，对于时间需求处理的失败将可能导致产品的损害和上百万美元的损失。

实时系统也有最小限度的用户交互，对于这类系统怎么样定义它的用例是一件值得考虑的事情。实时系统通常都是高度算法化的，用例可能并不是最好的描述算法的文档方法。典型地，一个用例将引用在其它地方描述的算法。

如果你的系统具有有效的外部可视行为，那么用例能够极大地帮助你文档化你的系统需求。下面我描述的系统就有大量外部可视行为。在IT系统中应用用例的规则在这里仍然适用。

产品传送系统(PT)项目
用户是一个全球最大的铁矿生产商，它在澳大利亚西北的Headland港拥有一套铁矿传送工厂。铁矿从传送带网络传送到火车车厢，然后分类，称重，保存在仓库。最后铁矿从仓库中运出，再通过传送带运送到船上。

这个系统中每个东西都很大。有的传送带有7公里长，需要15分钟才能启动。运行传送带网络需要一个复杂的控制系统。对控制系统的一个需求是减少运行系统需要的人数。另一个需求是降低对运行系统的人的培训需求。图1是工厂的航拍图。

在左上角有一个船泊位。你可以看到有铁路线从右边连过去。卸货场在接近于中间的垂直线附近。在这个线的顶端是粉碎机。你可以在北面和南面的院子里看到仓库。传送带运行在卸货场和粉碎机，以及粉碎机和仓库之间。 你可以看到运输机从仓库装上铁矿，把它运到船上。运输机的容量非常大。在这个系统中，传送带可以在一小时内传送10000吨的铁矿！

有一些能够增加系统复杂度的需求非常值得关注。控制系统在避免溢出的情况下要达到最大的生产能力。出口容量在2004年从每年67M（百万）吨增加到81M吨，到2011年将扩大到90M吨。

基本概念：作业(route)
一个作业(route)由一系列传送带、定位和反馈设备组成，这些设备被选择和调配以便把铁矿从源位置运送到目标位置。作业可以是单独的，也可以共享设备以便允许把铁矿分开运输，从一个源位置运送到多个目标位置，或者组合运输，从多个源位置运送到一个目标位置。这些作业由操作员创建、维护和删除。一旦操作员启动作业，系统就开始工作，按照正确的顺序启动每个工作，以及处理一些异常状态例如有不合适的产品已经在传送带上。

为了达到生产力的需求，控制系统采用激进的启动和错误处理策略。尽管已经存在的系统在一个时间点一个作业只能启动一条传送带，当它达到最大速度后，再启动下一条，依此类推。 新的控制系统在一个作业中将同时启动所有的传送带－－注意我们的传送带的长度不同，启动时间和容量也不同。在出现问题时，新的系统试图尽可能关闭最少数量的设备以避免溢出，因为启动一个长的传送带需要15分钟。无论什么可能情况，设备都将保持运行，直到铁矿有可能溢出为止。系统需要同时运行作业，以便矿石能够传送到多个目标位置或者把矿石从多个源位置组合到一个位置。

设备失败的处理是全自动的。当一个传送带一小时可以传送超过10000吨矿石时，你可以想象出现问题时不能很快停下传送带的后果。这个结果并不是你可以用独轮车能够清理干净的！你将不得不使用一些重型设备来清理那些溢出的矿石，而且需要花费很长的时间。甚至有更坏的结果，比如一个错误导致矿石已经倒进了船的甲板上。

PT系统的用例模型
本文的工作基于IBM(r) Rational Unified Process(r) (RUP(r))和一本名为“用例建模”的书，这本书由Kurt Bittner和Ian Spence合著。用例是一个可供选择的写需求的方法。在过去，我们基于一个词"shall"来书写这些声明。在几年前我曾经在一个国防项目工作，它包括22卷需求文档，没有人能够真正全部理解它们。确认所有的需求描述是正确的和一致的是一件非常困难的事情。用例可以帮助我们处理这类问题。用例把需求放在系统提供给用户和有关人员的上下文中。 按照顺序描述每个用例以消除上下文的冗余，这些冗余在用传统的基于"shall"的需求描述方法中是必然包括的。

这里仅仅描述用例模型的一些特点，因为全部模型太大，也太复杂。用例的规范非常长，也非常细致。

识别角色(actor)
在整个操作开始前主要工作集中在识别角色是非常重要的，因为它可以确定系统的边界，清楚地指示哪些是在系统范围内，哪些在系统范围外。我们不想开发那些我们没有必要付钱的东西。在PT系统中，运输机是一个我们需要交互的系统。这里我们只需要知道运输机干什么工作，并不需要控制它如何工作，我们也不需要修改它。既然我们不控制运输机，它就在我们的系统范围之外，作为一个角色模型存在。我们有Ship-Hatch Loaders, Stackers, Sampling Stations 和Dust Control Systems - 所有这些外部系统都作为角色模型。图2显示部分这个系统的角色。

在图2中，角色使用UML 包分组。在左边是角色包。最重要的一个在左上角。CRO 就是Control Room Operator，中央控制室操作员。其它重要的还有在左下角的RSMT(Root System Maintenance Technician，根系统维护技术员)。

其它的包包括所有不同的设备角色。一些用例提到我们管理的通用设备，另一些将提到特定的不同类型的设备。

在图的下方有一些与我们交互的外部设备。左边的一个是PMAC，一个已经存在的系统用来处理我们的用户界面。如果它仅仅是与我们的系统相关的用户界面，那么我们不需要把它看作角色，因为实际上角色是CRO。但是它实际上是我们相关的角色，因为我们给它传递信息，并且从它那里收集信息。

电力负荷管理系统Power Load Management System (PLMS)是值得关注的。在Headland港，港口工厂有自己的电站。当你启动7KM长的传送带，并在上面运行数千吨的矿石是，它需要大量的电力供应。因此，传送带的启动实际上是错开的，以便降低电站的负荷。只要你想启动传送带，PT系统都将询问电站并得到电站的许可。

确定用例
用例是一种简单的可选择的定义需求的方法。首先，让我们再次回顾一下用例的定义：

用例定义一个由系统完成的操作序列，它给操作者和相关人员提供可观察到的有价值的结果。

在识别IT系统的用例时，牢记“可观察到的有价值的结果”是非常重要的，这一点在这里仍然适用。我们将看到系统提供给操作者和相关人员的值。在我们的例子中，中央控制室操作员是一个角色，但是整个公司实际上都可以看到系统把矿石从一个地方移动到另外的地方。“由系统完成的操作序列”声明了在用例中系统怎么做的描述。这些每个都是我们系统的需求。最后，用例是一个完整的有意义的事件流。把“完整的有意义的事件流”和“可观察到的有价值的结果”这两个概念组合起来可以帮助避免识别出不完整的功能片断并把它称为用例。

用例和角色在用例图中以图形化的方式描述。图3显示了 PT系统的顶层用例图。你很快就能看到 PT系统的用例分为4组：Operation, Administration, Configuration 和System Startup。

PT系统中用例相关的操作在图4中显示:

PT的主要用例是“传送产品”。正如这个用例的名字那样，你可以看到在这里系统提供给用户和有关人员的价值是把产品从一个地方运送到另一个地方的能力。这个软件也能够用来运送其它物品，不仅仅是铁矿。例如它能够用来在制药厂传送药片。传送产品是一个很大的用例，但它抓住了最根本的因素，即我们的系统存在的原因，即给我们的操作者和相关人员提供的价值。

在图4中我们看到与电源管理系统(PLMS)的交互，请求启动设备，我们也看到了用例与我们控制的设备的交互。我们可以显示每个设备角色，但那样的话，图就显得太混乱了。

在图4中，从CRO到传送产品的箭头，表示这个操作员发起或者启动这个用例。用例到设备和PLMS操作者的箭头表示这个用例或者系统与设备和PLMS交谈。从船舱装载系统(SHLS)的箭头表示SHLS发起与系统的交互－－特别地，SHLS可以请求铁矿流暂时中断以便装载机移动到另一个舱室。

有关管理、配置和系统启动的用例在图5中描述。

在这里我们可以做的一件事情是在对系统的操作影响最小的情况下更新系统软件。因此我们有"Perform Software Upgrade" 用例。我们也有"Start System" 用例 -这个用例经常被忘掉。系统有人身安全优先的规则，Start System 用例包括在系统启动时进行的所有安全检查的规格说明。你一定不想在服务人员在传送带上工作时偶然地启动它！

Route System Maintenance Technologist (RSMT)是一个负责创建作业或者预定义作业的人，预定义的作业稍后由CRO使用。我们可以在系统中添加新的设备，定义新设备的种类以及定义系统传送产品的特点。港口工厂处理来自不同矿山的不同类型的铁矿，它们有不同的颗粒大小、不同的矿石成分等级。我们要非常小心的一件事情是避免把错误的矿石装到船上去。

关于用例图这里要警告一下：用例图只是冰山的一角。直到你开始写用例规格之前不要去重新分解、重组和调整用例模型。用例的规格大约95％来自用例模型。用例图仅仅给你一个模型的总体、全面的概要描述。

正如我前面提到的，用例描述“事件流”。图6显示不同种类的事件流和它们是如何在用例规格中描述的。

从顶部到底端底蓝色粗线条表示主事件流(Basic Flow)。它表示每件事情都按照正确的方式发生。有很多种分支流(Alternate Flow)。描述处理设备故障的分支是一个很好的分支流的例子。另一个例子是描述操作员取消了前面请求的动作。

这里一个非常重要的结构是子事件流(Subflow)。子事件流就象子程序调用。我们试图保持主事件流简单易读，没有子事件流是很难做到这一点的。例如，我们使用子事件流来描述我们启动或者安放设备位置时发生的细节。这些过程每个都相当复杂，如果我们都在主事件流上描述，那么它将变得很长并且很难理解。

图7显示一个主事件流的片断：

在第二步，系统检查作业是否有效。如果系统确认作业无效时会发生什么？这在分支流中描述。在用例规格中我们使用脚注来指示分支流，脚注文本包括指向相关文档章节的交叉引用。这将减少描述事件流的混乱，使得它更容易读。在这里我使用 "§" 符号指示存在一个分支流。我也用高亮的红色表示这是项目术语表－－一份很重要的文档－－中的定义。

在第3步，系统检查选择的作业的启动策略。"Starting/Positioning Stragegy 2.1"表示交错启动，它需要在启动作业前所有的设备都到位。这个启动策略在分支流中描述。最后系统向PLMS询问是否允许启动作业。如果不允许时发生的事情也在分支流中描述。

在图8中，我们将看到分支流和子事件流的例子。

分支流定义当基于某种原因设备不到位，因而这个作业不能启动时应该发生什么。系统给操作者发一个消息，建议在我们实际启动作业前把设备移动到相应的位置。在这个点上，用例就结束了。

子事件流的例子提供我们实际上如何启动作业的更详细的信息。系统检查全部作业设备是否畅通（传送带上没有其它物品）。如果正常，系统同时移动所有需要定位的设备到相应的位置，包括作业自己需要的设备和要与其它作业共享的设备，然后我们交错启动所有的设备以避免电力过载。当全部设备都运行起来后，我们告诉操作员作业已经启动，然后用例结束。第16步的 "a", "b" 和 "c" 也涉及了子事件流。

特殊需求
有很多需求，特别在实时系统中，不能归结到用例的事件流中。通常它们是非功能需求如性能、可用性等等。那些与给定用例相关的特殊需求可以归结到与用例规格定义相关联的"特殊需求"一节中。有时为了方便，甚至功能需求也可以放到这一节中。图9即为一个示例。

第一个例子可以作为一个分支流，但是为了使主事件流基于阅读，我们可以简单地说：“系统检查是否有特殊需求的xyz节中规定的不能启动的状况发生”。在这个特定用例中，如果我们在码头传送带上还有东西，而传送带由于完成了往甲板上卸矿石已经停止工作，那么我们将给操作员发出一个警告。

第二个例子是一个算法的详细描述，这个算法用来调整传送带的传输量和传送速度。这里，主事件流可以简单地描述：“传输量和传送速度按照特殊需求中的uvw节进行调整。”

结构化用例
用例的结构化是一个高级课题。你也可以不使用这项技术来完成一个系统的需求文档。用例的结构化可以让你避免冗余信息，保证用例文本只存在一个单独的可维护的位置。关于结构化的重要的一点是，你必须避免让用例模型和用例变得难以理解。

结构化技术在图10中显示。

在图的左边，我们有一个用例，它有一个主事件流，一个分支流和一个子事件流。子事件流和分支流都可以作为单独的用例分出来。分支流变成一个新的用例，扩展了原始的用例。子事件流也变成一个新的用例，它包含在原始的用例中。一般来说，包含关系仅仅用于一个分支流共用于多个用例的情况。这就是我们如何确保仅仅写一个分支流，仅仅有一个维护地点的方法。通常，当需要在已经存在的用例上增加新功能而且你又不想修改原始用例时，可以创建一个扩展流

把这些结构化技术用到我们的产品传送系统后，改变后的用例如图11所示：

这些新的用例称为“抽象用例”，因为它们没有操作者，你不能直接调用它们。如果我把这些抽象用例隐藏起来，你仍然可以相当清楚地看到系统的主要功能。

一系列的错误处理用例都以这样的声明开始：“当系统检测到设备故障”或者“当系统检测到超载”等。然后用例继续描述系统在这些情况的响应。

在图11的顶部，我提炼出了两个抽象用例：一个是启动作业，另一个是停止作业。从技术角度来说，我在这里破坏了规则：包含用例应当被多于一个的用例共享。我之所以这么做是因为，如果我在“传送产品”用例中写出所有的内容，文档将超过300页。把它分开可以让很多人同时在系统的不同部分描述需求。

补充需求
我们有很多补充的需求，它们不适合放在任何用例中。因为特定的需求与具体的用例相关，这些都是典型的非功能性需求。在你在用例中的需求和补充的需求之间存在一个平衡。当你进行实时系统工作时，你可能发现会比你进行IT系统开发时有更多的补充需求。这是由于在实时系统中有更多的有时间要求的需求，它们都在补充需求中描述。

下面是放在补充需求中的非功能需求的例子：

• The PT System shall, upon notification of fault requiring upstream interlocks to be set to "False", set Upstream interlocks to False within 0.60 second.
• The PT System annual Availability (refer Glossary) shall exceed 99.954%.
• The PT System Maintenance Procedures shall comply with the Client's maintenance strategy for real-time PLC control systems.
• The PT System shall use the existing PMAC System for the CRO, PCO, and viewer interface.
• The portion of the PT System controlling route interlocking and directly connected to route equipment and interconnected systems shall be PLC based and, in the event of failure of higher level control within the PT System, shall be capable of safely operating any route currently starting, running, or stopping.

功能需求也可以包括在补充需求中。当有些功能用用例写还不如用补充需求描述时，可以把这些需求放在补充需求中，而不用写一个完整地用例规格定义。下面是一些这样的例子:

• The System shall advise the Operator if the sum of the source feed setpoints for a route is more than 10% less than the minimum capacity for the route.
• If a feed source has been enabled for a route with a cleanup destination, the System shall:
  • Raise an alarm
  • Re-raise the alarm every 10 minutes while the condition persists
• If during a ship hatch change, burden is on the wharf conveyor at or within the gross stopping distance of the shiploader, the System shall:
  • Raise an alarm
  • Issue a message to the operator
  • Stop the wharf conveyor
  • Issue a request to the SHLS to stop the shiploader boom conveyor

用例的益处
用例有以下益处：

• 给出需求的上下文，清楚显示为什么需要系统。
• 把需求按照时间顺序排列，使需求比传统方式更加容易读，更容易理解。
• 更容易得到客户的认同，因为他们能更容易地阅读和理解。
• 可以用作项目计划、分析、设计、测试和文档的基础。

另一方面，关于用例有很多不正确的观点。第一个是，象当前多种书籍和文章中指出的，传统的书写需求的方法能够更严谨和精确。实际上并不是这样的，我们在这个项目中也能写出非常严谨而精确的用例。

另一个看法是任何没有经过专业培训的人都可以写用例。写传统需求文档的原则在这里仍然适用。你需要从外部视角来看系统做什么。你不需要写出系统是怎样做的。象传统的需求一样，你写的用例需求也应该是可测试的。新手经常继续使用老的诸如功能分解的习惯。有开发背景的人经常倾向于从系统内部而不是用外部视角描述。

用例贯穿整个项目
我前面提到，用例在整个项目中都有用。

项目计划
在这里我们没有足够的空间讨论分配用例迭代的准则。只能简单说，这些准则基于RUP的风险评估。下面是分配的迭代：

用例分析
用例分析是一个用来识别对象、类、类属性和类方法的过程。 由于这个项目的实现方法是非面向对象的，我们使用一个映射把面向对象的分析模型转换到过程设计模型。图12显示对启动作业用例进行分析的部分结果：

测试计划
我极力推荐下面的一篇文章：June 2001 Rational Edge，Jim Heumann，"Generating Test Cases from Use Cases"。在我们的PT系统中使用这种方法识别测试用例。图13显示启动作业用例的迭代2的测试用例。注意在测试用例和用例需求之间的连接。它可以帮助保证需求都被测试，以及测试用例随着需求变更而更新。

经验学习
1. 集中在外部可视的行为上。这一点怎么强调都不过分，这就是我为什么这里再次重复的原因。在这个项目中，我经常告诉那些需求分析人员，让他们想象它们是飞翔在港口工厂的用户，让他们问自己他们想要看见发生的事情。如果你写的描述一些事情的需求不可见，那么你将不能对它进行测试。

2. 不要引入设计。这与经验1相关。下面是一个例子

每个作业都拥有一个使能信号，这个信号来自于作业的运送源。使能信号在操作间内部驱动作业运送来源的物理信号。(用例在这里描述了系统内部信号。)

有很多原因使你不应该这么做。首先，它使得测试很困难，因为描述的行为在外部不可见。第二，如果你把设计信息放到用例中，你就需要照着这些信息实现，因为那是需求，因此你不仅必须照着它来进行演示说明，而且它也限制你的设计人员的实现方式。

3. 不要为内部监控过程写用例。在这个系统中，由于是实时系统，有很多在系统内部运行的过程用来检查、监控和轮询其它设备。你不应该在你的用例中描述这些，因为它是设计，它仅仅是一种可能的实现方式。

除非过程与系统的目标相关，例如在建筑监控中的“监控建筑”用例中，你应该把它们写在补充需求规格中。例如

• 系统应该每200毫秒或者更短的时间内检查所有设备的状态。
• 系统应该在设备失败的200毫秒内开始响应。
• 系统应该保证产品混合率在设定值的+/-5%范围内。

在用例的分支流或者扩展用例中，都可以描述如果系统检测到问题时发生什么事情。这些需求可以使你设计诸如轮询设备或者设备产生中断等的过程，然是它们属于设计应该考虑的事情，不属于需求的范围。

4. 不要太早"冻结"用例。在项目中太早冻结用例将会导致很多问题，因为在你和你的客户更好地理解需求时，你可以找到机会重新组织用例，或者你将引出新的用例，或者你要修改现有的用例。需求变更会发生，但这需要在一个迭代过程的管理和限制下进行，以便进行适当的影响评估，以及合适的预算和计划日程的变更。如果你使用迭代过程，你至少有在后面的迭代中改正的机会。

5. 不要过于追求完美的用例模型而超出项目计划日程。这是经验4的必然结论。你从来都不可能得到一个完美的用例模型。在某个点上，你将不得不停下修补完善用例模型的工作，开始实际的系统开发工作。即使用例模型并不完美，你也可能开发出符合用户需求的系统。最后，图14显示PT用例模型的实际样子。

你将看到选择作业、启动作业和停止作业是主要的用例。这里并没有围绕着传送产品用例把所有其它用例联系在一起，我们不得不在附加需求中描述其它的需求。来自操作员和相关者的选择、启动和停止作业的需求并没有进行评估。用例模型不完善的主要原因在于，需求必须在某个点冻结，以便开发者不会频繁地面对不确定的开发目标，系统应当被实际开发测试和部署。

6. 不要害怕收集细节信息。用例假定容易被每个人阅读，但是这并不意味着你在大街上随便找一个人，给他一个描述复杂系统的用例，就能够期望他能够理解。

需要问你自己的问题是：你的客户需要多大程度的细节？你想给你的开发者多大的范围？如果你在用例中没有给出很多细节，你就让你的开发者自行作出决定。你想这样做吗？你的开发者可能有丰富的经验而你也很高兴这么做。另一方面，如果你正在进行实际的开发，没有充分的细节不一定是可以接受的。你需要给开发者和测试者描述以足够的细节信息，说明什么对于客户是重要的。

如果有大量的细节信息，可以考虑把它们放到特殊需求或者附加需求中，或者用活动框图(Activity Diagram)来补充用例。(参见经验9)

7. 不要引入用例间的直接交互。用例不能相互交互。它们可以相互影响，但是只能通过操作系统状态来影响。

8. 不要把有关解决资源争夺问题的架构决策放到用例中。这一点与第2课有关，例如，当操作员使能一个作业的来源时，同时第二个作业共享同一个来源因此得到一个来源不可用的错误时，会发生什么情况？

这些状况应该在不同的用例中描述。在每个用例，你只需要简单描述在给定环境下你想要系统做什么。在这个例子中，系统内部如何工作，什么信号发到设备，这些都属于架构或者设计问题。系统架构需要解决这些问题，诸如保证信号在非常接近情况下接收、不同顺序接受或者高频率地接收。

9. 使用活动框图以便使得复杂的用例能够易于理解。活动框图可以作为用例的规格创建。

总结
在PT系统中使用用例给项目带来很大的价值。只要有外部可见的系统行为，就应该使用用例来定义需求规格。

对任何系统来说，在确定用例时，要集中在系统的目标上以及系统给相关人员提供的价值。在写用例时要维护一个系统的外部视图。

对于实时系统，附加需求在整个系统需求中占有更大的百分比。

by Hans-Erik Erikkson and Magnus Penker

The case study in this article provides a feel for how UML is used in the real world. The application, which handles the borrowing and reserving of books and magazines in a library, is large enough to put UML through some realistic paces.

If it were any larger, we couldn't fit it in the magazine.

We analyze and describe the app in an analysis model with use cases and a domain analysis. We expand it into a design model that describes representative slices of a technical solution. Finally, we code a piece of it in Java. (The code, plus the complete analysis and design models are supplied online, in a format readable by the included evaluation copy of Rational Rose.)

Remember that what's shown is only one possible solution. There are plenty of others, and there is no "right" solution for all circumstances. Of course, some solutions will prove better than others, but only experience and hard work will result in that knowledge.

Requirements
Typically, a representative of the end user of the system writes the text requirement specification. For the library application, it looks like this:

• It is a support system for a library.
• A library lends books and magazines to borrowers, who are registered in the system, as are the books and magazines.
• A library handles the purchase of new titles. Popular titles are bought in multiple copies. Old books and magazines are removed when they are out of date or in poor condition.
• The librarian is an employee of the library who interacts with the customers (borrowers) and whose work is supported by the system.
• A borrower can reserve a book or magazine that is not currently available in the library so that when it's returned or purchased by the library, that person is notified. The reservation is canceled when the borrower checks out the book or magazine or through an explicit canceling procedure.
• The library can easily create, update, and delete information about the titles, borrowers, loans, and reservations in the system.
• The system can run on all popular technical environments, including Unix, Windows, and OS/2, and has a modern graphical user interface (GUI).
• The system is easy to extend with new functionality.

The first version of the system doesn't have to handle the message that is sent to the borrower when a reserved title becomes available, nor does it have to check that a title has become overdue.

Analysis
The analysis is intended to capture and describe all the requirements of the system, and to make a model that defines the key domain classes in the system (what is handled in the system). The purpose is to provide an understanding and to enable a communication about the system between the developers and the people establishing the requirements. Therefore the analysis is typically conducted in cooperation with the user or customer.

The developer shouldn't think in terms of code or programs during this phase; it is just the first step toward really understanding the requirements and the reality of the system under design.

Requirements Analysis. The first step in analysis is to figure out what the system will be used for and who will be using it. These are the use cases and actors, respectively. The use cases describe what the library system provides in terms of functionality: the functional requirements of the system. A use-case analysis involves reading and analyzing the specifications, as well as discussing the system with potential users (customers) of the system.

The actors in the library are identified as the librarians and the borrowers. The librarians are the users of the system and the borrowers are the customers, the people who check out and reserve books and magazines, although occasionally a librarian or another library may be a borrower. The borrower is not intended to directly interact with the system; the borrower's functions are done on behalf of the borrower by the librarian.

The use cases in the library system are:

• Lend Item
• Return Item
• Make Reservation
• Remove Reservation
• Add Title
• Update or Remove Title
• Add Item
• Remove Item
• Add Borrower
• Update or Remove Borrower

Because a library often has several copies of a popular title, the system must separate the concept of the title from the concept of the item.

The library system analysis is documented in a UML use-case diagram as shown in Figure 1. Each of the use cases is documented with text, describing the use case and its interaction with the actor in more detail. The text is defined through discussions with the user/customer. The descriptions of all the use cases are included online; the use case Lending Item is described as follows:

1. If the borrower has no reservation:
   • A title is identified.
   • An available item of the title is identified.
   • The borrower is identified.
   • The library lends the item.
   • A new loan is registered.
2. If the borrower has a reservation:
   • The borrower is identified.
   • The title is identified.
   • An available item of the title is identified.
   • The library lends the corresponding item.
   • A new loan is registered.
   • The reservation is removed.

Besides defining the functional requirements of the system, use cases are used in the analysis to check whether the appropriate domain classes have been defined, and they can be used during the design process to confirm that the technical solution is sufficient to handle the required functionality. The use cases can be visualized in sequence diagrams, which detail their realization.

Domain Analysis. An analysis also itemizes the domain (the key classes in the system). To conduct a domain analysis, read the specifications and the use cases and look at which "concepts" should be handled by the system. Or organize a brainstorming session with users and domain experts to try to identify all the key concepts that must be handled, along with their relationships to each other.

The domain classes in the library system are as follows: BorrowerInformation (so named to distinguish it from the actor Borrower in the use-case diagram), Title, Book Title, Magazine Title, Item, Reservation, and Loan. They are documented in a class diagram along with their relationships, as shown in Figure 2. The domain classes are defined with the stereotype «Business Object», which is a user-defined stereotype specifying that objects of the class are part of the key domain and should be stored persistently in the system.

Some of the classes have UML state diagrams to show the different states that objects of those classes can have, along with the events that will make them change their state. The classes that have state diagrams available online are Item and Title.

A sequence diagram for the use case Lend Item (the borrower does not have a reservation) is shown in Figure 3. Sequence diagrams for all the use cases are online.

When modeling the sequence diagrams, it becomes obvious that windows or dialogs are needed to provide an interface to the actors. In this analysis, it was sufficient to be aware that interface windows are needed for lending, reserving, and returning items. The detailed user interface is not specified at this point.

To separate the window classes in the analysis from the domain classes, the window classes are grouped into a package named "GUI Package," and the domain classes are grouped into a package named "Business Package."

Design
The design phase expands and details the analysis model by taking into account all technical implications and restrictions. The purpose of the design is to specify a working solution that can be easily translated into programming code.

The design can be divided into two segments:

Architectural design. This is the high-level design where the packages (subsystems) are defined, including the dependencies and primary communication mechanisms between the packages. Naturally, a clear and simple architecture is the goal, where the dependencies are few and bidirectional dependencies are avoided if at all possible. Detailed design. Here all classes are described in enough detail to give clear specs to the programmer who will code the class. Dynamic models from the UML are used to demonstrate how objects of the classes behave in specific situations.

Architecture Design
A well-designed architecture is the foundation for an extensible and changeable system. The packages can concern either handling of a specific functional area or a specific technical area. It is vital to separate the application logic (the domain classes) from the technical logic so that changes in either don't impact the other part. One goal is to identify and set up rules for dependencies between the packages (e.g., "subsystems") so that no bidirectional dependencies are created between packages (in order to avoid packages becoming too tightly integrated with each other). Another goal is to identify the need for standard libraries. Libraries available today address technical areas such as the user interface, the database, or communication, but more application-specific libraries are expected to emerge as well.

The packages, or subsystems in the case study are as follows:

User-Interface Package. These classes are based on the Java AWT package, a standard library in Java for writing user-interface applications. This package cooperates with the Business-Objects package, which contains the classes where the data is actually stored. The UI package calls operations on the business objects to retrieve and insert data into them.

Business-Objects Package. This includes the domain classes from the analysis model such as BorrowerInformation, Title, Item, Loan, and so on. The design completely defines their operations and adds support for persistence. The business-object package cooperates with the database package in that all business-object classes must inherit from the Persistent class in the Database package.

Database Package. The Database package supplies services to other classes in the Business-Object package so that they can be stored persistently. In the current version, the Persistent class will store objects of its subclasses to files in the file system.

Utility Package. The Utility package contains services that are used in other packages in the system. Currently the ObjId class is the only one in the package. It is used to refer to persistent objects throughout the system including the User-Interface, Business-Object, and Database packages.

The internal design of these packages is shown in Figure 4.

Detailed Design
The detailed design describes the new technical classes—the classes in the User-Interface and Database packages—and fleshes out the Business-Object classes sketched during the analysis. The class, state and dynamic diagrams used are the same diagrams used in the analysis, but they are defined on a more detailed and technical level. The use-case descriptions from the analysis are used to verify that the use cases are handled in the design; sequence diagrams are used to illustrate how each use case is technically realized in the system.

Database Package. The application must have objects stored persistently, therefore a database layer must be added to provide this service. For simplicity, we store the objects as files on the disk. Details about the storage are hidden from the application, which calls common operations such as store(), update(), delete(), and find(). These are part of a class called Persistent, which all classes that need persistent objects must inherit.

An important factor in the persistence handling is the ObjId class, whose objects are used to refer to any persistent object in the system (regardless of whether the object is on disk or has been read into the application). ObjId, short for object identity, is a well-known technique for handling object references elegantly in an application. By using object identifiers, an object ID can be passed to the generic Persistent.getObject() operation and the object will be retrieved from persistent storage and returned. Usually this is done through a getObject operation in each persistent class, which also performs necessary type checks and conversions. An object identifier can also be passed easily as a parameter between operations (e.g., a search window that looks for a specific object can pass its result to another window through an object ID).

The ObjId is a general class used by all packages in the system (User Interface, Business Objects, and Database) so it has been placed in a Utility package in the design rather than in the Database package.

The current implementation of the Persistent class could be improved. To that end, the interface to the Persistent class has been defined to make it easy to change the implementation of persistent storage. Some alternatives might be to store the objects in a relational database or in an object-oriented database, or to store them using persistent-object support in Java 1.1.

Business-Objects Package. The Business-Objects package in the design is based on the corresponding package in the analysis, the domain classes. The classes, their relationships, and behavior are preserved, but the classes are described in more detail, including how their relationships and behavior are implemented.

Some of the operations have been translated into several operations in the design model and some have changed names. This is normal, since the analysis is a sketch of the capabilities of each class while the design is a detailed description of the system. Consequently all operations in the design model must have well-defined signatures and return values (they are not shown in Figure 5 due to space restrictions, but they are present in the model online). Note the following changes between the design and the analysis:

• The current version of the system does not have to check whether an item is returned in time, nor does the system have to handle the ordering of reservations. Therefore the date attribute in the Loan and Reservation classes has not been implemented.
• The handling of magazine and book titles is identical, except for the maximum lending period, which doesn't have to be handled. The subclasses Magazine and Book Title in the analysis have thus been deemed as unnecessary and only a type attribute in the Title class specifies whether the title refers to a book or magazine. There's nothing in object-oriented design that says the design can't simplify the analysis!

Both of these simplifications could be removed easily if deemed necessary in future versions of the application.

The state diagrams from the analysis are also detailed in the design, showing how the states are represented and handled in the working system. The design state diagram for the Title class is shown in Figure 6. Other objects can change the state of the Title object by calling the operations addReservation() and removeReservation(), as shown in the diagram.

User-Interface Package. The User-Interface package is "on top" of the other packages. It presents the services and information in the system to a user. As noted, this package is based on the standard Java AWT (Abstract Window Toolkit) class.

The dynamic models in the design model have been allocated to the GUI package, since all interactions with the user are initiated through the user interface. Again, sequence diagrams have been chosen to show the dynamic models. The design model's realizations of the use cases are shown in exact detail, including the actual operations on the classes.

The sequence diagrams are actually created in a series of iterations. Discoveries made in the implementation (coding) phase result in further iterations. Figure 7 shows the resulting design sequence diagram for Add Title. The operations and signatures are exactly as they appear in the code online.

Collaboration diagrams can be used as an alternative to sequence diagrams, as shown in Figure 8.

User-lnterface Design
A special activity carried out during the design phase is the creation of the user interface.

The user interface in the library application is based on the use cases, and has been divided into the following sections, each of which has been given a separate menu bar in the main window menu:

Alternatively, perhaps you're a Project Manager, looking to formalise the OO design process a little to make sure you're getting the most from your move to C++/Java or a similar language.

In this paper, I take a look at the UML (Unified Modelling Language) notation for Object Oriented Analysis and Design - the emerging standard designed by Booch, Rumbaugh and Jacobson, each of whom previously had their own notations published independently.

The starting point is Object Modelling, a technique that enables you to focus on class structure, inheritance, etc., whilst avoiding language specifics such as pointer dereferencing.

Object Modelling In UML

Figure 1 - Subset of UML Object Modelling Notation  -  A Summary

Object Modelling is the central technique in UML. It is a language independent notation allowing the specification of classes, their data or attributes(private) and methods (public), inheritance, and other more general relationships between classes. The notation itself is fairly simple to grasp (see figure 1), however this hides the somewhat more subtle thought processes underlying a good model.

The best way to understand the notation is to look at an example. The following Object Model shows a simple Banking System, containing classes for Head-Office, Branch, Accounts held at that Branch, and the Customers who the Accounts belong to:

Figure 2 - A Simple Banking System Object Model

Examining this Object Model in more detail, we can see the following information about our class structure:

• A Head-Office class (containing "bankName" and "address" fields, otherwise known as attributes)  "administers" an (unspecified) number of Branch classes; whilst a Branch is "administered-by" exactly one Head-Office (the little black arrows indicates the direction in which the name given to a relationship should be read). On the diagram this relationship is represented by the line from the Head-Office class to the Brach class which is labelled "administers". The "1" at the Head-Office end of the line shows that exactly one Head-Office is associated with each Branch (as you would expect). The "*" at the Branch end of the line shows that a Head-Office "administers" many Branches - again as you would expect.

•  Similarly, a Branch class (which contains "manager" and "address" attributes) "holds" many Account classes; whilst each Account class "is-held-by" exactly one Branch.  We can also see that we have determined that an Account class has a "CalcCharges" method (also known as operations or member functions) defined. This method, when invoked, will look at the detail stored within the Account object, and apply the appropriate (undoubtedly extortionate) charges to the Account. The second method -"PrintStatement" - will take the details of the Account and print them out.

• The inheritance "triangle" (labelled "account-type") shows us that our system knows about three types of Account: the basic account (in this case a virtual class called Account), and two specialised accounts - the CurrentAccount and SavingsAccount - which are derived from Account. The fact that the "CalcCharges" is shown in both sub-classes indicates that its implementation is re-defined for these classes (in C++ terms it is a virtual function). This is indicative of the fact that charges on a "SavingsAccount" are calculated in a completely different manner to charges on a "CurrentAccount".

• Implicit in the decision to use inheritance and redefine methods in sub-classes is the fact that the system, when implemented, will use the polymorphism features of the target language (C++, Java ...) to enable all Accounts to be treated in a single coherent fashion, regardless of the particular charges mechanism involved. This is of course one of the reasons we use an object-oriented development language in the first place.

• Each Account "belongs-to" exactly one owner - the Customer class on the diagram. Customers, on the other hand, may have many Accounts.

It's worth noting here that because an Account may "belong-to" a Customer, both CurrentAccounts and SavingsAccounts may also belong to a Customer.  In   other words, the "belongs-to" relationship between Accounts and Customers is inherited by the CurrentAccount and SavingsAccount classes. This fact simplifies the diagram considerably, removing the need for these relationships to be noted explicitly. This simplification will also be apparent in our final implementation of the system.

• Finally, you can see that there are two relationships shown between the Account and the Transaction classes. This is because, in our banking system, each individual transaction (credit, debit, etc.) must have two associated accounts - the Account the money is "debit(ed)-from", and the Account the money is "credit(ed)-to". This enables the bank to record exactly where each transaction has come from, and gone to, so to speak.

These last point brings out an interesting feature of what is being shown on an Object Model: clearly it wouldn't make sense for each Transaction to be "debit(ed)-from" and "credit(ed)-to" the same Account - no money would be transferred! Obviously, although the lines (relationships) are shown to the same Account class, they do not (necessarily) represent links to the same Account object at run-time.

A relationship shown on an Object Model indicates that some kind of run-time link will exist between two instances of the classes shown on the Object Model. Thus the Branch to Accounts relationship should be read as follows:

An instance of the class Branch will be linked to (zero to) many instances of the class Account, whilst an instance of the class Account will be linked to (one and only) one instance of the class Branch.

This can be shown more clearly by the following instance diagram (instance diagrams are used to assist in understanding and clarifying Object Models - they also give quite a hint as to how relationships can be implemented in C++!):

Figure 3 - Instance Diagram Showing Branch and Account objects

By now, you may be beginning to see how Object Models can assist the analysis/design process. They assist in the clarification of the relationships that should be (somehow) represented in a software system. The important point to note hear is that we are first working out what relationships we need to represent in our system ("belongs-to", etc.), without worrying too much about exactly how they should be stored. Put another way, Object Modelling allows us to focus on exactly what problem we are trying to solve, before we look at the best way of implementing our model in a particular programming language.

Implementing Object Models
OK, that's fine, you may say, but how do Object Models relate to C++ or Java, exactly? Lets take a look at a sub-set of our previous example:  

Figure 4 - Subset of Banking Model

Our Object Model shows us that we need four classes: Transaction; Account; Current Account and Savings Account, and that our implementation must enable us to represent the fact that any particular Account has two sets of Transactions associated with it - which will be needed to implement the PrintStatement method. The Account, CurrentAccount and SavingsAccount classes are easily mapped to the C++ (or Java) inheritance mechanisms:

class Account {
       /* ... data ... */
public:
       virtual void CalcCharges();
       void PrintStatement();
};

class SavingsAccount : public Account {
       /* any additional data */
public:
        virtual void CalcCharges(); /* re-definition */
       /* use the base class PrintStatement method */
};

class SavingsAccount : public Account {
       /* any additional data */
public:
       virtual void CalcCharges(); /* another re-definition */
       /* use the base class PrintStatement method */
};

Figure 5 - Mapping Object Model Inheritance To C++ Inheritance

The Transaction class may be implemented as follows:

class Transaction {
        long value;   /* stored in pence */
       date_t date;  /* date of transaction */
public:
        /* Access and Update functions */
        Date(date_t); /* set */
        date_t Date(); /* get*/
        Value(long);  /* set */
        long Value(); /* get */
};

Figure 6 - Transaction Class In C++

This leaves us with the "debit-from" and "credit-to" relationships to be implemented. Here we have a number of choices: linked-lists; collection-classes; (dynamically bounded) arrays of pointers; etc. could all be used to represent these relationships.

class TransactionList {
       TransactionList * next; /* ptr to next element */
       Transaction * data;  /* store the transaction here */
public:
       void Data (Transaction *);   /* set */
       Transaction * Data();    /* get */
       void NextItem(TransactionList *); /* set next ptr */
       TransactionList * NextItem();  /* get next ptr */
};

Figure 7 - Simple Transaction List Handler Class

For brevity, a linked-list class with a somewhat limited interface is used in this example - although this may not the best choice.
Amending our Account class definition to use this class gives us the following new definition:

class Account {
       TransactionList * debitedFrom; /* debited from Tx list*/
       TransactionList * creditedTo;  /* credited to Tx list */
public:
      virtual void CalcCharges();
      void PrintStatement();

      /* some new methods to manipulate the Transaction list */
 DebitTx (Transaction *);   /* Add a debit Tx */
 CreditTx (Transaction *);  /* Add a credit Tx */
 Transaction* NextDebitTx();     /* Iterator:get debit Tx */
 Transaction* NextCreditTx(); /* Iterator:get cred Tx  */
};

/* sample method implementation */
Account::DebitTx(Transaction * theTx) {
          /* add a new list contained at the beginning of the list */
 TransactionList * tmpTxLp = debitedFrom;
 debitedFrom = new TransactionList;
 debitedFrom->NextItem(tmpTxLp);

 /* new put the transaction data into the list */
 debitedFrom->Data(theTx);
};

Figure 8 - Account Class amended to use Transaction List

Although this is a somewhat simplistic implementation - it demonstrates the point that the model shown in figure 4 is easily translated into C++. Of course, better implementations of the "debit-from" relationship are possible, but the fact that the Account class interface completely hides the underlying implementation of this relationship means that we can improve on our first cut implementation at a later date with little impact on our overall system code. In other words, use of the Account class interface has limited the impact of the relationship implementation method: something we strive to achieve when writing OO based applications.

A couple of other points are worthy of note at this stage:

• The linked list class contains pointers (references in Java) to Transaction objects. This is implicit in our Object Model, and is what the system's users would expect to see. To see why, consider the case when a new Transaction value is entered in error. The Transaction is linked to two accounts ("debit-from" and "credit-to"). If the Transaction object is shared, only one object need be modified to rectify the situation. Using two objects would either mean that either the system has to update two objects (equals more coding work), or that the user has to update two Transactions (equals greater potential for mistakes).

• Although our Object Model "debit-from" relationship uses a linked list, there are many alternatives to this choice - including the use of a relational database to underpin the system. The point is, however, no matter what mechanism is used, we are actually trying to implement a "many-to-one" relationship between an Account and a Transaction. It is this relationship that exists in the banking problem domain - not a relationship involving linked lists or collection classes. Object Modelling enables us to spot the relationship required by the problem domain, and then choose the best way of implementing it.

• So far, we have only implemented the "debit-from" relationship in one direction- from the Account class to the Transaction class. Our model does not (yet) specify in which direction the relationship will be traversed. If we need to traverse the relationship in both directions - getting from the Transaction to the related Account - our implementation will prove insufficient, and some form of double pointer schema may be needed. Much work would have been saved if we had known this fact before we had started writing the code.

• Although our Object Model provided a starting point for our implementation, it was not complete, for example new methods have been added to the Account class.

• Other factors may also influence our choice of implementation: do we need a direct form of access - for example using a Transaction number to go directly from the Account to the relevant Transaction? If we do, then a linked-list will prove an inefficient choice of implementation. Again, it would be very useful to know this type of information before we start trying to implement the relationship.

From these points we can see that we need to consider the wider requirements of our system before we can come up with the right implementation of our "debit-from" relationship (not to mention the many other classes and relationships that might be required). We can't produce a good design for a system unless we consider all the required functionality - in detail. Use Cases provide the mechanism for doing this.

Use Cases In UML
Use Cases are used to document system requirements. They provide a useful technique which, in conjunction with Object Modelling, help us to clarify exactly what the system is supposed to do. Let's take a look at the requirements for our banking system:

Figure 9 - Use Cases for Banking System

This Use Case diagram shows us the following:

• The required business functions - that is, the type of operation you'd expect to find on the menu of the application once it had been developed. In this case we have identified the following functions:

• Bank managers need to periodically print out a report detailing all the customers who are overdrawn; these appear on the branch printer

• Customers may use the system for balance enquiries

• Data processing staff use the system to do basic data entry (transactions on accounts)

• Clerks may periodically request statements on behalf of Customers;

• There are four distinct types of user of the system: Bank Managers; Clerks; Data Processing Assistants; and Customers. Each type of user typically has their own particular set of requirements for a system: hence identify user types assists in identifying all the required system functions.

The Use Case diagramming technique allows us to make a first cut at defining the system requirements, and will help us in presenting these requirements back to the users of the system. It also partitions the system into single atomic business functions, which may be used as a basis for costing the system, or for planning a phased system delivery. In this case each successive phase would deliver further batches of Use Cases.
Further information is still required, however, to tie down the detail of what each businese function does. Use Case Detail provides this information (explanatory notes are shown in bold):
 

As work progresses on the Use Cases, the requirements of the system become clearer enabling the Object Model to be updated in parallel, helping us make sure our model (and the subsequent implementation in the chosen language) contains all the necessary classes and class inter-links.
Whilst we're nearer to resolving some of the issues identified at the end of the discussion of implementing Object Models, a number are still outstanding: we still can't be sure in what direction the relationships must be implemented, whether we have identified all the methods; or what implementation of the links will best suit the use to which they'll be put. To sort out the remaining issues we'll need to look in more detail exactly how each Use Case will be implemented, using Sequence Diagrams.

Sequence Diagrams
Sequence diagrams, performed on a per Use Case basis, examine the flow of  method call calls within a system.

Figure 10 - Sequence Diagram for Overdrawn Report

Performing a complete analysis requires that each individual Use Case must be examined, although in practise only selected Use Cases may be examined. The Sequence Diagram in figure 10 shows the Overdrawn Report Use Case defined earlier.
The Overdrawn Report Use Case is thus implemented as follows:

• The Head-Office object (there is only one of them) has methods which correspond to each Use Case - in this case an OverdrawnReport method (this is a convenience for brevity, normally there would be a single "InitialObject" which the system would know about, and which would provide the entry point into the run-time model for all code).

• The Head-Office OverdrawnReport method locates the relevant Branch (as determined by the Use Case input: theBranchUseCase) and cascades the request to the Branch by calling its OverdrawnReport method.

• The Branch object in turn passes the request on down to each Account it holds (using the Account's OverdrawnReport method)!

• Each Account then:

• checks if it has been overdrawn for greater than the period specified by theOverdraftPeriod, which is passed as an argument to the Account.OverdrawnReport method (the detail of this is not shown - but involves summing up all the Transactions it holds, and checking the date on which it last became overdrawn).

• if appropriate it then calls one of its own methods to print the report (detail not shown), and resets its lastReportDate attribute, again using its own method.

• The method calls unwind until the Use Case is complete.

Figure 11 - Updated Banking System Object Model

Reviewing the Object Model (see figure 11), we can see a number of additions as a result of  completing this Sequence Diagram:

• OverdrawnReport methods have been added to the Branch and Account classes.

• A lastReportedDate attribute and associated methods have been added to the Account class, along with a printOverdrawnReport method.

• The "administers" relationship between Head-Office and Branch has been qualified to indicate that "direct access" via the Branch's "sort-code" is required across the link (thus assisting in link design) - note the consequent change in the multiplicity of the relationship from many-to-one to one-to-one.

• We have added directionality to many of the links (e.g. see the arrow-head on the Branch to Account link).

Of course, we've only looked at one Use Case, so its likely the model will change further as more sequence diagrams are developed.

The Overall Process
From the above discussion we can see that Use Cases and Sequence Diagrams both add to integrity and completeness of our Object Model, and that a good Object Model provides a firm foundation for a good design, and hence a good implementation of the system.

Figure 12 - The Overall Process

This approach separates the Problem and Technical Domain aspects of the project:

• Problem Domain Analysis is concerned with capturing requirements and producing a first cut Object Model. Typically the Object Model will be incomplete, having only a subset of the class attributes and methods defined.

• Problem Domain Design is concerned with finalising the detail of the problem domain parts of the Object Model, and results in an Object Model with a complete set of Problem Domain specific classes, attributes and methods.

• User Interface Design is the first step that focuses on the Technical Domain aspects of the problem, and involves taking the Use Cases as defined earlier, and designing a Graphical User Interface appropriate to the Technical Architecture chosen for the project (MS Windows, X/Motif, etc.). Typically you would expect to find one controlling dialog box (which may use other subsidiary dialogs) for each Use Case in the system. Some prototyping may be appropriate at this point in the project. For small projects, prototyping and UI design may be undertaken in parallel with Use Case development.

• Technical Domain, High Level Design focuses on adding classes to meet the technical needs of the project, and is driven by the technical architecture of the project. Classes may be GUI related, DBMS (object or relational) related, distribution related (CORBA, DCOM, etc.), external systems related, or may provide an interface to internal system components such as printers. Previous Sequence Diagrams may be updated to confirm the validity of the technical design - in particular you would expect to see GUI classes appearing between the System Boundary and the Problem Domain classes.

• Finally, Detailed Technical Design, looks at link implementations, detailed data typing of attributes, full specification of all methods (including parameters), etc. The end result is a complete design of the full system.

The separation between Problem Domain and the Technical Domain aspects of the system is useful in large projects, allowing the focus of those working on the project to be clearly divided, as summarised in figure 13:

Figure 13 - Seperation Of Problem and Technical  Domain Components of a System

For smaller projects (one or two persons for a couple of months) the two domains may be merged, if desired.
As mentioned previously, Use Cases may be used in phasing a project; the process shown earlier does not prohibit this. A project with 50 Use Cases could be structured in three phases as shown in figure 14:

Figure 14 - Evolutionary Phasing Of OO Project

The object-based structure of the application lends itself well to this approach.

Summary
This paper has taken a look at the Use Case, Object Modelling, and Sequence Diagramming notations of UML, how Object Modelling maps to OO programming languages, and shown how these notations hang together to complement each other. A number of other UML notations are not covered in this article, however further information can be found on www.ratio.co.uk.

I hope you can see that OOA/D offers a number of potential benefits in an OO based development environment. These include:

• better modelling of the problem domain (equals happier users)

• better overall software design with a strong focus on class structure

• more flexible and maintainable systems through better class partitioning

• good documentation (the notations) - and a single central overall design notation (the Object Model)

• a flexible approach to project phasing

• assistance in tie-ing down requirements, and

• less work (in the long run)

Mark Collins-Cope is Technical Director at Ratio Group Ltd., a consultancy and training company specialising in OO related methods, languages and technologies. For further information on OOA/D using UML, Java, C++, Design Patterns or related topics please call 0171 386 9600 or email info@ratio.co.uk.

Copyright
This material remains the copyright of Ratio Group Ltd. Licence is granted for the use of this material for personal development purposes only.

http://www.csai.cn/tech/xqgc/xq1231.htm

用例驱动的需求过程实践

一、需求矛盾

　　根据CHAO的权威统计，虽然自"软件危机"提出以来，软件工程方法得到了长足的发展与进步，但在去年的软件项目成功率仍然不足30％，绝大多数的软件项目仍然超进度、超成本。而在这些不成功的项目中，由于需求不清晰、需求不完整等方面的因素，占到了60％左右。

　　下面的这幅漫画虽然不乏夸张，但却是能够激起我们的深思：

　　根据笔者多年来从事软件需求捕获、分析工作的实践经验，认为造成这一现象的根本原因在于客户与开发人员之间的沟通存在障碍，双方都以自己的角度、自己的专业术语进行沟通，这使得大家并不能够很好地就软件需求达成共识。

　　由于帮助客户更好地利用信息化工具提高工作效率，是我们软件开发团队的责任，因此我们没有权利让用户理解我们所用的语言，而是反过来，我们有义务去理解用户的语言，站在用户的角度看问题。

　　而事实上，许多开发团队经常抱怨"我们的客户连需求都说不清楚"、"我们的客户对计算机了解太少了"。多年以来，大家都习惯从自己的角度来定义、分析问题，这也就造成了软件行业成为了一个最缺乏信任的行业，我们需要改一下习惯了。

二、现代需求实践

　　针对这些现象，许多先贤们开始了实践，并且总结出了一系列优秀的需求实践：

1）Use case：用例分析技术

　　鼎鼎大名的RUP是这样总结自己的：用例驱动，以体系结构为中心，迭代、增量的开发过程。Use case也伴随着RUP、UML一起名扬天下。

　　用例用来描绘一个系统外在可见的需求情况，是代表系统中各个项目相关人员（风险承担人，Stakeholder）之间就系统的行为所达成的契约。

2）User Story：用户故事、用户素材

　　用户故事是Kent Beck在极限编程（XP）方法论中推荐的最佳实践之一。它由客户参与编写，说明他们需要系统为他们做什么，一般用客户的术语写就，三句话左右。

3）Feature：特征

　　这是特征驱动开发（FDD）方法论的核心实践之一。一个特征就是一个小的，具有客户价值的功能，通常表示为<action><result><object>。

　　从上面的定义来看，这三种现代软件工程需求实践无一例外地遵从两个原则：一是站在用户的角度看待系统、定义系统；二是用用户看得懂的语言表达。而在笔者的实践中，鉴于以下两点考虑还是先在团队中应用了"用例分析技术"：

1）用户故事略显粗糙，掌握起来需要经验，没有详细的规则用于按部就班，一开始采用容易迷失方向；而用例相对来说更加形式化，易于上手；

2）特征看上去很有吸引力，但毕竟相关的理论还未完整，引入团队实践有些困难。

三、用例分析技术简介

　　用例分析技术是Rational三友之一Ivar Jacobson先生于1967年在爱立信公司开发AXE交换机时开始研究，并于1986年总结、发布的一项源于实践的需求分析技术。Ivar先生在加盟Rational之后，与三友合作提出了UML、完善了RUP，用例分析技术也因此被人广泛了解和关注。

　　用例分析技术为软件需求规格化提供了一个基本的元素，而且该元素是可验证、可度量的。用例可以作为项目计划、进度控制、测试等环节的基础。而且用例还可以使开发团队与客户之间的交流更加顺畅。

　　许多人是在学习UML的时候接触到Use case，所以许多人都误解其为一种图表，把用例图当作用例分析的全部，其实这是错误的，用例描述才是用例分析技术的核心。下面是一个简单的例子：


3.1 参与者，Actor

　　参与者，定义了用户在系统交互过程中扮演的角色，其可以是一个人，也可以是另一个相关的系统。

3.2 用例，Use case

　　用例实例（场景）是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果，一个用例定义一组用例实例（场景）。

　　一个用例应为参与者提供（实现）一个价值。

　　就像类对应于对象一样，一个用例的实例就是使用场景，用例就是对使用场景进行抽象的总结：

　　1）前置条件：指在用例启动时，参与者（Actor）与系统应置于什么状态，这个状态应该是系统能够检测到的、可观测的；

　　2）后置条件：用例结束时，系统应置于什么状态，这个状态也应该是系统能够检测得到的、可观测的；

　　3）基本事件流：基本事件流是对用例中常规、预期路径的描述，也被称为Happy day场景，这时大部分时间所遇到的场景；它将体现系统的核心价值；

　　4）扩展事件流：主要是对一些异常情况、选择分支进行描述。

　　建议大家在编写事件流时，注意以下几点：

　　1）使用简单的语法：主语明确，语义易于理解；

　　2）明确写出"谁控制球"：也就是在事件流描述中，让读者直观地了解是参与者在控制还是系统在控制；

　　3）从俯视的角度来编写：指出参与者的动作，以及系统的响应，也就是第三者的角度；

　　4）显示过程向前推移：也就是第一步都有前进的感（例如，用户按下tab键做为一个事件就是不合适的）；

　　5）显示参与者的意图而非动作（光有动作，让人不容易直接从事件流中理解用例）；

　　6）包括"合理的活动集"（带数据的请求、系统确认、更改内部、返回结果）；

　　7）用"确认"而非"检查是否"：（如系统确认用户密码正确，而非系统检查用户密码是否正确）；

　　8）可选择地提及时间限制；

　　9）采用"用户让系统A与系统B交互"的习惯用语；

　　10）采用"循环执行步骤x到y，直到条件满足"的习惯用语。

四、Alistair Cockburn眼中的用例分析技术

　　在使用用例分析技术时，很多人都觉得如何确定用例的粒度是一个难点，而且感觉到用例没有什么规则遵从，甚至有无所适从的感觉。正如Cockburn先生提出的学习用例分析技术的"守、破、离"的三个阶段：

　　1）守：练习基本功夫，遵循规则，照章行事；

　　2）破：能突破传统，因地制宜地灵活应用； 3）离：超脱任何招式与规则，达到无招胜有招的境界。

　　但用例分析技术却让第一阶段的初学者感到无法很快地掌握。而其所著"编写有效用例"则想为用例分析技术补充规则，让大家能够更好地掌握。

　　Cockburn先生在Ivar Jacobson的基础上，做了一些补充：

　　1）用例是契约，是系统与涉众之间达成的契约。也就是将用例朝着形式化的方向发展；

　　2） 将用例分成三级：

　　◆ 概要级：包括多个用户目标（显示用户目标运行的语境，显示相关目标的生命周期、为低层用例提供一个目录表）；

　　◆ 用户目标级

　　◆ 子功能级

　　不过，对于Cockburn先生的贡献，用例始祖Ivar大师并未做出任何反应。本人在实践中认为，Cockburn先生的思路与理念对于初学用例分析技术的人来说，十分有价值，使得用例分析技术更具操作性，当其同时也有点画地为牢的感觉，也许Cockburn先生也意识到这点，因此第三阶段就是"离"，没有规则，按需灵活使用。

　　用例分析技术在需求过程中的地位如下图所示：

　　对于用例分析技术理解上的两个最大的误区是：

　　1）用例分析技术包括了整个需求过程：它只是一个需求分析技术，是在传统的需求捕获技术的基础上使用的，并无法替代这些技术；

　　2）用例分析技术是分解技术：其实用例分析技术是一种合成技术，将在需求捕获中收集而来的零散的特性合成为用例：

5.1 用例分析前的工作

　　在用例分析之前，应该完成以下工作：

　　1）确定涉众（Stakeholder）和用户类型（命名、简要描述、涉众代表、特征、能力）；

　　2）确定涉众代表（命名、简要描述、责任、参与）；

　　3）在项目中加入涉众代表（访谈、问卷、顾问、评审、角色扮演）；

　　4）创建共同的构想（问题定义、系统范围、用户目标、非功能需求à前景文档）；

　　5）采用传统的需求捕获技术捕获需求；

　　6）组建用例分析队伍（少量、有问题域知识）。

5.2 用例分析过程中的注意事项

　　用例分析的过程如下图所示：

　　在使用中要注意：

　　1）用例源于涉众，请不要自己杜撰出用例；

　　2）用例的事件流的编写过程中，应充分加入团队的参与；

　　3）虽然用例源于涉众，但不要企图向他们直接问"你还有什么用例?quot;这样的问题。

IBM Rational
2004 年 3 月

Rational Unified Process 是软件工程的过程。它提供了在开发组织中分派任务和责任的纪律化方法。它的目标是在可预见的日程和预算前提下，确保满足最终用户需求的高质量产品。

什么是 Rational 统一过程（ Rational Unified Process）?
Rational Unified Process 是软件工程的过程。它提供了在开发组织中分派任务和责任的纪律化方法。它的目标是在可预见的日程和预算前提下，确保满足最终用户需求的高质量产品。

Rational Unified Process 是 Rational 公司开发和维护的过程产品。Rational Unified Process 的开发团队同顾客、合作伙伴、Rational 产品小组及顾问公司共同协作，确保开发过程持续地更新和提高以反映新的经验和不断演化的实践经验。

Rational Unified Process 提高了团队生产力。对于所有的关键开发活动，它为每个团队成员提供了使用准则、模板、工具指导来进行访问的知识基础。而通过对相同知识基础的理解，

无论你是进行需求分析、设计、测试项目管理或配置管理，均能确保全体成员共享相同的知识、过程和开发软件的视图。

Rational Unified Process 的活动创建和维护模型。 Rational Unified Process 强调开发和维护模型--语义丰富的软件系统表达，而非强调大量的文本工作。

Rational Unified Process是有效使用 Unified Modeling Language (UML)的指南。UML是良好沟通需求、体系结构和设计的工业标准语言。UML 由 Rational 软件公司创建，现在由标准化对象管理机构（OMG）维护。

Rational Unified Process 能对大部分开发过程提供自动化的工具支持。它们被用来创建和维护软件开发过程（可视化建模、编程、测试等）的各种各样的产物--特别是模型。另外在每个迭代过程的变更管理和配置管理相关的文档工作支持方面也是非常有价值的。

Rational Unified Process 是可配置的过程。没有一个开发过程能适合所有的软件开发。Rational Unified Process 既适用小的开发团队也适合大型开发组织。Rational Unified Process 建立简洁和清晰的过程结构为开发过程家族提供通用性。并且，它可以变更以容纳不同的情况。它还包含了开发工具包，为配置适应特定组织机构的开发过程提供了支持。

Rational Unified Process 以适合于大范围项目和机构的方式捕捉了许多现代软件开发过程的最佳实践。部署这些最佳实践经验--使用 Rational Unified Process 作为指南--给开发团队提供了大量的关键优势。在下节中，我们对 Rational Unified Process 的6个基本最佳实践经验进行描述。

6个最佳实践的有效部署
Rational Unified Process 描述了如何为软件开发团队有效的部署经过商业化验证的软件开发方法。它们被称为"最佳实践"不仅仅因为你可以精确地量化它们的价值，而且它们被许多成功的机构普遍的运用。为使整个团队有效利用最佳实践，Rational Unified Process 为每个团队成员提供了必要准则、模板和工具指导；

1. 迭代的开发软件
2. 需求管理
3. 使用基于构件的体系结构
4. 可视化软件建模
5. 验证软件质量
6. 控制软件变更

迭代的开发产品 -- 面对当今的复杂的软件系统，使用连续的开发方法：如首先定义整个问题，设计完整的解决方案，编制软件并最终测试产品，是不可能的。需要一种能够通过一系列细化，若干个渐进的反复过程而生成有效解决方案的迭代方法。Rational Unified Process 支持专注于处理生命周期中每个阶段中最高风险的迭代开发方法，极大地减少了项目的风险性。迭代方法通过可验证的方法来帮助减少风险--经常性的、可执行版本使最终用户不断的介入和反馈。因为每个迭代过程以可执行版本告终，开发团队停留在产生结果上，频繁的状态检查帮助确保项目能按时进行。迭代化方法同样使得需求、特色、日程上战略性的变化更为容易。

需求管理 -- Rational Unified Process 描述了如何提取、组织和文档化需要的功能和限制；跟踪和文档化折衷方案和决策； 捕获和进行商业需求交流。过程中用例和场景的使用被证明是捕获功能性需求的卓越方法，并确保由它们来驱动设计、实现和软件的测试，使最终系统更能满足最终用户的需要。它们给开发和发布系统提供了连续的和可跟踪的线索。 __

基于构件的体系结构 -- 该过程在全力以赴开发之前，关注于早期的开发和健壮可执行体系结构的基线。它描述了如何设计灵活的，可容纳修改的，直观便于理解的，并且促进有效软件重用的弹性结构。Rational Unified Process 支持基于构件的软件开发。构件是实现清晰功能的模块、子系统。Rational Unified Process 提供了使用新的及现有构件定义体系结构的系统化方法。它们被组装为良好定义的结构，或是特殊的、底层结构如Internet、CORBA 和 COM 等的工业级重用构件。

可视化软件建模-- 开发过程显示了对软件如何可视化建模，捕获体系结构和构件的构架和行为。这允许你隐藏细节和使用"图形构件块"来书写代码。可视化抽象帮助你沟通软件的不同方面，观察各元素如何配合在一起，确保构件模块一致于代码，保持设计和实现的一致性，促进明确的沟通。Rational软件公司创建的工业级标准 Unified Modeling Language(UML)是成功可视化软件建模的基础。

验证软件质量 -- 拙劣的应用程序性能和可靠性是戏剧性展示当今软件可接受性的特点。从而，质量应该基于可靠性、功能性、应用和系统性能根据需求来进行验证。Rational Unified Process帮助计划、设计、实现、执行和评估这些测试类型。质量评估被内建于过程、所有的活动，包括全体成员，使用客观的度量和标准，并且不是事后型的或单独小组进行的分离活动。

控制软件的变更 -- 管理变更的能力--确定每个修改是可接受的，能被跟踪的--在变更不可避免环境中是必须的。开发过程描述了如何控制、跟踪和监控修改以确保成功的迭代开发。它同时指导如何通过隔离修改和控制整个软件产物（例如，模型、代码、文档等）的修改来为每个开发者建立安全的工作区。另外，它通过描述如何进行自动化集成和建立管理使小队如同单个单元来工作。

过程简介

二维结构

开发过程可以用二维结构或沿着两个坐标轴来表达：

• 横轴代表了制订开发过程时的时间，体现了过程的动态结构。它以术语周期（cycle）、阶段(phase)、迭代（iteration）和里程碑(milestone)来表达。
• 纵轴表现了过程的静态结构：如何用术语活动（activity）、产物(artifact)、 角色(worker)和工作流(workflow)来描述。

迭代模型图显示了过程的二维结构

阶段和迭代--时间轴
这是开发过程沿时间的动态组织结构。

软件生命周期被分解为周期，每一个周期工作在产品新的一代上。Rational Unified Process将周期又划分为四个连续的阶段。

• 初始阶段
• 细化阶段
• 构造阶段
• 交付阶段

每个阶段终结于良好定义的里程碑--某些关键决策必须做出的时间点，因此关键的目标必须被达到。

过程中的阶段和主要里程碑

每个阶段均有明确的目标。

初始阶段

初始阶段的目标是为系统建立商业案例和确定项目的边界。

为了达到该目的必须识别所有与系统交互的外部实体，在较高层次上定义交互的特性。它包括识别所有用例和描述一些重要的用例。商业案例包括验收规范、风险评估、所需资源估计、体现主要里程碑日期的阶段计划。

本阶段具有非常重要的意义，在这个阶段中，关注的是整个项目进行工程中的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来说，初始阶段的时间可能很短。

本阶段的主要目标如下：

• 明确软件系统的范围和边界条件，括从功能角度的前景分析、产品验收标准和哪些做与哪些不做的相关决定
• 明确区分系统的关键用例（Use-case） 和主要的功能场景
• 展现或者演示至少一种符合主要场景要求的候选软件体系结构
• 对整个项目做最初的项目成本和日程估计(更详细的估计将在随后的细化阶段中做出)
• 估计出潜在的风险(主要指各种不确定因素造成的潜在风险)
• 准备好项目的支持环境

初始阶段的产出是:

• 蓝图文档核心项目需求关键特色主要约束的总体蓝图
• 原始用例模型(完成10%～20%)
• 原始项目术语表(可能部分表达为业务模型)
• 原始商业案例,包括业务的上下文、验收规范（年度映射、市场认可等等），成本预计
• 原始的风险评估
• 一个或多个原型

里程碑：生命周期的目标

初始阶段结束时是第一个重要的里程碑：生命周期目标里程碑。初始阶段的评审标准：

• 风险承担者就范围定义成本日程估计达成共识
• 以客观的主要用例证实对需求的理解
• 成本/日程、优先级、风险和开发过程的可信度
• 被开发体系结构原型的深度和广度
• 实际开支与计划开支的比较

如果无法通过这些里程碑，则项目可能被取消或仔细地重新考虑。

细化阶段

细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。

为了达到该目的，必须对系统具有"英里宽和英寸深"的观察。体系结构的决策必须在理解整个系统的基础上作出：它的范围，主要功能和如性能等非功能性需求。

容易引起争论，细化阶段是四个阶段中最关键的阶段。该阶段结束时，硬"工程"可以认为已结束，项目则经历最后的审判日：决策是否项目提交给构建和交付阶段。对于大多数项目，这也相当于从移动的、轻松的、灵巧的、低风险的运作过渡到高成本、高风险并带有较大惯性的运作过程。而过程必须能容纳变化，细化阶段活动确保了结构、需求和计划是足够稳定的，风险被充分减轻，所以可以为开发结果预先决定成本和日程安排。概念上，其逼真程度一致于机构实行费用固定的构建阶段的必要程度。

在细化阶段，可执行的结构原形在一个或多个迭代过程中建立，依赖于项目的范围、规模、风险和先进程度。工作量必须至少处理初始阶段中识别的关键用例，关键用例典型揭示了项目主要技术的风险。通常我们的目标是一个由产品质量级别构件组成的可进化的原型，但这并不排除开发一个或多个探索性、可抛弃的原型来减少如：设计/需求折衷，构件可行性研究，或者给投资者、顾客即最终用户演示版本等特定的风险。

本阶段的主要目标如下：

• 确保软件结构、需求、计划足够稳定；确保项目风险已经降低到能够预计完成整个项目的成本和日程的程度。
• 针对项目的软件结构上的主要风险已经解决或处理完成。
• 通过完成软件结构上的主要场景建立软件体系结构的基线。
• 建立一个包含高质量组件的可演化的产品原型。
• 说明基线化的软件体系结构可以保障系统需求可以控制在合理的成本和时间范围内。
• 建立好产品的支持环境。

初始阶段的产出是：

• 用例模型（完成至少80％）-- 所有用例均被识别，大多数用例描述被开发
• 补充捕获非功能性要求和非关联于特定用例要求的需求
• 软件体系结构描述_可执行的软件原型
• 经修订过的风险清单和商业案例
• 总体项目的开发计划，包括纹理较粗糙的项目计划，显示迭代过程和对应的审核标准
• 指明被使用过程的更新过的开发用例
• 用户手册的初始版本（可选）

里程碑：生命周期的结构

细化阶段结束是第二个重要的里程碑：生命周期的结构里程碑。此刻，检验详细的系统目标

和范围、结构的选择以及主要风险的解决方案。主要的审核标准包括回答以下的问题：

• 产品的蓝图是否稳定？
• 体系结构是否稳定？
• 可执行的演示版是否显示风险要素已被处理和可靠的解决
• 构建阶段的计划是否足够详细和精确？是否被可靠的审核基础支持？
• 如果当前计划在现有的体系结构环境中被执行而开发出完整系统，是否所有的风险承担人同意该蓝图是可实现的？
• 实际的费用开支与计划开支是否可以接受？

如果无法通过这些里程碑，则项目可能被取消或仔细地重新考虑。

构建阶段

在构建阶段,所有剩余的构件和应用程序功能被开发并集成为产品,所有的功能被详尽的测试。

构建阶段，从某种意义上说，是重点在管理资源和控制运作以优化成本、日程、质量的生产过程。就这一点而言，管理的理念经历了初始阶段和细化阶段的智力资产开发到构建阶段和交付阶段可发布产品的过渡。

许多项目规模大的足够产生许多平行的增量构建过程，这些平行的活动可以极大地加速版本发布的有效性；同时也增加了资源管理和工作流同步的复杂性。健壮的体系结构和易于理解的计划是高度关联的。换言之，体系结构上关键的质量是构建的容易程度。这也是在细化阶段平衡的体系结构和计划被强调的原因。

本阶段的主要目标如下：

• 通过优化资源和避免不必要的返工达到开发成本的最小化
• 根据实际需要达到适当的质量目标
• 据实际需要形成各个版本（Alpha,Beta,and other test release）
• 对所有必须的功能完成分析、设计、开发和测试工作
• 采用循环渐进的方式开发出一个可以提交给最终用户的完整产品
• 确定软件站点用户都为产品的最终部署做好了相关准备
• 达成一定程度上的并行开发机制

构建阶段的产出是可以交付给最终用户的产品。它最小包括：

• 特定平台上的集成产品
• 用户手册
• 当前版本的描述

里程碑：初始运作能力

创建阶段结束是第三个重要的项目里程碑（初始功能里程碑）。此刻，决定是否软件、环境、用户可以运作而不会将项目暴露在高度风险下。该版本也常被称为"beta"版。

构建阶段主要的审核标准包括回答以下的问题:

• 产品是否足够稳定和成熟得发布给用户?
• 是否所有的风险承担人准备好向用户移交?
• 实际费用与计划费用的比较是否仍可被接受?

如果无法通过这些里程碑,则移交不得不被延迟。

交付阶段

交付阶段的目的是将软件产品交付给用户群体。

只要产品发布给最终用户，问题常常就会出现：要求开发新版本，纠正问题或完成被延迟的问题。

当基线成熟得足够发布到最终用户时，就进入了交付阶段。其典型要求一些可用的系统子集被开发到可接收的质量级别及用户文档可供使用，从而交付给用户的所有部分均可以有正面的效果。这包括：

• 对照用户期望值，验证新系统的"beta测试"
• 与被替代的已有系统并轨
• 功能性数据库的转换
• 向市场、部署、销售团队移交产品

构建阶段关注于向用户提交产品的活动。典型的，该阶段包括若干重复过程，包括 beba 版本、通用版本、bug 修补版和增强版。相当大的工作量消耗在开发面向用户的文档，培训用户。在初始产品使用时，支持用户并处理用户的反馈。开发生命周期的该点，用户反馈主要限定在产品性能调整、配置、安装和使用问题。

本阶段的目标是确保软件产品可以提交给最终用户。本阶段根据实际需要可以分为几个循环。本阶段的具体目标如下：

• 进行 Beta 测试以期达到最终用户的需要
• 进行 Beta 测试和旧系统的并轨
• 转换功能数据库
• 对最终用户和产品支持人员的培训
• 提交给市场和产品销售部门
• 和具体部署相关的工程活动
• 协调 Bug 修订/改进性能和可用性(Usability)等工作
• 基于完整的 Vision 和产品验收标准对最终部署做出评估
• 达到用户要求的满意度
• 达成各风险承担人对产品部署基线已经完成的共识
• 达成各风险承担人对产品部署符合 Vision 中标准的共识

该阶段依照产品的类型,可能从非常简单到极端复杂的范围内变化。例如，现有的桌面产品的新版本可能非常简单，而替代国际机场的流量系统会非常复杂。

里程碑：产品发布

在交付阶段的终点是第四个重要的项目里程碑，产品发布里程碑。此时，决定是否目标已达到或开始另一个周期。在许多情况下，里程碑会与下一个周期的初始阶段相重叠。

发布阶段的审核标准主要包括以下两个问题：

• 用户是否满意？
• 实际费用与计划费用的比较是否仍可被接受？

迭代过程

Rational Unified Process 的每个阶段可以进一步被分解为迭代过程。迭代过程是导致可执行产品版本（内部和外部）的完整开发循环，是最终产品的一个子集，从一个迭代过程到另一个迭代过程递增式增长形成最终的系统。

迭代方法的益处

与传统的瀑布式方法相比，迭代过程具有以下的优点：

• 减小了风险
• 更容易对变更进行控制
• 高度的重用性
• 项目小组可以在开发中学习
• 较佳的总体质量

开发过程中的静态结构(Static Structure of the Process)
开发流程定义了"谁""何时""如何"做"某事"。四种主要的建模元素被用来表达 Rational Unified Process：

• 角色(Workers),"谁"
• 活动(Activities),"如何"
• 产物(Artifacts),"某事"
• 工作流（Workflows），"何时"

活动、产物、角色

角色、活动和工作产物

角色

角色定义了个人或由若干人所组成小组的行为和责任。可以认为角色是项目组中个人戴的"帽子"。单个人可以佩戴多个不同的帽子。这是一个非常重要的区别。因为通常容易将角色认为是个人或小组本身，在 Unified Process 中，角色还定义了如何完成工作。所分派给角色的责任既包括某系列的活动，还包括成为产物的拥有者。

人与角色

活动

某个角色的活动是可能要求该角色中的个体执行的工作单元。活动具有明确的目的，通常表现为一些产物，如模型、类、计划等。每个活动分派给特定的角色。活动通常占用几个小时至几天，常常牵涉一个角色，影响到一个或少量的产物。活动应可以用来作为计划和进展的组成元素；如果活动太小，它将被忽略，而如果太大，则进展不得不表现为活动的组成部分。

活动的例子：

• 计划一个迭代过程，对应角色：项目经理
• 寻找 use cases 和 actors, 对应角色:系统分析员
• 审核设计,对应角色:设计审核人员
• 执行性能测试,对应角色:性能测试人员

产物

产物是被产生的、修改，或为过程所使用的一段信息。产物是项目的实际产品、项目产生的事物，或者供向最终产品迈进时使用。产物用作角色执行某个活动的输入，同时也是该活动的输出。在面向对象的设计术语中，如活动是活动对象（角色）上的操作一样，产物是这些活动的参数。

产物可以具有不同的形式：

• 模型，如 Use-Case 模型或设计模型
• 模型组成元素,即模型中的元素，比如类,用例（use case） 或子系统般的元素
• 文档,如商业案例或软件结构文档
• 源代码
• 可执行文件

工作流

仅依靠角色、活动和产物的列举并不能组成一个过程。需要一种方法来描述能产生若干有价值的有意义结果的活动序列，显示角色之间的交互作用。

工作流是产生具有可观察结果的活动序列。

UML 术语中,工作流可以表达为序列图、协同图，或活动图。在本文中，使用活动图的形式来描述。

工作流样例

注意要表达活动之间的所有依赖关系并不是总可能或切合实际的。常常两个活动较表现的交织得更紧密，特别是在涉及到同一个角色或个人时。人不是机器，对于人而言，工作流不能按字面地翻译成程序，被精确地、机械地执行。

下节中，我们将讨论开发过程中最基本的工作流，称之为核心工作流。

核心工作流(Core workflows)
Rational Unified Process 中有9个核心工作流,代表了所有角色和活动的逻辑分组情况。

9个核心的过程工作流

核心工作流分为6个核心"工程"工作流

1. 商业建模工作流
2. 需求工作流
3. 分析和设计工作流
4. 实现工作流
5. 测试工作流
6. 分发工作流

和3个核心"支持"工作流

1. 项目管理工作流
2. 配置和变更控制工作流
3. 环境工作流

尽管6个核心工程工作流能使人想起传统瀑布流程中的几个阶段，但应注意迭代过程中的阶段是不同的，这些工作流在整个生命期中一次又一次被访问。9个核心工作流在项目中的实际完整的工作流中轮流被使用，在每一次迭代中以不同的重点和强度重复。

商业建模

决大多数商业工程化的主要问题，是软件工程人员和商业工程人员之间不能正确地交流。这导致了商业工程的产出没有作为软件开发输入而正确地被使用，反之亦然。Rational Unified Process 针对该情况为两个群体提供了相同的语言和过程，同时显示了如何在商业和软件模型中创建和保持直接的可跟踪性。

在商业建模中，使用商业用例来文档化商业过程，从而确保了组织中所有支持商业过程人员达到共识。商业用例被分析以理解商业过程如何被业务支持，而这些在商业对象模型中被核实。

许多项目可能不进行商业建模。

需求

需求工作流的目标是描述系统应做"什么"，并允许开发人员和用户就该描述达成共识。为了达到该目标，进行提取、组织、文档化需要的功能和约束；跟踪、为折衷方案及决定形成文档。

蓝图被创建，需求被提取。代表用户和其他可能与开发系统交互的其它系统的 Actor 被指明。Use case 被识别,表示系统的行为。因为use case 根据 actor 的要求开发,系统与用户之间的联系更紧密。系统展示了用于再生系统的用例模型。

样例用例模型

每一个用例被仔细地描述。用例描述显示了系统如何与 actor 交互及系统的行为.非功能性的需求在补充说明中体现。

Use case 起到贯穿整个系统的开发周期线索的作用。相同的用例模型在需求捕获阶段、分析设计阶段和测试阶段中使用。

分析和设计

分析设计工作流的目标是显示系统"如何"在实现阶段被"实现"的。你需要一个如下系统：

• 在特定的实现环境中完成用例描述中指定的任务和功能
• 满足了所有的需求
• 健壮的被建造（如果功能需求发生变化，易于更改）

分析设计结果是一个设计模型和可选的分析模型。设计模型是源代码的抽象；即设计模型充当源代码如何被组建和编制的"蓝图"。

设计模型由设计类和一些描述组成。设计类被组织成具有良好接口的设计包和设计子系统，而描述则体现了类的对象如何协同工作实现用例的功能。

下图是上例 use-case 模型的设计模型示例的一个部分。

设计模型的一部分

设计活动以体系结构设计为中心。结构的产物和验证是早期迭代的主要焦点。结构由若干结构视图来表达，这些视图捕获了主要的构架设计的决定。本质上，结构视图是整个设计的抽象和简化，该视图中细节被放在了一旁，使重要的特点体现得更加清晰。结构不仅仅是良好设计模型的承载媒介，而且在系统的开发中能提高任何被创建模型的质量。

实现

实现阶段的目的：

• 定义代码的组织结构--以层次化的实施子系统的形式
• 实现类和对象--以构件的形式（源文件、二进制文件、可执行文件等）
• 将开发出的构件作为单元进行测试
• 对由单个实现者（或小组）产生的结构集成为可执行的系统

系统通过完成构件而实现。Rational Unified Process 描绘了如何重用现有的组件,或实现经过良好责任定义的新构件,使系统更易于使用,提高了系统的可重用性。

构件被构造成实施子系统。子系统被表现为带有附加结构或管理信息的目录形式。例如，子系统可以被创建为文件系统中的文件夹或目录，或 Rational Apex for C++ or Ada,或 Java中的包。

测试

测试的目的是：

• 验证对象间的交互作用
• 验证软件构件的正确集成
• 验证所有需求被正确的实现
• 识别并确保载软件发布之前缺陷被处理

Rational Unified Process 提出了迭代的方法，意味着在整个项目中进行测试，从而允许尽可能早的发现缺陷，从根本上降低了修改缺陷的成本。测试类似于三维模型，分别从可靠性、功能性、应用和系统性能来进行。流程从每个维度描述了如何经历测试生命周期的几个阶段，计划、设计、实现、执行和审核。

另外，描述了何时及如何引入测试自动化的策略。使用迭代的方法，测试自动化是非常重要的，它允许在每次迭代结束及为每个新产品进行回归测试。

发布

发布工作流的目标是成功地生成版本，将软件分发给最终用户。它包括了范围广泛的活动。

• 生成软件本身外的产品
• 软件打包
• 安装软件
• 给用户提供帮助

许多情况下，还包括如下的活动

• 计划和进行 Beta 测试版
• 移植现有的软件或数据
• 正式验收

尽管发布工作流主要被集中在交付阶段,但早期阶段需要加入为创建阶段后期的发布做准备的许多活动。

Rational Unified Process 中的发布和环境工作较其它工作流包含了较少的内容。

项目管理

软件项目管理是一门艺术，它平衡了互相冲突的目标，管理风险，克服各种限制来成功地发布满足投资用户和使用者需要地软件。如此少的无争议的成功项目无疑是该项任务难度的证明。

工作流主要集中在迭代开发过程的特殊方面。本节我们的目标是提供以下的事物来使该任务更简单。

• 管理项目的框架
• 计划、配备、执行、监控项目的实践准则
• 管理风险的框架

它并不是成功的灵丹妙药，但提供了管理项目能显著提高软件成功发布的方法。

配置和变更管理

本工作流中，描绘了如何在多个成员组成的项目中控制大量的产出物。控制有助于避免混乱，确保不会由以下的问题而造成产品的冲突。

• 同步更新--当两个或两个以上的角色各自工作在同一产物上时，最后一个修改者会破坏前者的工作。
• 通知不达--当被若干开发者共享的产品中的问题被解决时，修改未被通知到一些开发者
• 多个版本--许多大型项目以演化的方式开发。一个版本可能供顾客使用，另一个版本用于测试，而第三个版本处于开发阶段。如果问题在其中任何一个版本中被发现，则修改需要在所有版本中繁衍，从而可能产生混乱导致昂贵的修改和重复劳动，除非变更被很好地控制和监控。

工作流提供了准则管理演化系统中的多个变体，跟踪给定软件创建过程中的版本。根据用户定义地版本规则建造程序或整个版本，实施特定于现场的开发策略。

工作流描述了了如何管理并行开发、分布式开发，如何自动化创建工程。这在如每天均需要频繁编译链接的重复过程中尤为重要。如果没有有力的自动化是不可能的同，时也阐述了对产品修改原因、时间、人员保持审计记录。

工作流也涵盖了变更需求管理，即如何报告缺陷，在它们的是生命周期中如何管理，及如何使用缺陷来跟踪进展和发展的倾向。

环境

环境工作流的目的是给软件开发组织提供软件开发环境--过程和工具--软件开发团队需要它们的支持。

工作流集中在项目环境中配置过程的活动，同样着重支持项目的开发规范的活动。提供了逐步指导手册，介绍了如何在组织中实现过程。

环境工作流还包含了提供了定制流程所必须的准则、模板、工具的开发工具箱。开发工具箱在本文后续的"定制流程的开发工具箱"中更详尽的讨论。

环境工作流没有被牵涉到如选择、获取、使其运行和维护开发环境等的具体方面。

Rational Unified Process －具体产品
Rational Unified Process 产品包括：

• 能使用 web 搜索的知识基础--为全部团队成员就所有关键的开发活动提供准则、模板、工具指导。知识基础进一步划分为：
  • 扩展的准则供全部成员对软件生命期所有组成部分进行参考。提供了既为高层次的思考过程，也为日常沉闷的活动进行指导的指南。该指南发布为 HTML 格式以利于独立于平台的桌面访问。
  • 工具指导涵盖整个生命周期工具的指引。同样，它以 HTML 格式发布.详细情况参见"工具集成"。
  • Rational Rose 的例子和模板为在遵循 Rational Unified Process 时如何组织Rational Rose 的信息提供参考。
  • SoDA 模板提供10个以上 SoDA 模板以协助软件文档自动化。
  • Microsoft Word 模板提供了超过30个模板以帮助工作流和生命期所有部分文档化。
  • Microsoft Project Plans 许多项目经理发现很难做出反映迭代开发方法的项目计划。该模板根据 Rational Unified Process 为该方法提供一个好的开端。
  • Development kit 介绍了如何定制和扩展 Rational Unified Process 至采用该方法机构或项目的特定需求,同时提供了工具和模板来辅助该工作.开发工具包在本节的后续部分阐述。
  
  
• Addison-Wesley 出版，Philippe Kruchten 所著的 《Rational Unified Process A Introduction》。本书共 277页，对开发过程和知识基础提供了很好的介绍和概括。

知识基础的浏览

Rational Unified Process 允许使用任何流行的浏览器如：IE、Netscape Navigator 进行浏览。使用 Rational Unified Process ，你仅需少许的鼠标点击即可获得所需的信息。该知识基础包含了许多超文本链接，各种过程元素用交互的图案来表达，很容易直观的寻找相关信息。功能强大的搜索引擎、索引、"资源管理器式外观"的树状浏览使得使用该过程很容易。浏览按钮允许如同读书一般前后翻页。

信息在若干不同的视图中表现，允许你相关于角色、特定活动或工作流来查看信息。对于关键的项目角色，提供易于学习的指导过程。

交互式的图象和可导航的按钮使查找特定的信息更加方便

定制过程的开发工具包

Rational Unified Process 足够通用及完备，如同它名字所描述的一般。然而，在某些情况下，该软件开发过程需要被修改、调整和剪裁以容纳具体的特性、约束和机构的历史情况。特别的，该过程不应该盲目的被遵循，形成许多无用的工作，产生无用产物。它应尽可能的精炼并能够快速地、可预见地产生高质量的软件。

开发过程包含了开发工具包，它包括了指导如何定制过程以满足机构或项目特定需要的指南。工具包还包括了创建过程，以及搜索引擎、索引、场所地图、树型浏览器等的衍生和操作的模板。开发工具包使得能定制组织结构维持 Rational Unified Process 的感观。

开发过程定制程度越高，则定制化向未来过程版本的移植越困难。开发工具包描述了减少定制化移植时工作的策略、工具和技术。

工具集成

软件工程化过程需要工具支持系统生命期的所有活动，尤其是支持开发、维护和各种各样产物的簿记--特别是模型。迭代的开发过程对使用的工具集提出了特殊的要求，如工具的集成和模型代码之间的双向工程。同样，还需要支持跟踪需求，文档自动化以及测试自动化如促进回归测试等的工具。Rational Unified Process 可以与各种各样的工具一同使用，包括 Rational公司和其它供应商的产品。而 Rational提供许多有效支持 Rational Unified Process 良好集成的工具。

下面提供了支持 Rational Unified Process 的工具清单。

Rational Unified Process 对于大多数产品均提供了工具指引（Tool Mentors）。工具指引是详细介绍如何操作工具以实现开发过程的指南（即弹出什么样的窗口，对话框中的信息及如何漫游的工具）。工具指引允许将独立于工具的过程链接至日常工作的实际操作工具。

• Rational Requisite ? Pro --通过使需求更易于书写，交流和修改使在整个应用开发中全体开发小组能实时更新和跟踪。
• Rational ClearQuest? -- 基于窗口的和 Web 的需求变更管理产品,时项目小组能跟踪和管理开发生命期中的所有变更活动。
• Rational Rose?98 -- 世界领先的用于商业过程建模，需求分析，构建结构设计的可视化建模工具。
• Rational SoDA? -- 为整个软件开发过程提供产品文档自动化的工具，极大减少了文档工作的时间和成本。
• Rational Purify? -- C/C++构件和应用程序开发者使用的运行错误检查工具,帮助检查内存错误。
• Rational Visual Quantify? -- C/C++、VB、Java构件和应用程序开发者使用的高级性能评测工具,帮助评估性能瓶颈。
• Rational Visual PureCoverage? -- 自动的软件测试覆盖率工具，使开发者能全面地有效地测试他们的应用程序。
• Rational TeamTest -- 创建、维护和执行自动化的功能测试，允许全面地测试代码和决定软件是否满足期望的需求和性能。
• Rational PerformanceStudio? -- 评测和预计 Client/Server 和 Web 系统性能的易于使用、准确和可升级的工具。
• Rational ClearCase? --主导市场的软件配置工具，为项目经理提供跟踪每个软件开发项目进化的能力。

Rational Unified Process 的历史
Rational Unified Process 经过了许多年的成熟期并反映了许多人和公司的集体经验。让我们简要地看一下如下图所示它的历史：

Rational 统一过程的演进历史

从时间上回顾，Rational Unified Process 是 Rational Objectory Process(version 4)的直接继承者。Rational Unified Process 合并了数据工程、商业建模、项目管理和配置管理领域更多的东西，后者作为与 Prue Atria 的归并结果。它更紧密地集成至 Rational 软件工具集。Rational Unified Process 是"Rational Approach" 与Objectory process (version 3)的综合,在1995年 Rational 软件公司与 Objectory AB 合并之后。从它的 Objectory 前任,继承了过程结构和 use case 的中心概念。从它的 Rational 背景,得到了迭代开发和体系结构的系统阐述。该版本同样包括了Requisite,Inc 配置管理部分和从 SQA,?Inc 继承的详细测试过程。最后，该开发过程是第一个使用了统一建模语言(UML0.8)。

Objectory process 作为 Ivar Jacobson 的 Ericsson 经验于1987在瑞典被创建。该过程称为他公司 Objectory AB 的产品。由于以 use case 概念和面向对象的方法为中心,它很快得到了软件工业的认可并被许多世界级的公司集成。Objectory process 的简单版本作为课本在1992年被出版。

Rational Unified Process 是更为通用方法的一个特定的、详细的实例，该通用方法在 Ivar Jacobson,Grady Booch,和James Rumbaugh 所著的课本《The Unified Software Development Process》有介绍。

参考资料

• Barry W. Boehm, A Spiral Model of Software Development and Enhancement, Computer, May 1988,IEEE, pp.61-72
  
  
• Barry W. Boehm, Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82.
  
  
• Grady Booch, Object Solutions, Addison-Wesley, 1995.
  
  
• Grady Booch, Ivar Jacobson, and James Rumbaugh, Unified Modeling Language 1.3, White paper,Rational Software Corp., 1998.
  
  
• Alan W. Brown (ed.), Component-Based Software Engineering, IEEE Computer Society, LosAlamitos, CA, 1996, pp.140.
  
  
• Michael T. Devlin, and Walker E. Royce, Improving Software Economics in the Aerospace and Defense Industry, Technical paper TP-46, Santa Clara, CA, Rational Software Corp., 1995
  
  
• Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar ?vergaard, Object-Oriented Software Engineering-A Use Case Driven Approach, Wokingham, England, Addison-Wesley, 1992, 582p.
  
  
• Ivar Jacobson, M. Griss, and P. Jonsson, Software Reuse-Architecture, Process and Organization for Business Success, Harlow, England, AWL, 1997.
  
  
• Philippe Kruchten, The 4+1 View Model of Architecture, IEEE Software, 12 (6), November 1995, IEEE, pp.42-50.
  
  
• Philippe Kruchten, A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.
  
  
• Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.
  
  
• Grady Booch, Jim Rumbaugh, and Ivar Jacobson, Unified Modeling Language-User's Guide, Addison-Wesley, 1999.
  
  
• Philippe Kruchten, Rational Unified Process-An Introduction, Addison-Wesley, 1999.
  
  
• Walker Royce, Software Project Management . A Unified Framework, Addison-Wesley, 1998.
  

　　管理上的问题不能得到彻底的解决，软件的质量保障就无从谈起。笔者最近在与印度一家通过了CMM4级评估的软件公司（以下简称A公司）进行合作的过程中，较为详细地了解了他们有关项目管理的一些详细情况，更深刻地感受到了项目管理的规范化与企业软件质量保障之间的密切关系。下面想着重从软件企业的构架，软件项目计划、项目管理、项目经理的职责等方面对印度软件的项目管理及我国软件质量保障应注意的问题进行一些经验总结，供业内人士参考。
 
　　1.软件企业的组织结构

　　(1)A公司结构

　　图1是A公司的组织结构图，同国内公司差异较大的部门有QA、SSG和人力资源部门。

图1

　　* A公司中，QA(Quality Assure)部门与研发部门独立，负责监督流程的执行。QA同时负责领导与研发部门组成的联合工作组，制定公司流程。
　　* SSG(System Support Group)类似我们的IT部门，负责公司所有计算机软件和硬件资源的分配和管理。所有的办公环境和开发/实验室环境由SSG负责安装和维护，计算机资源属于SSG，由各个项目向SSG提出需求，项目结束后，设备需要交还给SSG。个人和项目组没有固定的软件和硬件资源。SSG是与研发平行的部门。
　　* 人力资源部门负责公司的人力资源管理，并维护员工的技能数据库。项目开始时，项目组向人力资源申请人力，向SSG申请计算机硬件和软件。项目结束时需要释放计算机资源给SSG，释放人力资源到人力资源池，并同时更新员工的技能数据库。研发部门的人力资源由研发总负责人和其助手分配(类似我国各公司的人力资源部)。

　　(2)项目组结构

　　1) A公司对项目组进行独立核算，项目具体负责人为PC(Project Coordinator)，负责项目计划和执行，对项目具体成员进行分工。在每个阶段的结束会议上(如概要设计结束)，PC要接受QC(Quality Coordinator)的审查。除了PC与QC的接口外，所有其他外部接口都由EM(Engineer Manager)完成，EM负责与客户打交道，向SSG、人力资源要求资源，与其他项目组协调进度。
 
　　2) 汇报关系为:
　　Team Member->Team Leader->PC->EM->研发总负责人。

　　3) 印度工程师分为7级，半年一次考评，即半年有一次升级机会。
　　1级:Software Engineer，刚毕业的本科生和研究生。
　　2级:Senior Software Engineer。
　　3级:Project Leader。
　　4级:Project Manager。
　　5级:Senior Project Manager。
　　3级可以成为PC，4级可以成为EM。刚开始平均2年升一级，越往后升职越慢。

　　A公司规定，一人最多可以同时兼任两个项目的PC，EM管理的项目没有限制。

　　A公司通常的项目组为4到5人，最多不超过10人。

　　以上是A公司（同时也是印度大多数规范化的软件公司）的组织结构和项目组结构。可以看出，A公司的组织结构非常清晰，各个部门分类非常细，任务明确，软件生产的每一个步骤都有专门的部门、专门的人员负责，从最基础的开发人员到负责统领全局的总经理，层层管理，沟通渠道畅通。而在我国，管理的不规范往往首先体现在公司的组织结构上，集中表现为部门的缺失和管理的交叉上。我国的软件公司，大部分规模较小，开发人员超过100人的公司很少。在印度，软件公司无论大小，都是“麻雀虽小，五脏俱全”，绝不会因为公司的规模大小而改变合理的组织结构。因此笔者认为，国内的软件企业要想有效地保障产品质量，首先就要在构架合理的组织结构上下功夫，这就如同盖高楼首先要打好地基一样，地基不打牢，结构不合理，其他方面再下功夫也是徒劳。有人说，因为国内软件企业规模小，所以造成结构设置的欠缺，但笔者认为恰恰是因为没有建立一个规范化的组织结构，才会使软件产品质量不保，进而严重影响了企业的发展扩大。

　　2.项目计划

　　凡事预则立，不预则废。这里的“预”就是指计划。对于软件企业，计划的重要性是不言而喻的。让我们先看看A公司的项目计划是如何制定的:在A公司，项目开始之前必须先估计项目的规模（以代码行数来衡量）;然后制定项目计划。通常时间为2～3周，已知的最长有5周。EM负责制定项目 EWP(Engineer Work Paper)，其中定义了项目需要的人力和计算机资源，由相关部门同意，并报研发总负责人批准后才能开始项目。

　　项目的正式开始时间由项目组的Kickoff Meeting算起，Closeout Meeting结束。

　　大概很多人都听过这样一句话：“计划赶不上变化”。这种“变化”对某些行业而言也许并不会产生太大的影响，但对于软件企业而言，却会给软件产品的质量保证带来严重的负面影响。为什么会造成这种“计划赶不上变化”的现象？究其原因，笔者认为主要是因为对计划的重视程度不够，计划过于笼统、粗糙导致可执行性太差，再加上一些人为因素的影响，必然会产生这样的后果。

　　如果我们的软件企业都能像A公司这样，在作计划时能考虑到每一个细节，不是仓促做出决定，而是由所有的相关部门共同对产品计划进行反复研究、制定、讨论、修改，最终形成一套系统、严密、具有很强的可执行性的计划。计划一旦形成，就严格按照计划去执行，而不受某个人、某件事的影响，那么就不仅能够减少大量资源的浪费，产品的质量也得到了保障。

　　因此，对计划的高度重视、周密制定、严格执行是企业有效保障产品质量的一个重要环节。

　　3.项目管理

　　当企业构架了合理的组织结构并制定了缜密的计划后，就进入了产品的开发阶段。在这个阶段中，项目管理起了重要作用，它所涉及的环节相当具体复杂，下面先介绍一下A公司在项目管理上的具体细节：

　　(1)开发阶段和项目周期
　　开发阶段比较明显，注重各阶段应完成的功能，对本阶段应完成的工作不能留到下一阶段。
 
　　(2)流程

　　* A公司对流程比对项目更重视。
　　* 软件开发流程非常规范和系统化，其流程的可执行性很高，并且能在实践过程中不断改进。A公司的流程已覆盖到了一个项目研发的所有方面，包括从最开始的意向到最后软件的版本发布(release)，都有相应的流程规定，基本上已形成一种工业化的软件开发。
　　* 人和流程是保证项目成功的两个最关键因素。由好的人按好的流程进行项目开发，才能最大限度地保证项目的成功。一个好的流程可以保证差的人做出来的东西不至于太差，但不能确保做出精品。通过流程可以实现一种规范化、流水线化、工业化的软件开发。

　　(3)计划

　　1) 计划详细、周到。

　　2) 流程中明确定义开发阶段。
 
　　3) 每个阶段都列出了该阶段的各项活动，并详细描述每项活动的属性:
　　* 进入条件，输入;
　　* 验证方法;
　　* 结束条件，输出。

　　4)每个阶段结束都要召开阶段结束会议。前一个阶段结束才能进入下一阶段。

　　5)计划中每个活动都比较具体，每个活动的时间以天（半天）为单位。计划包括了开展质量控制活动的时间。

　　(4)Review

　　按印度公司流程，一般把Review和测试作为保证软件质量两个主要手段。测试的重要性就不需说明了，而Review则是一个非常简单有效并能尽早发现软件中错误的方法，可以说，任何交付物都要经Review后才能进行基线化。目前A公司有很详细全面、可执行性很高的Review流程和各种交付物的Review Checklist。

　　在印度软件企业，现有这么一句口号：凡事有计划，凡事必review。

　　(5)QA

　　QC（质量经理）作为质量保证部门（SQA）的代表，监督和保证项目的进展遵循QMS各项流程和模板，并且收集项目中发现的一些问题和解决方法以优化流程。

　　(6)度量数据

　　CMM中比较强调用数据说话，对项目过程中基本上所有的数据都会有记录，最后把收集的数据提交质量保证部门进行分析，以改进流程。A公司的项目经理和质量经理很重视项目中的数据收集，包括各种Review数据、测试数据以及项目组员每天的活动数据等。项目经理也要维护一个项目档案，在这个项目档案中可以说包含了项目开发过程中所有的产出、开发活动、管理活动等的记录。可以这么说，有了这个项目档案，你就可以完全了解这个项目的开发过程。

　　(7)团队精神

　　印度公司都比较强调团队精神、合作精神，应该说，其流程本质上就要求员工之间的互相协调和理解。相对而言，印度员工的合作精神和协调精神都比我国员工要好得多。

　　(8)培训

　　印度公司都比较强调培训，一般有专门的培训部门进行协调。在新员工进入公司后都会有公司流程和其他一些公司普遍章程的培训，以保证员工对流程的理解和执行。对于具体项目，项目经理在制定项目计划时就会在项目计划中提出所有的培训需求，包括技术上的培训和其他所需的培训。

　　(9)配置管理
　　在项目正式开展前，项目经理就要制定配置管理计划，并且指定配置管理员建立起配置管理库，按配置流程严格进行配置管理。在配置流程中也详细提供了对更改的控制，没有经过批准的更改请求是绝对不能进行的。
　　(10)记录

　　记录及时、充分、比较准确。这些记录包括:重要的邮件、会议纪要、审核记录、缺陷报告、测试报告。
 
　　1)与客户和其他项目组的所有往来必须邮件记录。

　　2)对所有的活动都有一个跟踪落实的过程，比如对所有的Review记录和更改请求都会有一个状态标识，标识其当前状态，通过跟踪其状态来监督其落实。

　　3)对所有的活动，包括对文档和代码的更改都会有一个历史记录。

　　4)记录比较准确、比较客观。

　　5)许多记录都是通过定量的数值记录，强调以数据说话（CMM4级的重点就是量化管理）。

　　以上是A公司在项目管理中所涉及到的一些主要环节，很值得国内的软件企业在制定项目管理规划时借鉴。除此之外，我国的软件企业在产品开发管理的过程中，还易出现以下几个方面的问题:

　　1)需求说明差─需求不清楚、不完整、太概括、或者不可测试，都会造成问题。

　　2)不切实际的时间表─如果在很短的时间里要求做许多事，出现错误是不可避免的。

　　3)测试不充分─只能根据客户意见或系统崩溃来判断系统的质量。

　　4)不断增加功能─在开发正在进行过程中要求增加许多新的功能。这是常见的问题。

　　5)交流问题─如果开发人员对客户的要求不了解，或者客户由不恰当的期望，必然会导致错误。
 
　　这些问题的出现，将会对软件质量的保证产生不良影响，针对上述问题并结合A公司在项目管理方面的经验，笔者提出一些相应的解决方法，以供参考：

　　1)可靠的需求─应当有一个经各方一致同意的、清楚的、完整的、详细的、整体的、可实现的、可测试的需求。为帮助确定需求，可使用模型 (prototypes)。

　　2）合理的时间表――为计划、设计、测试、改错、再测试、变更、以及编制文档留出足够的时间。不应使用突击的办法来完成项目。

　　3)适当测试─尽早开始测试；每次改错或变更后，都应重新测试。项目计划中要为测试和改错留出足够时间。

　　4)尽可能坚持最初的需求─一旦开发工作开始，要准备防止修改需求和新增功能，要说明这样做的后果。如果必须进行变更，必须在时间表上有相应的反映。如果可能，在设计阶段使用快速的模型，以便使客户了解将会得到的东西。这将会使他们对他们的需求有较高的信心，减少以后的变更。

　　5)沟通――在适当时机进行预排和检查;充分利用团组通信工具―电子邮件、群件(groupware)、网络故障跟踪工具、变更管理工具、以及因特网的功能。要确保文件是可用的和最新的。优选电子版文档，避免纸介质文档:进行远距离联合作业及协作;尽早使用模型，使客户的预想表达清楚。

　　4.PC（项目经理）

　　项目经理是项目成败的关键人物，其对项目的成败负主要责任。因此在这里将项目经理的有关内容单独提出，以A公司为例详细说明PC在整个产品研发过程中所扮演的角色，希望能对国内软件企业的项目经理有所启示。

　　（1)在A公司，按流程在一个项目正式开展之前，项目经理需要完成：

　　* 项目计划(Project Plan):在此描述整个项目所应完成的交付物、项目时间表、培训需求、资源需求、质量保证计划以及过程和交付物的定量质量目标等。

　　* 项目配置管理计划(Project Configuration Plan):在此指定配置管理员，描述项目配置项列表、配置管理库、版本管理计划等等。

　　*项目过程手册(Process Handbook):在此描述本项目所采取的裁剪后的生命周期模型和流程。

　　（2）在项目开发过程中，项目经理需非常了解项目进度，进行工作任务细化、具体计划和安排项目成员工作任务等工作。对突发事件项目经理需能及时合理地进行协调。

　　（3)总的说来，PC安排工作有这么几个特点:

　　a.PC对软件开发具有丰富的经验，了解软件开发的普遍流程，了解各个阶段所需完成的工作，这是安排好项目组成员工作的前提，在A公司对PC的整体素质要求非常高。

　　b.在项目正式开展前，PC准备项目计划文档，在项目计划中包含了项目进度时间表，但此时间表比较粗，只能给出各个阶段和各个子阶段的起始结束日期。对各个阶段和各个子阶段的详细工作安排和各项工作责任人只能在项目开展工程中根据项目实际情况进行安排，一般是在每周项目组例会上进行本周详细工作安排。
 
　　c.PC对工作安排往往精确到天，有时甚至精确到小时，要做到这一点，需要:

　　* PC对本项目进展非常了解。了解渠道通常是每周组员的状态报告和直接与组员接触了解，这也需项目组成员能如实汇报工作。

　　* 对现阶段或本周所需完成的工作非常了解。知道现在该做什么，并且能把各项工作进行合理细致地划分，因为各个分解的工作比较细致，因此能相对精确地评估出这些工作完成所需的时间。

　　* PC对项目组员的能力比较了解，安排工作时能做到有的放矢。当安排的员工对工作不熟悉时，会指定相应的组员进行协助。

　　* PC对组员的工作安排都比较细致饱满。一般不会出现有些员工有事干，有些员工没事干的情况，当出现这种情况或员工提前完成工作时，PC就会进行相应的协调。

　　d.PC在项目组例会上的工作安排一般只限于本周或甚至是过后的二、三天，一般不会太长，对长时间工作的安排容易失去精确并且不易控制。相对而言，短时间的工作安排就比较精确而且容易控制，并且能不断根据完成的工作进行调整。当然，这就要求PC能根据项目计划中的项目时间表进行整体进度的把握。

　　e.项目组例会一般一周一次（时间不能太长），但必要时（如组员工作已完成或其他事情），也可在中途召开项目会议进行工作安排，一般时间都比较短（十几分钟左右，一般不超过半小时，以免浪费时间），总之，当PC觉得需要时，就会召开项目会议。

　　f.当项目组出现意外事件或影响项目团结的事件时，PC能及时合理协调，解决项目组内的不和谐气氛。
 
　　g.PC善于鼓励手下，发挥员工的潜能，PC往往会赞扬很好地完成了工作的组员。
 
　　从上面可以看出，对PC的能力（包括技术和管理能力）要求是非常高的，我国的软件企业往往只重视PC的技术能力，但事实上，一个只精通技术的人往往不能成为一个合格的领导者， 笔者认为对PC而言，首先要求他能够比他的下属看得更远一步，顺利时不盲目乐观，遇到挫折时不茫然失措，使整个团队始终保持高昂的士气。

　　总结

　　以上结合印度软件项目管理的经验总结了一些我国软件质量保障应注意的问题。曾有人提出:这样一味地学习模仿，民族软件工业没有多大希望。但笔者认为，在这个问题上不妨采取“拿来主义”的办法，对于好的，事实证明是成功的经验，首先是“占有”，然后才是“挑选”和“创新”。如果能把印度的管理经验真正领会并付诸实践，相信对我们的民族软件工业一定会起到积极的推动作用。

2. 白盒测试
　　白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。
　　“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。

3. 灰盒测试
     灰盒测试，确实是介于二者之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。
灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。
   灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识盒与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。
      灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。

<date>

Summary
总结 _____________________________________________________________

Coordinator协调员 <name> _____________________________________________________________


Sponsor主持人 <name> _____________________________________________________________


Participants参与者 <names and roles> _____________________________________________________________


Facilitator推动者 <name>
_____________________________________________________________

Metrics度量 <the total labor hours spent on planning and performing the retrospective>Planning:Meeting (meeting duration multiplied by the number of participants):Documentation Production:<计划和进行回顾的总工时>计划会议（由参与者数量累计的会议工时）文档输出
_____________________________________________________________

Things That Went Well
做得好的方面

Business Issues业务问题 1.
_____________________________________________________________

Requirements需求 1.
_____________________________________________________________

Process过程 1.
_____________________________________________________________

Project Management项目管理 1.
_____________________________________________________________

Technology技术 1.
_____________________________________________________________

<other category>其他归类 1.
_____________________________________________________________

<other category>其他归类 1.
_____________________________________________________________

Things That Could Have Gone Better
可以改进的方面

Business Issues业务 1.
_____________________________________________________________

Requirements需求 1.
_____________________________________________________________

Process过程 1.
_____________________________________________________________

Project Management项目管理 1.
_____________________________________________________________

Technology技术 1.
_____________________________________________________________

<other category>其他归类 1.
_____________________________________________________________

<other category>其他归类 1.
_____________________________________________________________

Things That Surprised Us
让我们意外的事情

Business Issues业务 1.
_____________________________________________________________

Requirements需求 2.
_____________________________________________________________

Process过程 1.
_____________________________________________________________

Project Management项目管理 1.
_____________________________________________________________

Technology技术 1.
_____________________________________________________________

<other category>其他归类 1.
_____________________________________________________________

<other category>其他归类 1.
_____________________________________________________________

Lessons Learned
经验教训

Business Issues业务问题 1.
_____________________________________________________________

Requirements需求 1.
_____________________________________________________________

Process过程 1.
_____________________________________________________________

Project Management项目管理 1.
_____________________________________________________________

Technology技术 1.
_____________________________________________________________

<other category>其他归类 1.
_____________________________________________________________

<other category>其他归类 1.
_____________________________________________________________

Final Thoughts
最后总结

Things to Keep维持原状的 1.
_____________________________________________________________

Things to Change要改进的 1.

  1、弄清概念的必要性
  随着软件学科和软件业的不断发展，“名词”越来越多。但是，“名词”背后的“含义”也真的有如此之多的增长吗？
  举个例子。1986年，Barry Boehm提出了软件开发的螺旋模型。从那时起，螺旋模型被当作软件开发的标准方法。螺旋模型还有其他不同的常用名字，比如演进模型，或者迭代模型[1]。类似的例子还有很多。
  看来，软件界存在不少这种“新瓶装旧酒”的现象——一个新名词出现了，它可能仅仅是披着新的表达形式的外衣，而其含义其实和某个旧名词相同。
笔者认为，在软件学科飞速发展的今天，反而是踏踏实实搞清楚“变幻无穷”的诸多名词背后的真正含义，才是最便捷之道。

  2、本文的方法：一图胜千言
  本文采用“为概念及其关系建模”这样一种方法，不仅考察单个名词的含义，还考察名词之间的关系。
  一图胜千言。一个概念的本质，往往需要从它同其他概念的关系中，得以体现。不仅考察个体，还考察多个个体之间的关系，这种方法在系统论中，被比喻成“1 + 1 > 2”。令人愉快的是硬币的另一面，注重考察关系这种方法，从其成本角度而言却是“1 + 1 < 2”。

  3、RUP核心概念解析
  3.1、任务来自问题
  RUP著名的二维结构，其时间维相关的概念有阶段、迭代、里程碑等，内容维相关概念有工作流、角色、活动、工件等。但笔者发现，不少人对这些概念理解不深，特别是对概念之间的关系把握不到位，造成实践中出现问题。

  另外，就是迭代式开发——这种包括RUP在内的多种软件工程过程都一致推崇的最佳实践——和活动、工件这些基本概念有何关系。不知道迭代和活动、工件的关系，实际应用RUP时又如何贯彻迭代式开发的思想呢？
  还有，配置和变更管理对所有现代软件开发过程都是必不可少的支持活动，RUP更是将其列为“RUP的6大最佳实践”之一。但笔者发现，不少开发人员认为配置和变更管理太麻烦，仅仅是因为他们没有理解配置和变更管理和工件的基本关系。
我们的任务，就来自于这些问题。我可以用一幅图解决这些问题吗？

  3.2、一图胜千言
  下图是一幅UML类图，它概括了上述问题的相关概念，并着重表达了概念之间的关系。本图的丰富语义，我们通过下面几节细细来分析。

  3.3、角色执行活动，活动生产工件
  任何软件工程过程，都少不了角色（role）、活动（activity）、工件（artifact）等概念（或者类似概念）。

  这些概念本身很好理解。角色是对个人或者作为开发团队的一组人的职责的规定；具体人和角色的关系，好比人和帽子的关系。活动就是角色执行的工作单元。工件就是工作的成品或半成品。
  倒是这些概念的关系显得更加重要。角色的职责，具体体现在他执行活动和负责工件上。工件是由活动生产出来的——工件是活动的输出；比如制定《编码规范》。然而，活动本身也可能以工件为输入——活动可能要求使用工件；比如编码活动要参考《编码规范》。还有一种关系，工件既是活动的输入又是它的输出——活动修改工件；比如修改《编码规范》。

  3.4、阶段和迭代：提供不同级别的决策时机
  尽早解决重大风险，是软件工程管理中的一条重要原则。正如Tom Glib所说：“如果我们不主动化解风险，那么它们会自己找上门来。”[2]心存侥幸是很危险的。
  RUP是风险驱动的。它将整个开发生命周期分为4个阶段：初始阶段、细化阶段、构造阶段、移交阶段。初始阶段着重化解业务风险，并确保所有涉众对项目达成一致的认识。细化阶段主要化解技术风险，要定义并创建可执行的系统架构。相对而言，当决定开始构造阶段的时候，风险已经比较小了。当然，风险是动态变化的，构造阶段和移交阶段照样会有这样那样的风险存在。

  RUP的每个阶段又可分为一到多个迭代周期。采用迭代式开发，意味着有持续不断的反馈；反馈是决策的基础，也是化解风险的基础。迭代式开发的一个主要目的就是尽早降低风险，通过每次迭代中分析、按重要性排序并解决主要风险，来达到尽早化解风险的目的。

  这个根据持续反馈来进行决策的时机，叫做里程碑（milestone）。里程碑有2种，阶段结束对应的里程碑叫做主要里程碑（major milestone）；迭代结束对应的里程碑叫做次要里程碑（minor milestone）。可以说，阶段和迭代，为开发团队提供了不同级别的决策时机。

  上图清晰的表达了上述分析的思想。里程碑分为主要里程碑和次要里程碑2种；阶段可以包含多次迭代；每个阶段必然有一个主要里程碑标识结束，每个迭代必然以一个次要里程碑标识结束。
  迭代的具体进行，是要靠角色执行相关活动。上图中的迭代和活动的多对多关系，精彩地反映了迭代开发的特点——每次迭代都执行多个（甚至全部）开发活动。

  3.5、配置和变更管理支持迭代式的基于基线的开发
  迭代式开发意味着每个后继迭代，都以前一个迭代为基础，不断地进化和完善系统，直至完成最终产品。历史上有一段时期，为了强调这一点，RUP曾特意宣传“迭代和增量开发”。
  建立并管理基线（baseline），为迭代式开发提供了有力支持。基线的要点有二：一是要通过评审，二是要受配置和变更管理控制。IEEE对于基线的完整定义是：已经通过正式复审和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能通过正式的变更控制过程进行改变。
  配置和变更管理完成建立并管理基线的任务。置于配置和变更管理之下的工件，称为配置项（configuration item）——因此下图把配置项建模为工件的子类。而基线就是有多个配置项组成的瞬时快照——因为受配置和变更管理控制是基线的必要条件。

  上面讨论了“工件－配置项－基线”这些静态概念，下面再讨论一下相关动态概念。任何工件，都有可能发生变更；正如并不是所有工件都是配置项一样，变更也不一定都受控，比如，用于讨论的临时设计就不必受控。只有配置项的变更，才是需要受配置和变更管理控制的。到底哪些工件应当受控，是根据实践情况决定的，应当在规范性和灵活性之间权衡考虑。

  3.6、发布是什么，发布不是什么
  发布（release）是软件产品的一个稳定的、可执行的版本，它包括了发布说明、用户手册等相关工件。
  单纯的文档或者不能执行的软件版本，并不是发布。
  发布是某个迭代周期的成果，但是并非每个迭代周期都用发布。
  图中表达得很明白，发布是特殊的基线。这意味着发布不是单一的工件，而是工件集；而且发布的工件都应当置于配置管理的控制之下，这是因为你必须标识和跟踪这些工件，开发团队或者用户的很多活动都和它们相关。

  4、总结
  UML已经广泛用于软件开发活动，可视化表达使得理解和解决问题变得容易。本文是UML的另一个应用，它被用来明确概念之间的关系，希望对大家有所启发。

  参考文献：
  [1] Gary Pollice等著，宋锐等译. 小型团队软件开发：以RUP为中心的方法. 中国电力出版社，2004
  [2] Per Kroll等著，徐正生等译. Rational统一过程：实践者指南. 中国电力出版社，2004

  作者简介：
  温昱，架构设计师，松耦合空间（http://lcspace.nease.net）创办人。擅长面向对象、架构和框架设计，对设计模式、UML和软件工程有深入研究。可以通过wenyu@china.com和作者联系。