Chapter 18: A Coordination Perspective on Software System Design - Organizing Business Knowledge The Mit Process Handbook [Electronic resources] نسخه متنی

Chapter 18: A Coordination Perspective on Software System Design

Chrysanthos Dellarocas

An earlier version of this chapter appeared as C. Dellarocas (1997), A coordination perspective on software system design, Proceedings of the Ninth International Conference on Software Engineering and Knowledge Engineering (SEKE'97), Madrid, June 17-20, 1997, pp. 569-78. 1997 Knowledge Systems Institute. Reprinted by permission.

18.1 Introduction

In large software systems the identification and proper management of interconnection relationships and constraints among various pieces of a system has become responsible for an increasingly important part of the development effort. In many cases the design, testing, and maintenance of protocols for managing communication, resource sharing, synchronization, and other such interconnection relationships take far more time and effort than the development of the core functional pieces of an application. In this chapter we use the term dependencies to refer to interconnection relationships and constraints among components of a software system.

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, 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 (e.g., the existence of a shared resource dependency might require a distributed mutual exclusion protocol). 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. 1994) (figure 18.1). 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.

Figure 18.1: Implementation languages often force the distribution of coordination protocols among several code modules. In this example the implementation code of a pipe protocol for managing a single data flow dependency has been distributed among three code modules.

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 the protocols for managing them 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.

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 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. In many cases this requires extensive code modifications or the introduction of additional code around the component.

As a response to these problems, we introduce the principles of our coordination perspective on software system design. Following that, we describe SYNTHESIS,a prototype software development environment that embodies the principles of the coordination perspective. We present our experience with using SYNTHESIS to facilitate software reuse. We discuss related work, describe some future directions of the project, and conclude with a summary of our findings.