Method Constraints

[superfly]

Gday,
A long time disgruntled rose user, I have just started evaling ea. Looks v good so far.
Are the pre and post constraints on a method able to be generated as comments in code? Do they serve any other purpose than duocumentation solely within the model?
Thanks

[thomaskilian]

I'm not much in code generation but I'd vote for keeping code inside program files and (global) documentation inside the model. What would be the advantage of having the constraints as documentatory text in your code? Or would you like to have the code gen produce something like an assert?

[superfly]

Well having something generated assert like would be ideal, mind you it would have to be very customisable as everybody has a differnet way they're going to want to do this:). I suspect sparx has bigger fish to fry as this would be pretty complicated albeit very useful.

As for documentation in code - it can't hurt to have the contract documented in the code as
1. a reminder to implement the appropriate asserts
2. someone IS going to have to edit this code one day without access to the model.

After all any comments you put in the Notes box end up both in code and in the model.


Cheers

[mikewhit]

Well it might be nice to have constraints appear in Javadoc/Doxygen comments, for documentation purposes, so it's better that this comes straight from the model.

Though I've not worked on the "code gen" end of things yet so don't know if I'm talking rubbish ;-)

[superfly]

Agreed, that's my question, can you get the constraints as documented in the model to appear in the code in some format?

[mikewhit]

Having looked in the Field Substitution Macros page of the EA help file, I can't see any way of extracting the Element Properties: Constraints.

Must be a deficiency in EA, in which case, why not submit it to the Bugs or Feature Request forums ?

You ought to be able to get any property of an element in a straightforward way, without recourse to Addins, but ...

... a post in the Automation forum shows that there is a way to get a property, if you produce an Addin that can extract the property you want:
http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.cgi?board=Automation;action=display;num=1094146636

I imagine that the 'classic' way would be to do this with VB, though from my point of view, I would try this with Perl (ActiveState) and Win32::Ole

[superfly]

Gday,
Well that'll teach me for asking.
Had a look into what you said and had a play with the templates on another issue and see what you mean. Suspect it's on their extensive TODO list somewhere anyway but i'm compiling a a bit of a list I'll submit to them once I know ea a bit better.

Way too lazy to write an addin. I'm already having trouble justifying the amount of time I'm spending messing with this already. Mind you it'd just be an OCL parse away from automatic gen of pre/postcondition checking  code.

Still I'd better get some real work done this year.
CHeers

[Eve]

Look forward to getting your list.

We don't mind making generically useful enhancements to the code generation templates.  Field substitution macros are easy to add, so sure I don't mind.  (The hardest part about adding them is adding them to the help, and I don't need to do that.

Simon

[mikewhit]

Field substitution macros are easy to add

Why have explicit separate macros for various attributes, rather than (e.g.) a document object model approach where you can navigate to the property you want - in effect doing in the macro what you would otherwise be doing in the VB.

This could be a string parameter parsed at runtime
Field("element.link.property")
rather than a template language construct
Field.element.link.property.

Of course, any error at run time would have to return  "#undefined property#" or somesuch.