Design by Contract - PowerPoint PPT Presentation

About This Presentation
Title:

Design by Contract

Description:

(insertion-sort (cdr lon)) // car = first/head, cdr = rest/tail (insertion-sort '(2 3 1 4 7 5) ... Maps a concrete object (satisfying representation invariant) to the ... – PowerPoint PPT presentation

Number of Views:54
Avg rating:3.0/5.0
Slides: 30
Provided by: csWr
Learn more at: http://cecs.wright.edu
Category:

less

Transcript and Presenter's Notes

Title: Design by Contract


1
Design by Contract
  • Invariants
  • Pre-post conditions Rights and Obligations
  • Exceptions Contract Violations

2
Correctness
  • Implementation is correct relative to a
    specification.
  • P S Q
  • Precondition binds the client.
  • It is an obligation for the client and a benefit
    for the supplier.
  • Postcondition binds the supplier (routine).
  • It is an obligation for the supplier and a
    benefit for the client.
  • Non-Redundancy Principle

3
Spec vs Impl
  • Spec
  • pre x0 /\ y3
  • post x3 /\ y0
  • Implementations
  • x 3 y 0
  • x xy yxy
  • tx xy yt
  • Spec?
  • pre true
  • post xx 2
  • Spec
  • pre e gt 0
  • post xx -2 lt e

