Static and Dynamic Verification-Software Engineering-Lecture Slides, Slides of Software Engineering

This lecture is part of lecture series for Software Engineering course. Prof. Prateek Aron delivered this lecture at Allahabad University. Its main points are: Static, Dynamic, Verification, Software, Inspections, Testing, Specification, Error, Checklist, System, Overview, Modifications

Typology: Slides

2011/2012

Uploaded on 07/16/2012

sanaka
sanaka ๐Ÿ‡ฎ๐Ÿ‡ณ

4.6

(21)

71 documents

1 / 27

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Objectives
๏‚—To describe the program inspection process and its role
in V & V
๏‚—To explain static analysis as a verification technique
๏‚—To describe the Cleanroom software development
process
1 COMP201 - Software Engineering
docsity.com
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b

Partial preview of the text

Download Static and Dynamic Verification-Software Engineering-Lecture Slides and more Slides Software Engineering in PDF only on Docsity!

Objectives

๏‚— To describe the program inspection process and its role in V & V

๏‚— To explain static analysis as a verification technique

๏‚— To describe the Cleanroom software development process

Recap: Verification vs Validation

๏‚— Verification : "Are we building the product right"

๏‚— The software should conform to its specification

๏‚— Validation : "Are we building the right product"

๏‚— The software should do what the user really requires

Inspection Pre-Conditions

๏‚— A precise specification must be available

๏‚— Team members must be familiar with the organisation standards

๏‚— Syntactically correct code must be available

๏‚— An error checklist should be prepared

๏‚— Management must accept that inspection will increase costs early in the software process

๏‚— Management must not use inspections for staff appraisal

The Inspection Process

Inspection meeting

Individual preparation

Overview

Planning

Rework

Follow-up

Inspection Teams

๏‚— Made up of at least 4 members

๏‚— Author of the code being inspected ๏‚— Inspector who finds errors, omissions and inconsistencies ๏‚— Reader who reads the code to the team ๏‚— Moderator who chairs the meeting and notes discovered errors

๏‚— Other possible roles are Scribe and Chief moderator

Inspection Checklists

๏‚— Checklist of common errors should be used to drive the inspection

๏‚— Error checklist is programming language dependent

๏‚— The 'weaker' the type checking, the larger the checklist

๏‚— Examples: ๏‚— Initialisation, ๏‚— Constant naming, ๏‚— loop termination, ๏‚— array bounds, etc.

Inspection Rate

๏‚— 500 statements/hour during overview

๏‚— 125 source statement/hour during individual preparation

๏‚— 90-125 statements/hour can be inspected

๏‚— Inspection is therefore an expensive process

๏‚— Inspecting 500 lines costs about 40 man/hours effort

Automated Static Analysis

๏‚— Static analysers are software tools for source text processing They parse the program text and try to discover potentially erroneous conditions and bring these to the attention of the Verification & Validation team

๏‚— Very effective as an aid to inspections. A supplement to but not a replacement for inspections

Stages of Static Analysis

๏‚— Control flow analysis. Checks for loops with multiple exit or entry points, finds unreachable code, etc.

๏‚— Data use analysis. Detects uninitialised variables, variables written twice without an intervening assignment, variables which are declared but never used, etc.

๏‚— Interface analysis. Checks the consistency of routine and procedure declarations and their use

Stages of Static Analysis

๏‚— Information flow analysis. Identifies the dependencies of output variables. ๏‚— Does not detect anomalies itself but highlights information for code inspection or review

๏‚— Path analysis. Identifies paths through the program and sets out the statements executed in that path. ๏‚— Again, potentially useful in the review process

๏‚— Both these stages generate vast amounts of information. Must be used with care.

Use of Static Analysis

๏‚— Particularly valuable when a language such as C is used which has weak typing and hence many errors are undetected by the compiler

๏‚— Less cost-effective for languages like Java that have strong type checking and can therefore detect many errors during compilation

Verification and Formal Methods

๏‚— Recall that formal methods are based on mathematical representations of the software as a formal specification.

๏‚— They are concerned with:

๏‚— Mathematical analysis of the specification; ๏‚— Transformation of the specification to a more detailed semantically equivalent representation; ๏‚— Formally verifying that one representation of a system is equivalent to another.

Cleanroom Software Development

๏‚— The name is derived from the 'Cleanroom' process in semiconductor fabrication.

๏‚— The philosophy is defect avoidance rather than defect removal

๏‚— Software development process based on:

๏‚— Incremental development ๏‚— Formal specification. ๏‚— Static verification using correctness arguments ๏‚— Statistical testing to determine program reliability.

The Cleanroom Process

Construct structured program

Define software increments

Formally verify code

Integrate increment

Formally specify system

Develop operational profile (^) statisticalDesign tests

Test integrated system

Error rework