Software Product-Line Engineering: A Family-Based Software Development Process: Designing The Family - PowerPoint PPT Presentation

View by Category
About This Presentation

Software Product-Line Engineering: A Family-Based Software Development Process: Designing The Family


Title: Software Product Len Engineering Subject: Introduction Author: David M. Weiss Last modified by: David Weiss Created Date: 5/22/2009 1:33:10 PM – PowerPoint PPT presentation

Number of Views:105
Avg rating:3.0/5.0
Slides: 33
Provided by: Davi1447


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Software Product-Line Engineering: A Family-Based Software Development Process: Designing The Family

Software Product-Line Engineering A Family-Based
Software Development Process Designing The Family
  • David Weiss

FAST Process
  • A process for defining families and developing
    environments for generating family members
  • Find abstractions common to the family
  • Define a process for producing family members
  • Design a language for specifying family members
  • Generate software from specifications
  • Family-oriented Abstraction, Specification,

A FAST Process
Domain Engineering
Product Engineering Environment
The Domain Model
  • Conceptual Framework
  • Family Definition
  • Commonalities and Variabilities Among Family
  • Common Terminology for the Family
  • Decision Model
  • Economic Analysis
  • Product Line Architecture
  • Optional Application Modeling Language (AML)
    Language for stating requirements
  • Mechanism for generating products
  • Composer or Compiler (AML)

The Conceptual Framework (1)
  • Qualify The Domain
  • Is it economically viable?
  • Artifact Economic Model
  • Define The Family
  • What do members of the family have in common and
    how do they vary?
  • Artifact The Commonality/Variability Analysis
  • Define The Decision Model
  • What decisions must be made to identify a family
  • Artifact The Decision Model Table

The Conceptual Framework (2)
  • Create The Architecture
  • What is a good modular structure and a good uses
  • Artifacts Module Guide, Interface
    Specifications, Uses Relation
  • Design The System Composition Mapping
  • What modules are needed for which decisions?
  • Artifacts System Composition Mapping, Uses
  • Design The Product Engineering Environment
  • What are good mechanisms for using the decision
    model to produce products or to generate products
    from the AML?
  • Artifacts Decision Model GUI, Generator or
    Compiler (AML)

Architecture for the Product Line
  • Purpose Enable product generation through
    composition of modules, each module hiding a
    parameter of variation
  • Apply information hiding to create a modular
  • Each variability is the hidden decision of a
  • Define interface specifications for each module
  • Define a uses relation among programs that appear
    on module interfaces

From Parameters Of Variation To Implementations
Via The Module and Uses Structures
  • ... program structure should be such as to
    anticipate its adaptations and modifications.
    Our program should not only reflect (by
    structure) our understanding of it, but it should
    also be clear from its structure what sort of
    adaptations can be catered for smoothly. Thank
    goodness the two requirements go hand in hand.
  • Edsger W. Dijkstra
  • On Program Families

  • Module Work assignment for a developer or small
    team of developers
  • Concept explored and extended by David Parnas and
    others starting around 1970
  • Goals of modularization
  • Manage complexity by separating concerns
  • Make the system easier to
  • Understand
  • Integrate and build
  • Maintain (change)
  • Test
  • Verify
  • Free modules from product specific dependencies

Modularization Criteria
  • Possible ways to organize a system into modules
  • Functional each module is a function
  • Steps in processing each module is one step in a
    chain of processing
  • Information hiding each module hides a design
  • Information hiding principle
  • Independently-changeable information, such as
    design decisions, should be hidden in
    independently-changeable modules
  • Changes to module implementations are hidden
    behind well-defined interfaces that are stable
    over time
  • Secret decision thats hidden in a module

Typical secrets
Secret Typical Change
How to control a device Faster, larger, version of device
Platform characteristics Faster processor, multi-processor, larger memory
How to control a display Reorganization of screen real-estate, look and feel
How to exchange data Protocol change
Database physical structure Fields added, faster access needed, field sizes change
Algorithm Different time-space trade-off needed, more accurate algorithm invented
Representation of System Entities such as Jobs and Users Change in performance requirements More system entities

