Like many software products, Catacomb has evolved through its development. Mistakes have been made and better ways of doing things have been found after trying a range of alternatives. Not all components conform to the structure proposed here, but all new development does, and existing components are steadily being converted. )
A Model corresponds to a particular type of biological entity such as a T-type Calcium channel. Whereas a Framework specifies what variables and subcomponents are possible, a Model assigns particular values to them (for a channel, how many states there are, the properties of each etc).
If you give Catacomb a Framework then it can construct a user interface allowing you to make any model consistent with that Framework. If you give it a Model (using only the structures it understands) then it can deduce the Framework and allow you to make other models.
A consequence of the above is that models are hierarchical whereas Frameworks are flat. For example, The channel framework says that a channel contains a list of possible states. It doesn't say what a state is. That is left to the channel state framework. On the other hand, a model of a particular channel has to give not only the parameters of the channel, but also say what the states are and give their parameters and so on. Items at any level in the hierarchy are Models.
Computations of model behavior are associated with frameworks, not models. That is, the calculation is written to handle any model consistent with the given framework. In most cases, calculations involve two types of object: Properties objects include a condensed and efficient version of the data in the model and all the numerical code necessary to compute how a model behaves. State objects contain the instantaneous state of an instance of a model. For example, there may be many ion channels of the same type on a cell. In the calculation there would be many State objects (perhaps containing just one integer to say what state the channel is in) and one Properties object holding supplied and derived (buffered) data necessary for computing the evolution of the channels.
There are two core data structures used in models - Lists and Selections corresponding to the requirements of declarative model description. A List contains other models all of the same type. A Selection refers to a model by name. The model itself should exist in a list somewhere accessible to Catacomb - usually in a List which is part of a model higher up in the current hierarchy. A model may also occasionally contain another model directly, an Object, in which case it is referred to by its type.
Frameworks corresponding to a particular classes of biological entity state what the elementary parameter names are, and what lists, selections, and objects are present, each with a name and the type it contains or references.
At present, most frameworks are implemented as java class definitions, and models as instances of java classes. This is concise and convenient, but also potentially error-prone since a framework is much more restricted than a class definition. The favored approach is to store frameworks as models derived from the Framework framework. The latter is a model derived from itself so the regression does not continue ad infinitum.
Catacomb provides a GUI to create new models which represent frameworks, and can generate java source code and byte-code on the fly. This moves the task of making models - machine readable descriptions of biological systems - out of the programming domain and into the field of activity of experimental biologists. Of course, computing what they will actually do is another matter entirely.
Here is a complete listing of the contents of the Framework framework and the FrameworkElement framework it relies on:
Framework {
String name; // the name of the framework
String package; // the package to which it will belong
int color;
List frameworkElements;
String guiHints;
}
FrameworkElement {
String name;
int type; // one of INT, DOUBLE, STRING, CHOICE,
// OBJECT, LIST, SELECTION
String info; // text description of the field
int visibilityLevel; // an integer between 1 and 10 giving
// governing presentation to the user
boolean initialize; // whether to set the initial value
String initialValue; // if above is true, the initial
// value to be assigned in new models
boolean getClassFromName; // specify if the type of an object,
// list or reference should be deduced
// from its name
String targetClass; // type to use if above is false
String choiceOptions; // options for the menu, if applicable
String guiHints; // hints for the GUI about how to
// present a field
}
Given the above definitions, frameworks for all the models understood by Catacomb can be constructed. The machinery used to create new frameworks is the same as to create new models, since frameworks are just models based on the Framework framework. Likewise, the storage of frameworks is no different from the storage of models.
The above also shows the naming conventions used by Catacomb. A variable in a framework which is a list of elements of type ABCDefG is called aBCDefGs. An object or selection of type ABCdefG is called aBCdefG. These are not obligatory, but anything so named does not need a constructor.
If you use Catacomb to make a new model according to an existing framework "foo", in package "pkg" it performs the following steps: