The fast food restaurant

(1)

The fast food restaurant

A case study for modelling business process using ABS

Aravinth A. Sivalingam

Thesis submitted for the degree of

Master in Informatics: programming and networks 60 credits

Institutt for informatikk

Faculty of mathematics and natural sciences

UNIVERSITY OF OSLO

(2)

(3)

The fast food restaurant

A case study for modelling business process using ABS

Aravinth A. Sivalingam

(4)

http://www.duo.uio.no/

Printed: Reprosentralen, University of Oslo

(5)

The fast food restaurant

Aravinth A. Sivalingam July 31, 2018

(6)

(7)

Abstract

Nowadays there is an increasing amount of technology used to improve businesses. An important aspect of the business is planning on how to use available resource effectively to gain profit. As an example of a business scenario, we present a fast-food restaurant that has to plan the number of staff required based on an estimation of the amount of orders. An effect of bad or no plan would result in either later delivery times or even loss of profit due to human resources issues, which could result in a negative reputation for the restaurant.

To study this problem a model will be developed, which can be used to plan the amount of staff based on an estimated number of orders. We also investigate if properties from distributed architectures such as concurrency, fault tolerance and scalability can be incorporated when planning business process.

The model created was developed in ABS (a language for distributed and object-oriented models with Java like syntax). This gave a rough sketch on how could be planned for an estimated number of orders. The model also provided statistics such as predicted successful delivery rates based on available human resources and client workloads. From a business per- spective, this could be used to find out a good balance between human resources and profits.

(8)

(9)

List of Figures

2.1 Architecture of the ABS language[13] . . . 5

2.2 Architecture of distributed monitoring by Irimie Bogdan . . 16

3.1 Architecture of the fast-food restaurant business process . . 25

3.2 Sequence diagram of business model system . . . 28

4.1 Database table structure . . . 37

5.1 Before duplicate order . . . 51

5.2 Duplicate order result . . . 52

5.3 Overlapping Test . . . 53

5.4 Overlapping Test result . . . 53

5.5 Before theManagerand theDelayQueue . . . 54

5.6 Multiple overlapping Test result . . . 55

5.7 Multiple overlapping test result . . . 56

5.8 How it comes into theManagerand theDelayQueue . . . 57

5.9 Possible Solution . . . 58

5.10 How it comes into theManagerand theDelayQueue . . . 59

5.11 Possible solution for the result 2 . . . 59

6.1 Divide the componentChef . . . 72

6.2 BPMN diagram – Pizza Takeaway (Online ordering) . . . 77

(14)

(15)

List of Tables

5.1 20 client test results part 1 . . . 62 5.2 20 client test results part 2 . . . 63

(16)

(17)

Preface

I would like to thank Grefsen High School who gave me a kick start on life, known as Nydalen High School now. I would like to say thank you to Nor- way that has an excellent education opportunity for anyone who wants to study. That made me have the chance to try out Programming and Net- working. This gave me a nice start to my career.

My interest in computer science started at second-year at the university.

That made me try to find out more. Today, I’m here and finished the master degree. During my study time, I have had many new friends. I am proud of many of them. I look up to be in touch with them in the future.

Thanks for all good friends.

Finally, I would like to thank my parents who have always supported me and who still do it for all the choices I take. They are a gift for me from God.

Thank you to my brother, who is the happiness in my family. He makes the house warm by laughter. Thank you for all the arguments we have had, Ayanthan.

Ara says:

There is no easy life, if you don’t believe in you. You are the one can solve everything, if you want to.

(18)

(19)

Part I

Introduction

(20)

(21)

Chapter 1

Introduction

Any system in which a number of independent interconnected components can cooperate in order to achieve a common goal[4], is a distributed system. The purpose of a distributed system is scalability and availability. Scalability is the ability to grow by adding extra components to the system[14]. This is with the intention to accumulate the system for more processing and storage.

Availability is represented by how ready the system is to commit to a task when needed.

A business process is defined as "a set of logically related tasks performed to achieve a defined business outcome". Processes have two important charac- teristics. They have customers and they cross organizational boundaries.

An example of a business process could be «ordering goods from a sup- plier» among others. Business needs good planning. Better planning leads to more gain and reduces risk. Considering groceries stores as an example, they need good planning to automate the ordering of the goods. The stores can save time with an automatic ordering system. An ideal system will check the amount of supplies in the store. By using prediction and models, the system must order more supplies to receive them at the right time. An- other example would be calculating the best possible rule for all deliveries during needed times.

The problem in this thesis will be to investigate if a language to model distributed systems, fits for planning business process models.

In this thesis, we develop a case study based on a busy Fast-food restaurant with a combination of subscriber(regular) and drop-in customers, who order sandwiches. It is difficult for such a restaurant to plan when and what orders are to be carried out to get better results. An outcome of the system will be that customers receives their orders within the agreed time. The restaurant aims to deliver freshest sandwiches. When the sandwiches in the order are made, it shall be delivered to the customer at once.

A Fast-food restaurant business includes a logistic issue. Logistic is the knowledge of planning, managing and organizing product and informa-

(22)

tion flow in business or the military[9]. The architecture of the system that is being made for this sandwich restaurant can be seen as a solution for other business owners who have logistics measures.

(23)

Chapter 2

Background

2.1 ABS

ABS stands for abstract behavioral specification, andis a novel language for modeling distributed, object-oriented systems at an abstract, yet precise level[13].

This language has been build to support the modelling of concurrent and distributed systems. The ABS language has a syntax similar to Java and that implies Java developers can understand this language easier.

The architecture of ABS has been separated by different layers as illustrated in figure 2.1.

Figure 2.1: Architecture of the ABS language[13]

2.1.1 The function layer

The function layer is split into algebraic data types and functions.

(24)

Algebraic data types

The predefined datatypes in ABS are Bool, Int, String, Unit and generic list.

Bool is same as Boolean in Java. It has true or false as values. Int stands for integer and have values asZ={.., -2, -1, 0, 1, 2, ..}. The string syntax is the same as in the other programming language. TheUnitsyntax is a type of the function, and have no return.Unitis similar tovoidin Java.

