21 Jan
2011
21 Jan
'11
9:57 a.m.
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. > 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