DRIVE: An Environment for the Organised Construction of User-Interfaces to

This paper describes a runtime user-interface development environment (UIDE) for the novel capability of interactively using and specifying user-interfaces to object-oriented databases (IDSs). A framework provides the foundation for IDSs constructed. This concerns interpreting an IDS, specified in a conceptual object-oriented data language, using a persistent meta model. A generic environment model facilitates dynamic integration of existing user-interface widgets into the meta model. This achieves the goal of providing a database representation independent visual environment (DRIVE). The architecture and use of DRIVE are described and the benefits of this approach are discussed.


Introduction
As the issue of providing user-interfaces to databases (IDSs) becomes the focus of increasing numbers of research groups, there is a call for tools that act as sketch pads for new interaction and presentation ideas. Unless such tools follow a well-defined organised approach, results will be harder to reproduce in commercial systems and remain limited to the original tool of conception.
Creating such tools raises critical problems in terms of their flexibility and performance. Supporting diverse interactive components and coordinating them uniformly with respect to database components [14] presents a challenge to all IDS developers. In addition, the interactive specification of IDS elements through direct manipulation [17] with immediate feedback on modifications [7] requires a particular solution when the data resides in a database. Typically this problem is exacerbated by an impedance mismatch between the user-interface programming language and the database's data model.
In regard of these issues, a database representation independent visual environment (DRIVE) is presented which serves as a tool for using and specifying existing and prototype IDSs in a runtime user-interface development environment (UIDE).
To ensure well-defined organised IDS construction, DRIVE enforces the relationships and dependencies identified in our framework for user-interfaces to databases [11] using a conceptual object-oriented data language. The architecture presented provides a means for coordinating disparate interface components using a persistent meta model of the IDS framework together with an environment model. This scheme has the following distinct advantages: • interactive support for IDS schema and object definition and manipulation without requiring the support of schema evolution in the object oriented database system used.
• explicit consideration for users of IDSs as modelled within the IDS framework, allowing user-specific configurations incorporating security measures.
• dynamic integration of existing and novel user-interface objects, such as widgets and controls, in an environment model.
The following section briefly describes our IDS framework with particular emphasis on the mapping to the conceptual language. Section 3 shows an IDS prototyped in the DRIVE UIDE, which is used as an exemplar for the following technical content. Section 4 presents DRIVE's architecture based on runtime interpretation of a persistent meta model of the IDS framework. Section 5 details the environment model, which dynamically binds visualisation classes of the framework meta model to external user-interface objects. Section 6 describes the process of IDS construction, for interactive manipulation of conceptual language specifications. Finally, conclusions and some further work are discussed.

