Supermarket

checkout simulation
Concurrency and parallelism

Txomin Sirera Ibarluzea - 13110349
18/11/2013
All about a supermarket checkouts simulation application carried out to help managers to
reach a decision about the purchasing of new scanners.

Content index
1. Supermarket background ...................................................................................................... 4
1.1. Application requirements ............................................................................................. 4
1.1.1. Functional requirements ....................................................................................... 4
1.1.2. Non-functional requirements................................................................................ 5
1.2. Development environment ........................................................................................... 5
1.3. Structure of the application .......................................................................................... 5
2. Supermarket class diagram ................................................................................................... 6
3. Class details ........................................................................................................................... 7
3.1. CheckOut ....................................................................................................................... 7
3.1.1. Variables ................................................................................................................ 7
3.1.2. Constructor ............................................................................................................ 8
3.1.3. Operations ............................................................................................................. 8
3.2. Customer ..................................................................................................................... 12
3.2.1. Variables .............................................................................................................. 12
3.2.2. Constructor .......................................................................................................... 12
3.2.3. Operations ........................................................................................................... 12
3.3. Item ............................................................................................................................. 14
3.3.1. Variables .............................................................................................................. 14
3.3.2. Constructor .......................................................................................................... 14
3.3.3. Operations ........................................................................................................... 14
3.4. Worker......................................................................................................................... 15
3.4.1. Variables .............................................................................................................. 15
3.4.2. Constructor .......................................................................................................... 15
3.4.3. Operations ........................................................................................................... 15
3.5. SpecialWorker ............................................................................................................. 16
3.6. Supermarket ................................................................................................................ 16
3.6.1. Variables .............................................................................................................. 16
3.6.2. Constructor .......................................................................................................... 17
3.6.3. Operations ........................................................................................................... 17
4. Process phases .................................................................................................................... 19
4.1. Supermarket ................................................................................................................ 19
4.2. Worker......................................................................................................................... 20
4.3. Customer ..................................................................................................................... 20
4.4. Interpreting the output ............................................................................................... 22
5. Testing the application ........................................................................................................ 24
5.1. Worker behaviour test ................................................................................................ 24
5.2. Customer behaviour test ............................................................................................. 24
5.2.1. Successfully treated customer ............................................................................ 24
5.2.1. Unsuccessfully treated customer ........................................................................ 25
5.3. Encountered errors ..................................................................................................... 25

Illustration index
Figure 1: Supermarket ................................................................................................................... 4
Figure 2: Class diagram ................................................................................................................. 6
Figure 3: CheckOut class details .................................................................................................. 11
Figure 4: Customer class details .................................................................................................. 14
Figure 5: Item class details .......................................................................................................... 15
Figure 6: Worker class details ..................................................................................................... 16
Figure 7: SpecialWorker class details .......................................................................................... 16
Figure 8: Supermarket class details ............................................................................................. 18
Figure 9: Customer/Worker interaction...................................................................................... 19
Figure 10: Supermarket flow chart ............................................................................................. 20
Figure 11: Worker flow chart ...................................................................................................... 20
Figure 12: Customer flow chart ................................................................................................... 21

1. Supermarket background
A big supermarket
1
chain wants a simulation of their checkouts. There is a new scanners
technology on the market, the use of them would reduce the scanning time for each item,
because they are much more reliable, but three of the new scanners cost as much as five of
the old ones. The managers want to know if it worth the purchase of these products. The aim
of the application is to help them reach a conclusion giving them a source of data to make or
not the investment.
This document gives all the information needed for the understanding and comprehension of
that project.

Figure 1: Supermarket
1.1. Application requirements
Managers have decided that the application should cover the following functional and non-
functional requirements.
1.1.1. Functional requirements
All these requirements have been implemented in the application using final variables,
providing easy modifiable simulations.
A variable number of functioning checkouts.
The number of products for each trolley to be generated randomly within a user
specified range.
The time for each product to be entered at the checkout to be generated randomly
within a user specified range.
One or more checkouts to have a restriction on the number of items

