weeblygraceordering.weebly.com/uploads/2/4/1/1/24119261/c… · web viewthe main system calls...

Chapter 3

3.1 Software Requirements Specification

3.1.1 Introduction

On selecting a project every member of the group should have an idea and the ability to

develop the chosen project. It is also important to have a project adviser that can able to guide

the group throughout the project.

In many popular restaurants, waiters/waitresses tend to miss out on tables or customer

calls during busy hours potentially decreasing services to the client. The group intends to design

a system in which the customer can call their service easily and help the restaurant increase

overall efficiency.

3.1.1.1 Goals and Objective

Customer satisfaction is the key to success for any business. Restaurant order and

payment system aims to:

Help the company to better serve their customers

The system intends to make the process easier, help the customers to order

and pay easier than and as fast as possible.

To improve, upgrade and develop current system

Improve and development of the restaurant’s current system can satisfy

the needs of their customers. Helps owners, managers, and staffs achieve

Restaurant Ordering System

that outstanding service reputation which always sets a restaurant apart

from its fierce competition.

To have a reliable, efficient, effective, user friendly and competitive system

Running the restaurant as efficiently as possible can meet the needs not

only the customers but also the restaurant. It can help them attract more

customers to earn big sales.

3.1.1.2 Statement of Scope

Order systems, in one form or another, have been a part of doing business for ages,

and have developed alongside technology to provide powerful means of capturing, tracking and

shipping customers' orders. Advanced order processing systems can span multiple continents to

track and facilitate international orders, shipments and returns for a wide range of product lines

and consumer segments.

An order processing system captures order data from customer service employees or

from customers directly, stores the data in a central database and sends order information to the

accounting and shipping departments, if applicable. Order processing systems provide tracking

data on orders and inventory for every step of the way.

And accurately is the key to customer satisfaction. Order processing systems help

ensure that all of your customers' orders are filled on time, since automated systems can reduce


errors in order processing. This can enhance the customer experience and maximize your

company's profitability.

User Requirements for the Restaurant Automated Ordering System

Food Inventory System

Req.

No.

Priority Reference Description

Access Privilege

R1 High Manager/Dine-

In Supervisor

and Waiter

There are two levels of access: Manager, Dine-In

Supervisor and waiters.

R2 High Manager

/Dine- in

Supervisor and

Waiter

The manager/dine – in supervisor and waiter is

allowed to enter/access, edit and add menu on the

system.

R3 High Manager The manager is allowed to monitor the food available

in the kitchen to update the system if there are not

available in the menu.

R4 High Manager The manager is allowed to cancel order by inputting

transaction code or the OR in the receipt.

R5 High Waiter The waiters allowed using the system for taking the


order of the customer.

R6 Medium Waiter The waiter allowed assisting the customer and using

the system when there’s a request in customer’s food.

R7 High Cashier The cashier allowed to print the entire bill that the

system sent

R8 Low Kitchen staff The kitchen staff will receive the order sent by the

system

R9 High Manager The manager is allowed to view on what’s going on in

the system.

Security

R10 High Manager

/Dine- in

Supervisor and

Waiter

The manager/dine – in supervisor is required to log on

with a unique username and password before using the

system.

R11 High Manager

/Dine- in

Supervisor and

Waiter

The password contains 6 to 15 alphanumeric

characters.

Tables

R12 High Customer Each special table accepts up to 5 persons and above.

R13 High Customer For every three tables can use of one system.


User Interface

R14 Medium Customer The system shall have a database.

R15 Low Customer The background of all windows shall be based on

what the theme color of the restaurant.

R16 Medium Customer The system shall respond to all users if it is done in 3

to 5 seconds.

Billing

R17 High Customer Itemized customer invoices showing the amount of

their total orders.

R18 Medium Customer An account history for customer shall contain all

activity by date.

3.1.1.3 Software content

Restaurant owners can enhance their business productivity by making use of the

restaurant ordering system which will help them increase their business revenue. Restaurant

business services are growing in demand; therefore one way to complete to other restaurant is to

improve the quality of their service.

Restaurant ordering system will replace the manual process of ordering. through

the use of the system, the customer waiting time will be minimized and the process will be fast

and easy to serve.

3.1.1.4 Major constraints


Max’s Restaurant will use a Tablet for their ordering Process to satisfy the

