UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN

Transcripción

1 UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN DESARROLLO DE COMPONENTES REUTILIZABLES DE SOFTWARE SOBRE FRAMEWORK JAVA EE MEMORIA PARA OPTAR AL TITULO DE INGENIERO CIVIL EN COMPUTACIÓN ROBERTO VARAS ACEVEDO PROFESOR GUÍA: LUIS GUERRERO BLANCO MIEMBROS DE LA COMISIÓN: JAIME SANCHEZ ILABACA ANDRÉS FARÍAS RIQUELME SANTIAGO DE CHILE ENERO

2 RESUMEN DE LA MEMORIA PARA OPTAR AL TÍTULO DE INGENIERO CIVIL EN COMPUTACIÓN POR: ROBERTO VARAS ACEVEDO PROF. GUÍA: SR. LUIS GUERRERO DESARROLLO DE COMPONENTES REUTILIZABLES DE SOFTWARE SOBRE FRAMEWORK JAVA EE El principal objetivo del presente trabajo es la obtención de un grupo de componentes reutilizables que permitan reducir los costos de desarrollo de una empresa particular. La selección de estos últimos debe basarse en los proyectos ya construidos por la empresa y su uso debe reducirse a la utilización de una una jerarquía de clases que permita que los desarrolladores se abstraigan de la lógica de aplicación en cada proyecto, enfocando sus esfuerzos en la lógica de negocio. Es posible abordar estos objetivos mediante la factorización del código que se escribe repetidamente en todos los proyectos. Este trabajo se enmarca en el contexto del desarrollo de un framework para aplicaciones web, usando la plataforma Java EE. El esquema de desarrollo sigue la línea expresada en el trabajo de Don Roberts y Ralph Johnson en Evolve Frameworks into Domain-Specific Languages, enfocándose en la fase de obtención de una biblioteca de componentes. Para validar el impacto del uso de componentes de este tipo, se ha desarrollado una estructura genérica para proyectos web, provista de un componente asociado a la construcción de mantenedores de entidades. La validación ha sido realizada sobre un proyecto real. Los resultados han sido satisfactorios y ha sido posible constatar la reducción en el costo de desarrollo. Se ha estimado un ahorro cercano al 75% con respecto a un escenario sin componentes. Se espera que a futuro se concluya el desarrollo de todos los componentes identificados y que la herramienta crezca a medida que se utiliza para el desarrollo de nuevos proyectos. 2

3 Agradecimientos Agradezco a todos quienes han sido el pilar de mi vida durante todos estos años de esfuerzo. A mi familia, mis amigos, mi mujer; mi gente. Le doy las gracias a los que han creído siempre en mí y en la llegada de este día. A mi querida madre, por su esfuerzo sin descanso y por su apoyo de siempre. A mi hermanita regalona y a su padre que siempre supo ser un gran amigo y compañero. A mi abuela, por estar siempre en los momentos difíciles para la familia. A mi mujer, por no dejar que me rindiera, por apoyarme sin dudas ni temores, por darme fuerza cuando parecía no quedar aire. A mis grandes amigos, por los insultos necesarios y aquellas reuniones sagradas de cada lunes. A aquellos con quienes me gustaría compartir estos momentos, pero ya no están; gracias por hacerme jurarles que no les fallaría. Agradezco también a mi profesor, por guiarme y alentarme cuando pensé que mi trabajo no iba a ningún lado. Gracias también a todos los profesores que dejaron huella más allá de los libros. Gracias a los amigos de Tecnova por su apoyo y por la experiencia que he ganado jugándomela en la cancha, haciendo honor a la confianza que me han dado. Gracias al coraje, la música y los libros. De nuevo, gracias a mi gente. Gracias a ti, que leerás este trabajo. Gracias a ti, que siempre estuviste presente y sonríes al saber que te menciono en estos párrafos. 3

4 Índice Agradecimientos Introducción Conceptos Básicos Justificación y Motivación Objetivos Objetivos Generales Objetivos Específicos Dominio de Aplicación Alcance del estudio Revisión Bibliográfica Frameworks y Componentes Especificación Java EE Patrones de Diseño Metodología Investigación Aproximación inicial al proyecto Levantamiento de Requerimientos Estudio y análisis de desarrollos previos Factorización de funcionalidades comunes Selección de herramientas Diseño e implementación de los componentes Validación de Re-utilización de Componentes Desarrollo Toma de requerimientos Antecedentes y reuniones con gerencia Reunión con área de desarrollo Análisis de aplicaciones Análisis de Tarificación de Telefonía Móvil Para Redes Privadas de Empresas Sistema de Administración de Acceso a Antenas de Telefonía Sistema de Recaudación y Cobranza de Compañía de Seguros Factorización de Funcionalidades Componentes seleccionadas y su impacto Selección de Herramientas Análisis de Frameworks Java EE JBoss Seam Apache Wicket Oracle ADF

5 Decisión final Análisis de Alternativas Para Capa de Persistencia Selección de IDE Resultados Arquitectura General Diseño Construcción Componentes Mantenedores Diseño Implementación Uso Reportes Diseño Validación Experiencia en Proyecto Real Conclusiones Discusión final Visión de Futuro...90 Bibliografía

6 1 Introducción En la actualidad, existen muchos frameworks de desarrollo para aplicaciones empresariales basadas en el lenguaje JAVA, en particular, cimentadas en la especificación Java EE. Sin embargo, la adopción de estos marcos de trabajo en las empresas nacionales dedicadas al desarrollo de software tiende a darse de modo relativamente forzoso. Esto se manifiesta en el hecho de que se suelen adoptar las soluciones que están de moda o aquellas con las que alguno de los miembros del staff está más familiarizado. En muchos casos, este modo de proceder desvía la verdadera visión que genera el desarrollo de un framework; esto es, el deseo de estandarizar los procesos de desarrollo y poder reutilizar el trabajo realizado previamente, de modo que se genere una entidad viva que crezca y gane energía luego de cada nueva aplicación desarrollada. Esto significa que se busca obtener una familia de productos que pueda crecer en la medida en que se le da uso, dado que la implementación de nuevas aplicaciones a partir de ella ampliará la base de funcionalidades, las que han de ser encapsuladas en componentes que pueden agilizar el desarrollo de los proyectos que se presenten en el futuro. Sin duda, este enfoque permite evitar el costo inicial del diseño y desarrollo del framework, tarea que dista bastante de la trivialidad. Sin embargo este mismo enfoque, en muchas ocasiones, resulta ser limitado por el exceso de generalidad de las soluciones adoptadas y por la variabilidad en la elección de los marcos de trabajo. Esto último trae como consecuencia el desaprovechamiento del know-how adquirido por los desarrolladores que participan en los distintos proyectos. Este valor perdido se ve acentuado por el hecho de que, generalmente, estos frameworks son utilizados sin un debido proceso de capacitación que permita desarrollar teniéndose en mente las premisas básicas que promueve cada marco de trabajo. Un claro ejemplo de ello es el hecho de que los frameworks basados en componentes son usados muchas veces sin aprovechar su poder. Esto, porque se 6

7 utilizan los componentes existentes para lograr las funcionalidades particulares de la aplicación en desarrollo, pero sin generar nuevos componentes que permitan facilitar las tareas cuando vuelvan a aparecer. Esto trae consigo el esfuerzo constante de diseñar y desarrollar una y otra vez una arquitectura básica genérica para aplicaciones web, además de la re implementación de un gran número de funcionalidades que se repiten en la mayoría de los proyectos de construcción de sistemas de información administrativos basados en web. En conjunto con la característica de re-utilización, es importante que las aplicaciones desarrolladas tengan en mente las necesidades de escalabilidad de toda aplicación empresarial. En general, las empresas exitosas tienden a crecer, contratando más gente y expandiendo sus procesos de negocio, lo que presenta la necesidad de tener soluciones escalables y fáciles de mantener. Las aplicaciones que sustentan estas soluciones deben estar preparadas para enfrentar este crecimiento y superar las restricciones que van surgiendo a medida que nuevas líneas de negocio aparecen en el camino (Ahmed K., Umrych E., 2001, pp 19). Parte de este desafío es resuelto gracias a la especificación Java EE, pero para obtener reales beneficios de esto, es necesario minimizar la distancia entre el desarrollador y los distintos módulos, componentes y servicios que provee Java EE. En este contexto se encuentra el presente trabajo, el cual consta de un estudio y análisis de un conjunto de aplicaciones desarrolladas por una empresa particular, identificando, de este modo, las funcionalidades más utilizadas. Así, se da inicio a la generación de un marco de trabajo que permita aprovechar los desarrollos ya realizados y crear esta incipiente familia de productos para, de esta forma, poder reducir costos y aumentar la calidad en los resultados obtenidos. Una vez realizado el análisis, se ha diseñado y desarrollado un proyecto de aplicación web genérica pensada para evolucionar en el tiempo, siendo mantenible y escalable, permitiendo de esta 7

8 manera que la empresa minimice los tiempos de desarrollo y maximice el valor entregado a sus clientes. El presente trabajo está acotado a la extensión de un framework Java EE de propósito general, mediante el diseño de una estructura genérica acompañada de un conjunto de componentes re-utilizables. Se cree que este trabajo establecerá la base de un sistema capaz de evolucionar hasta una familia de productos para aplicaciones web. Este sistema también debe entregar utilidades que aceleren la labor de los ingenieros desarrolladores, por medio de la integración del framework de propósito general con una suite de herramientas que resuelvan problemas técnicos ligados tanto al uso de una arquitectura web, como de la utilización de los servicios y componentes que provee Java EE. La mayoría de los frameworks de aplicaciones web (basados en el lenguaje java) disponibles en la actualidad, se encuentran más cerca de ser un marco de trabajo de caja blanca que de caja negra, dada la amplitud del mercado que quieren cubrir y la necesidad de ser útiles para la mayor cantidad posible de situaciones. Se ha realizado un análisis que ha permitido escoger uno de estos frameworks con el fin de extenderlo a través del desarrollo de un conjunto de componentes re-utilizables para que, de este modo, la empresa pueda ir generando una solución cada vez más próxima a un framework de caja negra que se ajuste a sus necesidades particulares. En la figura 1 se presenta un diagrama del esquema general utilizado para la generación de un framework típico (Roberts D., Johnson R, 1996, pp 2). En dicho gráfico es posible apreciar las etapas del desarrollo y cómo se ubican, en este esquema, los conceptos de caja blanca y caja negra mencionados previamente. 8

9 Figura 1. Esquema General de Construcción de un Framework de Desarrollo Se ha escogido la especificación Java EE para el desarrollo del trabajo, dado que es la tecnología más utilizada por la compañía y porque es la principal herramienta en el mercado de las soluciones de software para empresas. Esta especificación, entrega utilidades suficientes para obtener una solución sólida y robusta, que esté a la altura del desafío que significa generar un estándar de desarrollo para una empresa en etapa de crecimiento sostenido y que se encuentra en un exhaustivo plan de mejoramiento y estandarización de sus procedimientos. Dentro del esquema ilustrado en la figura 1, el presente trabajo se encuentra en la etapa de obtención de una biblioteca de componentes. Se ha tomado la decisión de acotar el trabajo a las etapas previas en 9

10 este esquema, dado que la construcción de un framework siguiendo todo este flujo es un proceso complejo y costoso, que supera el alcance de un trabajo como el que se presenta. Cabe destacar que este proyecto no busca la reinvención de la rueda, puesto que hace uso de herramientas Open Source cuando resulta ser necesario. Tampoco se busca hacer una combinación simple de herramientas existentes, dado que dicha tarea no logra resolver los problemas que motivan el tema de este trabajo. A modo de ejemplo, se plantea lo siguiente: para el manejo de la persistencia de los datos en las aplicaciones, es posible hacer uso de utilidades como TopLink, Hibernate o incluso implementaciones directas del patrón DAO, sin bibliotecas de por medio. Estas herramientas podrán, eventualmente, proveer implementaciones de la JPA (Java Persistence API) y, de esta forma, no será necesario realizar esta tarea de bajo nivel, considerando la existencia de herramientas sólidas en el mercado que ya resuelven estos problemas. La elección de una herramienta sobre otra ha de estar sustentada por un análisis acabado que justifique dicha decisión. 10

11 2 Conceptos Básicos Framework de desarrollo: Es una estructura de soporte definida, mediante la cual otro proyecto de software puede ser organizado y desarrollado. Representa una arquitectura de software que modela las relaciones generales de las entidades de un dominio particular. Provee una estructura y una metodología de trabajo que extiende o utiliza las aplicaciones del dominio definido. Especificación Java EE: Plataforma de programación para desarrollar y ejecutar software de aplicaciones en el lenguaje JAVA, con una arquitectura distribuida de varios niveles, basada en componentes modulares que se ejecutan sobre un servidor de aplicaciones (2009, Java EE at a Glance). Framework de Caja Blanca: Es un framework que requiere que sus usuarios tengan cierto conocimiento de su funcionamiento interno para aprovecharlo al máximo. Usualmente se extienden los comportamientos creando subclases y aprovechando la herencia (Roberts D., Johnson R.; 1996; pp 3). Framework de Caja Negra: Es un marco de trabajo que no requiere que sus usuarios conozcan su funcionamiento interno. Las funcionalidades se obtienen mediante la composición de objetos, delegando el comportamiento entre ellos (Roberts D., Johnson R., 1996, pp 8). API: Application Programming Interface, Interfaz de programación de aplicaciones. Java Persistence API: API de persistencia desarrollada para la plataforma Java EE, incluida en el estándar EJB3. Busca unificar la manera en la que funcionan las utilidades que proveen un mapeo entre los objetos de la aplicación y las entidades de una base de datos. Existen distintas implementaciones de esta API, tales como Hibernate o TopLink. 11

