لطفا منتظر باشید ...
18.5 Related Work
The ideas expressed in this work are most closely related to research in coordination theory and architecture description languages. Recent efforts to build open software architectures are an interesting, but contrasting, approach for achieving many of the goals of our coordination perspective on software system design. This section briefly discusses all three research areas.
18.5.1 Coordination Theory
Coordination theory (Malone and Crowston 1994) focuses on the interdisciplinary study of coordination. Research in this area uses and extends ideas about coordination from disciplines such as computer science, organization theory, operations research, economics, linguistics, and psychology. It defines coordination as the process of managing dependencies among activities. Its research agenda includes characterizing different kinds of dependencies and identifying the coordination protocols that can be used to manage them.The present work can be viewed as an application and extension of coordination theory, in that it views the process of developing applications as one of specifying architectures in which patterns of dependencies among software activities are eventually managed by coordination protocols. The project grew out of the Process Handbook project (Dellarocas et al. 1994; Malone et al. 1993) which applies the ideas of coordination theory to the representation and design of business processes. The goal of the Process Handbook project is to provide a firmer theoretical and empirical foundation for such tasks as enterprise modeling, enterprise integration, and process re-engineering. The project includes (1) collecting examples of how different organizations perform similar processes and (2) representing these examples in an on-line ''Process Handbook''that includes the relative advantages of the alternatives.The Process Handbook relies on a representation of business processes that distinguishes between activities and dependencies and supports entity specialization. It builds repositories of alternative ways of performing specific business functions, represented at various levels of abstraction. SYNOPSIS has borrowed the ideas of separating activities from dependencies and the notion of entity specialization from the Process Handbook. It is especially concerned with (1) refining the process representation, so that it can describe software applications at a level precise enough for code generation to take place, and (2) populating repositories of dependencies and coordination protocols for the specialized domain of software systems.
18.5.2 Architecture Description Languages
Several Architecture Description Languages (ADLs) provide support for representing software systems in terms of their components and their interconnections (Kogut and Clements 1994). Different languages define interconnections in different ways. For example, Rapide (Luckham and Vera 1995) connections are mappings from services required by one component to services provided by another component. Unicon (Shaw et al. 1995) 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 that might require the introduction of additional coordination code in order to be properly managed. Unlike Unicon, however, SYNTHESIS dependencies are specifications that 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 representations, the work reported in this chapter 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.
18.5.3 Open Software Architectures
Computer hardware has successfully moved away from monolithic, proprietary designs, toward open architectures that enable components produced by a variety of vendors to be combined in the same computer system. Open architectures are based on the development of successful bus and interconnection protocol standards. A number of research and commercial projects are currently attempting to create the equivalent of open architectures for software components. Such approaches are based on standardizing some part of the glue required to compose components. The most notable efforts in that direction include object-oriented architecture standards, such as CORBA (Object Management Group 1991), Microsoft's OLE (1994), and Apple's Open Scripting Architecture (1993), and application frameworks such as X-Windows/Motif (OSF 1990; Scheifler et al. 1988) and Microsoft Visual Basic (1993).Open software architectures and our coordination perspective were both motivated by the complexity of managing component interdependencies. However, the two approaches represent very different philosophies. Open architectures take the stance that designers should not have to deal with software dependencies. In essence they are ''hiding interconnection protocols under the carpet''by limiting the kinds of allowed relationships and by providing a standardized infrastructure for managing them. 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, one should consider the full range of possibilities with the help of design handbooks.
Successful software bus approaches can enable independently developed applications to interoperate without the need to write additional coordination code. However, they have a number of drawbacks. First, they can only be used in environments for which versions of the software bus have been developed. For example, OLE can only be used to interconnect components running under Microsoft Windows. Second, they can only be used to interconnect components explicitly written for those architectures. Third, the standardized interaction protocols might not be optimal for all applications.In contrast, integrating a set of components using SYNTHESIS typically does require the generation of additional coordination code, although most of that code is generated semi-automatically. Components in SYNOPSIS architectures need not adhere to any standard and can have arbitrary interfaces. Provided that the right coordination protocol exists in its repository, 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 effcient implementations. Finally, open software architecture protocols can be incorporated into SYNTHESIS repositories as special cases of coordination protocols.
