第九章 用例建模

9.1 用例建模概念

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

 为什么需要⽤例建模——描述系统的功能性需求

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

⽤例模型的表⽰——⽂本描述

 ⽤例模型的表⽰——⽤例图

 ⽤例图的主要元素

参与者（Actor）

与系统交互的人或外部系统

用例（Use case）

系统为参与者提供的有价值的服务功能

关联（Association）

用例图中用例与参与者之间的交互关系

 

 什么是⽤例？

一个用例  定义系统的一系列行为 通过此可为参与者提供有价值且可观测的结果。

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

参与者的定义：关注⾓⾊

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

 交互——关联

• 参与者与用例之间的交互通道
• 用一条直线表示交互——关联
  • 有箭头的关联指出是谁发起的交互
  • 没有箭头则表明双方都可以发起交互

 箭头的使用习惯

 每⼀个交互——关联代表⼀个完整的对话

 

 9.2 用例建模过程

构建用例模型的步骤

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

1. 寻找参与者

•   谁/什么使用系统？
•   谁/什么从系统中获取信息？ 
•   谁/什么向系统提供信息？
•   公司的哪个部门会使用系统？
•   谁/什么负责系统的维护？  
•   还有哪些其他系统会使用系统？                                  

识别参与者——是谁与系统进行交互？

 参与者的描述

 参与者建模的检查项

• 是否找全所有的参与者？是否对系统环境中所有的角色进行了描 述和建模？
• 每个参与者是否至少与一个用例发生了交互？
• 是否可以为每一个角色找到至少两个实例？
• 不同参与者与系统的交互是否一致，扮演的角色是否相似？如果 有，则应该要合并这些参与者作为同一种角色

寻找用例

 识别用例

• 每个参与者的目标是什么？
  • 为什么参与者要使用这个系统？
  • 参与者是否需要对系统中数据进行创建，存储，更改，删除或 者读取的操作？为什么？
  • 参与者是否需要将外部事件或发生的改变告知系统？
  • 参与者是否需要知道系统内部发生的事件或改变？
• 系统是否能够应对业务中所有的正确行为与操作？

用例的描述

 用例的命名

• 表明参与者的目标或者作用
• 使用主动语态：用动词起始
• 设计一系列操作流程(to-do list)
• 几种表达：
  • Register for Courses
  • Registering for Courses
  • Acknowledge Registration
  • Course Registration

用例建模过程中的检查项

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

寻找用例的方法

• 和用户交互
• 基本策略：把自己当作actor，与设想中的系统进行交互。 考虑：
  • 系统交互的目的是什么？
  • 需要向系统输入什么信息？
  • 希望由系统进行什么处理并从它得到何种结果？

PS:确定Use Case和确定actor不能截然分开

用例建模的过程： 用例图 --》用例提纲 --》用例详细规约

用例的全生命周期

 用例简述的例子

• 用例简述:

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

• 处理购物交易:

        客户带着要购买的货物到收款处，收银员使用POS机扫描记录每一种预购 买的货物。系统计算总价并打印清单。客户付款，系统验证并保存销售记录。 系统更新库存，客户得到收条并带着货物离开。

    

 

用例文档模板

UC_id：用例名

描述：对该用例的一句或两句的描述。

参与者：参与该用例的参与者。

包含：该用例所包含的用例，以及包含它的用例。

扩展：该用例可以扩展的用例，以及扩展它的用例。

泛化：若该用例的子用例和父用例。

前置条件：启动此用例所必须具备的条件。

细节：该用例的细节。（基本流与可选流）

后置条件：在该用例结束时确保成立的条件。

例外：在该用例的执行的过程中可能引起的例外* 。

限制：在应用中可能出现的任何限制* 。

注释：提供可能对该用例是重要的任何附加信息。

总结：

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

9.3 细说用例

一、设定系统边界

• 系统边界：一个系统所包含的所有系统成分与系统以外各种事物的分界线
• 系统边界会对用例以及Actor的定义有所影响

 系统边界定义之一

 系统边界定义之二

 系统边界定义之三

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

• 功能分解：将问题分解为粒度小，独立的部分。
  • 不同的模块协同工作，体现系统的功能。
    • 通常，一些功能分解并没有实际的意义。Often do not make sense in isolation.
• 用例：
  • 不是功能分解的过程！
  • 综合所有功能一起描述系统如何使用。
  • 需要包含语境信息

 

 如何避免功能性分解？

问题现象

• 非常细小的用例
• 用例过多
• 没有实际价值的用例
• 通过底层操作进行命名
  • “操作”+“对象”
  • “功能” + “数据”
  • 例如：“插入卡片”
• 很难理解整体模型

修改思路：

• 寻找更大的应用场景    “为什么要构建这个系统？”
• 从一个用户的角度出发
  • “用户希望达到什么目的？”
  • “这个用例可以满足谁的目标？”
  • “这个用例的意义是什么？有什么价值？”
  • “这个用例背后的用户故事是什么？”

三、何时使用包含关系？

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

 四、何时使用扩展关系？

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

 五、用例图中的主要图标

 

9.4 用例工具介绍

系统建模⼯具的主要功能

• 可视化模型表达
  • UML模型
  • Web模型，例如Azure
  • 数据库模型，例如Power Designer
  • 用户自定义模型，例如Visio
• 画图工具

•  辅助开发流程中的项目管理

常⽤系统建模⼯具

 

 

 

 9.5 微信抢票应用案例

⽤户故事

 

⽤户故事⽰例

作为通过紫荆之声微信服务号参与活动的在校生，我希望可以对某个活动抢票

1. 已抢到票的活动参与者通过票务详细信息进入选座页面
2. 若活动时期仍然有效，系统给出可交互的活动座位平面图
3. 活动参与者选中任一座位，点击“提交”按钮
4. 系统弹出包含选中座位信息的确认对话框
5. 活动参与者点击“确认”按钮，若该座位可选，系统为活动参与者分配座位；若当前座位已经被选，系统会弹出“座位已被选”对话框并回到抢票页面

⼀、参与者列表

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

⼆ 、⽤例列表