COP 2224 C++ Programming
Programming Project #3

(Due Tuesday, December 12, 2000, by the start of Class)

Purpose:

To practice object oriented design, using multiple classes and objects, and basic design techniques such as encapsulation, abstraction, composition, and inheritance.  To practice good programming techniques, style, design, testing, and good program documentation, on a medium-sized programming example.

Description:

For this project you are to simulate a voice mail system.  The system has a collection of mailboxes, each of which may be accessed by a four digit extension number (7213 for example).  A user of the system may put a message into any existing mailbox.  Since we don't have the hardware to actually record voice mail messages available, we will fake this part of the system and simply have users type text messages in at the keyboard, after first typing in the extension.

Any user with a valid mailbox and its password may do any of the following:

• play back messages
• delete messages
• change the greeting
• change the password

(Additional features are up to your group.  Feel free to design the "perfect" voice mail system, but keep in mind the short amount of time available before you become too ambitious!)

In addition an administrator needs to be able to activate and deactivate mailboxes by using a special password.  (Anyone knowing the password is considered an administrator.)

A model solution can be downloaded and run.  This program has many creative features, you should not simply imitate this program!  (Invent your own design, user interface, and feature set.)

Project Requirements:

• This will be a group project.  Groups will be assigned in class.  All members of a group must participate in the project; each group member will be evaluated by the others.
• Your group must get together to analyze the problem and determine a set of classes that will be needed.  As you analyze, keep notes on the details of the project (for example, the user interface you decide on, or extra features you decide to attempt).
• Make up some scenarios or use cases and run through them.  Write down the responsibilities and knowledge the objects of your various classes must have.  It may help to use index cards; you can put one class one each card and as you run through your scenarios you can add to or remove from the card any responsibilities, knowledge, or helpers.  You may end up throwing away some cards or creating new ones.  This popular design technique is known as "CRH cards".  In the end, the responsibilities become member functions, the knowledge becomes properties, and the helpers listed become function calls (from this class’s member functions to other classes’ public member functions).  The better your CRH cards, the better your design will be.  For the responsibilities that become member functions, write down the return type and argument lists.
• Draw your design on paper, showing each class as a box (with a name and a major responsibility to go with it).  If objects of one class access members of another class, show this relation by drawing a line between the two classes.  Feel free to use UML or a simpler notation to document your design.
• Divide up the labor of the project so all team members have some classes to design, implement, and test. At this stage each team member can work independently.  Make sure the team member responsible for a class has his or her name listed in the comments as author.
• A team is only as strong as its weakest member.  Make sure you show up for all scheduled group meetings.  If you are assigned a class to build, do it.  Don’t let the team down!  If every member doesn’t do his or her part, the project can fail (and all team member’s will have their grade affected).  Also, be open to ideas from your team members.  Don’t be afraid to argue a point you don’t agree with or fully understand.  (It’s not personal!)  Remember there is no single right anwser.
• Take the time to write test drivers for your classes.  A test driver is a short program designed to try out all the features of a single class.  This program should call every public member function of an object of a class, and display the results so you can tell if the class is working correctly.
• If one class uses another, make sure you get the header file for that class so you can write your own class that uses it.  Your group will have to decide which classes should be designed and built first so everything goes smoothly.  Note the header files come before you implement any classes!!  Once you decide on the public members, don't change them or you will force other group members to rewrite and retest their code as well.
• Although not usually a separate class, the user interface (usually "main") must also be designed and built by some member of your group.
• In two weeks your design should be complete.  We will review the group designs in class at that time.
• In the end, your group will have a single multi file project to turn in.  On the due date, there will also be a confidential questionnaire to fill out, where you evaluate your and your group members’ performance.

To be turned in:

A 3.5" disk with your group's program on it.

A printout of your design (the CRH index cards can be turned in if you used this method).
A printout of your complete program.

The performance evaluation by every team member.  (Note these will be kept confidential, only I will see them.)

Additional Notes:

This should be a fun but practical and useful project.  Don’t hesitate to consult with your instructor with problems and questions.

Use the Keep it Simple priciple.  You can always add more features later!

Use inheritence and the STL where possible.

This project was adapted from a similar one by Rick Mercer in "Computing Fundamentals with C++", 2nd Edition.  (C) 1999 by Franklin, Beedle & Associates.  Pages 472-473, 513-515.  (The author lists Cay S. Horstmann’s "Mastering Object-Oriented Design in C++", (C) 1995 John Wiley and Sons, NY as his source for the project idea.)