1 Formal Methods in SE Qaisar Javaid Assistant Professor Lecture 05.

Slides:



Advertisements
Similar presentations
1 Verification by Model Checking. 2 Part 1 : Motivation.
Advertisements

The Quest for Correctness Joseph Sifakis VERIMAG Laboratory 2nd Sogeti Testing Academy April 29th 2009.
Modeling Software Systems Lecture 2 Book: Chapter 4.
Formal Methods and Testing Goal: software reliability Use software engineering methodologies to develop the code. Use formal methods during code development.
Introducing Formal Methods, Module 1, Version 1.1, Oct., Formal Specification and Analytical Verification L 5.
1 Model checking. 2 And now... the system How do we model a reactive system with an automaton ? It is convenient to model systems with Transition systems.
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
Abstraction and Modular Reasoning for the Verification of Software Corina Pasareanu NASA Ames Research Center.
Testing and Quality Assurance
LIFE CYCLE MODELS FORMAL TRANSFORMATION
Software Failure: Reasons Incorrect, missing, impossible requirements * Requirement validation. Incorrect specification * Specification verification. Faulty.
Software Reliability CIS 640 Adapted from the lecture notes by Doron Pelel (
Formal Methods in Software Engineering Credit Hours: 3+0 By: Qaisar Javaid Assistant Professor Formal Methods in Software Engineering1.
© Janice Regan, CMPT 102, Sept CMPT 102 Introduction to Scientific Computer Programming The software development method algorithms.
Algorithms and Problem Solving-1 Algorithms and Problem Solving.
Algorithms and Problem Solving. Learn about problem solving skills Explore the algorithmic approach for problem solving Learn about algorithm development.
ECE Synthesis & Verification1 ECE 667 Spring 2011 Synthesis and Verification of Digital Systems Verification Introduction.
Modeling Software Systems Lecture 2 Book: Chapter 4.
Describing Syntax and Semantics
School of Computer ScienceG53FSP Formal Specification1 Dr. Rong Qu Introduction to Formal Specification
1 Formal Engineering of Reliable Software LASER 2004 school Tutorial, Lecture1 Natasha Sharygina Carnegie Mellon University.
SE-565 Software System Requirements More UML Diagrams.
Software Integration and Documenting
02/06/05 “Investigating a Finite–State Machine Notation for Discrete–Event Systems” Nikolay Stoimenov.
Cheng/Dillon-Software Engineering: Formal Methods Model Checking.
1 Thread Synchronization: Too Much Milk. 2 Implementing Critical Sections in Software Hard The following example will demonstrate the difficulty of providing.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
Benjamin Gamble. What is Time?  Can mean many different things to a computer Dynamic Equation Variable System State 2.
Reliable Design of Safety Critical Systems Dr. Abhik Roychoudhury School of Computing
Overview of Formal Methods. Topics Introduction and terminology FM and Software Engineering Applications of FM Propositional and Predicate Logic Program.
B. Fernández, D. Darvas, E. Blanco Formal methods appliedto PLC code verification Automation seminar CERN – IFAC (CEA) 02/06/2014.
Software Engineering Research paper presentation Ali Ahmad Formal Approaches to Software Testing Hierarchal GUI Test Case Generation Using Automated Planning.
Fundamental Programming: Fundamental Programming K.Chinnasarn, Ph.D.
1 Introduction to Software Engineering Lecture 1.
Formal Verification Lecture 9. Formal Verification Formal verification relies on Descriptions of the properties or requirements Descriptions of systems.
Introduction to Problem Solving. Steps in Programming A Very Simplified Picture –Problem Definition & Analysis – High Level Strategy for a solution –Arriving.
Advanced Topics in Software Engineering Marjan Sirjani Tehran University Faculty of Engineering ECE Department Tehran,
Safety-Critical Systems 5 Testing and V&V T
CIS 842: Specification and Verification of Reactive Systems Lecture 1: Course Overview Copyright 2001, Matt Dwyer, John Hatcliff, and Radu Iosif. The.
Basic Concepts of Component- Based Software Development (CBSD) Model-Based Programming and Verification.
COP4020 Programming Languages Introduction to Axiomatic Semantics Prof. Robert van Engelen.
Data Structures and Algorithms Dr. Tehseen Zia Assistant Professor Dept. Computer Science and IT University of Sargodha Lecture 1.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Verification & Validation By: Amir Masoud Gharehbaghi
Software Engineering1  Verification: The software should conform to its specification  Validation: The software should do what the user really requires.
CSCI1600: Embedded and Real Time Software Lecture 28: Verification I Steven Reiss, Fall 2015.
Static Techniques for V&V. Hierarchy of V&V techniques Static Analysis V&V Dynamic Techniques Model Checking Simulation Symbolic Execution Testing Informal.
Formal Methods in Software Engineering1 Today’s Agenda  Mailing list  Syllabus  Introduction.
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
Automated Formal Verification of PLC (Programmable Logic Controller) Programs
From Natural Language to LTL: Difficulties Capturing Natural Language Specification in Formal Languages for Automatic Analysis Elsa L Gunter NJIT.
Agenda  Quick Review  Finish Introduction  Java Threads.
INTRODUCTION TO COMPUTER PROGRAMMING(IT-303) Basics.
Algorithms and Problem Solving. Learn about problem solving skills Explore the algorithmic approach for problem solving Learn about algorithm development.
Copyright 1999 G.v. Bochmann ELG 7186C ch.1 1 Course Notes ELG 7186C Formal Methods for the Development of Real-Time System Applications Gregor v. Bochmann.
Algorithms and Problem Solving
Formal methods: Lecture
Object-Oriented Software Engineering Using UML, Patterns, and Java,
About the Presentations
Automatic Verification
Software Design Methodology
Gabor Madl Ph.D. Candidate, UC Irvine Advisor: Nikil Dutt
IS 2935: Developing Secure Systems
Test Case Test case Describes an input Description and an expected output Description. Test case ID Section 1: Before execution Section 2: After execution.
Software Verification and Validation
Software Verification and Validation
Algorithms and Problem Solving
Formal Methods in software development
Software Verification and Validation
Presentation transcript:

1 Formal Methods in SE Qaisar Javaid Assistant Professor Lecture 05

2 Some related books: Also:Mainly:

3 Goal: software reliability Use software engineering methodologies to develop the code. Use formal methods during code development

4 What are formal methods? Techniques for analyzing systems, based on some mathematics. This does not mean that the user must be a mathematician. Some of the work is done in an informal way, due to complexity.

5 Examples for FM Deductive verification: Using some logical formalism, prove formally that the software satisfies its specification. Model checking: Use some software to automatically check that the software satisfies its specification. Testing: Check executions of the software according to some coverage scheme.

6 Typical situation: Boss: Mark, I want that the new internet marketing software will be flawless. OK? Mark: Hmmm. Well,..., Aham, Oh! Ah??? Where do I start? Bob: I have just the solution for you. It would solve everything.

7 Some concerns Which technique? Which tool? Which experts? What limitations? What methodology? At which points? How expensive? How many people? Needed expertise. Kind of training. Size limitations. Exhaustiveness. Reliability. Expressiveness. Support.

8 Badmouth Formal methods can only be used by mathematicians. The verification process is itself prone to errors, so why bother? Using formal methods will slow down the project.

9 Some answers... Formal methods can only be used by mathematicians. Wrong. They are based on some math but the user should not care. The verification process is itself prone to errors, so why bother? We opt to reduce the errors, not eliminate them. Using formal methods will slow down the project. Maybe it will speed it up, once errors are found earlier.

10 Some exaggerations Automatic verification can always find errors. Deductive verification can show that the software is completely safe. Testing is the only industrial practical method.

11 Our approach Learn several methods (deductive verification, model checking, testing process algebra). Learn advantages and limitations, in order to choose the right methods and tools. Learn how to combine existing methods.

12 Emphasis The process: Selecting the tools, Modeling, Verification, Locating errors. Use of tools: Hands on. PVS, SPIN Visual notation: Statecharts, MSCs, UML.

13 Some emphasis The process of selecting and using formal methods. The appropriate notation. In particular, visual notation. Hands-on experience with tools.

14 The unbearable easiness of grading During class, choose some small project in groups, e.g., Explore some examples using tools. Implementing a simple algorithm. Dealing with new material. or covering advanced subject. - Office presentation (1 hour). - Written description (2-3 pages + computer output or 6-10 pages). - Class presentation ( hours per group).

15 Example topics Project: Verify some example using some tools. Communication protocols. Mutual exclusion. Advanced topics: Abstractions. Reductions. Partitions. Static analysis. Verifying pushdown automata. Verifying security protocols.

16 Where do we start? Boss: Mark, can you verify this for me? Mark: OK, first I have to...

17 Things to do Check the kind of software to analyze. Choose methods and tools. Express system properties. Model the software. Apply methods. Obtain verification results. Analyze results. Identify errors. Suggest correction.

18 Different types of software Sequential. Concurrent. Distributed. Reactive. Protocols. Abstract algorithms. Finite state.

19 Specification: Informal, textual, visual The value of x will be between 1 and 5, until some point where it will become 7. In any case it will never be negative. (1 =0)) 1<=x<=5 X=7 X>=0

