2

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.

hamed
  • 471
  • 1
  • 9
  • 22

3 Answers3

2

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

bruno
  • 32,421
  • 7
  • 25
  • 37
  • yes, you are right, the position of <> is incorrect. finally, do you agree with me on Aggregation? could you explain more about impact of composition on implementation code? totally selecting aggregation or association doesn't impact on code? – hamed Jul 10 '20 at 10:14
  • @hamed it is confusing to use an aggregation when it must not be the case or the reverse. In your case it seems better to use compositions rather than 'simple' aggregations because to still have the *NetworkUDPSender* and *NetworkUDPReceiver* when the *NetworkAgent* disappear has no sense – bruno Jul 10 '20 at 10:46
  • I think NETWORKUDPSENDER and receiver are shareable and could be alive by their own, finally could you explain more about impact of composition on implementation code? – hamed Jul 10 '20 at 13:56
  • @hamed if you use a socket (UDP/IP) the channel is bidirectional, and for me that socket is managed by *NetworkAgent*, so without it you cannot anymore receive nor send through the socket. If you have `A<*>---B`or even just `A<*>--->B` when an instance of *A* disappears the corresponding instance of *B* disappears too, this must be made by the implementation – bruno Jul 10 '20 at 15:02
  • I don't know why but I use two different sockets for receiving and sending. yes if I use 1 socket Composition is correct but I think based on classes I show on image and using 2 different sockets, Aggregation is correct. finally, if it is a composition I should be careful about deleting child object and for Aggregation and Association there is no differentiation on code? – hamed Jul 10 '20 at 16:49
  • Bruno please respond to my second question(consequences of wrong decision) generally. not only in this situation. – hamed Jul 10 '20 at 16:52
  • sockets are placed on childs, for this reason, they haven't any dependency on the parent – hamed Jul 10 '20 at 16:56
  • @hamed in that case I do not see the interest to have the class *NetworkAgent*. `don't know why but I use two different sockets for receiving and sending` : this is not satisfying, an architecture is used because of 'good' reasons, not because of the result given by a dice. Out of that I supposed I already answer to your second question, – bruno Jul 10 '20 at 17:03
2

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.

Christophe
  • 68,716
  • 7
  • 72
  • 138
  • when I set ReceiverUDPAgent as shareable Aggregation in Visual Paradigm, it automatically draws Aggregation and put the diamond on the part side, like image. I go to NetworkAgent specification, open ReceiverAgent specification then set Aggregation type to shared. how could I draw Aggregation and put diamond on whole side? – hamed Jul 11 '20 at 08:58
  • @hamed Ok, you then need to set the NetworkAgent as sharable aggregation, since the agent is the aggregate (you can understand this as the aggregate sharing its parts). – Christophe Jul 11 '20 at 09:04
  • no, I agree with the association, only I want to know why Visual Paradigm place Aggregation diamond on the part side? – hamed Jul 11 '20 at 09:51
0

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!

qwerty_so
  • 35,448
  • 8
  • 62
  • 86