CORRECT - Developing Fault-Tolerant Distributed Systems

by Alfredo Capozucca, Barbara Gallina, Nicolas Guelfi, Patrizio Pelliccione and Alexander Romanovsky

The CORRECT project - rigorous stepwise development of complex fault-tolerant distributed systems: from architectural description to Java implementation - is an international project that aims to provide methodological support for developing fault-tolerant distributed systems in a cost-effective way. The proposed architecture-based methodology covers all phases of system development, from requirement specification to implementation. It is built on a Model-Driven Architecture methodology that automatically generates Java code from a UML-based software architecture description by means of semi-formal refinements.

Software and hardware systems have become widely used in many sectors, including manufacturing, aerospace, transportation, communication, energy and healthcare. Failures due to software or hardware malfunctions or malicious intentions can have economic consequences, but can also endanger human life. There is clearly a growing need for these systems to meet the highest dependability requirements.

Software Architectures (SA) involved in Model-Driven Engineering (MDE) techniques help to develop a system blueprint that can be validated and can guide all phases of system development. There are still many challenging issues in this area, in particular the integration of a new methodology into the industrial software-development life cycle, and in relating the results obtained by SA-based analysis to requirements and coding.

CORRECT methodology.

This situation has motivated the investigation of a new architecture-centric method for developing families of complex fault-tolerant distributed systems. This effort is conducted by the Software Engineering Competence Center at the University of Luxembourg (SE2C) in collaboration with the University of Newcastle upon Tyne (UK), in the context of the CORRECT project. CORRECT is a three-year (2004-2006) project, entirely funded by the Luxembourg Ministry of Higher Education and Research. This architecture-based methodology covers all phases of system development, from requirements specification all the way to system implementation. As graphically summarized in the figure, it consists of four steps:

• Step 1: SA specification: initially, an SA specification (described in some architectural language) is produced to model architectural concepts such as components, connectors, ports and configurations. This specification takes into account normal (ie expected) behaviour, while leaving exceptional behaviour unspecified. The dependability of such an SA specification may be verified with SA-related analysis tools.
• Step 2: Annotated SA: software components receive service invocations and return responses when the services are accomplished. The possible responses of a component when implemented and operating are 'normal' and 'exceptional'. While normal responses report those situations where components provide normal services, exceptional responses correspond to errors detected in a component. Therefore, it is natural to design not only normal, but also exceptional behaviour. Similarly to normal behaviour, exceptional behaviour can be elicited from requirements and thus modelled. The goal of this step is to extend the architectural model in order to identify those components or connectors that raise and handle exceptional behaviour. We annotate the architectural model with minimal information, only identifying which component will handle each kind of exception. In contrast, the exception-handling policies are identified later in the process by employing notations and mechanisms specific to fault tolerance. There are a number of reasons for this: the information available at the architectural level could be insufficient to identify how to handle the exception, and, since the handling of exceptions depends strongly on the implementation language selected, we do not want to embed implementation-dependent information into the architectural model.
• Step 3: Model-to-model transformations: the essence of model-driven development is the idea that a system is incrementally obtained by instantiating and refining a specification of system structure and behaviour. The OMG initiative Model-Driven Architecture (MDA) is an implementation of a more general trend of model-driven development, with the deployment effort focused around industrial standards such as MOF, UML, CWM, QVT etc.
  Following the MDA principle, our methodology incorporates proper (automatic or semi-automatic) model-to-model transformation techniques to generate more detailed design models for handling exceptions. Since these models are typically more informative than the architectural ones, it is generally impossible to derive a complete low-level fault-tolerance model. Some extra information must be added and some refinements are needed. If the relevant architectural language supports a behavioural description, this information can be exploited in order to obtain a more detailed design model. Language- or design-specific exception-handling policies are selected at this level, and are modelled using design-level tools.
• Step 4: Code generation via transformations: the next step involves the automatic generation of the application skeleton code from the fault-tolerance design model, via transformation rules.
  Since it is usually impossible to generate a complete implementation, what we may reasonably expect is to generate an implementation schema with a set of classes and their methods and exceptions declaration. The role of a programmer is then to write the body of the methods and the code of the exceptional behaviour, while the schema automatically manages exception propagation and orchestration.

Link:
http://se2c.uni.lu/tiki/tiki-index.php?pt=Research%20Groups$ADS:%20Architecture$CORRECT&page=CorrectOverview

Please contact:
Nicolas Guelfi, University of Luxembourg
E-mail: nicolas.guelfiuni.lu