Concepts, Goals and Solutions in an Elevator Simulation Program: Collecting Valuable Statistics for Evaluating an Elevator System

This case study looks at a strategy for collecting important information from a particular elevator simulation to answer the question, "Is the elevator system that we are simulating performing its task of transporting passengers between various floors properly?" In other words, if we took a real elevator system, extracted all its relevant characteristics, and turned it into a computer simulation, how well would this system perform?

Statistics

A numerical fact or datum, especially one computed from a sample, is called a statistic.

Statistics is the science that deals with the collection, classification, analysis, and interpretation of numerical facts or data, and that, by use of mathematical theories of probability, imposes order and regularity on aggregates of more or less disparate elements.

The term statistics is also used to refer to the numerical facts or data themselves.

Two statistics considered important by most elevator travelers when rating an elevator system are

The time a typical person has to wait on a floor after having pressed the button to call the elevator
The average time it takes to travel one floor

An attempt to collect these numbers from an elevator simulation could be done as follows.

Because the Person objects are "traveling" through the elevator system, it is ultimately these objects that the Elevator objects must service. Consequently, the Person objects will "know" how well the system is working and are able to collect some of the essential statistics required. An analogous strategy in the real world would be to interview the users of the elevator system and gather some of their elevator system experiences.

Each Person object of the elevator simulation program could be implemented to have a couple of instance variables keeping track of its total waiting time outside the elevator (to answer the first bullet) and an average traveling time per floor (addressing the second bullet). They would give a good indication of how well the elevator system is working and be part of the statistics collected for each simulation. We could call these variables totalWaitingTime and averageFloorTravelingTime.

Calculating totalWaitingTime would require a method located inside Person containing instructions to start the computer's built-in stopwatch every time the person has "pressed a button" on a particular Floor object calling an elevator. As soon as the Elevator object "arrives," the stopwatch is stopped and the time is added to the current value of totalWaitingTime.

Similarly, the averageFloorTravelingTime is calculated by another method inside Person starting the stopwatch as soon as the Person object has "entered" the Elevator object. When the Person has reached its "destination," the stopwatch is stopped and the time divided by the number of floors "traveled" to get the average traveling time per floor. This result is stored in a list together with other averageFloorTravelingTime sizes. When the final averageFloorTravelingTime statistic needs to be calculated, a method will calculate the average of the numbers stored in the list.

All these calculations involving starting and stopping stopwatches, summing numbers, calculating averages, and so on are not of any interest to other objects in the simulation, and they would complicate matters unduly for other programmers were they exposed to them. Consequently, we should hide all the methods involved here by declaring them to be private.

Each Person object must also be able to report its totalWaitingTime and averageFloorTravelingTime sizes. We can do this through two public methods arbitrarily named getTotalWaitingTime and getAverageFloorTravelingTime. Any other object calling any of these two methods will receive the corresponding statistic.

Another programmer who is also working on this project is writing a class to collect the important statistics of each simulation. He or she calls this class StatisticsReporter. He or she must ensure that all Person objects are "interviewed" at the end of a simulation by letting the StatisticsReporter collect their totalWaitingTime and averageFloorTravelingTime statistics. The StatisticsReporter can now simply do this by calling the getTotalWaitingTime and getAverageFloorTravelingTime methods of each Person object involved in a particular simulation.

To summarize:

getTotalWaitingTime and getAverageFloorTravelingTime are part of an interface that is hiding or encapsulating all the irrelevant complexities for our happy programmer of the StatisticsReporter.
Likewise, the instance variables of the Person objects should be hidden by declaring them private. This prevents any other objects, including the StatisticsReporter, from mistakenly changing any of these sizes. In other words, the getTotalWaitingTime and getAverageFloorTravelingTime methods "cover," by means of encapsulation, the instance variables totalWaitingTime and averageFloorTravelingTime as a protective wrapper by allowing only the StatisticsReporter to get the values of these and not to set them.