软件工程4 用例建模

1、用例建模的概念

用例建模是一种需求分析方法，侧重于从用户的角度出发，将系统当做一个黑盒子，描述用户将如何使用系统，以此来梳理系统需求。相较于传统的结构化分析与设计方法，用例主张通过用户语言从“人”的视角对有价值的行为进行抽象，能够更全面的对问题域和系统价值进行分析，在需求描述上也更为收敛，一个上百种特性（计算机实现角度描述）的系统可能只有不到10个用例。

用例模型的组成部分包含参与者与用例，想要做好用例建模必须准确理解他们的含义：

一、用例的组成

参与者

1）参与者是系统之外直接与系统进行有意义交互的任何事物。

2）参与者是独立于系统的实体，是系统的触发者，需要直接参与系统的交互。如果我找某代理帮我在某平台办理购房手续，即使我是需求方和直接受益人，也不能算作平台的实际参与角色，仅仅是利益相关者（stakeholder）而已。

3）参与者是角色而非个人。角色与具体个人的区别在于“角色”是业务中的职能单位，而一个人可能承担多个角色。比如便利店的店员可能充当库存管理员和收银员两种角色参与业务；一个人的角色也可能发生转换，例如在游戏中的观战观众，如果加入对战就变成了玩家角色。

4）参与者不仅可以由人承担，还可以是其他系统、硬件设备，甚至是时钟。

• 其他系统：当你的系统需要与其他系统交互时，例如在淘宝购物下单时去请求卖家的上架管理系统的库存信息，商家管理系统就是一个参与者；

• 硬件设备：当系统需要与硬件设备交互时，硬件设备也可以作为系统参与者，例如高铁乘车需要在道闸刷身份证，道闸的读写器就是一个参与者；

• 定时器：当你的系统需要通过时钟确定某个时间来触发时，时钟就是一个参与者，例如系统在用户生日的零点准时推送祝福，就需要引入时钟作为参与者。

尽可能将角色细化，再合并和抽象，但要避免过度泛化。例如滴滴的专车司机、社会车辆司机经过细化再合并之后都是司机角色，但不能将司机和乘客都泛化为“用户”，这样不能恰当的表述各角色需求。

用例

1）用例是参与者在系统中进行的一系列有价值的操作。

2）用例是有步骤的，他是由一系列连贯的业务步骤组成的业务活动。

3）用例是有目标的，它能够为参与者带来有意义、有价值的结果，能给系统相关人清楚传达系统能提供的价值，而不是某个具体功能的操作。例如“输入身份证号”就不是用例，而“在线购票”则是。

4）用例是对一组实例的抽象（即场景），能够从使用者角度清晰描述与其互动的方式以观测系统实现全貌，包含基本事件流、扩展流、子事件流，比如购物时正常购物、填错地址改地址、拍多了取消订单...但从用例角度都抽象在“下单”用例中。一个场景是一个具体的行为，一个用例是对一类相关行为的抽象。

系统用例建模包含多个用例，需要通过完整文档组织整个业务的用例，通常放在PRD内。

二、用例的不足与误解

1）AI、算法、策略产品引擎及接口描述不适用。用例多用于描述需要大量交互产品，因为它本身就是强调参与者与系统交互的视角。

2）用例缺乏约束性，需要非功能需求补充。用例仅组织、描述功能需求，强调发起什么请求得到什么反馈，但在系统安全性、稳定性等方面需要通过非功能性需求描述作为补充。

关于用例的理解，很多人都误认为用例就是用例图，需要注意的是，用例是一种需求分析方法，用例图只是描述用例的一个部分，单从用例的表述层面来看，也还需要通过用例文档细化描述。

三、用例的表述方式

用例模型的表述包括两部分：用例图是目录，用例文档是封装所有需求的形式。

 

 

1）用例图

用例图中通常包含参与者、用例与系统边界。

参与者主要是系统使用角色，需要根据系统范围的边界确定是在系统内还是系统外，例如我们设计用户使用的电商购物软件时，就不会把供应商的库管员拉进系统角色中。绘制用例图时通常左边放置主要使用角色，右边是被动维护角色，具体绘制方法还需根据场景确定，能让读者清晰理解即可。

 

用例的定义与切分粒度需根据应用场景决定，通常方法是：

• 强调系统为参与者提供的完整价值，需要明确是从价值维度而非功能维度的描述，需要让看文档的使用人能便捷理解，即使是业务人员。

• 通过询问自己：用例是个完整可销售的服务吗？老板理解和认可单个用例价值吗？来判断对用例的定义是否到位。

• 用例的表述以主动的逻辑命名，动宾结构，体会一下：药品采购VS采购药品...

系统边界用于清楚分割和定义系统提供的价值范围。边界内的由系统提供，边界外则不提供。

2）用例文档

用例图目录绘制完成后，就是通过用例文档对用例进行更加详尽的描述，通常包含如下部分：

• 标题/作者/修改历史：定义文档、署名作者及记录变更信息

• 简要概述：描述基本含义和背景

• 利益相关者/涉众/参与人及其相关利益：除了用例参与人，为便于对用例价值和系统边界的理解可加入利益相关者的描述信息

• 事件流：基本流程/扩展流程/异常流程，描述如何通过交互传递用例承诺的价值，是严格流程化、规范化的“词牌名”，大致结构为：⽤例开始（⼊⼝） → {⽤户发起请求 → 系统校验请求 → 系统处理 → 系统反馈} → ⽤例结束

• 基本流：无分支，仅顺序、完整的描述成功路线。主语是用户，即使繁琐也要按步骤写，帮助自己切换视角，注意仅描述故事，与交互和界面元素无关，也没有技术实现。

• 扩展流程/异常流程：描述除基本流以外的分支流程。

• 辅助图例：如若通过文字描述不好理解用例，可增加其他辅助图例，如状态机等。

• 前置条件/后置条件：前置条件描述正确的起点，需要具备哪些条件才能开始用例；后置条件描述正确的结束，可能有多种，如取消订单和完成订单。

• 术语表：对重要或者难以理解的术语作出解释。

• 界面图例：通过界面辅助读者理解用例。

• 限制条件：用例可能在数量、金额、时间等方面的限制。

• 特殊需求：例如敏感词审核等其他用例交互外的诉求。

• 策略：通常描述时机和受，如广告消息推送，单独进行描述。

用例文档中具体描述的内容可按需裁剪，并非每项都需要覆盖，清楚达意即可。