Experiences with ALMA: Architecture-Level Modifiability Analysis

Abstract

Modifiability is an important quality for software systems, because a large part of the costs associated with these systems is spent on modifications. The effort, and therefore cost, that is required for these modifications is largely determined by a system's software architecture. Analysis of software architectures is therefore an important technique to achieve modifiability and reduce maintenance costs. However, few techniques for software architecture analysis currently exist. Based on our experiences with software architecture analysis of modifiability, we have developed ALMA, an architecture-level modifiability analysis method consisting of five steps. In this paper we report on our experiences with ALMA. We illustrate our experiences with examples from two case studies of software architecture analysis of modifiability. These case studies concern a system for mobile positioning at Ericsson Software Technology AB and a system for freight handling at DFDS Fraktarna. Our experiences are related to each step of the analysis process. In addition, we made some observations on software architecture analysis of modifiability in general.

Introduction

Software evolves, whether we like it or not. Studies indicate that more than 50% of total life cycle cost is spent after initial development (Lientz and Swanson, 1980; Nosek and Palvia, 1990). This high cost of software maintenance is caused by the incorporation of all kinds of anticipated and unanticipated changes after the system has been delivered. Bass et al. (1998) make a distinction between local, non-local, and architectural changes. A local change involves the modification of a single component. A non-local change requires modifications in multiple components. An architectural change affects the fundamental ways in which the components interact, and is likely to require changes all over the system. Obviously, local changes are preferable to non-local and architectural changes.

During software development, a number of strategies are applied to ease a system's evolution, such as separation of concerns, information hiding, the application of design patterns, etc. Note, however, that the use of `improved' software engineering technologies does not necessarily incur lower maintenance costs. For instance, Dekleva (1992) found no difference in maintenance costs between systems developed using development methodologies considered modern at that time, and those developed using a more traditional approach. Development methodologies were considered modern if they produced an implementation-independent logical representation of a system's function. Dekleva found that such modern development methodologies lead to changes in the allocation of maintenance time. Less time was spent on bug fixing, evaluating change requests, and the like, while more time was spent on implementing changes imposed by external factors and functional enhancements. Apparently, those modern methodologies enable the realization of significant enhancements, while traditional methodologies facilitate patching but discourage users to request major changes. We may conjecture a similar phenomenon, i.e. maintenance will be different but not necessarily cheaper, for architecture- based development versus non-architecture-based development. We have no empirical data to substantiate this conjecture, yet.

Another strategy that may be employed to enhance the modifiability of a system is to assess the quality of interim results produced in the development process. In particular, the software architecture of the system may be assessed to determine the evolutionary capabilities of the system yet to be built. IEEE Standard 1471 (IEEE, 2000) defines software architecture as `the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution'. The software architecture captures the first design decisions concerning the system.

In an architecture-based development process, the result of these design decisions is represented in an architectural description. The main mechanisms to represent architectural descriptions are architecture description languages (ADLs) and view models. ADLs resemble module interconnection languages (MILs) (Prieto-Diaz and Neighbors, 1986). For an overview of ADLs, see (Medvidovic and Taylor, 2000).

View models are based on the principle that a software architecture cannot be captured in a single view. View models define a number of aspects of a software architecture that should be addressed in a software architecture description, e.g. (Kruchten, 1995) or (Soni et al., 1995). The views in both these models are represented as box-and-line diagrams. Their semantics are defined rather informally. A more recent version of the latter model uses UML to define its semantics more precisely (Hofmeister et al., 1999).

Early design decisions captured in these models have a considerable impact on various quality attributes of the system, including its modifiability. It thus pays off to assess these quality attributes at this early stage. We have defined a generalized, adaptable method for architecture-level modifiability analysis (ALMA), which is based on the Software Architecture Analysis Method (SAAM) (Kazman et al., 1996). ALMA is a generalization of earlier work by the authors independently (Bengtsson and Bosch, 1999; Lassing et al., 1999). In this paper we illustrate our experiences in using ALMA in two case studies. One case concerns a system developed by Ericsson Software Technology for positioning mobile telephones, and the other case concerns a system for freight handling at DFDS Fraktarna. The observations made in this paper corroborate and strengthen our individual experiences in earlier studies (Bengtsson and Bosch, 1999; Lassing et al., 1999).

In Section 2, we sketch ALMA. The steps of this method are used in subsequent sections to structure our experiences and put them into perspective. Section 3 introduces the two cases. Our experiences are described in Section 4. In Section 5, we conclude with some summarizing statements.