Jan Bosch

Software Architecture as a Set of Architectural Design Decisions

Software architectures have high costs for change, are complex, and erode during evolution. We believe these problems are partially due to knowledge vaporization. Currently, almost all the knowledge and information about the design decisions the architecture is based on are implicitly embedded in the architecture, but lack a first-class representation. Consequently, knowledge about these design decisions disappears into the architecture, which leads to the aforementioned problems. In this paper, a new perspective on software architecture is presented, which views software architecture as a composition of a set of explicit design decisions. This perspective makes architectural design decisions an explicit part of a software architecture. Consequently, knowledge vaporization is reduced, thereby alleviating some of the fundamental problems of software architecture.

On the notion of variability in software product lines

The authors discuss the notion of variability. We have experienced that this concept has so far been underdefined, although we have observed that variability techniques become increasingly important. A clear indication of this trend is the recent emergence of software product lines. Software product lines are large, industrial software systems intended to specialize into specific software products. The authors provide a framework of terminology and concepts regarding variability. In addition, they present three recurring patterns of variability. Finally, they suggest a method for managing variability in software product lines.

A taxonomy of variability realization techniques

Development of software product families relies heavily on the use of variability to manage the differences between products by delaying design decisions to later stages of the development and usage of the constructed software systems. Implementation of variability is not a trivial task, and is governed by a number of factors. In this paper, we describe the factors that are relevant in determining how to implement variability, and present a taxonomy of variability realization techniques. Copyright

Software Architecture: The Next Step

This position paper makes the following claims that, in our opinion, are worthwhile to discuss at the workshop. 1) The first phase of software architecture research, where the key concepts are components and connectors, has matured the technology to a level where industry adoption is wide-spread and few fundamental issues remain. 2) The traditional view on software architecture suffers from a number of key problems that cannot be solved without changing our perspective on the notion of software architecture. These problems include the lack of first-class representation of design decisions, the fact that these design decisions are cross-cutting and intertwined, that these problems lead to high maintenance cost, because of which design rules and constraints are easily violated and obsolete design decisions are not removed. 3) As a community, we need to take the next step and adopt the perspective that a software architecture is, fundamentally, a composition of architectural design decisions. These design decisions should be represented as first-class entities in the software architecture and it should, at least before system deployment, be possible to add, remove and change architectural design decisions against limited effort.

COVAMOF: A framework for modeling variability in software product families

A key aspect of variability management in software product families is the explicit representation of the variability. Experiences at several industrial software development companies have shown that a software variability model should do four things: (1) uniformly represent variation points as first-class entities in all abstraction layers (ranging from features to code), (2) allow for the hierarchical organization of the variability, (3) allow for the first-class representation of simple (i.e., one-to-one) and complex (i.e., n-to-m) dependencies, and (4) allow for modeling the relations between dependencies. Existing variability modeling approaches support the first two requirements, but lack support for the latter two. The contribution of this paper is a framework for variability modeling—COVAMOF—that provides support for all four requirements.

Product derivation in software product families: a case study

From our experience with several organizations that employ software product families, we have learned that, contrary to popular belief, deriving individual products from shared software assets is a time-consuming and expensive activity. In this paper we therefore present a study that investigated the source of those problems. We provide the reader with a framework of terminology and concepts regarding product derivation. In addition, we present several problems and issues we identified during a case study at two large industrial organizations that are relevant to other, for example, comparable or less mature organizations.

Architecture-level modifiability analysis (ALMA)

Several studies have shown that 50-70% of the total lifecycle cost for a software system is spent on evolving the system. Organizations aim to reduce the cost of these adaptations, by addressing modifiability during the systems development. The software architecture plays an important role in achieving this, but few methods for architecture-level modifiability analysis exist. Independently, the authors have been working on scenario-based software architecture analysis methods that focus exclusively on modifiability. Combining these methods led to architecture-level modifiability analysis (ALMA), a unified architecture-level analysis method that focuses on modifiability, distinguishes multiple analysis goals, has explicit assumptions and provides repeatable techniques for performing the steps. ALMA consists of five main steps, i.e. goal selection, software architecture description, change scenario elicitation, change scenario evaluation and interpretation. The method has been validated through its application in several cases, including software architectures at Ericsson Software Technology, DFDS Fraktarna, Althin Medical, the Dutch Department of Defense and the Dutch Tax and Customs Administration.

Design erosion: problems and causes

Design erosion is a common problem in software engineering. We have found that invariably, no matter how ambitious the intentions of the designers were, software designs tend to erode over time to the point that redesigning from scratch becomes a viable alternative compared to prolonging the life of the existing design. In this paper, we illustrate how design erosion works by presenting the evolution of the design of a small software system. In our analysis of this example, we show how design decisions accumulate and become invalid because of new requirements. Also it is argued that even an optimal strategy for designing the system (i.e. no compromises with respect to e.g. cost are made) does not lead to an optimal design because of unforeseen requirement changes that invalidate design decisions that were once optimal.

From integration to composition: On the impact of software product lines, global development and ecosystems

Three trends accelerate the increase in complexity of large-scale software development, i.e. software product lines, global development and software ecosystems. For the case study companies we studied, these trends caused several problems, which are organized around architecture, process and organization, and the problems are related to the efficiency and effectiveness of software development as these companies used too integration-centric approaches. We present five approaches to software development, organized from integration-centric to composition-oriented and describe the areas of applicability.

Superimposition: a component adaptation technique

Abstract Several authors have identified that the only feasible way to increase productivity in software construction is to reuse existing software. To achieve this, component-based software development is one of the more promising approaches. However, traditional research in component-oriented programming often assumes that components are reused “as-is”. Practitioners have found that “as-is” reuse seldom occurs and that reusable components generally need to be adapted to match the system requirements. Existing component object models provide only limited support for component adaptation, i.e. white-box techniques such as copy–paste and inheritance, and black-box approaches such as aggregation and wrapping. These techniques suffer from problems related to reusability, efficiency, implementation overhead or the self problem. To address these problems, this article proposes superimposition, a novel black-box adaptation technique that allows one to impose predefined, but configurable types of functionality on a reusable component. Three categories of typical adaptation types are discussed, related to the component interface, component composition and component monitoring. Superimposition and the types of component adaptation are exemplified by several examples.