D.B.B. Rijsenbrij

Towards a broader view on software architecture analysis of flexibility

Software architecture analysis helps us assess the quality of a software system at an early stage. We describe a case study of software architecture analysis that we have performed to assess the flexibility of a large administrative system. Our analysis was based on scenarios, representing possible changes to the requirements of the system and its environment. Assessing the effect of these scenarios provides insight into the flexibility of the system. One of the problems is to express the effect of a scenario in such a way that it provides insight into the complexity of the necessary changes. Part of our research is directed at developing an instrument for doing just that. This instrument is applied in the analysis presented.

How well can we predict changes at architecture design time

Two years ago, we analyzed the architecture of Sagitta 2000/SD, a large business information system being developed on behalf of Dutch Customs. We were in particular interested in assessing the capabilities of the system to accommodate future complex changes. We asked stakeholders to bring forward possible changes to the system, and next investigated how these changes would affect the software architecture. Since then, the system has been implemented and used, and actual modifications have been proposed and realized. We studied all 117 change requests submitted since our initial analysis. The present paper addresses how well we have been able to predict complex changes during our initial analysis, and how and to what extent the process to elicit and assess the impact of such changes might be improved. This study suggests that architecture analysis can be improved if we explicitly challenge the initial requirements. The study also hints at some fundamental limitations of this type of analysis: (1) fundamental modifiabilityrelated decisions need not be visible in the documentation available, (2) the actual evolution of a system remains, to a large extent, unpredictable and (3) some changes concern complex components, and this complexity might not be known at the architecture level, and/or be unavoidable.

VIEWPOINTS ON MODIFIABILITY

Software architecture is generally regarded as an important tool to achieve systems of higher quality. It is claimed that the foundation for a systems quality is laid by the decisions made in the software architecture. A question that is occupying both researchers and practitioners is in which areas should decisions be made in the software architecture? We believe architectural view models play an important role in the answer to this question. View models consist of a coherent set of architectural views. These view models have both a prescriptive and a descriptive role in the development process. Their prescriptive role is that they call for a number of aspects to be considered when defining a software architecture and their descriptive role is that they provide a framework to document a software architecture. Currently, a number of view models exist, the most important of which are the 4+1 View Model of Kruchten and the four views by Soni et al. In our experience with modifiability analysis for business information systems we found that the views in current view models do not include all information required. In this paper we discuss the views we found useful for architecture level impact analysis of business information systems. They are illustrated using a case study we performed for the Dutch Tax and Customs Administration. We claim that when these views are required for architecture level impact analysis, the decisions they capture should also be considered during architecture development.

A view on components

Components are nowadays considered the next step in information system development. Components are assumed to foster reuse and flexibility and to reduce the complexity of distributed deployment. This paper investigates the properties of components that determine whether the above goals are met. To that end, we explored the literature and had a number of interviews with representatives from tool vendors, tool users and software houses. The resulting views are summarized in this paper and applied to a small example. In our further research, the architecture sketched in this example will be worked out in further detail and compared with the architecture of similar systems found in industry. This will deepen our understanding and assessment of the architectural choices made.

Flexibility of the ComBAD Architectures

Software architecture is nowadays regarded as the first step to achieving software quality. The architect’s main task is to translate quality requirements into a software architecture. An important step is to assess whether the architecture actually satisfies these quality requirements. The purpose of this paper is to explore which architectural choices support flexibility and how flexibility can be assessed. To that end, we explored the ComBAD architecture, whose main objective is flexibility. We investigated the architectural choices made and assessed whether flexibility was achieved. This will not only increase our insight into flexibility in general, but particularly into the assessment of this quality attribute. We use the term flexibility in the broadest sense of the word: to denote adaptability, portability and reusability. Adaptability can be regarded as flexibility in the narrow sense, portability as the flexibility to use a system in various technical environments, and reusability as the flexibility to reuse part of a system in another system.