[全程建模]业务用例与用例的对应关系解析

下文中是关于业务用例和用例之间的对应关系的对话，一般来说在一些较大的业务系统或者业务逻辑较为复杂的系统开发中才需要进行单独的业务建模过程，而对于大多数业务系统是不需要单独进行这样的开发阶段的。

在每次的全程建模的培训中，青润都会提出这个过程将业务建模过程进行详细的分解，但是在《软件工程之全程建模实现》一书中对业务建模并没有进行深入的阐述。

下文中的系统用例在青润的定义中一般就称之为用例，而系统用例这个名词用于非业务性相关用例的命名，比如用户管理，码表分类定义/管理之类的非用户原有业务需求产生的用例上，或者称之为支撑业务用例而不得不构建的用例被称之为系统用例。所以在这里单独进行明确，以便于大家的区分。

业务用例和用例的对应关系一般是1对1和1对多最为普遍，但是也可能出现多对1的形式，甚至一些用户业务间交叉过多的业务实现中还可能出现多对1的形式。比如下面这个例子就是2003年底在北航给软工硕士讲课期间产生的一张图，此图的模型也在《软件工程之全程建模实现》一书的光盘中可以找到：

下面是相关的对话内容，有助于对以上内容的进一步理解。

 

缘，妙不可言  21:32:59

UML中，我本来认为业务用例和系统用例的关系是一对多，因为系统用例是从业务用例场景中推导出来的。可是后来被淘宝的面试官反驳了。我反复思考后现在认为：业务用例和系统用例只是有用例粒度上的区别，即不同抽象层次上的，并不存在所谓的1对多关系。而且一个业务用例对象可以有不同的场景实例，所以某个业务用例场景只是该业务用例对象的某个方面而已，自然从该业务用例场景中推导出的系统用例和该业务用例不会是1对多关系。

   我觉得我的理解应该还有不对的地方，请本群的UML大牛--青润，给予指导，其他群友也一起参与讨论下吧

青润  21:46:02

呵呵，这两者的关系，我那本书里做了详细的阐述。

基本上可以认为是粒度的问题，但是，也可能出现一些业务用例在确定了其业务范畴之后认为可以另外一个或者多个业务用例合并成为一个系统用例，所以，两者不是简单的1vn的关系，应该是n v m的关系更合适。

缘，妙不可言  21:48:30

多个业务用例合并成为一个系统用例 ？？

青润  21:48:50

对，你肯定是没有遇到过，实际系统中会有这种特殊情况出现的，呵呵。

缘，妙不可言  21:49:04

应该是不同业务用例场景中推导出的系统用例合并为一个吧

青润  21:51:05

在一些特殊业务系统的开发中，有可能出现这种情况，比如，抽取出来的公用子流部分，完全可能进行子流的合并开发，实现系统的快速搭建和原型展示，这时候和用例业务场景没有关系，呵呵，当然也有特殊的业务系统在实际开发中会出现合并的问题，比如你前期业务用例划分过细，或者用户方曾经进行过一些业务流程的制度性分割造成的结果，你想想吧，肯定能想明白。

缘，妙不可言  21:52:39

太深了，大象那书里是说 对象必须从多个场景中分析出来，每个场景只是该对象映射到该处的一个方面，所有名词，包括用例也是对象，他的分析方法和概念类对象一样

青润  21:53:47

呵呵，这么说没有大的错误，只是考虑的业务环境不够完整，经历的业务系统多了，自然会遇到各种各样稀奇古怪的业务状况，自然就会有这样的情况出现。