1. 1 A Modularity Assessment Framework for Context-dependent Formal Specifications Naoyasu Ubayashi (Kyushu University, Japan) September 14, 2010 ACoM 2010

2. Contexts in embedded systems  Many embedded systems not only affect their contexts through actuators but also are affected by their contexts through sensors.  However, traditional PLE is mainly conducted from the viewpoint of system functions, and contexts are only roughly analyzed. 2 Unexpected behavior might emerge in a system if a developer does not recognize any possible conflicting combinations between the system and contexts. Embedded System Actuator Sensor Contexts

3. Our approach CD-PLP (context-dependent product line practice with lightweight formal approaches)  We proposed a new style of PLE that focuses on constructing embedded systems that take into account the contexts. 3 CD-PLP Described in a formal specificatio n language (VDM++) A configuration can be formally checked! Naoyasu Ubayashi, et al. : Context-dependent Product Line Practice for Constructing Reliable Embedded Systems, SPLC2010 Core assets described in formal languages are effective for constructing reliable product lines. However, it is not clear which modularity is adequate from the viewpoint of Context asset description  crosscutting over system assets Formal specification vs. V&V  Model structures are different when the purpose of the modeling is V&V

4. Today’s my talk -- Next step of CD-PLP 4 Modularity Assessment Framework for Adequate Core Asset Descriptions Formal specification V & V Refinement Which modularity is adequate ?

5. Outline  CD-PLP with VDM++  Lesson learned  Modularity assessment framework  Conclusion 5

6. CD-PLP WITH VDM++ -- QUICK OVERVIEW -- 6

7. 7 Example: an electric pot water level sensor heater thermistor liquid context system pot The pot controls the water temperature by turning on or off the heater. The pot changes its mode to the heat- retaining mode when the temperature becomes 100 Celsius. The pot observes the volume from the water level.

8. 8 CD-PLP Step 1: Analyze features: Boil: () ==> () Boil() == while thermistor.GetTemperature() <= 100.0 do heater.On(); Step 3: Validate a composed system specification VDM++ System LineContext Line Step2: Select a set of features Controller Heater Thermistor Water level sensor Air Pressure Low VDMTools test execution The boiling point of the water is below 100 Celsius. The controller continues to heat the water. As a result, its volume will be empty.

9. LESSON LEARNED 9

10. CD-PLP with VDM++/VDMTool 10 Context assets are formally described ! A configuration of system and context assets can be checked ! However, … Really modular ?

11. Core asset development using VDM++ 11

12. Context asset description in VDM++ 12 -- CONTEXT-liquid class Liquid instance variables protected aap : AtmosphericAirPressure; protected boiling_point : map real to real; protected temperature : real; protected amount : real; operations public GetAap: () ==> AtmosphericAirPressure GetAap() == return aap; public SetAap: AtmosphericAirPressure ==> () SetAap(a) == aap := a; public GetBoilingPoint: real ==> real GetBoilingPoint(atm) == return boiling_point(atm); public GetTemperature: () ==> real GetTemperature() == return temperature; public SetTemperature: real ==> () SetTemperature(t) == temperature := t; public AddTemperature: () ==> () AddTemperature() == if temperature < boiling_point(aap.GetAtm()) then temperature := temperature + 1.0 else (temperature := boiling_point(aap.GetAtm()); amount := amount - 1.0 --- evaporation ) pre temperature <= boiling_point(aap.GetAtm()) post temperature <= boiling_point(aap.GetAtm()); public GetAmount: () ==> real GetAmount() == return amount; public SetAmount: real ==> () SetAmount(a) == amount := a; end Liquid Contexts are abstracted as a set of functions (methods).  Is a functional module adequate for describing contexts ? Additional constraints are introduced to validate a configuration.  These constraints are needed to execute test facilities supported by VDMTool.

13. Lesson learned 13 VDM++ is useful for asset descriptions. However, VDM++ is not always satisfactory. At the same time, there are no formal languages that satisfy all of our needs. Modularity Assessment Framework for selecting appropriate formal languages

14. MODULARITY ASSESSMENT FRAMEWORK 14

15. Criteria for assessment  Specifications Expressiveness Composability  V & V Testability Abstraction  Refinement from formal specifications to implementation Traceability 15 Check priority ! 1.Expressiveness 2.Composability 3.Testability 4.Abstraction 5.Traceability

16. Application to CD-PLP with VDM++ 16 Although the adoption of VDMTools/VDM++ has several problems, we think that this selection is valid because a configuration can be tested functionally. High priority Functional decomposition OO-based modularity Not easy to express crosscutting features of contexts Only functional checking

17. 17 Major drawback System features (VDM++) Context features (VDM++) feature composition crosscutting VDM++ cannot modularize a crosscutting feature.

18. In case of Alloy … 18 Not Acceptable ! Traceability Testability However, Alloy is a good tool if the traceability is not important.

19. CONCLUSION 19

20. Conclusion & Future work  We proposed a modularity assessment framework for selecting appropriate formal languages.  Future work: integrated usage of multiple formal languages. 20

21. 21 Thank you for your attention.