1
See Figure 1
The rate the customer arrives at the checkouts to be generated randomly within a user
specified range.
Total wait time for each customer.
Total utilization for each checkout.
Total products processed.
Average customer waiting time.
Average checkout utilisation.
Average products per trolley.
The number of lost customers (Customers will leave the store if they need to join a
queue more than six deep or if the car park is full).
1.1.2. Non-functional requirements
The non-functional requirements are basically related with reliability and use of the checkouts,
these two features are connected with concurrent programming. First goes the reliability
(safety) and then the checkout utilisation (liveness), this has been the order followed when
programming, resulting in a high performance application.
1.2. Development environment
The application has been built in Java programming language and it has been release under the
Eclipse IDE
2
. One of the main characteristics of the application is the use of concurrency,
resulting on different responses every time it is executed.
The class diagrams have been built with Visual Paradigms
3
for UML 2.0 tool; this is
a UML CASE Tool supporting UML 2, SysML and Business Process Modelling Notation
(BPMN) from the Object Management Group (OMG). In addition to modelling support, it
provides report generation and code engineering capabilities including code generation. It
can reverse engineer diagrams from code, and provide round-trip engineering for
various programming languages.
1.3. Structure of the application
The application has an internal structure based on package distribution:
Main: Contains the main class (Supermarket
4
) of the application.
Customer: Contains all classes related with the customer.
Checkout: Contains all classes related with the checkout functions.
Worker: Contains all classes related with the worker.


2
For further information check http://www.eclipse.org/
3
For further information check http://www.visual-paradigm.com/
4
See Supermarket class
2. Supermarket class diagram
The class diagram of an application provides a general idea of its structure and attributes and
operations in each class, the one below (Figure 1) shows just the relations between them.

Figure 2: Class diagram
There, can be seen that the Supermarket class is in the middle of the application, within it
executes and finalizes the application. There is the main operation and the variable
initialization. These variables are composed by a list of Worker and Customer, a CheckOut
object and more control variables.
The Worker class is a generalization for SpecialWorker, which is used as fast checkout; it has
a limit of maximum quantity of products if someone wants to use it. This class receives the
CheckOut in its constructor to use it synchronized
5
operations, because each
Worker/SpecialWorker is a thread.
The Item object is used by the Customer several times to simulate the goods that are going to
be bought. This one also receives the CheckOut class in its constructor because the same
reason as the Worker does.


5
Thread synchronization ensures that objects are modified by only one thread at a time and that
threads are prevented from accessing partially updated objects during modification by another thread
3. Class details
In the lines below each class of the application is presented in detail, explaining what do each
variable count and what each operation do.
3.1. CheckOut
The CheckOut
6
class has all the synchronized operations. These operations are used by the
Customer, Worker and Supermarket threads; the last one is using it to get the summaries of
each checkout and more detailed information about purchases and customers.
3.1.1. Variables
NO_SELECTED_CHECKOUT: This variable sets the number associated with a no selected
checkout. Helps to identify customers with more than x tries to enter in a queue. The
type is a final int.
numberOfCustomersInSupermarket: This variable counts the total customers inside
the supermarket. Its type is an int.
lostCustomers: This variable counts the amount of customers lost because the capacity
of the car park. Its type is an int.
checkOutId: This variable is a unique identification for each checkout. Its type is an int.
totalCustomersInQueue: This variable counts the total amount of customers in all
queues. Its type is an int.
totalCustomersForCustomCheckOut: This variable counts the total amount of
customers in custom queues. Its type is an int.
specialCheckOutsBegin: This variable contains the value of the first special checkout id.
Its type is an int.
allowedCustomCustomersInQueue: This variable sets the total amount of customers
allowed to be in queues. Its type is an int.
lostCustomersAfterShopping: This variable counts the amount of customers lost
because the availability of the queues. Its type is an int.
totalCustomerWaitTime: This variable is used to know the wait time in the queue for
each customer. Its type is a long.
itemsInCheckOut: This variable reflects the total amount of items treated by each
checkout. Its type is an array of ints.
customersInQueue: This variable reflects the quantity of customers in each checkout
queue. Its type is an array of ints.
customersInCheckOut: This variable reflects the total amount of customers treated by
each checkout. Its type is an array of ints.
paid: This variable reflects the current status of each checkout in terms of paying. Its
type is an array of booleans.
charged: This variable reflects the current status of each checkout in terms of charging.
Its type is an array of booleans.
occupied: This variable reflects the current status of each checkout in terms of
availability. Its type is an array of booleans.

