Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: zz-x2580
## **DRAFT**
This is a draft assignment specification. It is subject to change. Repositories have not been created for you yet, nor submission enabled, but starter code can be viewed here.
—
## Value: 10 marks
## Aims
* Practice how to apply a systematic object-oriented design process
* Gain experience in implementing an object-oriented program with multiple interacting classes
* Learn more about the Java class libraries
## Preamble
In this assignment, you will design and implement a prototype system that could serve as the “back-end” of a venue hire system (such as for holding conferences). Pay careful attention to the requirements and make sure you have a complete and sound understanding of them before developing a design and implementing it.
## Requirements
In this venue hire system, customers can make, change and cancel reservations. Each venue has a number of rooms of various sizes: rooms are either small, medium or large. A reservation request has a named identifier and is for one or more rooms of a certain size (e.g. two small rooms and one large room) for a period of time given by a start date and an end date. A reservation request is either granted in full or is completely rejected by the system (a request cannot be partially fulfilled).
Assessment will be based on the design of your program in addition to correctness. You should submit at least a UML class diagram used for the design of your program, i.e. not generated from code afterwards.
The implementation should input and output data in the JSON format. It will read from STDIN (`System.in` in Java) and output to STDOUT (`System.out` in Java). The input will be a series of JSON objects, each containing a single command. After reading in a JSON object, the implementation will immediately process that command; i.e. it cannot wait for all commands to be input before acting on them. You can assume `room` commands will precede all other commands, but beyond that there are no guarantees of the order or quantity of each command. The commands are as follows (the text in italics is what will vary):
* Specify that venue *venue* has a room with name *room* and that has size *size*.
> { “command”: “room”, “venue”: *venue*, “room”: *room*, “size”: *size* }
* Request *id* is from *startdate* to *endate* for *small* number of small rooms, *medium* number of medium rooms, and *large* number of large rooms.
> { “command”: “request”, “id”: *id*, “start”: *startdate*, “end”: *enddate*, “small”: *small*, “medium”: *medium*, “large”: *large* }
* Change existing reservation *id* to be from *startdate* to *endate* for *small* number of small rooms, *medium* number of medium rooms, and *large* number of large rooms.
> { “command”: “change”, “id”: *id*, “start”: *startdate*, “end”: *enddate*, “small”: *small*, “medium”: *medium*, “large”: *large* }
* Cancel reservation *id* (if it exists) and free up rooms
> { “command”: “cancel”, “id”: *id* }
* List the occupancy of each room in the venue *venue*
> { “command”: “list”, “venue”: *venue* }
To remove any ambiguity, reservation requests and changes are fulfilled as follows: each venue is checked (in order of definition in the input) to determine whether it can satisfy all requested rooms, and if so, the first available rooms (again in order of definition in the input) are assigned to the reservation. The output should list rooms assigned to the reservation in order of the declarations at the start of the input (see first example below). Do not try to fulfil requests by allocating larger rooms when a small room is requested, or by reassigning rooms to different reservations to create space, etc. For the `list` command, output an array containing the occupancy of each room at the specified venue in order of room declarations, then date (see below).
