Architecture Reconstruction to Support a Product Line Effort: Case Study

Dali currently uses the PostgreSQL relational database. By executing the SQL code in the file, one set of tables is created for each relation. The data is then entered into these tables. At that point, two additional tables are generated: components and relationships. The components table lists the set of source and target elements. The relationships table lists the set of relations extracted from the system.

4   View Fusion

The View Fusion process involves defining a set of queries to manipulate the extracted views and create fused views. We carried out two fusions in this case study:

1. Fusing the information from the various views to determine the types of elements in the components table.
2. Developing a very high-level system decomposition.

In some cases, a static call view may be fused with a dynamic call view. The reason is that a static view may not provide all of the architecturally relevant information required. In the case of late binding in the system, some function calls may not be identified until run-time, so there is a need to generate a dynamic call view. These two views needed to be reconciled and fused to produce the complete call graph for the system. In reconstructing these systems, however, only static information was available.

One of the automotive motor systems contained code developed by the organization, external code for the CAN bus, and code to interface between these two pieces of software. In performing the reconstruction, we were interested in identifying the code in each of these parts of the system (high-level components). We wrote a query that created a separate table within PostgreSQL for each component and derived its visualization. Figure 4 presents a view of all three high-level components.

This high-level decomposition allowed us to concentrate our reconstruction efforts on the most important code to the organization, the INTERNALSW component.

5   Architecture Reconstruction

The Architecture Reconstruction phase consisted of two primary activity areas:

1. visualization and interaction
2. pattern definition and recognition

Once Dali has opened and loaded the database containing the various views, it generates a visual representation similar to that shown in Figure 5. We examined the visualization to define and recognize the various patterns, and uncover the architecture of the system.

By aggregating the variables and functions the file contains, we were able to obtain a view of the system in terms of various files and their relations. Figure 6 shows this visualization.

In this view, the connections (arcs) between the nodes (files) represent different types of relations. For example, there may be simple relations such as one file includes another file, or the arc could represent composite relations of different types (a function in the file calls a function in the other, and a variable in the file is accessed in the other).

We began to identify architecture components by reading comments in the code to determine what functionality was being carried out in the file. We also read the documentation and talked to system maintainers. This enabled us to identify several components and determine which files belonged to a particular component. A visualization of the components was generated by creating and executing a pattern on the view shown above in Figure 6. The resulting view is shown in Figure 7.

By reading the comments and examining the code, we learned that that the HWPARAMETER component consisted of a set of declaration of hardware specific variables that were included in almost every file. We manipulated the visualization manually to hide this component. By similar means, we identified that the UTILITY component consisted of a set of utility functions that were accessed by almost all of the components. We manipulated the visualization to hide this component, as well.

An examination of the BLACKBOARD component revealed how it was used. The component contains a set of files in which large sets of variables are declared. Other components access the values in these variables (access_read view) and some of the components set the values of these variables (access_write view). We identified this approach as the blackboard architectural style and produced the view shown in Figure 8.

Next, we removed the BLACKBOARD component and the arcs to it to determine the functional decomposition of the system. Figure 9 shows a visualization of the functional decomposition. All the arcs except the calls view between functions in the components are hidden.

By removing the COMMIF and EXTERNALSW components from the view, we isolated software of interest in the case study. This updated view is shown in Figure 10.

In this view, we can identify some layering between the components. The MAIN component is at a higher layer than the CONTROL component and there is a layer under that containing the USERIF, CRITICAL, PTION, and EEP components. However this is not a strictly layered architecture, as we can see by the links between MAIN and the lower level components USERIF, CRITICAL, PTION, etc. By examining these links, we determined that the main function (contained in the MAIN component) contains a cyclic executive that calls various functions in the different components. This architecture style is typical of embedded system software with hard performance requirements.

6   Results

The view of the software in Figure 10 shows the various architecture components in one of the motor systems. The same process outlined in the last section was carried out for the three systems in the case study. In each of the systems, we identified similar components. We also came up with several important differences in characteristics among these systems by talking to the maintainers. For example, each system had different performance requirements. In the motor system with the CAN bus interface, certain information was obtained from the CAN bus. This information was not available in the other systems because they lacked this interface.

We further identified several architectural styles in the three systems:

• blackboard style. It shows that system functionality was divided across several computational steps; and each step is a knowledge source. Together, they follow a set of rules to form the solution. After each computation, several reactions are possible. We captured this using a large amount of state variables.
• cyclic executive style. It was identified in the MAIN component of each system. The MAIN component calls functions in each of the other components. This architecture style is typical of embedded system software with hard performance requirements and with both critical and less critical functionality.
• partial layered style. It was identified in each of the systems, although it was not strictly followed because of the cyclic executive.

We used the system reconstructions to determine the architectural and technical feasibility of developing a software product line from the three small automotive motor systems. A method, Mining Architectures for Product Line Evaluations (MAP) [Stoermer 01], has been developed that outlines the activities required to help stakeholders make that decision. Currently, the customer organization has an effort underway to develop a product line architecture for two of the motor systems and has produced a prototype product line. The organization is now investigating the feasibility of including the other system as well as additional products in that product line.