A Two-phase Process for Software Architecture Improvement

4 Architecture Impact Analysis

　　Software architecture impact analysis is concerned with measuring change on an architectural level. In our process, this not only means visualising the parts of the architecture that are affected by a change, but also comparing the before and after situations. Impact analysis covers steps 2a and 2b of Figure 1. In these steps the software architect interacts with the RPA model. If he or she sees possibilities for improvements, changes can be made in the model and the results can be evaluated and compared with the original. Before the software architect can start interacting with the RPA model, information has to be extracted from the software. The extraction is mostly an automated process.
　　Scripts can be used to extract information from the software often in combination with commercial tools, like QAC [Pro96], Sniff [Tak95] and the Microsoft BSC kit. The type of information extracted is for instance the use relation between functions, otherwise known as the call-graph. The part-of relation for each level of abstraction (Figure 2) can also be extracted. Following the example, the part-of relation between units and modules can be extracted by scanning the filenames of the units for their prefix. Simpler is the part-of relation between modules and subsystems, which relates to files in directories. Note that the same module prefix may have been used in different directories, which in the example is considered an architecture violation that needs to be corrected in a first transformation.

　　Using RPA expressions, it is possible to add high-level information to the RPA model. For instance, the use relation between units can be calculated by lifting the use relation between functions using the part-of relation between functions and units. RPA has a rich set of operators to calculate the high-level information [FO94,FKO98,FO99,FK99].

　　It is also possible to add accounting information by using multi-relations [FK99], so that the architect knows how many static function calls exist from one unit to another. Figure 5 shows an example. The left-hand side shows a use relation of units. The right-hand side shows the lifted use relation (module level) with accounting information.

　　Figure 5: (Multi) Use-Relation

　　One way of evaluating the recovered architecture is using architectural metrics for the different quality aspects. Metrics are defined using an RPA expression, which can be executed on the RPA model. An example of a metric is the cohesion of a unit, which can be expressed as the quotient of the number of internal static function calls and the number of all possible internal static function calls. Some other examples of metrics are listed below.

　　A metric for coupling defines the rate of external connections. The coupling metric, like the metric for cohesion, can be defined for different levels of abstraction.

　　A metric for layering indicates the rate of up-calls in a layered architectural model.

　　Another way of evaluating the recovered architecture is by using box-arrow diagrams as in Rigi [SWM97], the Software Bookshelf [FHK+97] and 3D visualisation [FJ98]. Figure 3 shows how the old and new situations of a simple use relation between modules are related. Restricting views and zoom functions can be calculated on the RPA model to let the software architect focus on the problems at hand. Note that architecture impact analysis is a highly interactive process that cannot be completely automated. The final decisions have to be made by the architect. The process can only show possible changes and their impact. An example of a valuable change in the model is function-clone elimination as described in the example of Section 3.

　　The process for software architecture improvement, supported by the proper tooling, gives us an appropriate framework for investigating the impact of changes on an architectural level, as well as a basis for defining new and better metrics for the different quality aspects.
　　5 Software Architecture Transformations

　　The goal of impact analysis performed on a model of the software architecture is to identify valuable architecture changes, i.e. changes that lead to an improved software architecture. Once one or more valuable architecture changes have been identified in the model, we want to adapt the software of the existing system accordingly. For this purpose a recipe is used, which describes how to translate changes performed in the model of the software architecture into changes in the actual software.
　　A recipe is a generic description of a so-called architecture transformation. An architecture transformation is a transformation in the software, which has an impact on the architectural model of the system.

　　An interesting property of architecture transformations is that they can be combined, so larger architecture transformations can be constructed as a sequence of smaller architecture transformations (see the example below).

　　Our goal is to identify a set of useful architecture transformations. This set will include basic architecture transformations (i.e. architecture transformations that are not described as a sequence of smaller architecture transformations) and composite architecture transformations. Composite transformations consist of a number of basic transformations, but have a right of existence of their own (mostly because they are frequently used). We expect this set of useful architecture transformations to grow in time as we gain more insight into the kind of transformations needed. The basic and composite architecture transformations can be seen as building blocks, from which recipes can be constructed.

　　There are several advantages of constructing recipes as sequences of architecture transformations over constructing them by hand.

　　An architecture transformation provides a standard solution, which can be reused. Constructing a recipe for a certain change, as a fixed sequence of architecture transformations, guarantees that this change will always be performed in the same way. This will probably makes it easier to understand the architecture of the transformed software.
　　Architecture transformations are building blocks, so recipes can be composed as a sequence of architecture transformations, which saves development time.
　　Implementing small basic architecture transformations is much simpler than implementing complete dedicated recipes.
　　We will now give some examples of possible architecture transformations, both basic and composite, based on the example given in Section 3.