Sie sind auf Seite 1von 12

OSE560 TERM PROJECT

(2010-05-21)

Object-oriented Analysis of
Queuing System

Team Member:

Bongeun Goo
Chunhua Nan
Dongsuk Lee
Jinsun You
Joohee Lee
Wooyoung Choi

Professor: Hyun Chung


Contants
1. Introduction. .................................................................................................................................... 3
2. Object-Oriented Analysis................................................................................................................. 4
2.1 Use case Diagram. ................................................................................................................ 4
2.2 Class Diagram. ...................................................................................................................... 5
2.3 State Diagram. ...................................................................................................................... 6
2.4 Activity Diagram. ................................................................................................................. 8
3. Conclusion..................................................................................................................................... 12
1. Introduction.

Object
We analyzed and designed a queuing system with UML, which consist of
-Queue
-Server
-Entity
-And calling population

Our system simulates a dynamic behavior of various queuing system and satisfies followings
-designed as an object-oriented system
-should be capable of simulating the behavior of various configuration of queues and servers, i.e.,
single queue-single server a single queue-multiple servers.
-a queue can have fixed capacity or unlimited capacity
-the calling population can have fixed capacity and unlimited capacity
-the behavior of a queue can be FIFO (first in first out), FILO (first in last out), PR (Priority)
-the arrival process and service time can be Normal distribution or Poisson distribution.

What is UML
UML is acronym for Unified Modeling Language, which is one of the tool in the field of object
oriented system. Because it helps to visualize the vision of system developer, make others easy to
understand and share. We could organize diagrams and expand by UML.
Especially we draw following diagrams.
-class diagram
-use case diagram
-activity diagram
-state diagram

Link:
www.uml.org
http://en.wikipedia.org/wiki/Unified_Modeling_Language

What is Queuing System


Queuing system(Picture1) is organized with Population, Queue, Server. Entity comes from population
after IAT (inter arrival time), then puts on the queue. If any server is idle, entity on the queue moves to
server. Otherwise, if all servers are busy, entity waits on the queue. And as soon as server state
changes to idle, entity moves to server. After the service time, entity departs the server and goes back
to the population.
Picture 1 Queuing System.

2. Object-Oriented Analysis.
This queuing system has been designed as an object-oriented system by UML program included Use
case Diagram, Class Diagram, State Diagram and Activity Diagram.

2.1 Use case Diagram.

A Use case Diagram describes the proposed functionality of a new system. A Use Case represents a
discrete unit of interaction between a user (human or machine) and the system. This interaction is a
single unit of meaningful work, such as Create Account or View Account Details.

Each Use case describes the functionality to be built in the proposed system, which can include
another Use case's functionality or extend another Use case with its own behavior.

Our Use Case Diagram (Picture 2) is like a lower picture. User‘s behavior is to send massage to
system and get output from system. Send messages specify the condition and run the simulation.
Specifying the condition message sets up system to be prepared working and simulation. Specifying
the condition message is related to update information. This relationship is called extend. When
specifying the condition message inputs system, update information message is followed inevitably.

And user send run the simulation message which runs the simulation process. After the system takes
this message, system executes simulation program and outputs the result. When all of system‘s action
is completed, user wants to check the result of simulation. Therefore, user takes the get result message.
This is shown with pictures and texts.
Picture 2 Use case Diagram

2.2 Class Diagram.

This diagram (Picture 3) is divided by 3 parts; User Interface, FEL (Future Event List) and Queuing
System. Clock which is located between FEL and Queuing System controls time until Simulation
Time.

First, User Interface plays a role of getting data from a user, so it shows input forms. Simulator
included in User Interface has a Random Number Generator which makes random number according
to distribution chosen from the user, and calculates exact time information. We considered 2
distributions; one is Normal distribution that needs mean and deviation values, the other is Poisson
distribution that has mean and starting stream values. Rule Of Queue has 4 rules; Arbitrary, FIFO,
FILO, and PR. When the user chooses the Arbitrary, the system selects randomly 1 out of them. FIFO
treats entities by lower arrival time first, and FILO is an opposite manner to FIFO. PR handles entities
with PR sign first.

Second, FEL obtains all data from Simulator; we named data to the index. Event Notice has Event
Name and Event Time. Event Name checks changes of entity at each Event Time that makes System
State varied. It also manages Arrival, Departure, and Terminate. Whenever an entity comes in the
Queue, LQ (Length of queue) will be increased, and then the entity leaves from the queue to a server;
LQ will be decreased and LS (Server state) will be increased. Priority Number is needed to each entity
in order to arrange them in the queue.

Third, Queuing System has Population, Queue, Server, Entity, and Output. Population, Queue, Server
has a same function that counts entities and records them. Population has its size. Server has its
number and state (Idle/Busy). It measures busy time to calculate each server‘s utilization. Entity has
all data from FEL with low rank classes and obeys Event Notice‘s order. Queue counts accumulated
entities to calculate Queue Length. Sorting is happened, whenever events occur by rules. Output class
(Table 1) gathers all these recorded data together, and calculates them, then finally show the below
results on the monitor.
Output Formula(Class[Attribute or Operation])
Service time Server[measureBusyTime]
Idle Time Clock[simulationTime] - Server[measureBusyTime]
Utilization Each Server[measureBusyTime]/Clock[simulationTime]
Max. Queue Length Max(Queue[countAccumulatedEntities])
Avg. Queue Length Queue[countAccumulatedEntities]/ Clock[simulationTime]
No. of Entities Per Server Server[countDepartureEntities]
Total No. of Create Entities Population[countCreateEntities]
Total No. of Coming Back Entities Population[countComingBackEntities]
Max. Waiting Time Max(Queue[measureWaitingTime])
Min. Waiting Time Min(Queue[measureWaitingTime])
Table 1 Output Class

Picture 3 Class Diagram

2.3 State Diagram.


State diagrams, one of the dynamic models, are used to detail the transitions or changes of state,
when an object can go through in the system. They show how an object moves from one state to
another and the rules that govern that change. State charts typically have a start and end condition.

When a state is changed, an event is changed, too. State diagrams have their parameters which are
entry, do, and exit. Entry means what action or input message happens to change states. This is like a
beginning message. Do parameter is what activities are happened during changing states. For example,
do action is like hammering the nail to make chair. And last, exit action is when changing state is
completed what messages or data are emitted to next state.

In this system state has changed following diagram (Picture 4). System is getting input data and
checking it verified as general other programs. Queue simulation will be iterated so far as by the time
appointed, after system environment is set in accordance with input data, and initial value is applied.
Picture 4 State Diagram
2.4 Activity Diagram.
An Activity diagram is essentially a fancy flowchart Activity diagrams and state chart diagrams are
related. For our Activity Diagram (Picture 5, 6, 7) we used the following process
- Analyze given Single Queue – Multi Server system.

Swim lane
User
Program -

Explanation of Activity Diagram

Open program execution file


