Q1. What is the purpose of designing an Elevator System in software terms?

Answer:

The purpose is to simulate and control the movement and behavior of one or more elevators in a building. The system manages floor requests, optimizes movement based on direction and current load, ensures safety mechanisms, and provides user interaction such as selecting a destination or triggering an emergency alarm. It is a real-world example of applying object-oriented design principles like abstraction, encapsulation, inheritance, and polymorphism.

Q2. Who are the key actors in the Elevator System, and what are their roles?

Answer:

• Passenger: Requests elevators, selects destination floors, and may trigger an emergency.
• Elevator Control System: Assigns elevators and determines optimal movement.
• Maintenance Technician: Performs diagnostics and puts elevators into service mode.
• Emergency System: Ensures safety during faults or fire. These actors help identify the use cases and interactions for modeling system behavior.

Q3. How are classes organized in the Elevator System's Class Diagram?

Answer:

The classes are divided into logical roles:

• Core System Classes: ElevatorSystem, Elevator, ElevatorController
• Component Classes: Door, Button, ButtonPanel, WeightSensor
• Utility Classes: Floor, EmergencySystem
• Relationships: The system uses aggregation (e.g., multiple Elevators in ElevatorSystem), and composition (e.g., an Elevator has a Door and ButtonPanel). The ElevatorController acts as the brain of the system.

Q4. How does the ElevatorController assign elevators efficiently?

Answer:

The controller monitors:

• Each elevator’s current floor and direction

• The floor request’s direction (up/down)
• Pending requests in elevator queues Using this data, it applies scheduling logic like:
• Nearest Elevator Algorithm
• Look-Ahead Optimization
• Idle Elevator Priority This logic ensures minimal wait time and efficient usage of elevators.

Q5. What are some edge cases the system should handle?

Answer:

• Overload: If the weight exceeds a threshold, the elevator shouldn’t move and should show a warning.
• Emergency Triggered: Stops the elevator and sounds an alarm.
• Power Failure: Returns elevators to the ground safely.
• Conflicting Requests: Same floor, both up and down pressed; handled based on direction and load.
• Multiple Requests: Queue management ensures the elevator serves requests in a logical order.

Q6. How is the Door subsystem managed?

Answer:

Each Elevator has a Door object with two main methods: open() and close(). The door operates automatically when the elevator stops at a floor. It also includes obstruction detection logic to reopen the door if something blocks it while closing. The Door class works closely with the state of the Elevator and safety rules.

Q7. What design patterns are used in this system?

Answer:

• Singleton Pattern: For ElevatorSystem, ensuring a single control unit.
• Observer Pattern: To notify when floor buttons are pressed.
• Command Pattern: For encapsulating elevator movement and requests.
• State Pattern: To manage elevator states like MOVING, STOPPED, or DOOR_OPEN.

Q8. Can the system be extended for multiple buildings or smart systems?

Answer:

Yes, the system can be extended by:

• Introducing a Building class to group multiple ElevatorSystems.
• Adding Access Control for security-restricted floors.
• Using real-time Sensor Data and AI logic for predictive movement.
• Creating mobile apps or IoT integrations for user control.