J. Henk Obbink

The Past, Present, and Future for Software Architecture

Its been 10 years since David Garlan and Mary Shaw wrote their seminal book Software Architecture Perspective on an Emerging Discipline, since Maarten Boasson edited a special issue of IEEE Software on software architecture, and since the first International Software Architecture Workshop took place. What has happened over these 10 years? What have we learned? Where do we look for information? Whats the community around this discipline? And where are we going from here?This article is part of a focus section on software architecture.

CoPAM: a compact-oriented platform architecting method family for product family engineering

In this paper we describe a family of methods that enable the development of product family architectures. These methods have in common that they offer support in developing a family of software-intensive products on the basis of one or more common platforms, that they use component technology to build the platforms and the products, and that they use several well-defined software development processes. The methods differ in many important decisions regarding processes and architecture, which are tuned carefully to the business and organizational context. In this way the method family establishes a significant synergy in the development of several product families in a large and diverse industrial company.

Multi-view Variation Modeling for Scenario Analysis

We propose an approach using scenarios to describe a spectrum of possible futures and analyze them to assess and improve the ease of accommodating new requirements by a system architecture. Variation modeling forms an important part of the analysis. This paper focuses on an approach to variation modeling across multiple architectural views. The models do not only display the variability in these views, but also the relationships between them. In particular, they can show how choices in one view influence choices in the other views.

Variability Issues in Software Product Lines

Software product lines (or system families) have achieved considerable adoption by the software industry. A software product line captures the commonalities between a set of products while providing for the differences. Differences are managed by delaying design decisions, thereby introducing variation points. The whole of variation points is typically referred to as the variability of the software product line. Variability management is, however, not a trivial activity and several issues exist, both in general as well as specific to individual phases in the lifecycle. This paper identifies and describes several variability issues based on practical experiences and theoretical understanding of the problem domain.

Scenario-based decision making for architectural variability in product families

In this paper, we present a systematic approach towards decision making for variability in product families in the context of uncertainty. Our approach consists of the following ingredients: a suitable set of architectural views that bridge the gap between customer needs and available technology, a multi-view variation modeling technique, the selection of several scenarios of different kinds, and a quantitative analysis of quality aspects for these scenarios.

Systems engineering environments of ATMOSPHERE

The ATMOSPHERE project is partly funded by the Commission of the European Communities as an ESPRIT II Technology Integration Project (TIP). Its ambition is to make a major contribution to the progress of the state of the art of System Engineering in Europe. In order to do so, the project has adopted a very pragmatic approach which is reflected in the ATMOSPHERE acronym meaning: Advanced Tools and Methods for System Production in Heterogeneous, Extensible, Real Environments.

A scenario-driven approach for value, risk, and cost analysis in system architecting for innovation

We present a quantitative method for scenario-driven value, risk, and cost analysis when proposing new system architectures for innovation projects. The method helps to articulate the relative benefits and/or disadvantages of the proposed set of scenarios in the early architecting phases of a new system. It provides the arguments on which to base an informed decision to select the final architectural scenarios for further consideration in the design. In this paper we present a case study in which we applied the proposed method.

ESAPS - Engineering Software Architectures, Processes and Platforms for System Families

Across Europe 21 companies and research institutions work since July 1999 together on the Development and Evolution of Software Architectures, Processes and Platforms for System Families in the ITEA project ESAPS. Based upon earlier and smaller scale experiments in ARES and PRAISE ESAPS aims to improve the state of practice in European industry with respect to the Engineering of Architectures, Processes and platforms for system families in order to achieve significant higher levels of reuse and improved system quality.

Analysis of software architectures in high and low volume electronic systems, industrial experience report

This paper reported about work in progress. One of the main findings is that the Soni ideas, although originated within the Siemens company, are also useful within Philips. We came to similar conclusions as Soni et. al. [1] and particularly we found it difficult to pinpoint the conceptual architecture. Explicit relationships between the various architectures were not always made clear. The most clear is the relationship between module and code architectures. This determined often the relationships between the module and execution architectures, but in general they are difficult to find and in many cases implicit. The similarities and differences among the various systems are surprising. In particular, there appears to be no standard way of representing the various architectures. For each of the individual cases the work has resulted in a much better understanding of the software architectures. In the past these architectures, were either implicit, hidden and scattered over many documents, or only known by the experts. By explicitly extracting them and modelling them from various viewpoints it has become easier to share the relevant architectural knowledge with the non-SW architects (HW-Architects, System Architects, Product Managers, etc.) in the organisation.

Process differentation and integration: the key to just-in-time in product development

In this paper it is argued that in order to achieve the required reduction in product lead-time for embedded software a proper differentiation and integration of a number of key developemt processes like: usability engineering, hardware engineering and software engineering should take place. It is furthermore argued that this makes only sense if an appropriate modular system architecture exists, which admits a flexible Δ development approach for its major components.