Composing Components: How Does One Detect Potential Architectural Mismatches?

Cristina Gacek and Barry Boehm
Center for Software Engineering
University of Southern California
Los Angeles, CA, USA, 90089-0781

Nowadays, in order to be competitive, a developer's usage of Commercial off the Shelf (COTS), or Government off the Shelf (GOTS), packages has become a sine qua non, at times being an explicit requirement from the customer. The idea of simply plugging together various COTS packages and/or other existing parts results from the megaprogramming principles [Boehm and Scherlis 1992]. What people tend to trivialize is the side effects resulting from the plugging or composition of these subsystems. Some COTS vendors tend to preach that because their tool follows a specific standard, say CORBA, all composition problems disappear. Well, it actually is not that simple. Side effects resulting from the composition of subsystems are not just the result of different assumptions in communication methods by various subsystems, but the result from differences in various sorts of assumptions, such as the number of threads that are to execute concurrently, or even on the load imposed on certain resources. This problem is referred to as architectural mismatches [Garlan et al. 1995] [Abd-Allah 1996]. Some but not all of these architectural mismatches can be detected via domain architecture characteristics, such as mismatches in additional domain interface types (units, coordinate systems, frequencies), going beyond the general interface types in standards such as CORBA.

Other researchers have successfully approached reuse at the architectural level by limiting their assets not by domain, but rather by dealing with a specific architectural style. I.e., they support reuse based on limitations on the architectural characteristics of the various parts and resulting systems [Medvidovic et al. 1997] [Magee and Kramer 1996] [Allan and Garlan 1996]. This approach can be successful because it simply avoids the occurrence of architectural mismatches.

Our work addresses the importance of underlying architectural features in determining potential architectural mismatches while composing arbitrary components. We have devised a set of those features, which we call conceptual features [Abd-Allah 1996][Gacek 1997], and are building a model that uses them for detecting potential architectural mismatches. This underlying model has been built using Z [Spivey 1992].

Conceptual Features

When composing systems, many potential architectural mismatches can be detected by analyzing their various choices for conceptual features. Mismatches may occur because the subsystems have different choices for some particular feature. E.g., one is multi-threaded and the other isn't, creating the possibility of synchronization problems when accessing some shared data (the single-threaded part assumes there is absolutely no risk). Mismatches may also occur because the subsystems make the same choice for some particular feature. E.g., if two subsystems are single-threaded, we may also run into synchronization problems when accessing some shared data, since both parts assume there is absolutely no risk.

Note that the use of conceptual features becomes a facilitator when dealing with COTS and GOTS. Conceptual features do describe the system and often help describe API's, without giving away secrets that could reduce the vendor's competitive advantage.

Conceptual Feature Set

By analyzing various architectural styles and their common descriptions [Shaw and Garlan 1996] we devised our current working set of architectural conceptual features. The architectural styles we used are distributed processes, event-based, layered, main-subroutine, object-oriented, pipe-and-filter, blackboard, rule-based, logic programming, transactional database-centric, real-time, and closed-loop feedback control. Our resulting conceptual features are:

Impact on Megaprogramming

How architectural mismatches can obstruct a megaprogramming effort has already been very clearly illustrated [Garlan et al. 1995]. We don't only have to consider functionality and environment, but also the architectural features intrinsic to the various parts.

In order to substantiate that each one of the above features could be used to determine potential architectural mismatches we will be discussing one mismatch example for each feature.


Architectural features can be used to provide information on potential architectural mismatches early on in the reuse process. Hence this information is instrumental for early risk assessment.

Here we presented a set of architectural features that are relevant to reuse. We also illustrated by examples how these features can be used to detect potential architectural mismatches. More of these mismatches have been discussed in [Abd-Allah 1996] and [Gacek 1997], but these classifications are still evolving. Although not discussed here, we have also built a prototype tool (AAA--Architect's Automated Assistant), based on the Z model, that uses as input styles, components, and/or COTS descriptions and analyzes them for compatibility.


[Abd-Allah 1996] A. Abd-Allah, Composing Heterogeneous Software Architectures, Doctoral Dissertation, Center for Software Engineering, University of Southern California, August 1996 (
[Allan and Garlan 1996] R. Allen and D. Garlan, The Wright Architectural Specification Language, 24 September 1996 (
[Boehm and Scherlis 1992] B. W. Boehm and W. L. Scherlis, "Megaprogramming," Proceedings of the DARPA Soft ware Technology Conference, April 1992 (available via USC Center for Software Engineering, Los Angeles, CA, 90089-0781).
[Gacek 1997] C. Gacek, "Detecting Architectural Mismatches During Systems Composition," USC Technical Report USC-CSE-97-506, Center for Software Engineering, University of Southern California, 8 July 1997 (
[Garlan et al. 1995] D. Garlan, R. Allen, and J. Ockerbloom, "Architectural Mismatch or Why it's hard to build systems out of existing parts," IEEE Software, November 1995, pp. 17-26.
[Magee and Kramer 1996] J. Magee and J. Kramer, "Dynamic Structure in Software Architectures," in Proceeding of the ACM SIGSOFT'96: Fourth Symposium on the Foundations of Software Engineering (FSE4), San Francisco, CA, October 1996, pp. 24-32.
[Medvidovic et al. 1997] N. Medvidovic, P. Oreizy, and R. N. Taylor. "Reuse of Off-the-Shelf Components in C2- Style Architectures," in Proceedings of the 1997 Symposium on Software Reusability (SSR'97), pp. 190-198, Boston, MA, May 17-19, 1997.
[Shaw and Garlan 1996] M. Shaw and D. Garlan, Software Architectures--Perspectives on an Emerging Discipline, Prentice Hall, 1996.
[Spivey 1992] J. Spivey, The Z Notation, Prentice Hall, 1992.
[Zaremski and Wing 1993] A. M. Zaremski and J. M. Wing, "Signature Matching: A Key to Reuse", Proceedings of the First ACM SIGSOFT Symposium on the Foundations of Software Engineering, December 1993, pp. 182-190.