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

上次问题的后续对话，应该有助于理解这个问题的全部，因此贴上来。

  清水  8:54:56
早啊

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

    我觉得我的理解应该还有不对的地方，请本群的UML 大牛-- 青润，给予指导，其他群友也一起参与讨论下吧
卡恩NO.1  21:31:22
UML 中，我本来认为业务用例和系统用例的关系是一对多，因为系统用例是从业务用例场景中推导出来的。可是后来被淘宝的面试官反驳了。我反复思考后现在认为：  业务用例和系统用例只是有用例粒度上的区别，即不同抽象层次上的，并不存在所谓的1 对多关系。而且一个业务用例对象可以有不同的场景实例，所以某个业务用例场景只是该业务用例对象的某个方面而已，自然从该业务用例场景中推导出的系统用例和该业务用例不会是1 对多关系。

    我觉得我的理解应该还有不对的地方，请群友也一起参与讨论下吧
ancestor  9:17:06
流汗图标
卡恩NO.1  9:18:08
青润老师昨晚的回答有点深，而且感觉不是我想要的答案
青润  9:20:13
我给你一张图
青润  9:20:20
http://hi.csdn.net/attachment/201012/15/0_12923759477zhZ.gif

青润  9:20:41
这个例子就是2003 年底在北航给软工硕士讲课期间产生的一张图，此图的模型也在《软件工程之全程建模实现》一书的光盘中可以找到
清水  9:21:00
旁听学习先
青润  9:21:14
http://blog.csdn.net/qingrun/archive/2010/12/15/6076869.aspx
这个是针对昨天这个话题补充了一些修订内容后，撰写的文字，可以去看看，应该说得比较明确了。
ancestor  9:21:47
两者站的角度不同
卡恩NO.1  9:21:55
哈，青润老师今早刚写的啊，拜读下先
青润  9:21:57
除了对话外的内容如下：
下文中是关于业务用例和用例之间的对应关系的对话，一般来说在一些较大的业务系统或者业务逻辑较为复杂的系统开发中才需要进行单独的业务建模过程，而对于大多数业务系统是不需要单独进行这样的开发阶段的。

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

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

业务用例和用例的对应关系一般是1 对1 和1 对多最为普遍，，但是也可能出现多对1 的形式，甚至一些用户业务间交叉过多的业务实现中还可能出现多对1 的形式。比如下面这个例子就是2003 年底在北航给软工硕士讲课期间产生的一张图，此图的模型也在《软件工程之全程建模实现》一书的光盘中可以找到
青润  9:22:11
刚补充完的，呵呵。然后就看到你这里的消息了。
清水  9:22:33
看看先 

青润  9:22:45
这个文字描述其实不好写清楚，因为涉及到一些复杂业务逻辑，或者复杂业务关系之间的相互嵌套的问题。
青润  9:23:03
一般不常见，但是，在国内这类业务形式还是比较多的存在的
ancestor  9:23:02
业务用例，可以理解为：用来描述用户真实的日常办公中的一个个场景。
系统用例, 是面向系统的。是指为了实现用户在业务用例中展现出来的场景，系统应该怎么去做
卡恩NO.1  9:23:28
一般来说在一些较大的业务系统或者业务逻辑较为复杂的系统开发中才需要进行单独的业务建模过程，而对于大多数业务系统是不需要单独进行这样的开发阶段的。 

卡恩NO.1  9:23:37
你都是直接进入系统用例阶段么  ？
青润  9:23:55
这个问题不如不问。
因为明显不是如此。
卡恩NO.1  9:24:23
一般来说在一些较大的业务系统或者业务逻辑较为复杂的系统开发中才需要进行单独的业务建模过程
青润  9:24:37
对于用户业务比较直接简单的，完全不必作业务模型开发，可以直接进入用例模型的开发阶段。
ancestor  9:25:01
卡恩让淘宝的面试官给弄成魔症了~
卡恩NO.1  9:25:16
不是，这种概念性问题还是要清楚的
青润  9:25:44
呵呵，没事，技术讨论么，每个人都可能有自己的观点和看法，但是，解决问题的才是最好的办法。对于不同的业务系统有可能办法是有差异的。
ancestor  9:25:43
嗯，其实业务用例和系统用例都是需求范畴内的
清水  9:25:45
大家觉得  需求的文档  是否要区分对内和对外两种版本？
青润  9:25:56
不需要。
青润  9:26:12
很多年前就有人问过。我当时的回答就是，需求必须让用户看懂。
清水  9:26:15
这个问题昨天技术开会的时候  我们公司讨论过
ancestor  9:26:13
只是站在不同角度，不同时期的事情，它们的域不同
ancestor  9:26:33
一个代表【业务范围】，一个代表【系统范围】。。
青润  9:26:57
在全程建模的开发方法轮中，我也认为只有设计模型阶段以后的才完全不需要用户的参与，甚至分析模型对于用户来说都是可以看懂的。
青润  9:27:11
而实际上，在多个项目中我也如此做到了。
卡恩NO.1  9:28:21
业务用例和用例的对应关系一般是 1  对 1  和 1  对多最为普遍，但是也可能出现多对 1  的形式，甚至一些用户业务间交叉过多的业务实现中还可能出现多对 1  的形式。

     大象作者说不是 1 对多或者类似的数量关系，因为用例也是对象，对象要从不同的场景中分析出来。淘宝的面试官说业务用例只是为了搞清楚客户需求，不存在所谓的 1 对多
