系统架构师学习笔记_第六章（下）_连载

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  迭代过程

在进行文档化时，提倡一种更具有迭代性质的方法——架构先被原型化、测试、估量、分析，然后在一系列的迭代过程中被细化。

除了减少 风险之外，还有其他优点：团队合作、培训、加深对架构的理解、深入程序和工具 等。使 需求被细化、成熟化。

系统大多数关键的功能以场景的形式被捕获，关键意味着：最重要的功能、系统存在的理由、使用频率最高的功能、必须减轻的一些重要技术风险。