Keywords user interface, data model, automatic generation, screens, graphical user interface introduction




Скачать 35.64 Kb.
НазваниеKeywords user interface, data model, automatic generation, screens, graphical user interface introduction
Дата20.12.2012
Размер35.64 Kb.
ТипДокументы

Bajaj, et al. User Interface Generation From The Data Schema

User Interface Generation From The Data Schema



Akhilesh Bajaj

University of Tulsa

akhilesh-bajaj@utulsa.edu


Jason Knight

University of Tulsa

jason-knight@utulsa.edu



ABSTRACT


Traditionally, the data and process models have been considered separately when modeling an application for construction purposes. System analysis and design has largely ignored the issue of the relationship between the user interface (UI) and the underlying data schema, leaving UI creation within the purview of the human computer interaction (HCI) literature. Traditional HCI methods however, underutilize the information in the data schema when designing user screens. Much of the work on automatic user interface (UI) generation has met with limited success because of the added load on the human designer to use specialized scripts for UI specification. In this research in progress, we propose a methodology applicable to database driven systems that a) automatically infers a draft interface directly from an extended entity relationship (EER) model schema and b) lists the interactions that need to take place between the designer and the tool in order to generate the final user schema.

Keywords


user interface, data model, automatic generation, screens, graphical user interface

INTRODUCTION


The graphical user interface has become both ubiquitous and relatively uniform in providing access to applications for diverse users (Myers et al., 2000). From the early 1980-s, user interface (UI) management systems focused on providing human designers high-level specification languages such as state transition diagrams or event based representations to specify the interface in response to events (Jacob, 1986, Olsen, 1986). These representations have become progressively richer and model-based interface development tools today range from automatic interface generators to tools that offer advice based on task representations.

This research in progress is important because traditionally, the data model and the process model have been considered separately when modeling an application for construction purposes. The system analysis and design (SA&D) area has largely ignored the issue of the relationship between the user interface (UI) and the underlying data schema, leaving UI creation within the purview of the human computer interaction (HCI) literature. Traditional HCI methods underutilize the information in the data schema when designing user screens. However, business applications are usually database driven, and the UI for most business information systems represents processes that allow users to interact with the data. In this work, we take a first step in bridging this gap between the SA&D and HCI literatures, and propose a generalized methodology to generate a UI that uses the data schema as the foundation.

Figure 1 (Szekely, 1996) describes the model-based interface development process. The model component organizes the specification into three layers. Domain models correspond to the data schema. Examples of task models include data flow diagrams or other activity diagrams. An abstract UI specification provides a set of low level interface tasks such as selecting from a set of elements, information elements selected from the domain model, and how the two should be grouped. The concrete UI specification deals with the actual interface elements such as the windows, buttons, checkboxes and navigation buttons. Based on figure 1, it is clear that the majority of model-based environments explicitly differentiate between task (process) models and data models.

The very great majority of business applications involve a database back-end with a front-end UI, and hence we utilize the extended entity relationship (EER) model to capture the data schema (Chen, 1976, Smith and Smith, 1977). Our methodology uses a set of rules to map EER objects automatically to provide a first cut user-interface, and then provides an opportunity for a structured dialog with the user to attempt to assuage some of the problems with the data-model-only approach.




Figure 1. Model-Based Interface Development Process (Szekely, 1996)


A Methodology to Derive a UI from an EER Schema


Before presenting the methodology, we list the concepts in the EER model that we will map. We base our list of concepts largely from standard database textbooks like (Korth et al., 2005) and assume an EER schema to consist of the following concepts:

-entity sets,

-relationship sets with 0/1 cardinality on at least one side, and any cardinality on the other,

-relationship sets with m:n cardinality and n-ary relationships

-attributes of entity and relationship sets,

-multi-valued attributes

-composite attributes

-entity subclasses that have extra attributes and/or extra relationships, with no multiple inheritance

-weak entity sets (existence dependencies) with a unique identifier


