Ternas de Hoare

INTEGRANTES:
PAULO CSAR VALDEZ
AGUILAR ERICK DANIEL
QUISPE HUARI ROBERTO
KENJI UEDA RODRIGUEZ
UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS| FACULTAD DE INGENIERIA
DE SISTEMAS

DEDICATORIA

INDICE

INTRODUCCIN

La verificacin formal de un algoritmo consiste en un conjunto de tcnicas

de comprobacin que permiten demostrar que un programa puede
funcionar correctamente o no.
La verificacin consiste en todo un proceso de inferencia en el cual cada
representacin formal posee una regla de correspondencia y esta
representacin formal se da a travs de la terna de Hoare.

LOGICA DE HOARE
Es una extensin de la lgica de predicados de primer orden para razonar
sobre la correccin de programas imperativos construidos sobre una
signatura (S, ). Esta extensin se obtiene introduciendo un lenguaje de
comandos con el que se construyen los programas y una relacin especial
para expresar el comportamiento de un programa, asi como un conjunto de
reglas de clculo para la manipulacin de las expresiones de
comportamiento.
Basada en la idea de diagrama de flujo anotado.

S es una frase de cdigo en un programa de alto nivel, con una nica

entrada y una nica salida normal.
Instruccin.
Bloque de instrucciones consecutivas.
Un programa o subprograma.

Cada frase S denota una relacin entre dos estados en un espacio de

estados definido por el producto cartesiano de los valores de las variables
del programa. Es decir, al ejecutar una instruccin o secuencia de
instrucciones S, se modifica el valor de una o varias variables, transitando
de un estado a otro.
P y Q son anotaciones, frmulas de la Lgica de Primer Orden (Lgica de
Predicados).
P Precondicin (se refiere al estado previo a S)
Q Postcondicin (se refiere al estado posterior a S)

Notacin: {P}S{Q}

REPRESENTACIN FORMAL: TERNAS DE HOARE

Si C es una parte del cdigo, entonces cualquier asercin {P} se denomina
precondicin de C si {P} slo implica al estado inicial. Cualquier asercin
{Q} se denomina postcondicin si {Q} slo implica el estado final.
Esta definicin se representa como: {P}C{Q} y se denomina terna de
Hoare.
EJEM. 1
{ y 0} x:= 1/y {x= 1/y}
EJEM. 2
A veces no existe precondicin:
{ } a:=b {a=b}
Esto significa que siempre se obtienen estados que satisfacen la
postcondicin independientemente de la precondicin.
{ } Representa la asercin vaca que se puede entender como verdadero
para todos los estados.
PRECONDICIONES Y POSTCONDICIONES
Las precondiciones indican las condiciones que deben satisfacer los datos
de entrada para que el programa pueda cumplir su tarea.
Las postcondiciones indican las condiciones de salida que son aceptables
como soluciones correctas del problema en cuestin.
Ejemplo:
Programa que calcula la raz cuadrada
Precondicin: Que el argumento de la funcin no sea negativo
Postcondicin: La raz cuadrada de ese argumento.
NOMENCLATURA:
En la mayora de los cdigos el estado final depende del estado inicial esto
sucede tambin en el caso de la precondicin y postcondicin estas no son
independientes entre s.
Existen dos posibles nomenclaturas que permiten
dependencia entre precondicin y postcondicin:

reflejar

dicha

REPRESENTACIN DEL SUBNDICE: mediante subndices se indica si

las variables representan valores iniciales o finales. {a =b } {b
=a } donde representa el estado final y el estado inicial.

REPRESENTACIN DE LAS VARIABLES OCULTAS: Las variables ocultas

son variables que aparecen o no en el cdigo y que se introducen

para almacenar los valores iniciales de ciertas posiciones de

memoria. Su definicin debe aparecer en la precondicin. {a=A,b=B}
h:=a; a:=b; b:=h {a=B, b=A}

CONCEPTO DE CORRECCIN
En este concepto se debe de distinguir dos clases de correccin:
Si {P}C{Q} es un cdigo con la precondicin {P} y la postcondicin {Q},
entonces {P}C{Q} es correcto si cada estado inicial posible que
satisfaga {P} da como resultado un estado final que satisface {Q}.

