1. COMS 309 Weiss Spring 2010 Producing Products Software Product-Line Engineering: A Family- Based Software Development Process: Producing Members Of The Family David Weiss weiss@cs.iastate.edu

2. COMS 309 Weiss Spring 2010 Producing Products Topics Creating the decision model Implementing the modular structure 2

3. COMS 309 Weiss Spring 2010 Producing Products 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

4. COMS 309 Weiss Spring 2010 Producing Products Product Engineering Environment A FAST Process Domain Engineering Product Engineering Products Feedback Investment Payback 4

5. COMS 309 Weiss Spring 2010 Producing Products 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

6. COMS 309 Weiss Spring 2010 Producing Products 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

7. COMS 309 Weiss Spring 2010 Producing Products The Conceptual Framework (2) Create The Architecture –What is a good modular structure. a good uses structure, and a good process structure? –Artifacts: Module Guide, Interface Specifications, Uses Relation, Process Structure 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

8. COMS 309 Weiss Spring 2010 Producing Products 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 Define a process structure 8

9. COMS 309 Weiss Spring 2010 Producing Products Decision Model and System Composition Mapping 9

10. COMS 309 Weiss Spring 2010 Producing Products The Decision Model The set of decisions needed to specify a product in the product line, the ordering of the decisions, and the constraints on and among the decisions 10

11. COMS 309 Weiss Spring 2010 Producing Products The Decision Model What decisions must I make to specify a product in the product line? –Example: How many wind speed (WS) spensors will the FWS have? In what order must I make decisions? –Example: Decide the maximum number of WS sensors before deciding the number of WS sensors of each resolution How is one decision constrained (affected by) another? –Example: If total number of WS sensors is N, and number of high resolution sensors is K, then number of low resolution sensors must be N-K 11

12. COMS 309 Weiss Spring 2010 Producing Products The System Composition Mapping The set of modules needed to compose a product in the product line –When I have specified a product, what modules do I need to produce the product? Example: Wind speed sensors require wind speed sensor driver –How should the modules I have chosen be instantiated to produce the product? Example: Short message format requires short message format module –Parameterize the module? »Run time or compile time? –Have different versions of the module? »Build time 12

13. COMS 309 Weiss Spring 2010 Producing Products Applying The FWS Architectural Structures To Create The System Composition Mapping 13

14. COMS 309 Weiss Spring 2010 Producing Products FWS Behavior HidingDevice InterfaceSoftware Design Hiding Sensor Device Transmitter Device Message Generation Message Format Averager Data Banker Sensor Monitor FWS Module Structure 14

15. COMS 309 Weiss Spring 2010 Producing Products Uses Relation A uses B means B must be present and operate according to its specifications for A to operate according to its specifications What are A and B? –Modules Requires presence of complete module Coarse grained –Program, e.g., public methods for a class Fine grained –Define a uses relation among programs that appear on module interfaces 15

16. COMS 309 Weiss Spring 2010 Producing Products FWS Uses Relation On Modules Controller Message Generation Sensor Monitor Averager Data Banker Sensor Device Driver Transmitter Device Driver Message Format 16

17. COMS 309 Weiss Spring 2010 Producing Products Importance of Uses (1) Uses determines the order in which modules should be implemented –Data Banker & Sensor Device Driver Before Sensor Monitor & Averager Controller Message Generation Sensor Monitor Averager Data Banker Sensor Device Driver Transmitter Device Driver Message Format Remember that Uses and Module Structures Are Different 17

18. COMS 309 Weiss Spring 2010 Producing Products Importance of Uses (2) Uses determines the modules that are needed to build a family member –If message generation is included, then so must be averager, transmitter device driver, message format, data banker, sensor device driver Controller Message Generation Sensor Monitor Averager Data Banker Sensor Device Driver Transmitter Device Driver Message Format 18

19. COMS 309 Weiss Spring 2010 Producing Products Importance of Uses (3) Uses determines the modules that are needed to build a family member –In most product lines, some modules are common and always included, some are only included for certain products Laser Device Driver Controller Message Generation Sensor Monitor Averager Data Banker Wind Speed Sensor Device Driver Transmitter Device Driver Message Format Water Temperature Sensor Device Driver 19

20. COMS 309 Weiss Spring 2010 Producing Products FWS Behavior HidingDevice InterfaceSoftware Design Hiding Sensor Device Transmitter Device Message Generation Message Format Averager Data Banker Sensor Monitor FWS Module Structure Wind Speed Sensor Device Driver Water Temperature Sensor Device Driver Laser Device Driver Radio Driver 20

