Containment and Aggregation Relationship

As it is said in ARLOW, J., AND NEUSTADT, I. UML 2 and the Unified Process, 2nd ed book, there are 7 types of relationship between different objects.

  1. Dependency

  2. Association

  3. Aggregation

  4. Composition

  5. Containment

  6. Generalization

  7. Realization

But I have read in somewhere else that if a relationship has one of the following conditions, it must be an aggregation relationship:

a) Membership b) Containment c) Assembly

The problem is I can't find out the difference between Aggregation and Containment relationship as a separate relationships!


2 Answers 2


There is a lot of confusion about the terms, not all definitions you may find will align.

Containment means the containing object does not directly expose the contained object. It exposes its own interface and may call on the contained object on behalf of the client. So there is no way for the client to mess with the contained object. The containing object owns the contained object and likely created it. Like a diner with a counter where the owner creates whatever you order for you and offers you the result.

With aggregation the aggregating object is exposing the interface of the aggregated object directly. When the client calls on the aggregated object, the aggregating object does not act as an intermediary, the client is directly manipulating the aggregated object, And the aggregated object may exists without the aggregating object, the latter does not own it and typically did not create it. It merely makes it accessible through its own interface. Like a self service diner where you get access to the kitchen and you can make your own meal.

  • yeah you are right. I mean that they are inseparable, because there isn't any obvious difference. For example for aggregation and composition there are some differences like sharing and life-time dependency. Feb 15, 2020 at 22:03

The connector you are referring to is a package merge. P. 276 of UML 2.5:

A package merge defines how the contents of one package are extended by the contents of another package.

The rules behind that are detailed (in length) in UML 2.5 p. 240.

The circle-plus notation is an alternate to the dashed open triangle (dependency) relation with <<merge>> keyword.

Most (all?) UML tools allow structural containment by using packages which can be nested (and can contain elements/diagrams). Package merge isn't needed in these cases. If you want to describe package dependency and merge on an abstract/meta level you will make use of that connector. It's a bit unlucky that these ontologies were not separated well. So you find models which use tool based containments and on top use of these connectors.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.