nal workshop april8 veena

7/30/2019 NAL Workshop April8 Veena

1/37

1Copyright 2005 Liverpool Data Research Associates Limited

Success of Formal MethodsImplemented in the LDRA tool suite

Veena BN

2013 LDRA Ltd


2/37

Agenda

Introduction Formal Methods: Why? Where? How?

Mathematical models & algorithms by stealth

Industrial strength formal methods Techniques & methods implemented in the LDRA

tool suite

Conclusion

Summary

2


3/37

What are Formal Methods?

A Formal Method is defined as being amathematically based analysis technique which

has a defined semantics.

This definition is that adopted by the Avionics

Community in DO-178C [DO1].

A Formal Method is required to have the property

of soundness

intended to demonstrate that the technique has beensubjected to peer review or can be demonstrated to be

valid

3


4/37

LDRA Ltd

Liverpool Data Research Associates

Founded 1975 Provider of Test Tools & Solutions

Metrics Pioneer

Consultancy, Support, Training Active participation in standards

such as DO-178B/C, MISRA C/C++

4


5/37

The LDRA tool suite

5

Widely known for its extremely powerful Dynamic Analysis, Unit Test and Object CodeVerification (Level A) capabilities where it has been a world leader for a long period.

Also well known for its Static Analysis capability.

However, it has not been acknowledged in the formal methods arena.

Part of the reason is that LDRA have deliberately avoided the association, because somany software engineers are fearful of the mathematical overtones.


6/37

Formal Methods: Where? How?

Users are perfectly happy to discuss issues suchas data flow anomalies without the faintest idea

as to how one might go about finding such

anomalies.

The underlying graph theory and sophisticatedmathematics are a total mystery.

This paper documents some of the most

commonly used Formal Methods which have

been implemented in the LDRA tool suite formany years

6


7/37

Industrial Strength Formal Methods

The application areas where LDRA tools are usedare extremely diverse.

Frequently the users are pushing the extreme

quarters of the programming languages and the

LDRA tool suite is always expected to be able toperform its analyses.

Tool suite users rarely confine themselves to

carefully selected subsets of the languages;rather, they use the full language spectrum.

7


8/37

LDRA tool suite Formal Methods

The LDRA tool suite make extensive use ofFormal Methods techniques in order to detect

defects in source and object code software

The Formal Methods implemented in the LDRA

tool suite belong primarily to variants of modellingmethods.

The algorithms which implement these models

have been refined for as many as 40 years andcope with multi-various programming constructs.

8


9/37

Formal Methods Techniques

There are two underlying mathematical models ofthe programs being analysed produced by the

LDRA tool suite

9

Mathematical Models

DataFlow

Model

ControlFlow

Model


10/37

Control Flow Model

The control flow modelis based on the syntaxand semantics of each specific programminglanguage.

It handles such diverse constructs:

Recursion (single procedure, multi-procedural, multi-file),

Procedural parameters,

Pointers to procedures,

Multi-threading, tasking, concurrent processes,

Exception handling,

The control flow model is system wide multi-procedural, multi-file

10


11/37

Control Flow Model: Example Graph

11


12/37

Control Flow Model

12

Flow

Graph

Annotated

Flow Graph


13/37

The Data Flow Model

Powerful graph theoretic algebras are applied tothe system-wide control flow model to yield a

number of different types of analysis.

Defects detected include:

references to un-initialized variables

wasted computations on variables

variables which do not contribute to outputs

parameter mismatches of various types

The model is system wide and includes variable

aliasing through procedure interfaces

13


14/37

Data Flow Analysis

Analysis is done based on the declaration andscope of program variables

The operations performed reference (R: use in a computation)

definition (D: use in the left-hand-side of anassignment operation).

The values of variables at declaration and after end ofscope are treated as undefined(U).

UR, DD and DUanomalies are reported

14


15/37

Data Flow Analysis: from the tool suite

15

Data flow + Violations

Procedure information


16/37

Data Coupling Analysis

This technique investigates the way in which proceduresinteract with data items which are not local to thatprocedure.

Procedures acquire external data items in two ways parameters and global variables

For Ex: a global variable when passed as a parameter ina call then has two access mechanisms inside theprocedure. The danger arises firstly from the programmer failing to appreciate

this fact and thinking they are distinct

secondly from a compiler treating them as distinct when theprogrammer thinks they are the same

Use of pointers make it worse

The tool has algorithms to detect problems of this type

16


17/37

File Handler Analysis

This technique looks at the use of file handlers (I/O

streams, files, etc.).

The Control Flow Model is annotated with the operations

performed on the file handlers,

open, close, assignment, aliasing, etc..

The objective is to search system wide to find instances

(on any path) of:

files written to, before being opened;

files written to, after being closed;

files written to, but never closed.

17


18/37

Storage Analysis

This model is, at present, exclusive to C. Theproblem is to identify the careless use of storage

Storage allocated and then not de-allocated

correctly

It is also possible to release memory notallocated and this is also reported

18


19/37

Pointer Analysis

19

