6

enter image description here

Lets say A, B are classes then what does this UML diagram mean?

(1) A contains B

Or

(2) B contains A

I'm confused as to which direction the aggregation holds.

Aditya Kalra
  • 71
  • 1
  • 2

3 Answers3

8

In both cases the class closest to the diamond is the one that contains the class farthest from it. The relationship indicates either a single contained object or a collection of them. Usually it is indicated graphically with a legend similar to the one used in database ERM diagrams: "1..1", "1..m", etc.

The filled diamond means composition. The contained objects has little or no use outside the container and perhaps the container is incomplete without them (or is in an invalid/unstable state without them). For example, every iPhone has a touch screen panel (the transparent thing with a flat cable attached to the side). The touch screen panel separated from the iPhone is not of much use. You don't see people carrying in their pockets detached touch screen panels with the flat cable hanging out.

The empty diamond means aggregation. The contained object can exist separatelly from the container and is useful outside the container. The container can live without the contained object. A keychain is a composite object with a lot of keys attached to it, the keys, laser pointers and can openers can work by themselves without being attached to a keychain and neither the keychain or the tool (key, etc) is left in an unstable state. You can add and remove this items to the keychain but they can exist by themselves as functional tools. The keychain itself can be empty, and you can't say it is broken because of that.

See also this answer: https://softwareengineering.stackexchange.com/a/336764/61852

candied_orange
  • 102,279
  • 24
  • 197
  • 315
Tulains Córdova
  • 39,201
  • 12
  • 97
  • 154
3

This is the sort of thing examples help with.

enter image description here

We have an aggregation of ducks on the pond. At least when it's duck season. The ducks do not contain the pond. Well, they drink from it, but that's a different relationship. Unlike the car and carburetor relationship the pond isn't composed of ducks. The pond doesn't stop being a pond if the ducks leave.

The arrow depicting the direction of the association relationship isn't even required to depict aggregation.

UML comes in many versions at this point and people aren't always faithful to the formal rules so you almost have to treat every class diagram like it has it's own language.

candied_orange
  • 102,279
  • 24
  • 197
  • 315
  • `The arrow depicting the association relationship isn't even required to depict aggregation.` The arrow still adds value. Your example indicates a bidirectional relation. That is, the car knows and has access to the carburetor and the carburetor knows about the car that it belongs do. Likewise with the pond and ducks. The container (the car and pond, in your examples) always need to know about the thing that it contains. However, if you added an arrow to the carburetor and duck, it would indicate that the carburetor and duck did not have access to its car or pond. – Thomas Owens Jul 08 '17 at 14:24
  • 1
    @ThomasOwens yeah that's one of those things I don't trust to always be intended when I try to read a uml. – candied_orange Jul 08 '17 at 15:34
  • It's one of the problems with how people use UML. If I don't see the arrow, I usually consider it as undefined - maybe it's a bidirectional relationship, maybe it's not. The arrow head should only be used to indicate a directional relationship. Even when I'm using [UML as a Sketch](https://martinfowler.com/bliki/UmlAsSketch.html), I try to follow the rules and syntax and semantics of the language, but not everyone does. – Thomas Owens Jul 08 '17 at 15:37
  • 1
    Duck season. Wabbit season. Duck season. Wabbit season. – Robert Harvey Jul 08 '17 at 15:43
  • 1
    FWIW - There is no "standard" that says lack of arrow automatically indicates "bidirectional relation". Most people don't use the arrow because it is generally implied that aggregation, composition and inheritance is uni-directional if the designer is following good software design practices. "Technically" I suppose one can claim the example indicates a "bidirectional relation" but in practice it seems a stretch. The goal of creating UML diagrams is to communicate efficiently. Being nit picky about usually unimportant details like arrows drives people away from using UML diagrams. – Dunk Jul 10 '17 at 20:32
  • A legend telling me what your particular flavor of uml is helps a lot. – candied_orange Jul 10 '17 at 21:00
  • 1
    @Dunk Page 19 of the UML 2.5 specification: `An association with neither end marked by navigability arrows means that the association is navigable in both directions`. Both Composition and Aggregation are association relationships. – Thomas Owens Jul 22 '17 at 22:34
  • @ThomasOwens - Well, I guess that is a perfect example of why very few people bother using UML anymore. It had a lot of promise in the beginning. However, like any bureaucracy, instead of defining a standard that is "useful" and easy for the user, they change the rules to make it easier for the people making the rules. In this case, the tool developers. In so doing, they lost thousands upon thousands of potential customers. I'll still use it how I've always done, it has proven to work more than sufficiently for many years. If someone wants to nitpick, I'll tell them to fix it, it won't be me. – Dunk Jul 25 '17 at 18:42
0

FWIW I'll add the definition from the UML specs on p. 110:

none Indicates that the Property has no aggregation semantics. shared

shared Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.

composite Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (see the definition of parts in 11.2.3).

Especially the explanation for shared (your example with the hollow diamond) is notable as it says "it has not specific meaning". You should therefore avoid it simply unless you have good reasons to use it in your domain. In the latter case you need an explicit definition of its semantics.