清水  9:28:31
有个问题  我们的客户是强势的  需求文档必须按他的方式  他关于的业务意义（往往是这个系统的亮点  他底做报告的亮点）来描述
但这样的文档  对指导开发  意义不大  象这类问题  有没有比较好的解决经验？
mrman  9:28:45
实际上，很多文档都是分了两份
1+1  9:29:06
淘宝的面试官说的对。 
青润  9:29:39
如果用户方有这样的要求，而他们的文档明显不适合开发人员理解，那么你可以准备两份，但是一般情况下，这个需求文档是不需要两份的。
清水  9:28:31
有个问题  我们的客户是强势的  需求文档必须按他的方式  他关于的业务意义（往往是这个系统的亮点  他底做报告的亮点）来描述
但这样的文档  对指导开发  意义不大  象这类问题  有没有比较好的解决经验？
ancestor  9:29:43
不同的人，对于术语有不同的理解。;-)
青润  9:30:01
因为如果你的技术人员无法理解用户的描述，你怎么保证你的业务系统用户可以用起来没有障碍呢？
清水  9:30:34
对  这就是我想讨论的
如果分两份  就有个问题了  以什么为界限划分呢
青润  9:30:36
对象，也有对象的拆分问题，大的对象和小的对象，要知道对象本身也是对象组成的，我为什么就不能拆分呢？
ancestor  9:30:52
淘宝面试官说的力度，其实，也可以理解为业务用例和系统用例的scope 不同
青润  9:30:57
如果我把业务用例这个对象拆分了，是不是就是1 对多了呢？
青润  9:31:23
如果我进行了对象组合，那是不是就出现了多对1 呢？
清水  9:31:28
刚才说的业务用例  与  系统用例  能否作为一个划分的界限？用户需要理解系统用例吗
青润  9:31:31
这是对象概念中最基础的问题了。
青润  9:31:59
用户可以理解系统用例！这一点完全没有问题，我在多个项目中如此操作过
卡恩NO.1  9:32:56
额，我把青润说的这话发给大象作者，静候他的回复
青润  9:33:24
呵呵，没问题。
卡恩NO.1  9:33:58
其实可能你们都对，我功力太浅给理解错了
卡恩NO.1  9:34:03

ancestor  9:34:23
举个简单的例子，比如一个商场的收款系统，它的业务用例是顾客通过某个系统与收款员交互。而系统用例范围是小于等于业务用例的，它是从业务用例中提取出与系统开发有关的部分，再分析成为系统用例。比如在收款系统中，顾客并不参与收款机的操作，所以它与收款机的系统用例是无关的，而收款员参与这些操作，那么他是系统用例中的一个actor
青润  9:35:11
简单的例子里面business uc 和uc 必然是一样的。
ancestor  9:35:12
卡恩NO.1  9:33:58
其实可能你们都对，我功力太浅给理解错了
无所谓对于错，每个人理解一句话都是不一样的，最终结果达到一样就可以了
破碎虚空  9:35:52
白猫黑猫，抓到老鼠就是好猫
ancestor  9:36:02
呵呵
青润  9:38:08
这个不是理解错误，是一个概念的争论问题，涉及到业务的复杂性和实现关系的基础问题。
青润  9:38:36
没有遇到过这种过度复杂或者因为行政关系造成业务流程被强行分割的系统的话，的确很难理解。
青润  9:39:02
国内这类外行领导内行进行业务流程强行分割组合的事情，实际上是不少见的，但是大部分在国企。
ancestor  9:39:24
这里有个比较关键点取决于理解，“ 行业”
ancestor  9:40:16
系统分析用例是行业信息化经验比较丰富的产物