ABS has the opportunity to create its own datatypes. This is useful when one needs different constructors with accessory functions.

Example 1

1 d a t a C o u r s e = C o u r s e ( I n t c o u r s e I d , S t r i n g courseName ) ;

d a t a P e r s o n = S t u d e n t ( I n t s t u d e n t I d , S t r i n g studentName , L i s t <

Course > l ) | P r o f e s s o r ( I n t e m p l o y e e I d , S t r i n g employeeName , I n t d e p a r t m e n t I d , L i s t <Course > l ) ;

Coding/data_type.abs

The Example 1 shows how user-defined data types can be used. A person can be a Student or a Professor in this example. Both constructors are different, but both represent a person. These constructors also contain accessor functions such asemployeeIdorstudentId.

Functions

The signature of a def-function is: def [type] [function name](...parameters...) = ... ; The example 2 shows how to define a function without a object. This

function check whether the person is a student or not.

Example 2

module S c h o o l ;

2

d e f B o o l i s S t u d e n t ( P e r s o n p ) = c a s e p {

4 S t u d e n t ( _ , _ , _ ) => True ;

_ => F a l s e ;

6 } ;

Coding/function_boolean_defined.abs

2.1.2 The OO-Imperative Layer

This layer is divided into the imperative language and the object model.

The object model

To access an object in ABS, it is necessary to implement an interface on the class. The following example shows how an object in ABS is declared:

i n t e r f a c e Person { S t r i n g getPersonName ( ) ; }

2 i n t e r f a c e Student extends Person { I n t g e t S t u d e n t I d ( ) ; } i n t e r f a c e Course {

4 S t r i n g getCourseName ( ) ;

(25)

S t r i n g getCourseCode ( ) ;

6 }

c l a s s S t u d e n t C o u r s e R e g i s t r a t i o n ( S t r i n g personName , I n t studId , S t r i n g courseName , S t r i n g courseCode ) implements Student , Course {

2 S t r i n g getPersonName ( ) { r e t u r n personName ; } I n t g e t S t u d e n t I d ( ) { r e t u r n studId ; }

4 S t r i n g getCourseName ( ) { r e t u r n courseName ; } S t r i n g getCourseCode ( ) { r e t u r n courseCode ; }

6 }

If a method is not listed on the interface of an object, then there it is not ac- cessible to these methods from other classes. InterfaceStudenthasgetStu- dentId()method, but it also includes getPersonName, because it is extends from interfacePerson. InterfaceStudenthas two methods, which aregetStu- dentId()andgetPersonName().

The data type can be also used to represent data structure. If the object does not need to have new functions but only hold on variables, then the data type declaration is a simple choice. The example 1(on page 6) shows Course and Person are implemented and have no functions.

Every class declaration has the opportunity to define aUnit run()method.

This method is run automatically when the object is created.

The imperative layer

ABS hasstatementsas assignment, while-loops, conditionals, synchronous and asynchronous method calls, method return, await, suspend, case, get and skip[13]. The example below will show how some statement works.

Customer findCustomer ( CustomerList c l ) {

2 Customer r e s u l t ;

I n t i = 0 ; /* d e c l a r a t i o n */

4 while( i <l e n g t h( c l ) ) { /* while loop with c o n d i t i o n a l */

Customer curCust = nth ( c l , i ) ; /* assignment */

6 I n t c u r I d = curCust . g e t I d ( ) ; /* synchronous method c a l l s

*/

i f ( i d == c u r I d ) { r e s u l t = curCust ; }

8 i = i + 1 ;

}

10 r e t u r n r e s u l t ; /* r e t u r n s t a t e m e n t with r i g h t type " Customer "

*/

}

Communication with an object can be done as below.

1 I n t c u r I d = curCust . g e t I d ( ) ; /* synchronous method c a l l s */

(26)

This method returns the of the object of type Customer. Field on an object are automatically private. To access a field from an object, it needs get methods or set methods for reading or writing in a field of the object. From the example above, the getId() method would be a get method.

Methods are implemented using blocks of code inside curly braces within a sequence of declaration and statements.

1 {

Customer c = new CorpIndvCustomerImpl ( 1 7 ) ;

3 Customer d = new CorpIndvCustomerImpl ( 1 6 ) ; CustomerList l = Cons ( c , Cons ( d , n i l ) ) ;

5 Customer e = c . findCustomer ( l ) ; }

The concurrency Layers

ABS is built for concurrency. By initializing a class we automatically create a thread. ABS handles multitasking usingconcurrent object group (COG).

COG is a collection of tasks that use common thread. It is such that only one task is active, while the other tasks care suspended.

The communication in ABS is divided into two method calls, synchronous and asynchronous. The synchronous method calls are used when method B called by method A and it is a dependent execution of method B to continue method A. The syntax of the synchronous method calls is following, target.method(args1, args2,...). Target is the object of the method.

The asynchronous method calls are the opposite of synchronous method calls, that means it is independent method calls. If method B is called by method A, but method A has no need to wait for method B to complete, then method A can call B asynchronous call. This will make method A to call method B and continue to perform method A, regardless of method B is finished or not. The system will ensure that method B will be executed by so-called COG system. The syntax for asynchronous method calls istar- get!method(arg1, arg2,...).

In the implementation of the system, there has been used statements like await, time, class, import and export. Await statement was used for syn- chronizing with another process the system requires from. ABS has its own time unit with statement time. ABS is an object-oriented language with similar Java syntax. ABS language follows the same structure for the class statement in Java language. If function calls required to be performed from another object than that self, an interface with function signature of that function to be to called must be implemented. See code example 3.

Example 3

i n t e r f a c e DB {

2 F i l e g e t F i l e ( F i l e n a m e f I d ) ;

(27)

}

4

c l a s s D a t a B a s e ( Map< F i l e n a m e , F i l e > db ) i m p l e m e n t s DB {

6 F i l e g e t F i l e ( F i l e n a m e f I d ) { r e t u r n l o o k u p ( db , f I d ) ;

8 }

}

Coding/Interface.abs

Import and export is important when it’s comes to functions’ call from other class. All ABS definitions (classes, interfaces, functions data types, type aliases) are contained in modules[1]. So the module is exported and imported when used. Then you can use that class from the module from another class/module.