12 Serializable: Una clase Java es serializable si puede ser convertida a bytes y registrada en un archivo, de modo que posteriormente pueda ser transmitida a través de la red, para ser recuperada por algún cliente que lo solicite. Beans: Un Bean es una pieza de software que tiene la particularidad de ser re-utilizable. Debe ser serializable, tener sólo atributos privados, métodos get y set que permitan acceder a dichos atributos y tener un constructor público que no reciba parámetros. EJB: Entreprise Java Beans. Una de las API que forman parte del estándar Java EE de Sun Microsystems (actualmente JEE 5.0, pronto JEE 6). Su especificación detalla cómo los servidores de aplicaciones proveen objetos desde el lado del servidor CORBA: Estándar que establece una plataforma de desarrollo de sistemas distribuidos facilitando la invocación de métodos remotos bajo un paradigma orientado a objetos. Oracle Aplication Development Framework (ADF): Marco de trabajo comercial basado en Java EE para la creación de aplicaciones empresariales. Reflection API: Interfaz de programación de aplicaciones utilizada comunmente por programas que requieren la habilidad de examinar o modificar el comportamiento en tiempo de ejecución de aplicaciones corriendo en una máquina virtual Java. Permite trabajar con meta programación y manipular la información estructural de los objetos aunque ésta no sea conocida en tiempo de compilación. Generics: Característica del lenguaje Java, introducida en la versión 5, que permite que una clase o método pueda operar sobre varios tipos de datos, abstrayéndose de estos, sin perder robustez, debido a que provee chequeo de tipos en tiempo de compilación. Cuando se utiliza en conjunto con la API de reflexión es posible obtener construcciones muy poderosas, que fomentan la re-utilización de código. 12

13 Annotations: Característica del lenguaje Java que permite proveer información acerca de un programa sin que ésta forme parte de él. Los datos que se entregan a través de anotaciones no afectan la semántica del código que decoran, sin embargo sí afectan la manera en que ciertas bibliotecas o herramientas tratan este código, lo que, en consecuencia sí puede afectar el funcionamiento del programa original. RIA: Rich Internet Applications. Aplicaciones de arquitectura web que se destacan por proveer una experiencia de usuario rica en interactividad, dinámicas y sin recargas de página constantes. Se caracterizan, también, por proveer elementos multimedia que no se ven en las aplicaciones web tradicionales. AJAX: Asynchronous JavaScript and XML. Técnica de desarrollo web, utilizada principalmente para crear RIAs. Consta principalmente de código javascript que se ejecuta en el lado del cliente y se comunica en forma asíncrona con el servidor, en segundo plano. Esto implica, que la aplicación puede comunicarse constantemente con el servidor, de modo asíncrono, sin necesidad de refrescar la vista completa. JSF: JavaServer Faces. Estándar para la construcción de interfaces de usuario en el lado del servidor. Simplifica el desarrollo de la vista en aplicaciones Java EE. Representa un Framework para la construcción de la capa de vista de aplicaciones Java EE. BPM: Business Process Management. Aproximación gerencial enfocada en alinear todos los aspectos organizacionales con las necesidades y requerimientos de los usuarios. Está respaldado por herramientas tecnológicas que permiten modelar el flujo de las distintas tareas que deben realizar los usuarios en cada proceso de la organización. 13

14 Managed Beans: Beans manejados por el contenedor de aplicaciones. Estos objetos, al ser manejados por el contenedor, pueden ser inyectados en la capa de presentación, dando vida al patrón de inversión de control e inyección de dependencias. Message Driven Beans: Beans que permiten que las aplicaciones procesen mensajes de modo asíncrono. Actúan como escuchadores de mensajes JMS. POJO: Plain Old Java Object. Son clases simples que no dependen de ningún framework en especial. Este término no encapsula ninguna nueva tecnología. Ha sido acuñado buscando la revalorización del diseño simplemente orientado a objetos, evitando la complejidad introducida por algunos frameworks. Classpath: Argumento establecido a través de la línea de comandos o de una variable de ambiente que le indica a la máquina virtual de java dónde buscar clases definidas por el usuario, paquetes o bibliotecas en programas java. 14

15 3 Justificación y Motivación El desarrollo de una estructura de trabajo de las características descritas, en conjunto con el diseño e implementación de componentes re-utilizables, presenta un gran desafío técnico y teórico. Esto justifica su implementación a partir de los grandes beneficios que se pueden obtener cuando se ha logrado una solución estable y sólida, la cual permita ir reduciendo progresivamente los costos en los que se incurre cada vez que se enfrenta un nuevo proyecto. Esta reducción de costos permite obtener ventajas competitivas a la hora de realizar Propuestas Técnico- Económicas en busca de ganar nuevos clientes, lo que, en el largo y mediano plazo, permite aumentar sostenidamente las utilidades de la empresa. El proceso de desarrollo de este trabajo comprende varias etapas de distinta complejidad y que requieren de diversas habilidades técnicas y conocimiento teórico. Con el presente trabajo, también se busca resolver el problema de la heterogeneidad en los distintos desarrollos realizados por la empresa. Se pretende obtener un resultado que facilite la programación, pero que también fomente el orden en la estructura del código y dificulte la ocurrencia de malas prácticas. En general, las malas prácticas surgen por el desconocimiento de los distintos patrones de diseño que ya han sido descubiertos y que son aplicables a un sinnúmero de problemas. En muchos casos estos patrones son simples de usar, aunque el principal inconveniente es que no son simples de comprender. Parte del proceso de simplificar el desarrollo, tiene que ver con la minimización de la complejidad de la información que los desarrolladores necesitan manejar para aplicar los patrones. Para llevar a cabo esta tarea de acercamiento de las buenas prácticas a los implementadores, es necesario tener un acabado conocimiento de lo que son estas buenas prácticas, para lo cuál es preciso recopilar información de las aplicaciones realizadas comúnmente y llevar este conocimiento a un diseño simple y a 15

16 conceptos simples de comprender (Alur D., Crupi J., Malks D., 2001, pp 22). En cuanto a las necesidades de la empresa, la principal motivación pasa por la necesidad de reducir costos, aumentar la calidad de los productos entregados a sus clientes y minimizar las dificultades que ha debido enfrentar como consecuencia del crecimiento explosivo que ha experimentado. 16

17 4 Objetivos 4.1 Objetivos Generales El principal objetivo es proveer una herramienta modular, mantenible y escalable, que permita reducir los costos de desarrollo. Es deseable también que se fomente la re-utilización de funcionalidades ya generadas en proyectos construidos previamente. Gracias a esto, se espera que el framework crezca naturalmente en el tiempo y que sea lo suficientemente flexible para que su adaptación a cada nuevo proyecto no implique costos o esfuerzos adicionales. En términos concretos, el objetivo general es la extensión de un framework de propósito general Java EE, a través del desarrollo de un conjunto de componentes re-utilizables, escogidos cuidadosamente, mediante un análisis previo de un grupo de aplicaciones ya construidas por la empresa. Este producto, debe presentar ventajas reales y verificables. Estas ventajas deben manifestarse en una reducción en el tiempo y los recursos que debe utilizar la compañía en todos los proyectos que emprende. Es decir, se busca construir un conjunto de componentes reutilizables, los cuales serán seleccionados mediante el análisis de aplicaciones descrito previamente. Estos componentes deben tomar forma a partir de la construcción de una jerarquía de clases que permita que los desarrolladores se abstraigan de la lógica de aplicación en cada proyecto, enfocando sus esfuerzos en la lógica de negocio. Esto es posible gracias a la factorización del código que se escribe repetidamente en todos los proyectos. 17

18 4.2 Objetivos Específicos Obtener un catastro que permita determinar las funcionalidades que se utilizan con mayor frecuencia en un conjunto de aplicaciones ya construidas, con el fin de identificar los módulos y componentes a desarrollar. Este objetivo corresponde al análisis de aplicaciones descrito en la sección anterior. Desarrollar una estructura general que contenga los componentes más relevantes para el funcionamiento de la mayoría de las aplicaciones empresariales que el mercado atacado por la empresa requiere. Este mercado está definido por aplicaciones de diversos dominios, pero que presentan un conjunto muy bien definido de funcionalidades comunes, tales como sistemas de perfilamiento, generación y despliegue de reportes, mantenedores de parámetros y módulos de mensajería entre usuarios, entre otros. Este objetivo consta de la construcción de un proyecto genérico que contenga los módulos que son siempre utilizados en las aplicaciones de arquitectura web. Es necesario realizar esta implementación para poder incluir en ella los componentes a desarrollar, de acuerdo a los objetivos generales presentados anteriormente. Establecer los mecanismos que permitan relacionar y enlazar distintas partes del sistema, sobre todo aquellas que se basan en herramientas de apoyo externas. Este objetivo se hace necesario por constituir el pegamento que permite que todos los módulos funcionen de modo integrado y transparente para los futuros desarrolladores que utilicen la herramienta. Es decir, este objetivo es manifestación de la necesidad de que todos los componentes a desarrollar constituyan una solución integral, sin piezas de software aisladas que requieran de mucho trabajo para ser usadas. 18

19 Obtener una primera aproximación a la generación de una eventual familia de productos, que provea los cimientos para la construcción de un framework de caja negra basado en componentes y que facilite el desarrollo. Este objetivo hace patente la necesidad de que la solución provea funcionalidades que puedan ser utilizadas en múltiples proyectos, sin importar el dominio de aplicación de cada uno. La plataforma debe proveer un conjunto de funcionalidades que pueden ser configuradas para generar una estructura básica que sea punto de partida para cualquier proyecto. Diseñar e implementar un conjunto de componentes de software re-utilizables, que permitan reducir la inversión de recursos que debe hacer la empresa actualmente. Este conjunto está definido por el análisis de aplicaciones realizado, y se complementará con el análisis más fino que se lleva a cabo en la segunda parte del trabajo. Evaluar los resultados a través de ejemplos de uso real de la herramienta en desarrollos de la empresa, contrastando el tiempo y costo utilizados con una evaluación de referencia que represente el contexto original pre-implementación. Con esto, ese espera validar que efectivamente existe una mejora desde la situación anterior, previa a la realización de este proyecto. Proveer un marco de trabajo que no sea un dolor de cabeza para los desarrolladores, de fácil acceso, pero no por ello con poco poder. Se busca lograr una solución que no presente un nivel de complejidad muy alto en términos de uso, pero siempre manteniendo el control sobre lo que se está desarrollando, haciendo uso de componentes flexibles y configurables. Esto es necesario, porque el objetivo general de facilitar el desarrollo no debe verse opacado por la construcción de componentes de difícil aprovechamiento, que sólo puedan ser útiles para desarrolladores de conocimiento muy avanzado. 19

20 4.3 Dominio de Aplicación El dominio de aplicación que se pretende abarcar está acotado por las aplicaciones que se desarrollan con mayor frecuencia en la empresa. Éstas están principalmente ejemplificadas en aplicaciones web que utilizan el patrón Modelo-Vista-Controlador y que basan su interacción en el patrón de repositorio, es decir, compartiendo una fuente de datos común. La solución se enmarca en el contexto de la problemática que enfrenta la empresa escogida en particular y no busca resolver los problemas de una empresa cualquiera dedicada al desarrollo de software. Gracias a esto, es posible acotar el nicho de aplicaciones objetivo que el presente trabajo ha de cubrir. En la actualidad, los principales clientes de la empresa son compañías dedicadas a las telecomunicaciones, organizaciones gubernamentales y corredores de seguros. Los proyectos que lleva adelante se aplican a modelos de negocio muy diversos, pero que tienen muchos factores comunes en términos de requisitos funcionales y de la arquitectura utilizada. Es por ello que se observa un gran potencial de optimización en los procesos de desarrollo. Esto se demuestra posteriormente con los resultados obtenidos en el análisis de las aplicaciones de muestra. Se contempla que en el futuro se adapte el esquema al uso de middleware como colas MQ o Webservices o colas JMS, pero el uso de dichas tecnologías se escapan de los objetivos del presente trabajo, lo que implica que la necesidad de facilidad de adaptación se vislumbra como un requerimiento no funcional. Los componentes principales que se plantean como objetivo están relacionados con la interacción entre los prototipos de interfaz de usuario con el modelo de negocios y los datos subyacentes, abarcando los usos más comunes, como el manejo simplificado de formularios web, uso optimizado de recursos de base de datos, re-utilización de código para el cuidado de dichos recursos, además de un conjunto de módulos de interfaz de usuario que evite la re-implementación de controles visuales utilizados a menudo. El principal objetivo es analizar el 20

21 conjunto inicial de soluciones de software ya desarrolladas, factorizar las funcionalidades comunes, encontrar patrones que permitan automatizar -en la mayor medida posible- su futura implementación y explicitar esta automatización mediante el desarrollo final de los componentes re-utilizables. Se plantea también como objetivo la validación de la cualidad de re-utilizable de estas piezas de software. Esto se logra mediante el uso de la herramienta en un proyecto real de la empresa. 4.4 Alcance del estudio Como se ha descrito previamente, uno de los más importantes objetivos que se busca atender está relacionado con la futura implantación de un enfoque de desarrollo orientado a familias de productos. El trabajo a desarrollar es un primer paso en esa dirección y pretende ser una incipiente aproximación a la eventual obtención de una línea de productos básica para aplicaciones web. Para lograr esto, se extenderá un marco de trabajo de propósito general Java EE mediante la adición de componentes que simplifiquen la generación de instancias que requieran utilizar alguna de estas funcionalidades principales que estarán disponibles. Por ejemplo, si una línea aérea desea implementar un nuevo sistema de venta de pasajes, es probable que parte del esfuerzo del desarrollo se ponga en la generación de mantenedores de parámetros, donde los administradores podrán establecer los itinerarios, tarifas de pasajes, etc. Además es altamente probable que un área de la línea aérea quiera visualizar estadísticas de venta, a través de tablas y reportes. Dada esta diferenciación de áreas, también es necesario que el sistema pueda restringir el acceso de determinados usuarios a un grupo definido de funcionalidades. Este grupo debe ser también seleccionado de acuerdo al rol del usuario en el sistema. Este es un ejemplo básico, que se puede aplicar tanto a la línea aérea, como a una verdulería, un banco, una caja de 21

