Dialogs and Interaction Schema: Characterizing the ... - CiteSeerX

Dialogs and Interaction Schema: Characterizing the Interaction Space of Information Systems Srinath Srinivasa1 Bernhard Thalheim Brandenburgische Technische Universit¨at Postfach 101344, D-03013 Cottbus Germany fsrinath,[email protected]

Contents 1. Introduction

2

2 Algorithmic Behavior vs Interactive Behavior 2.1 Turing Machines vs Interaction Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Categories and Coalgebras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 3 5

3 Characterizing an Interaction Space 6 3.1 Dialogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 Dialog Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4 Category Theoretic Formalisms for Dialogs

11

5 Related Work 12 5.1 Comparison with UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2 Other Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6 Conclusions

13

1 This research was supported by the German Research Society, Berlin-Brandenburg Graduate School in Distributed Information Systems (DFG grant no. GRK 316). 1

Abstract Information systems design concern modeling systems that are dynamic in nature. A dynamic system essentially has two dimensions of concern – static structure and dynamic behavior. The existence of dynamics – or interactions among parts of the system distinguish a dynamic system from a heap or collection of parts. Specification and management of the static aspects of an information system like the data and metadata have been fairly well addressed by existing paradigms. However an understanding of the dynamic nature of information systems is still low. Currently most paradigms model behavioral properties above an existing structural model, resulting in what may be called “entity centric” modeling. Such a kind of modeling would neglect properties that can be attributed to behavioral processes themselves, and relationships that might exist among such processes. In this paper, we address behavioral modeling by first considering system behavior to be in the form of an abstract “interaction space,” that depicts the domain of information system behavior. A new paradigm called “dialogs” is also proposed, which depicts semantic interactive processes existing in the interaction space; and an “interaction schema” as a characterization of the interaction space. Keywords: Information System, Interaction Space, Interaction Schema, Interaction Machines, Dialogs

1. Introduction Design processes for information systems need to address issues of modeling dynamic systems. A dynamic system is characterized fundamentally by two dimensions of concern – the static structure and dynamic behavior. The structural elements of a dynamic system are those elements which may be identified from static snapshots of the system domain; while the dynamic aspects involve those semantic elements of the system that exist over the time domain. There are a number of approaches towards modeling dynamic systems and to represent structure and behavior. Presently, in the object-oriented domain, UML [22] is a well accepted standard. A characteristic of UML and related modeling techniques is that the modeling is “entity centric” in nature. In this, domain entities or objects, form the building blocks of the model; and dynamics are represented as interaction processes on top of the domain entities. However, a shortcoming with such an approach is that behavioral aspects of the information system gets inadequate treatment. During the life cycle of an information system, a number of situations arise which cannot be accurately foreseen. Incorporating these changes might affect the behavioral aspects as much as they affect structural aspects of the information system. An “entity centric” approach would be inadequate in capturing changes that affect behavioral properties. In addition, behavioral processes inside an information system often influence the functioning of one another, which do not get captured by entity centric modeling. In our work, we approach system modeling by first dividing a dynamic system into two abstract “spaces” or domains of concern – the static or entity space, and the dynamic or interaction space. The entity space is the domain that contains the classes of all entities (we call them “domain objects” in order to be explicit) that are part of the static system structure, and the interaction space is the domain that contains classes of all dynamic interaction processes that are part of the information system. A characterization of an abstract space is called a schema. The system model hence consists of two schemata – an entity schema that characterizes the entity space and an interaction schema that characterizes an interaction space. In [20], we argue that a separate notion of interaction space distinct from the entity space for information systems is important for ameliorating their maintainability. In current modeling techniques, we occassionally encounter non-intuitive classes as part of the system model. (For example, a class called “Command” in GUI design; a class called “Event” in designing discrete event simulation, etc.) Such non-intuitive classes are often touted as “great” classes which form the key to reducing the complexity in modeling. However, with a notion of entity and interaction spaces; we can recognize that almost always such non-intuitive classes represent abstractions of interaction processes among domain objects. That is, they are classes that are part of the interaction space. Hence an explicit characterization of the interaction space, would not only capture how dynamics affect the functioning of domain objects, but also how different interaction processes affect one another. An overall framework of our approach is as depicted in Figure 1. The abstract space of concern of a dynamic system may be divided into – an “entity” space consisting of structural properties, and an “interaction” space consisting of behavioral properties. The focus of the work is upon developing paradigms for characterizing the interaction space of an information system. This task is further divided into two streams – analysis and design. In analysis, the task is to discern properties of a given dynamic system that manifest due to the interactions that take place in the system (emergent properties of dynamic systems). Some approaches towards this end are proposed in [21] and [19]. The design aspect is concerned with developing 2

System space

Interaction space

Entity space

Analysis

Design

Identification of properties that arise due to interactions

Characterizing an Interaction Schema for the Information System

Figure 1. Overview of the research framework paradigms that may be used for building interaction schemata. This paper addresses the design aspect in more detail. Rather than proceeding analogous to an existing paradigm (like say, object-orientation), we proceed by first examining properties of interaction spaces from a theoretical standpoint and develop paradigms accordingly. The resulting paradigm is a notion called “dialogs” which represent interaction processes as first order objects. Although a dialog may be implemented with the traditional notion of an object, it is distinguished by its signature elements from objects of conventional object orientation. The rest of the paper is organized as follows – Section 2 addresses the concept of an interaction space from a philosophical viewpoint. An interaction space represents an “open” space that consists of multiple interaction processes existing in a system that itself interacts with its environment over multiple interfaces. Recent notions like “Interaction Machines” [23], [24], [25] show that an “open” interaction space cannot be reduced to a “closed” space of an algorithmic computation. An open interaction space is represented by a Multi-stream Interaction Machine (MIM) rather than a Turing Machine (TM) that represents computable functions. Section 3 introduces our approach to characterize an interaction space, by introducing paradigms called “dialogs” and “dialog associations” that represent single stream and multi stream interactive processes respectively. Section 4 illustrates formal underpinnings for dialogs and dialog associations using category theory. Section 5 addresses related literature, and Section 6 concludes the paper.

