Product Line Architecture Research Articles

Component documentation—a key issue in software product lines

Product lines embody a strategic reuse of both intellectual effort and existing artefacts, such as software architectures and components. Third-party components are increasingly being used in product line based software engineering, in which case the integration is controlled by the product line architecture. However, the software integrators have difficulties in finding out the capabilities of components, because components are not documented in a standard way. Documentation is often the only way of assessing the applicability, credibility and quality of a third-party component. Our contribution is a standard documentation pattern for software components. The pattern provides guidelines and structure for component documentation and ensures the quality of documentation. The pattern has been validated by applying and analysing it in practice.

Towards Testing Product Line Architectures

A product line architecture is a single specification capturing the overall architecture of a series of closely related products. Its structure consists of a set of mandatory elements and a set of variation points. Whereas mandatory elements are part of the architecture of every product in the product line architecture, variation points precisely define the dimensions along which the architectures of individual products differ from each other.The increased use of product line architectures in today's software development projects poses several challenges for existing testing techniques. In this paper we discuss those challenges and discuss what we believe are opportunities for addressing them.

6.7.3 The Raytheon Enterprise Architecture Process (REAP)

AbstractArchitecture processes have become an essential component in the construction of complex systems and in the government's evaluation of defense contractors. The Raytheon Enterprise Architecture Process (REAP) is a systems architecting process being developed by Raytheon Company to address both the needs of our customers and of Raytheon as a system integrator. This process integrates established industry and government standards including: Zachman Framework for Enterprise Architecture, C4ISR/Department of Defense Architecture Framework, Software Engineering Institute's Architecture Tradeoff Analysis Method, Unified Modeling Language, and Colored Petri Nets. The REAP initiative is being approached as a “one‐company” standardized methodology to address architecture definition, description, evolution, and assessment throughout Raytheon. The REAP facilitates higher interoperability for our customers' systems, enables the sharing of architectural best practices through common taxonomy and representation, and supports the creation of product line architecture templates to provide established architecture baselines for the design of new systems.

Analysis of a software product line architecture: an experience report

This paper describes experiences with the architectural specification and tool-assisted architectural analysis of a mission-critical, high-performance software product line. The approach used defines a “good” product line architecture in terms of those quality attributes required by the particular product line under development. Architectures are analyzed against several criteria by both manual and tool-supported methods. The approach described in this paper provides a structured analysis of an existing product line architecture using (1) architecture recovery and specification, (2) architecture evaluation, and (3) model checking of behavior to determine the level of robustness and fault tolerance at the architectural level that are required for all systems in the product line. Results of an application to a software product line of spaceborne telescopes are used to explain the approach and describe lessons learned.

Verifying cross-cutting features as open systems

Feature-oriented software designs capture many interesting notions of cross-cutting, and offer a powerful method for building product-line architectures. Each cross-cutting feature is an independent module that fundamentally yields an open system from a verification perspective. We describe desiderata for verifying such modules through model checking and find that existing work on the verification of open systems fails to address most of the concerns that arise from feature-oriented systems. We therefore provide a new methodology for verifying such systems. To validate this new methodology, we have implemented it and applied it to a suite of modules that exhibit feature interaction problems. Our model checker was able to automatically locate ten problems previously found through a laborious simulation-based effort.

A software architecture for structuring complex web applications

In this paper we present an architecture for building families of rich Web applications. We first characterize current trends in Web applications, from read-only Web sites to sophisticated applications where complex distributed transactions must be supported. We next some design principles for building Web applications, and give the rationale for separating application behavior from navigation and interface issues. We briefly argue the need for developing a product line architecture for simplifying the systematic construction of different families of applications. We next describe the main components of our architecture explaining how we manage to decouple application specific aspects from technological aspects (such as dynamic page generation and persistence) that can be eventually solved by reusing of-the-shelf components. We show how to build application frameworks using this architecture using a concrete example of an electronic CD store.

Product line software engineering of embedded systems

