系统分析与设计作业4
- 简答题
- 用例的概念
是软件工程或系统工程中对系统如何反应外界请求的描述,是一种通过用户的使用场景来获取需求的技术。用于描述系统的一组成功和失败场景. - 用例和场景的关系?什么是主场景或happy path?
每个用例提供了一个或多个场景,说明了系统是如何和其他系统或者用户进行互动的.
主场景或happy path是指主要的系统交互,是一个默认场景,不存在错误条件.是对于真实的交互进行的一种简化.主要用于突出逻辑性. - 用例有哪些形式?
- brief
简短的用例, 都是主要的成功场景. 只在早期的需求分析过程中出现, 目的是为了能够通过用例的形式快速了解主题. - casual
非正式的段落格式,包括多个段落. 同样出现在早期的需求分析过程中. - fully
所有用例的步骤和各种条件都十分详细,有必要的支持部分,比如前提和成功条件.
- brief
- 用例的概念
- 对于复杂业务,为什么编制完整用例非常难?
因为复杂的业务涉及到的相关的角色和各种条件都非常多, 随着角色和之间的关系的数量的增加, 最后导致的整个用例的各种可能性增加. 所以最后确定下来一个可行的用例非常难. - 什么是用例图?
用例图是用户与系统交互的最简形式, 可以展现出用户和其他相关用例之间的关系. - 用例图的基本符号与元素?
图中分别是actor的符号和use case符号 - 用例图的画法和步骤
- 确定参与者
- 确定系统边界
- 确定用例及支持该用例的系统
- 绘制用例间的关系
- 用例给利益相关人与开发者的价值
用例图是项目利益相关人,开发者交流的工具. 能够把原来很抽象的逻辑交互用图的形式表示出来, 能够更好从不同感官去理解问题.
- 建模练习
-
百词斩
- 买电影票
- 买电影票
-
为什么相似系统的用例图是相似的?
因为相似系统的交互逻辑往往是类似的, 涉及到的用户也都是类似的, 所以从用例图的角度来看最后的效果应该是相似的. -
如果是定旅馆业务,请对比 Asg_RH 用例图,简述如何利用不同时代、不同地区产品的用例图,展现、突出创新业务和技术。
预先设定不同的颜色用于表示不同类型的用例图和不同的业务和技术, 最后通过不同的颜色来标识出不同重要和创新程度的业务和技术. -
如何利用用例图定位创新思路(业务创新、或技术创新、或商业模式创新)在系统中的作用
因为用例图把用户和系统之间的交互都可视化出来了, 所以相对于一般的逻辑交互来说可以更加直观地表现出来可能存在的一些重要的或者遗漏的细节, 所以通过对于用例图的分析,可以更加把用户目标表现得更加清晰, 能够更加方便地增加或者删改用户的潜在需求.
-
请使用 SCRUM 方法,选择一个用例图,编制某定旅馆开发的需求(backlog)开发计划表
| ID | Name | Imp | Est | How to demo | Notes |
| — | — | — | — | —| — |
| 1 | 找酒店 | 50 | 10 | 根据位置信息返回附近的酒店再对于结果进行选取| |
| 2 | 预定 | 50 | 20 | 需要判断酒店是不是已经满了, 如果有空就可以填写个人信息| 为了确保酒店的位置不会发生冲突,需要二阶段提交防止冲突|
| 3 | 支付订单 | 30 | 5 |对于已经选择并且完成的订单进行支付操作| 需要和其他手机支付app达成协议|
| 4 | 管理订单| 20 | 3| 用户可以修改已经开始的订单| |
| 5|管理账户| 30 | 10|修改个人信息||
-
5.根据任务4,参考使用用例点估算软件成本,给出项目用例点的估算
用例 | 事务 | 计算 | 原因 | uc weight |
---|---|---|---|---|
查找酒店 | 2 | 3 | 对于所有酒店的信息获取存入数据库 | 简单 |
预定酒店 | 3 | 4 | 酒店验证个人信息真实性 | 简单 |
支付订单 | 1 | 1 | 网站收益来源,确保正确性 | 复杂 |
订单管理 | 4 | 4 | 对于订单管理的权限 | 简单 |
管理账户 | 3 | 3 | 对于个人信息的修改验证真实性 | 简单 |