The UEA sRNA workbench is a simple to use, downloadable sRNA software package based on algorithms developed for the original UEA sRNA Toolkit that will perform a complete analysis of single or multiple-sample small RNA datasets from both plants and animals to identify interesting landmarks (such as detection of novel micro RNA sequences) or other tasks such as profiling small RNA expression patterns in genetic data.
The UEA sRNA workbench is available to download at:
Organisation of the code
ExeFilescontains the compiled executables for the main operating systems: OSX, Linux and WIndows.
TutorialDatacontains all files (transcriptomes, genomes, input files) used for the testing of the tools.
datacontains the RFAM libraries
installerscontains a set of wrappers for building the project
srccontains the main Java code and the JUnit testing.
webcontains the web interfaces
masteris only used for hosting tested stable software.
- external users are encouraged to fork from the master branch. If you would like your code to be added to the master branch please issue a pull request. Your code will then be tested by the UEA sRNA Workbench development team and, if suitable, will be included in the main branch.
UEA sRNA Workbench source code is licensed under the MIT (see license file).
example files (transcripts, genomes, input files) which need to be unzipped
The workbench is a maven project. All dependencies should be handled with the POM file as should all build instructions. SQL interactions are handled using the Hibernate system. Data source configurations and any communication with REST services should be done using Spring which is already included in the project. Each new tool should be placed in the package following the convention: uk.ac.uea.cmp.srnaworkbench.tools.newtool Each new tool requires a package for JavaFX code (listed as packageNameFX) and workflow code (packagenameWF)
Adding new tools
Following the Model View Controller (MVC) paradigm
Model: The sRNA Workbench workflow module code
Controller: A special class in the workbench registered as the controller for the FXML file (do not do this in the FXML markup but instead do it programmatically, see other controller classes for examples). In addition to implementing the Initializable interface, ControlledScreen should also be implemented.
Workflow modules can be chained together to form a workflow. Each module consists of two classes that must extend the correct interfaces and abstract classes. A complete new module’s functional code will be one module and one module runner (graphical element is explained above). A complete example of a default (clean) new tool can be found in the docs directory. Modules must be connected together to form a workflow. Workflows always start with either the Database or FileManager module. One builds an on disk or in memory database to store workbench data at run time. One simply serves as the input module for files. Both have the same interface. More information on the workflow modules currently available in the workbench can be found on the workbench website including tutorials on their use.
Modules are chained together by adding them to the workflow manager: First create the entry point to the workflow (either FileManager or Database) and their respective runner code and add them to the workflow manager class for example:
DatabaseWorkflowRunner DB_runner = new DatabaseWorkflowRunner(); WorkflowManager.getInstance().addModule(DB_runner); //set size of file hierarchy web view DatabaseWorkflowModule.getInstance().setFrameSize(visualBounds); DatabaseWorkflowModule.getInstance().setPos(60, (float) visualBounds.getMaxY() / 4.0f); Or using FileManager (no database) WorkflowManager.getInstance().setFirstModuleTitle("FileManager"); //create the file manager module and add it to the workflow FileManagerWorkflowModule fm_module = new FileManagerWorkflowModule("FileManager", visualBounds); fm_module.setPos(60, (float) visualBounds.getMaxY() / 4); FileManagerWorkflowModuleRunner fm_runner = new FileManagerWorkflowModuleRunner(fm_module); WorkflowManager.getInstance().addModule(fm_runner);
Then add any further modules you require and connect them together.
Example of connecting FileManager to Filter tool:
//create the filter module and add it to the workflow Filter2WorkflowModule filter_module = new Filter2WorkflowModule("Filter", visualBounds); filter_module.setPos(260, (float) visualBounds.getMaxY() / 4); Filter2WorkflowModuleRunner filter_runner = new Filter2WorkflowModuleRunner(filter_module); WorkflowManager.getInstance().addModule(filter_runner); //connect the FileManager to the Fitler tool WorkflowManager.getInstance().connectModule2Module("FileManager", "Filter");
This will mean that when the workflow is triggered the connected modules must complete before the module it is connected to will begin. Each completion of a module triggers an “update” event in which the next module on the list is queried to see if all its connections are also complete. Modules can also be connected with SQL queries given as the data transfer. Examples of this can be found in the miRCat preconfigured workflows and the miRPare workflows. When the correct interfaces are implemented the user will need to (among other methods that are related to graphical input) implement a process method. All functional code should go in here, as the method terminates the update method will be triggered in the workflow manager.
Releasing the program
When ready to do a release, package up the software however you are familiar with. You can release a package with just jars or if you are familiar with creation of individual OS packages (.app, .exe etc) then those are fine too.