《UML Distilled》读书笔记--概要开发过程

本文是《UML Distilled》一书的读书笔记,主要探讨了使用UML进行概要开发的过程,涵盖了领域模型构建、测试策略以及在实际工作和任务中的应用。
摘要由CSDN通过智能技术生成

 

UML Distilled

Martin Fowler

屋檐下的水滴-- 读书笔记系列

 

概要开发过程

不了解建模技术如何适应过程,建模技术就不会有丝毫意义。UML是独立于过程的。不管使用什么过程,都可以用UML来记录分析结果和设计决定。

开发组应该产生自己的过程。与软件开发有关的各种因素,如软件种类、规模等等,促使你使用各种不同的过程。利用已发表的过程作为起点,而不是遵循的标准。

过程一览

初始

确定项目业务依据,粗略估计值多少钱、可挣多少钱,确定项目范围

细化

收集更详细的需求,进行高层分析与设计,建立基础体系结构,制作构造计划

构造

多次迭代,每次是一个小的项目,对每次迭代的用例进行分析、设计、编码、测试、集成

移交

β测试、性能调整、用户培训

任何阶段都可以有迭代,但构造乃是进行迭代的关键阶段,其中每次迭代都构造优产软件,进行测试与集成,满足项目需求的一个子集。每次迭代包括通常生存期的所有阶段,即分析、设计、实现、测试。

初始

制定项目的业务依据,确定项目范围,可能需要初步分析以得出项目规模概念。Martin建议初始不要做太多,而应该只是几天的工作,以判断是否值得在细化阶段进行几个月的深入考察。

细化

细化大约占项目全过程的1/5,其完成标志两件事情为:

1.开发人员能轻易估算构作一个用例所需的时间(精确到人周);

2.已经识别出所有的重要风险,并知道如何应对。

 

风险驱动。识别那些驱使你偏离正常进程的风险,风险越大,越需要留意。

需求风险

最重要的任务是尽可能多的发现用例,特别是最重要最有风险的用例。为此,应安排几次和用户的面谈。

另一重要任务是构作领域模型轮廓。从概念视面绘制的类图、活动图这两种UML技术对此极为重要。前者可用于描述业务专家在思考业务时所用的概念,以及他们将这些概念联系起来的方法;后者最重要的用途是帮助发现并行线程,并可在业务过程中消除一些不必要的顺序。

应该把初始的领域模型看作是一个轮廓,而不是一个高层模型,诀窍是发现并专注于重要细节。构作领域模型的应是一个24人的小组,包括开发人员和领域专家。建模期间,应确保既未在细节中裹足不前,又未运作在一个太高的层次之上。已知用例会驱动领域模型。

对付需求风险最重要的要素之一是熟悉领域的专业知识,不接近领域专家是项目失败最常见的原因之一。值得花相当时间和财力引入领域专家。

技术风险

最重要的工作是构作原型,以确定风险,确定工作量。应针对用例的任何微小部分构作原型。构作原型时不要受实际发布环境的限制。

最大的技术风险在于如何把各个设计成分组合在一起,而不在于成分本身。

技艺风险

获得OO技艺的最佳办法是导师指导。如果无法办到,可考虑每两个月左右做一次项目审查,让经验丰富的导师花几天时间审查设计的各个方面。也可以通过阅读来补充技艺,至少每两个月读一本扎实精深的技术书籍。

政治风险

找一名老练的法人政治家。

 

制定构造计划[1]

制定计划的要素包括:对构作建立一系列迭代,定义每次迭代要发布的功能。步骤如下:

1.   用例分类。首先,客户按业务价值将用例分为高、中、低三档;然后,开发人员按开发风险进行分类。

2.   用例工作量估算。开发人员估算以最佳状态构作每一个用例(包括分析、设计、编码、单元测试、集成、编制文档)所需的时间,并精确到人周。

3.   考虑是否需要细化那些高风险、需花费大量时间的用例。

4.   确定迭代长度。对整个项目使用一个固定的迭代长度,以得到正常的发布节律。一次迭代构作少量用例。对于C++,迭代长度可高达68周。

5.   通过比较估计和现实来度量,并设定一个负载因子,它是理想时间和现实时间之差。

6.   计算一次迭代的开发量,即项目速度 = 开发人员数 * 迭代长度 / 负载因子。

7.   初步估计构造所需的迭代次数。 迭代次数 = (所有用例的总时间 / 项目速度) + 1

8.   对迭代分配用例。优先处理优先级高、开发风险高的用例。

9.   分配构造阶段10%35%的时间用于移交前的调整与包装;根据风险程度的大小,将构造阶段10%20%的时间作为意外因子,加于移交阶段的末尾[2]

10.完成一个交付计划,在其中指明每次迭代要做的用例。随着项目的进展,联合用户适当的调整它。

2003-10-01

构造

迭代的目的是降低风险。它可以早点暴露风险,并用于更好的控制开发。

测试和集成是大任务,它们占用的时间往往要比预期长,把它们留到收尾来做,任务就会艰巨,并导致士气低落。因此Martin鼓励编写自测试软件。集成应该是一个持续过程,每天都做详尽的构作和集成。

重构是代码迭代中一项非常有用的技术,用于减轻重新设计的短痛。它不改变程序功能,而只是改变其内部结构,使其更易理解和更易起作用。

重构原则:

1.   不要同时进行重构和功能添加。将二者清楚的分开,按一些短小的步骤交替进行。

2.   保证在重构之前已进行良好的测试。

3.   采取短小而谨慎的步骤进行重构,每一步之后都要进行测试。

增添新功能或修复错误后,应该进行重构。不要安排专门的时间,而是每天做一点。

 

计划走岔之时

对计划要确切了解的唯一一件事情:事情并不是按照计划进行的。

计划管理的全部工作:有效的适应变化。

迭代开发的关键是恪守日期表,不许错过任何日期。不过,经过和用户协商,用例可以推迟。

应该期望每两次或三次迭代,就变动一次计划。

 

构作阶段UML的使用

增加用例时,使用概念类图来确定其作用范围,看这些概念如何适应已经产生的软件。

和领域专家共同使用UMLBrad Kain说,仅当和领域专家坐在一起时,才会出现分析,否则便是拟分析。

讨论设计时,需探讨各个类如何协作以实现每一个用例。CRC卡和交互图可以清楚的描述记录在类图上的职责和功能。将这些设计视作初稿和讨论设计途径的工具,并转化为代码。

代码将暴露设计缺陷,此时应勇敢的改变设计。

移交

迭代开发的要点:正规运行整个开发过程,养成良好的交付习惯。

优化为了提供系统性能而降低可理解性与可扩展性。过早优化会使开发更难,必须留到结尾再做。

                                                                                                                                            2003-10-02



[1] 方法源自Beck2000一书。

[2] 不考虑意外因子而计划发布,即按内部目标日期计划发布,但提交发布却在意外因子结束之时。

 

屋檐下的水滴-- 读书笔记系列
  
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值