《UML精粹》学习笔记系列-第二章 开发流程

第二章  开发流程

   UML是从一大推面向对象分析与设计的方法论中所诞生出来的。在某种程度范围内，这些方法论都会在图形模型语言中混合某种开发流程，以说明软件该如何开发下去。

1.反覆式和瀑布式的开发流程

      两者的本质差异在于：我们该如何把项目分解成一些比较小的部分。我们需要把项目加以分解，这样一来大家就可以随时掌握问题，并追踪进度。

瀑布式开发风格是根据开发活动来分解项目的。为了编写软件，你需要进行一些特定的开发活动，包括：需求分析、设计、编程与测试。如果是一年的时间需要如下分配：

分析阶段	设计阶段	编码阶段	测试阶段
2个月	4个月	3个月	3个月

反覆式开发风格则是根据不同的功能性子集合将项目分解开来。你可以把一年的项目分解成每次长达三个月的反覆。在第一次反覆中，我们会处理约1/4的需求，并且将者1/4的需求走完整个软件开发的生命周期：分析、设计、编码和测试。在反覆结束出，我们会哟偶完成1/4所需功能性的系统。接下来，我们会进行第二次反覆，它会在第6个月结束。

你可以采用混合式的解决方案，【McMconnel】一书中描述了一种分期交付式生命周期，它会先以瀑布式开发风格完成分析与高阶的设计工作，然后将编程序与测试工作分成几次反覆。以一年的项目为例：它可能会有长达4个月的分析与设计工作，然后以4次长达2个月的反覆来建构出系统。

OO社群长久以来一直偏好反覆式开发方式，而且我们可以放心大胆地说有非常多跟建立UML有关的人，至少都偏好某种形式的反覆式开发关系。

虽然大家都宣称正在采用反覆式开发方式，不过实际上却是按照瀑布式的方法在做。常见的特征有：

A、我们现在正在进行一次分析反覆，接下来会有两次的设计反覆。。。。

B、这次的反覆的程序中有许多程序bug，不过我们最后将会把它们都清除干净。

评注：由于反覆式开发希望在反覆结束之后，可以产生具备产品品质、测试、整合过的软件出来。所以如果反覆结束之后，程序中有许多bug，就不能说反覆结束。另一方面，这点反而像是瀑布式开发流程中编写代码开发阶段结束，下一步准备进行测试开发阶段。

    

采用反覆式开发方式时常会用到的一种开发技术就是 固定时间长度（time boxing）。它让每次反覆都有固定长度的时间。如果你发现原本在某次反覆中想要建构的部分无法完全做完的话，那么你必须决定要在这次反覆中将某些功能延迟处理；而不是将这次反覆的结束日期延后。

如果大家能够经常性的将系统功能延后处理，那么等到他们面对大的发行版本、需要对延后日期或功能做出明确抉择时，就会有较好的经验来处理它。另一方面，在反覆间延后处理某些功能，可有效帮大家学习如何找到真正的需求优先顺序。

对犯法是开发方式来说，最常见的考量之一就是重写编码的议题。重写程序比维护那些设计不好的程序更有效率。下面列出一些实际经验，它们非常有助于让重做变得更加有效率。

自动化的回归测试（automated resgression tests）	当我们正在改变一些东西时，它有助于我们快速侦测到任何程序的瑕疵：单元测试有一条不错的经验法则就是，单元测试的程序代码大小大约跟你的产品程序代码相当
重构（refactoring）	它是以有纪律方式改变现有软件的一项开发方式。重构是将一连串小的、保留行为的转换动作施行到程序代码库的工作方式。
持续整合（continuous integration）	它能让整个团队保持同步，以避免痛苦的整合周期。这种做法的核心是已完全自动haunt的建构流程为基础达到的。

2、预测式和自适应的规划方式

预测式的解决方案想在项目初期做一些事，以便可以更加了解稍后会发生的事。采用 预测式规划方式时，我们可以把项目区分成两个时期。在第一个时期，我们会先想出一个计划，这时候计划书是比较难预测的。不过，等到第二个时期，因为计划书已经在实施当中了，所以他就变的比较容易预测。

在软件项目中，增加它的复杂度的其中一个独特来源就是我们很难了解软件系统的需求为何。绝大多数项目都会经历重大的需求剧烈变动：在项目后期发生需求变动。这些变动会撼动真个预测计划的基础。

评注：需求变动是所有软件开发者心中的疼

另一种流派主张需求剧烈变动是不可避免的事。对许多项目来说，我们几乎不可能让需求稳定到可使用预测计划。一方面是因为单凭想象就要知道软件能做什么是一件极度困难的事，另一方面则是因为市场环境会造成不可预测的变动。采用这个想法的流派倡导 自适应规划方式，可预测被他们视为幻影。他们采用规划方式会将软件项目中的变动视为一种常态。他们以控制变动的方式让项目交出它所能做出来的最佳软件；我们虽然会去掌控项目，不过，却不认为它是可预测的。

评注：自适应将计划驱动的流程缩短以为数周为单位的循环周期，在每一个周期中，我们根据当前的情况不断地调整计划以及计划的执行过程，同时不断地产生能够工作的代码，并且不断地将代码部署到应用环境中去。

对比两种方式，有两点建议：

A、除非你有一份精确、稳定的需求，而且有把握他们不会发生显著变动，要不然请不要做出一份预测性计划

B、如果你无法获得一份精确、稳定的需求，那么采用自适应的规划风格。

3、敏捷开发流程

敏捷开发流程本质上具有很强的自适应性。同时他们也是非常具有人员导向的开发流程。敏捷开发解决方案假设项目成功的最重要因素在于项目成员的职业素质，以及在人际关系上他们合作的情况究竟如何。至于他们所使用的开发流程或开发工具严格来说都只有次一级的效果。

评注：敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件爱你开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果多经过测试，具备可视、可集成和可运行使用的特征。从这个定义我们就可以理解上面的那段话了，当一个项目被切换成一个个小项目时，如果某个开发人员负责的项目不够稳定，就会出现“木桶效应”；如果一旦某几个成员对项目不能够完全理解，后期就会花费大量的时间用于整合。

4、Rational统一开发流程

  RUP虽然被称为开发流程，不过事实上他是一个开发流程框架，里面提供跟开发流程有关的一整组字汇与松散的结构 

  当你在使用RUP时，你要做的第一件事就是选出自己的开发案例：它是你在项目中将会施行的开发流程。开发案例间的变异很大，所以不要奢望你的开发案例看起来会跟其他开发案例很像。

RUP本质都是反覆式开发流程。瀑布式开发风格并不符合RUP的精神。

所有RUP项目必须遵循下面四个开发阶段：

（1）、初始阶段（inception）:它会对项目作出一个最初的评估结果。

（2）、详述阶段（elaboration）:它会找出项目的主要使用案例，并且会在几次反覆中写出软件，以并让系统的架构成型。在详述阶段结束结束时，你应该对需求有很好的体会，而且回一个大致上成形、可运行的系统，我们将把它当做后续开发工作的源头。

（3）、构建阶段（construction）：它会继续进行写软件的过程，写出发行出去的功能性。

（4）、移交阶段（transition）:里面会有各式各样后期、不需要反覆进行的开发活动，可能会包含将软件配置到资料中心、使用者训练等等类似的事项。

评注：完成这4个阶段称为一个开发周期，它产生的软件称作第一代。除非生命结束，一个现有铲平可以通过重复下一个相同的起始、详述、构建和移交四阶段，各个阶段的侧重点与第一次不同，从而演进为下一代产品。这个时期我们称之为演进（evolution）。最后伴随着产品经过几个周期的演进，新一代产品不断被制造出来。

详细可参考：http://www.ibm.com/developerworks/cn/rational/r-rudp/ 点击打开链接

5、裁减开发流程以适合项目需要

  软件开发工作的进行方式会受到许多因素影响。因此我们总需要将开发流程加以裁减，以适合项目的特殊环境需要。

评注：模式——UML可以告诉我们该如何表达出面向对象设计的结果。相反地，从模式所看到的开发流程所得到的结果：它们可用来作为范例的设计结果。

模式不仅仅只包含一个模型而已，里面也包括了采用这种做法的理由究竟为何。我们通常会说模式代表他对某种设计问题的解决方案。模式中必须清楚地点出问题所在、解释它解决问题的理由，也会说明什么环境下，我们可采用或不能采用这个模式。

模式之所以很重要，是因为他们是理解一种语言或模型技术的下一步。

6、在开发流程中使用UML

不论你是不是采用瀑布式解决方案，我们都依然会做分析、设计、编码与测试等开发活动。你可以在具有一个星期长反覆的反覆式项目中，每个星期施行一次微型的瀑布式开发流程。

需求分析

在需求分析开发活动中，我们会试图了解：针对我们将花费功夫的软件，它的使用者与顾客究竟想要系统做些什么事。与其相关的UML现有相关技术：

A.使用案例（use case），我们会在里面描述人们是如何跟系统互动的。

B.由概念性观点所画出来的类别图（class diagram）,它是我们可拿出来建构领域中一组精确字汇的好方法。

c.活动图（activity diagram），里面可秀出组织的工作流程，以了解软件跟人类活动间是如何互动的。

D.状态图（state diagram）,如果某个概念具有一种有趣的声明周期时，它就会变得有用，里面会秀出各种状态以及改变状态的事件。

在进行需求分析时，请记住，其中最重要的一件事是跟你的使用者与顾客沟通。

在分析时用UML的最大风险就是：那些领域专家无法完全理解你所画出的图。如果了解领域的人武大理解这张图，那么它所造成的后果比没有用更糟；因为它会引起大家对开发团队的不信任感。

设计

当你在进行设计工作时，你可以在图中加入更多技术细节。一些相关技术包括：

A、由软件观点所画出的类别图，里面会秀出软件中的类别，以及他们间是如何相关的。

B、常见情节的时序图（sequence diagram）。一种很有价值的做法是从使用案例中找出最重要、最有趣的情节，然后用CRC卡（CRC card）或时序图画出软件中会发生什么情形。

C、用打包图（package diagram）画出软件中大型结构的组织方式。

D、针对有复杂生命历程的类别，画出他们的状态图

E、用配置图（deployment diagram）画出软件的实体安排情形。

不论是下蓝图或草稿做法，找寻设计上的一些替代方案，这对我们来说都是有意义的事。我们通常最好是在草稿模式下探索这些不同替代方案，因为它可让我们快速产生这些替代方案，并修改它们。

文档

一旦你写好软件之后，你可以用UML来帮你记录下来什么东西已经完成。针对这点，我发现UML的图有助于大家对系统产生一个整体了解。写文档的人需要决定什么东西重要、什么不是，不过写的人通常会比读此书的人具备更好知识，足以做出这样的判断。

7、了解前人所遗留的程序

UML可以用一两种方式来帮你理解一大推不熟悉的程序。体关键事物画出草图这种做法可当成一种推行的笔记机制，他可以在你学习这些程序时，帮你记下一些重要资讯。