Complete class diagram (phase 5 and 6). 17 Questions. 17 To be submitted: 18 Marking Criteria. 20 Appendix A: Sample Output for a completed phase 6. 22 Objectives In this assignment you will develop an application which uses inheritance, polymorphism, interfaces and exception handling. This assignment must be implemented:

2. incrementally according to the phases specified in this documentation. If you do not submit a complete working and tested phase you may not be awarded marks.
4. 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.
6. 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 In assignment 1 you are going to develop a discrete event-driven simulation to simulate a local shop (e.g. a small general store). In an event driven simulation we have a model of the world being simulated (a shop in this assignment). That world is modified by events that occur at specified times (arrival, collect items, pay and leave). 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 shop). 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 the 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. Our shop simulation will have an abstract Event class which will be extended by three concrete event classes:

• ArrivalEvent to represent a group of customers arriving at the shop sometimes there is more than one person doing the shopping. Assuming there is room for the customers to enter the shop, this event will also be responsible for scheduling the CollectItems event which will collect the items to be purchased and for scheduling the next ArrivalEvent.
• CollectItemsEvent - when this event occurs the customer group collects the items for purchase. This event will be responsible for scheduling the PayEvent for the customer group.
• PayEvent represents the customer paying for the items and schedules the LeaveEvent
• LeaveEvent the group has finished their shopping and now leaves the shop with their pruchases.

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. Part 1: Assignment 1 Version 1 This version (version 1) of the assignment will use fixed values for arrival times, collection times, payment times, leave times and the number of customers arriving in a group at the shop. This will make it easy to test your implementation and check the output generated by your code. This version is to be developed incrementally in the 5 phases described below. In practice, the values for arrival times, collection times, payment times, leave times etc. would not be fixed, they would be selected from an appropriate statistical distribution. The final part of the assignment (phase 6) will be to include a simplified version of this type of variability by using a random number generator. The phase 6 version will be more difficult for markers to check if you have some small differences in your code, therefore if you reach phase 6 of the assignment, you are required to submit both version 1 (completed phase 5) and version 2 (completed phase 6) of your assignment. Name this first version of your program Assignment1V1. Assignment1V1 is to be developed in 5 phases as follows. Do not move onto the next phase until you have a complete, working and tested phase. Backup your work between phases so that if you do not get the next phase completed you will still have a complete working phase to submit. Phase 1

Description

In phase 1, you are to simulate customer groups of two people arriving every two time units for 20 time units. The only event types that will be processed in this initial phase are ArrivalEvents. There will be no limit to the number of customers in the shop in this phase. However, this phase will require you to set up most of the framework needed to develop the rest of the simulation. At the end of the phase 1 simulation you are to display all the customer groups currently in the shop and all the customer groups that have ever arrived at the shop (this will be a history/log of customers that could be used for future analysis). Given that leave events will not be implemented in this phase, the customer groups in the shop will correspond to the customer groups in the log/history. The output for phase 1 should be similar to the following: Simulation Trace: ============== t = 0: group 0 arrived t = 2: group 1 arrived t = 4: group 2 arrived t = 6: group 3 arrived t = 8: group 4 arrived t = 10: group 5 arrived t = 12: group 6 arrived t = 14: group 7 arrived t = 16: group 8 arrived t = 18: group 9 arrived t = 20: group 10 arrived the following groups are in the shop: ============================== Group 0 (2 people) arrived at t = 0 Group 1 (2 people) arrived at t = 2 Group 2 (2 people) arrived at t = 4 Group 3 (2 people) arrived at t = 6 Group 4 (2 people) arrived at t = 8 Group 5 (2 people) arrived at t = 10 Group 6 (2 people) arrived at t = 12 Group 7 (2 people) arrived at t = 14 Group 8 (2 people) arrived at t = 16 Group 9 (2 people) arrived at t = 18 Group 10 (2 people) arrived at t = 20 the following groups are in the history/log: =================================== Group 0 (2 people) arrived at t = 0 Group 1 (2 people) arrived at t = 2 Group 2 (2 people) arrived at t = 4 Group 3 (2 people) arrived at t = 6 Group 4 (2 people) arrived at t = 8 Group 5 (2 people) arrived at t = 10 Group 6 (2 people) arrived at t = 12 Group 7 (2 people) arrived at t = 14 Group 8 (2 people) arrived at t = 16 Group 9 (2 people) arrived at t = 18 Group 10 (2 people) arrived at t = 20 However, the above output must be generated by running the simulation (i.e. by putting events on the event queue, then removing and processing events from the event queue). Your phase 1 must build most of the framework required to run the simulation. If the output is generated by a series of for loops you have not coded phase 1 correctly and you will be awarded no marks for phase 1. It is important to build phase 1 correctly as it is the foundation for the rest of the assignment. The design and requirements for phase 1 are discussed further below. You must develop the code according to the following class diagram and descriptions of the classes and methods that follow. (If necessary, you may have to use Words view->zoom to magnify and view the class diagram.)