Modules

Every ABS file in the system, need to be added with module declaration on the first line of the file. This module declaration can be used to connect objects, datatype and function from another file. Import and export are the following connectors between files. Import used for getting data(object, datatype and function) and export is to give availability to these data(object, datatype and function). So then it is possible to call a function from another file from one another file. The following example, On file 1:

1 module School ; e x p o r t * ;

On file 2:

module T e s t ;

2 import * from School ;

The shown example, there is used import *, which means it import all available data(object, function and datatype). Export * means export all data(object, function, datatype). But it is possible to import just what one needs and what one needs to be export from the file.

2.1.3 How to run ABS?

It is important to mention how to run ABS on a machine. To set up the ABS on an Ubuntu machine, it needs minimum java 8 JDK, ant build tool, git and the language Erlang, where the version is minimum 18. To be on the comfort zone is recommend to have latest java JDK and latest Erlang version. It takes more time to setup ABS for every new machine which was used. Therefore I built a bash script to auto setup ABS on the machine which uses Ubuntu/Linux as the operating system.

(28)

Example 4 ¹

# ! / b i n / b a s h

2

e c h o Welcome t o i n s t a l l i n g a b s c o m p i l e r

4

e c h o ======INSTALL JAVA JDK==========

6 s u d o a p t−g e t i n s t a l l d e f a u l t−j d k −y

e c h o ======COMPLETED− JAVA JDK=======

8

e c h o ======INSTALL ERLANG============

10 wget h t t p s : / / p a c k a g e s . e r l a n g−s o l u t i o n s . com / e r l a n g−s o l u t i o n s _ 1 . 0 _ a l l . d e b

s u d o dpkg −i e r l a n g−s o l u t i o n s _ 1 . 0 _ a l l . d e b −y

12 s u d o a p t−g e t u p d a t e −y

s u d o a p t−g e t i n s t a l l e r l a n g −y

14 e c h o ======COMPLETED− ERLANG========

16 e c h o ======INSTALL ANT===============

s u d o a p t−g e t u p d a t e −y

18 s u d o a p t−g e t i n s t a l l a n t −y

e c h o ======COMPLETED− ANT===========

20

e c h o ======INSTALL ABS===============

22 m k d i r −p ~ / S o u r c e cd ~ / S o u r c e

24 g i t c l o n e h t t p s : / / g i t h u b . com / a b s t o o l s / a b s t o o l s . g i t cd a b s t o o l s / f r o n t e n d

26 a n t

cd ~

28 e c h o "\nPATH=$PATH : ~ / S o u r c e / a b s t o o l s / f r o n t e n d / b i n / b a s h " >> . b a s h r c e c h o "\ n a l i a s a b s−run = ’ gen / e r l / run ’ " >> . b a s h r c

30 b a s h

e c h o ======COMPLETED=================

Coding/install_abs.sh To run this file use: sh [filename].sh on the terminal

1https://github.com/aravinthAS/Distributed-resturant-system/blob/master/

Install-ABS-Linux.sh

(29)

2.2 Problem: Case Study

Distributed systems have various types of architectures. An example is client-server architecture, where the service is delivered by a server and used by clients. Another type is a distributed object architecture, where the system is a collaboration between objects and the locations are irrelevant.

In this thesis we focus on the client-server architecture for the implementation of the fast-food case study. This case study is about fast-food restaurants, where the customer can be portrayed as the client and the restaurant as the server. The goal is to help the restaurant to plan their orders. The chefs (manpower) are part of the server, who will perform their work as a task in the system and deliver fresh food to the customer on an agreed time.

Lets look at what planning is needed for a fast food restaurant. They need a way to predict the resources required(goods and staff) to stick to their delivery time. The restaurant is planning to release an IT system. A possible outcome of this development can be an increase the successful delivery rate by 10%. They want to check the impact of that increase for their delivery time.

2.2.1 The link between distributed architecture properties and fast-food restaurant

Characteristic properties of distributed architecture are resource sharing, parallel processes, scalability and fault tolerance[8]. It is interesting to see which of the features fit into a system for the fast-food restaurant. Let’s look at how we can incorporate the properties of distributed architectures within fast-food restaurants.

Openness

The openness of a distributed system is that other services can use this system from remote, e.g., different client programs connect to this system.

The system to be built must be for a particular restaurant and therefore the customer system will be the same. Openness is not important to this case, because of ABS is a modelling language and no other application can not connect to an ABS system. Openness in distributed systems have also the characteristic to add new features to the system.

Concurrency

The distributed system has several components that are connected to each other. Even though these components need to synchronize, they can for most of the time run independently. There may be more of the same type of component, in order to parallelize the work of any part of the processing that the work goes through.

In the fast-food restaurant, there are workers. Compared with distributed

(30)

architecture, the workers are as components. We have more chefs, waiters, and managers. The restaurant has more chefs to do the work faster when they have demand. This behaviour can be compared to the components that are increased on times of higher workloads.

Scalability

The distributed system gives the opportunity to increase or decrease the number of components, without interfering any components in the system. This is called scalability of the system. This is possible when there is no coupling between the components, making the system independent.

That will make the system scalable to add or remove a component in the system. Dependency between components will make it difficult to add new component because the connections between components must be adjusted to the new component. In that case the system will not be scalable.

The fast-food restaurant has unknown number of customers. The system should have the ability to work independently of the number of customers.

If a new customer enters, the system should be able to manage it and not interfere the other parts of the system. If it manages to do it, then it will be seen as the system is scalable. It is the same situation for employees who work at the restaurant. There may be a new employee which will be added to the system without interfering with other workers.

Fault tolerant

The fault tolerant is appropriately in which the system never crash when a subsystem or a component fails. When the subsystem recovers, then it continue its execution from the state after the recovery.

2.2.2 A business process description for a fast-food restaurant The fast-food restaurant has staff including waiters, managers and chefs.

The waiter is the one who receives the order and delivers the order to the customer. This may cause some customers to wait to order because the waiter might have pending orders to deliver. Therefore, this restaurant has decided to have at least one waiter to receive orders and another waiter to deliver the orders.

