Code generate collection classes (C++)

[d_p_robinson]

I'm having problems getting EA (beta 2) to generate code for collection classes.

I have:

Class1 has directed association with Class2 as target, multiplicity 1..*, i.e. Class1 holds a reference to one or more instances of Class2.

I followed the instructions in the help for generating collection classes for association roles, setting up collection classes for Class1. No matter what I did this always resulted in raw pointer to Class2 being generated as a member for Class1.  

Time to think outside the box, EA sometimes being less than intuitive...

Setting the collection class on the contained Class2 results in a collection class being generated. Surely this must be wrong as Class2 should have no knowledge of how it is being contained!  

In addition to this it would be nice for the qualifier entered in the source role for the association to be referenced as a marker in the code, much as #TYPE# is replaced by the name of the class.

[«Midnight»]

[Before you go too far with what I state below, take a moment to read through the EA 7.0 release notes for betas 1 and 2. You can find these in the Latest News section of the forum. If you have access to the beta, you might want to use it for the tests below.]

If you open the Tools | Options dialog, then look at the various languages under Source Code Engineering, you'll see that some offer collection classes for 1..* associations while others do not.

Furthermore, there is a properties dialog you can open for individual attributes in a class, where you can specify whether an attribute is itself a collection.

It is likely worth playing around with these settings, to see how EA defaults things for each configuration. If you are still unable to get things the way you want post back, telling us how far you get, and what the results are.

If nobody can resolve it from there perhaps either a feature request or a bug report is in order.

David

[Eve]

The collection class settings on a class are for containers of that class.

This is less useful if you consider templates/generics, but consider an example without that.

I have a class called Foo.  There are non-typesafe containers available, but I want typesafe containers for Foo.

So, I create classes FooList and FooMap and set these as the collection classes for Foo.

[d_p_robinson]

I'm using 7.0 beta 2 (build 811).

Furthermore, there is a properties dialog you can open for individual attributes in a class, where you can specify whether an attribute is itself a collection.

An association does not get modelled as an attribute until the code is generated and then reversed.

Digression: This in itself is an issue because IM(H!)O a relationship should be modelled as either an association of some kind or an attribute. Otherwise if the modeller changes the name of, for example, the attribute but not the association when code is regenerated a new member is added to the code. Not only that but if the association is moved on the diagram to a different target the attribute is left with the original type. I guess this has been done to death in other threads

The collection class settings on a class are for containers of that class.

My main bone of contention is that EA forces the collection class to be specified on the target (owned) class and not the source (owner). This is just plain barmey. What happens when I want to contain a class by two other classes, in one instance mapped by string and in the other by int? I can't do this because EA uses the collection class specified by the collected class.  

I have a class called Foo.  There are non-typesafe containers available, but I want typesafe containers for Foo.
 
So, I create classes FooList and FooMap and set these as the collection classes for Foo.

I've used typedefs for this, for example:

Code: [Select]

typedef std::map<std::string, AClass> AClassMap;
AClassMap mAClasses;


The trouble with this is that all you get in the model is the association to the typedef class, the link to the contained class(es) is lost.

So, what I would like to see in EA is:

• Associations reversed as associations only and not as attributes as well.

• Collection class specified by the owner of the collection.

• Even better: specify the collection class on the association, where it properly belongs

• Qualified collection classes to code generate using the qualifier as well (for example map<#QUALIFIER#, #TYPE#>). At the moment it appears that the qualifier type is ignored.
  

Not to mention world peace, an end to poverty, ...

[Paolo F Cantoni]

Go for it!

My colleague Darren and I posted some stuff on the necessary coupling between attribute and role.  IF you've already found it and agree, perhaps you could add some support and thereby "bump" it.

Your other points are well taken and, in my view, sound!

Incidentally, if Sparx make the necessary changes to put the collection semantics on the Association, then they can also move the Realization, Specialization and Meronymic semantics there also - thus "killing a flock of birds with one stone"!

Paolo

[Eve]

EA currently provides three levels of specification of the collection class that override each other appropriately.

• Language
  
• Class
  
• Association (It's the Member Type field on either end of an association)
  

[sl@sh]

• Collection class specified by the owner of the collection.
• Even better: specify the collection class on the association, where it properly belongs

I'd go with the latter. Consider a class A that owns both a list of class B and a map of class C. Or just a list and a map both of class B! You cannot properly model this unless you assign the collection type to the association.