Manejo de eventos anormales para sistemas … · 3 Mecanismo de Excepciones Ventajas: Separan el código de manejo de errores de código normal; Mejora la fiabilidad de sistema de

1

Manejo de eventos anormales para sistemas embebidos confiables

Guillermo RimoldiSonnet José PabloMuro Gustavo

2

Manejo Eventos Anormales

Tradicionalmente se utilizaban mecanismos de retorno de código de error, Los inconvenientes de este método trajo como consecuencia la introducción de mecanismos excepciones.

3

Mecanismo de Excepciones

Ventajas:Separan el código de manejo de errores de código normal;Mejora la fiabilidad de sistema de software.

Desventajas:La semántica y la sintaxis de las construcciones de excepciones actuales dejan espacio para su uso indebido;Aumento excesivo de código, aumentando asi la complejidad y costos del sistema sin contribuir significativamente a la exactitud y fiabilidad.

4

Propuesta

Un marco conceptual general para el manejo de todos los tipos de errores, que integra:

Excepciones de seguridad;Diseño por contrato;Tolerancia a fallos

Conjunto de criterios para el diseño y el uso de mecanismos de control.Diseño de un mecanismo de excepciones basado en los criterios anteriores, con un semántica y una sintaxis que evita malos usos.

5

Dificultades del Manejo de Eventos Anormales

Inconvenientes de la arquitectura jerárquica Devolución de valor de estado o de error;Utilización de los mecanismos de control de excepciones;Dificultados asociadas a los sistemas embebidos;

6

Los inconvenientes de la estructura jerárquica

Por lo general, el software esta estructurado en capas o niveles, estos implementan un nivel de abstracción que dificulta el manejo de eventos anormales, ya que estos son detectados en los niveles inferiores y no es posible llevar a cabo el adecuado procedimiento de recuperación;La solución al inconveniente citado es permitir la comunicación entre las capas o niveles de manera q los errores se propaguen hasta los niveles superiores donde puedan ser tratados correctamente.

7

Devolviendo valor de estado o de error

En C tradicionalmente para llevar a cabo el manejo de eventos anormales se devuelve un valor de estado o de error en cada funciónEste valor de estado o de error se verifica en cada nivel y:

Continua el procedimiento normal;Se trata ;Procedimiento de propagación de errores;

Un problema del método, es cuando se detectan errores en los niveles ubicados en la mitad de la jerarquía, estos rara vez pueden ser tratados y deben ser propagados. Estos errores se generan enniveles inferiores y no están relacionados con la lógica actual por lo que no pueden ser tratados . Estos errores se denominan tramperrors.

8

Mecanismos de Control de Excepciones

Como solución al problema anterior se desarrollaron mecanismos de control deexcepciones. Lenguajes como Ada, Eiffel, C++, Java y C# proporcionan apoyo para estas estructuras.Las excepciones son superiores a la devolución de valor de estado o de error ya que:

Proporcionan una clara separación del código de control de error del código normal;No requieren verificación y propagación del valor de estado o de error;El programa no las puede evitar;Menor complejidad;Más facil de leer;Más eficiente;Menos errores.

El uso excesivo de estas conduce a programas plagados de bloques try-catch que:Manejan las situaciones mas normales;Convierten las excepciones entre los niveles de abstracción mientras se están propagando;Incluso detectándolas se ignora su tratamiento (para evitar errores de compilador).

9

Dificultades Asociadas a Sistemas Embebidos

Soporte para programas en C: la falta de un manejo estructurado de excepciones en C es un inconveniente para la creación de sistemas fiables, por lo tanto la incorporación de un sistema bien diseñado de excepciones permite un adecuado equilibrio entre la eficiencia, portabilidad y fiabilidad.Compatibilidad y soporte de sistemas heredados: el sistema de manejo de eventos anormales debe permitir,

Máxima portabilidad;Máxima compatibilidad (reutilización).

10


Soporte para tolerancia a fallas: teniendo en cuenta los requerimientos de confiabilidad de los SE, el mecanismo de excepciones debe proporcionar un apoyo adecuado a la tolerancia a fallos:

