UNIVERSIDAD SIMÓN BOLÍVAR INGENIERÍA DE LA COMPUTACIÓN ANÁLISIS E IMPLEMENTACIÓN DE LA HERRAMIENTA DE ADMINISTRACIÓN DE LA SOLUCIÓN INFINIX SUITE.

Transcripción

1 UNIVERSIDAD SIMÓN BOLÍVAR INGENIERÍA DE LA COMPUTACIÓN ANÁLISIS E IMPLEMENTACIÓN DE LA HERRAMIENTA DE ADMINISTRACIÓN DE LA SOLUCIÓN INFINIX SUITE. Por CAROLINA TEJA PABLO INFORME FINAL DE CURSOS EN COOPERACIÓN Presentado ante la Ilustre Universidad Simón Bolívar como Requisito Parcial para Optar por el Título de Ingeniero en Computación Sartenejas, Septiembre de 2006 i

2 UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA EN COMPUTACIÓN ACTA FINAL DE CURSOS EN COOPERACIÓN ANÁLISIS E IMPLEMENTACIÓN DE LA HERRAMIENTA DE ADMINISTRACIÓN DE LA SOLUCIÓN INFINIX SUITE. Presentado Por: CAROLINA TEJA PABLO Este Trabajo de Cursos en Cooperación ha sido aprobado en nombre de la Universidad Simón Bolívar por el siguiente jurado examinador: Prof. Dionisio Acosta - Jurado Prof. Ascánder Suárez - Tutor Académico Ing. Alejandro Pujol - Tutor Industrial Sartenejas, 06 / 10 / 2006 ii

3 ANÁLISIS E IMPLEMENTACIÓN DE LA HERRAMIENTA DE ADMINISTRACIÓN DE LA SOLUCIÓN INFINIX SUITE. Presentado Por: Carolina Teja Pablo En el presente trabajo de pasantía se desarrolló la Herramienta de Administración para la solución INFINIX Suite. Esta solución es ofrecida por la compañía Wincor Nixdorf a las entidades financieras para la integración de los diferentes canales de comunicación bancaria (agencias, call center, cajeros automáticos, entre otros), desarrollada sobre la plataforma J2EE. Para el desarrollo de la herramienta se utilizaron las metodologías RUP y Extreme Programming. Con estas metodologías se dividió el proyecto en tres etapas. En un principio se llevó a cabo la etapa de análisis en la cual se elaboró el documento de requerimientos SRS, el diagrama de clases y los diagramas de secuencia. Finalmente para esta etapa se presentó un prototipo de pantallas navegable sin funcionalidad, para lo cual se utilizaron los requerimientos previamente obtenidos. Posterior a toda la fase de análisis, se procedió con la etapa de desarrollo en la cual se implementaron todos los servicios en las diferentes capas de la solución y siguiendo los patrones de desarrollo establecidos por Wincor Nixdorf para la solución INFINIX Suite. En esta etapa de desarrollo se utilizó la tecnología del framework Spring para manejar todos los servicios como beans. Además en ésta capa se desarrollaron las funcionalidades establecidas en la fase de análisis con los casos de uso, estas funcionalidades fueron desarrolladas por módulos, donde cada módulo fue desarrollado por completo antes de proseguir con el siguiente. Culminada la etapa de desarrollo, se realizaron las pruebas necesarias para mejorar la herramienta en conjunto con el equipo de QA. Es importante mencionar que fuera de los objetivos de este proyecto se desarrolló adicionalmente el servicio que será utilizado para validar los usuarios con el protocolo LDAP para toda la solución INFINIX Suite. Al término de esta pasantía se obtuvo como resultado la Herramienta de Administración para INFINIX Suite, totalmente integrada a la solución y que cumple con las funcionalidades requeridas. Dicha herramienta ya está siendo utilizada por el equipo de trabajo para configurar y administrar los componentes en el desarrollo de la solución. iii

4 Índice 1. Introducción Descripción de la Empresa Marco Teórico Spring Struts Starteam Continuum Maven LDAP INFINIX Suite Marco Metodológico RUP: Rational Unified Process XP: Extreme Programming XP vs. RUP RUP y XP en el Proyecto Starteam, Continuum y Maven Análisis Actores Requerimientos Funcionales Generales Requerimientos Funcionales por Módulo Requerimientos No Funcionales Diseño Framework INFINIX Infinix Caribe Base de Datos INFINIX Implementación Beans Spring Pruebas: JUnit Manejo de Errores LDAP para INFINIX Suite AJAX: Asynchronous JavaScript and XML Librería Drag and Drop Resultados Módulo de Administración de Usuarios Módulo de Administración para Menú Conclusiones Recomendaciones...53 iv

5 Índice de Figuras Figura 1.- Capas en la solución INFINIX Suite...11 Figura 2.- Esquema con todos los componentes de la Herramienta...20 Figura 3.- Estructura de los proyectos en INFINIX Suite...26 Figura 4.- Manejo de Exceptions...33 Figura 5.- Manejo de Exceptions en INFINIX Suite...33 Figura 6.- Uso de los DTO en InfinixCaribe y en el Framework Figura 7.- Fragmento de la página para modificar un menú donde se puede observar la estructura de directorio...37 Figura 8.- Pantalla para crear un usuario...40 Figura 9.- Pantalla para la creación de un usuario luego de seleccionar un tipo de usuario y completar los campos del formulario...41 Figura 10.- Mensaje de error al introducir un usuario inválido en la creación de usuarios...42 Figura 11.- Pantalla con la lista de usuarios...43 Figura 12.- Pantalla para la búsqueda de usuarios...44 Figura 13.- Pantalla que se muestra al obtener un usuario...45 Figura 14.- Mensaje de confirmación para eliminar un usuario...45 Figura 15.- Pantalla para modificar un usuario Figura 16.- Primera pantalla para crear un menú Figura 17.- Lista de Ambientes que poseen un menú...50 Figura 18.- Despliegue gráfico para un menú Figura 19.- Pantalla para modificar un menú...51 v

6 Lista de Símbolos y Abreviaturas AJAX DAO DI DTO INFINIX IoC HTML HTTP J2EE JAR JDBC JNDI JSP MVC POM QA RMI RUP SQL SRS UP URL XML XP Asynchronous Javascript And Xml Data Access Object Dependency Inyection Data Transfer Object INtegración FInanciera NIXdorf Inversion Of Control HyperText Markup Language HyperText Transfer Protocol Java 2 Enterprise Edition Java ARchive Java DataBase Connectivity Java Naming and Directory Interface Java Server Pages Model View Controller Project Object Model Quality Assurance Remote Method Invocation Rational Unified Process Structured Query Language Software Requirements Specification Unified Process Uniform Resource Locator extensible Markup Language extreme Programming vi

7 1. Introducción En la actualidad las organizaciones se desenvuelven en ambientes competitivos, que unido a las exigencias del mercado, se ven en el compromiso de aumentar la eficiencia en todas las áreas relacionadas con el servicio al cliente. Debido a las necesidades del sector bancario por mejorar la atención al cliente, Wincor Nixdorf desarrolló INFINIX Suite, una solución para integrar los canales, los cuales son las diferentes maneras que tiene una institución financiare para comunicarse con sus clientes. Es importante aclarar que la solución es 100% desarrollada en Venezuela. Tradicionalmente las aplicaciones que se desarrollan para el sector bancario necesitan establecer una interfaz de comunicación con cada uno de los sistemas empresariales por cada sub-sistema. Como ejemplo podemos observar en la Figura 1 que para establecer la comunicación entre los canales (Internet, Mobile, PDT, Branch Office) y los sistemas empresariales (Host, DBMS, Enterprise Application) es necesario crear una interfaz de comunicación en los sub-sistemas (WWW-Wap Server, IVR/Call, Router) por cada uno de los sistemas empresariales. Enterprise application (SAP, Sanchez etc.) CICS MQ family ISO 8583, etc. DBMS Host Internet/ WWW-WAP server(s) Home banking IVR/Call center system Router/ switch (De-) central server Internet Mobile PDA Contact center Self-service Branch office Figura 1.- Aplicaciones Tradicionales para el Sector Bancario Esta solución provoca una redundancia entre la comunicación de los canales y los sistemas 1

8 2 empresariales. Para evitar esta redundancia en la comunicación la solución INFINIX Suite propone crear una única capa encargada de establecer una interfaz de comunicación con cada uno de los sistemas empresariales. A través de esta capa es que los canales se comunican con cada uno de los sistemas empresariales. Ver Figura 2. Figura 2.- Integración de Canales con INFINIX Suite. Una de las necesidades que surge del mercado es desarrollar un nuevo canal para la solución INFINIX Suite que permita administrar la configuración del resto de los canales, además de los elementos que son comunes para todos ellos, como por ejemplo los usuarios, perfiles y parámetros generales del sistema. El desarrollo de la Herramienta de Administración, para este nuevo canal, es el objetivo fundamental de este proyecto. Esta Herramienta de Administración forma parte del conjunto de valores agregados de la solución INFINIX Suite. Este valor agregado surge como necesidad de minimizar la dependencia entre la institución bancaria y Wincor Nixdorf. Con esta independencia se brinda a la entidad financiera mayor control sobre sus operaciones para el manejo y administración de la solución, ideal para sus objetivos institucionales.

