发信人: leeyg(雷云勾)
整理人: leeyg(2001-06-05 22:31:41), 站内信件
|
对于上一个题目，个人认为“员工”类与“科室”类之间的关系应该
是 “关联”。
“关联”关系和“聚类”关系，是比较容易混淆的概念。如果在自然语言上
能够以“…的一部份”或“包含”的字眼来形容，这是聚类关系是容易理解的。
但如果有“组成”的意思却又不是严格的“一部分”，是什么关系呢？
本人认为：
除非聚类关系的意义很明显，否则都是“关联”关系（xixi，远高建模方法定理）
“关联”关系是一种高度抽象的关系，包含了任意两个对象（或者多个对
象、甚至一个对象的两种角色）之间的某种联系，因此，聚集也是一种关联。单
独引入聚集概念无非是因为在现实世界中它的应用较为广泛，并且在关系结构上
有其自身规律。
在UML的表示法中，表达“聚类”关系的符号只是关联端点
（association end）的一种修饰(adornments)。关于adornments，UML是这样定
义的：
these adornments indicate properties of the association related to
the class.The adornments are part of the association symbol,not part
of the class symbol。《UML Notation Guide》，可见，UML认为，“聚类”
是“关联”的一种。
在实现上，“聚类”与“关联”采用的都是用指针的方法来实现的。A与B的
聚类关系或A与B的关联关系，都是在A中设B指针，在B中设A指针实现。在UML的图示化表达方式上没有使人误解A与B（除聚类与关联外）的其它关系，而在实现
上又是相同的，我们认为，没有必要死抠“聚类”与“关联”的关系。
强调实现，是因为好的建模语言，不能是为了建模而建模，它必须延续到后
面的开发过程，因此，过分地严格区分UML的语义，可能会落入钻牛角尖的陷
井。同时，也必须提醒，UML是一种以图形符号为主要表述方式的语言，语言学
（包括自然语言、符号语言）认为，图形符号的表达方式只是概括性的，它描述
客观事物的能力远没有自然语言精确及强大（不然人类也不会进化到文字的出
现）。
还有一个问题，“聚类”与“关联”的实现是否真的一样呢？
在解决这个问题前，我们必须有一个验证工具。Rose能够自动产生源代码框
架，正是一个理想的验证工具。在此，我们必须作一个假定：假定Rose完全实现
了UML，Rose能够实现的，即是UML所要求的，Rose不能实现的，即是UML所不允
许的。
上一节课我们已经建了一个“员工”的类，在Logical View中再建一个“科
室”类，然后在“员工”类与“科室”间加一个“Undirectional Association”，（点击“员工”类后拖动鼠标到“科室”
类），点击选中新建的关联符号后，点击右键，在下拉菜单的“aggregate”中
打上勾，然后按住shift键，分别点选“员工”、关联及“科室”的符号，选中
它们三个，然后在Tools菜单的“C++\Browse Header”中点击一下（不好意思，
没有DELPHI,我只看得懂C++），我们可以看到，在“员工”类的属性中，有一个
注明是表示的关联的属性：
科室 *the_科室
同样，在“科室”类的属性中，有一个表示关联的属性：
员工 *the_员工
好，让我们按刚才的步骤将这个关联的“aggregate”去掉，再Browse Header一次，我们可以看到，与上一次的结果是一样的，也就是说，关
联与聚类实现的方法真是一样的。
我们已经建立了“科室”这个类，科室嘛，当然要有领导（不然下面的人怎
样拍mp呢？），于是在“科室”类中加入一个“科长”属性。
问题来了，问题二：
这个关联描述的是“科室”类与“员工”类的关系，可是怎样描述“科长”
与“员工”的领导关系呢（这mp拍错了可是大件事）。
这一次我不来选择题了，大家自由发挥。
----
软件开发是可工业化组织实施的艺术创作 |
|