customer order and to have good services.

3.1.2 Usage scenario

3.1.2.1 User profiles

Dine – in Supervisor The one who can view, edit, update and delete the old menu of an

Ordering system.

Manager The manager can also view menus and monitor foods or restaurant

functions.

Cashier /Counter They are responsible by calculating and printing the bill of the

customer.

Waiter s Has a responsibility to guide the customer on how the system can

use in tablet. They can also view menus and take orders from the

customer using system. Waiters also have an account to access the

system.


3.1.2.2 Use-cases

1. Order food

2. Select

3. Verify

4. Send order

5. Preparation

6. Compute order

7. Create bill

8. Payment bill

9. Payment by the

customer

10. Change

11. Give order

12. Cancel order

13. Log – in

14. Food

monitoring

15. Available food

16. Not available

food

17. Report

18. Sales report

19. Waiter report

20. Update menu

21. Add menu

22. Edit menu

23. Delete menu


2.2.1 Use – case Diagram

Manager

Dine – In Supervisor


Log in

Print Report

View report

Monitor food

Assign waiter

Monitor customer satisfaction

Monitor and save transaction

Cashier

Waiter

Figure 1: Use-Case Diagram of an Ordering system

The diagram above shows that can access the system and what is the purpose of that

system. Like this manager can only view the report of the system. Dine – in Supervisor will

be the one to monitoring foods, monitoring satisfaction and also assigning waiter. Cashier

can also monitor/ save transaction, Accept Order, Accept payment, Print bill and the lastly is


Cancel order

Send order

Print bill

Accept order

Accept payment

Sign out

Give Order

the Waiter . Waiter can also send order to kitchen, the one who can cancel the order and also

the one who serve/ give the order of customer.

3.1.2.2.2 Use-Case Descriptions

Use-Case : Login

Primary actor: Manager , Dine – In Supervisor and Waiter

Goal in context: To gain access to the system.

Preconditions: The Manager, Dine – In Supervisor and Waiter has a valid username

and password.

Trigger: The Manager, Dine – In Supervisor and Waiter needs access to the

system to perform their job.


Scenario: 1. The system prompts the manager, dine-in supervisor and

waiter for their username and password.

2. The manager, dine-in supervisor and waiter enter their

username and password.

3. The unit sends the username to the web server.

4. The web server sends back the password registered for the

username.

5. The unit verifies the password and sets the user’s authorization.

6. The manager, dine-in supervisor and waiter is given access to

the system to perform

Exception: The user has an invalid password.

Use-case: view report

Primary actor: Manger

Goal in context: To see the report of sale and waiter.

Precondition: The manager must log on to the system with their username and

password.

Trigger: The manager needs to view the report of sales and waiters.

Scenario: 1. The manager log on to system.


2. The system will verify their account.

3. If correct the manager can view the reports.

4. The manager can print the reports.

Exception: The user doesn’t have an account.

Use-case: Monitor food

Primary actor: Dine – In Supervisor

Goal in context: To monitor food inventory in the system.

Prediction: Check if there are foods available.

Trigger: The Dine – In Supervisor monitors food in the kitchen.

Scenario: 1. The Dine – In Supervisor checks the stock/storage of

ingredients.

2. The Dine – In Supervisor reports all the changes in kitchen to

Manager.

Exception: The user doesn’t have an account.

Use-case: Monitor Customer Satisfaction

Primary actor: Dine – In Supervisor

Goal in context: To see where the customer satisfy.


Prediction: The best food for the customer.

Trigger: The Dine – in Supervisor will survey about the food.

Scenario: 1. If the customer will satisfy on their order.

2. The Dine – in supervisor will survey about the best meal.

Exception: If the customer not satisfy on their order.

Use-case: Assign Waiter

Primary actor: Dine – in Supervisor

Goal in context: To assist the customer.

Prediction: To get the customer order through tablet.

Trigger: The waiter send the order to kitchen

Scenario: 1. Assign the waiter to assist the customer

2. Get the customer order.

3. Give the vacant seat to customer.

Exception: No waiter available.

Use-case: Monitor /save transaction

Primary actor: Cashier

Goal in context: To check the debit of the restaurant


Prediction: To see the total sale of the day.

Trigger: To see all sales income.

Scenario: 1. The customer pay after eat the foods.

2. The cashiers give the sales report to manager.

