CIS 890: Safety Critical Systems
|
|
- Phoebe Fleming
- 5 years ago
- Views:
Transcription
1 CIS 890: Safety Critical Systems Lecture: SPARK -- Analysis Tools Copyright 2007, John Hatcliff. The syllabus and all lectures for this course are copyrighted materials and may not be used in other course settings outside of Kansas State University in their current form or modified form without the express written permission of one of the copyright holders. During this course, students are prohibited from selling notes to or being paid for taking notes by any person or commercial firm without the express written permission of one of the copyright holders.
2 Outline SPARK tool architecture overview Dataflow and information flow analysis Path functions Verification conditions Iterative processes (properties of loops) Nested processes
3 SPARK Tool Support The Examiner is the primary SPARK tool. From the perspective of the developer, it s the entry point into the SPARK tool chain.
4 Examiner Functionality The Examiner is a free-standing software tool to support the use of SPARK The Examiner always checks conformance of text file to the rules of SPARK checks consistency of executable code with its core annotations Optionally, the Examiner can be used to obtain verification conditions (VCs) for SPARK programs which can be fed to downstream tools facilitate demonstration that a SPARK program is free from run-time errors produce an obsolescent and less rigorous form of analysis called path functions.
5 SPARK Eliminates Errors Many run-time exceptions of full Ada cannot occur in SPARK Constraint_Error cannot arise if analysis shows that the program cannot violate ranges such as array bounds and does not cause arithmetic overflow or attempt to divide by zero. Storage_Error cannot arise since the storage requirements can be determined at compile time (recursion and dynamic arrays are forbidden in SPARK) and suitable hardware can therefore be provided. Program_Error cannot arise because the conditions leading to it such as running into the end of a function can never arise in SPARK. Tasking_Error cannot arise because SPARK does not support tasks and protected objects and the communication between them. (Note: this applies even when the Ravenscar profile is considered.)
6 Examiner Functionality The Examiner supports two specific forms of flow analysis Data Flow Analysis usage of parameters and global variables corresponds to their modes variables not read before assigned values are not overwritten without being used all imported variables used somewhere etc. Data & Information Flow Analysis checks derives annotations in addition to the above these different levels of checking can be combined within a single program
7 Derives Annotations Recall the basic properties of derives annotations procedure Exchange(X, Y : in out Float); --# derives X from Y & --# Y from X; is T : Float; begin T := X; X := Y; Y := T; end Exchange; +++ Flow analysis of subprogram Exchange performed: no errors found.
8 Derives Annotations Recall the basic properties of derives annotations procedure Exchange(X, Y : in out Float); --# derives X from Y & --# Y from X; is T : Float; begin T := X; X := Y; Y := X; end Exchange; What sort of output does the Examiner give?
9 Examiner Output Symbols used for classifying outputs +++???!!! OK, the examiner ran with no warnings or errors warning error
10 Information Flow Analysis Examiner outputs for the preceeding example!!! ( 2) Flow Error : 35: Importation of the initial value of variable X is ineffective.!!! ( 3) Flow Error : 33: The variable T is neither referenced nor exported.!!! ( 4) Flow Error : 50: The imported value of X is not used in the derivation of Y.??? ( 5) Warning :601: The imported value of Y may be used in the derivation of Y.
11 Full Slide Graphic SPARK Program Path functions The Examiner Verification conditions Messages regarding flow analysis Additional rules Proof tools The proofs Interactions with human user
12 Path Function Reveals what happens when a particular path is traced through a subprogram A subprogram with no loops has a finite number of paths through it and for each of these there is a corresponding path function Each path function has two parts traversal condition which is a formula defining the conditions under which the path is traversed action part which defines the final values of modified variables in terms of the initial values of the imported variables
13 Path Function Example Here s a very simple example of a path function procedure Exchange(X, Y : in out Float); --# derives X from Y & --# Y from X; is T : Float; begin T := X; X := Y; Y := T; end Exchange;} Path 1 Traversal condition: 1: true. Action: x' := y & y' := x & t' := x.
14 Path Function Example Example with simple branching function Max(I,J : Integer) return Integer is Result : Integer; begin if I > J then Result := I; else Result := J; end if; return Result; end Max; Path 1 Traversal condition: 1: i > j. Action: max' := i & result' := i. Path 2 Traversal condition: 1: not (i > j). Action: max' := j & result' := j.
15 Path Function Example Example with nested conditionals procedure Fault_Integrator(Fault_Found : in Boolean; Trip : in out Boolean; Counter : in out Integer); --# derives Trip from Fault_Found, Trip, Counter & --# Counter from Fault_Found, Counter; is begin if Fault_Found then Counter := Counter + Up_Rate; if Counter >= Upper_Limit then trip := True; Counter := Upper_Limit; end if; else Counter := Counter - Down_Rate; if Counter <= Lower_Limit then Trip := False; Counter := Lower_Limit; end if; end if; end Fault_Integrator;
16 Path Function Example Path function for examples with nested conditionals (part 1) Path 1 Traversal condition: 1: fault_found. 2: counter + up_rate >= upper_limit. Action: trip' := true & counter' := upper_limit. Path 2 Traversal condition: 1: fault_found. 2: not (counter + up_rate >= upper_limit). Action: counter' := counter + up_rate. Path condition is stated in terms of initial values of imported variables. Trip not modified in this branch, so not listed.
17 Path Function Example Path function for examples with nested conditionals (part 2) Path 3 Traversal condition: 1: not fault_found. 2: counter - down_rate <= lower_limit. Action: trip' := false & counter' := lower_limit. Path 4 Traversal condition: 1: not fault_found. 2: not (counter - down_rate <= lower_limit). Action: counter' := counter - down_rate.
18 Path Functions The path function mechanism can be used to detect infeasible paths (dead code) if X > Y then if X < Y then end if end if; It is impossible to have a path that reaches this point (assuming X, Y are not modified). Certification standards for development process often require each line of code to be traced back to some system requirement (each piece of code should be in the system for a reason) Also, these same standards often require testing to certain levels of coverage for a particular coverage criteria Thus, it is useful to have automated tools to indicate if a particular section of code is never executed otherwise, we might be working forever to try to generate a test that covers it
19 Path Functions Examiner output for example with infeasible path Path 2 Traversal condition: 1: x > y. 2: x < y. Running the SPARK Simplifier (SPADE) Path 2 Path eliminated. (Contradictory traversal condition)
20 Assessment Estimated that around 10% of paths in typical production programs can never be executed because the appropriate combination of path conditions never arises It is often easier to leave the code intact rather than make the conditions more elaborate However, this is not an option under certain certification regimes Due to combinatorial explosion in number of paths, it is often easier to develop a formal correctness proof using verification conditions that to manually analyze and document the correctness of each path Path functions can be used as the basis of automatically generating tests from implementations.
21 Tool Invocation Typical tool invocation $ spark -pfs <filename> Switch for option to generate path conditions. Output goes by default into a subdirectory named p within the current directory. $ spadesimp Automatically looks for various files (including p directory) within current directory to simplify
22 For You To Do (insert simple tool-based exercise for path conditions here)
23 Verification Conditions Pre-condition N(..) } Post-condition Path functions The Examiner Verification conditions Messages regarding flow analysis Additional rules Proof tools The proofs Interactions with human user Given some initial procedure contract information in the form of pre/post-conditions (or some other goal such as avoiding certain runtime errors), the Examiner DOES NOT try to directly prove that the code satisfies the contract instead, it processes the contract and the code and generates verification conditions -- conjectures which, if proved to be true, show that the postconditions to indeed always follow from the preconditions.
24 Verification Conditions Example with simple post-condition contract procedure Exchange(X, Y : in out Float); --# derives X from Y & --# Y from X; --# post X = Y~ and Y = X~; is T : Float; begin T := X; X := Y; Y := T; end Exchange; Essence of what the Examiner produces as verification condition generator for example above. H1: true. -> C1: y = y. C2: x = x. Simple post condition stating that parameter values have been swapped. H1 and H2 and -> C1 and C2 and
25 Steps for Simple Tool Chain Steps for generating verification conditions Pre-condition N(..) } Post-condition The Examiner $ spark -rtc <filename> Verification conditions (output in subdirectory p with file extension.vcg) SparkSimp $ sparksimp The proofs (output in subdirectory p with file extensions.siv and.slg)
26 Verification Conditions Can the tools detect a simple error? procedure Exchange(X, Y : in out Float); --# derives X from Y & --# Y from X; --# post X = Y~ and Y = X~; is T : Float; begin T := X; X := Y; Y := T + 1.0; end Exchange; Examiner output H1: true. -> C1: y = y. C2: x + 1 = x. Simplifier output H1: true. -> C1: false.
27 Verification Conditions Can the tools detect a simple error? procedure Exchange(X, Y : in out Float); --# derives X from Y & --# Y from X; --# post X = Y~ and Y = X~; is T : Float; begin T := X; X := Y; Y := X; end Exchange; Examiner output H1: true. -> C1: y = y. C2: y = x. Simplifier output In this case, the Examiner actually reports a number of information flow errors, but if we continue with VC generation, here s what we would get. H1: true. -> C1: y = x. Example File: ex0304c
28 Verification Conditions Verifying against possible run-time check errors type T is range ; procedure Inc(X : in out T); --# derives X from X; is begin X := X + 1; end Inc; Examiner+Simplifier output H1: x >= H2: x <= > C1: x <= 127. Verification generated each time we have an assignment to a variable of range type (to establish that the assigned value is within range). Pre-conditions automatically generated based on knowledge of range type. Assessment: one cannot prove the conclusions from the given hypotheses -- so we have the potential for an error on some calls to the procedure. Example File: ex0304d
29 Verification Conditions Using contract pre-conditions to eliminate possibility of run-time violation (and allowing VCs to be proved) procedure Inc(X: in out T) --# derives X from X; --# pre X < T Last; is begin X := X + 1; end Inc; Max value of range type Examiner output H1: x < t last. H2: x >= t first. H3: x <= t last. -> C1: x + 1 >= t first. C2: x + 1 <= t last. which the Simplifier is able to prove. Example File: ex0304e
30 Verification Conditions Alternatively, use defensive programming procedure Inc(X: in out T) --# derives X from X; is begin if X < T Last then X := X + 1; end if; end Inc; Assessment: generally, not a good idea when one has an automated contract checking framework. We should instead let the contract checker do the work statically and avoid the run-time overhead. However, relying on contracts does mean that we have to establish that every client correctly satisfies the pre-condition.
31 For You To Do (insert exercise here for applying the Examiner/Simplifier for VC generation and simplification)
32 Dealing With Loops Loops introduce complexity in proving correctness a loop is traversed a number of times with different conditions (overwise it would never terminate) usually, automated verification techniques are not powerful enough to calculate the conditions (loop invariants) necessary to summarize the behavior of the loop on all paths Generally, with techniques based on Hoare Logic (such as SPARK), one seeks to reduce the problems given to the automated tool to reasoning about a collection single segments (paths) through the method use explicit assertions at crucial points to break up paths in the method to achieve this property each path should have its own pre/post condition when gluing the paths together, the post-condition of the preceding path has to be strong enough to establish the precondition of the successor path
33 Reasoning About Loops Consider the following simple iterative arithmetic calculation.. procedure Divide(M, N : in Integer; Q, R : out Integer); --# derives Q, R from M,N; is begin Q := 0; R := M; loop exit when R < N; Q := Q + 1; R := R - N; end loop; end Divide; Consider the behavior for M=5, N=2 Q=0, R=5 1st iteration Q=1, R=3 2nd iteration Q=2, R=1 3rd iteration when could things go wrong in the algorithm? Let s add pre-conditions to prevent that. Then add a post-condition to capture the correctness property. Example File: ex0305a
34 Reasoning About Loops Begin with appropriate pre/post-conditions procedure Divide(M, N : in Integer; Q, R : out Integer); --# derives Q, R from M,N; Simple pre-condtion --# pre (M >= 0) and (N > 0); --# post (M = Q * N + R) and (R < N) and (R >= 0); is begin Q := 0; R := M; loop exit when R < N; Q := Q + 1; R := R - N; end loop; end Divide; Correctness properties for output Q := Q + 1; R := R - M; false R < N? Need to cut this looping path into segments without cycles Example File: ex0305a
35 Reasoning About Loops Add loop invariant to summarize relationships between variables procedure Divide(M, N : in Integer; Q, R : out Integer); --# derives Q, R from M,N; --# pre (M >= 0) and (N > 0); --# post (M = Q * N + R) and (R < N) and (R >= 0); is begin Q := 0; R := M; loop --# assert (M = Q * N + R) and (R >= 0); exit when R < N; Q := Q + 1; R := R - N; Loop invariant end loop; end Divide; Example File: ex0305a
36 Path Segments Each path now has a pre/post-condition Note: the assert cuts a path and becomes the postcondition for the preceding segment and the precondition for the following section. Start pre M >= 0 and N > 0; (pre) Q := 0; R := M; (post) (pre/post) (pre) assert M = Q * N + R and R >= 0; false R < N? true Q := Q + 1; R := R - M; Halt post (M = Q * N + R) and R < N and R >= 0; (post)
37 Examiner VC Output Path 1 Start pre M >= 0 and N > 0; (pre) Q := 0; R := M; (post) assert M = Q * N + R and R >= 0; H1: m >= 0. H2: n > 0. -> C1: m = 0 * n + m. C2: m >= 0. the simplifier can reduce this (and subsequent VCs) to true
38 Examiner VC Output Path 2 Q := Q + 1; R := R - M; false R < N? (pre/post) assert M = Q * N + R and R >= 0; H1: m = q * n + r. H2: r >= 0. H3: not (r < n). -> C1: m = (q + 1) * n + (r - n). C2: r - n >= 0.
39 Examiner VC Output Path 3 H1: m = q * n + r. H2: r >= 0. H3: r < n. -> C1: m = q * n + r. C2: r < n. C3: r >= 0. (pre) assert M = Q * N + R and R >= 0; R < N? true Halt post (M = Q * N + R) and R < N and R >= 0; (post)
40 Check vs Assert assert causes the accumulated conditions to be dropped (starts a new path), whereas check causes the conditions to be maintained procedure P(... ) --# pre B1; --# post B3; is begin -- some code --# check B2; -- more code end p; path 1 path 2
41 Using Check Let s see the VCs generated when check is used procedure Exchange(X, Y : in out Float); --# derives X from Y & --# Y from X; --# post X = Y~ and Y = X~; is T : Float; begin T := X; X := Y; --# check X = Y~; Y := T; end Exchange; H1: true. -> C1: y = y. H1: true. H2: y = y. -> C1: y = y. C2: x = x. Example File: ex0306a
42 VCs for Procedure Calls H1: M-Pre. -> C1: N-Pre. H1: M-Pre. H2: N-Post. -> C1: M-Post. Pre-condition M(,, ) {. check N-Pre N(..) assume N-Post } Pre-condition N(..) } Post-condition Post-condition
43 VCs for Procedure Calls Building on our previous example procedure CAB(A, B, C : in out Float); --# derives A from C & --# B from A & --# C from B; --# post A = C~ and B = A~ and C = B~; is begin Exchange(A,B); Exchange(A,C); end CAB; Assumptions from postcondition of each call CAB post-condition procedure Exchange(X, Y : in out Float); --# derives X from Y & --# Y from X; --# post X = Y~ and Y = X~; end Exchange; CAB pre-condition H1: true. H2: a 1 = b. H3: b 1 = a. H4: a 2 = c. H5: c 2 = a 1. -> C1: a 2 = c. C2: b 1 = a. C3: c 2 = b. Note: Exchange has no preconditions so there are no intermediate check obligations. Thus, there is a single path (with a single VC) with hypotheses added for post-conditions of Exchange. Example File: ex0306b
44 GCD Verification GCD written as a recursive function function GCD(M, N: Integer) return Integer is begin if N = 0 then return M; else return GCD(N, M rem N); end if; end GCD 15, 9 9, 6 6, 3 3, 0
45 GCD Verification Iterative version of GCD procedure GCD(M, N : in Integer; G : out Integer); --# derives G from M,N; is C, D : Integer; R : Integer; begin C := M; D := N; while D /= 0 loop R := C rem D; C := D; D := R; end loop; G := C; end GCD; M,N are mode in, so we can t assign to them -- we need to introduce temporary variables.
46 GCD Verification Iterative version of GCD procedure GCD(M, N : in Integer; G : out Integer); --# derives G from M,N; is C, D : Integer; Q, R : Integer; begin C := M; D := N; while D /= 0 loop Divide(C, D, Q, R); C := R; Swap(C, D); end loop; G := C; end GCD; Utilized previously discussed procedures to illustrate treatment of procedure calls.
47 GCD Verification Adding a simple pre-condition and loop invariant procedure GCD(M, N : in Integer; G : out Integer); --# derives G from M,N; --# pre M >= 0 and N > 0; is C, D : Integer; Q, R : Integer; begin C := M; D := N; while D /= 0 loop --# assert C >= 0 and D > 0; Divide(C, D, Q, R); C := R; Swap(C, D); end loop; G := C; end GCD; We are not in a position to do full verification yet, but we at least need to prove enough to establish that the preconditions of Divide are satisfied. Example File: ex0306d
48 GCD Verification Summary of VC paths procedure GCD(M, N : in Integer; G : out Integer); --# derives G from M,N; --# pre M >= 0 and N > 0; is C, D : Integer; Q, R : Integer; begin C := M; D := N; while D /= 0 loop --# assert C >= 0 and D > 0; Divide(C, D, Q, R); C := R; Swap(C, D); end loop; G := C; end GCD; 1. From the start to the assertion, 2. From the assertion around the loop back to the assertion, 3. From the assertion to the check associated with the call of Divide, 4. From the start to the finish, 5. From the assertion to the finish. Example File: ex0306d
49 For You To Do (insert exercise here for applying the Examiner/Simplifier for VC generation and simplification for loop invariants and procedures)
50 Summary SPARK provides a powerful framework for verifying data/information flow partial & full functional correctness absence of run-time exceptions Framework is integrated directly via source code annotations
51 Acknowledgements The material in this lecture is based on Chapter 3 from High Integrity Software: The SPARK Approach to Safety and Security, John Barnes, Addison Wesley, 2003.
CIS 890: Safety Critical Systems
CIS 890: Safety Critical Systems Lecture: SPARK Contract Checking with Bakar Kiasan Copyright 2011, John Hatcliff. The syllabus and all lectures for this course are copyrighted materials and may not be
More informationSpark verification features
Spark verification features Paul Jackson School of Informatics University of Edinburgh Formal Verification Spring 2018 Adding specification information to programs Verification concerns checking whether
More informationLecture 1 Contracts. 1 A Mysterious Program : Principles of Imperative Computation (Spring 2018) Frank Pfenning
Lecture 1 Contracts 15-122: Principles of Imperative Computation (Spring 2018) Frank Pfenning In these notes we review contracts, which we use to collectively denote function contracts, loop invariants,
More informationLecture 1 Contracts : Principles of Imperative Computation (Fall 2018) Frank Pfenning
Lecture 1 Contracts 15-122: Principles of Imperative Computation (Fall 2018) Frank Pfenning In these notes we review contracts, which we use to collectively denote function contracts, loop invariants,
More informationPart II. Hoare Logic and Program Verification. Why specify programs? Specification and Verification. Code Verification. Why verify programs?
Part II. Hoare Logic and Program Verification Part II. Hoare Logic and Program Verification Dilian Gurov Props: Models: Specs: Method: Tool: safety of data manipulation source code logic assertions Hoare
More informationCIS 890: Safety-Critical Systems
CIS 890: Safety-Critical Systems Fall 2007 Lecture 1: Application Areas and SPARK Demo Copyright 2007, John Hatcliff. The syllabus and all lectures for this course are copyrighted materials and may not
More informationSoftwaretechnik. Program verification. Software Engineering Albert-Ludwigs-University Freiburg. June 30, 2011
Softwaretechnik Program verification Software Engineering Albert-Ludwigs-University Freiburg June 30, 2011 (Software Engineering) Softwaretechnik June 30, 2011 1 / 28 Road Map Program verification Automatic
More informationHybrid Verification in SPARK 2014: Combining Formal Methods with Testing
IEEE Software Technology Conference 2015 Hybrid Verification in SPARK 2014: Combining Formal Methods with Testing Steve Baird Senior Software Engineer Copyright 2014 AdaCore Slide: 1 procedure Array_Indexing_Bug
More informationSoftware Model Checking: Theory and Practice
Software Model Checking: Theory and Practice Lecture: Specification Checking - Specification Patterns Copyright 2004, Matt Dwyer, John Hatcliff, and Robby. The syllabus and all lectures for this course
More informationLecture Notes on Contracts
Lecture Notes on Contracts 15-122: Principles of Imperative Computation Frank Pfenning Lecture 2 August 30, 2012 1 Introduction For an overview the course goals and the mechanics and schedule of the course,
More informationA3. Programming Languages for Writing Safety-Critical Software
A3. Programming Languages for Writing Safety-Critical Software (a) Overview. (b) SPARK Ada. Critical Systems, CS 411, Lent term 2002, Sec. A3 A3-1 (a) Overview Important Factors for Programming Languages
More informationAXIOMS OF AN IMPERATIVE LANGUAGE PARTIAL CORRECTNESS WEAK AND STRONG CONDITIONS. THE AXIOM FOR nop
AXIOMS OF AN IMPERATIVE LANGUAGE We will use the same language, with the same abstract syntax that we used for operational semantics. However, we will only be concerned with the commands, since the language
More informationSoftwaretechnik. Program verification. Albert-Ludwigs-Universität Freiburg. June 28, Softwaretechnik June 28, / 24
Softwaretechnik Program verification Albert-Ludwigs-Universität Freiburg June 28, 2012 Softwaretechnik June 28, 2012 1 / 24 Road Map Program verification Automatic program verification Programs with loops
More informationLectures 20, 21: Axiomatic Semantics
Lectures 20, 21: Axiomatic Semantics Polyvios Pratikakis Computer Science Department, University of Crete Type Systems and Static Analysis Based on slides by George Necula Pratikakis (CSD) Axiomatic Semantics
More informationHoare Logic: Proving Programs Correct
Hoare Logic: Proving Programs Correct 17-654/17-765 Analysis of Software Artifacts Jonathan Aldrich Reading: C.A.R. Hoare, An Axiomatic Basis for Computer Programming Some presentation ideas from a lecture
More informationTesting! Prof. Leon Osterweil! CS 520/620! Spring 2013!
Testing Prof. Leon Osterweil CS 520/620 Spring 2013 Relations and Analysis A software product consists of A collection of (types of) artifacts Related to each other by myriad Relations The relations are
More informationFormal Methods. CITS5501 Software Testing and Quality Assurance
Formal Methods CITS5501 Software Testing and Quality Assurance Pressman, R. Software Engineering: A Practitioner s Approach. Chapter 28. McGraw-Hill, 2005 The Science of Programming, David Gries, 1981
More informationThe HOL-SPARK Program Verification Environment. Stefan Berghofer secunet Security Networks AG
The HOL-SPARK Program Verification Environment Stefan Berghofer secunet Security Networks AG August 15, 2018 Contents 1 Introduction 2 1.1 SPARK.............................. 2 1.2 HOL-SPARK...........................
More informationStatic program checking and verification
Chair of Software Engineering Software Engineering Prof. Dr. Bertrand Meyer March 2007 June 2007 Slides: Based on KSE06 With kind permission of Peter Müller Static program checking and verification Correctness
More informationLecture 18 Restoring Invariants
Lecture 18 Restoring Invariants 15-122: Principles of Imperative Computation (Spring 2018) Frank Pfenning In this lecture we will implement heaps and operations on them. The theme of this lecture is reasoning
More informationAn Annotated Language
Hoare Logic An Annotated Language State and Semantics Expressions are interpreted as functions from states to the corresponding domain of interpretation Operators have the obvious interpretation Free of
More informationProgram Verification. Aarti Gupta
Program Verification Aarti Gupta 1 Agenda Famous bugs Common bugs Testing (from lecture 6) Reasoning about programs Techniques for program verification 2 Famous Bugs The first bug: A moth in a relay (1945)
More informationSimulink 모델과 C/C++ 코드에대한매스웍스의정형검증툴소개 The MathWorks, Inc. 1
Simulink 모델과 C/C++ 코드에대한매스웍스의정형검증툴소개 2012 The MathWorks, Inc. 1 Agenda Formal Verification Key concept Applications Verification of designs against (functional) requirements Design error detection Test
More informationSemantics. There is no single widely acceptable notation or formalism for describing semantics Operational Semantics
There is no single widely acceptable notation or formalism for describing semantics Operational Describe the meaning of a program by executing its statements on a machine, either simulated or actual. The
More informationOutline. Introduction. 2 Proof of Correctness. 3 Final Notes. Precondition P 1 : Inputs include
Outline Computer Science 331 Correctness of Algorithms Mike Jacobson Department of Computer Science University of Calgary Lectures #2-4 1 What is a? Applications 2 Recursive Algorithms 3 Final Notes Additional
More informationSPARK A state-of-the-practice approach to the Common Criteria implementation requirements
SPARK A state-of-the-practice approach to the Common Criteria implementation requirements Roderick Chapman Praxis Critical Systems Limited, 20 Manvers Street, Bath BA1 1PX, U.K. +44 1225 466991 rod@praxis-cs.co.uk
More informationGNAT Pro Innovations for High-Integrity Development
GNAT Pro Innovations for High-Integrity Development José F. Ruiz Senior Software Engineer Ada Europe 2010, Valencia 2010-06-15 www.adacore.com Index Development environment Tools Static
More informationLecture Notes on Linear Search
Lecture Notes on Linear Search 15-122: Principles of Imperative Computation Frank Pfenning Lecture 5 January 28, 2014 1 Introduction One of the fundamental and recurring problems in computer science is
More informationAdvances in Programming Languages
T O Y H Advances in Programming Languages APL4: JML The Java Modeling Language David Aspinall (slides originally by Ian Stark) School of Informatics The University of Edinburgh Thursday 21 January 2010
More informationIntroduction to Axiomatic Semantics
Introduction to Axiomatic Semantics Meeting 10, CSCI 5535, Spring 2009 Announcements Homework 3 due tonight Homework 2 is graded 13 (mean), 14 (median), out of 21 total, but Graduate class: final project
More informationBounded Model Checking Of C Programs: CBMC Tool Overview
Workshop on Formal Verification and Analysis Tools, CFDVS, IIT-Bombay - Feb 21,2017 Bounded Model Checking Of C Programs: CBMC Tool Overview Prateek Saxena CBMC Developed and Maintained by Dr Daniel Kröning
More informationVerification Condition Generation
Verification Condition Generation Jorge Sousa Pinto Departamento de Informática / Universidade do Minho jsp@di.uminho.pt www.di.uminho.pt/~jsp Outline (1) - From Hoare Logic to VCGen algorithms: an architecture
More informationUNIT 3
UNIT 3 Presentation Outline Sequence control with expressions Conditional Statements, Loops Exception Handling Subprogram definition and activation Simple and Recursive Subprogram Subprogram Environment
More informationSPARK Examiner with Run-time Checker Generation of VCs for SPARK Programs
Status: Definitive 22 November 2005 Originator Team Approver Team Line Manager Copyright The contents of this manual are the subject of copyright and all rights in it are reserved. The manual may not be
More informationCSC313 High Integrity Systems/CSCM13 Critical Systems. CSC313/CSCM13 Chapter 2 1/ 221
CSC313 High Integrity Systems/CSCM13 Critical Systems CSC313/CSCM13 Chapter 2 1/ 221 CSC313 High Integrity Systems/ CSCM13 Critical Systems Course Notes Chapter 2: SPARK Ada Sect. 2 (f) Anton Setzer Dept.
More informationVerification Overview Testing Theory and Principles Testing in Practice. Verification. Miaoqing Huang University of Arkansas 1 / 80
1 / 80 Verification Miaoqing Huang University of Arkansas Outline 1 Verification Overview 2 Testing Theory and Principles Theoretical Foundations of Testing Empirical Testing Principles 3 Testing in Practice
More informationLecture Notes: Hoare Logic
Lecture Notes: Hoare Logic 17-654/17-754: Analysis of Software Artifacts Jonathan Aldrich (jonathan.aldrich@cs.cmu.edu) Lecture 3 1 Hoare Logic The goal of Hoare logic is to provide a formal system for
More informationVerifying Safety Property of Lustre Programs: Temporal Induction
22c181: Formal Methods in Software Engineering The University of Iowa Spring 2008 Verifying Safety Property of Lustre Programs: Temporal Induction Copyright 2008 Cesare Tinelli. These notes are copyrighted
More informationSoftware Model Checking: Theory and Practice
Software Model Checking: Theory and Practice Lecture: Specification Checking - Foundations Copyright 2004, Matt Dwyer, John Hatcliff, and Robby. The syllabus and all lectures for this course are copyrighted
More informationSymbolic Execution and Proof of Properties
Chapter 7 Symbolic Execution and Proof of Properties Symbolic execution builds predicates that characterize the conditions under which execution paths can be taken and the effect of the execution on program
More informationSemantic Analysis. CSE 307 Principles of Programming Languages Stony Brook University
Semantic Analysis CSE 307 Principles of Programming Languages Stony Brook University http://www.cs.stonybrook.edu/~cse307 1 Role of Semantic Analysis Syntax vs. Semantics: syntax concerns the form of a
More informationCIS 771: Software Specifications. Lecture: Alloy Whirlwind Tour (part A)
CIS 771: Software Specifications Lecture: Alloy Whirlwind Tour (part A) Copyright 2007, John Hatcliff, and Robby. The syllabus and all lectures for this course are copyrighted materials and may not be
More informationLecture 4 Searching Arrays
Lecture 4 Searching Arrays 15-122: Principles of Imperative Computation (Spring 2018) Frank Pfenning One of the fundamental and recurring problems in computer science is to find elements in collections,
More informationStatic Analysis Techniques
oftware Design (F28SD2): Static Analysis Techniques 1 Software Design (F28SD2) Static Analysis Techniques Andrew Ireland School of Mathematical and Computer Science Heriot-Watt University Edinburgh oftware
More informationCIS 771: Software Specifications
CIS 771: Software Specifications Lecture 11: Introduction to OCL & USE Copyright 2001-2002, Matt Dwyer, John Hatcliff, and Rod Howell. The syllabus and all lectures for this course are copyrighted materials
More informationFachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn. 4. Testing
4. vs. Model Checking (usually) means checking the correctness of source code Model Checking means verifying the properties of a model given in some formal (not program code) notation Attention: things
More informationWarm-Up Problem. Let be a set of well-formed Predicate logic formulas. Let be well-formed Predicate logic formulas. Prove or disprove the following.
Warm-Up Problem Let be a set of well-formed Predicate logic formulas Let be well-formed Predicate logic formulas Prove or disprove the following If then 1/35 Program Verification Carmen Bruni Lecture 18
More informationLecture 10 Design by Contract
CS 5959 Writing Solid Code Fall 2015 Nov-23 Lecture 10 Design by Contract Zvonimir Rakamarić University of Utah Design by Contract Also called assume-guarantee reasoning Developers annotate software components
More informationPrinciples of Programming Languages
Principles of Programming Languages Lesson 14 Type Checking Collaboration and Management Dana Fisman www.cs.bgu.ac.il/~ppl172 1 Type Checking We return to the issue of type safety we discussed informally,
More informationGlobal Optimization. Lecture Outline. Global flow analysis. Global constant propagation. Liveness analysis. Local Optimization. Global Optimization
Lecture Outline Global Optimization Global flow analysis Global constant propagation Liveness analysis Compiler Design I (2011) 2 Local Optimization Recall the simple basic-block optimizations Constant
More informationComputer Security Course. Midterm Review
Computer Security Course. Dawn Song Midterm Review In class: Logistics On time: 4:10-5:30pm Wed 1 8x11 page cheat sheet allowed Special requirements: see TA Part I, II, III Scope Software Security Secure
More informationCMSC 330: Organization of Programming Languages. Formal Semantics of a Prog. Lang. Specifying Syntax, Semantics
Recall Architecture of Compilers, Interpreters CMSC 330: Organization of Programming Languages Source Scanner Parser Static Analyzer Operational Semantics Intermediate Representation Front End Back End
More informationFormal Methods for Java
Formal Methods for Java Lecture 1: Introduction Jochen Hoenicke Software Engineering Albert-Ludwigs-University Freiburg October 26, 2011 Jochen Hoenicke (Software Engineering) Formal Methods for Java October
More informationChapter 3. Describing Syntax and Semantics
Chapter 3 Describing Syntax and Semantics Chapter 3 Topics Introduction The General Problem of Describing Syntax Formal Methods of Describing Syntax Attribute Grammars Describing the Meanings of Programs:
More informationCSC313 High Integrity Systems/CSCM13 Critical Systems. CSC313/CSCM13 Chapter 1 1/ 38
CSC313 High Integrity Systems/CSCM13 Critical Systems CSC313/CSCM13 Chapter 1 1/ 38 CSC313 High Integrity Systems/ CSCM13 Critical Systems Course Notes Chapter 1: Programming Languages for Writing Safety-Critical
More informationAn Eclipse Plug-in for Model Checking
An Eclipse Plug-in for Model Checking Dirk Beyer, Thomas A. Henzinger, Ranjit Jhala Electrical Engineering and Computer Sciences University of California, Berkeley, USA Rupak Majumdar Computer Science
More informationFundamentals of Software Engineering
Fundamentals of Software Engineering Reasoning about Programs - Selected Features Ina Schaefer Institute for Software Systems Engineering TU Braunschweig, Germany Slides by Wolfgang Ahrendt, Richard Bubel,
More informationReasoning About Imperative Programs. COS 441 Slides 10
Reasoning About Imperative Programs COS 441 Slides 10 The last few weeks Agenda reasoning about functional programming It s very simple and very uniform: substitution of equal expressions for equal expressions
More informationOutline. software testing: search bugs black-box and white-box testing static and dynamic testing
Outline 1 Verification Techniques software testing: search bugs black-box and white-box testing static and dynamic testing 2 Programming by Contract assert statements in Python using preconditions and
More informationAdaCore technologies
AdaCore technologies for CENELEC EN 50128 2011 Eric Perlade Technical Account Manager RSSRail 2017 CENELEC EN 50128:2011 CENELEC EN 50128 Main standards applicable to railway systems Complete System 50126
More informationIntroduction to Axiomatic Semantics (1/2)
#1 Introduction to Axiomatic Semantics (1/2) How s The Homework Going? Remember that you can t just define a meaning function in terms of itself you must use some fixed point machinery. #2 #3 Observations
More informationCSE 331 Software Design and Implementation. Lecture 3 Loop Reasoning
CSE 331 Software Design and Implementation Lecture 3 Loop Reasoning Zach Tatlock / Spring 2018 Reasoning about loops So far, two things made all our examples much easier: 1. When running the code, each
More informationTool Support for Design Inspection: Automatic Generation of Questions
Tool Support for Design Inspection: Automatic Generation of Questions Tim Heyer Department of Computer and Information Science, Linköping University, S-581 83 Linköping, Email: Tim.Heyer@ida.liu.se Contents
More information15-122: Principles of Imperative Computation (Section G)
15-122: Principles of Imperative Computation (Section G) Document 2 Solutions 0. Contracts This lecture was mainly about contracts and ensuring correctness of code. Josh Zimmerman There are 4 types of
More informationProof Carrying Code(PCC)
Discussion p./6 Proof Carrying Code(PCC Languaged based security policy instead of OS-based A mechanism to determine with certainity that it is safe execute a program or not Generic architecture for providing
More informationG Programming Languages - Fall 2012
G22.2110-003 Programming Languages - Fall 2012 Lecture 4 Thomas Wies New York University Review Last week Control Structures Selection Loops Adding Invariants Outline Subprograms Calling Sequences Parameter
More informationIntroduction to Axiomatic Semantics (1/2)
#1 Introduction to Axiomatic Semantics (1/2) How s The Homework Going? Remember: just do the counterexample guided abstraction refinement part of DPLL(T). If you notice any other errors, those are good
More informationCS/ENGRD 2110 Object-Oriented Programming and Data Structures Spring 2012 Thorsten Joachims. Lecture 10: Asymptotic Complexity and
CS/ENGRD 2110 Object-Oriented Programming and Data Structures Spring 2012 Thorsten Joachims Lecture 10: Asymptotic Complexity and What Makes a Good Algorithm? Suppose you have two possible algorithms or
More informationCS2 Algorithms and Data Structures Note 10. Depth-First Search and Topological Sorting
CS2 Algorithms and Data Structures Note 10 Depth-First Search and Topological Sorting In this lecture, we will analyse the running time of DFS and discuss a few applications. 10.1 A recursive implementation
More informationIII. Check if the divisors add up to the number. Now we may consider each of these tasks separately, assuming the others will be taken care of
Top-Down Design 1 Top-Down Design: A solution method where the problem is broken down into smaller sub-problems, which in turn are broken down into smaller subproblems, continuing until each sub-problem
More informationCOS 320. Compiling Techniques
Topic 5: Types COS 320 Compiling Techniques Princeton University Spring 2016 Lennart Beringer 1 Types: potential benefits (I) 2 For programmers: help to eliminate common programming mistakes, particularly
More informationChecking Program Properties with ESC/Java
Checking Program Properties with ESC/Java 17-654/17-765 Analysis of Software Artifacts Jonathan Aldrich 1 ESC/Java A checker for Java programs Finds null pointers, array dereferences Checks Hoare logic
More informationCS 161 Computer Security
Wagner Spring 2014 CS 161 Computer Security 1/27 Reasoning About Code Often functions make certain assumptions about their arguments, and it is the caller s responsibility to make sure those assumptions
More informationJava Software Solutions for AP Computer Science 3rd Edition, Lewis et al. 2011
A Correlation of AP Computer Science 3rd Edition, Lewis et al. 2011 To the INTRODUCTION This document demonstrates how AP (Advanced Placement) Computer Science, 3rd Edition 2011, Lewis et al. meets the
More informationWarm-Up Problem. 1. What is the definition of a Hoare triple satisfying partial correctness? 2. Recall the rule for assignment: x (assignment)
Warm-Up Problem 1 What is the definition of a Hoare triple satisfying partial correctness? 2 Recall the rule for assignment: x (assignment) Why is this the correct rule and not the following rule? x (assignment)
More informationFormal Verification! Prof. Leon Osterweil! Computer Science 520/620! Spring 2012!
Formal Verification Prof. Leon Osterweil Computer Science 520/620 Spring 2012 Relations and Analysis A software product consists of A collection of (types of) artifacts Related to each other by myriad
More informationCIS 890: Safety Critical Systems
CIS 890: Safety Critical Systems Lecture: Requirements Introduction Copyright 2011, John Hatcliff. The syllabus and all lectures for this course are copyrighted materials and may not be used in other course
More informationData Structures and Algorithms. Part 2
1 Data Structures and Algorithms Part 2 Werner Nutt 2 Acknowledgments The course follows the book Introduction to Algorithms, by Cormen, Leiserson, Rivest and Stein, MIT Press [CLRST]. Many examples displayed
More informationReview: Hoare Logic Rules
Review: Hoare Logic Rules wp(x := E, P) = [E/x] P wp(s;t, Q) = wp(s, wp(t, Q)) wp(if B then S else T, Q) = B wp(s,q) && B wp(t,q) Proving loops correct First consider partial correctness The loop may not
More informationProgram Verification. Program Verification 307/434
Program Verification Program Verification 307/434 Outline Introduction: What and Why? Pre- and Postconditions Conditionals while-loops and Total Correctness Arrays Program Verification Introduction 308/434
More information6. Hoare Logic and Weakest Preconditions
6. Hoare Logic and Weakest Preconditions Program Verification ETH Zurich, Spring Semester 07 Alexander J. Summers 30 Program Correctness There are many notions of correctness properties for a given program
More informationSEQUENCES, MATHEMATICAL INDUCTION, AND RECURSION
CHAPTER 5 SEQUENCES, MATHEMATICAL INDUCTION, AND RECURSION Alessandro Artale UniBZ - http://www.inf.unibz.it/ artale/ SECTION 5.5 Application: Correctness of Algorithms Copyright Cengage Learning. All
More informationObjectives. Chapter 19. Verification vs. validation. Topics covered. Static and dynamic verification. The V&V process
Objectives Chapter 19 Verification and Validation Assuring that a software system meets a user s need are to introduce software verification and validation (V&V) and to discuss the distinction between
More informationReasoning about programs
Reasoning about programs Last time Coming up This Thursday, Nov 30: 4 th in-class exercise sign up for group on moodle bring laptop to class Final projects: final project presentations: Tue Dec 12, in
More informationAlgorithms and Data Structures. Algorithms and Data Structures. Algorithms and Data Structures. Algorithms and Data Structures
Richard Mayr Slides adapted from Mary Cryan (2015/16) with some changes. School of Informatics University of Edinburgh ADS (2018/19) Lecture 1 slide 1 ADS (2018/19) Lecture 1 slide 3 ADS (2018/19) Lecture
More informationLast time. Reasoning about programs. Coming up. Project Final Presentations. This Thursday, Nov 30: 4 th in-class exercise
Last time Reasoning about programs Coming up This Thursday, Nov 30: 4 th in-class exercise sign up for group on moodle bring laptop to class Final projects: final project presentations: Tue Dec 12, in
More informationLecture 5 - Axiomatic semantics
Program Verification March 2014 Lecture 5 - Axiomatic semantics Lecturer: Noam Rinetzky Scribes by: Nir Hemed 1.1 Axiomatic semantics The development of the theory is contributed to Robert Floyd, C.A.R
More informationSardar Vallabhbhai Patel Institute of Technology (SVIT), Vasad M.C.A. Department COSMOS LECTURE SERIES ( ) (ODD) Code Optimization
Sardar Vallabhbhai Patel Institute of Technology (SVIT), Vasad M.C.A. Department COSMOS LECTURE SERIES (2018-19) (ODD) Code Optimization Prof. Jonita Roman Date: 30/06/2018 Time: 9:45 to 10:45 Venue: MCA
More informationThe Spark Approach. Regensburg
The Spark Approach to High Integrity Software Regensburg 18 June 2009 John Barnes Regensburg 1 What is software for? Does the software drive the hardware? Or Does the hardware implement the software? We
More informationData Structures and Algorithms Chapter 2
1 Data Structures and Algorithms Chapter 2 Werner Nutt 2 Acknowledgments The course follows the book Introduction to Algorithms, by Cormen, Leiserson, Rivest and Stein, MIT Press [CLRST]. Many examples
More informationAlgorithms and Data Structures
Algorithms and Data Structures or, Classical Algorithms of the 50s, 60s, 70s Richard Mayr Slides adapted from Mary Cryan (2015/16) with small changes. School of Informatics University of Edinburgh ADS
More informationViolations of the contract are exceptions, and are usually handled by special language constructs. Design by contract
Specification and validation [L&G Ch. 9] Design patterns are a useful way to describe program structure. They provide a guide as to how a program fits together. Another dimension is the responsibilities
More informationResearch Collection. Formal background and algorithms. Other Conference Item. ETH Library. Author(s): Biere, Armin. Publication Date: 2001
Research Collection Other Conference Item Formal background and algorithms Author(s): Biere, Armin Publication Date: 2001 Permanent Link: https://doi.org/10.3929/ethz-a-004239730 Rights / License: In Copyright
More informationBoca Raton Community High School AP Computer Science A - Syllabus 2009/10
Boca Raton Community High School AP Computer Science A - Syllabus 2009/10 Instructor: Ronald C. Persin Course Resources Java Software Solutions for AP Computer Science, A. J. Lewis, W. Loftus, and C. Cocking,
More informationLecture Notes on Queues
Lecture Notes on Queues 15-122: Principles of Imperative Computation Frank Pfenning and Jamie Morgenstern Lecture 9 February 14, 2012 1 Introduction In this lecture we introduce queues as a data structure
More informationChapter 3 (part 3) Describing Syntax and Semantics
Chapter 3 (part 3) Describing Syntax and Semantics Chapter 3 Topics Introduction The General Problem of Describing Syntax Formal Methods of Describing Syntax Attribute Grammars Describing the Meanings
More informationSystem Correctness. EEC 421/521: Software Engineering. System Correctness. The Problem at Hand. A system is correct when it meets its requirements
System Correctness EEC 421/521: Software Engineering A Whirlwind Intro to Software Model Checking A system is correct when it meets its requirements a design without requirements cannot be right or wrong,
More informationCoding and Unit Testing! The Coding Phase! Coding vs. Code! Coding! Overall Coding Language Trends!
Requirements Spec. Design Coding and Unit Testing Characteristics of System to be built must match required characteristics (high level) Architecture consistent views Software Engineering Computer Science
More informationCIS 771: Software Specifications. Lecture: Alloy Logic (part D)
CIS 771: Software Specifications Lecture: Alloy Logic (part D) Copyright 2007, John Hatcliff, and Robby. The syllabus and all lectures for this course are copyrighted materials and may not be used in other
More informationVerification Condition Generation via Theorem Proving
Verification Condition Generation via Theorem Proving John Matthews Galois Connections Inc. J Strother Moore University of Texas at Austin Sandip Ray University of Texas at Austin Daron Vroon Georgia Institute
More information