As summarized in (Szekely, 1996), an automatic interface generation algorithm should specify components at the following levels:

  1. P :presentation units (the different windows and a list of their contents)

  2. N: navigation between presentation units

  3. A: abstract interface items ( e.g., a drop down list, a check box, etc.)

  4. C: concrete interface items (how each abstract item will be implemented, such as a list-of-values for a drop-down list specification)

  5. L: window layout (position, font size, and other presentation criteria

Our methodology, described next, consists of two phases: the automated generation of the first-cut interface (FCI), followed

by the structured dialog with the human designer to generate the second-cut interface (SCI).

Generating the First Cut Interface (FCI)


The FCI consists of primitive screens that interact with the data, as well as provides for navigation between them. For convenience, we present our methodology for FCI generation in the following format. For each EER concept, we list the mapping to a relational schema and to the UI. We will not consider the C components of the mapping here, since C is system dependent (e.g., different UI systems will implement drop down lists differently). The L aspect is described in the end, since it contains common rules that apply to all the screens.

Entity Sets


Relational mapping: Create a table for the entity set. The columns of the table are the attributes of the strong entity set. The primary key of the table is the primary key of the entity set.

UI Mapping:

Presentation Units: Create a separate screen with all the attributes of the entity set. Additional buttons labeled CREATE, UPDATE, DELETE, RESET, EXIT are also created for the screen. These allow basic database access operations, as well as allow the user to exit the application.

Navigation: The screen gets links to the screens that correspond to every m:n relationship set in which the entity set participates, and to the screens that correspond to every multi-valued attribute of the entity set

Abstract Interface Items: -For enumerated type attributes, provide a fixed list of values.

-For attributes that are dates, currency, strings or numbers, provide a text box.

-For the primary key attribute(s), provide a non-updatable text box (grayed out) with a drop down list to search for existing rows in the table.

-For attributes that are Boolean, provide a check box

-Primary key fields should be in grey background and non-updateable


Relationship sets with 0/1 cardinality on at least one side, and any cardinality on the other


Relational mapping: Add a column(s) in the table that corresponds to the entity set that is on the “Any Cardinality” side. The column(s) we add here is the primary key of the entity set that is on the 0/1 side and any other attributes of the relationship set.

UI Mapping:

Presentation Units: Use already developed screens say, S1 for the entity set that corresponds to the “Any Cardinality” side, and S2 for the entity set that corresponds to the 0/1 side

Navigation: No additional navigation provided here

Abstract Interface Items:

-In S1, provide a drop-down list of values that show the primary key of the entity on the “Any Cardinality” side.

-Follow the same rules for other relationship attributes as described for entity sets.

-In S2, provide a view only drop down list for all entities on the “any cardinality” side that are linked to the entity which is displayed in all of S2.


Relationship sets with m:n cardinality and n-ary relationships


Relational mapping: Create a separate table for the relationship set. The columns of the table are the attributes of the relationship set (if any) + primary keys of all the entity sets that participate in the relationship set. The primary key of the table is = the primary keys of all the entity sets that participate in the relationship set.

UI Mapping:

Presentation Units: Create a separate screen with all the attributes of the relationship set, as well as the primary keys of all participant entity sets. Additional buttons labeled CREATE, UPDATE, DELETE, RESET, EXIT are also created for the screen. These allow basic database access operations, as well as allow the user to exit the application. If the relationship has no attributes then disable the UPDATE button.

Navigation: The screen gets links to the screens that correspond to every participant entity set

Abstract Interface Items: -For enumerated type attributes, provide a fixed list of values.

-For attributes that are dates, currency, strings or numbers, provide a text box.

-For the primary key attributes, provide a drop- down list of relevant values drawn from the participant entity sets

-For attributes that are Boolean, provide a check box

-Primary key fields should be non-updateable (grayed out) and drop down search. If no attributes other than primary keys, then no UPDATE button should be there.


Multi-valued attributes


Relational mapping: Create a separate table for the multi-valued attribute. The columns of the table are the primary key of the entity set to which the attribute belongs + a separate column for values of the attribute. The primary key of the table is all the columns of the table.

UI Mapping:

Presentation Units: Create a separate screen with the primary key of the entity set and the multi-valued attribute. Additional buttons labeled CREATE, DELETE, RESET, EXIT are also created for the screen. These allow basic database access operations, as well as allow the user to exit the application.

Navigation: The screen gets a link to the screen for the entity set that owns the multi-valued attribute.

Abstract Interface Items: -For enumerated type attributes, provide a fixed list of values.

-For attributes that are dates, currency, strings or numbers, provide a text box.

- For the primary key attributes of the owner entity set, provide a non-updatable text box (grayed out) with a drop down list to search for existing rows in the table.


Composite attributes


Relational mapping: No separate table is created for composite attributes. Only the leaf attributes are used when transferring to the relational schema. The only effect on the UI is at the L level, where attributes that belong to a composite hierarchy should be grouped together on the screen corresponding to that entity set or relationship set.


Entity subclasses that have extra attributes and/or extra relationships


Relational mapping: Create a separate table for the superclass first, using the rules for mapping entity sets we have seen earlier. For each subclass entity set, create a separate table. The columns of each table = the additional attributes of the corresponding subclass entity set + the primary key of the superclass entity set. The primary key of the subclass table is the primary key of the superclass table.


UI Mapping:

Presentation Units: Create a separate screen with all the extra attributes of the subclass, as well as the primary key of the superclass entity set. Additional buttons labeled CREATE, UPDATE, DELETE, RESET, EXIT are also created for the screen. These allow basic database access operations, as well as allow the user to exit the application.

Navigation: The screen gets a link to the screen that corresponds to the superclass entity set

Abstract Interface Items: -For enumerated type attributes, provide a fixed list of values.

-For attributes that are dates, currency, strings or numbers, provide a text box.

-For the primary key attributes, provide a drop- down list of relevant values drawn from the superclass entity sets

-For attributes that are Boolean, provide a check box


Weak entity sets (existence dependencies) with a unique identifier


Relational mapping: Create a separate table for the weak entity set. The columns of the table are the attributes of the weak entity set + the primary key of the corresponding strong entity set. The primary key of the table is the primary key of the corresponding strong entity set + the unique identifier of the weak entity set.

UI Mapping:

Presentation Units: Create a separate screen with all the attributes of the weak entity set, as well as the primary key of the strong entity set. Additional buttons labeled CREATE, UPDATE, DELETE, RESET, EXIT are also created for the screen. These allow basic database access operations, as well as allow the user to exit the application.

Navigation: The screen gets a link to the screen that corresponds to the strong entity set

Abstract Interface Items: -For enumerated type attributes, provide a fixed list of values.

-For attributes that are dates, currency, strings or numbers, provide a text box.

-For the primary key attributes, provide a drop- down list of relevant values drawn from the superclass entity sets as well as a non-updateable field for the unique identifier attributes of the weak entity set.

-For attributes that are Boolean, provide a check box


As shown above, the primitive screens in the FCI correspond to tables in the relational schema that is derived from the EER schema. Each screen provides write access to one table, and read access to multiple tables, as specified in the Presentation Units. Navigation is also provided to other primitive screens as specified above. Next we describe the Layout guidelines for the screens in the first cut interface, drawing on well known HCI principles.


Layout Guidelines for FCI Screens:

Basic layout principles that we utilize include the following:

  • Grouping like objects

  • Using familiar language

  • Using color

  • Consistency

  • Clearly marked Exits

  • Shortcuts

  • Easy reversal


These are summarized from classic works such as (Shneiderman, 1998, Nielsen, 1993). Next we describe definite guidelines for incorporating several of these concepts in the first cut interface.


Grouping like objects:

Grouping like objects is useful because it allows the user to create multiple-item chunks. This allows the users’ short term memory to manage more items on the screen than the usual 7 +/- 2 items. Grouping can be performed using line boundaries, or spatial proximity. This rule can be applied in many ways on the FCI screens. First, for each screen corresponding to an entity set, weak entity set, subclass and relationship set, the primary key fields used to identify objects in the table that the screen can write to, should be grouped together. Second, attributes that are intrinsic to an entity set or a relationship set should be grouped together. Third, primary keys that allow selection from other tables (as in the case of 1:n relationships) should be grouped together. Fourth primary keys that are view-only should be grouped together. Fifth, attributes that are part of the same composite hierarchy should be grouped together. Sixth, buttons providing database functionality such as CREATE, UPDATE and DELETE should be grouped together. The RESET button should be kept in its own group. Finally, the EXIT button should be kept separate from the others.

Using familiar language: One of the tenets of good data modeling is to use the language of the users in creating the names of objects and attributes. Since the primitive screens are based on the data schema, our methodology provides support for this HCI requirement.


Consistency: Using the FCI generation rules promotes consistency in look and feel. For each screen, the primary key of the table that it writes to should provide a drop down selection. All other primary keys from other tables that are read only from that screen should be select only, but should provide a GO button to be able to jump to the write screen for the corresponding table, so that particular record may be edited from its relevant screen. Buttons that perform the same tasks across screens should be in the same location, and have the same look and feel.

Clearly Marked Exits: This is useful to provide a feeling of user empowerment. Since the first cut interface screens all have clearly marked exits that allow us to exit the application, this HCI requirements is supported in our methodology.


AN ILLUSTRATIVE EXAMPLE of a First Cut INterface


Figure 2 depicts a simple EER schema, following standard diagramming conventions (Korth et al., 2005). Attributes are next to each entity and relationship set. Figure 3 illustrates the 4 screens in the FCI, generated using the AIG algorithm outlined above.



Figure 2. EER Schema for Application





Figure 3. The Four First Cut UI Screens from the EER Schema



After the first cut interface has been generated, using the guidelines described above, the primitive screens need to be augmented with a set of navigation screens as well as view only items specific to the application. This is described in brief next, because of space limitations. It will be presented in more detail at the conference.

Generating the Second Cut Interface


The motivation is to overcome some of the earlier disadvantages of AIG toolkits. This step is based on interaction from users, as well as the process diagram for the application. The steps in the SCI can be divided into the following categories:

-generation of menu screens that perform navigation to the primitive screens

-bundling of primitive screens into one window if access to more than one table is required for a business process

-removal of attributes from certain screens (e.g. salary from the employees screen)

-addition of specific view-only information that the employee needs to perform the data entry on a screen E.g., a summary for the sales of a particular customer for the last year can be useful view-only information when updating the customer_category field on the primitive screen corresponding to the customers entity set. customers screen).

-addition of graphic reports on certain primitive screens

-addition of intuitive identifiers such as customer_name for the customers primitive screen that allow for easier human searching in the drop down list for customers and add more intuitive identifiers such as name to the primary keys in the drop down lists. In order to simplify the human workload, we do not allow the addition of any updateable fields, the idea being that each screen provides at most one updateable table, though multiple readable tables. This is similar to the notion of updateable views in the database literature.


CONCLUSION


In this research in progress, we propose a methodology to infer a set of primitive screens from an EER schema, that serves as a foundation for a complete UI. The chief contribution of the methodology is that it focuses on database driven applications, and balances automatic generation of the UI with input from the designer in order to arrive at a final UI. We are testing our methodology with two applications, one of which is a teaching case that consists of approximately 12 tables, while the second is a real world application of approximately 25 tables. The EER diagram of the real world application is shown in Appendix 1. In both cases, students or end users familiar with the domain will be provided a user interface generated with the methodology described here and asked to evaluate the interface. Results will be presented at the conference.

As part of this work, we aim to extend the rules described here to incorporate higher level navigation screens, construct a compiler that automatically generates the first cut schema based on the rules described here, and test the methodology for large scale applications.

REFERENCES






  1. Chen, P. P. (1976) ACM Transactions on Database Systems, 1, 9-36.




  1. Jacob, R. J. K. (1986) ACM Transactions on Graphics, 5, 283-317.




  1. Korth, H., Silberschatz, A. and Sudarshan, S. (2005) Database Systems Concepts, McGraw Hill, New York.




  1. Myers, B., Hudson, S. E. and Pausch, R. (2000) ACM Transactions on Computer-Human Interaction, 7, 3-28.




  1. Nielsen, J. (1993) Usability Engineering, Academic Press.

  2. Olsen, D. R. (1986) ACM Transactions on Information Systems, 5, 318-344.




  1. Shneiderman, B. (1998) Designing the User Interface, Addison Wesley Longman.




  1. Smith, J. M. and Smith, D. C. P. (1977) ACM Transactions on Database Systems, 2, 105-133.




  1. Szekely, P. A. (1996) In Design, Specification and Verification of Interactive Systems: Proceedings of the Third International Eurographics Workshop (Eds, Bodart, F. and Vanderdonckt, J.) Namur, Belgium.





