Final Project

This page lists the milestone requirements for the Final Project in CC 410. Read the requirements carefully and discuss any questions with the instructors or TAs.

Purpose

This assignment allow students to exercise their programming skills by building a project of their own design. Ideally, the project will be something related to the student’s personal interests or area of study. All the requirements listed below are considered flexible and can be adapted to fit the individual project and student.

General Requirements

Assignment Requirements

A complete final project should include the following features:

Language Requirements

• The final project must be written in the same programming language used for the rest of the course, unless given prior permission from the instructor.
• In general, the structure of the final project should somewhat mirror the structure of the semester-long restaurant project. This includes using the same build tools (gradle or tox) and test frameworks. The goal is to use the tools learned throughout the semester to build a different project and focus on the design of the code, not learning new tools or languages.

Structural Requirements

• Satisfy all general requirements listed above.
• Include several object-oriented data/object classes, separated across at least two packages.
  • This does not include packages used for enums, base classes, or GUIs - there must be at least two distinct packages of instantiable data classes.
  • It is recommended, but not required, that applications follow the Model-View-Controller or MVC architecture.
• Demonstration of inheritance between classes.
  • This should include the use of both direct subclassing and interfaces.
• A user interface with multiple panels/views/pages/operations.
  • This could be a graphical user interface (GUI), or a web-based interface.
• The use of an external library or web API.
  • The external library or API should be integrated directly into the application in some way.
• Proper documentation comments in code.
• A complete set of UML Class Diagrams.

Functional Requirements

• Sufficient demonstration of functionality beyond just creating and storing data.
  • This means that there should be several functions that do something with the data, such as perform an algorithm or compute a result.
• Unit tests to adequately test that the code works properly.
  • This should test the structure, defaults, and functionality of all data objects as well as any additional functionality. Basically, anything that is the demonstration of functionality described above should have associated tests.
  • A high level of code coverage should be achieved.
  • Some user interface code may be omitted from unit testing if it is impractical to test.

Other Requirements

• At least one cool feature above and beyond the requirements listed above. This is at your discretion, but as part of your project presentation you should clearly state the cool feature and why it is included.

Time Requirements

Completing this project is estimated to require 25-50 hours depending on familiarity with the tools involved. Spread across the entire semester, this equates to roughly 1-3 hours of work each week. This project should be roughly 1/4 to 1/3 the size and scope of the semester-long restaurant project.

Milestones

The final project in this course will consist of several different milestones. Each milestone will require students to schedule a short meeting with the instructor or GTA to review the project as it stands and get feedback. The milestones are meant to roughly correspond to content being covered in this class.

• Milestone 1 (Week 1) - Review project description and answer questions. Discuss possible topics.
• Milestone 2 (Week 5) - Discuss possible project topics and class structures.
• Milestone 3 (Week 9) - Discuss classes and inheritance, review existing unit tests and documentation. Discuss possible user interfaces.
• Milestone 4 (Week 13) - Discuss user interfaces, review existing code against requirements. Discuss possible external libraries or APIs. Review existing code against requirements. Discuss final steps and presentation.
• Milestone 5 (Week 16) - Present project to class, submit final code for review.

Deliverables

1. Create a Release Tag on GitHub - Your final submission to Canvas should include a release tag on GitHub to the final version of your project. Ensure that it meets the requirements listed above. All project deliverables should be included in the final GitHub release.
2. Presentation - Please include any presentation materials (slides, etc.) in your git repository and make sure they are uploaded to GitHub as part of your release tag.
3. Code Documentation - Your code should include full documentation comments that can be used to generate developer documentation. Optionally, you may choose to deploy that documentation to GitHub pages.
4. Packaged Release (optional) - You are encouraged to create a packaged release for your project that can be easily downloaded and installed.
5. README File (optional) - You are encouraged to create a README file that describes your project, including how to compile and run it.
6. User Documentation (optional) - You may also include some user documentation describing how to use the project from a user’s perspective. This may be included as part of your README file as well.

Suggested Presentation Outline

• Introduction - Introduce yourself and the project
• Background - Give information on the project’s inspiration and any related work to be aware of
• Implementation - Discuss how the project was designed and developed (should be the bulk of the presentation)
• Evaluation - Briefly evaluate how well your project met the original goal and how it compares to similar projects, if applicable
• Future Work - Share ways you would improve this project if given the opportunity to continue working on it
• Conclusion - Summarize what you learned
• Demo - Open your application and show us how it works, especially any cool features, and also open the source code and share interesting portions of it as well

Grading Rubric

This assignment will be graded following the concept of criterion grading, an approach that only assigns points for completing the full requirements. However, the requirements will be brief and straightforward, and will be treated as such. Projects that meet the requirements listed above will, at a minimum, earn a passing grade of 60%.

Projects that go above and beyond the requirements in various ways will be graded higher. In general, the goal of this project is to build a program that is interesting and engaging to the user, but also demonstrates the student’s ability to develop professional code. So, projects that are easy to use, interesting, demonstrate good design and coding standards, and fit well within the student’s defined interests are likely to earn additional points.

Throughout the semester, students will have a chance to work with an instructor or GTA to get feedback on the project while it is being developed. These meetings allow the student to get information about which requirements have been met and which ones have not, as well as general overview of the project from the reviewer.

Submission

Submit this assignment by creating a release on GitHub and uploading the release URL to the assignment on Canvas. You should not submit this Codio project or mark it as complete in Codio, in case you need to come back to it and make changes later.

Hello Real World

This page lists the milestone requirements for the Example 1 - Hello Real World project. Read the requirements carefully and discuss any questions with the instructors or TAs.

Purpose

This assignment mimics the traditional “Hello World” project that most programmers learn as their first program, but done following professional coding standards and guidelines. In effect, this is how a professional coder would write “Hello World” as a project for work.

General Requirements

Assignment Requirements

This project should include the following features:

• A HelloWorld class that contains a main method.
  • The main method should print “Hello World” if no command line arguments are received.
  • The main method should print “Hello {arg}” if a command line argument is received.
• Unit tests that achieve 100% code coverage in the HelloWorld class, properly testing both with and without command-line arguments.
• Documentation comments following the language’s documentation standards for each class, method, and any class attributes.
  • Python: All .py files should also include a file docstring, including __init__.py and __main__.py files for packages.
• All variables and methods in the HelloWorld class must include explicit data types
  • Java: no changes are needed since Java already requires this.
  • Python: add type hints to all methods and variables. Type hints in the HelloWorld class must not use Any as a type.

Time Requirements

Completing this project is estimated to require 2-5 hours depending on familiarity with the tools involved.

Grading Rubric

This assignment will be graded based on the rubric below:

• HelloWorld class - 30%
• Unit Tests - 30%
• Documentation - 20%
• Automation - 20%

The following deductions apply:

• Any portion of the project which will not compile (Java), pass a strict type check (Python), or execute properly will be given a grade of 0.
• Any portion of the project that does not pass a style check will have its grade reduced by 30% of the total points available on that portion.

This is not an exhaustive list of possible deductions. The instructors will strive to provide reasonable and fair grading, but we can’t predict all possible defects. It is up to the student to ensure that the project is complete and correct before submission.

Submission

Submit this assignment by creating a release on GitHub and uploading the release URL to the assignment on Canvas. You should not submit this Codio project or mark it as complete in Codio, in case you need to come back to it and make changes later.

Restaurant Classes

This page lists the milestone requirements for Milestone 1 of the CC 410 Restaurant Project. Read the requirements carefully and discuss any questions with the instructors or TAs.

Purpose

The CC 410 Restaurant Project project for this semester is centered around building a point of sale (POS) system for a fictional restaurant named That’s a Wrap, offering wraps of all shapes and sizes to celebrate our favorite movies.

This first milestone involves building the classes that represent items on the restaurant’s menu. In a traditional Model-View-Controller software design pattern, these classes would make up the core of the model. This content should be mostly review of concepts learned in prior CC courses with the addition of enumerations (enums). It should not be particularly difficult, but it may be repetitive and time consuming.

Specifically, we’ll focus primarily on data encapsulation by storing attributes about each menu item in the class. We’ll also learn how to combine state and behavior by modifying the string representation of the object based on the current state, or the combined values stored in the attributes.

General Requirements

This milestone must follow these professional coding standards:

• All code must be object-oriented.
  • All executable code must be within a class
    • Python package files such as __init__.py and __main__.py are exempt.
  • Classes must be organized into packages based on common usage.
• This project must include automation for compilation and execution.
  • Java: Use Gradle with the application plugin. The project should compile without errors. You may include a main class in a separate package for testing purposes only.
  • Python: Use tox configured to use Python 3.9 and a requirements file to install libraries. You may include a main class in a separate package for testing purposes only.
• All code must properly compile or be interpreted.
  • Java: It must compile using Gradle.
  • Python: It must be interpreted using Python 3.9. Where specified, type hints should be included in the code, and all code should pass a strict Mypy type check.
• Submissions to Canvas should be tagged GitHub releases that are numbered according to Semantic Versioning.

Assignment Requirements

This milestone should include the following features:

• Wrap classes - 5
  • Declared in the thatsawrap.data.wraps package
• Side classes - 3
  • Declared in the thatsawrap.data.sides package
• Drink classes - 3
  • Declared in the thatsawrap.data.drinks package
• Enumeration classes - 3
  • Declared in the thatsawrap.data.enums package

See the That’s a Wrap Menu section below for descriptions of what each class should contain.

Python - these files should include complete type annotations and achieve a low imprecision percentage in Mypy using strict type checking.

Time Requirements

Completing this project is estimated to require 3-8 hours.

Grading Rubric

This assignment will be graded based on the rubric below:

• Wrap classes - 40%
• Side classes - 20%
• Drink classes - 30%
• Enumeration classes - 10%

The following deductions apply:

• Any portion of the project which will not compile (Java), pass a strict type check (Python), or execute properly will be given a grade of 0.
• Any portion of the project which does not meet the general requirements listed above will have a commensurate amount of points deducted.

This is not an exhaustive list of possible deductions. The instructors will strive to provide reasonable and fair grading, but we can’t predict all possible defects. It is up to the student to ensure that the project is complete and correct before submission.

Submission

Submit this assignment by creating a release on GitHub and uploading the release URL to the assignment on Canvas. You should not submit this Codio project or mark it as complete in Codio, in case you need to come back to it and make changes later.

That’s a Wrap Menu

our motto: be a star - wrap things your way!

Each attribute described below should be implemented as a private variable within the class. Most attributes will also include a getter method, and sometimes a setter method, following this naming scheme (using Price as an example):

• Java - The private price attribute would have a getPrice getter and setPrice setter method.
• Python - The private __price attribute would have a getter and setter named price implemented as a Python Property.

Wraps

Each wrap should be stored in an appropriately named class in the thatsawrap.data.wraps package. Each wrap should include an attribute for the following data:

• Shell - a Shell value (see below). It should have a getter and setter method.
• Addins - a Java HashSet or a Python set of Addin values (see below).
  • This attribute should have a getter method that returns a shallow copy of the set to prevent external modification. See HashSet’s Copy Constructor (Java) or set.copy (Python).
  • This attribute should also have methods for Add Addin and Remove Addin to modify the list of condiments.

In addition, each wrap should have the ability to return the following data through an appropriate getter method. The data may be stored as attributes or hard coded directly into the method.

• Price - a Java double or Python float value representing the base price of the item plus any upcharge associated with the chosen Shell value.
• Calories - an int value representing the number of calories associated with the item.
• Instructions - a Java LinkedList of String values or a Python list of str values.
  • If stored as an attribute, it should return a shallow copy of the list to prevent external modification. See LinkedList’s Copy Constructor (Java) or list.copy (Python).

Each wrap class should also override the default string representation method (toString() in Java or __str__() in Python) and return a string that properly describes the wrap. The string should be formatted as “{wrap name} in a {shell} Shell”, such as “The Godfather in a Stromboli Shell”.

It should also override the default equality method (equals() in Java or __eq__() in Python). Two items should be considered equal only if the values of all attributes are equal.

