sdpsem2t03dynamicmodelanswernotes

12
Tutorial answer notes Notes on the Coffee Shop exercise Some Assumptions: There are only two tables and one waiter The scenario starts when the customer generates an order Customer Name/Id Attributes (What I know) No Ordered Colas Beers Hamburgers Cakes Table_no Visibility (Who I know) The waiter Methods (What I do) Generate order : Decide order Update my attributes Tell waiter “Process_Order(C,B,H,C,table_no)” Eat(C,B,H,C) Check Eat …(simulate eating) Ask For Bill(table_no) Tell the waiter “Get_bill(table_no)” Pay(tendered_amount)

Upload: hanaomar

Post on 04-Sep-2015

212 views

Category:

Documents


0 download

DESCRIPTION

model answer

TRANSCRIPT

Tutorial answer notes

Notes on the Coffee Shop exercise

Some Assumptions: There are only two tables and one waiter The scenario starts when the customer generates an order

Customer Name/IdAttributes (What I know)No Ordered

Colas

Beers

Hamburgers

Cakes

Table_no

Visibility (Who I know) The waiter

Methods (What I do)

Generate order : Decide order Update my attributes Tell waiter Process_Order(C,B,H,C,table_no)

Eat(C,B,H,C) Check Eat (simulate eating)

Ask For Bill(table_no) Tell the waiter Get_bill(table_no)

Pay(tendered_amount) Tell the waiter Process_payment(tendered_amount,table_no)

WaiterName/IdAttributes (What I know)

Table1Table2

Colas

Beers

Hamburgers

Cakes

State of the table (free, New cust, Ordered, Delivered, Bill ordered, Waiting for change, Paid)

Visibility (Who I know) Customers, Cashier, Cook

Methods (What I do)

Process order(C,B,H,C,table_no) : Change state Update my attributes Tell cook Prepare order (C,B,H,C, table no) Tell cashier File_Order(C,B,H,C, table no)

Collect_order(C,B,H,C, table no) Check Change state Tell the customer Eat(C,B,H,C)

Process Payment(amount) Tell Cashier Calculate Change(amount, table no) Return Change

Get_bill(table_no) Tell cashier Calculate Bill(table no) Return Bill

CashierName/IdAttributes (What I know)

PricesTable1Table2

Colas.50

Beers1.20

Hamburgers1.99

Cakes5

Visibility (Who I know) Nobody ( the waiter comes to me!)

Methods (What I do)

File_Order(C,B,H,C, table no) Update table data

Calculate Bill(table no) Calculate Bill Return to waiter

Calculate Change(amount, table no) Calculate change Return to waiter

Cook Name/Id

Attributes (What I know)

Stock

Colas30

Beers3

Hamburgers50

Cakes6

Visibility (Who I know) I know of the waiter (only for call back)

Methods (What I do)

Prepare order (C,B,H,C, table no) Update stock Cook Tell waiter collect_order(C,B,H,C,table no)

Notes on the Lift case study notes

Use case diagram (first-cut)

Brief first description of Use Cases (as seen from the customer- for requirements specification purposes):

Set-up:The User specifies the parameters of the simulation (such as number of passengers, lifts, floors, duration of the simulation etc. The system then initialises using that data.At the beginning each passenger decides (or is it decided for him/her?) what time they first join a queue for a lift, which floor they originate from and which floor they want to go to. (there is only one queue per floor). At the beginning, all lifts are at ground floor (but we do not need to burn our bridges on this)

Run Simulation: This use case can have some - students are expected to notice it.For every simulated time step (tick of the clock) two things may happen: a passenger may decide it is the time to join the queue A lift may do one of the following: Move (note simplification: lifts are stopping at all floors) Open the doors This will have the effect of first unloading everyone that needs to be at that floor and then loading anybody that is waiting (subject to capacity). People are stupid: they get in the lift, even if it is going the other way. Close the doors- The whole process is visualised in simulation time

Get statistics:At the end of the simulation, the user may decide to get stats. The ensuing scenario collects all the relevant data from the instances and calculates the statistics to display to the user. The stats are not stored locally (again, let us not burn our bridges on this).

Actors: -Only who uses the simulation is an actor- discuss that Passenger is part of the simulation, not an actor

The Conceptual diagramThis is just one possible solution for the conceptual diagram.

Some points:A class knows things, knows of other classes and /or does things. This is richer than an entity! Simulation is a vague class, but we need a class that holds all the general data for the simulation (no global data allowed!) and keeps track of the process. The use of a Controller class is in fact an important design pattern. It also takes care of the other objects (creation, deletion etc) and can communicate with the MVC. I have not included attributes such as number of passengers/lifts/floors, at the stage. Well need to store them at the design phase, though! Timer I am not sure we need this at this moment Queue is a container class. It may not have attributes, but is rich in associations and behaviour (add passenger, pregnant women first etc) Floor may eventually be redundant as it has no attributes (only its ID and does very little. Its roles can be replaced with attributes at the design phase. Passenger. There may be some more redundancy there. You may be able to work out that a passenger is in a queue from the time, but the association should still be there. On the other hand you may want to add later things such passenger weight, to calculate the total weight, etc. Other possible classes may include: Statistics (if we need to do more than flag them to the user) Distribution (this is essential if we want to impose patterns of passenger movement) Its inclusion will change the class diagram

For eliciting requirements, keep things simple. Some answers to common questions There is one queue per floor (not per lift) (lifts will be next to each other)1. The lifts initially will stop at every floor2. No express lift3. The distribution of arrivals to the queues is constant to start with, but it will change in later versions!)Sequence diagrams

The students should realise why there are 3 sequence diagrams - one for each use case.

This is a specimen solution (Some of the names of the messages may not be very good choices feel free to change).

An advice is to work out that floors are redundant as classes because: They have no data (for our specification of the lifts problem) They have no methods (do nothing) It can be implemented as attributes (for example, a passenger getting from floor 1 to floor 2 can be implemented with two attributes on passenger (origin, destination,). Also note that the lift can schedule the type and time of the next event (arrival, stop unloading-open doors, start loading etc)

Start Simulation Seq Diagram

Simulate Seq. Diagram (Doing a time step really)

Get stats seq diagram