SFDC 1020
`SFDC 1020
`
`
`
`
`
`
`
`
`
`

`
`24-29 April1993
`
`lNlfRcH1’93
`
`Generating User Interfaces from Data Models and
`Dialogue Net Specifications
`
`Christian Janssen, Anette Weisbecker,
`
`Jurgen Ziegler
`
`und Organisation
`fur Arbeitswirtschaft
`Fraunhofer-Institut
`Nobelstr. 12, D-7000 Stuttgart 80, Germany
`janssen@iao.fhg. de, weisbeck@iao.fhg.
`de, ziegler@iao.fhg.de
`
`email:
`
`ABSTRACT
`A method and a set of supporting tools have been developed
`for an improved
`integration
`of user interface
`design with
`software
`engineering methods
`and tools. Animated
`user
`interfaces
`for database-oriented
`applications
`are generated
`from an extended data model and a new graphical
`technique
`for specifying
`dialogues. Based on views defined
`for
`the
`data model,
`an expert
`system uses explicit
`design rules
`derived
`from existing
`guidelines
`for producing
`the static
`layout of
`the user
`interface. A petri net based technique
`called
`dialogue
`nets is used for specifying
`the dynamic
`behaviour. Output
`is generated for an existing user interface
`management
`system. The approach
`supports
`rapid proto-
`typing while
`using the advantages
`of standard software
`engineering methods.
`
`KEYWORDS:
`Specification,
`Systems.
`
`Interface Design, Dialogue
`User
`Automatic
`Dialogue Nets, User
`Interface Management
`
`INTRODUCTION
`advances have been made with
`In the last years, significant
`development
`tools
`like
`user
`respect
`to user
`interface
`interface
`builders
`and user interface management
`systems
`(UIMS).
`Compared
`to programming
`with user
`interface
`toolkits,
`these systems help a lot
`in designing
`and imple-
`menting graphical user interfaces [10].
`
`however,
`user interfaces,
`of graphical
`The development
`still a time-consuming
`activity. With the tools commercially
`available today, every user interface object has to be created
`and Iayed out explicitly.
`Dialogue
`control
`specifications
`have to be added by programming
`(using user
`interface
`builders)
`or via a specialized language (using user interface
`management
`systems), which may require a large effort and
`needs specific knowledge.
`
`is
`
`to follow
`is difficult
`it
`tools,
`available
`currently
`With
`existing
`user interface
`design guidelines
`and style guides
`like [16, 4, 12, 17] and to maintain
`consistency
`across the
`user interface as well as consistency with other applications.
`Particularly,
`little
`or no support
`is provided
`for selecting
`
`of
`
`is
`this material
`all or part
`fee
`without
`to copy
`Permission
`for
`or distributed
`are not made
`the copies
`granted
`provided
`that
`notice
`and tha
`direct
`commercial
`advantage,
`the ACM copyright
`title
`the publication
`and its date
`appear,
`and notice
`is given
`of
`that
`copying
`is by permission
`of
`the Association
`for Computing
`Machinery.
`To copy
`otherwise,
`or
`to republish,
`requires
`a fee
`and/or
`specific
`permission.
`
`01993
`
`ACM 0-89791-575-5/93/0004/041
`
`8...$1.50
`
`appropriate interaction
`
`objects for a specific task.
`
`part of an
`of the non-interactive
`Regarding the specification
`application
`which is typically
`done in the early phases of
`the design cycle, user interface tools cannot make use of the
`models developed with general
`software
`engineering me-
`thods and tools. This leads to extra effort
`and potential
`inconsistencies when moving from the requirements
`analy-
`sis to user interface design.
`It
`is therefore important
`to use
`analysis results like the data model as input
`for user inter-
`face development
`tools.
`
`in this paper addresses the problems
`The work described
`mentioned
`above. A method
`and supporting
`tools-the
`GENIUS tool environment
`(GENerator
`for user Interfaces
`Using Software ergonomic
`rules)—have
`keen developed for
`the automatic
`generation
`of user interfaces
`from extended
`data models and petri net based dialogue descriptions. Our
`approach is suitable for
`the generation
`of animated proto-
`types of database-oriented
`applications
`based on notations
`that are commonly
`used in general
`software
`engineering
`methods. After a discussion of related work, we will
`intro-
`duce the overall structure of
`the GENIUS environmen~
`and
`describe the generation
`of
`the static and dynamic
`parts of
`the user interface.
`
`RELATED WORK
`Automatic
`User
`Interface Generation
`in literature
`A number of research systems are documented
`from higher
`that automatically
`generate the user interface
`level specifications.
`Jade [23] and ITS [20] are generating
`presentational
`designs from frame-like
`dialogue
`specifica-
`tions. UofA*
`[15] and Mickey
`[11] are generating
`presen-
`tation and dialogue from a specification
`of
`the application
`commands, Within UIDE [5] combined with DON [91 a
`specification
`consisting
`of objects,
`attributes,
`attribute
`types, actions, parameters,
`preconditions,
`and postcondi-
`tions is used. Each of
`these systems introduces
`its own no-
`tation
`for
`the higher
`level
`user
`interface
`specification.
`(Mickey
`bases on Pascal code, but
`introduces
`a new nota-
`tion within comments.) However,
`the use of widely
`known
`notations is important
`for
`the acceptance of
`tools by system
`developers.
`
`data models is
`the first UIMSS which incorporates
`One of
`how to derive
`HIGGENS
`[7].
`In this system it
`is specified
`views
`from data models. The views,
`including
`data and
`methods
`for
`interacting
`with them,
`represent
`an abstract
`form of
`the display
`shown to the user. For each view the
`actual
`presentation
`on the physical
`device
`has to be
`
`418
`
`SFDC 1020
`
`

`
`IIIT{RCHI’93
`
`24-29 April1993
`
`for
`uses the data model
`defined. HIGGENS
`explicitly
`to our approach and most
`interface definition
`but
`in contrast
`of
`the systems mentioned
`above, doesn’t
`incorporate
`rules
`for the generation of the physical user interface. So, it offers
`less flexibility
`and power with respect
`to the selection and
`layout of interaction
`techniques.
`
`in dia-
`in and groups. Unlike
`grams which are combined
`logue nets,
`in statecharts one cannot open a state without
`leaving the current state. SUPERMAN
`diagrams
`[22] con-
`tain fork and join constructs,
`so that
`they can handle paral-
`lelism in principle,
`but
`lack a clear semantic
`concept
`in
`comparison
`to petri nets.
`
`[1]
`by de Baar, Foley and Mullet
`The system described
`generates dialogue
`boxes and menus from enhanced data
`models. By this approach, descriptions
`from data modeling
`can be reused for
`the user
`interface
`specification,
`and
`double effort and consistency problems are avoided, On the
`other hand,
`the approach described by de Baar et al. does
`not include a graphical dialogue specification
`technique.
`
`[13] Entity Rela-
`In the approach of Petoud and Pigneur
`tionship models (in textual
`form) are used for user interface
`generation. The dynamics are textually
`specified and can be
`visualized
`by a precedence
`graph. The graph, however
`cannot be modified
`nor substructure,
`so that
`the system is
`not likely to be suitable for bigger applications.
`
`user
`generating
`systems automatically
`existing
`Overall,
`into general soft-
`lack a proper
`integration
`interfaces either
`ware engineering methods, or an adequate way of defining
`the dynamics of the dialogue, or both.
`
`Graphical Dialogue Specification
`speci-
`dialogue
`There are many approaches
`for graphical
`[18]) are based
`fication. Some of
`them (e.g. USE diagrams,
`not suited for
`on state-transition
`diagrams
`and therefore
`input dialogues.
`graphical
`user interfaces with concurrent
`so that multiple
`Jacob [8] extends state transition
`diagrams
`parallel diagrams are used. However,
`the global
`relations of
`the concurrent
`dialogues
`cannot
`be visualized
`by this
`approach. Similarly,
`in statecharts [19] parallelism can be
`handeled, but
`there are no transitions
`between parallel dia-
`
`I
`
`UIMS Language
`
`1!
`
`environment.
`the GENIUS
`of
`1: Overview
`Figure
`based on the data model.
`Views
`are defined
`views
`are
`specified
`in
`Transitions
`between
`dialogue
`nets. A knowledge-based
`component
`generates the static user interfaces
`from the view
`definitions.
`As a target system, an existing UIMS
`is used. The dialogue nets as well are transformed
`into code for the UIMS.
`
`Pern nets have already been used in the context of dialogue
`specification
`and user interface management
`systems. Event
`graphs [14] can be used to describe the dynamic
`visibility
`of objects within
`a graphical-interactive
`application.
`Petri
`net objects [2] are more powerful
`since general object
`flow
`and object manipulation
`can be described. However,
`they
`are more complex
`than event graphs and less suited for the
`earlier design phases.
`
`is simi-
`The technique used in our approach, dialogue nets,
`lar
`to event graphs in modeling
`the dynamic
`visibility
`of
`objects needed for
`the coarse-grain
`dialogue
`specification.
`Compared with event graphs,
`they offer essential
`features
`like hierarchical
`dialogue structuring,
`and the declaration of
`modal dialogue windows.
`
`GENERATING USER INTERFACES IN THE GENIUS
`APPROACH
`1), Entity Relationship
`(figure
`approach
`In the GENIUS
`data models are used as the starting point
`for
`the specif-
`ication of
`the user interface. The Entity Relationship
`(ER)
`model
`[3]
`is a well established conceptual data model and is
`used in most of
`todays software-engineering
`methods [21]
`and computer-aided
`software engineering
`(CASE)
`tools.
`
`In the following
`components of
`
`sections we will
`the environment.
`
`describe
`
`the different
`
`of Views
`Definition
`The application
`data model does not describe the data nee-
`ded by the user for specific
`tasks and no partitioning
`of
`the
`data is shown with respect
`to single dialogue steps. In order
`to structure
`the information
`contained
`in the data model
`with respect
`to tasks of
`the user, views are defined. The
`generation of windows
`showing application
`data cannot be
`done directly
`from the ER model as the user may not want
`to see all attributes of an entity in a certain situation. Also,
`attributes
`of several
`entities
`and relationships
`may be
`needed in the same window. A view consists of a subset of
`entities,
`relationships,
`and attributes
`of
`the overall
`data
`model. Furthermore,
`views may be substructure,
`i.e. con-
`tain other views.
`
`a
`view definition,
`to enable an easy and powerful
`In order
`of extensions
`have been made to the ER data
`number
`model. For specifying
`logical groups of attributes,
`complex
`attributes are introduced. The grouping
`information
`is used
`in the user
`interface
`generation
`process
`for visualizing
`groups of related data. For
`reducing
`the complexity
`of
`the
`graphical
`representation
`of ER diagrams,
`a set of entities
`and relationships
`can be replaced by a single symbol and
`edited separately.
`
`types
`different
`two
`of
`functions
`Furthermore,
`associated to views. Data manipulation
`functions
`tinguished
`from navigation
`functions. Navigation
`
`can be
`are dis-
`functions
`
`419
`
`

`
`24-29 April1993
`
`i.e. define the
`call other views,
`dialogue
`structure which
`can
`also be represented by dialogue
`nets (see below). The functions
`and their properties
`are used in
`the generation process to create
`appropriate
`controls (e.g. menu
`items or pushbuttons).
`
`Because the entire information
`of
`needed for
`the generation
`application
`windows
`from
`views cannot be expressed in a
`graphical
`representation,
`it
`is
`necessary to supply additional
`textual descriptions.
`These are
`provided
`in so-called property
`sheets. Property
`sheets consist
`of
`two types of information:
`
`in-
`properties
`o Descriptive
`clude a name, and a short
`description.
`For attributes,
`properties
`like type,
`range
`of values,
`type of selection,
`and defaults are stored.
`
`INIERCHI’9
`
`=T *E
`
`40
`
`Pundo
`
`(ERDE). The view is a subset of
`in the ER Diagram Editor
`Figure 2: View definition
`- the overall data model and contains the related entities Customer and Order with their
`attributes. The attribute CAddress is complex
`.
`
`l
`
`in-
`Task oriented properties
`clude frequency and type of
`access, and priority
`for the task. Functions associated to
`the views can also be described as properties.
`
`the
`our methodology,
`supporting
`In the tool environment
`editor
`definition
`of views is done with a direct manipulation
`selects
`for ER models (figure 2). The application
`developer
`elements
`from the ER diagram.
`Property
`sheets can be
`PoPPd uP and edited directly. Thus, no programming
`skills
`are required for the definition
`of
`the views, and it is easy to
`involve
`non-programmers
`e.g. application
`experts
`and
`interface designers in this process.
`
`Interface Generation
`Base for User
`The Knowledge
`The views
`form a logical
`description
`of
`the application
`windows.
`This description
`is used as input
`for an expert
`system controlling
`the generation
`process. The knowledge
`base includes
`
`l
`
`l
`
`abstract
`
`interaction
`
`object
`
`types, and
`
`rules for selection and layout of
`
`interaction
`
`objects.
`
`to
`types contain attributes
`objecl
`interaction
`The abstracf
`specific data like name and range
`be filled with application
`of a data field as well as layout attributes
`like alignment,
`colour,
`and size. Depending
`on the target user
`interfaces
`and the available
`devices, different
`interaction
`objects may
`be defined.
`The standard
`interaction
`objects defined
`are
`windows,
`dialogue
`boxes, menus, entry
`fields,
`constant
`fields, exclusive
`choices, nonexclusive
`choices, operation
`choices,
`lists,
`and scrollbars.
`They
`are called
`abstract
`because they are independent
`of
`their
`physical
`imple-
`mentation, e.g. as OSF/Motif
`or Open Look widgets.
`
`the user interface are
`The design rules for the generation of
`derived from existing guidelines
`and style guides. Most of
`the rules concerning
`formats and arrangement of data fields
`and field prompts are derived from Smith and Mosier
`[16].
`Rules for
`the interaction
`object selection
`and layout have
`been extracted
`from the CUA [4], OSF/Motif
`[12] and
`Open Look [17] style guides.
`
`objects are
`interaction
`the abstract
`Some attribute values of
`give the designer
`the
`defined
`by dejiazdts. The defaults
`opportunity
`to influence
`the generation process and provide
`application
`or organizational
`preferences. They are stored
`outside the knowledge
`base in order
`to enable easier chan-
`ges by the designer without
`needing to access the expert
`system shell.
`
`Process
`The Generation
`is done in
`description
`of
`the user interface
`The generation
`three steps. In the first step, appropriate
`interaction
`objects
`for
`the information
`contained in a view are selected accor-
`ding to the information
`stored in the property
`sheets. For
`each view a window is generated. General
`layout atrnbutes
`of
`the windows
`like substructuring
`in status, application
`and information
`area are taken from the default values. The
`interaction
`objects
`for
`the data specified
`in a view are
`determined
`by values of
`the property
`sheets, mainly by the
`data type,
`range, and condition
`values. For example, a data
`field Condition
`(figure
`2) with enumerated
`values where
`only one selection is permitted
`is represented as an exclu-
`sive choice like set of
`radio buttons
`(figure
`3).
`If a large
`number of values is available
`for exclusive
`selection radio
`buttons are not appropriate
`and a list
`is used. For a function,
`its type, scope and frequency
`of use determine
`its presen-
`
`420
`
`

`
`INTERCHI’93
`INERIIHI '93
`
`24-29 April1993
`24—29 April 1993
`
`File
`Fils
`
`Edit
`Edit
`
`View
`view
`
`Options
`Opt ions
`
`HdP
`
`Customer
`customer
`Number:
`12456896
`LE5%x.1
`‘“”’”
`Nana:
`University Stuttgart
`Name:
`University
`Stuttgart
`
`Stre=t :
`Ci tu:
`
`Phone:
`
`Nobelstr. 12
`Nobel
`str.
`12
`7000 Stuttgart
`7000
`Stuttgart
`0711 / 970-0
`0711
`/
`970-0
`
`Conditions
`conditions
`0 1?! cash payment
`
`0 52 discount
`QSA
`discount
`<>10Z total anount>10000
`OIOX
`total
`amOunt>10000
`O 152 uni out-si tics
`915X
`univw-sities
`
`J
`
`I
`
`1
`
`Ship.-Date
`Ship.
`-Oate
`
`Total
`Total
`
`flnount
`t+mount
`
`Orders
`Orders
`Number
`Number
`
`b
`
`Figure
`3: Sample
`generated window
`from the view
`Figure 3: Sample generated window from the view
`definition in Figure 2.
`definition
`in Figure 2.
`
`tation as a menu item or as an operation choice such as a
`tationas
`a menu item or as anoperation
`choice such asa
`push button.
`push button.
`
`In the second step the attribute
`values
`for
`the selected
`In the second step the attribute values for the selected
`interaction objects are determined. Attributes which only
`interaction
`objects are determined.
`Attributes
`which only
`depend on the contents of the application (like text labels,
`depend on the contents of
`the application
`(like text
`labels,
`field length,
`format and default values) are copied from the
`field length, format and default values) are copied from the
`property sheets. A second type of attributes are obtained by
`property sheets. A second type of attributes are obtained by
`the default values which exist for each interaction object
`the default
`values which exist
`for each interaction
`object
`type. The third type of attributes, mainly the layout infor-
`type. The third type of attributes, mainly
`the layout
`infor-
`mation, depend on other interaction objects.
`mation, depend on other interaction
`objects,
`
`The layout is determined in the third and last step of the
`The layout
`is determined
`in the third and last step of
`the
`generation. Here, the arrangement inside complex elements
`generation. Here,
`the arrangement
`inside complex elements
`like groups is determined first. Afterwards the remaining
`like groups is determined
`first. Afterwards
`the remaining
`elements are arranged on the available screen space ac-
`elements are arranged on the available
`screen space ac-
`« cording to their priority or the given sequence.
`cording to their priority
`or the given sequence.
`
`The expert system delivers a user interface description
`The expert
`system delivers
`a user
`interface
`description
`which is then transformed in a specification interpreted by
`which is then transformed
`in a specification
`interpreted
`by
`the underlying UIMS (figure 3).
`the underlying UIMS (figure 3).
`
`The process of
`the automated user interface generation can
`The process of the automated user interface generation can
`be influenced in a number of ways. The simplest is
`be influenced
`in a number
`of ways. The simplest
`is
`modifying
`the default
`values of
`the interaction
`objects.
`In
`modifying the default values of the interaction objects. In
`addition, the interaction objects and the rules stored in the
`addition,
`the interaction
`objects and the rules stored in the
`knowledge
`base can be changed,
`It
`is also possible to have
`knowledge base can be changed. It is also possible to have
`various
`knowledge
`bases for
`the generation
`of different
`various knowledge bases for the generation of different
`types of user interfaces, e.g. alphanumeric
`and graphical.
`types of user interfaces, e.g. alphanumeric and graphical.
`
`SPECIFYING THE COARSE GRAIN DIALOGUE WITH
`SPECIFYING THE COARSE GRAIN DIALOGUE WITH
`DIALOGUE NETS
`DIALOGUE NETS
`For the construction of working prototypes which are to be
`For the construction
`of working prototypes which are to be
`evaluated with users, the rapid generation of static appli-
`evaluated with users,
`the rapid generation
`of static appli-
`cation windows described in the previous section is
`cation windows
`described
`in the previous
`section
`is
`necessary but not sufficient. Dialogue
`control
`information
`necessary but not sufficient. Dialogue control information
`has to be passed to the generation
`system so that
`the user
`has to be passed to the generation system so that the user
`interface can be animated.
`interface can be animated.
`
`Two
`levels
`of dialogue
`control
`are distinguished.
`The
`Two levels of dialogue control are distinguished. The
`coarse grain dialogue defines the sequencing of views
`coarse grain
`dialogue
`defines
`the sequencing
`of views
`(mapped to application windows) and the call of application
`(mapped to application windows)
`and the call of application
`functions as the result of user input. Thefine grain dialogue
`functions as the result of user input. Thefine
`grain dialogue
`defines state changes on the level of single user interface
`defines state changes on the level of single user interface
`objects. This includes the alteration of text values and
`objects. This includes
`the alteration
`of
`text values and
`changes in the sensitivity of menu items, for example.
`changes in the sensitivity
`of menu items,
`for example.
`
`For the construction of the first working prototype showing
`For the construction
`of
`the first working
`prototype
`showing
`the broad look-and-feel of an application, mainly the coarse
`the broad look-and-feel
`of an application, mainly the coarse
`grain
`dialogue
`is needed.
`Implementing
`the fine grain
`grain dialogue is needed. Implementing the fine grain
`dialogue leads to a complete user interface for the appli-
`dialogue
`leads to a complete
`user interface
`for
`the appli-
`cation system and is usually not specified graphically. Tex-
`cation system and is usually not specified graphically.
`Tex-
`tual specifications like those described in [6] are more
`tual specifications
`like those described
`in [6] are more
`suitable for the fine grain dialogue.
`suitable for the fine grain dialogue.
`
`In order to integrate the dialogue specifications in the
`In order
`to integrate
`the dialogue
`specifications
`in the
`methodology
`described so far,
`it
`is important
`that
`the tech-
`methodology described so far, it is important that the tech-
`nique uses the concepts of the view definition phase, and
`nique uses the concepts of
`the view definition
`phase, and
`offers a graphical representaion. Based on these require-
`offers a graphical
`representation. Based on these require-
`ments, a technique called dialogue nets has been developed.
`ments, a technique called dialogue nets has been developed.
`
`Basic Concepts of Dialogue Nets
`Basic Concepts
`of Dialogue Nets
`Like all petri nets, dialogue
`nets consist of places,
`trans-
`Like all petri nets, dialogue nets consist of places, trans-
`itions, and flow relations. In their current form, dialogue
`itions, and flow relations,
`In their current
`form, dialogue
`nets are elementary
`nets,
`i.e.
`they show the flow of un-
`nets are elementary nets, i.e. they show the flow of un-
`distinguishable tokens and places can only be marked with
`distinguishable
`tokens and places can only be marked with
`one token at a time.
`one token at a time.
`
`Views are associated to places in the net so that the marking
`Views me associated to places in the net so that
`the marking
`of a place with a token models the dynamic visibility of the
`of a place with a token models the dynamic
`visibility
`of the
`view. Dialogue steps are modeled by transitions. There are
`view. Dialogue
`steps are modeled by transitions. There are
`basically two types of transitions:
`basically two types of transitions:
`
`- Unspecified transitions only have a meaningful label.
`l Unspecified
`transitions
`only have a meaningful
`label.
`
`l
`
`- Fully specified transitions contain a condition and an
`Fully
`specified
`transitions
`contain a condition
`and an
`action. The condition typically contains an input event,
`action, The condition
`typically
`contains an input event,
`but can also include other events and additional condi-
`but can also include other events and additional
`condi-
`tions. The actions are mainly calls to application func-
`tions. The actions are mainly
`calls to application
`func-
`tions, but can also contain actions related to the user
`tions, but can also contain
`actions related to the user
`interface.
`interface.
`
`A transition can only be fired if the input places (linked
`A transition
`can only be fired if
`the input places (linked
`with the transition by an incoming flow relation) are
`with
`the transition
`by an incoming
`flow relation)
`are
`marked and the output places (outgoing flow relation) are
`marked and the output places (outgoing
`flow relation)
`are
`
`421
`421
`
`

`
`24-29 April1993
`24-29 April 1993
`
`INT*RCHI
`INERCHI '93
`
`
`
`Figure 4a: Dialogue net with unspecified transitions for
`Figure 4a: Dialogue
`net with unspecified
`transitions
`for
`the specification of the order dialogue.
`the specification
`of
`the order dialogue.
`
`pushbutton Order
`pressed
`
`Get Order Data
`
`Figure 4b: Fully specified Order transition showing a
`Figure
`4b: Fully
`specified Order
`transition
`showing
`a
`condition and action.
`condition
`and action.
`
`unmarked. Tokens are removed from the input places and
`unmarked. Tokens are removed
`from the input places and
`the output places are marked. Side places (two~direction
`the output places are marked, Side places (two-direction
`flow relation) must contain a token before a transition fires
`flow relation) must contain a token before a transition
`fires
`but are not changed. Additionally, a fully specified trans-
`but are not changed. Additionally,
`a fully
`specified
`trans-
`ition can only fire if the conditions are satisfied, and the
`ition can only fire if
`the conditions
`are satisfied,
`and the
`actions are executed when firing. A special transition, the
`actions are executed when firing. A special
`transition,
`the
`start transition (labeled Start) is fired at the beginning of
`wart
`transition
`(labeled Star?)
`is fired at
`the beginning
`of
`each dialogue.
`each dialogue.
`
`Figure 4a shows a dialogue net with unspecified transitions.
`Figure 4a shows a dialogue net with unspecified
`transitions.
`The Customer view is opened at the beginning. Via the
`The Customer
`view is opened at
`the beginning.
`Via the
`Order transition, the Order view can be opened showing
`Order
`transition,
`the Order
`view can be opened showing
`details of the selected order. Save can be executed at any
`details of
`the selected order. Save can be executed at any
`time. The Close transition ends up the Customer dialogue.
`time. The Close transition
`ends up the Customer dialogue.
`A fully specified Order transition (figure 4b) shows the
`A fully
`specified Order
`transition
`(figure
`4b) shows the
`condition and action for the transition.
`condition
`and action for the transition.
`
`Hierarchical Structurlng of Dialogue Nets
`Hierarchical
`Structuring
`of Dialogue Nets
`Real dialogues may contain numerous views which cannot
`Real dialogues may contain numerous views which cannot
`be shown in a single net. Therefore, a partitioning of the
`be shown in a single net. Therefore,
`a partitioning
`of
`the
`dialogue net is required. As a structuring mechanism, com-
`dialogue net is required. As a structuring mechanism,
`com-
`plex places are introduced (places with double border). A
`plex places are introduced
`(places with double border). A
`complex place is associated with a subdialogue shown in a
`complex place is associated with a subdialogue
`shown in a
`
`
`
`of the Customer dialogue
`refinement
`Figure 5: Hierarchical
`Figure 5: Hierarchical refinement of the Customer dialogue
`by a complex place and a subdialogue net.
`by a complex place and a subdialogue net.
`
`separate dialogue net. Consequently, complex places are not
`separate dialogue net. Consequently,
`complex places are not
`directly associated with views or windows. Subdialogue
`directly
`associated with views or windows.
`Subdialogue
`nets are started when the associated complex place is
`nets are started when
`the associated
`complex
`place is
`marked and can be ended by removing the token from the
`marked and can be ended by removing
`the token from the
`complex place, or by removing all tokens from the subdialo-
`complex place, or by removing all
`tokens from the subdialo-
`gue nets. In the example (figure 5) an extended Customer
`gue nets.
`In the example (figure
`5) an extended Customer
`dialogue is shown in a separate dialouge net.
`dialogue is shown in a separate dialouge net.
`
`Modal Views
`Modal Views
`As petri nets are able to model parallelism, several views in
`As petri nets are able to model parallelism,
`several views in
`a dialogue can be open at a time. In the examples in figures
`a dialogue can be open at a time,
`In the examples in figures
`4 and 5, the Customer view remains open when the Order
`4 and 5, the Customer
`view remains open when the Order
`transition opens the Order view. Even in parallel graphical
`transition
`opens the Order view. Even in parallel graphical
`user interfaces, however, modal views are needed. Modal
`user interfaces,
`however, modal views are needed. Modal
`views are modeled by modal places (graphically marked
`views are modeled by modal places
`(graphically
`marked
`with a bold border) in dialogue nets. If a modal place is
`with a bold border)
`in dialogue
`nets.
`If a modal place is
`marked, no transition in the entire dialogue can fire except
`marked, no transition
`in the entire dialogue can fire except
`for those having that modal place as input place. The Mes-
`for
`those having that modal place as input place. The il4es-
`sage view in figure 5 is an example of a modal view.
`sage view in figure 5 is an example of a modal view.
`
`There are some other features of dialogue nets like optional
`There are some other
`features of dialogue nets like optional
`flow relations for reducing the net complexity, multiple
`flow relations
`for
`reducing
`the net complexity,
`multiple
`ways of entering or exiting a subdialogue, and assigning
`ways of entering
`or exiting
`a subdialogue,
`and assigning
`subdialogues to transitions, that cannot be shown in the
`subdialogues
`to transitions,
`that cannot be shown in the
`scope of this paper.
`scope of this paper.
`
`Generating Executable Dialogues from Dialogue Nets
`Generating
`Executable Dialogues
`from Dialogue Nets
`For the animation of views in our method, it is mostly
`For
`the animation
`of views
`in our method,
`it
`is mostly
`sufficient to use unspecified transitions. For each view, a
`sufficient
`to use unspecified
`transitions.
`For each view, a
`place in a dialogue net is generated. For each function, a
`place in a dialogue
`net
`is generated. For each function,
`a
`transition is inserted into the net. So, the transitions in the
`transition
`is inserted into the net. So,
`the transitions
`in the
`dialogue net correspond to functions specified in the
`dialogue
`net correspond
`to functions
`specified
`in the
`property sheets of the views. The effect of the navigation
`property
`sheets of
`the views. The effect of
`the navigation
`functions, however, are more easily specified graphically
`functions,
`however,
`are more easily specified
`graphically
`through the creation of flow relations in dialogue nets,
`through
`the creation
`of
`flow relations
`in dialogue
`nets,
`which is supported in a graphical dialogue net editor in the
`which is supported in a graphical dialogue net editor
`in the
`GENIUS environment.
`GENIUS environment.
`
`From the dialogue net specification, executable rules are
`From the dialogue
`net specification,
`executable
`rules are
`generated for the underlying user interface management
`generated
`for
`the underlying
`user
`interface management
`system in two steps. First, the unspecified transitions are
`system in two steps. First,
`the unspecified
`transitions
`are
`converted to fully specified ones. For this purpose, infor-
`converted
`to fully
`specified
`ones. For
`this purpose,
`infor-
`mation from the generation process of the static user inter-
`mation from the generation process of
`the static user inter-
`face is used, because the controls generated may support
`face is used, because the controls
`generated may support
`specific event types, which determine the conditions in the
`specific event
`types, which determine
`the conditions
`in the
`fully specified transitions. In the second step, the dialogue
`fully
`specified transitions.
`In the second step,
`the dialogue
`net specification with fully specified transitions are con-
`net specification
`with fully
`specified
`transitions
`are con-
`verted to rules of the underlying UIMS.
`verted to rules of
`the underlying UIMS.
`CONCLUSIONS
`CONCLUSIONS
`Our approach facilitates the generation of executable user
`Our approach facilitates
`the generation
`of executable user
`interfaces for database-oriented applications from a level of
`interfaces for database-oriented
`applications
`from a level of
`specification which is higher than the ones in use with
`specification
`which
`is higher
`than the ones in use with
`today ‘s user interface development tools. Also, the graphi-
`today’s user interface development
`tools. Also,
`the graphi-
`cal notations are more familiar to software developers. The
`cal notations are more familiar
`to software developers. The
`GENIUS approach offers a much better integration of the
`GENIUS approach offers a much better
`integration
`of
`the
`user interface development with general software-enginee-
`user interface development with general software-enginee-
`ring methods. Double specification
`is avoided by using the
`ring methods. Double specification is avoided by using the
`data model as a basis for the definition of the user interface.
`data model as a basis for the definition
`of
`the user interface.
`The specification of the dynamics is much easier with the
`The specification
`of
`the dynamics
`is much easier with the
`graphical dialogue net representation than with a textual
`graphical
`dialogue
`net
`representation
`than with a textual
`language. Dialogue
`nets are suitable
`for describing
`the
`language. Dialogue nets are suitable for describing the
`
`422
`422
`
`
`
`

`
`INTIRCHI’!13
`
`24-29 April1993
`
`coarse-grain
`interfaces.
`
`level of parallel
`
`dialogues
`
`in graphical
`
`user
`
`9.
`
`and
`the selection
`concerning
`of guidelines
`The support
`layout of
`interaction
`objects and the use of global default
`values for
`relev