CODEV: UN GENERADOR DE APLICACIONES WEB MULTICAPA

CODEV: UN GENERADOR DE APLICACIONES WEB MULTICAPA
David A. Meza1,2, Sergio F. Ochoa2
1
Altura Soluciones
(593 9) 544-9563
[email protected]
2
Departamento de Ciencias de la Computación, Facultad de Ciencias Físicas y Matemáticas,
Universidad de Chile.
{dmeza, sochoa}@dcc.uchile.cl
RESUMEN
Este artículo describe el diseño y la implementación de la herramienta CodEv (acrónimo de
Code Evolution), la cual genera parte de un sistema de información Web, en Java y utilizando
bases de datos relacionales. A partir del modelo de datos del sistema, CodEv genera la
funcionalidad necesaria para realizar las operaciones CRUD (Create, Read, Update y Delete)
sobre todas las tablas involucradas. Esta funcionalidad es estructurada a través de una
arquitectura multicapa, separando así las responsabilidades de presentación, negocio y datos
para cada componente. La herramienta es fácil de usar y genera un esqueleto funcional del
sistema de información en muy corto tiempo, evitando los errores más comunes, y
permitiendo tener ciclos de desarrollo más cortos. Así se hace factible realizar prototipos
rápidos, ayudando de esta manera a tener una mejor interacción con el cliente. En el artículo
se presentan la arquitectura y tecnologías de CodEv y de las soluciones generadas.
Palabras Clave: Generación de Código, Sistemas de Información Web.
1. INTRODUCCION
El desarrollo de software es un proceso laborioso,
exigente y altamente calificado. El diseño y
programación de estos sistemas es tan complejo y está
sujeto a tantos errores, que es subestimado por la
mayoría. Los clientes y usuarios de este software
generalmente no tienen idea del tamaño o la
complejidad del mismo. Tampoco saben cómo el
software va a ser diseñado, construido o inclusive cómo
va a funcionar. Por lo tanto, el desarrollo ocurre en una
frágil matriz de aplicaciones, usuarios, exigencias del
cliente, leyes, políticas internas, presupuestos,
dependencias organizacionales y requisitos que
cambian frecuentemente. 1
En el mundo de hoy, sigue creciendo la necesidad de
soportar un modelo de empresa con distribución
geográfica del trabajo, con flexibilidad y seguridad. Es
por eso que las empresas siguen optando por utilizar
1
Construido de la lógica de varios autores e ideas propias
sistemas de información que ayuden a automatizar sus
procesos y a soportar la distribución geográfica del
trabajo de sus empleados, clientes y proveedores.
Esto ha hecho que siga creciendo al mismo ritmo la
demanda por sistemas de información Web, y que
además estos sistemas requieran ser flexibles y
mantenibles al igual que los procesos que ellos
automatizan. La rápida adaptación al cambio es una
capacidad que las empresas, los procesos y los sistemas
de información deben mantener vigente desde el
momento de su concepción.
El valor estimado de inversión en proyectos de
tecnologías de información y comunicaciones (TICs) a
nivel mundial para el año 2006 fue de más o menos
US$ 900.000 millones, para un aproximado de un
millón de proyectos [StG94], [StG03]. Todos estos
valores cuentan todos los proyectos, a pesar de que
muchos de estos sistemas se terminen tarde o que ni
siquiera lleguen a terminarse [InfQ06].
El proceso de desarrollo de sistemas es aún un proceso
altamente artesanal, es decir que la calidad del producto
final va a depender fuertemente de las capacidades del
equipo de desarrollo. A pesar de los enormes avances
que se han hecho en el ámbito de la ingeniería de
software, el desarrollo de estos sistemas está aún lejos
de ser un proceso previsible.
En la actualidad si un cliente requiere previsibilidad en
los resultados de un software que desea desarrollar,
entonces necesitará contar con un equipo de altamente
calificado. Por otra parte, ese equipo altamente
calificado tendrá un costo superior al promedio, lo cual
se verá reflejado en el costo total del proyecto.
Típicamente los proyectos de software en
Latinoamérica tienden a contar con estrechos márgenes
presupuestarios.
Otro dato muy importante a considerar radica en que la
mayoría de los sistemas computacionales que se
producen actualmente, están relacionados con sistemas
de información. Es decir, son sistemas computacionales
organizados para facilitar el manejo (captura,
almacenamiento, procesamiento y presentación) de
información importante de la empresa cliente. Por
ejemplo sus procesos, productos, servicios, clientes,
proveedores y las relaciones entre ellos. Estos sistemas
computacionales
generalmente
almacenan
su
información en bases de datos relacionales.
Usualmente las empresas cliente necesitan que los
sistemas sean implantados rápidamente, y en la
mayoría de los casos no entienden por qué el proceso
de desarrollar estos sistemas se vuelve tan complejo y
costoso. En muchos casos se quejan de la alta inversión
y del ritmo demasiado lento de la implantación
tecnológica.
Por otro lado se encuentra la visión de las personas de
tecnología, quienes están encargados del desarrollo e
implantación de estos sistemas. Ellos usualmente están
restringidos por varios aspectos tecnológicos y no
tecnológicos como por ejemplo:
-
-
-
La tecnología para el desarrollo de sistemas Web y
las herramientas disponibles para hacerlo son
altamente cambiantes.
Usualmente existen restricciones sobre la
funcionalidad del sistema, y el ambiente de
ejecución.
Frecuentemente también existen restricciones en
tiempo y dinero para ejecutar los proyectos.
-
Los desarrolladores deberían seguir los estándares
y mejores prácticas de la empresa y del mercado.
Por último, una de las restricciones más
importantes que deben enfrentar los ingenieros de
software, es que los sistemas deben ser flexibles y
mantenibles, ya que se espera que sean usados por
un largo periodo de tiempo, y por lo tanto, lo más
probable es que sean modificados muchas veces
durante su tiempo de vida útil.
Últimamente se ha creado un fenómeno en el que los
sistemas se tratan de realizar con inversiones y tiempos
demasiado acotados para la realidad del proyecto. Por
lo tanto, lo que se sacrifica en la mayoría de casos, es
una buena definición de los requerimientos del sistema,
pieza fundamental para construir la funcionalidad
requerida del sistema final y/o asegurar un nivel
mínimo de calidad del producto final [Gla02].
Durante mucho tiempo se ha buscado la manera de
reducir el tiempo empleado en la producción de
sistemas, y se han tratado de implementar distintas
soluciones al problema. Una de las soluciones más
exitosas y masificadas en el tiempo se dio en el apogeo
de las aplicaciones cliente-servidor, en la década del
´90 [Mic01]. Allí los lenguajes y herramientas de
desarrollo destinados a crear cierto tipo de aplicaciones
específicas, como sistemas orientados a datos, habían
evolucionado y madurado hasta el punto de tener
capacidad de generación de código y el uso de
asistentes (wizards). Esto facilitaba las tareas
repetitivas, evitando los errores de programación o de
lógica, que en este tipo de tareas pueden costar gran
cantidad de tiempo al programador. Un ejemplo de este
tipo de herramientas fueron Visual Basic 6.0, Access u
Oracle Forms.
Los generadores de código y los asistentes facilitan el
trabajo y reducen el esfuerzo de desarrollo, permitiendo
a los desarrolladores concentrarse en las reglas de
negocio y en realizar una mejor solución, puesto que
para crear las aplicaciones no se requiere de un
conocimiento tan profundo del lenguaje de
programación y sus estructuras. De esa manera el
desarrollador pone toda su energía en lo relevante del
proyecto.
Con este tipo de herramientas se facilitó la
construcción de aplicaciones pequeñas y prototipos de
aplicaciones, simplificando el trabajo de la toma de
requerimientos y evolucionándolos a sistemas
completos. Los generadores de aplicaciones orientados
a manejo de datos, usualmente generan aplicaciones
CRUD (Create, Read, Update and Delete), de manera
simple y repetitiva. En otras palabras, mantenedores de
datos en base a tablas o joints entre tablas.
2. PROBLEMA A RESOLVER
Como se dijo anteriormente, la tendencia a acortar el
tiempo e inversión en la construcción de sistemas
provoca muchos problemas, generando una gran
cantidad de proyectos que no llegan a terminarse o que
no son usados puesto que no satisfacen los
requerimientos originales. Estos sistemas contienen
errores causados por fallas en la toma de
requerimientos, fallas en la comunicación o
entendimiento de estos requerimientos por parte los
ingenieros de software. Aún con todos los esfuerzos
para mejorar las técnicas y herramientas disponibles
para los desarrolladores, no se ha logrado que exista
una comunicación ágil con el cliente, y por tanto, una
definición clara y a tiempo de requerimientos
involucrados en el proyecto.
En muchos casos, y también por falta de tiempo, se
deja de lado el diseño de una buena arquitectura de
sistemas, considerando flexibilidad, seguridad,
capacidad de cambio y de crecimiento. Por ende,
muchos de estos sistemas presentan importantes
problemas debido a esta reducción de calidad,
específicamente
problemas
de
mantenibilidad,
extensibilidad y escalabilidad.
crean nuevos frameworks, mayores capacidades de las
herramientas de desarrollo y lenguajes de
programación, nuevas capas de abstracción y
funcionamiento de los sistemas. Todos estos avances y
cambios tecnológicos dificultan aún más el poder
establecer la infraestructura inicial para un proyecto
Web, ya que el tiempo se utilice en aprender a usar
estas tecnologías no necesariamente puede ser
amortizado en el período de toma de requerimientos o
entendimiento del problema de negocio del cliente.
Este artículo presenta y describe la herramienta CodEv
(Code Evolution), la cual pretende resolver los
siguientes problemas, para el dominio específico de los
sistemas de información Web en Java:
1) Reducir el tiempo de desarrollo por medio de la
automatización de las tareas repetitivas del
proyecto.
2) Facilitar y acelerar la definición de requerimientos
y funcionalidad del sistema en base al uso de
prototipos rápidos.
3) Ayudar a crear una arquitectura de sistemas
multicapa para que sea escalable, extensible y
mantenible.
Todo esto se logra por medio de la creación rápida de
prototipos evolutivos de aplicaciones Web multicapa.
3. SOLUCIÓN PROPUESTA
Los métodos ágiles son un esfuerzo por ayudar a
reducir el riesgo de construir el sistema equivocado, ya
que promueve una fuerte participación del cliente y la
asimilación de los cambios al sistema por medio de la
utilización de pequeñas iteraciones [Hem06]. Sin
embargo, cuando el cliente no puede o quiere participar
tan cercanamente en el proyecto, estos métodos de
desarrollo son poco aplicables. Este tipo de situación se
da especialmente cuando los ingenieros de software y
el cliente no se encuentran en el mismo lugar. Por
ejemplo, si éstos se encuentran en diferentes ciudades o
países, y la comunicación mediada por tecnología no es
eficiente para la ejecución normal del proyecto.
CodEv es un generador de aplicaciones Web Java,
orientadas a operaciones CRUD sobre a base de datos
relacionales. El código generado adhiere a una
arquitectura de sistemas multicapa, la cual representa
un esqueleto funcional de la aplicación. Esta estructura
básica usualmente representa el 40-50% de la
funcionalidad total del sistema de información. La
misma puede ser desarrollada en un tiempo muy corto
(dependiendo del sistema, no más de un par de horas),
se evitan los errores comunes, y permite tener ciclos de
desarrollo más cortos. De esta manera CodEv ayuda a
mantener una mejor interacción y trabajo conjunto con
el cliente.
Todos estos problemas están presentes en el desarrollo
de sistemas de información Web, y en muchos casos en
mayor medida que en el resto de los sistemas de
software, puesto que es el ámbito tecnológico en que
más avances se realizan actualmente. Por ejemplo, se
Al poder crear esqueletos de aplicaciones Web Java
muy rápidamente y al poder interactuar el usuario con
una aplicación funcional, el prototipo evolutivo se
convierte en un puente de comunicación entre el
usuario y el ingeniero de software, ayudando de esta
manera a definir los requerimientos más clara y
rápidamente. Esto ayuda además a reducir el tiempo de
desarrollo, ya que se parte con necesidades claras de
usuario y una aplicación con una arquitectura escalable
y mantenible, que puede ser evolucionada fácilmente.
Lo cual, visto de manera general, también ayuda a
reducir los costos.
El generador de código está orientado a un dominio
muy específico: los sistemas de información para el
Web con lenguaje Java. Por lo tanto, es en proyectos
nuevos, dentro de este dominio, donde se podrán ver
los beneficios planteados y podrá tener mayor utilidad
y aporte al ahorrar tiempo de setup y de programación.
En resumen, la ventaja de utilizar CodEv radica en que
será posible reducir el tiempo de desarrollo a partir de
la creación rápida de un esqueleto funcional de la
aplicación. De esta manera se eliminarán los posibles
errores que se puedan cometer y se reforzará la
arquitectura del sistema multicapas que promueve la
extensibilidad, escalabilidad y mantenibilidad [SEI00].
Esto facilitará además la especificación y validación de
los requerimientos.
4. CODE EVOLUTION
desarrollador dentro de la plataforma Eclipse, para
manejar así los datos del esquema de datos escogido.
CodEv fue creado sobre la base de una arquitectura de
componentes, y diseñado como un plug-in de la
plataforma Eclipse. De esa manera se pueden obtener
varias de las ventajas de estos plug-ins, como por
ejemplo: fácil de instalar, configurar y ejecutar. Las
aplicaciones que son generadas con CodEv también
están integradas dentro de Eclipse como proyectos Web
Java. Esto hace que las mismas obtengan todas las
ventajas de la plataforma, y que el proceso de
generación y edición de las aplicaciones sea
transparente para el usuario.
La contextualización de la generación del código se
basa en tomar los metadatos del esquema directamente
desde el repositorio de datos. El generador toma las
definiciones de las tablas, campos, tipos de datos, sus
relaciones, claves primarias y foráneas, los cuales
constituyen los metadatos procesables [Par07]. Con
esto construye una representación en memoria de estas
definiciones y genera los elementos necesarios (en base
a las plantillas), para que se pueda hacer el
mantenimiento CRUD avanzado de cada tabla con sus
respectivas relaciones.
La plataforma Eclipse entrega una arquitectura
extensible, con puntos de extensión claramente
definidos y documentados, llamados plug-ins. El
mecanismo básico de extensibilidad se basa en que los
nuevos plug-ins pueden añadir nuevos elementos de
procesamiento al ambiente y/o a los plug-ins existentes.
Cada plug-in tiene que estar de acuerdo con el contrato
o API definido para los plug-ins de Eclipse, para que de
esa manera pueda funcionar y trabajar con el ambiente
[ML05]. La instalación de CodEv dentro de Eclipse
sigue el proceso estándar de la instalación de plug-ins
(se debe tener J2SE y Eclipse IDE instalados
previamente para proceder con la instalación de
CodEv).
En la Figura 2 se pueden apreciar los 3 grandes
componentes de CodEv y su relación con la plataforma
Eclipse. También se puede apreciar la relación de la
plataforma con la aplicación generada, y sus capas de
presentación, negocio y persistencia. A continuación se
describen brevemente los tres componentes principales
de CodEv.
-
4.1. Arquitectura del Generador CodEv
La Figura 1 muestra un esquema de alto nivel
indicando cómo se integran CodEv y las aplicaciones
generadas, dentro del contexto de la plataforma
Eclipse. El desarrollador instala, ejecuta y configura
CodEv dentro de Eclipse para acceder a la información
de metadatos del esquema base, a partir del cual se
desea generar la aplicación Web Java. La aplicación
generada puede ser modificada y ejecutada por el
-
Manejador de Presentación: Es el componente
que se encarga de la integración con la plataforma
Eclipse; es decir, contiene la implementación de los
elementos visuales específicos de la plataforma,
para que el desarrollador pueda interactuar y
realizar la generación de manera sencilla. Además,
se encarga de la captura de información, de las
notificaciones al desarrollador y de las
actualizaciones necesarias a la plataforma Eclipse.
El tener un solo componente como punto de
integración con la plataforma Eclipse hace más
fácil la extensión y evolución de CodEv.
Manejador de BD: Este componente se encarga de
proveer el manejo de la conexión con el motor de
base de datos y la creación del modelo de
abstracción (o representación de metadatos) que
será usado por CodEv, para que el desarrollador
pueda configurar los elementos a generar. Por
medio de este componente se logra desacoplar el
generador, del lugar que se obtiene la
representación de los metadatos, pudiendo tener así
varias fuentes de datos e implementaciones de
acceso a los datos.
-
encuentra la implementación de la funcionalidad de
creación de todos los archivos necesarios para tener
una aplicación Web Java multicapa, en base a la
representación de metadatos y parámetros de
configuración. Este componente tiene lógica para
controlar la generación y regeneración de la
aplicación, creación o sobre-escritura de archivos y
directorios seleccionados.
Manejador de Generación: Es el componente que
se encarga de la generación de los archivos físicos
en base a plantillas. En este componente se
Configura
Modifica /
Ejecuta
Sistema Generador de
Aplicaciones Web
Multicapa - CodEv
Genera
Metadatos
DB
Maneja
Datos
Aplicación Web Java
generada
Figura 1. Integración de CodEv y las aplicaciones generadas con Eclipse
Figura 2. Arquitectura de CodEv
4.2.
Arquitectura de las Soluciones Generadas
La arquitectura de los sistemas generados es multicapa.
Cada capa es una partición lógica (no necesariamente
física) de los componentes de la aplicación, por lo tanto
se requiere que el programador de mantenga el
encapsulamiento de las capas y las invocaciones en el
orden adecuado, en base a la definición de la jerarquía
de capas de la arquitectura. Si eso no se respeta,
entonces se perderán todas las ventajas de contar con
una arquitectura multicapa.
Se recomienda separar la aplicación en un mínimo de 3
capas: presentación, negocio y persistencia [Fow03A],
ya que éstas representan los macro-componentes
mínimos para separar las responsabilidades en un
sistema de información Web. Dentro de estas se capas
podrán implementar otros patrones, o también tener
varias capas que la compongan. Por esa razón a este
tipo de arquitecturas se la llama multicapa.
Se dice que este tipo de arquitectura es inherentemente
más mantenible y escalable, ya que cada una de las
capas es independiente, y de esta manera se aíslan los
detalles de implementación específicos de cada una de
ellas. Cualquier cambio que se requiera realizar estará
focalizado y aislado a una capa, haciendo más fácil y
simple el cambio posterior de lógica, o inclusive, de
capas completas. Para mantener la separación de
responsabilidades e independencia entre capas, se
utilizan varios patrones de diseño muy conocidos
[GHJV98].
Client
Presentation Layer
La capa de presentación (Figura 3) se encarga de toda
la lógica de despliegue y envío de información a los
clientes. Esta capa es implementada por medio de JSP’s
y Struts2. Este últomo es un framework que incentiva
el uso del clásico patrón de diseño Model-ViewControler (MVC) [Rou07].
La capa de negocio se encarga de aislar y centralizar la
lógica de las validaciones y restricciones de la
aplicación. Esta capa es implementada por medio de
Managers, que siguen las reglas del patrón de diseño
Facade. Este patrón provee una interfaz unificada a un
grupo de funcionalidades de un subsistema o
componente.
La capa de persistencia se encarga del acceso y manejo
de datos sean locales o remotos. Esta capa es
implementada por medio de clases que siguen las
reglas del patrón de diseño DAO (Data Access Objects)
y el framework de persistencia objeto relacional
Hibernate [BK06].
4.3. Proceso de Generación
Los procesos de generación o regeneración de código
son guiados y son bastante simples. Por lo tanto,
dependiendo de las opciones de configuración
deseadas, estos procesos pueden durar tan poco como 5
minutos para generar la aplicación Web Java completa.
Después de esto se puede editar o ejecutar la aplicación
generada directamente desde el ambiente Eclipse.
* Código genérico multi-browser
* MVC con Struts2 + JSP’s +
Javascript (AJAX)
Business Layer
* Manejadores > reglas de negocio
Persistence Layer
* Persistores + Hibernate
Any convencional DB
* Mysql
Figura 3. Componentes y conexiones de la capa de presentación basada en Struts2
Existen dos modelos conocidos para la regeneración de
código: 1) comparación de archivos, es decir que se
compara archivo por archivo para ver si hay
diferencias, permitiendo al desarrollador combinar los
cambios. 2) herencia o extensión de clases base, en el
cual las clases base no son modificadas por el
desarrollador y pueden ser regeneradas en cualquier
momento. En este caso, el desarrollador puede
modificar las clases extendidas sin riesgo de perder sus
cambios por el proceso de regeneración.
CodEv ha sido construido para permitir la evolución de
la aplicación generada siguiendo un proceso no
destructivo en base a herencia. Para esto se tienen que
respetar una serie de lineamientos y prácticas de
modificación de la aplicación generada, pero que
permitirán realizar la evolución y la regeneración de la
aplicación en cualquier momento.
Para el proceso de generación se deben ingresar datos
de configuración a través de los asistentes (wizard),
como son: nombre de proyecto, paquete java, datos de
la conexión al esquema de datos. Posteriormente se
puede seleccionar las tablas y campos asociados a los
módulos CRUD que se desean generar. También se
permite seleccionar la tabla que servirá para la
autenticación de usuarios de la aplicación, además de
los campos de “nombre de usuario” y “clave” a través
de los cuales se efectuará la autenticación en sí.
El proceso de generación crea un proyecto Web Java
dentro de Eclipse, usando el nombre de proyecto
ingresado. Una vez creado, este proyecto contiene
todos los componentes necesarios y está listo para ser
probado (ejecutado). El proyecto generado tiene la
estructura presentada en la Figura 4. También, se debe
notar que las clases son creadas dentro del directorio
que representa al paquete Java, ingresado en las
opciones de configuración.
Figura 4. Estructura de un proyecto Web Java creado
con CodEv
4.4.
Se almacena la definición de los parámetros de
configuración ingresados por el usuario para la
generación, lo que da la capacidad de regeneración de
la aplicación. Para la regeneración se presentan los
datos de configuración ya cargados en un editor. Aquí
también se presentarán las nuevas tablas y campos para
que el usuario los pueda seleccionar para la
regeneración de la aplicación.
Proceso de Desarrollo Recomendado
CodEv podrá ser usado en conjunto con cualquier
metodología de desarrollo, con sus debidas limitaciones
y ajustes. Sin embargo, en el caso que se obtiene un
mejor aprovechamiento para la creación de prototipos
(o de programas funcionales finales), será con una
metodología evolutiva o iterativa-incremental. De esta
manera, la funcionalidad que se genere se podrá ir
aumentando y refinando, en base a los ajustes en los
requerimientos del cliente.
Por el lado del equipo de desarrollo, el uso de CodEv
también debe ir acompañado de un proceso de
capacitación al personal. Principalmente en lo que se
refiere al uso de las tecnologías involucradas, y
también en el uso adecuado del generador, como
herramienta y como instrumento de apoyo al proceso
de desarrollo. Esto ayudará a asegurar el éxito del
proyecto y un mejor aprovechamiento de la
herramienta.
4.5.
Figura 5. Modelo iterativo de desarrollo con generación
de código
Como se muestra en la Figura 5, primeramente se debe
realizar un análisis y diseño del dominio y de la
solución, para posteriormente crear un modelo de datos
en base al dominio de aplicación y crear el esquema de
base de datos. El generador se ejecutará contra este
esquema de datos para obtener la aplicación funcional.
Por lo tanto, se alterará la aplicación antigua para poder
obtener la nueva funcionalidad de acuerdo a las
necesidades del cliente.
Una vez finalizados estos cambios se revisa la
aplicación con el cliente y se reinicia el ciclo de
análisis y diseño de las modificaciones (o aumentos) a
la aplicación. Se altera el modelo de datos y se ejecuta
el generador el cual no dañará la programación ya
realizada en el sistema, sino que se generará la
aplicación y sus cambios, en base al nuevo modelo de
datos. En este punto puede ser necesario refactorizar
partes de la aplicación, para que funcionen con el
nuevo modelo de datos generado.
Esto formará un ciclo de iteraciones y evolución de la
aplicación que ayudará al desarrollador a cumplir sus
objetivos de aclarar y satisfacer las necesidades del
cliente de una manera rápida, al poder presentar
elementos funcionales que dan al cliente una visión
mucho más clara de lo que desea y lo que obtendrá.
El proceso descrito se asimila al modelo espiral creado
por Barry W. Bohem, que basa sus características en
sucesivas iteraciones (ciclos) que contienen una serie
de pasos, los cuales permiten la evolución del producto
deseado [Boh88].
Bosquejo de la Solución Generada en
Ejecución
A continuación se presenta un esquema general de las
páginas (elementos de presentación) que son generados
por cada una de las tablas, con sus respectivas
relaciones en el modelo de datos. Estas páginas serán
los puntos de interacción del usuario con el sistema.
Todos los elementos son páginas Web estándares
(XHtml, CSS y Javascript) que serán procesados en el
servidor dinámicamente, por medio de páginas JSP. Se
generan elementos de presentación que serán generales
para la aplicación, y otros que serán para la
visualización y administración de datos por cada tabla.
El sistema generará una pantalla de login en base a una
tabla que es seleccionada por el usuario. Esta será la
página principal y representará el punto de ingreso al
sistema desde donde se podrá acceder a las
funcionalidades del mismo. El sistema contará con
control y validación de datos para todas sus pantallas.
Esta validación se hace utilizando Struts2 en el
servidor.
Para cada tabla se genera una página de listado con los
elementos de datos. A través de esta pantalla se tendrá
acceso a las funciones para: crear, modificar y eliminar
datos de la tabla listada. Al hacer click en un elemento
de menú para la tabla que se desea revisar, se
presentará la página de listado de elementos para esa
tabla (Figura 6).
La página de listado cuenta con la capacidad de
búsqueda o filtrado de datos por cada uno de los
campos de la tabla, excepto por la clave primaria. Se
podrá colocar todas las opciones por las que se desee
filtrar el listado de elementos, y este filtro se mantendrá
para las siguientes interacciones. Los resultados que se
obtengan siempre se presentarán paginados.
Figura 6. Página con listado de datos
Además se podrán generar varios tipos de elementos de
filtrado, dependiendo del tipo de dato en la base de
datos que se esté utilizando. Para los elementos de
filtro de tipo “texto” o “numérico”, se crea una caja de
texto en donde se debe llenar el string de texto a
buscar. Para todos los campos que sean de tipo fecha,
se crea una caja de texto que al seleccionarla, aparece
una ventana flotante para la selección de la fecha a
buscar.
Para los elementos de búsqueda que representan una
relación 1-N, existe la capacidad de buscar por
elementos pertenecientes a la tabla padre (lado 1 de la
relación). Para ello aparecerá una pantalla flotante con
el listado de elementos padre que pueden ser filtrados,
para que se pueda seleccionar el elemento deseado.
Una vez seleccionado el elemento, se cierra la ventana
flotante y se actualiza la caja de selección de listado,
utilizando el nombre del elemento padre seleccionado.
Al hacer click en el enlace para la creación de un nuevo
elemento, se presentará la página para agregar un
nuevo elemento de datos a la tabla, con capacidad de
búsqueda sobre datos de la tabla padre.
5. DISCUSIÓN
Los problemas que inicialmente se plantearon, fueron
resueltos en mayor o menor grado con CodEv. Esta
herramienta permite la generación de aplicaciones Web
Java, en base a una arquitectura multicapa. Estas
aplicaciones son ricas en funcionalidad y pueden ser
generadas en muy rápidamente. Además, CodEv apoya
al desarrollador en la tarea de crear prototipos
evolutivos o aplicaciones completas, las cuales pueden
evolucionar de manera sencilla. Estas aplicaciones (o
prototipos) funcionan dentro de un ambiente de
desarrollo integrado y se pueden poner en
funcionamiento con mínimo esfuerzo.
Esto permite la interacción temprana del usuario con un
prototipo del sistema real, y de esa manera se puede
obtener retroalimentar muy valiosa, especialmente en
las primeras etapas del proyecto. La claridad y rapidez
en la definición de los requerimientos depende en gran
medida del uso de CodEv.
La herramienta cumple varios requisitos funcionales,
como son la generación en base a plantillas, la
integración con una plataforma robusta, abstracción del
modelo de metadatos y capacidad de regeneración de
las aplicaciones. También, cumple en gran medida con
diversos atributos de calidad, como son:
-
-
-
Instalabilidad, ya que el proceso de instalación del
ambiente y del generador son sencillas y rápidas.
Usabilidad, ya que el proceso de generación de los
componentes CRUD es muy fácil, es guiado, y
dependiendo de la configuración de la generación
deseada puede tomar menos de 5 minutos.
Portable, ya gracias a su integración con Eclipse,
CodEv puede ejecutar en múltiples sistema
operativos (todos los sistemas operativos para los
que exista un J2SE 5.0 o superior).
Extensible y mantenible, ya que el sistema está
diseñado para que cada componente aísle su propia
lógica y función (separación de responsabilidades)
por medio de interfaces claras de comunicación
entre ellos. La estrategia de generación de código
en base a plantillas, también ayuda a que los
sistemas sean más fácil de cambiar y extender.
Se concluyó que las herramientas de generación de
código son mejores o peores dependiendo del objetivo
que tenga el proceso de generación. Típicamente estas
herramientas pueden caracterizarse es: fáciles de usar,
con buenas capacidades de generación, o fácilmente
configurables. Sin embargo, es muy difícil el poder
crear una herramienta que pueda cumplir con todas
estas características, y por lo tanto esperar que sea útil
en todos los contextos de generación.
6. CONCLUSIONES Y TRABAJO FUTURO
La mayoría de generadores son usados por un grupo
reducido de personas que incluye a sus creadores,
empresa en la que trabajan y los grupos con
conocimientos similares. Dado que los generadores
generalmente son creados para un dominio y un
proceso específico de desarrollo, no es fácil trasladarlos
a otras empresas o contextos sin cambios o una amplia
capacitación. Por otra parte, es relativamente sencillo el
crear o usar una herramienta de generación de código,
si se tiene una base sólida de conocimiento previo. El
gran problema, como en todo cambio organizacional,
es el poder lograr el equilibrio entre las herramientas,
las personas y los procesos.
En el caso de CodEv, se empezó con el plan de crear un
generador genérico, y se terminó realizando un
generador muy ajustado al proceso de trabajo de una
empresa específica. La puesta en producción de CodEv
en dicha empresa involucró procesos de capacitación y
entrenamiento, modificación de los procesos de análisis
y diseño (para incluir prototipos evolutivos), y en
general involucró agilizar la metodología de desarrollo,
para poder sacar ventaja de la interacción con el
cliente. También, se incorporaron algunas herramientas
nuevas como plug-ins de eclipse y otras herramientas
de soporte al trabajo de la empresa.
Una de las conclusiones sacadas a partir este trabajo
indica que es mucho más fácil incorporar un ambiente
de generación de código dentro de una empresa con
procesos maduros. Esto se debe a que los proyectos se
llevan a cabo de manera similar, por lo tanto la
capacitación resulta ser más sencilla. De esa manera,
las experiencias obtenidas en un proyecto pueden ser
usadas en los siguientes. Además, el uso de CodEv en
proyectos reales, crea la retroalimentación necesaria
para realizar sus correspondientes ajustes. Como para
todo software, un generador de código y sus plantillas
de generación requerirán mantenimiento y mejoras que
involucran un tiempo no despreciable. Por lo tanto, es
muy importante seleccionar o crear herramientas que
vayan en la línea de conocimiento del personal, y del
funcionamiento de la empresa en sí. No se puede
esperar, que la empresa cambie sus procesos para poder
ajustarse al paradigma que ofrece una herramienta
específica.
También, para que la creación o el uso de una
herramienta de generación de código sea en cierta
medida exitoso, debe venir acompañado de ajustes en
la metodología de trabajo, en la capacitación al
personal y en las herramientas complementarias usadas
por la empresa. De lo contrario se corre el riesgo de
que la generación de código se convierta en una traba
más que en una ayuda. Existen muchas mejoras que se
pueden realizar a la herramienta, pero entre las más
importantes, están las siguientes:
-
-
-
-
-
-
Incorporar soporte para nuevos motores de base de
datos, por ejemplo, Oracle y SQLServer, ya que
son de los más populares en el mercado. Por el
momento CodEv sólo se tiene soporte para
MySQL.
Crear nuevas plantillas de presentación, con
colores y menús, para que se pueda seleccionar
variedad de estilos gráficos. Por el momento sólo
existe una plantilla de presentación.
Incorporar capacidades de internacionalización
para Struts2. Esto permitiría que el generador sea
usado en aplicaciones para múltiples idiomas, y
extendería la base de usuarios de la herramienta. La
aplicación generada está actualmente en castellano.
Incorporar las capacidades de generación de código
de Spring, que es un framework de Inversión de
Control (IoC) y otros servicios populares en
aplicaciones Java empresariales. Esto permitiría
que las aplicaciones generadas sean más fácilmente
configurables y mantenibles, haciéndolas más
cercanas a nivel empresarial.
Incorporar capacidad de comparación de cambios
para los archivos base que son regenerados y que
pueden ser alterados por el usuario de CodEv.
Permitir un mejor control de generación de código,
por medio de la selección de campos de relación y
de tablas que rompen relaciones de muchos a
muchos (M-N).
7. REFERENCIAS
[BK06] Bauer Christian, King Gavin, Java Persistence
with Hibernate. USA, Manning, 2006.
[Boh88] Bohem Barry. Paper. A Spiral Model of
Software Development and Enhancement,
1988,
<http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?t
p=&arnumber=59&isnumber=6>
[Fow03A] Fowler Martin, Patterns of Enterprise
Application Architecture. Boston, USA,
Addison-Wesley, 2003.
[GHJV98] Gamma Erich, Helm Richard, Johnson
Ralph, Vlissides John, Elements of Reusable
Object-Oriented Software. USA, AddisonWesley, 1998.
[Gla02] Glass Robert L., Facts and Fallacies of
Software Engineering. USA, Addison-Wesley,
2002.
[Hem06] Hemrajani Anil , Agile Java Development
with Spring, Hibernate and Eclipse. USA,
Sams, 2006.
[InfQ06] InfoQueue. Article. Interview: Jim Johnson of
the
Standish
Group,
2006,
<http://www.infoq.com/articles/InterviewJohnson-Standish-CHAOS>.
[Mic01] Microsoft. Microsoft Hails 10 Years of
Publisher,
2001,
<http://www.microsoft.com/presspass/press/20
01/oct01/10-15TenYearsPublisherPR.mspx>.
[ML05] Mcaffer Jeff, Lemieux Jean-michel, Eclipse
Rich Client Platform: Designing, Coding, And
Packaging Java Applications. USA, AddisonWesley, 2005.
[Par07] Parsian Mahmoud, JDBC Metadata, MySQL,
and Oracle Recipes: A Problem-Solution
Approach. NYC, USA, Apress, 2006.
[Rou07] Roughley Ian. Starting Struts 2, 2007,
<http://www.infoq.com/minibooks/startingstruts2>.
[SEI00] SEI, Three Tier Software Architectures, 2000,
<http://www.sei.cmu.edu/str/descriptions/threet
ier.html>.
[StG94] Standish Group. The CHAOS Report, 1994,
<http://www.standishgroup.com/sample_resear
ch/chaos_1994_1.php>.
[StG03] Standish Group. Press Release. Latest Standish
Group CHAOS Report Shows Project Success
Rates Have improved by 50%, 2003,
<http://www.standishgroup.com/press/article.p
hp?id=2>.
[Sun07] Sun Microsystems, The Java EE Tutorial.
2007,
<http://java.sun.com/javaee/5/docs/tutorial/doc/
bnbly.html>.
[Wik06] Wikipedia. Lista de países ordenados por PIB
(Producto
Interno
Bruto),
2006,
<http://en.wikipedia.org/wiki/List_of_countries
_by_GDP_%28nominal%29>.