用例模型在线视频

同学们 今天我们讲一下面向对象的需求分析

我们首先介绍一下它的用例模型

在这节课中 我们描述一下需求分析的基本概念

以及它是如何影响到我们后面的分析与设计的

另外我们学习一下如何阅读和理解需求分析的结果

以及如何以需求分析的结果为起点开始进行面向对象的分析与设计

在这堂课中 我们介绍三个内容

首先 是对需求分析的概述

然后介绍一些它的基本概念 最后重点介绍用例模型

在RUP的软件开发过程中 我们可以看到

需求是分析设计之前的一个活动

需求的输出结果是我们分析设计的输入

我们的分析设计以需求结果为起点进行分析设计

而需求分析主要在RUP的初始阶段完成

通过需求分析我们定义我们需要开发的软件

以其为起点我们进行分析与设计

通过需求分析我们建立维护客户以及我们软件开发团队

比如项目经理架构师设计师等相关人员对我们所要开发的软件达成一致

另外通过需求分析来帮助我们的系统开发人员更好的理解我们所要开发的软件是什么样子

同时通过需求分析我们来定义和限制所要开发系统的范围

也就是说 什么的功能 哪些功能是我们软件系统所应该提供的

而哪些功能不是我们系统所应该实现的

基于需求分析 我们的项目经理来基于需求分析制定整个项目开发的计划

基于需求分析 我们来预估软件开发所需要的成本和开发周期等等

通过需求分析我们还可以定义我们用户的软件操作界面

也就是说我们通常所说的用户接口

在面向对象分析里面主要输出有三个

第一个是用例模型 用例模型主要描述整个软件系统的功能需求

第二个是术语表

术语表的定义是我们所开发的软件系统最基本最核心最重要的一些概念

最后一个是附加规格说明书

它描述了整个系统的性能 安全性 可靠性这样一些非功能性需求

下面我们介绍一下需求分析中的一些基本概念

最重要的一个基本概念就是系统行为

我们把系统行为定义成一个软件系统它可以做什么以及它对外部的事件或者信号如何进行响应

有些软件系统是主动的 它的行为就表现是它能够为用户提供什么样的服务

它能够执行什么样的动作能够做什么

也有一些软件系统是被动的

它接受外部的信号 外部的输入数据 外部的事件

然后根据外部的事件进行相应的处理

也就是说如何对外部的事件进行响应的

系统行为又有两个重要的特性

第一个是可见性 第二个是可测试

可见性就是确定系统的行为必须是从外部的用户外部的环境是能够观察到的

比如说系统对用户的请求进行处理之后它的输出结果展示给用户

这就是系统的一个行为

可测试要求系统在相同的环境下 相同的输入参数

系统会返回或者是输出一个相同的结果

比如说在相同的环境相同的输入参数下

第一次系统的输出结果是1 如果是第二次输出结果还是1

或者说每一次输出结果都是1 那么它就具有可测试性

反之第一次输出结果是1 第二次变成0

每次输出结果都不确定 那么就不具有可测试性

系统行为描述了系统的功能需求

在面向对象中我们对系统行为的捕获和描述采用的是用例

用用例模型来描述它

用例模型实际上描述了系统和它的外部环境之间的交互关系

也就是说系统和它的外部环境之间有什么样的输入有什么样的请求

系统又如何进行计算和处理 给外部环境做了什么样的输出或者响应

我们把这些都在用例模型中进行捕获和描述

在用例模型中有两个最重要最基本的元素

第一个是角色 第二个是用例

角色描述了和系统交互的任何事物

最常见最普通的角色就是软件系统的用户

例如说教学管理系统中它的角色有老师有学生有教务管理员

学生通过系统选课 注册课程 查看成绩等等

除了用户是它的角色以外

还有其他事物也是我们所开发软件系统的角色

例如说 对一个工业控制系统来讲

在工业现场往往有很多传感器

通过这些传感器捕获现场的温度压力等一些参数

把这些数据作为事件传送给工业控制系统

所以这些传感器对于我们工业控制系统软件来讲 也是系统角色