21. COMS 309 Weiss Spring 2010 Producing Products Importance of Uses (4) Uses determines the modules that are needed to build a family member –Modules at the lowest level that are needed to build a product are developed first –Modules at the lowest level are usually invoked most often and should execute fastest Controller Message Generation Sensor Monitor Averager Data Banker Sensor Device Driver Transmitter Device Driver Message Format 21

22. COMS 309 Weiss Spring 2010 Producing Products Controller Message Generation Sensor Monitor Averager Data Banker Sensor Device Driver Transmitter Device Driver Message Format FWS Behavior HidingDevice InterfaceSoftware Design Hiding Transmitter Device Message Generation Message Format Averager Data Banker Sensor Monitor Sensor Device FWS Module Structure FWS Uses Structure 22

23. COMS 309 Weiss Spring 2010 Producing Products 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. 23

24. COMS 309 Weiss Spring 2010 Producing Products Parameters of Variation For Behavior (Table A-1, p. 117) Parameter (Variabilities) MeaningValue SetBinding Time Default P1: HighResWeight, V1.Weight applied to high resolution sensor readings [1..100]Specification50 P2: LowResWeight, V1.Weight applied to low resolution sensor readings [1..100]Specification50 P3: History, V1.Number of sensor readings used per sensor in calculating the weighted average. [1..10]Specification5 P4: MsgType, V2.Type of message that will be transmitted {SHORTMSG,LO NGMSG} SpecificationSHORTMSG 24

25. COMS 309 Weiss Spring 2010 Producing Products Parameters of Variation For Devices (Table A-1, p. 117) Parameter (Variabilities) MeaningValue SetBinding Time Default P5: MaxSensorPeriod, V6. Maximum Sensor Period[1.. 600]Translator Construction 600 P6: MaxSensors, V4.Maximum number of sensors on board a FWS [2..20]Translator Construction 20 P7: MaxTransmitPeriod, V3 Maximum Transmission Period [1.. 600]Translator Construction 600 P8: MinLow, V4., V5.Minimum number of low resolution sensors [2.. MaxSensors-2] Translator Construction 2 P9: MinHigh, V4., V5.Minimum number of high resolution sensors [2.. MaxSensors-2] Translator Construction 2 P10: SensorCount, V4.Number of wind speed sensors (LOW, HIGH) 1,Specification1 P11: SensorPeriod, V6.Sensor period[1..MaxSensorP eriod] sec. Specification5 P12: SensorRes, V5.The resolution of each sensor For each sensor, one of {LOWRES, HIGHRES} SpecificationLOWRES P13: TransmitPeriod, V3.Transmit period[1..MaxTransmit Period] sec. Specification10 1. LOW and HIGH are integers representing the number of low resolution and high resolution sensors respectively, such that Minlow ≤ LOW ≤ L. Minhigh ≤ HIGH ≤ H, L+H ≤ MaxSensors 25

26. COMS 309 Weiss Spring 2010 Producing Products Ordering of Decisions (Table 5-4 p. 76) DecisionOrder (Phase) Maximum number of sensors on board FWS (P6)1 Maximum Sensor Period (P5)1 Maximum Transmission Period (P7)1 Minimum number of low resolution sensors (P8)1 Minimum number of high resolution sensors (P9)1 Type of message that will be transmitted (P4)2 Weight applied to high resolution sensor readings (P1)2 Weight applied to low resolution sensor reading (P2)2 Length of the history of the sensor readings that will be used to calculate the weighted average of sensor readings (P3) 2 Number of wind speed sensors (P10)2 Resolution of each sensor (P12)2 Sensor period (P11)2 Transmission period (P13)2 26

27. COMS 309 Weiss Spring 2010 Producing Products User Selectable Parameters of Variation (Table 5-5 p. 83) DecisionParameter of Variation Weight applied to high resolution sensor readings HighResWeight (P1) Weight applied to low resolution sensor reading LowResWeight (P2) Length of sensor-readings historyHistory (P3) Type of message that will be transmitted MsgType (P4) Number of wind speed sensorsSensorCount (P10) Sensor periodSensorPeriod (P11) Resolution of each sensorSensorRes (P12) Transmission periodTransmitPeriod (P13) 27

28. COMS 309 Weiss Spring 2010 Producing Products System Composition Mapping (Table 5-6 p. 92) Decision (Parameter of Variation)Module(s) Number of low resolution sensors (P10)Sensor Monitor, Data Banker, Sensor Device Driver Weight applied to low resolution sensors (P2)Averager, Data Banker Number of high resolution sensors (P10)Sensor Monitor, Data Banker, Sensor Device Driver Weight applied to high resolution sensors (P1)Averager, Data Banker Length of sensor-readings history (P3)Message Generation, Averager, Data Banker, Sensor Device Driver Sensor period (P11)Sensor Monitor, Sensor Device Driver Transmission period (P13)Message Generation, Transmitter Device Driver, Message Format, Averager, Data Banker Type of message (P4)Message Format 28

