Tan Yuan Hua

UNIVERSITY OF WALES, UK

FINAL YEAR PROJECT

The Food Service Industry:A Highly Expandable IT Solution

By

Tan Yuan Hua

BACHELOR OF SCIENCE (HONS) IN BUSINESS COMPUTING AND INFORMATION TECHNOLOGY

APRIL 2009

i

Declaration

PROJECT DECLARATION FORM

University of Wales

The declaration form is to be completed and attached within the project dissertation. The student should read and sign the declaration.

Student Particulars

Name: TAN YUAN HUA Student ID: 018800005137

Project Title: The Food Service Industry: A Highly Expandable IT Solution

Major: Computer Science Business Computing and Information Technology

Date: APRIL 2009

Student Declaration

I declare that

1. I understand what plagiarism is;

2. The consequences of plagiarism have been explained to me by my institution; and

3. The project is all my own work and I have acknowledged any use of others’ published or unpublished works.

4. The project was completed over two semesters from TERM 3 2008 to TERM 1 2009.

5. I had done backup of my coding and dissertation.

Student Signature: _________ Date: _______________

ii

University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution

Acknowledgement

The challenges that were faced during the project were able to be overcome by

the support of various people and sources. This project was only made possible with the

help of the people around me and the understanding of my family members, friends and

especially my girl.

This dissertation was able to be delivered on time with both qualitative and

quantitative research writing being fulfilled in spite of the circumstances was

achievable only with the dedication of the lecturer, industry professionals, school mates

and friends. With that, I would like to give my deepest gratitude to the following

mentioned on the next paragraph.

I would like to thanks University of Wales and Informatics Education, for

providing a thorough syllabus that helped built by knowledge and skills, and for

providing the digital library which was used for most of the project research. I am

grateful to my project supervisor, Mr. Pala, for providing professional opinions and for

guiding me throughout this project. Special thanks to Dr. Teo Kim Heng for his

contribution of great opinions and thoughts. I am also pleased to be given the

opportunities by the restaurant owner, to help implement a solution that proves to help

the business.

Lastly, this give me great opportunity to express my thankfulness to all else and

especially my girl, whom selflessly helped me both explicitly and implicitly to ensure

that I am able to complete the project on time. Thank you.

ii


Abstract

The profit maximizing nature of businesses is an omnipresent motivation for

entrepreneurs to supersede yesterday's performance and enhance tomorrow's prospect.

Therefore, leveraging on technologies give businesses more room for growths. What is

needed is an IT solution that is able to help the businesses today, while also able to easily

adapt to business strategy changes in the future.

A highly expandable IT solution is the focus of this project. This solution is able

to help the businesses improve on their business processes and solve their business

problems today. In addition to that, it is also designed and built in anticipation of the

future. However, it is not a straightforward task.

A lot of analyses were made on the design of the solution. The challenges were

numerous as designing an architecture in anticipation of the future proves to be a

complicated job. N-tier system architecture and software design patterns were factored

into the solution to ensure scalability and expandability. Integration of devices and

components using low level proprietary protocols has to be ensured with another layer of

abstraction from the software.

Despite surmounting challenges, the highly expandable IT solution was

successfully built by an intricate integration of various concepts and implemented at the

targeted business. This shows the high amount of achievement that was gained

throughout the whole project.

ii


Table of Content

DECLARATION I

ACKNOWLEDGEMENT II

ABSTRACT III

CHAPTER 1: INTRODUCTION 1

1.1 BACKGROUND 11.2 AIM 21.3 OBJECTIVES 31.4 TIME PLAN 4

CHAPTER 2: LITERATURE REVIEW 5

2.1 INTRODUCTION 52.2 SYSTEM ARCHITECTURE 62.3 SOFTWARE DESIGN PATTERNS 8

2.3.1 Database Factory Pattern 82.3.2 Class Helper Pattern 92.3.3 Composite View Pattern 10

2.4 .NET TECHNOLOGIES 112.4.1 Introduction to the .NET Framework 112.3.2 Web Application or Window Application 132.3.3 Window Application: WPF or Windows Forms 15

2.4 SUMMARY 16

CHAPTER 3: SOFTWARE DEVELOPMENT METHODOLOGY 17

3.1 INTRODUCTION 173.2 PLANNING 183.3 REQUIREMENT ANALYSIS 20

3.3.1 Business Use Case Diagram 203.3.2 System Use Case Diagram 31

3.4 DESIGN AND DEVELOPMENT 413.4.1 Technologies Used 413.4.2 Database Design 423.4.3 System Design 443.4.4 System Class Diagram 483.4.5 User Interface Design 50

3.5 IMPLEMENTATION 553.6 TESTING AND INTEGRATION 57

ii


3.6.1 Test Cases 58

CHAPTER 4: PROJECT EVALUATION AND CONCLUSION 62

4.1 PROJECT EVALUATION 624.2 FUTURE ENHANCEMENTS 644.3 CONCLUSION 65

REFERENCES 66

APPENDICES 68

APPENDIX A: SCREEN CAPTURE OF DIFFERENT SOFTWARE INTERFACES 68Appendix A-1: Cashier User Interface 68Appendix A-2: Change Price Window 68Appendix A-3: Cashier User Interface 69Appendix A-4: Daily Sales Windows 69Appendix A-5: Sales Report Window 70

APPENDIX B: PICTURES OF DIFFERENT DEVICES THAT WERE USED 71Appendix B-1: Customer Display (Black), VFD2029 71Appendix B-2: Cash Drawer (Black), RJ11 71Appendix B-3: TYSSO Thermal Receipt Printer (Black), PRP-085IIIT 71Appendix B-4: 1515L Multifunction 15” LCD Touchmonitor 72

APPENDIX C: SCREEN CAPTURE OF DIFFERENT RECEIPTS GENERATED 73Appendix C-1: Receipt Notification for Chefs (Original and Amended) 73Appendix C-2: Receipt for Customers (Before Payment and After Payment) 73

3


Chapter 1: Introduction

1.1 Background

The profit maximizing nature of businesses is an omnipresent motivation for

entrepreneurs to supersede yesterday's performance and enhance tomorrow's prospect. As

such, providing better services and product values remain a focus for most businesses in

today’s environment. The current advances in technology and the increasing

sophistication of solutions allow businesses to achieve this: by enhancing the

effectiveness and efficiency of their operation. Businesses that succeed in leveraging on

technology will be able to simplify and develop various areas of their operation, and thus

prosper in the industry.

Leveraging on technology might be able to help businesses; however, one must

ensure that the solution is a scalable and expandable one. This will guarantee that future

changes in business strategies would not encompass a total redesign of the system.

Castelli and Pagano (2003) state that “In order to provide service expansion, these

systems must be based on open architectures” (p. 335). According to Castelli et al.

(2003), architecture is considered open when the total functionality is partitioned into a

number of established rules and such architecture makes it possible to expand the system

functionality by adding new service component instead of re-building the whole system

(p.335). Therefore, the design of this expandable solution will take into consideration

these factors to ensure an open architecture is created.

3


With an open architecture, it does not necessary means that the solution is

expandable and scalable. The software design itself should encompass many different

software design patterns that not just help in the reusability of components, but rather, for

scalability and expandability. As mentioned by Khosravi and Gueheneuc (2004),

software design patterns are able to provide the following quality

characteristics for software (p. 15). According to Khosravi et al. (2004),

these are some of the characteristics; Availability, Configurability,

Changeability, Flexibility, Hardware Independence, Scalability (p. 15 –

31). With that, it gave me certainty that software design patterns have

to be factored as part of the software design.

There is a reason as to why the IT solution has to be developed

for scalability and expandability. The targeted restaurant owner is very

ambitious with his own business. Therefore, the IT solution that

supports the business has to be ambitious too. A vision by the

restaurant owner to transform the restaurant, eventually, to be a chain

with established brand name. Therefore, to support for future changes,

I reckon that the solution have to be scalable and expandable. This

ensures the IT strategy is well aligned with the business strategy.

3


1.2 Aim

To develop an expandable solution for the food service industry that helps to

enhance the existing business operations and also designed in anticipation of future

changes and expansions.

1.3 Objectives

In order to achieve the aim of the project, a few objectives have been drawn up to

ensure that the project deliverables is in line with the project aim. These objectives will

help me to identify the important milestones of this project and thus, would make this

project a success if all these objectives are met at the end of this project. The objectives

are:

1. To research and gain more domain knowledge in terms of the food service

industry.

2. To research on the existing n-tier system architecture and software design

patterns for the solution.

3. To research on existing technologies that can be used to create the solution

and other tools that has the likelihood to integrate into this project.

4. To design and create a user interface using usability engineering that will

enhance users’ experience when dealing with the application.

5. To learn and develop the solution using n-tier application architecture and

software design patterns to enhance software scalability and expandability.

3


6. To implement the solution to the targeted restaurant successfully without any

interruption to the existing business.

4

4

4


1.4 Time Plan

4

4

4


73

73


Chapter 2: Literature Review

2.1 Introduction

A highly expandable IT solution is one where it can scale and expand as required.

And in accordance to the business strategy, the solution should have parallel alignment in

