Set Association Specializations

[hglathe]

Hi,

I have to introduce several specializations on an aggregation.
See 'Set Association Specializations' under EA UML Help.
Having a look on the example in the UML Help of EA you can see {subsets...}-qualifiers on the specialized association ends.

In my own model, I also defined such specializations but the {subset ... }-qualifiers doesn't appear in the diagram.
Is it manually attatched in the UML Help example or do I miss the option to enable the feature for displaying this informations?

Hope, I made my point clear...

Thanks in advance, Helko

[KP]

Looks like it doesn't display for aggregations. You will need to use associations instead of aggregations, or send in a bug report.

[Paolo F Cantoni]

Looks like it doesn't display for aggregations. You will need to use associations instead of aggregations, or send in a bug report.

Hi Helko,

DO send in a bug report.

Aggregations should be Associations with AggregationKind set - but they're not.  There are MANY palces where Aggregations behave one way and Associaitons with AggregationKind set behave differently..

Paolo

Concistency, konsistency, consistensy! ^TM_{Uffe - after Paolo}

[hglathe]

Hi I will make a bug report.

Can you tell me the difference between an inserted association and an inserted aggregation?
Both are associations right?
If I draw an association and define its target end as to be a composite or aggregation in the details property section. Isn't it exactly the same as when drawing an aggregation between two classes directly?
The properties of both 'associations' shall be the same afterwards. Or isn't it?

Regards, helko

[qwerty]

EA has introduced a dichotomy by defining a Composite meta-type which is derived from Association. But it still has properties on Associations which make it appear as composite. So a Composite and an Association with composite property look the same but from EA's perspective are different.

q.

[hglathe]

OK I understand the what but I don't understand the why.
What is the reason for EA to introduce two ways for modeling aggregations / compositions? If both ways are ending in different model elements: What of them are better for later model transformations (e.g. derive a logical database model with primary and foreign keys etc. from a first conceptual model which has been modeled as an uml class diagram).
What of them is 100% compliant with the UML standard? I guess I have to use simple associations instead and set the aggregation/composition property at the association ends manually.

Regards, Helko

[qwerty]

We call that EAUI - EA Unique Interface. Swallow it or die. You might try to ask for bug correction or a feature request. This works - in parts. But EA never is getting more consistent. Maybe this is the nature of the thing.

q.

[Geert Bellekens]

Helko,

If you are using a recent version of UML you should definitely only use associations.
I suspect that the aggregations (as a different meta-type) have been introduced way back in the beginning of the product (and UML), and they've been hanging around since then for backward compatibility.

Geert

[hglathe]

We call that EAUI - EA Unique Interface. Swallow it or die. You might try to ask for bug correction or a feature request. This works - in parts. But EA never is getting more consistent. Maybe this is the nature of the thing.

q.

Sorry, but 'swallow it or die' is not very nice. You can call it whatever you want. Now if have to replace all the EAUI-flavoured aggregations through simple asscociations and give them aggregation properties manually.
It is not a bug, you're right. But it is also not intuitive and leads to misunderstandings.

Regards, Helko

[Makulik]

Sorry, but 'swallow it or die' is not very nice. You can call it whatever you want.

Hmm, I think q. just wanted to give a statement how things with EA actually are: Working with EA is not always like holidays on a ponyfarm.

IMHO it's still a really good tool (if not the best) compared to others, and usually you have a good chance to work around it's obstacles in various ways.

Just my 0.02$
Günther

[Paolo F Cantoni]

Helko,

If you are using a recent version of UML you should definitely only use associations.
I suspect that the aggregations (as a different meta-type) have been introduced way back in the beginning of the product (and UML), and they've been hanging around since then for backward compatibility.

Geert

Unfortunattely Geert, depending on your needs, you can't (surprise, surprise).

You can't create Aggregated Associations with the Quicklinker..,. (for example).  THere are other places where EA doesn't recognise Aggregated Associatins as Aggregations.

Overall I've found I've had to resort to EA Aggragations/Compositions.

Unsatisfactory ALL round.

Paolo

[Geert Bellekens]

Hmm, even worse then.
I feel like it shouldn't be too hard to get rid of this one would it?
I mean what would it take? Change a few lines of code to create associations with the appropriate aggregationKind, and do a one-time cleanup in the t_connector table.

Maybe if we complain loud enough? :-/

Geert

[KP]

Change a few lines of code to create associations with the appropriate aggregationKind, and do a one-time cleanup in the t_connector table.

But that would break every customer add-in or script that performs an if Connector.Type="Aggregation" and every custom query with a where t_connector.Connector_Type='Aggregation' clause.

You could write yourself an add-in with an EA_OnPostNewConnector function that checks for an Aggregation and converts it to the equivalent Association...

[Geert Bellekens]

But that would break every customer add-in or script that performs an if Connector.Type="Aggregation" and every custom query with a where t_connector.Connector_Type='Aggregation' clause.

I understand that, and I would be overjoyed when something like that would break one of my add-ins, but if you always want to be backwards compatible that will eventually halt every progress.
I'm afraid you sometimes have to make hard choices.

Geert

[qwerty]

There's a fruity company which for long time tried to be backward compatible (a tiny one still holds on to this). Once they made an X and threw away all those burdens. And still they do. Guess why they are so successful. 'Death is very likely the single best invention of life'

q.

P.S. What a coincidence. My 1111th post (under this account)