Blackboards

Brian Sung
Nov 1 · 4 min read

In order to keep up with the ever-changing requirements, programmers need to make every effort to write code that is as flexible as possible. This will allow code to stay up-to-date for as long as possible and be fixed with relative ease. In order to write code that is flexible, you must minimize coupling (better known was decoupling)–the dependencies among modules of code. One of the techniques for decoupling that I am going to highlight in this blog post is called the Blackboard technique.


The Blackboard technique is a term coined by “The Pragmatic Programmer” that aims to decouple modules even further by providing a meeting place where modules can exchange data anonymously and asynchronously. For example, think about how detectives crack murder cases. Maybe there will be a room with a blackboard in the middle, and the chief investigator will write a note with the question “Who committed the murder?” and post it on the blackboard.

Each detective may make contributions to the potential murder mystery by adding their knowledge, facts, statements from witnesses, any forensic evidence that might arise, etc. As the data accumulates, a detective might start to notice a connection and post that speculation or observation as well. This process continues with different detectives, different shifts, until the case is closed.

When using the blackboard approach, some of the key features include:

  • None of the detectives need to know the existence of any other detective. Individually, they look at the blackboard for new information and add their findings/speculations.
  • The detectives may all have different skills, different disciplines, different educational backgrounds, etc. Although there is a difference in the level of expertise by each detective, they all share the same desire to solve the case.
  • Different detectives may come and go during the course of the process and may work different shifts.
  • No restrictions apply on what can be placed on the blackboard. The blackboard can have text, pictures, physical evidence, etc.

Using a simple blackboard model can give you a solid metaphor to work with when making a design. All of the features above which described detectives are just as applicable to objects and code modules. By using a blackboard system, you are able to decouple objects from each other completely, providing a meeting place for consumers and producers can exchange data anonymously and asynchronously. Ultimately, it cuts down on the amount of code you have to write.


Blackboard implementations

Originally, computer-based blackboard systems were invented for use in artificial intelligence applications where the problems to be solved were large and complex–such as speech recognition, knowledge-based reasoning systems, etc. Nowadays, blackboard-like systems are based on a model of key/value pairs; a concept known as tuple space.

Using these systems, for example, you can store active Java objects–not just data–on the blackboard and retrieve them by partial matching of fields or by subtypes. For example, let’s say you have a type Actor which is a subtype of Person. If you wanted to find a particular actor, you could search a blackboard containing Person objects by using an Actor template with a lastName value of “Jackson”. You will possibly get the actor Samuel L. Jackson, but not the singer Michael Jackson.

Since blackboards allow you to store objects, you can design algorithms based on a flow of objects, not just data. Think of it as detectives pinning witnesses themselves onto a blackboard, not just their statements. Any of the detectives can ask a witness questions related to the case, post the findings, and move that witness to another area on the blackboard, where he or she might respond differently if given access to read the blackboard.

A big advantage for using a blackboard system is it gives you a single, consistent interface to the blackboard. It removes the need for so many interfaces, making it a more elegant and consistent system to use.


Application example

Consider the following problems (which can apply to many things):

  • There is no guarantee on the order in which data arrives.
  • Data gathering may be done by different people distributed across different offices in different time zones.
  • Data gathering may also be done automatically by other systems, which may arrive asynchronously.
  • Certain data may be dependent on other data.
  • Arrival of new data may raise new questions and policies.

Using a blackboard system in this case in conjunction to a rules engine that encapsulates the requirements is an elegant solution to the problems listed above. This allows the order of data arrival to be irrelevant because when data arrives, it triggers the appropriate rules. Feedback is easily handled as well because the output of any set of rules can post to the blackboard and trigger more appropriate rules.

The same can be accomplished with brute-force methods, however, the system will become more brittle. When it breaks, you might not be able to get it to work again. When coordinating workflow, use blackboards.

Brian Sung

Written by

Blogs from my apprenticeship at 8th Light

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade