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].
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
Dynamism. A system is dynamic if and only if it allows non-blocking
control connectors (spawns), i.e., the number of concurrent threads may
vary through time.
Supported data transfers. These may be achieved through: explicit
data connectors, an implicit global network of data connectors, or shared
Triggering capability. Some systems allow the transfer of data (events)
along explicit data connectors or a global network to cause certain actions,
e.g. control transfers or additional data transfers.
Concurrency. Whether single or multiple threads are allowed to execute
concurrently. Note that concurrency is not the same as dynamism.
Distribution. A system may be distributed or not.
Layering. A system may or may not impose layering constraints on
its control components.
Encapsulation. A system may be object-oriented or not.
Termination. Some systems may have explicit termination characteristics,
e.g., under normal conditions, blackboard systems always terminate, whereas
closed-loop feedback control ones never do.
Preemption. Some systems may allow for preemption of some execution
in order to handle a more urgent situation.
Predictable response time. The real-time style requires that a system's
response time for certain events be predictable in all cases.
Component priorities. In order to achieve better and/or more urgent
results efficiently, several styles have components prioritized in various
manners, thus specifying execution precedence.
Backtracking. The styles with their roots in artificial intelligence
allow for backtracking while trying to solve a problem. Depending on the
granularity being used, one could say the same about database centric systems
while doing their rollback/recovery.
Reentrance. Some styles allow for multiple simultaneous, interleaved,
or nested invocations of the same piece of code which will not interfere
with each other, i.e., their control components are reentrant.
Reconfiguration. Upon some special conditions (or failures), some
systems perform on-line reconfiguration, whereas others have it done off-line.
Central control entity. Some styles have some specific central control
entity responsible for arbitrating which components are to execute at any
given point in time.
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.
Dynamism: In case we have composition via a blocking data connector,
the receiving control component may be inactive when data is sent through
the data connector, and it may never become active (again), thus creating
a deadlock on the sending control component.
Data Transfers: The obvious example here is that of non-matching
signatures [Zaremski and Wing 1993].
Triggering: Different sets of recognized messages are used by two
subsystems that permit triggers and are being composed together.
Concurrency: When two concurrent threads share data there is a potential
for synchronization problems. One of the ways this situation may occur
is if composition is achieved by a system that allows for concurrency spawns
another (sub)system that originally assumed no concurrency would be present.
Distribution: A remote connector is extended into or out of a non-distributed
subsystem (i.e. a subsystem originally confined to a single node). The
non-distributed subsystem is not prepared to handle any possible networking
situations that may arise.
Layering: A layering constraint is violated during composition.
This may not be as problematic as other mismatches discussed here, but
it will violate the virtual machine concept that existed for a reason.
Encapsulation: Objects have public and private data. Private data
are hidden from the outside world, hence are only visible from within that
object. Consequently, if during composition there was an assumption that
at least part of some private data would be available to others, we have
Termination: Whenever there is a call (not a spawn) from one control
component to another, if the callee does not terminate (e.g., a closed-loop
feedback control system, or a system having an infinite loop), the caller
is in a deadlock situation.
Preemption: Composing two preemptive systems may cause problems,
since events may be handled differently by the two subsystems (one might
have a more urgent situation than the other).
Predicted response time: Composition of two systems that must have
predicted response times brings up issues on how to combine their predicted
Component priorities: Composition of systems which have component
priorities (either implicit or explicit) may lead into problems. How do
we know how components' priorities compare across systems?
Backtracking: Composition between a system that allows for backtracking
and one that doesn't may clearly cause problems. We may have used part
of the other system (which changed the overall state) and then have to
backtrack. There is no way of undoing what the other system did.
Reentrance: As a side effect of composition we could run into the
situation of trying to start some non-reentrant component that is already
Reconfiguration: Composing a subsystem that performs on-line reconfiguration
with one that doesn't, can create a situation where upon a failure only
part of the overall resulting system is reconfigured and running.
Central control entity: In event-based systems, the event manager
is responsible for selecting the control components for execution, based
on the events received. When composing with other event-based systems,
the existence of more than one event manager causes problems on deciding
which control component to activate next. Both event managers assume that
they have complete control on execution sequencing.
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 (http://sunset.usc.edu/TechRpts/dissertation.html).
[Allan and Garlan 1996] R. Allen and D. Garlan, The
Wright Architectural Specification Language, 24 September 1996 (http://www.cs.cmu.edu/afs/cs/project/able/ftp/wright-tr.ps).
[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,
[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,
[Spivey 1992] J. Spivey, The Z Notation, Prentice
[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,