Introduccin a los Mtodos Formales

1
Introducción a los Métodos Formales
2
Objetivos

• Introducción a los métodos formales con especial
  énfasis en el uso del lenguaje de especificación
  del método RAISE (RSL).
• Ganar experiencia práctica en la escritura de
  especificaciones formales en RSL, en particular
  haciendo uso de un estilo aplicativo secuencial.
• Obtener experiencia en el uso de las herramientas
  de RAISE.

3
Bibliografía

• Transparencias
• http//www.dirinfo.unsl.edu.ar/ingsw1/index.h
  tml
• Libros
• The RAISE Specification Language
• The RAISE Development Method
• Specification Case Studies in RAISE
• Sitio del UNU/IIST (herramientas, reports, etc.)
• http//www.iist.unu.edu

4
Confiabilidad

• Cómo lograrla?
• Aseguramiento de la calidad del SW
• Gestión de la configuración del SW.
• Planificación y control.
• Evaluación y control de riesgos.
• Revisiones del sw.
• Pruebas del sw.

5

• Uso de FM
• Encontrar errores cuanto antes.
• Concentrarnos en las etapas iniciales captura y
  análisis de requisitos.
• FM ayudan a eliminar inconsistencias e
  incompletitud.
• Razonar sobre las propiedades del sistema.
• FM permiten demostrar propiedades.

6
Terminología

• Prueba (test, testing). Acto de ejercitar el
  software.
• Demostración ? Proof

7
Métodos Formales(Formal Methods)

• Los métodos formales que se utilizan para
  desarrollar sistemas de computadoras son técnicas
  de base matemática para describir propiedades del
  sistema. Estos métodos formales proporcionan
  marcos de referencia en el seno de los cuales las
  personas pueden especificar, desarrollar y
  verificar los sistemas de manera sistemática, en
  lugar de hacerlo ad-hoc.
• Software Engineering Encyclopedia (Marcianiack,
  JJ 1994).

8
Métodos de Desarrollo de Software

• Ad-hoc
• Sistemáticos
• Rigurosos
• Formales

9
Métodos Formales(Formal Methods)

• Mathematically based techniques for the
  specification, development and verification of
  software and hardware systems.
• http//en.wikipedia.org/wiki/Formal_methods

10
FM, Sistema Formal y Notación Formal (Alagar
Periyasamy)

• Lenguaje Formal
• Sintaxis precisa
• Semántica precisa
• Sistema de Demostración (proof)
• Sistema deductivo que permite razonamiento formal
  (Demostración de propiedades).
• Herramientas para
• Especificar
• Demostrar propiedades

Notación Formal
Sistema Formal
Método Formal
11
Métodos Formales Estilos de Desarrollo

• Transformacional
• (p.e. SETS)
• Invent and Verify
• (p.e. VDM, Z, RAISE, B)

12
Grados de Rigor (NASAs Langley Research Center )

• Nivel 1 Especificación formal de todo o parte
  del sistema.

13
Grados de Rigor (2)(NASAs Langley Research
Center )

• Nivel 2 Especificación formal en dos o más
  niveles de abstracción y pruebas en lápiz y papel
  de que la especificación detallada implica la más
  abstracta.

14
Grados de Rigor (3)(NASAs Langley Research
Center )

• Nivel 3 Prueba formal realizada usando un
  probador de teoremas semi-automático.

15
Especificaciones de Software

16
Especificación de Requisitos

• Cómo especificar los requisitos?
• Informalmente
• Lenguaje ambiguo
• (p.e. lenguaje natural)

17
Especificación de Requisitos

• Cómo especificar los requisitos?
• Semiformalmente
• (sintaxis más ó menos precisa,
• semántica informal,
• p.e. UML)

18
Especificación de Requisitos

• Cómo especificar los requisitos?
• Formalmente
• (sintaxis y semántica formal)
• Especificación formal modelo matemático que
  describe el mundo real.

19
Especificación

• Especificación Implementación
• (qué) (cómo)
• (abstracto) (concreto)
• Especificación Programa

20
Estilos de Especificaciones Formales
21
FM, Pro y Contras

• Especificaciones no ambiguas. ?
• Demostración formal de propiedades. ?
• Comprensión profunda del problema gt reducción de
  errores y omisiones. ? gt
• incremento en la confiabilidad. ?
• Generación automática de código. ?

22
FM, Pro y Contras

• Verificación es costosa y consume tiempo. ?
• No se adaptan a todo tipo de sistema. ?
• Pocos expertos. ?
• Dificultan la validación con el cliente. ?
• Combinación de técnicas

23
RAISE
24
Qué es RAISE?

• Rigorous Approach to Industrial Software
  Engineering
• Consiste de
• Un método para desarrollar software.
• Un lenguaje de especificación formal (RSL).
• Conjunto de herramientas.

25
Características del método RAISE

• Desarrollo separado
• Desarrollo incremental
• Inventar y Verificar
• Riguroso

26
Grados de Rigor en RAISE

• Sólo especificación formal formalidad aplicada
  sólo al proceso de especificación.
