Week 06 Notes for CS 1500 -- Spring 2000
(this is draft material)

* Take roll

* Take a look at the schedule for the week. 

* Quiz #1 has been graded.  I am handing it back.

* Class grades -- more there.

* We have a lab scheduled for Friday -- top down
  design of a program to compute the maximum of
  two SAT scores.
  
* I have assigned a second Solo program.

* Lecture topic: The switch statement.

==================================================
WEDNESDAY
==================================================

* Take roll

* Take a look at the schedule for the week. Solo #2 program due
  date is new

* ANNOUNCEMENT:  I added structure chart to help with Solo #2
* ANNOUNCEMENT:  I simplified Lab04 by taking out step j.


* Lecture topic: Truth Tables for logical operators
* Lecture topic: De Morgan's Laws
    + Examples of Boolean Algebra, using concepts related to
      Lab 04 and Solo Program #2.

First Example:

      if (the score is not in range)

	// this "does not work"
	// It means something to the C++ compiler, but
	// it is not what you want it to mean
      if (!(0<=score<=800))

	// You say it this way to get what you want
	// This is correct, but complicated-looking
      if ( ! ( (0<=score) && (score<=800) ) ) 

	// We simplify by first using one of de Morgan's laws.
	// ! ( A && B) is the same as (!A) || (!B)
      if ( ! (0<=score) || ! (score<=800)  ) 

	// We finish simplifying by using the law of
	// trichothomy of numbers: If we have two
	// numbers x and y, either x > y, x = y, or x < y.
      if ( (0 > score) ||  (score > 800)  ) 
      

Second Example:

      if ( !( (dry || hot) && (dry || ventilated) ) )
         PlaceInDryer() ;

          // Using property 3a on page 195 
      if ( !(  dry || (hot && ventilated)  ) )
         PlaceInDryer() ;

          // Using De Morgan's law a, on page 196
      if ( !dry &&  !(hot && ventilated) )
         PlaceInDryer() ;

           // Using De Morgan's law
	   // (if it is wet,  and also cool or stuffy,
	   //  then we had better put the
           //  item in the dryer.)
      if ( !dry &&  (!hot || !ventilated) )
         PlaceInDryer() ;

* Lecture topic: Top Down and Bottom Up Testing
                 and Program Design Methodologies

* Lab04 gives you a step-by-step tutorial on how to design a
  program using top-down design (stepwise refinement).

  + The idea is to figure out what the major steps are to solve
    the problem.  Then write the main function, making the major
    steps into function calls.

    For example: the major steps of the Lab 4 problem are taken
    as: "give instructions," "read a score," "check to see if
    score is in range," and "compute maximum value."  In our
    design, we decide that each of these major steps will be
    performed by a function call.  We design a main function
    that solves the problem by relying on calls to these
    functions.

   + In the initial (level-one) version of the program, we
     write the actual code only for the main function.  The
     other functions must be included so that the program will
     compile and execute, but they are written to be simple
     "stubs" that perform only a few extremely simple actions
     -- just enough to keep the program going without running
     into trouble.

     For example the stub of the function that performs
     "compute maximum value" only writes a message to let the
     user know if and when this function executes, and it just
     returns the first input value so that something --
     anything -- will be returned when the main program tries
     to assigns the return value of the function to a variable.

     (To see this better, refer to the stub code for Lab04, and
     the Lab04 directions.)
   
   + The programmer can compile, run, and test the program
     after the main function and the stubs have been written.
     Often the programmer can get all the bugs out of the main
     function at this stage of testing -- while the called
     functions are still only stubs.

   + The programmer then replaces the stubs one at a time with
     the actual code required for the function.  The programmer
     compiles, runs, and tests the program after completing
     each function.

     This way, if there is a problem, it is almost sure to be
     due to something wrong with the particular function the
     programmer is currently working on.  (the fault is
     isolated to one particular area of the program.)  This
     means that very little time will be wasted looking for the
     location of errors in a program.

* You should create Solo #2 using top-down design too.  Follow
  the structure chart in the assignment directory.

* When time allows look at the tips in the assignment
  directory for Solo #2 and the structure chart.

--------------------------------------------------
* Reading topic: Header File for class specifications