Implementación de un Sistema de Información basado en

componentes con J2EE.

Sebastián Bengochea – Fabián Fajardo – Juan Diego Ferré sbengoch@fing.edu.uy, ffajardo@adinet.com.uy, jdferre@fing.edu.uy

Instituto de Computación – Facultad de Ingeniería – Universidad de la República

Julio Herrera y Reissig 565 5to. piso, Montevideo 11300, Uruguay Fax: +598–2–711 0469

http://www.fing.edu.uy/inco

Resumen: El siguiente documento presenta la aplicación en un caso de estudio (“Sistema de Gestión Hotelera” [1]) del artículo “Arquitectura de Sistemas de Información basados en Componentes sobre la Plataforma J2EE” [2]. En el mismo se expone una metodología para a partir de un documento de arquitectura lógica basada en componentes se pueda obtener una implementación en la plataforma J2EE. La implementación del Sistema de Gestión Hotelera se basa en los documentos de arquitectura [3] y [4]. En este reporte se presenta el desarrollo e implementación de uno de los casos de uso del “Sistema de Gestión Hotelera”, puntualmente Hacer Reserva. Se expondrán los cambios y consideraciones tomados a la hora de implementar. Por cada capa se realizará una discusión de posibles decisiones alternativas, evaluando ventajas y desventajas de estas. Así mismo se presentarán limitaciones encontradas en la plataforma. Finalmente se concluirá sobre la aplicación 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 Información, Java 2 Enterprise Edition, Enterprise Java Beans, Desarrollo basado en componentes, Arquitectura de Software.

Tabla de Contenidos 1. Introducción.................................................................................................................. 3 2. 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. Implementación de Hacer Reserva ............................................................................... 7 3.1. Máquina de Estado: Identificar Cliente ..................................................................... 9 3.2. Máquina de Estado: Alta Cliente............................................................................... 9 3.3. Máquina 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 Diálogos de Usuario ...................................................................................... 11 4.3. Diálogos 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 Diálogos de Usuario ......................................................................................... 14 Discusiones..................................................................................................................... 18

7. Diálogos de Usuario ................................................................................................... 18 7.1. Composición 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. Diseño de la Base de Datos ..................................................................................... 27 9.3. Discusiones.............................................................................................................. 28

10. Conclusiones........................................................................................................... 29 Persistencia ..................................................................................................................... 29

11. Referencias ............................................................................................................. 31 Anexo: Máquinas de Estado ............................................................................................... 32

Identificar Reserva.......................................................................................................... 32 Tomar Reserva................................................................................................................ 32 Cancelar Reserva ............................................................................................................ 33 Modificar Reserva .......................................................................................................... 33

Página 2 de 33

1. Introducción Durante la últimos años ha resurgido con fuerza renovada el interés por parte de las empresas actuales de poner en producción Sistemas de Información, que provean mayor valor a sus negocios. La amplia difusión y fácil acceso a Internet desarrollado en la década pasada han permitido generar no solo una gran infraestructura, sino que han sido de central importancia para concebir nuevas tecnologías, las cuales permitan desarrollar Sistemas de Información:

• Flexibles: que sea posible (sin requerir un gran esfuerzo) la incorporación 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 implementación original del sistema. Un ejemplo de esto es la gran cantidad de usuarios capaces de acceder por la Web.

• Independientes del Hardware: la concepción de un sistema de Información 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 solución final de forma sencilla.

• Rápido desarrollo: dados los tiempos actuales y la gran competencia, la concepción de

cualquier sistema debe de realizarse cada vez en menor tiempo, intentando en etapas tempranas la puesta en producción de parte del sistema para de forma incremental incorporar nuevas funcionalidades.

Java 2 Plataform, Enterprise Edition (J2EE) ha surgido y madurado en los últimos años como una de las tecnologías utilizadas para concepción de Sistemas de Información. J2EE es una especificación que intenta resolver los problemas antes presentados, brindando servicios de persistencia, seguridad, transaccionalidad, presentación web (Páginas HTML generadas dinámicamente con código java JSP hasta Web Services sobre el estándar SOAP), entre otros. En el presente reporte se presenta la experiencia de desarrollar un Sistema de Información basado en componentes utilizando JBoss [5], el cual es una implementación open source de J2EE. El sistema desarrollado es el “Sistema de Gestión Hotelera” [1] y el proceso de desarrollo utilizado es el presentado en el artículo “Arquitectura de Sistemas de Información basados en Componentes sobre la Plataforma J2EE” [2]. En dicho artículo se expone una metodología para a partir de un documento de arquitectura lógica basada en componentes se pueda obtener una implementación en la plataforma J2EE. Se presentarán las distintas capas de la Arquitectura y como fue implementada cada una. Se analizarán las decisiones tomadas y posibles alternativas en la implementación. Finalmente se concluirá sobre la aplicación 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.

