[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kuml-devel
Subject:    [KUML] KUML IO.
From:       "Riehl, Jonathan (Jonathan)" <Jonathan.Riehl () exchange ! ons ! octel ! com>
Date:       2000-06-26 16:33:39
[Download RAW message or body]

Hi Geoff, Darius, et al.!
	I am of the opinion that involving other developers in the IO design
is of the utmost importance.  Why, you might ask?  I would like to build
integrations between KUML, my own projects
(http://sourceforge.net/projects/basil, http://wildideas.org/basil/,) and
others (such as Argo.)  My view was addressed somewhat by some requirements
I posted some time ago (see the KUML archives re: Some notes about
modeling.)  I have somewhat of a selfish view (Basil = world domination,)
but one integration shows the way to others who would have use of KUML
outside of its object modeling roots.
	Actually, all I have to pick at is nits so far.  On a philosophical
level, XMI has a built in extension mechanism and I don't see why this
shouldn't be explored first and foremost.  The clearest example I can point
to is the Unisys XMI plug-in for Rose (if you don't have a few thousand US
dollars available for Rose, don't sweat it, I can provide reference
documents.)  They simply define some extensions to the document type and
embed their diagram information under the appropriate extension tag area.
Embedding PGML would not be a problem at all (esp. considering it is not a
proprietary DTD/DTD extension,) and writing a quick tool to extract PGML
files from an XMI document would be nigh trivial.  For diagrams, instead of
exporting to GIFs only, a PGML export could be added as well.
	The Argo approach provides cleaner XMI, without the baggage of
diagrams and other project minutia.  However, it bothers me that their
outputs are spread over several files (I suspect this is due to their use of
an external meta-model library and its provision of XMI built in.)  This
also raises the issue of a XMI import ability.  In my current understanding
of Argo, it would be lost if I tried to take another party's XMI file (such
as the over labeled crud that Unisys' system spits out) and import it.  They
have no mechanism to infer any of the project details behind an XMI input
(which is not to say that one can't be built in short order.)  An object
modeling tool should be robust enough to not need any of that junk anyway.
(I have also CC'd the ArgoUML developer's list so I may shortly be
enlightened where wrong :)
	As a final note, I would also like to see a project DTD banged out
(showing source files and their relationship to the object model,) and then
have it embedded in XMI as well.  I think that both ArgoUML and KUML have
talked about this to some degree, but no actions were taken.  Perhaps it is
time for the open source modeling community to see what kind of document
standards weight it can throw around.

-Jon

PS. Don't let me stop you from building something and then releasing it to
the KUML public, but don't be surprised if I gripe about integrating the
results into my meta-modeling environment ;)  I'm sure we're all aware that
standards rarely drive code but rather it usually works the other way.

-----Original Message-----
From: glastech@iinet.net.au [mailto:glastech@iinet.net.au]
Sent: Monday, June 26, 2000 7:50 AM
Subject: 


	([127.0.0.1] helo=delenn.glastech.com.au ident=gjg)
	by delenn.glastech.com.au with smtp (Exim 3.14 #2)
	id 136jPk-0000KP-00
	for kuml-devel@barney.cs.uni-potsdam.de; Mon, 26 Jun 2000 20:39:44
-0400
From: Geoff Glasson <gjg@delenn.glastech.com.au>
Reply-To: Geoff Glasson<glastech@iinet.net.au>
To: kuml-devel@barney.cs.uni-potsdam.de
Subject: Fwd: Re: IO subsystem
Date: Mon, 26 Jun 2000 20:39:44 -0400
X-Mailer: KMail [version 1.1.50]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <00062620394400.01236@delenn.glastech.com.au>
Content-Transfer-Encoding: 8bit
return-path: glastech@iinet.net.au

Hi guys,

I've been keeping Darius up to date with what I've been doing and he 
suggested that I post to this group.  So this is the e-mail that I sent him.

I have been using KDE 2.0 (Kleopatra) on Linux and have just installed 
FreeBSD and KDE 1.1.2 running under VMWare.  I am attempting to ensure that 
everything I do builds on both (unlike in the past).

Geoff

----------  Forwarded Message  ----------
Subject: Re: IO subsystem
Date: Tue, 13 Jun 2000 19:54:00 -0400
From: Geoff Glasson <gjg>
To: Darius Stachow <dstachow@ngi.de>


Hi Darius,

At this stage I don't believe that there is a need to involve other
developers in the IO subsystem.  The whole design is still fluid as I will
explain below, and I think that multiple developers would simply confuse the
issue.  It is my intention to get the IO subsystem developed, and then use
it
to build a KUML model that describes the IO subsystem.  At that point I
think
that it would be beneficial to get feedback from other developers, because
they will have something that they can use and critique.

I have been forced to change the way in which KUML models are stored as XML
files.  As you may be aware, the XMI interchange format is used for
exchanging UML models between software tools.  However I have discovered
that
XMI does not support the transfer of graphical information.

I have given this some thought and have decided to take a leaf out of ARGO's
book and create multiple data files.  Now there will be a data file in XMI
format that contains all the information that describes classes,
associations, etc, plus a PGML file for every diagram in the model.  PGML
format allows us to store graphical information that will allow us to
reconstruct a KUML model from a file.

One drawback to this method is that there will be a large number of data
files, any one of which could be missed when copying the model from one
machine to another.  This of course will be a major problem, so after much
thought I decided that a KUML model will be stored in a compressed TAR file.
The TAR file will contain the XMI data file, a PGML file for every diagram,
plus a manifest that describes what files make up the model.  At this stage
I
cannot see a better way, but once the initial IO subsystem is released I
will
be open to any suggestions.  I am concerned about the performance of this
mechanism, but will have to get it working and then do some benchmarking.

On the KDE 2 front, I have been continuing to port KUML to KDE 2 and have a
working copy.  There is still a lot of things to be completed, because at
this stage I have done enough to allow me to create class diagrams.  As you
have probably already seen, I have defined a constant KDE2 which determines
that we are building under KDE 2.  I have wrapped all my KDE2 changes within
#ifdef so that (hopefully) developers on KDE 1.X are not inconvenienced too
much.  As far as I am aware I am the only person working on KDE 2, so if one
of the other developers has trouble building on KDE 1, point him in my
direction.

Regards...Geoff

--
Geoff Glasson
glastech@iinet.net.au

-------------------------------------------------------

-- 
Geoff Glasson
glastech@iinet.net.au

[prev in list] [next in list] [prev in thread] [next in thread]