TIGER:Table Independent GUI Environment for Relational objects
Raman Kannan
Software Engineering Department
Monmouth College, West Long Branch, NJ 07764
ABSTRACT
In this paper we present a reusable classification scheme for manipulating relational database objects, called TIGER. Our object classification scheme captures the end user perspective of graphical user interface elements rather than the developer perspective of user interface elements and thus facilitates the realization of user interface models directly from the user requirements without any intermediate phases, such as analysis. Using these user defined models, a highly intuitive graphical user interface is constructed at run time. The class hierarchy, model specification and screen construction are independent of the underlying table structures and thus existing tables can also be manipulated using our scheme by defining a model.
Pertinent Topic Areas: User Interface Frameworks, ER model and OO Design.
Contact:
Raman Kannan
Email: kannan@moncol.monmouth.edu
Software Engineering Department
Distributed Network Agents Laboratory
Monmouth College
West Long Branch, NJ 07764
Phone:(908) 571-7578
MOTIVATION
Considerable effort is spent on designing and developing graphical user interfaces (GUI) for managing corporate information assets. While in use, GUI is also subject to numerous changes, ranging from geometry (placement) to complex interaction schemes. Further, GUI being the most visible aspect of interactive applications, users tend to demand most from user interfaces. In other words, GUI plays a significant role in user acceptance and must lend itself to rapid changes in the geometry and other related behavior. Consequently, the study of UI design, generation, and maintenance is an active area of research and development, as evidenced by the number of research articles published [1,2,3,4, 6]. The compelling motivation is to better understand and possibly reduce the GUI development effort. Thus, the impetus behind our effort is two fold: application development cost reduction and customer satisfaction. We achieve (1) very high productivity because the entire framework is schema independent and can be used enterprise wide, and (2) a high degree of customer satisfaction, since end users create, modify and model the user interfaces themselves. We now present the TIGER model, architecture, class hierarchy, example scenarios and future directions.
DESIGN RATIONALE
UI design and components are dictated by application specific requirements and the interaction model of the application for which the UI is to be built. Specifically, the underlying UI Widgets (menu bars, dialog boxes) have to be programmed for the particular layout and event management. The predicament is that these widgets support the computer GUI domain rather than the application domain. The resulting conceptual difference requires careful translation between user requirements and UI requirements, and consequently, despite the availability of widget libraries, UI development still requires significant time and effort. Our main objective was to eliminate this translation process [5] in the domain of GUI design, construction and maintenance. To that end, we formulated a unifying semantic model, TIGER Model (TM), for the users as well as the developers, to represent the GUI characteristics of application objects. We devised an interface hierarchy based on the observed interface behavior, conceptually native to the problem domain rather than the traditional UI widget hierarchy. Thus, the model empowers the end user to describe the presentation characteristics in their own terms and the descriptions are translated into highly intuitive interfaces without application specific development effort. We developed a general model that can be applied to most application domains. However, in this article we present, (1) the model for the domain of relational database (RDB) and (2) an application of the model because relational DB are the most prevalent in the industry. For the uninitiated, a relational database is a set of tables and a table is a collection of tuples. Tuples are an ordered set of attributes. Attributes have a domain, the set of all possible values the attribute can take. At any given time, an attribute can take exactly one value. For details see [7,8]. We now present the TIGER model.
THE TIGER MODEL (TM)
TM consists of an extensible set of User Interface Behaviors (IB) appropriate for the relational database (RDB) elements and a catalog of associations. An association is a definition of an RDB element in terms of its desired user interface behavior. At run-time, IBs translate into the familiar GUI objects such as pull down menu, radio button, pop up menu or simply an entry field. For example, consider the attribute, status, for a customer. The attribute, status, can take one of two values (Boolean), open or closed. Correspondingly, in the TIGER model, a BooleanItem, by definition, behaves similar to a Boolean in that there are two(cardinality) permissible values (the domain) and can take one of them at any given time. Thus, in our example: the IB for the status attribute is a BooleanItem; the two permissible values are open and closed; and for a given customer, status can be either closed or open. At run-time an attribute with an IB of BooleanItem is visually presented as a radio button. Note, that we are interested only in their presentation characteristics and not in the application behavior of these objects. In other words, objects have the two distinct behaviors: (1) application behavior and (2) presentation behavior. Thus, TIGER model extends the traditional object model by incorporating presentation behavior, similar to recent efforts, such as (1) MVC Programming [9] and (2) Extended Objects [10]. However, the similarity between MVC and TIGER is limited to the fundamental premise that both approaches distinguish the visual characteristics of an application object from its application behavior. MVC uses a collection of classes to separate business model, presentation and user interaction; TIGER provides an integrated environment to define, manage and interpret the models for relational elements (tables, records and attributes). The TIGER model is implemented as class categories and the implementation classes were derived jointly by the users and developers by considering the characteristics and the operational needs of the users. We call this Joint Class Design (JCD), a subset of Joint Application Design (JAD) [11,12] wherein entire applications are designed jointly by the users and developers. We analyzed the interaction model for existing tables and elements of relational tables. From these we developed models for tables, attributes and interaction. We now present these models.
MODEL FOR TABLES
The TIGER model for tables consists of three different abstractions: Relation, Policy and Screen. Screens are the user interface widgets that facilitate the user interaction. Relations or Tables capture the database schema and the Policy objects capture business process rules as described below. The Screen object isolates GUI abstractions (widgets, callbacks, etc.) from other essential interaction behavior. Tables can be analyzed from two orthogonal perspectives: Business Process perspective and the database schema perspective. Accordingly, we implemented the behavior of a table as two cooperative classes, decoupling these two perspectives. From a business process perspective, tables are either (1) restricted or (2) unrestricted. Restricted tables contain sensitive data and are well guarded. At least two users are required to effect a modification, one makes a change and the other approves the change. No single user can affect a change to completion without verification. Unrestricted tables contain non-critical data and the contents of these tables may be changed immediately by any user without the verification process. Thus, in our model, there are two kinds of Policy classes, facilitating these two processes: (1) Restricted and (2) Unrestricted. However, it should be noted that in real life, business policies tend to be complex and here we have presented a simplified view of the model. From a database schema perspective, for technical reasons, typically, schema are normalized and stored in one or more tables. These relationships are captured in our model by classifying the relations into independent, dependent and primary tables. An independent table is a collection of reference data, such as the list of departments or list of valid currencies or list of nations in the world. A dependent table is one where records can be added only with respect to records in a primary table. For example, account information(dependent) can only be added in the context of an existing customer (primary). The relationship between a primary table and the dependent tables are maintained as bi-directional associations, such that users can access a primary table while manipulating a dependent table and vice versa. Thus, in the TIGER model a relation is characterized by a business policy {Restricted and Unrestricted} and schema classification {Independent, Primary and Dependent}.
The screen captures the essence of the business policy as well as the characteristics of relational tables as shown in the Booch Diagram[13] in Figure 1. There are three kinds of screens, Maker, Checker and Browser; and each class of screen implements a distinct operational behavior as shown in Figure 2.
Each screen has an underlying relation. Screen objects support query by example for retrieval. In addition, (1) a maker screen supports common activities such as deletion, addition, and modification; and (2) the checker screen facilitates, approval and rejection. Users can also navigate from a primary to a dependent table and vice versa from with in a screen object.
MODEL FOR ATTRIBUTES
From our JCD analysis, we classified the set of all attributes using two orthogonal views: (1) A validation perspective and (2) a cardinality perspective. From a validation perspective the values are subject to validation before being committed into the database. Consider a customer phone number. A phone number, as we know it, can only be numeric (type integrity). Similarly, the domicile of a customer can only be one of the well-known countries (referential integrity). The cardinality view, on the other hand, specifies the number of legitimate values for a given attribute. Thus, at run-time, the validation characteristics are translated into the callbacks to be associated with GUI elements; and the cardinality aspects are translated into the type of GUI widget (radio button, File Widget, Pop UP Menu, etc.) required to display the underlying attribute. Consider the following examples: (1) the attribute, gender, for a customer can take one of two values (Boolean), male or female; (2) the state of origin for a customer must
be one of the 52 states within the USA (static list),and (3) the customer name is unrestricted and is to be entered by the users (user entered). A Booch diagram [13] for this classification is presented in Figure 3 and a catalog of the TM for attributes is presented in Table 1.
MODEL FOR USERS
Typically, diverse set of users own and operate the enterprise information base and so frameworks must accomodate the needs of a variety of user groups. Thus, we categorized the users according to their job function. There are essentially 3 kinds of users: (1) Those who lookup information; (2) Those who add/delete/modify information; and (3) those who verify/approve these modifications. Note that these
TM Category Special Behavior Example
Attribut
e if
any
BooleanItem one of two values gender {male, female}
StaticListItem one of a short list of customer_status{active,
values
closed,
inactive,restricted}
DynamicListItem Present the user with customer_domicile
a list of values from {must be a known
a column in a country, listed in the
different table, country table}
preserves referential
integrity
UserEnteredItem anything value entered by user Customer Name
alphabet value entered by user City name
s can only be alphabets
numerals value entered by user Phone number
can only be numerals
alpha-nu value entered by user Postal Code
meric can only be alphabets
+ numerals
masked value entered by user Password, or other
will be masked by a sensitive information
specific character that should not be
visible in plain text.
ReferentialItem value entered by user
but must be validated
against a column in
another table as in
DynamicListItem.
functions correspond to the operational behaviors presented for a screen: (1) Browsers, who lookup information ; (2) Makers, who manipulate the tables (add, delete, modify the records in the table); (3) Checkers, who approve the modifications. Additionally, there are two special classes of users, (1) Managers, who could assume either role Maker/Checker, and (2) System administrators who set up users, tables and these classes were realized by simple specializations. A Booch Class hierarchy for the user hierarchy is presented in Figure 4.
ANALYSIS
The TIGER model for attributes, users and screens is independent of the underlying relational schema and captures both the static and dynamic aspects of GUI, enforcing a uniform interaction model for the entire information base. These components can be used in a variety of applications. In the relational table domain, the model is rich enough to capture relationships between tables and, at run time, navigation, validation, and access control are fully supported. The model can be enriched by implementing additional abstractions.
The abstractions, {table, attribute and user} are implemented as three different class hierarchies. For the tables and the attributes, the associated GUI behavior, such as radio button, pull down menu, etc., are encapsulated within these classes. As users required new features, additional derived classes implementing the required specialization were incorporated. For example, the ReferentialItem inherits behaviors from both a UserEnteredItem and a DynamicListItem with minor modifications. In Table 2, we present these associations between the model and GUI domain.
From the user perspective TIGER framework exploits the capabilities of OOD methodology to maintain one to one correspondence between the software components and user specification. The need for explicitly translating user specifications to corresponding UI Widgets is obviated.
Table 2: TIGER model and GUI Widget Association
Model Specification Software Comments
(end user) Interpretation
Maker Application maker specific operations
Window
Checker Application checker specific operations
Window
Browser Application browser specific operations
Window
UserEnteredItem Text Entry with a validation function
(alphabets only) for alphabets
UserEnteredItem Text Entry with a validation function
(numerals only) for numerals
UserEnteredItem (mask) Text Entry with a validation function to
mask
BooleanItem RadioButton the two values are specified
by the user
StaticListItem PopupMenu the value list is specified
by the user
DynamicListItem PopupMenu the table, column is
specified by the user
ReferentialItem Text Entry the table, column is
specified by the user
and if the entered value is
not found in the column, the
list of possible values is
displayed.
TIGER FRAMEWORK
Our framework can be summarized as "Assembly by Declaration," founded upon the premise that the definition of an application entity must include its intended "presentation behavior" as well. Database designers and end users prescribe a desired UI behavior and a corresponding GUI is constructed at run time. Abstract data type includes the memory structures and associated behavior. Generally, OO model includes the behavior from an application point of view. Like MVC and Extended Objects, we introduce the third dimension: the presentation behavior. In other words, business entities include data members, application behavior and presentation behavior. The TIGER framework is declarative (or data driven) in that users define how the tables are to be presented using the model and the corresponding GUI screens are assembled at run-time by a model interpreter. These GUI definitions are held in a model repository and may be changed, which allows the users to experiment and customize the GUI without incurring expensive modification at the implementation or design level. Thus, by combining the two design methodologies OO design and "Data Driven" design, the TIGER framework empowers the end user to design, modify and use highly intuitive, contemporary user interfaces for managing corporate data.
ARCHITECTURE
The TIGER architecture is composed of a (1) TIGER Model Interpreter (TMI) (2) TIGER UI Model Repository (TMR) (3) a run-time TIGER class library (TCL) as shown in Figure 5. TMR is a catalog of associations and the characteristics of the association. The prototype TMR is stored as a set of relational tables as well. The TCL implements the set of user interface behaviors using commercially available user
interface packages. The TMI is a simple control abstraction. Given a table name, TMI retrieves the model information for the table in the context of the executing user, and constructs a screen appropriate for the user business function. For manipulating the database, SQL based commercial libraries are used. For OS specific functions such as user authentication, POSIX compliant System services are used. The initial prototype of our system is used to manipulate strictly relational objects managed by a single database management system, such as, Oracle and Sybase DBMS. At the Distributed Network Agents laboratory, we are in the process of incorporating database independence such that TIGER can be used to manipulate any number of data store packages such as Ingres, Postgres and other Object Oriented databases.
DISCUSSION
In this section we consider related work and future enhancements. Commercially available UI Generators [14][15][16] as well as research endeavors to automatically generate forms [17][18][19][20] were well known. However, upon further investigation, we found it worthwhile and justifiable to continue with TIGER. Here we present some of the justification.
At the time of the prototype development, commercially available toolkits, such as, OI toolkit [14] and Oracle SQLForms [15] were initially considered. Our task at hand then was to implement GUI based data management screens for more than 40 tables. The OI toolkit was adequate to create generic widgets but required customizing as many screens as there were tables. This alternative was considered unacceptable due to the following reasons: (1) customization and setup cost in terms of human effort; (2) cost of propagating the changes and upgrades; (3) required technical specialization and maturity for direct manipulation by our typical end user; and (4) prohibitive cost to acquire one license per end user. In addition to the above disadvantages, Oracle SQLForms suffers from being database-centric as well and consequently these tools were not considered any further. Instead, we created the class libraries (Item hierarchy, AppWindow hierarchy) using these toolkits; and these class libraries were then used to build the model interpreter. At run-time the model descriptions are translated into these class objects by the model interpreter.
The research systems identified were quite helpful to validate our approach for correctness and feasibility. However, the focus of systems described in [17][18][19] was on forms and office automation. In [20] Choobineh et. al describe a system for designing and analyzing databases using forms. Several conceptual elements in characterizing database elements are similar, as in, User-Triggered, Form-Triggered for screen fields and Parent-Child Categories. Thus, the tool is database intensive whereas our tool is GUI intensive. For example, support for translating database elements directly into graphical user interface elements such as dialog boxes, menus, etc., is not evident. In particular, the mechanisms to enforce arbitrary validation schemes, such as, ASCII, Alphanumeric, Numeric and Masked are not supported. In contrast, in our framework, a column in a table (attribute) can be classified as UserEntered(Alphabets only) and at run time the character validation functions are attached at the user interface level automatically. However, it should be noted that their model included input in non-ASCII forms such as bit-maps and voice which were not even considered in TIGER framework. Further, the implementation platform (LightSpeed Pascal in Apple Macintosh environment) was considered unsuitable for our needs.
Future enhancement will include incorporating automatic characterization of attributes and support for multi-database integration. Our intention is to inductively classify attributes within a table by scanning the populated database values. For example, if a column contains only numeric values, then the column may be characterized as UserEntered(Numerals Only) or if a column contains values whose domain is a small number of distinct values, then the column may be classified as StaticListItem.
SUMMARY
In this paper we have presented the TIGER model for constructing highly intuitive GUI for relational database elements directly from specifications. Our approach is founded upon the basic concepts: (1) User Interface behavior must also be defined for application objects; (2) While the layout and the particular elements that make up a GUI is very specific to the underlying schema, the traits of the elements themselves are common and generic, as in a BooleanItem; and (3) the traits can be captured using a simple, descriptive model.
Our environment is rich in presentation capabilities and effective in containing software development lifecycle costs. Using the model interpreter and the model repository, any number of existing relations (tables) could be manipulated by building a model. The tables need not be modified and most importantly, schema specific software does not have to be written. New tables can also be incorporated by defining the UI model for these entities in the model repository and without writing additional software. Most commonly used validation schemes, referential integrity enforcement and navigation, are supported. Users do not have to be proficient in SQL or the database schema.
From a development process perspective, the model was designed jointly by the developers and the users which resulted in a smooth transition from development into production. We have implemented the model using multiple application design paradigms, namely OOD and the data driven model. As a result, the framework is highly extensible, reusable and adaptable. In particular, (1) because of object orientation, new UI behaviors and other business policies may be incorporated without having to re-design the core components of the system; and (2) being data driven, existing tables and newer tables can be incorporated as needed, by defining a model rather than undertaking a development effort.
Although, our discussion is centered around relational objects, the classification and the architecture are generic and can be used to manipulate other repositories. For example, a BooleanItem is rendered as a RadioButton whether the underlying element is a column in table or the attribute in an Object Oriented Database. To incorporate other repositories, the Database Library has to be replaced by an equivalent library. Thus, we claim that our approach is table independent.
Finally, we summarize our experience as follows:(1) given the interface behavior and a unifying model, scalability and extensibility can be achieved by adopting a model driven UI generation paradigm; (2) the arduous and repetitive task of static GUI layout design can be relegated to a model interpreter; (3) close correspondence between what is specified (system specification), and what is delivered (design through software and documentation) can be maintained using appropriate technologies and methodologies, such as Object Orientation; and (4) the traditional difficulty in completing non-trivial software projects can be alleviated by teaming with the user community.
ACKNOWLEDGMENTS
The Item and the AppWindow categories of the TIGER model and the initial prototype were conceived and implemented by the author as a technologist at Citibank, N.A, where the prototype is widely used. The author acknowledges the DBMS manipulation library developed by Richard Toynbee at Citibank, N. A., and the support given by the following team members: Byron Nicas, Luis Soto, and Herbert Rodriguez. At the DNA laboratory, unified environment for a heterogeneous multi-database environment is being developed and is largely unfunded. The author acknowledges the support given by the volunteer graduate student members of the DNA laboratory, Software Engineering Department, Center for Telematics, Monmouth University and ASSET Corporation, Holmdel, New Jersey. Trade marks are used only for reference purposes. SQL is an ANSI standard for manipulating relational databases. POSIX is an IEEE standard defining portable operating system interfaces.
REFERENCES
1. Betts, B. and et. al.. Goals and objectives for user interface software. Computer Graphics, 21, 2, (April 1987) 73-78.
2. Coutaz, J. Abstractions for user interface design. IEEE Computer, 18, 9, (1985) 21-34.
3. Nielson, J. Iterative User-Interface Design. IEEE Computer, 26, 11, (1993), 32-41.
4. Nielson, J. The Usability Engineering Life Cycle. IEEE Computer, 25, 3, (1992), 12-22.
5. Williams, M.G. and Begg, V. Translation between Software Designers and Users. Communications of the ACM, 36, 4, (1993), 102-103.
6. Feller, P.H. User Interface Technology Survey. Technical Report, Software Engineering Institute, Carnegie-Mellon University, CMU/SEI-87-TR-6, (April 1987).
7. Date, C.J. An Introduction to Database Systems. Volume 1, (1981), Addison Wesley, Reading, MA.
8. Date, C.J. Relational Database: Selected Writings. (1986), Addison Wesley, Reading, MA.
9. Glenn E. Krasner and Stephen T. Pope. A Cookbook for Using the Model View-Controller User Interface Paradigm in Smalltalk-80, Journal Of Object Oriented Programming, August-September 1988, 26-49.
10. Marc Rettig, Gary Simons and John Thomson. Extended Objects, Communication of the ACM, August 1993, 36, 8, 19-24.
11. August, J.H. Joint Application Design; The Group Session Approach to System Design. Yourdon Press, Englewood Cliffs, NJ., 1991.
12. Wood, J. and Silver, D. Joint Application Design: How to Design Quality Systems in 40% Less Time. Wiley, New York, 1989.
13. Booch, D. Object Oriented Analysis and Design with Applications. Second Edition. Benjamin/Cummings Publishing Company, Inc., Redwood City, CA 94065, 1994.
14. User Manual, Object Interface (OI toolkit), ParcPlace Systems.
15. User Manual, Oracle Family of Products (SQLForms in particular), Oracle Corporation.
16. User Manual, TAE Plus, Century Computing, Inc.
17. Tsichritzis, D. Form Management. Communication of the ACM 25, 7, July 1982, 453-478.
18. Yao, B., Hevner, A., Zhongzhi, S., and Luo, D. FORMANAGER: An office forms management system. ACM Transactions Office Information System, 2, 3, July 1984, 235-262.
19. Shu, N. Formal: A forms-oriented, visual-directed application development system. IEEE Computer, August 1985, 38-49.
20. Joobin Choobineh, Michael V. Mannino and Veronica P. Tseng. A Form-Based Approach for Database Analysis and Design. Communication of the ACM, 35, 2, 1992, 108-120.