The usual suspects -
* Inheritance, 
* Class references in code

(You can stop reading here, unless you care about modules... )

and also...
* The name of method categories. If a category begins with an asteriks,
all the method in it are considered to be parts of a class extension,
which has a separate node than the class. 

For example: 

Object>>mimeType references MIMEDocument, and thus creates a bad
dependency. Rename it's method category from MIME to *Network-Url, and
the dependency is gone. 

As far as dependency detection knows, it's part of a class extension in
the system category Network-Url.

The next step we need is a menu item on SystemCategories that allows you
to file out the class in the category, 
 plus all the methods in extension method categories named like itself, 
 minus all the methods in itself, that live in class extension
categories that are not itself.

Then we can maintain modules in complete separation, without relying on
changesets.

Daniel Vainsencher

Stephane Ducasse <ducasse at iam.unibe.ch> wrote:
> Really interesting.
> I do not have the time to look at your code now. Can you tell what are 
> the information you take into account?
> 
> 
> On dimanche, septembre 15, 2002, at 03:22  PM, danielv at netvision.net.il 
> wrote:
> 
> > Change Set:		SpaghettiTrace
> > Date:			15 September 2002
> > Author:			Daniel Vainsencher
> > Prerequisites:	3.2
> >
> > Tool for understanding indirect links between code.
> > If you have trouble, please run the tests first.
> >
> > setup (this will take a minute or two):
> > graph _ CodeGraphCreator graphForClassesAndExtensions: Smalltalk
> > allClasses
> >
> > The following show one way each class is dependent on the other (there
> > could be other ways):
> >  CodeAnalyzer pathBetween: MIMEDocument and: Object in: graph (Simple
> > inheritance)
> >  CodeAnalyzer pathBetween: Object and: MIMEDocument in: graph (bad bad
> > link!! ;-)
> >  CodeAnalyzer pathBetween: MIMEDocument and: GeeBookMorph in: graph
> > (whats that got to do with it?!!)
> >
> > You can also find paths between groups of classes (useful to analyze
> > whole categories):
> >  GraphAnalyzer new shortestPathFrom: {#Object} to: {#MIMEDocument}  in:
> > graph
> >
> > Components show what groups of classes are interdependent:
> >  components _ GraphAnalyzer new findStrongComponentsIn: graph
> >  (components detect: [:e | e includes: #VRMLNodeSpec]) size (ok,
> > interesting)
> >  bigComp _ (components detect: [:e | e includes: #GeeBookMorph]) size
> > (Gulp)
> >  components select: [:e | e size > 1]
> >
> > Another way to define components is that you can find an indirect link
> > between any two node, in both directions. Probably on at least one of
> > those directions you can find a good example of a bad dependency. You
> > can see them using pathBetween:.. as above.
> >
> > CodeAnalyzer pathBetween: (Smalltalk classNamed: bigComp atRandom) and:
> > (Smalltalk classNamed: bigComp atRandom) in: g
> >
> > Have fun.
> >
> > Daniel Vainsencher
> > <SpaghettiTrace.cs.gz>
> Dr. Stéphane DUCASSE (ducasse at iam.unibe.ch) 
> http://www.iam.unibe.ch/~ducasse/
>   "if you knew today was your last day on earth, what would you do
>   different? ... especially if, by doing something different, today
>   might not be your last day on earth" Calvin&Hobbes