Software architecture for product lines

1
Software architecture for product lines

• Rodrigo Mendes

2
Schedule

• Software Product Lines
• Architecture for Product Lines
• SLA Quality Tools
• Nortels Study Case
• Conclusion
• References

3
Software Product Lines (SPL)
4
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.

5
MCGREGOR et al

• Introduction of SPL in a organization has two
  strategies
• Heavyweight Strategy e.g. Cumins Company.
• Lightweight Strategy e.g. Nokia Company.

A comparison of heavyweight and lightweight
strategies and single-system development.
6
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.

7
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.

8
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.

9
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.

10
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.

11
Software Product Line Architecture
12
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.

13
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.

14
Garlan D.

• There must be an up-front (and on-going)
  investment in developing a reusable architecture
  that can be instantiated for each product.

Product Line Architectures
15
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 product-line 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.

16
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.

17
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

18
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.

19
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 product-line
  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 product-line architectures in the
  selected domains.

20
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.

21
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.

22
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.

23
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.

24
Feature-Oriented Reuse Method (FORM)

• Feature-Oriented Reuse Method product line
  engineering process.

25
Feature-Oriented Reuse Method (FORM)

• Global control behavior of the low-end home
  integration system.

26
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.

27
Evaluation Elements

• The framework elements and the questions used in
  the analysis.

28
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.

29
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.

30
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.

31
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

32
SLA Quality Tools
33
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.

34
Nortels Study Case
35
Nortel Study

• Nortels leadership in digital switch
  architecture enabled the company to capture US
  and international markets. After the 1984 breakup
  of ATT, only Nortel could provide Bell operating
  companies with the capability to offer customers
  equal access to long-distance carriers. The
  companys high product quality allowed it to
  become the first digital switch supplier in
  Japan.

36
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.

37
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 rhythmregular 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.

38
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 well-balanced architecture (c) an
architecture overly focused on immediate needs.
39
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.

40
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.

41
Nortel Study - The principles

• Establishing architectural rhythm
• Rhythm ensures that all involvedincluding
  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.

42
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.

43
Nortel Study - The principles

• Partnering with stakeholders
• Partnering was a key element in delivering the
  value of Nortels 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.

44
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.

45
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.

46
Conclusion
47
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.

48
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.

49
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 Product-Line
  Architecture. IEEE, 1997.