On the Formal Specification of Automatabased Programs via

On the Formal Specification of Automatabased Programs via Specification Patterns Spring/Summer Young Researchers' Colloquium on Software Engineering 2010, Nizhny Novgorod Andrey Klebanov, SPb SU ITMO supervised by Oleg Stepanov, Ph. D, SPb SU ITMO and Jet. Brains

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

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

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

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

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

Problem overview 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 On the Formal Specification of Automata-based Programs via Specification Patterns 7

Example of the problem 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 U open))))) M. B. Dwyer, G. S. Avrunin, J. C. Corbett, “Patterns in Property Specifications for Finite -state Verification, ” Proc. 21 st Int’l. Conf. Software Engineering. 1999 On the Formal Specification of Automata-based Programs via Specification Patterns 8

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

Existing solution (AP) 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. 5 th Central and Eastern European Software Engineering Conf. in Russia. 2009 On the Formal Specification of Automata-based Programs via Specification Patterns 10

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

Solution details 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 mapping exists On the Formal Specification of Automata-based Programs via Specification Patterns 12

Significance of SP in AP … it is important to consider temporal properties patterns (structures) which are most suitable and appropriate for automatabased 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) On the Formal Specification of Automata-based Programs via Specification Patterns 13

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

Spec 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 Finitestate Verification, ” Proc. 21 st Int’l. Conf. Software Engineering. 1999. On the Formal Specification of Automata-based Programs via Specification Patterns 15

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

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

Spec patterns Globally Scope Before Q After Q Between Q and R After Q until R Q R Q State sequence On the Formal Specification of Automata-based Programs via Specification Patterns 18

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

“Absence” pattern Intent Mapping To describe a portion of a system's execution that is free of certain events or states. Also known as “Never”. LTL Scope Mapping Globally Before R <>R -> (!P U R) After Q [](Q -> [](!P)) Between Q and R []((Q & !R & <>R) -> (!P U R)) After Q until R CTL [](!P) [](Q & !R -> (!P W R)) Scope Mapping Globally AG(!P) … … After Q until R AG(Q & !R -> A[!P W R]) Example and known This pattern could be used to specify either entire model properties or state group uses properties. To specify a safety property the pattern should be used with a “Global” scope. For example when it’s required to specify a property: “Automaton A never gets into the state s. ” Relationships with other patterns … On the Formal Specification of Automata-based Programs via Specification Patterns 20

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

Applicability analysis 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? On the Formal Specification of Automata-based Programs via Specification Patterns 22

Intermediate results organization № Requirement 17 If either heater of one of the valves failure has happened, then coffee machine (automaton A 0) will mandatory change its state to the state 5. Original formal mapping AG((y 31 = 4 | y 32 = 4 | y 2 = 4) & y 0 = 2 → A(y 0 = 2 U y 0 = 5))) Pattern, Scope Source Response (constrained), Globally 2 AG(P → A(S)), P: (y 31 = 4 | y 32 = 4 | y 2 = 4) & y 0 = 2, S: y 0 = 2 U y 0 = 5 On the Formal Specification of Automata-based Programs via Specification Patterns 23

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

Inexpressible properties Issues in the model? If the resource is hold, then it’s not free until it’s released. o 1. x 1 W o 1. z 1 & G (o 1. z 2 -> (o 1. x 1 W o 1. z 1) & o 1. z 1 -> (!o 1. x 1 W o 1. z 2)) SP (“Absence” pattern): [](Q & !R -> (!P W R)) Q: Resource is hold P: Resource is free R: Resource is released On the Formal Specification of Automata-based Programs via Specification Patterns 25

SP adaptation for AP Original example for the “Absence” pattern: Examples and The most common example is mutual exclusion. In a state-based model, the scope would be global and P Known Uses would be a state formula that is true if more than one process is in its critical section. Adapted example: Examples and This pattern could be used to specify either entire model Known Uses properties or state group properties. To specify a safety property the pattern should be used with a “Global” scope. For example when it’s required to specify a property: “Automaton A never gets into the state s. ” On the Formal Specification of Automata-based Programs via Specification Patterns 26

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

Grammar (an extract) <requirement> : : = <scope> <pattern> <scope> : : = «For all the states holds that» | «Before the state where Q, holds that» | «After the state where Q, holds that» | «Between the states where Q and R, holds that» | «After the state where Q, before the state where R, holds that» <pattern> : : = <absence> | <universality> | <existence> | <constrained existence> | <precedence> | <response> | <constrained response> | <chain precedence> … : : = «never P. » <absence> … <response> … : : = «always if P, then eventually S. » … … <requirement> is a start nonterminal symbol On the Formal Specification of Automata-based Programs via Specification Patterns 28

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

Example (Original property) 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 On the Formal Specification of Automata-based Programs via Specification Patterns 30

Example (Step 1) 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 On the Formal Specification of Automata-based Programs via Specification Patterns 31

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

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

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

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

Summary 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 On the Formal Specification of Automata-based Programs via Specification Patterns 36

Open issues 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 On the Formal Specification of Automata-based Programs via Specification Patterns 37

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