<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body>
Hi Luis,<br>
<br>
Concerning your questions about XMI, I think that integrating the real MOF
into Umbrello would show a high compliancy to UML standards (and I would
really like that). I'm not sure about feasibility of this objective but,
if it is, I think that the MOF should be clearly separate. I don't think
the development should consist in implementing the methods of meta-classes
of the MOF. My last reading of UML was more than one year ago but I remember
there are some methods that are specified in OCL. Most of these methods are
only for navigation and consistency checking (am I right ?). My opinion is
that real implementation (I mean implementation that is not specified in
UML documents) should be in an other model that maps with the MOF. If the
MOF is rich enough (I didn't check that), it should be sufficient to describe
all required information for model display, code generation, consistency
checking... Note that I didn't check that at all but I remember I have seen
elements dealing with model display and elements dealing with code generation.<br>
<br>
But I share your worry about feasability (integrate full MOF into Umbrello).
Nevertheless, I think that all information that is (clearly ?) specified
in UML should be separate (even if the full MOF is not implemented). If you
plan to redesign Umbrello, I would suggest a progressive isolation of UML
elements (MOF meta-classes) from other classes.<br>
<br>
Concerning your questions about code generation, I would prefer your second
solution (read an XMI-File and generate code from there).<br>
If I try to give a (extremely simplified) architecture of the tool, I would
see:<br>
<ul>
<li>a package that contains only the MOF (or a subset),</li>
<li>a package that parses XMI-files and instanciates MOF meta-classes or
that generates an XMI-file from a model (that is probably what you called
libXMI),</li>
<li>a GUI package and</li>
<li>a code generation package.</li>
</ul>
Note that the 2 last packages should be also based on the first one.<br>
<br>
I hope it helps and I'd like to have your opinion.<br>
<br>
<br>
Regards,<br>
<br>
Jean<br>
<br>
<br>
-------- Original Message --------
<table cellpadding="0" cellspacing="0" border="0">
<tbody>
<tr>
<th valign="baseline" align="right" nowrap="nowrap">Subject: </th>
<td>[Uml-devel] Umbrello design (was UML XML tree viewer)</td>
</tr>
<tr>
<th valign="baseline" align="right" nowrap="nowrap">Date: </th>
<td>Tue, 5 Nov 2002 00:07:19 +0100</td>
</tr>
<tr>
<th valign="baseline" align="right" nowrap="nowrap">From: </th>
<td>Luis De la Parra Blum <a class="moz-txt-link-rfc2396E" href="mailto:lparrab@gmx.net"><lparrab@gmx.net></a></td>
</tr>
<tr>
<th valign="baseline" align="right" nowrap="nowrap">Reply-To: </th>
<td><a class="moz-txt-link-abbreviated" href="mailto:luis@delaparra.org">luis@delaparra.org</a></td>
</tr>
<tr>
<th valign="baseline" align="right" nowrap="nowrap">To: </th>
<td><a class="moz-txt-link-abbreviated" href="mailto:ansutton@kent.edu">ansutton@kent.edu</a>, Heiko Nardmann <a class="moz-txt-link-rfc2396E" href="mailto:h.nardmann@secunet.de"><h.nardmann@secunet.de></a>,
<a class="moz-txt-link-abbreviated" href="mailto:umbrello-devel@kde.org">umbrello-devel@kde.org</a></td>
</tr>
<tr>
<th valign="baseline" align="right" nowrap="nowrap">References: </th>
<td><a class="moz-txt-link-rfc2396E" href="mailto:200211041006.56017.h.nardmann@secunet.de"><200211041006.56017.h.nardmann@secunet.de></a> <a class="moz-txt-link-rfc2396E" href="mailto:200211041015.26027.ansutton@kent.edu"><200211041015.26027.ansutton@kent.edu></a></td>
</tr>
</tbody>
</table>
<br>
<br>
<pre>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
-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. <a class="moz-txt-link-freetext" href="http://www.apachecon.com">http://www.apachecon.com</a>
_______________________________________________
Uml-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:umbrello-devel@kde.org">umbrello-devel@kde.org</a>
<a class="moz-txt-link-freetext" href="https://mail.kde.org/mailman/listinfo/umbrello-devel">https://mail.kde.org/mailman/listinfo/umbrello-devel</a>
</pre>
</body>
</html>