Reference no: EM132849276

Objectives
In this assignment you will develop an application which uses inheritance, polymorphism, interfaces and exception handling.

This assignment must be implemented:

1. incrementally according to the phases specified in this documentation. If you do not submit a complete working and thoroughly tested phase you may not be awarded marks.

2. according to the design given in these specifications. Make sure your assignment corresponds to the class diagram and description of the methods and classes given in this document. You must use the interface and inheritance relationships specified in this document.You must implement all the public methods shown. Do not change the signature for the methods shown in the class diagram. Do not introduce additional public methods unless you have discussed this with the unit coordinator - they should not be required. You may introduce your own private methods if you need them. Make sure your trace statements display the data according to the format shown in the example trace statements. This will be important for markers checking your work.

3. Using the versions of the software and development tools specified in the unit profile and on the unit website.

Background - The Task and Event Driven simulation

The Task

In assessment 1 you are to develop a discrete event-driven simulation to simulate a supermarket where a customer progresses through the following steps:
• arrives and (if permitted) enters the shop
• shops for the items he/she wishes to purchase
• proceeds to the checkout area where he/she may have to wait in the checkout queue until a checkout serverbecomes available
• when a server is available (and the customer is at the front of the queue) he/she is served (i.e. this would be where he/she packages their purchases and pays)
• customer then leaves the shop

Event Driven Simulation
In an event driven simulation we have a model of the world being simulated (in this assignment it is the supermarket). That world model is modified by events that occur at specified times (e.g. arrival, checkout, service and leave events).

The way that event-driven simulation works is that the events result in actions being performed on the model being simulated (in this case the supermarket). These events can also trigger other events. An event is scheduled to occur at a particular time and is stored in time order on an event queue, where time corresponds to the time of a simulation clock. By convention, clock time is an integer, beginning at time 0. Simulation proceeds by removal of the event at the head of the event queue; its time becomes the current clock time for the simulation. The behaviour associated with the event (typically encapsulated in a method called process()), is then executed. The process methods may make changes to the simulated world model and schedule new events.

In our supermarket simulation will have an abstract Event class which will be extended by four concrete event classes:
• ArrivalEvent - to represent a customer arriving at the shop. Assume only one customer arrives at a time. Assuming there is room for a customer to enter the shop, this event will also be responsible for scheduling the CheckOutEvent after allowing time for the customer to collect their shopping in their trolley/basket. The ArrivalEvent processing must also schedule the next ArrivalEvent.
• CheckOutEvent - the customer goes to the checkout and joins the checkout queue. If there is a server available, then the CheckOutEvent will schedule a Service Event to occur at the same time as the CheckOutEvent (i.e. no waiting time on the queue). If no server is available, then the customer will be added to the checkout queue and will be served when he/she reaches the front of the checkout queue and a server becomes available (see ServiceEvent and LeaveEvent below).
• ServiceEvent - this event will be responsible for scheduling "serving" the customer (packaging the purchases and taking payment) and for scheduling the LeaveEvent (after the customer has been served).
• LeaveEvent - this event is responsible for recording the customer leaving the shop and as a server is now available, it is also responsible for getting the next customer (if any) from the head/front of the checkout queue and scheduling the event for that customer to be served immediately. (Take care: the new service event must be scheduled to occur at the same time as the leave event - do not introduce a delay).

It is very important for you to develop this assignment incrementally and make sure each phase is working correctly before you try to add any additional functionality required in the next phase. Always keep a backup of the previous working phase before you move on to the next phase. That way, after phase 1, you will always have a working phase that can be submitted.

Timing for events (and other constants)
In a simulation you do not normally use the same values for arrival times, times to be served etc. In practice these values are normally selected from an appropriate statistical distribution and will vary from customer to customer. However, for ease of development and testing we will use constant values for the timing of arrivals, shopping, being served etc.
• Number of servers in the shop - 2 servers
• Maximum number of customers allowed - 5 customers
• Time between arrivals - 1 time unit
• Time to "shop" - i.e. time to collect purchases in trolley/basket and go to the checkout area (the time delay after the arrival to schedule the CheckOutEvent) - 1 time unit
• Time to be served - 5 time units
Note: when testing you may wish to change some of the above constants. That is acceptable. However, you must make sure that when you submit your code it adheres to the above specifications.

Class Diagram for the Complete Assignment (all phases)

