第九章 用例建模

课程来源： 学堂在线 -- 清华大学 -- 软件工程

重点掌握概念和知识点：

• 掌握用例的粒度
• 使用UML建模工具绘制用例图，除EA外可以选择轻量在线建模工具ProcessOn
• 撰写简单用例文本

 9.1 用例建模概念

用例在需求管理过程中的作用

为什么需要用例建模 

用例建模 -- 描述系统的功能性需求

• 关联干系人需要以及软件需求
• 确认与系统交互的人或对象(参与者)
• 定义系统的边界
• 捕捉和传达系统的理想行为(用例)
• 验证或确认需求
• 规划工具

作用 

• 用例建模作为黑箱测试设计的参考
• 用例提供需求的上下文情境，将系统的需求用逻辑序列进行表述，解释说明为什么需要这个系统，确保与干系人的需求是一致的
• 规范化的表述形式让用例有较强的复用性，可以应用于文档撰写和系统设计、测试等各个过程

 用例模型的表示——文本描述

用例模型的表示——用例图 

举例  ATM机    联想需求

•  ATM涉及哪些业务
• ATM会与哪些系统或对象进行交互
• 不同对象、系统是如何和ATM进行交互的

用例图的主要元素

什么是用例

定义系统的一系列行为 

通过此可为参与者提供有价值且可观测的结果，可以确认系统是否达到了用户的预期

注意：用例定义的粒度要适中，过细的用例体现为用例无法为参与者提供足够的价值，需要与其他的用例合并，形成一个相对完整的流程，来达到参与者的目的；过粗的用例太过宽泛，可以根据不同角色用户的使用目的或使用方式将这个用例拆分细化

用例包含软件系统需求

• 定义一个参与者要用到的系统功能
• 描述系统为实现参与者价值所开展的行为序列
• 对参与者与系统之间的交互活动进行建模
• 从特定的用户角度出发，是完整的，实现特定用户价值的事件流

 参与者的定义：关注角色

•  与系统交互的人
• 与系统交互的硬件组件
• 或者其他的外部系统
• 关注的重点是所承担的“角色”
• 参与者的名要明确定义其角色

* 在命名中要体现角色的特性

将用户角色和用户实例进行区分 

交互——关联（Association）

 

箭头的使用约束

1.  若图中标明了箭头的相应信息，也应该在用例文本描述中有所体现，标志在何种情况下进入用例
2. 箭头表示并不是必须的，仅当需求中有明确的定义时才进行使用
3. 有两个或两个以上的箭头指向了同一个用例是一种异常的表示
4. 箭头的方向只表示消息的传递方向而不表示哪个参与者创建用例，或者是用例服务的受益方

场景(Scenario)是⽤用例的实例 

一个用例会有不同的场景，也就意味着有不同的事件流，需要将不同的场景分别进行描述

场景可以表达正面的行为需求也可以表达反面的、不希望发生的交互，还可以包括并行机制 

 

9.2 用例建模过程

• 第一步：找到所有的参与者和用例
  • 识别出参与者并做简单的描述
  • 识别出用例并做简单的介绍
• 第二步：编写用例
  • 列出用例
  • 给用例事件流程划分重要等级
  • 按照重要程度排序详细描述事件流程 

构建用例模型的步骤(一) 

参与者的描述

参与者建模的检查项

• 是否找全参与者？否对系统环境中所有的角色进行了描述和建模？

• 每个参与者是否至少与一个用例发生了交互？

• 是否可以为每一个角色找到至少两个实例？

• 不同参与者与系统的交互是否一致，扮演的角色是否相似？如果有，则应该要合并这些参与者作为同一种角色

寻找用例

 

用例描述

 

用例的命名

• 表明参与者的目标或者作用
• 使用主动语态：用动词起始
• 设计一系列操作流程(to-do list)

用例建模过程中的检查项

• 用例建模是为了表示系统的行为。通过模型可以很容易理解系统进行的操作 
• 应该识别出所有的用例，用来表达所有的需求
• 系统的任何一个特性都可以找到对应的用例
• 用例模型并不包含多余的行为；所有的用例可以追溯到系统的功能性需求作为验证
• 去掉所有的CRUD类的用例
  • 创建(Create), 查找(Retrieve), 更新(Update), 删除(Delete)

构建用例模型的步骤(二) 

寻找用例的方法

• 和用户交互
• 基本策略：把自己当作actor，与设想中的系统进行交互

考虑：

• 系统交互的目的是什么？
• 需要向系统输入什么信息？
• 希望由系统进行什么处理并从它得到何种结果？ 

注意： 确定Use Case和确定actor不能截然分开

用例建模的过程

用例图 -> 用例提纲 -> 用例详细规约 

 用例的全生命周期

用例简述和用例概述

用例简述：一段简洁的摘要，主要描述用例的成功场景

用例概述：

• 非正式、随意的格式
• 非正式段落，覆盖各种场景

详细用例规约的例子 

 

用例文档模板

 

总结：Use Case模型的建立步骤 

1. 找出系统外部的参与者和外部系统，确定系统的边界和范围
2. 确定每一个参与者所期望的系统行为
3. 把这些系统行为命名为Use Case
4. 使用泛化、包含、扩展等关系处理系统行为的公共或变更部分
5. 编制每一个Use Case的脚本
6. 绘制Use Case图
7. 区分主事件流和异常情况的事件流，可以把表示异常情况的事件流作为单 独的Use Case处理
8. 细化Use Case图，解决Use Case间的重复与冲突问题 

9.3 用例建模精讲

一、设定系统边界

系统边界：一个系统所包含的所有系统成分与系统以外各种事物的分界线

系统边界会对用例以及Actor的定义有所影响

系统边界定义之一

 

系统边界定义之二 

 

系统边界定义之三 

 

二、不要把用例定义成功能分解 

功能分解 ：将问题分解为粒度小，独立的部分

不同的模块协同工作，体现系统的功能。通常，一些功能分解并没有实际的意义。

用例：

• 不是功能分解的过程！
• 综合所有功能一起描述系统如何使用
• 需要包含语境信息

事例

 错误用例

 走出功能分解：正确的用例建模

 

如何避免功能性分解

三、何时使用包含关系？ 

• 当多个用例有共享行为时，使用包含关系
• 为共享行为单独创建用例，被相关用例“包含” 

四、何时使用扩展关系？ 

• 一个用例与另外一个用例近似，只有少许额外的活动
• 将代表普遍或基本行为的情况定义为一个用例
• 将特殊的、例外的部分定义为扩展用例 

 

五、用例图中的主要图标 

 

9.4 建模工具介绍

系统建模工具的主要功能 

 可视化模型表达

• UML模型
• Web模型，例如Azure
• 数据库模型，例如Power Designer
• 用户自定义模型，例如Visio

 

常用系统建模工具 

  

资源链接：http://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools 

资源链接：List of Requirements Management Tools | The Making of Software 

UML 2.0

 

资源链接：IBM Developer 

 

 

资源链接：http://www.softwarechn.com/SparxSystems/sparxsystems_index.htm 

EA工具介绍 

 

9.5 微信抢票案例

用户故事 

 

一、参与者列表 

• 活动参与者：通过系统进行抢票的用户
• 活动组织者：通过系统发布活动信息的用户
• 后台管理员：通过系统管理用户权限的用户
• 微信平台：提供用户身份绑定的部分信息，提供活动发布的平台
• 系统时钟：推广活动时需要时钟调度 

二、用例列表 

 

用例模型：方案⼀ 

 

EA建模：用例概要简述 

 

EA建模：创建用例建模工程 

 

EA建模：参与者 

 

EA建模：用例