Formal Methods in Software Engineering Credit Hours: 3+0 By: Qaisar Javaid Assistant Professor.

Slides:



Advertisements
Similar presentations
Formal Specifications
Advertisements

1 Note content copyright © 2004 Ian Sommerville. NU-specific content © 2004 M. E. Kabay. All rights reserved. Formal Specification IS301 – Software Engineering.
25 February 2009Instructor: Tasneem Darwish1 University of Palestine Faculty of Applied Engineering and Urban Planning Software Engineering Department.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
1 Software Processes A Software process is a set of activities and associated results which lead to the production of a software product. Activities Common.
What is software? Computer programs and associated documentation
1 Chapter 4 - Part 1 Software Processes. 2 Software Processes is: Coherent (logically connected) sets of activities for specifying, designing, implementing,
Chapter 2 – Software Processes
ISNE101 Dr. Ken Cosh. Recap  We’ve been talking about Software…  Application vs System Software  Programming Languages  Vs Natural Languages  Syntax,
Software Processes Coherent sets of activities for specifying, designing, implementing and testing software systems.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 20 Slide 1 Critical systems development.
CS 355 – Programming Languages
Formal Methods in Software Engineering Credit Hours: 3+0 By: Qaisar Javaid Assistant Professor Formal Methods in Software Engineering1.
Formal Specification - Techniques for the unambiguous specification of software Objectives: To explain why formal specification techniques help discover.
Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page: Lecture.
Software Testing and Quality Assurance
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 10 Slide 1 Formal Specification.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 10 Slide 1 Formal Specification.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Process Models.
Software Requirements
©Ian Sommerville 2000 Software Engineering, 6th edition Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing.
©Ian Sommerville 2000Software Engineering, 6/e, Chapter 91 Formal Specification l Techniques for the unambiguous specification of software.
Describing Syntax and Semantics
School of Computer ScienceG53FSP Formal Specification1 Dr. Rong Qu Introduction to Formal Specification
L ECTURE 2 S OFTWARE P ROCESSES 1. O BJECTIVES To describe outline process models for requirements engineering, software development, testing and evolution.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 10 Slide 1 Formal Specification.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
MCA –Software Engineering Kantipur City College. Topics include  Formal Methods Concept  Formal Specification Language Test plan creation Test-case.
Software Process Activities. Process activities Real software processes are inter-leaved sequences of technical, collaborative and managerial activities.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 10 Slide 1 Critical Systems Specification 3 Formal Specification.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 10 Slide 1 Formal Specification.
Chapter 3 Software Processes.
Formal Methods 1. Software Engineering and Formal Methods  Every software engineering methodology is based on a recommended development process  proceeding.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 9 Slide 1 Formal Specification l Techniques for the unambiguous specification of software.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
Software Models (Cont.) 9/22/2015ICS 413 – Software Engineering1 -Component-based software engineering -Formal Development Model.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2000Software Engineering, Chapter 10 Slide 1 Chapter 10 Formal Specification.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 1 Software Processes (Chapter 3)
Software Processes lecture 8. Topics covered Software process models Process iteration Process activities The Rational Unified Process Computer-aided.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 1 Software Processes l Coherent sets of activities for specifying, designing,
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 9 Slide 1 Chapter 9 Formal Specifications.
Formal Methods in Software Engineering Credit Hours: 3+0 By: Qaisar Javaid Assistant Professor.
Overview of Formal Methods. Topics Introduction and terminology FM and Software Engineering Applications of FM Propositional and Predicate Logic Program.
Software Design Deriving a solution which satisfies software requirements.
WXGE6103 Software Engineering Process and Practice Formal Specification.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Requirements Engineering Methods for Requirements Engineering Lecture-30.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 19Slide 1 Chapter 19 Verification and Validation.
An Introduction to Software Engineering
SWEN 5130Requirements Engineering Algebraic Specification Slide 1 Algebraic Specification u Specifying abstract types in terms of relationships between.
Chapter 2 – Software Processes Lecture 1 Chapter 2 Software Processes1.
Software Engineering Chapter 10 Formal Specification Ku-Yaw Chang Assistant Professor Department of Computer Science and Information.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2000Software Engineering, Chapter 10 Slide 1 Chapter 10 Formal Specification.
Requirement Specification SRS document is a contract between the development team and the customer How do we communicate the Requirements to others? Firm.
1 SYS366 Week 2 - Lecture Visual Modeling and Process.
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini II. Software Life Cycle.
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini XVII. Verification and Validation.
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini IX. System Models (III)
IS301 – Software Engineering V:
Formal Specification.
Chapter3:Software Processes
Software Processes (a)
Formal Specifications
Department of Computer Science Abdul Wali Khan University Mardan
Algebraic Specification Software Specification Lecture 34
Activities of Formal Methods
Presentation transcript:

Formal Methods in Software Engineering Credit Hours: 3+0 By: Qaisar Javaid Assistant Professor

Formal Specification

