Automated Restaurant System (Command Design Pattern)PROBLEMY.docx

Automated Restaurant System (Command Design Pattern)
PROBLEM
You are to implement an automated restaurant system utilizing
the Command design pattern, minimally consisting of the
following three commands. You will then extend this basic
system in any way that you choose to demonstrate the use of
additional design patterns.
· Display menu
· Submit Order
· Display tab
SCENARIO (of the basic system)
In the basic system, we assume that all orders are from the same
table (i.e., there is only one table in the restaurant). Therefore,
a tab is generated by simply totaling all of the ordered items,
and tabs are not stored.
The menu of the basic system will consist of just main entrees.
It will not include appetizers, desserts, drinks, etc. The
information for each entrée will just be the name of the dish
("Roast Beef", "Chicken Korma", "Jiaozi", etc.) and the price.
APPROACH
You should implement the Command design pattern. This
includes the following:
· Text-based user interface
· SystemInterface class
· Invoker class
classes of the Command design pattern
· Command interface
· Command classes (one for each command)

· Aggregator class
· Menu class
· MenuItem Class
· Orders class
· OrderItem Class
· Tab class
The user interface should just be a text-based numbered list of
options, implemented in the main method. (It can be a GUI if
you desire and are familiar with the development of GUIs, but
no extra points will be given for this).
The SystemInterface can be a class of all static methods – one
for each of the three commands of the user interface, if it does
not have any state in your extension of the program.
The Aggregator class maintains references to the Menu object
and the Orders object. It should provide a getter method for
retrieving the Menu and Orders objects (no setters are needed).
The Menu and Orders classes store a collection of MenuItem
and OrderItem objects, respectively. A MenuItem object will
store the menu item #, the description, and its cost. An
OrderItem object will store an order by its item number only
(not its description).
The Invoker class has methods cooresponding to the methods of
the system interface. Each method simply creates a Command
object of the appropriate Command class (constructed with a
reference to the Aggregator object), calls its execute method,
and returns the results (as a single object) back to the system
interface. (Execute methods should not be passed any parameter
values - any values needed are passed to the constructor.)
A tab will be constructed from the Tab class containing all of
the ordered items, returned as an array of strings for the user
interface to display. Note that a tab needs information from both

the Menu and the Orders objects. (The Orders object indicates
what menu items were ordered, and the Menu class has the
description of each item to include in the Tab.)
EXTENSION OF THE BASIC SYSTEM
You are to extend the design and capabilitities of the program in
any ways that you wish. While the design may certainly call for
the use of design patterns already used in the assignments this
semester (i.e. Iterator, Factory, Strategy, and Decorator), the
intent is to demonstrate the significant and appropriate use of
design patterns not worked on in these assignments.
Following are some ideas on how the system may be extended:
· Capability of maintaining orders (and tabs) for multiple tables.
· Capability of maintaining a queue of waiting groups of
different size to be seated, and
automatically seated as people leave tables (triggered when tab
paid).
· Capability of maintaining an inventory of items (tomatoes,
etc.) and their depletion as
orders are prepared, which may have various effects (e.g., what
is offered on the menu,
the price of certain items, the options offered for certain items)
· Capability of "dynamic pricing" in which menu items change
price based on factors such as
how well certain items is selling.
· Capability of generating various reports (sales, inventory,
etc.)
· Capability of manager adjusting a given table's tab based on
some factors.
· Anything else you can think of!

1
– Implementing the Decorator Design Pattern
(with Strategy Pattern)
PROBLEM
You are to design and implement code based on the Decorator
pattern for generating an appropriate receipt for a customer
buying items at a particular Best Buy store. The general format
of a receipt is as follows:
Basic Receipt
Store Header (store street address, phone number, state
code, store number)
Date of Sale
Itemized Purchases
Total Sale (without sales tax)
Amount Due (with added sales tax)
Dynamically-Added Items
Tax Computation object (based on state residing in)
Optional Secondary Headers (“Greetings”), e.g.,
- “Happy Holidays from Best Buy”
- “Summer Sales are Hot at Best Buy”
Relevant Rebate Forms (to be printed at the end of
the receipt)
Promotional Coupons (e.g., “10% off next purchase”)
APPROACH
We will assume that the code is written as part of the software
used by all Best Buy stores around the country. Therefore, the
information in the Store Header will vary depending on the
particular store's location. In addition, the amount of sales tax
(if any) is determined by the state that the store resides in. The
calculation of tax will be implemented by use of the Strategy

