What should the level-one program look like?

• The level-one program needs documentation for the main program and for the functions called by the main program (they are called level-two functions)
  
  
• The documentation for every function must tell what the function will do when it is completed.
  
  
• In the level-one program you need to finish the code for the main function.
  
  
• In the level-one program you need to have stubs for all the level-two functions.
  
  
• If you follow my suggested design the main program will have some declarations of variables, perhaps some function prototypes, perhaps an initial call to askPermission, and a loop containing calls to getParams, getImage, doTileJob, and askPermission.
  
  
• If so, the level-one program will need to have stubs for askPermission, getParams, getImage, and doTileJob.
  
  
  • The stub for askPermission could just write a line to standard output identifying itself (so you can tell when it executes), and return "true". It's important to return a value, because the main program tests it, and needs a certain value to proceed. Be aware that if the function simply returns "true", when you test the program it will get into an infinite loop that you'll need to abort with a ctrl-c. That's OK, but kind of inconvenient. You could also define a global variable "REPEATS" at the beginning of the program file, initialize it there to equal 0, and put code in the stub that adds 1 to "REPEATS". You could code the stub so that it returns "true" if "REPEATS" has not reached some ceiling value, but returns "false" otherwise. If you did that you'd be forcing the main loop to stop after a certain number of repetitions.
    
    
  • The stub for getParams doesn't necessarily have to do anything except print a message, but if you have time it would be good to write the stub so it assigns values to the parameters, and so the message it print tells what those values are. Doing this will help you monitor the "data flow" of your program. (Keep reading for more information about this.)
    
    
  • The stub for getImage can print a message identifying itself. If you have time to work on this, write the getImage stub to give values to its output parameters and to write the values of all its simple parameters in the message. (Don't worry about trying to write the buffer - it's not simple enough.) Note: You will learn from this whether or not the filename parameter was correctly transferred to the getImage stub - an aspect of "data flow".
    
    
  • The stub for doTileJobs can print a message identifying itself. If you have time to work on this, write the doTileJobs stub to write the values of all its parameters in the message. When you test the program you will be able to check that doTileJob gets correct parameter values - more information about "data flow".