软件方法(下)第8章分析之分析类图—知识篇Part11-类之间的关系

2022-10-31 17:03:52 浏览数 (1)

DDD领域驱动设计批评文集>>

《软件方法》强化自测题集>>

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……”,然后就没了。为什么要这样调用,也讲不出什么理由,反正我就是这样做了,而且做出来了,好像也能用,就行了呗,管它洪水滔天!

[推荐升级]23套UML EA和StarUML的建模示范视频-全程字幕(2022.6.1更新)

6月9-12晚网课:软件需求设计方法学全程实例剖析

6月23-26晚剔除“伪创新”的领域驱动设计-网络公开课

《软件方法》书中自测题-题目全文 分卷自测(1-8章)16套111题

《软件方法》强化自测题集110题

CTO也糊涂的常用术语:功能模块、业务架构、用户需求……[20210217更新]

如何选择UMLChina服务


0 人点赞