Software architecture
for product lines
Rodrigo Mendes
Schedule






Software Product Lines
Architecture for Product Lines
SLA Quality Tools
Nortel’s Study Case
Conclusion
References
2
Software
Product Lines (SPL)
3
Motivation


Based
on
approaches
like
Eli
Whitney
(interchangeable parts) and Henry Ford (interchange
parts and assembly line)
Standard Practice that proposes a proative reuse,
stimulating
interchangeable
components
to
construct high-quality products faster and cheaper.
4
[MCGREGOR et al]

Introduction of SPL in a organization
strategies:


has two
Heavyweight Strategy – e.g. Cumins Company.
Lightweight Strategy – e.g. Nokia Company.
A comparison of
heavyweight and
lightweight strategies
and single-system
development.
5
Keys of Success

A successful SPL practice are common in
three efforts:



Exploration of commonality among products;
Encouraging architecture centric development;
Two Tiered Organization Structure.
6
Exploring commonality and variability


“We consider a set of programs to constitute a
family whenever it is worthwhile to study programs
from the set by first studying the common
properties of the set and then determining the
special properties of the individual family members.”
[David Parnas]
SPL scope is specified such that the products have a
high degree of commonality.
7
Exploring commonality and variability

Variation points has two major dimensions:




Time Dimension
Space Dimension
In a heavyweight strategy, assets are acquired
before creating products.
In lightweight initiation schemes, assets are
acquired in time production.
8
Architecture centric development


Architecture is the major key to a SPL
strategy have success.
Creation of a design architecture for SPL
provides a set a range of values for each
quality attribute necessary to represent all
products.
9
Two Tiered Organization Structure

A organization using SPL practice facilitates two
fundamental roles:




Development of reusable assets
Development of products that uses those assets
In heavyweight approaches, there are a specific
team
to
produce
assets,
components
and
architecture.
In lightweight approaches, few products are created
and then mining efforts to extract common
assets.
10
Software Product Line
Architecture
11
Software Product Line Architecture (SPLA)

A product-line architecture is an abstraction: it is a
specification of the high level structures of a family
of applications. These structures reveal
complementary facets of an architecture (static
structure, dynamic structure, etc… ) and contain
elements like components, connections, data,
processes [Bass et al, 1998].
12
Architecture-Centric Evolution


In product lines, a key challenge is that a product
line approach requires different methods of
development.
In a product line approach, one must also consider
requirements for the family of systems, and the
relationship between those requirements and the
ones associated with each particular instance.
13
[Garlan D.]

There must be an
up-front (and ongoing) investment in
developing a
reusable architecture
that can be
instantiated for each
product.
Product Line Architectures
14
[Lalanda P.]

A product-line architecture has to meet three
fundamental requirements:



It has to drive the architectural design of new applications
in the product-line;
It has to facilitate the reuse of components at the productline level;
It has to permit various analyses in order to assess the
impact (cost, performance, etc… ) of specific requirements
for the development of new applications in the product-line.
15
[Lalanda P.]

A product-line architecture has to capture both
architectural commonalities and variabilities of a
family of applications. Commonalities and
variabilities may concern any element of an
architecture as components, topology, dynamics and
physical environment for example.
16
Designing a SPLA

In order to design a SPLA, commonalities e
variabilities must be expressed as follows:

Commonalities:




Standard software components and the way they are
connected
Standard execution modes
Standard execution threads
Standard mappings onto execution platforms
17
Designing a SPLA

Variabilities:


As indicated in [Perry, 1998], several techniques can be
used in order to encapsulate variability. The most
important techniques are: Under-specification,
Provisions and Decision points.
Can be expressed in three ways:



Encapsulating architectural elements that vary and to leave them
unspecified;
Making provisions;
Encapsulating architectural elements that vary and to specify a list
of possibilities or parameters.
18
Style Specific Techniques


A way to get more specific is to take into account architectural
styles and to express what should be done to build a productline architecture as a function of styles.
In order to achieve a more effective guidance, is necessary:



Identify in the business units the domains that could benefit from
a product-line approach;
Identify the architectural styles used in the selected domains and
describe them as architectural patterns;
Provide style-specific techniques to guide the design of productline architectures in the selected domains.
19
E.g.: Repository Style


Components communicate via a shared memory
called a repository. The repository represents the
only vector of communication for the system
components.
Repository styles are structured into:



Independent software components containing domain
knowledge, called domain components. They are defined by
their inputs and outputs;
A structured repository accessible by every component
(read and write accesses);
A control component which purpose is to activate and
coordinate the domain components.
20
E.g.: Repository Style

A set of actions should be performed to design a
SLA in repository-style domains. The major actions
are the following:



Standardisation of the shared repository;
Definition of reusable domain components;
Definition of a standard control component.
21
Feature-Oriented Reuse Method (FORM)



The Feature-Oriented Domain Analysis (FODA)
method has a focus on requirements in assets core
development.
Although marketing and product plan (MPP) can
provide new assets.
FORM is an extension of FODA with support to
architecture design and object-oriented component
development, also incorporating a marketing
perspective and exploring its analysis and design
issues.
22
Feature-Oriented Reuse Method (FORM)

Consists in two major processes:

Asset development
Consists in analyse product line and developing architectures and
reusable components based on analysis results.

Product development
Includes analysis requirements, selecting features and
architecture and adapting components and generating code for
the product.
23
Feature-Oriented Reuse Method (FORM)
Feature-Oriented Reuse Method product line engineering process.
24
Global control behavior of the low-end home integration system.
Feature-Oriented Reuse Method (FORM)
25
Evaluation of Product Line Methods


There are number of software architecture design methods
have been developed. SPLIT, CoPAM and FORM are the major
methods on achieve the needs of software product lines.
Evaluation Framework based on three sources:




NIMSAD (Normative Information Model-based Systems Analysis
and Design) evaluation framework;
The definition of a method and its ingredients
Evaluation framework for component based software development
methodologies
The evaluation results are divided into four elements: context,
user, contents and validation.
26
Evaluation Elements
The framework elements and the questions used in the analysis.
27
Evaluation of SPLA Methods Results

Context



FORM the most indepth method outputs by generating
results that are quite close to the implementation;
CoPAM takes a wider insight into the issue by also
considering the business and organizational aspects.
SPLIT method are at the domain modeling level, resulting in
a definition of a product line by means of requirements,
architecture, components and variation points.
28
Evaluation of SPLA Methods Results

User



None of the methods under evaluation highlight the user
benefits of the methods.
SPLIT and CoPAM recognizes that a successful method
utilizes skills that are already widely known among software
professionals. The FORM method differs with the others in
at least in two ways: first, it defines notation, techniques
and a tool, ASADAL, explicitly. Second, the skills that are
explicitly specified are not widely known among software
developers.
Under the interpretation above, SPLIT and CoPAM are more
practical methods and aimed at industrial use, whereas
FORM is aimed at the academic audience.
29
Evaluation of SPLA Methods Results

Contents


FORM and the SPLIT methods state that an interface
between the requirements and architecture design is
needed.
For instance, platform engineering of CoPAM develops a
platform of reusable components, which refers to the
design of domain components and architecture in FORM and
SPLIT.
30
Evaluation of SPLA Methods Results

Validation


The SPLIT method is the most immature method, whereas
the FORM is the most long-lived one, having being applied
to several industrial case studies on various domains.
CoPAM is surely the first of its kind, but it comprises
existing (and therefore mature) family engineering
methods, and inherits the strengths of those methods;
31
SLA Quality Tools
32
SPLA Quality Tools

ARCHMETRIC


Tool that provides support an architect in identifying and
locating potential structural weaknesses.
ARCHREFACTOR

Tool that complements Ménage (a design environment) in
implementing a set of pre-defined refactoring strategies. An
architect simply provides ARCHREFACTOR with input on
which refactoring algorithm to apply on which part of the
architecture.
33
Nortel’s Study Case
34
Nortel Study

Nortel’s leadership in digital switch architecture
enabled the company to capture US and
international markets. After the 1984 breakup of
AT&T, only Nortel could provide Bell operating
companies with the capability to offer customers
equal access to long-distance carriers. The
company’s high product quality allowed it to become
the first digital switch supplier in Japan.
35
Nortel Study

Problem


After nearly 20 years of successful use, however, the digital
switch architecture began to show signs of needing
renewal. In the late 1980s, the company considered a
major restructuring of the architecture, but the CEO
decided to wait. This decision had severe consequences,
with a reduction in product quality and a tripling in the
length of release cycles.
Nortel later attributed these problems to architecture
breakdown.2 The company took action and rebounded.
After reporting substantial losses in 1993, Nortel posted
profits of $408 million in 1994, $473 million in 1995, and
$623 million in 1996.
36
Nortel Study - How do they get it?

The Answer was obtained through a rigorous
methodology. The methodology applied is based on
the following organizational principles:






Focusing on simplification, minimization, and clarification.
Adapting the architecture to future customer needs,
technology, competition, and business goals.
Establishing a consistent and pervasive architectural rhythm—
regular architecture and product releases that help coordinate
the actions and expectations of all parties.
Partnering and broadening relations with stakeholders.
Maintaining a clear architecture vision across the enterprise.
Proactively managing risks and opportunities.
37
Nortel Study – The principles

Focusing on simplification

“A ruthless focus on simplification, clarification, and
minimization is essential for a successful large software
project”. [Booch]
Simplification requires
balancing the tension between
the needs of current and
potential users. (a) An
architecture overly focused on
future needs; (b) a wellbalanced architecture; (c) an
architecture overly focused on
immediate needs.
38
Nortel Study - The principles

Adapting to future needs


Business pressures in 1986 caused the shifting of
technology renewal funds to other uses.
In late 1980s, the architecture deteriorated, and developers
would clone rather than share architecture components,
increasing the amount of code. Initially this was seen as an
increase in productivity,9 but by 1993 the time required to
add features had tripled.
39
Nortel Study - The principles

Adapting to future needs


One manager said that instead of creating feature-rich
products, they were creating products with “just the
features that make you rich.”
The group planned the evolution of the architecture, tying
new features to scheduled releases over the course of two
years. Also, engineers worked collaboratively with
customers and thus understood not only the technical
aspects of the features, but also their market implications.
40
Nortel Study - The principles

Establishing architectural rhythm


Rhythm ensures that all involved—including customers,
engineers, suppliers, managers, and executives—
understand important issues and know their own
responsibilities.
Planning, development, testing, problem resolution,
creation of documentation, issuing of releases, and
marketing all had their own predictable rhythm, and this
allowed for synchronization and closure of tasks. Everyone
knew the milestones preceding a release and the regular
intervals between them.
41
Nortel Study - The principles

Establishing architectural rhythm
In the case of architecture, balancing short-term results and far-reaching vision is a
lot harder than it looks. Rhythm helps maintain a profitable balance.
42
Nortel Study - The principles

Partnering with stakeholders


Partnering was a key element in delivering the value of
Nortel’s architecture. Internal stakeholders, like users and
developers of architectures, encourage partnering and
therefore reduce of architecture and product complexity.
Reward promotions and raises are influencied by Partnering.
43
Nortel Study - The principles

Maintaining Vision


Without a clear vision, something as abstract as a software
architecture cannot be effectively shared.
Developers and users must feel confident that they know
the general purpose of the designs and code and that they
can identify individuals who know the details.
44
Nortel Study - The principles

Managing risks and opportunities


At specific stages, the architecture is reviewed with internal
and external customers and stakeholders, tracking and
testing the assumptions underlying customer requirements.
Risky areas were tested with prototypes representing
alternative technical approaches, and the chosen solution
was the first to be implemented, tested, and integrated. To
avoid disrupting the rhythm of releases, the group delivered
high-risk features in phases, over multiple releases.
45
Conclusion
46
Software Product Line Architecture (SPLA)




SPL is a trend of how produce software product
lines, joining productivity, quality and reuse.
SPL challenges are more related to organizational
problems than technical solutions.
SPLA is one of major ways to achieving a success
SLA.
SPLA has some methods of design at community,
and they are becoming mature, as we see in FORM.
47
References




Mcgregor, J. D. et al Initiating Software Product
Lines. IEEE Software, 2002.
Kang C. el al, Feature-Oriented Product Line
Engineering. IEEE Software, 2002.
David Garlan, Software Architecture: a
Roadmap. School of Computer Science Carnegie
Mellon University. ACM Press, 2000.
Philippe Lalanda, Style-specific techniques to
design product-line architectures.
48
References



Mari Matinlassi, Evaluation of Product Line
Architecture Design Methods. ICSR 2002, 2002.
Matt Critchlow et al, Refactoring Product Line
Architectures. REFACE2003 , 2003.
David Dikel et al, Applying Software ProductLine Architecture. IEEE, 1997.
49