聊聊UML用例图
Posted 与小婧同行
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了聊聊UML用例图相关的知识，希望对你有一定的参考价值。
用例，它是：
面向对象软件过程的骨架——开发过程中一切工作的组织框架；
面向对象软件过程的神经系统——用例驱动过程；
面向对象软件过程的血肉——需求的来源，测试的依据……
——大象 Thinking in UML
为了让我们能把天聊下去，我先来说明一些关于用例图的术语。
1Actor 执行者/参与者
在用例图中一般用火柴人表示，是指用例的执行者。
参与者并不一定是系统的用户，它们可能是外部系统、外部机构、外部设备和其它与系统有交互的任何外部实体。
我们可能会在很多书上或者教案上看到有会有“主要参与者”和“次要参与者”之说。
主要参与者就是驱动用例的人，没这个人用例就没办法执行，大部分都是人。
次要参与者大部分情况下是系统，比如数据转换系统，如果没有这个系统，人为的也可以转换，而且数据转换系统工作的前提也是人去执行了某个用例。
其实吧，在实际的应用过程中，我觉得对于我们做需求来说，不用分的那么细。
至少我目前使用到现在都没有分过那么细。
因为我们主要还是接触到业务端的用例，最多到系统用例，没有到设计层面。
大部分情况下，我们使用的都是“主要参与者”。
当你要去分析接口之类的，可能会使用到“次要参与者”。
题外话：分析接口，我一般会使用数据流图、上下文图，所以这也许是我不会使用到“次要参与者”的一部分原因吧。
2UseCase用例
用例在用例图中用一个椭圆表示，椭圆里面用“动宾”结构进行命名。
A UseCase is a specification of behavior.
用例是一种行为。
用例至少有一个执行者，必须在边界内。
用例最容易出问题的地方有两个：粒度、关系。
粒度的部分我在接下来的用例层级的部分会聊到。
关系是指用例和用例之间的关系。
用例和用例之间的关系只有：继承、扩展、包含。
用例和用例之间没有时序关系，没有判断关系！！！
Generalization继承/泛化
用例中的继承关系很简单。
可以发生在参与者和参与者之间，也可以发生在用例和用例之间。
不能发生在参与者和用例之间。
娃继承了爹妈的长相，但是娃又可以自己存在一些与他们长相不同的部分，比如基因突变。
父母都是大眼睛、塌鼻梁，那么宝宝是大眼睛（这是继承）、高鼻梁（这是属于宝宝自己的属性，没有继承父母的属性）。
当然，这是一个不恰当的例子，也是一个没有抽象过的现实中的例子。
实际上呢，继承的概念其实与抽象有关系。
比如授课老师、班主任都可以抽象为老师，老师、学生都可以抽象为人……
至于要怎么抽象，抽象到什么粒度，其实和你需要分析和建立的模型有很大关系。
Extend扩展
Extend is intended to be used when there is some additional behavior that should be added, possibly conditionally, to the behavior defined in one or more UseCases.
扩展可以理解为是一种功能的增强或者分支情况。
在大部分情况下，执行者是执行主用例的，但是一些特殊情况下被执行的用例就成为扩展用例。
比如，学生选课的例外情况就是没选完课就退出了。
这个扩展用例后续在分析和实现的时候需要考虑包括：之前填写的信息是否需要保存，是否需要提示学生等等。
Include包含
The Include relationship is intended to be used when there are common parts of the behavior of two or more UseCases.
我觉得包含的最大的意义和作用在于复用。
如果你觉得一个用例的子用例会被其他的执行者或者用例复用，那么就把这个用例单独抽象出来，和主用例形成包含的关系。
简单举个我在《聊聊UML（2）关于面向对象》的洗漱的例子。
我们将“洗漱”从“起床”这个用例中抽离出来，其主要目的是有一个“睡觉”的用例也需要有“洗漱”这个用例。
于是“洗漱”被复用了。
3Subject边界
在用例图中会有个方框，把用例框在里面，把执行者框在外面。
当然，有的用例图不仅仅只有一个方框，特别是把各个系统的用例画在一张图上的时候。
所以用例图有一个非常重要的作用，确定边界。
有人问，用上下文图也可以确定边界啊，为什么要用用例图。
我个人觉得，分析的角度不一样。
用例图的分析是场景化的分析，什么Actor会执行什么UseCase。
上下文图分析是数据分析，系统间的数据来往。
根据OMG的官方定义，我们可以知道用例图主要是用来做需求捕获的。
UseCases are a means to capture the requirements of systems, i.e., what systems are supposed to do.
但是在实际的应用过程中，和其他的UML模型一样，用例是可以分层的。
这个分层倒不是说父用例、子用例之类的。
而是在不同的阶段应用用例图，会有不同的层级粒度效果。
1业务用例
在项目的初始阶段，或者说我们在前期进行需求捕获或者调研的时候，会发现我们绘制的用例图大都是业务层面的，也是我们常说的业务用例。
其实就是将用户讲述的工作，用用例图画出来。
最常见的问题是：您平时的主要工作事项有哪些？
注意：业务用例是那种即便脱离了系统也能正常运行的用例。
我以前经常犯的错误是，过早的用技术解决方案去描述和理解用户需求。
换句话说，可能在还没搞清楚客户的业务场景和习惯、问题的时候，我已经想到“嗯，这样用一个下载的功能就可以了……”
然后，我就陷入了思维的圈圈里，一心一意的想要去做下载。
但是其实在我绕了很多的圈子后，发现其实在页面展示，外加数据接口的解决方案会比下载更合适。
这是经历过无数的需求变更后才发现的。
所以，在这个层级，在需求调研和捕获的阶段最常用的是“业务用例”。
你用用例图将业务用户和用例识别出来，这是关键。
2概念用例
如果说“业务用例”是现实世界的描述，那么“概念用例”就是虚拟世界的第一层抽象。
我们用“业务用例”描述的内容，很多是没有经过分析的。
在分析过后，我们可能会觉得有些用户是可以抽象成一个角色的。
比如我们在做学生选课系统调研的时候，调研了任课老师、班主任、助教、教务主任等等。
在做业务用例的时候，我们会将这些人都作为执行者。
但是到了概念用例的时候，我们会发现，班主任与任课老师的用例有重合。
于是我们可以定义执行者的继承关系。
但是，并不是所有的情况都要使用概念用例的。
对于一些业务领域规模不是很庞大，业务交叉复杂的情况才会使用概念模型。
在某种程度上来说，概念用例起到的作用是承上启下，为了通过业务用例得到系统用例而产生的中间过渡。
3系统用例
就像我上面提到的那样，如果你的业务不是那么的复杂，你可以直接从业务用例分析得到系统用例。
从业务层面到概念层面再到系统层面，我们需要通过其他的一些模型来进行分析、验证和优化。
最常用到的其实是我们后面会提到的“活动图”。
因为每个业务用例都需要在活动图中有所反映，每个执行者也需要在活动图中有所对应。
否则，就会出现矛盾的情况。
比如你的活动图中只有老师、学生、管理员三个角色，但是用例图中出现了授课老师、班主任等等执行者。
非常明显的表明了这两者的不一致，要么是其中一种图中的描述有问题，要么就是两者都有问题。
系统用例的出现，也表明我们的用例分析已经从问题域抵达解决方案域了。
所以你在系统用例中会看到很多的功能性的用例，掺杂了技术的描述。
上面这张用例图来自于OMG的UML2.5说明，发现神奇的事情是在这里标注了“多重性”，就是线上面的数字。这个数字之前在“类图”中见到过，后面我们也会在“类图”中详细聊。不知道这是不是UML2.5的一个变化点。
我不清楚有多少小伙伴听过这种开发模式的。
我记得曾经有一段时间这种模式非常火，有一本书叫做《实例化需求》就是关于这种方法的。
用例驱动开发，并不是画用例图就结束了，而是写系统用例。
当用例建模到了系统用例的层级，会需要写用例。
很多书中有给出用例的一个模板，我在网上找了一个模板。
用例驱动开发的过程就是BA拿用例当做需求规格SRS、FS、PRD。
开发和测试就拿着这个用例来进行开发和测试。
有小伙伴建议我去开个收费的课程，表示愿意付费来跟着我一起学习UML。
我想了一下，还是决定在这里免费和大家聊聊UML的信息。
一是因为我只是知识点的总结和转化，并没有对你们有实践的指导。
二是因为我觉得好像收多少钱都不大合适。
如果你觉得有帮助，可以给我打赏。
如果你有进一步的问题，可以扫下面分答的二维码来咨询。
建议大家尽量把问题描述具体一些，谢谢！
小婧是一名行走在实践路上的资深业务分析师（BA），如果想与我同行，就请关注我吧！
以上是关于聊聊UML用例图的主要内容，如果未能解决你的问题，请参考以下文章