31244 Applications Programming

48024 Object Oriented Design

Assignment 1: Za pizza
Due date: Monday 6 September, 6:00 pm Value: 20%
Topics: Standard patterns, OO design
Objectives: This assignment supports subject objectives 1 and 2.

1. Individual work
You should write every line of code, except for code supplied by the lecturer. You may
discuss ideas, approaches, and problems, but you are not allowed to copy code from the web or
from any other person. Do not send your code to any student; it is an offence for a student to
have a copy of someone else's assignment before the due date. The FEIT penalty for serial
academic misconduct is zero marks for the subject, as described in the subject outline. If you are
charged with Academic Misconduct I will send you email to notify you of the charge, and the
Academic Misconduct Committee will get in touch with you at some point.

2. System specification

2.1 Domain
The system simulates the operation of a pizza shop; the name of the shop is "The Za". The
system has three main parts
1. Get an order from the customer.
2. Make pizzas and sell them to the customer.
3. Reduce the stock on hand when a pizza is made.
The system will be extended in the next two assignments.

The Za offers three kinds of pizza, where each pizza has exactly two toppings. The names
of the pizzas, their toppings, and their costs are
pepperoni pepperoni, olive $4.50
marinara prawn, olive $6.70
vegetarian zucchini, artichoke $8.90
A customer can order at most three pizzas; do not test or enforce this, just choose your input so
any customer orders at most three pizzas. A customer has a name; multiple customers may have
the same name. The system starts with an arbitrary amount of 20 of each topping. When a
topping is put on a pizza, the amount on hand is reduced by 1. Don't run out of toppings; choose
your input so the Za never runs out of toppings. The Za starts with $1,000 in cash; this increases
when a customer pays for his or her order.

2.2 System interface

The system uses the console for all IO; all indents in the output are in steps of four spaces.
A full IO trace can be found at UTSOnline/Assignments/1/io.txt.

Main menu
The system is driven from a menu with five choices:
O Order from zero to three pizzas
T Show the types of pizza sold by the Za
C Show the customer orders

1 of 8
 S Show the state of the Za: cash and stock on hand
? Show the menu choices
X Exit the system
The prompt for a choice is always preceded by a space line; see the IO trace. Input may be upper
or lower case. The menu input is validated; if the choice is invalid, the system shows the valid
choices and asks for a new choice. The system runs until the user decides to exit.

A choice to see the choices gets the following response:

Your choice (O/T/C/S/?/X): ?
The menu choices are
O Order pizzas
T Show the types
S Show the Za
? Show the choices
X Exit

An invalid input gets the following response:

Your choice (O/T/C/S/?/X): wa?
Sorry, that is not a menu choice
The menu choices are
O Order pizzas
T Show the types
S Show the Za
? Show the choices
X Exit

A choice to exit simply exits the system; there is no goodbye message:

Your choice (O/T/C/S/?/X): x

Order pizza
When the user chooses to make an order, s/he is asked for his or her name, and then the
types of pizza. A pizza is requested by name; if the input does not match one of the stored types,
then an error message is shown and the user is asked to enter a new name. The order is finished
when the user enters "end". The system then shows (with two decimal places) the total charge of
that order and increments the Za's cash on hand. A single order looks like:

Your choice (O/T/C/S/?/X): o

Your name: fred

Type of pizza (or end): pepperoni
Type of pizza (or end): caviar
We make pepperoni, marinara, and vegetarian pizzas
Type of pizza (or end): marinara
Type of pizza (or end): end
The charge is $11.20
There is no requirement that a customer name is unique. Choose your input so a customer never
makes an order of more than three pizzas.

Show the customer orders

The system shows the names and orders of all customers ever served. For a run with many
orders, the customers (and their orders) are shown from first served to last.
Your choice (O/T/C/S/?/X): c

2 of 8
The customers served are
fred: pepperoni, marinara

Show the Za
The system shows the cash on hand (with two decimal places), and the stock on hand. For
a run with a single order of a pepperoni and a marinara pizza as shown above, four toppings are
used (one pepperoni, two olive, and one prawn) so the output looks like:

Your choice (O/T/C/S/?/X): s

The Za has $1,011.20

The stock on hand is
pepperoni: 19
olive: 18
prawn: 19
zucchini: 20
artichoke: 20

3. The input class In

Use the class In to get input; the code is provided and explained in an appendix to lab 1,
and may be downloaded from any lab solution on UTSOnline. Do not change anything in this
class. Please do not ask me if it's OK to change this code; do not change a line of code in this
class. Just use the class as it exists.

4. Solution outline
It is easy to get confused when designing an OO solution for this system. We refer to
different types of pizza in real life, but these are not different Java classes (types); they are
simply objects of type Pizza that have different attribute values, different toppings. I have given
you an outline of the solution in Appendix A to help you get started.

5. Expected work load

This assignment has been estimated at a load of 15 hours for the average student who has
completed all the tutorial and lab exercises. To give you some idea of the code involved, my
solution (without class In) has about 140 lines of executable code. This count does not include
class and method headers, or attributes.