- Execute Program
Show GUI,require inputdata
- Display input data screen
Input data
- User input queue system conditions
Check data
- Check input data types. If, there are wrong data type go to ‗Send error massages‘ step. Else,
go to ‗Define Vector List‘ step.
Define Vector List
- Generate Vector list ‗EventNotice(EventName, EventTime, PriorityNumber)‘
Generate object
- Generate ‗EndOfSimulationTime‘, ‗NoOfServer‘, ‗InterArrivalTime‘, ServiceTime‘,
‗RuleOfQueue‘, ‗AcceptUserInput()‘, ‗DisplayInterfaceWindow()‘
Set initial simulation Environments
- Set Ls(t)=0, Lq(t)=0, setclock=0, output.*=0, IATdistribution, Servicetimedistribution,
No.OfServer, RuleOfQueue, TerminateEvent with EndOfSimulationTime
Generate initial notice & Pop. –
- Generate initial notice ‗EventNotice(A,0,0)‘ and Connect
‗EventNotice(T,EndOfSimulationTime,0)‘, also input Population = Population -1
Store on FEL
- At first, Resister ‗EventNotice(A,0,0)‘ and ‗EventNotice(T,EndOfSimulationTime,0)‘ on FEL.
After for Every Store on FEL EventNotice will be storeed by FEL arrange method. It showed
Store on FEL activity diagram.
Call time advance notice
- Call time advance notice, Find imminent event notice from F.E.L, Advance clock time to
imminent event time relate to simulation time control. In Call time advance notice step
include checking current time ―t‖. Of course initial value of ―t‖ is 0.
Find imminent event notice from FEL
- Find imminent event notice. And the imminent event notice‘s EventTime ―s‖ should be s ≥ t.
Advance clock time to imminent event time
- In this step, Program change current simulation time it would change ―t‖ to ―s‖
Get imminent EventNotice from FEL index
- Get first EventNotice on FEL. Its EventTime has same value of Current simulation time.
Check EventName
[If, Event=A]
- Then, Check Population size
[If, Population size > 0]
Record ClockTimeOfArrival
- Record event time of current EventNotice.
Generate new IAT and priority by Random#Generator and given distribution
- Set IAT & PR using Random#Generator And Record them.
Set new 'ArriveEventNotice with clock+IAT as EventClock(Arrive,clock+IAT,PR)
- Generate Vector list ‗EventNotice(EventName, EventTime, PriorityNumber)‘
Store on FEL
- For Every Store on FEL EventNotice will be stored by FEL arrange method. It showed Store
on FEL activity diagram.
Population.size—
- EventNotice is from Population. So, it has to consider population change.
[If, Population size = 0]
- Then, omit next arrival generation step. There is no population to entering current system.
[If, EventName=D]
- Then Execute Depart event step
Ls(t)—;
- In this step, one of server finished service. So, it shows one of server is empty.
Record ClockTimeOfDepart
- Record Departure time(Current Time) on ClockTimeDepart.
Population++
- One of Event is finish and return to population. So, represent it.
[If, Lq(t)!=0]
- It means queue has more than one of population. One of waiting arrival in queue moves to
empty servers.
Remove current eventnotice from FEL(reset index# of rest FEL)
- After finishing task, eventnotice is useless data on FEL. So, it needs to delete. Also this
method can save memory. Also after deleting, modify index values
Call Queue Rule
- This step calls QueueList and checks the behavior of queue type as FIFO, FILO, Priority.
- The list already arranged in ‗Store on Queuelist‘ step, so it just needs to take one value
following the rules.
[if and Ls(t)=0]
- Then, the arrival notice can take service in one of empty server.
Record ClockTimeOfServiceBegin
- Set current simulation time on ClockTimeOfServiceBegin
Generate servicetime by Random#Generator and give distribution
- Set Servicetime using Random#Generator and Record them.
Ls(t)++, Lq(t)—
- The empty Server take eventnotice to service so Ls(t) is increasing and Lq(t) is decreasing. If
Lq(t) is less than 0, set Lq(t) = 0.
Set 'Depart'eventNotice with clock+serviceTime as EventClock(Depart,clock+serviceTime,pr)
- Generate Departure eventnotice (D, clock+serviceTime, 0)
Store on FEL
- For Every Store on FEL EventNotice will be stored by FEL arrange method. It showed Store
on FEL activity diagram.
[If all Ls(t)=1]
- Server is full so Arrival needs to store in Queue
[If, Lq(t)=max.capacity]
- Queue can‘t admit. So, delete this eventnotice
[If Lq(t)<max.capacity]
- Queue store Arrival eventnotice
Lq(t)++
- Increase Queue length. It shows eventnotice is register in Queue
call Queue.Rule
- This step calls QueueList and checks the behavior of queue type as FIFO, FILO, Priority.
- The list already arranged in ‗Store on Queuelist‘ step, so it just needs to take one value
following the rules.
store on QueueList
- For Every Store on QueueList, EventNotice will be stored by Queue arrange method. It
showed Store on Queuelist activity diagram.

Picture 5 Activity Diagram


Picture 6 Store on FEL

Picture 7 Store on QL
3. Conclusion.
In this project, we analyzed and designed UML (Unified Modeling Language) diagram to represent
the behavior of the queuing system.

Queuing system in this project has been accurately designed as an object-oriented system by UML.

At first, we designed Use case Diagram.


Secondly, we did the fundamental object-oriented analysis of each system components and
collaborated objects to a class which have the same attributes and operations. Then, we defined the
relationship between classes. This is the Class Diagram.
According to the Class Diagram, we designed Activity Diagram and State Diagram.

These single queue-single server, single queue-multi server system which we designed are totally
satisfied the requirements. The calling population can have a fixed capacity and unlimited capacity,
and the queue can have unlimited capacity. Moreover, the behavior of a queue can be FIFO (First-In
First-Out), FILO (First-In Last-Out), and PR (Priority). The arrival process and service time can be
Poisson distribution and Normal distribution.

Before drawing UML Diagram, we discussed about the system and an agreement has been established
about that what kind of problem we would going to solve and the requirements need to be satisfied.
Then, we had meetings every several days. Not all meeting went smoothly. We had different ideas and
hard to decide which one is better and also, same idea with different words. For example, someone
use . It seems very important to make an agreement of not only problem description, but also the same
words, at the beginning. During the meeting, again and again, we evaluated our system and diagrams
better and better. Moreover, we recognized that this kind of project cannot be completed at once,
though, sharing ideas and communication is much more important. If we have more time, we could
have progressed this project step by step and also use some software system to make simulation about
this queuing system.

However, we could not validation the modeling of our queuing system because we did not simulate by
software. After finishing UML diagram, we are not sure whether it has errors or not.

In the future, we could design multi queue, multi server system and also consider about the queuing
system having different types of entities. And also, using software system, such as C++, to simulate
the queuing system and compare it to the mathematical queue formulations.