软件系统分析与设计 | 用例模型

一、用例相关概念

1、什么是用例？

use case is a collection of related success and failure scenarios that describe an actor using a system to support a goal.

用例（use case），或使用案例、用况，是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。编写用例时要避免使用技术术语，而应该用最终用户或者领域专家的语言。用例一般是由软件开发者和最终用户共同创作的。

2、用例和场景的关系？什么是主场景或 happy path？

• 用例(use case)和场景(scenario)的关系：用例表示一组场景(a collection of scenarios)，场景属于用例的实例。
• 主场景(the primary scenario)或happy path：用例从触发事件开始，一步一步执行，最终满足用例利益的步骤集合；应该包含以下信息：
  • 两个执行者之间的交互。如，用户提交了订单。
  • 为保证主成功场景得以继续的确认。如，系统确认用户密码。
  • 主成功场景推进过程中的内部变化。如，系统扣除用户账户余额。

3、用例有哪些形式？

• Brief(high level): 一段简单的概要，通常是主要成功案例。主要在早期需求分析中，快速了解主题和范围，创作可能只需几分钟
• Casual(简便格式): 非正式格式，涵盖各种场景的多个段落，主要在早期需求分析中使用
• Fully: 所有的步骤和变化都写得很详细，并有支持部分，如前提条件和成功保证。主要在确定了许多用例并以简短格式编写后，详细编写了一些具有架构意义和高价值的用例

4、对于复杂业务，为什么编制完整用例非常难？

由于复杂业务的场景较多，场景较为复杂，无法完整考虑各步骤的前置条件和成功保证。在前期的考虑中，很难不遗漏一些业务条件和需求，且这些需求条件还可能发生变化。所以对于复杂业务，编制完整用例且不遗漏情景、良好地安排每个场景、场景内元素地关系非常困难。

5、什么是用例图？

用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。用例图（User Case）是外部用户（被称为参与者）所能观察到的系统功能的模型图。用例图是系统的蓝图。用例图呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。

6、用例图的基本符号与元素？

• 参与者(Actor) - 表示的是一个系统用户，也就是与应用程序进行交互的用户、组织或者外部系统
  
• 用例(Use Case) - 表示的是对系统提供的功能、服务的一种描述
  
• 用例之间的关系
  • 包含关系(Include) - 表示用例可以简单地包含其他用例所具有的行为，并把它所包含的用例行为作为自身行为的一部分。在UML中常用带箭头的虚线表示，箭头指向被包含的用例
    
  • 泛化关系(Generalization) - 泛化指的是一个父用例可以被特化形成多个子用例，而父用例和子用例之间的关系就是泛化关系。在UML中用空心三角箭头的实线表示，箭头指向父用例
    
  • 扩展/延伸关系(Extend) - 表示在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例，原有的用例叫做基础用例，相当于为基础用例提供一个附加功能。在UML中用带箭头的虚线表示，箭头指向基础用例
    
  • 关联关系(Association) - 表示的是参与者与用例之间的关系。在UML中常用一条直线，或者是一条带箭头的线条来表示，箭头指向信息接收方
    
• 子系统(Subsystem) — 用来展示系统的一部分功能，这部分功能联系紧密
  

7、用例图的画法与步骤

A、确定参与者，包括:

• 主要参与者：谁将使用系统的主要功能、谁将需要系统的支持以完成工作等
• 协作参与者：谁将提供对应的系统功能、谁将维护系统，保证系统处于工作状态等
• 幕后参与者：谁会对系统产生的结果感兴趣
• 根据用户需求识别和创作用例，主要重点在于：
  B、识别使用系统的主要参与者（primary actors）/角色(roles)
  C、识别系统依赖的外部系统
  D、识别用例（服务）
  E、识别用户级别用例（user goal level）
  F、识别子功能级别的用例（sub function level）
  G、建立 Actor 和 Use Cases 之间的关联。

8、用例图给利益相关人与开发者的价值有哪些？

A、对于利益相关人：

• 可以直观看到系统的结果和用户的功能体验，保证系统按照用户的需求进行设计。
• 用例能够根据需要对复杂程度和形式化程序进行增减调节，即能够响应用户（利益相关人)提出的需求，而用例图则使得这种调节更加便利，可以通过修改图形间的关系实现。

B、对于开发者来说：

• 用例图是设计者设计过程的结论与参考，设计者与开发者之间的交流工具，开发者开发过程的蓝图。
• 用例图使得开发者能够更明确地获得需求，更好地理解需求。
• 用例图可以指导开发和测试，同时可以在整个过程中对其他工作流起到指导作用。

二、绘制用例图

选择2-3个你熟悉的类似业务的在线服务系统（或移动 APP），如定旅馆（携程、去哪儿等）、定电影票、背单词APP等，分别绘制它们用例图。并满足以下要求：

1. 请使用用户的视角，描述用户目标或系统提供的服务
2. 粒度达到子用例级别，并用 include 和 exclude 关联它们
3. 请用色彩标注出你认为创新（区别于竞争对手的）用例或子用例
4. 尽可能识别外部系统和服务

• 订旅馆：
  
• 扇贝单词
  

A、为什么相似系统的用例图是相似的？

相似系统面对的参与者和用例是相似的，用例之间的关系也是同构的。用户预期的功能都是相似的，即不同的同类系统一定具有一致基本功能以及带有自己特色的扩展功能。所以体现在用例图上也是相似的。

B、如果是定旅馆业务，请对比 Asg_RH 用例图，简述如何利用不同时代、不同地区产品的用例图，展现、突出创新业务和技术

不同时代、不同地区用户习惯、需求法规以及其他社会环境的不同，使得技术和业务需求方面有所差距，这些差异会体现在用例图中，可以用不同的色彩标注他们来突出创新之处。

C、如何利用用例图定位创新思路（业务创新、或技术创新、或商业模式创新）在系统中的作用

用例图中的每个用例之间的关系都是明确的，我们可以对其中相对独立，即入度出度都比较小的用例进行创新，这样对系统整体的影响就不会很大。创新的角度可以是删去这个用例或者是给这个用例添加新功能。

D、请使用 SCRUM 方法，选择一个用例图，编制某定旅馆开发的需求（backlog）开发计划表

ID	Name	Imp	Est	How to demo
1	登录	5	3	人脸识别登录
2	查询酒店	7	10	通过位置、地图筛选，或直接通过酒店名查找酒店，同时可以做简单预测
3	预订酒店	5	14	选择酒店、挑选房间并进行预定
4	支付	7	14	提交订单，使用银行卡或者其他支付方式支付

E、根据任务4，参考使用用例点估算软件成本，给出项目用例点的估算。
根据用户点方法，对用例分配权重的标准是：

• 简单用例：1 到 3 个事务，权重=5
• 一般用例：4 到 7 个事务，权重=10
• 复杂用例：多于 7 个事务，权重=15

用例	事务	计算	UC权重
登陆	1	1	简单
查询酒店	3	3	一般
预订酒店	3	3	一般
支付	2	2	简单