共计 3014 个字符，预计需要花费 8 分钟才能阅读完成。
用例的概念
用例（use case），或使用案例、用况，是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。编写用例时要避免使用技术术语，而应该用最终用户或者领域专家的语言。用例一般是由软件开发者和最终用户共同创作的。
用例和场景的关系？什么是主场景或 happy path？
用例是是一组相关的成功和失败的场景（success and failure scenarios），这些场景是用于描述一个 actor 使用系统去 support 一个目标（goal）。
主成功场景或 happy path 是用例从触发事件开始，一步一步执行，最终满足用例利益的步骤集合。
主成功场景应该包括以下信息：
两个执行者之间的交互。如，用户提交了订单。
为保证主成功场景得以继续的确认。如，系统确认用户密码。
主成功场景推进过程中的内部变化。如，系统扣除用户账户余额。
用例有哪些形式？
摘要：简洁的一段式概要，通常用于主成功场景。在早期需求分析过程中，为快速了解主题和范围，通常花费少量时间快速编写。
非正式形式：非正式的段落格式，用几个段落覆盖不同的场景。
详述：详细编写所有步骤和各种变化，同时具有补充部分，如前置条件和成功保证。确定并以摘要形式编写大量用例后，在第一次需求讨论中，详细地编写其中少量的具有重要架构意义和高价值的用例。
对于复杂业务，为什么编制完整用例非常难？
复杂业务的场景较多，场景较为复杂。在前期的考虑中，很难不遗漏一些业务条件和需求，且这些需求条件还可能发生变化。所以对于复杂业务，编制完整用例且不遗漏情景、良好地安排每个场景、场景内元素地关系非常困难。
什么是用例图？
用例图是描述系统与其他外部系统以及用户之间交互的图形，即用例图描述了谁将使用系统，用户希望以什么方式与系统交互。用例图确定系统中所包含的参与者、用例和两者之间的对应关系，它描述的是关于系统功能的一个概述，描述软件应具备哪些功能模块以及这些模块之间的调用关系。用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户）。
用例图的基本符号与元素？
参与者：表示与您的应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。
用例 (Use Case): 用例就是外部可见的系统功能，对系统提供的服务进行描述。用椭圆表示
子系统 (Subsystem)：用来展示系统的一部分功能，这部分功能联系紧密。
关系
用例图中涉及的关系有：关联、泛化、包含、扩展；
关联 (Association)：表示参与者与用例之间的通信，任何一方都可发送或接受消息。
【箭头指向】：指向消息接收方
泛化 (Inheritance)：就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。
【箭头指向】：指向父用例
包含 (Include)：包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤；
【箭头指向】：指向分解出来的功能用例
扩展 (Extend)：扩展关系是指 用例功能的延伸，相当于为基础用例提供一个附加功能。
【箭头指向】：指向基础用例
依赖 (Dependency)：表示源用例依赖于目标用例；
【箭头指向】：指向被依赖项
项目 (Artifact)：用依赖关系把某个用例依赖到项目上。
用例图的画法与步骤
确定参与者，包括:
主要参与者：谁将使用系统的主要功能、谁将需要系统的支持以完成工作等
协作参与者：谁将提供对应的系统功能、谁将维护系统，保证系统处于工作状态等
幕后参与者：谁会对系统产生的结果感兴趣
根据用户需求识别和创作用例，主要重点在于：
识别使用系统的主要参与者（primary actors）/ 角色 (roles)
识别系统依赖的外部系统
识别用例（服务）
识别用户级别用例（user goal level）
识别子功能级别的用例（sub function level）
建立 Actor 和 Use Cases 之间的关联。
用例图给利益相关人与开发者的价值有哪些？
对于利益相关人：
可以直观看到系统的结果和用户的功能体验，保证系统按照用户的需求进行设计。
用例能够根据需要对复杂程度和形式化程序进行增减调节，即能够响应用户（利益相关人 ) 提出的需求，而用例图则使得这种调节更加便利，可以通过修改图形间的关系实现。
对于开发者来说：
用例图是设计者设计过程的结论与参考，设计者与开发者之间的交流工具，开发者开发过程的蓝图。
用例图使得开发者能够更明确地获得需求，更好地理解需求。
用例图可以指导开发和测试，同时可以在整个过程中对其他工作流起到指导作用。
选择 2 - 3 个你熟悉的类似业务的在线服务系统（或移动 APP），如定旅馆（携程、去哪儿等）、定电影票、背单词 APP 等，分别绘制它们用例图。并满足以下要求：
1. 请使用用户的视角，描述用户目标或系统提供的服务
2. 粒度达到子用例级别，并用 include 和 exclude 关联它们
3. 请用色彩标注出你认为创新（区别于竞争对手的）用例或子用例
4. 尽可能识别外部系统和服务
订旅馆：
定电影票：
1. 为什么相似系统的用例图是相似的？
相似系统面对的参与者和用例是相似的，用例之间的关系也是同构的。用户预期的功能都是相似的，即不同的同类系统一定具有一致基本功能以及带有自己特色的扩展功能。所以体现在用例图上也是相似的。
2. 如果是定旅馆业务，请对比 Asg_RH 用例图，简述如何利用不同时代、不同地区产品的用例图，展现、突出创新业务和技术
不同时代对预定的酒店的需求不同。可以让筛选算法与时俱进，满足一些不同的主流要求。且用户会需要更加优秀、好用、有参考价值的评价系统，也需要随时更新。而不同地区的消费特点不同，旅游胜地和普通城市用户对于酒店预订的需求有差别，可以在用例图上突出一些特点。
3. 如何利用用例图定位创新思路（业务创新、或技术创新、或商业模式创新）在系统中的作用
应该通过创新点在图中的位置来判断。如果创新位于较高的父级，则作用比较大。如果是子类或者是被包括的关系，则作用相对较小。
4. 请使用 SCRUM 方法，选择一个用例图，编制某定旅馆开发的需求（backlog）开发计划表
ID
Name
Imp
Est
How to demo
1
find hotel
10
3
Find the hotel by name or location or type
2
make reservation
7
4
determine hotel, room type, time and then confirm
3
pay reservation
7
3
payment supported by pay system
4
modify reservation
5
2
modify reservation and hotel make approval
5
comment hotel
4
2
Comment of the hotel and show to others
5. 根据任务 4，参考 使用用例点估算软件成本，给出项目用例点的估算
根据用户点方法，对用例分配权重的标准是：
简单用例：1 到 3 个事务，权重 =5
一般用例：4 到 7 个事务，权重 =10
复杂用例：多于 7 个事务，权重 =15
用例
业务
计算
原因
UC 比重
查找酒店
3
2
简单
下订单
7
6
一般
支付
2
1
简单
修改订单
3
2
简单
评论
3
2
简单
