Refactor FERN classes to use SBSCL classes

[hemilpanchiwala]

@draeger, @matthiaskoenig, @zakharc, @shalinshah1993
This issue is created for discussion of making FERN use the classes from SBSCL for interpreting and processing the models to perform the stochastic simulation.

Here's the UML of classes related to the Network interface.

Here, it is seen that there are further classes extending the Network interface performing different things and to note the most important thing that PropensityCalculator class (using the Network) makes use of the MathTree class which creates an instance of SBMLinterpreter (each time it is invoked) for calculating the node values. So, I am quite confused about how to proceed for refactoring FERN to interpret the model using the SBMLinterpreter and pass it to the stochastic simulator as many things are interlinked currently.

In SBSCL, we just have one class SBMLinterpreter which is like access to everything (also we don't have any propensity calculation and other mechanisms which are needed for the stochastic simulations). On the other side in FERN, there is AmountManager for managing amounts, AnnotationManager for storing annotation for the network, its species and reactions, SBMLEventHandlerObserver for events, SBMLPropensityCalculator for calculating propensities and same for other things.

Also, adding FERN's structure for performing stochastic simulation

[zakharc]

@hemilpanchiwala: Thank you for reporting this.

From my perspective, we can make use of some simple patterns to make the simulations of different types more logically isolated from each other, e.g. Composite combined with Chain of Responsibility pattern to let components access global properties through their parent. We could also use Decorator to override the properties on parts of the Composite(s).

However, this might need much more time than we have. I would suggest focusing on the simple things first.

For example:

• Simple refactoring of StochasticTestSuiteTest, SBMLTestSuiteRunner, SBMLTestSuiteTest, SEDMLExecutorTest, etc. (brake down giant test methods to the smaller one, introduce setUp and tearDown methods, proper handling of the exceptions, etc.)
• Provide abstract classes for test suite tests (for common initialization methods and constants)
• Remove constructs like this (JUnit should handle the potential errors of a parametrized test iteration):

  
  boolean isFailedTest = false;
  for (String failedTest : failedTests) {
  isFailedTest = isFailedTest || path.contains(failedTest);
  }

if (isFailedTest) { return; }

- Provide consistent formatting (for the complete library) in a **separate** PR.
- Whatever else you will stumble over while working on the previous ones.