Phase 1 class diagram

Figure 1. Phase 1 Class diagram Note: You may add your own private methods to the classes if required, but do not add public methods. The class diagram specifies the design that you are to adhere to. Additional methods and member variables will be added in subseqent phases. See the final class diagram in Figure 2. The above diagram is a sub-set of the final class diagram that will correspond to your final application. It is the class diagram for phase 1 only. For example, when you reach phase 2 and 3 you will add three additional classes (CollectItemsEvent, PayEvent and LeaveEvent) that extend the Event class. In subsequent phases, some of the classes will also require additional instance variables and methods to implement the functionality required in those later phases. The additional variables and methods required are described in each phase and a complete class diagram that includes all the additional classes, variables and methods required for phases 2-6 is shown at the end of phase 6. However, you should not try to complete the whole assignment at once. Make sure that you develop each phase, test it and save a backup before you move on to add the functionality required for the next phase.

The IScheduler interface (and the benefits of using an interface)

Note the IScheduler interface that is shown in the class diagram (implemented by the Simulator class and used by the Event class). 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 events 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() method we limit the events access to the relevant part/interface of the Simulator class. The only method the Event classes can use is the schedule() method. 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.

Implementing Phase 1

To achieve the phase 1 functionality, you have to implement the following:

2. The ShopModel class.

This is the class that models who is in the shop (i.e. the customer groups currently in the shop).It maintains an ArrayList of the CustomerGroups in the shop. It also maintains an ArrayLIst of all the CustomerGroups that have ever arrived in the simulation. This is a log/history of all the CustomerGroups and captures data that could be used for future statistical analysis. The ShopModel is also responsible for assigning a unique identified to each customer group. It has an instance variable called nextIdentifier that is used for this purpose. It gets initialized to 0. When a new group arrives (see ArrivalEvent below), the shop models getNextId() method is used to get the next unique identifier for the new group. Hint: What kind of variable would you use in a class to track the number of instances of the class that have been constructed? (In getNextId() dont forget to increment the nextIdentifier ready for the next arrival.) The logGroup() method and addGroup() methods add customer groups to the history/log ArrayList and the groups (in the shop) ArrayList respectively. The addGroup() method must also maintain an instance variable that tracks the number of Groups in the shop.

2. The CustomerGroup class.

This class stores the information about a customer group that has arrived at the shop. It stores a unique identifier for the group (generated in the shop model when a new customer group is added), the number of people in the group, and the arrival time of the group. It must also include getters for its instance variables and an appropriate toString() method.

2. The abstract Event class.

This class has an instance variable to store the time the event is scheduled occur. The time will be set in the constructor when a new event is created. It must include a getTime() method to return the time. It also has an abstract process() method: public abstract void process( ShopModel sm, IScheduler s );

2. The IScheduler interface

public void schedule( Event e );

2. The ArrivalEvent class

This class extends the abstract Event class. It must therefore implement its own process() method. For this phase, the ArrivalEvents process() method is required to:

2. Set the group size (number of people in this newly arrived group). It will always be 2 in this phase of the assignment. In practice, this number would be selected from an appropriate statistical distribution.
4. Obtain the next unique identifier for the group from the shop model (it should use the shop models getNextId() method).
6. Create a newly arrived CustomerGroup with the id obtained in (ii) above.
8. Add the new customer group to the history/log ArrayList using the shop models logGroup() method.
10. Add the new customer group to the ArrayList of groups in the shop using the shop models addGroup() method. Normally this is only done if the group can enter the shop. However, in phase 1 we will allow everyone to enter the shop. There is no limit to the number of people in the shop in phase 1.
12. Print a message with details of the group that has arrived (see the sample output showing the simulation trace above).
14. Schedule the next arrival event (as discussed in the background notes above). In the next phase we will also schedule a CollectItemsEvent to get the items to be purchased by the group.

2. The Simulator class.

This class must implement the IScheduler interface. (What does that mean? What does it mean the Simulator class must include?) The Simulator has the following instance variables:

• private ArrayList events; // The ordered ArrayList of

// events the event queue

• private int clock; // A clock to track the time in the simulation

// To be initialized to 0 at the start.

• private ShopModel model; //A reference to the shop model

The Simulator class has the following methods

• The constructor.

The reference to the shop model object is to be passed into the simulators constructor in the main() method of the program and in the constructor it is to be assigned to the ShopModel instance variable.

• The initialize() method.

The ArrayList of events (called the event queue) is to be passed into the simulator using this initialize method. The initial event queue is to be created in the programs main() method. The main() method is also to create the first ArrivalEvent (to arrive at time 0) and add it to the event queue. The main method is to then invoke the simulators initialize() method to pass it the initial event queue at the start of the simulation. Recall that when an arrival event is processed, the next arrival event is to be scheduled. There could be more than one event (and more than one event type), hence the array list is a list of Events.

• The run method()

This is the method that runs the simulation. It is passed the time to stop the simulation and executes a loop that takes events from the event queue and processes them until either there are no events on the queue or the time/clock has reached the stop time. Note that the clock time gets set to the time of the event each time an event is removed from the event queue. Assuming the instance variables shown above, the code for this method is given below. public void run(int stopTime) { if ((events == null)|| events.isEmpty() ) return; Event e = events.remove(0); clock = e.getTime(); // events queue will never become empty as after the first event is // added, every arrival event will generate a new arrival event // (which may be greater than the stop time) while (clock e.process(model, this);// the this argument means that we are // passing a reference to this simulator // object to the events process method. e = events.remove(0); clock = e.getTime(); } }

• The schedule method()

This method adds an event to the event queue, i.e. to the ArrayList of Events. The event queue is to be maintained as an ordered list (in ascending order of the time the event is scheduled to occur). The event to be scheduled is passed into the schedule() method. Make sure that you insert it into the event queue so that the queue is maintained in ascending order of the time the event is scheduled to occur. This is important to make sure the events are processed in the correct order (i.e. according to the time they are scheduled). To maintain the queue in sorted order, insert the new event in the correct place (according to its time). If you do that there is no need to sort the queue each time you add an event (which is inefficient and unnecessary). Hint: this means that in your schedule method you must iterate through the queue events until you find the correct place to insert the new event, then insert the new event in that location. Once you have found the correct place to insert your event,you can use the ArrayList classs add(int index, E element) method to insert the event in the correct place. (Don\'t forget to check that your code works for the \"boundary\" conditions (i.e. adding to the empty list, the front of the list and the end of the list). https://howtodoinjava.com/java/collections/arraylist/add-replace-element-at-index/ UseArrayList.add(int index, E element)method toadd element to specific indexof ArrayList.

2. The main method (in Assignment1V1.java) must:

2. Create an instance of the ShopModel.
4. Create an instance of the Simulator and pass it a reference to the newly created instance of a ShopModel.
6. Create an ArrayList of Events (called the event queue). This event queue is to be maintained in order of when the events are scheduled to occur. In later phases this event queue will contain different types of events (e.g. CollectItemsEvent), but in phase 1 we will only be adding ArrivalEvents to the queue.
8. Create and add the first ArrivalEvent to the event queue. It is to be scheduled to arrive at time 0.
10. Invoke the simulators initialize() method and pass the ArrayList of events to the simulator.
12. Invoke the simulators run() method to run the simulation. Pass the number of time steps to run the simulation as the argument to the run method.
14. To check that everyone has arrived and is in the shop, use the shop models showGroups() method to display all the customer groups in the shop (i.e. in the groups ArrayList).
16. To check that all the customer groups have also been stored in the history/log of customer groups use the shop models showLog() method to display the contents of the history ArrayList.

See the sample output for phase 1 shown earlier. Note that we have:

2. An abstract Event class with an abstract process() method. This is because as we develop the simulation we will require more than just arrival events and the different event types will have to be processed in different ways. Each event type will inherit from the Event class and will also be required to implement their own process method. This is an example of polymorphism.

Note that the signature for the process method is: public abstract void process( ShopModel sm, IScheduler s );

2. An IScheduler interface. This is implemented by the Simulator class as the simulator will be required to schedule events in the event queue according to their scheduled time. 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). As part of an events process method it is required to schedule other events. The simulator has methods other than its schedule() method. However, the schedule method is the only method that should be of interest to the Event classes so by passing the IScheduler to the process() method we limit their 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.

** As soon as have you completed and tested phase 1(and definitely by the due date), submit the code in the submission area for the phase 1 (only). This submission is required to demonstrate that you have started developing the code incrementally and so that we can check you understand the framework/design required for the simulation. Phase 2 In phase 2 we will now have the newly arrived groups collect the items they wish to purchase. This will be achieved by introducing a new Event type (an CollectItemsEvent) to be scheduled and processed. To do this we have to:

2. Add a collectItems () method to the ShopModel class.

This method is to print out a message to indicate the time that the group involved has collected their purchases ready for payment (i.e. print out the following message: t = time: Purchases collected by Group groupId where the words in italics and bold are to be the actual group id and time. The signature for the collectItems () method is: public void collectItems(int time, CustomerGroup g)

2. Add a CollectItemsEvent class

• The CollectItemsEvent extends the abstract Event class and must implement its own process() method.
• The CollectItemsEvents process() method must use the shop models collectItems() method to get a collect the purchases for the group (i.e. print out the message). (In a later phase the process model will also schedule the PayEvent for the group.)
• The CollectItemsEvent must also have an instance variable that is a reference to the customer group associated with the order so that it knows which group is collecting their purchases. This means the signature for the CollectItemsEvents constructor will be:

public CollectItemsEvent (int time, CustomerGroup group)

2. Have the ArrivalEvents process() method schedule the new CollectItemsEvent six time units after the group arrives (i.e. this will be when they have collected all the items they wish to purchase)

2. What should be output by the program at this point? Manually predict this. Run and test it.

Phase 3 In phase 3 we will have people pay the shopkeeper and leave. To achieve this, we need to complete part (a) and (b) (phase 3 subphases) below: Part (a) Payment:

2. Implement a pay() method in the shop model, which is to

• Print a message when the group pays the shopkeeper as follows:

t = time: Group groupId customer has paid

2. Introduce the PayEvent class. The PayEvent class must:
   • Extend the abstract Event class
   • Have a reference to the customer group that is about to leave
   • Implement its own process() method which is to invoke the shop models pay() method.
5. Have the CollectItemsEvent schedule a PayEvent for the group 4 time units after purchases have been collected.
7. What should be output by the program at this point? Manually predict the output. Run and test it.

Part (b) Leave:

2. Implement a leave() method in the shop model, which is to:
   • print a message when a group leaves the shop as follows:

t = time: Group groupId leaves the shop where the words in italics and bold are to be the actual group id and time

• remove the group from the ArrayList and
• decrement the number of groups (numGroups) in the shop.

2. Introduce a LeaveEvent class. The LeaveEvent class must:
   • Extend the abstract Event class
   • Have a reference to the customer group that is about to leave
   • Implement its own process() method which is to invoke the shop models leave method.

2. Have the PayEvent schedule a LeaveEvent for the group 1 time unit after payment is received by the shopkeeper.

2. What should be output by the program at this point? Manually predict the output. Run and test it.

Phase 4 Now there are restrictions on the number of customers allowed in the shop. This will correspond to the number of seats made available in the shop. *** For the purpose of testing and to allow the markers to check your output, set the maximum number of customers in the shop to 8. Extend the ShopModel class as follows: Part (a) restrict customer numbers

2. Add a ShopModel constructor that has one parameter that is to be passed the maximum number of customers allowed in the shop when the ShopModel object is created. (The UML diagram in Fig 2 now includes this constructor.)

2. Include an instance variable in the ShopModel class that records the number of customer spaces/slots available. This will initially be set to the maximum number of customers allowed in the shop and is to be reduced when customers enter the shop and incremented when customers leave.
4. When customers arrive in the shop, if there is room available for all the people in the group to enter the shop, then they can enter the shop to purchase their shopping (i.e. schedule a CollectItemsEvent) as normal.
6. If there are sufficient room for all members of the group to enter the shop, print a message as follows:

t = time : Group groupId (number in group) enter the shop where the words in italics and bold are to be the actual group id and time. In that case, if new customers enter, the number of customer spaces available in the shop should be decremented. If there are insufficient seats for the group, then these customers cannot enter the shop. In that case, print a message saying: t = time : Group groupId leaves as there is insufficient room for the group where the words in italics and bold are to be the actual group id and time. Assume that if there is insufficient room the group just goes away (i.e. it does not get added to the ArrayList of Customer Groups in the shop) and is considered lost business. They should still be recorded in the log/history. Keep track of how many customers are lost business during the simulation and print that information as part of the statistics at the end of the simulation. (This is to be a count of the number of customers (not groups) that do not enter the shop.) In both cases (enter the shop or not entered), the process method should schedule the next arrival.

2. Dont forget to increase the number of customer spaces available when a customer group leaves the shop.

Part (b) Statistics

2. At the end of the simulation, print the following statistics:
   • How many customers were served (requires an instance variable to track this it is to be incremented when the customer pays the shopkeeper for the purchases). This is to track the number of customers, not the number of groups served.
   • How many customers were lost business (requires an instance variable to track this)
   • Display the groups still in the shop at the end of the simulation
   • Display the log/history of customer groups that arrived in the simulation.

Phase 5 Output your simulation statistics to a file called statistics.txt . It should be stored in the default folder when you run the program. Use a Formatter to write to the file (see revision notes on the unit website.) At the end of phase 5, the simulation trace should be displayed on the standard output and the statistics.txt file should contain the output showing the number of people served, the lost business, the list of customer groups in the shop and the log of customer groups that were processed in the simulations. Note that in this phase you have to modify the signature of the showLog and showGroups method so that they are passed the output Formatter to write the data to the file. This completes Version 1 of your assignment 1 program that has to be submitted. In phase 6 you are to develop Version 2 which uses a random number generator to introduce some variability so that your simulation is slightly more realistic. If you complete phase 6, you are to submit both version 1 and version 2 of the code. The marker must be able to test phase 5 even if you have also completed phase 6. Part 2: Assignment 1 version 2 Phase 6 In a simulation you do not normally use the same values for arrival times, times to be served etc. As explained earlier, in practice these values are normally selected from an appropriate statistical distribution. To model this type of variability we are going to use a simple random number generator in a second version of your program. Copy your version 1 program to Assignment1V2. Now add a random number generator to your abstract Event class as follows: static Random generator = new Random(1);//use a seed of 1 Note that we have seeded the random number generator with 1. This is to ensure that we will always generate the same output each time we run the code. This will help you to test your code more easily and will also allow the markers to check your work for this version of the program. Your concrete event classes must now use this random number generator to:

2. Determine how long after an arrival before the CollectItemsEvent is to be scheduled (values to be between 3 and 8 time units).
4. Determine the number of people in a group (to be between 1 and 3 people in a group).

In the phase 6 class diagram, you will observe that we have introduced some additional instance variables in the event classes. These are to be used to set the upper and lower bounds on the values generated by the random number generator to achieve the ranges specified above. For example, in the ArrivalEvent we have added the instance variables groupLowerBound and groupGeneratorBound to be used to get random numbers in the range required for the group size. We have said that is to be between 1 and 3. If we assign 1 to the groupLowerBound and 3 to the groupGeneratorBound, then in the Arrival classs process method we can generate numbers in the range1 to 3 using getGenarator().nextInt(groupGeneratorBound) + groupLowerBound; // the getGenerator() method is // now to be added to the Event // superclass. Sample output for a completed phase 6 is shown in appendix A at the end of this document. Note that the output was generated with a different seed. You are to use a seed of 1, so you should expect to get different results to those shown in Appendix A. Check that the output is correct for your simulation trace. Complete class diagram (phase 5 and 6) Figure 2. Complete Class diagram Note the parameter names (not the types) are different in the ArrivalEvent class in this final UML class diagram compared to the phase 1 diagram. You can use either the shortened names shown here or the names on the phase 1 diagram. Questions Regardless of which phase you have completed, Include the answers to the following questions in your report. Question 1: Why does the random number generator in phase 6 need to be static? Question 2: What is the default access modifier for an instance variable if we dont specify an access modifier and what does it mean in terms of what other classes can access the instance variable? Question 3: How could you restrict the instance variables in Event to only the subclasses of Event? To be submitted: You are required to submit phase 1 separately in the phase 1 submission area to demonstrate incremental development. Your final assignment is to be submitted in the assignment 1 submission area. If you have completed phase 6 submit both the phase 5 and 6 versions (V1 and V2). Phase 1 - in the Assessment 1 Phase 1 submission area

2. To demonstrate incremental development, your completed Assignment1V1 phase 1 application (zip file with your NetBeans project) is to be submitted in a separate area on Moodle (the assessment 1 phase 1 submission area)

Phase 1 will be started in the week 3 tutorial. You will also be required to submit your progress on phase 1 as part of the week 3 tutorial. Note that you are not required to complete the whole of phase 1 in the tutorial. However, you should make a good start and have a good understanding of how to progress when you leave the tutorial. When you have completed and tested the whole of phase 1, you must submit it in the assessment item 1 phase 1 submission area on Moodle. This must be submitted no later than the due date for the phase 1 submission in Moodle. Ideally your phase 1 will be completed before the due data shown as you should be working on subsequent phases by then. Note that phase 1 doesnt get awarded marks when you submit it. It is to demonstrate incremental development. The week 5, Phase 1 submission does not require the submission of a report. That is required with your final submission. Your Final Assessment 1 submission. Submit the following in the Assessment 1 final submission area:

2. Phase 6 (or your last completed phase). You are to submit the zip file(s) for your NetBeans project(s). Assuming you have completed to the end of phase 6, you are to submit the zip files with the NetBeans project for both programs (Assessment1V1 (phase 5) and Assessment1V2 (phase 6)). Both versions must be fully documented.

If you only complete to the end of one of the Version 1 phases (phases 1 to 5), then submit your last completed phase of development. Again, the code must be fully documented. Note that no marks can be awarded for code that does not compile or run. Code must be developed incrementally in the order of phase development described in this document. You must also code according to the design specified in this document. Note that if you only complete phase 1 it should be submitted again in the assignment 1 submission area with your report. You must use Javadoc comments when you write comments before the class and method headers. See the document about comments and Javadoc on the unit website (under this assignment specification)

2. Report (Word document)

A template for your report is provided in the assignment 1 area. You are to complete the following sections:

2. Description Section: A description of your program describing the phase you have completed (and what it does).
4. Testing Section: Explain how you tested your code. What are all the checks you performed to make sure the output is correct? (See examples in the template, but make sure your list is complete.)
6. Sample Output Section: Sample output for your last completed phase of the program. If you have reached the phase where you output the statistics results to a file, then your documentation should include the output to the standard output (trace of the simulation) and a copy of the contents the statistics.txt file.
8. Bugs/Limitations Section: If there are known bugs they must be documented here otherwise you will lose marks for poor testing as well as the bug in your code.
10. Future Developments Section: What additional statistics could you collect that may be of interest to the shop owner? When there is not a constant time between events, there is the possibility that multiple customers might be ready to pay for their purchases at the same time. What modifications would you need to cope with more than one customer being ready to pay for their purchases at the same time?
12. Answers to the three questions in the Questions section above.

Marking Criteria This assessment item is worth 20% of the final mark for the unit. The marks available will depend on which phase you have completed but your assignment must be completed according to the design specified in this document. The phase submitted must show all the functionality required for that phase (and preceding phases) and be thoroughly tested. Marks cannot be awarded for an assignment that does not compile and run. Marks will be awarded for the following:

2. Design and Implementation: The functionality must be complete for the phase you have submitted and must be implemented according to the design given in this specification. You must develop the assignment incrementally according to the phases specified.
4. Language use: This includes correct usage of inheritance, polymorphism, an interface, correct use of an ArrayList (including correct insertion into the event queue), variable declarations, constant declarations, class definitions, object creation, loop control, use of selection statements, method definitions and use, display of results etc. Marks will be deducted for unnecessary/very inefficient code. Refer to the Guidelines for Java Programming documentation on the unit website for more details.
6. Documentation: This includes some of the marks under the layout and code documentation column where you are awarded marks for appropriate comments in your code. You must add comments:
   2. before each class (describe the class)
   4. before each method (describe - what the method does, the parameters and the return values)
   6. and in the body of methods as required, but dont over comment.

** You must use Javadoc to document your method and class headers. ** Comments in the code must be meaningful and useful. Marks will also be deducted under the layout and code documentation column if the layout of the code or names of classes, methods and variables do not follow normal conventions. Documentation marks also includes the marks for the accompanying documentation/report. More details about the content required in the varions sections the report are specified above. The template you are to use for the report is provided in Moodle.

2. Testing: Part of the marks are for listing the test/checks you performed to make sure each of your completed phases is working correctly. These are to be listed in the report along with the sample output which should include the simulation trace, the results of printing the groups and history lists and the statistics (if you have reached that phase). The output for the trace and statistics should be checked to make sure all aspects of your simulation and the statistics are correct. Marks awarded for testing will include your list of checks in the report as well as for working code that passes all the tests/checks. Note that the documentation also includes a section for bugs/limitations. Ideally, the phase you submit should not have any bugs. However, if the phase you submit has any bugs(i.e. does not pass all its tests/checks) and you do not document them, you will lose marks for inadequate testing and documentation as well as for the function that does not work. If the phase you submit does not have the functionality for that phase, you will be marked according to the last working phase your code demonstrates. Make sure you have backed up a complete, thoroughly tested phase ready for submission before you add the functionality for the next phase.
4. Marks will be deducted for late submission according to the university policy (-5% of the total mark for the assignment for each day late).

Available marks for each phase is shown in the following table:

	Functionality: implemented incrementally and using the design specified	Language Use	Testing (thorough testing and documented tests)	Report	Layout and code documentation (Use Javadoc)	Totals
Phase1 (Arrive)	/12	/10	/2	/8	/10	/42
Phase 2 (Collect Items)	/12(P1) +/6(P2)	/10	/2(P1) + /1(P2)	/8	/10	/49
Phase 3 (Pay and Leave)	/12 +/6 +/6	/10	/2 +/1 +/1	/8	/10	/56
Phase 4 A (seat constraint)	/12 +/6 +/6 +/6	/10	/2 +/1 +/1 +/2	/8	/10	/64
Phase 4 B (statistics)	/12 +/6 +/6 +/6 +/4	/10	/2 +/1 +/1 +/2 + /2	/8	/10	/70
Phase 5 (write to file)	/12 +/6 +/6 +/6 +/4 +/4	/10	/2 +/1 +/1 +/2+ /2 +/1	/8	/10	/75
Phase 6 (random values)	/12 +/6 +/6 +/6 +/4 +/4 +/4	/10	/2 +/1 +/1 +/2 +/2 +/1 +/1	/8	/10	/80
Totals	42	10	10	8	10	80

Note that the mark shown for each phase includes the marks from previous phases as well as the marks for that phase. The assessment item is worth 20% so this mark will be converted to a mark out of 20. Appendix A: Sample Output for a completed phase 6 Note this is a sample only. It did not use a seed of 1 for the random number generator. Your should expect your output with a seed of 1 to be different. On the standard output: run: Simulation Trace: ================= t = 0: group 0 arrived t = 0: Group 0 (3 people) entered t = 2: group 1 arrived t = 2: Group 1 (1 people) entered t = 4: group 2 arrived t = 4: Group 2 (1 people) entered t = 6: group 3 arrived t = 6: Group 3 (1 people) entered t = 7: Purchases collected by Group 0 t = 8: group 4 arrived t = 8: Group 4 (2 people) entered t = 10: group 5 arrived t = 10: Group 5 (1 people) leaves as there is insufficient room for the group t = 11: Purchases collected by Group 1 t = 11: Purchases collected by Group 2 t = 11: Group 0 customer has paid t = 12: group 6 arrived t = 12: Group 6 (2 people) leaves as there is insufficient room for the group t = 12: Group 0 leaves t = 13: Purchases collected by Group 3 t = 14: group 7 arrived t = 14: Group 7 (3 people) entered t = 15: Group 1 customer has paid t = 15: Group 2 customer has paid t = 16: group 8 arrived t = 16: Group 8 (1 people) leaves as there is insufficient room for the group t = 16: Group 1 leaves t = 16: Group 2 leaves t = 17: Purchases collected by Group 4 t = 17: Group 3 customer has paid t = 17: Purchases collected by Group 7 t = 18: group 9 arrived t = 18: Group 9 (2 people) entered t = 18: Group 3 leaves t = 20: group 10 arrived t = 20: Group 10 (1 people) entered BUILD SUCCESSFUL (total time: 0 seconds) In the statistics.txt file: Statistics ========== The number of people served = 6 The lost business = 4 people The following groups are in the shop: ===================================== Group 4 (2 people) arrived at t = 8 Group 7 (3 people) arrived at t = 14 Group 9 (2 people) arrived at t = 18 Group 10 (1 people) arrived at t = 20 The following groups are in the history/log: ============================================ Group 0 (3 people) arrived at t = 0 Group 1 (1 people) arrived at t = 2 Group 2 (1 people) arrived at t = 4 Group 3 (1 people) arrived at t = 6 Group 4 (2 people) arrived at t = 8 Group 5 (1 people) arrived at t = 10 Group 6 (2 people) arrived at t = 12 Group 7 (3 people) arrived at t = 14 Group 8 (1 people) arrived at t = 16 Group 9 (2 people) arrived at t = 18 Group 10 (1 people) arrived at t = 20