Chapter 4: Toward a Design Handbook for Integrating Software Components - Organizing Business Knowledge The Mit Process Handbook [Electronic resources] نسخه متنی

Chapter 4: Toward a Design Handbook for Integrating Software Components

Chrysanthos Dellarocas

An earlier version of this chapter appeared as C. Dellarocas (1997), Towards a design handbook for integrating software components, Proceedings of the 5th International Symposium on Assessment of Software Tools (SAST'97), Pittsburgh, PA, June 2-5, 1997, pages 3-13. 1994 IEEE. Reprinted by permission.

4.1 Motivation

As the size and complexity of software systems grows, the identification and proper management of interconnection dependencies among various pieces of a system has become responsible for an increasingly important part of the development effort. In today's large systems, the variety of encountered interconnection dependencies (e.g., communication, data translation, resource sharing, and synchronization dependencies) is very large, while the complexity of protocols for managing them can be very high.

Dependencies among software components are especially important in component-based software development. In this case, the core functional elements of an application are implemented using off-the-shelf components. The focus of the design effort then lies in integrating these components by identifying and properly managing their interdependencies and mismatches. The practical diffculty of achieving widespread software reuse is a manifestation of the fact that component integration is not a trivial problem. Nevertheless, most current programming languages and tools have so far failed to recognize component interconnection as a distinct design problem that should be separated from the specification and implementation of the underlying components.

The distinct nature and equal importance of components and dependencies is captured relatively well in high-level, architectural descriptions of systems. In such descriptions components are typically depicted using boxes and dependencies using arrows. However, at that level of description dependencies are usually informal artifacts and their exact translation into implementation-level concepts is not obvious.

As design moves closer to implementation, current design and programming tools increasingly focus on components, leaving the description of interdependencies among components implicit, and the implementation of protocols for managing them fragmented and distributed in various parts of the system. At the implementation level, software systems are sets of modules in one or more programming languages. Although modules come under a variety of names (procedures, packages, objects, clusters, etc.), they are all essentially abstractions for components.

Most programming languages directly support a small set of primitive interconnection mechanisms, such as procedure calls, method invocations, and shared variables. Such mechanisms are not suffcient for managing more complex dependencies that are commonplace in today's software systems. Complex dependencies require the introduction of more complex managing protocols, typically comprising several lines of code. By failing to support separate abstractions for representing such complex protocols, current programming languages force programmers to distribute and embed them inside the interacting components (Shaw et al. 1995). Furthermore the lack of means for representing dependencies and protocols for managing them has resulted in a corresponding lack of theories and systematic taxonomies of interconnection relationships and ways of managing them.

This expressive shortcoming of current languages and tools is directly connected to a number of practical problems in software design:

Discontinuity between architectural and implementation models. There is currently a gap between architectural representations of software systems (sets of activities explicitly connected through rich vocabularies of informal relationships) and implementation-level descriptions of the same systems (sets of modules implicitly connected through defines/uses relationships).

Diffculties in application maintenance. By not providing abstractions for localizing information about dependencies, current languages force programmers to distribute managing protocols in a number of different places inside a program. Therefore, in order to understand a protocol, programmers have to look at many places in the program. Likewise, in order to replace a protocol, modifications must be made in many different modules.

Diffculties in component reuse. Components written in today's programming languages inevitably contain some fragments of coordination protocols from their original development environments. Such fragments act as (often undocumented) assumptions about the structure of the application where such components will be used. When attempting to reuse such a component in a new environment, such assumptions might not match the interdependency patterns of the target application. In order to ensure interoperability, the original assumptions then have to be identified, and subsequently replaced or bridged with the valid assumptions for the target application (Garlan et al. 1994). In many cases this requires extensive code modifications or the introduction of additional code around the component. In most cases such modifications are designed and implemented in an ad hoc manner.

Based on the previous observations this chapter claims that if we are to achieve large-scale component-based software development, we need new methodologies and tools that treat the interconnection of software components into new applications as a distinct design problem, entitled to its own representations and design frameworks. Such methodologies will be based on theories of component interconnection that organize and systematize the existing knowledge in the field of component integration, as well as facilitate the creation of new knowledge in the field.

To this end, section 4.2 proposes a framework for studying software component interconnection. The framework is based on software system representations that provide distinct abstractions for components and their interdependencies. Such representations allow the systematic classification of different kinds of dependencies and associated coordination protocols into design handbooks of component integration, similar to the well-established handbooks that assist design in more mature engineering disciplines. Section 4.3 briefly reports on SYNTHESIS, a component-based software development environment based on our framework. Section 4.4 discusses related work. Finally, section 4.5 sums up the conclusions and presents some directions for future research.