Assocition instead of Aggregation

[juhel]

Hello,

With EA 4.00.729, I create 2 class : Class1 and Class2 and Class2 has a member of type Class1.

When I forward generate the code (in Java) I get :

public class Class2 {

     private Class1 att1;}

Now, when I reverse engineer my 2 classes, EA draws an arrow named 'att1' from Class2 to Class1.

When I right click on this link, I can see that it's an association.

My question is : Why isn't it an aggregation (with a diamond) or a composition?

Regards,

Philippe

[sargasso]

Phillipe,

Consider this.  Create two classes, classA and int. Add an attribute to classA and set its type to int.  Round trip it.  Would you then expect to get an aggregation or composition?

Consider also this.  IMO (and very little experience with java) aggregations and compositions have little use at the physical design level.

hth
Bruce

[Javier]

Phillipe,

You can consider an aggregation a "kind of" association that has semantics for the roles a class A and class B play.  When you forward-engineer the code, these semantics are unambigious and EA is capable of generating the code the way you need it.

However, when you reverse-engineer the code, I gather EA cannot tell whether it would be a aggregation (hollow diamond) or composition (filled diamond) and it punts for a more generic association.  Without going into details, I imagine that the reverse engineering process can be tailored to what you need--possibly it has defaults--or you have to intervene and modify the association by hand.

Bruce,

I disagree with your statement :

IMO [snip] aggregations and compositions have little use at the physical design level.

Although it is true that during initial design it is important just to determine the association--regardless of whether it's aggregation or not, hollow/filled diamond, navigability, etc., I believe it is important to qualify the association correctly.  In our environment we make sure that aggregation is expressed correctly: filled diamonds depict the same lifetime for the container and contained object, while hollow diamonds reflect separate lifetimes.

I compare this to use case design, where you start up by identifying the actors associated with a given use case, and you don't care about who starts the use case initially, but after you're done with identifying the actors, then you start filling up the arrows to convey the initiating and receiving actors.

Regards,

Javier

[sargasso]

You are right - my statement as it stands was out of hand and incorrect.

[TrtnJohn]

 In our environment we make sure that aggregation is expressed correctly: filled diamonds depict the same lifetime for the container and contained object, while hollow diamonds reflect separate lifetimes.
Regards,

Javier

Javier,

I always get confused by this also.  I like the way that you use them though.  But, does this mean that you never user generic associations for classes?  I've always thought of the 2 aggregations as either "Has a" or "Must have a" relationships.  I am not sure what you mean by "Kind of" association.    Can you give more details?

Thanks!

[Javier]

TrTnJohn,

In the most generic terms, all associations can be represented with a dashed arrow and a stereotype.  Bidirectional associations with two dashed arrows, one on each direction

for example, generalization can be a dashed arrow and a <<specialize>> stereotype, composition can be a dashed arrow and a <<has a>> stereotype, etc.

Several of the associations are so common that they deserve their own icon, aggregation (hollow diamond) being one of them, and composition (filled diamond) being another.  Thus my comment on the "kind of" association.  You can think of composition as a kind of aggregation (explanation below).

Now, regarding your comments on aggregation and composition, it is important to note that aggregation (your "has a") has a lifetime implication.  An aggregated instance may have a different lifetime than the aggregating instance.

Composition, on the other hand (your "must have a") , implies that the aggregated and aggregating instances have the same lifetime.  Whan A goes away, B goes away.

Notice that the UML does not say whether A and B are associated during construction of the aggregating class or whether the association is built by calling a method in A after A is constructed.  This is in line with UML, since it takes care of the "logical" design aspect.  In C++ there is another aspect that it's called physical design (by John Lakos).

Lastly, I use generic associations in my designs.  For example, if I want to have a developer notice that A uses B in some way, just draw a dashed arrow pointing to B to note that A depends in some way on B (i.e., uses it in the class "interface", denoting that interface here means all the methods for A and B is used as a parameter in one of the methods).

Regards,

Javier

[TrtnJohn]

I see what you mean now.  Your "kind of" meant it was like a stereotype of the generic association.  I agree with your description on lifetimes.  Thinking of the classes that way makes it easier to tell what type of association to use.

Thanks for the clear explanation!