29. COMS 309 Weiss Spring 2010 Producing Products Decision Model (1) ParameterMeaningValue Set, Default ConstraintsBinding Time Modules P5: MaxSensorPeriod Maximum Sensor Period [1.. 600] D: 600 Translator Const. Sensor Monitor P6: MaxSensorsMaximum number of sensors on board a FWS [2..20] D: 20 Translator Const. Averager, Data Banker P7: MaxTransmitPeriod Maximum Transmission Period [1.. 600] D: 600 Translator Const. Message Generation P8: MinLowMinimum number of low resolution sensors [2.. MaxSensors-2] D: 2 Translator Const. Sensor Monitor, Data Banker P9: MinHighMinimum number of high resolution sensors [2.. MaxSensors-2] D: 2 Translator Const. Sensor Monitor, Data Banker 29

30. COMS 309 Weiss Spring 2010 Producing Products Decision Model (2) ParameterMeaningValue SetConstraintsBinding Time Modules P1: HighResWeight Weight applied to high resolution sensor readings [1..100] D: 50 SpecAverager, Data Banker P2: LowResWeight Weight applied to low resolution sensor readings [1..100] D: 50 SpecAverager, Data Banker P3: HistoryNumber of sensor readings used per sensor in calculating the weighted average. [1..10] D: 5 SpecMessage Generation, Averager, Data Banker, Sensor Device Driver P4: MsgTypeType of message that will be transmitted {SHORTMSG,LONGMSG } D: SHORTMSG SpecMessage Format 30

31. COMS 309 Weiss Spring 2010 Producing Products Decision Model (3) ParameterMeaningValue SetConstraintsBinding Time Modules P10: SensorCount Number of wind speed sensors (LOW, HIGH)LOW and HIGH are integers representing the no. of low resolution and high resolution sensors respectively, such that Minlow ≤ LOW ≤ L. Minhigh ≤ HIGH ≤ H, L+H ≤ MaxSensors SpecSensor Monitor, Data Banker, Sensor Device Driver P11: SensorPeriod Sensor period [1..MaxSensorPeriod] sec. D: 5 SpecSensor Monitor, Sensor Device Driver P12: SensorRes Resolution of each sensor For each sensor, one of {LOWRES, HIGHRES} D: LOWRES Spec P13: TransmitPeriod Transmit period [1..MaxTransmitPeriod] sec. D: 10 SpecMessage Generation, Transmitter Device Driver, Message Format, Averager, Data Banker 31

32. COMS 309 Weiss Spring 2010 Producing Products From Parameters Of Variation To Implementations: The Decision Model System Composition Mapping 32

33. COMS 309 Weiss Spring 2010 Producing Products Applying The FWS System Composition Mapping: The Structure of the FWS Code Base 33

34. COMS 309 Weiss Spring 2010 Producing Products Code Base 0 Controller (First part) Code Base 1 Controller (Second part) ------------------------------ Data Banker ------------------------------ Sensor Monitor (First part) Code Base 2 Sensor Monitor (Second part) ------------------------------ Message Generator ------------------------------ Averager Code Base Short Code Base Long Message Format for Short MessagesMessage Format for Long Messages Common Code Transmit Device Driver ------------------------------ Sensor Device Drivers 34

35. COMS 309 Weiss Spring 2010 Producing Products // ---------------------------------------------- Code Base 0 ---- FWS0.java------------------- --------------- // First part of Controller import java.util.*; public class FWS { // Constants defining FWS configuration will be appended here, followed by Code Base 1. // ---------------------------------------------- Code Base 1 -----FWS1.java------------------- --------------- // Second part of Controller public FWS() { DataBanker.init(); MessageGenerator m = new MessageGenerator(); m.start(); for (int i = 0; i < sensors.length; i++){ SensorMonitor s = new SensorMonitor(sensors[i]); s.start(); } 35

