Dynamic Dialog Management

Wolfram Clauss, Jana Lewerenz, and Bernhard Thalheim
BTU Cottbus, Computer Science Department
{clauss, jl, thalheim}@informatik.tu-cottbus.de
October 1997

Abstract

The relationship between global database schema and local views is widely accepted as well understood. Characteristics of this relationship may also be transferred to the dynamic component of databases: the global behavior and its local representations (dialogs). This comparison is supported by a category-theoretic framework. Furthermore, we use the mutual dependencies that become apparent in this context to suggest an approach to the design of dialogs as a means of communication with the user in an integrated form that allows for design facilitation as well as flexible and adaptive dialog management.

1 Motivation

An integrated system design promises to significantly improve the productivity of the development process as well as the maintainability of the application system. Especially the design of user interfaces has mostly been proposed as a separated activity [4, 5]. The integration of dialog behavior into database application design has only recently been addressed [1, 3, 11].

The discrepancy, however, between the well-based techniques and theories for structural database design on the one hand and the missing theoretical foundations of the corresponding behavior design on the other hand led us to ask the question which fundamental differences actually exist between structure design and behavior design. We found that many perceptions on structural design can indeed be transferred to behavioral design. We want to further develop this point of view in the following position paper.

Our starting point is to intuitively apply characteristics of the relation between database schema and database views to the behavior component. The overall system behavior, corresponding to the global database schema, can be projected on particular local behavior `views' that we want to refer to as dialogs in the following.

After illustrating the general dependencies between (database) schema, (database) views, behavior and dialogs from such an intuitive point of view, we want to present a theoretical framework for transferring meta-characteristics of the schema/views relation to the behavior/dialogs relation. We then will expose an approach to the practical consequences, especially for the design and management of dialogs.

2 Perspectives on Database Design

There are four sides to database design: whereas schema definition and views characterize the system's statics, behavior and dialogs capture its dynamics. On the other hand do schema and behavior convey the aspect of globality, while views and dialogs represent local realizations.

2.1 Statics

A schema can be understood as a type definition (or as a collection of static integrity constraints) and determines possible database instantiations. The database schema and its instantiations capture the global view on a database's statics.

The application of view definitions to any of such instantiations creates database views (view instances) that locally present specific instantiation parts to the user. Views may also be defined over views, thus building more complex combinations of parts of the underlying instantaneous database.

2.2 Dynamics

The definition of all possible functionality within a database system (or the collection of all dynamic integrity constraints) is the system's behavior. Those functions actually being performed then represent an instantiation of this behavior. In correspondence to the (static) database schema and database instantiations, this part of a system's dynamics stands for the global aspect.

In order to support certain activities, however, parts of this global behavior have to be selected and structured which is achieved by dialog definitions. The specific execution and `staging' of dialog definitions are the eventual dialogs (dialog instances) that serve as a local representation of the system's behavior in a specific context to the user. Again, dialogs can be defined over dialogs which corresponds to the definition of dialog flows as illustrations of underlying business processes.

Finally, it has to be pointed out that the specification of a system's dynamics necessarily includes its statics just as, e.g., function specifications incorporate information on input and output parameters since dynamic integrity includes static integrity (see section 3).

2.3 Consequences on the system's dynamics

The approach outlined above offers a convenient means for supporting the design of behavioral database aspects. On the one hand, it is obvious that global behavior can and should be developed in cooperation with the schema design. What is even more important, however, is the possibility to find methodical approaches to dialog design similar to the relationship of views to schema and additionally intertwined with global behavior (see sections 4 and 5).