除了人和用户之外 和系统交互的硬件设备也可能是我们系统的角色

第三类角色就是其他的软件系统

比如在教学管理系统中学生选修的课程

最后我们根据学生选课需要的学分来计算他所要缴纳的学费

那么我们负责缴纳学费的计费系统就是我们教学管理系统的一个角色

和我们当前开发软件交互的其他的软件系统也可能是我们的角色

所以角色总体上可以分为三类

客户 硬件设备和其他的外部软件系统

第二个元素就是用例 用例描述了系统的行为

用例中具体描述系统是如何一步步执行动作最后向角色输出结果

用例捕获了系统的行为描述了系统特定的功能需求

下面我们介绍一下用例模型

在用例模型中 我们通过用例模型来描述系统的功能和行为

所以在用例模型中我们描述了系统的角色和用例

角色代表的是系统的外部环境 用例代表的是功能行为

也就是说在用例模型中我们描述了角色和角色相关的用例之间的关系

角色可以去执行触发相应的用例

比如这个例子中 我们的学生可以去执行登录系统

可以执行注册课程 可以执行查看成绩单这样一些用例

在用例模型中 我们如何阅读和理解用例模型

通过一个用例模型 我们首先可以识别出系统有哪些角色

例如教学管理系统中我们的角色有

学生 教师 课程目录 数据库 课程注册管理员还有计费系统等五个角色

另外可以识别出系统中有哪些用例

例如说有查看成绩单 注册课程 登录 选课以及提交课程成绩等等

总共有八个用例

另外在图中我们可以看到

哪些角色它所关联的或者说它所执行的用例又有哪些

以课程注册管理员为例

他可以执行的用例包括登录 维护教师信息 维护学生信息以及关闭注册

注册管理员在系统中需要执行的用例有四个

通过用例图我们可以很清晰的看到系统的角色 主要用例

以及角色和用例之间的关系

在这张图中我们还可以发现

有一些角色和用例关系之间是一个带箭头的

另外一些角色和用例之间是不带箭头的

这两种角色可以区分为主动角色和被动角色

主动角色例如注册管理员

带箭头就表示他可以主动的去触发执行相应的用例

而另外一些例如课程目录 数据库 计费系统和用例之间是没有箭头的

没有箭头表示用例在执行过程中 它可能向计费系统发出请求

也就是说这些角色并不是主动的去执行用例

而是用例在执行过程中需要和它进行交互 所以称之为被动角色

在用例图中我们定义了用例

每个用例有它的名称

但通过用例和用例名称并不能详细的描述系统的功能需求或者系统行为

所以在用例之外 我们需要对每一个用例给出它的具体描述

我们把它称之为用例规约

用例规约是对每一个用例的详细描述和说明

用例规约包含哪些内容呢

首先用例规约有它的名字

它的名称要和它所描述的用例的名称必须保持一致

其次要对用例有一个简要的概述

说明这个用例的行为 主要动作等等

在用例规约中最重要的是第三项 事件流

事件流描述了用例执行 被触发后

系统是如何一步步通过一系列的动作来完成这个用例

最后向用户输出结果的

第四项是关系 用例是有关系的

我们会在后期进行详细介绍

用例之间有泛化关系 包含关系 扩展关系

第五点是活动图 活动图与我们传统软件开发的流程图类似

我们采用活动图来描述事件流

我们之前采用文字描述事件流 第一步做什么 第二步做什么

但是有些用例的事件流非常复杂可能包含分支 循环 跳转

如果仅仅用文字描述可能很难理解很难描述清楚

这种情况下我们使用活动图来辅助说明事件流

再下来是用例图 这里指的不是整个系统的用例图

而是通过局部的用例图来说明当前用例和哪些角色哪些用例有关系

也就是说是一个局部的用例图 用来说明用例规约中的关系

再然后是特殊需求

特殊需求介绍了当前用例和与其相关的例如非功能性需求或者开发环境约束等等

比如说当前用例的安全性要求很高 比其他用例安全性都高

