3 Comparison

The perspective described here is most similar to that of Dellarocas [Del96], who proposes a language for classifying and describing typical features of the interconnections between software components. Dellarocas has also developed tools that implement these features and use them to integrate components into a system. The Component-Based Software Engineering project at Andersen Consulting [BBK⁺97] takes a similar approach. Since the methodologies associated with these approaches only provide relatively informal descriptions of component interconnections, they do not seem to have the power and flexibility of ASDL .

Alexander and his associates [BA96,PA97b,PA97a] have proposed a specification-oriented approach to component-based software engineering. The work in [BA96] is particularly relevant to the perspective described here; it uses a combination of Larch [GH93] and CSP that is analogous to the Z/CSP formalism of ASDL . The formalism of [BA96] is used to develop problem-specific applications for software, hardware, and hybrid systems. While ASDL (and Z) seem more appropriate for modeling domain-specific component-based software development systems, there are interesting similarities between the hardware models of [BA96] and the model in example (c) above, and also between the way in which nonfunctional requirements are represented by the constrained by clause of VSPEC [BA96] and the semantic abbreviations of ASDL.

Batory and his associates have used a generative approach [BO92] to describe how software systems can be constructed from plug-compatible components. In this approach, a type equation is used to define a software system, and an attribute grammar is used to express the set of all software systems that can be generated. This approach has been applied to network protocols and database management systems [BO92], and more recently to memory simulators [JPB97] and data language compilers [VB97]. While Batory's approach seems well suited to these applications, it relies on type-checking of parameters to determine the validity of a specific component composition. This relatively rigid approach is less appropriate for systems like PGM , in which the validity of component compositions depends on the values of attributes of component interface features.

Several researchers have proposed formalisms for describing software architectures and architectural styles [AAG95,AG94,IW95,MDEK95,ZJ93,Wil96]. While the spirit of all of this work has much in common with our own ideas, we believe that there are some important differences. First, the software types include a comprehensive set of variable declarations and constraints. These provide expressive power and flexibility, and also permit the use of a mixture of formal notations for the specification of architectural features. ASDL therefore supports an approach to architectural specifications that is both heterogeneous and orthogonal. Second, the operations provide a natural way to describe architectural styles that have dynamic features. This approach was illustrated in example (b) above, where the special event names used in the composition expression referred to the operations create_node and assign_label . Some approaches [IW95,MDEK95] use languages that support the dynamic creation of processes. These languages can also be used to model evolving architectures, but they have the drawback of additional semantic complexity when compared with CSP and Z. In addition, the dynamic operations must be explicitly specified in the underlying languages. In ASDL , only a reference to an operation like create_node is needed - the actual operation may be specified using a more appropriate formalism.

The increasing scale and complexity of modern software systems requires that they often be assembled from existing components. The goal of our approach is to develop and apply a formalism that can be used to describe methodologies that support the component-based construction of software. The fact that the software types and operations of ASDL are described in terms of Z schemas is not important per se - the key point is that the language provides a system-independent architectural notation. It is also important to note that Z and CSP are used orthogonally, in order to express different aspects of ASDL .

Finally, the software types and operations provide not only the ability to describe particular component-based software development systems, but also a basis for a methodology for developing architectural descriptions. This is analogous to the manner in which abstract data types are used. A stack with its standard operations suggests potential uses in algorithms; a software type with its associated operations similarly suggests potential uses in architectural descriptions. For example, given a module type representing a logical view, it is natural to formulate interface requirements for a corresponding unit in terms of operations that specify virtual ports, attributes, links, and virtual port descriptions. As another example, in describing an application system, it is natural to ask whether two nodes belong to a common view and should be connected by an assign_label operation, or whether they belong to different views and should be related by an operation that creates entries in a relation between the views. The types and operations of ASDL provide a rich variety of choices for handling such issues.