Redundancia mínima y diversidad de software: debido a las restricciones de costos la redundancia de hardware no es una opción posible. Por lo tanto el software debe hacerse cargo de la tolerancia a fallos. Contención del daño: después que se detecta un error se debe verificar en que medida a sido afectado el sistema. En los SE no se puede garantizar q el daño se ha limitado a ciertas áreas. Recuperación de errores: se encarga de llevar el sistema de un estado erróneo a un estado coherente.

Hacia delante (forward) : continuación desde el estado erróneo con correcciones selectivas,Hacia atrás (backward): Se basa en restaurar el sistema a un estado seguro previo a la aparición del error y ejecutar una secuencia alternativa. Su principal inconveniente es salvar el estado del sistema, este estado se llama punto de recuperación (checkpoint).

11

Manejo Eventos Anormales

Tradicionalmente se utilizaban mecanismos de retorno de código de error, Los inconvenientes de este método trajo como consecuencia la introducción de mecanismos excepciones.

12

Mecanismo de Excepciones

Ventajas:Separan el código de manejo de errores de código normal;Mejora la fiabilidad de sistema de software.

Desventajas:La semántica y la sintaxis de las construcciones de excepciones actuales dejan espacio para su uso indebido;Aumento excesivo de código, aumentando asi la complejidad y costos del sistema sin contribuir significativamente a la exactitud y fiabilidad.

13

Propuesta

Un marco conceptual general para el manejo de todos los tipos de errores, que integra:

Excepciones de seguridad;Diseño por contrato;Tolerancia a fallos

Conjunto de criterios para el diseño y el uso de mecanismos de control.Diseño de un mecanismo de excepciones basado en los criterios anteriores, con un semántica y una sintaxis que evita malos usos.

14

Dificultades del Manejo de Eventos Anormales

Inconvenientes de la arquitectura jerárquica Devolución de valor de estado o de error;Utilización de los mecanismos de control de excepciones;Dificultados asociadas a los sistemas embebidos;

15

Los inconvenientes de la estructura jerárquica

Por lo general, el software esta estructurado en capas o niveles, estos implementan un nivel de abstracción que dificulta el manejo de eventos anormales, ya que estos son detectados en los niveles inferiores y no es posible llevar a cabo el adecuado procedimiento de recuperación;La solución al inconveniente citado es permitir la comunicación entre las capas o niveles de manera q los errores se propaguen hasta los niveles superiores donde puedan ser tratados correctamente.

16

Devolviendo valor de estado o de error

En C tradicionalmente para llevar a cabo el manejo de eventos anormales se devuelve un valor de estado o de error en cada funciónEste valor de estado o de error se verifica en cada nivel y:

Continua el procedimiento normal;Se trata ;Procedimiento de propagación de errores;

Un problema del método, es cuando se detectan errores en los niveles ubicados en la mitad de la jerarquía, estos rara vez pueden ser tratados y deben ser propagados. Estos errores se generan enniveles inferiores y no están relacionados con la lógica actual por lo que no pueden ser tratados . Estos errores se denominan tramperrors.

17

Mecanismos de Control de Excepciones

Como solución al problema anterior se desarrollaron mecanismos de control deexcepciones. Lenguajes como Ada, Eiffel, C++, Java y C# proporcionan apoyo para estas estructuras.Las excepciones son superiores a la devolución de valor de estado o de error ya que:

Proporcionan una clara separación del código de control de error del código normal;No requieren verificación y propagación del valor de estado o de error;El programa no las puede evitar;Menor complejidad;Más facil de leer;Más eficiente;Menos errores.

El uso excesivo de estas conduce a programas plagados de bloques try-catch que:Manejan las situaciones mas normales;Convierten las excepciones entre los niveles de abstracción mientras se están propagando;Incluso detectándolas se ignora su tratamiento (para evitar errores de compilador).

18


