SD3049 Formal Methods Module Leader Dr Aaron Kans Module website www.homepages.uel.ac.uk/A.Kans/sd3049.

Slides:



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

Design by Contract.
25 February 2009Instructor: Tasneem Darwish1 University of Palestine Faculty of Applied Engineering and Urban Planning Software Engineering Department.
Formal Modelling of Reactive Agents as an aggregation of Simple Behaviours P.Kefalas Dept. of Computer Science 13 Tsimiski Str Thessaloniki Greece.
CS 501: Software Engineering Fall 2000 Lecture 2 The Software Process.
CSE 470 : Software Engineering The Software Process.
Chapter 3 Process Models
LIFE CYCLE MODELS FORMAL TRANSFORMATION
Software system modeling
ISBN Chapter 3 Describing Syntax and Semantics.
Requirements and Design
Formal Methods in Software Engineering Credit Hours: 3+0 By: Qaisar Javaid Assistant Professor Formal Methods in Software Engineering1.
Shaoying Liu Department of Computer Science
1 SWE Introduction to Software Engineering Lecture 23 – Architectural Design (Chapter 13)
CSC 402 Requirements Engineering 1. 2 Problem Definition Requirements Definition informal statement of need for system natural language statement of what.
CS 501: Software Engineering
CS 425/625 Software Engineering Software Processes
©Ian Sommerville 2000Software Engineering, 6/e, Chapter 91 Formal Specification l Techniques for the unambiguous specification of software.
1 CMSC 132: Object-Oriented Programming II Nelson Padua-Perez William Pugh Department of Computer Science University of Maryland, College Park.
Describing Syntax and Semantics
School of Computer ScienceG53FSP Formal Specification1 Dr. Rong Qu Introduction to Formal Specification
1 SWE Introduction to Software Engineering Lecture 11 - Requirements Engineering Processes.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 10 Slide 1 Formal Specification.
© The McGraw-Hill Companies, 2006 Chapter 7 Implementing classes.
1 CMPT 275 Software Engineering Requirements Analysis Process Janice Regan,
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 10 Slide 1 Critical Systems Specification 3 Formal Specification.
Formal Methods 1. Software Engineering and Formal Methods  Every software engineering methodology is based on a recommended development process  proceeding.
1COM6030 Systems Analysis and Design © University of Sheffield 2005 COM 6030 Software Analysis and Design Lecture 4 - System modelling Dr Richard Clayton.
Real-Time Software Design Yonsei University 2 nd Semester, 2014 Sanghyun Park.
©The McGraw-Hill Companies, Inc. Permission required for reproduction or display. Chapter Chapter 1 Introduction to Object-Oriented Programming and.
Compositional IS Development Framework Application Domain Application Domain Pre-existing components, legacy systems Extended for CD (ontologies) OAD Methods.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 9 Slide 1 Formal Specification l Techniques for the unambiguous specification of software.
Software Models (Cont.) 9/22/2015ICS 413 – Software Engineering1 -Component-based software engineering -Formal Development Model.
Course: Software Engineering © Alessandra RussoUnit 1 - Introduction, slide Number 1 Unit 1: Introduction Course: C525 Software Engineering Lecturer: Alessandra.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
1COM6030 Systems Analysis and Design © University of Sheffield 2005 COM 6030 Software Analysis and Design Lecture 10 – Classes and operations Dr Richard.
Software Engineering Management Lecture 1 The Software Process.
Introduction to Formal Methods Based on Jeannette M. Wing. A Specifier's Introduction to Formal Methods. IEEE Computer, 23(9):8-24, September,
Overview of Formal Methods. Topics Introduction and terminology FM and Software Engineering Applications of FM Propositional and Predicate Logic Program.
WXGE6103 Software Engineering Process and Practice Formal Specification.
Requirements Engineering Methods for Requirements Engineering Lecture-30.
Chapter 4 프로세스 모델 Process Models
SD3049 Formal Methods. Formal Methods Module Leader Dr Aaron Kans
1 CS 501 Spring 2004 CS 501: Software Engineering Lecture 2 Software Processes.
Formal Methods.
Formal Methods in Software Engineering Credit Hours: 3+0 By: Qaisar Javaid Assistant Professor.
November 2003J. B. Wordsworth: J3ISDQR41 Information Systems Development Quality and Risk (4)
PROGRAMMING PRE- AND POSTCONDITIONS, INVARIANTS AND METHOD CONTRACTS B MODULE 2: SOFTWARE SYSTEMS 13 NOVEMBER 2013.
Formal Methods in Software Engineering1 Today’s Agenda  Mailing list  Syllabus  Introduction.
Requirements Engineering Methods for Requirements Engineering Lecture-31.
Requirement Analysis SOFTWARE ENGINEERING. What are Requirements? Expression of desired behavior Deals with objects or entities, the states they can be.
Lectures 2 & 3: Software Process Models Neelam Gupta.
CSCI 383 Object-Oriented Programming & Design Lecture 7 Martin van Bommel.
CLASSES AND OBJECTS Chapter 3 : constructor, Separate files, validating data.
A framework that describes the activities performed at each stage of a software development project. A life-cycle or a software process is the organisational.
Formal Methods. What Are Formal Methods Formal methods refers to a variety of mathematical modeling techniques that are applicable to computer system.
Requirement Specification SRS document is a contract between the development team and the customer How do we communicate the Requirements to others? Firm.
Software Design and Development Development Methodoligies Computing Science.
1 M206 Chapter 31: An Overview of Software Development 1.Defining the problem 2.Analyzing the requirement – constructing initial structural model 3.Analyzing.
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini VII. System Specification (I)
Formal Specification.
Introduction to Formal Methods
Software Engineering Management
Lecture 3 Prescriptive Process Models
Software Design Methodology
Advantages of Formal Methods
Department of Computer Science Abdul Wali Khan University Mardan
Software system modeling
Activities of Formal Methods
Presentation transcript:

SD3049 Formal Methods Module Leader Dr Aaron Kans Module website

What is this module about? Developing software like an ENGINEER

High Integrity Software Development By the end of this lecture you should be able to: define the term high integrity software; distinguish between different types of critical software; identify the weaknesses of testing as an approach to software verification; identify the weaknesses of natural language specifications; distinguish between formal and informal methods of software development; describe what is meant by the term lightweight formal methods.

Introduction Often software is integrated into a mechanical or electronic system Such software is known as embedded software Costs of software failure in these systems can be dangerously high Require a higher degree of confidence in the correctness of the software. Such software is known as HIGH INTEGRITY SOFTWARE.

Critical Software business critical software mission critical software safety critical software

Integrity Levels Integrity level 5 Integrity level 1

Some high profile examples of high integrity software failures The loss of NASA’s Mars Climate Orbitor in November 1999 The crash of the European space agencies Ariane5 rocket in July 1996 Radiation overdoses administered by the Therac-25 machine in the USA during the 1980’s.

CLIENT DEVELOPER FINAL APPLICATION TESTING SPECIFICATION The importance of the specification

Limitations of Testing 1.Testing cannot take place until some implementation is available. 2.Testing can only help to uncover errors - it cannot guarantee the absence of them. 3.Testing is always carried out with respect to requirements as laid down in the specification.

UML: a review The Unified Modelling Language (UML) notation is used to specify and design systems according to the principles of object-oriented development BankAccount accountNumber: String accountName: String balance: Real deposit (Real) withdraw (Real) : Boolean currentBalance(): Real

Weakness of natural language specifications Withdraw: “Receives a requested amount to withdraw from the bank account and, if there are sufficient funds in the account, meets the request. Returns a boolean value indicating success or failure of the attempt to withdraw money from the account.” Natural language descriptions do not have a fixed meaning, they are ambiguous. These notations do not have a fixed semantics

Incomplete specifications A specification can be considered incomplete when the behaviour is not completely defined. Withdraw: “Receives a requested amount to withdraw from the bank account and, if there are sufficient funds in the account, meets the request. Returns a boolean value indicating success or failure of the attempt to withdraw money from the account.”

Inconsistent specifications A specification is inconsistent when it contains within it contradictions. Withdraw: “Receives a requested amount to withdraw from the bank account and, if there are sufficient funds in the account, meets the request. Returns a boolean value indicating success or failure of the attempt to withdraw money from the account.” OVERDRAFT?

Formal languages It is desirable to use a specification notation with a fixed, unambiguous, semantics. Notations that have a fixed semantics are known as formal notations, or formal languages. A fixed semantics is achieved by defining a language in a completely unambiguous way using a mathematical framework.

Formal Methods initial formal specification 1st transformation 2nd transformation nth transformation final program A formal method includes a proof system for demonstrating that each transformation preserves the formal meaning captured in the previous step.

Advantages of formal methods formal specifications can help considerably in generating suitable test cases; the discipline required in producing a formal specification allows for feedback on system specifications at early development stages, increasing confidence that the specification accurately captures the real system requirements; important properties of the initial specification can be checked mathematically and incorporated as run-time checks in the final program; proofs can help uncover design errors as soon as they are made, rather than having to wait for testing of the final implementation; a proof of program correctness can be constructed that is a much more robust method of achieving program correctness than is testing alone.

Classifying formal methods AlgebraicModel-based Sequential systems Larch Vienna Development Method (VDM) Z B Concurrent Systems Calculus of Communicating Systems (CCS) OBJ Prototype Verification System (PVS) Concurrent Sequential Processes (CSP)

Lightweight Formal Methods INFORMAL SPECIFICATION (UML class diagram) FORMAL SPECIFICATION (VDM specification) IMPLEMENTATION (Java class)