OOP #10: Correctness Fritz Henglein. Wrap-up: Types A type is a collection of objects with common...
-
date post
21-Dec-2015 -
Category
Documents
-
view
215 -
download
0
Transcript of OOP #10: Correctness Fritz Henglein. Wrap-up: Types A type is a collection of objects with common...
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