software product-line engineering: a family- based software development process: designing the...

Software Product-Line Engineering: A Family-

Based Software Development Process:Designing The Family

David Weiss

[email protected]

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, Translation

Session 3 21 May 2009 DMW 2

Product Engineering Environment

A FAST Process

Domain Engineering

Product Engineering

Products

Feedback

Investment

Payback


The Domain Model

• Conceptual Framework– Family Definition

• Commonalities and Variabilities Among Family Members• 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 member?– Artifact: The Decision Model Table


The Conceptual Framework (2)• Create The Architecture

– What is a good modular structure and a good uses structure?

– Artifacts: Module Guide, Interface Specifications, Uses Relation

• Design The System Composition Mapping– What modules are needed for which decisions?– Artifacts: System Composition Mapping, Uses Relation

• 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 architecture– Each variability is the hidden decision of a module

• 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

Modules

• 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 decision

• 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 that’s 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• What’s the secret?

– Example: Conditions under which outputs are produced• 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 sensors)– 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 A’s secret is a subsecret of B’s secret

• Example– Device Interface: How to monitor and control devices

– Sensor Device Driver (How to monitor sensor)– Transmitter Device Driver (How to control

transmitter)



FWS

Behavior HidingDevice Interface Software Design Hiding

SensorDevice

TransmitterDevice

MessageGeneration

MessageFormat

Averager DataBanker

SensorMonitor

FWS Module Hierarchy

The Module Guide

• Textual description of the module hierarchy• Each module described by its secret


Excerpts From The FWS Module Guide (1)

1. Behavior Hiding ModulesThe 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 ControllerServiceProvide the main program that initializes a FWS.

SecretHow to use services provided by other modules to start and maintain the proper operation of a FWS.

Associated variabilities and parameters of variationNone


Excerpts From The FWS Module Guide (2)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 DriverService

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

• 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 representation– …

• 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 module’s programs that are visible, forming an

abstract interface for the module’s users. The programs may include data types, signals, exceptions, and other devices that the implementers employ to reflect the assumptions that the module’s 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 implementation.

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 module’s users are allowed to make about the module.

• Secret: What programs and data structures are hidden behind the interface and how they are implemented.



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



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

implemented.

An abstraction• Work assignment: Design and implement instances of the many-to-one mapping that

constitutes the abstraction.• 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.



A collection of macros and preprocessor directives• 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 implementation.• 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 mapping)– Common part is what’s revealed to module’s users (the one)– Secret is how the module is implemented (the many)

• Services (capabilities) that the module provides allows module users to take advantage of the abstraction– 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 module’s

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 implemented

• There may be additional modules for other design decisions

• Example: Message Format Module– Secret: How to create a message in the correct format for

transmission– Variability: MsgType (V2, P4)


Summary

• 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 implemented

• Architecture is a set of structures, such as module structure, uses structure, process structure, plus interface specifications


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


TeamsRole 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


software product-line engineering: a family- based software development process: designing the...

Documents

good uses structure

family membersdesign

program structure

product linepurpose

product generation

good modular structure

hidden decision

composition of modules