UML module hackery

[Matthew Palmer <mjp16 ieee uow edu au>]

I'm looking at getting some work done on the UML module for Dia (aaah,
summer interns are wonderful sometimes) and I'm just making sure I'm not
wading into territory where others are making splashes of their own which
are going to work to cross purposes.

I'm coming from a background of rather heavy RationalRose (hack, spit!)
usage, and I see a couple of areas in which Dia's UML support falls short. 
Don't get me wrong, I prefer the toolbar way of Dia preferable, I'm not
about to go rewriting the whole application.  There are, however, a few
deficiencies I've noted (at least, in the last version I used - haven't
waded into it very recently; hmm, perhaps I should again) which I want
fixed.  And I'm willing to donate programmer time to the cause.

So, in no particular order, here are my issues:

* Dia lines suck hard.  This is the thing which struck me first when trying
it out, and they still give me the s**ts.  Both the 'up and across' nature
of them, and the 'tie points' they work with.  I propose to make them more
RR-like, by:

        * In class diagrams having the terminus of the line in the centre of
        the object, and then rendering the line only in those points where
        it isn't inside an object.  Also, any arrows or other symbols would
        get rendered at the edge of the object.  Toss out tie-points
        completely.  Yuck.

        * In other types of objects, toss tie points and do vaguely similar
        things to the class diagrams above (but, not having played as much with
        those, I don't have as much of an idea about those).

* Make labels (of all sorts) more mobile, and clean up the default placement
of multiplicity tags.

Moving out of the realm of simple RR-like features, I'd like to get into a
little more "whoa horsey!" type of features, like:

* Storing actual code along with class methods.  It's always felt to me that
UML would make a really nice "graphical programming" tool, if we could store
program code along with the structural elements.  It also means that we can
skip out of letting out UML model fall to pieces as soon as we start to
code, because we'll still be working with it.

That last one might not get done, depending on what happens with the rest of
the bits.

So, hands up if you're working on these areas or planning on doing so, or
even if you know much about what my peons are up for.  This work will be
getting started in about 3 weeks time.  I don't want to stomp on anything
someone else is doing, so if you're in there digging away, please speak up
so we can work together.


-- 
-----------------------------------------------------------------------
#include <disclaimer.h>
Matthew Palmer, Geek In Residence
http://ieee.uow.edu.au/~mjp16