9 3 Las actividades administrativas suelen involucrar el manejo de información valiosa para las empresas. El encargado de cumplir con estas actividades podría corromper la información o ingresar nueva inconsistente y con errores, que pueden ser hechos de mucha importancia para el desempeño y funcionamiento de los sistemas de una empresa. Por lo delicado de las actividades administrativas es una gran ventaja para las entidades financieras contar con una herramienta que facilite la administración de los componentes que conforman la solución, pues disminuye los errores que existen a la hora de manipular dichos componentes. Con la herramienta se permite disminuir los errores propios de la actividad administrativa, debido a que en ella se incluyen validaciones y lo más importante una interfaz gráfica sencilla y fácil de utilizar. El presente libro muestra el desarrollo de la Herramienta de Administración de INFINIX Suite para el Banco del Caribe. Este desarrollo se explica en cuatro capítulos del libro que se explican brevemente a continuación con la intención de dar una visión general del documento. En el capítulo 2 se presenta una visión general de la empresa a fin de ubicar al lector dentro del ambiente donde fue llevada a cabo la pasantía. En el capítulo 3 se presenta el marco teórico de la pasantía, es decir todos aquellos conceptos que fueron utilizados y que son indispensables para el entendimiento de todo lo expuesto en este trabajo. En el capítulo 4 se describe todas las metodologías utilizadas para desarrollar la herramienta. Esta metodología es la utilizada por la empresa para la solución INFINIX Suite. En el capítulo 5 se presenta el análisis de los requerimientos del sistema y sus correspondientes casos de uso a fin de entender con mayor profundidad dichos requerimientos. En el capítulo 6 se hace referencia a todo el diseño escogido para la herramienta. En el capítulo 7 se presentan todos los detalles de implementación que se realizaron tomando en cuenta el diseño escogido para el sistema. En el capítulo 8 se presentan los resultados de la pasantía con imágenes de las pantallas del producto final. Por último, conclusiones y recomendaciones para una próxima herramienta administrativa.

10 2. Descripción de la Empresa Wincor Nixdorf fue fundada en el año 1952 por Heinz Nixdorf con el nombre de Nixdorf Computer como una organización dedicada al área de tecnología de la información. En 1990 Nixdorf Computer es adquirida por la corporación Siemens AG surgiendo así Siemens Nixdorf Information System AG, compañía que operó con este nombre hasta 1998 cuando cambia su orientación y se convierte en una empresa netamente centrada al área de la banca y de puntos de venta, constituyendo así Siemens Nixdorf Retail and Banking System GMBH. A finales de 1999, Siemens Nixdorf logra su independencia del grupo Siemens, al ser adquirida por los inversores Kohlberg Kravis Roberts & Co. Ltd. (KKR) y GS Capital Partners III, L.P, convirtiéndose en Wincor Nixdorf GMBH & Co. KG. Hoy en día, Wincor Nixdorf está presente en más de 40 países con subsidiarias en 28 de ellos y cuenta con dos fábricas, una en Paderborn (Alemania) y la otra en Singapur. Wincor Nixdorf C.A. es la subsidiaria venezolana, líder en el área de tecnología de información con más de 15 años operando en el país y sirviendo los diferentes sectores productivos con soluciones informáticas de vanguardia. Su sede principal está ubicada en la ciudad de Caracas [1]. En la actualidad cuenta con más de 100 colaboradores a nivel nacional y mas de 4600 a nivel mundial. Desde su fundación ha estado a la vanguardia tecnológica, ofreciendo soluciones de alta calidad en la automatización de los procesos de sus clientes, siendo hoy por hoy uno de los principales proveedores líderes en el sector bancario. Las áreas más importantes que cubre la empresa son: las soluciones de autoservicio, automatización de agencias bancarias, cajeros automáticos, servidores, computadoras, impresoras de alto rendimiento, integración de sistemas, consultoría y servicios. Wincor Nixdorf como corporación tiene un objetivo bien claro: Ser líderes y obtener beneficios en todos los segmentos de mercado en los que está presente. La estrategia se basa en sistemas abiertos y soluciones orientadas hacia el usuario, de la máxima calidad, y que aportan claras ventajas competitivas a sus clientes y empresas asociadas. 4

11 5 La empresa está dividida en tres grandes unidades: La Unidad de Mercadeo y Ventas es la encargada de llevar al mercado venezolano la gama de productos y soluciones que brinda la empresa; la Unidad de Consultoría, Proyectos y Servicios (CPS) es la encargada de acometer los proyectos que la unidad de ventas obtenga, además de prestar servicio técnico a las soluciones y productos instalados. Por último, la unidad de Administración Comercial que maneja las finanzas de la empresa. Los pasantes que entran a la empresa para hacer nuevos desarrollos están canalizados a través de la unidad CPS.

12 3. Marco Teórico 3.1. Spring Es un framework de código abierto creado para enfrentar la complejidad del desarrollo de aplicaciones empresariales. Utiliza la inyección de dependencias y la orientación a aspectos [2]. Características - Ligero: esta característica se refiere al mínimo impacto que puede causar su uso en una aplicación. Spring se considera ligero por los pocos cambios que son necesarios realizar en un proyecto para utilizarlo o dejarlo de utilizar. Esta característica hace referencia a las funciones básicas que provee Spring. Para los componentes extras, como acceso a base de datos, requiere mucho más acoplamiento [3]. - Inyección de Dependencias (Dependency Injection DI): Spring promueve desacoplamiento en el manejo y creación de dependencias a los componentes a través de la técnica conocida como Inversion of Control (IoC). La inyección de dependencias es un ejemplo de IoC, donde el contenedor le provee las dependencias al objeto antes de que éste las solicite. - Orientación a Aspectos: Spring provee soporte para la programación orientada a aspectos que permite el desarrollo por separado de la lógica del negocio y los servicios del sistema. Un ejemplo en el que la orientación a aspectos es muy utilizada es en el seguimiento de las transacciones dentro de una aplicación. Los objetos no son responsables, ni siquiera se enteran, de registrar sus transacciones en el sistema. - Contenedor (Application Context): Spring contiene y maneja todo el ciclo de vida y la configuración de los componentes pertenecientes a las aplicaciones. - Framework: Hace posible configurar y construir aplicaciones complejas a partir de componentes simples. Los objetos de las aplicaciones se crean declarativamente en un archivo XML. La técnica de IoC provee amplias ventajas para el framework de Spring. Algunas de las ventajas 6

13 7 son [3]: Reducción de código: El código necesario para ensamblar los diferentes componentes de la aplicación se reduce drásticamente. Para lograrlo DI provee una búsqueda automática con JNDI (Java Naming and Directory Interface) que resuelve las dependencias que necesita un componente y un proxy automático para localizar los recursos remotos. Aislar las dependencias: Colocar la configuración de las dependencias en un archivo XML, permite reconfigurar cuando sea necesario sin necesidad de compilar nuevamente todo el código. Esto separa todas las opciones de configuración de la aplicación, además de hacer más fácil el cambio de la implementación de una dependencia por otra. Un ejemplo de este caso es cambiar una dependencia de un manejador de PostgreSQL a Oracle. Manejar las dependencias en un solo lugar. Toda la información de las dependencias se encuentra en un solo repositorio, lo cual lo hace más manejable y fácil de administrar. Spring está formado por siete módulos bien definidos. Las aplicaciones que se desean desarrollar con este framework no necesitan lidiar con todos sus módulos, pueden utilizar solo aquellos que consideren convenientes. Los módulos que proveen las principales funcionalidades de Spring y además se utilizaron para este proyecto se explican a continuación [2, 3]. Contenedor Base: Provee la funcionalidad principal de Spring. En este módulo se encuentra el BeanFactory que aplica la técnica IoC y se encarga de construir todos los beans de la aplicación. El módulo ApplicationContext y WebContext ofrecen funcionalidades adicionales a las básicas provistas por el BeanFactory. JDBC y DAO: la integración de estos dos conceptos permite mantener el código de acceso a la base de datos limpio y simple. De esta manera se evitan los problemas que resultan al cerrar la conexión de base de datos. BeanFactory provee un avanzado mecanismo de configuración capaz de manejar beans de cualquier naturaleza utilizando las facilidades de almacenamiento. El ApplicationContext tiene como base el BeanFactory y agrega otras funcionalidades como fácil integración con los aspectos de AOP, manejo de los mensajes para uso de internacionalización, entre otras. Por lo general, en la mayoría de las aplicaciones desarrolladas bajo el ambiente J2EE es

