This introduces a hierarchy of Swarms

This is the same story of the Students, their fingerprints, and the Policeman.

Except now there is a new class, called Observer. The Observer gives the user a graphical interaction with the simulation.

The Swarm scheduling apparatus is designed to manage actions that occur at several different levels. So the "top level", now the observer, is the one that is created in the main function of Test.java. Then that Observer object creates the Model swarm.

Observer

This is the new class in this example. Many Swarm models have this design, where a top level class is created to collect information and chart graphs and so forth. In this simple example, we have created only one Swarm display, the EZGraph, and on there we just plot some silly numbers the students give us back when we ask them for data. Two lines are plotted in this graph. One line--the average of student reports--is constructed by surveying the elements of the agentList, which is retrieved from the Model when needed. The other line plots the report of a particular student. In order to be sure that the graphs update properly, we schedule them with Swarm scheduling and then activate them in the same context where we activate the lower level swarms.

Please note the sequence of instructions to the Observer in the main. It is a Swarm standard sequence.

buildObjects
buildActions
activateIn:
go

If you look down in the Observer class, you note that the buildObjects method will cause the Model object to be created and it will tell that Model object to go ahead and buildObjects() for itself. The same is true for buildActions() and activateIn:. This design is what interleves the actions at several levels into a common time scale.

I made a little mistake (oversight, really) in designing the schedules for this model. As in the previous exampes, the students contact each other for 10 periods, then a cop is appointed to find a criminal's fingerprint.

When you run this model, you press the start button, and you can watch the graph an read the output to the console. After the simulation hits the policeman's action, you are sitting there expecting the simulation to end, but it does not. Rather, even though no actions occur in the Model schedules, the agents still exist, and the graph still exists, so the graph can go on asking the students for data if it wants.

This gave me some ideas about ways to schedule agent actions directly from graph commands, but I don't know of any useful examples.

Model
The only change here is the addition of a getStudentList() method.

Student
The only change here is the addition of a getSomeData() method. I was a little at loss to think of some data the student could pass back for a graph, and so I did the bare minimum: they return random numbers. But if your example had something more interesting, you could use this same approach to graph it.