tan yuan hua
TRANSCRIPT
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
6. To implement the solution to the targeted restaurant successfully without any
interruption to the existing business.
4
4
4
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
1.4 Time Plan
4
4
4
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
73
73
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
Figure 3.3 – Business Use Case Diagram
73
73
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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.
Principal Actor: Customer
Precondition:
The Customer must be in the restaurant and seated around a table and had already ordered.
MAIN FLOW
Step Name Description
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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.
Principal Actor: Customer
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
Step Name Description
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
Step Name Description
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
Step Name Description
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
Step Name Description
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
S1#007 Records exist at Selected Items Panel.
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.
S1#008 Records exist at Selected Items Panel.
“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.
Test Case ID Pre-Condition Condition Expected Result
S2#001 Table Panel is enabled.
User selected an intended table identifier.
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.
S2#002 Records exist at Selected Items 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.
S2#003 Records exist at Selected Items Panel.
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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.
Test Case ID Pre-Condition Condition Expected Result
S3#001 Table Panel is enabled. User is able to choose the intended table identifier.
System retrieves the order information and populates the Selected Item Panel.
S3#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.
The Selected Item Panel and the Display Price Panel are also cleared.
S3#003 Table Panel is enabled.
User selected an intended table identifier.
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.
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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.
Test Case ID Pre-Condition Condition Expected Result
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
Appendices
Appendix A: Screen Capture of Different Software Interfaces
Appendix A-1: Cashier User Interface
Appendix A-2: Change Price Window
73
73
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
Appendix A-3: Cashier User Interface
Appendix A-4: Daily Sales Windows
Appendix A-5: Sales Report Window
73
73
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
Appendix B-4: 1515L Multifunction 15” LCD Touchmonitor
73
73
University of Wales, UKThe Food Service Industry: A Highly Expandable IT Solution
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)