你的UML第一张图是用例图么？（2）——从活动图到用例图

叁歲伎倆 2022-08-03 05:05 118阅读 0赞

前言：

之前已经说过如果是我我会选择第一张UML图是活动图，事实上，通过这种方式能够更好的帮助我们分析用例，因为用例涵盖过程和工作流分析，所以活动图能够成为用例的有用的辅助措施，对于复杂工作流的业务来说更是如此，所以笔者的机房合作就是把活动图的每一个活动作为一个用例的候选，下面可以看一下转换流程。

# 一、用例到底是什么 #

一个用例其实可以分成两种不同的意义：一个意义是从用户的角度出发；另一个意义则是从系统的角度去看。从用户角度出发，我们可以发现每一个用例所代表的都是用户对于系统的一个期待，一般来说，我们把这样的期待当成是用户进入系统的一个请求，用属于方式来说，就是一个用户目标。所以看一些比较老的电子书都会说每一个用力都是一个用户目标，这就是从用户观点去思考用例，从这个观点来说，用户通常都是非常明确的。但是从系统的角度，则又又有另外一个不同的想法，系统所看到的每一个用例，其实代表的是系统所提供的某种服务，这个服务是由系统内部的诸多程序（现在我们通常称为对象）通力协作共同提供的，所以基于系统会把重点放在服务本身上面，去在乎到底哪一个用户来使用这个服务。

事实上，笔者认为，这两个观点互为表里，只是很多书籍会有一些侧重，所以一个真正的软件设计者必须同时从“用户角度”及“系统角度”分别思考。

# 二、四个问题解决“用户角度”“系统思考”双重思考 #

我在最上面说过，每一个活动作为一个用例的候选，那如何从系统角度和用户角度从活动里面找出用例呢？

四个问题：

1.在这个活动中，谁是主要工人？

2.这个活动进行中，需要系统提供的服务么？

3.系统需要提供什么服务？

4.系统需要其他信息系统支持么？

笔者是自己列了一个表格，把自己的活动进行筛选。如下图：

![Center][]

上面的图只是我分析的一部分，但是大家可以清晰的看到，比如上交费用这个活动，系统是不提供服务的，这要我们就可以进行筛选我们的用例，根据系统需要的服务进行选择用例，用例图如下：

![Center 1][]