A Practical Approach to Programming With Assertions by David Rosenblum

1

A Practical Approach toProgramming With

Assertionsby David Rosenblum

Sameh ElghzaliFall 2009

2

Outline

• Overview of data assertions and why programming with assertions is a great idea?

• History of data assertions• Impact of data assertions on software

products quality• The tool under study• The data assertion process• Discussion and questions

3

Programming With Assertions (1/2)

• What is data assertion?• Definition: Assertions are formal

constraints on software system behavior that are commonly written as annotations of a source text

• The primary goal in writing assertions is to specify what a system is supposed to do rather than how it is to do it

4

Programming With Assertions (2/2)

• In addition to their formal verifications, assertions have long been recognized as a potential powerful tool for automatic runtime detection of software faults during debugging, testing and maintenance

• More recently, assertion have been viewed as a permanent defensive programming mechanism for runtime fault detection in production versions of software systems

5

Why Programming with Assertions Is a Great Idea? (1/3)• Assertions provide run-time checks of

assumptions that you would have otherwise put in code comments

• An assert statement simply checks a Boolean condition, and does nothing if it is true but immediately terminates the program if it is false

• Assert statements serve as test code integrated directly into your implementation

6

Why Programming with Assertions Is a Great Idea? (2/3)• An assertion allows you to express in code

what you assume to always be true about data at a particular point in execution

• You probably already write comments throughout your code to document non-obvious assumptions about the values of data structures, so why don't you instead write it into assert statements

7

Why Programming with Assertions Is a Great Idea? (3/3)

• When you are writing code filled with assert statements, you can be more confident that when execution reaches a certain point, certain conditions are guaranteed to be met

• When you are debugging code filled with assert statements, failures appear earlier and closer to the locations of the errors, which make them easier to diagnose and fix

8

Outline



products quality• The Tool under study• The data assertion process• Discussion and questions

9

History of Data Assertions (1/3)

• Alan Turing advocated use of assertions in 1950 at a conference in Cambridge, he gave a short talk entitled “Checking a Large Routine” which explains the idea with great clarity

• He explained that the programmer should make a number of definite assertions which can be checked individually, and from which the correctness of the whole program easily follows

10


• Floyd demonstrated the need for loop assertions for verification of programs in 1967

• Luckham et al. elaborated around 1975 the basic principles outlined by Floyd into an algorithm for mechanical program verification that was based on the generation and proof of simple assertions called verification conditions

• this algorithm was implemented in the Stanford Pascal Verifier around 1979

11


• At the international conference on reliable software in 1975, several authors described systems for deriving runtime consistency checks from simple assertions

• Today, assertion features are available as programming language extensions, as programming language features, and in complete high-level formal specification languages

12

Data Assertion Tools

• Many data assertion tools been developed and used for multiple software languages such as Sather, Eiffel, Fortran, Ada, C, C++, Java and others

• ADL (Assertion Definition Language) is an example of data assertion tool for Jave and C++ code

• APP (Annotation Pre-Processor) is data assertion tool for C language is used in this presentation as an example

13

Outline


• History of Data Assertions• Impact of data assertions on software


14

Impact of Data Assertions on Software Products Quality• In Perry and Evangelist’s empirical study, it was

shown that most software faults are interface faults

• Perry and Evangelist identified 15 different kinds of interface faults in the software change request data that they analyzed

• APP was initially designed to process assertions on function interfaces and simple assertions in function body

• APP can help to diagnose and resolve most of the interface and other functional body faults

15

Perry and Evangelist's Classifications of Interface FaultFault Code Interface Fault

F1Construction (mismatched separate interface and implementation)

F2 Inadequate Functionality

F3 Disagreements on Functionality

F4 Changes in Functionality (requirements changes)

F5 Added Functionality (requirements changes)

F6 Misuse of Interface

F7 Data Structure Alteration

F8 Inadequate Error ProcessingF9 Additions to Error Processing

