UML用例图在线视频

嗨，大家好

今天我们一起讨论用例图

当我们说用例图的时候，一般指的是用例分析技
术

而不单单是那个简单的有个小人和小饼的图

首先我们要明确用例分析技术是一个

比UML标准大11岁的需求分析技术

后来被伊万•雅各布森引入了UML才得以流行

用例分析技术是通过用例以及用例描述

参与者以及用例之间的关系来描述系统功能性需
求的一种方法

它的目的是让各种元素的交互变的可视化

用例图在软件开发的各个环节都有着十分重要的
指导意义

因此，我们要尽可能做好用例分析，为后面的软
件开发活动打好基础

免得失之毫厘差之千里

一个用例图的基本构成很简单，首先要确定的是
系统的边界

只有确定了系统边界，我们才能够正确的确定参
与者和用例

否则原本的参与者可能因为边界的错误判断

而进入系统的内部，反而成了一个用例

用例表示的是一个用户的目标

它代表的是系统可以提供的服务

参与者之间常用的关系是泛化

就是一个参与者派生出更具体的其他的参与者

这里需要多说一点的就是用例之间的关系

关系分为4种，一般的关联关系，包含关系，扩展
关系

还有刚才我们提到的泛化关系

包含关系最经典的应用就是复用

有时候某个用例的事件流过于复杂

为了简化用例的描述

我们就把某一段事件流抽出来形成一个被包含的
用例

或者相反，这些用例划分的太细了，抽象出来一
个基本用例

叫基用例，来包含这些细颗粒的用例

那什么是扩展关系呢？扩展用例就是将基用例中
的一段

相对独立的并且可选的动作，用扩展用例把它封
装起来

再让它从基用例中声明的扩展点上进行扩展

从而使基用例行为更加简练，目标更加集中

扩展用例为基用例添加了新的行为

打开用例这个黑盒子，里面对应着这个用例的业
务描述

在用例描述里，我们需要写清楚

这个用例的前置条件和后置条件

表明这个用例在执行前和执行后系统的可观测的
状态

然后需要把常规的业务场景描述出来

还需要把异常的情况和可选择的分支流程表达出
来

初学者往往比较重视画图，而没有意识把用例这
个黑盒子打开

看看这个里面有什么细节

当然这个用例描述不是自己跑到用例里面去的

而是需要分析人员把需求分析整理出来，还原业
务场景

虽然用例描述很重要

但只有合理的抽象出用例，用例关系全面涵盖业
务流程之后

才能进一步细化出用例描述

因此，对用例的正确理解和把握就变得十分重要

从本质上说，用例是参与者使用系统的目标

这个目标是通过一系列的动作组合而成

目标的达成是可观测的和有意义的

因此，你不能把点击鼠标这个小动作当做一个用
例

有时候为了便于表达，可以把用例图分层

大粒度的用例表明用户的目标是一个概要级别的

中等粒度的用例是目标级别的

小粒度的用例是子功能级别的

要想画出用例图，在确定系统边界之后

需要仔细斟酌的就是如何从需求描述中抽象出真
正的参与者

比如，客户通过给机票代理公司打电话

要求定机票，那么对机票预订系统来说

客户是参与者么？

还有，需求中要求系统晚上12点自动打印出业务
报表

那谁是参与者呢？

当我们识别参与者感到困难的时候

可以通过问问题的方法来让这些参与者逐步浮出
水面

常问的问题包括：谁使用这个系统

如果有不同的角色使用不同的系统功能

那我们一下子就可以识别出一大部分的参与者

下一个好问题就是：系统需要与哪些系统交互

从而可以识别出有哪些外部系统

和我们的系统相关联，它们也是典型的参与者

识别出来了参与者之后，跟着参与者顺藤摸瓜

可以先识别出和参与者直接相邻的这些用例

然后判断这个用例是不是可以扩展或者包含了其
他用例

当你感到识别困难的时候，还是可以问一些典型
的问题

比如问，系统提供哪些功能？

参与者和系统之间的交互有哪些？

有哪些信息需要读取、删除或者修改？

识别参与者，识别用例，包含分析设计时识别对
象

这些都是很抽象的工作

需要经过充分的训练才能较好的完成这个任务

识别出来用例之后，需要给用例一个合适的名字

用例的名字和参与者的名字合在一起

其实正好构成一句话：谁干了什么

也就是说，参与者是名词，是主角，用例是动宾
短语

合在一起就构成一个完整的语义

有时候为了便于理解，我们可以用被动词来表示
是系统在控制流程

而不是参与者在控制流程

需要注意的是，当用例图的元素无法简洁的表达
你的想法的时候

就可以把这些更具体的分析转移到用例内部

也就是放到用例描述里面去

当我们初步完成用例图的编写之后，要注意进行
适当的迭代

对过大的用例分解成更小的用例

合理使用扩展关系和包含关系

对那些粒度过细的用例要大胆进行合并

从而让用例图变得更加合理

作为这部分的小结，我们看一下如何学习用例分
析技术

和其他软件工程的规则一样

用例分析技术的学习过程也可以分成“守破离”三
个阶段

守，就是苦练基本功，老老实实按照要求，一招
一式，像模像样

破，就是经过充足的训练之后

逐渐不再局限于死的规则，变得灵活起来

最后就是离，到了这个阶段，不再记忆任何规则

这些规则都已经深入骨髓了，化为无形

对任何一个需求的分析都是最优的

一般来说，我们在做分析需求的时候可以采用这
样的顺序

首先根据需求画出简单的用例图

对每个用例补充它的用例描述，具体怎么补充

可以使用活动图，流程图或者任何你觉得可以使
用的工具

补充了用例描述，你就会发现自己对需求的理解
更深入了

这时候回过头去看一看原来设计的用例图

你就会有不满意的地方

对这些地方展开重构，拆分或整合用例

补充或者是调整新的用例描述

如此这般几次迭代之后

你就会得到一个相对完美的分析结果

好，UML用例图我们就说到这儿，谢谢大家