So first thing: the metrics implemented by Andre are used to do automatic re-structuring of classes into packages as Alex said. But they are only the metrics, you need an algorithm to do the actual regrouping of class in packages. The algorithms uses the metrics to know what classes are "closer" one to the other. Without this algorithm (not very difficult to implement) there is always the possibility to use the metrics as quality metrics for existing packages.
However I would be cautious about that. Actually, I started to implement them (and Andre took the flag recently) to experiment more formaly their real interest.
Cool! I would be interested to see this.
Sure, whatever you want, just ask :-) We have a paper as CSMR 2011, if this is what you mean ?
My impression is, actually, that they are not that much interesting for this purpose, that people do not really group classes based on cohesion/couopling considerations, but rather or higher level consideration (like all UI goes there, and all security code goes there, ...)
This is what happen most of the time. You may see a strong coupling between Seaside and Pier, but they live in different packages. And you have JComponent and JButton both in Swing, while JComponent does not reference JButton that much.
BTW, jannik did a related work with DSM, except he was looking at cycles, i.e. he used another metric.
Which metric?
his metric is: "how much dependency cycles are there between packages?" he tries to lower this metrics just as one can try to lower coupling (bunch coupling or any other).
We don't pretend Bunch cohesion/cooupling metrics are better than other, it is just that Bunch is a well known tool. There are many other metrics and I personnaly believe that they are all more or less equivalent (in quality, not in results).
I think we should look for some other metrics, more conceptual probably, ... ?
nicolas