Formal Methods of Systems Specification Logical Specification of Hard- and Software
description
Transcript of Formal Methods of Systems Specification Logical Specification of Hard- and Software
1.7.2008
Formal Methods of Systems SpecificationLogical Specification of Hard- and Software
Prof. Dr. Holger SchlingloffInstitut für Informatik der Humboldt Universität
and
Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik
1.7.2008 Slide 2H. Schlingloff, Logical Specification
Assertion Languages
• OCL is an assertion language for UML
• Similar assertian languages have been defined for various programming languages Java Modeling Language (JML) for Java Spec# for C# PSL for VHDL
• General idea static analysis: try to verify the assertions without
running the program dynamic supervision: use the assertions to
influence the execution of the program
1.7.2008 Slide 3H. Schlingloff, Logical Specification
Example: JML
Reference: http://www.eecs.ucf.edu/~leavens/JML/jmlrefman/
•using Hoare style pre- and postconditions and invariants
•specifications are added as Java annotations (comments) to the Java program can also be stored in separate specification files
//@ <JML specification>/*@ <JML specification> @*/
1.7.2008 Slide 4H. Schlingloff, Logical Specification
JML Syntax
• assert Defines a JML assertion
• requires Defines a precondition on the method that follows
• ensures Defines a postcondition on the method that follows
• invariant Defines an invariant property of the class
• signals Defines a condition on when a given exception can be thrown
by the method that follows• assignable
Defines which fields are allowed to be assigned to by the method that follows
1.7.2008 Slide 5H. Schlingloff, Logical Specification
JML expressions
• Boolean Java expressions• \result
identifier for the return value of the method that follows
• \old(<name>) modifier to refer to the value of variable <name>
at the time of entry into a method (OCL @pre!)
• \forall, \exists universal and existential quantifier (for arrays etc.) range of quantification limited!
• a ==> b, a<==>b logical implications
1.7.2008 Slide 6H. Schlingloff, Logical Specification
Example
public class Account { public static final int MAX_BALANCE = 1000; private int balance; private boolean isLocked = false;
//@ invariant balance >= 0 && balance <= MAX_BALANCE; //@ assignable balance; //@ ensures balance == 0; public Account() { }
//@ requires amount > 0; //@ ensures balance = \old(balance) + amount; public void deposit(int amount) { … }
//@ ensures isLocked == true; public void lockAccount() { this.isLocked = true; } }
1.7.2008 Slide 7H. Schlingloff, Logical Specification
Dynamic Analysis
•Generate extra code from annotations to check violations assert: check at the given statement requires: check before entering the method ensures: check at the end of the method invariant: check after each statement
- obviously, only when statement might affect expression
•Use assertions to generate JUnit test cases set preconditions, get postconditions
1.7.2008 Slide 8H. Schlingloff, Logical Specification
Static Analysis Tools
•Abstract interpretation tries to calculate possible values of variables sound approximation to the possible ranges e.g., i [-maxint..16], [17..21], [22..maxint]i += 1 i [-maxint..17], [18..22], [23..maxint]
•Formally, an abstraction function is a mapping from a (large) concrete domain into a (small) abstract domain; e.g., int {neg, zero, pos} operations on concrete objects are replaced by
operations on abstract objects
1.7.2008 Slide 9H. Schlingloff, Logical Specification
JML Screenshot
www-sop.inria.fr/.../bcwp/img/jmlCompile.jpeg
1.7.2008 Slide 10H. Schlingloff, Logical Specification
Spec# and Spec Explorer
Microsoft‘s Road to Specification•Evolving algebras (Egon Börger et al.,
1990‘s) „Philosophical“ background
•ASMs and the ASML (Yuri Gurevich et al.) Theoretical background
•Spec# (Wolfram Schulte et al.) Interactive program verification
•Spec Explorer (Wolfgang Grieskamp et al.) Support for model-based testing
1.7.2008 Slide 11H. Schlingloff, Logical Specification
Spec# Overview
• Aiming at program verification• Based on C# (which in turn is based on C++ and Java)• Spec# is an extension of C# by non-null types, method
contracts, object invariants, and checked exceptions can be seen as a programming language of its own
• Tool support compiler
- statically enforces non-null types- emits run-time checks for method contracts and invariants- records the contracts as metadata for consumption by
downstream tools static program verifier „Boogie“
- generates logical verification conditions from a Spec# program- uses automatic theorem prover- analyzes the verification conditions to prove the correctness of
the program or find errors in it
http://www.cs.nuim.ie/~rosemary/ETAPS-SpecSharp-Tutorial.pdf
1.7.2008 Slide 12H. Schlingloff, Logical Specification
Use of Spec#
•Write each class containing methods and their specification together in a Spec# source file Invariants that constrain the data fields of
objects may also be included
•Run the verifier (either from IDE or command line) push button, wait (maybe long), get a list of
compilation/verification error messages Interaction with the verifier is done by
modifying the source file
1.7.2008 Slide 13H. Schlingloff, Logical Specification
Screenshot
• Freely available, needs MSVS .Net
Wrong inputPrecondition not
satisfied
Log messages for programmer
1.7.2008 Slide 14H. Schlingloff, Logical Specification
Example
// non-null argument
assume: not checked but taken as granted
assert: statically or dynamically validated
1.7.2008 Slide 15H. Schlingloff, Logical Specification
Swap Example
•How can the proof be performed?
1.7.2008 Slide 16H. Schlingloff, Logical Specification
Spec# Verification
• focus on automation of verification rather than full functional correctness of specifications No verification of liveness (termination or other temporal
eventuality properties) No arithmetic overflow checks (yet)
• Active research on extensions (e.g. comprehensions)
1.7.2008 Slide 17H. Schlingloff, Logical Specification
Quantifiers
•Quantification on finite domains! Verification can be expensive (search all
values)
1.7.2008 Slide 18H. Schlingloff, Logical Specification
Loop Invariants
• Can help the solver to reach its goal !
1.7.2008 Slide 19H. Schlingloff, Logical Specification
Loop Invariants
• Can help the solver to reach its goal !
1.7.2008 Slide 20H. Schlingloff, Logical Specification
1.7.2008 Slide 21H. Schlingloff, Logical Specification
BoogiePL
• Simple procedural language for .Net
if (condition) S else TSpec#:
assume condition;S
assume ! condition;T
Thenbranch
Elsebranch
BoogiePL:
1.7.2008 Slide 22H. Schlingloff, Logical Specification
BoogiePL syntax
1.7.2008 Slide 23H. Schlingloff, Logical Specification
1.7.2008 Slide 24H. Schlingloff, Logical Specification
BoogiePL Verifier
• Based on HP‘s „Simplify“ theorem prover http://www.hpl.hp.com/techreports/2003/HPL-2003-148.pdf
first-order theorem prover (satisfiability) includes complete decision procedures for the
theory of equality and for linear rational arithmetic heuristics for linear integer arithmetic propositional connectives are solved by backtracking handling of quantifiers by pattern-driven
instantiation (incomplete)
• Translation from Boogie PL to Simplify weakest precondition of each statement each statement and each procedure gives rise to
one verification condition