Exception: If the cashier forget to save the receipt.

Use-case: Accept payment


Goal in context: To get the payment of the customer.

Prediction: The cashiers create a receipt for customer.

Trigger: The customer will wait their change.

Scenario: 1. The customers pay the total bill.

2. The customers wait the receipt and the change if there have a

change.

Exception: If the customer not willing to wait.

Use-case: Print bill



Goal in context: To printout the bill

Prediction: The system must send the total amount to the cashier

Trigger: The printer should be ready to print.

Scenario: 1. The cashier receives total amount of customer’s order.

2. The cashier printout the bill.

3. The cashier puts aside the bill just to be ready to give it if the

customers request their bill.

Exception: Insufficient ink for the printer.

Use-case: Send Order

Primary actor: System

Goal in context: To send the order to the kitchen.

Prediction: The customer must finish order on the system

Trigger: Click send button after the customer chooses their order.

Scenario: 1. The waiter or customers click the send button in the system.

2. The kitchen server will receive a notification on the LCD of

their receiver.

Exception: If the food is not available.


Use-case: Cancel order

Primary actor: Waiter

Goal in context: To cancel order of the customer.

Prediction: The cashier must finish creating the bill.

Trigger: The customers make a hand – wave signal.


Scenario: 1. The customers make a hand wave signal to the waiter.

2. The customers say if he/she wants to cancel their order.

3. The waiters get the table no. of the customer.

4. The waiters say to the cashier the cancellation of the customer

order.

5. The cashiers give the receipt to the manager.

6. The manager finds the transaction code in the system to cancel

all their orders.

Exception: If the cancellation has error.

Use-case: Give order

Primary actor: Waiter

Goal in context: To serve the food to the customer.

Prediction: The kitchen staff must finish preparing the food.

Trigger: The kitchen staff will send the confirmation to the monitor in front to

serve the customer order.

Scenario: 1. The waiters will get the food to the counter.

2. The waiters will see the receipt if what table he/she serve it.

3. The waiters will serve the food to the customer.

Exception: The bill is not included.


Use-case: Sign out

Primary actor: Manager, Dine – In Supervisor, Waiter.

Goal in context: To sign out the system.

Prediction: The manager and 2 other will need to sign out to system.

Trigger: The manager and 2 other will sign out for security of the system.

Scenario: 1. They need to sign out for the security of the system.

2. The system need to sign out before leave to restaurant.

3. Sign out the system if no one can use it.

Exception: If you forget to sign out the system.

3.1.2.3 Special usage consideration

Table Reservation does not include.

The system can only accept orders which are dine-in or take out.


ORDER

3.1.2.4 Activity Diagram

Start

No

Is the

Order final?

Yes

Figure 2 –Activity Diagram of Order.


Display OrderWindow

Final Order

Click on Menu

Display complete order

Order combo meal

Order DrinkOrder Dish

The customer will order using the system and choose from the available meals.

The customer chooses the meal by clicking it in the system which is on every waiter. The

customer will then be finalized their order to be sent by the waiter.

<<Precondition>>

Yes

No

Exact change?


Total bill is displayed

Order has been confirmed

Cash Collector collects cash

Returns change

User receives Final Bill

Payment

Figure 3 – Activity diagram of Payment

The system will compute the total amount of the food order. The waiter will get

the bill on the counter and give it to the customer. Payment is accepted in terms of cash

payments.


Prompts the user for username and password

Prompts user for invalid username and P/W

Log on to system

Is Username and No

Password valid? Yes

Figure 4. Activity Diagram of Log on to the system

Show the step taken as the supervisor logging on to the system. Access is only granted if

the correct username and password combination is entered within the first three attempts. After a

third attempt the user should wait 60m seconds to log on again.


User enters username and password

Access granted

Verify Username and Password

Is password Valid? No

Yes

Is Change Required?

Yes

No


Prompts the user for password

User Enters Password

Update Menu

Save the Menu

Make Change

Prompts User for invalid P/W

Figure 5.Activity Diagram of updated menu

The user must have a valid username and password to logs onto the system. A

menu list will be displayed when the user enters the system. The Supervisor makes the

required changes.

Is a Particular Item NO

Out of Stock?


Log out from the System

Food Monitoring

Yes

Figure 6. Activity Diagram of Inventory

