Who owns the associated class in this uml diagram?

1
votes

Sorry for this newb question, i'm new to UML.

The diagram for a system is this one:

From what I know of UML, none of the classes in this diagram can own instances of the associated class as there's no aggregate relationship with it.

Does this mean in an implementation of the system in Java, based on the diagram, an outside class has to own instances of the associated class?

Sorry if the answer is obvious. I've spent hours scratching my head over it.

3
uml

3 Answers

1
votes

First off, terminology. @Daniel is right, you don't have an association class. However, I don't think you mean Association Class:

Does this mean in an implementation of the system in Java, based on the diagram, an outside class has to own instances of the associated class?

If I understand correctly that's the nub of your question. In implementation terms, which class(es) have a member variable containing a list of references to instances of Associated Class?

Again - if I understand right - your question stems from the following logic:

  1. In UML, "ownership" is commonly described as a quality of Aggregation (or Composition) relationships.
  2. The relationship between Aggregated/Composite PART Class and Associated Class is a simple binary association - not Aggregate/Composite.
  3. Therefore the "ownership" property doesn't apply
  4. Therefore who owns the list of references to Associated Class instances?

If that's right then the issue is with the specific meaning of "ownership". Whilst not tightly defined in UML, "ownership" typically means responsibility for managing full lifecycle.

I think you're interpreting it more generally: that if an association isn't aggregate, then the participating classes can't hold references to each other.

That's not the case. It's perfectly reasonable for Aggregated/Composite PART Class to hold a reference (or list of references) to instances of Associated Class. The inverse is equally valid. In some cases both are valid (with the attendant need to maintain consistency).

So in summary: is it necessary for an outside class to own the instances of Associated Class? No. It's perfectly valid for either or both ends of a binary association to manage instances of the relationship.

hth and apologies if I misunderstood your question.

PS: a final observation: be very careful about what you mean when using Aggregation. It's notoriously imprecise in the UML spec. Composition has a more rigorous definition, and you can cover 99% plus of all modelling scenarios using Composition and plain Binary Associations. About the only place Aggregation has a well-defined meaning not completely covered by the other two is denoting when recursive relationships must be acyclic.

0
votes

UML does not specify the full behaviour of a system. So what do you mean, when you say an object owns another object? Also instances AssociatedClass could be root objects that are not owned by any other object.

0
votes

The diagram you provided doesn't really contain an association class. The class you named 'associated class' is just a normal class. It also isn't owned by anything (that we see in the diagram).

If what you had in mind was association class, then take a look at example diagram with association class:

an example class diagram with association class

In this example, the MilleageCredit is an association class. So for each distinct combination of Fligh-FrequentFlyer there is one MilleageCredit.

As for ownership, since the Association class represents a relation between 2 associated objects, it gets deleted when

  • the association is cleared
  • either or both of associated objects are deleted

So if you delete either the Flight or FrequentFlyer the MilleageCredit will be gone too. Also if you unlink Flight from FrequentFlyer again the MilleageCredit will be delete.

There's plenty of good UML docs online, for example UML basics: The class diagram

Hope this helps, otherwise please provide more info in the question.