1.1 --- a/doc/krempler/design-ak.tex	Sat Mar 05 20:53:47 2005 +0100
     1.2 +++ b/doc/krempler/design-ak.tex	Wed Mar 09 05:53:06 2005 +0100
     1.3 @@ -9,7 +9,7 @@
     1.4  The Dialog Guide is responsible for guiding the user the way to obtaining a solution to a problem. 
     1.5  
     1.6  \subsection{Dialog Phases}
     1.7 -On a coarse level, interaction goes through several phases with fixed sequence, independent of the particular problem being solved (\refUR{COMMON:CALCDATA:phases}). These so-called Dialog Phases have been modelled on a state machine with well-defined states and transitions between the states. Regardless of mathematical context, the Dialog Phases provide a certain degree of error-robustness by recognising out-of-order events.
     1.8 +On a coarse level, interaction goes through several phases with fixed sequence, independent of the particular problem being solved (\refUR{COMMON:CALCDATA:phases}). These so-called Dialog Phases have been modelled on a state machine with well-defined states and transitions between the states. During each of these phases, the Dialog Guide behaves differently and reacts to different requests. Regardless of mathematical context, the Dialog Phases provide a certain degree of error-robustness by recognising out-of-order events.
     1.9  \subsubsection{Initialising}
    1.10  To start interaction, the Dialog Guide has to establish connections with the components it interacts with, a Worksheet representing the Presentation Layer and a Math Engine representing the application (\refUC{START:contact_math}). In addition to that, the Dialog Guide needs information about the user it deals with, to be able to adapt its behaviour accordingly (\refUC{START:ident_user}, \refUR{COMMON:USERS:multi}).
    1.11  Only after being provided with a CalcHead to act upon and - optionally - a Formalization of a pre-defined Example (\refUC{START:from_example}), the Dialog can enter the Specification Phase.
    1.12 @@ -19,15 +19,34 @@
    1.13  To enter the Solving Phase, a valid CalcHead is required.
    1.14  Consequently, the mathematical situation initially described by the CalcHead is transformed towards a situation called result. The transformation is performed in steps which are recorded in a CalcTree. As opposed to the Specifying Phase, the steps are not cumulative, but sequential. This implies that while it is possible to change steps already taken, such an action is likely to render subsequent steps invalid. The transformations are not performed by the Dialog Guide itself but by the Math Engine. Requests to take a step are passed to the Math Engine and steps entered by the user are checked by the Math Engine. Note that the Dialog Guide does not know anything about mathematics, it knows only about the structure of interaction in problem-solving. As stated before, transformations can be done entirely by the user or by the Math Engine, or with combined effort of both. This opens up a spectrum of interactional possibilities how to take a step and the various possibilities are described as Dialog Atoms (see \ref{}).
    1.15  
    1.16 +\paragraph{}
    1.17 +With the concept of a state machine in mind, additional phases can be added easily in the course of future development to handle more complex sequences.
    1.18  
    1.19  \subsubsection{Subproblems}
    1.20 -
    1.21 -With the concept of a state machine in mind, additional phases can be added easily in the course of future development to handle more complex sequences. 
    1.22 +Subproblems are calculations within calculations. In principle, they do not differ from top-level problems, but testing of the prototype implementation the necessity to treat the specification of subproblems differently might turn up. This can be achieved by adding another Dialog Phase. In the present implementation, interactive specification of subproblems is skipped and taking this step is always left to the Math Engine.
    1.23  
    1.24  % add state diagram
    1.25  
    1.26  \subsection{Dialog Atoms}
    1.27 -
    1.28 +As opposed to the high-level Dialog Phases, Dialog Atoms are basic building blocks of system-user interaction at the level of a single interaction. For configuring the Dialog Guide's interactional behaviour, we aim at developing an abstract language with Dialog atoms as "nouns".
    1.29 +%WN040506 Hhhmmmm, as Folgende brauchst Du für das nachfolgende UR --- kann man das nicht irgendwo ganz am Anfang einführen ????
    1.30 +The following proposal for possible atomic interactions when taking a step in a calculation during the Solving Phase is taken from \cite{wn:diss}:
    1.31 +\begin{quotation}
    1.32 +The dialog atoms are the following, ordered by descending 'activity' of the learner: All atoms concern a step from the current formula \currf applying a tactic \tac which yields the resulting formula \res(the derivation of \currf), i.e. $f\longrightarrow^{\it tac}\;f^\prime$.
    1.33 +\begin{enumerate}
    1.34 +\item \label{putres} given \currf, input the next formula \res 
    1.35 +\item \label{fillres} given a partial \currf (supplied by \sisac), complete \currf such that it is a derivation of \currf
    1.36 +\item \label{puttac}given \currf, input a tactic \tac to be applied to \currf
    1.37 +\item given \currf, select \tac from a list (supplied by \sisac) to be applied to \currf
    1.38 +\item \label{filltac} given \currf and a partial \tac, complete the \tac (i.e. a theorem, a substitution, etc.) such that it can be applied to \currf
    1.39 +\item given \currf, \tac, and a partial \res, complete \res such that it is the result of applying \tac to \currf
    1.40 +\item given \currf and \res, input \tac such that \res is the result of \currf applying \tac
    1.41 +\item given \currf and \res, select \tac from a list (supplied by \sisac) such that \res is the result of \currf applying \tac
    1.42 +\item given \currf, \res and a partial \tac, complete \tac such that \res is the result of \currf applying \tac
    1.43 +\end{enumerate}
    1.44 +\end{quotation}
    1.45 +Note that exchanging the parts of the user and \isac{} in the above proposal yields another set of Dialog Atoms, which can be treated as equivalent from the Dialog's point of view.  
    1.46 +Taking atom 1 as an example, it is essentially the same whether \currf is supplied by \isac{} and \res is expected to be input by the user or the user asks \isac{} to derive \res from \currf. In abstract terms, in both cases one part provides \currf and the other part is expected to supply \res. For this reason, the Dialog Guide tries to provide symmetric Dialog Atoms and make use of this symmetry in the implementation.
    1.47  
    1.48  \section{Communicating the State of Calculation}
    1.49  \subsection{Wrapper-based Design}