Team Project -- Pizza Ordering

Subject to Change (last modified July 16, 2015)

This is an iterative project. There will be four deliverables scheduled at various points in the semester. The deliverables correspond to assignments A2--A5.

Students will work on the project in teams of 3/4.

1. Problem Statement: A Pizza Ordering System

1.1. Version 1

A local pizza store wants you to develop a Java-based pizza ordering system. The system needs to let cashiers serve customers in the store and also take phoned in orders. Customers can place orders through kiosks. Customers can order anything on the menu (e.g., pizza, breadsticks, soft drinks, etc). While ordering, they can change their mind. Customers must be able to view the menu for kiosk orders. The application must handle payments.

Store managers must be able to define a menu, modify the menu, and set the special for the day. Each of these three involve naming the items and their prices. Chefs must be able to view orders and mark them as complete when the orders are completed. For this part of the project, let us ignore delivery folks, who would mark the orders as delivered.

In the first implementation of the project, you can assume for simplicity that the implementation is running on a single machine as a standalone application. The implementation must have a graphical user interface that uses Java Swing (or something similar).

1.2. Version 2

Once the pizza store starts flourishing, it introduces an app that one could use on their phones for placing the orders. Now they need a centralized server that handles orders coming from phone apps as well as computers that are in the store. Customers are also encouraged to use frequent buyer accounts that track their purchases and offer free pizza certificates once their purchases reach a certain defined amount (that can be configured by store managers.

2. Deliverables

The project will be submitted in stages. Submit an electronic copy of the deliverables at each stage. For A2 and A3, the deliverable will be a PDF document. For A4, you will submit both a PDF document and code as a jar file. For A5, you will turn in code as a single jar file.

You must embed all the images (i.e. jpg, bmp, etc.) in the PDF file as your submission. Any tool specific model files will NOT be accepted. Do not submit images as separate files. Please make sure that you include your name on the front page of all submitted documents.

• Due: Monday, September 21, 2015, 11:59 PM via Canvas assignment submission.
• 20 points.
• Tasks
  1. Flesh out the requirements listed under version 1 above.
  2. You must include possible erroneous situations for everything that is listed.
  3. Identify the actors.
  4. Think about use cases. Use cases must cover all general kinds of end-to-end uses. Follow the format used in Larman's text when you write them up.
  5. Prepare a document containing the following:
     1. Use case diagram showing the actors and the use cases. (5 points)
     2. All use cases in fully-dressed essential form. (15 points)

• Due: Tuesday, September 28, 2015, 11:59 PM via Canvas assignment submission.
• 20 points.
• Tasks
  1. Based on the use cases identified in the previous assignment, model the domain concepts and their relationships.
  2. Express a Domain Model as a UML class diagram. Follow the format used in the text. This is worth 15 points. The Domain Model should:
     • Be expressed at the problem domain level of abstraction; it should focus on the abstract concepts and not include design or implementation classes.
     • Include relevant and necessary associations and other links.
     • Attributes should be simple or "pure data elements" such as scalars. State that is complex should be represented as associations to concepts that represent the complex entity.
     • Do not worry about the direction (arrows) of the associations.
     • Include multiplicity if appropriate.
     • Use Generalization/Specialization (inheritance) sparingly, and only for true "is-a" relationships.
     • Do not include operations or methods in your conceptual model.
  3. Include a brief glossary that defines each concept. This is worth 5 points.
  4. Include the previous use case document after completing required updates. You may fix errors in them, but the previous documents will not be re-graded. The current document must be consistent with the previous document, i.e., your domain model must support the requirements and use cases that you listed or were asked to list in A2.

• Due: Wednesday, October 28, 2015, 11:59 PM via Canvas assignment submission.
• 50 points.
• Tasks
  1. Use Subversion/GitHub/any repository based version control system. for all types of documents (design diagrams, tests, implementation code).
  2. Prepare sequence diagrams as part of the design process. Submit three key/difficult/interesting ones.
  3. Prepare a design class diagram.
  4. Write up a system test plan.
  5. Write JUnit test cases.
  6. Implement the system for iteration 1. You must use the GRASP patterns that you studied in the class. Use Swing for the user interface.
  7. Test your system.
• Submission:
  1. Submit a document containing the following:
     1. Three sequence diagrams (9 points)
     2. Class diagram (5 points)
     3. System test plan (4 points)
     4. Commit log showing checkins, checkouts, etc from your repository based version control system (3 points). This log will help us determine a number of things, such as (1) level of individual participation, (2) adequate use of a version control system. If the document shows an inadequate amount of checkin and checkout, the team may lose points. If an individual has no corresponding entry in the log, this individual may lose a lot of points for not participating in the project (i.e., the penalty is not limited to the 3 points for submitting the commit log).
  2. Submit the following code in a single jar file (the test and implementation should be in separate Java packages). Note that the code must implement the design you provided above. Points will be deducted if it doesn't.
     1. JUnit test code (4 points)
     2. System implementation and document describing how to run the system (25 points). This is broken down as follows:
        • Features: 20 points
        • Design quality: 3 points
        • Programming style: 2 points

• Due: Friday, November 20, Sunday, November 22, 2015, 11:59 PM via Canvas assignment submission.
• 60 points.
• Tasks
  1. After A4 is graded, you must browse the wrapup message for assignment A4 on the main discussion board, where we will post some suggestions for core functionality and user interface.
  2. Refactor the code from iteration 1 to cleanly separate the user interface layer from the application and domain layers.
  3. Allow for distribution. You may use Java RMI to enable distributed communication between the central server and the computers at the store. You will use Android's communication mechanism to connect the phone app with the central server. Note that you don't need a real phone. You can use the Android emulator.
  4. Use design patterns (e.g., Facade, Strategy and so on).
• Submit the following in a single jar file.
  1. System implementation Java source files. (56 points)
     You can name subpackages as you like: test, ui, view, model, core, etc., but all code and data files should reside under the package cs414.a5.eid. and the source files must be in the folder hierarchy cs414/a5/eid/.
     • Features: 40 points
     • Design quality: 10 points
     • Programming style: 4 points
  2. A text file named README, that 1) lists the external .jar file dependencies, if any, (database, user interface, logging, etc.), 2) shows how to run from command line, 3) gives user names and passwords if necessary, and 4) discusses what is especially strong, weak, or missing from the assignment, 5) what patterns and refactorings were used. (4 points)
  3. Commit log (3 points). This log will help us determine a number of things, such as (1) level of individual participation, (2) adequate use of a version control system. If the document shows an inadequate amount of checkin and checkout, the team may lose points. If an individual has no corresponding entry in the log, this individual may lose a lot of points for not participating in the project (i.e., the penalty is not limited to the 3 points for submitting the commit log).