以下讨论来自“理论与推演”群中的对话。
2013-01-31
北京-FireSpider 男13:28:45
青润老师，请教个问题：软件架构设计和软件概要设计是什么关系？
青润14:20:25
概要设计是从需求延伸的，架构设计着眼于系统整体的逻辑实现。着眼角度不同。
北京-FireSpider 男 14:27:29
哦，那也就是说，概要设计不涉及系统实现的问题吗？
青润 14:27:54
概要设计是分模块进行的，架构设计是需要考虑所有模块的。
青润 14:28:24
起始点不同，考虑的范围也不同，另外，概要设计一般是需求的进一步细化，在我的书中称之为半数字化的设计。
青润 14:28:32
详细设计才是完全数字化的设计。
青润 14:28:54
也就是说，架构设计在概要设计的时候开始起作用，但是完全起作用要在详细设计的时候才有。
北京-FireSpider 男 14:29:16
哦。
青润 14:29:48
如果你看了我书中对应的部分，可以看到概要和详细设计的区别，很明显，也很明确。
北京-FireSpider 男 14:30:29
是不是可以这样说：概要设计对应用例分析阶段，与系统实现无关，也就与架构设计无关了。而详细设计阶段对应用例设计阶段，因为与实现有关，因此就与架构有关了。
青润 14:31:02
这个说法是不对的。
青润 14:31:13
没有用例设计阶段。
青润 14:31:26
针对uc的设计就是从概要设计到详细设计，推进下去的。
青润 14:32:03
概要设计，一般来说，是简单的mvc划分，详细设计的时候会增加一些具体细节的设计模式和一些具体设计方法的应用。
北京-FireSpider 男 14:33:49
用例设计改为用例实现的说法呢？
青润 14:36:24
没听说过。
青润 14:36:44
用例实现是说：use case realization这个关系么？
青润 14:37:57
如果是这样的话，我认为的这个说的是：业务用例到系统用例的对应实现关系。
也就是说，哪些业务用例是需要在本次开发中实现的，就会转换为对应的系统用例保存下来，其他的uc都将被规划到以后的开发中或者不实现
北京-FireSpider 男 14:37:58
我也有点糊涂。很多书上的系统分析设计都是基于系统用例的。现有用例分析，然后就是设计，难到设计不是针对用例的？
青润 14:38:39
设计必须是针对用例的，所以很多书中都跨越了这一段，因为他们说不清楚。
青润 14:39:00
我的书中的需求阶段中对此有很详细的介绍，我可以给你一个截图做说明。
北京-FireSpider 男 14:39:19
好的
北京-FireSpider 男 14:39:33
您的书，今天我忘带了，所以没法看到。
青润 14:42:16
青润 14:42:34
我才注意到，书中并没有针对这一段内容的介绍，是培训中讲过的内容。
北京-FireSpider 男 14:42:48
嗯
青润 14:43:02
业务用例，到系统实现的用例之间会有一个处理过程，这个过程决定哪些用户提出的需求直接实现。
青润 14:43:19
buc和uc之间是m：1或者1：m的关系
北京-FireSpider 男 14:43:29
嗯
青润 14:43:37
基本不会有M：N的关系，也就是不建议存在buc拆分的问题。
青润 14:44:39
青润 14:44:48
这张图基本上覆盖了这些情况。
青润 14:45:08
前面说错了，应该是buc到uc之间是M：1的关系。
北京-FireSpider 男 14:46:51
哦，是这样。
青润 14:47:28
这张图是06年给总参培训时候的一张图，因为不涉及机密，可以使用。
北京-FireSpider 男 14:48:56
我想想，这一块我好想还是存在理解误区。
青润 14:49:06
嗯。
北京-FireSpider 男 14:56:13
这种buc和uc之间的映射关系，应该是指包含子buc的buc，对吧。因为一个粒度比较大，还包含很多子buc的buc，它可能因为子buc映射为多个uc而表现出：一个buc对应多个uc的情况。
青润 14:57:00
其实这里面buc完全可以做成我的元用例的概念。
北京-FireSpider 男 14:57:13
嗯
青润 14:57:17
做的非常细，细到无法再分割，然后进行组合，形成实际的uc。
北京-FireSpider 男 15:05:52
这个是请假业务的流程图：
北京-FireSpider 男 15:07:18
如果把请假表示为一个业务用例的话，它下面的处理节点也算作业务用例。就会出现：请节业务用例包含“填写请假申请单”、“部门经理审批”、“总经理审批”、“行政归档”四个子业务用例。
北京-FireSpider 男 15:07:56
从“填写请假申请单”、“部门经理审批”、“总经理审批”、“行政归档”直接创建系统用例，得到系统用例：填写请假申请单”、“部门经理审批”、“总经理审批”、“行政归档”。
北京-FireSpider 男 15:08:33
同时，请假也直接创建一个系统用例。这样就会出现：请节系统用例包含“填写请假申请单”、“部门经理审批”、“总经理审批”、“行政归档”四个子系统用例。
北京-FireSpider 男 15:14:32
是不是就是这样的呢？
北京-FireSpider 男 15:14:28
北京-FireSpider 男 15:15:46
北京-FireSpider 男 15:15:55
画错了。
北京-FireSpider 男 15:16:10
北京-FireSpider 男 15:16:38
请假系统用例与这几个业务用例的关系是不是就可以认为是：多个业务用例对应一个系统用例呢？
北京-FireSpider 男 15:16:55
北京-FireSpider 男 15:17:07
而这里是不是可以认为是：一个系统用例对应一个业务用例呢？
青润 15:57:34
关于这个问题，你应该去看一下我元用例概念的定义和解析。
青润 15:58:01
请假这个业务用例之下的各个用例是否已经无法拆分，如果可以拆分就可以继续拆，直到成为元业务用例为止。
青润 15:58:36
而用例必须是合理的，也就是说，必须是多个元用例的组合。
元业务用例和元用例可能是1：1的关系，目前这个问题还需要深入的进行一下逻辑分析才能确定是否都是1：1的关系。
北京-FireSpider 男 16:01:49
关于元用例，我觉得必须配合界面原型才能知道，凭着大脑去推演，好像挺难，有时只管的表示一下子就能判断出来。
青润 16:02:14
这个完全不需要
青润 16:02:27
元用例的创建本来是为了进行用例规模度量的。
青润 16:03:01
也就是用于用例复杂度计算，同时可以评估开发工作量的，后来我把它延伸到进行需求的完整实现的细节上。
北京-FireSpider 男 16:07:54
“元业务用例和元用例可能是1：1的关系”，如果多个“元业务用例”对应一个“元用例”是不是可以认为“元业务用例”还需要进一步拆分呢？
青润 16:08:18
是不是说反了？呵呵
青润 16:08:26
应该是元用例还需要进一步拆分。
北京-FireSpider 男 16:08:35
哦，对，呵呵。
青润 16:08:38
一般来说元业务用例对元用例就是1：1
青润 16:08:55
而且元用例就是元业务用例推到过来的，这个过程不需要进行合并。
北京-FireSpider 男 16:08:56
嗯
青润 16:09:17
而往往系统没有那么复杂的时候就不需要太多元用例的概念，直接用元业务用例映射过来组合成用例即可。
青润 16:09:25
没必要把简单的事情也分几个步骤来操作。
青润 16:09:36
否则，就是自己把自己复杂化了。
青润 16:10:00
所以，一般来说不存在这个假设，只有可能是元业务用例过于复杂，并不是最小化的，所以，需要考虑拆分。
青润 16:10:30
也就是说，在流程图中如果某个活动还有子项活动的时候，那就需要考虑这个活动的拆分，形成更多的元业务用例，否则是不需要考虑的。
北京-FireSpider 男 16:12:44
您前面图的，“公文撰写”和“发送EMAIL”两个业务用例，实际上在系统实现上，“发送EMAIL”可能是内置的，就是在“公文撰写”完毕并提交，自动发送EMAIL。这样的话，就是多个业务用例对应一个系统用例了。
青润 16:13:15
对，多个业务用例对应一个系统用例，这是很常见的。
青润 16:13:35
业务用例可以讨论的很细，甚至直接到达元用例的层级。
北京-FireSpider 男 16:13:43
嗯
北京-FireSpider 男 16:14:27
呵呵，好像很需要动脑筋思考业务信息化的事情啊。
青润 16:14:46
呵呵。
北京-FireSpider 男 16:14:46
不同的人，可能做出不同的分析出来。
青润 16:15:01
这里面才能分割出来，那些需要系统实现，哪些不需要。
北京-FireSpider 男 16:29:56
需要拆分业务用例的，我觉得这涉及业务重构了。
青润 16:30:15
也可能是业务重构，也可能是业务调研不清楚。
北京-FireSpider 男 16:30:32
需要将一个业务用例映射为多个系统用例的，应该是涉及业务重构了。
北京-FireSpider 男 16:30:39
嗯
青润 16:30:56
其实，大概有三分之一的用户需求变化责任在程序员身上，是因为不了解用户业务或者没有调研清楚造成的结果。
北京-FireSpider 男 16:32:42
嗯，很有可能。
青润 16:33:13
不是很有可能，是事实，呵呵。只不过，程序员涉及到自身，不愿意承认而已。
青润 16:33:21
我们不是神，不是所有的需求都能理解的。
青润 16:33:29
需要过程，需要时间。
青润 16:33:38
理解错误，也在所难免。
北京-FireSpider 男 16:33:42
但比如我们现在做的石油管线巡检，原始业务是管道管理员给巡线员埋纸条，让巡线员去找纸条，以此作为考核指标。但上GPS巡线后，业务方式完全发生变化了。
青润 16:33:52
只不过，我们处于行业内，难免想要给自己做一些掩盖。
北京-FireSpider 男 16:33:55
虽然业务目标一致，但是业务实现方式完全不同了。
北京-FireSpider 男 16:34:06
这时的业务节点，其实就需要重构了。
青润 16:34:17
这属于业务改革，那就是另外的事情了。
北京-FireSpider 男 16:34:22
嗯
北京-FireSpider 男 16:54:23
多谢清润老师的耐心讲解。青润 16:54:35
不客气。