Formal Specification and Verification: Mathematically Based Software Quality Assurance Techniques

1
Formal Specification and Verification
Mathematically Based Software Quality Assurance
Techniques

• Presented by Kendra M.L. Cooper
• www.utdallas.edu/kcooper
• kcooper_at_utdallas.edu

2
Todays Presentation

• Overview of Software Quality Assurance (SQA)
  Process Activities
• Formal Specification and Verification
• What is a formal method?
• Why are they a quality assurance technique?
• Model Checking
• What is a model checker?

3
Fault Prevention, Detection, and Removal
SQA a process view
SQA Process
SE Methodology
Certification (CMM, ISO,)
Process Improvement
Project Management
Configuration Management
Are we building the product right?
Are we building the right product?
Validation
Verification
Reviews (walkthroughs, inspections)
Testing
Type, syntax checking
Model Checking
Theorem Proving
Simulation, Executable Prototypes
(Fagen, Gilb) Requirements, analysis model,
detailed design, architecture, test cases, plans,
Test code at different levels unit, integration,
system,...
specification is written in a formal notation and
tool support available
4
SQA an alternate process view
Stakeholders(customer)
Specified (or modeled) in an informal,
semi-formal, or formal notation
Requirements
Specified (or modeled) in an informal,
semi-formal, or formal notation
Validation
Architecture
Verification
Specified (or modeled) in an informal,
semi-formal, or formal notation
Analysis Design
Verification
Construction
Fault Prevention, Detection, and Removal
Verification
Testing
Verification
Process Improvement
Configuration Management
Project Management
5
Specification Notations

• Informal
• Natural language (English)
• Little training required readable
• Extremely difficult to create precise, concise,
  unambiguous specifications
• Semi-formal
• Syntax defined but not semantics (i.e., precise
  meaning)
• Training required, straightforward to learn
• Graphic notations
• Considered more readable than some formal methods
• e.g., Unified Modeling Language (UML)

6
Specification Notations

• Formal
• Syntax and semantics precisely defined using
  mathematics
• Used to create precise, concise, (mathematically)
  unambiguous specifications
• The precision of the notation forces the
  stakeholders to question, investigate, analyze,
  and correct the specification
• Discrete mathematics used include predicate
  logic, set theory, automata theory,
• Graphic or text based syntax
• Training required
• Some considered not straightforward to read
• e.g., Z, VDM, SDL, CSP, Petri Nets,
• J. Bowen maintains a formal methods website
• http//archive.comlab.ox.ac.uk/formal-methods.html
  
• (93 formal notations listed)

7
Formal Methods

• Formal method
• Formal notation tool support heuristics on
  how to use them
• Each formal method
• provides specific fault detection capabilities
• One formal method is not well suited for all
  kinds of problems
• e.g., SDL is specifically tailored for
  communication domain
• One formal method is not well suited for all
  kinds of verification activities
• e.g., SDL tool support provides typechecking and
  simulation capabilities does not support model
  checking
• can be between fully automated or partially
  automated

8
Formal Verification

• Type, Syntax checking
• Used to identify illegal syntax, type mismatches
• similar idea to first pass of a compiler
• Fully automated
• Not too much expertise is needed
• Lowest assurance of quality (among these
  techniques)
• e.g., Z, VDM-SL

9
Formal Verification

• Model Checking
• Used to do an exhaustive, state-space exploration
  of the system
• Determine if properties defined hold or do not
  hold for the system
• Properties are defined in temporal logic
• Fully automated
• Expertise in temporal logic is needed
• Provide middle level assurance of quality (among
  these techniques)
• e.g., SPIN/Promela

10
Formal Verification

• Theorem Proving
• Mechanical theorem provers used to deduce the
  correctness of the specification
• Partially automated
• Substantial expertise in high order logic (or
  other construction logic) is needed
• Highest level assurance of quality (among these
  techniques)
• e.g. , HOL, PVS

11
Model checking

• Correctness verification, in general, is an
  undecidable problem
• Model checking is a rather recent verification
  technique based on the fact that most interesting
  system properties become decidable (i.e.,
  algorithmically verifiable) when the system is
  modeled as a finite state machine

12
Model Checking - Principles

• Describe a given system (software or otherwise)
  as a FSM
• Express a given property of interest as a
  suitable formula in temporal logic
• Verify whether the systems behavior does indeed
  satisfy the desired property
• this step can be performed automatically
• the model checker either provides a proof that
  the property holds or gives a counterexample in
  the form of a test case that exposes the systems
  failure to behave according to the property

13
Model Checking - Principles

• Property to be verified given through a formula
  written in a temporal logic (TL)
• There are many variations of TL
• Linear-time Temporal Logic (LTL) --
  SPIN
• Branching Temporal Logic (BTL)
• Real-Time Temporal Logic (RTTL)
• Computation Tree Logic (CTL)
  -- SMV
• Graphical Interval Logic (GIL)
• Quantified Regular Expressions (QRE)
• Others

14
Model Checking - Principles

• Linear Temporal Logic (LTL)
• Linear time logics view time as a sequence of
  states with no choice as to which state is next
• The choice of the next state is deterministic
• Connectives of LTL (in addition to not, and, or,
  implication)
•                   Always
  ltgt                Eventually o                  
  Next cycle (-)                 previous cycle
  U                  Until
• Examples of LTL p
  // p is always true
• ltgtR -gt (P U R) // Eventually
  it is the case that P exists
• //
  before R happens.

15
Model Checking - Principles

• Safety Property
• A safety property asserts that nothing bad
  happens with the execution of a program statement
  or particular series of statements.
• An example of bad would be an improper or wrong
  output.
• Examples
•     (readySignal 1 -gt ()ackSignal
  0)
• This assertion states "Always, readySignal equals
  one implies ackSignal equals zero on the next
  cycle".
• It makes use of the Always operator (the box) and
  the Next Cycle operator (the empty parentheses
  pair).
• (readySignal 1 -gt (-)ackSignal 0)
• This assertion states Always, readySignal equals
  one impliesackSignal equals zero on the previous
  cycle
• Makes use of the previous cycle operator (-)

16
Model Checking - Principles

• Liveness Property
• A liveness property asserts that something good
  will happen, eventually
• Example
• ltgt(out11 ()()out2 lt 2
  (-)out30)
• This assertion states "Eventually, out1 will
  equal one, and then two cycles later and always
  after that, out2 is less than two and on the
  previous cycle out3 equals zero.
• This example uses the Eventually operator (the
  diamond ltgt), the always operator (the box ),
  and the Next and Previous Cycle operators (the
  empty parentheses pair () and the parenthesized
  minus sign (-), respectively.

17
Model Checking - Principles

• Benefits of model checking
• Pushbutton technique
• Prove safety, liveness properties
• Limitations with model checking
• Restricted to systems that can be modeled as FSM
• Not a general technique
• Combinatorial explosion of the number of states
  of a FSM
• Modeling a K bit register requires 2k states

18
Model Checking

• A nice, brief introduction to model checking
• Ghezzi, C., Jazayeri, M., and Mandrioli, D.,
  Fundamentals of Software Engineering, second
  edition, Prentice Hall, 2003, Section 6.6.
• A more theoretical tutorial on model checking
• Meuller-Olm, M., Schmidt, D.A. and Steffen, B.
  Model checking a tutorial introduction,. Proc.
  6th Static Analysis Symposium, G. File and A.
  Cortesi, eds., Springer LNCS 1694, 1999, pp.
  330-354.
• SPIN homepage (a well known model checker)
• http//spinroot.com/spin/whatispin.html