I’m sure that my many and varied fans, especially those plumbed in through Google Reader, will be very interested to hear that, from the middle of this month, dantwining.com will be switched off and only dantwining.co.uk will point to this blog. It’s time to update those bookmarks!
Sometimes bigger isn’t always better. If your dynamically-expanding virtual machine images are growing out of control, then here’s how to trim them back…
As I mentioned in my previous article, I’m not entirely happy with my Block object. For a start, its name is completely wrong; nothing it does ever blocks the thread of execution. Secondly, I’m not happy that the Block object is responsible for both defining the characteristics of a Block objects, and for constructing their various implementations. Finally, I’ve realised that having a return type for the action() method makes the done() method entirely redundant.
The core of most JADE-based systems are the Behaviours that respond to incoming messages, sent to them by other Agents (and which, in turn, send messages to other Behaviours). Testing these Behaviours is critical, but complicated; instantiating a standard JADE Behaviour in a test involves instantiating much of the JADE architecture that, through inheritance, is required for the existence of any Behaviour; and that underlying architecture provides mechanisms used by Behaviours that aren’t accessible to the tests.
jade-oo decouples behavioural logic from the underlying JADE system, allowing isolated testing of these critical components. Here’s how…
In JADE, an Agent has a set of Behaviours, and each Behaviour has an action() method. The Agent calls the action() method of each Behaviour in turn, and so the overall operation of the Agent is performed by each of its individual behaviours.
By default, an Agent will continue to call each of the action() methods of its behaviours, in turn, without pausing. Rather than looping forever at 100% CPU, Behaviours can call one of two block() methods, provided by the Behaviour base class. Calling block() from within the action() method tells the Agent to only call action() again if a message is received; and calling block(long timeout) tells the Agent to only call action() again if a message is received or timeout milliseconds elapses, whichever is sooner.
What happens if, within your action() method, you call block() then block(50)? What happens if you call block() right at the beginning of your action() method? How can you unit test that a certain set of of inputs will prompt a Behaviour to block()?
Hiding calls to block() within the action() method results in hidden side-effects that are difficult to reason about, and difficult to capture and test.
I’ve spent the last couple of years working on, among other things, a JADE-based multi-agent system. JADE is a stable, mature framework for the development of agent-based systems, but it violates a few of the principles of good object-oriented software. jade-oo is my (outside-of-work) attempt to demonstrate how those issues might be addressed.
I’m not entirely sure what to make of this. It’s quite amusing though, even if it isn’t what I’d intended this blog to be about…