Command Execution

The purpose of the CommandExecutionsubsystem is to export two operations. The rst one is

used for computing a list of strings that represent command names for a given selection. The second operation is used for executing a command. These two operations are imported by the

EditorManagerclass in order to implement operations that are used by call-back operations in

the Control class. The Control class, in turn, reacts to events detected by the user interface

subsystem, such as pushing the right mouse-button or selecting an item from a pop-up menu. Three properties characterise a command. It has a name, a precondition and a list of operations that are executed when the user has selected the command. This list may include operations implementing user dialogues as well as operations on the project-wide abstract syntax graph, which are implemented in the tool's schema. The list of operations has ACID properties as required in Section 2.3.2. A menu, in turn, consists of a collection of commands that satisfy the precondition for the current selection.

Each command is implemented in a separate class. We call these classes interactions. Upon construction of objects of such a class, an object of class Selection representing the current

increment is passed as an argument and stored in an instance variable. The class has three methods, which implement the properties of commands: GetName returns the name of the

command as a string, IsAvailable returns a boolean value that determines whether or not

the command is available for the current selection and nally,Executeexecutes the command.

It returns true, if the command was successfully completed and false, if it was aborted. This return value is evaluated by the EditorManagerin order to call a database transaction commit

or abort operation.

Menus are implemented as collections of interactions in class InteractionCollection. The

class, therefore, stores a list of interactions in an instance variable. It exports an operation to obtain a list of strings that represents the names of commands to be presented in a menu. It also exports an operation to execute a particular operation. It is implemented by invoking the Execute operation of the respective interaction. The constructor of this class obtains

an object of class Selection, which identies the current increment. It then constructs the

context sensitive menu by creating instances of interaction classes, testing for their availability and including them in the collection if IsAvailable returns true. It is a problem to decide

which commands to consider when an interaction collection is built. If any command the tool supports is considered, menu computation is certain to be too inecient.

Commands in structure-oriented editors are always applied to the current increment, or its parents in the abstract syntax. This observation can be exploited for an ecient computation of menus. Therefore, interactions are grouped by increment types. Furthermore, an interaction collection class is dened for each increment type. During construction of an interaction col- lection, the collection only considers interactions dened for one increment type. To compute the available interactions, we only have to consider the interaction collection that is dened for the type of the current increment, and the collection that is dened for the parent type of the current increment. These collections have to be merged.

Now we again have the problem that increment collection classes are language- and thus tool-specic, though their use in the ToolKernel subsystem requires a uniform interface.

We solve the problem by following the same strategy as that used during layout computa- tion. We create a new class MenuConstructionand declare this class to be an export of the

CommandExecutionsubsystem. The only parameter of the constructor of this class is an object

of class Selection representing the current increment. Upon construction it decides which

interaction collections to construct based on the actual type of the current increment. It then exports an operation which returns the computed increment interaction collection. The incre- ment type specic interaction collection classes are, in turn, implemented as subclasses of class

InteractionCollection. Exploiting polymorphism, MenuConstruction may thus return a lan-

guage specic interaction collection to the EditorManagerclass. As this inherits its signature

from the predened classInteractionCollection, theToolKernelsubsystem remains language

independent and thus can still be reused in dierent tools.

Inheritance can also be exploited to share commands between dierent, but similar, increment types. As an illustrating example, consider procedures and functions as used in the interface denition language of Figure 2.4 on Page 14. Commands for creating and changing names, parameter lists and comments had to be included in both menus. Therefore, a lot of interac- tions had to be dened redundantly for both functions and procedures. This can be avoided completely if an interaction collection for an abstract increment type Operation is dened.

Interactions implementing commands that are applicable to functions and procedures are as- sociated with increment typeOperation. During the construction of this interaction collection

for Operation, the interactions for type Operation have to be considered. The collections

for functions and procedures then have to inherit from the Operation interaction collection.

During the construction of these child interaction collections, we need only ensure that the constructor of the parent interaction collection is executed.

IncIntAct_11 ... IncIntAct_1m IncIntAct_21 ... IncIntAct_2o ... IncIntAct_n1 ... IncIntAct_np

... Interaction Collection Interaction Collection_1 Interaction Collection_2 Interaction Collection_n Interaction Collection_m ... Menu Construction IncIntAct_m1 IncIntAct_mj

Figure 5.4: Design of Command Execution Subsystem

This inheritance mechanism can also be exploited for reusing command denitions that are common to arbitrary tools. Every tool, for instance should have commands for version and conguration management of documents. An abstract increment class DocumentVersionthat

has the property of being the unit of version management can, therefore, be introduced. All predened interactions implementing commands for version management can then be attached to this increment class and the interaction collection for class DocumentVersionarranges for

inclusion of these interactions in a menu. If a tool is to support version management, the interaction collection for the root increment type of this tool can then be declared to inherit from the collection for the predened abstract class DocumentVersion. Similarly, interactions

implementing commands for building congurations are attached to an abstract increment classUsingIncrementfrom which language-specic increment classes, representing imports from

other documents, inherit.

For a summary of the discussion consider the architecture of the CommandExecution sub-

system displayed in Figure 5.4. The subsystem exports classes InteractionCollection and MenuConstruction. Their export interface remains stable in dierent tools. During instantia-

tion of an object of classMenuConstructionfor a current increment, two interaction collections

are constructed and merged afterwards. During construction of an interaction collection, all interactions that are dened for an increment type or its super types are constructed and in- cluded in the collection, only if they are available. This is determined by operationIsAvailable

that is dened in each interaction class. After that an interaction collection can be obtained by the EditorManagerclass from the MenuConstructionclass. The collection will contain only

those interactions that are applicable in the current selection context. Interactions can be inherited by dening inheritance relationships between the respective interaction collection classes. This allows for the sharing of commands between dierent increment types as well as for the reuse of predened commands between dierent tools.