讲课视频在线视频

接下来我们来探索

用例建模的完整过程

用例建模包含两个步骤

第一步

找到参与者和用例

利用客户的需求和系统的

潜在使用者信息

来寻找用例和参与者

第二步是编写用例

补充用例的事件流

我们来分步骤看

首先寻找参与者

我们可以通过一些问题

进行辅助

例如

是谁或者是什么在使用系统

理解系统的设计目的

服务于哪些人或者物

根据不同的用户类型

表示为不同的参与者

系统外部与系统进行交换的人

或者物也应该设计为参与者

它们用来传输消息或者接受消息

同时我们还需要思考的问题有

是公司的哪个部门

会使用这个系统

谁负责系统的维护

还有哪些系统会使用当前的系统

通过这些问题

可以帮助我们抽取使用者的角色

找到潜在的参与者之后

我们需要进一步识别参与者

我们通过一个非常简单的问题

来识别

这个问题就是

是谁真正与系统发生交互

我们来看一个例子

在最开始的时候

学生是不能直接操作

中心选课系统的

我们是通过教务人员

根据学生的需要操作选课系统

进行相入课程的录入

随后产生了在线选课系统

在这个时候

学生是可以

直接与在线系统进行交互的

所以 在中心选课系统中

学生并不是参与者

而在在线选课系统中

学生是参与者之一

确认了参与者之后

则需要在用例文档描述中

对参与者信息细化

参与者定义时

考虑的是用户的身份

因此参与者的名称

应该要明确指明

参与者 与系统交互时的身份

同时要注意参与者的命名

该要唯一

可以与其他参与者进行区分

一个命名为用户的参与者

是非常 不恰当的

因为这个名字

很难了解用户真正的身份

随后要对参与者进行简要的描述

具体的内容包括

这个参与者代表了哪些用户

为什么会需要这个参与者

参与者对于系统的需求

具体的是什么

这里就体现了

参与者和用例之间的关系

这里再向大家额外介绍一种

特殊的参与者

在一些系统中

用例通常是在特定的时间被触发

例如月底 每天零时等

这里我们可以抽相出一类

特殊的参与者

可以将其命名为调度器或者时钟

相比较而言使用调度器

作为参与者的名称更好

因为这个可以是人

或者非人为的控制器

而时钟则更像是

设计模型中的一个具体对象

最后我们可以根据下述的标准去

判断对于参与者的建模是否合理

首先我们要看

是否找全了所有的参与者

是否对系统环境中所有的角色

都进行了描述和建模

每一个参与者

是否至少都和系统中的一个用例

发生了交互

我们是否可以为每一个角色找到

至少两个应用实例

不同参与者

与系统的交互是否一致

扮演的角色是否相似

如果有这样的情形出现

则需要考虑将这些参与者

合并为同一种角色

在寻找参与者的同时

要描述系统为参与者提供的服务

以至参与者如何与系统交互

这个就是寻找用例的过程

最好的方式

就是把自己也当作参与者

与设想中的系统进行交互

在寻找用例时需要注意的问题是

不要一开始就尝试

去捕捉所有的细节

我们要全面的认识和定义

每一个用例

要点是与穷举的方式去考虑

每个参与者与系统的交互情况

我们要注意

寻找用例和寻找参与者的过程

是不能完全分开的

我们可以通过下述的问题

来辅助 寻找和识别用例的过程

每个参与者的目标是什么

我们为什么需要这个系统

参与者是否需要对系统中的

数据进行创建

存储更改删除或者读取

参与者是否需要将外部事件

或者 发生的改变告知系统

参与者是否需要知道

系统内部发生的事件或改变

同时我们不要忘记系统的启动

中止或维护等这些用例

调度器根据时间触发的用例等

在设计过程中也要避免

用例力度过细或过粗的现象

一些简单的辨别规则

已经在用例建模概念中

进行了介绍

大家可以参考这些规则进行检查

确定了用例之后

我们需要对其进行文本描述

用例的名称应该是唯一的

清楚地表达了参与者与系统交互

的目标

所以我们要注意使用

动宾结构作为名称

用例的简要描述中

介绍了参与者和系统如何交互

系统需要进行哪些原子操作等

在敏捷开发的过程中

每一次迭代可以选择部分用例

进行细化描述

通过这样的方式

设置用例的优先级可以保证重要

的功能尽快完成交付

最后需要建立

参与者与用例之间的关联关系

对于用例的命名

我们需要再次强调

用例的命名

该表明了参与者的目标或者作用

