Dependency Structure Matrix - First thoughts
In no particular order
Modal Dialog - It's unfortunate that (like CodeDependency), you haven't come up with a better way of showing dependency information than in a modal dialog. I confidently predict that this will be the biggest complaint you get about the dependency structure matrix.
Compilation - I'm guessing from the fact that you need to build a project before showing the DSM that you are getting dependencies off of the compiled classes. This is odd, because it means you can't include non-Java dependencies, including JSPs. I know you've got heavily optimized dependency analysis from the PSI tree (or you wouldn't be able to do dead code analysis, if nothing else). What's the deal?
Module groups - Show module groups on the DSM. Obvious.
Hide row - Need to be able to hide a row. Obvious.
Navigate from DSM - including auto-scroll. Obvious.
Libraries - One good and simple use-case of a DSM or dependency graph is to be able to tell just what libraries are used from where. There needs to be an optional ability in the DSM to show dependencies on libraries (sadly, Java is without the ability to declare inter-library dependencies, although that is changing).
Trigger refactoring from DSM - Move, Rename, and Safe Delete are the most valuable, but anything that works for a class or package is probably worth including. In my perfect world, I'd be able to unsnarl a dependency tangle via drag-and-drop on the DSM.
Dependency graphs - The DSM is a powerful visualization, but I believe that dependency graphs are just as powerful and complementary to DSM. Play around with CodeDependency to get some ideas.
Dependency rules - IDEA already includes a concept of dependency rules. At a minimum, he DSM needs to be able to highlight dependencies which violate rules. Slightly more advanced (and cooler) would be to have the ability to see and edit rules from the DSM. If there is a rule prohibiting a cell, it's upper right corner could have an indicator. Adding or removing rules could be done via the right click menu from any cell.
Printing - IDEA has historically not been much for printing information, probably because printing is something that usually happens only when you're developing without pleasure. DSMs (and dependency graphs) just cry out for making into manager-pleasing wallpaper.
Better cycle sorting - There seems to be something odd or incomplete about your sorting algorithm, when it comes to cycles. If I've got a set of mutual dependencies in a hub-and-spoke pattern, the hub should always come last. Right now, it could be first, last, or anywhere in the middle. You need a secondary sort after the topological sort.
Oh, yeah, I should also mention that it totally rocks that you guys are taking dependency visualization seriously. The previous table-based solutions were very difficult to use, and the DSM is a great alternative.
--Dave Griffith
Please sign in to leave a comment.
It was discussed here many times that modal dialogs are evil and counter productive. I don't understand why people working on new features are still not told to avoid them. Didn't Jetbrains learn anything from the model mess we are in now?
S.
Stefan, it was told a couple of times: non-modal dialogs often is much
harder to implement right than modal dialogs.
On 2007-05-27 22:45:33 +0400, Stefan Arentz <no_reply@jetbrains.com> said:
>> In no particular order
>>
>> Modal Dialog - It's unfortunate that (like
>> CodeDependency), you haven't come up with a better
>> way of showing dependency information than in a modal
>> dialog. I confidently predict that this will be the
>> biggest complaint you get about the dependency
>> structure matrix.
Do I miss something obvious? DSM results are in toolwindow (with all
available docking/floating options). What modal dialog you're talking
about?
Max
Hurm. You are right. I'm an idiot. I would strongly suggest, though, that toolwindows never be set to float by default, to prevent precisely this sort of confusion.
--Dave Griffith
On 2007-05-28 00:07:09 +0400, Dave Griffith <dave.griffith@cnn.com> said:
On the other hand "docked" default for these kind of thing is obviously
wrong unless you have 30 inch Apple display.
>> I would strongly suggest, though, that toolwindows never be set to float
>> by default, to prevent precisely this sort of confusion.
>
>
Couldn't it be another editor window?
/Mikael
You wouldn't be able to pull it out to the other monitor.
Dave,
Speed. It takes 4s to analyze all IDEA classes at my mac (1m if you add
IO time) and >20m to analyze source files (remember, javac has already
done all the work for you). Since you usually have your project mostly
compiled this shouldn't be a major drawback. As for JSPs and other
non-java resources - we plan to analyze them too. This doesn't
contradict class files analysis.
By the way, all the DSM model is completely independent of the
underlying information and dependency analysis types. If a need arise -
and that's for EAP is for - we'll throw in source-level analysis too.
I'm also thinking about using DSM for various non-java dependencies:
spring beans, page flows, etc. Is it interesting enough for anyone?
In the plan.
Hidden row shouldn't be remembered between DSM sessions, right?
You mean like F4? Where should it take you if you have a cell selected?
Will be done.
There are major chances DSM refactoring won't be done in Selena. Let's
keep fingers crossed.
I've experimented with dependency graphs a lot. Unfortunately it was not
practical for IDEA (>10,000 classes). Even modules diagram is too
clattered to understand what's going on.
This is planned. You'll be also able to select a region and mark the
whole region as prohibited dep.
Added to todo list.
There indeed is a secondary sort. It minimizes dependencies in the
upper-right triangle. Can you give me a sample when it doesn't work good?
>I've experimented with dependency graphs a lot. Unfortunately it was not
>practical for IDEA (>10,000 classes). Even modules diagram is too
>clattered to understand what's going on.
True. Where dependency graphs really shine is understanding smallish graphs, particularly less than 20 nodes. They are good for the use cases "show me all elements connected to this one (including cross-dependencies between them)" and especially "Show me what the hell's going on with this cycle". Somewhat less good for "show me all of the subelements within this element", but that's still worthwhile on occasion.
>There indeed is a secondary sort. It minimizes dependencies in the
>upper-right triangle. Can you give me a sample when it doesn't work good?
Ah, got it. That's very clever. What I hit was a particularly sketchy edge case that I just happened to have in a couple of projects. I've got one package that acts as the entry point "n" other packages, each of which has precisely one back-reference to the entry-point package, and no other cross-references between them. The dependency graph will have one horizontal line of "1"s and one vertical line of "1"s which cross on the diagonal, and no matter how you sort the cycle, you end up with "n" dependencies in the upper-right. I suppose you could add a tertiary sort for this case, something like maximize the count of dependencies on the bottom edge of the cycle, but most likely this case can be just ignored. Cycles like that are usually easy to remove in any case.
>I'm also thinking about using DSM for various non-java dependencies:
>spring beans, page flows, etc. Is it interesting enough for anyone?
I'm of two minds on this. It would seem to be the right answer for completeness, but I'm not sure how much actual information will be gleaned from it.
I really like where this is headed, and am glad to see you're tasked to it.
--Dave Griffith
Mike Aizatsky (JetBrains) wrote:
>> Couldn't it be another editor window?
IDEABKL-67
Bas
Just a little sidenote: You may want to mark the DSM Analysis plugin or whatever it is as being JetBrains code so that when an exception occurs I can click the blame button to send the stacktrace to you.
Hello Gordon,
Fixed already.
--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"
All I ask is that DSM be accessible from OpenAPI (or unobfuscated closed API). We have internal dependency management system here and I'd love to plug it into DSM.