OOP #10: Correctness

Fritz Henglein

Wrap-up: Types A type is a collection of objects with

common behavior (operations and properties).

(Abstract) types can only be accessed through their operations.

A type in object-oriented programming is usually decribed by an object protocal: which operations they have, but not what properties they have (object protocol)

Wrap-up: Types... An interface defines an object

protocol. A class defines object protocol,

class protocol and an implementation

A type is a subtype of another if each object of the first type is also an object of the second type.

Wrap-up: Types... Upcasts and downcasts convert objects

from one type to another Upcasts have no run-time effect on objects

and can be omitted from the source code. (No code generated!)

Downcasts on objects check the runtime type of an object; may raise exception. (Code for test generated!)

Upcasts on objects correspond to application of subtype polymorphism; may be omitted.

Correctness Specification and code (Formal) verification Testing Design by contract

Specification and code Programs have a purpose Specification: explicit properties

a program should have (what it should accomplish)

Correctness: Proof/argument that a program satisfies its specification to a satisfactory degree

Verification Specification: Complete specification

of all desired properties in formal, mathematical language

Correctness: Formal or rigorous (mathematical) proof of correctness

Requires: Formal/rigorous semantics for specification language and programming language

Verification: Properties Only method to ‘check’ the infinity of all

possible inputs a program may ever be tried on

Total bug elimination Requires mathematical sophistication in

people and tools Doesn’t apply to ill-specified systems Doesn’t scale well. Expensive Applied in high-cost-per-bug areas (e.g.,

hardware, avionics)

Note: Verification: “Did we build the

system right?” Validation: “Did we build the right

system?”

Partial verification (type checking, static analysis) Partial verification: Formal

verification of some properties, not all

Usually applied to general robustness properties: doesn’t generate type error (static type

checking) doesn’t dereference null pointers

(extended static checking)

Testing Exercising (production) code on a

well-design test suite Purpose: Finding as many bugs as

possible within reasonable

Testing: Granularity Unit testing: testing of individual

methods, classes Integration testing: testing of

interaction between several units System testing: testing of whole

system Acceptance testing (validation):

testing of whole system

Testing: Methods White-box testing: Design test

suite by analysis of code; ensure coverage of all statements in code

Black-box testing: Design test suite by analysis of specification; ensure coverage of boundary cases, important cases.

Testing: Process Seed test suite (from specification) Incrementally:

Add tests (‘specify’) and code (‘implement’) hand-in-hand

Run test suit Fix code (plus add additional tests)

Regression testing: Repeat execution of whole test suite to catch (re)introduction of bugs

Test-driven design Forces thinking about precise

specifications, in particular interfaces Catches bugs early (the later the

more expensive) Eases bug location Forces thinking about building

support for testing into the program design

Design by contract Program design driven by

‘contract’ model (method) precondition: a property that

must hold

Conditions (invariants) Precondition: a property that must

hold upon entry into a method. Postcondition: a property that

must hold upon exit from a method. Class invariant: a property that

must hold both upon entry and upon exit from a method.

Assertion: a property that must hold

Who is responsible? Precondition: The precondition

must be ensured by the caller (client)

Postcondition: The postcondition must be ensured by the method (service provider)

Class invariant: The class invariant must be ensured by the class (service provider)

Property of what? Precondition: The precondition

involves the receiver object and all arguments of a method call.

Postcondition: The postcondition involves the receiver object and all arguments of a method call.

Note: The receiver object’s properties should be statable through its public interface.

Property of what?... Class invariant: The class

invariant involves instance variables and methods.

Note: The class invariant may refer to private fields and methods.

Assertion (invariant) An assertion is any executable

statement, which may either succeed or fail.

Intention: The assertion should always succeed.

An assertion is executed at runtime. If it fails the program is terminated, or a failure report is logged.

Design by contract Define interface with properties in

the form of: method preconditions and

postconditions class invariants loop invariants (assertion in loops) assertions other places

Enforce invariants

Enforcing invariants Static checking: Prove that all

invariants will always hold for any input

Example: Extended Static Checking; e.g. ESC/Java

Dynamic checking: Execute invariants as assertions at runtime; signal error if assertion doesn’t succeed (proof that invariants do not always hold)

Enforcing invariants Dynamic checking: Execute

invariants as assertions at runtime; signal error if assertion doesn’t succeed (proof that invariants do not always hold)

Example: Eiffel (built into the language); for Java: e.g. iContract (preprocessor), plus other tools