14 8 recomendable utilizar ApplicationContext. La razón principal es que engloba todas las características de BeanFactory y otras adicionales. Cuando el uso de memoria es un punto importante y realmente no se necesitan todas las ventajas que brinda ApplicationContext es preferible solo utilizar BeanFactory. Un ejemplo para este caso son las aplicaciones con applets, donde es muy importante el peso de la aplicación [4]. Para el manejo de los beans de INFINIX Suite se utilizó el ApplicationContext para aprovechar los beneficios que ofrece a diferencia de BeanFactory. Con ApplicationContext se pueden manejar transacciones y configurar aspectos esenciales para el desarrollo del proyecto, además de garantizar que todos los beans a ser utilizados por la aplicación se creen al levantar la aplicación y no cada vez que se necesite de uno en particular. De fallar la creación de algún bean no se inicia la aplicación. En INFINIX Suite se utilizan los patrones DAO y DTO del estándar de diseño de J2EE. Estos patrones permiten resolver el problema de acceso a los datos, que normalmente depende del tipo de manejador de base de datos. Los DAO (Data Access Object) son utilizados para abstraer y encapsular todos los accesos a la base de datos; manejan la conexión a la base de datos para obtener, modificar y guardar los datos. Estas clases vienen representadas por una interfaz y una implementación. La implementación recibe la instancia de la librería JDBCTemplate por el mecanismo de inyección de Spring, para poder realizar cualquier operación sobre la base de datos. La librería JDBCTemplate, provista por Spring, facilita notablemente el acceso a la base de datos, ya que encapsula todo el manejo de excepciones y ofrece una variedad de métodos que simplifican las consultas más comunes que se realizan sobre una tabla. Los DTO (Data Transfer Object) son los patrones utilizados para transferir los datos entre las diferentes capas de la aplicación. Son utilizados en conjunto con los DAO para encapsular los datos obtenidos de la base de datos Struts Es un framework para construir aplicaciones web basadas en Java. Usa el patrón de diseño Modelo-Vista-Controlador (Model View Controller MVC).

15 9 En este patrón, los componentes del modelo facilitan una interfaz para los datos o servicios usados en la aplicación, y además de proveer la lógica del negocio. Los componentes del modelo en Struts son los ActionForm y los Action. De esta manera, el controlador no tiene que manipular los datos de la aplicación [5]. Los componentes de la vista son usados para generar la respuesta al explorador y son los que se muestran al usuario. Estos pueden ser páginas JSP o HTML. El componente esencial del patrón es el controlador. Es un servlet que se encarga de recibir las solicitudes para la aplicación y manejar el flujo de datos entre la capa de modelo y la capa de vista, además de controlar la interacción entre ambas capas. Con el archivo strut-config.xml se configura el controlador. La base del framework provee las principales funcionalidades del MVC. En la base de Struts está el ActionServlet y las clases base para el desarrollo de cualquier aplicación [5]. Las clases base son Action y ActionForm. Las clases Action son usadas por el ActionServlet para procesar las solicitudes. Los ActionForm son usados para capturar los datos desde los formularios HTML y para devolver datos a la capa de vista para generar nuevas páginas Starteam Provee el manejo de versiones de un proyecto como también la configuración del manejo de software, lo cual permite establecer las necesidades de todo el equipo de trabajo. Promueve la comunicación del equipo y a su vez ayuda a la colaboración con el control centralizado de los proyectos. Se basa en la metodología SCM (Software Configuration Management) que permite controlar y administrar el desarrollo de un proyecto de software. La metodología esta basada en la definición de mecanismos que mantienen las distintas versiones del producto, manejan auditorias, controlan los cambios y reportan esos cambios durante el desarrollo del proyecto [6] Continuum Es un servidor que provee integración continua para la construcción de proyectos basados en

16 10 Java. El término de integración continua se refiere al proceso de construir y probar el código frecuentemente, para generar la versión a ser utilizada. Los beneficios de la integración continua son la identificación inmediata de defectos para garantizar que un proyecto fue construido satisfactoriamente. El servidor de Continuum chequea el repositorio donde se encuentra el código fuente en intervalos regulares de tiempo, éste también provee la posibilidad de configurar estos trabajos de chequeo a conveniencia del equipo de desarrollo del proyecto. El monitoreo en el proyecto se hizo con Maven pero también puede hacerse a través de Ant o Shell Script [7] Maven Es una Herramienta de Administración y construcción de proyectos de software, basada en el concepto POM (Project Object Model). Se encarga de construir, reportar y documentar el proyecto desde un punto central de información [8]. POM es utilizado para describir el proyecto de software en desarrollo, sus dependencias con módulos externos y componentes, además de establecer el orden de compilación. Este concepto está representado como un XML que posee etiquetas preestablecidas, que contienen tareas bien definidas como compilación del código y empaquetamiento. Permite publicar de manera sencilla un proyecto y de esta manera compartir los componentes, que se encuentran empaquetados en diversos archivos con extensión JAR, con otros proyectos. Esta publicación se hace a través de Continuum. Este servidor compila y corre las pruebas del código fuente con Maven para generar los JARs, los cuales pueden ser utilizados por todos los demás proyectos a través de las etiquetas que definen las dependencias en el POM LDAP Lightweight Directory Access Protocol es un protocolo de red que permite el acceso a un servicio de directorio para consultar y modificar la información. El directorio LDAP, es un árbol de entradas que presentan un conjunto de atributos con sus respectivos valores. [9]

17 11 El Banco del Caribe posee todos los datos de sus usuarios bajo este protocolo, es por ello que este concepto debe ser manejado para este proyecto. Todos los usuarios que serán creados con la Herramienta de Administración deben ser usuarios que existan en la base de datos del banco. Es necesario validar antes de la creación de un usuario para INFINIX Suite, si existe dicho usuario para la base de datos del banco INFINIX Suite Es una solución desarrollada por Wincor Nixdorf orientada a soportar los diferentes canales de distribución de las instituciones financieras: agencias, internet banking, call centers, ATM y terminales móviles entre otros, integrando todos ellos entre sí y con los diversos sistemas empresariales con los que cuente la institución, utilizando para ello un esquema centralizado. Está completamente desarrollada en el lenguaje de programación Java, sobre la plataforma J2EE [13]. El objetivo de INFINIX Suite es proveer un conjunto de características que permitan la optimización de la gestión en las agencias y sucursales de una institución financiera, siendo una solución integrada, adaptable, expansible y portable, que se ajusta a las necesidades de cualquier institución y es capaz de adaptarse a las nuevas funcionalidades que sean requeridas. Las capas que conforman la arquitectura de la solución son presentadas en la Figura 3. Value Object Layer Presentation Layer Deployment Layer Business Logic Layer Data Access Layer Enterprise Application Integration Layer Architectural Component Layer Figura 3.- Capas en la solución INFINIX Suite. 1. Presentation Layer: Punto de entrada a los servicios de la aplicación de cara al usuario o a un sistema externo. En un primer nivel representa la transformación de las solicitudes recibidas desde

18 12 un dispositivo externo al mecanismo utilizado internamente por el sistema, ofreciendo un acceso homogéneo que independiza a la capa de Deployment y Business Logic de las particularidades asociadas a los diferentes dispositivos que actúan como clientes del sistema. Además, esta capa representa las interfaces de usuario necesarias para acceder a los servicios publicitados y los mecanismos de acceso a la aplicación por otros sistemas. Es en esta capa donde se utilizó el framework de Struts. 2. Deployment Layer: Esta capa actúa como la puerta de entrada a los servicios ofrecidos por la lógica de negocio. Actúa como una fachada de la lógica de negocio donde se publican las funcionalidades ofrecidas a la capa de presentación. Esta capa, principalmente tecnológica, condiciona la forma en que los servicios son invocados desde la capa de presentación. 3. Business Logic Layer: Implementa la lógica de negocio de la aplicación, alberga los componentes que combinan las reglas de negocio y los datos. Los elementos en esta capa modelan los objetos y procesos de negocios interactuando con las capas inferiores para la obtención o persistencia de datos o para la solicitud de servicios a otros sistemas que formen parte del proceso de negocio. Esta capa esta definida para ser independiente de la tecnología utilizada en la Capa de Deployment de forma de buscar su máxima reusabilidad y flexibilidad. Para manejar toda la lógica del negocio, que en nuestro caso son los procesos del banco, se utilizó el framework de Spring. 4. Enterprise Application Integration Layer: Esta capa da servicio a la interconexión con sistemas externos. Abstrae a la lógica de negocio de las particularidades que implica la comunicación con otros sistemas. Esta capa se orienta principalmente a la solicitud de servicios publicados por otros sistemas. 5. Data Access Layer: Esta capa abstrae a la aplicación del acceso a diferentes mecanismos de persistencia de datos. Cumplen la función de conocer la forma de interactuar con el mecanismo de persistencia y transformar los datos obtenidos a un value object que pueda ser transportado y manipulado dentro de los procesos de la lógica de negocio o presentado al usuario o sistema externo. En esta capa se utilizó el patrón de diseño DAO. 6. Value Object Layer: Esta capa define los objetos que transportan los datos entre las diferentes capas y componentes que conforma el sistema. Todo el intercambio de información entre las

