系统分析与设计hw6
简答题
用例的概念
用例也就是在用户和软件系统交互的过程中,对于不同行为而产生不同结果的描述,其是很多个场景的集合,每个场景都说明了用户和软件系统交互的一种路径或方式,其描述了系统可以做什么,从而对软件系统提供一个明确的业务目标。
用例和场景的关系?什么是主场景或 happy path?
用例实际上就是场景的集合,很多个场景结合起来构成一个用例,场景往往只描述用户和整个系统中一个或者某些模块的交互和交互结果,而用例则是对整个软件系统的描述,主场景可以认为是一个软件系统的基本流程,一个软件系统可能有很多功能,但是正如28法则所说,20%的工作就可以完成80%的需求,而代表这完成的20%工作的场景,就可以认为是满足了大部分的需求,也就可以认为是一个软件项目的基本流程,也就是主场景
用例有哪些形式?
主要分为以下三种形式
- 摘要(brief): 描述较为剪短,通常用来描述主场景,以便开发人员快速知悉系统需求,创建时间较快,一般在项目初期使用
- 非正式(casual): 由几个非正式的段落构成,除了主场景外,还描述了其他几个比较重要的场景,但是仍有需要补充的地方
- 完整型(fully): 有结构的详细描述了用例中的所有场景的步骤和交互行为,包括了前提条件和成功保证等各种细节,为项目开发的全过程提供保障
对于复杂业务,为什么编制完整用例非常难?
因为对于复杂业务来说,其场景不仅多而且往往很复杂,而且每个场景之间有时候又有复杂的联系,所以在一开始创建场景的时候很难马上想到所有的细节问题,所以复杂业务的用例往往需要不断的迭代,才有可能创建出一个相对完整的用例,所以一开始就要求编制出一个完整用例是很不现实的。
什么是用例图?
用例图是指由参与者(Actor)、用例(Use Case),边界以及它们之间的关系构成的用于描述系统功能的视图,是用户与系统交互的最简表示形式,展现了用户与他相关的用例之间的关系。通过用例图,人们可以获知系统不同种类的用户和用例。
用例图的基本符号与元素?
- 参与者(Actor): 一个系统用户,包括和软件系统交互的用户、组织或系统
- 用例(use case)用例是参与者可以感受到的系统服务或功能单元,包括变量在内的一组动作序列的描述
- 系统边界: 标识建模系统的边界,系统所包含的范围
- 包含关系(include): 表示用例可以简单地包含其他用例所具有的行为,并把它所包含的用例行为作为自身行为的一部分
- 泛化关系(Generalization):用例的泛化指的是一个父用例可以被特化形成多个子用例,用我们熟悉的语言来说就是继承关系
- 拓展关系(extend):表示在一定条件下,把新的行为加入到已有的用例中,获得的新用例叫做扩展用例,原有的用例叫做基础用例,相当于为基础用例提供一个附加功能
- 关联关系(Association): 示的是参与者与用例之间的关系
用例图的画法与步骤
1.绘制系统边界,并且给系统命名
2.确定参与者信息,包括主要参与者,协作参与者和幕后参与者,并且标记好这些参与者之间的关系
3.编写用例,描述好每个参与者分别会参与哪些业务事件,并且标记好参与者和用户的联系
4.确定好用例之间的联系,不如包含关系或者拓展关系等
5.确定系统的外部依赖,比如一些外部的api等,并在图中标明
用例图给利益相关人与开发者的价值有哪些?
- 可以让人更为清晰的认识系统的功能和用户交互情况,保证能基本满足用户的需求
- 对于开发人员可以通过用例图和设计人员更好的沟通,避免沟通过程中出现误解,带来不必要的成本
- 用例图可以对开发者的开发和测试进行指导,使开发者对模块间的关系更为清晰,同时也可以评估整个项目的复杂度
- 如果后续有需求变更,用例图可以很好的反映出变化,有利于大型团队的信息交流
建模练习题
1.以扇贝单词app为例,用例图如下:
为什么相似系统的用例图是相似的?
因为相似的系统都具有相同的功能和需求,而用例图是由参与者、用例,边界以及它们之间的关系构成的用于描述系统功能的视图。在功能和需求相似的情况下,用例图自然相似。
如果是定旅馆业务,请对比 Asg_RH 用例图,简述如何利用不同时代、不同地区产品的用例图,展现、突出创新业务和技术
不同时代用户的需求不同,Asg_RH用例图主要满足的是用户基本需求,在不同时代不同地区都会有不一样的新技术,新特点,比如现在,就有了二维码技术和人脸识别技术,可以作为extends的部分拓展到系统中去
如何利用用例图定位创新思路(业务创新、或技术创新、或商业模式创新)在系统中的作用
可以在用例图中把某几个比较具有创新性的用例标上颜色,使得开发者快速定位到该用例图中的创新点。并且可以查看该创新思路在用例中的位置。同时通过创新点在用例图中的不同位置以及和其他用例的关系,可以体现出该创新点的重要性以及难度。
请使用 SCRUM 方法,选择一个用例图,编制某定旅馆开发的需求(backlog)开发计划表
id | name | importance | estimation | how to demo |
---|---|---|---|---|
1 | 账户管理 | 40 | 10 | 实现用户注册登录,修改密码等 |
2 | 酒店查询 | 60 | 20 | 通过GPS定位或者用户自主选择,查询某个区域内的酒店信息,并且实现各种查询接口,如价格区间是否有空房等 |
3 | 房间预订 | 70 | 20 | 点入酒店信息后可以进行房间预订,用户提交房间信息和入住时间等必要信息提交订单,然后交给酒店处理 |
4 | 订单管理 | 40 | 10 | 实现显示订单详情,在订单界面可以购买增值服务,或者可以取消修改订单等 |
5 | 支付功能 | 30 | 15 | 用户在下订单时需要可以选择各种付款方式,如银行卡、微信、支付宝等 |
根据任务4,参考使用用例点估算软件成本,给出项目用例点的估算
用例 | 事务 | 计算 | 原因 | UC权重 |
---|---|---|---|---|
账户管理 | 5 | 2 | 用户登陆、注册账号,获取和管理账号上的信息 | 简单 |
酒店查询 | 7 | 6 | 利用已知的酒店信息进行排序,或者用户输入关键词进行模糊查询,并且要显示酒店的各种信息 | 平均 |
房间预订 | 3 | 2 | 进行用户信息录入,创建订单 | 简单 |
订单管理 | 5 | 3 | 用户修改订单信息或取消订单 | 简单 |
支付功能 | 1 | 1 | 用户支付订单费用,调用API即可 | 简单 |