49445230DEV452-fc6e85e048-50
Improve how to use section on README.md How to Use section must be improved; we need to explain the many parameters that jpeek jar accepts and the default values for each parameter.
README.md@yegor256yegor256@gmail.com49512030DEV120-5199fe2242-44
TCC: inclusion of inherited attributes and methods in the analysis should be configurable. Come back here after #187 is fixed and adjust the xpath for `attrs` and `methods` accordingly.
src/main/resources/org/jpeek/metrics/TCC.xsl@yegor256yegor256@gmail.com49612030DEV120-7c3cf0d448-49
TCC: this metric needs to exclude private methods from the analysis. Adjust the xpath for `methods` accordingly after #188 is fixed.
src/main/resources/org/jpeek/metrics/TCC.xsl@yegor256yegor256@gmail.com49721630DEV216-5540d94267-71
LCOM4: "NotCommonAttributesWithAllArgsConstructor" test now fails. Constructor with all attributes parameters should not affect LCOM4 metric. So LCOM4.xsl needs to be fixed in order to avoid constructors affection to the metric values. "NotCommonAttributesWithAllArgsConstructor" test case must be added into collection returning by the targets() in the MetricsTest.java when this puzzle done.
src/main/resources/org/jpeek/metrics/LCOM4.xsl@yegor256yegor256@gmail.com4986430DEV64-b6d7d67d66-69
Implement the C3 method according to the description above. The variable names and comments have to be extracted into a set of words. JPeek core will have to provide all comments for each method so words can be extracted and LSI calculated for each method.
src/main/resources/org/jpeek/metrics/C3.xsl@yegor256yegor256@gmail.com4996530DEV65-657d930a51-53
TLCOM: we are including access to ALL fields here. After #156 is fixed, come back and refactor xpath for $Ms_that_use_attrs, $left_attrs, and $right_attrs in order to avoid including access to fields belonging to other classes.
src/main/resources/org/jpeek/metrics/TLCOM.xsl@yegor256yegor256@gmail.com5006530DEV65-8529ead179-83
TLCOM: need to establish transitive connections between methods with arbitrarily long chains of method calls between them. Right now, this code can establish transitive connections to a max depth of 3 levels, ie up to something like this: m1 calls m2 calls m3 which uses a3 therefore m1 is connected to m3. It will miss connections in longer chains. After fixing this, maybe we can add it to the standard metrics in App.
src/main/resources/org/jpeek/metrics/TLCOM.xsl@yegor256yegor256@gmail.com5016515DEV65-76f12f4d86-87
TLCOM: add test for OneMethodCreatesLambda after #171 is fixed. The extra synthetic method introduced by the compiler distorts this metric's result.
src/main/resources/org/jpeek/metrics/TLCOM.xsl@yegor256yegor256@gmail.com50211130DEV111-5690cd5a27-36
LORM: figure out how to extract the concepts from each method of a class and then measure their "dispersal": how far apart they are semantically speaking. This would be the same as asking "to what degree are these methods talking about the same things?". Based on a couple of supporting papers that I added to this ticket (here: https://github.com/yegor256/jpeek/issues/111#issuecomment-365651455), I believe the way forward is to use Latent Semantic Indexing of the methods of the class and see how close or synonymous they are with the concept expressed in the class name itself. There seem to be a few java libraries available for latent semantic indexing that we can use.
src/main/resources/org/jpeek/metrics/LORM.xsl@yegor256yegor256@gmail.com50311230DEV112-f7b740c574-95
Implement natural language processing techniques to analyze conceptual similarity of methods. Two methods have a `conceptual-relation` if they contain at least one same `concept`. `concepts` are identified by semantic processing of the class/method, as being associated in the knowledge-base with that class/method (original paper in /papers/etzkorn00.pdf). The original paper does not explicitly define the implementation of semantic processing, or which NLP methods are being used, but it is a knowledge-based system, which means that additional input must inserted into the LORM method - that is, a set of possible concepts - which are then recognized in a particular method/piece of code. This set of possible concepts depends on the `domain` that the class is in. One way of interpreting what the `domain` is (this is not defined in the original paper), is the business domain the class is used for. Another definition of `domain` also comes to mind - the programming language being used. Concepts could be defined as all reserved Java keywords and "semantic processing" recognizes which reserved keywords are used in a particular method. Hence, if two methods use same reserved keywords, they have a `conceptual-relation`. Using this definition would require no additional input by the user of the LORM method. Right now it is stubbed because NLP/semantic processing is not implemented yet.k Ensure that JPeek core implements these techniques, collects information on such relations and unstub the lines commented below.
src/main/resources/org/jpeek/metrics/LORM.xsl@yegor256yegor256@gmail.com50411930DEV119-5f1c56e063-69
`indirectly-related-pairs` are pairs of methods, which are connected through `directly-related-pairs`. See section 3.1 of https://pdfs.semanticscholar.org/672e/de6e3e600eafd84036a0b983b88e481ac626.pdf The key sentence is "The indirect connection relation is the **transitive closure** of direct connection relation". See https://en.wikipedia.org/wiki/Transitive_closure for more info on what is a Transitive Closure. We need to apply a Transitive Closure Algorithm on a graph of `directly-related-pairs`. A simpliest Transitive Closure algorithms has O(V³) time complexity and involves a mutable V×V table (V is amount of vertices). See https://www.geeksforgeeks.org/transitive-closure-of-a-graph/ for an example.
src/main/resources/org/jpeek/metrics/LCC.xslyegor256yegor256@gmail.com50513430DEV134-3180ea3826-28
Matrix.xsd: add `xsd:documentation` tags as per issue #134. We need to document the schemas in src/resources/org/jpeek/xsd so that the semantics of the generated XML documents is transparent for maintainers.
src/main/resources/org/jpeek/xsd/matrix.xsdyegor256yegor256@gmail.com50645230DEV452-6485f2e2138-141
Extract report building Analyze method is too big. We need to extract report building from here and use a map instead of if statements se we can make easier to add and remove metrics from execution.
src/main/java/org/jpeek/App.javayegor256yegor256@gmail.com50722730DEV227-fbf042c2174-179
Add a test to check whether passing params to XSLDocument really works. Currently only C3 metric template is known to use parameter named 'ctors'. However C3.xsl is a work in progress and has impediments, see #175. In case the parameter becomes obsolete, consider simplifying construction of XSLDocument without params (see reviews to #326).
src/main/java/org/jpeek/XslReport.javayegor256yegor256@gmail.com50811430DEV114-7bfa1f3a132-143
Find and include the name of the variable the method is called on, if possible. Currently, only the name of called method is retrieved. This is currently implemented in `visitMethodInsn` down below. Example 1: `Bar.NAME.length();` - Here, `length` is retrieved from the method `visitMethodInsn`'s - param `name`, but the word `NAME` itself is not included in any of - the `visitMethodInsn` arguments. Example 2: `src.length();` - Here, `length` is retrieved from the method `visitMethodInsn`'s - param `name` but the word `src` itself is not included in any of - the `visitMethodInsn` arguments.
src/main/java/org/jpeek/skeleton/XmlClass.javayegor256yegor256@gmail.com50947330DEV473-a79b415538-41
Find a way to eliminate this ClassDataAbstractionCouplingCheck. The class probably needs to be split into smaller ones, perhaps extracting the maps into separate objects (extending MapEnvelopes), or maybe the list itself.
src/main/java/org/jpeek/graph/XmlGraph.javayegor256yegor256@gmail.com51041230DEV412-3d56567633-38
We start implementing LCOM4Calculus implementation. We should continue calculating real 'class@value' and 'class/vars/var[@id=pairs]/text' values and remove @Disabled annotation on all Lcom4CalculusTest class. If we choose to calculate LCOM4 with Java only we should also remove LCOM4.xsl part that is doing the calculus and let the xsl here just to build the structure of the xml result. This part is especially the one calculating "xsl:variable name='E'" L73->L89, and the one doing the division L97 -> L99
src/main/java/org/jpeek/calculus/Calculus.javayegor256yegor256@gmail.com51144930DEV449-96cd40b839-50
The `node` method in this interface was designed with only XSL implementation in mind - it uses the `metric` parameter to select the XSL file and uses that file to transform the `skeleton`. This makes Java based implementations a little awkward because the `metric` parameter becomes redundant: there is a Java implementation for each metric, and these implementations already know which metric they are for. The question becomes - how to select correct java implementation for a given metric and integrate it seamlessly with XSL calculus in `XslReport`. One option could be removing the `metric` parameter from the method and injecting a Calculus for a concrete metric in `XslReport` directly. Another could be implementing Chain Of Responsibility pattern. Decide on the best way to integrate Java based Calculus with XSL based Calculus in `XslReport` and implement it.
src/main/java/org/jpeek/calculus/Calculus.javayegor256yegor256@gmail.com51244930DEV449-dd12396b88-94
Implement NCC calculation with `XmlGraph` and use this class to fix CCM metric (see issue #449). To do this, this class, once it works correctly, should be integrated with XSL based calculuses in `XslReport` (see `todo #449` in Calculus). Write a test to make sure the metric is calculated correctly. Also, decide whether the whole CCM metric should be implemented in Java, or only the NCC part. Update this `todo` accordingly.
src/main/java/org/jpeek/calculus/java/Ccm.javayegor256yegor256@gmail.com5136830DEV68-6427b29437-40
SCOM has an impediment on issue #103: cannot currently be tested in MetricsTest when the resulting value is "NaN". Affected tests are: NoMethods, OneVoidMethodWithoutParams, WithoutAttributes, OneMethodCreatesLambda.
src/test/java/org/jpeek/MetricsTest.javayegor256yegor256@gmail.com51411830DEV118-aa952a1547-51
Add test for LCC with "IndirectlyRelatedPairs" and others. In "IndirectlyRelatedPairs" all methods exist in one transitive closure, so the result should be {@code 1d}. Also, all classes without transitive relations should have the same LCC metric as TCC metric. Before do it we have to fix puzzles in LCC.xml.
src/test/java/org/jpeek/MetricsTest.javayegor256yegor256@gmail.com51543730DEV437-43230a3b52-61
Skeleton structure has changed in #437, and therefore some xsl metrics calculus are in error or give bad results. Fix the corresponding xslt files and then reput these expected results in metricstest-params.csv MethodsWithDiffParamTypes,CCM,0.0667d MethodsWithDiffParamTypes,SCOM,0.2381d OverloadMethods,SCOM,0.75d TwoCommonAttributes,TLCOM,4.0d Bar,CCM,0.2222d TwoCommonMethods,CCM,0.0333d TwoCommonMethods,LORM,0.26667d
src/test/java/org/jpeek/MetricsTest.javayegor256yegor256@gmail.com51641530DEV415-1e78bb5374-77
LCOM4: Graph algorithm to determine disjoint sets. Disjoint sets calculus is now implemented. We should continue calculating LCOM4 metrics (probably you should wait for #413, #403. After implementing, remove the @Disabled from the below test too.
src/test/java/org/jpeek/metrics/Lcom4Test.javayegor256yegor256@gmail.com57011930DEV119-e522f2bb44-50
`indirectly-related-pairs` are pairs of methods, which are connected through `directly-related-pairs`. See section 3.1 of https://pdfs.semanticscholar.org/672e/de6e3e600eafd84036a0b983b88e481ac626.pdf The key sentence is "The indirect connection relation is the **transitive closure** of direct connection relation". See https://en.wikipedia.org/wiki/Transitive_closure for more info on what is a Transitive Closure. We need to apply a Transitive Closure Algorithm on a graph of `directly-related-pairs`. A simplest Transitive Closure algorithms has O(V³) time complexity and involves a mutable V×V table (V is amount of vertices). See https://www.geeksforgeeks.org/transitive-closure-of-a-graph/ for an example.
src/main/resources/org/jpeek/metrics/LCC.xslYegor Bugayenkoyegor256@gmail.com57152230DEV522-5ca0c25872-75
there is a 4th step for incorrect calculation: nc in case of calling one method from another because of `xsl:if test="$method/ops/op/text()[. = $other/ops/op/text()]"` method name is not used for creating edge.
src/test/java/org/jpeek/metrics/CcmTest.javaYegor Bugayenkoyegor256@gmail.com57253560DEV535-cc53a61c24-26
renderOneReport is not stable on checking /shutdown endpoint Increasing timeout does not help, problem should be investigated and response validation returned back
src/test/java/org/jpeek/web/TkAppTest.javaYegor Bugayenkoyegor256@gmail.com