19 13 diferentes capas que definen la aplicación y los componentes que la conforman se realizará utilizando value object (también denominados Data Transfers Objects DTO). Los objetos en esta capa están orientados a encapsular grupos de datos necesarios para realizar un proceso de negocio de forma de transportarlos a lo largo de la aplicación como un único elemento, aportando a su vez funcionalidad específica a lo largo de la arquitectura. 7. Arquitectural Component Layer: Esta capa ofrece al sistema un conjunto de componentes que simplifican diferentes necesidades dentro de la aplicación. En esta capa se encuentran componentes comunes que por su comportamiento o complejidad tiende a ser elementos reutilizables e independientes de la lógica de negocio y por ellos requieren ser diseñados e implementados de forma independiente. A su vez, los elementos aquí contenidos condicionan el desarrollo, debido a que es en ellos donde se define la forma de interacción entre las diferentes capas, así como la forma de interacción entre INFINIX y elementos externos al sistema, tales como base de datos o sistemas externos. Por otro lado, también da soporte a diferentes mecanismos ampliamente utilizados en el sistema buscando una mayor eficiencia y abstracción para el resto del sistema. Dentro de la capa de presentación se utilizan las clases Action de Struts quienes son las encargadas de dar respuesta a los procesos desencadenados por el usuario. Por el contrario en la capa de la lógica del negocio se utilizan los beans de Spring para manejar todos los servicios que pueden ser invocados desde la capa de presentación. En el momento que desde un Action se hace la llamada a un servicio manejado como un bean de Spring es donde se fusionan estas dos tecnologías.

20 4. Marco Metodológico En el desarrollo del proyecto se utilizó como principal metodología RUP. Pero además de RUP se utilizó las buenas prácticas de la metodología XP en cuanto a la fase de pruebas. Explicaremos cada una de ellas, para posteriormente identificar las diferencias, además de establecer que puntos en específico de cada metodología fueron utilizados RUP: Rational Unified Process Es un refinamiento de la metodología UP (Unified Process) desarrollado por la Corporación Rational Software. RUP plantea una serie de pasos a seguir para el desarrollo iterativo e incremental de software adoptando el modelo de objetos [10]. Su función principal reside en el diseño y desarrollo de proyectos de gran escala en etapas o iteraciones, para evitar incurrir en la mala práctica de desarrollar todo en un mismo paso. Para garantizar que el proyecto sea desarrollado de forma incremental, este se divide en iteraciones las cuales deben incorporar nuevas funcionalidades al sistema. Cada iteración envuelve revisión de los requerimientos, diseño, implementación de las funcionalidades y pruebas sobre las mismas. Características - Desarrollo iterativo e incremental. - Manejo de requerimientos: El levantamiento de información se realiza con los usuarios finales del sistema, para identificar y conocer sus necesidades, y así establecer los requerimientos y futuros cambios. A partir de los requerimientos se definen los posibles casos de uso, que representan la interacción del usuario con el sistema. Estos casos de uso representan las funcionalidades a incluir dentro de cada iteración. - Arquitectura basada en componentes: Permite crear un sistema escalable y fácil de comprender que promueva la reutilización. Un componente esta constituido por un conjunto de objetos. El desarrollo iterativo permite identificar de forma gradual los componentes que deben ser desarrollados, comprados o reutilizados y que generalmente son ensamblados 14

21 15 dentro de las infraestructuras existentes. - Modelado visual del software: Uso de representaciones gráficas como camino efectivo para obtener una visión general de la solución. Permite simplificar el problema observado, además de establecer un intermediario entre la lógica de negocio y el código implementado. - Verificación de la calidad del software: Planea un proceso de calidad durante todo el proyecto, involucrando a todos los integrantes del equipo. - Control de cambios: Define métodos para controlar y monitorear los cambios del sistema. Fases de un Proyecto para UP 1. Fase de Inicio: en esta fase se establece el caso de negocio, el cual incluye el contexto del negocio, los factores de riesgo y la estimación de los costos. Para completar esta fase también es necesario crear un modelo básico de casos de uso, un plan de proyecto, puntualizar los candidatos a la arquitectura y describir el problema estableciendo el alcance. Es la fase más corta del proyecto, obedeciendo al espíritu de UP. 2. Elaboración: consiste en implementar los componentes básicos de la arquitectura y manejar los factores de riesgo conocidos. De manera tal que al finalizar esta fase se asegure que la arquitectura soportará las funcionalidades claves del sistema en términos de desempeño, escalabilidad y costo. 3. Construcción: se implementan todas las funcionalidades del sistema sobre la arquitectura establecida y se obtiene como resultado la capacidad operacional del sistema. 4. Transición: sirve para desplegar el sistema ante los usuarios, recibir las críticas sobre la primera versión operacional del sistema, refinar el sistema y entrenar a los usuarios para que puedan usarlo adecuadamente XP: Extreme Programming Es una metodología diseñada para responder a los problemas generados por cambios en los requerimientos durante el desarrollo del proyecto, ya que en la mayoría de los proyectos de software el

22 16 cliente no sabe exactamente lo que quiere. Este cambio continuo en los requerimientos es la única constante en los ambientes de desarrollo de software [11]. Se fundamenta principalmente en la flexibilidad de poder cambiar requisitos durante la fase de desarrollo de un proyecto. Esto es considerado una buena práctica debido a la naturaleza volátil de los requerimientos y a la posibilidad de que surjan nuevos. Características - Mantener la comunicación entre los programadores y los clientes. - Realizar un diseño simple. - Probar diariamente el software. - Entregar el software al cliente lo antes posible y hacer los cambios sugeridos. - Estar en la capacidad de responder ante los cambios de requerimientos y de tecnología. Plantea diversas reglas y prácticas a usar durante cada una de las fases conocidas de un proyecto: planificación, diseño, codificación y prueba. 1. Planificación: durante esta fase se deben escribir las historias de usuario. Éstas son escritas por los clientes para indicar de forma puntual lo que necesitan que haga el sistema por ellos. Además se estiman los tiempos que durará cada historia de usuario. Se divide el proyecto en iteraciones y cada iteración tiene un plan asociado. 2. Diseño: para el diseño se busca que sea lo más simple posible. Se escoge un sistema de metáforas para nombrar las clases y los métodos de forma tal que se expliquen por si solos y describan la naturaleza del sistema. 3. Codificación: durante esta etapa el cliente siempre tiene que estar abierto a responder preguntas, participar y colaborar con el equipo de desarrollo cada vez que sea necesario. El código debe estar acorde con el estándar establecido, generalmente se utiliza el estándar del lenguaje de programación utilizado. Se deben crear las unidades de prueba antes de codificar, ya que le permite al desarrollador considerar todo lo que se debe tomar en cuenta al momento de desarrollar las funcionalidades. Cada vez que se aprueba un módulo se debe integrar, lo que permite detectar y anticipar errores de integración. La optimización de código se deja para el final. 4. Prueba: en esta fase se deben tener pruebas unitarias para todo el código. Antes de generar una

23 17 nueva versión, el código debe aprobar todas las pruebas unitarias. Cada historia de usuario tiene una prueba de aceptación asociada, es decir, uno o varios escenarios planteados por el cliente donde se espera que el sistema actúe correctamente XP vs. RUP Después de describir ambas metodologías, se pueden apreciar con más claridad sus diferencias. Estas derivan de los objetivos que cada metodología quiere alcanzar. Por un lado, RUP fue creada para que proyectos de larga duración se estructuraran desde un principio. Con lo cual se desea mantener una documentación bastante detallada de todo lo que se haga a lo largo del proyecto. De manera tal que se le pueda hacer un seguimiento al software y que éste no se desvíe de los objetivos que debe cumplir. En cambio, XP fue diseñada para lograr proyectos en poco tiempo. Esto lo hace con la documentación necesaria, es decir, la que le da el propio cliente y así gana tiempo para el desarrollo del software. No se gasta el tiempo en tener documentaciones muy detalladas de cada uno de los cambios que sufre el proyecto como RUP y se enfoca más en cómo se tiene que desarrollar el software para evitar errores. XP a diferencia de RUP no establece fases del proyecto ni lo que se debe obtener al finalizar cada fase. Solo divide el proyecto en iteraciones de igual duración. Con historias de usuario asignadas a cada iteración RUP y XP en el Proyecto Para el desarrollo de la Herramienta de Administración de la solución INFINIX Suite se utilizó como principal metodología RUP, aplicando sus seis buenas prácticas. A esta metodología se le añadió el manejo que hace XP para las pruebas. Rational Unified Process Se utilizó el desarrollo iterativo e incremental en cuanto a los documentos y al software, pues, los diagramas y casos de uso fueron puliéndose en la medida en que se iban generando productos de software.

24 18 El manejo de requerimientos se hizo a través del documento SRS (Software Requirements Specification), desarrollado en la etapa inicial del proyecto. Los requerimientos identificados en esta etapa no fueron manejados de forma rígida, algunos cambiaron durante el desarrollo del proyecto. Otra buena práctica es la arquitectura basada en componentes, en nuestro caso la Herramienta de Administración constituye uno de los componentes de INFINIX Suite ensamblado con los frameworks Spring y Struts, integrados bajo la infraestructura de J2EE. Modelado visual del software con la elaboración de los casos de uso, el diagrama de clases y el diagrama de secuencias. La verificación de calidad que plantea RUP está a cargo del equipo de QA, que en inglés significa Quality Assurance, este grupo se encargó de toda la verificación de calidad en el proyecto de INFINIX Suite. Por último, el control de cambios del software se hizo con la ayuda de las herramientas StarTeam y Continuum. De este punto hablaremos más adelante. Extreme Programming De XP se aplicó el desarrollo iterativo y lo referente a las pruebas. Es decir, todos los métodos de una clase tienen pruebas unitarias y para publicar una versión estable del módulo, ésta tiene que pasar todas las pruebas de todo el proyecto. Estas pruebas unitarias contemplan además del curso normal los casos bordes que pueden existir dentro del contexto del problema. Otra característica utilizada que corresponde a la metodología es probar periódicamente el software. El servidor de Continuum fue programado para ejecutar las pruebas unitarias todas las noches para los proyectos. Dentro de la etapa de codificación se utilizó como práctica el posponer la optimización de código hasta el final del proyecto, es decir, se enfocó en el desarrollo de funcionalidades antes de optimizar el código que las implementa.

