http://www.cnblogs.com/hack/archive/2010/08/25/1808561.html
6.3 基于 UML 的软件开发过程
6.3.1 开发过程概述
UML 是独立于软件开发过程的，能够在几乎任何一种软件开发过程中使用。迭代的渐进式软件开发过程包含四个阶段：初启、细化、构件、部署。
1、初启
项目的发起人 确定项目的 主要目标 和 范围，初步的可行性分析 和 经济效益分析。
2、细化
细化阶段的开始 标志着 项目的正式确立。
1.初步的需求分析，比较重要、比较有风险的用例。
2.初步的高层设计，用例、用例图、类、类图 将 依据 包 的划分方法 分属于 不同包。
3.部分的详细设计，根据软件元素 的重要性和风险程度 确立优先细化原则，不能将风险的识别和解决延迟到细化阶段后。
4.部分的原型构造。
3、构建
构造阶段，每次迭代中实现一部分用例，用户可以及早参与对已实现用例的实际评价。
原则：
1.用户认为业务价值较大的用例 应 优先安排。
2.开发人员评估后 认为 开发风险较高的用例 优先 安排。
迭代计划中，要确定迭代次数、每次迭代所需时间 以及 每次迭代中应完成的用例。
6.3.2 基于 UML 的需求分析
1、生成用例
如果多个用户扮演同一角色，这些用户将由单一执行者表示。如果一个用户扮演多种角色，则需要多个执行者来表示同一用户。
用例主要来源于分析人员对 场景的 分类和抽象，即将相似的场景进行归类，使一个用例可以通过实例化和参数调节而涵盖多个场景。
2、用活动图表示用例
3、生成用例图
执行者与用例之间的关系有两种：触发执行、信息交换。
执行者指向用例 表示 触发执行 和/或 信息交换，用例指向执行者 表示用例将生成的信息传递给执行者。
4、建立顶层架构
顶层架构便于开发人员 聚焦于系统的不同部分。
模型——视图——控制器（Model、View、Controller，MVC）模式。
模型 维护并保存数据，视图 呈现数据，控制器将动作映射为处理功能并实际调用。
MVC 模式特别适合于分布式应用软件，尤其是web应用系统。
分层模式 降低软件系统的 耦合度。
确立顶层架构的过程中需综合考虑以下因素：
包的数量，架构过早地陷入细节，返工的可能性很大，也不合理地限制了后续分析和设计活动的自由空间。
包之间的耦合度。
将不稳引起的软件元素分类聚集于少数几个包中，以提高软件系统的可维护性。
可选功能 和 必须实现的功能 置于 不同的包。
根据开发人员 专长 划分，使每个包都能分配给最合适的开发人员，有利于并行开发。
6.3.3 面向对象的设计方法
1、设计用例实现方案
1.提取边界类，实现类和控制类。
边界类用于描述 系统与外部环境之间的交互。
a.界面控制。
b.外部接口。
c.环境隔离。使目标软件系统的 其余部分 尽可能地 独立于环境软件。
边界类，<<boundary>>。
实体类“内向收敛”特征，仅提供 读/写 信息的必要操作 作接口，并不涉及业务逻辑处理，<<entity>>。
控制类，<<control>>。
边界类的作用范围可以超越单个用例。
2.构造交互图
交互图作为用力的精确实现方案。
事件流中的事件 直接对应交互图中的消息，事件间的先后关系体现为 交互图中的时序，对消息的响应 则构成消息接收者的职责，这种职责被确立为 类的方法。
不应该出现 穿越控制类 生命线 的消息。
为 易于理解，应该用分离的 UML 交互图 分别表示 事件流和每个备选事件流。
原则上，每个类都应该有一个操作来响应交互图中指向其对象的那条消息。
2、设计技术支撑方案
当用户需求发生变化时，技术支撑方案应具有良好的稳定性。
技术支撑方案应该位于层次结构中的较低层次。
一方面取决于 需求，另一方面取决于 对软件技术手段把我和选取。
3、设计用户界面
1.熟悉用户 并对 用户分类，以便尽量照顾到所有用户的合理要求，并优先满足某些特权用户。
2.按用户类别 分析用户的 工作流与习惯，从每类中选取一个用户代表，建立调查表，判断用户对操作界面的需求和喜好。
3.首先应考虑命令的顺序，一般常用命令居先，与用户工作习惯保持一致；其次，根据外部服务之间的聚合关系组织相应的命令；然后充分考虑人类记忆的局限性，最好组织为一颗两层多叉树；提供操作的快捷方式。
5.利用快速原型演示，改进界面设计。并评判系统是否 齐全、方便、好用。
4、精化设计模型
对模型进行改进的活动可以分为 精化 和 合并 两种。一般先从精化开始。设计优秀的粗粒度组件应该只是完成一项功能，这一点是它与子系统的主要区分。
粗粒度组件的范围过于广泛，难以发挥重用价值，粗粒度组件拥有持久化的行为，拥有业务逻辑，需要表示层的支持。
将需求分成几个功能组，基本上就可以得到相应的粗粒度组件了。
过小的范围，将会造成粗粒度组件不容易使用，用户需要理解不同的粗粒度组件之间的复杂关系。
如果可能，在粗粒度组件之间定义单项关联可以有效的减少组件之间的耦合。
尽可能简化组件之间的关系。
我们需要从软件的目标领域中 识别出关键性的实体，或者说领域中的名词。然后决定它们应该归属于那些粗粒度组件。
两个组件之间存在重复的要素，可以从中抽取共性的部分，形成新的组件。
6.4 系统架构文档化
6.4.1 模型概述
以精心选择的形式 将若干结构元素进行装配。
软件架构 = { 元素，形式，关系/约束 }
逻辑视图（logical view）对象模型。
过程视图（process view）并发和同步特征。
物理视图（physical view）分布式。
开发视图（development view）静态组织结构。
场景。
Rational 4.1 视图模型。
每个视图上均独立地应用 Perry&Wolf 软件架构公式。
对每种视图选用特定的 架构风格（architectural style）。
6.4.2 逻辑结构
逻辑架构主要支持功能性需求，系统分解为一系列的关键抽象，（大多数）来自于问题域，表现为对象或对象类的形式。
抽象、封装、继承。
对于数据驱动程度高的应用程序，可以使用其他形式的逻辑视图，如 E-R图 代替面向对象的方法。
1、逻辑视图的风格
采用面向对象的风格，试图在整个系统中 保持 单一的、一致的 对象模型。
6.4.3 进程架构
进程架构考虑一些非功能性的需求，并发性、分布性、系统完整性、容错性，以及逻辑视图的主要抽象如何与进程结构相配合在一起。
进程是 构成可执行单元任务的分组。
区分主要次要任务：主要任务是 可以唯一处理的架构元素；次要任务是 由于实施原因而引入的局部附加任务。
6.4.4 开发架构
开发架构关注软件开发环境下实际模块的组织。
开发架构用模块和子系统图来表达，显示了“输出”和“输入”关系。
考虑因素：开发难度、软件管理、重用性、通用性、由工具集、语言 所带来的限制。
开发视图 是建立产品线的 基础。
推荐使用分层（layered）的风格，每层具有良好定义的职责。某层子系统依赖同一层或低一层的子系统，最大程度地减少了具有复杂模块依赖关系的 网络的开发量。
6.4.5 物理架构
物理架构主要关注系统非功能性的需求，可用性、可靠性（容错性），性能（吞吐量）、可伸缩性。
软件至节点的映射需要高度的灵活性 及 对源代码产生最小的影响。
6.4.6 场景
4种视图的元素通过数量比较少的一组重要场景（更常见的是用例）进行无缝协同工作，我们为场景描述相应的脚本（对象之间和过程之间的交互序列）。
在某种意义上 场景是最重要的 需求抽象。
4+1 的 +1 起到了两个作用：
作为一项驱动因素 来发现架构设计过程中的 架构元素。
作为架构原型测试的出发点。
场景表示法与组件逻辑视图非常相似，但它使用过程视图的连接符来表示对象之间的交互。
6.4.7 迭代过程
在进行文档化时，提倡一种更具有迭代性质的方法——架构先被原型化、测试、估量、分析，然后在一系列的迭代过程中被细化。
除了减少 风险之外，还有其他优点：团队合作、培训、加深对架构的理解、深入程序和工具 等。使 需求被细化、成熟化。
系统大多数关键的功能以场景的形式被捕获，关键意味着：最重要的功能、系统存在的理由、使用频率最高的功能、必须减轻的一些重要技术风险。