[Uml-devel] codegenerators

[P. Fleury]

Brian Thomas wrote:

>On Sunday 20 April 2003 11:13 pm, Pascal wrote:
>  
>
>	Umn, perhaps I dont understand round-tripping, but I thought what
>	you just mentioned IS roundtripping, e.g. make a edit in the code and 
>	then the UML diagram updates and vice-versa. Can you describe
>	the "limited usability" of diff3 so I understand it better and how it 
>	diverges from round-tripping? Do you mean just to not let Umbrello
>	blow away your edits in the code? I think there are still problems here.. 
>	for example you may ADD a method that doesnt exist in the UML. 
>	Later on, you decide to add the method (operation) to the UML class. 
>	What should Umbrello do then? and that is assuming that it recognizes
>	that both the method you edited and the operation are the same thing.
>	The code to do that is pretty similar to what is needed for full round-
>	tripping. Right now I dont see how you can go "halfway" with this sort 
>	of thing and do a decent job.
>
>	I also want to reinforce that I DONT want round-tripping right away. I 
>	just would be happy to be able to better control the action of the code
>	generation from the UML tool with perhaps some ability to "preview" 
>	the code that would be generated.
>
>	BTW, I've been wanting to work on the code, but alot of instability has
>	appeared over the last few weeks and Im waiting for the hacking on the
>	diagrams to die down and stabilize before I start.
>  
>
Sorry, I was never good at explaining even the simplest stuff in a clear 
way...
My suggestion does not imply round-tripping, because I do not expect 
manual changes in the code to be reflected in Umbrello. Only if I add 
something in Umbrello, it will be reflected in the code, after 
generation, but without wiping out what was there before. The real 
reason for this is that I tend to write my classes quite small, and have 
accessors for many things, so these are all inline. This should not be 
removed during code generation. But if I add a method in Umbrello, I 
would like the code generation to add that method to the class. However, 
if I add manually an accessor to my class, I will have to make the 
change in Umbrello too. I think this is not a big problem, as we very 
well can manage having umbrello open in a window, and whatever IDE or 
editor open in another window. The integration here is the kwin part :-)
In case of conflict, as your example mentions, I would let this up to 
the user. There are graphical tools for that, especially if using a 
diff3 which can be presented with e.g. kompare.
I know this is quite limiting, but with little effort we could improve 
the usability quite a bit.

>
>  
>
>>I think too that round-tripping is a hard problem, but the source of
>>this is that the code analysis part has to deal with getting from
>>low-level information (the source) to higher-level features. A state
>>diagram or sequence diagram can be tricky to figure out automatically...
>>    
>>
>
>	No question! I certainly dont claim to know how to do that myself so	
>	I couldnt begin to code a program to do that. IMO the sequence/state
>	diagrams are of little use for code generation in their current form.
>	There just isnt enough information specified in them so that they 
>	can be successfully integrated in with class/object diagrams. I 
>	think the UML designers will have to do a much better job on these 
>	types of diagrams before code generation using them can be a reality
>	(and that may take many years from now to be a reality). In fact the
>	weakness in many of the UML diagrams leads me to believe that
>	the software community will eventually scrap UML in favor of something
>	else, or UML will morph tremendously in the next few years.
>  
>
I think that UML has been designed to convey information about software 
architecture. Its (relative) simplicity is therefore necessary. It has 
also had the benefit of bringing everydoby in using the same "language", 
which I think is the biggest achievement of UML.
No doubt, for code generation, there will be more, but maybe as a "next 
step" or additional information. The same state diagram can be 
implemented in many ways, so giving additional information can make the 
selection of the way possible. If this is embedded within UML, I fear 
that the "pattern reuse" will suffer, because the pattern should be 
abstracted from too many implementation details.

--pf