2 Algorithmic Behavior vs Interactive Behavior This section addresses the notion of an “interaction space” of an information system. Historically the notion of problem solving has been represented as mathematical functions that map problem states to solution states. The space of functions that characterizes such mappings are called computable functions, represented by algorithms. However, computability represents a domain that extends beyond closed functions that map input states to output states. When problem solving is interactive in nature; and/or when interactions take place over multiple streams; the resultant abstract space can no longer be reduced to closed mathematical functions. This section introduces related concepts that address this issue and which form the underpinnings for the proposed model.

2.1 Turing Machines vs Interaction Machines Recent approaches towards formalizing interactive behavior have shown that interactive problem solving cannot be modeled by the traditional notion of algorithms. The main concepts in this regard are illustrated here. The notion of algorithmic problem solving is expressed by the concept of a Turing Machine (TM) (cf. [8]). Definition: A Turing Machine TM is a tuple TM = (S; ; ; s0 ; P ) where S is the set of TM states,  is a set of the tape symbols, s0 2 S is the starting state, P  S is the set of halting states, and  is a transition relation  : S   ! S    fL; Rg; where L corresponds to moving the tape one position to the left, and R corresponds to moving the tape one position to the right.

3

TMs begin computation at state s0 , and at each computational step map the current input symbol x 2  to an output symbol y 2 , and moves one step to the left or right on the input tape. In addition, the internal state of the TM is altered by each computation step. The TM halts when it reaches any halting state p 2 P . The problem solving process is characterized by the transition from an initial problem state or the initial state s0 to a halting state p 2 P . The problem solving process is hence a mapping (s0 ; i) ! (p; o) where i 2  is the input string of tape symbols, and o 2  is the output produced by the TM. In the above definition, it can be noted that the set of input symbols provided by the tape cannot be altered by the environment once the TM computation has begun. In other words, TMs characterizing the notion of algorithmic problem solving represents a non interactive notion of problem solving [24]. TMs depict a model for algorithmic computation or mathematical functions which can be characterized by a mechanical translation from a given problem state to a solution state. Real world applications however, are seldom described by initial problem states that contain all information necessary for problem solving. They normally involve problem solving processes which are interactive in nature. An interactive problem solving process involves one or more exchanges of information between the information system and the environment as part of problem solving. Interactive problem solving can be represented by a stream of mappings of the form (sk ; ik ) ! (sk+1 ; ok ); (sk+1 ; ik+1 ) ! (sk+2 ; ok+1 ); : : :, where output ok can influence the next input from the environment ik+1 . An interactive problem solving process involving k interactions is hence characterized by the transition from the initial state s0 to the final state sk , reached after the k interactions. In order to illustrate the differences between interactive and non interactive problem solving processes in a formal manner, we first need to define a “problem solving process” (PSP) and contrast an interactive PSP from a non interactive PSP.

h

i

Definition: A problem solving process (PSP), is defined as a a tuple, PSP = S; I; O;  , where S is a set of states of a domain of concern, I is a domain depicting the input set of parameters provided for the PSP, O is a domain depicting the output that can be produced S O, that changes the state of the domain of concern from a “problem state” by the PSP, and  is a mapping of the form  : S I p S , to a “solution state” s S , given an input i I , and producing an output o O.

2

2

 !  2

2

Definition: A “closed” PSP or an algorithmic PSP is defined as a PSP, where the path from p to s that characterizes the mapping  , may be recursively determined given the initial conditions – p and i. That is, there exists an algorithmic process TM , which can implement . Definition: An “open” PSP or an interactive PSP is defined as IPSP = hS; I; O; ; E i, where S; I and O are as defined for PSP and E is the environment in which the PSP functions. The mapping  from p to s of IPSP is defined as a stream of the form (p1 ; i1 ) ! (p2 ; o1 ); (p2 ; i2 ) ! (p3 ; o2 ); : : : ; (pk ; ik ) ! (s; ok ), where any ik = E (ok?1 ) is the input provided by the environment after k interactions and after k ? 1 intermediate outputs have been produced by the PSP.

The question now would be whether the mapping  from p to s of an IPSP is representable by an algorithmic process TM . That is, whether the outcome of an interactive process be determined by an algorithm, given the initial conditions. It

can be seen that, for a finite algorithmic specification to exist, the set of all inputs that could be provided by the environment

E at any stage in the interactive process, should be representable by a finite set of specifications. This is explained in a more

formal fashion below by first introducing the notion of a “solution space” of a PSP.

h

i

h

i

2

Definition: The solution space of a given PSP = S; I; O;  (or IPSP = S; I; O; ; E ) is the set of all states si S (inclusive of starting and ending states) that are visited by PSP starting from when computation begins till the end of computation, as part of the problem solving process.

The solution space of a PSP is represented as a set SP SP , which contains all states that are visited by the PSP for all inputs. In the case of an algorithmic PSP, the elements of the set SP SP are recursively enumerable, given the mapping  and the set of all input strings. For an interactive PSP, if the inputs that could be provided by the environment are recursively enumerable from a finite set of specifications, then  may be defined for each input and each interaction, making the solution space, a recursively enumerable set. However, if the inputs that may be provided by E cannot be enumerated by a finite set of specifications, then  cannot be defined by a finite set of specifications as well. Hence, the question of whether an interactive PSP can be represented by an algorithm would depend on whether the behavior of the environment can be represented by an algorithm.

