Scrigroup - Documente si articole

Username / Parola inexistente      

Home Documente Upload Resurse Alte limbi doc  


ComunicareMarketingProtectia munciiResurse umane


On-line Restaurant Ordering

Marketing

+ Font mai mare | - Font mai mic



On-line Restaurant Ordering




Problem Statement 5

Business Model 7

Business Actors 7

Business Scenarios 7

Browse the Menu 7

Place the Order 7

Process the Order 7

Pay by Credit Card 7

Review the Restaurant 7

Configure the System 8

Business Use Cases and Activity Diagrams for the Business Process 8

Browse the Menu 8

Place the Order 9

Process the Order 9

Browse the Menu & Place the Order & Process the Order 10

Pay by Credit Card 11

Review the Restaurant 12

Configure the System 13

Business Object Diagram 13

Domain Model – adding attributes 15

Position of the Application in the Business. Context Diagram. 16

Requirements Analysis Model 17

Actor Descriptions (Concerns and Responsibilities) 17

Client 17

Waiter 17

Kitchen 17

CCA 17

Administrator 17

System Event List 18

F1. The Interaction with the Client 18

F2. The Interaction with the Kitchen 18

F3. The Interaction with the Waiter 18

F4. The Interaction with CCA 18

F5. The Interaction with Administrator 18

F6. The Running Function 19

Attributes of the System 19

Software Use Cases (Use Case Diagram and Description) 19

Browse the Menu 19

Place the Order 21

Process the Order 21

Pay by Credit Card 22

Review the Restaurant 24

Configure the System 24

System Sequence Diagram 25

Browse the Menu 25

Browse the Menu – adding software classes 26

Place the Order 26

Place the Order – adding software classes 27

Process the Order 27

Process the Order – adding software classes 28

Pay by Credit Card 28

Pay by Credit Card – adding software classes 29

Review the Restaurant 30

Review the Restaurant – adding software classes 31

Configure the System 32

Configure the System – adding software classes 33

Design Model 34

Responsibility Assignment to Classes 34

System Initialization 34

Browse the Menu 34

Place the Order 36

Process the Order 38

Pay by Credit Card 39

Review the Restaurant 42

Configure the System 43

Interaction Diagrams – Collaboration Diagrams 44

Browse the Menu 44

Place the Order 45

Process the Order 45

Pay by Credit Card 46

Review the Restaurant 46

Configure the System 47

Design Class Diagram 47

Design Pattern Identification 47

Delegation 47

Marker Interface 49

Proxy 50

Factory Method 50

Singleton 52

Façade 54

Adapter 55

Model-View-Controller 55

State Diagrams for Business Objects with Non-trivial Life Cycle 56

Order 56

Bill 57

Architecture Document – Package Diagram 58

Nested packages Diagram 58

Package Diagram 59

Architecture Document - Class cohesion inside packages 59

cca 59

restaurant.main 60

restaurant.repository 61

restaurant.util 62

restaurant.menu 63

restaurant.remote 64

restaurant.view 65

restaurant.review 68

restaurant.client 68

restaurant.order 69

restaurant.payment 70

restaurant.configuration 71

Running the application 73

Instalation 73

Running 73

Problem Statement

The restaurant of the Rex hotel become increasingly busy, waiters and waitresses are finding themselves with having to reduce the level of customer service in order to balance their higher volume of customers. In addition, there is much inefficiency involved with the standard order taking processes. This inefficiency is due to the existence of the following causes:

- Waiters and waitresses handwrite orders and walk the orders to the kitchen

- Waiters must make constant trips to the kitchen in order to check the status of an order

- Waiter handwriting can be misinterpreted by kitchen staff

- Orders can be misplaced or overlooked by kitchen staff

- Waiters become stressed due to high level of multitasking due to having to simultaneously serve multiple customers

- Credit cards are taken away from customers view, creating a potential security hazard

- Customers often have to wait long periods before being fed due to the above inefficiencies

The owner of the restaurant believes that it is time to replace the archaic use of paper and pencil with the technologies that are currently available. In order to do this, the owner decided to buy a software application that will automate many tasks that waiters and waitresses must perform.

The software system will be installed in a network and run on the thin clients that will stay on the tables from the restaurant.

