María Marta Novaira’s research while affiliated with National University of Río Cuarto and other places

Tabular notations, in particular SCR specifications, have proved to be a useful means for formally describing complex requirements. The SCR method offers a powerful family of analysis tools, known as the SCR Toolset, but its availability is restricted by the Naval Research Laboratory of the USA. This toolset applies different kinds of analysis considering the whole set of behaviours associated with a requirements specification. In this paper we present a tool for describing and analyzing SCR requirements descriptions, that complements the SCR Toolset in two aspects. First, its use is not limited by any institution, and resorts to a standard model checking tool for analysis; and second, it allows to concentrate the analysis to particular sets of behaviours (subsets of the whole specifications), that correspond to particular scenarios explicitly mentioned in the specification. We take an operational notation that allows the engineer to describe behavioural "scenarios" by means of programs, and provide a translation into Promela to perform the analysis via Spin, an efficient off-the-shelf model checker freely available. In addition, we apply the SCR method to a Pacemaker system and we use its tabular specification as a running example of this article.

We study the use of an off-the-shelf formal verification tool, namely the explicit-state model checker SPIN, for various analyses related to SCR (Software Cost Reduction) formal requirements specifications. Unlike other studies, where model checking is used for a specific purpose in the context of SCR analysis (e.g., test generation or invariant verification), we use the model checker as the only analysis tool, for consistency checking, completeness analysis, property verification, etc. Moreover, to assess our characterization of the various analyses in terms of model checking, we develop a case study (a pacemaker specification), more complex than those typically found in the SCR literature.

We report on our experience in teaching introductory courses on programming based on formal specification and program calculation, in two different Computer Science programmes. We favour the use of logic as a tool, the notion of program as a formal entity, as well as some issues associated with efficiency. We also review and use in practical cases some program transformation strategies, such as generalisation, tupling and modularisation. We describe our approach, its advantages and drawbacks. Furthermore, we present some preliminary results from an ongoing qualitative research which intends to characterise, describe and understand the students' experiences when taking these courses.

Abstract In this paper we introduce a proposal for teaching formal methods in an undergraduate curricula, using the Coq proof assistant and type theory concepts. We propose a course of specification, derivation and verification of systems in the functional and imperative paradigms, and an extension to reactive and real time systems. We describe too a first experiment. Keywords: Programming Education, Type Theory, Coq, Functional Programming, Imperative Programming, Reactive and Real Time Systems. ,,,,,,, ,,,,,,

Resumen Para el abordaje al diseño y desarrollo de un sistema de software es necesario estudiar en detalle la estructura y dinámica de la organización donde el mismo funcionará. Esto ayudará a obtener una lista de requerimientos del sistema más acertada. Modelar los procesos de negocio es una parte esencial del proceso de desarrollo de software que permite a los analistas definir qué hace el negocio y a partir de ello definir los requerimientos del sistema. Con el propósito enunciado, Booch, Rumbaugh y Jacobson[3] proponen construir el modelo de negocio como primera etapa de la metodología de desarrollo de software, denominada Proceso Unificado. En este trabajo mostramos una propuesta de un modelo genérico para el modelo de negocio, para lo cual analizamos cada uno de los artefactos del modelo y cómo ellos se relacionan, y especificamos un conjunto de reglas de negocio[7] que el modelo debe verificar. El modelo genérico propuesto es representado gráficamente en términos de UML (Unified Modeling Language)[2] a través de un diagrama de clases. El modelo genérico tiene como finalidad establecer las bases para especificar un modelo concreto, es decir, permite definir instancias de modelos de negocio a un problema real. Palabras Claves: Proceso Unificado, Modelo de Negocio, Reglas de Negocio, Artefactos, Modelo Genérico 1. Introducción Entender la estructura y dinámica de la organización, detectar los problemas corrientes e identificar potenciales o posibles mejoras y asegurar un entendimiento común de la organización entre todos los participantes, son algunos de los focos principales a la hora de decidir el diseño y desarrollo de un sistema de software. Luego se podrán derivar los requerimientos del sistema necesarios para soportar la estructura y dinámica de la organización. El Proceso Unificado de desarrollo de software [3] es una metodología que define quién está haciendo qué, cuándo, y cómo para construir o mejorar un producto de software. Es una guía para todos los participantes del proyecto, tanto clientes y usuarios, como desarrolladores y directivos. El Proceso Unificado utiliza UML (Unified Modeling Language) [2], como medio de expresión de los diferentes modelos que se crean durante las etapas del desarrollo. UML es un lenguaje estándar de modelado que permite visualizar, especificar, construir y documentar los artefactos de un producto de software. El Modelo de Negocio [6] es la primer etapa que propone el proceso que permite establecer una abstracción de la organización. El RUP [1] (Rational Unified Process) propone construir un conjunto de artefactos para modelar integramente el negocio. Existen algunos trabajos (desde [8] a [12]) que presentan el modelo de negocio del RUP, la definición de sus artefactos y la evolución al modelo de requerimientos, sin embargo no reflejan claramente las relaciones entre los artefactos ni especifican reglas para verificar las instanciaciones realizadas. En [8] propone un método para obtener el modelo de requisitos a partir del modelo de negocio. En [11] propone utilizar las extensiones a UML propuestas por la OMG, para el Modelado de Negocio. En particular se utilizan los estereotipos, que son capaces de contemplar una visión inicial de los procesos de negocio, siendo posible capturar de forma significativa eventos, entradas, recursos y salidas asociadas a un proceso de negocio. En [12] se presenta una definición del modelo del negocio y del dominio utilizando Razonamiento Basado en Casos (RBC), y se propone obtener el Modelo del Negocio a partir de un conjunto de especificaciones iniciales brindadas por los analistas. En este trabajo se muestran y explican algunas relaciones detectadas entre los artefactos del modelo de negocio, se define un conjunto de reglas de negocio[7] que debe cumplir este modelo y se construye un modelo genérico del mismo. El modelo genérico se presenta gráficamente en términos de UML a través de un diagrama de clases, que podrá ser instanciado con diferentes modelos reales. El modelo genérico establece las bases para especificar un modelo concreto. El propósito principal del modelo genérico es facilitar al desarrollador la comprensión y desarrollo del contexto del sistema. Con la aplicación de las reglas definidas para cada artefacto y la relación entre los mismos, el modelo genérico ayuda a construir un modelo suficiente y correcto para el conocimiento que se requiere del contexto. Por otro lado, el modelo genérico puede ser también usado para verificar un modelo de negocio concreto previamente construido.