DPSD HW6 - Version 1.4

Reminder: If you haven't done so already, be sure to update your "Lessons Learned" document based on the previous assignment and with what you learn while extending that version to 1.4.

First review "Chapter 2: Java" for Android in your Programming Android textbook. Pay special attention to "Modular Programming in Java", pp. 64-67. You will be required to use this technique in this assignment - can you figure out where? Post your ideas on Piazzin a public discussion before the second lecture of Week 7.

Make sure you update your API and other re-usable code based on comments and feedback from all prior versions of Project 1.

Supporting User Interaction With a Web-based GUI

Add a web-based GUI (JSP and Servlets). Like your 1.3 version user interfaces, this will re-use your Client code to communicate with the Server. So, if your Client or Server code is not designed to support this, start refactoring it right away.

Note that when you are finished, you will have 3 UIs that can all talk to the Server (and all at the same time). You will have added a web-based GUI and also continue to use your console-based UI from Version 1.5 to load Property files and allow your Swing-based GUI to update the base-price; all functionality in those clients must remain working as you add the new ones.

Data Persistence

Store the Pizza Configuration data in a local database.

Questions:

  1. Where is this database and code located?
  2. How should we design this piece?

More Details:

We now need to extend this system so it can be used over the web.

Your web-based Client app (Servlet and JSP) must support the following functionality:

  1. Show list of available pizzerias in a drop down box and allow the user to select one (Servlet 1).
  2. Then based on the selected Pizzeria, allow the user to order their Pizza (finally!!). (Servlet 2)
  3. The customer submits it (Servlet 2) and the details of their order are shown (including the price) to the customer (JSP 1).

Also, as you begin development, be sure to use the same configuration options that you used in the previous version. And note that the tricky part is that the Option Sets are not hard-coded.

Your web-based GUI code must re-use your client code. This means that if you have not de-coupled it from your main program in V1.3, you MUST refactor this first in order to make this next version work. And if you have not done this, it probably means you do not have a working GUI, so you will need to re-code this also.

If your Client code, protocol, or Server from Version 1.3 does not already support the features required to implement the new functionaility, you must add them.

UI Technical Requirements

You have to design this task being mindful of technical requirements.
  1. Create a Servlet (1) that interacts with the Server in V1.3 to get the list of available pizzerias and allows the user to select one.

    Hints:

    • According to your protocol, what does the Client request and what does the Server respond with in order to support this functinality?

  2. Create another Servlet (2) that can interact with the Server created in V1.3 to get the data for ordering a Pizza. For each option set, use a drop-down that is labelled with the option set name and gives the options for that set as the values to choose from. Make sure you GUI does NOT allow the user to make selections for values that they are not allowed to specify when really ordering a pizza.

    Hints:

    • According to your protocol, what does the Client request and what does the Server respond with in order to support this functinality?
    • What does the Server do in response to receiving the pizza order?

  3. Create a JSP that shows the Pizzeria and the selected choices for the pizza, showing the total cost.
Please keep in mind that data displayed is dynamic (i.e. read from the list of PizzaConfigs on the Server and accessed through your PizzaConfig API)

DB Technical Requirements

In this unit you have to provide Create, Update and Delete operations for persisting the data into a Database. Your Server should be able to switch between the LHM and DB version on startup - prompt the user starting the Server and use weak association to set up the backing data in your Server (either LHM or DB). We will talk about this more in class - make sure to follow the specified architecture discussed.

You may work with your final-project partner(s) to figure out how to setup a database and establish connectivity on your individual machines.

The DB version must support all needed operations in the UIs (character-based, Graphical, and newly added Web-based User Interfaces) including the following:

  1. Adding a new Pizzeria. (UI)
  2. Retreiving the list of available Pizzerias. (ALL)
  3. Retreiving a PizzaConfig. (ALL)
  4. Deleting a Pizzeria. (UI)
  5. Updating a Pizzeria. (UI and GUI, as specified in Version 1.3)
Note: none of the UI or GUI features are new ones; in other words, they must still work from Version 1.3 with the DB version of your Server.

You will need to design and implement:

  1. A database schema. (Be sure to apply rules of normalization discussed in class).
  2. Create a set of classes for managing the Create, Update and Delete operations.
  3. Use Prepared Statements with parameters for your queries. Read and follow the Oracle Tutorial on Using Prepared Statements
  4. You should write a driver (in main) and test out the DB functionality in a console program on the server side. Please submit your DB test output in a text file called DataBaseTest.txt.
Reminder: You will implement the database functionality in the server; the clients know nothing about how the data is stored.

Grading your Submission

  1. Program Specification/Correctness
    1. No errors, program always works correctly and meets the specification(s).
    2. The code could be reused as a whole or each routine could be reused.
    3. Design is reusable and extensible.
    4. Packages are created and used appropriately to demonstrate separation of concerns.
    5. All features of all user interfaces work with the LHM version and the DB version of your API.
    6. Interfaces, abstract classes, weak association, and patterns are applied appropriately and as specified.
    7. DB schema is normalized.
  2. Code is adequately tested and test runs are shown and demonstrated.
  3. Readibility
    1. No errors, code is clean, understandable, and well-organized.
    2. Code has been packaged and authored based on Java Coding Standards.
    3. Documentation
    4. The documentation is well written and clearly explains what the code is accomplishing and how.
    5. Detailed class diagram is provided.
    6. Database Schema is documented.
    7. No errors, code uses the best approach in every case. The code is extremely efficient without sacrificing readability and understanding.