Low Level Design of an Elevator System

Requirements

• There are multiple elevators in any building

• The elevators will be used by all

• For separate buildings, a separate elevator system

• Passenger/Service/Private elevators

• There are multiple algorithms for elevator movement ie FCFS, Shortest Seek time first, Scan Algo, and Look Algo, the design must support different algorithms for lift movement

• There are multiple algorithms for the serving elevator selection,odd-even selection, zonal selection

• A state must be maintained for the lift, which is visible on a Display

• There is an external button on every floor to summon the elevator and another internal keypad inside every elevator

• The external requests have direction with respect to the source floor and internal requests have a destination floor for a specific elevator ID

User Flow

• The user presses the up or down button, on any particular floor(Source Floor)

• One of the lifts is selected to serve

• Users can enter the Lift and press the keypad to enter the destination floor

• The User successfully reaches the destination floor

Object/Classes Indetification

(starting with what happens inside main()- top-down)

ElevatorSystem (Singleton for a single building)

• Encapsulates all the high-level APIs into a Facade for interacting with our System

• Initialises number of floors and elevators

• Has an elevator selection strategy

• Has an external request handler for outside buttons- ExternalRequestProcessor, this sets the elevator selection strategy and processes external requests

• Has an internal request handler for inside buttons,-InternalRequestHandler this process of internal requests

• Has an ElevatorManager that in turn instructs the Elevators how to move

External Request

Internal Request

ElevatorManager (also a singleton)

• maintains a map of elevator IDS to elevators

  

• 

ExternalRequestProcessor

• We encapsulate the ElevatorSelectionStratergy inside the ExternalRequestProcessor which uses this strategy to serve ExternalRequests of choosing an elevator

ElevatorSelectionStrategy/ElevatorSelectionStrategies

InternalRequestsProcessor

Elevator

ElevatorController/ElevatorMovementController

ElevatorCurrState

ElevatorControlStrategy/ElevatorControlStrategies

Sensor

• 

  Sensor class is an Observer and all elevators are observables

Summary of the Design

• The ElevatorSystem facade is created which encapsulates all the high-level APIs needed to interact with our system

  • It can return you a singleton instance for the system

  • It can initialise the lift system (number of lifts, number of floors) for you using the ElevatorManager, also spawning instances of ExternalRequestsProcessor and InternalRequestsProcessor in the process

  • When ElevatorSystem gets an internal request it creates an instance of InternalRequest and passes it to InternalRequestsProcessor's handler

    • This InternalRequestsProcessor's handler invokes the ElevatorManager (which has elevator->ID mapping) to fetch the relevant Elevator via elevator ID and passes the destination floor to an Elevator handler

    • Each Elevator has a handler that gets the destination floor from above and uses the composed ElevatorController to move the controller

    • The ElevatorController has an ElevatorCurrState and ElevatorControlStrategy, both of these determine how and where the elevator moves

  • When ElevatorSystem gets an external request it creates an instance of ExternalReqest and passes it to ExternalRequestsProcessor's handler

  • The ElevatorSystem takes in a concrete ElevatorSelectionStrategy and sets the ElevatorSelectionStrategy for the ExternalRequestsProcessor instance

UML DIAGRAM

Additional Improvements

• Alternative Design

• 

• Above, the strategy design pattern is used by ExternalButtonDispatcher (ElevatorSelectionStratergy) and by ElevatorCarController (ElevatorCarControlStratergy)

• ElevatorCarControlStratergy deals with how the enqueued requests are served given the direction the elevator is moving and the direction the user wants to go

  • SCAN: The elevator moves in one direction completely in one pass serving all the requests in that direction only, sequentially. We would continue moving in every direction completely, even if we do not have any service requests in that direction

  • LOOK: The elevator improves on SCAN and changes direction if no requests are pending in that direction