Interactions

From the list of requirements identied in Section 6.1, we have not yet addressed the specica- tion of tool commands. A tool builder will have to dene the command names that appear in context-sensitive menus that the user can pop up. This includes the denition of preconditions that must be fullled for the appearance of the command in the menu. Moreover, the partic- ular dialogues between tool and user, if any, must be dened. The tool builder might want to dene dierent dialogue styles in dierent tools. In particular, the process model might require a particular way of handling static semantic errors or inter-document consistency con- straint violations. The command denition language must be exible enough to support these dierent concerns. Moreover, a number of command denitions are very similar among mul- tiple increment classes. A tool builder will appreciate it if commands can be dened once and can then be reused in dierent classes. To meet these requirements, we add a concept of interactions to the class specication language that supports the denition of commands as required.

The denition of an interaction encompasses an internal and an external name, a selection context, a precondition and an action. The external name appears in context sensitive menus. The internal name is used to determine the redenition of an inherited interaction. The selection context denes which increment must be selected so that the interaction is considered for inclusion in a menu. It is actually included if the precondition that follows the ON clause

evaluates toTRUE. The action is a list of GTSL statements that is executed as soon as the user

We dene two further predened classes that can only be used in interaction bodies. These classes are TEXT and TEXT SET. They oer primitives for user dialogue specications. TEXT

oers user interaction primitives to cope with strings. It has methods for displaying a string in a message window, editing a single text-line or editing a text that consists of arbitrary lines. TEXT SET oers primitives to handle input and output of sets of strings. Among these

are methods for selection windows in which users can select single or multiple entries. As an example, consider in Figure 6.14 the interaction that changes a module's name.

INCREMENT SPECIFICATION Module; ...

INTERACTIONS

INTERACTION ChangeName NAME "Change Module Name" SELECTED IS name ON (name.expanded) VAR t:TEXT; err:TEXT_SET; BEGIN t:=NEW TEXT(name.unparse);

IF (t.LINE_EDIT("Enter New Module Name!")) THEN IF (NOT name.change_name(t.CONTENTS())) THEN

err:=NEW TEXT_SET(name.get_errors()); err.DISPLAY(); ABORT ENDIF ENDIF END ChangeName;

Figure 6.14: Command Denition to change a Module Name

This interaction is considered to be oered if the current increment is the module's name. It is actually oered if the name identier has already been expanded. If this is the case and the user has requested a menu, the string Change Module Name will become a menu item. If the

user chooses this item, the action is executed and the user will be prompted to edit the name of the module in a line edit window. The default character string in this line edit window is the old module name that is computed by sending message unparse to abstract syntax child name. If the dialogue is completed, the LINE EDIT method returns TRUE and the increment

modication operationchange name (c.f. Page 150) is executed. The operation returnsTRUEif

the identier is lexically correct, otherwise it returnsFALSEand an error message is displayed.

Afterwards the command is aborted, i.e. the state of the document is restored to its state before the command execution started.

Subclasses inherit interactions from their super classes. The interaction ChangeName dened

above is, in fact, inherited by the four dierent subclasses of Module. Interactions might be

redened. As an example of this, consider type collection modules in the Groupie interface specication. They dene very low-level modules, which are often imported from a very great number of other modules. For these modules, the above interaction might not be appropriate. Suppose that the command for type collection modules should warn the user if the change impacts more than a xed amount of other modules, say 10. In that case, it would also be inappropriate to tolerate static semantic errors as was the case in the other interaction. Due to the exibility of the class specication language we can then redene the interaction in class

TCModule to take these considerations into account. The redened interaction is depicted in

INCREMENT SPECIFICATION TCModule; ...

INTERACTIONS

INTERACTION ChangeName NAME "Change Module Name" SELECTED IS name ON (name.expanded) VAR t,warning:TEXT; err:TEXT_SET; cont:BOOLEAN; BEGIN IF name.ExpTo.SIZE>10 THEN

warning:=NEW TEXT("Module is imported by more than ten other modules!"); cont:=warning.ASK_TO_CONTINUE("Do you want to continue?");

