\chapter{Future Work}\label{chap:futurework}
In the future we would like to see more acceptance
of ITL as a general metaheuristic search technique
as well as see its use in model-based software development.
For ITL to become a well respected techniques, such as those
described in \tion{metaheur} and \tion{sbse},
the following research would have to be completed

\be
{ITL should be applied to instructive toy problems}
{ITL should be used to solve other software engineering problems}
\item the conjecture that ITL's use of partial solutions prevents it from getting stuck in local optima should be verified
\item a more rigorous study of alternative search strategies for ITL should be conducted
\item a downloadable, ready-to-use implementation of ITL should be made available to the public
\item methodologies for dealing with low-cardinality discrete functions should be investigated
\item different automatic stopping conditions could be investigated
\ee
The list's length reflects
the short time that has elapsed since ITL was developed
and the even shorter time that ITL has been considered a
metaheuristic search technique, rather than any intrinsic
difficulty foreseen in completing the proposed work.

\paragraph{Toy problems}
New techniques are often applied to simple problems
when first introduced.  This thesis introduced
ITL as a metaheuristic search technique, but
skipped the step of proving ITL could be 
effective on simple problems.
For example, ITL could be used to find satisfying
assignments for propositional logic statements,
\eg in LSAT problems, 
to find maxima in piecewise-linear functions,
or to find function approximators.

\paragraph{Other software engineering problems}
As shown in \tion{sbse}, metaheuristic search techniques
have been applied to numerous problem domains
in software engineering.
It would bolster the case for ITL if it was used
to solve problems in domains
other than requirements analysis, \chap{casestudies},
and model property verification, \chap{properties}.


\paragraph{ITL robustness in the face of local optima}
It was conjectured in \chap{itl} that the
use of partial solutions makes ITL unlikely to
get stuck in local optima.
This claim should be investigated, most
likely through the use of toy problems have
have a variable amount of deceptiveness.
This question has great bearing on the issue of
search strategy.
If ITL is currently, as conjectured, robust in the 
presence of numerous local optima, then improvements
to the search strategy would not have to be tailored
to this problem.
If, however, this conjecture turns out to be incorrect,
then new search strategies specifically designed to
combat the presence of local optima need to be developed.

\paragraph{Improved search strategy}
As discussed in \chap{itl}, ITL currently uses a
simple greedy forward select without any backtracking.
Investigation into more sophisticated strategies
should be done.
There are at least two features that the search strategy could use.
First, the search should be able to proceed backwards as
well as forwards, \ie ITL should be able to retract
some of the previous treatments according to some rule.
Second, the search should have some parameter that controls
the amount of exploration and exploitation done.
This could be set by the user at the start of the search
or could be dynamically adjusted during the search.

Another feature that might prove useful is allowing
ITL to maintain multiple partial descriptions so that
multiple hyper-rectangles be searched each iteration.
This is shown in \fig{itlSearchFuture}.
While some attempt was made to conduct this type
of search, as described in \tion{searchStrategy},
that search strategy did not maintain multiple hyper-rectangles.
While searching points that passed any treatment found during
each iteration, ITL did not keep track of which
treatments were actually responsible for
increasing the objective score.
Searching only one hyper-rectangle makes the assumption
that there are not multiple locations in the input
space that have equal quality near-optimal solutions.
A traditional metaheuristic search technique would
not necessarily try to capture multiple near-optimal solutions, 
even if they were of the same quality, 
since the user only wants a single high-quality solution.
But ITL, particular when viewed as a model controller,
attempts to restrict output behavior,
so if a model exhibits highly desirable behavior
in more than one location in the input space,
ITL should try to find all such locations
to provide the user with a more flexible set of advice.

\begin{figure}
\centering
\begin{tabular}{cc}
\includegraphics[width=2.7in]{Figures/itl_search} &
\includegraphics[width=2.7in]{Figures/multi_search} \\
single hyper-rectangle & multiple hyper-rectangles \\
\end{tabular}
\caption{Restricting search to a single vs.\ multiple hyper-rectangles}
\label{fig:itlSearchFuture} 
\end{figure}


\paragraph{Public availability}
Our current implementation of ITL\footnote{Internally called surfer.} grew 
out of a GUI developed for instructional purposes.
While adherence to OO design principles has
made extension of the code base possible,
it is probably time for the prototype to 
be thrown away now that we have gained valuable
insight into what works and what needs to be
tried.
This next version of the code should be as portable
and ready to use as the GA package gac\footnote{
Found at \url{http://www.cs.uwyo.edu/~wspears/freeware.html}.} or 
the machine learning weka package\footnote{Found at \url{http://www.cs.waikato.ac.nz/ml/weka/}.}.
In particular, the code should be developed with
the possibility of replacing certain parts of
the algorithm easily; for instance, we have already
mentioned that the search strategy might need improvement.
This code also needs to have a publicly accessible
location so that other researchers can access it
without needing to get in contact with its developers.

\paragraph{New methodologies for objective function development}
The difficulties we saw ITL have with the models
in \chap{others} might be solved with improved
methodologies for developing objective functions.
While objective function development will always
require a certain amount of domain-specific knowledge,
it is possible that certain methodologies
tailored for use with ITL can be found that offer
general guidance to analysts faced with
discrete objective functions.

\paragraph{Automatic stopping conditions}
All the studies in this thesis ran the ITL search
for a fixed number of iterations, \ie
a fixed search depth.
The size of  partial descriptions that will be useful
is a domain specific feature.
Different models with input spaces with different 
cardinalities will require different sized partial
descriptions to constrain output behavior.
So that users of ITL do not have to experiment
with different search depths to determine the
size of useful partial descriptions,
different automatic stopping conditions should be
developed.
These stopping conditions might be based on
the average values of the partial descriptions
or the variance of the partial descriptions. 

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "../thesis"
%%% End: 
