作业4
1.简答题
-
用例的概念
用例是描述参与者使用软件系统在不同交互手段和场景下,可能达到的一系列成功或者失败的结果。用例目的是获取需求,它说明了系统是如何和最终用户或其它系统互动,明确业务范围、服务对象、外部系统。 -
用例和场景的关系?什么是主场景或 happy path?
- 关系:场景是用例的实例化,用来说明在某种情况下用户和系统的交互过程。而用例是一系列的成功和失败场景的集合,用来描述参与者使用系统来完成目的时可能出现的各种情况。
- 主场景(happy path):每个用例一般只有一个主场景,主场景是指系统最主要的交互,通常是默认没有错误或异常的场景,是最常用的直接地实现用户目标的场景。
- 用例有哪些形式?
用例的三种形式:
- 摘要:简洁的一段式摘要,通常用于主成功场景。
- 非正式:非正式的段落格式。用几个段落覆盖不同场景。
- 详述:详细编写所有步骤及各种变化,同时具有补充部分,如前置条件和成功保证。
-
对于复杂业务,为什么编制完整用例非常难?
复杂的业务会涉及到的很多的场景,要将业务涉及的所有参与者,相关的场景全部列举出来是很困难的。用例编制者需要熟悉各种业务场景和流程,理清所有场景的关系,而复杂业务很多时候有些需求是不清晰的,所以编制复杂业务的完整用例是很难实现的。 -
什么是用例图?
用例图是系统语境图,由参与者、用例、边界以及它们之间的关系构成的用于描述系统功能的视图。用例图展示系统边界、位于边界之外的事物以及系统如何被使用。用例图可以作为沟通的工具,用以概括系统及其参与者的行为。 -
用例图的基本符号与元素?
- 参与者(Actor):表示的是一个系统用户,指的是与应用程序进行交互的用户、组织或者外部系统,图中人形符号。
- 用例(Use Case):表示的是系统提供的功能、服务,图中椭圆符号。
- 用例关系
1) 包含关系(Include):表示用例可以简单地包含其他用例所具有的行为,并把它所包含的用例行为作为自身行为的一部分。带箭头的虚线表示,箭头指向被包含的用例,并有include标识。
2) 泛化关系(Generalization):泛化指的是一个父用例可以被特化形成多个子用例,而父用例和子用例之间的关系就是泛化关系。用空心三角箭头的实线表示,箭头指向父用例。
3) 关联关系(Association):表示的是参与者与用例之间的关系。用一条直线,连接参与者和实例,并有association标识。
4)扩展/延伸关系(Extend):表示把新的行为加入到已有的用例中,获得的新用例叫做扩展用例,原有的用例叫做基础用例,相当于为基础用例提供一个附加功能,不会影响到基础用例的完整性。用虚线表示,箭头指向基础用例,并有extends。
-
用例图的画法与步骤
- 确定划分系统边界
- 识别确定系统的参与者,对于每类用户,标识与系统相关的用户所扮演的所有角色
- 为每个目标创建用例,构造用例,确定用例之间的关系
- 确定用户的优先级,审核,评估和验证。
- 用例图给利益相关人与开发者的价值有哪些?
- 对于利益相关人来说,可以直观了解系统的功能和操作过程,确保系统满足用户的需求。用例图可以根据用户提出的需求,直观地呈现系统程序的增删调节,通过修改用例图来表现。
- 对于开发者来说,可以明确系统的业务范围、服务对象、外部系统与设备。可以识别技术风险,提前实施关键技术原型攻关与学习。还可以评估项目工作量,合理规划迭代周期,规划人力需要。
2.建模练习题(用例模型)
- 选择2-3个你熟悉的类似业务的在线服务系统(或移动 APP),如定旅馆(携程、去哪儿等)、定电影票、背单词APP等,分别绘制它们用例图。并满足以下要求:
- 请使用用户的视角,描述用户目标或系统提供的服务
- 粒度达到子用例级别,并用 include 和 exclude 关联它们
- 请用色彩标注出你认为创新(区别于竞争对手的)用例或子用例
- 尽可能识别外部系统和服务
- 订旅馆系统用例
- 外卖系统用例
- 然后,回答下列问题:
- 为什么相似系统的用例图是相似的?
因为相似系统的业务逻辑是相似,使用到的用例的类型基本一致,用例之间的关系也是相似的。同类系统的实例之间具有一致的基本功能,而区分的主要依据是带有特色的扩展功能。所以在用例图上是相似的。 - 如果是定旅馆业务,请对比 Asg_RH 用例图,简述如何利用不同时代、不同地区产品的用例图,展现、突出创新业务和技术。
根据当地的特色产业,如旅游业,为旅客提供针对性的旅馆推荐。还可以根据时代的前沿技术,例如大数据和人工智能,学习用户的习惯来进行智能推荐。 - 如何利用用例图定位创新思路(业务创新、或技术创新、或商业模式创新)在系统中的作用
在用例图中高亮标记一些核心的创新业务,让开发人员直观了解该系统的创新功能以及功能的实现路径。 - 请使用 SCRUM 方法,选择一个用例图,编制某定旅馆开发的需求(backlog)开发计划表
- 为什么相似系统的用例图是相似的?
ID | Name | Imp | Est(man/day) | How to demo | Notes |
---|---|---|---|---|---|
1 | 账号系统 | 10 | 5 | 账号注册、登录、登出 | 密码加密传输、个人信息的设置 |
2 | 搜索酒店 | 15 | 8 | 页面给用户提供多样化方便的搜索酒店功能 | 预测匹配,允许筛选 |
3 | 寻找房间 | 15 | 8 | 进入酒店页面,显示酒店提供的所有房间的信息 | 房间信息描述要细致,只显示空闲房间 |
4 | 预定房间 | 10 | 3 | 用户选择房间后锁定房间,生成订单信息 | 给订单派发房间号并锁定防止冲突 |
5 | 支付订单 | 10 | 5 | 订单下好后在限定时间内支付,否则取消订单,可选择多种支付手段 | 微信、支付宝支付api |
6 | 取消预定 | 5 | 3 | 在预定日期前两天以上可以取消订单并退款 | 要收退订手续费 |
- 根据任务4,参考 使用用例点估算软件成本,给出项目用例点的估算
简单用例:1 到 3 个事务,权重=5
一般用例:4 到 7 个事务,权重=10
复杂用例:多于 7 个事务,权重=15
用例 | 事务 | 计算 | 原因 | 权重 |
---|---|---|---|---|
账号系统 | 3 | 1 | 框架 | 简单 |
搜索酒店 | 8 | 8 | 搜索分类方式复杂多样 | 复杂 |
寻找房间 | 4 | 4 | 一般 | |
预定房间 | 2 | 1 | 简单 | |
支付订单 | 6 | 4 | 关联外部系统 | 一般 |
取消预定 | 2 | 1 | 简单 |