Verification of Distributed Hierarchical Components

Abstract

Components allow to design applications in a modular way by enforcing a strong separation of concerns. In distributed systems this separation of concerns have to be composed with distribution of controls due to asynchrony. This article relies on Fractive, an implementation of the Fractal component model allowing to unify the notion of components with the notion of activity. This article shows how to build automatically the behaviour of a distributed component system. Starting from the functional specification of primitive components, we generate a specification of a system of components, their asynchronous communications, and their control. We then show how to use such a specification to verify properties specific to components, reconfigurations, or asynchrony.

Temporal Specification and Deductive Verification of a Distributed Component Model and Its Environment

“…Model checking [17], which verifies the properties of the components against the specification, has already been tested in various circumstances, one particular application of this method been tested in [10]; it is a powerful and well established technique allowing to incorporate a number of algorithms and tools to deal even with the famous state explosion problem. However, when applied to a component system, it has one indicative drawback, namely it has an explorative nature and it cannot efficiently handle infinite state systems; in fact, model checking is used to take "snapshots" of various static states of a system, and quickly verify them, but when we consider a long running system -possible even infinite -it is easy to understand that this procedure becomes not feasible.…”

A Specification Language for Distributed Components Implemented in GCM/ProActive

“…But in [13] we have shown that it plays an important role as an intermediate format between the platform tools; it can be viewed as the low-level semantic notation expressing both behaviour, structure and synchronisation of our components. This pNet model is the main intermediate format used by our tools to interface with the verification tools (see Section 1.4.1).…”

“…In [13] we have shown how to specify both the functional and the nonfunctional behaviour of GCM/ProActive components; however for the time being we focus only on the functional (also known as business) behaviour, leaving the non-functional parts (life-cycle, bindings, reconfiguration management) to further developments of the JDC.…”

“…First, we shall transform the original JDC specification using the mapping to simple types. Then we shall build pNets models as described in previous work [12,13]. Finally, for each formula to be checked, we will use finite partitions as a domain abstraction for each parameter in the model, that will give a finite model usable in a model-checker.…”

“…Then, in [12,13] we synthesised a behavioural model for GCM/ProActive components, including their functional and non-functional behaviour. In Figure 2, we provide a partial model of CoCoME in pNets.…”