Iteration 3 Deliverables

[withaspirit]

Milestone Description

For this iteration, you are to use what you have learned from Assignments 2 and 3 and split your system up into three (or more) separate programs that can run on three separate computers and communicate with each other using UDP. Your task in Assignment 3 was to implement a simple version of a remote procedure call, so you are encouraged to recycle that code here.

The Scheduler will now be used to coordinate the movement of cars such that each car carries roughly the same number of passengers as all of the others and so that the waiting time for passengers at floors is minimized. Hint: if a passenger wants to go down and there is an elevator above the passenger, then that elevator should service the passenger rather than having a second elevator go up instead. The state machines for each car should execute independently of each other, but they will all have to share their position with the scheduler. The scheduler will choose which elevator will be used to service a given request.

Note: any task preceded (???) has some uncertainty around it. This refers to how it will be done or whether it will be done at all.
NOTE: This needs to be updated because some these tasks should be done in iteration 4, not iteration 3.

Iteration 2 Leftovers

• Scheduler Redesign @ryandash
  • Refactor Scheduler Functionality #106
    • Give Scheduler more of ElevatorSubsystem's current functionality without modifying the underlying logic. Change parameters as necessary.
    • Move ElevatorSubsystem's chooseElevator method into Scheduler #128
    • (???) Move ElevatorSubsystem's list of Elevators and addElevator() method into Scheduler #131
    • Give Scheduler ElevatorSubsystem's run() method #132
  • Fix SchedulerTest - should test that Elevator can receive all inputs, send all ApproachEvents, and that FloorSubsystem's requests and the buffer are empty afterwards
• Elevator Message Transfer
  • Should Elevator communicate directly with Scheduler or stuff on the buffer instead of going through the subsystem?
  • [ ] Give Elevator reference to buffer or Scheduler instead of ElevatorSubsystem?
  • Fix message passing: Two Buffers #109
    • Change BoundedBuffer to UnboundedBuffer  #110
    • [ ] Renamed BoundedBuffer to UnboundedBuffer
    • Program lag after all Requests from Input processed #111
  • Allow FloorSubsystem, Scheduler, and Elevator or ElevatorSubsystem to be instantiated without buffers (useful for when Client/Server model will be incorporated)
    • Modify JUnit tests as needed
• ElevatorSubsystem Redesign @ryandash
  • Further identify purpose of ElevatorSubsystem
  • Determine cardinality of ElevatorSubsystem-Elevator relationship: One-to-one or One-to-many? #133
  • Should ElevatorSubsystem still send FloorRequests to Scheduler for Client/Server model (currently is necessary for FloorSubsystem to not get deadlocked) #134
  • ElevatorSubsystem Receive messages ?
• Elevator Movement Algorithm Update @Bnortron
  • (???) Implement Elevator Movement State Machine Diagram properly: Check for a request in floors queue after every floor? (would allow elevator to visit floor 50 if it’s going up from floor 1 to floor 100)
    • Use floorsQueue.peekNextFloor() method
    • Change the Movement Algorithm so that it relies on receiving an ApproachEvent to stop instead of looping until it gets to a floor
    • Ensure everything works the same as before
• FloorQueue Update @julian-carleton
  • All handling of where the request is placed in the queue should be done in FloorsQueue. When adding a request, the Elevator should just be calling floorsQueue.addRequest() and passing any needed information
  • FloorQueue: CurrentDirectionQueue, Elevator: ServiceDirection #104
  • FloorsQueue: Refactor, Tests, BugFixes #137
  • Replace the requests ArrayList with FloorsQueue in the Elevator class
    • Ensure all JUnit Tests still work properly
  • Rename FloorsQueue to FloorQueue (do in separate PR)
• Elevator Service Algorithm Update
  • Prerequisite: FloorsQueue: Elevator’s request list is replaced with FloorsQueue
  • Ensure Elevator still visits Floors in a proper order (see Elevator Request + FloorRequest cases)
    • JUnit tests for ElevatorMovement
    • Change FloorsQueue structure if necessary
• Elevator Movement properties modification @Bnortron
  • Add statements for modifying the ElevatorMotor's MovementState
    • Add JUnit tests for stuff like stopping after reaching a correct floor, that Elevator is still moving at a certain point, etc.
  • Add statements for modifying the ElevatorMotor's Direction
    • Add tests for different cases (ask about Example Diagram)
