International audienceComponent-based Engineering aims at providing a modular means to specify a wide range of applications. The idea is to promote a clean separation of concerns, and thus reusability, in order to ease the burden of software development and maintenance. The specification of such component models however, tends to be informal, leaving their inherent ambiguities open to interpretation. In this paper we present our ongoing work towards a formal specification of the Fractal Component Model mechanized in the Coq Proof Assistant. An operational semantics for building component-based architectures is presented, along with its compliance with the Fractal specification

Gaspar, Nuno

Madelaine, Eric

INRIA a CCSD electronic archive server

HAL Id: hal-00725291https://hal.inria.fr/hal-00725291v2Submitted on 24 Aug 2012HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.L’archive ouverte pluridisciplinaire HAL, estdestinée au dépôt et à la diffusion de documentsscientifiques de niveau recherche, publiés ou non,émanant des établissements d’enseignement et derecherche français ou étrangers, des laboratoirespublics ou privés.Fractal à la CoqNuno Gaspar, Eric MadelaineTo cite this version:Nuno Gaspar, Eric Madelaine. Fractal à la Coq. Conférence en IngénieriE du Logiciel, Jun 2012,Rennes, France. ￿hal-00725291v2￿Fractal à la CoqNuno Gaspar∗Oasis Project TeamINRIA Sophia Antipolis - MéditerranéeNuno.Gaspar@inria.frEric MadelaineOasis Project TeamINRIA Sophia Antipolis - MéditerranéeEric.Madelaine@inria.frAbstractComponent-based Engineering aims at providing a modular means to specify a widerange of applications. The idea is to promote a clean separation of concerns, and thusreusability, in order to ease the burden of software development and maintenance. Thespecification of such component models however, tends to be informal, leaving their inher-ent ambiguities open to interpretation.In this paper we present our ongoing work towards a formal specification of the FractalComponent Model mechanized in the Coq Proof Assistant. An operational semantics forbuilding component-based architectures is presented, along with its compliance with theFractal specification.1 IntroductionBuilding software is becoming a more and more complex task. Our era of computers andelectronics demands highly sophisticated applications, where not only performance but alsoreliability are expected. Coping with such needs requires special care when designing software.The approach promoted by Component-based Engineering tackles these requests by leveragingthe view of software as building blocks that when put together form the intended functionality.This is the rationale followed by the Fractal Component Model [3].Essentially, the essence of the Fractal Component Model lies around the notions of com-ponent, interface and binding. The components represent entities, generally pieces of softwarecode, that communicate explicitly and necessarily by means of interfaces. This is in fact themain difference between Component-based programming and standard Object-oriented pro-gramming. The inherent advantage is that the dependencies between software blocks becomeexplicit, permitting an easier software maintenance. At last, bindings convey procedures callsor messages passing between interfaces.Components are deemed composite if they possess subcomponents. These can be shared,thus possibly yielding graph architectures and not only tree structures. Moreover, monitoringand on the fly reconfiguration of applications are other concerns tackled by Fractal.1.1 Motivation and Related WorkMany approaches regarding the formalization of component models can be found in the litera-ture. While it is still an utopia to see formal methods as part of the standard software engineer-ing discipline, the maturity attained by formal tools already permit considerable achievements.In [4], Henrio et al. present a framework for reasoning on component composition mecha-nized in Isabelle/HOL. Their focus is on a GCM-like component model1 and show promisingresults for dealing with reconfiguration properties in a mechanical way.∗The author is partially funded under contract CIFRE 2012/0109 ActiveEon/INRIA1The Grid Component Model (GCM)[1] is an extension of Fractal for distributed and parallel architectures.P. Collet, P. Merle (eds.); Conférence en IngénieriE du Logiciel (CIEL), Juin 2012, pp. 1–6 1Fractal à la Coq N. Gaspar, and E. MadelaineMoreover, a formal specification of the Fractal Component Model has been proposed in theAlloy specification language [5]. This work proves the consistency of a (set-theoretic) model ofFractal applications. This is perhaps the work most closely related with ours.Their specification however, is constrained by the first-order relational logic nature of theAlloy Analyzer. In fact, they point to the use of the Coq Proof Assistant in order to overcomethis limitation.In this paper we present our work in progress towards a mechanization of the Fractal Speci-fication in the Coq Proof Assistant. Our approach differs from the remaining in that we aim atproviding a semantics that allows the building of correct-by-construction Fractal architectures.The remainder of this paper is organized as follows. Section 2.1 shows the encoding of Frac-tal’s basic definitions. Next, section 2.2 details a semantics for building Fractal Architectures.The kind of properties that can be proved in our development are discussed in section 2.3.Finally, section 3 concludes by pointing some directions for future work.2 Mechanizing Fractal ArchitecturesAs mentioned above, the Fractal Component Model has three core elements: components,interfaces and bindings. As such, we shall consider a simple language built around these coreelements. In the following, we omit the obvious definitions for the sake of space.2.1 Basic DefinitionsLet us first demonstrate how interfaces and components are mechanized in the Coq ProofAssistant.1 Induct ive i n t e r f a c e : Type :=2 | I n t e r f a c e : ident −> (∗ i t s id ∗)3 type −> (∗ i t s type ∗)4 path −> (∗ path to the component i t be longs ∗)5 a c c e s s i b i l i t y −> (∗ I n t e r n a l /External ∗)6 communication −> (∗ c l i e n t / s e r v e r ∗)7 f u n c t i o n a l i t y −> (∗ f u n c t i o n a l /Control ∗)8 language −> (∗ the language i t implements ∗)9 i n t e r f a c e .An interface is characterized by an identifier, a type, a path identifying the component wherethe interface belongs to, whether it is accessible internally or externally, whether is it supposedto communicate as client or server, whether it serves functional or control purposes, and finallythe language it implements. The intended meaning of each of these fields should be clear.The only complex aspect may arise from the path field. Fractal is a hierarchical componentmodel, and since by introspection an interface is able to identify the component it belongsto, a path identifying this component is necessary. Its definition is a list of identifiers, wherethese identifiers indicate the components that need to be traversed in the hierarchy to reachthe component holding the interface.1 Induct ive component : Type :=2 | Component : ident −> (∗ i t s unique id ∗)3 type −> (∗ i t s type ∗)4 path −> (∗ i t s path on the h i e ra r chy ∗)5 con t r o lLeve l −> (∗Lowest/ I n t r o sp e c t i on /Conf igurat ion ∗)6 l i s t component −> (∗ i t s sub components ∗)7 l i s t i n t e r f a c e −> (∗ i t s i n t e r f a c e s ∗)8 l i s t b inding −> (∗ i t s b ind ings ∗)9 component .2 Actes de CIEL 2012Fractal à la Coq N. Gaspar, and E. MadelaineA component has an identifier, a type, a path indicating its level in the hierarchy, a control leveldetermining what it can do, subcomponents, interfaces and bindings. Bindings are connectingcomponents together by means of their interfaces.1 Induct ive binding : Type :=2 | Normal : path −> i d ent −> i dent −> i d ent −> i dent −> binding3 | Export : path −> i d ent −> i dent −> i d ent −> binding4 | Import : path −> i d ent −> i dent −> i d ent −> binding .A binding is always established between a client and a server interfaces. It can be a normal,export or import binding. These are defined by indication of the component’s path which theybelong to, and by the identifiers of the involved components and interfaces. For export andimport bindings the identifier of one intervening component can always be inferred and thus isomitted.2.2 Operational Semantics of Fractal ArchitecturesHaving defined our core elements, it is now time to introduce a notion of state. A state is thestructure that holds all the relevant information. For instance, for a tiny programming languageit is generally a function mapping variables to their values.1 De f i n i t i o n s t a t e := component .23 De f i n i t i o n empty state : s t a t e :=4 Component ( Ident ”Root” ) Top n i l Con f igurat ion n i l n i l n i l .In our case, a state has the same shape of a component. An empty state is therefore acomponent named Root without any subcomponents, interfaces and bindings.The syntactic categories of our language for building Fractal Architectures are defined asfollows.a ::= mk component component| mk interface interface| bind binding| a; a| doneThe meaning of the first three constructs should raise no doubt: making components, makinginterfaces and establishing bindings. We use a for representing actions2. Allowing for multipleactions to execute as a sequence is defined by means of the standard operator ;. Last, donestands for the completed action.The design of software architectures can be seen from a transition system point of view.One makes some action a, in some state σ, and ends up with a reduced action a’ in some stateσ’. This can be represented by the following manner.〈a, σ〉 −→ 〈a′, σ′〉.Building Fractal architectures will therefore require to define these transition rules for eachconstructor of our language. In other words, to define a semantics.In the following we use the . notation for projections.2In the realm of programming languages semantics, instruction or statement are the terms usually em-ployed. In our case we consider that action is a more adequate nomenclature.3Fractal à la Coq N. Gaspar, and E. MadelaineMaking Componentsc = Component id t p cl subComps interfaces bindingsvalid component path p σwell formed component c∀ c’, c’ ∈ (get scope p σ) → (c’.id 6= id)〈make component c, σ〉 −→ 〈done, add component σ c〉(SMakeComponent)The above rule dictates that for creating a component one must supply a valid path, it mustbe itself well formed, and its identifier must be distinct from the ones in the same scope. Thevalid component path predicate expresses the well-formedness of a path in the hierarchy ofcomponents for the current state. Component well-formedness is inductively defined in Coq asfollows.1 Induct ive wel l formed component ( c : component ) : Prop :=2 | WellFormedComponent Base :3 we l l f o rmed i n t e r f a c e s ( c−>i n t e r f a c e s ) −>4 we l l f o rmed b ind ing s ( c−>b ind ings ) ( c−>subComponents ) ( c−>i n t e r f a c e s ) −>5 ( c−>subComponents ) = n i l −>6 wel l formed component c7 | WellFormedComponent Step :8 ( f o r a l l c ’ , In c ’ ( c−>subComponents ) −> wel l formed component c ’ ) −>9 un ique id s ( c−>subComponents ) −>10 we l l f o rmed i n t e r f a c e s ( c−>i n t e r f a c e s ) −>11 we l l f o rmed b ind ing s ( c−>b ind ings ) ( c−>subComponents ) ( c−>i n t e r f a c e s ) −>12 wel l formed component c .As for interfaces, they are deemed well formed provided that their pair of values ident ×accessibility is unique. Moreover, each binding must be valid, that is, be of normal, importor export kind. These predicates are defined analogously to the precedent.At last, it is requested that inserting a component will not break the unicity of identifiers in thehierarchical level being inserted to. The function get scope : path → state → list componentreturns the list of components where the insertion is supposed to occur.Making Interfacesi = Interface id t p a c f lvalid interface path p σc = get component with path p s∀ i’, i’ ∈ (c.interfaces) → i’.id =id → i’.accessibility 6= a〈make interface i, σ〉 −→ 〈done, add interface σ i〉(SMakeInterface)As in the creation of components, creating an interface also requires a valid path. The functionget component with path : path→ state→ component returns the component where the in-terface is supposed to be added. Inserting the interface must not break the property of uniquepair of values ident × accessibility.Making Bindingsvalid component path (b.path) σvalid component binding b components〈make binding b, σ〉 −→ 〈done, add binding σ b〉(SMakeBinding)4 Actes de CIEL 2012Fractal à la Coq N. Gaspar, and E. MadelaineAs in the above rules, a valid path is expected. Further, establishing a binding also requires thevalid component binding predicate to hold. As stated in the Fractal specification, a bindingis either a normal, export or import binding.1 Induct ive va l id component b ind ing (b : b inding ) ( s : s t a t e ) : Prop :=2 | NormalBinding : normal binding b s −> va l i d b i nd i ng b s3 | ExportBinding : expor t b ind ing b s −> va l i d b i nd i ng b s4 | ImportBinding : import b ind ing b s −> va l i d b i nd i ng b s .For instance, a binding is deemed normal if it is established between two external interfaces,and the components owning these interfaces have the same enclosing component, i.e., they arein the same composite component. Moreover, a binding must be established between client toserver interfaces.Sequence of Actions Finally, our last action serves the purpose of composing actions. Itsdefinition is straightforward: having a composition of an action a1 with an action a2, we firstneed to reduce a1 so we can reach a2.〈a1, σ〉 −→ 〈a′1, σ′〉〈a1; a2, σ〉 −→ 〈a′1; a2, σ′〉(SSeq1)〈a1, σ〉 −→ 〈done, σ′〉〈a1; a2, σ〉 −→ 〈a2, σ′〉(SSeq2)So far, all the above rules defined a one step transition. However, there are cases where wemay want to reason about multiple steps transitions. For instance, the action1 De f i n i t i o n S impleArch i tec ture : a c t i on :=2 Mk component n i l ( Ident ”A” ) SomeType Conf igurat ion n i l n i l ;3 Mk component n i l ( Ident ”B” ) SomeType Conf igurat ion n i l n i l ;4 Mk inter face ( ( Ident ”A” ) : : n i l ) ( Ident ”X” ) SomeType External C l i en t Control C;5 Mk inter face ( ( Ident ”B” ) : : n i l ) ( Ident ”Y” ) SomeType External Server Control C;6 Bind ( ( Ident ”A” ) : : n i l ) ( Ident ”X” ) External7 ( ( Ident ”B” ) : : n i l ) ( Ident ”Y” ) External .requires five steps to complete. Here, what we would like to do is to be able to reason onthe overall execution of this action. As such, we need to formalize this notion of multiplesteps. This is achieved by the reflexive transitive closure of our transition relation. Consideringstep : action ∗ state→ action ∗ state→ Prop, our inductive definition modelling our transitionrules, we can define the notion of multiple steps in the following manner.1 Notation ”a ’/ ’ s ’−−−>∗’ a ’ ’ / ’ s ’ ” := ( r e f l s t e p c l o s u r e s tep (a , s ) ( a ’ , s ’ ) ) .23 Lemma we l l f o rmed a r ch i t e c t u r e :4 e x i s t s s ,5 S impleArch i tec ture / empty state −−−>∗ Done / s .6 Proof .7 . . .8 Qed .Having this notion defined we can now reason on the overall execution of a sequence ofactions. For instance, the above trivial lemma states that the execution of our SimpleArchi-tecture will indeed terminate.2.3 Meeting the SpecificationThe rigorous definition of the possible actions that one can take allow us to formally reason onall possible outcomes. One important theorem is to prove that starting an architecture in a wellformed state, when the execution completes it will end up in a state that is also well formed.5Fractal à la Coq N. Gaspar, and E. Madelaine1 De f i n i t i o n we l l f o rmed ( s : s t a t e ) : Prop :=2 match s with3 | Component id t p c l l c l i lb =>4 id = ( Ident ”Root” ) /\ t = Top /\ p = n i l /\ c l = Conf igurat ion /\5 l i = n i l /\ wel l formed component (Component id t p c l l c l i lb )6 end .78 Theorem v a l i d i t y :9 f o r a l l a s s ’ , a / s −−−>∗ Done / s ’ −>10 wel l fo rmed s −>11 wel l fo rmed s ’ .It should be noted that the above theorem is an universal quantification over all possible Fractalarchitectures. Thus, every architecture built with our semantics rules and obeying the well-formedness hypothesis will be well formed.Preliminary results allow us to conclude on the feasibility of this approach. At this stagehowever, the proof is not completed and a more precise definition of our well formed predicateis needed for a full compliance with the Fractal specification.3 Final RemarksIn this paper we presented the first steps towards a mechanized specification of the FractalComponent Model. At this stage, there is still some remaining work to be included in our Coqdevelopment. Inclusion of a progression theorem and typing rules on bindings are natural nextsteps. Furthermore, a seamless integration with the Vercors platform [2] could be envisaged. Inthe long term one of our goals is to use this formalization in conjunction with model checkingtechniques in order to address behavioural properties of complex component architectures.Moreover, our action language opens interesting perspectives w.r.t. reconfiguration capa-bilities of component-based systems. Another research direction to follow would be to see howcould we best leverage this kind of approach with the concerns of autonomic reconfigurations.AcknowledgementsThe authors are grateful to Ludovic Henrio for numerous remarks in earlier versions of thispaper and engaging discussions about possible future research directions.References[1] Françoise Baude, Denis Caromel, Cédric Dalmasso, Marco Danelutto, Vladimir Getov, LudovicHenrio, and Christian Pérez. Gcm: a grid extension to fractal for autonomous distributed compo-nents. Annales des Télécommunications, 64(1-2):5–24, 2009.[2] Rabéa Ameur Boulifa, Raluca Halalai, Ludovic Henrio, and Eric Madelaine. Verifying safety of fault-tolerant distributed components. In International Symposium on Formal Aspects of ComponentSoftware (FACS 2011), Lecture Notes in Computer Science, Oslo, 2011. Springer.[3] Eric Bruneton, Thierry Coupaye, and Jean-Bernard Stefani. The fractal component model, 2004.[4] Ludovic Henrio, Florian Kammüller, and Muhammad Uzair Khan. A framework for reasoning oncomponent composition. In FMCO 2009, Lecture Notes in Computer Science. Springer, 2010.[5] Philippe Merle and Jean-Bernard Stefani. A formal specification of the Fractal component modelin Alloy. Rapport de recherche RR-6721, INRIA, 2008.6 Actes de CIEL 2012

