legend to the reader's marks:

%

% [] the brackets enclose comments additional to,

%    and not belonging to the text

%

% {} the braces enclose exact proposals for new text,

%    which are embedded into comments.

%

% /  marks a character to be deleted in the line _above_

%

% ^  points to a certain position in the line above,

%    usually concerning a comment or an insertion

\part{Architectural Design Document}

\chapter{Surveys}

\section{Survey on the components}

Below there is a short description of the role of the modules shown in

Fig.\ref{all-modules}.

\begin{figure} [htb] 

\centerline{\psfig{figure=fig/soffice/RK-architecture.eps,width=11cm}}

\caption{\sisac s components} \label{all-modules}

\end{figure}

\begin{description}

 \item[Browsers] (Example Browser, Knowledge Browser) allow to browse

 through the content of \sisac s knowledge base. The browsers also allow dynamic views onto the knowledge, where an actual example is the starting point to find appropriate (types of) problem(s), theorems in use, etc.

%the \emph{KE-Store}. There are different types of informations (Problems, Methods, Examples, \dots) which can be accessed in a similar way.

%A Browser might also add dynamic information (i.e. to visualize if a problem matches a model) and is mainly accessed through browser-windows (delivers its content as HTML-pages).

%\item[Browser-window] Used to access the HTML-pages generated by \emph{knowledge browsers} and the \emph{example browser} (not shown in Fig.\ref{all-modules}).

%\item[Browser generators] transform knowledge held in SML-datastructures into an XML standard format which is augmented with metadata by use of the description editor. (Not displayed in Fig.\ref{all-modules}) %Interpretation of the internal SML structures to create a browseable hierarchy for Problem- and other Browsers.

 \item[Worksheet] is the learners main working place when calculating an example in interaction with \sisac. A calculation on this worksheet is intended to be like traditional paper-and-pencil work.

 \item [Dialog-guide] consists of two parts, the worksheet-dialog and the browser-dialog. The former is responsible for the interaction with the math-engine (appropriately detailed steps etc.), the latter for the views into the knowledge base (which might depend of which course the learner is member of, etc.)

\item[Dialog editor] allows to define dialog patterns and strategies, and to preset dialog states.

 \item [User-model] holds settings for the dialog-state and a (compressed) history of dialog-states.

 \item [Dialog-settings] are given for each learner in order to preset the dialog appropriately to the respective preferences (graphical representation etc.).

 \item[Explanation Editor] is used by a course designer or a teacher (no specific exptertise in computermathematics is required~!) (1) to prepare examples and (2) to extend \sisac s knowledge base with explanations.

%Used to gather information and extend the information stored in the descriptions records. Administrators as well as Course-leaders have to be assisted when they build up their curse or maintain existing informations. The description-editor acts as ``frontend'' for the \emph{description}

\item [Examples] are provided with with hidden formalisations for automated solving as \sisac s prerequisite for user guidance. They can exactly be formatted like example collections in traditional textbooks.

\item [Knowledge + explanations] is what the learner sees during problem solving:

\begin{enumerate}

\item Theories with axioms, definitions and theorems (proven with

Isabelle) \item Problems like types of equations, or problems of

applied math \item Methods to solve the problems.

\end{enumerate}

These three parts of knowledge have been imported from SML in a batch process, and this raw material can be augmented with multimedia explanations by the explanation editor, presumerably specific to courses.

\item [Math authoring] tools provide for the compilation of the knowledge, which \sisac{} requires for automated problem solving (as the prerequisite for user guidance). This task requires more or less expertise in computermathematics.

\item [Knowledge] comprises theories, problems and methods, and is held in the SML-core for efficient access by the math engine. This knowledge is exported to XML (in a batch process) for augmentation with explanations using the explanation editor.

 \item [Math engine] is a fairly small knowledge interpreter, which depends on the knowledge and some of Isabelles services (matching, parsing, pretty-printing etc.). Thus the math engine is written in the same language as Isabelle, in SML.

 \item[Calc-state] (short for state of a calculation) is held in a calc-tree for each calculation.

 \item [Isabelle] is an interactive theoremprover which lays the deductive foundation of \sisac.

\item [Bridge] wraps the SML-process of the math-engine as a Java-object, i.e. it provides for data-exchange between SML and Java, for multi-user facilities and for distributing work-load to several instances of the math-engine.

\end{description}

%WN050519---AK->isac-ADD-----------------BEGIN---please don't remove this line

\footnote{Begin of copy from \cite{AK04:thesis} p.53-57.}

\section{Basic Concepts for Separable User Interfaces}\label{AK:DESIGN:SYSTEM:BASIC}

Apart from the benefits of structuring complex systems, separable user interfaces provide adaptability of look-and-feel without the need of reworking the entire system. For our analysis, we will concentrate on the Seeheim and Model-View-Controller (MVC) basic architectures.

\subsection{The Seeheim Model}\label{AK:DESIGN:SYSTEM:BASIC:seeheim}

The Seeheim Model \cite{Seeheim}

%WN040619 \cite{...The Seeheim Model...}

%

%WN040619 vielleicht auch eine kurze Bemerkung dazu, dass das Modell bereits in den Urzeiten der Softwaretechnologie formuliert wurde (und heute nicht/trotzdem zitiert wird -- INSPEC auf der TUB macht 'forward searches')

%

splits the entire system into three components as follows:

\begin{description}

\item[The Presentation Layer] is responsible for translation of

physical representations, such as images, sounds, key-presses or

mouse events into the logical concepts of the system and vice

versa. Typical tasks of the Presentation Layer include rendering

data on the display and parsing user input. \item[The Dialogue

Controller] defines the structure of the interaction between user

and system. Typical tasks of the Dialogue Controller include

accepting events the user triggered on the Presentation Layer,

routing events to appropriate destinations and making decisions

whether and how to notify the user of changes in the state of the

system. In other words, the Dialogue Controller defines (and

enforces the use of) a language for the interaction between user

and application. \item[The Application Interface] is an

abstraction of the application's data and procedures from the user

interface's point of view. It maps objects and operations on the

user interface to actual data objects and code in the application,

thus representing the application's functionality in a concise and

consistent way.

\end{description}

\begin{figure} [htb]

\centerline{\includegraphics[width=\textwidth, keepaspectratio=true]{fig/AK-seeheim_basic}}

\caption{Interaction in the Seeheim Architecture}

\label{fig.seeheim_basic}

\end{figure}

Note that in figure \ref{fig.seeheim_basic}, the messages are named "notify" and "request" from the user's point of view. From the Dialogue Controller's point of view, the messages are distinguished by their direction in or out of the Dialogue Controller. Even more so, the Application and the Presentation Layer (representing the user) do not differ in a structural way. Both are merely objects generating events which might be of interest to other objects and have to be handled according to the Dialogue Controller's state and logic. It is the semantic in the Dialogue Controller's logic that makes a difference between user and application, if any.

\subsection{The MVC Architecture}\label{AK:DESIGN:SYSTEM:BASIC:mvc}

As opposed to the Seeheim Model, which structures the system as a whole, the MVC

%WN040619 \cite{}

architecture \cite{buschmann} is grouped around single data objects as follows:

%

%WN040619 wie oben: MVC kurz in die Landschaft einordnen (kurze Recherche mit Google hat mir auch schon die Augen ge�fnet ;-) ... super, dass Du auch einen (offenbar _sehr_) aktuellen Ansatz gefunden hast !!!

%

\begin{description}

\item[The Model] is any data object in the application requiring user interaction.