ENDIF; IF cont THEN

t:=NEW TEXT(name.unparse);

IF (t.LINE_EDIT("Enter New Module Name!")) THEN name.change_name(t.CONTENTS());

IF NOT name.Errors.IS_EMPTY()) THEN err:=NEW TEXT_SET(name.get_errors()); err.DISPLAY(); ABORT ENDIF ENDIF ENDIF END ChangeName;

Figure 6.15: Redened Command Denition to change a Module Name

The redened interaction accesses the semantic relationship ImpFrom/ExpTo between module

names and their counterpart in import lists. If the number of entries in the implicit link is bigger than the upper bound, a warning will be displayed on the user's screen. If the user ignores the warning, the change operation is performed. Note that this time we access the

Errors attribute of the name regardless of the result returned by change name. At this state, Errors will be dirty for the following reason: method change name modies the lexical value

attribute that, in turn, outdates the set of dened modules. Since the error set of the module name will depend on that attribute it will become dirty as well. The access of the error set attribute that checks whether the set is empty will, therefore, cause semantic rules to re re- evaluating the static semantic constraints and bringingErrorsback into clean state. If the set

includes any error descriptor, they will be formatted and then the command will be aborted and thus all performed changes will be undone.

Due to multiple inheritance and redenition, ambiguous situations may occur. These are sim- pler than for methods because interactions do not have parameters or types and are, therefore, not considered here any further. The formal denition in the appendix includes constraints that exclude name clashes and incorrect repeated inheritance of interactions.

Interactions have transaction properties. They are atomic i.e. they are either performed completely or not at all. They are the unit of concurrency control, i.e. an interaction may be delayed or even aborted in case of concurrency control conicts with other concurrent interactions. Hence interactions are performed in isolation. Once completed, the eect of an interaction is durable, i.e. all changes that were made during the interaction persist even if the tool is stopped accidentally by a hardware or software failure.

6.5.6 Summary

We have dened an object-oriented language for the behavioural denition of increment classes. Compared to object-oriented programming languages (such as our implementation languages C++ and

O

2

C

), our language considerably raises the level of abstraction at which tool builders

specify tools. We have dened unparsing schemes as a declarative concept for dening the ex- ternal representation of documents. We have included primitives for dening the abstract and lexical syntax of increments. Beyond this higher-level of abstraction, the language provides the exibility for a tool builder to use a lower-level of abstraction, if required. Implicit meth- ods of increment classes provide an interface to these denitions so that they can be used in methods at a lower-level of abstraction. We have dened semantic rules as a declarative formal- ism to specify static semantics and inter-document consistency. Compared to programming languages, this particularly relieves the tool builder from worrying about execution orders. Finally, we have added a concept for dening tool commands including their appearance in context-sensitive menus and primitives for user dialogue specication.

The language supports the structuring of specications particularly well. Components are increment classes that are identied in the ENBNF and entity relationship model. Their inheritance and import/export relationships are explicit. Reuse of denitions is supported because all denitions are inherited by subclasses and can be redened there if required. The language distinguishes dierent kinds of classes and dierent kinds of properties in order to enable domain specic static semantic constraints to be dened. A signicant number of potential specication errors are excluded by these constraints. In an object-oriented pro- gramming language, even if it is as strongly typed as

O

2

C

, these specication errors cannot

be highlighted due to the lack of domain knowledge.

6.6 Related Work

This section reviews the most powerful existing tool generators with respect to the tool speci- cation languages they use and compares the approaches with GTSL. Subsection 6.6.1 presents ordered attribute grammars as they are used by the Cornell Synthesizer Generator [RT84]. Section 6.6.2 discusses the Centaur System [BCD+88] with respect to its specication lan-

guages. The language PROGRESS [Sch91a] developed in the IPSEN project is dedicated to the specication of general graph structures. As such it has been applied to the specication of abstract syntax graphs as well. PROGRESS is then discussed in Subsection 6.6.3.

In document Tool specification with GTSL (Page 163-166)