6
See Figure2
queueAvailability: This variable reflects the current status of each queue checkout in
terms of availability. Its type is an array of booleans.
noQueueAvailable: This variable gathers if all queues are full. Its type is a boolean.
3.1.2. Constructor
The constructor is used to initialize all variables.
All int variables are initialized to 0 apart from specialCheckOutsBegin, which gets the
value of the least of total checkout quantity and number of special checkouts.
Sizes for arrays are set; all of them, apart from allowedCustomCustomersInQueue, are
the same as the checkout quantities. The other one is initialized with the least of the
total checkouts multiplied by the maximum amount of customers in queue and the
special checkout quantity multiplied by maximum amount of customers in queue.
o int arrays are initialized to 0 for each checkout.
o paid, charged and occupied are initialized to false for each checkout.
o queueAvailability is initialized to true for each checkout.
3.1.3. Operations
All operations in this class has the prefix of synchronized, that is because is the class Customer
and Worker are going to use independently changing variables, that is the reason of that
prefix.
enterSupermarket:
o Receives: int.
o Returns: Boolean.
o Execution: This operation is executed by the customer. The operation checks
the total amount of customers in the supermarket car park, if it is full, the
customer does not enter the supermarket incrementing the value of
lostCustomers, if not it parks the car and enters inside, incrementing the
numberOfCustomersInSupermarket. After all the process, it returns if it enters
or not.
selectQueue:
o Receives: int and int.
o Returns: int.
o Variables:
queueSelected: This says if the customer has or not selected a queue.
Its type is a Boolean.
noForSpecialCheckOut: This says if the customer can use a special
checkout or not. Its type is a Boolean.
intents: Total attempts of trying to enter in a queue. Its type is an int.
o Execution: This operation is executed by the customer. It prints out that
customer is doing the shopping, and how many items do it entered in the
trolley. The items quantity is passed into the checkCustomerOption
7
operation
and after that the value of noForSpecialCheckOut is changed. Depending on
the value of that, the customer is going to try to find a free queue. If the

7
See checkCustomerOption operation
customer has more than the items permitted for the special checkout, it only
can use the custom checkouts, but if the total amount of customers in custom
checkouts is the same as the allowed one, the customer cannot enter, so it
increases the number of attempts to enter a queue and waits until queue
availability changes. On the other hand, the customer that can use a special
checkout also can use a custom check out, but if all queues are full, it increases
the intents of entering a checkout and waits until queue availability changes.

Once the queue availability for the checkout is updated, the customer is able
to select a free checkout only if the intents made to enter in it are less than
the specified by the MAX_QUEUE_INTENTS
8
variable. If the customer fulfils the
rule it can go to the next step that consists on viewing the availability of the
checkouts. If the customer can use a special checkout, it set as a priority for it
to check the special checkout availability, then the custom ones. Once it finds
an available queue it returns the value of it to be used in the next operations.
After that, it notifies the others that some values have been changed.
payAndGo:
o Receives: int, Item [] and int.
o Returns:
o Variables:
itemQuantity: It gives the total amount of items bought by the
customer. Its type is an int.
o Execution: This operation is executed by the customer. The operation executes
the pay
9
operation, passing the list of items, to get the items bought by the
customer and then, it pays changing the value of the paid variable in that
checkout to true. After that, it waits until the worker on the checkout charges
it. Once this happens, quantity of treated items and customers in the checkout
are incremented, least the number of customers in queue and customers in
supermarket and finally the queue availability variables are changed. If the
checkout was not a special one, the number of customers for custom
checkouts is reduced. After that, it notifies the others that some values have
been changed.
pay:
o Receives: Item [].
o Returns: int.
o Execution: It is just a loop where goes from the firs value of the Item [] array to
the last, waiting the time of each product. At the end it returns the array size,
that it is the same as the items bought by the customer.
enterInQueue:
o Receives: int and int.
o Returns:

8
See Supermarket class
9
See pay operation
o Execution: This operation is executed by the customer. The operation is called
after the customer has selected a queue. The value of the customers in the
queue for that checkout is incremented as the total customers in queues. If
the quantity of customers in queues is equal to the maximum customers
permitted, the noQueueAvailable becomes true, and then it notifies the other
of the updates done. Finally, if the checkout selected is occupied, the
customer waits until it becomes available.
waitCustomers:
o Receives: int.
o Returns:
o Execution: This operation is called by the worker; it makes the worker wait
until some customer enters the queue associated with its own checkout, when
this happens the worker changes its availability and notifies the other.
charge:
o Receives: int.
o Returns:
o Execution: This operation is called by the worker, here it waits until the
customer has paid , when that happens it changes its availability and updates
the value of the charged on true, then it notifies the other.
getSummary:
o Receives:
o Returns:
o Variables:
totalTreatedCustomers: This variable counts the quantity of the total
amount of customers treated. Its type is an int.
totalTreatedItems: This variable counts the quantity of the total
amount of items treated. Its type is an int.
o Execution: This operation is executed by the supermarket. The operation
executes a loop that goes from the first to the last checkout getting their
amount of clients and items treated; after the loop, the general information is
shown.
closeSupermarket:
o Receives:
o Returns:
o Execution: This operation is executed by the supermarket. The operation is
executed once the number of customers in supermarket is 0 and it is closed. It
changes the status of the paid and charged lists and then notifies the others.
checkCustomerOption:
o Receives: int.
o Returns: Boolean.
o Variables:
noForSpecialCheckOut: This variable determines if the customer can
access or not the special checkout. Its type is a Boolean.
o Execution: This operation takes into account the value received and it
compares with SPECIAL_CHECKOUT_MAX_ITEM_QTY
10
, if is less than it the
value of noForSpecialCheckOut is set on false, else it is true. The value is
returned to be used in other operations and notified to the others.
collectSurvey:
o Receives: long.
o Returns:
o Execution: This operation is called by the customer; it updates the value of
totalCustomerWaitTime summing up the value received. Then it notifies to the
others of the change.
leftGoodsAndGoHomeUpset:
o Receives: int.
o Returns:
o Execution: This operation is executed by the customer. The operation reduces
the number of customers in the supermarket and sums the number of
customers lost after doing the shopping. Then it notifies about the changes.

Figure 3: CheckOut class details

10
See Supermarket class
3.2. Customer
This class is the one which simulates the customer behaviour. It is a thread, so each customer
executes the run operation inside, that execution is made simultaneously by every customer.
3.2.1. Variables
MAX_ITEMS: This variable sets the number associated with the maximum items that a
customer can purchase. The type is a final int.
MAX_PARKING_TIME: This variable sets the number associated with the maximum
time that a customer can spend parking the car. The type is a final int.
MAX_SHOPPING_TIME: This variable sets the number associated with the maximum
time that a customer can spend doing the shopping. The type is a final int.
checkout: This variable contains all functionalities of the Checkout class, allowing the
customer to use its operations. Its type is a Checkout.
entered: This variable sets if the customer has entered in the supermarket or not. Its
type is a Boolean.
items: This variable holds the items purchased by the customer. Its type is an array of
Item.
checkOutId: This variable is related to the id checkout selected by the customer after
the shopping process. Its type is an int.
customerId: This variable is the id of each customer, this helps to distinguish them. Its
type is an int.
startWaitTime: This variable holds the exact time when the customer enters a queue.
Its type is a long.
endWaitTime: This variable holds the exact time when the customer leaves a queue.
Its type is a long.
totalWaitTime: This variable holds the total time when the customer enters a queue.
Its type is a long.
3.2.2. Constructor
The constructor is used to initialize all variables.
This constructor receives two variables:
o int: It is an identification number.
o CheckOut: It carries all operations of the class.
The checkout and the customer id are equalled to the variables the customer has.
All long variables are initialized to 0.
The entered Boolean is set to false.
3.2.3. Operations
run:
o Receives:
o Returns:
o Execution: This operation is executed when the customer is created and called.
The first thing a customer does is to park the car. When it is trying to park the
car enterSupermarket
11
is called and depending on the value returned it enters
or not the supermarket. If the customer enters the supermarket, starts doing
the shopping when fillTrolley
12
operation is called. Then, it calls the
selectQueue
13
operation passing the id of the customer and the quantity of the
items bought. If the value returned by the operation is different from the
NO_SELECTED_CHECKOUT
14
value, enters the queue, pays and fills a survey
(collectSurvey
15
) with the total wait time of the customer in the queue. If not,
the customer leaves the supermarket leaving the goods bought
(leftGoodsAndGoHome
16
).
parkTheCar:
o Receives: int.
o Variables:
parkingTime: This variable simulates the customer parking time, it is
randomly calculated. It goes from 1 to MAX_PARKING_TIME. Its type is
an int.
o Execution: It simulates the customer parking time, this is why it receives the
customer id, that way every customer is distinguished when parking the car; it
only sleeps the thread of the customer for the number calculated for
parkingTime variable.
fillTrolley:
o Receives:
o Returns:
o Variables:
parkingTime: This variable simulates the items that the customer is
going to buy, it is randomly calculated. It goes from 1 to MAX_ITEMS.
Its type is an int.
o Execution: This operation is run by each customer after entering the
supermarket. After getting the random number for the item quantity, it
initializes an array of Item and after that it fills. Then shoppingTime
17
operation
is called.
shoppingTime
o Receives:
o Returns:
o Variables:
shoppingTime: This variable simulates the customer shopping time, it
is randomly calculated. It goes from 1 to MAX_SHOPPING_TIME. Its
type is an int.

