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