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