The purpose of this project is to extend the implementation of the bowlingAlley class from project 1 to include more information about each party of bowlers. This will be accomplished using a new class named party. Each instance of party will contain the party name, telephone number, number in party, arrival time, departure time, number of games bowled, and number of shoes rented.
You have been provided the header files bowlingAlley.h, bowlingExceptions.h, party.h, and IOExceptions.h defining the classes bowlingAlley and party, and the appropriate exceptions. Your task is to implement the member functions for the class party and to modify your implementation of the bowlingAlley class to incorporate parties. This code will be contained in the files bowlingAlley.cc and party.cc, as appropriate.
As with project 1, you must write a thorough test program for your implementation of these two classes. Your test program should be contained in the file main.cc and should be documented using the "percent block" comments.
The Guidelines for Programming Projects apply. You are also subject to the Guidelines for Programming Assignments, issued by the Department of Computer Science as an addendum to The Honor System.
The default constructor for the party class should not initialize the data members. The only reason this constructor is present is so the output statement shows where it is utilized.
The functions party::printOut, party::readIn, and bowlingAlley::displayGroups all take streams as a parameter. It is the user's responsibility to call these functions with streams that are prepared for input or output (as appropriate). In each function, if the stream enters the fail state, the appropriate exception should be thrown.
You may continue to be literal about comparing strings in the party class. For example, treat "Bowler" as distinct from "BOWLER".
Because the functionality of the bowlingAlley is unchanged, assuming you were careful in your implementation of project 1, most of the changes to bowlingAlley.cc should be minor. In addition, the types of tests used in your test program should remain fairly constant.
Do not edit your files from project 1 directly - make copies! It would be advisable to create a new folder for each project.
To submit your files for grading, place bowlingAlley.cc, party.cc and main.cc in the same directory, and at the prompt in that directory enter:
~radu/bin/submit CS241 project2 *.dat
If you are using a slip day for this project, you must submit with:
~radu/bin/submit CS241 project2late *.dat
Your submission will fail if the project does not compile. The submit program does not count slip day usage, but the graders do.
The third parameter to the submit program allows you to submit your input files (up to three extra files). Input files should have the extension .dat (e.g. input.dat, goodinput.dat, myinput.dat, etc.)
The implementation points cover both correctness and efficiency. It is not enough to turn in a program that compiles and executes. The graders will scrutinize the implementation of the member functions and will deduct points for poor design decisions even if your program runs correctly on all reasonable input.
The style points cover poor programming style that needs to be addressed and a lack of useful comments within your program. In addition, graders may deduct style points for implementations that will work but could lead to difficulties or inefficiencies as we proceed on to future assignments.
When grading your test program, the graders will look for evidence that you considered the various implementation issues in this class. Even if your code works, you will be penalized for not testing that it works. This also means that you can lose points twice for the same issue: once in the implementation and again for not performing proper testing (which would have identified the first).
Some specific things the graders will be looking for: