[Uml-devel] Code generation proposal, take 3

Brian Thomas thomas at mail630.gsfc.nasa.gov
Thu May 15 09:01:05 UTC 2003


On Thursday 15 May 2003 09:07 am, PF wrote:
> [snip]
>
> 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?
>

	No, I think its possible to add in a selection to view the code of the active
	language for that class in the class properties popup that wont be difficult
	to understand/find/use. This "code properties" view might be arranged like:

        -----------------------------------------------------------------
        |   Code Generation Settings for this Class |
        -----------------------------------------------------------------
        |                                                                               |
        |               <colorized class code here>           |
        |                                                                               |
        -----------------------------------------------------------------

        Code generation settings envolving things like whether or not you want 
        accessor functions, etc.  IF you click on a certain colorized chunk of 
        the code, it could popup the appropriate dialog for that UMLObject so 
        you could change it easily. For example, in the following code:

        void Function () { <blah blah blah> }

	might all be the color red. IF clicked on, then it would cause a popup 
        editor for the "FUnction"	operation (this already exists, we just
       need to make the linkage). In the popup, you can change the name of the 
       operation, the body of the code, the operation parameters, etc. When you
        "apply" or "close" the operation edit popup, a signal is sent to 
        regenerate the class code and to update the view of the code for that 
        class. Note that some language specific stuff would also have to appear
        in the operation editor dialog popup, for example, if the active 
        language is "C++" the ability to make that operation "virtual" would 
        be there.

	And speaking of C++, you would want to be able to view both the .cpp 
        and the .h files. This may be satisfied by allowing the code view 
        window to be tabbed, allowing the choice. Both views are colorized, and
        have "clickable" code short cuts to the appropriate UML dialog
	popups.



> >            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.

	I disagree that it will be clumsy. I believe the GUI issues may be 
       sorted out.
	I DO agree that many types of selection need to be available. 

> 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.

	Well, Im not sure I agree here as I would like to see some
	"scriptablity" for creation of the accessor methods from class 
        attributes.
	Obviously, various languages have different default scripts. 
       Ultimately, these scripts would be used by the code import/
       roundtripping to identify new operations/methods etc. In this manner, 
       the diff3 chunk you get may be easily identified and inserted in the UML
      diagrams.

> 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.
> [snip]

	Exactly. I just think that these rules will vary from language to language
	(unless I misunderstood you on this point).
>
> >            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.

	Well, I dont want anything so sophisticated right now. I feel that code
	import and roundtripping are a 2nd stage effort. I'd be happy right now
	to just do better code generation control. Im not saying these issues 
        arent
	important or worth considering in the current design, just that I dont
	want to fully address them and implement them until the basic ability 
	to control and view code generation is improved, as per my proposal.

>
> >            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.

	Yeah, there are a variety of ways to go about this. Im not feeling too
	strongly one way or the other about what is the right direction at this
        time.

> >       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).
> [snip]

	Yeah, sounds like we are in complete agreement on this. Im taking alook
	at your codesystem.xmi file today, and will feed back comments as they
	occur to me. 

	If you willing to collaborate then with me on this effort, perhaps we 
        can work to merge our proposals. Of importance is the different view on
       scope of the work. It sounds to me that you are having a broader scope,
       with issues of code import and roundtripping that I dont want to address
       at this time.

	 Let me know. 

						=b.t.

-- 

If you _really_ feel this strongly about the bug, you could
either try to increase the number of hours a day for all of
us or you could talk to my boss about hiring me as a consultant
to fix the problem for you on an emergency basis :)

	- Rik van Riel explaining what to do against kernel bugs





More information about the umbrello-devel mailing list