The class bowlingAlley is designed to allow a user to manage groups of patrons using the lanes in a bowling alley. In this initial implementation each group will be represented by a last name (e.g., by a string such as "Bowler"). The bowlingAlley class will allow users to add and remove groups and to query for information about the status of the bowling alley and individual groups.
Notice that the inclusion of a group in a bowlingAlley object does not imply assignment to a particular lane in the bowling alley. We are not concerned with which lane was assigned, but whether or not a lane was found for the group. Also, we only allow a group to use a single lane. As a result, there may be no duplicate names in the bowlingAlley object.
You have been provided the header files bowlingAlley.h and bowlingExceptions.h defining the class bowlingAlley and the appropriate exceptions. Your task is to implement the member functions for the class bowlingAlley. This implementation should be contained in the file bowlingAlley.cc. You may not change the class definition in any way.
In addition to your implementation of the member functions, you must write a thorough test program for your implementation of these class members. This file should be called main.cc. Some of the issues you should consider are:
Some of these issues refer to a single member function, others can affect several functions. It is likely that your test program will be longer than the implementation of the member functions.
Because main.cc is likely to be a large file, you must carefully document your test program. In addition, you will be required to use a particular form of commenting in this file. When testing a concept, you must give an introductory header explaining what is being tested. This header should be delineated using lines of percent signs. For example, after you have successfully filled a bowlingAlley object, you should test to make sure the bowlingAlleyFull exception is thrown if another group is inserted.
//%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
// myBowlingAlley is now full. Now test to make sure a call to
// assignGroup throws the bowlingAlleyFull exception.
//%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
try
{
myBowlingAlley.assignGroup("More Than Full");
cout << "Error: bowlingAlleyFull not thrown on assign when full\n";
}
catch(bowlingAlleyFull)
{
cout << "Exception caught on assign when full\n";
}
Your test program may not be interactive or menu driven. It should be a linear sequence of calls to the various functions using hard-coded data.
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.
For this assignment you will need to use the C++ string manipulation library. For a review of C++ strings and string operations, see pages A32-A34 in your text.
You may be literal about comparing strings. For example, treat "Bowler" as distinct from "BOWLER".
You will use your implementation of project 1 in future projects. As a result, we will have multiple versions of the files bowlingAlley.h, bowlingAlley.cc, etc. It is recommended to create a separate folder for each project.
To submit your files for grading, place bowlingAlley.h, bowlingExceptions.h, bowlingAlley.cc, and main.cc in the same directory, and at the prompt in that directory enter:
~radu/bin/submit CS241 project1
If you are using a slip day for this project, you must submit with:
~radu/bin/submit CS241 project1late
Your submission will fail if the project does not compile.
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: