Formal Verification Issues For Component-Based Development

Component-based development has made a breakthrough in software industry, it offers safer systems and easier to maintain, furthermore, costs and time to market are reduced. However, several issues, such as the correctness of component-based systems, their adaptation or the interactions between their components, require rigorous verification through the use of formal methods and tools. In this paper, we first present an introduction to component-based development; afterward we propose a classification of formal verification issues for component-based systems.


Introduction
In component-based development [1] the construction of a software system is reduced to an assembly of separately developed software components. This offers as advantages to reduce development costs as well as time to market. Moreover, the quality of the software systems is better, since the latter are built from tested and certified components. In addition, the maintenance and evolution stages of the system are simply a replacement of software components; furthermore, in response to changes in users' requirements or in the environment, component-based systems can also be reconfigured by modifying the links of their architecture.
Nevertheless, the component-based development process should be controlled by the use of formal methods, which allo w, at any stage of the lifecycle, verifying important issues; such as the correctness of componentbased systems, their adaptation or the interactions between their software components. This paper is structured as follows. Section 2 presents the basic concepts of component-based development. In Section 3 we show the need for the use of formal methods through a classification of the various verification issues for component-based systems. Section 4 is devoted for related work and finally section 5 concludes this paper.

Related work
As to the best of our knowledge, this paper is the first presenting a classification of the main issues of formal verifications for the component-based systems, nevertheless, other works deal with the need for the formalization in this domain. In [30], the authors present the need for an abstract approach, the need for formalization for architecture description languages and interface description languages, and the formal languages used for formalization. Compared to our wo rk, the authors invest much more in the study and comparison of the formal languages used in the field of software components, while our work rather focuses on the identification and classification of the problems that may arise during the component based development.
The authors of [31] present briefly an introduction to the component-based development; afterwards the need for formalization in this context is illustrated through a non-trivial example. However, the authors do not offer a detailed classification of potential problems of componentbased development.
In [29], a classification of component models is proposed through a comparative study in five dimensions: life cycle, interface specification, interactions, extrafunctional properties, and domains. Indeed, this work constitutes a more general classification of component models; the authors introduce the use of formal languages for software components, however, they do not provide a detailed study of formal verification issues for componentbased development.
Further, unlike [30] and [31], in order to be more selfcontained, basic concepts related to component-based development are provided, this is essential for understanding the formal verification issues.

Basic concepts of component-based development
In this section we present the basic princip les and concepts of component-based development.

Software component
In the literature, there are many definitions of the notion of software component; according to [1], "A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only.
A software component can be deployed independently and is subject to third-party composition". Indeed, a software component interacts with its environment only through its interfaces, since it is designed without any knowledge of its environment; this offers an independence allowing its use in different contexts.

Interfaces and assembly
A software component can have two types of interfaces: on the one hand, the provided interfaces; they represent the services that the component offers, on the other hand, the required interfaces; which are the services that the component needs to accomplish its functions. The assembly of a component-based system is done by linking the provided interfaces with the required interfaces of a selection of software components; however, in order to guarantee a correct assembly of these components, the compatibility of their interfaces should be verified beforehand.
The semantics of an interface is usually specified by its signature. However, the description of an interface only by its signature is insufficient for modeling and verifying the notion of compatibility, indeed, the specification of an interface must also include the definition of the behavior, such as the sequence of service calls between components of the system, or the time constraints, such as the execution time of a service. As we will see in the next sections, the application of formal methods is inescapable for the verification of these issues.

Component models and component frameworks
Others aspects, relating in particular to the definition of the components and their composition are specified by the component model to which the component is assigned. Indeed, the component models define a specific representation, composition modes, interaction styles and others standards dedicated to software components [2]. In addition, component models form the basis for creating component frameworks. Component frameworks establish the physical environmental conditions for the execution and cooperation of components in the system, and they help also to regulate the interactions between components in execution [1].
Component frameworks can only concern physical components, unlike component models, these can be defined for the different levels of abstraction for a component [3], indeed, some component models define a software component as an execution entity, this is the case for Fractal [4] for example, while others component models define a software component as a design entity, as is the case for SOFA [5].

Instance of a software component
Some component models distingu ish component types from their instances, allowing the creation and the destruction of component instances at runtime, as is the case for EJB [6] or CCM [7 ]. Others component models like Wright [8] do not take instantiation into account.

