- 用例的概念
用例是一系列描述用户使用系统实某种目的时成功或失败的场景的集合,它使用文字表示,而不是图表 - 用例和场景的关系?什么是主场景或 happy path?
一个场景是一系列用户和系统间动作和会话的合集,是用例的一个实例;
一个用例代表一系列场景的集合,其中包括主场景和一个/多个可选的替代场景;
主场景是主要的系统交互,常常是成功的场景(而不是失败的场景);Happy Path 是一个无异常或无错的默认场景; - 用例有哪些形式?
- Brief:是一段总结概括,并且经常是描述主要成功场景的;在早起需求分析中,为了获取对主体和范围的快速认知,通常用几分钟来构建简洁用例
- Casual:非正式的多段文本,可以涵盖多个场景
- Fully:所有步骤和变化都有详细描述,并且有包括先决条件、成功保证等支持部分
- 对于复杂业务,为什么编制完整用例非常难?
复杂业务的场景多且复杂,并且其间关系复杂,编制用例时难以涵盖全部场景;
对于单个场景,也难以考虑到所有的用户-系统的交互情况;
因此对于复杂业务编制完整用例非常困难 - 什么是用例图?
用例图是指由参与者、用例、(系统)边界以及上述要素之间的关系构成的图,可以描述系统的功能,可以为actor提供指南,告诉actor这个系统能够提供什么服务 - 用例图的基本符号与元素?
用例图基本元素包括:- actor(参与者)
- system(系统)
- use case(用例)
- relationship(关系)
- actor(参与者)
- 用例图的画法与步骤
- 确定系统(研究对象)
使用上面说到的system框表示我们要研究的系统,并给它取名 - 确定actor
确定使用系统的用户,放在系统框左边;
确定系统依赖的第三方系统(外部系统),然后放在系统框的右边 - 确定用例
确定用户级别用例,并画在系统框里面
确定子功能级别用例(用户用例下包含的操作),并画在系统框里面
确定用户用例与子用例之间的关系(include、extend,其中include由用户用例指向子用例,必须实现,extend由子用例指向用户用例,可选择实现),并用上面说的关系连线连接 - 确定参与者actor与用例之间的关系
确认参与者actor与用例之间关系后,使用无箭头的实现连接参与者与用例
- 确定系统(研究对象)
- 用例图给利益相关人与开发者的价值有哪些?
- 用例图描述了系统功能、需求范围,一来明确业务范围(方便开发人员理解),二来明确功能范围(便于用户理解)
- 给出了明确而持续的指导,指导开发人员这个系统应该能够做什么,应该实现什么功能,哪些功能是可选的
- 帮助评估工作量
建模练习题(用例模型)
-
选择2-3个你熟悉的类似业务的在线服务系统(或移动 APP),如(携程、去哪儿等)、定电影票、背单词APP等,分别绘制它们用例图。并满足以下要求:
-
请使用用户的视角,描述用户目标或系统提供的服务;
-
粒度达到子用例级别,并用 include 和 exclude 关联它们;
-
请用色彩标注出你认为创新(区别于竞争对手的)用例或子用例;
-
尽可能识别外部系统和服务;
答:
- 旅馆订票系统用例图
- 外卖订餐系统用例图
-
[UML]UML系列——用例图中的各种关系(include、extend) - wolfy - 博客园 (cnblogs.com)