norajose1.ppt

Tratamiento de errores
Informática III
Temario
Conceptos: fallas, errores y fiabilidad
Taxonomía de fallos: tipos y modos
Diseño de software fiable
Errores, aserciones y excepciones
Estrategias de manejo de fallos
Modelos de recuperación
Modelos de integración
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 2
Introducción
Los sistemas complejos involucran
actividades concurrentes e
interactuantes que pueden dar lugar a
condiciones “excepcionales”
Del correcto tratamiento de estas
condiciones depende el grado de
confiabilidad del software
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 3
Definiciones
Fiabilidad
Fallo
Error
Defecto
Estado
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 4
Fiabilidad (Reliability)
Randell la define como:
“... Una medida del éxito con que el
sistema se ajusta a alguna
especificación definitiva de su
comportamiento.”
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 5
Fallo (Failure)
Estamos en presencia de un fallo
cuando el comportamiento de un
sistema se desvía del especificado.
Un sistema altamente fiable presenta
una baja tasa de fallos.
Fiabilidad y fallos están relacionados al
comportamiento del sistema, es decir
con su aspecto externo.
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 6
Defectos (Faults) y Errores
(Errors)
Los fallos son el resultado de problemas
internos inesperados que el sistema
manifiesta eventualmente en su
comportamiento externo
Estos problemas se denominan errores, y sus
causas defectos
Un componente defectuoso de un sistema,
producirá un error bajo un conjunto concreto
de circunstancias durante la vida del sistema.
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 7
Fallos encadenados
Fallo
Informática III
Defecto
Error
Fallo
Ing. José L. Simón/Ing. Nora Blet
Defecto
Pág. 8
Tipos de Fallo
Transitorios
Permanentes
Intermitentes
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 9
Fallos Transitorios
Un fallo transitorio comienza en un
instante concreto, se mantiene durante
un período y luego desaparece solo
Ejemplo: fallos de hardware por
interferencia electromagnética o térmica
Frecuentes en los sistemas de
comunicación
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 10
Fallos Permanentes
Aparecen en un instante determinado y
permanecen hasta que son reparados
Ejemplos: un cable cortado o un error
de diseño del software
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 11
Fallos Intermitentes
Son fallos transitorios que “reaparecen”
con frecuencia.
Ejemplo: un componente de hardware
sensible al calentamiento
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 12
Modos de Fallo
Los modos de fallo de un sistema se
clasifican según su impacto en los
servicios prestados por el sistema, en
dos dominios:


Fallos de valor
Fallos de tiempo
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 13
Clasificación de Modos de Fallo
Modos de Fallo
Dominio del Valor
Dominio del Tiempo
Arbitrario
(fallo no controlado)
Error
Valor
De Límites
Erróneo
Adelanto
Fallo silencioso
Informática III
Omisión
Fallo de Parada
Ing. José L. Simón/Ing. Nora Blet
Retraso
Fallo Controlado
Pág. 14
Mejoras en la Fiabilidad
Hay dos técnicas que permiten diseñar
software fiable:


Prevención de Fallos
Tolerancia a Fallos
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 15
Prevención de Fallos
Intenta impedir (acotar) la introducción
de fallos antes de que el sistema esté
operativo mediante:


Evitación
Eliminación
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 16
Evitación de Fallos
Se intenta acotar la introducción de
componentes (hardware y software )
potencialmente defectuosos durante la
construcción del sistema
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 17
Hardware
Utilización de componentes mas
confiables
Empleo de técnicas refinadas para la
interconexión y ensamblado de
subsistemas
Aislamiento de interferencias externas
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 18
Software
Especificaciones rigurosas/formales
Metodologías de diseño
Uso de herramientas con abstracción,
encapsulamiento y modularidad
Gestión de la complejidad
Gestión de la calidad del software y el
proceso de construcción
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 19
Eliminación de Fallos
Aunque se utilicen las técnicas de
evitación mencionadas, es imposible
obtener ausencia total de defectos
Las medidas de eliminación de fallos,
es decir, procedimientos para encontrar
y eliminar la causa de los errores, son
inevitables
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 20
Técnicas de Eliminación de
Fallos
Revisión de diseño
Verificación de programas
Inspección de código
Prueba (testing) del sistema
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 21
Prueba de sistemas
Los tests sólo pueden utilizarse para demostrar
la existencia de fallos, no su ausencia
Frecuentemente es imposible hacer pruebas
bajo condiciones reales
Los errores introducidos durante la captura de
requerimientos pueden no manifestarse hasta
que el sistema esté operativo
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 22
Tolerancia a Fallos
Por las limitaciones expuestas, el
diseño de sistemas críticos debe recurrir
a técnicas de tolerancia a fallos
Un sistema puede proveer tres niveles:



Tolerancia total de fallos (Fail operational)
Degradación controlada (Graceful
Degradation (fail soft))
Fallo seguro (Fail Safe)
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 23
Recuperación de Errores
Una vez detectada la situación de error
y valorado el impacto causado al
sistema se deben iniciar procesos de
recuperación de errores
Consiste en llevar al sistema desde un
estado erróneo a otro en el cual el s.
pueda continuar su operación normal
(probablemente degradada)
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 24
Recuperación: Estrategias
Hacia delante (forward) : continuación
desde el estado erróneo con
correcciones selectivas.
Hacia atrás (backward): restaurar un
estado seguro previo a la aparición del
error y ejecutar una secuencia
alternativa. El estado seguro se llama
punto de recuperación (checkpoint)
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 25
Recuperación
El uso de roll forward implica la
correcta valoración de daños causados
al entorno del sistema y la exacta
determinación de la causa del fallo
El roll back tiene la ventaja de hacer
innecesaria la determinación de la
causa del fallo, pero a veces es
imposible “deshacer” los efectos
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 26
Excepciones
Son ocurrencias concretas de un error
Cuando un componente detecta un
error debe señalarlo al invocador
lanzando una excepción
La respuesta del invocador se
denomina gestión (manejo, captura)
de la excepción
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 27
Excepciones
La gestión de excepciones se puede
considerar como un mecanismo de
recuperación hacia delante
Sin embargo, también se pueden
utilizar para proporcionar una
recuperación de errores hacia atrás
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 28
Excepciones
Las excepciones y su gestión pueden
utilizarse para:



Enfrentarse a condiciones anormales que
surgen en el entorno (propósito original)
Tolerar los defectos en el diseño del
programa
Proporcionar unas capacidades de
propósito general para la detección de
errores y la recuperación
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 29
Modelo
Excepción
de Interfaz
Petición Respuesta
De Servicio Normal
Vuelta al Servicio
normal
Actividad Normal
Excepción
de Fallo
Manejador de Excepciones
Excepción Interna
Petición
Respuesta
De Servicio
Normal
Informática III
Excepción
de Interfaz
Ing. José L. Simón/Ing. Nora Blet
Excepción
de Fallo
Pág. 30
Manejo de Excepciones
Los lenguajes de programación deben ofrecer
mecanismos para el manejo de excepciones:





R1 (simplicidad): Sencillo de comprender y utilizar
R2 (discreción): Que no afecte la claridad del código
ni su comprensión
R1 y R2 son cruciales en el diseño de sistemas fiables!
R3 (eficiencia): Introduce sobrecarga en la ejecución
sólo cuando se maneja una excepción
R4 (uniformidad): Provee tratamiento uniforme de
las excepciones del entorno y del programa
R5 (recuperación): Permite la programación de
acciones de recuperación
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 31
Mecanismos de Manejo
Retorno de un valor inusual (C)
Bifurcación forzada (Assembler)
goto no local
Excepciones (C++, Java)
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 32
Retorno de Valor Inusual
if( fopen(“archiv.dat”, “r”) != 0 ){
/* código de manejo de error */
} else {
/* código normal */
};
 R1
Informática III
 R2  R3
 R4
Ing. José L. Simón/Ing. Nora Blet
 R5
Pág. 33
Bifurcación Forzada
jsr pc, IMPRIME_SIMB
jmp ERROR_ES
jmp DISPOSITIVO_NO_PREPARADO
# Procesamiento normal
 R1
Informática III
 R2  R3  R4
Ing. José L. Simón/Ing. Nora Blet
 R5
Pág. 34
goto No Local
on error goto err_sub//versión de alto
nivel del anterior
...
Procedure Sub_1
 R1
...
 R2
Endproc
 R3
Procedure Sub_2
 R4
Endproc
 R5