The system will have a GUI which provides the following list of application features that will greatly reduce the inefficiencies describe above:

A. GUI will provide a mapping of all the restaurant tables.

1. By clicking on a specific table that a waiter/waitress is currently servicing, the customer can send an order to the kitchen wireless.

2. Orders will be placed by clicking on food items displayed on a menu that is integrated into application

If a menu item becomes unavailable, the menu item will become grayed-out to indicate its unavailability to the customer.

The customer will be able to access nutritional information for items on the menu.

The system will have a feature that will make updating the menu simple and easy in order to accommodate to the daily specials of the restaurant.

3. The GUI table representation (perhaps a simple square) will be color-coded to indicate the status of the table’s order (i.e. when it becomes green, the waiter will know that the order is ready).

4. When a certain time interval has passed in which a waiter has not visited a table, the GUI representation of that table will blink in order to remind the waiter to check on that table.

B. GUI will have the capability to process a credit card payment at the table. The customer will input the credit card number and the system will verify the card validity with the help from a credit card authorization (CCA). If the credit card is OK, the system will request to the CCA to perform the payment of consumption. In addition, GUI will support this feature by having a print option that will print out a detailed receipt.

C. GUI will have a notepad feature, which allows customers to make personal notes as well send notes to the kitchen in order to place customized orders. For instance, at the end of the meal the customers may use the notepad feature of the system in order to fill out general restaurant surveys as well as specific reviews on the meals ordered. These would prove beneficial to both the restaurant and to future customers. This information would be stored in a repository for access at ordering time for other diners.

Business Model

Business Actors

They are Actors in the business environment.

Client

CCA

Kitchen

Waiter

Administrator

Business Scenarios

They represent a sequence of actions and interactions between business actors and the system

Browse the Menu

1. Client asks to see the menu

2. System offers the menu to the Client

3. Client browses through the menu and chooses his today order

Place the Order

1. Client asks to place an order

2. System briefs to the Client his selected plates

3. Client can update his order

4. Order is placed to the Kitchen

Process the Order

1. Kitchen receives the order



2. Kitchen prepares each menu item on the order

3. When every menu item is ready the Waiter serves the meal to the client

Pay by Credit Card

1. Client asks to pay by credit card

2. System offers the Client the facility where to enter his personal credit card data

3. Client enters personal information

4. System forwards the payment details to CCA

5. System prints the receipt of the operation

Review the Restaurant

1. Client asks to write a review of his experience in the restaurant

2. System offers the Client the facility where to enter his review

3. System saves any review filled in by the Client

Configure the System

1. Administrator asks to update the menu

2. System offers the Administrator the facility where to enter his modifications

3. System saves any modification made by the Administrator

Business Use Cases and Activity Diagrams for the Business Process

describe a sequence of actions of a business as a whole to fulfill a goal of a business actor

Browse the Menu

Place the Order

Process the Order

Browse the Menu & Place the Order & Process the Order

Pay by Credit Card

Review the Restaurant

Configure the System

Business Object Diagram

The Domain Model illustrates the meaningful conceptual classes in the problem domain.

Candidate conceptual classes:

terminal

table

restaurant

waiter

client

order

kitchen

menu

menu item

credit card

bill

CCA

receipt

review

administrator

Domain Model – adding attributes

Position of the Application in the Business. Context Diagram.

Requirements Analysis Model

Actor Descriptions (Concerns and Responsibilities)

Client – extern ( => Actor)

Interests:

to serve a good meal

to be served on-time

to be served according to his special requests on the menu items

Responsibilities:

to have the amount of cash to pay his bill or to carry a valid credit card

to be hungry

Waiter – intern ( => Agent)

Interests:

to serve in a restaurant with good reviews from the clients

Responsibilities:

to help the client to use the terminals on the tables

to check on his clients within a specified interval of time

to serve the order to the table

Kitchen – intern ( => Agent)

Interests:

to receive good reviews from the clients

Responsibilities:

to know how to cook each menu item

to prepare each menu item in a reasonable amount of time

CCA – extern ( => Actor)

Interests:

Responsibilities:

to check for credit card information in its database

to check the correctness of the credit card number/credit card pin-code pair

