Library Services problem statement sys 5110, sys 4124

8/9/2019 Library Services problem statement sys 5110, sys 4124

1/13

Evaluating Library Services

Problem DescriptionProblem Statement

Library management is considering improving the service at their closed stack library by adding

additional clerks to improve the time borrowers take to check out a book (that is the time from

which the borrower arrives at the service desk to the time the borrower leaves with the book). Inaddition, management is also interested in ensuring that clerks are sufficiently busy.

SUI Details

The diagram shows the setup of the library with aclose stack policy.

Library clerks are responsible for retrieving booksfrom the stacks for the borrowers.

Borrowers: A borrower checks, using the library

inventory system, that a book is available. Theborrower prints out a checkout slip for the desired

book using the library inventory system and

deposits it the service desk. The borrower thenwaits for his or her name to be called by a clerk to

obtain the desired book.

The library inventory system ensures thatthe borrower can check out only one bookand that it is available.

Clerks: A clerk picks up a maximum of 4 checkout

slips from the service desk. The clerks will thenretrieve the four books requested on the slips. The

clerk returns to the service desk and calls out the

names of each borrower for them to retrieve the requested books.

Checkout slips are picked up by clerks on a first-come, first-served basis. Books arereturned to customers also on a first-come first-serve basis.

If two or more clerks are idle when a borrower arrives at the checkout desk, the clerk whohas been idle the longest services the borrower.

If two or more slips are at the checkout desk and two or more clerks are available, theclerks DO NOT divide the work evenly among themselves. One clerk takes up to 4 slips;

then if there are still borrowers with slips to be picked up, the next clerk takes as many

slips as possible, and so on

C

Service Desk

Library Stacks

Library Clerks

B

B

BB

B

C

C

Checkout Slips

Depositing Checkout Slip

Waiting for Clerk with book

Receiving book


2/13

Project Goal

The main goal of this study is to find the effect of changing the number of clerks on the

utilization of the clerks and the average turnaround time for borrowers (time it borrowers stay inthe library after submitting a slip).

A steady-state study is to be used to study the operation of the library during the busy periodusing the number of customers served for terminating the simulation (note that although the busy

period is of finite time, for the purposes of the study, the busy period is being extended). A single

parameter has been definedthe number of clerks servicing borrowers (from the current 3 to 4and 5).

Parameters

numClerks: The number of clerks in the library.

Experimentation

Time units: minutes Observation interval: Steady state study.

The parameter numClerks is varied from 3 to 4 to 5, that is, there are three cases to this

project.

Output

avgBorrowerResponseTime:The average turnaround time of borrowers.

clerkUtil[numClerks]: Clerk utilization. This is a set of numClerk scalar values thatshows the utilization (percent time each clerk was busy).


3/13

ABCmod Conceptual Model

High Level Conceptual Model

Simplifications

Checkout slips are not explicitly modelled. Instead, the Customer entities serve as surrogatesfor the slips.

Structural View

Figure 1 Library Structural DiagramEntity Structures

1. Borrower: represents the persons arriving to borrow a book.

2. Clerk: A set of resource queue entities that represents the clerks that carry out the

retrieval of books.3. Slips: This queue represents the queue of checkout slips presented by the borrowers. Note

that the Borrower entities serve as surrogates for the slips.

4. ClerksIdle: This queue represents the queue of clerks that are idle. Note that identifiers tothe Clerk entities are found in this queue.

Notes:

Clerks can service up to 4 borrowers at a time. Servicing is completed (i.e. the check out)on a first-come first serve basis. Thus the Clerk entities have a dual roleresource andqueue.

Note that the slips are not explicitly modeled. When the Clerks are finding books usingthe slips, the Borrower entity is attached to the Clerk entity in lieu of an explicit Slip

entity. This represents the servicing of the Borrower by the Clerk (i.e. finding a book forthe borrower). This Queue role of the Clerk entity ensures that Borrower entities are