The manager is given the right and privileges to enter the system and make the

required changes. The manager checks the stock/storages of ingredient notices an item out of

stock and updates the item accordingly.

3.1.3 Data Model Description

3.1.3.1 Data Objects

Menu Data Object

Meal No. A unique number for meal


Update Items Accordingly

Meal Name The name of every meal.

Price The amount of every meal.

Class ID For the identity of every class.

Order Detail Data Object

Order No. The number of every order. To have a unique identifier in order.

Meal No The number of meals according to their classification.

Quantity The quantity of the food ordered.

Classification Data Object

Class ID For the identity of every class.

Class Name It classifies the class of the meal.

Payment Data Object

Order No. Number of every order. To have a unique identifier in order.

OR No. A unique number given to the total meal ordered

Date Shows The date of transaction.

Status The Status of an order whether it is rejected or not.


Total Amount The total amount due of all meals ordered.

Table No. A number in a table.

User ID It identifies the user. Every user has their own User ID.

Table Data Object

Table No. A number assign in each table. To have a unique identifier of table.

Status Shows Either the table is occupied or still available for the next client.

User Log Data Object

User ID A unique identifier assigned to the Supervisor.

Password The Administrator password used to log on to system. This is use

for security purposes.


2.1.3.2 Relationship


CustomerOrder

FOODFrom

POS

Paid WAITER

Give toServe Send SendPreparing

CASHIERKITCHEN

Need Need

Table number

Price

Number

Name

Amount Menu

Computer

Payment

Figure 7. Entity Relationship Diagram

The customer will order food from the system. The system sends the ordered

details to the kitchen which needs chefs in the preparation of food and will be given to the

waiters after to be served to the clients. The system also send the total amount of the bill to the

cashier who needs an accountant to print the bill and will give to the waiter to be paid by the

appropriate clients.

3.1.3.3 Complete data model


Give

BILLTo print

ACCOUNTANTCHEF

DateTotal amountOR number

ManagerUser nameFirst nameMiddle name Last name AddressPassword

Cashier ID no.First nameMiddle name Last name Address

Waiter User nameFirst nameMiddle name Last name AddressPassword

Figure8. Complete Data Diagram of Ordering system


ReportDaily Monthly

MenuBreakfastLunch Dinner Special menu of the dayDessert

Order Order no.Item discPrice

Billing Item discOR No.Total amount Date Time

Table Name representCustomer No. Time & DateIn charge waiter

Dine – in SupervisorUser nameFirst nameMiddle name Last name AddressPassword

3.1.4 Functional Data Description

3.1.4.1 Class Diagram

1 1

M 1

1 M

M

1 1 1


Table Table No. Int (20)Status Char (20)

+add ()+check ()

OrderOrder No. Int (20)OR No. Int (20)Date VarChar (10)Status Char (20)

+cancel ()+check ()+view order ()+set order ()+modify order ()

MenuMeal no. Int (10)Meal name Char (20)Price Int (10)Class Char (20)

+add meal ()+edit ()+delete ()

Bill Total amount Int (20)OR No. Int (20)Date VarChar (20)

+print ()

Order Detail

Order no. Int (10)Meal no. Int (10)Quantity Int (10)

+quantity ()+cancel ()+edit ()

Classification

Class ID Int (20)Class Name char (20)

+add ()+edit ()

Figure9. Class Diagram

The class diagram shows the functions of each table in the system. Each entity

with their appropriate attributes has its own functionality in the system. They have their own

connections to one another by their respective cardinality.

3.1.4.2 Software Interface Description

3.1.4.2.1 External machine Interface

The software will be Capable of using tablets to send the order thru the use

of GPRS connection.

3.1.4.2.2 External system interfaces

The Max’s restaurant will communicate with a standalone ordering system

so our system doesn’t need an internet connection.


Order Detail

Order no. Int (10)Meal no. Int (10)Quantity Int (10)

+quantity ()+cancel ()+edit ()

3.1.4.2.3 Human Interface

The Max’s Restaurant will provide a Tablet to their order process system.

3.1.4.3 Report

3.1.4.3.1 Inventory of Reports

3.1.4.3.2 Layout of Reports

3.1.4.3.3 Data Dictionary of Reports

3.1.5 Behavioral Model Description

3.1.5.1 Description of software behavior

3.1.5.1.1 Events

