1. Lab4 Modeling the Conveyor Agent for the Grocery Checkout System
COP 4331: OO Processes for SW Development
© Dr. David A. Workman
School of EE and Computer Science
March 22, 2007

2. Lab Requirements
Following the process presented in class for modeling the Shopper, Clerk and Bagger; you are to model the Conveyor Agent. (See slides included in this presentation as illustrations and a guide to this assignment.)
Deliverables:
A Powerpoint presentation for the Conveyor Design. This shall include a State Transition Diagram (see slides 18, 21, 22 )model of the Conveyor's behavior, a class interface specification (see slides 11, 13 and 14). The STD should include all the messages sent to each Agent and all the messages received from other agents.
Don't forget your title slide and page numbers.
February 28, 2007
(c) Dr. David Workman

3. Super Food Market Checkout Subsystem February 28, 2007
Aisle n
Aisle Width 1 2 9
Aisle 2
Aisle 1
Starting
Point
Aisle Delta
Exit
Shopper & Cart
Bagger
& Shopper
Exit
Cart Pool
Checkout
Queue
Sales
Register
Explain the flow of processing.
Conveyor
Bagging
Bin
bagger
Entry
clerk
Shopper
Enters
Bagger Returns
Cart
Checkout
Subsystem
February 28, 2007
(c) Dr. David Workman

4. Checkout Station Model
9:When the payment transaction has been completed and all bags have been loaded in the cart, the shopper leaves the store with the bagged groceries.
6: The shopper pays for the groceries and is given a sales receipt.
2: Shopper places plastic divider on conveyor after last grocery item.
5: When all items have been processed by the clerk, the shopper is presented with the total amount of the purchase.
1: Shopper unloads grocery items, if there is room on conveyor.
Cart
Cart
Shopper
Conveyor
Scales
&
Scanner
Bagging
Bin
Bagger
3: Conveyor has a fixed capacity in numbers of items and transports them at a constant rate to the clerk’s station.
Clerk
Sales
Terminal
7: When the cart has been unloaded, the shopper gives the cart to the bagger to be filled with bags of groceries.
4:Clerk removes grocery items from conveyor and enters their identity and price into the sales system. Some items are identified and priced by bar codes. Other items must by manually identified and weighed.
8:The bagger loads grocery bags with items that have been priced by the clerk. Bags are held in the bin until the cart becomes available from the shopper.
February 28, 2007
(c) Dr. David Workman

5. Activity Diagram for Use Case Flow
Bagger
Bag
Groceries
Bagger
Load Cart
With
Bags
Stop
Shopper
Unloads
Cart
Start
Shopper
Pay For
Groceries
Clerk
Price Checks
Items
February 28, 2007
(c) Dr. David Workman

6. Conveyor Model slot N slot 1 Shopper Clerk
N = Conveyor capacity in Slots.
RULES:
(1) A slot is the space that can be occupied by a single item.
(2) The shopper always deposits the next item at slot 1, when it is empty. (3) The clerk always removes an item from slot N, when it is full.
(4) If slot N is empty and at least one other slot is filled, the conveyor rotates one slot to the right. The amount of time necessary for the conveyor to rotate one slot position is a model parameter and is specified as a multiple of the simulation time granule.
February 28, 2007
(c) Dr. David Workman

7. Discrete Event Simulator: Architecture Diagram
February 28, 2007
(c) Dr. David Workman