Soporte para programas en C: la falta de un manejo estructurado de excepciones en C es un inconveniente para la creación de sistemas fiables, por lo tanto la incorporación de un sistema bien diseñado de excepciones permite un adecuado equilibrio entre la eficiencia, portabilidad y fiabilidad.Compatibilidad y soporte de sistemas heredados: el sistema de manejo de eventos anormales debe permitir,

Máxima portabilidad;Máxima compatibilidad (reutilización).

19


Soporte para tolerancia a fallas: teniendo en cuenta los requerimientos de confiabilidad de los SE, el mecanismo de excepciones debe proporcionar un apoyo adecuado a la tolerancia a fallos:

Redundancia mínima y diversidad de software: debido a las restricciones de costos la redundancia de hardware no es una opción posible. Por lo tanto el software debe hacerse cargo de la tolerancia a fallos. Contención del daño: después que se detecta un error se debe verificar en que medida a sido afectado el sistema. En los SE no se puede garantizar q el daño se ha limitado a ciertas áreas. Recuperación de errores: se encarga de llevar el sistema de un estado erróneo a un estado coherente.

Hacia delante (forward) : continuación desde el estado erróneo con correcciones selectivas,Hacia atrás (backward): Se basa en restaurar el sistema a un estado seguro previo a la aparición del error y ejecutar una secuencia alternativa. Su principal inconveniente es salvar el estado del sistema, este estado se llama punto de recuperación (checkpoint).

20

Criterios para el manejo de eventos anormales

Separación de responsabilidadesDefinición: un sistema de software es un conjunto de

elementos de software que interactúan sobre la base de una especificación de obligaciones mutuas (Teoría de Contrato).

¿Qué es un elemento de software?Un objetoUn componenteUna sección de códigoUna función

21


Según la Teoría de Contrato, hay un contrato entre un elemento “proveedor” (se invocan sus métodos y funciones) y un elemento “cliente” (el que invoca).

¿Por qué está compuesto este contrato?Al contrato lo componen las precondiciones (garantizadas por el elemento cliente

antes de que se ejecute la rutina del proveedor), las postcondiciones (garantizadas por el elemento proveedor después de que se ejecuta su rutina) y por

último las invariantes o condiciones (que caracterizan la consistencia y las propiedades de integridad de todo el elemento).

22


¿Qué significa relyer?Es el elemento de software que asume que una condición (pre, post o invariantes) es verdadera.

¿Qué significa ensurer?Es el elemento de software responsable de garantizar

una condición (pre, post o invariantes).

Un código ensurer ha cumplido la condición si transfiere el control a un código relyer, cuando la condición que los

relaciona es verdadera.

23


24


Semántica de error y alineación de construcciones.

¿Qué se define por evento anormal?

Son aquellos que pueden surgir en la ejecución de una operación y que están relacionados con ella. Para su tratamiento requieren un cambio inmediato del curso

normal de ejecución.

25


Tipos de eventos anormales (Error de software y error de aplicación)

Error de software: estado inválido al que el sistema llega debido a la presencia de bugs. Se pueden manifestar de manera intermitente y transitoria o existen aquellos que surgen en forma segura bajo un juego de condiciones conocidas.

26


Error de aplicación: estado inválido al que el sistema llega debido a circunstancias que surgen de forma justificable e inevitable durante su ejecución. Pueden ser incidentes (cuando son predecibles y enumerables), o emergencias (cuando son situaciones poco comunes y poco frecuentes que, aunque pueden ser previsibles, no coinciden con el nivel de abstracción actual. ERROR TRAMP).

Se deben proveer mecanismos eficientes para el tratamiento de cada uno de estos tipos de errores.

27

Criterios para el manejo de eventos anormalesCRITERIO 1:

SOPORTE PARA MÚLTIPLES MECANISMOS DE MANEJO DE ERRORES.

Manejo de incidentes: la forma más efectiva para reportarlos es el retorno de códigos de error, ya que el código que invoca puede tratarlos eficientemente utilizando las instrucciones convencionales del lenguaje.

28



