Tratamiento de errores

Presentación del tema: "Tratamiento de errores"— Transcripción de la presentación:

1 Tratamiento de errores
Informática III

2 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

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

4 Definiciones Fiabilidad Fallo Error Defecto Estado

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.”

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.

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.

8 Fallos encadenados Fallo Defecto Error Fallo Defecto

9 Tipos de Fallo Transitorios Permanentes Intermitentes

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

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

12 Fallos Intermitentes Son fallos transitorios que “reaparecen” con frecuencia. Ejemplo: un componente de hardware sensible al calentamiento

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

14 Clasificación de 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

15 Mejoras en la Fiabilidad
Hay dos técnicas que permiten diseñar software fiable: Prevención de Fallos Tolerancia a Fallos

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

17 Evitación de Fallos Se intenta acotar la introducción de componentes (hardware y software ) potencialmente defectuosos durante la construcción del sistema

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

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

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

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

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

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)

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)

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)

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

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

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

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

30 Manejador de Excepciones
Modelo Excepción de Interfaz Excepción de Fallo Petición De Servicio Respuesta Normal Vuelta al Servicio normal Actividad Normal Manejador de Excepciones Petición De Servicio Respuesta Normal Excepción Interna Excepción de Interfaz Excepción de Fallo

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

32 Mecanismos de Manejo Retorno de un valor inusual (C)
Bifurcación forzada (Assembler) goto no local Excepciones (C++, Java)

33 Retorno de Valor Inusual
if( fopen(“archiv.dat”, “r”) != 0 ){ /* código de manejo de error */ } else { /* código normal */ };  R1  R2  R3  R  R5

34 Bifurcación Forzada jsr pc, IMPRIME_SIMB jmp ERROR_ES
jmp DISPOSITIVO_NO_PREPARADO # Procesamiento normal  R1  R2  R3  R  R5

35 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

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 programa Mínima sobrecarga Soporte de múltiples manejadores de excepciones

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

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

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

40 Excepciones síncronas
Hay dos modelos para declararlas: Una constante Un objeto de un tipo particular

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.

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{

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 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.

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 escape En un modelo híbrido el manejador puede decidir qué hacer

45 Modelo de Reanudación P Hq Q Hr R 1.-P invoca Q 2.-Q invoca R
6.-Hr reanuda R 5.-Hq reanuda Hr P Hq Q Hr R 4.-Hr genera la excepción q 3.-R genera la excepción r

46 Modelo de Terminación P Q R Terminación excepción Manejador Para R
P invoca Q P Terminación Q invoca R Q R excepción Manejador Para R

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.

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

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

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.