用例建模 - 绘制用例图

1.简答题

1.用例的概念

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

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

场景是actors和系统之间一系列特定的actions和会话，又被称为用例实例（use case instance）。一个用例代表了一些场景的集合。

主场景对应主要的系统会话（交互），一般是“成功的”场景，是最常用、直接地实现用户目标的场景。

happy path是一个默认场景，没有异常或错误条件。比如验证信用卡号的happy path是，验证规则中没有一条会引发错误，从而使执行成功地持续到最后。

3.用例有哪些形式？

Brief

简短的一段总结，通常是针对主要的成功场景。是为了在早期的需求分析过程中，快速了解主题和范围，可能只需要几分钟就可以创建。
Causal

非正式的段落格式。涵盖多种场景的多个段落。
Fully

所有的步骤和变化都写得很详细，并且有补充部分，如前置条件和成功保证。在以简短的格式识别和编写了许多用例之后，在第一个需求研讨会期间有少量的具有结构重要性和高价值的用例被详细地编写。

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

因为复杂业务所涉及的场景非常多，较为复杂，场景之间的关联使得用例设计变得十分困难。要编写完整用例，需要非常熟悉这些场景，还需要建模知识，注意与用户交互的各种细节，并且还要应对实际中需求发生变化的情况，所以非常难。

5.什么是用例图？

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

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

参与者（Actor）：表示的是一个系统用户，也就是与应用程序进行交互的用户、组织或者外部系统。
用例（Use Case）：表示的是对系统提供的功能、服务的一种描述。
用例之间的关系：

包含(Include)：表示用例可以简单地包含其他用例所具有的行为，并把它所包含的用例行为作为自身行为的一部分。在UML中常用带箭头的虚线表示，箭头指向被包含的用例。

泛化(Generalization)：泛化指的是一个父用例可以被特化形成多个子用例，而父用例和子用例之间的关系就是泛化关系。在UML中用空心三角箭头的实线表示，箭头指向父用例。

关联(Association)：表示的是参与者与用例之间的关系。在UML中常用一条直线，或者是一条带箭头的线条来表示，箭头指向信息接收方。

扩展/延伸(Extend)：表示在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例，原有的用例叫做基础用例，相当于为基础用例提供一个附加功能。在UML中用带箭头的虚线表示，箭头指向基础用例。

7.用例图的画法与步骤

确定研讨的系统
- 使用用例图 System框表示一个待研究的系统
- 正确命名系统或子系统
识别 Actors
- 识别使用系统的主要参与者（primary actors）/角色(roles)
  - 使用用例图 actor符号表示，通常放在系统的左边
  - 企业应用可以通过企业组织架构，业务角色与职责识别
  - 互联网应用则必须通过市场分析，确定受众范围
  - 千万不要用“用户”代表系统使用者，以避免过于通用导致缺乏用户体验。
- 识别系统依赖的外部系统
  - 使用用例图 Neighboursystem框表示用例依赖的外部系统、服务、设备，并使用构造型（Stereotype）识别
  - 要将一些专业功能赋予专业系统
识别用例（服务）
- 识别用户级别用例（user goal level）
  - 以主要参与者目标驱动
  - 收集主要参与者的业务事件
  - 必须满足以下准则
    - boss test
    - EBP test
    - Size Test
  - manage 用例。特指管理一些事物的 CRUD 操作，例如管理文件、管理用户等
- 识别子功能级别的用例（sub function level）
  - 子用例特征
    - 业务复用。
    - 复杂业务分解。
    - 强调技术或业务创新。
  - 正确使用用例与子用例之间的关系
    - <> 表示子用例是父用例的一部分，通常强调离开这个特性，父用例无法达成目标或失去意义！
    - <> 表示子用例是父用例的可选场景或技术特征。
    - <> 箭头指向子用例；<> 箭头指向父用例。箭头表示的依赖关系！
建立 Actor 和 Use Cases 之间的关联
- 请使用 无方向连线，表示两间之间是双向交互的协议

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

对利益相关人：
- 可以直观看清系统的结果以及用户的功能体验，提供了系统使用和行为的摘要视图，保证系统能够按照用户的需求进行设计，并且便于与利益相关人进行沟通，及时对系统功能进一步完善。
- 能够根据业务场景的复杂程度和形式化程序进行增减调节，能够相应利益相关人提出的需求。通过用例图进行系统功能的增减以及修改更加便利。
- 使得系统能够注重其参与者的用户体验。
对开发者：
- 明确系统的业务范围、服务对象（角色）、外部系统与设备
- 帮助识别技术风险，提前实施关键技术原型公关与学习
- 易于评估项目工作量，合理规划迭代周期，规划人力需要

2.建模练习题（用例模型）

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

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

携程酒店：

猫眼电影：

2.2回答下列问题：

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

因为相似系统面向的Actor是相似的，从Actor视角定义的用例也是相似的，连同用例之间的关系都是相似的。这本质是因为相似系统的功能需求是相似的。
如果是定旅馆业务，请对比 Asg_RH 用例图，简述如何利用不同时代、不同地区产品的用例图，展现、突出创新业务和技术

不同时代用户的需求不同，Asg_RH用例图主要满足的是用户基本需求，如今的产品则综合考虑了更多功能，更加人性化。不同地区的旅馆在服务、价格、交通方面都会有较大的差别，可以在用例图中突出这些方面的重要性。
如何利用用例图定位创新思路（业务创新、或技术创新、或商业模式创新）在系统中的作用

使用不同的颜色来标记创新思路可以快速定位其在用例图中的位置，利用创新思路在用例图中的位置可以看出它在系统中的作用。如果把用例图看成一棵树，则位于越靠近根的创新思路作用越大。
请使用 SCRUM 方法，选择一个用例图，编制某定旅馆开发的需求（backlog）开发计划表

选择携程订酒店的用例图。

ID	Name	Imp	Est	How to demo
1	find hotel	10	5	根据酒店名、地点查找酒店，输入目的地、日期等相关信息后获取匹配的酒店列表
2	make reservation	10	5	选择酒店、房间并确认
3	login	6	2	建立用户账户信息数据库，与第三方软件绑定实现多种方式登陆
4	manage basket	7	3	用户查看订单，并可以进行修改
5	pay	8	3	在完成登陆后可以支付订单费用，需要用到不同支付方式的api

根据任务4，参考使用用例点估算软件成本，给出项目用例点的估算

根据用户点方法，对用例分配权重的标准是：
- 简单用例：1 到 3 个事务，权重=5
- 一般用例：4 到 7 个事务，权重=10
- 复杂用例：多于 7 个事务，权重=15

用例	业务	计算	UC比重
find hotel	3	3	简单
make reservation	4	4	一般
login	2	1	简单
manage basket	4	3	一般
pay	3	1	简单