MANEJO DE EXCEPCIONES EN JAVA!

Podemos considerar que una Excepcin en programacin es una situacin poco habitual que provoca resultados inesperados o incoherentes en nuestros mtodos, pero que es contemplada en el anlisis, diseo y construccin de nuestro sistema : el sistema se puede recuperar de estas situaciones. Como ejemplos podemos citar envos duplicados de informacin, una cada de nuestra base de datos, informacin invlida o incosistente como un nmero de telfono con un formato incorrecto... Para mantener cdigos robustos que manejen estas situaciones, los lenguajes de programacin incorporan mecanismos para el manejo de excepciones como parte de sus estructuras de control. Y las situaciones poco habituales que provocan resultados inesperados o incoherentes y que no controlamos ? Eso es un error en tiempo de ejecucin en nuestro sistema, que puede desembocar en una inconsistencia de datos en nuestra base de datos o en la finalizacin inesperada de nuestro sistema. Un buen indicador de la calidad de un sistema software es comprobar cmo responde cuando se producen fallos, ya sean esperados y controlados (excepciones) o inesperados e incontrolados (errores). Excepciones en Java En el caso de Java se utilizan bloques try - catch - finally, throw y throws, y las subclases de java.lang.Exception. Un mtodo lanzarn (mediante un throw) una excepcin (una clase que hereda java.lang.Exception) provocando que se abandone el flujo de ejecucin normal y cediendo el control al bloque en el que se capturar (en un bloque try - catch - finally). En la declaracin del mtodo se incluye throws para avisar de que puede lanzar una excepcin. Existen muchas excepciones predefinidas en Java, pero tambin nosotros podemos crear excepciones particulares a nuestros sistemas : basta crear una clase que extienda de java.lang.Exception. Existen dos grandes tipos de excepciones en Java : Checked Exceptions (excepciones controladas). Se corresponden a errores previstos, controlados en el codigo y por tanto permite al sistema recuperarse. Son lo que hemos definido anteriormente como excepciones. Elcompilador Java es una gran ayuda ya que te obliga a capturarlas en un bloque try - catch - finally o a declarar que el mtodo puede devolver una excepcin (declarando un throws). Unchecked Exceptions (excepciones no controladas). Son excepciones no previstas ni controladas, y por tanto puede provocar inconsistencia de datos y la finalizacin inesperada del sistema : lo que hemos definido anteriormente como errores en tiempo de ejecucin. En Java se implementan como subclases de java.lang.RuntimeException (que a su vez hereda de java.lang.Exception) y el compilador no nos obliga a capturarlas ni a declarar que nuestros mtodos pueden lanzarlas. NullPointerException o IllegalArgumentException son dos ejemplos de estas excepciones.

No olvides utilizar la parte finally de los bloques try - catch - finally para liberar recursos como conexiones o archivos. Manejo de Excepciones en una arquitectura Java Al invocar un mtodo deberamos obtener como resultado o bien el resultado normal de la ejecucin o bien no hacer absolutamente nada. Las excepciones nos servirn para comunicar a las capas superiores informacin sobre por qu no se ha hecho nada si fuese necesario. La utilizacin de bloques try - catch - finally es ms costoso en trminos de tiempo de ejecucin y recursos que la utilizacin de bloques if - else. Por tanto es recomendable utilizar excepciones para controlar el flujo, es mejor utilizar los mecanismos de control de flujo ya existentes que consumen menos y son ms fcilmente mantenibles. Tampoco es recomendable capturar una excepcin en un bloque catch y no hacer nada, o no hacer nada ms que lanzarla nuevamente. Es aconsejable que las excepciones no rompan la encapsulacin. Por ejemplo si en una capa inferior se produce una excepcin (por ejemplo una SQLException en la capa de persistencia), a la capa superior no le interesa conocer los detalles de implementacin, sino: si se puede recuperar del error, es aconsejable transformar la excepcin original en otra excepcin controlada ochecked con la informacin necesaria para recuperar que la capa superiro se pueda recuperar. o si no puede recuperarse del error pasamos a la capa superior una excepcin no controlada o unchecked si no se debe continuar el flujo normal, o bien un resultado nulo si no se quiere hacer nada especial. Slo deberamos de crear excepciones propias cuando aporten algo til como informacin extra cuando sean capturadas o comportamientos propios (como un tratamiento especial en un log). Al capturar excepciones tambin capturamos las que heredan de sta. Por tanto al capturar una excepcin del tipo java.lang.Exception tambin estamos capturando todas las unchecked (ya que heredan de java.lang.RuntimeException y sta hereda de java.lang.Exception). Hay que tener cuidado de si esto es realmente lo que queremos. Por todo lo dicho anteriormente, la gestin de las excepciones nos debera de servir para recuperarnos ante errores esperados. Pero deberamos tener en cuenta que pueden existir errores no controlados. Podramos gestionar estos errores en un nico punto, desviando todas las excepciones no capturadas a un action donde se tratarn (tpicamente presentacin de una pgina de error con un mensaje y las acciones permitidas para el usuario, as como la auditora del error). Podemos indicar en el web.xml esta redireccin : <error-page> <exception-type>java.lang.Throwable</exception-type> <location>/gestionErrores.do</location> </error-page>

UML

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en ingls, Unified Modeling Language) Es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estndar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programacin, esquemas de bases de datos y componentes reutilizables. UML es un lenguaje de modelado que permite la representacin conceptual y fsica de un sistema. Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir mtodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que est descrito el modelo. El lenguaje UML se expresa con smbolos y/o agrupaciones de estos llamados diagramas. Nos sirve fundamentalmente para crear diferentes tipos de ellos permitindonos ver desde diferentes perspectivas un sistema software.

UML es un lenguaje para hacer modelos y es independiente de los mtodos de anlisis y diseo. Existen diferencias importantes entre un mtodo y un lenguaje de modelado. Un mtodo es una manera explcita de estructurar el pensamiento y las acciones de cada individuo. Adems, el mtodo le dice al usuario qu hacer, cmo hacerlo, cundo hacerlo y por qu hacerlo; mientras que el lenguaje de modelado carece de estas instrucciones. Los mtodos contienen modelos y esos modelos son utilizados para describir algo y comunicar los resultados del uso del mtodo.

Un modelo es expresado en un lenguaje de modelado. Un lenguaje de modelado consiste de vistas, diagramas, elementos de modelo, los smbolos utilizados en los modelos y un conjunto de mecanismos generales o reglas que indican cmo utilizar los elementos. Las reglas son sintcticas, semnticas y pragmtica. DIAGRAMAS DE CLASE Un diagrama de clases es un tipo de diagrama esttico que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de anlisis y diseo de los sistemas, donde se crea el diseo conceptual de la informacin que se manejar en el sistema, y los componentes que se encargaran del funcionamiento y la relacin entre uno y otro.

DIAGRAMAS DE CASOS DE USO Los diagramas de casos de uso documentan el comportamiento de un sistema desde el punto de vista del usuario. Por lo tanto los casos de uso determinan los requisitos funcionales del sistema, es decir, representan las funciones que un sistema puede ejecutar. Su ventaja principal es la facilidad para interpretarlos, lo que hace que sean especialmente tiles en la comunicacin con el cliente.

E. Relaciones entre objetos

Durante la ejecucin de un programa, los diversos objetos que lo componen han de interactuar entre s para lograr una serie de objetivos comunes.

Existen varios tipos de relaciones que pueden unir a los diferentes objetos, pero entre ellas destacan las relaciones de: asociacin, todo/parte, y generalizacin/especializacin.

a.) Relaciones de Asociacin

Seran relaciones generales, en las que un objeto realiza llamadas a los servicios (mtodos) de otro, interactuando de esta forma con l.

Representan las relaciones con menos riqueza semntica.

b.) Relaciones de Todo/Parte (Generalizacion)

Muchas veces una determinada entidad existe como conjuncin de otras entidades, como un conglomerado de ellas. La orientacin al objeto recoge este tipo de relaciones como dos conceptos; la agregacin y la composicin.

En este tipo de relaciones un objeto componente se integra en un objeto compuesto. La diferencia entre agregacin y composicin es que mientras que la composicin se entiende que dura durante toda

la vida del objeto componedor, en la agregacin no tiene por qu ser as.

Esto se puede implementar como un objeto (objeto compuesto) que cuenta entre sus atributos con otro objeto distinto (objeto componente).

c.) Relaciones de Generalizacin/Especializacin (Herencia)

A veces sucede que dos clases tiene muchas de sus partes en comn, lo que normalmente se abstrae en la creacin de una tercera clase (padre de las dos) que rene todas sus caractersticas comunes.

El ejemplo ms extendido de este tipo de relaciones es la herencia, propiedad por la que una clase (clase hija) recoge aquellos mtodos y atributos que una segunda clase (clase padre) ha especificado como "heredables".

Este tipo de relaciones es caracterstico de la programacin orientada a objetos.

En realidad, la generalizacin y la especializacin son diferentes perspectivas del mismo concepto, la generalizacin es una perspectiva ascendente (bottom-up), mientras que la especializacin es una perspectiva descendente (top-down).