Week 02 Notes for CS 2500, Section 001 -- Spring 2006

• Take Roll.
• Announcement(s)
  • Problem: I'm not getting any questions in office hours, or by e-mail. Why isn't anyone telling me about "snags"? Is the information in "Gotcha's" enough to take care of all?
  • Take care of add forms
  • AMP is paying for a facilitator/tutor for cs1500 & cs2500.
    Jeremy Hinshaw will be the facilitator/tutor and his hours will be:
    • Mon & Wed 9:00am to 10:00am
    • Tues & Thurs 4:00pm to 5:00pm
  • Students joining the course need to go through the formal ADD procedure. You can take care of it at MSR building. Done? Census date is Monday, March 13.
  • Discuss with class what they should have turned in for the "Hello World" assignment.
  • Look at the schedule
  • Progamming I is a prerequisite for programming II, and students without prerequisites may be dropped by the instructor. See me after class if you have not passed the equivalent of CS 1500.
  • The first programming assignment is in place online.
  
  
  
• Show class where to get Jove handouts online:
  • Jove Help
  
  
• Discuss top-down program design methodology using online examples of level-one through level-three programs, or other programming problem.
  
  
  1. First create a header comment for the program. Use the specs in the assignment to create your description of what the program does.
     
     
  2. Invent your algorithm: Conceive of a method for solving the problem. The method must involve just a few steps. Keep the number of steps small - maybe 3-4 major steps - by not including much detail at this level. A function must not take up more than about 24 lines of code (a "screenful"). Less is better.
     • The algorithm must be complete: All required tasks of the algorithm are covered by the steps given, even though many details may not be explicitly mentioned.
     • The steps of the algorithm must be in the correct order.
     • Getting the "order" right includes putting some steps inside a loop, if-else, or other control structure, where required for correct operation.
     
     
  3. Next translate the algorithm into C++, making it into your main function.
     
     
  4. Make "steps" of the algorithm into function calls in the main function. Use good mnemonic names for the functions. Include parameters in the calls.
     
     
  5. Start thinking about data flow. Put the variable declarations you need into the main function, and insert the parameters you will need into the function calls. Write prototypes for the functions. This will "force you" to finish thinking through the data flow considerations. You will have to determine what all the parameters will be and their data types. Remember to think about whether each parameter should be a value parameter or reference parameter (the kind with which you use the '&' in C++).
     
     
  6. Create stubs for the function calls in the main program.
     • Begin each stub by writing a header comment telling what the function will do when completed. (In other words, the header does not tell what the stub function does. It tells what the completed function will do.)
     • Next write code for the stub function. Usually a stub writes a message to let the user know when it is executing. The stub must also return a value if the caller expects one. If the caller expects the function to set the values of other parameters or variables, the stub must do that. Usually the programmer just picks arbitrary values for the stub to return or set.
     
     
  7. Compile and test the program. Fix any problems with the main function and stubs.
     
     
  8. When everything checks out, start expanding stubs into completed functions. How do you do that? Basically you just perform the steps above all over again. Now you are working on a function at the next level down instead of the main function. You must still defer detail. Include only enough detail at each level so that the function has just a few steps.
     
     
  9. You work like this over and over, going down level-by-level. Eventually, there will be steps to fill in that are so simple that they can be coded directly into just one or two C++ statements. Once you reach this "bottom level" everywhere in the program, you are finished writing it.
     
     
• Discuss program testing strategies and requirements.
  • Data Coverage -- Black Box Testing
    • Average inputs
    • inputs near and on boundaries
  • Code Coverage -- White/Clear Box Testing
    • Statement Coverage
    • Path Coverage
    
    
• Show example of reading e-mail on the Sun Ultra's.
  
  
• The compiler command option for naming the executable file:
  (g++ -o letters letters.cpp)
  
  
• Discuss compiling/debugging with jove
  • How to execute the compiler "inside" jove: (C-u, C-x, C-e)
  • C-x 1 "unsplits" the screen.
  • How to break out of jove to a sub-shell whilst "saving your place": (M-s)
  • Testing the program while in the sub-shell.
  • How to break out of the sub-shell and return to "your place" in jove: (exit)
  
  
• Consider problems related to second through final levels of assigned programming problem
  
  
• Look at Notes on Recursion