GUI requirements

This page is a list of requirements for a GUI for MOCCASIN.

Initial functionality

• Basic application menubar featuring the name of the application (MOCCASIN?), A "File" menu and an "Edit" menu. If there is time, there should be "Help" menubar item too. [Done]

• Basic application window split into two halves: an upper half and a lower half. In-between the two halves there is a progress bar, and buttons with options. [Done]

• Sequence of events during user interaction:

  • Input filename (Browse/enter path to matlab script)
  • Display the file the user selected in the upper half of the window.
  • Select options (check boxes would seem most appropriate)
    1. Output variables as parameters OR species (default).
    2. Output SBML with rate rules (default) OR SBML with reactions.
  • Run button
  • Save file (browse/enter xml filename). If user quits without saving, show them a warning. [Done]

Notes

To start with this could literal be two fields for filenames; two checkboxes and a Run button. Being able to browse for input would be the first step; extending this to being able to enter the input as text would be the next improvement. [Done]

First advanced functionality

• When the conversion has happened; having the xml pop up as a text window which the user can choose whether to save or not rather than always saving a file. [Done]

• There are further options that would display parsing output - we could have this as an option and scroll the output past people so they see we are doing something.

• Progress indicator of some sort is always helpful; since once we get bigger files we may well have a time delay between pressing Run and getting output. This could be just scrolling the output past.

Future functionality

• Models may well have variables that should be interpreted as species that take part in reactions and others that are species that don't take part in reactions (boundaryCondition in SBML) and others that are parameters since they do not represent a biochemical species. This is information that we would probably need the user to actually tell us - as it is in no way obvious from ode equations. I would envisage that our first window has an "Advanced features" button which can be selected once the input model is available. This would then bring up another window that listed the variables found within the model and provided the user with the opportunity to say - this should be a species, this should be a parameter, this should be a compartment. Of course we would need the functionality within our conversion to distinguish this but it would the ultimate goal. Note: SBToolbox2 does this i.e. asks users to specify the SBML class of each of the variables.

• Models may be spread over multiple files. We should bear in mind the possibility that a user would supply a model by specifying a main file and a directory containing other files. This could be extended to a situation where we parse the given files and then report unidentified functions and ask the user to point to their location.

• Other advanced features that would require the user to decide things (once we have the functionality to do this would be

  1. do you want initial assignments or shall we calculate them for you
  2. do you want functionDefinitions
  3. the can of worms that is units (would go with asking the user to specify when being asked to identify species/parameters etc)