Archive for the ‘Development methodologies’ Category

Data Flow

December 31, 2009

Today’s topic is ostensibly Data Flow, though the linked article deals with the offshoot dubbed by its inventor “Flow-Based Programming”.

More often than not, data flow programming involves using a GUI to connect boxes to one another.  The connections direct the “flow” of data through reusable components to build a software system.

There are some interesting examples in the audio and video worlds, where signal generators or input sources are routed through processors, filters, mixers, and so on.  Such systems allow non-computer-scientists and non-hardware engineers to build complex software signal processors quickly, and visualize and test the results along the way.

Sonic Core SCOPE audio data flow

Xine video architecture data flow

Business process managers tend to follow the data flow programming model, too.

Although data flow programming often depends on niche proprietary development environments, the concepts involved can be applied when designing any software.  The key is to separate the logic from the data structures during system design.  This separation facilitates the design of reusable logic components — input sources, data generators, filters, output targets, and so on.  Such reusable components can significantly ease the development of new features; and modifying existing logic often becomes a simple matter of surgically inserting or removing reusable logic components.

Of course, object oriented fanatics have a hard time separating logic from data.  But an open-minded OO developer might save herself a lot of bad code and software bloat by keeping the data flow paradigm in mind the next time she designs a new software system or reverse-engineers an existing one.

J. Paul Morrison developed a more-or-less data flow system for a Canadian bank (?Bank of Montreal?).  He writes about Flow-Based Programming in a quirky style and with a few antiquated ideas thrown in for good measure.  Originally his intriguing essay was a book, now out of print:

http://www.jpaulmorrison.com/fbp/book.pdf

Enjoy!

ttp://media.createdigitalmedia.net/cdmu/images/stories/2006/august2006/creamware_scope_desktop.jpg
Advertisements

Actor Model

November 29, 2009

Today’s article describes the Actor Model.

The Actor Model is one part methodology, one part framework for building parallel, distributed systems.  Each “Actor” is an agent which does its own thing, and communicates with neighbouring Actors.  Both object-oriented programming and peer-to-peer networks share many of the concepts and constraints of Actor model systems.

From one of the early papers on the Actor Model (“Viewing Control Structures as Patterns of Passing Messages”, Carl Hewitt, 1976):

The actor metaphor for problem solving is a large human scientific society: each actor is a scientist.  Each has his her own duties, specialties, and contracts.  Control is decentralized among the actors.  Communication is highly stylized and formal using messages that are sent to individual actors.

To me the most startling and interesting concept of the Actor model is that communications are carried out between Actors A and B by creating a “messenger” – itself an actor! – and sending the messenger to actor B.

In object oriented programming, this would be a bit like calling a method with the ability to decide what parameters to pass after the method has started executing.  This would be a hardcore drug for dependency injection’ists!

Hewitt’s 1976 paper is seminal:

https://www.cypherpunks.to/erights/history/actors/AIM-410.pdf

However I do think there is better reading on the topic, and Gul Agha’s articles in particular is a much more enjoyable read:

http://dspace.mit.edu/bitstream/handle/1721.1/6952/AITR-844.pdf?sequence=2

There is also a great little collection of links on the “E programming language” website:

http://www.erights.org/history/actors.html

Happy reading!