Computer Systems _ Architecture Lesson 5

Document Sample
Computer Systems _ Architecture Lesson 5 Powered By Docstoc
					Computer Systems & Architecture
               Lesson 5




      10. Software Product Lines
10. Software Product Lines

Objectives
• Describe why we need to reuse an existing architecture
• Explain that what makes software product lines work
• List the three things should be consider the
  architecture for product lines
10.1 Overview
• 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.
• When an organization is producing multiple
  similar systems and re-using the same
  architecture, it enjoys substantial benefits that
  include reduced cost of construction and
  reduced time to market.
•   This is the lure of the software product line,
    defined as
    –   A set of software-intensive systems sharing a
        common, managed set of features that satisfy the
        specific needs of a particular market segment or
        mission and that are developed from a common
        set of core assets in a prescribed way.
  10.2 What makes software product lines work?
• The essence o a software product line is the
  disciplined, strategic re-use of assets in producing a
  family of products.
• What makes product lines succeed to 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
  economics.
• The potential for re-use is broad and far-ranging,
  including:
   – Requirements
– Architectural design
– Elements
– Modeling and analysis
– Testing
– Project planning
– Process, methods and tools
– People
– Exemplar systems
– Defect elimination
 10.3 Scoping

• The scope of the 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.
10.4 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.
• 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 on.
• A product line architect needs to consider
  three things:
   • Identifying variation points
   • Supporting variation points
   • Evaluating the architecture for product
     line suitability
 Identifying variation points
• Identifying variation is an ongoing activity.
  Because of the many ways a product can vary,
  variants can be identified at virtually any time
  during the development process.
• Some variations are identified during product
  line requirements elicitation; others, during
  architecture design; and still others, during
  implementation.
• Variations may also be identified during
  implementation of the second products as well.
Supporting variation points
• In a conventional architecture, the mechanism for
  achieving different instances almost always comes
  down to modifying the code. But in a software
  product line, architectural support for variation can
  take many forms:
   • Inclusion or omission of elements.
   • Inclusion of a different number of replicated
     elements.
   • Selection of versions of elements that have the
     same interface but different behavioral or quality
     attribute characteristics.
• These mechanisms produce wholesale changes at the
  architectural level. Other mechanisms can be
  introduced that change aspects of a particular element.
  More sophisticated techniques include the following:
   – In object-oriented systems, specializing or
     generalizing particular classes can achieve variation.
   – Building extension points into element’s
     implementation.
   – Variation can be accomplished by introducing build-
     time parameters to an element, a subsystem, or a
     collection of subsystems, whereby a product is
     configured by setting a collection of values.
-   Reflection is the ability of a program to
    manipulate data on itself or its execution
    environment or state.
-   overloading is a means of re-using a
    named functionality to operate on different
    types.
Evaluating a product line architecture

 • Like any other, the architecture for a
   software product line should be evaluated
   for fitness of purpose.
 • In fact, given the number of systems that
   will rely on it, evaluation takes on an
   even more important role for a product
   line architecture.
-   What and how to evaluate. The evaluation will
    have to focus on the variation points to make
    sure they are appropriate, that they offer
    sufficient flexibility to cover the product
    line’s intended scope.
-   When to evaluate. An evaluation should be
    performed on an instance or variation of the
    architecture that will be used to build one or
    more products in the product line.
10.5 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.
• Architecture definition needs to emphasize
  variation points in a software product line.
• Configuration management is each product is the
  result of binding a large number of variations.
Adoption strategies
• Getting an organization to adopt the product line
  approach is in many regards like any other
  technology insertion problem.
• How to solve it depends on the organization’s culture
  and context.
• Top-down adoption comes when a manager decrees
  that the organization will use the approach.
• Bottom-up adoption happens when designers
  and developers working at the product level
  realize that they are needlessly duplicating
  each other’s work and begin to share
  resources and develop generic core assets.
• Orthogonal to the issue of in which direction
  the technology will grow is the question of
  how the product line itself grows. Here there
  are two primary models.
   • Proactive model
   • Reactive model
Creating products and evolving a product line

• An organization that has a product line
  will have an architecture and a collection
  of elements associated with it.
• From time to time, the organization will
  create a new number of the product line
  that will have features both in common
  with and different from those of other
  members.
• One problem associated with a product
  line is managing its evolution.
• As time passes, the product line-or, in
  particular, the set of core assets from
  which products are built – must evolve.
• That evolution will be driven by both
  sources which are:
  – External sources
  – Internal sources
    Organizational structure
•  An asset base on which products depend, but which
   has its own evolutionary path, requires an
   organization to decide how to manage both it and
   product development.
• Jan Bosch has studied product line organizational
   models and has identified four types:
  1. Development department
  2. Business units
  3. Domain engineering unit
  4. Hierarchical domain engineering units.

				
DOCUMENT INFO