[Uml-devel] Umbrello design (was UML XML tree viewer)

[Luis De la Parra Blum]

Hi Andrew, hi list,

On Monday 04 November 2002 16:15, Andrew Sutton wrote:
...
> the first thing to get attention should be the creation of a truly
> compliant xmi implementation (say, libXMI). this should be able to handle
> model documentation and the dynamic loading of meta-model libraries to

I like your suggestions, and I also think this would be the way to to things 
if we really want to do it "the right way"
The problem is that Iam not sure we can go this way... I mean, altough I see 
this as the correct approach, I also see the risk of being *too* academic and 
then not being able to get something that really works in real life.

dont get me wrong, I am not saying we should discard this idea, but just that 
we should discuss it throughly before deciding on it.
I am only learning UML now, and to be honest, the whole MOF-thing seems really 
interesting to me, but also a bit too abstract... and somehow i have the 
feeling that but for you and maybe other one or two guys in the group, the 
other developers are not MOF and XMI experts either =((

ok... so to try to start making things a little bit clearer:
We want to separate the Modell from its graphical representation -- so far 
everyone agrees --
(now I am goint to explain what I have understood from the discussion so far. 
If I got something wrong or put words in your mouth that you didnt mean, 
please correct me.  some comments of my own are also included =)

I understand you propse to create a component (library) which:
1) reads XMI files
2) creates a model out of this files (not a DOM tree, but really a modell, 
containging a "Modell" object, which in turn contains "Class" and 
"Association" objects, etc. This objects have methods "setAttribute(xyz)" and 
so on
3) this component can then generate programming source code for the objects in 
its modell

Using this library, you suggest to feed it the XMI file of UML itself, have it 
generate the classes skeleton for us, and then we use this code for..... for 
what??
-> if libXMI alread gives us a Modell, then we already have what we need, dont 
we? I am getting a bit confused now. why do we need another UML modell on top 
of the modell itslef?

Another thing is: the code generator will probably only write the skeleton for 
the classes (class and method declarations) and we would still need to 
implement the methods manually.. right?  (ok, ok.. so for what I've seen most 
of them are just get/setter)

->How would we integrate this into "the application" ?  (just link it in and 
use it as a "normal" library?)

->If libXMI is to be able to write code... how are we going to handle various 
languages?  
a)- should the library use come "code generation" libraries which get the 
modell and write the code (approach similar to current implementation) or 
b)- should it read the XMI file and generate code from there?

approach b) sounds more like "the unix way of doing things", but this would 
mean having one "filter" for each supported languages. (altough on second 
thought, nothing prevents us from implementing more than one language into a 
"filter program")
Approach a) seems more... "modern"??? to me, as this is a typical Plug-in , 
and has the advantage of better communication / interaction with the 
controlling program... for example if a file already exists modify it?, 
replace it? skip it??  - so you can implement this in approach a) as well and 
comunicate with the filter via a pipe or a socket, but the interaction would 
be more complicated... and the filter itself could not interact directly with 
the application / user -> example: with the Plug-in approach each language 
can have its own "configuration" dialog to set up language-specific options.
Since each plug in would be responsible for its dialog and its options, the 
only thing we need to know is that there is a method "configureOptions()" 
which will show the dialog and take the appropiate changes... in the filter 
approach we would probably need to know which options are available to each 
language and manage the dialogs in the application itself.

If we want to just generate the UML implementation classes ( class Class, 
class Attribute, etc) then I think the better way would be to find out how 
XSLT work and then write one of those things to generate C++ code from the 
UML-XMI specification... but this of course would not give us a real Modell, 
just the classes to make the modell with.

the other approach would be to get something intermediate between what we 
currently have, and the "real thing" ... that means, implement the UML 
classes where we feel it really makes sense, and simplify things when/if we 
feel some parts of the UML specification are too-detailed/abstract/academic.

We could *probably* reach 100% UML conformity to the extern world, but not 
being UML conformat from inside *could* mean there will be things which are 
too difficult to implement (and we would have the same problem we have today)
So, it would mean a big risk of having to redo everything again, but it would 
have the advantage that since it is more "concrete" it would be easier to 
understand and implement even without knowing every detail of the MOF or UML.

comments??  I would like to go the first way ( libXMI ). I am just not sure 
how to go about it.. or that we have the resources needed to do such a thing.

regards

luis