11
See enterSupermarket operation in CheckOut class
12
See fillTrolley operation
13
See selectQueue operation in CheckOut class
14
See CheckOut class
15
See collectSurvey operation in CheckOut class
16
See leftGoodsAndGoHomeUpset operation in CheckOut class
17
See shoppingTime operation
o Execution: It simulates the customer shopping time; it only sleeps the thread
of the customer for the number calculated for shoppingTime variable.

Figure 4: Customer class details
3.3. Item
The Item
18
object is created to simulate the goods the customer buys.
3.3.1. Variables
ITEM_WAITING_MAX_VALUE: This variable sets the number of maximum number of
waiting for items to be processed. The type is a final int.
ITEM_WAITING_MIN_VALUE: This variable sets the number of minimum number of
waiting for items to be processed. The type is a final int.
itemWaitingDifference: It keeps the value of the possible numbers to be used when
generating the item waiting time. Its type is an int.
itemWaitValue: It contains the value of the waiting time of the item. Its type is an int.
3.3.2. Constructor
The constructor is used to initialize all variables.
The itemWaitingDifference is set with the least between ITEM_WAITING_MAX_VALUE
and ITEM_WAITING_MIN_VALUE. And then the itemWaitValue is set randomly from 1
to the value get in the itemWaitingDifference.
3.3.3. Operations
getItemWaitValue:
o Receives:
o Returns: int.
o Execution: Just an operation to get the value of the variable itemWaitValue.

18
See Figure 4

Figure 5: Item class details
3.4. Worker
This class is the one which simulates the worker behaviour. It is a thread, so each worker
executes the run operation inside, that execution is made simultaneously by every worker.
3.4.1. Variables
checkOutId: This variable is the id of each customer, this helps to distinguish them. Its
type is an int.
checkout: This variable contains all functionalities of the Checkout class, allowing the
customer to use its operations. Its type is a Checkout.
3.4.2. Constructor
The constructor is used to initialize all variables.
This constructor receives two variables:
o int: It is an identification number.
o CheckOut: It carries all operations of the class.
The checkout and the worker id are equalled to the variables the customer has.
3.4.3. Operations
run:
o Receives:
o Returns:
o Execution: This operation is executed while the supermarket is opened, once it
closes, the execution ends. First it calls the waitCustomer
19
operation passing
its own id. Then it charges the customers. And these steps are repeated until
the end.
goHome:
o Receives: int.
o Returns:
o Execution: It prints out that the worker has gone home.

19
See waitCustomer operation in CheckOut class

