类图中组合与依赖的区别?

时间:2014-02-22 08:08:24

标签: dependencies uml composition class-diagram

我知道,有人曾就此案提出同样的问题,但我仍然没有真正理解,我需要一个具体的答案。谢谢:D

3 个答案:

答案 0 :(得分:3)

由于甘尼斯没有正确解释构图的含义,我必须这样做。

正如Gangnus所解释的, 聚合 是一种特殊形式的关联,其意图是部分 - 整体 - 关系,但没有精确的语义(UML规范说:“共享聚合的精确语义因应用领域和建模者而异”)。例如,我们可以对类CarEngine之间以及类CourseLecture之间的聚合建模,因为引擎是汽车的一部分而讲座是一部分一门课程

组合 (在UML规范中也称为“复合聚合”)是一种特殊形式的聚合,其中组件实例是最多一个聚合实例的一部分一次(也就是说,它不能在几个聚合之间共享)。这意味着CarEngine之间的聚合是一个组合(因为引擎不能同时在两个汽车之间共享),而Course和{{1}之间的聚合由于讲座可以在两门课程之间共享(例如,数据库管理课程和软件工程课程可以共享UML讲座),因此不一定是作文。这意味着在聚合方面,组合的关联结束的多重性为Lecture1,而在非复合聚合的情况下,它也可能是0..1

除了合成的主要特征(具有独占部分)之外,合成还可能带有生命周期依赖在聚合及其组件之间暗示当删除聚合时,其所有部分都将随之删除。然而,这仅适用于某些组合情况,而不适用于其他情况,因此它不是一个定义特征。 UML规范声明:“在删除复合实例之前,可以从复合实例中删除部件,因此不会将其作为复合实例的一部分删除。”在我们* - Car组合的示例中,显然情况是在汽车被摧毁之前可以将汽车从汽车中移除,在这种情况下发动机不会被破坏并且可以重新启动使用

答案 1 :(得分:1)

这些事情彼此相距甚远。

A- - - ->B  Dependency 

是最常见的事情。这意味着,A的代码要注意B类.A可见的B成员的变化可能需要A的变化。

A------->B association (with none aggregation)

协会更紧密的联系。该关联可以具有不同的亲密度,但即使在最弱的一个,它必须具有至少一个导航箭头。 (如果它们是双面的,它们没有显示)这意味着存在一些从A到B指向的简单方法。例如,存在一个结构为a.x.y.b. 该关联具有聚合等属性。它可以是nonesharedcomposition

A<>------>B  association (with shared aggregation) 

共享没有严格的定义,它留给我们建模者和工具作者。但通常它表明某个实例或类在某种意义上有一些B的实例。

A♦------>B  association (with composite aggregation or simply 'composition') 

它具有严格的定义 - 这意味着,A或其实例具有B的实例。它还暗示,这些B仅存在于该关联的边界中。当协会或其拥有的将被销毁时,将无法访问这些B.如果没有满足这些严格的要求,那就不是一个组合。

来自UML标准2.5的引用: “复合聚合是一种强大的聚合形式,需要一部分(见11.2.3)实例一次最多包含在一个复合实例中。如果复合实例被删除,其所有部分通常都会被删除它。

associations和依赖项的其他变体也存在。

因此,依赖是作曲所有者的祖先。

答案 2 :(得分:1)

很简单。 依赖关系是指向关系的类型,它没有运行时语义含义。它说一个元素(依赖的来源)的定义也是 在语义上或结构上依赖于目标元素的定义。没有运行时语义含义意味着现实世界中没有实例。 (例如,依赖于某些人的人不能通过模型​​中的依赖关联:)

组合是复合聚合类型的关联。它可以有一个实例(运行时语义含义)为了更准确,它是关联结束时作为组合的属性元素。你可以在世界任何地方找到作品。很好的例子是人体...它是头部,手臂,腿部的组成...... 零件不能与其他相同类型的组合物物理连接。如果它的部分存在,人体就存在。