LABORATOIRE
INFORMATIQUE, SIGNAUX ET SYSTÈMES DE SOPHIA ANTIPOLIS UMR 6070
A C ONTRACTING S YSTEM FOR H IERARCHICAL C OMPONENTS Philippe Collet, Roger Rousseau, Thierry Coupaye, Nicolas Rivierre Projet OCL Rapport de recherche ISRN I3S/RR–2005-02–FR Janvier 2005
L ABORATOIRE I3S: Les Algorithmes / Euclide B – 2000 route des Lucioles – B.P. 121 – 06903 Sophia-Antipolis Cedex, France – Tél. (33) 492 942 701 – Télécopie : (33) 492 942 898 http://www.i3s.unice.fr/I3S/FR/
R ÉSUMÉ :
M OTS
CLÉS
:
A BSTRACT: This article presents the contracting system ConFract for the open and hierarchical component model Fractal. Contracts are dynamically built from specifications, currently executable assertions, at assembly times, and are updated according to dynamic reconfigurations. These contracts are not restricted to the scope of interfaces, taken separately. On the contrary, new kinds of composition contracts can be built in order to associate several external interfaces of a component, providing a "usage contract", or several interfaces inside the component, providing a "assembly and implementation contract". All these contracts identify fine-grained responsabilities and developers can thus easily organize the handling of contract violations and the resulting reconfigurations.
K EY WORDS :
A Contracting System for Hierarchical Components 1
1
2
Philippe Collet , Roger Rousseau , Thierry Coupaye , and Nicolas Rivierre 1
2
University of Nice - Sophia Antipolis, I3S Laboratory, France, 2
[email protected]
France Telecom R&D Division,
MAPS/AMS Laboratory, Grenoble & Issy les Moulineaux, France
Abstract. This article presents the contracting system ConFract for
the open and hierarchical component model Fractal. Contracts are dynamically built from speci cations, currently executable assertions, at assembly times, and are updated according to dynamic recon gurations. These contracts are not restricted to the scope of interfaces, taken separately. On the contrary, new kinds of composition contracts can be built in order to associate several external interfaces of a component, providing a usage contract, or several interfaces inside the component, providing a assembly and implementation contract. All these contracts identify ne-grained responsibilities and developers can thus easily organize the handling of contract violations and the resulting recon gurations.
1 Introduction Since McIlroy's appeal in 1968, component-based software engineering (CBSE) has gone through an important evolution. Components were at rst units of compilation, then modules tting together with an explicit interface (Modula2, Ada. . . ), then classes associated by use or inheritance links (Eiel, C++. . . ), and nally, black boxes, organized in a (re-)con gurable architecture and capable of communicating on a network through several interfaces (CCM, EJB, .NET. . . ). Nowadays one would like to reconcile the advantages of all these notions of software components, while having the means to manage the resulting architecture, separate concerns and choose the right level of abstraction. A modern software component can be thus considered as a runtime entity which communicates through (possibly remote) interfaces which can be dynamically binded, as well as a hierarchy of subcomponents, with possible sharings. This supposes elaborated component models such as
Fractal
[1], which makes possi-
ble to extend technical services with its openness capabilities, while separating concerns. Such models drastically change the processes of traditional software engineering, by mixing static, dynamic, functional and extra-functional properties. To ensure the reliability of the resulting applications, it is necessary to integrate veri cations into adapted but complex development processes. As a component
Research report ISRN I3S/RR-2005-02-FR, submited to ICSE-CBSE'05, 16 pages
2
Philippe Collet et al.
is usually de ned as an unit of composition with contractually speci ed interfaces [2], the notion of contract appears as a natural solution to express and organize speci cations and veri cations [3]. But as components are organized hierarchically, these contracts must not be only associated to interfaces taken separately. They have to be also de ned at the component level. With the possibility of dynamic recon gurations, contracts must also be built and updated dynamically, taking into account any dependent change in the architecture. Moreover, if contracts are updated, they can be used to check the consistency of the dynamic recon gurations. Finally, in order to handle at best contract violations, the contracting system mut determine negrained responsibilities on each element of a contract.
ConFract, a contracting system for hierarchical compoFractal component model[1]. In its integration, ConFract also uses the re exive capababilities and the control features of extra-functional concerns provided by the Fractal platThis article presents
nents that meets these requirements and is targeted to the
form. Section 2 describes the rationale for a contracting system on components such as the
Fractal
ones. Examples of speci cations with executable assertions
are given in section 3. Section 4 presents the
ConFract
system by describing
its types of contract and their responsibilities. Contract checking and some examples of dynamic recon gurations are also presented. The implementation is described in the section 5 and section 6 discusses related work. Finally, section 7 concludes this article.
2 Rationale for Contracting Components 2.1
Context
The
Fractal
3 is a general component model with the fol-
component model [1]
lowing main features: composite components (to have a uniform view of applications at various levels of abstraction), shared components (to model resources and resource sharing while maintaining component encapsulation), re ective capabilities (introspection capabilities to monitor a running system and re-con guration capabilities to deploy and dynamically con gure a system) and openness (in the model, almost everything is optional and can be extended). The
Fractal
component model basically enables developers to hierarchically or-
ganize an application, with components being built from other subcomponents. Components can be connected through server (provided) and client (required) interfaces. Throughout this paper, we illustrate our approach with the example of a simpli ed simulator of a black and white copier (see gure 1). From an external point of view, the copier component
provides two
server interfaces, a control panel (pp) and an output tray for copies (ot). The client interfaces manage everything the environment has to supply to make a copy: some black ink (bi), an input tray (it), a glass pane with the original
3
The reader can nd a more detailed description of the model in [4] and at
http://fractal.objectweb.org
Contracting System BC CC LC CTC
controllers
ROOT
membrane
BC CC LC CTC
COPIER PRINTER
it
SCANNER
ot
FinalizerCtl fctl
DRIVER
pp
pp
Glass
ap
ScannerCtl sctl PrintingPanel
it
DigitalImage di
PrinterCtl pctl
FINALIZER
bi
InputTray
ap
OutputTray
bi
BlackInk
UnstableCopy uc
ot
3
gs
gs
ap
ap
ap
AcPower
ap
ENVIRONMENT
Fig. 1. Internal architecture of the copier.
(gs) and AC power (ap). At assembly times, the surrounding root component
connects all these interfaces with interfaces of compatible type, but inverse role, which come from an component simulating the user behavior. Internally, a
Fractal component is formed out of two parts: a membrane and
a content. The content of a composite component is composed of other components, called subcomponents, which are under the control of the enclosing component. The
Fractal
model is thus recursive and allows components to be
nested. The membrane embodies the control behavior associated with a particular component. In particular, it can i) intercept oncoming and outgoing operation invocations targeting or originating from the component's subcomponents,
ii) superpose a control behavior to the behavior of the component's subcomponents or iii) provide an explicit and causally connected representation of the component's subcomponents. From an internal point of view, the copier subcomponents:
,
is thus the assembly of four
which distributes the internal control ow,
scans the original document,
,
,
which prints the required copies and
which
,
which dries the ink or cooks the toner. The assembly is under the control of the copier membrane, which is made of interceptors and controller objects, provided by the
Fractal platform. To connect the external interfaces of a composite Fractal model provides the concept of
component with its subcomponents, the
internal interface. Every internal interface is connected with an external interface, of the same name, but with a inverse role. For example, the component
provides the server interface
of the component
,
ot,
which implements the server interface
via the internal interface
nections bind the interfaces
ot
of
.
ap of power supply, distribute
ot
The internal con-
the control ow from
4
Philippe Collet et al.
through the interfaces sctl, pctl and fctl. The data ow is shown by the path of the paper via it, uc, ot, of the digital image via gs, di, uc, ot and of the ink via bi, uc and ot. The signatures of the interfaces are de ned using the underlying language of the implementation
Julia
[1] of
Fractal ,
Java
currently
4 , as shown on g-
ure 2. These signatures can refer to library interfaces or classes, such as
SheetImage, InkCartridge
or
Stack
external interfaces
internal interfaces
library interfaces
i n t e r f a c e OutputTray { Stack /∗ Sheet ∗/ s h e e t s ( ) ...
i n t e r f a c e UnstableCopy { S h e e t copy ( ) ...
interface Sheet { S h e e t I m a g e image ( ) boolean i s S t a b l e ( ) ...
interface PrintingPanel { v o i d copy ( i n t n ) double d u r a t i o n ( ) b o o l e a n isPowerOn ( ) boolean isCopying ( ) ...
interface DigitalImage { S h e e t I m a g e image ( ) ...
interface BlackInk { InkCartridge cartridge () double minLevel ( ) ... interface InputTray { Stack /∗ Sheet ∗/ t r a y ( ) boolean isPaperJam ( ) int capacity () ...
Sheet,
in this example.
i n t e r f a c e SheetImage { boolean equals ( SheetImage o ) boolean i s B l a n k ( ) ...
interface ScannerCtl { void scan ( ) double d u r a t i o n ( ) ...
interface InkCartridge { d o u b l e l e v e l ( ) / / ml ...
interface PrinterCtl { void p r i n t ( ) double d u r a t i o n ( ) ...
i n t e r f a c e S t a c k / ∗ Elem ∗ / { / / J a v a 2 P l a t f o r m , v1 . 4 . 2 / / without genericity . . . int size () O b j e c t peek ( ) O b j e c t pop ( ) O b j e c t push ( O b j e c t o ) Object elementAt ( int i ) ...
interface FinalizerCtl { void f i n a l i z e ( ) double d u r a t i o n ( ) ...
interface Glass { Sheet o r i g i n a l ( ) boolean o r i g i n a l O n G l a s s ( ) ...
Fig. 2. Partial signatures of the copier interfaces.
2.2
Motivations
It is now well accepted that interface signatures, even with comments, are insuf cient to capture and control the salient properties of an application [3]. More complete speci cations are needed on the functional and extra-functional aspects (architecture, performances, quality of services, etc.). Some properties can be checked early, using static analyses or proofs. Other properties, often extra-functional, which refer to runtime values, can only be dynamically veri ed. In the case of hierarchical components where the assemblies are dynamic, we liken the word static to before the component is started . For example, in the case of the copier, one should be able to verify statically that all the subcomponents are connected to a power supply or to prove the functional properties of very stable library interfaces (Sheet,
4
For space's sake, the keyword
public
Stack,
and ";" are omitted.
etc.).
Contracting System
5
Either static or dynamic, many dierent properties can be expressed, using dierent speci cation formalisms [58]. For example, interface automata [6] enables a speci cation to capture input assumptions about the order in which the methods of a component are called and output guarantees about the order of called external methods. Checking compatibility and re nement between interface models is then possible. Behavior protocols [7] express traces on interface method calls with a form of regular expressions and takes into account hierarchical components. These protocols can be de ned on interfaces, frames (aka component types) and architectures (aka component internal assembly). Re nement of speci cations are veri ed at design time, while adherence of a component's implementation to its speci cation is checked at run time. We decide to rst focus on the contracting mechanisms, rather than on the expressiveness of the speci cation formalism. We use executable assertions, the formalism rst used with contracts [9], to reason about component contracts using both functional and extra-functional speci cations. Nevertheless, to obtain a high con dence degree, it will be necessary, at long term, to take into account, in the same platform, dierent speci cation formalisms, formal or semi-formal, for proofs, static or dynamic checking. To our knowledge, the proposals to explicitly support contracts for components all focus on interfaces or connectors, taken separetely. They aim at specifying behavior [8], architectural constraints [10] or quality of services [11]. As such they lack several important features to be well suited to our de nition of components: they do not take into account a hierarchical assembly of components; contracts are not built incrementally and not updated if any dynamic recon guration occurs; the responsabilities of contracts are not precisely determined to handle violation in the most e cient way. Facing all the problems stated above, we de ne the requirements of the
Fract
Con-
system to the following.
Speci cations can be either functional or extra-functional. They can be veri ed either statically (at assembly time) or dynamically (at runtime). They state properties that are related to interfaces, but also to the components themselves, while respecting visibility rules of the
Fractal
model.
Speci cations, which play the role of provisions, are distinguished from Contracts, which are rei ed and incrementally built following con guration actions. Contracts are also updated when dynamic recon gurations occur, so that they can be used to check the modi ed architecture.
Responsibilities among the contract participants must also be clearly de ned to enable the developers to precisely handle contract violations (log, renegotiation of contracts, dynamic recon gurations, organized panic, etc.).
Consequently, contracts in the
ConFract
system will take their usual sense
of document negotiated between several parties, the responsibilities of which are
clearly established for each provision.
6
Philippe Collet et al.
3 Examples of Speci cation 3.1
Informal Descriptions
As in current proposals for contracting components [11, 8], it must be possible to use the connection point between two interfaces, client and server, to de ne some speci cations. In the case of the method
copy
on the control panel of the
copier, one can express the precondition:
n
the parameter
must be positive
or the postcondition:
the copier is no more in the state
[1]
isCopying.
[2]
These properties are certainly useful, but with a rather poor semantics. To express more relevant properties, it is necessary
to compose external or
internal properties by widening the scope, while respecting encapsulation, which is controlled by the membranes. As for the method one could express, as precondition:
enough ink is available on interface inal is placed on
gs
copy
of the control panel,
bi, enough paper on it, an origap
[3]
and the power is supplied on
as functional postcondition:
ot are the sheets that were in the inverse order it before the copy, all printed with the image of the original
the copies in the tray in the tray
gs
on
[4]
and stabilized
and as extra-functional postcondition:
the duration of a copy conforms to the printing speed of the copier,
[5]
in number of pages per minute.
Moreover, in the case of a composite component, it is also necessary to compose its internal properties, visible through its internal interfaces
5 or through
the external interfaces of its subcomponents. So, for the component could express, as functional postcondition of
the copies of the tray
.di
ot
.pp.copy():
,
are printed with the image scanned from
.it and stabilized postcondition of .pp.copy():
on a blank paper sheet
or as extra-functional
n copies is the n printings and
the duration of the duration of
sum of the duration of the scan plus
stabilizations.
one
[6]
[7]
With such possibilities of expression, one could then reason in a compositional way [3], for example by verifying that the external behavior of the copier is properly obtained by the organization and the internal behavior that implement it.
3.2
Executable Assertions
In the
CCL-J 5
ConFract
system, speci cations are currently written in the language
(Component Constraint Language for
Java
), which is inspired by
OCL
In Fractal, internal interfaces are systematically and complementarilly associated to external interfaces, in order to go through the membrane of composite components, as on gure 1.
Contracting System
7
Fractal . Currently, the categories of speci pre, post, inv, rely and guarantee. They correspond
[12] and enhanced to be adapted to cations are classic [13],
to validity periods at con guration and run times. Each category consists of one or more clauses, identi ed by a number or a label and bound by a logical conjunction. The scope of speci cations is adapted to components using variants of the
context construct. It can refer to a method of a Java interface: context methodsignature ( g. 3); a component type: on COPIER context ( g. 4); or a particular component (instance or template of Fractal components [1]): on context ( g. 5).
on Fractal interfaces
on Java interfaces
c o n t e x t v o i d P r i n t i n g P a n e l . copy ( i n t n ) pre 0 < n / / cf spec [ 1 ] rely isPowerOn ( ) guarantee isCopying ( ) post ! isCopying ( ) / / cf spec [ 2 ] context InputTray inv tray ( ) . size () = b i . minLevel ( ) n . pp . copy ( i n t n ) post / / cf spec [ 6 ] ( l e t Stack /∗ S h e e t ∗/ r = < fz >. o t . s h e e t s ( ) ; / / o u t p u t s h e e t s i n t o = < f z > . o t . s h e e t s ( ) . s i z e ( ) @pre ; / / s h e e t s nb b e f o r e c o p y i n o t i n t p = < p t > . i t . t r a y ( ) . s i z e ( ) @pre ; / / s h e e t s nb b e f o r e c o p y i n i t ) forEach ( i i n 1 . . n : r . e l e m e n t A t ( o+ i ) . image ( ) . e q u a l s ( < sn > . d i . image ( ) ) & & r . e l e m e n t A t ( o+ i ) . image ( ) . i s S t a b l e () && r . e l e m e n t A t ( o+ i ) = = < p t > . i t . t r a y ( ) . e l e m e n t A t ( p−i + 1) @pre ) end on on < cp > c o n t e x t < dv > . pp . copy ( i n t n ) post / / cf spec [ 7 ] l e t ( d o u b l e t h d = < sn > . s c t l . d u r a t i o n ( ) + n ∗( < p t > . p c t l . d u r a t i o n ( ) + < f z > . f c t l . d u r a t i o n ( ) ) ) t h d −1 inv / / c f spec [ 9 ] l e t ( Component [ ] s u b c = F r a c t a l . g e t C o n t e n t C o n t r o l l e r ( t h i s ) . g e t F c S u b C o m p o n e n t s ( ) ) forEach i i n 1 . . s u b c . l e n g t h : Arrays . a s L i s t ( subc [ i ] . g e t F c I n t e r f a c e s ( ) ) . e x i s t s ( I n t e r f a c e i r : C l a s s . forName ( i r . g e t F c I t f S i g n a t u r e ( ) ) . c o n f o r m s T o ( ACPower . c l a s s ) && i r . i s F c C l i e n t I t f ( ) ) ; end on
Fig. 5. Examples of internal component speci cations with CCL-J .
In the same way, the gure 5 shows some examples of internal composition speci cations. All the properties are located on component instances, as they are dependent from a speci c assembly. The top example is the equivalent of the functional property [6], and of the extra-functional property [7] given on page 6. The bottom example of the gure illustrates an architectural constraint, using the introspection capabilities of
Fractal :
that all the subcomponents of type
ACPower.
have at least a client interface of
[9]
9
'
% &
$
#
" !
h
, \
) * q l k
i
/
;
6 ;