The customer registers the order at the front desk of the restaurant. An order may have more sandwiches of the same and/or different types. The customer can plan to repeat the same order on defined period of time. e.g., 10 assorted sandwiches each friday of this month to be delivered at 12 a.m.

The time frame between each round can be specified by the customer. For this case study we simplify the selector of ingredients for the sandwich since it is not relevant to a distributed system.

(31)

The waiter will stand at the front desk and receive orders from the customer. These will be delivered to a manager. The manager has the task of planning when the order is going to be carried out by the kitchen and delivered to the customer. The planning will be calculated based on the delivery time it takes to complete the order and how many orders restaurants have left on their waiting list.

When the time to start processing the order arrives, the manager sends the order to a chef who is available in the kitchen. The chef is precise in making orders at the time the manager asks. This is because the manager plans ahead for it. When the chef is done, the order is given to a waiter who serves the food to the customer.

For the customer, a good service relies on receiving their orders fresh and on the agreed time. It is exactly what the goal of any restaurant will be.

Within the expected time, there must be enough staff for every part of process to achieve 100% success rate of the orders. But it is not optimal to fill enough staff for every part of process, when its comes to profit of the restaurant. Every staff should be paid for the work they do.

The new system should help the restaurant to earn money while maintains a high level of service to the customers. The goal of the restaurant should be to reduce staff and earn money, without affecting any orders or customers.

Which tasks that are performed by manpower(staff) can be reduced by the new system?

Number of overlapping orders

When there are many orders who have the same end time of the order, it is impossible to make all orders with the same end time at once. One chef can only process one order at a time. The issue here is that if there are orders that have the same end time, there has to be the same amount of chefs to process the order. Therefore, the manager has the job to change the end time of the orders to delivery many orders in time. The system should help to handle the orders with the overlapping issue.

Book from different locations

Online ordering is a feature in modern restaurants that allow customers to place orders rather than being in person. If this is not present, this leads to some customers not bothering to order food at this restaurant. This reduces business for the customer. This is something the restaurant will change.

The system should be able to offer the customer a sandwich order without being in person at the place at the restaurant. So that the customer can use a device to order through the system.

(32)

Book for multiple times

The restaurant has customers who have defined orders as well, which can be repeated a number of times. An example is when a customer will order the same for every friday in a month. The customer should not need to order every friday. To make it easy, the customer should be able to make this repeated order at once. This system should allow a customer to become a regular customer at this restaurant, which leads to better income for the restaurant and the good service to the customer.

(33)

2.3 A distributed monitor with a delay queue for client requests

Bogdan Irimie[2] had implemented aDistributed Monitoring System,that is able to monitor, filter and store security parameters of network hosts for the cloud [16]. ThisDistributed Monitoring System[16] has a distributed architecture with delay queue system. I will now go deeper on the architecture for this system to understand why it is built like this. A closer look at design of this architecture may be needed for better comprehension of the system.

(34)

Figure 2.2: Architecture of distributed monitoring by Irimie Bogdan

(35)

ThisDistributed Monitoring[16] system is built with the following components: Client, aLoad balancer,FrontEnd,Scheduler,Scanner,Converterand Presenter, a database, message queue and a delay queue. FrontEnd,Sched- uler,Scanner,ConverterandPresentercan be run on different machines. All these five components have the opportunity to run more of themselves at the same time, so that they have the possibility of running tasks concur- rently. Tasks are defined in the request from the client and further processed in the system and return the result back to the client. The delay queue gives the opportunity to give more repetitions on same task with a time interval between these repetitions. The whole system has been implemented in programming language Java.

Client

Clients can use the system to check some security parameters of network host. The client will give an input in JSON-format with information about which security check have to be done and how many repetitions of such request will be handle.

Example 5 The client request example in JSON-format:

1 {

" c l i e n t I d " : " 13 ",

3 "command" : " s e c u r i t y e c r y p t 2 l v l 1 9 2 . 1 6 8 . 0 . 1 0 2 ",

" r e s p o n s e A d d r e s s " : " h t t p : / / 1 9 2 . 1 6 8 . 5 6 . 1 0 1 : 8 0 0 8 / j o b F i n i s h e d ",

5 " r e p e t i t i o n s ": 3 ,

" r e p e t i t i o n I n t e r v a l ": 1 0 0 ,

7 " p r o c e s s o r s " : [

" XmlToJson {\ i t C o n v e r t e r } ",

9 " s e c u r i t y . T l s C i p h e r s u i t e s F i l t e r ",

" s e c u r i t y . T l s E c r y p t 2 L e v e l "

11 ] ,

" a d a p t e r " : " a d a p t e r s . EventHubAdapter "

13 }

Example 5 will be used to explain the other components.

Load balancer

Clients send request to a component which is a Load balancer that distributes the requests to the FrontEnd component(s). Basically, the Load balancer checks if any FrontEnd is available, if there are available FrontEnds, one of them gets the request, but if there is no available FrontEnds, the request waits for a FrontEnd to become available.

FrontEnd

FrontEnd will receive a JSON object from the load balancer and will save this to the database. After writing down the request in the database, the

(36)

FrontEndreceives an ID from the database (the so-called document index).

After that, the ID is sent to a queue to be further processed by the scheduler.

Scheduler

The purpose of the Scheduler component is to determine whether this task is to be repeated several times, or only once through the clients data.

In example 5, the JSON input has two relevant variables. They are

”repetitions” and ”repetitionInterval”. This variables state that the task should be repeated three times (”repetitions”) with 100 seconds interval between each repetition. What happens is that the component Scheduler extracts the job from the database using the id. Here, the ’repetitions’

variable is subtracted by 1 (2 in Example 5). Then the database is updated and the document index will be sent to the queue of theScannercomponent and to thedelayqueue to process the rest of repetition.

Scanner

The Scannercomponent can be seen as an instruction executor. First, the Scannerreads the input data from the database and retrieves the command from the variable ”command” and runs the corresponding command. It generates a response, which is written to the database and the data ID is passed to the queue of converter. The Nmap tool has been used in this example. In this case the machine requires that Nmap is already installed where the Scanner component is running. With this Distributed Monitoring system, it is possible to download other utility tools and run them through theScannercomponent. Example 5, we run the command