4

Prasse and Rittgen [17] address the above problem and argue that interaction represents a different domain than algorithmic problem solving – although within the domain of computable functions. In other words, the domain represented by algorithms (shown to be equivalent to recursively enumerable sets and inductive algebras) do not represent the complete domain of computable functions. The intersection between interactive and algorithmic functions (interactive functions which can be represented algorithmically), are said to be partial recursive functions. The differences between algorithmic and interactive PSPs go deeper than the above. For instance, an interactive PSP which interacts with multiple interaction streams – characterized by IPSP = hS; I; O; ; E1 ; E2 ; : : : ; En i – cannot be reduced to one which interacts with a single interaction stream [25]. However, this aspect does not directly affect interaction schema design, as illustrated later in this paper. For the problem of designing an interaction schema, the fact that an interactive solution space cannot be comprehensively described by algorithms affects further design decisions.

2.2 Categories and Coalgebras While the paradigm of Interaction Machines stretch the notion of problem solving from purely algorithmic computation to include interaction as well, it can be seen that interaction, as a process in itself has already been addressed in many different ways. For example, an interactive mapping of the form (p1 ; i1 ) ! (p2 ; o1 ); (p2 ; i2 ) ! (p3 ; o2 ); : : : can be represented as a state machine that transforms an input string to an output string. Similarly, literature on reactive systems, have addressed systems that maintain an ongoing interaction with their environment [13]. However, in order to understand the nature of an interaction space – or the dynamic behavior of an information system, it is important to bring together the concepts of interactive problem solving and representation of interactive processes. An interaction space consists of many interactive PSPs, which could be either sequential or interleaved in space and time. The functioning of one PSP might affect the functioning of an other PSP and PSPs may need to be added, modified or deleted from the interaction space. A suitable mathematical formalism is hence needed for representing and managing PSPs in an interaction space. Category theory and the associated theory of coalgebras [9], [10], provide a framework of formal underpinnings for representing and manipulating dynamic systems. Some fundamental concepts from category theory which are used later in developing the proposed model, are introduced below. Definition: A category K is a collection of “objects” obj (K ) and “morphisms” mor(K ), such that – 1. Each morphism f has a “typing” on a pair of objects A, B written f : is the “source” or “domain” of f and B is its “target” or “co-domain”.

A ! B . This is read as ’f is a morphism from A to B ’. A



2. There is a partial function on morphisms called composition and denoted by an infix ring symbol, . The ”composite” g may be formed if g : B C and f : A B mor(K ).

!

3.

! 2 This composition is associative: h  (g  f ) = (h  g )  f .

f : A ! C

A category represents a dynamic domain that consists of a set of objects and a set of morphisms or dynamics. Dynamic behavior itself is generally represented in the form of a state machine. In designing reactive systems, a popular representation is that of a Labeled Transition System (LTS). An LTS, and any other dynamic system whose behavior is characterized by morphisms between systemic states, can be represented using a single formalism called coalgebras. Definition: Let F : Set ! Set be a functor that maps between sets. An F -coalgebra or an F -system [18] is defined as a tuple hS; S i, where S is a set of system “states” and S is a mapping S : S ! F (S ), called the “dynamics” of the system.

In the above definition, the actual system that is depicted depends on the definition of the functor F (S ). For example, if F (S ) = fg, then hS; S i denotes a terminating system where each state maps onto the terminating state fg. Similarly, if F (S ) = S , then hS; S i denotes a deterministic system where each state maps onto at most one state. The above two definitions will be used to provide formal underpinnings of the proposed paradigm of dialogs and interaction schema.

5

3 Characterizing an Interaction Space This section introduces the notion of an interaction schema that is used to characterize an interaction space. An interaction schema is considered to be made up of semantic processes called “dialogs” which are related among themselves by “dialog associations.”

3.1 Dialogs As depicted in Figure 1, properties of a dynamic system can be divided into two abstract “spaces” or domains of concern. The static “entity space” concerns all structural aspects of the system; and the dynamic “interaction space” concerns the behavioral aspects of the system. An abstract space or domain may be said to consist of classes of entities that together make up the domain. For example, for the entity space, the set of all classes of objects that constitute the structural elements of the dynamic system, together make up the entity space. Since such classes of objects are conventionally called “domain objects” we retain the same convention referring the term “domain objects” to mean “an object that is part of the static structure.” Figure 2 schematically depicts the notion of an interaction object as opposed to a domain object. A domain object represents an object that can be identified in any static snapshot of the problem domain. Some examples of domain objects would be objects like Account, Transaction Log, User, etc. An interaction object, on the other hand represents a semantic interactive PSP that is part of the information system. An interactive process may be attributed to a single domain object as in Figure 2(a), or to a group of domain objects (a subsystem) as depicted in Figure 2(b). An interaction object depicts the interactive behavior of the domain object or subsystem with its environment in achieving any given functionality. The “environment” may consist of other domain objects within the information system; or may depict the larger environment that is outside of the information system. Interaction objects are semantic objects that are identified in a dynamic fourdimensional picture of the problem domain. Some examples of interaction objects are objects that represent processes or workflows like “OpenNewCreditAccount”, “OpenNewDebitAccount”, “MoneyTransfer”, etc., in a banking situation; or objects like “LandingProtocol”, “TakeoffProtocol”, “CruiseControlProtocol”, etc., in an air traffic control scenario. Each of the above interaction objects involve one or more domain objects like User, Teller, Account or Airplane, ControlTower, etc., and interacts with a larger environment. A characterization of a space is called a schema. An object schema or structural schema characterizes the object space, and an interaction schema characterizes the interaction space.

