系统构架师学习 第六章

第六章 UML 建模与架构文档化

方法种类的膨胀，极大地妨碍了用户的使用和交流。

UML通过统一的表示法，使不同知识背景的 领域专家、系统分析、开发人员、用户 可以方便地交流。

6.1.2  UML 体系结构演变

UML 是用 元模型 描述的，元模型是 4层元模型体系结构模式中的一层，其他层次分别是 元-元模型、模型层、用户对象曾。其中元模型层 由 元-元模型层 导出。

元模型的体系结构模式 可以用来定义 复杂模型 所要求的 精确定义，这种复杂模型通常需要被 可靠地 保存、共享、操作 以及在工具之间进行交换。它的特点如下：

1、在每一层都递归地定义语义结构。
2、可用来定义 重量级和轻量级 扩展机制。
3、在体系结构上 将其他体系结构的标准统一起来。

UML 元模型又被分解为三个逻辑子包：基础包、行为元素包、模型管理包。

6.2  UML 基础

UML 通过 图形化的表示机制 从多个侧面 对系统的分析和设计模型进行刻画。

10种视图，四类：

1、用例图

2、静态图，包括 类图、对象图、包图。

类图的边表示类之间的联系，包括 继承、关联、依赖、聚合 等。

对象图描述在某种状态下或某一时间段，系统中 活跃的对象及其关系。

包由 子包、类 组成。

3、行为图，包括 交互图、状态图、活动图，他们从不同的侧面刻画系统的动态行为。

交互图分为 顺序图、合作图。顺序图强调 对象之间 消息发送的时序。合作图更强调对象间 的动态协作关系。

状态图 描述 对象的动态行为。

活动图 描述 操作序列，这些操作序列 可以并发、同步，包含控制流、信息流。

4、实现图，包括 构件图、部署图。描述组成和分布情况。

部署图 节点表示实际的计算机和设备，边表示节点之间的物理连接，也可以显示连接的类型及节点之间的依赖性。

6.2.2  用例和用例图

用例图 也翻译为 用况、用按 等，在 UML 中，用例用一个椭圆表示，往往用 动宾结构 或 主谓结构 命名。

可选的 动作序列 和 会出现异常的动作序列。

用例是代表系统中 各种相关人员之间 就系统的行为所达成的契约。

需求阶段 用例是 分析人员与客户沟通的工具 项目规模估算的依据；
设计阶段 用例是 系统功能设计的主要输入；
实现阶段 用例是 检测类型为正确性的文档。

本质上，用力分析 是一种功能分解 的技术。

1、参与者 角色，参与者实际上 并不是系统的一部分。

2、用例间的关系，泛化、包含、扩展 等。

包含是比较特殊的依赖关系。

扩展，基本用例必须声明 若干“扩展点”，而这些扩展用例只能在这些扩展点上增加新的行为和含义。

3、用例图

建模人员可以在途中给某些图符加上填充色，在语义上，使用填充颜色和不使用填充颜色的模型是 一样的。

6.2.3  交互图

描述对象之间 对象与参与者之间 动态协作关系 协作过程中行为次序。

通常描述用例的行为，显示该用例中所涉及的对象 对象之间的消息传递。

顺序图、协作图 之间可以互相转化，一个用例需要多个顺序图或协作图。

交互图可以帮助分析人员 对照检查 每个用例中所描述的 用户需求，提醒分析人员去补充遗漏的类或方法。

水平方向为对象维，一般 主要参与者放在最左边，次要参与者放在最右边。

垂直方向为时间维。

6.2.4  类图和对象图

一般而言，类的名字是 名词。

类之间的关系 有 关联、聚集、组合、泛化、依赖 等。

1、关联，链 是关联的实例，关联表示 类与类之间的关系，链表示 对象与对象之间的关系。

关联用 实线表示，角色还具有多重性。

关联类 描述关联的 属性、操作、以及其他信息。

关联类 通过一条虚线与关联连接。

自返关联 又称 递归关联，同一个类的两个对象间的关系。两个关联端，每个关联端的角色不同。

2、聚集和组合

聚集 是一种特殊形式的 关联，类之间整体与部分的关系。

组合 整体与部分具有同样的生存期，是一种特殊形式的聚集。

3、泛化关系，一般和特殊元素之间的关系，就是平常所说的继承关系。

6.2.5  状态图和活动图

1、状态图

描述 对象 生存期间的 动态行为，所经历的状态序列，引起状态转移的 事件、动作。

是 UML 动态行为建模的 5个图之一，用 状态机 对一个对象的生命周期建模，状态图 用于显示状态机，重点在于 状态之间的控制流。

除了 初态和终态，还有 Idle 和 Running 两个状态，keyPress、finished、shutDown 是事件。

2、活动图

是 UML 动态行为建模的 5个图之一，描述系统的 工作流程 和 并发行为。状态图的特殊形式，一个活动结束后将立即进入下一个活动。

基本概念：活动、泳道、分支、分叉、汇合、对象流。

1.活动，注意区分 动作状态 和 活动状态，

动作状态是原子的，没有内部转移，没有内部活动，所占用的时间可以忽略，目的是执行进入动作，然后转向另一个状态。

活动状态是可分解的，工作完成需要一定的时间。

2.泳道，是活动图中区域划分，每个泳道代表一个责任区，泳道 和 类 并不是一一对应的关系。

3.分支，同一个触发事件，可以根据不同的警戒条件 转向不同的活动，每个可能的转移 是一个分支。

4.分叉和汇合，如果要表示 系统或对象 中的 并发行为，使用 分叉fork 和 汇合join，汇合正好与分叉相反。

5.对象流，活动图中可以出现对象，对象可用作为活动的输入输出。活动图中的对象流表示活动和对象之间的关系。

6.2.6  构件图

构件 是系统中 遵从一组接口 且提供其实现的 物理的、可替换 的部分。

构件图 显示一组构件 以及它们 之间的相互关系，包括 编译、连接、执行时 构建之间的依赖关系。

构件就是一个实际文件，以下几种类型：

1、部署构建
2、工作产品构件
3、执行构件

构件图可以对以下几个方面建模：

1、对源代码文件之间的相互关系建模。
2、对可执行文件之间的相互关系建模。

6.2.7  部署图

部署图 也称 配置图、实施图，显示系统中计算节点的 拓扑结构、通信路径、节点上运行的软构件等。

一个系统模型只有一个部署图，常用语帮助理解分布式系统。

部署图 由 体系结构设计师、网络工程师、系统工程师 等 描述。

 

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

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

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

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