6. Online support
FAQs (Frequently Asked Questions) and their answers are posted on UTSOnline in
Assignments/1/faq. If you have a question, check the FAQ first; it may already be answered
there. You should read the FAQ at least once before you hand in your solution, but to be safe
check it every couple of days. Anything posted on the FAQ is considered to be part of the
assignment specification. The FAQ will be frozen (no new entries) two days before the due date.

If anything about the specification is unclear or inconsistent, contact me and I will try to
make it clearer by replying to you directly and posting the common questions and answers to the
FAQ. This is similar to the job experience, where you ask your client if you are unsure what has
to be done, but then you write all the code to do the task. Email rist@it.uts.edu.au to ask for any
clarifications or corrections to the assignment.

I cannot tell you how to design, write, or debug your code; that is your task. I cannot
answer questions of the form "Is this right?"; I cannot "pre-mark" your design, or your code.

3 of 8
There is no discussion board, because the assignment tests your ability to develop a solution. It is
a test of your individual ability, so it is not appropriate to share problems and solutions. The
tutorials and labs provided a forum for discussion and an opportunity for feedback, using
problems that are not immediately assessed.

7. PLATE marking
Your solution is marked for correctness by PLATE (the Programming Learning And
Teaching Environment). This ensures correct and consistent marking, but you need to set up
your solution exactly as specified here. PLATE has no ability to work out that you really did the
task but just didn't get the IO right. It simply does a character by character comparison of the
output of your system and the output of the model system, when given the input in the test files.
You can submit a solution to PLATE many times; I urge you to do this, to make sure that your
IO format is correct so you receive credit for your work,

7.1 The root class

