The work reported in this chapter grew out of the Process Handbook project at MIT's Center for Coordination Science (Dellarocas et al. 1994; Malone et al. 1993). The Process Handbook project 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. 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.
Architecture Description Languages (ADLs) provide support for representing the high-level structure of software systems in terms of their components and their interconnections (Kogut and Clements 1994; Shaw and Garlan 1994). They are an evolution of Module Interconnection Languages (MIL), first proposed in the 1970s (DeRemer and Kron 1976). Most ADLs provide separate abstractions for representing components and their interconnections. SYNOPSIS shares many of the goals and principles of ADLs. However, whereas previously proposed architectural languages only provide support for implementation-level connector abstractions (e.g., a pipe, or a client/server protocol), SYNOPSIS is the first language that also supports specification-level abstractions for encoding interconnection relationships (dependencies). Furthermore, apart from introducing a new architectural language, this work proposes a more general perspective on designing systems which also includes the development of design handbooks for activities and dependencies as well as a design process for generating executable systems by successive specializations of their architectural descriptions. The project that comes closest to our work is UniCon (Shaw et al. 1995).
A number of research tools attempt to facilitate the design and development of software systems by providing graphical, architectural views of systems and automated assistants which guide users through the design process. STILE (Stovsky and Weide 1998) provides good support for graphical component-based design but does not provide particular support for distribution or for managing component mismatches. The Software Architect's Assistant (Kramer et al. 1993) is a visual environment for constructing distributed applications. Aesop (Garlan et al. 1994) exploits the notion of architectural style to assist users in constraining their design alternatives and verifying the correctness of their designs.
Broadly speaking, SYNTHESIS also provides a graphical architecture description language and a design assistant for generating executable applications. However, the specific models (activities, dependencies, and coordination processes), relationships (decomposition, specialization), and design operations (replace dependencies with compatible coordination processes) supported by SYNTHESIS are different from the systems above and specifically geared to facilitate the integration of heterogeneous, multilanguage, and possibly incompatible software components. It will be interesting to see how good ideas from various software design assistants can be constructively combined.
Component frameworks such as OLE, CORBA, and OpenDoc (Adler 1995) 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 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 interconnection protocols defined in specific component frameworks can be incorporated into SYNTHESIS repositories as one, out of many, alternative ways of managing the underlying dependency relationships.