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

List:       kde-kuml-devel
Subject:    Re: Another status report
From:       Geoff Glasson <glastech () iinet ! net ! au>
Date:       2002-06-27 13:08:23
[Download RAW message or body]

Guys,

Like Jake I worked on kUML a couple of years ago but my day job got in the 
way and I had to pull out ( unfortunately that's still the case so at this 
stage I won't be getting involved again ).

Anyway, I worked on the experimental persistence layer.  What I was trying to 
achieve was to define an interface that would allow kUML to read and write a 
number of different formats.  At the time I was doing lots of work with Rose 
and I figured that if kUML had the ability to store models in XMI format, as 
well as Rose's format then it would be easier to get it accepted by 
mainstream development houses.  It would also give kUML the ability to easily 
convert from one format to another - ie: load a kUML diagram and save it in 
Rose format, and vice versa.  Similarly, this interface was intended to allow 
other model repositories to be bolted on at a later date without major 
changes to the way in which the design elements were stored internally.  I 
seem to recall that just prior to my exit from the project I did have save 
and restore going ( in a very rudimentary  form ) but can't remember whether 
I committed the changes.

Just prior to my leaving the project a number of new folks joined and wanted 
to rewrite everything from scratch rather than getting what we had working 
and then using it to redesign the project if necessary ( no criticism 
intended - I'm not a big fan of chucking code away without at least trying to 
rescue it ).  I believed at the time that we had a solid if somewhat clunky 
piece of software that we could use as a basis for moving forward.  My 
intention for the persistence layer was to do just that, because the 
experimental persistence layer in the old kUML source tree is very raw, quite 
ugly, if I do say so myself not very well designed ( the implementation of 
the XMI support not the interace itself ).

So now you know what I was trying to achieve, and I still believe that it is 
the right way to go.  As I'm sure you're all aware, the external 
representation need not resemble the internal representation provided that 
there are sufficient tools to easily perform the conversion.  Therefore, I 
think that it would be best to define an interface, implement a simple save / 
restore mechanism, get the graphical editor working, and only then look at 
providing a more sophisticated save / restore mechanism once there is 
something that works.  Naturally you will need to provide some form of 
conversion mechanism so that users can migrate from the simple to the complex 
data storing mechanism.

Just my 2 cents.

Regards and best wishes...Geoff

On Mon, 25 Feb 2002 01:21, you wrote:
> You have definitely made it more difficult than it needs to be.  I
> worked on this project a year or two ago, and would be willing to
> participate again if this simpler approach was taken.  Perhaps kUML
> would benefit from having options for how persistence is done anyway.
> Many discoveries for how to make things simpler/better in the more
> complex approach will be discovered while implementing a simpler
> approach (like models in XML files, with an interface "similar" to what
> the repository would eventually have).
>
> I have been away from the project for a long time, so please forgive me
> if I'm being ignorant ;-)
>
> Cheers,
> Jake
>
> On Sun, 2002-02-24 at 07:47, Gerard Flynn wrote:
> > Chris Moore wrote:
> > >Gerard Flynn wrote:
> > >>Chris Moore wrote:
> > >>
> > >>    Is it really be this difficult to write a good UML tool or have we
> > >>made it more difficult than it needs to be ?
> > >
> > >Too many people are scratching their itches.  That's OK by me.  If it's
> > >not interesting why do it?  But it does mean we lose momentum towards
> > >our ultimate goal.  With my old project, one group got really excited
> > >about implementing an object database.
> > >
> > >Time to set some short term goals?  Is anything achievable short-term?
> > >I can certainly have a repository done soon.  And XML export shouldn't
> > >be too hard I think.  Anybody apart from Gerard doing anything?  Hmmm?
> >
> >     Well that last part doesn't seem to have attracted many responses.
> >
> >     I had a look at the current version of kUML the other day and it
> > seems to me that it would already compare favorably with other
> > alternatives if it only it was possible to save and restore diagrams.
> >
> >   One thing that I don't think anyone has given much thought to is just
> > how the front-end is supposed to actually use the Repository.  I would
> > think that it would be much easier to start experimenting on this from a
> > front-end implementation that basically works than from scratch.
> >
> >   Still I think that if there are only the two of us, even this isn't
> > exactly a "short term" goal.
> >
> >   I'm wondering if we shouldn't just try to get a simple but workable
> > save/restore mechanism implemented in kUML 0.5 without using the
> > repository.
> >
> >   This could have several advantages :
> >
> >         1) The Linux community gets a reasonably usable UML tool.
> >         2) kUML gets a much expanded user pool, a few of whom just might
> > be interested in helping us                   achieve our longer term
> > goals. 3) We would be more in line with the proven evolutionary approach
> > to open source development                  rather than the more
> > questionable "architectural" approach.
> >         4) Seeing concrete benefits of our work could be a significant
> > psychological boost for us.
> >
> >     I'm not suggesting that we abandon all the work we have done in the
> > last year on the repository, just that we might want to rethink our
> > priorities between short-term usable solutions and long-term ideal ones.
> >
> >   What are your thoughts on this ?
> >
> >   Gerard

-- 
Geoff Glasson
glastech@iinet.net.au


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