terms of usage and also design. In the food service industry, IT solution can help in many

ways, from servicing of customers to the notification of orders to the chefs. As the

business grows, it has to cater to the needs of the management too. For example,

customer relationship management, integrated workflow, mobile ordering and even

resource scheduling. These are some of the anticipated functionalities that could be

implemented in near future.

In order for such functionalities to be implemented in near future, there has to be

some form of capabilities in the software that is built. Such capabilities have to

encompass the quality characteristics as mentioned by Khosravi et al. (2004). Thus, to

ensure the quality characteristics exist in the system, an open architecture has to be

designed as recommended by Castelli et al. (2003). This will be further explained at the

other sections in this chapter.

The software solution is a critical part of the whole IT solution. In order to design

in anticipation of the possible future changes, software design patterns have to be

factored into the software design for building scalable and expandable solution. As

mentioned by Ng, Cheung, Chan and Yu (2006), they deemed that Open-Closed Principle

as one of the most commonly adopted software design tactics (p.51). Open-Closed

73

73


Principle is means that “software entities should be open for extension, but closed for

modification” (Meyer, 1988). This further proves the possibility of using software design

patterns to build scalable and expandable IT solution.

Low level protocols and proprietary protocols that are embedded at devices that

will be implemented in this IT solution are also examined. These include low level COM

port communication and even proprietary ESC/POS command developed by Epson. As

mentioned by Garlan & Shaw (1993), “Abstraction layering and system decomposition

provide the appearance of system uniformity to clients” (p.4). This is the reason why the

technique was to add a layer of abstraction in the software solution to hide the detailed

implementation.

2.2 System Architecture

As stated in the section 2.1, there has to be some form of capabilities in the

software in order to cater for future changes. In this case, an open architecture is required.

As mentioned by Castelli et al. (2003), an open architecture makes it possible to expand

the system functionality by adding new service components (p.335). This will thus, gives

quality characteristics like changeability, flexibility, hardware independence and

scalability to the system (Khosravi & Gueheneuc, 2004). This will allow expanding of

system functionality to be done easily.

Software architecture acts as a bridge between the user requirements and the

implementations (Garlan, 2000). In order to ensure that the IT solution is also capable of

being scaled and expanded to future business changes, there must be some sort of

73

73


architecture that act as a bridge between the two. For this, the three-tier software

architecture is looked into.

Based on Grisham (2002), three-tier software architecture constitutes of the

following separation of logic.

1. User Interface2. Business Processing3. Database Access

With the separation of the whole software into logical units, the system can

provides increased flexibility, maintainability, reusability, and scalability, while hiding

the complexity of distributed processing from the user (Grisham, 2002). This is what is

required for the building of the expandable IT solution.

Figure 2.1 – 3-Tier Client/Server Overview

73

73


The diagram above shows the typical three-tier client/server implementation.

Using this as a conceptual model, one can implement the different layering at the

software side with different components for each layer.

2.3 Software Design Patterns

Software application will usually have multiple releases of enhancement before

their retirement as mentioned by Ng et al. (2006, p.51). Therefore, the software have to

be structured in a way where by the behavior of the system can be changed easily to cater

for future requirements easily (Ng, Cheung, Chan, Yu, 2006, p.51). In order for that to

happen, apart from the implementation of software architecture, it will be the

implementation of design patterns during the software design phases.

For the context of this project, design patterns that can help on the scalability and

expandability of the software will be analyzed. This is to ensure that only the design

patterns that truly help the solution will be implemented.

2.3.1 Database Factory Pattern

A database factory pattern implemented in the software ensures that when a

database change requirement is created, re-work on the software is minimized. Therefore,

adding a distinct database layer to the application can greatly increase its flexibility and

adaptability to change (Primary Objects, 2009).

According to Selvaraj and Ghosh (1997), a database factory class is actually a

combination of both the Factory Method and Abstract Factory patterns (p.15). Figure 2.2

shows the UML diagram of a typical implementation of the database factory class.

73

73


However, the details of this pattern will not be further explained as it will be

further discussed during the design and implementation of the expandable IT solution.

2.3.2 Class Helper Pattern

An extension of the Helper Pattern, the Class Helper Pattern helps to organize

common functionalities in a single class to ensure consistency. This is especially helpful

when there is a need to use a common method at every layer to process information, thus,

such common functionality should be place within a single class. Typically, a Class

Helper Pattern resides in the application common layer where all layers, data access,

business logic and presentation, are able to access the class at ease.

The Class Helper Pattern can also scale as the software expands. This is due to its

wide range of usage. It can hide implementation details of low level protocols from the

main classes while being able to communicate with proprietary devices effectively. More

methods can be added to the class at ease without fear of regression, breaking other codes

that are already implemented.

Figure 2.2 – UML Diagram of Database Factory Pattern

73

73


Figure 2.3 shows the UML diagram of a typical implementation of the Class

Helper Pattern.

2.3.3 Composite View Pattern

Used for the user interface layer, or Presentation layer, the Composite View

Pattern is a view built using other reusable sub- views (Sun Microsystems, 2002). As

mentioned in the article provided by Sun Microsystems (2002), a single change to a sub-

view is automatically reflected in every composite view that uses it. This can help the

user interface to scale and expand as wanted as the user interface of the new modules can

be included as sub-view to a main view.

Figure 2.4 shows how one main user interface is divided into many different parts

that form the whole page in Java. This allows understanding of how the pattern works

and implement in other possible situation using the same methodology.

Application CommonClass Namespace

Definitions

ErrorMessages

ConcreteHelper

getPrintCommand()

getPrintErrorMessage()

PrintReceipt()

Figure 2.3 – UML Diagram of Class Helper Pattern

73

73


2.4 .NET Technologies

2.4.1 Introduction to the .NET Framework

The Microsoft .NET Framework is a cluster of several technologies that enable

applications to be developed and executed in a managed and typed-safe environment

(Richter, 2000, p.9). More detailed

information can be retrieved from the

Microsoft’s Developer Centre website. For

this section, I will briefly talk about the

few critical technologies that form

the .NET framework.

1. The .NET Languages

2. Common Language Infrastructure

3. Framework Class Library Figure 2.5 - .NET Framework

Figure 2.4 – Screenshot of implemented Composite View Pattern

73

73


The .NET Framework comprises of a few languages for different developers with

different preference of programming

language. There is the C#.NET language,

C++ lookalike, for ease of transition of

previous C++ developers. The VB.NET,

Visual Basic lookalike, an object oriented

and modernized successor of VB 6.0.

Lastly, there is the J#.NET language which

is a Java clone. There are, in fact, a couple

more .NET compliant languages. Those

languages, however, will not be discussed here.

The Common Language Infrastructure is the key technologies that allow different

developers with different programming language preference to work together in the same

project (“.NET Framework”, 2004). All the different codes will be compiled into a

similar, platform neutral language, called the Common Intermediate Language (CIL).

The CIL is then further compiled into machine readable code in the Common Language

Runtime environment. All codes will be executed and managed in this environment.

The last technology to discuss in this section is the .NET Framework Class

Library. The class library contains thousands of objects and functionalities that can be

utilized by the applications instead of rebuilding those common classes again. This part

of the.NET technology provides more rapid application development for developers.

Figure 2.2 – Common Language Infrastructure

73

73


2.3.2 Web Application or Window Application

Having introduced the technology framework for Microsoft .NET, the next step is

to determined the context of the application. Do I build the expandable IT solution as a

Web Application or Window Application? In this section, I will perform a comparison

between Window application and Web application.

The table below reflects the advantages and disadvantages of building the solution

using either the Window application or the Web application.

Window Application Web Application

User Interface Easy to build Difficult to build

Figure 2.3 – .NET Class Library

73

73


Performance Fast More overhead

Development Easy to build Difficult to build

Maintenance Complex process Easy process

Resources Client Dependent Server Dependent

Framework

Dependency

All clients machine have to be

installed with the .NET

framework.

Only the server machine has to

be installed with the .NET

framework.

Robustness and

Reliability

If a client machine fails, the

other is still able to proceed.

If a web server fails, no one

can proceed.

From the table above, it is quite clear that the solution should be built using the

Window application. The following paragraphs explain my stand for this.

The solution has to provide high usability and high performance for the frontline

staff. This will ensure that the solution is responsive to the users’ action. For Web-based

application, there is usually a high overhead in terms of responsiveness due to the amount

of data transfer that is required before the server post back with a response. In addition,

the web page that resides in the web browser usually has to refresh itself before

presenting the response from the server. All these factors increases the overall time

required for a request to be responded.

In addition, the solution has to be very robust and reliable. This is to ensure the

optimum software availability. For the solution, the order system will have to be

available at various stations in the restaurant. Therefore, in this case, if one of the stations

Table 2.4 – Window App VS Web App

73

73


fails, there are still other available stations in the restaurant to create orders. If the

solution were to be built as a web based application, all the dependency will be placed on

the web server. Should there be a web server failure, the whole system will collapse. This

is undesirable.

Although there are other factors that makes Window application looks like a

second tier choice, all these factors are not as crucial as high usability, high performance,