The root class must be named Za and must include a static main method for your code to
be marked by PLATE. The code in this method contains only a call to the constructor:
public class Za
{ public static void main(String[] args)
{ new Za(); }
When you create a jar file, make sure you set the root class in the jar.

7.2 IO format
A sample transcript of the IO is provided at Assignments/1/io.txt. Your IO format must
match the transcript format exactly. All indents are made in steps of four spaces. If your IO does
not follow the correct format, then PLATE will give you zero for that part. Use the class In from
Assignments/1 for all input; do not change this class.

7.3 Submission
You must submit a jar file to PLATE; a zip file is no longer accepted. The instructions to
create a jar file of your system using BlueJ are given below; if you do not use BlueJ then you
will have to work out how to create a jar file using your system.

0. Log into your home account; your home account has your student id as the login name.
1. Create a jar file of your BlueJ project.
To create a .jar file in BlueJ, in the system window go Project -> Create Jar File
Click on Include source and enter Za.
Click on Continue
2. Go to http://plate.it.uts.edu.au/
3. Click on Applications Programming -> Assessments -> Assignment 1
4. Click on Your Submission
5. On this page, you will find a form to upload your submission as a jar file.
After you have uploaded your jar file, check the "Submitted files" list to make sure your
Java files are really there. If there are no files listed, your jar or zip file was empty.

7.4 PLATE support

The assignment is due at 6:00 pm on a Monday. Please be aware that there is no technical
support over the weekend, so if there is a problem it will not be seen by technical support until
Monday morning. Problems with PLATE over the weekend will not be considered as a valid
reason for special consideration. PLATE may become overloaded on the due date, when many

4 of 8
students wait until the last second to submit, and then submit repeatedly. To be safe, submit your
solution well before the due date.

8. Style marking
Your system is marked for good design by the MoMa (Model Matcher) tool, as shown in
the marking scheme given in lab 2. MoMa compares your code to the model solution using a set
of metrics that reflect good design. This was done to ensure a consistent marking scheme, in
response to student complaints about inconsistent marking when marking was done by hand.
This means that marking is now completely consistent and has no flexibility; MoMa simply
counts the stated things and gives you a mark. It is simply not possible to write a design marking
system that has the knowledge, understanding, and flexibility of an expert programmer. If it was
possible, we wouldn't need programmers!

The model solution was designed using the design rules and standard code patterns taught
in the subject. In many cases, the patterns and rules result in just one solution and there is no
choice. In cases where no single solution is mandated, any good solution that obeys the design
rules and creates a simple, elegant, reusable solution is accepted.

I understand that you may not agree with or even like the design rules taught in this
subject. I didn't invent them! I collected them from many authorities in the field of OO design
over many years and re-phrased and systematised them. You may use different design rules in
other programming subjects. You may use different design rules at your job, when your
company defines a house style to follow. The form of the solution in this assignment, however,
should be determined by the correct application of the design rules and standard solutions taught
in this subject. This teaches you how to design; it prepares you for other situations where the
design rules may be different but must still be correctly applied.

The code shown in Appendix A may be downloaded from UTSOnline as a zip file. It does
not compile; you need to add methods to make this code compile. You do not have to use this
code. You can change anything in this code. This base code is removed from your solution by
MoMa before your solution is marked. This means that you get no marks (in the class count) for
these classes, because I gave them to you. There are additional classes, so you still get marks for
classes that you discover. Please do not ask me for the names of these classes.

9. Spoofing
Your code is marked by software, so you can get a good mark by fooling or spoofing the
software. To get a perfect mark for correctness, you could submit a solution that contains only
IO code that matches the provided IO trace. To get a perfect mark for (say) method size, you
could code 100 empty methods to bring the average method size down to 0.1 lines of code. The
penalty for spoofing PLATE is no marks for that task (correctness mark). The penalty for
spoofing MoMa is -10 marks for each spoof (style mark).

10. Submission and return

10.1 Late submission

There is no late submission. Assignments used to be due at 6pm on a Friday, but I have
now shifted the due date to 6pm the following Monday. This gives everyone an extra three days
(and a weekend) to work on the task, but you must make the Monday deadline. The model
solution will be posted to UTSOnline the next day.

5 of 8
10.2 Notification of mark
PLATE shows you the mark for correctness when you submit your code. The marking
sheet shows the correctness, style, and final marks; it can be picked up from the FEIT Resource
Hub in Building 10 (10.3.510). I will try to have the assignments marked within a week and will
send out email when the sheets can be collected; at the very latest, marking sheets can be picked
up after 6pm on Monday 20 September.

11. Special circumstances

You may apply for special consideration (SC) due to unforeseen circumstances, either
before or after the due date, at http://www.sau.uts.edu.au/assessment/consideration.html. The
three basic reasons for SC are health, family, or work problems; "I haven't finished yet" is not a
valid reason. You must provide documentary evidence to support your claim, such as a doctor's
certificate, a statutory declaration, or a letter from your employer.

12. Marking scheme

12.1 Weighting
The mark is based on two parts: correctness (c) and good design (d). Each component is
marked out of 50, and the final mark is the sum of the two components weighted equally: the
final mark = correct + design. This is the weighting for this assignment; I reserve the right to
change the weightings for other two assignments. Please do not assume that this weighting will
be used for all three assignments.

12.2 Correctness (50)

10 Main menu 10 Ordering
10 Show the Za 10 Show the customer records
5 Show the choices 5 Show the types

12.3 Good design (50)

5 Classes 10 Attributes
10 Class encapsulation 10 Small methods
10 Functions 5 Good names

12.4 Penalties
Spoof correctness 0 marks (correctness) for that part
Spoof style -10 (style) each occurrence
Empty methods -1 (style) for each empty method
Unused code -1 (style) for each uncalled method
show and toString are not counted

12.5 Minimum essential requirements

A pass is given for a correct system that has one class with one method, and is not a spoof.

6 of 8
Appendix A: Solution outline
Here are some of my ideas for the structure of the solution. You do not need to use any of
the ideas or code presented here, but they do provide the basis for the model solution that is used
to mark your code. Please do not ask me to provide more details about the ideas or code in this
appendix. Please do not ask me for more of the solution than is described here.

Classes
The Pizza class has a name, an array of toppings and a price.

The Stock class has an array of toppings. When a pizza is made, the amount of the relevant
topping is decremented.

The Factory class has an array that contains the three types of pizza; these three objects
provide a specification for each type of pizza. It has a method that receives the name of the pizza
as a string, and makes a pizza of that type. After a pizza has been made, it is placed in a special
location so the person that took the order can pick it up and give it to the customer. Here is an
outline of the class showing the key code:

class Factory
{ private Stock stock;
private Pizza[] pizzas = new Pizza[3];
private Pizza made;

public Factory()
{ create and store the three types of pizza }

The key insight is that the toppings are in one object (stock) and are put on another object
(a pizza) by the factory, so the factory points to (and uses) suppliers of both types; class Pizza
does not refer to class Stock directly.

public void make(String name)

{ made = pizza(pizza(name)); }

private Pizza pizza(Pizza spec)

{ Pizza pizza = new Pizza(spec);
for (String top: spec.tops())
{ stock.sub(top);
pizza.add(top); }
return pizza; }

public Pizza made()

{ return made; }

List of names
Each name is followed by a comma, except the last one.
private String names()
{ String s = "";
for (String name: names)
s += name() + ", ";
return s.substring(0, s.length() - 2); }

7 of 8
Construction order
I use a bottom-up coding order so I can test my code immediately after I have written it. I
write the supplier code and then hack up a couple client commands to exercise the supplier. This
is the order I added code to my solution:

1. Create the stock; decrement it. Code toString.

2. Define and create a single pizza. Code toString.
3. Get an order for a single pizza (no customer name).
4. Add the loop for multiple pizzas. Code toString.
5. Add the customer records. Code toString.
6. Write the menu system, with just one choice: order.
7. Add the other menu choices.
8. Add validation.
9. Add cash.
10. Tweak the IO to get it right.

You may prefer to start by coding the menu; the problem is that you then have to add
dummy code (empty methods) to test that your menu works. Also, you know how to code a
menu; the code was given in the lectures. Coding a menu is not a design issue. Coding the menu
first gives you no help in designing the less obvious parts and may even get in the way; you may
lock in design decisions without thinking about them first.

8 of 8