\item[The View] is an object providing a visual representation of the respective Model, thus enabling the Model to output its data.

\item[The Controller] is an object accepting user input and notifying the Model or the View accordingly, thus providing the user with a means of controlling the Model.

\end{description}

\begin{figure} [htb]

\centerline{\includegraphics[width=8cm, keepaspectratio=true]{fig/AK-mvc_collaboration}}

\caption{Interaction in the MVC Architecture}

\label{fig.mvc_collaboration}

\end{figure}

In a complex system, the link between application and user can contain several Model-View-Controller-triples, each grouped around a specific data item.

\subsection{Comparing the approaches}\label{AK:DESIGN:SYSTEM:BASIC:compare}

\begin{itemize}

\item Without the need to pass the Dialogue Controller on every interaction, the MVC model tends to be faster in runtime. This is particularly important for giving the user immediate feedback about his current actions and options.

% pl: Ich sehe nicht, warum das MVC Modell effizienter sein soll.

\item Being built around smaller units of single objects, MVC is more flexible and easier to develop and extend.

% pl: Das halte ich auch fuer Propaganda. Es ist nicht flexibler, wenn die

% Praesentation eines Elementsvon einem globalen Kontext abhaengt.

\item On the other hand, MVC lacks the clear separation between application and presentation layer, spreading the functionality across a multitude of interacting MVC triples. While this eases development, the resulting complex dependencies make it harder to understand or debug the system as a whole.

% pl: Eben, das ist doch wesentlich.

\end{itemize}

%WN040619 Der guten Eindruck (wenn nicht gar neu entfachtes Interesse), den Du mit dem Absatz bei Prof.Lucas machst, wird noch besser, wenn Du Artikel angibst, die diesen Vergleich auch machen (oder hat man das Seeheim-Model schon ganz vergessen ?)

\subsection{Implications for \isac{}}\label{AK:DESIGN:SYSTEM:BASIC:isac}

\label{seeheim-mvc}%...%WN040815

The design of \isac{} is based on the Seeheim Model, for the following reasons:

\begin{itemize}

\item A clear separation of Application, Dialogue Controller and Presentation layer is a design goal because:

\begin{itemize}

\item At present, the Application itself is written in SML, whereas the rest of the system is being implemented in Java. The necessity to interface the different worlds of different programming languages implicitly separates Application from User Interface.

% pl: Die Struktur waere auch sinnvoll, wenn alles in eneir Sprache

% implementiert waere.

\item The already-implemented Math Engine with the Isabelle system in the background uses more computing resources than a typical consumer machine can provide at present. This and the goal to centralise mathematical knowledge and example collections for groups of users suggests running the Application on a dedicated server.

\item To minimise effort and expenses on the side of the user, the part of the system running on the user's machine should be kept as small as possible, a Java-capable web browser being the aimed-at minimum. An ideal design would leave only the Presentation Layer running on the user's machine.

\item The goal to adapt \isac{}'s behaviour to the situation of the individual user's situation asks for a well-defined, configurable and exchangeable Dialogue Controller.

\item As it seems foreseeable that the design of \isac{}'s Dialogue Controller will pose questions going well beyond the scope of a single master's thesis, a separable Dialogue Controller component will ease independent research. We expect the development of new approaches to dialogue description languages as practical experience with a \isac{} prototype becomes available.

%WN040619 An dieser Stelle des theoretischen Zuganges zum isac-Dialog ist vielleicht taktisch klug vorzubemerken, dass _eine_ Diplomarbeit die Aufgabe nicht zu Ende bringen kann. Dann ergibt die deutliche Separation der Dialogkomponente nach Seeheim weitere Vorteile: die leichtere Weiterfhrung der Arbeit am Dialog (wobei im isac-Projekt damit gerechnet wird, dass die isac-Interaktionsm�licheiten 'between partners (user --- system) on an equal base' neuartige Ans�ze fr Dialog-Beschreibungs-Sprachen forcieren werden, sobald praktische Erfahrungen mit isac m�lich sind)

%AK danke, sehr wertvoll!!!!

\end{itemize}

\item The major drawback of the Seeheim Model, the difficulty to provide immediate feedback to the user, is not relevant to the design of \isac{}, as the complex mathematical knowledge involved requires consultation of the Math Engine for even basic feedbacks. With the present speed of the Math Engine, any additional delays from the use of the Seeheim Model will not be perceivable by the user.

% pl: Das verstehe ich auch nicht ganz. Z.B. syntaktisch falsch eingegebene

% Zahlen kann man doch sofort abfangen, oder nicht? Aber vielleicht auch

% nicht. Da muesste man den Design genauer kennen.

%WN040619 .. elegant ausgedrckt ;-)

Any operations not involving mathematical knowledge can be handled locally by the Presentation Layer, in a MVC manner, if desired.

\item The aforementioned goal of adapting \isac{}'s behaviour to the situation of the individual user can be easily adressed by augmenting a centralised Dialogue Controller with a User Model. The User Model would store preferences set by the course designer and the user himself. The Dialog Guide would report activities to the User Model, which would store these reports and process them into an abstraction of the user's preferences, experience and behaviour. The other way round, the User Model would be queried by the Dialog Guide for clues how to behave in a specific user-interaction situation.

\end{itemize}

% This makes a preliminary design for \isac{} look something like:

% pl: Warum "preliminary" und "something like this" ?

% Wie waere: "Based on these considerations, the top level design of \isac{}

% looks like this"

Based on these considerations, the top level design of \isac{} looks like this:

\begin{description}

\item[Math Engine or Kernel] In terms of the Seeheim Model, this is the Application. This component is already implementetd in SML and is intended to run on a centralisad dedicated server. All mathematical knowledge resides in this component,

%WN040819 All mathematical knowledge required for calculations by the kernel ...

all calculations are done here.

%WN040819 (while the (static~!) knowledge to be shown to the user is exported from SML to the KE-Store (XML) by a batch process).

%WN040819 ... wobei meine Bemerkungen an dieser Stelle ev.zu sehr ins Detail und daher woanders hin gehoeren; aber irgendein Bezug zwischen hier ('mathematical knowledge') und 6.4.1...Browsing the 'Knowledge Base' waere ev. hilfreich

The SML system communicates via the standard input and output text streams.

\item[Dialog Guide and User Model] In terms of the Seeheim Model, this is the Dialogue Conroller. This component is being implemented in Java. All user interaction is controlled by this component, and this is the only component aware of the individul user.

% pl: Ist die Implementierung Teil der Diplomarbeit?

\item[Worksheet] In terms of the Seeheim Model, this is the Presentation Layer. This component is being implemented in Java, with the additional goal of running in standard environments encountered on a consumer PC installations, as this component is intended to run locally on the user's machine.  The Worksheet is the only component aware of visual aspects of data, such as formatting, and the only component with direct user-interaction.

\end{description}

\begin{figure} [htb]

\centerline{\includegraphics[width=\textwidth, keepaspectratio=true]{fig/AK-isac_seeheim_um}}

\caption{Basic \isac{} architecture for calculations}

\label{fig.isac_seeheim_um}

\end{figure}

\footnote{End of copy from \cite{AK04:thesis} p.53-57.}

%WN050519---AK->isac-ADD-----------------END---please don't remove this line

\section{Survey on the architecture}\label{MH->isac-ADD1}

\cite{MH04:thesis} describes the architecture depictured in Fig.

\ref{fig.system_overview} on p.\pageref{fig.system_overview} as follows.

%WN040815---MH->isac-ADD1-----------------BEGIN---please don't remove this line

