A Web-Based Resource Booking System

• Due Date: Wed Dec 8, 2010 by 5:30 pm
• Technological Platform to be used: JEE

The system enables personnel to book resources, such as rooms or equipments, for their own use at specified times.

The system must support of the following use cases:

• User to login. Authentication done via htaccess
• User to view the current bookings of a selected resource and time
• User to book a resource, if available, at a specified time. Bookings can be done on the hour or on the half-hour for a duration that is a multiple of 30 min. You can assume that bookings do not span the midnight boundary.
• User to make a repeated booking of a selected resource. In such a booking, the user specifies the start and end dates, the start time, the duration, and the frequency. The frequency can be a given set of dates or selected from predefined classes, such as “Second Friday of Each Month” and “Every Monday”.
• The “admin” user to add, edit, or delete a resource. Each resource has an ID, a location, and a description.
• The “admin” user to delete bookings made by others. In that case, an email is auto-sent to them with a reason for the deletion.

You need to deliver two things by the due date of this project:

• Submit the report and source files
  The report file (in pdf, doc, or html formats) and the Java files. These can be submitted using: submit 4413 proj files

• Upload a WAR webapp

Create a war file of your webapp and name it eBookn, where n is your group number. Upload the war file to:

http://red.cse.yorku.ca:4413

Use the Tomcat Manager facility (name/password the same as your own tomcat) to upload your war file. Your webapp will auto deploy. If it does not run properly then the likely cause is a hard-coded path. You can fix the problem and re-upload as many times as needed (before the deadline) but make sure you stop or undeploy your webapp before re-uploading. Please do not undeploy someone's else webapp!

The report is meant to describe your execution of the project to someone who is familiar with the project, e.g. a fellow student who is also executing the same project and writing a similar report. Hence, the report should focus on your own experience and efforts, i.e. what you actually did, rather than on general description. It is expected to be very brief, to the point, and made up of at most ten pages of typed text and diagrams (excluding printouts and source listing).

The report have a title page containing the team member names and their cse numbers, the assigned group number, the course number and term. It should also have a TOC (Table of Contents) with titles and page numbers. Finally, it should have the following sections:

1. Design: Describe your system's architecture and data flow briefly (diagrams are ideal here). Also, several design issues and decisions must have popped up during the analysis and design phases, e.g. MVC, namespaces, file formats, algorithms, authentication, etc. Describe in this sections the key issues and decisions that were made and why they were made the way they did.
2. Implementation: This is similar to the previous part but pertains to implementation issues and decisions. This section should also include Testing and Status. The former discusses how the project was tested and the latter lists each and every limitation, shortcoming, or extra features of the finished webapp with respect to requirement.
3. The Team: Provide the cse# and name of each member of the team and indicate the contact person in case there are questions. It is essential that you explain how the work was divided and how communication and consistency were maintained. Include here the main lessons that were learned from this project.
4. The Source Code: Provide listing of all programs (including jspx, tags, xsl, web.xml, etc.). Partition this section into subsections, provide a title for each, and create an entry (title and page number) in the Report's TOC for each subsection. Make sure the code is properly formatted. Some editors do not format properly because they use spaces instead of tabs and/or use proportional fonts. Do not delay printing your code to the last minute; resolve this issue early on.

The project will be evaluated based primarily (80%) on meeting the specs (these include system functionality and report contents) and on its internal quality (design, style, code, etc.). The remaining (20%) is based on how your project compares with those of other teams.