Organizing Business Knowledge The Mit Process Handbook [Electronic resources] نسخه متنی

4.2 A Framework for Studying Software Component Interconnection

4.2.1 A Coordination Perspective for Representing Software Systems

One of the reasons behind the failure of today's programming languages and methodologies to recognize component interconnection as a distinct design problem is the lack of expressive means for representing interdependencies and their associated coordination protocols as distinct and separate entities from the interacting components. Therefore the first ingredient of our framework is a representation that achieves this distinction. The representation is based on the principles of coordination theory.

Coordination theory (Malone and Crowston 1994) is an emerging research area that focuses on the interdisciplinary study of coordination. One of the intended applications of coordination theory is the design and modeling of complex systems, ranging from computer systems to real-life organizations. Coordination theory views such systems as collections of interdependent processes performed by machine and/or human actors. Processes are sets of activities. Coordination theory defines coordination as the management of dependencies among activities. It makes a distinction between two orthogonal kinds of activities:

Production (or core) activities. Activities directly related to the stated goals of a system. For example, the SQL engine of a database system would qualify as a production activity in that system.

Coordination activities. Activities which do not directly relate to the stated goals of a process, but are necessary in order to manage interdependencies among production activities. Algorithms that control concurrent access in multi-user databases would be considered coordination activities under this framework.

The definitions above suggest representations in which software systems are depicted as sets of interdependent software activities. At the specification level, activities represent the core functional elements of the system while dependencies represent their interconnection relationships and constraints. At the implementation level, activities are mapped to software components that provide the intended functionality, while dependencies are mapped to coordination protocols that manage them. Figure 4.1 depicts an example of a software system specification and implementation using such a representation.

Figure 4.1: Representing a software application as a set of activities interconnected through dependencies

4.2.2 A Design Handbook for Integrating Software Components

The existence of representations that treat dependencies and coordination processes as distinct entities enable the construction of taxonomies of software interconnection problems and solutions. This section presents the beginnings of such a taxonomy. The taxonomy contains the following elements:

A catalog of the most common kinds of interconnection dependencies encountered in software systems

For each kind of dependency, a catalog of sets of alternative coordination protocols for managing it

Our taxonomy uses multidimensional design spaces to classify both dependencies and coordination protocols. It begins by identifying a small number of generic dependencies. For each generic dependency, it defines a number of design dimensions that can be used to further specialize the relationship. These dimensions form a design space that contains different specializations of the given dependency. Each point in the design space defines a different specialized dependency type.

Furthermore, for each dependency, our taxonomy identifies a few generic coordination processes that manage it. It also defines a design space that contains several related specialized versions of these coordination protocols. The dimensions of the design space are the questions the designer will have to answer in order to select one of the available coordination processes for managing a given dependency.

Overview of the Dependencies Space An important decision in making a taxonomy of software interconnection problems is the choice of the generic dependency types. If we are to treat software interconnection as an orthogonal problem to that of designing the core functional components of an application, dependencies among components should represent relationships which are also orthogonal to the functional domain of an application. Fortunately this requirement is consistent with the nature of most interconnection problems: whether our application is controlling inventory or driving a nuclear submarine, most problems related to connecting its components together are related to a relatively narrow set of concepts, such as resource flows, resource sharing, and timing dependencies. The design of associated coordination protocols involves a similarly narrow set of mechanisms such as shared events, invocation mechanisms, and communication protocols.

After making a survey of existing systems, and building on earlier results of coordination theory (Malone and Crowston 1993, 1994), we can base our taxonomy of dependencies on the assumption that component interdependencies are explicitly or implicitly related to patterns of resource production and usage. In other words, activities need to interconnect with other activities, either because they use resources produced by other activities, or because they share resources with other activities.

Based on this assumption, we include the most generic dependency families in our taxonomy:

Flow dependencies. Flow dependencies represent relationships between producers and consumers of resources. They are specialized according to the kind of resource, the number of producers, the number of consumers, and so on. Coordination protocols for managing flows decompose into protocols which ensure accessibility of the resource by the consumers, usability of the resource, as well as synchronization between producers and consumers.

Sharing dependencies. Sharing dependencies encode relationships among consumers who use the same resource or producers who produce for the same consumers. These are specialized according to the sharing properties of the resource in use (divisibility, consumability, concurrency). Coordination protocols for sharing dependencies ensure proper enforcement of the sharing properties, usually by dividing a resource among competing users, or by enforcing mutual exclusion protocols.

Timing dependencies. Timing dependencies express constraints on the relative flow of control among a set of activities. Examples include prerequisite dependencies and mutual exclusion dependencies. Timing dependencies are used to specify application-specific cooperation patterns among activities which share the same resources. They are also used in the decomposition of coordination protocols for flow and sharing dependencies.

It is not possible to complete describe the taxonomy in the limited space of this chapter. Instead, the following sections will present a small subset of the taxonomy of flow dependencies, as well as an example of how it can be used to guide the design of software interconnection protocols. A full description of the taxonomy is contained in (Dellarocas 1996).

A Taxonomy of Flow Dependencies Flow dependencies encode relationships among producers and consumers of resources. This section presents a generic model for classifying flow dependencies and a framework for designing coordination protocols for such dependencies. The framework is based on some results of coordination theory, extended and adapted for the field of software components.

