回复网友xiaobai1023的用例分析问题

网友xiaobai1023：

谭老师，你好：
我有这样一个需求：
通过调度框架如（quartz）定时去执行一些动作，动作的内容是去取一些“原始数据”可能是一些文件，也有可能是通过socket向第三方系统发送一条命令得到的数据，将得到的这些原始数据通过一些数据的映射、转换组装成我的上层系统中的值对象上传。
可能是需求简单的缘故，本身实践UML的时间也不长，产生了如下疑问，希望您能帮助解答一下，谢谢。
1、我刚开始把我的系统使用者作为业务主角去分析获取他的用例，但是发现从他的身上得到的用例只有两个：控制调度、配置“原始数据”和上层系统的值对象的对于关系，其中控制调度包括配置和启、停调度，后来又觉得作为业务用例的话我的业务主角只有一个业务用例那就是 采集数据，但是后来发现不管从哪个业务用例出发，到了系统用例的时候却依然还是那些用例，有些迷茫了，可能是我的角度没有站对吧。
2、系统中的调度框我老是觉得有些系统用例是由他发出来的，按照老师书中所讲的他应该是一个 业务工人，不是业务主角，但是这样的话就觉得有些用例没有了发出者~
目前就是这样，望能解惑，谢谢。

我的回复：

获取用例最重要的就是先明确边界。一旦边界确定下来，边界外的就是参与者，边界内的就是用例。
在你这个例子里，由于并不是非行业服务软件，都是在计算机系统内的功能，如何确定什么是业务用例，什么是系统用例呢？其实不论是服务软件还是系统软件，业务用例要说明的问题仍然是一个完整且独立的“业务”目标。系统用例要说明的问题仍然是系统做什么来满足这个目标。
就以这个例子来说，从你的需求描述：“通过调度框架如（quartz）定时去执行一些动作，动作的内容是去取一些“原始数据”可能是一些文件，也有可能是通过socket向第三方系统发送一条命令得到的数据，将得到的这些原始数据通过一些数据的映射、转换组装成我的上层系统中的值对象上传。”中可以看到一些动作，比方取原始数据，向第三方发命令，软换数据，上传等。显然它们可以作为备选用例，但它们是业务用例还是系统用例呢？
通过这些的问题来帮助确定：
1.谁使用这个用例？
2.用例能帮助actor完成什么目的？
3.这个用例是完备的吗？
4.这个用例是独立的吗？
如果满足，上述四个问题，那么用例可以作为业务用例，否则它就不是。比方，取原始数据，这个用例似乎就不是一个完备的用例。取了数据有什么用？如果取来了就不再做任何处理，取数据的意义何在呢？ 再比如转换数据，这个用例很可能不是一个独立的用例，它很可能与取数据是绑定在一起的，在取数过程中或取数据结束后马上执行这个用例。。。。
经过这些分析，我们会发现上述用例似乎都不是业务用例。那么业务用例在哪里？出现这个问题要考虑一下是否我们的边界选择有问题了，我们站在了系统内部来寻找业务用例。现在，我们试着把边界扩大一些，把刚才的所需求描述作为一个黑盒子，假设我们不知道框架，不知道数据映射，也不知道什么第三方系统。这时，黑盒子提供的价值是什么？采集数据？上传数据？转换数据？
同样再四个问题去问它们。假设有一个系统A作为actor，它向黑盒子提出的要求可能是：
a:采集我需要的数据并转换成相应的格式再返回给我；
b:帮助我把数据转换成相应的格式并上传到另一个系统B；
c:....
以a,b为例，以4个问题去问时，好象就能得到满意的答案了。业务用例可以归纳为：采集数据并转换格式；转换数据格式并上传。注意，如果把采集数据和转换格式分成两个用例，对系统A来说就不完整了，A需要的是采集并转换，而不是单独的转换。
这两个业务用例看上去有点怪，我们做一点加工，根据问题a,把转换格式作为采集数据的一个include，根据问题b,上传才是真正目的，因此把数据转换也作为上传的一个include。 好，再在我们得到两个业务用例：采集数据和上传数据，它们都include了转换数据格式这样一个辅助业务用例。这两个业务用例都有使用者，帮助使用者完成了一个明确的目的，并且是独立的。

接下来，你所提到的需求就可以派上用场：我们需要为业务用例描述业务用例场景来说明用例如何满足需求。在这个描述过程中，很显然的，在数据采集的场景中一定会提到取“原始数据”，向第三方发数据请求命令等；上传会提到数据组装等工作；而转换数据格式也会提到数据映射，转换等。
经过这一步工作，需求和业务目标有了结合。重要的是你知道了业务用例在需求的哪个阶段发生作用，承担什么职责。
在考虑如何实现这些需求时，比如取原始数据时，谁发出命令？我们可以写个定时器，可以写个按钮让人去按。最终，我们选择了一个调度框架，由它来发出命令。于是，调度框架在实现需求时承担了命令发出者的角色，也就是说它成为了一取数据这一系统用例的动作发出者。这样，调试框架就作为一个业务工人出现在数据采集业务用例场景当中；并且，当我们分析到系统层面时，它是取数据系统用例的一个actor。

最后，你说“但是后来发现不管从哪个业务用例出发，到了系统用例的时候却依然还是那些用例，有些迷茫了”,关键是你在发现和分析用例时思路还没有理清楚，因此对结果不自信。我上述的分析结果未必是正确的，因为我不太了解需求。但是思路应当是可以供你参考的。