[Soot-list] Structure of Soot (OO Design)

[Hayden Melton]

 > Thank you for putting a metric to how difficult it is to understand Soot
> code. Over the last month I have been refactoring Soot beyond
> recognition, trying to isolate the optimization routines from the
> parsing and code generation. Soot feels as though every class depends on
> every other class; a huge ball of spaghetti where pulling on any strand
> pulls brings the whole ball with it.
>
> Your graph certainly verified my feeling.

I'm glad the metric matches your intuition. It's been a bit of a mission
convincing some open-source developers of its usefulness! One problem i think
is that open source developers often understand the whole system they work on,
so understand what every class in a cycle does. But for a `newb' like myself to
understand their system it's very hard because everything's cyclically
dependent. I empathize with ya dude.



Eric Bodden: I have made available the data that I used to generate those
graphs. Follow this link, scroll down to the table and download the zip file
for the latest version of Soot:

http://www.cs.auckland.ac.nz/~hayden/corpus.htm

You can use this information to show which files participate in the SCCs and
which have large transitive dependencies. In terms of actual refactoring
there's no silver bullet. The Azureus people used a move-method refactoring on
some static methods to break up some SCCs.

My feeling is that classes with a high fanin that are involved in large SCCs are
a good place to start. Classes that are widely referenced are often
``low-level" classes and should not depend on ``high-level" classes. Look at
these and see if you can reduce their dependencies by extracting interfaces,
creating new classes, moving methods etc. There is a catalogue of refactorings
specifically for breaking cyclic dependencies in John Lakos's book
``Large-Scale C++ Software Design".

/
Hayden






>
>
> Hayden Melton wrote:
>
> >Hi all,
> >
> >
> >I’m a PhD student at the University of Auckland, New Zealand. As part of my
> >research I am doing empirical studies on a corpus of Java applications
> looking
> >at their (OO) design. If you are a developer of Soot you might be interested
> in
> >the metrics I have collected on it. They are available as graphs here:
> >
> >http://www.cs.auckland.ac.nz/~hayden/junitEvolution.htm
> >
> >There’s an explanation of what the graphs mean on my research page:
> >
> >http://www.cs.auckland.ac.nz/~hayden/research.htm
> >
> >Briefly, there are a lot of classes in Soot involved in a big (compilation)
> >dependency cycle (or to use the graph-theory term: strongly connected
> >component). I think this is bad, though it’s only one aspect of the quality
> of
> >a design. Other applications like ArgoUML and Azureus have exhibited this
> large
> >SCC characteristic too. As a result of my contact with the Azureus
> developers
> >they have begun refactoring Azureus.
> >
> >In any case, check it out if you’re interested in the design of Soot; or OO
> >Design and metrics in general.
> >
> >/
> >Hayden Melton
> >
> >_______________________________________________
> >Soot-list mailing list
> >Soot-list at sable.mcgill.ca
> >http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
> >
> >
> >
>
>
> --
> ----------------------------------------------------------------------
> Kyle Lahnakoski                                       kyle at arcavia.com
> (416) 892-7784                                    Arcavia Software Ltd
>
>