Each wrap description will include a list of ingredients included on the wrap. Those ingredients should be represented using Boolean attributes that are set to true by default, with appropriate getter and setter methods. Changing any of these to false will cause a “Hold {ingredient}” message, such as “Hold Pepperoni”, to be added to the Instructions list. Likewise, changing it back to true will remove the appropriate message. If all ingredients are at their default values, the Instructions list should be empty.

Each wrap will be served in a particular Default Shell, and will include a default set of Addins. Those attributes should be populated appropriately in the constructor for the wrap. Changes to the Shell and Addins attributes will not affect the Instructions attribute at this time (we’ll add that later).

The number of Calories for a wrap will remain constant, regardless of other attributes (we’ll just pretend that changing the wrap doesn’t change the number of calories).

The Price for a wrap will change based on the value selected for the Shell. Each wrap will have a base price listed for the Default Shell option. Other shells include an associated upcharge or discount, which must be adjusted.

The Godfather (Italian Stromboli)

this wrap will make your taste buds an offer they can’t refuse

thatsawrap.data.wraps.Godfather - The price is $9.65 and it is 1268 calories. Served in a Stromboli Shell. Ingredients: Pepperoni, Sausage, Marinara and Cheese. Addins: Peppers and Onions.

The Wizard of Oz (Spinach Greens)

an emerald city of flavors - truly a wrap of a different color

thatsawrap.data.wraps.Wizard - The price is $10.35 and it is 1085 calories. Served in a Spinach Shell. Ingredients: Chicken, Spinach, Cheese. Addins: Tomatoes and Dressing.

Some Like It Hot (Buffalo Chicken)

a hot and spicy classic

thatsawrap.data.wraps.SomeLike - The price is $11.45 and it is 1370 calories. Served in a Whole Grain Shell. Ingredients: Chicken, Cheese. Addins: Onions, Peppers and Buffalo Sauce.

West Side Story (Corned Beef)

a specialty from the city so nice they named it twice

thatsawrap.data.wraps.WestSide - The price is $8.75 and it is 1240 calories. Served in a Whole Grain Shell. Ingredients: Corned Beef, Cabbage and Cheese. Addins: Onions, Pickles and Mustard.

Spartacus (Everything)

a massive wrap that can feed even the hungriest warrior

thatsawrap.data.wraps.Spartacus - The price is $16.55 and it is 1874 calories. Served in a Spinach Shell. Ingredients: Pepperoni, Sausage, Chicken, Corned Beef and Cheese. Addins: Peppers, Tomatoes, Onions, Pickles, Buffalo Sauce and Dressing.

Sides

Each side should be stored in an appropriately named class in the thatsawrap.data.sides package. Each side should include an attribute for the following data:

• Size - a Size value (see below). It should have a getter and setter method.

In addition, each side should have the ability to return the following data through an appropriate getter method. The data may be stored as attributes or hard coded directly into the method.

• Price - a Java double or Python float value.
• Calories - an int value.

Each side class should also override the default string representation method (toString() in Java or __str__() in Python) and return a string that properly describes the side. The string should be formatted as “{size} {side name}”, such as “Indie Yankee Doodle Dandy”.

It should also override the default equality method (equals() in Java or __eq__() in Python). Two items should be considered equal only if the values of all attributes are equal.

Each side description will include a Price and number of Calories for each Size. The sides will have a default size of Indie.

Yankee Doodle Dandy (Mac & Cheese)

stuck a feather in his cap and called it macaroni

thatsawrap.data.sides.Yankee - Indie: $2.25 and 400 calories. Studio: $3.95 and 650 calories. Blockbuster: $6.25 and 875 calories.

The French Connection (Fries)

fried potatoes good enough to keep for yourself

thatsawrap.data.sides.French - Indie: $2.75 and 550 calories. Studio: $4.85 and 700 calories. Blockbuster: $5.25 and 950 calories.

Snow White (Apple Slices)

guaranteed not to be poisoned or your money back

thatsawrap.data.sides.SnowWhite - Indie: $1.50 and 225 calories. Studio: $2.25 and 350 calories. Blockbuster: $3.00 and 475 calories.

Drinks

Each drink should be stored in an appropriately named class in the thatsawrap.data.drinks package. Each drink should include an attribute for the following data:

• Size - a Size value (see below). It should have a getter and setter method.

In addition, each drink should have the ability to return the following data through an appropriate getter method. The data may be stored as attributes or hard coded directly into the method.

• Price - a Java double or Python float value.
• Calories - an int value. It should have a getter method.
• Instructions - a Java LinkedList of String values or a Python list of str values.
  • If stored as an attribute, it should return a shallow copy of the list to prevent external modification. See LinkedList’s Copy Constructor (Java) or list.copy (Python).

Each drink class should also override the default string representation method (toString() in Java or __str__() in Python) and return a string that properly describes the drink. The string should be formatted as “{size} {drink name}”, such as “Indie Forrest Gump”.

It should also override the default equality method (equals() in Java or __eq__() in Python). Two items should be considered equal only if the values of all attributes are equal.

Each drink description may include a list of flavors that may be added. Those flavors should be represented using Boolean attributes that are set to false by default, with appropriate getter and setter methods. Changing any of these to true will cause a “Add {flavor}” message, such as “Add Cherry”, to be added to the Instructions list. Likewise, changing it back to false will remove the appropriate message.

In addition, drinks may specify default flavors that should be represented using Boolean attributes that are set to true by default, with appropriate getter and setter methods. Changing any of these to false will cause a “Hold {flavor}” message, such as “Hold Coconut”, to be added to the Instructions list. Likewise, changing it back to true will remove the appropriate message.

If all flavors are at their default values, the Instructions list should be empty.

Each side description will include a Price and number of Calories for each Size. The sides will have a default size of Indie. Changes to the Size attribute will not affect the Instructions attribute.

Forrest Gump (Chocolate Shake)

you never know what you are going to get

thatsawrap.data.drinks.Forrest - Flavors: Chocolate (default), Vanilla, Caramel and Coffee. Indie: $5.25 and 980 calories. Studio: $7.50 and 1365 calories. Blockbuster: $9.00 and 1875 calories.

Singin’ in the Rain (Soda Fountain)

comes with a little umbrella, but you have to provide the song

thatsawrap.data.drinks.Singin - Flavors: Cherry (default), Strawberry, Cola and Grape. Indie: $2.75 and 360 calories. Studio: $3.25 and 400 calories. Blockbuster: $4.00 and 550 calories.

Rocky (Protein Smoothie)

eye of the tiger not included

thatsawrap.data.drinks.Rocky - Flavors: Strawberry (default), Banana, Peach and Mango. Indie: $5.85 and 665 calories. Studio: $7.95 and 825 calories. Blockbuster: $9.45 and 1060 calories.

Enumerations

Each enumeration should be stored in an appropriately named class in the thatsawrap.data.enums package. Each enumeration class should also override the default string representation method (toString() in Java or __str__() in Python) and return a string that properly describes the item. Python developers may also wish to override the __repr__() method to return this value as well.

Shell

an excellent setting for a delicious meal

thatsawrap.data.enums.Shell - Whole Grain (add $0.75), Spinach (add $1.00) or Stromboli (add $1.50)

Size

options to fit any budget

thatsawrap.data.enums.Size - Indie (Small), Studio (Medium), Blockbuster (Large)

Addins

the extras aren’t just in the background

thatsawrap.data.enums.Addins - Peppers, Onions, Tomatoes, Pickles, Dressing, Buffalo Sauce, Mustard

Special thanks to friends and family for inspiration and menu suggestions!

Documentation & Testing

This page lists the milestone requirements for Milestone 2 of the CC 410 Restaurant Project. Read the requirements carefully and discuss any questions with the instructors or TAs.

Purpose

The CC 410 Restaurant Project project for this semester is centered around building a point of sale (POS) system for a fictional restaurant named That’s a Wrap, offering wraps of all shapes and sizes to celebrate our favorite movies.

The second milestone involves writing documentation and unit tests for our existing code base. Our goal is to adequately test each part of our code via unit tests, reaching 100% code coverage at a minimum. In addition, we’ll add all of the required documentation comments in our existing code.

General Requirements

This milestone must follow these professional coding standards:

• All code must be object-oriented.
  • All executable code must be within a class
    • Python package files such as __init__.py and __main__.py are exempt.
  • Classes must be organized into packages based on common usage.
• This project must include automation for compilation, unit testing, documentation generation, and execution.
  • Java: Use Gradle with the application plugin. The project should compile without errors. You may include a main class in a separate package for testing purposes only.
  • Python: Use tox configured to use Python 3.9 and a requirements file to install libraries. You may include a main class in a separate package for testing purposes only.
• All code must properly compile or be interpreted.
  • Java: It must compile using Gradle.
  • Python: It must be interpreted using Python 3.9. Where specified, type hints should be included in the code, and all code should pass a strict Mypy type check.
• Where specified, code should contain appropriate unit tests that achieve the specified level of code coverage.
  • Java: Use JUnit 5. You may choose to use Hamcrest for assertions.
  • Python: Use pytest. You may choose to use Hamcrest for assertions.
• Where specified, code should contain appropriate documentation comments following the language’s style guide.
  • Java: Use javadoc to generate documentation.
  • Python: Use pdoc3 to generate documentation.
• Submissions to Canvas should be tagged GitHub releases that are numbered according to Semantic Versioning.

Assignment Requirements

This milestone should include the following features:

Data Types

• Each Wrap, Side, and Drink class should contain complete typing information.
  • Java - this is already handled by the compiler, so no changes are needed.
  • Python - the code should contain complete type annotations and achieve low imprecision percentage in Mypy using strict type checking.

Unit Tests

• Each Wrap, Side, and Drink class should have a corresponding class of unit tests that achieve 100% code coverage and adequately test all features of those classes.
  • See the discussion below for more information on unit tests to be included.
  • Each unit test should be in a matching package in the test directory for the class it is testing.
  • Python - unit tests do not require type annotations.
  • Where possible, use parameterized unit tests to reduce the number of individual tests written.
  • You may use any form of assertions, including the Hamcrest library.

Documentation

• Each Wrap, Side, Drink, and Enumeration class should have all required documentation comments.
  • Every method must be documented, including parameters and return values.
  • Checkstyle/Flake8 should not give any errors related to documentation in the src directory.
  • You are encouraged, but not required, to create documentation comments for unit tests.
  • You should be able to generate documentation using javadoc/pdoc3 as shown in the “Hello Real World” project.
  • You will be graded on the content of the comments - make sure they are descriptive and succinct, with the appropriate sections/tags.

UML Class Diagram

• Create a UML Class Diagram representing the structure of this program.
  • Store the UML diagram as an image file (PNG preferred).
  • Place the image in the root of the project directory (directly inside the java or python folder).
  • Make sure it is committed to GitHub and included in your project release.
  • You may include additional materials, such as the source file used to create the image.

Time Requirements

Completing this project is estimated to require 3-8 hours.

Grading Rubric

This assignment will be graded based on the rubric below:

• Unit Tests - 60%
  • Wrap Classes - 30%
  • Side Classes - 10%
  • Drink Classes - 20%
• Documentation Comments - 30%
  • Wraps Classes - 8%
  • Side Classes - 8%
  • Drink Classes - 8%
  • Enumeration Classes - 6%
• UML Class Diagram - 10%

The following deductions apply:

• Any portion of the project which will not compile (Java), pass a strict type check (Python), or execute properly will be given a grade of 0.
• Any portion of the project which does not meet the general requirements listed above will have a commensurate amount of points deducted.

This is not an exhaustive list of possible deductions. The instructors will strive to provide reasonable and fair grading, but we can’t predict all possible defects. It is up to the student to ensure that the project is complete and correct before submission.

Submission

Submit this assignment by creating a release on GitHub and uploading the release URL to the assignment on Canvas. You should not submit this Codio project or mark it as complete in Codio, in case you need to come back to it and make changes later.

Unit Tests

Wrap

Each test class should contain unit tests for the following (this is not an exhaustive list, but should get close to 100% coverage):

