Ensuring
Supportability with Metrics and Audits
Maintainability is the key issue for the long-term success of software projects and is an important part of the quality process in software projects. Software metrics and audits capture typical shortcomings in the field of error handling and complexity. So it is often necessary to reduce consolidate the current version before further changes are made. This process is called Refactoring [6].
JLin is the primary tool for SAP NetWeaver developers to ensure the supportability and robustness of the program code while writing it. JLin comes with plenty of rules that help finding potential risks for maintenance and robustness in the program code. Unfortunately these rules have to be configured by hand to be really effective.
Use strict settings to enforce maintainability right from the beginning. Static code analysis is a powerful quality assurance tool especially when working with freelancing software developers.
The following tools can be used to generate metrics and audits from source code.
· JLin: Is supported in the SAP NetWeaver Developer Studio.
· PMD: Open-source plug-in that can be used to detect copy&paste coding. Not available in the SAP NetWeaver Developer Studio – can be installed separately.
· JDepend: Open-source plug-in that can be used to create design metrics and detect cyclic dependencies between packages. Not available in the SAP NetWeaver Developer Studio – can be installed separately.
In addition to metrics, every component should be profiled before it is used productively. For every click and scenario measure the following:
...
§ How much CPU is used?
§ How much memory (garbage) is used?
§ Are there memory leaks?
Metrics
Lines of Code (LoC)
The LoC is the sum of all code lines in a compilation unit or class. For Java, empty lines, Javadoc and comments are not counted. Methods with a high LoC count will most likely cause problems if they have to be changed, fixed, or extended.
Cyclomatic Complexity (CC)
The Cyclomatic Complexity measures the program complexity. There is a strong connection between this indicator and error density. Cyclomatic Complexity is defined as the number of decisions (if, for, while and do statements) per method or function, + 1. Switch statements do not increase the Cyclomatic Complexity in this definition so a method or function has a minimum CC of 1.
A CC value in the range of 10-15 should be considered as maximum. Values below 7 are satisfactory, below 5 would be good.
Methods with a CC over 15 should be refactored following the Extract Method pattern before the next change or enhancement. For more details see:
http://www.refactoring.com/catalog/extractMethod.html
Refactoring in the SAP Netweaver Developer Studio
The SAP Netweaver Developer Studio contains Refactoring tools that can be used to safely break up complex methods or classes into smaller entities. Keeping software manageable is no magic with these tools and a catalogue of patterns for refactoring.
For more details see: http://www.refactoring.com/
A practical use case is described at:
http://www.onjava.com/pub/a/onjava/2004/06/16/ccunittest.html
The JLin rule Cyclomatic Complexity Metric can check for thresholds. Before using CC this rule should be reconfigured with INFO_LEVEL=7, WARNING_LEVEL=16 and ERROR_LEVEL=30.
The disadvantage of CC is that it counts conditional and iteration statements only. So a method with 200 statements and method calls has a CC of 1. For more information on CC please have a look at the following Web page:
http://www.sei.cmu.edu/str/descriptions/cyclomatic.html.
Depth of Nesting
This test procedure counts how deep if, switch, for, while, and do statements in a constructor or method are nested. Every loop-nesting level means another level of complexity. A method of complexity O(n) explodes to complexity O(n³) when called in two nested loops and becomes a performance problem. A value of 3 should be considered as maximum.
The JLin rule Max nesting level per method can check for deeply nested methods. Before using this test this rule should be reconfigured with INFO_LEVEL=4, WARNING_LEVEL=6 and ERROR_LEVEL=50.
If a the depth of nesting value is very high it could be necessary to refactor the code according to Replace Conditional by Polymorphism. For more details see:
http://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html
Number of Parameters
This test procedure counts the parameters of a constructor or method. A value of 7 should be considered as maximum.
The JLin rule Arguments per method checks the number of parameters for a method or constructor. Before using this test this rule should be reconfigured with INFO_LEVEL=8, WARNING_LEVEL=11 and ERROR_LEVEL=20.
Number of Attributes
Classes with a very high number of attributes often represent a flat composition of several entities. It is recommended to extract groups of related attributes and their methods to classes and use composition instead.
Number of Operations
If a class has a high number of operations, it should be considered to split up the method.
The JLin rule Methods per Class checks classes that are candidates for decomposition. Before using this test the rule should be reconfigured with INFO_LEVEL=30, WARNING_LEVEL=50 and ERROR_LEVEL=100.
For more details see:
http://www.refactoring.com/catalog/extractClass.html.
Audits
Audits apply pattern matching to Java source code to find common mistakes and maintenance flaws.
Copy & Paste Programming
Copy and paste is a popular way to reuse existing functionality in a different context. Unlike a method, class, or package, there is no formal interface (signature, scope, type) between the pasted code and its environment, so copy and paste is pretty unsafe.
Problems of copy & paste:
· Change Management
Copying program code also copies the bugs. To keep track of the locations where the duplicated code has been used is quiet impossible.
· Productivity
Changes made to any part of the code must be applied to the other methods where the code has been copied to.
· Stability
Side effects may break "proven code" because the environment is different. This applies especially to copied code snippets.
· Reusability
Differences and similarities of replicated code sections are difficult to find because they are hidden in the code and sometimes slightly altered. Copy and paste also prevents reuse in dependent parts of a program because it wraps common behaviour in different interfaces.
· Overall design
New classes can be created very fast with copy and paste and can lead into spending less effort on good and reusable design and results in long and complex methods.
For more details see:
http://www.onjava.com/pub/a/onjava/2003/03/12/pmd_cpd.html
This is certainly a very controversial topic. For more details refer to the book Anti Patterns.
Cyclic Dependencies between Packages
For more details see:
http://www.clarkware.com/software/JDepend.html