Interoperable Software Modules
Il-Hyung Cho John D. McGregor Department of Computer Science Clemson University Clemson, SC 29634 Email: fihcho,
[email protected] Lee Krause Software Productivity Solutions, Inc. 122 Fourth Ave. Indialantic, FL 32903 Email:
[email protected]
Abstract
compatibility, software architecture, components, interoperability, speci cation, signature matching, interfaces
Interoperability is the ability of two or more software modules to communicate and cooperate with each other. The interoperability problem arises when software developers want to reuse legacy software systems, or when software systems are componentized and these components need to be connected in order to work together. The problem occurs in both heterogeneous (multi-lingual) and homogeneous environments. Software modules can be functions, objects, or components which consist of multiple functions or objects. In this paper we focus on the speci cation of software components in object oriented systems.
1 Introduction Reuse of software modules is an important but elusive goal for most software development organizations. Reuse is important because it has the potential to save time, reduce costs, maximize resources, and increase reliability. However, software reuse is practical only when it is easier to identify the appropriate modules to use than to write them from scratch. This paper addresses one aspect of this problem: whether two software modules can communicate appropriately with each other. We report on an investigation that has surveyed existing techniques for supporting the selection of interacting components, describe a tool that supports a speci c technique for de ning patterns of interaction and nally describe an evolution of that technique to provide more complete support. To be reused, a module has to provide behaviors that are needed in the new application environment. In other words, the module must \match" the other modules with which it will interact. There are a number of de nitions of \match" in the literature. In [18], a number of issues have been raised regarding software reuse: retrieval, reuse, substitution, subtype, and interoperation.
Traditionally, interoperability checking is performed by signature matching between an invoking function and a function being invoked. Function level signature matching techniques are not sucient for software components in object oriented systems since an object encapsulates a set of data and functions, and a component may contain more than one object. In this paper we rst describe the interoperability problems of software modules both in the procedural and object oriented paradigms, and then review current approaches and compare them. Based on the review, we propose a new interoperable component model (ICM) that enhances software reusability and maintainability.1
In retrieval, we want to retrieve a component from a software library that satis es a given query. In reuse, we adapt a component from a software library to t the needs
keywords: protocols, protocol analysis, protocol inThis work has been funded by NASA Goddard under the DOSAEE Phase II contract NAS5-33219. 1
1
of a given subsystem, based on how well the component meets our requirements. In substitution, we want to replace one software component with another without a ecting the observable behavior of the entire system; a special case of substitution is when a subtype object is the component substituting for the supertype object. In interoperation, we want one component to interact properly with the other [18]. All these issues are related; however, in this paper, we will focus on interoperation. The simplest, and possibly original, technique for organizing reusable software modules is a subroutine library (e.g., a function library in C). The advent of object-oriented languages has stimulated higher levels of reuse: not only at the function level, but also at the object level. In C++, the Standard Template Library (STL)[9] provides a set of container classes and template algorithms that support a wide range of useful functionality. The library supports most commonly used data structures. As the size and complexity of these libraries increase, the need for automatic ways to locate and suggest candidates for a speci c role in an application also increases. Without automatic mechanisms to test for compatibility, programmers have to perform the searches and comparisons manually. We use the terms software module and component as synonyms for some cohesive subset of a software system. Components serve as the building blocks of a software system. Each component de nes an interface that provides access to its services from outside the component. The interface is comprised of methods and describes the responsibilities and behavior of the component. A component may operate across language boundaries, operating system boundaries or network boundaries. However, the typical interface of a component does not provide sucient information to judge whether two components can successfully work together. A protocol is the sequence of messages involved in the interactions of two components (or objects). If the protocols are not compatible, the components can not interoperate2. The use of protocols to describe object communication fosters structured, safer and potentially veri able information exchange between objects. The protocol plays an important role as a partial interface speci cation (a class may participate in multiple protocols). An object's interface alone involves only the one object, but a protocol de nes the interaction of two objects.
The main contribution of this paper is to propose a technique for determining the compatibility of two software components, where compatibility is de ned as the ability to interoperate. A secondary contribution is to provide a critical analysis of existing techniques for determining this compatibility. In the following section, we present DOSAEE (Domain-Oriented Software Analysis and Engineering Environment)3, and its use of protocol as an element in de ning a software architecture. Type matching techniques have been used to check one dimension of the compatibility of components. These techniques are covered in the section 3. In section 4 we overview the approaches taken by di erent researchers to solve the interoperability problem. At the end of the section each technique is categorized into a taxonomy which gives an overall view of the interoperability problem. In section 5 and section 6 we propose a novel approach of interface description with protocol information, and give some observations on component level programming in object oriented systems and its viability in software development. The nal section concludes with future work.
We will use interoperation, as synonyms.
DOSAEE is a CASE tool developed by Software Productivity Solutions (SPS).
2
interaction
and
2 DOSAEE Approach The Domain Oriented Software Analysis & Engineering Environment (DOSAEE)[13] is a graphical tool that facilitates the development of new software systems. The tool supports the creation, specialization, adaptation, and re nement of the architectural elements (protocols, components, and patterns) into a domain architecture. Protocols represent the sequences of interactions that occur between software components in the software system. Components represent the building blocks of software applications, and are tied together via patterns to become a micro architecture of the whole system. Its approach is to support architecture speci cation methods that incorporate the speci cation of protocols in the development of domain architectures. DOSAEE supports the application of protocols for developing new components as well as reusing existing components. The tool evaluates the compatibility of components in an architecture (i.e., reuse components), guides the composition of components, and facilitates the development of adaptors which allow an engineer to integrate components without having to modify any components. A single protocol de nes an ordered sequence of interactions, de ning which component initiates 3
collaboration
2
3 Type Compatibility
the interaction, what information ows between the components, and what style of interaction is used. DOSAEE currently supports interaction styles of event, message, and RPC. Consider the example shown in Figure 1. There are three components, ATM, Customer Database (CD), and Transaction Controller (TC), and two protocols, ValidatePIN and InitiateWithdraw. In this example, the ATM component is participating in both protocols. One or more messages can be involved in each protocol, and a certain message can be in more than one protocol. It is implied that only after the PIN is validated will the ATM machine support the withdraw message even though the information about order of messages is not explicitly speci ed in the gure. In the DOSAEE tool, the protocols in the gure can be read from top to bottom. In the tool, when a user clicks on the protocol name ATM
ValidatePIN
The issue of whether two components are type compatible arises in a number of circumstances including when we want to reuse a software module in a new application. For an existing module (or legacy code) to be (re)used seamlessly in a new environment (or in a new framework), we rst need to have a mechanism to locate the module in a library. If we know the exact name of the module we can simply browse the library or query the library using the name. If we do not remember the name but know the signature of the module, i.e., return type and type of arguments, then we can query the library using the signature. Once the module is identi ed, it can be checked for compatibility with other components that have already been selected. In this section we survey a number of techniques for determining whether two components are type compatible.
Customer Database
3.1 Signature Matching
InitiateWithdraw
Zaremski and Wing [17] implemented a signature matching technique for software modules. The signature of a function is simply its type; however, the signature of a component is a multiset of user-de ned types and a multiset of function signatures. The same matching techniques used for primitive functions are applied repetitively to test the compatibility of two components. The main purpose of their matching de nition is for retrieval of software components from a library. They formally de ne Signature Matching using the Standard ML notation [14], and implement the matching techniques using Larch [5] for exact matches, and for various kinds of relaxed matches. An exact match does not require the same variable names, but requires that each variable has the same type. Furthermore, it allows polymorphic type matching using a generic type: If a function is of type ( ; ) ! bool, then it matches to a function of type ( ; ) ! bool, where and can be of any type (either a built-in type or user de ned type). In relaxed matching, the user queries with partial information: the provided types may be generic, or the order of the parameter type may be changed, that is, queries with type (int; float) ! bool instead of (float; int) ! bool. The technique does not provide a way to recognize that two components that do not match are very close to matching. Neither do they have a mechanism to check for a behavioral (or semantic) mismatch nor component interoperability.
Transaction Controller
Figure 1: ATM cash withdraw protocols a new window will popup and show detailed message sequences involved in the protocol, including message name, parameters and return types. A user of the DOSAEE tool can describe components and protocols at various levels of abstraction. The CD and TC components can be viewed as sub-components of a Bank component. The two protocols can also be considered as sub-protocols of the CashWithdraw protocol. Or, each of the two protocols can be further subdivided into more concrete levels of protocols. For the ATM component to interoperate with CD and TC components, it has to be protocol compatible with them: the method signatures and the message sequence should match. Firstly, the method signatures are matched between the invoking component and the invoked component. If they do not signature-match (or type match), they may still be functionally compatible. In this case, DOSAEE provides a protocol adaptor to make them interoperable. The next section presents current research efforts on type speci cation and type matching techniques, which is followed by the section on module interoperability. DOSAEE will be further discussed when we present our extensions in a later section. 3
3.2 Behavioral Subtyping
Match: Component, Component ! Bool Match(C; C ) = matchsig (Csig ; Csig ) ^ matchspec (Cspec ; Cspec ) 0
Signature matching is not sucient to ensure a subtyping relationship as shown by Liskov and Wing [8]. They cover a semantics of the subtype relation in object oriented languages and propose a behavioral notion of subtyping. A subtype object can be used anywhere its supertype object can be. Type checking using speci cation matching captures only a small part of what it means for a program to be correct; the same is true for the co-/contra-variance rules [4]. For example, both stacks and queues might have put and get methods. According to the signature matching technique and contra-variance rules, either can be a valid subtype of the other. However, a program written with the expectation that x is a stack, may not work correctly if x actually denotes a queue, and vice versa. Liskov and Wing [8] propose a stronger requirement that constrains the behavior of subtypes:
0
0
Two components C and C match if their signatures match and then if their speci cations match. The signature match lters out non-matching components to save e ort for the more expensive speci cation match. They provide both exact match and relaxed match for functions and modules. They also provide a protocol speci cation for module interoperability, which is covered in the next section. 0
4 Module Interoperability While the relationship sought out for type compatibility problem is whether one software component can be thought of as a subtype of the other or is behaviorally compatible to the other, the main concern for interoperability is to identify the relationship between two di erent software components, and determine whether they can interact. For retrieval, a user has to provide, in a query, the signature and speci cation information of the module with which his/her module is to interact. Interoperability problems arise not only in a homogeneous environment, but also in a heterogeneous environment: We may want a component C written in language A to interact with a component C written in language B . Problems occur at both the syntactic and semantic levels. That is, two interoperating modules may compile without an error, but the functionality of the interoperation may not be what is expected. For example, a client component may interoperate with a component it `thinks' is a queue, not realizing it is actually a stack component. Interfaces (method signatures) of both stack and queue components may well be identical and the client component may not be able to tell whether it is interacting with the correct component. This situation would cause erroneous behavior of the systems, and must be avoided. As will be seen, some of the approaches discussed in this section consider only syntactic level interoperability, and others consider both syntactic and semantic levels of interoperability. In this section, we consider Zaremski and Wing's protocol speci cation approach [18], Polylith system [11, 12], PolySPIN [2], CORBA IDL, and Software Adaptor approach [16]. The techniques address one or more of the following issues; How can a component be speci ed so that it can interoperate to the other? How can we identify a module with which we
Subtype Requirement: Let (x) be a property provable about objects x of type T. Then (y) should be true for objects y of type S where S is a subtype of T.
By applying the requirement to the above examples, we can easily see that the stack does not satisfy the requirement of the queue: queue requires that get() return the item lastly put, but the stack requires that get() return the item most recently put. The behavioral subtyping requirement is satis ed by specifying the type of objects with not only the type's name and signatures, but its method's behavior in terms of preand post- conditions.
0
3.3 Speci cation Matching
In [18], Zaremski and Wing extended their earlier work by proposing a speci cation matching scheme. Speci cation matching is a way of comparing two software components. In object oriented programming, it can help determine when one type is a behavioral subtype of another. In the context of system interoperability, it can help determine whether the interfaces of two components mismatch. Interoperability issues will be covered in the next section. As described in Section 3.1, Zaremski and Wing use standard ML notation to de ne speci cation matching, and use the Larch Prover to prove the matching. Speci cation matching goes a step beyond signature matching: it provides a behavior of its component. They use pre- and post-conditions for the speci cation, similar to pre- and post-conditions speci ed in [8]. The component matching is de ned as follows: 4
want our application to interoperate? or masked out. But NIMBLE allows programmers to adapt the interfaces of existing software automat How can we make one module interoperate with ically. the other if they are not compatible? Figure 2 illustrates an example of signature mismatch. The module on the left has a record type 4.1 Speci cation Matching { Protocol EmployeeRecord and calls the procedure printLabel de ned in the module on the right. The module on Zaremski and Wing [18] recognize that signature the right, however, expects a di erent record type matching and pre-/post-condition is not enough to and they cannot be directly linked. Not only does check for components interoperability. Consider that the module on the right expect a di erent number of components C and S communicate via a communica- parameters, but the type and order of the parameters tion channel. Their speci cations are an exact match. are di erent. Assume however, that C can do multiple sends before To resolve the mismatch, the programmer rst doing a receive, but that S can only alternate receive creates the desired map as shown at the bottom of the and send, as speci ed in the following message se- gure. This map is compiled with NIMBLE and used quences: to generate an implementation of the map. In case parameters have to be modi ed, programmers have C = send ! (receive ! C jsend ! C ) to provide a coercion module with an eval statement. S = receive ! send ! S In the eval statement, the rst parameter (mapSex) is the name of the coercion routine and the second If C does multiple sends in a row and then parameter is input to the routine. The string type does a receive, S deadlocks after doing its rst receive (`male' or `female') of Sex is converted to integer type since it wants to do a send next, corresponding to a (1 for male and 2 for female) of Sex. The implemenreceive by C, but con icting with C's second send: tation of the routine is shown as follows: their message sequences do not match. To specify the message sequences, [18] adds a protocol speci cation to a component's interface speci cation, adding a matchprotocol predicate to the de nition of Interop- int mapSex(char* s) { if (strcmp(s, "male") == 0) erates as follows: return(1); else return(2);
Interoperates: Component, Component ! Bool Interoperates(C; C ) = Match(C; C ) ^ matchprotocol(Cprotocol ; Cprotocol ) 0
}
0
0
In NIMBLE, the matching is done at the syntax level: only signature matching is done for interoperability checking. Thus, two syntactically matching software modules may not be able to interoperate, i.e., may give a run time error, if they are not semantically compatible { a speci cation/protocol mismatch, according to [18]. To work within a multi-language environment, the software bus [12] technique was introduced to interconnect software components written in di erent programming languages. Heterogeneity in language is accommodated since program units are prepared to interface directly to the bus, not to other program units. The software bus is responsible for message delivery and resolving mismatch. Programmers are responsible for specifying the application structure in terms of MIL (Module Interconnection Language) which is similar to IDL (Interface De nition Language). Only procedural languages are supported by the Polylith system.
In the case of a mismatch, i.e., if the protocols of the two components are incompatible as described in the above example, they don't provide a mapping mechanism to adapt one protocol to the other to make them interoperable. As described in the Section 3.1, this technique provides both exact matching and relaxed matching.
4.2 Polylith
In the Polylith interconnection system [11], a language called NIMBLE is used to map the type mismatches between two interoperating modules written in the same language. An invoking module may not signature-match to an invoked module, but they may be functionally compatible. In such a case, programmers have to edit the source level of the invoked module to reuse it in a new environment. The parameters may appear in a di erent order, data types may not exactly match, and some parameters may be added 5
TYPE EmployeeRecord : { Name : string; Address : string[4]; Sex : string; Age : integer; Salary : float; }
}
TYPE PrintRecord : { Sex : integer; Name : string; Address : string[4]; }
{
MAP
...
VAR emp : EmployeeRecord;
PROC PrintLabel (Label: PrintRecord); BEGIN if Label.Sex = 1 then write("Ms. "); else write("Mr. "); write(Label.Name); write(Label.Address); END
... printLabel(emp);
ACTUAL PATTERN: Name: string; Address: string[4]; Sex: string; Age: integer; Salary: float FORMAL PATTERN: integer; string; string[4] NIMBLE: eval(mapSex, Sex); Name; Address
Figure 2: NIMBLE MAP
4.3 PolySPIN
model. Also, when a new language needs to work in PolySPIN with other N languages, there has to be a new implementation for each of the the N lanThe main focus of while in IDL (or MIL), there needs to be only PolySPIN (Support for Persistence, Interoperability guages, one additional IDL implementation. and Naming in POLYlingual) system [2] is resolving interoperability problems arising in systems written in di erent programming languages without re- 4.4 CORBA IDL quiring the programmer to construct any additional Interface de nes a component's boundaries: it gives speci cation. PolySPIN is composed of four sub- client modules contractual points to access a service components to implement seamless interoperation: module. Components written to IDL are portable Locator resolves object reference, Language Arbiter across languages, operating systems, and networks. handles language speci c information, Communica- CORBA IDL [10] covers both procedural languages tor handles inter-language invocation (e.g., marshal- and object oriented languages. Following is a simple ing and unmarshaling), and Type Matcher resolves IDL example. typing matching, none of which are programmers' concerns. interface foo { As in the Polylith system, PolySPIN does not void operation1(...); require either pre-/post-condition speci cations nor void operation2(...); a protocol speci cation. Major di erences are: while } the Polylith system supports only procedural languages, PolySPIN supports only object oriented lanA component which implements the foo interguages (at the time of this writing, CLOS, C++, face has to provide an implementation of each operand Java); while the former requires additional spec- ation. Both operations return void, but the return i cation (MIL), the latter does not. This makes type can be any other type. (Speci cally, CORBAPolySPIN more seamless than any other techniques de ned primitive types or interface object types like mentioned. Programmers do not have to be con- foo. These types are also used in the parameter list.) cerned about additional speci cations other than the A shortcoming, according to [2], is seamlessname of modules and parameters. In the Polylith ness. Like MIL, similar problems occur when a comsystem if one application changes, its MIL also has ponent changes. IDL only de nes the interface of to change. Worse yet, if other modules need to in- the service provider. Thus, the relationship is masteroperate with the modi ed application, their MILs ter/slave, or client/server. The interoperation is one have to be modi ed. This problem does not occur in way: from client to server. Server only returns results PolySPIN. However, the price to pay for the seam- to the client, but there is no information speci ed in lessness is high complexity in the implementation server IDL for the server to invoke methods of the 6
client. Also, there is no message sequence informa- protocol compatibility. The authors provide a more tion. In [16], Yellin and Strom argue that this is not relaxed de nition by using the notion of subprotocol. a true sense of interoperation. The software adaptors are built in a semiautomatic way. Once users nd out that two components are not protocol compatible but are func4.5 Software Adaptor tionally compatible, they need to provide interface As with CORBA IDL, this work concerns component mapping information to construct an adaptor. Once level programming: how well will two software com- built, the adaptor will intercept the outgoing mesponents work together if connected? If two compo- sages for a component and adjust the message to the nents match perfectly, they can be simply connected incoming message of the other component. together without any additional work. For two components with functionally compatible but type in- 4.6 PROCOL compatible interfaces, Yellin and Strom [16] present Software Adaptor as a bridge between the compo- PROCOL (PROtocol-constrained Concurrent Object nents. An adaptor is a piece of code that compensates Language) is a concurrent object oriented language for the di erences between their interfaces: di erent [3]. PROCOL de nes a protocol within each object message and parameter names, di erent parameter de nition. The protocol constrains sequences of mesorders, and even di erent numbers of states. sage communications, and controls access to methods An interface is de ned in each component, and of the object through guards. (A method is called an a component can be composed with another compo- action in PROCOL.) An object de nition consists of nent through their interfaces. (Note that in CORBA several parts. An example of a bank account object IDL, an interface is de ned only on one of the two is as shown: components.) An interface of a component speciACCOUNT es messages to be sent and to be received, and a OBJ Protocol protocol which constrains the message sequences inCreator(amount) -> Open; volved in the collaboration. The protocol describes ( Creator() -> Inquire + the sequencing constraints by means of a nite state Creator(amount) -> Deposit + machine: It consists of a set of states and a set of (balance > 0) : Creator(amount) -> transitions. The following shows the format of an Withdraw interface: ) *; Creator() -> Close Declare float balance, amount; Actions Open = { balance = amount; } Withdraw = { if (amount > balance) amount = balance; Creator.(amount); balance -= amount; } Deposit = { balance += amount; } Inquire = { Creator.(balance); } Close = { Creator.(balance); } EndOBJ ACCOUNT.
Collaboration component_name { Receive Messages { // messages to be received }; Send Messages { // messages to send }; Protocol { States { // name of states }; Transitions { state1: -sending_message -> state2; state2: +receiving_message -> state3; ... }; } }
An object de nition begins with `OBJ objecttype name' and ends with `EndOBJ object-type name'. The Protocol part is a regular expression of sender(message) ! action terms. The expression has four operators: `+' (for selection),`;' (for sequence), `*' (for repetition), and ` ' (for method guard). In the example, the bank account object protocol constrains the order of actions to be called: Open followed by Inquire, Deposit, or Withdraw in repetition, followed by Close. (balance > 0) is a
The term Collaboration is used to denote an interface of a component. + in front of a message denotes the message as input, and ? is the denotation for output. If P(P') is a protocol of a component C(C'), P and P' are compatible if P = P , where P is the same as P except that the direction of all messages is reversed. This is a strict de nition of 0
7
guard for the Withdraw method: Withdraw can only be invoked when the balance is greater than zero. Local data and object types are declared in the Declare part. The Actions part de nes methods of the object. The Creator speci es the object which created the current object. Creator() ! Inquire in the Protocol part speci es that the creator can call the Inquire action once the account is open. Creator.(balance) in Inquire and Close denotes that the object returns the balance to the creator upon invocation. In PROCOL each object is a unit of concurrency. An object runs concurrent with other objects unless it is engaged in communication with others. (They would run parallel if each object is assigned to a separate processor.) Objects can run without protocols, but it is advisable to make protocols mandatory, because the protocol at a minimum serves as a clear interface speci cation of the object concerned. It does not support inheritance, but delegation is being investigated to replace inheritance.
by programming language constructs, while implementation relationships are Def/Use relations and directly supported by programming language constructs. Whereas the implementation relationship is concerned with how a component achieves its computation, the interaction relationship is used to understand how that computation is combined with others in the overall system. For compatibility checking, the implementation relationships require type and behavior checking as described in the Section 3, while the interaction relationships require protocol compatibility.
4.8 Comparison
We compare the techniques covered in this section. The comparison criteria are 1. The level of software modules being considered. Function, object, or component? 2. Whether the modules are heterogeneous or homogeneous. 3. What, if any, additional speci cation is needed? Such as, Whether the speci cation is needed in only one module or in both. Where the speci cation needs to be provided. Within the module or separate from the module The scope of the speci cation. Should the speci cation cover syntactic interoperability or semantic interoperability? 4. How matching is performed if the two modules are not compatible. In Table 1, we list the categories and apply them to each technique described in this section. If a module is speci ed as a component it can be used for both objects and components. For example, CORBA IDL can be used for both objects and components. The module of Formal Connector is an abstract architectural component. It is generic in a sense that it does not depend on any particular language. Speci cation Matching is not targeted to object oriented languages, but the technique is generic enough to be extended to object oriented languages. PolySPIN, Software Adaptor, and PROCOL are exclusively for object oriented languages. Polylith, PolySPIN, and CORBA IDL are developed with multiple language support as a main goal. PolySPIN is the only one which does not require an additional speci cation. Speci cation Matching de nes signatures, pre-/post-conditions and protocol speci cations within each module. All of the other techniques need some sort of interface
4.7 Formal Connectors The Formal Connector technique [1] is used at an architectural level in a software system. The main goal is to provide a complete theory of architectural descriptions which had been previously described informally by using boxes and lines. The components and connectors of the software architecture are described with a subset of the CSP (Communicating Sequential Process) notation. The connectors are de ned as separate and explicit semantic entities. Formal Connectors re ne the conventional programming paradigm of Def/Use which is characterized by the procedure call/return. The re ned paradigm is also adopted in PROCOL and Software Adaptor, where module interactions are viewed as two way message communications. Contrasted to PROCOL, Formal Connectors deal with architectural components instead of objects. Contrasted to the Software Adaptor technique, Formal Connectors always have a connector component between interacting components. In Software Adaptor, a connector (an adaptor) is not needed when two components are protocol compatible. It is needed only when two interacting components are functionally compatible, but protocol incompatible. Also, protocols are de ned at a separate connector component, but in Software Adaptor, they are de ned within each component. Two relations are speci ed: interaction relationships are viewed as occurring in architectural abstractions which are not directly provided 8
Module OO Support Multi-language Additional Speci cation Separate Speci cation Speci cations needed at Semantic Match Protocol Match Matcher (Adaptor)
Speci cation Matching function, component possible no signature, pre/ post, protocol no within module both sides yes yes none
CORBA Formal Polylith PolySPIN IDL Connector module object component component
Software Adaptor component
PROCOL object
no yes MIL
yes yes none
yes yes IDL
yes
not applied
yes
both sides no
not applied no
server only no
no
no
no
yes
yes
yes
none
none
adaptor
no
software type bus matcher
yes yes yes generic no no WRITE (state machine- method arch. language like) protocol guards yes yes no (within object) separate both both component sides sides yes no no
Table 1: Categories in module interoperation.
Polylith The main goal is to use the software bus
speci cations. PROCOL has a speci cation de ned within an object. Speci cation Matching de nes all of the speci cations within a module. All of the others have a speci cation that is separate. Most of the techniques require a speci cation be de ned for each component. CORBA only requires the interface speci cation of the service component. The Formal Connector approach de nes a separate connector component which connects the two components. Speci cation Matching and Formal Connector support semantic matching. For the stack and queue example described in 3.2, these techniques may well detect incompatibility provided the components are adequately documented. Speci cation Matching, Formal Connector, Software Adaptor, and PROCOL support protocol matching. For the send and receive example described in 4.1, these techniques may well detect protocol incompatibility. Polylith, PolySPIN and Software Adaptor provide matching facilities in the case of mismatch between modules: type mismatch in Polylith and PolySPIN, and protocol mismatch in Software Adaptor. To conclude, each technique is somewhat unique in what it requires. The features are largely distinguished by the goal each technique tries to achieve. Therefore, it would be instructive to restate the main concern of each approach.
to interconnect software components written in di erent languages for execution.
PolySPIN The main goal is seamless, and auto-
matic, support for interoperability in polylingual software environments. By restricting its concern to object oriented languages, it can provide a uniform mechanism to support for polylingual interoperability.
CORBA IDL The primary goal is to provide an
open object infrastructure, and common speci cation language, to support objects written in di erent languages running on di erent systems to interact with each other.
Formal Connector The main concern of this ap-
proach is to provide theoretic background for architectural connectors so that architectural compatibility can be checked in a way similar to type checking in a programming language.
Software Adaptor The main goal is to devise an
interface de nition so that the de nition can be e ectively used to check for protocol compatibility between components and to provide an adaptor for making the two components work together.
Other interesting categories to further characterize these techniques are level of programming; technique uses a module containing signatures, component (CORBA, Formal Connector, Software pre-/post-conditions, and protocols to check for Adaptor) or object level (Speci cation Matching, both semantic and protocol mismatches. PolySPIN PROCOL); design (or architectural) level
Speci cation Matching This
9
(Formal Connector) or implementation level (all others); formal (Speci cation Matching, Formal Connector), and non-formal (all others). Our goal is to exploit the features provided by these various research e orts and to construct a new scheme which would serve our purpose { a reusable component model that is language independent but supports semantic checking.
5 Interoperable Model (ICM)
Component
In section 2, we described the use of protocols in DOSAEE. The DOSAEE tool aids software engineers in capturing and specifying protocols. In this section, we elaborate the textual form of the protocol speci cation, and propose a new protocol speci cation language to form what we call the Interoperable Component Model. This model is intended to address several of the uses we have previously discussed. It provides a more complete speci cation that aids in the design of component interactions and it provides sucient information to determine whether two components can interoperate successfully. We will focus on the protocol speci cation syntax in the interest of space. The protocol speci cation is a constrained form of an interaction, as de ned in the UML metamodel [15]. In the UML meta-model, an interaction contains a set of messages specifying the communication between a set of instances. A protocol is more constrained in the sense that it contains a set of messages between exactly two instances. We also want the protocol speci cation not to reveal details of the implementation information. We consider the protocol to be an interconnection mechanism for software systems composed of components, and we describe it as the list of services an object provides, a list of services an object can request from the other object, and a speci cation of the ordering of those services. Consider the example shown in gure 1. A new format for the interface and protocol speci cation of the three components is described as follows. protocol ValidatePIN(Transaction,Database) { Transaction sends validataPin to Database; } protocol InitiateWithdraw(Transaction, TransactionControl) { Transaction sends withdraw to TransactionControl; }
interface ATM { roles: Transaction in ValidatePIN { } Transaction in InitiateWithdraw { } } interface CustomerDatabase { void validatePin(Account, PIN); roles: Database in ValidatePIN { validatePin } } interface TransactionController { Money withdraw(Account, Amount); roles: TransactionControl in InitiateWithdraw { withdraw } }
There are two features of ICM protocols that deserve special attention. First, protocols can be rst class objects. Their de nition is separate from that of the components that they integrate. This enhances the reuse potential for protocols and makes them a concrete realization of a \pattern". Second, the protocol de nes roles rather than naming speci c objects or classes. For example, in the protocol ValidatePIN, roles of Transaction and Database are speci ed. Also, message information is described in the protocol speci cation: sender, receiver, and name of the method. The interface description speci es signatures for provided methods and roles played in the protocols in which it is participating. For example, the ATM interface plays the role of Transaction in both ValidatePIN and InitiateWithdraw protocol. The ATM interface does not have any method listed since it does not provide any. In role descriptions, names of the methods involved in the protocol are listed. By describing roles played in protocols, the interface now ful lls our component model | lists services provided, services requested, and the ordering of those services. (Absolute order of messages is not shown in the description, but additional language constructs can be used in the role description to specify message orders.) In the example there is one message per protocol, but there can be more than one sending and receiving message as long as those messages are semantically part of the protocol, as will be shown later. CORBA IDL is the only one of the approaches reviewed that supports inheritance. Since the IDL only speci es method signatures, inheritance does not introduce any more problems than does class inheritance. However, inheriting an interface that contains a protocol speci cation can cause some interesting
10
problems.4 Consider again the example described in gure 1. At the interface TransactionController, the withdraw method would return a speci ed amount of money after it checked to ensure a sucient balance. The balance checking might have been implemented within the withdraw method. However, we can have it explicitly speci ed at the interface using the \extends" construct as in Java. The interface can be extended to satisfy the change as follows: interface BCTransactionController extends TransactionController { boolean balanceCheck(Account, Amount); roles: BCTransactionControl in BCInitiateWithdraw { balanceCheck, withdraw } }
BC stands for balance check. When one interface inherits from another interface, the subinterface acquires all the method de nitions and roles from the super-interface. An interface can inherit more than one interface (multiple inheritance). Note that the methods lists in the role description implicitly specify the order of methods being invoked: balanceCheck followed by withdraw. The BCIntiateWithdraw (BCIW) protocol has to be modi ed due to this change. protocol BCInitiateWithdraw(Transaction, BCTransactionControl) { Transaction sends balanceCheck to BCTransactionControl; Transaction sends withdraw to BCTransactionControl; }
Now, the interface BCTC can play either the role of TransactionControl in IW protocol or the role of BCTransactionControl in the BCIW protocol. Note that the ATM interface needs no change. An ATM component can interact with both TC and BCTC components. We do not consider inheriting the protocol itself. The BCIW protocol could be inherited from the IW protocol, but there is no advantage in doing so. It only adds complexity in the inheritance structure. A protocol is a contract that supports identi cation of interfaces that conform to the roles and message patterns that it de nes just as an interface is a contract that supports the identi cation of components that implement the methods that are speci ed
in the interface. As long as any two interfaces conform to a protocol they can interact together. For example, consider a BankCustomer interface and a BankAccountant interface shown below. interface BankCustomer { roles: Transaction in InitiateWithdraw { } } interface BankAccountant { Money withdraw(Account, Amount); roles: TransactionControl in InitiateWithdraw { withdraw } }
They conform to the IW protocol (i.e., protocol match), and can interact with each other. Assume you have a BankCustomer component and want to nd another component that can interact with it. You know that the BankCustomer component participates in the InitiateWithdraw protocol. You can search a component library for a component that implements an interface that plays a corresponding role in the same protocol. In CORBA IDL, if a component is modi ed by adding/deleting a part of its implementation, the corresponding interface has to be modi ed to conform to the change, or vice versa. In ICM, not only the interface but the protocol and the other party of the protocol may have to change. Therefore, we need a conformance mechanism to trace any change in the interface, protocol, and the component that implements the interface. This points out an inherent drawback to the use of protocols. There is the danger that they will be de ned so speci cally that implementation details of the objects playing roles must be known to check for conformance. There is a de nite trade-o between more complete speci cation and the exibility that one wishes to achieve in an object-oriented design. The interactions between components should always be capable of being de ned at a domain level and in terms of responsibilities. Good class design and the use of only public methods from the object's interface should ensure that the protocol de nition does not become too low level. The next section analyzes our approach. We compare it to the previous approaches reviewed in section 4.
6 Analysis of Results
Inheritance of interface with protocol description has not Three issues concerning module interoperability were been a focus of research to the best of our knowledge. raised in section 4. These issues are key factors to 4
11
be addressed for a component model. The ICM addresses the rst issue | How to specify components so that they can be designed to interoperate with each other. The other two issues are module identi cation and module adaptation. Our research has addressed the rst area, the second follows from the completeness of the ICM speci cation. The third area can be built on top of the ICM speci cation and will be the subject of future research. Some of the working component models in the industry are CORBA IDL, Microsoft COM, and JavaBeans [7]. CORBA IDL was reviewed in this paper, but the other two were not because they follow the same pro le as CORBA. All three models utilize an interface speci cation on the service module. None of the three address the second and third issues; however, none of them addresses semantic or protocol mismatch issues. In section 4.8, several criteria were listed to compare each of the approaches. One problem with the conventional procedure call mechanism used in OO languages is its asymmetric nature: The Sender speci es who it sends to, but the Receiver doesn't have any control over the received message. To be symmetric and to support encapsulation of its implementation, the Receiver has to exercise access control on its methods. This issue has been raised by Yellin and Strom in [16] | having the speci cation on the service module only does not support the true sense of interoperability. The interface speci cation of an OO system has to be provided for both the sender and receiver sides. None of the previous work can describe an interface of a software module interacting to more than one module. In real applications, one software module may well interact with several modules, and the interface and protocol must be able to specify all the interactions. In our approach, the interface can describe more than one module it is interacting with by specifying protocol names at the interface. ICM is similar to the Software Adaptor approach in that it is component based, supports OO languages, does not support multi-language, and has separate speci cations on each side. Both of them are language independent | the speci cation can be used for components implemented in any OO language. It is di erent from the Software Adaptor approach in that in the protocol speci cation, the Software Adaptor uses a state transition model to specify the sequence of messages. In ICM, the sequence information is not explicitly speci ed in the components' speci cation, it is in the protocol de nition. The Software Adaptor describes collaboration between only two modules, but in ICM, an interface can describe
more than one module for collaboration. Protocol adapters are not supported in ICM. In section 4.8 several criteria were listed to compare each of the approach. The ICM according to the criteria is as shown at Table 2. Semantic checking is not yet considered in ICM. It can be done by using pre-/post-conditions. This technique can be added into our model where the method signatures are listed in the interface. These conditions can be used for testing the functionality of interoperation. However, we don't attempt to specify the interface and protocol in every possible detail. Helm et. el. [6] suggest a form referred to as a Contract to specify behavioral compositions and the responsibilities on participating objects. A contract de nes a set of communicating participants and their contractual obligations. Classes conforming to the contract can interact with each other. This is a lot like our approach. But one di erence is that the Contract discloses details of implementation information about the classes involved in the contract. Our approach does not reveal any of the implementation details. Checking for interoperability and testing the functionality of interoperation are di erent issues even though there are some overlap. The more checking done, the less testing needed. The less checking done, the more testing needed. Where the emphasis is on checking, there has to be more speci cation on the interface than simple method signatures. Where the emphasis is on testing, there has to be more test cases to uncover possible semantic/protocol mismatches. The protocol match can be checked both at the syntactic level and the semantic level. The syntactic match can be checked by examining the protocol name, and participants declared in the protocol. Semantic checking can be accomplished by using a component interaction testing technique for creating test scenarios for the components. The interface information can be readily used for documenting a component and as a source to generate test cases for interface/protocol testing. A future goal for this work is to further automate the process of reading the interface and protocol speci cation of a component and determine the interoperability. The tool would automatically generate test cases for checking functional interoperability of components.
12
7 Conclusion We have presented our research activities that address software interoperability and component models. Component level software development is receiv-
Module OO Support Multi-lang Additional Spec Separate Spec Spec at Sem/Protcl Match Matcher component yes no protocol, sequence yes both sides not yet no
Table 2: Module interoperation categories of ICM ing much attention in recent years due to its promise [6] R. Helm, I.M. Holland, and D. Gangopadhyay, of plug-and-playable software. The current interest \Contracts: Specifying Behavioral Compositions in architectural software design has a great e ect on in Object-Oriented Systems," OOPSLA, 1990. componentizing software module. A component plays TM the role of reusable software unit, and can interop- [7] JavaSoft, JavaBeans 1.0 API Speci cation, http://java.sun.com/beans. erate with other software modules if their interfaces (and protocols) match. Our proposed model | the [8] B.H. Liskov and J.M. Wing \A New De nition Interoperable Component Model is based on interof the Subtype Relation," Lecture Notes in Comface and protocol speci cations and can be applied puter Science 707 Springer-Verlag, 1993. to mainstream OO languages like Java, C++ and Smalltalk. [9] D.R. Musser and A. Saini, C++ Programming The component model we have presented is a with the Standard Template Library, Addisonnovel approach toward the speci cation of plug-andWesley, 1995. playable software modules. Most component models are only concerned about syntactic level interop- [10] Object Management Group, The Common Object Request Broker: Architecture and Speci caerability checking. Even though some models (e.g., tion., John Wiley & Sons, Inc., 1992. Speci cation Matching covered in 4.1) address semantic level interoperability checking, their speci - [11] J. Purtilo and J.M. Atlee, \Module Reuse by Incations are glued within the module; there is no septerface Adaptation," Software Practice and Exaration between the interface and implementation. perience, 21(6), June 1991. Currently, the component model is being investigated for use in veri cation. Future work will [12] J. Purtilo, \The Polylith software bus," ACM consider the binding of the component model to inTransactions on Programming Languages and dustrial standard platforms | the CORBA and Java Systems, 16(1), January 1994. component models. [13] SPS, Domain Oriented Software Analysis and Engineering Environment, www.sps.com/ company/techfocus/modeling/dosaee.html. D. Ullman, Elements of ML Program[1] R. Allen and D. Garlan, \Formal Connectors," [14] Je rey ming, Prentice-Hall, 1994. CMU Tech Report CMU-CS-94-115 [15] Rational Software Corporation, UML Seman[2] D. Barrett, A. Kaplan and J. Wileden, \Autics, http://www.rational.com/uml/semantics/. tomated Support for Seamless Interoperability in Polylingual Software Systems," 4th Sympo- [16] D. Yellin, and R. Strom, \Interfaces, Protocols, and Semi-Automatic Construction of Software sium on the Foundations of Software EngineerAdaptors," OOPSLA, 1994. ing, Oct. 1996. Zaremski and J.M. Wing, \Signature [3] J. Bos and C. La ra, \PROCOL A Parallel Ob- [17] A.M. Matching: A Key to Reuse," Proc. ACM SIGject Language with Protocols," OOPSLA, 1989. SOFT Symp. on the Foundations of Software Engineering, December 1993. [4] L. Cardelli, \A semantics of multiple inheritance," Info. and Computation, 76 (1988) 138- [18] A.M. Zaremski and J.M. Wing, \Speci cation 164. Matching of Software Components," Proc. ACM SIGSOFT Symp. on the Foundations of Software [5] John Guttag and James Horning, Larch: LanEngineering, October 1995. guages and Tools for Formal Speci cation, Springer-Verlag, 1993.
References
13
