finished review WK bakk (conflicts in content and titlepage handled in next go)
1.1 --- a/doc/GS/titlepage.tex Tue Oct 30 19:47:19 2007 +0100
1.2 +++ b/doc/GS/titlepage.tex Wed Oct 31 16:05:26 2007 +0100
1.3 @@ -8,7 +8,7 @@
1.4 \textbf{\LARGE{Feasibilitystudy:\\
1.5 Communication of a Web 2.0 Browser with an Interactive
1.6 Mathematics Server}} \\
1.7 - \medskip
1.8 + \medskip
1.9 \vspace{15mm}
1.10
1.11 {\large G\"unther Schr\"ottner} \\
1.12 @@ -30,8 +30,7 @@
1.13 \vspace{5mm}
1.14
1.15 \begin{figure}[htb]
1.16 -\centerline{\includegraphics[width=0.2\textwidth,
1.17 -keepaspectratio=true]{../fig/icons/tug}}
1.18 +\centerline{\includegraphics[width=0.2\textwidth, keepaspectratio=true]{../fig/icons/tug}}
1.19 \end{figure}
1.20
1.21
1.22 @@ -43,8 +42,7 @@
1.23 \vspace{30mm}
1.24 {\small
1.25 \begin{tabular}{ll}
1.26 -
1.27 - Supervisor: & Dipl.-Ing. Dr.techn. Denis Helic \\
1.28 + Supervisor: & Dipl.-Ing. Dr.techn. Denis Helic \\
1.29 Project Coordinator: & Dr.techn. Walther Neuper \\
1.30 \end{tabular}
1.31 }
2.1 --- a/doc/WK/WK_bakk.tex Tue Oct 30 19:47:19 2007 +0100
2.2 +++ b/doc/WK/WK_bakk.tex Wed Oct 31 16:05:26 2007 +0100
2.3 @@ -1,12 +1,8 @@
2.4 \documentclass[a4wide]{report}
2.5 \input{preamble}
2.6
2.7 -\title{Transfer \isac s Graphical Userinterface \\
2.8 - To Web2.0 Technology}
2.9 -\author{Wolfgang Kandlbauer}
2.10 -\date{$\today$}
2.11 +\begin{document}
2.12
2.13 -\begin{document}
2.14 \input{titlepage}
2.15 \tableofcontents
2.16 \listoffigures
3.1 --- a/doc/add-content.tex Tue Oct 30 19:47:19 2007 +0100
3.2 +++ b/doc/add-content.tex Wed Oct 31 16:05:26 2007 +0100
3.3 @@ -1,778 +1,2299 @@
3.4 -%nicht vergessen: auch add.tex ($Revision $) \"andern !
3.5 -\chapter{Architectural Design Document}
3.6 -\section{The overall architecture}
3.7 -%W.N.: dieser Abschnitt ist f''ur alle
3.8 -This is just a first draft for the structure of the JAVA-part of the
3.9 -\isac\/-project. Communication between JAVA and math-engine is done
3.10 -through the \emph{wrapper} which translates the commands and
3.11 -XML-formulas to an character-stream which is interpreted by the
3.12 -SML-engine.
3.13 + legend to the reader's marks:
3.14 +%
3.15 +% [] the brackets enclose comments additional to,
3.16 +% and not belonging to the text
3.17 +%
3.18 +% {} the braces enclose exact proposals for new text,
3.19 +% which are embedded into comments.
3.20 +%
3.21 +% / marks a character to be deleted in the line _above_
3.22 +%
3.23 +% ^ points to a certain position in the line above,
3.24 +% usually concerning a comment or an insertion
3.25
3.26 -\subsection{overview}
3.27 -Below is a short description of the role of the modules shown in
3.28 -Fig.\ref{all-modules} and Fig.\ref{design}.
3.29 +\part{Architectural Design Document}
3.30 +
3.31 +\chapter{Surveys}
3.32 +\section{Survey on the components}
3.33 +
3.34 +Below there is a short description of the role of the modules shown in
3.35 +Fig.\ref{all-modules}.
3.36 +\begin{figure} [htb]
3.37 +\centerline{\psfig{figure=fig/soffice/RK-architecture.eps,width=11cm}}
3.38 +\caption{\sisac s components} \label{all-modules}
3.39 +\end{figure}
3.40 +
3.41 \begin{description}
3.42
3.43 - \item[Browsers] (Example Browser, Knowledge Browser) Used to browse
3.44 - through the content of the \emph{KE-Store}. There are different
3.45 - types of informations (Problems, Methods, Examples, \dots) which can
3.46 - be accessed in a similar way.
3.47 + \item[Browsers] (Example Browser, Knowledge Browser) allow to browse
3.48 + 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.
3.49
3.50 - A Browser might also add dynamic information (i.e. to visualize if a
3.51 - problem matches a model) and is mainly accessed through browser-windows
3.52 - (delivers its content as HTML-pages).
3.53 +%the \emph{KE-Store}. There are different types of informations (Problems, Methods, Examples, \dots) which can be accessed in a similar way.
3.54
3.55 - \item[Browser-window] Used to access the HTML-pages generated by
3.56 - \emph{knowledge browsers} and the \emph{example browser} (not shown in Fig.\ref{all-modules}).
3.57 +%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).
3.58
3.59 - \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.
3.60 +%\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}).
3.61 +%\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.
3.62
3.63 - \item[Worksheet] Interface to the user to access the ME
3.64 + \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.
3.65
3.66 - \item [Dialog] consists of two parts, the worksheet-dialog and the browser-dialog.
3.67 + \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.)
3.68
3.69 - \item [Dialog-state] holds the identity of a user and data tracing all activities within one session.
3.70 +\item[Dialog editor] allows to define dialog patterns and strategies, and to preset dialog states.
3.71
3.72 \item [User-model] holds settings for the dialog-state and a (compressed) history of dialog-states.
3.73
3.74 - \item[Description Editor] Used to gather informations and extend the
3.75 - informations stored in the descriptions
3.76 - records. Administrators as well as Course-leaders have to be assisted
3.77 - when they build up their curse or maintain existing informations.
3.78 - The description-editor acts as ``frontend'' for the
3.79 - \emph{description}
3.80 + \item [Dialog-settings] are given for each learner in order to preset the dialog appropriately to the respective preferences (graphical representation etc.).
3.81
3.82 - \item [Math engine] does all mathematics in \sisac{} by use of Isabelles theorems and some of Isabelles services (matching, parsing, pretty-printing etc.)
3.83 + \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.
3.84 +%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}
3.85
3.86 - \item[ProveState] Holds all informations of a calculation. (or at
3.87 - least provides the interface for informations which are hold inside
3.88 - the ME). References to ProveState are interchanged between some of
3.89 - the java-modules when different modules want to acces one calculation
3.90 - (i.e. find a fitting problem for a ProveState)\footnote{Momentary,
3.91 - this module handles different tasks as there are storage of the
3.92 - state, connection with the ME (to calculate) and communication
3.93 - between Browser and WorkSheet. It should be splitted into parts for
3.94 - the proper tasks as soon a possible}.
3.95 +\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.
3.96
3.97 -
3.98 - \item[Description] This structure holds all informations used
3.99 - by the browsers (for examples, problems, methods, and lateron for theories). Formulas, formalisation etc. are merged to records
3.100 - and stored in an internal database. A storage and locating mechanism
3.101 - has to be defined in the DDD.
3.102 +\item [Knowledge + explanations] is what the learner sees during problem solving:
3.103 +\begin{enumerate}
3.104 +\item Theories with axioms, definitions and theorems (proven with
3.105 +Isabelle) \item Problems like types of equations, or problems of
3.106 +applied math \item Methods to solve the problems.
3.107 +\end{enumerate}
3.108 +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.
3.109
3.110 - The descriptions are accessed through an ``wrapper'' class
3.111 - (Description-object), which ensures the consistency of the
3.112 - descriptions. \begin{itemize}
3.113 +\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.
3.114
3.115 - \item There is maximal one client which is allowed to alter
3.116 - an description at one time.
3.117 +\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.
3.118
3.119 - \item If one client alteres an description, all other clients which
3.120 - read this description have to be informed.
3.121 - \end{itemize}
3.122 + \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.
3.123
3.124 - \item [Math authoring tools] extend Isabelles authoring tools ({\tt use\_thy} etc.); these authoring tools will remain within the SML development environment.
3.125 + \item[Calc-state] (short for state of a calculation) is held in a calc-tree for each calculation.
3.126
3.127 - \item [Knowledge] comprises theories, problems and methods held in SML data-structures. Theories are generated within the logical framework of Isabelle.
3.128 + \item [Isabelle] is an interactive theoremprover which lays the deductive foundation of \sisac.
3.129
3.130 - \item [Isabelle] is an interactive theoremprover which lays the deductive fundaments of \sisac.
3.131 +\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.
3.132
3.133 \end{description}
3.134
3.135 +%WN050519---AK->isac-ADD-----------------BEGIN---please don't remove this line
3.136 +\footnote{Begin of copy from \cite{AK04:thesis} p.53-57.}
3.137 +\section{Basic Concepts for Separable User Interfaces}\label{AK:DESIGN:SYSTEM:BASIC}
3.138 +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.
3.139 +
3.140 +\subsection{The Seeheim Model}\label{AK:DESIGN:SYSTEM:BASIC:seeheim}
3.141 +The Seeheim Model \cite{Seeheim}
3.142 +%WN040619 \cite{...The Seeheim Model...}
3.143 +%
3.144 +%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')
3.145 +%
3.146 +splits the entire system into three components as follows:
3.147 +\begin{description}
3.148 +\item[The Presentation Layer] is responsible for translation of
3.149 +physical representations, such as images, sounds, key-presses or
3.150 +mouse events into the logical concepts of the system and vice
3.151 +versa. Typical tasks of the Presentation Layer include rendering
3.152 +data on the display and parsing user input. \item[The Dialogue
3.153 +Controller] defines the structure of the interaction between user
3.154 +and system. Typical tasks of the Dialogue Controller include
3.155 +accepting events the user triggered on the Presentation Layer,
3.156 +routing events to appropriate destinations and making decisions
3.157 +whether and how to notify the user of changes in the state of the
3.158 +system. In other words, the Dialogue Controller defines (and
3.159 +enforces the use of) a language for the interaction between user
3.160 +and application. \item[The Application Interface] is an
3.161 +abstraction of the application's data and procedures from the user
3.162 +interface's point of view. It maps objects and operations on the
3.163 +user interface to actual data objects and code in the application,
3.164 +thus representing the application's functionality in a concise and
3.165 +consistent way.
3.166 +\end{description}
3.167 +
3.168 \begin{figure} [htb]
3.169 -\centerline{\psfig{figure=fig/all-modules.eps,width=11cm}}
3.170 -\caption{\sisac s modules}
3.171 -\label{all-modules}
3.172 +\centerline{\includegraphics[width=\textwidth, keepaspectratio=true]{fig/AK-seeheim_basic}}
3.173 +\caption{Interaction in the Seeheim Architecture}
3.174 +\label{fig.seeheim_basic}
3.175 \end{figure}
3.176
3.177 +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.
3.178 +
3.179 +
3.180 +\subsection{The MVC Architecture}\label{AK:DESIGN:SYSTEM:BASIC:mvc}
3.181 +As opposed to the Seeheim Model, which structures the system as a whole, the MVC
3.182 +%WN040619 \cite{}
3.183 +architecture \cite{buschmann} is grouped around single data objects as follows:
3.184 +%
3.185 +%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 !!!
3.186 +%
3.187 +
3.188 +\begin{description}
3.189 +\item[The Model] is any data object in the application requiring user interaction.
3.190 +\item[The View] is an object providing a visual representation of the respective Model, thus enabling the Model to output its data.
3.191 +\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.
3.192 +\end{description}
3.193 +
3.194 \begin{figure} [htb]
3.195 -\centerline{\psfig{figure=fig/design.eps,width=11cm}}
3.196 -\caption{Overall design}
3.197 -\label{design}
3.198 +\centerline{\includegraphics[width=8cm, keepaspectratio=true]{fig/AK-mvc_collaboration}}
3.199 +\caption{Interaction in the MVC Architecture}
3.200 +\label{fig.mvc_collaboration}
3.201 \end{figure}
3.202
3.203 +In a complex system, the link between application and user can contain several Model-View-Controller-triples, each grouped around a specific data item.
3.204
3.205 -\subsection{detailed description}
3.206 +\subsection{Comparing the approaches}\label{AK:DESIGN:SYSTEM:BASIC:compare}
3.207 +\begin{itemize}
3.208 +\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.
3.209 +% pl: Ich sehe nicht, warum das MVC Modell effizienter sein soll.
3.210 +\item Being built around smaller units of single objects, MVC is more flexible and easier to develop and extend.
3.211 +% pl: Das halte ich auch fuer Propaganda. Es ist nicht flexibler, wenn die
3.212 +% Praesentation eines Elementsvon einem globalen Kontext abhaengt.
3.213 +\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.
3.214 +% pl: Eben, das ist doch wesentlich.
3.215 +\end{itemize}
3.216 +%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 ?)
3.217 +
3.218 +\subsection{Implications for \isac{}}\label{AK:DESIGN:SYSTEM:BASIC:isac}
3.219 +\label{seeheim-mvc}%...%WN040815
3.220 +The design of \isac{} is based on the Seeheim Model, for the following reasons:
3.221 +\begin{itemize}
3.222 +\item A clear separation of Application, Dialogue Controller and Presentation layer is a design goal because:
3.223 +\begin{itemize}
3.224 +\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.
3.225 +% pl: Die Struktur waere auch sinnvoll, wenn alles in eneir Sprache
3.226 +% implementiert waere.
3.227 +\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.
3.228 +\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.
3.229 +\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.
3.230 +\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.
3.231 +%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)
3.232 +%AK danke, sehr wertvoll!!!!
3.233 +\end{itemize}
3.234 +\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.
3.235 +% pl: Das verstehe ich auch nicht ganz. Z.B. syntaktisch falsch eingegebene
3.236 +% Zahlen kann man doch sofort abfangen, oder nicht? Aber vielleicht auch
3.237 +% nicht. Da muesste man den Design genauer kennen.
3.238 +%WN040619 .. elegant ausgedrckt ;-)
3.239 +
3.240 +Any operations not involving mathematical knowledge can be handled locally by the Presentation Layer, in a MVC manner, if desired.
3.241 +
3.242 +\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.
3.243 +\end{itemize}
3.244 +
3.245 +% This makes a preliminary design for \isac{} look something like:
3.246 +% pl: Warum "preliminary" und "something like this" ?
3.247 +% Wie waere: "Based on these considerations, the top level design of \isac{}
3.248 +% looks like this"
3.249 +Based on these considerations, the top level design of \isac{} looks like this:
3.250 +
3.251 \begin{description}
3.252 - \item[Description] \
3.253 -
3.254 - Holds all information displayed by the knowledge-Browser
3.255 - Informations are gathered from the ME and the
3.256 - description-editor. The description has to protect the
3.257 - informations in terms of their consistency and access.
3.258 -
3.259 - There are different types of informations available (Problems,
3.260 - Methods, Examples, \dots); these types demand that different
3.261 - types of informations are stored. e.g. a Problem-description
3.262 - is only valid, if all mathematical constraints are given (see
3.263 - ``Terms'' for more details)\kommentar{wir sollten ein bib file
3.264 - fuer unsere dokumente machen}
3.265 -
3.266 - The mathematical informations must not be set by an human
3.267 - user, but only through synchronisation with the mathematics
3.268 - knowledge-base.
3.269 -
3.270 - Furthermore, there are additional informations, which extend
3.271 - the knowledge given by the ME with explanations, references
3.272 - to relevant examples and so on.
3.273 -
3.274 -% AG: schraenkt zu sehr die implementierung ein - nicht notwendig an dieser stelle
3.275 -%
3.276 -% Informations regarding the different
3.277 -% types of information should be stored the way to avoid
3.278 -% needless development. The UserRequirements for the different
3.279 -% Browsers show very similar demands on types of properties to
3.280 -% show on a page. There are plain text, formulars,
3.281 -% formalisations, links, images \dots.
3.282 -
3.283 -% XML give us a very nice structure to put this different
3.284 -% properties into one container. Text can be stored directly in
3.285 -% respective datafields. Formulas can even be put there in the
3.286 -% preferred way -- as MathML. Binary data (images, \dots) should
3.287 -% be referenced by identifyers which enables us to fetch the
3.288 -% files from another storage.
3.289 -
3.290 -% The XML-Descriptions are managed by an own Manager which
3.291 -% stores the files and is responsible to fetch the correct data
3.292 -% if a Browser requests a description with the unique ID. If
3.293 -% there are more than one \emph{description editor}, the manager
3.294 -% has to synchronize their access.
3.295 -
3.296 - \begin{itemize}
3.297 -
3.298 - \item descriptions are held outside the SML part to ease
3.299 - access and maintenance of the records. (i.e. put them into a
3.300 - database)
3.301 -
3.302 - \item each record has to have an unique and immutable
3.303 - identifyer to ensure consistency of the data.
3.304 -
3.305 - \item there should be an clear mechanism to determine the
3.306 - unique ID of a record\footnote{not only the ID should be
3.307 - unique but also the algorithm to gain the id if an item is
3.308 - wanted. If only the ID is unique, the browser-generator has to
3.309 - be queried for the correct ID. If the algorithm is known, the
3.310 - knowledge browser can get an ID without bothering the
3.311 - SML-engine}
3.312 -
3.313 -% AG7.11. kein HTML im storage !
3.314 -% \item a cache, which holds the textual descriptions as HTML
3.315 -% could be useful (either along the XML-Description or within
3.316 -% the browsers).
3.317 -
3.318 -% AG7.11. implementierung hier nicht interessant
3.319 -% \item there are datatypes, which cannot be stored directly
3.320 -% inside the XML-files (e.g. images)\footnote{store a reference
3.321 -% instead (e.g. a URL, filename or ID)}.
3.322 -
3.323 - \item binary data can be used in more than one data-record.
3.324 -
3.325 - \end{itemize}
3.326 - \item[\emph{Knowledge-Browsers} (short Browser)] \
3.327 -
3.328 - A \isac\/-\emph{knowledge-browser} is used to enter the
3.329 - knowledgebase and gain informations about the content and use of
3.330 - the special \isac\/ System. Although only HTTP-access is mentioned
3.331 - in the most parts of this document, the design of the
3.332 - knowledge-browser must not limit the access to this channel.
3.333 -
3.334 - A few points to keep in mind to understand the structure of the
3.335 - design.
3.336 -
3.337 - \begin{itemize}
3.338 -
3.339 - \item multiple layer structure to ease exchangeability of the
3.340 - knowledge-presentation
3.341 -
3.342 - \item there are logically different browsers for different
3.343 - datatypes (problems, examples, \dots). Although they provide
3.344 - different types of informations and have autonomous
3.345 - navigation-trees, the same software is used for all of them -
3.346 - just the information (provided by the description) is
3.347 - adjusted on demand.
3.348 -
3.349 - \item browsers can either create static HTML-pages or react
3.350 - interactively on each request (Servlet, CGI, \dots)
3.351 -
3.352 - \item a browser has different ``roles'' e.g. ``find a
3.353 - problem'' or just browsing through the knowledge or the
3.354 - examples. The Browser has to encode all necessary informations
3.355 - in the destination-URL to switch between these modes.
3.356 -
3.357 - \item besides the links stored in the description, there are
3.358 - links to be automatically generated
3.359 - (item-keywords,\dots). Browsers have to determine on the fly
3.360 - if the destination is available.
3.361 -
3.362 -% \item browsers have to support session and user-identification
3.363 -% and adjust their behaviour accordingly.
3.364 -
3.365 - \item the user can open a worksheet through clicking a link in
3.366 - the browser-window. This call for a worksheet is tunneled
3.367 - through \isac\/s dialogs to avoid direct communications
3.368 - between frontend-applications.
3.369 -
3.370 -% \item browsers have to communicate with the worksheet. Because
3.371 -% it is not possible to signal the worksheet from a Browser-Window,
3.372 -% it is neccessary to call the Browser-Window by the worksheet with
3.373 -% the URL of a browser and an proveStateID. With this ID, the
3.374 -% browser can try to gain access to the respective ProveState
3.375 -% (eventually after forcing the user to enter an
3.376 -% password). Afterwards, browser and worksheet can communicate
3.377 -% throug this ProveState with each other)
3.378 -
3.379 -% \item it is also neccessary to call an worksheet by the (WEB)
3.380 -% browser to perform a calculation. This can be done through
3.381 -% starting the worksheet as applet or calling a
3.382 -% worksheet-application with JAVA-WebStart\footnote{it depends
3.383 -% on the size of the worksheet which method should be
3.384 -% preferred. It is most likely that WebStart should be
3.385 -% preferred}. In both cases, a new instance of worksheet is
3.386 -% created with the ProveState as argument.
3.387 - \end{itemize}
3.388 - More details about the structure are given in section \ref{ADD:knowledge-browser}
3.389 -
3.390 - \item[\emph{Dialog}\/-Layer] \isac{} utilizes a \emph{dialog}
3.391 - layer to controll all communications between the user
3.392 - (frontend-applications) and the \isac{}-core (MathEngine,
3.393 - description). This Layer is devided into three
3.394 - sub-components which are specialized to their tasks.
3.395 -
3.396 - \begin{description}
3.397 -
3.398 - \item[session-dialog] is responsible to create and interlink
3.399 - the worksheet- and and browser-dialogs. It also gives access
3.400 - to some user-settings as preferred browser which are
3.401 - transfered to the session-controller (which is a client-side
3.402 - program to control a single \isac{} session). There is one
3.403 - instance of the session-dialog per \isac\/-System which
3.404 - controlles all open sessions. One user can work in different
3.405 - sessions concurrently (e.g. an author can be logged in as
3.406 - simple course-member the same time to check his input)
3.407 -
3.408 - \item[worksheet-dialog] One instance of a worksheet-dialog is
3.409 - responsible to make all adjustments regarding the calculations
3.410 - (more than one concurrently!) of a user. Even if the user
3.411 - works on more than one worksheet, all worksheets access the
3.412 - same dialog.
3.413 -
3.414 - \item[browser-dialog] One instance of a Browser-dialog is
3.415 - responsible to make all adjustments regarding the presentation
3.416 - of knowledge while a user is logged in. Even if more than one
3.417 - browser perform concurrent querys for one user, they access
3.418 - the same instance of the browser-dialog.
3.419 -
3.420 - \end{description}
3.421 -
3.422 - \item[\emph{ProveState}\/-Object, -ID] \
3.423 - \begin{itemize}
3.424 -
3.425 - \item ProveStateID has to be unique within the actual session of the
3.426 - system.
3.427 -
3.428 - \item ProveState has to refer to the respective session within
3.429 - the ME (i.e. dialog guide).
3.430 -
3.431 - \item Besides information about the assigned calculation,
3.432 - ProveState has to provide information for the browser
3.433 -
3.434 - \item an ProveState can be accessed concurrently. e.g. the
3.435 - workspace can edit the formalisation while the problem-browser
3.436 - changes the assigned problem. The object has to ensure its
3.437 - consistency or cunsult the ME if an action is allowed
3.438 -
3.439 - \item the ProveState has to hold user- and permission information
3.440 - to determine if an worksheet or browser may gain access.
3.441 -
3.442 - \item parts of the information accessible throug the ProveState
3.443 - is stored in reality within the ME.
3.444 -
3.445 - \item ProveState can have listeners and inform assigned browsers
3.446 - and worksheets about changes of its state.
3.447 -
3.448 - \item ProveState could be an \emph{Dinopolis}\/-Object and
3.449 - ProveStateID the respective guid.
3.450 -
3.451 - \end{itemize}
3.452 +\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,
3.453 +%WN040819 All mathematical knowledge required for calculations by the kernel ...
3.454 +all calculations are done here.
3.455 +%WN040819 (while the (static~!) knowledge to be shown to the user is exported from SML to the KE-Store (XML) by a batch process).
3.456 +%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
3.457 +The SML system communicates via the standard input and output text streams.
3.458 +\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.
3.459 +% pl: Ist die Implementierung Teil der Diplomarbeit?
3.460 +\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.
3.461 \end{description}
3.462
3.463 +\begin{figure} [htb]
3.464 +\centerline{\includegraphics[width=\textwidth, keepaspectratio=true]{fig/AK-isac_seeheim_um}}
3.465 +\caption{Basic \isac{} architecture for calculations}
3.466 +\label{fig.isac_seeheim_um}
3.467 +\end{figure}
3.468 +\footnote{End of copy from \cite{AK04:thesis} p.53-57.}
3.469 +%WN050519---AK->isac-ADD-----------------END---please don't remove this line
3.470
3.471 -\subsection{Communication Channels}
3.472 +\section{Survey on the architecture}\label{MH->isac-ADD1}
3.473 +\cite{MH04:thesis} describes the architecture depictured in Fig.
3.474 +\ref{fig.system_overview} on p.\pageref{fig.system_overview} as follows.
3.475
3.476 -\begin{description}
3.477 -\item[Browsers $\leftrightarrow{}$ Description \cnumber{3}]
3.478 -Browsers and Description utilize \emph{Dinopolis} to
3.479 -communicate with each other. A Browser has to pass an Object which
3.480 -identifies the current user to the Description to gain access
3.481 -tow the stored information. Informations are put into a
3.482 -description-object when transferred.
3.483 -
3.484 -\item[Description $\leftrightarrow{}$ Wrapper \cnumber{2}]
3.485 -To initiate the structure of the description, the
3.486 -Browsergenerator has to be queried for the structure of the
3.487 -Information. There is one instance of the description and
3.488 -one Wrapper which communicate with each other using the
3.489 -\emph{Dinopolis}\/-Framework. The Wrapper passes the request to the
3.490 -browser-generators which reside inside the SML-Layer.
3.491 -
3.492 -\item[Browsers $\leftrightarrow{}$ Browser-Windows \cnumber{4}]
3.493 -From the Browser-Windows point of view, the Browsers act as a normal
3.494 -HTTP-Server. All communication is performed with the HTTP-Protocol.
3.495 -This behaviour is reached utilizing a Servlet-Engine.
3.496 -
3.497 -\end{description}
3.498 -
3.499 -\section{The worksheet}
3.500 -%W.N.: gesamter Abschnitt ist f''ur A.K.
3.501 -The worksheet is the component responsible for interaction with the user while doing a claculation.
3.502 -
3.503 -The functionality is split between a worksheet presentation layer (WPL) and the worksheet dialog guide (WDG). This makes it possible to change the logic of user-interaction (WDG) and the presentation or skin (WPL) independently from each other.
3.504 -
3.505 -The WPL is responsible for visible presentation of data (like formulas in a calculation) and user-interface objects (like buttons or menus). Moreover, the WPL accepts input from the user.
3.506 -The WDG makes decisions on which data and which choices of user-interaction to present in which order, depending on the role (student, teacher, author, ...), the preferences and the history of the user.
3.507 -
3.508 -\subsection{}
3.509 -
3.510 -\subsection{}
3.511 -
3.512 -\subsection{}
3.513 -
3.514 -
3.515 -\section{The knowledge browsers}
3.516 -\label{ADD:knowledge-browser}
3.517 -This section contains a brief information about the modules needed
3.518 -create a knowledge browsers output. A more detailed description
3.519 -along with a draft of needed methods is given in section
3.520 -\ref{SDD:knowledge_browser}.
3.521 -
3.522 -%\subsection{knowledge browser}
3.523 -The knowledge Browsers generate the user-interface for querying the
3.524 -knowledgebase for static and dynamic purposes. By static browsing is
3.525 -ment: getting an overview of the content of isac. The user can not see
3.526 -if the presented content was just generated or is stored on a server.
3.527 -When the knowledge-browser is in an dynamic mode, it creates HTML
3.528 -pages as reaction to the users input. If one and the same page is
3.529 -called twice, it might present different data depending on the users
3.530 -input and his history (e.g. which examples he solved)
3.531 -
3.532 -Upon this description, we recapitulate the main tasks of the
3.533 -{knowledge-browser}.
3.534 -\begin{description}
3.535 - \item[HTTP-access] Queries are made through HTTP. This means we have
3.536 - to interpret the callers HTTP request to understand what the user
3.537 - wants, forward the request to the ``deeper'' layers of \isac{} and
3.538 - encode the result to HTML to be presented in a Browser-Window.
3.539 -
3.540 - \item[gathering the informations] Depending of the kind of request,
3.541 - different informations have to be gathered and combined to meet the
3.542 - users needs. e.g. if the user just wants to browse through the
3.543 - knowledge without doing any calculation, no connection to the
3.544 - MathEngine is neccesary. Its enough to visualize the stored
3.545 - informations (see also \emph{description} in section
3.546 - \ref{ADD:description})
3.547 -
3.548 - \item[filter informations given to the user] We want to adjust the
3.549 - output to the users needs and permissions. Therfore we need a method
3.550 - to decide which informations should be given respectively which
3.551 - details are blocked. This mechanism also has to gather and store all
3.552 - the actions the user attempts within \isac{} to build up a history for
3.553 - judgement when an example is presented to the user.
3.554 -\end{description}
3.555 -
3.556 -These tasks lead to the internal structure as given in figure
3.557 -\ref{ADD:fig-browser-int}. This figure shows the modules of the
3.558 -\emph{knowledge browser} and how the browser is embedded within \isac.
3.559 -
3.560 -\begin{figure} [htb]
3.561 -\centerline{\psfig{figure=fig/browser_int.eps,width=11cm}}
3.562 -\caption{parts of the browser}
3.563 -\label{ADD:fig-browser-int}
3.564 +%WN040815---MH->isac-ADD1-----------------BEGIN---please don't remove this line
3.565 +\begin{figure}[htb]
3.566 +\centerline{\psfig{figure=fig/MH-system_overview.eps,width=7cm}}
3.567 +%\centerline{\includegraphics[width=\textwidth, keepaspectratio=true]{system_overview}}
3.568 +\caption{The current design of the \isac{} system}
3.569 +\label{fig.system_overview}
3.570 \end{figure}
3.571
3.572 -\subsection{Servlet BrowserFrontend} \label{BrowserFrontend}
3.573 -This module waits for HTTP connects and forwards the requests to the
3.574 -Information-Processor. It provides the interface to the user and
3.575 -visualizes the content of the \emph{knowledge-base} as well as its
3.576 -structure. The BrowserFrontend runs within a ServletEngine and is
3.577 -started by the \isac\/-Administrator when he wants to allow users to
3.578 -browse the knowledge. A request by an Browser-Window contains the id of
3.579 -the session (to identify the user which accesses the browser), the
3.580 -item to show (e.g. an problem- or example-ID) and the task to perform
3.581 -(e.g. find an item for a running calculation, show the explanation of
3.582 -an problem \dots).
3.583
3.584 -This informations are used to query the \emph{information-processor}
3.585 -with gathers the informations and returns the result.
3.586 +The system architecture is designed as a \emph{distributed system}. %WN040815\cite{coulouris}.
3.587 +This means that the components described below are designed process
3.588 +independently and they can be executed on different computers
3.589 +concurrently. The thesis covers the design of the graphical user interface
3.590 +component and the interfaces that are necessary to connect to the
3.591 +other components of \sisac{}.
3.592
3.593 -The main task of the BrowserFrontend is the visualisation of these
3.594 -informations. The information are gained in form of a map which has a
3.595 -known set of fields. These fields contain informations to be displayed
3.596 -as well as optional layout-hints. If the layout-hint is missing, the
3.597 -Browser-Frontend has to create a fitting layout by himselve. This
3.598 -includes the highlighting of special values --- e.g. if some item does
3.599 -not match a selected Problem.
3.600
3.601 -The task of creating a valid HTML-Page is encapsuled within the
3.602 -\emph{encoder}.
3.603 +The components of \sisac{} are:
3.604
3.605 -Besides the pure informations about a special item, also the structure
3.606 -has to be visualised. This happens in form of a tree which represents
3.607 -the hierarchical structure of the content. The nodes of this tree are
3.608 -used to jump directly to an other information-page.
3.609 +\begin{itemize}
3.610
3.611 -\subsection{information-processor}
3.612 -The information-processor runs in the same virual machine as the
3.613 -BrowserFrontend. Therefore it communicates with the Frontend through a
3.614 -well defined set of method calls and exists one time per
3.615 -BrowserFrontend instance. The information-processor handles the
3.616 -communication with the remote \isac{} components. Strictly speaking it
3.617 -communicates with the \emph{browser-dialog} of the current user
3.618 -(determined with the session given by the browser-frontend) to gather
3.619 -all informations necessary for the current request.
3.620 + \item The \textbf{backend} of \sisac{} is responsible for doing
3.621 + the calculation and holding the mathematical knowledge also known
3.622 + as knowledge base. The mathematical engine can only do one calculation
3.623 + at a time.
3.624 + This is a restriction that needs to be bypassed.
3.625
3.626 -We want to allow that:
3.627 + \item Hence, the component called \textbf{Bridge}
3.628 + is designed as a \emph{multiuser} component. Multiuser in this
3.629 + context means that the Bridge distributes the simultaneous user
3.630 + requests over several instances of the mathematical machine.
3.631 + A more detailed description can be found in \cite{RG04:thesis}.
3.632 + Note that in this context the name Bridge has nothing to do with the
3.633 + structural software pattern ``Bridge'', described in
3.634 + Design Patterns by the ``Gang of Four''. %\cite{Gamma95}.
3.635 +Rather, the
3.636 + component Bridge in the \sisac{} system architecture can be
3.637 + described as an ``Adapter'' in the meaning of a design pattern.
3.638 + It converts the interface of the mathematical engine
3.639 + into another interface that the other parts of \sisac{}, especially the
3.640 + \emph{WorksheetDialog}, expect.
3.641 + Moreover, the Bridge also ``converts'' the functional software
3.642 + design paradigm of the mathematical engine into an object-oriented
3.643 + design paradigm the other parts of \sisac{} expect; therefore, the Bridge lets
3.644 + components work together that could not otherwise because
3.645 + of incompatible interfaces.
3.646 +
3.647 + \item The \textbf{WorksheetDialog} acts as a middleman between the Worksheet
3.648 + and the Bridge. It is the central component while solving an example.
3.649 + The Worksheet provides the user with information during a calculation in
3.650 + cooperation with the WorksheetDialog. The WorksheetDialog decides how detailed
3.651 + the user should see the information, depending on the user history, experience
3.652 + of the user and role of the user. The WorksheetDialog can also
3.653 + restrict the access to parts of the knowledge to ensure that the
3.654 + user is not swamped with examples for which his experience level is not
3.655 + high enough and he is not meant to solve yet.
3.656 +
3.657 + The design of the WorksheetDialog at the moment concentrates on the
3.658 + solving part. User history, restricting access and different grades
3.659 + for showing information are scheduled in the design but not yet completely
3.660 + finished.
3.661 +
3.662 + Worksheet and WorksheetDialog stand in a 1:1 relation, which means that
3.663 + for each Worksheet a separate WorksheetDialog is necessary.
3.664 +
3.665 + \item The \textbf{BrowserDialog}\label{AG:BrowserDialog} is the component in charge as far as the
3.666 + knowledge base is concerned. Strictly speaking, the \emph{InformationProcessor}
3.667 + provides information about the knowledge base. Each part of the knowledge base
3.668 + (problem, method and theory, see section~\ref{knowledge base}) can be accessed and also
3.669 + the example collection can be accessed.
3.670 + Another task of the InformationProcessor is the authorization of the
3.671 + user that wants to connect to the \sisac{} system.
3.672 + Currently a username and a password are used to authorize
3.673 + the user. Security considerations like encryption
3.674 + have not been included in the design process so far.
3.675 +
3.676 + The InformationProcessor provides
3.677 + a well designed interface that can be used by a client and is described
3.678 + in more detail in section \ref{D:IP}.
3.679 +
3.680 + The \emph{SessionDialog}, which is also part of the BrowserDialog, is
3.681 + responsible for the (re-) identification of the user.
3.682 + A user might connect and log in several times
3.683 + (e.g. with different applications), then the SessionDialog has to ensure
3.684 + that all WorksheetDialogs for this user work on the same data.
3.685 + A deeper look into the design of the SessionDialog can
3.686 + be found in \cite{AG:thesis}.
3.687 +
3.688 + There is only one SessionDialog per \sisac{} system.
3.689 +
3.690 + \item The \textbf{Graphical User Interface} is responsible for
3.691 + establishing a connection to \sisac{}. It consists of two components, namely,
3.692 + the \emph{HierarchyBrowser} and the \emph{Worksheet}. The requirements
3.693 + for these components have already been described in sections \ref{REQ:WS} and
3.694 + \ref{REQ:HB}. The following sections describe the design of the
3.695 + graphical user interface and the communication interfaces to the
3.696 + WorksheetDialog and BrowserDialog.
3.697 +\end{itemize}
3.698 +%WN040815---MH->isac-ADD1-----------------END---please don't remove this line
3.699 +
3.700 +
3.701 +\chapter{Session Management}
3.702 +%WN040815---AG->isac-ADD1-----------------BEGIN---please don't remove this line
3.703 +%WN040815---AG->isac-ADD1-----------------BEGIN---please don't remove this line
3.704 + \section{The Dialogs}
3.705 +
3.706 + \label{ADD:dialog}
3.707 +
3.708 + The \emph{dialog} is the ``heart'' of the system which controls the
3.709 + behavior of the different modules. It is responsible to adjust the
3.710 + reaction of the system to fit the learners (and teachers) demands.
3.711 + Among others, these demands contain:
3.712 +
3.713 + \begin{description}
3.714 + \item [record a learners success] by means of solved examples. This
3.715 + record can be used to create a set of proposed examples for a
3.716 + single user. Furthermore, the teacher can use this feedback to
3.717 + enhance the quality of his lecture (e.g if a single example causes
3.718 + problems for most students)
3.719 +
3.720 + \item [restrict access to parts of the knowledge] The set of
3.721 + available examples can vary depending on the already solved
3.722 + examples or the progress of the lecture to ensure, that the student
3.723 + is not swamped with examples he is not meant to solve yet.
3.724 + Furthermore, the available information have to be restricted while
3.725 + the learner writes a test. This also implies, that the access for
3.726 + not authenticated users can be restricted as well (by IP). (The
3.727 + user may not access the public information)
3.728 +
3.729 + \item [communication between different applications] \isac{} uses
3.730 + different applications to access the knowledge and mathematical
3.731 + capabilities of the system. For example: from the users point of
3.732 + view, the worksheet calculates while the KnowledgeBrowsers are used
3.733 + to select problems or methods for use within the calculation. In
3.734 + this case, worksheet and KnowledgeBrowser are just two
3.735 + access-points for the same application. The dialog establishes and
3.736 + controls the connection of these access-points.
3.737 +
3.738 + \item [manage the connected users] A user might be connected using
3.739 + several applications. For instance he can calculate an example and
3.740 + search a related \emph{problem} using a \emph{browser}. The dialog
3.741 + has to ensure, that these applications work on the same data.
3.742 + Therefore a \emph{session} is used which is aware of the different
3.743 + connections of a user.
3.744 +
3.745 + \end{description}
3.746 +
3.747 + Because of the various duties of the dialog, it is split up into a
3.748 + number of modules. Applications have an own ``peer'' which is used to
3.749 + communicate which them. These peers act as a kind of ``border'' --
3.750 + informations the user is not meant to get, may not cross this border
3.751 + but are filtered before. This filtering goes along with an possible
3.752 + transformation of the data.
3.753 +%For instance -- as mentioned in previous
3.754 +% subsections -- a \emph{KE-Object} is transferred to the internal
3.755 +% object structure when it is loaded from the
3.756 +% \emph{KE-Store}. The \emph{browser-dialog} is used to
3.757 +% translate it to XML after all manipulations on the object are done.
3.758 +%
3.759 +% These considerations lead to the component-layout as given in figure
3.760 +% \ref{fig.browser-masterdialog} on p.\pageref{fig.browser-masterdialog} which shows the dialog and its relations
3.761 +% to the applications along the informations where they are located
3.762 +% (server or client). Although the ``browser'' runs on the server, it
3.763 +% is situated in the frontend-layer. The reason is that the Web-Based
3.764 +% knowledge-browser as discussed in this state of development, could be
3.765 +% replaced by an browser with an other interface. This may not affect
3.766 +% the overall design of the system.
3.767 +%
3.768 +% \begin{figure} [htb]
3.769 +%\begin{center}
3.770 +% \centerline{
3.771 +%\psfig{figure=fig/browser-masterdialog.eps,height=11cm}
3.772 +%%\includegraphics[width=11cm]{\extend{fig/browser-masterdialog}}
3.773 +%}
3.774 +% \caption{Structure of the Dialog}
3.775 +%
3.776 +%%=\label{fig.browser-masterdialog}
3.777 +% \label{ADD:dialog-structure}
3.778 +% \end{center}
3.779 +% \end{figure}
3.780 +
3.781 + \subsection{Session-Dialog}\label{ADD:session_dialog}
3.782 + The \emph{session-dialog} governs the user-login and performs all
3.783 + necessary actions to build up a users dialog. It is started on
3.784 + system-startup and waits for connects by an
3.785 + \emph{session-controller}. There is only one session-dialog per
3.786 + \isac\/-System.
3.787 +
3.788 + The session-controller is a client-side program which performs the
3.789 + login and starts the \isac{} frontend-applications on a users
3.790 + machine. Besides the authentication, the session-dialog is also
3.791 + responsible to instantiate and interlink the application dependent
3.792 + parts of the dialog-layer as there are the Browser-Dialog and the
3.793 + WorkSheet-Dialog.
3.794 +
3.795 + Although one user can log in twice at a time, only one application
3.796 + dialog is created to ensure that all user-dependent information are
3.797 + up to date. Therefore the session-dialog has to maintain lists of
3.798 + logged in users and their respective dialogs.
3.799 +
3.800 +For the dialogs providing user-guidance see chap.\ref{DG} below.
3.801 +
3.802 +%--- from AGs thesis ------------------------------------//WN060324
3.803 +% \subsection{Browser-Dialog}\label{AG:Browser-Dialog}
3.804 +% These requirements demand that the Dialog is involved in all
3.805 +% user-activities. Therefore, the Dialog ``sticks'' behind the Browser
3.806 +% and determines the way of information-representation. Nevertheless,
3.807 +% the Browser has different ``modes'' which need more or less
3.808 +% interference of the Dialog.
3.809 +%
3.810 +% \begin{figure} [htb]
3.811 +%\begin{center}
3.812 +% \centerline{
3.813 +%\psfig{figure=fig/browser-dialog.eps,width=11cm}
3.814 +%%\includegraphics[width=11cm]{\extend{fig/browser-dialog}}
3.815 +%}
3.816 +% \caption{Interaction with the Browser-Dialog}
3.817 +% \label{design}
3.818 +%\end{center}
3.819 +% \end{figure}
3.820 +%
3.821 +% \begin{description}
3.822 +% \item[static knowledge-browsing] is access to the knowledge allowed -
3.823 +% determine and select additional informations (fitting explanations
3.824 +% and examples), log access.
3.825 +%
3.826 +% \item[search an item] determine the amount of help to give, log
3.827 +% access. The ``amount of help'' includes the representation of
3.828 +% additional information as well as the presentation of
3.829 +% ``match-results''. Matching is done through contacting the
3.830 +% \emph{WS-Dialog} which holds the necessary informations to perform
3.831 +% a match.
3.832 +%
3.833 +% \item[select an item] ``push it into the model'' contact the
3.834 +% responsible \emph{WS-Dialog} and ``offer'' the selected item
3.835 +% (Problem, Method, \dots). This Mode needs to know the responsible
3.836 +% worksheet in first place. The user could run more then one
3.837 +% worksheet at a time - so the Browser needs to know to which one the
3.838 +% selected item should be passed.
3.839 +% \end{description}
3.840 +%
3.841 +% So, the browser-dialog acts as peer for the browser. It performs all
3.842 +% communications with the rest of the \isac{} system and transform the
3.843 +% data to a suitable format. It does not constrain the browsers mode
3.844 +% (what the browser wants to do) or the presentation of the gathered
3.845 +% informations.
3.846 +%
3.847 +% \subsection{WorkSheet Dialog}
3.848 +% The worksheet-dialog contains the ``intelligence'' of the Worksheet, see chap.\ref{DG} below.
3.849 +
3.850 +\subsection{Browser-Dialog and Worksheet-Dialogs}\label{WN-add-BDialog-WSDialog}Both dialogs are discussed in a separate chapter, in chap.\ref{DG}.
3.851 +TODO.WN060705
3.852 +
3.853 + \section{Access Rights}
3.854 +
3.855 +%WN000705---summerterm06------------BEGIN---please don't remove this line
3.856 +\subsection{Dialog Guide and User Model}\label{WN-add-DG-UserModel}
3.857 +
3.858 +
3.859 +%WN000705---summerterm06--------------END---please don't remove this line
3.860 +
3.861 + \subsection{User-Administration}
3.862 + \label{ADD:user_admin}
3.863 + The \emph{user-administration}\/-module helps the dialog to maintain
3.864 + the users and control the access for \emph{courses}.
3.865 +
3.866 + \subsubsection{user}
3.867 + Information stored in an user-module contain personal information
3.868 + like name and login, as well as important administrative information
3.869 + like the courses he is member of and a reference to the
3.870 + \emph{user-model} which contains all information which are relevant
3.871 + to build up an environment for the user (solved examples, history,
3.872 + ...)
3.873 +
3.874 + \begin{verbatim}
3.875 + user:
3.876 + FirstName:String
3.877 + LastName:String
3.878 + login: String
3.879 + password: String (encrypted)
3.880 + courses: {course*}
3.881 + solved_examples, history, ...
3.882 + temporary_environ: hierarchy_opt
3.883 + \end{verbatim}
3.884 +
3.885 + The field \emph{temporary\_environ} is used in case of an
3.886 + examination. If this field is set to non-empty, a user has only
3.887 + permissions to the elements of the referenced hierarchy. This
3.888 + hierarchy typically contains the examples to solve and a few
3.889 + explanations which are permitted within the exam.
3.890 +
3.891 + \subsubsection{course}
3.892 +\label{ADD:course}
3.893 + A \emph{course} is a object within \isac{} to define a learning
3.894 + environment for different users. Typically, a course contains
3.895 + explanations to the mentioned theories and examples which are
3.896 + organized within an hierarchy. There are tools which help a
3.897 + course-designer to build up a hierarchy by e.g. copying a part of an
3.898 + other hierarchy. A typical reason for doing this is to copy a part of
3.899 + the problem-hierarchy and afterwards enrich the items with
3.900 + explanations and examples fitting the audience of the
3.901 + course
3.902 +
3.903 +% \kommentar{gute moeglichkeit, die beschreibungen und beispiele an den
3.904 +% kurs anzupassen. examples koennen trotzdem noch fuer die
3.905 +% kursteilnehmer herausgefiltert werden.}.
3.906 + Additionally, examples and general explanations can be added.
3.907 +
3.908 + The hierarchy of a course is located within the \emph{KE-Store}
3.909 + while the object describing the actual \emph{course} is located
3.910 + within the \emph{user-management-module}. Permissions are handled based on the user and
3.911 + \emph{KE-Objects} (hierarchies, examples, explanations,
3.912 + knowledge)
3.913 +
3.914 + \begin{verbatim}
3.915 + course:
3.916 + metadata:
3.917 + name:string
3.918 + hierarchy: hierarchy-id
3.919 + members:{user-id, user-id, ...}
3.920 + admin: user-id
3.921 + \end{verbatim}
3.922 +
3.923 + There are tools which perform the tasks of adding an removing users
3.924 + to a course. While adding a user to a course is relatively simple --
3.925 + ensure the user has proper rights for all \emph{KE-Objects} within
3.926 + the used hierarchy -- the task of removing a user from a course is
3.927 + more complicated: the user might be member of more than one course
3.928 + which access the same example. Removing access-rights for such an
3.929 + example might collide with the course the user is still member of.
3.930 + Therefore, the tool has to check all courses of the user before
3.931 + removing any permissions.
3.932 +
3.933 + The data-structure is usable for another set of tools which can act
3.934 + on them -- like hide an example for all members of a course till they
3.935 + are able to solve them or contact all of the course-members.
3.936 +
3.937 +%fuer commit
3.938 +%object structure
3.939 +%begin of dialog-description (has to be reviewed)
3.940 +%user-state and relations (user defined hierarchy) are still missing
3.941 +
3.942 +%\section{missing objects (temporary subsection)}
3.943 +
3.944 + \subsection{Permissions-module}
3.945 + The \emph{permissions-module} stores and maintains informations
3.946 + about which user might access to which \emph{KE-Objects}. The
3.947 + administration of the permissions is based upon the users stored
3.948 + within the \emph{user-administration}\/-module
3.949 +
3.950 + Permissions are applied, whenever an KE-Object is accessed. When
3.951 + informations ``leave'' the dialog -- e.g. when they are delivered to
3.952 + the \emph{browser}, the (browser-) dialog can remove links whose
3.953 + destinations are not accessible. Note, that the dialog can decide not
3.954 + to show an example to a user although he has the proper permissions
3.955 + -- in this case, the references are filtered out by an didactic filter.
3.956 +%before they are delivered to the browser-dialog.
3.957 +
3.958 + Permissions can be set at once to a number of users using tools which
3.959 + can access the objects within the \emph{user-management-module}.
3.960 + E.g. a tool is used to to add and remove users from a course. These
3.961 + tools traverse the members of the course and set the proper
3.962 + permissions for them. There is a special mode to limit access, when
3.963 + the user participates to a exam. In this case access is limited to
3.964 + the environment given in the \emph{temporary\_environ} field of the
3.965 + user-object.
3.966 +%WN040815---AG->isac-ADD1-----------------END---please don't remove this line
3.967 +%WN040815---AG->isac-ADD1-----------------END---please don't remove this line
3.968 +
3.969 +
3.970 +\chapter{Dialog Guide}\label{DG}
3.971 +%WN050518---AK.p.61-62->isac-ADD--------BEGIN---please don't remove this line
3.972 +\footnote{Begin of copy from Alan Krempler \cite{AK04:thesis} p.61-62 with updates by Georg Kompacher \cite{ba-GK07}.}
3.973 +%\subsubsection{Browsing the Knowledge Base}
3.974 +\section{Browser Dialogs and WorkSheet Dialog}\label{WN-add-BDialog-WSDialog}
3.975 +%WN060324--->thesis.ML-----------------BEGIN---please don't remove this line
3.976 +In contrast to most currently available algebra systems, \isac{} bases its
3.977 +calculations entirely on rules and knowledge visible to the user. For
3.978 +every step done in a calculation, there is a justification in \isac{}'s
3.979 +knowledge base, which can be displayed on request. Even more importantly,
3.980 +these justifications are meant to be understood by the user, as they are
3.981 +expressed in terms of human mathematical reasoning, not in sophisticated
3.982 +and optimised algorithms.
3.983 +
3.984 +% GK070313- tag for quicksearch START
3.985 +
3.986 +As \isac{}'s knowledge base can be understood by humans, it can be used as
3.987 +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.
3.988 +
3.989 +\begin{figure}[htb]
3.990 +\centerline{\includegraphics[width=10cm, keepaspectratio=true]{fig/AK-sysdesign_draft}}
3.991 +\caption{The first sketch for \isac{}'s architecture}
3.992 +\label{fig.sysdesign_draft}
3.993 +\end{figure}
3.994 +
3.995 +% KE-Store heisst im Glossary "KE-base"? Die Bedeutung muss auch im Text
3.996 +% erklaert werden.
3.997 +
3.998 +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.
3.999 +
3.1000 +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.
3.1001 +
3.1002 +The two subsystems interact in the following points:
3.1003 +\begin{itemize}
3.1004 +\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.
3.1005 +
3.1006 +\item When browsing thru the knowledge base, an example illustrating the presented concept can be calculated.
3.1007 +
3.1008 +\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.
3.1009 +%WN060324+++............................................................
3.1010 +The other reason for accessing the Knowledge Base from a calculation is, to explore the application of nearby knowledge-items to the calculation.
3.1011 +
3.1012 +\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.
3.1013 +
3.1014 +% \begin{itemize}
3.1015 +% \item Which other theorem can be applied to the current formula~?
3.1016 +% \item Which other rule-set can be applied to the current formula~? How does this rule-set behave with another rewrite-order~?
3.1017 +% \item Which assumptions are generated by the rewrites on the current formula~?
3.1018 +% \item Which other problem could match the model of the current calc-head~?
3.1019 +% \item Which other method's guard could match the model of the current calc-head~?
3.1020 +% \end{itemize}
3.1021 +
3.1022 +Separate design considerations about the Browser Dialog see chap.\ref{WN-add-BrowserDialog}.
3.1023 +%............................................................+++WN060324
3.1024 +\end{itemize}
3.1025 +
3.1026 +%For an in-depth discussion of the Knowledge Browser, see \cite{AG:thesis} and section \ref{AG:BrowserDialog} on p.\pageref{AG:BrowserDialog}.
3.1027 +
3.1028 +\begin{figure}[htb]
3.1029 +\centerline{\includegraphics[width=\textwidth, keepaspectratio=true]
3.1030 +{fig/GK-sysdesign_seeheim}}
3.1031 +\caption{Design based on the Seeheim model and showing the separation of
3.1032 +browsing the knowledge and calculating}
3.1033 +\label{fig.sysdesign_seeheim}
3.1034 +\end{figure}
3.1035 +\footnote{End of copy from \cite{AK04:thesis} p.61-62.}
3.1036 +% GK070313- tag for quicksearch END
3.1037 +%WN050518---AK.p.61-62->isac-ADD--------END---please don't remove this line
3.1038 +
3.1039 +%WN050518---AK.p.57-58->isac-ADD--------BEGIN---please don't remove this line
3.1040 +\footnote{Begin of copy from \cite{AK04:thesis} p.57-58.}
3.1041 +\section{Location of the Dialog Guide}\label{AK:DESIGN:SYSTEM:DISTRIBUTE:dialog}
3.1042 +
3.1043 +With at least two machines involved - the user's computer with the
3.1044 +Worksheet and the server with the Math engine - the question where
3.1045 +to put the Dialog Guide remains. The Dialog Guide accesses the
3.1046 +Math Engine, the Worksheet and the User Model frequently. For
3.1047 +simplicity, mobility, security and centralisation reasons, the
3.1048 +User Model cannot reside on the user's machine. The same is true
3.1049 +for the Dialog Guide. The Dialog Guide with the persistent data of
3.1050 +the User Models could run on the server together with the Math
3.1051 +Engine or on an other server of his own. The Dialog Guide is
3.1052 +designed with the ability to run on a machine of its own in mind.
3.1053 +The final decision on the location of the Dialog Guide will be
3.1054 +based on tests with the prototype implementation.
3.1055 +%WN060324--->thesis.ML-----------------END---please don't remove this line
3.1056 +
3.1057 +\footnote{End of copy from \cite{AK04:thesis} p.57-58.}
3.1058 +%WN050518---AK.p.57-58->isac-ADD--------END---please don't remove this line
3.1059 +
3.1060 +
3.1061 +
3.1062 +
3.1063 +%WN050518---AK.p.65-67->isac-SDD--------BEGIN---please don't remove this line
3.1064 +\footnote{Begin of copy from \cite{AK04:thesis} p.65-67.}
3.1065 +\section{The Interfaces to the WorkSheet Dialog Component}\label{AK:DESIGN:SYSTEM:ARCH:interface}
3.1066 +Data exchanged at the interfaces of the WorkSheet Dialog component include:
3.1067 +\begin{description}
3.1068 +\item[Examples to be started] When initialising the Dialog to
3.1069 +moderate a process of calculation, the starting point can be an
3.1070 +empty worksheet or an Example from the example collection. In case
3.1071 +of starting from an Example, the Example has to be passed to the
3.1072 +Dialog. \item[Notifications about updates in a calculation] With
3.1073 +present technology, calculations done by the Math Engine may take
3.1074 +longer than the average user would wait. Moreover, response times
3.1075 +are not easily predictable, so waiting for a call to return would
3.1076 +block the WorkSheet Dialog - hence user interaction - for too
3.1077 +long a period of time. Therefore calls to the Math Engine return
3.1078 +immediately, with asynchronous notifications being sent when the
3.1079 +Math Engine completes a request. In addition to continuous
3.1080 +attention to the user, this approach allows for several users
3.1081 +watching one and the same calculation on their respective
3.1082 +Worksheets and being even notified of updates in the calculation
3.1083 +requested by other users. For efficiency reasons, the update
3.1084 +notifications contain hints about which parts of the Calc Tree may
3.1085 +be affected by the update. These notifications are passed from the
3.1086 +Math Engine to the Dialog and from the Dialog to the Presentation
3.1087 +Layer. \item[The calculation itself] The Dialog needs access to
3.1088 +the Calc Tree stored in the Math Engine and passes a filtered
3.1089 +version of the tree to the Worksheet for display. The Dialog
3.1090 +cannot understand the mathematical meaning of Formulas, but is is
3.1091 +interested in identifying Tactics. It is the Tactics which the
3.1092 +user is learning to apply and the WorkSheet Dialog has to provide
3.1093 +appropriate user guidance for. \item[Calc Head] As with the Calc
3.1094 +Tree during the Solving Phase, during the Specifying Phase a Calc
3.1095 +Head has to be shared between Math Engine, WorkSheet Dialog and
3.1096 +Worksheet. \item[Notifications about user requests] The Dialog has
3.1097 +to be informed about actions the user triggers on the Worksheet.
3.1098 +The Dialog in turn translates the user actions into internal state
3.1099 +changes or requests to the Math Engine. \item[Requests to the Math
3.1100 +Engine] As the Math Engine stores the only instance of the Calc
3.1101 +Tree significant to further processing, all manipulations of the
3.1102 +tree have to be done by the Math Engine. Request to edit the
3.1103 +calculation originating from the user are processed by the
3.1104 +WorkSheet Dialog and execution is requested from the Math Engine.
3.1105 +\item[Information touched] Records of the user's interaction with
3.1106 +\isac{}'s knowledge are kept in the User Model and abstracted to
3.1107 +\isac{}'s view of the user's knowledge and abilities. The User
3.1108 +Model is informed about every interaction of the user with the
3.1109 +calculation or the Knowlegde Base. The User Model's abstraction is
3.1110 +in turn queried by the WorkSheet Dialog to decide on details of
3.1111 +user guidance. \item[Dialog Atoms] Information about the Dialog
3.1112 +Atoms involved in user interaction is passed to the User Model to
3.1113 +record not only the fact that the user interacted witch certain
3.1114 +parts of knowledge but also the nature of the interaction.
3.1115 +\item[User settings] The user's preferences about the way he
3.1116 +wishes to be guided have to be communicated to the WorkSheet
3.1117 +Dialog, whereas preferences about the visual appearance of the GUI
3.1118 +are communicated directly to the Worksheet.
3.1119 +\end{description}
3.1120 +\footnote{End of copy from \cite{AK04:thesis} p.65-67.}
3.1121 +%WN050518---AK.p.65-67->isac-SDD--------END---please don't remove this line
3.1122 +
3.1123 +
3.1124 +
3.1125 +%WN050518---AK.p.67-76->ADD-----------BEGIN---please don't remove this line
3.1126 +\footnote{Begin of copy from \cite{AK04:thesis} p.67-76.}
3.1127 +\section{Controlling the Course of Interaction}\label{AK:DESIGN:DIALOG:INTERACT}
3.1128 +The WorkSheet Dialog is responsible for guiding the user the way to obtaining a solution to a problem.
3.1129 +
3.1130 +\subsection{Dialog Phases}\label{AK:DESIGN:DIALOG:INTERACT:phase}
3.1131 +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.
3.1132 +
3.1133 +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}.
3.1134 +\subsubsection{Initialising}
3.1135 +To start interaction, the WorkSheet Dialog has to establish
3.1136 +connections with the components it interacts with, a Worksheet
3.1137 +representing the Presentation Layer and a Math Engine representing
3.1138 +the application (UC.\ref{START:contact-math}). In addition to
3.1139 +that, the WorkSheet Dialog needs information about the user it
3.1140 +deals with, to be able to adapt its behaviour accordingly
3.1141 +(UC.\ref{START:ident-user}, UR.\ref{COMMON:USERS:multi}). Only
3.1142 +after being provided with a CalcHead to act upon, optionally
3.1143 +filled in with a Formalization of a pre-defined Example
3.1144 +(UC.\ref{START:from-example}), the Dialog can enter the
3.1145 +Specification Phase.
3.1146 +\subsubsection{Specifying}
3.1147 +The goal of this phase is to gather enough - and consistent -
3.1148 +information to start solving (UC.\ref{SPECIFY}). During this
3.1149 +phase, the user can add information to a CalcHead, in arbitrary
3.1150 +order. After every item added, the CalcHead is checked with the
3.1151 +Math Engine for consistency and completeness
3.1152 +(UC.\ref{SPECIFY:check}, UR.\ref{DIALOG:GUIDE:model-feedback}).
3.1153 +
3.1154 +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}).
3.1155 +\subsubsection{Solving}
3.1156 +To enter the Solving Phase, a valid CalcHead is required.
3.1157 +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}).
3.1158 +
3.1159 +\paragraph{}
3.1160 +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.
3.1161 +
3.1162 +\subsubsection{Solving Subproblems}
3.1163 +Subproblems are calculations within calculations; in principle, they do not differ from top-level problems.
3.1164 +
3.1165 +\begin{figure}[htb]
3.1166 +\centerline{\includegraphics[width=\textwidth, keepaspectratio=true]{fig/AK-dialog_phases}}
3.1167 +\caption{A state machine for the Dialog Phases}
3.1168 +\label{fig.states}
3.1169 +\end{figure}
3.1170 +
3.1171 +\subsection{Dialog Atoms}\label{AK:DESIGN:DIALOG:INTERACT:atom}
3.1172 +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.
3.1173 +
3.1174 +Let us quote \cite{wn:diss} again:
3.1175 +\begin{quotation}
3.1176 +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$.
3.1177 \begin{enumerate}
3.1178 - \item more than one user may access one BrowserFrontend (and thus the
3.1179 - information-processor)
3.1180 - \item more than one Browser-Frontends access one browser-dialog
3.1181 +\item \label{putres} given \currf, input the next formula \res
3.1182 +\item \label{fillres} given a partial \currf (supplied by \sisac), complete \currf such that it is a derivation of \currf
3.1183 +\item \label{puttac}given \currf, input a tactic \tac to be applied to \currf
3.1184 +\item given \currf, select \tac from a list (supplied by \sisac) to be applied to \currf
3.1185 +\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
3.1186 +\item given \currf, \tac, and a partial \res, complete \res such that it is the result of applying \tac to \currf
3.1187 +\item given \currf and \res, input \tac such that \res is the result of \currf applying \tac
3.1188 +\item given \currf and \res, select \tac from a list (supplied by \sisac) such that \res is the result of \currf applying \tac
3.1189 +\item given \currf, \res and a partial \tac, complete \tac such that \res is the result of \currf applying \tac
3.1190 +\end{enumerate}
3.1191 +\end{quotation}
3.1192 +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.
3.1193 +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.
3.1194 +
3.1195 +\section{Sharing the Calculation with other Components}\label{AK:DESIGN:DIALOG:SHARE}
3.1196 +
3.1197 +\subsection{Representing the Model and the Specification}\label{AK:DESIGN:DIALOG:SHARE:spec}
3.1198 +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.
3.1199 +
3.1200 +
3.1201 +\subsection{Representing the Path to the Solution}\label{AK:DESIGN:DIALOG:SHARE:solve}
3.1202 +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.
3.1203 +
3.1204 +\subsection{Treating Subproblems}\label{AK:DESIGN:DIALOG:SHARE:subprob}
3.1205 +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.
3.1206 +Two possibilities for treating subproblems and feeding their results back into the main calculation were explored.
3.1207 +\subsubsection{Independent CalcTrees}
3.1208 +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.
3.1209 +\subsubsection{One Common CalcTree}
3.1210 +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.
3.1211 +
3.1212 +This approach was chosen for implementation, in part due to the fact that the already-implemented Math Engine stores calculations in a single tree.
3.1213 +
3.1214 +\subsection{Accessing Calculation Data}\label{AK:DESIGN:DIALOG:SHARE:access}
3.1215 +\subsubsection{CalcHead}
3.1216 +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.
3.1217 +\subsubsection{CalcTree}
3.1218 +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.
3.1219 +Several reasons suggested hiding the internal representation:
3.1220 +\begin{itemize}
3.1221 +\item An Iterator can serve the additional purpose of referencing elements of a calculation.
3.1222 +\item An Iterator is likely to be a much smaller object than the calculation it points into.
3.1223 +\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.
3.1224 +\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.
3.1225 +\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.
3.1226 +\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.
3.1227 +\end{itemize}
3.1228 +
3.1229 +\subsection{Communicating Changes in the State of Calculation}\label{AK:DESIGN:DIALOG:SHARE:change}
3.1230 +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.
3.1231 +The WorkSheet Dialog intercepts the flow of information and modifies it by implementing \isac{}'s logic of user-interaction.
3.1232 +\subsubsection{Wrapper-based Design}
3.1233 +One approach is wrapping the objects representing the calculation
3.1234 +- the Calculation Tree and associated objects - into objects with
3.1235 +the same interfaces but different behaviour, following the
3.1236 +Decorator pattern \cite{Gamma95}. This way, the WorkSheet Dialog
3.1237 +can filter information considered not appropriate for being
3.1238 +presented to the user by simply removing these data from the
3.1239 +representation accessible to the Presentation Layer. For an
3.1240 +example, if the user is not interested in the Tactics transforming
3.1241 +one formula into another, the Tactics simply do not show up in the
3.1242 +representation of the calculation seen by the Presentation Layer.
3.1243 +This has the advantage of simplicity - the Presentation Layer and
3.1244 +the Application need not consider filtering taking place or even
3.1245 +know about filtering at all. Moreover, the same interface can
3.1246 +still be used if one would want a system without the intervention
3.1247 +of a WorkSheet Dialog for direct communication between the
3.1248 +Application and the Presentation Layer.
3.1249 +\subsubsection{Event-driven Design}
3.1250 +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}.
3.1251 +
3.1252 +\section{Configuring the User-Interface}\label{AK:DESIGN:DIALOG:UI}
3.1253 +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.
3.1254 +
3.1255 +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.
3.1256 +\subsection{The Presentation Layer in Control}\label{AK:DESIGN:DIALOG:UI:present}
3.1257 +If the Presentation Layer controls every aspect of a button, such as visual appearance, placement on screen and the actions triggered, everything seems easy.
3.1258 +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.
3.1259 +
3.1260 +We could show the button all the time, with the WorkSheet Dialog
3.1261 +simply ignoring requests when not appropriate. This has the
3.1262 +disadvantage of confusing the user with lots of buttons which can
3.1263 +be clicked but make no sense in the current context.
3.1264 +
3.1265 +We could show buttons only if clicking them makes sense. If the
3.1266 +Presentation Layer were to solve this problem, it would need
3.1267 +information about the current phase of the dialog. While this may
3.1268 +seem feasible, in other situations the applicability of the button
3.1269 +might depend on the user's role or privileges, or on the user's
3.1270 +level of expertise, which in turn might change even during a
3.1271 +session. Especially if buttons depend on didactic strategies, this
3.1272 +involves knowledge which has nothing to do with presentation but
3.1273 +is clearly part of the WorkSheet Dialog.
3.1274 +
3.1275 +\subsection{The WorkSheet Dialog in Control}\label{AK:DESIGN:DIALOG:UI:dialog}
3.1276 +If we put the WorkSheet Dialog in control of the buttons, it
3.1277 +becomes easy to solve problems with context, but this would
3.1278 +require the WorkSheet Dialog to care about internationalisation
3.1279 +and visual appearance, which is out of interactional context and
3.1280 +should be left to the Presentation Layer.
3.1281 +
3.1282 +\subsection{Splitting up Responsibilities and Providing for Interaction}\label{AK:DESIGN:DIALOG:UI:split}
3.1283 +It seems best to have the various aspects of a button controlled
3.1284 +by the component which possesses the information necessary to do
3.1285 +so.
3.1286 +
3.1287 +While the Presentation Layer should control every visual aspect of
3.1288 +a button such as text, shape and placement on screen, the
3.1289 +WorkSheet Dialog should control the context in which the button
3.1290 +appears and the action it triggers. See \cite{sliski} for the
3.1291 +discussion of a related problem.
3.1292 +
3.1293 +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.
3.1294 +
3.1295 +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.
3.1296 +
3.1297 +
3.1298 +\section{Obtaining and Storing Configuration Data}\label{AK:DESIGN:DIALOG:CONFIG}
3.1299 +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}).
3.1300 +
3.1301 +\subsection{The User Settings}\label{AK:DESIGN:DIALOG:CONFIG:settings}
3.1302 +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.
3.1303 +
3.1304 +\subsection{Permissions and Security Issues}\label{AK:DESIGN:DIALOG:CONFIG:secure}
3.1305 +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.
3.1306 +
3.1307 +\subsection{The User Model}\label{AK:DESIGN:DIALOG:CONFIG:model}
3.1308 +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.
3.1309 +
3.1310 +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.
3.1311 +
3.1312 +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.
3.1313 +
3.1314 +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.
3.1315 +
3.1316 +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.
3.1317 +
3.1318 +\footnote{End of copy from \cite{AK04:thesis} p.67-76.}
3.1319 +%WN050518---AK.p.67-76->ADD-----------END---please don't remove this line
3.1320 +
3.1321 +%WN000705---summerterm06------------BEGIN---please don't remove this line
3.1322 +% GK070313- tag for quicksearch START
3.1323 +\section{Browser Dialog}\label{WN-add-BrowserDialog}
3.1324 +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.
3.1325 +
3.1326 +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.
3.1327 +There are two sources where the browser dialogs fetch their information:
3.1328 +\begin{enumerate}
3.1329 +\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.
3.1330 +\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.
3.1331 \end{enumerate}
3.1332
3.1333 -The first point is obvious. A WebServer simply has to serve different
3.1334 -users. The second decision is necessary to enable the system to run
3.1335 -differen BrowserFontends concurrently (e.g. to reduce server-load or
3.1336 -to allow a user to access different types of Browser-Frontends
3.1337 -concurrently).
3.1338 +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}).
3.1339
3.1340 -We may not store informations regarding an user within the
3.1341 -information-processor but forward it to the respective
3.1342 -browser-dialog. Otherwise, a (eventually existing) concurrent
3.1343 -BrowserFrontend would not be able to access these data.
3.1344 +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
3.1345 +\begin{itemize}
3.1346 +\item an example browser dialog, which is responsible for starting the execution of examples
3.1347 +\item a knowledge browser dialog, which is responsible for displaying the respective parts of the math knowledge; thus there is a
3.1348 + \begin{itemize}
3.1349 + \item theory dialog
3.1350 + \item problem dialog
3.1351 + \item method dialog
3.1352 + \end{itemize}
3.1353 +\end{itemize}
3.1354 +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.
3.1355
3.1356 -Communication between information-processor and browser-dialog is done
3.1357 -utilizing \emph{dinopolis}. So, the information-processor first has to
3.1358 -request an object-proxy for the browser-dialog to communicate
3.1359 -with. Administration of the dialogs for different users is done by the
3.1360 -session-dialog.
3.1361 +\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}.
3.1362
3.1363 -\subsection{browser-dialog}
3.1364 -This part of the browser finally gathers the informations for the
3.1365 -request. Depending of the type of request, it contacts the
3.1366 -description and / or the WorkSheet-dialog. Afterwards the
3.1367 +\subsection{Survey on requirements}\footnote{This is a survey from an early design phase documented in \cite{AG:thesis} p.42}
3.1368 + The \emph{browser-dialog} is the peer for the browser within the
3.1369 + dialog and gathers the informations for the request. Depending of the
3.1370 + type of request, it contacts the \emph{KE-Store} and/or the
3.1371 + WorkSheet-dialog. Afterwards, the informations are filtered depending
3.1372 + a users actual permissions and duties. It is possible, that pages are
3.1373 + blocked as a whole --- e.g. if an example is not accessible before an
3.1374 + other one is solved. Alternatively, some fields might be blocked. e.g.
3.1375 + if a learner has to solve a problem while performing a test, he might
3.1376 + see all available problems -- but the dialog will suppress the fields
3.1377 + which tell the user if (and why) an actual problem does not fit.
3.1378
3.1379 -informations are filtered depending a users actual permissions and
3.1380 -duties. It is possible, that pages are blocked as a whole --- e.g. if
3.1381 -an example is not accessible before an other one is solved. In
3.1382 -addition, some fields might be blocked. e.g. If a lerner has to find
3.1383 -an problem while performing a test, he might see all available
3.1384 -Problems -- but the dialog will suppress the fields which tell the
3.1385 -user if (and why) an actual problem does not fit.
3.1386 + The permissions are gained from different sources.
3.1387 + \begin{itemize}
3.1388 + \item The course-designer may define a group of users which may
3.1389 + access an example.
3.1390
3.1391 -The permissions are gained from different sources.
3.1392 + \item The course-designer may define preconditions before a example is
3.1393 + displayed (e.g. a date, or a set of examples to solve first)
3.1394 +
3.1395 + \item The course-designer may set the user to use a ``temporary
3.1396 + environment'' which alters all permissions to a set of
3.1397 + \emph{KE-Objects}(e.g. while an exam)
3.1398 +
3.1399 + \item The dialog-layer maintains a user-history to find out which
3.1400 +%WN ? dialog-state ~~~~~~~~~~~~
3.1401 + examples and parts of the knowledge are already visited and solved.
3.1402 + \end{itemize}
3.1403 +
3.1404 + The informations about a user are stored within the user-model.
3.1405 + Informations like the history are not only gathered and used by the
3.1406 + browser-dialog but by the whole dialog-layer.
3.1407 +
3.1408 +
3.1409 +\section{Dialog Guide and User Model}
3.1410 +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.
3.1411 +
3.1412 +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.
3.1413 +
3.1414 +
3.1415 +%% NC2301- tag for quicksearch
3.1416 +\chapter{Worksheet}
3.1417 +%% see the survey in \ref{MH->isac-ADD1} on p.\pageref{MH->isac-ADD1}.
3.1418 +
3.1419 +The worksheet is the center of user interaction in the \sisac{}
3.1420 +system. From the Users point of view, the Worksheet is the place
3.1421 +where the calculation happens. The \sisac{}'s knowledge base is
3.1422 +constantly expanding and the user interface has to be flexible
3.1423 +enough to allow the user to use every function provided by the
3.1424 +mathematics engine.
3.1425 +
3.1426 +\section{The Presentation Model}
3.1427 +
3.1428 +As already mentioned when designing \sisac{}, the entire was split
3.1429 +into components according to the Seeheim Model. The Worksheet
3.1430 +component according to this model represents the Presentation
3.1431 +Layer. According to Seeheim Model, the Presentation Layer is the
3.1432 +component that serves for the simultaneous interactive
3.1433 +communication with the user. This component defines the user
3.1434 +interface on a lexical level by specifying the user interface
3.1435 +widgets presented to the user. These user interface widgets serve
3.1436 +the purpose of supplying output to the user and receiving input
3.1437 +from the user.
3.1438 +
3.1439 +\begin{figure}[htb]
3.1440 +\centerline{\includegraphics[width=\textwidth,keepaspectratio=true]{fig/NC-Seeheim_Worksheet}}
3.1441 +\caption{Worksheet as a part of Seeheim Application Model}
3.1442 +\label{fig.seeheim_worksheet}
3.1443 +\end{figure}
3.1444 +
3.1445 +\section{Communication between the Presentation and Dialogue Control Layer}
3.1446 +
3.1447 +As mentioned in the previous section, the main purpose of the
3.1448 +Worksheet is to translate the user interactions to the requests to
3.1449 +the system. In this section we shall discuss how to implement the
3.1450 +communication between the Dialogue and the Presentation Layer. To
3.1451 +further simplify things, the communication is divided into two
3.1452 +categories:
3.1453 +
3.1454 \begin{itemize}
3.1455 - \item The course-designer may define a group of users which may
3.1456 - access an example.
3.1457 -
3.1458 - \item The course-designer may define preconditions befor a example
3.1459 - is displayed (e.g. a date, or a set of examples to solve first)
3.1460
3.1461 - \item The course-designer may set the user to a special ``role''
3.1462 - (e.g. in examisation)
3.1463 +\item User Interface Events, which consist of user requests and
3.1464 +system messages
3.1465
3.1466 - \item The dialog-layer maintaines a user-history to find out which
3.1467 - examples and parts of the knowledge are already visited and solved.
3.1468 +\item Calculation Events, which represent the output of the
3.1469 +mathematic engine
3.1470 +
3.1471 \end{itemize}
3.1472
3.1473 -The informations about a user are stored within the
3.1474 -user-model. Informations like the history are not only gathered and
3.1475 -used by the browser-dialog but by the whole dialog-layer.
3.1476 +\subsection {User Interface Events}
3.1477
3.1478 -%\begin{description}
3.1479 -% \item [services to communicate with the webbrowser] These services
3.1480 -% depend on the used machanism to communicate. The browsers are used
3.1481 -% inside a servlet, so the interfaces to the servletengine have to be
3.1482 -% provided. The services have to implement the tasks \begin{itemize}
3.1483 +The most common way to implement this type of communication is to
3.1484 +hold a reference to the system interface of the Worksheet Dialogue
3.1485 +in the Worksheet and for every user interaction event, simply call
3.1486 +specific methods of the interface to execute the command. However,
3.1487 +the designers of \sisac{} had to take in the consideration that the
3.1488 +Worksheet and the rest of the system are two different and
3.1489 +separate applications, meant to run on different computers and
3.1490 +communicate over network. Second consideration was that the
3.1491 +Worksheet application does not necessary need to be an AWT or
3.1492 +SWING application, but could be a pure text mode interface or even
3.1493 +a 3D enhanced virtual reality interface. Additionally, the
3.1494 +components had to be as flexible as possible, but the interface
3.1495 +should remain the same, thus allowing for the separate development
3.1496 +of Presentation and Dialogue Layer.
3.1497
3.1498 -% \item Show informations to a given item. $\rightarrow$ The user
3.1499 -% already has the id of a problem, examle, \dots and wants the
3.1500 -% browser to display it. The browser has to ask the
3.1501 -% description to gain informations and produce the HTML.
3.1502 +The logical answer was to use the "command objects" as a practical
3.1503 +mean for network transport, because they can be easily serialised.
3.1504 +The receiving module of the system has only one method for
3.1505 +communication that handles all user interaction events. For each
3.1506 +event this method receives the appropriate "command object" as the
3.1507 +parameter and acts accordingly. This keeps the interface between
3.1508 +the objects simple and stable.
3.1509
3.1510 -% \item Show informations regarding a given \emph{Proof-State}. The
3.1511 -% proof-state containes certain informations about the state of a
3.1512 -% users calculation. The Problem is part of this state and can be
3.1513 -% presented and altered by the browser. So, the user can find the
3.1514 -% proper problem by browsing through the problem-tree and interpret
3.1515 -% the browsers feedback.
3.1516 +In case of \sisac{} Worksheet the "command objects" are called
3.1517 +Actions. The Actions can be sent from Worksheet Dialog to
3.1518 +Worksheet or vice versa. The actions sent from the Worksheet
3.1519 +Dialog to Worksheet are called UIActions and represent different
3.1520 +User Interface Elements the Worksheet needs to present to the
3.1521 +user. When the Worksheet receives the UIAction, it adds a widget
3.1522 +to the User Interface. To each of these widgets a certain
3.1523 +UserAction is assigned. When the User activates the widget, the
3.1524 +Worksheet makes sure that the proper UserAction is sent to the
3.1525 +Worksheet Dialog. The Worksheet self has no knowledge about the
3.1526 +meaning of the Action.
3.1527
3.1528 -% \end{itemize}
3.1529 +As already mentioned in this document, there is a strong
3.1530 +discrepancy in the architectural requirements set for the system.
3.1531 +The Presentation Layer should have no knowledge of the state in
3.1532 +which the dialogue currently is and the Dialogue Layer should have
3.1533 +no knowledge over such things as placement and
3.1534 +internationalisation. The solution is to establish a certain
3.1535 +hierarchy within the set of UIActions. This hierarchy lets the
3.1536 +Presentation Layer choose the widgets for representation, but
3.1537 +leaves the possibility for the Dialog Layer to choose the
3.1538 +circumstances in which the widget is available. Certain actions
3.1539 +are always available, like the actions applied to the entire
3.1540 +calculation, whereas other actions can only be performed on a
3.1541 +single (or even specific) formula, like changing the tactic or
3.1542 +assumption and are available only in certain dialogue phases.This
3.1543 +hierarchy is implemented in \sisac{} with "contexts". For example the
3.1544 +actions applied to the entire calculation have a certain context
3.1545 +and all such actions are rendered as push-buttons in the upper
3.1546 +part of the worksheet.
3.1547
3.1548 -% \item [services to access the informations from the
3.1549 -% description]. This services have to fetch the appropriate
3.1550 -% description-object and use the get-services to access the stored
3.1551 -% data.
3.1552 +It is important to note that according to Seeheim Model, the
3.1553 +Presentation Layer is not responsible for the context management,
3.1554 +so the context of a certain action is sent to the Worksheet as a
3.1555 +part of the UIAction object.
3.1556
3.1557 -% \item [services to access a given \emph{proof-state}] When the
3.1558 -% browser generates dynamic pages, he needs informations about the
3.1559 -% actual proofstate to adjust its output. As soon as the user changes
3.1560 -% the Problem, it also uses a service to change the proofstate to set
3.1561 -% the new Problem.
3.1562 +\begin{figure}[htb]
3.1563 +\centerline
3.1564 +{
3.1565 + \includegraphics[width=\textwidth,keepaspectratio=true]{fig/NC-Worksheet_WorksheetDialogue_Communication}
3.1566 +}
3.1567 +\caption{User Interface Events}
3.1568 +\label{fig.worksheet_ui_events}
3.1569 +\end{figure}
3.1570
3.1571 -% \item [(internal) services to generate the HTML-Pages] It is
3.1572 -% important to represent all informations in an clear
3.1573 -% way. Furthermore, the whole system should be presented in an
3.1574 -% consistent look \& feel. Therefore, the informations have to be
3.1575 -% gathered first, and are then put into a service which encodes them
3.1576 -% in HTML. The informations are passed inside a structure which
3.1577 -% containes the informations and assigned datatypes. The task
3.1578 -% HTML-creation is basicly done through filling in the proper datatype
3.1579 -% in the respective fields\footnote{This ``fields'' could be taken out
3.1580 -% of templates which describe a HTML-Page or (as first implementation)
3.1581 -% in an statically way. Anyway the creation should be encapsulated
3.1582 -% within an own service to enhance its behavour by and by}.
3.1583
3.1584 +\subsection {Calculation Events}
3.1585 +
3.1586 +Second part of the communication between the Worksheet and the
3.1587 +mathematical engine are the calculation events. They are fired
3.1588 +each time the mathematical engine has some data for the worksheet.
3.1589 +These events are handled asynchronously in a separate method of
3.1590 +the Worksheet. The asynchronous communication can have its
3.1591 +disadvantages. If the mathematical core processes several
3.1592 +different calculations from several users, the user may have to
3.1593 +wait several seconds for the result to appear. This can sometimes
3.1594 +be a serious usability problem. However, the major advantage is
3.1595 +that the asynchronous message passing allows for more parallelism.
3.1596 +
3.1597 +\section{Calculation views}
3.1598 +
3.1599 +According to the User Requirements, the user can start using the
3.1600 +Worksheet in two different modes:
3.1601 +
3.1602 +\begin{itemize}
3.1603 + \item the specifying phase
3.1604 + \item the solving phase.
3.1605 +\end{itemize}
3.1606 +
3.1607 +From the Worksheet of view the two modes are the same (like a
3.1608 +blank piece of paper). The Worksheet has no knowledge of the
3.1609 +current phase.
3.1610 +
3.1611 +\section{Calchead Panel}
3.1612 +
3.1613 +If the CalcHeadPanel is displayed because the user started a calculation from
3.1614 +scratch, then the user first has to \emph{model} the problem.
3.1615 +As specified in the User Requirements, the Calculation Model is
3.1616 +made up of the following fields :
3.1617 +
3.1618 +\begin{itemize}
3.1619 + \item 'given' which includes the input-items
3.1620 + \item 'where' which includes the pre-condition on the input-items
3.1621 + \item 'find' which includes the output-items
3.1622 + \item 'relate' which includes parts of the post-condition.
3.1623 +\end{itemize}
3.1624 +
3.1625 +To provide a full specification, the user must also make inputs about the problem type, the
3.1626 +theory that is necessary to solve the problem and the method on how to solve
3.1627 +the problem. Each input value is checked by the mathematical engine. If an
3.1628 +input value is incorrect or cannot be handled by the mathematical engine, then
3.1629 +the user has to be informed about this fact. So far \sisac{} can only inform
3.1630 +the user that something went wrong but is not in the position to provide help
3.1631 +to correct the problem.
3.1632 +
3.1633 +If the user wants to refine a problem or to match a problem,
3.1634 +then the model of the current example and the specified problem from the problem
3.1635 +hierarchy are compared against each other by the mathematical engine. The
3.1636 +task of the CalcHeadPanel is to colorize the fields which are either correct (match)
3.1637 +or not correct (do not match).
3.1638 +
3.1639 +%-------------------------------------------------------------------------------
3.1640 +\subsubsection{Implementation Details}
3.1641 +%------------------------------------------------------------------------------
3.1642 +
3.1643 +The CalcHeadPanel helps the user to model and specify a problem. If the user
3.1644 +decided to calculate a prepared example from the example hierarchy then
3.1645 +the CalcHeadPanel is already filled with values that are stored in the XML file
3.1646 +that represents the example (see listing~\ref{lst:exp}), otherwise the user
3.1647 +has to input all values that are necessary for a complete formalization of an
3.1648 +example.
3.1649 +
3.1650 +\lstinputlisting[language=ISACXML,caption=Representation of a particular example
3.1651 + from the example hierarchy in XML.,label=lst:exp]
3.1652 + {listings/MH-exp_IsacCore_Tests_1a.xml}
3.1653 +
3.1654 +It is very cumbersome to input a complete formalization; therefore, the
3.1655 +CalcHeadPanel has views with different detail levels for the
3.1656 +formalization of an example: A {\tt FullCalcHeadView}
3.1657 +in which all items of a formalization have to be input and a
3.1658 +{\tt SimpleCalcHeadView}. The {\tt SimpleCalcHeadView} provides a view
3.1659 +that is similar to existing algebra systems where the user has to
3.1660 +input only the example he wants to calculate (e.g. $x+1=2$). At the time of
3.1661 +this writing \sisac{} is only able to provide the {\tt SimpleCalcHeadView}
3.1662 +for equations.
3.1663 +
3.1664 +As soon as a complete and correct formalization has been entered, \sisac{} will
3.1665 +be able to calculate the formalized example and can go into solving phase.
3.1666 +
3.1667 +\subsubsection{Communication with the Calchead Panel}
3.1668 +
3.1669 +The Calchead Panel is an integral part of the Worksheet and
3.1670 +communicates with the Worksheet Dialog through aforementioned User
3.1671 +Interface and Calculation Events.
3.1672 +
3.1673 +\chapter{Knowledge Browser}\label{WN-add-Knowledge-Browser}
3.1674 +\section{Survey on the requirements}
3.1675 +\cite{AG:thesis} p.38 gives the following survey on the requirements as seen from an early stage of design.
3.1676 +
3.1677 +%%WN040815---AG->isac-ADD2-----------------BEGIN---please don't remove this line
3.1678 +A \isac\/-\emph{knowledge-browser} is used to enter the
3.1679 +\emph{knowledge} and gain information about the content and use of
3.1680 +the special \isac\/ System. %Although only HTTP-access is needed in the first phase of development, the design of the knowledge-browser must not limit the access to this channel.
3.1681 +The the design is split
3.1682 +into layers which separate the functionality of knowledge-gathering
3.1683 +and knowledge-presentation.
3.1684 +
3.1685 +A few points to keep in mind to understand the structure of the
3.1686 +design.
3.1687 +
3.1688 + \begin{itemize}
3.1689 +
3.1690 + \item multiple layer structure to ease exchangeability of the
3.1691 + knowledge-presentation
3.1692 +
3.1693 + \item Depending on their type, information is structured to different
3.1694 + hierarchies. An user can browse through the problems to gain an
3.1695 + overview about the capabilities of an \isac{} site, or view
3.1696 + the provided examples. Although this views might look logically
3.1697 + different for the user, the same software is used for all of them.
3.1698 +
3.1699 +% there are logically different browsers for different datatypes
3.1700 +% (problems, examples, \dots). Although they provide different types
3.1701 +% of informations and have autonomous navigation-trees, the same
3.1702 +% software is used for all of them - just the information (provided
3.1703 +% by the description) is adjusted on demand.
3.1704 +
3.1705 + \item A browser can either deliver static informations or react
3.1706 + interactively on each request.
3.1707 +%(see use cases for browsing the
3.1708 +% knowledge and finding a problem for a calculation\kommentar{referenz
3.1709 +% einfuegen})
3.1710 + Both modes require a filtering-mechanism to adjust the
3.1711 + delivered data. This mechanism is located inside the
3.1712 + \emph{dialog}. Reasons to block information include security reasons
3.1713 + (block information while an exam is in progress) as well as
3.1714 + educational reasons (do not swamp a user with examples he is not
3.1715 + expected to solve)
3.1716 +
3.1717 + \item A browser has different ``roles'' e.g. ``find a problem'' or
3.1718 + just browsing through the knowledge or the examples. %WN03.DROPPED: In case of an WEB-based browser, these roles have to be encoded within the request.
3.1719 +
3.1720 + \item The different roles require interaction with other \isac{}
3.1721 + modules. This interaction is established and controlled by the
3.1722 + dialog.
3.1723 +
3.1724 +% \item besides the links stored in the description, there are links to
3.1725 +% be automatically generated (item-keywords,\dots). Browsers have to
3.1726 +% determine on the fly if the destination is available (or suppress
3.1727 +% the generation of the link otherwise).
3.1728 +
3.1729 + \item the user can open a worksheet by clicking a link in the
3.1730 + browser-window. This call for a worksheet is tunneled through
3.1731 + \isac\/s dialogs to avoid direct communications between
3.1732 + frontend-applications. On the other way round, the worksheet might
3.1733 + call an browser (e.g. to find a matching problem) -- this leads to a
3.1734 + new BrowserWindow which is created by the dialog.
3.1735 +%\footnote{This
3.1736 +% requirement affords the \emph{session-controller} which uses an extra
3.1737 +% interface to the session-dialog as described in subsection
3.1738 +% \ref{ADD:session-dialog}}.
3.1739 +\end{itemize}
3.1740 +
3.1741 +%WN [... das ist eine Art Liste von Software-Requirements, oder ? Dann werden wir sie auch dort unterbringen, und von hier dorthin verweisen.]
3.1742 +%
3.1743 +% \subsection{Structure}
3.1744 +% This subsection describes the parts of the \emph{Browser}. As interface
3.1745 +%%WN [vom User her gesehen]
3.1746 +% to the Browser, a WEB-Browser is used (\emph{Browser-Window}). This
3.1747 +% interface is only exemplary %to gain a better understanding. WN:
3.1748 +% within this thesis. %WN end
3.1749 +% Other
3.1750 +% interfaces are possible (e.g. a shell-like interface).
3.1751 +%
3.1752 +% The knowledge browsers generate the user-interface for querying the
3.1753 +% knowledge and examples for static and dynamic purposes. By static
3.1754 +% browsing is meant: getting an overview of the content of \isac{} without
3.1755 +% interaction with the \emph{math-engine}. When the knowledge-browser
3.1756 +% is in dynamic mode, it creates HTML pages as reaction to the users
3.1757 +% input with interference of other \isac{} modules. If one and the same
3.1758 +% page is called twice, it might present different data depending on
3.1759 +% the users input and his history (e.g. which examples he solved)
3.1760 +%
3.1761 +% Upon this description, we recapitulate the main tasks of a WEB-based
3.1762 +% \emph{knowledge browser}.
3.1763 +%
3.1764 +% \begin{description}
3.1765 +% \item[HTTP-access] Queries are made through HTTP. This means we have
3.1766 +% to interpret the callers HTTP request to understand what the user
3.1767 +% wants, forward the request to the ``deeper'' layers and encode the
3.1768 +% result to HTML to be presented in a Browser-Window.
3.1769 +%
3.1770 +% \item[gathering the informations] Depending of the kind of request,
3.1771 +% different informations have to be gathered and combined to meet the
3.1772 +% users needs. e.g. if the user just wants to browse through the
3.1773 +% knowledge without doing any calculation, no connection to the
3.1774 +% MathEngine is necessary. It is enough to visualize the stored
3.1775 +% informations (see also subsection \emph{KE-STORE},
3.1776 +% \ref{ADD:ke-store}) %\kommentar{verweise auf UCs einfuegen}
3.1777 +%%WN [ .................. auch Verweise auf Usecases waren vielleicht informativ]
3.1778 +%
3.1779 +% \item[filter informations given to the user] We want to adjust the
3.1780 +% output to the users needs and permissions. Therfore we need a method
3.1781 +% to decide which informations should be given respectively which
3.1782 +% details are blocked. This mechanism also has to gather and store all
3.1783 +% the actions the user attempts within \isac{} to build up a history
3.1784 +% for judgment when an example is presented to the user \footnote{this
3.1785 +% is a task for the browser, but on the dialog-layer of the system --
3.1786 +% therefore, the \emph{browser-dialog} was created}.
3.1787 +%
3.1788 %\end{description}
3.1789 +%
3.1790 +% These tasks lead to the internal structure as given in figure
3.1791 +% \ref{ADD:fig-browser-int}. This figure shows the modules of the
3.1792 +% \emph{knowledge browser} and how the browser is embedded within
3.1793 +% \isac.
3.1794 +%
3.1795 +% \begin{figure} [htb]
3.1796 +% \begin{center}
3.1797 +% %\includegraphics[width=11cm]{\extend{fig/browser_int}}
3.1798 +% \psfig{figure=fig/browser_int.eps,width=11cm}
3.1799 +% \caption{parts of the browser} \label{ADD:fig-browser-int}
3.1800 +% \end{center}
3.1801 +% \end{figure}
3.1802 +%%WN [{(Decorated) Knowledge} statt 'Description']
3.1803 +%
3.1804 +% \subsection{BrowserFrontend} \label{BrowserFrontend} This module
3.1805 +% implements the information-encoding Layer. It takes the user-requests
3.1806 +% and forwards it to the information-processor. The resulting data is
3.1807 +% transferred in an open, XML-based format.\footnote{for more informations how to store mathematical informations see section \ref{xml-applications}}
3.1808 +%% which is discussed in more
3.1809 +%% detail in the Software Requirements Document.\kommentar{referenz zu
3.1810 +%% theoretischeren kapiteln ueber OmDoc XSLT usw.}
3.1811 +%
3.1812 +% The WEB-based browser is implemented as JAVA-Servlet which waits for
3.1813 +% HTTP connects from a client and decodes the request. The request has
3.1814 +% a \emph{command} which tells the browser what it should do (e.g. display
3.1815 +% informations about an example, find a problem for a running
3.1816 +% calculation, \dots) and an \emph{object} (which example should be
3.1817 +% displayed, which problem was selected, \dots). Additionally, the
3.1818 +% servlet contains sessions which identify the user and a state which
3.1819 +% can be used to store temporary settings.
3.1820 +%
3.1821 +% The task of creating a valid HTML-Page is encapsulated within the
3.1822 +% \emph{encoder} which utilizes XSLT to convert the XML-result. This
3.1823 +% enables us to customize the look of a site just by exchanging
3.1824 +% the XSL-Template.
3.1825 +%
3.1826 +% Besides the pure data, the XML-result can also contain layout-hints
3.1827 +% which affect the resulting HTML-output. This is necessary because we
3.1828 +% have different types of informations to be displayed.
3.1829 +%
3.1830 +% Additionally to the pure informations about a special item, also the
3.1831 +% structure has to be visualized. This happens in form of a tree which
3.1832 +% represents the hierarchical structure of the content. The nodes of
3.1833 +% this tree are used to jump directly to an other information-page. (as
3.1834 +% demanded in the UC described in section \ref{creating-frameset})
3.1835 +%
3.1836 +% \subsection{Information-processor}
3.1837 +% The \emph{information-processor} runs in the same visual machine as
3.1838 +% the BrowserFrontend and communicates with the Frontend through a well
3.1839 +% defined set of method calls. So, it exists one time per
3.1840 +% BrowserFrontend instance. It is separated into an own module because
3.1841 +% it summarizes the functions which are used by different types of
3.1842 +% \emph{browser-frontends}. The information-processor handles the
3.1843 +% communication with the remote \isac{} components. Strictly speaking
3.1844 +% it communicates with the \emph{browser-dialog} of the current user
3.1845 +% (determined with session-informations given by the browser-frontend)
3.1846 +% to gather all informations necessary for the current request.
3.1847 +%
3.1848 +% We want to allow that:
3.1849 +% \begin{enumerate}
3.1850 +% \item more than one user may access one BrowserFrontend (and thus the
3.1851 +% information-processor)
3.1852 +% \item more than one Browser-Frontends access one browser-dialog
3.1853 +% \end{enumerate}
3.1854 +%
3.1855 +% The first point is obvious. A Web-Server simply has to serve different
3.1856 +% users. The second decision is necessary to enable the system to run
3.1857 +% different BrowserFrontends concurrently (e.g. to reduce server-load of
3.1858 +% the WEB-server by using multiple WEB-servers which access the same
3.1859 +% \isac\/-system or to allow a user to access different types of
3.1860 +% Browser-Frontends --- WEB-based and a browser-shell ---
3.1861 +% concurrently).
3.1862 +%
3.1863 +% We may not store informations regarding an user within the
3.1864 +% information-processor but forward it to the respective
3.1865 +% browser-dialog. Otherwise, a (eventually existing) concurrent
3.1866 +% BrowserFrontend would not be able to access these data.
3.1867 +%
3.1868 +% Communication between information-processor and browser-dialog is
3.1869 +% done utilizing \emph{dinopolis}. So, the information-processor first
3.1870 +%%WN ~~~~~~~~~~~~~~~~ [fehlt in Fig.1.2.]
3.1871 +% has to request an object-proxy for the browser-dialog to communicate
3.1872 +% with. Administration of the dialogs for different users is done by
3.1873 +% the \emph{session-dialog}%\kommentar{ref einfuegen}
3.1874 +%\footnote{explained
3.1875 +% later in this section}.
3.1876 +%
3.1877 +% \subsection{Browser-dialog}
3.1878 +% The \emph{browser-dialog} is the peer for the browser within the
3.1879 +% dialog and gathers the informations for the request. Depending of the
3.1880 +% type of request, it contacts the \emph{KE-Store} and/or the
3.1881 +% WorkSheet-dialog. Afterwards, the informations are filtered depending
3.1882 +% a users actual permissions and duties. It is possible, that pages are
3.1883 +% blocked as a whole --- e.g. if an example is not accessible before an
3.1884 +% other one is solved. Alternatively, some fields might be blocked. e.g.
3.1885 +% if a learner has to find an problem while performing a test, he might
3.1886 +% see all available Problems -- but the dialog will suppress the fields
3.1887 +% which tell the user if (and why) an actual problem does not fit.
3.1888 +%
3.1889 +% The permissions are gained from different sources.
3.1890 +% \begin{itemize}
3.1891 +% \item The course-designer may define a group of users which may
3.1892 +% access an example.
3.1893 +%
3.1894 +% \item The course-designer may define preconditions before a example is
3.1895 +% displayed (e.g. a date, or a set of examples to solve first)
3.1896 +%
3.1897 +% \item The course-designer may set the user to use a ``temporary
3.1898 +% environment'' which alters all permissions to a set of
3.1899 +% \emph{KE-Objects}(e.g. while an exam)
3.1900 +%
3.1901 +% \item The dialog-layer maintains a user-history to find out which
3.1902 +%%WN ? dialog-state ~~~~~~~~~~~~
3.1903 +% examples and parts of the knowledge are already visited and solved.
3.1904 +% \end{itemize}
3.1905 +%
3.1906 +% The informations about a user are stored within the user-model.
3.1907 +% Informations like the history are not only gathered and used by the
3.1908 +% browser-dialog but by the whole dialog-layer.
3.1909 +%
3.1910 +% After collecting the informations, they are encoded to XML and passed
3.1911 +% to the \emph{information-processor}. Note, that this XML-document is
3.1912 +% adjusted to the current users needs.
3.1913 +%
3.1914
3.1915 -\section{description}
3.1916 -\label{ADD:description}
3.1917 -The description is responsible for handling of all information
3.1918 -presented by the Browsers. Its informations stem eigher from the
3.1919 -\isac\/-ME or from an author via the \emph{description-editor}.
3.1920 +%WN060705---summerterm06------------BEGIN---please don't remove this line
3.1921
3.1922 -The services offered by the description are mainly to be
3.1923 -devided in three groups.
3.1924 -\begin{description}
3.1925 - \item [synchronisazion with the ME] these methods handle the
3.1926 - communication with the SML-part of \isac{}. The
3.1927 - problem-tree\footnote{the same method has to be applicable for
3.1928 - different types of informations stored inside the \emph{ME} the
3.1929 - problem tree is solely the first task to be investigated} has to be
3.1930 - parsed to find new problem-descriptions or modifications to existing
3.1931 - ones. Following tasks have to be implemented:
3.1932 +\section{Kinds of browsers and their differences}\label{WN-add-browsers}
3.1933 +The task of the browsers is to provide acces to the KEStore, see chap.\ref{} and reflects the
3.1934 +
3.1935 +The browsers for the four parts of knowledge, for examples,
3.1936 +theories, problems and methods look very similar: they display a
3.1937 +hierarchy containing all elements of the respective part and an
3.1938 +element if selected in the hierarchy.
3.1939 +
3.1940 +The browsers all work very similar; the most significant
3.1941 +difference is in the interactions available (for instance, there
3.1942 +is a $<$Refine$>$ button on the ProblemBrowser only). But as the
3.1943 +front-end has no idea about the meaning of buttons and other
3.1944 +interactive elements, the difference can be neglected.
3.1945 +
3.1946 +%WN051010---RK->isac-ADD-----------------BEGIN---please don't remove this line
3.1947 +\footnote{Begin of \cite{ba-RK06} p....-- p....}
3.1948 +
3.1949 +\section{Browsers and dialogs}\label{WN-add-browsers-and-dialogs}
3.1950 +The architecture of the browsers and their dialogs is shown in
3.1951 +figure \ref{fig.RK-browsers-add} and \ref{fig.RK-browserdialogs-add} and shall be discussed here. Note, that
3.1952 +not all attributes and methods of the classes are shown in the diagrams for simplicity.
3.1953 +
3.1954 +\begin{figure}[htb]
3.1955 +\centerline{\includegraphics[width=0.95\textwidth, keepaspectratio=true]{fig/poseidon/RK-browsers}}
3.1956 +\caption{The Design of the Browsers}
3.1957 +\label{fig.RK-browsers-add}
3.1958 +\end{figure}
3.1959 +
3.1960 +\begin{figure}[htb]
3.1961 +\centerline{\includegraphics[height=\textwidth, keepaspectratio=true,angle=270]{fig/poseidon/RK-browserdialoges}}
3.1962 +\caption{The design of the Browserdialogs}
3.1963 +\label{fig.RK-browserdialogs-add}
3.1964 +\end{figure}
3.1965 +
3.1966 +The browsers are built totally equal.
3.1967 +The way, elements of the knowledge base or the
3.1968 +example collection are presented should be equal anyway. The only thing that differs is the
3.1969 +behavior of some elements (e.g. the buttons) and their content, they are displaying.
3.1970 +The browser itself does not care about the meaning of the
3.1971 +elements it is showing. The meaning of the elements is only known by the dialog,
3.1972 +controlling the browser. That fact, that the browsers are all built equal can be taken as
3.1973 +an indication that the representation of the elements is separated well from their meaning.
3.1974 +
3.1975 +\subsection{Communication between Browsers and Dialogs}
3.1976 +The browser and the browserdialog communicate over Java RMI (Remote Meth\-od Invocation) \cite{WN061010.TODO}.
3.1977 +This is a Java technology to call methods of objects, which do not have to run on the
3.1978 +same Java Virtual Machine, they do not even have to run on the same physical device.
3.1979 +Whenever information has to be passed from the browser to the dialog, the \verb'notifyUserAction()'
3.1980 +method of the \verb'IBrowserDialog' interface is used to pass a \verb'UserAction'. There
3.1981 +are different kinds of \verb'UserActions' carrying different information.
3.1982 +Whenever information has to be passed from
3.1983 +the browser dialog to the browser, the \verb'IToGuiInterface' implemented by the \verb'BrowserFrameRMI'
3.1984 +is used to hand over a \verb'UIAction'. The \verb'UIAction' carries a \verb'EUIContext', which is
3.1985 +implemented as enumeration. It determines, which component of the browser the
3.1986 +\verb'UIAction' concerns. The \verb'UIAction' is forwarded to this component, where it is
3.1987 +finally handled.
3.1988 +
3.1989 +\subsection{Binding a Browser to a Dialog}
3.1990 +The binding of a browser to the according browser dialog happens after login. The \verb'login()' method of
3.1991 +the \verb'UserManager' creates a new \verb'Session' and returns an interface to this session.
3.1992 +The \verb'WindowApplication'
3.1993 +registers to the session by use of the \verb'registerBrowserFrame((IToGUI) this)' method, passing
3.1994 +itself. The session does now execute the \verb'initializeWindowApplication()' method
3.1995 +which calls the \verb'openNewBrowserFrame()' method for all four kinds of browser, passing the
3.1996 +according dialog. A new \verb'BrowserFrame' is created, taking the according dialog as argument of
3.1997 +the constructor. The \verb'registerBrowserFrame()' method of the dialog is called to register
3.1998 +an interface to the \verb'BroserFrame' for the dialog.
3.1999 +
3.2000 +This explanation might sound frightening at first. However, it
3.2001 +leads to a clear separation of the tasks. The browsers do not need
3.2002 +to know anything about the dialogs except of an interface to pass
3.2003 +\verb'UserActions'. The dialogs do not need to know anything about
3.2004 +the browsers except of an interface to pass \verb'UIActions'. The
3.2005 +\verb'WindowApplicaion' does only know the browser but not the
3.2006 +dialogs. The session does only know the dialogs but not the
3.2007 +browsers themselves.
3.2008 +
3.2009 +\subsection{The Processing of Links}
3.2010 +Whenever a link is selected, the \verb'Minibrowser' creates a \verb'UserActionOnLink'. How
3.2011 +this is actually done, and how the \verb'Minibrowser' works, can be read in \ref{sec.RK-hmtl-in-java}.
3.2012 +The \verb'UserAction' is sent to the according dialog, where it is evaluated.
3.2013 +
3.2014 +Whenever a dialog
3.2015 +decides to display a link target in its registered browser, an \verb'UIActionOnLink' containing the
3.2016 +link target is sent to the \verb'BrowserFrameRMI'. The \verb'EUIContext' of this object is set
3.2017 +to UI\_CONTEXT\_MINIBROWSER, so it is forwarded to the \verb'Minibrowser', where the page is finally
3.2018 +loaded.
3.2019 +
3.2020 +\footnote{End of \cite{ba-RK06} p....-- p....}
3.2021 +%WN051010---RK->isac-ADD-----------------END---please don't remove this line
3.2022 +
3.2023 +
3.2024 +
3.2025 +
3.2026 +
3.2027 +
3.2028 +
3.2029 +
3.2030 +
3.2031 +
3.2032 +
3.2033 +
3.2034 +
3.2035 +
3.2036 +
3.2037 +
3.2038 +
3.2039 +
3.2040 +
3.2041 +
3.2042 +
3.2043 +%WN000705---summerterm06--------------END---please don't remove this line
3.2044 +
3.2045 +
3.2046 +
3.2047 +%%%%%%%%%%%%%%%%%
3.2048 +%% KE-Store, KE-Objects
3.2049 +%%%%%%%%%%%%%%%%%
3.2050 +
3.2051 + \chapter{KE-Store}\label{ADD:ke-store}
3.2052 +%WN [siehe oben {Decorated Knowledge(base)} := Knowledge(base) + Explanations ?
3.2053 +%WN Falls wir das so benennen, waere das Folgende von einigen Aenderungen betroffen, die ich nicht angemerkt habe ...]
3.2054 +%WN000705---summerterm06------------BEGIN---please don't remove this line
3.2055 +\section{Notes WN}
3.2056 +These notes are an {\em un}-structured collection of (user- and software-) requirements and (architectural- and software-) design consideration\footnote{These notes where compiled as a prerequesite for re-designing the dialoguies in the \sisac{} summerterm 06}.
3.2057 +\begin{itemize}
3.2058 +\item The (K)(E)(Stor)e encapsulates a database (stor)ing \isac s mathematics (K)nowledge and the (E)xamples.
3.2059 +\item The elements of the knowledge are given by the need of \sisac s mathematics engine to automatically solve the examples in the KEStore.
3.2060 +\item See the user requirements in sect.\ref{WN-urd-KEStore}
3.2061 +\item The hierarchy of examples can be rearranged for specific courses
3.2062 +\item Each element of the KEStore knows the respective path in the (current -- examples!) hierarchy.
3.2063 +\item The elements of the KEStore store sufficient information on formatting for automated generation of the presentation of single elements as well as for collections of elements.
3.2064 +\item The generation of the presentation format is located in the system as close to the front-end as possible (in order to feature dfferent formats like html, pdf etc).
3.2065 +\item The access to the database (internal to the KEStore) is encapsulated by methods of the KEStore. The arguments carry the course (the student is assigned to), the time (for time constraints during exams) etc. The return values of these methods may be up to additional filtering and subsequent calls of specific methods.
3.2066 +\item
3.2067 +\item
3.2068 +\item
3.2069 +\end{itemize}
3.2070 +
3.2071 +\section{The initial structure with xml- and html-files}\label{WN-add-KEStore-old}
3.2072 +
3.2073 +
3.2074 +%WN000705---summerterm06--------------END---please don't remove this line
3.2075 +
3.2076 +\section{Some old design considerations}\footnote{Design considerations from \cite{AG:thesis} p.43-53.}
3.2077 +
3.2078 + This module is used to store and provide all static informations within \sisac, a user can
3.2079 + obtain. Informations are supplied to the \emph{KE-Store}\/-module
3.2080 + by either importing them from XML or entering them directly through
3.2081 + an \isac{}-KE-Object-editor
3.2082 +
3.2083 + Parts of the content contain mathematical informations
3.2084 + (\emph{formalization}\/s) along to \emph{descriptions} and
3.2085 + \emph{explanations}. Though the details of attached informations
3.2086 + vary, all objects are handled in an similar way. Therefore, the
3.2087 + umbrella term \emph{KE-Object} is introduced. Different types are
3.2088 + described in the following:
3.2089 +
3.2090 + \begin{description}
3.2091 + \item[simple KE-Object] Is a collection of informal data without any
3.2092 + mathematical information (no \emph{formalization}). It can be used
3.2093 + to build up explanations of any content.
3.2094 +
3.2095 + \item[Knowledge] \isac \emph{knowledge} is taken from the
3.2096 + mathematics-knowledge-base and consists solely of formal
3.2097 + information. There are different types of mathematical knowledge
3.2098 + which build up the three dimensions of the \isac{}-KB.
3.2099 + %\kommentar{referenz zu den 3 dimensionen}
3.2100 +
3.2101 + This informations reflect the knowledge of the math-engine, but a
3.2102 + possible change to the informations will not change any
3.2103 + informations within the KB! Therefore, \emph{knowledge}\/
3.2104 + informations have to be immutable to avoid
3.2105 + ambiguities\footnote{\emph{knowledge-objects} are synched with the
3.2106 + \emph{KnowledgeBase} using unique identifiers}.
3.2107 +
3.2108 + \item[Decorated Knowledge]a course-designer or maintainer of an
3.2109 + \isac{} site can add a informal \emph{explanation} to the
3.2110 + mathematical knowledge. This combination is called \emph{decorated
3.2111 + knowledge}
3.2112 +
3.2113 + \item[Examples] An \emph{example} consists of the an informal
3.2114 + \emph{description} to tell the user what to do and an formal
3.2115 + representation (\emph{formalization}) to enable the MathEngine to
3.2116 + solve it.
3.2117 +
3.2118 + There is a special form of examples called
3.2119 + \emph{composite-examples} which are used to describe examples which
3.2120 + are partitioned to several parts (a., b., c., \dots). More details
3.2121 + on that in subsection \ref{ADD:example-collections}
3.2122 +
3.2123 + \item[Example Collections] As the name suggests, a \emph{example
3.2124 + collection} is a object to combine a number of examples to
3.2125 + collections. It does not contain any mathematical informations. An
3.2126 + example can appear an arbitrary number of example-collections.
3.2127 +
3.2128 + \end{description}
3.2129 +
3.2130 + All objects can contain additional informations like images or
3.2131 + descriptions to enhance the understandability. These infos are
3.2132 + attached using the \emph{presentation} and reference to extra data
3.2133 + (images).
3.2134 +
3.2135 + \paragraph{hierarchy:} \emph{KE-store-object}\/s are used
3.2136 + to build up the learning-environment for the user. The compilation of
3.2137 + the proper parts is achieved using the \emph{hierarchy-object} which
3.2138 + combines the single items to an hierarchy and provides the basis for
3.2139 + a tree-like navigation through the content.
3.2140 +
3.2141 + There are some standard-hierarchies which reflect the structure of
3.2142 + the knowledge of the MathEngine. These hierarchies are maintained by
3.2143 + the math-engineers within the SML-part of the system and only synched
3.2144 + with them. Vice versa, a change on the explanations will \textbf{not}
3.2145 + change the knowledge! Therefore these hierarchies may not be changed
3.2146 + (like the \emph{KE-objects}, the ``nodes'' of these hierarchies)
3.2147 +
3.2148 +%WN [^^^ die obigen Absaetze moechte ich mit Dir noch umformulieren. Weiter bin ich jetzt nicht gekommen]
3.2149 +
3.2150 + \subsection{XML-Import/Export}
3.2151 + \label{ADD:xml-in-ex}
3.2152 + \emph{KE-Objects} can be imported and exported from and to XML.
3.2153 + They contain informal data which are enriched by a set of tagged
3.2154 + formulas which contain the mathematical meaning necessary to solve
3.2155 + it. This summary of data can be transferred to the
3.2156 + MoWGLI XML-format which provides a
3.2157 + machine-readable and machine-\emph{understandable} way to present
3.2158 + mathematical documents. Export can also be used to transfer the
3.2159 + informations to an other \isac{}-engine (the destination
3.2160 + \isac{}-system has to have the necessary mathematical capabilities
3.2161 + which can not be ensured by the document-format.
3.2162 +
3.2163 + The different types can be treated in very similar ways -- they
3.2164 + differ only in the amount of given data. In case of an import of
3.2165 + \emph{knowledge}, the resulting \emph{KE-Object} has to be
3.2166 + write-protected to avoid any alteration.
3.2167 +
3.2168 + Objects like \emph{problems} and \emph{examples} contain a
3.2169 + formalization which consists of tags and related pieces of
3.2170 + information -- most likely formulas. These formulas are also
3.2171 + encoded in MoWGLI. The tags have to be preserved because they give
3.2172 + the meaning to the formulas.
3.2173 +
3.2174 + Parts of the content (like images and links to related examples) are
3.2175 + implemented using textual references. So, unique identifier for all
3.2176 + KE-Objects have to be used to store this relations in an textual
3.2177 + form.
3.2178 +
3.2179 + Note, that the dialog can add automatically generated references
3.2180 + which are not part of the KE-Object and though not stored within the
3.2181 + export-file.
3.2182 +
3.2183 + The \emph{hierarchies} have a different structure than KE-Objects and
3.2184 + are stored in own documents. Again, unique identifiers are necessary
3.2185 + to restore the references. When an hierarchy is exported, its
3.2186 + referenced KE-Objects can be exported in own files in the same
3.2187 + operation.
3.2188 +
3.2189 + \begin{figure} [htb]
3.2190 +\begin{center}
3.2191 +% \centerline{
3.2192 +\psfig{figure=fig/description_structure.eps,width=11cm}
3.2193 +%\includegraphics[width=11cm]{\extend{fig/description_structure}}
3.2194 + \caption{parts of the \emph{KE-Store} module} \label{ADD:descr-structure}
3.2195 +\end{center}
3.2196 + \end{figure}
3.2197 +
3.2198 + \subsection{Communication with the \emph{dialog}}
3.2199 +
3.2200 + To communicate with the rest of the system, the informations are put
3.2201 + into a hierarchy of (\emph{dinopolis})-objects which are transferred
3.2202 + to the dialog (again using \emph{dinopolis}). These objects can cope
3.2203 + with the dialogs need of restricting several kinds of details. The
3.2204 + object-structure is finer grained than the junks within the
3.2205 + underlying XML-Structure. e.g. it keeps its formulas in own objects.
3.2206 +% More details on this are given within the SDD.
3.2207 +
3.2208 + These objects also can be modified (with sufficient access-rights) by
3.2209 + an example-author or a course-designer. Also, new \emph{KE-Objects}
3.2210 + can be created. Several constraints on edition of examples have to be
3.2211 + mentioned.
3.2212 +
3.2213 \begin{itemize}
3.2214 - \item query the \emph{ME}
3.2215 - \item interpret the \emph{ME}\/s result
3.2216 + \item there is a maximum of one client at a time which is allowed to
3.2217 + alter an object. This is because if two editors alter an object
3.2218 + concurrently, they would overwrite each others changes. (A lock is
3.2219 + required)
3.2220
3.2221 - \item alter a existing problem-description (only visible inside the
3.2222 - package - only used by description-object)
3.2223 + \item if an object is changed, all users of the object have to be
3.2224 + informed to update their representation.
3.2225
3.2226 - \item create a new description-record.(only visible inside the
3.2227 - package - only used by description-object)
3.2228 - \end{itemize}
3.2229 -
3.2230 - \item [create and maintain navigation-trees] The description
3.2231 - containes a hierarchy for each of \isac s main branches of the
3.2232 - knowledge base which are generated automatically out of the ME.
3.2233 - Additionally, there are other hierarchies which can be created by
3.2234 - course instructors. These hierarchies are either created through
3.2235 - copying from an existing one (for example if an part of the
3.2236 - problem-tree is covered in an course) or they are created from
3.2237 - scratch (e.g. to build a new example-collection). Parts of the
3.2238 - hierarchy can be locked, if a course instructor wants to present the
3.2239 - content in well sized chunks.
3.2240 -
3.2241 - \item [provide the na\-vi\-ga\-tion-trees to other java-layers in the
3.2242 - system] Na\-vi\-ga\-tion-trees are maintained and provided seperated
3.2243 - to the actual informations and are represented as an own kind of
3.2244 - data. This enables the system to build up a the tree fast without
3.2245 - parsing all contained records. Further, this disconnects content with
3.2246 - naming. e.g to use examples within different example-collections with
3.2247 - a different naming. Such a navigation-tree can be loaded seperated.
3.2248 -
3.2249 - \item [offering the data-records to other java-layers in the system]
3.2250 - once the informations are gathered, the description has to
3.2251 - provide access to the other java-modules which enable the user to
3.2252 - display or alter the informations. The real storage of the data is
3.2253 - internal. All access to this informations are channeled through the
3.2254 - \emph{description-object}. Concurrent access to a single datarecord
3.2255 - is led to one and the same description-object which forwards
3.2256 - qualified requests to the description. Following services
3.2257 - have to be provided to satisfy these requirements. \begin{itemize}
3.2258 - \item request a description-object for a particular problem
3.2259 -
3.2260 - \item request the creation of a new description-record (for
3.2261 - instance a new example) - this also includes the maintenance of a
3.2262 - tree (the new recored has to be attached to a tree to reach it
3.2263 - afterwards). It is not allowed to attach a new node everywere. The
3.2264 - problemtree must not be changed by the java-part of the system but
3.2265 - only from the knowledge-base !
3.2266 -
3.2267 - \item communicate with the description-objects.
3.2268 + \item the structure of the knowledge may not be altered. These
3.2269 + informations are stored within the SML-part and are only changed by
3.2270 + the math-engineers. To keep the storages in sync, unique identifiers
3.2271 + have to be used.
3.2272
3.2273 \end{itemize}
3.2274
3.2275 - \item [administer the contained data-records] Although a uniform
3.2276 - interface for different data has to be provided, the datarecords may
3.2277 - differ in terms of their contained data. While a simple prosa
3.2278 - description of a used method is free in the usage of different media
3.2279 - (text, images, ...), a problem-description must contain special
3.2280 - informations to be valid. Additionaly, the informations have to be of
3.2281 - a special type. The description has to offer services which
3.2282 - ensure the consistency of these data. It must provide the information
3.2283 - which types of data a record has to contain, respectively which data
3.2284 - it might contain. (there might be mandatory and optional fields)
3.2285 + The object-representation can also be generated out of XML-files
3.2286 + without storing them within the \emph{KE-Store}-module. The interface to
3.2287 + the Dialog keeps the same but without the ability to change the
3.2288 + information. A module like that can be used to calculate an external
3.2289 + example ``on the fly'' (e.g. out of the ActiveMath system
3.2290 + ) if it contains the proper
3.2291 + formalization.
3.2292
3.2293 -\end{description}
3.2294 + \subsection{Relations}
3.2295 +\label{ADD:relations}
3.2296 + Contained items can be interlinked in various ways. On the one hand,
3.2297 + there are hierarchical structures which can be used to provide an
3.2298 + ``navigation-tree''. A structure like this is given by the
3.2299 + \emph{problem}\/-tree. Each node (except the root-node) has an
3.2300 + ``ancestor'' and an arbitrary number of child-nodes. In case of the
3.2301 + mathematical data, these structures are given and may not change, in
3.2302 + case of an example-hierarchy, a course-designer may change them -
3.2303 + respectively each course has a own hierarchy (an example can
3.2304 + appear on different places on different hierarchies)
3.2305
3.2306 -\subsection{description-object}
3.2307 -The description-object acts as ``wrapper'' for the description
3.2308 -records. It provides services to access as well as change the stored
3.2309 -descriptions. There must be a way to inform interested modules about a
3.2310 -datachange (A \emph{description-editor} has opened a description while
3.2311 -it changes $\rightarrow$ the displayed information has to be
3.2312 -updated). Concurrent change of a record is prohibited to avoid
3.2313 -inconsistency - therefore the description-object has to provide a kind
3.2314 -of ``writelock'' to ensure that only one module is allowed to change a
3.2315 -description at one time. Following kinds of services have to be
3.2316 -implemented to satisfy these requirements:
3.2317 -\begin{description}
3.2318 - \item [communication with the \emph{description}] to forward
3.2319 - get- and change-requests (package-internal methods)
3.2320 + On the other hand, relations can be located within an object. They
3.2321 + are part of the object. For example if a \emph{KE-Object} contains
3.2322 + links to related examples.
3.2323
3.2324 - \item [get-service for other Java-modules] namely the Browsers and
3.2325 - the description-editor. These methods provide access to the
3.2326 - different datafields inside a description record. As the records are
3.2327 - different from case to case and can change by and by there should
3.2328 - not be one get Method per datafield but one method with a parameter
3.2329 - which identifies the field to be read. Additionally there is a
3.2330 - Service needed to gain informations which fields are present
3.2331 - respectively which type they have.
3.2332 + Both types of relations can be suppressed by the \emph{dialog}.
3.2333 + Respectively it can choose which ones it shows. Again, this
3.2334 + decision depends on a users experience/permissions and a
3.2335 + course-designers intentions.
3.2336
3.2337 - \item [alter-service for other Java-modules] namely the
3.2338 - \emph{description-editor}. This service has to satisfy the same
3.2339 - constraints as the get-service. It should take informations for
3.2340 - different datafields and provide the information which informations
3.2341 - a record can take. Additionally, submitted data has to be checked
3.2342 - for its correct datatype and the writelock has to be maintained.
3.2343 + Relations within \isac{} are realized as dinopolis-references. When
3.2344 + they are exported, they are stored in their unique
3.2345 + textual-representation.
3.2346
3.2347 -\end{description}
3.2348
3.2349 -\section{Dialog}
3.2350 -\label{ADD:dialog}
3.2351 -The behaviour of the whole System is controlled by a \emph{Dialog} to
3.2352 -enable the System to adjust its reaction to the learners (and
3.2353 -teachers) demands. Among others, these demands contain
3.2354 -\begin{description}
3.2355 - \item [record a learners success] by means of solved examples. This
3.2356 - record can be used to create a set of proposed examples for a single
3.2357 - user. Furthermore, the teacher can use this feedback to enhance the
3.2358 - quality of his lecture (e.g if a single example causes problems for
3.2359 - most students)
3.2360 + \subsection{Presentation}
3.2361 + The Presentation has to meet several requirements depending on the
3.2362 + object to show. While \emph{problems} (like the other automatically
3.2363 + created informations) have a uniform appearance and a known set of
3.2364 + informations, \emph{examples}, \emph{simple KE-Objects} and
3.2365 + especially \emph{example\_collections} have a higher need of
3.2366 + individual layout. The requirements are even hardened because of the
3.2367 + dynamic parts of this informations.
3.2368
3.2369 - \item [restrict access to parts of the knowledge] The set of
3.2370 - available examples can vary depending on the already solved examples
3.2371 - or the progress of the lecture to ensure, that the student is not
3.2372 - swamped with examples he is not ment to solve yet. Furthermore, the
3.2373 - available informations have to be restricted while the learner
3.2374 - writes a test. This also implies, that the access for not
3.2375 - authenticated users can be restricted as well (by IP). (The user may
3.2376 - not access the public informations)
3.2377 + The uniform presentation of the mathematical data can be left to the
3.2378 + browser which transforms the data using templates.
3.2379
3.2380 - \item [communication between different applications] \isac{} uses
3.2381 - different applications to access the knowledge and mathematical
3.2382 - capabilities of the system. At least two of them have to communicate
3.2383 - with each other. From the users point of view, the worksheet
3.2384 - calculates while the knowledgebrowsers are used to select problems
3.2385 - or methods for use within the calculation. In this case, worksheet
3.2386 - and knowledgebrowser are just two access-points for the same
3.2387 - application. The dialog establishes the connection of these
3.2388 - access-points.
3.2389 -\end{description}
3.2390 + Other data has to be enriched with layout-hints which have to be
3.2391 + preserved on its way through the dialog. This can be accomplished by
3.2392 + adding an layout-template with ``slots'' to fill the informations in.
3.2393 + If an detail is suppressed by the dialog, default-values have to be
3.2394 + given.
3.2395
3.2396 -These considerations lead to the component-layout as given in figure
3.2397 -\ref{ADD:dialog-structure}. Although the ``browser'' runs on the
3.2398 -server, it is situated in the frontend-layer. The reason is that the
3.2399 -Web-Based knowledge-browser as discussed in this state of development,
3.2400 -could be replaced by an browser with an other interface. This may not
3.2401 -affect the overall design of the system.
3.2402 + This template has to be created by the example-, respectively the
3.2403 + KE-Object-editor which is the only one who knows how to present its
3.2404 + informations in the proper way.
3.2405
3.2406 -\begin{figure} [htb]
3.2407 -\centerline{\psfig{figure=fig/browser-masterdialog.eps,height=11cm}}
3.2408 -\caption{Structure of the Dialog}
3.2409 -\label{ADD:dialog-structure}
3.2410 -\end{figure}
3.2411 + It is important to mention that presentations can be ``nested''. This
3.2412 + means, hat a document is created out of a number of objects. This
3.2413 + mechanism is obvious when we look at a \emph{KE-Object} which
3.2414 + contains formulas.
3.2415
3.2416 + \begin{figure} [htb]
3.2417 +\begin{center}
3.2418 +% \centerline{
3.2419 +\psfig{figure=fig/nested_presentation.eps,height=6cm}
3.2420 +%\includegraphics[width=7cm]{\extend{fig/nested_presentation}}
3.2421
3.2422 -\subsection{Session-Dialog}
3.2423 -The \emph{session-dialog} governs the user-login and performs all
3.2424 -necessary actions to build up a users dialog. It is started on
3.2425 -system-startup and waits for connects by an
3.2426 -\emph{session-controller}. There is only one session-dialog per
3.2427 -\isac\/-System.
3.2428 +%}
3.2429 + \caption{nested presentation} \label{ADD:nested-presentation}
3.2430 +\end{center}
3.2431 + \end{figure}
3.2432
3.2433 -The session-controller is a client-side program which performs the
3.2434 -login and starts the \isac{} frontend-applications on a users machine.
3.2435 -Besides the authentification, the session-dialog is also responsible
3.2436 -to instantiate and interlink the application dependend parts of the
3.2437 -dialog-layer as there are the Browser-Dialog and the WorkSheet-Dialog.
3.2438 + The enclosing object is the description which contains both
3.2439 + text blocks and fields which contain references to the formula and
3.2440 + the image. When the document is to be displayed (creation of am
3.2441 + HTML-Document), the formula is asked for its presentation (which
3.2442 + most likely results in an MathML - text).
3.2443
3.2444 -Although one user can log in twice at a time, only one application
3.2445 -dialog is created to ensure that all user-dependent informations are
3.2446 -up to date. Therefore the session-dialog has to maintain lists of
3.2447 -logged in users ant their respective dialogs.
3.2448 + This mechanism is expandable to more general cases --
3.2449 + \emph{KE-Objects} can be used to set up the layout by just generating
3.2450 + the frames to put other object presentations in. Objects like this
3.2451 + will be used to give an visible context for other objects like e.g.
3.2452 + to summarize different sections to one page or building up an
3.2453 + \emph{example-collection}\footnote{more details on example
3.2454 + collections and composite examples see subsection
3.2455 + \ref{ADD:example-collections}}
3.2456
3.2457 -\subsection{Browser-Dialog}
3.2458 -These requirements demand that the Dialog is involved in all
3.2459 -user-activities. Therefore, the Dialog ``sticks'' behind the Browser
3.2460 -and determines the way of information-representation. Nevertheless,
3.2461 -the Browser has different ``modes'' which need more or less
3.2462 -interferance of the Dialog.
3.2463 + To accomplish this behavior, the layouter has the option to either
3.2464 + create an link to an embedded object, or to make it ``in-line''.
3.2465 +% presentation eines unterbeispiels: wenn nur das unterbeispiel dargestellt
3.2466 +% wird, dann kann das unterbeispiel ``anfordern'', dass das uebergeordnete
3.2467 +% beispiel sich darstellt und nur das aktuelle unterbeispiel einbindet ?
3.2468 +% oder parametrisierte links auf die uebergeordneten beispiele mit angabe
3.2469 +% welche teile dargestellt werden sollen ?
3.2470
3.2471 -\begin{figure} [htb]
3.2472 -\centerline{\psfig{figure=fig/browser-dialog.eps,width=11cm}}
3.2473 -\caption{Interaction with the Browser-Dialog}
3.2474 -\label{design}
3.2475 -\end{figure}
3.2476
3.2477 -\begin{description}
3.2478 - \item[static knowledge-browsing] is access to the knowledge allowed
3.2479 - - determine and select additional informations (fitting descriptions
3.2480 - and examples), log access.
3.2481 +% ``kurz'' oder langpresentation.
3.2482 +% links werden entweder als hyperlinks
3.2483 +% dargestellt oder ``inline'' eingebunden
3.2484
3.2485 - \item[search an item] determine the amount of help to give, log
3.2486 - access. The ``amount of help'' includes the representation of
3.2487 - additional information as well as the presentation of
3.2488 - ``match-results''. Matching is done through contacting the
3.2489 - \emph{WS-Dialog} which holds the necessary informations to perform a
3.2490 - match.
3.2491 + \subsection{Example Collections and composite examples}
3.2492 + \label{ADD:example-collections}
3.2493 + Example collections are used to summarize related examples to one
3.2494 + page. This page can be designed to match a given layout -- e.g. to
3.2495 + ease the visual matching between an example-subsection in a textbook and
3.2496 + the presented corresponding \isac{}-page. The contained examples are
3.2497 + stored as references to them.
3.2498
3.2499 - \item[select an item] ``push it into the model'' contact the
3.2500 - responsible \emph{WS-Dialog} and ``offer'' the selected item (Problem,
3.2501 - Method, \dots). This Mode needs to know the responsible worksheet in
3.2502 - first place. The user could run more then one worksheet at a time -
3.2503 - so the Browser needs to know to which one the selected item should
3.2504 - be passed.
3.2505 -\end{description}
3.2506 -So, the Dialog is a part of the browser but has a fix set of
3.2507 -responsibilities and a clear interface: It holds the functions to
3.2508 -access the data but does not constrain the browsers mode and least of
3.2509 -all the presentation of the gathered informations.
3.2510 + An example-collection does not have any mathematical informations
3.2511 + about its content - it is just used to summarize and layout a set of
3.2512 + related examples.
3.2513
3.2514 -\subsection{WorkSheet Dialog}
3.2515 -The worksheet-dialog contains the ``intelligence'' of the Worksheet.
3.2516 + \emph{Composite examples} go a step further. A composite example is
3.2517 + for instance a text example which defines a task and a set of
3.2518 + sub items (a.), b.), c.) ) which define what to solve.
3.2519
3.2520 -\subsection{Description and external Informations}
3.2521 - \isac gets its math-descriptions out of the \emph{description} module
3.2522 - which processes the stored informations and builds an
3.2523 - object-structure for the dialog to work with. The process of building
3.2524 - up the internal structure can also be based upon well structured
3.2525 - Documents like MathML and OMDoc. Vice versa, an export into an
3.2526 - XML-format is necessary to utilize the rich set of already built
3.2527 - utilities. The first process is used to import informations from
3.2528 - external information-sources like ActiveMath. The export to XML can
3.2529 - be used to render the output for representation as used for the
3.2530 - Browsers.
3.2531 + \begin{figure} [htb]
3.2532 +\begin{center}
3.2533 +% \centerline{
3.2534 +\psfig{figure=fig/composit_examples.eps, width=7cm}
3.2535 +%\includegraphics[width=8cm]{\extend{fig/composit_examples}}
3.2536
3.2537 -\section{The browser generators}
3.2538 -%W.N.: dieser Abschnitt ist f''ur A.G. + W.N.
3.2539 + \caption{composite examples} \label{ADD:composit-examples}
3.2540 +\end{center}
3.2541 + \end{figure}
3.2542
3.2543 -\subsection{}
3.2544 + Examples like this are split into two parts:
3.2545 + \begin{description}
3.2546
3.2547 -\subsection{}
3.2548 + \item [description] Describes the task of the example in an informal
3.2549 + (usually text, formulas and images) way. It does not have any
3.2550 + formal information about the task it describes. The full
3.2551 + \emph{formalization} is stored within the sub-examples. Though, the
3.2552 + only difference to a \emph{simple KE-Object} is the reference to
3.2553 + its sub-examples.
3.2554
3.2555 -\subsection{}
3.2556 + \item [sub-examples] One description can be used for one or more
3.2557 + sub-examples which contain formalization. Although there are common
3.2558 + parts in sub-examples with the same description, the sub-examples
3.2559 + contain the full formalization. The sub-example can be calculated
3.2560 + from the ME without interference with an other object.
3.2561
3.2562 -\subsection{}
3.2563 + \end{description}
3.2564
3.2565 -\subsection{}
3.2566 + In opposition to a simple example-collection, a nested example needs
3.2567 + fix links between the task description and the sub-examples. This is
3.2568 + because the informal description of these objects is split.
3.2569
3.2570 +% When an sub-example is to be calculated, it asks its task description
3.2571 +% for additional informations and ``overloads'' these information with
3.2572 +% its own set of formulas. If an information is given twice, the
3.2573 +% sub-example is to be preferred. This is to alter the task slightly
3.2574 +% within an sub-example (most likely the value of an variable).
3.2575
3.2576 + When an sub-example is displayed, it cares sole for its own
3.2577 + informations -- not for the informations displayed by the enclosing
3.2578 + description. In figure \ref{ADD:nested-presentation}, the enclosing
3.2579 + object cares of the position of the example-description, the
3.2580 + positions of the sub-example-descriptions and the numeration. The
3.2581 + fields for the sub-examples are filled with the sub-examples
3.2582 + presentation. If the designer of an example-collection wants to limit
3.2583 + the shown sub-examples he can do this by setting up the dialog to
3.2584 + suppress the unintended references (see subsection \ref{ADD:dialog}).
3.2585 +
3.2586 + \subsection{Object structure}
3.2587 + \label{ADD:object-structure}
3.2588 + We have seen in the last sections that -- although the informations
3.2589 + to present look very different at first glance -- we finally achieve
3.2590 + very similar needs.
3.2591 +
3.2592 + All objects might have a \emph{presentation} which describes the way
3.2593 + they \emph{want} to be displayed. This presentation is \emph{not}
3.2594 + obligatory -- a displaying device (browser) might choose to ignore
3.2595 + this layout. (respectively it might be incapable to follow the hints
3.2596 + given by the presentation). The layout built up by presentation
3.2597 + contains fields which are to be filled by other objects. The names of
3.2598 + this fields are also given within the list in the \emph{additional}
3.2599 + field. If a output-device ignores the presentation, at least the
3.2600 + order of this list should be preserved. Listed elements also act as
3.2601 + keys in the object to map to the final content.
3.2602 +
3.2603 + The \emph{formalization} contains a mathematical presentation of the
3.2604 + object if needed. The content of this field is given to the
3.2605 + \emph{worksheet} respective the \emph{math-engine} if there are some
3.2606 + calculations to perform on this object.
3.2607 +
3.2608 + \emph{Parent} and \emph{childs} are used to build up a
3.2609 + content-dependent hierarchy. With content-dependent is meant, that the
3.2610 + content of an object is not complete without the content of the
3.2611 + referenced object (e.g. examples).
3.2612 +
3.2613 + \emph{Meta} contains meta-information like severity or target group.
3.2614 + More details on this are given in subsection \ref{ADD:metadata},
3.2615 + \emph{metadata}
3.2616 +
3.2617 + \begin{verbatim}
3.2618 + object
3.2619 + presentation:
3.2620 + additional:
3.2621 + formal_data: isac-specification & formalization
3.2622 + parent:
3.2623 + childs:
3.2624 + meta: <metadata>
3.2625 + *<items listed in additional>:<values>
3.2626 + \end{verbatim}
3.2627 +
3.2628 + \paragraph{simple KE-Object}
3.2629 +
3.2630 +% explanation fuer alle objekte, simple explanation fuer das objekt ohne formalisierung ??
3.2631 +
3.2632 + The \emph{simple\_KE-Object} consists solely of a presentation and
3.2633 + the references of the therein used fields. Most likely, these
3.2634 + references will lead to images and formulas to display.
3.2635 + \emph{Formalization}, \emph{parent} and \emph{childs} stay empty.
3.2636 +
3.2637 + \begin{verbatim}
3.2638 + simple_KE_object
3.2639 + presentation: XML
3.2640 + additional:[KE_object (ID), ...]
3.2641 + formalization: empty
3.2642 + formal_data: isac-specification & formalization
3.2643 + parent: empty
3.2644 + childs: empty
3.2645 + meta: <metadata>
3.2646 + *<items listed in additional>:<values>
3.2647 + \end{verbatim}
3.2648 +
3.2649 + \paragraph{mathematical object} Mathematical objects are the
3.2650 + way to represent formal informations of the \emph{mathematical
3.2651 + knowledge base} within the KE-Store. They are generated through an
3.2652 + automatic import. Although there is the possibility to attach
3.2653 + informations depending their presentation, usually this fields will
3.2654 + stay empty and the task of presentation is left to the output-modules
3.2655 + which utilize standard-templates for them.
3.2656 +
3.2657 + %The \emph{parent} and \emph{child} are also automatically set and
3.2658 + %reflect the position within the hierarchy of the respective
3.2659 + %knowledge-type (\emph{axes} of the knowledge space)
3.2660 +
3.2661 + \begin{verbatim}
3.2662 + knowledge_object
3.2663 + presentation: empty
3.2664 + additional: empty
3.2665 + formal_data: isac-specification & formalization
3.2666 + parent: empty
3.2667 + childs: empty
3.2668 + meta:<metadata>
3.2669 + \end{verbatim}
3.2670 +
3.2671 + % parent: empty %mathematical-object (ID)
3.2672 + % childs: [ mathematical-object (ID), mathematical-object (ID), ...]
3.2673 + % meta:<metadata>
3.2674 +
3.2675 + \paragraph{simple example}
3.2676 +
3.2677 + The \emph{simple example} extends the capabilities of the
3.2678 + \emph{simple KE-Object} by adding an example formalization. The
3.2679 + \emph{parent} and \emph{child} fields are left empty.
3.2680 +
3.2681 + \begin{verbatim}
3.2682 + eimple_example_object
3.2683 + presentation: XML
3.2684 + additional: [KE_object (ID), ...]
3.2685 + formal_data: isac-specification & formalization
3.2686 + parent: empty
3.2687 + childs: empty
3.2688 + meta: <metadata>
3.2689 + *<items listed in additional>:<values>
3.2690 + \end{verbatim}
3.2691 +
3.2692 + \paragraph{composite example - task-description}
3.2693 +
3.2694 + \emph{composite example}\/s are the most complex objects within the
3.2695 + \emph{KE-Store-module}. They consist of a \emph{presentation}
3.2696 + which describes the general task (a train drives with a speed of 160
3.2697 + km/h from A to B \dots) as well as hierarchical informations.
3.2698 + Instead of a formalization, it contains links to its sub-examples in
3.2699 + its \emph{childs} field. This object is just a container for its
3.2700 + sub-examples.
3.2701 +
3.2702 + \begin{verbatim}
3.2703 + KE_object
3.2704 + presentation: XML
3.2705 + additional: [KE_object (ID), ...]
3.2706 + formal_data: isac-specification & formalization
3.2707 + parent: empty
3.2708 + childs: [composit-example subexample (ID), ...]
3.2709 + meta: <metadata>
3.2710 + *<items listed in additional>:<values>
3.2711 + \end{verbatim}
3.2712 +
3.2713 + \paragraph{composite example - sub-example}
3.2714 +
3.2715 + This object builds the counterpart of the \emph{task-description}.
3.2716 + Its \emph{presentation} contains only information about the
3.2717 + sub-example (most likely the ``question'':''when will the train arrive
3.2718 + at B''). The \emph{formalization} field contains the full formal
3.2719 + description.
3.2720 +
3.2721 +% waere nicht eine moegliche aufteilung der formalisierung doch besser ? dann koennte man
3.2722 +% die subexamples leicht alle auf einmal abaendern (bzw. ein neues daraus generieren)
3.2723 +
3.2724 + \begin{verbatim}
3.2725 + KE_object
3.2726 + presentation: XML
3.2727 + additional: [KE_object (ID), ...]
3.2728 + formal_data: isac-specification & formalization
3.2729 + parent: composit-example task-description (ID)
3.2730 + childs: empty
3.2731 + meta: <metadata>
3.2732 + *<items listed in additional>:<values>
3.2733 + \end{verbatim}
3.2734 +
3.2735 + Its theoretically possible to build a deeper hierarchy of
3.2736 + \emph{composite examples}. In this case, the informations about a
3.2737 + sub-example are gathered by traversing all parents till an object with
3.2738 + \emph{parent}=\emph{empty} reached.
3.2739 +
3.2740 + \subsubsection{hierarchy}% (explanation-module)}
3.2741 + All objects within the \emph{KE-Store-module} can be arranged
3.2742 + within a hierarchy to let the user navigate through them. This
3.2743 + hierarchy is stored within an own \emph{hierarchy-object} which is
3.2744 + different to the other items in the \emph{KE-Store-module}.
3.2745 +
3.2746 + Like the other objects, it does contain metadata which describe the
3.2747 + purpose of the hierarchy. All other entries serve the representation
3.2748 + of the structure.
3.2749 +
3.2750 + Every \emph{node} contains name, value and childrens. The value is a
3.2751 + reference to an \emph{KE-Object} which has to be called when the node
3.2752 + is selected. \emph{name} is a string to show when the node is
3.2753 + displayed. \emph{children} is a list of \emph{node id}\/s where a
3.2754 + node id is an identifier which uniquely identifies one node.
3.2755 +
3.2756 + The root node has a predefined \emph{node id}. Each node id may only
3.2757 + occur once within an hierarchy.
3.2758 +
3.2759 + \begin{verbatim}
3.2760 + hierarchy:
3.2761 + metadata: (name, target group, ...}
3.2762 + rootnode: {name:string, value:ke-object-id,
3.2763 + children[nodeid, nodeid, ...]}
3.2764 + <nodeid>*:{name:string, value:ke-object-id,
3.2765 + children[nodeid, nodeid, ...]}
3.2766 +
3.2767 + \end{verbatim}
3.2768 +
3.2769 + The \emph{KE-Store} can import and export a complete hierarchy
3.2770 + using one file for the hierarchy and one for each used
3.2771 + \emph{KE-Object}.
3.2772 +
3.2773 + Assembly of the nodes could also happen in an nested way like usual
3.2774 + in XML. The advantage of the presented version is that contained
3.2775 + nodes can be found at first glance -- this is useful to restrict
3.2776 + access to an ``temporary environment'' as proposed in section
3.2777 + \ref{ADD:user-admin}.
3.2778 +
3.2779 +% \kommentar{aufbau der knoten koennte auch ineinander verschachtelt
3.2780 +% sein (XML, nested maps) vorteil dieser methode ist, dass die in
3.2781 +% einer hierarchie vorhandenen knoten sofort erkannt werden koennen
3.2782 +% (notwendig fuer ``temporary environments'')}
3.2783 +
3.2784 + \subsection{Metadata} \label{ADD:metadata}
3.2785 +
3.2786 + All objects contain a field called \emph{meta} which contains
3.2787 + key-value tuples for various informations. This informations have to
3.2788 + serve different purposes:
3.2789 +
3.2790 + \begin{description}
3.2791 +
3.2792 + \item[copyright issues] This type of fields contain informations
3.2793 + which have to be considered when the object is displayed or
3.2794 + exported (for the purpose to pass on to other systems). Among
3.2795 + others, this fields can contain informations about the
3.2796 + \emph{author} and \emph{usage-permission}.
3.2797 +
3.2798 + \item[hints for the dialog] As mentioned, the dialog has to decide if
3.2799 + and when an object is to be displayed or filtered. \emph{metadata}
3.2800 + is used to assist this decisions by giving informations about
3.2801 + targeted users and difficulty of an example. This hints are not
3.2802 + the only mechanism to determine if an object is to be displayed --
3.2803 + a more detailed description of this is given in subsection
3.2804 + \ref{ADD:dialog}, \emph{dialog}
3.2805 +
3.2806 + \item[search hints] Metadata can also be used by search-engines to
3.2807 + categorize an objects content. This fields should also be passed on
3.2808 + to an searchable output-device like an HTTP-based Browser.
3.2809 +
3.2810 + \item[administrative data] like date of creation, last change, \dots
3.2811 +
3.2812 + \end{description}
3.2813 +
3.2814 + Most data fields do not belong to only one of this groups but are used
3.2815 + for different purposes. For instance although an \emph{author} is
3.2816 + mainly used to give information about the copyright, it might also be
3.2817 + the subject of an search process.
3.2818 +
3.2819 + There are a number of meta-schemas which are used to classify
3.2820 + informations on the web\footnote{See also section \ref{metadata}}.
3.2821 +% A full set of used metadata is given in the SDD.
3.2822 +%WN040815---AG->isac-ADD2-----------------END---please don't remove this line
3.2823 +%WN040815---AG->isac-ADD2-----------------END---please don't remove this line
3.2824 +
3.2825 +\footnote{End of copy from \cite{AG:thesis} p.53}
3.2826 +
3.2827 +
3.2828 +%WN040815---AG->isac-ADD3-----------------BEGIN---please don't remove this line
3.2829 + \section{KE-Objects and external Informations} \label{ADD:xml}
3.2830 +\footnote{Begin of copy from \cite{AG:thesis} p.59}
3.2831 +
3.2832 + \isac gets its math-descriptions out of the \emph{KE-Store}-module
3.2833 + which processes the stored informations and builds an
3.2834 + object-structure for the dialog to work with. The process of
3.2835 + building up the internal structure can also be based upon well
3.2836 + structured Documents like MathML and OMDoc. Vice versa, an export
3.2837 + into an XML-format is necessary to utilize the rich set of already
3.2838 + built utilities. The first process is used to import informations
3.2839 + from external information-sources like ActiveMath. The export to
3.2840 + XML can be used to render the output for representation as used for
3.2841 + the Browsers.
3.2842 +%WN040815---AG->isac-ADD3-----------------END---please don't remove this line
3.2843 +
3.2844 +
3.2845 +%WN040815----------------left from AG in the version up to now----------vvv
3.2846 +%WN040815----------------left from AG in the version up to now----------vvv
3.2847 +%...
3.2848 +% \paragraph{alternative:} courses could be used as ``usergroups''.
3.2849 +% permissions could be set for the course and ``inherited'' to the
3.2850 +% users. the problem is how to deal with users which are in multiple
3.2851 +% groups. (set the \textbf{user} to mode course and therefore block all
3.2852 +% explanations instead of changing the the permissions ?)
3.2853 +% \\
3.2854 +
3.2855 +% all objects are listed, permission depends on object and user (e.g.
3.2856 +% role or usergroup). usergroups can be handled like single users,
3.2857 +% roles define a set of permissions.
3.2858 +% \\
3.2859 +% course-obj + role(admin) = user-gismo $\Rightarrow$
3.2860 +% writepermission(course-obj)+addusers(course-obj)
3.2861 +% \\
3.2862 +% a user is member of a course if he is in the member-role of a course this \\
3.2863 +% \\
3.2864 + \paragraph{questions his thesis) to answer:} (WN: stated by AG at finishing his thesis) \\
3.2865 + Has user \emph{user1} permission to read/write an object ? \\
3.2866 + Who is member/admin of course \emph{course1} \\
3.2867 +% add a user to a course:\\
3.2868 +% permissions.course-id.members+=user-id\\
3.2869 +% read-permissions have to be set for all examples within the course\\
3.2870 +% \\
3.2871 +% dialog: display an link ? \\
3.2872 +% should link (reference) be displayed on an example ? \\
3.2873 +% could the link be suppressed although the user has read-permissions to the example?\\
3.2874 +% $\Rightarrow$ permissions for all references ?
3.2875 + \\
3.2876 + short USE-Case: fetch a course-startpage
3.2877 + \begin{itemize}
3.2878 + \item Browser wants to enter a course. he knows the
3.2879 + \begin{itemize}
3.2880 + \item name (ID) of the user
3.2881 + \item ID of the course to display
3.2882 + \end{itemize}
3.2883 + \item browser asks the dialog for the startpage of the course
3.2884 + \item dialog determines the hierarchy of the course
3.2885 + \item dialog fetches the informations from the KE-Store
3.2886 + using the users permissions (exception if the permissions do not
3.2887 + suffice)
3.2888 + \item dialog filters the hierarchy according to the user-model and
3.2889 + delivers it to the browser-dialog
3.2890 + \item browser removes links to ungranted KE-Object and creates the
3.2891 + hierarchy (tree)
3.2892 + \item browser asks for the startpage (rootnode)
3.2893 + \item dialog fetches it (exception if mot granted) and filteres it
3.2894 + according to the user-model
3.2895 + \item browser removes links to ungranted KE-Objects and builds the
3.2896 + presentation (accessing the presentation-fields - exception if not
3.2897 + granted)
3.2898 + \item $\Rightarrow$ XSLT-transformations
3.2899 +\end{itemize}
3.2900 +%WN040815----------------left from AG in the version up to now----------^^^
3.2901 +%WN040815----------------left from AG in the version up to now----------^^^
3.2902 +
3.2903 +\chapter{Bridge Java -- SML}\label{WN-add-Bridge}
3.2904 +%WN040815---RG->isac-ADD1-----------------BEGIN---please don't remove this line
3.2905 +%WN040815---RG->isac-ADD1-----------------BEGIN---please don't remove this line
3.2906 +\section{Design der Klassenhierarchie}
3.2907 +Diese Klassen MathEngine, bilden das Interface zum Frontend und zum Dialog.
3.2908 +%WN040617 hier kannst Du die Punkte 3.3.1-3. als Begründung für die jeweiligen Designentscheidungen verwenden -- das ergibt berechtigte Mehrfachnennungen, die jeweils notwendig im entsprechende Zusammenhang sind.))
3.2909 +\subsection{MathEngine}
3.2910 +Diese Klasse wird zu vom Dialog gestartet und stellt die Verbindung zur eigentlichen Bridge her. Alle Objekte am Frontend kommunizieren nur über diese Komponente mit der Bridge. MathEngine ist ein Singleton (siehe \ref{pat:singleton}).
3.2911 +%WN040815 Weitere Details sind in Abschnitt \ref{...4.Implementierung...} auf S.\pageref{xxx} zu finden.
3.2912 +%WN040815[solche Verweise wären nachfolgend auch angebracht für CalcTree, CalcIterator, BridgeMain, SMLThread und XML-Parser]
3.2913 +\subsection{CalcHead}
3.2914 +Diese Klasse repräsentiert den Kopf einer Berechnung in SML.
3.2915 +Der CalcHead enthält das Model und die Spezifikation einer Berechnung (siehe Glossar
3.2916 +%WN040815 S.\pageref{xxx} +\label{xxx} nach \chapter{Glossar}
3.2917 +). Er muss ausgefüllt und korrekt sein, bevor die eigentliche Berechnung gestartet werden.
3.2918 +\subsection{Formula}
3.2919 +Diese Klasse repräsentiert eine Formel in einem CalcTree.
3.2920 +\subsection{Tactic}
3.2921 +Diese Klasse repräsentiert eine Tactic in einem CalcTree.
3.2922 +%WN040815 ... Mit einer Tactic gibt der Benutzer an, auf welche Weise die nächste Formel in der Rechnung zu konstruieren (und von der MathEngine in den CalcTree einzufügen) ist.
3.2923 +\subsection{CalcElement}
3.2924 +Übergeordnete Klasse von CalcHead, Formula, und Tactic.
3.2925 +\subsection{CalcTree}
3.2926 +Diese Klasse repräsentiert eine Berechnung im SML-Kernel. Wenn der Benuzter am Frontend eine neue Berechnung startet, wird intern ein solches Objekt erzeugt.
3.2927 +\paragraph{ICalcIterator iterator()} liefert einen neuen Iterator zu diesem CalcTree.
3.2928 +\paragraph{public ICalcIterator getActiveFormula()} liefert einen neuen Iterator, der die aktive Formel\footnote{Damit ist diejenige Stelle im CalcTree gemeint, an der die Berechnung fortgesetzt wird.} markiert.
3.2929 +\paragraph{public void moveActiveFormula(ICalcIterator newActiveFormula)} bewegt die aktive Formel auf eine neue Position, die von dem mitgegebenen Iterator markiert wird.
3.2930 +\paragraph{public int replaceFormula(Formula newFormula)} ersetzt die aktive Formel durch eine neue, mitgegebene Formel.
3.2931 +\paragraph{public int appendFormula(Formula newFormula)} fügt diese neue Formel unter der aktiven Formel ein.
3.2932 +\paragraph{public int setNextTactic(Tactic tactic)} teilt dem Kernel mit, welche Taktik im nächsten Schritt angewandt werden soll.
3.2933 +\paragraph{public Tactic fetchProposedTactic()} liefert die vom Kernel vorgeschlagene Taktik für den nächsten Schritt zurück.
3.2934 +\paragraph{public Tactic[] fetchApplicableTactics(int scope)} liefert ein Feld mit allen Taktiken in einem bestimmten Bereich \emph{scope} zurück, die an der aktiven Formel als nächster Schritt angewandt werden können.
3.2935 +\paragraph{public int autoCalculate(int scope, int nSteps)} fordert den Kernel auf, die Berechnung bis zu einem bestimmten Punkt selbstständig weiterzurechnen.
3.2936 +Der Parameter \emph{scope} gibt den Bereich an, der beim weiterrechnen nicht verlassen werden soll, und kann folgende Ausprägungen besitzen:
3.2937 +\begin{itemize}
3.2938 + \item Aktuelles Subproblem der Berechnung
3.2939 + \item Aktuelle Subberechnung
3.2940 + \item Die ganze Rechnung
3.2941 +\end{itemize}
3.2942 +Der Parameter \emph{nSteps} gibt an, wieviele Schritte maximal weitergerechnet werden soll. Wenn \emph{nSteps} den Wert 0 besitzt, wird bis zum Ende fertiggerechnet.
3.2943 +
3.2944 +\subsection{CalcIterator}
3.2945 +Der CalcIterator dient dazu, sich im CalcTree zu bewegen und eine bestimmte Formel oder Taktik zurückzuliefern, oder um eine Stelle zu markieren, ab der weitergerechnet werden soll. Diese Klasse verwendet das Design Pattern Iterator (siehe \ref{pat:iterator}).
3.2946 +%WN040815 Der CalcIterator verdeckt die aus Gründen formaler Logik notwendige strukturelle Komplexität des CalcTree.
3.2947 +\subsubsection{Methoden}
3.2948 +\paragraph{boolean moveRoot()} setzt den Iterator auf die erste Position des CalcTree
3.2949 +\paragraph{boolean moveUp()} bewegt den Iterator zur vorhergehenden Formel
3.2950 +\paragraph{boolean moveDown()} bewegt den Iterator zur nächsten Formel
3.2951 +\paragraph{boolean moveLevelDown()} bewegt den Iterator eine Verschachtelungsebene tiefer. Nur relevant bei Berechnungen mit Subrechnungen.
3.2952 +\paragraph{boolean moveLevelUp()} bewegt den Iterator eine Verschachtelungsebene nach außen.
3.2953 +\paragraph{boolean moveTactic()} bewegt den Iterator zur Taktik, die zu der aktuellen Formel führte.
3.2954 +\paragraph{boolean moveFormula()} bewegt den Iterator nach Aufruf von \emph{moveTactic} wieder zur Formel zurück.
3.2955 +%WN040815[bitte Folgendes bitte sicher in Deinen Text einfügen:]
3.2956 +%WN040815\footnote{Eine Variante dieser Design-Entscheidung, die die Struktur des CalcTrees genauer abbildet: {\em nur} für eine {\em Formel} (d.h. eine Formel oder ein CalcHead) besitzt der CalcIterator einen eindeutigen Wert; daher werden moveTactic und moveFormula gestrichen, dafür aber getElement durch getTactic ergänzt: getTactic liefert die Taktik, die jene Formel erzeugt hat, auf die CalcIterator zeigt.}
3.2957 +\paragraph{int getLevel()} liefert den Level ($=$Anzahl der Subrechnungsebenen) der aktuellen Formel.
3.2958 +\paragraph{ICalcElement getElement()} liefert das aktuell markierte Element der Berechnung (Formel, Taktik, CalcHead) zurück.
3.2959 +\paragraph{Object clone()} klont den Iterator und liefert ein zweites Iterator-Objekt zurück, das auf die selbe Position im CalcTree zeigt.
3.2960 +\paragraph{int compareTo(Object o)} vergleicht diesen Iterator mit einem zweiten. Die Iteratoren werden als gleichwertig betrachtet, wenn beide auf die selbe Position im CalcTree
3.2961 +
3.2962 +\subsection{BridgeMain}
3.2963 +Die zentrale Komponente des Bridge-Systems. Sie startet die anderen Prozesse, die zur Kommunikation mit SML dienen, leitet die Anfragen an den Kernel weiter.
3.2964 +\subsection{SMLThread}
3.2965 +Hier wird der SML-Prozess gestartet und die Ein- und Ausgabe der Daten gemanagt.
3.2966 +\subsection{XMLParser}
3.2967 +Hier wird der XML-Output des Kernels geparst und in Java-Objekte umgewandelt, die dann wieder an das Frontend weitergereicht werden.
3.2968 +
3.2969 +%\begin{figure}[htbp]
3.2970 +% \centering
3.2971 +% \includegraphics[width=1.00\textwidth]{fig/RG-design.eps}
3.2972 +% \caption{Design der Bridge-Komponenten}
3.2973 +% \label{fig:design}
3.2974 +%\end{figure}
3.2975 +%WN040815---RG->isac-ADD1-----------------END---please don't remove this line
3.2976 +\newpage %to keep page numbering after some editing
3.2977 +.
3.2978 \ No newline at end of file