Difference between Aggregation and Association

[thomaskilian]

There are two distinct connectors: Association and Aggregation. If you use them from the toolbox and check their properties, you see that they are different elements. But: you can open an Association's properties, set either end to "composite" and voila, you have an Aggregation. This one looks exactly like the Aggregation element and seems to have the same properties. But the properties stilll tell that this is an Association.

Question: why two different elements? Is there a difference?

[«Midnight»]

I've seen this too. When you are parsing a model through automation, particularly when you need to wade through a complex package, this can really trip you up.

I keep thinking that the 'option' ea gives a user allows an "association" to be turned into an "aggravation."

On the surface this appears to be EA helping the user, who may have to 'upgrade' a simple association from earlier in the design process when it comes time to be more detailed. I think it is worth looking into the UML specification documents to discover whether there really are two entities here (EA does not handle all of the approximately 38 classifiers and other entities, but it does address more than it first seems).

Perhaps the Sparx folks have a ready answer...

I'd love to know, since this really fouls me up when I try to accelerate model parsing via the database.

[thomaskilian]

...which was the reason for my question

[Paolo F Cantoni]

...which was the reason for my question

I gave EA Aggregations away almost as soon as I came across them.

See WARNING: Aggregations vs Aggregate Asscociations  This was nearly a year ago.  Sparx may have changed how they work, but in my view they are anathema.

Paolo

[KP]

I think it is worth looking into the UML specification documents to discover whether there really are two entities here

In UML 2, the class is Association and aggregation is an attribute of the member end Property; In UML 1.5, Aggregation was a class. Therefore, EA's Aggregation connector is a relic from UML 1.5 that hasn't been deprecated yet. NB: both associations and aggregations should codegen correctly, and both should export to XMI as associations. NB2: to stop it tripping you up in automation, you could write a function "IsAssociation()" to test for either.

I keep thinking that the 'option' ea gives a user allows an "association" to be turned into an "aggravation."

Yes, aggravation is the correct term.  

[«Midnight»]

Thanks Neil,

This actually makes sense, and may go some ways towards resolving the issue Paolo was referring to.

Methinks I will adjust my UML toolbox to remove the UML 1.x 'aggravation' entity, then use associations and set them as appropriate.

Thomas, here is another really useful thing that could come from your 'helper' add-in idea. We could come up with a couple of custom routines that grab an association when you first create it, and then do the background work to make it an aggregation (note the UML 2.0 spelling) or composition. Then we could add a tools to the toolbox with the appropriate graphics - recycling the 1.5 icon removed earlier; not only nifty, but green too!

David

In the meantime, I'll create some kind of function per Neil's suggestion, as well as one to hunt for anything strange in the background database. Sigh...

[Paolo F Cantoni]

Methinks I will adjust my UML toolbox to remove the UML 1.x 'aggravation' entity, then use associations and set them as appropriate.

Given Neil's explanation, I'd suggest Sparx remove it fro the UML 2 toolbox.  
It seemed to me that it was a hangover, but seeing as no one outside Sparx sees the product road map, it was difficult to determine if this was in fact the case or if there was a plan to deprecate it...

Paolo

[thomaskilian]

Thanks Paolo for pointing me to your almost 1 year old thread. I'll stick to that and get rid of these aggregations

Neil,  wouldn't it be possible to replace the element in the toolbox so it generates an association with composite/shared side instead of this aggregation?

[«Midnight»]

Agreed, all.

And yes Thomas, that's just what I was talking of.

But, given the tendency of holdovers (hangovers) to be persistent, one needs to know whether Sparx will handle this in the near future.

If there's still a chance for it in 6.5, I'd be happy to wait for it. Otherwise I think it would be a good idea to build this functionality as an add-in. It take the labour out of doing the right things right, which is half the battle in getting things done at all.

In shared models - particularly where there are multiple developers - this is the kind of thing that gets completely out of control. As long as anyone has access to the 'old' way of doing things policing the model becomes a new, vital task, with zero net productivity. As a project manager from way back this is guaranteed not to improve my day...

[sargasso]

I'd like it NOT removed.

I have clients who still use 1.5 spec as the corporate standard for existing systems.  (Too many models to migrate!)  Just because you've got a brand new Masserati doesn't mean that all mechanics in the world have to throw out their tool chests and get new ones.

b

[«Midnight»]

Sorry Bruce,

That's definitely my bad. I had meant that it should be removed from the default selection in the UML 2.0 setup.

Of course it should not be removed from either the EA product (absolutely not!), nor should it be removed from the default list for UML 1.x.

This is what comes from speaking while trying to change feet. I'm so embarrassed...

David

[thomaskilian]

Just as a reminder to Sparx for 6.5: this aggregation thingy is also generated from the quick linker. I'd prefer this also to create an appropriate association.

Thanks.

[SF_lt]

Thomas, register^tm   as suggestion/bug

[thomaskilian]

I forgot that indeed