Search our
entire site
Enter your search
terms below, or visit
our search page

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:

• 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 data variables.
• 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 a problem.
• 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 response times.
• 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 executing.
• 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.

Conclusion

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.

Bibliography

[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, 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 (http://sunset.usc.edu/TechRpts/Papers/usccse97-506/usccse97-506.ps).
[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.