On the Formal Specification of Automata-based Programs via Specification Patterns

1. On the Formal Specification of Automata-based Programs via Specification Patterns Spring/Summer Young Researchers' Colloquium on Software Engineering2010, Nizhny Novgorod Andrey Klebanov, SPb SU ITMO supervised by Oleg Stepanov, PhD, SPb SU ITMO and JetBrains

2. On the Formal Specification of Automata-based Programs via Specification Patterns Agenda Automata-based programming (AP) Obstacles in formal specification Spec patterns (SP) SP applicability analysis for AP Specification process Conclusion

3. Automata-based programming (AP) On the Formal Specification of Automata-based Programs via Specification Patterns • AP is not about using FSMs for specific problems • AP is a software development paradigm used to design and implement entities with complex behaviour

4. Automated controlled entity On the Formal Specification of Automata-based Programs via Specification Patterns

5. Automata-based programming book On the Formal Specification of Automata-based Programs via Specification Patterns http://is.ifmo.ru/books/

6. Agenda On the Formal Specification of Automata-based Programs via Specification Patterns • Automata-based programming • Obstacles in formal specification • Spec patterns • SP applicability analysis for AP • Specification process • Conclusion

7. Problem overview On the Formal Specification of Automata-based Programs via Specification Patterns • Model checking could be successfully applied to automata-based programs • But defining formal specification as a temporal logic formula is an error-prone and time-consuming task • Hard to understand • Hard to specify correctly

8. Example of the problem On the Formal Specification of Automata-based Programs via Specification Patterns Between the time an elevator is called at a floor and the time it opens its doors at that floor, the elevator can arrive at that floor at most twice []((call & <>open) -> ((!atfloor & !open) U (open | ((atfloor & !open) U (open | ((!atfloor & !open) U (open | ((atfloor & !open) U (open | (!atfloor U open)))))))))) M.B. Dwyer, G.S. Avrunin, J.C. Corbett, “Patterns in Property Specifications for Finite-state Verification,” Proc. 21st Int’l. Conf. Software Engineering. 1999

9. Existing solutions (non AP) On the Formal Specification of Automata-based Programs via Specification Patterns Different graphical notations: Helps to understand, but still useless for specification assistance!

10. Existing solution (AP) On the Formal Specification of Automata-based Programs via Specification Patterns Contracts: Pros: Simple Cons: Limited expressive power Labour-intensive for state groups A. Borisenko, P. Fedotov, O. Stepanov, A. Shalyto, “Reliable Software with Complex Behavior Development,” Proc. 5th Central and Eastern European Software Engineering Conf. in Russia. 2009

11. Suggested solution On the Formal Specification of Automata-based Programs via Specification Patterns Express verifiable requirements in a controlled natural language

12. Solution details On the Formal Specification of Automata-based Programs via Specification Patterns • The language is defined by a formal grammar • No need in NLP • Customizable for different domains • The grammar is based on the set of specification patterns (SP) • For each requirement equivalent verifiable formal mappingexists

13. Significance of SP in AP On the Formal Specification of Automata-based Programs via Specification Patterns … it is important to consider temporal properties patterns (structures) which are most suitable and appropriate for automata-based programs verification.Existence of such patterns would allow focusing on classes of temporal properties of automata models which definitely would facilitate flow chart development for automata-based programs verification K.A. Vasileva, E.V. Kuzmin, “LTL Verification of Automaton Programs,” Modeling and Analysis of Information Systems, vol. 14, no. 1, pp. 3–14, 2007. (in Russian)

14. Agenda On the Formal Specification of Automata-based Programs via Specification Patterns • Automata-based programming • Obstacles in formal specification • Spec patterns • SP applicability analysis for AP • Specification process • Conclusion

15. Spec patterns On the Formal Specification of Automata-based Programs via Specification Patterns • SP is a generalized description (both formal and in natural language) of a commonly occurring requirement on a permissible state sequences in a finite-state model of a system • Formally describes some aspect of a system’s behaviour M.B. Dwyer, G.S. Avrunin, J.C. Corbett, “Patterns in Property Specifications for Finite-state Verification,” Proc. 21st Int’l. Conf. Software Engineering. 1999.

16. Spec patterns On the Formal Specification of Automata-based Programs via Specification Patterns Property = SP + Scope

