Structuring Exception Handling For Dependable Component-Based Software Systems



Descargar 131,17 Kb.
Fecha de conversión18.07.2017
Tamaño131,17 Kb.


Structuring Exception Handling For Dependable Component-Based Software Systems
Estructura de manejo de exepciones para un software Component-Based confiable

Autores: - Paulo Asterio de C. Guerra

- Fernando Castor Filho

- Vinicius Asta Pagano



- Cecília Mary F. Rubira


Introducción
El impulso para desarrollar este artículo fueron las dificultades con la que los programadores de sistemas de software hechos en base a componentes se encontraban, una y otra vez, al enfrentar grandes sistemas en donde se debían integrar partes de software. Estas eran hechas por programadores que al momento de escribirlas no sabían donde iban a ser implementadas, y por otra parte quienes debían unirlos no sabían como estaban conformados los componentes. La separación de tareas genera complicaciones extra a la hora de implementar el manejo de excepciones. Y además, no había un método general para el manejo de excepciones en sistemas de este tipo.
Al momento de realizar la implementación, es importante definir una manera de cómo y por quien van a ser tratado el manejo de excepciones entre los componentes y conectores, si esto no se resuelve puede derivar en dos situaciones indeseables: el contexto y la semántica de la excepción se pierden, haciendo imposible que otros componentes lo manejen; o la excepción será ignorada y propagara errores a lo largo del sistema.
Para estudiar la implementación de manejo de excepciones partieron de un modelo de componente, que ya había sido propuesto por T. Anderson y P. A. Lee, llamado IFTC (idealizad fault-tolerance component), este modelo es una clase, objeto, o incluso un sistema, que separa la actividad normal de la actividad anormal. Al recibir la petición de un servicio, se pueden dar tres casos: una respuesta normal, que implica el pedido haya sido procesado satisfactoriamente; una excepción de interfaz indicando que fue un pedido no valido; o un excepción de tipo error, es decir que fue un pedido valido pero no pudo ser procesado.

En base al modelo visto, se supone que un componente debería poder detectar cuando sucedan condiciones anormales ya previstas. Pero a la hora de realizar el desarrollo de la arquitectura el implementador deberá tener en cuenta aquellas situaciones que el componente podría no contemplar, para obtener un sistema mas robusto, por lo tanto estos casos quedan dependiendo de la forma en que los componentes sean organizados, lo que podría causar problemas en la arquitectura a la hora realizar la integración del sistema.



Para evitar los efectos que esta forma de trabajo puede causar, se propone una estrategia dividida en dos partes complementarias. Un manejo de excepciones entre componentes y otro a nivel interno de los componentes. Ambos comparten una jerarquía de excepciones para expresar la semántica de fallas de un componente o un conector.


Estrategia propuesta
Luego de analizar, diseñar el sistema y los modelos de fallos de componentes y arquitectura, se propone a tener en cuenta los siguientes pasos descriptos en la publicación:


  1. En caso de ser necesario, implementar la jerarquía de excepciones descripta a continuación,

La superclase de la jerarquía (tipo abstracta) de excepciones es Excepción, que se divide en ExcepcionDeclarada y ExcepcionNoDeclarada, esta ultima a su vez se divide en ExcepcionPedidoRechazado(el pedido no fue procesado por no ser no ser correcto, es decir no cumplio el contrato, pero el sistema aun es consistente) y ExcepcionFallo (el pedido no fue procesado porque el sistema fallo). Esta ultima clase se subdivide en ExcepcionFalloRecuperado (el componente quedo estable a pesar del fallo) y ExcepcionFalloNoRecuperado(el fallo dejo al componente en estado no consistente).




  1. Implementar el manejo de excepciones a nivel de componente (ALE handlers), que se ocupan principalmente de excepciones que son previstas a nivel interno de componentes y declaradas en las interfaces requeridas. La implementación de clases se encarga de: detectar las condiciones anormales previamente anticipadas y lanza una excepción declarada; hallar otras condiciones excepcionales especificas de la implementación del componente y lanza una excepción interna; ejecuta una “limpieza” al finalizar un bloque try-catch, en java existe el bloque finally.

La fachada es una interfaz entre el cliente que hace el pedido y otra interfaz. Se utiliza como intermediario para facilitar el acceso al servicio requerido.

Los ALE se encargan de manejar:


- excepciones lanzadas por un error en la interfaz

- excepciones producidas por la implementación interna del componente


- excepciones causadas por otros componentes
En el caso que sea posible, se corrige el error mas adelante.

También se ocupa de las excepciones producidas entre la fachada y la interfaz.

Las excepciones declaradas en el componente y las que sean ExcepcionPedidoRechazado se propagan directamente a quien haya solicitado el servicio. Para otras excepciones se puede retroceder en el proceso y si resulta exitoso se devuelve ExcepcionFalloRecuperado, o en caso contrario se lanza ExcepcionFalloNoRecuperado.

