Cafe Management System

Third Year Project Report

B.C.A

PSIT College of Higher Education

Author:
Charu Awasthi
 Cafe Management System

Abstract

This report documents the process of designing, developing and testing a software system to be used in a
restaurant; usually given the name restaurant management system. The restaurant management system
is there to help communication between all teams within a restaurant by minimising the probability
ofhumanerrors.
 Acknowledgements

Iwould like to thank my project supervisor,manish sir ,for providing an awful amount of guidance and input
throughout the writing ofthis report.Inaddition,I’dlike tothank my family forthe support throughout my fi
nalyearatuniversity,andforcheckingovermyreport.
Contents

1 Introduction 6
1.1 Chapter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 The Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Project Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Existing Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Project Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 Summary of Chapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7 Commonly Used Words . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.8 Closing Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Background 10
2.1 Chapter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Point-of-Sale (POS) Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Existing Point-of-Sale (POS) Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Platform Choice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5 Software Choice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.7 Requirement Gathering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.8 Development Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.9 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Requirement Analysis 14
3.1 Chapter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Stakeholder Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 Measureable Goals and Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5.2 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.6 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 Design 20
4.1 Chapter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3 Component Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4 Data Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4.1 Relational Database Management System (RDBMS) . . . . . . . . . . . . . . . . 20
4.4.2 Extensible Markup Language (XML) . . . . . . . . . . . . . . . . . . . . . . . . . 21

3
 4.4.3 Storage Method Chosen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4.4 Normalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.4.5 Entity Relationship Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.4.6 Database Design Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5 Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.5.1 Order GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.5.2 Kitchen GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.5.3 Management GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.6 Pricing Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.7 Flow Charts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.8 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5 Implementation 32
