CategoryProtoPattern
----

SingleThreadedAgentPattern is probably not a good name for this pattern -- suggestions are welcome.  Edit my text if you think I would find it an improvement.
''Thanks for the picture, whoever you are.''
I also think this is (or should be) a well-known pattern.  Any pointers?  --MarnixKlooster

----

You are creating a piece of software that consists of several processes that communicate asynchronously through some event mechanism.  The only way to run the system is to run those processes in parallel.  You want SoftwareDesignForTesting.  But this structure is a nightmare to test: the exact timing of events changes inbetween runs.

'''Therefore,'''
implement the following structure for each process.

http://c2.com/wiki/agent.gif


The Agent is activated by calling methods on the ListenerInterface.  The Agent notifies the outside world of important events by calling methods on the NotifierInterface.

Using this design, it is easy to test the Agent.  Create an class NotifierForTest which implements the NotifierInterface, that simply logs all methods called on it.  A test script first creates an Agent and gives it a NotifierForTest.  Then it starts calling methods on the ListenerInterface, and checks the result stored in NotifierForTest.

You can now run the processes by letting every Agent run in its own thread, and let it run a message loop: read an event from the message queue, call the method on the ListenerInterface, repeat ad infinitum.  Create a Notifier class, which implements the NotifierInterface methods by sending events.  These events should send events to the message queues of the other Agents' threads.

'''Advantages'''

The important feature of this design is that the Agent is always used in a completely single-threaded way, so that you don't have to worry about synchronization issues.

A nice side effect of this approach is that the code for the Agents is completely independent of the event mechanism used between the processes.  So the event mechanism also can be tested separately.

'''Potential problems'''

The thing to look out for is the events -- make sure that the data contained in the event isn't used by two processes at the same time.  Either copy the data, or make sure the event's data is synchronized correctly.

'''Examples'''

We have applied this ProtoPattern very successfully in software we have recently written.  There were actually three different Agents communicating, and one of the Agents was also communicating with itself through the event mechanism.  [More details will perhaps be added later.]

-----

I used this pattern for implementing digital video to desktop. Each stage in processing a frame was implemented as an object that looped within a thread, with some synchronisation between these objects. See:
http://www.research.digital.com/SRC/argo/ecoop/ecoop.html

Another name for this pattern could also be DaisyChain. --SteveFreeman

----
Are there any tools which help to automate this type of testing pattern,
where one sequence of events generates another?