En el caso de que los ALEH no sean aplicables, ya que no se dispone del código fuente para modificar un componente, una poderosa herramienta son las envolturas que permiten transformarlos como son vistos externamente para el manejo de excepciones.




  1. Implementar el manejo de excepciones a nivel de arquitectura (CLE handlers), que se encargan de lidiar con todas las excepciones no declaradas, lanzadas por componentes preexistentes a la hora de implementarlos en un nuevo sistema.

Debido a que los desarrolladores no saben donde sus componentes van a ser usados, resulta que los conectores son el lugar mas indicado para situar a los CLE handlers. Estos se ocupan de la recuperación de errores y enmascararlos a nivel de arquitectura y de resolver las fallos por problemas semánticos (darle nombres o significados distintos al mismo problema) entre cliente y servidor.

En el caso de recibir una falla se debe encargar de solicitar el mismo pedido original a otro servidor, en caso de que lo haya. Si un servidor falla frecuentemente, el CLE debe ser capaz de detectarlo y aislarlo, y buscar uno alternativo que pueda darle el servicio buscado. Si no hay servidor alternativo devuelve al cliente la falla, que puede propagarse directamente o en caso de no poder, debe envolverla para que pueda ser recibida y entendida por el cliente o en su defecto una ExcepcionNoDeclarada es lanzada.


A modo de guía los autores proponen las siguientes directivas de cómo deben tratarse las excepciones en el caso de que un servidor levante la excepción E1 luego de que el cliente le envía una petición.

- Si E1 se declara en el interfaz requerido del componente del cliente y el interfaz proporcionado del componente del servidor, E 1 debe ser propagada automáticamente.

- Si E1 se declara en el interfaz proporcionado del componente del servidor y hay un tipo de excepción correspondiente E2 (semántica compatible) declarado en el interfaz requerido del componente del cliente, una excepción del tipo E2 se propaga. Un ejemplo típico de este panorama ocurre cuando las excepciones E1 y E2 tienen un antepasado común, E3; Otro ejemplo ocurre cuando E2 es un supertype de E1

- Si E1 se declara en el interfaz proporcionado del componente del servidor y no se puede traducir según las dos reglas indicadas arriba, después tres diversos resultados son posibles:

-- Si E1 fue señalado porque la petición recibida por el componente del servidor era inválida, y el estado de este último no fue cambiado, una excepción del tipo RejectedRequestException debe ser señalada;

-- Si E1 fue señalado porque el componente del servidor recibió una petición válida y no podía procesarla, si el estado del componente no se ha dañado, un subtipo de RecoveredFailureException se señala;

-- Si E1 fue señalado porque el estado del componente del servidor se ha dañado de alguna manera, cualquiera debido a una petición inválida de debido a una petición válida que no podría ser procesada, un subtipo de UnrecoveredFailureException debe ser señalada.

- Si E1 es un subtipo de UndeclaredException, puede ser propagado automáticamente;

- Si E1 no se declara en el interfaz proporcionado del componente del servidor y no es un subtipo de UndeclaredException, la excepción propagada debe estar de un caso de UnrecoveredFailureException, indicando que el componente del servidor puede estar en un estado contrario.




Resultados
Esta metodología fue puesta a prueba, para el caso de una empresa brasilera, dedicada a brindarle información al viajante en el subsistema de quejas, y se obtuvieron los siguientes resultados:

  • Al estar separados los comportamientos normales y anormales, se pueden modificar el manejo de excepciones sin afectar el funcionamiento general del sistema y lo que resulta mejor aún es que al estar en clases separadas pueden ser reutilizados y esto resulta beneficioso ya que la cantidad de lugares en que las excepciones pueden ocurrir es en general mucho mayor que las maneras de tratarlas.

  • Adaptar un sistema a esta estrategia para el manejo de errores llevo movilizar cerca del 5% de un total de 9000 líneas de código, lo cual es aceptable. Gracias a que la implementación de conectores fue hecha desde un principio, se utilizaron solamente seis conectores. En cambio, adaptar la jerarquía de excepciones demando mucho mas trabajo, revisar mas de 250 lugares en donde excepciones eran lanzadas.

  • Son de gran importancia las opiniones y propuestas de quienes implementan el sistema para futuras correcciones.


Conclusiones
No resulta tarea sencilla la implementación de manejo de excepciones en sistemas basados en componentes, de tal manera que resulten robustos y reutilizables. Por lo que es bastante útil tener una guía o estrategia de pasos a seguir, que no complica por demás el desarrollo, ya que los modelos de componentes mas usados no lo proveen.

Uno de los aspectos a resaltar del trabajo es la división de manejo de excepciones, entre el nivel de componentes y de conectores propuesto para poder ser reutilizado en distintas aplicaciones.



A pesar de la utilidad de esta labor, aún tiene algunas limitaciones en las que se deberá trabajar en el futuro. Por ejemplo, no es aplicable a lenguajes que no soporten manejo de excepciones. Otro aspecto en el que deberá desarrollarse será la creación de una herramienta que permita una implementación más automática que maneje las excepciones en ambos niveles, así como también la aplicación de la división de comportamiento normal y anormal basada en la programación orientada a aspectos.



La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal