COP 2224 C++ Programming
Programming Project #3
(Due Tuesday, December 12, 2000, by the start of Class)
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.
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
This program has many creative features, you should not simply
imitate this program!
(Invent your own design, user interface, and feature set.)
- 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
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.)
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.)