Implementacin de un Sistema de Informacin basado en componentes con J2EE.

Sebastin Bengochea Fabin Fajardo Juan Diego Ferr sbengoch@fing.edu.uy, ffajardo@adinet.com.uy, jdferre@fing.edu.uy

Instituto de Computacin Facultad de Ingeniera Universidad de la Repblica Julio Herrera y Reissig 565 5to. piso, Montevideo 11300, Uruguay Fax: +5982711 0469 http://www.fing.edu.uy/inco

Resumen: El siguiente documento presenta la aplicacin en un caso de estudio (Sistema de Gestin Hotelera [1]) del artculo Arquitectura de Sistemas de Informacin basados en Componentes sobre la Plataforma J2EE [2]. En el mismo se expone una metodologa para a partir de un documento de arquitectura lgica basada en componentes se pueda obtener una implementacin en la plataforma J2EE. La implementacin del Sistema de Gestin Hotelera se basa en los documentos de arquitectura [3] y [4]. En este reporte se presenta el desarrollo e implementacin de uno de los casos de uso del Sistema de Gestin Hotelera, puntualmente Hacer Reserva. Se expondrn los cambios y consideraciones tomados a la hora de implementar. Por cada capa se realizar una discusin de posibles decisiones alternativas, evaluando ventajas y desventajas de estas. As mismo se presentarn limitaciones encontradas en la plataforma. Finalmente se concluir sobre la aplicacin del documento utilizado para realizar el pasaje de la arquitectura basada en componentes a J2EE [2] y el manejo de la persistencia en la plataforma utilizada.

Palabras clave: Sistemas de Informacin, Java 2 Enterprise Edition, Enterprise Java Beans, Desarrollo basado en componentes, Arquitectura de Software.

Tabla de Contenidos

1. 2.

Introduccin.................................................................................................................. 3 Caso de Uso: Hacer Reserva..................................................................................... 4 2.1. Hacer Reserva............................................................................................................ 4 2.2. Identificar Cliente ...................................................................................................... 5 2.3. Alta Cliente................................................................................................................ 5 2.4. Confirmar Reserva..................................................................................................... 6 3. Implementacin de Hacer Reserva ............................................................................... 7 3.1. Mquina de Estado: Identificar Cliente ..................................................................... 9 3.2. Mquina de Estado: Alta Cliente............................................................................... 9 3.3. Mquina de Estado: Confirmar Reserva.................................................................. 10 3.4. Maquina de Estado: Hacer Reserva......................................................................... 10 4. Arquitectura del Sistema ............................................................................................ 11 4.1. Interfaz de Usuario .................................................................................................. 11 4.2. UI de Dilogos de Usuario ...................................................................................... 11 4.3. Dilogos de Usuario ................................................................................................ 12 4.4. Servicios del Sistema............................................................................................... 12 4.5 Servicios de Negocio ................................................................................................ 12 5. Interfaz de Usuario ..................................................................................................... 13 Discusiones..................................................................................................................... 13 6. UI de Dilogos de Usuario ......................................................................................... 14 Discusiones..................................................................................................................... 18 7. Dilogos de Usuario ................................................................................................... 18 7.1. Composicin de Casos de Uso ................................................................................ 20 7.2. Discusiones.............................................................................................................. 23 8. Servicios del Sistema.................................................................................................. 23 Discusiones..................................................................................................................... 23 9. Servicios de Negocio .................................................................................................. 25 9.1. Persistencia usando CMP ........................................................................................ 25 9.2. Diseo de la Base de Datos ..................................................................................... 27 9.3. Discusiones.............................................................................................................. 28 10. Conclusiones........................................................................................................... 29 Persistencia ..................................................................................................................... 29 11. Referencias ............................................................................................................. 31 Anexo: Mquinas de Estado ............................................................................................... 32 Identificar Reserva.......................................................................................................... 32 Tomar Reserva................................................................................................................ 32 Cancelar Reserva ............................................................................................................ 33 Modificar Reserva .......................................................................................................... 33

Pgina 2 de 33

1. Introduccin
Durante la ltimos aos ha resurgido con fuerza renovada el inters por parte de las empresas actuales de poner en produccin Sistemas de Informacin, que provean mayor valor a sus negocios. La amplia difusin y fcil acceso a Internet desarrollado en la dcada pasada han permitido generar no solo una gran infraestructura, sino que han sido de central importancia para concebir nuevas tecnologas, las cuales permitan desarrollar Sistemas de Informacin: Flexibles: que sea posible (sin requerir un gran esfuerzo) la incorporacin de nuevos requerimientos en el tiempo. Escalables: que permitan atender una demanda creciente de solicitudes de servicios sin necesidad de realizar grandes cambios en la implementacin original del sistema. Un ejemplo de esto es la gran cantidad de usuarios capaces de acceder por la Web. Independientes del Hardware: la concepcin de un sistema de Informacin sea independiente del fabricante del Hardware (por ejemplo Arquitectura del Sistema, Sistema Operativo, DBMS, etc). Interoperables: los sistemas puedan brindar y utilizar servicios de otros sistemas, eventualmente coordinando y cooperando para llegar en conjunto a una solucin final de forma sencilla. Rpido desarrollo: dados los tiempos actuales y la gran competencia, la concepcin de cualquier sistema debe de realizarse cada vez en menor tiempo, intentando en etapas tempranas la puesta en produccin de parte del sistema para de forma incremental incorporar nuevas funcionalidades.

Java 2 Plataform, Enterprise Edition (J2EE) ha surgido y madurado en los ltimos aos como una de las tecnologas utilizadas para concepcin de Sistemas de Informacin. J2EE es una especificacin que intenta resolver los problemas antes presentados, brindando servicios de persistencia, seguridad, transaccionalidad, presentacin web (Pginas HTML generadas dinmicamente con cdigo java JSP hasta Web Services sobre el estndar SOAP), entre otros. En el presente reporte se presenta la experiencia de desarrollar un Sistema de Informacin basado en componentes utilizando JBoss [5], el cual es una implementacin open source de J2EE. El sistema desarrollado es el Sistema de Gestin Hotelera [1] y el proceso de desarrollo utilizado es el presentado en el artculo Arquitectura de Sistemas de Informacin basados en Componentes sobre la Plataforma J2EE [2]. En dicho artculo se expone una metodologa para a partir de un documento de arquitectura lgica basada en componentes se pueda obtener una implementacin en la plataforma J2EE. Se presentarn las distintas capas de la Arquitectura y como fue implementada cada una. Se analizarn las decisiones tomadas y posibles alternativas en la implementacin. Finalmente se concluir sobre la aplicacin del documento utilizado para realizar el pasaje de la arquitectura basada en componentes a J2EE [2] y el manejo de la persistencia en la plataforma utilizada.

