Genereitor 2: Generador de C Odigo J2EE

Universitat de Lleida Escola Polit`cnica Superior e Ingenier Tcnica en Informtica de Sistemas a e a Trabajo de nal de carrera
Genereitor 2
Generador de cdigo J2EE o
Autor: Hugo Alonso Capuz Director: Ramn Bjar Torres o e Septiembre de 2008
Agradecimientos
Durante la realizacin de este proyecto, muchas han sido las personas que, o de una forma u otra, me han aportado su ayuda, su apoyo y sus nimos. En a 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 Ral, porque sin su ayuda hubiera sido mucho ms duro. u a ...a Juan y Nacho, por conarme la realizacin de este proyecto y abrirme las o puertas del mundo laboral. ...a Ramn, por ofrecerse a ser mi tutor y darme consejo y opinin. o o ...a mis compaeros de la ocina, por alegrar las maanas de lunes y n n compartir caras de sueo. n
A todos vosotros... Gracias!
Indice general
I Introduccin o 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. Situacin inicial o 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. Aplicacin web . . . . . . . . . . . . . . . . . . . . . . . . o 1.4.2. Conexin a bases de datos . . . . . . . . . . . . . . . . . . o 1.4.3. Integracin de los mdulos de la empresa . . . . . . . . . o o 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 propias . . . . . . . . . . . . . . . . as 2.1.6. Accesibilidad . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.7. Scripts de compilacin y despliegue . . . . . . . . . . . . . o 2.1.8. Estructura de proyecto obsoleta . . . . . . . . . . . . . . . 2.1.9. Integracin con mdulos de la empresa . . . . . . . . . . . o o 2.1.10. Funcionalidades descartadas. . . . . . . . . . . . . . . . .
INDICE GENERAL
II
Estructura lgica de Genereitor o
25
26 27 27 28 31 31 32 34
3. Modelo de 3 capas 3.1. Arquitecturas antiguas . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1. Aplicaciones autnomas . . . . . . . . . . . . . . . . . . . o 3.1.2. Aplicaciones con conexin a BD: 2 capas . . . . . . . . . . o 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 J2EE? e . . . . . . . . . . . . . . . . . . . . . . . . . . .
34 35 35 35 35 35 36 37 39 39
4.1.1. Ahorro de trabajo . . . . . . . . . . . . . . . . . . . . . . 4.1.2. Documentacin . . . . . . . . . . . . . . . . . . . . . . . . o 4.1.3. Estndar y conable . . . . . . . . . . . . . . . . . . . . . a 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. Generacin de esqueleto o 5.1. Funciones de la interfaz . . . . . . . . . . . . . . . . . . . . . . . 5.1.1. Fase 1. Generacin de esqueleto . . . . . . . . . . . . . . . o 5.2. Resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1. Ficheros properties y descriptores de despliegue. . . . . . . 5.2.2. Scripts de compilacin . . . . . . . . . . . . . . . . . . . . o 5.2.3. Capa web - Servlets (Controlador) . . . . . . . . . . . . . 5.2.4. Capa web - JSP (Vista) . . . . . . . . . . . . . . . . . . . 5.2.5. Capa de lgica de negocio - Fachada de Componentes o (Modelo) . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.6. Capa de acceso a datos - Scripts SQL . . . . . . . . . . . 5.2.7. Documento de instalacin . . . . . . . . . . . . . . . . . . o 3
INDICE GENERAL
6. Generacin de partes de cdigo o o 6.1. Funciones de la interfaz . . . . . . . . . . . . . . . . . . . . . . . 6.1.1. Fase 1: Conexin . . . . . . . . . . . . . . . . . . . . . . . o 6.1.2. Fase 2: Seleccin de tabla . . . . . . . . . . . . . . . . . . o 6.1.3. Fase 3: Seleccin de tablas relacionadas . . . . . . . . . . o 6.1.4. Fase 4: Seleccin de campos . . . . . . . . . . . . . . . . . o 6.1.5. Fase 5: Seleccin de parmetros . . . . . . . . . . . . . . . o a 6.2. Resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1. Capa web - JSP (Vista) . . . . . . . . . . . . . . . . . . . 6.2.2. Capa web - Servlet (Controlador) . . . . . . . . . . . . . . 6.2.3. Capa de lgica de negocio - Fachada . . . . . . . . . . . . o 6.2.4. Capa de lgica de negocio - Componentes . . . . . . . . . o 6.2.5. Capa de lgica de negocio - Excepciones . . . . . . . . . . o 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. Generacin de script para tablas maestras o 7.1. Funciones de la interfaz . . . . . . . . . . . . . . . . . . . . . . . 7.1.1. Fase 1: Conexin . . . . . . . . . . . . . . . . . . . . . . . o 7.1.2. Fase 2: Seleccin de tablas . . . . . . . . . . . . . . . . . . o 7.1.3. Fase 3: Seleccin de campos . . . . . . . . . . . . . . . . . o 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
Implementacin de Genereitor o
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 lgica de negocio o 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
Conclusin o
106
107
11.Visin global del trabajo realizado o
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. Adicin de nuevas caracter o sticas a Genereitor . . . . . . . 112 12.1.2. Mantenimiento y modicacin de los proyectos generados. 113 o 12.1.3. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . 114
VI
Apndices e
115
116
A. Documento de anlisis y dise o a n
A.1. Descripcin y objetivos . . . . . . . . . . . . . . . . . . . . . . . . 116 o A.2. Resumen ejecutivo . . . . . . . . . . . . . . . . . . . . . . . . . . 117
INDICE GENERAL
A.2.1. Data Access Layer (Capa de Acceso a Datos) . . . . . . . 117 A.2.2. Business Logic (Lgica de Negocio) . . . . . . . . . . . . . 117 o A.2.3. Model-View-Controller (Modelo-Vista-Controlador) . . . 117 A.3. Sistema Actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 A.4. Identicacin y denicin de requisitos . . . . . . . . . . . . . . . 121 o o A.4.1. Ambito y alcance del proyecto . . . . . . . . . . . . . . . 121 A.5. Catlogo de requisitos del sistema a . . . . . . . . . . . . . . . . . 123
A.5.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . 123 A.5.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . 124 A.6. Modelo de procesos . . . . . . . . . . . . . . . . . . . . . . . . . . 124 A.6.1. Generacin del esqueleto . . . . . . . . . . . . . . . . . . . 124 o A.6.2. Generacin de script de tablas maestras . . . . . . . . . . 126 o A.6.3. Generacin de cdigo o o . . . . . . . . . . . . . . . . . . . . 127
A.7. Denicin de la arquitectura del sistema . . . . . . . . . . . . . . 131 o 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. Generacin . . . . . . . . . . . . . . . . . . . . . . . . . . 134 o A.9. Denicin del interfaz de usuario (prototipos) . . . . . . . . . . . 134 o A.9.1. Generacin del esqueleto . . . . . . . . . . . . . . . . . . . 135 o A.9.2. Generacin de script de tablas maestras . . . . . . . . . . 136 o A.9.3. Generacin de cdigo o o . . . . . . . . . . . . . . . . . . . . 139
A.10.Migracin inicial de datos . . . . . . . . . . . . . . . . . . . . . . 144 o B. Combineitor, herramienta complementaria 145
B.1. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 B.2. Ejemplo de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 B.3. Motivos de la eleccin de bash para su implementacin . . . . . . 151 o o C. Tecnolog utilizadas as 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 eleccin de ant . . . . . . . . . . . . . . . . 157 o 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. Mtodos que implementa Genereitor para dos entidades relacionadas 21 e 3.1. Ejemplo de aplicacin de 3 capas y 2 niveles . . . . . . . . . . . . o 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 aplicacin de ejemplo ((taller)). o 5.1. Arbol de directorios simplicado de una aplicacin web. . . . . . o 5.2. Ruta de los cheros .properties. . . . . . . . . . . . . . . . . . . . 5.3. Ruta de los scripts de compilacin. . . . . . . . . . . . . . . . . . o 5.4. Ruta de los servlets de un mdulo web. . . . . . . . . . . . . . . o 5.5. Ruta de la parte web (interfaz) de un mdulo web. . . . . . . . . o 5.6. Ruta del modelo de una aplicacin con EJB. . . . . . . . . . . . . o 5.7. Ruta de los scripts SQL. . . . . . . . . . . . . . . . . . . . . . . . 6.1. Esquema de las vistas con entidades relacionadas (amarillo) en la edicin de la principal (azul). . . . . . . . . . . . . . . . . . . . o 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 aadidas automticamente por sus relaciones. . . . . . . . n a 7.3. Estructura lgica de Genereitor . . . . . . . . . . . . . . . . . . . o 8.1. Diversas tecnolog utilizadas en la interfaz de Genereitor. . . . . as 8.2. Reconocimiento de las peticiones del usuario por el controlador. .
76 84 87 95
A.1. Pgina de conexin del generador actual . . . . . . . . . . . . . . 119 a o A.2. Pgina de seleccin de tabla del generador actual . . . . . . . . . 119 a o A.3. Error de conexin del generador actual . . . . . . . . . . . . . . . 119 o A.4. Pgina de seleccin de campos y parmetros del Generador actual 120 a o a A.5. Esquema de la arquitectura J2EE . . . . . . . . . . . . . . . . . . 122 A.6. Esquema de los procesos del Generador . . . . . . . . . . . . . . 125 A.7. Esquema de procesos de la generacin del esqueleto . . . . . . . . 126 o A.8. Esquema de procesos de la seleccin de tablas para la generacin o o del script de tablas maestras . . . . . . . . . . . . . . . . . . . . . 127 A.9. Esquema de procesos de la seleccin de campos y opciones para o la generacin del script de tablas maestras . . . . . . . . . . . . . 128 o A.10.Esquema de procesos de la seleccin de la tabla principal o . . . . 129
A.11.Esquema de tratamiento de tablas relacionadas . . . . . . . . . . 129 A.12.Esquema de procesos de la seleccin de parmetros . . . . . . . . 131 o a A.13.Esquema de la arquitectura de software . . . . . . . . . . . . . . 133 A.14.Esquema de la interfaz del generador . . . . . . . . . . . . . . . . 142 A.15.Recopilacin de los formularios de la interfaz del generador . . . 143 o B.1. Proceso de combinar un chero a trozos. . . . . . . . . . . . . . . 145 B.2. Mensaje de conrmacin del paquete de cdigo de combineitor. . 147 o o B.3. Lista de seleccin de los cheros a combinar. o . . . . . . . . . . . 147
B.4. Dilogo de seleccin de aplicacin enviada o no a cliente. . . . . . 149 a o o C.1. Proceso de combinacin de XSLT . . . . . . . . . . . . . . . . . . 159 o
Parte I
Introduccin o
10
Cap tulo 1
Situacin inicial o
1.1. Aplicaciones empresariales
Hoy en d cualquier empresa de cierta envergadura necesita manejar sus a datos de forma sencilla, rpida y ecaz. Hace aos, toda la informacin se almaa n o cenaba 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 tamao, la consulta, modicacin o insercin de datos cuestan n o o mucho tiempo y el mantenimiento es complicado, al ser un soporte f sico susceptible al desgaste o a la destruccin por accidentes (fuego, inundaciones, etc). o 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 econmico como de tiempo, al mrgen de la necesidad de disponer de espacio o a en otro lugar para albergar la copia. Tambin mantener y actualizar un archivo e de seguridad implica ms trabajo y ms tiempo. a a Con la aparicin de la informtica estos problemas comenzaron a desapao a recer. 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 los problemas de tamao. La an n cinta magntica se convirti en el soporte ideal para albergar copias de segurie o dad de bancos de datos de gran magnitud, ya que pese a su lentitud en el acceso a los datos (an as era innitamente ms rpido que las copias en papel), eran u a a un soporte econmico y ecaz. o Conforme la tecnolog avanzaba, la demanda de sistemas de almacenamiena to de mayor calidad y facilidad de uso increment enormemente, y en este marco o es donde surge el concepto de aplicacin empresarial. Una aplicacin empresao o rial es, a grandes rasgos, un sistema informtico que ayuda a incrementar o a controlar la productividad de una empresa. El principal objetivo de una aplicacin empresarial es incrementar los beo necios de una empresa mediante la reduccin de costes o la aceleracin del o o ciclo productivo, delegando a una mquina la realizacin de tareas que antes a o requer del trabajo de varios empleados. an
11
CAP ITULO 1. SITUACION INICIAL
1.2.
Aplicaciones web
La implementacin de una aplicacin empresarial se puede enfocar de divero o sas maneras, pero actualmente las aplicaciones web son la forma ms eciente a de llevar a cabo un proyecto de este tipo. Una denicin de aplicacin web podr ser un sistema a los que los usuarios o o a acceden a travs de un servidor web mediante Internet o una intranet1 , utilizane do para ello un navegador. La aplicacin est codicada en lenguajes soportados o a por los navegadores web (HTML, JavaScript, etc). Este tipo de aplicaciones son populares debido a lo prctico del uso del a navegador web como cliente ligero, puesto que prcticamente todos los sistemas a informticos cuentan en su conguracin por defecto con uno, lo que supone a o una gran ventaja a la hora de llevar a cabo actualizaciones o mantenimiento de la aplicacin, puesto que que estas tareas se llevan a cabo en el servidor. Esto o 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 actualizacin. o Es sencillo implementar nuevas funcionalidades (tales como procesadores de texto, clientes de correo o motores de bsqueda) e integrarlas en la u aplicacin. o No se necesita espacio en disco exclusivo para la aplicacin en la mquina o a del cliente, dado que no existe ningn proceso de instalacin. u o Proporciona una independencia de plataforma respecto del cliente, no importando el sistema operativo o el navegador que ste utilice2 . e Por contra, tambin adolecen de una serie de inconvenientes respecto de las e aplicaciones de escritorio: Dependen de una conexin con Internet o la intranet donde se aloja la o aplicacin, por lo tanto si esta conexin se ve interrumpida, la aplicacin o o o no es accesible.
1 Una intranet es un conjunto de contenidos compartidos por una organizacin, o un o grupo determinado de componentes de sta. Es una potente herramienta que permite divulgar e informacin de la compa a sus empleados con efectividad, estando stos informados de las o na e ultimas novedades y datos de la organizacin. o Su funcin principal es proveer lgica de negocios para aplicaciones de captura, informes o o y consultas con el n de facilitar la produccin de los grupos de trabajo. Tambin es un o e importante medio de difusin interna de la informacin propia de la compa o o na. 2 Aunque una aplicacin web proporciona independencia de plataforma, una implementao cin inconsistente de HTML, CSS, DOM u otras especicaciones del navegador puede interferir o en el funcionamiento de la aplicacin. Adems, las caracter o a sticas propias de los navegadores, tales como la posibilidad de modicar el tamao de fuente o deshabilitar la ejecucin de n o scripts, pueden afectar a su funcionamiento.
12
Las funciones de interfaz que puede ofrecer un navegador web son mucho ms limitadas que aquellas de las que se disponen en una aplicacin a o de escritorio. Por ejemplo, la caracter stica arrastrar y soltar, aunque es posible disponer de ella en una aplicacin web, es mucho ms dif de o a cil implementar que en una aplicacin de escritorio. o La amplia difusin de la que gozan las aplicaciones de escritorio en ciertos o campos (e.g. tareas de omtica) supone una traba para las aplicaciones a web de este tipo, ya que es complicado ofrecer compatibilidad con los contenidos creados inicialmente con aquellas. Una aplicacin web generalmente contiene elementos que permiten interaco tividad entre el usuario y la informacin, tales como el acceso a bases de datos o o la cumplimentacin de formularios. o
1.3.
Ventajas perseguidas con el desarrollo de Genereitor
Las soluciones de software empresarial ofrecidas por los fabricantes de forma ((genrica)) no siempre satisfacen las necesidades de las empresas, hecho que se e acrecenta en corporaciones de cierta magnitud. Es por sto que muchas veces e 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 informticas per, a sonalizadas 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 aplicacin personalizada frente a un paquete de fbrica o a son innumerables, dado que desde el principio del desarrollo del producto se tiene en cuenta la situacin espec o ca del cliente a quien va dirigida, en lugar de tener que usar un paquete prefabricado y aprovechar las caracter sticas que le sean utiles 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 de trabajo para adaptarse al software de a gestin. o Comex Grupo Ibrica es una empresa del sector de las TIC, y uno de sus e cometidos es el desarrollo de aplicaciones empresariales a medida. Desarrollar una aplicacin de este tipo requiere invertir mucho tiempo y esfuerzo, lo que en o 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 aplicacin a medio hacer y acorde o con las necesidades y caracter sticas del proyecto al que se enfrenta el equipo de desarrollo, la fase inicial de la implementacin es mucho ms directa. o a
13
Al disponer ya de versiones ((primitivas)) de todos los niveles de la aplicacin, desde interfaz web hasta mtodos de acceso a datos, el desarrollo o e comienza con la implementacin de las partes espec o cas de la aplicacin, o haciendo uso de la pericia y creatividad de los programadores para tareas espec cas de cada proyecto que dicilmente podr ser automatizables. an Optimizacin del cdigo. Delegando en Genereitor la implementacin de las o o o bases de un proyecto, se garantizan unos cimientos slidos, ya que el cdigo o o generado se basar en unas plantillas que han sido revisadas minuciosaa mente, y que conforme se vayan descubriendo fallos en las mismas, se implementen nuevas mejoras o se mejore su eciencia, stos se incorpoe rarn a todos los proyectos. Al trabajar siempre sobre bases similares, se a garantiza que el cdigo generado sea revisado indirectamente muchas ms o a veces que el que pueda implementar una persona, por lo que los fallos se detectarn mucho antes. a Homogeneidad dentro del proyecto. En la implementacin de proyectos o de cierta envergadura es normal que trabajen varias personas, que pueden tener diferentes costumbres a la hora de programar. Mientras uno describa los mtodos con nombres ms descriptivos, otro lo har con literales e a a ms concisos y abreviados. Esta situacin se convierte en un problema a a o la hora de realizar el mantenimiento o la resolucin de incidencias de un o proyecto, puesto que se entremezclan los diferentes criterios de los distintos programadores que han implementado las diferentes partes de la aplicacin, teniendo que consultar cmo se ha llamado a cada mtodo o, o o e en el peor de los casos, modicar los nombres de estos mtodos con las e consecuencias que sto puede acarrear, como que otras partes del proyecto e dejen de funcionar correctamente. Genereitor proporciona un unico criterio para el nombrado de variables, constantes, mtodos, identicadores de campos en los formularios web, e etc., de forma que el mantenimiento o la implementacin de funciones o nuevas es ms cmodo, puesto que el programador siempre va a conocer a o cmo se han nombrado los mtodos o los campos del formulario que tiene o e que utilizar, sin necesidad de consultarlo en la documentacin o en la o especicacin de la clase. o 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 lgico como de directorios, lo que permite agilizar o el trabajo al programador que haya adquirido un m nimo de costumbre, puesto que no tendr que buscar por el rbol de directorios dnde est ciera a o a to componente o parmetro de conguracin: siempre estarn en el mismo a o a lugar. Ms adelante se detallar esta estructura de directorios. a a Documentacin. En el mbito empresarial, el desarrollo de las aplicaciones o a siempre se ve obstaculizado por las prisas. Perder ms tiempo de la cuenta a en el desarrollo de un proyecto signica disminuir el mrgen de benecios, a y a consecuencia de sto los plazos suelen ser muy ajustados. e Por esta razn, nunca suele haber una buena documentacin para cada o o aplicacin que se implementa, puesto que siempre hay cosas ms urgentes o a en las que emplear el tiempo. 14
As Genereitor ofrece en el cdigo generado comentarios explicativos de las , o partes menos claras, as como notas en formato Javadoc para la generacin o automtica de documentacin, que podr ser consultada tanto v web (de a o a a forma similar a la consulta de las APIs de J2EE en la pgina de Sun) como a 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 automtica una explicacin a o aclarativa del funcionamiento y la nalidad de cada mtodo implementado, e pero s se ofrecen las bases de esta documentacin, de manera que el o programador pueda rellenar en el cdigo de forma breve las funciones o que crea convenientes, obteniendo en poco tiempo y sobre la marcha una documentacin completa que ayude a quien en un futuro haya de realizar o un mantenimiento de la aplicacin. o Un ejemplo de la documentacin ofrecida podr ser el siguiente: o a
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 documentacin necesaria. o La nalidad de Genereitor consiste, a grandes rasgos, en proporcionar al desarrollador la estructura de la aplicacin totalmente personalizada conforme o a los requisitos del proyecto (nombre de la aplicacin y los paquetes y clases o que la componen, adaptacin conforme al servidor de aplicaciones utilizado y o sistema de bases de datos sobre el que operar), ya preparada para comenzar el a desarrollo, evitando as la tarea de crear dicha estructura a mano. As mismo, se proveern scripts de compilacin para la herramienta ant cona o forme a los diferentes componentes, dependencias y librer del proyecto. Se as proporcionarn dos tipos de scripts: a Scripts para desarrollo. Scripts para preproduccin y produccin, orientados a la compilacin y o o o despliegue en los servidores del cliente. Tambin se proporcionan, para cada entidad de la base de datos, paquetes e que contendrn el cdigo fuente correspondiente a todas las capas de la aplia o cacin (tanto capa de presentacin como lgica de negocio), que podrn ser o o o a insertadas en la aplicacin como si de mdulos se tratase, de manera que se o o puedan aadir a la aplicacin las funciones correspondientes a cada entidad de n o forma progresiva conforme avance la implementacin. o La conjuncin de la estructura bsica generada al principio con los mdulos o a o creados a posteriori darn como resultado una aplicacin web completa que, a o 15
aunque de forma bsica y primitiva, ser totalmente funcional, incluyendo una a a rudimentaria interfaz web y funciones de lectura, insercin, modicacin y boo o rrado de todo tipo de entidades existentes en la base de datos. As el programador obtiene una aplicacin que ya funciona sin tocar una sola , o l nea de cdigo, sobre la que comenzar a trabajar. Evidentemente esto supone o un ahorro de tiempo enorme comparado con lo que costar empezar el proyecto a desde cero, teniendo que implementar todo a mano.
1.4.
Requisitos de Genereitor
Genereitor es una herramienta de generacin de aplicaciones web automtica, o a que mediante la conexin a una base de datos previamente implementada y los o requisitos de la aplicacin a generar es capaz de devolver al programador dicha o aplicacin en una fase muy temprana del desarrollo, aunque completamente o funcional. As los requisitos bsicos son los que se listan a continuacin: , a o
1.4.1.
Aplicacin web o
Genereitor se implementar como una aplicacin web, cuyo acceso se efecte a o u mediante un navegador web estndar. Aunque no es indispensable, se ha decia dido implementar mediante la tecnolog J2EE por diversos motivos: a Es la tecnolog que se utilizar obligatoriamente para las aplicaciones gea a neradas con Genereitor, por lo que servir de toma de contacto, aprendizaje a y experiencia para el posterior desarrollo de las plantillas que generarn a dichas aplicaciones. Es una tecnolog madura y ampliamente extendida en el campo de las a aplicaciones web, ofrece una estructura slida y modular y dispone de mulo titud de APIs y componentes a disposicin del programador, de forma que o ahorra mucho trabajo al no tener que implementar dichos componentes, puesto que estn integrados en el servidor de aplicaciones. a Su aprendizaje no es excesivamente dif cil, por lo que se preere a otras tecnolog ms complicadas. as a Es una tecnolog libre y puede ser desarrollada con herramientas coma pletamente gratu tas, lo que supone una ventaja a la hora de incorporar Genereitor a produccin, ya que se evitan gastos de licencias de uso que se o producen al utilizar otras tecnolog tales como .Net. as
1.4.2.
Conexin a bases de datos o
La herramienta ha de ser capaz de generar aplicaciones adaptadas a diversos sistemas de bases de datos, que variarn de un proyecto a otro. Es por esto que a debe ser capaz de manejar ecientemente y generar las capas de acceso a datos para la base de datos contra la que se apoyar la aplicacin a generar. a o 16
Inicialmente, los sistemas de bases de datos soportados son: Oracle 9 PostgreSQL MySQL Microsoft SQLServer HSQLDB
1.4.3.
Integracin de los mdulos de la empresa o o
En la empresa se utilizan diversos mdulos que han sido desarrollados a lo o largo del tiempo y que ofrecen funcionalidades espec cas a los proyectos, tales como com.comex.cms, que proporciona un sistema de gestin de contenidos, o com.comex.xml que maneja el env y recepcin de mensajes mediante XML o o o com.comex.usuarios, que da soporte para la gestin de usuarios, perles y grupos o a una aplicacin web. o Genereitor ser capaz de integrar, bajo demanda del programador, estos a mdulos a la aplicacin a generar, personalizando su comportamiento y modio o cando los cheros de conguracin para compilar automticamente los cheros o a fuente de dichos mdulos. o
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 generacin de aplicaciones, de forma que o dichas aplicaciones ya incorporen en su lgica el tratamiento de las claves ajenas. o
1.4.5.
Interfaz intuitiva
Genereitor contar con una interfaz clara e intuitiva, con literales que identia quen claramente la funcin de cada uno de los componentes que forman parte o de sta. Cuando, por cuestiones de espacio, sea dif ofrecer literales demasiado e cil espec cos, se proveern de explicaciones mediante etiquetas otantes al pasar a el puntero del ratn sobre dicho literal. o Asimismo, el manejo de errores ser capaz de informar al usuario de cundo a a ha ocurrido algn fallo en la ejecucin del programa o la introduccin de datos, u o o indicando la causa del mismo.
17
1.5.
Requisitos de las aplicaciones desarrolladas con Genereitor
Las aplicaciones desarrolladas con Genereitor sern aplicaciones web implea mentadas en J2EE[1], cuya estructura seguir las recomendaciones de las Java a BluePrints[2]. Permitirn tanto la consulta como la modicacin de los datos almacenados a o en una base de datos, que podr estar soportada por diferentes servidores de a bases de datos. Segn las necesidades del proyecto, la capa de aplicacin podr estar imu o a plementada mediante EJBs o POJOs, y en consecuencia sern desplegables en a diversos servidores de aplicaciones, con o sin contenedor de EJB. Las interfaces generadas sern accesibles a nivel AA[3], aunque se ofrecern a a soluciones ms ecientes cuando este nivel de accesibilidad no sea necesario. a Sern compatibles con los mdulos desarrollados en la empresa (com.comex.common, a o 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 correspondern a las distintas etapas de desarrollo de la aplicacin. Los a o scripts de despliegue proporcionados aceptarn parmetros que modicarn el a a a despliegue segn se encuentre el proyecto en desarrollo, preproduccin o producu o cin. o El tratamiento de archivos binarios se llevar a cabo mediante streaming, a tanto para la carga como la descarga de grandes binarios al servidor de bases de datos, lo que evitar la saturacin del servidor de aplicaciones por falta de a o memoria, a la vez que facilita el manejo de archivos multimedia en caso de que se quiera aadir un reproductor de medios. n Seguirn los siguientes patrones de desarrollo: a Modelo-Vista-Controlador. Modelo-Vista-Controlador (Model-View-Controller) es un patrn de desarrollo que separa la parte lgica de una aplicacin de o o o su presentacin. Bsicamente sirve para separar el lenguaje de programao a cin del HTML lo mximo posible y para poder reutilizar componentes o a fcilmente. a El Modelo representa las estructuras de datos. T picamente el modelo de clases contendr funciones para consultar, insertar y actualizar informaa cin de la base de datos. o La Vista es la informacin presentada al usuario. Una vista puede ser una o pgina web o una parte de una pgina. a a El Controlador acta como intermediario entre el Modelo, la Vista y cualu quier otro recurso necesario para generar una pgina. a Filtro. El patrn ltro consiste en el uso de objetos con atributos incompletos o que no sern vlidos para el tratamiento de datos, pero que se utilizan a a para la recogida de datos en formularios y en las operaciones de lgica de o 18
la interfaz, que mediante la consulta al modelo de datos completarn los a atributos del ltro para crear un objeto vlido. a Facade. La fachada se usa para proporcionar una interfaz para la capa de lgica o de negocio, de forma que los dems componentes de la aplicacin accedan a o a dicha capa a travs de la fachada, en lugar de hacerlo directamente. Para e ello, se implementa un bean de fachada, que representa los componentes de la lgica de alto nivel, que a su vez interactuarn con los componentes o a de bajo nivel. El uso de fachada repercute en una mayor facilidad de uso y legibilidad de la capa de lgica de la aplicacin, al tiempo que exibiliza el desarrollo. o o Singleton. Este patrn restringe la creacin de objetos pertenecientes a una o o clase o el valor de un tipo a un unico objeto. Su intencin consiste en garantizar que una clase slo tenga una instancia o o y proporcionar un punto de acceso global a ella. El patrn singleton se implementa creando en nuestra clase un mtodo o e que crea una instancia del objeto slo si todav no existe alguna. Para o a 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 patrn ServiceLocator permite proveer a la aplicacin de un cono o trolador centralizado que permite manejar todos estos servicios desde un mismo componente, evitando el tener que buscar a lo largo de toda la aplicacin los servicios necesarios en cada momento. o
19
Cap tulo 2
Antiguo generador
Antes del desarrollo de Genereitor ya exist una herramienta de caracter a sticas similares, pero sus funciones era muy limitadas. En lugar de generarse un proyecto completo y funcional, se creaban unicamente los cimientos de varios cheros de cdigo, que luego habr de ser completados y adaptados por el o an programador. La antigedad de esta herramienta y la dicultad de su mantenimiento prou pici que cayera progresivamente en desuso, puesto que el ahorro de tiempo o que supon al principio fue mermando con el paso del tiempo, al evolucionar a las caracter sticas y los requisitos de los proyectos demandados por los clientes. La falta de mantenimiento regular se tradujo en que, actualmente, cuesta ms a arreglar y adaptar el cdigo generado que implementarlo desde cero o reciclar o un proyecto existente y adaptarlo a mano. Adems, las escasas funciones que a an son aprovechables no compensan con el esfuerzo invertido en la adaptacin u o a los nuevos mtodos de trabajo. e A continuacin se detallan los problemas ms importantes de los que adolece o a 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 aplicacin que explote una base de datos, siempre teniendo en cuenta o las restricciones de sta, de forma que se mantenga la consistencia de la infore macin almacenada. o
20
CAP ITULO 2. ANTIGUO GENERADOR
El antiguo generador slo ten en cuenta las caracter o a sticas propias de cada entidad, es decir, slo proporcionaba la lgica para el tratamiento de los campos o o propios de cada tabla, de manera que las relaciones con otras tablas hab que a hacerlas a mano, tarea que conlleva tiempo y esfuerzo. Otro inconveniente es que, al tenerlas que hacer una por una, el cdigo implementado por el programador o es susceptible de fallos que hagan que la aplicacin no funcione correctamente o en determinadas ocasiones que, por extraas o inusuales, no se hayan tenido en n cuenta inicialmente por el programador, o que en el peor de los casos, pongan en peligro la integridad de la base de datos si sta no est perfectamente diseada. e a n Por esto, Genereitor tiene en cuenta automticamente las relaciones entre a tablas, ofreciendo la lgica para el tratamiento de las mismas, de la forma que o indica la gura 2.1.
Figura 2.1: Mtodos que implementa Genereitor para dos entidades relacionadas e
2.1.2.
Interfaz
En el desarrollo del antiguo generador de cdigo se descuid demasiado el aso o pecto 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 ms claros y concisos posible, y mostrando mediante tooltips 1 que a clariquen la funcin que ofrecen las opciones que no resulten triviales en la o presentacin. o
1 Letreros
que aparecen al situar el cursor sobre una opcin determinada o
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 algn problema, no se u informa al usuario de qu es lo que falla o cual puede ser la causa del problema. e Este fallo se aprecia acusadamente en caso de errores de conexin a la base de o datos, donde simplemente se vuelca en pantalla el contenido de la excepcin o generada, que generalmente suele ser poco aclarativa. En Genereitor se ha implementa un sistema de noticacin de errores, meo diante 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 fcilmente identicable. a
2.1.4.
Restricciones
En el diseo de la base de datos siempre se tienen en cuenta diversas resn tricciones que deben cumplir las entidades que se van a almacenar, tales como campos obligatorios, longitud de cadenas de caracteres o rango mximo de cama pos numricos. Pero es posible que interese ampliar estas restricciones o aadir e n nuevas en ciertos casos, sin modicar la base de datos, sino a nivel de aplicacin. o El generador antiguo no era capaz de aplicar restricciones al manejo de la base de datos2 , tarea que de ser necesaria, ten que ser implementada a mano. a Se ha decidido automatizar la adicin de estas restricciones, de manera que se o puedan modicar longitud mxima de campos en los formularios de la aplicacin a o a generar, as como aadir la obligatoriedad de contener valores no nulos a n cualquier campo, aunque el diseo de la base de datos s lo permita. n
2.1.5.
Soporte para librer propias as
En la empresa se han desarrollado a lo largo del tiempo una serie de librer as y mdulos de uso comn, que proporcionan funciones y herramientas utilizadas o u por la mayor de los proyectos que se desarrollan, tales como gestin de taa o blas maestras, gestin de usuarios, perles y grupos, gestin de contenidos, etc. o o ms adelante se explicarn en detalle las funciones de estos mdulos. Evidena a o temente es necesario adaptar el cdigo para el uso de estas librer tarea que o as, actualmente se hace a mano. En el nuevo generador se permitir elegir en la fase de creacin de la esa o tructura del proyecto qu mdulos van a ser necesarios para la aplicacin, de e o o manera que quede disponible todo el abanico de opciones que ofrece cada una de ellos. Tambin se modicarn los scripts de compilacin y despliegue para e a o compilar automticamente estos mdulos a la vez que el proyecto a desarrollar. a o
restricciones que se pueden aplicar sern siempre a nivel de la aplicacin a generar, a o nunca se modicarn las de la propia base de datos desde un generador automtico. a a
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 vetado. a Por esto, Genereitor ofrecer alternativas accesibles en forma de comentarios en a el cdigo generado, dejando tambin las funciones JavaScript para que el proo e gramador elija la que ms convenga segn los requisitos del cliente. a u
2.1.7.
Scripts de compilacin y despliegue o
Una de las tareas ms tediosas a la hora de comenzar la implementacin a o de una aplicacin es confeccionar los scripts de compilacin. puesto que son de o o elaboracin muy delicada. o 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 ofrecern automticamente a a estos scripts, personalizados de acuerdo a las caracter sticas del proyecto, mduo los y librer utilizados y aplicaciones web que contiene. as
2.1.8.
Estructura de proyecto obsoleta
La funcin de generacin de estructura de proyecto (esqueleto) del generador o o antiguo devuelve un paquete cuya organizacin no se corresponde con los reo quisitos actuales de desarrollo de aplicaciones J2EE, por lo que el programador ha de reorganizar los cheros y directorios a mano para adaptarlos al esquema vlido. Dicho esquema vlido es el aconsejado en las Java BluePrints[2]. a a
2.1.9.
Integracin con mdulos de la empresa o o
En la empresa se han desarrollado a lo largo del tiempo una serie de mduo los que ofrecen diversas funcionalidades a las aplicaciones desarrolladas, tales como la gestin de tablas maestras, gestin de contenidos, soporte para usuao o rios, grupos y perles, etc. El generador antiguo no ofrece soporte para estos mdulos, pero Genereitor contemplar su integracin opcional en las aplicaciones o a o desarrolladas con l, y en caso de seleccionarse se crearn los cheros espec e a cos de dichos mdulos, de manera que las aplicaciones puedan disponer de dichas o funcionalidades.
2.1.10.
Funcionalidades descartadas.
Con el paso del tiempo, hay tecnolog que quedan obsoletas y son sustias tu das por otras ms ecientes, o simplemente se decide en un momento dado a apostar por alternativas que proporcionen ms ventajas respecto a las actuales. a
3 En
C.3 en la pgina 155 se detallan las caracter a 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 descartada. Tambin utiliza plantillas JSP para generar a e los diversos cheros de cdigo fuente, mientras que Genereitor utilizar plantillas o a XSL4 .
4 En C.4 en la pgina 158 se detallan las caracter a sticas de XML/XSLT y las ventajas que tiene frente a otros sistemas.
24
Parte II
Estructura lgica de o Genereitor
25
Cap tulo 3
Modelo de 3 capas
Antes de comenzar a analizar las diferentes arquitecturas disponibles, conviene realizar una pequea aclaracin. n o No se deben confundir los trminos capa y nivel: e Las capas hacen referencia a la estructura lgica de la aplicacin, que o o repercutir, entre otras cosas, en su modularidad y escalabilidad. a Los niveles por contra, sealan la estructura f n sica sobre la que se despliega la aplicacin, es decir, en cuantas mquinas corre. o a Dependiendo de la envergadura del proyecto, podemos encontrarnos aplicaciones pequeas que estn implementadas con 3 capas, pero slo 2 niveles, por n e o ejemplo en la gura 3.1 en la pgina siguiente se muestra la distribucin f a o sica de una aplicacin de 3 capas, cuyas capas de acceso a datos y lgica de negocio o o corren bajo la misma mquina. a Tambin se puede dar el caso en que una misma mquina soporte la capa de e a lgica de negocio y la capa cliente, o que todas las capas se alojen en el mismo o servidor. Por otro lado, no es raro que, en aplicaciones de gran envergadura, los servidores de bases de datos se implementen en clsteres, es decir, varias mquinas u a que, por computacin distribu o da, ofrecen la misma funcin y se reparten la o carga de trabajo y la capacidad de almacenamiento. En caso de Genereitor, se trata de una aplicacin de 3 capas y 3 niveles, o ya que tanto la lgica de negocio como el cliente se encontrarn en mquinas o a a separadas. El caso ((especial)) de Genereitor es que no trabajar sobre una base a de datos en particular, sino que est diseado para utilizar diversos sistemas de a n bases de datos, que usualmente se alojarn en servidores diferentes, por lo que a incluso se podr considerar como una aplicacin de 4, 5 o incluso ms niveles. a o a En la gura 3.2 en la pgina siguiente se ilustra este ejemplo. a
26
CAP ITULO 3. MODELO DE 3 CAPAS
Figura 3.1: Ejemplo de aplicacin de 3 capas y 2 niveles o
Figura 3.2: Estructura f sica de Genereitor.
3.1.
Arquitecturas antiguas
Antes de analizar el modelo de arquitectura utilizado para la implementacin de Genereitor se dar un vistazo a las caracter o a sticas de las arquitecturas predecesoras, comentando sus ventajas e inconvenientes.
3.1.1.
Aplicaciones autnomas o
Una aplicacin autnoma es aquella cuya arquitectura est compuesta por o o a una sola capa, que aglutina la interfaz de usuario, la lgica de tratamiento o
27
de datos y el almacenamiento de stos. Las caracter e sticas de este modelo de aplicaciones son las siguientes: Su ejecucin no depende de otras aplicaciones, aunque puede existir inteo gracin entre varias aplicaciones. o Se encuentra almacenada en el disco duro del usuario. Su interfaz grca est formada por ventanas de aplicacin. a a o Cuando el usuario cierra la ventana, la aplicacin naliza su ejecucin. o o No tienen restricciones de seguridad, pudiendo la aplicacin acceder al o disco duro del usuario y establecer conexiones de red. Este diseo arcaico conlleva gran cantidad de inconvenientes: n En cada sistema operativo se ejecuta de forma diferente, por lo que no hay compatibilidad multiplataforma. Problemas de integracin en sistemas software complejos, tales como los o sistemas de gestin de una empresa. o Problemas de integracin en sistemas de informacin consistentes en varias o o aplicaciones. Problemas de escalabilidad, tanto a nivel de almacenamiento como de adicin de nuevas funciones. o Otro planteamiento de esta estructura monocapa es aquel consistente en un mainframe, un gran ordenador central que soporta todo el peso de la aplicacin, o y una serie de terminales tontos, mquinas que no realizan ningn proceso y que a u simplemente tienen la tarea de servir de presentacin de la interfaz al usuario. o Este planteamiento se representa en la gura 3.3 en la pgina siguiente. a An as tanto la lgica de la aplicacin, el acceso a datos y la presetacin de u , o o o la informacin estaba completamente implementada en un slo bloque monol o o tico de software. Cualquier modicacin sobre la aplicacin requer modicar la o o a totalidad de este unico 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 ms a archivos reconocibles por el sistema operativo. En esta arquitectura, el programa que permite el acceso y administracin de la base de datos debe estar muy o estrechamente unido a la aplicacin cliente. o
3.1.2.
Aplicaciones con conexin a BD: 2 capas o
Un avance ms a la arquitectura anterior consiste en dividir los sistemas a 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 estn compuestas por dos capas1 , tal como se muestra en a la gura 3.4: Front-end: es la capa donde el usuario interacta con su mquina y que, geu a neralmente, aglutina toda la lgica de negocio. o Back-end: es la capa de acceso a datos, cuya funcin la realiza un servidor de o 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 interacta con el cliente. En estos casos, varias u estaciones de trabajo clientes necesitarn ser actualizadas con una nueva versin a o de la aplicacin del cliente simultneamente al cambio en la base de datos. Esta o a
1 Es importante no confundir esta arquitectura con la del mainframe monocapa. En la arquitectura de 2 capas, la lgica de la aplicacin reside en la capa cliente (front-end), que se o o ejecuta en cada mquina cliente. En la estructura anteriormente mencionada, las estaciones a de trabajo son unicamente dispositivos de entrada (teclado, ratn) y salida (pantalla) de o informacin, no realizando stos ninguna tarea relacionada con la aplicacin, ms que la de o e o a meros interfaces.
29
generalmente no es una tarea sencilla, sobre todo si las aplicaciones cliente estn a geogrcamente dispersas. a Otro problema es la dicultad de compartir procesos comunes. Tras largas horas de trabajo frente a la mquina para lograr un proceso en particular, este a cdigo es dif o cilmente reutilizable en otras aplicaciones. Un problema ms es la seguridad. Esta puede ser establecida en cualquera de a las dos capas, pero cada una tiene sus limitaciones. La primera solucin consiste o 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 slo asegurar qu datos o e pueden ser actualizados o accedidos, sino de qu manera. En cuanto al segundo e punto, que es el ms usado, aunque el usuario puede acceder a la base de datos a con su identicacin, tiene dos problemas: o Dado que ninguno de los objetos en la base de datos es seguro, cualquier usuario puede tener acceso total a la misma con alguna aplicacin de o front-end. La implantacin de la seguridad deber ser desarrollada, probada y mano a tenida en absolutamente toda la red, sin importar dnde se encuentren las o estaciones cliente. Otros inconvenientes son: Los servidores de bases de datos no proporcionan un lenguaje de programacin completo 2 , con control de ujo, y los procedimientos almacenados3 , o aunque ayudan, no son la solucin. o Los datos no estn encapsulados, por lo que sigue siendo necesario que el a programador de las aplicaciones de los clientes realice tareas de control de integridad de los datos. No resulta fcil realizar cambios en la estructura de una base de datos de a la que dependen varias aplicaciones. A medida que el negocio crece y el nmero de usuarios simultneos del u a sistema aumenta, se complican las opciones de escalabilidad del sistema. Aplicaciones de 2 capas funcionan perfectamente en entornos pequeos, n pero no son capaces de acompaar un gran crecimiento del negocio. n Las actualizaciones de la aplicacin cliente se han de distribuir entre todos o los usuarios, que debern realizar una instalacin de la nueva versin del a o o producto en sus mquinas. En sistemas con muchos usuarios, esta tarea a ser costosa a nivel tanto econmico como temporal. a o
2 Para suplir esta carencia, los diversos sistemas de bases de datos estn desarrollando sus a propios lenguajes procedurales, de modo que ampl la funcionalidad de los procedimientos an 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 slo necesita o enviar los resultados de regreso a la capa superior, deshacindose de la sobrecarga resultante e de transferir grandes cantidades de datos.
30
El implementar la lgica de acceso a datos en el propio cliente implica que o un usuario puede descifrar su funcionamiento, y por tanto su implementacin, lo que posibilita el aprovechamiento de fallos de seguridad para o llevar a cabo acciones que no estn previstas. a 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 devolucin de la respuesta a esta peticin depender de la mquina o o a a donde se encuentra alojado el servidor, y no de la del cliente, que unica mente recibe el resultado. El servidor de datos devuelve slo la informacin solicitada a travs de o no e la red, de tal modo que el trco de la misma resulta sustancialmente rea ducido. 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 ms ecazmente la integria dad 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 integracin en sistemas software complejos como pueden ser o los sistemas de gestin de una empresa o los sistemas de informacin integrados o o consistentes en ms de una aplicacin. Estas aplicaciones, como ya hemos visto, a o suelen encontrarse con importantes problemas de escalabilidad, disponibilidad, seguridad e integracin. o El paso siguiente a la arquitectura de 2 capas fue la aparicin entre la capa o de interfaz (presentacin) y la de acceso a datos, de una tercera capa de reglas o o lgica de negocio, que es la que realmente implementa las funciones de la o aplicacin y debe obviar tanto la estructura de los datos como su ubicacin. o o El cliente ((pesado)) que en la arquitectura de dos capas aglutina la interfaz junto con la lgica de la aplicacin se divide en un cliente ((ligero)) y la lgica o o o de la aplicacin se traslada completamente a un servidor. Por ejemplo, en una o aplicacin web el cliente es un navegador que muestra las pginas enviadas por o a el servidor que administra la lgica de negocio, las cuales permiten el ingreso o o la consulta de los datos.
3.2.1.
Funciones de cada capa
En la gura 3.5 en la pgina siguiente se ilustran de manera general los a 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 ms bajo. Sus funciones incluyen el almacenamiento, a la actualizacin y la consulta de todos los datos contenidos en el sistema. En o la prctica, esta capa es esencialmente un servidor de bases de datos, aunque a podr ser cualquier otra fuente de informacin. Gracias a esta divisin, es poa o o sible 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 lgica de negocio y presentacin, en un servidor independiente o incluso estar o o distribuida entre un conjunto de servidores, dependiendo de la magnitud de la aplicacin. o 3.2.1.2. Capa de aplicacin o
El comportamiento de la aplicacin es denido por los componentes que o modelan la lgica de negocio. Estos componentes reciben las acciones a realizar o a travs de la capa de presentacin, y lleva a cabo las tareas necesarias utilizando e o la capa de datos para manipular la informacin del sistema. Tener la lgica de o o negocio separada del resto del sistema tambin permite una integracin ms e o a sencilla y ecaz con sistemas externos, ya que la misma lgica utilizada por o la capa de presentacin puede ser accedida desde procesos automticos que o a intercambian informacin con los mismos. o 3.2.1.3. Capa de presentacin o capa cliente o
La capa de presentacin representa la parte del sistema con la que intero acta el usuario, la interfaz. En una aplicacin web, un navegador puede utiu o lizarse como cliente del sistema, pero sta no es la unica posibilidad, tambin e e puede generarse una aplicacin que cumpla las funciones de cliente ((ligero)) para o 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, adems de las que de por s tienen los sistemas diseados de forma a n modular. Pero tambin han conseguido mejorar muchos de los aspectos que han e resultado dif ciles de solucionar en la arquitectura de 2 capas: 32
Permite la reutilizacin: La aplicacin est formada por una serie de como o a ponentes que se comunican entre s a travs de interfaces y que coope e ran para lograr el comportamiento deseado. Esto permite no solamente que estos componentes puedan ser fcilmente reemplazados por otros, por a ejemplo en caso de necesitarse mayor funcionalidad, sino tambin que los e mismos puedan ser utilizados para otras aplicaciones. Acompa a el crecimiento: Cada uno de los componentes de la aplicacin n o pueden colocarse en el mismo equipo o distribuirse a travs de una red. De e esta manera, proyectos de gran envergadura pueden dividirse en pequeos n proyectos ms simples y manejables, que se pueden implementar en forma a progresiva, agregando nuevos servicios segn la medida de crecimiento de u la organizacin. o Uso eciente del hardware: Debido a que los componentes pueden ser distribuidos a travs de toda la red, se puede hacer un uso ms eciente de los e a recursos de hardware. En vez de necesitarse grandes servidores que contengan la lgica de negocios y los datos, es posible distribuirlos en varias o mquinas ms pequeas, econmicas y de fcil reemplazo en caso de fallo. a a n o a M nima inversin inicial: Generalmente, un cambio en el sistema de gestin o o tra asociada una inversin importante en la actualizacin de hardware a o o en los clientes, debido a nuevas necesidades de cmputo de las aplicacioo nes ((pesadas)). Los clientes ((ligeros)) de esta nueva modalidad permiten manterner el equipamiento actual o adquirir uno de muy bajo coste y actualizar, slo en caso de ser necesario, la tecnolog de los servidores. o a Distintas presentaciones: Debido a que separa la presentacin de la lgica o o de negocio, es mucho ms sencillo realizar tantas presentaciones diferena tes como dispositivos con capacidades e interfaces se tenga (PC, PDA, telfonos mviles, etc.). e o Encapsulacin de los datos: Debido a que las aplicaciones cliente se coo munican con los datos a travs de peticiones que los servidores responden e ocultando y encapsulando los detalles de la lgica de la aplicacin, obteneo o mos un nivel de abstraccin que permite un acceso a los datos consistente, o 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, stas pueden ser probadas independientee mente y con mucho ms detalle, lo que conduce a obtener un producto a mucho ms slido y able. a o
33
Cap tulo 4
Arquitectura J2EE
J2EE es una tecnolog que pretende simplicar el diseo y la implementacin a n o de aplicaciones empresariales. Una aplicacin empresarial es una aplicacin que probablemente disponga o o de aplicaciones y bases de datos ya existentes, que se quieran seguir utilizando durante la migracin a un nuevo conjunto de herramientas que exploten las o posibilidades de Internet, comercio electrnico y otras nuevas tecnolog o as. Las razones principales de la evolucin de las aplicaciones empresariales son: o Necesidad de aprovechar las nuevas tecnolog especialmente los avances as, en sistemas web. Necesidad de manejar detalles a bajo nivel, propias e inherentes a toda aplicacin empresarial, tales como seguridad, proceso de transacciones y o tareas multihilo. Evolucin y popularidad de conceptos ampliamente aceptados, tales como o 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 ms coa nocidos 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 J2EE? e
Tal vez J2EE no sea la tecnolog denitiva para el desarrollo de aplicacioa nes empresariales, no obstante ofrece una serie de ventajas que la han hecho posicionarse como una de las alternativas ms utilizadas: a
34
CAP ITULO 4. ARQUITECTURA J2EE
4.1.1.
Ahorro de trabajo
Una aplicacin empresarial necesita implementar servicios realmente como plejos para ser completamente funcional y eciente. Ejemplos de estos servicios son el manejo de estados y transacciones, pooling de recursos o gestin de tao reas multihilo. La arquitectura J2EE separa estos servicios de bajo nivel de la lgica de la aplicacin, puesto que estn implementados en el propio servidor de o o a aplicaciones. De este modo, no es necesario implementarlos para cada proyecto en caso de ser necesarios.
4.1.2.
Documentacin o
J2EE es desarrollado por un consorcio formado por grandes compa el nas, Java Community Process1 , lo que garantiza que su implementacin est docuo a mentada de forma completa y normalizada. Asimismo, las APIs utilizadas tambin cuentan con documentacin completa e o y detallada de todas sus funciones. Esta documentacin puede ser consultada o directamente desde la pgina de Sun, existiendo documentacin para todas las a o versiones de la especicacin. o
4.1.3.
Estndar y conable a
El uso de una arquitectura madura y que se ha convertido en estndar de faca to implica la posibilidad de desarrollar aplicaciones conables, lo que se traduce en menor gasto de mantenimiento y garantiza su longevidad y escalabilidad. Esta especicacin es considerada informalmente como un estndar, debido o a 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 slamente unos o pocos cambios en los cheros de conguracin. De hecho, aunque Genereitor o est desarrollado para trabajar sobre Tomcat, se ha conseguido desplegar soa bre OC4J y JBoss sin problemas, haciendo m nimos cambios en sus cheros de conguracin. o
4.2.
Plataforma J2EE
La plataforma J2EE utiliza un modelo de aplicaciones distribu y multicado pa. La lgica de la aplicacin est dividida en componentes, y cada componente o o a
1 La
especicacin de J2EE se puede consultar en http://www.jcp.org/en/jsr/detail?id= o
244.
35
est instalado en una mquina espec a a ca, cuyas caracter sticas irn acordes con a los requisitos de los componentes que se alojan en ella2 . En la gura 4.1 se muestra un diagrama bsico de la arquitectura J2EE. a
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 aplicacin de su representacin de cara al usuario, y o o de la interaccin de ste con la aplicacin, mediante la divisin del sistema en o e o o tres partes fundamentales: Modelo: contiene la lgica de negocio de la aplicacin. o o Vista: muestra al usuario la informacin que ste solicita. o e Controlador: recibe e interpreta la interaccin del usuario, actuando sobre o modelo y vista de manera adecuada para provocar cambios de estado en la representacin interna de los datos, as como en su visualizacin. o o Un esquema de estas tres capas se presenta en la gura 4.2 en la pgina a siguiente.
2 Aunque la arquitectura est pensada para que las diversas capas estn soportadas por e e mquinas diferentes, es perfectamente posible, en el caso de aplicaciones pequeas, que todos a n los servidores residan en la misma mquina. As a mismo, para aplicaciones de gran envergadura, tambin es posible que una capa sea soportada por varios servidores, utilizando computacin e o distribuida.
36
Figura 4.2: Diagrama del MVC.
Las consecuencias del uso de MVC en el diseo de una aplicacin son: n o Componentes del Modelo reutilizables. La separacin entre modelo y viso ta permite implementar mltiples vistas que utilicen el mismo modelo. A u consecuencia de sto, los componentes del modelo de una aplicacin eme o presarial son ms fciles de implmenetar, probar y mantener, puesto que a a el modelo se basa en estos componentes. Fcil soporte para nuevos tipos de clientes. Para incluir una nueva vista a en una aplicacin (mviles, pdas, etc) slo es necesario implementar dicha o o o vista y la lgica de control del modelo, e incorporarlos a la aplicacin. o o Dicha vista aprovechar el modelo existente para funcionar. a Incrementa la complejidad del dise o. Este esquema incorpora algunas clan ses adicionales, debido a la separacin de vista, modelo y controlador, por o lo que el diseo aumenta de tamao y, en aplicaciones pequeas, puede n n n ser engorroso mantener tal separacin. o Esta arquitectura ha demostrado ser muy apropiada para las aplicaciones web, y se adapta extraordinariamente a las tecnolog proporcionadas por la as 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 aplicacin y la lgica de negocio que o o gobierna el acceso a dichos datos. Estar implementado por un conjunto de a clases Java. Para este cometido existen dos alternativas de implementacin: o
37
4.3.1.1.
Enterprise JavaBeans
Enterprise JavaBeans es una arquitectura de componentes distribu del lado do del servidor para la construccin modular de aplicaciones empresariales. o La especicacin EJB es una de las muchas APIs de J2EE3 , que intenta o proveer un mtodo estndar para implementar la lgica de negocio que se suee a o le encontrar en aplicaciones empresariales. Fue concebida para manejar caracter sticas tales como persistencia, integridad transaccional y seguridad de forma estndar, liberando a los programadores para concentrarse en las tareas espec a cas de cada aplicacin. o La especicacin EJB provee: o 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 pequea envergadura, n 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 mtodos getPropiedad() e y setPropiedad(). Genereitor implementa su capa modelo con POJOs, aunque los proyectos generados con l incluyen la posibilidad de implementarla mediante EJB. e
3 La especicacin de EJB 2.0 se puede descargar en http://www.jcp.org/en/jsr/detail? o id=19/. 4 La gestin transaccional es un mtodo consistente en descomponer los procesos en operao e ciones atmicas e indivisibles llamadas transacciones. Cada transaccin debe nalizar de forma o o correcta o incorrecta como una unidad completa, no puede acabar en un estado intermedio. Tambin establece caracter e sticas como rollback, que permite, en caso de fallo, deshacer la operacin para restaurar su estado inicial e informar del fallo. o
38
4.3.2.
Vista
La vista proporciona una serie de pginas web, creadas dinmicamente, al a a cliente, que las recibir como simples pginas HTML que interpretar su navea a a gador. Existen mltiples frameworks que generan estas pginas web a partir de u a distintos formatos, siendo el ms extendido JSP (Java Servlets Page 5 ). a JSP permite desarrollar pginas HTML, pero incluye la posibilidad de utilizar a en stas cdigo Java, lo que permite a personas con conocimientos en HTML e o desarrollar interfaces de una forma rpida y sencilla. a Alternativas a JSP son ASP, PHP y Phyton, no obstante la primera es la que ofrece una mejor integracin con J2EE. o
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 grco autnomo (standa o alone), las interacciones del usuario pueden ser pulsaciones de botones o selecciones en mens, mientras que en una aplicacin web, estas interacciones estn u o a representadas por peticiones HTTP (GET y POST). Las acciones implementadas por el modelo pueden ser la ejecucin de procesos o el cambio de estado del moo delo. Basado en las interacciones del usuario y las respuestas de las acciones del modelo, el controlador responde seleccionando una vista apropiada a la peticin o 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 diseado eespecialmente para ofrecer contenido dinmico desde un servidor web, n a generalmente HTML.
5 La
especicacin de JSP se puede consultar en http://www.jcp.org/en/jsr/detail?id= o
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 ms avanzados, a 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 parmetros de conguracin. a o
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 implementacin de aplicaciones web para o 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 la aplicacin. Esta aplicacin en realidad slo ser un a o o o a esbozo del resultado nal, pero sentar las bases para el desarrollo posterior por a parte de los programadores, ahorrando una cantidad sustancial de tiempo. Para explicar los diferentes apartados se har referencia a una hipottica a e aplicacin ((taller)), cuyo esquema de la base de datos se reeja en la gura 4.3. o
Figura 4.3: Esquema de la base de datos de la aplicacin de ejemplo ((taller)). o
41
Cap tulo 5
Generacin de esqueleto o
La generacin del esqueleto es la primera fase de la implementacin de una o o aplicacin web. o Anteriormente se habr realizado el dise o de la aplicacin, teniendo en a n o cuenta, segn los requisitos del cliente, la estructura que tomar el proyecto u a y las tecnolog a utilizar. Este diseo quedar reejado con detalle en un as n a documento de anlisis y diseo (ver A en la pgina 116 para consultar el de a n a Genereitor), que servir de gu a lo largo de todo el proceso de implementacin. a a o Una vez han quedado claramente reejados todos los requisitos y caracter sticas que ha de tener el proyecto en el documento de anlisis y diseo, se procede a n a disear e implementar la base de datos sobre la que se apoyar la aplicacin. n a o Este paso no es comn a todas las aplicaciones, puesto que es comn que el u u cliente proporcione ya una base de datos existente (en caso de migraciones o actualizaciones de aplicacin). o Tras esto, se comienza la implementacin del proyecto, generando el esqueo leto. El esqueleto de una aplicacin es la estructura de directorios sobre la que se o asienta, y que permite tener separados y bien identicados los componentes de la misma segn su funcin y la capa a la que pertenecen. u o Junto a la estructura de directorios se generarn cheros que implemena tarn funciones relativas a cada capa de la aplicacin, y que sern explicados a o a con detalle ms adelante. Algunos de estos cheros se generarn como clases a a vac con la cabecera pero sin mtodos. Estos mtodos sern proporcionados as, e e a con la generacin de cdigo, operacin que se realizar para cada entidad de la o o o a base de datos que quiera ser tenida en cuenta en la aplicacin, y posteriormeno te sern aadidos a estos cheros ((incompletos)) con una herramienta auxiliar a n (Combineitor, ver apartado B en la pgina 145). a
42
CAP ITULO 5. GENERACION DE ESQUELETO
5.1.
5.1.1.
Funciones de la interfaz
Fase 1. Generacin de esqueleto o
La unica pantalla de generacin de esqueleto contiene tres bloques que so o licitan informacin al programador para adecuar el esqueleto generado a las o necesidades del proyecto. 5.1.1.1. Bloque de datos generales
En este primer bloque se solicitan los datos generales necesarios para generacin del esqueleto de una aplicacin. Tales datos son: o o Sistema de bases de datos. El programador elegir de entre las opciones disa ponibles (Oracle 9, PostgreSQL, MySQL, HSQLDB o SQLServer1 ) el sistema de bases de datos que se ha elegido en el proceso de anlisis para soportar a la base de datos. Esta opcin afectar tanto a los datasources como a la o a forma de acceder a los datos en la base de datos. Servidor de aplicaciones. Segn el diseo de la aplicacin, se elegir entre u n o a OC4J o Tomcat2 . Nombre de la aplicacin. El nombre de la aplicacin. o o Nombre del paquete base de la aplicacin. El nombre del paquete base o de la aplicacin3 . o En este bloque tambin se ofrece un pulsador con el literal ((Default)), cuya e funcin es autocompletar el siguiente bloque con los datos de conexin de las o o bases de datos de desarrollo que hay en la factor de software de la empresa, a segn el servidor de bases de datos seleccionado. Con varias pulsaciones sobre u 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 conexin o
Aqu se recogen los datos de conexin de la base de datos contra la que va o a trabajar la aplicacin a desarrollar: o 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 aplicacin siempre sea el ultimo elemento del nombre o del paquete base. As la aplicacin taller tendr su paquete base llamado com.comex.taller. Es , o a por esto que en la casilla de ( (nombre de paquete base) slo hay que introducir los primeros ) o elementos del nombre (com.comex), ya que el ultimo se completa automticamente a partir a del contenido de la casilla ( (nombre de la aplicacin) o ).
2 El 1 El
43
Puerto. SID, o nombre de la base de datos. Usuario. Contrasea. n Aunque para la generacin del esqueleto realmente no es necesaria una coo nexin real a la base de datos, stos se requieren para congurar correctamente o e los dataosurces. Para comprobar que los datos introducidos son correctos, y as evitar errores tipogrcos, se proporciona un botn con el literal ((Test)) que lanza una conea o xin al servidor cuyos datos han sido introducidos, informando al programador o de si sta ha sido exitosa, o del error producido en caso contrario. e 5.1.1.3. Bloque de opciones de la aplicacin o
En este ultimo bloque de datos se solicitan las caracter sticas particulares del proyecto a generar: Mdulos web. Una aplicacin web puede estar formada por varios mdulos o o o o subaplicaciones. Por ejemplo, en el caso de un portal que tenga una parte de acceso pblico (por ejemplo taller-web), una para clientes (talleru clientes) y otra para administracin de contenidos (taller-admin). Se ofrece o una lista en la que se aadirn todos los mdulos que sean necesarios para n a o la aplicacin. o Utilizar Authenticator. Permite aadir un mecanismo de seguridad a las n conexiones de la aplicacin, consistente en un parmetro authenticator, o a que conrma que el usuario que solicita la conexin es un usuario vlido o a conforme al registro de usuarios existente en la base de datos. Utilizar XML4 . Integra en la aplicacin el mdulo de comunicacin de datos o o o mediante XML de la empresa (com.comex.xml). Utilizar CMS. Integra en la aplicacin el sistema de gestin de contenidos o o (com.comex.cms). Utilizar parmetros. Hace que la aplicacin generada tome una serie de parmea o a tros que se alojarn en la base de datos, en lugar de almacenarlos en la a propia aplicacin.5 o Utilizar tablas maestras. Integra en la aplicacin el mdulo de tablas maeso o tras (com.comex.tablasmaestras), que genera las interfaces de gestin de o
funcin XML todav no est implementada completamente. o a a la opcin parmetros es obligatoria, puesto que otros mdulos dependen o a o de estos parmetros. Ms adelante, cuando se actualicen esos mdulos y no requieran los a a o parmetros alojados en la base de datos, esta posibilidad se ofrecer como opcional. a a
5 Actualmente 4 La
44
tablas maestras a partir de un script que se generar a posteriori con la a funcin ((Generar script de tablas maestras)) de Genereitor.6 o Usuarios, perles y grupos7 . Integra en la aplicacin el mdulo que da soo o porte para usuarios, grupos de usuarios y perles, y ofrece una lista para congurar los perles que se utilizarn en la aplicacin. a o Librer as. Ofrece una lista de las librer comnmente utilizadas, de manera as u que el programador incluya las que crea convenientes teniendo en cuenta los requisitos del diseo. Estas librer se incluirn en el esqueleto genen as a rado, y se tendrn en cuenta en los scripts de compilacin y despliegue de a o la aplicacin para que no haya que moverlas a mano. o Por ultimo, tras haber rellenado las opciones pertinentes y al pulsar el botn o ((Generar )), el programa devuelve un paquete comprimido que contiene el esqueleto de la nueva aplicacin. o
5.2.
Resultado
Tras haber generado el esqueleto, se ha obtenido un paquete que contiene la estructura del proyecto comprimida. El siguiente paso ser descomprimir su a contenido en el directorio de la mquina del desarrollador, que ser su copia de a a trabajo. De forma muy simplicada, la estructura de directorios generada es la representada en la gura 5.1 en la pgina siguiente. a Adems de la estructura de directorios, se generan diversos archivos que a a continuacin se detallan: o
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 pgina HTML, contiene v a nculos a las acciones (por ejemplo, a vehiculo.listar.do), que hacen referencia a los mtodos e de los servlets (Actions). Este chero se encarga de interpretar las peticiones del usuario, mediante su interaccin con la interfaz, e invocar al o 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 la que se use al implementar la interfaz. De este modo se a
la opcin tablas maestras es obligatoria, puesto que otros mdulos dependen o o de funcionalidades implementadas en com.comex.tablasmaestras. Cuando se actualicen estas dependencias y no se requiera del mdulo de tablas maestras, esta posibilidad se ofrecer como o a opcional. 7 La funcin Usuarios todav no est implementada completamente. o a a
6 Actualmente
45
/ META-INF apps taller taller-ejb ejb ......................................... Fachada y EJB exception ..................................... Excepciones taller-web.................................Mdulo web ((web)) o src servlet.........................................Actions taglib ............................. Tags de la parte web util web.....................................JSP, CSS, imgenes a taller-webadmin ..................... Mdulo web ((webadmin)) o ... ... src.........Ficheros de conguracin, despliegue, data-sources... o components common.........................................Mdulos utilizados o taller dal.............................................Acceso a datos bean..........................Implementacin de los objetos o lib ........................................................ Librer as setup instalacion ............................... Ayuda a la instalacin o scripts..............................................Scripts SQL Figura 5.1: Arbol de directorios simplicado de una aplicacin web. o / 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 rpida localizacin y correccin a o o de errores en la escritura de los textos de la aplicacin. o log4j.properties: Contiene la conguracin de los logs de la aplicacin. Se ofreo o cen tres conguraciones (para desarrollo, preproduccin y produccin), o o puesto que segn la etapa en la que se encuentre el proyecto ser necesau a ria una mayor o menor intensidad en la monitorizacin y auditor de los o a eventos que tengan lugar. cong.properties: Contiene diversos parmetros de conguracin general proa o pios de la aplicacin. o 46
En caso de que la aplicacin utilice EJBs, se proporcionarn tambin los o a e archivos (incompletos, se completarn con la generacin de cdigo) que cona o o tendrn los descriptores de despliegue. Estos archivos indican al servidor de a aplicaciones cmo han de desplegar la aplicacin para ponerla en funcionamieno o to y el tratamiento que han de dar a los EJBs.
5.2.2.
/
Scripts de compilacin o
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 compilacin. o Estos archivos build.xml repartidos por toda la estructura de directorios son los que indican a ant de qu forma se debe llevar a cabo la compilacin del e o proyecto. El script principal es el situado en el directorio ra (/build.xml), que ir llaz a mando segn convenga a los situados en los diferentes directorios de la estrucu tura. El motivo de la divisin de las tareas de compilacin en varios scripts es o o 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 funcin es idntica al anterior, pero teniendo en cuenta los parmetros de la o e a mquina del cliente donde se va a desplegar para su entrada en produccin, por a o lo que algunos parmetros sern diferentes. a a
5.2.3.
Capa web - Servlets (Controlador)
En esta ruta se alojan los cheros fuente de los servlets, tags y dems utilia dades que utiliza el controlador de la capa de aplicacin para generar la interfaz o web y comunicarse con el modelo de la capa de lgica de negocio. o Las funciones de los archivos generados son las siguientes: servlet/InicioAction.java: Implementa el servlet de bienvenida a la aplicacin, o que se encargar de formar la primera pgina de la interfaz. a a 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 mdulo web. o inactivas, y por tanto se considere que han caducado. Tambin limpiar cae a da cierto tiempo los atributos de dichas sesiones inactivas. servlet/TallerBaseAction.java: Servlet base que extendern todos los dems de a a la aplicacin. Implementa tambin funciones comunes o usadas por varios o e servlets, con objeto de reutilizar cdigo. Tambin implementa los mtodos o e e para que los dems servlets sean capaces de comunicarse con la fachada a que da acceso al modelo de la aplicacin. o taglib/ContenedorTag.java y taglib/BotonTag.java: Implementacin de los tags o que se utilizarn en los JSP para dibujar el contenedor general de la interfaz a y los botones. Esto supone una gran reutilizacin de cdigo, consiguiendo o o adems que todas las pginas pertenecientes al mismo mdulo web tengan a a o la misma apariencia. Directorio util: Aqu se localizan otros tags ms genricos, que no se modican a e de uno proyecto a otro, como el tag Paginador, que se encarga de agrupar los resultados de las listas en pginas de n elementos, ofreciendo enlaces de a ((siguiente)), ((anterior)), etc, y tambin implementa la funcin de ordenar. e o Tambin se encuentran aqu cheros que almacenan mtodos para validar e e 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 nmeros y cadenas. u
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 pgina siguiente): a Los directorios mostrados contienen los siguientes cheros: WEB-INF: Contiene los descriptores de los tags que estn disponibles para su a 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 mdulo web. o pretarlos segn su implementacin en el directorio del apartado anterior. u o Tambin contiene el chero web.xml8 . e css: Incluye estilos provisionales para la aplicacin, que luego habrn de ser o a modicados por el programado o diseador para adecualos a los requisitos n visuales impuestos por el cliente. error: Contiene las pginas que se mostrarn en caso de error. a a imagenes: Contiene las imgenes que se utilizan en la interfaz en botones, pula sadores de ordenacin de tablas, etc. o js: Recopilacin de utiles JavaScript que sern utilizados si los requisitos de o a accesibilidad de la aplicacin lo permiten. o privado y publico: Ficheros JSP que implementan cada pgina de la interfaz a de la aplicacin, tanto aquellas zonas de acceso pblico como las de acceso o u restringido.
5.2.5.
Capa de lgica de negocio - Fachada de Componeno tes (Modelo)
El modelo, ya sea implementado a partir de EJBs o POJOs, se encuentra en la siguiente ruta: Estos archivos slo representan la Fachada que se encarga de comunicar la o lgica de negocio de la aplicacin con los servlets, es decir, el modelo con el o o controlador. Cuando se genera el esqueleto, Genereitor todav no conoce qu entidades a e de la base de datos se van a manejar en la nueva aplicacin, por lo que no es o posible ofrecer estos archivos completos. En su lugar, se ofrecen unicamente las cabeceras de los cheros, y en la fase de generacin de cdigo se ofrecern trozos que se insertarn en los cheros que o o a a correspondan9 .
8 web.xml es el descriptor de despliegue que indica al contenedor de servlets diversos parmea tros, tales como la localizacin de los paquetes que forman el modelo, los descriptores de tags, o las pginas que mostrar en caso de error, etc. a 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 aplicacin con EJB. o
5.2.6.
Capa de acceso a datos - Scripts SQL
Con la generacin del esqueleto tambin se devuelven una serie de scripts o e SQL, aunque muchos de ellos estarn vac (recordemos que la implementacin a os o 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 generacin del esqueleto, estos cheros unicamente contendrn los o a datos de creacin de los componentes de la base de datos para el manejo de o la tabla APLICACION PARAMETRO, el rol APLICACION ROL APLICACION10 y los grants (permisos) de este rol para modicar la tabla parmetro. Esta tabla a ser utilizada por la aplicacin para guardar diversos parmetros. a o a Los cheros 07 CODIGO 00.SQL y 07 CODIGO 01.SQL sern utilizados si la a aplicacin implementa su capa de acceso a datos mediante PL/SQL directameno a te en el servidor de bases de datos. El chero 07 CODIGO 00.SQL contendr los
implementado una herramienta auxiliar, Combineitor, cuyas caracter sticas y funcionamiento se detallan en B en la pgina 145. a 10 Por ejemplo, TALLER ROL APLICACION.
50
tipos que utilizar PL/SQL mientras que 07 CODIGO 01.SQL contendr la ima a plementacin de las funciones y procedimientos. o a El estado inicial de 07 CODIGO 01.SQL ser el siguiente:
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 sern utilizadas por combineia tor para introducir los trozos de cdigo generados mediante el bloque funcional o de generacin de cdigo. o o
5.2.7.
Documento de instalacin o
Por ultimo, en la ruta setup/instalacion.html se proporciona un manual de instalacin de la aplicacin, a modo de gu para la instalacin de la aplicacin o o a o o en el cliente.
51
Cap tulo 6
Generacin de partes de o cdigo o

Este bloque funcional es el encargado de generar los componentes de la aplicacin correspondientes a cada una de las entidades de la base de datos que o van a formar parte de la aplicacin que se va a desarrollar. o Generalmente ser necesario realizar este paso para cada una de las entidades a 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 ms adelante, compartirn a a a ciertos componentes de la aplicacin. o Tambin en este apartado se generarn trozos de los cheros que quedaron e a incompletos en el apartado de generacin de esqueleto, y que se introducirn o a en dichos cheros mediante la herramienta Combineitor, cuyo funcionamiento est detallado en el apndice B en la pgina 145. a e a
6.1.
6.1.1.
Fase 1: Conexin o
El primer paso para la elaboracin de las partes de cdigo correspondientes o o a una entidad de la base de datos es la conexin al servidor de bases de datos. o Por ello, la primera fase de este bloque funcional es la introduccin de los datos o de conexin: o 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
CAP ITULO 6. GENERACION DE PARTES DE CODIGO
Usuario. Contrasea. n Tambin se proporciona un pulsador con el literal ((Default)), cuya funcin e o es autocompletar el siguiente bloque con los datos de conexin de las bases de o datos de desarrollo que hay en la factor de software de la empresa, segn el a u 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 botn ((Conectar)), se realizan una serie de validaciones mediante o 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 numrico y no nulo. e Si no se introduce un valor para el campo contrasea, se avisa al usuario n mediante un mensaje junto al botn ((Conectar)), y se hace parpadear o brevemente dicho campo para llamar su atencin. Si se vuelve a pulsar el o botn ((Conectar)) se lanzar efectivamente la conexin contra el servidor, o a o indiferentemente de que se haya introducido una contrasea. n Si existe algn error en los datos se informar al usuario mediante una caja u a de texto situada al principio de la pgina. De lo contrario, se lanzar la conexin a a o al servidor. Es posible que los datos introducidos, pese a tener un formato vlido, no sean a correctos y el servidor de bases de datos no responda o rechace la conexin. De o ser as se informar nuevamente al usuario del error y se le permitir modicar , a a los datos introducidos para volver a lanzar la conexin1 . o
6.1.2.
Fase 2: Seleccin de tabla o
En esta segunda fase se muestra al usuario, una vez se ha establecido con xito la conexin a la base de datos, una lista con todas las tablas y vistas e o existentes en ella, de donde se elegir la tabla correspondiente a la entidad para a que se desea generar los componentes de la aplicacin. o
1 Debido a que algunos sistemas de bases de datos ofrecen ms informacin que otros cuando a o ocurre un error en la conexin, dependiendo del sistema elegido los textos explicativos del error o sern ms o menos espec a a cos. Por ejemplo, mientras que un sistema puede devolver un error de tipo usuario no vlido, otro lanzar simplemente error en la conexin. a a o
53
6.1.3.
Fase 3: Seleccin de tablas relacionadas o
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 pgina 21, se muestran aqu dichas tablas relacionadas, ofreciendo as la posibia lidad de generar la lgica para dichas tablas de manera conjunta, adems de una o a presentacin especial en las vistas que se generarn. Todo esto ser explicado o a a con detalle en la seccin 6.2 en la pgina 58. o a Esta vista se compone de dos listas, una que contendr las tablas seleca cionables, es decir, el conjunto de tablas cuyas relaciones apuntan a la tabla seleccionada en el paso anterior, y otra en la que se aadirn las tablas que el n a usuario quiere incluir en el paquete de cdigo que va a ser generado. o 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, pasndose directamente a a la fase 4.
6.1.4.
Fase 4: Seleccin de campos o
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 campos aparecern en las pantallas de listado de e a la aplicacin web. Es posible que algunas propiedades de la entidad para o la que se est generando cdigo no interese que sean mostradas en las a o 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 diseo n de sta o cualquier otra circunstancia. Para los campos que sean clave e primaria de la tabla, o que cuenten originalmente con dicha restriccin o impuesta directamente en la base de datos no ser posible modicarla. a Tambin se podr redenir la longitud mxima que acepten los formue a a larios de edicin de la aplicacin a generar. Si el programador introduce o o una restriccin ms permisiva que la establecida en la base de datos, se o a conar en que acto seguido ser modicada dicha restriccin en la base a a o de datos, por lo que Genereitor no reportar ningn tipo de error. Esto se a u ha decidido implementar de este modo, permitiendo violar las restricciones de tamao porque no es raro encontrar errores de diseo en la base de n n datos, que habrn de ser subsanados aparte. De este modo, aunque la base a de datos tuviera errores de este tipo en su diseo, se permite la generan cin del cdigo acorde al diseo correcto, conando en que el programador o o n modicar la base de datos para subsanar el error. a Las longitudes mximas aparecern con los valores por defecto de las resa a tricciones que establece la base de datos.
54
Por ultimo se permite denir la etiqueta (texto explicativo) que descri bir cada propiedad de las entidades de la base de datos en la interfaz de a la aplicacin, por ejemplo en las descripciones de los campos de edicin o o o buscador. Estos literales tendrn el valor por defecto del nombre de la propiedad de a cada tabla, en formato Java 2 . Tambin se ofrece al usuario informacin tal como el nombre de cada proe o piedad 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 implementada la propiedad en la lgica de la aplicacin. a o o
6.1.5.
Fase 5: Seleccin de parmetros o a
Esta ultima fase del bloque funcional de generacin de cdigo consta de tres o o partes: 6.1.5.1. Datos de aplicacin o
Como en los otros bloques funcionales, es necesario informar a Genereitor del nombre de la aplicacin y el paquete base de la aplicacin que se va a generar. o o Como en otras ocasiones en las que se requieren los datos, es requisito que el ultimo componente del nombre de paquete sea el nombre de aplicacin, por lo o que no es necesario poner este ultimo componente, siendo concatenado al nal el nombre de la aplicacin por la propia interfaz de genereitor. o 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 opcin es debida a que con frecuencia las aplicaciones se desarrollan soo bre bases de datos que no estn implementadas por el equipo de desarrolladores a de la empresa, sino que el propio cliente la proporciona (por ejemplo, en caso de una migracin de una aplicacin existente a otra nueva, conservando el modelo o o 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 llevarn los objetos a que representarn a las entidades de la base de datos. a 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 llamada LISTADO VEHICULOS. Genereitor propondr como nombre del bean que represente a esta entidad ListadoVehiculos. Pero esto, aunque a nivel de implementacin ser posible, no es lgico. o a o
2 La columna PROPIEDAD DE EJEMPLO tendr como literal por defecto PropiedadDeEa jemplo.
55
Una tabla que represente un listado de veh culos en realidad almacenar ena tidades de tipo veh culo y no listados de veh culos, por lo que a la hora de implementar la aplicacin es ms lgico y ms cmodo para el programador o a o a o hablar de objetos de tipo Vehiculo. As es posible modicar el nombre de los beans con los que se trabajar en , a la aplicacin. No obstante, en los componentes de acceso a datos se seguir reo a riendo a las tablas por sus nombres originales (LISTADO VEHICULOS, puesto que de lo contrario no ser posible acceder a la informacin. a o 6.1.5.3. Parmetros a
En este ultimo bloque de la pgina se permite al usuario seleccionar las a caracter sticas particulares de los componentes generados para la entidad sobre la que se est trabajando. a Mdulos web: tal y como se vio en el bloque funcional de generacin de esqueo o leto, una aplicacin puede contar con varios mdulos web que aprovechen o o la misma lgica de negocio, aunque tengan diferentes funcionalidades. As o , es probable que una entidad de la base de datos tenga que ser accesible por varios mdulos web, por lo que aqu se ofrece una lista para aadir los o n mdulos que han de implementar dicha entidad. o Aunque la entidad siempre estar disponible a nivel de modelo, porque a todos los mdulos web de la aplicacin comparten esta capa, aqu se seo o leccionar para qu mdulos se ha de implementar vista y controlador. a e o Utilizar Authenticator. Permite aadir un mecanismo de seguridad a las n conexiones de la aplicacin, consistente en un parmetro authenticator, o a que conrma que el usuario que solicita la conexin es un usuario vlido o a 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 simultnea, en lua gar de tener que hacerlo uno por uno. JSP de edicin: Genera la parte de la vista correspondiente a la pantalla de o edicin de los objetos pertenecientes a la entidad de la cual se est geneo a rando la lgica, que permitir aadir, editar o borrar registros en la base o a n de datos. JSP de detalle: Genera la parte de la vista correspondiente a la pantalla de detalle, que mostrar todas las propiedades de los objetos pertenecientes a a la entidad. Tratar las entidades secundarias en la misma pgina que la principal: a Esta opcin integra, en caso de que se hayan seleccionado tablas relacioo nadas a la principal, el listado de las secundarias en la misma pantalla que la edicin de la entidad principal. o
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 ningn veh u culos. Asumiremos que un veh culo siempre tiene propietario. Esta opcin nos permite aadir, a la vista de edicin de la entidad Proo n o pietario el listado de entidades Vehiculo que le pertenecen, de forma que dicha lista de veh culos se reeja visualmente como una propiedad ms del a propietario. Junto con el listado de veh culos se proporciona un buscador, de forma idntica al listado de la entidad principal, Propietario. e Si no se selecciona esta opcin, el listado de la entidad secundaria se moso trar en una pantalla diferente a la edicin de la principal. a o 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 gestin de los datos de ambas usando esta opcin, es decir, o o con el listado de la secundaria en la edicin de la principal. Por contra, o en la gura 6.2 en la pgina siguiente se muestra el ujo de las vistas con a esta opcin desactivada. o
Figura 6.1: Esquema de las vistas con entidades relacionadas (amarillo) en la edicin de la principal (azul). o
EJB/Clases Java: Aqu seleccionar el programador si desea utilizar EJB o a POJOs para implementar la capa de lgica de negocio, dependiendo de los o rquisitos de la aplicacin que se est desarrollando. o a EJBs locales/remotos: Si se seleccionan EJBs para implementar la capa de lgica de negocio, aqu se seleccionar si se desea utilizar EJBs o a 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 opcin slo est presente si se ha seleccionado una o o a base de datos Oracle. PL/SQL permite implementar la lgica de acceso a o 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 unicamente 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 unicamente 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 ms eciente utilizar PL/SQL si est disponible, puesto que los datos a a enviados entre el servidor de aplicaciones y el servidor de bases de datos son unicamente los que interesan, liberando a la red de trco innecesario. a
6.2.
6.2.1.
Resultado
Capa web - JSP (Vista)
En la parte correspondiente a la vista, el paquete de cdigo generado cono tendr, segn las opciones seleccionadas, los siguientes componentes: a u
3 La diferencia entre EJBs remotos o locales es que los remotos son accesibles por todos los componentes de la aplicacin, mientras que los locales unicamente pueden ser llamados desde o la capa de lgica de negocio. Es por esto que normalmente la fachada se implementa como o remota, ya que ha de ser accesible desde la capa web, y los dems componentes se implementan a como locales, ya que slo han de ser accedidos por la fachada y entre ellos. o
58
6.2.1.1.
JSP de listado
Ser el chero que se utilice para la composicin dinmica de la vista de a o a listado y buscador de la entidad generada. Dicha vista se compondr, en primer lugar, de un buscador que permite a introducir valores para cualquiera de las propiedades de la entidad, y que al pulsar el botn ((Buscar)) devolver una lista de los resultados ltrados por los o a valores introducidos. Si existen en la entidad propiedades de tipo fecha, junto al campo para introducir dicho dato se proporciona un botn que al pulsarlo despliega un o calendario, permitiendo al usuario de la aplicacin seleccionar el d con mayor o a comodidad. Este calendario est implementado con JavaScript y CSS, por lo a que no funcionar en un navegador sin soporte para JavaScript. No obstante, se a podr introducir la fecha directamente en la casilla correspondiente, por lo que a 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 un absurdo. a Si la clave primaria de la entidad es unica (consta de un slo campo) y o numrica se asume que es autonumrica y por tanto no se ofrece buscar por e e dicho campo, puesto que no tendr utilidad ltrar por una propiedad de tales a caracter sticas. La suposicin de que el campo es autonumrico es necesaria, o e 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 autonumrico o realmente es e un cdigo numrico con algn signicado. Es por esto por lo que se proporo e u ciona tambin la alternativa para considerar dicha clave primaria como campo e numrico, en forma de comentarios en la pgina. e a Bajo el buscador se encuentra el listado. Dicho listado se construye con un tag tabla proporcionado con la generacin del esqueleto, que generar dinmicao a a mente el listado a partir de un objeto BaseBeanSet4 que recibe como parmetro. a Dicho tag tabla recibe una serie de descriptores, tanto de tabla como de columna, que indican de qu manera ha de dibujarse (por ejemplo, el nmero y e u caracter sticas de las columnas que formarn el listado). a Para cada entidad de la base de datos del tipo listado que cumpla con las condiciones impuestas por el ltro de bsqueda en caso de haberse especicado u se mostrar una la en la tabla. Si el nmero de las a mostrar excede de a u a o 105 , el paginador de la tabla se encargar de mostrar slo los diez primeros elementos, creando al pie de la tabla una lista de pginas de la tabla, a las que a se puede acceder pinchando directamente sobre los nmeros o sobre las echas u de anterior y siguiente. Este paginador tambin permite ordenar la tabla por e 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 todos los objetos de la base de datos del tipo que se quiere listar. a 5 10 es el valor por defecto que se ofrece para la longitud de las pginas, pero es totalmente a personalizable.
59
cabecera de cada columna. Al realizar una ordenacin, se resaltar la columna o a 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 adems: a a Un checkbox para seleccionar registros y poder borrarlos posteriormente con el botn inferior de ((borrar)), en caso de que se haya seleccionado a o la hora de generar el cdigo la opcin ((generar cdigo para borrar varios o o o beans en listado)). Un botn de edicin, que llevar a la pgina de edicin de la entrada cuyo o o a a o botn se pulse, permitiendo al usuario modicar el registro, en caso de o que se haya seleccionado al generar el cdigo la opcin ((generar JSP de o o edicin)). o 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 algn chero almacenado en u el registro, el botn aparecer de color naranja (activo) y al pulsarlo o a comenzar la descarga6 . Si dicho registro no almacena un binario, el a botn se muestra gris (inactivo) y se avisa al usuario de que no hay o datos almacenados al pulsarlo. Borrar binario: Permite borrar el chero binario del registro seleccionado. Bajo el listado se ofrecen tambin los botones de ((Borrar)), que elimina los e registros seleccionados en la tabla, ((Nuevo)), que lleva a la vista de edicin de la o entidad mostrando los registros en blanco para la adicin de un nuevo registro, o y ((Volver)), que permite regresar a la pgina visitada anteriormente. a Todos los estilos utilizados, tanto en el buscador como en el listado, estn a denidos en la hoja de estilos CSS proporcionada con la generacin de esqueleto. o 6.2.1.2. JSP de edicin o
Al editar o insertar un registro, el controlador llama a la vista de edicin. o 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 edicin. o Nuevamente si existe un campo de tipo fecha, se proporciona el calendario junto a la casilla correspondiente.
6 Como se explicar ms adelante, tanto las cargas como las descargas de binarios se hacen a a 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 reproduccin del recurso, sino que en o cuanto acabe la descarga del primer ( (trozo) de chero comenzar, almacenando en el bfer ) a u los datos de los siguientes trozos conforme se vayan descargando del servidor.
60
Si la clave primaria es unica y numrica se asume que es autonumrica, por e e lo que no se muestra el campo para aadir dicho dato. Se asume que al realizar n la insercin le ser asignado un nuevo valor de clave primaria al registro. o a Si existen campos binarios (BLOBs) el formulario proporcionado es de tipo multipart, que permite subir cheros grandes en partes al servidor. Si es una operacin de edicin, tanto si hay binarios almacenados como si no, aparecen o o los campos de seleccin de archivo vac Si se modican, se aadir o sobreo os. n a escribir el binario de la base de datos por el subido recientemente. Si se dejan a en blanco, no se modicarn dichos campos en la base de datos. Para la operaa cin de eliminar el binario almacenado en un registro, se proporciona el botn o o ((Borrar binario)) en la pantalla de listado. Al nal de la pgina se proporcionan los botones de ((Aceptar)) y ((Volver)), a que retornarn al usuario a la pantalla de listado, guardando o descartando a respectivamente las modicaciones. Entidades relacionadas En caso de que se haya generado componentes para las tablas relacionadas, en esta pgina aparecern adems: a a a Buscador y listado de cada entidad relacionada si se seleccion la opcin o o de tratar entidades relacionadas en la misma pgina que la principal (a gura 6.1 en la pgina 57). a Botones de listado de entidades secundarias si no se seleccion dicha opo cin, que llevar a la vista de listado de la entidad secundaria (gura 6.2 o a en la pgina 58). a En ambos casos el buscador y listado tendrn idntico comportamiento que a e los de la entidad principal, pero mostrarn unicamente los campos correspona dientes 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, slo se listarn los veh o a culos correspondientes a dicho usuario, y no los de los dems. a
Validaciones de datos introducidos

Las validaciones de los datos introducidos se realizan por defecto en la mquia na del cliente, mediante el intrprete de JavaScript del usuario. Si los requisitos e de accesibilidad de la aplicacin impiden el uso de dicho sistema, se han de o 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 cdigo. o 61
6.2.2.
Capa web - Servlet (Controlador)
El componente correspondiente al controlador que manejar las peticiones a del usuario, provinientes de la vista, e interactuar con el modelo, consultando o a modicando los datos, se proporciona tambin en el paquete de cdigo generado e o para cada entidad. El servlet proporcionado contar con las siguientes funciones7 : a perform(), que es la encargada de recibir la llamada de la vista y dirigir la peticin del usuario hacia la accin del servlet que corresponda. o o inicio(), es la funcin inicial del controlador de la entidad. Se encarga de seleco cionar la vista de listado, tras establecer un ltro de bsqueda nulo (para u que la lista muestre todos los registros) y una ordenacin por defecto. Para o obtener la lista de elementos llamar a la funcin getListaEntidad() de la a o fachada del modelo. listar(), se encarga de crear la vista de listado tras haber insertado, actualizado o borrado un registro. Mantiene la ordenacin, la paginacin y el ltro o o de bsqueda establecidos antes de comenzar el proceso de edicin, inseru o cin o borrado. Para obtener la lista de elementos llamar a la funcin o a o getListaEntidad() de la fachada del modelo. listarSession(), de cometido similar a listar(), salvo que devuelve la vista de listado con la paginacin, ordenacin y ltro de bsqueda denidos por o o u defecto en la sesin. Para obtener la lista de elementos llamar a la funcin o a o getListaEntidad() de la fachada del modelo. paginar(), establece el cambio de orden o la agrupacin en pginas de n eleo a mentos (10 por defecto). Dene la propiedad de la entidad por la que se ordena, el tipo de ordenacin (ascendente o descendente), y el nmero de o u pgina que va a mostrar la vista. Tras componer la lista de elementos ora denada, se invoca a la vista de listado. Para obtener la lista de elementos llamar a la funcin getListaEntidad() de la fachada del modelo. a o buscar(), crea un ltro de bsqueda a partir de los parmetros introducidos en u a 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 la a funcin getListaEntidad() de la fachada del modelo. o nuevo(), Esta funcin unicamente invoca a la vista de edicin de la entidad o o correspondiente. En caso de que la tabla de la base de datos que representa dicha entidad tenga clave primaria unica y numrica no aparece el campo e correspondiente a esta propiedad, ya que se asume que es autonumrica y e la capa de acceso a datos le asignar automticamente un valor. a a
7 Nota: en los nombres de las funciones, el literal Entidad equivale al nombre de la entidad que se introdujo en la etapa de seleccin de parmetros del bloque funcional de generacin de o a o cdigo. Por ejemplo, la funcin getEntidad() equivaldr a getPropietario() en el ejemplo de las o o a 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 funcin, que ser llamada desde la vista de edicin una vez o a o se hayan rellenado los campos correspondientes a las propiedades de la entidad, llamar a la funcin insertEntidad() de la fachada del modelo, a o pasando un objeto del tipo de la entidad. editar(), invoca la vista de edicin, con los valores de todas las propiedades del o objeto que se quiere editar, para que el usuario modique las que desee. Al igual que la funcin insertar(), si la clave primaria de la entidad es o unica y numrica no se recoge dicho valor, puesto que no ser posible e a modicarlo. actualizar(), al conrmar los cambios, esta funcin env el objeto modicado o a a la funcin updateEntidad() de la fachada de la capa de lgica de negocio. o o borrar(), recoge el valor (o valores) de la clave primaria del registro y llama a la funcin deleteEntidad() de la fachada. o borrarVarios(), recoge el valor de la clave primaria de los registros seleccionados y llama a la funcin deleteListaEntidad() de la fachada de la capa de lgica o o de negocio. createDescriptorTabla(), que se encarga de crear los descriptores de la tabla y las columnas de los listados. Esta funcin es llamada por las anteriores o 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 estn seleccioa nados en el listado. tratarError(), dene el comportamiento de la aplicacin en caso de que se proo duzca algn error. u 6.2.2.1. Servlets de entidades con binarios
En caso de que en la entidad para la que se ha generado cdigo posea campos o que almacenan binarios (de tipo BLOB), adems de las funciones anteriores se a generan las siguientes: getPropiedadbinariaEntidad(), que llamar a la funcin getPropiedadbinariaEntidad() a o de la fachada y devolver al usuario el archivo binario almacenado en la a base de datos. La descarga del chero se efecta mediante streaming, es u decir, se env los trozos concatenados en vez de cargar el chero de an una vez, lo que mejora el rendimiento y evita el colapso del servidor de aplicaciones por desbordamiento de memoria. delPropiedadbinariaEntidad(), que llamar a la funcin delPropiedadbinariaEntidad() a o de la fachada borrando el binario almacenado.
63
createEntidadMultipart(), cuya funcin es recuperar los atributos del regiso tro que se introduce en las pantallas de insercin o actualizacin, ya que o o en caso de haber binarios los formularios de dichas pantallas son de tipo multipart. La funcin createEntidad() no tiene en cuenta los campos o binarios. Tambin las funciones insertar() y actualizar() sufren cambios al aparecer e atributos binarios, puesto que se subirn por partes al servidor de bases de datos: a primero se almacenan los atributos no binarios, y luego se divide el binario en trozos y mediante la funcin appPropiedadbinariaEntidad de la fachada se env o an los fragmentos al servidor. Esta funcin optimiza la memoria consumida en el servidor de aplicaciones, o 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 seleccin de parmetros en el bloque funcional de generacin de cdigo de Geo a o o nereitor, aparecern por cada entidad secundaria funciones idnticas a las de la a e principal, pero incluirn el nombre de la entidad a la que ofrecen funcionalidad. a Por ejemplo, en el caso de Vehiculo, que es entidad relacionada de Propietario: insertar() corresponder a la insercin de una entidad Propietario, es decir, la a o entidad principal. insertarVehiculo() corresponder a la insercin de una entidad Vehiculo, es dea o cir, la entidad relacionada.
6.2.3.
Capa de lgica de negocio - Fachada o
Aunque los cheros de fachada ya se proporcionan con la generacin de o esqueleto, se van completando conforme se suceden las generaciones de cdigo o de las diferentes entidades de la base de datos. El paquete de cdigo generado para una entidad contiene dos trozos de la o fachada. En caso de que la aplicacin utilice EJBs: o 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 lgica de negocio de la aplicacin. o o 64
6.2.4.
Capa de lgica de negocio - Componentes o
Los componentes de la capa de lgica de negocio, ya sean EJB o POJO, o 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 la que interacte con la base de a u datos para obtener o modicar la informacin contenida en ella. o Tambin manejan la apertura y clausura de las instancias de la conexin con e o el servidor de bases de datos, y de ser necesario, implementan soporte transaccional para dichas conexiones. La gestin transaccional garantiza que la base de datos va a mantener siemo pre un estado ntegro y consistente, de manera que si falla la ejecucin de una o operacin, se devuelve la base de datos al estado inmediatamente anterior al o comienzo de la ejecucin de dicha operacin (rollback ), de modo que no queden o o operaciones a medias que pongan en peligro la integridad de la base de datos. Las operaciones implementadas en dichos componentes sern, para cada ena tidad 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 parmetro se le a 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 una a excepcin. o getListaEntidad(): Llama a la capa de acceso a datos para que devuelva una lista de todos los registros contenidos en ella. Tambin se puede pasar e un ltro del tipo de la entidad, para que devuelva slo los registros que o coincidan con los criterios que dicho ltro impone. deleteEntidad(): Llama a la funcin deleteListaEntidad() tras crear una lista de o un slo elemento, que ser el que tenga por clave primaria la del ltro o a recibido como parmetro. a deleteListaEntidad(): Elimina todos los registros de la base de datos que coincidan con los criterios establecidos por el ltro que se recibe como parmetro. a Este ltro no tiene por qu poseer un valor de clave primaria. e insertEntidad(): Llama a la capa de acceso a datos para que inserte el registro que corresponde al ltro que se recibe como parmetro. Si la clave pria maria de la entidad es unica y numrica, retornar el valor de la clave e a primaria que la capa de acceso a datos ha asignado al registro, ya que se asumir autonumrica. a e updateEntidad(): Llama a la capa de acceso a datos para que actualice el registro con clave primaria la del ltro que recibe como parmetro, con los a atributos de dicho ltro. Gestin transaccional y de conexiones: o beginTransaction(): marca el comienzo de la transaccin (slo EJB). o o commitTransaction(): naliza y conrma el xito de la transaccin (slo e o o EJB). 65
rollbackTransaction(): devuelve la transaccin al estado que ten al hao a cer beginTransaction() (slo EJB). o getConnection(): abre una conexin con la base de datos. o closeConnection(): naliza la conexin. o En caso de que la entidad contenga campos binarios, se proporcionan adems: a 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 parmetro. a getPropiedadbinariaEntidad(): Consulta a la capa de acceso a datos el contenido del binario almacenado en la propiedad correspondiente a esta funcin. o deletePropiedadbinariaEntidad(): Llama a la capa de acceso a datos para que elimine el binario almacenado en la propiedad correspondiente.
6.2.5.
Capa de lgica de negocio - Excepciones o
Para cada entidad sobre la que se genera cdigo, se proporciona tambin o e la implementacin de sus excepciones. Evidentemente, dicha implementacin o o ser muy bsica, puesto que no se pueden conocer de forma automtica las a a a situaciones en las que la entidad podr causar excepciones, ni qu desea hacer a e el programador para manejarlas. Por ejemplo, la implementacin de la excepcin para una entidad Catlogo o o a ser la siguiente: a
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 excepcin genrica, pero se contempla la posibilidad de personalizar su o e comportamiento.
6.2.6.
Capa de acceso a datos - Componentes
Las clases Java correspondientes a la capa de acceso a datos sern las ena cargadas de comunicarse con la base de datos, y contendrn las consultas o a modicaciones necesarias para realizar su tarea. Las funciones implementadas en la capa de acceso son llamadas por los componentes de la lgica de negocio (EJBs o POJOs), y hacen uso de la API o jdbc que proporciona J2EE para comunicarse con la base de datos. Implementan las siguientes funciones: getEntidad() a partir del ltro proporcionado, que habr de tener asignados al a 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 bsqueda que establece el ltro. u insertEntidad() inserta un registro de la entidad, con los valores del ltro. Si la entidad tiene clave primaria unica y numrica se asume que es auto e numrica, no se pasar valor para la clave primaria, sino que se recibir de e a a la base de datos al insertar el registro, asumiendo que el sistema de base de datos le asignar dicho valor al registro. El valor de la clave primaria a se devuelve al completar con xito la operacin. Si la clave primaria no es e o autonumrica, la funcin no devuelve nada. e o insertListaEntidad() esta funcin no se usa originalmente, simplemente admite o un BaseBeanSet de ltros y por cada elemento de dicho set, llama a la funcin insertEntidad(). o updateEntidad() actualiza el registro de la entidad con los valores del ltro. updateListaEntidad() esta funcin no se usa originalmente, simplemente admio te un BaseBeanSet de ltros y por cada elemento de dicho set, llama a la funcin updateEntidad(). o deleteEntidad() crea un BaseBeanSet de una posicin, que contendr el ltro o a que acepta como parmetro, y llama a deleteListaEntidad(). a deleteListaEntidad() borra los registros cuyas claves primarias coincidan con las de los ltros contenidos en el BaseBeanSet que acepta como parmetro. a Las funciones insertListaEntidad() y updateListaEntidad() no se utilizan en la aplicacin generada, puesto que los casos en los que se quiera insertar varios o registros en una misma operacin son escasos. De todos modos se ofrecen por si o en un futuro se decidiera dotar a la aplicacin de esta posibilidad. o
67
Tampoco se utiliza deleteEntidad(), ya que el borrado se suele hacer por lista de varios elementos, borrando los que el usuario seleccion en el listado de la o vista. Esta funcin se mantiene por si el desarrollador decide aadir la funcionao n lidad de borrado unitario. No obstante, dicha operacin se ejecuta actualmente o con deleteListaEntidad(), donde la lista ser de un unico elemento. a 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 aadirn las siguientes funciones: n a appendPropiedadbinariaEntidad() inserta en la base de datos el objeto binario en la propiedad de la entidad correspondiente, de manera que si el tamao total del binario excede de la longitud establecida (512kb por n defecto), aadir slo un trozo del chero. Esta funcin ser llamada ren a o o a currentemente 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 unica propiedad de la entidad, de manera que si sta contase con varias propiedades binarias, se generar las funciones e an 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 una implementacin diferente para cada entidad, tanto prina o cipal 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 aplicacin es Oracle o y se ha seleccionado PL/SQL como mtodo de acceso a datos, se generarn e a 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 ms de 30 caracteres. Por esto, a 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 mxima permitida. a Este proceso de recorte de los identicadores de funcin se representa en la o gura 6.3 en la pgina siguiente. a
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 funcin PL/SQL orio ginal ser APLICACION FN INSERT TABLA DE NOMBRE EXTREMADAMENTE LARGO, a donde: APLICACION ser el nombre de la aplicacin para la que se est generando el a o a cdigo PL/SQL. o FN indica que el cdigo que sigue corresponde a una funcin PL/SQL. En dicho o o lenguaje hay funciones y procedimientos, que se diferencian en que las primeras retornan un valor, mientras que los ultimos no. Un procedimiento se identicar con el literal PR. a INSERT es el identicador de la tarea que realiza esta funcin, en este caso o 69
insertar. TABLA DE NOMBRE EXTREMADAMENTE LARGO es el nombre de la tabla. Vemos que el identicador de la funcin generado excede de la longitud o mxima permitida, por lo que habr que recortarla. a a 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 suprimir los guiones bajos del nombre de la tabla: a 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 dejndolos con una longitud m a nima de tres caracteres: APLIC5 ACION10 FN I15 NSERT20 TABD25 ENOMB30 REEXT35 REMAD40 AMENT45 ELARG50 O, tras recortar ((TABLA)) convirtindolo en ((TAB)). ((DE)) e 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)) convirtindolo en ((NOM)). e Tras recortar todos los componentes: APLIC5 ACION10 FN I15 NSERT20 TABD25 ENOME30 XTLAR35 , 35 caracteres en total. Tras nalizar los recortes todav se excede la longitud permitida, por lo a que, como ultimo recurso, se trunca el nombre de la funcin hasta el mximo o a nmero de caracteres permitidos: u APLIC5 ACION10 FN I15 NSERT20 TABD25 ENOME30 , 30 caracteres en total, por lo que ya es una longitud vlida. a A partir de estos identicadores recortados se crear el cdigo necesario a o para generar el script PL/SQL que, una vez compilado en el servidor de bases de datos, se convertir en las funciones y procedimientos disponibles para realizar a el tratamiento de los datos. Las funciones y procedimientos generados son: GET ENTIDAD, funcin que recibe la clave primaria de la entidad y devuelve o todas sus propiedades. GET ENTIDADES, funcin que recibe un ltro del tipo de la entidad, y deo vuelve todos los registros que coinciden con los criterios de bsqueda esu tablecidos en el ltro. INSERT ENTIDAD, aade un registro del tipo de la entidad a la base de datos. n Dependiendo de si su clave primaria es autonumrica o no, ser funcin e a o y devolver el valor de la clave autonumrica del registro que se acaba de a e 70
aadir o procedimiento no devolver nada, puesto que la clave primaria n a ser proporcionada con el resto de parmetros de entrada. a a 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 parmetro. a Si la entidad para la que se est generando cdigo posee propiedades que a o almacenan objetos binarios (BLOB), para cada una de dichas propiedades se generarn tambin las siguientes funciones y procedimientos: a e a n APPBLOBn ENTIDAD, que ser el procedimiento encargado de aadir los trozos del chero binario al registro de la base de datos. o a GETBLOBn ENTIDAD, funcin que devolver el objeto binario almacenado 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 numerndolas (APPBLOB1 ENTIDAD a para el primer campo binario, APPBLOB2 ENTIDAD para el segundo, etc), en lugar de incluir el nombre de la propiedad sobre la que actan. Esto es debido a u la restriccin de 30 caracteres de Oracle. Por ello, antes de la implementacin de o o estas funciones se seala en forma de comentario a qu parmetro representan. n e a
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 estarn en consecuencia a representadas en el bean. Aparte de las propiedades que tiene la propia entidad en la base de datos, es comn que en la implementacin del bean aparezcan otras propiedades u o 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 pgina 21, se observa que en ambos casos hay funciones a (sealadas en negrita) que no se corresponden con ninguno de los parmetros n a de las tablas, sino que representan la relacin entre ambas (listaVeh o culos en propietario, y propietario en veh culo) Estas propiedades son en s mismas objetos dentro de los objetos, que sern utilizadas por la capa de lgica de negocio a o cuando se necesite analizar dichas relaciones entre tablas, pero no se utilizarn a 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 Catlogo: a 71
TALLER CATALOGO ID CATALOGO NUMBER ID VEHICULO NUMBER FOTOGRAFIA BLOB DESCRIPCION CLOB Sin embargo, se observan los siguientes parmetros en la implementacin del a o 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 sealan la tabla n que representa a esta entidad en la base de datos y la secuencia que le corresponde (es una tabla con clave primaria autonumrica), existen dos propiedades e extra, pathFotograa y lengthFotograa, cuyos valores no se almacenan en la base de datos, sino que son utilizados por la lgica de la apliacin para desempear o o n diferentes funciones. Las funciones que implementa cada bean son las siguientes: Constructora vac inicializa un objeto del tipo la entidad correspondiente a: 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 sern: a 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
Generacin de script para o tablas maestras

Las tablas maestras son aquellas que unicamente contienen informacin res o pecto a la entidad a la que representan. Por tablas maestras se entienden tablas sencillas, que generalmente sern de tipo identicadorvalor y, en caso de mana tener alguna relacin con otra tabla, una clave ajena. o Por ejemplo, en el caso de la gura 7.1, las tablas unicamente 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: Conexin o
El primer paso para la elaboracin de las partes de cdigo correspondientes o o a una entidad de la base de datos es la conexin al servidor de bases de datos. o Por ello, la primera fase de este bloque funcional es la introduccin de los datos o de conexin: o Sistema de bases de datos (lista desplegable con todos los sistemas de bases de datos soportados por la herramienta). 74
CAP ITULO 7. GENERACION DE SCRIPT PARA TABLAS MAESTRAS
Host. Puerto. SID, o nombre de la base de datos. Usuario. Contrasea. n Tambin se proporciona un pulsador con el literal ((Default)), cuya funcin e o es autocompletar el siguiente bloque con los datos de conexin de las bases de o datos de desarrollo que hay en la factor de software de la empresa, segn el a u 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 botn ((Conectar)), se realizan una serie de validaciones mediante o 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 numrico y no nulo. e Si no se introduce un valor para el campo contrasea, se avisa al usuario n mediante un mensaje junto al botn ((Conectar)), y se hace parpadear o brevemente dicho campo para llamar su atencin. Si se vuelve a pulsar el o botn ((Conectar)) se lanzar efectivamente la conexin contra el servidor, o a o indiferentemente de que se haya introducido una contrasea. n Si existe algn error en los datos se informar al usuario mediante una caja u a de texto situada al principio de la pgina. De lo contrario, se lanzar la conexin a a o al servidor. Es posible que los datos introducidos, pese a tener un formato vlido, no sean a correctos y el servidor de bases de datos no responda o rechace la conexin. De o ser as se informar nuevamente al usuario del error y se le permitir modicar , a a los datos introducidos para volver a lanzar la conexin1 . o
7.1.2.
Fase 2: Seleccin de tablas o
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 sern aadidas al seleccionarlas a la otra lista. El programador podr aadir a n a n tantas tablas como considere necesarias.
1 Debido a que algunos sistemas de bases de datos ofrecen ms informacin que otros cuando a o ocurre un error en la conexin, dependiendo del sistema elegido los textos explicativos del error o sern ms o menos espec a a cos. Por ejemplo, mientras que un sistema puede devolver un error de tipo usuario no vlido, otro lanzar simplemente error en la conexin. a a o
75
Al pulsar el botn ((Siguiente)), se analizan las claves ajenas de las tablas o seleccionadas, y se aaden a la lista automticamente las tablas que son refen a renciadas por las que el usuario ha seleccionado. Por ejemplo, si en la aplicacin Taller (gura 4.3 en la pgina 41) se seleccioo a n an a nase la tabla TALLER RECLAMACION, se aadir automticamente las tablas TALLER REPARACION, TALLER OPERACION, TALLER PIEZA, TALLER VEHICULO y TALLER PROPIETARIO, conforme al esquema 7.2.
Figura 7.2: Tablas aadidas automticamente por sus relaciones. n a
7.1.3.
Fase 3: Seleccin de campos o
En esta ultima etapa se seleccionarn los campos que aparecern en la inter a a faz generada por tablas maestras en diversos apartados, tales como el buscador, la vista de edicin o la de detalle. Consta de varios bloques. o En el primer bloque se introducirn el nombre de aplicacin y el del paquete a o 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 permitirn personalizar la interfaz generada por la aplicacin tablas a o maestras. Dichas opciones son: Campo por defecto: Para cada entidad se ha de seleccionar un campo por defecto, que ser el campo por el que los listados iniciales aparecern a a 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 sita el puntero del u ratn sobre este campo, aparece un tooltip (mediante el tag tooltip de o 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 restriccin de obligatoriedad activada en la o base de datos. De no ser as se permite establecer dicha restriccin a nivel , o de aplicacin. Si se pulsa en el literal de la cabecera de esta columna se o activa o desactiva esta opcin para todos los campos de la tabla. o Literal: Es el texto que acompaar a las casillas de los formularios generados n a por la aplicacin tablas maestras. Por defecto se ofrece el nombre del campo o transcrito a formato Java (ID PROPIETARIO idPropietario). Listado: Permite seleccionar qu campos aparecern en la vista de listado. Si e a se activa o desactiva la casilla de la cabecera de la tabla, se activan o desactivan todos los campos de la tabla para dicha opcin. Al activarse o un campo, aparece un valor en la columna ((Idx)), que representa el orden de aparicin de los campos en la lista. Dicho orden se puede modicar, o tarea que se llevar a cabo arrastrando y soltando con el ratn las las a o 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 actualizarn. a Ord: Esta opcin slo est activa para los campos que se han seleccionado o o a para aparecer en el listado, e indica si se ofrecer la posibilidad de ordenar a dicho listado por cada campo en particular. Al seleccionar un campo para listado, se activa esta opcin por defecto. o Buscador: Indica los campos que aparecern en el formulario de buscador. a Idx: Indica la posicin en la que aparecern los campos del formulario de buso a cador. El orden se establece al seleccionar los campos de forma secuencial, es decir, el primero en seleccionarse recibir el valor 1, el segundo el 2, etc. a MaxL: Indica la longitud mxima que aceptar la casilla de buscador para a a cada campo. Detalle: Indica los campos que aparecern en el formulario de detalle. a Idx: Indica la posicin en la que aparecern los campos del formulario de detao a lle. El orden se establece al seleccionar los campos de forma secuencial, es decir, el primero en seleccionarse recibir el valor 1, el segundo el 2, etc. a MaxL: Indica la longitud mxima que aceptar la casilla de detalle para cada a a campo. Claves Ajenas: En esta columna slo aparecern opciones para los campos o a que sean clave ajena de alguna otra tabla. La casilla permite indicar que se desea tener en cuenta la relacin entre tablas. Para los campos que o formen parte de una misma relacin, estas opciones funcionarn de manera o a paralela, es decir, al activar el usuario un campo, automticamente se a activarn todos los que forman parte de dicha clave ajena. a ?: Al poner el cursor del ratn sobre este pequeo literal se mostrar, por medio o n a de un tooltip, la tabla y el campo a los que hacen referencia cada clave ajena, a modo informativo.
77
Campo: Este ultimo 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 cdigos o campos autonumricos que no aportan un sigo e nicado claro al usuario, por ello es mejor describir la tabla relacionada por un campo ms descriptivo. Por ejemplo, si hubiera una tabla relacioa nada ((persona)), ser ms intuitivo mostrar el valor del campo ((nombre)) a a que el ((nif)), aunque este ultimo fuera la clave primaria que realmente es referenciada. Tambin para cada tabla se establece un nombre, que dar t e a tulo a las vistas de edicin, detalle, buscador y edicin de cada entidad. o o
7.2.
Resultado
El paquete obtenido al pulsar el botn ((generar)) contiene los siguientes o archivos:
7.2.1.
Script para tablas maestras
Es un chero XML que, en combinacin con la aplicacin tablas maestras de o o la empresa, generar la lgica necesaria para tratar las tablas maestras de la a o aplicacin. o Los motivos de utilizar este sistema y no generar un paquete para cada entidad mediante la funcionalidad de generacin de cdigo son que las tablas o o maestras son muy sencillas, por lo que con este sistema se reutilizan muchos componentes cuya implementacin resultar redundante si se implementaran o a de otro modo. As las tablas comunes compartirn la vista, puesto que harn uso de los , a a mismos JSP de listado, bsqueda, edicin y detalle, tendrn un unico compou o a nente (EJB o POJO) en la capa de aplicacin y un unico servlet en la capa o web. El script obtenido para las tablas COMUNIDAD AUTONOMA, PROVINCIA y MUNICIPIO vistas en la gura 7.1 en la pgina 74 ser el siguiente: a a
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 noma " id = " o 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 el signicado de cada parmetro de este chero: a a

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 noma " id =" o APLICACION_COMUNIDAD_AUTONOMA ">
Esta l nea indica el comienzo de la descripcin de una tabla. Los parmetros o a que aparecen son los siguientes: clase indica que las entidades de esta tabla estn implementadas en el objeto a com.comex.aplicacion.dal.bean.ComunidadAutonoma. campoPorDefecto indica que la ordenacin bsica ser por el campo NOMo a a BRE.
79
nombre indica qu literal aparecer en la aplicacin como t e a o tulo de las vistas que hagan referencia a esta entidad. Ntese que hay un espacio y una o tilde en la letra ((o)), lo que indica que dicho campo fue modicado por el programador en el formulario de seleccin de campos de Genereitor. Este o valor es la forma de referirse a la entidad que utilizar la vista. a 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 descripcin de un campo de la tabla. o 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 referido en la vista este campo, los a encabezados de los listados y los literales que acompaen a las casillas que n 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 en las vistas de listado de la entidad. a buscador indica si, adems de en el listado, aparecer en el buscador, ofreciena a do 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 tamao que tendr la columna del buscador correspondiente a n a este campo. Este valor tendr que ser modicado a posteriori por el proa gramador, puesto que es dif saber el tamao exacto que corresponder a cil n a cada columna en el momento de la generacin. o indice indica la posicin en la tabla de listados de este campo. o
< buscador maxLength ="22" size ="100" indice ="1"/ >
Esta l nea indica los parmetros del buscador, en caso de que el campo deba a aparecer en dicha vista.
80
maxLength indica la longitud mxima que aceptar la casilla de bsqueda. a a u size indica el tamao que tendr la casilla. Este valor tendr que ser modicado n a a a posteriori por el programador, puesto que es dif saber el tamao cil n exacto que corresponder a la casilla dentro del formulario de bsqueda. a u indice indica la posicin en el formulario de bsqueda de este campo. o u
< detalle maxLength ="22" size ="100" indice ="2"/ >
Esta l nea indica los parmetros de la vista detalle, en caso de que el campo a deba aparecer en dicha vista. maxLength indica la longitud mxima que aceptar la casilla de edicin/dea a o talle. size indica el tamao que tendr la casilla. Este valor tendr que ser modican a a do a posteriori por el programador, puesto que es dif saber el tamao cil n exacto que corresponder a la casilla dentro del formulario de edicin/dea o talle. indice indica la posicin en el formulario de edicin/detalle de este campo. o o
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 en el listado de la tabla que estaa mos tratando referenciando a la relacionada. En este caso, aunque la clave primaria de PROVINCIA sea ID PROVINCIA, en el listado de MUNICIPIO aparecer el nombre de la provincia en lugar del identicador, puesto a que el nombre ofrece ms informacin al usuario. a o
81
7.2.2.
Beans
Al igual que en el bloque funcional de generacin de cdigo, se proporcionan o o 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 seccin o de generacin de cdigo (ver apartado 6.2.8 en la pgina 71), aunque ofrecen o o a 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 pgina 74), tomaremos el bean Provincia, ya que a posee tanto claves ajenas que referencian a COMUNIDAD AUTONOMA como referencias desde MUNICIPIO. De esto se deduce que el objeto Provincia pertenecer a una ComunidadAua tonoma, por lo que poseer un atributo que almacenar la clave primaria que a a referencia a dicha entidad. Pero tambin habr una serie de objetos de tipo e a Municipio que harn referencia al objeto Provincia, por lo que el bean correspona diente implementar un nuevo atributo, que representar el listado de objetos a a Municipio que pertenecen a esta Provincia. As los atributos del bean Provincia sern: , a
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 en la generacin de cdigo, y otro a o o atributo de tipo BaseBeanSet que almacenar el conjunto de elementos de tipo a Municipio que pertenecen a la Provincia. Por ultimo, tambin se implementan en el bean los mtodos get() y set() de e e todos los atributos, al igual que los beans devueltos con generacin de cdigo. o o
82
Parte IV
Implementacin de o Genereitor
83
Genereitor se ha implementado siguiendo las pautas de la especicacin J2EE, o con una arquitectura de 1+2+1 capas, tal como indica la gura 7.3. En el cap tulo 4 en la pgina 34 se ha analizado la arquitectura de una a aplicacin J2EE, por lo que ahora se analizar la forma en la que se ha llevado o a a cabo la implementacin del proyecto. o
Figura 7.3: Estructura lgica de Genereitor o
84
Cap tulo 8
Capa web
La capa de presentacin de Genereitor se basa en pginas web HTML geo a neradas dinmicamente con JSP, que incorporan validaciones JavaScript para a los formularios de introduccin de datos y que comprueban que los datos sean o correctos en el lado del cliente, de forma que se evitan conexiones innecesarias o con datos incorrectos al servidor de aplicaciones. Tambin es una parte fundamental de la capa de presentacin el navegador e o web, que cumple la funcin de interpretar, renderizar y presentar la interfaz de o usuario. Usar un navegador web estndar se traduce en un ahorro de tiempo a de trabajo, puesto que no es necesario implementar una interfaz completa, y garantiza el acceso a cualquier cliente, puesto que la gran mayor de sistemas a actuales incorpora al menos un navegador en su conguracin por defecto. o
8.1.
JSP
La capa de presentacin se ha implementado mediante JSP, que posibilita o el uso de Java en pginas HTML para dotarlas de contenido dinmico. Tras la a a ejecucin de un JSP, al usuario (el programador en este caso) se le presenta, o v navegador, una pgina HTML que representar la interfaz. En C.2 en la a a a pgina 153 se ofrece una explicacin de la tecnolog JSP. a o a Las diversas pantallas que se le presentan al usuario consisten en formularios que ste habr de rellenar segn la accin que desee realizar, enviando los datos e a u o 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 que permite a los desarrolladores y diseadores web a n implementar y desarrollar rpida y fcilmente pginas web dinmicas. Estas a a a a aplicaciones son multiplataforma. JSP separa el diseo de la interfaz de usuario n de la generacin de contenidos, lo que posibilita que un diseador sin conoo n cimientos de la tecnolog sea capaz de modicar el aspecto de la pgina sin a a alterar los mecanismos de manejo y generacin de contenidos dinmicos. o a Presenta una serie de ventajas: 85
CAP ITULO 8. CAPA WEB
Se puede utilizar la tecnolog JSP sin necesidad de aprender Java, utilizana do la librer estndar de etiquetas (JSTL). Sin embargo, para aprovechar a a toda la potencia del sistema es aconsejable poseer conocimientos de Java. Es posible extender el lenguaje JSP mediante la implementacin de tags o personalizados, que ampl las funcionalidades de la librer estndar. en a a Las pginas que se generan son fciles de mantener, por la mencionada a a separacin entre diseo y generacin de contenidos. o n o La tecnolog JSP hace uso de tags al estilo de XML para encapsular la a lgica que genera el contenido de la pgina. Dicha lgica reside en los recursos o a o del servidor (un ejemplo es la arquitectura de componentes JavaBeans), cuyas funcionalidades sern accedidas por la pgina mediante estos tags o etiquetas. a a Esta tecnolog es una extensin de los Java Servlets, que son mdulos que a o o 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 o ptimo, separacin de lgica y presentacin y facilidad tanto de administracin o o o o como de uso. Dado lo complejo de algunos formularios, se ha implementado un control de errores mediante JavaScript, que permitir al usuario corregir cualquier error en a los datos introducidos antes de enviar la peticin al servidor. En caso de error, o antes de lanzar la conexin al servidor, se informa al usuario de los campos que o han de ser corregidos. Tambin se hace uso de varios tags, que facilitan la implementacin de las e o pginas JSP, permitiendo reutilizar cdigo y evitando tener que implementarlos a o cada vez que se utilicen. En la gura 8.1 en la pgina siguiente se presenta una pantalla de la interfaz a de Genereitor sealando varios de sus componentes y cmo se han creado. No n o se seala en el esquema, pero para la apariencia general de la interfaz se han n 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 pgina JSP ofreciendo diferentes funciones, de manera a que no es necesario implementarlas cada vez que se utilicen. Son capaces de aceptar parmetros, que sern obligatorios o no dependiendo de la manera en a a que est el tag implementado. e La tecnolog J2EE permite al programador implementar tags personalizados a conforme a sus necesidades, expandiendo las posibilidades del lenguaje HTML. De esta manera es posible implementar un tag ((lista)) que incluya en la pgina a generada con el JSP un listado con ciertas caracter sticas, que recibir como a parmetro el conjunto de datos a listar y otras opciones, de manera que podemos a utilizar dicho tag para generar listas en toda nuestra aplicacin implementando o 86
Figura 8.1: Diversas tecnolog utilizadas en la interfaz de Genereitor. as
tanto la lgica como la apariencia de dicha lista una sla vez. En cada pgina o o a que se utilice la lista, unicamente ser necesario incluir su llamada (tag). a Un ejemplo trivial de tag podr ser el siguiente: a 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 una imagen de cabecera al principio de la pgina y a a un link de contacto al nal, de forma que se podr utilizar englobando todo el a contenido de cada JSP para que todas las pginas compartieran dicha cabecera a e informacin de contacto, sin tener que inclu en cada chero. Un ejemplo o rlo de uso ser el siguiente: a
87
Listing 8.2: Pgina JSP de ejemplo a

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 gina </ title > a </ head > < body > < ejemplos : cabecera > ... Contenidos ... </ ejemplos : cabecera > </ body > </ html >
Vemos que la primera l nea de este ultimo fragmento hace referencia a un chero ejemplos.tld. Dicho chero contiene las descripciones de todos los tags disponibles en la aplicacin, de manera que el servidor de aplicaciones conozca o cmo han de ser interpretados y a qu clases corresponden dentro de la impleo e mentacin de la interfaz. o En dichos descriptores se reejan los siguientes parmetros: a Nombre del tag. Clase que implementa el tag. Atributos aceptados, obligatoriedad de stos y si son capaces de averiguar e sus valores en tiempo de ejecucin. o Informacin o aclaraciones. o En caso de que contenga cuerpo, se puede indicar a modo informativo qu ha de contener dicho cuerpo. e Un descriptor de tags correspondiente al tag ((cabecera)) anteriormente descrito ser el siguiente: a 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 pgina, puesto que a la hora de hacer a modicaciones (e.g. traducir la aplicacin) slo se ha de actualizar el archivo de o o etiquetas, en lugar de cada una de las pginas. a Uso de EtiquetaTag:
<comex:etiqueta clave="clave"/>
clave (Obligatorio) : es el cdigo que identica a cada etiqueta en el o chero etiquetas.properties.
Es importante destacar que el uso de este tag facilita enormemente la internacionalizacin de la aplicacin: se pueden mantener varios cheros de etiquetas, o o uno por cada idioma, y permitir al usuario que seleccione el idioma de su preferencia. De este modo mantenemos la misma implementacin de los JSP, siendo o 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 aadir un campo a una lista, se elimina automticamente de la otra. n a Uso de ListaDobleTag:
<comex:listadoble id="id" lista="lista" orden=orden/>
id (Obligatorio): el ID que tendr la lista doble dentro del JSP. a 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 sern: a 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 imgenes, una para cada botn, que han de estar a o situadas en las rutas: a o ((contexto))/img/arrow rigth.gif, que ser el botn para pasar elementos de la lista de elementos disponibles a la de elementos seleccionados. ((contexto))/img/erase.gif, que ser el botn para eliminar elementos de la a o lista de seleccionados. 8.1.1.3. <genereitor:tooltip>
Permite aadir etiquetas informativas sobre campos de texto, especialmente n util cuando no existe mucho espacio disponible en la pgina (e.g. tablas de gran a envergadura) y se han de usar abreviaturas o no es posible mostrar directamente toda la informacin necesaria. o Uso de TooltipTag:
<genereitor:tooltip texto="texto" tooltip="tooltip" long="longitud"/>
texto (obligatorio): es el texto que se mostrar por defecto en la pgina. a a 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 mostrarn a en la pgina. Si el contenido de texto es de longitud inferior a este a campo y no se ha especicado tooltip, no se mostrar etiqueta al a pasar el puntero sobre el texto. Si la sobrepasa, cortar el texto a los a long primeros caracteres, seguidos de ((...)), y se mostrar el contenido a entero de texto en la etiqueta. Los tres campos soportan expresiones en request-time.
Se puede personalizar la apariencia de la etiqueta deniendo los styles siguientes: .tooltiptag .tooltiptagHover .tooltiptag span .tooltiptagHover span
90
8.1.1.4.
<genereitor:contenedor>
Proporciona el contenedor base para la interfaz grca, que ser la misma a a en todos los apartados: Fondo. Barra de t tulo. Barra de men superior. u Barra inferior. As mismo inicia y termina un formulario, dado que cada pgina del generador a va a constar de un unico formulario, de id formulario y mtodo post, cuyos e campos irn inclu a dos entre las etiquetas del tag en cada pgina. a Tambin proporciona una caja de contenido para mostrar errores de conee xin, validacin de datos, informacin adicional o advertencias. o o o Para mostrar u ocultar esta ventana existen dos funciones Javascript: showbox("tipo",mensaje);, que al ejecutarse har visible la caja de informaa cin, mostrando un icono segn el primer parmetro (cuyos valores pueden o u a ser ((info)) y ((error))) y el mensaje. Si el primer parmetro no coincide a con los valores sealados, no se muestra ningn icono. Tras esto, va al n u inicio de la pgina. a hidebox(); Oculta la caja de informacin. o En la barra de men superior se ubican los enlaces a las cuatro partes del u generador: generacin de esqueleto, de script de tablas maestras, de cdigo y o o ajustes. Para cada uno de estos cuatro enlaces, se requieren las siguientes etiquetas en el etiquetas.properties: boton.esqueleto boton.script boton.codigo Tambin necesita las siguientes imgenes: e a ((contexto))/imagenes/img pie.jpg: imagen del pie de pgina. a ((contexto))/imagenes/icono ok.gif: icono de conrmacin para la infobox. o ((contexto))/imagenes/icono error.gif: icono de error para la infobox. ((contexto))/imagenes/g.ico: icono que aparecer en la barra de direcciones a (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 pgina visitada, y en la lista de favoritos en caso de a a adir tal direccin. n o
91
Y los siguientes estilos: #contenedor general, que dene el estilo general del cuerpo de la pgina (fnd body.gif). a #cabecera, que dene la cabecera de la pgina (img cabecera.jpg). a #contenedor, que dene el estilo del contenedor de la pgina. a #navegador top, que dene el estilo de la barra de men superior (fnd navtop.gif). u .opcion navtop, estilo de cada opcin del men superior. o u .navtop, aspecto de los botones del men superior. u .navtop:hover, aspecto de los botones del men superior al pasar el u puntero sobre ellos. #pie, que dene el estilo del pie de pgina (fnd pie.gif). a Uso de ContenedorTag:
<genereitor:contenedor accion="accion"> . . . </genereitor:contenedor>
accion (Opcional): dene la accin del formulario. o
8.1.1.5.
<genereitor:boton>
Tag que permite la inclusin de botones en la web. o Uso de BotonTag:

<genereitor:boton valor="valor" ancho=ancho/>
valor (Obligatorio): dene el texto que llevar el botn. a o id (Opcional ): dene el id del botn dentro de la pgina. o a javascript (Opcional ): dene una funcin Javascript asociada al o botn. o onclick (Opcional ): dene un evento al hacer click sobre el botn. o href (Opcional ): dene un enlace para el botn. o orden (Opcional ): dene el orden del botn en la pgina. o a
92
ancho (Opcional ): dene el ancho del botn (1, 2 3). o o css (Opcional ): permite establecer un estilo para el botn. o enabled (Opcional ): permite activar o desactivar el botn. o title (Opcional ): dene el t tulo del botn. o Todos los campos soportan expresiones en request-time excepto id.
8.1.2.
JavaScript
Parte de la interfaz grca de Genereitor consta de varios formularios gea nerados de forma dinmica conforme a los metadatos de las tablas de la base a de datos contra la que se est trabajando. Segn las caracter a u sticas de dichas tablas, es comn que se presenten al usuario formularios con gran cantidad de u 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 conexin: o Los campos host, SID y usuario no se encuentren vac os. El campo puerto no se encuentre vac y sea un campo numrico o e vlido. a El campo contrasea, en caso de estar vac se advertir al usuario n o, a mediante un mensaje junto al botn de conectar de tal situacin, y o o el campo contrasea parpadear brevemente. Si se vuelve a pulsar el n a botn conectar, se enviar la conexin al servidor con la contrasea o a o n vac puesto que es posible que exista acceso sin contrasea. a, n En los formularios de seleccin de campos de tabla, que haya por lo menos o un campo sealado como campo de ordenacin por defecto para cada n o tabla. En el formulario de seleccin de campos de tabla del bloque funcional de o generacin de script de tablas maestras, se comprobar que haya por lo o a menos un campo para buscador, un campo para detalle y un campo para listado en cada tabla. Que ningn campo de nombre de bean, alias de campo, nombre de apliu cacin, paquete base o longitud mxima de campo est vac o a e o. Que todos los campos de longitud mxima sean de tipo numrico. a e
93
En caso de incumplirse alguna de las anteriores condiciones, se retorna al comienzo de la pgina (en caso de que la misma supere la altura de la ventana del a navegador), y se muestra una cabecera informando de cada error sucedido, de forma que sean fcilmente localizables para el usuario. Los datos introducidos a 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 lana zar la conexin al servidor de aplicaciones, que recoger toda la informacin o a o 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 mucho tiema po recargando la interfaz en cada vericacin, puesto que se tendr que enviar o an 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 el usuario son vlidos. a a
8.1.3.
CSS
Cascading Style Sheets (hojas de estilo en cascada) es un lenguaje utilizado para denir la presentacin de un documento escrito en HTML o XML. Esto o establece una separacin completa entre contenido y presentacin. Con CSS se o o denen colores, tipograf capas, mrgenes y otros aspectos de la presentacin as, a o del documento. Esta separacin proporciona una ventaja en cuanto a la accesibilidad de los o 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 mens o elementos al mrgen, para lograr copias impresas de calidad. u a Una con tipograf grandes y colores de alto contraste, para facilitar el as acceso a los contenidos a personas con dicultades o problemas visuales. As las ventajas que ofrece son: , Centraliza el control de la presentacin de un sitio web completo con un o slo chero de estilos, lo que mantiene la concordancia entre la apariencia o 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, segn el dispositivo u mostrado (ordenador, pda, pgina para imprimir). a 94
El cdigo HTML es ms claro de entender y se reduce su tamao, al exo a n ternalizar las deniciones de estilo. Por ultimo, conviene destacar que CSS es un estndar de W3C. Tanto Gene a reitor como las interfaces que genera utilizan hojas de estilo correspondientes a la versin 2.12 de CSS. o
8.2.
Servlets
Bajo JSP y las diferentes tecnolog que lo complementan, explicadas en el as apartado anterior, se encuentran los servlets, y que dentro del patrn estructural o de modelo-vista-controlador realizan la funcin de controlador. o Los servlets hacen de intermediarios entre la vista y el modelo, al ser ms a verstiles que JSP para esta funcin al estar escritos como clases Java normales, a o evitando de esta forma mezclar cdigo visual (HTML, XML) con cdigo Java, o o delegando a JSP unicamente la funcin de componer la interfaz visual. Cada o v nculo en la interfaz web se corresponde con una accin de un servlet. o Los servlets tienen una funcin perform(), que es la encargada de recibir la o peticin del usuario que llega de la interfaz, y dirigir la ejecucin hacia la funcin o o o 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
especicacin de CSS 2.1 puede ser consultada en http://www.w3.org/TR/CSS21/. o
95
8.2.1.
InicioAction.java
Este primer servlet es el ms sencillo de todos, y es el encargado de cargar a la pgina de bienvenida a Genereitor, que dar acceso a las secciones correspona a dientes a los tres bloques funcionales, los cuales cuentan con un servlet dedicado para cada uno. Unicamente cuenta con dos funciones: perform, que ser la encargada de a consultar la peticin del usuario que le llega desde la vista y dirigirla hacia la o funcin correspondiente, e inicio, que llama a la vista para que muestre la interfaz o 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 mtodos que implementa. e 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 mostrarn. a Operacin de conexin. Esta operacin es comn a los tres bloques funcioo o o u nales4 , por lo que se implementa en este servlet para no repetir dicha funcin en los servlets correspondientes a cada bloque. o Recoleccin de datos de conexin: Se encarga de recoger los datos de la o o conexin de los formularios. Dado que dichos datos son comunes a las tres, o la funcin encargada de dicha tarea se implementa. o Compresin: Tambin aqu se implementa la funcin que crea en el servidor o e o el chero comprimido que se devolver al usuario al nal de cada ejecucin a o de todos los bloques funcionales. Llamadas a la lgica de la aplicacin: Son las funciones que recolectan los o o datos devueltos por la lgica de la aplicacin: o o 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 conexin contra un servidor web, siempre se busca el chero index.htm, o index.php o similar. En este caso existe un index.jsp, que unicamente contiene una redireccin o hacia la accin inicio.inicio.do, que se encargar de llamar al controlador para que genere la o a vista inicial, contenida en el chero index2.jsp. 4 Si bien slo es necesaria una conexin con la base de datos en los bloques de generacin o o o de cdigo y script de tablas maestras, recordemos que se incluy la posibilidad de comprobar o o la conexin en la etapa de generacin de esqueleto, a n de vericar que los datos introducidos o o son correctos.
96
Recoleccin de datos de formularios: Funciones que recolectan los datos o introducidos en los formularios de la aplicacin y componen los nodos XML o de datos que luego sern combinados con las plantillas XSL para generar a los cheros que se devolvern posteriormente al usuario. a Creacin y borrado de temporales: Tanto los cheros generados como los o cheros que se contienen se almacenan durante la sesin en el servidor. o 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 generacin de esqueleto slo se compone de o o una etapa, el servlet correspondiente dispone unicamente de dos funciones de acceso pblico. u La primera se encargar de formar la vista que presentar al usuario el a a formulario de introduccin de los datos requeridos. o 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 comn (imgenes, hojas de estilo, pginas de error u a a genricas), empaquetarlos y devolverlos al usuario. e Para esto, el servlet llama a su clase superior, GenereitorBaseAction, aprovechando las funciones que implementa. Tambin subdivide el proceso en funciones recursivas para optimizar el cdie o go. Por ultimo, implementa una funcin conectar, que es simplemente una lla o mada a la funcin homnima de GenereitorBaseAction. o o
8.2.4.
CodigoAction.java
Este servlet implementa acciones para cada etapa de la que consta el bloque funcional de generacin de cdigo. o o 8.2.4.1. Inicio
Al igual que el anterior, la primera etapa cuenta con una funcin de inicio, o encargada de dibujar la interfaz de introduccin de los datos de conexin. o o 8.2.4.2. Conexin a la base de datos o
Esta funcin es una mera llamada a la funcin homnima de la clase superior, o o o GenereitorBaseAction, que lanza la conexin a la lgica de la aplicacin. o o o
97
8.2.4.3.
Seleccin de tabla o
Tras efectuar la conexin, la segunda opcin consulta a la fachada de la o o lgica de negocio para obtener un listado de todas las tablas existentes en la o base de datos, que se pasarn a la vista como parmetro de un tag lista, y se a a evaluar si dicha tabla posee alguna clave ajena. a Si se da el caso de que existen tablas cuya clave primaria sea una clave ajena de la tabla seleccionada, se presentar al usuario una lista de las tablas a relacionadas. Si no, este paso se omite. 8.2.4.4. Seleccin de tablas relacionadas o
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 parmetros de sesin, para su recuperacin posterior a la hora de generar a o o el paquete. 8.2.4.5. Seleccin de campos o
Tras la seleccin de tablas, se consulta a la lgica de la aplicacin los campos o o o de cada tabla que ha sido seleccionada, mostrndose una vista que permite al a usuario establecer los campos que desea que aparezcan en los listados de la aplicacin que se va a generar, as como las restricciones de obligatoriedad y o longitud mxima que aceptar. Tambin se permite modicar el nombre que a a e cada propiedad de las entidades de la tabla recibir al ser implementados como a objetos Java. Dicho listado ser generado dinmicamente con JSP. a a Tras conrmar que los datos introducidos son correctos, se almacenarn a como parmetros de sesin y se presentar al usuario la vista correspondiente a a o a la ultima etapa del proceso. 8.2.4.6. Seleccin de parmetros y generacin de paquete o a o
En esta fase se presenta nuevamente un formulario al usuario. Al pulsar el botn ((Generar)) se llama a la funcin homnima de este servlet, que se eno o o cargar de recolectar los parmetros de este ultimo formulario, as como los a a atributos almacenados en la sesin, para luego llamar a la funcin de Genereio o torBaseAction que convertir dichos parmetros en nodos de datos XML. Tras a a esto, crear la estructura de directorios necesaria para organizar los cheros que a formarn parte del paquete que se devolver al usuario y se combinarn, segn a a a u los parmetros introducidos, las plantillas XSL necesarias para generar dicho a paquete. Tras esto, se llama a la funcin ((comprimir)) de la clase superior, y se o devuelve el paquete al usuario. 98
Esta ultima etapa est descompuesta en varias funciones para hacerla ms a a modular, de forma que el mantenimiento de la aplicacin sea ms sencillo. o a
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 funcin de inicio, o encargada de dibujar la interfaz de introduccin de los datos de conexin. o o 8.2.5.2. Conexin a la base de datos o
Esta funcin llama a la funcin homnima de la clase superior, GenereitorBao o o seAction, que lanza la conexin a la lgica de la aplicacin. Tras esto, presenta o o o al usuario la vista de seleccin de tablas. o 8.2.5.3. Seleccin de tablas o
Tras recuperar las tablas que ha seleccionado el usuario, se aaden a la n lista automticamente todas las tablas referenciadas por las claves ajenas de las a seleccionadas, y se elabora la vista de seleccin de campos y las propiedades de o stos, que se presentar al usuario. e a 8.2.5.4. Seleccin de campos y generacin de paquete o o
Tras recopilar la informacin del formulario que acaba de rellenar el usuario, o se procede a elaborar los nodos XML que reunen toda la informacin necesaria, o y se combinan con las plantillas XSL oportunas para generar el paquete que contendr el script de tablas maestras y los beans correspondientes a las entidades a para las que se ha generado dicho script.
8.2.6.
ServletEscuchador.java
Este ultimo 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 generado en el servidor de aplicaciones para confeccionarlo, pero a dicho paquete comprimido todav no se ha borrado, puesto que la aplicacin a o 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 de transferir completamente. a
99
Por esto, es ste servlet el encargado de hacer esta ((limpieza)), vigilando el e tiempo de vida de las sesiones iniciadas en la aplicacin, y al momento de la o muerte de cada sesin, elimina los paquetes comprimidos correspondientes del o servidor de aplicaciones. De este modo no quedan residuos que, de otro modo, acabar por llenar la capacidad de almacenamiento del servidor que soporta an Genereitor.
8.3.
Otros
Aparte de los cheros mencionados hasta ahora, tambin forman parte de la e capa web diversos componentes que ofrecen varias utilidades: UtilesWEB.java: Este chero implementa una serie de utilidades estndar a que se usarn en los servlets, tales como validacin de campos numria o e cos, formateo de fechas, funciones conversoras de HTML a texto plano, comprobacin de fechas, etc. o ConstantesWEB.java: Aqu se recopilan diversos valores constantes que se utilizan en la aplicacin, como por ejemplo nombres de atributos de sesin. o o Slo se hallan aqu las constantes de propsito general, las espec o o cas de cada bloque funcional se declaran en el servlet correspondiente.
100
Cap tulo 9
Capa de lgica de negocio o

La lgica de negocio se implementa en Genereitor mediante POJOs (Plain o Old Java Objects), que son clases normales de Java. Hemos visto al analizar el funcionamiento de la arquitectura J2EE que sta proporciona la tecnolog EJB e a para implementar la capa de lgica de negocio. No obstante, para esta capa o Genereitor no requiere de la potencia ni caracter sticas de dicha tecnolog por a, lo que utilizando clases Java lograremos un diseo ms sencillo, a la vez que n a ahorraremos en recursos ya que no se requerir de un contenedor de EJBs para a ejecutarlo. As el unico componente que formar la capa de lgica de negocio ser Co, a o a nexion. Esto es debido a que realmente Genereitor no maneja datos, para la generacin de una aplicacin web es indiferente que la base de datos contra la que se o o trabaja contenga o no datos. Por contra, esta sencillez del diseo se ve truncada al enfrentarnos a la n necesidad de conectar a varios sistemas de bases de datos, por lo que tenemos que es necesario realizar una implementacin de la lgica de negocio para cada o o conexin. No obstante, todas las implementaciones compartirn fachada, de o a forma que esta diferencia sea transparente en cuanto a los componentes de las capas superiores. As la lgica de negocio, compuesta por el objeto Conexin, tiene las si, o o guientes funciones: conectar() lanza una conexin a la base de datos a partir de un ltro de tipo o conexion. Su unica funcin es comprobar que la conexin es correcta y que o o 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 informacin sobre las tablas que tienen por o clave primaria un campo que es clave ajena de la tabla sobre la que se trabaja. getClavesImportadas() devuelve informacin sobre las tablas que tienen por o clave ajena la clave primaria de la tabla sobre la que se trabaja. Es importante sealar que normalmente las aplicaciones que trabajan sobre n una base de datos almacenan los datos de conexin en un chero de datasources, o que almacena todos los datos de conexin. o Por la naturaleza de Genereitor, esto ser imposible, ya que es necesario que a sea capaz de conectarse a cualquier base de datos, cuyos parmetros de conexin a o sern introducidos por el usuario. As el tipo de objeto Conexion se utiliza para a , almacenar estos datos.
9.1.
Excepciones
La clase GenereitorException rene los cdigos de excepcin que Genereitor u o o manejar en caso de producirse cualquier error. A n de proporcionar la infora macin precisa de la causa de cada error, se denen una serie de cdigos de o o excepcin, que equivalen a diversos mensajes que se reejarn en el sistema de o a gestin de logs: o
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 vlidos, user a no vlido, pass no vlido). Esto es debido a que algunos sistemas de bases de a a datos hacen distinciones al lanzar una excepcin, hacindolo de manera ms o e a espec ca, mientras que otros informan de los errores de forma ms general. Los a cdigos de error que lanzan cada base de datos se consultan en los componentes o de la lgica de negocio de cada sistema, lanzando una GenereitorException acorde o al cdigo de la SQLException generada por el sistema de bases de datos. o
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 conexin a difereno tes 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 conexin con el sistema o 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 soportado el sistema de bases de datos no se puede realizar un anlisis del e a 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 unico1 . De este modo se consigue un desarrollo ms intui a tivo, al usar objetos ((completos)) en lugar de conjuntos de objetos ms simples. a Realmente no pertenecen a una capa espec ca, ya que estn disponibles a todos a los niveles de la aplicacin. o 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 ((conexin)). o Para explicar el funcionamiento de un bean, se presenta el ejemplo ms a sencillo de los utilizados. El bean conexion representa un objeto ((conexin)) cuyos atributos correso ponden a los que se introducen en las etapas de conexin a base de datos de o 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 especicacin de JavaBeans se puede consultar en http://java.sun.com/javase/ o 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 del objeto, que crear el objeto o a 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 mtodos: e 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 funcin Object podr adoptar o devolver valores nulos, mientras que la funcin o a o primaria devolver 0 en su lugar2 . a 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 especicacin comn a todos, a modo de fachada, de manera que para el resto o u de componentes de la aplicacin el acceso sea transparente. o
comportamiento se implementar seg n convenga. a u 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
Conclusin o
106
Cap tulo 11
Visin global del trabajo o realizado

Con Genereitor se ha conseguido elaborar una herramienta de generacin de o cdigo funcional y personalizada a los requerimientos de cada proyecto, ofrecieno do al programador la posibilidad de comenzar el desarrollo del mismo a partir de una aplicacin que ya funciona, y que dispone de mtodos estndar a todos o e a los niveles. Esta tarea, que sin la ayuda de Genereitor cuesta varios d es reas, suelta ahora en cuestin de 5 minutos, ofreciendo adems una implementacin o a o de calidad, respetando estndares y convenciones del lenguaje. a Para la implementacin de Genereitor se han utilizado tecnolog tales como o as J2EE, puesto que proveen de una estructura modular que facilita el desarrollo y el mantenimiento de la aplicacin, as como la adicin de nuevos mdulos y o o o componentes. La eleccin del desarrollo de la aplicacin en Java/J2EE ha sido tomada por o o diferentes motivos: Es una tecnolog muy utilizada para el desarrollo de aplicaciones web, a por lo que existe un gran soporte y mucha documentacin disponible. o Tiene mucho tiempo de experiencia en el sector, por lo que est muy desaa rrollada, 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 ms complicadas. as a Sirve como experiencia para el desarrollo de las plantillas de las aplicaciones que se generarn con Genereitor, que obligatoriamente han de estar a desarrolladas en esta tecnolog a. Se ha optado por utilizar en la medida de lo posible software libre y gratu por lo que el uso de J2EE se preere a tecnolog propietarias o con to, as
107
CAP ITULO 11. VISION GLOBAL DEL TRABAJO REALIZADO
licencias comerciales, tales como .Net. Por el mismo motivo, el servidor de aplicaciones sobre el que se desplegar Genereitor es Apache Tomcat1 a La entrada en produccin de Genereitor se ha llevado a cabo de forma proo gresiva, poniendo a disposicin de los programadores primero el mdulo de geo o neracin de script de tablas maestras en febrero, y los mdulos de generacin o o o de esqueleto y generacin de cdigo en abril. o o El proyecto actualmente tiene aproximadamente 1500 horas de desarrollo. En este tiempo van inclu dos los periodos de formacin en las tecnolog utilizadas, o as y la elaboracin del documento de anlisis y diseo previo a la implementacin o a n o de la aplicacin (disponible en el apndice A en la pgina 116). o e a
11.1.
Cambios en Genereitor durante su desarrollo
Aunque se elabor un documento de anlisis y diseo donde se redactaron o a n al detalle las caracter sticas que tendr Genereitor, durante la etapa de implea mentacin y pruebas se llevaron a cabo diversos cambios, bien debidos a modio caciones 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 slamente se iba a tener en cuenta un nivel de relaciones o entre las tablas para la generacin del script de tablas maestras, es decir, no se o tendr en cuenta las tablas relacionadas de las relacionadas. Adems, se iba a an a presentar al usuario una lista para la seleccin de las que considerase oportunas. o Pero una vez implementada la lgica que extra las relaciones de la base de o a datos, se lleg a la decisin de que era interesante tener en cuenta las relaciones o o entre las tablas a todos los niveles, puesto que es comn que las tablas maesu tras tengan varios niveles de relaciones. Un par de ejemplos que ilustran dicha situacin: o Pa Comunidad autnoma, Provincia, Comarca, Municipio... s, o En, era, per o odo, poca, edad... e Una era contiene varios per odos, que a su vez contienen varias pocas, etc. e Adems, se decidi eliminar la posibilidad de eleccin del usuario, agregando a o o automticamente todas las tablas relacionadas, porque comnmente se seleccioa u naban todas las tablas del rbol de relaciones, as que seleccionndolas todas a a
1 Con licencia Apache v2.0, cuyos trminos se pueden consultar en http://www.apache. e org/licenses/GPL-compatibility.html. 2 Cuando el desarrollo de Genereitor estaba avanzado, se abri el acceso a los programadores o del departamento de J2EE de la empresa, cuyo feedback aport nuevas ideas y propuestas de o soluciones a los problemas.
108
automticamente eliminamos la posibilidad de que el usuario por error olvide a seleccionar una tabla. Beans en tablas maestras Los beans son generados en la etapa de generacin de cdigo. No obstante, o o dicho bloque funcional slo tiene en cuenta automticamente las relaciones en un o a sentido, mientras que tablas maestras trabaja con relaciones en ambos sentidos (importadas y exportadas). Es por ello que se decidi proporcionar tambin los o e beans de las tablas maestras en esta bloque funcional, de forma que se doten automticamente de los atributos correspondientes a las relaciones de ambos a sentidos. En el ejemplo anterior, de las entidades en, era, per o odo, poca y edad, e un per odo pertenece a una era, por lo que el bean correspondiente poseer un a atributo era. Este atributo tambin es aadido por generacin de cdigo. e n o o Pero al mismo tiempo, un per odo tiene una serie de pocas, por lo que se e le aadir un atributo listaEpocas. n a PL/SQL En principio no se contempl la posibilidad de generar cdigo PL/SQL, o o pero tras comprobar que la mayor de los proyectos usaban esta tecnolog se a a, decidi dar soporte en la capa de acceso a datos, y proporcionar las funciones o PL/SQL que implementarn la capa de acceso a datos en el propio servidor de a bases de datos, liberando la carga de trabajo tanto al servidor de aplicaciones como a la red. Mdulos web o La opcin en generacin de esqueleto y generacin de cdigo que permite o o o o introducir varios mdulos web al principio no exist Se generaba automtio a. a camente el mdulo aplicacin-web y si el programador seleccionaba una casilla o o de ((generar mdulo de administracin)), se generaba tambin el mdulo aplicao o e o cin-webadmin. Pero al nal se decidi dar opcin de personalizar el nombre y o o o el nmero de los mdulos web. u o Listado de entidades relacionadas en la vista de edicin de la principal o En principio se generar vistas de edicin y detalle de manera indepenan o diente para todas las tablas, tanto la principal como las relacionadas. Luego se decidi aadir la opcin de incluir el listado de las tablas relacionadas en la o n o pantalla de edicin de la entidad principal, puesto que esta vista era usada con o 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 implementar las operaciones con binarios o 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 aplicacin y permite que, en caso de utilizarse reproductores o de medios (audio, v deo), el tiempo de carga del buer sea menor, al tener que descargar slamente una parte del archivo y comenzar a reproducirla mientras se o descargan las dems, en lugar de traer el chero completo y entonces comenzar a la reproduccin. o
11.2.
Conocimientos adquiridos
Con la elaboracin de Genereitor se han adquirido gran cantidad de conocio mientos, tanto relativos a tecnolog como a metodolog de trabajo. Algunas as as de estas son: Java: se ha adquirido gran experiencia en este lenguaje, del que al principio no se ten apenas conocimientos. a J2EE: se ha familiarizado con esta tecnolog para el desarrollo de aplicaciones a web, as como de las APIs que implementa, tales como conectores a bases de datos (jdbc), JavaServlets, JSP, gestin transaccional, etc. Tambin se o e han adquirido conocimientos de aplicaciones desarrolladas en capas, la divisin de tareas y modularidad de las aplicaciones. o Patrones de dise o de aplicaciones: tales como el Modelo-Vista-Controlador, n Facade, Filtro, Singleton o ServiceLocator. Tecnolog usadas en la web: se ha trabajado con HTML, JavaScript, CSS as o AJAX, tecnolog ampliamente usadas en los sistemas web actuales. as Bases de datos: tambin se ha trabajado con diversos sistemas de bases de e datos, ampliando los conocimientos que ya se pose sobre SQL, y adan quiriendo experiencia en administracin de bases de datos. Tambin se ha o e familiarizado con el uso de PL/SQL para bases de datos Oracle. XML y XSLT: como lenguajes de tratamiento de datos y conversin de plano tillas para creacin de mltiples documentos. o u
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
Administracin de bases de datos: Oracle SQLdeveloper 1.5, TOra. o Herramientas de construccin y despliegue: Apache Ant. o Sistemas de control de versiones: SVN.
A Documentacin: L TEX. o
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 pgina siguiente se presentan unos cuantos datos a numricos relativos a las plantillas utilizadas por Genereitor, as como de los e paquetes de datos que genera, que dan una visin aproximada de la cantidad de o cdigo que es utilizado para proporcionar dichos paquetes a la medida de cada o aplicacin. o
111
Esqueleto Cdigo o Tablas Maestras TOTALES
Nm. plantillas u 135 plantillas 28 plantillas 2 plantillas 165 plantillas
Datos de las plantillas L neas totales Tamao total Promedio l n 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 tamao/plantilla n 8,5 KiB/plantilla 14 KiB/plantilla 8,5 KiB/plantilla 9,3 KiB/plantilla
112 Datos de los paquetes generados L neas totales Tamao total Promedio l n 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 Cdigob o Tablas Maestrasc
Nm. archivos u 116 archivos 18 archivos 4 archivos
Promedio tamao/archivo n 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 imgenes ni librer a as. datos se han tomado analizando el paquete generado para una sla tabla de 5 campos. o 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 diseo y desarrollo de Genereitor siempre se tuvo en n cuenta que no iba a ser una herramienta ((denitiva)), sino que por el contrario estar siempre sometida a labores de mantenimiento, que correspondern con a a los cambios en los requisitos y las exigencias de los clientes, y la futura adopcin o de nuevas tecnolog o actualizacin de versiones de las utilizadas actualmenas o te, por lo que habr que adecuar el funcionamiento de Genereitor a las nuevas a 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.
Adicin de nuevas caracter o 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 necesario ima plementar su capa de acceso a datos (recordemos que existe una fachada comn u a todos, pero una implementacin para cada uno, puesto que son manejados o de manera diferente) y los componentes que manejan su conexin. Tambin se o e habr de aadir dicho sistema de bases de datos al seleccionable de los formua n larios de la interfaz correspondientes a las vistas de conexin. o Al implementar Genereitor se ha tenido en cuenta la posibilidad de que en un futuro sea necesario aadir, por lo que se ha hecho especial hincapi en la n e modularidad de la gestin de los diferentes sistemas de bases de datos. Por ejemo plo, 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 aadir soporte para un sistema de bases de datos nuevo, se podr copiar la n a 113
CAP ITULO 12. TRABAJO FUTURO
implementacin de uno ya existente y modicarlo segn convenga, de manera o u 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 implementacin del soporte para el nuevo. o 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 una tarea trivial, unicamente siendo necesaria a la adicin de un enlace en el tag contenedor para que apareciera un botn en la o o barra superior que llevase hasta la nueva funcionalidad, y una vez implementada la capa de aplicacin del nuevo mdulo, la compilacin y el despliegue se har o o o a de forma automtica. a El nuevo bloque funcional dispondr de las funcionalidades implementadas a para la capa de acceso a datos, con lo que podr acceder de forma transparente a a diversos sistemas de bases de datos, y utilizar los objetos Conexion, Tabla y Columna. Tambin contar con la coleccin de custom tags y estilos para e a o implementar las vistas de la interfaz, de forma que la apariencia del nuevo bloque funcional fuera similar al resto de la aplicacin. o
12.1.2.
Mantenimiento y modicacin de los proyectos geo nerados.
Todos los cheros fuente se generan a partir de plantillas XSL, de forma que cualquier modicacin en los requisitos de los proyectos a generar que imo plique una modicacin en el cdigo fuente, se aplicar directamente sobre las o o a 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 aplicacin, bien o de los parmetros introducidos por el programador en la interfaz de Genereitor. a Estas cadenas estn diseadas con XML, teniendo los parmetros de cada nodo a n a nombres intuitivos, precisamente para facilitar su adicin a las plantillas. o Tambin es importante destacar el hecho de que actualmente las cadenas e XML contienen exceso de informacin respecto a la utilizada en las plantillas. o La razn de este exceso es precisamente la potencial necesidad de usar esas inforo macin ((extra)) en un futuro, de forma que ya est disponible y no sea necesario o e modicar las funciones que recolectan los datos, reduciendo este mantenimiento unicamente a la modicacin de las plantillas, lo que supone una ventaja que o contrarresta con creces la disminucin del rendimiento de las combinaciones1 . o
1 Dada la velocidad de las combinaciones de las plantillas XSL, el exceso de datos en los nodos provoca una disminucin de rendimiento tan pequea que es irrelevante, sobre todo o n 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 modicacin que sea necesaria en el cdigo generado deber ser , o o a 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 transformacin (las sentencias XSL) de los componentes de la plantilla (elementos en el o lenguaje correspondiente al chero que va a ser generado). Las modicaciones en la estructura de archivos de los proyectos generados debern ser llevadas a cabo en los propios servlets de Genereitor, ya sean en la a fase de generacin de esqueleto, cdigo o tablas maestras. Dichas rutas se hallan o o agrupadas dentro de los servlets en arrays segn las condiciones del proyecto a u generar, separando los grupos de plantillas y cheros generados que se han de combinar para cada opcin seleccionada en la interfaz. o Es importante tener en cuenta que, de producirse una modicacin en la o estructura de los proyectos generados, los paquetes que devuelven los tres bloques funcionales han de ser modicados para conservar una estructura idntica, e ya que de lo contrario se producirn fallos en el rbol de directorio, generando a a 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 ms inmediata es la ina tegracin en los proyectos generados de los mdulos CMS2 , XMl y el soporte o o para grupos y perles del mdulo Usuarios. Todos estos mdulos han sido desao o rrollados en la Empresa y son utilizados en muchas de las aplicaciones que se desarrollan. Posteriormente, y segn las necesidades con respecto a los requisitos de nueu vos proyectos que se contraten, se ampliar el soporte para otros sistemas de a bases de datos tal como se ha comentado anteriormente, o se integrarn nuevos a mdulos que se desarrollen en la empresa para uso comn. o u
2 Actualmente
el desarrollo de soporte para CMS se halla muy avanzado
115
Parte VI
Apndices e
116
Apndice A e
Documento de anlisis y a dise o n

A continuacin se presenta la transcripcin del documento de Anlisis y o o a Dise o elaborado previamente al comienzo del desarrollo de la aplicacin. n o Nota: La elaboracin del documento de anlisis y diseo es previa al o a n comienzo del desarrollo del proyecto, por lo que existen bastantes diferencias entre lo que en un principio se plane y que aparece en este documento o y el resultado nal.
A.1.
Descripcin y objetivos o
El objetivo de este proceso es la obtencin de una especicacin detallada o o del nuevo Generador de cdigo J2EE, de forma que ste satisfaga todas y o e cada una de las necesidades funcionales de los usuarios de la aplicacin. o En el apartado de este documento Situacin Actual se realiza un estudio o sobre cmo trata el sistema actual el proceso de generacin de cdigo para de o o o esta manera poder detectar problemas y necesidades que el nuevo sistema de informacin tratar de solventar tanto a nivel de funcionalidad como de agilidad o a en el manejo de la herramienta, as como aadir nuevas caracter n sticas que permitan incrementar su eciencia y evolucionar ciertos apartados del sistema actual para adaptarlos a las nuevas tendencias tecnolgicas. o La denicin del sistema junto con la especicacin de requisitos realizada en o o este proceso permitir describir con precisin el nuevo sistema de informacin, a o o entrando en detalle en las tareas propias del Anlisis Funcional: a Modelo de procesos del sistema. Interfaces de usuario. 117
APENDICE A. DOCUMENTO DE ANALISIS Y DISENO
La participacin activa de los usuarios durante las diferentes sesiones de o trabajo para la completa denicin del sistema habr resultado decisiva e imo a prescindible para la actual fase de anlisis del nuevo sistema, ya que dicha a participacin constituye una garant de que los requisitos, datos, procesos e o a interfaces identicados han sido comprendidos e incorporados al sistema. El objetivo del proceso de Diseo del Sistema de Informacin es la denin o cin de la arquitectura del sistema y del entorno tecnolgico que le va a dar o o soporte, junto con la especicacin detallada de los componentes del sistema de o informacin. o A partir de dicha informacin, se generan todas las especicaciones de conso truccin relativas al propio sistema, as como la descripcin tcnica del plan o o e de pruebas, la denicin de los requisitos de implantacin y el diseo de los o o n procedimientos de migracin y carga inicial. o
A.2.
Resumen ejecutivo
El objetivo de este proyecto es ofrecer una herramienta que permita agilizar la creacin de nuevos proyectos consistentes en aplicaciones web contra bases o de datos de cualquier tipo. Se trata de una plataforma web que genera cdigo fuente J2EE de una aplio cacin web a todos los niveles, as como los elementos para los diferentes niveles o del esquema:
A.2.1.
Data Access Layer (Capa de Acceso a Datos)
Genera las clases de acceso a datos con las operativas CRUD ms comunes: a insercin de registros, actualizacin, consulta (por clave primaria o por cualquier o o otro campo) y borrado (unitario y masivo).
A.2.2.
Business Logic (Lgica de Negocio) o
La plataforma ha de dar opcin de implementar la BL mediante Enterprise o Java Beans (EJBs) o mediante clases bsicas Java, dependiendo si el servidor de a aplicaciones en el que ir alojado el proyecto soporta EJBs o no. a
A.2.3.
Model-View-Controller (Modelo-Vista-Controlador)
La interfaz de usuario ser implementada siguiendo el patrn de modeloa o vista-controlador. Para ello se utilizarn clases previamente implementadas en el a comex-common1 . Se generarn JSPs de listado y de alta/modicacin, y Actions a o (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 realizacin de los JSPs se utilizar la coleccin de etiquetas (tags) o a o 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 aplicacin web o apoyada en una base de datos, capaz de realizar los accesos CRUD t picos a sta. Tambin crea la estructura de cheros bsica en la que se asientan todos e e a los proyectos realizados por el departamento Java de Comex Grupo Ibrica, e as como los archivos de instalacin y conguracin de la aplicacin que se va a o o o 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 Ibrica, proporcionando una base estndar, pero personalizada conforme a los e a 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 cdigo fuente, ajustando ya o a los parmetros de la nueva aplicacin, de modo que el programador no tenga a o que recurrir a un proyecto ya existente y modicar su cdigo para ajustarlo a o la conguracin y necesidades del nuevo programa. o Esta herramienta proporciona un ahorro de tiempo considerable en las primeras etapas de desarrollo, permitiendo al programador ocupar su tiempo en tareas ms espec a cas de cada proyecto, y evitndole las tareas mecnicas de a a creacin de las bases de cada aplicacin que se desarrolla, ya que el hecho de o o que exista una base comn ya creada por la organizacin permite automatizar u o esta tarea. El funcionamiento se basa en la consulta de la base de datos sobre la que se apoyar la aplicacin. Esta base de datos puede ser proporcionada por el cliente, a o 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 elaboracin de esta base de datos es un paso previo al uso del Generador, o ya que ste proporciona un sistema de consulta y edicin de los contenidos de e o las tablas donde se almacenan los datos, pero no es capaz de editar las propias tablas o aadir nuevas. n Es una herramienta de ayuda a la implementacin de la aplicacin requerida o o 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 aplicacin, escogiendo el programador las que ms se ajusten al proyecto o a solicitado por el cliente. Una vez elegidas las opciones, el Generador devuelve un paquete comprimido, conteniendo la estructura de archivos de la aplicacin y los mtodos de acceso a o e 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 aplicacin que no o sea posible generar de forma automtica, como podr ser la interfaz web que a a se presentar a los usuarios nales de la aplicacin, etc. a o
119
A.3.
Sistema Actual
Se dispone actualmente de un generador de cdigo, que ofrece soporte para o 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: Pgina de conexin del generador actual a o
Figura A.2: Pgina de seleccin de tabla del generador actual a o
El primer problema con el que nos encontramos es que cuando se produce un error de conexin con la base de datos, el programa no devuelve un mensaje o de error, sino que vuelca a la pgina la excepcin provocada. a o
Figura A.3: Error de conexin del generador actual o
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, sealando las claves primarias. Tambin ofrece informacin sobre el tipo de dato n e o que se almacena en cada campo, su longitud y decimales en caso de ser valores numricos. e A continuacin se ofrecen los distintos parmetros que podemos congurar o a para generar el cdigo apropiado a las necesidades del proyecto. o
Figura A.4: Pgina de seleccin de campos y parmetros del Generador actual a o a
Los problemas ms importantes en el Generador actual son los siguientes: a No se tiene en cuenta ningn tipo de relacin entre tablas, lo cual se u o 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 aplicacin las tenga en cuenta y se mantenga la consistencia en los datos. o No se ofrece en el generador la posibilidad de aadir restricciones al pron grama 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, aade comprobaciones en campos n que contengan NIF o fechas). Se ofrecen opciones que ya no son utiles o ya no interesa tenerlas en cuenta, como la posibilidad de usar Struts en lugar de servlets, que no se incluirn a en el nuevo Generador. La opcin de crear la estructura del proyecto se ofrece en la ultima etapa o 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 conexin. o
A.4.
Identicacin y denicin de requisitos o o
En este apartado se lleva a cabo la denicin, anlisis y validacin de los o a o requisitos a partir de la informacin facilitada por los usuarios participantes. o Se obtiene un catlogo detallado de los requisitos, a partir del cual se puede a comprobar que los productos generados en las actividades de modelizacin se o ajustan a los requisitos de usuario.
A.4.1.
A.4.1.1.
Ambito y alcance del proyecto

Denicin del proyecto o
El proyecto ser una plataforma web capaz de generar cdigo J2EE automtia o a camente ajustndose a los requisitos del proyecto solicitado por el cliente y cuyo a desarrollo se va a comenzar. Para su funcionamiento ser necesaria la creacin previa de una base de a o datos contra la que trabajar la nueva aplicacin, dado que esta plataforma no a o ha de ser capaz de modicar las bases de datos que tiene en cuenta al generar el cdigo, y por tanto tampoco de crearlas (las aplicaciones generadas con esta o herramienta s han de poder modicar su base de datos). El Generador trabajar sobre el servidor de aplicaciones Apache Tomcat, y a ser capaz de manejar los tipos de bases de datos ms comunes (Oracle, Posta a greSQL, MySQL, HSQLDB, SQLServer), contemplando la posibilidad de aadir n soporte para otros sistemas de bases de datos con la simple inclusin de un o plugin. Tambin podr crear cdigo para aplicaciones que sern soportadas tane a o a to por Tomcat como por otros servidores de aplicaciones (OC4J, etc), segn lo u indiquen los requisitos del proyecto. Los proyectos generados con esta aplicacin seguirn la arquitectura en tres o a capas de J2EE (gura A.5 en la pgina siguiente), compuesta por una capa de a acceso a datos, la lgica de negocio y el patrn modelo-vista-controlador. o o La capa de acceso a datos proporciona un acceso simplicado a la informacin contenida en la base de datos contra la que trabajar la aplicacin que se o a o est creando. Esto permite que los dems componentes del sistema accedan a la a a base de datos sin necesidad de conocer el modo de almacenamiento de sta, de e 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 abstraccin. o Sobre esta capa de acceso a datos est la lgica de negocio, consistente en a o una serie de componentes que interactan con la capa de acceso a datos, y una u fachada que simplica el uso de estos componentes y contra la que trabajan las actions de la tercera capa. La lgica de negocio se podr implementar mediante o a EJBs o clases bsicas de Java, segn dicten los requisitos del proyecto que solicita a u 122
Figura A.5: Esquema de la arquitectura J2EE
el cliente, y si el servidor sobre el que funcionar la aplicacin soporta EJBs o a o no. La tercera capa sigue el patrn modelo-vista-controlador, de forma que el o usuario del programa interactuar con una vista, comnmente compuesta por a u pginas JSP. Estas JSPs harn peticiones al servidor, quien tiene implementado a a un controlador que se mantiene a la espera de instrucciones. En el momento en que recibe una peticin, invoca las actions necesarias, que se comunicarn con la o a capas inferiores y devolvern al usuario el resultado de la operacin requerida. La a o interfaz de acceso pblico generada por el programa cumplir obligatoriamente u a con un nivel de accesibilidad AA2 segn el W3C. u Al solicitar el usuario la creacin del esqueleto de un nuevo proyecto, aparte o de la estructura de cheros de la aplicacin, tambin sern generados los cheros o e a de conguracin XML y los scripts de instalacin que luego sern usados por o o a ant para instalar la aplicacin en el servidor. o A.4.1.2. Identicacin de participantes (Actores) o
El usuario nal de esta herramienta ser el desarrollador del proyecto requea rido por el cliente, puesto que el Generador es una ayuda al desarrollo de las aplicaciones solicitadas a Comex Grupo Ibrica. e Aunque la estructura general del proyecto pueda ser creada por un Jefe de Proyecto o un Analista y los diferentes mdulos sean generados por los Prograo madores, en la aplicacin slo existe un perl de usuario. o o
2 Aunque las interfaces generadas por el programa cumplan con el nivel AA de accesibilidad, la propia interfaz del Generador no lo cumplir, puesto que para facilitar tareas a la hora de a usarlo se utilizar JavaScript. a
123
A.5.
Catlogo de requisitos del sistema a
El nuevo sistema a desarrollar tiene como objetivo cumplir una serie de requisitos funcionales y no funcionales que se resumen a continuacin: o
A.5.1.
Requisitos funcionales
1. El sistema generar el esqueleto inicial de la aplicacin el cual podr ser a o a para una aplicacin pensada para correr sobre un servidor que posea cono tenedor de EJBs o no. 2. El esqueleto inicial de la aplicacin contendr los descriptores de cheros o a XML necesarios para el empaquetado mediante la herramienta ant. 3. En el esqueleto inicial vendrn implementados los componentes genricos a e de la aplicacin: o Fachada. Accin base. o Clases con constantes. Ficheros de conguracin (acciones, textos). o Ficheros de etiquetas. Descriptores de cheros (para contenedores de EJBs si es el caso, para el servidor web y taglibs). Librer necesarias. as 4. En el esqueleto inicial se ha de incluir tambin las clases, librer y cone as guraciones necesarias para el uso de las herramientas genricas para la e gestin de parmetros y tablas maestras implementadas por Comex. o a 5. El sistema generar el cdigo necesario para todas las capas tomando como a o base una de las tablas de la base de datos. 6. El cdigo generado depender de si el servidor sobre el que se va a ejecutar o a soporta EJBs o no. 7. Si el servidor soporta EJBs, se dar la opcin de generar cdigo para EJBs a o o locales o remotos. 8. El sistema tendr en cuenta las relaciones entre las tablas de la base de a datos (foreign keys), y generar el cdigo para acceder a las tablas refea o renciadas por stas automticamente. e a 9. El sistema ha de ser capaz de generar aplicaciones para diferentes sistemas de bases de datos (Oracle, PostgreSQL, MySQL, HSQLDB, SQLServer). 10. Existir la posibilidad de aadir soporte para otros sistemas de bases de a n datos mediante la inclusin de plugins al sistema. Se proporcionar docuo a mentacin para ello. o
124
11. Generar aplicaciones pensadas para ser soportadas por diferentes servia dores de aplicaciones (Apache Tomcat, OC4J). 12. Crear las bases de la interfaz web genrica con sus distintos apartados a e (cabeceras y pies comunes a todas las pginas, men). a u 13. Proporcionar una serie de funciones JavaScript genricas para la interfaz a e web (calendario y comprobacin de fechas, NIF/CIF, implementacin del o o algoritmo md5...).
A.5.2.
Requisitos no funcionales
1. Toda interfaz de acceso pblico generada por el programa cumplir con u a un nivel de accesibilidad AA3 segn el W3C. u 2. El aplicativo web ser compatible con los navegadores web estndar. a a 3. La arquitectura del software ser la de un Sistema Centralizado con Ara quitectura de Tres Capas. Dicha arquitectura seguir los estndares J2EE. a a 4. El servidor web que soportar la aplicacin ser Apache Tomcat. a o a 5. La compilacin e instalacin de las aplicaciones generadas se llevar a cabo o o a mediante ant, que proporciona independencia de la plataforma sobre la que se instala, al contrario que makefile.
A.6.
Modelo de procesos
Para la realizacin de este apartado se habrn analizado las necesidades de o a los usuarios para establecer un conjunto de procesos que conformen el sistema de informacin. Se realizar un enfoque descendente (top-down), en varios nio a veles de abstraccin y/o detalle, donde cada nivel proporciona una visin ms o o a detallada del proceso denido en el nivel inmediatamente superior. En la elaboracin de este modelo de procesos se llegar a un nivel de deso a composicin en el que los procesos obtenidos sean claros y sencillos, es decir, o buscando un punto de equilibrio en el que dichos procesos tengan signicado por s mismos dentro del sistema global y a su vez la mxima independencia y a simplicidad. La totalidad de procesos indicados en este apartado sern los que deber dar a a soporte el nuevo sistema.
A.6.1.
Generacin del esqueleto o
Al iniciar el Generador, se ofrecer al usuario la opcin de crear el sistema a o de cheros bsico para una nueva aplicacin, dado que para esta tarea no se a o requiere conexin a base de datos. o
3 Unicamente es requisito que sean accesibles las interfaces de acceso p blico, es decir, la u parte de la interfaz destinada a administracin no ha de cumplir este requisito. o
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 del nuevo proyecto, as como los a)) cheros XML de conguracin y los scripts de instalacin que luego sern usados o o a por ant para instalar la aplicacin en el servidor que corresponda. o Aunque no se necesite conectar a la base de datos para generar el esqueleto, la aplicacin pedir una serie de datos necesarios para crear la estructura: o a 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 aplicacin a crear. o Nombre del paquete base. Datos de conexin a la base de datos (host, puerto, SID, usuario, cono trasea). Opcin de comprobar si estos datos son correctos mediante un n o botn que lance la conexin contra la base de datos y devuelva un mensaje o o segn los datos sean correctos o no. u Prejos de los nombres de tabla (terminados en (( ))). Prejos de los parmetros (terminados en (( ))). a
126
Si el esqueleto va a ser generado con parmetros o con tablas maestras a (radio). Ruta de los parmetros/tablas maestras. a Lista de librer a incluir. as El esquema de procesos de la fase de generacin del esqueleto se presenta en o la gura A.7.
Figura A.7: Esquema de procesos de la generacin del esqueleto o
A.6.2.
Generacin de script de tablas maestras o
Esta funcionalidad del generador permite crear el script de tablas maestras para un proyecto mediante la conexin a la base de datos sobre la que se apoyar, o a permitiendo al usuario seleccionar las tablas que se habrn de tener en cuenta a para la generacin de dicho script. o En primer lugar se presenta una pantalla de conexin, donde una vez ino troducidos los datos de host, puerto, SID, usuario y contrasea, el programa n se conecta a la base de datos y devuelve una lista de todas las tablas que la conforman (gura A.8 en la pgina siguiente). De dicha lista el usuario dea ber elegir las que convengan para generar el script. Una vez seleccionadas las a tablas apropiadas, el Generador ofrecer al usuario una lista de todos los campos a y opciones. Una vez seleccionadas las tablas que se utilizarn, se presenta una pantalla a con todos los campos que conforman las tablas seleccionadas, as como una serie
127
Figura A.8: Esquema de procesos de la seleccin de tablas para la generacin o o del script de tablas maestras
de opciones tanto de cada tabla como de los campos, de forma que el usuario pueda elegir las que ms convengan segn los requisitos del proyecto a realizar. a u Para cada tabla se informar de su clase y se pedir una descripcin (literal ) a a o y la seleccin del campo por defecto. Para cada campo, aparte de las opciones o de tabla, se podr aplicar la restriccin de campo obligatorio y se presentarn a o a 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 ultimo paso se presenta en la gura A.9 en la pgina siguiente. a
A.6.3.
A.6.3.1.
Generacin de cdigo o o
Conexin a la base de datos o
El primer paso para la generacin de un nuevo mdulo de un proyecto es o o la conexin a la base de datos sobre la que se ejecutar. Para esto, el usuario o a seleccionar el tipo de base de datos que la aplicacin va a usar (y que debe a o estar implementada previamente al uso del Generador). Tras esto, rellenar los a datos de conexin (Host, Puerto, SID, Usuario y Contrasea) y pulsar el botn o n a o ((Conectar)). Al pulsar ((Conectar)) se comprobar que los datos de conexin introducidos a o sean correctos, de otro modo devolver un error con una breve explicacin y a o volver a pedir los datos de conexin. a o Tambin se comprobar que el host contra el que lanzamos la peticin est ace a o e tivo, y que la base de datos que hemos introducido exista en el servidor, as como 128
Figura A.9: Esquema de procesos de la seleccin de campos y opciones para la o generacin del script de tablas maestras o
que el usuario y la contrasea proporcionados para el acceso a la misma sean n correctos. Si algo de esto no se cumple, nuevamente se mostrar un error y a retornar a la pgina de conexin. a a o A.6.3.2. Seleccin de la tabla principal o
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 ste la e que le interese. Al seleccionarla, se realizar otra consulta a la base de datos, a obteniendo el nombre de los campos que conforman esa tabla. A.6.3.3. Seleccin de tablas relacionadas y campos o
Una vez seleccionada la tabla principal, se vuelve a consultar la base de datos, mostrando al usuario un listado de las tablas que hacen relacin a sta, o e 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 cdigo. o Asimismo para cada tabla (principal y relacionadas) existe la posibilidad de consultar y seleccionar sus campos. Al seleccionar una de las tablas, se presentar al usuario el listado de campos que la forman, de manera que ste pueda a e elegir los que interesan. Tambin se ofrecer informacin acerca de tipos de datos e a o almacenados, nombres de variables y si son clave primaria de la tabla. Las consultas a base de datos se realizarn tal como indica el esquema de a la gura A.10 en la pgina siguiente. Se consultarn las claves ajenas de otras a a
129
Figura A.10: Esquema de procesos de la seleccin de la tabla principal o
clases que hagan referencia a la tabla a partir de la que se va a trabajar, y se consultar al usuario si quiere que sea tenida en cuenta. Slo se tendrn en a o a cuenta las referencias a primer nivel, es decir, se descartarn los atributos de las a tablas que sean clave ajena de otra clase que haga referencia a la tabla sobre la que se est trabajando, de la forma que indica el diagrama de la gura A.11: a
Figura A.11: Esquema de tratamiento de tablas relacionadas
Este proceso se repetir tantas veces como clases hagan referencia a la clase a seleccionada. A.6.3.4. Seleccin de campos o
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 ste pueda revisar que e todo sea correcto. En esta lista tambin se ofrecern una serie de opciones de e a manera que se puedan aplicar algunas restricciones en la entrada de datos de la aplicacin a generar que la base de datos no tenga. o La lista mostrar para cada tabla: a
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 si en la base de datos ese a campo puede tomar valores nulos o no. Si el campo es obligatorio (mandatory) en la base de datos, el checkbox aparecer seleccionado e inactivo. a Si no lo es, podremos seleccionarlo para que en nuestra aplicacin s lo o 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 mxima que puede tomar un campo de tipo a cadena de caracteres. Ofrece la posibilidad de aumentar en el programa generado la restriccin que imponga la base de datos, o de establecerla si o no existe. Descripcin: permite introducir el nombre (literal ) de cada campo. o A.6.3.5. Seleccin de parmetros o a
En este ultimo paso se seleccionarn los parmetros oportunos para las ne a a cesidades de la aplicacin que se va a generar. Las opciones son las siguientes: o Nombre del paquete. Lista de nombres de beans. Generar cdigo para borrar varios benas en listado (check ). o Generar JSP de edicin (check ). o Generar JSP de detalle (check ). Nombre de la aplicacin. o Generar con EJB/Clases Java (radio). Generar EJB locales/remotos (radio, slo activo si en el anterior se seleco cion EJB). o A la hora de trabajar con las tablas relacionadas con la primaria, el unico campo que variar respecto de sta ser el nombre del bean que tenga asociado. a e a 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 beans. Las dems opciones ser idnticas para todas las tablas, as que slo se tendrn a a e o a que rellenar una vez. Segn las capacidades del servidor donde ir alojada la aplicacin que estau a o mos creando y los requisitos del proyecto, el generador ofrece la posiblidad de 131
generar cdigo para usar EJBs o clases Java. Al seleccionar EJBs, aparecer una o a nueva opcin que dar a elegir entre EJBs locales o remotos. Si se seleccionan o a clases Java, esta opcin no estar visible, ya que es indiferente. o a Cuando ya hayamos completado todas las opciones para todas las tablas relacionadas que nos interesan, el Generador nos devolver un paquete comprimido a que contendr el cdigo fuente solicitado, tal como indica la gura A.12. a o
Figura A.12: Esquema de procesos de la seleccin de parmetros o a
A.7.
Denicin de la arquitectura del sistema o
La estructura cliente-servidor posibilita que la aplicacin slo tenga que estar o o instalada en una mquina, que esperar a que los clientes realicen peticiones a a para ejecutar las operaciones requeridas y devolver los resultados. El servidor sobre el que est alojada la aplicacin es Apache Tomcat, pese a que dentro de a o la funcionalidad del programa es capaz de generar cdigo fuente para proyectos o 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 travs de e Internet, con un simple navegador, evitando la instalacin de programas cliente o espec cos para cada usuario, y la actualizacin de estos programas cliente en o posibles actualizaciones de la aplicacin. o Las ventajas de este diseo frente a una estructura monol n tica (un ejecutable autnomo, y una copia de ste instalada en cada cliente) son evidentes, haciendo o e que la disponibilidad del sistema sea instantnea en el momento que sea requea rida, no teniendo que estar instalado en el cliente cuando no sea utilizado, y al ser presentado a travs de una interfaz web, garantizamos el funcionamiento e en cualquier sistema que pueda utilizar el cliente, puesto que las operaciones se ejecutarn slo en el servidor. a o Un inconveniente de esta arquitectura puede ser el riesgo de sobrecarga de la red o del servidor cuando muchos clientes accedan a l de forma simultnea, e a 132
pero dado que el uso de la aplicacin no ser intensivo, este aspecto puede ser o a descartado. La arquitectura del proyecto, correspondiente con la arquitectura J2EE, est formada por tres capas (gura A.13 en la pgina siguiente): a a 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), segn las propiedades o los requisitos del proyecto a reau lizar. Puesto que la elaboracin de la base de datos es anterior al uso del Geo nerador, ste ha de ser verstil en este sentido, ya que se ha de ajustar a las e a 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 como parmetro, siendo la lgica de negocio quien gestione la a a o comunicacin con sta. o e El segundo nivel, la lgica de negocio (BL, Business Logic), implementa o 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 estn almacenados. e El tercer nivel, la parte web de la aplicacin, sigue el patrn modelo-vistao o controlador (MVC, Model-View-Controller). Esta separacin en tres niveles pero mite 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 con la Business Logic para consultar o actualizar los a 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 ima plementada mediante JSP.
A.7.1.
Gestor de base de datos
El Generador de cdigo tomar como base inicial los datos contenidos en una o a base de datos, que variar segn las necesidades del proyecto a realizar. Dado a u que los diferentes proyectos se apoyarn sobre bases de datos de distintos tipos, a el Gestor de bases de datos tendr que cumplir con los siguientes requisitos: a 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 sobre un servidor de aplicaciones (Apache Toma cat), que proporcionar a la aplicacin web los siguientes recursos fundamentaa o les: 133
Figura A.13: Esquema de la arquitectura de software
Servidor web, capaz de construir de forma dinmica la interfaz del sistema, a basado en pginas web (JSPs). Ser capaz de soportar concurrencia y a a controlar distintas sesiones de trabajo simultneas. a Contenedor, capaz de ejecutar los diferentes componentes de software que permitirn desarrollar la lgica de los componentes base y los mdulos a o o funcionales de la plataforma, as como encapsular la comunicacin del o 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 simultneas. a
A.8.
Modelo de datos
Dentro de este apartado se identican todas las necesidades de informacin o de cada uno de los procesos que conforman el sistema de informacin, con el n o 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 cdigo de la aplicacin, el generador se ejecuta contra la base o o de datos propia de la aplicacin a crear, cuya implementacin se habr realio o a zado 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 cmo estn almacenados los datos. o a 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 ampliacin para sistemas de bases de datos que no estn incluidos en la o e implementacin base, de manera sencilla y documentada, mediante plugins que o ser desarrollados conforme a las nuevas necesidades. an
A.8.2.
Generacin o
Una vez consultada la estructura de la base de datos, el Generador ser capaz a de crear rdenes que se efecten contra la base de datos, ya no slo de consulta, o u o sino de modicacin, creacin y borrado de registros, esta vez ya a nivel de o o 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.
Denicin del interfaz de usuario (prototio pos)
La interfaz de usuario est estructurada en tres ((ramas)), correspondientes a a las tres funciones principales del Generador: Generacin del esqueleto de un proyecto. o Generacin del script de tablas maestras de un proyecto. o Generacin de cdigo de las diferentes partes de un proyecto. o o Estas tres opciones se presentan en la pgina inicial del Generador, mediante a tres botones que enlazan a cada una de las funciones. Existe una cuarta opcin o (Ajustes), que permitir establecer los parmetros de conexin por defecto para a a o las distintas bases de datos sobre las que la Empresa est trabajando en cada e momento, de forma que no se tengan que introducir cada vez que se requiera la 135
ayuda del Generador. A continuacin se detallan los diferentes componentes de o cada pantalla de la interfaz.
A.9.1.
Generacin del esqueleto o
Esta parte consta slo de una pantalla, que pedir los siguientes campos: o a Tipo de base de datos: ser un combo que mostrar los sistemas de bases a a de datos para los que puede trabajar el Generador (Oracle, MySQL, PostgreSQL, HSQLDB, SQLServer y cualquiera que se aada en un futuro), de n los que habr que seleccionar el que soportar la nueva aplicacin. a a o Tipo de servidor de aplicaciones: ser un combo que mostrar los servia a dores de aplicaciones para los que puede trabajar el Generador (OC4J, Tomcat y cualquiera que se aada en un futuro), de los que habr que n a seleccionar el que soportar la nueva aplicacin. a o Nombre de la aplicacin: ser un textbox en donde habr que introducir el o a a nombre de la aplicacin para la que se va a crear el esqueleto. o Nombre del paquete base: ser un textbox en donde habr que introducir a a el nombre del paquete base de la aplicacin para la que se va a crear el o esqueleto. Datos de conexin: aunque para este paso no es necesario conectarse a una o base de datos, rellenar ahora los datos de conexin permite al Generador o crear el esqueleto ya preparado para la base de datos sobre la que vaya a trabajar la aplicacin. o Host: textbox donde se introduce el servidor donde se aloja la base de datos. Puerto: textbox numrico donde se introduce el puerto en el que ese cucha 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. Contrasea: textbox de tipo password donde se introduce la contran sea del usuario. n Comprobar: botn que lanza una conexin con los datos introducidos o o 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 botn permite comprobar, en el caso de que el servidor de bases de o datos est activo, si los datos de conexin introducidos son correctos. e o Parmetros: permite seleccionar mediante un checkbox si se utilizarn parmea a a tros en la aplicacin que se va a generar. De ser as se activarn dos campos o , a de texto, donde se habrn de introducir el prejo de los nombres de los a parmetros (que acabar en (( )), de no ser as el Generador lo pondr al a a a nal del nombre introducido) y la ruta donde se encuentran esos parmea tros. 136
Tablas maestras: permite seleccionar mediante un checkbox si se utilizarn a tablas maestras en la aplicacin que se va a generar. De ser as se actio , varn dos campos de texto, donde se habrn de introducir el prejo de a a los nombres de las tablas maestras (que acabar en (( )), de no ser as el a Generador lo pondr al nal del nombre introducido) y la ruta donde se a encuentran las tablas maestras. Usuarios: permite seleccionar mediante un checkbox si la aplicacin que se va o a generar tendr soporte para diferentes usuarios. De ser as se activarn a , a los siguientes campos: Prejo de los nombres de usuario: textbox en el que se introducir el a prejo que llevarn los nombres de usuario, seguido del carcter (( )). a a De no ser as el Generador lo pondr al nal del nombre introducido. , a Ruta de los usuarios: textbox donde se introducir la ruta donde se a encuentra los archivos de usuario. Grupos: checkbox que indica que la aplicacin a generar ha de tener o soporte para grupos de usuarios. Perles: checkbox que indica que la aplicacin a generar ha de tener o soporte para diferentes perles de usuario. Al activar esta opcin, se o activan los siguientes campos: Textbox para aadir un nuevo perl. n Lista que muestra los perles aadidos. n Botn de ((aadir perl)), que aade el nombre del perl que o n n gura en el textbox a la lista. Botn de ((borrar perl)), que elimina de la lista el perl seleccioo nado. Librer as: lista de las librer disponibles, de donde se seleccionarn las que as a la nueva aplicacin necesite para funcionar. o Generar: botn que conrma las opciones introducidas anteriormente y genera o el paquete que contendr el esqueleto ya creado. a Retroceder: botn que cancela el proceso y devuelve al usuario a la pgina o a principal.
A.9.2.
Generacin de script de tablas maestras o
Este apartado consta de tres etapas: A.9.2.1. Conexin o
Esta pantalla consta de los siguientes campos: Datos de conexin: o Tipo de base de datos: lista para seleccionar el tipo de base de datos a la que se va a conectar (aadido posteriormente). n 137
Host: textbox donde se introduce el servidor donde se aloja la base de datos. Puerto: textbox numrico donde se introduce el puerto en el que ese cucha 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. Contrasea: textbox de tipo password donde se introduce la contran sea del usuario. n Conectar: Botn que lanza la conexin contra el servidor de bases de datos o o segn los datos introducidos. u Retroceder: botn que cancela el proceso y devuelve al usuario a la pgina o a principal. Al pulsar el botn ((Conectar)), y si se puede establecer la conexin, se pasa o o a la siguiente etapa. En caso contrario, informa del error de conexin y devuelve o al usuario a la pantalla de conexin para modicar los datos. o A.9.2.2. Seleccin de tablas o
Una vez establecida la conexin, se presenta al usuario una pantalla con los o 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 generacin del script de tablas maestras. o Siguiente: botn que conrma las opciones introducidas anteriormente y env o a al usuario a la pantalla de seleccin de campos. o Retroceder: botn que cancela el proceso y devuelve al usuario a la pantalla o de conexin. o A.9.2.3. Seleccin de campos o
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 continuacin: o ID de tabla: muestra la tabla cuyos atributos aparecen a continuacin en la o 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 restriccin ya est impuesta en la base de datos, el checkbox o a aparecer tildado e inactivo. a Literal: permite establecer el literal de cada campo. Su valor por defecto ser el a identicador de campo en formato Java4 . Listado: Checkbox de activacin. El usuario lo activar si quiere que el atrio a buto sealado sea listable. Al activarlo, aparecen seleccionables las n siguientes opciones: Indice: permite establecer el orden en el que aparecern en la lista a los diferentes campos de una tabla. Ordenable: muestra si el listado conseguido es ordenable o no. Buscador: Checkbox de activacin. El usuario lo activar si quere que ese campo o a aparezca en la funcin buscador que aparecer en la pgina del futuro o a a proyecto. Indice: indica5 el orden en el que aparecern los resultados del busa cador con los campos introducidos. MaxLength: permite establecer la mxima medida del campo. a Detalle: Checkbox de activacin. El usuario lo activar si quiere que para el o a atributo seleccionado haya una vista ((detalle)). Indice: Indice: permite establecer el orden en el que aparecern en a los resultados los campos introducidos. MaxLength: permite establecer la mxima medida del campo. a Foreign Keys: Checkbox de activacin. El usuario lo activar si quiere que la foreign o a key detectada sea tenida o no en cuenta.
4 Ejemplo: el campo ID PRODUCTO FABRICADO tendr como literal por defecto a idProductoFabricado. 5 El ndice de buscador se actualiza automticamente al tildar el checkbox de activacin. a o
139
Campo: combo que permitir seleccionar qu campo de la tabla refea e renciada 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.
Generacin de cdigo o o
Este apartado consta de cinco etapas: A.9.3.1. Conexin o
Esta pantalla consta de los siguientes campos: Datos de conexin: o Tipo de base de datos: lista para seleccionar el tipo de base de datos a la que se va a conectar (aadido posteriormente). n Host: textbox donde se introduce el servidor donde se aloja la base de datos. Puerto: textbox numrico donde se introduce el puerto en el que ese cucha 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. Contrasea: textbox de tipo password donde se introduce la contran sea del usuario. n Conectar: botn que lanza la conexin contra el servidor de bases de datos o o segn los datos introducidos. u Retroceder: botn que cancela el proceso y devuelve al usuario a la pgina o a principal. A.9.3.2. Seleccin de la tabla principal o
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 la que le a interese. Siguiente: botn que lleva al usuario al siguiente paso. o Retroceder: botn que devuelve al usuario a la pantalla de conexin a la base o o de datos. 140
A.9.3.3.
Seleccin de tablas relacionadas o
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 continuacin. o 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 acompaada de un checkbox que permia n tir seleccionarla o no. a Siguiente: botn que lleva al usuario a la pantalla de seleccin de campos. o o Retroceder: botn que devuelve al usuario al paso anterior. o A.9.3.4. Seleccin de campos o
ID de tabla: muestra la tabla cuyos atributos aparecen a continuacin en la o 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 seleccionado e inactivo. Si no lo es, podremos seleccionarlo a para que en nuestra aplicacin s lo sea. o MaxLength: indica la longitud mxima que puede tomar un campo de tipo a cadena de caracteres. Ofrece la posibilidad de aumentar en el programa generado la restriccin que imponga la base de datos, o de establecerla si o no existe. Descripcin: permite introducir el nombre (literal ) de cada campo. o Siguiente: botn que lleva al usuario a la pantalla de seleccin de campos. o o Retroceder: botn que devuelve al usuario al paso anterior. o Una vez seleccionados los campos a tener en cuenta y conrmadas las opciones de cada uno, el usuario introducir las caracter a sticas del proyecto a crear mediante el siguiente formulario: Nombre del paquete: textbox donde se introducir el nombre del paquete que a se va a generar.
141
Lista nombres de los beans: para cada tabla (primaria y relacionadas) se ha de introducir el nombre del bean asociado a ellas. Constar de: a Nombre de la clase. Nombre del bean: textbox. Generar cdigo para borrar varios beans en listado: checkbox que pero mite al usuario elegir si se desea generar cdigo para borrar varios beans o en listado o no. Generar JSP de edicin: checkbox que permite al usuario elegir si se desea o generar JSPs de edicin. o Generar JSP de detalle: checkbox que permite al usuario elegir si se desea generar JSPs de detalle. Nombre aplicacin: textbox donde se introducir el nombre de la aplicacin o a o para la que se est creando el paquete. a EJBs/Clases Java: radio que permite al usuario elegir si se desea generar cdigo con EJBs o con clases Java, segn el servidor de aplicaciones que o u contenga la aplicacin soporte o no EJBs. Si se seleccionan EJBs, apareo cer la siguiente opcin: a o EJB local/remoto: radio que permite al usuario elegir si se desea generar EJBs locales o remotos. Generar: botn que conrma las opciones introducidas anteriormente y geo nera el archivo comprimido que contendr el cdigo del paquete. a o Retroceder: botn que cancela el proceso y devuelve al usuario a la pantalla o de resumen/opciones de campos A continuacin se presenta un esquema de los campos que contendrn los o a diferentes apartados de la interfaz web (guras A.14 en la pgina siguiente y A.15 a en la pgina 143): a
142
Figura A.14: Esquema de la interfaz del generador
143
Figura A.15: Recopilacin de los formularios de la interfaz del generador o
144
A.10.
Migracin inicial de datos o
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 migracin inicial. o
145
Apndice B e
Combineitor, herramienta complementaria

Como ya se ha visto, en la fase de generacin de esqueleto se proporcioo nan ciertos cheros ((incompletos)), cuyo contenido se amplia mediante trozos inclu dos en el paquete que se devuelve al usuario en la fase de generacin de o cdigo de cada entidad de la base de datos. o En un principio, el mecanismo de inclusin de dichos trozos en sus archivos o correspondientes se llevaba a cabo a mano, pegando el trozo en el archivo generado en el esqueleto. Este proceso es breve, no lleva ms de cinco minutos, y a est esquematizado en la gura B.1. a
Figura B.1: Proceso de combinar un chero a trozos. Sin embargo, en la fase de implementacin de las plantillas, se llevaban a cabo o decenas de pruebas cada d para comprobar el correcto funcionamiento de las a aplicaciones generadas, por lo que el tiempo perdido en completar los archivos se multiplicaba, disminuyendo enormemente la produccin y ralentizando el o 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 solucin temporal, se desarroll un pequeo script de bash que como o n binaba dichos trozos automticamente, evitando al programador la tarea de a completarlos a mano. Pero tras un anlisis, se decidi incorporar denitivamena o te este script al sistema, de forma que todos los usuarios pudieran disponer de l. e Para ello se mejor sensiblemente el sistema de combinacin, estableciendo o o en las plantillas de los cheros incompletos marcas en forma de comentarios. El script analizar y reconocer dichas marcas, insertando en su lugar los trozos a a correspondientes. Tambin se le dot de una interfaz ms amigable que la l e o a nea de comandos, optando por una basada en dilogos mediante el paquete dialog, disponible en a la prctica totalidad de distribuciones GNU/Linux. a
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 generacin de cdigo devuelve un paquete, correspondiente a o o 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 aplicacin. o 4. Se accede por consola al directorio de trabajo donde reside el esqueleto y se otorga permiso de ejecucin a combineitor1 : o
1
$ chmod + x combineitor
1 La operacin de otorgar permisos de ejecucin slo es necesario realizarla la primera vez o o o que se ejecuta el script.
147
5. Tras esto, se ejecuta el script:

1
$ ./ combineitor
Una vez lanzado el script, aparece un mensaje de conrmacin, que indica a o qu entidad de la base de datos corresponde el paquete que se pretende combinar, e tal como se ve en la gura B.2.
Figura B.2: Mensaje de conrmacin del paquete de cdigo de combineitor. o o Tras aceptar este mensaje, se muestra una lista de los trozos disponibles en el paquete de cdigo para combinar con sus correspondientes en el esqueleto, tal o como muestar la gura B.3.
Figura B.3: Lista de seleccin de los cheros a combinar. o Tras seleccionar el usuario los cheros convenientes (que por norma general sern todos ellos, razn por la que aparecen por defecto todos seleccionados), a o se procede a copiar todos los archivos del paquete de cdigo en su ubicacin o o correspondiente dentro del esqueleto de la aplicacin. o 148
Los cheros compuestos por trozos sern completados con el contenido de a las partes del paquete de cdigo que correspondan. o Por ultimo, si se ha seleccionado combinar los scripts SQL o PL/SQL, se pregunta al usuario si ha habido env de la aplicacin (gura B.4 en la pgina os o a siguiente). El motivo de esta pregunta es que en la aplicacin original, para o montar la base de datos en los servidores del cliente se proporcionan diversos scripts SQL, organizados segn su contenido, y que hay que ejecutar en orden: u 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 no ha recibido una versin de la aplicacin que se a o o est desarrollando, los trozos de los scripts se distribuirn en estos scripts iniciaa a les. Sin embargo, si al cliente ya se le ha entregado una versin de la aplicacin, o o el inclu las modicaciones en estos cheros implicar que el cliente tendr que r a a eliminar su base de datos y volver a ejecutar todos los scripts por orden, con la consecuente prdida de los datos que pudiera haber aadido (o la necesidad de e n hacer un respaldo de la informacin). o Es por sto que las modicaciones en la base de datos se proporcionan, e a partir del primer env a cliente de la aplicacin, en cheros parche, cuya o o ejecucin modicar el comportamiento de la base de datos conforme los obo a jetivos requeridos. As si en el dilogo de combineitor que pregunta por los , a env de la aplicacin, se generar con el contenido de los trozos un chero os o a XX FECHA DESCRIPCION.SQL, por ejemplo XX 20080810 ADICION TABLA CATALOGO.SQL. Tras haber realizado este ultimo paso, la aplicacin est lista para desplegar o a en el servidor de aplicaciones2 .
2 Antes de desplegar la aplicacin hay que ejecutar los scripts creados contra la base de o datos, puesto que de otra manera no ser posible que la lgica de acceso de la aplicacin a o o consulte o modique los datos correspondientes a la nueva entidad.
149
Figura B.4: Dilogo de seleccin de aplicacin enviada o no a cliente. a o o
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 combineitor para a saber dnde insertar los trozos. Se etiquetan con el literal ((genereitor)) para o indicar a los programadores que son trazas generadas automticamente, que no a son comentarios de un desarrollador, y que por lo tanto no se pueden quitar. De lo contrario, combineitor no realizar su tarea de forma correcta. a El trozo de dicho chero para una entidad catlogo contendr lo siguiente: a a
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 estn en las l a neas 8 y 21. El n del ultimo trozo no es necesario indicarlo, puesto que corresponde con el n de chero. Una vez realizada la combinacin, el resultado ser el siguiente: o a
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 cdigo. Tambin se mantienen las marcas de insercin, de forma que el o e o proceso de combinacin se pueda repetir al aadir otra entidad de la base de o n datos a la aplicacin. o
B.3.
Motivos de la eleccin de bash para su imo plementacin o
Como ya se ha comentado, esta herramienta auxiliar se concibi en un prino cipio como mera ayuda al desarrollo de las plantillas de Genereitor, por ello se eligi un lenguaje sencillo, rpido y del que ya se tuviera experiencia previa. o a Cuando se tom la decisin de inclu o o rlo en Genereitor como herramienta complementaria, se plante portar el cdigo a otro lenguaje ms eciente y que o o a soportase multiplataforma, pero se desestim la idea, puesto que la totalidad de o 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 util imprescindible, ya se ha comentado que el proceso que realiza combineitor puede ser ejecutado por el programador en menos de cinco minutos.
152
Apndice C e
Tecnolog utilizadas as
C.1. JavaScript
JavaScript es un lenguaje de scripts (guiones) generalmente utilizado para el desarrollo de pginas web, ofreciendo funcionalidades en el lado del cliente a (client-side)1 , sin necesidad de establecer conexin con el servidor. o Es un lenguaje de programacin interpretado2 y su sintaxis es similar a la de o Java o C. Es un lenguaje orientado en objetos basado en prototipos, y dispone de herencia, disponible mediante clonacin de objetos existentes, que hacen la o funcin de prototipos. o Debido a que JavaScript se ejecuta directamente en el navegador del usuario, en lugar de en un servidor remoto, responde instantneamente a las acciones a 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 programacin estructurada de los lenguajes ms o a comunes (C, Java). Hace distincin entre expresiones y declaraciones. o Permite evaluar expresiones en tiempo de ejecucin. Es decir, acepta el o paso como parmetro de una cadena de caracteres, que interpretar como a a una expresin y, tras evaluarla, devolver un resultado. o a
1 Aunque inicialmente JavaScript se utilizaba unicamente 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 de referencia a 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 compilacin. o 3 Un array asociativo es un tipo de dato abstracto, compuesto por una coleccin de claves o unicas y una coleccin de valores, donde cada clave est asociada con un valor. Las operaciones o a bsicas de un array asociativo son add (asignar una nueva clave a un nuevo valor), reasign a (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 dbilmente tipicado, puesto que no es necesario declarar e el tipo de datos en la asignacin de variables, y la conversin de un tipo a o o otro se realiza de forma automtica. A esta caracter a stica se le conoce como duck typing. El siguiente fragmento de cdigo es perfectamente vlido: o a
1 2 3 4 5 6 7 8 9 10 11
var variable1 = 2; variable1 =+ 3; // 2 + 3 , variable1 es de tipo num rico e alert ( variable1 ) ; // devolver 5 a variable1 = " Cadena de caracteres "; alert ( variable1 ) ; // devolver " Cadena de caracteres " a 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 mtodos. Una funcin puede se llamada e o como mtodo. e Soporta expresiones regulares. El principal inconveniente de JavaScript es que no es accesible. Es por sto e que no es recomendable su uso en pginas que requieran un nivel aceptable a de accesibilidad, o en caso de que se decida usarlo, es necesario ofrecer una alternativa bajo el tag <noscript> en la pgina. Por ejemplo, si se ofrece un a men desplegable que funciona con JavaScript, se ofrecer tambin el men desu a e u plegado u otra alternativa para los navegadores que no soporten JavaScript.
C.1.1.
Alternativas
Como ya se ha dicho, si la aplicacin requiere de un nivel aceptable de o 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 visin, es probable que no sea posible ejecutar dichos guiones. o 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 similaas res. El problema de delegar al servidor tareas que se pueden hacer en cliente es evidente: se requieren ms conexiones entre ambos lados para realizar la misma a tarea, lo que repercutir en el rendimiento nal de la aplicacin. a o
C.2.
JSP
JavaSever Pages es una tecnolog de Java que permite generar dinmicaa a mente documentos HTML, XML o de otros tipos, en respuesta a una peticin de o 154
un cliente web. Permite el uso de cdigo Java y proporciona algunas acciones o predenidas que pueden ser incrustadas en el contenido esttico. a La sintaxis JSP aade tags, al estilo de XML, llamadas acciones JSP y que n son utilizadas para invocar a las funcionalidades provistas por el uso de JSP. Adems, se ofrece la posibilidad de crear nuevos tags, extendiendo la librer de a a los ya existentes (provistos por HTML o XML). Es un mtodo de ampliar las e 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 peticin. Las sucesivas peticiones se vern satisfechas o a con ms rapidez, ya que no ser necesario volver a compilar el JSP. a a
C.2.1.
Alternativas
La alternativa ms inmediata al uso de JSP es ASP, de Microsoft. No obsa tante, JSP ofrece las siguientes ventajas con respecto a su rival: C.2.1.1. Plataforma e independencia del servidor
JSP sigue la losof de Java de write once, run anywhere. Su caracter a stica multiplataforma nos proporciona independencia sobre el sistema operativo que debe llevar el servidor que aloje el contenedor donde se almacenarn, compilarn a a y ejecutarn los JSP. Por el contrario, ASP est limitada a arquitecturas basadas a a en tecnolog de Microsoft. a As JSP se puede ejecutar en los sistemas operativos y servidores ms co, a munes, como son Apache, Netscape o Microsoft IIS, mientras que ASP slo tiene o 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 unicamente de Microsoft. C.2.1.3. Tags
Mientras que tanto JSP como ASP usan una combinacin de tags y scripts o para crear paginas web dinmicas, la tecnolog JSP permite a los desarrollaa a dores crear nuevos tags. As los desarrolladores pueden crear sus tags de forma personalizada, y no depender de los scripts. Esto proporciona una alta reutilizacin de cdigo. o o C.2.1.4. Java
La tecnolog JSP usa Java para crear contenido de forma dinmica, mientras a a que ASP usa VBScript o Jscript. Java es un lenguaje mas rpido, potente y a 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 ms fcil que las que a a usan ASP. Los lenguajes de script estn bien para pequeas aplicaciones, pero no a n encajan bien para aplicaciones grandes. Java es un lenguaje estructurado y es ms fcil de construir y mantenimientos grandes como aplicaciones a a modulares. La tecnolog JSP hace mayor nfasis en los componentes que en los scripts, a e esto hace que sea ms fcil revisar el contenido sin que afecte a la lgica a a o o revisar la lgica sin cambiar el contenido. o La arquitectura EJB encapsula la lgica de acceso a BD, seguridad, inteo gridad transaccional y aislamiento de la aplicacin. o Debido a que la tecnolog JSP es abierta y multiplataforma, los servidores a web, plataformas y otros componentes pueden ser fcilmente actualizados a o cambiados sin que afecte a las aplicaciones basadas en la tecnolog JSP. a
C.2.2.
Inconvenientes
Uno de los inconvenientes con respecto a otras tecnolog similares es que as tiene una curva de aprendizaje ms pronunciada. Aprender a programar en JSP a requiere ms esfuerzo, sobre todo si no se tiene experiencia anterior en lenguajes a de programacin, que ASP. o
C.3.
Ant
Apache Ant es una herramienta utilizada para la realizacin de tareas mecnio a cas y repetitivas, especialmente durante el proceso de compilacin y construccin o o de aplicaciones. Es similar a make, pero est implementado usando Java, requiea re la mquina virtual de Java y se integra perfectamente con proyectos en dicho a lenguaje. La principal diferencia con make es que utiliza XML para describir el proceso de construccin y sus dependencias, mientras que make utiliza su propio formato o Makele. Los scripts XML utilizados por ant llevan por nombre build.xml. Ant es software de cdigo abierto, y est liberado bajo la Apache Software o a 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 accin o como rdenes del intrprete de comandos propio del sistema operativo sobre o e el que se ejecuta, ant resuelve esta situacin proveyendo por l mismo gran o e cantidad de funciones, lo que garantiza que permanecern idnticas en todos los a e 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 intrprete de Unix, si intentamos ejecutar make e con esta orden en un entorno Windows, no funcionar. Sin embargo, un script a build.xml para ant que hiciera la misma funcin que el anterior ser o 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 en cualquier sistema que contase con una mquina a a virtual Java instalada, puesto que no depende de las rdenes del intrprete de o e 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 slo es una barrera para los nuevos usuarios, que tienen o que aprender este lenguaje, sino tambin un problema para los proyece tos muy grandes, cuando los scripts comienzan a hacerse muy grandes y complejos. Esto es un problema comn a todos los lenguajes que utilizan u XML, pero la granularidad de las tareas de ant signica que los problemas de escalabilidad no tardan en aparecer. La mayor de las antiguas herramientas (<javac>, <exec>, <java>) tiea nen malas conguraciones por defecto y valores para las opciones que no son coherentes con las tareas ms recientes. Pero cambiar estos valores a supone destruir la compatibilidad hacia atrs. Esto tambin sucede al exa e pandir 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 construccin de varios d o as.
C.3.3.
Alternativas: Maven
Una alternativa clara al uso de ant que superara muchas de las limitaciones de las que ste adolece es el uso de maven. e Maven aplica patrones a la estructura del proyecto, lo que deber promover a la productividad, facilitar la comprensin de la estructura del proyecto y reducir o el coste de trabajar con un nuevo proyecto, ya que la estructura ser idntica. a e 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 cmo ha de ser un proyecto Java y convenciones sobre la conguracin. o o Maven, como herramienta de gestin de proyectos, proporciona funciones de: o Compilacin. o Documentacin (e.g. Javadoc). o Reporting sobre datos del proyecto. Gestin de dependencias. o SCM5 y releases. Distribucin de la aplicacin a servidores locales o remotos. o o 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 documentacin y el sitio web del o proyecto.
C.3.4.
Motivos de la eleccin de ant o
Pese a que es evidente que existen alternativas mejores a ant, se ha decidido mantener esta herramienta por diversas razones. He aqu las ms importantes: a
4 En realidad, este proceso de copiar-pegar-adaptar no se tiene por qu llevar a cabo, ya e que una de las caracter sticas de Genereitor es precisamente ofrecer estos scripts adaptados al proyecto que se est generando, de forma automtica y totalmente funcional desde el principio a a de la implementacin del proyecto. o 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 Telemticos a para la elaboracin de los proyectos que este organismo le encarga, y al o 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 ms cmodo realizar las tareas de gestin de todos a o o los proyectos con esta herramienta que introducir varias que, realizando la misma funcin, su funcionamiento sea diferente. o Generacin automtica de scripts. Uno de los inconvenientes que se ha o a planteado respecto a ant es lo engorroso que es generar los scripts de compilacin de forma correcta para aplicaciones de cierta envergadura. o En este caso en particular este inconveniente no es tal, ya que Genereitor proporciona dichos scripts de forma automtica. a Integracin con IDEs. Aunque es posible utilizar Maven con cualquier IDE, o los ms usados (NetBeans, Eclipse y Oracle JDeveloper) proporcionan por a defecto soporte para ant6 , por lo que la integracin es instantnea. o a
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 transformacin de documentos XML en otros documentos (tanto XML o como otros formatos), a partir de una serie de datos. XSLT es un estndar de a W3C7 , y junto a XPath forman parte de XSL. Adems de la transformacin de documentos XML, XMLT ofrece tambin a o e otras funciones: Aadir y eliminar elementos a un rbol XML. n a Aadir y eliminar atributos a un rbol XML. n a Reorganizar y mostrar elementos. Mostrar u ocultar determinados elementos. Encontrar o seleccionar elementos espec cos. En el proceso de transformacin intervienen dos archivos, el de datos, que o contendr todos los nodos de informacin formateada en XML, y la plantilla a o XSLT, que ser la base del documento resultante de la combinacin de ambos. a o El proceso de combinacin se ilustra en la gura C.1 en la pgina siguiente. o a 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 programacin proporciona automticamente un build.xml para compilar y o a desplegar dicho proyecto. 7 La especicacin de XSLT se puede consultar en http://www.w3.org/XML/. o
159
Figura C.1: Proceso de combinacin de XSLT o
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 rbol. a Y una plantilla muy bsica puede ser: a
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 ningn formato. Esto destaca la capacidad de XSLT de crear casi cualquier u 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, pginas JSP, incluso cheros de conguracin propios de Oracle a o JDeveloper. Pero sus posibilidades no se terminan ah Es comn el uso de esta . u tecnolog para elaborar a partir de plantillas y de datos introducidos en un a 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 unico formato de salida de documentos. Permite manipular de muy diversas maneras un documento XML: reordenar elementos, ltrar, aadir, borrar, etc. n Permite acceder a todo el documento XML. XSLT es un lenguaje XML. Tambin es importante el hecho de que existen diferentes procesadores XSLT, e 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, tambin se han de mencionar diversos inconvenientes que plantea e el uso de XSLT: Su utilizacin es ms complicada que la de un lenguaje de programacin o a o convencional, y su sintaxis es algo incmoda. o Consume una cantidad sustancial de recursos, que dependern de la forma a en que est elaborada la plantilla XSLT, pero que para transformaciones e de cierto volmen de datos o plantillas con ujos complicados, puede ser u 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 realizacin de plantillas complejas puede ser poco intuitiva. Adems, al o a no permitir la declaracin de funciones, no es posible la reutilizacin del o o cdigo dentro de una misma plantilla. o 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 propsito general, por lo o que no ha de utilizarse como tal.
C.4.3.
Alternativas
Hay varias alternativas que permitir la generacin de documentos a partir an o 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 siendo reemplazado por este ultimo. a Otras opciones ser JavaScript Style Sheets (JSSS), Formatted Output Spean cication Instance (FOSI) o Sintactically Awesome StyleSheets (SASS), pero no son tecnolog estndar. as a Por ultimo, tambin se puede utilizar para realizar transformaciones de plan e tillas la tecnolog JSP, que proporcionar la potencia del lenguaje Java y pera a mitir simplicar la elaboracin de las plantillas ms complicadas. No obstante, a o a se ha preferido utilizar XSLT por la eciencia en las plantillas sencillas, que sern a las ms comunes. Genereitor cuenta con ms de 150 plantillas, que si se tuvieran a a que implementar en archivos JSP supondr una carga importante, tanto en an tiempo de compilacin como en ejecucin. o o
C.5.
Javadoc
Javadoc es una utilidad de Sun Microsystems para la generacin de docuo mentacin de APIs en formato HTML a partir de cdigo fuente Java. o o Los comentarios Javadoc estn destinados a describir, principalmente, clases a y mtodos. Como estn pensados para que otro programador los lea y utilice e a la clase (o mtodo) correspondiente, se decidi jar al menos parcialmente un e o formato comn, de forma que los comentarios escritos por un programador reu sultaran 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 documentacin de la clase. o
8 Document Style Semantics and Specication Language, lenguaje de especicacin y o semntica de estilo de documentos, especicado por el estndar ISO/IEC 10179:1996. a a 9 Standard Generalized Markup Language, lenguaje estndar de marcas generalizado (ISO a 8879:1986).
162
Javadoc es el estndar de la industria para documentar clases de Java. La a mayor de los IDEs los generan automticamente. a a
C.5.1.
Alternativas
La principal alternativa a Javadoc es Doxygen, que utiliza un mtodo similar e para generar la documentacin, pero es compatible con diversos lenguajes, entre o ellos C++, C, Java, Objective-C, Python, IDL, PHP, C# y D. Asimismo las interfaces generadas por Doxygen son ms agradables a la vista. a Doxygen, al igual que Javadoc, es multiplataforma. El motivo de la eleccin de Javadoc es que es el estndar de Sun para geo a nerar documentacin. Adems, al estar mucho ms extendido, los IDEs ms o a a a comunes ofrecen soporte nativo para este formato de documentacin, e incluso o son capaces de crearla automticamente. a
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 Autnoma de Aragn 7/2001, de 31 de mayo, de o o creacin de la Entidad Pblica Aragonesa de Servicios Telemticos: o u a 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, Ao 3, Edicin no 52, Seccin Tecnolog n o o a: http://www.e-estrategia.com.ar [11] Interfaces grcas en Java, Micael Gallego Carrillo y otros, ed. Ramn a o Aceres, 2005. [12] Adobe, Centro de desarrolladores: Introduccin a XSL: o 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

Genereitor 2: Generador de C Odigo J2EE

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Genereitor 2: Generador de C Odigo J2EE

Enviado por

Direitos autorais:

Formatos disponíveis

Universitat de Lleida Escola Polit`cnica Superior e Ingenier Tcnica en Informtica de Sistemas a e a Trabajo de nal de carrera

