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

List:       kde-kuml-devel
Subject:    AW: Fixing persistence in kuml_old
From:       "Darius Stachow" <Darius.Stachow () ponton ! de>
Date:       2002-03-06 13:25:23
[Download RAW message or body]

Hi guys,

Sorry for my absence the last days! Although I don't have the time to
write a mail I'm reading all mails.

I may give some information about the IO code in kUML 0.5.1. The
experimental persistance layer was initiated by Geoff Glasson and is
based on the Memento pattern what means the state of the objects to be
saved would be stored/restored through code outside of the objects. The
IO framework should replace my old IO code that was based on object
serializing. The goals of the new persistance layer was to get the
possibility to have more just one file format and to decouple the IO
code from the data objects. Unfortunately it's mostly not finished as
you already have found out. 

I agree that the meta model used in kUML 0.5.1 isn't compatible with the
official UML specs and therefore it wouldn't be wise to implement XMI on
top of it as it would be to complicated. XMI should be an mandatory
option for the new UML repository.

If we want to resurrect the loading/saving of models in kUML 0.5.1 we
should go the easier way and implement the model IO through object
serializing.

Bye
Darius

-----Ursprüngliche Nachricht-----
Von: Mailing list agent [mailto:mdom@barney.cs.uni-potsdam.de]Im Auftrag
von Gerard Flynn
Gesendet: Mittwoch, 6. März 2002 07:00
An: kuml-devel@barney.cs.uni-potsdam.de
Betreff: Re: Fixing persistence in kuml_old


Jake Fear wrote:

>I have put some comments in below where they seem most appropriate.
>
>-----Original Message-----
>From: Mailing list agent [mailto:mdom@barney.cs.uni-potsdam.de] On
Behalf Of
>Gerard Flynn
>Sent: Sunday, March 03, 2002 2:19 PM
>To: kuml-devel@barney.cs.uni-potsdam.de
>Subject: Fixing persistence in kuml_old
>
>Hi all,
>
>  I just checked in a change to kuml_old which fixes the parser problem

>when using the non-XML persistence layer to the extent that it will not

>hang the program.  It still doesn't actually restore diagrams, but I 
>commented out the warning boxes anyway.
>
>  I've begun trying to understand the state of the non-XML persistence 
>code.  Presumably this code actually worked at some time in kUML's 
>distant past, which would explain why there are kUML files in the doc 
>directory, but it was in a broken state by the time kUML was moved to 
>Sourceforge.  The question is how broken, and what will it take to fix 
>it ?  Any ideas from kUML old-timers on this would be greatly
appreciated.
>
>
><jake> To the best of my knowledge it never more than "mostly" worked,
but
>did work for a subset of class diagrams.  I wish I knew/remembered more
>about the file formats and error cases and such, but I do not.
>
  Well that's better than not working at all for class diagrams.

>
>  From my own preliminary investigations, it appears that the key to 
>this layer is the IOInterface which is inherited from by many kUML 
>classes.  It provides the readAsKuml and writeAsKuml methods.  One nice

>feature is that the classes which implement this interface are somewhat

>isolated from the actual file format by the IOKumlUtility class which 
>does the actual low level parsing and writing.
>
><jake>Could XML persistence be hidden behind these interfaces?  This
may
>allow for existing XML persistence tools to be leveraged to some
degree.
>The utility of this would of course depend and the relative
completeness of
>the oldest file format.
>
  I guess you could have one of two things in mind by "XML persistence".

  If you mean keeping a simple file format with the same content as the 
current one but converting it to XML then I think this would be quite 
easy to do by modifying the IO utility class.  I'm not sure what the 
advantage would be however.  It would allow us to avoid having to deal 
with low level parsing but if that's already handled well by the current

IO class then I'm not sure there would be much point.  If on the other 
hand we find out that there are a lot of problems with that class, then 
sure converting to XML would probably be a good idea.

  If instead you mean an XML format similar to XMI then I'm not sure 
that the kUML class structure is sufficiently similar to the UML 
meta-model for this to make sense.  I think this was what the 
experimental XML layer was about and that appears to use different 
interfaces.  Anyway I tend to think that XMI is best left to the new 
repository and that if we try to fix persistence in kUML that we should 
stick to something simple and easy to implement.

  Gerard


>


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