David Weiss weiss@sei.pku.edu.cn Software Product-Line Engineering: A Family-Based Software Development Process: Designing The Family David 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 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

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

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

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

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

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

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

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

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

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

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

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

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

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

Session 3 21 May 2009 DMW

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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