2

I have 2 classes Job and Task. These are the rules:

  • Each Job has a numeric identifier.
  • Each Job has 10 corresponding Tasks.
  • Each Task has a numeric identifier.
  • A Task cannot exist without a Job.

I am trying to build Class diagram for these 2 classes. Since Task cannot live without Job so I thought this is a composition and this is how I build the Class diagram:

enter image description here

But now I am confused that if this association is actually dependency:

enter image description here

How can I know in this case if the relationship is composition or dependency?

UPDATE

I have fixed the composition (Composite Aggregation) in the Class diagram as Thomas Kilian suggested:

enter image description here

ChumboChappati
  • 1,442
  • 4
  • 18
  • 38

1 Answers1

3

A dependency is the weakest relation between elements. It means that if the element which is depended on is changed it needs some kind of attention in the depending element. E.g. there can be dependencies on enumerations or in a conceptual phase between classes or between packages if they contain associated classes.

A composite aggregation is in first place a strong relation (an association) between two elements. That is one of both is also working with the other side in some way (using attributes or methods). Further the composite aggregation is telling something about object lifetimes. The elements being composed will die once the compositing element is removed. This is merely a construct used for data security e.g. where you need to delete personal records if the person is removed (the car/wheels example does not seem to make so much sense since the wheels still are useable once the car is crashed). Another use could be (nowadays less) storage management.

Two side notes:

  • Your drawing is wrong as the filled diamond must attach to the outside and not to the inside of the shape.

  • The shared aggregation (hollow diamond) has no defined semantics and should only be used once you define it in a certain domain for a specific use. See p. 112 of the 2.5.1 specs:

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

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
  • Thanks. I dont get your 2nd side note: "The shared aggregation (hollow diamond) has no defined semantics and should only be used once you define it in a certain domain for a specific use." Can you explain with an example? – ChumboChappati Apr 16 '18 at 21:11
  • See my addition. – qwerty_so Apr 17 '18 at 07:53
  • @ThomasKilian there is no hollow diamond in the question – srh Apr 17 '18 at 13:26
  • @srh If you read my answer: "Two side notes". Just in case someone comes across this with the hollow diamond instead. – qwerty_so Apr 17 '18 at 13:54
  • @ThomasKilian can you give an example of your 2nd side note? I still dont understand what you meant. – ChumboChappati Apr 18 '18 at 14:55
  • The hollow diamond is often wrongly used. People think that it's some kind of "loosely coupled composite" which it isn't. My advice is simply: do not use it, as it has no common definition. – qwerty_so Apr 18 '18 at 15:14