high robustness and high reliability. After choosing the preferred type of application, in

the next section, I look into the two different types of window application that can be

built using the Microsoft .NET technologies.

2.3.3 Window Application: WPF or Windows Forms

The Window Presentation Foundation, or WPF for short, is a unified framework

to build the next-generation application that greatly enhances user experiences. The

framework provides developers superior 2D and 3D graphics support, interactive data

visualization and superior content readability (Faraday & Becker, 2009).

As mentioned by Faraday et al. (2009), the Window Forms is a set of classes that

exist in the .NET framework to allow rapid development of Windows client application.

It also contains extensive user controls support graphic supports through the Graphical

Device Interface, or GDI for short. One added advantage about the Window Forms is its

existence period. It has been in the industry for a long time and hence, there will be more

available support if an issue was found during the development phase.

73

73


In view of the expandable solution, it does seem that the Window Forms is more

appropriate than the WPF. However, they can co-exist in a solution should there be a

reason to include either of the type of platform. Firstly, there are more supports for

Window Forms applications than WPF since the latter is a new technology. Secondly,

WPF requires the Microsoft Expression Studio to create more interactive user experience,

this means added cost to purchase the software and the license. Lastly, the learning curve

for WPF is steep, as with any new technologies. With my development experience

towards Window Forms, I would thus, develop the proposed solution using the Window

Forms technology.

2.4 Summary

In this chapter, various parts of the projects were looked into. These include the

system architecture that comprises on an open and three-tier concept. Software design

patterns were also examined for possibility of integrating into the software architecture to

ensure scalability and expandability. In addition, .NET technologies, that will be used to

implement the solution, are also introduced in this chapter. Different types of solutions

are also critically reviewed and compared in this chapter.

73

73


Chapter 3: Software Development Methodology

3.1 Introduction

In this chapter, the initial stages of the solution’s development process will be

introduced. This includes all the works required from the requirement engineering

process to the design of the system architecture. In addition, the usability engineering

process would allow me to create a user interface for the solution that provides enhanced

human-computer interaction.

This whole commercial project was handled by me and another friend, whom

have the contact with the restaurant owner. However, since my friend have no software

development experience, he is in charge of hardware procurement and other none

software related issues. I am fully in charge of developing the software solution, and for

the sake of clarity for this project, I will touch a little on the overview, inclusive of areas

where work were done by both of us.

Figure 3.1 – Software Development Life Cycle

73

73


Throughout the whole software development phase, I will be using the Software

Development Lifecycle Methodology to guide me through to the successful

implementation of the custom built solution.

There are a total of 8 stages for this Software Development Lifecycle Diagram. In

this project, all the 8 stages will be walkthrough with the initial stages (highlighted in

green) being the most important. The rest of this chapter will be dedicated for discussion

for the software development lifecycle.

3.2 Planning

Planning is the stage in software development lifecycle where the solution is

given proper budget estimation, resource allocation, activities required, project schedule,

tools required and etc. Other plans, like business continuity plan and disaster recovery

plan, should also be included for the whole planning stages.

During the project initiation, we were approached by the owner of the restaurant

to develop the expandable IT solution for the food industry in specific, not just for the

restaurant alone. Therefore, it has to be simple to use and able to help to enhance the

current manual business process. We were given an initial budget of 20,000 RM for the

whole implementation, from the hardware to the software solution. With that, my friend

and I went to the targeted restaurant to meet the owner and gather an initial requirement

of what is expected of the project and the developed solution.

The below diagram reflects the floor plan of the restaurant and the owner‘s

requirement on the solution.

73

73


From the owner’s perspective, he requires two order stations, depicts OS1 and

OS2 in the diagram, in the implementation. This is to ensure that the staffs do not have to

walk a long distance to key in the orders. He also needs two printer stations, depicts P1

and P2 in the diagram. This is to ensure that a notification is sent to the kitchen staff to

prepare the order whenever orders are keyed into the order stations. There is also a

cashier station, depicts C in the diagram. This is for collection of receipt and payment

whenever the customers asked for billing.

Once we have gathered an initial high level requirement of the solution and what

the restaurant’s owner expects, we begin to perform feasibility study. We were given the

following factors:

Budget: 20,000 RM

Timeframe: 4 Months

Inner Restaurant(Non Smoking Area)

Outer Restaurant(Smoking Area)

OS2

OS1

P1 P2

C

Order Pickup Area

Figure 3.2 – Restaurant Floor Plan

73

73


Date of Implementation: 12/01/2009

Based on my friend’s research and sourcing of the hardware products, which I

will not further elaborate as it is not within the context of this academic project, it totaled

up to amount to 11,000 RM. This leaves a budget of 9000 RM for the software

development process. Based on my personal experience on development with the .NET

platform, this gives us a tight dateline to develop and fine tune the software solution

With that, we proceed to the next phase of the software development lifecycle

process; the requirement analysis phase. Before actually going into the requirement

analysis, we came out with a name for the software, called Restaurant Assistant. This will

aid us in identifying the software from the whole solution.

3.3 Requirement Analysis

The requirement analysis phase is the second phase of the software development

lifecycle as reflected in the diagram in the introduction. During this phase, the user’s

requirement is further elaborated. It is also our responsibilities that the solution to be

developed is in line with the business function. To ensure that, business use case diagram

is drawn as a communication tool to the user to project the way the system will works

when it is implemented.

3.3.1 Business Use Case Diagram

The business use case diagram is used as a platform to understand the way the

business operates. It will give a better understanding and would allow us to ensure that

73

73


the implemented system do not have to overhaul the way the business operates

fundamentally.

Firstly, all the actors in the use case diagram have to be identified as they will

help us to identify further series of interactions that can occur in the business operations.

The identified actors for the business are:

1. Customer

The customer is the one who comes to the restaurant to pay for the service and

the foods that he/she ordered. Majority of their interaction will be with the

frontline staff as they are being served by them.

2. Frontline Staff

The frontline staffs are those who serve and take orders from the customers.

Orders are then given to the kitchen staff, the non principal actor, for

processing. The frontline staff is the one whom the customers will interact

with most of the times.

3. Cashier Staff

The cashier staff is the one who is in charge of the counter at any point of

time. He/she has the responsibilities to issue receipt, give changes and

maintain high integrity of the total amount in the cashbox at the counter.

4. Kitchen Staff

73

73


The kitchen staff is the one who will receive the orders from the frontline staff

and prepare the orders accordingly. He/she can be the one who cook the

foods, prepare the drinks and also prepare the raw materials for the chef. For

the sake of simplicity, all of them are categorized under this section.

Secondly, the different use cases are identified. Each of these use case represent a

particular business process in the restaurant and the interaction between the different

actors.

B1: Order Food

The Customer initiates an order to the Frontline Staff. The Customer then order

the food that they want by saying the dish name to the Frontline Staff. The

Frontline Staff will jot down the order on a piece of paper to keep track of the

Customer’s order. The Frontline Staff will then pass the piece of paper to the

Kitchen Staff for preparation of the foods ordered.

B1-1: Order Drink

The Customer initiates an order to the Frontline Staff. The Customer then order

the drink that they want by saying the drink name to the Frontline Staff. The

Frontline Staff will jot down the order on a piece of paper to keep track of the

Customer’s order. The Frontline Staff will then pass the piece of paper to the

Kitchen Staff for preparation of the drinks ordered.

B2: Change Order

The Customer initiates a change order to the Frontline Staff. The Customer will

tell their changes of order to the Frontline Staff, simply by saying the changes

73

73


required. The Frontline Staff will amend the Customer’s order on a piece of paper

to keep track the Customer’s order. The Frontline Staff will then pass the piece of

paper to the Kitchen Staff to notify them of the changes made.

B3: Serve Food

Once the food is prepared by the Kitchen Staff, the Frontline Staff will serve the

food to the Customer.

B3-1: Serve Drink

Once the drink is prepared by the Kitchen Staff, the Frontline Staff will serve the

drink to the Customer.

B4: Prepare Food

After the Frontline Staff pass the Customer’s order to the Kitchen Staff, the

Kitchen Staff will proceed to prepare the food. This includes preparing the raw

materials, getting the necessary sauces and preparing them and then cooking the

food.

B4-1: Prepare Drink

After the Frontline Staff pass the Customer’s order to the Kitchen Staff, the

Kitchen Staff will proceed to prepare the drink. This includes preparing the raw

materials and then preparing the drink.

B5: Make Payment

The Customer will initiate a make payment request to the Frontline Staff. The

Frontline Staff will then total up the order and request for payment. The Customer

makes the payment to the Frontline Staff after that. The Frontline Staff will pass

73

73


the payment to the Cashier Staff for further processing before passing the change

and receipt back to the Customer.

Next, based on the actors and relevant use cases, the full business use case diagram is

reflected below.

Customer

B1: Order Food

Frontline Staff

B2: Change Order

B5: Make Payment

Cashier Staff

Initiate Order B1-1: Order Drink<extend>

Initiate Change

Initiate Payment

Receive Payment

Receive Payment

B3: Serve Food

B3-1: Serve Drink

<extend>

Kitchen Staff

Receive Order

Receive Order