It was already explained that dialogs can be understood as views on the global behavior which in turn incorporates static information. They are also related to (static) database views in that actual (`staged') dialogs incorporate view instances as structural reference. (For an illustration and comparison of the characteristics of the structural and the behavioral component, see figure 1.) Thus, dialog definitions are based on and regulated by the behavior definition and inherent static definitions; their specific instantiation, though, depends not only on the current behavior instance but also on the current view instances, i.e., the working context.

This bears the following consequences:


Figure 1. Transferring structural characteristics to behavior.

3 Theoretical Model

What was illustrated from a rather intuitive point of view in section 2 is now supplied with a theoretical framework. A category-theoretic approach backs our notion of dynamic specifications containing static definitions and also provides a means for formally capturing the relationship between global definitions on the one hand and local definitions on the other hand.

3.1 Outline of the framework

State automata are a standard means for the modeling of system behavior. We have found that this model nicely integrates schema, views, behavior and dialogs of a database application on the basis of a category-theoretic interpretation. In addition, we point to the corresponding denotational semantics of interactive systems.

3.2 Global definitions as automata

We interpret the schema as definition of a set of possible database instances (states) and the behavior of the database system as definition of a set of possible update operations transforming one instance into another (transitions). Taking the states as objects and the transitions as morphisms, the addition of a concatenation of transformations (including the `empty' concatenation) extends the state automaton to a category. Given a particular database definition, let this category be D.

3.3 Local definitions as functors

In general, a view is a function that maps the instances of the conceptual schema to some external schema. Thus, a view f on D is a function mapping D to some other category C. The definition of views over views is simply the concatenation of such functions.

An abstract dialog F based on the view f is a functor that extends f with the transformation of morphisms. This model satisfies the condition that static integrity is a subset of dynamic integrity. We can use this relationship to infer the complete underlying view from a given dialog specification or to automatically create a generic dialog from a given view specification. In correspondence to views, we are also able to easily define dialogs over dialogs, which appears useful for the modularization of interactive database applications.

3.4 Semantics

The formal semantics of a database specification consists of two functions: [ · ]S and [ · ]B for schema and behavior, respectively. [ · ]S maps the syntax of schema definitions to UN, the set of all countable subsets of a (probably but not necessarily) countable universe U. (We ignore here that depending on the existence of general recursion in A (the set of user actions), it might be necessary to use different structures than sets as semantic domains.) [ · ]B, given a specific schema definition S and a countable set of user actions A (e.g., a query language supplied to the user), maps the syntax of behavior specifications to ([S]S[S]S)A.

The model semantics further underlines the relationship of dialog behavior to the other aspects of application design. We previously defined a view f to be a function from D, the instance category of a given schema, to another category C. If the semantics of a schema is a countable set, however, f cannot be a schema -- opposing our interest in defining views over views. This problem does not occur if we split views into the view translation function, f, and the view schema, the codomain cod(f) of the view translation (see figure 1). A corresponding argument applies to dialogs, which are split into dialog translations and dialog definitions.

The formal split of view schema and view translation is a powerful tool. We are now able to formally capture the consequences of local and global schemas on their respective dynamic counterparts. What is more, we can also embed these structures into the behavior definition and, therefore, have computable design obligations for necessary behavior and dialog modifications.

4 Consequences on the Integration of Design Perspectives

The various interrelationships between design perspectives as introduced in section 2 and theoretically backed in section 3 influence the design process in that the mutual dependencies have to be satisfied on the one hand and can also be exploited for design facilitation on the other hand. An approach that would be able to satisfy these demands is the Structure-Process Codesign approach presented in [2].

4.1 Mutual dependencies within one level of locality

In section 3 it was pointed out that a system's dynamics are based on its statics. Thus, either side has to consider design decisions made on the respective counterpart: Behavior and dialog definitions are dependent on schema and views, respectively, and the static perspective, on the other hand, has to be adopted to suit behavioral requirements.

Any changes that then occur in the statics may need to find their correspondence in modified dynamics, i.e., a change of input (schema) type and/or output (schema) type may demand a redefinition of the transition in between. In the same way, dialogs have to adopt their internal processing to the underlying views. Finally, any modifications of transitions may demand changes of the types concerned.

Such dependencies relating only to one level of locality, i.e., to one category (see section 3), can be regarded as simple insertion or deletion of states and/or transitions within an automaton the implications of which are well-understood [10, 12]. An example data model for consistent schema transformation and its formal semantics has been proposed in [7].

4.2 Mutual dependencies between different levels of locality

When using translations between different levels of locality, say C and C', however, the consequences are somewhat more interesting. In addition to modifications within the same level of locality (in C), it may be necessary

Thus, it is, e.g., possible for view translations to change after modifications of the global schema to still produce the same outward effect as well as for the view definition to change in order to suit the modified schema.


Figure 2. The abstraction layer model of the database design process.

4.3 New design approaches

For the design of database applications this implies that design decisions or design modifications in any component have an influence on other components as well. These decisions or modifications and their resulting design obligations require a classification that also includes measures for the plausibility and the necessity of following steps considering the situational context (see figure 2). Such a classification, besides the fact that it encourages completeness and consistency of design, also has the advantage that it facilitates the design process as, firstly, the checking for potential obligations and even some modifications themselves may be performed automatically and, secondly, the design process can be adapted to the user's and the situation's requirements.

5 Design and Management of Dialogs

We previously pointed out that a system's dynamics depend on its statics and that global definitions and local representations are also interrelated. In particular dialog specifications are influenced by global behavior definitions as well as the underlying view schemas.

The position that dialogs thus take amongst the design perspectives introduced in section 2 already suggest their use within a database application. Just as dialog design cooperates with view design and behavior design, dialogs also depend on views and global behavior in their eventual managing. The consequences stemming from this point of view are explained and illustrated in the following.

5.1 Dialogs and their intention

Dialogs as a local presentation of the system's behavior can naturally be regarded as a means of communication with the user. Through dialogs users can be supplied with functionality (parts of the global behavior) as well as data (view instances). Additionally, dialog hierarchies and dialog sequences structure the specific behavior in a way that allows for the support of business workflows.

In order to be accepted by the users as an efficient tool in solving their tasks, dialogs have to be motivating, intuitively usable and adaptive to tasks as well as to users [9].

5.2 Dialog design

For the design of dialogs, an integrated approach was already suggested as being most appropriate. From the dialogs' point of view this means that their development is highly influenced by and permanently adjusted to the underlying views and the global behavior definitions. Moreover, the dialog design itself can also impose obligations to the design of other components.

Above all, views and global behavior play a role as dialog content. This refers to data and functionality made available in an individual dialog step. In other words, through the specification of behavior `views' and the usage of database views as structural reference dialogs combine these two aspects into a representation specification for the user. (The pure dialog content is complemented by specifications concerning the eventual dialog appearance and the sequencing of individual dialog steps as further illustrated in [9].)

The results of such an integrated design approach will be

Finally, during re-design phases modifications in dialog appearance as well as in internal dialog processing can be achieved with less effort as they may be retraced to underlying components.

5.3 Dialog management

We avoid to `hard-code' dialogs that would have to consider every possible situation and context. Rather we rely on the use of dialog definitions and dialog translations that allow for generic dialogs (see section 3) the realization of which is based on the underlying views and on the current behavior instance and thus can be sensitive to the execution context. (This problem was also recognized in [6].) On the other hand we have the means of additional specifications of appearance and dialog sequencing as mentioned above that can also take specifics of the performing actor and the task on hand into account.

As a consequence of this approach the application system is supplied with a set of specifications that concern different dialog aspects like dialog content (views and global behavior), dialog appearance (layout specification) and dialog flow (sequencing of individual dialog steps). These can be combined according to the respective situational requirements and allow, therefore, for a dynamic and adaptive dialog behavior.

References

[1] Hans-Jorg Bullinger, Klaus-Dieter Fahnrich, Christian Janssen: Ein Beschreibungskonzept fur Dialogablaufe bei graphischen Benutzungsschnittstellen. Informatik Forschung und Entwicklung 2/1996.

[2] Wolfram Clauss, Bernhard Thalheim: Abstraction Layered Structure-Process Codesign. To appear in: Proc. of COMAD'97. Chennai (Madras), India, 1997.

[3] R. C. H. Connor, Q. I. Cutts, G. N. C. Kirby, V. S. Moore, R. Morrison: Unifying Interaction with Persistent Data and Program. In: Pete Sawyer (ed.): Interfaces to Database Systems. Proc. of IDS94. Springer, Berlin, 1994.

[4] Kevin Cox, David Walker: User Interface Design. 2nd Edition. Prentice Hall, New York, 1993.

[5] Ray E. Eberts: User Interface Design. Prentice Hall, Englewood Cliffs, 1994.

[6] Christian Janssen, Anette Weisbecker, Jurgen Ziegler: Generierung graphischer Benutzungs-schnittstellen aus Datenmodellen und Dialognetz-Spezifikationen. In: Heinz Zullighofen (ed.): Proc. of Requirements Engineering '93: Prototyping. Teubner, Berlin, 1993.

[7] Anthony Kosky, Susan B. Davidson, Peter Buneman: Semantics of Database Transformations. Technical Report MS-CIS-96-05, University of Pennsylvania, 1996.

[8] Jan van Leeuwen (ed.): Handbook of Theoretical Computer Science. Elsevier, Amsterdam, 1990.

[9] Jana Lewerenz: Dialogs as interfaces for distributed database application systems. In: Proc. of the Workshop of the Graduate School of Distributed Information Systems. Wulkow, October 1997.

[10] Dominique Perrin: Finite Automata. In: Jan van Leeuwen (ed.) [8].

[11] Bettina Schewe: Kooperative Softwareentwicklung. Ein objektorientierter Ansatz. Deutscher Universitatsverlag, Wiesbaden, 1996.

[12] Wolfgang Thomas: Automata on Infinite Objects. In: Jan van Leeuwen (ed.), [8].

Copyright © 1997, ER'97, Wolfram Clauss, Jana Lewerenz, and Bernhard Thalheim. All rights reserved.