to perform a payment

to respond to any request in the lowest time possible

Administrator – intern ( => Agent)

Interests:

to work in a fashionable restaurant

to perform his duties with help from an easy to use interface

Responsibilities:

to update the menu items and specials of the day

to update the nutritional information

to update the prices and stock

System Event List

F1. The Interaction with the Client

The System displays the menu to the Client

The System displays nutritional information of a menu item to the Client

The System marks as unavailable the menu items whose stock ended

The System checks the Client’s order

The System displays the order synopsis to the Client

The System displays the CC payment page to the Client

The System receives the CC number from the Client

The System receives the CC pin-code number from the Client

The System displays the consumption bill to the Client

The System prints a receipt of the payment for the Client

The System displays the review page to the Client

The System saves the Client review

The System displays restaurant/menu item review to the Client

F2. The Interaction with the Kitchen

2.1 The System sends the order to the Kitchen

2.2 The System receives confirmation of a cooked ordered menu item from the Kitchen

F3. The Interaction with the Waiter

3.1 The System notifies the Waiter that a certain time interval has passed since he last visited his table

3.2 The System notifies the Waiter that a Client has ordered from one of his tables

3.3 The System notifies the Waiter that the order from the Client is prepared and must be served at the table

F4. The Interaction with CCA

4.1 The System sends Client and CC data to CCA

4.2 The System receives from CCA the correctness of sent Client data

4.3 The System asks CCA to perform the payment for the Client

F5. The Interaction with Administrator

5.1 The System displays the authentication page to the Administrator

5.2 The System authenticates the Administrator

5.3 The System displays the configuration page to the Administrator

5.4 The System saves the modifications made by the Administrator

F6. The Running Function

6.1 System checks when the entire Client order is cooked

6.2 System checks when a certain time interval has passed since the Waiter last visited his tables

6.3 System checks when a menu item becomes unavailable for further ordering

6.4 System updates stock quantities

Attributes of the System

placed order color: red

cooked order color: green

initial table color in the table mapping representation: yellow

unavailable menu item: gray

waiter notification timeout: 10 minutes

Software Use Cases (Use Case Diagram and Description)

Browse the Menu

Primary Actor: Client

Stakeholders: -

Preconditions:

the Client must be sited at one of the restaurant tables

the System displays on the terminal of each table the table mapping representation, with yellow color for corresponding table

Post-conditions:

the Client knows the menu

the Client fills in quantities for the menu items he wants to order

Trigger:

the Client presses his table (yellow color) in the table mapping representation

Cross-references from System Event List: 1.1, 1.2, 1.3, 1.13, 6.3

Main Flow:

The Client presses his table button in the table mapping representation

Alternative flow: A1

Alternative flow: A2

Alternative flow: A3

The System checks availability for all menu items and specials of the day

Exception flow: E1

The System displays the menu composed of menu items and specials of the day and having the no-more available menu items gray-colored.

The Client browses the menu items and the specials of the day

Alternative flow: A3

Alternative flow: A4

The Client fills in the quantities he wants to order for each desired menu item or specials of the day

Alternative Flows:

A1.

If there is an administrator logged in who performs modifications in the system configuration, the client is notified to wait until the administrator finishes his job

Return to main flow at step 1.



A2.

If the client has an order prepared which was not yet served at the table, pressing the button marks that the order is served by the waiter to the table

The table button in the table representation becomes yellow (waiting for a new menu request)

Return to main flow at step 1

A3.

If the client at the current table has an order which started to be processed in the kitchen but is not yet entirely prepared, pressing the button marks that the waiter visits his table

The system resets the timeout signaling the waiter to check his table every 10 minutes

The table button is colored in red (order being processed)

Return to main flow at step 1

A4.

The Client presses the request nutritional information button next to a menu item

The System collects all nutritional information about the menu item

The System displays the nutritional information page of the menu item

The Client reads the nutritional information for the menu item

Return to the main flow at step 5.

A5.

The Client presses the read reviews button on the menu interface

The System collects all reviews

The System displays the reviews

The Client reads the reviews

Return to the main flow at step 5.

Exception flows:

E1.

The Systems finds that there are no menu items in stock

The System displays an error message

The flow ends.

