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. Authenticates is done via htaccess
• User to view the current bookings of a selected resource
• User to book a reource, 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 an iterated 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 upload it to the course server. You create the war file via the export utility of your IDE or, if you are not using an IDE, by simply issuing the command “jar -cf x.war y” while in the webapps directory, where x is eFcode and y is the name of your webapp (which could be x too). Then, upload the war file to http://red.cse.yorku.ca:4413 using the manager's facility (password the same as your own tomcat). Your app 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 should include 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, representations, 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 or shortcoming of the finished webapp with respect to requirement.
3. The Team: Provide the cs# 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 was communication and consistency 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 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.