Sunteți pe pagina 1din 9

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)
Tell the waiter Process_payment(tendered_amount,table_no)

Waiter
Name/Id
Attributes (What I know)
Table1
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

Table2

Cashier
Name/Id
Attributes (What I know)

Colas
Beers
Hamburgers
Cakes
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

Prices
Table1 Table2
.50
1.20
1.99
5

Cook
Name/Id
Attributes (What I know)
Stock
Colas
Beers
Hamburgers
Cakes

30
3
50
6

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)

Set up

User

Run
Simulation

Get Statistics

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 <<includes>> - 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 diagram


This is just one possible solution for the conceptual diagram.
business
::Simulation

Time step
start_time
End_time

1
business
::Timer
Time_now

1
1..*
business
::Lift
TimeNextEvent
0..1* NextEvent
*

1..**
business
::Passenger
TimeJoinedQueue

1 2..*

*
*

is destined
originates

*
0..1

1
business
::Floor

Destination
1
origin

1
1

business
::Queue

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 floor
2. No express lift
3. 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

S-ar putea să vă placă și