4
Insertion Sort
  • (define (insertion-sort lon)
  • (if (null? lon) ()
  • (insert (car lon)
  • (insertion-sort (cdr lon))
  • )
  • )
  • )
  • // car first/head, cdr rest/tail
  • (insertion-sort '(2 3 1 4 7 5) )
  • (1 2 3 4 5 7)

5
  • (define (insert n lon)
  • (cond
  • ((null? lon) (list n))
  • ((gt n (car lon))
  • (cons (car lon)
  • (insert n (cdr lon))
  • )
  • )
  • (else (cons n lon))
  • ))
  • Precondition lon is ordered.
  • Postcondition (insert n lon) is ordered.

6
Assertions
  • In theory, assertions are first-order logic
    formulae.
  • In a programming language, assertions are
    computable boolean expressions that can contain
    program variables, arithmetic/boolean
    operations, and possibly, user-defined functions.

7
(contd)
  • In Eiffel, the expression OLD attr in
    postcondition denotes the value of the attribute
    attr on routine entry.
  • In general, the preconditions must not use
    features hidden from the clients. However, the
    postconditions can use any feature, even though
    only clauses without hidden features are directly
    usable by the client.

8
Algebraic Specification Example
9
ADT GStack
  • create -gt GStack
  • push Gstack x G -gt GStack
  • pop Gstack -gt GStack
  • top GStack -gt G
  • empty Gstack -gt boolean
  • constructors create, push
  • observers top, empty
  • non-constructors pop

10
  • Forall s e GStack, x e G
  • pop(push(s,x)) s
  • top(push(s,x)) x
  • empty(create()) true
  • empty(push(s,x)) false
  • Preconditions
  • pop(s) requires s / create()
  • top(s) requires s / create()

11
ADT (Bounded) GStack
  • create int -gt GStack
  • push Gstack x G -gt GStack
  • pop Gstack -gt GStack
  • top GStack -gt G
  • empty Gstack -gt boolean
  • full Gstack -gt boolean
  • constructors create, push
  • observers top, empty, full
  • non-constructors pop

12
  • Auxiliary functions
  • Forall s e Gstack Terms
  • n e int, x e G ngt0
  • count(create(n)) 0
  • count(push(s,x)) 1 count(s)
  • capacity(create(n)) n
  • capacity(push(s,x)) capacity(s)

13
  • Preconditions
  • Forall s e Gstack Terms,
  • n e int, x e G ngt0
  • pop(s)
  • requires s / create(n)
  • top(s)
  • requires s / create(n)
  • push(s,x)
  • requires capacity(s)
  • gt count(s) 1

14
  • Forall s e GStack, n e int, x e G ngt0
  • pop(push(s,x)) s
  • top(push(s,x)) x
  • empty(create(n)) true
  • empty(push(s,x)) false
  • full(s) (capacity(s) count(s))

15
Specifying Class
16
Categories of Operations
  • Creators ( x -gt T )
  • Constructors
  • Queries (x T x -gt )
  • Observers
  • Commands (x T x -gt T )
  • Constructors, Non-constructors

17
  • class IntStack
  • private int capacity
  • private int count
  • public IntStack(int c) ...
  • // require c gt0
  • // ensure capacity c
  • // ensure empty()
  • // ensure count 0
  • public void push(int e) ...
  • // require not full()
  • // ensure top() e
  • // ensure not empty()
  • // ensure count old count 1

18
  • public void pop() ...
  • // require not empty()
  • // ensure not full()
  • // ensure count old count - 1
  • public int top() ...
  • // require not empty()
  • public boolean empty() ...
  • public boolean full() ...
  • // class invariants
  • // empty() (count 0)
  • // full() (count capacity)
  • // pop(push(e)) identity-map

19
Class Invariant
  • A class invariant for C is a set of assertions
    that every instance of C must satisfy at all
    stable times. That is, immediately after its
    creation and before/after a public method call
    (by a client).
  • The class invariant relates attributes and/or
    functions.
  • E.g., 0 lt count lt capacity
  • E.g., (count gt 0) gt (scount top())

20
Role of Class Invariants in Software Engineering
  • Invariants not only apply to the routines
    actually written in the class, but also to any
    routines added later.
  • Correctness of a method meth
  • P and Inv meth_body Q and Inv
  • Role of constructor definitions
  • If default initialization of the fields
    violates class invariant, an explicit constructor
    is needed.

21
From ADT specs to Pre-Post Conditions
  • A precondition for a specs function reappears as
    a precondition for the corresponding routine.
  • Axioms involving a command (possibly with
    queries) reappear as postconditions of the
    corresponding procedure.

22
(contd)
  • Axioms involving only queries reappear as
    postconditions of the corresponding functions or
    as clauses of the class invariant.
  • Axioms involving a creator reappear in the
    postcondition of the corresponding constructor
    procedure.

23
Introducing Representation
  • class IntStack
  • private int s ...
  • public IntStack(int c) ...
  • // ensure s / null
  • public void push(int e) ...
  • // ensure scount e
  • // ensure for i in 1..count-1 do
  • // si old si
  • public void pop() ...
  • // ensure for i in 1..count-1 do
  • // si old si
  • ...
  • //--FRAME AXIOMS--//

24
Model-based Spec. and Impl.
  • Implementation/Representation invariant
  • Assertion characterizing the set of concrete
    objects that are implementations of the abstract
    objects (cf. class invariant).
  • Abstraction function
  • Maps a concrete object (satisfying
    representation invariant) to the corresponding
    abstract object.
  • Usually onto but not one-one.

25
Bugs
  • A run-time assertion violation is a manifestation
    of a bug in the software.
  • Precondition violation Bug in the client.
  • Postcondition violation Bug in the supplier.
  • Error
  • A wrong decision made during software
    development.
  • Defect
  • The property of a software that may cause the
    system to depart from its intended behavior.
  • Fault
  • The event of a software departing from its
    intended behavior.

26
Failure
  • A routine call fails if it terminates its
    execution in a state that does not satisfy the
    routines contract.
  • Violates postcondition or class invariant.
  • Calls a routine whose precondition is violated.
  • Causes an abnormal OS signal such as arithmetic
    overflow, memory exhaustion, etc.

27
Exception
  • An exception is a run-time event that may cause a
    routine call to fail.
  • Every failure results from an exception, but not
    every exception results in a failure (if the
    routine can recover from it).

28
Disciplined Exception Handling
  • Rescue Clause
  • Retry
  • Attempt to change the conditions that led to the
    exception and execute the routine again from the
    start (possibly, exploring alternatives).
  • Software fault tolerance.
  • true Retry_Body Inv and Pre
  • Failure
  • Clean-up the environment (restore the invariant),
    terminate the call and report failure to the
    caller.
  • true Rescue_Body Inv

29
Developer Exceptions
  • Exceptions are propagated up the call chain
    (dynamic).
  • A supplier code can define an exception and raise
    it, to enable context-sensitive handling of the
    exception by the various clients.
  • In Java, an exception is a typed packet of
    information (object), which is useful in locating
    and diagnosing faults. Checked exceptions
    contribute to robustness by forcing the client to
    process exception explicitly, or propagate it
    explicitly.
Write a Comment
User Comments (0)
About PowerShow.com