Software Component Interconnection Should Be Treated as a Distinct Design Problem

Chrysanthos Dellarocas

Sloan School of Management
Massachusetts Institute of Technology
Room E53-315, Cambridge, MA 02139
Tel: (617) 258-8115
Fax: (617) 258-7579
Email: dell@mit.edu

Abstract:

As the size and complexity of software systems grows, the identification and proper management of interconnections among the pieces of the system becomes a central concern. Nevertheless, many programming languages and tools today still place an emphasis on representing components, leaving the description and management of component interdependencies implicit, or distributed among the components. This paper claims that this expressive shortcoming is one important factor that impedes wide-spread software reuse. It proposes a new perspective for designing software which elevates the representation and management of software component interdependencies to a distinct design problem, orthogonal to that of representing and implementing the core functional pieces of an application. The perspective calls for software description languages with clear distinctions between software components and their interconnection dependencies. It also calls for systematic taxonomies of software interconnection dependencies and sets of alternative protocols for managing them. SYNTHESIS, a prototype software application development tool based on that perspective has been developed and used in order to minimize the manual effort required to integrate independently developed components into new applications.

Keywords: component-based software development, software interconnection, software architecture, reuse, coordination protocol

Workshop Goals: Learning; networking; advance state of theory and practice of component-based software development

Working Groups: Rigorous Behavioral Specification as an Aid to Reuse, Domain Engineering Tools.

Background

One of the principal goals of my research at MIT's Center for Coordination Science is to develop new theories, methodologies and tools, specifically designed for component-based software development. My interest is to develop general theories and techniques that facilitate the reuse of independently designed components. Therefore, my work contrasts with component frameworks (such as OLE and CORBA) that define specifications to which all components have to adhere in order to be reusable. I am also member of the Process Handbook project [2, 6], which aims to build better tools for visualizing, designing and reusing business processes. A crucial part of both projects is an emphasis on developing semi-formal taxonomies of software and business processes respectively, as well as a focus on the practical applicability of our methodologies in real-life, large-scale organizations.

Position

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

Nevertheless, 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 source and executable 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 invocation, shared variables, etc. Such mechanisms are not sufficient 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 complex protocols, such programming languages force programmers to distribute and embed them inside the interacting components [8]. 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 implementing them. The failure of many current languages and tools to recognize software component interconnection as a distinct design problem 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 im plicitly connected through defines/uses relationships).
•  Difficulties 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 or modify a protocol, programmers have to look at many places in the program.
•  Difficulties 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 [3]. In many cases this requires extensive code modifications or the introduction of additional code around the component. Up until now, in most cases such modifications are being handled in an ad-hoc manner.

Motivated by the previous observations this paper claims that large-scale component-based software development will be greatly assisted by new methodologies and to ols which treat the interconnection of software components into new applications as a distinct design problem, entitled to its own representations and design frameworks. More specifically, such methodologies and tools should be based on the following two principles:

Explicitly represent software dependencies.

One of the reasons behind the failure of many 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 principle of our perspective is the need for a representation that achieves this distinction. One such representation can be based on the principles of coordination theory.

Coordination theory [7] is an emerging research area that focuses on the interdisciplinary study of coordination. One of the intended applications of coordination theory is in the design and modeling of complex systems, ranging from computer systems to organizational processes [2, 6]. 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 above definitions 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.

Build design handbooks of dependencies and coordination protocols.

The existence of representations that treat dependencies and coordination protocols as distinct entities enables the construction of taxonomies of software interconnection problems and solutions. Such taxonomies will contain catalogs of the most common kinds of interconnection dependencies encountered in software systems. For each kind of dependency, they will catalogue sets of alternative coordination protocols for managing it. The development of such taxonomies will help transform the problem of integrating existing software components into new applications from an ad-hoc endeavor to a systematic design activity. In that sense, they will play a role similar to that of the well-established design handbooks that assist design in more mature engineering disciplines.

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, we have based our initial taxonomy of dependencies on the assumption that component interdependencies are explicitly or implicitly related to patterns of resource production and usage. Based on this assumption, the most generic dependency families in our initial taxonomy include:

• Flow dependencies. Flow dependencies represent relationships between producers and consumers of resources. 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. They encode relationships among consumers who use the same resource or producers who produce for the same consumers. 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.

 

 

The above dependency families should be considered as a ``vocabulary'' of elementary software interconnection relationships. One of the aims of our future research is to discover interesting complex interconnection relationships occurring in software systems and to represent them as patterns of more elementary dependency types.

The SYNTHESIS Application Development Environment

In order to test the validity of the ideas outlined in this paper we developed SYNTHESIS, an application development environment based on the principles of our coordination perspective. SYNTHESIS provides a software architecture description language (ADL) that supports separate language entities for representing software activities and dependencies. In addition, it contains our initial taxonomy of software dependencies and coordination protocols, organized in an on-line repository of increasingly specialized objects. Finally, it provides a design assistant that uses the on-line repository of coordination protocols in order to semi-automate the integration of existing software components into new applications. Reference [1] contains a detailed description of the SYNTHESIS system, our initial taxonomy of dependencies and coordination protocols and all experiments we performed in order to validate its practical usefulness.

