Alonso

Universitat de Lleida Escola Polit` ecnica Superior Ingenier a T ecnica en Inform atica de Sistemas Trabajo de nal de carrera
Genereitor 2
Generador de c odigo J2EE
Autor: Hugo Alonso Capuz Director: Ram on B ejar Torres Septiembre de 2008
Agradecimientos
Durante la realizaci on de este proyecto, muchas han sido las personas que, de una forma u otra, me han aportado su ayuda, su apoyo y sus animos. En especial, he de dar las gracias...
...a mis padres, por brindarme la oportunidad de estudiar una carrera, por celebrar los aprobados y por comprender los suspensos, siempre con una sonrisa en los labios. ...a Andrea, por apoyarme, por animarme y por estar ah siempre que la necesitaba. ...a Ra ul, porque sin su ayuda hubiera sido mucho m as duro. ...a Juan y Nacho, por conarme la realizaci on de este proyecto y abrirme las puertas del mundo laboral. ...a Ram on, por ofrecerse a ser mi tutor y darme consejo y opini on. ...a mis compa neros de la ocina, por alegrar las ma nanas de lunes y compartir caras de sue no.
A todos vosotros... Gracias!
Indice general
I Introducci on 10
11 11 12 13 16 16 16 17 17 17 18 20 20 20 21 22 22 22 23 23 23 23 23
1. Situaci on inicial 1.1. Aplicaciones empresariales . . . . . . . . . . . . . . . . . . . . . . 1.2. Aplicaciones web . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. Ventajas perseguidas con el desarrollo de Genereitor . . . . . . . . 1.4. Requisitos de Genereitor . . . . . . . . . . . . . . . . . . . . . . . 1.4.1. Aplicaci on web . . . . . . . . . . . . . . . . . . . . . . . . 1.4.2. Conexi on a bases de datos . . . . . . . . . . . . . . . . . . 1.4.3. Integraci on de los m odulos de la empresa . . . . . . . . . 1.4.4. Tratamiento de relaciones entre entidades . . . . . . . . . 1.4.5. Interfaz intuitiva . . . . . . . . . . . . . . . . . . . . . . . 1.5. Requisitos de las aplicaciones desarrolladas con Genereitor . . . . 2. Antiguo generador 2.1. Carencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1. Relaciones entre entidades . . . . . . . . . . . . . . . . . . 2.1.2. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3. Tratamiento de errores y excepciones . . . . . . . . . . . . 2.1.4. Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.5. Soporte para librer as propias . . . . . . . . . . . . . . . . 2.1.6. Accesibilidad . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.7. Scripts de compilaci on y despliegue . . . . . . . . . . . . . 2.1.8. Estructura de proyecto obsoleta . . . . . . . . . . . . . . . 2.1.9. Integraci on con m odulos de la empresa . . . . . . . . . . . 2.1.10. Funcionalidades descartadas. . . . . . . . . . . . . . . . .
INDICE GENERAL
II
Estructura l ogica de Genereitor
25
26 27 27 28 31 31 32 34
3. Modelo de 3 capas 3.1. Arquitecturas antiguas . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1. Aplicaciones aut onomas . . . . . . . . . . . . . . . . . . . 3.1.2. Aplicaciones con conexi on a BD: 2 capas . . . . . . . . . . 3.2. Arquitectura de 3 capas. . . . . . . . . . . . . . . . . . . . . . . . 3.2.1. Funciones de cada capa . . . . . . . . . . . . . . . . . . . 3.2.2. Ventajas de la arquitectura de 3 capas . . . . . . . . . . . 4. Arquitectura J2EE 4.1. Por qu e J2EE? . . . . . . . . . . . . . . . . . . . . . . . . . . .
34 35 35 35 35 35 36 37 39 39
4.1.1. Ahorro de trabajo . . . . . . . . . . . . . . . . . . . . . . 4.1.2. Documentaci on . . . . . . . . . . . . . . . . . . . . . . . . 4.1.3. Est andar y conable . . . . . . . . . . . . . . . . . . . . . 4.1.4. Flexible . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2. Plataforma J2EE . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3. Model-View-Controller . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2. Vista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.3. Controlador . . . . . . . . . . . . . . . . . . . . . . . . . .
III
Funcionalidades de Genereitor
40
42 43 43 45 45 47 47 48 49 50 51
5. Generaci on de esqueleto 5.1. Funciones de la interfaz . . . . . . . . . . . . . . . . . . . . . . . 5.1.1. Fase 1. Generaci on de esqueleto . . . . . . . . . . . . . . . 5.2. Resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1. Ficheros properties y descriptores de despliegue. . . . . . . 5.2.2. Scripts de compilaci on . . . . . . . . . . . . . . . . . . . . 5.2.3. Capa web - Servlets (Controlador) . . . . . . . . . . . . . 5.2.4. Capa web - JSP (Vista) . . . . . . . . . . . . . . . . . . . 5.2.5. Capa de l ogica de negocio - Fachada de Componentes (Modelo) . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.6. Capa de acceso a datos - Scripts SQL . . . . . . . . . . . 5.2.7. Documento de instalaci on . . . . . . . . . . . . . . . . . . 3
INDICE GENERAL
6. Generaci on de partes de c odigo 6.1. Funciones de la interfaz . . . . . . . . . . . . . . . . . . . . . . . 6.1.1. Fase 1: Conexi on . . . . . . . . . . . . . . . . . . . . . . . 6.1.2. Fase 2: Selecci on de tabla . . . . . . . . . . . . . . . . . . 6.1.3. Fase 3: Selecci on de tablas relacionadas . . . . . . . . . . 6.1.4. Fase 4: Selecci on de campos . . . . . . . . . . . . . . . . . 6.1.5. Fase 5: Selecci on de par ametros . . . . . . . . . . . . . . . 6.2. Resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1. Capa web - JSP (Vista) . . . . . . . . . . . . . . . . . . . 6.2.2. Capa web - Servlet (Controlador) . . . . . . . . . . . . . . 6.2.3. Capa de l ogica de negocio - Fachada . . . . . . . . . . . . 6.2.4. Capa de l ogica de negocio - Componentes . . . . . . . . . 6.2.5. Capa de l ogica de negocio - Excepciones . . . . . . . . . . 6.2.6. Capa de acceso a datos - Componentes . . . . . . . . . . . 6.2.7. Capa de acceso a datos - PL/SQL . . . . . . . . . . . . . . 6.2.8. Capa de acceso a datos - Beans . . . . . . . . . . . . . . . 7. Generaci on de script para tablas maestras 7.1. Funciones de la interfaz . . . . . . . . . . . . . . . . . . . . . . . 7.1.1. Fase 1: Conexi on . . . . . . . . . . . . . . . . . . . . . . . 7.1.2. Fase 2: Selecci on de tablas . . . . . . . . . . . . . . . . . . 7.1.3. Fase 3: Selecci on de campos . . . . . . . . . . . . . . . . . 7.2. Resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.1. Script para tablas maestras . . . . . . . . . . . . . . . . .
52 52 52 53 54 54 55 58 58 62 64 65 66 67 68 71 74 74 74 75 76 78 78 82
7.2.2. Beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IV
Implementaci on de Genereitor
83
85
8. Capa web 8.1. JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85 86 93 94 95
8.1.1. Custom Tags . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.2. JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.3. CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2. Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
INDICE GENERAL
8.2.1. InicioAction.java . . . . . . . . . . . . . . . . . . . . . . . . 8.2.2. GenereitorBaseAction.java . . . . . . . . . . . . . . . . . . 8.2.3. EsqueletoAction.java . . . . . . . . . . . . . . . . . . . . . 8.2.4. CodigoAction.java . . . . . . . . . . . . . . . . . . . . . . . 8.2.5. TablasAction.java . . . . . . . . . . . . . . . . . . . . . . . 8.2.6. ServletEscuchador.java . . . . . . . . . . . . . . . . . . . .
96 96 97 97 99 99
8.3. Otros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 9. Capa de l ogica de negocio 101
9.1. Excepciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 10.Capa de acceso a datos 103
10.1. Componentes de acceso a datos . . . . . . . . . . . . . . . . . . . 103 10.2. Sistema de base de datos . . . . . . . . . . . . . . . . . . . . . . . 103 10.3. Beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Conclusi on
106
107
11.Visi on global del trabajo realizado
11.1. Cambios en Genereitor durante su desarrollo . . . . . . . . . . . . 108 11.2. Conocimientos adquiridos . . . . . . . . . . . . . . . . . . . . . . 109 11.3. Herramientas utilizadas . . . . . . . . . . . . . . . . . . . . . . . 110 11.4. Datos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . 110 12.Trabajo futuro 112
12.1. Mantenimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 12.1.1. Adici on de nuevas caracter sticas a Genereitor . . . . . . . 112 12.1.2. Mantenimiento y modicaci on de los proyectos generados. 113 12.1.3. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . 114
VI
Ap endices
115
116
A. Documento de an alisis y dise no
A.1. Descripci on y objetivos . . . . . . . . . . . . . . . . . . . . . . . . 116 A.2. Resumen ejecutivo . . . . . . . . . . . . . . . . . . . . . . . . . . 117
INDICE GENERAL
A.2.1. Data Access Layer (Capa de Acceso a Datos) . . . . . . . 117 A.2.2. Business Logic (L ogica de Negocio) . . . . . . . . . . . . . 117 A.2.3. Model-View-Controller (Modelo-Vista-Controlador) . . . 117 A.3. Sistema Actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 A.4. Identicaci on y denici on de requisitos . . . . . . . . . . . . . . . 121 A.4.1. Ambito y alcance del proyecto . . . . . . . . . . . . . . . 121 A.5. Cat alogo de requisitos del sistema . . . . . . . . . . . . . . . . . 123
A.5.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . 123 A.5.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . 124 A.6. Modelo de procesos . . . . . . . . . . . . . . . . . . . . . . . . . . 124 A.6.1. Generaci on del esqueleto . . . . . . . . . . . . . . . . . . . 124 A.6.2. Generaci on de script de tablas maestras . . . . . . . . . . 126 A.6.3. Generaci on de c odigo . . . . . . . . . . . . . . . . . . . . 127
A.7. Denici on de la arquitectura del sistema . . . . . . . . . . . . . . 131 A.7.1. Gestor de base de datos . . . . . . . . . . . . . . . . . . . 132 A.7.2. Servidor de aplicaciones . . . . . . . . . . . . . . . . . . . 132 A.8. Modelo de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 A.8.1. Consulta . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
A.8.2. Generaci on . . . . . . . . . . . . . . . . . . . . . . . . . . 134 A.9. Denici on del interfaz de usuario (prototipos) . . . . . . . . . . . 134 A.9.1. Generaci on del esqueleto . . . . . . . . . . . . . . . . . . . 135 A.9.2. Generaci on de script de tablas maestras . . . . . . . . . . 136 A.9.3. Generaci on de c odigo . . . . . . . . . . . . . . . . . . . . 139
A.10.Migraci on inicial de datos . . . . . . . . . . . . . . . . . . . . . . 144 B. Combineitor, herramienta complementaria 145
B.1. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 B.2. Ejemplo de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 B.3. Motivos de la elecci on de bash para su implementaci on . . . . . . 151 C. Tecnolog as utilizadas 152
C.1. JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 C.1.1. Alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . 153 C.2. JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
INDICE GENERAL
C.2.1. Alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . 154 C.2.2. Inconvenientes . . . . . . . . . . . . . . . . . . . . . . . . 155 C.3. Ant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
C.3.1. Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 C.3.2. Desventajas . . . . . . . . . . . . . . . . . . . . . . . . . . 156 C.3.3. Alternativas: Maven . . . . . . . . . . . . . . . . . . . . . 157 C.3.4. Motivos de la elecci on de ant . . . . . . . . . . . . . . . . 157 C.4. XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 C.4.1. Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 C.4.2. Inconvenientes . . . . . . . . . . . . . . . . . . . . . . . . 160 C.4.3. Alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . 161 C.5. Javadoc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 C.5.1. Alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Indice de guras
2.1. M etodos que implementa Genereitor para dos entidades relacionadas 21 3.1. Ejemplo de aplicaci on de 3 capas y 2 niveles . . . . . . . . . . . . 3.2. Estructura f sica de Genereitor. . . . . . . . . . . . . . . . . . . . 3.3. Esquema de la arquitectura monocapa con mainframe y terminales tontas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4. Esquema de la arquitectura de 2 capas . . . . . . . . . . . . . . . 3.5. Esquema de la arquitectura de 3 capas . . . . . . . . . . . . . . . 4.1. Diagrama de la arquitectura J2EE . . . . . . . . . . . . . . . . . 4.2. Diagrama del MVC. . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3. Esquema de la base de datos de la aplicaci on de ejemplo ((taller)). 5.1. Arbol de directorios simplicado de una aplicaci on web. . . . . . 5.2. Ruta de los cheros .properties. . . . . . . . . . . . . . . . . . . . 5.3. Ruta de los scripts de compilaci on. . . . . . . . . . . . . . . . . . 5.4. Ruta de los servlets de un m odulo web. . . . . . . . . . . . . . . 5.5. Ruta de la parte web (interfaz) de un m odulo web. . . . . . . . . 5.6. Ruta del modelo de una aplicaci on con EJB. . . . . . . . . . . . . 5.7. Ruta de los scripts SQL. . . . . . . . . . . . . . . . . . . . . . . . 6.1. Esquema de las vistas con entidades relacionadas (amarillo) en la edici on de la principal (azul). . . . . . . . . . . . . . . . . . . . 6.2. Esquema de las vistas con entidades relacionadas (amarillo) en diferente pantalla que la principal (azul). . . . . . . . . . . . . . . 6.3. Proceso de recorte de identicadores en funciones PL/SQL . . . . 7.1. Ejemplo de tablas maestras relacionadas. . . . . . . . . . . . . . 27 27 29 29 32 36 37 41 46 46 47 48 49 50 50
57 58 69 74
INDICE DE FIGURAS
7.2. Tablas a nadidas autom aticamente por sus relaciones. . . . . . . . 7.3. Estructura l ogica de Genereitor . . . . . . . . . . . . . . . . . . . 8.1. Diversas tecnolog as utilizadas en la interfaz de Genereitor. . . . . 8.2. Reconocimiento de las peticiones del usuario por el controlador. .
76 84 87 95
A.1. P agina de conexi on del generador actual . . . . . . . . . . . . . . 119 A.2. P agina de selecci on de tabla del generador actual . . . . . . . . . 119 A.3. Error de conexi on del generador actual . . . . . . . . . . . . . . . 119 A.4. P agina de selecci on de campos y par ametros del Generador actual 120 A.5. Esquema de la arquitectura J2EE . . . . . . . . . . . . . . . . . . 122 A.6. Esquema de los procesos del Generador . . . . . . . . . . . . . . 125 A.7. Esquema de procesos de la generaci on del esqueleto . . . . . . . . 126 A.8. Esquema de procesos de la selecci on de tablas para la generaci on del script de tablas maestras . . . . . . . . . . . . . . . . . . . . . 127 A.9. Esquema de procesos de la selecci on de campos y opciones para la generaci on del script de tablas maestras . . . . . . . . . . . . . 128 A.10.Esquema de procesos de la selecci on de la tabla principal . . . . 129
A.11.Esquema de tratamiento de tablas relacionadas . . . . . . . . . . 129 A.12.Esquema de procesos de la selecci on de par ametros . . . . . . . . 131 A.13.Esquema de la arquitectura de software . . . . . . . . . . . . . . 133 A.14.Esquema de la interfaz del generador . . . . . . . . . . . . . . . . 142 A.15.Recopilaci on de los formularios de la interfaz del generador . . . 143 B.1. Proceso de combinar un chero a trozos. . . . . . . . . . . . . . . 145 B.2. Mensaje de conrmaci on del paquete de c odigo de combineitor. . 147 B.3. Lista de selecci on de los cheros a combinar. . . . . . . . . . . . 147
B.4. Di alogo de selecci on de aplicaci on enviada o no a cliente. . . . . . 149 C.1. Proceso de combinaci on de XSLT . . . . . . . . . . . . . . . . . . 159
Parte I
Introducci on
10
Cap tulo 1
Situaci on inicial
1.1. Aplicaciones empresariales
Hoy en d a cualquier empresa de cierta envergadura necesita manejar sus datos de forma sencilla, r apida y ecaz. Hace a nos, toda la informaci on se almacenaba en archivos de papel, lo que ocasionaba innidad de problemas a la hora de hacer cualquier consulta o tratamiento de datos: los archivadores de papel ocupan mucho tama no, la consulta, modicaci on o inserci on de datos cuestan mucho tiempo y el mantenimiento es complicado, al ser un soporte f sico susceptible al desgaste o a la destrucci on por accidentes (fuego, inundaciones, etc). As mismo, las copias de seguridad son complicadas de hacer, ya que duplicar todos los registros de un archivo de cierta magnitud conlleva un gran coste tanto econ omico como de tiempo, al m argen de la necesidad de disponer de espacio en otro lugar para albergar la copia. Tambi en mantener y actualizar un archivo de seguridad implica m as trabajo y m as tiempo. Con la aparici on de la inform atica estos problemas comenzaron a desaparecer. Cuando los sistemas de bases de datos se desarrollaron, se convirtieron en una ventajosa alternativa frente al tradicional soporte de papel, ofreciendo rapidez y comodidad, al tiempo que desaparec an los problemas de tama no. La cinta magn etica se convirti o en el soporte ideal para albergar copias de seguridad de bancos de datos de gran magnitud, ya que pese a su lentitud en el acceso a los datos (a un as era innitamente m as r apido que las copias en papel), eran un soporte econ omico y ecaz. Conforme la tecnolog a avanzaba, la demanda de sistemas de almacenamiento de mayor calidad y facilidad de uso increment o enormemente, y en este marco es donde surge el concepto de aplicaci on empresarial. Una aplicaci on empresarial es, a grandes rasgos, un sistema inform atico que ayuda a incrementar o controlar la productividad de una empresa. El principal objetivo de una aplicaci on empresarial es incrementar los benecios de una empresa mediante la reducci on de costes o la aceleraci on del ciclo productivo, delegando a una m aquina la realizaci on de tareas que antes requer an del trabajo de varios empleados.
11
INICIAL CAP ITULO 1. SITUACION
1.2.
Aplicaciones web
La implementaci on de una aplicaci on empresarial se puede enfocar de diversas maneras, pero actualmente las aplicaciones web son la forma m as eciente de llevar a cabo un proyecto de este tipo. Una denici on de aplicaci on web podr a ser un sistema a los que los usuarios acceden a trav es de un servidor web mediante Internet o una intranet1 , utilizando para ello un navegador. La aplicaci on est a codicada en lenguajes soportados por los navegadores web (HTML, JavaScript, etc). Este tipo de aplicaciones son populares debido a lo pr actico del uso del navegador web como cliente ligero, puesto que pr acticamente todos los sistemas inform aticos cuentan en su conguraci on por defecto con uno, lo que supone una gran ventaja a la hora de llevar a cabo actualizaciones o mantenimiento de la aplicaci on, puesto que que estas tareas se llevan a cabo en el servidor. Esto presenta grandes ventajas: Las modicaciones no tienen que ser instaladas y ejecutadas en cada uno de los clientes o usuarios, lo que simplica enormemente las tareas de actualizaci on. Es sencillo implementar nuevas funcionalidades (tales como procesadores de texto, clientes de correo o motores de b usqueda) e integrarlas en la aplicaci on. No se necesita espacio en disco exclusivo para la aplicaci on en la m aquina del cliente, dado que no existe ning un proceso de instalaci on. Proporciona una independencia de plataforma respecto del cliente, no importando el sistema operativo o el navegador que este utilice2 . Por contra, tambi en adolecen de una serie de inconvenientes respecto de las aplicaciones de escritorio : Dependen de una conexi on con Internet o la intranet donde se aloja la aplicaci on, por lo tanto si esta conexi on se ve interrumpida, la aplicaci on no es accesible.
1 Una intranet es un conjunto de contenidos compartidos por una organizaci on, o un grupo determinado de componentes de esta. Es una potente herramienta que permite divulgar informaci on de la compa n a a sus empleados con efectividad, estando estos informados de las u ltimas novedades y datos de la organizaci on. Su funci on principal es proveer l ogica de negocios para aplicaciones de captura, informes y consultas con el n de facilitar la producci on de los grupos de trabajo. Tambi en es un importante medio de difusi on interna de la informaci on propia de la compa n a. 2 Aunque una aplicaci on web proporciona independencia de plataforma, una implementaci on inconsistente de HTML, CSS, DOM u otras especicaciones del navegador puede interferir en el funcionamiento de la aplicaci on. Adem as, las caracter sticas propias de los navegadores, tales como la posibilidad de modicar el tama no de fuente o deshabilitar la ejecuci on de scripts, pueden afectar a su funcionamiento.
12
Las funciones de interfaz que puede ofrecer un navegador web son mucho m as limitadas que aquellas de las que se disponen en una aplicaci on de escritorio. Por ejemplo, la caracter stica arrastrar y soltar, aunque es posible disponer de ella en una aplicaci on web, es mucho m as dif cil de implementar que en una aplicaci on de escritorio. La amplia difusi on de la que gozan las aplicaciones de escritorio en ciertos campos (e.g. tareas de om atica) supone una traba para las aplicaciones web de este tipo, ya que es complicado ofrecer compatibilidad con los contenidos creados inicialmente con aquellas. Una aplicaci on web generalmente contiene elementos que permiten interactividad entre el usuario y la informaci on, tales como el acceso a bases de datos o la cumplimentaci on de formularios.
1.3.
Ventajas perseguidas con el desarrollo de Genereitor
Las soluciones de software empresarial ofrecidas por los fabricantes de forma ((gen erica)) no siempre satisfacen las necesidades de las empresas, hecho que se acrecenta en corporaciones de cierta magnitud. Es por esto que muchas veces se opta por prescindir de estas soluciones e implementar las propias, de forma personalizada para que cubran exactamente las necesidades de cada caso. As , aparecen empresas dedicadas a desarrollar soluciones inform aticas personalizadas para cada cliente, de forma que tras un estudio de las necesidades y los requisitos del cliente, se le ofrezca un producto totalmente personalizado y adecuado a su negocio. Las ventajas de una aplicaci on personalizada frente a un paquete de f abrica son innumerables, dado que desde el principio del desarrollo del producto se tiene en cuenta la situaci on espec ca del cliente a quien va dirigida, en lugar de tener que usar un paquete prefabricado y aprovechar las caracter sticas que le sean u tiles a la empresa. En muchas ocasiones el uso de estos paquetes provoca, aparte de que muchas de las funciones queden desaprovechadas, que la propia empresa tenga que modicar su metodolog a de trabajo para adaptarse al software de gesti on. Comex Grupo Ib erica es una empresa del sector de las TIC, y uno de sus cometidos es el desarrollo de aplicaciones empresariales a medida. Desarrollar una aplicaci on de este tipo requiere invertir mucho tiempo y esfuerzo, lo que en consecuencia deriva en dos de los grandes inconvenientes de las soluciones de software a medida: el tiempo de desarrollo y derivado de esto, el precio nal del producto. Con Genereitor se persiguen las siguientes metas: Ahorro de tiempo. Si se dispone de una aplicaci on a medio hacer y acorde con las necesidades y caracter sticas del proyecto al que se enfrenta el equipo de desarrollo, la fase inicial de la implementaci on es mucho m as directa.
13
Al disponer ya de versiones ((primitivas)) de todos los niveles de la aplicaci on, desde interfaz web hasta m etodos de acceso a datos, el desarrollo comienza con la implementaci on de las partes espec cas de la aplicaci on, haciendo uso de la pericia y creatividad de los programadores para tareas espec cas de cada proyecto que dicilmente podr an ser automatizables. Optimizaci on del c odigo. Delegando en Genereitor la implementaci on de las bases de un proyecto, se garantizan unos cimientos s olidos, ya que el c odigo generado se basar a en unas plantillas que han sido revisadas minuciosamente, y que conforme se vayan descubriendo fallos en las mismas, se implementen nuevas mejoras o se mejore su eciencia, estos se incorporar an a todos los proyectos. Al trabajar siempre sobre bases similares, se garantiza que el c odigo generado sea revisado indirectamente muchas m as veces que el que pueda implementar una persona, por lo que los fallos se detectar an mucho antes. Homogeneidad dentro del proyecto. En la implementaci on de proyectos de cierta envergadura es normal que trabajen varias personas, que pueden tener diferentes costumbres a la hora de programar. Mientras uno describa los m etodos con nombres m as descriptivos, otro lo har a con literales m as concisos y abreviados. Esta situaci on se convierte en un problema a la hora de realizar el mantenimiento o la resoluci on de incidencias de un proyecto, puesto que se entremezclan los diferentes criterios de los distintos programadores que han implementado las diferentes partes de la aplicaci on, teniendo que consultar c omo se ha llamado a cada m etodo o, en el peor de los casos, modicar los nombres de estos m etodos con las consecuencias que esto puede acarrear, como que otras partes del proyecto dejen de funcionar correctamente. Genereitor proporciona un u nico criterio para el nombrado de variables, constantes, m etodos, identicadores de campos en los formularios web, etc., de forma que el mantenimiento o la implementaci on de funciones nuevas es m as c omodo, puesto que el programador siempre va a conocer c omo se han nombrado los m etodos o los campos del formulario que tiene que utilizar, sin necesidad de consultarlo en la documentaci on o en la especicaci on de la clase. Homogeneidad entre proyectos. El uso de Genereitor implica que todos los proyectos que se desarrollen con su asistencia van a tener la misma estructura, tanto a nivel l ogico como de directorios, lo que permite agilizar el trabajo al programador que haya adquirido un m nimo de costumbre, puesto que no tendr a que buscar por el arbol de directorios d onde est a cierto componente o par ametro de conguraci on: siempre estar an en el mismo lugar. M as adelante se detallar a esta estructura de directorios. Documentaci on. En el ambito empresarial, el desarrollo de las aplicaciones siempre se ve obstaculizado por las prisas. Perder m as tiempo de la cuenta en el desarrollo de un proyecto signica disminuir el m argen de benecios, y a consecuencia de esto los plazos suelen ser muy ajustados. Por esta raz on, nunca suele haber una buena documentaci on para cada aplicaci on que se implementa, puesto que siempre hay cosas m as urgentes en las que emplear el tiempo. 14
As , Genereitor ofrece en el c odigo generado comentarios explicativos de las partes menos claras, as como notas en formato Javadoc para la generaci on autom atica de documentaci on, que podr a ser consultada tanto v a web (de forma similar a la consulta de las APIs de J2EE en la p agina de Sun) como en las notas emergentes de los diferentes entornos integrados de desarrollo que se utilizan (NetBeans, Oracle Jdeveloper, etc). Evidentemente no es posible ofrecer de forma autom atica una explicaci on aclarativa del funcionamiento y la nalidad de cada m etodo implementado, pero s se ofrecen las bases de esta documentaci on, de manera que el programador pueda rellenar en el c odigo de forma breve las funciones que crea convenientes, obteniendo en poco tiempo y sobre la marcha una documentaci on completa que ayude a quien en un futuro haya de realizar un mantenimiento de la aplicaci on. Un ejemplo de la documentaci on ofrecida podr a ser el siguiente:
1 2 3 4 5 6 7 8 9
/* * * * @param conn Connection * @param filtro Vehiculo * @param orderBy String * @return com . comex . common . bean . BaseBeanSet * @throws java . sql . SQLException */ public static BaseBeanSet g e t L i s t a V e h i c u l o s ( Connec ...
A partir de estos comentarios, Javadoc es capaz de generar la documentaci on necesaria. La nalidad de Genereitor consiste, a grandes rasgos, en proporcionar al desarrollador la estructura de la aplicaci on totalmente personalizada conforme a los requisitos del proyecto (nombre de la aplicaci on y los paquetes y clases que la componen, adaptaci on conforme al servidor de aplicaciones utilizado y sistema de bases de datos sobre el que operar a), ya preparada para comenzar el desarrollo, evitando as la tarea de crear dicha estructura a mano. As mismo, se proveer an scripts de compilaci on para la herramienta ant conforme a los diferentes componentes, dependencias y librer as del proyecto. Se proporcionar an dos tipos de scripts: Scripts para desarrollo. Scripts para preproducci on y producci on, orientados a la compilaci on y despliegue en los servidores del cliente. Tambi en se proporcionan, para cada entidad de la base de datos, paquetes que contendr an el c odigo fuente correspondiente a todas las capas de la aplicaci on (tanto capa de presentaci on como l ogica de negocio), que podr an ser insertadas en la aplicaci on como si de m odulos se tratase, de manera que se puedan a nadir a la aplicaci on las funciones correspondientes a cada entidad de forma progresiva conforme avance la implementaci on. La conjunci on de la estructura b asica generada al principio con los m odulos creados a posteriori dar an como resultado una aplicaci on web completa que, 15
aunque de forma b asica y primitiva, ser a totalmente funcional, incluyendo una rudimentaria interfaz web y funciones de lectura, inserci on, modicaci on y borrado de todo tipo de entidades existentes en la base de datos. As , el programador obtiene una aplicaci on que ya funciona sin tocar una sola l nea de c odigo, sobre la que comenzar a trabajar. Evidentemente esto supone un ahorro de tiempo enorme comparado con lo que costar a empezar el proyecto desde cero, teniendo que implementar todo a mano.
1.4.
Requisitos de Genereitor
Genereitor es una herramienta de generaci on de aplicaciones web autom atica, que mediante la conexi on a una base de datos previamente implementada y los requisitos de la aplicaci on a generar es capaz de devolver al programador dicha aplicaci on en una fase muy temprana del desarrollo, aunque completamente funcional. As , los requisitos b asicos son los que se listan a continuaci on:
1.4.1.
Aplicaci on web
Genereitor se implementar a como una aplicaci on web, cuyo acceso se efect ue mediante un navegador web est andar. Aunque no es indispensable, se ha decidido implementar mediante la tecnolog a J2EE por diversos motivos: Es la tecnolog a que se utilizar a obligatoriamente para las aplicaciones generadas con Genereitor, por lo que servir a de toma de contacto, aprendizaje y experiencia para el posterior desarrollo de las plantillas que generar an dichas aplicaciones. Es una tecnolog a madura y ampliamente extendida en el campo de las aplicaciones web, ofrece una estructura s olida y modular y dispone de multitud de APIs y componentes a disposici on del programador, de forma que ahorra mucho trabajo al no tener que implementar dichos componentes, puesto que est an integrados en el servidor de aplicaciones. Su aprendizaje no es excesivamente dif cil, por lo que se preere a otras tecnolog as m as complicadas. Es una tecnolog a libre y puede ser desarrollada con herramientas completamente gratu tas, lo que supone una ventaja a la hora de incorporar Genereitor a producci on, ya que se evitan gastos de licencias de uso que se producen al utilizar otras tecnolog as tales como .Net.
1.4.2.
Conexi on a bases de datos
La herramienta ha de ser capaz de generar aplicaciones adaptadas a diversos sistemas de bases de datos, que variar an de un proyecto a otro. Es por esto que debe ser capaz de manejar ecientemente y generar las capas de acceso a datos para la base de datos contra la que se apoyar a la aplicaci on a generar. 16
Inicialmente, los sistemas de bases de datos soportados son: Oracle 9 PostgreSQL MySQL Microsoft SQLServer HSQLDB
1.4.3.
Integraci on de los m odulos de la empresa
En la empresa se utilizan diversos m odulos que han sido desarrollados a lo largo del tiempo y que ofrecen funcionalidades espec cas a los proyectos, tales como com.comex.cms, que proporciona un sistema de gesti on de contenidos, com.comex.xml que maneja el env o y recepci on de mensajes mediante XML o com.comex.usuarios, que da soporte para la gesti on de usuarios, perles y grupos a una aplicaci on web. Genereitor ser a capaz de integrar, bajo demanda del programador, estos m odulos a la aplicaci on a generar, personalizando su comportamiento y modicando los cheros de conguraci on para compilar autom aticamente los cheros fuente de dichos m odulos.
1.4.4.
Tratamiento de relaciones entre entidades
Genereitor ha de ser capaz de averiguar las relaciones que tienen las diferentes entidades de una base de datos, informando de ello al programador y ofreciendo la posibilidad de ser tratadas en la generaci on de aplicaciones, de forma que dichas aplicaciones ya incorporen en su l ogica el tratamiento de las claves ajenas.
1.4.5.
Interfaz intuitiva
Genereitor contar a con una interfaz clara e intuitiva, con literales que identiquen claramente la funci on de cada uno de los componentes que forman parte de esta. Cuando, por cuestiones de espacio, sea dif cil ofrecer literales demasiado espec cos, se proveer an de explicaciones mediante etiquetas otantes al pasar el puntero del rat on sobre dicho literal. Asimismo, el manejo de errores ser a capaz de informar al usuario de cu ando ha ocurrido alg un fallo en la ejecuci on del programa o la introducci on de datos, indicando la causa del mismo.
17
1.5.
Requisitos de las aplicaciones desarrolladas con Genereitor
Las aplicaciones desarrolladas con Genereitor ser an aplicaciones web implementadas en J2EE[1], cuya estructura seguir a las recomendaciones de las Java BluePrints[2]. Permitir an tanto la consulta como la modicaci on de los datos almacenados en una base de datos, que podr a estar soportada por diferentes servidores de bases de datos. Seg un las necesidades del proyecto, la capa de aplicaci on podr a estar implementada mediante EJBs o POJOs, y en consecuencia ser an desplegables en diversos servidores de aplicaciones, con o sin contenedor de EJB. Las interfaces generadas ser an accesibles a nivel AA[3], aunque se ofrecer an soluciones m as ecientes cuando este nivel de accesibilidad no sea necesario. Ser an compatibles con los m odulos desarrollados en la empresa (com.comex.common, com.comex.tablasmaestras, com.comex.cms, com.comex.usuarios, com.comex.xml, etc). Han de ser parametrizables en cuanto al despliegue en diferentes entornos, que corresponder an a las distintas etapas de desarrollo de la aplicaci on. Los scripts de despliegue proporcionados aceptar an par ametros que modicar an el despliegue seg un se encuentre el proyecto en desarrollo, preproducci on o producci on. El tratamiento de archivos binarios se llevar a a cabo mediante streaming, tanto para la carga como la descarga de grandes binarios al servidor de bases de datos, lo que evitar a la saturaci on del servidor de aplicaciones por falta de memoria, a la vez que facilita el manejo de archivos multimedia en caso de que se quiera a nadir un reproductor de medios. Seguir an los siguientes patrones de desarrollo: Modelo-Vista-Controlador. Modelo-Vista-Controlador (Model-View-Controller) es un patr on de desarrollo que separa la parte l ogica de una aplicaci on de su presentaci on. B asicamente sirve para separar el lenguaje de programaci on del HTML lo m aximo posible y para poder reutilizar componentes f acilmente. El Modelo representa las estructuras de datos. T picamente el modelo de clases contendr a funciones para consultar, insertar y actualizar informaci on de la base de datos. La Vista es la informaci on presentada al usuario. Una vista puede ser una p agina web o una parte de una p agina. El Controlador act ua como intermediario entre el Modelo, la Vista y cualquier otro recurso necesario para generar una p agina. Filtro. El patr on ltro consiste en el uso de objetos con atributos incompletos que no ser an v alidos para el tratamiento de datos, pero que se utilizan para la recogida de datos en formularios y en las operaciones de l ogica de 18
la interfaz, que mediante la consulta al modelo de datos completar an los atributos del ltro para crear un objeto v alido. Facade. La fachada se usa para proporcionar una interfaz para la capa de l ogica de negocio, de forma que los dem as componentes de la aplicaci on accedan a dicha capa a trav es de la fachada, en lugar de hacerlo directamente. Para ello, se implementa un bean de fachada, que representa los componentes de la l ogica de alto nivel, que a su vez interactuar an con los componentes de bajo nivel. El uso de fachada repercute en una mayor facilidad de uso y legibilidad de la capa de l ogica de la aplicaci on, al tiempo que exibiliza el desarrollo. Singleton. Este patr on restringe la creaci on de objetos pertenecientes a una clase o el valor de un tipo a un u nico objeto. Su intenci on consiste en garantizar que una clase s olo tenga una instancia y proporcionar un punto de acceso global a ella. El patr on singleton se implementa creando en nuestra clase un m etodo que crea una instancia del objeto s olo si todav a no existe alguna. Para asegurar que la clase no puede ser instanciada nuevamente se regula el alcance del constructor. ServiceLocator. Los componentes J2EE se vale de APIs que proporcionan diferentes servicios, tales como interfaces EJB, DataSources, conexiones, etc. El patr on ServiceLocator permite proveer a la aplicaci on de un controlador centralizado que permite manejar todos estos servicios desde un mismo componente, evitando el tener que buscar a lo largo de toda la aplicaci on los servicios necesarios en cada momento.
19
Cap tulo 2
Antiguo generador
Antes del desarrollo de Genereitor ya exist a una herramienta de caracter sticas similares, pero sus funciones era muy limitadas. En lugar de generarse un proyecto completo y funcional, se creaban u nicamente los cimientos de varios cheros de c odigo, que luego habr an de ser completados y adaptados por el programador. La antig uedad de esta herramienta y la dicultad de su mantenimiento propici o que cayera progresivamente en desuso, puesto que el ahorro de tiempo que supon a al principio fue mermando con el paso del tiempo, al evolucionar las caracter sticas y los requisitos de los proyectos demandados por los clientes. La falta de mantenimiento regular se tradujo en que, actualmente, cuesta m as arreglar y adaptar el c odigo generado que implementarlo desde cero o reciclar un proyecto existente y adaptarlo a mano. Adem as, las escasas funciones que a un son aprovechables no compensan con el esfuerzo invertido en la adaptaci on a los nuevos m etodos de trabajo. A continuaci on se detallan los problemas m as importantes de los que adolece el generador actual.
2.1.
2.1.1.
Carencias
Relaciones entre entidades
La caracter stica principal de las bases de datos relacionales es, precisamente, las relaciones entre las diferentes entidades de la misma. Estos lazos entre las entidades se representan mediante claves ajenas, que son caracter sticas comunes y compartidas por dos entidades. As , es ineludible el tratamiento de estas relaciones de manera eciente por cualquier aplicaci on que explote una base de datos, siempre teniendo en cuenta las restricciones de esta, de forma que se mantenga la consistencia de la informaci on almacenada.
20
CAP ITULO 2. ANTIGUO GENERADOR
El antiguo generador s olo ten a en cuenta las caracter sticas propias de cada entidad, es decir, s olo proporcionaba la l ogica para el tratamiento de los campos propios de cada tabla, de manera que las relaciones con otras tablas hab a que hacerlas a mano, tarea que conlleva tiempo y esfuerzo. Otro inconveniente es que, al tenerlas que hacer una por una, el c odigo implementado por el programador es susceptible de fallos que hagan que la aplicaci on no funcione correctamente en determinadas ocasiones que, por extra nas o inusuales, no se hayan tenido en cuenta inicialmente por el programador, o que en el peor de los casos, pongan en peligro la integridad de la base de datos si esta no est a perfectamente dise nada. Por esto, Genereitor tiene en cuenta autom aticamente las relaciones entre tablas, ofreciendo la l ogica para el tratamiento de las mismas, de la forma que indica la gura 2.1.
Figura 2.1: M etodos que implementa Genereitor para dos entidades relacionadas
2.1.2.
Interfaz
En el desarrollo del antiguo generador de c odigo se descuid o demasiado el aspecto visual de la herramienta, ofreciendo una interfaz pobre y poco intuitiva, de forma que un programador sin experiencia en el uso de la herramienta precisaba de explicaciones por parte de los jefes de proyecto acerca de su funcionamiento. Genereitor persigue la facilidad de uso, proveyendo a la interfaz de t tulos y literales lo m as claros y concisos posible, y mostrando mediante tooltips 1 que clariquen la funci on que ofrecen las opciones que no resulten triviales en la presentaci on.
1 Letreros
que aparecen al situar el cursor sobre una opci on determinada
21
2.1.3.
Tratamiento de errores y excepciones
Otro defecto del que adolece el generador antiguo es el tratamiento de excepciones y errores en su funcionamiento. Cuando existe alg un problema, no se informa al usuario de qu e es lo que falla o cual puede ser la causa del problema. Este fallo se aprecia acusadamente en caso de errores de conexi on a la base de datos, donde simplemente se vuelca en pantalla el contenido de la excepci on generada, que generalmente suele ser poco aclarativa. En Genereitor se ha implementa un sistema de noticaci on de errores, mediante una caja de mensajes en la parte superior de la interfaz, de forma que en caso de ocurrir cualquier error, el usuario sea informado de la causa de una forma clara y concisa, de manera que sea f acilmente identicable.
2.1.4.
Restricciones
En el dise no de la base de datos siempre se tienen en cuenta diversas restricciones que deben cumplir las entidades que se van a almacenar, tales como campos obligatorios, longitud de cadenas de caracteres o rango m aximo de campos num ericos. Pero es posible que interese ampliar estas restricciones o a nadir nuevas en ciertos casos, sin modicar la base de datos, sino a nivel de aplicaci on. El generador antiguo no era capaz de aplicar restricciones al manejo de la base de datos2 , tarea que de ser necesaria, ten a que ser implementada a mano. Se ha decidido automatizar la adici on de estas restricciones, de manera que se puedan modicar longitud m axima de campos en los formularios de la aplicaci on a generar, as como a nadir la obligatoriedad de contener valores no nulos a cualquier campo, aunque el dise no de la base de datos s lo permita.
2.1.5.
Soporte para librer as propias
En la empresa se han desarrollado a lo largo del tiempo una serie de librer as y m odulos de uso com un, que proporcionan funciones y herramientas utilizadas por la mayor a de los proyectos que se desarrollan, tales como gesti on de tablas maestras, gesti on de usuarios, perles y grupos, gesti on de contenidos, etc. m as adelante se explicar an en detalle las funciones de estos m odulos. Evidentemente es necesario adaptar el c odigo para el uso de estas librer as, tarea que actualmente se hace a mano. En el nuevo generador se permitir a elegir en la fase de creaci on de la estructura del proyecto qu e m odulos van a ser necesarios para la aplicaci on, de manera que quede disponible todo el abanico de opciones que ofrece cada una de ellos. Tambi en se modicar an los scripts de compilaci on y despliegue para compilar autom aticamente estos m odulos a la vez que el proyecto a desarrollar.
restricciones que se pueden aplicar ser an siempre a nivel de la aplicaci on a generar, nunca se modicar an las de la propia base de datos desde un generador autom atico.
2 Las
22
2.1.6.
Accesibilidad
Las pocas partes de la interfaz web que proporciona el generador antiguo basan parte de su funcionamiento en JavaScript. Ahora se desea que las aplicaciones desarrolladas sean accesibles, por lo que el uso de JavaScript est a vetado. Por esto, Genereitor ofrecer a alternativas accesibles en forma de comentarios en el c odigo generado, dejando tambi en las funciones JavaScript para que el programador elija la que m as convenga seg un los requisitos del cliente.
2.1.7.
Scripts de compilaci on y despliegue
Una de las tareas m as tediosas a la hora de comenzar la implementaci on de una aplicaci on es confeccionar los scripts de compilaci on. puesto que son de elaboraci on muy delicada. En el desarrollo de proyectos J2EE utilizaremos para esta tarea la herramienta ant que, al ser multiplataforma, proporciona ventajas sobre otras herramientas similares tales como Makele3 . Con Genereitor se ofrecer an autom aticamente estos scripts, personalizados de acuerdo a las caracter sticas del proyecto, m odulos y librer as utilizados y aplicaciones web que contiene.
2.1.8.
Estructura de proyecto obsoleta
La funci on de generaci on de estructura de proyecto (esqueleto) del generador antiguo devuelve un paquete cuya organizaci on no se corresponde con los requisitos actuales de desarrollo de aplicaciones J2EE, por lo que el programador ha de reorganizar los cheros y directorios a mano para adaptarlos al esquema v alido. Dicho esquema v alido es el aconsejado en las Java BluePrints[2].
2.1.9.
Integraci on con m odulos de la empresa
En la empresa se han desarrollado a lo largo del tiempo una serie de m odulos que ofrecen diversas funcionalidades a las aplicaciones desarrolladas, tales como la gesti on de tablas maestras, gesti on de contenidos, soporte para usuarios, grupos y perles, etc. El generador antiguo no ofrece soporte para estos m odulos, pero Genereitor contemplar a su integraci on opcional en las aplicaciones desarrolladas con el, y en caso de seleccionarse se crear an los cheros espec cos de dichos m odulos, de manera que las aplicaciones puedan disponer de dichas funcionalidades.
2.1.10.
Funcionalidades descartadas.
Con el paso del tiempo, hay tecnolog as que quedan obsoletas y son sustitu das por otras m as ecientes, o simplemente se decide en un momento dado apostar por alternativas que proporcionen m as ventajas respecto a las actuales.
3 En
C.3 en la p agina 155 se detallan las caracter sticas de la herramienta ant.
23
En generador antiguo ofrece soporte para Struts, que ya no se utiliza en la empresa y por lo tanto ser a descartada. Tambi en utiliza plantillas JSP para generar los diversos cheros de c odigo fuente, mientras que Genereitor utilizar a plantillas XSL4 .
4 En C.4 en la p agina 158 se detallan las caracter sticas de XML/XSLT y las ventajas que tiene frente a otros sistemas.
24
Parte II
Estructura l ogica de Genereitor
25
Cap tulo 3
Modelo de 3 capas
Antes de comenzar a analizar las diferentes arquitecturas disponibles, conviene realizar una peque na aclaraci on. No se deben confundir los t erminos capa y nivel: Las capas hacen referencia a la estructura l ogica de la aplicaci on, que repercutir a, entre otras cosas, en su modularidad y escalabilidad. Los niveles por contra, se nalan la estructura f sica sobre la que se despliega la aplicaci on, es decir, en cuantas m aquinas corre. Dependiendo de la envergadura del proyecto, podemos encontrarnos aplicaciones peque nas que est en implementadas con 3 capas, pero s olo 2 niveles, por ejemplo en la gura 3.1 en la p agina siguiente se muestra la distribuci on f sica de una aplicaci on de 3 capas, cuyas capas de acceso a datos y l ogica de negocio corren bajo la misma m aquina. Tambi en se puede dar el caso en que una misma m aquina soporte la capa de l ogica de negocio y la capa cliente, o que todas las capas se alojen en el mismo servidor. Por otro lado, no es raro que, en aplicaciones de gran envergadura, los servidores de bases de datos se implementen en cl usteres, es decir, varias m aquinas que, por computaci on distribu da, ofrecen la misma funci on y se reparten la carga de trabajo y la capacidad de almacenamiento. En caso de Genereitor, se trata de una aplicaci on de 3 capas y 3 niveles, ya que tanto la l ogica de negocio como el cliente se encontrar an en m aquinas separadas. El caso ((especial)) de Genereitor es que no trabajar a sobre una base de datos en particular, sino que est a dise nado para utilizar diversos sistemas de bases de datos, que usualmente se alojar an en servidores diferentes, por lo que incluso se podr a considerar como una aplicaci on de 4, 5 o incluso m as niveles. En la gura 3.2 en la p agina siguiente se ilustra este ejemplo.
26
CAP ITULO 3. MODELO DE 3 CAPAS
Figura 3.1: Ejemplo de aplicaci on de 3 capas y 2 niveles
Figura 3.2: Estructura f sica de Genereitor.
3.1.
Arquitecturas antiguas
Antes de analizar el modelo de arquitectura utilizado para la implementaci on de Genereitor se dar a un vistazo a las caracter sticas de las arquitecturas predecesoras, comentando sus ventajas e inconvenientes.
3.1.1.
Aplicaciones aut onomas
Una aplicaci on aut onoma es aquella cuya arquitectura est a compuesta por una sola capa, que aglutina la interfaz de usuario, la l ogica de tratamiento
27
de datos y el almacenamiento de estos. Las caracter sticas de este modelo de aplicaciones son las siguientes: Su ejecuci on no depende de otras aplicaciones, aunque puede existir integraci on entre varias aplicaciones. Se encuentra almacenada en el disco duro del usuario. Su interfaz gr aca est a formada por ventanas de aplicaci on. Cuando el usuario cierra la ventana, la aplicaci on naliza su ejecuci on. No tienen restricciones de seguridad, pudiendo la aplicaci on acceder al disco duro del usuario y establecer conexiones de red. Este dise no arcaico conlleva gran cantidad de inconvenientes: En cada sistema operativo se ejecuta de forma diferente, por lo que no hay compatibilidad multiplataforma. Problemas de integraci on en sistemas software complejos, tales como los sistemas de gesti on de una empresa. Problemas de integraci on en sistemas de informaci on consistentes en varias aplicaciones. Problemas de escalabilidad, tanto a nivel de almacenamiento como de adici on de nuevas funciones. Otro planteamiento de esta estructura monocapa es aquel consistente en un mainframe, un gran ordenador central que soporta todo el peso de la aplicaci on, y una serie de terminales tontos, m aquinas que no realizan ning un proceso y que simplemente tienen la tarea de servir de presentaci on de la interfaz al usuario. Este planteamiento se representa en la gura 3.3 en la p agina siguiente. A un as , tanto la l ogica de la aplicaci on, el acceso a datos y la presetaci on de la informaci on estaba completamente implementada en un s olo bloque monol tico de software. Cualquier modicaci on sobre la aplicaci on requer a modicar la totalidad de este u nico bloque. Un avance sobre este modelo fue realizado a partir de bases de datos basadas en servidores de archivos. En este caso, la base de datos consiste en uno o m as archivos reconocibles por el sistema operativo. En esta arquitectura, el programa que permite el acceso y administraci on de la base de datos debe estar muy estrechamente unido a la aplicaci on cliente.
3.1.2.
Aplicaciones con conexi on a BD: 2 capas
Un avance m as a la arquitectura anterior consiste en dividir los sistemas de una sola capa en dos capas bien diferenciadas. Es lo que se conoce como arquitectura cliente-servidor.
28
Figura 3.3: Esquema de la arquitectura monocapa con mainframe y terminales tontas
Estas aplicaciones est an compuestas por dos capas1 , tal como se muestra en la gura 3.4: Front-end: es la capa donde el usuario interact ua con su m aquina y que, generalmente, aglutina toda la l ogica de negocio. Back-end: es la capa de acceso a datos, cuya funci on la realiza un servidor de bases de datos y reside en un servidor central bajo un entorno controlado.
Figura 3.4: Esquema de la arquitectura de 2 capas
Uno de los problemas en este tipod e arquitecturas es la dicultad de manipular los cambios en la capa que interact ua con el cliente. En estos casos, varias estaciones de trabajo clientes necesitar an ser actualizadas con una nueva versi on de la aplicaci on del cliente simult aneamente al cambio en la base de datos. Esta
1 Es importante no confundir esta arquitectura con la del mainframe monocapa. En la arquitectura de 2 capas, la l ogica de la aplicaci on reside en la capa cliente (front-end), que se ejecuta en cada m aquina cliente. En la estructura anteriormente mencionada, las estaciones de trabajo son u nicamente dispositivos de entrada (teclado, rat on) y salida (pantalla) de informaci on, no realizando estos ninguna tarea relacionada con la aplicaci on, m as que la de meros interfaces.
29
generalmente no es una tarea sencilla, sobre todo si las aplicaciones cliente est an geogr acamente dispersas. Otro problema es la dicultad de compartir procesos comunes. Tras largas horas de trabajo frente a la m aquina para lograr un proceso en particular, este c odigo es dif cilmente reutilizable en otras aplicaciones. Un problema m as es la seguridad. Esta puede ser establecida en cualquera de las dos capas, pero cada una tiene sus limitaciones. La primera soluci on consiste en dar privilegios a cada uno de los objetos que componen la base de datos y a los usuarios. Sin embargo, las corporaciones no requieren s olo asegurar qu e datos pueden ser actualizados o accedidos, sino de qu e manera. En cuanto al segundo punto, que es el m as usado, aunque el usuario puede acceder a la base de datos con su identicaci on, tiene dos problemas: Dado que ninguno de los objetos en la base de datos es seguro, cualquier usuario puede tener acceso total a la misma con alguna aplicaci on de front-end. La implantaci on de la seguridad deber a ser desarrollada, probada y mantenida en absolutamente toda la red, sin importar d onde se encuentren las estaciones cliente. Otros inconvenientes son: Los servidores de bases de datos no proporcionan un lenguaje de programaci on completo 2 , con control de ujo, y los procedimientos almacenados3 , aunque ayudan, no son la soluci on. Los datos no est an encapsulados, por lo que sigue siendo necesario que el programador de las aplicaciones de los clientes realice tareas de control de integridad de los datos. No resulta f acil realizar cambios en la estructura de una base de datos de la que dependen varias aplicaciones. A medida que el negocio crece y el n umero de usuarios simult aneos del sistema aumenta, se complican las opciones de escalabilidad del sistema. Aplicaciones de 2 capas funcionan perfectamente en entornos peque nos, pero no son capaces de acompa nar un gran crecimiento del negocio. Las actualizaciones de la aplicaci on cliente se han de distribuir entre todos los usuarios, que deber an realizar una instalaci on de la nueva versi on del producto en sus m aquinas. En sistemas con muchos usuarios, esta tarea ser a costosa a nivel tanto econ omico como temporal.
2 Para suplir esta carencia, los diversos sistemas de bases de datos est an desarrollando sus propios lenguajes procedurales, de modo que ampl an la funcionalidad de los procedimientos almacenados, tales como PL/SQL de Oracle o PL/PgSQL de Postgres. 3 Los procedimientos almacenados son programas que se almacenan f sicamente en una base de datos. Ofrecen la ventaja de que son ejecutados directamente en el motor de bases de datos, y como tal posee acceso directo a los datos que necesita manipular y s olo necesita enviar los resultados de regreso a la capa superior, deshaci endose de la sobrecarga resultante de transferir grandes cantidades de datos.
30
El implementar la l ogica de acceso a datos en el propio cliente implica que un usuario puede descifrar su funcionamiento, y por tanto su implementaci on, lo que posibilita el aprovechamiento de fallos de seguridad para llevar a cabo acciones que no est an previstas. Por contra, algunas de las ventajas que ofrece este sistema son: Cuando un servidor de bases de datos procesa una consulta, la eciencia en la devoluci on de la respuesta a esta petici on depender a de la m aquina donde se encuentra alojado el servidor, y no de la del cliente, que u nicamente recibe el resultado. El servidor de datos devuelve s olo la informaci n on solicitada a trav es de la red, de tal modo que el tr aco de la misma resulta sustancialmente reducido. Esto permite crear aplicaciones que acceden a grandes cantidades de datos utilizando anchos de banda no excesivamente amplios. Un servidor de bases de datos puede asegurar m as ecazmente la integridad y consistencia de los datos que los sistemas utilizados anteriormente, tales como servidores de archivos.
3.2.
Arquitectura de 3 capas.
La estrategia tradicional de utilizar aplicaciones compactas causa gran cantidad de problemas de integraci on en sistemas software complejos como pueden ser los sistemas de gesti on de una empresa o los sistemas de informaci on integrados consistentes en m as de una aplicaci on. Estas aplicaciones, como ya hemos visto, suelen encontrarse con importantes problemas de escalabilidad, disponibilidad, seguridad e integraci on. El paso siguiente a la arquitectura de 2 capas fue la aparici on entre la capa de interfaz (presentaci on) y la de acceso a datos, de una tercera capa de reglas o l ogica de negocio, que es la que realmente implementa las funciones de la aplicaci on y debe obviar tanto la estructura de los datos como su ubicaci on. El cliente ((pesado)) que en la arquitectura de dos capas aglutina la interfaz junto con la l ogica de la aplicaci on se divide en un cliente ((ligero)) y la l ogica de la aplicaci on se traslada completamente a un servidor. Por ejemplo, en una aplicaci on web el cliente es un navegador que muestra las p aginas enviadas por el servidor que administra la l ogica de negocio, las cuales permiten el ingreso o la consulta de los datos.
3.2.1.
Funciones de cada capa
En la gura 3.5 en la p agina siguiente se ilustran de manera general los componentes de la arquitectura de 3 capas.
31
Figura 3.5: Esquema de la arquitectura de 3 capas
3.2.1.1.
Acceso a datos
Es la capa de nivel m as bajo. Sus funciones incluyen el almacenamiento, la actualizaci on y la consulta de todos los datos contenidos en el sistema. En la pr actica, esta capa es esencialmente un servidor de bases de datos, aunque podr a ser cualquier otra fuente de informaci on. Gracias a esta divisi on, es posible agregar soporte para una nueva base de datos en un per odo de tiempo relativamente corto. La capa de datos puede estar en el mismo servidor que las de l ogica de negocio y presentaci on, en un servidor independiente o incluso estar distribuida entre un conjunto de servidores, dependiendo de la magnitud de la aplicaci on. 3.2.1.2. Capa de aplicaci on
El comportamiento de la aplicaci on es denido por los componentes que modelan la l ogica de negocio. Estos componentes reciben las acciones a realizar a trav es de la capa de presentaci on, y lleva a cabo las tareas necesarias utilizando la capa de datos para manipular la informaci on del sistema. Tener la l ogica de negocio separada del resto del sistema tambi en permite una integraci on m as sencilla y ecaz con sistemas externos, ya que la misma l ogica utilizada por la capa de presentaci on puede ser accedida desde procesos autom aticos que intercambian informaci on con los mismos. 3.2.1.3. Capa de presentaci on o capa cliente
La capa de presentaci on representa la parte del sistema con la que interact ua el usuario, la interfaz. En una aplicaci on web, un navegador puede utilizarse como cliente del sistema, pero esta no es la u nica posibilidad, tambi en puede generarse una aplicaci on que cumpla las funciones de cliente ((ligero)) para interactuar con el usuario.
3.2.2.
Ventajas de la arquitectura de 3 capas
La arquitectura de 3 capas tiene todas las ventajas de los sistemas cliente/servidor, adem as de las que de por s tienen los sistemas dise nados de forma modular. Pero tambi en han conseguido mejorar muchos de los aspectos que han resultado dif ciles de solucionar en la arquitectura de 2 capas: 32
Permite la reutilizaci on: La aplicaci on est a formada por una serie de componentes que se comunican entre s a trav es de interfaces y que cooperan para lograr el comportamiento deseado. Esto permite no solamente que estos componentes puedan ser f acilmente reemplazados por otros, por ejemplo en caso de necesitarse mayor funcionalidad, sino tambi en que los mismos puedan ser utilizados para otras aplicaciones. Acompa na el crecimiento: Cada uno de los componentes de la aplicaci on pueden colocarse en el mismo equipo o distribuirse a trav es de una red. De esta manera, proyectos de gran envergadura pueden dividirse en peque nos proyectos m as simples y manejables, que se pueden implementar en forma progresiva, agregando nuevos servicios seg un la medida de crecimiento de la organizaci on. Uso eciente del hardware: Debido a que los componentes pueden ser distribuidos a trav es de toda la red, se puede hacer un uso m as eciente de los recursos de hardware. En vez de necesitarse grandes servidores que contengan la l ogica de negocios y los datos, es posible distribuirlos en varias m aquinas m as peque nas, econ omicas y de f acil reemplazo en caso de fallo. M nima inversi on inicial: Generalmente, un cambio en el sistema de gesti on tra a asociada una inversi on importante en la actualizaci on de hardware en los clientes, debido a nuevas necesidades de c omputo de las aplicaciones ((pesadas)). Los clientes ((ligeros)) de esta nueva modalidad permiten manterner el equipamiento actual o adquirir uno de muy bajo coste y actualizar, s olo en caso de ser necesario, la tecnolog a de los servidores. Distintas presentaciones: Debido a que separa la presentaci on de la l ogica de negocio, es mucho m as sencillo realizar tantas presentaciones diferentes como dispositivos con capacidades e interfaces se tenga (PC, PDA, tel efonos m oviles, etc.). Encapsulaci on de los datos: Debido a que las aplicaciones cliente se comunican con los datos a trav es de peticiones que los servidores responden ocultando y encapsulando los detalles de la l ogica de la aplicaci on, obtenemos un nivel de abstracci on que permite un acceso a los datos consistente, seguro y auditable. Con esto se pretende lograr que si hay cambios en la capa de datos, la capa de negocios se haga cargo de administrar tales cambios de forma transparente de forma que el cliente permanezca ajeno a esos cambios. Mejor calidad nal de las aplicaciones: Como las aplicaciones son construidas en unidades separadas, estas pueden ser probadas independientemente y con mucho m as detalle, lo que conduce a obtener un producto mucho m as s olido y able.
33
Cap tulo 4
Arquitectura J2EE
J2EE es una tecnolog a que pretende simplicar el dise no y la implementaci on de aplicaciones empresariales. Una aplicaci on empresarial es una aplicaci on que probablemente disponga de aplicaciones y bases de datos ya existentes, que se quieran seguir utilizando durante la migraci on a un nuevo conjunto de herramientas que exploten las posibilidades de Internet, comercio electr onico y otras nuevas tecnolog as. Las razones principales de la evoluci on de las aplicaciones empresariales son: Necesidad de aprovechar las nuevas tecnolog as, especialmente los avances en sistemas web. Necesidad de manejar detalles a bajo nivel, propias e inherentes a toda aplicaci on empresarial, tales como seguridad, proceso de transacciones y tareas multihilo. Evoluci on y popularidad de conceptos ampliamente aceptados, tales como la arquitectura multicapa y el desarrollo de software basada en componentes. Muchos entornos de desarrollo (frameworks ) de aplicaciones empresariales han aparecido a partir de estas necesidades. Algunos de los ejemplos m as conocidos son Java2 Platform Enterprise Edition, J2EE, de Sun Microsystems, Distributed Internet Applications Architecture, DNA, de Microsoft y Common Object Request Broker Architecture, CORBA, de Object Management Group (OMG).
4.1.
Por qu e J2EE?
Tal vez J2EE no sea la tecnolog a denitiva para el desarrollo de aplicaciones empresariales, no obstante ofrece una serie de ventajas que la han hecho posicionarse como una de las alternativas m as utilizadas:
34
CAP ITULO 4. ARQUITECTURA J2EE
4.1.1.
Ahorro de trabajo
Una aplicaci on empresarial necesita implementar servicios realmente complejos para ser completamente funcional y eciente. Ejemplos de estos servicios son el manejo de estados y transacciones, pooling de recursos o gesti on de tareas multihilo. La arquitectura J2EE separa estos servicios de bajo nivel de la l ogica de la aplicaci on, puesto que est an implementados en el propio servidor de aplicaciones. De este modo, no es necesario implementarlos para cada proyecto en caso de ser necesarios.
4.1.2.
Documentaci on
J2EE es desarrollado por un consorcio formado por grandes compa n as, el Java Community Process1 , lo que garantiza que su implementaci on est a documentada de forma completa y normalizada. Asimismo, las APIs utilizadas tambi en cuentan con documentaci on completa y detallada de todas sus funciones. Esta documentaci on puede ser consultada directamente desde la p agina de Sun, existiendo documentaci on para todas las versiones de la especicaci on.
4.1.3.
Est andar y conable
El uso de una arquitectura madura y que se ha convertido en est andar de facto implica la posibilidad de desarrollar aplicaciones conables, lo que se traduce en menor gasto de mantenimiento y garantiza su longevidad y escalabilidad. Esta especicaci on es considerada informalmente como un est andar, debido a que los suministradores deben cumplir ciertos requisitos de conformidad para declarar que sus productos son conformes a J2EE, no obstante no se trata de un estandar ISO o ECMA.
4.1.4.
Flexible
Las aplicaciones desarrolladas con J2EE gozan de gran exibilidad. Es posible desplegarlas en cualquier servidor de aplicaciones haciendo s olamente unos pocos cambios en los cheros de conguraci on. De hecho, aunque Genereitor est a desarrollado para trabajar sobre Tomcat, se ha conseguido desplegar sobre OC4J y JBoss sin problemas, haciendo m nimos cambios en sus cheros de conguraci on.
4.2.
Plataforma J2EE
La plataforma J2EE utiliza un modelo de aplicaciones distribu do y multicapa. La l ogica de la aplicaci on est a dividida en componentes, y cada componente
1 La
especicaci on de J2EE se puede consultar en http://www.jcp.org/en/jsr/detail?id=
244.
35
est a instalado en una m aquina espec ca, cuyas caracter sticas ir an acordes con los requisitos de los componentes que se alojan en ella2 . En la gura 4.1 se muestra un diagrama b asico de la arquitectura J2EE.
Figura 4.1: Diagrama de la arquitectura J2EE
4.3.
Model-View-Controller
El concepto de la arquitectura Modelo-Vista-Controlador se basa en separar el modelo de datos de la aplicaci on de su representaci on de cara al usuario, y de la interacci on de este con la aplicaci on, mediante la divisi on del sistema en tres partes fundamentales: Modelo: contiene la l ogica de negocio de la aplicaci on. Vista: muestra al usuario la informaci on que este solicita. Controlador: recibe e interpreta la interacci on del usuario, actuando sobre modelo y vista de manera adecuada para provocar cambios de estado en la representaci on interna de los datos, as como en su visualizaci on. Un esquema de estas tres capas se presenta en la gura 4.2 en la p agina siguiente.
2 Aunque la arquitectura est e pensada para que las diversas capas est en soportadas por m aquinas diferentes, es perfectamente posible, en el caso de aplicaciones peque nas, que todos los servidores residan en la misma m aquina. As mismo, para aplicaciones de gran envergadura, tambi en es posible que una capa sea soportada por varios servidores, utilizando computaci on distribuida.
36
Figura 4.2: Diagrama del MVC.
Las consecuencias del uso de MVC en el dise no de una aplicaci on son: Componentes del Modelo reutilizables. La separaci on entre modelo y vista permite implementar m ultiples vistas que utilicen el mismo modelo. A consecuencia de esto, los componentes del modelo de una aplicaci on empresarial son m as f aciles de implmenetar, probar y mantener, puesto que el modelo se basa en estos componentes. F acil soporte para nuevos tipos de clientes. Para incluir una nueva vista en una aplicaci on (m oviles, pdas, etc) s olo es necesario implementar dicha vista y la l ogica de control del modelo, e incorporarlos a la aplicaci on. Dicha vista aprovechar a el modelo existente para funcionar. Incrementa la complejidad del dise no. Este esquema incorpora algunas clases adicionales, debido a la separaci on de vista, modelo y controlador, por lo que el dise no aumenta de tama no y, en aplicaciones peque nas, puede ser engorroso mantener tal separaci on. Esta arquitectura ha demostrado ser muy apropiada para las aplicaciones web, y se adapta extraordinariamente a las tecnolog as proporcionadas por la plataforma J2EE. As , para implementar una arquitectura MVC sobre J2EE, los componentes de la misma ser an:
4.3.1.
Modelo
El modelo representa los datos de la aplicaci on y la l ogica de negocio que gobierna el acceso a dichos datos. Estar a implementado por un conjunto de clases Java. Para este cometido existen dos alternativas de implementaci on:
37
4.3.1.1.
Enterprise JavaBeans
Enterprise JavaBeans es una arquitectura de componentes distribu do del lado del servidor para la construcci on modular de aplicaciones empresariales. La especicaci on EJB es una de las muchas APIs de J2EE3 , que intenta proveer un m etodo est andar para implementar la l ogica de negocio que se suele encontrar en aplicaciones empresariales. Fue concebida para manejar caracter sticas tales como persistencia, integridad transaccional y seguridad de forma est andar, liberando a los programadores para concentrarse en las tareas espec cas de cada aplicaci on. La especicaci on EJB provee: Persistencia. Procesado transaccional4 . Control de concurrencia. Eventos, usando Java Message Service. Seguridad. Despliegue de componentes de software en el servidor de aplicaciones. 4.3.1.2. Plain Old Java Objects
Los POJOs son clases Java simples, que no dependen de un framework en especial. Es una apuesta por la simplicidad en proyectos de peque na envergadura, en los que es posible prescindir de los complejos frameworks y la arquitectura que implica el uso de EJBs. Las caracter sticas de un POJO son: Es serializable. Tiene constructor sin argumentos. Permite el acceso a sus propiedades mediante m etodos getPropiedad() y setPropiedad(). Genereitor implementa su capa modelo con POJOs, aunque los proyectos generados con el incluyen la posibilidad de implementarla mediante EJB.
3 La especicaci on de EJB 2.0 se puede descargar en http://www.jcp.org/en/jsr/detail? id=19/. 4 La gesti on transaccional es un m etodo consistente en descomponer los procesos en operaciones at omicas e indivisibles llamadas transacciones. Cada transacci on debe nalizar de forma correcta o incorrecta como una unidad completa, no puede acabar en un estado intermedio. Tambi en establece caracter sticas como rollback, que permite, en caso de fallo, deshacer la operaci on para restaurar su estado inicial e informar del fallo.
38
4.3.2.
Vista
La vista proporciona una serie de p aginas web, creadas din amicamente, al cliente, que las recibir a como simples p aginas HTML que interpretar a su navegador. Existen m ultiples frameworks que generan estas p aginas web a partir de distintos formatos, siendo el m as extendido JSP (Java Servlets Page 5 ). JSP permite desarrollar p aginas HTML, pero incluye la posibilidad de utilizar en estas c odigo Java, lo que permite a personas con conocimientos en HTML desarrollar interfaces de una forma r apida y sencilla. Alternativas a JSP son ASP, PHP y Phyton, no obstante la primera es la que ofrece una mejor integraci on con J2EE.
4.3.3.
Controlador
El controlador traduce las interacciones del usuario con la vista a acciones que son interpretables por el modelo. En un cliente gr aco aut onomo (standalone ), las interacciones del usuario pueden ser pulsaciones de botones o selecciones en men us, mientras que en una aplicaci on web, estas interacciones est an representadas por peticiones HTTP (GET y POST). Las acciones implementadas por el modelo pueden ser la ejecuci on de procesos o el cambio de estado del modelo. Basado en las interacciones del usuario y las respuestas de las acciones del modelo, el controlador responde seleccionando una vista apropiada a la petici on del usuario. En la plataforma J2EE el controlador se desarrolla mediante servlets. Un servlet es un objeto que se ejecuta en un servidor J2EE (como Oracle Container for Java, OC4J), o un contenedor (como Tomcat)6 , y que ha sido dise nado eespecialmente para ofrecer contenido din amico desde un servidor web, generalmente HTML.
5 La
especicaci on de JSP se puede consultar en http://www.jcp.org/en/jsr/detail?id=
53.
6 La diferencia entre un servidor de aplicaciones y un contenedor de servlets es que el primero extiende esta funcionalidad, proporcionando contenedor para objetos m as avanzados, tales como EJB. Como en Genereitor no se utiliza EJB, se ha desarrollado para desplegar sobre Tomcat. No obstante, se puede desplegar sobre OC4J simplemente cambiando algunos par ametros de conguraci on.
39
Parte III
Funcionalidades de Genereitor
40
En esta parte de la memoria se van a describir las capacidades de Genereitor como herramienta de ayuda a la implementaci on de aplicaciones web para entornos empresariales. Genereitor se divide en tres grandes bloques funcionales, correspondientes a tres funciones que, aunque son diferentes, se complementan para conseguir formar un todo que ser a la aplicaci on. Esta aplicaci on en realidad s olo ser a un esbozo del resultado nal, pero sentar a las bases para el desarrollo posterior por parte de los programadores, ahorrando una cantidad sustancial de tiempo. Para explicar los diferentes apartados se har a referencia a una hipot etica aplicaci on ((taller)), cuyo esquema de la base de datos se reeja en la gura 4.3.
Figura 4.3: Esquema de la base de datos de la aplicaci on de ejemplo ((taller)).
41
Cap tulo 5
Generaci on de esqueleto
La generaci on del esqueleto es la primera fase de la implementaci on de una aplicaci on web. Anteriormente se habr a realizado el dise no de la aplicaci on, teniendo en cuenta, seg un los requisitos del cliente, la estructura que tomar a el proyecto y las tecnolog as a utilizar. Este dise no quedar a reejado con detalle en un documento de an alisis y dise no (ver A en la p agina 116 para consultar el de Genereitor), que servir a de gu a a lo largo de todo el proceso de implementaci on. Una vez han quedado claramente reejados todos los requisitos y caracter sticas que ha de tener el proyecto en el documento de an alisis y dise no, se procede a dise nar e implementar la base de datos sobre la que se apoyar a la aplicaci on. Este paso no es com un a todas las aplicaciones, puesto que es com un que el cliente proporcione ya una base de datos existente (en caso de migraciones o actualizaciones de aplicaci on). Tras esto, se comienza la implementaci on del proyecto, generando el esqueleto. El esqueleto de una aplicaci on es la estructura de directorios sobre la que se asienta, y que permite tener separados y bien identicados los componentes de la misma seg un su funci on y la capa a la que pertenecen. Junto a la estructura de directorios se generar an cheros que implementar an funciones relativas a cada capa de la aplicaci on, y que ser an explicados con detalle m as adelante. Algunos de estos cheros se generar an como clases vac as, con la cabecera pero sin m etodos. Estos m etodos ser an proporcionados con la generaci on de c odigo, operaci on que se realizar a para cada entidad de la base de datos que quiera ser tenida en cuenta en la aplicaci on, y posteriormente ser an a nadidos a estos cheros ((incompletos)) con una herramienta auxiliar (Combineitor, ver apartado B en la p agina 145).
42
DE ESQUELETO CAP ITULO 5. GENERACION
5.1.
5.1.1.
Funciones de la interfaz
Fase 1. Generaci on de esqueleto
La u nica pantalla de generaci on de esqueleto contiene tres bloques que solicitan informaci on al programador para adecuar el esqueleto generado a las necesidades del proyecto. 5.1.1.1. Bloque de datos generales
En este primer bloque se solicitan los datos generales necesarios para generaci on del esqueleto de una aplicaci on. Tales datos son: Sistema de bases de datos. El programador elegir a de entre las opciones disponibles (Oracle 9, PostgreSQL, MySQL, HSQLDB o SQLServer1 ) el sistema de bases de datos que se ha elegido en el proceso de an alisis para soportar la base de datos. Esta opci on afectar a tanto a los datasources como a la forma de acceder a los datos en la base de datos. Servidor de aplicaciones. Seg un el dise no de la aplicaci on, se elegir a entre OC4J o Tomcat2 . Nombre de la aplicaci on. El nombre de la aplicaci on. Nombre del paquete base de la aplicaci on. El nombre del paquete base de la aplicaci on3 . En este bloque tambi en se ofrece un pulsador con el literal ((Default )), cuya funci on es autocompletar el siguiente bloque con los datos de conexi on de las bases de datos de desarrollo que hay en la factor a de software de la empresa, seg un el servidor de bases de datos seleccionado. Con varias pulsaciones sobre este literal se rota de forma c clica entre las diferentes conexiones para un mismo sistema de bases de datos, puesto que se da el caso que para algunos sistemas hay varias bases de datos de desarrollo. 5.1.1.2. Bloque de datos de conexi on
Aqu se recogen los datos de conexi on de la base de datos contra la que va a trabajar la aplicaci on a desarrollar: Host.
soporte para otros sistemas de bases de datos se contempla como trabajo futuro. soporte para otros servidores de aplicaciones o contenedores de EJB se contepla como trabajo futuro. 3 Es requisito que el nombre de la aplicaci on siempre sea el u ltimo elemento del nombre del paquete base. As , la aplicaci on taller tendr a su paquete base llamado com.comex.taller. Es por esto que en la casilla de ( (nombre de paquete base) ) s olo hay que introducir los primeros elementos del nombre (com.comex), ya que el u ltimo se completa autom aticamente a partir del contenido de la casilla ( (nombre de la aplicaci on) ).
2 El 1 El
43
Puerto. SID, o nombre de la base de datos. Usuario. Contrase na. Aunque para la generaci on del esqueleto realmente no es necesaria una conexi on real a la base de datos, estos se requieren para congurar correctamente los dataosurces. Para comprobar que los datos introducidos son correctos, y as evitar errores tipogr acos, se proporciona un bot on con el literal ((Test )) que lanza una conexi on al servidor cuyos datos han sido introducidos, informando al programador de si esta ha sido exitosa, o del error producido en caso contrario. 5.1.1.3. Bloque de opciones de la aplicaci on
En este u ltimo bloque de datos se solicitan las caracter sticas particulares del proyecto a generar: M odulos web. Una aplicaci on web puede estar formada por varios m odulos o subaplicaciones. Por ejemplo, en el caso de un portal que tenga una parte de acceso p ublico (por ejemplo taller-web), una para clientes (tallerclientes) y otra para administraci on de contenidos (taller-admin). Se ofrece una lista en la que se a nadir an todos los m odulos que sean necesarios para la aplicaci on. Utilizar Authenticator. Permite a nadir un mecanismo de seguridad a las conexiones de la aplicaci on, consistente en un par ametro authenticator, que conrma que el usuario que solicita la conexi on es un usuario v alido conforme al registro de usuarios existente en la base de datos. Utilizar XML4 . Integra en la aplicaci on el m odulo de comunicaci on de datos mediante XML de la empresa (com.comex.xml). Utilizar CMS. Integra en la aplicaci on el sistema de gesti on de contenidos (com.comex.cms). Utilizar par ametros. Hace que la aplicaci on generada tome una serie de par ametros que se alojar an en la base de datos, en lugar de almacenarlos en la propia aplicaci on.5 Utilizar tablas maestras. Integra en la aplicaci on el m odulo de tablas maestras (com.comex.tablasmaestras), que genera las interfaces de gesti on de
funci on XML todav a no est a implementada completamente. la opci on par ametros es obligatoria, puesto que otros m odulos dependen de estos par ametros. M as adelante, cuando se actualicen esos m odulos y no requieran los par ametros alojados en la base de datos, esta posibilidad se ofrecer a como opcional.
5 Actualmente 4 La
44
tablas maestras a partir de un script que se generar a a posteriori con la funci on ((Generar script de tablas maestras )) de Genereitor.6 Usuarios, perles y grupos7 . Integra en la aplicaci on el m odulo que da soporte para usuarios, grupos de usuarios y perles, y ofrece una lista para congurar los perles que se utilizar an en la aplicaci on. Librer as. Ofrece una lista de las librer as com unmente utilizadas, de manera que el programador incluya las que crea convenientes teniendo en cuenta los requisitos del dise no. Estas librer as se incluir an en el esqueleto generado, y se tendr an en cuenta en los scripts de compilaci on y despliegue de la aplicaci on para que no haya que moverlas a mano. Por u ltimo, tras haber rellenado las opciones pertinentes y al pulsar el bot on ((Generar )), el programa devuelve un paquete comprimido que contiene el esqueleto de la nueva aplicaci on.
5.2.
Resultado
Tras haber generado el esqueleto, se ha obtenido un paquete que contiene la estructura del proyecto comprimida. El siguiente paso ser a descomprimir su contenido en el directorio de la m aquina del desarrollador, que ser a su copia de trabajo. De forma muy simplicada, la estructura de directorios generada es la representada en la gura 5.1 en la p agina siguiente. Adem as de la estructura de directorios, se generan diversos archivos que a continuaci on se detallan:
5.2.1.
Ficheros properties y descriptores de despliegue.
acciones.properties: Este chero contiene todas las acciones que se ofrecen en la interfaz de usuario, y la correspondencia con el servlet que las implementa. La interfaz (vista), que es una p agina HTML, contiene v nculos a las acciones (por ejemplo, a vehiculo.listar.do), que hacen referencia a los m etodos de los servlets (Actions ). Este chero se encarga de interpretar las peticiones del usuario, mediante su interacci on con la interfaz, e invocar al servlet correspondiente. etiquetas.properties: Este chero contiene los textos mostrados en la interfaz web. En lugar de escribirlos directamente en el chero JSP, se utiliza este chero que contiene los literales de la interfaz identicados con una etiqueta, que ser a la que se use al implementar la interfaz. De este modo se
la opci on tablas maestras es obligatoria, puesto que otros m odulos dependen de funcionalidades implementadas en com.comex.tablasmaestras. Cuando se actualicen estas dependencias y no se requiera del m odulo de tablas maestras, esta posibilidad se ofrecer a como opcional. 7 La funci on Usuarios todav a no est a implementada completamente.
6 Actualmente
45
/ META-INF apps taller taller-ejb ejb ......................................... Fachada y EJB exception ..................................... Excepciones taller-web.................................M odulo web ((web)) src servlet......................................... Actions taglib ............................. Tags de la parte web util web..................................... JSP, CSS, im agenes taller-webadmin ..................... M odulo web ((webadmin)) ... ... src......... Ficheros de conguraci on, despliegue, data-sources... components common.........................................M odulos utilizados taller dal.............................................Acceso a datos bean.......................... Implementaci on de los objetos lib ........................................................ Librer as setup instalacion ............................... Ayuda a la instalaci on scripts..............................................Scripts SQL Figura 5.1: Arbol de directorios simplicado de una aplicaci on web. / apps/ taller/ src/ conf/ propertyFiles/ etiquetas.properties acciones.properties des.log4j.properties pre.log4j.properties pro.log4j.properties des.config.properties pre.config.properties pro.config.properties Figura 5.2: Ruta de los cheros .properties. permite el soporte para varios idiomas, o la r apida localizaci on y correcci on de errores en la escritura de los textos de la aplicaci on. log4j.properties: Contiene la conguraci on de los logs de la aplicaci on. Se ofrecen tres conguraciones (para desarrollo, preproducci on y producci on), puesto que seg un la etapa en la que se encuentre el proyecto ser a necesaria una mayor o menor intensidad en la monitorizaci on y auditor a de los eventos que tengan lugar. cong.properties: Contiene diversos par ametros de conguraci on general propios de la aplicaci on. 46
En caso de que la aplicaci on utilice EJBs, se proporcionar an tambi en los archivos (incompletos, se completar an con la generaci on de c odigo ) que contendr an los descriptores de despliegue. Estos archivos indican al servidor de aplicaciones c omo han de desplegar la aplicaci on para ponerla en funcionamiento y el tratamiento que han de dar a los EJBs.
5.2.2.
/
Scripts de compilaci on
apps/ taller/ taller-ejb/ build.xml taller-web/ build.xml build.xml components/ taller/ build.xml build.xml build.xml Figura 5.3: Ruta de los scripts de compilaci on. Estos archivos build.xml repartidos por toda la estructura de directorios son los que indican a ant de qu e forma se debe llevar a cabo la compilaci on del proyecto. El script principal es el situado en el directorio ra z (/build.xml), que ir a llamando seg un convenga a los situados en los diferentes directorios de la estructura. El motivo de la divisi on de las tareas de compilaci on en varios scripts es la mejora de la modularidad, manteniendo independencia entre las diferentes partes del proyecto. Junto a cada script build.xml se proporciona otro, build para envio.xml, cuya funci on es id entica al anterior, pero teniendo en cuenta los par ametros de la m aquina del cliente donde se va a desplegar para su entrada en producci on, por lo que algunos par ametros ser an diferentes.
5.2.3.
Capa web - Servlets (Controlador)
En esta ruta se alojan los cheros fuente de los servlets, tags y dem as utilidades que utiliza el controlador de la capa de aplicaci on para generar la interfaz web y comunicarse con el modelo de la capa de l ogica de negocio. Las funciones de los archivos generados son las siguientes: servlet/InicioAction.java: Implementa el servlet de bienvenida a la aplicaci on, que se encargar a de formar la primera p agina de la interfaz. servlet/ServletEscuchador.java: Se trata de un servlet que monitoriza las sesiones para crear y destruir las sesiones que permanezcan demasiado tiempo 47
/ apps/ taller/ taller-web/ src/ java/ com/ comex/ taller/ servlet/ InicioAction.java ServletEscuchador.java TallerBaseAction.java taglib/ BotonTag.java ContenedorTag.java util/ Figura 5.4: Ruta de los servlets de un m odulo web. inactivas, y por tanto se considere que han caducado. Tambi en limpiar a cada cierto tiempo los atributos de dichas sesiones inactivas. servlet/TallerBaseAction.java: Servlet base que extender an todos los dem as de la aplicaci on. Implementa tambi en funciones comunes o usadas por varios servlets, con objeto de reutilizar c odigo. Tambi en implementa los m etodos para que los dem as servlets sean capaces de comunicarse con la fachada que da acceso al modelo de la aplicaci on. taglib/ContenedorTag.java y taglib/BotonTag.java: Implementaci on de los tags que se utilizar an en los JSP para dibujar el contenedor general de la interfaz y los botones. Esto supone una gran reutilizaci on de c odigo, consiguiendo adem as que todas las p aginas pertenecientes al mismo m odulo web tengan la misma apariencia. Directorio util: Aqu se localizan otros tags m as gen ericos, que no se modican de uno proyecto a otro, como el tag Paginador, que se encarga de agrupar los resultados de las listas en p aginas de n elementos, ofreciendo enlaces de ((siguiente)), ((anterior)), etc, y tambi en implementa la funci on de ordenar. Tambi en se encuentran aqu cheros que almacenan m etodos para validar de forma accesible diversos eventos en los formularios de la interfaz, como comprobar que un NIF exista o que la fecha sea correcta, y diversas funciones de formateo de n umeros y cadenas.
5.2.4.
Capa web - JSP (Vista)
En la carpeta taller-web/web se alojan todos los cheros fuente directamente relacionados con la interfaz y su aspecto (gura 5.5 en la p agina siguiente): Los directorios mostrados contienen los siguientes cheros: WEB-INF: Contiene los descriptores de los tags que est an disponibles para su uso en la interfaz, de forma que los cheros JSP sean capaces de inter48
/ apps/ taller/ taller-web/ web/ WEB-INF/ css/ error/ imagenes/ js/ privado/ publico/ Figura 5.5: Ruta de la parte web (interfaz) de un m odulo web. pretarlos seg un su implementaci on en el directorio del apartado anterior. Tambi en contiene el chero web.xml8 . css: Incluye estilos provisionales para la aplicaci on, que luego habr an de ser modicados por el programado o dise nador para adecualos a los requisitos visuales impuestos por el cliente. error: Contiene las p aginas que se mostrar an en caso de error. imagenes: Contiene las im agenes que se utilizan en la interfaz en botones, pulsadores de ordenaci on de tablas, etc. js: Recopilaci on de u tiles JavaScript que ser an utilizados si los requisitos de accesibilidad de la aplicaci on lo permiten. privado y publico: Ficheros JSP que implementan cada p agina de la interfaz de la aplicaci on, tanto aquellas zonas de acceso p ublico como las de acceso restringido.
5.2.5.
Capa de l ogica de negocio - Fachada de Componentes (Modelo)
El modelo, ya sea implementado a partir de EJBs o POJOs, se encuentra en la siguiente ruta: Estos archivos s olo representan la Fachada que se encarga de comunicar la l ogica de negocio de la aplicaci on con los servlets, es decir, el modelo con el controlador. Cuando se genera el esqueleto, Genereitor todav a no conoce qu e entidades de la base de datos se van a manejar en la nueva aplicaci on, por lo que no es posible ofrecer estos archivos completos. En su lugar, se ofrecen u nicamente las cabeceras de los cheros, y en la fase de generaci on de c odigo se ofrecer an trozos que se insertar an en los cheros que correspondan9 .
8 web.xml es el descriptor de despliegue que indica al contenedor de servlets diversos par ametros, tales como la localizaci on de los paquetes que forman el modelo, los descriptores de tags, las p aginas que mostrar en caso de error, etc. 9 Para automatizar la tarea de incrustar los trozos en los cheros correspondientes se ha
49
/ apps/ taller/ taller-ejb/ src/ java/ com/ comex/ taller/ bl/ ejb/ TallerFacadeEJB.java TallerFacadeEJBBean.java TallerFacadeEJBHome.java Figura 5.6: Ruta del modelo de una aplicaci on con EJB.
5.2.6.
Capa de acceso a datos - Scripts SQL
Con la generaci on del esqueleto tambi en se devuelven una serie de scripts SQL, aunque muchos de ellos estar an vac os (recordemos que la implementaci on de la base de datos es un proceso anterior al uso de Genereitor). La ruta donde se encuentran es la de la gura 5.7: / setup/ scripts/ 01 TABLAS.SQL 02 CLAVES AJENAS.SQL 03 INDICES.SQL 04 SECUENCIAS.SQL 05 VISTAS.SQL 06 TRIGGERS.SQL 07 CODIGO 00.SQL 07 CODIGO 01.SQL 08 JOBS.SQL 09 SINONIMOS.SQL 10 ROLES.SQL 11 GRANTS.SQL 12 DATOS.SQL Figura 5.7: Ruta de los scripts SQL. Tras la generaci on del esqueleto, estos cheros u nicamente contendr an los datos de creaci on de los componentes de la base de datos para el manejo de la tabla APLICACION PARAMETRO, el rol APLICACION ROL APLICACION10 y los grants (permisos) de este rol para modicar la tabla par ametro. Esta tabla ser a utilizada por la aplicaci on para guardar diversos par ametros. Los cheros 07 CODIGO 00.SQL y 07 CODIGO 01.SQL ser an utilizados si la aplicaci on implementa su capa de acceso a datos mediante PL/SQL directamena los te en el servidor de bases de datos. El chero 07 CODIGO 00.SQL contendr
implementado una herramienta auxiliar, Combineitor, cuyas caracter sticas y funcionamiento se detallan en B en la p agina 145. 10 Por ejemplo, TALLER ROL APLICACION.
50
tipos que utilizar a PL/SQL mientras que 07 CODIGO 01.SQL contendr a la implementaci on de las funciones y procedimientos. a el siguiente: El estado inicial de 07 CODIGO 01.SQL ser
1 2 3 4 5 6 7 8 9
CREATE OR REPLACE PACKAGE TALLER_PKG AS TYPE tipo_cursor IS REF CURSOR ; -- genereitor : inse rtarTroz o1 END TALLER_PKG ; / CREATE OR REPLACE PACKAGE BODY TALLER_PKG AS -- genereitor : inse rtarTroz o2 END TALLER_PKG ; /
En este chero se aprecian las trazas que luego ser an utilizadas por combineitor para introducir los trozos de c odigo generados mediante el bloque funcional de generaci on de c odigo.
5.2.7.
Documento de instalaci on
Por u ltimo, en la ruta setup/instalacion.html se proporciona un manual de instalaci on de la aplicaci on, a modo de gu a para la instalaci on de la aplicaci on en el cliente.
51
Cap tulo 6
Generaci on de partes de c odigo

Este bloque funcional es el encargado de generar los componentes de la aplicaci on correspondientes a cada una de las entidades de la base de datos que van a formar parte de la aplicaci on que se va a desarrollar. Generalmente ser a necesario realizar este paso para cada una de las entidades que forman parte de la base de datos, salvo aquellos casos que se decidan tener en cuenta las relaciones entre tablas, que como se ver a m as adelante, compartir an ciertos componentes de la aplicaci on. Tambi en en este apartado se generar an trozos de los cheros que quedaron incompletos en el apartado de generaci on de esqueleto, y que se introducir an en dichos cheros mediante la herramienta Combineitor, cuyo funcionamiento est a detallado en el ap endice B en la p agina 145.
6.1.
6.1.1.
Fase 1: Conexi on
El primer paso para la elaboraci on de las partes de c odigo correspondientes a una entidad de la base de datos es la conexi on al servidor de bases de datos. Por ello, la primera fase de este bloque funcional es la introducci on de los datos de conexi on: Sistema de bases de datos (lista desplegable con todos los sistemas de bases de datos soportados por la herramienta). Host. Puerto. SID, o nombre de la base de datos. 52
DE PARTES DE CODIGO CAP ITULO 6. GENERACION
Usuario. Contrase na. Tambi en se proporciona un pulsador con el literal ((Default )), cuya funci on es autocompletar el siguiente bloque con los datos de conexi on de las bases de datos de desarrollo que hay en la factor a de software de la empresa, seg un el servidor de bases de datos seleccionado. Con varias pulsaciones sobre este literal se rota de forma c clica entre las diferentes conexiones para un mismo sistema de bases de datos, puesto que se da el caso que para algunos sistemas hay varias bases de datos de desarrollo. Al pulsar el bot on ((Conectar)), se realizan una serie de validaciones mediante JavaScript para comprobar que los datos introducidos tienen el formato correcto: Sistema de bases de datos, Host, SID y usuario no pueden tomar valores nulos. Puerto ha de tener valor num erico y no nulo. Si no se introduce un valor para el campo contrase na, se avisa al usuario mediante un mensaje junto al bot on ((Conectar)), y se hace parpadear brevemente dicho campo para llamar su atenci on. Si se vuelve a pulsar el bot on ((Conectar)) se lanzar a efectivamente la conexi on contra el servidor, indiferentemente de que se haya introducido una contrase na. Si existe alg un error en los datos se informar a al usuario mediante una caja de texto situada al principio de la p agina. De lo contrario, se lanzar a la conexi on al servidor. Es posible que los datos introducidos, pese a tener un formato v alido, no sean correctos y el servidor de bases de datos no responda o rechace la conexi on. De ser as , se informar a nuevamente al usuario del error y se le permitir a modicar los datos introducidos para volver a lanzar la conexi on1 .
6.1.2.
Fase 2: Selecci on de tabla
En esta segunda fase se muestra al usuario, una vez se ha establecido con exito la conexi on a la base de datos, una lista con todas las tablas y vistas existentes en ella, de donde se elegir a la tabla correspondiente a la entidad para que se desea generar los componentes de la aplicaci on.
1 Debido a que algunos sistemas de bases de datos ofrecen m as informaci on que otros cuando ocurre un error en la conexi on, dependiendo del sistema elegido los textos explicativos del error ser an m as o menos espec cos. Por ejemplo, mientras que un sistema puede devolver un error de tipo usuario no v alido, otro lanzar a simplemente error en la conexi on.
53
6.1.3.
Fase 3: Selecci on de tablas relacionadas
En caso de que en la base de datos existan tablas con claves ajenas que apunten hacia la tabla seleccionada en el paso anterior (ver gura 2.1 en la p agina 21, se muestran aqu dichas tablas relacionadas, ofreciendo as la posibilidad de generar la l ogica para dichas tablas de manera conjunta, adem as de una presentaci on especial en las vistas que se generar an. Todo esto ser a explicado con detalle en la secci on 6.2 en la p agina 58. Esta vista se compone de dos listas, una que contendr a las tablas seleccionables, es decir, el conjunto de tablas cuyas relaciones apuntan a la tabla seleccionada en el paso anterior, y otra en la que se a nadir an las tablas que el usuario quiere incluir en el paquete de c odigo que va a ser generado. Si no existen en la base de datos tablas cuyas claves ajenas referencien a la tabla elegida en el paso anterior, esta fase se omite, pas andose directamente a la fase 4.
6.1.4.
Fase 4: Selecci on de campos
Ahora se presenta al usuario el listado de campos de la tabla (o tablas, en caso de haber seleccionado las relacionadas) elegida, en un formulario que ofrece varias opciones: Permite seleccionar qu e campos aparecer an en las pantallas de listado de la aplicaci on web. Es posible que algunas propiedades de la entidad para la que se est a generando c odigo no interese que sean mostradas en las vistas de listado. Por esto, se permite al usuario seleccionar los campos que interesa que sean mostrados. Se pueden denir restricciones de obligatoriedad para los campos que no la tuvieran originalmente en la base de datos, ya por un error de dise no de esta o cualquier otra circunstancia. Para los campos que sean clave primaria de la tabla, o que cuenten originalmente con dicha restricci on impuesta directamente en la base de datos no ser a posible modicarla. Tambi en se podr a redenir la longitud m axima que acepten los formularios de edici on de la aplicaci on a generar. Si el programador introduce una restricci on m as permisiva que la establecida en la base de datos, se conar a en que acto seguido ser a modicada dicha restricci on en la base de datos, por lo que Genereitor no reportar a ning un tipo de error. Esto se ha decidido implementar de este modo, permitiendo violar las restricciones de tama no porque no es raro encontrar errores de dise no en la base de datos, que habr an de ser subsanados aparte. De este modo, aunque la base de datos tuviera errores de este tipo en su dise no, se permite la generaci on del c odigo acorde al dise no correcto, conando en que el programador modicar a la base de datos para subsanar el error. Las longitudes m aximas aparecer an con los valores por defecto de las restricciones que establece la base de datos.
54
Por u ltimo se permite denir la etiqueta (texto explicativo) que describir a cada propiedad de las entidades de la base de datos en la interfaz de la aplicaci on, por ejemplo en las descripciones de los campos de edici on o buscador. Estos literales tendr an el valor por defecto del nombre de la propiedad de cada tabla, en formato Java 2 . Tambi en se ofrece al usuario informaci on tal como el nombre de cada propiedad a la que hace referencia cada la del listado y si es clave primaria de la tabla, as como el tipo de dato SQL que almacena y el tipo Java con el que ser a implementada la propiedad en la l ogica de la aplicaci on.
6.1.5.
Fase 5: Selecci on de par ametros
Esta u ltima fase del bloque funcional de generaci on de c odigo consta de tres partes: 6.1.5.1. Datos de aplicaci on
Como en los otros bloques funcionales, es necesario informar a Genereitor del nombre de la aplicaci on y el paquete base de la aplicaci on que se va a generar. Como en otras ocasiones en las que se requieren los datos, es requisito que el u ltimo componente del nombre de paquete sea el nombre de aplicaci on, por lo que no es necesario poner este u ltimo componente, siendo concatenado al nal el nombre de la aplicaci on por la propia interfaz de genereitor. 6.1.5.2. Nombre de beans
Aqu se presenta la posibilidad de editar el nombre (o los nombres, en caso de haber seleccionado tablas relacionadas) de los beans que representan a las entidades de la base de datos. Esta opci on es debida a que con frecuencia las aplicaciones se desarrollan sobre bases de datos que no est an implementadas por el equipo de desarrolladores de la empresa, sino que el propio cliente la proporciona (por ejemplo, en caso de una migraci on de una aplicaci on existente a otra nueva, conservando el modelo de datos de la anterior). Estas bases de datos es posible que no cumplan con las convenciones de nomenclatura que interesan al equipo de desarrolladores, por lo que aqu se ofrece la posibilidad de modicar el nombre que llevar an los objetos que representar an a las entidades de la base de datos. Por ejemplo, es posible que en la base de datos que proporciona el cliente haya una tabla que contenga un listado de veh culos con sus caracter sticas, a como nombre del bean llamada LISTADO VEHICULOS. Genereitor propondr que represente a esta entidad ListadoVehiculos. Pero esto, aunque a nivel de implementaci on ser a posible, no es l ogico.
2 La columna PROPIEDAD DE EJEMPLO tendr a como literal por defecto PropiedadDeEjemplo.
55
Una tabla que represente un listado de veh culos en realidad almacenar a entidades de tipo veh culo y no listados de veh culos, por lo que a la hora de implementar la aplicaci on es m as l ogico y m as c omodo para el programador hablar de objetos de tipo Vehiculo. As , es posible modicar el nombre de los beans con los que se trabajar a en la aplicaci on. No obstante, en los componentes de acceso a datos se seguir a reriendo a las tablas por sus nombres originales (LISTADO VEHICULOS, puesto que de lo contrario no ser a posible acceder a la informaci on. 6.1.5.3. Par ametros
En este u ltimo bloque de la p agina se permite al usuario seleccionar las caracter sticas particulares de los componentes generados para la entidad sobre la que se est a trabajando. M odulos web: tal y como se vio en el bloque funcional de generaci on de esqueleto, una aplicaci on puede contar con varios m odulos web que aprovechen la misma l ogica de negocio, aunque tengan diferentes funcionalidades. As , es probable que una entidad de la base de datos tenga que ser accesible por varios m odulos web, por lo que aqu se ofrece una lista para a nadir los m odulos que han de implementar dicha entidad. Aunque la entidad siempre estar a disponible a nivel de modelo, porque todos los m odulos web de la aplicaci on comparten esta capa, aqu se seleccionar a para qu e m odulos se ha de implementar vista y controlador. Utilizar Authenticator. Permite a nadir un mecanismo de seguridad a las conexiones de la aplicaci on, consistente en un par ametro authenticator, que conrma que el usuario que solicita la conexi on es un usuario v alido conforme al registro de usuarios existente en la base de datos. JSP para borrar varios beans en listado: genera, en las vistas de listado, la posibilidad de seleccionar varios elementos del mismo tipo representados por el mismo tipo de bean para ser borrados de forma simult anea, en lugar de tener que hacerlo uno por uno. JSP de edici on: Genera la parte de la vista correspondiente a la pantalla de edici on de los objetos pertenecientes a la entidad de la cual se est a generando la l ogica, que permitir a a nadir, editar o borrar registros en la base de datos. JSP de detalle: Genera la parte de la vista correspondiente a la pantalla de detalle, que mostrar a todas las propiedades de los objetos pertenecientes a la entidad. Tratar las entidades secundarias en la misma p agina que la principal: Esta opci on integra, en caso de que se hayan seleccionado tablas relacionadas a la principal, el listado de las secundarias en la misma pantalla que la edici on de la entidad principal.
56
Por ejemplo, imaginemos que estamos trabajando con la entidad Propietario. Tendremos una entidad Vehiculo relacionada, puesto que un propietario puede tener varios, uno o ning un veh culos. Asumiremos que un veh culo siempre tiene propietario. Esta opci on nos permite a nadir, a la vista de edici on de la entidad Propietario el listado de entidades Vehiculo que le pertenecen, de forma que dicha lista de veh culos se reeja visualmente como una propiedad m as del propietario. Junto con el listado de veh culos se proporciona un buscador, de forma id entica al listado de la entidad principal, Propietario. Si no se selecciona esta opci on, el listado de la entidad secundaria se mostrar a en una pantalla diferente a la edici on de la principal. En la gura 6.1 se muestra el ejemplo de las entidades Propietario (principal) y Veh culo (relacionada) esquematizando las diferentes vistas que se generan para la gesti on de los datos de ambas usando esta opci on, es decir, con el listado de la secundaria en la edici on de la principal. Por contra, en la gura 6.2 en la p agina siguiente se muestra el ujo de las vistas con esta opci on desactivada.
Figura 6.1: Esquema de las vistas con entidades relacionadas (amarillo) en la edici on de la principal (azul).
EJB/Clases Java: Aqu seleccionar a el programador si desea utilizar EJB o POJOs para implementar la capa de l ogica de negocio, dependiendo de los rquisitos de la aplicaci on que se est a desarrollando. EJBs locales/remotos: Si se seleccionan EJBs para implementar la capa de l ogica de negocio, aqu se seleccionar a si se desea utilizar EJBs 57
Figura 6.2: Esquema de las vistas con entidades relacionadas (amarillo) en diferente pantalla que la principal (azul).
remotos o locales3 . PL/SQL o JavaSQL: Esta opci on s olo est a presente si se ha seleccionado una base de datos Oracle. PL/SQL permite implementar la l ogica de acceso a datos en el propio servidor de bases de datos, liberando carga de trabajo al servidor de aplicaciones. De esta manera, los componentes de la capa de acceso a datos implementados en Java u nicamente componen los ltros para las operaciones de acceso a datos y realizan las llamadas a las funciones implementadas en PL/SQL, que se ejecutan en el servidor de bases de datos y devuelven u nicamente los datos requeridos. Si se utiliza JavaSQL, las consultas a la base de datos se componen en la capa de acceso a datos, enviando peticiones a la base de datos y recibiendo y ltrando los resultados hasta obtener los registros deseados. Para accesos sencillos a la base de datos es indiferente el uso de un sistema u otro, pero cuando las consultas adquieren cierto grado de complejidad, es m as eciente utilizar PL/SQL si est a disponible, puesto que los datos enviados entre el servidor de aplicaciones y el servidor de bases de datos son u nicamente los que interesan, liberando a la red de tr aco innecesario.
6.2.
6.2.1.
Resultado
Capa web - JSP (Vista)
En la parte correspondiente a la vista, el paquete de c odigo generado contendr a, seg un las opciones seleccionadas, los siguientes componentes:
3 La diferencia entre EJBs remotos o locales es que los remotos son accesibles por todos los componentes de la aplicaci on, mientras que los locales u nicamente pueden ser llamados desde la capa de l ogica de negocio. Es por esto que normalmente la fachada se implementa como remota, ya que ha de ser accesible desde la capa web, y los dem as componentes se implementan como locales, ya que s olo han de ser accedidos por la fachada y entre ellos.
58
6.2.1.1.
JSP de listado
Ser a el chero que se utilice para la composici on din amica de la vista de listado y buscador de la entidad generada. Dicha vista se compondr a, en primer lugar, de un buscador que permite introducir valores para cualquiera de las propiedades de la entidad, y que al pulsar el bot on ((Buscar)) devolver a una lista de los resultados ltrados por los valores introducidos. Si existen en la entidad propiedades de tipo fecha, junto al campo para introducir dicho dato se proporciona un bot on que al pulsarlo despliega un calendario, permitiendo al usuario de la aplicaci on seleccionar el d a con mayor comodidad. Este calendario est a implementado con JavaScript y CSS, por lo que no funcionar a en un navegador sin soporte para JavaScript. No obstante, se podr a introducir la fecha directamente en la casilla correspondiente, por lo que la accesibilidad se mantiene. Si en la entidad existen propiedades de tipo archivo binario (BLOB), no se ofrece la posibilidad de ltrar por dichas propiedades, ya que ser a un absurdo. Si la clave primaria de la entidad es u nica (consta de un s olo campo) y num erica se asume que es autonum erica y por tanto no se ofrece buscar por dicho campo, puesto que no tendr a utilidad ltrar por una propiedad de tales caracter sticas. La suposici on de que el campo es autonum erico es necesaria, puesto que en algunos sistemas de bases de datos no existe el tipo de datos SERIAL (e.g. Oracle), por lo que no es posible determinar consultando los metadatos de la base de datos si dicho campo es autonum erico o realmente es un c odigo num erico con alg un signicado. Es por esto por lo que se proporciona tambi en la alternativa para considerar dicha clave primaria como campo num erico, en forma de comentarios en la p agina. Bajo el buscador se encuentra el listado. Dicho listado se construye con un tag tabla proporcionado con la generaci on del esqueleto, que generar a din amicamente el listado a partir de un objeto BaseBeanSet4 que recibe como par ametro. Dicho tag tabla recibe una serie de descriptores, tanto de tabla como de columna, que indican de qu e manera ha de dibujarse (por ejemplo, el n umero y caracter sticas de las columnas que formar an el listado). Para cada entidad de la base de datos del tipo listado que cumpla con las condiciones impuestas por el ltro de b usqueda en caso de haberse especicado se mostrar a una la en la tabla. Si el n umero de las a mostrar excede de a de mostrar s olo los diez primeros 105 , el paginador de la tabla se encargar elementos, creando al pie de la tabla una lista de p aginas de la tabla, a las que se puede acceder pinchando directamente sobre los n umeros o sobre las echas de anterior y siguiente. Este paginador tambi en permite ordenar la tabla por cualquiera de las propiedades de la entidad que aparecen, tanto ascendente como descendentemente. Esto se realiza pinchando sobre las echas que hay en la
4 BaseBeanSet es una lista de objetos que representan una entidad en la base de datos. En el caso del listado, contendr a todos los objetos de la base de datos del tipo que se quiere listar. 5 10 es el valor por defecto que se ofrece para la longitud de las p aginas, pero es totalmente personalizable.
59
cabecera de cada columna. Al realizar una ordenaci on, se resaltar a la columna por la que se ha ordenado la tabla, y el sentido, mediante el cambio de color de la cabecera de dicha columna y las echas. Para cada registro de la base de datos se mostrar a adem as: Un checkbox para seleccionar registros y poder borrarlos posteriormente con el bot on inferior de ((borrar)), en caso de que se haya seleccionado a la hora de generar el c odigo la opci on ((generar c odigo para borrar varios beans en listado)). Un bot on de edici on, que llevar a a la p agina de edici on de la entrada cuyo bot on se pulse, permitiendo al usuario modicar el registro, en caso de que se haya seleccionado al generar el c odigo la opci on ((generar JSP de edici on)). Si existen propiedades correspondientes a archivos binarios (BLOBs) se muestran, por cada uno, dos botones: Descargar binario: Permite descargar el binario almacenado en la base de datos al ordenador del usuario. Si hay alg un chero almacenado en el registro, el bot on aparecer a de color naranja (activo ) y al pulsarlo comenzar a la descarga6 . Si dicho registro no almacena un binario, el bot on se muestra gris (inactivo ) y se avisa al usuario de que no hay datos almacenados al pulsarlo. Borrar binario: Permite borrar el chero binario del registro seleccionado. Bajo el listado se ofrecen tambi en los botones de ((Borrar)), que elimina los registros seleccionados en la tabla, ((Nuevo)), que lleva a la vista de edici on de la entidad mostrando los registros en blanco para la adici on de un nuevo registro, y ((Volver)), que permite regresar a la p agina visitada anteriormente. Todos los estilos utilizados, tanto en el buscador como en el listado, est an denidos en la hoja de estilos CSS proporcionada con la generaci on de esqueleto. 6.2.1.2. JSP de edici on
Al editar o insertar un registro, el controlador llama a la vista de edici on. En esta pantalla se presentan al usuario casillas para rellenar con los datos oportunos el nuevo registro, o modicar los ya existentes en caso de tratarse de una edici on. Nuevamente si existe un campo de tipo fecha, se proporciona el calendario junto a la casilla correspondiente.
6 Como se explicar a m as adelante, tanto las cargas como las descargas de binarios se hacen mediante streaming, lo que evita saturar la memoria del servidor de aplicaciones, a la vez que permite el uso de, por ejemplo, reproductores multimedia, de forma que no tengan que esperar a la descarga del archivo completo para comenzar la reproducci on del recurso, sino que en cuanto acabe la descarga del primer ( (trozo) ) de chero comenzar a, almacenando en el b ufer los datos de los siguientes trozos conforme se vayan descargando del servidor.
60
Si la clave primaria es u nica y num erica se asume que es autonum erica, por lo que no se muestra el campo para a nadir dicho dato. Se asume que al realizar la inserci on le ser a asignado un nuevo valor de clave primaria al registro. Si existen campos binarios (BLOBs) el formulario proporcionado es de tipo multipart, que permite subir cheros grandes en partes al servidor. Si es una operaci on de edici on, tanto si hay binarios almacenados como si no, aparecen los campos de selecci on de archivo vac os. Si se modican, se a nadir a o sobreescribir a el binario de la base de datos por el subido recientemente. Si se dejan en blanco, no se modicar an dichos campos en la base de datos. Para la operaci on de eliminar el binario almacenado en un registro, se proporciona el bot on ((Borrar binario)) en la pantalla de listado. Al nal de la p agina se proporcionan los botones de ((Aceptar)) y ((Volver)), que retornar an al usuario a la pantalla de listado, guardando o descartando respectivamente las modicaciones. Entidades relacionadas En caso de que se haya generado componentes para las tablas relacionadas, en esta p agina aparecer an adem as: Buscador y listado de cada entidad relacionada si se seleccion o la opci on de tratar entidades relacionadas en la misma p agina que la principal (gura 6.1 en la p agina 57). Botones de listado de entidades secundarias si no se seleccion o dicha opci on, que llevar a a la vista de listado de la entidad secundaria (gura 6.2 en la p agina 58). En ambos casos el buscador y listado tendr an id entico comportamiento que los de la entidad principal, pero mostrar an u nicamente los campos correspondientes a dicha entidad principal. Por ejemplo, en el caso de veh culos y usuarios, al editar un usuario y mostrar la lista de veh culos, s olo se listar an los veh culos correspondientes a dicho usuario, y no los de los dem as.
Validaciones de datos introducidos

Las validaciones de los datos introducidos se realizan por defecto en la m aquina del cliente, mediante el int erprete de JavaScript del usuario. Si los requisitos de accesibilidad de la aplicaci on impiden el uso de dicho sistema, se han de eliminar estas validaciones y descomentar las ofrecidas en los servlets.
Etiquetas
Todos los textos que guran en la interfaz son generados mediante etiquetas, mediante el tag etiqueta proporcionado con el esqueleto, generadas en un trozo del chero etiquetas.properties que se entrega con cada paquete de c odigo. 61
6.2.2.
Capa web - Servlet (Controlador)
El componente correspondiente al controlador que manejar a las peticiones del usuario, provinientes de la vista, e interactuar a con el modelo, consultando o modicando los datos, se proporciona tambi en en el paquete de c odigo generado para cada entidad. El servlet proporcionado contar a con las siguientes funciones7 : perform(), que es la encargada de recibir la llamada de la vista y dirigir la petici on del usuario hacia la acci on del servlet que corresponda. inicio(), es la funci on inicial del controlador de la entidad. Se encarga de seleccionar la vista de listado, tras establecer un ltro de b usqueda nulo (para que la lista muestre todos los registros) y una ordenaci on por defecto. Para obtener la lista de elementos llamar a a la funci on getListaEntidad () de la fachada del modelo. listar(), se encarga de crear la vista de listado tras haber insertado, actualizado o borrado un registro. Mantiene la ordenaci on, la paginaci on y el ltro de b usqueda establecidos antes de comenzar el proceso de edici on, inserci on o borrado. Para obtener la lista de elementos llamar a a la funci on getListaEntidad () de la fachada del modelo. listarSession(), de cometido similar a listar(), salvo que devuelve la vista de listado con la paginaci on, ordenaci on y ltro de b usqueda denidos por defecto en la sesi on. Para obtener la lista de elementos llamar a a la funci on getListaEntidad () de la fachada del modelo. paginar(), establece el cambio de orden o la agrupaci on en p aginas de n elementos (10 por defecto). Dene la propiedad de la entidad por la que se ordena, el tipo de ordenaci on (ascendente o descendente), y el n umero de p agina que va a mostrar la vista. Tras componer la lista de elementos ordenada, se invoca a la vista de listado. Para obtener la lista de elementos llamar a a la funci on getListaEntidad () de la fachada del modelo. buscar(), crea un ltro de b usqueda a partir de los par ametros introducidos en el formulario de buscador, y devuelve al usuario la lista de elementos que coincidan con dicho ltro. Para obtener la lista de elementos llamar a a la funci on getListaEntidad () de la fachada del modelo. nuevo(), Esta funci on u nicamente invoca a la vista de edici on de la entidad correspondiente. En caso de que la tabla de la base de datos que representa dicha entidad tenga clave primaria u nica y num erica no aparece el campo correspondiente a esta propiedad, ya que se asume que es autonum erica y la capa de acceso a datos le asignar a autom aticamente un valor.
7 Nota: en los nombres de las funciones, el literal Entidad equivale al nombre de la entidad que se introdujo en la etapa de selecci on de par ametros del bloque funcional de generaci on de c odigo. Por ejemplo, la funci on getEntidad() equivaldr a a getPropietario() en el ejemplo de las entidades Propietario y Veh culo ya usado. As mismo, el literal Propiedadbinaria equivale al nombre de la propiedad cuyo tipo de datos almacenados es BLOB. Por ejemplo, getFotograaCatalogo().
62
insertar(), Esta funci on, que ser a llamada desde la vista de edici on una vez se hayan rellenado los campos correspondientes a las propiedades de la entidad, llamar a a la funci on insertEntidad () de la fachada del modelo, pasando un objeto del tipo de la entidad. editar(), invoca la vista de edici on, con los valores de todas las propiedades del objeto que se quiere editar, para que el usuario modique las que desee. Al igual que la funci on insertar(), si la clave primaria de la entidad es u nica y num erica no se recoge dicho valor, puesto que no ser a posible modicarlo. actualizar(), al conrmar los cambios, esta funci on env a el objeto modicado a la funci on updateEntidad () de la fachada de la capa de l ogica de negocio. borrar(), recoge el valor (o valores) de la clave primaria del registro y llama a la funci on deleteEntidad () de la fachada. borrarVarios(), recoge el valor de la clave primaria de los registros seleccionados y llama a la funci on deleteListaEntidad () de la fachada de la capa de l ogica de negocio. createDescriptorTabla(), que se encarga de crear los descriptores de la tabla y las columnas de los listados. Esta funci on es llamada por las anteriores cada vez que se ha de presentar un listado en pantalla. createEntidad(), que se encarga de recoger los valores de la vista para crear un objeto del tipo correspondiente a la entidad con la que se trabaja. getSelected(), averigua las claves primarias de los registros que est an seleccionados en el listado. tratarError(), dene el comportamiento de la aplicaci on en caso de que se produzca alg un error. 6.2.2.1. Servlets de entidades con binarios
En caso de que en la entidad para la que se ha generado c odigo posea campos que almacenan binarios (de tipo BLOB), adem as de las funciones anteriores se generan las siguientes: getPropiedadbinariaEntidad(), que llamar a a la funci on getPropiedadbinariaEntidad () de la fachada y devolver a al usuario el archivo binario almacenado en la base de datos. La descarga del chero se efect ua mediante streaming, es decir, se env an los trozos concatenados en vez de cargar el chero de una vez, lo que mejora el rendimiento y evita el colapso del servidor de aplicaciones por desbordamiento de memoria. delPropiedadbinariaEntidad(), que llamar a a la funci on delPropiedadbinariaEntidad () de la fachada borrando el binario almacenado.
63
createEntidadMultipart(), cuya funci on es recuperar los atributos del registro que se introduce en las pantallas de inserci on o actualizaci on, ya que en caso de haber binarios los formularios de dichas pantallas son de tipo multipart. La funci on createEntidad () no tiene en cuenta los campos binarios. Tambi en las funciones insertar() y actualizar() sufren cambios al aparecer atributos binarios, puesto que se subir an por partes al servidor de bases de datos: primero se almacenan los atributos no binarios, y luego se divide el binario en trozos y mediante la funci on appPropiedadbinariaEntidad de la fachada se env an los fragmentos al servidor. Esta funci on optimiza la memoria consumida en el servidor de aplicaciones, evitando que se colapse por overow. 6.2.2.2. Servlets de entidades relacionadas
En caso de que se hubieran seleccionado tablas relacionadas en la fase de selecci on de par ametros en el bloque funcional de generaci on de c odigo de Genereitor, aparecer an por cada entidad secundaria funciones id enticas a las de la principal, pero incluir an el nombre de la entidad a la que ofrecen funcionalidad. Por ejemplo, en el caso de Vehiculo, que es entidad relacionada de Propietario: insertar() corresponder a a la inserci on de una entidad Propietario, es decir, la entidad principal. insertarVehiculo() corresponder a a la inserci on de una entidad Vehiculo, es decir, la entidad relacionada.
6.2.3.
Capa de l ogica de negocio - Fachada
Aunque los cheros de fachada ya se proporcionan con la generaci on de esqueleto, se van completando conforme se suceden las generaciones de c odigo de las diferentes entidades de la base de datos. El paquete de c odigo generado para una entidad contiene dos trozos de la fachada. En caso de que la aplicaci on utilice EJBs: Trozo de AplicacionFacadeEJB. Trozo de AplicacionFacadeEJBBean. Y si se utilizan POJOs: Trozo de FacadeBL. Trozo de FacadeBLImpl. En conjunto, la fachada contiene las llamadas a todas las funciones disponibles en la l ogica de negocio de la aplicaci on. 64
6.2.4.
Capa de l ogica de negocio - Componentes
Los componentes de la capa de l ogica de negocio, ya sean EJB o POJO, implementan la forma en la que los datos han de ser tratados, y realizan las llamadas a la capa de acceso a datos, que ser a la que interact ue con la base de datos para obtener o modicar la informaci on contenida en ella. Tambi en manejan la apertura y clausura de las instancias de la conexi on con el servidor de bases de datos, y de ser necesario, implementan soporte transaccional para dichas conexiones. La gesti on transaccional garantiza que la base de datos va a mantener siempre un estado ntegro y consistente, de manera que si falla la ejecuci on de una operaci on, se devuelve la base de datos al estado inmediatamente anterior al comienzo de la ejecuci on de dicha operaci on (rollback ), de modo que no queden operaciones a medias que pongan en peligro la integridad de la base de datos. Las operaciones implementadas en dichos componentes ser an, para cada entidad de la base de datos: getEntidad(): Llama a la capa de acceso a datos para que devuelva un objeto del tipo de la entidad, con todas sus propiedades. Como par ametro se le ha de pasar un objeto del tipo de la entidad con, al menos, el valor de los campos que compongan la clave primaria. De otra forma, lanzar a una excepci on. getListaEntidad(): Llama a la capa de acceso a datos para que devuelva una lista de todos los registros contenidos en ella. Tambi en se puede pasar un ltro del tipo de la entidad, para que devuelva s olo los registros que coincidan con los criterios que dicho ltro impone. deleteEntidad(): Llama a la funci on deleteListaEntidad() tras crear una lista de un s olo elemento, que ser a el que tenga por clave primaria la del ltro recibido como par ametro. deleteListaEntidad(): Elimina todos los registros de la base de datos que coincidan con los criterios establecidos por el ltro que se recibe como par ametro. Este ltro no tiene por qu e poseer un valor de clave primaria. insertEntidad(): Llama a la capa de acceso a datos para que inserte el registro que corresponde al ltro que se recibe como par ametro. Si la clave primaria de la entidad es u nica y num erica, retornar a el valor de la clave primaria que la capa de acceso a datos ha asignado al registro, ya que se asumir a autonum erica. updateEntidad(): Llama a la capa de acceso a datos para que actualice el registro con clave primaria la del ltro que recibe como par ametro, con los atributos de dicho ltro. Gesti on transaccional y de conexiones: beginTransaction(): marca el comienzo de la transacci on (s olo EJB). commitTransaction(): naliza y conrma el exito de la transacci on (s olo EJB). 65
rollbackTransaction(): devuelve la transacci on al estado que ten a al hacer beginTransaction() (s olo EJB). getConnection(): abre una conexi on con la base de datos. closeConnection(): naliza la conexi on. En caso de que la entidad contenga campos binarios, se proporcionan adem as: appendPropiedadbinariaEntidad(): Llama a la capa de acceso a datos para que inserte un trozo del binario en un registro. La clave primaria y el trozo del binario son atributos del ltro que recibe como par ametro. getPropiedadbinariaEntidad(): Consulta a la capa de acceso a datos el contenido del binario almacenado en la propiedad correspondiente a esta funci on. deletePropiedadbinariaEntidad(): Llama a la capa de acceso a datos para que elimine el binario almacenado en la propiedad correspondiente.
6.2.5.
Capa de l ogica de negocio - Excepciones
Para cada entidad sobre la que se genera c odigo, se proporciona tambi en la implementaci on de sus excepciones. Evidentemente, dicha implementaci on ser a muy b asica, puesto que no se pueden conocer de forma autom atica las situaciones en las que la entidad podr a causar excepciones, ni qu e desea hacer el programador para manejarlas. Por ejemplo, la implementaci on de la excepci on para una entidad Cat alogo ser a la siguiente:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
package com . comex . taller . bl . exception ; import com . comex . common . exception . BaseException ; public class C a t a l o g o E x c e p t i o n extends BaseException { /* * * Constructor por defecto . El error sera E R R O R _ I N D E F I N I D O * @param texto El texto de la exception */ public C a t a l o g o E x c e p t i o n ( String texto ) { super ( texto ) ; } /* * * Constructor con codigo de error * @param texto El texto de la exception * @param codigoError El codigo de error de la exception */ public C a t a l o g o E x c e p t i o n ( String texto , int codigoError ) { super ( texto , codigoError ) ; } /* * * Constructor con codigo de error * @param codigoError El codigo de error de la exception */ public C a t a l o g o E x c e p t i o n ( int codigoError ) { super ( codigoError ) ; } }
66
Como se aprecia, hereda las funciones de la superclase BaseException a modo de excepci on gen erica, pero se contempla la posibilidad de personalizar su comportamiento.
6.2.6.
Capa de acceso a datos - Componentes
Las clases Java correspondientes a la capa de acceso a datos ser an las encargadas de comunicarse con la base de datos, y contendr an las consultas o modicaciones necesarias para realizar su tarea. Las funciones implementadas en la capa de acceso son llamadas por los componentes de la l ogica de negocio (EJBs o POJOs), y hacen uso de la API jdbc que proporciona J2EE para comunicarse con la base de datos. Implementan las siguientes funciones: getEntidad() a partir del ltro proporcionado, que habr a de tener asignados al menos los valores de la clave primaria, devuelve todas las propiedades del registro. getListaEntidad() devuelve todos los registros de la entidad que coincidan con los criterios de b usqueda que establece el ltro. insertEntidad() inserta un registro de la entidad, con los valores del ltro. Si la entidad tiene clave primaria u nica y num erica se asume que es autonum erica, no se pasar a valor para la clave primaria, sino que se recibir a de la base de datos al insertar el registro, asumiendo que el sistema de base de datos le asignar a dicho valor al registro. El valor de la clave primaria se devuelve al completar con exito la operaci on. Si la clave primaria no es autonum erica, la funci on no devuelve nada. insertListaEntidad() esta funci on no se usa originalmente, simplemente admite un BaseBeanSet de ltros y por cada elemento de dicho set, llama a la funci on insertEntidad(). updateEntidad() actualiza el registro de la entidad con los valores del ltro. updateListaEntidad() esta funci on no se usa originalmente, simplemente admite un BaseBeanSet de ltros y por cada elemento de dicho set, llama a la funci on updateEntidad(). deleteEntidad() crea un BaseBeanSet de una posici on, que contendr a el ltro que acepta como par ametro, y llama a deleteListaEntidad(). deleteListaEntidad() borra los registros cuyas claves primarias coincidan con las de los ltros contenidos en el BaseBeanSet que acepta como par ametro. Las funciones insertListaEntidad() y updateListaEntidad() no se utilizan en la aplicaci on generada, puesto que los casos en los que se quiera insertar varios registros en una misma operaci on son escasos. De todos modos se ofrecen por si en un futuro se decidiera dotar a la aplicaci on de esta posibilidad.
67
Tampoco se utiliza deleteEntidad(), ya que el borrado se suele hacer por lista de varios elementos, borrando los que el usuario seleccion o en el listado de la vista. Esta funci on se mantiene por si el desarrollador decide a nadir la funcionalidad de borrado unitario. No obstante, dicha operaci on se ejecuta actualmente con deleteListaEntidad(), donde la lista ser a de un u nico elemento. Acceso a datos de entidades con binarios Aparte de las funciones ya expuestas, para aquellas entidades que tengan alguna propiedad de tipo binario (BLOB), se a nadir an las siguientes funciones: appendPropiedadbinariaEntidad() inserta en la base de datos el objeto binario en la propiedad de la entidad correspondiente, de manera que si el tama no total del binario excede de la longitud establecida (512kb por defecto), a nadir a s olo un trozo del chero. Esta funci on ser a llamada recurrentemente hasta completar la totalidad del binario. getPropiedadbinariaEntidad() obtiene el objeto binario de la base de datos y lo devuelve a la fachada. deletePropiedadbinariaEntidad() elimina el objeto binario de la base de datos. Estas funciones corresponden a una u nica propiedad de la entidad, de manera que si esta contase con varias propiedades binarias, se generar an las funciones para cada una de dichas propiedades. Acceso a datos con entidades relacionadas En caso de que se hayan seleccionado entidades relacionadas a la tabla principal, se generar a una implementaci on diferente para cada entidad, tanto principal como relacionadas, al contrario que en los servlets, en los que se generaban acciones para todos los objetos dentro del mismo componente.
6.2.7.
Capa de acceso a datos - PL/SQL
Si el sistema de bases de datos elegido para la nueva aplicaci on es Oracle y se ha seleccionado PL/SQL como m etodo de acceso a datos, se generar an las funciones correspondientes en dicho lenguaje para la entidad o entidades seleccionada. Un problema del servidor de bases de datos Oracle es que no acepta nombres de funciones, procedimientos o identicadores de m as de 30 caracteres. Por esto, se realiza un recorte de los nombres de las tablas en la base de datos, a partir de los cuales se crean dichos identicadores, de forma que queden reconocibles por el usuario y no excedan de la longitud m axima permitida. Este proceso de recorte de los identicadores de funci on se representa en la gura 6.3 en la p agina siguiente.
68
Figura 6.3: Proceso de recorte de identicadores en funciones PL/SQL
Por ejemplo, imaginemos que tenemos una tabla APLICACION TABLA DE NOMBRE EXTREMADAMENTE LARGO. El nombre de la funci on PL/SQL original ser a APLICACION FN INSERT TABLA DE NOMBRE EXTREMADAMENTE LARGO, donde: APLICACION ser a el nombre de la aplicaci on para la que se est a generando el c odigo PL/SQL. FN indica que el c odigo que sigue corresponde a una funci on PL/SQL. En dicho lenguaje hay funciones y procedimientos, que se diferencian en que las primeras retornan un valor, mientras que los u ltimos no. Un procedimiento se identicar a con el literal PR. INSERT es el identicador de la tarea que realiza esta funci on, en este caso 69
insertar. TABLA DE NOMBRE EXTREMADAMENTE LARGO es el nombre de la tabla. Vemos que el identicador de la funci on generado excede de la longitud m axima permitida, por lo que habr a que recortarla. APLIC5 ACION10 FN I15 NSERT20 TABL25 A DE 30 NOMBR35 E EXT40 REMAD45 AMENT50 E LAR55 GO, 57 caracteres en total. El primer paso ser a suprimir los guiones bajos del nombre de la tabla: APLIC5 ACION10 FN I15 NSERT20 TABL25 ADENO30 MBREE35 XTREM40 ADAME45 NTELA50 RGO, 53 caracteres en total. Como el nombre sigue siendo demasiado largo, recortaremos los componentes del nombre de la tabla (TABLA, DE, NOMBRE, EXTREMADAMENTE y LARGO ) empezando por el primero y dej andolos con una longitud m nima de tres caracteres: APLIC5 ACION10 FN I15 NSERT20 TABD25 ENOMB30 REEXT35 REMAD40 AMENT45 ELARG50 O, tras recortar ((TABLA)) convirti endolo en ((TAB)). ((DE)) tiene menos de 3 caracteres, as que no se recorta. APLIC5 ACION10 FN I15 NSERT20 TABD25 ENOMB30 REREE35 XTREM40 ADAME45 NTELA50 RGO, tras recortar ((NOMBRE)) convirti endolo en ((NOM)). Tras recortar todos los componentes: APLIC5 ACION10 FN I15 NSERT20 TABD25 ENOME30 XTLAR35 , 35 caracteres en total. Tras nalizar los recortes todav a se excede la longitud permitida, por lo que, como u ltimo recurso, se trunca el nombre de la funci on hasta el m aximo n umero de caracteres permitidos: APLIC5 ACION10 FN I15 NSERT20 TABD25 ENOME30 , 30 caracteres en total, por lo que ya es una longitud v alida. A partir de estos identicadores recortados se crear a el c odigo necesario para generar el script PL/SQL que, una vez compilado en el servidor de bases de datos, se convertir a en las funciones y procedimientos disponibles para realizar el tratamiento de los datos. Las funciones y procedimientos generados son: GET ENTIDAD, funci on que recibe la clave primaria de la entidad y devuelve todas sus propiedades. GET ENTIDADES, funci on que recibe un ltro del tipo de la entidad, y devuelve todos los registros que coinciden con los criterios de b usqueda establecidos en el ltro. INSERT ENTIDAD, a nade un registro del tipo de la entidad a la base de datos. Dependiendo de si su clave primaria es autonum erica o no, ser a funci on y devolver a el valor de la clave autonum erica del registro que se acaba de 70
a nadir o procedimiento no devolver a nada, puesto que la clave primaria ser a proporcionada con el resto de par ametros de entrada. UPDATE ENTIDAD, procedimiento que modica las propiedades de un registro de la base de datos. DELETE ENTIDADES, procedimiento que elimina de la base de datos los registros cuya clave primaria coincida con las de la lista que se pasa por par ametro. Si la entidad para la que se est a generando c odigo posee propiedades que almacenan objetos binarios (BLOB), para cada una de dichas propiedades se generar an tambi en las siguientes funciones y procedimientos: a el procedimiento encargado de a nadir los APPBLOBn ENTIDAD, que ser trozos del chero binario al registro de la base de datos. on que devolver a el objeto binario almacenado GETBLOBn ENTIDAD, funci en el registro. DELBLOBn ENTIDAD, procedimiento que asigna valor NULL a la propiedad binaria del registro. Como en una entidad puede haber varios campos binarios y es necesario disponer de estas tres funciones para cada uno de estos campos, el nombrado de dichas funciones se realiza de forma diferente a las anteriores. Se otorgan los nombres de las funciones numer andolas (APPBLOB1 ENTIDAD para el primer campo binario, APPBLOB2 ENTIDAD para el segundo, etc), en lugar de incluir el nombre de la propiedad sobre la que act uan. Esto es debido a la restricci on de 30 caracteres de Oracle. Por ello, antes de la implementaci on de estas funciones se se nala en forma de comentario a qu e par ametro representan.
6.2.8.
Capa de acceso a datos - Beans
Un bean es un objeto Java que representa a una entidad de la base de datos. Una entidad tiene una serie de propiedades, que estar an en consecuencia representadas en el bean. Aparte de las propiedades que tiene la propia entidad en la base de datos, es com un que en la implementaci on del bean aparezcan otras propiedades adicionales, que enriquecen el objeto. Por ejemplo, en el caso de las entidades Propietario y Veh culo, visto en la gura 2.1 en la p agina 21, se observa que en ambos casos hay funciones (se naladas en negrita) que no se corresponden con ninguno de los par ametros de las tablas, sino que representan la relaci on entre ambas (listaVeh culos en propietario, y propietario en veh culo) Estas propiedades son en s mismas objetos dentro de los objetos, que ser an utilizadas por la capa de l ogica de negocio cuando se necesite analizar dichas relaciones entre tablas, pero no se utilizar an a la hora de leer o escribir en la base de datos. Otro ejemplo es el caso de las tablas con BLOBs, como la entidad Cat alogo: 71
TALLER CATALOGO ID CATALOGO NUMBER ID VEHICULO NUMBER FOTOGRAFIA BLOB DESCRIPCION CLOB Sin embargo, se observan los siguientes par ametros en la implementaci on del bean:
1 2 3 4 5 6 7 8
public static final String TABLA = " T AL L ER _C AT A LO GO " ; public static final String SECUENCIA = " T A L L E R _ S Q _ C A T A L O G O " ; protected Long idCatalogo ; protected Long idVehiculo ; protected byte [] fotografia ; protected String pathFo tografi a ; protected Integer l e n g t h F o t o g r af i a ; protected String descripcion ;
Aparte de las dos constantes que aparecen al principio, que se nalan la tabla que representa a esta entidad en la base de datos y la secuencia que le corresponde (es una tabla con clave primaria autonum erica), existen dos propiedades extra, pathFotograa y lengthFotograa, cuyos valores no se almacenan en la base de datos, sino que son utilizados por la l ogica de la apliaci on para desempe nar diferentes funciones. Las funciones que implementa cada bean son las siguientes: Constructora vac a: inicializa un objeto del tipo la entidad correspondiente con todos sus valores nulos. clone: crea una copia (clon) de un objeto del tipo la entidad correspondiente. get de cada propiedad: devuelve el valor de dicha propiedad, en su tipo de datos primario si lo hay (e.g. int). getObject de cada propiedad: devuelve el valor de dicha propiedad en su tipo de datos objeto (e.g. Integer). set de cada propiedad: establece el valor de dicha propiedad, en su tipo de datos primario si lo hay (e.g. int). setObject de cada propiedad: establece el valor de dicha propiedad en su tipo de datos objeto (e.g. Integer). Ejemplo de algunas funciones correspondietes al bean Catalogo ser an: Listing 6.1: Catalogo.java
1 2 3 4 5 6 7 8 9
public Catalogo () { idCatalogo = null ; idVehiculo = null ; fotografia = null ; descripcion = null ; path Fotogra fia = null ; l e n g t h F o t o g r a f i a = null ; }
72
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54
public Object clone () { Catalogo nuevo = ( Catalogo ) super . clone () ; nuevo . idCatalogo = idCatalogo ; nuevo . idVehiculo = idVehiculo ; nuevo . fotografia = fotografia ; nuevo . descripcion = descripcion ; nuevo . path Fotograf ia = pa thFotog rafia ; nuevo . l e n g t h F o t o gr a f i a = l e n gt h F o t o g r a f i a ; return nuevo ; } /* * * Devuelve el campo idVehiculo como Object * @return idVehiculo como Object */ public Long g e t I d V e h i c u l o O b j e c t () { return idVehiculo ; } /* * * Informa el campo idVehiculo como Object * @param idVehiculo El nuevo valor del campo idVehiculo */ public void s e t I d V e h i c u l o O b j e c t ( Long idVehiculo ) { this . idVehiculo = idVehiculo ; } /* * * Devuelve el campo idVehiculo como tipo basico * @return idVehiculo como tipo basico */ public long getIdVehiculo () { if ( idVehiculo != null ) return idVehiculo . longValue () ; else return ( long ) 0; } /* * * Informa el campo idVehiculo como tipo basico * @param idVehiculo El nuevo valor del campo idVehiculo */ public void setIdVehiculo ( long idVehiculo ) { this . idVehiculo = new Long ( idVehiculo ) ; }
73
Cap tulo 7
Generaci on de script para tablas maestras

Las tablas maestras son aquellas que u nicamente contienen informaci on respecto a la entidad a la que representan. Por tablas maestras se entienden tablas sencillas, que generalmente ser an de tipo identicadorvalor y, en caso de mantener alguna relaci on con otra tabla, una clave ajena. Por ejemplo, en el caso de la gura 7.1, las tablas u nicamente contienen un identicador y un nombre, y en caso de la tabla MUNICIPIO y PROVINCIA, la clave ajena que referencia a la PROVINCIA y COMUNIDAD AUTONOMA a la que pertenecen respectivamente.
Figura 7.1: Ejemplo de tablas maestras relacionadas.
7.1.
7.1.1.
Fase 1: Conexi on
El primer paso para la elaboraci on de las partes de c odigo correspondientes a una entidad de la base de datos es la conexi on al servidor de bases de datos. Por ello, la primera fase de este bloque funcional es la introducci on de los datos de conexi on: Sistema de bases de datos (lista desplegable con todos los sistemas de bases de datos soportados por la herramienta). 74
DE SCRIPT PARA TABLAS MAESTRAS CAP ITULO 7. GENERACION
Host. Puerto. SID, o nombre de la base de datos. Usuario. Contrase na. Tambi en se proporciona un pulsador con el literal ((Default )), cuya funci on es autocompletar el siguiente bloque con los datos de conexi on de las bases de datos de desarrollo que hay en la factor a de software de la empresa, seg un el servidor de bases de datos seleccionado. Con varias pulsaciones sobre este literal se rota de forma c clica entre las diferentes conexiones para un mismo sistema de bases de datos, puesto que se da el caso que para algunos sistemas hay varias bases de datos de desarrollo. Al pulsar el bot on ((Conectar)), se realizan una serie de validaciones mediante JavaScript para comprobar que los datos introducidos tienen el formato correcto: Sistema de bases de datos, Host, SID y usuario no pueden tomar valores nulos. Puerto ha de tener valor num erico y no nulo. Si no se introduce un valor para el campo contrase na, se avisa al usuario mediante un mensaje junto al bot on ((Conectar)), y se hace parpadear brevemente dicho campo para llamar su atenci on. Si se vuelve a pulsar el bot on ((Conectar)) se lanzar a efectivamente la conexi on contra el servidor, indiferentemente de que se haya introducido una contrase na. Si existe alg un error en los datos se informar a al usuario mediante una caja de texto situada al principio de la p agina. De lo contrario, se lanzar a la conexi on al servidor. Es posible que los datos introducidos, pese a tener un formato v alido, no sean correctos y el servidor de bases de datos no responda o rechace la conexi on. De ser as , se informar a nuevamente al usuario del error y se le permitir a modicar los datos introducidos para volver a lanzar la conexi on1 .
7.1.2.
Fase 2: Selecci on de tablas
En la siguiente fase se ofrece una vista que cuenta con una lista doble. En una de las listas aparecen todas las tablas y vistas existentes en la base de datos, que ser an a nadidas al seleccionarlas a la otra lista. El programador podr a a nadir tantas tablas como considere necesarias.
1 Debido a que algunos sistemas de bases de datos ofrecen m as informaci on que otros cuando ocurre un error en la conexi on, dependiendo del sistema elegido los textos explicativos del error ser an m as o menos espec cos. Por ejemplo, mientras que un sistema puede devolver un error de tipo usuario no v alido, otro lanzar a simplemente error en la conexi on.
75
Al pulsar el bot on ((Siguiente)), se analizan las claves ajenas de las tablas seleccionadas, y se a naden a la lista autom aticamente las tablas que son referenciadas por las que el usuario ha seleccionado. Por ejemplo, si en la aplicaci on Taller (gura 4.3 en la p agina 41) se seleccionadir an autom aticamente las tablas nase la tabla TALLER RECLAMACION, se a TALLER REPARACION, TALLER OPERACION, TALLER PIEZA, TALLER VEHICULO y TALLER PROPIETARIO, conforme al esquema 7.2.
Figura 7.2: Tablas a nadidas autom aticamente por sus relaciones.
7.1.3.
Fase 3: Selecci on de campos
En esta u ltima etapa se seleccionar an los campos que aparecer an en la interfaz generada por tablas maestras en diversos apartados, tales como el buscador, la vista de edici on o la de detalle. Consta de varios bloques. En el primer bloque se introducir an el nombre de aplicaci on y el del paquete base. Los siguientes bloques (tantos como tablas se hayan seleccionado) consisten en un listado de los campos que forman parte de cada tabla, y una serie de opciones que permitir an personalizar la interfaz generada por la aplicaci on tablas maestras. Dichas opciones son: Campo por defecto: Para cada entidad se ha de seleccionar un campo por defecto, que ser a el campo por el que los listados iniciales aparecer an ordenados en la interfaz. ID: Indica el nombre del campo dentro de la base de datos. Clase: Indica el tipo de dato SQL de cada campo. Si se sit ua el puntero del rat on sobre este campo, aparece un tooltip (mediante el tag tooltip de Genereitor) que indica el tipo de dato Java que le corresponde. KEY: Indica si un campo es clave primaria de la tabla.
76
Obl: Indica si el campo tiene la restricci on de obligatoriedad activada en la base de datos. De no ser as , se permite establecer dicha restricci on a nivel de aplicaci on. Si se pulsa en el literal de la cabecera de esta columna se activa o desactiva esta opci on para todos los campos de la tabla. Literal: Es el texto que acompa nar a a las casillas de los formularios generados por la aplicaci on tablas maestras. Por defecto se ofrece el nombre del campo transcrito a formato Java (ID PROPIETARIO idPropietario). Listado: Permite seleccionar qu e campos aparecer an en la vista de listado. Si se activa o desactiva la casilla de la cabecera de la tabla, se activan o desactivan todos los campos de la tabla para dicha opci on. Al activarse un campo, aparece un valor en la columna ((Idx)), que representa el orden de aparici on de los campos en la lista. Dicho orden se puede modicar, tarea que se llevar a a cabo arrastrando y soltando con el rat on las las de la columna, hasta ordenar de forma ((visual)) tal y como se desea que aparezcan los campos. Al soltar los registros los valores del ndice que marcan el orden se actualizar an. Ord: Esta opci on s olo est a activa para los campos que se han seleccionado para aparecer en el listado, e indica si se ofrecer a la posibilidad de ordenar dicho listado por cada campo en particular. Al seleccionar un campo para listado, se activa esta opci on por defecto. Buscador: Indica los campos que aparecer an en el formulario de buscador. Idx: Indica la posici on en la que aparecer an los campos del formulario de buscador. El orden se establece al seleccionar los campos de forma secuencial, es decir, el primero en seleccionarse recibir a el valor 1, el segundo el 2, etc. MaxL: Indica la longitud m axima que aceptar a la casilla de buscador para cada campo. Detalle: Indica los campos que aparecer an en el formulario de detalle. Idx: Indica la posici on en la que aparecer an los campos del formulario de detalle. El orden se establece al seleccionar los campos de forma secuencial, es decir, el primero en seleccionarse recibir a el valor 1, el segundo el 2, etc. MaxL: Indica la longitud m axima que aceptar a la casilla de detalle para cada campo. Claves Ajenas: En esta columna s olo aparecer an opciones para los campos que sean clave ajena de alguna otra tabla. La casilla permite indicar que se desea tener en cuenta la relaci on entre tablas. Para los campos que formen parte de una misma relaci on, estas opciones funcionar an de manera paralela, es decir, al activar el usuario un campo, autom aticamente se activar an todos los que forman parte de dicha clave ajena. ?: Al poner el cursor del rat on sobre este peque no literal se mostrar a, por medio de un tooltip, la tabla y el campo a los que hacen referencia cada clave ajena, a modo informativo.
77
Campo: Este u ltimo seleccionable es una lista de los campos que forman parte de la tabla referenciada por cada clave ajena, permitiendo elegir al usuario el campo de la tabla referenciada que se va a mostrar en la vista generada por tablas maestras. Esto se debe a que generalmente las claves primarias de las tablas son c odigos o campos autonum ericos que no aportan un signicado claro al usuario, por ello es mejor describir la tabla relacionada por un campo m as descriptivo. Por ejemplo, si hubiera una tabla relacionada ((persona)), ser a m as intuitivo mostrar el valor del campo ((nombre)) que el ((nif)), aunque este u ltimo fuera la clave primaria que realmente es referenciada. Tambi en para cada tabla se establece un nombre, que dar a t tulo a las vistas de edici on, detalle, buscador y edici on de cada entidad.
7.2.
Resultado
El paquete obtenido al pulsar el bot on ((generar)) contiene los siguientes archivos:
7.2.1.
Script para tablas maestras
Es un chero XML que, en combinaci on con la aplicaci on tablas maestras de la empresa, generar a la l ogica necesaria para tratar las tablas maestras de la aplicaci on. Los motivos de utilizar este sistema y no generar un paquete para cada entidad mediante la funcionalidad de generaci on de c odigo son que las tablas maestras son muy sencillas, por lo que con este sistema se reutilizan muchos componentes cuya implementaci on resultar a redundante si se implementaran de otro modo. As , las tablas comunes compartir an la vista, puesto que har an uso de los mismos JSP de listado, b usqueda, edici on y detalle, tendr an un u nico componente (EJB o POJO) en la capa de aplicaci on y un u nico servlet en la capa web. El script obtenido para las tablas COMUNIDAD AUTONOMA, PROVINCIA y MUNICIPIO vistas en la gura 7.1 en la p agina 74 ser a el siguiente:
1 2 3
4 5 6 7 8 9 10
<? xml version = " 1.0 " encoding = " ISO -8859 -15 " ? > < tablas > < tabla clase = " com . comex . aplicacion . dal . bean . C o m u n i d a d A u t o n o m a " c am po Po r De fe ct o = " NOMBRE " nombre = " Comunidad Aut o noma " id = " APLICACION_COMUNIDAD_AUTONOMA "> < campo obligatorio = " true " clase = " java . lang . Long " pk = " true " nombre = " IdComunidad " id = " ID_COMUNIDAD " > < detalle maxLength = " 22 " size = " 100 " indice = " 1 " / > </ campo > < campo obligatorio = " true " clase = " java . lang . String " pk = " false " nombre = " Nombre " id = " NOMBRE " > < listado buscador = " true " ordenable = " true " size = " 100 " indice = " 2 " / > < buscador maxLength = " 22 " size = " 100 " indice = " 1 " / > < detalle maxLength = " 22 " size = " 100 " indice = " 2 " / >
78
11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44
45 46 47 48
</ campo > </ tabla > < tabla clase = " com . comex . aplicacion . dal . bean . Provincia " c a mp oP or D ef ec t o = " NOMBRE " nombre = " Provincia " id = " A P L I C A C I O N _ P R O V I N C I A " > < campo obligatorio = " true " clase = " java . lang . Long " pk = " true " nombre = " IdProvincia " id = " ID_PROVINCIA " > < detalle maxLength = " 22 " size = " 100 " indice = " 1 " / > </ campo > < campo obligatorio = " true " clase = " java . lang . String " pk = " false " nombre = " Nombre " id = " NOMBRE " > < listado buscador = " true " ordenable = " true " size = " 100 " indice = " 1 " / > < buscador maxLength = " 22 " size = " 100 " indice = " 1 " / > < detalle maxLength = " 22 " size = " 100 " indice = " 2 " / > </ campo > < campo obligatorio = " true " clase = " java . lang . String " pk = " false " nombre = " Nombre " id = " I D _ C O M U N I D A D _ A U T O N O M A " > < listado buscador = " true " ordenable = " true " size = " 100 " indice = " 2 " / > < buscador maxLength = " 22 " size = " 100 " indice = " 2 " / > < detalle maxLength = " 22 " size = " 100 " indice = " 3 " / > < fk clase = " com . comex . aplicacion . dal . bean . C o m u n i d a d A u t o n o m a " tabla = " A P L I C A C I O N _ C O M U N I D A D _ A U T O N O M A " valor = " ID_COMUNIDAD " campo = " FK_TALLER_COMUNIDAD_AUTONOMA_ID_COMUNIDAD "> < descripcion > NOMBRE </ descripcion > </ fk > </ campo > </ tabla > < tabla clase = " com . comex . aplicacion . dal . bean . Municipio " c a mp oP or D ef ec t o = " NOMBRE " nombre = " Municipio " id = " A P L I C A C I O N _ M U N I C I P I O " > < campo obligatorio = " true " clase = " java . lang . Long " pk = " true " nombre = " IdMunicipio " id = " ID_MUNICIPIO " > < detalle maxLength = " 22 " size = " 100 " indice = " 1 " / > </ campo > < campo obligatorio = " true " clase = " java . lang . String " pk = " false " nombre = " Nombre " id = " NOMBRE " > < listado buscador = " true " ordenable = " true " size = " 100 " indice = " 1 " / > < buscador maxLength = " 22 " size = " 100 " indice = " 1 " / > < detalle maxLength = " 22 " size = " 100 " indice = " 2 " / > </ campo > < campo obligatorio = " true " clase = " java . lang . String " pk = " false " nombre = " Nombre " id = " ID_PROVINCIA " > < listado buscador = " true " ordenable = " true " size = " 100 " indice = " 2 " / > < buscador maxLength = " 22 " size = " 100 " indice = " 2 " / > < detalle maxLength = " 22 " size = " 100 " indice = " 3 " / > < fk clase = " com . comex . aplicacion . dal . bean . Provincia " tabla = " A P L I C A C I O N _ P R O V I N C I A " valor = " ID_PROVINCIA " campo = " FK_TALLER_PROVINCIA_ID_PROVINCIA "> < descripcion > NOMBRE </ descripcion > </ fk > </ campo > </ tablas >
Ahora se explicar a el signicado de cada par ametro de este chero:

1
< tabla clase =" com . comex . aplicacion . dal . bean . C o m u n i d a d A u t o n o m a " c am po Po r De fe c to =" NOMBRE " nombre =" Comunidad Aut o noma " id =" APLICACION_COMUNIDAD_AUTONOMA ">
Esta l nea indica el comienzo de la descripci on de una tabla. Los par ametros que aparecen son los siguientes: clase indica que las entidades de esta tabla est an implementadas en el objeto com.comex.aplicacion.dal.bean.ComunidadAutonoma. campoPorDefecto indica que la ordenaci on b asica ser a por el campo NOMBRE.
79
nombre indica qu e literal aparecer a en la aplicaci on como t tulo de las vistas que hagan referencia a esta entidad. N otese que hay un espacio y una tilde en la letra ((o)), lo que indica que dicho campo fue modicado por el programador en el formulario de selecci on de campos de Genereitor. Este valor es la forma de referirse a la entidad que utilizar a la vista. id indica la tabla de la base de datos que contiene los registros correspondientes a esta entidad.
< campo obligatorio =" true " clase =" java . lang . Long " pk =" true " nombre =" IdComunidad " id =" ID_COMUNIDAD " >
Esta l nea indica el comienzo de la descripci on de un campo de la tabla. obligatorio indica si el campo ha de tener obligatoriamente un valor o puede aceptar valores nulos. clase indica el tipo de dato Java que representa a este campo. pk indica si es clave primaria de la tabla. nombre indica el nombre por el que ser a referido en la vista este campo, los encabezados de los listados y los literales que acompa nen a las casillas que hagan referencia a esta propiedad. id indica la propiedad de la entidad de la base de datos a la que se reere este campo.
< listado buscador =" true " ordenable =" true " size ="100" indice ="2"/ >
Esta l nea indica que el campo aparecer a en las vistas de listado de la entidad. buscador indica si, adem as de en el listado, aparecer a en el buscador, ofreciendo la posibilidad de consultar los registros por el valor de este campo. ordenable indica si se ofrece la posibilidad de ordenar el listado por los valores de este campo. size indica el tama no que tendr a la columna del buscador correspondiente a este campo. Este valor tendr a que ser modicado a posteriori por el programador, puesto que es dif cil saber el tama no exacto que corresponder aa cada columna en el momento de la generaci on. indice indica la posici on en la tabla de listados de este campo.
< buscador maxLength ="22" size ="100" indice ="1"/ >
Esta l nea indica los par ametros del buscador, en caso de que el campo deba aparecer en dicha vista.
80
maxLength indica la longitud m axima que aceptar a la casilla de b usqueda. size indica el tama no que tendr a la casilla. Este valor tendr a que ser modicado a posteriori por el programador, puesto que es dif cil saber el tama no exacto que corresponder a a la casilla dentro del formulario de b usqueda. indice indica la posici on en el formulario de b usqueda de este campo.
< detalle maxLength ="22" size ="100" indice ="2"/ >
Esta l nea indica los par ametros de la vista detalle, en caso de que el campo deba aparecer en dicha vista. maxLength indica la longitud m axima que aceptar a la casilla de edici on/detalle. size indica el tama no que tendr a la casilla. Este valor tendr a que ser modicado a posteriori por el programador, puesto que es dif cil saber el tama no exacto que corresponder a a la casilla dentro del formulario de edici on/detalle. indice indica la posici on en el formulario de edici on/detalle de este campo.
2 3
< fk clase =" com . comex . aplicacion . dal . bean . Provincia " tabla =" A P L I C A C I O N _ P R O V I N C I A " valor =" ID_PROVINCIA " campo =" FK_TALLER_PROVINCIA_ID_PROVINCIA "> < descripcion > NOMBRE </ descripcion > </ fk >
Estas tres l neas indican que un campo es clave ajena que referencia a otra tabla, y que el programado la ha seleccionado para que sea tenida en cuenta. clase indica el bean que implementa la entidad que es referenciada por la clave ajena. tabla indica la tabla de la base de datos correspondiente a la entidad referenciada. valor indica la columna que es clave primaria de la tabla referenciada. campo indica el nombre que la clave ajena tiene en el sistema de bases de datos. descripcion indica el campo que aparecer a en el listado de la tabla que estamos tratando referenciando a la relacionada. En este caso, aunque la clave primaria de PROVINCIA sea ID PROVINCIA, en el listado de MUNICIPIO aparecer a el nombre de la provincia en lugar del identicador, puesto que el nombre ofrece m as informaci on al usuario.
81
7.2.2.
Beans
Al igual que en el bloque funcional de generaci on de c odigo, se proporcionan al usuario los beans correspondientes a cada una de las entidades que han sido consideradas tablas maestras. Los beans generados aqu son similares a los que ya se explicaron en la secci on de generaci on de c odigo (ver apartado 6.2.8 en la p agina 71), aunque ofrecen una caracter stica adicional debido a la forma de tratar las relaciones. Continuando con el ejemplo de COMUNIDAD AUTONOMA, PROVINCIA y MUNICIPIO (gura 7.1 en la p agina 74), tomaremos el bean Provincia, ya que posee tanto claves ajenas que referencian a COMUNIDAD AUTONOMA como referencias desde MUNICIPIO. De esto se deduce que el objeto Provincia pertenecer a a una ComunidadAutonoma, por lo que poseer a un atributo que almacenar a la clave primaria que referencia a dicha entidad. Pero tambi en habr a una serie de objetos de tipo Municipio que har an referencia al objeto Provincia, por lo que el bean correspondiente implementar a un nuevo atributo, que representar a el listado de objetos Municipio que pertenecen a esta Provincia. As , los atributos del bean Provincia ser an:
1 2 3 4 5
public static final String TABLA = " A P L I C A C I O N _ P R O V I N C I A " ; protected Long idProvincia ; protected String nombre ; protected C o m u n i d a d A u t o n o m a c o m u n i d a d A u t o n o m a ; protected BaseBeanSet l i s t a F k A p l i c a c i o n M u n i c i p i o I d M u n i c i p i o s ;
Vemos que, aparte de los atributos propios de la entidad, aparece un atributo del tipo ComunidadAutonoma, que ya aparec a en la generaci on de c odigo, y otro atributo de tipo BaseBeanSet que almacenar a el conjunto de elementos de tipo Municipio que pertenecen a la Provincia. Por u ltimo, tambi en se implementan en el bean los m etodos get() y set() de todos los atributos, al igual que los beans devueltos con generaci on de c odigo.
82
Parte IV
Implementaci on de Genereitor
83
Genereitor se ha implementado siguiendo las pautas de la especicaci on J2EE, con una arquitectura de 1+2+1 capas, tal como indica la gura 7.3. En el cap tulo 4 en la p agina 34 se ha analizado la arquitectura de una aplicaci on J2EE, por lo que ahora se analizar a la forma en la que se ha llevado a cabo la implementaci on del proyecto.
Figura 7.3: Estructura l ogica de Genereitor
84
Cap tulo 8
Capa web
La capa de presentaci on de Genereitor se basa en p aginas web HTML generadas din amicamente con JSP, que incorporan validaciones JavaScript para los formularios de introducci on de datos y que comprueban que los datos sean correctos en el lado del cliente, de forma que se evitan conexiones innecesarias o con datos incorrectos al servidor de aplicaciones. Tambi en es una parte fundamental de la capa de presentaci on el navegador web, que cumple la funci on de interpretar, renderizar y presentar la interfaz de usuario. Usar un navegador web est andar se traduce en un ahorro de tiempo de trabajo, puesto que no es necesario implementar una interfaz completa, y garantiza el acceso a cualquier cliente, puesto que la gran mayor a de sistemas actuales incorpora al menos un navegador en su conguraci on por defecto.
8.1.
JSP
La capa de presentaci on se ha implementado mediante JSP, que posibilita el uso de Java en p aginas HTML para dotarlas de contenido din amico. Tras la ejecuci on de un JSP, al usuario (el programador en este caso) se le presenta, v a navegador, una p agina HTML que representar a la interfaz. En C.2 en la p agina 153 se ofrece una explicaci on de la tecnolog a JSP. Las diversas pantallas que se le presentan al usuario consisten en formularios que este habr a de rellenar seg un la acci on que desee realizar, enviando los datos al servidor para que, tras ser tratados, se le devuelva, bien a una etapa siguiente del proceso, bien el resultado que desea obtener. JSP es una tecnolog a que permite a los desarrolladores y dise nadores web implementar y desarrollar r apida y f acilmente p aginas web din amicas. Estas aplicaciones son multiplataforma. JSP separa el dise no de la interfaz de usuario de la generaci on de contenidos, lo que posibilita que un dise nador sin conocimientos de la tecnolog a sea capaz de modicar el aspecto de la p agina sin alterar los mecanismos de manejo y generaci on de contenidos din amicos. Presenta una serie de ventajas: 85
CAP ITULO 8. CAPA WEB
Se puede utilizar la tecnolog a JSP sin necesidad de aprender Java, utilizando la librer a est andar de etiquetas (JSTL). Sin embargo, para aprovechar toda la potencia del sistema es aconsejable poseer conocimientos de Java. Es posible extender el lenguaje JSP mediante la implementaci on de tags personalizados, que ampl en las funcionalidades de la librer a est andar. Las p aginas que se generan son f aciles de mantener, por la mencionada separaci on entre dise no y generaci on de contenidos. La tecnolog a JSP hace uso de tags al estilo de XML para encapsular la l ogica que genera el contenido de la p agina. Dicha l ogica reside en los recursos del servidor (un ejemplo es la arquitectura de componentes JavaBeans), cuyas funcionalidades ser an accedidas por la p agina mediante estos tags o etiquetas. Esta tecnolog a es una extensi on de los Java Servlets, que son m odulos que extienden las funcionalidades de un servidor web. Se descargan bajo demanda a la parte del sistema que los necesita. JSP y Java Servlets proporcionan independencia de plataforma, rendimiento ptimo, separaci o on de l ogica y presentaci on y facilidad tanto de administraci on como de uso. Dado lo complejo de algunos formularios, se ha implementado un control de errores mediante JavaScript, que permitir a al usuario corregir cualquier error en los datos introducidos antes de enviar la petici on al servidor. En caso de error, antes de lanzar la conexi on al servidor, se informa al usuario de los campos que han de ser corregidos. Tambi en se hace uso de varios tags, que facilitan la implementaci on de las p aginas JSP, permitiendo reutilizar c odigo y evitando tener que implementarlos cada vez que se utilicen. En la gura 8.1 en la p agina siguiente se presenta una pantalla de la interfaz de Genereitor se nalando varios de sus componentes y c omo se han creado. No se se nala en el esquema, pero para la apariencia general de la interfaz se han utilizado hojas de estilo CSS.
8.1.1.
Custom Tags
Los tags son llamadas a objetos predenidos de la interfaz que se incluyen dentro del cuerpo de una p agina JSP ofreciendo diferentes funciones, de manera que no es necesario implementarlas cada vez que se utilicen. Son capaces de aceptar par ametros, que ser an obligatorios o no dependiendo de la manera en que est e el tag implementado. La tecnolog a J2EE permite al programador implementar tags personalizados conforme a sus necesidades, expandiendo las posibilidades del lenguaje HTML. De esta manera es posible implementar un tag ((lista)) que incluya en la p agina generada con el JSP un listado con ciertas caracter sticas, que recibir a como par ametro el conjunto de datos a listar y otras opciones, de manera que podemos utilizar dicho tag para generar listas en toda nuestra aplicaci on implementando 86
Figura 8.1: Diversas tecnolog as utilizadas en la interfaz de Genereitor.
tanto la l ogica como la apariencia de dicha lista una s ola vez. En cada p agina que se utilice la lista, u nicamente ser a necesario incluir su llamada (tag). Un ejemplo trivial de tag podr a ser el siguiente: Listing 8.1: CabeceraTag.java: tag de ejemplo
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
import java . io .*; import javax . servlet . jsp .*; import javax . servlet . jsp . tagext .*; public class CabeceraTag extends BodyTagS upport { BodyContent bc ; public void se tBodyCo ntent ( BodyContent bc ) { this . bc = bc ; } public int doAfterBody () throws JspException { try { JspWriter out = bc . g e t E n c l o s i n g W r i t e r () ; out . println ( " < div align =\" center \" > < img src =\"/ imagenes / cabecera . jpg \" alt =\"\" > </ div > " ) ; out . println ( bc . getString () ) ; out . println ( " < div align =\" center \" > < a href =\" mailto : d i r e c c i o n @ c o rr e o . com \" > Contacto </ a > </ div > " ) ; bc . clearBody () ; } catch ( IOException e ) { system . out . println ( " Error en Tag Cabecera " + e . getMessage () ) ; } return EVAL_BODY_TAG ; } }
Este sencillo tag incluir a una imagen de cabecera al principio de la p agina y un link de contacto al nal, de forma que se podr a utilizar englobando todo el contenido de cada JSP para que todas las p aginas compartieran dicha cabecera e informaci on de contacto, sin tener que inclu rlo en cada chero. Un ejemplo de uso ser a el siguiente:
87
Listing 8.2: P agina JSP de ejemplo

1 2 3 4 5 6 7 8 9 10 11 12 13
< %@ taglib uri = " ejemplos . tld " prefix = " ejemplos " %> < html > < head > < title > T tulo de la p a gina </ title > </ head > < body > < ejemplos : cabecera > ... Contenidos ... </ ejemplos : cabecera > </ body > </ html >
Vemos que la primera l nea de este u ltimo fragmento hace referencia a un chero ejemplos.tld. Dicho chero contiene las descripciones de todos los tags disponibles en la aplicaci on, de manera que el servidor de aplicaciones conozca c omo han de ser interpretados y a qu e clases corresponden dentro de la implementaci on de la interfaz. En dichos descriptores se reejan los siguientes par ametros: Nombre del tag. Clase que implementa el tag. Atributos aceptados, obligatoriedad de estos y si son capaces de averiguar sus valores en tiempo de ejecuci on. Informaci on o aclaraciones. En caso de que contenga cuerpo, se puede indicar a modo informativo qu e ha de contener dicho cuerpo. Un descriptor de tags correspondiente al tag ((cabecera)) anteriormente descrito ser a el siguiente: Listing 8.3: Fichero ejemplos.tld describiendo el tag cabecera
1 2 3 4 5 6 7 8 9 10 11 12 13
<! -- ejemplos . tld -- > <? xml version = " 1.0 " encoding = " ISO -8859 -1 " ? > <! DOCTYPE taglib PUBLIC " -// Sun Microsystems , Inc .// DTD JSP Tag Library 1.1// EN " " http: // java . sun . com / j2ee / dtds / web - j s p t a g l i b r a r y _ 1 _ 1 . dtd " > < taglib > < tag > < name > cabecera </ name > < tagclass > CabeceraTag </ tagclass > < bodycontent > JSP </ bodycontent > < info > Incluye imagen de cabecera . </ info > </ tag > </ taglib >
8.1.1.1.
<comex:etiqueta>
Este tag permite el uso de etiquetas en la parte web, cuyo contenido se halla en un chero etiquetas.properties. El sistema de etiquetas es preferible al 88
de escribir el texto directamente en la p agina, puesto que a la hora de hacer modicaciones (e.g. traducir la aplicaci on) s olo se ha de actualizar el archivo de etiquetas, en lugar de cada una de las p aginas. Uso de EtiquetaTag:
<comex:etiqueta clave="clave"/>
clave (Obligatorio ) : es el c odigo que identica a cada etiqueta en el chero etiquetas.properties.
Es importante destacar que el uso de este tag facilita enormemente la internacionalizaci on de la aplicaci on: se pueden mantener varios cheros de etiquetas, uno por cada idioma, y permitir al usuario que seleccione el idioma de su preferencia. De este modo mantenemos la misma implementaci on de los JSP, siendo el tag el que introduzca los literales correspondientes al idioma escogido. 8.1.1.2. <comex:listadoble>
Este tag implementa una lista doble para seleccionar varios campos de una lista extensa de elementos. Se presentan dos listas, a la izquierda una con todos los campos disponibles, y a la derecha otra con los campos seleccionados. As mismo se proporcionan dos botones para intercambiar los elementos de una lista a otra. Al a nadir un campo a una lista, se elimina autom aticamente de la otra. Uso de ListaDobleTag:
<comex:listadoble id="id" lista="lista" orden=orden/>
id (Obligatorio ): el ID que tendr a la lista doble dentro del JSP. lista (Obligatorio ): el BaseBeanSet que contiene los elementos a listar. orden (Opcional ): el orden inicial de los elementos en la lista. Los tres campos soportan expresiones en request-time.
Para el uso de este tag se han de indicar dos etiquetas en el etiquetas.properties correspondientes a los encabezados de cada tabla cuyas claves ser an: usuario.perles.porseleccionar, que corresponde a la tabla de elementos disponibles.
89
usuario.perles.seleccionados, que corresponde a la tabla de elementos seleccionados. As mismo requiere dos im agenes, una para cada bot on, que han de estar situadas en las rutas: a el bot on para pasar elementos de ((contexto))/img/arrow rigth.gif, que ser la lista de elementos disponibles a la de elementos seleccionados. ((contexto))/img/erase.gif, que ser a el bot on para eliminar elementos de la lista de seleccionados. 8.1.1.3. <genereitor:tooltip>
Permite a nadir etiquetas informativas sobre campos de texto, especialmente u til cuando no existe mucho espacio disponible en la p agina (e.g. tablas de gran envergadura) y se han de usar abreviaturas o no es posible mostrar directamente toda la informaci on necesaria. Uso de TooltipTag:
<genereitor:tooltip texto="texto" tooltip="tooltip" long="longitud"/>
texto (obligatorio): es el texto que se mostrar a por defecto en la p agina. tooltip (opcional): es el contenido de la etiqueta que se muestra al pasar el puntero sobre el texto. Si no se especica, se muestra el contenido de texto. long (opcional): es la cantidad de caracteres de texto que se mostrar an en la p agina. Si el contenido de texto es de longitud inferior a este campo y no se ha especicado tooltip, no se mostrar a etiqueta al pasar el puntero sobre el texto. Si la sobrepasa, cortar a el texto a los long primeros caracteres, seguidos de ((...)), y se mostrar a el contenido entero de texto en la etiqueta. Los tres campos soportan expresiones en request-time.
Se puede personalizar la apariencia de la etiqueta deniendo los style s siguientes: .tooltiptag .tooltiptagHover .tooltiptag span .tooltiptagHover span
90
8.1.1.4.
<genereitor:contenedor>
Proporciona el contenedor base para la interfaz gr aca, que ser a la misma en todos los apartados: Fondo. Barra de t tulo. Barra de men u superior. Barra inferior. As mismo inicia y termina un formulario, dado que cada p agina del generador va a constar de un u nico formulario, de id formulario y m etodo post, cuyos campos ir an inclu dos entre las etiquetas del tag en cada p agina. Tambi en proporciona una caja de contenido para mostrar errores de conexi on, validaci on de datos, informaci on adicional o advertencias. Para mostrar u ocultar esta ventana existen dos funciones Javascript: showbox("tipo",mensaje);, que al ejecutarse har a visible la caja de informaci on, mostrando un icono seg un el primer par ametro (cuyos valores pueden ser ((info)) y ((error))) y el mensaje. Si el primer par ametro no coincide con los valores se nalados, no se muestra ning un icono. Tras esto, va al inicio de la p agina. hidebox(); Oculta la caja de informaci on. En la barra de men u superior se ubican los enlaces a las cuatro partes del generador: generaci on de esqueleto, de script de tablas maestras, de c odigo y ajustes. Para cada uno de estos cuatro enlaces, se requieren las siguientes etiquetas en el etiquetas.properties: boton.esqueleto boton.script boton.codigo Tambi en necesita las siguientes im agenes: ((contexto))/imagenes/img pie.jpg: imagen del pie de p agina. ((contexto))/imagenes/icono ok.gif: icono de conrmaci on para la infobox. ((contexto))/imagenes/icono error.gif: icono de error para la infobox. ((contexto))/imagenes/g.ico: icono que aparecer a en la barra de direcciones (favicon 1 ), con el logotipo de Genereitor.
1 Favicon es como se conoce al icono que aparece en la barra de direcciones de la mayor a de navegadores, junto a la URL de la p agina visitada, y en la lista de favoritos en caso de a nadir tal direcci on.
91
Y los siguientes estilos: #contenedor general, que dene el estilo general del cuerpo de la p agina (fnd body.gif). #cabecera, que dene la cabecera de la p agina (img cabecera.jpg). #contenedor, que dene el estilo del contenedor de la p agina. #navegador top, que dene el estilo de la barra de men u superior (fnd navtop.gif). .opcion navtop, estilo de cada opci on del men u superior. .navtop, aspecto de los botones del men u superior. .navtop:hover, aspecto de los botones del men u superior al pasar el puntero sobre ellos. #pie, que dene el estilo del pie de p agina (fnd pie.gif). Uso de ContenedorTag:
<genereitor:contenedor accion="accion"> . . . </genereitor:contenedor>
accion (Opcional) : dene la acci on del formulario.
8.1.1.5.
<genereitor:boton>
Tag que permite la inclusi on de botones en la web. Uso de BotonTag:

<genereitor:boton valor="valor" ancho=ancho/>
valor (Obligatorio ): dene el texto que llevar a el bot on. id (Opcional ): dene el id del bot on dentro de la p agina. javascript (Opcional ): dene una funci on Javascript asociada al bot on. onclick (Opcional ): dene un evento al hacer click sobre el bot on. href (Opcional ): dene un enlace para el bot on. orden (Opcional ): dene el orden del bot on en la p agina.
92
ancho (Opcional ): dene el ancho del bot on (1, 2 o 3). css (Opcional ): permite establecer un estilo para el bot on. enabled (Opcional ): permite activar o desactivar el bot on. title (Opcional ): dene el t tulo del bot on. Todos los campos soportan expresiones en request-time excepto id.
8.1.2.
JavaScript
Parte de la interfaz gr aca de Genereitor consta de varios formularios generados de forma din amica conforme a los metadatos de las tablas de la base de datos contra la que se est a trabajando. Seg un las caracter sticas de dichas tablas, es com un que se presenten al usuario formularios con gran cantidad de campos para rellenar o vericar. Dada esta complejidad, no es raro que el usuario cometa fallos a la hora de rellenar los formularios, olvide introducir opciones o las rellene de forma incorrecta. Por esto, se implementa un control de errores que verica que se den las siguientes condiciones: En la etapa de conexi on: Los campos host, SID y usuario no se encuentren vac os. El campo puerto no se encuentre vac o y sea un campo num erico v alido. El campo contrase na, en caso de estar vac o, se advertir a al usuario mediante un mensaje junto al bot on de conectar de tal situaci on, y el campo contrase na parpadear a brevemente. Si se vuelve a pulsar el bot on conectar, se enviar a la conexi on al servidor con la contrase na vac a, puesto que es posible que exista acceso sin contrase na. En los formularios de selecci on de campos de tabla, que haya por lo menos un campo se nalado como campo de ordenaci on por defecto para cada tabla. En el formulario de selecci on de campos de tabla del bloque funcional de generaci on de script de tablas maestras, se comprobar a que haya por lo menos un campo para buscador, un campo para detalle y un campo para listado en cada tabla. Que ning un campo de nombre de bean, alias de campo, nombre de aplicaci on, paquete base o longitud m axima de campo est e vac o. Que todos los campos de longitud m axima sean de tipo num erico.
93
En caso de incumplirse alguna de las anteriores condiciones, se retorna al comienzo de la p agina (en caso de que la misma supere la altura de la ventana del navegador), y se muestra una cabecera informando de cada error sucedido, de forma que sean f acilmente localizables para el usuario. Los datos introducidos hasta el momento se mantienen, ofreciendo al programador la posibilidad de corregir los errores y volver a conrmar el formulario. Una vez se hayan superado las validaciones JavaScript se proceder a a lanzar la conexi on al servidor de aplicaciones, que recoger a toda la informaci on introducida en el formulario. El motivo del uso de JavaScript para realizar dichas validaciones es precisamente la complejidad de los formularios. Si se tuviera que comprobar la validez de los datos introducidos en el servidor de aplicaciones, se perder a mucho tiempo recargando la interfaz en cada vericaci on, puesto que se tendr an que enviar al servidor los datos, comprobarlos y devolverlos a la interfaz en caso de error. Usando JavaScript se descarga la red y el servidor, asegurando que los datos que env a el usuario son v alidos.
8.1.3.
CSS
Cascading Style Sheets (hojas de estilo en cascada) es un lenguaje utilizado para denir la presentaci on de un documento escrito en HTML o XML. Esto establece una separaci on completa entre contenido y presentaci on. Con CSS se denen colores, tipograf as, capas, m argenes y otros aspectos de la presentaci on del documento. Esta separaci on proporciona una ventaja en cuanto a la accesibilidad de los contenidos. Por ejemplo, en un sitio web podr amos denir tres hojas de estilo diferentes: Una con los colores corporativos de la empresa, que resultase atractivo visualmente. Una con fondos blancos y textos en negro, y ocultando elementos tales como men us o elementos al m argen, para lograr copias impresas de calidad. Una con tipograf as grandes y colores de alto contraste, para facilitar el acceso a los contenidos a personas con dicultades o problemas visuales. As , las ventajas que ofrece son: Centraliza el control de la presentaci on de un sitio web completo con un s olo chero de estilos, lo que mantiene la concordancia entre la apariencia de los diferentes apartados del mismo. Es posible que el usuario especique su propia hoja de estilo para un sitio web, de forma que pueda adecuarla a sus preferencias o necesidades de accesibilidad. Se pueden denir varias hojas de estilo diferentes, seg un el dispositivo mostrado (ordenador, pda, p agina para imprimir). 94
El c odigo HTML es m as claro de entender y se reduce su tama no, al externalizar las deniciones de estilo. Por u ltimo, conviene destacar que CSS es un est andar de W3C. Tanto Genereitor como las interfaces que genera utilizan hojas de estilo correspondientes a la versi on 2.12 de CSS.
8.2.
Servlets
Bajo JSP y las diferentes tecnolog as que lo complementan, explicadas en el apartado anterior, se encuentran los servlets, y que dentro del patr on estructural de modelo-vista-controlador realizan la funci on de controlador. Los servlets hacen de intermediarios entre la vista y el modelo, al ser m as vers atiles que JSP para esta funci on al estar escritos como clases Java normales, evitando de esta forma mezclar c odigo visual (HTML, XML) con c odigo Java, delegando a JSP u nicamente la funci on de componer la interfaz visual. Cada v nculo en la interfaz web se corresponde con una acci on de un servlet. Los servlets tienen una funci on perform(), que es la encargada de recibir la petici on del usuario que llega de la interfaz, y dirigir la ejecuci on hacia la funci on correspondiente, tal como muestra la gura 8.2.
Figura 8.2: Reconocimiento de las peticiones del usuario por el controlador.
El controlador de Genereitor se compone de seis servlets, que realizan funciones espec cas:
2 La
especicaci on de CSS 2.1 puede ser consultada en http://www.w3.org/TR/CSS21/.
95
8.2.1.
InicioAction.java
Este primer servlet es el m as sencillo de todos, y es el encargado de cargar la p agina de bienvenida a Genereitor, que dar a acceso a las secciones correspondientes a los tres bloques funcionales, los cuales cuentan con un servlet dedicado para cada uno. Unicamente cuenta con dos funciones: perform, que ser a la encargada de consultar la petici on del usuario que le llega desde la vista y dirigirla hacia la funci on correspondiente, e inicio, que llama a la vista para que muestre la interfaz correspondiente, en este caso la resultante de compilar el chero index2.jsp3 .
8.2.2.
GenereitorBaseAction.java
Es el servlet ((padre)) de TablasAction, EsqueletoAction y CodigoAction, de manera que los tres hereden los m etodos que implementa. Este servlet contiene funciones comunes a varios bloques funcionales: Paginador. Para cada vista generada, se requiere un paginador, que es el encargado de dar forma a las listas que se mostrar an. Operaci on de conexi on. Esta operaci on es com un a los tres bloques funcionales4 , por lo que se implementa en este servlet para no repetir dicha funci on en los servlets correspondientes a cada bloque. Recolecci on de datos de conexi on: Se encarga de recoger los datos de la conexi on de los formularios. Dado que dichos datos son comunes a las tres, la funci on encargada de dicha tarea se implementa. Compresi on: Tambi en aqu se implementa la funci on que crea en el servidor el chero comprimido que se devolver a al usuario al nal de cada ejecuci on de todos los bloques funcionales. Llamadas a la l ogica de la aplicaci on: Son las funciones que recolectan los datos devueltos por la l ogica de la aplicaci on: Lista de tablas de la base de datos. Lista de columnas de una tabla. Lista de claves ajenas de una tabla. Lista de claves primarias de una tabla que son ajenas de cualquier otra.
3 Al iniciar una conexi on contra un servidor web, siempre se busca el chero index.htm, index.php o similar. En este caso existe un index.jsp, que u nicamente contiene una redirecci on hacia la acci on inicio.inicio.do, que se encargar a de llamar al controlador para que genere la vista inicial, contenida en el chero index2.jsp. 4 Si bien s olo es necesaria una conexi on con la base de datos en los bloques de generaci on de c odigo y script de tablas maestras, recordemos que se incluy o la posibilidad de comprobar la conexi on en la etapa de generaci on de esqueleto, a n de vericar que los datos introducidos son correctos.
96
Recolecci on de datos de formularios: Funciones que recolectan los datos introducidos en los formularios de la aplicaci on y componen los nodos XML de datos que luego ser an combinados con las plantillas XSL para generar los cheros que se devolver an posteriormente al usuario. Creaci on y borrado de temporales: Tanto los cheros generados como los cheros que se contienen se almacenan durante la sesi on en el servidor. Estas funciones se encargan tanto de crearlos como de borrarlos cuando ya no son necesarios.
8.2.3.
EsqueletoAction.java
Dado que el bloque funcional de generaci on de esqueleto s olo se compone de una etapa, el servlet correspondiente dispone u nicamente de dos funciones de acceso p ublico. La primera se encargar a de formar la vista que presentar a al usuario el formulario de introducci on de los datos requeridos. La segunda encarga de recolectar los datos espec cos del formulario de la interfaz, combinar dichos datos, una vez formateados con XML con las plantillas XSL, copiar los cheros de uso com un (im agenes, hojas de estilo, p aginas de error gen ericas), empaquetarlos y devolverlos al usuario. Para esto, el servlet llama a su clase superior, GenereitorBaseAction, aprovechando las funciones que implementa. Tambi en subdivide el proceso en funciones recursivas para optimizar el c odigo. Por u ltimo, implementa una funci on conectar, que es simplemente una llamada a la funci on hom onima de GenereitorBaseAction.
8.2.4.
CodigoAction.java
Este servlet implementa acciones para cada etapa de la que consta el bloque funcional de generaci on de c odigo. 8.2.4.1. Inicio
Al igual que el anterior, la primera etapa cuenta con una funci on de inicio, encargada de dibujar la interfaz de introducci on de los datos de conexi on. 8.2.4.2. Conexi on a la base de datos
Esta funci on es una mera llamada a la funci on hom onima de la clase superior, GenereitorBaseAction, que lanza la conexi on a la l ogica de la aplicaci on.
97
8.2.4.3.
Selecci on de tabla
Tras efectuar la conexi on, la segunda opci on consulta a la fachada de la l ogica de negocio para obtener un listado de todas las tablas existentes en la base de datos, que se pasar an a la vista como par ametro de un tag lista, y se evaluar a si dicha tabla posee alguna clave ajena. Si se da el caso de que existen tablas cuya clave primaria sea una clave ajena de la tabla seleccionada, se presentar a al usuario una lista de las tablas relacionadas. Si no, este paso se omite. 8.2.4.4. Selecci on de tablas relacionadas
Si es necesario, se crea una vista que muestra al usuario una lista doble, para que seleccione las tablas relacionadas que se quiere tener en cuenta. Como ya se ha dicho, en caso de que la tabla principal no posea relaciones, este paso se omite. Tanto la tabla principal como las relacionadas si las hubiera, se almacenan como par ametros de sesi on, para su recuperaci on posterior a la hora de generar el paquete. 8.2.4.5. Selecci on de campos
Tras la selecci on de tablas, se consulta a la l ogica de la aplicaci on los campos de cada tabla que ha sido seleccionada, mostr andose una vista que permite al usuario establecer los campos que desea que aparezcan en los listados de la aplicaci on que se va a generar, as como las restricciones de obligatoriedad y longitud m axima que aceptar a. Tambi en se permite modicar el nombre que cada propiedad de las entidades de la tabla recibir a al ser implementados como objetos Java. Dicho listado ser a generado din amicamente con JSP. Tras conrmar que los datos introducidos son correctos, se almacenar an como par ametros de sesi on y se presentar a al usuario la vista correspondiente a la u ltima etapa del proceso. 8.2.4.6. Selecci on de par ametros y generaci on de paquete
En esta fase se presenta nuevamente un formulario al usuario. Al pulsar el bot on ((Generar)) se llama a la funci on hom onima de este servlet, que se encargar a de recolectar los par ametros de este u ltimo formulario, as como los atributos almacenados en la sesi on, para luego llamar a la funci on de GenereitorBaseAction que convertir a dichos par ametros en nodos de datos XML. Tras esto, crear a la estructura de directorios necesaria para organizar los cheros que formar an parte del paquete que se devolver a al usuario y se combinar an, seg un los par ametros introducidos, las plantillas XSL necesarias para generar dicho paquete. Tras esto, se llama a la funci on ((comprimir)) de la clase superior, y se devuelve el paquete al usuario. 98
Esta u ltima etapa est a descompuesta en varias funciones para hacerla m as modular, de forma que el mantenimiento de la aplicaci on sea m as sencillo.
8.2.5.
TablasAction.java
El servlet correspondiente al bloque funcional de tablas maestras tiene cinco funciones principales: 8.2.5.1. Inicio
Al igual que el anterior, la primera etapa cuenta con una funci on de inicio, encargada de dibujar la interfaz de introducci on de los datos de conexi on. 8.2.5.2. Conexi on a la base de datos
Esta funci on llama a la funci on hom onima de la clase superior, GenereitorBaseAction, que lanza la conexi on a la l ogica de la aplicaci on. Tras esto, presenta al usuario la vista de selecci on de tablas. 8.2.5.3. Selecci on de tablas
Tras recuperar las tablas que ha seleccionado el usuario, se a naden a la lista autom aticamente todas las tablas referenciadas por las claves ajenas de las seleccionadas, y se elabora la vista de selecci on de campos y las propiedades de estos, que se presentar a al usuario. 8.2.5.4. Selecci on de campos y generaci on de paquete
Tras recopilar la informaci on del formulario que acaba de rellenar el usuario, se procede a elaborar los nodos XML que reunen toda la informaci on necesaria, y se combinan con las plantillas XSL oportunas para generar el paquete que contendr a el script de tablas maestras y los beans correspondientes a las entidades para las que se ha generado dicho script.
8.2.6.
ServletEscuchador.java
Este u ltimo servlet es el encargado de borrar los cheros temporales que ya no se usan. Al generar un paquete, se borra inmediatamente la estructura de directorios que se hab a generado en el servidor de aplicaciones para confeccionarlo, pero dicho paquete comprimido todav a no se ha borrado, puesto que la aplicaci on no es capaz de saber si el usuario ha aceptado o no la descarga. Si se eliminase el paquete comprimido antes de que se hubiera completado la descarga, no se acabar a de transferir completamente.
99
Por esto, es este servlet el encargado de hacer esta ((limpieza)), vigilando el tiempo de vida de las sesiones iniciadas en la aplicaci on, y al momento de la muerte de cada sesi on, elimina los paquetes comprimidos correspondientes del servidor de aplicaciones. De este modo no quedan residuos que, de otro modo, acabar an por llenar la capacidad de almacenamiento del servidor que soporta Genereitor.
8.3.
Otros
Aparte de los cheros mencionados hasta ahora, tambi en forman parte de la capa web diversos componentes que ofrecen varias utilidades: UtilesWEB.java: Este chero implementa una serie de utilidades est andar que se usar an en los servlets, tales como validaci on de campos num ericos, formateo de fechas, funciones conversoras de HTML a texto plano, comprobaci on de fechas, etc. ConstantesWEB.java: Aqu se recopilan diversos valores constantes que se utilizan en la aplicaci on, como por ejemplo nombres de atributos de sesi on. S olo se hallan aqu las constantes de prop osito general, las espec cas de cada bloque funcional se declaran en el servlet correspondiente.
100
Cap tulo 9
Capa de l ogica de negocio

La l ogica de negocio se implementa en Genereitor mediante POJOs (Plain Old Java Objects ), que son clases normales de Java. Hemos visto al analizar el funcionamiento de la arquitectura J2EE que esta proporciona la tecnolog a EJB para implementar la capa de l ogica de negocio. No obstante, para esta capa Genereitor no requiere de la potencia ni caracter sticas de dicha tecnolog a, por lo que utilizando clases Java lograremos un dise no m as sencillo, a la vez que ahorraremos en recursos ya que no se requerir a de un contenedor de EJBs para ejecutarlo. As , el u nico componente que formar a la capa de l ogica de negocio ser a Conexion. Esto es debido a que realmente Genereitor no maneja datos, para la generaci on de una aplicaci on web es indiferente que la base de datos contra la que se trabaja contenga o no datos. Por contra, esta sencillez del dise no se ve truncada al enfrentarnos a la necesidad de conectar a varios sistemas de bases de datos, por lo que tenemos que es necesario realizar una implementaci on de la l ogica de negocio para cada conexi on. No obstante, todas las implementaciones compartir an fachada, de forma que esta diferencia sea transparente en cuanto a los componentes de las capas superiores. As , la l ogica de negocio, compuesta por el objeto Conexi on, tiene las siguientes funciones: conectar() lanza una conexi on a la base de datos a partir de un ltro de tipo conexion. Su u nica funci on es comprobar que la conexi on es correcta y que el servidor de bases de datos responde. getTablas() recupera las tablas de la base de datos, a partir de un objeto conexion. getColumnas() recupera las columnas de una tabla, a partir de un objeto conexion y un ltro tabla.
101
CAP ITULO 9. CAPA DE LOGICA DE NEGOCIO
getClavesExportadas() devuelve informaci on sobre las tablas que tienen por clave primaria un campo que es clave ajena de la tabla sobre la que se trabaja. getClavesImportadas() devuelve informaci on sobre las tablas que tienen por clave ajena la clave primaria de la tabla sobre la que se trabaja. Es importante se nalar que normalmente las aplicaciones que trabajan sobre una base de datos almacenan los datos de conexi on en un chero de datasources, que almacena todos los datos de conexi on. Por la naturaleza de Genereitor, esto ser a imposible, ya que es necesario que sea capaz de conectarse a cualquier base de datos, cuyos par ametros de conexi on ser an introducidos por el usuario. As , el tipo de objeto Conexion se utiliza para almacenar estos datos.
9.1.
Excepciones
La clase GenereitorException re une los c odigos de excepci on que Genereitor manejar a en caso de producirse cualquier error. A n de proporcionar la informaci on precisa de la causa de cada error, se denen una serie de c odigos de excepci on, que equivalen a diversos mensajes que se reejar an en el sistema de gesti on de logs :
1 2 3 4 5 6 7 8
public public public public public public public public
static static static static static static static static
final final final final final final final final
int int int int int int int int
ERROR_GENERAL = 0; C O N E X I O N _ R E C H A Z A D A =4; D A T O S _ N O _ V A L I D O S = 5; USER_NO_ VALIDO = 50; PASS_NO_ VALIDO = 51; T A B L A _ N O _ E N C O N T R A D A = 6; SID_NO_VALIDO = 7; C LA SS _N O T_ FO UN D = 999;
Hay excepciones que pueden resultar redundantes (e.g. datos no v alidos, user no v alido, pass no v alido). Esto es debido a que algunos sistemas de bases de datos hacen distinciones al lanzar una excepci on, haci endolo de manera m as espec ca, mientras que otros informan de los errores de forma m as general. Los c odigos de error que lanzan cada base de datos se consultan en los componentes de la l ogica de negocio de cada sistema, lanzando una GenereitorException acorde al c odigo de la SQLException generada por el sistema de bases de datos.
102
Cap tulo 10
Capa de acceso a datos

10.1. Componentes de acceso a datos
Estas clases son las encargadas de comunicarse con el sistema de bases de datos. Nuevamente se plantea el problema de la necesidad de conexi on a diferentes sistemas de bases de datos, por lo que se han de realizar implementaciones diferentes para cada uno. No obstante, todas las implementaciones ofrecen las mismas funciones: conectar() se utiliza simplemente para comprobar la conexi on con el sistema de bases de datos. getTablas() devuelve las tablas de la base de datos. getColumnas() devuelve las columnas de una tabla de la base de datos. getPrimaryKeys() devuelve los campos que son clave primaria de una tabla de una base de datos. Para recuperar los metadatos de las bases de datos se hace uso de la clase java.sql.DatabaseMetaData.
10.2.
Sistema de base de datos
Dado que Genereitor se puede conectar a cualquier base de datos mientras est e soportado el sistema de bases de datos no se puede realizar un an alisis del funcionamiento de dicha base de datos.
103
CAP ITULO 10. CAPA DE ACCESO A DATOS
10.3.
Beans
Los beans son un modelo de componentes de Sun que permite encapsular varios objetos en uno u nico1 . De este modo se consigue un desarrollo m as intuitivo, al usar objetos ((completos)) en lugar de conjuntos de objetos m as simples. Realmente no pertenecen a una capa espec ca, ya que est an disponibles a todos los niveles de la aplicaci on. En Genereitor existen cuatro tipos de Bean: BD: representa un objeto ((base de datos)). Tabla: representa un objeto ((tabla)). Columna: representa un objeto ((columna)). Conexion: representa un objeto ((conexi on)). Para explicar el funcionamiento de un bean, se presenta el ejemplo m as sencillo de los utilizados. El bean conexion representa un objeto ((conexi on)) cuyos atributos corresponden a los que se introducen en las etapas de conexi on a base de datos de Genereitor.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
public class Conexion extends BaseBean implements Serializable { private String host ; private String password ; private Integer port ; private String sid ; private String tipo ; private String user ; public Conexion () { host = null ; port = null ; sid = null ; user = null ; password = null ; tipo = null ; } public String getHost () { return host ; } public String getPassword () { return password ; } public int getPort () { if ( port != null ) { return port . intValue () ; } else { return 0; } } public String getSid () { return sid ; } public String getTipo () { return tipo ; }
1 La especicaci on de JavaBeans se puede consultar en http://java.sun.com/javase/ technologies/desktop/javabeans/index.jsp.
104
CAP ITULO 10. CAPA DE ACCESO A DATOS
36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57
public String getUser () { return user ; } public void setHost ( String host ) { this . host = host ; } public void setPassword ( String password ) { this . password = password ; } public void setPort ( int port ) { this . port = new Integer ( port ) ; } public void setSid ( String sid ) { this . sid = sid ; } public void setTipo ( String tipo ) { this . tipo = tipo ; } public void setUser ( String user ) { this . user = user ; } }
Como se aprecia, existe un constructor vac o del objeto, que crear a el objeto pero sin valores. Luego, mediante las propiedades get y set se establecen los diferentes atributos. Para el ejemplo se ha simplicado el bean, pero realmente por cada propiedad existen cuatro m etodos: getPropiedad getPropiedadObject setPropiedad setPropiedadObject Las propiedades Object son necesarias para cuando para un tipo de datos existe tipo primario y tipo objeto, por ejemplo int e Integer. En este caso, la funci on Object podr a adoptar o devolver valores nulos, mientras que la funci on primaria devolver a 0 en su lugar2 . Nuevamente, al ser el tratamiento de los tipos de datos diferentes3 para cada base de datos, los beans Tabla y Columna se han de implementar una vez por cada sistema de bases de datos soportado. No obstante, se mantiene una especicaci on com un a todos, a modo de fachada, de manera que para el resto de componentes de la aplicaci on el acceso sea transparente.
comportamiento se implementar a seg un convenga. ejemplo de esto es el uso de oracle.jdbc.driver.OracleTypes para bases de datos Oracle, mientras que para el resto se utiliza java.sql.Types.
3 Un
2 El
105
Parte V
Conclusi on
106
Cap tulo 11
Visi on global del trabajo realizado

Con Genereitor se ha conseguido elaborar una herramienta de generaci on de c odigo funcional y personalizada a los requerimientos de cada proyecto, ofreciendo al programador la posibilidad de comenzar el desarrollo del mismo a partir de una aplicaci on que ya funciona, y que dispone de m etodos est andar a todos los niveles. Esta tarea, que sin la ayuda de Genereitor cuesta varios d as, es resuelta ahora en cuesti on de 5 minutos, ofreciendo adem as una implementaci on de calidad, respetando est andares y convenciones del lenguaje. Para la implementaci on de Genereitor se han utilizado tecnolog as tales como J2EE, puesto que proveen de una estructura modular que facilita el desarrollo y el mantenimiento de la aplicaci on, as como la adici on de nuevos m odulos y componentes. La elecci on del desarrollo de la aplicaci on en Java/J2EE ha sido tomada por diferentes motivos: Es una tecnolog a muy utilizada para el desarrollo de aplicaciones web, por lo que existe un gran soporte y mucha documentaci on disponible. Tiene mucho tiempo de experiencia en el sector, por lo que est a muy desarrollada, lo que conlleva el desarrollo de aplicaciones maduras y estables. Su aprendizaje no es excesivamente dif cil, por lo que se preere a otras tecnolog as m as complicadas. Sirve como experiencia para el desarrollo de las plantillas de las aplicaciones que se generar an con Genereitor, que obligatoriamente han de estar desarrolladas en esta tecnolog a. Se ha optado por utilizar en la medida de lo posible software libre y gratu to, por lo que el uso de J2EE se preere a tecnolog as propietarias o con
107
GLOBAL DEL TRABAJO REALIZADO CAP ITULO 11. VISION
licencias comerciales, tales como .Net. Por el mismo motivo, el servidor de aplicaciones sobre el que se desplegar a Genereitor es Apache Tomcat1 La entrada en producci on de Genereitor se ha llevado a cabo de forma progresiva, poniendo a disposici on de los programadores primero el m odulo de generaci on de script de tablas maestras en febrero, y los m odulos de generaci on de esqueleto y generaci on de c odigo en abril. El proyecto actualmente tiene aproximadamente 1500 horas de desarrollo. En este tiempo van inclu dos los periodos de formaci on en las tecnolog as utilizadas, y la elaboraci on del documento de an alisis y dise no previo a la implementaci on de la aplicaci on (disponible en el ap endice A en la p agina 116).
11.1.
Cambios en Genereitor durante su desarrollo
Aunque se elabor o un documento de an alisis y dise no donde se redactaron al detalle las caracter sticas que tendr a Genereitor, durante la etapa de implementaci on y pruebas se llevaron a cabo diversos cambios, bien debidos a modicaciones en los requisitos generales de las aplicaciones, bien debido a errores o mejoras descubiertos durante las pruebas2 . Algunas de estas modicaciones fueron: Relaciones entre tablas maestras En un principio s olamente se iba a tener en cuenta un nivel de relaciones entre las tablas para la generaci on del script de tablas maestras, es decir, no se tendr an en cuenta las tablas relacionadas de las relacionadas. Adem as, se iba a presentar al usuario una lista para la selecci on de las que considerase oportunas. Pero una vez implementada la l ogica que extra a las relaciones de la base de datos, se lleg o a la decisi on de que era interesante tener en cuenta las relaciones entre las tablas a todos los niveles, puesto que es com un que las tablas maestras tengan varios niveles de relaciones. Un par de ejemplos que ilustran dicha situaci on: Pa s, Comunidad aut onoma, Provincia, Comarca, Municipio... E on, era, per odo, epoca, edad... Una era contiene varios per odos, que a su vez contienen varias epocas, etc. Adem as, se decidi o eliminar la posibilidad de elecci on del usuario, agregando autom aticamente todas las tablas relacionadas, porque com unmente se seleccionaban todas las tablas del arbol de relaciones, as que seleccion andolas todas
1 Con licencia Apache v2.0, cuyos t erminos se pueden consultar en http://www.apache. org/licenses/GPL-compatibility.html. 2 Cuando el desarrollo de Genereitor estaba avanzado, se abri o el acceso a los programadores del departamento de J2EE de la empresa, cuyo feedback aport o nuevas ideas y propuestas de soluciones a los problemas.
108
autom aticamente eliminamos la posibilidad de que el usuario por error olvide seleccionar una tabla. Beans en tablas maestras Los beans son generados en la etapa de generaci on de c odigo. No obstante, dicho bloque funcional s olo tiene en cuenta autom aticamente las relaciones en un sentido, mientras que tablas maestras trabaja con relaciones en ambos sentidos (importadas y exportadas). Es por ello que se decidi o proporcionar tambi en los beans de las tablas maestras en esta bloque funcional, de forma que se doten autom aticamente de los atributos correspondientes a las relaciones de ambos sentidos. En el ejemplo anterior, de las entidades e on, era, per odo, epoca y edad, un per odo pertenece a una era, por lo que el bean correspondiente poseer a un atributo era. Este atributo tambi en es a nadido por generaci on de c odigo. Pero al mismo tiempo, un per odo tiene una serie de epocas, por lo que se le a nadir a un atributo listaEpocas. PL/SQL En principio no se contempl o la posibilidad de generar c odigo PL/SQL, pero tras comprobar que la mayor a de los proyectos usaban esta tecnolog a, se decidi o dar soporte en la capa de acceso a datos, y proporcionar las funciones PL/SQL que implementar an la capa de acceso a datos en el propio servidor de bases de datos, liberando la carga de trabajo tanto al servidor de aplicaciones como a la red. M odulos web La opci on en generaci on de esqueleto y generaci on de c odigo que permite introducir varios m odulos web al principio no exist a. Se generaba autom aticamente el m odulo aplicaci on-web y si el programador seleccionaba una casilla de ((generar m odulo de administraci on)), se generaba tambi en el m odulo aplicaci on-webadmin. Pero al nal se decidi o dar opci on de personalizar el nombre y el n umero de los m odulos web. Listado de entidades relacionadas en la vista de edici on de la principal En principio se generar an vistas de edici on y detalle de manera independiente para todas las tablas, tanto la principal como las relacionadas. Luego se decidi o a nadir la opci on de incluir el listado de las tablas relacionadas en la pantalla de edici on de la entidad principal, puesto que esta vista era usada con frecuencia en las aplicaciones desarrolladas.
109
Streaming Debido a un bug en OC4J que provoca que al recibir archivos binarios de cierta envergadura desde un formulario el servidor de aplicaciones colapse por desbordamiento de memoria, se decidi o implementar las operaciones con binarios por trozos, tanto para la subida al servidor de bases de datos como para la descarga. De esta manera se evita el error en caso de usar OC4J, se mejora el rendimiento de la aplicaci on y permite que, en caso de utilizarse reproductores de medios (audio, v deo), el tiempo de carga del buer sea menor, al tener que descargar s olamente una parte del archivo y comenzar a reproducirla mientras se descargan las dem as, en lugar de traer el chero completo y entonces comenzar la reproducci on.
11.2.
Conocimientos adquiridos
Con la elaboraci on de Genereitor se han adquirido gran cantidad de conocimientos, tanto relativos a tecnolog as como a metodolog as de trabajo. Algunas de estas son: Java: se ha adquirido gran experiencia en este lenguaje, del que al principio no se ten a apenas conocimientos. J2EE: se ha familiarizado con esta tecnolog a para el desarrollo de aplicaciones web, as como de las APIs que implementa, tales como conectores a bases de datos (jdbc), JavaServlets, JSP, gesti on transaccional, etc. Tambi en se han adquirido conocimientos de aplicaciones desarrolladas en capas, la divisi on de tareas y modularidad de las aplicaciones. Patrones de dise no de aplicaciones: tales como el Modelo-Vista-Controlador, Facade, Filtro, Singleton o ServiceLocator. Tecnolog as usadas en la web: se ha trabajado con HTML, JavaScript, CSS o AJAX, tecnolog as ampliamente usadas en los sistemas web actuales. Bases de datos: tambi en se ha trabajado con diversos sistemas de bases de datos, ampliando los conocimientos que ya se pose an sobre SQL, y adquiriendo experiencia en administraci on de bases de datos. Tambi en se ha familiarizado con el uso de PL/SQL para bases de datos Oracle. XML y XSLT: como lenguajes de tratamiento de datos y conversi on de plantillas para creaci on de m ultiples documentos.
11.3.
Herramientas utilizadas
Durante el desarrollo de Genereitor se ha hecho uso de diferentes herramientas: Entornos integrados de desarrollo: NetBeans 6.0, Oracle Jdeveloper 10.1.3. 110
Administraci on de bases de datos: Oracle SQLdeveloper 1.5, TOra. Herramientas de construcci on y despliegue: Apache Ant. Sistemas de control de versiones: SVN.
A Documentaci on: L TEX.
Sistemas de bases de datos: Oracle, SQLServer, HSQLDB, MySQL, PostgreSQL. Servidores de aplicaciones: Oracle Container for Java (OC4J), Apache Tomcat. Navegadores: Firefox 2, Firefox 3.
11.4.
Datos del proyecto
En la tabla 11.4 en la p agina siguiente se presentan unos cuantos datos num ericos relativos a las plantillas utilizadas por Genereitor, as como de los paquetes de datos que genera, que dan una visi on aproximada de la cantidad de c odigo que es utilizado para proporcionar dichos paquetes a la medida de cada aplicaci on.
111
Esqueleto C odigo Tablas Maestras TOTALES
N um. plantillas 135 plantillas 28 plantillas 2 plantillas 165 plantillas
Datos de las plantillas L neas totales Tama no total Promedio l neas/plantilla 24.400 l neas 1,1 MiB 180 l neas/plantilla 5.700 l neas 384,2 KiB 200 l neas/plantilla 257 l neas 16,5 KiB 130 l neas/plantilla 30.300 l neas 1,5 MiB 185 l neas/plantilla
Promedio tama no/plantilla 8,5 KiB/plantilla 14 KiB/plantilla 8,5 KiB/plantilla 9,3 KiB/plantilla
112 Datos de los paquetes generados L neas totales Tama no total Promedio l neas/archivo 11.400 l neas 714 KiB 100 l neas/archivo 3.500 l neas 260 KiB 195 l neas/archivo 890 l neas 85 KiB 222 l neas/archivo
Esqueletoa C odigob Tablas Maestrasc
N um. archivos 116 archivos 18 archivos 4 archivos
Promedio tama no/archivo 6,2 KiB/archivo 14,5 KiB/archivo 21 KiB/archivo
Cuadro 11.1: Datos de las plantillas de Genereitor y los paquetes generados.
a Los
b Los
datos del paquete de esqueleto no incluyen im agenes ni librer as. datos se han tomado analizando el paquete generado para una s ola tabla de 5 campos. c Los datos se han tomado analizando el paquete generado para tres tablas relacionadas.
Cap tulo 12
Trabajo futuro
12.1. Mantenimiento
Durante el proceso de dise no y desarrollo de Genereitor siempre se tuvo en cuenta que no iba a ser una herramienta ((denitiva)), sino que por el contrario estar a siempre sometida a labores de mantenimiento, que corresponder an con los cambios en los requisitos y las exigencias de los clientes, y la futura adopci on de nuevas tecnolog as o actualizaci on de versiones de las utilizadas actualmente, por lo que habr a que adecuar el funcionamiento de Genereitor a las nuevas circunstancias. Es por esto que se ha previsto un sistema muy modular, de manera que cada componente realice funciones simples de forma ecaz y transparente, lo que facilita enormemente las tareas de mantenimiento.
12.1.1.
12.1.1.1.
Adici on de nuevas caracter sticas a Genereitor

Nuevos sistemas de bases de datos.
Como ya se ha visto, Genereitor soporta actualmente cinco sistemas de bases de datos (Oracle 9, PostgreSQL, MySQL, SQLServer y HSQLDB). Si en un futuro se desease dar soporte a un nuevo sistema de bases de datos, ser a necesario implementar su capa de acceso a datos (recordemos que existe una fachada com un a todos, pero una implementaci on para cada uno, puesto que son manejados de manera diferente) y los componentes que manejan su conexi on. Tambi en se habr a de a nadir dicho sistema de bases de datos al seleccionable de los formularios de la interfaz correspondientes a las vistas de conexi on. Al implementar Genereitor se ha tenido en cuenta la posibilidad de que en un futuro sea necesario a nadir, por lo que se ha hecho especial hincapi e en la modularidad de la gesti on de los diferentes sistemas de bases de datos. Por ejemplo, hay componentes que se han implementado de forma redundante, siendo iguales para varios sistemas de bases de datos. Esto es debido a que a la hora de a nadir soporte para un sistema de bases de datos nuevo, se podr a copiar la 113
CAP ITULO 12. TRABAJO FUTURO
implementaci on de uno ya existente y modicarlo seg un convenga, de manera que los componentes que manejan los sistemas existentes no tengan que ser modicados, y no se ponga en riesgo el perfecto funcionamiento de dichos sistemas durante la implementaci on del soporte para el nuevo. 12.1.1.2. Nuevos bloques funcionales
Genereitor cuenta con tres bloques funcionales, pero se contempla que en un futuro disponga de otros servicios relacionados con el desarrollo de nuevos proyectos. Dada la modularidad que ofrece la plataforma J2EE, implementar y acoplar un nuevo bloque funcional ser a una tarea trivial, u nicamente siendo necesaria la adici on de un enlace en el tag contenedor para que apareciera un bot on en la barra superior que llevase hasta la nueva funcionalidad, y una vez implementada la capa de aplicaci on del nuevo m odulo, la compilaci on y el despliegue se har a de forma autom atica. El nuevo bloque funcional dispondr a de las funcionalidades implementadas para la capa de acceso a datos, con lo que podr a acceder de forma transparente a diversos sistemas de bases de datos, y utilizar los objetos Conexion, Tabla y Columna. Tambi en contar a con la colecci on de custom tags y estilos para implementar las vistas de la interfaz, de forma que la apariencia del nuevo bloque funcional fuera similar al resto de la aplicaci on.
12.1.2.
Mantenimiento y modicaci on de los proyectos generados.
Todos los cheros fuente se generan a partir de plantillas XSL, de forma que cualquier modicaci on en los requisitos de los proyectos a generar que implique una modicaci on en el c odigo fuente, se aplicar a directamente sobre las plantillas. Las plantillas XSL se combinan con cadenas que contienen los datos, extra dos bien de la base de datos sobre la que se va a ejecutar la aplicaci on, bien de los par ametros introducidos por el programador en la interfaz de Genereitor. Estas cadenas est an dise nadas con XML, teniendo los par ametros de cada nodo nombres intuitivos, precisamente para facilitar su adici on a las plantillas. Tambi en es importante destacar el hecho de que actualmente las cadenas XML contienen exceso de informaci on respecto a la utilizada en las plantillas. La raz on de este exceso es precisamente la potencial necesidad de usar esas informaci on ((extra)) en un futuro, de forma que ya est e disponible y no sea necesario modicar las funciones que recolectan los datos, reduciendo este mantenimiento u nicamente a la modicaci on de las plantillas, lo que supone una ventaja que contrarresta con creces la disminuci on del rendimiento de las combinaciones1 .
1 Dada la velocidad de las combinaciones de las plantillas XSL, el exceso de datos en los nodos provoca una disminuci on de rendimiento tan peque na que es irrelevante, sobre todo teniendo en cuenta que el rendimiento general de Genereitor no es un aspecto crucial, puesto que no es una herramienta de uso intensivo.
114
CAP ITULO 12. TRABAJO FUTURO
As , cualquier modicaci on que sea necesaria en el c odigo generado deber a ser llevada a cabo en las propias plantillas. El uso de XSL permite que estas modicaciones puedan ser llevadas a cabo de una forma intuitiva, ya que es un lenguaje sencillo y que diferencia bien los elementos que manejan el ujo de la transformaci on (las sentencias XSL) de los componentes de la plantilla (elementos en el lenguaje correspondiente al chero que va a ser generado). Las modicaciones en la estructura de archivos de los proyectos generados deber an ser llevadas a cabo en los propios servlets de Genereitor, ya sean en la fase de generaci on de esqueleto, c odigo o tablas maestras. Dichas rutas se hallan agrupadas dentro de los servlets en arrays seg un las condiciones del proyecto a generar, separando los grupos de plantillas y cheros generados que se han de combinar para cada opci on seleccionada en la interfaz. Es importante tener en cuenta que, de producirse una modicaci on en la estructura de los proyectos generados, los paquetes que devuelven los tres bloques funcionales han de ser modicados para conservar una estructura id entica, ya que de lo contrario se producir an fallos en el arbol de directorio, generando archivos por duplicado, producto de la mezcla de la estructura nueva y la vieja.
12.1.3.
Trabajo futuro
El desarrollo que se ha de llevar a cabo de manera m as inmediata es la integraci on en los proyectos generados de los m odulos CMS2 , XMl y el soporte para grupos y perles del m odulo Usuarios. Todos estos m odulos han sido desarrollados en la Empresa y son utilizados en muchas de las aplicaciones que se desarrollan. Posteriormente, y seg un las necesidades con respecto a los requisitos de nuevos proyectos que se contraten, se ampliar a el soporte para otros sistemas de bases de datos tal como se ha comentado anteriormente, o se integrar an nuevos m odulos que se desarrollen en la empresa para uso com un.
2 Actualmente
el desarrollo de soporte para CMS se halla muy avanzado
115
Parte VI
Ap endices
116
Ap endice A
Documento de an alisis y dise no

A continuaci on se presenta la transcripci on del documento de An alisis y Dise no elaborado previamente al comienzo del desarrollo de la aplicaci on. Nota: La elaboraci on del documento de an alisis y dise no es previa al comienzo del desarrollo del proyecto, por lo que existen bastantes diferencias entre lo que en un principio se plane o y que aparece en este documento y el resultado nal.
A.1.
Descripci on y objetivos
El objetivo de este proceso es la obtenci on de una especicaci on detallada del nuevo Generador de c odigo J2EE, de forma que este satisfaga todas y cada una de las necesidades funcionales de los usuarios de la aplicaci on. En el apartado de este documento Situaci on Actual se realiza un estudio sobre c omo trata el sistema actual el proceso de generaci on de c odigo para de esta manera poder detectar problemas y necesidades que el nuevo sistema de informaci on tratar a de solventar tanto a nivel de funcionalidad como de agilidad en el manejo de la herramienta, as como a nadir nuevas caracter sticas que permitan incrementar su eciencia y evolucionar ciertos apartados del sistema actual para adaptarlos a las nuevas tendencias tecnol ogicas. La denici on del sistema junto con la especicaci on de requisitos realizada en este proceso permitir a describir con precisi on el nuevo sistema de informaci on, entrando en detalle en las tareas propias del An alisis Funcional: Modelo de procesos del sistema. Interfaces de usuario. 117
APENDICE A. DOCUMENTO DE ANALISIS Y DISENO
La participaci on activa de los usuarios durante las diferentes sesiones de trabajo para la completa denici on del sistema habr a resultado decisiva e imprescindible para la actual fase de an alisis del nuevo sistema, ya que dicha participaci on constituye una garant a de que los requisitos, datos, procesos e interfaces identicados han sido comprendidos e incorporados al sistema. El objetivo del proceso de Dise no del Sistema de Informaci on es la denici on de la arquitectura del sistema y del entorno tecnol ogico que le va a dar soporte, junto con la especicaci on detallada de los componentes del sistema de informaci on. A partir de dicha informaci on, se generan todas las especicaciones de construcci on relativas al propio sistema, as como la descripci on t ecnica del plan de pruebas, la denici on de los requisitos de implantaci on y el dise no de los procedimientos de migraci on y carga inicial.
A.2.
Resumen ejecutivo
El objetivo de este proyecto es ofrecer una herramienta que permita agilizar la creaci on de nuevos proyectos consistentes en aplicaciones web contra bases de datos de cualquier tipo. Se trata de una plataforma web que genera c odigo fuente J2EE de una aplicaci on web a todos los niveles, as como los elementos para los diferentes niveles del esquema:
A.2.1.
Data Access Layer (Capa de Acceso a Datos)
Genera las clases de acceso a datos con las operativas CRUD m as comunes: inserci on de registros, actualizaci on, consulta (por clave primaria o por cualquier otro campo) y borrado (unitario y masivo).
A.2.2.
Business Logic (L ogica de Negocio)
La plataforma ha de dar opci on de implementar la BL mediante Enterprise Java Beans (EJBs) o mediante clases b asicas Java, dependiendo si el servidor de aplicaciones en el que ir a alojado el proyecto soporta EJBs o no.
A.2.3.
Model-View-Controller (Modelo-Vista-Controlador)
La interfaz de usuario ser a implementada siguiendo el patr on de modelovista-controlador. Para ello se utilizar an clases previamente implementadas en el comex-common1 . Se generar an JSPs de listado y de alta/modicaci on, y Actions (Pseudo-Servlets ).
1 Comex dispone de un conjunto de clases y utilidades desarrolladas por la propia Empresa, que se agrupan en el paquete comex-common.
118
Para la realizaci on de los JSPs se utilizar a la colecci on de etiquetas (tags ) implementados en el comex-common. As mismo, estos JSPs han de cumplir obligatoriamente con un nivel AA de accesibilidad. El proyecto es una plataforma capaz de crear la base de una aplicaci on web apoyada en una base de datos, capaz de realizar los accesos CRUD t picos a esta. Tambi en crea la estructura de cheros b asica en la que se asientan todos los proyectos realizados por el departamento Java de Comex Grupo Ib erica, as como los archivos de instalaci on y conguraci on de la aplicaci on que se va a crear. El objetivo de este proyecto es facilitar en la medida de lo posible el comienzo del desarrollo de nuevas aplicaciones requeridas por los clientes de Comex Grupo Ib erica, proporcionando una base est andar, pero personalizada conforme a los requerimientos del sistema solicitado por el cliente. De este modo se evita el tener que comenzar cada nuevo proyecto desde cero, creando la estructura de cheros y proporcionando una parte importante del c odigo fuente, ajustando ya a los par ametros de la nueva aplicaci on, de modo que el programador no tenga que recurrir a un proyecto ya existente y modicar su c odigo para ajustarlo a la conguraci on y necesidades del nuevo programa. Esta herramienta proporciona un ahorro de tiempo considerable en las primeras etapas de desarrollo, permitiendo al programador ocupar su tiempo en tareas m as espec cas de cada proyecto, y evit andole las tareas mec anicas de creaci on de las bases de cada aplicaci on que se desarrolla, ya que el hecho de que exista una base com un ya creada por la organizaci on permite automatizar esta tarea. El funcionamiento se basa en la consulta de la base de datos sobre la que se apoyar a la aplicaci on. Esta base de datos puede ser proporcionada por el cliente, rescatada de un sistema de datos anterior del propio cliente o bien desarrollada por Comex a partir de los requisitos del proyecto solicitado. En cualquier caso, la elaboraci on de esta base de datos es un paso previo al uso del Generador, ya que este proporciona un sistema de consulta y edici on de los contenidos de las tablas donde se almacenan los datos, pero no es capaz de editar las propias tablas o a nadir nuevas. Es una herramienta de ayuda a la implementaci on de la aplicaci on requerida por el cliente, presentando una interfaz web que presenta las diferentes relaciones de la base de datos, as como las diferentes opciones disponibles para generar la aplicaci on, escogiendo el programador las que m as se ajusten al proyecto solicitado por el cliente. Una vez elegidas las opciones, el Generador devuelve un paquete comprimido, conteniendo la estructura de archivos de la aplicaci on y los m etodos de acceso a la base de datos ya implementados, todo listo para descomprimir en el servidor de pruebas y comenzar con el desarrollo de los apartados de la aplicaci on que no sea posible generar de forma autom atica, como podr a ser la interfaz web que se presentar a a los usuarios nales de la aplicaci on, etc.
119
A.3.
Sistema Actual
Se dispone actualmente de un generador de c odigo, que ofrece soporte para aplicaciones apoyadas en bases de datos Oracle, MySQL, PostgreSQL, HSQLDB y SQLServer. Al conectar a la base de datos, ofrece un combo con la lista de tablas presentes en la base de datos.
Figura A.1: P agina de conexi on del generador actual
Figura A.2: P agina de selecci on de tabla del generador actual
El primer problema con el que nos encontramos es que cuando se produce un error de conexi on con la base de datos, el programa no devuelve un mensaje de error, sino que vuelca a la p agina la excepci on provocada.
Figura A.3: Error de conexi on del generador actual
120
Una vez conectado a la base de datos correctamente y seleccionado una tabla de la misma, se nos presenta una pantalla con todos los campos que la forman, se nalando las claves primarias. Tambi en ofrece informaci on sobre el tipo de dato que se almacena en cada campo, su longitud y decimales en caso de ser valores num ericos. A continuaci on se ofrecen los distintos par ametros que podemos congurar para generar el c odigo apropiado a las necesidades del proyecto.
Figura A.4: P agina de selecci on de campos y par ametros del Generador actual
Los problemas m as importantes en el Generador actual son los siguientes: No se tiene en cuenta ning un tipo de relaci on entre tablas, lo cual se traduce en que todas las relaciones (claves ajenas) existentes en la base de datos han de ser escritas a mano por el programador para que la nueva aplicaci on las tenga en cuenta y se mantenga la consistencia en los datos. No se ofrece en el generador la posibilidad de a nadir restricciones al programa que no tenga la base de datos (obligar en el programa a introducir valores en campos que la base de datos acepta como nulos, incrementa las restricciones en longitudes de campos, a nade comprobaciones en campos que contengan NIF o fechas). Se ofrecen opciones que ya no son u tiles o ya no interesa tenerlas en cuenta, como la posibilidad de usar Struts en lugar de servlets, que no se incluir an en el nuevo Generador. La opci on de crear la estructura del proyecto se ofrece en la u ltima etapa del proceso, haciendo necesario conectar a una base de datos y seleccionar
121
una tabla, pese a que a la hora de crear el esqueleto no se utiliza para nada esta conexi on.
A.4.
Identicaci on y denici on de requisitos
En este apartado se lleva a cabo la denici on, an alisis y validaci on de los requisitos a partir de la informaci on facilitada por los usuarios participantes. Se obtiene un cat alogo detallado de los requisitos, a partir del cual se puede comprobar que los productos generados en las actividades de modelizaci on se ajustan a los requisitos de usuario.
A.4.1.
A.4.1.1.
Ambito y alcance del proyecto

Denici on del proyecto
El proyecto ser a una plataforma web capaz de generar c odigo J2EE autom aticamente ajust andose a los requisitos del proyecto solicitado por el cliente y cuyo desarrollo se va a comenzar. Para su funcionamiento ser a necesaria la creaci on previa de una base de datos contra la que trabajar a la nueva aplicaci on, dado que esta plataforma no ha de ser capaz de modicar las bases de datos que tiene en cuenta al generar el c odigo, y por tanto tampoco de crearlas (las aplicaciones generadas con esta herramienta s han de poder modicar su base de datos). El Generador trabajar a sobre el servidor de aplicaciones Apache Tomcat, y ser a capaz de manejar los tipos de bases de datos m as comunes (Oracle, PostgreSQL, MySQL, HSQLDB, SQLServer), contemplando la posibilidad de a nadir soporte para otros sistemas de bases de datos con la simple inclusi on de un plugin. Tambi en podr a crear c odigo para aplicaciones que ser an soportadas tanto por Tomcat como por otros servidores de aplicaciones (OC4J, etc), seg un lo indiquen los requisitos del proyecto. Los proyectos generados con esta aplicaci on seguir an la arquitectura en tres capas de J2EE (gura A.5 en la p agina siguiente), compuesta por una capa de acceso a datos, la l ogica de negocio y el patr on modelo-vista-controlador. La capa de acceso a datos proporciona un acceso simplicado a la informaci on contenida en la base de datos contra la que trabajar a la aplicaci on que se est a creando. Esto permite que los dem as componentes del sistema accedan a la base de datos sin necesidad de conocer el modo de almacenamiento de esta, de modo que se puedan tratar los objetos como tales, en lugar de como una tupla con valores contenida en una tabla de la base de datos. Esto proporciona un nivel mayor de abstracci on. Sobre esta capa de acceso a datos est a la l ogica de negocio, consistente en una serie de componentes que interact uan con la capa de acceso a datos, y una fachada que simplica el uso de estos componentes y contra la que trabajan las actions de la tercera capa. La l ogica de negocio se podr a implementar mediante EJBs o clases b asicas de Java, seg un dicten los requisitos del proyecto que solicita 122
Figura A.5: Esquema de la arquitectura J2EE
el cliente, y si el servidor sobre el que funcionar a la aplicaci on soporta EJBs o no. La tercera capa sigue el patr on modelo-vista-controlador, de forma que el usuario del programa interactuar a con una vista, com unmente compuesta por p aginas JSP. Estas JSPs har an peticiones al servidor, quien tiene implementado un controlador que se mantiene a la espera de instrucciones. En el momento en que recibe una petici on, invoca las actions necesarias, que se comunicar an con la capas inferiores y devolver an al usuario el resultado de la operaci on requerida. La interfaz de acceso p ublico generada por el programa cumplir a obligatoriamente con un nivel de accesibilidad AA2 seg un el W3C. Al solicitar el usuario la creaci on del esqueleto de un nuevo proyecto, aparte de la estructura de cheros de la aplicaci on, tambi en ser an generados los cheros de conguraci on XML y los scripts de instalaci on que luego ser an usados por ant para instalar la aplicaci on en el servidor. A.4.1.2. Identicaci on de participantes (Actores)
El usuario nal de esta herramienta ser a el desarrollador del proyecto requerido por el cliente, puesto que el Generador es una ayuda al desarrollo de las aplicaciones solicitadas a Comex Grupo Ib erica. Aunque la estructura general del proyecto pueda ser creada por un Jefe de Proyecto o un Analista y los diferentes m odulos sean generados por los Programadores, en la aplicaci on s olo existe un perl de usuario.
2 Aunque las interfaces generadas por el programa cumplan con el nivel AA de accesibilidad, la propia interfaz del Generador no lo cumplir a, puesto que para facilitar tareas a la hora de usarlo se utilizar a JavaScript.
123
A.5.
Cat alogo de requisitos del sistema
El nuevo sistema a desarrollar tiene como objetivo cumplir una serie de requisitos funcionales y no funcionales que se resumen a continuaci on:
A.5.1.
Requisitos funcionales
1. El sistema generar a el esqueleto inicial de la aplicaci on el cual podr a ser para una aplicaci on pensada para correr sobre un servidor que posea contenedor de EJBs o no. 2. El esqueleto inicial de la aplicaci on contendr a los descriptores de cheros XML necesarios para el empaquetado mediante la herramienta ant. 3. En el esqueleto inicial vendr an implementados los componentes gen ericos de la aplicaci on: Fachada. Acci on base. Clases con constantes. Ficheros de conguraci on (acciones, textos). Ficheros de etiquetas. Descriptores de cheros (para contenedores de EJBs si es el caso, para el servidor web y taglibs ). Librer as necesarias. 4. En el esqueleto inicial se ha de incluir tambi en las clases, librer as y conguraciones necesarias para el uso de las herramientas gen ericas para la gesti on de par ametros y tablas maestras implementadas por Comex. 5. El sistema generar a el c odigo necesario para todas las capas tomando como base una de las tablas de la base de datos. 6. El c odigo generado depender a de si el servidor sobre el que se va a ejecutar soporta EJBs o no. 7. Si el servidor soporta EJBs, se dar a la opci on de generar c odigo para EJBs locales o remotos. 8. El sistema tendr a en cuenta las relaciones entre las tablas de la base de datos (foreign keys ), y generar a el c odigo para acceder a las tablas referenciadas por estas autom aticamente. 9. El sistema ha de ser capaz de generar aplicaciones para diferentes sistemas de bases de datos (Oracle, PostgreSQL, MySQL, HSQLDB, SQLServer). 10. Existir a la posibilidad de a nadir soporte para otros sistemas de bases de datos mediante la inclusi on de plugins al sistema. Se proporcionar a documentaci on para ello.
124
11. Generar a aplicaciones pensadas para ser soportadas por diferentes servidores de aplicaciones (Apache Tomcat, OC4J). 12. Crear a las bases de la interfaz web gen erica con sus distintos apartados (cabeceras y pies comunes a todas las p aginas, men u). 13. Proporcionar a una serie de funciones JavaScript gen ericas para la interfaz web (calendario y comprobaci on de fechas, NIF/CIF, implementaci on del algoritmo md5...).
A.5.2.
Requisitos no funcionales
1. Toda interfaz de acceso p ublico generada por el programa cumplir a con un nivel de accesibilidad AA3 seg un el W3C. 2. El aplicativo web ser a compatible con los navegadores web est andar. 3. La arquitectura del software ser a la de un Sistema Centralizado con Arquitectura de Tres Capas. Dicha arquitectura seguir a los est andares J2EE. 4. El servidor web que soportar a la aplicaci on ser a Apache Tomcat. 5. La compilaci on e instalaci on de las aplicaciones generadas se llevar a a cabo mediante ant, que proporciona independencia de la plataforma sobre la que se instala, al contrario que makefile.
A.6.
Modelo de procesos
Para la realizaci on de este apartado se habr an analizado las necesidades de los usuarios para establecer un conjunto de procesos que conformen el sistema de informaci on. Se realizar a un enfoque descendente (top-down ), en varios niveles de abstracci on y/o detalle, donde cada nivel proporciona una visi on m as detallada del proceso denido en el nivel inmediatamente superior. En la elaboraci on de este modelo de procesos se llegar a a un nivel de descomposici on en el que los procesos obtenidos sean claros y sencillos, es decir, buscando un punto de equilibrio en el que dichos procesos tengan signicado por s mismos dentro del sistema global y a su vez la m axima independencia y simplicidad. La totalidad de procesos indicados en este apartado ser an los que deber a dar soporte el nuevo sistema.
A.6.1.
Generaci on del esqueleto
Al iniciar el Generador, se ofrecer a al usuario la opci on de crear el sistema de cheros b asico para una nueva aplicaci on, dado que para esta tarea no se requiere conexi on a base de datos.
3 Unicamente es requisito que sean accesibles las interfaces de acceso p ublico, es decir, la parte de la interfaz destinada a administraci on no ha de cumplir este requisito.
125
Figura A.6: Esquema de los procesos del Generador
Una vez seleccionadas las opciones correspondientes, se devuelve un chero comprimido que contiene la estructura ((vac a)) del nuevo proyecto, as como los cheros XML de conguraci on y los scripts de instalaci on que luego ser an usados por ant para instalar la aplicaci on en el servidor que corresponda. Aunque no se necesite conectar a la base de datos para generar el esqueleto, la aplicaci on pedir a una serie de datos necesarios para crear la estructura: Tipo de base de datos (combo de los tipos de BD disponibles en el Generador). Tipo de servidor de aplicaciones (combo de los tipos de servidores disponibles en el Generador). Nombre de la aplicaci on a crear. Nombre del paquete base. Datos de conexi on a la base de datos (host, puerto, SID, usuario, contrase na). Opci on de comprobar si estos datos son correctos mediante un bot on que lance la conexi on contra la base de datos y devuelva un mensaje seg un los datos sean correctos o no. Prejos de los nombres de tabla (terminados en (( ))). Prejos de los par ametros (terminados en (( ))).
126
Si el esqueleto va a ser generado con par ametros o con tablas maestras (radio ). Ruta de los par ametros/tablas maestras. Lista de librer as a incluir. El esquema de procesos de la fase de generaci on del esqueleto se presenta en la gura A.7.
Figura A.7: Esquema de procesos de la generaci on del esqueleto
A.6.2.
Generaci on de script de tablas maestras
Esta funcionalidad del generador permite crear el script de tablas maestras para un proyecto mediante la conexi on a la base de datos sobre la que se apoyar a, permitiendo al usuario seleccionar las tablas que se habr an de tener en cuenta para la generaci on de dicho script. En primer lugar se presenta una pantalla de conexi on, donde una vez introducidos los datos de host, puerto, SID, usuario y contrase na, el programa se conecta a la base de datos y devuelve una lista de todas las tablas que la conforman (gura A.8 en la p agina siguiente). De dicha lista el usuario deber a elegir las que convengan para generar el script. Una vez seleccionadas las tablas apropiadas, el Generador ofrecer a al usuario una lista de todos los campos y opciones. Una vez seleccionadas las tablas que se utilizar an, se presenta una pantalla con todos los campos que conforman las tablas seleccionadas, as como una serie
127
Figura A.8: Esquema de procesos de la selecci on de tablas para la generaci on del script de tablas maestras
de opciones tanto de cada tabla como de los campos, de forma que el usuario pueda elegir las que m as convengan seg un los requisitos del proyecto a realizar. Para cada tabla se informar a de su clase y se pedir a una descripci on (literal ) y la selecci on del campo por defecto. Para cada campo, aparte de las opciones de tabla, se podr a aplicar la restricci on de campo obligatorio y se presentar an las posibilidades de tenerlos en cuenta para listados, buscadores, detalles y el tratamiento de claves ajenas. Una vez escogidas todas las opciones necesarias, se genera el script. El esquema de procesos de este u ltimo paso se presenta en la gura A.9 en la p agina siguiente.
A.6.3.
A.6.3.1.
Generaci on de c odigo
Conexi on a la base de datos
El primer paso para la generaci on de un nuevo m odulo de un proyecto es la conexi on a la base de datos sobre la que se ejecutar a. Para esto, el usuario seleccionar a el tipo de base de datos que la aplicaci on va a usar (y que debe estar implementada previamente al uso del Generador). Tras esto, rellenar a los datos de conexi on (Host, Puerto, SID, Usuario y Contrase na) y pulsar a el bot on ((Conectar)). Al pulsar ((Conectar)) se comprobar a que los datos de conexi on introducidos sean correctos, de otro modo devolver a un error con una breve explicaci on y volver a a pedir los datos de conexi on. Tambi en se comprobar a que el host contra el que lanzamos la petici on est e activo, y que la base de datos que hemos introducido exista en el servidor, as como 128
Figura A.9: Esquema de procesos de la selecci on de campos y opciones para la generaci on del script de tablas maestras
que el usuario y la contrase na proporcionados para el acceso a la misma sean correctos. Si algo de esto no se cumple, nuevamente se mostrar a un error y retornar a a la p agina de conexi on. A.6.3.2. Selecci on de la tabla principal
Tras conectar a la base de datos, el sistema realiza una consulta y se presenta al usuario un listado de todas las tablas contenidas, seleccionando este la que le interese. Al seleccionarla, se realizar a otra consulta a la base de datos, obteniendo el nombre de los campos que conforman esa tabla. A.6.3.3. Selecci on de tablas relacionadas y campos
Una vez seleccionada la tabla principal, se vuelve a consultar la base de datos, mostrando al usuario un listado de las tablas que hacen relaci on a esta, y ofreciendo la posibilidad de seleccionar o no cada una de ellas, de forma que sean tenidas o no en cuenta a la hora de generar el c odigo. Asimismo para cada tabla (principal y relacionadas) existe la posibilidad de consultar y seleccionar sus campos. Al seleccionar una de las tablas, se presentar a al usuario el listado de campos que la forman, de manera que este pueda elegir los que interesan. Tambi en se ofrecer a informaci on acerca de tipos de datos almacenados, nombres de variables y si son clave primaria de la tabla. Las consultas a base de datos se realizar an tal como indica el esquema de la gura A.10 en la p agina siguiente. Se consultar an las claves ajenas de otras
129
Figura A.10: Esquema de procesos de la selecci on de la tabla principal
clases que hagan referencia a la tabla a partir de la que se va a trabajar, y se consultar a al usuario si quiere que sea tenida en cuenta. S olo se tendr an en cuenta las referencias a primer nivel, es decir, se descartar an los atributos de las tablas que sean clave ajena de otra clase que haga referencia a la tabla sobre la que se est a trabajando, de la forma que indica el diagrama de la gura A.11:
Figura A.11: Esquema de tratamiento de tablas relacionadas
Este proceso se repetir a tantas veces como clases hagan referencia a la clase seleccionada. A.6.3.4. Selecci on de campos
Tras este paso, se ofrece al usuario una lista de todos los campos de las tablas que se han seleccionado con anterioridad, de manera que este pueda revisar que todo sea correcto. En esta lista tambi en se ofrecer an una serie de opciones de manera que se puedan aplicar algunas restricciones en la entrada de datos de la aplicaci on a generar que la base de datos no tenga. La lista mostrar a para cada tabla:
130
Seleccionado: un checkbox que permite tener en cuenta o no los campos de cada tabla, tanto de la principal como de las relacionadas que se han seleccionado. ID del campo. Campo obligatorio: un checkbox nos indicar a si en la base de datos ese campo puede tomar valores nulos o no. Si el campo es obligatorio (mandatory ) en la base de datos, el checkbox aparecer a seleccionado e inactivo. Si no lo es, podremos seleccionarlo para que en nuestra aplicaci on s lo sea. Clase: indica el tipo de dato que contiene cada campo. Clave: indica si el campo es clave primaria o ajena de alguna tabla. MaxLength: indica la longitud m axima que puede tomar un campo de tipo cadena de caracteres. Ofrece la posibilidad de aumentar en el programa generado la restricci on que imponga la base de datos, o de establecerla si no existe. Descripci on: permite introducir el nombre (literal ) de cada campo. A.6.3.5. Selecci on de par ametros
En este u ltimo paso se seleccionar an los par ametros oportunos para las necesidades de la aplicaci on que se va a generar. Las opciones son las siguientes: Nombre del paquete. Lista de nombres de beans. Generar c odigo para borrar varios benas en listado (check ). Generar JSP de edici on (check ). Generar JSP de detalle (check ). Nombre de la aplicaci on. Generar con EJB/Clases Java (radio ). Generar EJB locales/remotos (radio, s olo activo si en el anterior se seleccion o EJB). A la hora de trabajar con las tablas relacionadas con la primaria, el u nico campo que variar a respecto de esta ser a el nombre del bean que tenga asociado. Es por esto que se presenta una lista con todos los nombres de las tablas seleccionadas, de forma que se puedan rellenar los diferentes nombres de los bean s. Las dem as opciones ser a id enticas para todas las tablas, as que s olo se tendr an que rellenar una vez. Seg un las capacidades del servidor donde ir a alojada la aplicaci on que estamos creando y los requisitos del proyecto, el generador ofrece la posiblidad de 131
generar c odigo para usar EJBs o clases Java. Al seleccionar EJBs, aparecer a una nueva opci on que dar a a elegir entre EJBs locales o remotos. Si se seleccionan clases Java, esta opci on no estar a visible, ya que es indiferente. Cuando ya hayamos completado todas las opciones para todas las tablas relacionadas que nos interesan, el Generador nos devolver a un paquete comprimido que contendr a el c odigo fuente solicitado, tal como indica la gura A.12.
Figura A.12: Esquema de procesos de la selecci on de par ametros
A.7.
Denici on de la arquitectura del sistema
La estructura cliente-servidor posibilita que la aplicaci on s olo tenga que estar instalada en una m aquina, que esperar a a que los clientes realicen peticiones para ejecutar las operaciones requeridas y devolver los resultados. El servidor sobre el que est a alojada la aplicaci on es Apache Tomcat, pese a que dentro de la funcionalidad del programa es capaz de generar c odigo fuente para proyectos no basados en este servidor de aplicaciones. La interfaz presentada al cliente es una plataforma web, de forma que sea accesible desde cualquier punto de la Intranet de la Empresa, o incluso a trav es de Internet, con un simple navegador, evitando la instalaci on de programas cliente espec cos para cada usuario, y la actualizaci on de estos programas cliente en posibles actualizaciones de la aplicaci on. Las ventajas de este dise no frente a una estructura monol tica (un ejecutable aut onomo, y una copia de este instalada en cada cliente) son evidentes, haciendo que la disponibilidad del sistema sea instant anea en el momento que sea requerida, no teniendo que estar instalado en el cliente cuando no sea utilizado, y al ser presentado a trav es de una interfaz web, garantizamos el funcionamiento en cualquier sistema que pueda utilizar el cliente, puesto que las operaciones se ejecutar an s olo en el servidor. Un inconveniente de esta arquitectura puede ser el riesgo de sobrecarga de la red o del servidor cuando muchos clientes accedan a el de forma simult anea, 132
pero dado que el uso de la aplicaci on no ser a intensivo, este aspecto puede ser descartado. La arquitectura del proyecto, correspondiente con la arquitectura J2EE, est a formada por tres capas (gura A.13 en la p agina siguiente): El primer nivel, la capa de acceso a datos (DAL, Data Access Layer), es capaz de almacenar bases de datos de varios tipos (Oracle, MySQL, PostgreSQL, HSQLDB, SQLServer), seg un las propiedades o los requisitos del proyecto a realizar. Puesto que la elaboraci on de la base de datos es anterior al uso del Generador, este ha de ser vers atil en este sentido, ya que se ha de ajustar a las caracter sticas requeridas por el proyecto solicitado por el cliente. Esta capa no es la encargada de manejar las conexiones a la base de datos, sino que siempre la recibir a como par ametro, siendo la l ogica de negocio quien gestione la comunicaci on con esta. El segundo nivel, la l ogica de negocio (BL, Business Logic), implementa los modos de acceso a la capa de datos, de forma que el programa sea capaz de trabajar con los distintos tipos de base de datos mencionados anteriormente. Asimismo, proporciona una fachada para la tercera capa, con arquitectura modelo-vista-controlador, de manera que el modelo sea capaz de comunicarse con los datos independientemente de la forma en que est en almacenados. El tercer nivel, la parte web de la aplicaci on, sigue el patr on modelo-vistacontrolador (MVC, Model-View-Controller). Esta separaci on en tres niveles permite independencia entre los datos presentados o requeridos por la interfaz de usuario (vista) y los que son enviados al servidor para su tratamiento (modelo), dado que es el controlador quien procesa y responde a los eventos invocados por la interfaz de usuario, y en su caso ordena lecturas o cambios en el modelo, que a su vez se comunicar a con la Business Logic para consultar o actualizar los datos almacenados f sicamente en la base de datos. Para el desarrollo de este nivel, se utilizan clases implementadas en el comex-common. La vista estar a implementada mediante JSP.
A.7.1.
Gestor de base de datos
El Generador de c odigo tomar a como base inicial los datos contenidos en una base de datos, que variar a seg un las necesidades del proyecto a realizar. Dado que los diferentes proyectos se apoyar an sobre bases de datos de distintos tipos, el Gestor de bases de datos tendr a que cumplir con los siguientes requisitos: Compatible con SQL. Capaz de hacer consultas, pero ha de impedir la posibilidad de insertar, actualizar o borrar campos.
A.7.2.
Servidor de aplicaciones
El sistema se implementar a sobre un servidor de aplicaciones (Apache Tomcat), que proporcionar a a la aplicaci on web los siguientes recursos fundamentales: 133
Figura A.13: Esquema de la arquitectura de software
Servidor web, capaz de construir de forma din amica la interfaz del sistema, basado en p aginas web (JSPs). Ser a capaz de soportar concurrencia y controlar distintas sesiones de trabajo simult aneas. Contenedor, capaz de ejecutar los diferentes componentes de software que permitir an desarrollar la l ogica de los componentes base y los m odulos funcionales de la plataforma, as como encapsular la comunicaci on del sistema con el gestor de base de datos. Al igual que el servidor web, es capaz de soportar concurrencia y controlar distintas sesiones de trabajo simult aneas.
A.8.
Modelo de datos
Dentro de este apartado se identican todas las necesidades de informaci on de cada uno de los procesos que conforman el sistema de informaci on, con el n 134
de obtener un modelo de datos que contemple todas las entidades, relaciones y atributos necesarios para dar respuesta a dichas necesidades. Dado que este proyecto no se apoya en ninguna base de datos propia, no existe un modelo de datos concreto que podamos describir de antemano. El Generador es capaz de trabajar con bases de datos a dos niveles:
A.8.1.
Consulta
Para generar el c odigo de la aplicaci on, el generador se ejecuta contra la base de datos propia de la aplicaci on a crear, cuya implementaci on se habr a realizado de antemano. Esta consulta no va dirigida a los datos que pudieran estar contenidos en esa base de datos, sino a los metadatos propios de su estructura. Interesa c omo est an almacenados los datos. Por ello, el sistema ha de ser capaz de realizar estas consultas en cualquier sistema de bases de datos contra el que sea ejecutado, o en su defecto prever una ampliaci on para sistemas de bases de datos que no est en incluidos en la implementaci on base, de manera sencilla y documentada, mediante plugins que ser an desarrollados conforme a las nuevas necesidades.
A.8.2.
Generaci on
Una vez consultada la estructura de la base de datos, el Generador ser a capaz de crear ordenes que se efect uen contra la base de datos, ya no s olo de consulta, sino de modicaci on, creaci on y borrado de registros, esta vez ya a nivel de contenidos (datos) y no de estructura (metadatos). Esto es debido a que las aplicaciones generadas han de ser capaces de modicar los datos contenidos en las bases de datos contra las que trabajan.
A.9.
Denici on del interfaz de usuario (prototipos)
La interfaz de usuario est a estructurada en tres ((ramas)), correspondientes a las tres funciones principales del Generador: Generaci on del esqueleto de un proyecto. Generaci on del script de tablas maestras de un proyecto. Generaci on de c odigo de las diferentes partes de un proyecto. Estas tres opciones se presentan en la p agina inicial del Generador, mediante tres botones que enlazan a cada una de las funciones. Existe una cuarta opci on (Ajustes ), que permitir a establecer los par ametros de conexi on por defecto para las distintas bases de datos sobre las que la Empresa est e trabajando en cada momento, de forma que no se tengan que introducir cada vez que se requiera la 135
ayuda del Generador. A continuaci on se detallan los diferentes componentes de cada pantalla de la interfaz.
A.9.1.
Generaci on del esqueleto
Esta parte consta s olo de una pantalla, que pedir a los siguientes campos: Tipo de base de datos: ser a un combo que mostrar a los sistemas de bases de datos para los que puede trabajar el Generador (Oracle, MySQL, PostgreSQL, HSQLDB, SQLServer y cualquiera que se a nada en un futuro), de los que habr a que seleccionar el que soportar a la nueva aplicaci on. Tipo de servidor de aplicaciones: ser a un combo que mostrar a los servidores de aplicaciones para los que puede trabajar el Generador (OC4J, Tomcat y cualquiera que se a nada en un futuro), de los que habr a que seleccionar el que soportar a la nueva aplicaci on. Nombre de la aplicaci on: ser a un textbox en donde habr a que introducir el nombre de la aplicaci on para la que se va a crear el esqueleto. Nombre del paquete base: ser a un textbox en donde habr a que introducir el nombre del paquete base de la aplicaci on para la que se va a crear el esqueleto. Datos de conexi on: aunque para este paso no es necesario conectarse a una base de datos, rellenar ahora los datos de conexi on permite al Generador crear el esqueleto ya preparado para la base de datos sobre la que vaya a trabajar la aplicaci on. Host: textbox donde se introduce el servidor donde se aloja la base de datos. Puerto: textbox num erico donde se introduce el puerto en el que escucha el servidor de bases de datos. SID: textbox donde se introduce el nombre (SID) de la base de datos. Usuario: textbox donde se introduce un usuario con permisos de lectura de la base de datos. Contrase na: textbox de tipo password donde se introduce la contrase na del usuario. Comprobar: bot on que lanza una conexi on con los datos introducidos hacia la base de datos, e informa de si ha podido conectar o no. Pese a que en esta etapa no es necesario conectar a la base de datos, este bot on permite comprobar, en el caso de que el servidor de bases de datos est e activo, si los datos de conexi on introducidos son correctos. Par ametros: permite seleccionar mediante un checkbox si se utilizar an par ametros en la aplicaci on que se va a generar. De ser as , se activar an dos campos de texto, donde se habr an de introducir el prejo de los nombres de los par ametros (que acabar a en (( )), de no ser as el Generador lo pondr a al nal del nombre introducido) y la ruta donde se encuentran esos par ametros. 136
Tablas maestras: permite seleccionar mediante un checkbox si se utilizar an tablas maestras en la aplicaci on que se va a generar. De ser as , se activar an dos campos de texto, donde se habr an de introducir el prejo de el los nombres de las tablas maestras (que acabar a en (( )), de no ser as Generador lo pondr a al nal del nombre introducido) y la ruta donde se encuentran las tablas maestras. Usuarios: permite seleccionar mediante un checkbox si la aplicaci on que se va a generar tendr a soporte para diferentes usuarios. De ser as , se activar an los siguientes campos: Prejo de los nombres de usuario: textbox en el que se introducir a el prejo que llevar an los nombres de usuario, seguido del car acter (( )). De no ser as , el Generador lo pondr a al nal del nombre introducido. Ruta de los usuarios: textbox donde se introducir a la ruta donde se encuentra los archivos de usuario. Grupos: checkbox que indica que la aplicaci on a generar ha de tener soporte para grupos de usuarios. Perles: checkbox que indica que la aplicaci on a generar ha de tener soporte para diferentes perles de usuario. Al activar esta opci on, se activan los siguientes campos: Textbox para a nadir un nuevo perl. Lista que muestra los perles a nadidos. Bot on de ((a nadir perl)), que a nade el nombre del perl que gura en el textbox a la lista. Bot on de ((borrar perl)), que elimina de la lista el perl seleccionado. Librer as: lista de las librer as disponibles, de donde se seleccionar an las que la nueva aplicaci on necesite para funcionar. Generar: bot on que conrma las opciones introducidas anteriormente y genera el paquete que contendr a el esqueleto ya creado. Retroceder: bot on que cancela el proceso y devuelve al usuario a la p agina principal.
A.9.2.
Generaci on de script de tablas maestras
Este apartado consta de tres etapas: A.9.2.1. Conexi on
Esta pantalla consta de los siguientes campos: Datos de conexi on: Tipo de base de datos: lista para seleccionar el tipo de base de datos a la que se va a conectar (a nadido posteriormente). 137
Host: textbox donde se introduce el servidor donde se aloja la base de datos. Puerto: textbox num erico donde se introduce el puerto en el que escucha el servidor de bases de datos. SID: textbox donde se introduce el nombre (SID) de la base de datos. Usuario: textbox donde se introduce un usuario con permisos de lectura de la base de datos. Contrase na: textbox de tipo password donde se introduce la contrase na del usuario. Conectar: Bot on que lanza la conexi on contra el servidor de bases de datos seg un los datos introducidos. Retroceder: bot on que cancela el proceso y devuelve al usuario a la p agina principal. Al pulsar el bot on ((Conectar)), y si se puede establecer la conexi on, se pasa a la siguiente etapa. En caso contrario, informa del error de conexi on y devuelve al usuario a la pantalla de conexi on para modicar los datos. A.9.2.2. Selecci on de tablas
Una vez establecida la conexi on, se presenta al usuario una pantalla con los siguientes campos: Lista de tablas: lista doble que muestra todas las tablas contenidas en la base de datos, permitiendo seleccionar al usuario las que convengan para la generaci on del script de tablas maestras. Siguiente: bot on que conrma las opciones introducidas anteriormente y env a al usuario a la pantalla de selecci on de campos. Retroceder: bot on que cancela el proceso y devuelve al usuario a la pantalla de conexi on. A.9.2.3. Selecci on de campos
Tras seleccionar las tablas que interesan, el sistema nos muestra una pantalla con una lista de todas las tablas que hemos seleccionado en el paso anterior y todos los campos que las componen, as como una serie de opciones que se explican a continuaci on: ID de tabla: muestra la tabla cuyos atributos aparecen a continuaci on en la lista. Clase de tabla: muestra la clase (nombre del bean ) de cada tabla. TableName: textbox que permite establecer un nombre de tabla.
138
Default: lista de radios que permiten seleccionar el campo por defecto en cada tabla. ID: muestra el ID de los campos de cada tabla. Clase: muestra el tipo de dato que se almacena en cada campo. Clave: indica si los datos almacenados en esa campo son claves primarias de ella o ajenas referenciando a otras. Obligatorio: si se selecciona, impide que ese campo pueda tomar valores nulos. Si esta restricci on ya est a impuesta en la base de datos, el checkbox aparecer a tildado e inactivo. Literal: permite establecer el literal de cada campo. Su valor por defecto ser a el identicador de campo en formato Java4 . Listado: Checkbox de activaci on. El usuario lo activar a si quiere que el atributo se nalado sea listable. Al activarlo, aparecen seleccionables las siguientes opciones: Indice: permite establecer el orden en el que aparecer an en la lista los diferentes campos de una tabla. Ordenable: muestra si el listado conseguido es ordenable o no. Buscador: Checkbox de activaci on. El usuario lo activar a si quere que ese campo aparezca en la funci on buscador que aparecer a en la p agina del futuro proyecto. Indice: indica5 el orden en el que aparecer an los resultados del buscador con los campos introducidos. MaxLength: permite establecer la m axima medida del campo. Detalle: Checkbox de activaci on. El usuario lo activar a si quiere que para el atributo seleccionado haya una vista ((detalle)). Indice: Indice: permite establecer el orden en el que aparecer an en los resultados los campos introducidos. MaxLength: permite establecer la m axima medida del campo. Foreign Keys: Checkbox de activaci on. El usuario lo activar a si quiere que la foreign key detectada sea tenida o no en cuenta.
4 Ejemplo: el campo ID PRODUCTO FABRICADO tendr a como literal por defecto idProductoFabricado. 5 El ndice de buscador se actualiza autom aticamente al tildar el checkbox de activaci on.
139
Campo: combo que permitir a seleccionar qu e campo de la tabla referenciada por la foreign key es el que contiene el nombre del registro que nos interesa. Nombre de tabla referenciada: se muestra a modo informativo el nombre de tabla referenciada por la FK presente. Nombre de campo referenciado: se muestra a modo informativo el nombre del campo referenciado por la FK presente.
A.9.3.
Generaci on de c odigo
Este apartado consta de cinco etapas: A.9.3.1. Conexi on
Esta pantalla consta de los siguientes campos: Datos de conexi on: Tipo de base de datos: lista para seleccionar el tipo de base de datos a la que se va a conectar (a nadido posteriormente). Host: textbox donde se introduce el servidor donde se aloja la base de datos. Puerto: textbox num erico donde se introduce el puerto en el que escucha el servidor de bases de datos. SID: textbox donde se introduce el nombre (SID) de la base de datos. Usuario: textbox donde se introduce un usuario con permisos de lectura de la base de datos. Contrase na: textbox de tipo password donde se introduce la contrase na del usuario. Conectar: bot on que lanza la conexi on contra el servidor de bases de datos seg un los datos introducidos. Retroceder: bot on que cancela el proceso y devuelve al usuario a la p agina principal. A.9.3.2. Selecci on de la tabla principal
En este apartado se presentan al usuario los siguientes campos: Lista de tablas: listado de todas las tablas que forman parte de la base de datos a la que se ha conectado, donde el usuario seleccionar a la que le interese. Siguiente: bot on que lleva al usuario al siguiente paso. Retroceder: bot on que devuelve al usuario a la pantalla de conexi on a la base de datos. 140
A.9.3.3.
Selecci on de tablas relacionadas
En este apartado se presentan al usuario los siguientes campos: Nombre de la tabla principal: muestra el nombre de la tabla principal, la que se ha seleccionado en el paso anterior y a la que hacen referencia las tablas de la lista que hay a continuaci on. Lista de tablas relacionadas: se presenta una lista con todas las tablas que hay en la base de datos que hacen referencia a la tabla principal, es decir, que contienen claves ajenas que corresponden con la clave primaria de la tabla principal. Cada tabla ir a acompa nada de un checkbox que permitir a seleccionarla o no. Siguiente: bot on que lleva al usuario a la pantalla de selecci on de campos. Retroceder: bot on que devuelve al usuario al paso anterior. A.9.3.4. Selecci on de campos
ID de tabla: muestra la tabla cuyos atributos aparecen a continuaci on en la lista. ID: muestra el ID de los campos de cada tabla. Clase: muestra el tipo de dato que se almacena en cada campo. Clave: indica si los datos almacenados en esa campo son claves primarias de ella o ajenas referenciando a otras. Obligatorio: indica si en la base de datos ese campo puede tomar valores nulos o no. Si el campo es obligatorio (mandatory ) en la base de datos, el checkbox aparecer a seleccionado e inactivo. Si no lo es, podremos seleccionarlo para que en nuestra aplicaci on s lo sea. MaxLength: indica la longitud m axima que puede tomar un campo de tipo cadena de caracteres. Ofrece la posibilidad de aumentar en el programa generado la restricci on que imponga la base de datos, o de establecerla si no existe. Descripci on: permite introducir el nombre (literal ) de cada campo. Siguiente: bot on que lleva al usuario a la pantalla de selecci on de campos. Retroceder: bot on que devuelve al usuario al paso anterior. Una vez seleccionados los campos a tener en cuenta y conrmadas las opciones de cada uno, el usuario introducir a las caracter sticas del proyecto a crear mediante el siguiente formulario: Nombre del paquete: textbox donde se introducir a el nombre del paquete que se va a generar.
141
Lista nombres de los bean s: para cada tabla (primaria y relacionadas) se ha de introducir el nombre del bean asociado a ellas. Constar a de: Nombre de la clase. Nombre del bean : textbox. Generar c odigo para borrar varios bean s en listado: checkbox que permite al usuario elegir si se desea generar c odigo para borrar varios bean s en listado o no. Generar JSP de edici on: checkbox que permite al usuario elegir si se desea generar JSPs de edici on. Generar JSP de detalle: checkbox que permite al usuario elegir si se desea generar JSPs de detalle. Nombre aplicaci on: textbox donde se introducir a el nombre de la aplicaci on para la que se est a creando el paquete. EJBs/Clases Java: radio que permite al usuario elegir si se desea generar c odigo con EJBs o con clases Java, seg un el servidor de aplicaciones que contenga la aplicaci on soporte o no EJBs. Si se seleccionan EJBs, aparecer a la siguiente opci on: EJB local/remoto: radio que permite al usuario elegir si se desea generar EJBs locales o remotos. Generar: bot on que conrma las opciones introducidas anteriormente y genera el archivo comprimido que contendr a el c odigo del paquete. Retroceder: bot on que cancela el proceso y devuelve al usuario a la pantalla de resumen/opciones de campos A continuaci on se presenta un esquema de los campos que contendr an los diferentes apartados de la interfaz web (guras A.14 en la p agina siguiente y A.15 en la p agina 143):
142
Figura A.14: Esquema de la interfaz del generador
143
Figura A.15: Recopilaci on de los formularios de la interfaz del generador
144
A.10.
Migraci on inicial de datos
Dado que el Generador no se apoya en ninguna base de datos propia, sino que trabaja a partir de las bases de datos de las aplicaciones que va a crear, no existe migraci on inicial.
145
Ap endice B
Combineitor, herramienta complementaria

Como ya se ha visto, en la fase de generaci on de esqueleto se proporcionan ciertos cheros ((incompletos)), cuyo contenido se amplia mediante trozos inclu dos en el paquete que se devuelve al usuario en la fase de generaci on de c odigo de cada entidad de la base de datos. En un principio, el mecanismo de inclusi on de dichos trozos en sus archivos correspondientes se llevaba a cabo a mano, pegando el trozo en el archivo generado en el esqueleto. Este proceso es breve, no lleva m as de cinco minutos, y est a esquematizado en la gura B.1.
Figura B.1: Proceso de combinar un chero a trozos. Sin embargo, en la fase de implementaci on de las plantillas, se llevaban a cabo decenas de pruebas cada d a para comprobar el correcto funcionamiento de las aplicaciones generadas, por lo que el tiempo perdido en completar los archivos se multiplicaba, disminuyendo enormemente la producci on y ralentizando el desarrollo del proyecto. Dichos cheros son los siguientes: acciones.properties 146
APENDICE B. COMBINEITOR, HERRAMIENTA COMPLEMENTARIA
etiquetas.properties InicioFilter.java FacadeEJB.java FacadeEJBBean.java ejb-jar.xml orion-ejb-jar.xml Scripts SQL o PL/SQL Como soluci on temporal, se desarroll o un peque no script de bash que combinaba dichos trozos autom aticamente, evitando al programador la tarea de completarlos a mano. Pero tras un an alisis, se decidi o incorporar denitivamente este script al sistema, de forma que todos los usuarios pudieran disponer de el. Para ello se mejor o sensiblemente el sistema de combinaci on, estableciendo en las plantillas de los cheros incompletos marcas en forma de comentarios. El script analizar a y reconocer a dichas marcas, insertando en su lugar los trozos correspondientes. Tambi en se le dot o de una interfaz m as amigable que la l nea de comandos, optando por una basada en di alogos mediante el paquete dialog, disponible en la pr actica totalidad de distribuciones GNU/Linux.
B.1.
Funcionamiento
El funcionamiento de combineitor es el siguiente: 1. Tras generar el esqueleto, el usuario descomprime el contenido del paquete devuelto por Genereitor en una carpeta dentro de su directorio de trabajo. Este paquete contiene ya una copia de combineitor. 2. La etapa de generaci on de c odigo devuelve un paquete, correspondiente a todos los componentes generados para la entidad de la base de datos sobre la que se trabajar a. 3. El usuario copia este paquete, sin descomprimir, en el directorio donde reside el esqueleto de la aplicaci on. 4. Se accede por consola al directorio de trabajo donde reside el esqueleto y se otorga permiso de ejecuci on a combineitor1 :
1
$ chmod + x combineitor
1 La operaci on de otorgar permisos de ejecuci on s olo es necesario realizarla la primera vez que se ejecuta el script.
147
5. Tras esto, se ejecuta el script:

1
$ ./ combineitor
Una vez lanzado el script, aparece un mensaje de conrmaci on, que indica a qu e entidad de la base de datos corresponde el paquete que se pretende combinar, tal como se ve en la gura B.2.
Figura B.2: Mensaje de conrmaci on del paquete de c odigo de combineitor. Tras aceptar este mensaje, se muestra una lista de los trozos disponibles en el paquete de c odigo para combinar con sus correspondientes en el esqueleto, tal como muestar la gura B.3.
Figura B.3: Lista de selecci on de los cheros a combinar. Tras seleccionar el usuario los cheros convenientes (que por norma general ser an todos ellos, raz on por la que aparecen por defecto todos seleccionados), se procede a copiar todos los archivos del paquete de c odigo en su ubicaci on correspondiente dentro del esqueleto de la aplicaci on. 148
Los cheros compuestos por trozos ser an completados con el contenido de las partes del paquete de c odigo que correspondan. Por u ltimo, si se ha seleccionado combinar los scripts SQL o PL/SQL, se pregunta al usuario si ha habido env os de la aplicaci on (gura B.4 en la p agina siguiente). El motivo de esta pregunta es que en la aplicaci on original, para montar la base de datos en los servidores del cliente se proporcionan diversos scripts SQL, organizados seg un su contenido, y que hay que ejecutar en orden: 01 TABLAS.SQL 02 CLAVES AJENAS.SQL 03 INDICES.SQL 04 SECUENCIAS.SQL 05 VISTAS.SQL 06 TRIGGERS.SQL 07 CODIGO 00.SQL 07 CODIGO 01.SQL 08 JOBS.SQL 09 SINONIMOS.SQL 10 ROLES.SQL 11 GRANTS.SQL 12 DATOS.SQL Si el cliente todav a no ha recibido una versi on de la aplicaci on que se est a desarrollando, los trozos de los scripts se distribuir an en estos scripts iniciales. Sin embargo, si al cliente ya se le ha entregado una versi on de la aplicaci on, el inclu r las modicaciones en estos cheros implicar a que el cliente tendr a que eliminar su base de datos y volver a ejecutar todos los scripts por orden, con la consecuente p erdida de los datos que pudiera haber a nadido (o la necesidad de hacer un respaldo de la informaci on). Es por esto que las modicaciones en la base de datos se proporcionan, a partir del primer env o a cliente de la aplicaci on, en cheros parche, cuya ejecuci on modicar a el comportamiento de la base de datos conforme los objetivos requeridos. As , si en el di alogo de combineitor que pregunta por los env os de la aplicaci on, se generar a con el contenido de los trozos un chero XX FECHA DESCRIPCION.SQL, por ejemplo XX 20080810 ADICION TABLA CATALOGO.SQL. Tras haber realizado este u ltimo paso, la aplicaci on est a lista para desplegar en el servidor de aplicaciones2 .
2 Antes de desplegar la aplicaci on hay que ejecutar los scripts creados contra la base de datos, puesto que de otra manera no ser a posible que la l ogica de acceso de la aplicaci on consulte o modique los datos correspondientes a la nueva entidad.
149
Figura B.4: Di alogo de selecci on de aplicaci on enviada o no a cliente.
B.2.
Ejemplo de uso
Un ejemplo de uso, para mostrar el funcionamiento de la herramienta: el chero ejb-jar.xml generado con el esqueleto tiene esta apariencia:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
<! DOCTYPE ejb - jar PUBLIC " -// Sun Microsystems , Inc .// DTD Enterprise JavaBeans 2.0// EN " " http: // java . sun . com / dtd / ejb - jar_2_0 . dtd " > <ejb - jar > < enterprise - beans > < session > < description > Session Bean ( Stateless ) </ description > < display - name > Ta l le rF a ca de EJ B </ display - name > <ejb - name > T al le rF a ca de E JB </ ejb - name > < home > com . comex . taller . bl . ejb . T a l l e r F a c a d e E J B H o m e </ home > < remote > com . comex . taller . bl . ejb . Ta l le rF ac a de EJ B </ remote > <ejb - class > com . comex . taller . bl . ejb . T a l l e r F a c a d e E J B B e a n </ ejb - class > < session - type > Stateless </ session - type > < transaction - type > Bean </ transaction - type > <! -- # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # -- > <! -- g e n e r e i t o r : i n s e r t a r T r o z o 1 -- > <! -- # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # -- > </ session > <! -- # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # -- > <! -- g e n e r e i t o r : i n s e r t a r T r o z o 2 -- > <! -- # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # -- > </ enterprise - beans > < assembly - descriptor > <! -- # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # -- > <! -- g e n e r e i t o r : i n s e r t a r T r o z o 3 -- > <! -- # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # -- > </ assembly - descriptor > </ ejb - jar >
Se observan en las l neas 13, 17 y 22 las trazas que utilizar a combineitor para saber d onde insertar los trozos. Se etiquetan con el literal ((genereitor)) para indicar a los programadores que son trazas generadas autom aticamente, que no son comentarios de un desarrollador, y que por lo tanto no se pueden quitar. De lo contrario, combineitor no realizar a su tarea de forma correcta. El trozo de dicho chero para una entidad cat alogo contendr a lo siguiente:
150
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
<ejb - local - ref > <ejb - ref - name > ejb / local / CatalogoEJB </ ejb - ref - name > <ejb - ref - type > Session </ ejb - ref - type > < local - home > com . comex . taller . bl . ejb . C a t a l o g o E J B L o c a l H o m e </ local - home > < local > com . comex . taller . bl . ejb . C a t a l o g o E J B L o c al </ local > </ ejb - local - ref > <! -- g e n e r e i t o r : f i n T r o z o 1 -- > < session > < description > Session Bean ( Stateful ) </ description > < display - name > CatalogoEJB </ display - name > <ejb - name > CatalogoEJB </ ejb - name > < local - home > com . comex . taller . bl . ejb . C a t a l o g o E J B L o c a l H o m e </ local - home > < local > com . comex . taller . bl . ejb . C a t a l o g o E J B L o c al </ local > <ejb - class > com . comex . taller . bl . ejb . C a ta lo go E JB Be a n </ ejb - class > < session - type > Stateful </ session - type > < transaction - type > Bean </ transaction - type > </ session > <! -- g e n e r e i t o r : f i n T r o z o 2 -- > < container - transaction > < method > <ejb - name > CatalogoEJB </ ejb - name > < method - name >* </ method - name > </ method > < trans - attribute > Required </ trans - attribute > </ container - transaction >
En este chero, las marcas de corte est an en las l neas 8 y 21. El n del u ltimo trozo no es necesario indicarlo, puesto que corresponde con el n de chero. Una vez realizada la combinaci on, el resultado ser a el siguiente:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
<! DOCTYPE ejb - jar PUBLIC " -// Sun Microsystems , Inc .// DTD Enterprise JavaBeans 2.0// EN " " http: // java . sun . com / dtd / ejb - jar_2_0 . dtd " > <ejb - jar > < enterprise - beans > < session > < description > Session Bean ( Stateless ) </ description > < display - name > Ta l le rF a ca de EJ B </ display - name > <ejb - name > T al le rF a ca de E JB </ ejb - name > < home > com . comex . taller . bl . ejb . T a l l e r F a c a d e E J B H o m e </ home > < remote > com . comex . taller . bl . ejb . Ta l le rF ac a de EJ B </ remote > <ejb - class > com . comex . taller . bl . ejb . T a l l e r F a c a d e E J B B e a n </ ejb - class > < session - type > Stateless </ session - type > < transaction - type > Bean </ transaction - type > <! -- # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # -- > <ejb - local - ref > <ejb - ref - name > ejb / local / CatalogoEJB </ ejb - ref - name > <ejb - ref - type > Session </ ejb - ref - type > < local - home > com . comex . taller . bl . ejb . C a t a l o g o E J B L o c a l H o m e </ local home > < local > com . comex . taller . bl . ejb . C a t a l o g o E J B L o c a l </ local > </ ejb - local - ref > <! -- g e n e r e i t o r : i n s e r t a r T r o z o 1 -- > <! -- # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # -- > </ session > <! -- # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # -- > < session > < description > Session Bean ( Stateful ) </ description > < display - name > CatalogoEJB </ display - name > <ejb - name > CatalogoEJB </ ejb - name > < local - home > com . comex . taller . bl . ejb . C a t a l o g o E J B L o c a l H o m e </ local - home > < local > com . comex . taller . bl . ejb . C a t a l o g o E J B L o c a l </ local > <ejb - class > com . comex . taller . bl . ejb . Ca ta lo g oE JB Be a n </ ejb - class > < session - type > Stateful </ session - type > < transaction - type > Bean </ transaction - type >
151
33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
</ session > <! -- g e n e r e i t o r : i n s e r t a r T r o z o 2 -- > <! -- # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # -- > </ enterprise - beans > < assembly - descriptor > <! -- # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # -- > < container - transaction > < method > <ejb - name > CatalogoEJB </ ejb - name > < method - name >* </ method - name > </ method > < trans - attribute > Required </ trans - attribute > </ container - transaction > <! -- g e n e r e i t o r : i n s e r t a r T r o z o 3 -- > <! -- # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # -- > </ assembly - descriptor > </ ejb - jar >
Vemos que los trozos se han insertado correctamente en su sitio, quedando separadas por comentarios las partes generadas por el esqueleto y las generadas por el c odigo. Tambi en se mantienen las marcas de inserci on, de forma que el proceso de combinaci on se pueda repetir al a nadir otra entidad de la base de datos a la aplicaci on.
B.3.
Motivos de la elecci on de bash para su implementaci on
Como ya se ha comentado, esta herramienta auxiliar se concibi o en un principio como mera ayuda al desarrollo de las plantillas de Genereitor, por ello se eligi o un lenguaje sencillo, r apido y del que ya se tuviera experiencia previa. Cuando se tom o la decisi on de inclu rlo en Genereitor como herramienta complementaria, se plante o portar el c odigo a otro lenguaje m as eciente y que soportase multiplataforma, pero se desestim o la idea, puesto que la totalidad de los integrantes del grupo de desarrollo de aplicaciones J2EE trabajan bajo sistema operativo GNU/Linux, por lo que no era necesario contar con independencia de plataforma. As mismo, no es un u til imprescindible, ya se ha comentado que el proceso que realiza combineitor puede ser ejecutado por el programador en menos de cinco minutos.
152
Ap endice C
Tecnolog as utilizadas
C.1. JavaScript
JavaScript es un lenguaje de scripts (guiones) generalmente utilizado para el desarrollo de p aginas web, ofreciendo funcionalidades en el lado del cliente (client-side)1 , sin necesidad de establecer conexi on con el servidor. Es un lenguaje de programaci on interpretado2 y su sintaxis es similar a la de Java o C. Es un lenguaje orientado en objetos basado en prototipos, y dispone de herencia, disponible mediante clonaci on de objetos existentes, que hacen la funci on de prototipos. Debido a que JavaScript se ejecuta directamente en el navegador del usuario, en lugar de en un servidor remoto, responde instant aneamente a las acciones del usuario, mejorando la experiencia del usuario. Las caracter sticas principales de JavaScript son: Es un lenguaje basado en objetos (arrays asociativos3 . ampliados con prototipos). Soporta la sintaxis de programaci on estructurada de los lenguajes m as comunes (C, Java). Hace distinci on entre expresiones y declaraciones. Permite evaluar expresiones en tiempo de ejecuci on. Es decir, acepta el paso como par ametro de una cadena de caracteres, que interpretar a como una expresi on y, tras evaluarla, devolver a un resultado.
1 Aunque inicialmente JavaScript se utilizaba u nicamente para operaciones en el lado del cliente, aparecieron plataformas que soportan su uso en el lado del servidor (LiveWire JavaScript), mediante motores tales como Rhino, JScript o SpiderMonkey. Una gu a de referencia elaborada por Sun para el trabajo con JavaScript del lado del servidor se puede consultar en http://docs.sun.com/source/816-6408-10/contents.htm. 2 No requiere compilaci on. 3 Un array asociativo es un tipo de dato abstracto, compuesto por una colecci on de claves u nicas y una colecci on de valores, donde cada clave est a asociada con un valor. Las operaciones b asicas de un array asociativo son add (asignar una nueva clave a un nuevo valor), reasign (modicar el valor referenciado por una clave), remove (desvincular un valor a una clave) y lookup (encontrar el valor asociado a una clave).
153
APENDICE C. TECNOLOG IAS UTILIZADAS
Es un lenguaje d ebilmente tipicado, puesto que no es necesario declarar el tipo de datos en la asignaci on de variables, y la conversi on de un tipo a otro se realiza de forma autom atica. A esta caracter stica se le conoce como duck typing. El siguiente fragmento de c odigo es perfectamente v alido:
1 2 3 4 5 6 7 8 9 10 11
var variable1 = 2; variable1 =+ 3; // 2 + 3 , variable1 es de tipo num e rico alert ( variable1 ) ; // devolver a 5 variable1 = " Cadena de caracteres "; alert ( variable1 ) ; // devolver a " Cadena de caracteres " variable1 = true ; // variable1 es de tipo booleano if ( variable1 ) { alert (" Verdadero ") ; } else { alert (" Falso ") ; }
Las funciones son objetos, y como tales tienen propiedades y pueden interactuar con otros objetos. Usa prototipos en lugar de clases para denir las propiedades de los objetos. No distingue entre funciones y m etodos. Una funci on puede se llamada como m etodo. Soporta expresiones regulares. El principal inconveniente de JavaScript es que no es accesible. Es por esto que no es recomendable su uso en p aginas que requieran un nivel aceptable de accesibilidad, o en caso de que se decida usarlo, es necesario ofrecer una alternativa bajo el tag <noscript> en la p agina. Por ejemplo, si se ofrece un men u desplegable que funciona con JavaScript, se ofrecer a tambi en el men u desplegado u otra alternativa para los navegadores que no soporten JavaScript.
C.1.1.
Alternativas
Como ya se ha dicho, si la aplicaci on requiere de un nivel aceptable de accesibilidad es necesario proveer de alternativas al uso de JavaScript, puesto que en caso de utilizar navegadores antiguos o lectores de pantalla para personas con problemas de visi on, es probable que no sea posible ejecutar dichos guiones. Muchas de las funciones que se implementan en el lado cliente con JavaScript se pueden modelar en el servidor, mediante JSP, PHP, CGI y tecnolog as similares. El problema de delegar al servidor tareas que se pueden hacer en cliente es evidente: se requieren m as conexiones entre ambos lados para realizar la misma tarea, lo que repercutir a en el rendimiento nal de la aplicaci on.
C.2.
JSP
JavaSever Pages es una tecnolog a de Java que permite generar din amicamente documentos HTML, XML o de otros tipos, en respuesta a una petici on de 154
un cliente web. Permite el uso de c odigo Java y proporciona algunas acciones predenidas que pueden ser incrustadas en el contenido est atico. La sintaxis JSP a nade tags, al estilo de XML, llamadas acciones JSP y que son utilizadas para invocar a las funcionalidades provistas por el uso de JSP. Adem as, se ofrece la posibilidad de crear nuevos tags, extendiendo la librer a de los ya existentes (provistos por HTML o XML). Es un m etodo de ampliar las funciones de un servidor web manteniendo la independencia de plataforma. Los JSP son compilados para convertirse en Java Servlets en el momento en el que un cliente hace la primera petici on. Las sucesivas peticiones se ver an satisfechas con m as rapidez, ya que no ser a necesario volver a compilar el JSP.
C.2.1.
Alternativas
La alternativa m as inmediata al uso de JSP es ASP, de Microsoft. No obstante, JSP ofrece las siguientes ventajas con respecto a su rival: C.2.1.1. Plataforma e independencia del servidor
JSP sigue la losof a de Java de write once, run anywhere. Su caracter stica multiplataforma nos proporciona independencia sobre el sistema operativo que debe llevar el servidor que aloje el contenedor donde se almacenar an, compilar an y ejecutar an los JSP. Por el contrario, ASP est a limitada a arquitecturas basadas en tecnolog a de Microsoft. As , JSP se puede ejecutar en los sistemas operativos y servidores m as comunes, como son Apache, Netscape o Microsoft IIS, mientras que ASP s olo tiene soporte nativo para servidores Microsoft IIS y Personal WebServer, ambos de Microsoft. C.2.1.2. Proceso de desarrollo abierto
El API de JSP se benecia de la extendida comunidad Java existente, por el contrario el desarrollo de ASP depende u nicamente de Microsoft. C.2.1.3. Tags
Mientras que tanto JSP como ASP usan una combinaci on de tags y scripts para crear paginas web din amicas, la tecnolog a JSP permite a los desarrolladores crear nuevos tags. As los desarrolladores pueden crear sus tags de forma personalizada, y no depender de los scripts. Esto proporciona una alta reutilizaci on de c odigo. C.2.1.4. Java
La tecnolog a JSP usa Java para crear contenido de forma din amica, mientras que ASP usa VBScript o Jscript. Java es un lenguaje mas r apido, potente y 155
escalable que los lenguajes de script. As mismo, JSP puede utilizar JavaScript para tareas de lado del cliente. C.2.1.5. Mantenimiento
Las aplicaciones que usan JSP tiene un mantenimiento m as f acil que las que usan ASP. Los lenguajes de script est an bien para peque nas aplicaciones, pero no encajan bien para aplicaciones grandes. Java es un lenguaje estructurado y es m as f acil de construir y mantenimientos grandes como aplicaciones modulares. La tecnolog a JSP hace mayor enfasis en los componentes que en los scripts, esto hace que sea m as f acil revisar el contenido sin que afecte a la l ogica o revisar la l ogica sin cambiar el contenido. La arquitectura EJB encapsula la l ogica de acceso a BD, seguridad, integridad transaccional y aislamiento de la aplicaci on. Debido a que la tecnolog a JSP es abierta y multiplataforma, los servidores web, plataformas y otros componentes pueden ser f acilmente actualizados o cambiados sin que afecte a las aplicaciones basadas en la tecnolog a JSP.
C.2.2.
Inconvenientes
Uno de los inconvenientes con respecto a otras tecnolog as similares es que tiene una curva de aprendizaje m as pronunciada. Aprender a programar en JSP requiere m as esfuerzo, sobre todo si no se tiene experiencia anterior en lenguajes de programaci on, que ASP.
C.3.
Ant
Apache Ant es una herramienta utilizada para la realizaci on de tareas mec anicas y repetitivas, especialmente durante el proceso de compilaci on y construcci on de aplicaciones. Es similar a make, pero est a implementado usando Java, requiere la m aquina virtual de Java y se integra perfectamente con proyectos en dicho lenguaje. La principal diferencia con make es que utiliza XML para describir el proceso de construcci on y sus dependencias, mientras que make utiliza su propio formato Makele. Los scripts XML utilizados por ant llevan por nombre build.xml. Ant es software de c odigo abierto, y est a liberado bajo la Apache Software License.
156
C.3.1.
Ventajas
La principal ventaja de este sistema con respecto a sus predecesores es la portabilidad. Mientras que make recibe las acciones necesarias para realizar una acci on como ordenes del int erprete de comandos propio del sistema operativo sobre el que se ejecuta, ant resuelve esta situaci on proveyendo por el mismo gran cantidad de funciones, lo que garantiza que permanecer an id enticas en todos los sistemas operativos. Por ejemplo, en un Makele para Unix, la orden borrar recursivamente un directorio ser a:
1
rm - rf directorio /
La orden rm es propia del int erprete de Unix, si intentamos ejecutar make con esta orden en un entorno Windows, no funcionar a. Sin embargo, un script build.xml para ant que hiciera la misma funci on que el anterior ser a:
1 2 3 4 5 6
<? xml version = " 1.0 " ? > < project name = " borrar " default = " b o r r a r D i r ec t o r i o " basedir = " . " > < target name = " b o r r a r D i r e c t o r i o " / > < delete dir = " directorio " / > </ target > </ project >
Y este script funcionar a en cualquier sistema que contase con una m aquina virtual Java instalada, puesto que no depende de las ordenes del int erprete de comandos.
C.3.2.
Desventajas
Pese a las ventajas anteriormente nombradas, ant adolece de una serie de inconvenientes: Al ser una herramienta basada en XML, los scripts ant deben ser escritos en XML. Esto no s olo es una barrera para los nuevos usuarios, que tienen que aprender este lenguaje, sino tambi en un problema para los proyectos muy grandes, cuando los scripts comienzan a hacerse muy grandes y complejos. Esto es un problema com un a todos los lenguajes que utilizan XML, pero la granularidad de las tareas de ant signica que los problemas de escalabilidad no tardan en aparecer. La mayor a de las antiguas herramientas (<javac>, <exec>, <java>) tienen malas conguraciones por defecto y valores para las opciones que no son coherentes con las tareas m as recientes. Pero cambiar estos valores supone destruir la compatibilidad hacia atr as. Esto tambi en sucede al expandir propiedades en una cadena o un elemento de texto, las propiedades no denidas no son planteadas como error, sino que se dejan como una referencia sin expandir. 157
No es un lenguaje para un ujo de trabajo general, y no debe ser usado como tal. Tiene reglas de manejo de errores limitadas y no dispone de persistencia de estado, por lo que no puede ser usado con conanza para manejar una construcci on de varios d as.
C.3.3.
Alternativas: Maven
Una alternativa clara al uso de ant que superara muchas de las limitaciones de las que este adolece es el uso de maven. Maven aplica patrones a la estructura del proyecto, lo que deber a promover la productividad, facilitar la comprensi on de la estructura del proyecto y reducir el coste de trabajar con un nuevo proyecto, ya que la estructura ser a id entica. Normalmente cuando se comienza un nuevo proyecto en el que se va a usar ant, se copian los scripts de un proyecto ya existente y se modican para adaptarlos al nuevo4 . Maven soluciona esto mediante el uso de patrones que indican c omo ha de ser un proyecto Java y convenciones sobre la conguraci on. Maven, como herramienta de gesti on de proyectos, proporciona funciones de: Compilaci on. Documentaci on (e.g. Javadoc). Reporting sobre datos del proyecto. Gesti on de dependencias. SCM5 y releases. Distribuci on de la aplicaci on a servidores locales o remotos. Este sistema distingue entre diferentes ciclos de desarrollo. Hay 3 ciclos de desarrollo predenidos: default, clean y site. El primero (default ) gestiona el desarrollo del proyecto, el segundo (clean ) elimina los artefactos producidos por el primero y el tercero (site ) se encarga de la documentaci on y el sitio web del proyecto.
C.3.4.
Motivos de la elecci on de ant
Pese a que es evidente que existen alternativas mejores a ant, se ha decidido mantener esta herramienta por diversas razones. He aqu las m as importantes:
4 En realidad, este proceso de copiar-pegar-adaptar no se tiene por qu e llevar a cabo, ya que una de las caracter sticas de Genereitor es precisamente ofrecer estos scripts adaptados al proyecto que se est a generando, de forma autom atica y totalmente funcional desde el principio de la implementaci on del proyecto. 5 Control de versiones de forma transparente, sin importar si debajo se usa CVS, GIT, SVN o cualquier otro.
158
Requisitos del cliente. Como ya se ha comentado a lo largo de la memoria, Comex depende de los requisitos de Aragonesa de Servicios Telem aticos para la elaboraci on de los proyectos que este organismo le encarga, y al ser uno de los mayores clientes, se adoptan dichos requisitos para todas las aplicaciones J2EE desarrolladas. As , el uso de ant viene impuesto por AST, por lo que es m as c omodo realizar las tareas de gesti on de todos los proyectos con esta herramienta que introducir varias que, realizando la misma funci on, su funcionamiento sea diferente. Generaci on autom atica de scripts. Uno de los inconvenientes que se ha planteado respecto a ant es lo engorroso que es generar los scripts de compilaci on de forma correcta para aplicaciones de cierta envergadura. En este caso en particular este inconveniente no es tal, ya que Genereitor proporciona dichos scripts de forma autom atica. Integraci on con IDEs. Aunque es posible utilizar Maven con cualquier IDE, los m as usados (NetBeans, Eclipse y Oracle JDeveloper) proporcionan por defecto soporte para ant6 , por lo que la integraci on es instant anea.
C.4.
XSLT
Extensible Stylesheet Language Transformations, transformaciones de lenguaje extensible de hojas de estilo. Es un lenguaje basado en XML, cuyo cometido es la transformaci on de documentos XML en otros documentos (tanto XML como otros formatos), a partir de una serie de datos. XSLT es un est andar de W3C7 , y junto a XPath forman parte de XSL. Adem as de la transformaci on de documentos XML, XMLT ofrece tambi en otras funciones: A nadir y eliminar elementos a un arbol XML. A nadir y eliminar atributos a un arbol XML. Reorganizar y mostrar elementos. Mostrar u ocultar determinados elementos. Encontrar o seleccionar elementos espec cos. En el proceso de transformaci on intervienen dos archivos, el de datos, que contendr a todos los nodos de informaci on formateada en XML, y la plantilla XSLT, que ser a la base del documento resultante de la combinaci on de ambos. El proceso de combinaci on se ilustra en la gura C.1 en la p agina siguiente. Un ejemplo sencillo de chero de datos puede ser el siguiente:
6 De hecho, al generar un nuevo proyecto en NetBeans o importar uno ya existente, el propio entorno de programaci on proporciona autom aticamente un build.xml para compilar y desplegar dicho proyecto. 7 La especicaci on de XSLT se puede consultar en http://www.w3.org/XML/.
159
Figura C.1: Proceso de combinaci on de XSLT
1 2 3 4 5 6 7 8 9 10 11 12 13
<? xml version = " 1.0 " ? > < personas > < persona > < nombre > Dante </ nombre > < telefono > 666555444 </ telefono > < edad > 18 </ edad > </ persona > < persona > < nombre > Randal </ nombre > < telefono > 666777888 </ telefono > < edad > 22 </ edad > </ persona > </ personas >
Vemos que los datos se hallan agrupados en nodos, conformando una estructura de arbol. Y una plantilla muy b asica puede ser:
1 2 3 4 5 6 7 8 9 10
< xsl:styl esheet xmlns:xsl = " http: // www . w3 . org /1999/ XSL / Transform " version = " 1.0 "> < xsl:output method = " text " omit - xml - declaration = " yes " indent = " yes " / > < xsl:template match = " / " > Hay < xsl:value - of select = " count ( personas / persona ) " / > personas . < xsl:for - each select = " personas / persona " > Nombre: < xsl:value - of select = " nombre " / >. Edad: < xsl:value - of select = " edad " / >. </ xsl:for - each > </ xsl:template > </ xsl:st yleshee t >
Al combinar ambos cheros, obtendremos el siguiente resultado:
160
Hay 2 personas. Nombre: Dante. Edad: 18. Nombre: Randal. Edad: 22.
Como se puede comprobar, el formato de salida en este caso es texto simple, sin ning un formato. Esto destaca la capacidad de XSLT de crear casi cualquier tipo de archivos a partir de los datos recopilados en el chero de datos. En Genereitor se generan con XSL diversos tipos de cheros: clases Java, archivos XML, p aginas JSP, incluso cheros de conguraci on propios de Oracle JDeveloper. Pero sus posibilidades no se terminan ah . Es com un el uso de esta tecnolog a para elaborar a partir de plantillas y de datos introducidos en un formulario web documentos PDF.
C.4.1.
Ventajas
Con todo lo visto, se pueden destacar las siguientes ventajas de esta tecnolog a: No asume un u nico formato de salida de documentos. Permite manipular de muy diversas maneras un documento XML: reordenar elementos, ltrar, a nadir, borrar, etc. Permite acceder a todo el documento XML. XSLT es un lenguaje XML. Tambi en es importante el hecho de que existen diferentes procesadores XSLT, como son Saxon, Xalan, LotusXSL o Unicorn, por lo que podemos adecuar el proceso respecto a nuestros requisitos tanto de rendimiento como de licencias.
C.4.2.
Inconvenientes
As mismo, tambi en se han de mencionar diversos inconvenientes que plantea el uso de XSLT: Su utilizaci on es m as complicada que la de un lenguaje de programaci on convencional, y su sintaxis es algo inc omoda. Consume una cantidad sustancial de recursos, que depender an de la forma en que est e elaborada la plantilla XSLT, pero que para transformaciones de cierto vol umen de datos o plantillas con ujos complicados, puede ser elevada. 161
La potencia del lenguaje es limitada, su abanico de opciones para controlar el ujo se limita a bucles condicionales (if, for-each, etc), por lo que la realizaci on de plantillas complejas puede ser poco intuitiva. Adem as, al no permitir la declaraci on de funciones, no es posible la reutilizaci on del c odigo dentro de una misma plantilla. No obstante y pese a las carencias listadas, hay que tener en cuenta que XSLT es un lenguaje de tratamiento de datos, y no de prop osito general, por lo que no ha de utilizarse como tal.
C.4.3.
Alternativas
Hay varias alternativas que permitir an la generaci on de documentos a partir de plantillas. Una de ellas es DSSSL8 , el predecesor de XSLT, que ofrece caracter sticas similares para SGML9 (en lugar de XML). No obstante, este sistema, aunque es muy parecido a XSLT, est a siendo reemplazado por este u ltimo. Otras opciones ser an JavaScript Style Sheets (JSSS), Formatted Output Specication Instance (FOSI) o Sintactically Awesome StyleSheets (SASS), pero no son tecnolog as est andar. Por u ltimo, tambi en se puede utilizar para realizar transformaciones de plantillas la tecnolog a JSP, que proporcionar a la potencia del lenguaje Java y permitir a simplicar la elaboraci on de las plantillas m as complicadas. No obstante, se ha preferido utilizar XSLT por la eciencia en las plantillas sencillas, que ser an las m as comunes. Genereitor cuenta con m as de 150 plantillas, que si se tuvieran que implementar en archivos JSP supondr an una carga importante, tanto en tiempo de compilaci on como en ejecuci on.
C.5.
Javadoc
Javadoc es una utilidad de Sun Microsystems para la generaci on de documentaci on de APIs en formato HTML a partir de c odigo fuente Java. Los comentarios Javadoc est an destinados a describir, principalmente, clases y m etodos. Como est an pensados para que otro programador los lea y utilice la clase (o m etodo) correspondiente, se decidi o jar al menos parcialmente un formato com un, de forma que los comentarios escritos por un programador resultaran legibles por otro. Para ello los comentarios Javadoc deben incluir unos indicadores especiales, que comienzan siempre por @ y se suelen colocar al comienzo de l nea. Lo que hace esta herramienta es extraer los comentarios Javadoc contenidos en el programa Java indicado y construir con ellos cheros .html que puede servir como documentaci on de la clase.
8 Document Style Semantics and Specication Language, lenguaje de especicaci on y sem antica de estilo de documentos, especicado por el est andar ISO/IEC 10179:1996. 9 Standard Generalized Markup Language, lenguaje est andar de marcas generalizado (ISO 8879:1986).
162
Javadoc es el est andar de la industria para documentar clases de Java. La mayor a de los IDEs los generan autom aticamente.
C.5.1.
Alternativas
La principal alternativa a Javadoc es Doxygen, que utiliza un m etodo similar para generar la documentaci on, pero es compatible con diversos lenguajes, entre ellos C++, C, Java, Objective-C, Python, IDL, PHP, C# y D. Asimismo las interfaces generadas por Doxygen son m as agradables a la vista. Doxygen, al igual que Javadoc, es multiplataforma. El motivo de la elecci on de Javadoc es que es el est andar de Sun para generar documentaci on. Adem as, al estar mucho m as extendido, los IDEs m as comunes ofrecen soporte nativo para este formato de documentaci on, e incluso son capaces de crearla autom aticamente.
163
Bibliograf a
[1] The Java EE 5 Tutorial: http://java.sun.com/javaee/5/docs/tutorial/doc/index.html [2] Sun Enterprise BluePrints: Guidelines, Patterns, and code for end-to-end Java applications: http://java.sun.com/blueprints/enterprise/index.html [3] Nivel Doble-A de Conformidad con las Directrices de Accesibilidad para el Contenido Web 1.0 http://www.w3.org/WAI/WCAG1AA-Conformance [4] Sun Developer Network: J2EE & JavaServlet Pages Technology: http://java.sun.com/products/jsp/ [5] Sun Developer Network: Development with JSP and XML: http://java.sun.com/developer/technicalArticles/xml/ WebAppDev3/index.html [6] JavaServlet Scriptlets, Richard G. Baldwin: http://www.developer.com/tech/article.php/626401 [7] Ley de la Comunidad Aut onoma de Arag on 7/2001, de 31 de mayo, de creaci on de la Entidad P ublica Aragonesa de Servicios Telem aticos: http://www.lexureditorial.com/boe/0106/11883.htm [8] Java EE y Web 2.0: http://www.programania.net/diseno-web/JavaScript/ java-ee-y-web-20/ [9] Arquitectura J2EE: http://www.proactiva-calidad.com/java/arquitectura/index.html [10] Estr@tegia Magazine, A no 3, Edici on no 52, Secci on Tecnolog a: http://www.e-estrategia.com.ar [11] Interfaces gr acas en Java, Micael Gallego Carrillo y otros, ed. Ram on Aceres, 2005. [12] Adobe, Centro de desarrolladores: Introducci on a XSL: http://www.adobe.com/es/devnet/dreamweaver/articles/xsl_ overview.html
164
BIBLIOGRAF IA
[13] JSP. Custom Tags, etiquetas a medida: http://www.programacion.com/java/articulo/customtags/ [14] Filtros y Servlets en Java: www.samelan.com/oscargonzalez/doc/java_filters.pdf
165

Alonso

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Alonso

Cargado por

Copyright:

Formatos disponibles

Universitat de Lleida Escola Polit` ecnica Superior Ingenier a T ecnica en Inform atica de Sistemas Trabajo de nal de carrera

