Who Cares?

The software architecture will not be of interest to most of the folks who would want a behavior analysis related app. But behavior analytic types who are also computer geeks might find this description of the internals of the software interesting.

Mostly this section is for me, to remind myself what I am building, where it is going.

Overall Structure

The general structure of the Continuous Behavior software is a configurable framework. The core framework supplies the functionality used to implement your applications. This core software is configured using human readable text files which are loaded by the framework to provide the specific functionalty that you require. The configurations are created as part of the application and cannot be changed.

The structure of the code and the structure of the configuration files parallel each other, as you might expect. The configuration files are more "user friendly", so I will use example configurations to illustrate the structure of the Continuous Behavior code. Note that configuration snippets are for illustration only, and may not be functional configuration.

The framework follows the Model-View-Controller (MVC) software architecture first popularized by Smalltalk in the early 1980's. A more modern example is the Ruby on Rails (RoR) web development environment.

The MVC architecture is intended to improve software maintainability by separating out the three major concerns of the application:

  1. the data representation (i.e., the model);
  2. how the user sees and responds to the data (i.e., the view); and
  3. the logic that ties the two together and which defines the overall behavior of the application (i.e., the controller).

The application does not strictly follow a MVC architecture. For example, where the programming model of IOS makes it easy to do so, the view may update the model without involving the controller. In fact, in some cases strictly following the MVC architecture would be difficult, and would subvert features of IOS. I do not follow the MVC architecture for the sake of following it.

Below is a configura tion snippet illustrating the top level structure of the Continuous Behavior software, including an overview of what the application is intended to do. Note that the configuration format is XML.

<instrument name="example_click_trainer" title="Click Trainer">


<overview>

User defines responses to be trained, schedule of reinforcement, and the
clicker sound to use for each. User may also define relevant stimuli which
presence or absence is to be recorded via buttons.

User presses appropriate behavior button as responses are observed. All
responses are timestamped, logged, and accumulated in summary tables, along
with whatever stimuli were in effect at the time.

Clicker emits the user selected sound for the behavior to signal time-to-reinforce
when schedule for that behavior is satisfied, including responses or non-responses
in presence/absence of user specified stimuli.
</overview>

<!--

Model: Underlying data store. Also known as: business model, data model. Responsible
for storage and retrieval of data; data integrity. The model is theoretically
independent of view and controller.
-->
<xi:include href="Model/Model.xml"/>

<!--

View: The user interface. Manages screens and objects on screens. Accepts user input,
which is handled by the controller.
-->
<xi:include href="View/View.xml"/>

<!--

Controller: Functionality that glues together the model and view to implement the
application logic.
-->
<xi:include href="Controller/Controller.xml"/>
</instrument>

Notice the "include" lines, such as this one:

<xi:include href="Model/Model.xml"/>

These lines cause the specified XML files to be read and used in place of the "include" line when the configuration is loaded. Without this ability, the configuration would be one huge file that would be vastly more difficult to understand.

Model

The model portion of a Model-View-Controller (MVC) software architecture is responsible for defining and managing the persistent data of the application. It provides the ability to read and update the data, plus it is responsible for maintaining the internal consistency of the data.

View

The view is the portion of the application that manages the device screen and objects on the screen. The view makes selected data from the model visible to the user. There may be multiple views on any piece of model information. The view does not directly ever modify model data; it only modifies data with the help of the controller or via model facilities that ensure data integrity.

Controller

The controller is the glue that ties the model and the view together with application configuration and logic. It manages events generated by the user via the view to produce the major actions of the application. In particular it provides the state machines that implement session control and "schedules of reinforcement."