25 Starteam, Continuum y Maven Se utilizaron diferentes herramientas tecnológicas para manipular las versiones del proyecto y a su vez compartir la última versión estable del mismo. Para ello se utilizaron las herramientas Starteam, Continuum y Maven. Con Starteam se manejaron las versiones del proyecto, además de ser utilizado como repositorio central para proveer respaldo. Para crear una versión estable del proyecto primero se debían publicar las fuentes en el Starteam, para que el servidor Continuum pudiese accederlas. Esta publicación es hecha directamente por el programador cuando desea generar una versión estable. Una vez publicado un proyecto, el servidor de Continuum construye un JAR mediante la definición de tareas que son ejecutadas por Maven. Es con esta herramienta que se resuelven las dependencias con otros proyectos, se realiza la compilación del código y se ejecutan las pruebas unitarias para finalizar con la construcción del JAR. Al ser generado un nuevo JAR del proyecto, cualquier otro proyecto diferente que tuviese una dependencia a éste, utilizará esta nueva versión. De esta forma se mantienen integrados todos los proyectos que conforman la solución INFINIX Suite.

26 5. Análisis Para levantar los requerimientos de la Herramienta de Administración, fueron necesarias varias reuniones con el tutor industrial. Con estas reuniones se permitió conocer en profundidad el problema y de esta manera seleccionar las mejores opciones para resolverlo tomando en cuenta el alcance y las necesidades del proyecto. Para facilitar el entendimiento del problema y hacerlo más manejable, se dividió el proyecto en varios módulos. Cada módulo comprende la administración de uno o varios componentes de INFINIX. Es necesaria una breve explicación del contexto para facilitar el entendimiento del problema. Para ello a continuación, se presenta sólo los componentes de la solución INFINIX Suite utilizados para el desarrollo de la Herramienta de Administración. Ver Figura 4. Tipo Sesión Canal Tipo Usuario Usuario Agencia Tipo Contraseña Perfil Grupo Grupo_Aplicaciones Ambiente Aplicaciones_Auxiliares Aplicación Etiqueta Menu Figura 4.- Esquema con todos los componentes de la Herramienta. Contexto del Problema Los canales son los medios de distribución bancarios, estos medios pueden ser: taquilla, el Internet Banking, los auto-servicios, entre otros. En esta primera etapa del proyecto de INFINIX para el Banco del Caribe se desarrolla solo el canal de taquilla. Para un canal se debe definir un tipo de sesión, un tipo de usuario, un tipo de contraseña y finalmente uno o varios perfiles. 20

27 21 El tipo de sesión es el que contiene las características de la sesión que puede ser iniciada por un usuario en un canal en específico. Un ejemplo de estas características es el timeout, que establece el tiempo máximo que dura una sesión. Tipo de usuario determina las características de un usuario que accede a un canal. Por ejemplo los usuarios del canal de internet banking necesitan registrar la cédula, mientras que los usuarios del canal de taquilla necesitan un número de taquilla; es en el tipo de usuario donde se establecen las diferencias de los usuarios dependiendo del canal al que pertenezcan. El tipo de contraseña es el que establece las características de una contraseña de un usuario. Por ejemplo, el tiempo de expiración, el tamaño máximo y mínimo, entre otros. Perfil es el que delimita las funciones de un usuario en un canal. El perfil es el que contiene los privilegios de los usuarios en el canal. Un perfil comprende un grupo de aplicaciones y un ambiente, los cuales establecen las características de la interfaz que verá un usuario. Ambiente permite definir las características visuales que serán expuestas por el sistema en el desktop. El ambiente está compuesto por el menú y por las aplicaciones auxiliares. Menú es la interfaz que lista de manera organizada las aplicaciones que podrá acceder el usuario. Las aplicaciones auxiliares, son el conjunto de aplicaciones que a pesar de no pertenecer al menú están disponibles en el ambiente al que pertenecen. Éstas tienen una organización diferente. A pesar de que el menú y las aplicaciones auxiliares contengan listadas todas las aplicaciones asociadas a un perfil, existe el grupo de aplicaciones. Este grupo es el que define cuales de las aplicaciones que pertenecen al ambiente (bien sea en el menú o en las aplicaciones auxiliares) pueden ser accedidas por los usuarios de un perfil. Las aplicaciones de usuario son el conjunto de aplicaciones que son añadidas a un usuario en particular. La funcionalidad de este componente es permitir personalizar con mayor detalle el rol de un usuario. Las propiedades son aquellas variables que pertenecen al entorno de la aplicación INFINIX Suite, que son definidas de manera global para todo el sistema. Un ejemplo de ello es número del banco. Este número puede ser utilizado en toda la aplicación como una propiedad, que al

28 22 momento de cambiar, no se ve afectado su uso en la solución. Las etiquetas son utilizadas para dar el nombre con el cual será desplegado cada uno de los elementos del menú. Estas permiten que un menú exista en diferentes idiomas. Una vez aclarado el contexto del problema, se identificaron los actores involucrados, las funcionalidades que deben tener la Herramienta de Administración, los casos de uso y los requerimientos no funcionales Actores El único actor relevante dentro del problema es el administrador; es el usuario que tiene acceso a la herramienta y posee los privilegios para administrar los componentes. Queda abierta la posibilidad de poder definir distintos niveles de privilegios para un administrador que permita acceder a uno o varios módulos de la Herramienta de Administración Requerimientos Funcionales Generales La Herramienta de Administración debe de validar al administrador solicitando su código de usuario y contraseña, para permitirle el acceso a la herramienta. Los componentes de INFINIX que deben ser administrables son: Ambiente, Agencia, Aplicación, Canal, Grupo, Menú, Perfil, Propiedad, Tipo de Contraseña, Tipo de Sesión, Tipo de Usuario y Usuario. Al iniciar sesión en la herramienta, se debe de mostrar un menú con las diferentes opciones para el administrador. Este menú debe presentar todos los componentes administrables del sistema, con las opciones de listar y crear por cada uno. Para obtener toda la información de un elemento en particular se debe de haber seleccionado previamente dicho elemento de la lista. Esta lista debe haberse mostrado con la opción del menú listar, y contiene todos los elementos para un tipo de componente. Las opciones de modificar y eliminar deben existir al momento de obtener toda la información de un elemento de cualquier componente, es decir, las opciones de modificar y eliminar aparecen

29 23 luego de obtener un elemento. Una vez seleccionada la opción eliminar, se debe desplegar una ventana de confirmación antes de proceder con la eliminación. Al seleccionarse la opción de modificar se debe mostrar todos los campos que pueden ser editados, con la data correspondiente al elemento escogido para ser modificado Requerimientos Funcionales por Módulo A continuación se listan los diferentes módulos de la herramienta con los requerimientos funcionales particulares para cada uno. En algunos módulos no existe ningún requerimiento particular, pero de igual forma se presentan todos los módulos. Módulo de Canales Para las opciones de crear y modificar se debe de desplegar la lista de todos los tipos de usuario, tipos de contraseña y tipos de sesión, para permitir al administrador escoger una opción por cada uno de ellos. Módulo de Tipos de Contraseña Módulo de Tipos de Sesión Módulo de Perfiles Para crear y modificar un perfil se debe de desplegar la lista con todos los ambientes, grupos de aplicaciones y canales, para permitir al administrador seleccionar una opción por cada lista. Por la gran cantidad de perfiles que se manejarán, se debe proporcionar un motor de búsqueda de perfiles por canal. Módulo de Usuarios o Usuario Para permitir crear un nuevo usuario, primero se debe validar su usuario (username) a través de la base de datos del banco. Esta validación debe de hacerse con el servicio de LDAP. Al ser válido el usuario, se deben obtener los datos: nombre, apellido y correo electrónico que el banco posee registrados para ese usuario. Los datos obtenidos deben ser guardados como atributos del nuevo

30 24 usuario creado. En las opciones de crear y modificar un usuario, se deben de presentar las listas de perfiles, agencias y tipos de usuario. Para los campos de perfiles y agencias se debe permitir al administrador escoger una o varias opciones, para el caso del campo tipo de usuario la selección debe ser simple. Debido a la gran cantidad de usuarios se debe proporcionar un pequeño motor de búsqueda. Esta búsqueda debe de poder hacerse por nombre y/o apellido, por perfil o por canal. o Tipo de Usuario Módulo de Aplicaciones o o Aplicaciones Grupo de Aplicaciones Para crear y modificar un grupo de aplicaciones se debe desplegar una lista con todas las aplicaciones. De esta lista el administrador debe seleccionar una o varias aplicaciones que conformarán el grupo. o Ambiente Para las opciones de crear y modificar se debe desplegar una lista con todas las aplicaciones del sistema, para que el administrador pueda escoger aquellas que desea como aplicaciones auxiliares para el ambiente. o Menú Se debe de facilitar la creación y modificación de un menú a través de una interfaz gráfica con drag and drop, que permitan arrastrar las aplicaciones hasta el nivel del menú donde se desea colocar. Adicionalmente se debe crear las etiquetas para cada uno de los elementos que va conformando el menú. Con la opción de listar Menú, se deben de mostrar la lista de ambientes, debido a que el menú no se identifica por sí solo, sino por el ambiente al que pertence. Al seleccionarse un ambiente de la lista, se debe desplegar de forma gráfica y navegable el menú para ese ambiente. Módulo de Propiedades Módulo de Agencias

