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

2. Topics Creating the decision model Implementing the modular structure Session 5 14 Jul 2009 DMW2

3. 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 5 14 Jul 2009 DMW3

4. Product Engineering Environment A FAST Process Domain Engineering Product Engineering Products Feedback Investment Payback Session 5 14 Jul 2009 DMW4

5. 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 5 14 Jul 2009 DMW5

6. 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 5 14 Jul 2009 DMW6

7. 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 5 14 Jul 2009 DMW7

8. FWS Behavior HidingDevice InterfaceSoftware Design Hiding Sensor Device Transmitter Device Message Generation Message Format Averager Data Banker Sensor Monitor FWS Module Structure Session 5 14 Jul 2009 DMW8

9. FWS Uses Relation On Modules Controller Message Generation Sensor Monitor Averager Data Banker Sensor Device Driver Transmitter Device Driver Message Format Session 5 14 Jul 2009 DMW9

10. 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 Session 5 14 Jul 2009 DMW10

11. 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 Session 5 14 Jul 2009 DMW11

12. 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 Session 5 14 Jul 2009 DMW12 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

13. Session 5 14 Jul 2009 DMW13 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

14. 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 Session 5 14 Jul 2009 DMW14 Controller Message Generation Sensor Monitor Averager Data Banker Sensor Device Driver Transmitter Device Driver Message Format

15. 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 Session 5 14 Jul 2009 DMW15

16. 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 5 14 Jul 2009 DMW16

17. 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 Session 5 14 Jul 2009 DMW17

18. 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 Session 5 14 Jul 2009 DMW18

19. 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 Session 5 14 Jul 2009 DMW19

20. 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) Session 5 14 Jul 2009 DMW20

21. 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 Session 5 14 Jul 2009 DMW21

22. 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 Session 5 14 Jul 2009 DMW22

23. 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 Session 5 14 Jul 2009 DMW23

24. 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 Session 5 14 Jul 2009 DMW24

25. From Parameters Of Variation To Implementations: The Decision Model System Composition Mapping Session 5 14 Jul 2009 DMW25

26. Session 5 14 Jul 2009 DMW26 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

27. Session 5 14 Jul 2009 DMW27 // ---------------------------------------------- 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(); }

28. Session 5 14 Jul 2009 DMW28 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 (); }

29. Session 5 14 Jul 2009 DMW29 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.

30. 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 5 14 Jul 2009 DMW30

31. Generating Family Members 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) Session 5 14 Jul 2009 DMW31

32. 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 Session 5 14 Jul 2009 DMW32

33. 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 Session 5 14 Jul 2009 DMW33

34. 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) Session 5 14 Jul 2009 DMW34

35. The Application Modeling Language: Graphical Interface Select sensor to be configured Mark the area of the sensor Configuration for selected sensor Configuration for the FWS Generate the product Session 5 14 Jul 2009 DMW35

36. Relationship Architecture Designer (RAD)

37. 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 Session 5 14 Jul 2009 DMW37

38. 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 Session 5 14 Jul 2009 DMW38

39. Exercise 8: Modifying the decision model for the FWS 1. Review the FWS decision model 2. Add the variability you created in Exercise 2 to the decision model, modifying the the parameters of variation and module and uses structures as necessary Session 5 14 Jul 2009 DMW39

40. Teams RoleResponsibilityPerson Systems EngineerCommonality/variabili ty analysis, decision model ArchitectModule, uses, process structures, interface specifications DeveloperModule implementation Tester & Integrator Module tests, System generation and verification Project ManagerEconomic model, project plan Session 5 14 Jul 2009 DMW40

41. Topics Creating the decision model Implementing the modular structure Session 5 14 Jul 2009 DMW41

42. Process Structure(s) Process: A sequence of events Processes may cooperate in a variety of ways –Sending messages –Synchronizing Sharing resources Producing and consuming (data) Event notification –Publish and subscribe –Observer pattern –… Different modes of cooperation may lead to different relations and therefore different structures Session 5 14 Jul 2009 DMW42

43. FWS Process Structure Representation (1) Session 5 14 Jul 2009 DMW43 Message GeneratorSensor Monitor Data Banker Read Write

44. FWS Sequence Diagram Session 5 14 Jul 2009 DMW44 Message GeneratorSensor MonitorData Banker Read Write

45. 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 5 14 Jul 2009 DMW45