Objectives l To explain why formal specification techniques help discover problems in system requirements l To describe the use of algebraic techniques for interface specification l To describe the use of model-based techniques for behavioural specification

Topics covered l Formal specification in the software process l Sub-system interface specification l Behavioural specification

Formal methods l Formal specification is part of a more general collection of techniques that are known as ‘formal methods’. l These are all based on mathematical representation and analysis of software. l Formal methods include Formal specification; Specification analysis and proof; Transformational development; Program verification.

Acceptance of formal methods l Formal methods have not become mainstream software development techniques as was once predicted Other software engineering techniques have been successful at increasing system quality. Hence the need for formal methods has been reduced; Market changes have made time-to-market rather than software with a low error count the key factor. Formal methods do not reduce time to market; The scope of formal methods is limited. They are not well- suited to specifying and analysing user interfaces and user interaction; Formal methods are still hard to scale up to large systems.

Use of formal methods l The principal benefits of formal methods are in reducing the number of faults in systems. l Consequently, their main area of applicability is in critical systems engineering. There have been several successful projects where formal methods have been used in this area. l In this area, the use of formal methods is most likely to be cost-effective because high system failure costs must be avoided.

Specification in the software process l Specification and design are inextricably intermingled. l Architectural design is essential to structure a specification and the specification process. l Formal specifications are expressed in a mathematical notation with precisely defined vocabulary, syntax and semantics.

Specification and design

Specification in the software process

Use of formal specification l Formal specification involves investing more effort in the early phases of software development. l This reduces requirements errors as it forces a detailed analysis of the requirements. l Incompleteness and inconsistencies can be discovered and resolved. l Hence, savings as made as the amount of rework due to requirements problems is reduced.

Cost profile l The use of formal specification means that the cost profile of a project changes There are greater up front costs as more time and effort are spent developing the specification; However, implementation and validation costs should be reduced as the specification process reduces errors and ambiguities in the requirements.

Development costs with formal specification

Specification techniques l Algebraic specification The system is specified in terms of its operations and their relationships. l Model-based specification The system is specified in terms of a state model that is constructed using mathematical constructs such as sets and sequences. Operations are defined by modifications to the system’s state.

Formal specification languages

Interface specification l Large systems are decomposed into subsystems with well-defined interfaces between these subsystems. l Specification of subsystem interfaces allows independent development of the different subsystems. l Interfaces may be defined as abstract data types or object classes. l The algebraic approach to formal specification is particularly well-suited to interface specification as it is focused on the defined operations in an object.

Sub-system interfaces

The structure of an algebraic specification

Specification components l Introduction Defines the sort (the type name) and declares other specifications that are used. l Description Informally describes the operations on the type. l Signature Defines the syntax of the operations in the interface and their parameters. l Axioms Defines the operation semantics by defining axioms which characterise behaviour.

Systematic algebraic specification l Algebraic specifications of a system may be developed in a systematic way Specification structuring; Specification naming; Operation selection; Informal operation specification; Syntax definition; Axiom definition.

Specification operations l Constructor operations. Operations which create entities of the type being specified. l Inspection operations. Operations which evaluate entities of the type being specified. l To specify behaviour, define the inspector operations for each constructor operation.

Operations on a list ADT l Constructor operations which evaluate to sort List Create, Cons and Tail. l Inspection operations which take sort list as a parameter and return some other sort Head and Length. l Tail can be defined using the simpler constructors Create and Cons. No need to define Head and Length with Tail.

List specification

Recursion in specifications l Operations are often specified recursively. l Tail (Cons (L, v)) = if L = Create then Create else Cons (Tail (L), v). Cons ([5, 7], 9) = [5, 7, 9] Tail ([5, 7, 9]) = Tail (Cons ( [5, 7], 9)) = Cons (Tail ([5, 7]), 9) = Cons (Tail (Cons ([5], 7)), 9) = Cons (Cons (Tail ([5]), 7), 9) = Cons (Cons (Tail (Cons ([], 5)), 7), 9) = Cons (Cons ([Create], 7), 9) = Cons ([7], 9) = [7, 9]

Interface specification in critical systems l Consider an air traffic control system where aircraft fly through managed sectors of airspace. l Each sector may include a number of aircraft but, for safety reasons, these must be separated. l In this example, a simple vertical separation of 300m is proposed. l The system should warn the controller if aircraft are instructed to move so that the separation rule is breached.

A sector object l Critical operations on an object representing a controlled sector are Enter. Add an aircraft to the controlled airspace; Leave. Remove an aircraft from the controlled airspace; Move. Move an aircraft from one height to another; Lookup. Given an aircraft identifier, return its current height;

Primitive operations l It is sometimes necessary to introduce additional operations to simplify the specification. l The other operations can then be defined using these more primitive operations. l Primitive operations Create. Bring an instance of a sector into existence; Put. Add an aircraft without safety checks; In-space. Determine if a given aircraft is in the sector; Occupied. Given a height, determine if there is an aircraft within 300m of that height.

Sector specification (1)