[Uml-devel] Code Generation storage in XMI (Was: Re: Some redundant strings in XMI file?)

[Brian Thomas]

On Saturday 13 September 2003 10:27 am, Sebastian Stein wrote:
> I took a look at a xmi file containing some source code. Here we have a
> snipset of an operation. Is the startMethodText="" and endMethodText=""
> really needed? I mean they are given by the signature of the operation
> already stored in the xmi file and can be easily regenerated? Maybe this
> would be a place hard to sync in the future...
>
>         <codeoperation parent_id="14" tag="operation_14" endMethodText="}"
>         writeOutText="true" indentLevel="1" role_id="-1" contentType="1"
>         startMethodText="public int op1 ( ) {" text="// bla bla " >

	Hi Sebastian,

	Well, I have some thoughts on this. First, while the "codeoperation" node appears
	to be generic, it really isnt as it is always nested within a particular "codegenerator"
	node, which has its own lookup table for what a 'codeoperation' object really is
	(e.x Java has javacodeoperation class). So I dont think there will be a problem 'sync'ing'
	the code between langauges.

	But having said that, its true that the startmethodText is 'autogenerated' from the UML 
	parameters, whilst the end text *should* always remain the same. So why is it there then?
	Basically because there is a provision in the code generation structure to allow the user to 
	create 'userGenerated' blocks of code. When that value is set, the user will be supplying the values 
	for start, body, and end text of the method. Often the user may resort to this functionality
	to supply the needed extra detais that are missing in UML, but may be needed by a particular
	langauge in order to create working code.

	But does that really make sense? Reflecting on how one can rely on stereotypes to supply
	some of the needed, langauge-specific 'extensions' for methods (in C++ 'const', 'virtual', etc)
	it probably isnt. What we probably only need to allow at this point is for the user to override 
	the autoGeneration of accessor method bodies and really nothing else. Still, stereotypes only
	take you part of the way practically. For example, imagine a Field (attribute) called "att1" which
	has a starting value of '1' and accessor methods. In C++, the generated code should look like:

	public class <blah> {

	        int att1 =  1;

	...

	        virtual int getAtt1 ();

		virtual void setAtt1 (int value);

	...

	}

	Assuming, of course, that the 'att1' field has the stereotype of "<<virtual>>". But how do I set one
	accessor to be virtual, and the other to be non-virtual (it *could* be desirable)?? Its not really possible
	without allowing the user to take control of the auto-generation of the start of the accessor method. 
	This is the use case I had in mind. To do a mixed case, the user would have to turn off auto-generation
	of accessor methods (optimistically in the future, they can do this on a class-by-class basis, if desired)
	and then create the accessor methods 'by hand' using operations, one WITH the virtual stereotype, the
	other without it.

	So, what have I really said then? I suppose I generally think you are right about the storage. For auto-
	generated methods (accessors or operations) we can leave the 'startMethodText' and 'endMethodText'
	attributes empty, supplying a value ONLY when the method is not 'autogenerated'. This should certainly
	make the code generation XMI section smaller, and perhaps, more readable.

	
					-b.t.