Pgina 3 de 33

2. Caso de Uso: Hacer Reserva

A continuacin se presenta el caso de uso Hacer Reserva y los casos de uso que lo componen [3].

2.1. Hacer Reserva

Nombre

Hacer Reserva (CU1)

Actores Creador de Reserva, Sistema de Mensajera Actividades Ver Disponibilidad, Sugerir Alternativas, Hacer Reserva, Confirmar Reserva Sinopsis Este caso de uso comienza cuando el Creador de Reserva solicita crear una reserva. El sistema chequea la disponibilidad de una habitacin en un hotel solicitado. Si hay disponibilidad el Sistema hace la reserva y le confirma la misma al cliente. Si no hay disponible una habitacin, el sistema sugiere hoteles alternativos. Curso Tpico de Eventos
1a. Incluir Identificar Cliente (CU2). 1b. Incluir Alta Cliente (CU3) 2. 3. 4. 5. Creador de Reserva indica hotel (en caso de estar en la Recepcin de un hotel esta informacin se provee automticamente), tipo de habitacin y duracin de la estada. Sistema confirma disponibilidad. Sistema registra la reserva. Incluir Confirmar Reserva (CU4).

Extensiones
1a. No existe el cliente: 1. 2. 1. Incluir Alta de Cliente. Resume 2. Sistema busca disponibilidad en otros hoteles. 1a. No hay disponibilidad en ningn hotel: 1. 2. 2. Sistema notifica a Creador de Reserva. Resume 2.

3a. No hay disponibilidad:

Creador de Reserva indica un hotel de su conveniencia. 2a. Creador de Reserva prefiere cambiar datos de la reserva: 1. Resume 2.

3.

Resume 4.

Pgina 4 de 33

2.2. Identificar Cliente

Nombre

Identificar Cliente (CU2)

Actores Cliente, Sistema de Mensajera Actividades N/A Sinopsis Identifica al actor como cliente registrado. Curso Tpico de Eventos
1. 2. 3. Cliente provee el nombre de usuario y el password. Sistema localiza al cliente. Sistema comprueba el password.

Extensiones
1a. Cliente no conoce el nombre de usuario ni el password: 1. 1. 2. 3. 4. 1. 2. 1. 2. Fallo. Sistema localiza al cliente. Sistema notifica al Sistema de Mensajera que enve e-mail al cliente con el password. Sistema notifica al Cliente que el password ha sido enviado por e-mail. Resume 1. Sistema notifica el error. Resume 1. Sistema notifica el error. Resume 1. 1b. Cliente no conoce el password:

2a. Sistema no encuentra un cliente con el identificador indicado:

3a. El password ingresado es incorrecto:

2.3. Alta Cliente

Nombre

Alta Cliente (CU3)

Actores Cliente, Sistema de Mensajera Actividades N/A Sinopsis Registrar al actor cliente como un usuario vlido del sistema. Curso Tpico de Eventos
1. 2. Cliente provee cdula de identidad, el nombre de usuario, password, e-mail, direccin, telfono y mvil. El Sistema registra el cliente. Cliente ingresa una cdula, password, e-mail telfono o mvil no valido: 1. 2. 3. 1. 1. Fallo. Fallo. Fallo. Falta algn dato requerido: Cliente ya existe:

Extensiones
1.

Pgina 5 de 33

2.4. Confirmar Reserva

Nombre

Confirmar Reserva (CU4)

Actores Sistema de Mensajera Actividades Confirmar Reserva Sinopsis Notifica al cliente cambios en una reserva. El mecanismo de comunicacin puede ser e-mail, beeper, mensaje al celular o fax, en funcin de los datos que se tenga del cliente y el modo de comunicacin elegido. Si el cliente es extranjero solo puede utilizarse e-mail. Curso Tpico de Eventos
1. 2. 3. Sistema identifica el mecanismo de comunicacin con el cliente. Sistema prepara informacin de la reserva. Sistema solicita al Sistema de Mensajera el envo del mensaje al cliente.

Extensiones
N/A

Pgina 6 de 33

3. Implementacin de Hacer Reserva

La implementacin del sistema se orient en todo momento a los casos de uso y procesos de negocio. Muchas de las decisiones tomadas a la hora de implementar buscan que el sistema tenga las siguientes caractersticas: Facilidad de incorporar nuevos casos de uso, reutilizar y cambiar lo menos posible el cdigo. Composicin de forma transparente de los casos de uso. Esto implica anidamiento de los casos de uso y reutilizacin de la lgica de negocios en todas las capas del sistema.

Dichas caractersticas nos permiten centralizar lgica en un nico punto con los consecuentes impactos que esto tiene (mantenibilidad, evolucionabilidad), acorta los tiempos de desarrollo y permite la construccin incremental del sistema (comenzando por los CU ms simples y reutilizando estos en CU ms complejos). La plataforma utilizada para implementar el Sistema de Gestin Hotelera es J2EE, puntualmente se utilizaron las siguientes herramientas: JBoss 3.2.1 Como Servidor de Aplicaciones [5]. Tomcat 4.1 Como Servidor Web [6]. Castor 9.5 Usado para el manejo de XML [7]. Oracle 8i Como Base de Datos sobre la cual se persistieron los datos.

La versin de Java utilizada para desarrollo y mquina virtual fue JSDK 1.4.1. Se tomo la decisin de utilizar el servidor Web (Tomcat 4.1) independiente (no como un servicio) del servidor de aplicaciones (JBoss 3.2.1). Esto permite (por ejemplo en ambientes de produccin) que ambos servidores se encuentren en mquinas distintas, lo cual en cierta medida facilita la escalabilidad de la solucin. Debido a esta separacin y al correr en Mquinas Virtuales distintas el acceso desde el servidor Web se logra a travs del uso de interfaces remotas. Se presentar a lo largo del presente documento el desarrollo del caso de uso Hacer Reserva. El mismo incluye otros casos de uso y sirve a modo de ejemplo, de cuales fueron los pasos y decisiones tomadas en el desarrollo del sistema. A partir de la descripcin de los casos de uso (CU), el primer paso es desarrollar cada una de las mquinas de estado, comenzando por aquellas que componen Hacer Reserva. Notar que la composicin de CU en su forma ms general puede derivar en un grafo acclico dirigido, donde se comenzara por implementar los CU cuyos grado de salida son cero (no dependen de otro CU).

Pgina 7 de 33

En la Figura 1, puede verse la Arquitectura Lgica del caso de uso Hacer Reserva, la misma fue desarrollada en base a lo definido en [2].

Figura 1 En el desarrollo de las mquinas de estado, se manej en todo momento una relacin uno a uno entre pgina JSP y estado. Esto facilita en gran medida la concepcin del sistema y permite darle caractersticas de usabilidad orientadas a un sistema Web. A continuacin se presentan los diagramas de mquinas de estado de Hacer Reserva (En el Anexo 1 estn las mquinas de estado de todos los CU implementados). Los estados grises representan acciones dentro de los estados.

Pgina 8 de 33

3.1. Mquina de Estado: Identificar Cliente

Figura 2

3.2. Mquina de Estado: Alta Cliente

Figura 3

Pgina 9 de 33

3.3. Mquina de Estado: Confirmar Reserva

Figura 4

3.4. Maquina de Estado: Hacer Reserva

Figura 5 En la mquina de estado de la Figura 5 se puede apreciar la composicin de casos de uso para AltaCliente, IdentificarCliente y ConfirmarReserva, correspondiente a los estados con estereotipo composite.

Pgina 10 de 33

4. Arquitectura del Sistema

En la Figura 6 se presenta la arquitectura del sistema en capas, utilizando para el mismo un modelo estricto (cada capa utiliza solo servicios de su capa inmediata).

Figura 6

4.1. Interfaz de Usuario

Esta capa es la encargada de presentar al usuario la informacin relevante del sistema, permite al usuario manipular dicha informacin. En esta capa se encuentran los formularios, pginas web, documentos, etc.

4.2. UI de Dilogos de Usuario

Capa encargada de manejar la lgica de Interfase de Usuario, es responsable de coordinar la presentacin al usuario. Por ejemplo coordinando la secuencias de pginas correctas a ser desplegadas al usuario en la capa vista en 4.1.

Pgina 11 de 33

4.3. Dilogos de Usuario

Esta capa se encarga de manipular la lgica de los dilogos con el usuario, esta capa es la encargada de mantener el estado actual de comunicacin con el usuario. Cada comunicacin por parte del usuario con el dilogo implica el manejo de una transaccin.

4.4. Servicios del Sistema

En esta capa se encuentra la lgica encargada de resolver los requerimientos funcionales del sistema. Esta capa cuenta con un conjunto de componentes (subsistemas) encargados cada uno de modularizar una funcionalidad o servicio del sistema global, la composicin de estos componentes permite manejar una solucin con alta cohesin y bajo acoplamiento. Tambin se encuentran en esta capa adaptadores de sistemas externos.

4.5 Servicios de Negocio

Capa encargada de manejar los tipos estables del negocio, entre otras cosas manejo de la informacin persistente del sistema.

Pgina 12 de 33

5. Interfaz de Usuario
Esta capa esta compuesta por las pginas JSP, HTML y archivos JavaScript. Como front end de nuestro sistema, las pginas sern accedidas entonces utilizando un Browser (cliente fino) por medio del cual el usuario va ha interactuar con el sistema. Todas las pginas HTML generadas a partir de una JSP estn configuradas para realizar el submit a un Servlet Despachador, utilizado como facade del sistema y nico punto de entrada de la capa UI Dialogos de Usuario. El Despachador ser tambin el encargado de redireccionar las respuestas por parte de la capa Dilogo de Usuario a pginas JSP (eventualmente cualquier URL) definidas a travs de un Mapa. Las funciones del despachador sern presentadas en la siguiente seccin. Si bien utilizamos un cliente fino como es un Browser HTML, realizamos verificaciones sintcticas de los datos en las mismas pginas HTML por medio de funciones JavaScript. Esto disminuye el trfico de datos a travs de la red y libera de procesamiento los servidores web y de aplicaciones. La estructura del sitio Web se basa en los casos de uso. Contamos con una pgina HTML inicial que permite disparar la ejecucin de los casos de uso disponibles, los cuales se encuentran en subdirectorios con nombres descriptivos tal como se ve en la Figura 7, en la cual se expone un diagrama de dependencias de las arquitectura de ejecucin para el CU Hacer Reserva.

Figura 7

Discusiones
Es posible dotar de lgica al Cliente (Browser), utilizando funciones y cdigos JavaScript. En la implementacin presentada el uso de JavaScript se limit al de verificacin sintctica. Si bien esto mejora la eficiencia de la aplicacin (ya que errores sintcticos son detectados antes de enviar los datos al servidor) genera replicacin de las validaciones, las que deben de incluirse en la capa Dilogos de Usuario. Considerar la inclusin de validaciones sintcticas en la capa Dialogos de Usuario (eventualmente alguna capa inferior) permite reutilizar la mquina de estado, lgica y validaciones en otros contextos de visualizacin o acceso a los Datos, como por ejemplo clientes remotos Java, Web Services o aplicaciones PDA. El uso de JavaScript adems, permite implementar dependencias entre controles, resolviendo el correspondiente join de las tablas en el cliente. Un ejemplo concreto de esto es la dependencia entre dos combos de una pgina, donde el valor seleccionado en el primero, limita las posibilidades de eleccin en el segundo (elegir un hotel limita la eleccin del tipo de habitacin sin necesidad de realizar un submit al Servidor). Si bien esto puede mejorar la usabilidad de las pginas reduciendo su nmero, es necesario evaluar la aplicacin de este mecanismo en base a la cantidad de datos utilizados, ya que de otra forma los tiempos de carga pueden incrementarse notoriamente en los casos de tablas con grandes cantidades de registros.

Pgina 13 de 33

El informe de errores generados por una pgina fue centralizado en una lista de strings con los mensajes correspondientes, asociados a errores semnticos (eventualmente sintcticos), que se despliega al comienzo de la misma pgina cuando es regenerada. Esto disminuye la usabilidad, ya que los mensajes de error no se relacionan directamente con el campo al que se refieren. Una solucin a este problema es utilizar una tabla de dispersin (java.util.Map) que permita asociar a cada control a desplegarse en la pgina un estado de error con su correspondiente mensaje. La reutilizacin de pginas web fue en realidad una consecuencia de la reutilizacin de casos de uso. Otro enfoque posible es crear pginas independientes inclusive del caso de uso y reutilizables en cualquier parte de la aplicacin. La desventaja es el incremento en la complejidad de cada pgina, donde deben de ser parametrizadas caractersticas tales como ttulos, formatos, etc. En esta aplicacin puntual, las pginas candidatas a este tipo de implementacin no se reutilizaran lo suficiente como para justificar el aumento en los tiempos de desarrollo y dificultades de mantenimiento.

6. UI de Dilogos de Usuario
La comunicacin de datos a travs de las distintas capas del sistema se realiza mediante JavaBeans serializables. Cada CU a nivel de la Interfaz de Usuario y UI de Dialogo de Usuario tienen definida una Interfase que ser el medio de comunicar datos entre estas dos capas. Dichas interfases deben implementar la interfase base IDatos y las correspondientes de todos los CU que estn incluidos en el primero. En la Figura 8 se muestra el diagrama de clases del CU Identificar Cliente.

Figura 8 La interfase IDatos define tres propiedades, que sern usadas en todos los CU:

mensaje : String - Que son mensajes propagados desde la capa Dilogos de Usuario para
dilogo con el usuario, por ejemplo errores transaccionales o semnticos. comando : String En una pgina HTML el usuario puede disparar ms de un evento distinto (por ejemplo seleccionar dar de alta un nuevo usuario o identificarse como un cliente ya existente), el comando entonces le indica al dilogo cual de esto eventos fueron seleccionados por el usuario. En la figura 9 se muestra una pgina con tres posibles eventos disparados por el usuario en el CU Hacer Reserva.

errores : List - Corresponde a una lista de errores encontrados en la ejecucin de un

ser presentados al Usuario a travs del HTML generado por la JSP.

Pgina 14 de 33

Evento generado por el usuario: CMD_AUTENTICAR

Evento generado por el usuario: CMD_CANCELAR

Evento generado por el usuario: CMD_ALTA_CLIENTE

Figura 9 Los comandos posibles estn definidos para cada CU en su correspondiente interfase, de esta forma se logra centralizar por medio de variables estticas finales los nombres usados. Notar que CMD_CANCELAR es un comando definido en la interfase IDatos ya que en todos los CU el usuario puede cancelar su ejecucin. La siguiente parte de la mquina de estado de Hacer Reserva muestra como los comandos corresponden a las entradas que generan cambios de estado, en nuestro caso alta corresponde a CMD_ALTA_CLIENTE e identificar a CMD_AUTENTICAR.

Figura 10 Cuando el usuario dispara un evento en una pgina HTML, se esta realizando el submit del formulario correspondiente. Los datos de la pgina llegan al Servlet Despachador como un objeto HttpRequest. A continuacin el Despachador debe de obtener la instancia de IDatos correspondiente al caso de uso corriente y cargar la misma con los valores enviados desde la pgina. El mecanismo utilizado para cargar el Bean que implementa la interfase IDatos que se utiliza en el Despachador es el siguiente: 1- El Servlet Despachador recibe un Request correspondiente a un submit HTML a travs del protocolo HTTP. 2- El Servlet obtiene el bean que implementa IDatos, puede ser de la HttpSession si se encuentra corriendo un CU, o al disparar el comienzo de un nuevo CU del dialogo correspondiente.

Pgina 15 de 33

3- Por medio de introspeccin el Servlet Despachador analiza los mtodos de la interfase IDatos y por cada mtodo set<nombrePropiedad> si existe un campo en el request que coincida con el nombre de la propiedad lo utiliza en el mtodo set para cargarlo al bean. De esta forma se logra que el Servlet Despachador sea independiente de las implementaciones de distintos CU, lo cual nos permite mantener muy sencillo el cdigo y adems agregar nuevos CU sin necesidad de tener que recompilar la lgica existente. Es necesario que el programador llame a los controles HTML de igual forma que se llaman las propiedades definidas en la interfase que implementa el bean, para que el mecanismo de introspeccin sea exitoso. Para mantener al despachador desacoplado de los CU y que el mismo funcione de forma transparente tanto en la llamada a los dilogos como en la respuesta de estos, es que se define un archivo XML que permite configurar las redirecciones de las respuestas segn el estado de cada CU a una URL particular, el esquema que valida a dicho XML puede verse en la Figura 11. Este archivo ser cargado por una clase Mapa (Singleton) usada por el Servlet Despachador.

Figura 11 El XML cuenta con un elemento propiedadesJNDI que contiene un conjunto de propiedades (nombre, valor) que sern usadas para configurar el servicio de directorios sobre el cual la factory DialogoFactory se va a encargar de obtener las interfaces correspondientes a los dilogos de usuario y retornarlas a medida que el Servlet Despachador las necesite. Es posible, cambiando la estructura del XSD, que cada dilogo tenga asignado un conjunto de propiedadesJNDI. De esta forma podran obtenerse dilogos de mltiples servidores de aplicacin. A cada CU le corresponde en el XML un elemento infoDialogo, con los siguientes atributos:

medio del servicio de Directorios de JNDI.

nombre: Corresponde al nombre que identifica al Dilogo. titulo: Titulo del Dilogo actual (utilizado para la presentacin en las pginas web). interfaceHome: Nombre de la interfase Home del SessionBean a ser obtenido por

Adems infoDialogo tiene un conjunto de hijos infoEstado los cuales, a partir de un estado actual de ejecucin del dialogo, definen a que URL debe de ser redireccionada la respuesta a el usuario. Para el manejo de XML se utilizo castor. A partir del esquema XSD que valida la estructura del XML usado en el singleton Mapa, se generan utilizando Castor un conjunto de clases capaces de leer el XML de texto desde un InputStream (por ejemplo de un archivo en disco o como un recurso remoto). A su vez estas clases corresponden a los elementos definidos en el esquema lo cual facilita y abstrae la lectura (parsing) y manipulacin del XML.

Pgina 16 de 33

A continuacin se presenta una instancia de XML correspondiente al esquema del Mapa para el CU Hacer Reserva.

Figura 12 Notar que las entradas del Mapa corresponden a los nombres de los dilogos seguido por los nombres de los estados, y por esto en la composicin de CU encontramos entradas nicas tal como puede verse en el tem 2 y 3 de infoEstado. En la Figura 13 puede verse la interaccin de las 3 primeras capas pasando por el Servlet Despachador e iniciando un nuevo dilogo o caso de uso.

Figura 13 Cada vez que se dispara un nuevo CU, viene en la HttpRequest un parmetro nomDialogo cuyo valor corresponde al atributo nombre del elemento infoDialogo del XML. El Despachador busca entonces el objeto dilogo en la httpsession. En caso de no encontrarlo, es creado a travs de la factory DialogoFactory. Una vez que el Despachador tiene un objeto dilogo, el cual implementa la interfase IDialogo, lo que hace es invocar el mtodo ejecutar con argumento IDatos nulo. El resultado de la invocacin

Pgina 17 de 33

de ejecutar retorna una instancia de IDatos la cual ser almacenada en la HttpSession para ser utilizada por la JSP en la generacin dinmica de las pginas HTML. El resultado adems cuenta con un identificador el cual corresponde a una entrada en el Mapa, indicando al despachador a que URL debe redireccionar la ejecucin del corriente CU. Lo que tenemos entonces es un Servlet Despachador que se adapta y configura de forma declarativa a un conjunto de casos de uso. En la Figura 14 se presenta la ejecucin de un caso de uso ya en proceso:

Figura 14

Discusiones
En la implementacin de la factory encargada de retornar la instancia de cada Dilogo se encapsulo el acceso a JNDI, de forma tal que dicha factory solo retorna una interfase Idialogo. Esto permite abstraer tanto la configuracin remota (por medio del XML, ver seccin 6), como la distribucin real de dichos dilogos. Se evalu el uso de Struts [8], como framework a utilizar para el desarrollo de la primeras dos capas (Interfaz de Usuario y UI de Dilogos de Usuario). Encontramos que dicho framework no es aplicable en el modelo utilizado ya que define la mquina de estados en la capa UI de Dilogos de Usuario y no en Dilogos de Usuario tal cual especificado en [2]. El hecho que la mquina de estados este definida en una capa independiente de la vista permite reutilizar la lgica de la misma en otros contextos, como por ejemplo aplicaciones clientes Java o PDA.

7. Dilogos de Usuario
En esta capa se implementa la mquina de estados, se coordina la composicin de casos de uso y se construyen las respuestas a ser devueltas luego de la ejecucin. Al igual que en las otras capas mantenemos una organizacin de paquetes orientada a elementos de uso comn y casos de uso, con lo cual tenemos un paquete por cada CU y otro sub paquete estado con las clases que implementan el pattern state [9] y definen la mquina de estado correspondiente, tal como puede verse en la Figura 15.

Pgina 18 de 33

Figura 15 Los dilogos en esta capa sern implementados por Statefull Session Beans, los cuales adems son los encargados de iniciar (begin) y finalizar (commit, rollback) una transaccin que enmarque la operativa por parte del usuario. Es por esto que los Session Bean de esta capa sern todos configurados como BMT (Bean Managed Transaction), mientras que los subsecuentes Session Beans del resto de las capas sern CMT (Container Managed Transaction) heredando estos la transaccin abierta por el Dilogo de Usuario [2]. Por otra parte los dilogos definirn interfaces remotas (para ser invocadas desde el Servlet Despachador) e interfaces locales (usadas por las composiciones de casos de uso). A continuacin en la Figura 16 se expone el diagrama de clases que define el API usado para el desarrollo del conjunto de dilogos (parte del paquete uy.edu.fing.leda.dlgusuario.base).

Figura 16

Pgina 19 de 33

Las interfases de IEstado e IContextoEstado son las usadas para implementar la mquina de estado (siguiendo el pattern state [9]). IContextoEstado va ha ser implementada por el dilogo. A su vez cada estado va ser un singleton que solo contendr la lgica de ejecucin, condicionada por los datos de entrada IDatos. Cada cambio de estado se implementa invocando sobre IContextoEstado el mtodo setEstado con el nuevo estado al cual pasa a encontrarse el dilogo actual. Resultado es la clase que se retorna luego de una ejecucin. En la ejecucin un dilogo (o caso de uso) puede encontrarse en una de tres etapas: xito, Fallo y En Proceso. La informacin de la etapa en que se encuentra un dilogo, permite en la composicin de casos de uso conocer cuando ha finalizado y de que forma (xito o Fallo) la ejecucin del dilogo compuesto. Por ejemplo la composicin en Hacer Reserva del CU Alta Cliente (ver Figura 4), el estado AltaCliente compuesto va ha invocar ejecutar del dilogo Alta Cliente mientras la etapa del resultado de la ejecucin sea En Proceso, cuando la etapa sea xito, entonces ocurrir un cambio de estado (ya que la ejecucin compuesta fue exitosa) y en caso de que la etapa sea Fallo se finalizar (en Fallo) la ejecucin del CU Hacer Reserva. La clase Resultado tambin cuenta con una instancia de IDatos, la cual tiene informacin relevante a la ejecucin del CU. Por ultimo esta clase tiene los mtodos concatenarRutaDlgEstado y getRutaDlgEstado, estos mtodos son usados en la composicin de CU para poder generar en el Mapa entradas nicas que permitan redirigir exitosamente las respuestas del Despachador para cada CU puntual.

7.1. Composicin de Casos de Uso

La composicin de casos de uso se deriva del documento de requerimientos que define la inclusin de CU ms simples dentro de otros ms complejos. Las siguientes decisiones de implementacin (muchas de las cuales ya presentamos) son usadas para lograr la composicin de CU de forma transparente: 1- Es fundamental que la instancia de IDatos de el caso de uso compuesto, implemente las interfaces correspondientes de IDatos de cada uno de los CU que lo componen. Esto permite que al interactuar entre casos de uso usando el mismo bean de informacin, no exista la necesidad de realizar transformaciones o adaptaciones intermedias, esto puede verse en la Figura 17.

Pgina 20 de 33

Figura 17 Por ejemplo en Hacer Reserva, cuando se invoca el Dilogo usado para el CU Confirmar Reserva, basta con invocar el mismo pasndole como argumento la instancia actual de IDatos (IDatosHacerReserva), ya que la misma es tambin una instancia de IDatosConfirmarReserva. En algunos casos se hace necesario tambin cambiar el comando actual, para que la composicin funcione correctamente. 2- Se define un estado (agregando al nombre el sufijo Comp en la implementacin) el cual es el encargado de coordinar la ejecucin del CU compuesto, tal como puede verse en la Figura 18, un extracto de la mquina de estado de hacer reserva.

Figura 18

Pgina 21 de 33

El estado IdentAlta recibe como entrada por parte del usuario una solicitud de alta (CMD_ALTA_CLIENTE), a partir de la cual obtiene la interfase de dilogo correspondiente al CU Alta Cliente y lo deja guardado (con el nombre del dilogo) en la interfase IContexto usando el mtodo setProperty (ver Figura 19). Realiza el cambio de estado a AltaClienteComp, a travs de IContexto usando setEstado.

Figura 19 3- El estado encargado de realizar la composicin obtiene de la interfase IContexto el dilogo correspondiente al CU que este estado est componiendo. En el ejemplo AltaClienteComp obtiene de IContexto el dilogo de nombre DlgAltaCliente. Es AltaClienteComp el encargado de disparar la ejecucin inicial y de controlar la evolucin del CU compuesto. Es aqu que se utilizan las etapas de un CU definidas en la clase Resultado (ver Figura 16). Es importante notar que cada Dilogo y estado que invoca una ejecucin compuesta de casos de uso, debe agregar al Resultado su nombre, con lo cual obtenemos entradas nicas para el Mapa de redireccin del Servlet Despachador. Esto permite reutilizar (o no) las JSP del CU compuesto, dando la flexibilidad al programador de eventualmente cambiar el front end en la composicin. En el ejemplo de composicin de Alta Cliente se tiene una entrada para el mapa (Figura 12, infoEstado 3):

/IngresoDatos/DlgAltaCliente/AltaClienteComp/DlgHacerReserva
Esta clave va ha permitir al Despachador, obtener la URL a la cual redirigir el resultado de la ejecucin (de la composicin de Alta Cliente en Hacer Reserva), lo importante es notar que para cada combinacin de CU compuesta se tiene una entrada distinta.

Figura 20

Pgina 22 de 33

El mecanismo de composicin utilizado permite de forma transparente (para el CU includo) integrar una secuencia no acotada de casos de uso.

7.2. Discusiones
Una alternativa evaluada para componer Casos de Uso fue la de utilizar un Stack, el cual se encargue de mantener los estados previos. Esta alternativa fue desechada debido a los siguientes problemas: La ubicacin del Stack debera ser UI de Dilogos de Usuario, para que el servlet Despachador pueda manejar el estado actual. El problema de este enfoque es que separa la lgica de la composicin de estados entre dos capas UI de Dilogos de Usuario y Dilogos de Usuario, limitando el reuso de la misma desde otras vistas. Si se desplaza al Stack hacia la capa de Dilogos de Usuario para mantener la poltica de reuso, se hace complejo su manejo desde el Despachador. En particular, se hace difcil para el Despachador determinar cual es el dilogo actual que debe de ejecutar y obtener el stub del mismo (recordad que los dilogos son remotos).

Para la implementacin de estados se utilizo el pattern singleton [9]. Esta decisin fue tomada debido a que permite reducir la cantidad de objetos Java creados aumentando la escalabilidad del sistema. La decisin de que los CU que componen (reutilizan) otros CU implementen cada interfase IDatos de los CU compuestos, genera problemas cuando dos campos con el mismo nombre, tienen significados semnticos distintos. Un problema podra surgir en el procesamiento del bean IDatos que va a contener y procesar un solo parmetro, dados por herencia de las interfaces, cuando deben de existir al menos dos parmetros distintos, siendo esta una limitacin en la composicin de Casos de Uso. En la implementacin del sistema no encontramos ningn caso de este tipo, ya que los parmetros con igual nombre, en la composicin de CU, correspondan a parmetros equivalentes semnticamente. La existencia de una nica interfase que herede de IDatos en todos los CU, facilita la composicin de CU y la invocacin de ms de un paso de ejecucin de la mquina de estado de forma consecutiva. La alternativa a este enfoque, es el de utilizar una interfase por cada pgina JSP. Aunque cada interfase herede de IDatos, es necesario en cada invocacin de ejecucin a la mquina de estado, construir la instancia de la nueva interfase correspondiente. Si bien esto puede facilitar la reutilizacin de la pgina JSP, limita la composicin de CU y el uso de la mquina de estados en ambientes que no sean Web, ya que es necesario en cada cambio de estado la construccin y carga de un nuevo Bean.

8. Servicios del Sistema

Esta capa es la encargada de coordinar y de resolver los requerimientos funcionales del sistema. Interacta con los componentes externos (en nuestro caso con el sistema de facturacin). Los Session Bean definidos como CMT (Container Manager Transaction) fueron mapeados sin problemas a partir del documento de la Arquitectura.

Discusiones
Al disear esta capa se plante la disyuntiva de permitir una comunicacin horizontal (entre capas), vertical (entre objetos de la misma capa) o una combinacin de ambas. Esto debido principalmente a que algunos dilogos de usuario, para resolver los casos de uso, requieren el uso

Pgina 23 de 33

de funciones de distintos servicios del sistema. Se plantearon dos opciones, o bien era el dilogo de usuario quien se encargaba de llamar a ambos servicios de sistema o se permita encadenar dichas invocaciones. Un ejemplo de este problema se da en el momento de hacer una reserva y enviar la confirmacin: para hacer la reserva se utiliza sistemaReservas, al enviar la confirmacin se utiliza sistemaClientes (para obtener la direccin de correo electrnico) y sistemaMensajera (es quien enva el mail). En la implementacin realizada se decidi permitir la comunicacin horizontal y la vertical, es decir, la que se aplicara mejor en cada caso ya que no permitir una de ellas no implicaba ninguna ventaja. Otro aspecto a destacar de esta capa es su sencillez. Sin contar el problema descrito anteriormente, no se present ninguna dificultad para su implementacin debido a que la mayora de los mtodos de las clases solo realizan una invocacin a mtodos de la capa inferior (Servicios de Negocio). Esto lleva a replantear la utilidad de la utilidad de esta capa y el porqu de su existencia. Sin embargo es donde se realiza la comunicacin con los sistemas externos, como ser el sistema de mensajera y el sistema de facturacin, lo cual no es razonable implementarlo (conceptualmente) ni en la capa inferior (Servicio de negocio) ni en la capa superior (Dilogos de Usuario). Una opcin alternativa es manejar una arquitectura de capas relajada, es decir, permitir utilizar funcionalidades de los Servicios de Negocios desde los Dilogos de Usuario. De esta forma se pueden quitar los servicios del sistema que manejan entidades locales y dejar solo aquellos que se utilizan para la comunicacin con sistemas externos. Esta opcin se descart debido a que se opt por una arquitectura en capas estricta.

Pgina 24 de 33

9. Servicios de Negocio
El manejo de los componentes persistentes se realiz por medio de dos enfoques, utilizando un conjunto de Entity Beans usando CMP 2.0 y utilizando JDBC directamente desde las implementaciones de los Managers. Los Managers permiten definir una interfase comn de manejo desde la capa de Servicios de negocio, obtenindose la flexibilidad de variar la implementacin interna de forma radical sin impactar en el resto del sistema.

Figura 21

9.1. Persistencia usando CMP

En la implementacin basada en CMP se busca evitar en todo momento usar consultas SQL o alguna solucin propietaria del servidor de aplicaciones utilizado [5], para de esta forma intentar mantener la propiedad de compatibilidad entre aplicaciones EJB. Es por esto que no se utiliz ningn Entity Bean cuyo manejo de persistencia fuera BMP. El uso de BMP puede ser importante para lograr cumplir con algunos de los requerimientos no funcionales de performance, en requerimientos clave del sistema, pero a modo de evaluacin acadmica fue que se tomaron los dos extremos posibles de implementacin de persistencia del sistema. Gran parte de los requerimientos fueron resueltos usando consultas EJB QL, las cuales son un mecanismo sencillo, flexible y compatible para la resolucin de consultas sobre Entity Beans y sus