”security encrypt2lvl 192.168.0.102” on the Scannercomponent. This is a command that runs through Nmap, completes its calculations and gives the result on XML format. That answer is stored in the database and the ID is sent to the queue of the converter.

Converter

The converter transforms data from any format to JSON-format. With respect to example 5, it transform data from XML to JSON. The new format is stored in the DB and sent further to the queue of the presenter.

Presenter

ThePresenter sends the result to the client. It first retrieves data from the database. The information we receive from the database contains a client ID that thePresenter can use to find the client and send the result to that client. In the event that the client is unavailable, it waits and sends data when the system can connect to the client. The data is in JSON format.

(37)

Queue

The assigned implementation of the distributed monitor uses RabbitMQ.

Read more about RabbitMQ’s pros and cons of this system in section 2.4.1.

Delay Queue

When scheduler finds a task which repeats multiple times, the task index will be sent to the delay queue, where the task gets delayed for one second as the default value. This value can be changed by the user by entering it in the variable ”repetitionInterval”. After the wait in thedelayqueue, the task will be added to the regular queue system. Example 5 uses the variable

”repetitionInterval ”, which changes the default value to 100 seconds. The request waits 100 seconds before it enters theScheduleragain to generate a new task.

Database

The assigned implementation of the distributed system uses MongoDB. In this architecture none of the components access the same data at the same time for further processing. Because each of the components writes to the database and further queues to the next component. Therefore, there will be no form of overwriting or erasing the data. Read more about MongoDB in section 2.4.2.

2.3.1 Architecture

In the rest of this section we are going to discuss pros and cons of this distributed architecture.

Pros

An architecture in which clients can sent multiple request at once.

For example, the delay queue, why was a delay queue in this distributed monitoring system important? The delay queue is for helping to repeat the same task. It is like a subscription model for this system. Subscription means an arrangement to receive something more times with a time range.

To repeat what delay queue does, it is a queue to delay the job with a spe- cific time to next repetition of the job. In this situation we can say that delay queue is equivalent withsubscription system.

Fault tolerance

Let say that all schedulers crashed, what happens with the system? This system will not die, even if the system does not have any scheduler. It is the same for the others components, like FrontEnd, Scanner, Converter and Presenter. When the system adds a new scheduler, the job will continue

(38)

the process in scheduler and move on to next component. This makes the system morefault tolerance, which is a positive thing about this architecture.

Lightweight data transfer

As we see in the architecture, the database iscentralizedin this distributed monitoring system. In the figure 2.2, all five main components are connected to the database. Which means that every component is not sending all data to each other. Every component sends just the ID of data, which store in database. The ID of data element is flow over all system. These five main components are using this ID to get data out. There are three properties that are good with this method of using database. The variable ID is an integer value. At first the system sends a Int ID variable between these components, which has a less cost of sending than sending all data between the components. This is more effective to handle with a value to communi- cate between these components. The most cost of the system will be when the component get the data from the database, but this occurs when it is necessary to get data. If a component crashes, then the data will not get lost. This is because all data is stored in the database and not in the components. That makes this centralized database more intelligent for this type of system. The last good thing is the availability of data for the system. All components that need data have access to read and write. Communication happens only between the components and the database.

Fault recovery

What happened if a component crashes during the middle of a task?

RabbitMQ is the queue system that this system used. The RabbitMQ queue system sends a job to the component and awaits an answer if it was completed or not. If it was not completed, then it will resend the job.

Without this, the system would forget to rerun the task. To answer the question "what happened if a component crashes in the middle of a run of a task?". The RabbitMQ queue system will try to resend the job and check the progress/status again, until the job is completed. To read more about RabbitMQ, see in section 2.4.1.

Cons

Centralized DB

Let’s see the negative of this system architecture. What happened if the database crashed? The system will try to connect to the database, but the database has been crashed, so the system will not respond.

(39)

2.4 Technology

This section will present a summary of the technology that has been used in this distributed monitoring system.

2.4.1 RabbitMQ

RabbitMQ[15, 22] is an open source message broker system. It focuses on the reliability of message delivery. This is accomplished by keeping track of several message conversation. The process is such that the queue sends the message to the component, and the message is deleted from the queue after the component responds to good progress. If one of the components is not available, the message will be queued to send later. If this does not happen, the message from the queue will not be deleted.

Once the component has finished its task, it will be marked as completed and deleted from the queue. This makes that a system is fault tolerant.

Fault tolerant means that if something crashes, the rest of the system will still hold and no data will be lost. When restarted, the system will resume from position before the crash.

RabbitMQ has the ability to disconnect one type of platform with another platform.

2.4.2 MongoDB

MongoDB[6, 7, 21] is a document-oriented database that does not use the row concept. It is known as ”NoSQL”, which actually means ”Not Only SQL”. MongoDB is developed in C ++, which stores data in Bi- nary JavaScript Object Notation(BSON) format similar to the structure of JavaScript Object Notation(JSON). This database is designed for distributed architectures, where the size of stored data is scalable as needed.

In the article CRUD Operations in MongoDB [7], they analyze the CRUD operations in MongoDB that are responsible forCreate,Read,Update and Delete.

MongoDB gives us the possibility of two functions for reading data and they arefind ()andfindOne (). We also need create that is to create the JSON object in the database from the client and then use ”update” to modify the data further in the process. Thus, the so-called ”write”operation from the architecture of the implementation in section 2.2. ”Update” is only possible if there is a previous creation of data, or it must create a new instance.

Indexing in MongoDB is useful when it comes to large amounts of data.

The index is used to identify a message in the database. RAM is defined as Random Access Memory that is used to keep data during operations that the system should do. Sending large data in the message queue leads to not enough RAM, but sending the index into the message queue will make it much faster and more convenient. MongoDB’s indexing is unique in the

(40)

database, which is then used as the primary key. Primary key is the pre- ferred reference and it automatically indexes the database.