8. Simulator Design: Class Diagram
See Notes
Simulator Design: Class Diagram
Interface and Control Layer
World
EventMgr *
Event *
All Active
Objects * 2
Agent
This layer consists of all active object classes. Active objects must be instances of some subclass of abstract class Agent. The simulation progresses as a result of Events created and serviced by Agents. An Event has four components: a Sender agent, a Recvr agent, an instance of some Message subclass, and an event time. When one Agent wishes to interact with another, it must do so by creating an Event that defines a “future” time at which the interaction will occur. The message component defines an action to the Recevr agent and possibly data necessary to complete the action.
Agent Layer
(Active Objects)
This layer contains all the derived subclasses of Message.
These classes are used to pass data for servicing interaction events
between Agents. Only recipient Agent classes know the content and use of instances of these classes. Methods of Agents receiving messages optionally take parameters which are instances of one (or more) of the Passive classes and return an instance of class Message or one of its sub-classes. Instances of the root class Message carry no data and denote signals that require some action on the part of the receiver Agent.
Message * 1
Other
Subclasses
Players
Message Layer
Interface and Control Layer
Class CMIIS defines and represents the “Simulated or Virtual World”. An instance of this class is the object to be simulated. One of its methods, Simulate(), controls the simulation by remove Events from the EventMgr and dispatching the contained Message instance to the designated receiver Agent. The receiving Agent acts on the Message it receives which may spawn new Events that are posted to the EventMgr. This scenario repeats until all Events have been dispatched and the Event queue (encapsulated by EventMgr) becomes empty.
Message Classes
Messages contain two important data members, a message handler id or code, and, optionally, a Passive data object that is needed by the message handler to execute the requested action. Message instances are created by the receiver Agent class – for each potential incoming message, the receiver Agent class assigns an integer code that identifies the private message handler that will be called to service or act on the message when it is received during simulation. Message handlers are called by the Dispatch method of the receiver Agent class – the Dispatch method uses the handler code to identify an internal private method that will act on the message data (if any). * *
All Passive
Classes/Objects
Passive Class Layer
The Passive layer contains all classes that model problem data and inanimate objects of the simulated world. Agents make direct calls on passive objects, but must account for the simulation time consumed when doing so. Passive objects make direct calls to each other, if necessary. Passive objects may be passed from one Agent to another as part of a instance of some Message subclass.
SimModels Classes
SimMgmt Classes
February 28, 2007
(c) Dr. David Workman

9. Discrete Event Simulator : SimMgmt
EventMgr
Agent
Message
simtime: int
sendr: Agent *
recvr: Agent *
msg: Message *
eventQ: List<Event>
Name: string
handler: int
descr: string
Agent() Initialize( Message * )
Dispatch( Message * )
Operator<< ( ofstream&, &Agent )
Operator>> ( ifstream&, &Agent)
+Extract( ifstream& ) +Insert( ofstream& )
#Get( ifstream& )
#Put( ofstream& )
NameOf(): String
EventMgr()
PostEvent( Event )
NextEvent(): Event
MoreEvents(): Boolean
Clock() : Simtime
GetSendr(): Agent *
GetRecvr(): Agent *
Message( int, string )
GetId(): int
Operator <<
Event( Time, Sendr Recvr, Msg )
GetSndr(): Agent *
GetRecvr(): Agent *
GetTime(): int
GetMsg(): Message *
Operator <<
An concrete class.
All Messages denote an interaction event that must be serviced by the recipient agent. The agent dispatch method uses the Id to determine the method of the agent that should be called to service the event. This class is extended by the agent to define the data needed by the
Method called to service the event.
The encapsulated event queue. The queue orders posted events by their Time.
The Clock() always returns the current simulation time.
The object by which active objects interact.
An abstract class.
All active agents of the simulated world must be derived subclasses of this class. The Dispatch() method interprets the Message of the receiver agent.
February 28, 2007
(c) Dr. David Workman

10. Discrete Event Simulator: Virtual World Interface
World(): The Constructor – it invokes the constructors of all “parts” of the simulated world that must exist when simulation starts. Each constructor parses its image from an input file.
Initialize(): This method “connects” the active agents that may need to interact during simulation. Each Agent is given an opportunity to “prime” the EventMgr to start the simulation.
Simulate(): This manages the simulation loop and outputs events to the simulation log. It may also serve to update the simulation display.
Insert(): This method outputs to the simulation log the instantaneous state of the simulated world object – it calls Put for each “part”, etc.
WrapUp(): This is the postmortem analysis method. It controls any clean up and display of simulation results.
World
World()
Initialize()
Simulate()
Insert()
WrapUp()
The object that represents the simulated world. It is the only interface with the application main()
February 28, 2007
(c) Dr. David Workman

11. Agent Subclass Interface Structure
Subclass data members
Called by World object
+Constructor()
+Initialize( Message* players)
+Dispatch( Message*)
+Operator>>( ifstream&, Subclass&)
+Operatpr<<( ostream&, Subclass&)
+Extract() //default program input stream
+Insert() //default program output stream
#Get()
#Put()
Redefined inherited and virtual methods defined in Agent
Called by other Agent subclasses
+AcceptMsg1(…) //handler id = 1
+AcceptMsg2(…) //handler id = 2 …
+AcceptMsgk(…) //handler id = k
Public methods corresponding to messages this Agent subclass can receive. Each constructs an appropriate Message instance
encoding the handler id and message data.
Called by Dispatch()
-doAcceptMsg1(…) //handler id = 1
-doAcceptMsg2(…) //handler id = 2 …
-doAcceptMsgk(…) //handler id = k
Private message handlers corresponding to messages this Agent subclass can receive.
February 28, 2007
(c) Dr. David Workman

12. Example: Agent Design February 28, 2007 (c) Dr. David Workman Message
AlphaMsg
BetaMsg
DeltaMsg
BtoA(beta)
BtoB
AtoB(delta) B
BtoC
AtoC C
CtoA(alpha)
Passive Data Classes
Alpha Beta
Delta
February 28, 2007
(c) Dr. David Workman

13. Example: Agent Design February 28, 2007 (c) Dr. David Workman A
Subclass data members
+Constructor()
+Initialize( Message* players)
+Dispatch( Message*)
+Operator>>( ifstream&, Subclass&)
+Operatpr<<( ostream&, Subclass&)
+Extract() //default program input stream
+Insert() //default program output stream
#Get()
#Put()
Called by World object
Called by other Agent subclasses
+AcceptBtoA(alpha): AlphaMsg* //handler id = 1
+AcceptCtoA(beta):BetaMsg* //handler id = 2
-doBtoA(alpha) //handler id = 1
-doCtoA(beta) //handler id = 2
Called by Dispatch()
February 28, 2007
(c) Dr. David Workman

14. Example: Agent Design February 28, 2007 (c) Dr. David Workman C B
Subclass data members
Subclass data members
+Constructor()
+Initialize( Message* players)
+Dispatch( Message*)
+Operator>>( ifstream&, Subclass&)
+Operatpr<<( ostream&, Subclass&)
+Extract() //default program input stream
+Insert() //default program output stream
#Get()
#Put()
+Constructor()
+Initialize( Message* players)
+Dispatch( Message*)
+Operator>>( ifstream&, Subclass&)
+Operatpr<<( ostream&, Subclass&)
+Extract() //default program input stream
+Insert() //default program output stream
#Get()
#Put()
+AcceptAtoC(): Message* //handler id = 1
+AcceptBtoC(): Message* //handler id = 2
+AcceptAtoB(delta): DeltaMsg* //handler id = 1
- AcceptBtoB(): Message* //handler id = 2
-doAtoC() //handler id = 1
-doBtoC() //handler id = 2
-doAtoB(delta) //handler id = 1
-doBtoB() //handler id = 2
February 28, 2007
(c) Dr. David Workman

15. Case Study: Grocery Checkout
Bagger
Shopper Behavior Scenario
Agents:
Shopper
Clerk
Bagger
Conveyor
1: Unload Grocery from Cart
2a: Deposit Grocery on Conveyor
2b: Conveyor receives Grocery
Repeat (1 – 2b) Until Cart empty
3a: Deposit plastic bar on Conveyor
3b: Conveyor receives plastic bar
4a: Hand empty Cart to Bagger
4b: Bagger receives Cart
5: Clerk says pay Money
6: Give payment to Clerk
7: Clerk returns change
8a: Clerk returns receipt
8b: Clerk tells Bagger to release
loaded Cart
9: Bagger returns loaded Cart
4b,9 4a
See Notes!
2a,3a
Shopper
Conveyor
2b,3b
Passive:
Cart
Grocery
PlasticBar
Money
Receipt
1: Conveyor should be an Agent because it is an object shared by two other Agents (Shopper & Clerk) that can – in a realworld scenario – attempt to change its state simultaneously;
the Shopper by adding an item to the Conveyor, the Clerk by attempting to remove one.
5,7,8a 6 8b
Clerk
February 28, 2007
(c) Dr. David Workman