Página 3 de 33

2. Caso de Uso: “Hacer Reserva” A continuación 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 Mensajería 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 habitación en un hotel solicitado. Si hay disponibilidad el Sistema hace la reserva y le confirma la misma al cliente. Si no hay disponible una habitación, el sistema sugiere hoteles alternativos.

Curso Típico de Eventos 1a. Incluir Identificar Cliente (CU2).

1b. Incluir Alta Cliente (CU3)

2. Creador de Reserva indica hotel (en caso de estar en la Recepción de un hotel esta información se provee automáticamente), tipo de habitación y duración de la estadía.

3. Sistema confirma disponibilidad.

4. Sistema registra la reserva.

5. Incluir Confirmar Reserva (CU4).

Extensiones 1a. No existe el cliente:

1. Incluir Alta de Cliente.

2. Resume 2.

3a. No hay disponibilidad:

1. Sistema busca disponibilidad en otros hoteles.

1a. No hay disponibilidad en ningún hotel:

1. Sistema notifica a Creador de Reserva.

2. Resume 2.

2. 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.

Página 4 de 33

2.2. Identificar Cliente

Nombre Identificar Cliente (CU2) Actores Cliente, Sistema de Mensajería Actividades N/A Sinopsis Identifica al actor como cliente registrado. Curso Típico de Eventos 1. Cliente provee el nombre de usuario y el password.

2. Sistema localiza al cliente.

3. Sistema comprueba el password.

Extensiones 1a. Cliente no conoce el nombre de usuario ni el password:

1. Fallo.

1b. Cliente no conoce el password:

1. Sistema localiza al cliente.

2. Sistema notifica al Sistema de Mensajería que envíe e-mail al cliente con el password.

3. Sistema notifica al Cliente que el password ha sido enviado por e-mail.

4. Resume 1.

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

1. Sistema notifica el error.

2. Resume 1.

3a. El password ingresado es incorrecto:

1. Sistema notifica el error.

2. Resume 1.

2.3. Alta Cliente

Nombre Alta Cliente (CU3) Actores Cliente, Sistema de Mensajería Actividades N/A Sinopsis Registrar al actor cliente como un usuario válido del sistema. Curso Típico de Eventos 1. Cliente provee cédula de identidad, el nombre de usuario, password, e-mail, dirección,

teléfono y móvil.

2. El Sistema registra el cliente.

Extensiones 1. Cliente ingresa una cédula, password, e-mail teléfono o móvil no valido:

1. Fallo.

2. Falta algún dato requerido:

1. Fallo.

3. Cliente ya existe:

1. Fallo.

Página 5 de 33

2.4. Confirmar Reserva Nombre Confirmar Reserva (CU4) Actores Sistema de Mensajería Actividades Confirmar Reserva Sinopsis Notifica al cliente cambios en una reserva. El mecanismo de comunicación

puede ser e-mail, beeper, mensaje al celular o fax, en función de los datos que se tenga del cliente y el modo de comunicación elegido. Si el cliente es extranjero solo puede utilizarse e-mail.

Curso Típico de Eventos 1. Sistema identifica el mecanismo de comunicación con el cliente.

2. Sistema prepara información de la reserva.

3. Sistema solicita al Sistema de Mensajería el envío del mensaje al cliente.

Extensiones N/A

Página 6 de 33

3. Implementación de Hacer Reserva La implementación 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 características:

• Facilidad de incorporar nuevos casos de uso, reutilizar y cambiar lo menos posible el código.

• Composición de forma transparente de los casos de uso. Esto implica anidamiento

de los casos de uso y reutilización de la lógica de negocios en todas las capas del sistema.

Dichas características nos permiten centralizar lógica en un único punto con los consecuentes impactos que esto tiene (mantenibilidad, evolucionabilidad), acorta los tiempos de desarrollo y permite la construcción incremental del sistema (comenzando por los CU más simples y reutilizando estos en CU más complejos). La plataforma utilizada para implementar el “Sistema de Gestión 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 versión de Java utilizada para desarrollo y máquina virtual fue JSDK 1.4.1. Se tomo la decisión 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 producción) que ambos servidores se encuentren en máquinas distintas, lo cual en cierta medida facilita la escalabilidad de la solución. Debido a esta separación y al correr en Máquinas Virtuales distintas el acceso desde el servidor Web se logra a través 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 descripción de los casos de uso (CU), el primer paso es desarrollar cada una de las máquinas de estado, comenzando por aquellas que componen Hacer Reserva. Notar que la composición de CU en su forma más general puede derivar en un grafo acíclico dirigido, donde se comenzaría por implementar los CU cuyos grado de salida son cero (no dependen de otro CU).

Página 7 de 33

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

Figura 1

En el desarrollo de las máquinas de estado, se manejó en todo momento una relación uno a uno entre página JSP y estado. Esto facilita en gran medida la concepción del sistema y permite darle características de usabilidad orientadas a un sistema Web. A continuación se presentan los diagramas de máquinas de estado de Hacer Reserva (En el Anexo 1 están las máquinas de estado de todos los CU implementados). Los estados grises representan acciones dentro de los estados.

Página 8 de 33

3.1. Máquina de Estado: Identificar Cliente

Figura 2

3.2. Máquina de Estado: Alta Cliente

Figura 3

Página 9 de 33

3.3. Máquina de Estado: Confirmar Reserva

Figura 4

3.4. Maquina de Estado: Hacer Reserva

Figura 5

En la máquina de estado de la Figura 5 se puede apreciar la composición de casos de uso para AltaCliente, IdentificarCliente y ConfirmarReserva, correspondiente a los estados con estereotipo composite.

Página 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 información relevante del sistema, permite al usuario manipular dicha información. En esta capa se encuentran los formularios, páginas web, documentos, etc.

4.2. UI de Diálogos de Usuario Capa encargada de manejar la lógica de Interfase de Usuario, es responsable de coordinar la presentación al usuario. Por ejemplo coordinando la secuencias de páginas correctas a ser desplegadas al usuario en la capa vista en 4.1.

Página 11 de 33

4.3. Diálogos de Usuario

Esta capa se encarga de manipular la lógica de los diálogos con el usuario, esta capa es la encargada de mantener el estado actual de comunicación con el usuario. Cada comunicación por parte del usuario con el diálogo implica el manejo de una transacción.

4.4. Servicios del Sistema En esta capa se encuentra la lógica 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 composición de estos componentes permite manejar una solución con alta cohesión y bajo acoplamiento. También 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 información persistente del sistema.

Página 12 de 33

5. Interfaz de Usuario Esta capa esta compuesta por las páginas JSP, HTML y archivos JavaScript. Como front end de nuestro sistema, las páginas serán accedidas entonces utilizando un Browser (cliente fino) por medio del cual el usuario va ha interactuar con el sistema. Todas las páginas HTML generadas a partir de una JSP están 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á también el encargado de redireccionar las respuestas por parte de la capa Diálogo de Usuario a páginas JSP (eventualmente cualquier URL) definidas a través de un Mapa. Las funciones del despachador serán presentadas en la siguiente sección. Si bien utilizamos un cliente fino como es un Browser HTML, realizamos verificaciones sintácticas de los datos en las mismas páginas HTML por medio de funciones JavaScript. Esto disminuye el tráfico de datos a través 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 página HTML inicial que permite disparar la ejecución 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 ejecución para el CU Hacer Reserva.

Figura 7

Discusiones

Es posible dotar de lógica al Cliente (Browser), utilizando funciones y códigos JavaScript. En la implementación presentada el uso de JavaScript se limitó al de verificación sintáctica. Si bien esto mejora la eficiencia de la aplicación (ya que errores sintácticos son detectados antes de enviar los datos al servidor) genera replicación de las validaciones, las que deben de incluirse en la capa Diálogos de Usuario. Considerar la inclusión de validaciones sintácticas en la capa Dialogos de Usuario (eventualmente alguna capa inferior) permite reutilizar la máquina de estado, lógica y validaciones en otros contextos de visualización o acceso a los Datos, como por ejemplo clientes remotos Java, Web Services o aplicaciones PDA. El uso de JavaScript además, 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 página, donde el valor seleccionado en el primero, limita las posibilidades de elección en el segundo (elegir un hotel limita la elección del tipo de habitación sin necesidad de realizar un submit al Servidor). Si bien esto puede mejorar la usabilidad de las páginas reduciendo su número, es necesario evaluar la aplicación 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.

Página 13 de 33