• When a new object is created:
  • The instructions list should be empty
  • The default shell should be set correctly
  • The addins should be set correctly
  • The calories should be set correctly
• For every shell option:
  • The price should be set correctly, including any surcharges for shell types.
  • The string representation of the item should be correct
• For every ingredient
  • Each ingredient should be included by default
  • Adding or removing an ingredient adds or removes an item in the instructions list
• For every addin:
  • If the addin is included by default, it should be in the addins list on a new object
  • Adding or removing an addin makes the correct modification to the addins list
• Equality tests:
  • Two instances of the same object are equal
  • Two instances with different shells are not equal
  • Two instances with different ingredients are not equal
  • Two instances with different addins are not equal
  • An instance of another object is not equal to an instance of this object (should not cause an exception)
• Other tests:
  • Changing multiple ingredients should add or remove multiple items in the instructions list

Sides

Each test class should contain unit tests for the following (this is not an exhaustive list, but should get close to 100% coverage):

• When a new object is created:
  • The default size should be set correctly
• For every size option:
  • The price should be set correctly
  • The calories should be set correctly
  • The string representation of the item should be correct
• Equality tests:
  • Two instances of the same object are equal
  • Two instances with different sizes are not equal
  • An instance of another object is not equal to an instance of this object (should not cause an exception)

Drinks

Each test class should contain unit tests for the following (this is not an exhaustive list, but should get close to 100% coverage):

• When a new object is created:
  • The instructions list should be empty
  • The default size should be set correctly
• For every size option:
  • The price should be set correctly
  • The calories should be set correctly
  • The string representation of the item should be correct
• For every flavor
  • Default flavors should be included by default, others should not be included by default
  • Adding or removing a flavor adds or removes an item in the instructions list
• Equality tests:
  • Two instances of the same object are equal
  • Two instances with different sizes are not equal
  • Two instances with different flavors are not equal
  • An instance of another object is not equal to an instance of this object (should not cause an exception)
• Other tests:
  • Changing multiple flavors should add or remove multiple items in the instructions list

Inheritance

This page lists the milestone requirements for Milestone 3 of the CC 410 Restaurant Project. Read the requirements carefully and discuss any questions with the instructors or TAs.

Purpose

The CC 410 Restaurant Project project for this semester is centered around building a point of sale (POS) system for a fictional restaurant named That’s a Wrap, offering wraps of all shapes and sizes to celebrate our favorite movies.

The third milestone involves refactoring our code to take advantage of inheritance and the use of interfaces. We’ll also need to update our documentation and unit tests accordingly.

General Requirements

Assignment Requirements

This milestone should include the following features:

Interface

• A new thatsawrap.data.menu.Item interface that is implemented by all wrap, side, and drink classes
  • It is highly recommended to do this by implementing the interface on the new base classes listed below.
  • See below for the description of what this interface should contain

Base Classes

• New abstract base classes for each type of menu item:
  • Wraps should inherit from thatsawrap.data.wraps.Wrap base class
  • Sides should inherit from the thatsawrap.data.sides.Side base class
  • Drinks should inherit from the thatsawrap.data.drinks.Drink base class
• Each new base class should contain all elements that are shared by each type of menu item
  • See below for the description of what the base classes should contain

Menu Class

• A new static class thatsawrap.data.menu.Menu that contains the full menu
  • See below for the description of what this Menu class should contain

Unit Tests

• Updated unit tests for each menu item to check for proper typing
  • Each menu item should implement the Item interface
  • Each menu item should inherit from the correct base class
  • Each class except Menu and Item should report near 100% code coverage.
• Add a unit test class for Menu to confirm that each possible menu item is present in the menu.

Updated Documentation and Style

• Update the UML Class Diagram to represent the new structure of the code.
• Make sure all code is free from style errors using Checkstyle/Flake8.

Time Requirements

Completing this project is estimated to require 3-8 hours.

Grading Rubric

This assignment will be graded based on the rubric below:

• Item Interface - 25%
• Base Classes - 30%
  • Wrap Base Class - 10%
  • Side Base Class - 10%
  • Drink Base Class - 10%
• Menu Class - 20%
• Updated Unit Tests - 10%
• Menu Unit Tests - 10%
• UML Class Diagram - 5%

The following deductions apply:

• Any portion of the project which will not compile (Java), pass a strict type check (Python), or execute properly will be given a grade of 0.
• Any portion of the project which does not meet the general requirements listed above will have a commensurate amount of points deducted.

This is not an exhaustive list of possible deductions. The instructors will strive to provide reasonable and fair grading, but we can’t predict all possible defects. It is up to the student to ensure that the project is complete and correct before submission.

Submission

Submit this assignment by creating a release on GitHub and uploading the release URL to the assignment on Canvas. You should not submit this Codio project or mark it as complete in Codio, in case you need to come back to it and make changes later.

New Classes

Item Interface

The thatsawrap.data.menu.Item class should be created as an interface that can be implemented by all other menu items. It should contain the following elements as abstract methods/properties:

• A getter for Price
• A getter for Calories
• A getter for Instructions

Each menu item (wraps, sides, and drinks) should be refactored to implement this interface. This will require some changes:

• Price and Calories is straightforward
• Instructions requires some changes
  • Wraps - the Instructions list should now include each of the Addins added to each item. This could be done via the new Wrap base class.
  • Sides - the Instructions getter will need to be added, and it should just return an empty list since sides do not have instructions. This can be done via the new Side base class.
  • Drinks - no changes needed

Accordingly, the unit tests for some of these classes will need updated, as discussed below.

Base Classes

Each of the three types of menu items should directly inherit from a new abstract base class. These classes should not be instantiated!

• thatsawrap.data.wraps.Wrap is the base class for all wrap items. It should include the following elements that are common to all wrap classes:
  • Shell - attribute with getter and setter.
  • Addins - attribute with getter, Add Addins and Remove Addins methods.
  • Price - abstract getter. This should be overridden in the subclass to return the correct price.
  • Calories - abstract getter. This should be overridden in the subclass to return the correct calories.
  • Instructions - getter. This should be overridden in the subclass to return the correct list of instructions.
    • One easy way to do this: the method in the superclass could be used to add the list of addins to the list, and then the subclass method could call the superclass method as part of its code and then add the ingredient changes itself.
• thatsawrap.data.sides.Side is the base class for all side items. It should include the following elements that are common to all side classes:
  • Size - getter and setter.
  • Price - abstract getter. This should be overridden in the subclass to return the correct price based on the size.
  • Calories - abstract getter. This should be overridden in the subclass to return the correct calories based on the size.
  • Instructions - getter. This should simply return an empty list, and does not need overridden.
• thatsawrap.data.drinks.Drink is the base class for all drink items. It should include the following elements that are common to all drink classes:
  • Size - getter and setter.
  • Price - abstract getter. This should be overridden in the subclass to return the correct price based on the size.
  • Calories - abstract getter. This should be overridden in the subclass to return the correct calories based on the size.
  • Instructions - abstract getter. This should be overridden in the subclass to return the correct list of ingredients changed.

Menu Class

The thatsawrap.data.menu.Menu class should be a class that has static getter methods for these four elements:

• wraps - a list of Item elements containing an instance of all available wraps (5 in total).
• sides - a list of Item elements containing an instance of all available sides. Since each side is available in three sizes, the list should include an instance of all three sizes of each side item (9 in total).
• drinks - a list of Item elements containing an instance of all available drinks. Since each drink is available in three sizes, the list should include an instance of all three sizes of each drink item (9 in total).
• fullmenu - a combined list of all menu items (23 in total).

In Java, these lists should use a subclass of the List interface. In Python, these methods should use the built-in Python list data type. Since they are static methods, they cannot be constructed as Python properties using the @property decorator.

Unit Tests

The following updates must be made to the existing unit tests in this project to accommodate these code changes:

Wraps

• When a new object is created:
  • The instructions list should now contain entries for each of the addins present by default
• Check inheritance:
  • Check if the object inherits from the correct base class
  • Check if the object implements the Item interface
• For each addin:
  • Check that adding or removing the addin will add or remove that element from the instructions list.

Sides

• When a new object is created:
  • The instructions list should be empty
• Check inheritance:
  • Check if the object inherits from the correct base class
  • Check if the object implements the Item interface

Drinks

• Check inheritance:
  • Check if the object inherits from the correct base class
  • Check if the object implements the Item interface

Menu

• Test that the wraps list contains an instance of each wrap
• Test that the sides list contains an instance of each side for each size
• Test that the drinks list contains an instance of each drink for each size
• Test that the full menu list contains an instance of each menu item in the lists above

GUI Basics

This page lists the milestone requirements for Milestone 4 of the CC 410 Restaurant Project. Read the requirements carefully and discuss any questions with the instructors or TAs.

Purpose

The CC 410 Restaurant Project project for this semester is centered around building a point of sale (POS) system for a fictional restaurant named That’s a Wrap, offering wraps of all shapes and sizes to celebrate our favorite movies.

The fourth milestone involves creating the various GUI windows and panels required for this project. The next milestone will involve adding functionality to these GUI elements beyond the ability to load different panels into the main window area.

General Requirements

Assignment Requirements

This milestone should include the following features:

New Packages

• A thatsawrap.gui package to store all GUI code.
• A thatsawrap.gui.wraps package to store all GUI panels for wraps.
• A thatsawrap.gui.sides package to store all GUI panels for sides.
• A thatsawrap.gui.drinks package to store all GUI panels for drinks.

Main GUI Classes

• A thatsawrap.Main class that properly loads and displays the program’s GUI.
• A thatsawrap.gui.PrimaryWindow class that represents the main GUI window.
  • It should contain two panels - a main panel and a sidebar panel.
  • It should also contain two methods: one to load a particular panel into the main panel, and another to load the order screen into the main panel.
• A thatsawrap.gui.MenuPanel class to represent the main ordering screen panel.
  • It should contain three panels of buttons, one each for wraps, sides, and drinks. They may be automatically generated from the menu.
  • Each wrap will be listed once, but each side and drink will have three buttons - one for each size.
  • When clicked, those buttons should call a method to load the appropriate panel into the main panel to allow customization of the menu item.
• A thatsawrap.gui.OrderPanel class to represent the sidebar panel containing a user’s order.
  • It should contain labels for order number, subtotal, tax, and total.
  • It should contain an Edit button that does nothing when clicked.
  • It should also include a list box as a placeholder that can be used to keep track of the order. The list box should expand to fill all remaining vertical space in the window.

Menu Item Panels

• A panel class in the thatsawrap.gui.wraps package for each wrap.
  • It should include appropriate controls for modifying the ingredients, shell, and addins.
  • You may want to include a parent WrapPanel class to reduce the amount of duplicate code.
• A SINGLE panel class SidePanel in the thatsawrap.gui.sides package.
  • It should include appropriate controls for modifying the size of the item.
  • Since each side only has a single option, this panel will be generalized to work with the parent Side class instead of individual sides themselves. When the buttons on the menu are clicked, you’ll need to make sure an instance of the correct menu item is created.
• A panel class in the thatsawrap.gui.drinks package for each drink item.
  • It should include appropriate controls for modifying the ingredients and size.
  • You may with include a parent DrinkPanel class to reduce the amount of duplicate code.

Each of the menu item panels should also implement the following functionality:

• When given an instance of the item as a parameter to the constructor, the values of the controls should be set to match the values in the instance.
• It should include a Save button that, when clicked, will replace the main panel with the order screen. We will handle actually saving the item in a future milestone.

Documentation and Tests

• Classes in the thatsawrap.gui package do require all appropriate documentation comments, and must be free of style errors. Every method must include full documentation comments.
• Classes in the thatsawrap.gui package do not require unit tests.
• Classes in the thatsawrap.gui package do not require type hints in Python, though you may continue to use them if they are helpful. Any errors from Mypy originating in these classes will be ignored.
• Create a new UML diagram that shows the structure of the thatsawrap.gui package and how all GUI classes are related. You should also show any links to the classes in the thatsawrap.data package, but you may choose to show simplified links between packages instead of individual classes. You do not have to include full details from classes in the thatsawrap.data packages.
  • For example, you can show that the classes in the thatsawrap.gui.wraps package are all related to similar classes in the thatsawrap.data.wraps package without listing the individual classes in that package.

