COP 3223H meeting -*- Outline -*-

* Developing Programs by Stepwise Refinement

  Based on the article
        Niklaus Wirth. "Program Development by Stepwise Refinement",
        CACM, April 1971, Vol 14, Num 4, pp. 221-227.
        Reprinted in CACM Jan. 1983, Vol 26, Num. 1, pp. 70-73.

** general idea: divide and conquer

------------------------------------------
HOW TO SOLVE COMPLEX PROGRAMMING PROBLEMS?

A general strategy: divide and conquer




Picture:











------------------------------------------
    Q: What is meant by using a divide and conquer strategy?
    Break up the problem into smaller pieces,
    solve each,
    then put them together to solve the entire problem


    Draw a picture like:

                   Complex Problem
                   /      |      \
                Prob 1  Prob 2   Prob 3
                       / | \     

    which might be something like (for a bank):

                  Reconcile Accounts
                  /      |       \
               Input   Reconcile  Output
             Records   /  |   \   Report


    We'll try to flesh out such pictures

** background
*** problems and specifications
------------------------------------------
       PROBLEMS AND SPECIFICATIONS

def: a problem is a desired
     relationship between


So a problem is essentially a 



Can be expressed as:

    precondition:

    frame condition:

    postcondition:



------------------------------------------
     ... inputs and outputs

     ... specification of this relationship

     ... gives assumptions about when problem applies

     ... says what can be changed

     ... describes how the changed things (or result)
         relate to the old things

*** correctness
------------------------------------------
            CORRECTNESS

def: An implementation, C, is *correct
   with respect to a specification*, S,
   iff






Example:
    // requires: true
    // modifies: x
    // ensures: x > y
    extern void make_greater(int x, int y);

Which is a correct implementation?

    // (a)
    void make_greater(int x, int y) {
          y = x-1;
    }

    // (b)
    void make_greater(int x, int y) {
          x = y+1;
    }

    // (c)
    void make_greater(int x, int y) {
          x = 3223;
    }
   
------------------------------------------
   ... for all inputs allowed by S (the precondition)
       C only changes things allowed by S's frame condition
       and the relationship between the old values and new
       is given by S's postcondition.

   ... (b) is correct
       (a) modifies y instead of x
       (c) doesn't always work (consider if y == 5000)

------------------------------------------
        MEANING OF A SPECIFICATION

def: the *meaning of a specification*, S,
     is




What is the meaning of:

    // (easy)
    // requires: false;
    // modifies: everything;
    // ensures: true
    extern void easy();


    // (impos)
    // requires: true;
    // modifies: everything;
    // ensures: false
    extern void impos();


    // (chaos)
    // requires: true;
    // modifies: everything;
    // ensures: true
    extern void chaos();


------------------------------------------
        ... the set of programs that correctly implement S.

        Q: How big is that set?
        Could be infinite.

*** refinement
------------------------------------------
             REFINEMENT

def: a specification Conc *refines* Abs
     iff




------------------------------------------
     ... every correct implementation of Conc
         is also a correct implementation of Abs

         (Can use square version of >= (]=) for "refines")

     Q: Can program code be used as a specification?
        Yes, 

     Q: If we consider code to also be a specification,
        then what does code C refines specification A mean?
        That C is a correct implementation of A

     Q: Suppose C refines A. Which is harder to implement, C or A?
        C, as any correct implementation of C also implements A