Dave wrote:

> It would be really useful to have an Image Analysis and Planning Tool
> which allowed one to understand the interdependencies between
> classes/methods and globals.  Ideally one would be able to plan a
> reorganize of the image without actually doing it in place. Being able
> to see the impact of many changes before making them would reduce the
> image FUD which one faces when trying to decide if you really dare make
> those sweeping changes that you think are either trivial or impossible.
> Hopefully the work by Stephan et al may come to play in such a tool. Our
> experience with running the Packager is that the more often people ran
> it the more they learned about problems in their image and the more
> concerned they became about writing more modular code. 

Five years ago I thought this would be pretty important... so that is actually 
what I've spent most of my time building in Oasis.  I don't recall if I've 
described some of those before, but basically they are as follows... throughout 
the last few years I've routinely used these models to analyze entire image's 
worth of class libraries... and in Oasis, I can indeed do this while such code 
is nicely tucked away in its own environment.

Referencing Model - a very coarse-grained analysis which tells me which classes 
refer to which globals.  Very simple, easy, and fast to compute.  Those of you 
who are looking at schemes such as partitioning along class category lines to 
find out what cross-references exist are doing something similar to this.

Expectations Model - a much finer-grained model, this model can be used in lots 
of ways, though I've been focusing on a much harder analytical problem ( below 
).  "Expectations" refers to the notion that in Smalltalk we do not have types, 
rather we have expectations- all we know is that we "expect" to be able to send 
a message to a particular object, that this message send will answer some 
object, and perhaps we have further expectations on what messages we can send to 
that result.  This model gathers information about where messages are being 
sent, and to whom, throughout a given chunk of code.  From it, you can learn 
many things.  I think that this is similar to what CodeCrawler provides.

Shard Model - Smalltalk does not have Interfaces as first class objects.  But 
there are cases where one would like very much to be able to rapidly peer deep 
inside a large mass of code to find out what messages are being sent back and 
forth to the objects acting in the various roles in that code.  The belief is 
that while Smalltalk does not have Interfaces, nonetheless they actually do 
exist, although implicitly, rather than explicitly.  Shards are the fragmentary 
evidence that Interfaces exist.

( skipping some steps )

Facet Model - A Facet is what Java would call an Interface.  That is, a Facet is 
a particular piece of the total Interface of an object.  If you really believe 
that the Interfaces exist, then there ought to be a way to extract them from 
their implicit existence.  This may or may not still be a hard problem.  It has 
most definitely been an extremely difficult one up to this point... but perhaps 
that is no longer the case.  The evidence from the Shard model has been 
overwhelmingly in favor that the Facets do exist... but getting that last step 
out of the way has been very difficult.  This is where I've actually spent the 
vast majority of my time on Oasis- the problem has strong appeal, the evidence 
from the Shard model is very supportive, but until recently none of the 
algorithms I've tried to complete this process worked.  I now have one that is 
looking much more promising, so at last I have the chance to explore this on its 
merits, rather than on perceptions.  I am very hopeful, not just to have 
completion on this particular problem, but so that it will cease to devour what 
little time I have to work on Oasis, so that I can finally turn my attention to 
some other issues and get Oasis into a shareable state.


- les