[Uml-devel] Code generation proposal, take 3

[Brian Thomas]

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

	Ok, I took a look at your XMI. Here's my summary of an hour-long 
        comparison:

	- your proposal is similar to mine in that you are mapping the output
        of the writeclass() method in codegenerator to a complex heirarchy
	of classes. This representation of the code to be written is then manipulatable
	by the Umbrello tool.

	- Differences appear from that stage onwards, and include:

	   * you have more consideration of code import and differencing.
           * you have more consideration of code collision and resolution between
             what is autogenerated and the user content (I think).
           * but you also have a simpler representation of the code in Umbrello. From what I can tell,
             it is "file" and "class" oriented, meaning these are the smallest manipulatable
             "units" in your represenation of the code. My proposal allows for attaching
            assosications between UMLObjects like associations and attributes, and 
            can handle much finer-grained control of the code output. Your "FilePack"
             class appears to be similar in function to my "CodeDocument". 
             But your FilePack class appears to only support representing a single document.
             This sort of functionality i sneeded to support languages like C++ where
             a class is represented by 2 or more files (in the case of C++, a ".cpp" and
             a ".h" file) Im sure FilePack could be extended to get around this problem, 
             but it might be a pain to do so.
             Also, there doesnt appear to be any way in your package to change the
             code generation parameters ("policy") for various classes.
          * You handle the header file issue implicitly with a headerPack class. I would
             simply create this as another "codeDocument" as needed. Neither solution
             is more "correct" than the other.
          * My proposal has more consideration of the widgets which are needed, and
             is designed to be extensible (or, at least, has examples of it being extended)
            for particular languages.
          * Because my proposal is "document" and "UMLobject" oriented, I believe it 
            will map better onto more languages (in particular XMLschema generation)
             where the orientation is more complex mapping than simple file is equivalent
             to a class.
          * Both proposals appear to support "external" documents which dont map to
            any class. Both proposals appear to have needed hooks to do the eventual
            code import and roundtripping.

	I believe its possible to merge these proposals, but I would like to know what
        your "NullFileNameTool", "CapitalizeFilenameTool", "underscoreFilenameTool"
       "substitutionFilePathTool" and "FlatFilepathTool" are used for. (sorry, I cant
         figure it out from the names ..)


	and a side note, while Im here....

	After I wrote that last email about having the same class in multiple associations
         in a class diagram I realized that this sort of thing *does* occur in commerical
         UML packages. In both Poseidon and MagicDraw the code import has a 
        configureation option of whether to choose to model associations with other
         classes as "attributes" or "aggregations" of that class being imported.

					-b.t.


> --pf

-- 

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