3 research outputs found
Component-based Development using the B method
Research reportIn component-based software development approaches, components are considered as black boxes. Components communicate through required and provided interfaces which describe their visible behaviors. In the best cases, the provided interfaces are checked compatible with the corresponding required interfaces, but in general cases, adapters have to be introduced to connect them. Compatibility between required and provided interfaces concerns the interface signatures, behavioral aspects and protocol level. We propose to specify component interfaces in B in order to verify these three levels of interoperability. The use of B assembling and refinement mechanisms eases the verification of the interoperability between interfaces and the correctness of the component assembly. The verification is done by the B prover
Automatic Construction of Validated B Components from Structured Developments
Decomposition and refinement provide a way to master the complexity of system specification and development. Decomposition allows us to describe a complex system in term of simpler and more understandable components and in terms of the interactions between these components. Refinement/Abstraction allows us to use more general specifications, which should also be more understandable, and which can be gradually made more precise. Combining decomposition and refinement offers a very powerful tool to build specifications. This process results in a structured object which describes both the final specification and its elaboration in term of interaction and refinement. Nevertheless the result remains intrinsically a complex object. The next step consists in developing tools to represent, to manipulate and to reason about such structured objects. The aim of this paper is to propose such a tool in the framework of the B method. By exploiting the B theory, and as far as possible without changing the method, we propose three algorithms to extract validated B components, using properties underlying the structure of developments. These new components can be exploited to extend a structured development, for instance to validate new properties
Advances in component-oriented programming
WCOP 2006 is the eleventh event in a series of highly successful
workshops, which took place in conjunction with every ECOOP
since 1996. Component oriented programming (COP) has been
described as the natural extension of object-oriented
programming to the realm of independently extensible
systems. Several important approaches have emerged over the
recent years, including component technology standards, such as
CORBA/CCM, COM/COM+, J2EE/EJB, and .NET, but also the increasing
appreciation of software architecture for component-based
systems, and the consequent effects on organizational processes
and structures as well as the software development business as a
whole.
COP aims at producing software components for a component market
and for late composition. Composers are third parties, possibly
the end users, who are not able or willing to change components.
This requires standards to allow independently created
components to interoperate, and specifications that put the
composer into the position to decide what can be composed under
which conditions. On these grounds, WCOP\u2796 led to the following
definition: "A component is a unit of composition with
contractually specified interfaces and explicit context
dependencies only. Components can be deployed independently and
are subject to composition by third parties."
After WCOP\u2796 focused on the fundamental terminology of COP, the
subsequent workshops expanded into the many related facets of
component software. WCOP 2006 emphasizes reasons for using
components beyond reuse. While considering software components
as a technical means to increase software reuse, other reasons
for investing into component technology tend to be overseen. For
example, components play an important role in frameworks and
product-lines to enable configurability (even if no component is
reused). Another role of components beyond reuse is to increase
the predictability of the properties of a system. The use of
components as contractually specified building blocks restricts
the degrees of freedom during software development compared to
classic line-by-line programming. This restriction is beneficial
for the predictability of system properties. For an engineering
approach to software design, it is important to understand the
implications of design decisions on a system\u27s properties.
Therefore, approaches to evaluate and predict properties of
systems by analyzing its components and its architecture are of
high interest.
To strengthen the relation between architectural descriptions of
systems and components, a comprehensible mapping to
component-oriented middleware platforms is important.
Model-driven development with its use of generators can
provide a suitable link between architectural views and
technical component execution platforms.
WCOP 2006 accepted 13 papers, which are organised according to
the program below. The organisers are looking forward to an
inspiring and thought provoking workshop. The organisers thank
Jens Happe and Michael Kuperberg for preparing
the proceedings volume