I am not shure, if I bother you with all this theory at all. But to me it seems necessary to talk about the basics, before presenting the results for the individual JSF frameworks.
Part I introduced the analysis results and metrics from quite popular developer tools like JavaNCSS, Checkstyle and Findbugs.
These are usefull during development and can give you a brief idea about the code base in general in terms of implemented source quality. Up to now, we only know about how much the developers care about maintainability and readability of their sources. And we do possibly know a little about the general development skills of the teams, because we know, how many bug pattern they have been taken care of.
What is still missing are metrics to judge about the software design. But of course you can analyze software with this scope, too. Even if the results are far less concrete than the already presented ones, they are not less important. This will only give you a very brief summary about it. If you want to know more about
it, you have to take the time and take a look at all those great theory behind. And of course you have to look at many projects and findings to know, what the results are going to tell you!
A good place to start is the XDepend Homepage. Beside the fact, that they deliver an awesome tool, you also find many details about the collected metrics.
Some of the analysis I am going to do with the JSF Frameworks are generated by XDepend.
Cumulative Component Dependency (CCD)
The metric of the metrics itself. CCD, is the sum over all components Ci in a subsystem of the number of components needed in order to test each Ci incrementally. This is true for direct and indirect dependencies.
Impact:
If you try to change code which has a high CCD, you probably have to change a lot of other dependend classes too.
This is error-prone and will generate new bugs in your software.
Threshold:
The major design goal is to keep the CCD low in general.
Derived metrics are the avarage component dependency ACD and the normalized cumulative component dependency, NCCD, which is the CCD devided by the CCD of a perfectly balanced binary dependency tree with the same number of components. The CCD of a perfectly balanced binary dependency tree of n components is (n+1) * log2(n+1) - n.
Average Component Dependency (ACD)
Expresses the average component (equivalent to 'compilation unit') coupling. It is the sum of all component depedencies divided by the number of components (SIZE).
Average Component Dependency = CCD(N)/N (N is # of components).
Impact:
An ACD of 20 indicates for example, that on an average the component depends directly and indirectly
(transitively) upon 19 other components +1 for itself.
Threshold:
The major design goal is to keep the ACD low in general. it should not exceed 20.
Afferent Coupling (Ca)
There are a number of coupling metrics available. Two of the well know ones are Afferent Coupling (Ca) and
Efferent Coupling (Ce). These integer based metrics represent a count of related objects.
Ca counts how many classes are using another package to compile sucessfully.
Impact:
Afferent Coupling signify an architectural maintenance issue, that an object has too much responsibility
(high Afferent Coupling).
Threshold:
There is no treshold for Ca in general. Using other packages is not bad in general. But you should keep in mind,
who is using what.
Efferent Coupling (Ce)
Ce counts how many classes used by the other package are needed to compile sucessfully.
Impact:
Afferent Coupling signify an architectural maintenance issue, that the object is not independent
enough (high Efferent Coupling).
Threshold:
There is no treshold for Ce in general. Beeing used by other packages is not bad in general.
But you should keep in mind, who is using what.
Instability (I)
The ratio of efferent coupling (Ce) to total coupling. I = Ce / (Ce + Ca).
Impact:
This metric is an indicator of the package's resilience to change. If I is near 1 it means the package
is instable. You can change it with nearly any effect on dependenc classes. If I is near 0 the package
is stable. Changes will have a big impact on other packages.
Threshold:
The range for this metric is 0 to 1.
Abstractness (A)
The ratio of the number of internal abstract types (i.e abstract classes and interfaces) to the number
of internal types.
Impact:
This metric is an indicator of the package's abstractness. If A is near =, you have a complete concrete
package without any abstract types. If A is near 1 you only have abstract types.
Threshold:
The range for this metric is 0 to 1
Distance (D) and I/A-Diagrams
D stands for Distance from main sequence. The perpendicular normalized distance of an assembly
from the idealized line A + I = 1 (called main sequence).
This metric is an indicator of the assembly's balance between abstractness and stability.
Impact:
An assembly squarely on the main sequence is optimally balanced with respect to its abstractness and
stability. Ideal assemblies are either completely abstract and stable (I=0, A=1) or completely
concrete and instable (I=1, A=0).
Threshold:
The range for this metric is 0 to 1, with D=0 indicating an assembly that is coincident with the
main sequence and D=1 indicating an assembly that is as far from the main sequence as possible.
D should have a value between -0.6 and 0.7.
If you draw a diagram from this, you can see if an assembly is in the zone of pain (I and A both close to 0)
or in the zone of uselessness (I and A both close to 1).
That's all theory for now. The third part will start delivering the results of the code analysis for PrimeFaces, RichFaces and ICEFaces.Stay tuned.
