-1

When it comes to class diagrams, can an association or aggregation exist between two objects that are in composition with one base object?

Example: Class Car has a composition relation with class Engine and class Fueltank. So Car has An Engine and a Fueltank, and Engine and a Fueltank are dependent on Car. But Engine also needs information from Fueltank, without intervention of Car (in accordance with a sequence diagram for example). That means Engine and Fueltank also have a relationship although, they're both compositions of the Car. See diagram below:

enter image description here

So, the question is, may such “loops”, or better redudant associations, in class diagrams occur? Or does that undermine the rules of OOP?

R.H.dev
  • 21
  • 3
  • where is the "loop" in your car example? – 463035818_is_not_an_ai Dec 12 '22 at 15:14
  • Not sure your analogy really works. I for one would not attribute a relationship between the fuel tank and the engine except for the car object that is holding them both. – NathanOliver Dec 12 '22 at 15:17
  • The word 'loop' may not be the best in use here, but there is like a closed circle to say so. The question is if that's a problem? – R.H.dev Dec 12 '22 at 15:18
  • @NathanOliver When different objects are involved in some kind of a chronologic proces, but those objects are direct related to one base object, class A in my example, then how could I implement it? Because when I add no relationsip between a class B and C, although they're involved in a proces, information would go back and forth via class A. But that could be unfortunate. – R.H.dev Dec 12 '22 at 15:27
  • That is no loop and it's not forbidden. Still, why do you see an issue? – qwerty_so Dec 12 '22 at 15:28
  • I’ve shortened the question by removing the introductory sentences, and by merging the abstract and concrete examples to avoid redundancy. With “loop” you mean “circular dependency” or redundant associations ? – Christophe Dec 12 '22 at 18:28
  • I vote to reopen the question: it shows personal research, is a founded question, and the only ambiguity is the unappropriate use of the term “loop”, which is a minor issue that does not prevent an objective, factual answer. – Christophe Dec 12 '22 at 18:30
  • 1
    @Christophe Thank u very much for the vote and editing. With "loop" I indeed meant more like redundant associations. Am I right designing my software with such a principle. – R.H.dev Dec 12 '22 at 20:53
  • 1
    @R.H.dev I hope the question gets reopened. Indeed, this design is perfectly legit, but it has a couple of drawbacks (ambiguity and design) – Christophe Dec 12 '22 at 21:40

1 Answers1

1

This is legal UML...

This kind of combination of composition and association is perfectly legal in UML and does not undermine OOP. There are only a few constraints in UML in this regard:

  • Composite aggregation is a strong form of aggregation that requires a part object be included in at most one composite object at a time.

  • Compositions may be linked in a directed acyclic graph with transitive deletion characteristics;

  • An end Property of an Association may only be marked as a shared or composite aggregation if the Association is binary and the other end is not marked as a shared or composite aggregation.

The first two restrictions are at object level and not necessarily at the class. The last restriction is for the class diagram: it says that a same association can't have composite or shared aggregation at both end. None of those restrictions are relevant for your diagram.

... but may not express what you think

The problem is that this diagram does not express what you think. It says that a Car c is composed of an Engine e and a Fueltank f; it also says that e is aggregated with a Fueltank, which could be f by coincidence, but which could also be another Fueltank and even a Fueltank of another Car. The model does not well represent the triangular relationship between the classes. Here some hints:

  • You may prevent the inconsistencies by adding some constraints that the engine fuel tank is the same than the car fuel tank.
  • You may make the engine/fueltank relation a derived association (i.e. somehow the engine's fuel tank will be derived from the car's fuel tank.
  • You may make the car/fueltank relation a derived association (i.e. the car's fuel tank is derived from its engine).
  • you ignore the relationship engine/fueltank and instead, use the car as a mediator between its components.
Christophe
  • 68,716
  • 7
  • 72
  • 138
  • Can you show me an example how a better diagram in this situation would look like? – R.H.dev Dec 13 '22 at 23:37
  • @R.H.dev the derived associations are shown with the association name precded by a / (you must of course add the operations that allow to derive the association (e.g. gettank() in a car that can use gettank() of the engine. For the mediator design pattern, you can find it on wikipedia. – Christophe Dec 14 '22 at 00:54