Profesor: Camilo Rueda 1 -...

Working Hypothesis

Desarrollo Formal de Software

Profesor:Camilo Rueda 1

1Universidad Javeriana-Cali

PUJ 2010

Working Hypothesis Oz

Proposito

Construir modelos formalesde sistemas

Verificar sistemas de softwareya construidos

Dar reflexiones sobre modelamiento y metodos formalesMostrar que el modelamiento formal puede resultarpracticoIlustrar la metodologıa con muchos ejemplosComprender las herramientas de apoyo al modelamientoformal

Contraste: Depuración


Lo que aprendera en el curso

Modelar (en lugar de programar)Las nociones de abstraccion y de refinamientoAlgunas tecnicas matematicas (para estructuras de datos)La practica de probar propiedades de sistemas yprogramas mecanicamenteEl uso de herramientas automaticas de modelamiento yverificacion de sistemas


Las Clases

Introduccion y motivacion mediante ejemplos pequenos, 2clasesEjemplos de desarrollo formal de programas secuenciales:2 clasesEjemplos de desarrollo formal de programas distribuidos: 2clasesEjemplos de desarrollo formal de programas concurrentes:1 claseRefrescar nociones de logica, teorıa de conjuntos, prueba,probadores: 2 clasesEjemplos de sistemas completos: 4 clasesPractica de uso de herramientas de modelamiento: 1 clase


Por que y cuando usar las tecnicas del curso?

Porque a veces no hay nada mejor que se pueda usar...Cuando el riesgo es muy altoCuando los usuarios ya han sufrido suficientementeCuando la gente se cuestiona sus procesos de desarrollode sistemasCuando el costo de mantenimiento se ha vuelto muy alto

Porque ha llegado a la conclusion de que lacomputacion deberıa ser tambien unaingenierıa


Para que le servira en su vida practica?

Para orientar mejor la concrecion de los requerimientos deun sistemaPara hacer mejores especificacionesPara identificar cuando un diseno entra en conflicto con laespecificacionpara verificar (sin depurar) un programa ya construidopara garantizar que un software cumple ciertaspropiedades fundamentalesPara al menos disenar mejores estrategias de depuracion

Para estar al tanto de un area estrategicade la computacion: premio Turing


Requisitos

Que debe saber antes?programarMatematica basica: funciones, relaciones

Que es bueno saber antes?algo de teorıa de conjuntosalgo de logicaalgo de diseno de softwareprogramar en algun lenguaje


Supuestas dificultades sobre tema del curso

Tiene que ser matematicoEl formalismo es difıcil de entenderNo es suficientemente visual (no hay cajas, flechas, etc.)Una persona cualquiera no puede realizar las pruebas quese requieren


Dificultades reales

Se debe pensar mucho antes de ecribir codigoIncorporacion en el proceso de desarrolloModelar es una actividad arduaLa tecnologıa de pruebas debe mejorarRealizar pruebas presupone criterios de disenoBaja calidad de los documentos de diseno


Datos en la industria (Abrial)

– A ojo:

n lıneas de codigo implican n/3 pruebas90 % de las pruebas son automaticas10 % de las pruebas son interactivas400 pruebas interactivas por hombre-mes

– 60,000 lıneas de codigo 20,000 pruebas 2,000 pruebasinteractivas– 2,000 pruebas interactivas 2,000/400 = 5 meses-hombre– Menos caro que tests exhaustivos


En otras disciplinas

Disciplinas de ingenierıa madurasAvionicaAeroespacialIngenierıa civilIngenierıa mecanicaConstruccion de barcos

Hay estrategias similares a metodos formales?Si, los planos:

Cierta representacion del futuro sistemasin la base (no se puede manejar el plano de un carro)permiten razonar sobre el sistema antes de construirlo


Razonar sobre el futuro sistema

Definir y calcular su comportamiento (lo que hace)Incorporar restricciones (lo que no puede hacer)Establecer su arquitecturabasandose en teorıas apropiadas

resistencia de materialesmecanica de fluidosgravitacion, etc.


Tecnicas para construir planos

Utilizar convenciones pre-definidas (usualmentecomputarizadas)Las convenciones deben facilitar el razonamientoAgregar detalles en versiones mas exactasPosponer escogencias dejando opciones abiertasDescomponer un plano en variosReutilizar planos (con pequenos cambios)


Que hacer ANTES de los planos

Definir objetivos principales del futuro sistemaEstudiar factibilidad

Definir Requerimientos


El ciclo de desarrollo clasico

Estudios del sistemaDocumento de requerimientosEspecificacion tcnicaDisenoCodificacionTests


Dificultades

Asegurar consistencia entre fasesMetodos formales pueden ayudar (en ultimas fases)Pero siguen dificultades en primeras fasesParte mas debil: el documento de requisitos


Acerca del documento de requerimientos

Importancia de este documento (dado el sitio en el ciclo dedesarrollo)Obtener un buen documento de requerimientos no es facil

cosas que se dejan de ladoDemasiado especıfico

Los documentos son en general difıciles de explotarPosiblemente existan guıas que permitan hacerlo


Acerca del documento de requerimientos (cont)

A menudo es necesario reescribirloCuesta una cantidad significativa de tiempo y dineroEl famoso sındrome de cambio de especificacion podrıadesaparecer


Reglas de estructuracion

Dos textos separados en el mismo documentotexto de explicacion: el por quetexto de referencia: el que

Incluir el texto de referencia en el de explicacionAnalogıa: los textos de matematicasEl texto de referencia se convierte eventualmente en eldocumento oficialdeben firmarlo las personas involucradas


El texto de referencia

