Moving From One System to Many

focuses on the construction of multiple systems from that architecture, discussing, and
giving examples of system product lines. It does this from five perspectives: that of the
technology underlying a product line, that of a single company that built a product line of
naval vessel fire-control systems, that of an industry-wide architecture, that of a single
company producing products based on the industry-wide architecture, and that of an
organization building systems from commercial components.

Software Product Lines: Re-using

Architectural Assets

A software architecture represents a significant investment of time and effort, usually by

senior talent. So it is natural to want to maximize the return on this investment by re-using
an architecture across multiple systems. Architecturally mature organizations tend to treat
their architectures as valuable intellectual property and look for ways in which that property
can be leveraged to produce additional revenue and reduce costs. Both are possible with
architecture re-use.

Software product lines based on inter-product commonality represent an innovative,

growing concept in software engineering. Every customer has its own requirements, which
demand flexibility on the part of the manufacturers. Software product lines simplify the
creation of systems built specifically for particular customers or customer groups.

What Makes Software Product Lines Work?

The essence of a software product line is the disciplined, strategic re-use of assets in
producing a family of products. What makes product lines succeed so spectacularly from the
vendor or developer's point of view is that the commonalities shared by the products can be
exploited through re-use to achieve production economies. The potential for re-use is broad
and far-ranging, including:

• Requirements. Most of the requirements are common with those of earlier systems and
so can be re-used. Requirements analysis is saved.

• Architectural design. An architecture for a software system represents a large

investment of time from the organization's most talented engineers. As we have seen,
the quality goals for a system?performance, reliability, modifiability, and so forth?are
largely allowed or precluded once the architecture is in place. If the architecture is

www.jntumaterials.co.in
 wrong, the system cannot be saved. For a new product, however, this most important
design step is already done and need not be repeated.

• Elements. Software elements are applicable across individual products. Far and above
mere code re-use, element re-use includes the (often difficult) initial design work.
Design successes are captured and re-used; design dead ends are avoided, not
repeated. This includes design of the element's interface, its documentation, its test
plans and procedures, and any models (such as performance models) used to predict or
measure its behavior. One re-usable set of elements is the system's user interface,
which represents an enormous and vital set of design decisions.

• Modeling and analysis. Performance models, schedulability analysis, distributed system

issues (such as proving absence of deadlock), allocation of processes to processors, fault
tolerance schemes, and network load policies all carry over from product to product.
CelsiusTech (as discussed in Chapter 15) reports that one of the major headaches
associated with the real-time distributed systems it builds has all but vanished. When
fielding a new product in the product line, it has extremely high confidence that the
timing problems have been worked out and that the bugs associated with distributed
computing?synchronization, network loading, deadlock?have been eliminated.

• Testing. Test plans, test processes, test cases, test data, test harnesses, and the
communication paths required to report and fix problems are already in place.

• Project planning. Budgeting and scheduling are more predictable because experience is
a high-fidelity indicator of future performance. Work breakdown structures need not be
invented each time. Teams, team size, and team composition are all easily determined.

• Processes, methods, and tools. Configuration control procedures and facilities,

documentation plans and approval processes, tool environments, system generation and
distribution procedures, coding standards, and many other day-to-day engineering
support activities can all be carried over from product to product. The overall software
development process is in place and has been used before.

• People. Because of the commonality of applications, personnel can be fluidly transferred

among projects as required. Their expertise is applicable across the entire line.

• Exemplar systems. Deployed products serve as high-quality demonstration prototypes

as well as high-quality engineering models of performance, security, safety, and
reliability.

www.jntumaterials.co.in
• Defect elimination. Product lines enhance quality because each new system takes
advantage of the defect elimination in its forebears. Developer and customer confidence
both rise with each new instantiation. The more complicated the system, the higher the
payoff for solving vexing performance, distribution, reliability, and other engineering
issues once for the entire family.

Scoping
The scope of a product line defines what systems are in it, and what systems are out. Put
less bluntly, a product line's scope is a statement about what systems an organization is
willing to build as part of its line and what systems it is not willing to build. Defining a
product line's scope is like drawing a doughnut in the space of all possible systems, as
shown in Figure 14.1. The doughnut's center represents the systems that the organization
could build, would build, because they fall within its product line capability. Systems outside
the doughnut are out of scope, ones that the product line is not well equipped to handle.
Systems on the doughnut itself could be handled, but with some effort, and require case-
by-case disposition as they arise. To illustrate, in a product line of office automation
systems a conference room scheduler would be in; a flight simulator would be out. A
specialized intranet search engine might be in if it could be produced in a reasonable time
and if there were strategic reasons for doing so (such as the likelihood that future
customers would want a similar product).

