Bug 53382 - round-trip code import and generation
Summary: round-trip code import and generation
Status: CONFIRMED
Alias: None
Product: umbrello
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: Umbrello Development Group
URL:
Keywords:
: 55248 87179 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-01-24 19:54 UTC by Jonathan Riddell
Modified: 2016-09-06 02:56 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Riddell 2003-01-24 19:54:41 UTC
Version:            (using KDE Devel)
Compiler:          gcc 2.95 
OS:          Linux

I didn't find a way to preserve code inserted by hand into a generated file, for example marking the user-defined block with a start/end comment (many commercial programs do so).
This should allow the whole process of writing a class, generating code, modifying it, importing and generating again... great !!!
Comment 1 Jonathan Riddell 2004-03-27 21:01:02 UTC
*** Bug 55248 has been marked as a duplicate of this bug. ***
Comment 2 Sebastian Stein 2004-08-17 11:59:54 UTC
*** Bug 87179 has been marked as a duplicate of this bug. ***
Comment 3 Oliver Kellogg 2004-12-26 19:37:51 UTC
The C++ and Java generators duplicate the source code in the XMI file, thus making the model file sizes explode - not a feasible approach for IMHO.
OTOH I don't want a tool to clutter my application code with special marker comments required for syncing with the model.

In light of these disadvantages, I suggest aiming a little lower: Support repeated code import. With this approach, the source code is always the master, and the model is synced to the source not vice versa.
Comment 4 A. Rick Anderson 2005-08-17 03:57:26 UTC
Whatever technique is used, the objective should be that code generation and model generation should be inverse operations.  I understand that the problem is that information is lost in both directions.  

Meta-tags stored in Java-Doc comments like comments is one way to deal with the gross, class level structure issues.  Using the 80/20 rule, synchronizing the static model with the static structure of the source in a round-trip manner is a reasonable initial objective.

When I wrote the Java code generator for Object Team, I added a single line, terminator comment at the end of the static elements, such as methods and classes.  We never had any users complain.  In fact, most users liked it and I personally have continued to use this coding practice even in Eclipse just because it makes reading the code easier.
ex:

public class Foo {
    public void myMethod() {
    } // method myMethod
} // class Foo

Comment 5 Chris Bruner 2005-11-30 10:44:39 UTC
Maybe I'm not understanding it right, but when I do a class import, I expected the class relationships to be known (what's a base class to what etc) and functions that are coded to be present in the generated class already. It seems that the importer can determine the function names,data names and class names as well as the comments that go with them, but not anything else.

To me it would seem that if the class importer could gather more information much of what this bug report is about would go away.

Is this a goal, or am I misunderstanding it completely?
Comment 6 Oliver Kellogg 2005-12-03 10:06:08 UTC
> To me it would seem that if the class importer could gather more
> information much of what this bug report is about would go away.

If we edit the model, we want the code to be synchronized with the
changed model.
If we edit the source code, we want the model to be synchronized with
the changed source code.
On doing an update, IMHO an automatic tool cannot decide by itself
which it should take: the code or the model. For example, if a class
is removed from the source code, should it be removed from the model?
Perhaps it was just moved to a different source file and the user
forgot to import that new file.
Comment 7 Chris Bruner 2005-12-04 05:06:46 UTC
I'm not sure if you are referring to my comment or not, but when I said import I would have expected that to be a one time operation, or very infrequently done. It would be used when first setting up the uml to reflect existing code, or if code which was in sync was changed at the source level instead of through the UML. In that case if the code was being imported and someone missed a class well that's the breaks. Garbage in Garbage out.
Comment 8 Oliver Kellogg 2005-12-06 06:55:14 UTC
> I'm not sure if you are referring to my comment or not [...]

Only loosely. So, to be more specific:

> To me it would seem that if the class importer could gather more
> information much of what this bug report is about would go away. 

What kind of info do you have in mind?
Comment 9 Chris Bruner 2005-12-06 08:05:37 UTC
Currently the import function will import header files which is fine as far as it goes. The code generator will create header files and body files. Why not have the import function import the body files as well. Then if a programmer already has a body defined for a function, the uml will know about it.

