软件体系结构——第六章<用例分析>

一、理解分析

什么是分析？

• 为了满足需求模型中所描述的功能，系统内部应该有什么样的业务核心机制

分析目标是开发一系列模型来描述软件的核心成分，从而满足客户定义的需求：建立分析模型

分析模型主要包含：

• 两个层次：构架分析和用例分析

• 两类模型：静态结构(包图、类图)和动态交互(顺序图、通信图)

牢记：分析模型的模型元素按照构架来组织，各类视图按照用例实现来组织

二、从用例开始分析

2.1、OOA目标

开发一系列模型来描述计算机软件，从而满足不同客户定义的需求：建立分析模型

• 包括两种模型图：描述对象及其交互

• 这些图按照用例模型来组织，每个用例图都会产生数张图。如：

  • 类图（class diagram）：描述了构成一类对象特征的状态和行为（描述软件架构）
  • 交互图（interaction diagram）：描述对象之间的交互行为（描述系统行为）

2.2、分析模型与用例模型

2.3、从需求到分析

2.4、OOA vs 用例模型

分析是建立在业务需求收集的基础上的，故分析模型则建立在用例模型的基础上；

用例模型确定了分析模型的结构——通过用例来组织分析模型；

分析是从用户视角理解用户问题（用例模型）过渡到开发团队视角分析用户问题（OOA）;

分析与需求捕获都需要多次迭代。

2.5、从用例开始分析迭代

RUP方法中最重要的思想就是迭代，而迭代的基础就是用例驱动（用例建模）

从用例开始分析的基本思路：

• 根据用例图和用例文档来确认需求定义是可靠的、一致的

• 用例分级：根据风险、重要性以及项目组的能力确定用例、以及用例相关路径的优先级

2.6、用例实现

用例实现是分析(设计)模型中一个系统用例的表达式。主要工作有：

• 使用构造型 <<use-case realization>>

• 描述对象间的协作（交互图）以完成用例目标

• 将用例模型中的用例和分析(设计)模型中的类和关系连接在一起

• 说明每个用例必须用哪些类来实现？

用例实现提供了从分析设计到需求的可追溯性

创建用例实现：

三、架构分析

架构（也称构架）Architecture ——系统的组织结构

• 面向对象分析与设计都是以架构为中心进行的

• 每个软件系统都有架构，可简单、可复杂

• 架构需要经过若干次分析与设计的迭代来完成

• 架构的分析与设计贯穿于整个分析与设计过程

构架分析的过程就是定义系统的高层组织结构和核心构架机制的过程。主要有：

• 定义系统高层组织结构—定义备选构架

• 确定系统通用构架机制—分析架构机制

• 提取系统的关键抽象以揭示系统必须能够处理的核心概念—关键架构抽象——搞清业务本质

• 创建用例实现来启动用例分析—用例实现

3.1、定义备选构架

所需工作：

①创建系统

• 设计构架的初始草图

• 初步定义一组在构架方面具有重要意义的元素，以用作分析的基础

• 初步定义一组分析机制（如：持久性、安全性 等）

• 初步定义系统的分层与组织

• 定义要在当前迭代中要处理的某个用例实现

②选取在构架方面重要的用例，确定其分析类

③通过分析分析类的交互来更新用例实现

经典的三层构架：

①模型视图控制器构架M-V-C

• 模型M，相关的数据，它是对象的内在属性

• 视图V是模型的外在表现形式，一个模型可以对应一个或者多个视图，视图还具有与外界交互的功能

• 控制器C是模型与视图的联系纽带。

注意：模型的更新与修改将通过控制器通知视图，保持视图与模型的一致性

MVC备选构架示意图：

②分析阶段的备选分层构架B-C-E

• 以构造型<<layer>>表示系统不同层次

• 以B-C-E划分系统的三类处理逻辑

  • 边界层(Boundary)负责系统与参与者之间的交互
  • 控制层(Control)处理系统的控制逻辑
  • 实体层(Entity)管理系统使用的信息

