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

Agenda

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

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

Automated controlled entity

Automata-based programming book

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

Agenda

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

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

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

Existing solutions (non AP)

Different graphical notations:

Helps to understand, but still useless for specification assistance!

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

Suggested solution

Express verifiable requirements in a controlled natural language

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

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)

Agenda

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.

Spec patterns

Property = SP + Scope

Spec patterns

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

Spec patterns

Globally

Before Q

After Q

Between Q and R

After Q until R

State sequence

Q R Q R Q

Spec patterns

Property patterns

Occurrence Order

AbsenceBounded existence

Universality Existence

Precedence

Response Chain precedence

Chain response

“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

Agenda

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?

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

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)

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

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:

Agenda

Automata-based programmingProblem overviewSpec patternsSP applicability analysis for APSpecification processConclusion

Grammar (an extract)

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

<absence> ::= «never P.»

… …

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

… …

<requirement> is a start nonterminal symbol

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

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

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

Example (Step 2)

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

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

Example (Step 4)

For all the states holds that never act = end

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

Agenda

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

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

Thank you!

Andrey Klebanov

SPb SU ITMOklebanov.andrey@gmail.com

on the formal specification of automata-based programs via specification patterns

automatabased programs

specification patternsexample

specification assistance

open u open atfloor

atfloor u open

twicecall open

software engineering

reliable software

Documents

automata and formal languages

formal languages finite automata

formal languages, automata and...

cs480(prasad)l9fsa1 finite state automata....

formal languages, automata and models of computation ·...

formal languages, automata and computability

formal pushdown automata dušan koláˇr chapter 1 -...

on the formal specification of automata- based programs via...

automata theory and formal...

comp209 automata and formal languages section 1...

topics automata theory grammars and languages complexities...

automata and formal languages - idc · automata and formal...

formal languages, regular expressions, automata, transducers

formal language and automata theory (cs21004)

formal languages, automata and computation

a bialgebraic approach to automata and formal language...

theory of automata formal languages

automata and formal languagesptw/research-methods.pdf ·...

automata theory and formal...

automata and formal languages - cm0081 finite automata...