另一种情况是整体拥有各部分,部分与整体共存,如整体不存在了,部分也会 随之消失,这称为组成(Composition)。例如,我们打开一个视窗口,它就由标题、外框和 显示区所组成。一旦消亡则各部分同时消失。在UML中,聚集表示为空心菱形,组成表示为 实心菱形。
需要注意的是,一些面向对象大师对聚集的定义并不一样。大家应注意其他面向对象 方法与UML中所定义的聚集的差别。
(4) 继承关系 人们将具有共同特性的元素抽象成类别,并通过增加其内涵而进一步分类。
例如,动 物可分为飞鸟和走兽,人可分为男人和女人。在面向对象方法中将前者称为一般元素、基 类元素或父元素,将后者称为特殊元素或子元素。继承(Generalization)定义了一般元素 和特殊元素之间的分类关系。在UML中,继承表示为一头为空心三角形的连线。如图1中, 将客户进一步分类成个体客户和团体客户,使用的就是继承关系。 在UML定义中对继承有三个要求:
*特殊元素应与一般元素完全一致,一般元素所具有的关联、属性和操作,特殊元素也 都隐含性地具有; *特殊元素还应包含额外信息;
*允许使用一般元素实例的地方,也应能使用特殊元素。
(5) 依赖关系 有两个元素X、Y,如果修改元素X的定义可能会引起对另一个元素Y的定义的修改,则 称元素Y依赖(Dependency)于元素X。在类中,依赖由各种原因引起,如:一个类向另一个类 发消息;一个类是另一个类的数据成员;一个类是另一个类的某个操作参数。如果一个类 的界面改变,它发出的任何消息可能不再合法。
(6) 类图的抽象层次和细化(Refinement)关系 需要注意的是,虽然在软件开发的不同阶段都使用类图,但这些类图表示了不同层次 的抽象。在需求分析阶段,类图是研究领域的概念;在设计阶段,类图描述类与类之间的接 口;而在实现阶段,类图描述软件系统中类的实现。按照Steve Cook和John Dianiels的观 点,类图分为三个层次。需要说明的是,这个观点同样也适合于其他任何模型,只是在类图 中显得更为突出。
概念层 概念层(Conceptual)类图描述应用领域中的概念。实现它们的类可以从这 些概念中得出,但两者并没有直接的映射关系。
事实上,一个概念模型应独立于实现它的 软件和程序设计语言。 说明层 说明层(Specification)类图描述软件的接口部分,而不是软件的实现部分 。
面向对象开发方法非常重视区别接口与实现之间的差异,但在实际应用中却常常忽略这 一差异。这主要是因为OO语言中类的概念将接口与实现合在了一起。大多数方法由于受 到语言的影响,也仿效了这一做法。现在这种情况正在发生变化。可以用一个类型(Type )描述一个接口,这个接口可能因为实现环境、运行特性或者用户的不同而具有多种实现 。
实现层 只有在实现层(Implementation)才真正有类的概念,并且揭示软件的实现部 分。这可能是大多数人最常用的类图,但在很多时候,说明层的类图更易于开发者之间的 相互理解和交流。 理解以上层次对于画类图和读懂类图都是至关重要的。但是由于各层次之间没有一 个清晰的界限,所以大多数建模者在画图时没能对其加以区分。画图时,要从一个清晰的 层次观念出发;而读图时,则要弄清它是根据哪种层次观念来绘制的。要正确地理解类图 ,首先应正确地理解上述三种层次。虽然将类图分成三个层次的观点并不是UML的组成部 分,但是它们对于建模或者评价模型非常有用。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