• 层之间只建立简单的依赖关系

3.2、分析构架机制

构架机制是对通用问题的决策、方针和实践

• 构架机制描述了针对一个经常发生的问题（如，数据存储、安全性等）的一种通用解决方案

• 另外，作为系统构架的一部分，构架机制常常集中和定位在系统的非功能需求上

构架机制具有三类：

• 分析机制（概念层次）

• 设计机制（具体技术）

• 实现机制（如何实现的方法）

示例：

常见的分析机制：

• 持久性(Persistency)

• 遗留接口(Legacy Interface)

• 分布(Distribution)

• 安全性(Security)

• 事务管理(Transaction Management)

• 进程控制和同步(Process Control and Synchronization)

• 通信方式(Communication)

“旅游申请系统”分析机制示例：

3.3、关键架构抽象——概念模型

目的是用来理解需求，以便系统必须能够对其进行处理，其特征表现为：

• 来源于业务，体现了业务的核心价值，即业务需要处理哪些信息——搞清业务的本质性工作

• 这些信息所构成的实体即可作为初始的实体分析类

• 具体来源有需求描述、词汇表，特别是业务对象模型

• 通过一个或多个类图来展示关键抽象，并为其编写简要的规格说明（如：类、属性、操作、类之间的关系）

“旅游申请系统”中的关键抽象：

根据此关键抽象的定义可定义类与类之间的关系

四、构造用例实现

针对每一个用例实现，必须完成5个步骤：

• 完善用例文档

• 识别分析类，形成B-C-E架构

  • 定义边界类、控制类和实体类

• 分析交互

  • 通过交互图（如，顺序图）分析用例实现的细节

• 完成参与类(VOPC)类图

  • 参与用例实现的类的类图(定义属性与分配职责)

• 根据类的职责，完善用例间的关系

4.1、完善用例文档

需求阶段的用例文档是从用户角度看待用户问题，侧重描述交互事件的1(动作)、4步(响应)

分析阶段则需要从系统角度看待用户问题，重点关注交互的2、3步：即系统如何响应用户请求

要做到：细化处理步骤和流程

4.2、识别分析类

牢记：一个用例的全部行为（功能）都是由相应的类的操作来完成的，故这些行为必须被分配到相应的类中。识别规则：

• 分析阶段所定义的类被称为分析类，主要关注系统的核心功能需求，用来对问题域的对象进行建模

• 而构架分析中所定义的B-C-E三层备选架构为识别分析类提供很好的思路

构造用例准则：

• 限制类的职责
  • 每个类都仅有一个职责或目标
  • 每个类具有唯一的标识符
  • 类中的操作或方法都是为了完成这个职责而设立的
• 采用清楚一致的命名
  • 清晰的命名可以让其他开发人员和相关人员理解并验证分析模型的有效性
  • 可以捕获其中的误解和错误
  • 避免其发展到足以威胁项目成功的地步
  • 业务术语命名规范问题——参考实际业务
• 保持简单
  • 分析只是对高层次解决方案的第一次尝试
  • 没必要花太多的时间来使你的第一稿草案看起来很完美

什么是边界类？

边界类表示系统与参与者之间交互的边界

• 通过检查用例图中的参与者与用例之间的关系，识别出边界对象

• 识别原则：用例图中的每一对参与者/用例都会构成一个边界对象——即边界类

• 是接口和外部事物的中间体

• 构造型<<boundary>>

两类边界类：

• 用户界面类：系统与人的交互

• 系统和设备接口类：系统与其他系统或硬件的交互

示例：识别分界类

• 识别规则：每对参与者/用例定义一个边界类

什么是控制类？

控制类表示系统的控制逻辑(业务处理过程)。为其它类提供工作流和会话服务，如：

• 在边界类访问实体类时，控制类将一系列复杂的请求封装成通用的工作流，使访问变得简单