B4: Prepare Food

B4-1: Prepare Drink

<extend>

Receive Change

Receive Change

73

73


Figure 3.3 – Business Use Case Diagram

73

73


Once the main use cases for the business have been identified, the next step is to

go into more details for the main use cases. The main use cases are the ones that define

the preceding activities which will describes the activities in the other use cases as

defined in the above diagram.

For this use case diagram, the main use cases are:

1. B1: Order Food

2. B2: Change Order

3. B5: Make Payment

For each of these main use cases, the business use-case activity diagram is created

for a deeper understanding of the activities flow.

Customer

Frontline Staff

Kitchen Staff

Place Order

Record Order

Process Order

Submit Order

Deliver Order

Confirm Order

Figure 3.4 – “B1: Order Food” Activity Diagram

73

73


Customer

Frontline Staff

Kitchen Staff

Change Order

Record Changes

Take note of changes

Submit Changes

Deliver Order

Confirm Order

Customer

Frontline Staff

Cashier Staff

Request Bill

Calculate Total

Make Payment

Request Payment

Deliver Payment

Confirm Receipt

Process Payment

Figure 3.5 – “B2: Change Order” Activity Diagram

Figure 3.6 – “B5: Make Payment” Activity Diagram

73

73


With the activity diagrams, the series of interaction between the different actors

are known. The next logical step is to create the use case description for each of the use

case with the aid of the respective activity diagram. The following figures show the text

description for the respective business use case:

73

73


Text Description for “B1: Order Food” Use Case:

Name: B1: Order Food Business Use-Case

Brief Description:

In this use case, a Customer who arrives at the restaurant will order their selected foods. The Frontline Staff will record the orders and pass it to the Kitchen Staff for processing. Once the food is ready, the Frontline Staff will pick up the order and send it to the Customer. The Customer then confirms that the food received is what he/she has ordered.

Principal Actor: Customer

Precondition:

The Customer must be in the restaurant and seated around a table to be able to order foods

MAIN FLOW

Step Name Description

Place

Order

The Customer walks into the restaurant and will be guided to a table. Time will be given to them to finalize on their order. He/she then places their order to the Frontline Staff.

Record

Order

The Frontline Staff, upon getting the order from the Customer, proceed to record down all the order on a piece of paper.

Submit

Order

The Frontline Staff will walk to the order pickup area and pass the piece of paper to the Kitchen Staff. They will then wait for the order to be processed.

Process

Order

The Kitchen Staff will process the order; cook the foods, prepare the drinks etc. Once the foods are prepared, they will place the foods at the order pickup area for the Frontline Staff to pickup.

Deliver

Order

The Frontline Staff will then pick up the foods from the order pickup area and deliver it to the respective Customer.

Confirm

Order

The Customer, upon receiving the foods, will check to ensure that the foods received is what they had ordered.

Figure 3.7 – Text Description of “B1: Order Food” Use Case

73

73


Text Description for “B2: Change Order” Use Case:

Name: B2: Change Order Business Use-Case

Brief Description:

In this use case, a Customer who arrived at the restaurant had already ordered their selected foods. However, due to some factors, they decided to change their order. Change order in this case means either adding new dishes, change the quantity of the existing order or cancelling an existing order. The Frontline Staff will record the changes and pass it to the Kitchen Staff for processing. Once the food is ready, the Frontline Staff will pick up the order and send it to the Customer. The Customer then confirms that the food received is what he/she has ordered.


Precondition:

The Customer must be in the restaurant and seated around a table and had already ordered.

MAIN FLOW


Change

Order

The Customer, who has already made their order, decided to change their order. This usually means either adding new dishes, change the quantity of the existing order or cancelling an existing order.

Record

Changes

The Frontline Staff, upon getting the changes required from the Customer, proceed to record down all the changes on a piece of paper.

Submit

Changes

The Frontline Staff will walk to the order pickup area and pass the piece of paper to the Kitchen Staff. They will then wait for the order to be processed.

Take note

of changes

The Kitchen Staff will have to take note of the changes and process the order with respect to the changes. Once the foods are prepared, they will place the foods at the order pickup area for the Frontline Staff to pickup.

Deliver

Order

The Frontline Staff will then pick up the foods from the order pickup area and deliver it to the respective Customer.

Confirm

Order

The Customer, upon receiving the foods, will check to ensure that the foods received is what they had ordered.

Figure 3.8 – Text Description of “B2: Change Order” Use Case

73

73


Text Description for “B5: Make Payment” Use Case:

Name: B5: Make Payment Business Use-Case

Brief Description:

In this use case, the Customer request for bill. The Frontline Staff will attend to the Customer request and will calculate the total based on what was ordered. The Frontline Staff will ask for the payment and the Customer will give cash to the Frontline Staff. He/she then takes the cash to the Cashier Staff. The Cashier Staff will process then payment and returns the change and receipt to the Frontline Staff. The Frontline Staff then takes the change and receipt to the Customer, who then confirm the receipt and leaves the restaurant.


Precondition:

The Customer must be in the restaurant and seated around a table and had already ordered. In addition, the orders must have already been served.

MAIN FLOW


Request Bill The Customer request for the bill. This will happen only when the Customer had previous ordered and that the orders had been served.

Calculate

Total

The Frontline Staff calculate the total payable based on the dishes on the table. This is usually calculated manually by the individuals.

Request

Payment

The Frontline Staff request for payment from the Customer.

Make

Payment

Upon request for payment from the Frontline Staff, the Customer pays the Frontline Staff with cash.

Deliver

Payment

The Frontline Staff will deliver the payment to the Cashier Staff and also the change and receipt to the Customer.

Process

Payment

The Cashier Staff will process the payment where required change is calculated and the receipt is generated for the Customer.

Confirm

Receipt

The Customer receives the change and the receipt. He/she will confirm if all the amounts tallied.

Figure 3.9 – Text Description of “B5: Make Payment” Use Case

73

73


3.3.2 System Use Case Diagram

The system use case diagram is used as a platform in defining the interactions

between the system and the users. This will provide a common ground of understanding

of the system between the users and the developers. As such, it is commonly used to

specify the requirements of a system as it is simple to understand and easy to use.

As with the business use case diagram, the first step of creating the system use

case diagram is also to identify the actors. However, since all the actors were already

identified and defined in the business use case diagram section, there is no need to re-

define them here. For clarity purposes, the identified actors for the system use case are re-

listed below.

1. Frontline Staff

2. Cashier Staff

3. Kitchen Staff

4. Manager

As one can identify just by comparing, there are actually two very prominent

differences between the identified actors for the business use case and the system use

case. The differences are as such:

1. The actor, Customer, is omitted from the system use case diagram.

2. The actor, Manager, is added to the system use case diagram and non-existent

in the system use case diagram.

73

73


The Customer is omitted because there is no direct interaction between the

Customer and the System that will be developed. This is so as the management wanted

the solution, which is to be implemented, to be transparent from the Customer’s

perspective. Thus, there is no need to include them for the system use case diagram.

Another difference is the inclusion of the Manager to the system use case diagram. As the

Manager of the restaurant will be able to access the reporting part of the system,

therefore, they will be included during the creation of the system use case diagram.

With the actors identified, we re-look at the different use cases that were

identified in the business use case diagram and determine if those activities have any

direct interaction with the system. Those without any direct interaction will be omitted

from the system use case diagram.

A number of use cases have been omitted from the system use case diagram.

These use cases are business activities and have no interaction with the system, and

should therefore, not be included. The following are the use cases omitted:

1. B3: Serve Food

2. B3-1: Serve Drink

3. B4: Prepare Food

4. B4-1: Prepare Drink

One use case was identified as part of the system activity that is to be initiated via

the actor, Manager. It is the View Report use case. As noted previously, this is because

the system now enables the Manager to view report anytime they want to. Therefore, it is

essential to include this into the system use case diagram.

73

73


The following diagram shows the full system use case diagram for the solution

that is to be developed.

S1: Order Food

Frontline Staff

S2: Change Order

S3: Make Payment

Cashier Staff

S1-1: Order Drink<extend>

Receive Payment

Receive Payment

Kitchen Staff

Create Order

Receive Order

Change Order

Receive Change

System

Manager

S4: View Report

Figure 3.10 – System Use Case Diagram

73

73


The following is the brief description for each of the use case. This will help to

provide some form of clarity when analyzing the system use case diagram without the

reference to the use case activity diagram and use case text description chart.

S1: Order Food

After the Customer finalizes their order via the Frontline Staff, the Frontline Staff

will proceed to create a new order via the system. When the Frontline Staff

finalize the order, the system will analyze the order and send the order to the

respective kitchen counters. For food orders, the order information will be sent to

the food counter in the kitchen.

S1-1: Order Drink

After the Customer finalizes their order via the Frontline Staff, the Frontline Staff

will proceed to create a new order via the system. When the Frontline Staff

finalize the order, the system will analyze the order and send the order to the

respective kitchen counters. For drink orders, the order information will be sent to

the drink counter in the kitchen.

S2: Change Order

After the Customer finalizes a change of order to the Frontline Staff, the Frontline

Staff will proceed to enter the changes to the system. In order to amend changes