F10 Inadequate Post-processing (resource de-allocation)

F11 Inadequate Interface Support

F12 Initialization/Value Errors

F13 Violation of Data Constraints

F14 Timing/Performance Problems

F15 Coordination of Changes

16

Outline




17

APP - Annotation Pre-Processor for C Code (1/2)• A method of generating consistency

checks from annotations on variables, subprograms and exceptions

• A method that uses incremental theorem providing to check algebraic specifications at run time

• A method of generating consistency checks that run in parallel in respect to the execution of the underlying system

18

APP - Annotation Pre-Processor for C Code (2/2)• provide complete flexibility in specifying

how violated assertions are handled at runtime and how much or how little checking is to be performed each time a self-checking program is executed

• Does not require complete specifications for its correct operations, and the assertions one writes for APP typically are not complete specifications in any formal sense

19

Outline




20

APP Assertion Constructs (1/2)

• APP recognizes assertions that appear as annotations of C source text

• Assertions are written inside comment regions using the extended comment indicators /*@ ... @*/

• Informal comments can be written in an assertion region by writing each comment between the delimiter // and the end of the line

21

APP Assertion Constructs (2/2)

• The constraint is specified using C’s expression language, with the C convention that an expression evaluating to zero is false, while a nonzero expression is true

• Quantification over finite domains can be specified using a syntax that is similar to C’s syntax for for loops

22

APP Recognized Assertions Constructs

• Assume Specifies a precondition on a function.

• Promise Specifies a post condition on a function

• Return Specifies a constraint on the return value of a function

• AssertSpecifies a constraint on an intermediate state of a function body.

23

Example of Data Assertions (Functional Interface)

int square_root(x) int x/*@

Assume x >=0;Return y where y>=0 Return y where y*y <=x && x< (y+1)*(y+1);

@*/ { ……}

Begin of assertion clause

End of assertion clause

Precondition constraints that input must be >0

constraints on the expected resultedValues from the function as indicated by keyword return

Begin of function

24

Example of Data Assertions (Functional Body)Void swap(x, y)Int* x;Int* y;/*@

Assume x && y && x!=y;Promise *x == in *y;Promise *y == in *x;

@*/{

*x == *y ^ *x;*y == *x ^ *y;

/*@Assert *y == in *x.

@*/*x == *y ^ *x;

}

Functional body assertion

Examples of functional Interface assertions

Begin of function

25

Violation Actions, Predefined Macros and Severity Levels (1/2)• APP converts each assertion to a runtime check,

which tests for the violation of the constraint specified in the assertion

• If the check fails at runtime, then additional code generated with the check is executed in response to the failure

• The default response code generated by APP prints out a simple diagnostic message

• Use some preprocessor macros that are predefined by APP, can enhance the presentation and diagnoses of failures

26

Violation Actions, Predefined Macros and Severity Levels (2/2)• APP supports the specification of an optional

severity level for each assertion, with 1 being the default and indicating the highest severity

• A severity level indicates the relative importance of an assertion and determines whether or not the assertion will be checked at runtime

• Severity levels can be used to control the amount of assertion checking that is performed at runtime without recompiling the program to add or remove checks

27

Generating and Running Self-checking Programs• APP translates an input annotated C

program into an equivalent C program with embedded assertion checks

• APP has the same command-line interface as cpp, the standard pre-processor pass of C compilers

• Standard build tools such as make and nmake can be used to build executable self-checking programs

28

A Classification of Assertion

• Specification of function interfacesThe primary goal of specifying a function interface is to ensure that the arguments, return value and global state are valid with respect to the intended behavior of the function; the common characteristic of all function interface constraints is that they are stated independently of any implementation for the function. The constraints are special forms of traditional preconditions and post-conditions

• Specification of function bodiesAssertions that are stated in terms of a particular function implementation can be used as “enforced comments” to guard against such faults in the function body

29

Specification of Function Interfaces(1/3)• Consistency between arguments

For each function in the system, specify how the value of each of its arguments depends on the values of its other arguments

• Dependency of return value on argumentsFunction in the system, provide post-conditions that specify how its return value(s) depends on the values of its arguments

• Effect on global stateFor each function in the system, specify what changes the function makes to the values of the global variables that are visible to it

30

Specification of Function Interfaces(2/3)• The context in which a function is called

For each function in the system, specify how the values of its arguments and the values of the global variables visible to it govern when it is valid for the function to be called

• Frame specifications For each function in the system, specify each case when the value of an argument passed to the function by reference, or the value of a global variable visible to the function, is to be left unchanged by the function

• Non-null pointersFor each function in the system, specify which pointer-valued arguments, return value(s) and global variables must not be null

31

Specification of Function Interfaces (3/3)• Sub-range membership of data

For each function in the system, specify all sub-range constraints on the values of its arguments, return value(s) and global variables that are of numeric type. Also specify all sub-range constraints on the values used to index its array-valued arguments, return value(s) and global variables

• Enumeration membership of dataFor each function in the system, specify all membership constraints on the values of its arguments, return value(s) and global variables that are of enumeration type

32

Specification of Function Bodies (1/2)• Condition of the else part of complex if

Statements For each if statement in the system that contains a final else part, explicitly specify the implicit condition of the final else part as an initial assertion in that part

• Condition of the default case of a switch statementFor each switch statement in the system that contains a default case, explicitly specify the implicit condition of the default case as an initial assertion in that case. For each switch statement without a default case, provide a default case containing an assertion that always evaluates to false

33

Specification of Function Bodies (2/2)• Consistency between related data

For each function body in the system, specify consistency constraints on mutually dependent data at frequent intervals within the code that manipulates that data

• Intermediate snapshot of computationFor each function body in the system, specify at frequent intervals the key constraints the function body must satisfy

34

Summary Classifications of Assertions

Assertion Code Description

I Specification of Function InterfacesI1 Consistency Between ArgumentsI2 Dependency of Return Value on Arguments

I3 Effect on Global StateI4 Context in Which Function Is CalledI5 Frame SpecificationsI6 Sub-range Membership of DataI7 Enumeration Membership of DataI8 Non-Null PointersB Specification of Function BodiesB1 Condition of Else Part of If StatementB2 Condition of Default Branch of Switch StatementB3 Consistency Between Related DataB4 Intermediate Snapshot of Computation

35

Effective Assertions for Detecting Interface Faults Fault Code Effective AssertionsF1 I1, I2

F2I1, I3, I4, preconditions I

F3 I2, I3,I4, I5F4 noneF5 noneF6 IF7 I1, I5, I6,I7, I8, B3F8 I, BF9 I, BF10 I3F11 I2, I3, post-conditionsF12 I1, I3, I6, I7, I8, B3F13 I2, I3, I5,I6, I7, B3F14 noneF15 I

Effective assertions in the empirical study was found to identify and diagnose most of the faults identified by Perry and Evangelist for the interface faults.

36

Conclusions (1/2)

• APP provides a rich collection of features for specifying not only the assertions themselves but also the responses to failed runtime assertion checks

• APP fits easily into the process of developing C programs

• The assertion checks generated by APP introduce negligible time and space overhead into the generated self-checking program

• APP provides severity levels in order to give the specifier greater control over the amount of assertion checking that is performed at runtime

37

Conclusion (2/2)

• APP will be extended to support other kinds of assertions and higher-level abstraction facilities

• APP new features will include constraints on types and global variables, a richer abstraction of arrays and other abstract data types, and constructs for specifying interactions between program units that are larger than functions

• Assertion checking is a powerful alternative for identifying and removing faults in large applications and it is powerful, practical, scalable and simple to use

38

Discussion and Questions

Documents

A Practical Approach to Programming With Assertions by David Rosenblum