20 Verification methods Finite state machines. Apply model checking. Apply deductive verification (theorem proving). Program too big, too complicated. Apply testing techniques. Apply a combination of the above!

21 Modeling Use the program text. Translate to a programming language embedded in some proof system. Translate to some notation (transition system). Translate to finite automata. Use visual notation. Special case: black box system.

22 Modeling Software Systems for Analysis

23 Modelling and specification for verification and validation How to specify what the software is supposed to do? Can we use the UML model or parts of it? How to model it in a way that allows us to check it?

24 Systems of interest Sequential systems. Concurrent systems (multi-threaded). 1. Distributive systems. 2. Reactive systems. 3. Embedded systems (software + hardware).

25 Sequential systems. Perform some computational task. Have some initial condition, e.g.,  0  i  n A[i] integer. Have some final assertion, e.g.,  0  i  n-1 A[i]  A[i+1]. (What is the problem with this spec?) Are supposed to terminate.

26 Concurrent Systems Involve several computation agents. Termination may indicate an abnormal event (interrupt, strike). May exploit diverse computational power. May involve remote components. May interact with users (Reactive). May involve hardware components (Embedded).

27 Problems in modeling systems Representing concurrency: - Allow one transition at a time, or - Allow coinciding transitions. Granularity of transitions. Assignments and checks? Application of methods? Global (all the system) or local (one thread at a time) states.