Comparisons Between MongoDB and MS-SQL Databases on the TWC Website [5] confirms the CRUD article [7] and tells more about how MongoDB is built up. In the article, they explain why it pays to choose MongoDB as a database: ”NoSQL provides a much more elastic, schemaless data model that maps to an application’s data organization and simplifies the interaction between the application and the database resulting in less code to write, debug and main- tain”.

The article also confirms that indexing in MongoDB makes the queries much faster and more efficient, through their tests. I refer to Figure 12 in the article [5] which is a diagram of the test with and without indexing.

2.4.3 Nmap

Nmap[19] stands for Network Mapper, and is a free open-source utility for network exploration and security monitoring tool. It is vastly used to investigate security issues regarding the system, or the monitoring service is up/down. This system is designed to quickly scan large networks, but works well for smaller networks. Nmap is available as a graphic and command line version. It works by creating a map of the network from the response it receives from the web search. An example is that using the Nmap command on the terminal or on the browser, and searching for an arbitrary website such as vg.no. Nmap creates map of the IPs and ports that are contacted based on which ports are open and closed. This is presented using the XML format.

(41)

Part II

The project

(42)

(43)

Chapter 3

Design

This chapter will describe how the architecture of this fast-food restaurant looks like. The goal of this thesis is to see how this distributed architecture fits into business processes. In this case, the fast-food restaurant is defined as a business process. Figure 3.1 shows the architecture of the fast-food restaurant, which is similar to the architecture of the distributed monitoring system of Irimie as described in previous section 2.3.

Figure 3.1: Architecture of the fast-food restaurant business process

(44)

3.1 Differences in architecture

There are some changes from Irimie’s distributed architecture to the business model architecture of the case study. The figure 3.1 shows how the architecture of the business model system looks like. The subsections below describes the differences between the architecture from figure 2.2 and figure 3.1.

3.1.1 Change of component, reflecting the process of the case study

The goal of the distributed monitoring system was to monitor the security of the cloud. The case study in this thesis is about the fast food restaurant.

In this case the different components are Receptionist, Manager, Chef and Waiter. Different type of problem has the different type of components.

In this architecture, it can have an unlimited number of the different components. It depends on the set of task(the business process).

3.1.2 None converter component

The distributed monitoring system of Irimie use JSON format of data, but the scanner in the system creates a different format of data. Which needs a component to convert data to JSON format, which is called the component Converter. The component Converter is not relevant to this project of a business model because the system handles the same format of data, all the time.

3.1.3 No website

In the distributed monitoring system of Irimie, it has an HTTP website to the client to interact with the system. In our case study, it could be a website to the client to register the order, but this system is on ABS, and ABS cannot connect to the external system as web service. The componentReceptionist on the business model architecture can be seen as a website for the client to give an order.

(45)

3.2 Running example

Examples are a simple way of describing the flow of an action in order to think through how it works. This example is about how a customer will order two sandwiches and it will help understanding the system.

The task: Alice will orderChicken & Bacon Ranch Melt sandwich which is number 2 and Meatball Marinara which is number 5, for delivery in one hour. Sandwich number 2 and 5 take 10 minutes together to make. This is the first time Alice order at this restaurant.

1. Alice gets created as aClientfor the system with parameter, a client_id and reference to the Load Balancer. (She is now registered as a customer)

2. Furthermore, she creates a list of sandwiches with number 2 and 5.

3. Alice sends the list and 60 minutes delivery time in as an order into the system.

4. ... system processes ...

5. Alice receives sandwich after 60 minutes from theWaiter

Goal achieved: Alice got her sandwichesChicken & Bacon Ranch Meltand Meatball Marinara(number 2 and 5)

This example will be used on sections 3.2, 3.3 and 3.4 with three divided sequence diagrams to understand how the system processes the order from Alice.

3.3 Sequence diagram

The example of the running in section 3.2 will continue on the sequence diagram. The sequence diagram[12] gives details on the interactions between the objects and also lead to understand how the flow of the system is.

(46)

Figure 3.2: Sequence diagram of business model system

First, we assume that all these objects have been created. Alice calls the sendOrder method in the Client object and sends with the required parameter (such as the sandwich list, number of repetitions, delivery time).

Then the client object calls on getReceptionist to deliver the order to the restaurant. OnceLoadBalancerhas helped find a receptionist, thesendOrder method is completed. From there, Alice can do anything, like ordering new sandwiches or not doing anything else. OnceLoadBalancerhas found an available receptionist,doTaskwill be called in the receptionist with the parameter the order. The receptionist stores the order in the database and receives a database id(order id, key for the order) and puts the order id in the queue betweenReceptionistandManager. Now the order from Alice is in the first queue, as depicted in figure 3.1.

(47)

(48)

The Manager retrieve the id of order from the queue with the getTask method. Then, the Manager uses the id of order and retrieves the entire order from the database. TheManagercalculates the cost of this order and finds that Alice’s order costs 10 minutes. Alice had no repetitions of the order and therefore it does nothing with the methodduplicate_order. The manager finds that time is now 0 and the order will be delivered in 60 minutes. It can wait for 50 minutes before it should be made and therefore the order is sent to theDelayQueue. TheDelayQueuechecks if other orders in the system crash on the same time, by calling thesort method inDelayQueue.

We assume that there is no other order than Alice’s order. Therefore, there will be no changes in waiting time or delivery time(endTime).

The order id is inserted into the queue list in theDelayQueueby the method insert. The order is waiting for 50 minutes. DelayQueueplaces the order in the queues between theReceptionistand theManager. Then remove the order id from the queue list inDelayQueue. TheManagerretrieve order id from the queue and reads order information from the database again and recognizes that it isjust in time(JIT) to make these two sandwiches. The order id will be added to the next queue (which is betweenManagerand Chef), as depicted in figure 3.1. Now the order is ready for production.

(49)

The Chef retrieve the order id from the queue and use order id to retrieve order information from the database. The chef walks through all the sandwiches. In our case, two sandwiches are going through(number 2 and 5). Then theChefwork for 10 minutes to preparing sandwiches. It is the time the kitchen uses to make this order, which was calculated by the Manager. Then it will be set to the next queue that is between theChefand theWaiter. The Waiterretrieve order id from the queue and retrieve order information from the database. It logs as completed order and that delivery was successful, because Alice’s order is delivered in 60 minutes as agreed.

