CSC/ECE 517 Fall 2009/wiki3 15 SJ3: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
mNo edit summary
 
(10 intermediate revisions by 2 users not shown)
Line 2: Line 2:


== Introduction to Assertions ==
== Introduction to Assertions ==
Assertions is statement used in code that indicates what a programmer assumes to be true at that point during execution.  They are used to help clarify program constraints and assumptions and ensure program correctness.  In general they can be thought of as way of testing.  Unlike test cases which apply external stimuli to objects and validate their state, assertions checks are used to check assumptions and constraints internally.
Assertions is statement used in code that indicates what a programmer assumes to be true at that point during execution.  They are used to help clarify program constraints and assumptions and ensure program correctness.  In general they can be thought of as way of testing.  Unlike test cases which apply external stimuli to objects and validate their state, assertions checks are used to check assumptions and constraints internally.


Line 9: Line 10:
</pre>
</pre>


The way the assertion statement behaves is based on the expression.  If the expression evaluates to true execution proceeds past the statement without notice.  If the expression evaluates false and exception is thrown causing the program to abort.  Typically the expression and line number are displayed to standard error as well.
The way the assertion statement behaves is based on the expression.  If the expression evaluates to true execution proceeds past the statement without notice.  If the expression evaluates false and exception is thrown causing the program to abort or execute an exception handler.  Typically if program is aborted the expression and line number are displayed to standard error as well.


=== Design by Contract ===
== Design by Contract ==
Assertions are used in a facility called [Design by Contract], http://en.wikipedia.org/wiki/Design_by_contract.  
Assertions are used in a facility called [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract].  
Contracts are a breakthrough technique to reduce the programming effort for large projects. Contracts are the concept of preconditions, postconditions, errors, and invariants. These specifications of "contract" define the interface of different element of software includes method, class, module...  
Contracts are a breakthrough technique to reduce the programming effort for large projects. Contracts are the concept of [http://en.wikipedia.org/wiki/Precondition preconditions], [http://en.wikipedia.org/wiki/Postcondition postconditions], [http://en.wikipedia.org/wiki/Invariant_(computer_science) invariants], and general errors. These specifications of "contract" define the interface of different element of software includes method, class, module, etc.


===Assert contract===
For detail information of contract, please refers to the helpful reading list in [2].
The most basic contract is the assert. An assert inserts a checkable expression into the code, and that expression must evaluate to true:


an assert  in function bodies works by throwing an AssertError, which can be caught and handled. Catching the contract violation is useful when the code must deal with errant uses by other code, when it must be failure proof, and as a useful tool for debugging.
=== Design by Contract Benefits ===
* A better understanding of the object-oriented method and, more generally, of software construction.
* A systematic approach to building bug-free object-oriented systems.
* An effective framework for debugging, testing and, more generally, quality assurance.
* A method for documenting software components.
* Better understanding and control of the inheritance mechanism.
* A technique for dealing with abnormal cases, leading to a safe and effective language construct for exception handling.


===Pre and Post contract ===
=== Precondition and Postcondition contract ===
The pre contracts specify the preconditions before a statement is executed. The most typical use of this would be in validating the parameters to a function. The post contracts validate the result of the statement. The most typical use of this would be in validating the return value of a function and of any side effects it has. The syntax is:  
The pre contracts specify the preconditions before a statement is executed. The most typical use of this would be in validating the parameters to a function. The post contracts validate the result of the statement. The most typical use of this would be in validating the return value of a function and of any side effects it has. The syntax is:  
<pre>
<pre>
  long square_root(long x)
long square_root(long x)
    in
in
    {
{
assert(x >= 0);
    assert(x >= 0);
    }
}
    out (result)
out (result)
    {
{
assert((result * result) <= x && (result+1) * (result+1) >= x);
    assert((result * result) <= x && (result+1) * (result+1) >= x);
    }
}
    body
body
    {
{
return cast(long)std.math.sqrt(cast(real)x);
    return cast(long)std.math.sqrt(cast(real)x);
    }
}
</pre>
</pre>
===In, Out and Inheritance ===
If a function in a derived class overrides a function in its super class, then only one of the in contracts of the function and its base functions must be satisfied. Overriding functions then becomes a process of loosening the in  contracts.


===Class Invariants ===
=== Invariant contract ===
Class invariants are used to specify characteristics of a class that always must be true (except while executing a member function). They are described in Classes.
Here is simple example of invariant condition. Physically a size of a container should be 0 or positive.
<pre>
assert(size >= 0)
</pre>


for detail information of contract, please refers to the helpful reading list in [2].
=== General Assertion Error ===
Assertion will fail here if there is not any memory to allocate.
<pre>
int* ptr = (int) malloc(sizeof(int));
assert(ptr != NULL);
</pre>


==The advantages of Contract Programming==
=== In, Out and Inheritance ===
 
If a function in a derived class overrides a function in its super class, then only one of the in contracts of the function and its base functions must be satisfied. Overriding functions then becomes a process of loosening the in  contracts.  
* A better understanding of the object-oriented method and, more generally, of software construction.
* A systematic approach to building bug-free object-oriented systems.
* An effective framework for debugging, testing and, more generally, quality assurance.
* A method for documenting software components.
* Better understanding and control of the inheritance mechanism.
* A technique for dealing with abnormal cases, leading to a safe and effective language construct for exception handling.


== Assertion Advantages ==
* Since they help clarifiy program constraints and assumptions they help with providing documentation.
* Provide runtime verification, which leads to continious and ongoing testing.
* Can perform Validations deep inside of a private method or in general a method not publicly visible.
* When used inside of classes they are encapuslated and hidden from the client. (helps client isolate problem to either client code or provided code)


=== The disadvantages of Contract Programming ===
== Assertion Disadvantages ==
* If not turned off they can lead to serious performance implications (e.g. asserting a list is sorted)
* Not useful when validaton and output for a given input over a range of scenarios
* If assumptons are to restrictive assertions indicate bugs that are potentially false positives.


== References ==
== References ==


[1] wiki page of "Design by Contract", http://en.wikipedia.org/wiki/Design_by_contract
[1] wiki page of "Design by Contract", http://en.wikipedia.org/wiki/Design_by_contract
[2] reading list of contract, http://www.eecs.northwestern.edu/~robby/contract-reading-list/
[2] reading list of contract, http://www.eecs.northwestern.edu/~robby/contract-reading-list/

Latest revision as of 03:05, 19 November 2009

Programming by Assertion

Introduction to Assertions

Assertions is statement used in code that indicates what a programmer assumes to be true at that point during execution. They are used to help clarify program constraints and assumptions and ensure program correctness. In general they can be thought of as way of testing. Unlike test cases which apply external stimuli to objects and validate their state, assertions checks are used to check assumptions and constraints internally.

Here is a basic assertion statement.

assert(expression);

The way the assertion statement behaves is based on the expression. If the expression evaluates to true execution proceeds past the statement without notice. If the expression evaluates false and exception is thrown causing the program to abort or execute an exception handler. Typically if program is aborted the expression and line number are displayed to standard error as well.

Design by Contract

Assertions are used in a facility called Design by Contract. Contracts are a breakthrough technique to reduce the programming effort for large projects. Contracts are the concept of preconditions, postconditions, invariants, and general errors. These specifications of "contract" define the interface of different element of software includes method, class, module, etc.

For detail information of contract, please refers to the helpful reading list in [2].

Design by Contract Benefits

  • A better understanding of the object-oriented method and, more generally, of software construction.
  • A systematic approach to building bug-free object-oriented systems.
  • An effective framework for debugging, testing and, more generally, quality assurance.
  • A method for documenting software components.
  • Better understanding and control of the inheritance mechanism.
  • A technique for dealing with abnormal cases, leading to a safe and effective language construct for exception handling.

Precondition and Postcondition contract

The pre contracts specify the preconditions before a statement is executed. The most typical use of this would be in validating the parameters to a function. The post contracts validate the result of the statement. The most typical use of this would be in validating the return value of a function and of any side effects it has. The syntax is:

long square_root(long x)
in
{
    assert(x >= 0);
}
out (result)
{
    assert((result * result) <= x && (result+1) * (result+1) >= x);
}
body
{
    return cast(long)std.math.sqrt(cast(real)x);
}

Invariant contract

Here is simple example of invariant condition. Physically a size of a container should be 0 or positive.

assert(size >= 0)

General Assertion Error

Assertion will fail here if there is not any memory to allocate.

int* ptr = (int) malloc(sizeof(int));
assert(ptr != NULL);

In, Out and Inheritance

If a function in a derived class overrides a function in its super class, then only one of the in contracts of the function and its base functions must be satisfied. Overriding functions then becomes a process of loosening the in contracts.

Assertion Advantages

  • Since they help clarifiy program constraints and assumptions they help with providing documentation.
  • Provide runtime verification, which leads to continious and ongoing testing.
  • Can perform Validations deep inside of a private method or in general a method not publicly visible.
  • When used inside of classes they are encapuslated and hidden from the client. (helps client isolate problem to either client code or provided code)

Assertion Disadvantages

  • If not turned off they can lead to serious performance implications (e.g. asserting a list is sorted)
  • Not useful when validaton and output for a given input over a range of scenarios
  • If assumptons are to restrictive assertions indicate bugs that are potentially false positives.

References

[1] wiki page of "Design by Contract", http://en.wikipedia.org/wiki/Design_by_contract

[2] reading list of contract, http://www.eecs.northwestern.edu/~robby/contract-reading-list/