AIP Underlying Technology

CAST – at the end of 2015 counting over 100 of the brightest developers and technologists in the business – has continuously worked on the topic of system-level code analysis and insight for over 20 years. Analyzing complex, multi-layer business applications requires an understanding of the numerous technologies and frameworks used. It requires realization that the intent of a procedural code like that found in C does not involve the same mechanisms found in object oriented Java or C#. The constructs such as a call-back in C or virtual calls in object oriented programming (and more globally, polymorphism) requires more than syntactic analysis. One must also understand the flow of data across the different programming elements as if the application were actually being executed.

AIP Underlying Technology

Numerous frameworks that are used to reduce development effort themselves introduce technologies and concepts with new behaviors that must also be understood. Behaviors like the Action class notion from JEE Struts framework, for example, must be well understood to perform an accurate analysis. In the JEE world alone, there are dozens of presentation, persistence, or inversion control frameworks such as Struts, JSF, Hibernate, Spring, etc. that require illumination to gain comprehension of their impact through an application.

And these technologies don’t remain static – they all constantly evolve and adapt to take advantage of new insights and techniques. New patterns like dependency injection design or lambda expressions, emerge frequently to help developers cope with ever growing complexity and new business demands. And while these new insights and technologies help develop performant and maintainable applications, they add an extra layer that must be well understood to determine what source code actually “does”.

The ultimate challenge is to then combine the understanding of each technical layer into a global, holistic understanding of the complete system. This is a necessity to accurately assess the software application’s health. How does the Javascript front-end talk to the business logic in C#? How does the C# communicate with the Cobol program and the CICS monitor? Is the SQL procedural statement working safely with the database? All of these questions can only be answered by a deep understanding of the whole system. Simply aggregating the quality of each component would be quicker, but those analytics wouldn’t reflect the true health and architectural defects wouldn’t be found. To achieve a real understanding of the system, code analyzers must speak to each other and understand each other. This is the only way to gain real insight into the true health of your application.