Pseudocode · Viking Code School

Modular Pseudocode for an Elevator

As an assignment for the Software Engineering Basics course of Viking Code School’s prep work, I was tasked with writing a program in pseudocode for an elevator. The program was to be broken down into modules that could tackle specific tasks and communicate with each other for the largely goal of operating the elevator.

The Premise:

You live in a 25 story building with one elevator. The central microcontroller got eaten by rats and the building manager has asked you to code up the elevator’s operating procedure until he can get a new one. You first want to think things through and pseudocode your design.

Elevator Details:

The basic elevator machinery is completely dumb (it doesn’t do anything it’s not told to do) but is capable of interpreting and executing the commands:

  • “open elevator door”
  • “close elevator door”
  • “go up full speed”
  • “go down full speed”
  • “slow down”
  • “stop”

…and it accepts user input in the form of:

  • floor buttons inside the elevator
  • door open and close buttons inside the elevator
  • up and down call buttons on each floor

…and it has sensors for:

  • if a human is in the door closing path
  • if it is currently at a floor (instead of in-between floors)

…and it has a few quirky requirements:

  • it must “slow down” at least 1 floor before it stops.
  • there is a small chance that it actually stops between floors by accident (it’s an old elevator)

The Task:

Your job is to design a properly working elevator. It should stop on each floor it is physically able to during a given trip to pick up whoever is going the same direction. Additionally, make sure that no one is:

  • smashed into the ground
  • pushed through the roof
  • squished by the doors
  • let off in between floors
  • stuck going the wrong direction (unless they choose not to exit)

My Pseudocode:

My code is broken up into five modules. The first, Elevator, is a short initialization, setting the starting currentFloor variable at 1 and the movement variable at rest before running the Listen module. The Listen module runs on a loop that only stops if a person presses one of the call buttons. The Listen program runs again when the elevator finishes delivering passengers and returns to rest.

If a call button is pressed during the Listen loop from above the current floor, the MoveUp module is run, while if it is below, the MoveDown module is run. Both of these modules move the elevator to the floor where the call button has been pressed, checks that the elevator did not stop in between floors, then runs the ButtonPush module.

The ButtonPush module opens the door, only closes if the door path is not blocked. Another loop then runs, checking until a floor button or door open or close button is pressed from within the elevator. The MoveUp or MoveDown module is then run according to which way the elevator needs to travel. If no button inside the elevator is pressed after 30 seconds, the elevator returns to the Listen module loop. This accounts for the chance that an elevator arrives at a floor, but the requester does not enter the elevator.

This pseudocode program got me thinking about all of the different variables involved, the edge cases, and how they could all interact with each other, while also being separated into modules.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s