31 Requerimientos No Funcionales Los requerimientos no funcionales presentados a continuación son de manera general para toda la herramienta. El esquema de seguridad que deberá utilizarse para autenticar a los usuarios deberá ser el mismo implementado para validar el acceso de los usuarios a INFINIX Suite, de forma tal de seguir los lineamientos de seguridad. El esquema de interfaces con el usuario seguirá los patrones implementados por los demás subsistemas. Considerando los mismos como amigables e intuitivos. El sistema debe soportar la interfaz JDBC para acceder a las bases de datos según el estándar SQL.

32 6. Diseño En este capítulo se describen las decisiones de diseño tomadas para la implementación de la Herramienta de Administración. Principalmente se explica cómo se conforman y dividen los diversos proyectos que constituyen la herramienta. Ver Figura 5. La estructura de la solución INFINIX Suite para el Banco del Caribe está compuesta por dos importantes sistemas, el sistema del Framework de INFINIX que contiene todos los servicios generales para la herramienta de INFINIX Suite independiente del banco cliente, y el sistema de INFINIX Caribe que corresponde a todos los servicios propios del Banco del Caribe. Dentro del Framework de INFINIX se encuentran los proyectos con los servicios internos. Estos proyectos comprenden los DAO s e interfaces de los servicios internos. En el sistema INFINIX Caribe se encuentran los proyectos de los servicios externos, presentación y web. Estos dos sistemas proveen flexibilidad y adaptabilidad de la solución a cualquier entidad financiera. La Herramienta de Administración para INFINIX Suite respeta esta estructura, por lo que posee un proyecto por cada uno; servicios internos, servicios externos, presentación y web. Figura 5.- Estructura de los proyectos en INFINIX Suite 26

33 Framework INFINIX 1. Servicios Internos Todos los servicios internos utilizados para la Herramienta de Administración se encuentran en varios proyectos dentro del Framework de INFINIX dependiendo del propósito de cada uno de los servicios. Por ejemplo, los servicios relacionados directamente con los componentes administrables están dentro del marco de seguridad de INFINIX, el cual se encuentra englobado en el proyecto infinix-security. Otros servicios como la validación por LDAP y el manejo de etiquetas, propiedades e idiomas pertenecen a los proyectos de infinix-common e infinix-catalog respectivamente. Para cada tabla de la base de datos se creó una interfaz DAO, inicialmente con los métodos más comunes: insertar, modificar, obtener y eliminar. En las interfaces DAO se colocan todos los métodos que interactúan de con la base de datos. Esto permite identificar claramente las capas que hacen más fácil la depuración de los errores. Representa la capa Data Access Layer dentro de INFINIX Suite. Los DTO son los patrones utilizados para transferir los datos entre las diferentes capas de la aplicación. Por cada tabla de la base de datos se creó un DTO, que contiene los mismos atributos de la tabla más todos aquellos que sean necesarios para su manejo. Para las claves foráneas la traducción corresponde a un objeto. Este objeto es el DTO que representa la tabla a la cual se hace referencia. Por cada interfaz DAO se crea una interfaz de servicio que representa los servicios internos del Framework INFINIX. Por lo general cada servicio utiliza un método en el DAO. Dichos servicios son los que pueden ser utilizados por la capa de servicios externos en INFINIX Caribe Infinix Caribe 1. Servicios Externo Los servicios externos son utilizados para comunicarse con los servicios del Framework INFINIX. En estos servicios se introducen los aspectos propios al banco y ajenos a la solución, se puede entender como el punto intermedio entre INFINIX Suite e INFINIX Caribe, es decir, entre la solución general y la solución para el Banco del Caribe. Una de las diferencias entre Framework INFINIX e INFINIX Caribe es el idioma, todo lo que se

34 28 maneja en el primero es en inglés mientras que para el segundo es en español. Dentro de los servicios externos se hace el manejo de errores que interesan de cara al usuario del sistema. Por cada DTO del Framework de INFINIX se crea un DTO en INFINIX Caribe que lo encapsula y a su vez permite el manejo de errores. Los servicios externos junto a los internos, representan la capa lógica del negocio (Business Logic Layer), y son los servicios externos los que permiten la comunicación entre los servicios del Framework de INFINIX y la capa de presentación. La comunicación entre estas dos capas es a través de la capa Deployment Layer de la solución. 2. Presentación La capa de presentación dentro del proyecto se divide en dos, por un lado se tiene la estructura usada por el framework Struts y por el otro se tiene la parte web asociada a los Javascript, páginas JSP y HTML. Lo que llamamos en este proyecto presentación se refiere a todos los action y form pertenecientes a la estructura del framework de Struts. Por cada caso de uso por módulo se hace referencia a una clase action y si lo necesita una clase form. Es en el action donde se hacen las llamadas a los servicios externos, utilizando los DTOs de InfinixCaribe como parámetros de entrada y salida. 3. Web Engloba todos lo referente a lo que finalmente constituye la página web y es visualizado por el usuario, HTML, JSP, Javascript, CSS, imágenes, además de los archivos de configuración de Struts y de Spring. Presentación y web son los proyectos que entran dentro de la capa Presentation Layer de la solución. Otra decisión de diseño fue validar todos los parámetros de entrada antes de utilizar un servicio externo. Sólo se validan los datos que son utilizados como parámetros de entrada para la llamada a un servicio externo y que fueron introducidos por el usuario en la página web. Estos datos son los utilizados para construir el DTO que se utiliza para la comunicación entre capas. En el único escenario donde un usuario introduce datos en un formulario es para el caso de

35 29 modificar o crear un elemento de un componente. Por lo general para esta validación se utilizó la interfaz validate que provee Struts en los form. En los casos donde se consideraba muy costoso y difícil de manejar ir al servidor para procesar la validación y posteriormente reenviar la página hacia el cliente con los mensajes de error con el último estado en que fue dejada la página por el usuario, se utilizó Javascript para la validación de campos. Para estos casos la validación ocurre del lado del cliente, por lo que no se incurren en costos de procesamiento ni problemas para desplegar la página tal y cómo el usuario la dejó Base de Datos INFINIX INIX Para la Herramienta de Administración no fue necesario ningún diseño de base de datos, pues esta herramienta trabaja con las tablas ya establecidas para la solución de INFINIX y aprobadas por la entidad bancaria. En algunos casos fueron necesarios pequeños cambios de alguna de las tablas, pero sólo como pequeñas mejoras, por ejemplo un campo de una tabla como único (unique), los identificadores de las tablas como auto-incrementos, entre otros. En cuanto a la estructura no se realizó ningún cambio.

36 7. Implementación Luego de culminar la etapa de diseño del proyecto, se prosiguió con la implementación. Dentro de la implementación se desarrollaron las funcionalidades especificadas en la etapa de análisis siguiendo los patrones de diseño ya establecidos. Estas funcionalidades corresponden a los casos de uso respetando las exigencias de los requerimientos. Antes de desarrollar las funcionalidades se creó un prototipo de interfaces sin ningún tipo de funcionalidad que permitió aún más comprender todo el problema. Fue para este prototipo que se incluyó la primera funcionalidad de inicio de sesión. Para desarrollar las funcionalidades de la herramienta se respetó el orden establecido por módulos en el plan de trabajo. Por cada módulo se comenzó con la implementación de los DAO y los servicios internos pertenecientes al sistema del Framewok INFINIX. Posteriormente se conectaban los servicios internos con los externos que pertenecen al sistema INFINIX Caribe. Finalmente se generaban todo lo relacionado con la capa de presentación. La implementación de la capa de presentación comenzaba con las páginas JSP para posteriormente incluir las funcionalidades con los action y forms por página Beans Spring Todos los servicios tanto internos como externos y las clases DAO son manejados como beans con la plataforma de Spring. Estos beans deben ser configurados en el XML respectivo, con todas las dependencias y propiedades que sean necesarias. Para colocar cada interfaz de servicio y DAO como bean, es necesario incluir un archivo XML con la nomenclatura de Spring por cada proyecto. A continuación se presenta un pequeño fragmento del XML de Spring para el proyecto de infinix-security. <bean id= beanbranchdao class= com.wincornixdorf.infinix.security.dao.impl.branchdaoimpl > <property name= database > <ref local= beandatabase /> </property> </bean> 30

