[Uml-devel] Code generation proposal, take 3

P. Fleury fleury at users.sourceforge.net
Thu May 15 23:45:05 UTC 2003


Hi Brian,

I think were on the same wavelength. Note also, as mentioned by Luis, I 
have not been thinking about round-tripping *at all*. Originally, I 
started that because I wanted the diff3 way of outputting code into a 
set of files I already modified by hand.
Further comments inlined.

Brian Thomas wrote:

>	   * you have more consideration of code import and differencing.
>  
>
I have not considered code import.

>           * you have more consideration of code collision and resolution between
>             what is autogenerated and the user content (I think).
>
That was the main purpose of me starting on it.

>           * 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
>
Yes. File-grain is left to the code writer modules.

>            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". 
>
No. FilePack is the set of files which are generated for a single 
Classifier. In FilePack, you have the directory fixed, then you can open 
as many files as you want, in just using the getStream(). So for C++, 
you'd use getStream(".h") and getStream(".cpp"), and for my Perl thingy, 
you'd use getStream(".pm"), getStream("Makefile.PL"), 
getStream("README"), getStream("test.pl").
Also, FilePack will make sure it closes the files, calles the 
appropriate finalizer on FileMGr (which then performs the merge).

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

>             Also, there doesnt appear to be any way in your package to change the
>             code generation parameters ("policy") for various classes.
>
Right. I did not want to modify the GUI too much, just add the diff3 :-)

>          * 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.
>
Maybe in using a codeDocument, we could have templates for function 
headers in the cpp portion. In mine, there is no way to do that.

>          * 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.
>
True. My only considerations were to add some in the code generation 
wizard. When selecting the naming convention, you get a set of choices 
(the FilenameTool derived classes). The FilepathTools, which take a 
package and a classifier name and compute the directory and filename (or 
file basename) are language dependent, and are thus provided by the 
corresponding code generator. The two derived classes are just the most 
used ones (for JAva, C++, Python, etc.) to be reused on the code generators.

>          * 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.
>
I'll trust you on the XMLSchema portion. To me a schema is just a sort 
of obscure cluttered XML file with tons of namespacing around :-)
No offense intended:-)

>          * 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 ..)
>  
>
A FilenameTool is given a package name or a class name, and transforms 
it into the naming conventions of the source code.
Hence a classifier named  "The base class" is converted into:
UnderscoreFilenameTool: the_base_class
CapitalizeFilenameTool: TheBaseClass
NullFilenameTool: "The base class"

The FilepathTools convert the package name and classifier name into a 
directory or filename. Hence, for C++, it should return:
getDirectory(pack="org.umbrello.main", class="UMLWidget") => 
"/org/umbrello/main"
getName(pack="org.umbrello.main", class="UMLWidget") => "UMLWidget"
And for perl, these two example yield "/org/umbrello/main/UMLWidget" and 
"UMLWidget"

But, yes, that is probably quite hard to read in the XMI file. It is 
much clearer in my head, but there is no direct XMI export there...

--Pascal
     

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






More information about the umbrello-devel mailing list