• ApproachEvent Integration to Floor #102
  • Add ArrivalSensor to Floor
  • Complete Floor's receiveApproachEvent method (perform the arrivalSensor.checkFloorNumber method)
  • Add JUnit Test for whether Floor's ArrivalSensor check actually changes the ApproachEvent.elevatorMayStop variable
    • [] If not, modify the ArrivalSensor's check method so that it does modify the ApproachEvent
  • Verify FloorSubsystem selects correct floor for ApproachRequests #112
• Optional Refactoring
  • Change Elevator and Floor to have addSubsystem() methods or give them a constructor without subsystem instead of having their respective subsystems in their constructors (better for testing and could eliminate the need for the "toggleMessageTransfer()" method in Elevator by simply having a check for whether elevatorSubsystem is null)
  • Determine if Elevator's acceleration and other constant properties should be moved out of the Elevator class into ElevatorMotor reduce clutter
  • Approach Request toString() method System Event toString methods, ApproachEvent fix #108
  • Clean up output statements like the TA said
  • Add more Elevator state info to output statements

Iteration 3 Breakdown

Major Goals

• Get simulation working for multiple elevators
• Elevator Selection Algorithm: Scheduler chooses which elevator serves a given request
• Message Transfer: Use Client/Server scheme as seen in Assignments 2 and 3 instead of what we have now.
• UDP messages to transfer data as seen in Assignment 2
• Three programs running separately as seen in Assignment 2
• Implement Doors on Elevators

Code Breakdown

• Client/Server
  • Determine how the Client/Server/Intermediary(???) scheme will be incorporated into project
  • Create IntermediateHost methods IntermediateHost send/receive and Scheduler Integration #124
    • Integrate with Scheduler IntermediateHost send/receive and Scheduler Integration #124
  • Create Client/Server methods @julian-carleton
    • Port number in constructor of each
    • Similar to assignment 3
    • Determine how many ports to use
  • Create Client / Server Classes to project Add Client, Server, IntermediateHost, Port, MessageTransfer #115
    • Use "addObject(Object object)" methods and if (client/model) { // do client/server stuff } else if (buffer) { // stuff with buffer } scheme so that the buffer can be used for JUnit tests concurrently with the client/server model
  • Integrate IntermediateHost
  • Integrate Client / Server
• Message Transfer
  • ElevatorRequest Sequence Diagram
• UDP Packets
  • Refer to this resource
  • Convert Requests to byte array and then from byte array to request
    • request classes implement serializable
    • method to convert Object to byte array
    • method to convert byte array to Object (maybe returns systemevent)
  • Create EncodeDecodeTest verifying this actually works
    • do the conversion for every type of request being sent (Done for FloorRequest and ElevatorRequest)
    • check that objects are the same after conversion (Not same object, but a copy of)
  • Integrate into code
• Elevator Select Algorithm Update
  • Fix ElevatorSelectionTest (currently bugged, loops infinitely)
  • Finish implementing Elevator Select Algorithm along with a state diagram
• Multiple Elevator Functionality
  • Note that many JUnit tests with have to be modified to ensure multiple Elevators can do them at once
  • [ ] Add JUnit tests where Structure has a varying number of Elevators
• Doors
  • Create Doors Class #107
    • Doors should have an ENUM indicating whether it is open or closed (not a boolean), a getter to indicate whether they're open/closed, methods to open and close themselves, and a door time variable with a default value that can be modified
    • Add Doors to elevator
• Update Movement Algorithm with doors:
  • Add statements for opening / closing doors to certain parts of the elevator
• Three programs running separately
  • Add main methods where appropriate
  • 3 Programs working

Documentation

• GitHub Release
• ReadMe
  • (update) Detailed set up and test instructions, including test files used
  • Breakdown of responsibilities of each team member for this iteration
  • General description of system
  • Explaining the names of your files, set up instructions, etc
• Diagrams
  • Updated UML class diagram
    • Insert into README
  • UML Sequence Diagram for
    • Transferring ApproachRequests
    • Transferring ElevatorRequests
    • Insert into README
  • State Machine Diagrams in README
    • Message Transfer - ElevatorRequest - FloorSubsystem to ElevatorSubsystem, Elevator, and back
    • Message Transfer - ApproachEvent - Elevator to FloorSubsystem and back
    • Elevator Service Algorithm