Procedure err_sub
// tratamiento de errores
Endproc
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 35
Manejo de excepciones
moderno
Mecanismo estructurado para el tratamiento de las
excepciones
Provisto por el entorno de ejecución (runtime)
Soportado directamente por el lenguaje de
programación
Provee tratamiento uniforme de las excepciones del
entorno y del programa
Mínima sobrecarga
Soporte de múltiples manejadores de excepciones
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 36
Manejo de excepciones
moderno
Lenguajes que tienen incorporado el
manejo de excepciones:





C++
Java
Visual Basic
Delphi /Pearl/Eiffel/Ada…
Todos los lenguajes .NET
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 37
Excepciones y su
representación
Síncronas: respuesta a una operación
inapropiada de un fragmento de código
Asíncronas(notificación asíncrona o
señal): generadas tiempo después de la
operación que da lugar a la aparición del
error
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 38
Detección
Detectada por el runtime y generada
síncronamente: división por cero
Detectada por la aplicación y generada
síncronamente: falla en assert
Detectada por el runtime y generada
asíncronamente: falla de alimentación
Detectada por la aplicación y generada
asíncronamente: un proceso detecta una
condición que causará una falla
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 39
Excepciones síncronas
Hay dos modelos para declararlas:


Una constante
Un objeto de un tipo particular
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 40
Dominio de un Manejador de
Excepciones
Dentro de un programa puede haber varios
manejadores para una misma excepción
Cada manejador tiene asociado un dominio
La granularidad del dominio determinará
qué tan precisamente puede localizarse la
fuente de la excepción. No todos los
lenguajes permiten alcanzar un nivel de
granularidad adecuado.
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 41
Dominio de un Manejador de
Excepciones
Bloque Protegido {//bloque vigilado(guarded)
// sentencias que pueden generar una
excepción
}
Manejador para Excepcion Tipo e1{
}
Manejador para Excepcion Tipo en{
}
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 42
Propagación de una Excepción
Si un bloque o procedimiento no tiene un
manejador adecuado para una excepción
generada, esta se propaga hacia el invocador
Si ningún procedimiento en la cadena de
llamadas tiene un manejador adecuado, la
excepción es manejada por el runtime,
abortando el programa
Muchos lenguajes proveen un manejador de
tipo catch all. Posible solución en caso que
el lenguaje precisa declarar el alcance de
las excepciones.
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 43
Modelos de Tratamiento de
Excepciones
Siempre debemos determinar que conducta
tomará el programa ante la presencia de una
excepción
Si el manejador resuelve el problema y el
invocador puede continuar su ejecución,
puede aplicarse el modelo de reanudación (o
de notificación)
Si no se devuelve el control al invocador el
modelo se denomina de terminación o escape
En un modelo híbrido el manejador puede
decidir qué hacer
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 44
Modelo de Reanudación
2.-Q invoca R
1.-P invoca Q
6.-Hr reanuda R
5.-Hq reanuda Hr
Hq
P
Hr
4.-Hr genera la excepción q
Informática III
Q
R
3.-R genera la excepción r
Ing. José L. Simón/Ing. Nora Blet
Pág. 45
Modelo de Terminación
P
P invoca Q
Q
Q invoca R
R
Terminación
excepción
Manejador
Para R
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 46
Modelo ideal de manejo de
excepciones (Garcia et al., 2001)
Las excepciones deberían representarse
como objetos
Debería ser obligatorio declarar todas las
excepciones externas que puede lanzar un
método en sus signaturas
public void ReplaceAttr throws
NoEncontrado, ValorErroneo { ... }
Sin embargo, debería permitir también un
enfoque híbrido puesto que algunas
excepciones son impredecibles, por
naturaleza.
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 47
Modelo ideal de manejo de
excepciones (Garcia et al., 2001)
Debería permitir una clara separación
entre excepciones internas y externas;
estas últimas son las únicas que se les
permitiría propagarse.
Debería permitir asociar manejadores a
distintos niveles de la estructura del
sistema
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 48
Modelo ideal de manejo de
excepciones (Garcia et al., 2001)
Debería soportar un modelo híbrido de
enlace entre excepción y manejador
Debería permitir la propagación
explícita de excepciones a lo largo de la
cadena de invocaciones
Debería usar el modelo de terminación
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 49
Modelo ideal de manejo de
excepciones (Garcia et al., 2001)
Soporte explícito de mecanismos de
“limpieza” específicas de la aplicación
Permitir ensayar la confiabilidad
Proveer soporte adecuado para el
manejo de excepciones en
programación concurrente.
Informática III
Ing. José L. Simón/Ing. Nora Blet
Pág. 50