Dan Higgins
June 2004

'Box And Arrow' Systems for Modeling

Boxes and arrows (or lines) are often used for characterizing concepts or models. (Thanks to Bertrum Ludaescher of SDSC for the 'Box and Arrow' expression!) Boxes usually represent some seperable chunk or block of the model and the arrows are used to indicate relationships between these blocks.  Such 'Box and Arrow' diagrams come in a variety of forms ---  often first appearing on napkins, pieces of paper, or blackboards. (Yes, some of us are so old that we still remember using chalk and blackboards!)

More recently, these informal  'Box and Arrow' are more likely to appear on a computer screen, perhaps created in PowerPoint or some drawing program like Adobe Illustrator. More formal systems which actually use that structure implied by the boxes and arrows have also become more common. This document takes a look at a few of those systems


Generic Modeling Environment(GME)  ---  (http://www.isis.vanderbilt.edu/Projects/gme/index.html)

As indicated in the text below (from the web site referenced above), GME is a what may be called a metadata modeling system. It starts with very high level concepts in its model building process. The interface is still "boxes and arrows", however.

"The Generic Modeling Environment  is a configurable toolkit for creating domain-specific modeling and program synthesis environments. The configuration is accomplished through metamodels specifying the modeling paradigm (modeling language) of the application domain. The modeling paradigm contains all the syntactic, semantic, and presentation information regarding the domain; which concepts will be used to construct models, what relationships may exist among those concepts, how the concepts may be organized and viewed by the modeler, and rules governing the construction of models. The modeling paradigm defines the family of models that can be created using the resultant modeling environment.

The metamodeling language is based on the UML class diagram notation and OCL constraints. The metamodels specifying the modeling paradigm are used to automatically generate the target domain-specific environment. The generated domain-specific environment is then used to build domain models that are stored in a model database or in XML format. These models are used to automatically generate the applications or to synthesize input to different COTS analysis tools."

GME Screen
GME Screen


Stella --- (http://www.iseesystems.com/)

Stella is a system for modeling and simulation that has been around since 1985. It is apparently quite popular in the environmental science and biology communities. An example graphical model showing interactions between elk, wolves, and vegetation is shown below. In this case, the boxes are called "stocks", the pipe-like arrows are "flows", the circles are "converters", and the other arrows are "connectors". The visual metaphor is a sort of fluid flow concept. Stocks represent the 'amount' of something which is determined by the fluid flow through the pipes.

Stella models may only use a few types of  'boxes and arrows' but the meaning of the models is remarkable clear. In the diagram below, it is quite obvious that the number of elk is increased by 'elk-births' and decreased by 'dying naturally', 'elk eaten', and 'hunting'. And one can see that the number of 'elk eaten' depends upon the 'stock' (number) of wolves.

A little thought shows that a Stella model is really a graphical representation of a set of coupled rate equations. The net flows are just the rates at which stocks increase or decrease. Stella does a nice job of hiding these mathematical details, while letting the user determine what concepts determine the amount (stocks) of various parameters. Note, however, that it would be difficult to use Stella models for some other types of workflows - e.g. a set of sequential image processing steps applied to some scanned image.

Stella Model

A Model Screen from Stella


Open DX --- (http://www.opendx.org/)

Open DX is a visualization system that happens to have a "Box and Arrow" language for creating visualizations from data. (It is based on IBM's Data Explorer, now released as Open Source). A 'Visual Program Editor' screen from OpenDX is shown below. This is an example of an image processing workflow where the 'Boxes' represent operations or transformations that are applied to data that flows through the system on a path determined by the 'arrows' (lines). In the screen shown below, data flows into the "Import" box and then is mapped and processed in various ways until an 'Image' is created in the box at the bottom. Note that this type of workflow is quite different than the Stella workflow. It really shows how a sequence of operations (tools, as shown in the list on the left) are applied to some data, while the Stella model shows how the parameters in a model are related while hidding the mathematical operations represented.

Other similar systems include Khoros (now  VisiQuest --- http://www.accusoft.com/) and  Simulink (http://www.mathworks.com/products/simulink/) a MatLab related visual modeling tool.

Open DX Screen
Open DX Visual Program Editor


Ptolemy/Kepler --- (http://ptolemy.eecs.berkeley.edu/,  http://kepler.ecoinformatics.org/)

Ptolemy/Kepler provides a combination of some of the features of other "Box and Arrow" systems by providing a user defined method for specifying just what the boxes and arrows mean. In this system, the Boxes are called "Actors"; and the arrows connect "Ports" on the Actors. Data is passed between ports under the control of a "Director" which determines how and when the data is passed. A commonly used Director is the "Synchronous Data Flow Director", which makes the system look much like the Open DX image precessing system. It represents data flowing through a number of transformations in a prescribed sequence.

Ptolemy/Kepler Synchronous DataFlow Model

Ptolemy/Kepler can also be used to create models more like those in Stella, however, by using different directors. A "Continuous Time Director" can be used to create a Preditor/Prey model, for example. In the first screen below, a model directly based on the differential equations (Lotka Volterra) is shown. Coupled expressions for the rates of change of two species are feed into "Integration actors". This is similar to what is being done in the Stella screen previously displayed. One can also do the same thing using some additional actors and explicitly labeling the parameters as indicated in the second screen shot following this paragraph. This screen shows 'rates' flowing into 'integrators' which is conceptually the same as Stella's 'flows' into and out of 'stocks'.

Ptolemy/Kepler Continuous Time (CT Director) Model - Preditor/Prey Model Using Expressions

Ptolemy/Kepler Continuous Time (CT Director) Model - Preditor/Prey Model Using Mathematical Actors and Explicit Labels


Conclusions ???

I am not sure exactly what conclusions can be drawn from a review to the "Box and Arrow" system examples shown here (and many others that can be found on the web and elsewhere) except that they are fairly common, indicating that many people think they have some usefulness. Some are used to express fairly general concepts and the relationships between these concepts. Others are expressions of specific instances of a model rather than general purpose. Sometimes the 'boxes' represent actionsor transformations and data flows through the 'arrows'; in other cases, the 'boxes' may represent the data (e.g. Stellas 'stocks') and the actual operations are somewhat hidden.