El informe de errores generados por una página fue centralizado en una lista de strings con los mensajes correspondientes, asociados a errores semánticos (eventualmente sintácticos), que se despliega al comienzo de la misma página 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 solución a este problema es utilizar una tabla de dispersión (java.util.Map) que permita asociar a cada control a desplegarse en la página un estado de error con su correspondiente mensaje. La reutilización de páginas web fue en realidad una consecuencia de la reutilización de casos de uso. Otro enfoque posible es crear páginas independientes inclusive del caso de uso y reutilizables en cualquier parte de la aplicación. La desventaja es el incremento en la complejidad de cada página, donde deben de ser parametrizadas características tales como títulos, formatos, etc. En esta aplicación puntual, las páginas candidatas a este tipo de implementación no se reutilizarían lo suficiente como para justificar el aumento en los tiempos de desarrollo y dificultades de mantenimiento.

6. UI de Diálogos de Usuario La comunicación de datos a través 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 estén 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 serán usadas en todos los CU:

• mensaje : String - Que son mensajes propagados desde la capa Diálogos de Usuario para ser presentados al Usuario a través del HTML generado por la JSP.

• errores : List - Corresponde a una lista de errores encontrados en la ejecución de un diálogo con el usuario, por ejemplo errores transaccionales o semánticos.

• comando : String – En una página HTML el usuario puede disparar más 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 diálogo cual de esto eventos fueron seleccionados por el usuario. En la figura 9 se muestra una página con tres posibles eventos disparados por el usuario en el CU Hacer Reserva.

Página 14 de 33

Evento generado por el usuario: CMD_ALTA_CLIENTE

Evento generado por el usuario: CMD_AUTENTICAR

Evento generado por el usuario: CMD_CANCELAR

Los comandos posibles están definidos para forma se logra centralizar por medio de variabCMD_CANCELAR es un comando definido en lapuede cancelar su ejecución. La siguiente parte de la máquina de estadocorresponden a las entradas que generan camCMD_ALTA_CLIENTE e identificar a CMD_AUTE

Cuando el usuario dispara un evento en unformulario correspondiente. Los datos de la páHttpRequest. A continuación el Despachacorrespondiente al caso de uso corriente y cpágina. El mecanismo utilizado para cargar el Bean quDespachador es el siguiente:

1- El Servlet Despachador recibe un Requprotocolo HTTP.

2- El Servlet obtiene el bean que imple

encuentra corriendo un CU, o al discorrespondiente.

Págin

Figura 9

cada CU en su correspondiente interfase, de esta les estáticas finales los nombres usados. Notar que interfase IDatos ya que en todos los CU el usuario

de Hacer Reserva muestra como los comandos bios de estado, en nuestro caso alta corresponde a NTICAR.

Figura 10

a página HTML, se esta realizando el submit del gina llegan al Servlet Despachador como un objeto dor debe de obtener la instancia de IDatos argar la misma con los valores enviados desde la

e implementa la interfase IDatos que se utiliza en el

est correspondiente a un submit HTML a través del

menta IDatos, puede ser de la HttpSession si se parar el comienzo de un nuevo CU del dialogo

a 15 de 33

3- Por medio de introspección el Servlet Despachador analiza los métodos de la interfase

IDatos y por cada método set<nombrePropiedad> si existe un campo en el request que coincida con el nombre de la propiedad lo utiliza en el método 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 código y además agregar nuevos CU sin necesidad de tener que recompilar la lógica 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 introspección sea exitoso. Para mantener al despachador desacoplado de los CU y que el mismo funcione de forma transparente tanto en la llamada a los diálogos como en la respuesta de estos, es que se define un archivo XML que permite configurar las redirecciones de las respuestas según 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 serán usadas para configurar el servicio de directorios sobre el cual la factory DialogoFactory se va a encargar de obtener las interfaces correspondientes a los diálogos de usuario y retornarlas a medida que el Servlet Despachador las necesite. Es posible, cambiando la estructura del XSD, que cada diálogo tenga asignado un conjunto de propiedadesJNDI. De esta forma podrían obtenerse diálogos de múltiples servidores de aplicación. A cada CU le corresponde en el XML un elemento infoDialogo, con los siguientes atributos:

• nombre: Corresponde al nombre que identifica al Diálogo. • titulo: Titulo del Diálogo actual (utilizado para la presentación en las páginas web). • interfaceHome: Nombre de la interfase Home del SessionBean a ser obtenido por

medio del servicio de Directorios de JNDI. Además infoDialogo tiene un conjunto de hijos infoEstado los cuales, a partir de un estado actual de ejecución 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 manipulación del XML.

Página 16 de 33

A continuación 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 diálogos seguido por los nombres de los estados, y por esto en la composición de CU encontramos entradas únicas tal como puede verse en el ítem 2 y 3 de infoEstado. En la Figura 13 puede verse la interacción de las 3 primeras capas pasando por el Servlet Despachador e iniciando un nuevo diálogo o caso de uso.

Figura 13

Cada vez que se dispara un nuevo CU, viene en la HttpRequest un parámetro “nomDialogo” cuyo valor corresponde al atributo nombre del elemento infoDialogo del XML. El Despachador busca entonces el objeto diálogo en la httpsession. En caso de no encontrarlo, es creado a través de la factory DialogoFactory. Una vez que el Despachador tiene un objeto diálogo, el cual implementa la interfase IDialogo, lo que hace es invocar el método ejecutar con argumento IDatos nulo. El resultado de la invocación

Página 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 generación dinámica de las páginas HTML. El resultado además cuenta con un identificador el cual corresponde a una entrada en el Mapa, indicando al despachador a que URL debe redireccionar la ejecución 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 ejecución de un caso de uso ya en proceso:

Figura 14

Discusiones

En la implementación de la factory encargada de retornar la instancia de cada Diálogo se encapsulo el acceso a JNDI, de forma tal que dicha factory solo retorna una interfase Idialogo. Esto permite abstraer tanto la configuración remota (por medio del XML, ver sección 6), como la distribución real de dichos diálogos. 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 Diálogos de Usuario). Encontramos que dicho framework no es aplicable en el modelo utilizado ya que define la máquina de estados en la capa UI de Diálogos de Usuario y no en Diálogos de Usuario tal cual especificado en [2]. El hecho que la máquina de estados este definida en una capa independiente de la vista permite reutilizar la lógica de la misma en otros contextos, como por ejemplo aplicaciones clientes Java o PDA.

7. Diálogos de Usuario En esta capa se implementa la máquina de estados, se coordina la composición de casos de uso y se construyen las respuestas a ser devueltas luego de la ejecución. Al igual que en las otras capas mantenemos una organización de paquetes orientada a elementos de uso común 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 máquina de estado correspondiente, tal como puede verse en la Figura 15.

Página 18 de 33

Figura 15

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

Figura 16

Página 19 de 33

Las interfases de IEstado e IContextoEstado son las usadas para implementar la máquina de estado (siguiendo el pattern state [9]). IContextoEstado va ha ser implementada por el diálogo. A su vez cada estado va ser un singleton que solo contendrá la lógica de ejecución, condicionada por los datos de entrada IDatos. Cada cambio de estado se implementa invocando sobre IContextoEstado el método setEstado con el nuevo estado al cual pasa a encontrarse el diálogo actual. Resultado es la clase que se retorna luego de una ejecución. En la ejecución un diálogo (o caso de uso) puede encontrarse en una de tres etapas: Éxito, Fallo y En Proceso. La información de la etapa en que se encuentra un diálogo, permite en la composición de casos de uso conocer cuando ha finalizado y de que forma (Éxito o Fallo) la ejecución del diálogo compuesto. Por ejemplo la composición en Hacer Reserva del CU Alta Cliente (ver Figura 4), el estado AltaCliente compuesto va ha invocar ejecutar del diálogo Alta Cliente mientras la etapa del resultado de la ejecución sea En Proceso, cuando la etapa sea Éxito, entonces ocurrirá un cambio de estado (ya que la ejecución compuesta fue exitosa) y en caso de que la etapa sea Fallo se finalizará (en Fallo) la ejecución del CU Hacer Reserva. La clase Resultado también cuenta con una instancia de IDatos, la cual tiene información relevante a la ejecución del CU. Por ultimo esta clase tiene los métodos concatenarRutaDlgEstado y getRutaDlgEstado, estos métodos son usados en la composición de CU para poder generar en el Mapa entradas únicas que permitan redirigir exitosamente las respuestas del Despachador para cada CU puntual. 7.1. Composición de Casos de Uso La composición de casos de uso se deriva del documento de requerimientos que define la inclusión de CU más simples dentro de otros más complejos. Las siguientes decisiones de implementación (muchas de las cuales ya presentamos) son usadas para lograr la composición 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 información, no exista la necesidad de realizar transformaciones o adaptaciones intermedias, esto puede verse en la Figura 17.

Página 20 de 33

Figura 17