Place the Order

Primary Actor: Client

Stakeholders: Kitchen, Waiter

Preconditions:

the Client must have filled in at least one quantity for one of the available menu items or the specials of the day

Post-conditions:

the Order is placed to the Kitchen and starts being processed

the Waiter is notified that a new order was placed from one of his tables

Trigger:

the Client presses the order button

Cross-references from System Event List: 1.4, 1.5, 2.1, 3.2, 6.4

Main Flow:

The Client presses the order button

The System checks entered quantities against stock quantities

A1

The System reserves the quantities for the Client order

The System displays a synopsis page of the Client order

A2

The Client fills in any custom note about his order

The Client confirms the order

The order is placed on the Kitchen’s cooking queue

The Waiter is notified by marking red the table button

The System updates the stock/reserved quantities

The System starts the timeout that will visually notify the waiter to check his table if more than 10 minutes elapsed

The System automatically adjusts any menu interfaces that were currently browsed by other clients, modifying quantities

Alternative Flows:

A1.

System finds that some of the ordered quantities are exceeding available stock

System automatically modifies ordered quantities to available stock

The flow returns to main flow at step 4.

A2.

The Client infirm the order

The system releases the quantities for the Client order

Return to main flow at step 1.

Process the Order

Primary Actor: Kitchen

Stakeholders: Waiter

Preconditions:

the Kitchen received a new order in the processing queue

Post-conditions:

the order is served to the Client

Trigger:

System places a new order in the Kitchen’s queue

Cross-references from System Event List: 2.1, 2.2, 3.1, 3.3, 6.1, 6.2

Main Flow:

The System places a new order in the Kitchen’s processing queue

A1

The Kitchen cooks a menu item

The System checks if the entire order is ready

A2

The System notifies the Waiter that the order is ready to be served by marking green the table representation on the table mapping representation

The System removes the order from the Kitchen’s cooking queue

The System stops any timeout interval check for the current table

The Waiter serves the order to the Client

The Waiter marks that he served the order by pressing the table button

The table button in the table mapping representation is colored yellow

The Client starts eating

Alternative Flows:

A1.

The timeout until the Waiter must re-check on his table elapses.

The System notifies the Waiter that he must visit his table by blinking the table button color on the table mapping representation

The Waiter visits the table and marks it visited by pressing the table button

The System resets the timeout

A2.

The System finds that not all ordered menu items were cooked/prepared

Return to main flow at step 3.

Pay by Credit Card

Primary Actor: Client

Stakeholders: CCA

Preconditions:

the Client has a unpaid bill for his order

Post-conditions:

the payment is recorded to CCA

the Client receives a receipt of the payment

Trigger:

The Client presses on pay my bill button

Cross-references from System Event List: 1.6, 1.7, 1.8, 1.9, 1.10, 4.1, 4.2, 4.3

Main Flow:

The Client presses on the pay my bill button

The System checks connection with CCA

E1

The System displays the bill to the Client

A1

A2

The Client confirms his bill by pressing the button to pay with credit card

The System asks for cc number

The Client enters his cc number

The System forwards the cc number to CCA

A3

CCA accepts cc number

The System asks for pin-code

The Client enters pin-code

The System forwards the pin-code to CCA

A4

CCA accepts pin-code

The System prints a receipt

The System asks CCA to record the payment

The System marks the bill as paid

Alternative Flows:

A1.

The Client infirm his bill

Return to main flow at step 1.

A2.

The Client asks to pay cash

The Waiter is notified that the Client wants to pay cash

The bill is marked as paid

A3.

CCA does not accept the cc number

The System displays an error message

Return to main flow at step 8.

A4.

CCA does not accept the pin-code

The System displays an error message

Return to main flow at step 13.

Exception Flows:

E1.

The connection with CCA cannot be established

The client is informed that he must pay by cash his bill

The System displays an error message

The flow ends

Review the Restaurant

Primary Actor: Client

Stakeholders: -

Preconditions:

the System must be up and running

Post-conditions:

the Client review is saved for later checking by other diners

Trigger:

the Client presses on the make a review button

Cross-references from System Event List: 1.11, 1.12

Main flow:

The Client presses the make a review button

The System displays the review enter page