22 compensación, etc. La idea es que estos componentes de alta demanda puedan ser desarrollados con facilidad, sólo configurando los parámetros y extendiendo clases abstractas que tengan ya desarrollada la parte común de la lógica. La resolución del problema presentado por este escenario constituye la delimitación más clara del alcance del trabajo desarrollado. Sin embargo, la construcción de un marco de trabajo completo es una tarea ardua y compleja. Para poder abordar este desafío es preciso tener claridad con respecto a las aristas que se deben abordar primero, explicitando de forma temprana cuáles son los problemas que no es posible resolver en el marco de un trabajo como el que se presenta. En ese sentido, este apartado busca manifestar cuáles son las principales características que tiene un framework completo y que no forman parte del alcance de este trabajo. Las principales limitaciones del estudio tienen que ver con la lógica de bajo nivel de una arquitectura web que utilice Java EE. El software obtenido no procura ser una implementación de un framework de propósito general. No busca construir desde cero todo el intrincado mapa de relaciones técnicas entre componentes de bajo nivel. Tampoco se quiere obtener un producto equivalente a frameworks Java EE como Wicket, Struts, Spring u Oracle ADF. Esto es así, porque sería irrealizable y muy costoso embarcar un proyecto de tal magnitud. Además, tal enfoque no resolvería los verdaderos problemas de negocio que la empresa busca paliar. Esto significa, que el trabajo a realizar busca hacer uso de alguno de estos frameworks abstractos y aterrizarlo a un nivel más concreto, generando funcionalidades de alto nivel y que estén más ligados a la semántica de los sistemas que a las abstracciones técnicas que debe haber detrás de todos ellos. Las decisiones relacionadas con la elección de la fuente de esta base técnica, base que no forma parte del alcance del proyecto, han sido tomadas en una etapa de análisis con dedicación especial. 22

23 5 Revisión Bibliográfica 5.1 Frameworks y Componentes Para poder llevar a cabo un desarrollo como el que se ha propuesto, es muy importante tener claro el contexto actual en el ámbito del desarrollo de software y cómo la implementación y uso de frameworks basados en componentes forma parte fundamental en la estrategia de cualquier empresa de soluciones informáticas. El principal objetivo de toda empresa es ganar dinero y crecer de forma constante. Para lograr esto, debe obtener un perfecto equilibrio entre su nivel de ventas y la capacidad que tiene para satisfacer los requerimientos de sus clientes. Además, no puede dejar de lado factores de negocio muy importantes, como la fidelización de sus clientes. Es por ello que el enfoque del desarrollo está apuntando cada vez más a los requisitos de calidad de los productos de software. El desarrollo de aplicaciones basadas en componentes permite atacar estas necesidades de forma muy natural. En cuanto al aumento de la capacidad de satisfacción de demanda, esto se logra gracias a la aceleración de los procesos que forman parte del ciclo de vida del producto de software particular. El diseño se simplifica, gracias a que el funcionamiento de cada componente ya es conocido y, a medida que la base de componentes crece, las nuevas soluciones se construyen agrupando estas piezas, simplemente configurándolas y definiendo las relaciones entre ellas (Nash M., 2003, pp 42). La implementación se reduce a esta configuración e instanciación de componentes, además de la generación de nuevas piezas modulares que es posible reutilizar en el futuro, por lo que el proceso es mucho más rápido que en el escenario tradicional monolítico. Con respecto al aumento de los estándares de calidad, el uso de componentes apunta claramente en esta dirección. Estos últimos no representan sólo un conjunto 23

24 de herramientas para resolver problemas, son precisamente una filosofía de desarrollo orientada a la calidad (Nash M., 2003, pp 44). Michael Nash, en su libro dedicado a componentes y frameworks en Java, señala: Una de las ventajas de un componente re-utilizable es que ha sido, precisamente, reutilizado. Esto significa que ha sido probado en otras aplicaciones y se sabe que su desempeño para llevar a cabo su función particular es correcto. (Nash M., 2003, pp 44) Esto explicita claramente una de las grandes ventajas que tiene el desarrollo de estos componentes en términos del aumento en los estándares de calidad de una empresa de desarrollo de software. Es posible ver con mayor claridad la importancia del concepto de calidad como factor fundamental en el desarrollo de software a través de un breve análisis de su incidencia en diversos ámbitos del desarrollo: Calidad del Ambiente: Un aspecto fundamental en la obtención de un producto de calidad es el ambiente en el que se ha desarrollado. Esto agrupa varios conceptos clave que son atacados o reflejados por la adopción de una estructura como la que se propone, dado que, con esta solución, se provee una arquitectura estándar, probada y garantizada, que le entrega a los desarrolladores las herramientas necesarias para promover el desarrollo adecuado del software (Nash M., 2003, pp 45). Calidad del Diseño: Un framework de desarrollo no consiste sólo de un conjunto de entidades concretas de software, es también un conjunto de patrones de diseño y una especificación de la forma en la que se establece la interacción entre las piezas que se crean a partir de estos patrones. Gracias a esto, los arquitectos pueden concentrarse en el 24

25 diseño específico de las funcionalidades y configuraciones que atañen solamente a cada desarrollo particular, sin tener que considerar una y otra vez la plataforma técnica y las funcionalidades estándar (Nash M., 2003, pp 46). Cumplimiento de requisitos explícitos e implícitos: Para poder satisfacer ambos tipos de requerimientos, es necesario que los desarrollos sean flexibles, de modo que puedan adaptarse a los constantes cambios que tienen los requisitos de los usuarios. Un marco de trabajo basado en componentes promueve la flexibilidad, por lo que se presenta como un remedio natural al eterno problema del cambio en los requisitos (Nash M., 2003, pp 46). Planificación: Por su naturaleza, un framework basado en componentes provee la información suficiente para poder desarrollar una planificación relativamente precisa y libre de sorpresas a futuro. La experiencia de re-utilización permite ir refinando las estimaciones, logrando cada vez planificaciones más precisas (Nash M., 2003, pp 47). Minimización de defectos de código: La mejor manera de reducir los errores en el código es reducir el código. Esto se simplifica al trabajar con una arquitectura que centralice las tareas realizadas comúnmente y que sólo requiera implementar secciones pequeñas de lógica particular, exclusiva de cada aplicación (Nash M., 2003, pp 47). Estándares de programación: La adopción de convenciones y de estándares de programación permite reducir aún más la cantidad de errores en el código y además agiliza el desarrollo (Nash M., 2003, pp 47). Detección de errores y testing: El esfuerzo invertido en la etapa de pruebas se reduce de manera constante, dado que, a medida que los componentes se van reutilizando, sus funcionalidades generales no requieren ser probadas nuevamente y el enfoque se reduce a 25

26 la validación de los puntos de flexibilidad, donde se incluye la lógica de cada aplicación en particular (Nash M., 2003, pp 48). Documentación: Por las mismas razones que facilitan la realización de pruebas, es posible generar una documentación más precisa y de calidad, dado que el esfuerzo se centraliza en la documentación de las funcionalidades particulares (Nash M., 2003, pp 48). Soporte y capacitación: El uso de frameworks y componentes permite obtener aplicaciones consistentes, cuyas funcionalidades comunes facilitan la capacitación y el soporte (Nash M., 2003, pp 48). Mantenibilidad: Para poder proveer soluciones que no se estanquen en un contexto tecnológico particular, es necesario que las aplicaciones crezcan y puedan tener nuevas funcionalidades y capacidades, que permitan obtener soluciones más sólidas y resolver un espectro más amplio de problemas. La re-utilización de componentes permite reducir el esfuerzo de mantenibilidad al mínimo, dado que los cambios al núcleo de la estructura y a los componentes ya existentes suelen ser mucho menos frecuentes que la adición de nuevas funcionalidades (Nash M., 2003, pp 49). Todos estos factores permiten observar la importancia que tiene un trabajo de estas características para una empresa en expansión. Estos puntos están siendo considerados de modo prioritario por la empresa, lo que se ha manifestado explícitamente en la creación de un área de aseguramiento de calidad, encargada de certificar que todos los proyectos cumplan correctamente con los puntos detallados previamente. Es por ello que el desarrollo de este trabajo se enmarca en un proceso de modernización y mejoramiento de los procesos de negocio en la empresa. 26

27 5.2 Especificación Java EE La decisión de utilizar la especificación Java EE como base del trabajo a realizar tiene que ver, principalmente, con el hecho de que es la arquitectura para aplicaciones empresariales que mejor se ajusta a un ambiente empresarial distribuido (Alur D., Crupi J., Malks D., 2001, pp 30). Particularmente, la compañía utiliza esta especificación en una serie de proyectos, dado que permite obtener soluciones sólidas, basadas en herramientas probadas extensivamente. Todo esto se da, principalmente, gracias al crecimiento del conjunto de herramientas disponibles en la especificación, tales como el estándar EJB3. La arquitectura EJB provee un estándar para desarrollar componentes re-utilizables del lado del servidor, los que se ejecutan en el contexto de un servidor de aplicaciones, que gestiona la utilización de los recursos. Estos componentes EJB, llamados Enterprise Java Beans, proveen persistencia, procesamiento de negocios, manejo de transacciones y capacidades de procesamiento distribuido para aplicaciones empresariales, es decir, el estándar provee portabilidad para componentes de negocio (Alur D., Crupi J., Malks D., 2001, pp 29). Esta portabilidad es, en gran medida, responsable del éxito de la especificación en la actualidad. También es posible implementar operaciones asíncronas de modo muy sencillo, a través del estándar de mensajería JMS. La especificación Java EE cuenta con una plataforma multicapa, como es posible apreciar en el siguiente diagrama: 27

28 Figura 2. Arquitectura Java EE Las capas que componen esta arquitectura, son las que se detallan a continuación (Alur D., Crupi J., Malks D., 2001, pp 32).: Capa Cliente: Capa que interactúa con los usuarios y despliega información para ellos desde el sistema. La plataforma Java EE soporta distintos tipos de clientes, tales como navegadores HTML o applets y aplicaciones Java. Capa Web: La capa web genera lógica de presentación y acepta respuestas de usuarios desde los clientes. A partir de las solicitudes del usuario, la capa web delega las solicitudes según sea necesario para generar las respuestas que se envían de vuelta al usuario. 28

29 Capa de Negocio: Es la capa que maneja la lógica del núcleo del negocio. La capa de negocio provee las interfaces necesarias a los componentes subyacentes de servicios de negocio. Estos componentes de negocio están típicamente implementados como EJB, soportados por un contenedor de EJBs que facilita el ciclo de vida de estos últimos, además de manejar la persistencia, transacciones y administración de recursos. Capa de Sistemas de Información Empresarial: Capa responsable de la información de los sistemas empresariales, incluyendo sistemas de gestión de bases de datos, sistemas de procesamiento de transacciones, sistemas legados y sistemas de planificación de recursos. En esta capa se realiza la integración de las aplicaciones Java EE con otras aplicaciones legadas de la empresa. Además de la visión general de las capas, para comprender a cabalidad la especificación, es preciso conocer los componentes nucleares de una aplicación Java EE. Estos son los siguientes (Alur D., Crupi J., Malks D., 2001, pp 34): Componentes de aplicación Java: Programas independientes Java que se ejecutan en el contenedor de aplicaciones. Componentes Applet: Applets Java que se ejecutan en un contenedor de applets, usualmente soportados por un navegador web. Servlets y JSPs: Componentes de la capa web que se ejecutan en un contenedor web. Los servlets y JSPs proveen mecanismos para la preparación dinámica de contenido, procesamiento y formato relacionado con la presentación. Componentes EJB: Componentes de negocio de baja granularidad, ejecutados en un contendor EJB, usualmente incluido en el servidor de aplicaciones. Los EJBs se dividen 29

30 principalmente en dos tipos: beans de sesión y beans de entidad. Los beans de sesión son adecuados para el procesamiento de flujos de trabajo. Pueden ser Stateful o Stateless. Un EJB de sesión Stateless no permite conocer su estado a lo largo de su ciclo de vida. A diferencia de ellos, los EJB Stateful permiten conocer información de estado a través de las llamadas a métodos que determinan el ciclo de vida del componente. Los beans de entidad son utilizados cuando un componente de negocio debe ser almacenado con algún medio de persistencia para, luego, ser compartido entre varios usuarios. La persistencia de estos componentes puede ser manejada por ellos mismos o por el contenedor. En el primer caso, cada bean de entidad debe proveer los métodos necesarios para el manejo de la persistencia. Por último, los servicios estándar que todo producto Java EE soporta son los siguientes: HTTP: Protocolo estándar para comunicación a través de la web. HTTPS: Igual a HTTP, pero con la adición de una capa de sockets segura. JDBC: API estándar para el acceso a recursos de bases de datos. JavaMail: API que provee un marco de trabajo independiente de la plataforma y del protocolo para el envío y recepción de correo en Java. Java Activation Framework (JAF): API utilizada por otros paquetes, principalmente para determinar el tipo de una pieza arbitraria de datos, encapsular el acceso a ella, descubrir las operaciones disponibles en ella e instanciar un bean apropiado que pueda ejecutar estas operaciones. Remote Method Invocation (RMI): Protocolo que permite la ejecución remota de métodos. 30

31 JavaIDL: Servicio que incorpora CORBA a la plataforma Java para proveer interoperabilidad utilizando un lenguaje estándar de definición de interfaces. Java Transaction API (JTA): Conjunto de APIs que permiten realizar manejo de transacciones. Las aplicaciones pueden utilizar la JTA para iniciar, confirmar o cancelar transacciones. JMS: API que permite el intercambio de mensajes a través de colas. Java Naming and Directory Interface (JNDI): Interfaz unificada para acceder a distintos servicios de nombres o directorios. JNDI se utiliza para registrar y buscar componentes de negocio u otros objetos orientados a servicios en un ambiente Java EE. 5.3 Patrones de Diseño Los patrones de diseño son un tema importante para el presente trabajo, dado que son parte fundamental en la teoría que sustenta los frameworks de desarrollo. Son también bandera de lucha cuando se busca obtener productos que se puedan reutilizar. Es por ello, que es preciso comprenderlos a cabalidad, para poder sacar el máximo provecho de la inversión de control y desarrollar componentes re-utilizables que, a su vez, sean fáciles de extender y conectar entre sí. Con el fin de que la estructura obtenida pueda satisfacer los requerimientos de calidad que la empresa busca atender, es preciso utilizar medios que permitan cumplir con puntos tan relevantes como el encapsulamiento de datos y algoritmos, separación de intereses, modificabilidad y mantenibilidad, entre otros. Para lograr esto, no se puede dejar de tener en cuenta los patrones de diseño asociados a la orientación a objetos, base del desarrollo planteado. La siguiente tabla muestra posibles patrones de diseño a utilizar cuando distintas porciones de un framework cambian de aplicación en aplicación (Roberts D., Johnson R., 1996, pp 6): 31

