A method for module architecture verification and its application on a large component-based system

Abstract

A method for module architecture verification is described, which yields support for checking on an architectural level whether the implicit module architecture of the implementation of a system is consistent with its specified module architecture, and which facilitates achieving architecture conformance by relating architectural-level violations to the code-level entities that cause them, hence making it easier to resolve them. Module architecture conformance is needed to enable implementing and maintaining the system and reasoning about it. We describe our experience having applied the proposed method to check a representative part of the module architecture of a large industrial component-based software system.

Introduction

The ever increasing complexity of software systems and the ever more rapidly changing requirements for these systems create a need for a careful design process. Software architecture has proven to be a crucial part of this design process [2]. There is no standard, universally accepted definition of the term software architecture, since it is still a field in its infancy. While there is no standard definition, there is also no shortage of them, see, e.g. [29]. In this paper, we will use the definition of Soni et al. (in Ref. [30]), since it is commonly used within our company.

In Ref. [30], software architecture is defined as the structures of a system and the relationships among the elements both within and between structures. Depending on the engineering concerns involved, several different structures can be distinguished. Kruchten [20] and Soni et al. [30] introduce similar approaches to categorize these structures. Both provide a possibility for separation of engineering concerns in the description of the architecture of a system. Kruchten defines different views (logical view, development view, process view, physical view) based around requirements in the form of scenarios. In this paper, we adhere to Soni et al. who distinguish between several categories of structures: conceptual architecture, module architecture, code architecture, and execution architecture.

An important part of a software architecture of a system is captured by its module architecture. The module architecture captures the functional decomposition of the system (i.e. the decomposition of the system into ‘building blocks’ like, e.g. subsystems, modules, and abstract program units) and it describes the interrelationships between the various ‘building blocks’ of the system [30].

Designing a new system involves designing its software architecture and hence, its module architecture. This so-called specified module architecture (or SMA) is usually documented in the system design specification as a collection of diagrams showing architectural entities and the interrelationships allowed between them. Usually, the SMA is designed very carefully in order to satisfy the requirements of all the stakeholders of the system. The implementation of this system should then be done in such a way, that the module architecture present in the implementation (also referred to as the implicit module architecture (or IMA)) conforms to the SMA of the system.

Conformance¹ of the IMA to the SMA is needed for two reasons: (1) to enable implementing the system and reasoning about it, and (2) to make the system prepared for future changes. Both arguments will be explained below.

The implementation of a complex software system may be so large, that it is impossible for one person to understand all the details of the implementation. Below, we will argue that, still, such large software systems can be implemented applying an appropriate SMA and taking care that the IMA remains consistent with the SMA. The SMA should specify a decomposition of the system into manageable parts (i.e. parts of which all details can be understood by one individual) to enable implementation. Furthermore, it should only allow limited dependencies among the system parts to make integration a feasible task. Then, the system parts can be implemented by separate teams and integrated later on. The SMA provides the overview needed to reason about the system, and to implement and integrate the system parts. However, reasoning about the system is only valid if the IMA is consistent with the SMA. Moreover, this consistency will considerably alleviate the process of implementing and integrating the system parts.

The design and implementation of a large system may take hundreds of man-years. During the lifetime of such a system, the requirements are likely to undergo some changes, requiring adaptations to the SMA and hence, to the implementation. Preferably, the adapted SMA and IMA (say SMA′ and IMA′) are derived from the existing SMA and IMA. Otherwise, one would have to rebuild the system from scratch again, which would take another hundreds of man-years. However, to be able to guarantee that the new system satisfies the new requirements, the SMA′ and the IMA′ of the new system should be consistent. Obtaining a consistent SMA′ and IMA′ by reusing the original SMA and IMA and adapting them so as to satisfy the new requirements requires the SMA and the IMA of the existing system also to be consistent.

In general, however, this so-called module architecture conformance is not automatically guaranteed, and needs to be verified. For large software systems, verifying whether or not the IMA conforms to the SMA is usually quite complex and takes a lot of time when performed by hand.

In this paper, we introduce a method for module architecture verification, which yields support for checking whether the IMA of a system conforms to its SMA. The different steps of the method are depicted in Fig. 1. They will be investigated in detail in Section 2.

The inputs for the method (drawn as boxes at the top of the picture) are the source code, the system documentation and the architects. The verification method consists of a number of steps (drawn as ovals): extraction, derivation, formalization, mapping, abstraction, verification, concretization and presentation. The outputs of the method (being the remaining boxes in the figure) are extracted code elements, architectural elements, constants, a mapping, architectural rules, and violations of the extracted information to those rules, both at architecture-level and at code-level.

The method consists of verification of a number of architectural conformance rules (or architectural rules for short). In our method, we define an architectural rule as a constraint that enforces a relation between architectural entities in the SMA and in the IMA.

The result of module architecture verification is a collection of violations to the architectural rules, which are the architectural entities of the IMA that do not conform to the SMA. Usually, the SMA serves as a blueprint to which the IMA should conform. In this case, the system's implementation should be adapted such that the IMA of the adapted implementation conforms to the SMA. The method supports the system designer to find the pieces of source code that should be changed by translating the architecture-level violations to violations at source code level.

We have successfully applied the proposed method in industry. We have built a prototype tool-set which automatically executes the computation-intensive steps of the method. The tool-set also includes a web-based presentation tool, which provides the results of the architecture verification as a series of browsable web pages. The prototype tool-set has been adopted in industry and is maintained there by the source code management team.

Currently, we have applied the method to verify a considerable part of the module architecture of a new large component-based system during the implementation and integration phase of the system. However, the method would be equally well applicable to verify the module architecture of existing (legacy) systems.

Module architecture verification is not an entirely new area. The idea of verifying module architectures is, among others, mentioned in [4], [6], [14]. No solutions are given in these papers, however.

Solutions to parts of the module architecture verification problem have been published in [1], [3], [11], [15], [24]. Each of them will be addressed in Section 4. In fact, as we will see, each of these solutions corresponds to one or more steps of our module architecture verification method. Implicitly, it is assumed that other steps have already been carried out. In this paper, we describe an overall method for module architecture verification, covering all steps that have to be carried out. As far as we know, applying module architecture verification on an industrial case, as presented in this paper, has not been published before in literature.

The remainder of this paper is structured as follows.

In Section 2, we introduce our module architecture verification method. This reflects the work in Ref. [19]. In Section 3, we investigate an application of the method proposed in Section 2 on a large component-based medical imaging system referred to as LSS. In this industrial case, Relation Partition Algebra (RPA) (published in [8], [9], [10]) has been used as an underlying formalism. We assume that the reader of this paper is familiar with RPA. To make the paper self-contained, we have included Appendix A, which describes all RPA-operators used in this paper. The complete set of RPA operators together with their mathematical foundation can be found in [9], [10].

Section 3 starts with a brief introduction to the medical imaging domain. Then, the verification of one of the architectural rules identified for the LSS is presented. (For completeness, we have added a list with the complete set of architectural rules verified for this system in Appendix B.) Furthermore, an overview is given of the architecture verification tool-set developed for the LSS to automate the computation-intensive steps of the method.

Section 4 discusses related work. Finally, conclusions are given in Section 5.