COIT20256 Data Structures and Algorithms - Assignment Help

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

In assignment 1 you are going to develop a discrete event-driven simulation to simulate a coffee shop.

In an event driven simulation we have a model of the world being simulated (a coffee shop in this assignment). That world is modified by events that occur at specified times (arrival, order 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 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.

Our coffee 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. Assuming there is room for customers to enter the shop, this event will also be responsible for scheduling the OrderEvent to serve the group and for scheduling the next ArrivalEvent.
• OrderEvent- the group getting their order (i.e. getting their coffees). This event will be responsible for scheduling the LeaveEvent for the group.
• LeaveEvent – the group has finished their coffees and now leaves the shop.

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, order times, leave times and the number of customers arriving in a group at the coffee 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, order 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 may be more difficult for markers to check, 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 into 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 <2 people> arrived

t =    2: group 1 <2 people> arrived

t =    4: group 2 <2 people> arrived

t =    6: group 3 <2 people> arrived

t =    8: group 4 <2 people> arrived

t =   10: group 5 <2 people> arrived

t =   12: group 6 <2 people> arrived

t =   14: group 7 <2 people> arrived

t =   16: group 8 <2 people> arrived

t =   18: group 9 <2 people> arrived

t =   20: group 10 <2 people> 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 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 Word’s view->zoom to magnify and view the class diagram.)

Phase 1 class diagram

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 two additional classes (OrderEvent and LeaveEvent) that extend the Event class.  In subsequent phases, some of the classes will require additional instance variables and methods to implement the functionality required in those later phases. The additional details are described in each phase and a complete class diagram that includes all the additional events 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 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() method 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() 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:

1. 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 model’s 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() don’t 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 apporpriate toString() method.

3. The abstract Event class.

 This class has an instance variable to store the time the event is scheduled to 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 );

4. The IScheduler interface

public void schedule( Event e );

5. The ArrivalEvent class

This class extends the abstract Event class.  It must therefore implement its own process() method.

For this phase, the ArrivalEvent’s process() method is required to:

1. 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.
2. Obtain the next unique identifier for the group from the shop model (it should use the shop model’s getNextId() method).

• Create a newly arrived CustomerGroup with the id obtained in (ii) above.

1. Add the new customer group to the history/log ArrayList using the shop model’s logGroup() method.
2. Add the new customer group to the ArrayList of groups in the shop using the shop model’s 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.
3. Print a message with details of the group that has arrived (see the sample output showing the simulation trace above).

• Schedule the next arrival event (as discussed in the background notes above). In the next phase we will also schedule an OrderEvent to get a coffee order for the group.

6. 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<Event> 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 simulator’s 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 program’s 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 simulator’s 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 <= stopTime) {

            e.process(model, this);// the this argument means that we are   

                                   // passing a reference to this simulator

                                   // object to the event’s 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 class’s 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/

Use ArrayList.add(int index, E element) method to add element to specific index of ArrayList.

7. The main method (in java) must:
8. Create an instance of the ShopModel.
9. Create an instance of the Simulator and pass it a reference to the newly created instance of a ShopModel.

• 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. OrderEvent), but in phase 1 we will only be adding ArrivalEvents to the queue.

1. Create and add the first ArrivalEvent to the event queue. It is to be scheduled to arrive at time 0.
2. Invoke the simulator’s initialize() method and pass the ArrayList of events to the simulator.
3. Invoke the simulator’s run() method to run the simulation. Pass the number of time steps to run the simulation as the argument to the run method.

• To check that everyone has arrived and is in the shop, use the shop model’s showGroups() method to display all the customer groups in the shop (i.e. in the groups ArrayList).
• To check that all the customer groups have also been stored in the history/log of customer groups use the shop model’s showLog() method to display the contents of the history ArrayList.

See the sample output for phase 1 shown earlier.

Note that we have:

1. 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 event’s 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 groups get their coffee order after they arrive.  This will be achieved by introducing a new Event type (an OrderEvent) to be scheduled and processed. To do this we have to:

1. Add a serveOrder() method to the ShopModel  

