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 basedon 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 be be placed into an object- allows the user to specify inter-object relationships. oriented database.For example, much of the circuit board design software currently available uses simple files to There are two main reasons why we don’t wish to store circuit information. Such systems could easily fit use any of the currently available UIMS’s. First, even into the object-oriented database paradigm. One could though we have seen systems which can communicate argue that even aside from making it possible to use with application data in some manner, a general purpose FaceKit with the application, storing the data in a database UIMS has no knowledge of database schemas. Since would make the application itself more manageable. FaceKit knows about databaseschemas, users may access database objects, methods, etc. and incorporate them

- 116- opcrafionul component. Both the representational and operational componentscommunicate directly with Cactis (figure 2). but their tasks are quite different. The primary responsibility of the rcprescntational component is managing the visual representationsof data- base objects. For the purpose of this discussion, database object, or object, may refer to a constructed object, rela- tionship, or attribute. Also, no distinction is made between schema and data objects at this time. The representational component builds, maintains and invokes the methods used to produce the visual representationsof objects. Thus, if we build an interface where a data object called person is representedby a screen image of that pcr- son, the representational component makes sure that the Figure 2 method used to draw these screen images is invoked at the proper times, with the correct parameters. 2. Modeling an Interface The representational component is also responsible FaceKit is built on top of an object-oriented DBMS for the input and output associatedwith an interface. Input named Cactis [HuK86,HuK87]. Since FaceKit has will generally consist of reading in someuser data or com- knowledge about both Cactis schemasconstructs and the mand, while output will consist of either displaying new various schema manipulation tools (DDL, C language objects on the screen or invoking a different representa- interface, etc.) available within Cactis, we will give a brief tion of objects already present. An object may have many description of the %actis data model before proceeding to different visual representationsin the same interface. For describe the data modeling aspectsof FaceKit example, a databasemay have a baby picture and an adult Cactis views an application environment as a collec- picture of the person in the example above. tion of conslrucred o&crs. An object may have uuribues The operational component is responsible for pro- and relationships. Objects and relationships are typed. A cessing user queries and sending the results to the constructed object’s type is determined by two things: its representational component so that the correct screen attribute structure and its connecrors. A connector allows updates will be performed. The operational component a relationship to be applied to a certain object. An attri- performs a function much like that of the dialogue control bute is an atomic property of a constructed object. These in the Seeheim model. However, it has access to the atomic properties may be of any C data type, except Cactis database management tools. This means that no pointer. A relationship is a directional mapping from one application interface model is necessary. Instead, the constructed object to one or more constructed objects. operational component talks directly to the application. Restrictions such as non-null or unique may also be put on This has several advantages. First, it allows FaceKit to a relationship. store the operational description of an interface within For example, a constructed object called person Cactis. Therefore, Cactis managesboth the data and the may have the attributes name, social-security-number, operational description. Not only does this make storage and age, which are all atomic and single-valued. It may of interface descriptions convenient, but it also allows also have a connector called children and a connector operations to be functionally depcndcnt on anything called parent. The directed relationships my-children and present in the database.This allows an interface to change my-parent can be used to connect people to their immedi- its behavior as the database is modified. Second, since ate family. Relationships may be used to pass attributes these tools give the interface direct accessto the applica- from one object to another, in order to calculate derived tion data, semantic feedback can bc gathcrcd merely by attributes. In this way, the social security number of a per- examining the relevant data. Similarly, constraints can be son could be passedto a child over the my-children rela- checked and adheredto. tionship, and used as the value of an attribute called Perhaps the most important effect of allowing the mygarent’s_social-security-number. operational component access to these tools is utilized’ FaceKit uses the data mode1 and the database when designing interfaces. Instead of only being able to managementtools provided by Cactis for data and schema bind a user request to some application subroutine, the manipulation. An interface needs to communicate with interface designer may construct a query using one of these Cactis tools and it needs to managevisual represen- these tools. Since new interface functionality can be tations and coordinate interface tasks. To accomplish this added quite rapidly in most cases,most of the functional- a FaceKit interface consists of two conceptual com- ity of Cacti.9can easily be plugged into an interface. ponents: the representational component and the