Manejo de emergencias: La forma más efectiva de reportarlos y propagarlos es utilizando el mecanismo de excepción. Debido a que este mecanismo está especialmente diseñado para atravesar la pila de llamadas hasta alcanzar la capa donde el error pueda ser tratado.

29



Manejo de errores de software: el método más eficiente es el de afirmaciones ejecutables (declaraciones comunes que se testean on-line para saber si son o no ciertas, si no lo son ha ocurrido un error). El no cumplimiento de las mismas debe invocar un manejador o handler global para que este registre suficiente información para reparar el problema y realizar un reset o un a prueba de fallos.

30


ÚNICO PUNTO DE CORRECCIÓN O REDUNDANCIA MÍNIMA DE CÓDIGO.

Evita tener dos secciones de código que confían y aseguran las mismas condiciones.

31


Caracterización de eventos anormales.

Debe ser realizada en las primeras etapas del diseño.Permite determinar correctamente las responsabilidades en el manejo de errores de todos los componentes del sistema.Es responsabilidad del código relyer el detectar y reportar errores de software, asícomo es responsabilidad del ensurer detectar y reportar errores de aplicación.La clasificación de un evento concreto es dependiente de la aplicación. Ejemplo: en una aplicación la imposibilidad de asignar un recurso puede ser considerado como una emergencia, mientras que en otras, este hecho se considera como un error de software. También depende del nivel de abstracción.

32


CONVERSIÓN ENTRE LOS DISTINTOS TIPOS DE ERROR.

El mecanismo para el manejo de eventos anormales debe soportar la conversión entre

los diferentes tipos de error.

33


Entendiendo la exactitud de la excepción.

Para especificar el comportamiento del software en presencia de una excepción se adoptan las siguientes garantías:

Garantía básica: No hay fuga de recursos. Los elementos de software quedan en un estado consistente aunque no predecible. La imposibilidad de ofrecer

siquiera este tipo de garantía es considerada un error de software. Garantía fuerte: el estado del programa permanece sin cambios. Es la única

que depende de los requerimientos de la aplicación. Sin falla: la operación nunca suscita una excepción. En algunas aplicaciones

es un requisito obligatorio. Sin este requerimiento otras operaciones no pueden siquiera proveer una garantía básica.

34


SEPARACIÓN DE PREOCUPACIONES PARA EXACTITUD DE EXCEPCIONES.

El mecanismo de excepción debe proveer soporte explícito para el logro de garantía básica.

CRITERIO 5: GARANTÍA PARA EXACTITUD DE EXCEPCIÓN.

Los códigos a cargo de las invariantes locales o globales deben ofrecer garantía sin falla. Si esta condición no es

alcanzada estamos en presencia de un error de software.

35


Descomposición de manejo de excepciones.

El mecanismo de excepción debe proveer un soporte adecuado para un esquema de tolerancia a fallas.

36


¿Cuál es la diferencia entre recuperación de error y tratamiento de error?

La recuperación de error devuelve al sistema a un estado consistente mientras que el tratamiento de error está a cargo de satisfacer, lo mejor posible, el servicio peticionado para que el sistema pueda continuar su operación.

37


SEPARACION DE PREOCUPACIONES PARA EL MANEJO DE ERRORES.

La recuperación de error debe estar apartada del tratamiento de error. Las estructuras de los mecanismos de excepción deben ser responsables únicamente de la lógica de recuperación, transfiriendo el control al código normal para su tratamiento.La separación de preocupaciones es importante por dos motivos. El primero es que permite la aplicación del criterio de único punto de corrección (ubicando el código de recuperación para todas las excepciones en un solo lugar) y el segundo es que la correcta separación de preocupaciones es entre el código de recuperación de error y el código de tratamiento de error.

38

Mecanismo para el manejo de excepciones

39


Consiste en la construcción de los siguientes bloques:

_TRY_UNLESS_FINALLY

La función _RAISE() permite señalar la excepción mediante un código de falla y los parámetros de falla

40