to the system, the Frontline Staff will have to retrieve an existing order by enter

the table number, and then amend accordingly and save the changed order. The

system will analyze the changes and send the changes to the respective kitchen

counters.

73

73


S3: Make Payment

After the Customer passes the payment to the Frontline Staff, the Frontline Staff

will proceed to the cashier counter and pass the payment to the Cashier Staff for

processing. After which, the Cashier Staff will pass the receipt generated and also

the change to the Frontline Staff. He or she will then pass both the receipt and

change to the Customer.

S4: View Report

Whenever the Manager of the restaurant wishes to know the total revenue of the

day or the current amount of money in the till, he/she can do so via the system.

The system allows him/her to view the report without any interruption to the

current operation of the system.

The above system use case diagram describes the interactions between the various

actors and the system. With the identification of the various use cases done, the next step

is to go into more details for the main use cases. The main use cases are the ones that

define the preceding activities which will also describe the activities in the other use

cases as defined in the diagram.

For this system use case diagram, the main use cases are:

1. S1: Order Food

2. S2: Change Order

3. S3: Make Payment

73

73


For each of these main use cases, the system use-case activity diagram is created

for a deeper understanding of the activities flow.

Frpntline Staff

System

Kitchen Staff

Retrieve Order

Display Order

Process Order

Analyze Change

Distribute Change

Frontline Staff

System

Kitchen Staff

Create Order

Record Order

Process Order

Analyze Order

Distribute Order

Enter Changes

Figure 3.11 – “S1: Order Food” Activity Diagram

Figure 3.12 – “S2: Change Order” Activity Diagram

73

73


Frontline Staff

Cashier Staff

System

Deliver Payment

Retrieve Record

Display Record

Enter Payment

Process Payment

Deliver Change

Confirm Change

Figure 3.13 – “S3: Make Payment” Activity Diagram

73

73


Text Description for “S1: Order Food” Use Case:

Name: S1: Order Food System Use-Case

Brief Description:

In this use case, the Frontline Staff creates a new order from the system. After the Frontline Staff completes the entering of order and save the order to the system, the system will record down the order and analyze it. It will then distribute the order to the respective kitchen counter based on the type of food. If it is a food type, it will be sent to the food kitchen counter for processing. If it is a drink type, it will be sent to the drink kitchen counter for processing.

Principal Actor: Frontline Staff

Precondition:

The Frontline Staff must have already had an order ready for entry to the system.

MAIN FLOW


Create

Order

The Frontline Staff will initiate a new order creation via the System. This is possible only when there is a new order ready for entry.

Record

Order

The Frontline Staff will record down the order into the System. This is via selection of different products in the User Interface. The System will capture and store all this details.

Analyze

Order

The System will analyze the order to separate them between the two types of foods; food and drink.

Distribute

Order

The System will then distribute the different foods to the respective kitchen counters for processing by the Kitchen Staff.

Process

Order

The Kitchen Staff will prepare the food via the requests made by the System.

Figure 3.14 – Text Description of “S1: Order Food” Use Case

73

73


Text Description for “S2: Change Order” Use Case:

Name: S2: Change Order System Use-Case

Brief Description:

In this use case, the Frontline Staff first retrieve an existing order from the system to check the order. The System displays the order to the Frontline Staff in order for the Frontline Staff to check. The Frontline Staff then enter the changes and save it to the System. The system will then save the changes and analyze it. It will then distribute the changes to the respective kitchen counter based on the type of food. If it is a food type, it will be sent to the food kitchen counter for processing. If it is a drink type, it will be sent to the drink kitchen counter for processing.

Principal Actor: Frontline Staff

Precondition:

The Frontline must have already had an order change request ready to enter into the System.

MAIN FLOW


Retrieve

Order

The Frontline Staff will retrieve an existing order from the System. This is because there is an order change request made.

Display

Order

The System displays an existing order to the Frontline Staff who requested it.

Enter

Changes

The Frontline Staff enter the changes and save the changes into the System.

Analyze

Change

The System will analyze the order to separate them between the two types of foods; food and drink.

Distribute

Change

The System will then distribute the different foods to the respective kitchen counters for processing by the Kitchen Staff.

Process

Order

The Kitchen Staff will take note of the change requests made by the System and adjust their preparation accordingly.

Figure 3.15 – Text Description of “S2: Change Order” Use Case

73

73


Text Description for “S3: Make Payment” Use Case:

Name: S3: Make Payment System Use-Case

Brief Description:

In this use case, the Frontline Staff takes the payment made and deliver it to the Cashier Staff. The Cashier Staff retrieve the order record from the system and the system will display the record to the Cashier Staff. A lot of information will be shown here, for example, the list of foods ordered and the total amount payable. The Cashier Staff then enters the payment made into the System for processing. The System shows the amount of change and also generates the receipt. The Cashier Staff then pass the change and receipt to the Frontline Staff for verification.

Principal Actor: Cashier Staff

Precondition:

The Frontline Staff must have already had a payment made for the Cashier Staff.

MAIN FLOW


Deliver

Payment

The Frontline Staff delivers the payment made to the Cashier Staff. This is because there is a payment request made.

Retrieve

Record

The Cashier Staff retrieve the order record that is pending payment from the System.

Display

Record

The System displays the record to the Cashier Staff.

Enter

Payment

The Cashier Staff enters the payment received into the System.

Process

Payment

The System will process the payment and generate the required change and the receipt.

Deliver

Change

The Cashier Staff delivers the change and the receipt to the Frontline Staff for verification.

Confirm

Change

The Frontline Staff confirms the change and receipt that they receive from the Cashier Staff.

Figure 3.16 – Text Description of “S3: Make Payment” Use Case

73

73


3.4 Design and Development

The design and development phase is the phase where the requirements are

deciphered and translated into designs and developed into a concrete system. In this part

of the report, there will be various sections that describe and define the different parts of

the project. From hardware implementation to software design, all these will be

documented.

3.4.1 Technologies Used

Numerous technologies were used in this project as each technology used is of a

different context. The client has provided us with their expectation of the solution and

there are certain also certain level of expectation of the solution I provides. Therefore, in

the following paragraphs, I will introduce and explain the technologies choice that I

made.

Windows Client .NET 2.0

The development platform for this whole solution will be based on the .NET

platform. In the literature review, the differences between the .NET web based solution

and .NET window based solution were discussed. Therefore, it will not be discussed

further in this section. The language preference for development is C# due to the level of

familiarity with the language. There are also various reasons why C# is preferred over

VB, however, it will not be discussed here also.

MySQL Server 5.1

73

73


The backend database of choice for this solution is MySQL Server 5.1. There was

a debate over 3 different database products, namely, Microsoft Access, MySQL Server

and Microsoft SQL Server. Eventually, MySQL Server was picked due to several factors.

Both MySQL Server and Microsoft Access are free while Microsoft SQL Server requires

a small amount of fee. In terms of speed, Microsoft SQL Server has an edge over both

MySQL Server and Microsoft Access but since MySQL Server is a better database

product than Microsoft Access and is free, the choice is concluded with MySQL Server.

3.4.2 Database Design

In the development of this solution, the first part was to identify the information

that is required to be captured by the system. From the business use case diagram and

system use case diagram, with the various activities diagram, we can identify the

different information that was required. The information required is then formulated and

presented in the diagram below:

T_ITEM_DTLPKID_ITEMITEM_NAME

ITEM_PRICE

ITEM_NOITEM_BUTTON_NAME

T_ORDER_DTLPKID_ORDERFKID_TRANSACTION

ITEM_NAME

ITEM_NO

QUANTITY

UNIT_PRICE

SUB_TOTAL

IN_CANCEL

TABLE_NO

DT_CREATED

TM_CREATED

DT_LAST_UPDATETM_LAST_UPDATE

T_TRANSACTIONPKID_TRANSACTIONTABLE_NO

TOTAL_COST

IN_PAID

DT_CREATED

TM_CREATED

DT_LAST_UPDATE

TM_LAST_UPDATE

Restaurant Assistant Database Design

1 .. n

1 .. 1contains

Figure 3.17 – Restaurant Assistant Database Design

73

73


As one can identify, there is not a lot of information that is required to be stored

by the system. Most of the focus of this solution will be on the processing of the

information. However, there are certain attributes of this database design that are towards

the system processing and also planted for future usage, such as tracings and debugging

of problems occurred in the system. For these, each of the attributes will be explained in

greater details in the respective data dictionaries.

Data Dictionary: T_ITEM_DTL

T_ITEM_DTL This table stores the products’ information that the restaurant has.

Data Member Name

Description Type Additional Type Information

Default Value

Mandatory? Unique?

ID_ITEM Unique identifier of the item INT(10) Auto Increment NULL YES YES

ITEM_NAME Current Name of the item VARCHAR(255) Min: 1 Max: 255 NULL YES NO

ITEM_PRICE Current Price of the item DECIMAL(18,2) Format: “0.00” “0.00” YES NO

ITEM_NO Business Identifier of the item VARCHAR(3) Min: 1 Max: 3 0 YES NO

ITEM_BUTTON_NAME