The data flow model is enhanced by the pointervariables and the operations performed uponthem.

The operations include aliasing over procedureboundaries and dereference operations.

PointerAnalysis:

Since this is a static model and pointer operationsare a dynamic issue, the model has certain

limitations.

Caveat:


20/37

Null Pointer Checking

The problem being addressed by this model to trap the possibility of using a null pointer, i.e., a

pointer which has no valid value

Accomplished by searching an annotated data

flow model which is enhanced by the conditionsof all the branching conditions

Then any use of a pointer in any context on a

path which does not contain a successful test of

the value of the pointer is flagged.

20


21/37

Divide-by-Zero Analysis

This model is similar in concept to the previousmodel and uses an enhanced data flow model.

The enhancements

Include the specific arithmetic operations on the

program variables

The aim is to detect constructs which can lead to

a divide-by-zero event.

Any input value which is not checked beforebeing used as a division is reported.

21


22/37

Array Bound Checking

The tool suite has two modes to address the problem ofarray bound overflow. The checks can be performed statically or dynamically.

The static checks are again performed by enhancing thedata flow model.

The model has limitations due to the dynamiccharacteristics and additionally, the unhelpful nature oflanguages such as C and C++ makes a precise algorithmdifficult.

The checks can also be performed dynamically.

The use of unchecked input values as an array index arereported.

22


23/37

Dead Code Analysis

23

In any programming language it is possible to

include code which never contributes to anyoutputs.

Except in specific circumstances, the removal ofthis code contributes to most qualitycharacteristics of a program.

Such code is flagged up by a comprehensivemodel which relates the program outputs to theprogram inputs, both directly and indirectly.


24/37

Information Flow Analysis

This model uses the same annotated data flowmodel as the dead code analysis.

Combines the relationships discovered between

the I/O variables and annotations supplied by

customers. Differences between the forecasts supplied by

customers and the actual results are reported.

This is another aspect of the tool which utilisesthe results of other Formal Methods.

24


25/37

Information Flow Analysis

Aims to discover the relationships between inputvariables and output variables.

The dependencies are classified as:

direct or indirect

sub categories of both (strong and weak).

This is performed in the LDRA Testbed tool suite

by scanning the system-wide control and

dataflow graphs with a grammar to discover such

relationships.

25


26/37

Information Flow Analysis Report

26


27/37

Exact Semantic Analysis

The tool compares user-supplied annotationswith the exact semantics of the program.

This includes the use of:

invariants

pre-conditions

post-conditions

This provides a direct link with a number of other

flavours of Formal Methods and notations.

27


28/37

LCSAJ Analysis

The set of linear code sequence and jump(LCSAJ) sub paths forms a basis set for the

generation of program paths.

As such, LCSAJs are a powerful vehicle for

analyzing path structure and generating targetedtest data.

The tool generates a test case plan.

28


29/37

LCSAJ Example Test Case Planner

29


30/37

Side Effect Analysis

The use of functions in complex expressions canbe a source of error if the functions concerned

have side effects.

parameter side effects

global variable side effects I/O side effects, both file and volatile location based

class member side effects

In particular, the result can be affected by compilers order

of evaluation

30


31/37

MC/DC Test Case Planning

Modified condition/decision coverage (MC/DC)requires testing of decisions in a program such that

changing the truth value of each individual

condition within the decision forces a consequence

on the overall decisions outcome A mathematical approach is implemented to

generate a test case planner

lists out minimal number of test conditions for maximum

coverage

Ex: for N number of variables, instead of2N test cases,

(N+1) cases would be sufficient

31


32/37

MC/DC planner: Example From The

LDRA tool suite

32


33/37

Conclusion

The LDRA tool suite comprising lexical analyzers,parsers and modelling tools have been in

continuous production since 1975

The use of the Formal Methods components

were first described in 1983 The algorithms have been applied to some 14

different computer languages with numerous

dialectic variations

The LDRA tool suite has been used in a huge

number of safety and mission critical applications

33


34/37

Summary

In 40 years the LDRA tool suite has progressedconsiderably but there is still much to be done.

The aim is to implement any technique

Which can reduce the occurrence of defects and faults

provided only that the technique is reasonablyapplicable to significant numbers of software systems

As more Formal Methods mature they are likely

to be prime candidates for implementation

34


35/37

References

35

Formal Methods by Stealth: Formal Methods

Implemented in the LDRA Tool Suite: M. A. Hennell,

and M. R. Woodward

An Algebra for Dataflow anomaly Detection: Ira Forman

RTCA. Software considerations in airborne systems and

equipment certification. Report DO-178B, Radio Technical

Commission for Aeronautics (RTCA) Inc., Suite 1020,

1140 Connecticut Avenue NW, Washington DC 20036,

U.S.A. (1992).

LDRA tool suite manual


36/37

Summaryand

Questions & Answers

36


37/37

37

@ldra_technology LDRA Software Technology LDRA Limited

For further information:

www.ldra.com [email protected]
http://www.ldra.com/mailto:[email protected]:[email protected]://www.ldra.com/

nal workshop april8 veena

Documents