Figure 14.1. The space of all possible systems is divided into areas within scope
(white), areas outside of scope (speckled), and areas that require case-by-case
disposition (black).

Adapted from [Clements 02b].

The scope represents the organization's best prediction about what products it will be asked
to build in the foreseeable future. Input to the scoping process comes from the
organization's strategic planners, marketing staff, domain analysts who can catalog similar
systems (both existing and on the drawing board), and technology experts.

www.jntumaterials.co.in
Architectures for Product Lines
Of all of the assets in a core asset repository, the software architecture plays the most
central role. The essence of building a successful software product line is discriminating
between what is expected to remain constant across all family members and what is
expected to vary. Software architecture is ready-made for handling this duality, since all
architectures are abstractions that admit a plurality of instances; a great source of their
conceptual value is, after all, that they allow us to concentrate on design essentials within a
number of different implementations. By its very nature an architecture is a statement
about what we expect to remain constant and what we admit may vary. In a software
product line, the architecture is an expression of the nonvarying aspects.

But a product line architecture goes beyond this simple dichotomy, concerning itself with a
set of explicitly allowed variations, whereas with a conventional architecture almost any
instance will do as long as the (single) system's behavioral and quality goals are met. Thus,
identifying the allowable variations is part of the architecture's responsibility, as is providing
built-in mechanisms for achieving them. Those variations may be substantial. Products in a
software product line exist simultaneously and may vary in terms of their behavior, quality
attributes, platform, network, physical configuration, middleware, scale factors, and so
forth.

A product line architect needs to consider three things:

• Identifying variation points

• Supporting variation points

• Evaluating the architecture for product line suitability

What Makes Software Product Lines Difficult?

It takes a certain maturity in the developing organization to successfully field a product line.
Technology is not the only barrier to this; organization, process, and business issues are
equally vital to master to fully reap the benefits of the software product line approach.

The Software Engineering Institute has identified twenty-nine issues or "practice areas" that
affect an organization's success in fielding a software product line. Most of these practice
areas are applied during single-system development as well, but take on a new dimension
in a product line context. Two examples are architecture definition and configuration
management.

www.jntumaterials.co.in
ADOPTION STRATEGIES

CREATING PRODUCTS AND EVOLVING A PRODUCT LINE

External sources

Internal sources

ORGANIZATIONAL STRUCTURE
Development department

Business units.

Domain engineering unit

Hierarchical domain engineering units

Building Systems from Off-the-Shelf

Components
Operating systems impose certain solutions and have since the 1960s. Database
management systems have been around since the early 1970s. Because of the ubiquity of
computers the possibility of using externally developed components to achieve some system
goals has been increasing dramatically. Even the availability of components may not cause
you to use or keep them (see the sidebar Quack.com), but you certainly need to understand
how to incorporate them into your system.

For systems built from off-the-shelf (OTS) components, component selection involves a
discovery process, which seeks to identify assemblies of compatible components,
understanding how they can achieve the desired quality attributes, and deciding whether
they can be integrated into the system being built.

Impact of Components on Architecture

Consider the following situation. You are producing software to control a chemical plant.
Within chemical plants, specialized displays keep the operator informed as to the state of
the reactions being controlled. A large portion of the software you are constructing is used
to draw those displays. A vendor sells user interface controls that produce them. Because it
is easier to buy than build, you decide to purchase the controls?which, by the way, are only
available for Visual Basic.

www.jntumaterials.co.in
What impact does this decision have on your architecture? Either the whole system must be
written in Visual Basic with its built-in callback-centered style or the operator portion must
be isolated from the rest of the system in some fashion. This is a fundamental structural
decision, driven by the choice of a single component for a single portion of the system.

The use of off-the-shelf components in software development, while essential in many

cases, also introduces new challenges. In particular, component capabilities and liabilities
are a principle architectural constraint.

Architectural Mismatch
Architectural mismatch is a special case of interface mismatch, where the interface is as
Parnas defined it: the assumptions that components can make about each other. This
definition goes beyond what has, unfortunately, become the standard concept of interface in
current practice: a component's API (for example, a Java interface specification). An API
names the programs and their parameters and may say something about their behavior, but
this is only a small part of the information needed to correctly use a component. Side
effects, consumption of global resources, coordination requirements, and the like, are a
necessary part of an interface and are included in a complete interface specification.
Interface mismatch can appear at integration time, just like architectural mismatch, but it
can also precipitate the insidious runtime errors mentioned before.

These assumptions can take two forms. Provides assumptions describe the services a
component provides to

its users or clients. Requires assumptions detail the services or resources that a component
must have in order to correctly function. Mismatch between two components occurs when
their provides and requires assumptions do not match up.