A todos vosotros... Gracias!

Estructura l ogica de Genereitor

8. Capa web 8.1. JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.1.1. Custom Tags . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.2. JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.3. CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2. Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.3. Otros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 9. Capa de l ogica de negocio 101

9.1. Excepciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 10.Capa de acceso a datos 103

11.Visi on global del trabajo realizado

A. Documento de an alisis y dise no

A.1. Descripci on y objetivos . . . . . . . . . . . . . . . . . . . . . . . . 116 A.2. Resumen ejecutivo . . . . . . . . . . . . . . . . . . . . . . . . . . 117

A.10.Migraci on inicial de datos . . . . . . . . . . . . . . . . . . . . . . 144 B. Combineitor, herramienta complementaria 145

C.1. JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 C.1.1. Alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . 153 C.2. JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

C.2.1. Alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . 154 C.2.2. Inconvenientes . . . . . . . . . . . . . . . . . . . . . . . . 155 C.3. Ant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

INICIAL CAP ITULO 1. SITUACION

INICIAL CAP ITULO 1. SITUACION

Ventajas perseguidas con el desarrollo de Genereitor

INICIAL CAP ITULO 1. SITUACION

INICIAL CAP ITULO 1. SITUACION

INICIAL CAP ITULO 1. SITUACION

Conexi on a bases de datos