Contiene las propiedades del futuro sistemaConstruido a partir de breves “fragmentos” etiquetados(trazabilidad)Debe ser facil de leer (tipo de caracteres diferente) y facilde identificar (enmarcado en caja)


Requerimientos: ejemplo del MIO

Determinar cuidadosamente los actores del sistema, que seincluiran en la forma de un cierto numero de conjuntos

P1: El sistema se compone de buses y estaciones


Requerimientos (cont)

El sistema controla la llegada y salida de buses de lasestaciones

P2: En cada estacion puede haber como maximo un bus


Requerimientos (cont)

El sistema identifica estaciones que tienen un bus

D1: El sistema registra buses parqueados en estaciones


Las variantes del desarrollo formal de sistemas

principio fundamentalSi el modelo de un sistema computacionaltiene una cierta propiedadentonces el sistema real tambien la tiene

Disenar para garantizarque las propiedadesse cumplen

metodo B

Disenar y luego chequearque las propiedadesse cumplen

model checking

verificar las propiedadesde un software ya construido

metodo JML


Metodo B: idea general

Modelar mediante sistemas de transicion de estadosEstado: observaciones del sistema en un momento dadoTransicion: ocasionada por un evento u operacion

Parte estatica parte dinamicaconstantes, operacionesvariables


Metodo B: idea general (cont)

constantes,variables

propiedades,invariante

operaciones guarda,sustitución


Eventos

Un evento es una transicion que se puede observarConsta de dos partes: una guarda y una accionLa guarda establece cuando puede ocurrir el evento

Esta formada por varias condicionesLa accion explica como se modifican las variables

Esta formada por varias asignaciones simples


Eventos: ejemplo

abrir =when

cerradas > 0then

cerradas, abiertas := cerradas − 1, abiertas + 1end

cerrar =when

abiertas > 0then

cerradas, abiertas := cerradas + 1, abiertas − 1end


Eventos(2)

Notacion

when < guarda > then < accion > end

Caso especial cuando la guarda es true

begin < accion > end


Eventos no determinısticos

xxx=any x , y , z, ... where

P(x , y , ..., v , w , ...)thenS(x , y , ..., v , w , ...)end

cerrar=any p where

p ∈ abiertasthenabiertas := abiertas\{p} ‖ceradas := cerradas ∪ {p}end


Sistema MIO

Hay una cierta cantidad de busesHay una cierta cantidad de estacionesEn un momento dado, en una estacion puede estar un busSe observa la llegada y salida de buses de las estaciones


Sistema MIO: componentes estaticos. Contexto

Constante n : numero total de busesConstante m : numero total de estaciones

Para estas constantes se definen axiomas, que establecen suspropiedades

variable tipon n ∈ N1m m ∈ N1

constantes, conjuntos y sus propiedades forman elcontexto del sistema


Sistema MIO: componentes estaticos. Contexto enRODIN

CONTEXT buses estacionesCONSTANTS

nm

AXIOMSaxm1 : m : N1axm2 : n : N1

END


Sistema MIO: componentes estaticos: abstraccion

Variable be: numero de buses en estacionesPropiedades (tipo) de la variable:

be ∈ N

Observaciones de be obedecen a un invariante

be ≤ n ∧ be ≤ m


Sistema MIO: componentes dinamicos)

Inicializacionbe := 0Entra un bus a una estacion

when be < n ∧ be < m then be := be + 1 end

Sale un bus de una estacion

when be > 0 then be := be − 1 end


MIO: especificacion en RODIN

MACHINE especSEES buses estacionesVARIABLESbe

INVARIANTinv1 : be : Ninv2 : be ≤ ninv3 : be ≤ m

...


MIO: especificacion en RODIN(cont)

EVENTSinitialisation

beginact1 : be := 0

end


MIO: especificacion en RODIN(cont)

...llega

whengrd11 : be < n

thenact11 : be := be + 1

endsale

whengrd11 : be > 0

thenact11 : be := be − 1

endEND


Obligaciones de prueba

La especificacion consta de:El contexto, o parte constante, que contiene:

los tipos, que se prepresentan mediante conjuntos diferidoslas constantes del sistemalos axiomas (“properties”) que definen propiedades de lasconstantes y conjuntos

El modelo abstracto (o maquina), que contiene:Las variables del sistemael invariante que expresa propiedades de las variablesLa parte dinamica del sistema: los eventos u operaciones


Obligaciones de prueba (2)

La especificacion debe probarse:

pruebas de consistenciasupuestos probar que

los axiomas los valores inicialescumplen el invariante

los axiomas, el invariante, los nuevos valores asignadosy la guarda del evento cumplen el invariante

prueba de ausencia de bloqueossupuestos probar que

los axiomas y el invariante la disyuncion de lasguardas se cumple


Reglas de inicializacion

Sea v := K la inicializacion.

Regla de factibilidad: ` ∃v .v = K FIS

Regla de inicializacion de invariante: ` I(v = K) INI INV


Reglas de inicializacion: ejemplo

Factibilidad: ` ∃parq.parq = 0 FIS

Satisfaccion del invariante:

` 0 ∈ N ∧ 0 ≤ nest ∧ 0 ≤ nbus INI INV


Reglas: preservar el invariante

Sean:un sistema con variable v e invariante I(v)

un evento con guarda G(v) y accion R(v)

Factibilidad de la accion mantener el invarianteI(v)G(v) FIS`∃v ′.v′ = R(v)

I(v)Gi(v) Ev/inv/INV`

I(R(v))

Ausencia de deadlock

I(v)` DLFG1(v) ∨ . . . ∨Gn(v)

Profesor: Camilo Rueda 1 -...

Documents

Transcript of Profesor: Camilo Rueda 1 -...