I assumed the deadline is using GMT. But I need it by 9 pm SGT.
Abstract The goal of this assignment is to implement and test a set of classes and interfaces1 to be used in the second assignment. You must implement the public and protected members exactly as described in the supplied documentation (no extra public/protected members or classes). Private members may be added at your own discretion. Language requirements: Java version 13, JUnit 4 Preamble All work on this assignment is to be your own individual work. As detailed in Lecture 1, code supplied by course staff (from this semester) is acceptable, but there are no other exceptions. You are expected to be familiar with “What not to do” from Lecture 1 and If you have questions about what is acceptable, please ask course staff. Introduction In this assignment, and continuing into the second assignment, you will build a simple simulation of a traffic management system (TMS). The first assignment will focus on implementing the classes that provide the core model for the system. A traffic management system monitors traffic flow in a region and adjusts traffic signals to optimise traffic flow. A TMS uses different types of sensors and signals to monitor and manage traffic flow. Two sensors used by a TMS are pressure pads and speed cameras. Pressure pads give an indication of how many vehicles are waiting at a location (e.g. at an intersection). Speed cameras determine the speed of vehicles passing the camera. These sensors have some on-board processing capability to provide some determination about traffic congestion at their location. They can also report the raw data that they collect. Two signals used by a TMS are traffic lights and speed limit signs. Traffic lights are positioned at intersections and the duration of the red and green lights can be adjusted by the TMS. Speed limit signs are LED displays that can be changed to set different speed limits to manage traffic congestion. For example, if one section of a road is congested, you could lower the speed limit in the previous sections of the road so that less traffic arrives at the congested area per minute. These signals have some on-board processing capability to provide a simple management interface, as well as the ability to set their specific parameters. A TMS needs to maintain a network of routes. Each route is a road that is being monitored and/or managed by the TMS. The TMS needs to know the intersections of different routes. It also needs to know what sensors and signals are on the route. The TMS gathers data from the sensors to determine how traffic is flowing and then adjusts signals to optimise traffic flow. When implementing the assignment you need to remember that it is implementing a simulation of the TMS and not the real TMS. Interfaces are provided for the sensors to allow easy replacement 1From now on, classes and interfaces will be shortened to simply “classes” 1 of sensor implementations in the program. You will not be collecting data from real sensors but will be implementing classes that demonstrate the behaviour of sensors. They store a set of data values that are used to simulate the sensors returning different values over time. Signals are simple simulations of real signals in that they only store the current state of the signal and allow the route to update the signal. To manage simulation of time, there is a TimedItem interface and a TimedItemManager class. Sensors implement the TimedItem interface, as they are items which need to react to timed events. TimedItemManager stores all the TimedItem objects in the application. It allows the application (to be implemented in assignment two) to simulate time passing, via its oneSecond method. This method sends the oneSecond message to all TimedItems. TimedItemManager is an implementation of a design pattern2 called singleton3. The key idea is that a singleton prevents you from creating more than one instance of the class. To ensure this happens, the TimedItemManager’s constructor is private and the getTimedItemManager method returns a reference to the only TimedItemManager instance. (The first time the getTimedItemManager method is invoked it creates the single TimedItemManager instance.) The registerTimedItem method allows you to add TimedItem objects to the manager. Supplied Material • This task sheet. • Code specification document (Javadoc).4 • A subversion repositiory for submitting your assignment called ass1.5 • Two files (JdkTest and SimpleDisplay) are provided in your subversion repository(it’s in the ass1 folder). JdkTest executes a test to ensure that you are using Java 13 to build and run your assignment. SimpleDisplay is a simple user interface for the assignment. If you wish to use this interface you will need to uncomment some code and add the creation of your traffic network. Any code you write in SimpleDisplay will not be marked. As the first step in the assignment you should checkout the ass1 repository from Subversion. Once you have created a new project from the repository you have checked out, you should run the JdkTest to ensure you have correctly set up the project to use Java 13. Javadoc Code specifications are an important tool for developing code in collaboration with other people. Although assignments in this course are individual, they still aim to prepare you for writing code to a strict specification by providing a specification document (in Java, this is called Javadoc). You will need to implement the specification precisely as it is described in the specification document. The Javadoc can be viewed in either of the two following way: 1. Navigate to the relevant assignment folder under Assessment on Blackboard and you will be able to download the Javadoc .zip file containing html documentation. Unzip the bundle somewhere, and open doc/index.html with your web browser. 2https://refactoring.guru/design-patterns provides a simple overview of the concept of design patterns. Follow on courses will explore design patterns in detail. 3https://refactoring.guru/design-patterns/singleton provides a reasonably detailed description of the singleton pattern. 4Detailed in the Javadoc section 5Detailed in the Submission section 2 Tasks 1. Fully implement each of the classes described in the Javadoc. 2. Write JUnit 4 tests for all the methods in the following classes: • DemoPressurePad (in a class called DemoPressurePadTest) • Intersection (in a class called IntersectionTest) Marking The 100 marks available for the assignment will be divided as follows: Symbol Marks Marked Description F 50 Electronically Functionality according to the specification R 35 Course staff Code review ( Style and Design ) J 15 Electronically Whether JUnit tests identify and distinguish between correct and incorrect implementations The overall assignment mark will be A1 = F + R + J with the following adjustments: 1. If F < 5,="" then="" r="0" and="" code="" style="" will="" not="" be="" marked.="" 2.="" if="" r=""> F, then R = F. For example: F = 22,R = 25,J = 17 ⇒ A1 = 22 + 22 + 17. The reasoning here is to place emphasis on good quality functional code. Well styled code that does not implement the required functionality is of no value in a project, consequently marks will not be give to well styled code that is not functional. Functionality Marking The number of functionality marks given will be F = Tests passed Total number of tests ·50 Each of your classes will be tested independently of the rest of your submission. Other required classes for the tests will be copied from a working version of the assignment. Code Review Your assignment will be style marked with respect to the course style guide, located under Learning Resources > Guides. The marks are broadly divided as follows: Naming 7 Commenting 8 Structure and Layout 13 Good Object-Oriented Practices 7 Note that style marking does involve some aesthetic judgement (and the marker’s aesthetic judgement is final). 3 JUnit Test Marking The JUnit tests that you provide in DemoPressurePadTest and IntersectionTest will be used to test both correct and incorrect implementations of the DemoPressurePad and Intersection classes. Marks will be awarded for test sets which distinguish between correct and incorrect implementations6. A test class which passes every implementation (or fails every implementation) will likely get a low mark. Marks will be rewarded for tests which pass or fail correctly. There will be some limitations on your tests: 1. If your tests take more than 20 seconds to run, or 2. If your tests consume more memory than is reasonable or are otherwise malicious, then your tests will be stopped and a mark of zero given. These limits are very generous (e.g. your tests should not take anywhere near 20 seconds to run). Electronic Marking The electronic aspects of the marking will be carried out in a linux environment. The environment will not be running Windows, and neither IntelliJ nor Eclipse (or any other IDE) will be involved. OpenJDK 13 will be used to compile and execute your code and tests. It is critical that your code compiles. If one of your classes does not compile, you will recieve zero for any electronically derived marks for that class. Submission Submission is via your subversion repository. You must ensure that you have committed your code to your subversion repository before the submission deadline. Code that is submitted after the deadline will not be marked. Details of how to commit code to your repository are described in the SVN Guides on Blackboard. Your submission should have the following internal structure: src/ folders (packages) and .java files for classes described in the Javadoc test/ folders (packages) and .java files for the JUnit test classes A complete submission would look like: src/tms/display/SimpleDisplay.java src/tms/intersection/Intersection.java src/tms/route/Route.java src/tms/route/SpeedSign.java src/tms/route/TrafficLight.java src/tms/route/TrafficSignal.java src/tms/sensors/DemoPressurePad.java src/tms/sensors/DemoSensor.java src/tms/sensors/DemoSpeedCamera.java src/tms/sensors/PressurePad.java src/tms/sensors/Sensor.java src/tms/sensors/SpeedCamera.java src/tms/util/DuplicateSensorException.java src/tms/util/RouteNotFoundException.java 6And get them the right way around 4 src/tms/util/TimedItem.java src/tms/util/TimedItemManager.java test/tms/JdkTest.java test/tms/intersection/IntersectionTest.java test/tms/sensors/DemoPressurePadTest.java Ensure that your assignments correctly declare the package they are within. For example, DemoPressurePad.java should declare package tms.sensors. Do not submit any other files (e.g. no .class files). Note that DemoPressurePadTest and IntersectionTest will be compiled without the rest of your files. Prechecks Prechecks will be performed on your assignment repository multiple times before the assignment is due. They will assess whether your folders and files are in the correct structure and whether your public interface aligns with the expected public interface. Successfully passing a precheck does not guarantee any marks. No functionality or style is assessed. Precheck #1: Approximately 5pm on the 25/03 Precheck #2: Approximately 5pm on the 30/03 Precheck #3: Approximately 5pm on the 02/04 Precheck #4: Approximately 5pm on the 06/04 Please endeavour to have code written and in your repository before at least one of these prechecks in order to make the most of them. No additional prechecks will be run for people who did not start the assignment in time, or who neglected to commit their code to their repository. Prechecks are valid only for currently released version of the Javadoc, if an update is made it may invalidate the precheck results. Late Submission Assignments submitted after the submission deadline of 17:00 on April 9, will recieve a mark of zero unless an extension is