Hello all!
When doing a little testing I found a rather serious problem that could
perhaps be connected to this. It looks like a lot of exceptions are thrown
when removing elements from a state or activity diagram. I will file a
separate issue with this problem.
/Linus
2009/1/3 Tom Morris <[email protected]>
> On Sat, Dec 20, 2008 at 12:23 PM, Bob Tarling <[email protected]>
> wrote:
> >> No one seems to have taken me up my offer of doing some of the other
> >> diagrams, so I guess it depends on how quickly I can plow through it.
> >
> > I think I must have missed this request. What is the best example to
> > use for reference?
> >
> > Certainly I'd like to change the sequence diagrams to use this.
> >
> > Maybe we can have a volunteer for each diagram type.
>
> Michiel helped out with the State & Activity diagrams (thanks Michiel)
> and I think I've finished up most everything else except for
> Sequence/Sequence2. The main thing needed right now besides the
> sequence diagrams is a bunch of eyeballs for testing. If people could
> run through each diagram and make sure it's behaving properly, that
> would be a big help. A good way to make sure that no Figs were missed
> is to choose a new larger default font and make sure that reloaded
> projects retain their original sizes rather than picking up the new
> larger font. Of course, keep an eye out for any other anomolies
> introduced.
>
> When doing the Sequence diagrams, the Use Case diagram is probably the
> best one to look at for a model since it's the simplest and it's the
> one that I did first.
>
> Basically you need to add a new constructor of the form Fig(Object
> owner, Rectangle bounds, Diagram Settings settings), deprecate all the
> old constructors, and change all the references to the old
> constructors (usually just two UML*Diagram and *DiagramRenderer).
> Usually there's one constructor that has all the work in it, so what I
> do is use Eclipse's Extract Method refactoring to pull out the code
> into a private method called initFig or something which can then be
> reused in the new constructor. This keeps the bulk of the code
> unchanged so so that it's easy to diff for any unintentional changes.
>
> Tom
>
> ------------------------------------------------------
>
> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=1000741
>
> To unsubscribe from this discussion, e-mail: [
> [email protected]].
>
------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=1003042
To unsubscribe from this discussion, e-mail:
[[email protected]].
