Consequences of misdiagnosis / false identifying of the relationships types in the class diagram

user_1347910 0
Viewed 92

I read a lot of documents about relationships in the class diagram but I'm still hesitant about some relationships.

  1. My first question is to identify the type of below relationship :

enter image description here

as you could see in the above image I have NetworkAgent class which includes NetworkUDPReceiver for listening and receiving and NetworkUDPSender for sending packets.

I know Aggregation is a whole-part structure as parts could be shareable and Association used when a class has a reference to another class as a member in the non-whole-part structure.

in the above example, I see a whole-part structure and shareable parts. does my opinion is right? do you see Aggregation?

  1. My second and more important question is what would happen if I choose the wrong relationship? I know the right answer may depend on my application or problem concept.

For example, if the correct answer is Association, what would happen, or what are the consequences if I choose Aggregation incorrectly? (and vice versa)

update question: Bruno correctly informs me the position of aggregation sign <> on the above image is incorrect and should be reversed.

ibm-rational visual-paradigm class-diagram class-design uml
3 Answers

as you could see in the above image I have NetworkAgent class which includes NetworkUDPReceiver for listening and receiving and NetworkUDPSender for sending packets.

no, in the diagram NetworkAgent is aggregated by NetworkUDPReceiver and by NetworkUDPSender, not the reverse, because the <> is not on the side of NetworkAgent

what would happen if I choose the wrong relationship?

if the correct answer is Association, what would happen, or what are the consequences if I choose Aggregation incorrectly? (and vice versa)

in that case your model is wrong / confusing, but that probably changes nothing concerning the corresponding Java code which does not depends on that (contrarily to a composition which has impact on the implementing code)

For me if you have these three classes you have compositions rather than aggregations because to still have the NetworkUDPSender and NetworkUDPReceiver instances when the corresponding NetworkAgent instance disappears has no sense, so NetworkAgent <*>-------NetworkUDPReceiver and NetworkAgent <*>-------NetworkUDPSender

user_24589910

This diagram is misleading

Fortunately, NetworkAgent has an embedded hint to help us sorting things out: two properties, receiverAgent and senderAgent, which are of type NetworkUDPReceiver and NetworkUDPSender respectively:

  • This is equivalent to having two associations, one with class NetworkUDPReceiver with the name receiverAgent on its side, and one with NetworkUDPSender with the name senderAgent on its side.
  • To be more accurate, this should be represented with a dotted end on the side of the receiver and the sender.
  • Since this design allows obviously to easily navigate from the agent to the sender or the receiver, you may show navigability with an arrow-head on the side of the sender and the receiver.
  • Assuming that the other classes are represented following the same logic, we can consider that there is no easy navigation back to the agen. This may be shown by a cross on the side of the agent.

So this corresponds almost exatly to the associations you have circled, with one significant exception: the aggregation which is wrong.

The thing with the aggregation

The white diamond is indeed meant to describe a part-whole relationship (with the diamond on the side of the whole). But UML let the semantics open, and de facto, there is no advantage of using it rather than a normal association. So, if you make the diagram, the best advice is to avoid it.

I would moreover challenge you to prove that there is a part-whole relation between an agent and sender/receiver: a sender is not a part of the agent. A sender is just associated to an agent.

Some modelers misuse the UML aggregation to represent systematically object composition. This is not fundamentally wrong, but mixes implementation concerns with design concerns. Such modelers would indeed use aggregation here, but would put it on the side of the agent.

More on this topic, with in-depth argumentation additional references, here.

Conclusion

The best is to remove the aggregation from the diagram. If you decide that you want to use it for object-composition, then move the diamond to the other side.

More generally: if you use an association instead of an aggregation, there's no impact. If you use aggregation instead of an association, it might be misleading, but in general without practical consequences.

user_37234230

I know Aggregation is a whole-part structure

Your diagram shows a shared composition (unfilled diamond).

p. 110 of UML 2.5:

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).

So in order to understand what the UML modeler wanted to express you need to explicitely ask him to define the semantics of the shared aggregation!

user_33796530
Related