pattern. The added items to be displayed on each receipt will be
handled by use of the Decorator pattern.
Basic Receipt
The information for the basic receipt should be stored in a
BasicReceipt object (see below). The instance variables of a
BasicReceipt should contain the date of sale, a PurchasedItems
object, the total sale (without tax) and amount due (with added
tax), each of type float. In addition, following the Strategy
design pattern, there should be an instance variable of
(interface) type TaxComputation that can be assigned the
appropriate tax computation object (e.g., MDTaxComputation)
for the state that the store resides in.
Determining Sales Tax
We will implement the classes so that the receipts can be
generated for one of four possible store locations, each in a
different state: Texas (6% sales tax), California (7.5%),
Massachusetts (6.25%), and Delaware (no sales tax). Note the
following “sales tax holidays” of individual states:
Texas
Has a sales tax holiday, but does not include computers or
computer accessories.
California
No sales tax holidays.
Massachusetts
For the benefit of back-to-school shoppers, there is a sales tax
holiday on the second weekend in August (for two days) which
includes school supplies, computers, sports equipment, and
health and beauty aids. The tax-free days on these items for
2016 will be August 13th and 14th.
The determination of sales tax is not just based on the tax rate
and purchase amount, but also on the purchase date (because of
the possible existence of tax holidays). That is why the method

of tax computation is contained in a TaxComputation object by
use of the Strategy pattern. (If there is no applicable sales tax,
e.g., in Delaware, then the TaxComputation variable is set to
null.) If an item is returned to a store in a different state from
which the item was purchased in, the Receipt object retrieved
from the system will have associated with it the
TaxComputation object for the state that the items were
purchased.
Adding Additional Receipt Items
There are a number of different “add on” items that may need to
be printed with the basic receipt.
During particular times of the year, a receipt header may begin
with a special greeting (e.g., “Happy Holidays from Best Buy”),
called a secondary header, to be added to the top of a receipt. In
addition, rebate forms may be printed at the end of a receipt if a
purchased item has a mail-in rebate. Finally, coupons may be
printed (also at the end of a receipt) if the total purchases
exceeds a certain dollar amount (e.g., if spend over $100, get a
10% off coupon for the next visit).
Objects of interface type AddOn are used to store the added
printout for a receipt. The interface has two methods - applies
(which is passed a PurchasedItems object containing all of the
items for the current receipt), and getLines (which returns the
added lines of text to be printed as a single String with
embedded newline characters). For AddOn objects of type
SecondaryHeader, applies always returns true. This is because if
a SecondaryHeader exists, it is always added to the (top) of the
receipt. Since rebates only apply to a specific item, method
applies returns true if and only if the particular item is found in
PurchasedItems. A similar approach is taken for adding coupons
to the end of a receipt, except that coupons apply if and only if
the customer has spent over a certain amount.

We assume that each Best Buy store downloads the current set
of decorator objects each morning.
Configuration File
A configuration file will be read by the program at start up, to
configure the system for the particular store location, containing
the following information: store street address, store phone
number, store number, and state code.
Factory Class
You must utilize a factory class to properly construct Best Buy
receipts based on the information read from the configuration
file, and the particular items purchased.
A UML class diagram for the design of this program is given
below.
Interfaces and Classes To Utilize
Following are the interface and classes to be used in the design
of the program.
Interfaces
public interface Receipt { // type of all receipt components
(i.e., BasicReceipt and receipt decorators)
public void prtReceipt();
}
public interface AddOn { // the type of added info to a
BasicReceipt (e.g., greetings, rebates, coupons)
public boolean applies(PurchasedItems items);
public String getLines();
}

public interface SecondaryHeading { // marker interface, i.e.,
nothing to implement
}
public interface Rebate { // marker interface, i.e., nothing to
implement
}
public interface Coupon { // marker interface, i.e., nothing to
implement
}
Abstract Classes
public abstract class Decorator implements Receipt {
private Receipt trailer;
public Decorator(Receipt r) {
trailer = r;
}
protected void callTrailer() {
trailer.prtReceipt();
}
public abstract void prtReceipt();
}
public abstract class TaxComputation {
public abstract double computeTax(PurchasedItems items,
ReceiptDate date);
protected abstract boolean taxHoliday();
}