32 Tabla 1. Patrones de Diseño y Problemas que Resuelven Qué Varía? Algoritmos Acciones Respuesta al cambio Interacción entre objetos Objeto siendo creado Interfaces de objetos Patrón de Diseño Estrategia Comando Observador Mediador Método Fábrica Adaptador Estos no son los únicos patrones que facilitan la re-utilización de código. Además de estos, se cuentan patrones como el del método plantilla, fachada, puente o decorador. El patrón más utilizado durante el desarrollo del presente trabajo es el patrón del método plantilla, el que consiste en la definición del esqueleto de un algoritmo en una operación, delegando algunos pasos a subclases. El método plantilla permite que las subclases redefinan ciertos pasos de un algoritmo sin modificar su estructura (Gamma E. et Al., 1995, pp 360). Figura 3. Patrón Método Plantilla. 32

33 6 Metodología A continuación se describen las etapas que han dado forma al producto. Se entrega una descripción sucinta de cada etapa, dado que posteriormente se provee información más detallada en la sección destinada al Desarrollo y Resultados obtenidos. 6.1 Investigación Ha sido indispensable destinar esfuerzo a una etapa preliminar dedicada a la investigación de los temas más relevantes que forman la base teórica del trabajo realizado. Esta investigación tuvo como fin allanar el camino al análisis y diseño de la solución, sin tener que volver en repetidas ocasiones a visitar referencias básicas. Para la consecución de los objetivos planteados, ha sido necesario investigar, a lo menos, los siguientes temas relevantes: Herramientas, componentes y servicios que provee la especificación Java EE Impacto y utilidad real de la utilización de frameworks y familias de productos en empresas dedicadas al desarrollo de software Patrones de diseño orientado a objetos, que forman parte fundamental de la conformación de las funcionalidades a construir. Esto, con el fin de satisfacer los requisitos de calidad y estándares mínimos que busca alcanzar la empresa 6.2 Aproximación inicial al proyecto Ha sido importante realizar un acercamiento preliminar a las etapas más importantes del desarrollo, con el fin de reducir el tiempo invertido en estas fases, además de lograr una comprensión clara y completa de las necesidades de la empresa. Esta aproximación se pone de 33

34 manifiesto en 2 actividades importantes: Reuniones preliminares de toma de requerimientos de alto nivel Análisis de aplicaciones construidas por la empresa previamente 6.3 Levantamiento de Requerimientos El primer paso concreto en el proceso ha sido realizar la toma de requerimientos específicos y definitivos de la empresa, identificando los principales objetivos que se deben considerar en el desarrollo. En esta etapa ha sido posible definir restricciones para las etapas posteriores y se ha buscado lograr consenso con respecto a los resultados de las etapas previas. 6.4 Estudio y análisis de desarrollos previos Esta etapa consta del estudio y análisis de un conjunto de aplicaciones ya desarrolladas por la empresa, en busca de la identificación de funcionalidades que son solicitadas por los clientes con alta frecuencia. Este estudio ha sido realizado con el objetivo de obtener la primera visión necesaria para el diseño e implementación de los componentes a construir. Esta es una de las etapas más importantes, puesto que representa el núcleo del análisis y el verdadero trabajo de ingeniería. Gracias a este análisis es posible determinar el alcance del proyecto y el enfoque que es preciso darle. 6.5 Factorización de funcionalidades comunes En esta etapa se ha realizado la efectiva factorización de funcionalidades frecuentes, de acuerdo a los resultados obtenidos en el estudio previo, analizando el costo e impacto de su desarrollo con respecto a la solución global que se quiere lograr. 34

35 6.6 Selección de herramientas Esta fase, consta del análisis y selección de las distintas herramientas a utilizar para la implementación de los componentes. Es posible dividirla en 3 etapas: Análisis y Selección de Framework Java EE a utilizar como base: Se han analizado 3 candidatos principales, dadas las necesidades establecidas en la etapa de levantamiento de requerimientos. Una vez escogidas estas 3 alternativas, se han analizado sus pros y contras, determinando cuál se ajusta más a los requisitos planteados. Análisis y selección de implementación de la JPA: Se consideró dedicar tiempo a esta tarea, dado que la gran mayoría de los proyectos construidos por la empresa hacen uso de bases de datos relacionales como medio de persistencia y, teniendo en cuenta este hecho importante, es preciso estandarizar la forma en la que la estructura general ha de gestionar el acceso a la información. No es posible realizar la implementación de componentes reutilizables si se genera una dependencia fuerte en un tema tan delicado y crucial como es el manejo de los datos. Análisis y selección de IDE a utilizar: Actualmente en el mercado hay una gran cantidad de Ambientes de Desarrollo Integrados (IDE) para simplificar la construcción de aplicaciones empresariales basadas en la especificación Java EE. La utilización de cualquiera de ellos tendrá impacto en el tiempo invertido en el desarrollo. Este impacto está directamente relacionado con el soporte que el IDE seleccionado tenga para el framework utilizado. Es por ello que ha sido necesario destinar tiempo al análisis de un conjunto de alternativas para cumplir esta función. La decisión final está ligada fuertemente al soporte del IDE para el framework. 35

36 6.7 Diseño e implementación de los componentes En esta etapa se contempla el diseño y generación de la estructura general, la que contiene los módulos principales que, con alta probabilidad, formarán parte de la gran mayoría de las aplicaciones que se construirán utilizando los componentes. Esta estructura tiene su base en la arquitectura propuesta por el framework seleccionado. Los componentes que se planea implementar son resultado del análisis de aplicaciones. 6.8 Validación de Re-utilización de Componentes Por último, es preciso validar que el producto obtenido satisfaga los requerimientos que motivaron su desarrollo. Es decir, se debe demostrar que los componentes son efectivamente reutilizables. Para ello, se presenta un caso de ejemplo real de un proyecto realizado por la empresa usando los resultados obtenidos hasta el momento. Se presenta una evaluación de referencia para la funcionalidad principal y se contrasta con el tiempo que efectivamente se utilizó gracias a la herramienta obtenida. Este ejemplo se basa en un proyecto real realizado por la empresa. 36

37 7 Desarrollo El primer paso en busca de la resolución del problema planteado apunta a la obtención de un enfoque más claro y detallado del producto que se quiere obtener. Para esto, se realizó una serie de reuniones con empleados de diversas áreas en la empresa en busca de una solución de consenso. Esta fase derivó en el establecimiento de prioridades y en la generación de una planificación más concreta, con metas más claras y definidas. Una vez finalizada esta fase previa de definición, se ha realizado un análisis al conjunto de aplicaciones escogidas, desentrañando el contexto de cada uno y obteniendo un resumen de sus objetivos. Esto, con el fin de descubrir las principales reglas de negocio, además de explicitar la diferencia existente entre los dominios de aplicación y la similitud en la arquitectura general y las funcionalidades más importantes. Luego de este análisis fue posible determinar las funcionalidades más importantes y que se desarrollan con mayor frecuencia. Se realizó la factorización de estas funcionalidades y se generó la base del plan de trabajo a llevar a cabo. Cabe destacar que la decisión sobre la prioridad de implementación estuvo influenciada por la oportunidad que se le presentó a la empresa de reducir los costos de implementación de un proyecto contemporáneo al desarrollo del presente trabajo. Es en este punto donde se marca un quiebre, dado que se completa la fase teórica de análisis y definición, para pasar a la etapa concreta de selección del framework base y de las herramientas que lo han de acompañar. La selección del framework base es el siguiente paso. Para ello se preseleccionaron 3 candidatos y, tras un análisis de ventajas y desventajas, tanto técnicas como comerciales y estratégicas, se escogió aquel que era capaz de resolver de mejor manera las necesidades de la empresa. Luego se analizaron implementaciones de la JPA y un conjunto de IDEs, de modo tal que la herramienta final obtenida para la empresa fuera la mejor alternativa posible. 37

38 Una vez reunido el conjunto de herramientas adecuado, ha sido posible comenzar el diseño y desarrollo de la arquitectura general, además de la implementación de los primeros prototipos y versiones de los componentes finales. Por último, ha sido posible realizar pruebas reales del uso de uno de los componentes, obteniendo estimaciones sobre el ahorro de tiempo y recursos que se pueden obtener gracias a la herramienta. Todo esto, gracias a la utilización real de esta en un proyecto real. A continuación se describen todas estas fases en más detalle, y se discuten los resultados obtenidos y el impacto que tiene la solución, además de la perspectiva de la empresa con respecto al uso del producto obtenido. 7.1 Toma de requerimientos Antecedentes y reuniones con gerencia Se han concertado reuniones preliminares de levantamiento de requisitos con las gerencias de arquitectura y desarrollo de la empresa, con el fin de recabar antecedentes claros sobre los objetivos que se quieren alcanzar. Gracias a estas reuniones ha sido posible acotar el desarrollo a las principales necesidades de la compañía. Esta empresa de desarrollo de software a medida, se ha visto en el problema de manejar un crecimiento explosivo, generado a partir de un aumento muy rápido de los niveles de venta. Esta expansión de la demanda trae consigo el evidente problema de tener que encontrar los mecanismos adecuados para poder satisfacerla. La primera solución tiene que ver con la contratación de nuevos recursos y la optimización de la asignación de aquellos con los que se cuenta. Sin embargo, esta aproximación no resulta suficiente y es por eso que se debe adoptar 38

39 medidas de mediano y largo plazo que permitan maximizar la capacidad que la empresa posee para lidiar con la construcción de los nuevos proyectos. Dentro de estas medidas se encuentra la creación de un área de QA, a cargo de la gerencia de arquitectura, cuya función principal tiene que ver con la definición de procesos internos que garanticen la entrega de productos de calidad a los clientes, cumpliendo con las restricciones de costo y tiempo. A pesar de que esta es una medida de alto impacto, tampoco resulta ser una acción mágica que ha de resolver todos los problemas que el mencionado crecimiento explosivo ha generado. Es así como, dentro de las medidas que se plantean como respuesta a los problemas surgidos, nace la intención de implementar -a mediano o largo plazo- un enfoque de desarrollo orientado a familias de productos, aun cuando los dominios de aplicación manejados por los clientes sean muy diversos. Esto es posible dada la identificación de factores comunes en la gran mayoría de las aplicaciones que se desarrollan, sin importar el dominio específico en las que estas últimas se enmarcan, puesto que un alto porcentaje de la demanda que maneja la empresa está enfocada a arquitecturas de aplicaciones web, lo cual se ha establecido como una tendencia bastante pronunciada en el mercado. La empresa busca acelerar los tiempos de desarrollo, dejando atrás la constante reinvención de la rueda. En ese proceso de búsqueda se enmarca el presente trabajo, generando la base de un mecanismo que permita enfrentar los futuros desarrollos con una visión más cercana a lo que son las familias de productos, reutilizando componentes generados con anterioridad. Un primer paso en esa dirección, es la generación de una arquitectura general que contenga una base de componentes re-utilizables. Esta arquitectura básica se debe construir a partir de un framework de desarrollo de propósito general, el cual debe ser extendido para adecuarse a la realidad de la empresa, proveyendo un conjunto de componentes re-utilizables. Estos últimos deben satisfacer 39

40 las necesidades que se presentan con más frecuencia en los problemas que enfrentan los clientes. Durante las reuniones preliminares se ha buscado determinar cuál ha de ser el enfoque del trabajo a realizar, es decir, aprovechando la experiencia de los miembros de las gerencias de desarrollo y arquitectura, se busca definir cuáles son las necesidades más frecuentes que se debe satisfacer y dónde están los puntos críticos que se están dejando pasar, puntos que, de ser abordados adecuadamente con el nuevo enfoque, pueden acelerar la construcción de proyectos futuros gracias a las soluciones del pasado. Concretamente, se ha establecido que la percepción general señala que las funcionalidades típicas, presentes en la gran mayoría de los desarrollos realizados por la empresa durante sus años de funcionamiento, son las siguientes: Mantenedores de parámetros: Constan de interfaces gráficas y componentes que permiten visualizar, crear, actualizar y eliminar datos paramétricos de las aplicaciones. Generalmente estos datos están almacenados en tablas en un sistema de gestión de bases de datos. Suelen estar definidos por una entidad principal y otras entidades satélite que se relacionan con la principal. La idea es generar componentes parametrizables que permitan obtener estos mantenedores rápidamente y en pocos pasos. Sistemas de perfilamiento: Son la puerta de entrada a todo sistema web que requiera acceso restringido y diferenciado de su base de usuarios al conjunto de funcionalidades que provee: un elemento fundamental de los sistemas de información administrativos. Consta de módulos de registro para el ingreso de nuevos usuarios, autenticación para el control del acceso de aquellos que ya forman parte de la base de datos y también módulos de administración de funcionalidades, los que permiten asociar permisos de acceso de cada rol a las distintas partes del sistema. 40

41 Generación de reportes y gráficos: Componentes que se alimentan de un conjunto definido de entidades y que permiten mostrar tablas de datos, además de exportación a un grupo determinado de formatos, tales como PDF, XSL, ODF, entre otros. También deben permitir desplegar los datos como gráficos de distinto tipo. La intención es que el framework provea el núcleo de estas características y que con poco esfuerzo de parametrización y personalización se pueda obtener la instancia particular que satisfaga las necesidades de cada proyecto. Sistemas de mensajería entre usuarios: Proveen mecanismos que facilitan la comunicación entre usuarios con distintos roles en un sistema. Agilizan los flujos de trabajo en un gran número de aplicaciones y consisten, principalmente, de bandejas de mensajes asociadas a cada usuario, además de una estructura de mensaje muy similar a la estructura de un mensaje de correo electrónico. En estas reuniones preliminares también se empezó a esbozar la idea de utilizar una herramienta de generación de fuentes que permita acelerar el desarrollo del código que no ha sido abordado aún por componentes, además de aquel que permite hacer uso de los componentes ya desarrollados. La idea es comenzar la construcción de una solución de largo plazo, encarnada en la arquitectura del framework y la biblioteca de componentes asociada; pero además se desea complementarla con herramientas que permitan obtener resultados tangibles en el corto plazo. 41

42 7.1.2 Reunión con área de desarrollo Siguiendo con la toma de requerimientos, se sostuvo una reunión con los desarrolladores y arquitectos más experimentados de la empresa, con el fin de aunar antecedentes concretos sobre la arquitectura y principales funcionalidades de los proyectos desarrollados por la empresa. El tema central de la reunión fue la búsqueda de alternativas para optimizar la etapa de construcción en el ciclo de vida del software. Se discutió sobre la experiencia con algunos frameworks para aplicaciones web, como Spring o JBoss Seam, además de algunas alternativas para la construcción de un generador de código que apoye el desarrollo con el framework y sus componentes. En ese sentido, la idea de este generador de código fue sumando consenso y se considera como parte del desarrollo final. Con respecto a la arquitectura y funcionalidades de los proyectos abordados por los ingenieros presentes, en su trayectoria dentro de la empresa, fue posible confirmar que un alto porcentaje de las aplicaciones realizadas se apegan a la arquitectura web en capas, usualmente utilizando el patrón MVC y con muchos puntos en común, a pesar de la diversidad de sus dominios de aplicación. Las funcionalidades mencionadas en esta reunión también están de acuerdo con lo señalado por los gerentes, por lo que la tendencia se fue confirmando, de cara al análisis de las aplicaciones. Otro tema tocado en la reunión tiene que ver con la reducción de la complejidad en la lógica de aplicación residente en la capa de control. Existe consenso en la idea de que el esfuerzo del desarrollo debe centrarse en la implementación de la lógica de negocio, reduciendo el tiempo invertido en enlazar las solicitudes de los usuarios finales con el flujo de los procesos de negocio. El desarrollo del presente trabajo apunta a lograr esta optimización del tiempo invertido, por lo 42

43 que se pone especial énfasis en la minimización del código que debe ser escrito para manejar la interacción del usuario con la aplicación. Se discutió también sobre un conjunto de posibilidades para implementar fácilmente y en el corto plazo el generador de código que acompañaría al framework y sus componentes. Varias de estas opciones tenían que ver con plantillas, como las que se utilizan en IDEs como NetBeans para la inserción de bloques de código. También se sugirió utilizar XDoclet. Sin embargo, para esta herramienta externa se utilizaría finalmente un proyecto básico construido en el pasado por uno de los ingenieros de la empresa, basado en la biblioteca de procesamiento de archivos XML Jelly. El proyecto consiste en una aplicación web que inspecciona una base de datos configurable, presenta las tablas encontradas en su interfaz y permite que el usuario seleccione para qué tablas desea generar las clases necesarias para el acceso a datos, utilizando el patrón DAO. Posteriormente se tomaría esta herramienta para modernizarla, migrarla desde Struts a JSF y construir plantillas que permitieran generar más clases que las que correspondían únicamente a la capa de persistencia. Más adelante se detalla el porqué es necesario considerar una forma de optimizar el desarrollo de la capa de persistencia, cuando se explicite el estudio realizado a las implementaciones de la JPA y a otras opciones tecnológicas. 7.2 Análisis de aplicaciones Para este análisis se ha obtenido un conjunto de aplicaciones típicas que han sido desarrolladas previamente por la empresa. Posteriormente se ha realizado una revisión de estas últimas y, gracias a esta revisión, es posible conocer el tipo de funcionalidades que aparecen con mayor frecuencia cuando los clientes de la empresa plantean sus necesidades para la implementación de un proyecto particular. Este análisis presenta como resultado evidente la obtención de un grupo definido de funcionalidades que son compartidas entre las aplicaciones, 43

44 aún cuando sus dominios particulares difieren en gran medida. Esta revisión confirma las decisiones adoptadas en la etapa de reuniones preliminares con la cúpula de la empresa. Se han escogido 3 proyectos para el análisis, todos ellos seleccionados, principalmente, porque son ejemplos claros de proyectos que utilizan funcionalidades muy comunes y cuyos dominios de aplicación son bastante diversos. En la presentación sucesiva se se omiten detalles específicos como el nombre de los clientes o detalles de las soluciones implementadas, por motivos de confidencialidad. La intención sólo es exponer el contexto de los proyectos y las funcionalidades que fue necesario implementar Análisis de Tarificación de Telefonía Móvil Para Redes Privadas de Empresas El proyecto consistió en la construcción de un sistema que se encarga de monitorear la tarificación que realiza una empresa de telefonía celular en sus planes para empresas. Se basa en una comparación de los archivos de registro de la tasación que realiza el sistema oficial de tarificación con la información teórica definida por el área de marketing, con el fin de identificar eventuales errores de cobro que impactan los ingresos de la compañía. Está compuesto por varios subsistemas, entre los que se cuenta un conjunto de mantenedores, a través de los cuales se puede definir la información paramétrica que forma la base del software. Estos mantenedores permiten definir las tarifas teóricas que se contrastan con los registros del sistema de tasación, además del conjunto de tarifas, horarios de cobro y servicios que forman parte del núcleo del negocio. Parte importante del proyecto está también relacionada con un conjunto de reportes que permiten que la compañía pueda visualizar en forma de tablas y gráficos los resultados de la comparación de la tasación real y la teórica, con el fin de informar a las áreas involucradas para 44

45 corregir estos errores y evitar pérdidas de dinero. Para controlar adecuadamente el acceso a los recursos, el sistema también cuenta con un subsistema de perfilamiento, que determina el menú de funcionalidades a las que puede acceder cada usuario, una vez que se ha identificado a través del mismo subsistema. La comparación se realiza a través de un proceso Java que se ejecuta diariamente. Este proceso es el encargado de interpretar los archivos que contienen los cobros reales y contrastarlos con la información que se ingresó al sistema a través de los mantenedores. Una vez que finaliza su comparación, registra los resultados en la base de datos, de modo que estos puedan ser visualizados por los usuarios en los distintos reportes. Como es posible deducir, este proceso es el enlace entre los mantenedores y los reportes. Este proyecto no tiene mucha más complejidad que la descrita. No presenta complicados flujos de negocio ni workflow, simplemente busca permitir que un determinado grupo de usuarios establezca las tarifas que se le debe cobrar a sus clientes, con el fin de que otros usuarios, de otra área, puedan validar que efectivamente se están aplicando bien los cobros correspondientes. Sin embargo, este proyecto no estuvo exento de problemas en la implementación. El proceso de pruebas fue bastante largo y hubo que realizar varias iteraciones con el cliente hasta lograr un producto que pudiese satisfacer sus necesidades. Este es un ejemplo del tipo de problemas que surgen cuando se reinventa la rueda en cada desarrollo. Recapitulando, este proyecto consta de 4 componentes principales: Un conjunto de mantenedores que permiten establecer tarifas y parámetros de sistema; un módulo de reportes que permite visualizar las diferencias entre la tarificación teórica y los cobros reales; un módulo de perfilamiento que controla el acceso de los distintos roles a los diversos recursos disponibles y un proceso java encargado de realizar la evaluación de las eventuales diferencias, enlazando los mantenedores con los reportes. 45

46 7.2.2 Sistema de Administración de Acceso a Antenas de Telefonía Sistema de información administrativo que se encarga de gestionar el acceso de un conjunto de sujetos interesados en manipular determinadas antenas de telefonía. El sistema maneja el préstamo de los llaveros que permiten que dichos sujetos ingresen a los recintos o sitios donde se ubican estas antenas. Para solicitar el préstamo de una llave, los usuarios deben ser registrados en el sistema como solicitantes, de modo que puedan completar los formularios que el proceso requiere. Una vez que los usuarios solicitan las llaves, tienen un plazo definido por el administrador para acudir a las distintas sucursales de llaves a retirar el llavero que solicitaron, trámite que se realiza a través de un usuario vigilante que valida sus datos y registra en el sistema que la llave ha sido retirada. Asimismo, cuando el solicitante ha dejado de utilizar la llave, debe devolverla en la misma sucursal, donde el vigilante registra la devolución. Si el solicitante no devuelve la llave en el plazo definido por la administración, queda marcado como usuario moroso y no puede volver a solicitar llaves hasta que resuelva su situación. Este sistema consta de varios componentes básicos, entre los que se cuentan lo siguientes: Mantenedores de Parámetros: El administrador tiene acceso a un conjunto de mantenedores, que le permiten configurar el sistema a través de la manipulación de datos. Gracias a estos mantenedores puede mantener al día la información de los llaveros, las antenas o sitios, las sucursales de llaves, etc. Sistema de Perfilamiento: Parte fundamental del sistema. Permite que se agreguen nuevos usuarios y que se gestione adecuadamente el acceso de aquellos que ya están registrados. Cada usuario tiene un único rol y ese rol define las funcionalidades a las que puede acceder. 46

47 Alarmas y Mensajería: Este proyecto implementa un subsistema de detección de alarmas y envío de mensajes a una lista de distribución cuando se han detectado problemas. Las alarmas pueden ser técnicas o de negocio. Esto significa que una alarma puede gatillarse por la falla de un sistema anexo o porque se ha detectado el ingreso no autorizado de una persona a una antena. Reportes: Uno de los requisitos impuestos por el cliente final fue la implementación de un conjunto de reportes que permitieran tener una visión del uso que tenía el sistema. Entre la información que se despliega se cuenta lo siguiente: Cantidad de llaveros solicitados y no entregados a tiempo para un período determinado Cantidad de alarmas técnicas detectadas en un período de tiempo Detalle de antenas que no cuentan con llaveros registrados El flujo de negocio es bastante sencillo, consta de un workflow simple, donde transcurre el ciclo de vida de una solicitud de llaves; desde su generación, pasando por su concreción en la entrega de las llaves, hasta su término cuando las llaves son devueltas. Hay caminos alternativos, como los que se dan cuando un solicitante deviene en usuario moroso, pero ninguno representa mayor complejidad. En términos funcionales, el flujo se ve satisfecho por los componentes detallados previamente, además de la ejecución de un conjunto de demonios de monitoreo, que permiten validar la ocurrencia de alarmas o el cambio de estado de un usuario desde activo a moroso. Lo más importante con miras a la construcción del trabajo que motiva este documento es la independencia entre estos módulos y la similitud en arquitectura con otros sistemas implementados por la empresa, como son aquellos que se describen en este mismo apartado. 47

48 7.2.3 Sistema de Recaudación y Cobranza de Compañía de Seguros Este proyecto consta de un sistema encargado de manejar la interacción de una compañía de seguros con un grupo de empresas asociadas que ofrecen sus servicios de seguro a sus clientes. Este modelo se denomina Telemercado y se basa en el principio de que una empresa determinada, que consta con una base de clientes, le ofrece a estos clientes un conjunto de servicios ofrecidos por una tercera compañía, de modo de ampliar la gama de productos que se le entrega a los clientes. Esta metodología permite aumentar fácilmente la cantidad de clientes a los que se puede llegar, pero induce ciertas complejidades que se deben manejar. Dentro de estas dificultades se cuenta una muy importante, que dice relación con la cobranza y recaudación de los servicios que se le prestan a estos nuevos clientes que no son, a priori, clientes directos. El sistema se encarga de manejar la interacción de la compañía de seguros con las demás empresas que cumplen el rol de patrocinadores de los servicios de seguro con los usuarios finales. En un resumen breve, es posible decir que el flujo de negocio se compone de una sucesión de etapas, definidas principalmente como: Generación de registros de pólizas de seguro a cobrar, envío de cobranza a empresa patrocinadora, recepción de respuesta a la cobranza enviada (reconocimiento de registros como válidos) y recepción de información de recaudación de las primas asociadas a cada seguro. Este sistema es bastante más complejo que los descritos anteriormente, pero es posible observar que, de todas formas, hay funcionalidades básicas que se repiten. Para poder manejar la comunicación con las empresas patrocinadoras, es necesario generar mantenedores que permitan configurar fácilmente la información relacionada. Además, no todas las funcionalidades están destinadas a ser accedidas por todos los usuarios, por lo que se hace necesario implementar un sistema de perfilamiento, que además, restrinja el acceso a cualquier persona que no cuente con un registro de usuario en el sistema. La plataforma también involucra 48

49 la generación de reportes que señalen todos los cobros informados a los patrocinadores, indicando el estado del reconocimiento y de los cobros efectivos. Es preciso también, que sea posible exportar estos reportes a PDF y Excel. El proyecto también contempla la implementación de procedimientos almacenados que se encarguen de interpretar los archivos intercambiados entre los distintos sistemas que interactúan en el flujo. Además se hace uso de colas JMS para realizar llamados a webservices que activan un conjunto de temporizadores que organizan la ejecución de tareas automatizadas. El acceso a la capa de persistencia se realiza con sentencias SQL directas envueltas en clases que implementan el patrón DAO. Recapitulando, el proyecto descrito es mucho más complejo que los anteriores, dado que su flujo de negocio está lleno de sutilezas que generan condiciones de borde difíciles de manejar. Esto se suma a la dificultad que presenta la integración con diversos sistemas externos. Sin embargo, dentro de su funcionamiento interno, la construcción de este proyecto también derivó en la necesidad de volver a realizar tareas que se han llevado a cabo en repetidas ocasiones en el pasado, como es la implementación de los componentes descritos previamente. El desarrollo de los mantenedores, los reportes y el manejo de perfilamiento son tareas que requieren bastante esfuerzo y que tienen un alto potencial de optimización. Dado este análisis, ha sido posible identificar la presencia de estas funcionalidades típicas, también descritas por la gerencia de la empresa en las reuniones sostenidas. Es decir, se ha confirmado el pronóstico establecido en la etapa de reuniones previas, lo que era esperable, considerando los años de experiencia de la empresa y de sus empleados. Gracias a estos resultados obtenidos, es posible abordar de mejor manera las etapas posteriores de la construcción de un framework que permita optimizar los procesos de desarrollo de la empresa, generando importantes ahorros de tiempo y recursos. Lo que, por consiguiente, también impacta 49

50 positivamente la capacidad de la empresa para enfrentar la alta demanda que debe satisfacer actualmente, dado el crecimiento explosivo que ya ha sido mencionado. 7.3 Factorización de Funcionalidades En esta sección se reunen los motivos que sostienen la decisión final sobre las funcionalidades escogidas y se describe el ahorro en esfuerzo que la empresa espera obtener a partir de la solución a implementar. La determinación final sobre las funcionalidades que se buscará empaquetar en componentes re-utilizables está sustentada de forma clara y evidente por el análisis realizado a las aplicaciones elegidas; análisis que ha arrojado resultados claros y concluyentes, entregando un conjunto inicial bien acotado y que promete entregar resultados inmediatos a la empresa, una vez que los componentes sean construidos. Los factores más importantes que deben motivar esta decisión tienen que ver con la frecuencia de uso de las funcionalidades en los proyectos, pero también es importante considerar el impacto que tiene la construcción de las mismas en las etapas del ciclo de vida del software. Esto es relevante, puesto que, más allá del potencial evidente de optimización cuando se está construyendo una pieza de software una y otra vez, se debe compensar este deseo de ahorro con los beneficios reales que se han de obtener una vez que se tenga el producto final. Para que estos beneficios sean realmente sensibles, es importante que las funcionalidades escogidas realmente impacten cada planificación. Esto, como punto importante para la decisión inicial y la primera fase de desarrollo. Más adelante, como se aprecia en el diagrama de las etapas de construcción de todo framework, se contempla la generación de entidades de granularidad cada vez más fina, con el fin de mejorar la composición de objetos e incrementar aún más la re-utilización de código y la transparencia en el uso de los componentes. 50

51 7.3.1 Componentes seleccionadas y su impacto La selección de componentes no se vio modificada con respecto a las conjeturas iniciales, dado que el análisis confirmó las estimaciones y, bajo esa configuración, los componentes escogidos son los siguientes: Mantenedores de parámetros: La estimación usual de esfuerzo que se le asigna a esta funcionalidad es de 2 días para 1 desarrollador y suele implementarse con una cardinalidad esperada de 5 instancias en cada proyecto. Sistemas de perfilamiento: La estimación usual de esfuerzo que se le asigna a esta funcionalidad es de 3 días para 1 desarrollador y suele implementarse con una cardinalidad esperada de 1 instancia en cada proyecto. Generación de reportes y gráficos: La estimación usual de esfuerzo que se le asigna a esta funcionalidad es de 2 a 3 días para 1 persona y suele implementarse con una cardinalidad esperada de 5 instancias en cada proyecto. Sistemas de mensajería entre usuarios: La estimación usual de esfuerzo que se le asigna a esta funcionalidad es de 4 días para 1 persona y suele implementarse con una cardinalidad esperada de 1 instancia en cada proyecto. Una vez obtenidos los componentes, se espera que el ahorro de esfuerzo sea de, por lo menos, un 50%. Es decir, para una funcionalidad que se estime en un día de esfuerzo para una persona, es espera que, utilizando los componentes desarrollados, se logre tener una instancia de la funcionalidad terminada en 1 día, cuando mucho. Por supuesto, esto puede variar de acuerdo a cada componente, pero la aproximación debiese estar bastante cerca de la realidad en todos los casos. 51

52 7.4 Selección de Herramientas La correcta selección de un buen conjunto de herramientas para complementar el framework es factor clave en el éxito del producto final, es por ello que se ha destinado el tiempo necesario para el análisis adecuado de todas las bibliotecas o estructuras que se han de utilizar en la búsqueda de una solución robusta que haga uso de complementos probados, sin perder esfuerzo en reinventar la rueda. Esta etapa de análisis y selección de herramienta se divide en 3 partes, de acuerdo al complemento analizado. Cada una de estas fases consistió en la revisión de 3 candidatos, buscando sus virtudes y defectos, para luego ponerlos en la balanza y así poder tomar una decisión informada. La primera etapa es la de selección de un framework base adecuado para la tarea a enfrentar. Luego se estudian las distintas alternativas para la capa de persistencia y, por último, se evalúa un conjunto de IDEs en busca de aquel que tenga mejor soporte para el framework base seleccionado. Estas distintas etapas se describen a continuación Análisis de Frameworks Java EE Una de las decisiones más importantes que es preciso tomar es la de la elección del Framework base que ha de ser extendido, dado que tendrá un alto impacto, tanto en la utilidad real que se podrá obtener como también en la solidez del producto. Es por ello que la decisión debe ser tomada con cuidado y teniendo en cuenta todas las ventajas y desventajas de los candidatos analizados. Como primer paso, ha sido necesario realizar una pre selección de alternativas posibles, dada la vasta oferta de marcos de trabajo para aplicaciones web basadas en java existentes actualmente. La vigencia, potencial de crecimiento, amplitud de posibilidades tecnológicas, integración con herramientas externas, respaldo institucional, curva de aprendizaje 52

53 no pronunciada y popularidad fueron los factores más importantes para llevar a cabo la pre selección. Una de las primeras opciones consideradas estuvo asociada al uso del framework Spring, dada su flexibilidad, poder y capacidad de integración. Sin embargo, esta opción se desechó dada la complejidad que reviste el uso de este marco de trabajo. La experiencia de la empresa ha demostrado que al utilizar Spring ha sido necesario tener siempre un coach experto en el equipo, quien se encarga de preparar el framework para que sea usado por los desarrolladores. Esto introduce una dependencia y un riesgo muy alto, dado que la empinada curva de aprendizaje de Spring no se ajusta a la capacidad de preparación de recursos con la que se cuenta. Los factores comerciales tampoco fueron suficientes para incluir Spring en la pre selección, dado que en la empresa hay muy poca experiencia de proyectos que lo hayan utilizado y no hay ningún cliente que lo plantee como requisito. El framework Struts es otro competidor que ha gozado de popularidad por mucho tiempo en el ámbito de las aplicaciones empresariales basadas en Java. Sin embargo, ah sido decisión de la empresa alejarse de esta alternativa, debido a que está poco actualizada e introduce factores de complejidad que están ausentes en otros marcos de trabajo. Su curva de aprendizaje también es pronunciada y tampoco hay clientes solicitando a la empresa desarrollos con Struts actualmente. Otro factor desfavorable para las alternativas mencionadas previamente, tiene que ver con la separación de intereses y el enfoque centrado en la lógica de negocio que se busca lograr. En frameworks como Struts y Spring aún hay mucho que construir en la capa de lógica de aplicación, teniendo demasiadas consideraciones con aspectos técnicos de bajo nivel, como el manejo de los objetos request y response asociados a las peticiones y respuestas de los servlets. En la búsqueda de frameworks más actuales que tengan este enfoque más centrado en la lógica de 53

54 negocio se encontraron opciones interesantes, como JBoss Seam, Apache Wicket y Oracle ADF. Estas opciones tienen otro conjunto de atributos a favor, tales como la orientación al desarrollo de componentes, principio clave para la obtención del producto que se quiere lograr. También es importante destacar el respaldo que tienen estos marcos de trabajo, sustentados por organizaciones y empresas tan importantes como JBoss, Apache y Oracle. Este conjunto de herramientas constituye la selección a ser analizada con mayor profundidad y es por ello que sus ventajas y desventajas son descritas con más detalle en los siguientes apartados. En la siguiente figura se puede observar un diagrama que señala la tendencia de búsquedas asociadas a estos frameworks en la web para el año El gráfico ha sido obtenido desde Google Trends y presenta la evolución de las búsquedas en la web durante el año. Figura 4. Tendencia de búsquedas en la web para JBoss Seam, Apache Wicket y Oracle ADF 54

55 JBoss Seam Seam es un framework de código abierto especializado en la construcción de aplicaciones de internet enriquecidas(ria) en el lenguaje java. Su creadores afirman que ha sido diseñado buscando eliminar la complejidad que suelen tener las plataformas de este tipo, tanto a nivel de API como a nivel de arquitectura. Está orientado a la construcción de componentes y se jacta de requerir muy poco XML. Esto es, porque los archivos XML se dejan sólo para lo estrictamente necesario y se compensa la disminución de estos archivos mediante la parametrización a partir de anotaciones (Java Annotations). Seam trabaja estrechamente ligado al estándar JavaServer Faces como framework asociado a la vista, pero actualmente se está trabajando en soporte para para otras platadormas como Wicket o Tapestry. Esto es posible, porque Seam es un Framework que abarca más que la capa de vista y los conceptos que lo sustentan son aplicables a todas las capas de la aplicación. Seam se integra perfectamente con distintas tecnologías, como son AJAX, JSF, JPA, EJB 3.0 y BPM, a través de las herramientas que forman la suite JBoss. Una de las características más interesantes de Seam, es el soporte para varios niveles de alcance(scope) o contexto para las variables que forman parte de cada instancia de la aplicación. Esto evita tener que manejar todo el estado en la sesión, lo que minimiza las fugas de memoria y simplifica el diseño y desarrollo de las aplicaciones, acotando el ciclo de vida de cada variable al alcance que debe tener, sin aumentar la complejidad para lograr esto. Otra de las características importantes es el soporte para el concepto de Biyección. Un concepto muy frecuente al hablar de frameworks de desarrollo es el del patrón de inyección de dependencias o inversión de control. La inyección de dependencias permite que un componente 55

56 obtenga una referencia a otro componente gracias a que el contenedor inyecta esta referencia en un método setter o en una variable de instancia. En oposición a esta relación unidireccional, Seam introduce la noción de biyección, que constituye una relación bidireccional, donde además de la inyección de referencias ocurre también una retroalimentación. Esta retroalimentación consiste en una actualización de la instancia de vuelta al contexto de origen. Todo esto se realiza dinámicamente, por lo que la biyección permite eliminar completamente la complejidad de mantener y actualizar los valores de las variables en los diferentes contextos. En cuanto a las desventajas, una de las principales dificultades a la hora de utilizar Seam, radica en la configuración inicial de la aplicación, la que se torna compleja y muy proclive a la ocurrencia de errores. La generación inicial del proyecto se torna generalmente en un proceso largo de prueba y error, lo que se ve acentuado por el poco soporte para Seam en los IDEs más importantes como NetBeans o Eclipse. Es en Eclipse donde se ve mejor soportado Seam, a través de la instalación de JBoss Tools, sin embargo, en las pruebas que se realizaron se encontraron varios bugs y problemas que igualmente hicieron difícil la construcción de un proyecto genérico. Como el título sugiere, Seam es parte de la suite de productos JBoss, patrocinada por Red Hat, lo que le da un valor agregado importante, por el respaldo que significa la experiencia de Red Hat en el rubro del desarrollo de software. Esto también implica ventajas comerciales, porque la empresa es partner oficial de Red Hat en Chile. Dicha alianza es una razón comercial poderosa para la eventual elección de este marco de trabajo. En términos de popularidad, Seam se ha mantenido sólido en el tiempo. Es posible ver en la figura 4 cómo ha superado en popularidad a Wicket y ADF, las otras alternativas evaluadas. Esto permite tener la confianza de una base de usuarios grande, lo que facilita la resolución de problemas, mediante la búsqueda en foros y listas de correo. 56

57 Apache Wicket Apache Wicket es un Framework para aplicaciones web basado en componentes, similar en conceptos a JavaServer Faces. En términos de diseño es cercano a lo que son los frameworks para interfaces gráficas de usuario (GUI) como swing. En ese sentido, al igual que swing hace uso de listeners registrados en los componentes para detectar los eventos gatillados por el usuario. Un listener es un componente de software que se adjunta a una fuente generadora de eventos y la escucha a la espera de que ocurran estos eventos, con el fin de realizar acciones adecuadas para manejarlo. Una de las principales características de Wicket yace en la aplicación del concepto de separación de intereses. Wicket logra exitosamente separar la presentación de la lógica de control a través de plantillas basadas en XHTML que no incluyen etiquetas ajenas al mencionado lenguaje de marcado. Esto permite que un diseñador pueda encargarse de construir las vistas de la aplicación sin preocuparse de la lógica subyacente. Por otro lado, los desarrolladores pueden concentrarse en la lógica la aplicación, sin preocuparse por la presentación. La asociación entre los elementos de la plantilla XHTML y los componentes de wicket se realiza a través del atributo class que es parte de todos los elementos HTML. Todo componente está respaldado por un modelo que maneja su estado. En cuanto a la capa de persistencia, Wicket no se amarra a ninguna estructura ni biblioteca particular, por lo que puede ser complementado directamente con alguna implementación de la JPA como Hibernate, EJBs o cualquier objeto simple de java. Una de las principales desventajas de Wicket, es su curva de aprendizaje, dado que, para poder utilizarlo es preciso tener conocimientos sólidos de java, dado que hace uso extensivo de características avanzadas que no suelen ser dominadas por el desarrollador promedio. Esto es así, 57

58 porque dentro de los mismos principios que motivaron la construcción de Wicket se encuentra la idea de poder realizar aplicaciones web completamente con el lenguaje java, con la sola ayuda de plantillas para la presentación. De hecho, suele decirse que construir aplicaciones web con Wicket es como desarrollar aplicaciones de escritorio basadas en eventos. En cuanto a motivos comerciales, Wicket no tiene ventajas y se ve disminuido frente a sus competidores, puesto que en la empresa no se ha desarrollado nunca una aplicación utilizándolo. Tampoco hay alianzas comerciales que motiven su uso ni clientes que lo soliciten. La términos de popularidad, no es posible afirmar que Wicket sea precisamente masivo. Sin embargo, cabe destacar que muchos desarrolladores con conocimientos avanzados en java manifiestan su amor por este marco de trabajo en artículos y blogs tecnológicos Oracle ADF Oracle ADF es un framework comercial basado en el lenguaje java para la creación de aplicaciones empresariales. Se basa principalmente en un enfoque visual y declarativo para la construcción de las aplicaciones. Está basado en el patrón MVC y soporta integración con diversas tecnologías, tales como EJBs, Web Services, Oracle TopLink, Javabeans, ADF Business Componentes, JavaServer Faces y struts, entre otras. Provee componentes integrados con AJAX para obtener una experiencia de uso fluida y libre de refrescos de página innecesarios. Está orientado a componentes y está muy ligado tecnológicamente a JavaServer Faces. Oracle ADF se jacta de ser más que un simple framework; es un meta-framework que maneja la integración entre distintos frameworks o tecnologías y lo hace de manera transparente al desarrollador. ADF está compuesto principalmente por 3 elementos: ADF Faces, ADF Controller y ADF Model. Sin embargo, el énfasis en este trabajo estará en la capa de presentación ADF Faces. 58

59 Como su nombre lo sugiere, está estrechamente ligada a JavaServer Faces y cualquier ingeniero que haya trabajado con JSF no tendrá problemas en introducirse al mundo de ADF Faces. Esto es una ventaja fundamental, dado que permite aprovechar el conocimiento previo que entrega la experiencia que ha tenido la empresa con muchos desarrollos basados en JSF. Como JSF, consta de plantillas de presentación basadas generalmente en archivos jsp o xml de extensión jspx, utilizando tags propietarios de Oracle. Sin embargo, tal como ocurre con JSF, está permitido modificar la configuración de la aplicación para reemplazar las clases que realizan el despliegue de la presentación y, gracias a esto, es posible utilizar cualquier tecnología para la presentación. Las vistas están respaldadas por un JavaBean manejado por el contenedor, el que se encarga de implementar la lógica de aplicación que gestiona la interacción del usuario con el software. Dado este concepto de respaldo del bean a la página, se utiliza el concepto de Backing Beans. Estos beans permiten fomentar la re-utilización, dado que es posible generar mini componentes re-utilizables, cuya lógica de aplicación está siempre encapsulada en un mismo bean. Estas clases manejadas por el contenedor soportan todas las características que provee Java para cualquier objeto, tales como herencia, generics, reflection, etc. Esta herramienta presenta la principal ventaja comercial, dado que la empresa tiene experiencia utilizándolo y además su principal cliente incluye su uso como un requerimiento para sus proyectos, por lo que resulta de particular interés acelerar los desarrollos en esta plataforma. La popularidad no es un factor tan importante en el caso de este framework, dado que la licencia de su uso incluye el soporte de Oracle, por lo que existe el respaldo constante de una de las más importantes empresas en el ámbito del software. 59

60 Decisión final A la hora de tomar la decisión final sobre el framework base a utilizar, lo que más ha primado son las razones comerciales y el deseo de la empresa de utilizar la herramienta en un proyecto cuya planificación coincidía con la etapa final de la construcción del presente trabajo. Por un lado, a pesar de la alianza con Red Hat, no han surgido solicitudes de proyectos que ameriten hacer uso de Seam, por lo que, bajo el punto de vista comercial, dicha alternativa no luce muy atractiva. El caso de Wicket es similar e incluso peor, la empresa no está dispuesta a correr el riesgo con un framework complejo, no muy masivo y que no se ve sustentado por solicitudes de clientes. Por otro lado, Oracle ADF es el framework que exige su principal cliente, lo que representa una razón fuerte para inclinarse por dicha opción. Además, dicho cliente ha solicitado el desarrollo de un proyecto que se ajusta mucho al tipo de problemas que se busca resolver con el framework y sus componentes, por lo que se ha decidido aprovechar la oportunidad de utilizar este proyecto para validar la cualidad de re-utilizable de los componentes desarrollados. De este modo, la empresa también puede determinar si efectivamente le conviene realizar la inversión necesaria para llevar a cabo este proyecto en el largo plazo Análisis de Alternativas Para Capa de Persistencia Esta etapa se vio mucho más acotada de lo que se pensó inicialmente, dado que la decisión sobre el framework base dejó el camino bastante allanado para la selección de herramientas restantes. Considerando que se utilizará Oracle ADF Faces pensando en el cliente principal de la empresa, se ha descartado inmediatamente Hibernate como alternativa para el manejo de la capa de persistencia, considerando que TopLink representa una alternativa muy similar y que tiene mejor integración con Oracle ADF. Además, uno de los requerimientos del 60

61 cliente es también que se haga uso de TopLink o, en su defecto, que la capa de persistencia sea manejada con consultas directas a la base de datos utilizando el patrón DAO. De todas maneras, esta decisión no afecta la planificación del trabajo final, puesto que el enfoque principal del proyecto no está en la capa de persistencia y esta implementación se considera un elemento externo. En ese sentido, el resultado final no se ve afectado por la alternativa que se seleccione en este apartado, pues el diseño considera una solución de bajo acomplamiento que no depende en absoluto de las herramientas que utiliza. Es por ello que será necesario utilizar patrones de diseño como el de la instanciación de objetos a través de fábricas, con el fin de introducir puntos de flexibilidad que fomenten el uso de herramientas inyectables Selección de IDE Nuevamente esta etapa de selección se vio directamente afectada por la decisión sobre el framework base a utilizar. Al escoger Oracle ADF se esté eligiendo casi de modo simultáneo trabajar con el IDE JDeveloper de Oracle, puesto que la integración de herramientas en JDeveloper para ADF es fluida y natural. Por el contrario, integrar ADF con IDEs como NetBeans o Eclipse es prácticamente imposible, dado el nulo soporte de estos ambientes de desarrollo para el mencionado marco de trabajo. 61

62 8 Resultados 8.1 Arquitectura General Una vez escogida la suite de herramientas a utilizar es posible dar inicio al trabajo concreto. El primer paso necesario es el diseño de la arquitectura general. A partir de esta arquitectura luego se construirán las aplicaciones futuras que hagan uso de estos componentes. A continuación se describen las fases más importantes en la obtención de la estructura básica Diseño La estructura sigue el patrón MVC y se apoya en las herramientas de Oracle ADF para integrar tecnologías. De este modo es posible lograr un producto sólido y flexible, capaz de trabajar en conjunto con múltiples frameworks y bibliotecas externas, a través de herramientas de terceros y los servicios de Java EE. Como anexo a esta estructura general se encuentra el generador de código. Este último facilita el desarrollo de las aplicaciones, construyendo automáticamente aquellos puntos críticos que aún no pueden ser manejados con la infraestructura provista. En la figura 5 se presenta el esquema tecnológico de la solución. En la figura también es posible apreciar la organización de las distintas capas que dan forma a la arquitectura. Las capas de presentación y control están fusionadas debido a que se sigue la estructura utilizada por Oracle ADF Faces. Cabe destacar que no se utilizarán todas las herramientas de Oracle ADF, como ADF Controller y ADF Model, puesto que las restricciones del cliente particular señalan que la separación de intereses debe mantenerse en los límites de Oracle ADF. Esto no implica que no se pueda tener correctamente separada la presentación de la lógica de aplicación. Como se puede apreciar en el diagrama, la vista se construye con plantillas jspx y la lógica de aplicación se encapsula en beans manejados por el contenedor. En esta capa se explicita el uso de las 62

63 caraterísticas de ADF Faces y JSF, que permiten manipular los objetos y eventos dinámicamente. Gracias a esto, es posible desarrollar componentes abstractos y manipular la estructura de los objetos concretos que los usarán, sin conocer esta estructura en tiempo de compilación. La capa de negocio está compuesta por los Enterprise Java Beans, WebServices, Message Driven Beans para manejo de colas JMS y POJOs. Esta es la capa donde debiese apuntar el esfuerzo en el desarrollo de nuevas aplicaciones, pues es aquí donde se implementan los flujos y reglas específicas al negocio. En la capa de integración se encuentra un conjunto de adaptadores que permiten integrar las aplicaciones con la fuente de datos u otra herramienta externa de la que se haga uso. Estas herramientas externas pueden ser webservices, repositorios de documentos, bases de datos, sistemas legados, etc. Es aquí donde se realiza la implementación de patrón DAO que permite alimentar de datos a los EJBs. También esta capa contempla el desarrollo de un adaptador de reportes, que será el encargado de traducir los reportes desplegados por la aplicación a plantillas que puedan ser provistas a herramientas externas, con el fin de realizar exportación a Excel y PDF, por ejemplo. También forma parte de la arquitectura un conjunto de componentes utilitarios que facilitan las tareas de elementos de todas las capas. Esto se debe realizar siempre teniendo cuidado de no introducir dependencias entre ellas. La finalidad de este conjunto de utilidades es proveer métodos de conveniencia para operaciones utilizadas por todas las capas, como el manejo de Strings, por ejemplo. En esta capa se desarrollan pequeños componentes que facilitan la reutilización de código en las demás capas. Gracias a las API de reflection, generics y annotations de java, es posible manipular datos en forma abstracta y construir componentes visuales en tiempo de ejecución, lo que forma parte importante del trabajo a realizar. 63

64 Figura 5. Esquema Tecnológico de la Estructura General. 64

65 8.1.2 Construcción La construcción de esta estructura inicial no presentó grandes dificultades, dado que el IDE JDeveloper facilita bastante la tarea de construir nuevos proyectos con ADF Faces + EJB. En esta etapa se generaron los archivos de configuración que permiten el movimiento de los engranajes. También se construyeron objetos básicos de ejemplo para demarcar la estructura final que deben tener las aplicaciones a desarrollar. Se generaron métodos y vistas que permiten manejar errores y se construyó la infraestructura global. Esta última tarea consta de la creación de los subproyectos que representan las distintas capas de la arquitectura, además de la configuración del alcance tecnológico de cada capa (Tecnology Scope) y el establecimiento del classpath de cada subproyecto(configuración de bibliotecas). 8.2 Componentes En el presente apartado se describe el proceso de diseño y construcción de los componentes. Se presentan diagramas de clases y se discute el potencial impacto de su utilización en la construcción de una instancia de la funcionalidad. Cabe señalar que por motivos de tiempo, no ha sido posible abordar el desarrollo de todos los componentes seleccionados en la etapa de análisis de aplicaciones. Es por ello que en esta sección no se abordan todos los componentes. Las funcionalidades sobre las que sí se alcanzó a trabajar son el componente para generación de mantenedores (tanto en diseño como en construcción) y el módulo de reportes (sólo su diseño). El proceso de diseño y construcción de estos elementos se describe a continuación. 65

66 8.2.1 Mantenedores La primera funcionalidad atacada fue la sindicada como más importante en las reuniones de toma de requerimientos. Fue también la de mayor impacto en el esfuerzo de desarrollo en los proyectos analizados. Sin duda, los mantenedores son un elemento fundamental en prácticamente todos los sistemas de información administrativos basados en la arquitectura web Diseño Para enfrentar de manera óptima la etapa de diseño es preciso tener claras las metas que se desea cumplir con el desarrollo. Como se mencionó previamente, uno de los principales objetivos es el de disminuir el esfuerzo invertido en la lógica de aplicación, permitiendo que los desarrolladores se enfoquen en la lógica de negocio. En ese sentido, la tendencia general es que los mantenedores no tengan mucha lógica de negocio, considerando que su función es realizar operaciones directas sobre la fuente de datos. Sin embargo, para el desarrollo de cada nueva aplicación, es importante que los programadores se concentren en la configuración particular de cada mantenedor y en las validaciones de datos. Es por esto que el enfoque sigue conservando su validez y el énfasis del diseño de este componente está en la optimización de las capas de presentación y control. El mayor potencial de optimización en la construcción de un mantenedor está en la reducción o eliminación(idealmente) de la lógica que maneja la interacción del usuario con la aplicación. Este potencial existe, porque en esencia todos los mantenedores se comportan de la misma manera y están compuestos por los mismos elementos visuales. Es por ello que, lógicamente, los usuarios interactúan con todos los mantenedores de la misma manera. 66

67 El primer paso en el diseño concreto de la funcionalidad es la identificación de los elementos visuales necesarios y suficientes para la construcción de cualquier mantenedor. De todas maneras, se espera que el producto final sea lo suficientemente flexible como para permitir que los desarrolladores puedan agregar elementos visuales adicionales. Este proceso de modelado de la vista arrojó como resultado un esquema de mantenedor como el que se muestra en la figura 6. Los objetos que componen el mantenedor son los siguientes: Tabla de datos: Presentación tabular de los registros existentes en la base de datos, correspondientes a la entidad que el mantenedor administra. Sus columnas son, en general, los atributos de la entidad y, por defecto, deben mostrarse todos. El programador puede decidir posteriormente si desea ocultar uno o varios de estos atributos. Contiene además una columna de acción, que le entrega al usuario la posibilidad de eliminar uno de los registros listados. Panel de filtros: Contiene un conjunto de campos de ingreso de datos, asociados a los atributos del objeto administrado, de modo que el usuario pueda filtrar los registros mostrados en la tabla de datos. El programador debe tener la posibilidad de configurar los campos del panel. No es posible transar la flexibilidad. Formulario de edición e ingreso de registros: Panel que contiene un conjunto de campos de ingreso de datos, asociados a los atributos del objeto administrado, de modo que el usuario pueda editar un registro existente o agregar uno nuevo. 67

68 Figura 6. Interfaz de mantenedores. Modo listado. Durante el diseño de componentes para aplicaciones web, no deben dejarse de lado los aspectos relativos a las interfaces gráficas y la usabilidad de las mismas. En el último tiempo, la usabilidad de interfaces ha demostrado ser un factor importantísimo en el diseño y construcción de aplicaciones. Esto no puede ser dejado de lado y es por eso que también se han tomado recaudos en ese sentido a la hora de diseñar la interfaz. Como se puede ver en la figura 6, la vista inicial no contiene el formulario de ingreso y edición de registros. Esta decisión de diseño se ha tomado en busca de optimizar la usabilidad de la interfaz, procurando no sobrecargar al usuario con demasiados formularios y opciones de interacción. Se ha optado por agregar un nivel más de navegación, en pos de la simplicidad de los elementos visuales. En la figura 7 se muestra el formulario de edición e ingreso de registros, el cual puede ser accedido desde el botón agregar ubicado al final de la tabla de listado de registros o desde el link ligado al campo primario de la entidad, en el caso de la edición. Este nivel adicional de navegación se diseñado pensando en la noción de modalidad, el mantenedor siempre está completo, pero el despliegue de los elementos visuales depende de las acciones que esté realizando el usuario. Existen 3 modalidades: 68

