用例分析概述在线视频

同学们

今天我们讲面向对象与分析设计的第十三课——用例分析（一）

在这一节课里面

我们描述了什么是用例分析

在RUP（统一软件开发过程）的哪一个阶段去执行它

如何来识别分析类

如何来定义分析类之间的协作

来实现用例的行为

也就是 我们在用例规约里面定义的事件流

最后呢 如何来开发一个用例实现

来描述用例

它是如何由这些分析类即它们的协作关系来实现的

用例分析是在设计阶段

由行为分析这个活动来执行

是由设计师来做的 我们可以看到呢

用例分析这个活动是在架构分析之后来执行的

整个用例分析它分析的对象是用例

所以用例模型是用例分析的主要的输入

除此以外

其他的需求成果 附加规格说明书 术语表

也是用例分析的一个输入

另外 用例分析活动需要在项目规范以及

软件体系架构的约束之下进行

所以 项目规范 规约指南和软件体系架构文档

也是它的输入

那么用例分析的输出结果首先识别分析类

其次是把所识别出来的分析类

定义它们之间的关系

我们把它称之为分析模型

最后呢还要描述这些分析类

是如何相互协作来实现用例功能的

也就是说我们要定义用例实现

所以分析类 分析模型和用例实现是我们整个用例分析的输出

在用例分析的步骤呢主要包括这么几个

首先第一步要补充用例描述

然后呢对每个用例定义它的用例实现

首先呢通过对用例行为的分析

也就是事件流的分析

识别相应的分析类

然后呢我们把用例的行为再分配给这些分析类

对于最后识别出来的每一个分析类

我们要描述它的职责 属性 关联关系

要定义它的分析机制

我们的用例分析是迭代的 多次执行完成的

所以每一次迭代后

要把所识别出新的分析类和之前的分析模型进行合并

最后进行检查

那么 第一步呢我们刚才讲

是补充用例的描述 在需求阶段呢

我们对每一个用例在用例规约里边

在事件流里边 已经描述了这个用例的行为

但这种描述呢有时候 可能不够具体

不够完整 使得这种描述呢

没有办法有效的支撑进一步的用例分析

所以在这种情况下

我们首先对我们需求阶段所描述的这种用例的事件流

或者用例的描述进行补充 描述它的细节

我们这里举了个例子

这个例子里面我们说系统展示课程列表

但是系统并没有讲

这个课程列表是从哪里提取出来的

所以补充以后呢我们就讲

这些课程列表信息我们需要从课程目录遗留数据库里面来获取

那么到了第二步

我们就是要从用例的行为里边要识别它的分析类

什么是类呢 我们讲类是对象的抽象

对一个类来讲

它描述了这些对象的公共的属性 行为 关系和语义

每个类有它的名称 属性和操作

那么通过用例分析我们把用例来识别出实现这个用例的这些分析类

分析类之间的协作关系

我们把这些统一起来

我们把它称之为 定义为用例实现

比如说用例实现包含了实现该用例的类图

以及类的对象之间的协作

通过时序图或者通讯图来描述

合在一起就构成了这个用例的实现

所以在用例分析的第一步

我们需要从用例的行为

来找出或者说识别出所需要的分析类

如何来找出来

这里我们采用一种方法

比如说根据用例行为的特点

我们把它分配给对应的不同的这个分析类

那么什么是分析类呢

所谓的分析类就是

我们在分析阶段我们来描述用软件

比如说用类的概念来描述软件系统

是如何来实现用例所描述的系统行为

一般情况下我们把分析类可以划分为三类

第一类 是用来存储系统信息的 我们把它称之为实体类

你比如说我们在教学管理系统里边

我们需要存储学生的信息 教师的信息

那么学生类 教师类 就可以看成一个实体类

第二个是用来控制组织业务流程的

我们把它称之为控制类

最后一个是用来跟用户进行交互的

我们把它称之为边界类

所以 整个分析类呢

可以划分为这三类 边界类负责交互

控制类 负责组织业务流程

实体类呢用来存储和管理信息

下面呢 我们首先来看边界类

我们说边界类描述系统和它外部环境之间的接口

根据外部环境的不同

边界内我们又把它细分为三类

第一类是和用户进行软件的用户直接交互的

我们把它称之为用户接口类

第二类呢 我们说系统的角色可能是外部的另外一个软件系统

所以把这种的边界类称为系统接口类

第三类呢 和外部的交互可能是一个硬件设备

所以我们把这一类边界被称之为设备接口类

对于边界类的描述

在Rational rose里面它给出了这样一个定义的符号

我们要注意

这不是标准的uml的一个符号

是Rational rose自己扩展出来的