Background
The framework that provides the foundation for IDS construction in DRIVE is based on Abowd and Beale's [1] interaction framework, which identifies four major components of an interactive system, ie. system, input, output and user. In applying this framework specifically to IDSs, modifications and extensions to these components have been made. We have identified an IDS to be the composition of database, interaction, visualisation and user components. In addition, the common features of each of these IDS components have been identified, eg. a visualisation component has a referent, metaphor and layout.
In our IDS framework [11], we have shown how such a detailed classification of components may be mapped to a conceptual language that embodies the relationships and dependencies among the components of an IDS.
For this purpose, we have chosen the modelling language NOODL for IDS specification. NOODL (Napier's object-oriented data language) is based on the modelling approach described in [2]; it has been used to model and to support the implementation of novel database applications, and also for the investigation of specific modelling issues such as declarative integrity constraints and activeness and the incorporation of views in object oriented data models. It also includes a query language [4].
A NOODL schema contains a list of class definitions, which show the name and ancestors of each class. A class definition also includes the names, sorts, and, optionally, definitions of the properties of each class. It may also contain operations, constraints, and triggers. Full details of NOODL may be found in [3]. Figure 1 depicts the classes and properties of a meta-model of the IDS framework using NOODL constructs. In mapping the framework to NOODL, certain components are depicted as NOODL classes, some as properties, while other are modelled using operations, constraints or triggers. An example schema based on the above template is given in the appendix.
In common with Rumbaugh's user interface modelling approach [15] multiple interface objects are associated with each data object. This permits database updates to be broadcast to each relevant interface object. Thus realising the facility for multiplecoordinated views. Much work in the field of HCI reflects this conceptual organisation. Conceptual architectures for user interface management systems (UIMS) typically involve the identification of the system (data) in separation from input and output (interface) components. This is evident in the archetypal Seeheim workshop model with application interface, dialogue control and presentation components; Smalltalk's model, view, and controller (MVC) paradigm; and the presentation, abstraction and control model (PAC) [14].
This meta model provides a number of features, including, • multiple interface objects associated with each data object • interface object composition for specification of layouts If an architecture exists which supports the NOODL data model, then concise specifications, using the IDS framework meta model, may be interpreted to automatically realise functional IDSs.  Figure 2 shows a display from the prototype IDS specified using the DRIVE UIDE (see appendix for the NOODL specification). The display shows various views of the museum, which may be altered interactively with the mouse and keyboard in designer mode. If an object is moved or altered in one view, then the change will be updated in the other views. The dialog box in the lower right of the display shows the details of the currently selected artefact. This shows the effect of the browse operation of the Artefact Interface class and serves as an example of the novel applications possible with integration of 3D graphics technology with traditional 2D graphics.

Architecture
Fundamental to the provision of such tools is their architecture. Figure 3 shows three architectures where database (DB) and user-interface (UI) components are linked in alternative ways. Gray and Cooper [9] have identified a need for architectures of integration, where relationships amongst IDS components are managed using some integrating model. This is necessary both to maintain multiple coordinated views of data [15] and provide the composition of interactive components from disparate origins.  Data, user, interface and visualisation classes combine to make up the IDS component. The environment model contains a scheme for handling interaction events and mapping them to the appropriate IDS objects, via instances of visualisation classes. A visualisation class may be derived in conjunction with existing userinterface widgets, such as OWL [13] controls, and advanced interface widgets, such as the 3D widget set's (TDW) [6] access widget.
The NOODL classes of an IDS are built upon a persistent data model layer. This layer, (similar to ObjectStore's Meta Object Protocol [12]) implemented with the POET [5] persistent C++ extension, provides a means of dynamically creating persistent IDS schemata together with their data. This data model is implemented as a vanilla C++ meta model and may be made to persist with object oriented database systems (OODB) supporting single inheritance, complex objects and polymorphic behaviour. Figure 4 shows the classes of the IDS specified in the appendix together with corresponding environment and user-interface widget classes managed by the environment model. Each IDS class is grouped according to the respective framework component modelled. The headings in italics identify the language used to define each particular class, with NOODL classes, C/C++ environment classes and (in this case)  • provides dynamic registration of environment classes for user-interface widgets.

Environment Model
• maps input and output events between corresponding user-interface and visualisation classes • channels events according to the mode of operation (designer or execution mode) Dynamic registration of environment classes is achieved by placing the environment manager in a dynamic link library (DLL), which is initially linked to DRIVE. Whenever a new type of widget is required, the code module (normally also a DLL) containing the widget code links with the environment manager and calls the appropriate C functions to register the environment class. These calls must define a template for the corresponding visualisation class as well as register the properties and callbacks of the environment class.
Consider when a user clicks the left mouse button on an artefact in the virtual museum example (appendix). Normally, this event is handled by the widget and the LButtonClick callback function is called within the encapsulated widget to respond to this event. However, in order to map this user-interface event to a NOODL select event, it must be forwarded to the environment manager with a message identifier using the NotifyInputCallback. This function matches the LButtonClick event with the select input callback of the registered env_Shape environment class and calls it.
In the virtual museum specification, the browse trigger of the artefact's interface object is fired when the select event occurs. This trigger assigns its referent to the referent of the associated Artefact Detail interface object, which then triggers a change in the Form visualisation object's text fields. Such a change will result in an output event, which then must be forwarded to the environment manager using the NotifyOutputCallback. The output callback accesses the text fields of the Form visualisation object and updates the TEdit user-interface widgets according to the newly selected artefact.
Clearly, if many interface objects share the same referent, a change in the linked data object will trigger updates in all associated visualisation objects. In this way, the mechanism for multiple coordinated user-interface widgets may be realised.
With all events channelled through the environment manager, a simple switch is sufficient to realise a change in mode of operation. If designer mode is set then all events will be forwarded to the appropriate environment class' edit callbacks. If execution mode is set, then they will be sent to normal callbacks. Although, this technique has been employed in MOG objects [8], the editing behaviour is internal to the encapsulated MOG object. Here, output callbacks allow editing behaviour and application functionality to be defined in the NOODL IDS.

Environment classes
It is possible to categorise the features of environment classes according to the input/output direction of events. Each input callback may contain code to modify a visualisation class' active property from its VISdata set or trigger a visualisation class' event operation. These may read information about the widget's state using its GUIdata set. For example, in figure 5, the commit input callback would read TEdit's text string pass it to the TextField visualisation class' text. Conversely, each output callback may modify a user-interface widget class' property via the GUIdata set and read information from the VISdata set.
Two other callbacks are required for creating and deleting environment objects at runtime. The create callback is called after a visualisation object is created or retrieved from the database. It must initialise the user-interface widget's state using the environment manager's CreateEnvObj and assign the GUIdata set using the VISdata set to read information from the derived visualisation object. The destroy callback is be called after visualisation object is deleted or unloaded from memory. It must remove the user-interface widget from memory and then call the environment object's destructor using the DeleteEnvObj function.

Integrating advanced user-interface widgets
The environment model is general enough to make use of the majority of existing user-interface widget sets. The term environment is purposely chosen to indicate that an IDS can interact with potentially much more than standard widgets. Through environment objects an IDS may communicate data to and from novel environments (eg. dynamic data streams, special I/O peripherals, other databases, etc.). This flexibility has been exploited in the task of designing three dimensional database environments using the 3D Widget set (TDW) [6]. Figure 5 shows the use of TDWs to construct a 3D environment representing the artefact of a museum. Each artefact uses a tdw_Shape to represent itself. These shapes are registered in a 3D scene (tdw_Scene) and rendered in a window (T3DWindow). This derived OWL window handles keyboard and mouse events (such as navigation and selection), which are passed to the shape that currently has the user's focus. In this way the user can directly manipulate the shapes in the 3D environment and change the state of the database through the environment model.

NOODL Data Model Interpreter
In order to manage the components of an IDS defined in the NOODL data model under the IDS framework, each class must identify the component to which it belongs, eg. a Visitor class must belong to the user component of the IDS framework. In this way the properties, operations and triggers of the framework meta model are constrained by the interpreter to appear only in their appropriate classes. The mechanism for enforcing this rule marks every property, operation and trigger with its identity in terms of the framework. These are detailed below.

Framework Class Templates
All classes may act as the referent of one or more interface classes and so may have one or more interface (obverted) properties, eg. from the Artefact data class, In addition to these framework features, each class may use standard NOODL constructs to model an IDS. However, with these features certain classes will depend on the existence of other classes, ie. authority and sophistication classes may not exist without user classes, and interface classes may not exist without a referent, metaphor and user. Indeed, the default IDS schema must contain at least one user class, in order to permit access to the IDS.
This provides a general scheme the organised construction of advanced IDSs. The next section covers their interactive specification.

IDS Construction
Given an architecture supporting the runtime interpretation of NOODL IDS specifications the facility exists within DRIVE to compile textual NOODL script files into the IDS framework meta model and generate working IDSs. In addition, with a runtime NOODL interpreter it is possible to entirely construct IDSs within DRIVE. Once a designer is satisfied, concise NOODL script specifications may be written out and documented.

IDS Editor
Interactive specification of IDSs is carried out through the IDS editor. This combines a hierarchical list view of the IDS schema with a node specific dialog. When the user selects an element in the schema list, the view on the right changes to display the controls required to edit that element. Hierarchical list views are becoming common place in windows applications. Sub-lists may be expanded or collapsed by double clicking the mouse button on the composite list node. This has been achieved with respect to an OODB by means of a persistent object resource key tree (PorkTree). Figure 6 shows the virtual museum specification with the PorkTree expanded to show the default properties of an interface class. Classes are strictly grouped according to their categorisation in the IDS framework.
Each node in the PorkTree contains an object of the IDS framework meta model and a dialog object. With this information a node acts as a unique key to the desired object. When a node is selected in the list view, the dialog object is passed the persistent meta model object for editing. The PorkTree contains nodes for editing the entire schema, from lists of class ancestors to individual properties. In addition to the schema information, IDS objects and their values also form part of the PorkTree.
This method works well for a few levels of sub-division, but if the tree becomes overcomplicated access to deep sub-nodes is sluggish and impractical. For this reason, the definitions of derived properties, operations, constraints and triggers are specified in an additional definition editor.

Context Sensitive Definition Editor
Given that DRIVE's design environment has access to the IDS component, and therefore all the constructs of the NOODL data model, it is possible at any point within the definition of an NOODL expression to determine the set of valid operators and operands. This is exploited in the definition editor where the context of the expression is represented by the elements in the operator and operand lists. With these lists the user can define complete operation definitions and constraint expressions, simply by selecting the available element and pressing the add button. Figure 7 represents the definition editor after the browse operation of the Artefact Interface class (see appendix) has been partially specified. The operand box is filled with the active properties and event operations of the artefact interface's associated Shape metaphor. The operator box contains complete, settor and delete elements to signify the completion of the current expression and the metaphor's settor and delete operators, respectively.
As with the PorkTree dialogs, the context sensitivity of the editors gives the designer support for constructing IDSs within the framework without deviating from the semantics of the data model. This is particularly useful for designers unfamiliar with NOODL where no knowledge of syntax is necessary. Consideration for advanced designers has been acknowledge by the provision of keyboard and mouse shortcuts. Typically, this method requires significantly less keyboard and mouse interactions than using a traditional text editor. Further, because the number of valid operators and operands is frequently less than 20, the performance of this editor does not hinder the specification process.

Direct Manipulation of User Interface Widgets for Editing
With each environment class registered, a corresponding visualisation class is added to the NOODL IDS specification and the design environment manages an associated palette of widgets that may be added to the IDS. This is activated when a developer enters designer mode. Each widget may be dragged and dropped into an appropriate user-interface window. This includes the creation of new windows and dialog boxes (by dragging onto a non-composite area). Figure 8

Conclusions
In this paper we have shown a database representation independent visual environment (DRIVE), which serves as a tool for using and specifying existing and prototype IDSs in a UIDE. A general philosophy of widespread mutability of IDS elements has been achieved in a dynamic interactive environment. An IDS component has been detailed, which ensures well-defined organised construction within our framework for user-interfaces to databases. User security is safe-guarded by defining the set of accessible interface objects within the IDS framework.
Tight coupling in DRIVE's design environment with NOODL data model constructs enable context sensitive editors to provide highly specialised support for novice designers ensuring the validity of designs under the IDS framework. The encapsulated editing behaviour of environment objects achieves direct manipulation of userinterface widgets.
The environment model permits dynamic integration of existing and novel userinterface objects, through independent environment objects. Such objects are linked to the application at run-time using an environment manager. If an existing widget is required which is unable to link with the environment manager, then it should be possible to provide a messaging interface, which uses the operating system's message protocol (eg. Windows messages) or a shared file messaging protocol. Indeed, dynamic reconfiguration or replacement of the IDS framework component is possible using the same technique in the reverse direction.
Currently, DRIVE supports NOODL IDS specifications integrating a range of simple 2D and 3D widgets. We intend investigating techniques for composing and mapping between such widgets, which may be reproduced in commercial applications. Empirical evaluations of such applications will doubtless follow.

Appendix -Example IDS Specification
This schema specifies the prototype IDS shown under the DRIVE UIDE in figure 8. The specification concerns a museum's database which is interacted with through a desktop virtual reality user interface. The data of the database is specified by the Artefact class, which holds its name, description and catalog_id. This information is displayed through the linked interface classes, Artefact Interface and Artefact Detail Interface.
Users of this system are modelled by the class Visitor. Sophistication and authority properties have been omitted, because no particular sophistication or authority is appropriate to this example. The user interacts with a number of Window Interface instances, through which s/he may browse the artefacts of the museum.
Each window uses a 3D window metaphor, which provides a virtual environment for the to navigate. The referent of a particular user's window, is a Museum Interface object, which uses a Shape metaphor.
The museum interface is composed of a collection of Artefact Interfaces and an Artefact Detail Interface. Each Artefact Interface also uses a Shape metaphor and the position of its shape must lie within the bounds of the museum's shape. If the user's intention is to browse a particular artefact, then the artefact detail interface's referent will be set to the selected artefact's referent. This has the effect of showing a form describing the details of the currently selected artefact.