46. Session 5 14 Jul 2009 DMW46

47. Session 5 14 Jul 2009 DMW47 FWS Generated Family Member (Addendum D, pp. 135-137)

48. Session 5 14 Jul 2009 DMW48

49. Session 5 14 Jul 2009 DMW49

50. Session 5 14 Jul 2009 DMW50

51. Relations Among Module, Uses, Process Modules: Work assignments that hide design decisions –Relation: Submodule Programs: Run time executable sequences of code (main program, methods, functions, etc.) –Relation: Uses (sometimes generalized to modules) Processes: Run time sequences of events (sequence of instructions + address space + program counter) –Relations: Gives work to, synchronizes with, shares resources with, … Programs in one module may use programs in another module The code that controls a process is a work assignment and must be part of a module Session 5 14 Jul 2009 DMW51

52. 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 5 14 Jul 2009 DMW52

53. FWS Behavior HidingDevice InterfaceSoftware Design Hiding Sensor Device Transmitter Device Message Generation Message Format Averager Data Banker Sensor Monitor FWS Module Structure Session 5 14 Jul 2009 DMW53

54. Abstract Interfaces: Key To Modular Architecture Session 5 14 Jul 2009 DMW54

55. 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 Session 5 14 Jul 2009 DMW55

56. 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 Session 5 14 Jul 2009 DMW56

57. Typical secrets SecretTypical Change How to control a deviceFaster, “larger”, version of device Platform characteristicsFaster processor, multi- processor, larger memory How to control a displayReorganization of screen real- estate, look and feel How to exchange dataProtocol change Database physical structureFields added, faster access needed, field sizes change AlgorithmDifferent 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 5 14 Jul 2009 DMW57

58. 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 Session 5 14 Jul 2009 DMW58

59. Example Module Structure Session 5 14 Jul 2009 DMW59

60. 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 Session 5 14 Jul 2009 DMW60

61. What’s an abstract interface? Set of assumptions that the developers of one module can make about another (not just the signature) –What access methods can I invoke? What are their parameters? What exceptions can occur? –What is the effect of calling a method? What are legal sequences of invocations of access methods? –Push(a) –Push(a).pop –Push(a).top What is the effect on one access method of calling another? –Push(a).top returns a –Set(x).get returns x –What are the externally-visible states of the module? Definition of interface used within context of writing interface specifications is broader than definition used by languages such as Java Session 5 14 Jul 2009 DMW61

62. What’s an abstract interface? One interface that represents many possible actual interfaces (many-to-one mapping) –Abstract device interface: one interface that works for many different implementations of the device (device driver) May have to re-implement the device driver for different versions of the device, but the software that uses the device driver doesn’t change –Interface may abstract away from language or platform C, C++, Java, C# –Provide mapping to different languages –Will have a manifestation in a particular language –Interface abstracts away from secret of the module Session 5 14 Jul 2009 DMW62

63. Interfaces and Assumptions Specifying the interface makes assumptions explicit –Signatures leave important assumptions implicit Does top remove the top element of the stack or just read it? Explicit assumptions –make the user’s job easier –make the reviewer’s job easier –make the implementer’s job easier –make the tester’s job easier –make it easier to predict what will be easy to change and what will be hard to change Session 5 14 Jul 2009 DMW63

64. Some Small Examples Session 5 14 Jul 2009 DMW64

65. Session 5 14 Jul 2009 DMW65

66. Session 5 14 Jul 2009 DMW66

67. Points To Note G/S is short for two access methods: –Get_AUDIBLE_SIGNAL –Set_AUDIBLE_SIGNAL Get_AUDIBLE_SIGNAL has no effect (doesn’t change the state) –The value it returns is defined by the type of its output parameter and the term !Aud signal! Ind_ctrl is a local data type that is used to define the value space for a parameter; it is not an internal variable. Compare to integer, which is used for BEEP_RATE Performance has not been specified Session 5 14 Jul 2009 DMW67

68. Session 5 14 Jul 2009 DMW68

69. Session 5 14 Jul 2009 DMW69

70. Points To Note The module signals two events, one is the event that the condition !RA valid! has become true, the other is the event that !RA valid! has become false. –The interface does not describe the mechanism used to publish and subscribe to events Session 5 14 Jul 2009 DMW70

