[Uml-devel] Code generation proposal, take 3

[P. Fleury]

Hi Brian,

I have also been thinking (and fiddling) with Umbrello for the code 
generation recently.  I have thought about extending the current 
framework a bit less than you did.

Brian Thomas wrote:

>	1. Easy user interface.
>               A. Use existing UML class/association popup dialogs for controlling code generation. 
>  
>
I think this contradict your requirement numbered 0. The existing 
dialogs do not allow you to set some aspects of the code generation, and 
hence you'll need more dialogs. Or do you mean "use the existing 
wizard", but implying that it may have an additional panel or two?

>            C. Support auto-generation of methods  (e.g. in most languages this means ability to auto-
>                  generate accessor methods)
>  
>
I am not sure that this is really part of the code generation. You'll 
have users who want to generate for this member, and not for that 
member, and have it public for reading (get()), but protected for 
writing (set()), or read-only. This will make both the code generation 
and the GUI clumsy.
Note also that if that work is done on the model level, the code 
generations only "see" the methods and attributes and will hence have 
much simpler code to generate all this. And a new language is added, it 
will benefit from that immediately.
One approach is to set rules about the naming of accessors, so that from 
the list of the methods/attributes of a class, a module can "deduce" 
what is a member accessor pattern. This is the JavaBeans way, and it 
would work nicely as we do have the model at hand here. then, in 
Umbrello, you would have a accessor pattern view, which displays only 
the patterns, and enables you to change them, having an effect on which 
methods/attributes are added/removed/renamed, etc.
IMHO the UML diagram shows me details about the data type, class name, 
public/protected/private of methods, etc. Having stuff generated which 
is not in the diagram gives me a hidden layer which I do not like too 
much. All methods and attributes of the classes should be in the model. 
If they clutter the view, then we must modify the view.

>            D. Intellegent collision resolution between away user-specified code and that which is
>                 auto-generated for methods/operations (this is more or less a sub-requirement for 3C)
>
I have been working out this one. Basically, I have split the code 
generator into different classes, with interfaces, so that we can 
specify several filenameing conventions, conversion from a package+class 
to a filename, and a pluggable source code repository. One implements 
the current "overwrite/ask/ignore or write if not existing" generation, 
and another implements the diff3 approach, using kompare to resolve 
conflicts if there are any.

>            E. Maintain current code generation control (e.g. header file stuff)
>  
>
I have kept this, just extracted it out of the CodeGenerator class, so 
that the header is put into the file before the code generator gets the 
file handle, so that code is not duplicated in every code generator.

>	An optional requirement is that outside documents could be auto-generated and controlled from
>	the Umbrello tool. Examples of what I mean are things like Makefiles. Im not sure about this, and
>	perhaps it may be left until Umbrello version 2 to be addressed.
>  
>
I have also thought a lot about this, because I wanted to generate Perl 
modules as if they were created with h2xs. That is, you get the code, 
you get a test.pl, README, Makefile.PL files, and the filenames computed 
from the package+class are also slightly different. (for package 
my.simple.package and class 'theclass', in Perl you'll get 
/my/simple/package/theclass/theclass.pm).

All this is the result of about 2 hours of thinking and playing with 
Umbrello 1.2[ab] :-) and another hour writing code. It compiles, but 
that's it, and it's not complete. FYI, the XMI file is here 
http://www.pafsoft.ch/codegensystem.xmi

--pf