[答疑]业务序列图的责任转移，颗粒度是用例的步骤呢还是整个用例

游戏人生 2021-12-29 14:13

潘老师,在对业务序列图进行改进,做责任转移,责任的颗粒度是用例的步骤呢？还是整个用例，按照你书上所说的序列图上面所有的交互动作都是系统用例级别的，如果基于这种图形进行责任转移，那转移的颗粒度一定是用例级别的了，但是你给出那个案例上，好像责任转移的都是用例的步骤，也就是说转移责任的颗粒度是系统用例的步骤，并不是整个用例。

UMLChina潘加宇

两个系统之间的协作尽量画在用例的级别，但不包括系统的自反消息。

“如果基于这种图形进行责任转移，那转移的颗粒度一定是用例级别的了”--这个理解有误，没有这样要求。

参见下图

---

应该在某个用例的某张序列图（或通信图）上描述，在什么场景，进行到哪个步骤时，A需要调用B的什么操作，在什么场景，进行到哪个步骤时，A需要调用C的什么操作，如图8-83。

图8-83 “A会调用B、C”应在序列图上表达

有了序列图，如图8-82的类图上的依赖虚线就没有必要画出来了，类图上画泛化和关联关系即可。

经常看到这样的类图：上面布满了依赖的虚线，却没有泛化和关联，如图8-84。如果这样的类图描述的是不同领域的类之间的协作，那还可以接受，如果类图上都是核心域的概念，那就要警惕了，可能建模人员根本没有去寻找泛化和关联关系。

图8-84 只有依赖关系的类图

也许有的读者会想，图8-84这不挺规整的嘛！问题就在于，这个关系为什么是这样，很可能是没有依据的。建模人员拍脑袋定了这样的依赖关系，然后就假装自己“建模”了。

如图8-85，有ABCD四个类，可以随意编排它们之间的依赖，不管哪一种，都可以写出代码来，编译器也不会报错。但哪一种更合理，要从静态关系来找依据。

图8-85 没有依据，依赖可以随意编排

作者有时候会听到开发人员向我介绍他所做系统的“架构”，“您看，A调用B，B调用C……”，然后就没了。也不讲什么理由，反正我就是这样做了，而且做出来了，也能用，就行了呗！

8.3.2 识别泛化关系

8.3.2.1 识别泛化的思路

（1）直接形成

类图中的两个类可能会直接形成泛化关系，如图8-86所示。严格的做法是针对每两个类，思考“A是B的一种吗？”，再反过来思考“B是A的一种吗？”不过如果真的要这样做，工作量还是挺大的。类图中有n个类，就需要思考2C2 n=n(n-1)次。n=11时，就是100次了！实际工作中，往往是先扫描一遍，大脑迅速过滤出可能值得这样思考的类，针对这些类思考即可。

图8-86 直接形成-两个类之间直接形成泛化关系

实际上，类图上已有的两个类有泛化关系但未识别的情况并不多，因为之前从用例规约识别类和属性时很有可能已经发现了。