1. OOP #10: Correctness Fritz Henglein

2. 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)

3. 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.

4. 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.

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

6. 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

7. 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

8. 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)

9. Note: Verification: “Did we build the system right?” Validation: “Did we build the right system?”

10. 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)

11. Testing Exercising (production) code on a well- design test suite Purpose: Finding as many bugs as possible within reasonable

12. 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

13. 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.

14. 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

15. 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

16. Design by contract Program design driven by ‘contract’ model (method) precondition: a property that must hold

17. 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

18. 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)

19. 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.

20. Property of what?... Class invariant: The class invariant involves instance variables and methods. Note: The class invariant may refer to private fields and methods.

21. 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.

22. 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

23. 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)

24. 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