UI Identifier of the item VARCHAR(255) Min: 1 Max: 255 0 YES NO

Data Dictionary: T_TRANSACTION

T_TRANSACTION This table stores the transaction information.

Data Member Name Description Type Additional Type Information

Default Value

Mandatory? Unique?

ID_TRANSACTION Unique identifier of the transaction

INT(10) Min: 1 Max: 255 NULL YES NO

TABLE_NO Table number where this transaction is tied to.

VARCHAR(2) Min: 1 Max: 2 NULL YES NO

TOTAL_COST Total cost of transaction DECIMAL(18,2) Format: “0.00” “0.00” YES NO

IN_PAID Indicator if this item has been cancelled

VARCHAR(1) Either ‘Y’ or ‘N’ ‘N’ YES NO

DT_CREATED Record creation date DATE N.A NULL YES NO

TM_CREATED Record creation time TIME N.A NULL YES NO

DT_LAST_UPDATE Record last updated date DATE N.A NULL YES NO

TM_LAST_UPDATE Record last updated time

TIME N.A NULL YES NO

Table 3.18 – Data Dictionary for T_ITEM_DTL

Table 3.19 – Data Dictionary for T_TRANSACTION

73

73


3.4.3 System Design

The system design is tightly coupled with the .NET framework as it defines the

underlying components for all .NET solution. Since I am building this solution with

the .NET framework, the design patterns introduced in this solution will be built on top of

the framework.

The following diagram shows the high level system architecture of the solution.

The architecture shows the different layering of logical partition of the system to

maintain a loosely coupled relationship between each layer. This allows the solution to

Data Dictionary: T_ORDER_DTL

T_ORDER_DTL This table stores the order details of a transaction.

Data Member Name Description Type Additional Type Information

Default Value

Mandatory? Unique?

ID_ORDER Unique identifier of the order (a particular item)

INT(10) Auto Increment NULL YES YES

ID_TRANSACTION Transaction ID tied with this order

INT(10) Min: 1 Max: 255 NULL YES NO

ITEM_NAME Name of item at time of order

VARCHAR(255) Format: “0.00” “0.00” YES NO

ITEM_NO Business identifier of item at time of order

VARCHAR(3) Min: 1 Max: 3 0 YES NO

QUANTITY Quantity of item at time of order

INT(10) Min: 1 Max: 255 0 YES NO

UNIT_PRICE Price of item at time of order

DECIMAL(18,2) Format: “0.00” “0.00” YES NO

SUB_TOTAL Subtotal of the item order (QUANTITY * UNIT_PRICE)

DECIMAL(18,2) Format: “0.00” “0.00” YES NO

IN_CANCEL Indicator if this item has been cancelled

VARCHAR(1) Either ‘Y’ or ‘N’ ‘N’ YES NO

TABLE_NO Table number where this order is tied to.

VARCHAR(2) Min: 1 Max: 2 NULL YES NO

DT_CREATED Record creation date DATE N.A NULL YES NO

TM_CREATED Record creation time TIME N.A NULL YES NO

DT_LAST_UPDATE Record last updated date DATE N.A NULL YES NO

TM_LAST_UPDATE Record last updated time

TIME N.A NULL YES NO

Table 3.20 – Data Dictionary for T_ORDER_DTL

73

73


introduce new modules and packages with ease as integrating new modules or packages

will prove to be easier in this architecture.

Stored Procedures

Centralized Database

Restaurant Assistant System Architecture

.NET Framework 2.0

User Interface Layer

Data Access Layer

Business Logic Layer

Com

mon

Layer

Comm

onHelper Class

DisplayH

elper ClassReceiptH

elper Class

Order UI Cashier UI

Business Logic Class

Data Access Class

Abstract Database Factory Class

Figure 3.21 – Restaurant Assistant System Architecture

73

73


The system is implemented based on a three tier architecture that separate the

data, business logic and user interface logic apart. The separate tiers bring greater

flexibility to the system and allow new modules and packages to be introduced easily.

The following paragraphs will explains each layer and the usage of the layer in greater

details.

In this architecture, there is a centralized database that stores all the information

required by the system. In order to access the database, the software will only be able to

communicate using Stored Procedure. This will enhance the communication with the

database rather than hard-coding the SQL statement directly into the software. Another

added advantage is that maintenance of software is easier as a change in the required

SQL statement just requires a change in Stored Procedure and not the whole software.

This will contain and minimize the changes required to an already deployed system.

The data access layer is an important layer in this solution. This is the layer that

serves as an adapter between the business logic layer and the database. This layer is

implemented using the Database Factory Design Pattern to ensure that a change of

database will not affect the system. For example, if MySQL database server is unable to

scale to the added requirements of the user, there will be a possibility of a change to IBM

DB2 database or Microsoft SQL database. For such changes, the solution has to be built

with such probabilities in mind to ensure that future changes would not requires a re-

design of the codes. The data access class is the class where the business logic class

would directly communicate with. It contains the necessary stored procedure names

where each method will call specifically. The abstract database factory class will deal

73

73


with the type of database call based on the configuration. Therefore, in the future, a

database change is as easy as changing the application configuration to ensure that the

correct connection type is made.

The business logic layer deals specifically to the rules and specifications of the

users, or the business requirements. This layer serves as a processing mechanism of users

input and then re-formulated and sends to the data access layer for storage. It can also

retrieve the required information from the data access layer based on a user’s action and

re-formulate the information to ensure that the users get the kind of information that they

understand.

The user interface layer is the medium where the user will directly access with.

This layer performs typical controls rendering, input validations, action validations and

even controls level access restrictions. This will ensure that the users’ input/action is

valid as the business logic layer do not handles incorrect data. For example, the user

interface layer should ensure that the quantity field should always be numeric and have

no decimal points or even alphabets to ensure that the business logic layer can correctly

process the information. In this architecture, there are two different user interfaces that

are required. One is the order UI and the other the cashier UI. However different they

might be, both of them will access the same business logic component to ensure that all

business rules and requirements are resided at one central component for simpler

deployment and development.

There is also a common layer which is accessible by all the three different tiers. In

this layer, there are three different static classes; The CommonHelper class, the

73

73


DisplayHelper class and the ReceiptHelper class. They serve mainly as utility classes

which performs repeatable actions based on the requests from the accessible layers. The

CommonHelper class performs very generic actions, like DateTime conversion from a

format to another, and even getting a formatted dataset. The DisplayHelper class

performs all action of information display to a display panel. This display panel is

capable of displaying production information, quantity, price and also total cost of

transaction. The ReceiptHelper class controls the printing of all receipts. Accessible

classes that want to generate the different type of receipts can invoke the different

methods of this class.

3.4.4 System Class Diagram

System class diagram shows the relationship and the types of object that the

system haves. It is essential to ensure that the development work will not be full of

questions as development can be hindered if the design is not mapped out properly. The

diagram on the next page shows the system class diagram.

73

73


BusinessClass

dataAccess: DataAccessLayerreceiptHelper: ReceiptHelpercommonHelper: HelperClassdisplayHelper: DisplayHelper

Figure 3.22 – Restaurant Assistant System Class Diagram

DataAccessBase

_database : Database

DataAccessBase()

_sectionHandler : DatabaseFactoryConfiguration

DatabaseFactory

DatabaseFactory()CreateDatabase()

DatabaseFactoryConfiguration

Name: StringConnectionStringName: StringConnectionString: String

MySQLDatabase

CreateConnection()CreateCommand()CreateOpenConnection()CreateStoredProcCommand()CreateParameter()CreateAdapter()

DataAccessLayer

RetrieveAllItemsInformation()GetTotalSales()CreateNewTransaction()CreateNewOrdersForTransaction()CreateNewOrderForUpdateTransaction()UpdateOrderForUpdateTrasaction()UpdateTransactionTable()ResetTransactionForTransafer()UpdateTableNo()RetrieveTransactionID()RetrieveOrderListOnTransaction()CheckTableAvailable()UpdatePaidIndicatorInTransaction()

ReceiptHelper

_printHeaderFont: Font_printBodyFont: Font_printFooterFont: Font_printChefFont: Font_printerName: StringdsReceiptForChef: DataSetdsReceiptForCustomer: DataSetdsMonthlyRepor: DataSet_monthlyTotal: double_dblTotalReceived: double

ReceiptHelper()PrintReceiptForCustomer()PrintMonthlyReport()PrintReceipt()PrintReceiptForChef()PrintReceiptForChefModified()

<<type>>Database

connectionString : String

CreateConnection()CreateCommand()CreateOpenConnection()CreateStoredProcCommand()CreateParameter()CreateAdapter()

DisplayHelper

DisplayMessage()DisplayAmountPayable()DisplayChangePayable()DisplayDefaultMessage()

HelperClass

GetNewOrderListDS()GetTransInfo()GetMonthlySales()GetDatabaseDateFormat()IsPrimaryKey()

CasherUI

Controls Variables

Controls Methods

OrderUI

Controls Variables

Controls Methods

73

73


3.4.5 User Interface Design

In this section, I will describe the user interface design process and how the

design will help the users of the application to use the system more easily. As noted in the

system architecture, there are two different user interfaces that existed in this system. One

