Ternas de Hoare INTEGRANTES: PAULO CÉSAR VALDEZ AGUILAR ERICK DANIEL QUISPE HUARI ROBERTO KENJI UEDA RODRIGUEZ UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS| FACULTAD DE INGENIERIA DE SISTEMAS
DEDICATORIA
INDICE
INTRODUCCIÓN
La verificación formal de un algoritmo consiste en un conjunto de técnicas de comprobación que permiten demostrar que un programa puede funcionar correctamente o no. La verificación consiste en todo un proceso de inferencia en el cual cada representación formal posee una regla de correspondencia y esta representación formal se da a través de la terna de Hoare.
LOGICA DE HOARE Es una extensión de la lógica de predicados de primer orden para razonar sobre la corrección de programas imperativos construidos sobre una signatura (S, Σ). Esta extensión se obtiene introduciendo un lenguaje de comandos con el que se construyen los programas y una relación especial para expresar el comportamiento de un programa, asi como un conjunto de reglas de cálculo para la manipulación de las expresiones de comportamiento. Basada en la idea de diagrama de flujo anotado.
• S es una “frase” de código en un programa de alto nivel, con una única entrada y una única salida normal. ◦ Instrucción. ◦ Bloque de instrucciones consecutivas. ◦ Un programa o subprograma.
• Cada frase S denota una relación 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 instrucción 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, fórmulas de la Lógica de Primer Orden (Lógica de Predicados). ◦ P ≡ Precondición (se refiere al estado previo a S) ◦ Q ≡ Postcondición (se refiere al estado posterior a S)
•
Notación: {P}S{Q}
REPRESENTACIÓN FORMAL: TERNAS DE HOARE Si C es una parte del código, entonces cualquier aserción {P} se denomina precondición de C si {P} sólo implica al estado inicial. Cualquier aserción {Q} se denomina postcondición si {Q} sólo implica el estado final. Esta definición 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 precondición: { } a:=b {a=b} Esto significa que siempre se obtienen estados que satisfacen la postcondición independientemente de la precondición. { } Representa la aserción vacía 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 cuestión. Ejemplo: Programa que calcula la raíz cuadrada • Precondición: Que el argumento de la función no sea negativo • Postcondición: La raíz cuadrada de ese argumento. NOMENCLATURA: En la mayoría de los códigos el estado final depende del estado inicial esto sucede también en el caso de la precondición y postcondición estas no son independientes entre sí. Existen dos posibles nomenclaturas que permiten dependencia entre precondición y postcondición:
reflejar
dicha
REPRESENTACIÓN DEL SUBÍNDICE: mediante subíndices se indica si las variables representan valores iniciales o finales. {a ω=b α} ∧ {b ω=a α} donde ‘ ω’ representa el estado final y ‘ α’ el estado inicial.
REPRESENTACIÓN DE LAS VARIABLES OCULTAS: Las variables ocultas son variables que aparecen o no en el código y que se introducen
para almacenar los valores iniciales de ciertas posiciones de memoria. Su definición debe aparecer en la precondición. {a=A,b=B} h:=a; a:=b; b:=h {a=B, b=A}
CONCEPTO DE CORRECCIÓN En este concepto se debe de distinguir dos clases de corrección: Si {P}C{Q} es un código con la precondición {P} y la postcondición {Q}, entonces {P}C{Q} es correcto si cada estado inicial posible que satisfaga {P} da como resultado un estado final que satisface {Q}.
CORRECCIÓN 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, además el segundo argumento de un comando de asignación puede ser cualquier expresión del correspondiente tipo s construida con constantes y funciones implementadas, y el primer argumento de un comando de selección o de iteración puede ser cualquier expresión del tipo BOOL. En nuestros programas, aunque no vamos a considerar declaraciones de tipo ni de variables, supondremos que existe una declaración de signatura donde aparecen los tipos y las constantes y funciones necesarias con propiedades conocidas, así como una asignación 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 corrección del siguiente algoritmo respecto de su especificación: P ≡ {x > 1} x←x+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
CORRECCIÓN TOTAL:
Se da cuando un código además de ser correcto parcialmente termina. Como hemos visto, la validez de una sentencia de corrección 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 precondición. Esta indefinición, a nivel teórico, sólo puede deberse a la aparición de ciclos tales que la aplicación reiterada del transformador asociado al cuerpo del ciclo a estados en los que es válida la condición de control nunca alcanza un estado en el que no se cumpla dicha condición. En estos casos se dice que el programa no termina. El lenguaje de la lógica de Hoare se podría ampliar con fórmulas de corrección total de la forma [P]α[Q] cuya validez en una interpretación A, para un estado esta, se puede establecer de la forma siguiente: A |=sta [P]α[Q], si y sólo si A |=sta P implica sta[α]Asta0 y A | =sta0 Q Y su validez en A se cumplira cuando sea válida para todos los estados definibles sobre A; lo que significa que la validez de una fórmula [P]α[Q] implica la terminación del programa α cuando parte de un estado caracterizado por P y la validez de Q en el estado que se alcanza. Sin embargo, el cálculo de Hoare no se amplia para tratar sentencias de corrección total, sino que la corrección parcial y la terminación se suelen tratar por separado. Aunque el lenguaje de sentencias de Hoare no contempla la posibilidad de expresar la terminación normal de programas, en muchos casos se puede recurrir a un método parcialmente informal derivado del siguiente razonamiento: La posibilidad de no terminación de un programa se debe normalmente a la aparición de ciclos y para que pueda terminar un ciclo es necesario que su cuerpo produzca algún tipo de evolución o progreso de los estados hacia situaciones en las que no se cumpla la condición de control. Esta idea la podemos concretar expresando la evolución del ciclo mediante una función de progreso f, con valor entero, tal que deba ser no negativa para que se ejecute el ciclo y disminuya estrictamente después de cada repetición; como el decrecimiento de la función en estas condiciones no puede ser perpetuo, resulta obvio al menos intuitivamente que el ciclo deberá terminar. Los códigos sin bucles siempre terminan por lo que la corrección parcial implica la corrección total. Esta distinción es esencial sólo en el caso de códigos que incluyan bucles o recursiones.
CALCULO DE HOARE Este cálculo se utiliza para la corrección de programas de manera parcial, se recurre a la ampliación del cálculo para la deducción natural apto para tratar sólo con fórmulas del cálculo de predicados de primer orden incorporando un conjunto de reglas para la deducción de la validez de fórmulas de corrección parcial conocido como cálculo de Hoare. Este cálculo consta de una regla general independiente de la estructura del programa que aparece en la fórmula de corrección, que refleja el significado de las fórmulas de corrección 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 programación, por lo que constituyen una autentica semántica para dicho lenguaje conocida como semántica axiomática. La regla independiente es:
Regla de refinamiento: ` P ⇒ P 0 ; ` {P 0}α{Q0}; ` Q0 ⇒ Q ` {P}α{Q}
Esta regla refleja realmente la semántica de las fórmulas de corrección parcial (véase el ejercicio 2.4) y nos viene a decir que siempre se puede reforzar la precondición y/o debilitar la postcondición de una fórmula de corrección válida.
REGLAS RELATIVAS POSTCONDICIONES
A
LAS
PRECONDICIONES
Y
Si R y S son dos aserciones entonces se dice que R es más fuerte que S si R ⇒S. Si R es más fuerte que S entonces se dice que S es más débil que R. Ejemplo: i>1 es más fuerte que i>0 ya que siempre que i>1 esto implica que i>0. Por tanto i>1 ⇒i>0. Si una aserción R es más fuerte que una aserción S entonces todos los estados que satisfacen R también satisfacen S pero no viceversa. Un
fortalecimiento de la aserción disminuye el número de estados que la pueden satisfacer.
Más fuerte ⇒ más selectivo, más específico. Más débil ⇒ menos selectivo, más general.
La aserción más débil es { } que recoge todos los estados posibles. Constante lógica V (true). La aserción más fuerte será por tanto F (false), ya que representa que ningún estado satisface dicha condición.
ESPECIFICACIÓ Y VERIFICACIÓN DE PROGRAMAS •
Axioma para el programa vacío: ` {P}SKIP{P} Este axioma refleja la transformador identidad.
•
semántica
del
programa
vacío
como
Axioma para la asignación:
` {P{X/t}}X := t{P} Cuando la sustitución P{X/t} sea admisible y el cálculo de la expresión t termine. Este axioma refleja el hecho de que después de ejecutar un comando X := t, el valor de la variable X se iguala al valor de t, luego si se quiere que la fórmula P sea válida después de la asignación, antes debe ser válida la misma fórmula para t en lugar de X. •
Regla para la selección: ` {P ∧ B}β{Q}; ` {P ∧ ¬B}γ{Q} ` {P} IF B THEN β ELSEγ END {Q} Esta regla refleja la semántica del comando correspondiente y nos dice que para que una construcción con este comando sea correcta respecto a una especificación (P, Q), lo debe ser cada uno de los programas alternativos β y γ respecto a las especificaciones obtenidas reforzando la precondición con las condiciones necesarias para que se ejecuten dichos programas.
•
Regla para la repetición: ` {P ∧ B}β{P} ` {P}WHILE B DO β END {P ∧ ¬B}
Esta regla nos dice que si P es una fórmula 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 número de repeticiones del ciclo y se cumplirá al final junto con la condición de terminación del ciclo. A estas fórmulas P se les llama invariantes del ciclo. La aplicación de la regla exige que se determine un invariante P conveniente para la corrección que se quiera deducir. •
Regla para la composición: ` {P}α{R}; ` {R}β{Q} ` {P}α; β{Q}
CONCLUSIONES
Los métodos formales permiten que un ingeniero de software especifique, desarrolle y verifique un sistema basado en computadora aplicando una notación rigorosa y matemática; utilizando esté método descubre y corrige ambigüedades, inconsistencias y errores.
Tenemos que tomar en cuenta que los métodos formales están presentes en bastantes campos y no solo los referidos a la ingeniería y la informática, los métodos formales tienen un amplio recorrido y su utilidad y eficiencia en desarrollo críticos están demostradas. Sus herramientas proporcionan el soporte automatizado necesario para la integridad, trazabilidad, verificabilidad, reutilización y para apoyar la evolución de los requisitos, los puntos de vista diversos y la gestión de las inconsistencias. Los métodos formales pueden ser aplicados en las empresas para mejorar sus procedimientos y productos.
La decisión de utilizar métodos formales debe considerar los costes de arranque, así como los cambios puntuales asociados a una tecnología radicalmente distinta. En la mayoría de los casos, los métodos formales ofrecen los mayores beneficios para los sistemas de seguridad y para los sistemas críticos para los negocios.
Lo que se ha pretendido plantear en este trabajo es cómo nos enfrentamos al reto de determinar si el software que construimos realmente hará lo que esperamos de él. Para ello hemos partido del entorno académico (donde lo que prima es la formalidad y la teoría) y hemos llegado hasta el entorno industrial guiado principalmente por metodologías de desarrollo bien definidas.
BIBLIOGRAFIA
