Differences

This shows you the differences between two versions of the page.

--- theproject [2010/11/24 14:24] – roumani
+++ theproject [2010/12/07 21:27] (current) – roumani
@@ Line 14: / Line 14: @@
 The system must support of the following use cases:
-  * User to login. Authenticates is done via htaccess
+  * User to login. Authentication done via htaccess
-  * User to view the current bookings of a selected resource
+  * User to view the current bookings of a selected resource and time
-  * 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 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 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".
+  * 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.
 ===== Deliverables =====
-You need to deliver three things by the due date of this project:
+You need to deliver two things by the due date of this project:
-    * Submit the report and source files
+    * 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''
-      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:
+Create a war file of your webapp and name it ''eBook//n//'', 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:
-  - 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.
+  - 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.
-  - 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.
+  - 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.
-  - 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.
+  - 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.
-   - 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 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.