Page 1

Formal Methods Module #1 FM Basic Concepts

Before that..  Software requirement ?  Software process?  System model?


Software Requirements ď ŽDescriptions and

specifications of a system

TYPES OF REQUIREMENT  User requirements  Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.  System requirements  A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor.  Software specification  A detailed software description which can serve as a basis for a design or implementation. Written for developers.

What is a software process?  It is a set of activities whose goal is the development

or evolution of software  Generic activities in all software processes are: 

  

Specification - what the system should do and its development constraints Development - production of the software system Validation - checking that the software is what the customer wants Evolution - changing the software in response to changing demands

What is a software process model?  A representation of a software process,

presented from a specific perspective  Examples of process perspectives are   

Workflow perspective - sequence of activities Data-flow perspective - information flow Role/action perspective - who does what

Software process model? Generic process models    

Waterfall Evolutionary development Formal transformation Integration from reusable components

Waterfall model Requirements definition System and software design Implementation and unit testing Integr ation and system testing Operation and maintenance

Evolutionary development Concurr ent activities

Outline description


Initial version


Intermediate versions


Final version

Spiral model of the software process Determine objectives alternatives and constraints

Risk analysis

Evaluate alternatives identify, resolve risks

Risk analysis Risk analysis

REVIEW Requirements plan Life-cycle plan

Development plan

Plan next phase

Integration and test plan

Prototype 3 Prototype 2

Risk analy sis Prototype 1

Operational protoype

Simulations, models, benchmarks Concept of Operation

S/W requirements

Requirement validation

Product design

Detailed design

Code Unit test Design V&V Integr ation test Acceptance test Develop, verify Service next-level product

Formal systems development

Requirements definition

Formal specification

Formal transformation

Integration and system testing

System Models (Ref: Chap. 7 Somm)

System models  System models  are Abstract

Descriptions of systems whose requirements are being analysed  Why model?

System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers

System modelling  Different models present the system from

different perspectives :   

External perspective showing the system‟s context or environment. Behavioural perspective showing the behaviour of the system. Structural perspective showing the system or data architecture.

Level of formalization

Model types  Data processing model showing how the    

data is processed at different stages Composition model showing how entities are composed of other entities Architectural model showing principal subsystems Classification model showing how entities have common characteristics Stimulus/response model showing the system‟s reaction to events

Data flow diagrams  DFDs model the system from a functional

perspective.  Tracking and documenting how the data associated with a process is helpful to develop an overall understanding of the system.  Data flow diagrams may also be used in showing the data exchange between a system and other systems in its environment.


Full power do: set power = 600 Timer

Waiting do: display time

Half power

Number Full power Half power

Door closed

Timer Door open Half power do: set power = 300

Operation do: operate oven

Set time do: get number exit: set time

Door closed Disabled do: display 'Waiting'

Cancel Start Enabled do: display 'Ready'

Door open

Waiting do: display time

THE UNIFIED MODELLING LANGUAGE  UML is devised by the developers of widely

used object-oriented analysis and design methods  Has become an effective standard for objectoriented modelling  Notation 

 

Object classes are rectangles with the name at the top, attributes in the middle section and operations in the bottom section Relationships between object classes (known as associations) are shown as lines linking objects Inheritance is referred to as generalisation and is shown „upwards‟ rather than „downwards‟ in a hierarchy

Formal methods  Formal specification is part of a more general

collection of techniques that are known as „formal methods‟ These are all based on mathematical representation and analysis of software  Formal methods include 

  

Formal specification Specification analysis and proof Transformational development Program verification

Formal Specification  Goals of formal specification:   

 

Complete Consistent Concise Unambiguous Valid—state exactly what the user wants

 Specifications based on formal semantic

model  What is/are semantics?  What is a formal semantic model?

Formal Semantics  Semantics means “meaning”

 Formal semantics: 

Meaning expressed in mathematics

 Formal semantic model: 

Complete semantic definition of a language in mathematics

 What mathematics? 

Discrete mathematics!

 Formal semantics permit dependable

communication between all parties

Notations For Formal Specification  Any notation with precise semantics can be

used  Formalism typically applied to just part of a specification  Notations use discrete mathematics, some with graphics  Several notations are sometimes used in the same specification:   

Z or VDM for data manipulation Statecharts for system states and transitions Natural language for non-functional specifications

Formal Methods Activities  Write a specification using a formal notation

 Validate the specification  

Inspect it with domain experts Perform automated analysis to prove theorems

 Refine the specification to an implementation 

Semantics-preserving transformations to code

 Verify that the implementation matches the

spec 

Mathematical argument

Advantages of Formal Specification  It provides insights into the software

requirements and the design.  Formal specifications may be analyzed mathematically for consistency.  It may be possible to prove that the implementation satisfies the specification.

Advantages of Formal Specification ď Ž Formal specifications may be used to guide

the tester of the component in identifying appropriate test cases. ď Ž Formal specifications may be processed using software tools. It may be possible to animate the specification to provide a software prototype.

Two specification techniques  Algebraic approach  The

system is specified in terms of its operations and their relationships

 Model-based approach  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 Algebraic


Sequential Larch (Guttag, Horning et al., 1985; Guttag, Horning et al., 1993), OBJ (Futatsugi, Goguen et al., 1985) Z (Spivey, 1992) VDM (Jones, 1980) B (Wordsworth, 1996)

Concurrent Lotos (Bolognesi and Brinksma, 1987),

CSP (Hoare, 1985) Petri Nets (Peterson, 1981)

Use of formal methods  Their principal benefits are in reducing the

number of errors in systems so their main area of applicability is critical systems:  

 

Air traffic control information systems, Railway signalling systems Spacecraft systems Medical control systems

 In this area, the use of formal methods is most

likely to be cost-effective  Formal methods have limited practical applicability

Use of formal specification ď Ž Formal specification involves investing more

effort in the early phases of software development This reduces requirements errors as it forces a detailed analysis of the requirements ď Ž Incompleteness and inconsistencies can be discovered and resolved !!! Hence, savings as made as the amount of rework due to requirements problems is reduced

Development costs with formal specification Cost

Validation Design and Implementation

Validation Design and Implementation Specification


Without formal specification

With formal specification

Formal Method Are Not…  Project management methods

 Useful for a non technical audience (customer)  Writing program twice  Replacements for all testing

 Infallible  Cost-effective for many routine projects

Three Levels of Formal Methods LEVEL 0 Formal Specification

LEVEL 1 Formal Verification

LEVEL 2 Theorem Provers

1. Requirements Only 2. No Analysis/Proof 3. Cost effective

1. Produce a program in a more formal manner 2. Use proofs of properties or refinements from formal specification 3. Costly

1. Use theorem prover 2. Fully formal machinechecked proofs. 3. Expensive, hard and often costly 4. Formally prove the entire system.

Three Levels of Formal Methods Level 2 Theorem Provers

Level 1 Formal Verification

Formal Method Basic #1  

formal method basic concept

Formal Method Basic #1  

formal method basic concept