Customer Class Event

Customer order food

Customer confirm order

The customer receives order

The customer receives a bill

Customer paid bill

Dine – In Supervisor Class Events


Dine – In Supervisor log onto the system

Dine – In Supervisor adds food in the menu

Dine – In Supervisor edits food in the menu

Dine – In Supervisor deletes food in the menu

Dine – In Supervisor update food in the menu

Cashier Class Events

Cashier receives the computed order

Cashier creates bill

Cashier print bill

Cashier receives payment

Kitchen Class Events

Kitchen receives the order

Kitchen prepare the order

Kitchen gives the prepared order to waiters


Waiters Class Event

Waiter user the system

Waiter assist customer in ordering

Waiter receive the prepared order

Waiter serve order

3.1.5.1.2 States

Customer States Description

Waiting The customer has been waiting for their order.

Paid The customer paid the bill after eating.

System State Description

Send The system sends order to the kitchen.

Compute The system compute the total amount of the order.

Update The system can update the menu.

Cashier States Description

Create The cashier will create the bill of the customer.


Print The cashier will print the bill.

Paid The cashier receives payment from the customer.

Dine – In Supervisor Description

Log in The Dine – In Supervisor has log onto system.

Add The Dine – In Supervisor add food in menu system.

Edit The Dine – In Supervisor edit food in menu system.

Delete The Dine – In Supervisor delete food in menu system.

Update The Dine – In Supervisor update food in menu system

3.1.5.2 State chart Diagram

Touch cash

option


A

Put cash in the slot

Screen free to take order

cash acceptable No

Yes

Touch the screen once

Touch cancel Touch an Item

Order

Touch cancel Think

Order

No

Yes Touch


Customers wait for a screen to be free

Customer ready to order

Menu screen

Item sent to cashier and kitchen

Cancel order

Compute item

Read Cash

Return change if any

Reject cash

Add/edit/create menu

Figure10. Overall System State chart Diagram

A state chart describe the possible states of a single class and the events that cause

state transitions. They are useful for showing the life cycle of the class. State chart and activity

diagrams both describe state transitions and share many of the same elements. The following

diagram shows the state chart diagram Restaurant Ordering system.

No

Yes


Item Update

Item added to kitchen

Display bill

Print receiptA

Log on UpdateMenu windows

Verifying

Manager class State chart Diagram

Figure11.Manager Class State chart Diagram

The Manager Class State chart Diagram shows the flow of the system when the

manager uses it. The system prompts the admin for their username and password, after that the

system will verify the username and password if it is register in the system then the manager can

update the food list in the system and if it is registered in the system will save the updated list.

Yes

No


Save

Drag Send Verify

Reset

View

Order class State chart Diagram

Figure12.Order Class State chart Diagram

The Order Class State chart Diagram shows the flow of the system in ordering. The

customer will drag ,or click only those foods they order, while they choosing their order the

system shows all the customer orders and the system verify the order by displaying a message if

it is sure t be sent or not.

3.1.6 Restrictions, Limitation, and Constraints

The Ordering system is not use an internet connection.

We can open it through net beans/java only.

3.1.7 Validation Criteria

Software validation will ensure that the system responds according to the users

expectation; therefore it is important that the end users are involved in some phases of the test

procedure.

3.1.7.1 Classes of tests

Unit testing will be conducted on all of software subsystem including

1. Login for MANAGER user

2. Login for WAITER users

3. Sign up for MANAGER account

4. Sign up for WAITER’s account

5. Creating new category


6. Uploading new food

7. Availability of food

8. Sending order to kitchen

9. Sending total price order to cashier

10. Viewing receive order to the kitchen

11. Viewing reports

12. Payment of food ordered using cash

13. Payment of food ordered using credit card

14. Updating of food

15. Updating of category

16. Updating of ADMIN account

17. Updating of WAITER’s account

18. Printing Reports

19. Printing Receipt

Testing will be conducted at the restaurant’s site.

3.1.7.2 Expected software response

The software should display an appropriate message when a value they enter is

correct.

The software should display an appropriate message when a value they enter is

incorrect.

3.1.7.3 Performance Bounds

The System shall be transfer the orders to the kitchen as many as the customer

enter to Restaurant.


The process of the Ordering System is base to the Customer Order.

3.2 Software Design Specification

