\section{Future development}
\label{development}

The following subsections describe features that could be added to the software and define which parts of the program they would affect. The features which could be implemented easily are described at first.

\subsection{Random update strategy}

Requirement S7

The only change necessary would be to add the method generateUpdateOne to FortranMain. Other classes and methods would remain unchanged. (For example the classes Definitions, Acceptation and the Parser already support the random update strategy.)

The prototypes have the subroutine update\_one implemented so that they could be used when implementing the method generateUpdateOne.

This feature was designed but not implemented.

\subsection{More distributions}

Requirement M10

More distributions could be added by modifying the Fortran module user\_dist.f90. No changes to the Generator would be needed. Some subroutines are trivial to implement by using existing NAG subroutines and functions while other subroutines are more difficult.

\subsection{Making the generating quicker}

If some input files (for example data) are not changed since the previous run the generator wouldn't have to check their validity. There are multiple ways to implement this feature.

\subsection{Defining properties for single parameters}

The format of the input files should be changed so that it would be possible to define a proposal distribution or an update count for a single parameter instead of parameter groups. The Parser should be changed accordingly. The data structures and Generator classes already support these features.

\subsection{The Gibbs algorithm}

Requirement S2

When using the Gibbs algorithm for a parameter its proposal distribution may contain references to other variables. The proposed value is accepted without calculating its likelihood.

Adding the Gibbs strategy would change the structure of the Fortran program. It would be impossible to generate new value proposals in advance, since the proposal distributions would change during the simulation.

The module ``proposal'' would no longer be able to generate proposals for all the parameters. The parameters with a static proposal strategy could utilize it as before. New values for other parameters should be generated in the subroutine update\_all (or update\_one if the random update strategy is used), since it would be too inefficient to add perform a subroutine call every time a proposal is needed. The acceptation procedures would also change a little.

The data structures Distribution and Variable are flexible enough to allow the description of non-static proposal distributions. 

The Parser would have to be changed to allow variable references when defining proposal distributions.

The classes Acceptation and FortranMain would have to be changed to generate code which updates also the parameters with the Gibbs algorithm.

The class Variable already has a field for algorithm choice.

\subsection{Parameters of proposal distribution}

Requirement S16

The parameters of proposal distribution could depend on the parameter's current value when using the random walk proposal strategy.

The implementation should be straightforward if the Gibbs algorithm is supported since the parameter can be a parameter of its own proposal distribution.

\subsection{Parameter blocks}

Requirements S6, S8

This feature was not designed. It would be necessary to introduce a data structure describing a block and changes to almost every class would be needed.

\subsection{Soft stop}

Requirement S15

By pressing a defined soft-stop key the user could be able to interrupt the simulation so that the output files would be at consistent state (for example with only fully executed iterations and the last values file existing).

The soft-stop feature could be added by editing the method generateMain in class FortranMain. It hasn't been determined if the soft stop is possible to be implemented in Fortran (that is, if it is possible to determine if a certain key is pressed).

\subsection{Graphical user interface}

Requirement N4

A graphical user interface for drawing the models and defining other parameters could be added to the generator.

\subsection{Reporting semantic errors}

Requirement E3

The Generator could report semantic errors in model descriptions. It is not straightforward to determine whether a model is semantically invalid.

\subsection{Parallel computing}

Requirement N3

The Fortran program could be designed to utilize multiple processors. For example generating proposals could be done in parallel with simulation. It has not been determined which other parts of the execution could be done in parallel.
