Tratamiento de errores - PowerPoint PPT Presentation

Loading...

PPT – Tratamiento de errores PowerPoint presentation | free to download - id: 788d30-YzZhM



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Tratamiento de errores

Description:

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 ... – PowerPoint PPT presentation

Number of Views:6
Avg rating:3.0/5.0
Slides: 51
Provided by: JosL76
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Tratamiento de errores


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
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 de Parada
Fallo silencioso
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
Modelo
Actividad Normal
Manejador de Excepciones
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 ? R4 ? R5
34
Bifurcación Forzada
jsr pc, IMPRIME_SIMB jmp ERROR_ES jmp
DISPOSITIVO_NO_PREPARADO Procesamiento normal ?
R1 ? R2 ? R3 ? R4 ? 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
46
Modelo de Terminación
P
Q
R
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.
About PowerShow.com