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

 

UML Distilled

Martin Fowler

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

http://blog.csdn.net/dwater

 

概要开发过程

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

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

过程一览

初始

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

细化

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

构造

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

移交

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

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

初始

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

细化

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

1．开发人员能轻易估算构作一个用例所需的时间（精确到人周）；

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

 

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

需求风险

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

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

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

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

技术风险

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

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

技艺风险

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

政治风险

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

 

制定构造计划[1]

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

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

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

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

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

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

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

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

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

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

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

2003-10-01

构造

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

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

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

重构原则：

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

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

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

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

 

计划走岔之时

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

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

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

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

 

构作阶段UML的使用

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

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

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

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

移交

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

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

                                                                                                                                            2003-10-02

---

[1] 方法源自Beck2000一书。

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

 

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

http://blog.csdn.net/dwater