The Client fills in the review and presses save button

The System saves the review in the repository

The System updates the reviews information that are being held as a resource for later browsing by clients

The System updates all reviews interfaces currently being browsed by clients

Configure the System

Primary Actor: Administrator



Stakeholders: -

Preconditions:

the Administrator knows his authentication data

Post-conditions:

information about admin authentication details, product categories and product details are being updated

Trigger:

the Administrator presses the configure button

Cross-references from System Event List: 5.1, 5.2, 5.3, 5.4, 6.4

Main flow:

The Administrator presses the configure button

A1

The System displays the authentication page

The Administrator fills in his authentication data

A2

The System displays the configure page

The Administrator modifies/updates information regarding administrators, product categories and product details. Some checks are always being made: there must always be at least one administrator, product category names and product names have to be unique

The System saves the data entered by the Administrator

The System refreshes the product descriptions information that was being held as a resource for displaying menu interfaces to clients

Alternative flows:

A1.

There are still clients that are in the middle of the processing order

The System displays a notify to the administrator asking him to wait until all clients ended their interaction with the system

The flow goes back to step 1

A2.

The System does not accept the entered authentication data

The System displays an error message

Return to main flow at step 4.

System Sequence Diagram

Browse the Menu

Browse the Menu – adding software classes

Place the Order

Place the Order – adding software classes

Process the Order

Process the Order – adding software classes

Pay by Credit Card

Pay by Credit Card – adding software classes

Review the Restaurant

Review the Restaurant – adding software classes

Configure the System

Configure the System – adding software classes

Design Model

Responsibility Assignment to Classes

System Initialization

Browse the Menu

Place the Order

Process the Order

Pay by Credit Card

Review the Restaurant

Configure the System

Interaction Diagrams – Collaboration Diagrams

Browse the Menu

Place the Order

Process the Order

Pay by Credit Card

Review the Restaurant

Configure the System

Design Class Diagram

Design Pattern Identification

Delegation

Marker Interface

- all classes that are transported over the network between actors and the system must be of Serializable type – this describes Marker Interface pattern. Some of them will automatically be of Serializable type by extending classes of Serializable type (for instance, GUI classes that extend JFrame)

Proxy

- class MenuManager acts as a Virtual Proxy for ProductDescription – initializes them only once and when needed, afterwards handles every request to any ProductDescription

Factory Method

Singleton

- all Singleton implementations will use the following lazy-loaded solution:

public class Singleton

private static class SingletonHolder

public static Singleton getInstance()

Façade

- DbManager acts as a Façade that provides a simpler interface to the logic needed for executing SQL queries into the database

Adapter

- RepositoryManager acts as an Adapter that wraps the logic of interaction with DbManager (which provides convenient methods for executing SQL queries) to an easy-to-use interface for the entire system

Model-View-Controller

- the entire system is based on the MVC architectural pattern. The View is represented by all GUI classes. The Controller consists in following Manager classes: MenuManager, OrderManager, PaymentManager, ReviewManager, ConfigurationManager. The Model is represented by all other classes (except actors) and encapsulates a data access layer to the persistent storage mechanism (database).

State Diagrams for Business Objects with Non-trivial Life Cycle

Order

Bill

Architecture Document – Package Diagram

Nested packages Diagram

Package Diagram

Architecture Document - Class cohesion inside packages

cca

- this package acts as a simulator of the real CCA system. It contains the CCA class, which implements restaurant.remote.CCARemote interface, which is the public interface of the CCA system for the restaurant

restaurant.main

- this package contains the classes needed to initialize the restaurant: Restaurant, Kitchen, Waiter, Table, Terminal. The Kitchen defines an internal class KitchenProcessOrderThread which will later be used to process an order placed by a client. The Waiter class defines an internal class WaiterTimeoutThread which will later be used to remind a waiter to check on his table after a client placed an order. The Main class is responsible for initializing the entire system.

restaurant.repository

- this package contains the logic for accessing the repository information (in our example, the MySQL database instance). It is part of the Model component in the Model-View-Controller pattern. The package has a manager class RepositoryManager which handles all requests to the repository from the system. It uses DbManager to perform mysql queries in the database. Both classes implement the Singleton lazy-loading pattern earlier described. RepositoryManager defines an internal class Queries which holds all the queries that are executed through DbManager in the database instance.

restaurant.util

- contains useful classes that are independently used by other classes in the system, and have no connection to the restaurant as a system. GUIUtil defines some common methods for laying out interfaces. RegExp contains regular expressions formats. ErrorCallbackInterface is an interface that can be implemented by any class that wants to act as an error catcher for some operations.

restaurant.menu

- contains all the classes needed to realize the Browse the Menu use case. ProductDescription is a class enclosing all information of a product from the repository and provides methods for reserving/releasing quantities for a client order. The Menu is composed of MenuItems which reference ProductDescriptions and catches events from the client regarding the menu and sends them to the MenuManager. The MenuManager is the controller for the Browse the Menu use case and handles all requests for a Menu and MenuItems. MenuManager and Menu both implement the lazy-loading Singleton pattern.

restaurant.remote

because the system is intended to run in a physically distributed environment, here are all remote interfaces that are to be implemented by real classes in the system so that their objects to become network accessible between remote parts of the system. Each remote interface acts as a stub for the real object in the system/remote system. Since different parts of the system must communicate using common system objects, and since those objects may reside in different name spaces (why not, different machines), this interfaces help declaring previously known public interfaces for the objects that are to be shared between different parts of the system. As seen by me, the system may be distributed as following: the terminals that are on each table (so all the information that need to be used by/retrieved from the thin clients running on the terminals must make use of such remote interfaces for the necessary objects), the CCA system which is on a different machine (a different building, company etc, so all communication to/from CCA must use a remote interface of the CCA system which is defined and declared by CCA and known by the restaurant system, and, moreover, all information sent to CCA must use remote interfaces that need to be known by CCA too) , and the main system. So all information that need to be shared between terminals and the main system, and between CCA and the main system need to be publicly known by both parts interested in the communication. This is the role of the xxxRemote interfaces defined in this package. ClientRemote (stub for Client) is needed because the client is sited at one of the restaurant tables, using a terminal that is network-accessible by the system, and the restaurant must know of a way of sending him necessary data. TerminalRemote is used for associating clients to terminals (simulation of a client who sits at a table and starts using the terminal on the table). MenuRemote and MenuItemRemote are used for displaying menu information to the client. MenuRemote is also used to catch all events sent by the client regarding the menu. OrderRemote and OrderedMenuItemRemote are used to display order information to the client. OrderRemote is also used to catch all evens sent by the client regarding his order. BillRemote is used to display bill information to the client and to catch client events regarding the bill. CCARemote is the interface for the CCA system that is used by the restaurant. PaymentRemote and CreditCardDataRemote represent information that is sent to CCA system when performing a payment/checking some credit card data validity.

restaurant.view