Other Instructions

You are welcome to add additional methods to the existing content in the thatsawrap.data package. If so, make sure you include appropriate documentation, type checking and unit tests.

See below for a few sketches of what your GUI might look like.

Time Requirements

Completing this project is estimated to require 3-8 hours.

Grading Rubric

This assignment will be graded based on the rubric below:

• Main class - 2%
• PrimaryWindow class - 4%
• OrderPanel class - 4%
• MenuPanel class - 20%
• Wrap Panel classes - 40%
• SidePanel class - 5%
• Drink Panel classes - 15%
• Updated UML diagram - 10%

The following deductions apply:

• Any portion of the project which will not compile (Java), pass a strict type check (Python), or execute properly will be given a grade of 0.
• Any portion of the project which does not meet the general requirements listed above will have a commensurate amount of points deducted.

This is not an exhaustive list of possible deductions. The instructors will strive to provide reasonable and fair grading, but we can’t predict all possible defects. It is up to the student to ensure that the project is complete and correct before submission.

Submission

Submit this assignment by creating a release on GitHub and uploading the release URL to the assignment on Canvas. You should not submit this Codio project or mark it as complete in Codio, in case you need to come back to it and make changes later.

GUI Sketches

Below are some GUI sketches to help you visualize one possible GUI for a previous version of this project. You do not have to match this design at all, but this is at least a good starting point that you can reach based on what you learned in Example 6.

Main Window

Wrap Panel

Side Panel

Drink Panel

Helpful Hints & Code

Here are a couple of helpful pieces of code that you may wish to use in your project.

Java

In many cases, I found it easiest to create private or protected methods that will construct my GridBagConstraints objects, either within the class I was working in or in a parent class in the case of wrap and drink panels. Here’s an example:

/**
  * Construct a GridBagConstraints object.
  *
  * @param y the y coordinate of the object
  * @param start set anchor to LINE_START
  * @return the constructed GridBagConstraints object
  */
protected GridBagConstraints makeGbc(int y, boolean start) {
    GridBagConstraints gbc = new GridBagConstraints();
    gbc.gridx = 0;
    gbc.gridy = y;
    if (start) {
        gbc.anchor = GridBagConstraints.LINE_START;
    }
    gbc.insets = new Insets(2, 2, 2, 2);
    return gbc;
}

Then, when I want to place something in my layout using a GridBagConstraints object build from this method, I can use this:

this.add(check, this.makeGbc(i++, true));

The biggest benefit to this approach is that I can easily adjust all of the buttons by changing this one method. This is a great example of the “Don’t Repeat Yourself” or DRY principle.

Python

In many cases, I found it helpful to create a dictionary of settings that I’d like use with the grid() method, and then pass that entire dictionary as keyword arguments to the method. I usually did this either in a helper method within the class itself, or in a parent class in the case of pizza and drink panels. Here’s an example:

def _grid_dict(self, row: int, sticky: str) -> Mapping[str, Any]:
    """Create a dictionary of settings.

    Args:
        row: the row for the item
        sticky: the sticky settings
    """
    settings: Dict[str, Union[str, int]] = dict()
    settings["row"] = row
    settings["column"] = 1
    settings["padx"] = 2
    settings["pady"] = 2
    settings["sticky"] = sticky
    return settings

Then, when I want to place something in my layout using the grid() method with these settings, I can use this:

checkbutton.grid(**self._grid_dict(i, "W"))

Notice that I have to place two asterisks ** before the method. That tells Python to “unpack” the dictionary returned by that method so that it can be read as individual keyword parameters. A deeper explanation is found here.

The biggest benefit to this approach is that I can easily adjust all of the buttons by changing this one method. This is a great example of the “Don’t Repeat Yourself” or DRY principle.

I also had to tell Mypy to ignore the lambda expressions used in the MenuPanel class, as it cannot properly determine the type of the lambda. You can do this by adding a # type: ignore comment at the end of the offending line.

button = Button(master=side_frame, text=str(side),
                command=lambda x=str(side):  # type: ignore
                self.action_performed(x))

If anyone is able to figure out exactly how to properly get Mypy to handle this, there are major Bug Bounty points available!

Event-Driven Programming

This page lists the milestone requirements for Milestone 5 of the CC 410 Restaurant Project. Read the requirements carefully and discuss any questions with the instructors or TAs.

Purpose

The CC 410 Restaurant Project project for this semester is centered around building a point of sale (POS) system for a fictional restaurant named That’s a Wrap, offering wraps of all shapes and sizes to celebrate our favorite movies.

The fifth milestone involves dealing with the various events generated by the GUI and constructing a list of items that represent an order.

General Requirements

Assignment Requirements

Changes to Previous Milestone

• Changes to the previous milestone:

  • Add a Cancel button to each of the wrap, side, or drink panels.
  • Add a Delete button to the OrderPanel panel.
  • Switch the list box in the OrderPanel to a tree element (Java JTree or tkinter Treeview). See the associated example project for code you can use for this.

See the updated GUI mockups below for some design ideas.

Order Tree Functionality

Once the entire project is working, you should observe the following behavior on the new tree element.

• When an item is added to the tree element in the OrderPanel, the following should happen:

  • The item’s string representation should be a top-level node in the tree.
  • Any instructions for that item should be represented as child nodes of the top-level node.
  • The item should be shown fully expanded by default.
  • The tree element should only allow the user to select one item at a time.

Save Buttons

When the Save button in any of the wrap, side, or drink panels is clicked, the following should happen:

• The item currently represented by the panel should be updated such that each attribute matches the current status of the associated GUI element.
• The item should be placed into the tree in the OrderPanel if it is a new item, or the item should be updated if it is being edited.
• The main panel in PrimaryWindow should be replaced with the MenuPanel (this was part of the previous milestone).

Cancel Button

When the Cancel button in any of the wrap, side, or drink panels is clicked, the following should happen:

• If an item is being edited, any changes made in the GUI should be discarded (the item should not be changed).
• The main panel in PrimaryWindow should be replaced with the OrderPanel (this was part of the previous milestone for the Save button, and the code is similar).

Edit Button

When the Edit button in the OrderPanel is clicked, the following should happen:

• The Item that is currently selected should be determined. If the selection is an child of that item, the code should work upwards in the tree to find the related Item.
• The appropriate wrap, side, or drink panel should be loaded into the main panel in PrimaryWindow and populated with the current data from the item (most of this should be present from the previous milestone, but much of it may be untested at this point).
• If the item is saved via the Save button, it’s entry in the tree element should be updated without changing the order of the items in the tree.
• If the changes are cancelled via the Cancel button, no changes should be made.

Delete Button

When the Delete button in the SidebarPanel is clicked, the following should happen:

• The Item that is currently selected should be determined. If the selection is an child of that item, the code should work upwards in the tree to find the related Item.
• That item should be removed from the tree element and any other relevant data structures in the OrderPanel class.

New Unit Tests

Unit tests should be added to the corresponding test package for the following classes:

• Each wrap panel in thatsawrap.gui.wraps
• Each drink panel in thatsawrap.gui.drinks
• The side panel in thatsawrap.gui.sides

Documentation and Tests

Finally, the following requirements from the previous milestone are continued:

• Classes and unit tests in the thatsawrap.gui package and sub-packages do require all appropriate documentation comments, and must be free of style errors. Every method must include full documentation comments.
• Classes in the thatsawrap.gui base package do not require unit tests, but all wrap, drink, and side panels require unit tests as outlined above.
• Classes and unit tests in the thatsawrap.gui package and sub-packages do not require type hints in Python, though you may continue to use them if they are helpful. Any errors from Mypy originating in these classes will be ignored.
• Update the GUI UML Diagram Contained in this project to match the updated structure of the GUI portions of this project. There will most likely not be any new classes, but new associations between existing classes.

Time Requirements

Completing this project is estimated to require 3-8 hours.

Grading Rubric

This assignment will be graded based on the rubric below:

• New GUI elements (“Cancel”, “Delete” and tree element): 5%
• Tree element displays order items correctly: 5%
• “Save” buttons work properly for all items: 25%
• “Cancel” buttons work properly for all items: 5%
• “Edit” button works properly for all items: 25%
• “Delete” button works properly for all items: 5%
• Unit Tests: 20%
• Updated UML Diagram: 10%

The following deductions apply:

• Any portion of the project which will not compile (Java), pass a strict type check (Python), or execute properly will be given a grade of 0.
• Any portion of the project which does not meet the general requirements listed above will have a commensurate amount of points deducted.

This is not an exhaustive list of possible deductions. The instructors will strive to provide reasonable and fair grading, but we can’t predict all possible defects. It is up to the student to ensure that the project is complete and correct before submission.

Submission

Submit this assignment by creating a release on GitHub and uploading the release URL to the assignment on Canvas. You should not submit this Codio project or mark it as complete in Codio, in case you need to come back to it and make changes later.

Updated GUI Sketches

Below are some GUI sketches to help you visualize one possible GUI for this project. You do not have to match this design at all, but this is at least a good starting point that you can reach based on what you know so far.

Main Window

Item Panel

Helpful Methods

I found these methods helpful in my solution:

• PrimaryWindow.addItem(item) - basically a pass-through method that calls the OrderPanel.addItem(item) method. This method would be accessible to all order item panels since they get a reference to the PrimaryWindow instance.
• OrderPanel.addItem(item) - adds a new item to the tree element, or updates the item if it is already contained in the tree.
• You must check that the two elements are the same instance, not just that they are equal. Otherwise, two items with the same ingredients and toppings will be regarded as the same item, preventing the user from ordering more than one of them. This can be done using the == operator in Java, or the is operator in Python. This means that you won’t be able to use the normal contains() or in method for determining if the item is already in a list - you must iterate through the list manually.
• OrderPanel.updateTree(item, node) - handles actually updating the tree. If node is null or not provided, it creates a new one, otherwise it uses the existing node and updates it. It should return the node or that node’s id when complete.

Unit Tests

Wrap Panels

Each wrap panel test class should contain unit tests for the following:

• If a panel is created without providing an existing item, it should create a new instance of that item in its internal attribute.
• Call the actionPerformed() method with an invalid action command, and assert that an exception is not thrown (it should not do anything).
• Instantiate the panel by providing an existing item and setting GUI elements accordingly:
  • For each shell, verify that if the existing item is using that shell, the shell combo box is set correctly.
  • For each ingredient, verify that if the existing item does or does not include that ingredient, the corresponding checkbox is set correctly.
  • For each addin, verify that if the existing item does or does not include that addin, the corresponding checkbox is set correctly.
• Fire the “save” event after changing GUI elements:
  • For each shell, verify that if that shell is selected in the shell combo box, the saved item now has the correct shell value.
  • For each ingredient, verify that if that ingredient is or is not selected, the saved item now has the correct value for that ingredient.
  • For each addin, verify that if that addin is or is not selected, the saved item now has the correct value for that addin.
• Fire the “cancel” event after changing GUI elements:
  • Instantiate a panel with an existing item, change several values in the GUI, and fire a “cancel” action, then assert that the item is unchanged from its previous state.

Side Panels

Each side panel test class should contain unit tests for the following:

• For each side, create the panel by providing an instance of that side (or the name of the side) and test that the item is set to an instance of that class.
• Confirm that the penal will throw an exception if it is instantiated without providing an instance of a side (or the name of a side).
• Call the actionPerformed() method with an invalid action command, and assert that an exception is not thrown (it should not do anything).
• Instantiate the panel by providing an existing item and setting GUI elements accordingly:
  • For each size, verify that if the existing item is that size, the size combo box is set correctly.
• Fire the “cancel” event after changing GUI elements:
  • Instantiate a panel with an existing item, change several values in the GUI, and fire a “cancel” action, then assert that the item is unchanged from its previous state.

Drink Panels

Each drink panel test class should contain unit tests for the following:

• If a panel is created without providing an existing item, it should create a new instance of that item in its internal attribute.
• Call the actionPerformed() method with an invalid action command, and assert that an exception is not thrown (it should not do anything).
• Instantiate the panel by providing an existing item and setting GUI elements accordingly:
  • For each size, verify that if the existing item is that size, the size combo box is set correctly.
  • For each ingredient, verify that if the existing item does or does not include that ingredient, the corresponding checkbox is set correctly.
• Fire the “save” event after changing GUI elements:
  • For each shell, verify that if that shell is selected in the shell combo box, the saved item now has the correct shell value.
  • For each ingredient, verify that if that ingredient is or is not selected, the saved item now has the correct value for that ingredient.
• Fire the “cancel” event after changing GUI elements:
  • Instantiate a panel with an existing item, change several values in the GUI, and fire a “cancel” action, then assert that the item is unchanged from its previous state.

Python tox Updates

I ran into issues with Python not running unit tests in tox properly on this assignment. There are two causes:

• Because tox runs in a virtual environment by default, it is unable to construct the graphical tkinter elements for testing. This can be resolved by passing through the DISPLAY environment variable.
• Because pytest is apparently very memory inefficient, the unit tests are killed by Codio once they consume too much memory. To work around this, we’ll run our unit tests in batches.

An updated tox.ini file is given below. I recommend replacing your file with this one:

[tox]
envlist = py39
skipsdist = True

[testenv]
deps = -rrequirements.txt
passenv = DISPLAY
ignore_errors = True
commands = python3 -m mypy -p src --html-report reports/mypy
           python3 -m coverage run --parallel-mode --source src -m pytest test/thatsawrap/data --html=reports/pytest-data/index.html
           python3 -m coverage run --parallel-mode --source src -m pytest test/thatsawrap/gui/wraps --html=reports/pytest-wraps/index.html
           python3 -m coverage run --parallel-mode --source src -m pytest test/thatsawrap/gui/drinks test/thatsawrap/gui/sides --html=reports/pytest-side-drinks/index.html
           python3 -m coverage combine
           python3 -m coverage html -d reports/coverage
           python3 -m flake8 --docstring-convention google --format=html --htmldir=reports/flake
           python3 -m pdoc --html --force --output-dir reports/doc .

The major changes:

• passenv = DISPLAY will tell the tox environment which display to use when loading tkinter elements.
• We now run coverage in parallel mode, and specify the test folders in the pytest command. This will run three separate sets of tests.
• Notice that the test reports will now be in different folders. The old reports/pytest folder will no longer be updated.
• We added a coverage combine command to combine the coverage data from multiple executions of pytest.

Orders & Combos

This page lists the milestone requirements for Milestone 6 of the CC 410 Restaurant Project. Read the requirements carefully and discuss any questions with the instructors or TAs.

Purpose

The CC 410 Restaurant Project project for this semester is centered around building a point of sale (POS) system for a fictional restaurant named That’s a Wrap, offering wraps of all shapes and sizes to celebrate our favorite movies.

The sixth milestone involves creating combo meals and orders from the items selected in the GUI. We’ll use this milestone to explore some software design patterns in our code, as well as learn about using test doubles in our unit tests. With this milestone, most of the work on the core functionality of the GUI will be complete.

General Requirements

Assignment Requirements

New Classes

This assignment will add several new classes to the project

Order Class

thatsawrap.data.order.Order - this class should represent a collection of Item objects that make up an order.

• It should implement the Iterator Pattern, such that it can be used in a for each loop or enhanced for loop to iterate through all items in the list.
• It should also support standard collection methods such as:
  • Getting the number of items in the collection
  • Determining if a given instance of an Item object is contained in the collection. Recall that this should use the identity test, not the equality test.
  • Getting a single item from the collection based on the index of that item.
  • Any other standard collection methods that you feel are helpful. See the Collection interface in Java or Emulating Container Types in Python for additional methods that may be useful.
• It should have the following attributes:
  • A private list of Items, with methods to add and remove items.
    • NOTE - in most languages, the default method to remove an item from a collection will rely on equality testing, not instance testing. So, you may wish to write this method yourself instead of relying on the underlying collection, in order to keep this and the GUI in sync.
  • A private integer representing the order number for this order.
    • It will be generated using the OrderNumberSingleton class discussed below. It should only include a getter.
  • A private static float for the tax rate, which is set to 0.125 (12.5%) by default.
    • It should include static methods to get and set the tax rate, which will be used by all Order objects.
    • The tax rate must always be a valid percentage value ranging from 0.0 to 1.0, inclusive, and this should be enforced by the setter.
• It should also have getters for these virtual attributes or properties:
  • Subtotal - the total sum of the prices for each item in the order.
  • Tax - the subtotal multiplied by the tax rate.
  • Total - the subtotal plus the tax.
  • Calories - the total number of calories in the order.
• All dollar amounts should not be rounded to two decimal places by this class. that will be handled by the GUI.

Combo Class

thatsawrap.data.order.Combo - this class should implement the Item interface, and represent a combo meal consisting of a wrap, a side, and a drink.

• The class should have the following attributes:
  • String Name - the name of the combo
  • A Wrap instance - the wrap in the combo
  • A Side instance - the side in the combo
  • A Drink instance - the drink in the combo
• The above attributes should conform to the following:
  • The attributes should have getters and setters.
  • The attributes may be set to null or None in the constructor to represent a combo yet to be configured.
  • The attributes should have a clear method to reset their values back to null or None. You may have a single method, or one for each attribute.
• The class should have the following static attributes:
  • Float Discount
    • It should have a value .95 ($0.95) by default.
    • It should include a static getter and setter method.
• The class should also implement the Item interface:
  • A getter for the price, that returns the sum of the prices of each item in the combo.
    • If all items in the combo are populated, the discount is applied to this total. Otherwise, no discount is applied.
  • A getter for the calories that returns the sum of the calories of each item in the combo.
  • A getter for instructions that returns a list containing the following:
    • The name of the combo, if set, as the first entry. If not, it should include “Custom Combo” as the first entry.
    • A second entry stating “$discount Discount Applied” if all items in the combo are present. If not, this entry should not be included.
• The class should also include the following methods not discussed above:
  • A constructor that accepts a string for the name.
    • The constructor should allow the name to be omitted or set to null or None. The name will only be set by the ComboBuilder class discussed below, but users will also be able to configure a custom combo via the GUI that does not include a name.
    • The constructor should set the other attributes to null or None initially.
  • A getter for all of the items in the combo. It should return a list containing each item that is populated.
  • An implementation of the appropriate method to check for equality between two objects.
    • Two combos are considered equal if their wrap, side, drink, and name are equal (they do not have to be the same instances, but each one should be equal).
    • If any attribute in this object is null or None, it is considered equal if the matching attribute is also null or None.
      • This presents a real problem in Java, because calling the equals() method on a null object will result in an exception. So, you’ll have to check if each attribute in this object is null first. If so, and the other object’s attribute is not null, then they are not equal. If this object’s attribute is not null, you can safely call equals() on it, regardless of the other object’s attribute.

Combo Builder

thatsawrap.data.order.ComboBuilder - a class that implements the Builder Pattern and Factory Method Pattern to build the available combos described below.

• It should include a single public static method to build a combo that accepts a string, and builds and returns the Combo object indicated by that string (the name of the combo).
• For simplicity, it may also include a public static getter for the number of combos available.

Order Number Singleton

thatsawrap.data.order.OrderNumberSingleton - a class that implements the Singleton Pattern to generate new order numbers.

• The class should have a non-static integer next order number attribute, which is initially set to 1
• It should have one public static method get next order number that will return the next order number.
  • This method should call a private get instance method to get the actual singleton instance stored as a static attribute in the class.
  • It should access the next order number attribute through that singleton instance.
  • This method should also use thread synchronization techniques to ensure that only a single thread can actually access and update the next order number attribute (a synchronized statement in Java or a lock in a with statement in Python).

Panel Factory

thatsawrap.gui.PanelFactory - a class that implements the Factory Method Pattern to return an instance of a GUI panel for a given wrap, side, or drink.

• It should include one public static method that is overloaded to accept two different sets of parameters:
  • get panel(String name, PrimaryWindow parent) should accept the name of a menu item item as a string, and return a panel that represents a new instance of that item, with the parent GUI element as its parent. You should be able to directly feed an action command from a button click in the GUI directly to this method and get the appropriate panel. If the name is not recognized, an exception should be thrown.
  • get panel(Item item, PrimaryWindow parent) should accept an instance of an Item and return a panel that represents that item, with the parent GUI element as its parent. If the item is not recognized, an exception should be thrown.
• For now, do not worry about updating this class to handle Combos as Items. We’ll address that in the next milestone.

Updated Classes

There will also be several updates to existing classes.

Menu Class

Menu - update to include the following items:

• A static getter method for combos that returns all pre-configured combos described below. This method should use the ComboBuilder class discussed below.
• Update the fullMenu method to include the combos returned from the method listed above.

Menu Panel

MenuPanel - update to include the following items:

• The button handler method should be updated to use the PanelFactory class to acquire the appropriate GUI panel based on the action command received from button that was clicked.

Order Panel

OrderPanel - update to include the following items:

• When clicking the Edit button, it should use the PanelFactory class to acquire the appropriate GUI panel based on the item selected in the tree.
• This class should now include a private order attribute that stores the items in the in the sidebar in an Order instance as well.
  • It should be instantiated by the OrderPanel constructor.
  • It should be kept up to date as items are added to and removed from the order in the sidebar.
  • Whenever the order is changed, it should be used to update the order number, subtotal, tax, and total elements in the GUI. Prices should be properly formatted as currency values.
    • See Currencies for Java.
• The GUI should include two new buttons:
  • New Order - clicking this button will create a new Order instance and reset all appropriate GUI elements for a new order. This will delete any existing order.
    • You may wish to implement a modal dialog that asks the user to confirm before deleting the existing order. See How to Make Dialogs for Java or Dialog Windows for Python. This is not required but highly recommended!
  • Checkout - clicking this button will have no effect at this time. It will be implemented in the next milestone.

Documentation Comments

All new and updated classes in this milestone should contain full documentation comments. Every method should be completely documented!

Unit Tests

All new classes except PanelFactory should include full unit tests that achieve at or near 100% code coverage and adequately test all aspects of the class. In addition, some previous tests may need to be updated to match new requirements.

Java Only: You should also update the unit tests for each of the GUI panels created in the previous milestone to use a fake PrimaryWindow object instead of creating one in the test. This should make the tests run much faster, and you should be able to see that the code in PrimaryWindow is not executing in the code coverage report.

Python Only: Sadly, I have yet to figure out if it is possible to properly fake parts of tkinter such that the PrimaryWindow class can be properly substituted with a fake. No changes are required at this time.

Once this milestone is complete, all classes in the following packages should have unit tests that achieve at or near 100% code coverage:

• thatsawrap.data.*
• thatsawrap.gui.drinks.*
• thatsawrap.gui.wraps.*
• thatsawrap.gui.sides.*

The only classes that do not meet this requirement are PrimaryWindow, OrderPanel, PanelFactory, and MenuPanel in the thatsawrap.gui package.

Time Requirements

Completing this project is estimated to require 3-8 hours.

Grading Rubric

This assignment will be graded based on the rubric below:

• New Classes: 40%
  • Order - 10%
  • Combo - 10%
  • ComboBuilder - 10%
  • OrderNumberSingleton - 5%
  • PanelFactory - 5%
• Unit Tests: 40%
  • Order - 15%
  • Combo - 15%
  • ComboBuilder - 5%
  • OrderNumberSingleton - 5%
• Class Updates: 20%
  • Menu and unit tests: 5%
  • MenuPanel: 5%
  • OrderPanel: 10%

The following deductions apply:

• Any portion of the project which will not compile (Java), pass a strict type check (Python), or execute properly will be given a grade of 0.
• Any portion of the project which does not meet the general requirements listed above will have a commensurate amount of points deducted.

This is not an exhaustive list of possible deductions. The instructors will strive to provide reasonable and fair grading, but we can’t predict all possible defects. It is up to the student to ensure that the project is complete and correct before submission.