StoreItem Class
public class StoreItem {
private String itemCode; // e.g., 3010
private String itemDescription; // e.g., Dell Laptop
private String itemPrice;
public StoreItem(String code, String descript, String price)
{ ... }
// appropriate getters and setters
}
PurchasedItems Class
public class PurchasedItems {
private ArrayList<StoreItem> items;
public PurchasedItems() {
items = new ArrayList();
}
public void addItem(StoreItem item) { ... }
public double getTotalCost() { ... }
public boolean containsItem(String itemCode) { ... }
}
BasicReceipt Class
public class BasicReceipt implements Receipt {
private String storeInfo; // store number, store address,

phone number
private String stateCode; // MD, DE, CA or MA
private PurchasedItems items;
private Date date;
private TaxComputation tc;
public BasicReceipt(PurchasedItems items) {
this.items = items;
}
public void setTaxComputation(TaxComputation tc) {
this.tc = tc; }
public void setDate(String date) { this.date = date; }
public void prtReceipt() {
// to implement
}
}
AddOn Classes
Each of these classes are implemented to provide the
information for a particular secondary header, rebate or coupon.
The following are examples only of what these classes may be.
public class HolidayGreeting implements AddOn,
SecondaryHeading {
public boolean applies(PurchasedItems items) {
return true; // SecondaryHeading decorators always
applied
}
public String getLines() {
return “* Happy Holidays from Best Buy *”;

}
}
public class Rebate1406 implements AddOn, Rebate {
public boolean applies(PurchasedItems items) {
return items.containsItem(“1406”);
{
public String getLines() {
return “Mail-in Rebate for Item #1406n” +
“Name:n” + “Address:nn” +
“Mail to: Best Buy Rebates, P.O. Box 1400,
Orlando, FL”;
}
}
public class Coupon100Get10Percent implements AddOn,
Coupon { // similar to rebate class }
Decorator Classes
There are two decorator types - one for displaying text at the
top of a receipt (PreDecorator), and another for displaying
information at the bottom of a receipt (PostDecorator). Each is
constructed to contain an AddOn object, which provides the
added information to be displayed on the receipt.
public class PreDecorator extends Decorator {
private AddOn a;
public PreDecorator(AddOn a, Receipt r) {
super(r);
this.a = a;
}

public void prtReceipt() {
System.out.println(a.getLines());
callTrailer();
}
}
public class PostDecorator extends Decorator
// similar, except that prtReceipt print the add on information
// after the other parts of the receipt are printed
Tax Computation Classes
public class MDTaxComputation extends TaxComputation {
public double computeTax(PurchasedItems items,
ReceiptDate date) {
// calls private method taxHoliday as part of this
computation
}
private boolean taxHoliday(ReceiptDate date);
// returns true if date of receipt within the state’s tax
free holiday,
// else returns false. Supporting method of method
computeTax.
}
// tax computation objects for other states are similar (to be
completed)
Factory Class
public class ReceiptFactory {
String header; // contains line with “Best Buy”,
store_num, street_addr, phone

String state_code;
private TaxComputation[] taxComputationsObjs; // tax
computation objects (for each state)
private AddOn[] addOns; // secondary header, rebate and
coupon add-ons
public ReceiptFactory() { // constructor
// 1. Populates array of StateComputation objects and array
of AddOn objects (as if downloaded
from the BestBuy web site).
// 2. Reads config file to assign store_num, street_addr,
etc.
// 3. Based on the state code (e.g., “MD”, from the config
file) stores appropriate
StateComputation object to be used on all receipts.
}
public getReceipt(PurchasedItems items) {
// 1. Sets the current date of the BasicReceipt.
// 2. Attaches the StateComputation object to the
BasicReceipt (by call to the setComputation
method of BasicReceipt).
// 3. Traverses over all AddOn objects, calling the applies
method of each. If an AddOn object
applies, then determines if the AddOn is of type
SecondaryHeader, Rebate, or Coupon.
If of type SecondaryHeader, then creates a
PreDecorator for othe AddOn. If of type Rebate or
Coupon, then creates a PostDecorator.
// 4. Links in the decorator object based on the Decorator
design pattern.
// 5. Adds current date to
// 6. Returns decorated BasicReceipt object as type
Receipt.

}
}
CLIENT CODE
public static void main(String[] args)
{
// 1. Creates a PurchasedItems object.
// 2. Constructs ReceiptFactory object.
// 3. Prompts user for items to purchase, storing each in
PurchasedItems.
// 4. Calls the getReceipt method of the factory to obtain
constructed receipt.
// 5. Prints receipt by method call to constructed receipt.
// get receipt date
// (prompt user for current date)
// display all available products to user
(to be implemented)
// get all user selections
(to be implemented)
ReceiptFactory factory = new ReceiptFactory();
Receipt receipt = factory.getReceipt(items, date);
receipt.prtReceipt();
}
PROGRAM TO CREATE
Create a program that will create of and display Best Buy
receipts. The program should provide a main menu as in the
following,
1 – Start New Receipt
2 – Add Items

3 – Display Receipt
Vary the AddOn objects stored in the ReceiptFactory to check
that the factory builds the correct receipts for various situations
(e.g., in which only a BasicReceipt is created; in which a
Greeting AddOn exists; and in which various combinations of
Coupon and Rebate AddOns exist).
4
PROJECT – Implementing an Online Shopping System
with Use of the Decorator, Strategy, and Command Patterns
(and more!)
PROBLEM
You are to design and implement an Amazon.com-like online
shopping system. You may include actual features of Amazon
(e.g., Prime customers), or you may include your own features.
The capabilities of the system MUST INCLUDE the following:
· generation of a receipt of some kind for all of the orders
placed, and the
inclusion of items on the receipt that are a result of the
particular items
purchased (by use of the Decorator design pattern).
· the use of the Command design pattern for implementation of
the
overall command-driven aspect of the system.
· the use of the Strategy design pattern for any part of the
system the
demonstrates its appropriate use
In addition, utilize any other design patterns that can be
appropriately applied. Be creative in the features supported by

the inclusion of such design patterns. For example, the
Decorator design pattern can be used for any situation in which
there are various combinations of behavior that cannot be
determined until runtime (not just the printing of a receipt). For
example, the total amount of an order may utilimately be based
on (a) the items ordered, (b) the shipping option selected, (c)
whether a preferred ("prime") customer or not, (d) whether you
have any credit from previous purchases/returns, (e) whether
you are purchasing items that are currently on sale, (f) whether
the purchase of a given item gives you a free associated item,
etc. The same is true of the Strategy pattern, it can be used in
any situation in which a section of code (algorithm) can vary,
and especially if it can be judged that it may vary in the future.
DECORATOR AND COMMAND PATTERN MATERIALS
Materials are provided giving details on the design and example
use of the Decorator pattern (from a previous Best Buy
assignment(Decorator)) and the Command pattern (from a
previous automated restaurant system assignment(Restaurant)).
These should be used for studying the details of the GENERAL
use of these patterns.
System Interface / User Interface
Your system must be designed with the use of a system
interface class, as demonstrated in the automated restaurant
system assignment. The methods of the system interface must
only return values of type String for a separate user interface to
call .The user interface may be text-based, or a GUI interface.
WHAT TO SUBMIT
Please submit one pdf document along with your code. (Export
all class diagrams to pdf. Do not submit file formats of the
particular UML drawing tool used.) and also Your code
separately. Your submission should include,

· A use case diagram of your system. There is no set number of
use cases to include - that will vary based on the particular
system designing. Include an explanation of each use case.
(Scenarios do not need to be provided.)
· The class diagram for your system. Make sure to include all of
the classes and interfaces. The class diagram should include the
relationships of association, composition, aggregation,
generalization (inheritance), and dependency where they exist;
notation of multiplicity, navigation, and role names where
appropriate; and the inclusion of the methods within each class,
including access modifiers (public, protected, private),
parameters, and return type (instance variables do not need to
be included).
· Discussion of the use of each design pattern within your
design, including
· why you made the decision to incorporate the use of the
pattern
· the benefits of the included pattern
· what specific aspects of the system can be easily modified as a
result of the use of design patterns in the design
· Program code, with sufficient in-code documentation
· List of commands the system provides, with a brief
explanation of each
1

Automated Restaurant System (Command Design Pattern)PROBLEMY.docx

More Related Content

Similar to Automated Restaurant System (Command Design Pattern)PROBLEMY.docx (20)

More from rock73 (20)

Recently uploaded (20)

Automated Restaurant System (Command Design Pattern)PROBLEMY.docx