- this is the View component in the Model-View-Controller architecture pattern. Here are defined all graphical interfaces that are displayed by the system. All interfaces that are to be displayed on the remote terminals are to be network-accessible, and this is achieved by extending JFrame (which is a Serializable type (see Marker Interface pattern described earlier) and by using remote interfaces of real objects: TableRepresentationGUI (displays the table representation mapping with the current table button marked yellow), MenuGUI (displays the menu interface), OrderGUI (displays the order interface), BillGUI (displays the bill interface), CreditCardGUI (displays the credit card interface), ReviewGUI (used when writing a review), ReviewsGUI (used to read saved reviews). TableRepresentationGUI also defines an internal class BlinkingThread that will be used when the table button will start blinking to notify that the waiter timeout elapsed. All other interfaces AdministrationGUI (displays the interface that allows the administrator to enter the Configure the System use case), ConfigurationGUI (interface allowing editing the configuration of the system) and AuthenticationGUI (admin authentication interface) are used for editing the system configuration. ConfigurationGUI also defines three internal classes IntegerEditor (used to restrict entering values in a table cell to an integer value), DoubleEditor (used to restrict entering values in a table cell to double value), and UniqueStringEditor (used to restrict entering unique per column values in a table).

restaurant.review

this package contains classes that are used for Review the Restaurant use case. ReviewManager is the controller of the use case and is responsible for displaying reviews to the clients, and to save new reviews into the repository. Review is the representation of a review from the repository. RepositoryManager implements the lazy-loading Singleton pattern

restaurant.client

- this package is a simulation of a real client that enters the restaurant and starts interacting with a terminal. It contains the Client that defines the client details, and is used by the restaurant to send data (graphical interfaces for instance) and to receive signals (of course, using the ClientRemote interface – see restaurant.remote description)

restaurant.order

this package contains classes that are used for Place the Orderd and also in the Process the Order use cases. OrderManager is responsible for receiving order requests from the clients, asking for confirmations, sending the orders to the kitchen, permanently checking if the orders are prepared, and notifying the waiters of order status changing and when they must check their tables if too much time has elapsed. OrderManager implements the lazy-loading Singleton pattern. The Order is composed of OrderedMenuItems and contains all information related to a client order, also catches all events from the client regarding his order, events that are delegated to the OrderManager.

restaurant.payment

- this package contains classes that are used in the Pay by Credit Card use case. PaymentManager is the controller of the class, and is responsible of getting credit card information from the client, communicating with CCA for validity of the client data, and for creating and printing the bill. PaymentManager implements the lazy-loaded singleton pattern. Bill contains all information regarding the bill for a client. Receipt is the class that prints the receipt of a payment information of a bill. CreditCardData is an object used in the communication with CCA to allow checking of credit card validity for a client. Payment is the information sent to CCA to perform a payment into the client account.

restaurant.configuration

- contains ConfigurationManager class which is the controller for the Configure the System use case. It implements the lazy-loaded Singleton pattern and is responsible for authenticating the administrator, building and displaying the interface with the configuration of the system, and for saving data into repository and refreshing modified data into the system.

Running the application

Instalation

the system must have installed a MySQL server instance (capable of transactions, supporting InnoDB tables), java sdk

install the database by running the queries inside online_restaurant.sql

change inside restaurant.properties DBHOST, DBNAME, DBUSER, DBPASS accordingly, to permit access to the database (mysql host, database name, mysql user, mysql password)

change (if necessary) in restaurant.properties the number of tables inside the restaurant (TABLENR), the number of waiters (WAITERNR) and the timeout in seconds for a waiter notification (WAITERTIMEOUT). The Restaurant will associate the waiters to the tables when initialized.

change (if wanted) in client.properties the names of the clients who will use the restaurant and their mapping to the restaurant tables. Please take care not to put invalid table numbers associated with the clients – must be different numbers lower than TABLENR from restaurant.properties. When Main starts initialization of the system, automatically associates the clients with the indicated tables. Each table that has no associated client, will not react to any user events.

change (if wanted) in cca.properties the data regarding client names and credit card numbers and pincodes. This information is used by CCA class (simulator of a real CCA system) to check for correctness of client credit card data. Please take care to put similar names as in client.properties for client names.

Running

- all classes are found in the classes folder

- all sources are found in the src folder

- a distribution jar named OnlinedRestaurant.jar is also present

- restaurant.main.Main is the main class of the project – initializes the restaurant, clients, cca, associates clients to restaurant tables/terminals.

- please include the mysql connector jar library inside lib folder in the classpath (the jdbc/odbc driver)

- you can use this command to execute from existing classes:

java –cp .;classes;libmysql-connector-java-5.1.5-bin.jar; restaurant.main.Main

- you can use this command to execute from distribution jar:

java -jar OnlineRestaurant.jar

- in the folder resources you will find this document, the associated Rational Rose .mdl file and the diagrams generated with Enterprise Architect

- when running, the system displays in the top left corner the admin button to administer the system (initial username & password: admin/password), and in the center of the screen, the table representation interfaces. Remember that tables with no associated clients will not respond to user interaction. Please take care of interfaces that are displayed on top of others (especially in the center of the screen).






Politica de confidentialitate



DISTRIBUIE DOCUMENTUL

Comentarii


Vizualizari: 1610
Importanta: rank

Comenteaza documentul:

Te rugam sa te autentifici sau sa iti faci cont pentru a putea comenta

Creaza cont nou

Termeni si conditii de utilizare | Contact
© SCRIGROUP 2022 . All rights reserved

Distribuie URL

Adauga cod HTML in site