- 117 - Figure 3 3. Designing an Interface sample applications of this interface. We will also show A very common UIMS approach to designing inter- how an interface used to retrieve information about com- f&es is to specify screen layout, then bind each possible puter networks can be built using FaceKit. user action to a specific application subroutine. Often, interface routines for the application program to call are 3.1. Defining Representations with FaceKit also provided. FaceKit takes a different approach to In figure 3, an object representation is being designing interfaces. Our approach allows the user to defined. The buttons on the left specify what kind of d&e what we view as two somewhat different aspectsof object is being defined and the line on top is a status line. the interface: appearance, and functionality. When In this case, the object type to be defined is all ( the &fining appearance we are really delining two kinds of representation being defined is applicable to all types in visuals, interface constructs and database objects. By the database). The current level and view are both interface constructs we mean items such as menus, schema. Two views are possible: schema and scrollbars, etc., as well as concerns like screenbrightness, class/subclass hierarchy. The schema view is the stan- icon sixes, etc. Defining the appearance of database dard graphical view of a database schema, while the objects involves specifying representations for a class of hierarchy shows a forest of classesand subclasses. Two objects. A representation may be identical for each data levels are also available: schema and data. The schema object in a class or it may be data dependent. In fact, it level lets us work with object types, while the data level may be dependenton external data For example, we may lets us work with object instances. The commands for use the system cloclr to determine the brightness of a pic- changing the view, level, and object type are available ture that representsthe data object sun. through a popup menu. The popup menu also has com- By defining the appearance of database objects mands for placing restrictions on the representationbeing separately, we need not worry about them when defining defined, moving around the schema,etc. functionality. The type of the query result determines the In the schemashown, the text enclosed in rectangles screen appearance. Any type that has no user-defined represents constructed objects and the unenclosed text representation will use a built-in default representation. represents the attributes of the constructed objects. The For example, if a query results in an object of class per- narrow arrows represent one-to-one relationships and the son, the interface automatically uses the representationof wide arrows representone-to-many relationships. person that has been defined. If one wishes to leave the Instead of representing a schema as a connected screen alone and produce the query result elsewhere, this graph, we will represent relationships with inclusion. may also be specitied. Thus, the object pointed to by an arrow will be included Both appearance and functionality are defined inside the object the arrow originates from. Also, atui- interactively with FaceKit. In or&r to better explain how butes will be included within the constructed object they they am defined, we will show how one would go about belong to. Once we choose relationship and inclusion defining an existing interface, an office forms system (figure 3). the schema changes to look like ligure 4. The called Freeform llCiN87]. We will also show some label on top of each box is the name of the relationship

- 118 - Object type: 411 IVIew: Schema

ilnwc, Plmm,yp --JYlm dam invoiaJmmba aDmmam

Figure 4 between the object representedby the box and the object it 3.2. Defining Operations with FaceKit is includ+ in. The double box around purchase denotes An operation definition window is shown in figure that it is a onetemany relationship. 5. The schema shown is a refined version of the schema Although the representation looks fairly formlike in figure 4. Although there is no reason we cannot have now, some further refinement is still needed. Attributes both the representation definition and operation definition need to have a line for filling in data behind them, windows up simultaneously, we will qnly use one at a representationsneed to be made different for various types time in order to make our diagrams less crowded and of attributes, and multi-valued relationships such as pur- confusing. A user building an actual interface would prob- chaseneed to be reprekentedwith some appropriate suuc- ably use them simultaneously. ture like a table. Since the details of these changes are By selecting an action (or sequenceof actions) from very similar to the examples above, we will not show the Action buttons and a result (or sequence of results) them. Instead, we will give some examples of defining from the Result buttons, the user can bind the desired functionality. functionality to a set of actions. For example, supposethe sequence pick, new action, and menu is selected. This specifiesthe following sequence.The user picks an object.

Figure 5

- 119- Opcrstim Oefhltlm uindad) , right mOUI. button COnflmS)

will demonstratehow one goes about defining a menu.

Edlttsa - lo ncrell deprerr lctt bmttec This is done by defining each menu item and its correspondingfunctionality. The menu item being de&d in figure 6 is Describe Current Object. ?he result of choosing this menu item will be a query, which will be definedin the OperationResult Specification window. We will &fine tbii query using the DDL. The DDL being used is a simplified version of the Cactis DDL [SwS88], with some pseudo-code added. Open-win. print, and all variables in lower case are FaceKit con- structs.All uppercase words are DDL keywords. First, the query opens an output window, then checksto make sure that the current object is of the class constructed. If it is not, an enxx messageis displayedin the output window and tbe query is complete. Otherwise, all attributes, relationships, and met@is directly con- nected to the current object’s type are found. This infor- mation is formattedand displayed in the output window. The result of selecting the Describe Current Object menu item from within Freeform is shown in figure 7. The current object is the one surrou&d by a dashed border. Both objectsthat appearon the form and thosethat do not, are found by the query. For example,the attribute birthdate is presented because it is in the database, althoughit is not part of the form being displayed Figure 7 Queries may also be produced by calling Cactis C routines.Currently, theseare the only two query methods The result of this is a new action. This new action will be Ihe appearanceof a menu. Therefore,we are causingthe implemented.We will not give any examplesof C queries, a pick, in Freeform,to createa menu. Sincea menuis to sincethey am conceptuallysimilar to DDL queries. hc created,a Menu Specificationwindow is created. so that we may specify which menu to use. Figure 6 shows 3.3. A Software Engineering Example sucha window, with a new menubeing dcfincd.We could Since most software engineersnow have accessto havealso chosenan alreadydefined menu, bul instead,we one or more computernetworks, they needan easyway to