serviced on a first-come first-serve basis.

The diagram shown shows the state of the system when an idle clerk is about to pick upthe slips from 3 borrowers waiting for a clerk.

The ClerksIdle Queue contains identifiers of R.Clerk entities; this queue is required to

ensure that the clerk who has been idle the longest services borrowers first.

RQ.Clerk[numClerks]

iC.iC.iC.

Q.Slips

Q.ClerksIdle

1

iC.Borrower

Legend


4/13

Behavioural View

(a) Borrower Lifecycle b) Clerk Lifecycle

Library Behaviour Diagram

Scheduled Action Constructs:

BorrowerArrival: Arrival of borrowers to the checkout counter.Activity Constructs:

FindBooks: Condition activity where a clerk searches stacks for up to 4 books for theBorrowers.

Checkout: A conditional activity where the clerk checks out a single borrower after finding

their book.Notes

The FindBooks activity has been placed in the Borrowers life cycle. Although in reality theClerk is searching for books using the slips picked up from the borrowers (which means that

the Borrowers are not really interacting with the Clerk resource), and that the slips are notmodelled explicitly (instead the iC.Borrower entities are attached to the R.Clerk[j] entity to

represent the slips), the activity was included in the Borrowers lifecycle diagram. Theperspective adopted is that the FindBooks activity is one in which the Clerk services the

Borrower.

The Clerk initially starts in the wait point at the top of the Clerk Lifecycle diagram waitingfor slips to become involved in a FindBooks activity instance.

Input

Exogenous Input (Entity Streams)

Variable Description Domain Sequence Range Sequence

uBorrowerArr Input entity stream variable

for borrowers at the

checkout counter.

RVP.DuBorrowerArr() N/A1 borrower arrives at

each arrival time.

Endogenous Input (semi-independent)

Variable Description Values

uFindBooksTime Time to find books in the

stacks for 1 to 4 borrowers.

RVP.uFindBooksTime(num), where num defines the

number of borrowers.

uCheckOutTime Time to check out a book

for a borrower.

RVP.uCheckOutTime()

BorrowerArrival

FindBooks

CheckOutFindBooksCheckOut


5/13

Detailed Conceptual Model

Structur al Components

Constants

Name Description ValueMAX_SLIPS Maximum number of slips that the clerk picks upat the checkout desk to find books in the stacks.

4

Parameters

Name Description ValuenumClerks Number of clerks for servicing borrowers. 3, 4 and 5

Consumer Class: BorrowerA person wishing to borrow a book.

Attributes DescriptionarrivalTime Time the person arrived at the desk to check out a book. Used to compute the

response time.

Resource Queue Set[numClerks]: ClerkThe clerks for servicing the borrowers. The number of clerks available is defined by the parameter

numClerks. Since the entity can service multiple borrowers at the same time, in the same order that it

received the slips, the role of Queue has been added.

Attributes Descriptionstatus Set to IDLE when waiting for Borrowers (i.e. placed the Q.ClerksIdle), and

BUSY otherwise. This attribute is required to observe the amount of time the

Clerk is busy.

n Number of borrowers being serviced when Status is set to Busy (one to

MAX_SLIPS).

list List of iC.Borrower's being serviced. Slips are not explicitly modeled. Instead a

reference to the iC.Borrower is attached to the RQ.Clerk member.

servicing This attributes reflects the phase of servicing in which the Clerk is involved. Itis only significant when the Status attribute is set to BUSY. I can have one of

two values:

FINDBOOKS - when searching for books in the stacks

READYCHECKOUT - ready to check out a book with a borrower

CHECKINGOUT - checking out a book with a borrower.

Queue Unary: SlipsThe borrowers line up at the checkout desk to present a slip for borrowing a book. This queue

represents the line of borrowers waiting to give their slip to a clerk.

Attributes Descriptionn Number of borrowers waiting to give a slip to a clerk.

