Differences

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

--- project [2011/11/15 15:19] – roumani
+++ project [2011/12/02 04:42] (current) – roumani
@@ Line 20: / Line 20: @@
 ==== Use Case: A client makes a fresh visit ====
-The relevant URL is ''red.cse.yorku.ca:port/eFcode'' (where eF stands for eFoods and ''code'' is the project's code assigned to your team). Send an email to Prof Roumani indicating the team members and the contact person and he will issue a team code for you. The Catalog servlet displays the catalog of the Company. It is up to you to determine how this display is done based on how much time you want to spend on this task and on how versatile you want your webapp to be. For example, you can at one extreme display all the items in one page; you can show the hierarchy by displaying only the categories and then the selected items; you can enable both direct and category-based access; you can have a search facility; you can have an express order form for those who know the item numbers; you can enable clients to bookmark pages; etc. Whatever you do, the client must be able to see the item's number, name, quantity per unit, and price. The client must also able to add an item to an initially empty shopping cart.
+The relevant URL is ''red.cse.yorku.ca:port/eFcode'' (where eF stands for eFoods and ''code'' is the project's code assigned to your team). Send an email to Prof Roumani indicating the team members and the contact person and he will issue a team code for you. The Catalog servlet displays the catalog of the Company. It is up to you to determine how this display is done based on how much time you want to spend on this task and on how versatile you want your webapp to be. For example, you can at one extreme display all the items in one page; you can show the hierarchy by displaying only the categories and then the selected items; you can enable both direct and category-based access; you can have an express order form for those who know the item numbers; you can enable clients to bookmark pages; etc. Whatever you do, the client must be able to see the item's number, name, quantity per unit, and price. The client must also able to add an item to an initially empty shopping cart.
 ==== Use Case: A client adds an item to the shopping cart ====
-The Cart servlet must react by displaying the content of the shopping cart. The display should be tabular with one item per row. The table columns display the number, name, and unit price of each item in a read-only fashion. In addition, there should be a writable column for the desired quantity and a read-only one for the extended price (defined as the quantity times the unit price). The display should also indicate a total, PST and GST (based on Ontario), a shipping cost ($5 that is waived for orders of $100 or more before taxes), and a grand total. The page has three buttons: Update (to refresh the calculated fields after editing a quantity), Continue Shopping, and Checkout. Notice that if the entered quantity of an item is zero then it should be removed from the cart. You need to also handle the case of negative or non-numeric quantities.
+The Cart servlet must react by displaying the content of the shopping cart. The display should be tabular with one item per row. The table columns display the number, name, and unit price of each item in a read-only fashion. In addition, there should be a writable column for the desired quantity and a read-only one for the extended price (defined as the quantity times the unit price). The display should also indicate a total, a shipping cost ($5 that is waived for orders of $100 or more before taxes), HST (13% of total, including shipping if any), and a grand total. The page has three buttons: Update (to refresh the calculated fields after editing a quantity), Continue Shopping, and Checkout. Notice that if the entered quantity of an item is zero then it should be removed from the cart. You need to also handle the case of negative or non-numeric quantities.
 ==== Use Case: A client logs in ====
-Upon checkout or at anytime, a login form (normally transmitted over https) is served prompting for the client name, shipping address, and payment details. We are not going to switch to https in this project. Instead, we will continue to use http and we will assume that all clients have already established accounts with the Company, i.e. each client has a profile that contains the shipping address and payment preferences. Hence, the login form prompts only for the client's account number and password.
+Upon checkout or at anytime, a login form (normally transmitted over https) is served prompting for the client's account number and password. We are not going to switch to https in this project; instead, we will continue to use http. We assume that all clients have already established accounts with the Company; i.e. adding new clients is //not// within the scope of this project.
 ==== Use Case: A client checks out ====
@@ Line 36: / Line 36: @@
 ==== Use Case: A client visits the URL of a P/O ====
-Upon confirmation of a P/O, the system stores its content in an XML file based on the PO.xsd schema. The name of the P/O file is derived from the account number of the client and the P/O number (a per-client serial number that starts at 1). For example, the the 3rd P/O of account number 1234B555, is: po1234B55503.xml. Since this is an XML file, it needs to be transformed to XHTML before the client can see it. Note that this use case does not involve authentication.
+Upon confirmation of a P/O, the system stores its content in an XML file based on the PO.xsd schema. The name of the P/O file is derived from the account number of the client and the P/O number (a per-client serial number that starts at 1). For example, the the 3rd P/O of account number 12345, is: po12345_03.xml. Since this is an XML file, it needs to be transformed to XHTML before the client can see it. Note that this use case does not involve authentication.
 In addition to the above use cases, it is recommended that your site supports the following uses: the ability to view the shopping cart from the catalog screen (i.e. without having to add an item); the ability to checkout from the catalog screen.
-==== Analytics and Cross Selling ====
+==== Analytics and Special Features ====
-Management wants to be able to determine the average time it takes a client to add an item to the cart and the average time between a fresh visit and checkout (in the same session). And on an ad-hoc basis, management may decide to advertise a certain item whenever a related item is added to the cart.
+Add support for the following:
+  * Management wants to be able to determine the average time it takes a client to add an item to the cart and the average time between a fresh visit and checkout (in the same session). Provide a mechanism by which these two averages can be viewed in real time.
+  * And on an ad-hoc basis, Management may decide to advertise a certain item whenever a related item is added to the cart. As a proof of concept, activate this by cross selling 2002H712 whenever 1409S413 is added to the cart. Keep in mind that this functionality should not be part of the webapp since Management may withdraw it at any time (w/o recompiling).
+  * Add a search facility to enable clients to look for items.
 ===== Analysis of Part 2 (B2B) =====
@@ Line 55: / Line 59: @@
   * Tables ''Category'', ''Item'', and ''Client'' in the ''CSE'' database
-  * [[http://www.cse.yorku.ca/~roumani/course/4413/res/PO.xsd|The purchase order's schema]]
+  * [[http://www.cse.yorku.ca/~roumani/course/4413/res/PO.xsd|The purchase order's schema]]. Here is a [[http://www.cse.yorku.ca/~roumani/course/4413/res/PO.xml| sample]] that adheres to the schema.
@@ Line 75: / Line 79: @@
 ===== Deliverables =====
-You need to deliver three things by the due date of this project:
+There are two deliverables:
+  - A Project Report (described below)
+  - A war file (make sure it includes source files)
+These need to be delivered by the due date as follows:
+  - Submit both by issuing the command: ''submit 4413 proj <file>'' where <file> is the report file or the project's war file. You can issue this command several times with each submission overwriting the older one. Issue ''submit -l 4413 proj'' to list what was successfully submitted.
-    * Hand in a paper report
+  - Upload the war 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!
-      This can be done after class or to the Department Office
-    * Submit the report and source files
+==== The Report ====
-      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
+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 output samples and source listing).
-      Create a war file of your webapp and upload it to the project's port number. 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:
+The report should be packaged as one document (pdf or docx); should have page numbers; and should have a table of contents (TOC) in which all sections after the front material and listed along with their corresponding page numbers. The report consists of the following parts:
-  - 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.
+  - Front Material: A cover page (course number and name, date, project name, team); an optional dedication page; the TOC
+  - 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, connecting B2B with B2C, 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.
-  - 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 was communication and consistency maintained. Include here the main lessons that were learned from this project.
-   - Printouts: Include printouts of the XML order file as it appears on disk and on the client's browser and a printout of the completed procurement report showing the chosen wholesaler and price per item.
+   - Output Samples: These samples are for the B2B part. Select any XML P/O and include a listing of how it appears on disk and a screenshot of how it appears in the browser. Include also one completed procurement report showing: the items to procure, the consolidated quantity per item, the chosen wholesaler and price per item, and the confirmation codes obtained from the wholesalers web services.
-   - 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 add an entry (with a page number) for each such subsection in the TOC. 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 this step to the last minute; resolve it early on.