Fractal à la Coq

HAL-UNICE

Fractal a` la Coq
Nuno Gaspar, Eric Madelaine
To cite this version:
Nuno Gaspar, Eric Madelaine. Fractal a` la Coq. Confe´rence en Inge´nieriE du Logiciel, Jun
2012, Rennes, France. 2012. <hal-00725291v2>
HAL Id: hal-00725291
https://hal.inria.fr/hal-00725291v2
Submitted on 24 Aug 2012
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destine´e au de´poˆt et a` la diffusion de documents
scientifiques de niveau recherche, publie´s ou non,
e´manant des e´tablissements d’enseignement et de
recherche franc¸ais ou e´trangers, des laboratoires
publics ou prive´s.
Fractal a` la Coq
Nuno Gaspar∗
Oasis Project Team
INRIA Sophia Antipolis - Me´diterrane´e
Nuno.Gaspar@inria.fr
Eric Madelaine
Oasis Project Team
INRIA Sophia Antipolis - Me´diterrane´e
Eric.Madelaine@inria.fr
Abstract
Component-based Engineering aims at providing a modular means to specify a wide
range of applications. The idea is to promote a clean separation of concerns, and thus
reusability, in order to ease the burden of software development and maintenance. The
specification of such component models however, tends to be informal, leaving their inher-
ent ambiguities open to interpretation.
In this paper we present our ongoing work towards a formal specification of the Fractal
Component Model mechanized in the Coq Proof Assistant. An operational semantics for
building component-based architectures is presented, along with its compliance with the
Fractal specification.
1 Introduction
Building software is becoming a more and more complex task. Our era of computers and
electronics demands highly sophisticated applications, where not only performance but also
reliability are expected. Coping with such needs requires special care when designing software.
The approach promoted by Component-based Engineering tackles these requests by leveraging
the view of software as building blocks that when put together form the intended functionality.
This is the rationale followed by the Fractal Component Model [3].
Essentially, the essence of the Fractal Component Model lies around the notions of com-
ponent, interface and binding. The components represent entities, generally pieces of software
code, that communicate explicitly and necessarily by means of interfaces. This is in fact the
main difference between Component-based programming and standard Object-oriented pro-
gramming. The inherent advantage is that the dependencies between software blocks become
explicit, permitting an easier software maintenance. At last, bindings convey procedures calls
or messages passing between interfaces.
Components are deemed composite if they possess subcomponents. These can be shared,
thus possibly yielding graph architectures and not only tree structures. Moreover, monitoring
and on the fly reconfiguration of applications are other concerns tackled by Fractal.
1.1 Motivation and Related Work
Many approaches regarding the formalization of component models can be found in the litera-
ture. While it is still an utopia to see formal methods as part of the standard software engineer-
ing discipline, the maturity attained by formal tools already permit considerable achievements.
In [4], Henrio et al. present a framework for reasoning on component composition mecha-
nized in Isabelle/HOL. Their focus is on a GCM-like component model1 and show promising
results for dealing with reconfiguration properties in a mechanical way.
∗The author is partially funded under contract CIFRE 2012/0109 ActiveEon/INRIA
1The Grid Component Model (GCM)[1] is an extension of Fractal for distributed and parallel architectures.
P. Collet, P. Merle (eds.); Confe´rence en Inge´nieriE du Logiciel (CIEL), Juin 2012, pp. 1–6 1
Fractal a` la Coq N. Gaspar, and E. Madelaine
Moreover, a formal specification of the Fractal Component Model has been proposed in the
Alloy specification language [5]. This work proves the consistency of a (set-theoretic) model of
Fractal applications. This is perhaps the work most closely related with ours.
Their specification however, is constrained by the first-order relational logic nature of the
Alloy Analyzer. In fact, they point to the use of the Coq Proof Assistant in order to overcome
this limitation.
In this paper we present our work in progress towards a mechanization of the Fractal Speci-
fication in the Coq Proof Assistant. Our approach differs from the remaining in that we aim at
providing a semantics that allows the building of correct-by-construction Fractal architectures.
The remainder of this paper is organized as follows. Section 2.1 shows the encoding of Frac-
tal’s basic definitions. Next, section 2.2 details a semantics for building Fractal Architectures.
The kind of properties that can be proved in our development are discussed in section 2.3.
Finally, section 3 concludes by pointing some directions for future work.
2 Mechanizing Fractal Architectures
As mentioned above, the Fractal Component Model has three core elements: components,
interfaces and bindings. As such, we shall consider a simple language built around these core
elements. In the following, we omit the obvious definitions for the sake of space.
2.1 Basic Definitions
Let us first demonstrate how interfaces and components are mechanized in the Coq Proof
Assistant.
1 Induct ive i n t e r f a c e : Type :=
2 | I n t e r f a c e : ident −> (∗ i t s id ∗)
3 type −> (∗ i t s type ∗)
4 path −> (∗ path to the component i t be longs ∗)
5 a c c e s s i b i l i t y −> (∗ I n t e r n a l /External ∗)
6 communication −> (∗ c l i e n t / s e r v e r ∗)
7 f u n c t i o n a l i t y −> (∗ f u n c t i o n a l /Control ∗)
8 language −> (∗ the language i t implements ∗)
9 i n t e r f a c e .
An interface is characterized by an identifier, a type, a path identifying the component where
the interface belongs to, whether it is accessible internally or externally, whether is it supposed
to communicate as client or server, whether it serves functional or control purposes, and finally
the language it implements. The intended meaning of each of these fields should be clear.
The only complex aspect may arise from the path field. Fractal is a hierarchical component
model, and since by introspection an interface is able to identify the component it belongs
to, a path identifying this component is necessary. Its definition is a list of identifiers, where
these identifiers indicate the components that need to be traversed in the hierarchy to reach
the component holding the interface.
1 Induct ive component : Type :=
2 | Component : ident −> (∗ i t s unique id ∗)
3 type −> (∗ i t s type ∗)
4 path −> (∗ i t s path on the h i e ra r chy ∗)
5 con t r o lLeve l −> (∗Lowest/ I n t r o sp e c t i on /Conf igurat ion ∗)
6 l i s t component −> (∗ i t s sub components ∗)
7 l i s t i n t e r f a c e −> (∗ i t s i n t e r f a c e s ∗)
8 l i s t b inding −> (∗ i t s b ind ings ∗)
9 component .
2 Actes de CIEL 2012
Fractal a` la Coq N. Gaspar, and E. Madelaine
A component has an identifier, a type, a path indicating its level in the hierarchy, a control level
determining what it can do, subcomponents, interfaces and bindings. Bindings are connecting
components together by means of their interfaces.
1 Induct ive binding : Type :=
2 | Normal : path −> i d ent −> i dent −> i d ent −> i dent −> binding
3 | Export : path −> i d ent −> i dent −> i d ent −> binding
4 | Import : path −> i d ent −> i dent −> i d ent −> binding .
A binding is always established between a client and a server interfaces. It can be a normal,
export or import binding. These are defined by indication of the component’s path which they
belong to, and by the identifiers of the involved components and interfaces. For export and
import bindings the identifier of one intervening component can always be inferred and thus is
omitted.
2.2 Operational Semantics of Fractal Architectures
Having defined our core elements, it is now time to introduce a notion of state. A state is the
structure that holds all the relevant information. For instance, for a tiny programming language
it is generally a function mapping variables to their values.
1 De f i n i t i o n s t a t e := component .
2
3 De f i n i t i o n empty state : s t a t e :=
4 Component ( Ident ”Root” ) Top n i l Con f igurat ion n i l n i l n i l .
In our case, a state has the same shape of a component. An empty state is therefore a
component named Root without any subcomponents, interfaces and bindings.
The syntactic categories of our language for building Fractal Architectures are defined as
follows.
a ::= mk component component
| mk interface interface
| bind binding
| a; a
| done
The meaning of the first three constructs should raise no doubt: making components, making
interfaces and establishing bindings. We use a for representing actions2. Allowing for multiple
actions to execute as a sequence is defined by means of the standard operator ;. Last, done
stands for the completed action.
The design of software architectures can be seen from a transition system point of view.
One makes some action a, in some state σ, and ends up with a reduced action a’ in some state
σ’. This can be represented by the following manner.
〈a, σ〉 −→ 〈a′, σ′〉.
Building Fractal architectures will therefore require to define these transition rules for each
constructor of our language. In other words, to define a semantics.
In the following we use the . notation for projections.
2In the realm of programming languages semantics, instruction or statement are the terms usually em-
ployed. In our case we consider that action is a more adequate nomenclature.
3
Fractal a` la Coq N. Gaspar, and E. Madelaine
Making Components
c = Component id t p cl subComps interfaces bindings
valid component path p σ
well formed component c
∀ c’, c’ ∈ (get scope p σ) → (c’.id 6= id)
〈make component c, σ〉 −→ 〈done, add component σ c〉 (SMakeComponent)
The above rule dictates that for creating a component one must supply a valid path, it must
be itself well formed, and its identifier must be distinct from the ones in the same scope. The
valid component path predicate expresses the well-formedness of a path in the hierarchy of
components for the current state. Component well-formedness is inductively defined in Coq as
follows.
1 Induct ive wel l formed component ( c : component ) : Prop :=
2 | WellFormedComponent Base :
3 we l l f o rmed i n t e r f a c e s ( c−>i n t e r f a c e s ) −>
4 we l l f o rmed b ind ing s ( c−>b ind ings ) ( c−>subComponents ) ( c−>i n t e r f a c e s ) −>
5 ( c−>subComponents ) = n i l −>
6 wel l formed component c
7 | WellFormedComponent Step :
8 ( f o r a l l c ’ , In c ’ ( c−>subComponents ) −> wel l formed component c ’ ) −>
9 un ique id s ( c−>subComponents ) −>
10 we l l f o rmed i n t e r f a c e s ( c−>i n t e r f a c e s ) −>
11 we l l f o rmed b ind ing s ( c−>b ind ings ) ( c−>subComponents ) ( c−>i n t e r f a c e s ) −>
12 wel l formed component c .
As for interfaces, they are deemed well formed provided that their pair of values ident ×
accessibility is unique. Moreover, each binding must be valid, that is, be of normal, import
or export kind. These predicates are defined analogously to the precedent.
At last, it is requested that inserting a component will not break the unicity of identifiers in the
hierarchical level being inserted to. The function get scope : path → state → list component
returns the list of components where the insertion is supposed to occur.
Making Interfaces
i = Interface id t p a c f l
valid interface path p σ
c = get component with path p s
∀ i’, i’ ∈ (c.interfaces) → i’.id =id → i’.accessibility 6= a
〈make interface i, σ〉 −→ 〈done, add interface σ i〉 (SMakeInterface)
As in the creation of components, creating an interface also requires a valid path. The function
get component with path : path→ state→ component returns the component where the in-
terface is supposed to be added. Inserting the interface must not break the property of unique
pair of values ident × accessibility.
Making Bindings
valid component path (b.path) σ
valid component binding b components
〈make binding b, σ〉 −→ 〈done, add binding σ b〉 (SMakeBinding)
4 Actes de CIEL 2012
Fractal a` la Coq N. Gaspar, and E. Madelaine
As in the above rules, a valid path is expected. Further, establishing a binding also requires the
valid component binding predicate to hold. As stated in the Fractal specification, a binding
is either a normal, export or import binding.
1 Induct ive va l id component b ind ing (b : b inding ) ( s : s t a t e ) : Prop :=
2 | NormalBinding : normal binding b s −> va l i d b i nd i ng b s
3 | ExportBinding : expor t b ind ing b s −> va l i d b i nd i ng b s
4 | ImportBinding : import b ind ing b s −> va l i d b i nd i ng b s .
For instance, a binding is deemed normal if it is established between two external interfaces,
and the components owning these interfaces have the same enclosing component, i.e., they are
in the same composite component. Moreover, a binding must be established between client to
server interfaces.
Sequence of Actions Finally, our last action serves the purpose of composing actions. Its
definition is straightforward: having a composition of an action a1 with an action a2, we first
need to reduce a1 so we can reach a2.
〈a1, σ〉 −→ 〈a′1, σ′〉
〈a1; a2, σ〉 −→ 〈a′1; a2, σ′〉
(SSeq1)
〈a1, σ〉 −→ 〈done, σ′〉
〈a1; a2, σ〉 −→ 〈a2, σ′〉 (SSeq2)
So far, all the above rules defined a one step transition. However, there are cases where we
may want to reason about multiple steps transitions. For instance, the action
1 De f i n i t i o n S impleArch i tec ture : a c t i on :=
2 Mk component n i l ( Ident ”A” ) SomeType Conf igurat ion n i l n i l ;
3 Mk component n i l ( Ident ”B” ) SomeType Conf igurat ion n i l n i l ;
4 Mk inter face ( ( Ident ”A” ) : : n i l ) ( Ident ”X” ) SomeType External C l i en t Control C;
5 Mk inter face ( ( Ident ”B” ) : : n i l ) ( Ident ”Y” ) SomeType External Server Control C;
6 Bind ( ( Ident ”A” ) : : n i l ) ( Ident ”X” ) External
7 ( ( Ident ”B” ) : : n i l ) ( Ident ”Y” ) External .
requires five steps to complete. Here, what we would like to do is to be able to reason on
the overall execution of this action. As such, we need to formalize this notion of multiple
steps. This is achieved by the reflexive transitive closure of our transition relation. Considering
step : action ∗ state→ action ∗ state→ Prop, our inductive definition modelling our transition
rules, we can define the notion of multiple steps in the following manner.
1 Notation ”a ’/ ’ s ’−−−>∗’ a ’ ’ / ’ s ’ ” := ( r e f l s t e p c l o s u r e s tep (a , s ) ( a ’ , s ’ ) ) .
2
3 Lemma we l l f o rmed a r ch i t e c t u r e :
4 e x i s t s s ,
5 S impleArch i tec ture / empty state −−−>∗ Done / s .
6 Proof .
7 . . .
8 Qed .
Having this notion defined we can now reason on the overall execution of a sequence of
actions. For instance, the above trivial lemma states that the execution of our SimpleArchi-
tecture will indeed terminate.
2.3 Meeting the Specification
The rigorous definition of the possible actions that one can take allow us to formally reason on
all possible outcomes. One important theorem is to prove that starting an architecture in a well
formed state, when the execution completes it will end up in a state that is also well formed.
5
Fractal a` la Coq N. Gaspar, and E. Madelaine
1 De f i n i t i o n we l l f o rmed ( s : s t a t e ) : Prop :=
2 match s with
3 | Component id t p c l l c l i lb =>
4 id = ( Ident ”Root” ) /\ t = Top /\ p = n i l /\ c l = Conf igurat ion /\
5 l i = n i l /\ wel l formed component (Component id t p c l l c l i lb )
6 end .
7
8 Theorem v a l i d i t y :
9 f o r a l l a s s ’ , a / s −−−>∗ Done / s ’ −>
10 wel l fo rmed s −>
11 wel l fo rmed s ’ .
It should be noted that the above theorem is an universal quantification over all possible Fractal
architectures. Thus, every architecture built with our semantics rules and obeying the well-
formedness hypothesis will be well formed.
Preliminary results allow us to conclude on the feasibility of this approach. At this stage
however, the proof is not completed and a more precise definition of our well formed predicate
is needed for a full compliance with the Fractal specification.
3 Final Remarks
In this paper we presented the first steps towards a mechanized specification of the Fractal
Component Model. At this stage, there is still some remaining work to be included in our Coq
development. Inclusion of a progression theorem and typing rules on bindings are natural next
steps. Furthermore, a seamless integration with the Vercors platform [2] could be envisaged. In
the long term one of our goals is to use this formalization in conjunction with model checking
techniques in order to address behavioural properties of complex component architectures.
Moreover, our action language opens interesting perspectives w.r.t. reconfiguration capa-
bilities of component-based systems. Another research direction to follow would be to see how
could we best leverage this kind of approach with the concerns of autonomic reconfigurations.
Acknowledgements
The authors are grateful to Ludovic Henrio for numerous remarks in earlier versions of this
paper and engaging discussions about possible future research directions.
References
[1] Franc¸oise Baude, Denis Caromel, Ce´dric Dalmasso, Marco Danelutto, Vladimir Getov, Ludovic
Henrio, and Christian Pe´rez. Gcm: a grid extension to fractal for autonomous distributed compo-
nents. Annales des Te´le´communications, 64(1-2):5–24, 2009.
[2] Rabe´a Ameur Boulifa, Raluca Halalai, Ludovic Henrio, and Eric Madelaine. Verifying safety of fault-
tolerant distributed components. In International Symposium on Formal Aspects of Component
Software (FACS 2011), Lecture Notes in Computer Science, Oslo, 2011. Springer.
[3] Eric Bruneton, Thierry Coupaye, and Jean-Bernard Stefani. The fractal component model, 2004.
[4] Ludovic Henrio, Florian Kammu¨ller, and Muhammad Uzair Khan. A framework for reasoning on
component composition. In FMCO 2009, Lecture Notes in Computer Science. Springer, 2010.
[5] Philippe Merle and Jean-Bernard Stefani. A formal specification of the Fractal component model
in Alloy. Rapport de recherche RR-6721, INRIA, 2008.
6 Actes de CIEL 2012


https://hal.inria.fr/hal-00725291v2/document

Fractal à la Coq

Abstract

Similar works

Full text

Available Versions

INRIA a CCSD electronic archive server

HAL-UNICE