简答题
1. 用例的概念
用例（英语：use case），或译使用案例、用况，是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。编写用例时要避免使用技术术语，而应该用最终用户或者领域专家的语言。用例一般是由软件开发者和最终用户共同创作的。
2. 用例和场景的关系？什么是主场景或 happy path？
场景(scenario)是参与者和系统之间的一系列特定的活动和交互，也称为用例实例(use case instance)。场景是使用系统的一个特定情节或用例的一条执行路径。例如使用现金成功购买商品的场景，或者由于信用卡付款被拒绝造成的购买失败场景。通俗地讲，用例(use case)就是一组相关的成功和失败场景集合，用来描述参与者如何使用系统来实现其目标。
3. 用例有哪些形式？
Brief（high level）
- Terse one-paragraph summary, usually of the main success scenario.
- During early requirements analysis, to get a quick sense of subject and scope. May take only a few minutes to create
Casual（简便格式）
- Informal paragraph format. Multiple paragraphs that cover various scenarios.
- When? As above.
Fully
- dressed All steps and variations are written in detail, and there aresupporting sections, such as preconditions and success guarantees.
- After many use cases have been identified and written in a brief format, then during the first requirements workshop a few (such as 10%) of the architecturally significant and high-value use cases are written in detail.
4. 对于复杂业务，为什么编制完整用例非常难？
复杂业务的子用例非常多，流程复杂，且需要处理的场景很多。因此很难考虑完全所有子用例和场景，且绘制的用例图繁杂，容易出错。而且复杂业务活动包含很多用例，他们与过程关系用户难以理解，功能业务逻辑十分复杂，且非常耗时，这样就不能保证用例的完整性、逻辑性。
5. 什么是用例图？
用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。用例图（User Case）是外部用户（被称为参与者）所能观察到的系统功能的模型图。用例图是系统的蓝图。用例图呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。
6. 用例图的基本符号和元素？
参与者（Actor）： 表示的是一个系统用户，也就是与应用程序进行交互的用户、组织或外部系统。
用例（Use Case）： 表示的是对系统提供的功能、服务的一种描述。
包含关系（Include）： 表示用例可以简单地包含其他用例所具有的行为，并把它所包含的用例行为作为自身行为的一部分。
泛化关系（Generalization）： 泛化指的是一个父用例可以被特定化形成多个子用例，而父用例和子用例之间的关系就是泛化关系。
关联关系（Association）： 表示的是参与者与用例之间的关系。
扩展/延伸关系（Extend）： 表示在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例，原有的用例叫做基础用例，相当于为基础用例提供一个附加功能。
系统边界：用来表示正在建模的边界。
7. 用例图的画法与步骤？
确定系统边界
确定参与者
- 谁将使用该系统的主要功能。
- 谁将需要该系统的支持以完成其工作。
- 谁将需要维护、管理该系统，以及保持该系统处于工作状态。
- 系统需要处理哪些硬件设备。
- 与该系统那个交互的是什么系统。
- 谁或什么系统对本系统产生的结果感兴趣。
识别用例
- 特定参与者希望系统提供什么功能。
- 系统是否存储和检索信息，如果是，由哪个参与者触发。
- 当系统改变状态时，是否通知参与者。
- 是否存在影响系统的外部事件。
- 哪个参与者通知系统这些事件。
确定用例间的关系
用例除了与参与者发生关系外，还可以具有系统中的多个关系，这些关系包括包含关系、扩展关系和泛化关系。应用这些关系的目的是为了从系统中抽取出公共行为和其变体。
8. 用例图给利益相关人与开发者的价值有哪些？
对于利益相关人：
- 可以直观看到系统的结果和用户的功能体验，保证系统按照用户的需求进行设计。
- 用例能够根据需要对复杂程度和形式化程序进行增减调节，即能够响应用户（利益相关人)提出的需求，而用例图则使得这种调节更加便利，可以通过修改图形间的关系实现。
对于开发者来说：
- 用例图是设计者设计过程的结论与参考，设计者与开发者之间的交流工具，开发者开发过程的蓝图。
- 用例图使得开发者能够更明确地获得需求，更好地理解需求。
- 用例图可以指导开发和测试，同时可以在整个过程中对其他工作流起到指导作用。
建模练习题（用例模型）
订旅馆（去哪儿）
订电影票（淘票票）
回答下列问题：
1. 为什么相似系统的用例图是相似的？
相似系统面对的参与者和用例是相似的，用例之间的关系也是同构的。用户预期的功能都是相似的，即不同的同类系统一定具有一致基本功能以及带有自己特色的扩展功能。所以体现在用例图上也是相似的。
2. 如果是定旅馆业务，请对比 Asg_RH 用例图，简述如何利用不同时代、不同地区产品的用例图，展现、突出创新业务和技术
不同时代对预定的酒店的需求不同。可以让筛选算法与时俱进，满足一些不同的主流要求。且用户会需要更加优秀、好用、有参考价值的评价系统，也需要随时更新。而不同地区的消费特点不同，旅游胜地和普通城市用户对于酒店预订的需求有差别，可以在用例图上突出一些特点。
3. 如何利用用例图定位创新思路（业务创新、或技术创新、或商业模式创新）在系统中的作用
应该通过创新点在图中的位置来判断。如果创新位于较高的父级，则作用比较大。如果是子类或者是被包括的关系，则作用相对较小。
4. 请使用 SCRUM 方法，选择一个用例图，编制某定旅馆开发的需求（backlog）开发计划表
请使用SCRUM方法，选择一个用例图，编制某定旅馆开发的需求（backlog）开发计划表
| ID |
Name |
Imp |
Est |
How to demo |
| 1 |
注册 |
5 |
3 |
点击注册按钮，输入手机号，获取验证码，输入密码 |
| 2 |
登陆 |
5 |
3 |
点击登陆，输入手机号，选择密码登陆或短信验证登陆，填写密码或获取验证码并正确填写验证码 |
| 3 |
查询酒店 |
15 |
10 |
通过位置，种类价格，档次等属性筛选或排序酒店，或直接通过酒店名查找酒店 |
| 4 |
预订酒店 |
20 |
16 |
选择酒店后，选择房间类型，根据条件筛选房间，确定入住日期，预付定金 |
| 5 |
取消预订 |
10 |
6 |
选择订单，点击退订，返回定金 |
| 6 |
酒店评价 |
10 |
8 |
交易完成后，可选择对酒店进行评论及评分 |
5. 根据任务4，参考使用用例点估算软件成本，给出项目用例点的估算
根据用户点方法，对用例分配权重的标准是：
简单用例：1到3个事务，权重=5
一般用例：4到7个事务，权重=10
复杂用例：多于7个事务，权重=15
| 用例 |
#事务 |
#计算 |
原因 |
UC权重 |
| 1 |
注册 |
4 |
2 |
简单 |
| 2 |
登陆 |
3 |
2 |
简单 |
| 3 |
查询酒店 |
7 |
7 |
一般 |
| 4 |
预订酒店 |
4 |
4 |
一般 |
| 5 |
取消预订 |
3 |
2 |
简单 |
| 6 |
酒店评价 |
3 |
2 |
简单 |
| 
转播