INICIAL CAP ITULO 1. SITUACION

Integraci on de los m odulos de la empresa

Tratamiento de relaciones entre entidades

INICIAL CAP ITULO 1. SITUACION

Requisitos de las aplicaciones desarrolladas con Genereitor

INICIAL CAP ITULO 1. SITUACION

CAP ITULO 2. ANTIGUO GENERADOR

que aparecen al situar el cursor sobre una opci on determinada

CAP ITULO 2. ANTIGUO GENERADOR

Tratamiento de errores y excepciones

Soporte para librer as propias

CAP ITULO 2. ANTIGUO GENERADOR

Scripts de compilaci on y despliegue

Estructura de proyecto obsoleta

Integraci on con m odulos de la empresa

C.3 en la p agina 155 se detallan las caracter sticas de la herramienta ant.

CAP ITULO 2. ANTIGUO GENERADOR

Estructura l ogica de Genereitor

CAP ITULO 3. MODELO DE 3 CAPAS

Figura 3.1: Ejemplo de aplicaci on de 3 capas y 2 niveles

Figura 3.2: Estructura f sica de Genereitor.

Aplicaciones aut onomas

CAP ITULO 3. MODELO DE 3 CAPAS

Aplicaciones con conexi on a BD: 2 capas

CAP ITULO 3. MODELO DE 3 CAPAS

Figura 3.3: Esquema de la arquitectura monocapa con mainframe y terminales tontas

Figura 3.4: Esquema de la arquitectura de 2 capas

CAP ITULO 3. MODELO DE 3 CAPAS

CAP ITULO 3. MODELO DE 3 CAPAS

Funciones de cada capa

CAP ITULO 3. MODELO DE 3 CAPAS

Figura 3.5: Esquema de la arquitectura de 3 capas

Ventajas de la arquitectura de 3 capas

CAP ITULO 3. MODELO DE 3 CAPAS

CAP ITULO 4. ARQUITECTURA J2EE

Est andar y conable

especicaci on de J2EE se puede consultar en http://www.jcp.org/en/jsr/detail?id=

CAP ITULO 4. ARQUITECTURA J2EE

Figura 4.1: Diagrama de la arquitectura J2EE

CAP ITULO 4. ARQUITECTURA J2EE

Figura 4.2: Diagrama del MVC.

CAP ITULO 4. ARQUITECTURA J2EE

CAP ITULO 4. ARQUITECTURA J2EE

especicaci on de JSP se puede consultar en http://www.jcp.org/en/jsr/detail?id=