C e n t r u m v o o r W i s k u n d e e n I n f o r m a t i c a Abstract behavior types: a foundation model for components and their composition The notion of Abstract Data Type (ADT) has served as a foundation model for structured and object oriented programming for some thirty years. The current trend in software engineering toward component based systems requires a foundation model as well. The most basic inherent property of an ADT, i.e., that it provides a set of operations, subverts some highly desirable properties in emerging formal models for components that are based on the object oriented paradigm. We introduce the notion of Abstract Behavior Type (ABT) as a higher-level alternative to ADT and propose it as a proper foundation model for both components and their composition. An ABT defines an abstract behavior as a relation among a set of timed-data-streams, without specifying any detail about the operations that may be used to implement such behavior or the data types it may manipulate for its realization. The ABT model supports a much looser coupling than is possible with the ADT's operational interface, and is inherently amenable to exogenous coordination. We propose that both of these are highly desirable, if not essential, properties for models of components and their composition. To demonstrate the utility of the ABT model, we describe Reo: an exogenous coordination language for compositional construction of component connectors based on a calculus of channels. We show the expressive power of Reo, and the applicability of ABT, through a number of examples.  An Abstract Data Type (ADT) defines an algebra of operations with mathematically well-defined semantics, without specifying any detail about the implementation of those operations or the data structures they operate on to realize them. As such, ADT is a powerful abstraction and encapsulation mechanism that groups data together with their related operations into logically coherent and loosely-dependent entities, such as objects, yielding better structured programs. ADT has served as a foundation model for structured and object oriented programming for some thirty years. The immense success of object oriented techniques has distracted proper attention away from critical evaluation of some of its underpinning concepts from the perspective of their utility for components. We propose that the most basic inherent property of an ADT, i.e., that it provides a set of operations in its interface, subverts some highly desirable properties in emerging models for component based systems. This is already evident in the current attempts at extending the object oriented models into the realm of components (see, e.g., Sections 3 and 5). We introduce the notion of Abstract Behavior Type (ABT) as a higher-level alternative to ADT and propose it as a proper foundation model for both components and their composition. An ABT defines an abstract behavior as a relation among a set of timed-data-streams, without specifying any detail about the operations that may be used to implement such behavior or the data types it may manipulate for its realization. In contrast with the algebraic underpinnings of the ADT model, 1 the (generally) infinite streams that are the elements of behavior in the ABT model naturally lend themselves to the coalgebraic techniques and the coinduction reasoning principle that have recently been developed as a general theory to describe the behavior of dynamic systems. The ABT model supports a much looser coupling than is possible with ADT and is inherently amenable to exogenous coordination. We propose that both of these are highly desirable, if not essential, properties for components and their composition. In our view, a component based system consists of component instances and their connectors (i.e., the "glue code"), both of which are uniformly modeled as ABTs. Indeed, the only distinction between a component and a connector is just that a component is an atomic ABT whose internal structure is unknown, whereas a connector is known to be an ABT that is itself composed out of other ABTs. As a concrete instance of the application of the ABT model, we describe Reo: an exogenous coordination model wherein complex coordinators, called "connectors" are compositionally built out of simpler ones [3, 4] . Reo can be used as a glue language for compositional construction of connectors that orchestrate component instances in a component based system. We demonstrate the surprisingly expressive power of ABT composition in Reo through a number of examples. The rest of this paper is organized as follows. In Section 2 we motivate our view of components and their composition as a conceptual model at a higher level of abstraction than objects and their composition. Section 3 contains a brief overview of some related work. We review the formal notion of abstract data types in Section 4, and elaborate on its links with and implications on object oriented programming in Section 5. We argue that some of these implications impede the ability of component models based on the object oriented paradigm to support flexible composition and exogenous coordination, both of which, we propose, are highly desirable properties in component based systems. Section 6 is an informal description of our component model, and in Section 7 we describe its accompanying model of behavior. Section 8 is an introduction to Abstract Behavior Types and their composition. In Section 9 we show how channels, connectors, and their composition in Reo are easily expressed as ABTs and their composition. Finally, we close with our concluding remarks in Section 10. The bulk of the work on component based systems is primarily focused on what components are and how they are to be constructed. Relatively little attention has been paid to alternative models and languages for composing components into (sub)systems, which is typically considered to be the purpose of the so-called glue code, assumed to be written in some scripting language. Clearly, components and their composition are not independent of one another: explicitly emphasizing one defines or at least constrains the other as well, if only implicitly. A conspicuous driving force behind the upsurge of interest and activity in component based software is the recognition that the object oriented paradigm is not the silver-bullet that some of its over-zealous advocates purported it to be. Nevertheless, presently, the dominant view of what components are or should be reflects a prominent object oriented legacy: components are fortified collections of classes and/or objects, with very similar interfaces. It follows that the interactions among and the composition of components must use mechanisms very similar to those for interactions among and composition of classes and objects. Thus, the method invocation semantics of message passing in object oriented programming becomes the crux of the component composition mechanisms in scripting languages. This approach to components "solves" some of the problems that are rooted in the inadequacies of the object oriented paradigm simply by shifting them elsewhere. For instance, the relatively tight coupling that must be established between a caller and a callee pair of objects indeed disappears as a concern at the intra-component level when the two objects reside in different component instances, but becomes an issue to be addressed in the glue code and its underlying middleware used to compose those components. As long as components and their interfaces are essentially the same as objects and their interfaces, the (scripting) programs that constitute the glue code end up to be inherently no different than other object oriented software. In complex systems, the body of such specialized glue code can itself grow in size, complexity, intricacy, fragility, and rigidity, 2 rendering the system hard to evolve and maintain, in spite of the fact that this inflexible code wraps and connects otherwise reusable, upgradeable, and replaceable components. An alternative view of components emerges if we momentarily ignore how they are made or even what they are made of, emphasizing instead what we want to do with them. Beyond fashionable jargon, hype, and merely technical idiosyncrasies, if there is to be any conceptual substance behind the term "component" deserving its minting, it must be that components are less interdependent and are easier and more flexible to compose than objects and classes. The definition of a class or an object specifies the methods it offers to other entities, and the method calls within the code of its methods determine the services and entities it requires to work. This results in a rather tight semantic interdependence among objects/classes and grants each individual a significant degree of control over precisely how it is composed with other classes or objects. In contrast to objects and classes, it is highly desirable for components to be semantically independent of one another and internally impose no restrictions on the other components they compose with. This yields a level of composition flexibility that is not possible with objects and classes 1 and which is a prerequisite for another highly desirable property in component based systems: we would like for the whole (system) to be more than the mere sum of its (component) parts. This implies that not only it should be generally possible to produce different systems by composing the same set of components in different ways, but also that the difference between two systems composed out of the same set of components (i.e., the difference between the "more" than the "sum of the parts" in each system) must arise out of the actual rules that comprise their two different compositions, i.e., their glue code. The significance of the latter point is that it requires the glue code to contribute to the semantics of the whole system well beyond the mere so-called "wiring-standard-level" support provided by the current popular middleware and component based technologies. On the other hand, we intuitively expect glue code to be void of any application-domain specific functionality: its job is merely to connect components, facilitating their communication and coordinating their interactions, not to perform any application-domain specific computation. This leads to a subtlety regarding the interaction between glue code and components which fundamentally impacts both. If the contribution of the glue code to the behavior of a composed system is no more than connecting its components, facilitating their communication and coordinating their interactions, then the difference between the behavior of two systems composed out of the same set of components can arise not out of any application-domain specific computation (and certainly not out of the components), but only out of how the glue code connects and coordinates these components to interact with one another. Since glue code is external to the components it connects, this implies that (1) the components must be amenable to external coordination control and (2) the glue code must contain constructs to provide such external coordination. The first implication constrains the mechanisms through which components can interact with their environment. The second implication means that the glue code language must incorporate an exogenous coordination model [2] . Finally, if glue code is to have its own non-trivial semantics in a composed system, it is highly desirable both for the glue code itself to be piece-wise explicitly identifiable, and for the semantics of each of its pieces to be independent of the semantics of the specific components that it composes. This promotes the recognition of the glue code as an identifiable, valuable software commodity, emphasizes the importance of its reusability, and advocates glue code construction through composition of reusable glue code pieces. The notion of compositional construction of glue code out of smaller, reusable pieces of glue code all but eliminates the conceptual distinctions between components and glue code. This behooves us to find conceptual models and formal methods for component based systems wherein the same rules for compositional construction indiscriminately apply to both components as well as their glue code connectors. In such a model, the (perhaps somewhat subjective) distinction between components and their (pieces of glue code) connectors still makes practical sense: although they are indistinguishable when used as primitives to compose more complex constructs, components and connectors are still different in that components are black-box primitives whose internal structures
Based on the same observations about the importance of studying glue as a first-class notion, Abstract Behavior Types (ABM) were proposed in REF guiding the design of the Reo language.
Abstract behavior types: A foundation model for components and their composition
SCIENCE OF COMPUTER PROGRAMMING
Computer Science