8.3 建模步骤3-2 识别类之间的关系
首先要说明：虽然本书先讲解“识别类和属性”，再讲解“识别类之间的关系”，但在实际工作中，先“识别类和属性”再“识别类之间的关系”这个思考顺序只是一个微小的思考周期内的顺序。建模一张类图，需要很多个思考周期。也就是说，识别类和属性→识别类之间的关系→识别类和属性→识别类之间的关系→……是交错进行的。
我们阅读用例规约或其他素材，一边思考一边建模，不管识别出类、属性还是关系，画上去就是，并不需要假装看不见类的关系，非得先把类和属性都识别完了，再来识别类之间的关系。
8.3.1 类之间的关系
类之间的关系有三种：泛化（Generalization）、关联（Association）和依赖（Dependency）。
图8-91 类之间的关系
泛化和关联是类的静态关系。这是系统要想办法记住的关系，或者说，这两个关系属于系统要维护的“数据”之一。即使系统当前没有运行需要用到这些关系的用例，这些关系依然存在，随时等待着被“使用”。
泛化表示集合关系。两个类形成泛化，意味着超类的对象集合包含子类的对象集合。B、C泛化到A（或者说，B、C继承A），意味着A的对象集合包含B和C的对象集合，如图8-92。
图8-92 泛化表示集合关系
*也可以换一种说法：子类的特征集合包含超类的特征集合。*
关联表示个体关系。关联可以发生在不同类之间，也可以发生在同一个类之间，意味着类的对象个体之间有关系。
如图8-93的左侧，A和B、C关联，意味着某个A的个体可能会和某些B和C的个体有关系；
如图8-93的右侧，A自己和自己关联，意味着某个A的个体可能会和另外的A个体有关系。
图8-93 关联表示个体关系
因为关联是个体的关系，所以会有1对多、多对多等多重性，而且存在自己和自己的关联。泛化关系没有多重性，也不允许自己和自己泛化。
集合关系还是个体关系，这是泛化和关联的本质区别，从自然语言的表达来推断有时是不可靠的。
例如，自然语言"人有男有女"说的是泛化关系。"人有男有女"的意思不是一个人的个体里有若干男人个体和若干女人个体，而是说人的对象集合包含了男人的对象集合和女人的对象集合。
自然语言"人有手有脚"说的却是关联关系。"人有手有脚"的意思不是人的对象集合包含了手、脚的对象集合，而是说一个人的个体组装了若干手和脚的个体。
读者可以自行体会一下“人有车有房”和“人有高富帅有屌丝”的区别。
对于比较熟悉的领域，例如刚才的男女、手脚，拍脑袋就可以知道是泛化还是关联，那拍脑袋就可以了。如果进入陌生的领域，有时回溯到集合和个体的本质区别是必要的。
再来看依赖关系：
如果B变化，A也需要变化，那么可以认为A依赖于B。
从这个定义来看，泛化和关联也是依赖关系。泛化是子类依赖于超类，关联的依赖看关联的方向。不过，泛化和关联有另外的表示法，所以一般说的依赖指除了泛化和关联之外的其他依赖，例如调用、创建等。
*显然，只有在信息系统的分析或设计模型里才需要依赖关系，纯粹描述领域知识的领域模型只需要泛化和关联关系。*
这些依赖关系并非时刻都存在，而是在信息系统执行某个用例的某个步骤时才会产生，而且持续的时间非常短——从分析工作流的假设来说，就是趋近于0。因此，要描述依赖关系，仅在类图上描述“A依赖于B”是不够的，还要具体到某个场景。
例如，要描述A会调用B、C的操作，如图8-94在类图上画一根依赖的虚线箭头，不是不可以，但还不够。
图8-94 在类图上表达“A依赖于B、C”还不够
应该在某个用例的某张序列图（或通信图）上描述，在什么场景，进行到哪个步骤时，A需要调用B的什么操作，在什么场景，进行到哪个步骤时，A需要调用C的什么操作，如图8-95。
图8-95 “A会调用B、C”应在序列图上表达
有了序列图，如图8-94的类图上的依赖虚线就没有必要画出来了，类图上画泛化和关联关系即可。
经常看到这样的类图：上面布满了依赖的虚线，却没有泛化和关联，如图8-96。如果这样的类图描述的是不同领域的类之间的协作，那还可以接受，如果类图上都是核心域的概念，那就要警惕了，可能建模人员根本没有去寻找泛化和关联关系。
图8-96 只有依赖关系的类图
也许有的读者会想，图8-96这不挺规整的嘛！问题就在于，依赖关系为什么是这个样子，很可能是没有依据的。建模人员拍脑袋定了这样的依赖关系，然后就假装自己“建模”了。
如图8-97，有ABCD四个类，可以随意编排它们之间的依赖，不管哪一种，都可以写出代码来，编译器也不会报错。但哪一种更合理，要从静态关系来找依据。
图8-97 没有依据，依赖可以随意编排
不时会有开发人员向我介绍他所做系统的“架构”，“您看，A调用B，B调用C……”，然后就没了。为什么要这样调用，也讲不出什么理由，反正我就是这样做了，而且做出来了，好像也能用，就行了呗，管它洪水滔天！
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
