Data model support classes

The ‘thin’ framework layer is primarily concerned with the implementation and execution of iPipeline’s workflow. However it does need to provide a means to build the ‘thick’ problem domain specific framework layer “on top of itself”. The data model support classes are intended to provide a group of software entities that support the development of the ‘thick’ problem domain layer. The ‘base process classes’ discussed in the previous section could fit this definition but are of such key importance they warranted a separate discussion. Figure 7-7 expands upon Figure 7-5 to show the data model support classes / interfaces.

Page | 104

Figure 7-7: Core iPipeline interfaces and their relationships

The data model support classes divide into four “sub-systems” to support the operation of the thin framework layer. These sub-systems may also be used by developers

Chapter 7: Design of iPipeline

Page | 105

implementing the “thick” problem domain layer. Table 7-4 summarises the provided sub- systems, their purpose and the classes / interfaces that provide their implementation.

Sub-System Name Classes / Interfaces Description

Dataflow token IProcessingResult The interface to be

implemented by the class that will serve as the dataflow token (see Chapter 5)

Settings Panel ISettingsPanel Interface to be implemented

by a graphical component that allows customisation of problem domain algorithms Parameter Management IValuePair<E,F>

IParameter<E> IParameterManager

Provides a generic system for transferring any data value without knowing its data type

Observer Pattern IObserver

ISubject IConnectable

Interfaces used to implement the observer software design pattern

Table 7-4: Thin framework layers supporting sub-systems

7.2.3.1 The dataflow token sub-system

As chapter 5 explained iPipeline employs a structure based dataflow model that generates a single output token from each workflow process. The token needs to ‘flow’ through the workflows directed graph. The ‘thin’ framework layer is responsible for ensuring that this happens. At the same time the ‘thin’ layer knows nothing about the token’s implementation. The token is highly specific the problem domain and is therefore implemented in the ‘thick’ problem domain layer. To solve this problem a software interface has been created in the ‘thin’ framework layer. This interface (IProcessingResult) must be implemented in the ‘thick’ problem domain layer. This interface ensures that the ‘thin’ framework layer can transfer the dataflow token between processes of the workflows directed graph.

7.2.3.2 The settings panel sub-system

While individual processes within a workflow have a consistent visual representation it is possible – even likely – that some of the problem domain algorithms encapsulated within them will require user defined inputs. In neuroscience for example many algorithms require the researcher to define a time window (the cross-correlation algorithm would be one case). The user defined inputs for a workflow process are dependent on the algorithm encapsulated by the process. The ‘thin’ framework layer can, therefore, have no knowledge of these (they are defined in the ‘thick’ problem domain layer). Despite this the ‘thin’ framework must still store and manage such user input since it is part of defining a workflow. This problem has been solved through the creation of the ISettingsPanel interface and the parameter manager sub-system.

The ISettingsPanel interface provides the ‘thin’ framework layer with the ability to attach a Java JPanel to any processes glyph. Accessed via the process glyph button (see Figure 7-6) this panel allows algorithm specific values to be supplied. The problem domain developer is free to develop any panel they need for their algorithm simply by implementing this interface. However the ‘thin’ framework layer needs to make the user inputted values

Page | 106

available to an algorithm in a consistent manner. This has to be achieved without the thin layer placing any restrictions on the user input and without knowledge of the number or type of values to be passed to the algorithm. The solution adopted models values as a name / value pair where the name is always a string and the value is a Java generic datatype that can become any type of value. This structure is known as a “Parameter” and is highly suited to inclusion in a list data structure. The Parameter Manager sub-system discussed in the next section manages an array list structure of these parameters. The ISettingsPanel provides interface methods to access “parameters” created by the JPanel that implements it. The BaseProcess uses these methods to populate a “parameter manager” object which the problem domain developer can access from the algorithm they are encapsulating into a process. This provides the problem domain developer the freedom to create and store as many “parameters” as they wish when creating the settings panel for a process. At the same time access is provided to these parameters via a software interface. This ensures that the developer’s parameters (whatever they might be) are delivered to the algorithm encapsulated in the process being created.

