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

List:       kde-kuml-devel
Subject:    Re: [argouml-dev] [KUML] KUML IO.
From:       Toby Baier <Toby.Baier () gmx ! net>
Date:       2000-06-26 22:09:27
[Download RAW message or body]

Hi Jonathan, everyone!
Nice to get in contact with you KUML ones again! Just some comments on
the mail: ArgoUML (or rather the used GEF-Framework) will switch from
PGML to SVG as graphical storage files soon, a paid project for this is
underway. As for the mess of files (one for the model, one for each
diagram), we thought about just zipping them into one .zargo file, which
is jsut as easy to explore when you want to look at the files if you
want to, but no action in this direction has been done so far. The
reason is not having nsuml as metamodel-library, it was done this way
before as well.
Yes, if there is graphical information in XMI files, it is lost while
loading into Argo. Maybe we can change that later, but we will stick to
multiple (maybe zipped) files for our projects (you can just use your
saved projects as images for web sites or pdfs, cause there are SVG
viewers/converters for that!).

Besides, I'm very happy to see that KUML is going to use XMI as well
now, so we can have model interchange! Yeah! Hope you're using XMI1.0
for UML1.3 as well? :-P

"Riehl, Jonathan (Jonathan)" schrieb:
> 
> 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


-- 
         Tobias Baier - Brahmsallee 31 - 20144 Hamburg - Germany
          Tel: +49 40 4291 0502      -    Fax: +49 40 4291 0502
          mailto:Toby.Baier@gmx.net -          ICQ#: 12164930
    http://www.stud.uni-hamburg.de/users/toby (last updated 26.7.98)

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