UNU/IIST
International Institute for Software Technology
Contract-Oriented Development of
Compo-nent Software
Zhiming Liu, He Jifeng and Xiaoshan Li
April 2004UNU-IIST and UNU-IIST Reports
UNU-IIST(United Nations University International Institute for Software Technology) is a Research and Training Centre of the United Nations University (UNU). It is based in Macau, and was founded in 1991. It started oper-ations in July 1992. UNU-IISTis jointly funded by the Governor of Macau and the governments of the People’s Republic of China and Portugal through a contribution to the UNU Endownment Fund. As well as providing two-thirds of the endownment fund, the Macau authorities also supplyUNU-IISTwith its office premises and furniture and subsidise fellow accommodation.
The mission ofUNU-IISTis to assist developing countries in the application and development of software tech-nology.
UNU-IISTcontributes through its programmatic activities:
1. Advanced development projects, in which software techniques supported by tools are applied, 2. Research projects, in which new techniques for software development are investigated,
3. Curriculum development projects, in which courses of software technology for universities in developing countries are developed,
4. University development projects, which complement the curriculum development projects by aiming to strengthen all aspects of computer science teaching in universities in developing countries,
5. Schools and Courses, which typically teach advanced software development techniques, 6. Events, in which conferences and workshops are organised or supported byUNU-IIST, and
7. Dissemination, in whichUNU-IISTregularly distributes to developing countries information on interna-tional progress of software technology.
Fellows, who are young scientists and engineers from developing countries, are invited to actively participate in all these projects. By doing the projects they are trained.
At present, the technical focus ofUNU-IISTis onformal methodsfor software development. UNU-IISTis an internationally recognised center in the area of formal methods. However, no software technique is universally applicable. We are prepared to choose complementary techniques for our projects, if necessary.
UNU-IISTproduces a report series. Reports are either Research R, Technical T, Compendia C or Adminis-trative A. They are records ofUNU-IISTactivities and research and development achievements. Many of the reports are also published in conference proceedings and journals.
Please write toUNU-IISTat P.O. Box 3058, Macau or visitUNU-IIST’s home page:http://www.iist.unu.edu, if you would like to know more aboutUNU-IISTand its report series.
UNU/IIST
International Institute for Software Technology
P.O. Box 3058 Macau
Contract-Oriented Development of
Compo-nent Software
Zhiming Liu, He Jifeng and Xiaoshan Li
Abstract
We present a model for component software. We describe how components are specified at the inter-face level, design level and how they are composed. From its external view, a component consists a set of interfaces, provided to or required from its environment. From its internal view, a component is an executable code that can be coupled with other components via its interfaces. The developer has to ensure that the specification of a component is met by its design and implementation. We also combine component-based and object-oriented techniques in component-based software development
Zhiming Liu is a research fellow at UNU/IIST, on leave from Department of Computer Science at the University of Liecester, Liecester, England where he is lecture in computer science. His research interests include theory of computing systems, including sound methods for specification, verification and refine-ment of fault-tolerant, real-time and concurrent systems, and formal techniques for OO developrefine-ment. His teaching interests are Communication and Concurrency, Concurrent and Distributed Programming, Internet Security, Software Engineering, Formal specification and Design of Computer Systems. E-mail: [email protected].
He Jifeng is a senior research fellow of UNU/IIST. He is also a professor of computer science at East China Normal University and Shanghai Jiao Tong University. His research interests include the Math-ematical theory of programming and refined methods, design techniques for the mixed software and hardware systems. E-mail: [email protected].
Xiaoshan Li is an Associate Professor at the University of Macau. His research areas are interval tem-poral logic, formal specification and simulation of computer systems, formal methods in system design and implementation. E-mail: [email protected].
Contents i
Contents
1 Introduction 1 2 Interfaces 2 2.1 Merge interfaces . . . 4 3 Contracts 4 3.1 Conceptual model . . . 4 3.2 Contract . . . 53.3 Merge and refinement . . . 8
4 Component 9 4.1 Design class model . . . 10
4.2 Components . . . 11
4.3 Method hiding . . . 11
4.4 Semantics components . . . 12
4.5 Refinement and composition of components . . . 15
5 Client-Server Systems 16 6 Conclusion and Discussion 17 6.1 Conclusion . . . 17
6.2 Points of discussion . . . 18
Introduction 1
1
Introduction
Using components to build and maintain software systems is not a new idea. However, it is today’s growing complexity of these systems that forces us to turn this idea into practice [Szy02, CD01, HC01]. While component technologies such as COM [Mic96], CORBA [OMG00], and Enterprise JavaBeans [Mic] are widely used, there is so far no agreement on standard technologies for designing and creating components, nor on methods for composing them. Finding appropriate formal approaches for specify-ing components, the architectures for composspecify-ing them, and the methods for component-based software construction, is correspondingly challenging. In this paper, we consider a contract-oriented approach to the specification, design and composition of components. Component specification is essential as it is impossible to manage change, substitution and composition of components if components have not been properly specified.
When we specify a component, it is important to separate different views about the component. From its user’s (i.e. external) point of view, a componentP consists a set of provided services [Szy02, Bro]. The syntactic specification of the provided services is described by an interface, defining the operations that the component provides with their signatures are. This is also called the syntactic specification of a component, such as COM and CORBA that use IDL [Gud01], and JavaBeans that uses Java Program-ming Language to specify component interfaces. Such a syntactic specification of a component does not provide any information about the effect, i.e. the functionality of invoking an operation of a component or the behavior, i.e. the temporal order of the interface operations, of the component.
For the functional specification of the operations in an interface, it is however necessary to know the conceptual state of the component. Consequently, the interface specification contains a so-called infor-mation model [CD01, Fil02]. In the context of such a model, we specify an operationop by a design
p(x) `Q(x, x0)in Hoare and He’s Unifying Theories of Programming (UTP) [HH98] that is seen as a
contract between the component and its client [CD01, HC01]. This definition of a contract also agrees with that of [Mey92, Mey97]. To use the serviceop, a client has to ensure the pre-conditionp(x), and when this is true the component must guarantee the post-conditionQ. We then define a contract of an interface by associating the interface with a set of features that we will call fields and assigning each a design MSpec(op)to each interface operationop. The types of the fields are given in a data/class model. The contract for the provided interface of a component allows the user to check whether the component provides the services required by other components in the system, without the need to know the design and implementation of the component. It also commits (or requires) the designers of the component who have to design the component’s provided services. A designer of the component under consideration (CuC) may decide to use services provided by other components. These services are called required services [Szy02]of CuC. Components that provide the required services of CuC can be built by another team or bought as a component-off-the-self (COTS). To use a component to assemble a system, one needs to know the specifications of both its provided and required services.
We will specify the design of a component by giving each operation op in the provided interface a program specification text MImpl(op) in the object-oriented specification language (OOL) defined in [HLL03b, LHLL03]. In MImpl(op), calls to operations in a required interface are allowed. With the
Interfaces 2
refinement calculus of object-oriented designs (RCOOD) in OOL [HLL02, HLL03b], we can verify whether MImpl(op) refines the specification ofop given in a contract of the provided interface. The verifier of a component needs to know the contracts of the provided interfaces, the contracts of the required interfaces, and the specification text for each operationop of the provided interface. We can thus understand a component as a relation between contracts of the required interfaces and contracts of the provided interface: given a contract for each required interface, we can calculate a design of anop from MImpl(op)and check whether it conforms to the specification MSpec(op)defined by the contract of the provided interface. A design of a component can be further refined into an implementation by refining the data/class model and then operation specifications MImpl(op).
A component assumes an architectural context defined by its interfaces. We connect or compose two components P1 and P2 by linking the operations in the provided interface of one component to the
matching operations of a required interface of another. For this, we have to check whether the provided interface of one componentP1contains the operations of a required interface of another componentP2,
and whether the contract of the provided interface ofP1 meets the contract of the required interface of P2. IfP1 andP2match well, the compositionP1||P2forms another component. The provided interface
ofP1||P2is the merge of the provided interfaces ofP1andP2. The required interfaces ofP1||P2are the
union of required interfaces ofP1 andP2, excluding (by hiding) the matched interfaces ofP1 andP2.
For defining composition, interfaces can be hidden and renamed.
A component is also replaceable, meaning that the developer can replace one component with another, may be better, as long as the new one provides and requests the same services. An component is better than another if it can provide more services, i.e. the contracts for its provided interfaces refine those of the other, with the same required services. Component replaceability is based on the notion of component refinement.
After this introduction, Section 2 defines the notions of interfaces and composition of interfaces by merg-ing them together. We define notations for specification of a contract in Section 3. Contract refinement and operation hiding are defined in this section. We devote Section 4 to the definition of components, their refinement and composition. Section 5 concludes the paper with discussions and possible exten-sions to the model. We will take part of the example of the ParcelCall system in [Fil02] to illustrate our approach and to show the advantages of the separation of the concerns in our framework.
As a starting point, we only deal with the functional/service specification of components and deals with functional compatibility. In Section 5, we give a discussion on the alternative ways to deal with behav-ioral specification and compatibility. This paper is not about development processes either. However, we will give an overview on how the model can be used in a component-based development together with an object-oriented implementation.
2
Interfaces
An interfaceIis a set of operation (or method) signatures, of the form op(in:U x,out:V y, inout:
W z), whereopis the name of the operation,xare the value parameters of typesU,ythe result
Interfaces 3
eters of typesV, andzthe value-result parameters of typesW. An interface can be specified as a family of operation signatures in the following format:
InterfaceI{
Method: op1(in:U1x1,out:V1y1,inout:W1z1);
. . .; opk(in:Ukxk,out:Vk yk,inout:W1zk) } DispatchParcel() LocalizeParcel() IParcelLoc IParcelInfo Where() <<comp spec>> <<comp spec>> CarrierSystem <<comp spec>> GIS <<comp spec>> MLS GTS CustomerService ISomeInterface
Figure 1: Architecture of ParcelCall
Figure 1 shows the ParcelCall system in [Fil02] that has three main components:
• a Mobile Logistic Server (MLS): is an exchange point or a transport unit (container, trailer, freight wagon, etc). It always knows its current location via the GPS satellite positioning system.
• a Goods Tracing Server (GTS): keeps track of all the parcels registered in the ParcelCall system. GTS is also the component which is integrated with the legacy systems of transport or logistic companies.
• a Goods Information Server (GIS): is the component which interacts with the customers and pro-vides the authorized customers the current location of their parcel, keeps them informed in case of delivery delays, etc.
In Figure 1, UML notation for interfaces and components is used.The provided interface of GIS com-ponent will establish communication with the customer: for instance a customer can request for finding the current location of a parcel viaLocateP arcel. The specification of this interface can be described as follows, where we usePPSto denote the powerset of a setS
InterfaceCustomerService{
Method: LocateParcel(in:PName pId,CName sId),out:Position location); DispatchParcel(in:PName pId,CName sId)}
Contracts 4
2.1 Merge interfaces
It is often the case that there are a number of components, each providing a part of the operations in the required interface of another component. We thus need to merge these components to provide one single interface to match the interface required by the other component.
Two interfacesI1andI2 are composable provided that every operation name in bothI1andI2must be
assigned the same signature. This condition is not too restrictive as to use a component designed for an application in another or specialize a generic component for a special application, renaming or adding a connector component [AG97, Sel98] can be used to customize the component.
Definition 1 Let{Ik :|k ∈ K}be a finite family of composable interfaces. Their merge]k∈KIk is
defined by]k∈KIkdef= ∪k∈KIk.
3
Contracts
Only a syntactic specification of its interface is not enough for the use or the design of a component. We also need to specify the effect, i.e. the functionality, of invoking an interface operation. This requires one to associate the interface to a conceptual state space, and a specification of how the states are changed by the operation under certain pre-conditions. We view such a functional specification of an interface as a contract between the component client and the component developer. The contract is the specification of the component that the developer has to implement. The contract is also between a user of the component and a provider of an implementation of the interface: the component has to provide the services promised by the specification provided that the user uses the component according to the precondition [Szy02].
3.1 Conceptual model
To define the conceptual state space of a contract for an interface and the types for the parameters of the interface operations, we assume that a type is either a primitive data type (such as the integers, the Booleans, etc.) or a class of objects (such as a Java class). This allows our framework to support both imperative and object-oriented programming in the design of a component.
The type definitions in fact form a conceptual class diagram [LHLC03, LHLL03] that is a UML class di-agram [BRJ99] in which the classes have no methods and the associations have no direction of visibility or navigation. Figure 2 is an example of a conceptual model for a library system. A UML class dia-gram can be specified by a class declaration section of an object-oriented prodia-gram in the object-oriented specification language (OOL) developed in [HLL03b, LHLL03] of the form
class1;class2;. . .;classn
Contracts 5
where each classiis of the form
ClassN extendsM {
public U1u1, . . . , Ukuk;
}
where
• N andM are distinct names of classes, andM is called the direct superclass ofN.
• Thepublicdeclaration declares the public attributes of the class and their types. Initial values are set when an object is created.
Notice that we do not declare methods for the classes as they will be given in the implementation of the component. Also, we need to declare the public fields as functional specification of operations directly refer to them. In the design model of a component, methods are introduced to realize the specification and then data encapsulation can be applied to make the fields private or protected.
Consider the simple conceptual class diagram in Figure 2 as an example. It is specified as
Class Lib{String name, String address};
Class Publication{String isbn, String title, String author};
Class Copy{String id, String location};
Class Own{Lib lib, P ublication p}; //∗Association
Class Contain{P ublication p, Copy c};//∗Association
Please see [LHLC03, LHLL03] for details on the formalization of UML, and [HLL03b, LHLL03] for the semantics of class declarations.
Publication own contain * 1 Copy 1 * Lib Lib
Figure 2: A conceptual class diagram
3.2 Contract
Given an interfaceI, a conceptual modelM, a setAof variable declarations of the formT xwhereT is either a primitive type or a class declared inM, called the type ofx, we define the alphabetαas the
Contracts 6
union of sets of the variables, the input and output parameters of the operations ofI.
inα def= A∪ {x∈x∪z|op(in:U x,out:V y,inout:W z)∈I} outα def= A∪ {y∈y∪z|op(in:U x,out:V y,inout:W z)∈I} outα0 def= {x0|x∈outα}, α def= inα∪outα
A conceptual state forhI, Miis a well-typed mapping from the variablesα to their value spaces. It is in fact a UML object diagram ofM plus values of variables in outαof primitive types that is a snapshot of the models consisting the current objects of the classes and links by the associations among these objects, as well as the values of variables of primitive types. A change of such a state is carried out by creating or destroying existing objects, forming or breaking links among objects, modifying values of object attributes, and changing values of some variables of primitive types. A specification of an operationop(in:U x,out:V y,inout:W z)in an alphabetαis a framed designβ:Dwhere
• β, a subset ofinα, is the frame ofDcontaining the variables to be changed byD.
• D= (b`Q)is a design [HH98] describing the behavior of the method: β: (b`Q)def= b∧ok⇒Q∧ok0∧ ∧x∈inα\β(x0 =x)
Predicatebis the assumption on the variables and input parameters which the method can rely on when it is activated, while predicateQis the commitment which must be true when the execution terminates. ok and ok0 are used to describe the termination behavior of op. We will omit the frames in the examples by assuming that a design only changes those variables whose primed versions appear are mentioned.
The variables of inα are used to record the values of the variables in A and input parameters x on the activation ofop, and the variables of outαthe values of the corresponding variables and outgoing parametersyon the termination of a method. For the conceptual model in Figure 2, let
Adef= {PPublicationP,PCopyCp,PContaincon,Liblib,POwn own}
wherePS is the power set ofS. The operationRecordCopy(in:String pid, String cid)that records a new copy of a given publication can be specified as
{con, Cp}: ∃p∈P.p.isbn=pid∧< lib, p >∈own∧ ¬∃c∈Cp.c.id=cid` ∃c0∈Cp0.c0.id=cid∧ ∃p∈P.p.isbn=pid
∧ con0=con∪ {< p, c0 >}
Contracts 7
Definition 2 A contract is a tupleC = (I, M, A,MSpec,Init) whereI is an interface,M is a con-ceptual model,Ais a set of variables, called the fields ofC, whose types are either declared inMor as primitive types, and MSpec a function that maps each operation ofIto a specification, and Init an initial condition that defines some values to fields as their initial values.
If no field is of an object type, we will omit the conceptual model from the specification of a contract. One can add invariants to the conceptual model that are to be preserved by specifications of all the interface operations [HL03, LHLC03].
In modular programming, a primitive contract is a specification of a module that defines the behavior of the operations in its interface. However, later we will see that contracts can be merged to form another contract and this corresponds to the merge of a number of modules. In object-orient programming, a primitive contract specifies an initialized class, i.e. an object, whose public methods are operations in the interface. This class wraps the classes in the conceptual modelM, and provides the interface operations to the environment. In the Java-like OOL [HLL02, HLL03b], such a contract can be specified as
InterfaceI{Meth:{m()|m()∈I}};
M; //∗class declarations for the conceptual model
Class C implementsI{Attr: A=Init;
Meth: {m(){MSpec(m)} |m∈I};
main(){C.N ew(x)} }
where main provides the condition Init when creating the new object of Cattached to x with the initial values of the attributes in A(see Section 4.1 for this command and [HLL03b, LHLL03] for its semantics).
Example A contract for interface CustomerService of ParcelCall assigns a specification to each method and can be written as follows, where MSpec(op)is given as the specification following the name op of each operation. We present a contract in a style such that the name of the interface is followed by the fields declarations, then the initial condition, and finally the operations with their specifications:
<<Contract>> CS
InterfaceCustomerService
Attr: PPNameP; //∗set of parcel names
PCNameS; //∗set of customer names
CName×PName owns; //∗owns(s, p):sownsp
PName7−→Position loc; //∗loc(p): the location ofp Init: P =∅∧S=∅;
Meth: LocateParcel(in:PName pId,CName sId,out:Position location){
pId∈P∧sId∈S∧owns(sId,pId)`location0 =loc(pId)}; DispatchParcel(in:PName pId,CName sId) : {
pId6∈P `(P0 =P∪ {pId})∧(S0=S∪ {sId})∧
(owns0=owns∪ {(sId,pId)})∧(loc0 =loc∪ {pId→(0,0)})
Contracts 8
3.3 Merge and refinement
Contracts of interfaces can be merged only when their interfaces are composable and the specifications of the common methods are consistent. This merge will be used to calculate the provided and required services when components are composed.
Definition 3 Contracts(Ii, Mi, Ai,MSpeci,Initi),i= 1,2, are consistent if
1. I1andI2 are composable.
2. Ifxis declared in bothA1andA2, it has the same type; and Init1(x) =Init2(x).
3. Any class nameCin bothM1 andM2has the same class declaration in them.
4. MSpec1(op)⇔MSpec2(op)for allop∈I1∩I2
This definition can be extended to a finite family of contracts.
Definition 4 Let{Ck= (Ik, Mk, Ak,MSpeck, Initk)}be a consistent finite family of contracts. Their
merge, (denoted bykk∈K Ck), is defined by
Idef= ]kIk, Mdef= ⊕kMk, Adef= ⊕kAk, Initdef= ⊕kInitk, MSpecdef= ⊕kMspeck
where ⊕denotes the overriding operator, e.g. (MSpeck⊕MSpeck+1)(op) = MSpeck+1(op)if op ∈
Ik∩Ik+1; MSpeck(op)ifop∈Ikbutop6∈Ik+1; MSpeck+1(op)otherwise.
A merge of a family of contracts corresponds the construction of a conceptual model from the partial models of the application domain in the contracts. There are three cases about the partial models:
1. The contracts do not share any fields or modelling elements in their conceptual models. In this case, the system formed by the components of these contracts are most loosely coupled. All com-munications are via method invocations. Such a system is easy to design and maintain. Composing these components is only plug-in composition.
2. The contracts may share fields, but their conceptual models do not share any common model ele-ments. In this case, application domain is partitioned by the conceptual models of these contracts. And components of the system are also quite loosely coupled and easy to construct and maintain. When composing these components, some simple wiring is needed.
Component 9
3. The contracts share common model elements in their conceptual models. The refinement/design of the contracts has to preserve the consistency and integrity, generally specified by state invariants, of the model. The more elements they share, the more tightly the components are coupled and the more wiring is needed when composing these components.
Definition 5 We say that a contract C1 = (I1, M1, A1,MSpec1, Init1) is (downwards) refined by C2 = (I2, M2, A2, MSpec2, Init2), denoted byC1 v C2, if there is a mapping ρ from A1 to A2
satisfying
1. The initial state is preserved: (x := Init1(x);ρ) v (y := Init2(y)), where x is the list of
variables defined inA1, andythe list of variables inA2. Notice that we have used a UTP design
to represent a refinement mapping.
2. The behavior of the operations of C1 are preserved: every operation op declared in I1 is also
declared inI2and(MSpec1(op);ρ) v (ρ;MSpec2(op)).
An upwards refinement relation can be similar defined in terms of a refinement mapping fromA2toA1.
The refinement relation between contracts will be used to define component refinement. The state map-pingρallows that a component developed in an application domain can be used in another application domain if such a mapping can be found.
Theorem 1 Contract refinement enjoys the properties of program refinement.
1. vis reflexive and transitive and a pre-order.
2. (An upper bound condition) The merge of a family of contracts refines any contract in the family, i.e.{Ck|k∈K}be a family of consistent contracts,Ci vkk∈K Ckfor anyi∈K.
3. (An isotonicity condition) The refinement relation is preserved by the merge operation on con-tracts, i.e. let{Cki |k∈K},i= 1,2, be families of consistent contracts without shared fields. If
C1
k vCk2for allk, thenkk∈KCk1 v kk∈K Ck2.
We define the equivalence relation by≡def=v ∩ w.
4
Component
A component consists of a provided interface and optionally a required interface, and an executable code which can be coupled to the codes of other components via their interfaces.
Component 10
The external behavior of a component is specified by the contracts of its interfaces. A design of a component has to reorganize the data to realize the conceptual states, and realize the conceptual models in the contract of the component by software classes. That is the conceptual model has to be transformed into a design model.
4.1 Design class model
We slightly generalize the definition of a contract to allow the declarations of methods in the class model that is now called a design class model, which is specified as a sequence of class declarations
class1;. . .;classn, each is of the form defined in [HLL03b]:
ClassN extendsM {
private U1u1, . . . , Ukuk;
protectedV1v1, . . . , V`v`;
public W1w1, . . . , Wmwm;
method m1(parameters1){c1};· · ·;mn(parametersn){cn}
}
whereparametersiis of the form<in:T1ixi,out:T2iyi,inout:T3izi>consisting of the value,
result and value-result parameters ofmi,ci of methodmi is a command called the body ofmi. We use
M eth(M)to denote the set of all methods declared in a design modelM. A commandcis specified according to the following syntax:
c::= β:p`Q design
|skip|chaos skip and abort
|varT x=e|endx variable declaration and undeclaration
|le:=e|c;c assignment and sequence
|c¢b¤c|b∗c conditional choice and loop
|le.m(e)|op(e) method call and operation call
|C.N ew(x)[e] Creating a new object with initail valuesefor its attributes
wherebis a Boolean expression,eis an expression, andleis an expression which may appear on the left hand side of an assignment and is of the formle ::=x|le.a|self wherexa simple variable andais an attribute of an object. We useif{(bi−→Pi)|1≤i≤n}fito denote the multiple choice statement.
Expressions, which can appear on the right hand sides of assignments, are constructed according to the rules e ::= x|null|self|e.a|eis C|(C)e|f(e), wherenull represents the special object of the special classN ullthat is a subclass of all class and hasnullas its unique object,e.ais thea-attribute ofe,(C)e
is the type casting,eisCis the type test. A full semantics of this language is given in [HLL03b].
Component 11
4.2 Components
Definition 6 A componentP is a tuple< O, I, M, A, MImpl, Init, R >where
• Ois an interface, called the provided or (output) interface ofP.
• I is an interface disjoint fromO, called the internal interface ofP
• M is a design class model.
• Ais a set of fields whose types are all declared inM.
• MImpl maps each operation declared inO∪I to a pair(α,Q), whereQis a command written in the above OOL, andαis the alphabet obtained fromAand the input and output parameters of the operations inO∪I.
• R, is the interface that is disjoint fromO andI and consists of the operations (not methods of classes in M) which are referenced in the program text MImpl(op) and bodies of methods in
M eth(M)but not inO∪I, whereop∈O∪I.Ris called the input or required interface ofP.
We callC = (O, I, M, A,MImpl,Init)a generalized contract, as it has internal operations and MImpl provides the specification of each operation ofOin terms a general OOL command.
Hence, we will use 4-tupleP = (C, I, O, R)denote a component, whereCis a generalized contract for the interfaceO]I.
A contract forRis called a required service ofP, and a contract of the interfaceOa provided service. Operations in R can be seen as holes in the component where their specifications or implementation given in other components that are to be plugged in. Therefore, the provided services of a component depends on its required services plugged in from other components. This leads to the definition of our semantics of a component.
In the above definition, we introduced private operations so that we can hide an output operation by making it a private operation. This will keep the definition MImpl valid as the hidden operations may be called in MImpl(op).
4.3 Method hiding
Component 12
Definition 7 (Hiding) LetC = (O, I, A, M,MImpl, Init)be a general contract, andH ⊆Oa set of operations. The notationC\Hrepresents the contract
(O\H, I∪H, M, A,MImpl, Init)
whereS\S1 is set-subtraction.
Theorem 2 The hiding operator enjoys the following properties.
1. (C\H)vC. 2. C\∅ ≡ C.
3. C\H ≡ C\(H∩O), whereIis the interface ofC. 4. (C\H1)\H2 ≡ C\(H1∪H2) ≡ (C\H2)\H1
5. (kk∈KCk)\H ≡ kk∈K(Ck\H)
4.4 Semantics components
Definition 8 The semantics of a component P is identified as a binary relation between its required services and their corresponding provided services
[[P]](CR, CO0 ) def
= (CR>> P)vCO0
where the variableCRtakes an arbitrary required service as its value,CO0 takes a provided service forO,
and the notationCR>> P denotes the provided service
(O, F(M), A, MSpec, Init)
whereF(M)is the class model obtained fromM by removing the methods of its classes, and mapping MSpec is defined from the given required service
CR=< R, MR, AR,MSpecR, InitR>
Component 13
by the recursive equations MSpec(op) = M(MImpl(op)), whereMreplaces every call ofop(inexp,outvar) with the actual input parameters inexp, output parameters outvar and value-result parameters vrexp ofO
by its corresponding specification.
M(op(inexp,outvar,vrexp)) def= µ
varT1x=inexp, T2y, T3z=vrexp;MSpecR(op);
outvar,vrexp:=y, z;endx, y, z
¶ ifop(in:T1x,out:T2y,inout:T3z)∈R
M(op(inexp,outvar,vrexp)) def= µ
varT1x=inexp, T2y, T3z=vrexp;MImpl(op); outvar,vrexp:=y, z;endx, y, z
¶ ifop(in:T1x,out:T2y,inout:T3z)∈O∪I
M(v:=e) def= v:=e
M(F(c)) def= F(M(c)) for any comandcand contextF
Notice that when a componentP has an empty set of required interface operations,P is a closed com-ponent and the notationC∅ >> P becomes a constant that is the semantics of the closed programP.
For a given contractCRfor the required interface ofP,CR >> P is a closed component. LetCObe a
contract of the provided interface ofP which serves as the specification of the component. We say that
P correctly realizes or implementsCOwith a given required serviceCRifCOv(CR>> P).
In a modular programming paradigm, a component can be designed and implemented as a module in which each of the operations in the output interface is “programmed” using procedures or functions that are defined either locally in the module or externally in other modules. In this case, the external modules that the component calls methods from must be declared, as well as the types of the attribute values and parameters of its methods. Therefore, a component is in fact not a single module, but an artifact that contains all these declared types and modules. In an object-oriented paradigm, such as Java, a component can be seen as a class that implements the interfaces inO:
M;//* the declaration of the design model
Class P implementsO{Attr: A;
public: mdef= MImpl(m); //* for eachm∈O;
private: opdef= MImpl(op)//* for eachop∈I
}
Thus, after adding the notation for interfaces and contracts to OOL in [HLL03b, LHLL03], the extended language provides a formal model for components and the calculus of contract refinement and compo-nent refinements [HLL03a] , and also extends RCOOD in [HLL02, HLL03b] to for compocompo-nent-based development.
Example Now we define a component GIS in the ParcelCall system to provide the services to cus-tomers. We will use some Java conventions in writing the specification, such as assignment to a variable
Component 14
with a method call that has anoutparameter.
<<Component>>GIS
Output InterfaceCustomerService
Attr: PPNameP;//∗set of parcel names PCNameS; //∗set of customer names
CName×PName owns; //∗owns(s, p):sownsp
(PName7−→Position)loc; //∗loc(p)returns the location ofp
Init: P =∅ ∧S=∅;
Meth: LocateParcel(in:PName pId,CNamesId,out:Position location){
if pId∈P∧sId∈S∧owns(sId,pId)//* call required method
thenlocation:=IParcelInfo.Where(pId)elseAbort}; DispatchParcel(in:PName pId,CName sId){
if pId6∈P ∧sId6∈Sthen(P :=P ∪ {pId};S :=S∪ {sId}; owns:=owns∪ {(sId, pId)};IParcelInfo.Deal(pId))elsechaos};
Input InterfaceP arcelinf o
Attr: PP N ame P; //∗set of parcel names
(PName7−→Position)loc; //∗loc(p)returns the location ofp;
Meth: Where(in:PName pId,out:Coordinates location){ Deal(in:PName pId)};
<<Contract>>Parcelinfo IParcelInfo::Init:P =∅;
IParcelInfo::Where(in:PNamepId,out:Position location) :
pId∈P `location:=loc(pId);
IParcelInfo::Deal(in:PName pId) :pId6∈P `loc0(pId) = (0,0)
We can calculate ParcelInfo>> GIS vCS. We have kept the attributeloc :P N ame7−→ P osition to avoid from defining a state mapping in the proof of the refinement. In the following part of the example, we provide a definition of component GTS to implement the contractP arcelInf o, that need the specification of a design class.
<<Component>>GTS
ClassParcel{PName id; Position location= (0,0); Positionloc(){return:=location}}; Ouput Interface IParcelInfo
Attr: PParcel Parcels: ;
Init: Parcels=∅;
Meth: Deal(in:PName pId){ Parcel.New(p)[pId];
Parcels:=Parcels∪ {p};endp};
W here(in: PNameid, out: Position location){
varParcelp=P.find(pId);location:=p.loc();endp}
Component 15
Define the refinement mappingρfrom the attributes ofP arcelto those ofP arcelInf o:
ρ(P)def= {p.id|p∈P arcel}
ρ(loc(pId)) =p.location for allpId∈P such that∃p∈Parcel.p.id=pId
ThenP arcelInf ovGT S.
4.5 Refinement and composition of components
For a componentPwith provided and required interfacesOandR, the semantics[[P]]is a binary relation between the input services and output services.
Theorem 3 (Monotonicity and Upwards Closure [Smy78]) LetP =< C, I, O, R >andvRandvO
are the refinement relations among contracts ofRand among contracts ofOrespectively. Then
vR◦[[P]]◦ vO = [[P]]
where◦denotes relational composition.
Thus, for any required servicesCRvCR0 , and provided servicesCOvCO0 , then
[[P]](CR, CO0 )⇒[[P]](CR0 , CO)
A componentP1 is a refinement of a componentP2, denoted byP2 vP1, ifP1 is a sub-relation ofP2.
Definition 9 ComponentP1is a refinement ofP2if
R1 = R2∧O1 = O2∧[[P1]]⇒[[P2]]
Equivalently,P1refinesP2iff for any required serviceCR,(CR>> P2)v(CR>> P1).
We therefore have whenP1refinesP2, then for any given required serviceCRand a contract a provided
Client-Server Systems 16
Definition 10 LetPi = (Ci, Ii, Oi, Ri)be two components with contractsCi = (Oi∪Ii, Mi, Ai), for
i= 1,2. Assume thatI1∩I2=∅,O1∩O2 =∅andR1∩R2 =∅. The compositionP1||P2is defined
to merge their contracts, output interfaces and input interfaces, and to remove those input interfaces of each component that are matched by the output interfaces in another:
P1||P2def=< C1kC2, I1∪I2, O1]O2, R1\O2∪R2\O1>
LetI def= I1∪I2,Rdef= R1\O2∪R2\O1andO def= O1∪O2. The composition ofP1andP2is defined
by [[P1kP2]](CR, CO0 ) def = ∃CR1, CO10 , CR2, CO20 • [[P1]](CR1, CO10 )∧ [[P2]](CR2, CO20 )∧ CR1\(R1\O2) =CO20 \(O2\R1) ∧ CR2\(R2\O1) =CO10 \(O1\R2) ∧ CR=CR1\(R1\O2)kCR2\(R2\O1)∧ C0 O =CO10 \(R2\O1)kCO20 \(R1\O2)
This definition allows an output interface and thus part of provided service of one component to be shared among a number other components. Hiding can be used to internalize the part of a provided service of one component that is used in another component:(P1kP2)\(R1∩O2)\(R2∩O1).
Example We can now composeGIS andGT S. (GIS||GT S)\IP arcelInf o. If we do not consider the relation betweenGT S with other components of the ParcelCall system, this composite component is a closed system that only provides services according to the contract ofCS, but it does not have any required interface. However, to complete the ParcelCall system, we can add a required service interface to get the new location of a parcel from the Mobile Logistic Server component M LS. Alternatively, we add another provided interface ChangLoc()that will be needed as a required interface of Mobile Logistic Server componentM LSto update the location of a parcel.
5
Client-Server Systems
Client-server systems are often seen as applications in component software. The architecture of such a system is organized as a layered structure as illustrated in Figure 3. On the top are the clients that only require services from the components in the next layer. Components in a middle layer provide services to components in the layer above, but requires services from the layer below. The components at the bottom are the basic server components that only provide services to the components above the bottom layer. Components of the same layer have disjoint provided interfaces. The layers are organized according to interface dependencies. The whole system is the composition of the components with the interfaces hidden:
Qdef= ((P11|| · · · ||P1k1)|| · · · ||(Pn1|| · · · ||Pnkn))\All
Conclusion and Discussion 17
whereAlldenotes all the linked interfaces. The construction of such a system can be top-down:
P11 P1k1
P2k2 P22
P21
Pn1 Pn2 Pnki Pnkn
Figure 3: Client-Server Systems
Q1=def (P11|| · · · ||P1k1)
Qj def
= (Qj−1||Pj1|| · · · ||Pjkj)\Ij−1, 1< j≤n
whereQnis the resulting component, andIi,1≤i < nare the linked interfaces.
The system construction can also be bottom-up:
S1=def Pn1|| · · · ||Pnkn
Sj def
= (Qj−1||Pn−(j−1)1|| · · · ||Pn−(j−1)kn−(j−1))\In−(j−1), 1< j≤n
We haveQ=Qn=Sn.
6
Conclusion and Discussion
6.1 Conclusion
We have proposed a model for software components and defined composition and refinement of com-ponents. This allows us to use the existing calculus in [HH98, HLL03b, LHLL03] to reason about and refine components. We have separated the different views about a component. The different views are specified at different levels of abstraction. A component is constructed to provide certain services and these services are specified in terms of the component’s interface and contract. This specification is taken as the requirement specification of the component. The designer of the component has to design and implement the component to satisfy this requirement specification. The design may make use of the provided services of existing components. Such a design can be specified in the object-oriented
Conclusion and Discussion 18
specification notation developed in [HLL03b], that supports incremental and step-wise construction of a component [LHLL03]. Merge and hiding of interfaces for components add more support to incremental construction of component software as well as to restrict the use of some services by certain users. When composing components, one has to check the matchability of the provided services of one compo-nent with the specification of the required services of another, both syntactically and semantically. The syntactic check is only to check the signature of the interface methods. The semantic check is to ensure that the provided service of one component does ensure the service required by another component. This is to check the pre and post conditions of in the specification of the services.
A component system is a composition of a family of components. The contracts of these components provide a decomposition of the application domain both in terms of the static conceptual model and the functionalities or services (use cases). Moreover, the decomposition is first done horizontally, i.e. decomposing according to the whole system’s use cases that are involved in a large number of common concepts (classes) and associations, and use cases of different components are less dependent. And then each group of use cases are decomposed vertically such that use cases can be realized by interactions of a number of components that are invisible to the outside of the system. In fact, vertical decomposition is more relevant to component-based development, as horizontal decomposition is more or less about design of independent components. Based on this discussion, we propose an extension to the UML and RUP use-case driven approach to system development [Kru00] so that components and their interfaces, instead of only classes and class associations [Lar01, Liu02], can be identified to create a component diagram. Then use cases can be described by component sequence diagrams or message sequence chart [Leu94], rather than system sequence diagrams that only describe interactions of actors and the whole system treated as a black box [Lar01, Liu02]. UML2.0 has made some progress in this direction, its component diagrams in particular. Therefore, the requirement analysis in component-based development is about the identification of these high level use cases and the creation of component sequence diagrams and component diagrams. Then the application of UML follows to the development of an component if an OO approach is thought appropriate for that component.
6.2 Points of discussion
The model of components is simplified in the sense that behavior or protocols of the interfaces are not described. There are several possible ways to address the problem of protocols. First, we can introduce control state variables in contracts and thus in components. This will allow us to define a contract as a state machine or statechart, e.g. [Sel98, WB00]. Then when two components are composed, deadlock freedom needs to be verified and this is not an easy task. Second, in addition to the state information, we can add a CSP-like specification of the order of the methods in a component, e.g. [AG97]. Again, matching between protocols in different components has to be checked and deadlock needs to be avoided. As we know from the model of CSP, this is not a trivial task either. We would like to propose a weak approach in which protocols of the provided interface and required interface of a component are de-scribed independently in terms of regular languages on the method names of the interfaces. To check the matchability between a provided interface with a required interface is then to check the provided interface protocol is a subset of the required interface protocol in terms of the regular languages that are
Conclusion and Discussion 19
defined for the protocols. This procedure can be automated.
Although the model of components does allow mutual dependency between two components and we check live-lock once the design specifications of the components are given. Again, all experts in formal methods are well aware that this is difficult in practice. We suggest the designers try to avoid mutual dependencies in their component software development.
The communication between components is modelled as synchronous method invocation. Asynchronous communication can be achieved by introducing buffer components. Components may also communicate via shared variables.
Future work also includes applying this framework to bigger case studies, combines it with UML, and provides a formalization to CORBA and COM. We will also look into adding non-functional features, such as timing and resources into the interfaces of components.
6.3 Related work
There is much work on the definitions of software components. We take the informal views of [CD01, HC01, DW98, Szy02] that a component both provides to and requires services from other components. We used the notion of contract for formal specification of provided and required services, A contract here is similar to that of Meyer [Mey92]. However, we have provided the notion of composition and there is a standard calculus for reason about and refine components at different levels of abstracts. A distinctive nature of our framework is the natural link of the component contract specification and its OO implementation. The contract specification and the OO notation are both defined in first-order predicate logic and based on Hoare and He’s UTP [HH98].
Contracts are also defined for software components in [HL03] that attempts to enhance Catalysis [DW98]. However, they do not deal with component composition.
A contract in [HHG90] models the collaboration and behavioral relationships between objects. In our approach, we provide the separation between the specification of a contract for an interface from the specification of the behavior of the component that realizes the contract. A notion of contract can also be found in [BPP99] that emerged in the model of action systems. It promotes the separation between the specification of what an agent can do in a system and how they need to be coordinated to achieve the required global behavior of the system. However, the architectural components there are not explored. A contract in [AJ99] describes the coordinations among a number of partners (i.e. components or ob-jects). Its main purpose is to support system architectural evolution and to deal with changes in business rules of the system application. Our contracts here specify the services of components while we treat interaction and coordinations as part of the implementation of the components. Our aim is to support construction of software components and component software systems. However, it is interesting to in-vestigate how these two notions of contracts can be combined to provide better support to both system construction and evolution.
References 20
We have not introduced a special concept of connectors, e.g. [DW98, JA97] as they can be treated as (special) components. It is however interesting and important to define a special class of components for connectors and study their properties and uses. We will include this in our future work.
Acknowledgement
We thank the referees of IFIP TCS2004 for their careful review and constructive comments that helped in the improvement of the paper. We also thank our colleague Dang Van Hung for his comments on the earlier version of the paper. An earlier version of the paper was submitted to the International Conference on Mathematics of Program Construction 2004. Although it was not accepted, two of the three referees gave very useful comments that helped us to revise the paper into the present form.
References
[AG97] R. Allen and D Garlan. A formal basis for architectural connection. ACM Transactions on Software
Engineering and Methodology, 6(3), 1997.
[AJ99] L. F. Andrade and J.L.Fiadeiro. Interconnecting objects via contracts. In R. France and B. Rumpe, editors, UML’99 - Beyond the Standard, LNCS1723. Springer-Verlag, 1999.
[BPP99] R.J.R. Back, L. Petre, and I.P. Paltor. Formalizing UML use cases in the refinement calculus. Technical Report 279, Turku Centre for Computer Science, Turku, Finland, May 1999.
[BRJ99] G. Booch, J. Rumbaugh, and I. Jacobson. The Unified Modelling Language User Guide. Addison-Wesley, 1999.
[Bro] M. Broy. Multi-view modeling of software systems. In H.V. Dang and Z. Liu, editors,
Proceed-ings of the Workshop on Formal Aspects of Component Software FACS’03, Satellite Workshop of the FM 2003, Pisa, Italy. UNU-IIST Technical Report 284, UNU-IIST, P.O. Box 3058, Macao,
http://www.iist.unu.edu/newrh/III/1/page.html.
[CD01] J. Cheesman and J. Daniels. UML Components. Component Software Series. Addison-Wesley, 2001. [DW98] D. D’Souza and A.C. Wills. Objects, Components and Framework with UML: The Catalysis
Ap-proach. Addison-Wesley, 1998.
[Fil02] J.K. Filipe. A logic-based formalization for component specification. Journal of Object Technology, 1(3):231–248, 2002.
[Gud01] M. Gudgin. IDL: Interface design for COM. Reading, MA: Addison-Wesley, 2001.
[HC01] G.T. Heineman and W.T. Councill. Component-Based Software Engineering, Putting the Pieces
To-gether. Addison-Wesley, 2001.
[HH98] C.A.R. Hoare and J. He. Unifying theories of programming. Prentice-Hall International, 1998. [HHG90] R. Helm, I. Holland, and D. Gangopadhyay. Contracts: Specifying behavioral compositions in
object-oriented systems. In Proc. OOPSLA’90/ECOOP’90, pages 169–180. ACM, 1990.
[HL03] S.M. Ho and K.K. Lau. Catalysis framework in first-order logic. In H.D. Van and Z. Liu, editors,
Proc. of FME03 Workshop on Formal Aspects of Component Software, Pisa, Italy, 2003. UNU/IIST
Tech Report No 284.
References 21
[HLL02] J. He, Z. Liu, and X. Li. Towards a refinement calculus for object-oriented systems (keynote talk). In
Proc. ICCI02, August 19-20, 2002, Alberta, Canada, 2002.
[HLL03a] J. He, Z. Liu, and X. Li. Component calculus. In V.H. Dang and Z. Liu, editors, Proc. Proc. Workshop
on Formal Aspects of Component Software (FACS’03), Satellite Workshop of FME2003, Pisa, Italy, 8-9 September, 2003. UNU/IIST Report No 284, UNU/IIST, P.O. Box 3058, Macao, 2003.
[HLL03b] J. He, Z. Liu, and X. Li. Modelling object-oriented programming with reference types and dynamic binding. Technical Report UNU/IIST Report No 280, UNU/IIST, P.O. Box 3058, Macao, 2003. http://www.iist.unu.edu/newrh/III/1/page.html.
[JA97] J.L.Fiadeiro and A.Lopes. Semantics of architectural connectors. In M. Bidoit and M. Dauchet, editors, Proc. TAPSOFT’97, LNCS 1214, pages 505–519. Springer-Verlag, 1997.
[Kru00] P. Kruchten. The Rational Unified Process – An Introduction (2nd Edition). Addison-Wesly, 2000. [Lar01] C. Larman. Applying UML and Patterns. Prentice-Hall International, 2001.
[Leu94] S. Leue. Methods and Semantics for Telecommunications Systems Engineering. PhD thesis, Depart-ment of Computer Science and Applied Mathematics, University of Berne, Switzerland, December 1994.
[LHLC03] Z. Liu, J. He, X. Li, and Y. Chen. A relational model for object-oriented requirement analysis in UML, 2003. Proc. ICFEM03, 5-7 November, 2003, Singapore. Lecture Notes in Computer Science. [LHLL03] Z. Liu, J. He, X. Li, and J. Liu. Unifying views of UML. Technical Report UNU/IIST Report No 288,
http://www.iist.unu.edu/newrh/III/1/page.html, UNU/IIST, P.O. Box 3058, Macao, 2003. Presented at <<UML>>2003 Workshop on Compositional Verification of UML, 21 October 2003, SF, USA. To appear in ENTCS.
[Liu02] Z. Liu. Object-oriented software development in UML. Technical Report UNU/IIST Report No 259, UNU/IIST, P.O. Box 3058, Macao SAR China, 2002.
[Mey92] B. Meyer. Applying design by contract. IEEE Computer, May 1992.
[Mey97] B. Meyer. Object-oriented Software Construction (2nd Edition). Prentice Hall PTR, 1997. [Mic] Sun Microsystems. Javabeans 1.01 specification. http://java.sun.com/beans.
[Mic96] Microsoft. The component object model specification. Report v0.99, Microsoft Standard, Redmond, WA: Microsoft, 1996.
[OMG00] OMG. The common object request broker: architecture and specification. Report v2.5, OMG Standard Collection, OMG, 2000.
[Sel98] B. Selic. Using UML for modelling complex real-time systems. In F. Mueller and A. Bestavros, editors, Language Compilers, and Tools for Embedded Systems, LNCS 1474, pages 250–262. Springer, 1998.
[Smy78] M. Smyth. Powerdomain. Journal of Computer Science and System Sciences, 16:23–36, 1978. [Szy02] C. Szyperski. Component Software: Beyond Object-Oriented Programming. Addison-Wesley, 2002. [WB00] M. Wirsing and M. Broy. Algebraic state machines. In T. Rus, editor, Proc. 8th Internat. Conf.
Algebraic Methodology and Software Technology, AMAST 2000. LNCS 1816, pages 89–118. Springer,
