Hi Tom,
My last commit must have disturbed your work somewhat, sorry for that ;-).
Feel free to adapt the architecture of my changes! I am not convinced myself
about some of the choices I made.
IMHO you are doing a great job - and I hope that it clarifies the subsystem
structure for me.
This is my dream:
Will this result in a complete package diagram showing the dependencies? At
least better then the ones currently in the cookbook...
:-)
Regards,
Michiel
----- Original Message -----
From: "Tom Morris" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, June 02, 2006 8:29 PM
Subject: RE: [argouml-dev] The structure and purpose of the GUI subsystem.
Linus said:
[the GUI class] is an attempt to break up the
ProjectBrowser class by moving some responsibilities out of it.
It sounds like we agree that the ProjectBrowser has turned into a tar baby.
It seems to have become the dumping ground for every piece of global state
that lacks a home of its own.
The comment that you identified was part of a larger attempt to break the
strong coupling between the ProjectBrowser and other classes. The comment
was actually obsolete even before it was committed because I'd already
decided that it would be better for the LRU menu to listen directly for
notification of file save events (and have the file saver post those
notifications).
I spent several hours teasing apart the ball of string that is
ProjectBrowser since Classcyle had identified it as the "best fragmenter"
for the large cycle of 758 classes. Because ProjectBrowser acts in so many
different roles, my first task was to separate out the methods and data for
the various roles into separate classes so that I had a cluster of
interrelated classes that I could use to trace what depended on what.
Because ProjectBrowser is basically the 2nd highest layer (after
org.argouml.application.Main) any reference to it from a lower level
component is likely to introduce large dependency cycles.
After splitting things up and breaking a few of the dependencies I was able
to reduce the size of the largest cycle from 758 classes to 229 classes with
ProjectBrowser off in its own little cycle of 21 classes.
Some of the issues that I identified with ProjectBrowser as part of this
investigation include:
- lots of ProjectBrowser.getInstance() calls used solely as parent for
popup dialog box. We can probably use null or figure out the main
application window using Swing calls for most (all?) of these.
- there are several references getStatusBar().showStatus which should
probably just post status events that the statusBar can listen for
- There are a number of Actions managed as singletons (undo/redo, save
project, remove from diagram). I didn't look into which ones really need to
be singletons, but I split them all off into a separate class just to
separate them from ProjectBrowser for investigative purposes.
- There's a ton of code specifically for Loading/Saving projects which I
split out.
- jumpToDiagramShowing() is only used one place (UMLToDoItem) so I moved it
there temporarily, but we should probably use the TargetManager or a similar
mechanism
- setToDoItem() - similar to above. The details pane should probably
listen for target changes.
- getTab() - only used in ToDo management - use event instead
Most of the (private) changes so far have been just to enable the
investigation rather than production ready code, but the one small change
that I thought was non-controversial (to break the large cyclic dependency
in the GUI class introduced by
http://argouml.tigris.org/servlets/ReadMsg?list=cvs&msgNo=11447) was
immediately rejected by Linus, so I figured I should stop, summarize the
results of the investigation so far and figure out what to do next.
I'd really like to see something done about this big ball of spaqhetti and
was willing to do the work, but now I'm unsure what the next step should be.
Should I let someone else do this work? Should I just drop it?
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.8.1/355 - Release Date: 2/06/2006
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.8.1/355 - Release Date: 2/06/2006
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
