Re: UML module hackery

[Lars Clausen <lrclause cs uiuc edu>]

On Mon, 11 Nov 2002, Matthew Palmer wrote:
> 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.

Sounds great!  It's good to have more hands working on it.Make sure that
you work off of the CVS tree, as many things have changes.

> 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).

Tie points (connection points), as the other poster mentioned, can be good
and bad.  Their big limitation is in the limited amount of them, their big
strengths are that they keep a neater diagram and are easier to handle
internally. 

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

If you're using 0.90, you'll find that the CVS version has better
multiplicity tag placement.  A number of objects already have mobile
labels, and that should really be the case for all labels.  It's not hard,
but a lot of busywork.  Hey, you said you had interns... :)

> 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.

We were discussing earlier a way to let users arbitrarily add fields to
objects.  Now the UML class object in particular is nasty, evil and hairy,
and (I think) the only object that doesn't use the nice properties system
for everything.  It also needs linebreaks for long signatures and a number
of other fixes that we've put off becuase it's so evil.  If you have an
intern whose sanity isn't a concern of yours, having it redone would be
great! :)

Again, it's important that you work against CVS head.  There will be a new
release as soon as we have the GTK 2.0 stuff in a state we like (for me,
that's mostly the font stuff, I don't know how strongly Cyrille feels about
getting the input methods ready for that release).

-Lars

-- 
Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| Hårdgrim of Numenor
"I do not agree with a word that you say, but I   |----------------------------
will defend to the death your right to say it."   | Where are we going, and
    --Evelyn Beatrice Hall paraphrasing Voltaire  | what's with the handbasket?