Date post: | 23-Jan-2016 |
Category: |
Documents |
Upload: | amaranta-lagos |
View: | 222 times |
Download: | 0 times |
Tratamiento de errores
Informática III
Informática IIIIng. José L. Simón/Ing. Nora
Blet Pág. 2
Temario
Conceptos: fallas, errores y fiabilidadTaxonomía de fallos: tipos y modosDiseño de software fiableErrores, aserciones y excepcionesEstrategias de manejo de fallosModelos de recuperaciónModelos de integración
Informática IIIIng. José L. Simón/Ing. Nora
Blet Pág. 3
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 4
Definiciones
Fiabilidad
Fallo
Error
Defecto
Estado
Informática IIIIng. José L. Simón/Ing. Nora
Blet Pág. 5
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 6
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 7
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 8
Fallos encadenados
Fallo
Defecto
Error Fallo
Defecto
Informática IIIIng. José L. Simón/Ing. Nora
Blet Pág. 9
Tipos de Fallo
Transitorios
Permanentes
Intermitentes
Informática IIIIng. José L. Simón/Ing. Nora
Blet Pág. 10
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 11
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 12
Fallos Intermitentes
Son fallos transitorios que “reaparecen” con frecuencia. Ejemplo: un componente de hardware sensible al calentamiento
Informática IIIIng. José L. Simón/Ing. Nora
Blet Pág. 13
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 14
Clasificación de Modos de Fallo
Modos de Fallo
Dominio del Valor Dominio del Tiempo Arbitrario
(fallo no controlado)
Error
De Límites
Valor
Erróneo
Adelanto Omisión Retraso
Fallo silencioso Fallo de Parada Fallo Controlado
Informática IIIIng. José L. Simón/Ing. Nora
Blet Pág. 15
Mejoras en la Fiabilidad
Hay dos técnicas que permiten diseñar software fiable: Prevención de Fallos Tolerancia a Fallos
Informática IIIIng. José L. Simón/Ing. Nora
Blet Pág. 16
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 17
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 18
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 19
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 20
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 21
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 22
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 23
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 24
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 25
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 26
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 27
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 28
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 29
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 30
Modelo
Actividad Normal Manejador de Excepciones
Vuelta al Servicionormal
Excepción Interna
PeticiónDe Servicio
PeticiónDe Servicio
RespuestaNormal
RespuestaNormal
Excepciónde Interfaz
Excepciónde Fallo
Excepciónde Fallo
Excepciónde Interfaz
Informática IIIIng. José L. Simón/Ing. Nora
Blet Pág. 31
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 32
Mecanismos de Manejo
Retorno de un valor inusual (C) Bifurcación forzada (Assembler) goto no local Excepciones (C++, Java)
Informática IIIIng. José L. Simón/Ing. Nora
Blet Pág. 33
Retorno de Valor Inusual
if( fopen(“archiv.dat”, “r”) != 0 ){
/* código de manejo de error */
} else {
/* código normal */
};
R1 R2 R3 R4 R5
Informática IIIIng. José L. Simón/Ing. Nora
Blet Pág. 34
Bifurcación Forzada
jsr pc, IMPRIME_SIMB
jmp ERROR_ES
jmp DISPOSITIVO_NO_PREPARADO
# Procesamiento normal
R1 R2 R3 R4 R5
Informática IIIIng. José L. Simón/Ing. Nora
Blet Pág. 35
goto No Localon 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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 36
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 programaMínima sobrecargaSoporte de múltiples manejadores de excepciones
Informática IIIIng. José L. Simón/Ing. Nora
Blet Pág. 37
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 38
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 39
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 40
Excepciones síncronas
Hay dos modelos para declararlas: Una constante Un objeto de un tipo particular
Informática IIIIng. José L. Simón/Ing. Nora
Blet Pág. 41
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 42
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 43
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 programaMuchos 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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 44
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 escapeEn un modelo híbrido el manejador puede decidir qué hacer
Informática IIIIng. José L. Simón/Ing. Nora
Blet Pág. 45
Modelo de Reanudación
PHq QHr R
1.-P invoca Q 2.-Q invoca R
5.-Hq reanuda Hr6.-Hr reanuda R
3.-R genera la excepción r4.-Hr genera la excepción q
Informática IIIIng. José L. Simón/Ing. Nora
Blet Pág. 46
Modelo de Terminación
P
QR
P invoca Q
Q invoca R
excepción
ManejadorPara R
Terminación
Informática IIIIng. José L. Simón/Ing. Nora
Blet Pág. 47
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 48
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 49
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 IIIIng. José L. Simón/Ing. Nora
Blet Pág. 50
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.