From System Specifications to Component Behavioral Models

1. From System Specifications to Component Behavioral Models Ivo Krka George Edwards Yuriy Brun Nenad Medvidovic

2. Background • Early development specifications • Partial • System-level • Scenarios and properties • Mapping early specifications to more comprehensive behavioral models is beneficial

3. Problem Statement Early development phases Partial Specifications System-level E.g., scenarios and properties Mapping early specifications to more comprehensive behavioral models is beneficial How can we synthesize more comprehensive behavioral models from early specifications?

4. Web Cache Example responseCache pre: cached = true post: none requestServer pre: cached = false post: none responseServer pre: none post: cached = true dataUpdate pre: none post: cached = false dataChanged pre: none post: cached = false Client Cache Server requestCache requestServer responseServer responseCache requestCache responseCache

5. Current Solutions • Component-level model synthesis [1] Client Cache Server responseCache -- pre: cached = true; post: none requestServer -- pre: cached = false; post: none responseServer -- pre: none; post: cached = true dataUpdate -- pre: none; post: cached = false dataChanged -- pre: none; post: cached = false requestCache requestServer responseServer responseCache requestCache Can Client request data twice in a row? Can Server send data without Cache’s request? Etc. responseCache Synthesize requestCache requestServer S1 S2 S3 Cache responseServer requestCache S5 S4 responseCache

6. Modeling Partial Behavior • Modal Transition Systems (MTS) • Required behavior • Potential behavior • Marked with “?” sign MTS M e1? e1 e2 S1 S2 S3 e3 e3? e1? e2 S4

7. Current Solutions • System-level partial behavioral model synthesis [2] • Shortcomings • Potential errors – system-level perspective • Components cannot satisfy the specification • Overlook discrepancies among specifications • Scale, analyzability and comprehensibility

8. Our Approach NEW IDEA: Generating Component-Level Partial-Behavior Models (MTSs)

9. Component-Level MTS Synthesis • Inputs • Sequence diagrams • Pre/post constraints • Outputs • Component MTSs

10. Component-Level MTS Synthesis Sequence diagram annotation Specs Final MTS generation Component-level constraints generation Initial MTS generation

11. Phase 1 Specs Sequence diagram annotation Component-level constraints generation Final MTS generation • Pre/post constraints • System-level Initial MTS generation • Pre/post constraints • Each component responseCache pre: cached = true post: none requestServerpre: cached = false post: none responseServerpre: none post: cached = true dataUpdatepre: none post: cached = false dataChangedpre: none post: cached = false Cache responseCache pre: cached = true post: none requestServerpre: cached = false post: none responseServerpre: none post: cached = true dataChangedpre: none post: cached = false

12. Phase 2 Specs Sequence diagram annotation Component-level constraints generation Final MTS generation • Component pre/post constraints Initial MTS generation • Initial MTS • Only potential transitions requestCache?, requestServer?, dataChanged? requestCache?, responseCache?, responseServer? responseServer? S1 (F) S2 (T) Cache dataChanged?

13. Phase 3 Sequence diagram annotation Specs Component-level constraints generation Final MTS generation • Pre/post constraints • Scenarios Initial MTS generation • Annotated scenarios • Conditions must hold The data is initially not cached. Cache Cache responseCache pre: cached = true post: none requestServerpre: cached = false post: none responseServerpre: none post: cached = true dataChangedpre: none post: cached = false F requestCache F requestServer F responseServer responseCache T requestCache T T responseCache T

14. Phase 4 Specs Sequence diagram annotation Final MTS generation Component-level constraints generation • Initial MTS • Annotated SDs Initial MTS generation • Final MTS • Strong refinement The scenario is incorporated into the MTS as required behavior. requestServer? dataChanged? requestCache? requestServer? Cache requestServer requestCache S1 (F) S2 (F) S3 (F) requestCache? dataChanged? responseServer? responseServer responseServer? responseCache? requestCache? requestCache responseCache S4 (T) S5 (T) S6 (T) dataChanged? responseServer? responseCache responseServer?

15. Utilization 1: Discovery of Specification Discrepancies • Scenario cannot execute • Constraint violated • Component cannot reach desirable state • Missing events Client Cache Server requestCache responseCache dataUpdate requestCache requestServer responseServer responseCache

16. Utilization 2: Requirements Elicitation • Propose new scenarios • Infer/propose new properties Client Cache Server requestCache requestServer responseServer dataUpdate When the data is not cached and the request is pending, the request will be pending in the next state dataChanged requestServer □((requestPending ¬ cached )→○(requestPending ))

17. Utilization 3: OTS Component Selection • Multiple candidate components • Satisfaction of required behavior • No proscribed behavior 1 2 3 Selection 1

18. Utilization 4: As-intended vs. As-implemented • Comparison • Introduced proscribed behavior? • Missing required behavior? • Architectural drift e1? e1 e1 S1 S2 S1 S2 e3 e3? e2 e3? e2 e2 e2 S3 S3

19. Conclusions • Synthesis algorithm the first step • Component-level MTSs • Notable potential contributions

20. Thank you! Questions?