系统分析与设计作业4

1. 简答题

1.1 用例的概念

用例是对一组动作序列的抽象描述，系统执行这些动作序列，产生相应的结果。这些结果要么反馈给参与者，要么作为其他用例的参数。
用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。

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

• 用例表示一组场景的集合，包括主场景，加上零个或多个可选场景。
• 主场景最常用，直接地实现用户目标的故事。对应于主要的系统交互，通常是“成功”场景。

1.3 用例有哪些形式？

• 摘要（brief）：简短的一段总结，通常是主要的成功场景。在早期的需求分析中，快速了解主题和范围。可能只需要几分钟来创建。
• 简便（Casual）：非正式的段落格式。包含多种场景的多个段落。
• 完整（fully）：所有的步骤和变化都写得很详细，并有支持部分，如先决条件和成功的保证。

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

对于复杂业务来说，其涉及到的场景也会变得非常多，它们之间的关联以及一些其他交互等问题非常多，用例更为复杂，需要考虑的细节也更加多，可能还会出现遗漏或者不清晰等等，所以编制完整用例很难。

1.5 什么是用例图？

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

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

• 参与者（Actor）：表示的是一个系统用户，也就是与应用程序进行交互的用户、组织或者外部系统。
  
• 用例：表示的是对系统提供的功能、服务的一种描述。
  
• 系统边界：系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。
  
• 包含关系（include）：表示用例可以简单地包含其他用例所具有的行为，并把它所包含的用例行为作为自身行为的一部分。在UML中常用带箭头的虚线表示，箭头指向被包含的用例。
  
• 扩展关系（extend）：表示在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例，原有的用例叫做基础用例，相当于为基础用例提供一个附加功能。在UML中用带箭头的虚线表示，箭头指向基础用例。
  
• 关联关系：表示的是参与者与用例之间的关系。在UML中常用一条直线，或者是一条带箭头的线条来表示，箭头指向信息接收方。
  
• 泛化关系：泛化指的是一个父用例可以被特化形成多个子用例，而父用例和子用例之间的关系就是泛化关系。在UML中用空心三角箭头的实线表示，箭头指向父用例。
  

1.7 用例图的画法与步骤

• 确定系统边界
• 确定参与者
  • 谁将使用该系统的主要功能。
  • 谁将需要该系统的支持以完成其工作。
  • 谁将需要维护、管理该系统，以及保持该系统处于工作状态。
  • 系统需要处理哪些硬件设备。
  • 与该系统那个交互的是什么系统。
  • 谁或什么系统对本系统产生的结果感兴趣。
• 参与者之间的关系
  • 因为参与者是类，所以多个参与者之间可以具有与类相同的关系。在UML用例图中，使用了泛化关系来描述多个参与者之间的公共行为。
• 识别用例
  • 识别用例最好的方法就是从分析系统的参与者开始，考虑每一个参与者是如何使用系统的。使用这种策略的过程中可能会发现新的参与者，这对完善整个系统的建模有很大的帮助。
• 用例之间的关系
  • 关联关系：关联关系表示参与者与用例之间的通信。不同的参与者可以访问相同的用例，一般说来它们和该用例的交互是不一样的
  • 包含关系：把几个用例的公共步骤分离成一个单独的被包含用例。被包含用例称作提供者用例，包含用例称作客户用例，提供者用例提供功能给客户使用。用例间的包含关系允许包含提供者用例的行为到客户用例的事件中。
  • 扩展关系：扩展关系是把新的行为插入到已有的用例中的方法。同一个基础用例的几个扩展用例可以在一起应用。
  • 泛化关系：一个用例可以被特别列举为一个或多个用例，这被称为用例泛化。当父用例能够被使用时，任何子用例也可以被使用。
• 参与者与用例的关系

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

• 明确系统的业务范围、服务对象（角色）、外部系统与设备
• 帮助识别技术风险，提前实施关键技术原型公关与学习
• 易于评估项目工作量，合理规划迭代周期，规划人力需要

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

2.1 绘制用例图

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

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

定旅馆（去哪儿）

定电影票

2.2 回答下列问题：

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

因为相似的系统的业务功能，以及参与者受众大多一样，想要实现的目标也相似，用例场景相似，所以用例图也相似。

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

新时代可以选择更加精准和智能的筛选或者预测算法，达到更好的用户体验效果，不同地区可以可以根据当地旅游景点等发展创新业务和技术。

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

使用色彩标注出创新用例或子用例。

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

ID	Name	Imp	Est	How to demo	note
1	登录	20	4	手机验证码或支付宝账号登录	短信服务，第三方授权
2	查询	60	12	根据地点时间以及对房间的要求查询满足需要的住处	筛选和排序算法，获取地理位置api
3	预定	50	10	选择时间地点，房型人数等预定，并确认订单	旅馆房间空闲状态的及时更新
4	支付	40	8	选择支付方式支付完成订单	与支付宝微信支付方的联合

2.2.5 估算项目用例点

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

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

用例	事务	计算	原因	UC权重
登录	3	2	验证码或账号密码登录	简单
查询	8	8	通过各种输入条件筛选排序等	复杂
预定	3	4	填写信息并确认订单	一般
支付	3	2	关联外部支付api	简单