1. David Weiss weiss@sei.pku.edu.cn
Software Product-Line Engineering: A Family-Based Software Development Process: Designing The Family
David Weiss

2. 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
Process is important; integration of a variety of ideas, most old, some new
FAST in use in Lucent for several years
Session 3 21 May 2009 DMW
Commonality Analysis -- Ardis and Cuka 7

3. Product Engineering Environment
A FAST Process
Investment
Domain Engineering
Feedback
Product Engineering Environment
Product Engineering
Payback
Products
Session 3 21 May 2009 DMW
Commonality Analysis -- Ardis and Cuka 6

4. 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 3 21 May 2009 DMW

5. 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 3 21 May 2009 DMW

6. 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 3 21 May 2009 DMW

7. 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
Session 3 21 May 2009 DMW

8. From Parameters Of Variation To Implementations Via The Module and Uses Structures
Session 3 21 May 2009 DMW

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

10. 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
Characteristics of a module from Module Guide
Modules can be more easily understood and designed than the software system that is composed of them.
Modules can be developed and evolved independently of each other. The dependency of other modules defines the bounds of module evolution.
Modules can be changed and tested independently, quickly leading to more flexible product lines.
A module is a design entity; the runtime structure need not represent the module structure.
A module is a work assignment.
Session 3 21 May 2009 DMW

11. 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
In practice, module can hide several design decisions
Session 3 21 May 2009 DMW

12. 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
Session 3 21 May 2009 DMW

13. 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.
Session 3 21 May 2009 DMW

14. 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?)
Session 3 21 May 2009 DMW

15. 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)
Session 3 21 May 2009 DMW

16. FWS Module Hierarchy FWS Device Interface Behavior Hiding
Software Design Hiding
Sensor
Device
Transmitter
Device
Message
Generation
Message
Format
Averager
Data
Banker
Sensor
Monitor
Session 3 21 May 2009 DMW

17. Session 3 21 May 2009 DMW

18. The Module Guide Textual description of the module hierarchy
Each module described by its secret
Session 3 21 May 2009 DMW

19. 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 variation
None
Session 3 21 May 2009 DMW

20. 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 variation
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.
Session 3 21 May 2009 DMW

21. 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?
Session 3 21 May 2009 DMW

22. 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.
Session 3 21 May 2009 DMW

23. 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 interface.
Session 3 21 May 2009 DMW

24. 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 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.
Session 3 21 May 2009 DMW

25. Different views of information hiding modules
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.
Session 3 21 May 2009 DMW

26. 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
Services are not meant to be “Services” in SOA context. In this context, services would be provided by a SOA Service.
Session 3 21 May 2009 DMW

27. From Parameters Of Variation To Implementations: The Decision Model
System Composition Mapping
Session 3 21 May 2009 DMW

28. 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)
Session 3 21 May 2009 DMW

29. 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
Session 3 21 May 2009 DMW
Commonality Analysis -- Ardis and Cuka 30

30. 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
Session 3 21 May 2009 DMW

31. 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.
Session 3 21 May 2009 DMW

32. 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 3 21 May 2009 DMW