Tratamiento de errores Informática III. Ing. José L. Simón/Ing. Nora BletPág. 2 Temario...

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


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


Blet Pág. 4

Definiciones

Fiabilidad

Fallo

Error

Defecto

Estado


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


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.


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.


Blet Pág. 8

Fallos encadenados

Fallo

Defecto

Error Fallo

Defecto


Blet Pág. 9

Tipos de Fallo

Transitorios

Permanentes

Intermitentes


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


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


Blet Pág. 12

Fallos Intermitentes

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


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


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


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


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


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


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


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


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


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


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


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)


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)


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)


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


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


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


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


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


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


Blet Pág. 32

Mecanismos de Manejo

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


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


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


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


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


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


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


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


Blet Pág. 40

Excepciones síncronas

Hay dos modelos para declararlas: Una constante Un objeto de un tipo particular


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.


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{

}


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.


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


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


Blet Pág. 46

Modelo de Terminación

P

QR

P invoca Q

Q invoca R

excepción

ManejadorPara R

Terminación


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.


Blet Pág. 48


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


Blet Pág. 49


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


Blet Pág. 50


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.

Tratamiento de errores Informática III. Ing. José L. Simón/Ing. Nora BletPág. 2 Temario...

Documents

Transcript of Tratamiento de errores Informática III. Ing. José L. Simón/Ing. Nora BletPág. 2 Temario...