APPENDIX 1


EER Diagram of Real world Application for which a User Interface will be Generated and Tested





Proceedings of the 5th AIS SIGSAND Symposium on Research in System Analysis and Design, Tulsa, USA, May 12-13, 2007



Похожие:

Keywords user interface, data model, automatic generation, screens, graphical user interface introduction iconKeywords Metaphor; Reasoning; Creativity; Graphical interfaces; Interface user behaviour; Natural language interaction. Introduction

Keywords user interface, data model, automatic generation, screens, graphical user interface introduction iconXml in the User Interface Context

Keywords user interface, data model, automatic generation, screens, graphical user interface introduction iconCs 235: User Interface Design Fall 2010

Keywords user interface, data model, automatic generation, screens, graphical user interface introduction iconEncrypted Speech with a Familiar User-Interface Building a Secure Phone

Keywords user interface, data model, automatic generation, screens, graphical user interface introduction iconAbstract – The mathematical model of data transfer with the use of the pulse response on interface rs-485 is developed in the paper. It allows defining frequency transfer function of the cable used at construction of network segment, and the pulse response for each segment

Keywords user interface, data model, automatic generation, screens, graphical user interface introduction iconKeywords Synchronous collaboration, heterogeneous devices, software architecture, conceptual model, beach application model and framework, i-land, roomware components Introduction

Keywords user interface, data model, automatic generation, screens, graphical user interface introduction iconWMer ru Payment Interfaces: Receive Payment Interface and Send Payment Interface
Магазин или Продавец – Интернет сайт, являющийся клиентом Сервиса и желающий подключить платежные интерфейсы wmer ru
Keywords user interface, data model, automatic generation, screens, graphical user interface introduction iconComplexity, Genetic algorithm, Information criterion of fitness, Sample random generation, Graphical models, Contingency tables. 1 Introduction

Keywords user interface, data model, automatic generation, screens, graphical user interface introduction iconUser assumes all risks related to the use of any information provided in the qol bib or forms bank. Data available on all instruments are provided "as is"

Keywords user interface, data model, automatic generation, screens, graphical user interface introduction iconA2 Instructions to the first task used in the interface

Разместите кнопку на своём сайте:
Библиотека


База данных защищена авторским правом ©lib.znate.ru 2014
обратиться к администрации
Библиотека
Главная страница