A todos vosotros... Gracias!

Estructura lgica de Genereitor o

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 lgica de negocio o 101

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

11.Visin global del trabajo realizado o

A. Documento de anlisis y dise o a n

A.1. Descripcin y objetivos . . . . . . . . . . . . . . . . . . . . . . . . 116 o A.2. Resumen ejecutivo . . . . . . . . . . . . . . . . . . . . . . . . . . 117

A.10.Migracin inicial de datos . . . . . . . . . . . . . . . . . . . . . . 144 o 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

CAP ITULO 1. SITUACION INICIAL

CAP ITULO 1. SITUACION INICIAL

Ventajas perseguidas con el desarrollo de Genereitor

CAP ITULO 1. SITUACION INICIAL

CAP ITULO 1. SITUACION INICIAL

CAP ITULO 1. SITUACION INICIAL

Conexin a bases de datos o

CAP ITULO 1. SITUACION INICIAL

Integracin de los mdulos de la empresa o o

Tratamiento de relaciones entre entidades

CAP ITULO 1. SITUACION INICIAL

Requisitos de las aplicaciones desarrolladas con Genereitor

CAP ITULO 1. SITUACION INICIAL

CAP ITULO 2. ANTIGUO GENERADOR

que aparecen al situar el cursor sobre una opcin determinada o

CAP ITULO 2. ANTIGUO GENERADOR

Tratamiento de errores y excepciones

Soporte para librer propias as

CAP ITULO 2. ANTIGUO GENERADOR

Scripts de compilacin y despliegue o

Estructura de proyecto obsoleta

Integracin con mdulos de la empresa o o

C.3 en la pgina 155 se detallan las caracter a sticas de la herramienta ant.

CAP ITULO 2. ANTIGUO GENERADOR

Estructura lgica de o Genereitor

CAP ITULO 3. MODELO DE 3 CAPAS

Figura 3.1: Ejemplo de aplicacin de 3 capas y 2 niveles o

Figura 3.2: Estructura f sica de Genereitor.

CAP ITULO 3. MODELO DE 3 CAPAS

Aplicaciones con conexin a BD: 2 capas o

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

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

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

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

Figura 4.3: Esquema de la base de datos de la aplicacin de ejemplo ((taller)). o