16. Case Study: Grocery Checkout
Shopper
Agent
+Shopper()
+Initialize( Message* )
+Dispatch( Message* )
+Extract()
+Insert()
#Get()
#Put()
Shopper
Bagger
Conveyor
Clerk
Message
MoneyMsg
CartMsg
ReceiptMsg
+ItemACK() Message*
+BarACK() Message*
+CartACK() Message*
+PayAmt( Money )MoneyMsg*
+ReturnChange(Money) MoneyMsg*
+ReturnReceipt( Receipt) ReceiptMsg*
+ReturnCart( Cart* ) CartMsg*
0..Nslots 1 1
Item
Money
Receipt
-doItemACK()
-doBarACK()
-doCartACK()
-doPayAmt( Money )
-doReturnChange(Money)
-doReturnReceipt( Receipt)
-doReturnCart( Cart* ) 1
Cart
Grocery
Bar *
BarCoded
Produce
February 28, 2007
(c) Dr. David Workman

17. State Transition Models
Activity
Start
[C] Event/Action
[C] Event/Action
Stop
[C] an [optional] boolean precondition that must be true before the Event can trigger a transition; no precondition implies the transition will occur unconditionally whenever the Event occurs in the system.
Event: a signal or message received that triggers a change in state.
Action: computation performed and/or message(s) sent in response to an event.
Activity: a state of processing that will continue until the next event; an activity could be a state of idleness.
February 28, 2007
(c) Dr. David Workman

18. [~1] ItemACK /DepositItem ReturnChange /Save Change
Shopper Model
Start
Unloading
Divider Sent
[1]
/Remove Item
/DepositItem
[~1] ItemACK /DepositItem
Messages Sent
DepositItem => Conveyor
TakeCart => Bagger
TakeCash => Clerk
TakeCredit => Clerk
ItemACK /TakeCart
[1] ItemACK
/Remove Item
/DepositItem
Wait ACK
Messages Received
ItemACK <= Conveyor
CartACK <= Bagger
PayAmt <= Clerk
ReturnChange <= Clerk
ReturnReceipt <= Clerk
ReturnCart <= Bagger
Transition Conditions:
[1] More items in Cart
[2] Cash >= Sales Total
PayAmt /Save Amount
CartACK
Cart ACK
Pay ACK
[2] PayAmt /TakeCash
[2]CartACK
/TakeCash
[~2]PayAMT
/TakeCredit
Wait Change
[~2]CartACK
/TakeCredit
Done
ReturnChange /Save Change
ReturnCart
/Save Cart
Wait Cart
Wait Receipt
ReturnReceipt
/Save Receipt
February 28, 2007
(c) Dr. David Workman

19. Case Study: Grocery Checkout
Shopper
void Shopper::Dispatch( Message* msg) throw(AppError) { int handler = msg->getId(); switch( handler ) { case 1: doAcknowledge(); break; …
default: throw AppError(" Unrecognizable Handler Id!"); }
-Wallet: Money
-Change: Money
-CartHandle: Cart*
-Conveyor, Bagger, Clerk: Agent*
-SalesRecord: Receipt*
-State: string ( initially = "start")
+Shopper()
+Initialize( Message* )
+Dispatch( Message* )
+Extract()
+Insert()
#Get()
#Put()
Message* Shopper::Acknowledged() { return new Message( 1, "Object Received.") }
// "1" is the handler id for: doAcknowledge().
void Shopper::doAcknowledged() { int simtime;
if( State =="Unloading" ) { if( CartHandle->IsEmpty() )
{ simtime = theEventMgr.Clock()+barDelay;
theEventMgr.PostEvent( Event( simtime, self, Conveyor,
Conveyor->TakeItem( new Bar() ));
State = "DividerSent"; return;
}else{ Grocery* groceryitem = CartHandle->getItem();
simtime = theEventMgr.Clock()+groceryDelay;
Conveyor->TakeItem( groceryitem )); return; }
}//unloading
}//end
+ItemACK() Message* //Change name (see Note)
+CartACK() Message* //Not needed (see Notes)
+PayAmt( Money )MoneyMsg*
+ReturnChange(Money) MoneyMsg*
+ReturnReceipt( Receipt*) ReceiptMsg*
+ReturnCart( Cart* ) CartMsg*
It is not necessary to have separate messages for acknowledging items and the cart. The internal "State" of the Shopper is sufficient to distinguish which acknowledgement is expected.
So only one message constructor is required for all types of acknowledgement – in fact, we should change the Shopper interface to offer only the method Acknowledge() Message*.
add
-doItemACK() // Change name(see Notes)
-doCartACK() //Not needed (see Notes)
-doPayAmt( Money )
-doReturnChange(Money)
-doReturnReceipt( Receipt)
-doReturnCart( Cart* )
-barDelay: int //Simulation input
-groceryDelay: int //Simulation input
February 28, 2007
(c) Dr. David Workman

20. Conveyor Model slot N slot 1 Shopper Clerk
N = Conveyor capacity in Slots.
RULES:
(1) A slot is the space that can be occupied by a single item.
(2) The shopper always deposits the next item at slot 1, when it is empty. (3) The clerk always removes an item from slot N, when it is full.
(4) If slot N is empty and at least one other slot is filled, the conveyor rotates one slot to the right. The amount of time necessary for the conveyor to rotate one slot position is a model parameter and is specified as a multiple of the simulation time granule.
February 28, 2007
(c) Dr. David Workman

21. Clerk Model February 28, 2007 (c) Dr. David Workman Start
Ring-up Items
Divider Received
[1] /RequestItem
[~1] ReceiveItem /PayAmount
/LastItemInBin
[1] ReturnItem
/RequestItem
TakeCredit /(update receipt)
[2]TakeCash /(update receipt)
/ReturnChange
Produce
Receipt
Make
Change
Transition Conditions:
[1] Grocery item received
[2] Cash Received > Sales Total
/ReleaseCart
/ReturnReceipt
Messages Sent:
RequestItem => Conveyor
LastItemInBin => Bagger
ReleaseCart => Bagger
PayAmt => Shopper
ReturnChange => Shopper
ReturnReceipt => Shopper
Messages Received:
ReturnItem <= Conveyor
TakeCash <= Shopper
TakeCredit <= Shopper
Done
February 28, 2007
(c) Dr. David Workman

22. LastItemInBin /CheckBin
Bagger Model
CheckBin /CheckBin
/[1]fill bag
Start
/CheckBin
/(open bag)
Bagging
Items
Sans Cart
Bagging Items
With Cart
TakeCart
Transition Conditions:
[1] More items in Bin
[2] No Items, but More Bags
[3] No Items, No Bags
LastItemInBin /CheckBin
CheckBin /CheckBin
/[1]fill bag
Last Item with Cart
Sans Release
CheckBin [1] /CheckBin
/[1]fill bag
Messages Sent:
CheckBin => Bagger
ReturnCart => Shopper
ReleaseCart [1]
/CheckBin
CheckBin [~1]
/CheckBin
Messages Received:
CheckBin <= Bagger
LastItemInBin <= Clerk
ReleaseCart <= Clerk
CheckBin [ 2 ]
/CheckBin
/load bag in cart
Fill Cart Sans Release
Bagging
Items with
Release
[2] ReleaseCart
/CheckBin
CheckBin [1] /CheckBin
/[1]fill bag
CheckBin [3]
CheckBin [~1]
Load Cart with Release
Wait for Release
CheckBin [3]
/ ReturnCart
CheckBin [2]
/CheckBin
/load bag in cart
ReleaseCart
/ReturnCart
Done
February 28, 2007
(c) Dr. David Workman