We at IMSA have solicited five software companies for bids in the creation of our Integrated Racing System (IRS), however after the initial round of review we are still unable to decide on a vendor. In fact, we are still somewhat unclear on what each vendor claims they will provide.

The members of the IRS reveiw team are fully versed in OO technology, as well as COTS, ORS, KAPS, SMERSH, CAD/CAM, OED, TCP, and GDD. Therefore we are requesting a second round from each company that fully details the design of their proposed system, as follows:

1. The design should include full class definitions for all the classes in your object model you deem relevant to the system. These definitions should appear in separate interface files for each major class under RACING-THING (i.e. PERSON is a major subclass of RACING-THING and should be defined in a separate file, but DRIVER is a subclass of PERSON and can be defined in the same file as PERSON.)

2. For each class in your system, identify the person in your group that will be responsible for that class. See the management issues below.

3. In the Users section below, there is a list of the types of access I would like for each kind of user of the system. Generate at least one user scenario for each subclass of PERSON. Before proceeding to the implementation step for this project, have your user scenarios approved by me.

4. Identify the responsibilities for each class in your system. Pay careful attention to the services the class will provide. Follow the recommended approach on page 66 of [UML]. Careful planning here will help determine a proper breakup of work responsibilites for class ownership.

5. Specify the behavior of each class of objects. It is acceptable for some classes to have behaviors subsumed by their superclasses. Use the recommended approach on page 79 of [UML]. Again, careful planning here will help determine a proper breakup of work responsibilites for class ownership.

6. Implementation: For the class PERSON, define a virtual method called user-menu(), that should be implemented for each subclass of PERSON according to the rules outlined below (in the Users section). Test your virtual functions by writing a simple program that requests the type of user, instanstiates it, and then calls the user-menu() method. Your initial implementation of user-menu() need only present a simple menu of options at this point.

Management Issues

Your project implementation should be organized such that there is a central directory in one of your member's accounts. This directory should be group readable, writeable, and executable to your SDM group (the UNIX names for each of your groups is listed on the main course web page).

The contents of this directory must be only the following:

1. A Makefile (if you choose to have one)
2. The .o files for each class implementation.
3. the .h files for each class interface.
4. A file (or files) containing your main function and any other functions not associated directly with a particular class.

Each group member must keep their class implementations in a private directory in their own acount. This directory should not be readable, or writeable to members of your group, nor should your implementation files. The directory may be executable to allow linking to your .h files if you would like to keep originals in your home directory.

When submitting, each group member submits their directory, and the group member with the group directory should submit the whole group project as well. You must let me know by email which user this is for each group

User Types

Fans should be able to access information about driver points and standings in the drivers championship, team points and standings, and manufacturer points and standings. They should also be able to look at the results of any race, see the schedule of races, or see the current state of a race being run in terms of car positions.

The Press should be able to do anything a fan can, and as well should be able to access team information such as finding all the team members.

Team members should be able to view any information about their own team, and should be able to change/update it.

IMSA staff should be able view or change any information in the system.