This paper briefly reports on the ERW'97 (European Reuse Workshop '97) by providing an overview of its sessions. The session regarding the adoption of reuse practices across a large organisation is presented in more depth. In this session, experiences and lessons learned in the ROADS project (Reuse Oriented Approach for Domain based Software) were presented and discussed. The ROADS project consisted of the realisation of four pilot experiments of reuse adoption in four different Business Units at Thomson-CSF and put domain architecture issues in the context of the overall reuse processes.
This paper addresses the issues with respect to product definition and product development, for an organization where several business-lines with their own bottom-line responsibility want to use a product-family approach.
This session was presented on a number of examples on architecting product families. Based on these examples the panellist discussed: related to product families.
Product families are united by common abstractions. When common abstractions can be directly translated into common implementation design elements and software components, reengineering and reuse are facilitated. But direct translation is often limited, however, by exigencies of performance, packaging, and product evolution. The result is an introduction of code-level sacrifices in commonality in which abstraction boundaries are reconfigured, inter-component communication patterns are tangled, and components are specialized and tailored. The consequences of these code-level sacrifices in commonality can be significant, since work is shifted from leveraged common design elements to a diversity of product-specific realizations. While this diversity may offer specific advantages in performance or packaging, it also can negate the potential leverage of reengineering and reuse at the product-line level.
The main issues identified in the area and which were selected for discussion are listed below:
Architecture recovery is concerned with deriving high-level architectural information from the information available about a system. The available information usually consists of the source code of the system, various documents, and possibly domain and application experts. Most architecture recovery efforts aim to use automatic tools as much as possible. In many cases the goal of architecture recovery is to produce the architecture of one or more existing, successful, systems in order to use it as the basis for developing a family architecture for a product family.
Software system has to face many changes during its life cycle. Some of these changes can be anticipated some come as surprises. Software systems can be designed to be flexible in terms of anticipated changes. Flexibility is achieved by structuring the system utilizing abstraction, indirection, late binding or some other variance mechanism. Surprising changes are still a problem. Partially this problem can be alleviated by proper management of design knowledge. We propose a mechanism to organize design decision so that this organization can be used to analyze change requests and determine their impact on system architecture. We demonstrate this using an industrial example.
State transition mechanisms are widely used in software engineering to implement state/event-dependent behavior. In C/C++, the implementation of state machines using ‘switch/case’ or ‘if’ statements causes problems in readability, understandability, maintainability, and modification. We have developed both a source code pattern searching tool capable of searching for state machine occurrences and a design pattern to replace state machines with C++ generic components. With ‘ESPaRT’ (Enhanced String Pattern Recognition Tool) we search for state machines in the source code. Examples of patterns for state machine detection are given in the paper. The state machine information is extracted and the state machine code is replaced by generic components following the “generic Harel State Machine Engine” (HSME) design pattern.
A critical distinguishing characteristic of architectures for families of embedded systems is their relative need for error-detection and -management. This need can range from extreme, as occurs with nearly all life-rated systems, to nominal, such as might occur with simple, inexpensive toys. Increasing a system’s capability for error detection and management invariably results in increased complexity and an increased load on system resources. Consequently, even systems with extremely high error management capability sometimes demonstrate anomalous behavior. When this occurs, it is typically necessary to rapidly and effectively identify the source of the anomaly. Therefore, a key consideration when developing an architecture for a family of embedded systems is determining the scope and nature of the diagnostic requirements that will be placed on the architecture. This paper discusses the value of diagnostic architectures, the construction of diagnostic architectures, and techniques for determining where diagnostic elements should be placed within an architecture. The paper also examines several specific diagnostic techniques and discusses tradeoffs between detail, data persistence, system performance, and system resources.
Software for large embedded systems (e.g. control systems for locomotives or large industrial drives) consumes a steadily increasing proportion of the engineering costs for development and maintenance. For this reason our goal is to share the effort by developing software that fits for several related products or product families. Not only the implementation, but also the software architecture and design shall be reused in similar applications. Replacing a hardware component or adding a customer desired feature in an application shall result in very limited changes in the control system software. As a solution for this common situation this paper defines a layered software architecture, which is designed for maximum reuse on different levels. The paper illustrates the internals of the common software layer, describes how it is used to build variants for different drive topologies, and how the lower layers were designed for fast application building.
The realization of software projects can be significantly eased by extending the focus of reuse to architectural aspects instead of concentrating on separate software elements. Yet in any case, operational techniques are required to support the retrieval and selection of reusable items. To this end, we extend on the concept of design spaces which allows to describe the relevant properties of software elements in a semi-formal way. Moreover, we show how the concept of extended design spaces can be deployed in tools supporting component-and framework-based software development.
ABB Power Generation's family of gas turbines covers the power range of 35 to 270 MW with five basic turbine types, which vary in size, combustion technology and equipment. Each type comes in several variatons, which in turn can be customized by adding or removing options or by following customer requirements not covered by standard options. This situation imposes high flexibility requirements on the turbine control system software. The scheme presented in this paper was developed to meet these requirements and ease turbine control engineering. It is based on the ideas of object oriented programming, which has been known to be very well suited for this kind of problems in conventional software engineering for quite some time. The architecture which results from this approach not only eases reuse of standard solutions throughout the whole turbine family, the design guidelines based on the object oriented principles also improve stability of the designed code. The concepts presented are currently being implemented for the ABB reference plant product family control system.
The whole idea of product families is building shared assets that can be leveraged to develop members of the product family. This has led product family developers to focus on three classes of shared assets because they knew how to leverage assets of those classes. These classes are reference architectures, reusable components, and component generators. Reference architectures define the span of a product family by providing a framework for obtaining the members through instantiation. The leverage gained from this class arises from shared structure, interaction protocols, services, interfaces, and components. Reusable components are generalized versions of components that can be specialized for particular family members through configuration and/or run-time parameters. The leverage gained from this class arises from avoiding the time and cost of rebuilding those components for each family member and from using more mature, higher quality, and better tested components. The structure, protocol, interface, and service restrictions specified in the reference architecture make it feasible to define the range that the components of that architecture must span. It can then be determined whether this space can be spanned through configuration and run-time parameterization. If so, prebuilt reusable components are the appropriate shared asset class. If not, generators must be employed to custom build each family member from specifications. The leverage gained from this third class is the same as the reusable component class, only the means of obtaining this shared asset is different.
Formal and informal methods for describing software architectures traditionally focus on a system's components and the interfaces between these components. They assume a design process in which the architect basically defines the architecture of a single product. If variants of this product are required, they are either handled implicitly or are defined at a later stage. Since industrial development processes which result in families of products are becoming increasingly common, there is a need for architectural models and notations in which diversity is modelled as an explicit and integral part of the architecture definition process. We believe that the use of such models can promote the overall optimisation of product families and can facilitate validation of architectural decisions. This paper presents a model which can be used to describe and manage architectures in a number of product family-oriented design processes.
Industrial software development is often an evolutionary process. Software products are developed for one specific customer and later on refined for other customers with different requirements in terms of a product family. Refinements happen at the implementation level (algorithms and data structures) and on the architectural level (the overall system structure). Recovery of architectural information is necessary to build up a complete and unambiguous description of the architecture of a system. In this paper, we describe an approach for the recovery of architectural structure that focuses on component and connector identification. We describe different strategies to define components and connectors of the system. The examples given in the paper were developed out of an industrial case study, a real-time Train Control System. The recovered architectural description allows reasoning about the quality of the system architecture: The description of the architectural structure revealed hardware-dependent components that in case of a hardware change would have to be changed completely. Therefore, our investigations showed that such a recovery of architectural structure is important to reduce future efforts in the development and maintenance of product lines.
This paper addresses how domain analysis served to help create reusable architectures and components in the development of a real-time embedded system. The resulting product is Motorola’s FLEX™ Kernel, a set of components to support development of portable wireless communication devices. The paper discusses this experience in terms of discovering and developing reusable frameworks for this domain. Our approach to incorporating tailorability into these components is described and compared with a recently published approach.
Distributed programming environments commonly restrict programmers to one form of intercomponent interaction. This forces programmers to emulate other interaction styles in terms of the dominant paradigm, obscuring their intent and resulting in a loss of clarity. Starting from a clear model of interaction between program components, this paper attempts to restore this missing clarity of intent. It achieves this by proposing a language tailored to the description of new and existing interaction styles that separates the specification of intercomponent interaction from the programming interface visible internally to the component.
We introduce a component model with an architectural description language that helps to manage the growing complexity and diversity of software in consumer electronics products. The model supports flexible instantiation and late binding of components at an absolute minimum of product costs (code size and speed). The model is being used in the production of the next generation of mid to high-end television sets.
This paper identifies the requirements placed on software system family architectures by the various stakeholders involved in software-system family development. The requirements are uncovered by analysing the roles of the various stakeholders in software-system family development. The stakeholders will have certain roles which pertain to the individual project/product and which are typical of all development paradigms. However, those in product family development will also have roles arising out of the fact that a family is being developed. An important task of the software-system family architecture is to support these family-related roles. The paper has a practical orientation, and concentrates on reporting research results. Further the paper provides an example of how the stakeholders and their roles may be allocated in a “real” organisation.