Comparison

Architecture Description Languages

Several Architecture Description Languages (ADLs) provide support for representing software systems in terms of their components and their interconnections [4]. Different languages define interconnections in different ways. For example, Rapide [5] connections are mappings from services required by one component to services provided by another component. Unicon [9] connectors define protocols that are inserted into the system in order to integrate a set of components. In that sense they are similar to the coordination protocols that manage dependencies in SYNTHESIS. Like Unicon, SYNTHESIS views dependencies as relationships among components which might require the introduction of additional coordination code in order to be properly managed. Unlike Unicon, however, SYNTHESIS dependencies are specifications which can then be managed (i.e. implemented) in a number of different ways. The set of dependency types is not fixed. Coordination theory is a framework that assists the discovery of additional dependency types and coordination protocols. Finally, apart from simply supporting dependency abstractions, the work reported in this paper proposes the development of taxonomies of abstract dependency relationships and coordination protocols for managing them as a key element in facilitating component-based software development.

Component Frameworks

Component frameworks such as OLE, CORBA, OpenDoc, etc. and our coordination perspective were both motivated by the complexity of managing component interdependencies. However, the two approaches represent very different philosophies. Component frameworks enable the interoperation of independently developed components by limiting the kinds of allowed relationships and by providing a standardized infrastructure for managing them. Only components explicitly written for a framework can interoperate with one another.

Our coordination perspective, in contrast, is based on the belief that the identification and management of software dependencies should be elevated to a design problem in its own right. Therefore, dependencies should not only be explicitly represented as distinct entities, but furthermore, when deciding on a managing protocol, the full range of possibilities should be considered with the help of design handbooks. Components in SYNTHESIS architectures need not adhere to any standard and can have arbitrary interfaces. Provided that the right coordination protocol exists in its repository, a system like SYNTHESIS will be able to interconnect them. Furthermore, SYNTHESIS is able to suggest several alternative ways of managing an interconnection relationship and thus possibly generate more efficient implementations. Finally, interconnection protocols defined in specific component frameworks can be incorporated into SYNTHESIS repositories as one additional way of managing the underlying dependency relationships.

References

1. Chrysanthos Dellarocas. A Coordination Perspective on Software Architecture: Towards a Design Handbook for Integrating Software Components (Ph.D. Thesis). MIT Center for Coordination Science Working Paper 193, February 1996.
2.  C. Dellarocas, J. Lee, T. W. Malone, K. Crowston and B. Pentland. Using a Process Handbook to Design Organizational Processes. In Proceedings, AAAI Spring Symposium on Computational Organization Design, March 21-23, 1994, Stanford, CA, pp. 50-56.
3.  D. Garlan, R. Allen and J. Ockerbloom. Architectural Mismatch or Why it's hard to build systems out of existing parts. In Proceedings, 17th International Conference on Software Engineering, Seattle WA, April 1995.
4.  Paul Kogut and Paul Clements. Features of Architecture Representation Languages. Carnegie Mellon University Technical Report CMU/SEI. Number to be assigned. Draft of December 1994.
5.  David C. Luckham and James Vera. An Event-Based Architecture Definition Language. IEEE Transactions on Software Engineering, Vol 21, No 9, Sep. 1995, pp. 717-734.
6.  T.W. Malone, K. Crowston, J. Lee and B. Pentland. Tools for Inventing Organizations: Toward a Handbook of Organizational Processes, In Proceedings, 2nd IEEE Workshop on Enabling Tech. Infrastructure for Collaborative Enterprises, April 20-22, 1993.
7.  Thomas W. Malone and Kevin Crowston. The Interdisciplinary Study of Coordination. ACM Computing Surveys, Vol. 26, No. 1, March 1994, pp 87-119.
8.  Mary Shaw. Procedure Calls Are the Assembly Language of Software Interconnection: Connectors Deserve First-Class Status. Carnegie Mellon University, Technical Report CMU-CS-94-107, January 1994.
9.  Mary Shaw, Robert DeLine, and Daniel Klein. Abstractions for Software Architecture and Tools to Support Them. IEEE Transactions on Software Engineering 21, 4, April 1995, pp. 314-335.

 

 

Biography

Chrysanthos Dellarocas is an Assistant Professor of Management and Information Technology at MIT's Sloan School of Management. His research focuses on designing CASE tools and methodologies for component-based software development. He is also interested in business engineering tools that assist managers better understand and improve their organizational processes. One of the goals of his research is the use of easy-to-understand, intuitive process models to drive the configuration and generation of enterprise-wide software solutions. He received his Diploma of Electrical Engineering at the National Technical University of Athens, and his M.S. and Ph.D in Computer Science from MIT. He has also worked as a Consultant for Andersen Consulting.