Model checking RAISE applicative specifications

Ensuring the correctness of a given software component has become a crucial aspect in Software Engineering and the Model Checking technique provides a fully automated way to achieve this goal. In particular, the usage of Model Checking in formal languages has been reinforced in the last decades given the fact that specifications provide an abstraction of the problem under study, supplying a model of the system of tractable size given the state explosion problem faced by the Model Checking technique. In this paper we focus on the main issues for adding Model Checking functionalities to the RAISE specification language and present the semantic foundations of our current approach for doing so. An outline of the main problems faced in the process and of the solutions to solve them are also presented.III Workshop de Ingeniería de Software y Bases de Datos (WISBD)Red de Universidades con Carreras en Informática (RedUNCI

Towards the verification of RAISE specifications through Model Checking

Ensuring the correctness of a given software component has become a crucial aspect in Software Engineering and the Model Checking technique provides a fully automated way to achieve this goal. In particular, the usage of Model Checking in formal languages has been reinforced in the last decades because the specifications themselves provide an abstraction of the problem under study (whether created by abstraction from the software or by hand) and the properties validated at the specification level can be warrantied to be preserved until implementation. In this paper we focus on the main issues for adding Model Checking functionalities to the RAISE specification language and present the most important characteristics of our current approach for doing so. An outline of the main issues and problems faced in the process and possible ways to solve them are also presented.Eje: Ingeniería de software y base de datosRed de Universidades con Carreras en Informática (RedUNCI

The Logic of the RAISE Specification Language

This paper describes the logic of the RAISE Specification Language, RSL. It explains the particular logic chosen for RAISE, and motivates this choice as suitable for a wide spectrum language to be used for designs as well as initial specifications, and supporting imperative and concurrent specifications as well as applicative sequential ones. It also describes the logical definition of RSL, its axiomatic semantics, as well as the proof system for carrying out proofs

AN EXECUTABLE SPECIFICATION FORMALISM REPRESENTING ABSTRACT DATA TYPES

It has been proved to be very useful and necessary to give formal specifications of software systems to be developed. The specifications should help to avoid the necessity of creating prototypes by offering direct executability. A useful specification language aiming the description of abstract data types - while maintaining abstractness - should also support the representation of states of objects, as well as support the transformation of declarative specifications into efficiently executable code. The present paper is intended to give an informal description of a specification language aimed to offer the features discussed above. Although the development of the language has mainly been motivated by the object-oriented language (OMOHUNDRO, 1993), it is intended to function as a specification formalism at a much broader field

A Derivation Strategy for Formal Specifications from Natural Language Requirements Models

Formal methods have come into use for the construction of real systems, as they help increase software quality and reliability. However, they are usually accessible only to specialists, thus discouraging stakeholders' participation, crucial in first steps of software development. To address this problem, we present in this paper a strategy to derive an initial formal specification, written in the RAISE Specification Language, from requirements models based on natural language, such as the Language Extended Lexicon, the Scenario Model, and the Business Rules Model, which are closer to the stakeholders' language. We provide a set of heuristics which show how to derive types and functions, and how to structure them in a layered architecture, thus contributing to fruitfully use the large amount of information usually available after requirements modelling stage. In addition, we illustrate the strategy with a concrete case study

An LTL Semantics of Business Workflows with Recovery

We describe a business workflow case study with abnormal behavior management (i.e. recovery) and demonstrate how temporal logics and model checking can provide a methodology to iteratively revise the design and obtain a correct-by construction system. To do so we define a formal semantics by giving a compilation of generic workflow patterns into LTL and we use the bound model checker Zot to prove specific properties and requirements validity. The working assumption is that such a lightweight approach would easily fit into processes that are already in place without the need for a radical change of procedures, tools and people's attitudes. The complexity of formalisms and invasiveness of methods have been demonstrated to be one of the major drawback and obstacle for deployment of formal engineering techniques into mundane projects

Towards the verification of RAISE specifications through Model Checking

Ensuring the correctness of a given software component has become a crucial aspect in Software Engineering and the Model Checking technique provides a fully automated way to achieve this goal. In particular, the usage of Model Checking in formal languages has been reinforced in the last decades because the specifications themselves provide an abstraction of the problem under study (whether created by abstraction from the software or by hand) and the properties validated at the specification level can be warrantied to be preserved until implementation. In this paper we focus on the main issues for adding Model Checking functionalities to the RAISE specification language and present the most important characteristics of our current approach for doing so. An outline of the main issues and problems faced in the process and possible ways to solve them are also presented.Eje: Ingeniería de software y base de datosRed de Universidades con Carreras en Informática (RedUNCI

Evolutionary design of a full-envelope full-authority flight control system for an unstable high-performance aircraft

The use of an evolutionary algorithm in the framework of H1 control theory is being considered as a means for synthesizing controller gains that minimize a weighted combination of the infinite norm of the sensitivity function (for disturbance attenuation requirements) and complementary sensitivity function (for robust stability requirements) at the same time. The case study deals with a complete full-authority longitudinal control system for an unstable high-performance jet aircraft featuring (i) a stability and control augmentation system and (ii) autopilot functions (speed and altitude hold). Constraints on closed-loop response are enforced, that representing typical requirements on airplane handling qualities, that makes the control law synthesis process more demanding. Gain scheduling is required, in order to obtain satisfactory performance over the whole flight envelope, so that the synthesis is performed at different reference trim conditions, for several values of the dynamic pressure, used as the scheduling parameter. Nonetheless, the dynamic behaviour of the aircraft may exhibit significant variations when flying at different altitudes, even for the same value of the dynamic pressure, so that a trade-off is required between different feasible controllers synthesized at different altitudes for a given equivalent airspeed. A multiobjective search is thus considered for the determination of the best suited solution to be introduced in the scheduling of the control law. The obtained results are then tested on a longitudinal non-linear model of the aircraft