- 120 - Object Data I

Figure 8 get information about these networks. With network Each CSNET-nude contains a numberof comput- configurationschanging fairly often, storing the‘informa- ers. Figure 9 showsa classhierarchy for the schematype tion in a databasemakes good sense. Having a graphical computer. In this hierarchy, computer is the basetype, interface to access such information also makes good mainframe, workstation, and micro are subtypes,and so sense.Our next exampleshows part of such an interface on. Classesare representedby enclosedtext and attributes beingbuilt with FaceKit. Sincethis interfacedoes not look are representedby unenclosedtext. Attributes are con- particularly “formlike”, it is good for illustrating the nected with lines: subclassesare connectedwith arrows. varietyof interfacesthat can be built with FaceKit Although this schemais not complete(for readability),we In Figure 8, we show a pictorial representationof a can seethat computerssuch as a Pyramid and a Sun 4 are smallsubset of the CSNET sitesin the United States.This different and contain different attributes. The database representation was built by invoking a method (not also contains methodswhich deal with this information. shown) that plots databaseobjects of type CSNET-node. Thesemethods are also accessibleto FaceKit. Due to spaceconstraints, only a small part of the map is For example,a methodwhich draws the representa- shown on the screen.Note that actual data, not schema tion of a computermay exist in the database(or one may information,is being displayed. be created specifically for this interface). FaceKit can access this information in order to create a graphical

View: Schema

Figure 9

- 121 - Sun 4 (server) Black/White Hard Disk - 250 Meg. I..,. l-rl Optical House

Figure 10 representationof a CSNET site (figure 10). Each com- 3. Future Directions puter at the selectedsite is shown along with its type and There are several areas of related research we name. How they ate connected to each other is also would like to explore in the future. First, we want to look shown. In this example,the gateway to the CSNET is a into giving FaceKit the ability to bootstrapinterfaces. An VAX U/780 named boulder. FaceKit doesnot evenneed interface designer could then design an interface using to know the specificsabout eachcomputer at that site. For interfacespreviously designedwith FaceKit. For exam- eachcomputer at that site, the databaseknows its type and ple, Freeformcould be used to define representationsand the proper method for that type is invoked. To build this operations when building a new interface. Along the part of the interface, we only had to specify the screen sameline, we would like see if interfacesnot built with relationshipsbetween the computersat a site. FaceKit could be usedas tools for building interfaceswith Figure 10 also contains a popup window that FaceKit. This means that some methods for translating displaysattribute information about a selectedcomputer. random interface queries into a form usable by FaceKit Since different computers have different attributes, the need to be developed.Whether this is feasible to any information given for a Sun will differ from the informa- significantextent, remains to be seen. tion given about a Pyramid. Once again, the database There is also the issue of portability. Currently, already knows these differencesand therefore, much of FaceKit is built on top of Cactis. Is it possibleto createa our work is done for us, especially if there is already a tool like FaceKit that can be easily connectedto a wide set built-in methodfor displayingattribute information. of object-oriented databases?Also, can the techniques used by FaceKit be successfullyused by other UIMS’s? 4. Implementaticm The techniquesthat dependon extensiveknowledge of the FaceKit is implementedon Sun workstations.It is application may not translatewell to a general purpose written in C and runs in a UNIK environment.All the UIMS. However, they may prove useful in other special window managementis done using Sunviews window application UIMS’s. Identifying these applications and package. This package also produces the graphics and seeingwhich techniqueswork well with themcould prove handlesuser input. SinceSunviews manages the windows, to be an interestingresearch problem. they may be moved,hidden, resized, collapsed, etc. just as any other Sun window. References Methods for creating relxesentationsare stored in b4.361 P. S. Barth, “An Object-OrientedApproach Cads along with the databaseobjects they represent.No to Graphical Interfaces”, ACM Trunsucrions distinction is made between them and regular Cactis on Gruphics5,2 (April 1986). 142-172. objects. Operation descriptions are also in Cactis, but [BoC74] R. Boyce and D. Chamberlin,“SEQUEL: ,A FaceKit creates separatedatabase objects (diitinct from Structured English rheQuery Language , regularCactis objects) for storing them. Proceedings of ACM-SIGFIDET