71. Goals for Creating Module Interface Specifications Clearly documents the behavior of the module –reduces time & knowledge required to adopt module Clearly documents the interfaces used by the module –Aids in creating stubs, mock interfaces and integration test scripts Improves the ability to isolate errors quickly Supports backwards compatibility. Defines implementers work assignment –Interface specification is essentially a contract for the developer that specifies the implementer’s task and the assumptions that users can make Enables straight-forward mapping between use case requirements and methods –reduces effort required for requirements traceability Session 5 14 Jul 2009 DMW71

72. Module Interface Specifications Are not: –Completed at end of development as “after-thought” –Typical API which focuses on describing signature of interface –Lengthy, 100+ page document –Replacement for design documents What they are: –Critical step in design interval –Description of minimal set of methods Do not include extra methods unless clearly understand how additional functionality would be used –Description of how to verify behavior of module in addition to how to use module –Easy to read, maintain –Means for supporting module extensibility Can be documented using Javadoc or other means. –Interface specifications should be completed before implementation Session 5 14 Jul 2009 DMW72

73. A method for constructing abstract interfaces Define services provided and services needed (assumptions) Decide on syntax and semantics for accessing services In parallel Define access method effects Define terms and local data types Define states of the module Record design decisions Record implementation notes Define test cases and use them to verify access methods Cover testing effects, parameters, exceptions –Test both positive and error use cases Cover broader set of tests than typical unit tests Support automation Design test cases before implementing module –Who is responsible for designing test cases? Session 5 14 Jul 2009 DMW73

74. Benefits Enables development of complex projects: –Support partitioning system into separable modules –Complements incremental development approaches Improves quality of software deliverables: –Clearly defines what will be implemented –Errors are found earlier –Error Detection is easier –Improves testability Defines clear acceptance criteria Defines expected behavior of module Clarifies what will be easy to change, what will be hard to change Clearly identifies work assignments Session 5 14 Jul 2009 DMW74

75. “Everything should be as simple as possible, but no simpler.” -- Albert Einstein Session 5 14 Jul 2009 DMW75

76. An FWS Example: The Data Banker Interface Specification Define services provided and services needed Session 5 14 Jul 2009 DMW76 ServiceProvided By Tested By 1. Initialize the set of stored sensor readings. 2. Store a new sensor reading, maintaining only the necessary history, and retrieve the current sensor reading history, keeping reads and writes synchronized.

77. An FWS Example: The Data Banker Interface Specification Decide on syntax and semantics for accessing services Access Methods Session 5 14 Jul 2009 DMW77 Exceptions: Uninitialized Access Methods Parameter name Parameter type Parameter Info Performance Best - Worst –Mapping to Services Provided writes: ISensorReading2 Exceptions: Uninitialized, Empty Access Methods Parameter name Parameter type Parameter InfoPerformance Best - Worst –Mapping to Services Provided readr; OVectorVector of elements of type SensorReading 2 Exceptions: None Access Methods Parameter name Parameter type Parameter Info Performance Best - Worst –Mapping to Services Provided init1

78. An FWS Example: The Data Banker Interface Specification Decide on syntax and semantics for accessing services (cont.) Local Data Types Session 5 14 Jul 2009 DMW78 TypeValue Space SensorReadingA pair (r, v) where r is of type SensorResolution and v is of type SensorValue, representing a sensor reading. SensorResolution{HighRes, LowRes} SensorValueInteger i, where i ≥ 1

79. An FWS Example: The Data Banker Interface Specification Decide on syntax and semantics for accessing services (cont.) Access Method Effects Legal Traces: init, init.write, init.write.read Equivalent Traces Values Session 5 14 Jul 2009 DMW79 TraceEquivalent write.read.readwrite.read TraceValue T.write i (s i ).read(v), i=1..nv=(s k, …, s n ), where (n-k) = min(n, HistoryLength)

80. An FWS Example: The Data Banker Interface Specification Define test cases and use them to verify access method Example Session 5 14 Jul 2009 DMW80 TC 1: Initialize StepDescriptionInput Type/Value Expected Results ServicePreamble 1Initialize data banker None1 2Read from the data banker Read from the DataBanker returns an exception. 2

81. An FWS Example: The Data Banker Interface Specification Complete services provided and services needed Session 5 14 Jul 2009 DMW81 ServiceProvided By Tested By 1. Initialize the set of stored sensor readings. initTC1, TC2, TC3, TC4, TC5 2. Store a new sensor reading, maintaining only the necessary history, and retrieve the current sensor reading history, keeping reads and writes synchronized. read, write TC1, TC2, TC3, TC4, TC5