S hE Ri

Definition: A schema is defined as a characterization of a space, and is represented as – = ; , where or “objects” in the space being characterized, and is the classes of “relationships” among the entities in .

R

E

E is the classes of “entities”

Definition: A dialog is a class of any “entity” that belongs to the interaction schema. The terms “interaction entity”, “interaction object” and “dialog object” are all used interchangeably to refer to specific instances of a dialog.

A dialog represents a semantic interaction process that is part of the dynamics of the information system. A dialog object interacts with its environment in a concurrent fashion and does not distinguish between two or more environments with which it interacts. A dialog may involve one or more domain objects, and is said to represent these domain objects to its environment. The domain objects in turn, are said to have adopted the dialog. Two or more dialogs may share a single domain object. In this case, the dialogs may either share the same class of the domain object or the same instance of the domain object. The interaction space represents the complete set of dynamics of the information system. Hence any message passing between any two domain objects is always qualified within the context of some dialog object. In addition, dialog objects may pass messages among themselves; however, a dialog object is not allowed to interact with any domain object other than those which it represents. An interaction between a dialog object D and an arbitrary domain object P should take place only through another dialog object D0 which represents P . At any given point in time, a domain object may have zero or more dialogs that are currently running which represent the domain object. The role of a given domain object is said to be the set of all dialogs that represent the domain object. The formal structure of a dialog is defined below: Definition: A dialog is represented as D

= hA; M; C; s0 ; i, where:

6

Domain Object

Domain Object

Domain Object

Domain Object

O1 method(I1) O2 method(I2)

O1 method(I1) O2 method(I2)

O1 method(I1) O2 method(I2)

O1 method(I1) O2 method(I2) ...

Dialog Object

n 1

3

2

SOI

EOI

...

time

(a) Y

Time X

Z

Domain object Interactions among domain objects and with the outside world Interaction object or dialog (a semantic interaction process) Entity space of the information system

(b)

Figure 2. Domain objects and interaction objects

 A is the set of domain objects that the dialog represents, and is called the attribute set of the dialog. Elements of A are of the form of either T – representing any domain object of type T , or x : T – representing a particular instance x of type which have attributes of the form x : T hence share the same instance x of the domain object of type T ).

T.

(Two dialogs

 M is a set of method interfaces, also called observer functions, which are of the form m(Ti ) : Tp _ Tp+1 _ : : : Tq , which indicates that the function can provide an input of type Ti to the dialog (which could be a combination of multiple inputs of different types), and can observe an output of one of the types in Tp : : : Tq from the dialog.

 C is a set of operational contexts of the dialog. Each operational context depicts an observably closed context of dialog behavior, represented by a Labeled Transition System (LTS).

 s0 is the Start state of the dialog. In most cases, s0 belongs to all operational contexts.   is a set of context morphisms, of the form e : ci ; cj , where e is an expression involving elements of A, and ci , cj 2 C . denotes that when e holds, and current operational context is ci , then the operational context changes to cj .

This

A dialog object interfaces with its environment through a set of method interfaces called “observer functions”. Each observer function accepts inputs of a specified type and gives back outputs within a specified range of types back to the environment. The behavior of a dialog is discerned by the environment through a series of “observations” made by providing inputs through the observer functions and observing the type of outputs obtained. Based on the current states of its domain objects, the behavior of a dialog object may change for the same series of interactions. These different sets of behaviors are said to result in different operational contexts for the dialog. The solution space of a dialog is described in terms of operational contexts. Each operational context represents an observationally closed world of dialog behavior – that is, in every state of the dialog, any given observer function is either disabled or defined to execute a particular set of activities to reach another destination state. An interactive PSP that a dialog executes is said to begin from the “start” state s0 , which is a state that is common to all observational contexts. The interactive PSP is said to have ended when it reaches an end state. However end states differ depending on the operational context. In order to illustrate the solution space of a dialog, it is necessary to define operational

7

contexts in a more formal fashion: Definition: An operational context ci

    

2 C = hS; s0 ; P; TI ; TO ; i, where:

S is a set of states of the interaction process. Each state is reached after zero or more interactions starting from the start state s0 . P  S is a set of end states that denote end of the interaction process. TI is the set of all input types that may be input by all observer functions of the dialog. TO is the set of all output types observable by all observer functions of the dialog.

is a transition relation of the form : S ! (TI ! TO )  S .

Each operational context contains a state machine representation for the dialog. The dialog begins at state s0 , and depending on what the current operational context is, a set of transitions are defined that map an input type to an output type and change states. In some states some of the observers may be disabled having no impact on the dialog. The transition relation within a context is specified by the term in the definition above. Such a representation of an interactive process is called a Labeled Transition System (LTS) which is used as a generic model for representing reactive systems [13]. An interactive PSP like a dialog is a special case of a reactive system. A reactive system is meant to maintain an ongoing interaction with its environment; while an interactive PSP maps from a problem state to a solution state with zero or more intermediate interactions. Dialog trace: Any instance of a dialog is said to leave a trace in the interaction space. The trace of a dialog is a string of the form s0 (TI ! TO ) p, where 9c 2 C; 9P 2 c, such that p 2 P . The trace of a dialog represents a particular interaction stream that maps from the initial state of the dialog to any solution state in any operational context of the dialog. The trace of a dialog is treated as a semantic entity that represents a dialog instance that once existed in the interaction space. Queries on interaction spaces return entire dialog traces and not any substructure of them. Distinguishability certificate: For any operational context ci 2 C , let Int(ci ) be the set of all strings of the form s0 (TI ! TO ) , that denote valid prefixes of interaction traces in ci . A prefix string g 2 Int(ci ) is said to be a distinguishability certificate for ci , if 8cj 2 C ? fci g; g 62 cj and 6 9h, such that h 2 ci ; h 62 cj ; and length(h) < length(g ). In other words, a distinguishability certificate for an operational context is the smallest trace prefix that uniquely identifies the trace as belonging to the context. Context morphisms: A dialog currently in context ci is said to switch to operational context cj , if a condition e holds such that e : ci ; cj 2  . Context morphism may occur at any time during the life time of a dialog. Let t denote the dialog trace prefix that has charted the behavior of the dialog in the current context ci . When the dialog changes context to cj , it changes to a state s in cj determined by the longest prefix p 2 pref (t), such that p is recognizable in cj . The trace prefix that is recognizable by all contexts is s0 . Hence in the worst case, the dialog rolls back to the start state in the new context and begins its process anew. Context morphism is not a “passive” mapping between dialogs. A context morphism may involve a few computations (for example, compensatory operations) to be performed before the dialog switches to a new context. Context Subsumption: In the definition of a dialog it was mentioned that the start state s0 is common to all contexts “in most cases.” The exception to the above rule occurs when contexts subsume one another. A context ci = hSi ; Pi ; TIi ; TOi ; i i is said to be subsumed by context cj = hSj ; Pj ; s0 ; TIj ; TOj ; j i if Si  Sj ; TIi  TIj ; TOi  TOj and i  j . Context subsumption is used to denote special areas of particular operational contexts, for example, critical regions. Since each operational context contains a separate state machine that defines the dialog, every context hence shares a common “start” state. However, a context that is subsumed by another context does not depict a new state machine, but instead depicts a subset of the state machine of the larger context. Hence such contexts need not have a common “start” state. Example 1: Figure 3 depicts a dialog object that has two operational contexts defined. The dialog indicates a process called MovePiece, that depicts the movement of a piece in a board game. The dialog applies to domain objects like Board, User and Piece. The operational context C0 for the dialog indicates the case when it is the user’s turn to move his/her piece on the board. The behavior in this context is shown by an LTS that depicts how a user picks up the piece and moves it to a new location. Context C1 depicts the case when it is the other user’s turn to move. In this context the user cannot pick up a piece to move; however may query regarding how any given piece has reached its present place. In this example, the stop states that indicate the end of a MovePiece process are the same as the start state. For an external observer, contexts C0 and C1 can be differentiated only by the behavior of the Pick() observer function. The function “picks” the piece in context C0, but only shows the history of the piece in context C1. The distinguishability certificate for both contexts is hence s0 Pick (). The trace prefix s0 Move() , for example, cannot distinguish between C0 and C1. The specification of the dialog has also shown the expressions that need to hold for each of the contexts. For the dialog to be in context C0, Me.isMyTurn() 8

Move()

MovePiece Board BoardObj; Piece Picked; Player Me;

Pick()

Picked

Commit()

Placed

Pick() Place() Move()

Pick()

C0:

Piece Pick(); Boardpos Move(); Boardpos Place(); int Commit(); int Abort();

Commit() Abort()

Abort()

Start

Move () Commit() Place() Pick() Pick() Show Hist

C0: [Me.isMyTurn()] C1: [not(Me.isMyTurn())]

Place()

C1:

Move()

Start Abort()

Move()

Figure 3. Movepiece: A dialog object should return true, where Me, is the domain object that corresponds to the user who is running the MovePiece dialog. For context C1, Me.isMyTurn() should return false. The figure also depicts a few observer functions which are shown as cancelled out in a few states. These depict disabled transitions in the respective dialog states. Example 2: A dialog object for a workflow depicting an application process in a university is shown below.

A = {Studentdb, Scorecard, Screeningscore, Application, Admissionslip, Rejectionslip} M = {RequestAppln() : Application; SubmitScoreCard(Scorecard, Application) : Admissionslip | Screeningform | Rejectionslip; SubmitScreeningScore(Scorecard, Application) : Admissionslip | Rejectionslip; RenewApplication(Application) : Admissionslip | Rejectionslip; } C = { 1: RequestAppln()/Application --> SubmitScoreCard()/Admissionslip 2: RequestAppln()/Application --> SubmitScoreCard()/Screeningform | Rejectionslip --> SubmitScreeningScore()/Admissionslip | Rejectionslip 3: RequestAppln()/Application --> RenewApplication()/Admissionslip | Rejectionslip } 9

In the above example, the dialog is a workflow process that represents domain objects like Studentdb, Scorecard, Screeningscore, etc. and performs the process of student application. The application process may be in three contexts. The first context refers to those applications where the student can get a direct admission based on his/her score card. The second context depicts cases where students need to undergo a screening test before a decision is made about their admission. The third context refers to returning students who wish to renew their applications, rather than starting a fresh application. There are four “observer” functions that return data of different types in different contexts.

3.2 Dialog Associations Earlier, a schema was defined as a tuple of entity and relationship types. In an interaction schema, dialogs form the entities of the schema. Relationships among dialog objects hence need to be represented in order to obtain a complete characterization of the interaction schema. Relationships may be of different types, and different relationship types may be identified based on the problem domain. However, we introduce a specific type of dialog relationship that is common across all application domains. This is called constrained association. This is in the form of an association between two or more dialog objects, and being characterized by zero or more constraints that hold on the dialogs in the association. Constraints in a constrained association are in the form of constraint equations on the operational contexts of the dialogs. Such an association depicts how an interactive process affects the functioning of the others. Definition: A constrained association between n dialogs is an n-ary association denoted by R(D1 ::Dn ) where D1 ::Dn are n dialogs, and  is a constraint relationship on the operational contexts of the n dialogs.

MovePiece Player1;

[CTS(Player1) = C0 && CTS(Player2) = C1] || [CTS(Player1) = C1 && CTS(Player2) = C0]

= h; D1 ; D2 ; : : : ; Dn i,

MovePiece Player2;

Figure 4. Constrained association between dialogs Figure 4 depicts a constrained association relationship. This relationship represents the association that exists between two “MovePiece” processes of opposing players. The constraint that needs to hold in this association is that while it is the first player’s turn to play – that is, when the first player is in context C0, the second player would be in context C1 and vice versa. Constrained associations are a general form of paradigms like mutual exclusions, monitors and critical sections used in resource sharing and processes management domains. While locks and critical regions seek to exclude processes from regions, constrained association may also have other constraints as well. For example, a constrained association may necessitate a dialog to be in a particular context when an other dialog is in an other context. This not only represents an exclusion constraint, but also an inclusion constraint that specifies where a particular dialog ought to be in. Constrained associations may have multiple arity and may hold over n dialogs simultaneously. Multi-stream interactive processes: A constrained association actually represents an interactive process that interacts over multiple streams. The entire set of dialogs and the constrained association in Figure 4 may be considered to be a multi-stream interactive PSP that interacts with two environments. To an observer on any of the streams, the behavior of the dialog seems to change due to hidden adversaries. A constrained association represents a multi-stream interaction process that is part of the system based on the functional requirements. On the other hand, any domain object D which has has currently has dialogs D1 ; D2 ; : : : ; Dn , representing it, also functions as a multi-stream interactive process.

10

The next section introduces formalisms for the dialog model using category theory and coalgebras. Using this formalism, the notion of constrained association is revisited to identify two kinds of constraints – affirmative and negative constraints – that could be defined on the operational contexts of the participant dialogs.

4 Category Theoretic Formalisms for Dialogs Category theory and the associated theory of coalgebras provide a natural means for representing dynamic systems. Rutten [18] provides a theory of “universal coalgebras” using which systems, morphisms between dynamic systems and congruence relationships between systems (using bisimulation) are established. In this section, we use concepts from these for describing dialogs and dialog associations, and to reason about the nature of interaction spaces. Let F : Set ! Set be a functor. An F -coalgebra or a F -system, as defined in [18] is a pair hS; S i, consisting of a set S and a function S : S ! F (S ). The set S is called the set of states of the system and S is called the dynamics of the system. Different kinds of systems may be described by describing different functors as part of F (S ). For example, if F (S ) = 1, where 1 is the singleton set fg, the F -coalgebra S ! F (S ) describes a system where every state leads to termination (the singleton set). Similarly, F (S ) = S , describes the class of deterministic systems where every state maps onto a another (possibly the same) state in the state set. An LTS may be described by an F -coalgebra by defining F (S ) = (TI ! TO )  S , where (TI ! TO ) is the set of all functions from the input domain TI to the obtainable outputs TO . This functor describes a transition where every element of TI maps to an element of S giving an output from TO . The system S ! F (S ) now defines a (deterministic) LTS where given an input, each state maps to another state and produces an output. Different contexts of a dialog and context morphisms may be represented as homomorphisms between systems. Let hS; S i and hT; T i be two systems. A function f : S ! T is said to be a homomorphism if F (f )  S = T  f . Intuitively, this means that if s 2 S and S (s) = s0 and f (s) = t, and f (s0 ) = t0 , then T (t) = t0 . A context transition system can now be defined as a set of systems that represent each context of the dialog, and a set of homomorphisms between these systems. Such a structure consisting of a set of objects and a set of morphisms between the objects is called a category. A dialog can now be defined as follows:

h

i

Definition: A dialog is a category C;  , consisting of a set of transition systems or “contexts” C and a set of morphisms  between the contexts. Each element of C is of the form S; S , where S is a set of states and S is the set of dynamics defined as a mapping S F (S ), where F (S ) = (TI TO ) S . TI and TO represent the input domain (method interfaces) and output domain (method return types) respectively.

!

!



h

i

Representing a multi-stream interaction process involves combining many single stream interaction processes. This may be achieved by using the coproduct or disjoint union between sets. A coproduct between two sets X and Y , denoted by X + Y is the set fh0; xi; h1; yijx 2 X; y 2 Y g. The elements of the sets are combined such that their individual identity is maintained. As seen earlier, a constrained association represents a multi stream interactive process. Constraints over a set of dialogs are defined on their operational contexts. With the notion of coproducts, two kinds of constraints may be defined – affirmative constraints and negative constraints. In affirmative constraints, the constraint equation indicates all coproducts of operational contexts that are allowed. Anything that is not specified by the affirmative constraints is disallowed. In negative constraint specification, the constraint equation specifies all coproducts that are disallowed. The multi-stream interaction can allow any coproduct that is not disallowed by the constraints. To illustrate the above by an example, we take up the case of the “MovePiece” dialog. The constraint that exists between two instances of the dialog is that the contexts of each are mutually exclusive. Let C01 ; C11 represent the first and second contexts of the first player and let C02 ; C12 represent the first and second contexts of the second player respectively. An affirmative constraint relation between the dialogs would be of the form f(C01 + C12 )(C11 + C02 )g, indicating the set of allowable coproducts. A negative constraint relationship that represents the same multi-stream interaction would be of the form f(C01 + C02 )(C11 + C12 )g.

11

5 Related Work Depicting an interactive process as a first class object, and relating interaction processes are not particularly new notions. There have been some approaches which have sought to represent processes as first class objects and also to relate process structures. Some examples are as follows – use cases (now part of UML [22]) consider process structures as coherent units of functionality. Workflow design for example, considers process structures as semantic entities in their own right. Recently, there have also been some approaches that relate workflow structures using aggregation and inheritance, to obtain a workflow schema of sorts [1]. Similarly Liu and Meersman [11] build an “activity schema,” where each object in the schema represents an interactive activity. The approach here is based on object-oriented notions, and activities are related by two kinds of relationships – specialization and aggregation. At more theoretical levels, there have been paradigms that relate dynamic processes thus creating a schematic structure. Some examples are Hierarchical Petri Nets [16], and Abstract State Machines [7]. In the field of databases, the notion of “transaction” is used to represent a dynamic process that is treated as a semantic entity. In order to get an understanding of related work in modeling dynamic systems and positioning the concept of an interaction space, we need to take a general view about how dynamic processes are classified. In a general sense, specification of dynamic processes may be classified as either – behavioral or functional. Behavioral specification specifies the “how” of the process. It specifies the activities and their sequence and/or dependencies that exist among activities. Behavioral specifications usually take the form of task dependency graphs, flow charts, object interaction diagrams, etc. Functional specification, on the other hand, specifies the “what” of a dynamic process. It specifies the different semantic states that the process undergoes in its lifetime, and transitions between states. These would usually be of the form of state charts, Petri nets, etc. A schematic structure is a logical representation of a domain, and hence it specifies the “what” of the domain. An interaction schema is hence a functional representation of a domain, in that, it is a specification of the domain of the dynamic behavior of the information system. It is in this fact that the notion of an interaction space differs from existing approaches. The specification of the dynamic behavior of an information system consisting of multiple interactive processes cannot be characterized by algorithms, or a collection of algorithms. For example, a collection of object interaction diagrams forms a set of algorithmic specifications that describe a set of dynamics. Similarly, workflow management systems represent collections of algorithmic specifications of processes that exist in the domain. But a notion of interaction schema is different in that it tries to characterize an abstract space that represents all behavioral characteristics o f the system.

5.1 Comparison with UML Since UML [22] is currently the standard for object oriented modeling, we first contrast the notion of dialogs and interaction schema with concepts in UML for representing interactive behavior. In UML, there are many different facets for representing behavioral aspects. An interaction is defined in UML as the “dynamic behavior of the message sequences exchanged among objects to accomplish a specific purpose.” From this definition, interaction is represented in two forms – as a collaboration diagram and a sequence diagram. A collaboration diagram shows the static collaboration structure among domain objects for a particular interactive process. The sequence diagram depicts the dynamic unfolding of the interaction sequence in executing a process. In addition, behavior is also represented in terms of state charts and activity diagrams which denote semantic states of the actual process itself. An activity diagram represents activities as action states, the completion of which would involve a transition. The notion of treating interaction processes as objects in their own right, is also addressed in a limited manner, in the form of use cases. A use case represents a “coherent unit of functionality provided by a system or a class as manifested by sequences of messages exchanged by the system and one or more outside interactors (called actors) together with actions performed by the system.” However, with the lack of a separate concept of an interaction space, the coherence between the different representations of behavior becomes difficult to reconcile.

5.2 Other Related Work Interactive paradigms of programming like object oriented, multi-agent and reactive systems, have been acknowledged to represent a different computing paradigm than algorithms. For example, in the context of reactive systems, Manna and Pnueli [13] conjecture that reactive systems are irreducible to algorithms. Abadi and Cardelli [2] develop a theory of objects using 12

the term objects as fundamental concepts, rather than trying to explain objects as functions. Miller [15] classifies software systems into two parts based on their design– hierarchical systems, where the design is sequential and the system has many inputs and a single output; and open systems, which are concurrent in nature having many inputs and many outputs. The behavior of objects that provide services over time represents a concurrent (open) domain rather than a hierarchical domain. Presently interaction processes are mostly designed in a sequential and hierarchical manner; however, by considering semantic interaction processes as objects in their own right, identifiable in the four-dimensional interaction space, we find that the interaction space represents a concurrent domain. Representing interactive processes as objects in their own right have also been addressed in some ways in the existing literature. Liu and Meersman [11], propose a notion of an “Activity schema,” where activities are treated as objects in their own right. Here, first order temporal logic (FOTL) is used to represent communication behavior among domain objects. An other approach that uses interaction components is by Broy [3]. Here, an interaction component is modeled as streams of inputs and outputs with its environment. Different kinds of composition relations are defined for composing these components. Designing the behavior of an information system is considered in a top-down fashion and three forms of refinement relations are also proposed. The notion of closed worlds and multiple closed worls, similar to context morphisms of dialogs, have been proposed in the context of non monotonic reasoning in Artificial Intelligence (Reiter, 1978, cf. [14], [12]). There have been many extensions to the basic closed world assumption – chiefly the generalized CWA (GCWA), and the extended CWA (ECWA). However, both of them address issues arising from disjunctions in the set of assertions; which is alleviated in the present case by use of multiple operational contexts. The notion of multiple closed worlds has also been addressed in the artificial intelligence domain and ay be be found in Kripke semantics for modal logics (cf. [14], [12]). Finally, the concepts of dialogs and interaction schema presented here are part of a larger framework called “codesign” [4], [5], where the effort is to bring coalgebraic techniques to practical computer science.

6 Conclusions When managing large dynamic systems, the notion of an interaction schema would be crucial for representing the behavioral dimension of the system separately. In order to characterize an interaction schema in a comprehensive manner, it is important to understand the nature of the interaction space. Interaction Machines (IMs) provide good insights into this end. Interaction machines show that interactive problem solving cannot be reduced to algorithmic problem solving. Although an object in the conventional sense would depict an interaction machine, the notion of IMs led us to ask how the solution space of an interactive problem solving is different from an algorithmic solution space. This led to the concept of an interaction space – that depicts the solution space of an information system. The dialogs model proposed in this paper can likely be implemented in many forms. However, we presently restrict the endeavor to developing the concept of dialogs as explained in this paper, and to design specific implementations for dialogs. Along this line, a specification language is planned that can be used to specify a dialog, its operational contexts and dialog associations. A CASE tool would then translate the specifications into some well known OO language like Java or C++. In addition to the above, a paradigm called Interaction Schema Management System (ISMS) is also planned which manages dialog traces. Queries may be designed based on temporal logic declarations that return individual or clusters of dialog traces.

Acknowledgments We would like to extend our heartfelt thanks to Myra Spiliopoulou for her comments on a previous version of the paper, and to Dina Goldin for clarifications regarding interaction machines and the nature of interactive problem solving.

References [1] W.M.P. van der Aalst. Generic Workflow Models: How to Handle Dynamic Change and Capture Management Information? Proc. of Fourth IFCIS Int’l Conf on Cooperative Information Systems (CoopIS), Edinburgh, IEEE Computer Society Press, September 1999. [2] Martin Abadi, Luca Cardelli. A Theory of Objects. Springer-Verlag, New York 1996. 13

[3] Manfred Broy. Compositional Refinement of Interactive Systems Modelled by Relations. to appear in LNCS, SpringerVerlag. [4] Wolfram Clauß, Bernhard Thalheim. Abstraction Layered Structure Process Codesign. Proceedings of the 8th International Conference on Management of Data (COMAD ’97), Narosa Publishers, Chennai, 1997. [5] Wolfram Clauß, Jana Lewerenz, Bernhard Thalheim. Dynamic Dialog Management. In: Stephen Liddle (Hrsg.): Proc. of the ER’97 Workshop on Behavioral Models and Design Transformations: Issues and Opportunities in Conceptual Modeling, Los Angeles, 1997. [6] Dina Goldin, Peter Wegner. Persistent Turing Machines. Technical Report, Brown University, 1998. [7] Yuri Gurevich. May 1997 Draft of the ASM Guide. Technical Report, University of Michigan EECS Department, CSETR-336-97. [8] John Hopcroft, Jeffrey Ullman. Introduction to Automata Theory, Languages and Computation, Addison-Wesley, 1979. [9] B. Jacobs, J.J.M.M. Rutten. A Tutorial on (Co)Algebras and (Co)Induction. Bulletin of EATCS, Vol. 62, 1997, pp. 222–259. [10] B. Jacobs. Categorical Logic and Type Theory, Elsevier, 1999. [11] Ling Liu, Robert Meersman. The Building Blocks for Specifying Communication Behavior of Complex Objects: An Activity-Driven Approach. ACM Transactions on Database Systems, Vol 21, No 2, June 1996, pages 157-207. [12] Witold Lukaszewicz. Non-Monotonic Reasoning: Formalization of Commonsense Reasoning, Ellis Horwood Series in Artificial Intelligence, 1990. [13] Zohar Manna, Amir Pnueli. The Temporal Logic of Reactive and Concurrent Systems, Springer-Verlag 1992. [14] V. W. Marek, M. Truszczynski. Nonmonotonic Logic: Context-Dependent Reasoning, Springer-Verlag, 1993. [15] Dale Miller. Logical Foundations for Open System Design. ACM Computing Surveys, Vol 28, Dec 1996. [16] A. Oberweis, P. Sander. Information System Behavior Specification by High-Level Petri Nets. ACM Transactions on Information Systems, Vol. 1, No. 4, October 1996, pages 380-420. [17] Michael Prasse, Peter Rittgen. Why Church’s Thesis still holds - Some Notes on Peter Wegner’s Tracts on Interaction and Computability, Computer Journal Vol. 41 (1998) No. 6, pages 357-362 [18] J.J.M.M. Rutten. Universal Coalgebra: a theory of systems. Technical Report, CS-R9652, Centrum voor Wiskunde en Informatica, Amsterdam, Netherlands, 1996. [19] Srinath Srinivasa, Myra Spiliopoulou. Modeling Interactions Based on Consistent Patterns. Proc. of CoopIS’99, IEEE Computer Society Press, Edinburgh, September 1999. [20] Srinath Srinivasa, Bernhard Thalheim, Myra Spiliopoulou. Interaction Schema and the Maintainability of Software Systems. Work in progress. [21] Srinath Srinivasa, Myra Spiliopoulou. Discerning Behavioral Properties by Analyzing Transaction Logs. to appear in Proceedings of ACM Symposium on Applied Computing, SAC’00, Como, Italy, March 2000. [22] UML Resource Center. http://www.rational.com/uml/index.jtmpl [23] Peter Wegner. Why Interaction is More Powerful than Algorithms? Communications of the ACM, May 1997. [24] Peter Wegner, Dina Goldin. Interaction as a Framework for Modeling. To appear in LNCS #1565. [25] Peter Wegner, Dina Goldin. Mathematical Models of Interactive Computing. Technical Report, Brown University, Jan 1999. [26] Peter Wegner, Dina Goldin. Coinductive Models of Finite Computing Agents. Electronic Notes in Theoretical Computer Science, Vol 19, Elsevier, 1999.

14