Specification and Verification

1
Specification and Verification

• Based on textbook
• Fundamentals of Software Engineering by
• Ghezzi, Jazayeri, Mandrioli

2
Outline

• Discussion of the term "specification"
• Types of specifications
• Infromal, semi-formal, formal
• operational
• Petri Nets
• Statecharts
• descriptive
• Algebraic notations
• Logic-based notation Z

3
Specification

• A broad term that means definition
• Used at different stages of software development
  for different purposes
• Requirements, architecture, design,
• Generally, a statement of agreement (contract)
• All desirable qualities must be specified

4
Uses of specification

• Statement of user requirements
• major failures occur because of misunderstandings
  between the producer and the user
• "The hardest single part of building a softwarem
  system is deciding precisely what to build" (F.
  Brooks)

5
Uses of specification (cont.)

• Statement of the interface between the machine
  and the controlled environment
• serious undesirable effects can result due to
  misunderstandings between software engineers and
  domain experts about the phenomena affecting the
  control function to be implemented by software

6
Uses of specification (cont.)

• Statement of design
• design process is a chain of specification (i.e.,
  definition)implementationverification steps
• requirements specification refers to definition
  of external behavior
• design specification must be verified against it
• design specification refers to definition of the
  software architecture, detailed design
• code must be verified against it

7
Uses of specification (cont.)

• A reference point during maintenance (or
  evolution)
• Clear description available

8
Specification qualities

• Precise, clear, unambiguous
• Consistent
• Complete
• internal completeness
• external completeness
• Supports incremental definition
• (difficult to accomplish)

9
Classification of specification styles

• Informal, semi-formal, formal
• Operational
• Behavior specification in terms of some abstract
  machine
• Descriptive
• Behavior described in terms of properties

10
Classification of specification styles

• Informal
• Natural language
• Semi-formal
• Syntax defined, semantics not defined
  mathematically
• e.g, UML, DFDs
• Formal
• Syntax and semantics are defined mathematically
• First order logic, set theory, automata theory
• e.g. Z, Petri nets, Statecharts, algebraic
  specifications,

11
Example 1

• Specification of a geometric figure E

E can be drawn as follows 1. Select two points
P1 and P2 on a plane 2. Get a string of a certain
length and fix its ends to P1 and P2 3. Position
a pencil as shown in next figure 4. Move the pen
clockwise, keeping the string tightly stretched,
until you reach the point where you started
drawing
this is an operational specification
12
Implementing the specification of a circle
13
A descriptive specification

• Geometric figure E is describe by the following
  equation
• ax2 by2 c 0
• where a, b, and c are constants

14
Formal Specification Notations

• Plethora of formal notations available
• Well known examples are
• Petri nets
• Finite State Machines
• Statecharts
• Z
• J. Bowen maintains a very useful formal methods
  webpage
• http//www.afm.sbu.ac.uk/

15
Petri nets

• Petri nets were developed in the early 1960s by
  C.A. Petri in his Ph.D. dissertation
• C.A. Petri. Kommunikation mit Automaten. PhD
  thesis, Institut für instrumentelle Mathematik,
  Bonn, 1962.
• Useful for modeling concurrent, distributed,
  asynchronous behavior in a system
• Tool support available
• http//www.daimi.au.dk/PetriNets/tools/db.html

16
Petri nets

• Defined as a quadruple (P,T,F,W) P places
• T transitions (P, T are finite)
• F flow relation (F ? P?T ? T?P )
• W weight function (W F ? N 0 )
• Properties (1) P ? T Ø (2) P ? T ? Ø (3) F
  ? (P ? T) ? (T ? P)
• (4) W F ? N-0
• Default value of W is 1
• State defined by marking M P ? N

17
Graphical representation
18
Semantics

• Transition t is enabled iff
• ?p ? t's input places, M(p) ? W(ltp,tgt)
• t fires produces a new marking M in places that
  are either t's input or output places or both
• if p is an input place M'(p) M(p) - W(ltp,tgt)
• if p is an output place M'(p) M(p) W(ltt,pgt)
• if p is both an input and an output place
  M'(p) M(p) - W(ltp,tgt) W(ltt,pgt)

19
Petri Net Behavior
Before firing
After firing

• Any enabled transition may fire
• Model does not specify which fires, nor when it
  fires

20
Modeling with Petri nets

• Places represent distributed states
• Transitions represent actions or events that may
  occur when system is in a certain state
• They can occur as certain conditions hold on the
  states

21
Limitations and extensions
Token represents a message. You wish to say that
the delivery channel depends on
contents. How? Petri nets cannot specify
selection policies.
22
Numerous extensions proposed

• Extensions introduce concepts of
• Time
• Priorities
• Values
• Hierarchical decomposition
• User interactions
• and combinations of extensions

23
Extension Timed Petri nets