int myCode(){

_TRY { /* Bloque de códicgo protegido*/Código donde puede ocurrir el error:- se da una excepción[_RAISE(code,parameter)]- abandonar código protegido [_LEAVE(code)]- verificar código de reintento [_RETRYCODE]

}_UNLESS { /* Bloque de recuperación de error */

Recuperación de error, se debe hacer:- identificar el código de excepción [_EXCEPTION]- obtener el parámetro de excepción [_EXCEPARAM]- reintentar el código protegido [_RETRY(code)]- abortar operación [_ABORT(code)]- traducir la excepción [_XTRANS(code)]- propagar la excepción [default option]

}_FINALLY { /* Finalización del bloque de código */

Se ejecuta si hay o no excepción.}_END

return;/* retorna del bloque protegido con el código de salida */}

41

Que hacer en el bloque _UNLESS

Se puede consultar la variable _EXCEPTIONSi decide no hacer nada se propaga al bloque exterior

Volver a intentar el bloque protegido (_RETRY )Abortar la propagación con una indicación de estado (_ABORT)Traducir el código de excepción(_XTRANS)

42

Contraste con otros trabajos

En C++, Java y C# que el bloque catchproporciona tratamiento para el error y no lo propaga. _UNLESS nunca debe tratar el error.El bloque catch no discierne entre el código de recuperación y el código de tratamiento de error. _UNLESS sólo tiene la responsabilidad del tratamiento de errores y no de la recuperación.

43

Contraste con otros trabajos

Ante la existencia de múltiples catch, sólo la primera que la maneja se ejecuta. En contraste solo hay un _UNLESS .Los bloques catch y finally no están obligados a ofrecer garantía de no fallar. Cualquier intento de propagar una excepción fuera de ellas, se considera un fallo de software capturado por las aserciones ejecutables.

44

El lenguaje Eiffel

Las excepciones en Eiffel se basan en el principio del diseño por contrato. Sin embargo, nuestro mecanismo sigue un enfoque diferente. En el lenguaje Eiffel las excepciones indican errores de software (una violación en una condición de prueba). En nuestro esquema estos errores no son indicados por las excepciones, sino mediante la invocación de un handler de aserción ejecutable. Las excepciones del lenguaje Eiffel se plantean de manera implícita por el soporte del sistema en tiempo de ejecución. En nuestro caso, se trata de una responsabilidad explícita del código ensurer utilizando _RAISE (). El código para la recuperación de Eiffel sólo puede hacer la transferencia explícita al principio del código protegido (la restauración de los invariantes y la condición previa) por lo tanto no presta el soporte necesario para la recuperación de errores hacia adelante. Por otra parte, nuestro mecanismo proporciona soporte explícito a la recuperación de errores hacia adelante y hacia atrás. La sentencia rescue sólo ofrece un soporte explícito a la preservación de los invariantes locales en presencia de excepciones. Por el contrario, nuestro mecanismo ofrece un soporte explícito a la preservación de los invariantes locales y globales.

45

Conclusiones

Se propuso una estrategia para integrar los códigos de error, las excepciones y las aserciones ejecutables.Se introdujo un marco de trabajo que integra:

Diseño por ContratoExcepción seguraTolerancia a fallos

46

Conclusiones

Se introdujeron criterios de ingeniería que permitieron:

Determinar las condiciones del contratoClasificación y transformación de todos los tipos de error.

Estos criterios se aplicaron en el contexto de la aplicación y el nivel de abstracción

47

Conclusiones

Los mecanismos de aserción ejecutable son responsables de proveer detección de error y así lograr un software tolerante a fallos.El mecanismo de excepción es responsable de:

Proporcionar recuperación de error.Las construcciones normales del soft (if, while, etc) son responsables del tratamiento del error.

48

Conclusiones

Clara asignación de responsabilidadesMenos código para gestión de eventos anormalesPromueve una disciplina para el diseño

49

Muhas gracias

Preguntas…

Documents

Manejo de eventos anormales para sistemas … · 3 Mecanismo de Excepciones Ventajas: Separan el código de manejo de errores de código normal; Mejora la fiabilidad de sistema de