EECS 370 – Software Design – Spring 2000

Homework Assignment 1

Due:    29 January.  The electronic copy is due 30 minutes before class ( 9:30 or 2:30 ).

Overall Assignment

For this assignment you are to create a calendar system for recording appointments and birthdays, using a variety of different structures.

Structures

You will need to implement the following structures, containing at least the following information:

Structure Name

Information

Appointment

The time of the appointment and a character string describing the event.

Birthday

The name of the person whose birthday is on this date.

Day

List(s) of appointments and/or birthdays for this date.

Month

A list of days in the month for which appointment or birthday information is stored.

Year

A list of months in the year for which appointment and birthday information is stored.

These structures are to be allocated dynamically as needed, and should be inter-connected using pointers.  ( I.e. a year structure should NOT simply contain an array of month structures. )  You should not create any excess structures for which there is no data to store.  ( I.e. do not automatically create 12 Months for every Year or 31 Days for every Month. )

Specific Input

Your program should read a series of commands from the standard input, one command per line.  The first character on the line will be either a 'Y', 'A', 'B', 'S', 'I', 'O', or 'Q" ( in either upper or lower case ), with the remainder of the line having varying information as follows:

·        Y <year>

Set the current year. The default year is the present year ( use the time( ) library function ).  The prompt  for the input should list the "current" year.  I.e.

        2001> y 2002

        2002> y 1999

        1999>

·        A <month> <day> <hour> <minute> <description, which may include spaces >

Enter an appointment for the time, date, and description given.  The month, day, hour, and minute values are given as space-separated integers. You are to perform error checking to validate the month, day, hour and minute values.

·        B <month> <day> <name, which may include spaces >

Enter a birthday for the person given.  The month, and day values are given as space-separated integers.  Note that birthdays occur every year. You are to perform error checking to validate the month and day values.

·        S <month1> <day1> <month2> <day2>

Show all of the Birthday and Appointment info for all days starting with <month1>/<day1> of the current year until <month2>/<day2> of the current year, in chronological order.  For each day the Birthday info is to be listed first, followed by the appointment info sorted by time.  Exact form of this is left to the student. You are to perform error checking to validate the month and day values.

·        I <filename>

Read commands from the given file.  Inside of this file all commands except I can be used ( eliminates a recursive command sequence ).  When the end of the file is reached, the program should resume reading from the standard input.

·        O <year> <filename>

Write current stored data for the given year to a file.  This file should write out the data in form of the Y, A, and B commands, so the file could be read in with the I command.

·        Q

Quit the program.  The program should immediately free up dynamic memory and then quit, regardless of whether Q is encountered in a file or from the standard input, and regardless of whether additional input remains to be read.

Command Line:

This program should accept one optional command line argument, as the name of a file from which to read commands.  If the filename is present, then the program should read from that file first before reading from standard input.

Sample Input:

Y 2000

A 1 16 17 0 Art Institute Evening Associates Meeting

A 2 13 18 0 EECS 370 Mid-term Exam

B 9 12 George P. Burdell

I MyBirthdays.dat

Y 2001

A 1 8 8 30 Meet with Dr. Esperdy at B.I. Chemicals

B 12 20 Joe Student

A 5 27 12 30 Lunch with Mr. Jones

Y 2000

S 1 1 3 31

O 2000 y2k.dat

Q

Output

The output of this program is in response to the S command, as described above.  Note that only the results should be directed to standard output.  Any prompts, messages, or other non-result output should be directed to standard error.

Implementation Notes

·        You are encouraged to use any features of C++ that you wish, including those not yet covered in class.  I.e. you are allowed to either read ahead or make use of previous knowledge.  However note the two exceptions ( classes and template libraries ) given below:

·        You are not allowed to use classes for this assignment.

·        You are not allowed to use template libraries ( STL ) for this assignment.  You may use the standard stdlib, stdio, iostream, iomanip, math, etc. libraries.

·        You may augment the data structures listed above as you wish, such as adding a field for the name of the month or a flag in the calendar to indicate a leap year.

·        Note that all structures are to be allocated dynamically, as are the character strings contained therein.

·        The output results are to be printed in chronological order.  Whether you choose to store the data in order or sort it while printing is left to the programmer's discretion.

·        Birthday information is independent of any particular year.  Whether to store ( links to ) the birthdays for every year or to have a separate storage for birthdays is left to the programmer to decide.

·        The format of the output is left to your discretion, but should be logically organized and easily read. 

·        Do not name your program "calendar", because that conflicts with a UNIX system utility.

What to Hand In:

1.      Your code, including a makefile and a readme file, should be handed in electronically using the turnin command ( see below ).

2.      The makefile should be set up so that the grader can simply type "make" to build your executable program.  The name of the resulting executable should be "myCalendar" ( Note case. )

3.      The purpose of the readme file is to make it as easy as possible for the grader to understand your program.  If the readme file is too terse, then (s)he can't understand your code; If it is overly verbose, then it is extra work to read the readme file.  It is up to you to provide the most effective level of documentation.  The readme file should be a plain ASCII text file named "readme" or "readme.txt".

4.      There is no requirement to hand in any printed material.  However, if you feel that your program can best be explained through materials that cannot be handed in electronically, ( such as hand-drawn sketches or diagrams ), then you may hand in supplemental printed material to the TA at the beginning of class.

5.      Make sure that your name and your section appear at the beginning of each of your files. 
Your program should also display this information when it runs.

Other Notes:

·        The correct turnin command for the 10:00 section is:

turnin -c eecs370 -p hw1 < files >

·        The correct turnin command for the 3:00 section is:

turnin -c eecs370a -p hw1 < files >

·        Note carefully that every time you submit files to a given project using turnin, it replaces any files that you had previously submitted for the same project.  It is therefore necessary to submit all files for a given assignment with a single turnin command.

·        As an exercise in reviewing other programmer's code, your program will be given to another student to critique.  Therefore do not put your student number or social security number anywhere in your program or documentation.  Use only your name and EECS user ID for identification.

·        Because we have not covered exceptions, you are allowed to overlook the fact that new might fail to allocate the desired memory.

Optional Enhancements:

This assignment provides you with several opportunities to enhance your program beyond what is required.  A few ideas include:

·        Defining a comment character, e.g. //, so that comments can be added to the data input file, either on separate lines or at the end of the data lines, or both.

·        Exception handling could be added to deal with "new" failures.

·        There are many other possibilities that you are left to consider for yourselves.

·        Documentation of enhancements:  Any enhancements added must be fully documented in the readme file, as a final section titled "Enhancements".

·        Grading of enhancements:  My recommendation to the graders is that it should be possible to receive 100% credit without implementing any enhancements, provided the rest of the assignment is perfect.  ( Yes, 100% means perfect in my book. )  Enhancements should not raise any grade above 100%, but may be taken into consideration to offset weaknesses in other areas to raise a grade closer to 100%.