TheWaiter calls the methodgiveMessagewith the message "DONE" to the

(50)

Client.

3.4 Scheduling formula in the component Manager

TheManageruses some formulas, which helps to calculate the cost of the order. An order contains a list of sandwiches. Each sandwich has a variable calledcost. The variablecostis the time it takes to make the sandwich.

As illustration we are using the following 2 formulas which uses this cost.

Formula 1:

totalCost+=cost(X_i)

Formula 2:

totalCost +=cost(X_i) + (^cost(X_i)

2 ∗length(X_i))

X_i is a sandwich from the order list.iis a position of a sandwich in the list of sandwiches. The variabletotalCostis total cost for sandwiches in the order. Formula 1 is used when it is only one of each type of sandwich. if there are more than one kind of sandwich in the list, then the scheduler use formula 2. Formula 1 add every cost of sandwiches. Formula 2 add the cost of one same sandwich and add extra cost for every same sandwiches in the order. When every sandwich in the order has been gone through, then the variabletotalCostgive the total amount of cost of the order.

The formula 2 takes into account reducing time if the chef makes more of the same type of sandwich in one order. For example, a bacon sandwich takes 2 minutes to make, so it does not mean making three of the same type of bacon sandwich, should take 6 minutes together. This is to the fact that the chef starts the three sandwiches at the same time. So when the chef, for example, puts two slices of cheese on one sandwich, the chef then puts two slices of cheese on the other sandwich at the same time before the chef goes on with other ingredients. Therefore, the tasks are merged, spending only a little extra time to make an extra sandwich. This is why we are considering a reduction of time per extra sandwich. This has been included in the calculation in this system. This formula is not taken after any original statistic. This is only a thoughtful formula. Formula 2 has formula 1 in the bill and the extra for remaining sandwiches. This will be the difference between these two formulas.

The graph 3.4 shows how would be the growth of formula 2. The graph result was based on the cost of sandwich, where the cost is 4 to make one sandwich.

(51)

2 3 4 5 6 7 10

15

length(X_i)

Cost

The x-axis of the graph is the number of the same sandwich. The y-axis of the graph is the number of total costs. It increases by half of the sandwich cost for each of the same sandwich. In the example, the sandwich cost was 4 minutes. It will increase 2 minutes for every extra sandwich. Formula 2 gives a proportional increase. The larger the number of sandwiches of the same type must be made, the smaller the amount of time it will be per sandwich.

(52)

(53)

Chapter 4

Implementation

This chapter describes the implementation of the case study. The implementation of the system is modeled in the ABS language. As a starting point, we are facing the distributed architecture described in section 2.2, and adapt it to fit the requirements of this case study. The architecture in figure 3.1 has been used in this system. Section 4.1 describe the code of the model. The full code of the model can be found in URL:

https://github.com/aravinthAS/Distributed-resturant-system .

4.1 The Code

4.1.1 Config

Config module is designed to simplify the other modules. Config module has export and import all modules in the system. Every module needs to import config module to get access to other modules and export all their functions to give access to other modules. The example below shows how to import the config module and export all their functions.

Example 6

1 e x p o r t * ;

i m p o r t * from C o n f i g ;

Coding/import_config_to_components.abs

The config module have general functions too, which are not in an object but defined bydefin ABS. Every module can use these type of function by import config module. These functions are in this case print functions.

All type of modules are imported into this config module and exported all.

By importing the config module from another module, the other module can access all other modules. This is to avoid importing each module into every module. Example 7 shows all modules that are in the system being imported into the config module and exported the same modules from the module config.

(54)

Example 7

module C o n f i g ;

2

e x p o r t * ;

4 e x p o r t * from C l i e n t ; e x p o r t * from R e c e p t i o n i s t ;

6 e x p o r t * from D a t a b a s e ; e x p o r t * from Queue ;

8 e x p o r t * from L o a d _ b a l a n c e r ; e x p o r t * from Chef ;

10 e x p o r t * from Waiter ; e x p o r t * from Manager ;

12 e x p o r t * from DelayQueue ; e x p o r t * from S t a t ;

14

i m p o r t * from C l i e n t ;

16 i m p o r t * from R e c e p t i o n i s t ; i m p o r t * from D a t a b a s e ;

18 i m p o r t * from Queue ;

i m p o r t * from L o a d _ b a l a n c e r ;

20 i m p o r t * from Chef ; i m p o r t * from Waiter ;

22 i m p o r t * from Manager ; i m p o r t * from DelayQueue ;

24 i m p o r t * from S t a t ;

Coding/config_import_export.abs

Now we are going to explain the rest of datatypes and functions in this module. The datatype data provides the ability of the system to make orders, the sandwich recipes, the ingredients for the sandwiches and to have system info. Example 8 shows how this is implemented in the config file.

Example 8

d a t a Data = Sandwich ( Sandwich_name sandwichName ,

2 L i s t < P a i r <Product_ID , P r o d u c t _ c n t >> i n g r e d i e n t s , I n t c o s t ) |

4 Order ( C l i e n t c l i e n t ,

L i s t <Sandwich_ID > s a n d w i c h e s ,

6 I n t r e p e t i t i o n s ,

I n t r e p e t i t i o n s I n t e r v a l ,

8 I n t o r d e r C o s t ,

I n t endTime ) |

10 I n g r e d i e n t ( S t r i n g i n g r e d i e n t ) | S y s t e m I n f o ( I n t n u m b e r O f C h e f s ) ;

Coding/Data_config.abs

In the config file, there are a lot of print features. These print features have various way to print information on the terminal. By changing the option id ingive_print_id ()function, you can get different information print out to the terminal. Below you have categories:

0. Print out [Time_X] [Client | Channel] [Content_message]

1. Print out all orders

(55)

2. Print out all queue statues

3. Print out [Time_X] [Content_message]

4. Print just statistic, But all option have statistics 4.1.2 Database

The module database provides the ability to save data that the system can use and edit. When the system is running and this database is initialized, then it is ready to use. If the system goes down, we lose all data, because data is not stored on hard disk or cloud. It is only temporarily stored in RAM (PC memory), so when the system ends, data is removed from the RAM. It was chosen to make it so because ABS is not designed to store data to file or connect to a cloud. It has been used themap to store data temporarily.