• 从边界类发出的任何消息将被转换成一系列从控制类发往实体类的消息

• 通常每个用例至少有一种控制类，也可能有多个

• 构造型<<control>>

示例：识别控制类

每个用例定义一个控制类

什么是实体类？

实体类是后续数据库设计的基础

• 使用构造型<<entity>>

• 可从以下内容中找到实体类：

  • 用例事件流(需求)
  • 业务模型(用例建模的用例规约文档(主语)、业务对象模型)
  • 词汇表(需求)

示例：候选实体类

确定分析类的过程：

• 识别分析类的过程就是对每个用例的实现。

• 即根据系统备选架构的约定，从用例模型中抽取出相应的B-C-E架构来填充系统架构

4.3、分析交互

面向对象系统是通过对象间的协作实现需求的

• 需求阶段通过自然语言描述

• 分析设计阶段则采用图形化方式描述协作过程，利用交互图将用例的行为(职责)分配给分析类

如何描述分析类——分析交互

描述对象间的交互，寻找对象行为

• 寻找对象行为（操作）的准则：

  • 确保操作自身的内聚性
  • 采用清楚明确的操作名
  • 完全满足用例要求
  • 保持简单

• 描述行为（操作）的步骤：

  • 将已识别的参与对象加到顺序图中
  • 从参与者开始，一步步寻找行为
  • 验证行为序列

顺序图与用例图和类图的关系：

如何利用顺序图进行职责分配？

• 以B-C-E的方式绘制顺序图，并以Control类将控制逻辑(处理过程)隐藏起来

• 可以将对象之间的信息传递以“//”的方式标记，表明初步进行类的职责分配

• 职责可以利用白话的方式将信息进行的说明，在信息长度不够时，可加上UML的注释来做说明

4.4、完成参与类(VOPC)类图

顺序图描述了用例中对象间的交互关系；而对象间的交互要用到类的方法以及类之间的关系

• 描述类的准则

  • 完整、保持简单、维持类的一致性

• 依照顺序图来描述类的步骤

  • 将对象的行为添加到类中
  • 重构类，使其符合类的定义规则
  • 发现类之间的关系

• 完成该用例“参与类类图”（VOPC, View of Participating Classes）

实例：旅游申请-绘制VOPC类图

五、定义分析类

如何定义？

从单个VOPC分析类入手，完成如下工作：

• 定义分析类的职责（操作、或方法）

• 定义分析类的属性

• 定义分析类的关系

  • 关联关系
  • 聚合关系
  • 泛化关系

• 限定分析机制

• 统一分析类

5.1、定义分析类的职责

职责即对象对外提供的行为——构造用例实现的过程实际上就是类的职责分配的过程。

如何获取类的职责？

• 从顺序图中设置的消息（“//”之后的内容——“分析”操作）得到

• 从非功能需求中得到

设计阶段最终演变为类的操作或方法

“分析”操作中的创建消息，没定义的原因：属于中间结果。与普通的消息直接由操作来响应不同，创建消息一般是通过类的构造函数来创建对象，调用也是通过一些特定的方式来实现的，因此这些与对象创建和删除等生命周期相关的操作在分析阶段一般不作考虑，也就不需要定义分析操作来表示。

利用文本方式描述职责：

可以利用一种“CRC卡”，以文本的方式来更好地、更直观地描述类的职责，其组成部分为：类(Class)、职责(Responsibility)、协作(Collaborator)

范例：申请类的CRC卡

5.2、定义分析类的属性

用来存储对象的数据信息——即数据元素，最小的数据集)

• 属性名是一个名词，可以利用文字详细说明属性中将要存储的相关信息

• 属性的类型主要来自业务领域，与具体编程语言无关，即先不考虑设计与实现

为分析类添加属性：（办理申请属性）

属性的定义主要针对实体类展开的

5.3、定义分析类的关系

实际业务中任何对象不能孤立地存在，它们之间需要频繁地通过消息(特定的关系)进行交互从而完成有用的工作，并达到用例的目标

