Open User123363 opened 3 years ago
@yegor256 i want to take that issue. Do you think implementing dfs inside xsl file is a good approach?
@starkda you can try. Indeed, implementing all metrics in XSL is what this project is about. Only if it's absolutely impossible to do so, we resort to Java.
@yegor256 now i am quite confident that using java is the only applicable approach. What i want to do is to append information about connectivity components to the end skeleton.xml after it is generated so ccm.xsl would capture it. What do you think?
@starkda let's try!
The problem with CCM metrics was found in the file "org/jpeek/metrics/CCM.xsl" in line 65 the variable 'ncc' is assigned the number of methods connected by edges, but^ according to the definition NCC is the number of connectivity components in a graph.
Definition of graph component - https://en.wikipedia.org/wiki/Component_(graph_theory)
An example implementation of an algorithm for finding connectivity components in a graph - https://www.geeksforgeeks.org/connected-components-in-an-undirected-graph/
The class on which the metric works in error:
In the above example you can see that all 5 methods are one connectivity component, however, jpeek says that NCC = 5, so we can conclude that instead of connectivity components he counts the number of connected methods.
According to the definition of CCM, the class given as an example should get a score of 1 because:
Indeed, if we calculate the connectivity components of the graph from the example, then NCC = 1, substituting the correct value in the formula:
The CCM metric will be 1, this will be the correct answer.