Por ejemplo en Hacer Reserva, cuando se invoca el Diálogo usado para el CU Confirmar Reserva, basta con invocar el mismo pasándole como argumento la instancia actual de IDatos (IDatosHacerReserva), ya que la misma es también una instancia de IDatosConfirmarReserva. En algunos casos se hace necesario también cambiar el comando actual, para que la composición funcione correctamente.

2- Se define un estado (agregando al nombre el sufijo Comp en la implementación) el cual es el encargado de coordinar la ejecución del CU compuesto, tal como puede verse en la Figura 18, un extracto de la máquina de estado de hacer reserva.

Figura 18

Página 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 diálogo correspondiente al CU Alta Cliente y lo deja guardado (con el nombre del diálogo) en la interfase IContexto usando el método setProperty (ver Figura 19). Realiza el cambio de estado a AltaClienteComp, a través de IContexto usando setEstado.

Figura 19

3- El estado encargado de realizar la composición obtiene de la interfase IContexto el diálogo correspondiente al CU que este estado está componiendo. En el ejemplo AltaClienteComp obtiene de IContexto el diálogo de nombre “DlgAltaCliente”. Es AltaClienteComp el encargado de disparar la ejecución inicial y de controlar la evolución 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 Diálogo y estado que invoca una ejecución compuesta de casos de uso, debe agregar al Resultado su nombre, con lo cual obtenemos entradas únicas para el Mapa de redirección 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 composición. En el ejemplo de composición 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 ejecución (de la composición de Alta Cliente en Hacer Reserva), lo importante es notar que para cada combinación de CU compuesta se tiene una entrada distinta.

Figura 20

Página 22 de 33

El mecanismo de composición utilizado permite de forma transparente (para el CU incluído) 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 ubicación del Stack debería ser UI de Diálogos de Usuario, para que el servlet Despachador pueda manejar el estado actual. El problema de este enfoque es que separa la lógica de la composición de estados entre dos capas UI de Diálogos de Usuario y Diálogos de Usuario, limitando el reuso de la misma desde otras vistas.

• Si se desplaza al Stack hacia la capa de Diálogos de Usuario para mantener la

política de reuso, se hace complejo su manejo desde el Despachador. En particular, se hace difícil para el Despachador determinar cual es el diálogo actual que debe de ejecutar y obtener el stub del mismo (recordad que los diálogos son remotos).

Para la implementación de estados se utilizo el pattern singleton [9]. Esta decisión fue tomada debido a que permite reducir la cantidad de objetos Java creados aumentando la escalabilidad del sistema. La decisión 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 semánticos distintos. Un problema podría surgir en el procesamiento del bean IDatos que va a contener y procesar un solo parámetro, dados por herencia de las interfaces, cuando deben de existir al menos dos parámetros distintos, siendo esta una limitación en la composición de Casos de Uso. En la implementación del sistema no encontramos ningún caso de este tipo, ya que los parámetros con igual nombre, en la composición de CU, correspondían a parámetros equivalentes semánticamente. La existencia de una única interfase que herede de IDatos en todos los CU, facilita la composición de CU y la invocación de más de un paso de ejecución de la máquina de estado de forma consecutiva. La alternativa a este enfoque, es el de utilizar una interfase por cada página JSP. Aunque cada interfase herede de IDatos, es necesario en cada invocación de ejecución a la máquina de estado, construir la instancia de la nueva interfase correspondiente. Si bien esto puede facilitar la reutilización de la página JSP, limita la composición de CU y el uso de la máquina de estados en ambientes que no sean Web, ya que es necesario en cada cambio de estado la construcción 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. Interactúa con los componentes externos (en nuestro caso con el sistema de facturación). Los Session Bean definidos como CMT (Container Manager Transaction) fueron mapeados sin problemas a partir del documento de la Arquitectura.

Discusiones

Al diseñar esta capa se planteó la disyuntiva de permitir una comunicación horizontal (entre capas), vertical (entre objetos de la misma capa) o una combinación de ambas. Esto debido principalmente a que algunos diálogos de usuario, para resolver los casos de uso, requieren el uso

Página 23 de 33

