Approach and findings of an architecture analysis within the framework of a code review

After the last article looked at important key figures from the static analysis of a code review, aspects of manual analysis are now highlighted. How does an architecture analysis work in a code review and what conclusions can be drawn from it?

From the software architecture, the essential elements of the system and the relationships between them can be identified. The architecture is significantly influenced by the non-functional requirements (e.g. time behavior and resource consumption) of a system. Knowledge of non-functional requirements is therefore of great importance for carrying out an architecture analysis on an existing application.

The illustration of the architecture by an external code review can be very useful for the client. Thus a comparison can be made between a possibly existing target architecture and the realized architecture in the application. This allows deviations to be detected and it can be assessed whether the application is suitable for use in planned operating scenarios. When evaluating the structure of an application, a target architecture or at least knowledge of a desired operating scenario is decisive. An architecture can only be evaluated if it is placed in a context. The meaningfulness of an architecture cannot be evaluated without knowledge of the application and/or deployment scenario.

The easiest way to show and illustrate the architecture of an application is to use diagrams. For example, the following UML diagrams can be used to illustrate the structure of an application:


Component diagram: Displays the relationships between the individual components using interfaces, dependency relationships, and connectors.

Distribution Diagram: Describes the dependencies of components by displaying their distributions and the relationships between the components on computer nodes.

In practice, variations of UML notations are often used. It is important to ensure general comprehensibility, which is why it is advantageous to adhere to common conventions. In order to be able to visualize an architecture, the rough structure of an application must first be understood. Two different procedures are suitable for this. Firstly, it can be helpful at the beginning to divide the software into large modules (backend, frontend, database, …).  This can be used to check which interfaces and data flows exist between the individual modules. From which module data are sent where and how are they further processed? Based on these questions, further components/modules can usually be added to the diagram until an overall picture emerges. After completion of the overall picture, it must be relatively easy for the viewer of the diagram to recognize what kind of components the software has and how they work together.

Another possibility to analyze the structure of a software is an automatically generated source code division into modules and the underlying components. Using this overview, as a kind of component tree, it is easy to determine which modules exist and for which functionalities they are responsible in the system. The individual modules then have to be linked via existing interfaces, data flows and dependencies.

In the first approach, the overall picture is approached by a rough division into modules, which is gradually refined. In the second variant, we start from the very small structure of the modules and their underlying components in order to group them together and put them in relation to each other. In addition to the visualization of the architecture image, the frameworks and technologies used are also considered and evaluated. The main question here is whether an application with its structure and the technologies used can be regarded as fit for the future and whether it has made use of a current technology stack. In the case of applications that have been in operation for some time, it must be assessed whether updates to newer versions are required and whether these are possible.

For the client, a code review with architecture analysis provides valuable insights. When considering the architecture for a specific application scenario, it can be evaluated whether it is suitable for this. If this is not the case, suggestions for improvement and recommendations for action can be made in order to align the application better with the target scenario. In addition, an assessment can be made of the future suitability of the application in its current state and with the technologies used.


Benny Schwarting
As an IT consultant, Benny is responsible for project coordination and requirements engineering. He always has an open ear for our customers and their requirements and supports them with good ideas to find the optimal solution