Problem definition
You are tasked with designing an elevator system for an office building.
Questions for the interviewer
- How many elevators can be in the building? How many of elevator cars will work concurrently?
- How many buildings do we serve?
- What functions should each elevator car panel support (e.g., open doors, close doors, turn on ventilation, emergency call)?
- What is the capacity of each elevator car (number of persons and maximum allowed weight)?
- Should the elevator have information panels inside the elevator car and on each floor? What information should be displayed on these panels?
- What optimization techniques should we apply for the elevator system? Should we prioritize optimizing idle time, waiting time or energy consumption?
Requirements
R1. The elevator system consists of 1 elevator per building with 3 concurrently working elevator cars.
R2. We serve an ensemble of 5 buildings. The elevator system is the same in each building.
R3. Each elevator car should support the following functions: select a floor, open doors, close doors, emergency call, and turn on ventilation.
R4. There should be a button panel on each floor with “Up” and “Down” buttons.
R5. The maximum allowed capacity of each elevator car is 6 persons or 600 kg.
R6. Each elevator car should have an information panel that shows the current floor number.
R7. Each floor should have hall information panels that indicate the direction of user requests if an elevator car has been requested.
R8. The elevator system should support 3 optimization strategies: minimize idle time, minimize waiting time, and minimize emery consumption.
Use case diagram
First of all, let’s define actors and possible use cases.
Primary actors: passenger
Secondary actors: service employee
System: elevator system
Passenger | Service employee | System |
Press button at the hall panel | Press button at the hall panel | Move the elevator car |
Press button at the elevator car panel | Press button at the elevator car panel | Process the elevator car request |
Change the optimization strategy | Process the hall request | |
Open/close door | ||
Show information on the hall panel | ||
Show information on the elevator car panel |
Relationships:
Generalization:
- Press an elevator button, such as “Open door”, “Close door”, “Emergency call” or “Floor number”, can be inherited from the “Press an elevator button” use case.
- Press a hall button, such as “Up”, “Down”, can be inherited from the “Press a hall button” use case.
- “Show information on the hall panel” and “Show information on the elevator car panel” could be inherited from the common use case “Show information on the panel”.
- “Process the elevator car request” and “Process the hall request” can be children of the common “Process request” use case.
Include:
- “Press button at the hall panel” use case includes “Process the hall request”.
- “Press button at the elevator car panel” use case includes “Process the elevator car request”.
Extend:
“Process the elevator car request” and “Process the hall request” can be extended by “Move the elevator car” if there are available elevator cars.
Diagram:
Sequence diagram
Let’s create a sequence diagram for the “Elevator call” interaction. To do this, we should first compose a list of actions included in the interaction:
- Passenger: presses a hall button.
- Hall button: creates a hall request.
- System: evaluates the desired direction for the hall panel.
- Hall panel: displays the desired direction.
- System: finds an appropriate elevator car.
- System: starts moving an idle car or continues moving the existing car.
- System: stops the car.
- System: opens the doors.
Activity diagram
Activity diagrams serve to represent a process as a transition between initial, intermediate, and final statuses.
Let’s compose an activity diagram for the action “Elevator car ride”.
Class diagram
Used design patterns:
- Observer – Observable pattern (to update date on the information panels).
- Command pattern (to execute the service command).
The codebase is published on GitHub.