[Uml-devel] codegenerators

[Luis De la Parra Blum]

On Thursday 03 April 2003 23:00, Brian Thomas wrote:
> > 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).

what document arch are you talking about?
I wasnt talking here about code generation (I guess the subject misslead you), 
but about code import -- we now have a C++ parser which is more or les good, 
but relatively inflexible...  we need a good code import architecture, 
flexible, where we can have many languages suported. they should spit out the 
XMI representation of the classes, which we can then load.
once that is working you can easyly merge two classes together.

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

I wasnt thinking this should happen on-line (automatic)... I would rather say, 
you tell umbrello to import some code-files.. it finds a class "MyClass", and 
if there happens to be a class with the same name in the current modell, it 
merges the two.

> 	operation in the code from "public" to "private" its clearly difficult to

if your MyClass has op1 as public, and you import myclass.h, which contains 
MyClass, and it's defined as private, then, in the merged class, it should be 
private (because you are importing the class, it has preference) or you ask 
the user:
 --> both classes differ on following operation, do you want to keep the 
current one, or take the one being imported?

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

embedding the editor is not the problem... but if I understand you right, 
you'd need to parse the file as you write in the editor ( in real time !)..
writing a c++ parser is not a trivial task.... for code import it would not be 
too dificult, because you parse only the class, ops and atts declarations ( 
small subset of the language) - you could take everything betwwen { } after 
the operation and put it as "CDATA" as the operation method (implementation)
but if you want to parse everything, well... it's a bit more complicated

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

yes, you are right.
I did not say the solution I proposed was perfect, but I can tell you it would 
give us good results, and it's extrem easy to implement.
... besides... if you want to rename an operation, you should do it in 
umbrello and re-generate. merge would then take the operation name out of the 
file and put the new name in, leaving the body intact.

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

hmm... I'm afraid I am not understanding you here (or you did not understand 
me before)
what kind of template are you talking about?
the files I said we should save, are the last generation of the code, so that 
we can feed it to merge.
imagine each time you generate you get a version number, like in CVS.
so you export a file for the first time, and its v1, then you edit it in kate, 
(v1-modified) then you change your class in umbrello, and export it again 
(v2).. merge would see the differences between v2 and v1 AND between 
v1-modified and v2, and put them togheter.
this has nothing to do with the language (java vs. c++).. merge does not 
really know what it's merging, it just compares wich lines are equal and 
tries to find patterns.. it can be c++, a web page, or a kword document.

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

I dont know if I got you right here, but I like the idea.
when you export a file, you write the file (v1) in the umbrello file
<umbrello xmi>
<model>
<class 1>
..
</model>
<diagram>
..
</diagram>
<code generated>
<class1>
<c++>
(cdata) Class1{
ops
}
(end of cdata)
<c++>
</class1>
</code generated>

this way the maping is solved... the *only* disadvantage I see is that the 
umbrello file will grow quite a bit, but we can always save the files 
compressed.


luis