de funciones de distintos servicios del sistema. Se plantearon dos opciones, o bien era el diálogo de usuario quien se encargaba de llamar a ambos servicios de sistema o se permitía encadenar dichas invocaciones. Un ejemplo de este problema se da en el momento de hacer una reserva y enviar la confirmación: para hacer la reserva se utiliza sistemaReservas, al enviar la confirmación se utiliza sistemaClientes (para obtener la dirección de correo electrónico) y sistemaMensajería (es quien envía el mail). En la implementación realizada se decidió permitir la comunicación 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 implementación debido a que la mayoría de los métodos de las clases solo realizan una invocación a métodos 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 comunicación con los sistemas externos, como ser el sistema de mensajería y el sistema de facturación, lo cual no es razonable implementarlo (conceptualmente) ni en la capa inferior (Servicio de negocio) ni en la capa superior (Diálogos de Usuario). Una opción alternativa es manejar una arquitectura de capas relajada, es decir, permitir utilizar funcionalidades de los Servicios de Negocios desde los Diálogos 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 comunicación con sistemas externos. Esta opción se descartó debido a que se optó por una arquitectura en capas estricta.

Página 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 común de manejo desde la capa de Servicios de negocio, obteniéndose la flexibilidad de variar la implementación interna de forma radical sin impactar en el resto del sistema.

Figura 21

9.1. Persistencia usando CMP

En la implementación basada en CMP se busca evitar en todo momento usar consultas SQL o alguna solución 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ó ningún 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 evaluación académica fue que se tomaron los dos extremos posibles de implementación 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 resolución de consultas sobre Entity Beans y sus

Página 25 de 33

relaciones. Por otra parte existe una fuerte limitación 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 definición 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 número único a cada reserva. Su implementación esta hecha de forma tal que su comportamiento sea el de un singleton. Pueden apreciarse de la Figura 22, en Reserva los métodos find utilizados para resolver parte de los requerimientos del sistema. A continuación 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

Página 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 definición como creación de la estructura de la BD se realiza en el deploy de la aplicación 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 abstracción 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. Diseño 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 más usuales. El diseño de la base de datos es el siguiente:

Clientes

PK,I1 ci

nombrepasswordemailtelefonomovildireccion

Habitaciones

PK,I1 numero

I2 ocupadaFK1 tipohabitacionFK1 nombrehotel

Hoteles

PK,I1 nombre

HotelTHRelacion

PK,FK1,I1 tipohabitacionPK,FK2,I1,I2 nombrehotel

Reservas

PK,I1 idreserva

I2 checkinI3 checkoutI3,I2 estadoFK1,I4 ciclienteFK2 numeroFK3 tipohabitacion

TipoHabitacion

PK,I1 nombre

detalle

ReservaAutonumerador

PK,I1 id

numeroactual

Figura 23

Página 27 de 33

Los índices fueron creados en función de las consultas que se realizan más habitualmente sobre la base, como ser la búsqueda de alternativas para un tipo de habitación, la búsqueda de una habitación disponible de un tipo en determinado hotel o la búsqueda de todas las reservas de un cliente en determinado estado en una fecha dada. Para testear la aplicación esta base fue cargada con datos de prueba. Las cantidades de tuplas cargadas para cada tabla son las siguientes:

Tabla Cantidad de Registros Clientes 20.001 Hoteles 20

TipoHabitacion 8 HotelTHRelacion 100

Habitaciones 2.000 ReservaAutonumerador 1

Reservas 189.986

9.3. Discusiones

