3354 Analyze-> Show Package Cycles... Abstract Art


See attached dependency graph. Isn't it pretty?
Reminds me of a Spirograph.

Cycle Size: 79, Strength: 67691, Girth: 2, Radio: 4, Diameter: 6, Best Fragment Size: 1



Attachment(s):
analyze_cycles.gif
14 comments
Comment actions Permalink


Perhaps some refactoring might be in order...

--Dave Griffith

0
Comment actions Permalink

Dave Griffith wrote:

>Perhaps some refactoring might be in order...
>

>

The hidden question is
"Where to start?",
or
"How can IDEA help me find 1°/ where to start, and 2°/ what to do?".
I'm sure a book could be written on the subject, around an example.


At a smaller scale, one "simple" feature would be very helpful:
"Dependency Cycle View" : click on a dependency links should show
dependency info.
http://www.jetbrains.net/jira/browse/IDEA-1883


Alain

0
Comment actions Permalink

Dave Griffith wrote:

>Perhaps some refactoring might be in order...
>

>

Some classes/packages dependency cases are normal - ex: PsixxUtils. It
would be useful to annotate those classes, to improve the dependency
analysis result display (filtering, sorting), and the dependency graphs
(colouring the OK links).


Alain

0
Comment actions Permalink

Small class dependency cycles are normal, particularly because some patterns more-or-less require them (Visitor being the prime example). In fact, the point of some patterns is to not so much get rid of cyclic class dependencies, but to compact the necessary cyclic structures to the smallest possible size, so you can forget about them.

Package dependency cycles are a lot more difficult to justify. In fact, I've never really heard a justification. Got one?

--Dave Griffith

0
Comment actions Permalink


>"Where to start?"

To be honest, the disease may be too widespread. This is a graph you print out and show to your boss when he asks why the application he paid to build has become effectively unmodifiable. Even with the best tools, this is looking like a multi-week job. But if you must...

>"How can IDEA help me find 1°/ where to start, and 2°/ what to do?".

IDEA could show you which of the links in the graph could be broken by a set of simple dependency inversions or package splitting, and give you an action to automatically do that. It could also make a guess as to what a good levelization of the graph could be, so you would have an idea of just which back-links you should be trying to break. Compuware has a tool that does both of those ( http://javacentral.compuware.com/products/optimaladvisor/ ). I've heard it uses JetBrains refactoring and inspection engines underneath, but I can't verify that.


>I'm sure a book could be written on the subject, around an example.

The best book for understanding all of this is Lakos's Large Scale C++ Design ( http://www.amazon.com/exec/obidos/tg/detail/-/0201633620/102-5812856-9243317?v=glance)
It's somewhat dated, and a lot of the issues with C++ are
blisfully absent in Java, but it's still a great book for understanding the design of large systems from a dependency-graph view.

BTW, unless things have changed recently, the "Show Package Cycles..." functionality is part of MetricsReloaded, not IDEA (although, as always, they are welcome to incorporate it into the core). I'm always looking for ways to improve it, but it hasn't been my highest priority of late. Posting requests about it to JIRA is a no-no, though.

--Dave Griffith

0
Comment actions Permalink

Alain Ravet wrote:

The hidden question is
"Where to start?",
or
"How can IDEA help me find 1°/ where to start, and 2°/ what to do?".
I'm sure a book could be written on the subject, around an example.


I've got a lot of respect for _Agile Software Development: Principles,
Patterns, and Practices_ by Robert C. Martin
(http://www.amazon.com/exec/obidos/tg/detail/-/0135974445/).

It goes into detail about why cycles are bad, and how to fix them. Where
to start is in packages that are volatile, but are depended upon by
more-stable packages (the book has metrics to measure
stability/volatility, or you can just use Metrics Reloaded). What to do
is Dependency Inversion, which can be accomplished in one step in IDEA
with Extract Interface (or Extract Superclass, making the superclass
abstract). You stick the interface with the stable package (or in a
separate, third package), that the volatile package depends on, thus
'inverting' the dependency.

--
Rob Harwood
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

0
Comment actions Permalink

Dave Griffith wrote:


>Package dependency cycles are a lot more difficult to justify. In fact, I've never really heard a justification. Got one?
>

>



Now that you're asking, I'm not so sure anymore !
:(


Alain

0
Comment actions Permalink

Rob

Where to start is in packages that are volatile, but are depended upon
by more-stable packages (the book has metrics to measure
stability/volatility, or you can just use Metrics Reloaded).




What set of metrics would you use?
I must confess I don't know where to start with Metrics Reloaded. It's
too big, too much, too many and too dry.


Alain

0
Comment actions Permalink

Alain Ravet wrote:

What set of metrics would you use?
I must confess I don't know where to start with Metrics Reloaded. It's
too big, too much, too many and too dry.


I would suggest finding a copy of Agile Software Development. It
explains which metrics to use and when. I believe Metrics Reloaded has
the right stats, but like you, I found it too information overloaded, so
I usually choose packages/classes by sight and intuition.

I would start with Instability and Abstractness, which are discussed in
Chapter 20 of ASD. Basically, you want more-stable packages to be
more-abstract. Depend on abstractions, not concrete things.

--
Rob Harwood
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

0
Comment actions Permalink

>I believe Metrics Reloaded has
the right stats, but like you, I found it too information overloaded, so
I usually choose packages/classes by sight and intuition.

Suggestions for improvement would be eagerly accepted. I will be doing some improvements to usability in the (much delayed) next release, including prebuilt sets of metrics and links to websites for further information. That said, I agree that the usability of the metrics analyses lags far behind that of the inspections. I'm really not sure how to improve it, short of massive visualization solutions like Compuware OptimalAdvisor or HeadWay ReView. Sadly, those stretch a single developer's capacity to build.

--Dave Griffith

0
Comment actions Permalink

Dave,

Suggestions for improvement would be eagerly accepted.




The simplest improvement would be put some pre-packaged profiles in the
plugin, and add a html comment area per profile, to document the why and
how to use.

From Rob's suggestion, one would be "find volatile packages".


Alain

0
Comment actions Permalink

>The simplest improvement would be put some pre-packaged profiles in the
plugin, and add a html comment area per profile, to document the why and
how to use.

Already got it about half implemented.

>From Rob's suggestion, one would be "find volatile packages".

The metrics involved are "Abstractness", "Instability", and "Distance from the main sequence", under "Package Metrics". They'll be packaged together as "Martin Metrics", in the next release.

0
Comment actions Permalink

Dave Griffith wrote:
>>The simplest improvement would be put some pre-packaged profiles in the


plugin, and add a html comment area per profile, to document the why and
how to use.

Already got it about half implemented.

>>From Rob's suggestion, one would be "find volatile packages".


The metrics involved are "Abstractness", "Instability", and "Distance from the main sequence", under "Package Metrics". They'll be packaged together as "Martin Metrics", in the next release.


Yes, I forgot the Distance one. That's good too. Those three metrics
together are a good starting point for finding and fixing poorly
designed package dependencies. Try to keep packages close to D=0 or at
least mostly less than 0.5. Try to maximize the number of packages close
to (A, I) = (1, 0) and (0, 1). It's not really attainable, but it's the
right direction to move towards.

--
Rob Harwood
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

0
Comment actions Permalink

Dave Griffith wrote:

>>The simplest improvement would be put some pre-packaged profiles in the
>>
>>
>
>Already got it about half implemented.
>

>


A sample project, that would show all the problems (1 per package, 1
package per profile) would be useful, for you to check the profiles, and
for us to learn the metrics, and compare the before/after refactoring
metrics;


Alain

0

Please sign in to leave a comment.