3.2.1 Introduction

On selecting a project every member of the group should have an idea and the ability to

develop the chosen project. It is also important to have a project adviser that can able to guide

the group throughout the project.

In many popular restaurants, waiters/waitresses tend to miss out on tables or customer

calls during busy hours potentially decreasing services to the client. The group intends to design

a system in which the customer can call their service easily and help the restaurant increase

overall efficiency.

3.2.1.1 Goals and Objectives

Customer satisfaction is the key to success for any business. Restaurant

ordering system aims to:

Have a reliable, efficient, effective , user friendly and competitive system

Running the restaurant as efficiently as possible can meet the needs not

only the customers but also the restaurant. It can help them attract more

customers to earn big sales.

Help the company to better serve their customers

The system can help the company to make their process easier, and the

customers to order and pay as fast as possible.


To improve the communication between the client and the server and minimize

the time in ordering

One of the main objectives of a restaurant is to ensure customer

satisfaction. Manual listing of orders by the waiters/ waitresses may result

uses the proposed system, manipulation of orders to the customers would

be so easy and quick by just touching on the desired menu.

To automatically computed the bill

The system will also automatically calculate and displays the final bill so

the bills will be ready to print without having any error because the

information for that item is already inserted.

To have an updated menu and avoid redundancy of cooking the ordered food.

Using the system will also avoid redundancy of cooking the ordered food

because the list of the ordered menu is listed on the screen in the kitchen.

And so the list of menus will be updated from time to time monitoring of

foods it will surely inform them whether the menu is still available or not.

The proponents offer a system that will give a higher-than-usual level of customer

service and have an efficient and effective serving of customer. Having the

proposed system will assure the company that their regular customers will come

back more often as well as introducing the restaurant to new customers.

3.2.1.2 Statement of scope

This study focuses on managing the restaurant order and monitoring food.

The scopes of the study defines what is or not to be done. This system can only


accept orders which are dine-in or takeout. Additional recipes and ingredients in

the list of custom meals will be accepted.

The proposed system is a software solution for users to easily add and take

order. When a new order comes in, some general information about the new order

will be inputted such as items from the menu, the price of each item, time and

date. After a new order has been successfully placed, a list of the items will be

sent to the kitchen for cooking and the total amount will be sent to the cashier to

print the bill. Ordering system will be a good solution for faster communication

between the client and the server.

Major Inputs:

Log-in name and password

Sign up

Table number

Food name, price, additional request, quantity and images

Order type

Update menu

Company Information

Processing Functionalities

Function Priority


Tables number Essential

Meal information entry Essential

Sending order Essential

Calculating totality Essential

Billing Essential

Receipt printing Essential

Reports printing Essential

Outputs:

Meal information, total amount of food ordered, sign in and sign out sheet, daily reports,

daily waiters report.

3.2.1.3 Software Context

The system is created in code that be written in NetBeans IDE with help of

SQLyog to running the system. The system don’t need a internet connection because it is

an standalone.

3.2.1.3 Major constraints

The system will not use a internet connection because our system is not Online

system. The system required to use a GPRS to send the order to kitchen and kitchen to

POS. The system will run fast and easy.


3.2.2 Data Design

As the application is being build in NetBeans IDE, SQLyog and GPRS. GPRS is

more important because it will be one who transmits the process of the system.

3.2.2.1 Internal Data Structure

The internal functional procedures are the logical entities that carry out

different task of adding, updating, deleting, viewing, or printing the database.

3.2.2.2 Global Data Structure

The only kind of data available globally to the whole system is the

database itself stored in SQLyog. Any data stored can be update or delete.

3.2.2.3 Temporary Data Structure

The Ordering system does not use any intermediate temporary files of its

own. Once the data is being stored all the intermediate data it being stored by the

DBMS.

3.2.2.4 Database Description

Table Name: tblmanager

Attributes : intID, varmanagerfname, varmanagerpassword, intstatus,ttLastLogin

Datetime

Description: it holds all the account information of the admin user in the system.


Table Name: tblcustomers

Attributes : intcusid, varcuslname,varcusemail,varcuspassword, intstatus,

dtregtime

Description: it holds all the employees account who access the system.

Table Name: tblcustomerbaskets

Attributes : intID, varseasonID, intcustomerID, intproductID, intproductquantity

