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

ГОСУДАРСТВЕННЫЙУНИВЕРСИТЕТ

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

Spring/Summer Young Researchers' Colloquium on Software Engineering 2010, Nizhny Novgorod

Andrey Klebanov, SPb SU ITMO

supervised by Oleg Stepanov, PhD,

SPb SU ITMO and JetBrains

2



Agenda

Automata-based programming (AP)Obstacles in formal specificationSpec patterns (SP)SP applicability analysis for APSpecification processConclusion

3



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

4



Automated controlled entity

5



Automata-based programming book

http://is.ifmo.ru/books/

6



Agenda

Automata-based programmingObstacles in formal specificationSpec patternsSP applicability analysis for APSpecification processConclusion

7



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

8



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 & !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)

Different graphical notations:

Helps to understand, but still useless for specification assistance!

10



Existing solution (AP)

Contracts:

Pros: Simple

Cons:Limited expressive powerLabour-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

Express verifiable requirements in a controlled natural language

12



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

13



Significance of SP in AP

… 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


15



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 Finite-state Verification,” Proc. 21st Int’l. Conf. Software Engineering. 1999.

16



Spec patterns

Property = SP + Scope

17



Spec patterns

Scope – an extent of the system execution over which the property should hold

18



Spec patterns

Globally

Before Q

After Q

Between Q and R

After Q until R

State sequence

Q R Q R Q

Sco

pe

19



Spec patterns

Property patterns

Occurrence Order

AbsenceBounded existence

Universality Existence

Precedence

Response Chain precedence

Chain response

20



“Absence” pattern

Intent To describe a portion of a system's execution that is free of certain events or states. Also known as “Never”.

Mapping LTL Scope Mapping

Globally [](!P)

Before R <>R -> (!P U R)

After Q [](Q -> [](!P))

Between Q and R []((Q & !R & <>R) -> (!P U R))

After Q until R [](Q & !R -> (!P W R))

CTL Scope Mapping

Globally AG(!P)

… …After Q until R AG(Q & !R -> A[!P W R])

Example and known uses

This pattern could be used to specify either entire model 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.”

Relationships with other patterns

…

21



Agenda


22



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?

23



Intermediate results organization

№ Requirement Original formal mapping

Pattern, Scope

Source

17 If either heater of one of the valves failure has happened, then coffee machine (automaton A0) will mandatory change its state to the state 5.

AG((y31 = 4 | y32 = 4 | y2 = 4) & y0 = 2 → A(y0 = 2 U y0 = 5)))

Response (constrained), Globally

AG(P → A(S)),

P: (y31 = 4 | y32 = 4 | y2 = 4) & y0 = 2,

S: y0 = 2 U y0 = 5

2

24



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)

25



Inexpressible properties

Issues in the model?

SP (“Absence” pattern): [](Q & !R -> (!P W R))Q: Resource is holdP: Resource is freeR: Resource is released

If the resource is hold, then it’s not free until it’s released.

o1.x1 W o1.z1 &G (o1.z2 -> (o1.x1 W o1.z1) &o1.z1 -> (!o1.x1 W o1.z2))

26



SP adaptation for AP

Examples and Known Uses

The most common example is mutual exclusion. In a state-based model, the scope would be global and P would be a state formula that is true if more than one process is in its critical section.

Examples and Known Uses

This pattern could be used to specify either entire model 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.”

Original example for the “Absence” pattern:

Adapted example:

27



Agenda

Automata-based programmingProblem overviewSpec patternsSP applicability analysis for APSpecification processConclusion

28



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> …

<absence> ::= «never P.»

… …

<response> ::= «always if P, then eventually S.»

… …

<requirement> is a start nonterminal symbol

29



Specification process

Informal algorithm:1. Extract property (generally some simple

model predicate)2. Select pattern and scope3. Perform derivation4. Based on the step 1 and step 2 data get

formal mapping for model checking

30



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

31



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

32



Example (Step 2)

Adverb “never” implies using “Absence” pattern with “Global” scope

33



Example (Step 3)

<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)

For all the states holds that never act = end

Formal expressions for model checking are: AG(! act = end) and □(!act = end)

35



Agenda


36



Summary

Significant obstacle exists in formal specification

SP facilitates specifying formal propertiesSP are applicable for AP, light adaption of the

original system is requiredSP could be a basis of the grammar-driven

specification process

37



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

38



Thank you!

Andrey Klebanov

SPb SU [email protected]

Documents

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