Figure 1: Interoperation Matrix
Johannes Sametinger
Johannes Kepler University
CD Laboratory for Software Engineering
Institut für Wirtschaftsinformatik
A-4040 Linz, Austria
E-mail:
sam@swe.uni-linz.ac.at
Tel: ++43-732-2468-9435
Fax: ++43-732-2468-9430
A variety of component types can be reused. Yet different composition techniques and different forms of interoperation of components make reuse difficult or impossible in many situations. We briefly introduce components and component composition. Then we describe forms of interoperation. We propose a classification by introducing an interoperation matrix where we consider control and data aspects of interoperation and distinguish among sixteen different forms of interoperation.
Keywords: software components, software composition, software interoperation, component taxonomy, software reuse
Workshop Goals: discussiondefinition of componentcompositioninteroperation
Working Groups: component certification tools, frameworks and processes; domain engineering tools
The author's main research interests include software engineering, software maintenance, software documentation, object-oriented programming, component-oriented programming, and software reuse. Results in the area of reuse include a proposal for reuse documentation [1], a method for documentation reuse [2, 3], a measure for ad-hoc reuse [4], a contribution on a component taxonomy [5], and empirical studies on reuse [4, 6].
Software components are self-contained, clearly identifiable pieces that describe and/or perform specific functions. This is a broad and general definition. We can have a variety of components like functions, classes, applications, subsystems, design documents, distributed processes, Ada packages, etc. We cannot necessarily reuse any of these components in a given reuse context. A classification system is important to assign components to specific categories and to limit component retrieval to categories appropriate in a certain context.
Constructing software systems from software components is called software composition. Composable software has a higher degree of flexibility than monolithic software. Different languages and environments realize software composition to different degrees and support different notions of components and compositions. Component-oriented software development requires that we have a selection of reusable components that are plug-compatible. No general model of software composition exists yet [7].
If two components interoperate, we have a sending component (initiating the interoperation) and a receiving component. The sending component activates the receiving component and passes control to it. The receiving component reacts to the control input; it performs some action and, depending on whether communication is synchronous or asynchronous, returns control to the sending component. Some amount of information is usually passed along with interoperation. If more extensive data exchange is needed, components may use another component for that purpose.
The receiving component may or may not be known to the sending component. This has a major influence on the flexibility of compositions. Interconnection can be between two components (peer-to-peer), to a fixed set of components (multicast), or to a dynamic set of components (broadcast). Static interconnections are peer-to-peer. Dynamic interconnections can be either peer-to-peer, multicast or broadcast. The data component also may or may not be known to both the sender and receiver of interoperation. Fig. 1 gives an overview of the categories resulting from these distinctions. We distinguish no, static, dynamic and broadcast for control and data, which leads to sixteen categories. Some forms of interoperation in this table seem somewhat exotic, for example, the combination no control and dynamic data. However, they do have practical applications.
Figure 1: Interoperation Matrix
For software reuse it is essential that components can be composed without having to know each other. This allows component composition without modifying components (dynamic control). For example, a function calls a sort function. In order to call a function shellsort instead, the program text in the calling function has to be modified. Object-oriented programming provides more flexibility through dynamic binding; a calling object does not know the receiver of a call. This makes this object work with a variety of other objects without being modified. Component composition is easiest and most flexible when interconnections among components are not point-to-point. Reusing components is easy in environments where each component can react to events generated by any other components and create new events without being aware of any recipients.
Standardized interoperation mechanisms of components on different levels of complexity and granularity are important for software reuse. We must also increase interchangeability of components beyond programming language boundaries and benefit from the availability of different programming paradigms.
Several definitions of components and reusable components have been provided in the literature. We distinguish two approaches. Components can be seen as some part of a software system that is identifiable and reusable; functions and classes are examples of such components. Components can also be seen as the next level of abstraction after functions, modules and classes. The term component-oriented programming (as a successor to object-oriented programming) is used in this context.
Examples of definitions in the former category have been proposed by Booch [8], by Holibaugh et al [9], by Nierstrasz and Dami [10], in the NATO Standard for the Development of Reusable Software Components [11], by Wegner [12], etc. The definitions are more or less general. Szypersky provides an example of the latter category. He sees component-oriented programming as a refined variation of object-oriented programming [13]. Without explicitly defining a component, Szypersky considers information hiding, polymorphism, late binding, and safety as crucial aspects for component-oriented programming.
Categories of components have also been suggested by Booch, Holibaugh, Nierstrasz, etc. Additional taxonomies have been proposed by Margono and Berard (a modification of Booch's taxonomy) [14], by Bradford Kain [15], by McGregor et al. [16], and by Dusink and van Katwijk [17]. The presented component taxonomies were created in different contexts and with different motivations. Many concentrate on source code and do not consider higher levels of abstractions.
Component types strongly influence how they are composed. Functional composition and object-oriented composition are typical for functions and classes. Nierstrasz and Dami make a distinction among functional composition, blackboard composition and composition by extension [10] and among macro expansion, high order functional composition and binding of communication channels [7]. In the literature the terms composition and interoperation are mostly used interchangeably.
Johannes Sametinger is assistant professor at the Johannes Kepler University in Linz, Austria. His research interests include software engineering, software documentation, software maintenance, software reuse, object-oriented programming, and programming environments. He was a visiting researcher at Texas A&M University and at Brown University for one year each in 1995 and 1996, respectively. He received a Ph.D. in 1991 in computer science from the Johannes Kepler University. Dr. Sametinger has also worked with Siemens in Germany on the development of compilers and programming environments.