Model-based software analysis

Model-based software analysis


Working with legacy code often suffers from a lack of human understanding, due to e.g.:

  • Outdated documentation

  • Missing test scenarios

  • Key developers that left

  • Use of multiple technologies

  • Mix of development approaches

Software engineers and architects thus spend a lot of time to fully understand a legacy system and its software.

ESI (TNO) is developing methods to analyze legacy software, improving human understanding of its functionality and structure. The semi-automated methods help to quickly answer analysis questions of engineers and architects, preventing manual error-prone work and improving efficiency.

Model extraction is used to create an accurate and up-to-date knowledge base that is used for various analysis purposes. To answer specific questions, customized analysis is often crucial. The analysis results can be used to improve or qualify the system and its software.

Up-to-date, high-level overviews beyond what regular developer environments offer are extremely valuable. Multi-level overviews allow a drill-down to deep-dive into relevant details to quickly find answers to analysis questions, even for large systems. Interactive querying additionally allows for flexibility.

Many different kinds of analysis are possible. Below are some characteristic analysis examples.

Architecture analysis and monitoring

The structure and behavior of a software system can be analyzed to detect violations of prescribed architectural rules. Knowing the violations, the system can gradually be adapted until it adheres to the rules. Monitoring keeps track of the progress made and helps prevents regressions.

Note that you can quickly spot the entangled part in the middle, and the decoupled fragments around it.

Change impact analysis

Software changes are often considered risky, as bugs may be missed during development and testing, resulting in high costs and reduced trust when customers encounter them. Automated comparison of the software, e.g. before and after a redesign or patch, can find unintended side effects of software changes or functionality that differs from a baseline.

Additional information