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

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

• 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

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

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