[Uml-devel] codegenerators

[Brian Thomas]

On Thursday 03 April 2003 02:51 pm, luis wrote:
> > - generate code in Umbrello
> > - edit the code with an editor/IDE
> > - Umbrello notices the code changes and updates the entire modell (maybe
> > add a new class or rename something)
> >
> > I'm not if we could do this, I think it might be impossible.
>
> it woud not be *too* difficult, once we have a good parser architecture and
> some code readers... till then we can forget about it.
>

	I dont think its out of the question for the current archetecture. The only
	major component I see missing to link my code document arch back to
	the UMLObjects are "AssociationRole" class (rather than have roles be
	properties of UMLAssociations).

> > Another solution:
> >
> > - generate code in Umbrello
> > - start an editor through Umbrello
>
> I think this is a very a good idea. we only need an entrie in the
> properties dialog:  "command for editor = kate %f "

	Well, IF you do this, it becomes seriously difficult to have UMLObjects
	synced up to changes in the code. For example, if you change an 
	operation in the code from "public" to "private" its clearly difficult to
	detect that in written code and make the correct change back in the
	UMLClass concerned. Even bigger problems result if you were to 
	rename an operation, propertie or class name in the code. I think editing,
	if it exists, should be done natively within umbrello. Embedding a 
	reasonable editor like kate is not out of the question.

>
> ....
>
> speaking of code generation and such...
> last night I was thinking that it'd be great to have umbrello update the
> files it generates instead of overwriting (what else is new?), but I do
> *not* want umbrello to insert "marks" in the code because of serveral
> reasons:
>
> - doesnt look good
> - it would mean the user cannot touch the marked sections, or else he'll
> loose everything.
> -others
>
> so, I tought that if CVS can merge files, so can we....
> $man merge
>
> I did a small experiment: the code generator's output stream is not
> connected to the file, but to a string, and when it finishes it calls a
> method "writeOutput" which checks if the file exists: if no, then it writes
> the whole thing to the target file, but if it exists, it writes it to a
> temp. file and then calls merge to do the work.
>
> the problem is that merge expects 3 files... where one of them should be
> the common ancestor of the other two. I did some tests with only two files
> --the one existing and the one being generated-- , using one of the files
> as both ancestor and merge,  and altough some parts were merged, some
> others just got overwritten (depending one which one you use as the
> original, the
> manually-written code, or the code being generated has preference in case
> of conflicts)
>
> I think merge can do all that we need, but for it to work ok, we'd need to
> keep a copy of the old files some where so that we can compare them
> later... I know, this is not optimal, but it'd be a way.

	Yeah, I thought of that too, but it gets complicated quickly. What, for
	example, do you do when the new code has an operation which is
	simply the renamed operation of the older code? Under your paradigm,
	BOTH operations would appear in the generated find code. Ditto
	for class fields, attributes and other properties which get renamed.

> I was thinking, everytime we generate a file, we could save a copy in the
> user's umbrello dir (compressed, of course). so the next time we generate
> the file, we merge the differences between the new model, and the user
> changes with respect to the previously generated file. -- conficts ( you
> change the parameter list manually in the file, and change it in the model
> as well) would have to be resolved manually, like in CVS--

	I agree that some type of template file is needed, but you got to have
	different template file for each language you support for each file
	that is generated.


> that would be easy, but if you move the file we'd have no file to compare
> against to... the other way I can think of, is to have a small database,
> where you map the umbrello file and generated file name to the generated
> file..
> something like
> "mydesign.xmi + theclass.cpp" -->  (file containing theclass.cpp code)
> this would be even easier, and we would not lose a file when it's moved,
> but if you store the map in a flat file, it could become slow after you'd
> generated a lot of files.
>
> comments?

	I would also favor puting the code generation templates within XMI 
	files. This would keep project files nicely together and make moving
	and trading with others a project  easier than having to give
	someone a pile of files and the correct directory structure (although
	I can see an arguement that you could argue that simply tar up the 
	templates/code works).

							=b.t.


-- 

  * Dr. Brian Thomas 

  * Code 630.1 
  * Goddard Space Flight Center NASA

  *   fax: (301) 286-1771
  * phone: (301) 286-6128

Of course it's possible to love a human being if you don't know them too well.
		-- Charles Bukowski