- 122 - Workshop on Data Descri don. Access and [KiM84] R. King and S. Melville, “Ski: A Semantic- Control, May 1974,219 -2c! 1. Knowledgeable Interface”, VLDB [BrH86] D. Bryce and R. Hull, “SNAP: A Graphics- C”;$?rence Proceedings, Singapore, August based Schema Manager”, IEEE Conference . On Data Engineering, 1986,151-164. [KiN87] R. King and M. Novak, “Freeform: A Uscr- @3LS83] W. Buxton, M. R. Lamb, D. Sherman and K. Adaptable Form Management System”, C. Smith, “Towards a Comprehensive User VL.DB Conference Proceedings, Brighton, Interface Mana ement System”, Computer England, 1987. Graphics Z7,3 (f uly 1983). 35-42. [KGM84] H. Kitagawa, M. Gotoh, S. Misaka and M. [Car871 L. Cardelli, “Building User Interfaces by Azuma, “Forms Document Managcmcnt Direct Manipulation”, Digiral Sysrems System SPECDOQ - Its Architccturc and Research Center Tech. Report, October 1987. Implementation”, SIGOA Conference Proceedings, June 1984,132-142. i3gef-W R. K. Ege, “Defining Constraint-Based User Interfaces”, Data Engineering 11, 2 (June [LeL83] A. Lee and F. H. Lochovsky, “Enhancing 1988), 54-63. The Usability of an Oflice Information System Through Direct Manipulation”, CIII [GGKSS] K. J. Goldman, S. A. Goldman, P. C. Conference Proceedings, 1983, 130-134. Kane&&is and S. B. Zdonik. “ISIS: Interface for a Semantic Information System”, [We871 B. A. Myers, “Creating Dynamic Interaction SIGMOD Conference Proceedings , May Techniques by Demonstration”, CIII + GI , 1985.328-342. 1987.271-278. FEW M. Gtyn, “Report on D$logue Specification [ODR85] D. R. Olsen, E. P. Dempsey and R. Roggc, TO’o! I; Computer Graphics Forum 3 (1984). “Input/Output Linkage in a User Interface - . System”, Computer Graphics 19, 3 (July 1985). 191-197. [Gre85] M. Green, “The University of Alberta User Interface Management System”, Computer [Ols86] D. R. Olsen, “MIKE: The Menu Interaction Graphics 19.3 (July 1985). 205-213. Kontrol Environment”, ACM Transactions on Graphics 5,4 (October 1986), 318-344. KM61 M. Green, “A Survey of Three Dialogue Models”, ACM Transactions on Graphics 5, [Ols87] D. R. Olsen, “Larger Issues in User Interface 3 (July 1986). 244-275. Management”, Computer Graphics (ACM SIGGRAPII Workshop on Software Tools for [Gre87] M. Green, “Directions for User Interface User Interface Management 21, 2 (April Management Systems Research”, Computer 1987). 134-137. Graphics 22,2 (April 1987), 113-l 16. [SRH85] A. J. Schulert, G. T. Rogers and J. A. [Hswm fk3ss M. Stonebeer and E. Wong, Hamilton, “ADM - A Dialog Manager”, CIII : A Relational Data Base 85, April 1985,177-183. Mana ement System”, Proceedings of the AFIP H National Computer Conference 44 J. L. Sibert, W. D. Hurley and T. W. Bleser, (May 1975), 409-416. “An Object-Oriented User Interface Management System”, Compuler Graphics [Hen861 D. A. Henderson, “The Trillium User 20.4 (August 1986). 259-268. Interface Design Environment”, CHI 86 Proceedings, April 1986,221-227. [SwS88] M. Swain and C. Stepleton, “Design of a Data Definition Language for Cactis”, [Hlm461 S. Hudson and R. Kin , “CACTIS: A University of Colorado, Compuler Science Database System f or Specifying Dept. Tech. Report, December 1988. Functionally-Defined Databases”, Proceedings of the International Worksho [SzM88] P. A. Szekely and B. A. Myers, “A User on3Tbjecr-Oriented Databases, Sept. 198% , Interface Toolkit Based on Graphical Objects . and Constraints”, 0OPSL.A Proceedings, 1988,3645. tatEn and R. King, “Object-Oriented IHuK871 J. Ullman, “Principles of Database support for Software [VIII Environments”, SIGMOD Conference Systems”, SecondEdition, Computer Science Proceedings, May 1987. Press. lP~881 S. Hudson and R. Kin “Semantic Feedback [YHS84] S. B. Yao, A. R. Hevner, Z. Shi and S. Luo, in the Higgens UIM J “. IEEE Transacrions “FORMANAGER: An Oflice Forms on Sojlware Engineering 14.8 (August 1988). Management System”, ACM Transactions on O&e Information Systems 2, 3 (July 1984), [HHNI E. L. Hutchins, J. D. Hollan and D. A. 235-262. Norman, “Direct Manipulation Interfaces”, in User Centered System Design ,87-124 . [Zlo751 M. M. Zloof, “Query By Example”, Proceedings of the Narional Cornpurer Conference 44 (1975), 431-438.

- 123 - - 124 -