Synchronous communication vs asynchronous communication
Usually, the communication between the software components is done in a synchronous manner, as is the case for Darwin [9] and SOFA. However, in some models such as EJB or CCM, communication can be done by asynchronously sending and receiving messages.

Single binding vs multiple binding
Some component models suppose one-to-one linking of interfaces, i.e. single bindin gs, as in SOFA, others component models allow an interface to be linked to several others interfaces, i.e. multiple bindings, as is the case of EJB and Fractal.

Life cycle of a component-based system
Component-based software systems are developed by selecting and assembling off-the-shelf components, instead of being programmed, this makes the lifecycle of a component-based software system different from traditional software system; it mainly comprises the following steps: 1-Requirements specification: It concerns collectin g, analyzing and specifying the needs of the future users of the system. 2-Architecture specification: The architecture of the software specifies the system in terms of abstract components of design and interactions between these components. 3-Selection and customization of components: First, the concrete components taken on the shelf are selected according to the software architecture; in a second step, each component must be personalized before being integrated into the new system. 4-Integration of the system: Integration is achieved by establishing mechanisms for communication and coordination of the various components of the final software system. 5-Test of the system: Various methods and tools are used to test the component-based system; in fact, it is a question of checking the properties concerning functional aspects as well as those related to the quality of the software. 6-Deployment: This is the installation of the software components of the system on one or more computers. 7-Maintenance and evolution of the system: After deployment, parts of the component-based system can be modified, due to changes in users' requirements or in the environment.
The concept of software construction by reuse is not new, indeed, the idea was already present in objectoriented programming, it was implemented by the inheritance mechanism; the relatively recent emergence of new technologies has signif icantly increased the possibilit ies of build ing systems and applications from reusable components. Furthermore, build ing systems based on components or building components for systems in different application areas requires methodologies and processes, including not only development and maintenance aspects, but also those relating to organizational, marketing, legal and other aspects.

Development for reuse and development through reuse
The component-based software engineerin g process includes two separate but linked processes via a component market. In the followin g we present each of the two processes: -Development for Reuse: This process consists of an analysis of the application domains in order to develop commercial-off-the-shelf (COTS) components related to these domains. To complete a successful reuse of the software, standards for similar systems must be identified and represented in a form that can be easily exploited to build other systems in the domain. Once created, reusable components will be available in organizations or at the market level as commercial components. -Development through reuse: this is related to the assembly of software systems from the components taken on the shelf.

Classification of formal verification issues for component-based systems
Formal approaches are rigorous methods aimed at modeling and analyzing complex systems. The idea of verifying pro grams is not new; in fact it dates back to the 1960s. Today, formal techniques and tools are widely used in both the academic and the industrial worlds. In our context, formal methods are essential for component-based development because they enable addressing important verification issues throughout the lifecycle of a component-based system. In the remainder of this section, we will detail these verification issues which we have classified into three levels, namely, at an individual component, during the composition of the components, and finally at the evolution level.

Component level
This level of analysis addresses the verification of an individual component before its composition with the rest of the system; we classified this verif ication into two types: − Context-independent verification: it consists of verifying the properties of a component in the isolation, thereby independently of its deployment context; indeed, the issues to be checked can concern the absence of deadlock in its own specification or the coherence of the specification of its temporal constraints. − Context-dependent verification: In componentbased development, components are developed independently of their deployment context; therefore, component correctness can be very difficult to define, as a component may behave correctly in a context but incorrectly in another. Existing approaches remedy this situation in two different ways; some approaches [10,11] propose to attribute to each component a description of its properties, thereby enabling the user of component to decide if the latter can behave correctly in a given context. Other approaches [12,13] deliver software components with a set of quality properties that are guaranteed in all contexts satisfying a number of conditions.

Composition level
This level addresses the verification of the composition of the system; we classified this verification into tree main issues:

Compatibility of components
The software components constituting a component-based system can be delivered by different sellers; therefore verification of their compatibility is an important issue. Some approaches define compatibility only in terms of signatures of services linkin g components [14,7,15]. However, this description is by no means exhaustive, because it does not include for example, the specification of the services calls sequence of a component, such an aspect is more a matter of behavior. On the other hand, other approaches offer a richer description of compatibility, including description of the behavior [16]. This makes it possible to verify that the composition will not lead to an erroneous interaction between the components of the system. Some approaches propose to verify compatibility at design t ime, while others perform checks during execution, thereby detect bad interactions between components dynamically; using a test environment in which the concerned components are duplicated [17].
Moreover, even if the components are not completely incompatible, they can sometimes cooperate correctly by generating appropriate adapters of their interfaces. Some approaches generate adapters for connecting components belonging to different component models [18,29]; this can be done in a fully automatic manner. Other approaches include adapters for integrating an incompatible functionality of components [19], in which case additional input is required from the user or the monitoring phase to provide information concerning the parts corresponding to the incompatible functionality.

