attribute <<Property>> problems

[danm]

Hi,
 A vanilla EA installation offers the <<Property>> (capital P) stereotype for attributes. However, that stereotype doesn't show up as a "Add New Stereotyped Override" in the transformation templates.

 OK, I'll just make a new one <<property>> by entering it into the attribute stereotype field - the tool won't let me enter that but instead recapitalizes it for me. OK, go into the stereotype dialog under UML ... no Property there, so I add it. Still doesn't show up.

 Eh? What is this supposed to be for, and how do I use it, or at least work around it to accomplish the same thing? My goal is to define attributes as properties at a high level model, which then transform into their respective languages. Should be a common use case.

  Maybe it's magically related to the Attribute__Property template. So Property is some kind of internally reserved stereotype.

[Thomas Mercer-Hursh]

See discussion here http://www.sparxsystems.com/cgi-bin/yabb/YaBB.pl?board=Automation;action=display;num=1201476079
and welcome to the magic domain ...

[danm]

Thanks Thomas.

The problem with this magic is that the elves are drunk and can't drive! EA took a patent out on <<Property>> so we can't use it, however it's actually not used internally. Well not quite true. The following picks up the <<Property>> stereotype during 'Attribute Declaration' codegen

Code: [Select]

%if attStereotype == "property"%
{\n\t//read property\n\tget{;}\n\t//write property\n\tset{;}\n}
%endTemplate%

So I guess EA ignores case on stereotypes too. Arg.

[danm]

I *think* I understand.

The property checkbox on the attribute pane is for manually creating property functions. OK no problem.

For high level modeling you should stereotype as <<Property>>, which I believe is supposed to be handled by the Attribute__Property template in the C# transform, for example.  This will code gen the get/set's for you eventually - fine.

Unfortunately, this template isn't being called for attributes which are stereotyped <<Property>>. Huh?

[Thomas Mercer-Hursh]

I haven't gotten far enough in my code generation ... there aren't a lot of pre-existing templates for ABL ... to know whether I have a problem or not.  While aesthetically, I would prefer to have «Property» defined along with all other Stereotypes and for all "magic" derived from that stereotype to be visible and available for modification, thus rendering the Property checkbox moot, if the Property checkbox produces the code you want and it doesn't complain about defining the stereotype as Property for documentation purposes, then it seems like functionally one has gotten to the desired end, even if it is annoying for it to be orthogonal to other stereotypes.

More immediately annoying to me is that the "magic" properties of Table and Column cannot be inherited by any other stereotype.  I.e., I can't define a stereotype «oeTable» for use with OpenEdge databases, which has additional characteristics appropriate to such databases, and which inherits all the "magic" behavior associated with «Table».  Not to mention tacky bits like «OpTable» which are not base types and which are not defined in terms of anything else.

[danm]

if the Property checkbox produces the code you want and it doesn't complain about defining the stereotype as Property for documentation purposes, then it seems like functionally one has gotten to the desired end, even if it is annoying for it to be orthogonal to other stereotypes.

That checkbox only works when you generate code directly from a model. If you're doing MDA transforms, like Model to C# and C++, you would have to go into all your properties in the C# and C++ models and click that box. Obviates the reason for doing MDA.

You could hack it and in your high level model just pick a language convention (say C# or C++) for the getters/setters, but blah. I think Sparx did the right thing here.

And I figured out my original problem. <<Property>> does the right code gen, but you have to set your attribute to Public access. I had it as Private, so the code gen wasn't working correctly.