36. COMS 309 Weiss Spring 2010 Producing Products class DataBanker { public static void init() { for (int i = 0; i < FWS.sensors.length; i++){ Vector v = new Vector(); for (int j = 0; j < FWS.HistoryLength; j++) v.addElement(new SensorReading(1,0)); map.put(FWS.sensors[i].name, v); } public static synchronized void write(String name, SensorReading r) { Vector v = map.get(name); if (v.size() > 0) v.removeElementAt(0); v.addElement(new SensorReading(r.res,r.value)); } public static synchronized Vector read(String name) { return (Vector)map.get(name).clone(); } private static HashMap map = new HashMap (); } 36

37. COMS 309 Weiss Spring 2010 Producing Products class SensorMonitor extends Thread { public Sensor sensor; public SensorMonitor(Sensor sensor){ this.sensor = sensor; } public void run() { while (true) { try { Thread.sleep(sensor.period); } catch (InterruptedException e) {} // For each sensor included in the family member, one sensor read and one data // banker write will be appended here, followed by Code Base 2. 37

38. COMS 309 Weiss Spring 2010 Producing Products Example Generated Code 38

39. COMS 309 Weiss Spring 2010 Producing Products FWS Generated Family Member (Addendum D, pp. 135-137) 39

40. COMS 309 Weiss Spring 2010 Producing Products 40

41. COMS 309 Weiss Spring 2010 Producing Products 41

42. COMS 309 Weiss Spring 2010 Producing Products 42

43. COMS 309 Weiss Spring 2010 Producing Products Summary: What Did We Do? Chose commonalities and variabilities Defined parameters of variation from variabilities Created product line architecture –Guided by variabilties Defined decision model Defined system composition mapping 43

44. COMS 309 Weiss Spring 2010 Producing Products 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) 44

45. COMS 309 Weiss Spring 2010 Producing Products Mechanisms for Composing Family Members Configuring a module for the value of a parameter of variation –Inserting configuration constants, or calling a configuration program on the module’s interface so that the module configures itself –Selecting the appropriate version of a module Short message module vs. long message module –Filling in a template Generate the proper number of calls to the SensorDrivers and insert into the SensorMonitor Module 45

46. COMS 309 Weiss Spring 2010 Producing Products Generating Family Members for The FWS Three ways to implement decisions in the FWS family –by defining a set of constants whose values are determined by the generator and inserted into the code for the family member before compilation Examples: Number of Low Resolution Sensors, Number of High Resolution Sensors, Sensor Period, … (Fig 5-18) –by selecting the appropriate classes from a library of FWS classes to be included in the set of code to be compiled, Example: Message Format Module for short messages, Message Format Module for long messages (Fig 5-20) –by inserting a few lines of code into predetermined locations Generate the proper number of calls to the SensorDrivers and insert into the SensorMonitor Module (Fig 5-19) 46

47. COMS 309 Weiss Spring 2010 Producing Products Code Base 0 Controller (First part) Code Base 1 Controller (Second part) ------------------------------ Data Banker ------------------------------ Sensor Monitor (First part) Code Base 2 Sensor Monitor (Second part) ------------------------------ Message Generator ------------------------------ Averager Code Base Short Code Base Long Message Format for Short MessagesMessage Format for Long Messages Common Code Transmit Device Driver ------------------------------ Sensor Device Drivers Insert constants Insert code Select module 47

48. COMS 309 Weiss Spring 2010 Producing Products The Application Modeling Language The Decision Model is an AML. Is there a better form? –FWS alternatives A file of constants in a specified order A simplified version of the decision model table A list of keyword-value pairs A graphical interface 48

49. COMS 309 Weiss Spring 2010 Producing Products The Application Modeling Language: Simplified Form of the Decision Model Table LowResSensor(1) LowResWeight(50) History(3) HighResSensor(1) HighResWeight(100) SensorPeriod(5) TransmitPeriod(10) MsgFormat(SHORTMSG) 49

50. COMS 309 Weiss Spring 2010 Producing Products The Application Modeling Language: Graphical Interface Configuration for selected sensor Configuration for the FWS Generate the product 50

51. COMS 309 Weiss Spring 2010 Producing Products Relationship Architecture Designer (RAD)

52. COMS 309 Weiss Spring 2010 Producing Products Summary The system composition mapping takes advantage of the uses relation to determine which modules are needed for each decision. –Modules may be configured, templates may be used, or code inserted The decision model uses the system composition mapping to compose a family member from the decisions made by the application engineer. The application engineer only needs to know the decisions that have to be made, and need not see the system composition mapping –Application Modeling Language 52

53. COMS 309 Weiss Spring 2010 Producing Products 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 Uses, Uses Relation Process 53

54. COMS 309 Weiss Spring 2010 Producing Products Exercise 5: Modifying the decision model for the FWS 1. Review the FWS decision model 2. Add the variability you created in Exercise 4 to the decision model, modifying the parameters of variation and module and uses structures as necessary 54

55. COMS 309 Weiss Spring 2010 Producing Products Backups 55

56. COMS 309 Weiss Spring 2010 Producing Products 56