David Weiss weiss@sei.pku

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

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

3. Product Engineering A FAST Process Investment Domain Engineering Feedback Product Engineering Environment Payback Products

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)

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

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)

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

8. From Parameters Of Variation To Implementations Via The Module and Uses Structures

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

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

12. Typical secrets

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. • Module: Message Generation Module

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?)

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)

16. FWS Module Hierarchy FWS Device Interface Behavior Hiding Software Design Hiding Sensor Device Transmitter Device Message Generation Message Format Data Banker Sensor Monitor Averager

18. The Module Guide • Textual description of the module hierarchy • Each module described by its secret

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

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.

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?

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.

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.

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.

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.

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

27. From Parameters Of Variation To Implementations: The Decision Model System Composition Mapping

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)

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

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

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.

32. Teams