Pgina 25 de 33

relaciones. Por otra parte existe una fuerte limitacin de este lenguaje de consultas ya que no se pueden utilizar comparaciones ni restricciones por campos del tipo fecha. Se detectaron algunos problemas con la definicin de relaciones que formen ciclos entre Entity Beans, posiblemente problemas propios del Servidor de aplicaciones utilizado [5], en muchos casos inesperadamente al recorrer las colecciones de las relaciones 1..n ocurrieron perdidas de datos almacenados en la BD.

Figura 22 El Entity Bean ReservaAutonumerador es utilizado para asignar de forma independiente de la BD, un nmero nico a cada reserva. Su implementacin esta hecha de forma tal que su comportamiento sea el de un singleton. Pueden apreciarse de la Figura 22, en Reserva los mtodos find utilizados para resolver parte de los requerimientos del sistema. A continuacin se presentan las consultas EJB QL parametrizables utilizadas en dicho Entity Bean:

findByHotelTipo
SELECT OBJECT(r) FROM Reserva r WHERE r.nombreHotel = ?1 AND r.nombreTipoHabitacion = ?2 AND (r.estado = 0 OR r.estado = 1 OR r.estado = 4)

findPendientesByClientes
SELECT OBJECT(r) FROM Reserva r WHERE

Pgina 26 de 33

r.ciCliente = ?1 AND r.estado = 0

findNoTomadas
SELECT OBJECT(r) FROM Reserva r WHERE r.nombreHotel = ?1 AND r.estado = 0 Es importante destacar que tanto la definicin como creacin de la estructura de la BD se realiza en el deploy de la aplicacin J2EE sobre el servidor de aplicaciones, con lo cual la estructura de la Base queda definida por los Entity Beans y sus relaciones (Foreign Keys). Se pudo verificar el funcionamiento de la abstraccin de la persistencia y consultas EJB QL utilizando distintos motores de BD para el desarrollo. Los DBMS utilizados indistintamente fueron Oracle y mySql, en los mismos el deploy y comportamiento de los Entity Beans fue el mismo.

9.2. Diseo de la Base de Datos

El modelo conceptual de la base de datos tiene una correspondencia directa con el modelo de Entity Beans presentado anteriormente, ya que la misma fue generada en el deploy de dichos beans. Posteriormente se cargaron datos y se crearon ndices para agilizar las consultas ms usuales. El diseo de la base de datos es el siguiente:
Clientes PK,I1 ci nombre password email telefono movil direccion Reservas PK,I1 I2 I3 I3,I2 FK1,I4 FK2 FK3 idreserva checkin checkout estado cicliente numero tipohabitacion I2 FK1 FK1 Habitaciones PK,I1 numero ocupada tipohabitacion nombrehotel

ReservaAutonumerador PK,I1 id numeroactual

HotelTHRelacion PK,FK1,I1 PK,FK2,I1,I2 tipohabitacion nombrehotel

TipoHabitacion PK,I1 nombre detalle

Hoteles PK,I1 nombre

Figura 23

Pgina 27 de 33

Los ndices fueron creados en funcin de las consultas que se realizan ms habitualmente sobre la base, como ser la bsqueda de alternativas para un tipo de habitacin, la bsqueda de una habitacin disponible de un tipo en determinado hotel o la bsqueda de todas las reservas de un cliente en determinado estado en una fecha dada. Para testear la aplicacin esta base fue cargada con datos de prueba. Las cantidades de tuplas cargadas para cada tabla son las siguientes: Tabla Clientes Hoteles TipoHabitacion HotelTHRelacion Habitaciones ReservaAutonumerador Reservas Cantidad de Registros 20.001 20 8 100 2.000 1 189.986

9.3. Discusiones
Al realizar el diseo conceptual de esta capa, se present el problema de cmo identificar cada una de las entidades. Las opciones manejadas fueron el uso de una clave natural para la entidad o una clave nica no natural. Si bien las claves naturales se asocian ms fcilmente con el objeto que representan (el nombre de un hotel por ejemplo) estas suelen depender en muchas ocasiones del contexto en que se manejen. Un ejemplo claro de esto es la identificacin de un cliente, lo natural es realizarla por el nombre (no es un identificador nico) o por la cdula de identidad la cual vara segn el pas (CI, DNI, Pasaporte, etc). Las claves no naturales no tienen problemas de contexto ni de ambigedad, pero son ms complicadas de manejar, ya que deben arrastrar siempre la clave junto con la informacin. Por ejemplo, al solicitar los hoteles, necesito enviar junto con el nombre (es lo que utiliza el usuario para identificar al hotel) la clave nica no natural (es lo que utiliza el sistema para identificar al hotel). Esto tambin obliga a realizar joins o duplicar informacin para obtener la identificacin para el usuario de un objeto (si las reservas tienen el cdigo del hotel es necesario ir al hotel a buscar el nombre, a menos que este se encuentre duplicado en la reserva) aumentando el tiempo de consulta y/o la complejidad del esquema al desnormalizarlo. En la implementacin realizada se utilizaron claves naturales debido a que su uso es menos complejo, ms directo, las entidades y el esquema son simples y poseen un identificador nico natural (Hotel-Nombre, Cliente-CI, etc).

Pgina 28 de 33

10.

Conclusiones

Quedo comprobado que la aplicacin de la metodologa presentada en [2], permite a partir de la especificacin de un sistema basado en componentes, realizar una rpida implementacin en la plataforma J2EE del Sistema de Informacin. La implementacin de los primeros CU, as como la interaccin de las 3 primeras capas (Interfase de Usuario, UI de Dilogos de Usuario y Dilogos de Usuario) definiendo implementaciones que permitan componer y reutilizar casos de uso fue lo que llevo ms tiempo. Luego de definidos estos puntos, la implementacin del resto del sistema resulto muy sencilla, siguiendo los siguientes pasos: 1- Definicin de la Mquina de Estados correspondiente al CU. 2- Implementacin de la interfaz de usuario en paralelo con la implementacin de dilogos de Usuario y Servicios del Sistema/Negocio (Dada la implementacin declarativa del servlet Despachador prcticamente no fue necesario realizar cambios a nivel de la capa UI de Dilogos de Usuario). 3- Pruebas e Integracin. Resulta interesante investigar la posibilidad de automatizar la generacin de clases correspondientes a la capa de Dilogos de Usuario (mquina de estado y Session Bean del dilogo) a partir de la definicin de la Mquina de Estados en algn lenguaje formal, como por ejemplo UML. A s como tambin en caso de incorporar metadata de la UI, la posible automatizacin en la generacin de la misma. La aplicacin de la metodologa presentada en [2] en conjunto con las decisiones tomadas en la implementacin, relativas a la composicin de casos de uso presentadas en el presente reporte, permiten la implementacin iterativa incremental de un Sistema de Informacin, donde la lgica de sus componentes se encuentran centralizados (a travs de casos de uso que se reutilizan) y donde el Sistema mantiene caractersticas de modularizacin, reuso y extensibilidad propios de una arquitectura en capas.