Assembly of components
The process of assembling components is mainly twofold: identifying the correct components taken on the shelf, and their connections together, so that the resulting component-based system corresponds to the desired requirements.
Usually, assembly strategies focus on finding the most cost-effective solution with respect to time [19]. The cost function can, for example, evaluate the components in terms of their performance measurements or the minimization of new requirements generated by the added components. The assembly can be selected based on an exhaustive evaluation of all possible alternatives [20], or via an iterative construction of a relatively optimal solution [21].
In this context, formal methods make the problem of assembly of components considerably simpler by simply providing a design of the component based system comprising specifications of a set of components and their connections, the problem being reduced to simply finding the correct component implementations taken on the shelf and formally verifying their compliance with the expected specifications. This verification can be carried out on the whole of the final component-based system or simply on a welldefined part.

The global verification
Furthermore, in addition to checking p roperties, formal methods can also help in optimizing componentbased systems, namely: − Detection of inactive components, which can be removed from the system. − The search for optimal system deployment by placing components in compute nodes based on the density of interaction between them [22].
As with compatibility, some approaches check the properties of a global system at design time, wh ile other approaches allow dynamic verification of the system, in fact, the conformance of the current behavior of the components in execution is verified in parallel with its specification [27], thereby any errors are reported in case of discrepancy.

Evolution level
After the deployment phase, a component-based system can evolve or adapt, in response to changes in users' needs or changes in its environment [23], namely: interoperability with others systems, optimization of computational algorithms, or technical changes.
Formal methods and techniques are very useful for modeling and analyzing the evolution of component-based systems [24]. We have classified this analysis into two types: − The dynamic reconfiguration of the architecture: this mainly includes the change of the links between the system components as well as the creation and destruction of the instances of the components. At this level, formal analysis seeks to verify the coherence of the global system after a dynamic reconfiguration. − Substitutability: one or more components can be replaced with new ones. Generally, approaches addressing this issue define an equivalence relation between the old and the new component, in order to verify that the substitution does not violate the correctness of the global system [25]. However, in some cases, the verification of the equivalence between the two versions of the system is not necessarily strong, because it is only necessary that the new system satisfies a given explicit property, this is considered much more by the approaches that do not aim to guarantee that the behavior remains unchanged, but rather to identify the behavioral differences between several versions of the system [26].
Furthermore, the evolution of a component-based system is usually defined with a set of evolution rules.

An application domain: Web services
Web services are a typical application domain of component-based development. Indeed, formal methods, used pragmatically, represent a very powerful way to verify several issues, such as the description, composition or evolution of web services.
Regarding the verification of the composition, for instance, the goal is to find the best way to put the services together for the accomplishment of a global task. The composition of web services is called choreography. Nowadays, several languages are dedicated to the description of choreography, for example: WS-CDL (Web Services Choreography Description Language) [32] or WSCI (Web Service Choreography Interface) [33].
Another example of the formal verification for web services is orchestration, this describes the business logic of web services; in fact, it is the description of the control flow of business processes, such as: sequential or parallel execution, etc. WS-BPEL (Web Services Business Process Execution Language) [34] is one of the most widely used languages to describe orchestration.
In this context, formal verification tools perform translations from languages such as: WS-CDL or WS-BPEL, to formalisms, such as: process algebras [8] or timed automata [35], thus allowing the verification of requested properties.

Conclusion
We presented an overview of the principles and basic concepts of the component-based software development paradigm. Afterwards, through a classification of verification issues for software components, we have shown the need for formal methods and techniques in this context. More generally, for a real integration of formal methods into the component-based development process, frameworks with textual input languages or graphical notations must be provided, and translation algorithms must be implemented; including translations between informal concepts of component-based systems to formalisms, as well as translations of these formalisms to proof or verification tools such as model checking tools.
Further, other issues have yet to be solved. In fact, we have good techniques and tools for formal verifications dedicated to the design phase, such as the UPPAAL model checker [28]; however, these tools cannot be used to do verifications during the execution phase, to control the behavior of a running system with respect to an expected formal model. On the other hand, it would be practical to design tools that allow d irect generation of code from the formal specification of a component-based system.