Software Product-Line Engineering: A Family-

Based Software Development Process:

Defining The FamilyDavid Weiss

weiss@sei.pku.edu.cn

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 2 20 May 2009 DMW 2

Product Engineering Environment

A FAST Process

Domain Engineering

Product Engineering

Products

Feedback

Investment

Payback

Session 2 20 May 2009 DMW 3

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)

Session 2 20 May 2009 DMW 4

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

Session 2 20 May 2009 DMW 5

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)

Session 2 20 May 2009 DMW 6

Defining Requirements For The Family: The Commonality Analysis

• Must specify requirements that are– common to all family members (commonalities)

– variable among family members (variabilities)

• Commonalities: Assumptions that hold for every member of the family

• Variabilities: Assumptions that define the range of variation for the family

• Parameters of Variation: Quantification of the variabilities• Dictionary of terms

– Technical terms that define a vocabulary for the domain

Session 2 20 May 2009 DMW 7

Organization of A Commonality/Variability Analysis

1. Introduction & Overview

2. Commonalities

3. Variabilities

4. Parameters of Variation

5. Dictionary

6. Issues

7. Notes

8. Review Questions

Session 2 20 May 2009 DMW 8

The Floating Weather Station: An Example

Session 2 20 May 2009 DMW 9

The Floating Weather Station

• Floating Weather Station (FWS) buoys are deployed at sea and periodically report the current wind speed via messages sent by radio. Each member of the FWS family contains an onboard computer that controls the operation of the buoy while it is at sea.

Session 2 20 May 2009 DMW 10

A Few FWS Commonalities

The following statements are basic assumptions about the FWS domain, i.e., they are true of all FWS systems.

C1. At fixed intervals, the FWS monitors the wind speed at its location.

C2. The FWS is equipped with one or more sensors that monitor wind speed.

…

Session 2 20 May 2009 DMW 11

A Few FWS Variabilities

The following statements describe how FWS may vary.

V1. The number of wind speed sensors on a FWS may vary. (C2)

V2. The sensor period of the sensors on a FWS may vary (C1, C2)

…

Session 2 20 May 2009 DMW 12

A Few Parameters of Variation

Parameter Meaning Value Set Binding Time

Default

P1. SensorCount (V1)

Number of wind sensors

[1..5] Specification 1

P2. SensorPeriod (V2)

Sensor period [1..600] sec. Specification 5

…

Session 2 20 May 2009 DMW 13

Dictionary of Terms

Term Meaning

Sensor period The number of seconds between sensor readings

Wind speed The speed of the wind in knots: nautical miles per hour

Session 2 20 May 2009 DMW 14

From Parameters Of Variation To Implementations: The Decision Model

Session 2 20 May 2009 DMW 15

System Composition Mapping

Session 2 20 May 2009 DMW 16

Engineer Application

Process Artifact

Key:

Validation & Acceptance

Customer(s)

Delivered System

Requirements

Decisions

Components+Tools+Processes

Code & Documentation

Decision Model

Summary

• Product Line Scope Is Defined By Commonality/Variability Analysis

• Commonalities Define What’s Common To All Family Members

• Variabilities Define The Range Of The Family• Parameters Of Variation Quantify The Range• Decision Model Uses Parameters of Variation In

Specifying Individual Products

Session 2 20 May 2009 DMW 17

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

Session 2 20 May 2009 DMW 18

“If I have seen farther than others it is because I have stood on the shoulders of giants.”

-- Isaac Newton

Session 2 20 May 2009 DMW 19

“Everything should be as simple as possible, but no simpler.”

-- Albert Einstein

Session 2 20 May 2009 DMW 20

Exercise 3: Scoping A Family Part 1

For the family you proposed in Exercise 1, define 3 commonalities and 3 variabilities

Commonalities

1.

2.

3.

Session 2 20 May 2009 DMW 21

Exercise 3: Scoping A Family Part 1 (cont)

For the family you proposed in Exercise 1, define 3 commonalities and 3 variabilities

Variabilities

1.

2.

3.

Session 2 20 May 2009 DMW 22

Exercise 3: Scoping A Family Part 2

Review the Commonality/Variability Analysis for the FWS

Issues:

Session 2 20 May 2009 DMW 23

Exercise 3: Scoping A Family Part 3

Propose one new commonality and (at least) one new variability for the FWS.

Commonality:

Variability:

Session 2 20 May 2009 DMW 24

FWS Commonalities

The following statements are basic assumptions about the FWS domain, i.e., they are true of all FWS systems.

Behavior

C1. At fixed intervals, the FWS transmits messages containing an approximation of the current wind speed at its location.

C2. The wind speed value transmitted is calculated as a weighted average of the sensor readings, calculated over several readings for each sensor.

Devices

C3. The FWS is equipped with one or more sensors that monitor wind speed.

C4. The FWS is equipped with a radio transmitter that enables it to send messages.

C5. Each sensor comes equipped with a software driver for it and a unique identifier. (See Appendix II for association of sensors and identifiers.)

C6. Each sensor on board a FWS has a way of indicating its reliability.

Session 4 21 May 2009 DMW 25

FWS Variabilities

The following statements describe how a FWS may vary.

Behavior

V1. The formula used for computing wind speed from the sensor readings may vary. In particular, the weights used for the high resolution and low resolution sensors may vary, and the number of readings of each sensor used (the history of the sensor) may vary.

V2. The types of messages that an FWS sends may vary according to both content and format. There are currently only two types of messages, described in section 8., Appendix I.

V3. The transmission period of messages from the FWS may vary.

Devices

V4. The number of wind speed sensors on a FWS may vary.

V5. The resolution of the wind speed sensors may vary.

V6. The sensor period of the sensors on a FWS may vary.

V7. The wind speed sensor hardware on a FWS may vary.

V8. The transmitter hardware on a FWS may vary.

V9. The method used by sensors to indicate their reliability may vary.

Session 4 21 May 2009 DMW 26

Teams

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

Session 2 20 May 2009 DMW 27