Figure 6: Worker class details
3.5. SpecialWorker
The SpecialWorker
20
extends the Worker class, so it has the same operations and variables that
its predecessor has.

Figure 7: SpecialWorker class details
3.6. Supermarket
The Supermarket
21
class its the main class. This class is where the application starts the
initialization and first steps for the simulation. Most of its variables are static, making it
available at the class level.
3.6.1. Variables
MAX_CUSTOMER_QTY_IN_SUPERMARKET_CAR_PARK: This variable sets the number
of maximum number of customers in the car park. The type is a final int.
SUPERMARKET_OPEN_TIME: This variable simulates the opening hour of the
supermarket. The type is a final int.
SUPERMARKET_CLOSE_TIME: This variable simulates the closing hour of the
supermarket. The type is a final int.
MAX_CUSTOMERS_IN_QUEUE: This variable sets the maximum number of customer
that can be waiting in the same queue. The type is a final int.
MAX_CHECKOUTS: This variable sets the maximum number of checkouts in the
supermarket. The type is a final int.
MAX_SPECIAL_CHECKOUTS: This variable sets the maximum number of special
checkouts in the supermarket. The type is a final int.
SPECIAL_CHECKOUT_MAX_ITEM_QTY: This variable sets the maximum number of
items allowed to access the special checkouts. The type is a final int.
MAX_QUEUE_INTENTS: This variable sets the maximum attempts that a customer can
do to try to enter in a queue before it leaves the supermarket. The type is a final int.
closed: This variable sets if the supermarket it closed or not. Its type is a Boolean.
workers: A set of workers that contains every of them and its executions. Its type is an
array of Worker.
customers: A set of customers that contains every of them and its executions. Its type
is an arrayList of Customer.

20
See Figure 6
21
See Figure 7
checkout: The variable that contains all operations of the CheckOut class. Its type is a
CheckOut.
supermarketOpenTime: This variable holds the total time of the supermarket since it
opens till close time. Its type is an int.
3.6.2. Constructor
The constructor is used to initialize all variables.
The array of workers is initialized with the size of MAX_CHECKOUTS
22
, the checkOut
variable is pointed to its class CheckOut and the supermarketOpenTime contains the
least between SUPERMARKET_CLOSE_TIME
23
and SUPERMARKET_OPEN_TIME
24
.
The next step is to initialize the workers; there is a loop that depending on the quantity
of MAX_SPECIAL_CHECKOUTS
25
creates a custom or a special checkout passing their id
and checkOut variables. After that loop, there is another that sets the customers
depending on supermarketOpenTime
26
; customers are created with an id and the
checkOut variables.
Finally, the Boolean of closed is set to false.
3.6.3. Operations
main: Its the starting point for the execution of the code in the application. There are
initialized the constructor and the operations that are going to be executed.
placeWorkers:
o Receives:
o Returns:
o Executes: This operation consists in a loop that starts the threads of the
workers array.
openSupermarket:
o Receives:
o Returns:
o Executes: This operation consists in a loop that starts the threads of the
customers arrayList.
closeSupermarket:
o Receives:
o Returns:
o Executes: This operation waits for the finalization of the customer threads
using the join method. After that it gets the summaries of the checkouts
(getSummary
27
), changes the value of the closed Boolean into true and after
calling the goHome
28
operation for each worker, it closes the supermarket

22
See Supermarket class
23
See Supermarket class
24
See Supermarket class
25
See Supermarket class
26
See Supermarket class
27
See getSummary operation in CheckOut class
28
See goHome operation in CheckOut class
with closeSupermarket
29
operation finishing the application and printing all
the results on the screen.

Figure 8: Supermarket class details

29
See closeSupermarket operation in CheckOut class
4. Process phases
When the application is executed there can be seen a principal way that later on is divided on
two: what the worker does and what the customer does. The process is based in threading and
their synchronization, so there can be seen an interaction between customer and worker using
the checkout. After their execution, they join the principal way again, finishing the execution.
The figure below (Figure 8) shows the interaction between Customer
30
and Worker
31
, an
asterisk means that the process changes a Boolean variable state which unlocks the next step
execution. When a customer or a worker calls a synchronized operation and inside it there is a
wait method, the caller is slept and every time the notifyAll is called it is woken up and
tries to execute the next step, if someone is ahead, it falls asleep again.

