FaceKit: A Database Interface Design Toolkit Roger King Michael Novak Department of Computer Science University of Colorado Boulder, Colorado 80309 Abstract FaceKit is an interface design toolkit for object- oriented databases. By combining techniques from the realm of User Interface Management Systems (UIMS) with a built-in knowledge about the specific kinds of tech- Figure 1 niques used by object-oriented databases, we have designed a system that allows a user to customize a data- the database,FaceKit makes designing a specific interface base interface with minimal programming. Knowledge easier and faster, and forces the interface to stay con- about object-oriented databaseconstructs such as classes, sistent with the database. groupings, etc., allows FaceKit to semi-automatically Databaseinterfaces have undergone many changes create graphical constructs appropriate to the object- in the last few years. Until a few years ago, most of the oriented databaseenvironment. FaceKit is built on top of database interfaces we saw where non-graphical. Aside Cactis, an object-oriented database management system from programming language interfaces, they include rela- (DBMS), and is capable of creating interfaces that deal tional algebras such as ISBL lUll], relational calculi like with Cactis both at the schemaand data level. QUEL [HSW75]. and query languages such as SEQUEL Keywords: graphical interfaces, user interface manage- [BoC74], which falls somewhere in between the two. ment systems,object-oriented databases. These interfaces vary in many ways, but their general goal is to provide a general, fairly complete, interface to a data- 1. Introduction base. Then came interfaces such as QBE lZlo75], which provides a form style interface for specifying queries. In FaceKit is a window based, interactive graphical the last few years there has also been much interest in system for designing (we do not support a formal design graphical databaseinterfaces. Among these are interfaces phase; some people might caIl FaceKit a tool for building such as ISIS [GGK85], Ski [KiM84], and SNAP [BrH86]. an interface) graphics-basedinterfaces for object-oriented which allow schemamanipulation in an interactive graphi- databases.Although more of a UIMS than a simple data- cal environment. They also include office forms systems baseinterface, FaceKit is intended for designing a particu- such as FORMANAGER [yHS84]. Freeform [KiN87], lar set of interlaces - those dealing with objectoriented and SPECDOQ lKGM84]. These systemsprovide a non- databases.FaceKit knows about schemas, type-subtype expert interface for the storageand retrieval of office data. hierarchies, methods, and database tools such as data definition languages (DDL). Therefore, knowledge about Obviously, a single interface cannot be everything the types of interfaces being designed and the objects they to everyone. Since many different database interfaces manipulate is built into FaceKit. This knowledge allows may prove useful, we feel that being able to quickly &fault representationsof databaseobjects and representa- design a new or altered interface could prove very useful. tions defined or modified by the user. Both default and UIMS’s are designed for this very purpose. The question user-defined representationsinherit properties in the same is, why not use an existing UIMS to rapidly generateinter- way as the databaseobjects they represent. This allows faces for an object-oriented database? To answer this the user to easily change any class or subclass of object question, a little background on UIMS’s is necessary. representationsand also leave the defaults in effect where We will use the Secheim model of user interfaces desired. By taking advantage of the structure provided by [Gre84,Gre85] (figure 1) to examine and compare some of the existing UIMS systems. The Seeheim model is a logical model applicable to a wide variety of UIMS’s. In this model the user interface is broken into three logical components: the presentation component, the application Permission to copy without fee all or part of this material is granted provided that the copies are not made OT distributed for This work was suppurred in par~ by ONR under contact numbers direct commercial advantage, the VLDB copyright notice and N00014-86-K-0054 and NOO14-88-K-0559. the title of the publication and its date appear, and notice is given that copying is by permission of the Very Large Data Base Endowment. To copy otherwise, OT to Tepublish, requires a fee and/or special permission from the Endowment. Proceedings of the Fifteenth International Amsterdam, 1989 Conference on Very Large Data Bases - 115 - interface model, and the dialogue control. The presenta- directly into the interface. Similarly, interface objects arc tion component is responsible for producing device output actually stored in the databaseand have the samestructure and gathering user input. ‘Ihe application interface model as databaseobjects. Thus, only one view of objects exists. is responsible for representing application data and mak- Even those UIMS’s which sham some data between the ing it available to the interface, as well as providing the interface and the application still require the user to view application with access to the interface. The dialogue interface and application objects scparatcly and to provide component forms the bridge between the presentation information about how the two are related. Having only component and the application interface model. It makes one view of objects means that less information needs to sure that tbe application carries out user rcqucsts and that be provided by the user. Furtbermorc, users do not need to the presentation component produces the output requested keep track of two different types of objects. by the appliiation. By providing accessto databasetools such as query Tbe main emphasis in much of the UIMS research languages and methods, FaceKit also gives the user more has been on the dialogue control component [Gre86]. ways of rapidly constructing an interface. Instead of writ- Although there have been systems with dialogue models ing code to generate an interface technique, the user may based on transition networks, gmrnmers, and events, these invoke a method in the database,or use a query language system share a common perspective. UIMS’s such as to define the technique. Interface objects previously ADM [SRHSS], Grins [ODR85], Menulay [BLS83], created may also be used, because they too are stored in MIKE [Oh%], and Trillium [Hen861all view an interface the database. as a dialogue between the user and the application. The The second mason that we don’t wish to use a user makes a request and the application respondsby per- currently available UIMS is that creating a new database forming some task and possibly providing some output. interface often involves creating a new application. For Similarly, the application makes input requests which the example, an office forms interface involves much more user responds to. ‘Ihe research emphasis in these systems than merely an interface to the database.New functionali- has been on how to provide the user with the appropriate ties must be built into the interface. These may include tools for specifying the dialogue. new mathematical functions such as computing the city Work done on the presentation component includes and state sales tax on a sales field, and utilities such as an Peridot iMye87] and Squeak [Car871 Both of these sys- inter-office memo system. Both of these new functionali- tems put heavy emphasis on allowing users to create new ties involve more than simple interaction with the DBMS. interaction techniques. Peridot users create these tech- In or&r to support this type of interface, we wish to allow niques by using examples to show how they should the user to interactively design both an interface and its appear, while Squeak lets users apply direct manipulation corresponding application simultaneously [HuK88]. principles [HIIN, L&83] to specify them. Unlike in a UIMS, our approach treats the interface being There are also several systems which focus on the designed as a databaseenvironment, rather than a dialo- application interface model. Filters iEge88] and Coral gue between a distinct user interface and an application. [SzM88] each provide a method of specifying relation- Instead of defining merely an interface, we define the ships between application and interface objects. visual, functional, and interactive aspectsof the environ- GWUIMS [SHB86] and H&ens [HuKSS] both allow for ment. Thus, certain otherwise hard to obtain functionali- sharing of data between the application and the interface. ties such as binding representations to objects can be All of these systemsuse an object-oriented data model. achieved. This also allows for “realistic” &fault interfaces and faster specification of representations. In fact, such an Another object-oriented system called GROW integration of database and UIMS technology has been [sar86] looks at some dialogue and presentation issues. suggestedbefore [Gre87,Ols87]. GROW emphasii building modifiable and reusable interfaces. The dialogue component uses messagesfor The minus side of our approach is that neither inter- communication between the application and the interface. faces outside the object-oriented databaserealm nor non- The presentation component provides a kernel of graphi- Cactis database applications are supported. However, cal objects arranged in a taxonomic hierarchy and it many applications may