\begin{figure}[htb]

\centerline{\psfig{figure=fig/MH-system_overview.eps,width=7cm}}

%\centerline{\includegraphics[width=\textwidth, keepaspectratio=true]{system_overview}}

\caption{The current design of the \isac{} system}

\label{fig.system_overview}

\end{figure}

The system architecture is designed as a \emph{distributed system}. %WN040815\cite{coulouris}.

This means that the components described below are designed process

independently and they can be executed on different computers

concurrently. The thesis covers the design of the graphical user interface

component and the interfaces that are necessary to connect to the

other components of \sisac{}.

The components of \sisac{} are:

\begin{itemize}

  \item The \textbf{backend} of \sisac{} is responsible for doing

   the calculation and holding the mathematical knowledge also known

   as knowledge base. The mathematical engine can only do one calculation

   at a time.

   This is a restriction that needs to be bypassed.

  \item  Hence, the component called \textbf{Bridge}

   is designed as a \emph{multiuser} component. Multiuser in this

   context means that the Bridge distributes the simultaneous user

   requests over several instances of the mathematical machine.

   A more detailed description can be found in \cite{RG04:thesis}.

   Note that in this context the name Bridge has nothing to do with the

   structural software pattern ``Bridge'', described in

   Design Patterns by the ``Gang of Four''. %\cite{Gamma95}.

Rather, the

   component Bridge in the \sisac{} system architecture can be

   described as an ``Adapter'' in the meaning of a design pattern.

   It converts the interface of the mathematical engine

   into another interface that the other parts of \sisac{}, especially the

   \emph{WorksheetDialog}, expect.

   Moreover, the Bridge also ``converts'' the functional software

   design paradigm of the mathematical engine into an object-oriented

   design paradigm the other parts of \sisac{} expect; therefore, the Bridge lets

   components work together that could not otherwise because

   of incompatible interfaces.

  \item The \textbf{WorksheetDialog} acts as a middleman between the Worksheet

   and the Bridge. It is the central component while solving an example.

   The Worksheet provides the user with information during a calculation in

   cooperation with the WorksheetDialog. The WorksheetDialog decides how detailed

   the user should see the information, depending on the user history, experience

   of the user and role of the user. The WorksheetDialog can also

   restrict the access to parts of the knowledge to ensure that the

   user is not swamped with examples for which his experience level is not

   high enough and he is not meant to solve yet.

   The design of the WorksheetDialog at the moment concentrates on the

   solving part. User history, restricting access and different grades

   for showing information are scheduled in the design but not yet completely

   finished.

   Worksheet and WorksheetDialog stand in a 1:1 relation, which means that

   for each Worksheet a separate WorksheetDialog is necessary.

  \item The \textbf{BrowserDialog}\label{AG:BrowserDialog} is the component in charge as far as the

   knowledge base is concerned. Strictly speaking, the \emph{InformationProcessor}

   provides information about the knowledge base. Each part of the knowledge base

   (problem, method and theory, see section~\ref{knowledge base}) can be accessed and also

   the example collection can be accessed.

   Another task of the InformationProcessor is the authorization of the

   user that wants to connect to the \sisac{} system.

   Currently a username and a password are used to authorize

   the user. Security considerations like encryption

   have not been included in the design process so far.

   The InformationProcessor provides

   a well designed interface that can be used by a client and is described

   in more detail in section \ref{D:IP}.

   The \emph{SessionDialog}, which is also part of the BrowserDialog, is

   responsible for the (re-) identification of the user.

   A user might connect and log in several times

   (e.g. with different applications), then the SessionDialog has to ensure

   that all WorksheetDialogs for this user work on the same data.

   A deeper look into the design of the SessionDialog can

   be found in \cite{AG:thesis}.

   There is only one SessionDialog per \sisac{} system.

  \item The \textbf{Graphical User Interface} is responsible for

   establishing a connection to \sisac{}. It consists of two components, namely,

   the \emph{HierarchyBrowser} and the \emph{Worksheet}. The requirements

   for these components have already been described in sections \ref{REQ:WS} and

   \ref{REQ:HB}. The following sections describe the design of the

   graphical user interface and the communication interfaces to the

   WorksheetDialog and BrowserDialog.

\end{itemize}

%WN040815---MH->isac-ADD1-----------------END---please don't remove this line

\chapter{Session Management}

%WN040815---AG->isac-ADD1-----------------BEGIN---please don't remove this line

%WN040815---AG->isac-ADD1-----------------BEGIN---please don't remove this line

 \section{The Dialogs}

 \label{ADD:dialog}

 The \emph{dialog} is the ``heart'' of the system which controls the

 behavior of the different modules. It is responsible to adjust the

 reaction of the system to fit the learners (and teachers) demands.

 Among others, these demands contain:

 \begin{description}

 \item [record a learners success] by means of solved examples. This

   record can be used to create a set of proposed examples for a

   single user. Furthermore, the teacher can use this feedback to

   enhance the quality of his lecture (e.g if a single example causes

   problems for most students)

 \item [restrict access to parts of the knowledge] The set of

   available examples can vary depending on the already solved

   examples or the progress of the lecture to ensure, that the student

   is not swamped with examples he is not meant to solve yet.

   Furthermore, the available information have to be restricted while

   the learner writes a test. This also implies, that the access for

   not authenticated users can be restricted as well (by IP). (The

   user may not access the public information)

 \item [communication between different applications] \isac{} uses

   different applications to access the knowledge and mathematical

   capabilities of the system. For example: from the users point of

   view, the worksheet calculates while the KnowledgeBrowsers are used

   to select problems or methods for use within the calculation. In

   this case, worksheet and KnowledgeBrowser are just two

   access-points for the same application. The dialog establishes and

   controls the connection of these access-points.

 \item [manage the connected users] A user might be connected using

   several applications. For instance he can calculate an example and

   search a related \emph{problem} using a \emph{browser}. The dialog

   has to ensure, that these applications work on the same data.

   Therefore a \emph{session} is used which is aware of the different

   connections of a user.

 \end{description}

 Because of the various duties of the dialog, it is split up into a

 number of modules. Applications have an own ``peer'' which is used to

 communicate which them. These peers act as a kind of ``border'' --

 informations the user is not meant to get, may not cross this border

 but are filtered before. This filtering goes along with an possible

 transformation of the data.

%For instance -- as mentioned in previous

% subsections -- a \emph{KE-Object} is transferred to the internal

% object structure when it is loaded from the

% \emph{KE-Store}. The \emph{browser-dialog} is used to

% translate it to XML after all manipulations on the object are done.

%

% These considerations lead to the component-layout as given in figure

% \ref{fig.browser-masterdialog} on p.\pageref{fig.browser-masterdialog} which shows the dialog and its relations

% to the applications along the informations where they are located

% (server or client). Although the ``browser'' runs on the server, it

% is situated in the frontend-layer. The reason is that the Web-Based

% knowledge-browser as discussed in this state of development, could be

% replaced by an browser with an other interface. This may not affect

% the overall design of the system.

%

% \begin{figure} [htb]

%\begin{center}

%   \centerline{

%\psfig{figure=fig/browser-masterdialog.eps,height=11cm}

%%\includegraphics[width=11cm]{\extend{fig/browser-masterdialog}}

%}

%   \caption{Structure of the Dialog}

%

%%=\label{fig.browser-masterdialog}

%   \label{ADD:dialog-structure}

% \end{center}

% \end{figure}

 \subsection{Session-Dialog}\label{ADD:session_dialog}

 The \emph{session-dialog} governs the user-login and performs all

 necessary actions to build up a users dialog. It is started on

 system-startup and waits for connects by an

 \emph{session-controller}. There is only one session-dialog per

 \isac\/-System.

 The session-controller is a client-side program which performs the

 login and starts the \isac{} frontend-applications on a users

 machine.  Besides the authentication, the session-dialog is also

 responsible to instantiate and interlink the application dependent

 parts of the dialog-layer as there are the Browser-Dialog and the

 WorkSheet-Dialog.

 Although one user can log in twice at a time, only one application

 dialog is created to ensure that all user-dependent information are

 up to date. Therefore the session-dialog has to maintain lists of

 logged in users and their respective dialogs.

For the dialogs providing user-guidance see chap.\ref{DG} below.

%--- from AGs thesis ------------------------------------//WN060324

% \subsection{Browser-Dialog}\label{AG:Browser-Dialog}

% These requirements demand that the Dialog is involved in all

% user-activities. Therefore, the Dialog ``sticks'' behind the Browser

% and determines the way of information-representation. Nevertheless,

% the Browser has different ``modes'' which need more or less

% interference of the Dialog.

%

% \begin{figure} [htb]

%\begin{center}

%   \centerline{

%\psfig{figure=fig/browser-dialog.eps,width=11cm}

%%\includegraphics[width=11cm]{\extend{fig/browser-dialog}}

%}

%   \caption{Interaction with the Browser-Dialog}

%   \label{design}

%\end{center}

% \end{figure}

%

% \begin{description}

% \item[static knowledge-browsing] is access to the knowledge allowed -

%   determine and select additional informations (fitting explanations

%   and examples), log access.

%

% \item[search an item] determine the amount of help to give, log

%   access. The ``amount of help'' includes the representation of

%   additional information as well as the presentation of

%   ``match-results''. Matching is done through contacting the

%   \emph{WS-Dialog} which holds the necessary informations to perform

%   a match.

%

% \item[select an item] ``push it into the model'' contact the

%   responsible \emph{WS-Dialog} and ``offer'' the selected item

%   (Problem, Method, \dots). This Mode needs to know the responsible

%   worksheet in first place. The user could run more then one

%   worksheet at a time - so the Browser needs to know to which one the

%   selected item should be passed.

% \end{description}

%

% So, the browser-dialog acts as peer for the browser. It performs all

% communications with the rest of the \isac{} system and transform the

% data to a suitable format. It does not constrain the browsers mode

% (what the browser wants to do) or the presentation of the gathered

% informations.

%

% \subsection{WorkSheet Dialog}

% The worksheet-dialog contains the ``intelligence'' of the Worksheet, see chap.\ref{DG} below.

\subsection{Browser-Dialog and Worksheet-Dialogs}\label{WN-add-BDialog-WSDialog}Both dialogs are discussed in a separate chapter, in chap.\ref{DG}.

TODO.WN060705

 \section{Access Rights}

%WN000705---summerterm06------------BEGIN---please don't remove this line

\subsection{Dialog Guide and User Model}\label{WN-add-DG-UserModel}

%WN000705---summerterm06--------------END---please don't remove this line

 \subsection{User-Administration}

 \label{ADD:user_admin}

 The \emph{user-administration}\/-module helps the dialog to maintain

 the users and control the access for \emph{courses}.

 \subsubsection{user}

 Information stored in an user-module contain personal information

 like name and login, as well as important administrative information

 like the courses he is member of and a reference to the

 \emph{user-model} which contains all information which are relevant

 to build up an environment for the user (solved examples, history,

 ...)

 \begin{verbatim}

 user:

    FirstName:String

    LastName:String

    login: String

    password: String (encrypted)

    courses: {course*}

    solved_examples, history, ...

    temporary_environ: hierarchy_opt

 \end{verbatim}

 The field \emph{temporary\_environ} is used in case of an

 examination.  If this field is set to non-empty, a user has only

 permissions to the elements of the referenced hierarchy. This

 hierarchy typically contains the examples to solve and a few

 explanations which are permitted within the exam.

 \subsubsection{course}

\label{ADD:course}

 A \emph{course} is a object within \isac{} to define a learning

 environment for different users. Typically, a course contains

 explanations to the mentioned theories and examples which are

 organized within an hierarchy.  There are tools which help a

 course-designer to build up a hierarchy by e.g. copying a part of an

 other hierarchy. A typical reason for doing this is to copy a part of

 the problem-hierarchy and afterwards enrich the items with

 explanations and examples fitting the audience of the

 course

% \kommentar{gute moeglichkeit, die beschreibungen und beispiele an den

%   kurs anzupassen. examples koennen trotzdem noch fuer die

%   kursteilnehmer herausgefiltert werden.}.

 Additionally, examples and general explanations can be added.

 The hierarchy of a course is located within the \emph{KE-Store}

 while the object describing the actual \emph{course} is located

 within the \emph{user-management-module}. Permissions are handled based on the user and

 \emph{KE-Objects} (hierarchies, examples, explanations,

 knowledge)

 \begin{verbatim}

  course:

     metadata:

     name:string

     hierarchy: hierarchy-id

     members:{user-id, user-id, ...}

     admin: user-id

 \end{verbatim}

 There are tools which perform the tasks of adding an removing users

 to a course. While adding a user to a course is relatively simple --

 ensure the user has proper rights for all \emph{KE-Objects} within

 the used hierarchy -- the task of removing a user from a course is

 more complicated: the user might be member of more than one course

 which access the same example. Removing access-rights for such an

 example might collide with the course the user is still member of.

 Therefore, the tool has to check all courses of the user before

 removing any permissions.

 The data-structure is usable for another set of tools which can act

 on them -- like hide an example for all members of a course till they

 are able to solve them or contact all of the course-members.

%fuer commit

%object structure

%begin of dialog-description (has to be reviewed)

%user-state and relations (user defined hierarchy) are still missing

%\section{missing objects (temporary subsection)}

 \subsection{Permissions-module}

 The \emph{permissions-module} stores and maintains informations

 about which user might access to which \emph{KE-Objects}. The

 administration of the permissions is based upon the users stored

 within the \emph{user-administration}\/-module

 Permissions are applied, whenever an KE-Object is accessed. When

 informations ``leave'' the dialog -- e.g. when they are delivered to

 the \emph{browser}, the (browser-) dialog can remove links whose

 destinations are not accessible. Note, that the dialog can decide not

 to show an example to a user although he has the proper permissions

 -- in this case, the references are filtered out by an didactic filter.

%before they are delivered to the browser-dialog.

 Permissions can be set at once to a number of users using tools which

 can access the objects within the \emph{user-management-module}.

 E.g. a tool is used to to add and remove users from a course. These

 tools traverse the members of the course and set the proper

 permissions for them. There is a special mode to limit access, when

 the user participates to a exam. In this case access is limited to

 the environment given in the \emph{temporary\_environ} field of the

 user-object.

%WN040815---AG->isac-ADD1-----------------END---please don't remove this line

%WN040815---AG->isac-ADD1-----------------END---please don't remove this line

\chapter{Dialog Guide}\label{DG}

%WN050518---AK.p.61-62->isac-ADD--------BEGIN---please don't remove this line

\footnote{Begin of copy from Alan Krempler \cite{AK04:thesis} p.61-62 with updates by Georg Kompacher \cite{ba-GK07}.}

%\subsubsection{Browsing the Knowledge Base}

\section{Browser Dialogs and WorkSheet Dialog}\label{WN-add-BDialog-WSDialog}