dectotalprice, varrequest, inttable, varstatus, dtdateadded

Description: it holds all the data the ordered in the system.

Table Name: tblimagesettings

Attributes: intid, intproductthimage, intmidiuming, intproductbigimage,

Intcategoryimage, intsiteforideaorspecialoffer, intbannering

Description: it holds all theimages in the system.

Table Name: tblmanager

Attributes : intID, varmanagerfname, varmanagerpassword, intstatus,ttLastLogin


Datetime

Description: it holds all the account information of the admin user in the system.

Table Name: tbllanguages

Attributes : intlaguageid, varname, varcode, varcatimage,vardirectory,

intsortorder

Description: it holds what language use in the system.

Table Name: tblmystore

Attributes : intid,; varstoreownername,varowneremail, varfromemail,

varcountry, varzone, varsendtoordereamail, varstoreaddsandphone,

varwelcometitle, txtwelcommess, varpostcode

Description: it holds all the information about the company description.

Table Name: tblproducts

Attributes : intproductid, intmanufacture, intcategoryid, intprodquantity,


Intprodmdel, intproddefaulting, decprice, dtaddeddate, dtlastmodified,

dtavailable, intordered, varedited

Description: it holds all the information the product in the system.

3.2.3 Architectural and Component level Design

3.2.3.1 Architectural Diagram


Order and Menu

Uses

Uses

Uses

Figure13. architectural Context Diagram

The architectural context Diagram for the software is shown above. As it is clear

from the diagram, various actors are manager, dine – in supervisor, waiters which use the system


RESTAURANT ORDERING

SYSTEM

Manager

Dine – in Supervisor

Neteans IDE My SQL

Waiter


Add/ delete Modify food info.


Table number Info.

Print or display Reports

Add/ delete Modify users info.

Menu info

Users login and logout info.

Users basicInfo.

Pricemenu info

Figure14. Call and return architectural Diagram

Call and return architecture has a main program, which controls all other. Basically it

selects the functions describe in components below it. The main system calls restaurant ordering

system. Now pending on the access levels, it calls the various functions. For example when main

calls add/delete/modify food info. This function further calls one of the functions shown below

depending upon the user wish.

<< access>>

<< access>>


MenuMenu No.Menu NameCategorySet menu no. ()Set menu name ()Set category ()Set quantity ()Get menu no. ()Get menu name ()Get category ()Get quantity ()

Customer Table no.Types Dine in Takeout

Set table no ()Set types Set dine in () Set take out ()Get table no ()Get types Get dine in () Get take out ()

<< users >>

<< access >>

<< access >>

Figure15. Object-oriented Architectural Diagram


PaymentCash Credit Credit card no.

Set cash ()Set credit ()Set credit card no. ()Get cash ()Get credit ()Get credit card no. ()

Report

Print receipt ()Print sales report ()

Dine in supervisorSign inOverwork Edit Add UpdateSet sign in ()Set overwork () Set edit () Set add () Set Update ()Get sign in ()Get overwork () Get edit () Get add () Get Update ()

Waiter Sign inOrderQuantity

Set sign in ()Set order ()Set quantity ()Get sign in ()Get order ()Get quantity ()

As we can see from the object-oriented architectural diagram, it describes the

details about the classes we are going to use and the variables and their types.

3.2.3.2 Description of Components

3.2.3.2.1 Component Customer

3.2.3.2.1.1 Processing narrative of component Customer

The component customer contains the class customer. It contains the attributes,

which are the basic data customer. It contains functions, which sets all the related data info and

out of the database.

3.2.3.2.1.2 Interface description of the component customer

The component customer has an interface with the class menu from which it

inherits attributes and functions. The menu class has attribute, which are the basic data common

to customer class and menu class functions to this data into database and retrieve from the

database.

3.2.3.2.1.3 Algorithmic description of the component Customer

Component Customer;

The intent of the component customer is to set basic data of customer into database and get the

data from the database.

Start

Declare variable of ordering food of customer


Set the data into the database

Get the data from the database

Calculate the bill of the customer

End

3.2.3.2.1.4 Design Class Hierarchy

<<access>>

3.2.3.2.1.5 Restriction/Limitation

This component can only be called when the user wants to order in the system.





3.2.3.2.2 Component Waiter


Component waiter consists of the class waiter. It contains the attributes, which are

