一、简答题
-
用例的概念
答:用例是一系列文本形式的成功或失败方法描述,用以说明参与者使用系统实现的某些目的,通过描述用户使用系统的情节来发现和记录功能性需求。
-
用例和场景的关系?什么是主场景或 happy path?
答:用例是相关的成功或失败场景的集合,用来描述参与者使用系统实现的某些目标;场景是用例实例,是参与者和系统之间的一系列特定的活动和会话。主场景或happy path代表主要的系统交互,通常是成功场景。
-
用例有哪些形式?
答:有三种形式,Brief(high level)、Casual(简便格式)、Fully。
-
对于复杂业务,为什么编制完整用例非常难?
答:复制业务往往包含很多的场景,各场景之间的各种关联会使得用例非常复杂,并且用例的编写者需要对这些场景流程有充分的了解,因此编制完整用例非常困难。
-
什么是用例图?
答:用例图是由参与者(Actor)、用例(Use Case),系统边界和他们之间的关系构成的用于描述系统功能的视图,是从参与者视角所能观察到的系统功能模型图。
-
用例图的基本符号与元素?
答:
基本元素:有参与者、用例、系统边界和关系箭头(包括关联关系,包含关系,扩展关系和泛化关系)。
基本符号:
-
关联关系:实线连线
-
泛化关系:空心三角虚线
-
包含关系:<<include>>
-
扩展关系:<<extends>>
-
-
用例图的画法与步骤
答:
-
绘制系统(System)边界,确定Subject(业务、软件系统、子系统、组件和设备等)
-
确定参与者(Actor)(画在系统边界左侧)
-
考虑系统功能的使用者、支持者及其他相关对象
-
确定参与者之间的泛化关系,使用泛化关系箭头连线
-
-
定义用例(Use cases)(系统边界内)
-
动词开头描述场景
-
-
确定用例之间和用例与参与者之间的关系
-
关联关系:使用实线相连
-
包含关系:客户用例和提供者用例之间用《include》箭头相连
-
扩展关系:基础用例和扩展用例之间用《extends》箭头相连
-
泛化关系:子用例与父用例之间用泛化箭头相连
-
-
-
用例图给利益相关人与开发者的价值有哪些?
答:
-
明确系统的业务范围、服务对象(角色)、外部系统与设备
-
帮助识别技术风险,提前实施关键技术原型公关与学习
-
易于评估项目工作量,合理规划迭代周期,规划人力需要
-
二、建模练习题
-
选择2-3个你熟悉的类似业务的在线服务系统(或移动 APP),如定旅馆(携程、去哪儿等)、定电影票、背单词APP等,分别绘制它们用例图。并满足以下要求:
-
请使用用户的视角,描述用户目标或系统提供的服务
-
粒度达到子用例级别,并用 include 和 exclude 关联它们
-
请用色彩标注出你认为创新(区别于竞争对手的)用例或子用例
-
尽可能识别外部系统和服务
-
扇贝单词:
百词斩:
-
然后,回答下列问题:
-
为什么相似系统的用例图是相似的?
因为相似系统的用户人群大致相同,需求大致相同,所以参与者和用例,参与者和用例之间以及用例和用例之间的关系都会很相似。
-
如果是定旅馆业务,请对比 Asg_RH 用例图,简述如何利用不同时代、不同地区产品的用例图,展现、突出创新业务和技术
并非定酒馆业务。但不同时代、不同地区用户对细节上的需求是不同的,Asg_RH用例图只设计了用户的基本需求,新时代的软件则在这部分需求上进行了创新和设计。下图比较就可以明显看出新时代的用例图体现出更丰富的需求。
-
如何利用用例图定位创新思路(业务创新、或技术创新、或商业模式创新)在系统中的作用
通过将用例的背景颜色设置为高亮,可以快速定位到系统的创新点。
-
请使用 SCRUM 方法,选择一个用例图,编制某定旅馆开发的需求(backlog)开发计划表
ID Name Imp Est How to demo 1 查询酒店 60 30 根据时间、位置等信息进行查询 2 账户管理 20 10 用户登陆/注册账号,管理用户信息 3 预订酒店 40 25 选择房间数量和类型 4 管理订单 20 10 可以更改或取消订单 5 支付 30 20 可通过外部api进行支付 -
根据任务4,参考 使用用例点估算软件成本,给出项目用例点的估算
用例 事务 计算 原因 UC 权重 查询酒店 10 6 通过多种方式筛选旅馆,保留用户心仪的旅馆 平均 账户管理 4 2 用户登录、注册,获取并管理用户信息 简单 选择房间 4 2 根据房间信息进行选择 简单 管理订单 3 3 修改、取消 简单 支付 5 3 调用外部api 简单
-