Variability in Software Product Lines

Product line engineering is a widely used approach for the efficient development of whole portfolios of software products. The basis of the approach is that products are built from a core asset base, a collection of artifacts that have been designed specifically for use across the portfolio. To account for differences among the software products, some adaptations of the core assets are usually required. These adaptations should be planned before development and made easy for the product developers to use without jeopardizing existing properties of the core assets. In a product line with a large number of products and core assets, as well as requirements to make fine-grained adjustments, managing variability can become problematic very quickly. Mismanagement may result in adding unnecessary variability, implementing variation mechanisms more than once, selecting incompatible or awkward variation mechanisms, and missing required variations. As the product line grows and evolves, the need for variability increases, and managing the variability grows increasingly difficult. This report describes the concepts needed when creating core assets with included variability. These concepts provide guidelines to core asset creators on how to model the variability explicitly, so it is handled consistently throughout the product line and managing the variability becomes feasible

Experience Using the Web-Based Tool Wiki for Architecture Documentation

In an organization that uses an architecture-centric development approach, it is the purpose of the software architecture, especially the product documentation, to guide all stakeholders who contribute in one way or another to the development of the product(s). Unfortunately, in many organizations, this documentation ends up on the shelves, unused and collecting dust. This happens in part because it is difficult to keep the architecture documentation current, hard for nondevelopers to understand what the documents describe, and challenging for nondevelopers to use the tools necessary to access the documentation. This technical note discusses the benefits and challenges of using a wiki-based collaborative environment to create software architecture documentation. The findings are based on two experiences. The first was that of a team of Carnegie Mellon University Master of Software Engineering (MSE) program students that used the wiki tool in a real-world software project. For its customer, the team had to produce and document the architecture of a system that will be developed by many geographically distributed teams. The second experience was a study conducted by another MSE student to reconstruct and document the architecture of a multitier enterprise application using the wiki tool and UML 2.0

Modifiability Tactics

An architectural tactic is a design decision that affects how well a software architecture addresses a particular quality attribute. This report describes how tactics are based on the parameters of quality attribute models. Tactics provide an architectural means of adjusting those parameters, which, in turn, can improve the quality-attribute-specific behavior of the resulting system. This report justifies the tactics for modifiability, using established concepts of coupling, cohesion, and cost motivations as the means of identifying parameters of interest. Various tactics are then described based on their ability to control these parameters. The report also describes a standard set of architectural patterns and their variants in terms of the use of these tactics

Illuminating the Fundamental Contributors to Software Architecture Quality

An architectural tactic is a design decision that helps achieve a specific quality-attribute response. Such a tactic must be motivated by a quality-attribute analysis model. This report presents the basic concepts of analysis models for two quality attributes-modifiability and performance, identifies a collection of tactics that can be used to control responses within those models, and discusses how to analyze the models in terms of these tactics. This report also describes how to interpret architectural designs in terms of analysis models and how to apply those models to specific architectures. In addition, it presents the analysis of several different architectural patterns taken from current literature

Deriving Architectural Tactics: A Step Toward Methodical Architectural Design

This is one of several reports that provide the current status on the work being done by the Software Engineering Institute (SEI) to understand the relationship between quality requirements and architectural design. The ultimate objective of this work is to provide analysis-based guidance to designers so that the quality attributes of generated designs are more predictable and better understood. Currently, four distinct problems must be solved to achieve that objective: (1) the precise specification of quality attribute requirements, (2) the enumeration of architectural decisions that can be used to achieve desired quality attribute requirements, (3) a means of coupling one quality attribute requirement to the relevant architectural decisions, and (4) a means of composing the relevant architectural decisions into a design. Embodying the solutions to these four problems into a design method that is sensitive to business priorities is an additional problem. This report deals with the third problem—coupling one quality attribute requirement to architectural decisions that achieve it. This report provides initial evidence that there is, in fact, a systematic relationship between general scenarios, concrete scenarios, architectural tactics, and design fragments. It examines, in detail, two concrete scenarios—one for performance and one for modifiability—and describes how to move from each scenario, through tactics, to design fragments that satisfy the scenario

Preliminary Design of ArchE: A Software Architecture Design Assistant

This report presents a procedure for moving from a set of quality attribute scenarios to an architecture design that satisfies those scenarios. This procedure is embodied in a preliminary design for an architecture design assistant named ArchE (Architecture Expert), which will be implemented on a rule-based platform. This report includes the theory and rationale precipitating the design of ArchE and then describes this design in detail

Using ArchE in the Classroom: One Experience

The Architecture Expert (ArchE) tool serves as a software architecture design assistant. It embodies knowledge of quality attributes and the relation between the achievement of quality attribute requirements and architecture design. This technical note describes the use of a pre-alpha release of ArchE in a graduate-level software architecture class at Clemson University. ArchE was used to assist the students in the architecting process. The tool was then evaluated by the students and instructor. The instructor felt that ArchE met his objectives as a pedagogical tool. The students, although critical of the pre-alpha status of ArchE, were enthusiastic about the benefits of having the step-by-step guide to the architect's designing process as provided by ArchE

Attribute-Driven Design (ADD), Version 2.0

This report revises the Attribute-Driven Design (ADD) method that was developed by the Carnegie Mellon Software Engineering Institute. The motivation for revising ADD came from practitioners who use the method and want ADD to be easier to learn, understand, and apply. The ADD method is an approach to defining a software architecture in which the design process is based on the software quality attribute requirements. ADD follows a recursive process that decomposes a system or system element by applying architectural tactics and patterns that satisfy its driving quality attribute requirements. This technical report revises the steps of ADD and offers practical guidelines for carrying out each step. In addition, important design decisions that should be considered at each step are provided

Documenting Software Architecture: Documenting Behavior

This report represents another milestone of a work in progress: a comprehensive handbook on how to produce high-quality documentation for software architectures. The handbook, tentatively titled Documenting Software Architectures, will be published in early 2002 by Addison-Wesley as part of the Software Engineering Institute (SEI) Series on Software Engineering. The book is intended to address a lack of language-independent guidance about how to capture an architecture in a written form that can provide a unified design vision to all of the stakeholders on a development project. A central precept of the book is that documenting an architecture entails two essential steps: (1) documenting the set of relevant views of that architecture, and then completing the picture by (2) documenting information that transcends any single view. The books audience is the community of practicing architects, apprentice architects, and developers who receive architectural documentation. This technical note describes ways to document an important but often overlooked aspect of software architecture: the behavior of systems, subsystems, and components

A Practical Method for Documenting Software Architectures

A practical approach for documenting software architectures is presented. The approach is based on the well-known architectural concept of views, and holds that documentation consists of documenting the relevant views and then documenting the information that applies to more than one view. Views can be usefully grouped into viewtypes, corresponding to the three broad ways an architect must think about a system: as a set of implementation units, as a set of runtime elements interacting to carry out the system’s work, and as a set of elements existing in and relating to external structures in its environment. A simple three-step procedure for choosing the relevant views to document is given, and applied to the problem of documentation for a large, complex NASA system