系分作业六

简答题

1. 用例的概念

用例是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。在UML的文档中，Use Case的定义是：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。

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

每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。主场景或happy path是指用例从触发时间开始，一步一步执行，最终满足用例利益的步骤集合。主成功场景应该包括一下信息：（1）两个执行者之间的交互。如，用户提交了订单；（2）为保证主场景得以继续的确认。如，系统确认用户密码；（3）主场景推进中的内部变化。如，系统扣除用户账户余额。

3. 用例有哪些形式？

• 摘要：简洁的一段式概要，通常用于主成功场景。在早期需求分析过程中，为快速了解主题和范围，通常花费少量时间快速编写。
• 非正式形式：非正式的段落格式，用几个段落覆盖不同的场景。
• 详述：详细编写所有步骤和各种变化，同时具有补充部分，如前置条件和成功保证。确定并以摘要形式编写大量用例后，在第一次需求讨论中，详细地编写其中少量的具有重要架构意义和高价值的用例。

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

复杂业务涉及到的场景比较多，业务流程复杂繁琐，场景之间也有各种关联，如果要编制完整的用例，需要熟悉各种业务场景和流程，还需要建模相关知识，注意用户交互的细节，并且增加了提取一个场景中的主要元素的难度。

5. 什么是用例图？

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

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

• 参与者（Actor）：参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。
  
• 用例（Use Case）：用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。
  
• 子系统(Subsystem)：用来展示系统的一部分功能，这部分功能联系紧密。
  
• 关系：用例图中涉及的关系有：关联、泛化、包含、扩展。
  a. 关联(Association)：表示参与者与用例之间的通信，任何一方都可发送或接受消息。箭头指向消息接收方。
  
  b. 泛化(Inheritance)：就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。箭头指向父用例。
  
  c. 包含(Include)：包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。箭头指向分解出来的功能用例。
  
  d. 扩展(Extend)：扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。箭头指向基础用例。
  
  e. 依赖(Dependency)：但VS2010的用例模型图中，添加了依赖关系，用带箭头的虚线表示，表示源用例依赖于目标用例。箭头指向被依赖项。
• 项目(Artifact)：用例图虽然是用来帮助人们形象地理解功能需求，但却没多少人能够通看懂它。很多时候跟用户交流甚至用Excel都比用例图强，VS2010中引入了“项目”这样一个元素，以便让开发人员能够在用例图中链接一个普通文档。
• 注释(Comment)

7. 用例图的画法与步骤

• 确定系统边界；
• 确定参与者，绘制在边界外；
• 确定用例，需要系统提供什么功能，相关的参与者等，由动词开头；
• 思考用例之间的关系，如包含关系、扩展关系和泛化关系；
• 确定关联的外部支持系统。

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

对于利益相关人，用例图可以使系统的功能和使用可视化，各模块功能之间关系清晰可见，方便向客户阐释；同时有助于客户在开发过程中提出改进意见；
对于开发者，用例图使得客户的需求可视化，同时使得系统架构和功能清晰。

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

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

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

回答下列问题：

• 为什么相似系统的用例图是相似的？
  因为相似系统的业务逻辑相似，而且他们的子系统也很相似，所以他们的用例图是相似的，可能只是具体功能和某些结构有点不同而已。
• 如果是定旅馆业务，请对比 Asg_RH 用例图，简述如何利用不同时代、不同地区产品的用例图，展现、突出创新业务和技术
  不同时代因为时代背景关系可能对订旅馆的需求和选择喜好不同，而不同的地区由于风土人情可能有不同的酒店特色。可以根据这些这些差异特点推出特色服务和特色酒店介绍，同时还可以增加附近景点推荐和特色主打。
• 如何利用用例图定位创新思路（业务创新、或技术创新、或商业模式创新）在系统中的作用
  对创新部分设置指定背景色，使得开发人员能迅速快捷地找到创新思路的输入输出以及上下关系和依赖。
• 请使用 SCRUM 方法，选择一个用例图，编制某定旅馆开发的需求（backlog）开发计划表

ID	Name	Imp	Est	How to demo
1	注册	20	2	使用手机号或邮箱注册，使用验证码作为验证成功方式
2	登录	15	2	使用账户密码或者手机验证码方式登录
3	查找旅馆	20	5	根据时间、旅馆星级、地点、房间数量、入住人数查找旅馆
4	预定房间	20	3	查找好酒店后，预定房间，然后确认
5	支付	25	3	调用支付API，使用银行卡支付、支付宝支付或者微信支付

• 根据任务4，参考使用用例点估算软件成本，给出项目用例点的估算
  根据用户点方法，对用例分配权重的标准是：
  a. 简单用例：1 到 3 个事务，权重=5
  b. 一般用例：4 到 7 个事务，权重=10
  c. 复杂用例：多于 7 个事务，权重=15

用例	事务	计算	UC权重
1	注册	2	简单
2	登录	2	简单
3	查找旅馆	5	一般
4	预定房间	3	简单
5	支付	3	一般