Aggregation relationship

[Si Perry]

Version 3.0 looks excellent - keep up the good work.

I was surprised to see that the aggregation relationship still seems somewhat quirky!

Drag the relationship from class A to class B, I would expect A to be the source, B the destination, with the diamond at the A end. What happens seems to be the reverse.

If I then reverse the direction (diamond now at A) and generate C++ source code, it sort of works...

I correctly get

B* m_B;

generated in class A. However:

1) Class A does not have the include of B.h (infact, B.h gets A.h incorrectly included)

2) Get/Set methods do not appear to be generated

3) Changing the containment at either end of the aggregation does not change how the link to B is represented (pointer, reference or value).

Are there any plans to address these issues?

Many thanks
Si

[sparks]

Hello,

I have made a note of your issues and we will look at them in the near future.  Thanks for the feeback.

Paul Mathers

[unnamedharald]

I also am surprised this problem still exists.  If I want to generate code I have to temporarily reverse direction of all aggragate relationships.  This is more than a pain when using even a moderately complicated diagram.  I have messed up too many diagrams this way so I currently do not use EA to generate much code.

Still, EA is an excellent tool.

[sparks]

Hello,

We have changed aggregations in the latest release of EA (build 423).  Can you download and retest the problems you were having.  Let us know if you have any other problems.

Paul Mathers

[Si Perry]

Hmmm....

Still doesn't seem to be working.

1. No notice seems to be made of the default Reference setting (i.e. for C++ & or *). Always seems to use *. This seems to apply to ALL code generation, and NOT just associations.

2. include of "part" class header still not appearing in "whole" class header

3. Get/Sets seem a bit "fuzzy" in their operation...by this I mean that I expected them to be automatically created, since the box is ticked in the code generation properties. In fact I can't work out what this option does.

It was only by playing around that I found by ticking the "Property" box for an attribute, giving the attribute a property name, pressing save and THEN pressing the "Create" button that appears that I get some Get/Set methods created - hardly an automatic operation! Also, I couldn't find anything in the help file about this.

I was also surprised that these generated methods have NO default behaviour generated for them - I expected them to Get/Set the attribute as appropriate. At the very least, putting the Property name as a comment after the attribute would allow easy matching of Get/Set to the attribute. Even better would be to use the attribute name by default and allow a property name to be entered if required.

I am currently working on a system that has many classes with many attributes that need Get/Set methods. Having to give each a property name, press the button and then enter some default behaviour seems rather time consuming for something that could be completely automated.

4. The "part" class still seems to have a member referencing the "whole" class, irrespective of what setting I apply to the relation direction.

Hope these comments help. If the problems are due to me not using EA correctly, please let me know!

[sparks]

Hi,

Aggregation has proved a surprisingly difficult relationship to get a handle on. Some people expect one set of behaviour - others the opposite.
Going back to the UML Specification (version 1.4) p. 2-22 the definition states

"aggregation :
when placed on one end (the "target' end), specifies whether the class on the target end is an aggregation with respect to the class on the other end (the "source' end). Only one end can be an aggregation.
Possibilities are:
none - The target class is not an aggregate
aggregate - the Target class is an aggregate; therefore the source is a part and must have the aggregation value of none
composite - The target class is a composite; therefore the source is a part and must have the aggregation value of none. The part is strongly owned by the compositie and may not be part of any other composite.
"

The diamond is placed on the aggregate end (target) and the part end (source) is left plain.
So if one draws an aggregation link from source A to target B, B is the aggregate by default and shows the diamond.

I checked this with a couple of other tools out of curiosity and the behaviour is essentially the same as above -
draw from A to B -
make link an aggregation
B by default is the aggregate (with diamond)

So when generating code the expected behaviour would be for B (target/aggregate) to have a variable (reference or value) to the part (A)

Header files will be addressed very! shortly (apologies for that)

Getters and setters are not generated by default ... this could be added if the contained type was a pointer or reference - which brings up the containment issue. Some of this was modified for the very latest release of EA - I will recheck the output and correct any further problems here.

Hope the above helps - we have tried to follow the specification as closely as possible - but are always open to other ideas and suggestions.

Geoff Sparks

[MMI]

The C++ code generation problems with an aggregation/containment relationship are still present (I am using EA 3.1.0 Build 457).

I have 2 classes with a containment relationship. When I generate the C++ for the 2 classes I can get an instance of the source in the target. However, a #include is incorrectly placed in the .h file for the source, and the #include for the source is missing in the target .h file.

Is there any plan for fixing this bug, we have quite a lot of containment within our design.

Thanks,

M

[gsparks]

Hi,

I just checked this out and have corrected the problem - thanks for letting us know. We will be posting the latest build of EA later next week - and the modification will be in that release.

Regards,

Geoff Sparks