Architecture Analysis

Do the implementation of your system
and its software architecture match?

Only if architecture and design are in sync with your code you are sure you can use the architecture as a guideline for discussing the impact and gravity of new features and thus the evolution of your products. That is what architecture is meant for.

Architecture conformance is key to success in the long run

Using the architecture verification ensures developers do not abandon the foundation of the system under development. Structures remain clean and clear. In safety and security relevant systems, architecture has in itself safety and security attributes that must be implemented in the code. Hence architectural deviations pose a threat for safety and security. This threat is effectively mitigated through architecture verification.

Where does the architecture come from?

The architecture verification is based on a structural model of the architecture and/or the design of your software. This structure can be an UML model or any other graph structure.

Axivion has import facilities for a broad variety of tools like Enterprise Architect, IBM Rational Rhapsody® and so on. So integration of the verification and your architecture and design processes is straightforward.

If you do not possess an architecture documentation yet, recovery, reverse engineering, and modelling is also supported by the Axivion Suite. Our Professional Services Team supports you in all activities related to architecture verification: Importing architectures, mapping to the code, reverse engineering of architectures etc.

Depending on the initial requirements, the architecture analysis starts with an existing semi-formal model, a documented description of the architecture or assumptions about a possible architecture. You could roughly describe these categories as architecture verification, architecture recovery and architecture archaeology. There are intermediate states and the goal is always to create the prerequisites for continuous architecture verification.

Architecture verification

Architecture verification uses an architecture description in the form of semi-formal notation, as provided by UML. Axivion Suite can import models and mapping information from widely used UML tools such as Enterprise Architect and IBM Rational Rhapsody®.

After the import, the graph of the model can be directly compared with the graph of the implementation resulting from the code analysis. If there is a match, there will be a convergence, if there are surplus edges in the model there will be an absence, and if there are surplus edges in the implementation there will be a divergence as a result. It will then indicate problems in the code.

Implementation and architecture can now be correlated in an iterative process. Once this goal is achieved, verification can become an integral part of the CI process. Architecture violations will then be detected immediately and can be discussed and resolved at an early stage.

Architecture recovery

Architecture recovery starts in a known project. At the beginning of the project there may have been architecture notations that were not maintained.

New requirements and maintenance tasks have watered down this original architecture and it was also not checked consistently.

Nevertheless, an idea of a basic architecture still exists and rudimentary fragments thereof are still available. The architecture hypothesis is now derived from these fragments and assumptions. The hypothesis is validated by comparison with the implementation and deviations are eliminated in an iterative process.

At the end, a validated architecture is available again, which enables the process of continuous architecture verification to begin.

Architecture archaeology

If you inherit a project from another department or from a customer, the initial situation in architecture issues is usually far from a validated architecture.

Often the documentation is insufficient or incomprehensible and all you can do is make assumptions about a possible architecture. In principle, the approach is similar to that of architecture recovery, but in an extreme form.

The first hypothesis chosen should be as simple as possible in order to identify the large structures and also to hazard some guesses. This process can be supported by analysing the current state. The Axivion Suite shows you the actual state of your system structure, here you may already be able to recognise first patterns.

In any case, it is worth learning as much as possible about the software structure and intention in advance, so you can propose meaningful initial hypotheses. The architecture analysis of the Axivion Suite will support you here.

The Axivion Suite is a real game changer. Thanks to continuous tests, the programmers go through a learning curve, which increases acceptance of the respective architectural requirements. In this kind of software archaeology project, this clears the way for reaching Level 3 of the Automotive SPICE standard.

Kosmas Kopmeier
Director Engineering Consulting, SynSpace Group GmbH