Painless Support for Static and Runtime Verification of Component-Based Applications

Architecture Description Languages (ADL) provide descriptions of a software system in terms of its structure. Such descriptions give a high-level overview and come from the need to cope with arbitrarily complex dependencies arising from software components. In this paper we present Painless , a novel ADL with a declarative trait supporting parametrized speciﬁcations and architectural reconﬁg-urations. Moreover, we exhibit its reliable facet on its integration with ProActive — a middleware for distributed programming. This is achieved by building on top of Mefresa , a Coq framework for the reasoning on software architectures. We inherit its strong guarantees by extracting certiﬁed code, and subsequently integrating it in our toolchain.


Introduction
Typically, one uses an Architecture Description Language (ADL) as a means to specify the software architecture. This promotes separation of concerns and compels the software architect to accurately define structural requisites. Nevertheless, this task is seldom trivial as arbitrarily complex architectures may need to be defined. It is thus important to provide the means for expressive and intuitive, yet reliable, specifications.
In this paper we present Painless, a novel ADL for describing parametrized software architectures, and its related formal verification support. We discuss its integration with ProActive [1], a middleware for distributed programming, and the reference implementation for the Grid Component Model (GCM) [2].
The GCM ADL lacks support for architectural reconfigurations and parametrization. Further, it is XML-based: while it may be suitable for tools, it is a rather verbose and static description of the architecture. Painless supports both the definition of parametrized architectures and the specification of reconfigurations in a declarative style. This facilitates deployment tasks and gives a more comprehensive understanding of the application's topology.
For instance, let us consider the motivating example depicted by Figure 1. This architecture concerns a previous use case [3] on the saving of power consumption by adequately adding/removing Street Light and Brightness Info components. For such scenario an ADL solely describing the deployment topology and unable to handle parametrized specifications becomes cumbersome. In this paper, our main goal is to provide an ADL specifying at the same time the initial deployment and the possible reconfigurations, while providing support for describing parametrized topologies. We also want to rely on formal methods to guarantee a safe deployment and reconfiguration of the considered systems.
In [11], we presented Mefresa -a Coq [16] framework providing the means for the formal reasoning on software architectures. Here, we extend Mefresa with the ability to interpret Painless specifications, and provably correct functions computing their compliance with the GCM technical specification [10]. We take advantage of Coq's strong guarantees by extracting certified code, and subsequently integrate it with the ProActive middleware. In our previous work we focused on the mechanization of the GCM, and facilities for developing arbitrarily complex proofs regarding its intricacies. In this paper, we focus on the pragmatical aspects of deployment and reconfiguration by providing an ADL, and all the toolchain that allows us to deploy and reconfigure GCM applications in ProActive while reusing the guarantees provided by our proven back-end.
We see our contribution as two-fold. Firstly, we propose Painless, a novel ADL supporting parametrized specifications and architectural reconfigurations. Its declarative nature promotes concise and modular specifications. Secondly, we describe the integration of its related tool support with ProActive. This provides a case study on the use of certified code, fostering the application of formal methods in a software engineering context. The remainder of this paper is organised as follows. Section 2 briefly discusses GCM and Mefresa. Section 3 overviews our approach for extending the Pro-Active middleware to cope with Painless specifications. Section 4 introduces the semantics of Painless. Section 5 shows the specification of the use case depicted by Figure 1 in Painless. Related work is discussed in Section 6. For last, Section 7 concludes this paper.