Submission

Submit this assignment by creating a release on GitHub and uploading the release URL to the assignment on Canvas. You should not submit this Codio project or mark it as complete in Codio, in case you need to come back to it and make changes later.

Combos

Classic

The Godfather, The French Connection, Singin’ in the Rain

Green

The Wizard of Oz, Snow White, Rocky

Hungry

Spartacus, Yankee Doodle Dandy, Forrest Gump

Spicy

Some Like It Hot, The French Connection, Forrest Gump

Unit Tests

This is a suggested list of unit tests you may wish to implement to test your new and updated classes in this milestone. You should be able to reach 100% code coverage in each of these classes.

Order

• When an order is created:
  • It initially has 0 items in it
  • It initially has 0 for the subtotal, tax, total, and calories
• When setting the tax rate:
  • A tax rate less than 0 throws an exception
  • A tax rate greater than 1 throws an eception
• When adding/removing items (use test doubles instead of real objects):
  • The size of the order changes as items are added/removed
  • The totals (subtotal, tax, total, calories) change as items are added/removed
• When checking if the order contains an item:
  • Confirm that containment uses instance comparison and not equality comparison. Create two actual order items (this cannot be done with fakes) that will return true when equals() is called. Place one in the order, and use them to confirm that contains returns both true and false when given two items that are equal but not the same instance.
  • Confirm that removal uses instance comparison and not equality comparison (same process as above)