Describing Modules
  • Whats the secret?
  • Example Conditions under which outputs are
  • Module Behavior Hiding Module
  • Example How to use services provided by other
    modules to obtain averaged wind speed data and
    transmit it at a fixed period.
  • Module Message Generation Module
  • What service(s) are provided by the module?
  • Example Periodically retrieve data from the Data
    Banker and transmit it.
  • Module Message Generation Module

Organizing Secrets Hierarchically
  • Environment characteristics
  • External device characteristics (How to monitor
  • External system characteristics (Protocol needed
    to communicate externally)
  • Platform characteristics
  • Platform specific services
  • Resource allocation algorithms
  • Thread Management
  • Processor scheduling
  • Memory allocation
  • Required behavior
  • Conditions under which outputs are produced (How
    often to send a message)
  • Software design decisions
  • How to store data
  • Computational algorithms (Averaging?)

The Module Hierarchy
  • A is a submodule of B means that As secret is a
    subsecret of Bs secret
  • Example
  • Device Interface How to monitor and control
  • Sensor Device Driver (How to monitor sensor)
  • Transmitter Device Driver (How to control

FWS Module Hierarchy
Behavior Hiding
Device Interface
Software Design Hiding
Sensor Device
Transmitter Device
Message Generation
Message Format
Data Banker
Sensor Monitor
(No Transcript)
The Module Guide
  • Textual description of the module hierarchy
  • Each module described by its secret

Excerpts From The FWS Module Guide (1)
  • Behavior Hiding Modules
  • The behavior hiding modules include programs that
    need to be changed if the required outputs from a
    FWS and the conditions under which they are
    produced are changed. Its secret is when (under
    what conditions) to produce which outputs.
    Programs in the behavior hiding module use
    programs in the Device Interface module to
    produce outputs and to read inputs.
  • 1.1 Controller
  • Service
  • Provide the main program that initializes a FWS.
  • Secret
  • How to use services provided by other modules to
    start and maintain the proper operation of a FWS.
  • Associated variabilities and parameters of
  • None

Excerpts From The FWS Module Guide (2)
  • Device Interface Modules
  • The device interface modules consist of those
    programs that need to be changed if the input
    from hardware devices to FWSs or the output to
    hardware devices from FWSs change. The secret of
    the device interface modules is the interfaces
    between FWSs and the devices that produce its
    inputs and that use its output.
  • 2.1. Sensor Device Driver
  • Service
  • Provide access to the wind speed sensors. There
    may be a submodule for each sensor type.
  • Secret
  • How to communicate with, e.g., read values from,
    the sensor hardware.
  • Associated variabilities and parameters of
  • V7., the wind speed sensor hardware.
  • Note
  • This module hides the boundary between the FWS
    domain and the sensors domain. The boundary is
    formed by an abstract interface that is a
    standard for all wind speed sensors. Programs in
    this module use the abstract interface to read
    the values from the sensors.

  • Abstraction many-to-one mapping
  • Not vague
  • Not mathematical
  • Not high-level
  • Model common aspects, but not all aspects
  • Device abstraction abstract away from details of
    control sequences
  • Data abstraction abstract away from data
  • One model, implementable many ways
  • Commonality and variability
  • Levels of abstraction?

Different views of information hiding modules
  • A set of programs and shared data
  • Work Assignment Design and implement the
    programs and the data structures that those
    programs share
  • Public Interface The subset of the modules
    programs that are visible, forming an abstract
    interface for the modules users. The programs
    may include data types, signals, exceptions, and
    other devices that the implementers employ to
    reflect the assumptions that the modules users
    are allowed to make about the module.
  • Secret How the programs are implemented, what
    the internal representation of the data is, and
    what internal programs are needed as part of the
  • An abstract interface and its implementation
  • Work assignment Design and implement the
    interface. The interface is abstract in that
    there are many possible implementations of it.
  • Public Interface A set of programs that provide
    the services offered by the module to its users.
    The programs may include data types, signals,
    exceptions, and other devices that the
    implementers employ to reflect the assumptions
    that the modules users are allowed to make about
    the module.
  • Secret What programs and data structures are
    hidden behind the interface and how they are

Different views of information hiding modules
  • A state machine
  • Work assignment Implement the state transition
    function of the state machine.
  • Public Interface Typically, a set of programs
    that provide ways to read the state of the module
    and to cause the module to transition from one
    state to another.
  • Secret How the state transition function is
    implemented, i.e., what programs and data
    structures are used to implement it.
  • A class
  • Work assignment Design and implement the public
    and private methods and the data structures
    needed to implement the module.
  • Public Interface The public methods and data of
    the class.
  • Secret How the methods are implemented, what the
    private methods are, and what data structures are
    used by the methods but do not appear in the

Different views of information hiding modules
  • An abstract data type
  • Work assignment Design and implement the data
    structure used to hold the data for variables of
    the type, and the operations that may be
    performed on the data.
  • Public Interface The operations that may be
    performed on the data type, including functions
    that read and change the value of the data.
  • Secret What the representation of the data
    structure is and how the operations are
  • An abstraction
  • Work assignment Design and implement instances
    of the many-to-one mapping that constitutes the
  • Public Interface The range of the many-to-one
    mapping, i.e., those programs and data that
    embody the services offered by the abstraction to
    its users. One may think of these as the common
    parts of the abstraction.
  • Secret How the details of the mapping are
    implemented so that the common parts of the
    abstraction remain fixed for different instances.

Different views of information hiding modules
  • A collection of macros and preprocessor
  • Work assignment Design and implement the macros
    and directives.
  • Public Interface The set of macros and
    directives that the developers of other modules
    may use.
  • Secret How the macros are implemented.
  • Note design time binding.
  • A black box
  • Work assignment Design and implement the
    external appearance and the internal
  • Public Interface The buttons and dials that the
    users can use.
  • Secret How the box is built.

Information hiding modules as abstractions
  • Module defines an abstraction (many-to-one
  • Common part is whats revealed to modules users
    (the one)
  • Secret is how the module is implemented (the
  • Services (capabilities) that the module provides
    allows module users to take advantage of the
  • Abstract data types Users operate on the data
    without knowing its representation
  • GUI creation environments (VB) Users construct
    GUIs without knowing details of display
  • Protocols Users send and receive data without
    knowing details of channel operation
  • Methods Users invoke methods without knowing
    modules algorithms

From Parameters Of Variation To Implementations
The Decision Model
System Composition Mapping
Information Hiding Modules And Product Lines
  • We want to be able to change the value of each
    variability independently
  • Create a module for each variability
  • Secret of the module is how the variability is
  • There may be additional modules for other design
  • Example Message Format Module
  • Secret How to create a message in the correct
    format for transmission
  • Variability MsgType (V2, P4)

  • Information hiding modules are work assignments
    that hide design decisions
  • We organize information hiding modules into a
    module hierarchy, described in the module guide
    for the family
  • In a product line, for each variability there is
    a module whose secret is how the variability is
  • Architecture is a set of structures, such as
    module structure, uses structure, process
    structure, plus interface specifications

  • Family
  • Product Line
  • Conceptual Model
  • Domain Engineering
  • Domain Model
  • Product Engineering (aka Application Engineering)
  • Product Engineering Environment
  • Decision Model
  • Commonality/Variability Analysis
  • System Composition Mapping
  • Application Modeling Language
  • Structure
  • Module
  • Secret
  • Abstraction
  • Module Hierarchy, Module Guide

Exercise 6 Secrets in FWS Modules
  • Propose a new module for the FWS that will be
    needed to implement the new variability for the
    FWS that you proposed in Exercise 3. State an
    appropriate secret for this module.
  • Add your new module to the FWS Module Hierarchy
    and Module Guide.

Role Responsibility Person
Systems Engineer Commonality/variability analysis, decision model
Architect Module, uses, process structures, interface specifications
Developer Module implementation
Tester Integrator Module tests, System generation and verification
Project Manager Economic model, project plan