Background
Mefresa provides a mechanized specification of the GCM, a simple operation language for manipulating architectural specifications, and the means to prove arbitrary complex properties about instantiated or parametrized architectures. It is developed with the Coq proof assistant [16]. 1 The GCM is constituted by three core elements: interfaces, components, and bindings.
An interface is defined by an id denoting its name, a signature corresponding to its classpath, and a path identifying its location in the component's hierarchy (i.e. the component it belongs to). It is of internal or external visibility, has a client or server role, is of functional or non-functional functionality, has an optional or mandatory contingency, and its cardinality is singleton, multicast or gathercast.
A component has an id, a path, a class, subcomponents, interfaces, and bindings. This implicitly models GCM's hierarchical nature. Further, components holding subcomponents are called composite.
Bindings act as the means to connect components together through their interfaces. They are composed by a path indicating the component holding the binding, and id s identifying the involved components and interfaces. Moreover, they can be of normal, import or export kind. A normal binding connects two components at the same hierarchical level, that is, they have the same enclosing component. The remaining kind of bindings are connecting together a component with a subcomponent. Whether of import and export kind depends on the client interface being from the subcomponent or from the enclosing one, respectively.
The GCM technical specification [10] dictates the constraints that a GCM application must comply with. They can be summed up into properties regarding the form of the architecture and its readiness to start execution. These requirements are encoded by the well-formed and well-typed predicates.
well-formed and well-typed architectures A component is well-formed if its subcomponents are well-formed and uniquely identifiable through their identifiers. Further, its interfaces, and bindings must also be well-formed.
Interfaces are well-formed if they are uniquely identifiable by their identifiers and visibility value: two interfaces may have the same identifier provided that they have a different visibility. bindings are well-formed if they are established between existing components/interfaces, from client to server interfaces, and unique.
A component may be well-formed but still unable to start execution. Further insurances are needed for the overall good functioning of the system in terms of its application dependencies. These are dictated by typing rules (see [10, p. 22]).
An interface possesses cardinality and contingency attributes. These determine its supported communication model and the guarantee of its functionality availability, respectively. For instance, for proper system execution we must ensure that client and singleton interfaces are bound at most once. For client interfaces only those of multicast cardinality are allowed to be bound more than once.
Analogously, similar constraints apply to the interfaces' contingency attribute. An interface of mandatory contingency is guaranteed to be available at runtime. This is rather obvious for server interfaces as they implement one or more service methods, i.e., they do have a functionality of their own. Client interfaces however, are used by service methods that require other service methods to perform their task. It therefore follows that a client and mandatory interface must be bound to another mandatory interface of server role. As expected, interfaces of optional contingency are not guaranteed to be available.
Mefresa captures these requirements by defining a well-typed predicate. Basically, it requires that both the contingency and cardinality concerns are met throughout the component hierarchy. Architectures not meeting these requirements are said to be ill-typed.
An operation language for manipulating GCM architectures Another important element of Mefresa is an operation language that allows the manipulation of GCM architectures. It possesses seven constructors: Mk component, Rm component, Mk interface, Mk binding, Rm binding, Seq, and Done. The meaning of each constructor should be intuitive from its name. The only doubt may arise from the Seq constructor: it stands for operation composition.
Its operational semantics is mechanized by the step predicate, and exhibit the following structure: op / σ → op / σ . States are denoted by σ, and in our particular case these have the shape of a component, i.e., an empty state is an empty component, etc. Thus, σ represents the component hierarchy being built.
With Coq, one can use these semantic rules to interactively reduce an operation to its normal form done, at which point some final state σ is attained. Naturally, the ability to perform such reduction depends on the demonstration that all required premises for each individual reduction step are met. This lets us wonder about a more general property that one can expect about σ on an overall operation reduction. Let −→* be the reflexive transitive closure of the step predicate. Then, the theorem depicted by Listing 1.1 should be intuitive. Informally, it expresses that if s is a well-formed state, and if we are able to reduce op to Done, then we know that the resulting state s' is well-formed. Proving this theorem is achieved by induction on the operation language constructors.
3 Overview of our approach Figure 2 gives an overview of our approach. In short, we obtain an extension to ProActive that is able to cope with Painless architectures. We extend Mefresa with functions -build state and well typed boolresponsible for ensuring the compliance of a deployment/reconfiguration specification with the GCM requirements. We prove these functions correct w.r.t the GCM mechanized specification, and use Coq's extraction mechanism to obtain certified OCaml code. Further, we also define a Painless interpreter that translates Painless expressions to Mefresa's operation language. This is directly programmed in OCaml. Finally, to ease the integration with ProActive, we use OCaml-Java [5] to produce Java byte code.

Painless hello world
Painless provides the software architect with the ability to write parametrized architectures and its possible structural reconfigurations in a declarative style. An excerpt of its grammar is defined by Table 1.
Its elementary -or normal forms -expressions include natural numbers, booleans, lists, and strings. Naturally, one can also use variables. Making and removing elements from the component architecture is achieved by the polymorphic mk and rm, respectively. As expected, skip is idempotent. Components, interfaces and bindings are also first-class citizens -where bexp is an expression for the three types of bindings. Facilities for manipulating lists, comparison, and binary operators such as + andare also built-in features. The standard if-thenelse, function application, sequence ; and match constructors conclude the range of allowed expressions. decl acts as a declaration layer composed by the usual (potentially recursive) let definitions, indexed by a parameter P.
An architecture arch is composed by a string str representing its name, k ≥ 0 declarations, and an expression describing the application deployment topology. Further, it may contain h ≥ 0 similarly defined reconfigurations. Listing 1.2 depicts a simple Painless specification. Its meaning should be intuitive. We give a representative name to the specification (line 1), and define two definitions holding an interface and component class (lines 2-3). Then, we define an interface named "GetLightInto", using the previously defined class, with a path indicating the component it belongs, and followed by its attributes concerning its visibility, role, etc (line 5). Next, we define the component named "Street Light", with an empty path -i.e., at the root of the component hierarchy -, with impl class as its implementation class, without subcomponents, with itf as its only interface, and without bindings (line 6). Finally, we deploy the application (line 7).