应该使用主动的语态

而且是一个动宾结构

这个用例背后

应该包含设计一系列操作流程

基于命名规范请大家分析

下述的表达形式有什么问题

有这样几种表达形式

哪种形式可以表现出

参与者的意义或价值

哪些不可以 如果是你你会选择

哪一个作为你的用例名称

以及说一下你的原因

有这样一种默认的判别规则

来判别用例命名是否合适

那就是将主参与者的名称

与应用的名称连成句子

去看是否有实际的意义

完成了用例的定义之后

我们可以通过下述规则

来验证用例模型是否完善

首先用例建模

是为了表示系统的行为

所以我们可以通过用例模型

很好地理解系统的相关操作

用例模型中应该标识所有的用例

来表达客户所有的需求

系统的任何一个特性

都应该找到相对应的用例

用例模型并不包含多余的行为

所有的用例

都可以追溯到系统的功能性需求

与作为验证

在设计用例的时候很多人会加上

创建查找更新删除等一类的用例

我们简称其为CRUD类的用例

对于这一类的用例

我们可以用一个更通用的用例

来概括

比如说我们可以将

增加顾客 删除顾客

更新顾客信息和查看顾客信息

这几个用例合并为一个用例

叫做维护顾客信息

构建模型的第二步

就是要为每一个用例

进行具体的文档描述

具体包括给用例事件流程

划分重要等级

按照重要程度

排序详细描述事件流程

在第一步寻找用例

和参与者的过程中

我们已经对用例进行了简要描述

那么在第二部中

编写用例的过程

就是将上一步所得到的简单描述

进行扩展 形成用例提纲

用例提纲涵盖了大致的事件流程

随后我们将其细化

增加条件说明等

形成更加详细的规约

后面我们将通过下订单这个用例

帮助大家理解用例描述

是如何进行细化的

用例建模的过程是逐步扩充的

迭代细化的

首先我们通过分析需求

识别到用例 例如下订单

进一步我们需要简要描述

这个用例的意义

这里列出下订单的简要描述

大概用两到三句话描述清楚即可

通过这个简述的内容

我们把基础事件流抽取出来

形成用例提纲

通过提纲可以大致了解

用例的规模和复杂程度

我们通过将事件流中的选择条件

约束等进一步细化

增加前置后置条件

完成用例详细规约描述

这个细化过程

往往是配合开发过程迭代进行的

所以需要考虑需求的优先程度

我们来看一下

下订单这个用例的简述表示形式

对于用例简述

我们只需要用简练的语言

表达清楚用例的意图即可

这里需要涵盖事件流的主要部分

我们看一下这个简单的描述

在用例概述中

我们将主体事件流抽出

这个时候需要兼顾不同的场景

例如在下订单这个用例中

主要的成功场景

有如下的7个环节

但是有一些特殊情景

也需要在设计系统时进行考虑

例如候选场景之一描述的

客户付款可能会失败

这个时候就要求客户

使用其它的付款方式进行付款

第二个候选场景就是

系统有可能与POS系统通讯失败

这个时候则需要通知用户

系统故障不能进行进一步的操作

这里只是给出了两种候选场景

在实际的应用中

远不止这两种场景

所以我们在设计系统的时候

也需要对每一个场景进行完善

我们将购物系统中下订单

用例的详细用例规约进行介绍

首先应该包含用例的名称

叫做下订单

它的前置条件是有一个用户

通过身份认证登录了系统

随后给出事件流的描述

在起始的时候我们需要标明

在何种条件下会进入到这个用例

如果出现了一场

或者其他的分支条件

我们需要在后面的步骤中

进行说明

在规约的最后我们应该记录

用例结束后系统的状态

在这个用例中最后的后置条件是

系统保存订单信息

并且标志为已确认

这个是一个用例文档模版

包含了一个用例规约的全部内容

大家可以根据具体的系统需要

参照这个模版

撰写相应的用例文档描述

最后我们将用例建模的步骤

总结如下

首先找出系统外部的参与者

和外部系统

确定系统的边界和范围

确定每一个参与者

所期待的系统的行为

我们把这些系统的行为

命名为Use Case

也就是用例

我们通过泛化包含扩展等关系

处理系统行为的公共

或者变更的部分

我们为每一个用例编制脚本

绘制相应的用例图 区分

主事件流和异常情况的事件流

可以把表示异常情况的事件流

作为单独的用例进行处理

最后我们把用例图进行细化

解决用例之间

可能存在的重复和冲突的问题