Towards Foundations of Information Systems Based on Interaction Modeling Srinath Srinivasa1 Brandenburgische Technische Universit¨at Postfach 101344, D-03013 Cottbus Germany
[email protected]
Abstract While algorithms constitute the fundamental building block of computations, it has been generally acknowledged that the behavior of an information system cannot be reduced to an algorithm. Most information systems are termed to be “open systems” whose design complexity is much higher than “closed” systems. The term open system is defined in different streams with different meanings for the term “open.” However, it is still unclear what exactly constitutes the complexity of open system design. In a stream of thought concerning interactive computation, Wegner [20] defines open systems as systems which interact with their environment for problem solving. In this paper, we explore this stream of thought concerning interaction modeling and look for formal underpinnings that explain why interactive computation cannot be reduced to algorithmic computation; and what could be the formal foundations for open systems design. Keywords: Interactive Problem Solving, Interaction Modeling, Open Systems, Category Logic, Deontic logic
1 Introduction Information Systems (IS) is a generic term referring to software systems that provide information based services. The notion of an IS has been addressed from various perspectives like managerial, technical, organizational, etc. However, despite the presence of an active research community that studies conceptual IS models, this term still lacks precise formal underpinnings. Unlike for say, databases, there is no agreement on what constitutes “principles of information systems.” Some of the pertinent questions that make up the foundational aspects would be: What are the technical components that make up the essential building blocks of every IS? What are the set of functionalities that should be present in every IS? What are the boundaries of IS behavior? What are some things that any IS cannot do – even theoretically?, etc. Researchers generally agree over a notion that an IS is an “open” system. However, there are no clear definitions and foundations to what constitutes an open system. The term “open system” has been explicitly
1 This research was supported by the German Research Society, Berlin-Brandenburg Graduate School in Distributed Information Systems (DFG grant no. GRK 316).
1
defined in at least three domains. In the domain of software architecture, an open system is a system whose architecture is well known and hence can be adapted and enhanced by third party vendors [14]. In the domain of actor computation, Agha et al. [2] define an open (actor based) system to be a system in which the addresses of some (but not necessarily all) actors of the system are known to the outside world. Open configurations for actor based systems enable easy composition and scalability of the system. They also enable an intuitive way of expressing different interface semantics. In the process calculus domain, Miller [13] classifies software systems into two classes – hierarchical and open organizations. In a hierarchical organization, the system is viewed as having many inputs and a single output. Such systems can usually be modeled using functions and generalizations over functions like functors. In an open organization, the system is viewed to have multiple inputs and multiple outputs. These are systems that incorporate features like object orientation, threads and communicating processes. Miller proceeds on these definitions to explain open systems in terms of process calculi. However the above definitions seem inadequate to understand the nature of open systems and where the complexity lies in designing open systems. For example, it is unclear why a system having multiple outputs (open organization) cannot be reduced to a system having a single output (hierarchical organization), by considering multiple outputs as a composite form of a single output. In a stream of thought related to that of process calculus, Wegner and Goldin [19, 20, 21] argue that interactive computation forms the basis for open organizations, which cannot be reduced to algorithmic computation. In fact, it is even argued that interactive computation cannot be reduced to a Turing Machine (TM) computation, which has been considered to represent the entire domain of computable functions. They propose an alternative notion called Interaction Machines (IMs) to form the basis for open systems and “empirical computer science.” Wegner and Goldin’s proposal has not been without its share of controversy. Some authors (for example, Prasse and Rittgen [15]) argue against Wegner’s thesis and claim that IMs can be reduced to TMs by “closing” the open configuration. In this paper we look into this stream of thought in more detail. We depict Wegner and Goldin’s claim in terms of what we call the “solution space” of an algorithmic or interactive computation. We show that while an interactive process can be theoretically reduced to an algorithmic process, IMs would still be an interesting notion because of how an interactive solution space differs from an algorithmic solution space. Interactive solution spaces characterize the behavior of open systems that are representative of most real world information systems. We look at some models towards foundations for interactive solution spaces that can in turn provide directions for principles of information systems and answer questions like the ones posed above.
2 Algorithms vs Interaction Historically, the notion of (automated) problem solving has been represented as computable functions that give an output “answer” to an input “problem.” Algorithms represent the space of computable functions. In the above notion of problem solving, there are some implicit assumptions. It is assumed that the input will never change once the process of problem solving has begun; and that problem solving processes do not affect one another. A number of approaches have been explored to hold these assumptions. For example, transaction processing in databases follow the ACID (Atomicity, Consistency, Isolation and Durability) property. Atomicity mandates the first assumption that the transition from the start of the process to its end should be closed. Isolation mandates the second assumption that processes are mutually exclusive of one another.
2
However, IS dynamics do not always adhere to these assumptions. In real world information systems, usually there are a number of interactions between the IS and the environment in the lifetime of a semantic process. For example, a process for booking train tickets may include a number of interactions like querying for existing trains, input of desired seat(s), input of criteria for concessions, choosing method of payment, etc. The presence of interactions changes the nature of IS dynamics. At the start of the process, there is insufficient information to determine what the output of the process will be; and an intermediate output during an interaction may affect the next input that is received. For example, the input train number for which a ticket is sought would be dependent on the query results for available trains. At the start of the process, neither the IS nor the user might know which train would be selected. These interactive processes are also not isolated from one another. A passenger booking a train ticket may be denied a ticket because of some other passenger booking the same ticket. While the underlying database dynamics that handles these different transactions maintains the ACID property, the semantic processes that make up IS dynamics don’t adhere to these restrictions. Recent papers on the notion of interactive problem solving, by Wegner and Goldin [18, 19, 20], claim that interactive problem solving like the above cannot be reduced to algorithmic problem solving characterized by computable functions. Algorithmic computation: The essential arguments towards this end, may be explained as follows. Algorithmic problem solving is represented by a TM (cf. [9]), that maps a given finite input specification to a finite output. TMs start their computation from a start state, and halt when one of the halt states is reached. Considering only those class of problems that result in a TM to halt, an algorithmic problem solving process can be represented as a mapping of the form I ! O, where I is the input “problem” domain and O is the output “solution” domain. Algorithmic problem solving is schematically represented in Figure 1(a). Examples of algorithmic mapping include – answering a database query, computing the square of a given number, etc. Definition: An algorithmic problem solving process (APSP), is defined as a a tuple, AP SP = hI; O; Æ i, where I is the “problem” domain depicting the set of possible inputs, O is the “solution” domain depicting the set of possible outputs, and Æ is a computable function of the form Æ : I
!
O, that maps input “problems” to output “solutions.”
Sequential interactive computation: Figure 1(b) represents a sequential, or single stream interactive problem solving process. Here, problem solving is the mapping from the “problem” state A, to the “solution” state E . However, this transition involves a number of intermediate interactions with the environment. Also inputs from the environment may be coupled with previous outputs from the computing machine. The interactions may potentially change the direction of the problem solving process. At the problem state A, given the set of initial inputs, it is not possible to determine the solution state that would be reached at the end of the interactive process. In addition, the start state A may be the result of earlier interactive computations, and hence may be different every time a new interactive process begins. In an interactive session, computation between any two consecutive interactions is algorithmic in nature. This mapping may be represented by a partial function of the form (sk ; ik ) ! (sk+1 ; ok ), where sk is the state of the system at the k th interaction, ik is the input provided at the k th interaction, ok is the output obtained after the k th interaction; and sk+1 is the new system state. The partial function may be represented as Æ : S I ! S O, where S is the state space of the system, I and O are the input and output domains respectively. In order to represent such a system, an abstract model called Single-stream Interaction Machine (SIM) was proposed in [20]. Later on Goldin [6] proposed an extension to TMs called the Persistent Turing Machine (PTM)
3
as a mathematical model for SIMs. PTMs have a minimal extension to TMs in the form of a persistent worktape that is maintained intact between successive interactions. At the beginning of a computational process, TMs begin from the same start state, while a PTM begins from a start state that is determined by the contents of the persistent worktape. Sequential interactive computations of the above form have also been addressed in the form of various models in different domains. Reactive systems [11] address systems that maintain an ongoing interaction with their environment. The fundamental model of a reactive system is a Labeled Transition System (LTS) that is represented as a tuple hS; A; Æ i, where S is the set of states, A is a set of “actions,” and Æ is a mapping of the form Æ : S ! P (A S ), that maps a given state to a set of behaviors (actions) and destination states. It is sometimes confusing to note that interactive systems like the above are also called “concurrent” systems. This is because, an interactive process maintains a coroutine or a concurrent relationship with its environment, as opposed to a subroutine or sequential relationship maintained by an algorithmic process. However, in our case, we term this as a sequential interactive process to denote that the interaction stream of inputs and outputs take place in a sequential manner. Formal definition of sequential interaction is as follows: Definition: A Sequential Interactive Process (SIP) is defined as a 5-tuple SIP = hS; I; O; Æ; E i, where S is the state space of the system, I and O are input and output domains respectively, Æ is a computable partial function of the form Æ : S I ! S O; and E is the environment whose input at the k th interaction may be dependent on the previous output obtained. E is hence defined as a (possibly non computable) mapping E : S O ! I . Definition: SIP denotes zero or more runs of a SIP and is a set consisting of elements of the form (s0 ; i0 )
(s1 ; o0 ) (s1 ; o0 ; E )
!
i1 (s1 ; i1 )
!
(s2 ; o1 ) (s2 ; o1 ; E )
!
!
i2 : : :
Definition: SIP n denotes SIPs consisting of n interactions. Elements of SIP n are also represented as (sk ; ik ) (sk+n ; ok+n 1 ) which is the transitive closure of n sequential interactions.
!
Concurrent (Multi-stream) interactive computation: Figure 1(c) depicts a multi-stream interactive process. Here, interaction takes place on more than one stream simultaneously. The figure depicts two interaction streams that the machine interacts with. While the internal state of the machine changes according to the sequence ABCDEF G, the stream on the left hand side perceives the change of system state to be BDEF G and the right hand side perceives the change to be ACG respectively. Multi-stream interactive processes are very common in practice. Tasks like coordination, resource sharing, multi-user applications, process management and workflows all address semantic processes that interact with multiple streams simultaneously. Hence, the lack of isolation among multiple IS processes is not always an undesirable side effect of parallelism, and could well be a required feature. However, the IS community has devoted far less attention to multi-stream interaction as a topic in its own right. Issues related to multi-stream interactions have mostly surfaced in domains like coordination models, process management and resource sharing. They have been mainly addressed as contention resolution problems – for example, locking in databases, monitors and semaphores in operating systems, multiplexing protocols (eg. token ring) in coordination and networking, etc. However, to the best of our knowledge, multi-stream interaction has not been considered in its entirety, and as a separate topic, by the IS community. Wegner and Goldin [20] introduce an abstraction representing a multi-stream interactive process. This is called a Multistream Interaction Machine (MIM). MIM is an extension of SIM in that it interacts on multiple streams simultaneously. In contrast to the reducibility of Multi-tape TMs to single-tape TMs, MIMs cannot be reduced to SIMs. However, unlike the PTM which models a SIM, there is no mathematical model proposed for a MIM. A Multi-stream interaction may be defined formally as follows:
4
Definition: A Multi-stream Interactive Process (MIP) that interacts with n environments, is defined as a 5-tuple hS; I; O; E ; Æ i, where S is the state space of the system; I and O are input and output domains respectively; E = fE1 ; E2 ; : : : En g is a set of environments that are simultaneously interacting with the MIP, and Æ is a computable partial function of the form S E I ! S E O; that, given an input from a particular environment and the present state of the process, maps to an output on (possibly another) environment and possibly changes the system state.
Theoretically, a MIM represents a foundational model of an information system. Any information system can be considered to be a multi-stream interaction machine that is interacting on multiple streams simultaneously. The observable behavior on any stream is influenced by interaction history and interactions taking place on other streams. In contrast to Wegner’s claims, single stream and multi stream interactions can be fundamentally reduced to TMs. While a TM is a mapping between domains I and O, a SIM is a computable mapping between S I and S O; and a MIM is a computable mapping between S E I and S E O. However, considering S I or S E I as input domains would mean that the state of the system (and the environment identifier, in the case of a MIM) have to be passed back and forth by the environment during each interaction. While in a theoretical sense this would reduce IS behavior to algorithmic behavior; it does not reflect how IS behavior proceeds in reality. It would still be interesting to model interactive behavior as they occur in practice – where environments are not cognizant of the system state, and states are not explicitly passed as inputs.
3 Algorithmic and Interaction Spaces The fundamental aspects that distinguish an “open” interactive computation from a “closed” algorithmic computation are two fold – persistence of state and channel sensitivity. Persistence of state over multiple interactions introduces sequential interaction and channel sensitivity of inputs and outputs introduces concurrent interaction. In order to see how these aspects affect behavior, we need to look at a concept called the “solution space” of a problem solving process. A problem solving process can be considered to represent transitions in an abstract state space that depicts different states of the system.
Definition: The solution space of a problem solving process is defined as the set of all state transition sequences that characterize the problem solving process.
For example, in a TM representing an algorithm, every computation starts at the start state, and ends at one of the halt states. The solution space for this algorithm is the set of all state sequences, beginning from the start state and ending at one of the halt states, that represents the TM behavior for all possible inputs. Such a set is also called the language of the TM. The characteristic feature of a TM solution space is that these exists a partial order among the TM states. The least element of the partial order is the start state, and the greatest elements are the set of halt states. Every state s in the set can be defined in terms of s0 , the start state. The solution space of an algorithm is the set of all state sequences starting from the start state, and terminating at any of the halt states. This set is well founded at the start state. In sequential interaction, the interactive process can begin in any state of the system. While the interactive process is also a sequence of state transitions, their solution space is not well founded. Figure 2(a) shows a reactive machine that alternates between two states and accepts a bit as input and provides another bit as output. In state S0 , the machine negates the input, and in state S1 the machine reflects the input. Figure 2(b) depicts the machine as two interaction streams – one of which begins when the machine is in state S0 and the other begins when the machine is in state S1 . It can be seen that the second interaction stream can be obtained from the first, after deleting the first stream element. Similarly, the first interaction stream can be obtained by deleting the first stream element of the second
5
stream. An interactive process involving this machine can start from any of the two states. Defining the system states so as to represent system behavior, we obtain the following: S1 = (S0 ; a ! :a) and S0 = (S1 ; a ! a) where a 2 f0; 1g. Such a circular definition constitutes an infinite subsethood chain among elements of the solution space. Here, S0 is defined in terms of S1 which is defined in terms of S0 which is defined in terms of S1 , and so on. Such a data structure is called a non-well-founded set [3], first proposed by Aczel [1]. Non-well-founded sets subsume well-founded sets which do not allow infinite subset chains among its elements. Non-well-founded sets without contradictions represent consistent circular relationships, while those with contradictions in them represent paradoxes. The solution space of a sequential interaction is hence a non-well-founded set that depicts the sequential interactive behavior. For multi-stream interactions, it is necessary to also introduce channel sensitivity into a non-well-founded set representation. One way to represent channel sensitivity is to use a channel identifier for each input and output element of a stream in a non-well-founded set. Thus ip would denote input from the pth channel and oq would denote output to the q th channel. However such a representation has changed the input and output domains, and has taken channels out of the model. Another means of representing multi-stream interaction of a machine having behavior B , is to consider that a subset of B is available on each interaction channel. This can be represented by replicating B on every channel and constraining its
space by behaviors taking place on other channels. Figure 3 shows an extension of the previous example. Consider a multi-stream interaction machine that has two states, the behavior from one of which reflects the input as output; and from that of the other, negates the input as output. Also let the machine have two interaction streams. At any time, only one of the streams can utilize the machine’s behaviors. Thus, if the reflector behavior is available to the first stream, it is not available to the second stream and vice versa. The same is true for the negator behavior. The figure shows this machine as two single stream machines with a constraint holding on them that prevents, permits or necessitates certain part of the behavior on each interaction stream. If interaction stream 0 has the reflector behavior, then it is forbidden for interaction stream 1 to have the reflector behavior. If interaction stream 1 completes its negator behavior and changes to reflector mode; it is required for stream 0 to change from reflector mode to negator mode. And such a transition on the part of stream 1 is permitted if stream 0 is also ready to carry out the corresponding complementary transition. The above model can be considered to be a schema of entities and relationships, where entities depict behavioral spaces on specific interaction channels; and relationships are constraints that depict how streams affect one another. Such a schema based representation is a tentative proposal for the solution space of a MIM, and could likely change if more characteristics of multi-stream interactions (in addition to channel sensitivity) are discovered. Since multi-stream interaction has not been addressed as a separate topic by mainstream IS communities, questions like the solution space of a MIM have also gone unaddressed. The interesting aspect of MIM solution spaces is their qualititative difference from an algorithmic solution space. An algorithm maintains a subroutine relationship with its environment. This enables a collection of algorithms to be modeled in a hierarchical fashion consisting of different well defined levels of granularity. In a TM, a state transition at one level may represent a complete TM computation at a lower level. This makes TM computations at one level to be abstracted away from TM computations at other levels. Abstract State Machines [8] utilize such a property of TM computations. An interactive process on the other hand, maintains a coroutine relationship with its environment. A collection of coroutines cannot be modeled in a purely hierarchical fashion. When coroutines interact on multiple streams, hierarchies breakdown and there is no characteristic structure of the interaction space. This might perhaps be cited as the reason for the emergence of paradigms like design patterns [5, 16], that seek to identify and document recurrent characteristic structures. Figure 4 schematically depicts solution spaces of algorithmic, sequential interactive and multi-stream interactive processes.
6
4 Some Modeling Underpinnings In this section we look at a modeling paradigm that has been proposed based on the insight that IS dynamics are not reducible to algorithmic behavior. Finally a tentative proposal for a mathematical model of a MIM called a PMTM, is also proposed.
4.1 Duality Paradigm In [7] we propose a few directions towards formal underpinnings for an IS. An IS is considered to be made up of static and dynamic properties. The static properties can be manipulated algorithmically, while the dynamic aspects are interactive in nature. Hence IS design can be considered as a sum of database design and interaction modeling. The above philosophy has been adopted in the duality paradigm [17]. In this approach for IS design, an IS is divided into two abstract “spaces” of concern: the static “object space” and the dynamic “interaction space.” An object schema characterizes the object space representing static structure; and an interaction schema characterizes the interaction space representing dynamic behavior. The interaction schema is built from semantic processes called “dialogs.” Dialogs represent single stream interactive processes. Multi stream processes are represented by defining constraint relationships called “constrained association” across dialogs which show how dialogs implicitly affect the behavior of one another.
4.2 Category vs Deontic Formalisms In the duality paradigm, the system model consists of two separate schemata that represent the structure and dynamics. For an executable model, these schemata should be combined to obtain a single model that can represent the complete IS characteristics. Such a translation can be of two types – a process centric and an object centric translation. In a process centric translation processes (dialogs) have independent threads of execution, and domain objects are used only as data stores. In an object centric translation, domain objects have independent threads of execution, and processes are embedded as part of object interactions. Logical underpinnings for both kinds of translation is explored below. Category logic: A category K in category logic, is represented as 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 : A ! B . This is read as ’f is a morphism from A to B ’. A is the “source” or “domain” of f and B is its “target” or “co-domain”. 2. There is a partial function on morphisms called composition and denoted by an infix ring symbol, Æ. The ”composite” g Æ f : A ! C may be formed if g : B ! C and f : A ! B 2 mor(K ). 3. This composition is associative: h Æ (g Æ f ) = (h Æ g ) Æ f . If “objects” of a category are taken to be the system state and morphisms as dynamics between the system states, a category would hence represent a dynamic entity. Hence a dialog can be represented as a category. In order to represent constrained associations, a concept called “coproducts” is used. The coproduct of two sets A and B is a set A + B = f(0; a)(1; b)ja 2 A; b 2 B g. That is, the coproduct of two sets is the disjoint union of the set elements such that individual identities are retained. Using coproducts, we can define constrained association in two ways: (a) affirmative constraints – a set of dialog coproducts that contains all coproducts from dialog activities that are admissible as part of the constraint, everything else is forbidden; and (b) negative constraints – a set of dialog coproducts that contains all coproducts of activities that are forbidden, everything else is allowed. Affirmative or negative coproducts can be variedly applied depending on the design context. Category logic can be used to translate an interaction schema into a process centric model of an IS. Using this model, assertions and reasoning can be performed on the characteristics of overall system behavior.
7
Deontic logic: Deontic logic is the logic of normative behavior [12]. It has been used in domains like law and ethics. There have been a few applications of deontic logic in computer science. A good example is the application of speech-act theory to information system design [10]. Normative behavior is made up of constructs like permission, obligation, prohibition, etc., which in turn imply specific activities. Some example axioms of a typical deontic system are as follows: O(p)
˜P (˜p) (Obligation to p entails no permission to not p). (p ! q ) ) P (p) ! ˜F (q ) (If p leads to q, then permission should lead to no prohibition to q). F (p) ) ˜P (p) (Prohibition to p entails no permission to p). )
Deontic logic can be used for an object centric translation of a duality model. Dialogs are distributed among the domain objects they represent and constrained association is represented in the form of deontics that depict coordination between domain objects.
4.3 Persistent Multi-Turing Machine As shown earlier, a constrained association can represent a multi-stream interactive activity. It’s structure is in the form of a constraint relationship between n dialogs. A dialog represents a single stream interactive behavior, whose foundational model is a PTM [6]. This provides an insight into a mathematical model called Persistent Multi-Turing Machine (PMTM) that can represent multi-stream interaction. This would also be a mathematical model for activities like coordination, collaboration and open systems in general. A PMTM may be defined as follows: Definition: An n-P M T M is a tuple hW; P T M1 ; P T M2 ; : : : ; P T Mn i that consists a persistent, shared worktape W and n Persistent Turing Machines P T M1 : : : P T Mn . At any given time k, a PTM can start its computation. It starts computation from state Wk which is the current state of the system. A shared persistent worktape represents a global shared memory, which is the least infrastructure necessary for defining constraints between interaction streams. Coordination semantics may be encoded as part of each PTM specification. Alternatively, the PTMs in a PMTM may be Universal PTMs, which can read another PTM specification on their input and adapt their behavior according to the specification. In such a case, the PMTM would represent any information system interacting on n channels. While a TM represents what a computer can effectively compute, an n-PMTM would represent what an n-channel information system can effectively achieve. However, for the present, these claims made are to be taken as purely tentative claims.
5 Conclusions This paper introduced the notion of open systems based on the irreducibility of interaction to algorithms. While algorithms represent what computers can effectively compute, interactive paradigms represent what information systems can effectively achieve. The importance of interaction in systems design has not received adequate attention by the IS community. In the ensuing years though, it seems imperative to identify and formalize aspects of interaction that can help in better designing information systems.
8
Acknowledgments The author would like to thank his supervisors Prof. Bernhard Thalheim and Dr. Myra Spiliopoulou for all their guidance and support; and to Prof. Dina Goldin for her guidance regarding Interaction Machines.
References [1] Peter Aczel, Non Well-Founded Sets, CSLI Lecture Notes #14, Stanford, 1988. [2] Gul Agha, Ian A. Mason, Scott Smith, Carolyn Talcott. Towards a Theory of Actor Computation. Proc of CONCUR ’92, R. Cleaveland (Ed.), LNCS 630, pp. 565-579, Springer-Verlag, 1992. [3] John Barwise, Lawrence Moss. Vicious Circles: On the Mathematics of Non-Wellfounded Phenomena. CSLI Lecture Notes, No. 60. 1996. [4] Wolfram Clauß, Bernhard Thalheim. Abstraction Layered Structure Process Codesign. Proc. of COMAD ’97, Narosa Publishers, Chennai, India, 1997. [5] E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns : Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. [6] Dina Goldin. Persistent Turing Machines as a Model of Interactive Computation. Proceedings of the FoIKS 2000, Burg, Germany, Feb 2000. [7] Dina Goldin, Srinath Srinivasa, Bernhard Thalheim. IS = DBS + Interaction: Towards Principles of Information Systems. Proc. of ER 2000, Salt Lake City, USA, Oct 2000. [8] Yuri Gurevich. May 1997 Draft of the ASM Guide. Technical Report, University of Michigan EECS Department, CSETR-336-97. [9] John Hopcroft, Jeffrey Ullman. Introduction to Automata Theory, Languages and Computation, Addison-Wesley, 1979. [10] Paul Johannesson. Representation and Communication - A Speech Act Based Approach to Information Systems Design, Information Systems, vol. 20 no. 4 pp. 291 - 303, 1995. [11] Zohar Manna, Amir Pnueli. The Temporal Logic of Reactive and Concurrent Systems, Springer-Verlag 1992. [12] John-Jules Ch. Meyer, Roel J. Wieringa (Eds). Deontic Logic in Computer Science: Normative System Specification. John Wiley and Sons, 1993. [13] Dale Miller. Logical Foundations for Open System Design. ACM Computing Surveys, Vol 28, Dec 1996. [14] Gary J. Nutt. Open Systems. Prentice Hall, New Jersey, 1992. [15] 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 [16] Wolfgang Pree. Design Patterns for Object-Oriented Software Development. Addison-Wesley, 1995. [17] Srinath Srinivasa. The Notion of the Interaction Space of an Information system. Proc. of CAiSE’00 Doctoral Symposium, Stockholm, Sweden, June 2000. [18] Peter Wegner. Why Interaction is More Powerful than Algorithms? Communications of the ACM, May 1997. [19] Peter Wegner, Dina Goldin. Interaction as a Framework for Modeling. In LNCS #1565. [20] Peter Wegner, Dina Goldin. Mathematical Models of Interactive Computing. Technical Report, Brown University, Jan 1999. [21] Peter Wegner, Dina Goldin. Coinductive Models of Finite Computing Agents. Electronic Notes in Theoretical Computer Science, Vol 19, Elsevier, 1999.
9
A
A
A
B
B
C
B C D
E
D
G F
E
Algorithmic Computation
Sequential Interaction
Computable function
Multi-stream (concurrent) Interaction
Computable partial function + output-input coupling + channel sensitivity
Computable partial function + output-input coupling
(a)
(b)
(c)
Figure 1: Algorithmic and interactive computations
1/0 0/1
{
S0
{(1,0)(0,0)(0,1)(0,0)(1,0)(1,1)(0,1)...} {(0,0)(1,0)(0,0)(0,1)(1,1)(0,1)(1,1)...}
S1 0/0 1/1
}
(a)
(b) Figure 2: Streams as non-well-founded-sets S1
S1
Interface 1
Interface 0
S0
S0
Figure 3: Solution space of a MIM
Higher Level Process
11111 00000 00000 11111
Higher Level Process
1111 0000 0000 1111 Lower level processes
(a)
111111111111 000000000000 000000000000 111111111111 000000000000 111111111111 000000000000 111111111111 000000000000 111111111111 0000000000 1111111111 0000000000 1111111111 0000000000 1111111111 0000000000 1111111111 0000000000 1111111111
Lower level processes
1111111111111111 0000000000000000 0000000000000000 1111111111111111 0000000000000000 1111111111111111 0000000000000000 1111111111111111 000000000000 111111111111 000000000000 111111111111 000000000000 111111111111 000000000000 111111111111 000000000000 111111111111
(b)
(c) Hierarchy no longer holds
Figure 4: Algorithmic and Interactive Spaces
10
