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 specications, currently executable assertions, at assembly times, and are updated according to dynamic recongurations. 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 recongurations.
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-)congurable 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 verications 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 dened as an unit of composition with contractually specied interfaces [2], the notion of contract appears as a natural solution to express and organize specications and verications [3]. But as components are organized hierarchically, these contracts must not be only associated to interfaces taken separately. They have to be also dened at the component level. With the possibility of dynamic recongurations, 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 recongurations. 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 reexive 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 specications 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 recongurations 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), reective capabilities (introspection capabilities to monitor a running system and re-conguration capabilities to deploy and dynamically congure 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 simplied 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 dened 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 insufcient to capture and control the salient properties of an application [3]. More complete specications 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 veried. 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 specication formalisms [58]. For example, interface automata [6] enables a specication 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 renement 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 dened on interfaces, frames (aka component types) and architectures (aka component internal assembly). Renement of specications are veried at design time, while adherence of a component's implementation to its specication is checked at run time. We decide to rst focus on the contracting mechanisms, rather than on the expressiveness of the specication formalism. We use executable assertions, the formalism rst used with contracts [9], to reason about component contracts using both functional and extra-functional specications. Nevertheless, to obtain a high condence degree, it will be necessary, at long term, to take into account, in the same platform, dierent specication 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 denition of components: they do not take into account a hierarchical assembly of components; contracts are not built incrementally and not updated if any dynamic reconguration occurs; the responsabilities of contracts are not precisely determined to handle violation in the most ecient way. Facing all the problems stated above, we dene the requirements of the
Fract
Con-
system to the following.
Specications can be either functional or extra-functional. They can be veried 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.
Specications, which play the role of provisions, are distinguished from Contracts, which are reied and incrementally built following conguration actions. Contracts are also updated when dynamic recongurations occur, so that they can be used to check the modied architecture.
Responsibilities among the contract participants must also be clearly dened to enable the developers to precisely handle contract violations (log, renegotiation of contracts, dynamic recongurations, 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 Specication 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 dene some specications. 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, specications 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 specipre, post, inv, rely and guarantee. They correspond
[12] and enhanced to be adapted to cations are classic [13],
to validity periods at conguration and run times. Each category consists of one or more clauses, identied by a number or a label and bound by a logical conjunction. The scope of specications 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 specications with CCL-J .
In the same way, the gure 5 shows some examples of internal composition specications. All the properties are located on component instances, as they are dependent from a specic 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 ;