Computing states from operations
Painless specifications are translated to Mefresa's operation language. The details of this process are discussed in Section 4.
As discussed above, one can check the feasibility of reducing an operation by interactively applying its reduction rules and attempting to prove the required premises. This ability is of great value when attempting to prove arbitrary complex properties about parametrized architectures. Yet, if we intend to build a state representing the result of an operation reduction, then we would be better with a function performing such task. This is the purpose of the function depicted by Listing 1.3.  Apart from the Seq and Done constructors, the remaining operation constructors are handled analogously. Seq is composed by two operations (line 11), the leftmost operation is fully evaluated, and the resulting state is used for evaluating the rightmost operation (lines [12][13][14][15]. Done means that the end of the operation was reached, and it simply returns the current state (line 16).
Another important note regards the use of the option type as return type of this function. This is due to the fact that it only returns a state if it was able to fully evaluate the given operation, otherwise, if the operation is invalid, it simply returns None. As seen above, the validity theorem (see Listing 1.1) enunciates that reducing an operation to Done from a well-formed state yields a well-formed state. Naturally, the analogous behaviour is expected from the build state function. Further, we also expect it to always be able to compute a resulting state from an operation op, whenever it is possible to fully evaluate op. Formally, listing 1.4 depicts the relevant theorem.  Proving build state correctness requires a case analysis on the operation constructors, and relating the boolean checks made in build state with the premises of the step predicate.
Considering the context of a component-based application life-cycle, one deploys its application by performing an operation op on an empty statewhich is provably well-formed. Then, if op can indeed be reduced, we reach a well-formed state s (see Listing 1.1). Performing an architectural reconfiguration boils down to applying an operation op' to s, leading to yet another well-formed state s' -provided that op' can indeed be reduced -, and this can be repeated indefinitely. Indeed, there is no need to explicitly compute the well-formedness of the attained states, as it is provably guaranteed. There is however such a need regarding their well-typedness. To this end, we define the well typed bool : component → boolean function. Basically, it acts as a decision procedure w.r.t. the well-typedness of a component. It is proved as the computational counterpart of the well typed predicate, that is, it is both sound and complete w.r.t. the well typed predicate.
If an issue occurs -invalid operation or ill-typedness of the returned statean exception is thrown and the deployment aborts. Otherwise, the operation is mapped to the adequate methods composing the ProActive API, and the actual deployment is performed by the middleware. Further, the object holding the state's structure is kept for subsequent reconfiguration tasks. Table 2 gives an excerpt of the rules for translating expressions to Mefresa's operation language. We use Γ e ⇓ v for denoting the evaluation of e under the environment Γ being reduced to v, and t stands for type inference.

Painless semantics
Rule nf sem dictates that a normal form yields immediately a semantic value. The rule skip sem simply depicts that skip is translated to Mefresa's done operation. Rules mk c sem and mk i sem illustrate the polymorphic constructor mk at work. It can be used to build components, interfaces and bindings -making bindings is omitted for the sake of space. These proceed by fully reducing the expression e into a component/interface/binding that can be used into Mefresa's operations. Rule c sem shows the reduction of a Component: all its elements (identifier, subcomponents, ...) need to be reduced and of adequate type. Analogous rules apply for Interfaces and Bindings. match sem illustrates how pattern matching is performed. First, the expression exp to be matched is reduced to some value val. Then, we reduce the expression exp k with the corresponding pattern pat k∈{1,n} matching with val. As expected, this occurs in an environment Γ enlarged with a mapping between pat k and val, and patterns are checked by order. var sem shows that a variable is reduced by looking it up in the environment Γ . Finally, the rule seq sem simple attests that a sequence of Painless expressions is translated to Mefresa's operations. The complete reduction of an expression should yield a (sequence of) Mefresa's operations, otherwise it is rejected. For instance, the rule arch sem depicts how an architecture without reconfiguration strategies is evaluated. β 0 ), ..., (P k , β k ) exp ⇓ α Γ t α : operation Γ Architecture str: decl 0 ... decl k≥0 deploy exp ⇓ α arch sem Basically, the deployment expression exp is reduced to α, under an environment including all the declarations decl i . Naturally, α must be of type operation. Dealing with reconfigurations is performed analogously. The expression to be evaluated is reduced on a context including the deployment declarations, the ones defined locally, and its instantiated parameters.

