系统设计与分析(四)
简答题
1. 用例的概念
用例是软件工程或系统工程中对系统如何反应外界请求的描述,是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景,该场景说明了系统是如何和最终用户或其它系统互动,也就是谁可以用系统做什么,从而获得一个明确的业务目标。
2. 用例和场景的关系?什么是主场景或 happy path?
用例在实际执行的时候会有很多的不同情况发生,称之为用例场景;也可以说场景是用例的实例,我们在描述用例的时候要覆盖所有的用例场景,否则就有可能导致需求的遗漏。在用例规约中,场景的描述可以由基本流和备选流的组合来表示。场景既可以帮助我们防止需求的遗漏,同时也可以对后续的开发工作起到很大的帮助:开发人员必须实现所有的场景、测试人员可以根据用例场景来设计测试用例。
主场景或者happy path是指触发事件开始,逐步执行直至满足用户利益的步骤集合。
3. 用例有哪些形式?
-
Brief
简短的一段总结,通常是主要的成功场景。在早期的需求分析中,快速了解主题和范围。可能只需要几分钟来创建。
-
Casual
非正式的段落格式,包含多种场景的多个段落。 -
Fully
所有的步骤和变化都写得很详细,有支持部分,如先决条件和成功保证。在确定了许多用例并简要地编写之后
格式,然后在第一次需求研讨会上一些(这样作为10%)的重要和高价值的建筑使用案例写得很详细。
4. 对于复杂业务,为什么编制完整用例非常难?
因为对于复杂业务,设计到的场景会非常多,场景之间的相互关联也会使得用例建模变得复杂。同时,用例建模也需要对场景非常熟悉,需要对场景之间的相互关系有一定的了解,对于建模者的建模能力要求也更高,因此编制完整用例便变得非常难。
5. 什么是用例图?
用例图是指由参与者(Actor)、用例(Use Case),边界以及它们之间的关系构成的用于描述系统功能的视图。用例图(User Case)是外部用户(被称为参与者)所能观察到的系统功能的模型图。用例图是系统的蓝图。用例图呈现了一些参与者,一些用例,以及它们之间的关系,主要用于对系统、子系统或类的功能行为进行建模。
6. 用例图的基本符号与元素?
用例图的基本符号与元素包括参与者、用例、子系统、关系
参与者:表示与您的应用程序或系统进行交互的用户、组织或外部系统,常用小人表示。
用例:外部可见的系统功能,对系统提供的服务进行描述,常用椭圆表示。
子系统:用来展示系统的一部分功能,这部分功能联系紧密。
关系:包括关联<
- 关联:表示参与者与用例的关系,符号为直线,由参与者指向用例。
- 泛化:表示继承关系,符号为带箭头的直线,由子用例指向父用例。
- 包含:表示当前用例包含其他用例的功能,符号为带箭头虚线,指向被包含用例。
- 扩展:表示用例功能的延伸,符号为带箭头的虚线,指向基础用例。
7. 用例图的画法与步骤
-
确定研讨的系统
使用用例图 System框 表示一个待研究的系统
-
识别 Actors
识别使用系统的主要参与者(primary actors)/角色(roles)
识别系统依赖的外部系统
-
识别用例(服务)
识别用户级别用例(user goal level)
识别子功能级别的用例(sub function level)
-
建立 Actor 和 Use Cases 之间的关联
使用 无方向连线,表示两间之间是双向交互的协议
8. 用例图给利益相关人与开发者的价值有哪些?
-
用例图给利益相关人的价值:
用例图能够清晰地展现系统的功能与设计,能够保证系统的设计满足客户的需求,同时能够让客户参与到其中,充分与客户沟通,理解客户的需求,完善系统的功能。
-
用例图给开发者带来的价值:
用例图能够清晰地给开发者展示系统的设计过程,更加清晰地了解客户的需求,明确系统的功能与边界,进而确定软件开发的方法和迭代周期,对软件的管理和完善起到比较好的作用。
建模练习题
- 选择2-3个你熟悉的类似业务的在线服务系统(或移动 APP),如定旅馆(携程、去哪儿等)、定电影票、背单词APP等,分别绘制它们用例图。并满足以下要求:
- 请使用用户的视角,描述用户目标或系统提供的服务
- 粒度达到子用例级别,并用 include 和 exclude 关联它们
- 请用色彩标注出你认为创新(区别于竞争对手的)用例或子用例
- 尽可能识别外部系统和服务
- 然后,回答下列问题:
- 为什么相似系统的用例图是相似的?
- 如果是定旅馆业务,请对比 Asg_RH 用例图,简述如何利用不同时代、不同地区产品的用例图,展现、突出创新业务和技术
- 如何利用用例图定位创新思路(业务创新、或技术创新、或商业模式创新)在系统中的作用
- 请使用 SCRUM 方法,选择一个用例图,编制某定旅馆开发的需求(backlog)开发计划表
- 根据任务4,参考 使用用例点估算软件成本,给出项目用例点的估算
-
万达电影App
-
百词斩App
回答问题:
-
因为相似系统需要应对的场景往往都是相似的,如订票和买东西都需要支付,涉及到预定的往往都需要定位到特定的地点,这些都需要找位置,需要实现找位置的功能,这些都是必须要实现的,因此用例图往往都是相似的。
-
不同时代,不同地区的用户对酒店的需求不相同,因此随着时代的演进,可以更新酒店的评论系统和推荐系统的算法,不同地区,如宗教地区,旅游文化地区等等,可以根据地方特定增加一些适当的筛选功能。
-
若创新思路是用例图中的父节点,则创新的突破性和作用比较大,如果是被包括的用例或者是子用例,则创新性较小。
-
课上酒店用例图的backlog
Id | Name | Imp | Est |
---|---|---|---|
1 | Find hotel | 30 | 5 |
2 | Make reservation | 30 | 10 |
3 | Manage basket | 90 | 16 |
4 | Pay | 70 | 8 |
5 | Login | 80 | 16 |
- 根据用户点方法,对用例分配权重的标准是:
- 简单用例:1 到 3 个事务,权重=5
- 一般用例:4 到 7 个事务,权重=10
- 复杂用例:多于 7 个事务,权重=15
用例 | 事务 | 计算 | 原因 | UC权重 |
---|---|---|---|---|
1 Find hotel | 3 | 5 | 简单 | |
2 Make reservation | 5 | 10 | 一般 | |
3 Manage basket | 5 | 7 | 一般 | |
4 Pay | 2 | 5 | 简单 | |
5 Login | 4 | 8 | 一般 |