1. Brief Description
2. Flow of Events

   2.1    Basic Flow - Add a Professor

   2.2    Alternative Flows

                          2.2.1    Modify a Professor

             2.2.2    Delete a Professor

                          2.2.3    Professor Already Exists

             2.2.4    Professor Not Found

3. Special Requirements
4. Preconditions

   4.1    Log In

5. Postconditions
6. Extension Points

1. Brief Description

This use case allows the Registrar to maintain professor information in the registration system. This includes adding, modifying, and deleting professors from the system.

The actor of this use case is the Registrar.

The use case begins when the Registrar selects the "maintain professor" activity from the Main Form.

2.1    Basic Flow - Add a Professor

1. The Registrar selects "add a professor."
2. The system displays a blank professor form.
3. The Registrar enters the following information for the professor: name, date of birth, social security number, status, and department.
4. The system validates the data to insure the proper data format and searches for an existing professor with the specified name. If the data is valid the system creates a new professor and assigns a unique system-generated id number. This number is displayed, so it can be used for subsequent uses of the system.
5. Steps 2-4 are repeated for each professor added to the system. When the Registrar is finished adding professors to the system the use case ends.

2.2    Alternative Flows

1. The Registrar selects "Modify a professor."
2. The system displays a blank professor form.
3. The Registrar types in the professor id number he/she wishes to modify
4. The system retrieves the professor information and displays it on the screen
5. The Registrar modifies one or more of the professor information fields: name, date of birth, social security number , status, and department.
6. When changes are complete, the Registrar selects "save."
7. The system updates the professor information.
8. Steps 2-7 are repeated for each professor the Registrar wants to modify. When edits are complete, the use case ends.

2.2.2     Delete a Professor

1. The Registrar selects "Delete a Professor."
2. The system displays a blank professor form.
3. The Registrar types in the professor id number for the professor that's being deleted.
4. The system retrieves the professor and displays the professor information in the form.
5. The Registrar selects "delete."
6. The system displays a delete verification dialog confirming the deletion.
7. The Registrar selects "yes."
8. The professor is deleted from the system.
9. Steps 2-8 are repeated for each professor the Registrar wants to modify. When the Registrar is finished deleting professors from the system, the use case ends.

2.2.3     Professor Already Exists

If in the "Add a Professor" sub-flow, a professor already exists with the specified name, an error message, "Professor Already Exists", is displayed. The Registrar can either change the name, choose to create another professor with the same name, or cancel the operation at which point the use case ends.

2.2.4     Professor Not Found

If in the "Modify a Professor" sub-flow or "Delete a Professor" sub-flow, a professor with the specified id number does not exist, the system displays an error message, "Professor Not Found". Then the Registrar can type in a different id number or cancel the operation at which point the use case ends.

    3.    Special Requirements

There are no special requirements associated with this use case.

    4.    Preconditions

            4.1    Log In

Before this use case begins the Registrar has logged onto the system.

    5.    Postconditions

There are no postconditions associated with this use case.

    6.    Extension Points

There are no extension points associated with this use case.