Requirements

• As a user I am able to request an elevator to the desired floor
• As a user I am able to drop at the desired floor
• As a user I am able to stop the elevator
• As a user I am able to send alert

Non-functional requirements:

• The elevator should move either from bottom to the top or from the top to the bottom
• In case of emergency the elevator should open the door at the closest floor and then move to the bottom when all users left the elevator
• The elevator does not move if it outweighs
• Elevator should support different sizes and weighs.
• The system should send a notification in case of emergency
• The system should enable disabling elevator to do maintenance

Define Core Objects

• Building
• Location
  • FloorLocation
  • ElevatorPlan
• ElevatorScheduler

Analyze Relationships

The building allows defining elevator locations. Each location defines a set of available floors and restrictions (working hours, max weight, etc).

The elevator can be requested and drop at all available floors. If the request or drop operation requires privileged access, the specific token should be provided that is verified with SecurityTokenVerifier.

The movement plan for the elevator is encapsulated in the ElevatorPlan instance that defines an order of floors to go through.

The elevator plan is enforced by the corresponding ElevatorScheduler. All requests to request, drop or reschedule elevator go through the scheduler.

If elevator's movement plan depends on other elevators, they can be merged into the cluster. So, each time the elevator's position is updated, plans for linked locations can be updated as well.

The operation mode can change. Effectively, the operation mode just changes the underlying scheduler and reschedules all elevators.

The plan is reconsidered each time when the request/drop is made.

Also the system has a monitoring system that periodically validates the elevator state and allows setting up alerts to be notified about the suspicious behavior.

Establish Hierarchy

Generally, the data model prefers to use composition over inheritance

Design Patterns

ElevatorScheduler, SecurityTokenVerifier, ElevatorObserver implement strategy pattern. LocationBuilder implements a builder pattern.

Also we use an observer pattern to notify the model about updates from the device.

Define Class Members (write code)

Attributes: For each class, define the attributes (data) it will hold...

Methods: Define the methods (functions) that operate on the attributes. Ensure they align with the object's responsibilities and adhere to the principle of encapsulation.

Adhere to SOLID Guidelines

SRP

• SecurityTokenVerifier follows single responsibility principle
• Scheduler is responsible to plan elevator movements
• Location and Location clusters are also separated into separate models

OCP:

• Not sure that we have examples that illustrate this

LSP:

• Schedulers and SecurityTokenVerifiers can be used interchangeable

ISP:

• The design mostly follow this principle

DIP:

• All external behavior is extracted into separate components (ElevatorScheduler, SecurityTokenVerifier)

Consider Scalability and Flexibility

The system can be extended with custom ElevatorSchedulers

Create/Explain your diagram(s)

Try creating a class, flow, state and/or sequence diagram using the diagramming tool. Mermaid flow diagrams can be used to represent system use cases. You can ask the interviewer bot to create a starter diagram if unfamiliar with the tool. Briefly explain your diagrams if necessary...

Future improvements

• Improve async state management