A Two-phase Process for Software Architecture Improvement

Recipe 1:

　　1. Rename the files of unit U so that they get the proper prefix.
　　2. Move the files of unit U to the directory (subsystem) to which the archiving module belongs.
　　3. Change all import statements in all the units according to the newly created name of the header file of unit U.
　　4. Adapt the build description (change file names, adapt include paths, etcetera).
　　It is possible to modify the software by hand by following the recipe, but this is a tedious and error-prone task. For large systems, the build description may consist of dozens of makefiles, which must all be analysed and possibly adapted. Moreover, worst case 1518 units may need to be adapted to include the proper import statements. For this relatively simple architecture transformation we already need tools to change the software.

　　Idea 2:

　　In legacy systems, functions may be organised in an arbitrary unit. During construction, a developer is sometimes pressured by time constraints to put a specific function in one unit while semantically it would fit better in another unit. The architect decides to move the function to the correct unit, say function F in unit U to unit X. The detailed recipe for applying this idea to the software depends heavily on for instance the implementation languages. Let us again take the programming language C as an example, then more specifically the recipe contains the following entries.

　　Recipe 2:

　　1. Move the declaration and definition of function F to the header file and body file of unit X respectively.
　　2. Change the #include statements in files that use function F.
　　3. Adapt the build description files.

　　Referring to step 1 in the recipe: moving the function declaration and definition is not trivial, and the types used in the function have to be within the scope of the new location, which means relocating type definitions or adding additional #include statements. The same holds for global variables and macros that are being used. Although idea 2 is similar to idea 1 (the same change but at a different level of abstraction) the recipes are different. Therefore we must consider these changes to be different. In general we can say that changes are dependent on the applied level of abstraction.

　　Idea 3:

　　Several units in the software contain identical functions or so-called function clones. The architect considers removing all but one, and changing the use relation of the units accordingly. The architect uses metrics for cohesion and coupling to determine which of the function clones should remain in the software. Once he or she has determined which function is the best choice (by trying one and using backtracking before trying the next), the following recipe can be executed.

　　Recipe 3:

　　1. Change the #include statements in the files that use one of the functions that will be removed.
　　2. Remove the function-clones.
　　3. Adapt the build description.

　　The impact analysis of a change of this kind has been exercised and implemented in the Abstract-level Re-clustering Tool (ART [Bro99]) developed at Philips Research, which calculates the impact of clone elimination and re-clustering based on the cohesion and coupling metrics.
　　In the case of embedded systems we should also consider the target system files (executables, dynamic libraries, scripts). These files are generated during construction and copied to the appropriate location on the target (for instance an EPROM). In a first experiment we decided to keep the target executables the same, i.e. not to change the communication protocols between the executables (which may occur if the architect moves a function from one target to another). In a next experiment, it is possible to also model the execution view of the systems, including the communication, after which the impact of such changes can also be viewed.

　　In this example we have given three ideas that are of interest to an architect after inspecting the views of the model (like the one presented in Figure 3). One can also consider more automation by introducing algorithms that try several changes using architectural metrics. Architectural metrics also abstract from the details of the system and can indicate some quality aspect of the system at some level of abstraction.