37 31 <bean id= beanbranchservice class= com.wincornixdorf.infinix.security.impl.branchserviceimpl > <property name= branchdao > <ref local= beanbranchdao /> </property> </bean> En este pequeño fragmento del archivo XML podemos observar como el bean beanbranchdao tiene la propiedad database que hace referencia al bean beandatabase, el cual posee la configuración del JDBCTemplate necesaria para todo el acceso a la base de datos. Debido a que los DAO se encargan de interactuar con la base de datos, los beans para estas clases poseen como propiedad el bean con el JDBCTemplate de la base de datos. El bean branchservice representa un servicio interno para el manejo de agencia en el framework de INFINIX, posee la propiedad branchdao que hace referencia al bean beanbranchdao de la clase DAO para la agencia. Cada servicio necesita de la referencia al bean del DAO correspondiente, ya que los servicios por lo general utilizan los métodos que proveen los DAO. En este ejemplo el servicio interno hace uso del DAO que le corresponde, pero pudiese necesitar de otras clases u otros servicios, en el caso que así lo necesite se colocan todas las propiedades con referencias a los beans que se deseen utilizar. Para comprender fácilmente los beans de los servicios externos daremos un pequeño ejemplo a continuación extraído del XML del AdministradorService en InfinixCaribe. <bean id= agenciaservice class= com.wincornixdorf.infinix.administrador.service.impl.agenciaserviceimpl > <property name="branchservice"> <ref bean="beanbranchservice"/> </property> </bean> El bean agenciaservice representa el servicio externo para el manejo de las agencias en InfinixCaribe, posee la propiedad branchservice que hace referencia a los servicios internos con el bean beanbranchservice (expuesto en el ejemplo anterior). Los bean de los DAO son utilizados por los servicios internos y a su vez, los beans de los servicios internos son llamados por los servicios externos, estos últimos son los utilizados en la capa de presentación. A través de las declaraciones de los beans se visualiza la dependencia que existe entre cada una de las capas de la aplicación y la interacción entre ellas.

38 Pruebas ruebas: : JUnit Las pruebas son esenciales para el buen manejo y control en el desarrollo de un proyecto. Dentro de la metodología XP son un punto importante. Para este proyecto se utilizaron las pruebas unitarias con el framework JUnit. JUnit es un framework de código abierto utilizado para crear pruebas unitarias y ejecutarlas repetidamente. Es una instancia de los frameworks xunit de pruebas unitarias para Java. [12]. Para hacer un uso exitoso de este framework se creó una clase de prueba por cada clase que requiriese ser probada. Dentro de cada clase prueba se agregaron pruebas unitarias para cada caso de uso por cada método de la clase. Estos casos de uso se limitaron a casos aceptados, casos bordes o casos inválidos, con la finalidad de tener registrado en cuáles ocasiones el método devuelve el resultado esperado o lanza la excepción adecuada Manejo de Errores Las excepciones en Java proveen un mecanismo consistente para identificar y responder a condiciones de error. Estas excepciones se clasifican en dos categorías: Checked Exceptions: Excepciones que deben ser capturadas para manejar la situación que ellas indican. De no ser capturadas deben ser lanzadas a niveles superiores pues su tratamiento se debe realizar de forma obligatoria, por eso son llamadas chequeadas. Unchecked Exception: Excepciones que no necesitan un tratamiento por lo que no hace falta sentencias de try-catch o throws para manejarlas. Usualmente son provocadas por un bug en el sistema. Las excepciones creadas para el proyecto INFINIX Suite son del tipo Unchecked. Aunque el concepto anterior explica que no necesitan ser manejadas, por decisiones de diseño estas excepciones no pueden llegar a la capa de Presentación y en consecuencia son capturadas en la capa de servicios externos. Para el manejo de excepciones se tienen dos interfaces y dos clases que son las que lanza el sistema INFINIX, estas se pueden apreciar en la Figura 6.

39 33 interface InfinixException Exception interface BusinessException RuntimeException InfinixRuntimeException BusinessRuntimeException Figura 6.- Manejo de Exceptions Las InfinixException son excepciones lanzadas por el Framework del sistema mientras que las BusinessException son lanzadas por el Framework y por la capa INFINIX Caribe. Para usar las BusinessException se debe incluir un mensaje de información con el código correspondiente en el archivo de errores de INFINIX Caribe. Este archivo contiene los mensajes mostrados al usuario y por ende todos ellos deben estar en el contexto del usuario. El flujo de excepciones a través del sistema es de la siguiente manera: Presentación DTOs Servicios Externos DAO s Excepciones Servicios Internos Figura 7.- Manejo de Exceptions en INFINIX Suite En la Figura 7 se puede observar cómo las excepciones son tratadas entre los servicios y los DAO sin llegar a la capa de presentación. Entre la capa de presentación y la de servicios externos sólo se intercambian DTOs de InfinixCaribe. Si ocurrió alguna excepción en los servicios externos, éstos deben devolver el DTO respectivo con el mensaje de error especificando lo que ocurrió. En los servicios

40 34 externos no se lanzan excepciones a la capa de presentación. Todos los DTO de InfinixCaribe deben extender de la clase InfinixDTO. Esta clase es la que contiene realmente un campo de error donde se guarda el mensaje antes mencionado. De igual manera todos los DTO deben tener un constructor que reciba un objeto InfinixDTO con la finalidad de conservar la traza de toda la transacción. [15] Como se mencionó en el capitulo de diseño, los DTO s de InfinixCaribe encapsulan los DTO s provenientes del framework. Esto se hace con el propósito de reutilizar los DTO del framework para añadirle el manejo de errores a través de la herencia de la clase InfinixDTO. En la Figura 8 vemos como en el Framework se hacen uso de los DTO del Framework, mientras que en InfinixCaribe se hace uso del DTO que resulta de la unión del DTO del Framework con el InfinixDTO que maneja los errores. Para la comunicación entre los servicios internos y los externos se hace uso de los DTO del Framework, es en este punto que se genera el DTO que finalmente es utilizado para la comunicación de los servicios externos con la presentación. Todos los DTO además de heredar de InfinixDTO, para el manejo de los errores, deben implementar la interfaz serializable, que permite enviar el objeto por valor desde el dominio de una aplicación a otro. + Figura 8.- Uso de los DTO en InfinixCaribe y en el Framework.

41 LDAP para INFINIX Suite Recordamos que la solución INFINIX Suite se está desarrollando para el Banco del Caribe, pero con la finalidad de ser adaptable para cualquier otra entidad financiera. Es por ello que la Herramienta de Administración debe colaborar con sistemas externos utilizados por el Banco del Caribe. El acceso a la base de datos del Banco del Caribe se hace utilizando el protocolo de servicio de directorio LDAP. Acceder a esta base de datos es un punto importante para la Herramienta de Administración. Datos personales de los usurarios que deben ser creados en la base de datos de INFINIX provienen de la base de datos del banco. Establecer la conexión con el servidor LDAP se hace a través de la interfaz DirContext creando una nueva instancia del objeto InitialDirContext. InitialDirContext es una clase que permite establecer el contexto inicial para desempeñar las operaciones de directorio. Para crear un nuevo InitDirContext son necesarias ciertas variables de ambiente, como la contraseña (Security Credentials), el nombre distinguido (DN) y el URL del host. El DN (Distinguished Name) es el identificador único por persona que permite la entrada al árbol de directorio LDAP. Todos los valores de estas variables de ambiente son inyectados con Spring como propiedades del bean LDAPService en el archivo de configuración que se muestra a continuación. <bean class="com.wincornixdorf.infinix.common.service.impl.ldapserviceimpl" id="ldapservice"> <property name="host"> <value>ldap:// :389</value> </property> <property name="distinguishedname"> <value> CN=Teja,Carolina,OU=Usuarios,OU=BANCARIBE,DC=tpr,DC=bancaribe</value> </property> <property name="securitycredentials "> <value>xxxxxxx</value> </property> </bean> Toda la implementación del servicio LDAP para la conexión y validación de usuarios recide en el proyecto infinix-catalog presente en el Framework de Infinix. Este servicio no se encuentra en el mismo proyecto donde están el resto de los servicios de la Herramienta de Administración, esto se debe a que el

42 36 servicio de validación de usuario es común al resto de los módulos de INFINIX Suite. Se utilizará para el inicio de sesión de los usuarios en el sistema INFINIX Suite. Para validar un usuario que se desea crear con la Herramienta de Administración, primero es necesario establecer la conexión con el servidor LDAP y así consultar si dicho usuario existe para el banco AJAX JAX: Asynchronous JavaScript and XML Para la operación de validación al momento de crear un usuario en la Herramienta de Administración se utilizó AJAX. Con el uso de ésta técnica la validación se hace de forma transparente para el usuario administrador. En el momento que el administrador introduce el campo correspondiente al usuario (username) y cambia el foco de éste input a otro en la página web, se hace la llamada al servicio para validar el usuario (campo onblur de la etiqueta HTML input). AJAX es una técnica para el desarrollo de aplicaciones web interactivas. Esta técnica tiene como propósito minimizar la transferencia de datos con el servidor y lo hace de forma transparente para el usuario. Permite incrementar la interactividad, rapidez y usabilidad de las aplicaciones web. [14] AJAX se utilizó de la siguiente forma en este proyecto, al efectuarse un evento en la página se hace la llamada a un método Javascript el cual ejecuta la conexión asíncrona con el servidor en búsqueda de información. En nuestro caso la conexión asíncrona hace la llamada a un Action de Struts, el cual utiliza el servicio necesario del Administrador para obtener la información y devolverla al Javascript como un archivo XML. Cuando el método Javascript recibe el XML con la información, se manipula y se hacen los cambios necesarios que finalmente visualiza el usuario en la página web Librería Drag and Drop Uno de los requerimientos para la administración del componente menú dentro de la Herramienta de Administración fue el proporcionar una interfaz con la técnica conocida como drag and drop. Esta técnica permite al usuario seleccionar un objeto y arrastrarlo hasta el lugar donde desea colocarlo. En nuestro contexto, permite arrastrar las aplicaciones hasta el lugar o nivel del menú donde