28 Modeling. The states based model. V={v 0,v 1,v 2, …} - a set of variables, over some domain. p(v 0, v 1, …, v n ) - a parametrized assertion, e.g., v 0 =v 1 +v 2 /\ v 3 >v 4. A state is an assignment of values to the program variables. For example: s= For predicate (first order assertion) p: p(s) is p under the assignment s. Example: p is x>y /\ y>z. s=. Then we have 4>3 /\ 3>5, which is false.

29 State space The state space of a program is the set of all possible states for it. For example, if V={a, b, c} and the variables are over the naturals, then the state space includes:,,, …

30 Atomic Transitions Each atomic transition represents a small piece of code such that no smaller piece of code is observable. Is a:=a+1 atomic? In some systems, e.g., when a is a register and the transition is executed using an inc command.

31 Non atomicity Execute the following when a=0 in two concurrent processes: P 1 :a=a+1 P 2 :a=a+1 Result: a=2. Is this always the case? Consider the actual translation: P 1 :load R1,a inc R1 store R1,a P 2 :load R2,a inc R2 store R2,a a may be also 1.

32 Scenario P 1 :load R1,a inc R1 store R1,a P 2 :load R2,a inc R2 store R2,a a=0 R1=0 R2=0 R1=1 R2=1 a=1

33 Representing transitions Each transition has two parts: The enabling condition: a predicate. The transformation: a multiple assignment. For example: a>b  (c,d ):=(d,c ) This transition can be executed in states where a>b. The result of executing it is switching the value of c with d.

34 Initial condition A predicate I. The program can start from states s such that I (s) holds. For example: I (s)=a >b /\ b >c.

35 A transition system A (finite) set of variables V over some domain. A set of states . A (finite) set of transitions T, each transition e  t has an enabling condition e, and a transformation t. An initial condition I.

36 Example V={a, b, c, d, e}.  : all assignments of natural numbers for variables in V. T={c >0  (c,e):=(c -1,e +1), d >0  (d,e):=(d -1,e +1)} I: c =a /\ d =b /\ e =0 What does this transition system do?