CORRECCIN PARCIAL:
En un programa real, aparecen declaraciones de tipo y
declaraciones de variables as como implementaciones de
funciones (pueden ser implementaciones incorporadas al sistema
o hechas por el usuario) que determinan la signatura del
programa, adems el segundo argumento de un comando de
asignacin puede ser cualquier expresin del correspondiente tipo
s construida con constantes y funciones implementadas, y el
primer argumento de un comando de seleccin o de iteracin
puede ser cualquier expresin del tipo BOOL. En nuestros
programas, aunque no vamos a considerar declaraciones de tipo
ni de variables, supondremos que existe una declaracin de
signatura donde aparecen los tipos y las constantes y funciones
necesarias con propiedades conocidas, as como una asignacin
de tipo a cada variable de programa.
Se dice que {P}C{Q} es parcialmente correcto si el estado final de
C, cuando termina el programa (aunque no se le exige esta
premisa), satisface {Q} siempre que el estado inicial satisface
{P}.
EJEMPLO
Probar la correccin del siguiente algoritmo respecto de su
especificacin:
P {x > 1}
xx+1
Q {x > 2}
sp(x x + 1, x > 1)
(y) x = (x + 1)[x : y] (x > 1)[x : y]
(y) x = y + 1 y > 1
x>2

CORRECCIN TOTAL:

Se da cuando un cdigo adems de ser correcto parcialmente

termina. Como hemos visto, la validez de una sentencia de
correccin parcial no implica que el transformador de estados
correspondiente al programa que aparece en la sentencia este
definido para todos los estados denotados por la precondicin.
Esta indefinicin, a nivel terico, slo puede deberse a la aparicin
de ciclos tales que la aplicacin reiterada del transformador
asociado al cuerpo del ciclo a estados en los que es vlida la
condicin de control nunca alcanza un estado en el que no se
cumpla dicha condicin. En estos casos se dice que el programa
no termina. El lenguaje de la lgica de Hoare se podra ampliar
con frmulas de correccin total de la forma [P][Q] cuya validez
en una interpretacin A, para un estado esta, se puede establecer
de la forma siguiente:
A |=sta [P][Q], si y slo si A |=sta P implica sta[]Asta0 y A |
=sta0 Q
Y su validez en A se cumplira cuando sea vlida para todos los
estados definibles sobre A; lo que significa que la validez de una
frmula [P][Q] implica la terminacin del programa cuando
parte de un estado caracterizado por P y la validez de Q en el
estado que se alcanza.
Sin embargo, el clculo de Hoare no se amplia para tratar
sentencias de correccin total, sino que la correccin parcial y la
terminacin se suelen tratar por separado.
Aunque el lenguaje de sentencias de Hoare no contempla la
posibilidad de expresar la terminacin normal de programas, en
muchos casos se puede recurrir a un mtodo parcialmente
informal derivado del siguiente razonamiento:
La posibilidad de no terminacin de un programa se debe
normalmente a la aparicin de ciclos y para que pueda terminar
un ciclo es necesario que su cuerpo produzca algn tipo de
evolucin o progreso de los estados hacia situaciones en las que
no se cumpla la condicin de control. Esta idea la podemos
concretar expresando la evolucin del ciclo mediante una funcin
de progreso f, con valor entero, tal que deba ser no negativa para
que se ejecute el ciclo y disminuya estrictamente despus de cada
repeticin; como el decrecimiento de la funcin en estas
condiciones no puede ser perpetuo, resulta obvio al menos
intuitivamente que el ciclo deber terminar.
Los cdigos sin bucles siempre terminan por lo que la correccin parcial
implica la correccin total. Esta distincin es esencial slo en el caso de
cdigos que incluyan bucles o recursiones.

CALCULO DE HOARE
Este clculo se utiliza para la correccin de programas de manera parcial,
se recurre a la ampliacin del clculo para la deduccin natural apto para
tratar slo con frmulas del clculo de predicados de primer orden
incorporando un conjunto de reglas para la deduccin de la validez de
frmulas de correccin parcial conocido como clculo de Hoare. Este clculo
consta de una regla general independiente de la estructura del programa
que aparece en la frmula de correccin, que refleja el significado de las
frmulas de correccin parcial, y una serie de reglas, una por cada
comando, ligadas a la estructura del programa. Con estas ltimas reglas se
intenta plasmar el efecto de cada comando del lenguaje de programacin,
por lo que constituyen una autentica semntica para dicho lenguaje
conocida como semntica axiomtica. La regla independiente es:

Regla de refinamiento:
` P P 0 ; ` {P 0}{Q0}; ` Q0 Q ` {P}{Q}

Esta regla refleja realmente la semntica de las frmulas de correccin

