artículo - CodeCompiling

Los CLEDAs: Una nueva arquitectura para optimizar el
Desarrollo de Aplicaciones WEB
Gabriel D. GUTIERREZ, Alejandro SALAS, Angel A. PÉREZ
Minotauro C.A., Corporación Parque Tecnológico de Mérida
Mérida, Mérida 5101, Venezuela
RESUMEN
METODOLOGÍA
CLEDA es un acrónimo para “Create, List, Edit, Delete
Architecture” y comenzó como un CRUD desarrollado en Java
con Struts e Hibernate cuando Minotauro C.A. comenzó a
desarrollar aplicaciones WEB. Inicialmente se encontraron
dificultades asociadas a la gran diversidad de herramientas
necesarias para el desarrollo de cada proyecto, y se comenzó a
implementar una serie de clases, plantillas y metodologías que
facilitaran el desarrollo de este tipo de aplicaciones; a largo
plazo, esto permitió automatizar muchos casos de uso en el
desarrollo de aplicaciones WEB. Luego se estandarizaron
algunas de estas plantillas, escribiendo tags de jsp y creando
una forma estándar de manejar usuarios, roles, privilegios y
permisos en general. A esto se añadieron algunas plantillas para
manejar listas y árboles, medidas de seguridad, y un motor de
workflow, entre otros. A lo largo de este proceso, la
productividad de la compañía creció y la calidad de las
aplicaciones WEB desarrolladas mejoró considerablemente. En
este punto, Minotauro C.A. decidió que podría ser interesante
que todo ese código y esfuerzo se transformaran en un proyecto
Open Source, con la esperanza de que otros pudieran utilizar sus
ventajas, ayudar a mejorar el framework y generar
retroalimentación, naciendo así el Proyecto CLEDA.
CLEDA es un framework de software libre implementado en
Java (con una versión en PHP), diseñado para desarrollar
sistemas de información y aplicaciones Web de alta calidad a
bajos costos y con tiempos de desarrollo razonables. La palabra
CLEDA es un acrónimo para “Create, List, Edit, Delete
Architecture” e inicialmente nació como un CRUD (Create,
Retrieve, Update and Delete), usado para referirse a las cuatro
funciones básicas de bases de datos e interfaces de usuarios [1].
Palabras Claves: Desarrollo de Software, Aplicaciones WEB,
Workflow, Framework, Open Source.
INTRODUCCIÓN
Las empresas que necesitan un software a la medida usualmente
esperan que los tiempos de desarrollo del mismo sean muy
cortos, con altos niveles de calidad y costos bastante bajos. Sin
embargo, en la realidad, si se quieren altos niveles de calidad
usualmente se disparan los costos al igual que los tiempos de
desarrollo. Si se quieren costos bajos, esto trae como
consecuencia que los estándares de calidad bajen, pero no
necesariamente sucede igual con los tiempos de respuesta. Si lo
que se espera son tiempos de desarrollo bastante cortos, esto
aumenta los costos y disminuye la calidad del software
entregado. Es por esto que hay que encontrar un equilibrio entre
estas tres variables: calidad, tiempos de desarrollo y costos; para
que las opciones del desarrollo de software sean atractivas a los
clientes de la pequeña y mediana industria, quienes son
bastantes sensibles a estos aspectos.
Es así que lo que se quiere lograr en el seno de las compañías de
Desarrollo de Software como Minotauro C.A. es encontrar una
estrategia que permita mejorar los tiempos de desarrollo, con
orientación hacia la calidad de los productos desarrollados,
menores costos para nuestros clientes, y mayor competitividad
en el ámbito nacional e internacional.
Muchos de los sistemas requeridos por los clientes de las
empresas de Desarrollo de Software tienen un componente de
flujo de trabajo considerable, desarrollado de manera poco
pragmática por la mayoría de los programadores. La mejor
forma de desarrollarlos es a través de un motor de flujo de
trabajo (motor de workflow) en vista de que esta metodología
contribuye a la reducción de los tiempos de desarrollo. Esto lo
saben las grandes empresas de desarrollo de software, pero las
empresas pequeñas o programadores individuales no lo toman
en cuenta o lo desconocen.
La estrategia utilizada para el desarrollo de CLEDA está basada
en patrones de requerimientos y patrones de casos de uso.
Adicionalmente se incluye la utilización de flujos de trabajo
(workflow) para la realización de las tareas. Esto es, el 80% de
los requerimientos entran en patrones bien conocidos (crear,
editar, etc.). Gracias a CLEDA se puede prestar más atención al
20% restante de los requerimientos, correspondientes a los
casos más particulares del sistema. Además, CLEDA brinda una
serie de servicios, plantillas y componentes predefinidos que
puedes ser reutilizados entre distintas aplicaciones, así como
también, la creación de plantillas y/o componentes propios.
Patrones de requerimientos
CLEDA (Create, List, Edit, Delete Architecture) describe uno
de los patrones de caso de uso más antiguos y comunes que se
encuentran en cualquier desarrollo de software.
Un patrón clásico, y es el que inició al desarrollo de la
metodología CLEDA, se muestra en la Figura 1.
Con la librería CLEDA los casos de uso de crear un objeto,
buscar y listar, editar, eliminar, ya están soportados.
Adicionalmente se deja la puerta abierta para los casos
particulares que entran en el caso de uso otras operaciones del
objeto X, y pueden ser invocados a partir de la búsqueda del
objeto X. También para los casos de búsquedas especificas se
tiene soporte para los filtros de búsquedas personalizados.
La librería CLEDA, como lo podemos ver en la Figura 2, está
compuesta por varios módulos. Estos son:
CledaTags: Contiene todo el manejo de las etiquetas
para la visualización y construcción de las planillas, etiquetas
por omisión que pueden ser modificadas. Conjunto de Tags JSP,
diseñados teniendo como objetivo principal a CledaMVC (pero
pensados además de forma genérica para trabajar con Struts1 /
Struts2 / Stripes, entre otros).
CledaCore: Clases, componentes y plantillas que
forman el núcleo del framework (soporte directo a los patrones
de requerimientos y casos de uso).
CledaMVC: Implementación simple y limpia de un
MVC basado en Servlets (alternativa a otros frameworks MVC,
entre ellos Struts1).
CledaFlow: Componentes del motor de workflow.
Depende de CledaCommons y CledaI18N. De ser necesario, es
utilizable independientemente del resto del framework.
Figura 1: Patrón de caso de uso clásico en el que se basa CLEDA.
Otra de las características importantes de CLEDA es que con
esta metodología se posee una manera estándar de manejar a los
usuarios, que se basa en Usuarios, Roles y Privilegios. Gracias a
este manejo estándar de usuarios el sistema puede saber lo que
puede y no puede hacer cada usuario, esto es, qué planillas
puede y no puede ver, editar, entre otros; a tal grado que hasta
puede saber qué campos puede ver o editar. El menú que se
presenta en el sistema está orientado a privilegios: se construye
dependiendo de los privilegios que tenga el usuario. De esta
manera el usuario puede usar sólo lo que sus permisos le
permiten.
IMPLEMENTACIÓN
Para la implementación de la librería CLEDA se utilizó la
arquitectura MVC (Model, View, Controller), por su diseño
para reducir el esfuerzo de programación, la reutilización de
código y la facilidad del mantenimiento de los sistemas
desarrollados. Inicialmente se utilizó Struts como framework
MVC, pero actualmente se está trabajando para desarrollar un
framework MVC mas versátil llamado CLEDA-MVC. En el
caso del modelo de dominio se utilizó Hibernate. Se desarrolló
un motor de flujo de trabajo basado en redes de petri. Todo esto
se desarrolló bajo el lenguaje de programación Java.
Para la implementación de los casos de uso que están basados
en CLEDA como mínimo se debe desarrollar lo siguiente:
Caso Crear – Editar:
objetoEdit.jsp: encargado de la vista del objeto, bien
sea para crear, editar, o ver. Gracias a los cleda-tags el jsp se
construirá de acuerdo a cierta permisología (edición, sólo
lectura, etc.), a tal grado que se puede configurar para que el
usuario pueda ver o editar ciertos campos dependiendo de su rol
o privilegio.
objetoEditAction.java: encargado del procesamiento de
la data del objeto, bien sea para mostrarla como para guardarla.
Interactúa directamente con el modelo del objeto.
Caso Buscar:
objetoSearch.jsp: encargado de la vista para las
búsquedas de los objetos. El resultado puede ser una lista en la
que, dependiendo de la permisología del usuario que esté
usando este caso de uso, se puede solicitar la edición, el
despliegue de la información, o la eliminación del o los objetos
resultado de la búsqueda, u otras operaciones sobre los mismos.
objetoSearchAction.java: encargado del procesamiento
de la solicitud de búsqueda. También puede procesar la
asociación de un objeto resultado de la búsqueda con otro,
dependiendo de cómo se haya construido el modelo de dominio.
Básicamente con estos dos casos se abarca parte de la filosofía
CLEDA, en vista de que podemos crear, listar, editar y eliminar
un objeto. Adicionalmente entran en juego el modelo, el caso de
filtros y finalmente la ejecución de otros Actions.
Modelo: es el intermediario entre la aplicación y la base
de datos, en pocas palabras es una imagen de la tabla en la base
de datos que representa el objeto. Es utilizado para facilitar la
manipulación de la información del objeto y se maneja con
POJOs de hibernate.
Figura 2: Arquitectura de CLEDA
...
<doc-section name="..." />
<doc-section name="..." />
...
Caso Filtros:
objetoFilter.jsp: encargado de personalizar los filtros de
búsquedas, con el se puede configurar los filtros que se listan al
momento de usar el caso de uso buscar.
</doc-type>
objetoFilterAction.java: encargado de aplicar los filtros
de búsqueda, según la respuesta recibida del jsp.
Otros Actions: son los otros Actions que pueden
depender de un objeto o no, y se ejecutarán de acuerdo a la
acción realizada en la interfaz, como por ejemplo la asociación
de un objeto por otro explicado en el caso de uso buscar.
En general, los Actions de buscar / editar / crear se
implementan de forma que pueden ser configurados e invocados
desde otros Actions.
Figura 4: Ejemplo de manejo de documentos para un
documento inscripción.
En la descripción del documento se debe colocar el nombre del
documento, una meta-data que es información adicional (como
por ejemplo cuál es el archivo que corresponde a la vista del
documento), para el caso de jsp o php, y también cuál es el
formulario asociado al documento en el caso de swing.
Igualmente se pueden definir secciones; en este segmento se
coloca el nombre de la sección, y dentro de éste se pueden
colocar los campos que están asociados al mismo, así como
también la permisología (en que estado del flujo de trabajo son
visibles, editables o de sólo lectura).
El modelo de la definición del flujo de trabajo para un
documento (netObjeto.xml) se presenta a continuación:
Figura 3: Ejemplo de CLEDA para un objeto Usuario.
Motor de Flujo de Trabajo (Workflow)
La mayoría de las aplicaciones tiene un componente basado en
flujo de trabajo (workflow), esto es a través de manejo de
documentos. Se puede ver como una persona que solicita una
inscripción en un instituto: esta solicitud es enviada a un agente
evaluador y si es aceptada es dirigida a una instancia superior, y
el resultado de esta calificación se le hace llegar a la persona
que hizo la solicitud. Este tipo de caso es muy común y
frecuente en los sistemas informáticos y para ello CLEDA
contiene un motor de flujo de trabajo basado en documentos. En
estos casos la implementación para cada documento es
básicamente un archivo jsp (docObjeto.jsp) que es la vista del
documento, un archivo java (DocObjetoAction.java) que es el
controlador, el modelo (MDocObjeto), un archivo xml
(docObjeto.xml) que contiene la descripción del documento, y
un archivo xml (netObjeto.xml) que es la definición del flujo de
trabajo del documento. En la Figura 4 podemos ver el ejemplo
mencionado anteriormente de la inscripción.
A manera de ejemplo, se presenta un modelo de lo que debe
contener un archivo de descripción de un documento
(docObjeto.xml):
<doc-type name="...">
<meta-data key="..." val="..." />
<meta-data key="..." val="..." />
<net-petri-def name="..." doc-type="...">
<!-- *********************************** -->
<!-- The list of places in the net-petri -->
<!-- *********************************** -->
<place-list>
<place name="..." />
<place name="..." />
...
</place-list>
...
<!-- *********************************** -->
<!-- The list of trans-set and trans -->
<!-- *********************************** -->
...
<trans-list>
<trans-set name="...">
<agent-def time="..." class="..." method="..." />
<privilege name="..." />
<work-list name="..." />
<meta-data key="..." val="..." />
<meta-data key="..." val="..." />
...
<doc-section-state name="..." state="..." />
<doc-section-state name="..." state="..." />
...
<trans name="..." type="...">
<meta-data key="..." val="..." />
<meta-data key="..." val="..." />
...
<pre-place name="..." />
<pre-place name="..." />
...
<pos-place name="..." />
<pos-place name="..." />
...
</trans>
...
</trans-set>
...
</trans-list>
...
<!-- *********************************** -->
<!-- The list of states in the net-petri -->
<!-- *********************************** -->
...
<state-list>
<state-grp name="..." terminal="...">
<meta-data key="..." val="..." />
<meta-data key="..." val="..." />
...
<doc-section-state name="..." state="..." />
<doc-section-state name="..." state="..." />
...
<state-set name="...">
<place name="..." tokens="..." />
<place name="..." tokens="..." />
...
</state-set>
...
</state-grp>
...
</state-list>
...
</net-petri-def>
En la definición del flujo de trabajo se especifican los lugares,
las transiciones y los estados que conformarán la red de petri,
así como también los privilegios que definen que tipo de
usuarios pueden atender a un documento en un estado y para un
grupo de transiciones particulares.
Adicionalmente el motor de flujo de trabajo puede manejar
agentes automatizados, así como también una serie de
activaciones de transiciones: por agentes, por usuarios,
automáticas y temporizadas. El motor está bastante funcional, y
para seguirlo mejorando esperamos en algún momento hacer las
comparaciones con Workflow Patterns Initiative, esto es,
realizar las pruebas de todos los casos posibles de flujos de
trabajo, como por ejemplo secuencia y paralelismo, entre otros
[2].
Realizado utilizando las arquitecturas CLEDA y WORKFLOW,
desarrollado en 2006 por la empresa Janus Sistemas C.A, con la
colaboración de Minotauro C.A [3].
Control de Inversiones: Sistema de registro y control
de inversiones en el sector público, utiliza Tecnología a 3 capas
en Java y MySQL. Realizado utilizando las arquitecturas
CLEDA y WORKFLOW, desarrollado en 2006 por Minotauro
C.A. [4].
Para estos productos los tiempos de desarrollo fueron
considerablemente bajos gracias a la arquitectura CLEDA. El
sistema Fenix Soft se tomó aproximadamente 6 meses de
desarrollo, un tiempo sumamente eficiente considerando que se
trató de un sistema de producción bastante completo y
complejo.
CONCLUSIÓN
Debido a que las empresas que necesitan un software a la
medida usualmente esperan que los tiempos de desarrollo del
software sean muy cortos, con altos niveles de calidad y costos
bastante bajos, creemos que hemos logrado alcanzar una
aproximación que cubre esa necesidad. Claro está que no
estamos afirmando que hemos conseguido el santo grial del
desarrollo de software, sino que tenemos una herramienta que
nos podría ayudar a la hora de desarrollar aplicaciones grandes
y complejas.
Se puede considerar que hemos conseguido una relación
adecuada entre los tiempos de respuesta, la calidad y los costos
de desarrollo de una aplicación, reducción en los costos de
entrenamiento de nuevo personal, y estandarización y
uniformidad en la interfaz de usuario. Así, el uso de la
aplicación se hace uniforme, y el proceso de levantamiento de
requerimientos se simplifica y se estandariza. También existe
una relación adecuada entre los actores encargados de las
ventas, el levantamiento de requerimientos, los lideres de
proyecto y los programadores. Se simplifican los procesos de
documentación de las aplicaciones, mejora la calidad y
confianza en el código generado, y por último se presentan una
mayor escalabilidad y menores costos de mantenimiento a
mediano y largo plazo.
REFERENCIAS
[1] CRUD (2007), Create, read, update and delete. Consultado
el 10 de febrero de 2007 en:
http://en.wikipedia.org/wiki/CRUD_(acronym)
[2] Workflow Patterns Initiative (2007). Workflow Patterns.
Consultado el 10 de febrero de 2007 en:
http://www.workflowpatterns.com
[3] Janus (2006), FenixSoft. http://www.janussistemas.com
PRODUCTOS REALIZADOS CON CLEDA
Fenix Soft: Sistema de Gestión y Planificación de
Producción, utiliza Tecnología a 3 capas en PHP y MySQL.
[4] Minotauro (2006). Control de Inversiones.
http://www.minotauro.com.ve