31244 Applications Programming 48024 Object Oriented Design Assignment 1: Za pizza Due date: Monday 6 September, 6:00 pm Topics: Standard patterns, OO design Objectives: This assignment supports subject objectives 1 and 2.
1.
Value: 20%
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
[email protected] 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. 1.
Log into your home account; your home account has your student id as the login name. 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 Show the Za 5 Show the choices
10 10 5
Ordering Show the customer records Show the types
12.3 Good design (50) 5 Classes 10 Class encapsulation 10 Functions
10 10 5
Attributes Small methods Good names
12.4 Penalties Spoof correctness Spoof style Empty methods Unused code
0 marks (correctness) for that part -10 (style) each occurrence -1 (style) for each empty method -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. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Create the stock; decrement it. Code toString. Define and create a single pizza. Code toString. Get an order for a single pizza (no customer name). Add the loop for multiple pizzas. Code toString. Add the customer records. Code toString. Write the menu system, with just one choice: order. Add the other menu choices. Add validation. Add cash. 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
