Java quick: Difference between revisions
(5 intermediate revisions by the same user not shown) | |||
Line 670: | Line 670: | ||
smoothedExperiment = new ExperimentalData1D( experiment.getDescription() + " (smoothed)", | smoothedExperiment = new ExperimentalData1D( experiment.getDescription() + " (smoothed)", | ||
smoothedData, experiment.isBaselineCorrected(), experiment.getTimeResolution()); | smoothedData, experiment.isBaselineCorrected(), experiment.getTimeResolution()); | ||
} | |||
</pre> | </pre> | ||
Line 722: | Line 723: | ||
the curly brackets can be prefixed by a derive class definition starting with a dollar sign | the curly brackets can be prefixed by a derive class definition starting with a dollar sign | ||
and ending with a colon as shown for the summarizing operators above. | and ending with a colon as shown for the summarizing operators above. | ||
= Graphical workflow editor: Grappa = | |||
Most of the time complex data analysis tasks cannot be solved by only applying a | |||
single operator to the data. Rather, selections of various operators need to be | |||
combined into more sophisticated workflows to extract desired result data. | |||
Alida inherently supports the development of such workflows. | |||
Grappa, the Graphical Programming | |||
Editor for Alida, allows for designing and manipulating workflows via graph edit operations, hence, offers | |||
an intuitive interface and large flexibility for developing workflows. | |||
A workflow in Alida is defined as a graph data structure. Each node of the graph represents an Alida operator, while edges between | |||
different nodes encode the flow of data and control. Each node owns a selection of input and output ports which are associated with the | |||
operator's parameters. Consequently, edges are directed, i.e., an edge always | |||
connects an output port of one operator node with an input port of another. Grappa visualizes such workflow graphs and supports manual editing, manipulation, and also workflow execution | |||
and analysis of results. | |||
Grappa can be started using the following command: | |||
<code>java de.unihalle.informatik.Alida.tools.ALDGrappaRunner</code> | |||
Grappa's main window is | |||
basically divided into two sections. On the left, the node selection menu is | |||
visible, while on the right the workbench area is located. | |||
In addition, the window features a menubar for configuring Grappa, loading and | |||
saving workflows, and accessing the online help. At the bottom of the window a | |||
panel displaying status and progress messages is available. | |||
A demo workflow is supplied with the distribution. To load this workflow right click into the workbench area to pop up the | |||
context menue. Select <code>'Load'</code> navigate to the base directory where you unpacked the distribution. | |||
From there navigate further to <code>share/examples/workflows</code> select <code>Demo.awf</code> | |||
and load the sample workflow. This workflow is also described in manual of Alida. | |||
== Operator node selection menu == | |||
In the selection menu on the left of Grappa's main window all Alida operators found in the | |||
classpath upon initialization are listed as potential nodes for Grappa workflows. | |||
In analogy to the graphical user interface | |||
they are arranged in a hierarchical ordering | |||
according to their package structure. The different package subtrees can be | |||
folded and unfolded by double-clicking on a folder's name in the selection tree, | |||
or by single-clicking on the circle displayed left to the folder icon. Above the | |||
tree view an operator filter is available which allows to select operators | |||
according to their names. For filtering, enter a substring into the text | |||
field and press the return key. | |||
Operator nodes can be added to a workflow by double-clicking on the operator | |||
name. A new operator node is then instantiated in the top left corner of the | |||
corresponding workflow tab, i.e., the active workflow (see below). | |||
Alternatively, an operator can be selected by clicking once on its name | |||
and afterwards clicking once on the position in the workflow tab where the new | |||
operator node should be positioned. | |||
== Workbench area == | |||
Workflows can be designed and executed in the workbench area on the right of the main window. It allows for instantiating | |||
multiple workflows in parallel where each workflow is linked to an individual tab of the workbench panel. | |||
A new workflow tab can be added via the item <code>'New'</code> in the context menu of the workbench. | |||
The context menu is displayed upon right-click on an empty location of the workbench area. | |||
Upon selecting the item <code>'New'</code> a new tab is added to the workbench panel. | |||
By default, the name of the new workflow is 'Untitled', but it can easily be | |||
renamed via the corresponding item <code>'Rename'</code> in the context menu. Via this | |||
menu it is also possible to close a workflow tab if no longer required. Note | |||
that its contents are lost if not saved before! The currently selected tab in | |||
the workbench contains the active workflow which can be edited and where | |||
new operator nodes can be added as outlined in the previous subsection. | |||
For each operator selected via the selection menu, a | |||
node in terms of a rectangle is added to the currently active workflow. Above the rectangle | |||
the name of the operator is displayed, while on its left and right side the operator's input and output ports are shown as circles and | |||
squares. Circles are associated with operator parameters of directions <code>IN</code> or <code>OUT</code>, while squares refer to parameters with | |||
direction <code>INOUT</code>. The latter ports are duplicated on both sides of the node. | |||
The colors of the circles indicate their type. Blue circles refer to required parameters, yellow circles are associated with optional | |||
parameters, and red circles are linked to supplemental parameters. To the left and right of the ports, | |||
respectively, the name of the corresponding parameters are written. | |||
Once operator nodes have been added to a workflow, they can easily be dragged | |||
and repositioned as well as resized via intuitive mouse actions. | |||
For each operator node a context menu can be popped up by clicking the node with the right mouse | |||
button. From this menu it is possible to delete the node (item <code>'Remove'</code>), or to configure the | |||
view via the item <code>'Options'</code>. It, e.g., allows to select the set of operator parameter ports | |||
to be shown, i.e. either all parameters or just the subset of non-expert parameters. From the | |||
context menu of a node it is also possible to configure the node (item <code>'Configure'</code>). | |||
On selecting the item for | |||
configuration, a window is displayed which allows to enter parameter values. | |||
The window is automatically generated, i.e., actually the same | |||
mechanisms as for executing operators via the graphical operator runner are applied. Accordingly, | |||
the configuration window is identical to the corresponding operator control | |||
window and shares the same layout, except for the control buttons and the batch | |||
mode tab which are missing. | |||
Operator parameters for a certain node can directly be specified via the | |||
configuration window, they can be loaded from a proper parameter file in XML | |||
format, or they | |||
can be configured by dragging edges between ports of different nodes with the | |||
mouse to propagate output data from one node as input data to another. To add an | |||
edge, move the mouse over an output port of a node until the port is surrounded | |||
by a green square, then press the left mouse button. Subsequently, while keeping | |||
the button pressed, move the mouse to the desired input port of another node. | |||
Once a green rectangle shows up around the target input port, release the | |||
button. Note that on dragging edges Grappa performs type and validity checks. | |||
Only ports being associated with compatible parameter data types can be | |||
linked to each other. Two parameter data types are compatible if they are | |||
either equal, the target data type is a super class of the source data type, or | |||
if Alida has access to a converter allowing to transform the source data type | |||
into the target type. Also | |||
edges are forbidden that would induce cycles into the workflow graph. | |||
Nodes in a workflow can have different states indicated by the color of their border. | |||
Red framed nodes are not ready for execution, i.e., their configuration is not | |||
complete. If a node is readily configured and can directly be executed, its | |||
border has a yellow color, while nodes that are configured, however, require | |||
additional input data from preceeding operator nodes have an orange color. | |||
Prior to executing these orange nodes it is, thus, necessary to execute the | |||
preceeding nodes first. | |||
Note that Grappa takes care of such dependencies, i.e., automatically executes | |||
nodes first from which result data is required for proper workflow or node | |||
execution. The state of a node is updated by Grappa in real-time, i.e., each | |||
change in its configuration directly invokes internal checkings and may result in a change of the node's color. | |||
Grappa offers various modes for executing a | |||
complete workflow or parts of it. | |||
From the context menu of the workbench the item | |||
<code>'Run'</code> is available which executes the complete workflow, i.e., all nodes | |||
currently present on the tab. From the context menu of a single node and its <code>'Run ...'</code> item also the whole workflow can be executed (item <code>'Workflow'</code>). | |||
Alternatively, via the item <code>'Nodes from here'</code> it is possible to only execute the nodes of the workflow subgraph for which the | |||
current node is the root (of course considering required dependencies). Finally, the item <code>'Node'</code> allows for running the workflow | |||
until the node in question. As mentioned before, Grappa automatically takes care | |||
of resolving dependencies, i.e., upon executing a node all nodes having a yellow | |||
or orange border and being predecessors of the node in question are also executed. Note that the execution of a workflow will fail if one of the nodes is still colored red, or if a node does not produce proper output data required by others. | |||
After successful execution of the workflow or a subset of nodes, the colors of | |||
the corresponding nodes change to green indicating that result data are | |||
available. For all terminal nodes having no successor the result frames are | |||
automatically opened. | |||
For all other nodes the result data can graphically be examined via the nodes' | |||
context menus from which the result windows can manually be opened. | |||
Once a node has been executed and is colored in green, it is not possible to | |||
re-execute the node until its configuration, or at least the configuration of | |||
one of its preceeding nodes, was changed. | |||
== Menubar == | |||
The Grappa main window features a menubar offering quick | |||
access to the basic functions of Grappa and some additional convenience functionality simplifying | |||
the work with the editor. | |||
Via the menu item <code>'File'</code> workflows can be saved to and read from | |||
disk. By saving a workflow currently two files are written to disk, one containing the information | |||
about the nodes and their configuration, and one storing graphical information | |||
regarding the current workflow layout. Both are required to load a workflow | |||
again. The first one has the extension <code>'.awf'</code>, the latter one the | |||
extension <code>'.awf.gui'</code>. | |||
Via the menu item <code>'Workflow'</code> new workflows can be added and existing ones be renamed, | |||
closed, executed or interrupted. | |||
Alida supports two categories of | |||
operators, i.e. operators mainly dedicated to direct application by non-expert users | |||
and operators for special tasks and expert usage. Via the item <code>'Options'</code> the menubar allows | |||
to switch the view in the selection menu between both categories. Also progress messages triggered by the | |||
operator node during execution and optionally shown in the status panel can be enabled or | |||
disabled via this menu. Finally, the menu item <code>'Help'</code> grants access to Alida's online help system | |||
where information about its functionality and descriptions of the operators can be found. |
Latest revision as of 17:16, 17 March 2016
Here we introduce Alida's operator concept with some code snippets of ALDOperator
and sub-classed demo operators.
we focus on Alida's capabilities to automatically generate user interfaces.
First operator
As a first example of an Alida operator we implement the row or column wise
sum for a 2D array of Doubles.
The class MatrixSum
extending ALDOperator
features three member variables
holding the input 2D array, an enum to indicate the mode of summation (ROW
or COLUMN
), and
an 1D array of the sums to be computed and returned by the operator.
Alida requires only to annotate these members with the @Parameter annotation
which declares
- the direction (
IN
,OUT
,INOUT
), - whether the parameter is required,
- an optional textual description,
- and a label used, e.g. in the graphical user interface automatically generated
to execute the operator.
It is important to add a public standard constructor (without arguments)
to be able to use Java's reflection mechanism.
Finally, the abstract method operate()
of ALDOperator
has to be overridden
implementing the functionality of the operator.
@ALDAOperator(genericExecutionMode=ALDAOperator.ExecutionMode.ALL, level=ALDAOperator.Level.APPLICATION) public class MatrixSum extends ALDOperator { /** Choose row or colum wise sum */ public static enum SummarizeMode { /** row wise */ ROW, /** column wise */ COLUMN } /** * Input matrix */ @Parameter( label= "Input matrix", required = true, direction = Parameter.Direction.IN, description = "Input matrix.") private Double[][] matrix; /** * Mode of summarizing */ @Parameter( label= "Summarize mode", required = true, direction = Parameter.Direction.IN, description = "Sum over columns or rows?") private SummarizeMode summarizeMode = SummarizeMode.ROW; /** * 1D Array of sums. */ @Parameter( label= "sums", direction = Parameter.Direction.OUT, description = "Row or column wise sums.") private Double[] sums = null; /** * Default constructor. * @throws ALDOperatorException */ public MatrixSum() throws ALDOperatorException { } /** * Constructor. * * @param matrix Input matrix. * @throws ALDOperatorException */ public MatrixSum(Double[] [] matrix) throws ALDOperatorException { this.matrix = matrix; } @Override protected void operate() { if ( matrix == null ) sums = null; // calculate sums if ( summarizeMode == SummarizeMode.ROW ) { sums = new Double[matrix.length]; for ( int row = 0 ; row < matrix.length ; row++ ) { sums[row] = 0.0; for ( int col = 0 ; col < matrix[0].length ; col++ ) sums[row] += matrix[row][col]; } } else { sums = new Double[matrix[0].length]; for ( int col = 0 ; col < matrix[0].length ; col++ ) { sums[col] = 0.0; for ( int row = 0 ; row < matrix.length ; row++ ) sums[col] += matrix[row][col]; } } }
These are the basic requirements for the operator to be used on the programming level. An example of this use is included in the example in the next section.
If we further annotate the class with
@ALDAOperator(genericExecutionMode=ALDAOperator.ExecutionMode.ALL)
this is all needed to also facilitate
execution of this operator via a graphical and a command line user interface
automatically generated by Alida.
(Setting level=ALDAOperator.Level.APPLICATION
declares this operator an application
which is used in the GUI to control display of available operators.)
Invocation via a graphical user interface
Alida comes with one single application to execute Alida operators with a automatically generated graphical user interface which may be started from command line by
java de.unihalle.informatik.Alida.tools.ALDOpRunnerGUI
This will pop up a window to choose an operator to execute.
Arranged according to the package structure all operators allows to be executed
via the graphical user interface according to their genericExecutionMode
are displayed.
Initially packages are unfolded up to a predefined depth.
Unfold the demo package, select MatrixSum
, and choose the "Configure Operator" button.
This will pop up another window which allows you to configure the input parameters
of the operator.
Important note: After finishing to input the data matrix entering the final matrix elements
you have to select a previous matrix element due to subtle AWT details.
For the enumeration to select the mode Alida has automatically generated
a combo box to allow convenient selections.
If you are finished with the parameter configuration you want to invoke the operator
using the run button.
On completion of MatrixSum
the interface will pop up the result window which allows you
to inspect the outcome of the operation.
Invocation via command line
The command line user interface of Alida allows to invoke all Alida operator properly annotated to allows generic execution.
You may invoke the matrix summation operator by
java de.unihalle.informatik.Alida.tools.ALDOpRunner MatrixSum matrix='[[1,2,3],[4,5,6]]' sums=-
which returns as result on standard output
sums = [6.0,15.0]
Parameter values are specified as name=value pairs. Alida's syntax for 2D array should be self-explanatory from this example. As the mode of summation is not supplied as a parameter its default is used
Note, the command
java de.unihalle.informatik.Alida.tools.ALDOpRunner MatrixSum matrix='[[1,2,3],[4,5,6]]'
will return no output as the command line user interface returns only output parameters requested.
The enumeration defined in MatrixSum
is supported by the
user interface without further action required as shown in the next example.
This also demonstrates redirection of output
to a file, sums.out in this case.
java de.unihalle.informatik.Alida.tools.ALDOpRunner MatrixSum matrix='[[1,2,3],[4,5,6]]' summarizeMode=COLUMN sums=@sums.out+
Input can be read from file as well:
java de.unihalle.informatik.Alida.tools.ALDOpRunner MatrixSum matrix=@data sums=-+
where the file data contains the string defining the matrix, e.g., [[1,2,3],[4,5,6]]
Adding more features to an operator
We now generalize this example to realize not only summation over rows or columns, but arbitrary summarizing operations. This shows Alida's feature to allow an operator as parameter of another operator.
Implementation
First we generalize ALDArraySum
to the operator ApplyToMatrix
which also takes a 2D array and an enum indicating the mode of marginalization (ROW
or COLUMN
).
It takes an additional input parameter which specifies the operation to be applied on each
row or column.
This parameter is itself an Alida operator and of type ALDSummarizeArrayOp
which is implemented as an abstract class.
This abstract operator defines a summarizing operator
which takes a 1D array as input and returns a summarizing scalar.
As this is an abstract class there is no need to override the operate()
method, however some getter and setter methods are provided.
@Parameter( label= "Input 1D array", required = true, direction = Parameter.Direction.IN, description = "Input array (1D).") protected Double[] data; /** * Summarizing scalar */ @Parameter( label= "Summarizing scalar", direction = Parameter.Direction.OUT, description = "Summarizing scalar of the 1D arra") protected Double summary = null; /** * Default constructor. * @throws ALDOperatorException */ public ALDSummarizeArrayOp() throws ALDOperatorException { } /** * Returns the 1D array * @return data array */ public Double[] getData() { return this.data; } /** * Sets the 1D array * @param data */ public void setData( Double[] data) { this.data = data; }
Now we add concrete examples of such a summarizing operation, in this case
summation (ALDArraySum
), to return the mean (ALDArrayMean
), and the minimum (ALDArrayMin
).
Each implements the operate()
method and has to supply a standard constructor.
In this example we add another constructor for convenience.
This operators are declared as operators on the standard in contrast to
application level, as they are not expected to be invoked as an application.
However, setting the level to standard in the menu of the graphical user interface
stills allows their execution.
When extending the abstract super class it is necessary to annotate the
class with @ALDDerivedClass
in order to allow Alida's dataIO mechanism to find the derived class
in the automatically generated user interface.
This holds for other parameter types as well.
More specifically, if an instance of a class is to be supplied in an automatically
generated user interface as a value for a parameter of one of its super classes,
Alida requires the annotation @ALDDerivedClass
.
@ALDDerivedClass @ALDAOperator(genericExecutionMode=ALDAOperator.ExecutionMode.ALL, level=ALDAOperator.Level.STANDARD) public class ALDArraySum extends ALDSummarizeArrayOp { @Override protected void operate() { summary = 0.0; for ( int i = 0 ; i < data.length ; i++ ) summary += data[i]; } /** * Default constructor. * @throws ALDOperatorException */ public ALDArraySum() throws ALDOperatorException { }
Now we are ready to implement
the ApplyToMatrix
operator, which also demonstrates supplemental parameters.
This supplementals, e.g., control debugging output or returning of intermediate results.
For demo purposes we declare a supplemental input parameter returnElapsedTime
.
If it is set to true the operator will return the elapsed time in a second
supplemental parameter with direction output.
Again, the operation is implemented in the operate()
method and the remainder of the
class supplies getter and setter methods for convenience.
The operate()
method give also an example of the invocation of an operator on the
programming level.
In this case, an instance of the operator is already passed as a parameter.
Its parameters are set, in this case each 1D array to be summarized in turn.
Upon return from the method runOp()
the results may be retrieved from the operator object,
in this example with the getSummary()
method.
Besides getter and setter methods as implemented in each operator
Alida provides also a generic get and set methods applicable to
all parameters of an operator.
Note, that the operator is not invoked by its operate()
method, but via
the runOp()
method implemented the base class ALDOperator
.
This methods validates the parameters before invocation of operate()
.
Furthermore, it take all necessary measures for Alida's processing
history which automatically logs
all manipulative actions on the data and corresponding parameter settings.
@ALDAOperator(genericExecutionMode=ALDAOperator.ExecutionMode.ALL, level=ALDAOperator.Level.APPLICATION) public class ApplyToMatrix extends ALDOperator { /** Choose row or colum wise sum */ public static enum SummarizeMode { /** row wise */ ROW, /** column wise */ COLUMN } /** * Input matrix */ @Parameter( label= "Input matrix", required = true, direction = Parameter.Direction.IN, description = "Input matrix.") private Double[][] matrix; /** * Mode of summarizing */ @Parameter( label= "Summarize mode", required = true, direction = Parameter.Direction.IN, description = "Sum over columns or rows.") private SummarizeMode summarizeMode = SummarizeMode.ROW; /** * Summarizing opererator */ @Parameter( label= "Summarizing operator", required = true, direction = Parameter.Direction.IN, description = "Specifies the summarizing operation to apply") private ALDSummarizeArrayOp summarizeOp; /** * 1D Array of summaries. */ @Parameter( label= "summaries", direction = Parameter.Direction.OUT, description = "Row or column wise summaries") private Double[] summaries = null; /** * Supplemental to request elapsed time to be returned */ @Parameter( label= "Return elapsed time", direction = Parameter.Direction.IN, description = "Request elapsed time consumed to be returned", supplemental=true) private boolean returnElapsedTime = false; /** * Elpased time */ @Parameter( label= "Elapsed time", direction = Parameter.Direction.OUT, description = "Elapsed time of operation in milliseconds", supplemental=true) private long elapsedTime; /** * Default constructor. * @throws ALDOperatorException */ public ApplyToMatrix() throws ALDOperatorException { } /** * Constructor. * * @param matrix Input matrix. * @throws ALDOperatorException */ public ApplyToMatrix(Double[] [] matrix) throws ALDOperatorException { this.matrix = matrix; } @Override protected void operate() throws ALDOperatorException,ALDProcessingDAGException { if ( returnElapsedTime ) elapsedTime = System.currentTimeMillis(); if ( matrix == null ) summaries = null; // calculate summaries if ( summarizeMode == SummarizeMode.ROW ) { summaries = new Double[matrix.length]; for ( int row = 0 ; row < matrix.length ; row++ ) { summarizeOp.setData(matrix[row]); summarizeOp.runOp(); summaries[row] = summarizeOp.getSummary(); } } else { summaries = new Double[matrix[0].length]; Double[] tmp = new Double[matrix.length]; for ( int col = 0 ; col < matrix[0].length ; col++ ) { for ( int row = 0 ; row < matrix.length ; row++ ) tmp[row] = matrix[row][col]; summarizeOp.setData(tmp); summarizeOp.runOp(); summaries[col] = summarizeOp.getSummary(); } } if ( returnElapsedTime ) elapsedTime = System.currentTimeMillis() - elapsedTime; } // ============================================================== // Getter and setter methods /** Get value of returnElapsedTime. * Explanation: Request elapsed time consumed to be returned. * @return value of returnElapsedTime */ public boolean getReturnElapsedTime(){ return returnElapsedTime; } /** Set value of returnElapsedTime. * Explanation: Request elapsed time consumed to be returned. * @param value New value of returnElapsedTime */ public void setReturnElapsedTime( boolean value){ this.returnElapsedTime = value; }
Invocation via a graphical user interface
If the graphical interface is still running just select our new operator
and begin to configure it.
For the parameter summarizing operator you have a choice of all operators extending
the abstract operator ALDSummarizeArrayOp
.
All which is necessary on the implementation side is proper annotation of the extending
classes with @ALDDerivedClass
.
As the selected operator may have its own parameters you may want to configure it.
In our example this is not necessary as the input array is, of course, supplied
by the ApplyToMatrix
operator.
Do not forget to input your data before hitting the run button.
After return, again a result window give you the results of the operation.
Note, if you did not tick Return elapsed time" this window will show zero
for the time elapsed as the operator has not been request to stop the time.
Invocation via command line
When invoking the ApplyToMatrix
operator from command line
we have to handle derived classes as value for parameters.
In the graphical user interface Alida features a combo box where
we may choose from.
In the command line interface Alida allows to prefix the value of a parameter
with a derived class to be passed to the operator.
This is necessary as Alida as, of course, no way to itself
decide if and which derived class is to be used.
Alida's syntax is to enclose the class name in a dollar sign and a colon.
As evident in the following example, abbreviations are of the fully
qualified class name are accepted as long as they are unambiguous.
java de.unihalle.informatik.Alida.tools.ALDOpRunner Apply \ matrix='[[1,2,3],[4,5,6]]' \ summarizeMode=ROW \ summarizeOp='<math>ALDArrayMean:{}' \ summaries=-
results in
summaries = [2.0,5.0]
ALDOpRunner
may be persuaded to show all operators derived from ALDSummarizeArrayOp
and known within the user interface if we enter an invalid class name:
java de.unihalle.informatik.Alida.tools.ALDOpRunner \ Apply matrix='[[1,2,3],[4,5,6]]' \ summarizeMode=ROW summarizeOp='</math>dd:{}' \ summaries=-
yields
ALDStandardizedDataIOCmdline::readData found 0 derived classes matching <dd> derived classes available: de.unihalle.informatik.Alida.demo.ALDArrayMean de.unihalle.informatik.Alida.demo.ALDArrayMin de.unihalle.informatik.Alida.demo.ALDArraySum ERROR: reading parameter <summarizeOp> returns null
Supplemental parameters are handled like other parameters
java de.unihalle.informatik.Alida.tools.ALDOpRunner Apply \ matrix='[[1,2,3],[4,5,6]]' \ summarizeMode=COLUMN \ summarizeOp='<math>ALDArrayMin:{}' \ summaries=- \ returnElapsedTime=true \ elapsedTime=-
gives
summaries = [1.0,2.0,3.0] elapsedTime = 4
Adding more data types as parameters
Alida provides automatic IO of primitive data types, enumerations, arrays, collections,
and operators.
In addition so called parameterized classes are supported.
Any Java class may be declared to be a parameterized class in Alida
by annotating the class @ALDParametrizedClass
as shown in the
class ExperimentalData1D
.
All member variables to be known to and handled by Alida's user interface
simply need to be annotated with @ALDClassParameter
.
Here we implement a toy version of experimental data ExperimentalData1D
.
A complete experiment contains
data of a time series of measurements of variable length.
Additional information is a descriptive string, the time resolution in milliseconds,
and whether baseline correction has been applied.
The class is annotated by @ALDParametrizedClass
, and
and all members to be handle in Alida'a user interfaces are
to be annotated with @ALDParametrizedClass
.
The label field has the same semantics as for parameters of operators.
These annotations are the only implementational overhead
to allow Alida to automatically generate user interfaces
where the parameterized class acts as a parameter.
@ALDParametrizedClass public class ExperimentalData1D extends ALDData { /** Description */ @ALDClassParameter(label="description", dataIOOrder = 1) private String description = null; /** The data */ @ALDClassParameter(label="data", dataIOOrder = 2) private Double[] data = null; /** Are the data baseline corrected? */ @ALDClassParameter(label="Baseline corrected", dataIOOrder = 3) private boolean baselineCorrected = false; @ALDClassParameter(label="Time resolution in milliseconds", dataIOOrder = 4) private Float timeResolution = Float.NaN; /** * Standard constructor is required */ public ExperimentalData1D() { } /** Constructor for an experiment. * Baseline correction is assumed to be false and nothung known about * the time resolution. * * @param description a textual description of the experiment * @param data measurements */ public ExperimentalData1D( String description, Double[] data) { this( description, data, false, Float.NaN); }
This is shown below for a simple normalizing operator SmoothData1D
which takes experimental data as input an returns a new instance
of ExperimentalData
which contains smoothed data.
@ALDDerivedClass @ALDAOperator(genericExecutionMode=ALDAOperator.ExecutionMode.ALL, level=ALDAOperator.Level.APPLICATION) public class SmoothData1D extends ALDOperator { public enum SmoothingMethod { MEDIAN, MEAN, GAUSSIAN } /** 1D Experiment */ @Parameter( label= "1D Experiment", required = true, direction = Parameter.Direction.IN, description = "1D Experiment", dataIOOrder = 1) protected ExperimentalData1D experiment; /** Smoothing method */ @Parameter( label = "Smoothing method", required = true, direction = Parameter.Direction.IN, callback = "smoothingMethodChanged", description = "Smoothing method", paramModificationMode = ParameterModificationMode.MODIFIES_INTERFACE, dataIOOrder = 2) SmoothingMethod smoothingMethod = SmoothingMethod.MEDIAN; /** Window width */ @Parameter( label = "Window width", required = true, direction = Parameter.Direction.IN, description = "Window width (should be uneven)", dataIOOrder = 3) Integer width = 3; /** Standard deviation of Gaussian */ @Parameter( label = "Standdard deviation of Gaussian", required = true, direction = Parameter.Direction.IN, description = "Standdard deviation of Gaussian", dataIOOrder = 3) Float sigma = 1.0F; /** Smoothed 1D Experiment */ @Parameter( label= "Smothed 1D Experiment", direction = Parameter.Direction.OUT, description = "Smothed1D Experiment", dataIOOrder = 1) protected ExperimentalData1D smoothedExperiment; /** * Default constructor. * @throws ALDOperatorException */ public SmoothData1D() throws ALDOperatorException { // necessary handle dynamic parameters correctly smoothingMethodChanged(); } @Override protected void operate() { this.fireOperatorExecutionProgressEvent( new ALDOperatorExecutionProgressEvent(this, "Starting to smooth 1D Data...")); Double[] smoothedData; if ( smoothingMethod == SmoothingMethod.MEDIAN) { smoothedData = median( experiment.getData(), this.width); } else { smoothedData = smoothByConvolution(); } smoothedExperiment = new ExperimentalData1D( experiment.getDescription() + " (smoothed)", smoothedData, experiment.isBaselineCorrected(), experiment.getTimeResolution()); }
This mechanism applies in a recursive fashion, i.e. a parameterized class may
(recursively) contain a member variable which itself is a parametrized class.
Likewise, an operator acting as a parameter of another operator
may in turn have a parameter of type ALDOperator
.
Invocation via a graphical user interface
Invoking and configuring SmoothData1D
from the graphical user interface
shows as the only required parameter the experimental data.
This parameterized class can be configured in a separate window
very similar to to configuration of operators.
Likewise the resulting normalized experimental data
may be inspected in their own window.
Obviously this is a toy example, as we would not expect the measurements to
be entered manually, but rather stored and read from file in a specialized format.
This is one of the rare cases where
custom data IO provider need to be implemented, in this
case for ExperimentalData1D
.
Invocation via command line
Again, invocation from command line is provided by Alida in an automatic way with no further implementational overhead. The syntax for parameterized classes es a comma separated list of name=value pairs enclosed in curly brackets where name refers to annotated member variables of the parameterized class.
java de.unihalle.informatik.Alida.tools.ALDOpRunner SmoothData1D \ experiment='{ baselineCorrected=false , \ description="my experiment" , \ data=[1.0,2.0,2.2,3.3,2.0,1.0,1.0,1.0,1.0,2.0,3.3,2.0] }' \ smoothingMethod=GAUSSIAN \ smoothedExperiment=-
yields
smoothedExperiment = { baselineCorrected=false , data=[1.28,1.85,2.37,2.76,2.05,1.23,1.01,1.01,1.23,2.05,2.73,2.35] , timeResolution=NaN , description="my experiment" (smoothed) }
If a class derived from ExperimentalData1D
was to be supplied to the operator,
the curly brackets can be prefixed by a derive class definition starting with a dollar sign
and ending with a colon as shown for the summarizing operators above.
Graphical workflow editor: Grappa
Most of the time complex data analysis tasks cannot be solved by only applying a single operator to the data. Rather, selections of various operators need to be combined into more sophisticated workflows to extract desired result data. Alida inherently supports the development of such workflows. Grappa, the Graphical Programming Editor for Alida, allows for designing and manipulating workflows via graph edit operations, hence, offers an intuitive interface and large flexibility for developing workflows.
A workflow in Alida is defined as a graph data structure. Each node of the graph represents an Alida operator, while edges between different nodes encode the flow of data and control. Each node owns a selection of input and output ports which are associated with the operator's parameters. Consequently, edges are directed, i.e., an edge always connects an output port of one operator node with an input port of another. Grappa visualizes such workflow graphs and supports manual editing, manipulation, and also workflow execution and analysis of results.
Grappa can be started using the following command:
java de.unihalle.informatik.Alida.tools.ALDGrappaRunner
Grappa's main window is basically divided into two sections. On the left, the node selection menu is visible, while on the right the workbench area is located. In addition, the window features a menubar for configuring Grappa, loading and saving workflows, and accessing the online help. At the bottom of the window a panel displaying status and progress messages is available.
A demo workflow is supplied with the distribution. To load this workflow right click into the workbench area to pop up the
context menue. Select 'Load'
navigate to the base directory where you unpacked the distribution.
From there navigate further to share/examples/workflows
select Demo.awf
and load the sample workflow. This workflow is also described in manual of Alida.
In the selection menu on the left of Grappa's main window all Alida operators found in the classpath upon initialization are listed as potential nodes for Grappa workflows. In analogy to the graphical user interface they are arranged in a hierarchical ordering according to their package structure. The different package subtrees can be folded and unfolded by double-clicking on a folder's name in the selection tree, or by single-clicking on the circle displayed left to the folder icon. Above the tree view an operator filter is available which allows to select operators according to their names. For filtering, enter a substring into the text field and press the return key. Operator nodes can be added to a workflow by double-clicking on the operator name. A new operator node is then instantiated in the top left corner of the corresponding workflow tab, i.e., the active workflow (see below). Alternatively, an operator can be selected by clicking once on its name and afterwards clicking once on the position in the workflow tab where the new operator node should be positioned.
Workbench area
Workflows can be designed and executed in the workbench area on the right of the main window. It allows for instantiating
multiple workflows in parallel where each workflow is linked to an individual tab of the workbench panel.
A new workflow tab can be added via the item 'New'
in the context menu of the workbench.
The context menu is displayed upon right-click on an empty location of the workbench area.
Upon selecting the item 'New'
a new tab is added to the workbench panel.
By default, the name of the new workflow is 'Untitled', but it can easily be
renamed via the corresponding item 'Rename'
in the context menu. Via this
menu it is also possible to close a workflow tab if no longer required. Note
that its contents are lost if not saved before! The currently selected tab in
the workbench contains the active workflow which can be edited and where
new operator nodes can be added as outlined in the previous subsection.
For each operator selected via the selection menu, a
node in terms of a rectangle is added to the currently active workflow. Above the rectangle
the name of the operator is displayed, while on its left and right side the operator's input and output ports are shown as circles and
squares. Circles are associated with operator parameters of directions IN
or OUT
, while squares refer to parameters with
direction INOUT
. The latter ports are duplicated on both sides of the node.
The colors of the circles indicate their type. Blue circles refer to required parameters, yellow circles are associated with optional
parameters, and red circles are linked to supplemental parameters. To the left and right of the ports,
respectively, the name of the corresponding parameters are written.
Once operator nodes have been added to a workflow, they can easily be dragged
and repositioned as well as resized via intuitive mouse actions.
For each operator node a context menu can be popped up by clicking the node with the right mouse
button. From this menu it is possible to delete the node (item 'Remove'
), or to configure the
view via the item 'Options'
. It, e.g., allows to select the set of operator parameter ports
to be shown, i.e. either all parameters or just the subset of non-expert parameters. From the
context menu of a node it is also possible to configure the node (item 'Configure'
).
On selecting the item for configuration, a window is displayed which allows to enter parameter values. The window is automatically generated, i.e., actually the same mechanisms as for executing operators via the graphical operator runner are applied. Accordingly, the configuration window is identical to the corresponding operator control window and shares the same layout, except for the control buttons and the batch mode tab which are missing.
Operator parameters for a certain node can directly be specified via the configuration window, they can be loaded from a proper parameter file in XML format, or they can be configured by dragging edges between ports of different nodes with the mouse to propagate output data from one node as input data to another. To add an edge, move the mouse over an output port of a node until the port is surrounded by a green square, then press the left mouse button. Subsequently, while keeping the button pressed, move the mouse to the desired input port of another node. Once a green rectangle shows up around the target input port, release the button. Note that on dragging edges Grappa performs type and validity checks. Only ports being associated with compatible parameter data types can be linked to each other. Two parameter data types are compatible if they are either equal, the target data type is a super class of the source data type, or if Alida has access to a converter allowing to transform the source data type into the target type. Also edges are forbidden that would induce cycles into the workflow graph.
Nodes in a workflow can have different states indicated by the color of their border. Red framed nodes are not ready for execution, i.e., their configuration is not complete. If a node is readily configured and can directly be executed, its border has a yellow color, while nodes that are configured, however, require additional input data from preceeding operator nodes have an orange color. Prior to executing these orange nodes it is, thus, necessary to execute the preceeding nodes first. Note that Grappa takes care of such dependencies, i.e., automatically executes nodes first from which result data is required for proper workflow or node execution. The state of a node is updated by Grappa in real-time, i.e., each change in its configuration directly invokes internal checkings and may result in a change of the node's color.
Grappa offers various modes for executing a
complete workflow or parts of it.
From the context menu of the workbench the item
'Run'
is available which executes the complete workflow, i.e., all nodes
currently present on the tab. From the context menu of a single node and its 'Run ...'
item also the whole workflow can be executed (item 'Workflow'
).
Alternatively, via the item 'Nodes from here'
it is possible to only execute the nodes of the workflow subgraph for which the
current node is the root (of course considering required dependencies). Finally, the item 'Node'
allows for running the workflow
until the node in question. As mentioned before, Grappa automatically takes care
of resolving dependencies, i.e., upon executing a node all nodes having a yellow
or orange border and being predecessors of the node in question are also executed. Note that the execution of a workflow will fail if one of the nodes is still colored red, or if a node does not produce proper output data required by others.
After successful execution of the workflow or a subset of nodes, the colors of the corresponding nodes change to green indicating that result data are available. For all terminal nodes having no successor the result frames are automatically opened. For all other nodes the result data can graphically be examined via the nodes' context menus from which the result windows can manually be opened. Once a node has been executed and is colored in green, it is not possible to re-execute the node until its configuration, or at least the configuration of one of its preceeding nodes, was changed.
Menubar
The Grappa main window features a menubar offering quick access to the basic functions of Grappa and some additional convenience functionality simplifying the work with the editor.
Via the menu item 'File'
workflows can be saved to and read from
disk. By saving a workflow currently two files are written to disk, one containing the information
about the nodes and their configuration, and one storing graphical information
regarding the current workflow layout. Both are required to load a workflow
again. The first one has the extension '.awf'
, the latter one the
extension '.awf.gui'
.
Via the menu item 'Workflow'
new workflows can be added and existing ones be renamed,
closed, executed or interrupted.
Alida supports two categories of
operators, i.e. operators mainly dedicated to direct application by non-expert users
and operators for special tasks and expert usage. Via the item 'Options'
the menubar allows
to switch the view in the selection menu between both categories. Also progress messages triggered by the
operator node during execution and optionally shown in the status panel can be enabled or
disabled via this menu. Finally, the menu item 'Help'
grants access to Alida's online help system
where information about its functionality and descriptions of the operators can be found.