Presentation is loading. Please wait.

Presentation is loading. Please wait.

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.

Similar presentations


Presentation on theme: "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."— Presentation transcript:

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 February 28, 2007(c) Dr. David Workman2 Lab Requirements 1.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.) 2.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.

3 February 28, 2007(c) Dr. David Workman3 Super Food Market Entry Exit Aisle 1 Aisle 2 Cart Pool Conveyor Aisle Delta Checkout Queue clerk Aisle n Aisle Width Starting Point Sales Register Bagging Bin bagger Shopper Enters Bagger Returns Cart Bagger & Shopper Exit Checkout Subsyste m Shopper & Cart

4 February 28, 2007(c) Dr. David Workman4 Checkout Station Model Conveyor Scales & Scanner Clerk Bagging Bin Sales Terminal Bagger Shopper Cart 1: Shopper unloads grocery items, if there is room on conveyor. 2: Shopper places plastic divider on conveyor after last grocery item. 3: Conveyor has a fixed capacity in numbers of items and transports them at a constant rate to the clerk’s station. 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. 5: When all items have been processed by the clerk, the shopper is presented with the total amount of the purchase. 6: The shopper pays for the groceries and is given a sales receipt. 7: When the cart has been unloaded, the shopper gives the cart to the bagger to be filled with bags of groceries. 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. 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.

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

6 February 28, 2007(c) Dr. David Workman6 Conveyor Model 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. slot N slot 1 ShopperClerk N = Conveyor capacity in Slots.

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

8 February 28, 2007(c) Dr. David Workman8 Simulator Design: Class Diagram See Notes 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. 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. World Message Players Agent Event 2 Passive Class Layer Message Layer Agent Layer (Active Objects) Interface and Control Layer EventMgr * 1 Other Subclasses All Active Objects * * All Passive Classes/Objects * * * 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. SimModels ClassesSimMgmt Classes

9 February 28, 2007(c) Dr. David Workman9 Discrete Event Simulator : SimMgmt Event Event( Time, Sendr Recvr, Msg ) GetSndr(): Agent * GetRecvr(): Agent * GetTime(): int GetMsg(): Message * Operator << simtime: int sendr: Agent * recvr: Agent * msg: Message * The object by which active objects interact. EventMgr EventMgr() PostEvent( Event ) NextEvent(): Event MoreEvents(): Boolean Clock() : Simtime GetSendr(): Agent * GetRecvr(): Agent * eventQ: List The encapsulated event queue. The queue orders posted events by their Time. The Clock() always returns the current simulation time. Agent Agent() Initialize( Message * ) Dispatch( Message * ) Operator<< ( ofstream&, &Agent ) Operator>> ( ifstream&, &Agent) +Extract( ifstream& ) +Insert( ofstream& ) #Get( ifstream& ) #Put( ofstream& ) NameOf(): String Name: string 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. Message handler: int descr: string Message( int, string ) GetId(): int 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.

10 February 28, 2007(c) Dr. David Workman10 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()

11 February 28, 2007(c) Dr. David Workman11 Agent Subclass Interface Structure Subclass 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() +AcceptMsg1(…) //handler id = 1 +AcceptMsg2(…) //handler id = 2 … +AcceptMsgk(…) //handler id = k -doAcceptMsg1(…) //handler id = 1 -doAcceptMsg2(…) //handler id = 2 … -doAcceptMsgk(…) //handler id = k Redefined inherited and virtual methods defined in Agent Public methods corresponding to messages this Agent subclass can receive. Each constructs an appropriate Message instance encoding the handler id and message data. Private message handlers corresponding to messages this Agent subclass can receive. Called by other Agent subclasses Called by Dispatch() Called by World object

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

13 February 28, 2007(c) Dr. David Workman13 Example: Agent Design 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() +AcceptBtoA(alpha): AlphaMsg* //handler id = 1 +AcceptCtoA(beta):BetaMsg* //handler id = 2 -doBtoA(alpha) //handler id = 1 -doCtoA(beta) //handler id = 2 Called by other Agent subclasses Called by Dispatch() Called by World object

14 February 28, 2007(c) Dr. David Workman14 Example: Agent Design C 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() +AcceptAtoC(): Message* //handler id = 1 +AcceptBtoC(): Message* //handler id = 2 -doAtoC() //handler id = 1 -doBtoC() //handler id = 2 B 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() +AcceptAtoB(delta): DeltaMsg* //handler id = 1 - AcceptBtoB(): Message* //handler id = 2 -doAtoB(delta) //handler id = 1 -doBtoB() //handler id = 2

15 February 28, 2007(c) Dr. David Workman15 Case Study: Grocery Checkout Agents: Shopper Clerk Bagger Conveyor See Notes! Passive: Cart Grocery PlasticBar Money Receipt Shopper Clerk Conveyor Bagger 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 Shopper Behavior Scenario 2a,3a 2b,3b 4a 4b,9 5,7,8a 6 8b

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

17 February 28, 2007(c) Dr. David Workman17 State Transition Models Activity Start [C] Event/Action [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. Stop

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

19 February 28, 2007(c) Dr. David Workman19 Case Study: Grocery Checkout Shopper +Shopper() +Initialize( Message* ) +Dispatch( Message* ) +Extract() +Insert() #Get() #Put() -Wallet: Money -Change: Money -CartHandle: Cart* -Conveyor, Bagger, Clerk: Agent* -SalesRecord: Receipt* -State: string ( initially = "start") +ItemACK() Message* //Change name (see Note) +CartACK() Message* //Not needed (see Notes) +PayAmt( Money )MoneyMsg* +ReturnChange(Money) MoneyMsg* +ReturnReceipt( Receipt*) ReceiptMsg* +ReturnCart( Cart* ) CartMsg* -doItemACK() // Change name(see Notes) -doCartACK() //Not needed (see Notes) -doPayAmt( Money ) -doReturnChange(Money) -doReturnReceipt( Receipt) -doReturnCart( Cart* ) Message* Shopper::Acknowledged() { return new Message( 1, "Object Received.") } // "1" is the handler id for: doAcknowledge(). void Shopper::Dispatch( Message* msg) throw(AppError) { int handler = msg->getId(); switch( handler ) { case 1: doAcknowledge(); break; … default: throw AppError(" Unrecognizable Handler Id!"); } 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; theEventMgr.PostEvent( Event( simtime, self, Conveyor, Conveyor->TakeItem( groceryitem )); return; } }//unloading }//end -barDelay: int //Simulation input -groceryDelay: int //Simulation input add

20 February 28, 2007(c) Dr. David Workman20 Conveyor Model 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. slot N slot 1 ShopperClerk N = Conveyor capacity in Slots.

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

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


Download ppt "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."

Similar presentations


Ads by Google