7.7 Summary
In this chapter, you have learned a few fundamental JSL model elements that facilitate the modeling of simple queueing situations. The classes and interfaces covered included:
EventGenerator
Used to cause a sequence of events to occur according to a pattern of time.
EventGeneratorActionIfc
Used to define a method that is called when an EventGenerator’s event is invoked
Station
An abstract base class that facilitates the receiving and send of QObjects within a model.
ReceiveQObjectIfc
An interface that defines a receive(QObjectIfc) method for receiving instances of the QQObject class.
SendQObjectIfc
An interface that defines a send(QObjectIfc) method for sending instances of the QQObject class.
SingleQueueStation
A concrete implementation of the abstract Station class that allows received instances of QObjects to wait in a Queue in order to use a resource (SResource).
SResource
A simple resource class that models units of capacity that can be seized and released.
The EventGenerator
class provides a reusable component that facilitates
the modeling of arrival processes. This was illustrated by modeling a
compound Poisson process as well as illustrating how to create objects
of user-defined classes (e.g. Order, Shirt, etc.). The station package
with the JSL allows the construction of networks of stations where
processing may occur. The SingleQueueStation
class is one example of the
kind of station that can be built. By using the ReceiveQObjectIfc
and
the SendQObjectIfc
a wide variety of additional components can be built
while taking advantage of the sending and receiving paradigm that is
often common in simulation modeling. We also introduced the SResource
class for modeling simple resource situations where a resource has a
capacity of units that can be used. How to model a simple shared
resource was also illustrated. With just these components you could
model a wide-variety of situations and build additional reusable
components.
As you perform your modeling, I strongly encourage you to plan your simulation model carefully (on paper) prior to entering it into a computer model. If you just sit down and try to program at the computer, the effort can result in confusing spaghetti code. You should have a plan for defining your classes and use a naming convention for things that you use in the model. I advise that you use some basic object-oriented program development methods such as the Unified Modeling Language (UML) diagrams and Class Responsibility Collaboration (CRC) cards. In addition, you should list out the logic of your model in some sort of pseudo-code. You should treat simulation model development like a programming effort.
The next couple of chapters will build upon the modeling foundations learned in this chapter.