Also if comments that are in the body were kept with the functions they are near (above I suppose) that would also be useful. (doxygen can do it, so I assume this should be able to as well).

These two needs seem so obvious to me, that it was why I was/am wondering if I'm missing something basic. (Like it already does it or something)
Comment 10 Oliver Kellogg 2005-12-06 20:53:56 UTC
Import of comments at classes and their members and methods
is implemented for header files (could use some improvement though.)
Import of body files is not yet implemented.
Comment 11 Einar Petersen 2007-10-05 19:10:48 UTC
IMPORT FLAW:

I find it a very serious flaw when importing classes into the umbrello modeller and only the class desciption is imported, all the aditional javadoc you have created dissapears (this goes for code generated with umbrello as well).

If automated import is to difficult at first then begin by implementing a wizard that allows you to place javadoc from imported code within the model manually.

Einar Petersen
Comment 12 Einar Petersen 2007-10-13 21:49:03 UTC
And in addition it would be nice if an imported class automatically showed up in the active model instead of having to drag it from tree view into the model.
Comment 13 Oliver Kellogg 2008-02-09 14:56:34 UTC
SVN commit 772711 by okellogg:

http://sf.net/mailarchive/forum.php?thread_name=704630.203.qm%40web58014.mail.re3.yahoo.com&forum_name=uml-devel

Walter Christie <wheeltracks1932@yahoo.com> wrote:
> I'm using Umbrello 2.0 with python. When using
> autogenerate, umbrello creates function definitions
> that are empty, removing any code that is in there
> already.


Right. Umbrello does not yet support round-tripping but here's my little stab
at it, for Python only. I'm not a Python expert and it's not yet perfect.
Perhaps you find ways of improving it.

CCBUG:53382


 M  +32 -2     pythonimport.cpp  
 M  +8 -2      pythonimport.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=772711
Comment 14 Thomas Kohler 2009-04-26 11:56:46 UTC
(In reply to comment #0)
> Version:            (using KDE Devel)
> Compiler:          gcc 2.95 
> OS:          Linux
> 
> I didn't find a way to preserve code inserted by hand into a generated file, for example marking the user-defined block with a start/end comment (many commercial programs do so).
> This should allow the whole process of writing a class, generating code, modifying it, importing and generating again... great !!!

After the long period of discussions to work around the problem I want to remember to the original request!

The goal at "the end of the day" should be: Code generation also for the function body not only for the class structure. The first step in this direction is this request from Jonathan Riddle. Also other packages like "Rhapsody" do so. The next step could be association between operations and activity diagrams. End last but not least code generation from activity diagrams.

BTW: the code generation for classes works great at the moment for C++ thanks to the developers.
Comment 15 Ralf Habacker 2016-09-06 02:13:10 UTC
For round trip engineering it is required to track the relations from which file objects are imported.

Say you have a python file1.py containing ClassA1 and ClassA2 and file2.py containing ClassB1 and ClassB2. If you you import these files in recent implementation there will be classes created in the Logical View named ClassA1, ClassA2, ClassB1 and ClassB2. Performing code generation from this model will create ClassA1.py ClassA2.py, ClassB1.py and ClassB2.py which does not match the initial files.
Comment 16 Ralf Habacker 2016-09-06 02:56:18 UTC
Managing usable code by round trip engineering requires also that umbrello needs to track and generate the whole content of files or needs to be smart enough to patch maintained files.

Say you want to manage blender python script library https://git.blender.org/gitweb/gitweb.cgi/blender-addons.git by round trip engineering. You import for example https://git.blender.org/gitweb/gitweb.cgi/blender-addons.git/blob/HEAD:/add_mesh_extra_objects/__init__.py, which contains:

- one mor more global file comments
- import statements
- variables, functions and code in the global namespace of the file

Now you change/add some methods and want to update the related file. As written before you need to know which uml objects are required to generate into which file. After umbrello generates the related file you want to run blender scripts with your changes applied. This will fail if the generated python file is incomplete.
If you are happy with the changes generated by umbrello you want  to submit your changes back to blender script repo for being included into further releases. The submission will fail if the generated patch does not follow the initial used coding style.