Editor Manager

Selection Editor Manager Opened Document

Figure 5.2: Architecture of the Tool Kernel Subsystem

The architecture of the ToolKernel subsystem is depicted in Figure 5.2. The export of this

subsystem is the classEditorManager. During start-up, each tool creates an object of this class

and stores it in an instance variable of the Control class. To invoke operations exported by

theToolKernel, theControl class then invokes a method from this object. The method itself

uses other methods fromEditor,OpenedDocumentandSelection. We now discuss each of these

classes in more detail.

Editor Manager

A user of a tool can open multiple editors in order to view or edit multiple documents at the same time. The purpose of classEditorManageris thus to implement the set of editors that are

currently in use. Its main data structure is, therefore, a set where it inserts or deletes objects of class Editorwhenever documents are opened or closed respectively.

Class EditorManagerexports a set of operations which are used by the Controlclass to react

to user input as well as to service requests. For most of the tasks listed below, an operation is exported, which obtains its parameters, such as document names, version names or le names, from dialogues with the user. Therefore,EditorManagerimports from the user interface

subsystem. Furthermore, most of these tasks represent generic services that should be oered by tools. During the execution of these services, there is no user who could be asked for parameters. Therefore, for each of the tasks, a second operation is exported, which obtains its parameters from arguments passed during operation invocation. ClassEditorManagersupports

the following tasks:

creating a new document and opening it in a new window in edit mode, importing a document from a textual representation stored in the le-system, opening an existing document version in edit or view mode,

exporting a document version to the le-system, deleting a document,

selecting an increment of a document version to become the current increment, computing a menu of commands applicable to the current increment,

executing a command selected from the menu,

aborting the current command execution to recover from a deadlock, freezing a version of a document,

deriving a version of a document,

merging two versions of a document and deleting a version of a document.

Among the tasks listed above, there are some, such as creating a new document or executing a command chosen from a menu, that modify the underlying abstract syntax-graph and must, therefore, be performed as ACID transactions. Class EditorManagerthus imports operations

from the ODBSto start and end a transaction. A transaction is started before the rst object

is modied and nished as soon as the last object has been modied. Besides ACID transac- tions, some ODBSs also support the concept of read-only transactions that are sequences of operations that do not modify any objects. In

O

transactions. These read-only transactions do not acquire any read locks on objects they ac- cess. We exploit this concept to improve the performance of tools and transaction throughput. Task that do not modify the underlying abstract syntax graph, such as selecting an increment or computing a menu, are thus executed as read-only transactions. Performance is improved, since time consuming locking is not performed during the execution of these tasks. Transaction throughput is increased, since locks are held for shorter periods of time and the probability of blocking concurrent transactions is decreased.

The method ExecuteCommand, which executes a command, imports classes and operations

exported by the CommandExecution subsystem. After a command execution is completed, ExecuteCommand commits the current transaction and tool execution resumes as a read-only

transaction. It must then redisplay any changes the command has caused in the project-wide abstract syntax graph. To improve the performance, changes must be redisplayed in an incre- mental manner. ExecuteCommand, therefore, implements the following strategy. If the command

whether or not any object was modied during a command execution is returned by the oper- ation from theCommandExecutionsubsystem. If objects were modied, the current increment is

redisplayed, for it is most likely that this has been modied. Moreover, each increment that is additionally changed is registered in a set calledModifiedIncrementsassociated with each doc-

ument. ExecuteCommandthen iterates over all documents that are currently displayed and then

iterates over theirModifiedIncrementssets and redisplays each of the increments in these sets.

To redisplay an increment, ExecuteCommandimports a method called UnparseToUserInterface

that is exported by classOpenedDocument. Finally, each set is emptied.

Editor

The main purpose of class Editoris to implement the editors where documents are displayed.

Class Editor, therefore, maintains references to a document, which is an instance of class OpenedDocument, an edit window (i.e. an instance of classEditWindowthat is imported from the UserInterfacesubsystem), an instance of classSelectionto keep track of the currently selected

increment and an instance of classEditorErrors, which displays errors of the current increment

in more detail2. Instances of class

Editorare created in class EditorManagerwhenever a new

document is opened. They are deleted whenever a document is closed.

The operations exported byEditorare used by methods from classEditorManager. A common

feature is that they access or modify the state of an editor. The operations in particular are:

selection of an increment,

obtaining the current increment, if any, opening and closing error windows, and

raising an editor that may be hidden behind other windows.

The Editorclass imports methods to create and delete edit windows and error windows from

the user interface subsystem. It also imports methods to create and delete edit documents and selection objects.