CSE143

Winter 1999

Homework #3B 

"Please remind me..."

Part A (written recursion problems): due in quiz section Tuesday, April 20

Part B (programming): electronic turn-in due by Monday, April 26, 5:00 pm

It's not been your day.  First you forgot about the weekly quiz in Sociology; then your dentist called to say you would be billed $50 for not calling to cancel your root canal (which you had really looked forward to); and you would have missed that monthly Computer Club meeting if you hadn't accidently run into the president carrying pizza boxes just before the meeting started.  There's got to be some way you can get organized.  If only your computer could remind you... if only there was a program that knew what was scheduled and reminded you everyday... if only...

This program will give you a chance to work with input and output text files; to use a List ADT; to solidify understanding of classes and their implementation; and to continue the experience of working with complex, multi-file projects.  Where you can, be a good software engineer: build a program that is modular, fail-safe, robust, easy to use, easy to understand, etc.

The program you need should read in a text file with information about appointments and things to remember.   Some appointments are reccuring, like the weekly Sociology quiz.  Others might be one-time affairs, like a visit to the dentist.  Every day, the computer should pop up a "to do" list of activities for the day.  To keep the file cleaned up, the program can write out a new file before shutting down.  You can edit that file directly to add new appointments, and then start the program again. 

Getting Started

Run the demo program with the given data file and see what it does.  (Your completed program should behave identically, given that same file.)  Next, experiment with the data file.  Make a copy and change it a little or a lot (following the file formats you'll discover from browsing through the starter programs) and try the program again.  It's very important to understand exactly how the file needs to look.  This time, you will have to program the file processing yourself, rather than using functions we give you for it.

Now study the code that we've supplied.  Some of it you will have to stick with; other parts may need completion.  Some parts will require you to do some design.  In other cases you may be to start from scratch.  Try to understand everything you're given first.  Some of the detailed instructions (or hints) about what you are to do may be contained in the source files we give you, so it is important to look at them carefully.

Eventually, after you've spent some time studying the problem, create a project with the starter files, and try to compile and link.  This will give you further insight into what's missing.

You might find it helpful to develop a list of all the functions you need to implement, and where those functions belong.   In addition to a list, a call graph might be helpful.  For the most part, you can deduce what's needed by looking at the starter code, as you did with homework #2.  But you also might find it helpful to define additional helper functions.  Feel free to do this as long as it makes good design sense.  You won't be able to turn in modified versions of certain files, however.

What does the program have to do?

Essentially, it has to process datafiles correctly, and be able to step through the appointments, day by day.

We will later designate at least one datafile which your program must process exactly as ours does.  But your program has to be able to run properly with any file that has the correct format, not just the ones we give you in advance.  Create and test with at least one non-trivial data file of your own, and be prepared to turn in that file.  Another thing you should test is taking the file created by your program (give it a different name so you don't clobber the original) and restarting the program with new file as input.  We will ask you to turn in one of these output files, too.

A really well-engineered program should also be able to detect and report on errors in the file, and to recover gracefully.  This is something we are likely to expect you to do in future assignments.  The demo program does some of this.  You do not have to have this much error handling in your own solution to homework #3.  You do have to be able to loop until the user inputs a good filename, however, using the same messages as the demo program does.

The output file should be one that the program can process without detecting errors.   Also, the "today's date" timestamp line of that file (the first line), should always be tomorrow's date (the next day that the program would have displayed.   (The preceding is not going to make sense until you have looked at the files and run the programs a few times!)

The Date class

The Date class we provide is deliberately simple, and therefore has a few shortcomings.   You should be aware of them to avoid confusion, but for this assignment you should use the class as-is.

A Date has only concepts of month and day, not day of the week or calandar year.    You may notice two upshots of this:

  1. Adding one month to a date like January 30 will produce a date like February 30, which is invalid.  The demo program drops this repeating appointment, and so should your program.
  2. Adding to a date that would cause the new date to occur "next year" will also form an invalid date.  Again, we drop the new appointment, and so should you.

Datafile Structure

The data file has the following form:

  1. The first line contains the date that the program will understand to "today." It contains exactly one date of the form d/m and nothing else.
  2. The first line is followed by zero or more lines containing one appointment each.
  3. An appointment consists of a date of the form m/d, an optional periodic specifier, and a description of the appointment. An appointment must be fully contained on one line.
  4. A periodic specifier may be either 'm' or a non-negative integer. The character 'm' signifies that the appointment is to be repeated each month on the same day given in the preceding date, beginning on the month given in the preceding date. If the periodic specifier is an integer n, the appointment should be repeated every n days.
  5. An appointment description is a string enclosed by double quotes.
  6. The date, periodic specifier, and description must be separated by spaces or tabs.

Other internal requirements

Now that you are familiar with concepts like invariants, assertions, fail-safe programming, and the stylistic expectations of the class in general and your TA in particular: continue to apply what you know along these lines!  As your programs become more and more complex, you'll find the the effort you expend in those areas will repay itself at debug time.

Part B turn-in:

The completed .h and .cpp files, as well as the data input and output files.  As usual, you must print the receipt and turn it in to get credit.  Bring the complete materials to quiz section on Tuesday.  If you cannot do that for some reason, make arrangements with your TA to hand over the material at some other time.  Please do not place it in the homework box unless you have arranged that ahead of time with your TA.

You may not modify the following files (which means you don't have to turn them in):

You may change the following:

You must write the following files from scratch:

Other materials to turn in

As usual, write up and staple to the receipt the following three items:

  1. What works/what doesn't
  2. Design critique
  3. Statement of authorship and help received

Seem like a lot of things to remember?  Maybe a to-do list program would help you organize it all...