Jan Gerben Wijnstra

Supporting diversity with component frameworks as architectural elements

The author describes personal experience with component frameworks within a family architecture for a medical imaging product family. The component frameworks are handled as an integral part of the architectural approach and are an important means to support diversity in the functionality provided by the individual family members. The paper focuses on a particular kind of component framework that has been applied throughout the medical imaging product family. This kind of framework is useful when the various family members are based on the same concepts and the diversity is formed by the differences in the specific instances of these concepts that are present in the family members. These component frameworks have a number of similarities, allowing a standardised approach to their development. They support the division of the system into a generic architectural skeleton, which can be extended with plug-ins to realise specific family members, each with their own set of features.

Architecture Recovery for Product Families

Software product families are rarely created right away but they emerge when a domain becomes mature enough to sustain their long-term investments. The typical pattern is to start with a small set of products to quickly enter a new market. As soon as the business proves to be successful new investments are directed to consolidating the software assets. The various products are migrated towards a flexible platform where the assets are shared and new products can be derived from. In order to create and maintain the platform, the organization needs to carry out several activities such as recovering the architectures of single products and product families, designing the reference architecture, isolating the variable parts, and generalizing software components. In this paper, we introduce a product family construction process that exploits related systems and product families, and we describe methods and tools used. We also present an approach for classifying platforms according to platform coverage and variation and describe three techniques to handle variability across single products and whole product families.

Critical Factors for a Successful Platform-Based Product Family Approach

The notion of software product families is becoming more and more popular, both in research and in industry. In presentations of ideal applications, the benefits of product families are stressed and very little attention is paid to possible problems. However, in practice, it is important to know what such problems could be and how they could be dealt with. In this paper we want to identify some of the most critical issues, and explain how they can be handled or even avoided. This will be done on the basis of experiences gained with three industrial product families for professional markets. The focus will be on product families that use platforms with reusable assets for the development of the family members.

Platform Engineering for the Medical Domain

The various products of Philips Medical Systems are grouped in product families. This paper describes the development of a single platform for several of these families. This platform incorporates shared functionality and shared architecture. Important entities within the platform are components, interfaces and information models.

Components, Interfaces and Information Models within a Platform Architecture

In this paper we describe our experiences with the development of a platform in the medical imaging domain. Three important ingredients of this platform are components, interfaces and information models. We will explain the requirements for the platform, why these three ingredients have been chosen, and our experiences when using this approach.

Component replacement in a long-living architecture: the 3RDBA approach

In order to respond to changing requirements and advances in technology, system and software architectures must evolve during their lifetimes. Usually, in this evolution, several key components of the architecture are replaced. Achieving successful architecture evolution at a reasonable cost and effort is difficult. It requires many architectural and technological decisions. This paper describes an approach, called 3RDBA that facilitates replacing a key component in a long-living architecture. It is based on systematically gathering all information needed to make well-founded decisions regarding evolution of the architecture. The approach consists of an exploration, consolidation and migration cycle. Each cycle contains four steps: requirements, design, build and analyze. 3RDBA enables construction and evaluation of several alternative architecture realizations together with a migration path from the existing architecture towards the selected, new architecture. We describe how we have successfully applied this approach to support the evolution of a medical imaging system architecture.

From problem to solution with quality attributes and design aspects

It is commonly accepted that quality attributes shape the architecture of a system. There are several means via which the architecture can support certain quality attributes. For example, to deal with reliability the system can be decomposed into a number of fault containment units, thus avoiding fault propagation. In addition to structural issues of architecture, qualities also influence architectural rules and guidelines, such as coding standards. In this paper we will focus on design aspects as a means of supporting quality attributes. An example of a design aspect is error handling functionality, which supports reliability. Quality attributes play a role in the problem domain; design aspects are elements in the solution domain.We will use an industrial case to illustrate our ideas. The discussion ranges from how design aspects are defined in the architecture based on quality attributes, to how design aspects can be used to verify the realized system against the prescribed architecture. The industrial case is a product family of medical imaging systems. For this product family, the family members are constructed from a component-based platform. Here, it is especially useful to achieve aspect-completeness of components, allowing system composition without worrying about individual design aspects.

Evolving a Product Family in a Changing Context

The notion of software product families is becoming more and more popular, both in research and in industry. There is no single best product family approach that is suitable for all, since each product family has its unique context. Such a context comprises elements such as scope, organization, and business strategy. As these elements can change over time, the product family approach may have to evolve with them. In this paper we describe our ideas for a method to assess the variability approach of an existing product family, and to improve that approach to match the changing context. This is illustrated in a case study from the medical imaging domain. This product family in question started out with only a few family members, but over time, the growth in the number of different applications and new application domains have put higher variability demands on the family. These changes also require an evolution in the product family approach. We will describe the current product family approach and the changing requirements on this approach. We also performed a partially automated analysis of the variation to give us a good overview of the way variation is currently handled in the system. Based on that, a direction for evolving the product family approach is proposed.

Component Frameworks for a Medical Imaging Product Family

In this paper we describe our experience with component frameworks in a product family architecture in the medical imaging domain. The component frameworks are treated as an integral part of the architectural approach and proved to be an important means for modelling diversity in the functionality supported by the individual family members. This approach is based on the explicit modelling of the domain and the definition of a shared product family architecture. Two main types of component frameworks are described, along with the ways in which they are to be developed.

Component Oriented Platform Architecting for Software Intensive Product Families

Platform-based product families are strategic business assets. A product platform represents a corporate asset from which streams of derivative products of a large variety can be derived and developed (so-called product families). Platform based development promises to be very effective in decreasing development cost and lead times while at the same time increasing product quality and market diversity. Currently industry is in the process of adapting this approach. In the course of time, electronic products have become software intensive. Unfortunately, software engineering processes and technologies that have been developed until now were mainly concerned with the creation of one product at a time. They do not address well the need for development and maintenance of a product platform and its derivative products. In this chapter, it will be shown how component oriented product family architectures provide a promising development paradigm. This paradigm solves the inherent dilemma of the need for careful engineering versus rapid realisation of a large variety of product instances. The approach is illustrated using examples from the medical and the consumer domain.