(Figure 1 attached shows the final class diagram for the assignment when all phases are complete.

As you develop the assignment, only add the parts required for the phase you are working on - develop incrementally. In some cases, you may have to add dummy/skeleton methods to allow your code to compile. The dummy/skeleton methods will be completed in later phases. (Use View->zoom in Word to view the details.)

Phase 0 (provided)

Phase 0 is provided in the assessment 1 area in the unit website (the same area as this specification). It uses a JavaFX GUI which is complete and must not be modified. This GUI implementation is provided to help you trace what is happening in your simulation. It is to help you with your debugging and testing.

Phase 0 does not do anything very interesting from a simulation perspective, as only arrival events are handled and the behaviour that is provided does nothing except schedule the next arrival event. In the subsequent phasesyou will be required to provide more detailed event behaviours and model behaviour. However, the GUI implementation that has been provided (the controller class and the associated FXML file) is complete and must NOT to be modified. JavaFX will be covered in Week 4; until then, treat the GUI as a "black box".

The GUI supports two modes of operation- a step mode which allows you to step through the simulation an event at a time until completion or you select stop. This is useful for testing as the state of the simulation is displayed at each step. If step mode is not selected, then the simulation will run to completion. Completion is determined by specifying a duration for the simulation - e.g. 20 time units.
To run a simulation, you need to
1. Specify the duration
2. Select the mode
3. Click the Simulate button.

You can run the simulation multiple times per session either in step mode or run to completion mode. However, you will need to reset the simulator between runs - use the Reset button for this. Note that the simulate and reset buttons are disabled/enabled according to context.

Phase 0 Tasks
• In phase 0 you are to obtain a copy of the phase 0 code from the unit website and run it from NetBeans. Familiarise yourself with how to use the GUI ( try step mode, non step mode, reset button between runs etc.). See the phase 0 test plan in the report template.
• In phase 0, you are not required to make any changes to the code provided. However, you must familiarise yourselves with the code that has been provided and document all public methods and classes except for the GUI files.

• Note the following in the design:

1. The separation of behaviour and view state. We have:
a. A Model class and a ModelState class. The Model class models the behaviour of the supermarket whereas the ModelState class maintains the state of supermarket in a form suitable for the GUI to display.
b. Similarly, there is a Simulator class and a SimulationState class. The Simulator models the behaviours required to run the simulation. The SimulationState class consists of the state information for the simulator AND the ModelState (the state of the supermarket) in a form suitable for the GUI to display.
2. The use of 2 interfaces - ISchedule and IUpdate (see the class diagram in Figure 1)
a. The ISchedule interface
The ISchedule interface is shown in the class diagram, but is not included in the phase 0 code. You will be required to add and use the ISchedule interface as part of your code development in phase 1.

Benefits of having anISchedule interface.
This interface is to be implemented by the Simulator class as the simulator will be required to schedule events in the event queue according to their scheduled time. As part of an event's process() method it is required to schedule other events. The Simulator class has a number of methods, but the only method that is relevant to the event classes is the schedule() method (specified in the interface). By passing the IScheduler to the process() we limit the event's access to the relevant part/interface of the Simulator class. The only method the Event classes can use is the schedule(). lt is good programming practice to use interfaces in this way, i.e. to "program to an interface" and only expose the part of the class that is needed.
Using an ISchedule interface also means that if you were to use a different simulator or scheduler that also implements the ISchedule interface, no change should be required to the process() methods in the event classes.
b. The IUpdate interface

The FXMLDocumentController implements the IUpdate interface. The IUpdate interface specifies the methods to
• Update the simulation state information (simulator and model state data) in the user interface - the document controller's update() method is called by the simulator's run() method to update the GUI during the simulation run. Note that the simulator has a reference to an IUpdater.
• Display a warning to the user. For example, if the user tries to start the simulation without entering the duration time for the simulation the warning() method is called by the FXMLDocumentController (see the simulateAction() method in the FXMLDocumentController).
• Allow the user to answer a question with either choice 1 or choice 2. The choose() method to achieve this is called by the simulator while stepping through the simulation (to allow the user to step or stop).

Benefits of having anIUpdate interface.

The benefit of having an IUpdate interface is again to only expose the part of the class that is needed to update the user interface. And again, if you used a different user interface and it also implemented the IUpdate interface, the code in the Simulator that interacts with and updates the user interface does not need to be changed.
 
Phase 1: Populating the log with customer arrivals

Phase 1 Tasks

1. Make a copy of the phase0 version and call it phase 1. This can be achieved by using the copy option in NetBeans as follows:
a. Right click on your phase 0 project (ShopP0) and select copy from the drop-down menu
b. You will see a pop-up window similar to the following. Name your project ShopP1

c. If necessary, browse to where you want to store your new phase 1 version and click the copy button.
d. You should now see the phase1 copy you are going to work with in the specified folder and it should also appear in NetBeans.

2. Add the ISchedule interface and modify the Simulator and event classes as per the class diagram (i.e. the Simulator must implement the ISchedule interface, and the parameter passed to the event process() methods must be of type ISchedule, not type Simulator). Make sure you understand why this is good design practice.(See the discussion in phase 0.)

3. Modify the Simulator class's schedule() method so that events are inserted into the event queue in time order, not simply added to the event queue with no consideration of time. This is very important or your simulation will not process events in the correct time order when you have more that arrival events occurring.

4. Implement the complete Record class as per the class diagram
This class maintains the customer state as he/she arrives and goes through the shopping process.

Note the use of an enum to model customer status; the update() method sets the status member to the appropriate enum value passed into its update() method and based on the status sets the record's appropriate time member variable(s) to maintain a record of when the customer arrived, departed, queued etc.

Note the use of a static counter to keep track of the number of customers that have arrived in the simulation to allow you to generate a unique customer number for each customer. Also remember to use of the static reset() method to reset this counter if the simulation gets reset.

5. Implement the parts of the ModelState class required for phase 1 as per the class diagram
This class maintains the state of the shop - this is recorded in the log (ArrayLIst). Log contains the records for ALL customers in the simulation. The ModelState class also tracks various counts (the number of customers currently in the shop and in phase 5 the number of customers turned away).

Getters are to be provided that return the state information required for the corresponding text areas in the GUI. For the non-counts, use Simulator class's events() method as a guide to how to use StringBuilder to build the String to be displayed in the GUI. Note that these methods will extract the required information from the log (e.g. the getPeopleShopping() method will iterate through the log and use StringBuilder to build the String with all the customers currently having a status of SHOPPING).

In this phase, ONLY complete the following in the ModelState class:
• The member variables
• Constructor
• addRecord() - adds the customer record to the log
• updateCounts() - if the customer record status is SHOPPING then this should increment the number in the shop, if it is FINISHED (at the end of the customer lifecycle), it should decrement the number in the shop as this means the customer has finished and left the shop. If the customer was turned away on arrival (in the final phase) and the state is TURNED_AWAY, then the turned away count must be incremented.
• getLog() - to return a String with the information about all the customers in the log. For display in the GUI. (use StringBuilder - similar to the Simulator class's events() method).
• getPeopleShopping() - get this information from the log and build the String of records with a status of SHOPPING using a StringBuffer (similar to the Simulator class's events() method).
• getNumberInShop() - return the number of customers in the shop.

6. Implement the parts of the Model class required for phase 1 as per the class diagram
This class models the behaviour of the shop. The methods that realise shop and customer behavior are invoked from the process() methods of the appropriate events.

In this phase, we only implement and process arrival events. In the final phase of the assignment you will only allow arrivals to enter the shop if the number of people already in the shop is less than the allowedMaximum.

However, in this phase, there is no limit, so turnAway() must always return false in this phase. In addition, turnAway() must add the record that is passed in as a parameter to the log and display a trace statement on the console to show the customer arrival. turnAway() will be called by the ArrivalEvent class's process() method; In the ArrvialEvent's process() method, if turnAway() returns false, then it means the customer can enter the shop and so the Model class's enter() method must be called.

The enter() method is to update the record passed in as its parameter to indicate that the customer is in the SHOPPING state and to record the time at which this SHOPPING activity started. In order to access SHOPPING in the Model class, the enum values need to be imported - use import static shop.Record.Status.*;

The Model class's enter() method must also call the ModelState class's updateCounts() method and display a trace statement on the console.

In this phase, only implement
• Member variables
• The constructor (don't forget to call Record.reset())
• getModelState() - it now returns modelState - not null.
• turnAway() - as discussed in description above
• enter() - as discussed in the description above

7. Further development of ArrivalEvent (for phase 1 behaviour)

• The ArrivalEvent's process() must still schedule the next arrival event, but before doing that, it must call the model's turnAway() method (which will always return false in this phase) If false is returned by turnAway() then the model's enter() method must be called.
• Update the toString() method in the ArrivalEvent's class so that it also captures the customer number (now available if you have implemented the Record class as per the class diagram).

Attachment:- Scope and Diagram.rar