the basic responsibilities of the waiter regarding on menu, payment and guiding customer in

ordering their food.


The component waiter has the interface with the classes Menu, Customer and

Payment. Since the waiter is responsible in ordering food for the customer, it inherits the

functions from the customer and menu to compute the payment.


Component waiter

The intent of the component waiter is to get the info from the customer to menu to compute the

payment.

Start

Get the order from the customer

Set waiter data into the database

Get waiter data from the database


Calculate the pay bill of the customer

End






This component can only be called when the customer wants to order in the

system.

3.2.3.2.3 Component Dine – In Supervisor








Component Dine – In Supervisor consists of class manager. It contains the

attributes, which are the basic responsibilities regarding in updating, editing and adding menu.


The Component Dine – In Supervisor has interface with the classes Menu,

Waiter and Reports. The Admin has the responsibility of setting the menu, waiters and reports.


Component Dine – In Supervisor

The intent of this component is to set the data of the Dine – In Supervisor, menu and reports.

Start

Set the data of Dine – In Supervisor into the database

Set the data of menu into the database

Set the data of waiter into the database

Get the data of Dine – In Supervisor from the database

Get the data of menu from the database

Get the data of waiter from the database

Print the reports

End



<<access>>






<<access>>

<<access>>


The component can only be called when the user wants to manipulate the

waiter data and menu data.


Report


3.2.3.2.7 Component Reports


The component report consists of the class report. The responsibilities of

this component are to print the report of customer order and sales report.


The component report has the interface with the menu. It inherits the data

members and functions from the class menu to print the sales report and receipt of the customer.


Component report

The intent of this is to print the reports

Start

Get the menu data

Print the menu data report

Get the payment data

Print the receipt of payment data

End



3.2.3.3 Dynamic behavior for component

3.2.3.3.1 Interaction Diagrams

system ready

Login



Report


Waiter Devices Printer Kitchen Ordering system

Reading

Not autheriticated () Success

Give access to waiter

Waiter get the order of the customer

For display Send list of order

For total order data

Figure16. Sequence diagram for waiter

This in a sequence diagram where the use case component is a waiter. The waiter

login to the system. A valid username and password result in a password correct event to system

which then gives access to the waiter. And customer can order now to the system to send it to the

kitchen to prepare and in cashier to print the receipt.

3.2.3 User Interface Design

The system has a Graphical User Interface, which is build completely in

SQLyog. Among the variety of design available in SQLyog we have chosen


Comparing

Display order

Print receipt

netbeans and javascript for development as more variety of component are

available in it and more sophisticated techniques are available to change

appearances of those components if required in future.

3.2.4.1 Description of the User Interface

3.2.4.2 Interface Design rules

3.2.4.3 Components Available

3.2.4.4 UIDS Description

3.2.5 Restrictions, Limitation and Constraints

3.2.6 Testing Issues


TABLE OF FIGURE

Figure1. Architecture Context diagram

Uses

Uses

Uses


RESTAURANT ORDERING

SYSTEM

Manager

Dine – in Supervisor

Netbeans IDE My SQL

Waiter

Order and Menu

Figure2. Call and Return Architecture Diagram


Add/ delete Modify food info.


Table number Info.

Print or display Reports

Add/ delete Modify users info.

Menu info

Users basicInfo.

Pricemenu info

Figure3. Object Oriented Architecture Diagram

<< access>>


Users login and logout info.

MenuMenu No.Menu NameCategorySet menu no. ()Set menu name ()Set category ()Set quantity ()Get menu no. ()Get menu name ()Get category ()


Set table no ()Set types Set dine in () Set take out ()Get table no ()Get types

<< access>>

<< users >>

<< access >>

<< access >>


MenuMenu No.Menu NameCategorySet menu no. ()Set menu name ()Set category ()Set quantity ()Get menu no. ()Get menu name ()Get category ()


Set table no ()Set types Set dine in () Set take out ()Get table no ()Get types






Figure4. Sequential Diagram

system ready

Login

Not autheriticated () Success

Give access to waiter

Waiter get the order of the customer

For display Send list of order


Report


Waiter Devices Printer Kitchen Ordering system

Reading

Comparing

Display order

For total order data


Print receipt

weeblygraceordering.weebly.com/uploads/2/4/1/1/24119261/c… · web viewthe main system calls...

Documents