特定的关系可表现为：

• 对象间的链接：对象间的语义联系

• 关联关系：协作关系

• 聚合关系：整体-部分

• 泛化关系：抽象-具体（一般-特殊）

对象间的链接——通过对象图：

对象图是显示系统某个时刻的对象及其关系的图

注意：可通过通信图来从对象链接的角度描述两个对象间的消息传递。

5.3.1、关联关系

关联是最常见的类与类之间的一种结构化关系，用来描述类之间的语义联系

• 表明类的对象之间存在着链接

• 对象是类的实例，而链接是关联的实例

识别关联的基本思路

• 从交互模型中发现对象之间的链接，从而在相应的类上建立关联关系。如：顺序图中的对象之间的协作关系、VOPC图中关联关系

• 从业务领域出发，分析领域中所存在的实体类之间的语义联系，为那些存在语义联系的类之间建立关联关系。

关联关系的分类：

关联可分为普通关联、递归关联、限定关联、或关联、有序关联、三元关联和聚合等七种

普通关联的表示方法

关联具有：名称、端点和角色名、多重性

• 名称：关联名，须用动词短语

• 端点和角色名：通过关联名可以表达关联关系的含义，端点名前加“+”表示该角色是公有的

• 多重性：* ，1.. *，1-40，5，3,5,8，…

自反关联：一个类自身之间存在的关联。表明一个类内不同对象之间存在链接

关联类：一种被附加到关联上的类，用来描述该关联自身所拥有的属性和行为

• 如：当某些属于关联自身的特征信息无法被附加到关联两端的类时，就需要为该关联定义关联类

5.3.2、聚合关系

聚合关系：一种特殊的关联关系

• 两个关联的类还分别代表“整体”或“部分”——即意味着整体包含部分

• UML图示：在整体方的直线末端加一个空心的小菱形

共享聚合：

• 聚合关系中如果处于部分方的对象同时参与了多个处于整体方对象的构成，则该聚合称为共享聚合。如，项目成员和团队之间的关联关系。

• 共享聚合关系的聚合重数为：n:n(多对多)

组合关系：

• 组合关系是聚合关系的复合聚合，由聚合演变而来。即：构成整体类的所有部分类完全隶属于整体类。（在整体端有一到多个实心的小菱形）

5.3.3、泛化关系

泛化是指类间的结构关系、亲子关系，即继承

• 子类继承父类所具有的属性、操作和关联关系

泛化关系主要来自业务对象模型。针对实体类，结合业务领域的实际需求，提取泛化关系主要有两种途径：

• 父类的提取：是否有类似的结构和行为的类，从而可以抽取出通用的结构和行为构成父类——归纳

• 子类的提取：将所有单个实体类的不同类别的结构和行为抽取出来单独构成不同的子类——演绎

泛化关系：

• UML中的泛化是通用元素和具体元素之间的一种分类关系。泛化可用于类、用例等模型元素。

• UML图示:父类方有一个带空心三角形的直线。

5.3.4、限定分析机制

为什么进行限定分析机制？

• 定义完分析类的职责、属性、关系后，分析类自身的功能已基本定义完成，但是缺少对非功能性需求的分析。

什么是分析机制？

• 用例实现主要关注系统的功能需求，而非功能需求也需要在分析模型中体现出来，这就是分析机制。

建立分析类和分析机制的对应表：

申请类的分析机制特性

5.3.5、统一分析类

业务的类体现了系统的静态结构，通过把所有用例实现的分析类图集成在一起可体现软件整体静态结构。

统一分析类的目的是：确保每个分析类表示一个单一的、明确定义的概念，而不会职责重叠或重复

具体实现：应从系统全局和实际业务出发，需要过滤分析类以确保创建最小数量的分析类。

ATM系统的分析类结果：

通过各个用例的VOPC图，删除那些没有引用或重复的实体类，即可得到由实体类组成的分析类图，这些是分析的关键