• A pair of constants lttmin, tmaxgt is associated
  with each transition
• Once a transition is enabled, it must wait for at
  least tmin to elapse before it can fire
• If enabled, it must fire before tmax has elapsed,
  unless it is disabled by the firing of another
  transition before tmax

24
Statecharts

• Modularized finite state machines
• Incorporated in UML
• Provide the notions of
• superstate
• state decomposition
• global communication
• semantics defined by Harel in 1980s
• Tool support available (e.g. Statemate)

25
Sequential decomposition--chemical plant control
example--
26
Parallel decomposition
27
Descriptive Specifications

• The system and its properties are described in
  the same language
• Proving properties, however, cannot be fully
  mechanized for most languages

28
Algebraic specifications

• Define a heterogeneous algebra
• more than 1 set
• Especially useful to specify ADTs (abstract data
  types)
• Well known notation is Larch

29
Example

• A system for strings, with operations for
• creating new, empty strings (operation new)
• concatenating strings (operation append)
• adding a new character at the end of a string
  (operation add)
• checking the length of a given string (operation
  length)
• checking whether a string is empty (operation
  isEmpty)
• checking whether two strings are equal (operation
  equal)

30
Specification syntax
  algebra StringSpec introduces sorts String,
Char, Nat, Bool operations new ()
String append String, String String add
String, Char String length String
Nat isEmpty String Bool equal String,
String Bool  
31
Specification properties
constrains new, append, add, length, isEmpty,
equal so that for all s, s1, s2 String c
Char isEmpty (new ()) true isEmpty (add (s,
c)) false length (new ()) 0 length (add
(s, c)) length (s) 1 append (s, new ())
s append (s1, add (s2,c)) add (append
(s1,s2),c) equal (new (),new ()) true equal
(new (), add (s, c)) false equal (add (s, c),
new ()) false equal (add (s1, c), add (s2,
c) equal (s1,s2) end StringSpec.  
32
Building modular specifications

• The case of algebraic specifications
• How to combine algebras taken from a library
• How to organize them in a hierarchy

33
Algebras used by StringSpec
algebra BoolAlg introduces sorts
Bool operations true () Bool false ()
Bool not Bool Bool and Bool, Bool
Bool or Bool, Bool Bool implies Bool, Bool
Bool ? Bool, Bool Bool constrains true,
false, not, and, or, implies, ? so that Bool
generated by true, false for all a, b
Bool not (true) false not (false) true a
and b not (not (a) or not (b)) a implies b
not (a) or b end BoolAlg.
34
Algebras used by StringSpec (cont.)
algebra NatNumb introduces sorts Nat,
Bool operations 0 () Nat Succ Nat Nat
Nat, Nat Nat - Nat, Nat Nat Nat,
Nat Bool end NatNumb.
35
StringSpec revisited
algebra StringSpec imports BoolAlg, NatNumb,
CharAlg introduces sorts String, Char, Nat,
Bool operations new () String end
StringSpec.
36
Z Notation

• Defined by Spivey in 1980s
• System specified by describing state space, using
  Z schemas
• Properties of state space described by invariant
  predicates
• first-order logic
• Operations define state transformations
• Tool support available (e.g., Fuzz)

37
An elevator example in Z
38
System state space
39
Formal Specifications and the end-user

• Requirements Specs should be used as common
  reference for producer and user
• Formal specifications help removing ambiguity,
  incompleteness,
• Can they be understood by end-user?
• Some notations are more readable than others
• Less readable notations can be the starting point
  for a prototype, support some form of animation
  (or simulation)

40
Verifying Specifications

• Formal specifications may be verified in a number
  of different ways
• Syntax, typechecking
• If the notation is typed
• Simulated
• Model checked (e.g., SPIN)
• Proven correct (e.g., HOL, PVS)
• More straightforward? Less assurance of
  correctness fully automated
• Less straightforward? Higher assurance of
  correctness not fully automated

More straightforward
Less straightforward
41
Verifying specifications

• Introduction to program correctness (2305 class
  notes, based on textbook Discrete Mathematics,
  Rosen)
• http//www.utdallas.edu/kcooper/teaching/2305/pro
  of/ProgramCorrectness.doc
• Introduction to model checking (Schmidt)
• http//www.cis.ksu.edu/schmidt/papers/home.html
• Introduction to Mechanized Formal Analysis
  (Rushby)
• http//www.cse.unsw.edu.au/kaie/nicta/FM-Workshop
  2003/talks/Rushby-tut.pdf

42
Conclusions

• Specifications describe
• what the users need from a system (requirements
  specification)
• the design of a software system (design and
  architecture specification)
• Descriptions are given via suitable notations
• There is no ideal notation
• They support communication and interaction
  between designers and users
• Formal specifications may be verified using a
  variety of techniques syntax, typecheckers,
  simulators, model checking, theorem provers