Al realizar el diseño conceptual de esta capa, se presentó el problema de cómo 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 más fácilmente 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 identificación de un cliente, lo natural es realizarla por el nombre (no es un identificador único) o por la cédula de identidad la cual varía según el país (CI, DNI, Pasaporte, etc). Las claves no naturales no tienen problemas de contexto ni de ambigüedad, pero son más complicadas de manejar, ya que deben “arrastrar” siempre la clave junto con la información. 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 también obliga a realizar joins o duplicar información para obtener la identificación para el usuario de un objeto (si las reservas tienen el código 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 implementación realizada se utilizaron claves naturales debido a que su uso es menos complejo, más directo, las entidades y el esquema son simples y poseen un identificador único natural (Hotel-Nombre, Cliente-CI, etc).

Página 28 de 33

10. Conclusiones

Quedo comprobado que la aplicación de la metodología presentada en [2], permite a partir de la especificación de un sistema basado en componentes, realizar una rápida implementación en la plataforma J2EE del Sistema de Información. La implementación de los primeros CU, así como la interacción de las 3 primeras capas (Interfase de Usuario, UI de Diálogos de Usuario y Diálogos de Usuario) definiendo implementaciones que permitan componer y reutilizar casos de uso fue lo que llevo más tiempo. Luego de definidos estos puntos, la implementación del resto del sistema resulto muy sencilla, siguiendo los siguientes pasos:

1- Definición de la Máquina de Estados correspondiente al CU. 2- Implementación de la interfaz de usuario en paralelo con la implementación de diálogos

de Usuario y Servicios del Sistema/Negocio (Dada la implementación declarativa del servlet Despachador prácticamente no fue necesario realizar cambios a nivel de la capa UI de Diálogos de Usuario).

3- Pruebas e Integración. Resulta interesante investigar la posibilidad de automatizar la generación de clases correspondientes a la capa de Diálogos de Usuario (máquina de estado y Session Bean del diálogo) a partir de la definición de la Máquina de Estados en algún lenguaje formal, como por ejemplo UML. A sí como también en caso de incorporar metadata de la UI, la posible automatización en la generación de la misma. La aplicación de la metodología presentada en [2] en conjunto con las decisiones tomadas en la implementación, relativas a la composición de casos de uso presentadas en el presente reporte, permiten la implementación iterativa incremental de un Sistema de Información, donde la lógica de sus componentes se encuentran centralizados (a través de casos de uso que se reutilizan) y donde el Sistema mantiene características de modularización, reuso y extensibilidad propios de una arquitectura en capas.

Persistencia

En tiempos de desarrollo no se detectan grandes diferencias entre una implementación de JDBC y otra enteramente realizada con CMP 2.0, salvo en algunos casos puntuales (por ejemplo con la alta, baja y modificación de cliente). El desarrollo con CMP puede ser un método eficiente si los beans son simples. Su manejo e implementación son extremadamente sencillos, una vez adquirida cierta experiencia en el tema. Para beans más complejos, las políticas de creación y carga de la información que siguen los servidores de aplicaciones en general podrían hacer que se perjudique la performance de ejecución de manera importante. Es en esos casos cuando el desarrollo con BMP puede aumentar su importancia, aunque requiera más tiempo de implementación. 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 tecnología EJB aún impone ciertas limitaciones no despreciables al momento de tomar decisiones de diseño que contemplen requerimientos importantes de performance (si bien es de esperar que dichas limitaciones vayan desvaneciéndose en futuras especificaciones). La limitación 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 diseño de la solución planteada para buscar disponibilidad con alternativas. En la solución con JDBC se puede restringir la cantidad de búsqueda de reservas utilizando una condición sobre las fechas de

Página 29 de 33

reservas disponibles, mientras que utilizando CMP es necesario cargar una gran cantidad de Entity Beans los cuales serán procesados usando lógica Java para filtrar las fechas no validas. Esta impacto a nivel de diseño 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 habitación de un cierto tipo en un hotel para un período de un día, donde no había disponibilidad. (Hotel Edén, Superior, 30/08/2003) cmp: 8,50 jdbc: 0,26 Buscar disponibilidad con alternativas Se busco una habitación de un cierto tipo en un hotel para un período de un día, donde no había disponibilidad. Existen 14 hoteles alternativos y solo 1 donde había disponibilidad. (Hotel Edén, Suite Presidencial, 30/08/2003) cmp: 36,0 jdbc: 2,5 La diferencia de tiempo encontrada entonces en la ejecución de una transacción hace que la puesta en producción del sistema con búsqueda de alternativas implementadas con CMP no sea viable. Esto nos lleva a plantear la posibilidad de una solución a través de un sistema que utilice en algunos requerimientos CMP y en otros BMP. Luego de realizadas las implementaciones usando persistencia a través de CMP y de JDBC, llegamos a la conclusión 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 diseños de soluciones poco performantes y hasta algunos problemas en la definición de relaciones con ciclos entre los beans y encontramos que la única ventaja del uso de CMP sobre la implementación directa a través de JDBC es la abstracción de las consultas SQL propietarias de cada BD. Esta limitante por otra parte puede ser evitada en caso de utilizar algún 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 especificación. 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) podría generar tiempos más favorables de respuesta promedio que una implementación basada en JDBC (o utilizando un framework de persistencia sin soporte de caché), quedando planteada esta interrogante para trabajos futuros.

Página 30 de 33

11. Referencias

[1] – J. Cheesman, J. Daniels. UML Components, Addison Wesley, 2002. [2] - D. Perovich, L. Rodríguez, A. Vignaga. “Arquitectura de Sistemas de Información

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 Gestión

Hotelera. Reporte Técnico RT03-15, InCo Pedeciba, Montevideo, Uruguay, 2003. [4] - D. Di Pascua, F. Hernández, A. Mackiewicz. Caso de estudio Sistema de Gestión

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.

Página 31 de 33

Anexo: Máquinas de Estado A continuación se presenta los diagramas de máquinas 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

Página 32 de 33

Cancelar Reserva

Modificar Reserva

Página 33 de 33