Conference Room Scheduling System

Note: This project MUST be written in Java, if you do not know Java it would be unwise to wait until the implementation portion of the project to learn it!!!!

System Description

You are designing a conference room scheduling system for use by a university to reserve classrooms and conference rooms in different buildings on campus. The system will need to be used by instructors, secretaries, and administrators to reserve rooms. Access will be controlled to prevent unauthorized scheduling and to ensure that no one can cancel a reservation made by someone else unless they have been granted. An exception to this is a sub-set of users with administrative privileges. 

The system will include a schedule client that will display a schedule of weekly meetings from Monday through Friday, 8:00 through 5:30. This client will be developed using a TableBean developed by George Heineman. An example of its use can be seen in this applet, shown below:

You'll notice this example only shows Monday through Friday. You will be given all the code used to create this applet and can modify it to meet your needs. The code is located in the zip file ScheduleFiles.zip.

Functionality

The first assignment for this project will be to write the requirements for the Conference Room Scheduling system. Here are some requirements from a precursor meeting scheduler to get you started:

• Add a meeting in a specific room for times specified using the TableBean interface. The user should use the mouse to select a region from one of the table Beans. If the user selects a column (for example, by clicking on the entry for Tuesday) then the meeting should be from 8:00 until 5:30. If the user selects a row (for example, by clicking on 11:00 until 12:00) then the same meeting will be scheduled each day for an hour starting at 11:00.

  An exception should be thrown when a user attempts to schedule a meeting during a time slot that is already occupied.
  

• Cancel all meetings that are wholly contained in the time region selected if you are the person who created the meeting.
  
• Show the schedule for the previous week
  
• Show the schedule for the week one month back
  
• Show the schedule for the next week
  
• Show the schedule for the week one month in the future
  
• After each meeting is canceled or added, meetings should be sent to a Meeting Server. This will allow the system to be multi-user.

Assignments (All are group projects)

Project #1: System Requirements

The above list gives some ideas on what the requirements would be for the system but there's much more to it than that. Requirements need to be developed for the three parts of the system: the Meeting Client, the Meeting Server, and the Administrative Interface. 

Bruegge and Dutoit give an outline for a Requirements Analysis Document on page 152. For this assignment, write a partial requirements document for the Conference Room Scheduler. We will leave sections 3.5.3 (object model) and 3.5.4 (dynamic models) for the next project. 

For the rest, make the following assumptions and/or simplifications:

Section 2: Current System - assume the system this would replace is the system currently used in the CS department to schedule rooms.

Section 3.4.1: Scenarios - this section will be omitted.

Section 3.4.2: Use Cases -  list all the use cases for the system with a brief description. Then, write more detailed descriptions of the following use cases:

• Add Standard Meeting
• Cancel Meeting
•  Add New User
• Edit Conference Room Information

Section 3.4.5: User interface - draw mock-ups/story-boards for all the displays in the system. This can be done in PowerPoint or any other preferred drawing tool. It would be a good idea to do these before the Use Cases.

Project #2: Analysis 

In this project, the Requirements Analysis Document is completed. Again, this will be simplified somewhat and it will not be a complete document.

Any problems pointed out with the first project (or any you discovered since turning it in) should be corrected. Then the work should concentrate on section 3.4.3 and 3.4.4 (p. 200 in text).

3.4.3: Skip the data dictionary but generate class diagrams for the system. Identify entity, boundary, and control classes. You should identify methods by name but do not need to provide method signatures.

3.4.4: Write sequence diagrams for the four use-cases that were detailed in Project #1.

Project #3: Design 

For this project, you will complete four documents. The first will be the System Design Document outlined on p. 283 of your text. The second will be the object design which will be done by writing JavaDoc comments for all your classes describing the class, attributes, and methods. The third will be a class diagram showing how your classes interface with each other (including multiplicity, aggregation, and inheritance). Your design documentation should make it clear exactly how you will be using the TableBean provided as part of your scheduler. The fourth document will be the XML schemas that define how the different pieces of your meeting scheduler will communicate with each other. This should also include some example validated XML for the different messages.

The goal here is to describe your design in enough detail that the implementation should be fairly straightforward. Glossing over details here will mean both a lower grade and more work you will have to do during the final project.

Project #4: Implementation and Testing

This project has two parts. First, you should write a test plan for how you will test your system. The test plan  and test case specifications should follow the format shown on pages 476 and 477 of your book. 

You will be demonstrating your project on the last day of class.