69 Modo listado: Corresponde al despliegue del panel de filtros y la tabla de listado de registros. Modo Edición: Corresponde al despliegue del formulario de edición de registros. Modo Creación: Corresponde al despliegue del formulario de adición de registros. Figura 7. Interfaz de mantenedores. Modo Edición. Luego de haber obtenido el diseño de la interfaz de usuario, es posible conocer con certeza los eventos que pueden ser generados por el usuario en su interacción con el sistema. Siendo así, ya se puede comenzar el modelado de la solución final. Para el diseño de las clases se ha definido una clase abstracta que debe ser extendida por los managed beans que respaldan las vistas. Esta clase encapsula la lógica de aplicación. Cada vez que es extendida, recibe un parámetro genérico, que debe ser ligado a la clase asociada a la entidad manejada por el mantenedor particular definido por la subclase. Esta clase abstracta se encarga de manejar toda la lógica de aplicación y de capturar los datos ingresados por le usuario. Todo lo que deben proveer las clases que la extienden, es la implementación de los métodos que se encargan de obtener los datos a través de consultas a el (o los) EJBs. 69

70 La clase base también es responsable de generar dinámicamente los elementos visuales que reciben los datos del usuario. Esto es posible a través de la recepción del parámetro genérico que se liga a la clase de la entidad a mantener, en conjunto con la API Reflection, que permite inspeccionar la estructura de este parámetro genérico en tiempo de ejecución. Esta tarea se lleva a cabo realizando una traducción, la que entrega el tipo de componente visual a generar a partir del tipo de dato del atributo de la clase asociado. La tabla de datos también se genera dinámicamente a partir del parámetro que indica la clase del objeto a administrar. La configuración particular de cada instancia del mantenedor se centra en la entidad. Es decir, la configuración se realiza en el JavaBean que representa la entidad en el modelo de clases. Esta parametrización se realiza a través de anotaciones creadas especialmente para estos efectos(java Annotations). La configuración se realiza a nivel de atributo y gracias a la API de anotaciones, es fuertemente tipada, lo que añade robustez al producto final. Además del managed bean base, el componente hace uso de varias clases utilitarias, las que permiten obtener una solución de alta cohesión y bajo acoplamiento, dejando la generación de elementos visuales en clases individuales, permitiendo tener una clase base de código limpio y sin dependencias fuertes. El manejo de excepciones también es un tema importantísimo a tener en cuenta, por lo que también se siguen buenas prácticas en ese sentido y se generan excepciones significativas en cada nivel. En la figura 8 se presenta el diagrama de clases que sustenta el diseño del componente asociado a los mantenedores. La figura muestra el diagrama de clases para un mantenedor concreto de ejemplo. 70

71 Figura 8. Mantenedor de Ejemplo, Diagrama de Clases. 71

72 Implementación El proceso de implementación de la funcionalidad planteó un interesante desafío en términos de investigación de las tecnologías disponibles. Las características del lenguaje java facilitaron el desarrollo y la solución lograda se adecúa totalmente al diseño planteado previamente. Se ha obtenido una estructura simple de utilizar y que cumple con los requisitos definidos. Tanto es así, que ha podido ser utilizada en un proyecto piloto. Dicha experiencia será descrita posteriormente. El componente asociado al mantenedor pudo ser desarrollado con éxito y los resultados han sido bastante satisfactorios, logrando ahorros de esfuerzo superiores al 50%. Durante la construcción del componente, se han tenido en cuenta patrones de diseño y buenas prácticas, con el fin de evitar vicios en el código logrado. Se han aprovechado también las características del lenguaje java en su versión 1.5, como el uso de enumeraciones en vez de constantes estáticas, ciclos foreach para la iteración de colecciones y parámetros genéricos. Se ha tenido también especial cuidado en el manejo de excepciones, procurando evitar siempre las excepciones no tipadas y generando una jerarquía de excepciones significativas. Este manejo de errores impacta positivamente la experiencia del usuario al utilizar los mantenedores, puesto que, de ocurrir algún error de sistema, las excepciones se manejan a conciencia y generan mensajes explicativos para el usuario, evitando las pantallas llenas de una traza que el usuario probablemente no entenderá. En la figura 9 se muestra un diagrama con la arquitectura final desarrollada para los mantenedores. Cabe destacar que la primera implementación de los mantenedores sólo contempla entidades simples, es decir, sin relaciones complejas con otros objetos de modelo. Esto reduce la complejidad sin sacrificar demasiado las posibilidades de uso, como se verá más adelante en el apartado dedicado a la validación del producto. 72

73 Figura 9. Arquitectura Mantenedores 73

74 Uso En este apartado se describe brevemente qué pasos se debe seguir para construir un mantenedor concreto. Es importante considerar que el componente sólo se encarga de manejar la lógica de aplicación para la generación de mantenedores. No realiza lógica de negocio y no tiene conocimiento de la forma en la que se obtienen los datos desde la fuente original. No se asume ninguna condición particular sobre la forma en la que se obtienen los datos, por lo que estos pueden ser extraídos de una base de datos, de un conjunto de archivos de texto, de una colección de archivos XML, etc. Además, dicha fuente de datos puede ser accedida con cualquier diseño; ya sea a través del patrón DAO, alguna implementación de la JPA, etc. Los pasos necesarios para construir un mantenedor concreto son los siguientes: 1. Generación de la página jspx La página jspx necesaria para el funcionamiento del mantenedor tiene una estructura estándar y debe contener un conjunto pequeño de componentes con identificadores pre definidos. La página debe contener los siguientes elementos: Un formulario (Sin identificador definido) 2 paneles visuales, uno para los elementos de interfaz del modo listado y otro para los elementos asociados a los modos de edición y creación. El panel de listado debe tener un contenedor para el formulario de filtros y una tabla para la lista de registros. El panel de edición debe tener un contenedor para el formulario de edición y creación. 74

75 Una vez creados estos elementos en el archivo, se obtiene una plantilla jspx de apenas 34 líneas. En la siguiente figura se muestra un ejemplo: Figura 10. Ejemplo de archivo jspx de mantenedor concreto 2. Construcción del Backing Bean El backing bean es una clase muy sencilla que no requiere manejar la lógica de aplicación. Tampoco requiere hacer asociaciones (binding) a ningún componente, dado que en tiempo de compilación, los componentes ni siquiera existen. El backing bean debe extender la clase MBMantenedor. Como se mencionó previamente, dicha clase recibe un parámetro genérico, el cuál debe ser saturado con la clase asociada a la entidad que administra el mantenedor. Es decir, la declaración de la clase debe ser, para el caso de un 75

76 mantenedor de usuarios: public class MBMantenedorUsuario extends MBMantenedor<Usuario> { } La clase MBMantenedor es abstracta, por lo que la clase MBMantenedorUsuario deberá implementar sus métodos abstractos. Estos métodos le permiten delegar la interacción con la fuente de datos a la capa de modelo, mediante el uso del patrón de diseño del método plantilla. Los métodos que deben implementarse son: public void inicializarelementos(hashmap<string, Object> params); Debe obtener un listado que contenga las entidades existentes en el sistema, filtradas de acuerdo a los parámetros que contiene el HashMap. Las entradas del HashMap tienen como llave el nombre del campo de la clase de la entidad y como valor el objeto que haya especificado el usuario en el formulario de filtros. Si los parámetros son nulos o el HashMap está vacío, se debe retornar la lista completa con las entidades existentes. public void create(t entidad); Debe encargarse de delegar a la capa de modelo la creación de nuevas entidades. La entidad del parámetro está lista para ser insertada, tiene todos sus campos llenos y corresponde a la información ingresada por el usuario para generar una nueva entidad. Cuando el parámetro de la clase base sea saturado (en este caso, con la clase Usuario) la firma del método pasa a ser: public void create(usuario entidad); 76

77 public void update(t entidad); Debe encargarse de delegar a la capa de modelo la actualización de entidades. La entidad del parámetro está lista para ser actualizada, tiene todos sus campos llenos y corresponde a la información ingresada por el usuario para modificar la entidad. Cuando el parámetro de la clase base sea saturado (en este caso, con la clase Usuario) la firma del método pasa a ser: public void update(usuario entidad); public void delete(t entidad); Debe encargarse de delegar a la capa de modelo la eliminación de entidades. La entidad del parámetro puede estar completamente vacía, salvo por el campo de dato principal de la clase (generalmente id ). Es decir, no hay garantías sobre el llenado de ningún otro campo. Cuando el parámetro de la clase base sea saturado (en este caso, con la clase Usuario) la firma del método pasa a ser: public void delete(usuario entidad); En la siguiente figura se muestra un ejemplo del managed bean que se debe desarrollar para el mantenedor concreto. 77

78 Figura 11. Ejemplo de managed bean de mantenedor concreto 3. Configuración y Restricciones sobre la Entidad En este apartado se detallan las restricciones que debe satisfacer la clase que representa la entidad en la capa de modelo. También se discute la forma en que se configura el mantenedor. Con respecto a las restricciones, lo único que debe cumplir la entidad es adecuarse al estándar para JavaBeans. Es decir, debe proveer un constructor que no reciba parámetros y sus atributos deben ser privados, pero debe existir la posibilidad de acceder a ellos a través de métodos get y set. La configuración se realiza a través de anotaciones que decoran los métodos get de cada variable de instancia de la clase. Estas anotaciones fueron desarrolladas especialmente para el componente y permiten modificar los atributos de los campos del formulario de filtros(@filterattribs), aquellos incluidos en el formulario de edición y creación 78

79 además de los campos que conforman las columnas de la tabla con la lista de registros En la figura 12 se muestra un fragmento de la clase Usuario del ejemplo mencionado, decorada con algunas anotaciones de configuración. Figura 12. Ejemplo de entidad con anotaciones de configuración 79

80 8.2.2 Reportes El segundo componente en la lista corresponde al módulo generador de reportes. Este componente toma un camino distinto al anteriormente presentado para los mantenedores. Esto ocurre, principalmente, porque en lo que a los reportes se refiere, las solicitudes que recibe la empresa no tienen tantas coincidencias en la definición de las interfaces de usuario y los elementos visuales que las componen. En las reuniones de análisis se expuso que, generalmente, los reportes tienen una estructura de presentación distinta, con elementos visuales diferentes, por lo que debe buscarse alguna otra alternativa para optimizar el desarrollo Diseño La búsqueda del potencial de mejora en la generación de los reportes fue el tema principal de una de las reuniones concertadas. Con la multiplicidad de posibildades de combinación de elementos visuales, se pierde la principal ventaja lograda con el primer componente desarrollado. Es, por tanto, preciso encontrar los puntos críticos donde se puede acelerar el desarrollo de la solución a todos los requerimientos asociados a los reportes. Para ello, es menester comprender cuáles son los requisitos más frecuentes y cómo se resuelven en cada desarrollo. En otras palabras, es necesario hilar más fino en la búsqueda de mejoras. El análisis de los requisitos en busca de los más frecuentes, arrojó como resultado que el factor común está en la conversión de las interfaces visuales a otros formatos de despliegue, tales como PDF o Excel. Una mirada superficial da la sensación de que no hay mucha necesidad de optimización en este apartado, dada la existencia de múltiples bibliotecas que realizan este trabajo. Sin embargo, es precisamente esta sobre oferta de alternativas donde se encuentran los principales problemas. En muchas ocasiones los clientes tienen requerimientos explícitos sobre 80

81 las bibliotecas o herramientas que se debe utilizar para realizar la conversión de las planillas a los formatos externos. Gran parte del esfuerzo en el desarrollo está en la construcción de plantillas y clases ad hoc para la utilización de las diversas bibliotecas. Es incluso frecuente, que se hagan diseños especiales para cada situación, sin contemplar las posibilidades de cambio futuro. Es aquí donde se puede mejorar. Con esto en mente, se ha abordado el diseño del componente. Nuevamente el diseño tiene como primer objetivo adecuarse a los requerimientos del cliente más importante de la empresa. Para la generación de reportes, el cliente exige que se utilice la herramienta Oracle Reports, por lo que los primeros trazos del diseño se esbozan en esa dirección. Oracle Reports es una herramienta de generación de reportes a partir de datos almacenados en una base de datos Oracle. Se compone de una aplicación de desarrollo donde se pueden generar plantillas de reportes, las que son respaldadas con consultas SQL o procedimientos almacenados. Utilizando estos atributos genera las instancias de cada reporte, de acuerdo a un conjunto de parámetros provistos por el usuario final. También consta de un conjunto de aplicaciones del lado del servidor, que permiten desplegar los reportes a través de un servlet, entre otras tareas. Oracle reports permite exportar las instancias de los reportes en diversos formatos, lo que lo hace una herramienta muy poderosa. Sin embargo, la generación de las plantillas base ha sido un cuello de botella importante en los desarrollos previos. Además, es deseable que en el futuro no sea necesario generar estas plantillas específicas para emular una vista que ya ha sido construida. En el fondo, se desea evitar tener que desarrollar la misma vista en repetidas ocasiones para adaptarla a distintas tecnologías. El concepto clave es el de adaptación, dado que, finalmente, lo que se hace siempre es adaptar la vista común del reporte a algún formato aceptable por la herramienta de turno utilizada para la exportación. 81

82 La idea, entonces, es generar un módulo adaptador de reportes, que sea capaz de tomar una instancia del reporte en su formato habitual, procesarlo y luego transformarlo a alguno de los formatos de entrada que espera Oracle Reports o cualquier otra herramienta utilizada para generar los archivos finales. En el caso de Oracle reports, los formatos de entrada aceptados son RFD, XML y páginas jsp creadas especialmente para ser interpretadas por el servidor de Reports. Aunque a primera vista parece ideal utilizar la aproximación de los jsp, resulta más simple realizar una conversión a XML. Esto, debido a la universalidad del formato y a la oportunidad que existe de aprovechar el hecho de que las plantillas de presentación jspx utilizadas por ADF son simplemente archivos XML. Esto reduce el problema a conocer el esquema de los XML de entrada de Oracle Reports y transformar el XML de los jspx en un XML que se adapte a dicho esquema. Una de las alternativas posibles es la utilización de archivos XSL que conviertan los principales componentes visuales de ADF Faces en los objetos que utilizan las plantillas de Reports. Esta es una de las tareas que deberá poder realizar el adaptador de reportes, una vez que pueda ser construido efectivamente. En la figura 13 se muestra el esquema asociado al componente adaptador de reportes. Por motivos de tiempo no ha sido posible realizar la implementación de este componente, pero el diseño planteado constituye un avance importantísimo con miras al objetivo global de la obtención de una herramienta que minimice el esfuerzo de los desarrollos. Se espera que la construcción de este módulo se lleve a cabo en el corto plazo. 82

83 Figura 13. Arquitectura Reportes 83