Tracking changes in the architecture of J2EE banking systems at ERSTE BANK Hungary
The need to reverse engineer and analyze the architecture of J2EE systems in business critical banking systems is obvious. Indeed, many of these systems are based on a 3-layer architecture using mainly Java technology. At the bottom, there resides the database layer which consists of tables, stored functions and procedures, triggers, and other database elements. At the top the Java code is being executed which encapsulates the business logic, usually. Between these two layers an application server is located which keeps the connections alive, provides execution environment for the running applications. The architecture of such a system is non-trivial: it is very hard to verify if two components are in relation, and its much harder to answer if they should be. But there is a more important question: when the system changes (e.g. new binaries are deployed, the database schema is altered), what effects do the changes imply? Static impact analysis is a method that may answer the question.
In the project the main goal was to detect and visualize the architectural changes of the enterprise systems, which helps understanding what has happenned to the code. Visualization also helps to determine which test cases should be executed to fully cover the changes. What we did:
- We performed a static analysis of the database side PL/SQL code and created an abstract representation (ASG - Abstract Semantic Graph) of it
- The same was performed for the top level Java code as well
- By using the deployment descriptor files and other configuration XMLs, we created a supergraph containing the entities and relations of all three layers
- The process has been repeated for consecutive versions of the systems, and for each version the obtained supergraph has been uploaded to the SourceInventorty repository
- The GUI of SourceInventory makes it easy to query and visualize the changes in architecture between the consecutive versions
