第2篇 | 用例图怎么画?历年真题告诉你考什么、怎么考

四季读书网 1 0
第2篇 | 用例图怎么画?历年真题告诉你考什么、怎么考

上篇我们搞清楚了用例图的三个组成部分——参与者、用例、边界框。但这才是入门级别的知识。考试真正拉分的地方,在于用例之间的关系,在于你怎么判断一道题到底在考什么。

这篇文章,把关系讲透,把真题讲穿,再给你一个考试能直接用的口诀。

用例之间的关系:Include、Extend、泛化

用例图里,用例和用例之间可以有关系。这种关系有三种类型,考试几乎每次都考。

第一种:包含关系(Include)

什么时候用Include?当一个用例A的执行,必须有另一个用例B的内容参与,而且B是A不可缺少的一部分。

举例子:顾客"下单"用例,一定包含"支付"用例——没有支付,下单就不完整。反过来"支付"可以单独存在,但"下单"离不开"支付"。

画法:虚线箭头,从A指向B,箭头上面标注《include》。

注意Include的特点:A一定需要B,B不一定需要A,而且包含关系是强制性的。

第二种:扩展关系(Extend)

什么时候用Extend?当一个用例A,在某些特定条件下,会表现出额外的行为B,B是A的扩展,但不是A的核心部分。

听起来有点绕,还是用例子理解:

"登录"用例,在"密码错误"这个特定条件下,会扩展出"找回密码"用例。"找回密码"不是每次登录都会发生的,它只在特定条件下才出现,平时不存在。

画法:虚线箭头,从B指向A(跟Include相反),箭头上面标注《extend》。

注意Extend的特点:扩展用例B是在特定条件下才插入A的,正常流程里B不存在。而且《extend》里面写的是扩展条件,不是B做了什么。

第三种:泛化关系(Generalization)

这是最容易理解的一种,就是"继承"。

当多个用例有共同的特征,可以抽象出一个父用例,子用例继承父用例的所有行为,同时可以有自己独特的地方。

例子:"登录"可以泛化为"账号密码登录"和"手机验证码登录"两个子用例。它们都是登录,共享登录的基本逻辑,但各有各的具体方式。

画法:实线空心箭头,从子用例指向父用例。

泛化关系在考试里通常不单独作为难点考查,一般作为参与者继承的考法出现——比如"管理员"和"普通用户"都继承自"用户"参与者。

[!ILLUSTRATION] 配图建议:三种用例关系对比图(Include/Extend/泛化)

Include 和 Extend 怎么区分?考试最常踩的坑

这个是高频丢分点,必须专门说。

核心判断方法:先问自己——这个行为是A必需的吗?

  • 是必需的,没有它A就不完整 → Include
  • 不是必需的,只是A在某些情况下的一种处理方式 → Extend

再用一个生活例子对比理解:

Include例子:你去餐厅吃饭,"点餐"一定包含"付款"——付款是点餐不可缺少的部分,付款失败,点餐就不算完成。

Extend例子:你在ATM取钱,"取款"在"余额不足"的时候会扩展出"打印凭条"——余额充足的时候不需要这个行为,它只是某种情况下的额外处理。

考试如果给你一个场景,让你判断是Include还是Extend,你就用这个标准套:

A必须有B才能完成 → IncludeB只是A在某些条件下才需要 → Extend

[!ILLUSTRATION] 配图建议:Include vs Extend 考试真题场景对比图

历年真题实战:这些坑你踩过几个?

【2020年选择题】以下关于UML用例图的描述,正确的是: A. 用例图描述的是系统的动态行为 B. 参与者位于系统边界框之内 C. 用例之间的关系包括包含、扩展和泛化 D. 用例图必须包含所有的系统参与者

答案:C

A错,用例图描述的是系统的功能需求,是静态结构,不是动态行为(那是状态图和活动图的事)。 B错,参与者一定在系统边界框外面,在里面的是用例不是参与者。 D错,用例图不需要包含所有参与者,只画跟系统功能相关的核心参与者。

【2021年选择题】在影院管理系统中,观众可以网上购票和现场购票,退票只能在网购票的情况下发生。以下关于用例图的说法,正确的是: A. 购票和退票之间是Include关系 B. 退票和购票之间是Extend关系 C. 网上购票和现场购票之间是Extend关系 D. 以上都不对

答案:B

退票是在网购票这个特定条件下才发生的额外行为(现场购票不能退),所以退票扩展自购票,是Extend关系。网上购票和现场购票都继承了购票,是泛化关系,但题目问的是退票和购票的关系,退票是在"网购票+退票权限"这个条件下才触发的,所以是Extend。

知识串讲:用例图和需求管理的关系

用例图是需求工程的重要输出,但它不是一个人埋头画的。

在PMBOK里,需求管理贯穿整个项目生命周期:需求获取→需求分析→需求规格说明→需求验证。用例图主要服务于"需求获取"和"需求规格说明"这两个环节——它用图形化的方式,把系统功能需求整理成"谁用系统做什么"的形式,让开发方和用户方都能看懂。

在软考里,用例图常常和范围管理里的WBS放在一起对比出题:WBS分解的是交付成果,描述的是"做什么";用例图描述的是用户视角的功能,描述的是"谁用、干什么"。 两者互补,不是替代关系。

一句话口诀

口诀:用例图里框外是人,框内是功能,包含必有,扩展可选

解析:参与者一定在边界框外面,用例一定在框里面。"包含(include)"是说这个子功能不可缺少,"扩展(extend)"是说在特定条件下才出现。考试看到这个口诀对应的场景,直接判断是Include还是Extend。


正在备考软考高项?持续关注,持续更新,系统化搞定UML用例图 🚀

抱歉,评论功能暂时关闭!