17. Spec patterns On the Formal Specification of Automata-based Programs via Specification Patterns Scope – an extent of the system execution over which the property should hold

18. Spec patterns On the Formal Specification of Automata-based Programs via Specification Patterns Globally BeforeQ AfterQ Scope BetweenQandR AfterQ untilR Q R Q R Q State sequence

19. Spec patterns On the Formal Specification of Automata-based Programs via Specification Patterns Property patterns Order Occurrence Precedence Bounded existence Chain response Absence Chain precedence Response Existence Universality

20. “Absence” pattern On the Formal Specification of Automata-based Programs via Specification Patterns

21. Agenda On the Formal Specification of Automata-based Programs via Specification Patterns • Automata-based programming • Obstacles in formal specification • Spec patterns • SP applicability analysis for AP • Specification process • Conclusion

22. Applicability analysis On the Formal Specification of Automata-based Programs via Specification Patterns • SP were extracted from some spec (500+) for traditionally (non-AP) developed programs • Is it worth using SP for AP formal specification? • I.e. is it possible to express requirements for AP via SP?

23. Intermediate results organization On the Formal Specification of Automata-based Programs via Specification Patterns

24. Applicability analysis On the Formal Specification of Automata-based Programs via Specification Patterns • 77 requirementsfor13 programsfrom 15 sources • 87% could be expressed via5 (out of 8) patterns NB: data is outdated (110+ requirements)

25. Inexpressible properties On the Formal Specification of Automata-based Programs via Specification Patterns Issues in the model? SP (“Absence” pattern): [](Q & !R -> (!P W R)) Q: Resource is hold P:Resource is free R:Resource is released

26. SP adaptation for AP On the Formal Specification of Automata-based Programs via Specification Patterns Original example for the “Absence” pattern: Adapted example:

27. Agenda On the Formal Specification of Automata-based Programs via Specification Patterns • Automata-based programming • Problem overview • Spec patterns • SP applicability analysis for AP • Specification process • Conclusion

28. Grammar (an extract) On the Formal Specification of Automata-based Programs via Specification Patterns <requirement> is a start nonterminal symbol

29. Specification process On the Formal Specification of Automata-based Programs via Specification Patterns Informal algorithm: • Extract property (generally some simple model predicate) • Select pattern and scope • Perform derivation • Based on the step 1 and step 2 data get formal mapping for model checking

30. Example (Original property) On the Formal Specification of Automata-based Programs via Specification Patterns Coffee machine control system never gets into the state where it doesn’t respond to either system timer events, or buttons “OK” or “Cancel” E.V. Kuzmin, V.A. Sokolov, “Modeling, Specification, and Verification of Automaton Programs,” Programming and Computer Software, vol. 34, no. 1, pp. 38–60, 2008

31. Example (Step 1) On the Formal Specification of Automata-based Programs via Specification Patterns Coffee machine control system never gets to the state where it doesn’t respond to either system timer events, or buttons “OK” or “Cancel” act = end

32. Example (Step 2) On the Formal Specification of Automata-based Programs via Specification Patterns Adverb “never” implies using “Absence” pattern with “Global” scope

33. Example (Step 3) On the Formal Specification of Automata-based Programs via Specification Patterns <requirement> → <scope> <pattern> → For all the states holds <pattern> → For all the states holds <absence> → For all the states holds that never P

34. Example (Step 4) On the Formal Specification of Automata-based Programs via Specification Patterns • For all the states holds that never act = end • Formal expressions for model checking are: AG(! act = end) and □(!act = end)

35. Agenda On the Formal Specification of Automata-based Programs via Specification Patterns • Automata-based programming • Obstacles in formal specification • Spec patterns • SP applicability analysis for AP • Specification process • Conclusion

36. Summary On the Formal Specification of Automata-based Programs via Specification Patterns • Significant obstacle exists in formal specification • SP facilitates specifying formal properties • SP are applicable for AP, light adaption of the original system is required • SP could be a basis of the grammar-driven specification process

37. Open issues On the Formal Specification of Automata-based Programs via Specification Patterns • Theoretical side: • Inexpressible properties analysis (also absent in the original SP paper) • New patterns • Practical side: • Tool support and integration • Wizard for the specification process

38. On the Formal Specification of Automata-based Programs via Specification Patterns Thank you! Andrey Klebanov SPb SU ITMO klebanov.andrey@gmail.com