5.1 Chapter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2 Implementing Extreme Programming (XP) . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3 Data Storage and Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.4 Stock Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.5 GUI Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.5.1 Order GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.5.2 Kitchen GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.5.3 Management GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.6 Pricing Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.7 Code Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.8 Version Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.9 Error Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.10 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6 Results 42
6.1 Chapter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.2 Management Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.2.1 Data Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.2.2 Stock Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.2.3 Offer Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.2.4 System Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.2.5 Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.3 Order Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.4 Kitchen Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.5 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7 Testing 61
7.1 Chapter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.2 Testing Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.2.1 Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.2.2 User Acceptance Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.2.3 Usability Testing and Usability Inspection . . . . . . . . . . . . . . . . . . . . . . 63
7.3 Testing Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.4 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
8 Conclusion 65
8.1 Chapter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.2 Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.3 Further Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.3.1 Graphical User Interface (GUI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.3.2 Table Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.3.3 Cooking Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.3.4 Online Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.4 Reflection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.5 Skills Attained . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.6 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Bibliography 66

List of Figures 69

List of Tables 71

List of Listings 72

A Initial Project Plan 73

A.1 Aims & Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
A.2 Proposed System Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
A.3 Task, Milestone and Deliverable Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 74

B Use Case Scenarios 75

C Database Structure 78

D Database Stock Control Functions 79

E Pricing Algorithm 81
Chapter 1

Introduction

1.1 Chapter Overview

This chapter gives an introduction to the project by defining the problems encountered by restaurants,
themainobjectivesthatthesystemexpectstoachieveandabriefintroductiontoexistingsolutions.

1.2 Project Objective

The objective of this project is to build an electronic restaurant management system using all of the
skills and techniques from the field ensuring that no common development mistakes are reproduced.
Project management is critical to all software engineering projects and keeping to a project plan will
be of similar importance.
One of the main objectives of any business is to maximize profit by increasing efficiency and de-
creasing overheads1 without compromising customer satisfaction. Currently, many restaurants use a
paper-based system to communicate between the restaurant and kitchen which can be shown to be one

6
 Even though this approach is implemented in successful profitable restaurants, there are several
problems which could be seen as reducing the restaurant’s efficiency:
• Miscommunication caused by handwriting.

• Unmanageable order logging.

• Inefficient restaurant-kitchen communication.

• Difficult order tracking and time management.

• Difficult stock management.

• Limited statistical output.

By introducing an electronic restaurant management system these problems can be avoided or improved
leading to an increase in profits.
The initial project plan drafted at the beginning of the project can be found in Appendix A.

1.4 Existing Solutions

There are many computerised restaurant management systems available but for each system there
exist disadvantages or missing features. The most common type of restaurant management system
contains a static order entry computer system usually in the shape of a desktop computer with a touch
screen. Typically this common approach is adequate to the restaurants requirements but still requires
handwritten orders to be relayed to the order entry computer system. A table comparing features of
existing solutions will be presented in Section 2.3.
A slightly different approach was implemented in a restaurant in Nuremberg, Germany, named
s Baggers [16]. The restaurant utilises a roller coaster approach to serving the food and an order
entry system fully operated by the customer. As reviewed by the BBC [15], there is no need for any
waiters as the customers use touch-screen monitors to browse the menu. This new invention can save
on operating costs, but the initial injection of cash required is substantial as every table requires the
necessary hardware.
The next section will introduce the project proposal listing the proposed features of the system.

1.5 Project Proposal

The aim of this project is to create a restaurant management system that can incorporate the benefits
of all the existing solutions but without any of the drawbacks as well as including many new features.
A list of proposed features can be found in table 1.1.
Many of the existing solutions to POS (Point-of-Sale) systems are sold with the required expensive
hardware so for any business looking to work to a budget, the more enriched software solutions are just
out of their range.

7
Table 1.1: A table showing the proposed features of the system and the motivation behind the features.
Feature Motivation
Automated stock control. Real-time view of ingredient stock levels so
only the meals with enough ingredient stock
can be sold.
Meal option and preference selection. Flexible meal options available for the cus-
tomer.
Wireless order system. Waiters no longer required to walk to and from
the central order computer system.
Advanced discount function. Calculating the best price for the customer.
Order alerts. Kitchen and bar staff in direct communication
with waiters allowing the kitchen to notify the
waiter that service is required.
Flexible GUI design. Software capable of being used on any sized
screen and so must have a flexible design.
Order logging. All orders logged for future query generation.
Large kitchen order display. Easy tracking and viewing of all active2 orders.

1.6 Summary of Chapters

The rest of this report consists of the following chapters:

• Background: Background investigation into the problem.

• Requirement Analysis: Requirements of the system including stakeholder identification, list of
features and tabulated requirements.

• Design: Project design process using several diagrammatic techniques.

• Implementation: Discusses the implementation of the software with the help of diagrams and
pseudocode.
• Results: Illustrates the system using screenshots.

• Testing: Documents how the system was tested.

• Conclusion: Project conclusion with future development ideas.

1.7 Commonly Used Words

Throughout this report, there are many commonly used words as detailed in table 1.2.

8 Carl Abernethy
 Table 1.2: A table showing the commonly used words throughout this report.
Word Definition
Ingredient Ingredient of a meal.
Prepared ingredient Collection of ingredients.
Item A meal or drink.
Menu section A section of menu for example starters, meats,
puddings etc.
Suborder A collection of customer ordered items.
Order A set of suborders.

1.8 Closing Remarks

This chapter has introduced the foundations of the project. The next chapter gives some background
investigation into the problem.

9 Carl Abernethy
 The proposed features in table 1.1 were generated from research into numerous POS systems. Table
2.1 shows the comparison between some of the proposed features and the features of other POS systems.
All these POS systems were found on the first page of a Google search on the 14th October 2009.

2.4 Platform Choice

Choosing a suitable platform normally goes down to the programmers experience and the type of
software to be developed. The restaurant management system could be developed as a web application
or a standalone application but must also be widely supported and platform-independent. Therefore
as the developer has minimal or no experience in web programming, the decision was taken to develop
a standalone application.
The next decision was to decide on a programming language, with the developer having previous
experience in python.This decision was fairly easy and Java was the selected program-ming language as the
developer has great knowledge in the Java Database Connectivity (JDBC ) API 1 that allows database-
independentconnectivitybetweentheJavaprogramminglanguageandnumerousdatabases[8].

2.5 UML

Diagrammatic techniques are used to visualise, construct and document software systems under de-
velopment. The most general modelling language to describe both the structure and behaviour of a
software system is Unified Modelling language (UML) created by the Object management group. The
diagrams one can create using UML can be shown by a class diagram (Figure 2.1). Throughout this
report, numerous models defined within the UML class diagram (Figure 2.1) will be used to graphically
representthesystem.

11
when the project has a strict deadline to work to. Roughly a £1 cost of change in the requirement
gathering can cost up to £100 in the testing stage and £1000 in the deployment stage to fix.

2.8 Development Methodology

A software development methodology is a framework used to plan the design of a software system
controlling the process of development. According to Geoffrey Elliott [5], software development meth-
odologies first emerged in the 1960’s with systems development life cycles (SDLC) being considered
the first formalised methodology. Since then there have been numerous popular software development
approaches including the waterfall model, prototyping, incremental, spiral and agile.
The agile methodology refers to a collection of different agile methods. This project will be based
on Extreme programming (XP) which is one of these agile methodologies using an iterative based
framework. Each iteration has a development cycle very similar to the waterfall model consisting
of planning, requirements analysis, design, development and testing. At each iteration, the business
representative sometimes referred to as the ‘customer’ is given a demonstration to promote useful
feedback. This type of methodology reduces risk and lets the project adapt to requested changes
quickly with minimum cost.
According to the Agile Manifesto [10], some of the main principles behind the agile methodology
are:

1. Customer satisfaction by rapid, continuous delivery of useful software.

2. Working software that is delivered frequently.

3. A welcomed late change in requirements.

4. Simplicity.

5. Regular adaptation to changing circumstances.

Given these principles and the nature of the project, extreme programming was the best choice
methodology to use as we expected frequent customer communication and constant requirement changes
post customer feedback. Therefore for this project, the supervisor acted as the customer regularly
reviewing the work. Any errors or unthoughtful designs were then picked up and fixed relatively early
in the process helping to minimise costly errors as shown in Boehm’s cost model (Figure 2.2).

2.9 Chapter Summary

This chapter has given examples of POS systems that are directly related to this project as well as
general information about requirement gathering and development methodologies. The next chapter
starts the process of the development methodology by generating the requirements of the system.

13 Carl Abernethy
Chapter 3

Requirement Analysis

3.1 Chapter Overview

This chapter will look at the stakeholders of the system and then discuss the required features using a
use case diagram to illustrate.

3.2 Stakeholder Identification

As defined in the Business Dictionary [4],
a stakeholder could be a person, group, organisation that has direct or indirect stake in an
organization because it can affect or be affected by the organization’s actions, objectives
and policies.
Hence, stakeholders can be split into two groups; internal and external with each stakeholder contrib-
uting directly or indirectly towards the business activities.
As an example, any system were there exists customer communication, that customer will be a
non-financial beneficiary stakeholder. According to an article written by Ian Alexander [1], the person,
group, organisation, or system is a stakeholder if they can be defined by any one of the following four
questions:

Who needs to be consulted on the scope of this project?

Who has an input to the budget of this project?
Who can support or harm this project politically?
Who can provide guidance on the usability, functionality, and required qualities (reliability,
safety, lifetime, maintainability, . . . ) of the system under development?

Therefore using these 4 questions as a guide, we can generate a list (Table 3.1) of the stakeholders
in this project.

3.3 Use Cases

A use case diagram that is part of the Unified Modelling Language (UML) which was introduced in
Section 2.6 gives a graphical overview of the functionality of a system. A use case diagram consists of
actors that are normally the stakeholders of the system and their use cases commonly defined as goals.

14
RESTAURANT MANAGEMENT SYSTEM CHAPTER 3. Requirement Analysis

Table 3.1: A table showing the stakeholders of the project.

Stakeholder Role
Carl Abernethy Project developer.
Prof. Chris Taylor Project supervisor.
Management User of the management application.
Waiters User of the restaurant application.
Kitchen Staff User of the kitchen application.
Bar Staff User of the restaurant application.
Customer Indirect user of the system.
Cashier External stakeholder; accepts payment.

Figure 3.1 shows several use case scenarios of the system that convey how the stakeholders interact
with the features to achieve a business requirement. The use case scenarios from figure 3.1 can be
found in Appendix B.
The use case diagram is designed to be sequential so by following the use cases down the spine, one
can follow the major steps of an order and several post features to query the data.

3.4 Features
An important part of requirements gathering is the production of a list of system features that cat-
egorises on priority.

Table 3.2: A table showing the proposed system features and allocated priorities.
Feature Priority
Communication of data between each application. 1
Minimum click touch screen GUI design for efficient ordering. 1
Meal ingredient and cooking preference options. 1
Interface to view active orders in the kitchen. 1
Ability to add flexible discounts; calculating best price for the customer. 1
Interface to maintain and manage the menus and associated meals. 1
Stock control for all ingredients; reducing/increasing stock automatically. 1
Ability to define groups of ingredients that may be used in numerous meals. 2
Flexible meal grid design to fit any screen size. 2
Real time waiter status alerts. 2
User login functionality. 3
Interface for table management and selection. 3
Figure generation; management can view statistics in numerous forms. 3
Automatic daily stock level alerts. 3
Ability to define meals by images as well as text. 3

3.5 Measureable Goals and Requirements

The measurable goals and requirements of the system are a list of manageable1 requirements and goals
for each application that can be prioritised and ‘ticked off’. The software requirements specification
1 Requirements that are realistic and can be completed within the allocated time.

15 Carl Abernethy
 Restaurant Management System

Book Table

Check/Deduct Stock

Waiter Chef
<<include>>

Receive Order Confirm Order

Order
Food/Drink
Place Order

Prepare Drink Cook Food

<<include>> <<include>>

Collect Order
Staff Bar Staff Call Server
Customer

Serve
Food/Drink

Eat Food

Pay for Meal

Pay
Accept Payment

<<include>>

Manager Check Offers Cashier

Generate Reports

Manage menu
& ingredients

Order Stock

<<include>>

Update Stock Levels

<<include>>

Stock Check

Login

Figure 3.1: Use case diagram showing some of the major features within the restaurant management
system.

16 Carl Abernethy
(SRS) is a complete list of requirements to be designed and developed and can take the form of functional
or non-functional requirements.

3.5.1 Functional Requirements

A functional requirement is a requirement that, when satisfied, will allow the user to perform some
kind of function. The functional requirements of the kitchen, management and order application can
be found in tables 3.3, 3.4 and 3.5 respectively. The priority value is in the range from 1 to 3 where 1
is high priority and 3 is low priority.

Table 3.3: Kitchen application functional requirements.

Requirements Priority
Organised display of active orders. 1
View preferences and optional choices of every meal. 1
Inform waiter; update order to ‘in progress’. 2
Inform waiter; update order to ‘ready’. 2
Display elapsed time and progress2 of each order. 3

Table 3.4: Management application functional requirements.

Requirements Priority
Ability to display the real time stock levels. 1
Ability to add ingredients, meals and menus. 1
Ability to edit ingredients, meals and menus. 1
Ability to remove ingredients, meals and menus. 1
Ability to display statistics of complete orders. 3
Ability to add new waiters to the system. 3
Ability to add, edit and remove offers. 1
Ability to add time intervals3 to menus and offers. 1
Ability to alter the grid size of the meals, menu sections and menus. 1
Ability to alter the seating layout. 3
Ability to alter the price of ingredients. 1
(Note: Ingredient might still be in stock at a different price)
Ability to change transparency of an image that represents a meal. 3
Means of stock checking. 1
Means of updating the minimum stock level. 1

17
 Table 3.5: Order application functional requirements.
Requirements Priority
Ability to view the active suborder details. 2
Ability to add a new order to a table. 1
Ability to add a new order without defining a table. 1
Ability to add a suborder to an existing order. 1
Ability to delete a suborder that has not yet been confirmed within the order system. 1
Ability to view optional ingredients in a meal. 1
Ability to view cooking preferences of ingredients that can be cooked different ways. 1
Ability to only view the active4 menus. 1
Ability to view the status of all active suborders. 2
Ability to print customer receipts on order completion. 3
Ability to view transaction list of current order. 3
Ability to alert the waiter when the drinks are complete. 3
Ability to delete an item or clear the transaction list. 2

3.5.2 Non-Functional Requirements

Non-functional requirements are usually some form of constraint or restriction that must be considered
when designing the solution. The non-functional requirements of the kitchen, management and order
application can be found in tables 3.6, 3.7 and 3.8 respectively. The priority value is in the range from
1 to 3 where 1 is high priority and 3 is low priority.

Table 3.6: Kitchen application non-functional requirements.

Requirements Priority
Ability to interact with the MySQL database. 1
Means of refreshing the orders within the ordered list. 1
Means of refreshing the status of orders. 3
(How many items in the suborder have been cooked)
Means of refreshing the status of orders. 3
(How many items in the suborder have not been cooked)
Means of refreshing the menu section list. 2
(How many items in the menu section have been cooked)
Means of refreshing the menu section list. 2
(How many items in the menu section have not been cooked)
Means of refreshing the meal colours within the ordered list: 3
==> White: not started
==> Yellow: in progress
==> Green: complete
Means of displaying only the food items so drink items are omitted. 1
Means of clearing the suborder from the kitchen display. 1

4A menu is active when the current time is within the specified time interval of the menu.

18
 Table 3.7: Management application non-functional requirements.
Requirements Priority
Ability to interact with the MySQL database. 1
Means of refreshing menus, menu sections and meals live. 3
Only accessible by management staff. 3
Means of displaying the links therefore being able to view the ingredients in a meal etc. 1
Means of searching the database using wild cards for easier data input. 2

Table 3.8: Order application non-functional requirements.

Requirements Priority
Ability to interact with the MySQL database. 1
Ability to update the suborder status every 5 seconds. 1
Ability to run on a PDA by defining smaller grid and font sizes. 2
Ability to use the application using a touch screen 1
without the need of a keyboard or mouse.
Colour co-ordinated meal buttons to visually warn the user of low stock. 2
Ability to disable meals that have run out of compulsory stock items. 1
Ability to only show an ingredient as an optional ingredient choice 1
if there exists enough ingredient stock.
Ability to calculate stock ingredient price, order price and discounted price. 1
Live refreshing of the menus depending on the starting time of the order. 1
Ability to apply offers depending on the starting time of order 1
even if the offer is inactive on completion of the order.
Minimum clicks from the beginning to the end of an order. 1

3.6 Chapter Summary

This chapter has discussed the requirements of the system and the development methodology that will
be used throughout this project. The design of the system is documented in the next chapter.

19
Chapter 4

Design

4.1 Chapter Overview

This chapter will focus on the design of the system using diagrams to illustrate graphically certain
sections of the software system.

4.2 Introduction
This project has been designed using numerous diagrammatic techniques. Recall from Section 2.6, that
the most general modelling language to describe both the structure and behaviour of a software system
is Unified Modelling language (UML).
Use case diagrams have already been used in the requirements analysis as a way to graphically
overview the order process within the system. Other diagrams from the UML family are used in the
design stage to show the structure and behaviour of numerous sophisticated design features.

4.3 Component Diagram

A component diagram is part of UML and its main purpose is to show the structural relationship
between components in the system. A component diagram is useful for this system as it shows the
higher architecture, as shown in figure 4.1.

4.4 Data Storage

The restaurant management system will be built around the data storage technique therefore choosing
the most appropriate persistent1 data storage is critical to a successful project and we can assume a flat
file storage approach is inadequate. The two most popular types of persistent data storage available
are relational database management system (RDBMS) and extensible markup language (XML).

4.4.1 Relational Database Management System (RDBMS)

A relational database management system (RDBMS) is a database managed system based around a
relational model and are the corner stone’s to many software systems including web based systems.
1 Data structure that preserves the original data when changed.

20
 << Server >>

MySQL
<< database >>

JDBC

{}
<< requires >> {}
<< requires >>

<< Computer >> << PDA >>

Software System Software System

<< Java Application >> << Java Application >>

Figure 4.1: Component diagram showing the higher level architecture of the system.

RDBMS are one of the most popular data storage methods out in the market and offer many advantages
including:
• Fast data extraction using structured query language (SQL).

• Good management of data and security through the management system.

• Good level of data consistency.

• Advanced features including functions and triggers.

• Requirement of a data model to be developed; leading to long term cost effectiveness.

In industry, there are numerous expensive highly functional RDMBSs including Oracle and SQLServer
that are very popular and offer technical support. However, there are also numerous open-source solu-
tions with many adjudged to be as good or better and are becoming even more popular with small
scale software systems.

4.4.2 Extensible Markup Language (XML)

XML is a markup language that was designed to transport and store data and is another example of
a persistent data storage technique. However, it is not a predefined language thus all tags must be
defined and due to its hierarchically data structure all elements must be promoted or demoted.
XMLcouldbeusedintwodifferentwaysindatastorage;storingtheXMLdocumentswithindatabase.

21
 Receipt Name
Display Name Available Stock
Key
Price Description
Relationship

Name Icon Path

Entity
ID

Relationship
Meal
attribute

Attribute

0..n 0..n 1..m

Contains

Available Stock Optional Contains

0..n Limited:
Optional 1 loop
Contains 1..m
Optional
Manual Measurement
Prepared Ingredients
1..m Available Stock

Name 0..n 0..n

ID
Manual Measurement
Contains
BelongsTo
Default Measurement
Ingredients
1..m
1
Available Stock
0..n
0..n 0..n Category
Has
Has Of
0..n
1
1
1
BelongsTo Name ID
0..n 1
Stock Of Unit Supplier

Price ID Name

Measurement

Min Threshold ID, Name, Details ...

Current Amount

0..n 1 0..n 0..m

Ingredient Detail BelongsTo Food Type Has Preference

ID Name
ID ID Name
Name
Description
0..n 1
BelongsTo
Strength (Drink only)

Figure 4.3: Entity Relationship diagram of a meal.

24
 Key Discounted Price

Table # Complete
Relationship
User # Price
Start Time
Entity Call Server

Defined
ID Ingredient Price
entity Order

Relationship
attribute
1
Attribute
Contains
Cooked

Suborder Time ID
1..n ID Price

User #
0..n 1..m
Complete Suborder Contains Suborder Product

Active

Suborder # Call Server 0..n 0..n

Removed
Contains Contains
Food/Drink
Food/Drink
Name Optional
1 1
ID Name Colour
ID Active

0..n 1..m 0..n 1..m

Menu BelongsTo Section BelongsTo Meal Suborder Product Ingredients

Order Number Order Number Price

1..n

From
ActiveOn
0..n 0..n
To 0..n
0..n
0..m Replaced Replaced
Original
Original
ID
Days
0..1 0..1
0..1
0..1
Name

1..n
0..m
From Contains Set #
ActiveOn

To 0..m Ingredient
Prepared Ingredient
1..n

System Settings Menu Section Height/Width

Offer ID
0..n 1
Of Type
Menu Section Text Size
Machine Name
N Set 1

ID ID Name
Menu Height/Width
N Set 2

Name Call Server Colours

Price
Menu Text Size
N Set 3 Menu Grid Groups
Percentage
Menu Char Limit
Menu Image Transparency

Figure 4.4: Entity Relationship of the menu, order, offer and system settings.

25 Carl Abernethy
 Select Menu => Select Item(s) => Show Item(s) Select Menu => Select Item(s)

Food
Select Food/drink Drink
Food
=> Select Menu
Drink
Menus
Select Food/drink
=> Select Menu

Menus
Transaction
Grid of items
List
Grid of items
Tables

Tables

Price
Command buttons

Command buttons

Start transaction => Finish transaction

Chronological order through commands

 1 2 3 1 2 3

Normal Grid 4 1 2 4 5 1 Shift of all

’Main Courses’

3 2 3
Starters

Main Course
1 2 3 1 2 3

Grid with Algorithm 4 4 5 No shift!

1 2 3 1 2 3
 Menu
Ordered Food Items
Section

Menu List Of
Ordered Food Items
Section Suborders

Menu
Ordered Food Items
Section

Command
Ordered Food Items
buttons

Tabs
Tabs: Different forms for inputting data

Search
tool
Details of
the selected
item
Items
Different
functions
available

Command buttons
 T1
O1

S1
O2
T2

O1 O3
T3

T4
O1

S2
O2 O2
R T5

O3
T6

O3
T7
O1

S3
O2
T8

O3
T9
 Start

Table
Table or no table?

No table

Add new order Yes

and sub order to New order?
database.

No

Add items (available) Add sub order

to sub order. to existing order.

Add
another
item
Automatically deduct
stock amount.

Confirm order.

Error: Order empty.

Yes
Order contain
Prepare drinks
drink items?

No

Drink: No
&
Drink complete; Food: No
Order contain
infrom server.
food items?
Colour: Colour 2

Drink: Yes
& Food: Yes
Food: No

Start food & inform server.

Colour: Colour 1

Cook food.

Food complete;
inform server.
Colour: Colour 3

Server collects
complete food/drink

No (Only for table orders!)

Pay?

Yes

Stop: Order complete