Component Assessment Using Specification-Based Analysis and Testing

component type C plugs into architecture Figure 1. Concept of Abstract Component Specification Now, suppose that there are one or more concrete components K1...Kn that can potentially be used with A as a component that satisfies C, as shown in Figure 2. For this to be semantically viable, the specification of a Ki, SKi must be compatible with SC (i.e., SKi implies SC) and Ki must be a faithful implementation of its specification SKi . The problem that the system integrator is faced with is: how do we verify that the specification of the concrete component implies the specification of the abstract (desired) component, and how do we assess Ki itself? Further, it may be that SKi is only an informal description of Ki. Since the source code of Ki is not available for examination, the only alternative left is to conduct some form of dynamic assessment to determine if Ki is viable for C. 2. Problem Description 4 Architecture A Specification for abstract component C required for “plug-in” to Architecture A Specification SC Interface Behavioral (Semantics) K1 Kn . . . What component most closely matches the desired idealized abstract specification Sc ? Concrete instances potentially satisfying specification Sc Figure 2. Conceptual Need to Assess One or More Concrete Components The following sections present the definitions and concepts necessary to understand the issues in component assessment as well as provide an overview of the assessment process itself. 2.1 SEMANTIC AND SYNTACTIC MAPPING The process of composing a component K with A is an act of interface and semantic mapping. For K to be successfully composed with A, the interface of K, I, must map to the interface specified for C, IC. There are two possible cases that can arise during this mapping process: 1. The interface of C, IC maps directly to the interface of K, IK (i.e., IK ⇒ IC). In this case, there is a oneto-one mapping from each element of C’s interface to an element of K’s, so there is at least syntactic compatibility between C and K. Semantically, there are two possible cases: • The semantics of K are sufficient to satisfy those specified in SC (i.e., SK ⇒ SC). In this situation, nothing further need be done. K is both syntactically and behaviorally compatible with C and can be freely composed with A. This is depicted in Figure 3 where a concrete component Ki has been selected that is compatibile with C. • The semantics of K are not sufficient for SC (i.e., ¬(SK ⇒ SC)). K is somehow lacking with respect to the behavioral semantics of C. At the extreme, K has no behavior in common with C. Arguably, K should not be considered further for composition with A. The possibility is that K has partial behavioral compatibility with C. In this case, K either has incompatible or missing behavior with respect to some portion of SC. To overcome this, a semantic adapter AS S C K must be specified (and built) such that, when composed with SK, the adapter yields a component that is compatible with C. The composition of this specification, AS S C K , and SK must satisfy the ( ) AS S K C C K S S o ⇒ . 2. Problem Description 5 Architecture A Specification for abstract component C required for “plug-in” to Architecture A K Specification SC Interface Behavioral (Semantics) Concrete component K plugs directly into architecture Figure 3. Selection of Compatible Concrete Component Ki 2. The interface of C cannot be mapped directly to the interface of K (i.e., ¬(IK ⇒ IC)). This case can occur in one of two different circumstances: • The syntactic interface of K is not compatible with that of C‘s. However, the semantics of K are sufficient for those specified for C. In this case, a syntactic adapter IS S C K must be specified and built. This adapter simply maps the interface of C to the interface of K such that ( ) I I I S S K C C K o ⇒ . • Neither the syntactic interface nor the semantics of K are compatible with C. This is the most complicated of situations because it requires that an adapter be specified such that both ( ) I I I S S K C C K o ⇒ and ( ) AS S K C C K S S o ⇒ hold. The practicality of this depends on both the syntactic and semantic distance between SC and SK. The above circumstances are illustrated by Figure 4 where a component K is plugged into adapter AS S C K , which is in turn plugged into architecture A. The dashed line indicates that some of the behavioral semantics may be provided by the adapter if the component K is somehow deficient as described by the second bullet in the first case above. 2. Problem Description