[Uml-devel] Re: Umbrello design (was UML XML tree viewer)
Jean Vittor
jean.vittor at wanadoo.fr
Mon Nov 4 16:56:02 UTC 2002
Hi Luis,
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.
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.
Concerning your questions about code generation, I would prefer your
second solution (read an XMI-File and generate code from there).
If I try to give a (extremely simplified) architecture of the tool, I
would see:
* a package that contains only the MOF (or a subset),
* 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),
* a GUI package and
* a code generation package.
Note that the 2 last packages should be also based on the first one.
I hope it helps and I'd like to have your opinion.
Regards,
Jean
-------- Original Message --------
Subject: [Uml-devel] Umbrello design (was UML XML tree viewer)
Date: Tue, 5 Nov 2002 00:07:19 +0100
From: Luis De la Parra Blum <lparrab at gmx.net>
Reply-To: luis at delaparra.org
To: ansutton at kent.edu, Heiko Nardmann <h.nardmann at secunet.de>,
umbrello-devel at kde.org
References: <200211041006.56017.h.nardmann at secunet.de>
<200211041015.26027.ansutton at kent.edu>
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. http://www.apachecon.com
_______________________________________________
Uml-devel mailing list
umbrello-devel at kde.org
https://mail.kde.org/mailman/listinfo/umbrello-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/umbrello-devel/attachments/20021104/661c6660/attachment.html>
More information about the umbrello-devel
mailing list