Persistencia
En tiempos de desarrollo no se detectan grandes diferencias entre una implementacin de JDBC y otra enteramente realizada con CMP 2.0, salvo en algunos casos puntuales (por ejemplo con la alta, baja y modificacin de cliente). El desarrollo con CMP puede ser un mtodo eficiente si los beans son simples. Su manejo e implementacin son extremadamente sencillos, una vez adquirida cierta experiencia en el tema. Para beans ms complejos, las polticas de creacin y carga de la informacin que siguen los servidores de aplicaciones en general podran hacer que se perjudique la performance de ejecucin de manera importante. Es en esos casos cuando el desarrollo con BMP puede aumentar su importancia, aunque requiera ms tiempo de implementacin. Cabe destacar que la convivencia entre beans BMP y CMP es posible, y el servidor de aplicaciones la hace totalmente transparente. Sin embargo, hemos podido comprobar que la tecnologa EJB an impone ciertas limitaciones no despreciables al momento de tomar decisiones de diseo que contemplen requerimientos importantes de performance (si bien es de esperar que dichas limitaciones vayan desvanecindose en futuras especificaciones). La limitacin sobre consultas EJB QL, las cuales no soportan condiciones que contengan campos del tipo fecha plantea ser un problema no menor. El mismo tiene un gran impacto en el diseo de la solucin planteada para buscar disponibilidad con alternativas. En la solucin con JDBC se puede restringir la cantidad de bsqueda de reservas utilizando una condicin sobre las fechas de

Pgina 29 de 33

reservas disponibles, mientras que utilizando CMP es necesario cargar una gran cantidad de Entity Beans los cuales sern procesados usando lgica Java para filtrar las fechas no validas. Esta impacto a nivel de diseo nos lleva a los siguientes tiempos encontrados entre ambas implementaciones, con diferencias sustanciales: Cantidad de reservas pendientes en total: 86000 Cantidad de reservas pendientes por hotel: 4300 Buscar las resevas para tomar hoy (promedio en segundos) cmp: 12,5 jdbc: 0,1 Buscar disponibilidad Se busco una habitacin de un cierto tipo en un hotel para un perodo de un da, donde no haba disponibilidad. (Hotel Edn, Superior, 30/08/2003) cmp: 8,50 jdbc: 0,26 Buscar disponibilidad con alternativas Se busco una habitacin de un cierto tipo en un hotel para un perodo de un da, donde no haba disponibilidad. Existen 14 hoteles alternativos y solo 1 donde haba disponibilidad. (Hotel Edn, Suite Presidencial, 30/08/2003) cmp: 36,0 jdbc: 2,5 La diferencia de tiempo encontrada entonces en la ejecucin de una transaccin hace que la puesta en produccin del sistema con bsqueda de alternativas implementadas con CMP no sea viable. Esto nos lleva a plantear la posibilidad de una solucin a travs de un sistema que utilice en algunos requerimientos CMP y en otros BMP. Luego de realizadas las implementaciones usando persistencia a travs de CMP y de JDBC, llegamos a la conclusin que el uso de Entity Beans (CMP y BMP) no tiene una gran diferencia en los tiempos de desarrollo comparado con los tiempos de JDBC. Le sumamos a esto las restricciones encontradas en CMP las cuales llevaron a diseos de soluciones poco performantes y hasta algunos problemas en la definicin de relaciones con ciclos entre los beans y encontramos que la nica ventaja del uso de CMP sobre la implementacin directa a travs de JDBC es la abstraccin de las consultas SQL propietarias de cada BD. Esta limitante por otra parte puede ser evitada en caso de utilizar algn framework de persistencia entre el modelo Orientado a Objetos y el modelo Relacional (por ejemplo utilizando Castor JDO [7]). Una ventaja no estudiada del uso de la persistencia en J2EE, es el de considerar el soporte de cach de Objetos previsto como parte de la especificacin. Evaluar este aspecto (ventaja del uso de BMP y CMP) en datos consultados constantemente (sobre una base en control directo por el servidor de aplicaciones) podra generar tiempos ms favorables de respuesta promedio que una implementacin basada en JDBC (o utilizando un framework de persistencia sin soporte de cach), quedando planteada esta interrogante para trabajos futuros.

Pgina 30 de 33

11.

Referencias

[1] J. Cheesman, J. Daniels. UML Components, Addison Wesley, 2002. [2] - D. Perovich, L. Rodrguez, A. Vignaga. Arquitectura de Sistemas de Informacin basados en Componentes sobre la Plataforma J2EE, InCo Pedeciba, Montevideo, Uruguay, 2003. [3] - D. Perovich, A. Vignaga. SAD del Subsistema de Reservas del Sistema de Gestin Hotelera. Reporte Tcnico RT03-15, InCo Pedeciba, Montevideo, Uruguay, 2003. [4] - D. Di Pascua, F. Hernndez, A. Mackiewicz. Caso de estudio Sistema de Gestin Hotelera, SI en Arquitecturas Distribuidas, Montevideo, Uruguay, 2003. [5] - JBoss Web Site: www.jboss.org. [6] - Tomcat Web Site: www.jakarta.apache.org/tomcat. [7] - Castor Web Site: www.exolab.org. [8] Struts Web Site: www.jakarta.apache.org/struts [9] - E. Gamma, R. Helm, R. Jonson, J. Vlissides, Design Patterns Elements of Reusable OO Software, Prentice may, 1995.

Pgina 31 de 33

Anexo: Mquinas de Estado

A continuacin se presenta los diagramas de mquinas de estado para los CU implementados y que no forman parte de Hacer Reserva. Los estados grises representan acciones dentro de los estados.

Identificar Reserva

Tomar Reserva

Pgina 32 de 33

Cancelar Reserva

Modificar Reserva

Pgina 33 de 33