Malone and Crowston (1994) have observed that whenever flows occur, one or more of the following subdependencies are present:

Usability. Users of a resource must be able to effectively use the resource.

Accessibility. In order for a resource to be used by an activity, it must be accessible to that activity.

Prerequisite. A resource can only be used after it has been produced.

The following paragraphs will introduce dependency and coordination process design spaces for each of the lower-level dependencies. The design space for generalized flow dependencies is defined by the product of the design spaces of the component dependencies.

USABILITY DEPENDENCIES Usability dependencies state the fact that resource users should be able to properly use produced resources. This is a very general requirement that encompasses some compatibility issues:

Data type compatibility

Format compatibility

Database schema compatibility

Device driver compatibility

The exact meaning and range of usability considerations varies with each kind of resource. One interesting observation resulting from this work is that regardless of the particular usability issue being managed, coordination alternatives for managing usability dependencies can be classified using the design dimensions listed in table 4.1.

ACCESSIBILITY DEPENDENCIES Accessibility dependencies specify that a resource must be accessible to a user before it can be used. Since users are software activities, accessibility specifies more accurately that a resource must be accessible to the pro cess that executes a user activity before it can be used. Important parameters in specifying accessibility dependencies are the number of producers, the number of users, and the resource kind.

There are two broad alternatives for making resources accessible to their users (tables 4.2 and 4.3):

Place producers and users ''close together.' '

Transport resources from producers to users.

Depending on the type of resource being transferred, either or both alternatives might be needed. Placing producer and user activities ''close''to one another generally decreases the cost of transporting the resource. Combinations of placing activities and transporting resources should be considered in situations where the cost of placing the activities is lower than the corresponding gain in the cost of transporting the resource.

PREREQUISITE DEPENDENCIES A fundamental requirement in every resource flow is that a resource must be produced before it can be used. This is captured by including a prerequisite dependency in the decomposition of every flow dependency.

Prerequisite dependencies can be further classified according to:

Number of precedent activities

Number of consequent activities

Relationship (and/or) among the precedent activities

In And-prerequisites, all activities in the precedent set must occur before activities in the consequent set can begin execution. By contrast, in Or-prerequisites, occurrence of at least one activity in the precedent set satisfies the prerequisite requirement.

Table 4.4 shows four generic processes for managing prerequisite dependencies. Each generic process can be further specialized according to a number of design dimensions specific to the process. For example, peer synchronization can be specialized according to the type of event used for synchronization. Table 4.5 contains a partial list of events. For each event, different execution environments provide different sets of corresponding system calls, providing yet another level of protocol specialization.

Figure 4.2: A simple software system

Designing Interconnection Protocols This section will provide an example of how the framework can be used to guide the design of interconnection protocols among software components. Because only a small subset of the taxonomy is presented in this chapter, the example will also, by necessity, be very simple.

Suppose that we need to connect two existing pieces of code: a C program providing a graphical interface that repeatedly asks the user for part numbers, and a Visual Basic program that queries a database and displays descriptions of the corresponding parts. The C program returns integer part numbers while the Visual Basic program expects strings. Figure 4.2 shows the components and their interconnection relationship, in this case a simple data flow.

According to our framework, in order to interconnect the two components, we need to design a coordination protocol for the data flow dependency. Following our generic model for flows, this means that we have to design protocols for managing usability, accessibility, and prerequisite dependencies.

To manage usability, we elect that the producer will be responsible for making the data usable to the consumer (see table 4.1). In this example this will require the addition of code at the C component for converting data from integers to strings.

To manage accessibility, we first preclude the possibility of integrating the two components in the same executable, because they are written in different languages.

We therefore have to transport the data from producer to consumer. Our framework provides a set of possibilities for doing this.

One possibility would be to use an RPC protocol to transmit the data from producer to consumer. DDE (dynamic data exchange) is one such protocol supported by Microsoft Windows. The advantage of such a protocol is that it explicitly passes control from producer to consumer, thus managing the prerequisite dependency as well. The resulting protocol is depicted in figure 4.3. In this protocol, the C component acts as a client, while the Visual Basic component is wrapped inside a handler for a DDE call and acts as a server.

Another possibility would be to use a shared memory location or a shared file, whose filename is fixed in advance and known to both parties. This solution would require us to address the prerequisite relationship separately: Make sure that the Visual Basic program only reads the next part number after it has been written by the C program. We select a peer synchronization mechanism specialized to use semaphores as the synchronization event. Finally, as shared memory locations are best for storing numbers, conversion from integers to strings is done at the consumer side. Our choices result in the protocol depicted in figure 4.4. Notice that, in this protocol, the two components are eventually wrapped in two executables that run independently and synchronize implicitly.^[1]

In conclusion, our framework not only can guide the design of interconnection protocols in a systematic way but also point out the range of alternatives available to the designer at each step.

figure 4.3 allows more than one part numbers to be generated before one of them is displayed. In this application such behavior would most likely not be acceptable. Dellarocas (1996) contains a taxonomy of different variations of prerequisite dependencies and corresponding coordination protocols that would give a fully satisfactory solution to this problem.