Figure 9: Customer/Worker interaction
4.1. Supermarket
When the application is launched this is the first thing what happens, the supermarket opens
its doors, positions the workers and creates all customers. After all customers are gone, it gets
the summary of each checkout, makes the workers go home and it closes.
The figure below (Figure 8) shows the supermarket behaviour as a flow chart.

30
See 4.3 point
31
See 4.2 point

Figure 10: Supermarket flow chart
4.2. Worker
When the supermarket is opened and places worker
32
, each worker starts waiting for a
customer. Once a customer has entered its queue and reached the checkout, charges the
customer after being paid and updates the values of the customers and items treated quantity.
This process is repeated while there are no more customers and supermarket is closed when
that happens, they go home.
The figure below (Figure 9) shows the worker behaviour as a flow chart.

Figure 11: Worker flow chart
4.3. Customer
After the doors of the supermarket are opened, customers are created, each one has to park
the car and this takes some time, but the car park has a limit, so if the limit is reached, they
leave the supermarket without doing the shopping.

32
Special workers are placed too, but at the moment the only difference is that customers have an item
limit to use them.
If the customer enters in the supermarket, makes the shopping, that takes some time. After
doing it, each customer checks if the queues are available, as there are two kinds of checkouts,
if it has less than one specific quantity of products, it first looks the special checkout queues, if
they are full, continues trying with the custom ones. If after a few intents (predefined) it has
not entered a queue, it leaves the supermarket without doing the shopping.
Once the customer has selected a queue without any problems, it waits in the queue until it
turn, when this happens, it started paying and after that it completes a survey giving the
information of how much time has wait in the queue. Finally the customer leaves the
supermarket successfully with the shopping done.
The figure below (Figure 10) shows the customer behaviour as a flow chart.

Figure 12: Customer flow chart


4.4. Interpreting the output
--SUPERMARKET OPENED--: This means that the supermarket has just been opened.
WorkerN placed in checkout: This means that the customer number N has been placed
in the assigned checkout.
CustomerM parking the car: This means that the customer number M is parking the
car.
CustomerM is gone because supermarket car park is full: This means that the car park
maximum capacity to harbour cars has reached and the customer number M has left
the supermarket without even entering inside.
CustomerM enters supermarket: This means that the customer number M has entered
the supermarket.
CustomerM shopping...(X): This means that the customer number M is doing the
shopping and it has taken X number of items in the trolley.
CustomerM leaves supermarket(X) after trying to get in a queue N times: This means
that the customer number M has left the supermarket because it tried to access in a
queue more than N times. The X number means how many customers are in the
supermarket.
CustomerM waiting in queue(X) for checkOutN: This means that the customer number
M is waiting in the queue for the checkout number N. The X number means the
amount of customers waiting in the queue.
CustomerM has paid in checkOutN and leaves supermarket(X): This means that the
customer number M has paid in the checkout number N and has left the supermarket.
The X number means the amount of customer in the supermarket.
CustomerM waiting time: X: This means that the customer number M has wait X time.
///////NO QUEUES AVAILABLE////////: This means that all queues are full and the
customer has to wait to enter one.
********CheckOutN summary******: This means that the summary of the number N
checkout begins.
o Total clients treated: X: This means that X number of customers have been
treated by the checkout number N.
o Total items treated: X: This means that X number of items have been treated
by the checkout number N.
Total treated customers: X: This means that X number of customers have been treated
totally since the supermarket opened till close time.
Total treated products: X: This means that X number of items have been treated totally
since the supermarket opened till close time.
Lost customers because queue availability: X: This means that the supermarket has lost
X number of customers because they have tried to enter a queue unsuccessfully.
Lost customers because car park availability: X: This means that the supermarket has
lost X number of customers because the lack of spaces in the car park.
Average products per trolley: X: This means that X amount of items are the general
average in each trolley.
Average wait time per customer: X: This means that the customers has spent X time in
average since they enter a queue until they left the supermarket.
WorkerN has gone home: This means that the worker number N has gone home.
--SUPERMARKET CLOSED--: This means that the supermarket is closed.

