From Source Code to Architecture

The first step in working with Sotoarc is to parse the source code of the software system to be investigated. This can be carried out with Sotoarc's GUI or automatically in a batch mode. During this process the resulting information is stored in an integrated repository.

There is not sufficient information in the source code to detect the underlying architectural structures automatically. For this reason Sotoarc makes it possible to define architecture models which describe how the structural elements of a software system, such as files, packages, directories and namespaces can be combined into larger architectural entities called modules, and how these modules may use each other.

Sotoarc architecture models serve to raise the level of abstraction in the visualization of software systems, and to check the conformance with the corresponding source code. Architecture models can be transferred to the Sotograph tool where they can be used for more detailed analyses and for trend monitoring.

Modules

From an architectural point of view, a software system consists of modules with well-defined interfaces and responsibilities. Modules cannot be directly extracted from source code where the highest level of abstraction is formed by items like Java packages, C# namespaces or directories. These are automatically mapped to logical packages of Sotoarc including their corresponding tree structure. Modules are composed of a set of these logical packages. Deployment components such as Java archives, assemblies or DLLs can be used as input to generate modules, but they do not necessarily correspond to architectural modules. For this reason the module structure is frequently defined manually in Sotoarc.

Modules can be defined ad-hoc with direct manipulation in the Sotoarc-GUI or with rule-based operations. The advantage of rule-based operations is that the resulting module structure adapts itself to an evolving code base. Modules have an optional public interface which Sotoarc checks for compliance.

Modules can be subsystems or layers. They can be flexibly nested, which makes it possible, for example, to define a layered architecture for the content of a subsystem.

Architectures

Architecture models serve to define how modules are allowed to cooperate. Most frequently, layer modules are used, which are arranged to form layered architectures. Layered architectures forbid upward references between layers and, in the case of strictly layered architectures, the access to certain lower layers.

Sotoarc provides additional mechanisms to flexibly allow or forbid references between any kind of modules. Typically, an architecture model consists of one or more layered architectures with other mechanisms used to define a few supplementary attributes.