43 37 desean ser colocadas, obteniendo como producto final el menú utilizado por los usuarios de INFINIX Suite. Esta funcionalidad fue agregada al proyecto a través de la librería drag-drop-folder-tree del autor Alf Magne Kalleland, la cual puede ser obtenida de forma gratuita del sitio web Esta librería fue escogida ya que se adaptaba fácilmente a nuestros requerimientos y además proveía una estructura de árbol semejante a la de administración de carpetas y archivos de un directorio lo cual la hace fácil de manejar. Ver Figura 9. Antes de seleccionar la librería se analizaron las existentes en internet como por ejemplo la librería YUD (The Yahoo! User Interface), pero se consideró drag-drop-folder-tree la más fácil de integrar a la herramienta y por ello fue escogida. Figura 9.- Fragmento de la página para modificar un menú donde se puede observar la estructura de directorio. El árbol se construye con las etiquetas de HTML para listas: <UL> y <LI>, y es con Javascript que los nodos pueden ejecutar acciones de drag y drop. Además fue necesario integrarla con otra librería que permitiese crear nuevos nodos en el árbol. La

44 38 librería escogida es folder-tree-static proveniente del mismo lugar de la librería anterior. Esta nueva librería permite agregar y eliminar nodos a la misma estructura de árbol que maneja la librería antes mencionada. Como era necesario colocar la opción de modificar el nombre de un nodo del árbol, fue necesario implementar para la librería folder-tree-static una nueva función modificar. Al integrar las dos librerías fue necesario realizar ciertos cambios para que juntas funcionaran correctamente y proveyeran de las funcionalidades exigidas en los requerimientos del proyecto.

45 8. Resultados La herramienta permite la administración de doce componentes de la solución INFINIX Suite que fueron detallados por sub-módulos en el capitulo de análisis. Por cada uno de los componentes se puede listar todos sus elementos, crear uno nuevo, eliminar uno existente y modificar uno en particular. Como estos cuatro casos de uso se repiten por cada componente escogimos para presentar los resultados dos componentes en particular. Debido a la complejidad que involucra el manejo de usuarios en comparación al resto de los módulos, éste es el escogido para ser explicado con detalle. Éste módulo se considera más complejo pues se utiliza la tecnología de AJAX y la comunicación con el servidor de LDAP. Como el módulo de administración de menú es muy versátil y por ende diferente en apariencia al resto de los módulos también formará parte de la explicación en los resultados. Es en éste que se utiliza la técnica del drag and drop Módulo de Administración de Usuarios 1. Crear Usuario Parte de la pantalla que corresponde a la creación de un nuevo usuario se muestra a continuación. 39

46 40 Figura 10.- Pantalla para crear un usuario. En ella podemos observar los diferentes campos para el formulario para crear un usuario. Los campos que corresponden al nombre, apellido y son de sólo lectura, ya que estos no son datos introducidos por el usuario, si no que son obtenidos con AJAX utilizando el servicio de LDAP de acuerdo al campo usuario ingresado. El campo localidad es de selección simple, por el contrario el campo perfiles y agencias son de selección múltiple. El campo tipo de usuario es más elaborado, pues de acuerdo al tipo de usuario que seleccione el administrador se busca con AJAX los campos que corresponden para el tipo seleccionado. En el Figura 11 se muestran los campos con sus nombres incluidos en la página luego de haberse seleccionado el tipo de usuario Usuario Temporal.

47 41 Figura 11.- Pantalla para la creación de un usuario luego de seleccionar un tipo de usuario y completar los campos del formulario. Si existe algún problema con la búsqueda del usuario se muestra un mensaje de error al administrador para que conozca el estado de la transacción. Este caso se muestra en la Figura 12.

48 42 Figura 12.- Mensaje de error al introducir un usuario inválido en la creación de usuarios 2. Listar Usuarios Luego de seleccionar en el menú la opción Listar Usuario se despliega la pantalla con la tabla que contiene todos los usuarios ordenados alfabéticamente. En general para cualquier módulo la lista de elementos que se muestra dentro de la tabla es paginada si es necesario, es decir si el volumen de datos es mayor al escogido para nuestra aplicación que es de veinte elementos. En la Figura 13 se muestra la imagen que corresponde a la pantalla de lista de usuarios.

49 43 Figura 13.- Pantalla con la lista de usuarios. Por cada fila de la tabla se presenta un usuario con su nombre y apellido. El campo que corresponde al usuario es un enlace que puede ser seleccionado para presentar en detalle toda su información. Este enlace corresponde al caso de uso Obtener Usuario. El botón buscar representa el caso de uso Buscar Usuario el cual se presenta a continuación. 3. Buscar Usuario Como opciones del pequeño motor de búsqueda para el componente usuario tenemos el nombre y apellido, perfil y canal. Cada uno de ellos son campos independientes de búsqueda lo que no permite ser utilizados en conjunto. En la Figura 14 se muestra la pantalla para la búsqueda de usuarios con todos lo campos indicados. Al escoger o ingresar el campo por el cual se desean filtrar los usuarios se muestran los usuarios que cumplen dichas condiciones igual que para el caso de uso Listar Usuario que fue explicado anteriormente.

50 44 Figura 14.- Pantalla para la búsqueda de usuarios. 4. Obtener Usuario Luego de ejecutar Listar Usuarios se puede seleccionar el usuario que se desee ver en detalle bien sea para eliminarlo, modificarlo o simplemente obtener toda su información. En este caso se muestran todos los campos que fueron ingresados al momento de la creación pero como lectura para no permitir su modificación. Ver Figura 15.

51 45 Figura 15.- Pantalla que se muestra al obtener un usuario. 5. Eliminar Usuario Como se observa en la Figura 15 tenemos el botón eliminar para el caso que se desee borrar definitivamente un usuario. Para este caso se muestra un mensaje de confirmación con el nombre y apellido del usuario seleccionado con el cual se procede o no con la transacción. Ver Figura 16. Figura 16.- Mensaje de confirmación para eliminar un usuario.

52 46 6. Modificar Usuario Para modificar un usuario se muestran todos los campos del componente usuario de tal manera que puedan ser editados por el administrador igual que al momento de la creación de un usuario. Ver Figura 17. Existen dos pequeñas diferencias en comparación con la creación de un usuario. Una es que los campos usuario, nombre, apellido y son de solo lectura, ya que estos son obtenidos de la base de datos del banco y no tiene sentido que el administrador de INFINIX los modifique. La segunda es de un nuevo campo de selección que corresponde a las aplicaciones auxiliares para un usuario. Este campo permite hacer selección múltiple. Figura 17.- Pantalla para modificar un usuario.

53 Módulo de Administración para Menú 1. Crear Menú Para crear un nuevo menú es necesario seleccionar el ambiente al que corresponde y el idioma en el que desea elaborar como se muestra en la Figura 18. Figura 18.- Primera pantalla para crear un menú. Luego de seleccionar el ambiente y el idioma se puede construir la estructura del menú. Para ello se encuentra una lista con las aplicaciones que pueden ser incluidas con drag and drop dentro del menú. La carpeta que se muestra como Menú Raíz es la base del nuevo menú que se desea crear. Para crear, modificar o eliminar carpetas es necesario desplegar el menú con el botón derecho del ratón sobre el lugar donde se desea realizar cualquiera de estas acciones. El menú se muestra en la Figura 19. Al seleccionar la opción del menú Crear, se muestra una ventana para introducir el nombre de la nueva carpeta a insertar. Ver Figura 20.

54 48 Figura 19.- Pantalla para crear la estructura de menú. Figura 20.- Ventana para crear una nueva carpeta. Luego de crear una nueva carpeta se pueden incluir aplicaciones dentro de éste arrastrándolas con el ratón y depositándolas en ella. Ver Figura 21. Si se desea modificar el nombre de una carpeta o una aplicación se debe seleccionar dicha opción del menú y se despliega la ventana para introducir el nuevo nombre, como se muestra en la Figura 22. Con todas estas acciones se puede ir construyendo el menú de forma interactiva y de manera tal que el usuario puede seguir su visualización paso a paso.

55 49 Figura 21.- Pantalla donde se muestra el drag and drop. Figura 22.- Ventana para modificar una carpeta del menú. 2. Listar Menús Este caso de uso sufre una pequeña modificación debido a que los menús no se identifican por sí solos, sino por el ambiente al que pertenecen. Es por ello que se muestra es la lista de ambientes que poseen un menú como se muestra en la Figura 23. De esta lista se puede seleccionar el ambiente que se desee para obtener más información.