The container holds on all orders from the clients while keeping on which sandwich and ingredients the restaurant have in a map. The map is logically divided into four categories by key value (Data_id). Data_id should determine whether it is order-, sandwich-, ingredient or system information-object. The order can have all the id as non-negative integers 1, 2, 3, .... Sandwich has the amount of{−499, ...,−1}. Ingredients have the amount of{...,−501,−500}. The id0is reserved to store system information. See example 8 onSystemInfo(...). Currently on the system-information is stored only number of chefs in the restaurant. No one need to set the number of chefs, but the system calculate for the restaurant for every chef been initialized. The system information can be extended with more information by sending multiple parameters in the SystemInfoobject, if the restaurant needs more. Figure 4.1 shows how the database table is divided.

Figure 4.1: Database table structure

(56)

Interface DB

• Data_ID insertDatahas a parameter and it is:¹

1. Data c: Contains entireOrder from the client, or aSandwich, or anIngredientorSystemInfo.

The method returns the database id for the object that is stored in the database.

• Data_ID removeDatahas one parameter and it is:

1. Data_ID db_id: Id for the data object that stored in the database.

The method returns the database id for the object that is deleted from the database.

• Unit updateDatahas two parameter and these are:

1. Data_ID db_id: Id for the data object that stored in the database..

2. Data c: Contains entireOrder from the client, or aSandwich, or anIngredientorSystemInfo.

It has no return value because it is a Unit/void.

• Data getDatahas a parameter and it is:

1. Data_ID db_id: Id for the data object that is stored in the database.

The method returns the object of the word (Data) from the database.

• Map<Data_ID, Data> getDatabasehas no parameters. The method returns the entire container.

Class Database

Interface DB is implemented in the Database class. The database class contains the variablecontainerin the type ofMap. The key for thecontainer is database id (Data_ID), and value is the data object, which can contain:

sandwich-, order-, ingredient- and system-information-object. The class has a variable, which isdb_counterin the form of data typeData_ID, which is defined as an int in the config file.

• Data_ID insertData¹

1. Temporary variable ”db_id” gets the next available order id, through ”db_counter”.

2. ”db_counter” is increased by one, for next available order id.

1https://github.com/aravinthAS/Distributed-resturant-system/blob/master/Database/

Db.abs

(57)

3. The if statement double checks if it does not contain anything on that ID in the container.

4. If there is no content in that space, then the Data c object (from the parameter) is inserted into the container.

5. returns ”db_id” which is the id of the object that was placed in the container.

• Data_ID removeData

1. If statement checks if there is a value in the container on the key

”db_id”.

2. If yes, value from the key ”db_id ” will remove that value in the container

3. and return db_id regardless

• Unit updateData

1. Updates the value with Data c object(from the parameter) with the key id ”db_id” on the container.

• Data getData

1. returns the value from the key ”db_id” from the container.

• Map<Data_ID, Data> getDatabase 1. returns the entire container (map).

4.1.3 Queue

The queue module is a queue system that holds orders. It is possible to place the id of orders in the queue and take the id of orders from the queue.

The queue system is made with the first in first out (so-called FIFO) system.

It is the components themselves that must call the method in the queue to retrieve orders. The task of the queue system is to keep data id of orders, which is an integer. This makes the system effective by sending orders and extracting with only integer.

Interface Queue

• The methodData_ID insert(Data_ID db_id)has one parameter and that is:²

1. Data_ID db_id: order ID, usually used by main components

• The method Data_ID getTask()has no parameter, but has a return value. The method returns the next order from the queue(follow first in first out).

• The methodInt getQueueLength()has no parameter, but returns the number of orders in the queue.

2https://github.com/aravinthAS/Distributed-resturant-system/blob/master/Queue/

Queue.abs

(58)

Class Queue

This interface is implemented in the class Queue. The Queue class has a list called inQueue, which will contain all orders waiting in the queue until the components retrieve the orders.

• Unit print()²

1. Retrieves the length of the queue 2. and prints the queue length

• Data_ID insert(Data_ID db_id) 1. Adds db_id to the list inQueue

2. prints the message that it has been entered 3. Calling the print method from this object 4. returns db_id (Equals to the id of an order)

• Data_ID getTask()

1. Waiting if the list inQueue is empty, if not, continue with it 2. takes out the first order from the list inQueue

3. set inQueue to point at the rest of the list 4. prints message that order has been deleted 5. returns db_id

• Int getQueueLength()

1. Retrieves the length of the list inQueue 2. and returns the length

4.1.4 Client

The client’s task is to be able to send orders and receive deliveries. The client is built on the interface "Client". The interfaceClienthas the methods

’sendOrder’, ’giveMessage’ and ’get_client_id’.

Interface Client

• The methodUnit sendOrderhas four parameters and they are³ 1. List<Sandwich_ID>sandwiches: A list of sandwich IDs which

client would like to order.

2. Int repetitions: Number of repetitions of the order from client’s request.

3. Int repetitonsInterval: The length of the waiting time between repetitions.

3https://github.com/aravinthAS/Distributed-resturant-system/blob/master/Client/

Client.abs

The fast food restaurant

The fast food restaurant

A case study for modelling business process using ABS

Aravinth A. Sivalingam

Thesis submitted for the degree of

Master in Informatics: programming and networks 60 credits

Institutt for informatikk

Faculty of mathematics and natural sciences

UNIVERSITY OF OSLO

The fast food restaurant

A case study for modelling business process using ABS

Aravinth A. Sivalingam

The fast food restaurant

Abstract

Contents

List of Figures

List of Tables

Preface

Part I

Introduction

Chapter 1

Introduction

Chapter 2

Background

2.1 ABS

2.2 Problem: Case Study

2.3 A distributed monitor with a delay queue for client requests

2.4 Technology

Part II

The project

Chapter 3

Design

3.1 Differences in architecture

3.2 Running example

3.3 Sequence diagram

3.4 Scheduling formula in the component Manager

Chapter 4

Implementation

4.1 The Code