1

Please note: I know that Aggregation is a specific type of Association. But, is this aggregation or not?

class A{
     void myfunc(){
         B myB = new B();
     }
}
class B{
    // some code for class B, which as nothing to do with class A
}

So, when object of B is created and destroyed within the scope of a function of class A, what is the relationship between the 2 classes?

P.C.
  • 651
  • 13
  • 30
  • This might help you: [Aggregation vs association](http://stackoverflow.com/questions/9640885/uml-aggregation-vs-association) – Jan Trienes Apr 13 '14 at 10:20
  • possible duplicate of [Aggregation versus Composition](http://stackoverflow.com/questions/734891/aggregation-versus-composition) – PsiX Apr 13 '14 at 20:17
  • My take on the association / aggregation / composition / dependency discussion: http://stackoverflow.com/questions/7718035/uml-association-and-dependency/7724681#7724681 – Uffe Apr 14 '14 at 06:57

3 Answers3

1
  • There are three aggregation states: none, shared and composition. It is not correct to use the word "aggregation" instead of "shared aggregation". Better say "shared" instead.
  • Shared aggregation is a non-strictly defined term, meaning 1:n relationship without strict containing (not composition).

I see your problem - you can call the function many times and each time the A instance will have one more B instance. So, it can be mistaken for 1:n association. But it it is not really. Look at a citation from UML standard, 2.5, p. 208: "An Association declares that there can be links between instances of the associated types". You declare an association, shown in "myfunc()". Every call to myfunc() creates a link, that belong to the same declaration, the same association. It is not one association 1:n, it is n "instances" of the same 1:1 association.

  • So, your example is n 1:1 and is none aggregation. It is not an attribute, but obviously, is navigable (one more non-strict term). So, you should show it as a usual arrow from A to B, without dots, and if you wish, you could put stereotype "local" on it.
Gangnus
  • 24,044
  • 16
  • 90
  • 149
  • Don't have UML spec by hand, but I remember that association (and aggregation and composition) are kind of properties of a class, just like an attribute. They share all characteristics with attributes (multiplicity, scope, name, etc) and only difference in practice is that attributes are normally of basic data types (int, char, bool, etc), while associations relate to "complex" types (classes). It is even legal in UML to model an associated class as a norman attribute. In this case there is no this kind of "strong" relationship, but rather short-term link inrun-time. – Aleks Apr 15 '14 at 07:33
  • @Aleks I have UML spec at hand and can assure you, that only *classifier owned* end of association is attribute. And is shown as *dotted* end. Association can be class by itself (not necessarily). BTW, you can easily have it at hand, too. http://www.omg.org/spec/UML/2.5/Beta2/ – Gangnus Apr 15 '14 at 07:45
  • It could be in theory... We could dive into UML spec and look for the formalism, and there is generally more than one solution. However, I am always looking for a pragmatic solution that is overall clear. Association between 2 classes indicates some kind of "strong" relationship and it is commonly mapped to an class's attribute. Dependency is there to show these "weak" and short-term dependencies, established in run-time inside the methods... Code generation softwares also tend to generate attributes from the associations – Aleks Apr 16 '14 at 08:33
  • @Aleks " Association between 2 classes indicates some kind of "strong" relationship and it is commonly mapped to an class's attribute." No, only dotted one. It is not formalism, you are simply mistaken. And if you are throwing off citations from UML standard as formalism, what are you talking about at all? What IS the criteria of correctness then? Go to wiki and study the technic of discussions. – Gangnus Apr 16 '14 at 09:08
  • Can you tell me where I can read about the 3 types of aggregation you have mentioned? – P.C. Apr 16 '14 at 17:27
  • @PrernaChikersal Download http://www.omg.org/spec/UML/2.5/Beta2/ (2.5 differs with 2.4.1 only in the way of explanation - it is easier to read), p. 109 – Gangnus Apr 17 '14 at 08:40
  • @Gangnus I am not "throwing out" citations from UML, only trying to be aware of its limitations and problems. This is not the place to discuss this wide topic, but after almost 2 decades of UML it still does not have widely support in the developers community. I don't see this forum as an academic research of the 1000 pages of metamodel, but rather as a tool to help people build useful models that lead to efficient project communication and effective development. And I am definitely not wrong as you said, my proposed solution (dependency) is perfectly consistent with UML. – Aleks Apr 17 '14 at 08:46
  • @Prerna Chikersal In the UML specification, they are "types of association". "A binary Association may have one end with aggregation = AggregationKind::shared or aggregation = AggregationKind::composite. When one end has aggregation = AggregationKind::shared a hollow diamond is added as a terminal adornment at the end of the Association line opposite the end marked with aggregation = AggregationKind::shared. The diamond shall be noticeably smaller than..." – Aleks Apr 17 '14 at 08:50
  • @Aleks I have never said that dependency cannot be a solution here. Any association can be shown as dependency, too. I have said that you are wrong saying that it is the only solution and association cannot be such. – Gangnus Apr 17 '14 at 09:02
  • @Gangnus I fully agree, notationally both are correct. I'm just of an opinion that association can be kind of misleading here, as it is commonly used for "stronger" dependencies, like class properties. I simply find dependency more accurate in this case. – Aleks Apr 20 '14 at 00:04
1

This is a clear example of dependency between 2 classes, a short term relationship established in run-time. No further filosofy.

Aleks
  • 5,674
  • 1
  • 28
  • 54
0

Since you have only a reference by a local variable in a method, there is no association (and hence, no aggregation) between A and B in your example.

Otherwise, sfinnie is right with his statement (in uml-aggregation-vs-association) that "Aggregation is semantically so weak as to offer nothing practically beneficial." So, you shouldn't waste your (and our) time asking this question.

Community
  • 1
  • 1
Gerd Wagner
  • 5,481
  • 1
  • 22
  • 41
  • Well, I need it for a school project. This is what my code looks like. I am trying to accurately represent it in a class diagram – P.C. Apr 16 '14 at 17:25