list List of references to iC.Borrower's waiting to give a slip to a clerk.

Queue Unary: ClerksIdleThis queue represents the clerks that are idle and waiting for slips from borrowers.

Attributes Descriptionn The number of idle clerks.

list The list of identifiers to RG.Clerk members that are idle.


6/13

Behavioural components

Time units: minutes

Observation interval: Steady state study.

Action: Initialise

TimeSequence < 0 >

Event SCS Q.Slips.n 0

num 0

WHILE(num < numClerks)

RQ.Clerk[num].status IDLE

SP.InsertQue(Q.ClerksIdle, num)

num num+1

END

Output

OUTPUTS

Trajectory Sets

Name DescriptionTRJ[RQ.Clerk[id].status] There are numClerk trajectory sets are defined: id is varied from 0 to

numClerks-1, to monitor thestatusattribute of each clerk

(RQ.Clerk[id].status).

Sample Sets

Name DescriptionPHI[responseTime] Collects the times it takes the response times for borrowers to check out a

book (from the time the borrower arrives at the checkout desk to the time he

or she leaves with the book). When the checkout procedure is completed for a

borrower, the time is computed as (t-iC.Borrower.arrivalTime).

Derived Scalar Output Variables (DSOV's)

Name Description Data Set Name Operator

AvgResponseTime The average response timefor borrowers.

PHI[responseTime] AVG

ClerkUtil[id] Where id is numbered 0 up

to numClerks-1. There are

numClerk scalar output

variables defined, one for

each clerk in the model.

TRJ[RQ.Clerk[id].Status] AVG

User Defined Procedures

User Defined Procedures

Name DescriptionClerkReadyToCheckOut() This procedure returns an identifier for an RQ.Clerk member that is

ready to checkout a book with a borrower. This conditions exists when:

1) Thestatusattribute of the member is set to BUSY

2) Theservicingattribute of the member is set to READYCHECKOUT

2) The nattribute of the member is non-zero.

If no RQ.Clerk member is ready to check out the books, the procedure

returns NONE (-1).


7/13


8/13

Behavioural Constructs

Activity: FindBooksPickup slips and find the books in the stack.

Precondition (Q.Slips.n > 0) AND (Q.ClerksIdle.n > 0)

Event SCS clerkId SP.RemoveQu(Q.ClerksIdle)

IF(Q.Slips.n > MAX_SLIPS)

numSlips MAX_SLIPSELSE

numSlips Q.Slips.n

ENDIF

num 0

WHILE (num < numSlips)

iC.Borrower SP.RemoveQu(Q.Slips)

SP.InsertQu(RQ.Clerk[clerkId], iC.Borrower)

num num+1

ENDWHILE

RQ.Clerk[clerkId].status BUSY

RQ. Clerk[clerkId].servicing FINDBOOKS

Duration RVP.uFindBooksTime(RQ.Clerk[clerkId].n)

Event SCS RQ.Clerk[clerkId].servicing READYCHECKOUT

Activity Construct: CheckOutTime to process the end of the checkout of books with each customer.

Precondition UDP.ClerkReadyToCheckout() NONE

Event SCS clerkId UDP.ClerkReadyToCheckOut()

RQ.Clerk[clerkId].servicing CHECKINGOUT

Duration RVP.uCheckOutTime()

Event SCS iC.Borrower SP.RemoveQu(RQ.Clerk[clerkId])

SP.Put(PHI[ResponseTime], t - iC.Borrower.arrivalTime)

SP.Leave(iC.Borrower)

IF(RQ.Clerk[clerkId].n = 0)

RQ.Clerk[clerkId].status IDLE

SP.InsertQu(Q.ClerksIdle, clerkId)ELSE

RQ.Clerk[clerkId].servicing READYCHECKOUT

ENDIF

Design of Verification/Validation Experimentation

Given the simplicity of the model, it is possible to validate the model using a trace log as

described below.

Trace Logging