那么边界类的职责呢

就是负责完成系统和系统外部的

这些角色之间的交互

换句话讲 边界类呢就是接收外部的这些角色的请求

或者信息输入 然后呢

把这个输出结果再展示给外部的这些角色

所以边界类描述了系统和外部角色之间的交互过程

那么我们如何来定义边界类呢

需要定多少个边界类呢

一般情况下在用例模型里面

每一个角色 用例对

也就是说角色和用例之间的这样一个线 一个箭头

我们可以给它定义对应的一个边界类

比如在这个例子里边

我们可以看到有一个用例有两个角色

总共有两个角色 就是有两个箭头

或者说有两个角色用例对

所以我们就对应分别定义了两个边界类

在边界类里边呢 我们讲第一类呢

是用户接口边界类

就是用户接口类 用户接口类呢

用户接口类呢

它描述了用户和系统之间的交互过程

在分析阶段

我们只需要关注用户和系统间执行了哪些操作

或者说哪些交互就可以了

我们不需要关注用户的界面是如何来设计的

比如说他是用的对话框是用的radiobox， checkbox

这些用户界面的设计细节

我们在分析阶段都是不考虑的

这些都留在设计阶段再详细考虑

在分析阶段我们只需要定义用户通过这个接口类

我向系统输入了哪些信息

或者说执行了哪些操作就可以了

同样的对于系统接口类和设备接口类来讲

我们在分析阶段只需要描述外部的系统或者外部的设备

和我们软件系统之间采用了什么样的协议就可以了

至于说协议是如何来实现的

我们同样要等到设计阶段再考虑

也就换句话来讲 在分析阶段

我们主要聚集在分析类的职责

而不是它的细节 或者说它是如何来被实现的

那么第二个分析类呢

我们要介绍下实体类

我们说实体类呢

它定义了系统要存储和管理的信息

实体类呢 它往往代表系统里边的一个关键概念

或者说 系统里边一些重要的基本概念

我们都可以把它定义成实体类

所以说从哪里来找到实体类呢

可以从以下几个方面

第一个呢 从用例的用例规约里边

在用例规约里边经常出现的

一些频繁出现的一些名词都可以

或者说有可能就是我们需要定义的实体类

第二类呢

如果这个系统做了领域分析或者说业务模型分析

我们可以从它的领域模型里边

也可以找到 或者说识别定义我们所需要的实体类

第三个呢 就是我们的术语表

在术语表里面我们定义系统里面的一些基本概念 那么这些概念呢

很有可能也是我们需要定义的实体类

最后一个呢 就是我们在架构分析阶段

我们初始定义的这个初始架构模型里边

那也可能包含有需要识别或者定义的实体类

实体类的作用是什么呢

实体类的作用就是用来存储管理我们系统里边所需要的信息

下面呢 我们说明一下如何来提取那个实体类 定义实体类

我们常用的办法呢 就是从用例规约的事件流描述里边来找它

我们采用的办法叫名词排除法

我们把用例的事件流做为一个输入

然后呢

从用例事件流之中找到一系列关键的概念

然后我们过滤掉一些不是实体类的对象

把这些不是实体类的名字过滤掉

然后剩余的 其余的 我们可以把它定义成实体类

那么主要过滤掉哪些呢

那么我们如何来做呢

第一步 我们在事件流里边把所有的名词下边画线

然后呢 我们把这个重复的 或者冗余的这些名词先去掉

还有一些名词可能是是模糊的 描述不清楚的

它的含义不清楚 不清晰把它去掉

另外的话有一些虽然是名词

它代表的是系统交互的外部角色 用户 把它去掉

再有一些呢 在事件流里边可能还会描述到一些实现约束

比如说实现约束里边出现的像数据库了

这样一些 这些呢 也把它去掉

还有一些名词呢

不能独立定义成一个类 它可能是把某个类里边的一个属性

比如说教师的这个教师的工号

那么工号呢 是一个属性

它不能独立定义成一个类也要去掉

还有一些呢操作 就是一些名动词的一些操作

把这些都去掉 那么剩余的呢

就应该是 或者说很有可能是我们所需要定义的一个实体类

我们把这种方法呢 叫做名词过滤法

好的 同学们 今天呢

我们讲了一下这个用例分析

他的活动在RUP里边的哪个阶段来执行

它的输入 它的输出

然后我们介绍了用例分析的第一步

要补充附加规格说明书

那么第二步呢 要找到分析类

我们说分析类呢有三种

控制类 实体类和边界类

然后呢 接着我们详细的介绍了一下边界类和实体类

在下一节里边我们将继续介绍控制类 谢谢大家

谢谢大家