On the Development of User Interface Systems for Object-Oriented Databases Juliano Lopes de Oliveira e-mail:
[email protected] Department of Computer Science University of Campinas (Unicamp) | Brazil
Abstract In this paper we present a user interface system which provides a complete environment for improved browsing in objectoriented database management systems (OODBMSs). The system uses only the basic features of the object-oriented data model, so it can be associated to di erent OODBMSs. The design of our system is based on features that, in our opinion, should be present in any database user interface system. We present and discuss such features. 1 Introduction In spite of the great number of OODBMSs already implemented, there is no agreement in the database research community about a formal de nition of the object-oriented (OO) data model. In fact, the OO data model is composed by a set of properties and functions that database researchers consider essential for a DBMS to be accepted as an objectoriented system. Recently, many papers proposed basic features that should be present in an OODBMS. The following characteristics represent some common points in these propositions: a) To have the basic features of a complete DBMS ; b) To support complex objects and object identity ; c) To support the class concept, and to permit inheritance and class hierarchies; d) To be extensible and computationally complete. Therefore, OODBMSs implement similar features, but they do not follow a speci c set of rigid rules. Due to this diversity of features, interface systems for OODBMSs have an ad hoc design, according to the speci c implementation used in the underlying database system for the fundamentals of the OO data model. In order to help the formalization of this design process, we introduce in the next section directives that should guide the development of OODBMSs user interfaces. As a case study of application of our directives, we present, in section 3, a user interface system for browsing and querying in OODBMSs.
2 OODBMS User Interface: Desired Features This section introduces features that should be considered in the design of user interfaces for OODBMSs. Some of these features represent a synthesis of many propositions from user interface literature, while others were identi ed during our experiments in the development of graphical user interfaces for database systems. Transparency and feedback: An interface is transparent when the user, at any moment, knows what is happening in the system. The user should have knowledge about possible actions in each context, and should know how these actions can be activated. To have transparency, the interface must provide feedback, indicating to the user the action that the system is performing. In DBMS's interfaces, the feedback feature is critical, mainly in querying or browsing activities, when the user wants to search data in a progressive way, based on intermediate results. Concision and presentation quality: A graphical interface needs to be concise in two aspects: a) in the presentation of options and information to the user; and b) in the amount of data input that is necessary for the user to express his desires. Each interface window should contain only the necessary information. Besides, the user should express his necessities and actions in a simple and quick way. The user should be able to lter the system's answers in some way, selecting the amount and the quality of the information that he wishes to visualize. The \presentation" factor is also very important in a graphical interface. However, decorative details should not overload the screen space, neither should they a ect the concision principle. The excessive use of colors and graphical shapes may become a prejudicial factor, grabbing the user attention. Adaptability and tutoriality: A graphical user interface should be tutorial, that is, at any time, the user can ask the system about the current context, about the options available in this context, and about the system functions in general. The system's answer to those questions should be direct, objective and concise, granting the desired help to the user, without overloading him with excessive information. Besides that, the interface should be adaptable to the user's way of working. The system should allow the user to choose the features that compose his workspace, such as fonts, colors, and con rmation mechanisms. Coherence and integrity: The previsibility and the coherence of an interface can be expressed by the fact that identical actions produce identical results in any system context. Those features improve the user understanding, and give
him a feeling of security that contributes to his con dence on the system. The user should have the intuition of the action that the system will perform, even if he is using a command for the rst time. Keeping an unique style in all contexts is fundamental for the system to provide these features. The expression integrity , in graphical interfaces context, refers to the mechanisms of con rmation and to the error handling routines. Con rmation mechanisms should be present to guarantee the integrity of the data manipulated by the interface. The indiscriminated utilization of these mechanisms, however, can make the operation of the system a boring task, a ecting the user performance due to repetition of identical actions. Another way to guarantee the data integrity is through undo mechanisms. Functional completeness: A graphical interface should provide access to the whole set of functions available in a DBMS. This functional completeness may be reached through a single general purpose tool. However, this kind of tool is usually very complex, for both designers and users. For this reason, there is a noticeable trend to develop specialized tools for each particular user group, and for each set of speci c tasks. These tools can be integrated in a homogeneous environment that lls the needs of the whole database (DB) user community. Automatic display generation: DBMSs user interface systems tend to adopt an interaction style based on the navigation and edition of DB objects. These objects can represent information about the DBs structure (schema) or about its contents (data). In traditional data models, the application is responsible for object representation, because object composition semantics is not expressed by the model structures. The new data models (semantic and object-oriented) support modeling of objects structures in a direct way, and the interface system should take advantage of this capability, creating object representations, independent from the application. Of course the application may specify when and how a representation is created, but the operational behavior of the representation is de ned by the interface system. Support of di erent abstraction levels: The support of di erent levels of data abstraction is a feature that complements the automatic presentation generation. The interface should provide facilities for manipulating the presentations, in order to adjust them to the user's necessities. There should exist mechanisms to replace, hide and highlight the structures of a complex object in a presentation. Similarly, it should be possible to associate presentations, by means of hierarchies, for instance, in such a way that a complex presentation could be de ned departing from simple presentations, just as a complex object is composed by the relationships among other objects. The basic point is that the interface should allow the user to choose the detail level for the representation of database information. Data access via DBMS: The automatic generation of presentations improves the isolation between the application's code and the interface management code. To provide this facility, however, the interface system should be able to access data stored in the DBMS. Most database user interface systems performs operations directly on the database, using the embedded knowledge about the DBMS's storage mechanisms. This approach introduces two main problems: the interface system becomes dependent of the DBMS's implementation, and it breaks the classical database system rule, which states that any access to database information is performed by the DBMS. Thus, the interface system should access data through the DBMS. A special module of the
interface system should be responsible for sending and receiving information from the DBMS. It is clear that this module is dependent on the underlying DBMS, as regards command syntax and result formats. However, if the implementation of these dependencies is well designed, the whole interface system can be ported to other DBMSs, with relatively simple adjusts, executed in a single system module. Action independence: A database user interface should guarantee that each user action produces a complete and perceptible result. To each action should correspond one answer or signal, showing that the system understood and accepted the user's command. The concept of action independence is not restricted to this kind of feedback; actually, it is an opposition to the use of processing modes. In the interface systems that use di erent processing modes, the user selects one mode, and from that point on, a di erent set of functions becomes active in the system. This kind of behavior is very hard to understand, mainly for novice users, since each mode has a speci c set of actions. Moreover, identical actions on di erent modes may not have similar semantics. In the interface systems that have the feature of action independence, on the other side, the available set of functions in any context is the same, and action semantics are coherent in any situation. Database integration and representation: The new database generation should provide capabilities for integration with other kinds of applications, such as programming languages, as well as with other DBMSs. Therefore, the user interfaces for these new DBMSs should permit the simultaneous visualization and manipulation of schemas and data from di erent databases. The view concept, traditionally used in the DB literature, can be used to build systems which have the capability of automatic generation of presentations involving objects from di erent classes [MM91]. The same principle can be applied to represent, in a single view, information originated from di erent DBMSs. Note, however, that a DBMS user interface should be constructed according to a speci c data model, in order to express, in a natural way, all the information conveyed by the model. It is not acceptable that an interface system restricts, in any aspect, the expressive power of the underlying DBMS data model.
3 GOODIES Overview GOODIES is a multiwindow graphical user interface, using the direct manipulation paradigm, and supporting multimedia objects. Due to space limitations, we will give a super cial description of GOODIES. For a complete description of the system the reader is referred to [OA93]. Schemas are visualized through three base windows: the directory window, which provides browsing facilities at DB level; the DB window, which presents the list of classes that are de ned in a given DB schema; and the class window, which presents the items that de ne a given schema class. These items are: a textual description of the class composition; a list of its superclasses; a list of its subclasses; a list of methods associated to the described class; a list of object instances that belong to the described class. The object window represents the values of an object instance, according to the class type description. Figure 2 shows an instance of the class presented in gure 1. There are seven groups of object attributes in GOODIES: simple; textual; images; sounds; lists; tuples; and sub-objects. The rst four types of attributes are self-describing. Lists are collections of elements that belong to the same type. Note
Figure 1: Class Window that this attribute do not correspond directly to the type constructor list of the OO model, since the former is also used to represent sets of elements. Tuples represent the aggregation of elements of heterogeneous types, that is, each tuple element may belong to any of the de ned attribute types. Sub-objects represent the concept of complex object .
simultaneously, and GOODIES allows the user to select the attributes that are presented in each object window. The Sequencing operations , activated by the next , previous and rst buttons of the object window, provide access to di erent objects through a single object window. Moreover, every object window has an auxiliary window where the user can de ne predicates. The composition of a predicate follows the rules of the query language of the underlying OODBMS. The user can save predicates, as well as he can load previously saved predicates. In this way, the predicates operate as a view of the DB schema. Predicates are evaluated in sequencing operations. Since an object window can have references to other objects (sub-objects), the act of opening an object window through these references creates a synchronization link between the complex object window and the sub-object window. Each reference to a sub-object can have many associated windows, forming a synchronization tree . A synchronization mechanism guarantees that any sequencing operation is re ected in the whole sub-tree whose root is the object window on which the sequencing operation was performed. It is important to note that the predicates de ned for each object window are still veri ed when the object window is synchronized with other windows. The association of predicates with the synchronization mechanism provided by GOODIES is similar to a query processing facility where the user selects and restricts the required information.
4 Conclusion Improving the access to the whole set of functions provided by DBMSs is the main objective of a database system user interface. However, because of the heterogeneity of the database users community, as well as of the functional complexity of DBMSs, this is not a simple task to accomplish. We summarized directives to guide the design process in order to produce DBMS user interfaces which provide those characteristics. We also presented a generic OODBMS user interface system. The design of the system was based on those directives. At the present moment, a prototype with all the funcionality described in this paper is implemented in a SUN SPARCstation, using the XVIEW toolkit and C++.
Acknowledgments
We wish to thank Claudia Bauzer Medeiros and Ricardo Anido for many hours of helpful discussions about DBMS user interfaces. Figure 2: Object Window GOODIES allows an arbitrary number of nested objects, since all auxiliary windows follow the same scheme for attribute representation used in the object window. The attributes that must be visualized in di erent windows are easily identi ed, because their reference names are ended with ellipses (\..."). Starting from the class window, the user can browse at schema level, either selecting classes from the subclasses and superclasses lists, or selecting methods from the class methods list. The selection of a method presents the method body in a text window. The data level navigation starts with the selection of an instance from the objects list of a class window. This causes the presentation of an object window for the selected object. The user can work with many instances of the same class
References [MM91] Jean-Claude Mamou and Claudia Bauzer Medeiros. Interactive Manipulation of Object-Oriented Views. In IEEE Proceedings of the International Conference on Data Engineering, pages 60{69, Kobe, Japan, April 1991. [OA93] Juliano Lopes de Oliveira and Ricardo de Oliveira Anido. Browsing and Querying in Object Oriented Databases. In Second International Conference on Information and Knowledge Management, pages 364{373, Washington, DC, USA, November 1993.
