CSE4413

User Tools

Site Tools

You are here: eCommerce Systems » The Project
Trace:
labs

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
labs [2007/11/08 06:53] – roumanilabs [2008/09/02 21:21] (current) – old revision restored roumani
Line 2: Line 2:
  
   * **An eCommerce Site Backed by Web Services**   * **An eCommerce Site Backed by Web Services**
-  * Due Date: <hi>Thu November 22</hi>+  * Due Date: <hi>Wed Nov 26 by 5:00 pm</hi>
   * Team Size: min=2, max=3 students   * Team Size: min=2, max=3 students
   * Technological Platform to be used: JEE   * Technological Platform to be used: JEE
Line 17: Line 17:
  
 ===== Analysis of Part 1 (B2C) ===== ===== Analysis of Part 1 (B2C) =====
 +
  
 ==== Use Case: A client makes a fresh visit ==== ==== Use Case: A client makes a fresh visit ====
-The relevant URL is ''red.cse.yorku.ca:port/eFnnnnnn/servlet/Catalog'' (where eF stands for eFoods and ''nnnnnn'' is the rightmost 6 characters of the cs# of a team member (designate one team member to be the liaison contact person). The Catalog servlet displays the catalog of the Company. It is up to you to determine how this display is done based on the amount of time available for this task. 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; 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 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.
  
  
Line 25: Line 26:
 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 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. 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 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. 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.
  
 +
 +
 +==== 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. 
  
 ==== Use Case: A client checks out ==== ==== Use Case: A client checks out ====
-Upon checkout, the servlet must normally switch to https and prompt for the client name, shipping address, and payment details. We are not going to do that for 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, we will serve a login screen that displays the total amount and prompts for the client's account number and password. Upon authentication (based on accounts.txt) a confirmation screen is displayed to indicate that the P/O has been accepted and to provide a URL that the client can visit at any time to view the created P/O. See the next use case for details.+Upon checkout, the controller must ensure the client is logged in and must then display a confirmation screen followed by an acknowledgement that the the order has been accepted and is being processed. A URL that the client can visit at any time to view the created P/O must also be provided. See the next use case for details. 
  
 ==== Use Case: A client visits the URL of a P/O ==== ==== 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 URL of the 3rd P/O of account number 1234B555, is: http://red.cse.yorku.ca:port/eFnnnnnn/po1234B55503.xml. Since this is an XML file, it needs to be transformed to XHTML before the client can see it. You can do this at the server or (preferably) at the client side. 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 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.
  
 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; the ability to cancel an order from the login screen. 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; the ability to cancel an order from the login screen.
Line 62: Line 68:
  
   * [[http://www.cse.yorku.ca/~roumani/course/4413/res/proj/YHZ.wsdl|The WSDL of the Halifax Wholesaler]]   * [[http://www.cse.yorku.ca/~roumani/course/4413/res/proj/YHZ.wsdl|The WSDL of the Halifax Wholesaler]]
 +
 +
 +
 +
 +
  
  
Line 78: Line 89:
       Create a war file of your webapp and upload it to the project's port number.        Create a war file of your webapp and upload it to the project's port number. 
  
-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 five typed pages (excluding the source listing). The report should include the following sections:+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:
  
-  - Design: During the execution of this project, several design decisions had to be made, e.g. file formats, algorithms, representations, etc. Describe in this sections the key decisions that were made and why they were made the way they did. For example, how many servlets are there, what is the function of each, and how does data flow among them. +  - 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.  
-  - Implementation: Indicate here how data is represented and any java classes that are used in addition to the main servlets. Indicate also whether the project (as submitted) is fully functional or not. If it is, indicate the type of testing that was done. If it is not, indicate clearly any parts of it that are functional. If certain parts could not be implemented, describe the problems that were encountered. +  - 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. Describe how the project was executed by the team, e.g. who did what.+  - 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.
    - 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.    - 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.
-   - The Source Code:  Provide listing of all programs. Partition this section into subsections and provide a title for each. Make sure the code is properly formatted. Some editors do not format properly because they use spaces instead of tabs 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 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.  
  
  
 ===== Evaluation ===== ===== Evaluation =====
  
-The project will be evaluated based primarily (80%) on what your team achieved (report; design; correctness, quality, and style of implementation; and the interface) and partly (20%) on how your project compares with those of other teams. +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. 
labs.1194504798.txt.gz · Last modified: 2007/11/08 06:53 by roumani