那么我们就在特殊需求中进行描述

还有两个我们称之为前置条件和后置条件

前置条件约束定义了当前用例在满足什么样的条件下可以被角色执行

或者说当前置条件不满足时 即使角色请求执行用例 系统也不会去执行

例如教学管理系统中

学生选课的前置条件是他已经成功登陆系统

如果他还没有登陆 那么选课这个用例就不应该被执行

后置条件意味着角色去请求执行用例

执行用例之后系统的状态应该满足符合后置条件

如果说执行完用例猴系统的状态不符合后置条件

那么这个执行是无效的

系统状态应该退回到用例执行之前的状态

最后还有一些其他的图 等等

这里是一个用例规约的事例

是一个最简单的登陆 它的用户名是登陆

它的简要描述是用户通过这个用例登陆到系统中去

下面是最核心的事件流 这里给出了两类

一类是基本流 它描述了用户在登陆界面中

通过输入用户名和密码进行验证成功登陆这样一个通常的主要的流程

还有一类是可选流 可选流则描述了异常情况下

例如用户输出的用户名和密码是错误的 系统是如何处理执行的

登陆用例没有特殊需求

它的前置条件是整个系统已经进入登陆界面

后置条件则定义了如果系统没有成功登陆

系统应该退回或者保持在登陆前的一个状态

在用例规约中 事件流是最重要的

每一个用例至少要有一个基本的事件流

基本事件流描述了这个用例或者系统在多数情况下的执行过程

它是如何一步步处理 一步步动作的

除了基本事件流 对每一个用例可能会有若干个可选事件流

可能没有 也可能会有一个两个甚至更多的可选流

可选流又分为三类

第一类是常规的变种

正常的事件流在某个条件下可能会有分支

比如说参数1时从这边走 参数2时从另一边走

参数1的情况下我们描述为基本流 参数2我们就描述为变种

还有些特殊情况

当用户的输入是特殊值时 事件是如何处理的

更常见的是异常流

当系统出错的情况下

系统输出不正确的参数 或者系统运行异常的情况下

系统是如何进行处理 如何进行响应的

这种就定义为异常流

所有的事件流不是独立的 我们观察下面这个图

中间的箭头表示的是基本流 两边的其他箭头则表示可选流

我们可以看到 可选流可以是基本流中分出来的

有可能循环回到基本流中去

也有可能运行后直接结束了

事件流很重要 下面我们介绍事件流描述定义的一些规则

在事件流描述中 首先我们要尽可能的对它进行详细的描述

因为事件流描述了系统的处理过程

后面的分析设计要基于事件流进行软件的分析与设计

第二点 事件流必须清楚的描述用例在什么情况下是如何被触发被执行的

以及运行到什么阶段结束的

要描述清楚用例的开始和结束

事件流还需要描述清楚系统的功能需求

当然不仅仅需要描述功能需求 还要描述相关的例如性能 安全性等其他需求

其次 在事件流中所有的事件都应该和当前用例相关

和当前用例不相关的其他用例的事件不应该定义在事件流中

事件流还需要定义清楚角色和系统之间的数据和信息交换

角色会向系统输入哪些数据信息

系统又会向角色输出哪些数据信息

事件流的描述代表了需求 所以要避免使用模糊用语

例如大概 可能 极大等等 这些词应该避免出现在事件流的描述中

下面我们介绍一个新的概念 剧情

剧情也称之为场景

剧情实际上是用例事件流的一个实例

将用例看成一个剧本

那么剧情就是请演员以这个剧本进行了一次表演

也就是说 剧情就是描述了用户对这个用例的一次执行过程

剧情是用例事件流的一个实例

同一个用例 不同的剧情执行过程可能是不一样的

如图所示 同一个用例 三种剧情执行过程是不一样的

有些用例太复杂 包含的事件流很多

有基本流有可选流 而且相互之间的交互关系也很复杂

通过定义剧情

可以帮助系统开发人员和用户去理解用例 理解事件流

同学们 我们今天有关用例模型的内容就介绍到这里

谢谢大家