%WN060324--->thesis.ML-----------------BEGIN---please don't remove this line

In contrast to most currently available algebra systems, \isac{} bases its

calculations entirely on rules and knowledge visible to the user. For

every step done in a calculation, there is a justification in \isac{}'s

knowledge base, which can be displayed on request. Even more importantly,

these justifications are meant to be understood by the user, as they are

expressed in terms of human mathematical reasoning, not in sophisticated

and optimised algorithms.

% GK070313- tag for quicksearch START

As \isac{}'s knowledge base can be understood by humans, it can be used as

a reference or even as a learning tool. Interaction with the knowlegde base is moderated by a dialogue controller (see also section \ref{AK:DESIGN:SYSTEM:BASIC:seeheim}), in a way similar to the interaction with the math engine in an ongoing calculation. Such a dialogue controller is responsible for the processing of actions coming from the math engine or the knowledge base and also for the response to user actions.

\begin{figure}[htb]

\centerline{\includegraphics[width=10cm, keepaspectratio=true]{fig/AK-sysdesign_draft}}

\caption{The first sketch for \isac{}'s architecture}

\label{fig.sysdesign_draft}

\end{figure}

% KE-Store heisst im Glossary "KE-base"? Die Bedeutung muss auch im Text

% erklaert werden.

As it was already discussed in UR.\ref{ur:4-data} the design took the designers of \sisac{} to 4 different browsers and guarantee a well designed abstraction every browser gets its own dialogue controller. Such a dialogue controller is one of the basic parts inside of \sisac{}. In the following paragraphs the term browsers will be used to describe the three knowledge browsers and the example browser. So these browsers with their corresponding dialogue controllers can be seen as one subsystem.

Mathematical knowledge is normally very static, but with \isac{} you can also make the current problem, method, theory or example available thru one of your browsers. So the basic design led to two subsystems which can be used separately, each with a presentation layer and a dialogue controller, but they can also access the actual context of each other.

The two subsystems interact in the following points:

\begin{itemize}

\item Both dialogue controllers share a common User Model, for a inventory of knowledge supposedly known to the user, be it from browsing the respective knowledge item, be it from having used specific knowledge in a calculation.

\item When browsing thru the knowledge base, an example illustrating the presented concept can be calculated.

\item When doing a calculation, items from the knowledge base justifying the correctness of the calculation can be displayed. This kind of context-based access to math knowledge is considered an efficient method of learning in \sisac.

%WN060324+++............................................................

The other reason for accessing the Knowledge Base from a calculation is, to explore the application of nearby knowledge-items to the calculation.

\item If the user is within a calculation and wants to apply a theorem to the current formula, he can switch to the theory browser and apply any formula of the knowledge base which matches. This communication between a browser and an active worksheet is done between their dialogue controllers.

%  \begin{itemize}

%  \item Which other theorem can be applied to the current formula~?

%  \item Which other rule-set can be applied to the current formula~? How does this rule-set behave with another rewrite-order~?

%  \item Which assumptions are generated by the rewrites on the current formula~?

%  \item Which other problem could match the model of the current calc-head~?

%  \item Which other method's guard could match the model of the current calc-head~?

%  \end{itemize}

Separate design considerations about the Browser Dialog see chap.\ref{WN-add-BrowserDialog}.

%............................................................+++WN060324

\end{itemize}

%For an in-depth discussion of the Knowledge Browser, see \cite{AG:thesis} and section \ref{AG:BrowserDialog} on p.\pageref{AG:BrowserDialog}.

\begin{figure}[htb]

\centerline{\includegraphics[width=\textwidth, keepaspectratio=true]

{fig/GK-sysdesign_seeheim}}

\caption{Design based on the Seeheim model and showing the separation of

browsing the knowledge and calculating}

\label{fig.sysdesign_seeheim}

\end{figure}

\footnote{End of copy from \cite{AK04:thesis} p.61-62.}

% GK070313- tag for quicksearch END

%WN050518---AK.p.61-62->isac-ADD--------END---please don't remove this line

%WN050518---AK.p.57-58->isac-ADD--------BEGIN---please don't remove this line

\footnote{Begin of copy from \cite{AK04:thesis} p.57-58.}

\section{Location of the Dialog Guide}\label{AK:DESIGN:SYSTEM:DISTRIBUTE:dialog}

With at least two machines involved - the user's computer with the

Worksheet and the server with the Math engine - the question where

to put the Dialog Guide remains. The Dialog Guide accesses the

Math Engine, the Worksheet and the User Model frequently. For

simplicity, mobility, security and centralisation reasons, the

User Model cannot reside on the user's machine. The same is true

for the Dialog Guide. The Dialog Guide with the persistent data of

the User Models could run on the server together with the Math

Engine or on an other server of his own. The Dialog Guide is

designed with the ability to run on a machine of its own in mind.

The final decision on the location of the Dialog Guide will be

based on tests with the prototype implementation.

%WN060324--->thesis.ML-----------------END---please don't remove this line

\footnote{End of copy from \cite{AK04:thesis} p.57-58.}

%WN050518---AK.p.57-58->isac-ADD--------END---please don't remove this line

%WN050518---AK.p.65-67->isac-SDD--------BEGIN---please don't remove this line

\footnote{Begin of copy from \cite{AK04:thesis} p.65-67.}

\section{The Interfaces to the WorkSheet Dialog Component}\label{AK:DESIGN:SYSTEM:ARCH:interface}

Data exchanged at the interfaces of the WorkSheet Dialog component include:

\begin{description}

\item[Examples to be started] When initialising the Dialog to

moderate a process of calculation, the starting point can be an

empty worksheet or an Example from the example collection. In case

of starting from an Example, the Example has to be passed to the

Dialog. \item[Notifications about updates in a calculation] With

present technology, calculations done by the Math Engine may take

longer than the average user would wait. Moreover, response times

are not easily predictable, so waiting for a call to return would

block the WorkSheet Dialog - hence user interaction  - for too

long a period of time. Therefore calls to the Math Engine return

immediately, with asynchronous notifications being sent when the

Math Engine completes a request. In addition to continuous

attention to the user, this approach allows for several users

watching one and the same calculation on their respective

Worksheets and being even notified of updates in the calculation

requested by other users. For efficiency reasons, the update

notifications contain hints about which parts of the Calc Tree may

be affected by the update. These notifications are passed from the

Math Engine to the Dialog and from the Dialog to the Presentation

Layer. \item[The calculation itself] The Dialog needs access to

the Calc Tree stored in the Math Engine and passes a filtered

version of the tree to the Worksheet for display. The Dialog

cannot understand the mathematical meaning of Formulas, but is is

interested in identifying Tactics. It is the Tactics which the

user is learning to apply and the WorkSheet Dialog has to provide

appropriate user guidance for. \item[Calc Head] As with the Calc

Tree during the Solving Phase, during the Specifying Phase a Calc

Head has to be shared between Math Engine, WorkSheet Dialog and

Worksheet. \item[Notifications about user requests] The Dialog has

to be informed about actions the user triggers on the Worksheet.

The Dialog in turn translates the user actions into internal state

changes or requests to the Math Engine. \item[Requests to the Math

Engine] As the Math Engine stores the only instance of the Calc

Tree significant to further processing, all manipulations of the

tree have to be done by the Math Engine. Request to edit the

calculation originating from the user are processed by the

WorkSheet Dialog and execution is requested from the Math Engine.

\item[Information touched] Records of the user's interaction with

\isac{}'s knowledge are kept in the User Model and abstracted to

\isac{}'s view of the user's knowledge and abilities. The User

Model is informed about every interaction of the user with the

calculation or the Knowlegde Base. The User Model's abstraction is

in turn queried by the WorkSheet Dialog to decide on details of

user guidance. \item[Dialog Atoms] Information about the Dialog

Atoms involved in user interaction is passed to the User Model to

record not only the fact that the user interacted witch certain

parts of knowledge but also the nature of the interaction.

\item[User settings] The user's preferences about the way he

wishes to be guided have to be communicated to the WorkSheet

Dialog, whereas preferences about the visual appearance of the GUI

are communicated directly to the Worksheet.

\end{description}

\footnote{End of copy from \cite{AK04:thesis} p.65-67.}

%WN050518---AK.p.65-67->isac-SDD--------END---please don't remove this line

%WN050518---AK.p.67-76->ADD-----------BEGIN---please don't remove this line

\footnote{Begin of copy from \cite{AK04:thesis} p.67-76.}

\section{Controlling the Course of Interaction}\label{AK:DESIGN:DIALOG:INTERACT}

The WorkSheet Dialog is responsible for guiding the user the way to obtaining a solution to a problem.

\subsection{Dialog Phases}\label{AK:DESIGN:DIALOG:INTERACT:phase}

On a coarse level, interaction goes through several phases with a fixed sequence, independent of the particular problem being solved (UR.\ref{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 WorkSheet Dialog 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.

With the Dialog Phases and their relationships becoming more complex in future development, providing separate sub-classes for the Dialog's behaviour in different states may be appropriate, as described in the State pattern \cite{Gamma95}.

\subsubsection{Initialising}

To start interaction, the WorkSheet Dialog has to establish

connections with the components it interacts with, a Worksheet

representing the Presentation Layer and a Math Engine representing

the application (UC.\ref{START:contact-math}). In addition to

that, the WorkSheet Dialog needs information about the user it

deals with, to be able to adapt its behaviour accordingly

(UC.\ref{START:ident-user}, UR.\ref{COMMON:USERS:multi}). Only

after being provided with a CalcHead to act upon, optionally

filled in with a Formalization of a pre-defined Example

(UC.\ref{START:from-example}), the Dialog can enter the

Specification Phase.

\subsubsection{Specifying}

The goal of this phase is to gather enough - and consistent -

information to start solving (UC.\ref{SPECIFY}). During this

phase, the user can add information to a CalcHead, in arbitrary

order. After every item added, the CalcHead is checked with the

Math Engine for consistency and completeness

(UC.\ref{SPECIFY:check}, UR.\ref{DIALOG:GUIDE:model-feedback}).

Requests for help entering items cannot be answered by the WorkSheet Dialog because of lacking mathematical knowledge. Such requests are passed to the Math Engine, if allowed by the user's settings. The Specifying Phase can be finished only after the CalcHead is confirmed being complete and consistent by the Math Engine (UC.\ref{SPECIFY:COMPLETE:model}).

\subsubsection{Solving}

To enter the Solving Phase, a valid CalcHead is required.

Consequently, the mathematical situation initially described by the CalcHead is transformed towards a situation called result. The transformation is performed in steps (UR.\ref{COMMON:CALCDATA:stepwise}) which are recorded in a CalcTree (UR.\ref{COMMON:CALCDATA:calc-tree}). 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 (UC.\ref{SOLVE:MANUAL:FORMULA:replace}). The transformations are not performed by the WorkSheet Dialog 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 (UR.\ref{COMMON:CALCDATA:correct}). Note that the WorkSheet Dialog 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 section \ref{AK:DESIGN:TECHUI:DIALOG:atom}).

\paragraph{}

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.

\subsubsection{Solving Subproblems}

Subproblems are calculations within calculations; in principle, they do not differ from top-level problems.

\begin{figure}[htb]

\centerline{\includegraphics[width=\textwidth, keepaspectratio=true]{fig/AK-dialog_phases}}

\caption{A state machine for the Dialog Phases}

\label{fig.states}

\end{figure}

\subsection{Dialog Atoms}\label{AK:DESIGN:DIALOG:INTERACT:atom}

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 WorkSheet Dialog's interactional behaviour (UR.\ref{DIALOG:FLEX:configure}), we aim at developing an abstract language with Dialog Atoms (UR.\ref{DIALOG:FLEX:atomic})as part of the vocabulary. The WorkSheet Dialog could contain an API for programming its behaviour, with a lower-level interface implementing an Interpreter pattern \cite{Gamma95} for Dialog Atoms and a high-level interface implementing the Strategy pattern.

Let us quote \cite{wn:diss} again:

\begin{quotation}

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$.

\begin{enumerate}

\item \label{putres} given \currf, input the next formula \res

\item \label{fillres} given a partial \currf (supplied by \sisac), complete \currf such that it is a derivation of \currf

\item \label{puttac}given \currf, input a tactic \tac to be applied to \currf

\item given \currf, select \tac from a list (supplied by \sisac) to be applied to \currf

\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

\item given \currf, \tac, and a partial \res, complete \res such that it is the result of applying \tac to \currf

\item given \currf and \res, input \tac such that \res is the result of \currf applying \tac

\item given \currf and \res, select \tac from a list (supplied by \sisac) such that \res is the result of \currf applying \tac

\item given \currf, \res and a partial \tac, complete \tac such that \res is the result of \currf applying \tac

\end{enumerate}

\end{quotation}

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.

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 WorkSheet Dialog tries to provide symmetric Dialog Atoms and make use of this symmetry in the implementation.

\section{Sharing the Calculation with other Components}\label{AK:DESIGN:DIALOG:SHARE}

\subsection{Representing the Model and the Specification}\label{AK:DESIGN:DIALOG:SHARE:spec}

A Model (UR.\ref{COMMON:CALCDATA:formalization}) storing lists of formulas called Given, Find, Where, Relate and a Specification (UR.\ref{COMMON:CALCDATA:specification}) storing identifications of a Theory, a Method and a Problem comprise all data necessary to specify a calculation to the Math Engine. In the \isac{} system, this information is called a CalcHead, indicating that every calculation (a subproblem, too) has a header specifying a starting point. Once the Solving Phase of a calculation is started, this information does not change any more.

\subsection{Representing the Path to the Solution}\label{AK:DESIGN:DIALOG:SHARE:solve}

The path to the result is represented by a tree-like structure (UR.\ref{COMMON:CALCDATA:calc-tree}), alternating formulas and tactics (UR.\ref{COMMON:CALCDATA:tactic}). There is always exactly one Tactic being applied to a formula. In the course of calculating a result, the structure grows as new formulas are added by the user or the Math Engine.

\subsection{Treating Subproblems}\label{AK:DESIGN:DIALOG:SHARE:subprob}

A subproblem is a calculation within a calculation. As such, every subproblem is preceded by a CalcHead. Once specified by a CalcHead, a subproblem could be treated as a calculation of its own and solved independently of the enclosing calculation.

Two possibilities for treating subproblems and feeding their results back into the main calculation were explored.

\subsubsection{Independent CalcTrees}

Every subproblem could be stored in an independent CalcTree. This would emphasise the fact that a subproblem can be solved independently of the enclosing problem and reflect that fact in the data structure used. As an advantage, every calculation would have exactly one CalcHead and exactly one CalcTree associated with it, representing the data involved in the Specifying Phase and the Solving Phase, respectively. This would allow for clearly separating the CalcHead from the CalcTree thus reflecting the separation of the Specifying Phase from the Solving Phase in the storage of data. On the other hand, such an approach would complicate feeding back the results of a subproblem into the enclosing calculation.

\subsubsection{One Common CalcTree}

As an alternative, all data of a calculation, including associated subproblems, could be stored in a single data structure, subproblems being stored as branches of the tree. While this approach reflects the fact that a subproblem is part of the enclosing calculation, the distinction between Specifying Phase and Solving Phase becomes blurred, as the CalcHeads specifying subproblems must be stored within a CalcTree. Having subproblems tightly integrated into the enclosing calculation eases using their results.

This approach was chosen for implementation, in part due to the fact that the already-implemented Math Engine stores calculations in a single tree.

\subsection{Accessing Calculation Data}\label{AK:DESIGN:DIALOG:SHARE:access}

\subsubsection{CalcHead}

With the CalcHead having a fixed number of fields, all members can be accessed directly. Wherever components share a CalcHead, the object itself is referenced or passed.

\subsubsection{CalcTree}

For accessing data in the dynamically growing CalcTree, the Iterator pattern \cite{Gamma95} was chosen for its main advantage of hiding the internal representation of the data accessed.

Several reasons suggested hiding the internal representation:

\begin{itemize}

\item An Iterator can serve the additional purpose of referencing elements of a calculation.

\item An Iterator is likely to be a much smaller object than the calculation it points into.

\item Several components residing on different machines imply having to pass information about the calculation across the network. Using compact Iterators instead of the entire calculation would make efficient use of network bandwidth and save computing time needed for serializing large objects.

\item At an early stage in design, the final structure of a calculation as stored in the Java-implemented part of \isac{} was not yet decided upon. Using Iterators made it possible to start development of other components without knowing which data structure would be eventually implemented.

\item There was much debate about runtime efficiency versus ease of development in representing a calculation. Hiding the internal representation would allow for implementing efficient data structures at a later time without having to redesign the entire system.

\item Neither the WorkSheet Dialog nor the Presentation Layer need to know how a calculation is actually stored. On the other hand, both components are interested in the structure of a calculation as presented to the user. Using Iterators would allow traversing a calculation in a user-oriented manner independent of the actual implementation.

\end{itemize}

\subsection{Communicating Changes in the State of Calculation}\label{AK:DESIGN:DIALOG:SHARE:change}

As a component sitting between the Application and the Presentation Layer, one of the tasks of the WorkSheet Dialog is to propagate information about changes or events in one component to the other.

The WorkSheet Dialog intercepts the flow of information and modifies it by implementing \isac{}'s logic of user-interaction.

\subsubsection{Wrapper-based Design}

One approach is wrapping the objects representing the calculation

- the Calculation Tree and associated objects - into objects with

the same interfaces but different behaviour, following the

Decorator pattern \cite{Gamma95}. This way, the WorkSheet Dialog

can filter information considered not appropriate for being

presented to the user by simply removing these data from the

representation accessible to the Presentation Layer. For an

example, if the user is not interested in the Tactics transforming

one formula into another, the Tactics simply do not show up in the

representation of the calculation seen by the Presentation Layer.

This has the advantage of simplicity - the Presentation Layer and

the Application need not consider filtering taking place or even

know about filtering at all. Moreover, the same interface can

still be used if one would want a system without the intervention

of a WorkSheet Dialog for direct communication between the

Application and the Presentation Layer.

\subsubsection{Event-driven Design}

In addition to data representing the state of calculation, there is data representing changes in time. Many of these changes occur asynchronously at unpredictable intervals - such as interactions of the user - or with considerable unpredictable delay after the event that that triggered them - such as results of a lengthy transformation becoming available. This sort of changes is communicated through event messages, with objects interested in such notifications registering as Observers \cite{Gamma95} with sources of events. The main sources of events are the Presentation Layer for user actions and the Application for new information about the calculation becoming available. The WorkSheet Dialog intercepts and filters these messages using the Mediator pattern \cite{Gamma95}.

\section{Configuring the User-Interface}\label{AK:DESIGN:DIALOG:UI}

The WorkSheet Dialog and the Presentation Layer have to cooperate closely in user interaction. Consider a button on the screen triggering some action. It is the Presentation Layer's responsibility to render the button and to notice the user clicking it. It is the WorkSheet Dialog's responsibility to decide whether the user is allowed to request such action and to trigger appropriate action in the Application.

The division is not always so clear-cut. Consider internationalisation of the user-interface (UR.\ref{COMMON:MISC:i18n}): Is it the Presentation Layer, which is responsible for rendering in general and the language environment, that decides which text to set on the button? Or is it the WorkSheet Dialog, which knows the meaning of the action triggered by the button? For the following considerations, we will stick to the example of the button.

\subsection{The Presentation Layer in Control}\label{AK:DESIGN:DIALOG:UI:present}

If the Presentation Layer controls every aspect of a button, such as visual appearance, placement on screen and the actions triggered, everything seems easy.

Problems arise if we consider buttons which are needed only in special contexts. A button asking for the next Tactic to be applied to a formula does not make sense during the Specifying Phase, where no Tactics occur.

We could show the button all the time, with the WorkSheet Dialog

simply ignoring requests when not appropriate. This has the

disadvantage of confusing the user with lots of buttons which can

be clicked but make no sense in the current context.

We could show buttons only if clicking them makes sense. If the

Presentation Layer were to solve this problem, it would need

information about the current phase of the dialog. While this may

seem feasible, in other situations the applicability of the button

might depend on the user's role or privileges, or on the user's

level of expertise, which in turn might change even during a

session. Especially if buttons depend on didactic strategies, this

involves knowledge which has nothing to do with presentation but

is clearly part of the WorkSheet Dialog.

\subsection{The WorkSheet Dialog in Control}\label{AK:DESIGN:DIALOG:UI:dialog}

If we put the WorkSheet Dialog in control of the buttons, it

becomes easy to solve problems with context, but this would

require the WorkSheet Dialog to care about internationalisation

and visual appearance, which is out of interactional context and

should be left to the Presentation Layer.

\subsection{Splitting up Responsibilities and Providing for Interaction}\label{AK:DESIGN:DIALOG:UI:split}

It seems best to have the various aspects of a button controlled

by the component which possesses the information necessary to do

so.

While the Presentation Layer should control every visual aspect of

a button such as text, shape and placement on screen, the

WorkSheet Dialog should control the context in which the button

appears and the action it triggers. See \cite{sliski} for the

discussion of a related problem.

First attempts aimed at providing means for the WorkSheet Dialog to enable or disable buttons otherwise controlled by the Presentation Layer. In the meantime, the goal changed to having the WorkSheet Dialog control the creation and destruction of elements of user-interaction as well.

The WorkSheet Dialog creates a element of user-interaction by providing an identification of the action it triggers. The presentation layer need not even understand the meaning of the action, it uses the identification merely for notifying the WorkSheet Dialog which action has been triggered by the user. In addition to that, the WorkSheet Dialog provides the Presentation Layer with hints about the context of the user interaction, such as whether the action relates to a single formula or the user's session as a whole. The Presentation Layer can use this information to choose an appropriate visual representation. Moreover, the the WorkSheet Dialog does not even request the trigger to be a button. It requests that a means for the user to trigger a request be created and it is left to the design of the Presentation Layer to offer a button, a menu item or both. This approach bears similarites to the Factory pattern \cite{Gamma95}, but the created object remains with the Presentation Layer and is not passed back to the WorkSheet Dialog.

\section{Obtaining and Storing Configuration Data}\label{AK:DESIGN:DIALOG:CONFIG}

Much of the WorkSheet Dialog's behaviour can be parameterised (UR.\ref{DIALOG:FLEX}), and many of these parameters are individual to a user (UR.\ref{DIALOG:ADAPT}). Moreover, some of the parameters are modified by the system itself during a session (UR.\ref{DIALOG:ADAPT}) based on data collected (UR.\ref{DIALOG:PROFILE}).

\subsection{The User Settings}\label{AK:DESIGN:DIALOG:CONFIG:settings}

By user settings we denote preferences on aspects of the system set by the user (UR.\ref{DIALOG:FLEX:configure}, UR.\ref{DIALOG:FLEX:info}), such as amount of data shown, levels of difficulty or customisations of the visual appearance of the program. As these settings do not pertain only to the WorkSheet Dialog but also to other parts of the system, they will be managed outside the WorkSheet Dialog. It is to be noted that this information does not change very often, so efficient processing is not an issue.

\subsection{Permissions and Security Issues}\label{AK:DESIGN:DIALOG:CONFIG:secure}

With \isac{} being developed as groupware (UR.\ref{COMMON:USERS:groups}), special attention has to be paid to the fact that settings will be set not only by the individual user, but also by privileged persons such as course administrators (UR.\ref{COMMON:USERS:roles}). In addition to that, changing some of the settings may be subject to restrictions (UR.\ref{DIALOG:RESTRICT:individual}) depending on the role of the user. It is assumed that reconciliation of contradictory settings and security issues have already been resolved by user management and that the WorkSheet Dialog has access to the settings in effect for the current session.

\subsection{The User Model}\label{AK:DESIGN:DIALOG:CONFIG:model}

As required in UR.\ref{DIALOG:ADAPT}, the WorkSheet Dialog will adapt to the assumed knowledge and abilities of the user. Decisions about which information to show and which actions to take will be based on an internal abstraction of the experience the system had with the user, the User Model.

The User Model is notified about every interaction between user and mathematical knowledge and information about the knowledge involved (UR.\ref{DIALOG:ADAPT:knowledge}). The user's performance (UR.\ref{DIALOG:ADAPT:perform}) is recorded together with information about the context of the interaction, i.e. the Dialog Atom used in the interaction. For efficiency reasons, data is stored as statistical digest rather than as log. The User Model is accessed frequently, at least once per interaction both for query and for recording the outcome, and logging every event would grow the amount of data processed unmanageable very soon.

Note that the User Model gathers and processes the data, but is not aware of their meaning - knowledge items and Dialog Atoms are processed as identifying numbers. Interpretation of the data is left to the components which use them, i.e. the WorkSheet Dialog and, in the future, the Browser Dialog.

Abstractions on a higher level than the presently used statistics could be added in the future, as cooperations of \isac{} in the field of didactics could provide abstract measures e.g. for a user's familiarity with a topic. In any case, the User Model provides descriptive information about the user and decisions about further actions are always taken by the WorkSheet Dialog.

As the user's history has to be regarded as well (UR.\ref{DIALOG:ADAPT:history}), the User Model will be stored across sessions along with the user's settings.

\footnote{End of copy from \cite{AK04:thesis} p.67-76.}

%WN050518---AK.p.67-76->ADD-----------END---please don't remove this line

%WN000705---summerterm06------------BEGIN---please don't remove this line

% GK070313- tag for quicksearch START

\section{Browser Dialog}\label{WN-add-BrowserDialog}

The browser dialogs are responsible to process the informations coming from the user interactions on the knowledge browsers (see chap.\ref{WN-add-Knowledge-Browser}) and also for gathering information from the knowledge base or (indirectly over the worksheet dialog) from the math engine.

There is no possibility for the learner to manipute the data presented by the knowledge browsers while using \sisac{}'s tutoring-system. The only way to change data from the KE-store is via \sisac{}'s authoring-system.

There are two sources where the browser dialogs fetch their information:

\begin{enumerate}

\item When Data has to be fetched from the KEStore (chap.\ref{ADD:ke-store}) it solely depends on the UserModel (the membership to a course, a session within a written examination, etc.) how much informationen if any can be retrieved form the KEStore.

\item Data from the MathEngine (chap.\ref{WN-add-Bridge}) which concerns a context to a certain calculation. The context gives a concrete interpretation of the meaning of an item of the KEStore. The user can choose if he wants to switch the context on or off. When the context is switched off only the static information from the KEStore will be presented.

\end{enumerate}

In analogy to the worksheet dialog the browser dialog has a central role in \sisac{}'s architecture following the 'Seeheim Model' (see sect.\ref{AK:DESIGN:SYSTEM:DISTRIBUTE:dialog}).

There is one dialog for one browser (see chap.\ref{WN-add-Knowledge-Browser}). But the functionality of the four browsers is more different than their layout shows. Thus there is a more sophisticated (subclass-)relation between the dialogs than betwenn the browsers. The dialog can be

\begin{itemize}

\item an example browser dialog, which is responsible for starting the execution of examples

\item a knowledge browser dialog, which is responsible for displaying the respective parts of the math knowledge; thus there is a

  \begin{itemize}

  \item theory dialog

  \item problem dialog

  \item method dialog

  \end{itemize}

\end{itemize}

The dialog has to handle links from each browser to each other. The dialogs are created at the same time at setup of the session.

\subsection{Browser Dialog and Worksheet Dialog:} There is four browser dialog for one session, while there may be $0\dots n$ worksheet dialogs (according to the number of worksheets opened). The relations between the two kinds of dialogs are discussed in \ref{WN-add-BDialog-WSDialog}.

\subsection{Survey on requirements}\footnote{This is a survey from an early design phase documented in \cite{AG:thesis} p.42}

 The \emph{browser-dialog} is the peer for the browser within the

 dialog and gathers the informations for the request. Depending of the

 type of request, it contacts the \emph{KE-Store} and/or the

 WorkSheet-dialog. Afterwards, the informations are filtered depending

 a users actual permissions and duties. It is possible, that pages are

 blocked as a whole --- e.g. if an example is not accessible before an

 other one is solved. Alternatively, some fields might be blocked. e.g.

 if a learner has to solve a problem while performing a test, he might

 see all available problems -- but the dialog will suppress the fields

 which tell the user if (and why) an actual problem does not fit.

 The permissions are gained from different sources.

 \begin{itemize}

 \item The course-designer may define a group of users which may

   access an example.

 \item The course-designer may define preconditions before a example is

   displayed (e.g. a date, or a set of examples to solve first)

 \item The course-designer may set the user to use a ``temporary

 environment'' which alters all permissions to a set of

 \emph{KE-Objects}(e.g. while an exam)

 \item The dialog-layer maintains a user-history to find out which

%WN                 ? dialog-state   ~~~~~~~~~~~~

   examples and parts of the knowledge are already visited and solved.

 \end{itemize}

 The informations about a user are stored within the user-model.

 Informations like the history are not only gathered and used by the

 browser-dialog but by the whole dialog-layer.

\section{Dialog Guide and User Model}

The term 'Dialog Guide' addesses an abstraction which comprises both, the Worksheet Dialog and the Browser Dialog. The Dialog Guide shall be subject to simple implementation and parameterization of 'intelligent dialog behaviour' by 'dialog authors' in the future.

There is a detailed discussion in sect.\ref{WN-add-DG-UserModel} p.\pageref{WN-add-DG-UserModel} about the relations beetwenn the dialoges an the UserModel within the context of session management.