This method is to print out a message to indicate the time that the group involved has been given their coffee (i.e. print out the following  message:

“t = time: Order served for Group groupId”

where the words in italics and bold are to be the actual group id and time.  The signature for the serveOrder () method is:

public void serveOrder(int time,  CustomerGroup g)

2. Add an OrderEvent class

• The OrderEvent extends the abstract Event class and must implement its own process() method.
• The OrderEvent’s process() method must use the shop model’s serveOrder() method to get a coffee order filled for the group (i.e. print out the message). (In a later phase the process model will also schedule the “LeaveEvent” for the group.)
• The OrderEvent 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 being served their coffee. This means the signature for the OrderEvent’s constructor will be:

public OrderEvent(int time, CustomerGroup group)

3. Have the ArrivalEvent’s process() method schedule the new OrderEvent one time unit after the group arrives
4. What should be output by the program at this point? Run and test it.

Phase 3

In phase 3 we will have people leave after they have finished their coffee. To achieve this, we need to:

1. 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”

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 model’s leave method.

3. Have the OrderEvent schedule a LeaveEvent for the group 10 time units after they receive their coffee.

4. What should be output by the program at this point? 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, make the number of seats in the shop 8.

Extend the ShopModel class as follows:

1. Add a ShopModel constructor that has one parameter that is to be passed the number of seats available in the shop when the ShopModel object is created.
2. Include an instance variable in the ShopModel class that records the number of seats available. The number of seats available is to be passed into the ShopModel constructor. (The UML diagram in Fig 2 now includes this constructor.)
3. When customers arrive in the shop, if there are enough seats available for all the people in the group, then they can enter the shop and get coffee (i.e. schedule an OrderEvent) as normal.
4. If there are sufficient seats to seat all members of the group, print a message as follows:

“t = time : Group groupId  (number in group) seated”

where the words in italics and bold are to be the actual group id and time.

In that case, if new customers are seated, the number of seats 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 are insufficient seats for the group”

where the words in italics and bold are to be the actual group id and time.

Assume that if there are insufficient seats the group just “goes away” (i.e. does not get added to the ArrayList of Customer Groups in the shop) and are 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.

In both cases (seated or not seated), the process method should schedule the next arrival.

5. Don’t forget to increase the number of seats available when a customer group leaves the shop.
6. At the end of the simulation, print the following statistics:
   • How many customers were served (requires an instance variable to track this)
   • 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.

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.

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:

1. Determine how long after an arrival before the OrderEvent is to be scheduled (values to be between 1 and 5 time units).
2. Determine the number of people in a group (to be between 1 and 4 people in a group).
3. Determine how long after getting their coffee the group stayed in the shop, i.e. how long after the OrderEvent before the LeaveEvent is to be scheduled to occur (values to be between 5 and 12 time units).

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.

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 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)

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 don’t 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

1. 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 data 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 doesn’t 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 submission  area:

1. 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 and Assessment1V2).

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.

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.

2. Report (Word document)

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

1. Description Section: A description of your program describing the phase you have completed (and what it does).
2. 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.)
3. 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.
4. 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.
5. Future Developments Section: What additional statistics could you collect that may be of interest to the shop owner?
6. 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:

1. 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.
2. 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.
3. 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:
   1. before each class (describe the class)
   2. before each  method (describe - what the method does, the parameters and the return values)

• and in the body of methods as required, but don’t over comment.

 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. The contents of the report are specified above. The template you are to use for the report is provided in Moodle.

4. 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.
5. Marks will be deducted for late submission according to the university policy (-5% of the total mark for the assignment for each day late).

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 output will be different.

On the standard output:

Simulation Trace:

=================

t =    0: group 0 <3 people> arrived

t =    0: Group 0 (3 people) seated

t =    1: Order served for Group 0

t =    2: group 1 <4 people> arrived

t =    2: Group 1 (4 people) seated

t =    4: group 2 <3 people> arrived

t =    4: Group 2 (3 people) leave as there are insufficient seats for the group

t =    6: Group 0 leaves

t =    6: Order served for Group 1

t =    6: group 3 <3 people> arrived

t =    6: Group 3 (3 people) seated

t =    8: group 4 <4 people> arrived

t =    8: Group 4 (4 people) leave as there are insufficient seats for the group

t =   10: group 5 <3 people> arrived

t =   10: Group 5 (3 people) leave as there are insufficient seats for the group

t =   11: Order served for Group 3

t =   12: group 6 <4 people> arrived

t =   12: Group 6 (4 people) leave as there are insufficient seats for the group

t =   14: group 7 <1 people> arrived

t =   14: Group 7 (1 people) seated

t =   16: group 8 <2 people> arrived

t =   16: Group 8 (2 people) leave as there are insufficient seats for the group

t =   16: Order served for Group 7

t =   17: Group 1 leaves

t =   18: Group 3 leaves

t =   18: group 9 <1 people> arrived

t =   18: Group 9 (1 people) seated

t =   20: group 10 <4 people> arrived

t =   20: Group 10 (4 people) seated 

In the statistics.txt file:

Statistics

==========

The number of people served = 11

The lost business  = 16 people

The following groups are in the shop:

=====================================

Group    7 (1 people) arrived at t = 14

Group    9 (1 people) arrived at t = 18

Group   10 (4 people) arrived at t = 20

The following groups are in the history/log:

============================================

Group    0 (3 people) arrived at t = 0

Group    1 (4 people) arrived at t = 2

Group    2 (3 people) arrived at t = 4

Group    3 (3 people) arrived at t = 6

Group    4 (4 people) arrived at t = 8

Group    5 (3 people) arrived at t = 10

Group    6 (4 people) arrived at t = 12

Group    7 (1 people) arrived at t = 14

Group    8 (2 people) arrived at t = 16

Group    9 (1 people) arrived at t = 18

Group   10 (4 people) arrived at t = 20