Figure 7-8: Settings panel for burst sort algorithm

Figure 7-8 provides an example of a settings panel for sorting neural spike train data based on when the spike train shows the first ‘burst’ of spiking activity. The panel is completely configurable by the problem domain process creator in terms of algorithm specific parameters. However it does require the presence of the OK and Cancel buttons as these store, or remove, the parameters from the processes ParameterManager software object. In addition the problem domain developer should name the dataset with a descriptive name which will be used to identify the dataset in any visualisation. The final design of a settings panel will contain two elements. The OK / Cancel and dataset name will always be present and forms the link between iPipelines ‘thin’ framework layer and the ‘thick’ problem domain layers. The remaining controls, values and the parameters generated from them are specific to the encapsulated algorithm and form part of the ‘thick’ problem domain framework layer.

A final issue faced when linking the ‘thin’ framework layer to the algorithm specific settings panel is the validation of the parameters. The ISettingsPanel provides a method to validate the parameters. This of course must be coded by the problem domain developer but the true / false Boolean result indicates the validity of the algorithm’s parameters to the ‘thin’ framework layer. A configuration that fails to pass this validation method cannot be part of a valid route through the workflow’s directed graph. The ‘thin’ framework layer will also indicate this failure to the user visually on the workflow desktop. Figure 7-9 shows an input process which should load data from a file but which has not yet been pointed at the required data file.

Chapter 7: Design of iPipeline

Page | 107

Figure 7-9: Visual encoding for incomplete parameter configuration

For incorrectly configured settings panels the ‘thin’ framework overlays an animated

icon on top of the process glyph. Visually this icon is a set of rotating gears that indicate the need for further configuration of the process settings panel.

7.2.3.3 The parameter management sub-system

The primary problem faced by the ‘thin’ framework layer is to find a way to use, transmit and manipulate data without knowing in advance what that data will be. The parameter management sub-system is the ‘thin’ framework layers solution to this problem. Figure 7-10 shows the system’s structure via a UML class diagram.

Page | 108

Figure 7-10: The parameter management sub-system structure

The core functionality of the system is described by two software interfaces. The IParameter interface represents the abstract concept of a name & value pair while the IParameterManager interface represents a collection of IParameter objects. For each of these two interfaces a concrete implementation is provided. These implementations are then used throughout the ‘thin’ framework layer to manage data that cannot be predefined. Examples of such data would include; the problem domain data model, the definition of the dataflow token and delivering algorithm specific data in a generic way. This sub-system therefore see’s use both within the ‘thin’ framework layer to manage data and also in the ‘thick’ problem domain layer.

The core of the system is a name-value pair where a string holds a name associated with a ‘value’. In this case the ‘value’ is any object or datatype. Java generics are used to allow a parameter to accept any ‘value’. The provided concrete implementation class examines the data type assigned on creation of a new Parameter and while it will allow the

Chapter 7: Design of iPipeline

Page | 109

value to change it will now allow a change in the values type after construction. The name component of the name-value pair is always a string. The interface IParameter<E> defines these rules while the Parameter<E> concrete class provides the implementation (see Figure 7-10).

The IParameterManager interface and its concrete implementation ParameterManager provide a means to store and pass parameter objects between software entities. In the ‘thin’ layer knowledge of the meaning of the parameters is not required. Its primary application within the ‘thin’ layer is to exchange values between a process and an associated algorithm specific settings panel. Every process implementation encapsulates a ParameterManager object which is exposed to the attached settings panel. Any settings values can therefore be stored as name-value pairs and accessed by the processes encapsulated algorithm.

The parameter / parameter manager system is also the primary tool for building the dataflow token that will be passed through the workflows directed graph. Its generic data allows structures to be built where the ‘value’ component is itself either another parameter or a list of parameters. The ‘thin’ layer represents the dataflow token via the IProcessingResult interface and this interface gives access to the dataflow token’s data through parameters (see Figure 7-7). In this way the ‘thin’ framework layer can manage the dataflow token without knowledge of its contents or structure