In order to be able to determine whether the product line approach is suitable, a company needs to analyse its business drivers, commonality of existing products, domain knowledge owned by the engineering staff, and quality of the representations of existing software artefacts. In this paper we present evaluation criteria for the development of a product line and give an overview of the current state of practices in the embedded software area. Evaluation criteria are divided into three classes. Business drivers of a product line are defined by analysing product assortment and business manners. Domains and personnel are considered in the analysis of the preconditions and targets of a product line. In the development of core assets, elements that affect assets engineering are considered as well as the mechanisms needed in their maintenance. A product line architecture that brings about a balance between sub- domains and their most important properties is an investment that must be looked after. However, the subdomains need flexibility to use, change and manage their own technologies, and evolve separately, but in a controlled way.

Software product lines: a case study

A software product line is a family of products that share common features to meet the needs of a market area. Systematic processes have been developed to dramatically reduce the cost of a product line. Such product-line engineering processes have proven practical and effective in industrial use, but are not widely understood. The Family-Oriented Abstraction, Specification and Translation (FAST) process has been used successfully at Lucent Technologies in over 25 domains, providing productivity improvements of as much as four to one. In this paper, we show how to use FAST to document precisely the key abstractions in a domain, exploit design patterns in a generic product-line architecture, generate documentation and Java code, and automate testing to reduce costs. The paper is based on a detailed case study covering all aspects from domain analysis through testing. Copyright © 2000 John Wiley & Sons, Ltd.

Evolution in software product lines: two cases

This paper discuss the results of two case studies from a technical perspective, concentrating on the evolution of software assets in two Swedish organizations that have employed a product-line architecture approach for several years. This paper describes and analyses the commonalities and differences of these two cases, emphasising categories of the evolution of the requirements, of the software architecture and of the software components. This paper concludes with three types of lessons learned about evolution in software product lines: three evolution categories are predominant, three other categories are less significant but still common, and seven guidelines for software product-line evolution emerge. Copyright (C) 1999 John Wiley & Sons, Ltd.

Transitioning legacy assets to a product line architecture

A successful software system evolves over time, but this evolution often occurs in an ad-hoc fashion. One approach to structure system evolution is the concept of software product lines where a core architecture supports a variety of application contexts. However, in practice, the high cost and high risks of redevelopment as well as the substantial investments made to develop the existing systems most often mandate significant leverage of the legacy assets. Yet, there is little guidance in the literature on how to transition legacy assets into a product line set-up. In this paper, we present RE-PLACE, an approach developed to support the transition of existing software assets towards a product line architecture while taking into account anticipated new system variants. We illustrate this approach with its application in an industrial setting.

Supporting reuse with object technology

Is there a way to develop software that is of higher quality and yet takes less time and effort to produce? Many software developers believe there is, through reusing high-quality, tested software already developed. Unfortunately, software reuse has proven difficult to achieve. Organizations attempting to implement a software reuse program face both technical and nontechnical problems. What do software developers have to do to successfully implement reuse? In 1995, George Mason University undertook a study to investigate the relationships between software reuse investment and capability, productivity, and quality, as well as many of the theories proposed by the literature. The study found that a product-line and software architecture approach are higher predictors of decreased effort and increased quality than software reuse alone. On the other hand, it found no relationship between software reuse capability and the library approach.

Applying software product-line architecture

Many organizations today are investing in software product-line architecture-for good reason: a well-executed architecture enables organizations to respond quickly to a redefined mission or to new and changing markets. It allows them to accelerate the introduction of new products and improve their quality, to reengineer legacy systems, and to manage and enhance the many product variations needed for international markets. However, technically excellent product line architectures do fail, often because they are not effectively used. Some are developed but never used; others lose value as product teams stop sharing the common architecture; still others achieve initial success, but fail to keep up with a rapidly growing product mix. Sometimes the architecture deterioration is not noticed at first, masked by what appears to be a productivity increase. To learn what factors determine the effective use of software architecture, the authors looked at Nortel (Northern Telecom), a company with nearly 20 years of experience developing complex software architecture for telecommunications product families. They identified six principles that help reduce the complexity of an evolving family of products and that support and maintain the effective use and integrity of the architecture.