• Especificación formal y desarrollo riguroso 1
  rigor en el proceso de desarrollo (se mantienen
  las relaciones de desarrollo y se las examina,
  sin embargo no son justificadas).
• Especificación y desarrollo formal 2 más
  justificación.

27
Método RAISE (1)
28
Método RAISE (2)

• Especificación Inicial E0 ,Crítica.
• No somos expertos en el domino.
• Requisitos en lenguaje natural, por personas
  diferentes.
• Ambiguos
• Inconsistentes
• Incompletos
• Vagos
• Qué hacer para construir una buena
  especificación inicial?

29
Método RAISE (3)

• Ser abstracto.
• Usar el vocabulario del cliente.
• Hacerla legible.
• Buscar problemas.
• Identificar condiciones de consistencia y
  políticas.

30
Validación y Verificación

• Validación Estamos construyendo el producto
  correcto?
• Verificación Estamos construyendo correctamente
  el producto?

31
Validación (1)

• Paso importante.
• No puede ser formal.
• Técnica Controlar que cada requisito ha sido
  tenido en cuenta.
• Cubierto correctamente.
• No cubierto (olvido) gt cambiar la
  especificación.
• No cubierto (pensamos que no es una buena idea
  por imposibilidad, inconsistencia) gt
  rediscutirlo con cliente.
• No cubierto (requisitos no funcionales, p.e.
  Sist. Op., lenguaje, performance, etc.) gt
  diferido para más adelante

32
Validación (2)

• Otras técnicas
• Buscar en la especificación propiedades que
  deberían estar en los requisitos pero que no
  están.
• Desarrollar casos de prueba (y resultados
  esperados) junto con la especificación para el
  cliente.
• Re-escribir los requisitos a partir de la
  especificación.
• Construir un prototipo de todo o parte del
  sistema para correr algunos casos de prueba.
• Objetivo de la validación buscar el compromiso
  del cliente.

33
Verificación (1)

• Controlar que estamos desarrollando el sistema
  correctamente.
• Viene después de la validación. Asume la
  corrección de E0.
• Basada en Inventar y Verificar
• Relación de Refinamiento o Implementación.

34
Verificación (2)Relación de Refinamiento o
Implementación

• Transitividad
• Monotonicidad
• B2 es un
• refin. de B1.
• A0 es un
• contrato entre
• los des. de
• A y B.

35
Relación de Refinamiento, condiciones (i)

• El nuevo modelo (A1) debe incluir TODAS las
  entidades del viejo (A0 )
• types, values, objects, variables y channels con
  los mismos nombres y tipos maximales.
• A1 puede tener más entidades que A0.
• Implementación estática, garantiza monotonicidad.
• Puede ser chequeada estáticamente.

36
Relación de Refinamiento, condiciones (ii)

• Todas las propiedades de A0 se mantienen (siguen
  siendo válidas) en A1.
• axiomas, defs. de funciones, constantes,
  restricciones en subtipos.
• No puede ser chequeada estáticamente, necesita
  demostración (Recordar que RAISE es riguroso.)

37
Estilos y Ruta de Desarrollo en RAISE
38
Lightweight FM

• Uso de FM sin demostraciones ni refinamientos.
• E0
• Implementación
• Para especificaciones iniciales simples.

39
Herramientas de RAISE

• Type-checker
• Confidence condition generator
• Pretty printer
• Traductores (C, Ada, SML ...)
• Demostrador

40
Confidence Conditions (1)

• Propiedades que deberían ser demostradas como
  verdaderas si el módulo no es inconsistente pero
  que no pueden determinarse como verdades o falsas
  por medio de una herramienta automática.

41
Confidence Conditions (2)

• Precondiciones de funciones parciales son
  satisfechas.
• Valores que se suponen deben ser subtipos, son
  subtipos.
• Definiciones de subtipos no vacíos.
• La definición de una función parcial sin pre
  condición.
• La definición de una función total con una pre
  condición...

42

• scheme CC
• class
• value
• x1 Int hd lt..gt,
• x2 Int f1(-1),
• x3 Nat -1,
• f1 Nat --gt Nat
• f1(x) is -x pre x gt 0
• type None i Nat - i lt 0
• value
• x4 Nat - x4 lt 0,
• f2 Nat -gt Nat
• f2(x) as r post r x 0
• end

43
CC.rsl421 CC -- application arguments and/or
precondition let x lt..gt in x lt..gt
end CC.rsl520 CC -- application arguments
and/or precondition -1 gt 0 /\ let x -1 in x gt
0 end CC.rsl616 CC -- value in subtype -1 gt
0 CC.rsl87 CC -- function result in
subtype all x Nat - (x gt 0 is true) gt -x gt 0
44
CC.rsl931 CC -- subtype not empty exists i
Nat - i lt 0 CC.rsl1110 CC -- possible value
in subtype exists x4 Nat - x4 lt
0 CC.rsl137 CC -- possible function result
in subtype all x Nat - exists r Nat - r x
0
45
Ventajas en el uso de RAISE

• Precisión
• Abstracción
• Razonamiento formal
• Re-uso
• ? Menor cantidad de errores.