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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[~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

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

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

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

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