• Creation uses `OrderNumberSingleton:
  • Create a fake OrderNumberSingleton that returns a value for an order number, then instantiate an Order and verify that it received the given order number.
• Tax Rate is global:
  • create two Order instances, change the tax rate, and confirm that both use the new tax rate. This is best done by adding an item to each order and checking the tax virtual attribute.
• Other tests:
  • Trying to remove an item that is not in the order should not throw an exception.
  • Add fake items to the order, get the iterator, and confirm that the fake items are returned in order.
  • Add fake items to the order, and confirm that each one can be accessed via its index.

Combo

• When creating a new combo:
  • The constructor should set the name if provided.
  • The constructor should accept a name of null or None and handle that case properly
  • The constructor should set the attributes to null or None
  • The totals of the combo (total, calories) are initially set to 0.
• When setting the discount:
  • A negative discount amount should throw an exception.
  • The discount can be succesfully set to 0.
• As items are added/removed in the combo (use test doubles instead of real objects):
  • The calories and price change correctly
  • If all items are populated, the price includes the discount correctly
  • If not all items are populated, the price should not include the discount
• Discount is global:
  • Create two Combo instances, change the discount, and confirm that both use the new discount. This is best done by adding all items to each combo and checking the total price.
• Test Items List:
  • Add fake items to the combo and verify that the list returned by items getter contains those items.
  • Getting a list when the combo is empty results in an empty list.
• Instructions list:
  • The instructions list should contain the combo name if set, or a default message if not set.
  • The instructions list should include a discount message if all combo items are populated.
• Exceptions:
  • Adding the wrong type to the combo throws an exception (try adding a wrap as a side, or adding a combo as a wrap, etc.)
• Equality tests (use test doubles instead of real objects):
  • Two combos containing the same items and name are equal
  • Two combos with different name and same items are not equal
  • Two combos with same name and different items are not equal
  • Two empty combos are equal
  • An empty combo is not equal to a combo containing items
  • A combo is not equal to another object (it should not throw an exception)
  • _You may need to add additional tests to achieve 100% code coverage of the equality method.

ComboBuilder

For these tests, I recommend just checking the types of the wrap, side, and drink items in the Combo returned, as well as the name, rather than using any fake objects. As before, you may wish to make these attributes visible to the test.

• Test that each combo can be built correctly by providing the name
• Test that providing an invalid name throws an exception

OrderNumberSingleton

• Call getNextOrderNumber() several times and make sure each one is sequential.

Python tox Updates

I ran into even more issues with Python not running unit tests in tox properly on this assignment. As before, it seems to be the same cause:

• Because pytest is apparently very memory inefficient, the unit tests are killed by Codio once they consume too much memory. To work around this, we’ll run our unit tests in batches.

An updated tox.ini file is given below. I recommend replacing your file with this one:

[tox]
envlist = py39
skipsdist = True

[testenv]
deps = -rrequirements.txt
passenv = DISPLAY
ignore_errors = True
commands = python3 -m mypy -p src --html-report reports/mypy
           python3 -m coverage run --parallel-mode --source src -m pytest test/thatsawrap/data --html=reports/pytest-data/index.html
           python3 -m coverage run --parallel-mode --source src -m pytest test/thatsawrap/gui/wraps/test_GodfatherPanel.py --html=reports/pytest-items1/index.html
           python3 -m coverage run --parallel-mode --source src -m pytest test/thatsawrap/gui/wraps/test_WizardPanel.py --html=reports/pytest-items2/index.html
           python3 -m coverage run --parallel-mode --source src -m pytest test/thatsawrap/gui/wraps/test_SomeLikePanel.py --html=reports/pytest-items3/index.html
           python3 -m coverage run --parallel-mode --source src -m pytest test/thatsawrap/gui/wraps/test_WestSidePanel.py --html=reports/pytest-items4/index.html
           python3 -m coverage run --parallel-mode --source src -m pytest test/thatsawrap/gui/wraps/test_SpartacusPanel.py --html=reports/pytest-items5/index.html
           python3 -m coverage run --parallel-mode --source src -m pytest test/thatsawrap/gui/drinks test/thatsawrap/gui/sides --html=reports/pytest-side-drinks/index.html
           python3 -m coverage combine
           python3 -m coverage html -d reports/coverage
           python3 -m flake8 --docstring-convention google --format=html --htmldir=reports/flake
           python3 -m pdoc --html --force --output-dir reports/doc .

The major changes:

• We now run coverage in parallel mode, and specify the test folders in the pytest command. This will run several separate sets of tests. I had to move each large GUI panel to its own test, as I couldn’t run them all in a single batch.
• Notice that the test reports will now be in different folders. The old reports/pytest folder will no longer be updated.
• We added a coverage combine command to combine the coverage data from multiple executions of pytest.

Checkout

This page lists the milestone requirements for Milestone 7 of the CC 410 Restaurant Project. Read the requirements carefully and discuss any questions with the instructors or TAs.

Purpose

The CC 410 Restaurant Project project for this semester is centered around building a point of sale (POS) system for a fictional restaurant named That’s a Wrap, offering wraps of all shapes and sizes to celebrate our favorite movies.

The seventh milestone involves finalizing the GUI for creating combos, and handling the steps to check out and pay for an order, including printing a receipt. The purpose is to continue to learn how to use and modify an existing GUI and interface with an external library.

General Requirements

Assignment Requirements

It is best to think of this assignment as one consisting of two distinct parts.

Part 1 - Update GUI Panels to Handle Combos

Add updated buttons and panels to the GUI to facilitate creation and customization of combos created as part of the previous milestone. It should have the following features:

• Users should be able to directly select one of the pre-built combos included in the previous milestone and add it to the order.
• Users should be able to create a custom combo consisting of a wrap, side, and/or drink of their choice.
  • You do not have to enforce the requirement that a combo contains all items to be added to the order. However, the combo should only get the discount if all items are populated. The existing Combo class should handle this as defined in the previous milestone.
• Any wrap, side, or drink in the combo should also be customizable.
• Some of the code in the OrderPanel class will need to be updated to properly handle combos.
  • Combos should be displayed with the title “Combo” as the topmost element in the tree.
  • The name of the combo should be the first child node, if set. If not set, a default name may be used.
  • If the combo is eligible for the discount, that message should be displayed as the second child node of the combo.(Hint: both of these are present in the instructions list returned from the combo class!)
  • Each item in the combo should be displayed below the combo name and discount message as a child node.
  • The instructions for each item in the combo should be displayed as child nodes of the appropriate item.
• In effect, combos will have 3 levels in the tree instead of the usual 2 for other order items.
• This means that some of the logic for handling item selection and updates will need to be carefully updated.
• You may choose to simply write special cases for handling combos instead of generalizing or using recursion (the tree will be limited to 3 levels of depth, not including the single hidden root node).
• Any new functionality should not interfere with previous functionality. This means:
  • All individual wraps, sides, and drinks can be added to the order and customized.
  • Any items in the order can be selected and edited.
    • If an item is part of a combo, you may choose to load the screen for editing the entire combo instead of the item selected - this is up to you!

Hints for Part 1

At the bottom of this page is a GUI sketch of one possible way to build a screen for customizing a combo. It is designed to reuse the existing panels for each menu item. We will refer to this class as ComboPanel in this document. In your implementation, you are encouraged to reuse existing code whenever possible - try to stick to the Don’t Repeat Yourself principle. Some hints for this particular implementation:

• Instead of each panel using the PrimaryWindow class/type as its parent, we can abstract that to a ParentPanel interface that is implemented by both the PrimaryWindow class and ComboPanel. This allows the existing order item panels to use the new ComboPanel as its parent.
• Use combo boxes to allow users to select from existing items to add to the combo. Add a listener/event handler for when the combobox is changed, and use that to change the panel for that item.
• Include a default option representing “no selection” in the combo boxes to allow users to clear out a particular option.
• Recall that the panels for each menu item will call a method in the parent panel when the item is saved. This can be used to retrieve the updated item from the panel when the “Save” button is clicked in the combo customization panel. Here’s the basic order of events:
  1. Click “Save” in ComboPanel
  2. Fire “save” event in item panel
  3. Receive item from panel via the panel calling the save method in its parent (which is now ComboPanel instead of PrimaryWindow)
  4. Update the combo order item
  5. Call the save method in the PrimaryWindow to add the item to the order.
• You may choose to add additional getters to the classes in the data package as desired.
• In Python, you may have a circular reference in your PanelFactory since it could be used from within ComboPanel, but also will be used to create instances of ComboPanel. A way to resolve this would be to create a ComboPanelFactory to handle combos, and adapt the code where PanelFactory is used to direct combo instances to the new ComboPanelFactory instead.

Documentation Comments

All new and updated classes in this milestone should contain full documentation comments. All methods must be fully documented!

Unit Tests

Your new GUI panel(s) should include some basic unit tests modeled after the tests used for the item panels. Specifically, you should test the following:

• Selecting a particular wrap, side, or drink in the appropriate GUI element causes a panel of the correct type to be loaded.
• Receiving a combo as input containing a particular wrap, side, or drink causes the panel of the correct type to be loaded.
• Selecting a particular wrap, side, or drink to be included in the combo via the GUI causes an item of that type to be added to the resulting Combo object when it is saved.
• Selecting the “no selection” option will remove that item from an existing Combo object when it is saved.
• Cancelling will result in no changes being made to the Combo object.

You should use test doubles (stubs, fakes, or mocks) in these unit tests to mimic the other parts of the application, including the order items and associated panels. The goal is to only test the new GUI panel(s) in isolation. This may not be possible in Python due to issues with mocking classes from tkinter.

Part 2 - Checkout

Implement the functionality for a user to checkout and complete an order. This process will make use of an external library to handle credit cards, cash transactions, and printing a receipt. First, you’ll need to install the register library into your application:

• Java
  • Download and install the latest JAR file release from GitHub.
  • View the Javadoc for specifics of how to use it.
  • Review the Source Code if desired.
  • All library classes are in the edu.ksu.cs.cc410.register package.
  • Post any questions or bugs regarding the library to the GitHub Issues page.
  • Pull requests for bug fixes are welcome! However, in general we won’t greatly change or enhance the functionality of the library overall.
• Python
  • Download and install the latest wheel file release from GitHub.
  • View the Documentation for specifics of how to use it.
  • Review the Source Code if desired.
  • All library classes are in the cc410.register package.
  • Post any questions or bugs regarding the library to the GitHub Issues page.
  • Pull requests for bug fixes are welcome! However, in general we won’t greatly change or enhance the functionality of the library overall.

When the user clicks the “Checkout” button in the GUI, they should be presented with the following options:

• Pay by Credit/Debit Card
• Pay by Cash
• Cancel

Clicking “Cancel” will return to the main GUI screen without changing the existing order.

Otherwise, see the descriptions below for the process of paying by credit/debit card or cash.

You may wish to use modal dialogs in various places in this milestone to present responses or error message to the user. See How to Make Dialogs for Java or Dialog Windows for Python.

Pay by Credit Card

When a user chooses to pay by credit card, the application should call the appropriate method of the CardReader class in the external library. That method will return one of the CardTransactionResult enumeration values, which describes the result. If the response is APPROVED, the transaction is completed and the application may proceed to print the receipt (see the description below). Otherwise, the appropriate error message from the CardTransactionResult should be displayed to the user, and they may choose to try again.

Pay by Cash

When the user chooses to pay by cash, the application should show a window where the user can enter the cash denominations and amounts provided from the customer. One possible GUI sketch for this window is included at the bottom of this page.

The GUI should include a “Cancel” button that can be used at any time to cancel the cash transaction and return back to the main GUI screen without changing the existing order.

The CashDrawer class in the external library is used to keep track of the available amount of each denomination in the drawer and to balance transactions. Each transaction begins by opening the drawer and providing the expected amount to be deposited. Then, while the drawer is open, cash denominations are added to the drawer from the customer and any change given back is deducted from the drawer. When the drawer is closed, the amount it contains must equal the previous amount plus the expected transaction amount. In addition, the total value in the drawer and the count of each denomination in the drawer may only be accessed when the drawer is closed.

Cash denominations are listed in the CashDenomination enum, which includes both the name and value of each denomination.

If the customer has not provided enough money to pay for the transaction, your application should not allow it to be finalized. Your application should also handle making appropriate change from the cash drawer when finalizing a transaction. This includes determining the count of each denomination to be given back to the customer. Some tips for completing this portion of the project:

• The contents of the drawer cannot be queried while the drawer is open, nor can the contents of the drawer be updated while it is closed. The external library will throw exceptions if this rule is violated.
• To make change, find the amount to be given back and work from the highest denomination to the lowest. Make use of division and modulo arithmetic. (This is exactly backwards to how you were most likely taught to do this in your head!) If you use any online resources to create this algorithm, make sure you cite them in the comments of your code.
• The cash drawer contains limited amounts of each denomination. So, when making change, you may find that you don’t have enough of a particular denomination. If that is the case, deduct one from the next largest available denomination and use that to refill this denomination. We will assume that you are able to freely convert one denomination to another using an external source. This is more difficult than it may seem. Make sure the rest of the process works before worrying about this edge case - it is not worth very many points!

When the transaction is completed successfully, the application may proceed to print the receipt (see the description below).

Printing a Receipt

Once a transaction has been completed successfully, the system should print a receipt containing the details of the transaction. The ReceiptPrinter class in the external library is used to print a receipt.

The receipt should include the following information:

• The order number
• The date and time of the transaction
• A list of all items in the order, including price and special instructions.
• The subtotal
• The tax amount
• The total amount
• The payment method (credit/debit or cash)
• If paid by cash, the amount received and the change given.

The receipt can only be printed one line at a time using the appropriate method in the ReceiptPrinter class, and each line is limited to no more than 40 characters. You are encouraged to make use of simple formatting, ASCII art, and short indentations to make the receipt more readable. There are methods provided in the ReceiptPrinter class to start and end a receipt.

The ReceiptPrinter class will print the receipt to a file named receipt.txt in the project folder. By default, the ReceiptPrinter will append new receipts to the end of that file. You may wish to empty this file regularly as part of testing, and should not commit it to GitHub.

Documentation Comments

All new and updated classes in this milestone should contain full documentation comments. All methods must be fully documented!

Unit Tests

Your application should include unit tests to test any functionality provided by your application. Specifically, you should test the following:

• When a cash transaction is finalized, the customer must have provided an amount of money equal to or greater than the transaction amount.
• When a cash transaction is completed, your application makes the correct change - both the amount and the denominations returned.
• When making change, the application will correctly handle the situation when not enough of a denomination is present.
• When a receipt is printed, it includes all of the information in an order.

You do not have to verify that the external library functions correctly. It already contains a complete set of unit tests. You are encouraged to review the source code of the unit tests contained in the external library for examples of how to test your own code!

Instead, you are highly encouraged to write wrapper classes around the classes in the external library using the adapter pattern and test those wrapper classes that contain your logic.

For example:

• Write a method in your CashDrawer wrapper that accepts a transaction amount and a description of the cash denominations provided by the user, and then computes the correct change and returns a description of the denominations and amounts to be given as change. If the user did not provide enough cash, it could throw an exception or some other error.
• Write a method in your CashDrawer wrapper that accepts a description of the cash provided by the user, and a description of the change to be given. The method should compute the updated contents of the drawer using its existing contents, making substitutions when needed to handle situations where not enough of a denomination are present, and then return a description of those changes.
  • Your wrapper would also include a separate method to actually send those changes to the cash drawer, but that method does not need to be unit tested for correctness and shouldn’t be directly called by the method above. That would technically be an integration test, which we aren’t worrying about for now.
• Write a method in your ReceiptPrinter wrapper that accepts an Order object and returns a list of strings that represent the receipt to be printed. Verify that the contents of that list fully reflect the Order given to it.
  • Your wrapper would also include a separate method to actually print a list of strings to a receipt, but that method does not need to be unit tested for correctness and shouldn’t be directly called by the method above.

If done correctly, you should not have to create a test double for any of the classes in the external library. While not an unbreakable rule, it is generally considered a bad practice to mock a type you don’t own, as that can lead to issues if the external library’s API changes in the future. The mock version of the library will continue to function as before, meaning tests will pass that would otherwise fail when executed on the real library.

Time Requirements

Completing this project is estimated to require 5 - 10 hours.

Grading Rubric

This assignment will be graded based on the rubric below:

• Part 1 - 50%
  • Combo Buttons on Menu Panel - 5%
  • Combo Interface for selecting/editing items - 25%
  • Sidebar Handles Combos - 10%
  • Unit Tests - 10%
• Part 2 - 50%
  • Credit Card - 5%
  • Cash Interface - 5%
  • Makes Change - 15%
  • Prints Receipt - 15%
  • Unit Tests - 10%

The following deductions apply:

• Any portion of the project which will not compile (Java), pass a strict type check (Python), or execute properly will be given a grade of 0.

This is not an exhaustive list of possible deductions. The instructors will strive to provide reasonable and fair grading, but we can’t predict all possible defects. It is up to the student to ensure that the project is complete and correct before submission.

Submission

Submit this assignment by creating a release on GitHub and uploading the release URL to the assignment on Canvas. You should not submit this Codio project or mark it as complete in Codio, in case you need to come back to it and make changes later.

Sample Combo Customization GUI

Sample Cash Transaction GUI

You may wish to review the Spinner (Java) or Spinbox (Python) GUI elements.

Website Basics

This page lists the milestone requirements for Milestone 8 of the CC 410 Restaurant Project. Read the requirements carefully and discuss any questions with the instructors or TAs.

Purpose

The CC 410 Restaurant Project project for this semester is centered around building a point of sale (POS) system for a fictional restaurant named That’s a Wrap, offering wraps of all shapes and sizes to celebrate our favorite movies.

The eighth milestone involves moving into the web by creating a data-driven website to display the menu and some other information about the restaurant.

General Requirements

Assignment Requirements

Web Framework

Add a Web Framework to the existing project.

• Java - Install the Spring framework using the Spring Initializr. It should include the Spring Boot DevTools, Spring Web, and Thymeleaf Template Engine as dependencies.
• Python - Install the Flask framework and the Flask-Classful extension. You may also wish to install python-dotenv to use a .flaskenv file.

Web Code

• Create a new thatsawrap.web package.
• Create a thatsawrap.web.MenuController class to act as the controller. It should include the following routes:
  • / - a home page for the application.
  • /about - an about page with the text given at the bottom of the page. You may add additional text and items as desired
  • /menu - a page that includes the entire menu (all predefined combos, wraps, sides, and drinks).
    • It should use the existing Menu class to collect these items.
    • You may add additional methods (with requisite unit tests) to the Menu class as desired to make this work.
• Update the required files to launch the web application properly as shown in the example video.

Templates

Create a base layout file including the following:

• Valid HTML5 structure
• A <title> element including the page name, followed by - That's a Wrap
• A <body> containing:
  • <nav> that contains links to all pages in the application
  • <main> containing all the content in the page
  • <footer> containing the following copyright notice: “© 2021 That’s a Wrap”
• It is recommended (but not required) to build upon an existing template. You may wish to review the Bootstrap 4.6 Examples.

Create the following template files to match the routes listed above:

• index.html contains an <h1> tag with the title “Homepage” and the following text in a paragraph (you may add additional text as desired):

Welcome to That’s a Wrap! Our motto: be a star - wrap things your way!

• about.html contains an <h1> tag with the title “About That’s a Wrap” and the following text in a paragraph (you may add additional text as desired):

That’s a Wrap was developed as part of the CC 410 course at Kansas State University by <your name here>.

• menu.html contains the following content:
  • an <h1> containing “Menu”
  • an <h2> for each of the four categories of menu items (wrap, side, drink, combo)
  • Each menu item should be placed in a <div> with the class menu-item. It should include:
    • The name of the item
    • The price of the item
    • The calories of the item
    • If the item comes in multiple sizes, the price and calories for each size should be listed somehow!
    • If the item is a combo, you may also include the contents of the combo!
  • You may use additional HTML elements & CSS style to improve the readability of this page as you see fit! As with the GUI project, this is your chance to explore a bit.
    • The model solution uses the Card component and Row Columns in Bootstrap 4.6.
  • Under the “Combo” heading, add a note that any wrap, sides, and drink may be combined for a combo discount, and print the current combo discount value as well. (Hint: you’ll have to send this through the controller to the template somehow…)

Documentation & Testing

• All new classes and methods must include full documentation comments.
• HTML templates do not require documentation, but inline comments are recommended if they are useful.
• No new unit tests are required.

Time Requirements

Completing this project is estimated to require 2 - 5 hours.

Grading Rubric

This assignment will be graded based on the rubric below:

• Web Framework Installation: 10%
• Web Code: 30%
  • Index & About Routes: 10%
  • Menu Route: 20%
• Templates: 60%
  • Layout Template: 20%
  • Index & About Templates: 10%
  • Menu Template: 30%

The following deductions apply:

• Any portion of the project which will not compile (Java), pass a strict type check (Python), or execute properly will be given a grade of 0.
• Any portion of the project which does not meet the general requirements listed above will have a commensurate amount of points deducted.
• Points will be deducted if pages do not contain valid HTML5 with all tags properly closed.

This is not an exhaustive list of possible deductions. The instructors will strive to provide reasonable and fair grading, but we can’t predict all possible defects. It is up to the student to ensure that the project is complete and correct before submission.

Submission

Submit this assignment by creating a release on GitHub and uploading the release URL to the assignment on Canvas. You should not submit this Codio project or mark it as complete in Codio, in case you need to come back to it and make changes later.

Web Sketches

Below is a screenshot from a previous model solution for some web design inspiration.

Form Data

This page lists the milestone requirements for Milestone 9 of the CC 410 Restaurant Project. Read the requirements carefully and discuss any questions with the instructors or TAs.

Purpose

The CC 410 Restaurant Project project for this semester is centered around building a point of sale (POS) system for a fictional restaurant named That’s a Wrap, offering wraps of all shapes and sizes to celebrate our favorite movies.

The ninth milestone involves augmenting the menu display from the previous project by adding search and filtering functionality via an HTML form.

General Requirements

Assignment Requirements

This milestone adds several pieces of functionality to your existing website, mostly based around searching and retrieving menu items.

Simple Search via Keywords

Your website should implement a simple search functionality via keywords, which allows the user to enter one or more words, separated by spaces, in a text input field, and then any menu items containing any of those keywords anywhere in the name of the item should be displayed on a results page.

You should also handle the case where keyword searches will return a combo if it contains an item that matches the search term. For example, a search for “wizard” should not only return that wrap, but also any combos that include that item.

Your search page should be accessible via the search route/URL. If you used a template layout that includes a search box, such as the Bootstrap Sticky Footer with Navbar, you may implement this search functionality using the search box in the default layout. Make sure that you specify the action of the form to point to the correct URL, since it will be available on all pages. The form should use the HTTP POST method.

You may choose to use the same template for both the search page and the results, or different templates. Also, don’t forget to add a link to the search URL in your site’s navigation in the layout template.

Advanced Search and Filter

Your website should also implement an advanced search and filter feature. This page will allow the user to find menu items based on the following criteria:

• Keywords (same as the simple search above)
• Type (wrap, side, drink, combo)
• Price Range (minimum & maximum)
• Calories Range (minimum & maximum)

Your advanced search page should include HTML form elements for each of the items given above, arranged to make it clear to the user how to use the form. Try to make it as functional as possible based on the user’s intent. For example, if the user doesn’t enter any keywords, assume that they wish to find all menu items. Likewise, if the user inputs a maximum price but not a minimum, you should show all items that are less than the maximum price given. When submitted, the form should use the HTTP POST method. If any inputs are invalid or cannot be parsed, you should substitute them with reasonable default values.

Your advanced search page should be accessible via the advancedsearch route/URL. You should add a link to this URL to your site’s navigation.

You must use the same template for both the search form and displaying results. If the search form has been completed and submitted, the submitted values should be present in the form where the results are displayed. Likewise, if the form has not been completed or no results are present, the site should clearly present that information to the user.

Search Functions in Menu

The functions required to search and filter the menu should be implemented in the existing Menu class as static methods. You should not perform any searching in the web application controller itself - it should simply call these methods as needed.

Some recommended functions you may wish to implement:

• filterKeywords(Iterable<Item> items, String keywords) - returns Iterable<Item>
• filterTypes(Iterable<Item> items, boolean wrap, boolean side, boolean drink, boolean combo) - returns Iterable<Item>
  • Alternatively, you could call the appropriate existing methods to collect these types initially before filtering
• filterPrice(Iterable<Item> items, float min, float max) - returns Iterable<Item>
• filterCalories(Iterable<Item> items, int min, int max) - returns Iterable<Item>

Each new method added to Menu should include proper unit tests. You are encouraged to use test doubles (mocks, etc.) to test these methods rather than using actual menu items.

Documentation & Testing

• All new classes and methods must include full documentation comments.
• HTML templates do not require documentation, but inline comments are recommended if they are useful.
• Any methods added to the Menu class require unit tests to achieve 100% coverage. You should use test doubles in these unit tests, and make sure you are testing all possible outcomes.

Time Requirements

Completing this project is estimated to require 2 - 5 hours.

Grading Rubric

This assignment will be graded based on the rubric below:

• Simple Search: 30%
  • Keyword Search: 15%
  • Results: 15%
• Advanced Search: 50%
  • Types: 10%
  • Price: 10%
  • Calories: 10%
  • Results: 20%
• Unit Tests: 20%

The following deductions apply:

• Any portion of the project which will not compile (Java), pass a strict type check (Python), or execute properly will be given a grade of 0.
• Any portion of the project which does not meet the general requirements listed above will have a commensurate amount of points deducted.
• Points will be deducted if pages do not contain valid HTML5 with all tags properly closed.

This is not an exhaustive list of possible deductions. The instructors will strive to provide reasonable and fair grading, but we can’t predict all possible defects. It is up to the student to ensure that the project is complete and correct before submission.

Submission

Submit this assignment by creating a release on GitHub and uploading the release URL to the assignment on Canvas. You should not submit this Codio project or mark it as complete in Codio, in case you need to come back to it and make changes later.

RESTful Architecture

This page lists the milestone requirements for Milestone 10 of the CC 410 Restaurant Project. Read the requirements carefully and discuss any questions with the instructors or TAs.

Purpose

The CC 410 Restaurant Project project for this semester is centered around building a point of sale (POS) system for a fictional restaurant named That’s a Wrap, offering wraps of all shapes and sizes to celebrate our favorite movies.

The tenth milestone involves building a RESTful web application that could be used to manage custom menu items.

General Requirements

Assignment Requirements

This milestone adds several pieces of functionality to your existing website, focused on managing custom menu items. First, you’ll need to add new classes to represent and store the custom items. Then, you’ll create a new web controller that follows a RESTful architecture to manage these custom items. While doing so, you’ll also create several templates to display the custom items on the web. Finally, you’ll update the UML diagram for your application to include the new web application classes.

New Classes

Custom Item Class

Create a class thatsawrap.data.custom.CustomItem that can represent a custom menu item. It should implement the Item interface, and should include both getters and setters for all required attributes. The class itself should only store the name, price, and calories of the item. It may simply return an empty list for special instructions. You may add additional utility methods as desired.

The class should include full documentation comments. You do not have to create any unit tests for this class.

Custom Item List Class

Create a class thatsawrap.data.custom.CustomItemList that represents a list of custom menu items. This class should implement both the Iterator design pattern (using the Iterable<CustomItem> type), as well as the Singleton design pattern. This class is designed to keep a single list of custom items in memory for the entire application. We are using the singleton pattern so that it can be instantiated in the web controllers as needed, and it will always refer to the same list.

This class should maintain a list of CustomItem objects, and provide methods for adding, retrieving, updating, and deleting those items. You may add additional utility methods as desired.

The class should include full documentation comments. You do not have to create any unit tests for this class.

In the next milestone, we will add serialization capabilities to this class, which will allow us to maintain a list of custom items across many application executions.

Web Controller

Create a new web controller named CustomController to handle these custom items. It should follow a RESTful architectural style. Specifically, it should include the following URL routes:

More details about each page is included below. In these URLs, assume the {id} is the index of the custom menu item in the CustomItemList data structure.

The class should include full documentation comments. You do not have to create any unit tests for this class.

Base Layout

Add a link to the /custom route to the navigation section of your site’s base layout template. This should be clearly accessible via the navigation menu or a similar structure.

All Items

You are encouraged to reuse the content from your existing template for displaying all custom menu items here. Each custom menu item should include a link to the /custom/{id} route for that item.

Single Item

This is a new page, but it can also reuse content from the existing template for menu items - just remove the loop! This page should include links to the /custom/{id}/edit and /custom/{id}/delete routes, as well as a link to the main /custom route.

New Item / Edit Item

You’ll need to create a form that can be used for creating new items or editing existing items. Much of the template code is reused, and there are ways to use the same template for both routes. You may include additional HTML attributes on the HTML form to add limits to the numerical values. However, your web application may assume that data submitted matches the expected format. We will handle validation of form data in the next milestone.

Delete Item

This page is a copy of the single item page, but with additional warnings about deleting the item. This page should have a form that uses the HTTP POST method to submit to the same URL. When submitted, it should delete the item from the list.

For the user, the process to delete an item should follow this pattern:

1. /custom - find the item to delete and click the link to see details.
2. /custom/{id} - click the delete link to delete the item.
3. /custom/{id}/delete - see a warning page about deleting, and click the delete link again.
4. /custom/{id}/delete - browser sends a POST request to this URL to delete the item (this is invisible to the user)
5. /custom - browser is redirected back to the main page

Update UML Diagram

At the end of this project, you should create a new UML diagram for the project that includes the new web application classes. It should also show the links to other classes/packages in the application, but those items do not require any details (they can just be simple boxes containing the class or package name.)

Time Requirements

Completing this project is estimated to require 2 - 5 hours.

Grading Rubric

This assignment will be graded based on the rubric below:

• CustomItem class - 10%
• CustomItemList class - 20%
• REST Controller & Templates - 60%
  • Create New - 15%
  • Read All - 10%
  • Read One - 10%
  • Update - 15%
  • Destroy - 10%
• UML Diagram Updates - 10%

The following deductions apply:

• Any portion of the project which will not compile (Java), pass a strict type check (Python), or execute properly will be given a grade of 0.
• Any portion of the project which does not meet the general requirements listed above will have a commensurate amount of points deducted.
• Points will be deducted if pages do not contain valid HTML5 with all tags properly closed.

This is not an exhaustive list of possible deductions. The instructors will strive to provide reasonable and fair grading, but we can’t predict all possible defects. It is up to the student to ensure that the project is complete and correct before submission.

Submission

Submit this assignment by creating a release on GitHub and uploading the release URL to the assignment on Canvas. You should not submit this Codio project or mark it as complete in Codio, in case you need to come back to it and make changes later.

Validation & Serialization

This page lists the milestone requirements for Milestone 11 of the CC 410 Restaurant Project. Read the requirements carefully and discuss any questions with the instructors or TAs.

Purpose

The CC 410 Restaurant Project project for this semester is centered around building a point of sale (POS) system for a fictional restaurant named That’s a Wrap, offering wraps of all shapes and sizes to celebrate our favorite movies.

The eleventh milestone involves adding form validation and serialization to the existing project, specifically targeted at custom menu items.

General Requirements

Assignment Requirements

This milestone consists of two portions: adding form validation to the forms for creating and editing custom items, and serializing those custom items to a file.

Form Validation

Update the forms for creating and editing custom menu items to perform server-side validation. This should use the built-in features of either Java Spring or Python Flask, as demonstrated in the example video. The following validation rules should be enforced:

• The name of the custom menu item should not be null, and have at least 4 characters.
• The price of the custom menu item must be greater than or equal to 1.50, and support no more than 2 decimal places. You may either use a validator for this or implement rounding in the setter for this item.
• The calories of the custom menu item must be an integer greater than or equal to 250.

When validation fails, the user should be taken back to the form, where the entered values are still present and the validation errors are clearly displayed.

Serialization

Update the application to use serialization to store and load the list of custom items. You may choose any file format (XML, JSON, or binary, or another of your choosing). See the serialization examples on GitHub (Java or Python) as well as the textbook for code you can use.

• The custom menu items should be loaded into memory when the singleton instance of the CustomItemList class is created. In Java, this would most likely be the getInstance() method, while in Python it would be in the __new__() method. So, when the user first visits the /custom page, the previously saved custom items should appear.
• The CustomItemList class should implement a new method called save that will serialize the current contents of the custom item list to a file.
• The application should add a new HTTP POST route to the CustomController with the path /custom/save that will save the existing custom items list to file by calling the new save method.
• Add an HTML form to the /custom index page containing a button to save the custom items by sending a POST request to the new route. This form will be very similar to the one used on the page for deleting items.

The code should include proper exception handling when reading and writing files, as well as ensuring the file is properly closed. In Java, a try with resources statement is recommended. In Python, a with inside a try structure is recommended. You may simply catch the generic exception and print it to the terminal instead of handling multiple exception types.

As proof of working serialization, create the following custom menu item and serialize it to a file, then ensure that file is committed to your Git repository when committing this project.

• Name: The Katharine Hepburn
• Price: 12.50
• Calories: 1907

Documentation & Testing

• All new classes and methods must include full documentation comments.
• HTML templates do not require documentation, but inline comments are recommended if they are useful.
• No new unit tests are required for this milestone.

Time Requirements

Completing this project is estimated to require 2 - 5 hours.

Grading Rubric

This assignment will be graded based on the rubric below:

• Validation: 30%
  • Name: 10%
  • Price: 10%
  • Calories: 10%
• Serialization: 70%
  • Save: 30%
  • Load: 30%
  • Preloaded Entry: 10%

The following deductions apply:

• Any portion of the project which will not compile (Java), pass a strict type check (Python), or execute properly will be given a grade of 0.
• Any portion of the project which does not meet the general requirements listed above will have a commensurate amount of points deducted.
• Points will be deducted if pages do not contain valid HTML5 with all tags properly closed.

This is not an exhaustive list of possible deductions. The instructors will strive to provide reasonable and fair grading, but we can’t predict all possible defects. It is up to the student to ensure that the project is complete and correct before submission.

Submission

Submit this assignment by creating a release on GitHub and uploading the release URL to the assignment on Canvas. You should not submit this Codio project or mark it as complete in Codio, in case you need to come back to it and make changes later.