After putting ITL in a search context, we
want to show how ITL can be used with
model based development, to search
through the models generated according
to this development methodology.
This section describes some of additional issues relating 
to ITL that come with using it in a model based environment.

\subsection{Searching Through Models}
With model based development, models are 
used by software engineering
researchers to investigate different problems
in different stages of the software life cycle.
Earlier life stages might be modeled with
a cost/benefit model,
like DDP (described in \tion{ddpDes}),
or a quality model like COQUALMO \cite{chulani99b}.
Later life stages like testing might be modeled
with a digital logic circuit design (like these in \tion{nasa}).
The purpose of using a model is to find
which input settings of the model lead 
to certain desired behaviors.
These inputs need to be controllable or
observable quantities so that
information gained from exploring the model
is actionable outside the model.
%can be used to inform real world policy making.
For example, a researcher might use a quality model
to inform a business manager of the minimum level
of expertise needed by a development team to reach
an acceptable level of quality.
Or a researcher might use a cost/benefit model
to develop a plan that balances the projected
cost of a project with its projected value.

Using ITL for early stage life cycle models
can also reduces one of the potential drawbacks
of ITL's partial descriptions.
The earlier a model is constructed the more likely 
there will be changes before project completion.
But since the earlier potential problems are found
the greater the saving, postponing analysis
would be a self-defeating solution.
So the uncertainty inherent in ITL's solution due 
to the variance of a partial solution
will be partially washed out by the uncertainty in the
initial estimates made during model construction.

But what if the model has many uncertain inputs?
This is when reformulating the original software
engineering problem as a search problem is most useful.
The model now becomes something that is
executed thousands (or hundreds of thousands) of times,
rather than something used to evaluate a single
set of input values.

\subsection{ITL as Model Controller}
If we want to use ITL as a model controller to
use with model based development, some changes
have to be made in how ITL is implemented.
Using ITL to control model execution breaks 
the objective function into two parts
(see \fig{modelControl}).
The objective function doesn't decode the candidate solutions, 
instead the model takes the candidate solution as an input
vector and returns an output vector.
The objective function takes that output vector
and returns a single numeric value.
The reason we do this has to do with the assumptions
we make about the model (which will be discussed in 
\tion{itlModels}).
Now the theories returned by the treatment learner
are used to restrict which input vectors are given
to the model.
Again, when ITL finishes searching, the conjunction
of these theories constitutes ITL's solution.

\begin{figure}

\centerline{
\xymatrixcolsep{3.9pc}\xymatrix @L=6pt @R=10pt
{ 
& &
\framebox{\parbox{9.8ex}{partial\\ description}} \ar `l[lld] _{input\: vector\: selection\: informed\:\:\:\:\:\:\:\:\:\:\:\:\:\:}
                             ^{by\: partial\: description}
			     [lld]
& \ar [l]_-{new}^-{treatment} \framebox[7.0ex]{learner} 
\\
\framebox{\parbox{7.95ex}{input\\ selection}} \ar[r]^-{\: \: \: \vec{i}} &
\framebox[6.1ex]{model} \ar[r]^-{\vec{o}} &
\framebox[8.3ex]{obj func} \ar[r]^-{instance}_-{set} & 
\framebox[10.2ex]{discretizer} \ar[u]^-{instance}_-{set}
}
}
                             
%\centerline{
%\xymatrixcolsep{3.6pc}\xymatrix@L=6pt
%{ 
%& & \framebox{partial solution} \ar@/_15pt/[lld]_{input\: vector\: restrictions\:\:}\\
%\ar[r]^-{\vec{i}} &
%\framebox[6.1ex]{model} \ar[r]^-{\vec{o}} &
%\framebox[8ex]{obj func} \ar[r]^-{instance}_-{set} & 
%\framebox[10.2ex]{discretizer} \ar[r]^-{instance}_-{set} & 
%\ar@/_20pt/[llu]_{new\: treatment} 
%\framebox[9.5ex]{learner} 
%}
%}
\caption{Diagrammatic view of ITL as a model controller}
\label{fig:modelControl}
\end{figure}



\subsection{Models}\label{sect:itlModels}
There are a few important assumptions we made about the
models that would be used with ITL, which are
\begin{enumerate} \itemsep -14pt
\item they have a well-defined input vector, $\vec{i}$, that can be supplied by ITL
\item they are black boxes, \ie their internals can not be modified
\item they have a well-defined output vector, $\vec{o}$, that can be accessed by ITL
\end{enumerate}
ITL must be able to control the region sampled by the model,
so there must be some mechanism for ITL to direct the selection
of input vectors.
For example, the models used in \chap{casestudies} can be
given a file listing the points in the input space
that should be visited, so ITL only has to generate
that file in the correct format.
Since ITL must have a low overhead for use, it cannot need
access to any model's internals.  
This way the model can simply be a pre-compiled application.
This greatly lowers the cost of using ITL with a model 
developed without any consideration given to the possible use of ITL.
Finally the model must have an output that can be accessed by
ITL, because the learner and discretizer must be able 
to read all the points generated by the model.
%In practice this means 
The model could output something
to the file system in a format that can be decoded by ITL, for instance.





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