5. Testing the application
It must be said that applications that contains threads inside are not easy to test, because you
can get the same result 99% of the times, but get an error when the other 1% is executed. The
testing of this application has been carried out, mostly, by the use of the debugger the Eclipse
IDE provides.
Both tests have been done after the application was finished, making the test as easy as
changing final variables. It must be said that all variables and operations have been declared as
public to have access to them in every part of the code, making their tracking easier.
5.1. Worker behaviour test
To test the worker behaviour only one worker was executed, so all customer are going to use
the checkout assigned to it. As the worker is a thread, the run method is the only interesting
one for testing, so a breakpoint is set in it there and in the operations it calls to check the
successfulness of all steps. Once the application is launched on the debug mode, the results
are the following:
1. The worker is successfully placed and has a checkout assigned
2. As the Boolean of the supermarket status is false, it enters the loop.
3. The worker is waiting.
a. When a customer came it wakes up
4. Changes the availability status
5. Waits until its paid
a. When the customer pays it wakes up
6. Changes the status of the checkout and says to the customer that it was already
charged.
These six steps were repeated while the amount of customers in the supermarket is 0. Apart
from the debug, the system prints out all the activity, so it is quite easy to track what is going
on.
5.2. Customer behaviour test
The customer behaviour is more difficult to track, but the well-structure of the application has
helped a lot in this aspect. For example the naming of the operations is very logic, so the steps
can be distinguished easily. There are two types of customers, the ones that have been treated
successfully and the customers that have left the supermarket due to some reason.
As all customers are threads, the only interesting operation inside the class is the run; that is
why a breakpoint is set there before the debugging process. Once the application is launched,
the results are the following.
5.2.1. Successfully treated customer
1. The customer is successfully created and tries to enter the supermarket
2. As there are no customers, the customer enters the supermarket
3. The customer makes the shopping
4. The customer selects a queue
5. The customer enters a queue
6. The customer updates the value of the pay status
a. Waits until the worker charges
b. Once it happens it wakes up
7. Changes the control values
8. Passes its wait time values to the application
These steps are executed by every successfully treated customer. Apart from the debug, the
system prints out all the activity, so it is quite easy to track what is going on.
5.2.1. Unsuccessfully treated customer
Here there are two kinds of customers too, the ones that leave the supermarket even entering
inside and the ones that after making the shopping has left the supermarket. For both of them,
the debug breakpoint is set in the selectQueue
33
and enterSupermarket
34
operations.
Without entering the supermarket:
1. The customer is successfully created and tries to enter the supermarket
2. The supermarket is full and the customer cannot enter
3. The customer leaves the supermarket
After entering the supermarket:
1. The customer is successfully created and tries to enter the supermarket
2. As there are no customers, the customer enters the supermarket
3. The customer makes the shopping
4. The customer selects a queue
5. The customer reaches the maximum attempts permitted to access a queue
6. The customer leaves the supermarket
As is said previously, apart from the debug, the system prints out all the activity, so it is quite
easy to track what is going on.
5.3. Encountered errors
While the testing has being done, there have been encountered some errors, most errors are
related with the threading issue, but there are few ones linked with logic.
About logic issues, the biggest trouble has been to find a logic to select a queue properly, this
happens because if the customer can use a special checkout priories the use of them. If they
are not available, it looks at the customs, as it happens in real life. The issue is that the
customers for custom checkouts and special checkouts must be separate; this provides the
amount of customers for each type of checkout.
On the other hand, the biggest issue related to threading was that after all the execution the
workers continued running. To fix this problem the application was modified to print out the
living status of each worker thread, the result was that they were waiting for something. That
did not make sense at first because there were no customers in the supermarket. So after
several tests, the problem was found. The workers were waiting for customers because the

33
See selectQueue operation in CheckOut class
34
See enterSupermarket operation in CheckOut class
loop before the wait method in waitCustomer
35
operation specified that the thread had to
wait until there were no customers. That is true, but when there were no customers in the
supermarket workers were waiting for them the solution has been to add a new rule where
says that the wait must be called while there are no customers in queue AND the
supermarket is open.

35
See waitCustomer operation in CheckOut class