The state of the simulation model is monitored by tracking the length of the two queues and eachof the RQ.Clerk resource queues.. These values are presented as follows (shown for 3 clerks):-------->Clock: xxx


9/13

Simulation Model

Design of Simulation Model and Program

The simulation model is implemented in the class Library(an extension of the ABSmod/J class

AOSimulationModel) and a number of other classes used to implement the various constructs

from the ABCmod conceptual model. All Java classes that make up the Java Library simulationmodel are placed in the Java package librarySimModel.

The following table shows how the various ABCmod entity structures are mapped to Java

classes and how objects instantiated from these classes are reference by the Libraryclass.

Entity Structures

ABCmod

Construct

Java Class Object References

iC.Borrower Borrower Typically by the reference

variable icBorrowerin thevarious methods that

manipulate Componentobjects.

RQ.Clerk Clerk

The enum types Statusand Servicingaredefined to restrict the values of the status andservicing attributes respectively. The list

attribute is implemented as a reference variable

listto an ArrayListobject. The methods

getN()provides the value of the attribute n and

the method spRemoveQue()implements thestandard procedure SP.RemoveQue for the entity.

Library.rqClerk

The above reference

variable references an array

of numClerksClerkobjects.

Q.SlipsArrayList

The queue is implemented using the ArrayList(standard Java Class), referenced by the private

reference variable qSlipsNotes

The various methods available in the

ArrayListclass provide the implementationof the various ABCmod procedures, such as

SP.InsertQue (qSlips.add) SP.RemveQue

(sqSlips.remove).

The attribute n is maintained within the

ArrayListobject (adjusted automaticallywhen ArrayListmethods are called). The

method qSlips.size()provides the value ofthe Q.Slips.nattribute.

Library.qSlips

The above reference

variable references an

ArrayList object.


10/13

Q.ClercksIdle ArrayList

The queue is implemented using the ArrayList(standard Java Class), referenced by the private

reference variable qSlipsNotes

See the description of Q.Slips for the use ofthe various ArrayList methods to implement

attributes and standard procedures.

Note that since RQ.Clerk (with scope=Set)

are queued, the identifiers, i.e. integer values,

are stored in the queue. Java autoboxingwith convert integers to/from Integer objects.

Examples (clerkIdis an integer variable):

o qClerksIdle.add(clerkId)o clerkId = qClerksIdle.remove(0)

Library.qClerksIdle

The above reference

variable references an

ArrayList object.

The following table provides mapping between the conceptual model Action/Activities to Java

classes.

Actions/Activities

ABCmod Constructs Java Classes

BorrowerArrival BorrowerArrival

FindBooks FindBooks

CheckOut CheckOut

Other classes that make up the Library ABSmod/J simulation model include:

Output(referenced by Library.output): Contains the Trajectory sets and methods forcomputing the DSOVs.

RVPs(referenced by Library.rvp): Contains the Java methods used to implement the CMRVPs.

UDPs(referenced by Library.udp): Contains the Java methods used to implement the CMUDPs.

Seeds: The class used to pass seeds for random number generators used in implementing thevarious RVPs.

The package librarySimModelprovides public access to the following:

The constructor Libraryto allow creation and initialisation of a Manufacturingobject,

The methods getAverageResponseTime(),getClerkUtil(),access the value of the output

variables avgResponseTime, clerkUtil[id] respectively.

The methods clearAllOutput() andclearResponseTimeOutput() to support the warmup time.

All public methods provided by the class AOSimulation(e.g. runsimulation) for

supporting experimentation.


11/13

Results of the Verification/Validation Experimentation

Beginning of the observation intervalRun with 3 clerks

-------->Clock: 0.0Clock: 2.0252182936660885Clock: 6.519692166753867Clock: 7.519692166753867Clock: 13.839792900157727Clock: 15.026303443584254Clock: 16.016732145570312


12/13


13/13

Documents

Library Services problem statement sys 5110, sys 4124