DDD领域驱动设计批评文集>>
《软件方法》强化自测题集>>
8.3.2 识别泛化关系
8.3.2.1 识别泛化的思路
（1）直接形成
类图中的两个类可能会直接形成泛化关系，如图8-98所示。严格的做法是针对每两个类，思考“A是B的一种吗？”，再反过来思考“B是A的一种吗？”不过如果真的要这样做，工作量还是挺大的。类图中有n个类，就需要思考2C2 n=n(n-1)次。n=11时，就是110次了！实际工作中，往往是先扫描一遍，大脑迅速过滤出可能值得这样思考的类，针对这些类思考即可。
图8-98 直接形成-两个类之间直接形成泛化关系
实际上，类图上已有的两个类有泛化关系但未识别的情况并不多，因为之前从用例规约识别类和属性时很有可能已经发现了。
（2）自下而上（从特殊到一般）
更多的情况是发现类图上已有的两个或多个类有共同特征，于是抽象出共同的超类，如图8-99所示。
图8-99 自下而上-两个类之上有共同的超类
关联也可以看作类的属性，关联的角色名相当于类的属性名称。如果多个类关联到同一个类而且角色名相同，也可以考虑泛化出共同的超类，如图8-100。注意，角色名要相同，否则即使类型相同也不是同一属性。
图8-100 共同的关联也可以提炼超类
（3）自上而下（从一般到特殊）
如图8-101所示，这个识别思路就是8.2.5.5 属性是否对所有对象都有意义里的思路，此处就不再重复叙述。
图8-101 自上而下-一个类分裂出子类
8.3.2.2 被误作关联的泛化
泛化关系有时会被误认为关联，下面列举一些错例供参考。
图8-102中，“员工有调度员、装卸工、配货员”指的是员工的对象集合包含了调度员、装卸工、配货员的对象集合，不是指一个员工对象由调度员对象、装卸工对象、配货员对象构成。正确的关系是右侧的泛化关系，而不是左侧的关联（此处是组合）关系。
图8-102 泛化被误作关联 例1
很多系统经常需要设置一些参数，有人会把参数建模成图8-103左侧的类图，把超时时间、锁定设置、频带等作为参数的属性。属性其实就是关联（此处是组合）的一种变体，8-103左侧和右侧是等同的。
图8-103 泛化被误作关联 例2
图8-103的意思是一个参数个体由若干个具体参数个体组成，这不符合领域内涵。更符合领域内涵的是“具体参数是参数的一种”或者“参数的集合包含各具体参数的集合”，也就是说，泛化关系更合适。还有一种做法是把具体的参数全部抽象为“名称”和“值”两个属性。如图8-104。
图8-104 泛化被误作关联 例2 更正
如果按图8-103的方式建模，参数类只有一个对象，但这个对象有很多个属性。当需要为系统设置一种新的参数时，就需要修改类结构，增加新的属性。如果按图8-104的方式建模，只需要增加新的参数对象即可，类结构不需要改变。
一些看起来像是多重性为1对0..1的关联，有可能实际上是泛化关系。例如，1台电器可能是1台洗衣机，也可能不是；1台电器可能是1台电视机，也可能不是；1台电器可能是1台空调，也可能不是，有人以为是关联关系，于是画出图8-105。
图8-105 泛化被误作关联 例3
图8-105的意思是：一台电器可能由一台洗衣机、一台电视机、一台空调组装而成。这是错误的，应该是电器的集合包含洗衣机、电视机和空调的集合，即泛化关系。如图8-106。
图8-106 泛化被误作关联 例3 更正
*也可以尝试在自然语言中用“可能是”和“可能有”来区分。一台电器可能是一台洗衣机，这是泛化关系；一台电器可能有一个电源适配器，这是关联关系。*
[推荐升级]23套UML EA和StarUML的建模示范视频-全程字幕（2022.6.1更新）
6月9-12晚网课：软件需求设计方法学全程实例剖析
6月23-26晚剔除“伪创新”的领域驱动设计-网络公开课
《软件方法》书中自测题-题目全文 分卷自测（1-8章）16套111题
《软件方法》强化自测题集110题
CTO也糊涂的常用术语：功能模块、业务架构、用户需求……[20210217更新]
如何选择UMLChina服务