is the Order UI and the other, the Cashier UI. The most frequently used interface would

be the Order UI as this interface is the trigger point of all orders.

Order User Interface

This initial design took into a few considerations which is important for the

design of this user interface. These are the few factors:

Food CategoriesP

anelFood Selection Panel

Logo/Restaurant Name/System Name

Food Categories

Table Entry Panel

Selected Items Panel

Buttons Panel

Figure 3.23 – Ordering User Interface Concept Design

73

73


1. Ability for the user to search and select items at ease.

2. Ability for the user to manipulate with the quantity fast.

3. Ability for the user to find and amend an existing order at ease.

As a point to note, this user interface will be used with a touch screen monitor. In

this case, the items for selection have to be large enough to ensure that the user can select

the intended item with ease. Therefore, almost all the controls in this user interface are

built in larger size and the fonts are made more obvious to ensure the factors are fulfilled.

The screenshot below shows the actual implemented user interface.

Table selection panel:- Check table orders- Table new orders

Left Button (Change Price)Right Button (Reduce Quantity)

Left Button (Cancel Current New Order)Center Button (Update Changes)Right Button (Commit New Order)

Quantity Panel:- Set quantity of an pre-chosen item

Figure 3.24 – Ordering User Interface

73

73


The language used in this system is Chinese as almost all the staffs are not

English literate. There is also this quantity panel below that is used to set the quantity of

the item selected. This functionality was requested by the user after deployment as they

do not wish to click the button like 10 times if a Customer orders 10 quantities for an

item.

The Change Price button will invoke a new window for user to enter the new

price for a particular item. From the screenshot of the program below, it is noted that this

window is also catered for use in a touch screen environment as the button and display

are enlarged. The image below shows the Change Price panel with the main program at

the background:

Left Button (Cancel)Right Button (Confirm)

Figure 3.25 – Ordering User Interface w/ Change Price Window

73

73


Cashier User Interface

The initial design concept was to ensure that the user will be able to use the

program with ease. Therefore, this particular user interface should not be cluttered by too

many controls to avoid complications. There are 5 main panels for this design, mainly the

Table Entry Panel, Items Listing Panel, Manager Panel, Display Price Panel and Buttons

Panel.

The Table Entry Panel allows the user to retrieve the items listing of a particular

order. The user enters the table number associated to the order to retrieve the order

information. The Items Listing Panel list out all the items that is associated to the order

retrieved. The Manager Panel contains all the information that the manager might needs

Table Entry Panel

Items Listing Panel

Buttons Panel

Display Price Panel

Manager Panel

Figure 3.26 – Cashier User Interface Concept Design

73

73


to know. The Display Price Panel tells the user the total price of the order, cash received

and change payable to the Customer. Lastly is the Button Panel where all the buttons to

invoke various function to end order, create receipts is resided at.

The screenshot below shows the implemented user interface for cashier.

Check Total Amount in Till. (For Today)

Top Textbox- Total AmountMiddle Textbox- Amount ReceivedBottom Textbox- Change Payable

Top Button (Print Reciept)Bottom Button (End Order)

Figure 3.27 – Cashier User Interface

73

73


3.5 Implementation

The implementation of the whole system, after development and testing, to the

restaurant was a challenge. There were many factors to consider and very little

timeframe. The following lists the factors that were under consideration and how the

resolutions were concluded for each of these factors.

1. The system can only be implemented and set up the day before the

restaurant is ready for re-open. We have only one day.

2. The staff in the restaurant has yet been taught on the usage of the system.

They can only learn while being on the job.

3. Although the manager has seen the system prior to implementation, the

system has yet to be tested in the real environment. This increases the risk

of failure when different users use the system differently.

Although we had only one day to implement the whole system in the restaurant, it

was actually sufficient. The whole implementation process from the installation of the

hardware; servers, touch screen monitor, receipt printer, display panel, printers, router,

CPUs, to the set up of software components; database set-up, software configuration, and

other hardware configurations, took five hours. During this process, all relevant

components were tested to ensure that it is working as intended.

The next concern is the staff training on the usage of system. With only three

hours of allocated time for training, we have to ensure that they understand the impact of

73

73


the system to the business process. There will be a slight change in the business process

since the roll out of the system to ensure optimal efficiency to the business. From the

order UI to the cashier UI, the staffs were taught to the comprehensive usage of the

system. However, during our support of the system on the first day of implementation,

we still encounter many questions on the usage of the system by the staffs.

The last concern is the business continuity portion when the system fails during

the operational hours of the business. This was discussed with the managers and we came

out with the conclusion that the pre-system implementation business process will be

triggered in the event the system fails to function as intended. This will minimize the

impact to the business. In addition, we were given a maximum of three hours to bring the

system back to the intended states in the event it fails.

73

73


3.6 Testing and Integration

The testing and integration of different technologies/components were done

throughout the development phase and also the implementation phase. Each different

components, receipt printer, display panel, cashbox, touch screen monitor and router

were tested for workability and integrated to ensure compatibility with the software.

The software modules were developed and tested for functionalities as each

modules development end. It was a progressive testing method whereby new modules

being developed were then subsequently tested with other parts of the modules. This

regression testing ensures that the new modules do not impact and break the other

modules that were already developed.

However, at the end of the whole development phase of the software, a complete

and thorough testing is to be executed to ensure the workability of the various modules of

the software and also the integration with the hardware. For the software, the test strategy

was to make use of the use case to test the system, also known as use case testing. Such

testing ensures that the requirements as approved by the users, are all working as

intended on the system to be delivered.

The below lists all the function to be tested based on the system use case:

1. S1: Order Food

2. S1-1: Order Drink

3. S2: Change Order

4. S3: Make Payment

5. S4: View Report

73

73


3.6.1 Test Cases

Test cases for: System Test Cases- S1: Order Food- S1-1: Order Drink Description:This test case is for testing of the relevant system use case for the ordering functionality.Other Information:NIL.

Test Case ID Pre-Condition Condition Expected Result

S1#001 Table Panel is enabled. User is able to choose the intended table identifier.

System displays the table identifier at the textbox.

S1#002 Table Panel is enabled.

User selected an intended table identifier.

User is able to clear the intended table identifier by clicking the “Clear” button.

The table identifier at the textbox is no longer being displayed.

S1#003 Food Categories Panel is enabled.

Items Selection Panel is enabled.

User is able to select the different category and the items of the selected category are reflected at the Items Selection Panel.

Selected Category is highlighted in blue and the buttons at Items Selection Panel are reflected with items from the selected category.

S1#004 Food Categories Panel is enabled.

Items Selection Panel is enabled.

User is able to choose the item that they wish to select.

On selection, the information is recorded at the Selected Items Panel.

S1#005 Records exist at Selected Items Panel.

User is able to change the quantity of an existing selected item. They can reduce the quantity by pressing the “Reduce Quantity” button or increase by clicking on the same item again.

Quantity of the selected item reflected in the Selected Items Panel is as intended by the user.

S1#006 Item ID has a prefix of X and exists at Selected Items Panel.

User is able to change the price of an existing selected item. They can change the price by selecting on an item in Selected Items Panel and clicking on the “Change Price” button.

Price of the selected item reflected in the Selected Items Panel is as intended by the user.

73

73



User is able to cancel the whole order. They can do this by clicking on the “Cancel” button.

Selected Items Panel is cleared.

Table ID selection is cleared.


“Commit” button is enabled.

User is able to commit the whole order. They can do this by clicking the “Commit” button.

System response with a confirmation.

If the table ID is taken, the system response with an error message.

System sends the order to the respective kitchen stations. The notification is in the form of a print.

Test cases for: System Test Cases- S2: Change OrderDescription:This test case is for testing of the relevant system use case for the ordering functionality.Other Information:Most of the essential test cases are already reflected in the test case for S1: Order Food, S1-1: Order Drink. Those test cases will be omitted in this test case description.




User is able to retrieve the order information by clicking on the “Check” button.

System retrieves the order information and populates the Selected Item Panel.


User is able to cancel the whole change order request. They can do this by clicking on the “Cancel” button.

Selected Items Panel is cleared.

Table ID selection is cleared.


User is able to commit the whole change order request. They can do this by clicking the “Update” button.

System response with a confirmation.

System sends the change order to the respective kitchen stations. The notification is in the form of a print.

Table 3.28 – Test Case Description for “S1: Order Food” Use Case

Table 3.29 – Test Case Description for “S2: Change Order” Use Case

73

73


Test cases for: System Test Cases- S3: Make PaymentDescription:This test case is for testing of the relevant system use case for the cashier functionality.Other Information:NIL.


S3#001 Table Panel is enabled. User is able to choose the intended table identifier.




User is able to clear the intended table identifier by clicking the “Clear” button.

The table identifier at the textbox is no longer being displayed.

The Selected Item Panel and the Display Price Panel are also cleared.



User is able to retrieve the order information by clicking on the “Check” button.


The total amount of the order is also calculated and displayed to the user.

In addition, the Display Panel will display the total amount payable.

S3#004 User has retrieved an order based on the table identifier.

User is able to print the receipt of the order by clicking the “Print Receipt” button.

System prints the receipt in accordance to the Selected Item Panel with other necessary information.

S3#005 User has retrieved an order based on the table identifier.

User is able to input the amount received and finalize the order by clicking the “Bill” button.

System output the change payable on the textbox.

In addition, it also prints the receipt, display the change payable at the Display Panel and eject the cashbox.

Table 3.30 – Test Case Description for “S3: Make Payment” Use Case

73

73


Test cases for: System Test Cases- S4: View ReportDescription:This test case is for testing of the relevant system use case for the reporting functionality.Other Information:NIL.


S4#001 NA. User is able to select the “Check total amount in tills” button.

System prompts the user to enter the password.

S4#002 The “Enter Password” window is active.

User is able to enter the password.

1) User enters a wrong password.

2) User enters a correct password.

1) The system prompts the user an error message.

2) The system displays the total amount in tills.

Table 3.31 – Test Case Description for “S4: View Report” Use Case

73

73


Chapter 4: Project Evaluation and Conclusion

4.1 Project Evaluation

Having been through the whole software development life cycle, the Restaurant

Assistant Solution was able to be deployed and used in a real world environment for three

months now. There were some slight issues at times but were all not related to the

software. These problems include disabled network connection, loose network cables,

printer out of paper and also the stuck cashbox.

In order to measure the success of this project, the project objectives that were set

in the beginning phase were re-visited. The objectives will be evaluated against whatever

that were created and deployed. The following are the objectives and also the evaluation

of each objective.

To research and gain more domain knowledge in terms of the food service

industry. For this objective, the research was on the various different types of restaurants

and the way they performed their business. At the beginning of the project, during

requirement elicitation, analyses were made on their business processes. Discussions

were also made to ensure that the owners are comfortable on how the system can help

them and how it changes their business process to the better. From whatever was done,

this objective has been fulfilled.

To research on the existing n-tier system architecture and software design

patterns for the solution. Various system architecture and software design patterns were

examined and researched for possibilities on integrating into the software solution. The

73

73


implemented solution used the three tier architecture along with various software design

patterns. This has allowed the solution to be expandable and scalable as intended. With

all that was done, this objective has been fulfilled successfully.

To research on existing technologies that can be used to create the solution

and other tools that has the likelihood to integrate into this project. Various

technologies were looked at during the literature review phases. All that were taken into

consideration were evaluated and then with their pros and cons weighted. The concluded

tools and technologies were also used and implemented in this project. Therefore, with all

that was done, this objective has been fulfilled.

To design and create a user interface using usability engineering that will

enhance users’ experience when dealing with the application. The user interfaces that

were implemented were all used by the users with ease. They were able to learn it and

understood the different parts of the user interface with ease. These prove that the design

of the user interface did enhance their experiences when using the application. Therefore,

with all that was done, this objective has been fulfilled.

To learn and develop the solution using three-tier application architecture to

enhance components' reusability. As with the application architecture that was created,

the whole solution was developed using three-tier application architecture. The learning

process and designing process was tedious but it was worth well as the separation of logic

allows future modules integration. Therefore, this objective has also been fulfilled

successfully.

73

73


To implement the solution to the targeted restaurant successfully without

any interruption to the existing business. The solution was implemented at the given

timeframe without any hiccups. The training was given to the staff, although some of the

staffs are still not able to learn quickly. Interruption to existing business process was

minimal although there are still some staffs that are not used to the new process.

Therefore, I reckon this objective to be fulfilled successfully also.

4.2 Future Enhancements

However comprehensive a system to be, there will bound to be somewhere that

can be further enhanced or improved. This goes the same for the system that was

developed. A lot of functionalities were given a thought but was not implemented due to

its non-existence in the user requirements. The following is the list of future

enhancements that were both discussed with the owners.

1. Using mobile devices, like PDAs, to take order instead of the allocated touch screen

monitors. This will further enhance the business efficiency.

2. More comprehensive reporting functionalities. There is only one function, which is to

view the total amount in tills. This will give the managers a better overview of the

business.

3. More functionality to both the cashier and the ordering programs. This will give the

users more alternatives to deal with other special scenarios that were not discussed in

the user requirements.

73

73


4.3 Conclusion

Although the solution was deployed to a real world environment, it still lacks

some functionality that was necessary to handle scenarios that was not in the users

requirements. Other than that, the solution has been working as intended. All

requirements were met and the owners were very satisfied with the solution and also the

services that were provided to them. There was a one day on site support to ensure that all

issues were resolved quickly.

A lot was learnt during this whole project, from the project proposal, to

requirements elicitation and finally, to solution implementation. Knowledge was the most

obvious gain. I was exposed to more technologies and methodologies. In terms of other

aspect, I learnt to handle the users and also the trainees. For the solution, there was a

dateline to meet. Therefore, time management was also very critical in this whole project.

I learnt that by following tightly to a time plan, which was planned with sufficient

buffers, one will then be able to deliver the project on time with much better success.

The technical knowledge that was gained during the project allows me to

implement the required skills into other projects. The business knowledge gave me the

experience to deal with future clients. Project management knowledge allows me to know

the different critical parts of the project and will help when I am given more projects to

manage in the future. With that, I conclude that it has been a wonderful journey to

manage and implement this project. I give my sincerest gratitude to University of Wales,

Informatics and the restaurant owner, for giving me the chance to work and handle on

this project. Thank you.

73

73


References

.NET Framework. (2004). In Wikipedia, the free encyclopedia. Retrieved February 10, 2009, from http://en.wikipedia.org/wiki/.NET_Framework

Castelli, D. & Pagano, P., (2003). A system for building expandable libraries. Proceedings of the 3rd ACM/IEEE-CS joint conference on Digital libraries. 335 – 345. Retrieved from The ACM Digital Library database.

Duell, M., Goodsen, J. & Rising, L., (1997). Non-software examples of software design patterns. Addendum to the 1997 ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications (Addendum), 120 – 124. Retrieved from The ACM Digital Library database.

Faraday, P. & Becker, B. (2009). Deciding When To Adopt Windows Presentation Foundation. Retrieved February 23, 2009, from http://windowsclient.net/wpf/white-papers/when-to-adopt-wpf.aspx

Garlan, D., (2000). Software Architecture: a Roadmap. Proceedings of the Conference on The Future of Software Engineering, 91 – 101. Retrieved from The ACM Digital Library database.

Garlan, D. & Shaw, M., (1993), An Introduction To Software Architecture. Advances in software engineering and knowledge engineering vol 2. World Scientific.

Grisham, G., (2002). The Need For Three-Tier Architecture. Retrieved October 03, 2008 from http://basis.com/advantage/mag-v6n2/threetier.html

Khosravi, K & Gueheneuc, Y.G., (2004), A Quality Model for Design Patterns. Retrieved from Google Scholar database.

Ng, T.H., Cheung, S.C., Chan, W.K &, Yu, Y.T., (2006), Toward effective deployment of design patterns for software extension: a case study, Proceedings of the 2006 international workshop on Software quality, 51 – 56. Retrieved from The ACM Digital Library Database

Meyer, B., (1988), Object-Oriented Software Construction, Prentice Hall.

Primary Objects. (2009). Primary Objects – Implementing a Database Factory Pattern in C# ASP.NET. Retrieved January 09, 2009, from http://www.primaryobjects.com/CMS/Article81.aspx

73

73


Ram, D.J, Raman, K.N.A & Guruprasad, K.N., (1997), A Pattern Oriented Technique for Software Design, Software Engineering Notes 22(4), Retrieved from The ACM Digital Library database.

Richter, J. (2002), Applied Microsoft .NET Framework Programming, Redmond, Washington: Microsoft Press.

Selvaraj, A.R & Ghosh, D, (1997). Implementation of a database factory. ACM SIGPLAN Notices Volume 32, Issue 6, 14 – 18. Retrieved from The ACM Digital Library database.

Smith, J. (2007). WPF vs. Windows Forms. Retrieved Feburary 12, 2009, from http://joshsmithonwpf.wordpress.com/2007/09/05/wpf-vs-windows-forms/

Sun Microsystems, Inc. (2002). Design Patterns: Composite View. Retrieved January 10, 2009, from http://java.sun.com/blueprints/patterns/CompositeView.html

73

73


Appendices

Appendix A: Screen Capture of Different Software Interfaces

Appendix A-1: Cashier User Interface

Appendix A-2: Change Price Window

73

73


Appendix A-3: Cashier User Interface

Appendix A-4: Daily Sales Windows

Appendix A-5: Sales Report Window

73

73


Appendix B: Pictures of Different Devices That Were Used

Appendix B-1: Customer Display (Black), VFD2029

Appendix B-2: Cash Drawer (Black), RJ11

Appendix B-3: TYSSO Thermal Receipt Printer (Black), PRP-085IIIT

73

73


Appendix B-4: 1515L Multifunction 15” LCD Touchmonitor

73

73


Appendix C: Screen Capture of Different Receipts Generated

Appendix C-1: Receipt Notification for Chefs (Original and Amended)

Appendix C-2: Receipt for Customers (Before Payment and After Payment)

Documents

Tan Yuan Hua