\documentclass[a4wide]{report}

 \input{preamble}

 \title{Context-based Access to \isac{}'s Knowledge Base}

 \author{Georg Kompacher}

 \date{$\today$}

 \begin{document}

 \begin{titlepage}

 \fontsize{12pt}{16pt}\selectfont

 \begin{center}

 \vspace*{10mm}

 \textbf{\LARGE{Context-based Access to\\

         \isac{}'s Knowledge Base}} \\

 \medskip

 \vspace{15mm}

 {\large Georg Kompacher} \\

 \vspace{1mm}

 {\large Student at the Institute for Software Technology (IST), 

 Graz University of Technology, Inffeldgasse 16b, A-8010 Graz, Austria.}

 {\large \verb,kompacher@student.tugraz.at,}

 \vspace{10mm}

 {\large Bachelor Thesis}

 \vspace{10mm}

 \end{center}

 \begin{center}

 \vspace{5mm}

 \begin{figure}[htb]

 \centerline{\includegraphics[width=0.2\textwidth, keepaspectratio=true]{fig/tug}}

 \end{figure}

 \vspace{5mm}

 Graz, April 2007 \\

 \end{center}

 \vspace{30mm}

 {\small

 \begin{tabular}{ll}

   Supervisor:    & Univ.Prof. Dipl.-Ing. Dr.techn. Franz Wotawa \\

   Project Coordinator: & Dr.techn. Walther Neuper \\

 \end{tabular}

 }

 \newpage

 \def\changemargin#1#2{\list{}{\rightmargin#2\leftmargin#1}\item[]}

 \let\endchangemargin=\endlist

 {

 \verb' '\\

 \vspace{20mm}

 \verb' '\\

 \begin{center}

 {\bf Abstract: }

 \end{center}

 This is a Bachelor's thesis done within the \sisac{}-project. The project

 aims at a 'transparent single-stepping system for applied mathematics'.

 The task assigned within the project comprised work on the (detailed)

 design, on implementation and documentation.

 The concern of the thesis' task is to make the knowledge transparent to

 the user. In particular, the user is enabled to get access to \sisac{}'s

 knowledge by viewing the context of a formula at a certain step of a

 calculation. The design had to take into account, that the knowledge

 presented to the user consists of two parts: (1) a static part from the

 knowledge and (2) a dyamic part calculated by the mathematics-engine for

 the specific context. The implementation provides the presentation of

 the context-related knowledge within three windows, one for theory data,

 one for problems and one for methods.

 The thesis considers some general aspects of presenting math knowledge

 as discussed in the area of 'user-interfaces for interactive theorem

 provers', describes the respective user requirements for \sisac{}, that

 is, the requirements of the learner doing a calculation. The main part

 comprises the architecture and also some details on the final

 implementation.}

 \end{titlepage}

 \tableofcontents

 % INTRODUCTION - BEGIN

 \chapter{Introduction}

 \section{About the \isac{}-Project}

 The \sisac{}-project is a development and research project at the

 Institute for Software Technology (IST) of the University of Technology in Graz. 

 It establishes a new technology for a novel kind of interactive and web-based transparent software for applied mathematics. The interactivity is given by the possibility to browse thru the knowledge base and the transparency is given by the ability of the user to see what knowledge is used and how the knowledge is used to solve a problem. So it is possible so solve problems, while \sisac{} can provide help and also additional information at every step of a calculation.

 The kernel of \sisac{} is a math-engine which is based on the theorem prover Isabelle which is written in SML while the rest of \sisac{} is written in Java \cite{JPL}.

 % isac is interactive - that means that the user can require a lot of knowledge - lookup from the current context (solve phase: step in a calculation, specify phase: model instantiated)

 \section{The Development Phase in Summer 2006}

 The concern of the development phase in the summer 2006 was to make the provided knowledge more transparent to the user. At this time the \sisac{}-Team consisted of the following members: Walther Neuper as the project coordinator, Alan Krempler as our design menthor and as developers Robert K\"onighofer, Nebojsa Simic and me.

 The first phase of the development process was shaped by intensive teamwork. After the new team members had read the existing code of \sisac{}, the design for the forthcoming development phase was discussed. Afterwards each member got his own task assigned, whereby every member was responsible for its own part, but that did not mean that only that member was allowed to modify his assigned parts.

 \section{Description of my Task}

 My task was it to make the presentation of the context-related knowledge within three windows, one for theory data, one for problems and one for methods, possible. More precisely my work comprised the following things:

 \begin{itemize}

 \item{Develop the data-structures to store the contexts.}

 \item{Modify the parser to build the contexts from XML files.}

 \item{Develop and modify the dialogs and also the knowledge browsers to make the presentation of context-related knowledge possible.}

 \end{itemize}

 This task belongs to the research field of 'user-interfaces for interactive theorem provers'. This is a research field since theorem provers became successful by more interactivity \cite{thiery92}. \sisac{} is based on the theorem prover Isabelle \cite{Nipkow-Paulson-Wenzel:2002}; for Isabelle there is a user-interface \cite{aspinall:proof-gen}, which has been adapted from a generic version.

 This research area gives some general hints for \sisac s user-interfaces; however, the major differences between \sisac{} and a theorem prover do not allow a direct transfer of design elements or of tools.

 % INTRODUCTION - END

 % USER REQUIREMENTS - BEGIN

 \chapter{User Requirements}

 \sisac{} is designed as a 'transparent system' as it provides access to all the know\-ledge the system requires for (automated) problem solving. The knowledge is structured within a 3-dimensional universe of mathematics (see \cite{wn:diss} for further information) and split into the following three kinds of knowledge:

 \begin{itemize}

 \item{Theories}

 \item{Problems}

 \item{Methods}

 \end{itemize}

 Needless to say that the knowledge has a highly complex structure, and it was one of the main goals of the developing phase in the summer of 2006 to make \sisac{} more transparent to help the student not to get lost in this structure. Principally, there are two ways to access the knowledge: Firstly, access along the structure inherent to the respective knowledge (see sect.\ref{WN-urd-KEStore}) and secondly access from a concrete calculation, where the knowledge is required for solving the problem (see sect.\ref{GK-urd-context-rel}). These two kinds of access are described below.

 \section{Knowledge-related views}\label{WN-urd-KEStore}

 As example collections (respective requirements see sect.8.2, sect.8.3 and sect.8.4 in \cite{isac:all}) are very close to the other three parts of knowledge (theories, problems and methods) they are included in this section.

 {\bf\UR{Each element of the knowledge belongs to either theories, problems or methods, or to the example collection.\label{UR.WN-thy-pbl-met}}}

 The elements of belonging to theories are

 \begin{itemize}

 \item theorems.

 \item rule sets, i.e. sets of theorems or other rule sets, which are applied as long as they can be applied to a certain formula.

 \item rewrite orders which are required to terminate rule sets which contain theorems on commutativity etc.

 \item computations involving sml-code (the only exception to rewriting).

 \item html data, only containing explanations.

 \end{itemize}

 {\bf\UR Examples, theories, problems and methods all have a

 hierarchical structure\label{UR-hierarchy}} and each element of

 the knowledge base has a unique position in this hierarchy.

 {\bf\UR{Each element of the knowledge base is displayed in the related brow\-ser.\label{UR.WN-thy-pbl-met-browser}}} This requirement has to be met in particular, if such an element is referenced by a link from another browser: wherever such a link is located, the element is displayed in the browser it belongs to, a theory-element in the theory-browser etc.

 {\bf\UR{Links can go from any element to any element.\label{}}} That means, an explanation for a problem can have a link to a method solving it, or to a theorem (in a theory) important for this problem; an explanation for a theorem can have a link to a problem, which uses the theorem in a certain way, etc.

 {\bf\UR There are specific links which start an example.\label{}} Such a link may be located in any part of the knowledge; if the link is activated, the respective example is displayed in the example-browser (UR.\ref{UR.WN-thy-pbl-met-browser}) together with the example location in the example hierarchy (UR.\ref{UR.WN-thy-pbl-met-hier-location}) {\em and} a worksheet is opened for this example.

 {\bf\UR Links outside \sisac's knowledge base open the standard browser.\label{}} i.e. links within the knowledge base may point anywhere, and if the destination is outside \sisac's knowledge, it is displayed outside \sisac, too.

 {\bf\UR{An element is always displayed togehter with the respective location in the hierarchy.\label{UR.WN-thy-pbl-met-hier-location}}} This requirement has to be met in particular, if the element is displayed following a link (indenpendently, from which browser).

 {\bf\UR{Each element has a certain position in the respective hierarchy.\label{UR.WN-thy-pbl-met-hierarchy}}} The hierarchy is the means for systematic search by the user. This does {\em not} mean, that this position can serve as a unique identification over time, see UR.8.6.4 in \cite{isac:all}.

 {\bf\UR{With each element in the knowledge base, explanations can be stored.\label{UR-explanation}\label{DIALOG:GUIDE:description}}}

 Every element in the Knowledge Base can provide explanations illustrating its meaning, giving theoretical background information, referencing related topics or giving examples of use. See sect.7.1 and also UR.8.6.2 in \cite{isac:all}.

 \section{Context-related views}\label{GK-urd-context-rel}

 The context is given by the state of a calculation (the so-called 'calc-state') on a Worksheet. One case is displaying a method with the tactic marked which just has been applied in a calculation (this is well-known from debuggers). And there are other dynamic views into the knowledge base.

 \paragraph{Context to all parts of the math-knowledge}

 {\bf\UR{A context is the current position on the worksheet last touched.}\label{}} The formula at this position is highlighted.

 {\bf\UR{Usually there is a context to any of the 3 parts of the math-knowledge for a position. See also UR.\ref{UR.WN-no-worksheet-no-context} and UR.\ref{UR.GK-may-be-no-context}}\label{}}

 {\bf\UR{\sisac{}'s use of math knowledge can be watched by the user.\label{DIALOG:GUIDE:dynamic-view}}} The user can look up the elements of the knowledge base currently used by \sisac{} to do a certain step in a calculation. This includes showing

 \begin{itemize}

 \item{tactics used in the calculation in their context in the knowledge base; particularly interesting are rewrite-tactics. The context to the calculation allows to display the rewrite, the assumptions generated, the rewrite-order used etc.}

 \item{methods being applied to solve the current problem with indication of the tactic being currently applied, of the method's guard etc.}

 \item{problems currently being solved in their context in the hierarchy of problems. This particularily helpful just before and after having \sisac{} refined a problem.}

 \end{itemize}

 {\bf\UR{On request, \sisac{} provides additional information on parts of the calculation.\label{DIALOG:GUIDE:detail}}\\}

 Additional information in a calculation can be provided at any time on request of the learner. This feature comprises more detailed views onto the calc-state, as well as explanations according to the following table:

 \begin{center}

 \begin{tabular}{l l l}

 {\tt 'detail'} on & element & yields\\

 \hline\hline

 whole formula  & //                & Assumptions\\

 whole formula  & //                & Tactic Applied\\

 whole formula  & //                & Intermediate Steps\\

 \hline\\

 {\tt 'detail'} on & calchead & yields\\

 \hline\hline

 specification  & theory            & file of the respective theory\\

 specification  & problem           & model instant. this problem\\

 specification  & problem           & inst. problem in the hierarchy\\

 specification  & method            & guard instantiated by the model\\

 specification  & method            & script in the hierarchy\\

 \end{tabular}

 \end{center}

 {\bf\UR{If there is no Worksheet open, then there is no context.}\label{UR.WN-no-worksheet-no-context}}

 {\bf\UR{There may be NO context for an element of the math-knowledge.}\label{UR.GK-may-be-no-context}} The reasons are specific to theories, problems and methods.

 {\bf\UR{The default setting for $<$Context On/Off$>$ is $<$On$>$}\label{}} - as soon as a Worksheet has been opened.

 {\bf\UR{If the knowledge browser is opened the first time and there is no context, it displays the element at the root of the respective hierarchy.}\label{UR.WN-init-no-context}}

 {\bf\UR{Any formula in a calculation has a context}\label{}} (with different details to different parts of the math-knowledge).

 {\bf\UR{The user can switch the context to a calculation on or off.}\label{}}

 {\bf\UR{The context of an element is displayed in the respective browser-window.}\label{}} This is analoguous to UR.\ref{UR.WN-thy-pbl-met}

 {\bf\UR{A context is displayed as soon as the window is activated}\label{}} or the respective button $<$Theories$>$ $<$Problems$>$ $<$Methods$>$ is pushed.

 {\bf\UR{The contents of the hierarchy can be filtered (due to a UserModel).}\label{}}

 {\bf\UR{The contents of the hierarchy remain unchanged during a session}\label{}} (SR: thus the hierarchy is loaded {\em once} at the beginning of a session)

 {\bf\UR{$<$Context On/Off$>$ is always available.}\label{}}

 \paragraph{Context to examples}

 {\bf\UR{The context of an example is the respective worksheet.}\label{}} If $<$Context On$>$ is set and a worksheet is brought to top, the respective example (i.e. the description of the example) is displayed in the example browser.

 {\bf\UR{A worksheet started by $<$New$>$ has no context.}\label{}} It is handled according to UR.\ref{UR.WN-init-no-context}

 {\bf\UR{An example may be displayed and NOT be allowed to calculate (according to the UserModel).}\label{}}

 \paragraph{Context to elements of theories}

 {\bf\UR{The context comes exactly from the current position on the worksheet.}\label{}}

 \pagebreak

 {\bf\UR{$<$To Worksheet$>$ is available if:}\label{}}

 \begin{enumerate}

 \item $<$Context on$>$ is selected {\em and}

 \item the worksheet on top is in the specify phase (and a calchead panel is open)

 \end{enumerate}

 {\bf\UR{$<$To Worksheet$>$ is {\em not} available:}\label{}}

 \begin{enumerate}

 \item if $<$Context off$>$ is selected

 \item if no worksheet is open

 \item if the worksheet on top is in the solve phase (and {\em no} calchead panel is open)

 \end{enumerate}

 \paragraph{Context to problems}

 {\bf\UR{The context of a formula to the problems is given by the headline of the calc-head on the next higher level in the calculation.}\label{}}

 {\bf\UR{The context of problem concerns the model of the current position and the modelpattern of a problem.}\label{}} Thus there is always a context, only exception is UR.\ref{UR.WN-init-no-context}

 {\bf\UR{If $<$Context off$>$ is selected, then $<$Refine$>$ and $<$To Worksheet$>$ are not available.}\label{UR.GK-context-off-ref-worksheet-na}}

 {\bf\UR{$<$Refine$>$ is available if $<$Context on$>$ is selected.}\label{}}

 {\bf\UR{$<$Refine$>$ is {\em not} available:}\label{}}

 \begin{enumerate}

 \item if $<$Context off$>$ is selected, as described in UR.\ref{UR.GK-context-off-ref-worksheet-na}

 \item if no worksheet is open

 \end{enumerate}

 {\bf\UR{$<$To Worksheet$>$ is available if:}\label{}}

 \begin{enumerate}

 \item $<$Context on$>$ is selected {\em and}

 \item the worksheet on top is in the specify phase (and a calchead panel is open)

 \end{enumerate}

 {\bf\UR{$<$To Worksheet$>$ is {\em not} available:}\label{}}

 \begin{enumerate}

 \item if $<$Context off$>$ is selected, as described in UR.\ref{UR.GK-context-off-ref-worksheet-na}

 \item if no worksheet is open

 \item if the worksheet on top is in the solve phase (and {\em no} calchead panel is open)

 \end{enumerate}

 \paragraph{Context to methods}

 {\bf\UR{The context of a formula to the methods is given by the headline of the calc-head on the next higher level in the calculation.}\label{}}

 {\bf\UR{The context of a method concerns the guard and the script.}\label{}} The script in the context shows the tactic which calculated the current position; the guard is matched with the model of the problem at the current position.

 {\bf\UR{$<$To Worksheet$>$ is available if:}\label{}}

 \begin{enumerate}

 \item $<$Context on$>$ is selected {\em and}

 \item the worksheet on top is in the specify phase (and a calchead panel is open)

 \end{enumerate}

 {\bf\UR{$<$To Worksheet$>$ is {\em not} available:}\label{}}

 \begin{enumerate}

 \item if $<$Context off$>$ is selected

 \item if no worksheet is open

 \item if the worksheet on top is in the solve phase (and {\em no} calchead panel is open)

 \end{enumerate}

 % USER REQUIREMENTS - END

 % ARCHITECTURAL DESIGN - BEGIN

 \chapter{Architectural Design}

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

 \footnote{Begin of updated parts from \cite{AK04:thesis} p.61-62.}

 %\subsubsection{Browsing the Knowledge Base}

 \section{The Dialogue Controllers}\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.

 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 the Seeheim model in \cite{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}

 As it was already discussed in UR.3.1.1 \cite{isac:all} the design took the designers of \sisac{} to 4 different browsers and to 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. An other subsystem comprises the worksheets with their corresponding 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 updated parts from \cite{AK04:thesis} p.61-62.}

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

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

 \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.18 in \cite{isac:all}) 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.19 in \cite{isac:all}) 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 from the KEStore.

 \item Data from the MathEngine (chap.20 in \cite{isac:all}) 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 \cite{Seeheim}).

 There is one dialog for one browser (see chap.18 in \cite{isac:all}). 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 between 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.

 \section{Context}

 To get the relation between the active formula from the active worksheet the worksheet dialog has to be contacted. The current position in the calculation tree has to be retrieved from the worksheet dialog. Then the math engine will be demanded to retrieve a context of that current position on the worksheet.

 To get a context-related view there are two components build together. One component is the context from the math engine and the second is the static part coming from the knowledge base. To merge them at the browsers the context objects need to store an identifier to the KE-store (KE-store-key) and to show the correct item in the hierarchy also an other key (hierarchy key) has to be stored inside of such a context. The math engine will give us the context in the xml-format and then the file is parsed and java-objects are build. As there are different context-types for every kind of knowledge (contexts to theories, problems and methods) will be sent to the right browser-dialog. The dialog has to decide, if the context has to be sent to the corresponding browser, which depends on the decision of the user, who can switch the context on or off.

 \section{Browser Dialogs and Worksheet Dialog}

 There are four browser dialogs 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}.

 \section{Survey on requirements}

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

 % ARCHITECTURAL DESIGN - END

 % SOFTWARE DESIGN AND IMPLEMENTATION - BEGIN

 \chapter{Software Design and  Implementation}\label{WN-sdd-BrowserDialogs}

 The figure Fig.\ref{fig.RK-browserdialoges} p.\pageref{fig.RK-browserdialoges} shows the class diagram for the browser dialogs which will be described in this chapter.

 \begin{figure}[htb]

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

 \caption{The class diagram for the browser dialoges}

 \label{fig.RK-browserdialoges}

 \end{figure}

 \begin{sloppypar}

 Each \verb'BrowserDialog' is responsible for the communication to the \verb'WSDialog's via the \verb'ContextProvider'-interface and also for the communication to the Browsers over Java RMI (Remote Method Invocation \cite{Pitt:2001:JRR}). Each \verb'BrowserDialog' gets information from the Browser by triggered \verb'UserAction's. In the other direction \verb'UIAction's are sent. Thes class has the following constructor:

 \verb'BrowserDialog(Session session)': This class must have the \verb'session_' locally stored to provide access to the active \verb'WorksheetDialog' for this \verb'BrowserDialog'. The \verb'Session' stores the \verb'WSDialogManager' and the \verb'WSDialogManager' itself stores the active \verb'WorksheetDialog'. The \verb'UserLanguage' is also read out from the \verb'session_' and stored locally.

 The \verb'BrowserDialog' offers the following public methods:

 \begin{itemize}

 \item{\verb'boolean notifyUserAction(IUserAction action)': This method is responsible for handling all actions coming from the browser stored in \verb'browser_frame_rmi_'. If the request has been accepted the return value is true otherwise it is set to false. The request can be denied if the user has no priviledges to do such a UserAction. To make this decision the BrowserDiaolg has to check up the \verb'UserSettings' and the \verb'UserModel'. But this would not lead to an exception. An exception is thrown if the current state of the \verb'BrowserDialog' cannot handle the \verb'UserAction' (\verb'DialogProtocolException').}

 \item{\verb'void presentContext(Context context)': This method belongs to the \verb'IContextPresenter' interface. It is called by the \verb'WorksheetDialog', if context changes have to be shown in the browser. This method checks the status of the member variable \verb'context_on_'. If \verb'context_on_' is set to false, the \verb'current_context_' won't change.}

 \item{\verb'void registerBrowserFrame(IToGUI browser_frame)': This method is called from the \verb'WindowApplication' to register the \verb'BrowserFrame' at the \verb'BrowserDialog'. After registering the \verb'BrowserFrame' the \verb'hierachy_' is sent as an \verb'UIActionOnHierarchy'.}

 \item{\verb'void sendCheckedContextToBrowser(Context context)': The Method is used when \verb'context_on_' is set to \verb'true'. Then the method checks the received context by use of the \verb'checkContext' method of the \verb'IContextProvider' interface. This interface returns again a context, which is sent to the \verb'BrowserFrame'.}

 \item{\verb'void sendInitContextToBrowser()': This method is used when the varable \verb'context_on_' is set from \verb'false' to \verb'true' or when \verb'showBrowserFrame()' is called. Then the context of the \verb'WorksheetDialog' of the active worksheet which has implemented the \verb'IContextProvider' interface is the initial context and it is sent to the \verb'BrowserFrame'.}

 \item{\verb'void showBrowserFrame()': If an \verb'UserAction' with the \verb'ActionID' is \verb'UI_BROWSER_GET_FOCUS' received this method is called and the the \verb'BrowserFrame' will get the focus.}

 \end{itemize}

 The \verb'BrowserDialog' offers the following protected methods:

 \begin{itemize}

 \item{\verb'void drawButtonContextOff()': This method causes the Context Off button to be shown. If the button is already shown, nothing happens. Otherwise the Button for Context On is removed and the Button for Context Off is shown.}

 \item{\verb'void drawButtonContextOn()': This method causes the Context On button to be shown. If the button is already shown, nothing happens. Otherwise the Button for Context Off is removed and the Button for Context On is shown.}

 \item{\verb'abstract void drawButtons()': This method has to be implemented by the derived classes because every browser has a different set of buttons.}

 \item{\verb'HierarchyKey getHierarchyKey(String xml_content)': To get the correct \verb'HierarchyKey' from the \verb'xml_content' string the '\verb'HierarchyKeyParser' will be used and the \verb'HierarchyKey' will be returned.}

 \item{\verb'void interpretLink(URL url)': This method responsible to interpret a link coming from the \verb'BrowserFrame'. Normal links fetch html-files which are shown in the correspondig browser (The first three letters in the filename show which browser is responsible for the link). For specific links coming from the ExampleBrowser which include \verb'#COMMAND_EXEC_EXAMPLE#' the method \verb'openWorksheetFromExample(String kestore_key)' is called. The \verb'kestore_key' is parsed from the \verb'URL'.}

 \item{\verb'Vector loadContent(String session, String type,' \verb'String filename)': The content is loaded from the \verb'KEStore' by using the \verb'callKEStore' method which encapsulates the communication via \verb'XML-RPC' \cite{oai:CiteSeerPSU:328175}. The content is stored as the first element. The \verb'Vector' is used to get better structured information if an erros occurs.}

 \item{\verb'Hierarchy loadHierarchy(ContextType type)': The \verb'Hierarchy' is loaded from the \verb'KEStore' by using the \verb'callKEStore' method.  If the type is unknown, \verb'null' will be returned.}

 \item{\verb'void sendContextToBrowser(Context context)': This method sends a context to the browser but first it has do get the \verb'HierarchyKey' and store it into the \verb'context' object. The sent context is the new \verb'current_context_'.}

 \item{\verb'void sendGetFocusToBrowser()': This method is responsible for making a \verb'BrowserFrame' visible to the user, i.e. when \verb'interpretLink' is called to open a html-file in a different browser this method will cause the \verb'BrowserFrame' to come in front of all frames.}

 \item{\verb'void sendLinkToMiniBrowser(Context context, ContextType type)': Sends the browser the information to display the new selected problem. This method is called if a new context has to be shown in the browser. A link is created out of the \verb'KEStoreKey' which is stored in     the \verb'Context' object. This created link is then sent to the minibrowser via \verb'void sendLinkToMiniBrowser(String link)'.}

 \item{\verb'void sendLinkToMiniBrowser(String link)': The \verb'user_status' is read out of the \verb'Usermanager', which is implemented as a singleton and then \verb'void sendLinkToMiniBrowser(String link, int user_status )' is called.}

 \item{\verb'void sendLinkToMiniBrowser(String link, int user_status )': Calls the \verb'doUIAction' method of the \verb'BrowserFrame' with an \verb'UIActionOnLink' but first the \verb'user_status' has to be checked for the privileges of the user to decide how much information will be provided.}

 \item{\verb'void setCurrentContextToWorksheet()': This method takes the \verb'current_context_' and calls the active Worksheet to set the \verb'current_context_' as the new context for the worksheet. The \verb'ToWorksheet' button is only visible if there is an active Worksheet and if the calcHead is opened.}

 \item{\verb'void switchToMatchOff()': This Method sends an \verb'UIAction' to instruct the \verb'BrowserDialog' to generate the Context off button (and also remove the Context on button first).}

 \item{\verb'void switchToMatchOn()': This Method sends an \verb'UIAction' to instruct the \verb'BrowserDialog' to generate the Context on button (and also remove the Context off button first).}

 \end{itemize}

 The \verb'BrowserDialog' offers the following private methods:

 \begin{itemize}

 \item{\verb'private Vector callKEStore(String function,' \verb'Vector parameters)': This method encapsulates the communication with \verb'KEStore'. This communictaion is done via \verb'XML-RPC'.}

 \item{\verb'private Vector filterContent(String session, Vector result)': Inside this method a \verb'DOM' is build from the \verb'String' stored in the result \verb'Vector'. Then some Node of the \verb'DOM' can be filtered depending on the privileges of the user.}

 \end{itemize}

 Here are the member variables of the \verb'BrowserDialog'. They are all set protected to be accessible from the derivated classes:

 \begin{itemize}

 \item{\verb'IToGUI browser_frame_rmi_'}

 \item{\verb'Hierarchy hierarchy_'}

 \item{\verb'Context current_context_'}

 \item{\verb'Session session_'}

 \item{\verb'ContextType context_type_'}

 \item{\verb'boolean context_on_visible_'}

 \item{\verb'boolean context_on_'}

 \item{\verb'UserLanguage user_language_'}

 \end{itemize}

 \section{Communication with the Browsers}

 Since only the GUI is running on the client-side, remote calls of the browsers' methods coming from the browser dialogs are performed by using Java RMI (Remote Method Invocation). Whenever a user performs an action on a \verb'BrowserFrame', the corresponding dialog is addressed by using the \verb'notiyfyUserAction()' method derived from the \verb'IBrowserDialog' interface to send an \verb'UserAction' to the browser dialog. To distinguish between the different types of \verb'UserAction's which store different kinds of information, there are many classes derived from the \verb'UserAction' class.

 To manage communication from the browser dialogs to the browsers the \verb'IToGui' interface, which is implemented by the \verb'BrowserFrameRMI', an \verb'UIAction' is passed.

 The \verb'UIAction' has an \verb'EUIContext', which has the type of an enumeration, as a member variable. The \verb'EUIContext' determines, which component of the browser the \verb'UIAction' concerns. The \verb'UIAction' is then forwarded to this component, where it is finally handled.

 \section{Communication with the Worksheet Dialogs}

 Every \verb'WorksheetDialog' implements the \verb'IContextProvider' interface. Each time a browser comes to the fore the method \verb'initContext' is called on the \verb'active_worksheet_dialog_'. The \verb'active_worksheet_dialog_' can be fetched from \verb'WSDialogManager' which is a memeber variable of the \verb'Session'. To get the correct context for each browser the \verb'cotext_type' must by passed as a parameter. A new \verb'Context' will be returned and then sent to corresponding \verb'BrowserFrameRMI' to be handled by a browser component.

 If the user selects an other element in the hierarchy, and the context is switched on, the actual context has to be fetched. The \verb'checkContext' method is called with a \verb'Context' as the only parameter to tell the \verb'ContextProvider' which element of the \verb'KEStore' has to be checked. The \verb'WorksheetDialog' returns the new \verb'Context' which was checked with the context of the actual calculation.

 \section{XML-Parser Digester}

 To parse the xml-files coming from the math-engine the digester component from the Jakarta Project\footnote{from \url{http://jakarta.apache.org/commons/digester/}} is used. The following subsections describe the usage of the digester inside the java code.

 \subsection{How the Digester works}

 The digester reads xml code and produces java objects dynamically which are filled with the contents of the xml code, whereas informations for the digester, e.g. which element has to be at a certain position in the hierarchy of the xml code, are defined as rules. There are e.g. rules to construct objects of a certain class to push them onto an internal stack.

 There are other rules to define which methods have to be called when a certain xml element was read by the parser. The methods access the top element of the stack by using the reflection mechanism. The content of the certain xml element is passed as a parameter of the method.

 There are also rules to afford that the top element of the stack is used as a parameter and call a method from the subjacent element with that top element as parameter. When the digester has finished parsing the top element will be returned.

 \subsection{Rules}

 The digester needs rules which specify, what to to if a certain element is read by the parser. Those rules are defined when the digester gets initialized. For the implementation of the contexts the following rules where used:

 \paragraph{addObjectCreate(java.lang.String pattern, java.lang.Class clazz)} Causes the parser to create a new java object of the class \emph{clazz} when the parser finds an element inside the xml code which matches the string \emph{pattern}. This new object will then be pushed on the stack.

 \\Example:

 \begin{verbatim}

 digester_.addObjectCreate("*/CONTEXTTHY", ContextTheory.class);

 \end{verbatim}

 \paragraph{addCallMethod(java.lang.String pattern, java.lang.String methodName, int paramCount)} Causes the parser to call the method \emph{methodName} to access the element on top of the stack when the element \emph{pattern} is read inside the xml code. The content of the xml element \emph{pattern} will be passed as a parameter of the method. The parameter \emph{paramCount} defines the number of expected parameters. To parse the components of the context we are only working with single paramenters. That means that the variable \emph{paramCount} is always set to 0.

 \\Example:

 \begin{verbatim}

 digester_.addCallMethod("*/GUH", "setKey", 0);

 \end{verbatim}

 The method access is passed by using the reflection mechanism, that means that the name of the method to be accessed is passed as a string. This circumstance causes that bad rules are detected at runtime, e.g. the method name is written incorrectly, or the object on the stack does not have such a method. These problems caused some debugging sessions because the problems could not be found easily.

 \paragraph{addSetNext(java.lang.String pattern, java.lang.String methodName)} Causes the parser to call the method \emph{methodName} on the second object from the stack when the element \emph{pattern} is read inside the xml code. As parameter the element at the top of the stack is passed and popped from the stack.

 \\Example:

 \begin{verbatim}

 digester_.addSetNext("*/GUH", "setKEStoreKey");

 \end{verbatim}

 \end{sloppypar}

 \section{Examples of the Implementation}

 Finally, to get an idea how the implementation works, some screenshots may be very helpful. As you can see in figure Fig.\ref{fig.GK-worksheet} there is an open worksheet and the current position on the worksheet is marked. Now the user takes a specific view on the theory context of that position. When the user opens the theory browser, as far as it is not open yet, he will see not only the static information but also, red marked, the context to his calculation (see Figure Fig.\ref{fig.GK-thy-browser}).

 \begin{figure}[htb]

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

 \caption{Example for an open worksheet}

 \label{fig.GK-worksheet}

 \end{figure}

 \begin{figure}[htb]

 \centerline{\includegraphics[width=\textwidth, keepaspectratio=true]{fig/GK-thy-browser}}

 \caption{Example for Context Information in a Theory Browser}

 \label{fig.GK-thy-browser}

 \end{figure}

 % SOFTWARE DESIGN AND IMPLEMENTATION - END

 % CONCLUSION - BEGIN

 \chapter{Conclusion}

 \section{Results of this thesis}

 The main goal of this thesis was to make \sisac{}'s knowledge transparent to the user. Now \sisac{} provides a very easy was for the user to view the context of a formula at a certain step of a calculation. So the user gets the possibility of learning by displaying not only the static informations about the knowledge, but also the context to any kind of the knowledge and this is a good way to understand which knowledge is used and also how it is used to solve an example.

 \section{Further Development}

 \subsection{The Implementation of a User Model}

 The user of \sisac{} is very often overwhelmed by the mass and the complexity of data. Very often the information provided to the user does not match the standard of knowledge of the user. One of the next developments in \sisac{} will be the implementation of such a User Model which stores not only the privileges of a user but also the improvements with his knowledge.

 \subsection{The Implementation of a Content Filter}

 After the development of a User Model, a content filter has to be implemented by using this user model to filter the informations provided to the user. There will be different methods to define filters for user groups or especially for specific users.

 % CONCLUSION - END

 \bibliography{bib/bib-GK}

 \end{document}