What can you do about interface mismatch? Besides changing your requirements so that
yesterday's bug is today's feature (which is often a viable option), there are three things:

• Avoid it by carefully specifying and inspecting the components for your system.

• Detect those cases you have not avoided by careful qualification of the components.

• Repair those cases you have detected by adapting the components.

The rest of this section will deal with techniques for avoiding, detecting, and repairing
mismatch. We begin with repair.

www.jntumaterials.co.in
TECHNIQUES FOR REPAIRING INTERFACE MISMATCH
To date, mismatch correction (or "component/interface repair") has received little
systematic attention. Terms such as "component glue" are evocative of the character of the
integration code and reflect the second-class status we assign to its development. Often
repairing interface mismatches is seen as a job for hackers (or sometimes junior
programmers) whose sense of aesthetics is not offended by the myriad "hacks" involved in
integrating off-the-shelf components. However, as is often the case, the weak link in a chain
defines the chain's strength. Thus, the quality of component repair may be directly
responsible for achieving?or failing to achieve?system-wide quality attributes such as
availability and modifiability.

TECHNIQUES FOR DETECTING INTERFACE MISMATCH

In order to repair mismatches, we must first detect or identify them. We present the
process of identifying mismatches as an enhanced form of component qualification.

The term component qualification has been used to describe the process of determining
whether a commercial component satisfies various "fitness for use" criteria. Some
component qualification processes include prototype integration of candidate components as
an essential step in qualifying a component. This integration step discovers subtle forms of
interface mismatch that are difficult to detect, such as resource contention. The need for
this step is a tacit acknowledgment of our poor understanding of component interfaces.

TECHNIQUES FOR AVOIDING INTERFACE MISMATCH

One technique for avoiding interface mismatch is to undertake, from the earliest phases of
design, a disciplined approach to specifying as many assumptions about a component's
interface as feasible. Is it feasible or even possible to specify all of the assumptions a
component makes about its environment, or that the components used are allowed to make
about it? Of course not. Is there any evidence that it is practical to specify an important
subset of assumptions, and that it pays to do so? Yes. The A-7E software design presented
in Chapter 3 partitioned the system into a hierarchical tree of modules, with three modules
at the highest level, decomposed into about 120 modules at the leaves. An interface
specification was written for each leaf module that included the access programs (what
would now be called methods in an object-based design), the parameters they required and
returned, the visible effects of calling the program, the system generation parameters that
allowed compile-time tailoring of the module, and a set of assumptions (about a dozen for
each module).

www.jntumaterials.co.in
Component-Based Design as Search
Since component capabilities and liabilities are a principle source of architectural constraint
in system development, and since systems use multiple components, component-based
system design becomes a search for compatible ensembles of off-the-shelf components that
come the closest to meeting system objectives. The architect must determine if it is feasible
to integrate the components in each ensemble and, in particular, to evaluate whether an
ensemble can live in the architecture and support system requirements.

In effect, each possible ensemble amounts to a continued path of exploration. This

exploration should initially focus on the feasibility of the path to make sure there are no
significant architectural mismatches that cannot be reasonably adapted. It must also take
into account the feasibility of the repair and the residual risk remaining once the repair is
completed.

An illustration of the model problem work flow is shown in Figure 18.1. The process consists
of the following six steps that can be executed in sequence:

1. The architect and the engineers identify a design question. The design question initiates
the model problem, referring to an unknown that is expressed as a hypothesis.

2. The architect and the engineers define the starting evaluation criteria. These criteria
describe how the model solution will support or contradict the hypothesis.

3. The architect and the engineers define the implementation constraints. The
implementation constraints specify the fixed (inflexible) part of the design context that
governs the implementation of the model solution. These constraints might include such
things as platform requirements, component versions, and business rules.

4. The engineers produce a model solution situated in the design context. The model
solution is a minimal application that uses only the features of a component (or
components) necessary to support or contradict the hypothesis.

5. The engineers identify ending evaluation criteria. Ending evaluation criteria include the
starting set plus criteria that are discovered as a by-product of implementing the model
solution.

6. The architect performs an evaluation of the model solution against the ending criteria.
The evaluation may result in the design solution being rejected or adopted, but often
leads to new design questions that must be resolved in similar fashion.

www.jntumaterials.co.in
 Figure 18.1. Model problem work flow

ASEILM Example
Our example centers around a Web-based information system developed at the Software
Engineering Institute (SEI) for automating administrative interactions between SEI and its
transition partners. The Automated SEI Licensee Management (ASEILM) system was created
with the following objectives:

• To support the distribution of SEI-licensed materials, such as courses and assessment

kits, to authorized individuals

