关于关联类的讨论摘抄

我自己很难理解关联类，并觉得这里有些问题，下面是我摘抄的文章或文章片断。

首先是关联类的基本定义：

关联类　一个关联可能要记录一些信息,可以引入一个关联类来记录。图3是在图2的基础上引入了关联类。关联类通过一根虚线与关联连接。图4是实现上述目标的另外一种方法,就是使雇用关系成为一个正式的类。

　

下面是来自UML讨论组的babituo的发言。

从认识论层面来理解
　

---

由于我们有共同的哲学爱好，所以，我觉得这个问题先从哲学层面找到答案会更有益于我们来理解它。

我们从ER图和类关联图对比谈起。

ER图认识问题的出发点是从信息系统主体角度出发的，目的是直接得到现实世界从信息角度分解的结果。着重于如何直接用数据关系来转述现实世界实物之间的关系。
因为ER模型是一个直接的数据关系模型，所以，从ER图看来，一切都是静态的，动态的东西也要静态化来处理，就像用线性化方法处理非线性问题。

作为面向对象的静态模型之一的“类-关联”图，认识问题的出发点是现实世界存在的活的事物，目的是先从本质上理解现实世界事物运动变化发展的规律，再考虑如何在计算机中模拟出这种本质规律的机制。
类-关联图之所以被称为静态模型，是因为其反映了事物本身和事物之间的相互关系的相对稳定性，这种稳定性是我们通过对事物运动变化过程离散采样，然后进行分析发现的相对不变的部分。我们的目的并不是得到这个相对稳定的对象和对象关系模型，而是根据这部分的认识，再重新拟合出新的现实世界过程模型，新的过程有计算机的参与。

以前，由于在技术标准上尚未找到对对象和对象关系信息的持久存储问题的答案，所以需要用关系型数据库来保存这些信息，于是出现两个模型混用的局面。这造成了两种思路的相互干扰。
如今，XML已经成为分布式的对象和对象关系信息的持久存储和交换的标准，但平台工具层面尚未有成熟的OO数据库得到广泛应用，因此，这个蹩脚的技术问题还会困扰我们一段时间，我们必须清楚地认识到，这只是技术手段，而不是思想。

我们试图用ER模型方法得到面向对象静态模型和用面向对象方法得到ER的实体关系模型，至少在思想上的不连贯的，尽管二者存在某种形式上的同态。

寻找关联类的方法应该来自纯粹的面向对象模式的思考。
我们起初建立面向对象的静态模型时，考虑的原则有两点：
1.所有的事必须要有对象来完成；
2.所有的对象必须做适当的事。
顺便提一句题外话：这两个原则实际上也是企业管理的原则，所以，我称现在企业管理思想还处于结构化时代，是进化到面向对象时代的时候了。

所谓关联，只是对象做事时，不同对象之间进行沟通的管道关系。当你发现某处这些管道关系很复杂，需要维护，又能够划归到某个独立的职责范围的时候，你觉得如果有一个对象专门处理这些关系就好了，就可以定义一个关联类。

当你开始考虑实现所有用例的时候，你暂时不需要考虑关联类的存在，只要满足以上两条原则就行了，随着被实现的用例越来越多，你需要把各个用例实现的对象模型合并成一个总的对象模型，你的总体的对象关联图也越来越复杂，这时候，你就可以考虑使用关联类，抽象类等高级一点的手段。这时，一定要保证总的用例模型和每一个用例实现的一致性。