82. An FWS Example: The Data Banker Interface Specification Record design decisions Interface Design Issues 1, Should we let the user read an empty vector of sensor readings after initialization, or just throw an exception? A1. Yes. An empty vector should be treated just as any other. A2. No. There are no valid values in an empty vector that can be averaged, so we should let he user know that the vector is empty by throwing the exception. Resolution: No. An empty vector is an exceptional case and the user should be informed that he/she has tried to access the data banker before any values have been read using the standard exception mechanisms. Session 5 14 Jul 2009 DMW82

83. Session 5 14 Jul 2009 DMW83 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 (); }

84. Summary Each variability is used to identify the secret of a module, one module per variability Every module has an abstract interface that provides a way for other modules to use its secret without knowing how the secret is implemented An interface is the set of assumptions that the users of a module can make about the module The interface specification for a module is a contract between the users of the module and the implementers of a module An abstract interface specification specifies both syntax and semantics for the interface There is a systematic process for developing interface specifications Session 5 14 Jul 2009 DMW84

85. 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 Information Hiding Secret Abstraction Module Hierarchy, Module Guide Uses, Uses Relation Abstract Interface Design By Contract Session 5 14 Jul 2009 DMW85

86. Exercise 9: Reviewing an interface specification 1.Review the Data Banker Interface Specification, answering the review questions in section 14 of the specification. Session 5 14 Jul 2009 DMW86

87. Exercise 10: Modifying an interface specification Suppose that a variability were added to the FWS family to allow for more than one type of sensor. 1.Propose a statement for such a variability. 2.Propose an associated parameter of variation. 3.Modify the Data Banker interface specification to provide a service to store more than one type of sensor data, consistent with the variability and parameter of variation you proposed in 1 and 2. Session 5 14 Jul 2009 DMW87

88. Exercise 11: Writing an interface specification Write an abstract interface specification for an FWS module other than the Data Banker or Message Format Module Session 5 14 Jul 2009 DMW88

89. Review Questions For Abstract Interfaces: Requirements Validity For each service provided by the module, is the service valid for all expected uses of this module? If not, give an example of a use where the service is not valid. For each service provided by the module, is the service valid for all expected configurations and versions of this module? If not, give an example of a needed configuration or version where the service is not valid. For each service needed described in this specification, is a module (or set of modules) identified that this module is allowed to use to satisfy the need? Session 5 14 Jul 2009 DMW89

90. Review Questions For Abstract Interfaces: Requirements Sufficiency Does the set of services provided specify all of the services that will be needed by users of this module? Are there any services defined that are not identified in the requirements? Does the set of services needed specify all of the services that this module will need from other modules in order to operate correctly? What services are needed that are not identified in the requirements? Session 5 14 Jul 2009 DMW90

91. Review Questions For Abstract Interfaces: Consistency Between Services Provided and Access Programs For each Services Provided described in this specification, which access program(s) can be used to satisfy the service? For each access program and signal specified in sections 2 and 6 which Service Provided is satisfied by the access programs? Session 5 14 Jul 2009 DMW91

92. Review Questions For Abstract Interfaces: Access Program Adequacy Is the set of access programs and signals sufficient to satisfy the uses needs of modules that are allowed to use this module? Are there access programs that should be combined into one access program? Are there single access programs that should be refactored into several different access programs? Are the performance requirements adequate for the uses that will be made of this module? Session 5 14 Jul 2009 DMW92

93. Review Questions For Abstract Interfaces: Implementation of Variability Which variability (or variabilities) does this module implement? Are all values in the range defined in the parameters of variation accounted for in implementing each variability? Which values are not? Can the variabilities be bound at the time specified in the commonality analysis for the variabilities? Session 5 14 Jul 2009 DMW93

94. Teams RoleResponsibilityPerson Systems EngineerCommonality/variability analysis, decision model ArchitectModule, uses, process structures, interface specifications DeveloperModule implementation Tester & Integrator Module tests, System generation and verification Project ManagerEconomic model, project plan Session 5 14 Jul 2009 DMW94

95. Backups Session 5 14 Jul 2009 DMW95

96. Session 5 14 Jul 2009 DMW96