www.jntumaterials.co.in
• To collect administrative information for assessments

• To graphically present revenue, attendance, and other information about SEI licensed
materials

• To track course attendance and royalties due to SEI

ASEILM must support the following multiple user types, each with varying authorization to
perform system functions:

• Course instructors can input course attendee lists, maintain contact information, and
download course materials.

• Lead assessors can set up assessments, input assessment information, and download
assessment kits.

• SEI administrators can maintain lists of authorized instructors and lead assessors, as
well as view or edit any information maintained by the system.

Quality
Requirement
Attribute

Functionality Provide Web-based access to a geographically dispersed customer base

Performance Provide adequate performance to users running overseas on low-

bandwidth connections (i.e., download times in tens of minutes, not hours)

Compatibility Support older versions of Web browsers including Netscape 3.0 and
Internet Explorer 3.0

Security Support multiple classes of users and provide an identification and

authorization scheme to allow users to identify themselves

Security Provide commercial-grade secure transfer of data over the Internet

www.jntumaterials.co.in
Software Architecture in the Future
The history of programming can be viewed as a succession of ever-increasing facilities for
expressing complex functionality. In the beginning, assembly language offered the most
elementary of abstractions: exactly where in physical memory things resided (relative to the
address in some base register) and the machine code necessary to perform primitive
arithmetic and move operations. Even in this primitive environment programs exhibited
architectures: Elements were blocks of code connected by physical proximity to one another
or knitted together by branching statements or perhaps subroutines whose connectors were
of branch-and-return construction. Early programming languages institutionalized these
constructs with connectors being the semicolon, the goto statement, and the parameterized
function call. The 1960s was the decade of the subroutine.

Growth in the types of abstraction available over time

The Architecture Business Cycle Revisited

In this context, we can now identify and discuss four different versions of the ABC that
appear to have particular promise in terms of future research:

• The simplest case, in which a single organization creates a single architecture for a
single system

• One in which a business creates not just a single system from an architecture but an
entire product line of systems that are related by a common architecture and a common
asset base

• One in which, through a community-wide effort, a standard architecture or reference

architecture is created from which large numbers of systems flow

www.jntumaterials.co.in
• One in which the architecture becomes so pervasive that the developing organization
effectively becomes the world, as in the case of the World Wide Web

Creating an Architecture
we emphasized the quality requirements for the system being built, the tactics used by the
architect, and how these tactics were manifested in the architecture. Yet this process of
moving from quality requirements to architectural designs remains an area where much
fruitful research can be done. The design process remains an art, and introducing more
science into the process will yield large results.

Answers to the following questions will improve the design process:

• Are the lists of quality attribute scenarios and tactics complete?

• How are scenarios and tactics coupled?

• How can the results of applying a tactic be predicted?

• How are tactics combined into patterns?

• What kind of tool support can assist in the design process?

• Can tactics be "woven" into systems?

Architecture within the Life Cycle

Although we have argued that architecture is the central artifact within the life cycle, the
fact remains that a life cycle for a particular system comprises far more than architecture
development. We see several areas ripe for research about architecture within the life cycle:

• Documentation within a tool environment

• Software architecture within configuration management systems.

• Moving from architecture to code.

The Impact of Commercial Components

the capabilities and availability of commercial components are growing rapidly. So too are
the availability of domain-specific architectures and the frameworks to support them,
including the J2EE for information technology architectures. The day is coming when
domain-specific architectures and frameworks will be available for many of today's common

www.jntumaterials.co.in
domains. As a result, architects will be concerned as much with constraints caused by the
chosen framework as by green-field design.

Not even the availability of components with extensive functionality will free the architect
from the problems of design, however. The first thing the architect must do is determine the
properties of the used components. Components reflect architectural assumptions, and it
becomes the job of the architect to identify them and assess their impact on the system
being designed. This requires either a rich collection of attribute models or extensive
laboratory work, or both. Consumers of components will want a trusted validation agency,
such as Underwriters Laboratories, to stand behind the predictions.

Determination of the quality characteristics of components and the associated framework is

important for design using externally constructed components. We discussed a number of
options with J2EE/EJB in Chapter 16 and the performance impact of each. How will the
architect know the effect of options that the framework provides, and, even more difficult,
the qualities achieved when the architect has no options? We need a method of
enumerating the architectural assumptions of components and understanding the
consequences of a particular choice.

Finally, components and their associated frameworks must be produced and the production
must be designed to achieve desired qualities. Their designers must consider an industry-
wide set of stakeholders rather than those for a single company. Furthermore, the quality
attribute requirements that come from the many stakeholders in an industry will likely vary
more widely than the requirements that come from the stakeholders of a single company.

www.jntumaterials.co.in