Motivation

The architecture of a software system describes its decomposition into smaller components and the relationships between them. This decomposition typically has two goals:

  • Smaller components are easier to handle than a large monolithical software system
  • If two units have no relationship with each other, they can be developed independently.

The architecture of a software system thus typically determines which relationships between components are allowed in the software system. Additionally, it determines which dependencies between components are not allowed, since they would decrease the maintainability, flexibility or extensibility of the software.

If the architecture of a software system is only represented as documentation, it can easily become outdated. The goal of the architecture analysis in ConQAT is to automate the evaluation of an architecture definition against its implementation in source code. This way, inaccuracies in the documentation and code fragments that violate the architecture can easily be spotted.

Architecture Analysis in ConQAT

The architecture conformance analysis is part of the architecture bundle.

The idea behind the analysis is very simple. ConQAT reads:

  • Very lightweight description of the system architecture
  • Implementation of the system

ConQAT then extracts the types and dependencies from the system implementation and maps them against the architecture. The detected violations are presented in different forms:

  • Architecture level: Architecture graph with violating dependencies between components
  • Implementation level: Lists of violating dependencies between types. ConQAT currently supports architecture analysis on Java and all .NET languages.

Architecture Definition Formalism

Architectures are defined using a very lightweight architecture description language. It comprises three concepts:

Component Hierarchy

Describes the decomposition of a system into components. A component can have sub-components. Each architecture has a single root component. We have found this simple model to be sufficiently expressive to model the system architectures we have so far encountered.

Dependency Policies

Determine which components may be in a relationship with each other. Each dependency policy has a source and a target component.

Mapping

Maps implementation artifacts to architecture components. Mapping is performed using regular expressions that work on the fully qualified type names. Architecture descriptions are stored in XML. They are created and maintained using the Architecture Editor.

JUnit Architecture Analysis

This section presents a ConQAT configuration that performs an architecture analysis on the JUnit project.

This architecture definition is not based on the official documentation of JUnit, but has been built to demonstrate the architecture analysis feature of ConQAT. Its purpose is thus merely demonstrative, and does not try to reveal weaknesses in the architecture of JUnit.

Architecture Definition

The specified architecture of JUnit looks like this:

JUnit Architecture

The architecture has 4 top-level components: JUnit, Lib, Samples and Tests. The components JUnit contains sub-components TextUI, Experimental, … The green arrows between components depict that dependencies between them are allowed.

The yellow arrow between Samples and Tests indicates that the dependencies between these components are not allowed, but tolerated for now. As a tribute to industrial practice, violating dependencies can be marked as “tolerated”. In this case, the dependencyjunit.samples.AllTests -> junit.tests.AllTests Has been tolerated. This feature can be used to differentiate between violations of different “severity”.

Run Configuration

The Java architecture analysis performed by the predefined block JavaArchitectureAnalysis from the blocklib bundle. The examples contain a ready-to-use run configuration to perform an architecture analysis of JUnit. To do this, open and run the configuration architecture-example-junit.cqr

Analysis Results

After the analysis finished, you get the results in two representations: as an assessment file (called architecture-assessment.xml, in the output folder) that you can open in the ConQAT Architecture editor and as a static HTML file (index.html in the output folder).

If you open the assessment file in ConQAT, you can interactively inspect the discovered violations. To do so, open the architecture file junit.architecture in architecture editor and click the Switch Editor Mode button as depicted below:

Architecture Editor Switch

The editor will then display the assessment result.

Architecture Assessment

The static HTML file looks like this:

Architecture Assessment HTML

  • A Outline. The outline contains pages that visualise the architecture definition and the assessed architecture in filtered and unfiltered versions.
  • B Assessed Architecture. This page displays the architecture together with the violations found in the implementation.
  • C Violations. List of violating dependencies between implementation elements.

The filtered architecture assessment pages are especially suitable if the architecture analysis is applied in continuous scenarios. It only displays the architecture violations.

NUnit Architecture Analysis

The architecture analysis for the .NET platform looks very similar. The ConQAT examples contain an architecture analysis on NUnit.

Please note again that the architecture definition used in the example is not based on the official documentation of NUnit, but has been built to demonstrate the architecture analysis feature of ConQAT. Its purpose is thus merely demonstrative, and does not try to reveal weaknesses in the architecture of NUnit.