Formal Methods in Software Development: An Introduction, Slides of Software Engineering

An overview of formal methods in software development, focusing on formal specifications, their role in the development of software systems, and their use in ensuring software correctness. It covers topics such as logical theories as specifications, specifying system states and operations, object-oriented systems, and the use of formal languages like z and object-z. The document also includes a case study on the therac-25 radiation therapy machine disaster, highlighting the importance of formal specifications in preventing software-related disasters.

Typology: Slides

2023/2024

Available from 04/26/2024

razaroghani
razaroghani 🇵🇰

4.5

(4)

151 documents

1 / 18

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Ch-01: Intro. To Formal Methods
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12

Partial preview of the text

Download Formal Methods in Software Development: An Introduction and more Slides Software Engineering in PDF only on Docsity!

Ch-01: Intro. To Formal Methods

Aims and Objectives

It aims to illustrate:

Basic approaches to formal specification.

e.g.: “state-based” and “class-based” approaches

This part of the course is about formal specifications and their role in (formal)

development of software systems.

Derivations of formal specifications from informal requirements.

Refinement of formal specifications into program structures and

specification of programs.

Basic techniques for reasoning about programs and their

correctness with respect to the specifications.

i.e. product meets its requirements

Radiation therapy machine massively overdosed 6 patients.

A Computer-initiated Disaster: Therac-

Three turntable positions:

Electron beam generator

Accessory turntable

Patient

Low energy electrons

High energy electrons

“Field light” for

positioning purposes.

Software fault :

turntable in wrong positionunsafe high radiation dose

Unsafe situations

A high energy electron beam can be needed but mustn’t hit patient directly.

  • (^) Predecessors Therac-6, Therac-20 had hardware interlocks.

Therac-25 relied only on software checks.

  • (^) Unsafe situations weren’t detected and patients were killed.
  • (^) Main Cause :

Unsafe architecture & lack of specs  software bugs

High electron beam + turntable in position 1 or 3 = unsafe

Lesson Learned

Formal specifications and rigorous (careful) analysis of

existing software with respect to the new system

architecture would have highlighted the problems.

A disaster would have been avoided.

What is a specification

Description of a (computer) system, which:

is precise;

defines the behaviour of the system;

( what, not how )

requires an understanding of the problem;

( why )

has formal semantics and reasoning laws.

( quality & correctness )

Example

(A formal specification in BNF language)

::= |

::= {}

::= |

::= |

. | . |

. |

::= E

::= |

::= + | -

Good numbers: 1E5, 0.5, 1.5E-5, 1. ,.

Bad number: E5, 1.5E5.

BNF

In computer science, BNF (Backus

Normal Form or Backus–Naur Form) is

one of the two main notation

techniques for context-free grammars ,

often used to describe the syntax

of languages used in computing, such

as computer programming languages ,

document formats, instruction sets and

communication protocols.

Specification as understanding

Specifying includes capturing requirements:

coming to understand what the customer wants.

Requirements

  • (^) Not fully defined by the user.
  • (^) Written in prose descriptions.
  • (^) Not well structured and with repetitions.

Specifications

  • (^) Formally define key understanding (“why”).
  • (^) Provide better structured documents

(with no repetitions).

Support software maintenance.

Quality & Correctness

Specification brings together

quality software and correctness.

Quality software:

Building the right system:

(system fits its purposes)

Correctness:

Building the system right:

(system conforms with the

specs)

Formal semantics and reasoning laws

How can we use specifications?

Modelling

As mathematical models, to describe and predict the intended (expected)

behaviour of the system. It helps focusing on some aspects of the system, leaving

out inessential details.

Design

To support constructive approaches to design (e.g., “bottom-up”). Specifications

would provide a description of what each building block does and enable us to

calculate how the whole system will behave once the blocks are combined.

Verification

To show the final system does what we intend. Construct formal proofs, based

on specification and program test, to show that the system satisfies its specification

requirements.

Formal languages

Z is one of the languages commonly used for writing state-based specifications.

It contains a lot of special-purpose notation. Object-Z is an extension of Z, which

facilitates the definition of class-based formal specifications.

We will

  • Borrow some good notational ideas from Z and apply to classical logic.
  • Learn in more details some main features of Object-Z.
  • Use conventional logic to define program specifications

Results:

  • Write state-based specifications that look like Z specifications.
  • Write class-based Object-Z specifications.
  • Map Object-Z specifications into (Java) program specifications.
  • (^) Use basic techniques for reasoning about correctness of Java programs.