Pat's Introduction

Last summer I decided to get a programming job to further develop the skills I had learned in class. I was hired to modify a simulation program that was designed to help marine biologists study fish movement in a small bounded environment, such as a lake or a bay. An initial version of the program had already been written, but the biologists wanted to make some improvements and add some new functionality.

A simulation is a model of a real system. Scientists build simulations to better understand the systems they are studying, to observe and predict their behavior, or to perform experiments on them. Many real systems are difficult or impossible to observe and control, much less experiment with. It is easy, though, to run a simulation program repeatedly and to modify it to explore the effect of changes to the model.

To become familiar with the marine biology simulation, I was referred to Jamie, an experienced software developer. Jamie described the existing program to me, and I continued from there. This is my report of what I learned and the code that I developed. I was working on a simulation of fish moving in a relatively small body of water, such as a lake. The modifications I added made the simulation more interesting and allowed the biologists to study more complex behavior. For example, one change I made allowed the biologists to track the fish population as fish breed and die. Another change allowed them to study what happens when there are several kinds of fish in the environment, with different patterns of movement.

Experimenting with the Program ("Black-Box" Testing)

On the first day of my internship, Jamie was not available to introduce the inner workings of the program to me, but my boss told me I could experiment with it to figure out what it did. I was given some instructions for running it and told where to find several data files to use with it. This was an interesting variation on "black box testing" — usually black-box test cases are derived from a high-level program specification, but in this case I was trying to deduce the specification from the program's behavior.

A black box object or module is one whose internal workings are hidden from the user. A classic example in the real world is a toaster; most people know how to use a toaster without ever looking inside it to see how it is wired. Black-box testing refers to running and testing a program based on the program specification, without knowing how it is implemented.

The first thing I did was to download the existing program and determine how to compile and run it. I ran the program several times with the different files and watched the behavior.

Exercise 1

Analysis Questions

  1. What do the grid lines represent?
  2. Where can fish be in the model? Can there be more than one fish in the same place at the same time?
  3. Do all fish face the same direction? Does a fish’s direction appear to matter?
  4. Pick one fish and watch it for several steps. Does it move in every step? How far does it move? Does it always move in the same direction? Can it move in any direction? Is it more likely to move in one direction over another?
  5. In general, how is the operation of the Marine Biology Simulation program similar to, and different from, the Aquarium Lab Series?
(A Markdown template for writing up answers to the Analysis Questions on this page is here.)

I made some notes and tried to deduce what the "rules" were in the program for fish movement. It was difficult to keep track of everything that was happening, so I decided to be more scientific in my tests. I noticed there was another data file named onefish.dat, which contained just a single fish. Using that, I created a table showing where the fish was at each timestep, which direction it was facing, and where it moved.

Exercise 2

Looking at the Data Files

I wanted to see if I could read the data files that were providing the initial configuration of fish in the "small bounded environment" of the simulation. I decided to start with onefish.dat. It turned out to be a plain text file, whose contents were: 

    bounded 7 5
    Fish 3 2

Exercise 3 and Analysis Questions

  1. Using any program that can view plain text files (such as Brackets, Atom, TextExit, Notepad, etc.), look over fish.dat and then run the program again using that data file. What appears to be the significance of the first line in each data file? What about the other lines?
  2. If the numbers "3 2" in onefish.dat refer to the initial location of the fish in the environment, how are locations in an environment numbered?
  3. Notice that there is another folder within the DataFiles folder, called UnboundedGridDataFiles. Compare the onefish.dat and fish.dat files in the two folders.
  4. Run the simulation program using both versions of fish.dat. What happens when fish get near the edges of the window? Is it the same behavior in both cases?
  5. Create a data file of your own and then run the program using it. Is the initial configuration of the fish and the environment what you expected?
Alyce Brady, Kalamazoo College