K.Analytics Application Analysis

So you have an application that you think/know is suffering from technical debt and is in need of some sort of attention. But you don’t know the condition of the application, how complex it is, how well written and, therefore, have no clue as to the best course of action. Do you refactor it? Can you? What about modernizing it? Or rewriting it? What are the costs, risks and timescales associated with each approach?

In yesterday’s post on Gartner’s TIME model we highlighted the difficulty of using a 2-D approach (technical condition/business value) to the analysis of what to do with legacy systems and suggested the problem is at least 3-D (adding in the driver to change) if not n-D. Well, the condition of the legacy application in question takes us beyond the third dimension.

At Morphis we use our own proprietary solution, K.Analytics, for the analysis of software applications. K.Analytics has been designed to be language-independent, as all analysis processes are performed on an abstraction of the target source code, which we refer to as the Abstract Syntax Tree. Through this abstraction, K.Analytics is able to examine more than just the code text itself, but how it all connects. As such, Kuscos supports a wide range of languages already, including:

• Cobol
• Embedded SQL (DB2) in Cobol
• JCL
• SAP ABAP
• PL/1
• Java
• JavaScript
• PL/SQL
• T-SQL
• VB6 (and variations)
• Delphi
• Powerbuilder
• C#
• VB.NET
• ASP
• ASP.NET
• Oracle Forms

By way of illustration of the analytical capabilities of K.Analytics, the following shows a sub-set of the results from analyzing a web application (AWS, DynamoDB, S3) written mainly in Java and including specific frameworks and Java-based technologies such as Project Reactor and Spring. The application was implemented using some of the features of the Facade design pattern and oriented to a services and microservices architecture using REST/JSON.

At the highest level, system metrics such as the number of modules, LoC, #comment lines etc are generated by K.Analytics.

[x_image type=”thumbnail” float=”none” src=”https://morphis-tech.com/blog/wp-content/uploads/2017/05/Screen-Shot-2017-05-10-at-12.39.24-PM.png” info=”none” info_place=”top” info_trigger=”hover”]

[x_image type=”thumbnail” float=”none” src=”https://morphis-tech.com/blog/wp-content/uploads/2017/05/Screen-Shot-2017-05-10-at-12.39.43-PM.png” info=”none” info_place=”top” info_trigger=”hover”]

Immediately it is obvious that the application is not well commented, falling far below the 30% to 75% you would expect for an application of this type.

K.Analytics also produces a design quality report that describes and specifies software quality and complexity. One metric used is cyclomatic complexity that measures the number of linearly independent paths through a program’s source code. Tabular:

[x_image type=”thumbnail” float=”none” src=”https://morphis-tech.com/blog/wp-content/uploads/2017/05/Screen-Shot-2017-05-10-at-12.57.31-PM.png” info=”none” info_place=”top” info_trigger=”hover”]

An average cyclomatic complexity of 9.93 (which is good) and a total of 23,114, Kuscos also produces a graphical representation which highlights the modules responsible for the greatest complexity.

[x_image type=”thumbnail” float=”none” src=”https://morphis-tech.com/blog/wp-content/uploads/2017/05/Screen-Shot-2017-05-10-at-11.18.38-AM.png” info=”none” info_place=”top” info_trigger=”hover”]

Cyclomatic complexity can then be used to derive decision density which is useful predictor of software maintainability. The Halstead Difficulty shows how difficult the application is to write or understand and the graphical representation (not shown) quickly highlights that the Turma.java module is the main culprit.

Structural fan-in and fan-out are also measured enabling the complexity of the static structure of the code to me determined. These values can be combined with other metrics such as the Halstead Effort/Difficulty to verify if the modules with high reuse are very complex. If they are, then they should be refactored.

Instability and maintainability are also key factors analyzed by K.Analytics.

Ultimately, different metrics can be combined, for example in this application, to identify the complex modules that also have the greatest external dependencies on the system. In this case, the Turma module.

[x_image type=”thumbnail” float=”none” src=”https://morphis-tech.com/blog/wp-content/uploads/2017/05/Screen-Shot-2017-05-10-at-11.19.51-AM.png” info=”none” info_place=”top” info_trigger=”hover”]

Code quality assessments against industry or company-defined standards is also a feature of K.Analytics. For more details on this and for further details on the other features of K.Analytics already presented, learn more about K.Analytics.