Painless standard library
As discussed above, the GCM component model is hierarchical, that is, a component may possess subcomponents. A component communicates with the "outside" world through its external interface, whereas it relies on its internal interfaces to communicate with its subcomponents. Typically, composite component interfaces are symmetric, that is, for each external interface of server role there is a internal interface of client role, and vice-versa. Listing 1.5 and Listing 1.6 depict a convenient function to ease the specification of such scenarios -with the obvious definition of visibility symmetry omitted for the sake of space. All the discussed functions are part of Painless standard library along with other facilities for dealing with common specification tasks. Further, the user can easily build its own libraries as specifications can be imported.

Specifying the Lights Control use case in Painless
In this section we show how the specification of the Lights Control application discussed in Section 1 (see Figure 1) is achieved in Painless. We follow a modular approach by separately specifying the Switched On Lights, Sensed Brightness Info, and Lights Control components. Listing 1.9 depicts the specification of the Switched On Lights component. Their understanding should pose no doubt. The first adds a Street Light component by making it with the adequate path (line 25) and subsequently binding it to Light Collector's multicast interface (line 26). As expected, the expression nth streetLight n returns a streetLight component with an identifier suffixed by n. The second reconfiguration is handled in a similar manner. We first need to unbind the component to remove (line 31) -where normal is the constructor for normal bindings -, and then we proceed by removing it (line 32). From a programming perspective, the reconfigurations are available through a simple method call indicating its name and parameters. Further, the evaluation of the deployment specification and subsequent applied reconfigurations is carried out by the machinery originating from Mefresa. Moreover, it should be noted that checking that a reconfiguration leads to a well-formed and well-typed component architecture is achieved without stopping any component. Indeed, before reconfiguring the application, ProActive needs to stop the involved composite component. The inherent benefit is that only valid reconfigurations w.r.t the mechanized GCM specification are mapped to the ProActive API. For instance, attempting to add a Street Light component with the same identifier as another one already deployed is rejected, i.e., an exception is thrown.
Our ProActive extension is freely available online. The release contains the examples discussed here and several others. The reader is pointed to the following website for more details http://painless.gaspar.link.
Di Cosmo et. al. defined the Aeolus component model [6]. Their focus is on the automation of cloud-based applications deployment scenarios. Their proposal is loosely inspired by the Fractal component model [4] whose most peculiar characteristics are its hierarchical composition nature and reconfiguration capabilities. However, while both approaches permit architectural reconfigurations at runtime, its specification is not supported by their ADL, it solely contemplates deployment related aspects. Moreover, support for parametrized specifications is also not covered, forcing the software architect to explicitly define the application's structure.
Regarding Fractal, it is also worth noticing that it tries to overcome the lack of support for reconfiguration specification through Fscript [7]. Fscript embeds FPath -a DSL for navigation and querying of Fractal architectures -and acts as a scripting language for reconfiguration strategies. These are not evaluated for their validity. Nevertheless, system consistency is ensured by the use of transactions: a violating reconfiguration is rolled back.
Like the Fractal ADL, xMAML [13] is XML-based, yet it permits the specification of reconfigurations. An important difference is that their focus is on processor architectures and aim at producing synthesizable models.
In [8], Di Ruscio et. al. defend the concept of building your own ADL through the byADL framework. Further, they claim that "it is not possible to define a general, optimal ADL once and forever", and propose the means to incrementally extend and customize existing ADLs by composing their metamodels. This approach offers an interesting perspective regarding the interoperability of Painless with other ADLs.

Final Remarks
In this paper we presented Painless and its related novel approach for the specification of software architectures. Its declarative trait allows for intuitive and concise specifications, liberating the software architect from highly verbose specifications such as the ones obtained via machine languages like XML. Moreover, its support for parametrized architectures eases deployment -it becomes a matter of instantiation -, and thus boosts productivity. Further, in ProActive, mapping components to physical resources is achieved through application/deployment descriptors. While this information is not an aspect of the architecture per se, extending Painless with such feature could be envisaged.
Another key ingredient is the treatment of structural reconfigurations as firstclass citizens. Indeed, by supporting the specification of the topological changes that may occur at runtime, it yields a better understanding of the application. Moreover, it is worth noticing that the specified reconfigurations become easily accessible from a programming perspective: through a simple method call with the name of the desired reconfiguration. Furthermore, reconfiguration specifications are evaluated at runtime. The clear benefit is that one can be highly confident that the reconfiguration will not leave the application in a ill formed or ill typed state as the evaluation process is carried out by provably correct code extracted from Mefresa. Additionally, a further inherent advantage is that it all happens without stopping the application. Indeed, actually performing the reconfiguration requires it to be stopped at the composite level. By making a prior evaluation, the risk of reconfiguration failure is avoided.