parcial (vase el ejercicio 2.4) y nos viene a decir que siempre se puede
reforzar la precondicin y/o debilitar la postcondicin de una frmula de
correccin vlida.

REGLAS
RELATIVAS
POSTCONDICIONES

LAS

PRECONDICIONES

Si R y S son dos aserciones entonces se dice que R es ms fuerte que S si R

S. Si R es ms fuerte que S entonces se dice que S es ms dbil que R.
Ejemplo: i>1 es ms fuerte que i>0 ya que siempre que i>1 esto implica
que i>0. Por tanto i>1 i>0.
Si una asercin R es ms fuerte que una asercin S entonces todos los
estados que satisfacen R tambin satisfacen S pero no viceversa. Un

fortalecimiento de la asercin disminuye el nmero de estados que la

pueden satisfacer.

Ms fuerte ms selectivo, ms especfico.

Ms dbil menos selectivo, ms general.

La asercin ms dbil es { } que recoge todos los estados posibles.

Constante lgica V (true).
La asercin ms fuerte ser por tanto F (false), ya que representa que
ningn estado satisface dicha condicin.

ESPECIFICACI Y VERIFICACIN DE PROGRAMAS

Axioma para el programa vaco:

` {P}SKIP{P}
Este axioma refleja la
transformador identidad.

semntica

del

programa

vaco

como

Axioma para la asignacin:

` {P{X/t}}X := t{P}
Cuando la sustitucin P{X/t} sea admisible y el clculo de la expresin t
termine. Este axioma refleja el hecho de que despus de ejecutar un
comando X := t, el valor de la variable X se iguala al valor de t, luego si
se quiere que la frmula P sea vlida despus de la asignacin, antes
debe ser vlida la misma frmula para t en lugar de X.

Regla para la seleccin:

` {P B}{Q}; ` {P B}{Q}
` {P} IF B THEN ELSE END {Q}
Esta regla refleja la semntica del comando correspondiente y nos dice
que para que una construccin con este comando sea correcta respecto
a una especificacin (P, Q), lo debe ser cada uno de los programas
alternativos y respecto a las especificaciones obtenidas reforzando la
precondicin con las condiciones necesarias para que se ejecuten dichos
programas.

Regla para la repeticin:

` {P B}{P}
` {P}WHILE B DO END {P B}

Esta regla nos dice que si P es una frmula que se mantiene cada vez
que se ejecuta el cuerpo del ciclo con las condiciones adicionales dadas
por B, entonces P se mantendr invariante para cualquier nmero de
repeticiones del ciclo y se cumplir al final junto con la condicin de
terminacin del ciclo.
A estas frmulas P se les llama invariantes del ciclo. La aplicacin de la
regla exige que se determine un invariante P conveniente para la
correccin que se quiera deducir.

Regla para la composicin:

` {P}{R}; ` {R}{Q}
` {P}; {Q}

CONCLUSIONES

Los mtodos formales permiten que un ingeniero de software

especifique, desarrolle y verifique un sistema basado en computadora
aplicando una notacin rigorosa y matemtica; utilizando est
mtodo descubre y corrige ambigedades, inconsistencias y errores.

Tenemos que tomar en cuenta que los mtodos formales estn

presentes en bastantes campos y no solo los referidos a la ingeniera
y la informtica, los mtodos formales tienen un amplio recorrido y
su utilidad y eficiencia en desarrollo crticos estn demostradas. Sus
herramientas proporcionan el soporte automatizado necesario para la
integridad, trazabilidad, verificabilidad, reutilizacin y para apoyar la
evolucin de los requisitos, los puntos de vista diversos y la gestin
de
las
inconsistencias.
Los mtodos formales pueden ser aplicados en las empresas para
mejorar sus procedimientos y productos.

La decisin de utilizar mtodos formales debe considerar los costes

de arranque, as como los cambios puntuales asociados a una
tecnologa radicalmente distinta. En la mayora de los casos, los
mtodos formales ofrecen los mayores beneficios para los sistemas
de seguridad y para los sistemas crticos para los negocios.

Lo que se ha pretendido plantear en este trabajo es cmo nos

enfrentamos al reto de determinar si el software que construimos
realmente har lo que esperamos de l. Para ello hemos partido del
entorno acadmico (donde lo que prima es la formalidad y la teora) y
hemos llegado hasta el entorno industrial guiado principalmente por
metodologas de desarrollo bien definidas.

BIBLIOGRAFIA