Repositorio Institucional de Documentos

M MC C- -S SP PY Y U UN N S SI IS ST TE EM MA A P PA AR RA A L LA A E EX XP PL LO OT TA AC CI IÓ ÓN N D DE E L LA A I IN NF FO OR RM MA AC CI IÓ ÓN N H HI IS ST TÓ ÓR RI IC CA A D DE E O OP PE ER RA AC CI IO ON NE ES S R RE EA AL LI IZ ZA AD DA AS S E EN N B BA AN NC CA A E EL LE EC CT TR RÓ ÓN NI IC CA A MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 3 Resumen MC-Spy básicamente es un módulo de una aplicación web, que por un lado: maneja, almacena y gestiona una serie de datos estadísticos obtenidos por él mismo de dicha aplicación web; y por otro lado utiliza todos esos datos almacenados para generar estadísticas y previsiones en formato de texto y gráfico. MC-Spy surgió inicialmente, y de hecho se desarrolló, bajo el contexto de su integración en una banca electrónica, pero puede ser totalmente integrado en cualquier otra aplicación web (Java), como de hecho se hizo posteriormente por parte de la empresa en la que se realizó el proyecto. Gracias a MC-Spy, los administradores de la banca electrónica (o aplicación web en general), podrán detectar al instante posibles errores de funcionamiento de la banca, podrán obtener estadísticas con la que los directores bancarios poder hacer sus decisiones, e incluso mostrar previsiones de entrada de dinero, operaciones que se prevé que se realizarán en la banca en los próximos meses (útil por ejemplo para anticipar un aumento de prestaciones de los servidores) ,etc… gracias a unos algoritmos de previsiones en base a las series de datos almacenados que el mismo MC-Spy ha estado contabilizando. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 4 Agradecimientos Por supuesto, agradecer su preocupación por el futuro de este proyecto, a Javier Campos, verdadero forjador de su (buen) fin. Recordar igualmente a todos mis compañeros del CPS. Reconocer también la preocupación de todos los amigos que de vez en cuando me preguntaban por este proyecto fin de carrera. Gracias a Eva, por todo lo que me has dado sin pedir nada a cambio. Por último y más importante, agradecer a mi familia el apoyo prestado, especialmente a mis padres, ejemplo en mi vida y artífices de mi educación. Todo lo conseguido por mí, es gracias a vosotros. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 5 Índice Resumen .................................................................................................................... 3 Agradecimientos ......................................................................................................... 4 Índice .......................................................................................................................... 5 1 Introducción....................................................................................................... 7 1.1 MC-Server ..................................................................................................... 7 1.2 Situación inicial de partida ........................................................................... 10 1.3 Objetivo final ............................................................................................... 10 1.4 Ampliación ................................................................................................... 11 2 Requisitos ....................................................................................................... 12 2.1 Requisitos funcionales ................................................................................. 12 2.2 Requisitos no funcionales ............................................................................ 14 3 MC-Spy ........................................................................................................... 15 3.1 Breve descripción de MC-Spy ..................................................................... 15 3.2 Arquitectura del sistema .............................................................................. 17 3.2.1 Módulo de recolección de datos ................................................................ 17 3.2.2 Módulo de Administración y consulta de estadísticas ................................ 18 4 Desarrollo del proyecto ................................................................................... 19 4.1 Fases del desarrollo .................................................................................... 19 4.1.1 Fase inicial de estudio ............................................................................... 19 4.1.2 Fase de desarrollo .................................................................................... 20 5 Modelo incremental ......................................................................................... 22 6 Gestión del proyecto ....................................................................................... 23 6.1 Gestión de riesgos ...................................................................................... 23 6.2 Plazos del proyecto ..................................................................................... 24 7 Conclusiones ................................................................................................... 26 7.1 Cumplimiento de objetivos........................................................................... 26 7.2 Extensiones no previstas en los objetivos iniciales ...................................... 26 7.3 Implantación de MC-Spy en sistemas reales ............................................... 26 7.4 Posibles extensiones futuras ....................................................................... 27 7.5 Valoración personal ..................................................................................... 27 7.6 Valoración por parte de la empresa ............................................................. 28 8 Bibliografía ...................................................................................................... 29 Anexo A. Análisis ...................................................................................................... 30 A.1 Primeras decisiones ......................................................................................... 30 A.1.1Aplicación local vs. Aplicación web ............................................................... 30 A.1.2 Base de datos vs. Log ................................................................................. 31 A.1.2.1 Espacio en disco .................................................................................... 31 A.1.2.2 Accesibilidad ......................................................................................... 31 A.1.2.3 Seguridad ............................................................................................... 32 A.1.2.4 Disponibilidad ....................................................................................... 32 A.1.2.5 Información ........................................................................................... 33 A.1.2 Composición del sistema ............................................................................... 33 MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 6 A.1.2.1 Recolección de datos ............................................................................... 33 A.1.2.2 Consulta de estadísticas ........................................................................... 34 A.1.2.3 Árbol de sesiones ..................................................................................... 38 A.1.2.3 Previsiones ............................................................................................... 39 A.1.3 Casos de uso ................................................................................................ 39 A.1.3.1 Uso de una operativa de la banca electrónica .......................................... 39 A.1.3.2 Consulta de una estadística ...................................................................... 42 A.1.3.3 Consulta del árbol de sesiones ................................................................. 43 A.1.4 Estudio teórico de las predicciones ............................................................... 45 A.1.5 Herramientas de desarrollo y auxiliares ......................................................... 47 Anexo B. Diseño ....................................................................................................... 48 B.1.1 Diseño lógico del sistema .............................................................................. 48 B1.1.1 Modelo lógico de subsistemas ................................................................... 49 B1.1.2 Modelo lógico de módulos de los subsistemas .......................................... 50 B.1.2 Diseño físico del sistema ............................................................................... 51 B.1.2.1 Modelo físico general del sistema ............................................................. 52 B.1.2.1.1 Subsistema Recolector de datos .......................................................... 54 B.1.2.1.2 Subsistema Cliente de consultas ......................................................... 55 B1.2.1.1.1 Patrón Model-View-Controller ..................................................... 55 B.1.3 Diseño de los orígenes de datos (BD) ........................................................... 57 B.1.3.1 Diseño lógico de MCSpy BD ..................................................................... 58 B.1.3.2 Creación de la base de datos ................................................................... 60 B.1.3.3 Diseño físico de la base de datos ............................................................. 65 B.1.3.4 Principales decisiones en el diseño de la BD ............................................ 66 B.1.4 Diseño de la interfaz gráfica .......................................................................... 69 B.1.4.1 Árbol de usuarios ...................................................................................... 69 B.1.4.2 Consulta de estadísticas ........................................................................... 72 Anexo C. Implementación ......................................................................................... 75 C.1 Paquetes que componen MC-Spy .................................................................... 75 C.1.1 Paquetes generales ..................................................................................... 79 C.2 Implementación del sistema de inserción en la BD .......................................... 91 C.2.1 Singleton ..................................................................................................... 92 C.2.2 JMS ............................................................................................................. 92 C.3 Implementación y algoritmia para las previsiones ............................................ 95 C.3.1 Detección del tipo de serie de datos ............................................................ 95 C.3.2 Algoritmos para cada uno de los tipos de series .......................................... 96 C.3.2.1 Serie sin tendencia ni estacionalidad ..................................................... 96 C.3.2.2 Serie sin tendencia con estacionalidad ................................................... 97 C.3.2.3 Serie con tendencia sin estacionalidad ................................................... 97 C.3.2.4 Serie con tendencia y con estacionalidad............................................... 97 C.4 Implementación de aspectos gráficos............................................................... 99 C.4.1 Árbol de sesiones ........................................................................................ 99 C.4.2 Estadísticas gráficas .................................................................................... 99 Anexo D. Pruebas .................................................................................................. 101 D.1 Pruebas unitarias ......................................................................................... 101 D.2 Pruebas de integración ................................................................................. 102 D.3 Respuesta ante un error detectado .............................................................. 102 Índice de figuras ..................................................................................................... 104 MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 7 1 Introducción MC-Spy surgió en un principio como un módulo que se debería de integrar dentro de un sistema de banca electrónica multicanal (MultiChannel Server, a partir de ahora MCServer), que se estaba desarrollando en la empresa TB-Solutions (a partir de ahora TBS). A través de MC-Server, los clientes de un banco, iban a poder realizar diversas operaciones bancarias desde su casa o lugar de trabajo mediante una conexión a Internet. El número de las operativas disponibles en MC-Server era relativamente grande, y el grado de diversidad entre ellas, alto. Estaba ya funcionando el sistema (al menos en una fase inicial), cuando se vio la necesidad, tanto por parte del cliente como de TBS, de conocer aquellas operativas que eran más utilizadas por los usuarios finales de la aplicación, al igual que aquellas que eran menos usadas, más desconocidas o peor utilizadas por los clientes. Así mismo, también era interesante conocer el tiempo que los usuarios de la aplicación tardaban en completar una operativa, y otros datos interesantes relativos al uso de dicha banca electrónica. Para ello, era necesario desarrollar un módulo, ya sea dentro o fuera de la propia aplicación, que obtuviera de algún modo toda esta información requerida, y mostrara a los clientes (no a los usuarios finales, sino a los administradores de la aplicación y a los ejecutivos de la banca) estos datos de una forma gráfica, para su posterior estudio y tomar las medidas oportunas en función de los resultados que se obtuvieran. Con estas necesidades iniciales, se propuso realizar MC-Spy como proyecto fin de carrera. 1.1 MC-Server Pasemos ahora, en primer lugar, a explicar más detalladamente qué es MC-Server y como está estructurado, para entender cómo el desarrollo de MC-Spy ha estado condicionado inicialmente por dichas circunstancias. MC-Server se puede definir, tal y como ya se ha dicho anteriormente, como un sistema de banca electrónica multicanal. Sin embargo, MC-Server es algo más que eso. MCServer es un framework de trabajo para la implementación de operativas online, orientado a la banca virtual, pero adaptable a otros contextos y modelos de negocio. MC-Server ofrece una serie de servicios y facilidades para el desarrollo rápido de operativas, garantizando el rendimiento, escalabilidad y flexibilidad de la solución. Es decir, MC-Server no se limita a ser únicamente el núcleo de una banca electrónica sobre la que implementar operativas, ya que lo que se pretende es adaptarse a cualquier otra solución; no obstante si que es verdad que cuando se propuso hacer este proyecto MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 8 fin de carrera, MC-Server se estaba desarrollando para ponerlo en funcionamiento como una banca electrónica para un banco andorrano. El siguiente gráfico muestra un resumen de los servicios que puede prestar al usuario MC-Server: STFIC W32 Integra local WEB SMS WAP KIOSKOS Banca Telefónica Otros... Cliente SMS PAM HTTP STFIC WAP Business Objects Business Rules e-Marketing MC-Core MC-Server STFIC SERVER Cuentas Transferencias Gestión de ficheros Valores Ticketing Otros... Servidor DAO HOST Figura 1Servicios de MC-Server El framework MC-Server se sustenta sobre las tecnologías más avanzadas en el campo de los entornos servidor J2EE. Comenzado a construirse bajo la plataforma Java 1.3, Enterprise Edition (J2EE), se ha seguido desarrollando e implementando hasta las versiones actuales de J2EE, siguiendo una serie de normas y patrones de diseño, que garantizan la flexibilidad, escalabilidad, disponibilidad e independencia de la plataforma, obteniendo al mismo tiempo un rendimiento excelente del sistema. Este último punto es fundamental y suele ser el punto débil de soluciones y arquitecturas diseñadas por empresas. En la siguiente ilustración se muestra una visión general de la arquitectura técnica del producto, en la cual podemos observar una distribución de componentes en el Servidor Web y las dos partes fundamentales del Servidor de Aplicaciones: Motor de Servlets y Contenedor de EJBs. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 9 JNDI Tree TB·Solutions Portable Framework Home Interface EJB Remote Interface Stateless SessionBean (EJB) Business Logic Layer (Stateless Java classes) Data Access Logic Layer (Stateless Java classes) Helpers (Stateless Java classes) Servlet Engine EJB Container Relational Database Application Server JMS Engine JDBC Datasource XSL Transformer Web Server Page View (XSL) Page View (XSL) Page View (XSL) J2EE Standard Framework Controller (Servlet) HOST Flow Definition XML Flow Definition XML HttpSession Attributes (JavaBeans) Presentation Logic Layer (Stateless Java classes) Page View (XSL) Page View (XSL) Page View (XSL) Figura 2Arquitectura técnica MC-Server MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 10 Para detallar el flujo de una petición de una forma resumida, y simplificando la explicación para favorecer su comprensión, podemos decir que todas las peticiones se dirigen a un solo servlet el cual controla el tipo de petición que llega y decide el proceso de lógica de negocio tiene que ejecutar. Este proceso se comunica con el EJB sin estado (stateless), que ejecutará dentro de una transacción el proceso de lógica de negocio apropiado para esa petición. Este último será el que se comunique con la capa de acceso a datos que es la que se integra con la base de datos o con Host según sea necesario. Finalmente, la respuesta se devuelve al servlet, que decidirá qué transformador utilizar para la respuesta. Las piedras angulares de la arquitectura son el uso del patrón Model-View-Controller junto con la minimización del uso de EJB y limitación del tipo de los mismos, dentro de la plataforma J2EE. 1.2 Situación inicial de partida Como situación inicial, tenemos una aplicación de banca electrónica, con su base de datos particular, y con una arquitectura característica (explicadas anteriormente). MC-Spy se debería de adecuar a todo ello, ya que como se ha explicado, estará integrado dentro de MC-Server, concretamente, en su administración. Todo ello supuso que diversas decisiones técnicas que se podían tomar a la hora de diseñar MC-Spy, vinieran ya impuestas por el ámbito en el cual se iba a implementar. Esto se explicará posteriormente, donde se desarrolla el Análisis del proyecto, en el anexo A de este documento. 1.3 Objetivo final Como objetivo final se plantea conseguir los siguientes objetivos:  Obtener una aplicación que muestre datos fiables y útiles para conocer el funcionamiento real de la banca electrónica. Lo que se pretende es obtener una serie de estadísticas sobre la utilización de la banca, y la obtención de predicciones sobre su evolución en un futuro a corto-medio plazo.  Obtener una aplicación robusta y que no penalice apenas el rendimiento de la banca electrónica.  Obtener una aplicación atractiva y sencilla de utilizar por cualquier empleado de la banca. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 17 3.2 Arquitectura del sistema Pasamos ahora a reseñar brevemente cual es la arquitectura de MC-Spy. Del porqué de esta división y de otros aspectos de su creación se habla más extensamente en el Anexo A, que expone el Análisis. Como ya se ha podido adelantar previamente, MC-Spy está formada por dos módulos principales:  Módulo de recolección de datos  Módulo de Administración y consulta de estadísticas. 3.2.1 Módulo de recolección de datos El módulo de recolección de datos se encarga recoger la información de las operativas ejecutadas en la Aplicación Web monitorizada por MC-Spy y almacenarla en base de datos. En el siguiente diagrama se puede ver el funcionamiento del módulo de recolección de datos. EJB MCSpy Base de Datos Cliente HTTPS JDBC Módulo de recolección de datos EJB Aplicación sobre MC·Server JSP NotificacionQueue Clase Estática Figura 4Modelo de Recolección de datos Los componentes que se ejecutan sobre la plataforma MC-Server (EJB’s, JSP’s, Servlet’s, etc.), cuando deseen registrar información relativa a una operativa de la aplicación, invocarán a una clase estática que encolará la información en una cola JMS, para su posterior almacenamiento en Base de datos. De este modo, la operación del registro de la información es asíncrona y no penaliza en rendimiento a la ejecución de la operativa de la aplicación “anfitrión” que se va a monitorizar. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 18 Para más información sobre estos aspectos, podemos ir al Anexo B donde se explica el diseño de la aplicación. 3.2.2 Módulo de Administración y consulta de estadísticas Este módulo consiste en una aplicación Web que permite a los usuarios administradores del sistema ver la información de los usuarios que han accedido al sistema, conocer el número de operativas que han ejecutado y consultar la estadísticas y previsiones que deseen. En el siguiente diagrama se puede ver el funcionamiento de este módulo de Administración: EJB Módulo de estadísticas JSP JDBC Cliente HTTPS Figura 5Módulo Administración o de Estadísticas El Módulo de Administración consiste en una serie de páginas JSP’s que mostrarán la información de Administración y estadísticas a los usuarios. Para el acceso a la base de datos las páginas JSP de la aplicación invocarán a un EJB. Para un mayor detalle del diseño de este módulo, se recomienda ir al Anexo B de este mismo documento. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 19 4 Desarrollo del proyecto En este capítulo se va a intentar resumir el trabajo realizado en este proyecto fin de carrera de una forma general. La realización de MC-Spy consta de dos fases perfectamente diferenciadas. 1. Una primera fase del proyecto consiste en la realización de una consultoría que proponga modificaciones de la información reflejada en los logs o almacenada en la base de datos de MC-Server, para su posterior explotación mediante MCSpy. Las propuestas que surgen como resultado de este estudio deben tener como objetivo la ampliación y refinamiento de la información histórica almacenada para que la aplicación que se desarrollará en la segunda fase de este proyecto la analice. 2. La segunda fase del proyecto consiste en la creación de una aplicación web que explote la información obtenida en dichas fuentes y generando estadísticas de utilización de las distintas operativas que conforman el sistema de e-banking subyacente. 4.1 Fases del desarrollo El desarrollo se ha dividido en varios puntos, para ir marcando hitos en su realización. Todo el proceso de trabajo y la forma de realizarlo se explica brevemente en los siguientes puntos. 4.1.1 Fase inicial de estudio  Investigación y estudio a fondo de MC-Server: Para poder integrar MC-Spy dentro del módulo de la Administración de MC-Server, hay que investigar como se ha desarrollado MC-Server (aplicación “anfitrión”), cuál es su arquitectura, como se define su base de datos u otros sistemas de almacenamiento de información, y otros datos referentes a su estructura y funcionamiento.  Consultoría: Se estudian las posibles implicaciones que suponen la integración de MC-Spy dentro de MC-Server, teniendo en cuenta las graves consecuencias que puede tener el hecho de realizar algún cambio no oportuno para el funcionamiento correcto de la banca electrónica.  Estudio teórico sobre las series de tiempo: La realización de previsiones basadas en series de tiempo, requieren que se realice un estudio relativamente detallado sobre éstas, concretamente sobre las relacionadas con la economía, como es este caso. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 20  Análisis: Se realiza el análisis técnico de la solución, que se incluye en los anexos a este mismo documento. 4.1.2 Fase de desarrollo  Cambios en MC-Server: Realización de las modificaciones surgidas en el estudio de los puntos anteriores(al menos las referidas a la base de datos).  Diseño de las páginas de la Administración: Se diseñan las pantallas sobre las que se mostrarán las gráficas, las que soliciten datos al usuario, además de los menús por los que se accederá a todas estas páginas.  Diseño e implementación del sistema de recolección de datos: Se decide el sistema que se usaría para recoger la información de las operativas ejecutadas en la Aplicación Web monitorizada por MC-Spy y almacenarla en base de datos. Ésta es la segunda parte de los cambios que habría que realizar en MC-Server para su integración con MC-Spy (después de los realizados en la base de datos). Se trata en primer lugar de estudiar en qué punto del código se realizan cada una de las operativas que queremos monitorizar, para posteriormente, realizar los cambios oportunos y necesarios en el código.  Implementación del sistema de almacenamiento de datos: Para conservar toda la información en la base de datos de lo que los usuarios operan en la banca electrónica, se decidió implementar un sistema de colas, en el cual la aplicación fuera dejando los datos, y ésta fuera insertándolos en la base de datos asíncronamente.  Implementación de un árbol dinámico: Desarrollo de un árbol mediante javascript y html dinámico, para mostrar los datos que se requieren en el módulo del Árbol de usuarios.  Implementación de la operativa del Árbol de sesiones: Se crean e implementan todas las clases necesarias para este módulo, tanto para acceder a la base de datos para ir a buscar la información, tanto como para tratar dichos datos y pasárselos al jsp para mostrarlos. También se desarrollan estos jsp, los cuales son los encargados de recoger los parámetros de búsqueda y a su vez mostrar la información requerida por el usuario.  Pruebas exhaustivas del Árbol de sesiones: aunque tras cada pequeño avance se probaba la aplicación, en este punto se realiza un exhaustivo plan de pruebas al Árbol de usuarios, donde se corrigen algunos puntos surgidos en esta fase.  Implementación de la operativa de Estadísticas: Se desarrollan las clases necesarias para este módulo, al igual que los jsp que muestran, ya sea de forma gráfica o en modo texto, la información sobre el uso de las operativas de la banca. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 21  Pruebas exhaustivas de las Estadísticas: Se prueban concienzudamente todas las gráficas y estadísticas que se ofrecen en este módulo, para comprobar su correcto funcionamiento, sobre todo la validez de sus datos.  Implementación de los algoritmos para las previsiones: Se codifican los algoritmos que se eligieron en el estudio previo, para realizar las previsiones de las series de tiempo.  Implementación de las Previsiones: Aunque está muy relacionado con el módulo anterior, ya que las previsiones también se muestran en forma de estadística, esta parte de desarrolla una vez terminada la fase anterior, para establecer una mayor independencia entre ellos.  Pruebas exhaustivas de las Previsiones: Se realizan continuas pruebas mientras dura el desarrollo de esta parte, comparando los resultados obtenidos mediante los algoritmos codificados, y los que deberían haber salido mediante los algoritmos teóricos. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 22 5 Modelo incremental Tal y como se ha visto en al apartado anterior, el desarrollo se ha dividido en varios sub-desarrollos. Esto implica que algunos de ellos necesitaran que el desarrollo anterior estuviera plenamente operativo. Debido a esto, se ha seguido un modelo incremental ya que de esta forma los desarrollos posteriores podían implementarse con la seguridad de que las funcionalidades que necesitan eran correctas. Además, de esta forma se pudo seguir trabajando con nuevos módulos mientras se validaban los módulos implementados. En la siguiente figura se muestra el esquema del modelo incremental: Figura 6Modelo Incremental Requerimientos Verificación Especificación Verificación Planificación Verificación Diseño Arquitectural Verificación En cada módulo: - Diseño - Implementación - Integración - Test - Validación Modo Operacional MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 23 6 Gestión del proyecto En este apartado se explican las labores de gestión del proyecto que no están directamente relacionadas con el desarrollo del mismo, pero que son necesarias para conseguir el objetivo final. 6.1 Gestión de riesgos Detectar de forma temprana los riesgos que puedan aparecer en el desarrollo del proyecto, contribuye a una mejor planificación del mismo. Los principales riesgos detectados, y las acciones necesarias para superarlos son los siguientes:  Dependencia de aplicaciones existentes: ya que el desarrollo debe integrarse con unos módulos existentes, antes de comenzar el desarrollo de las nuevas funcionalidades debe conocerse a fondo estas aplicaciones; ya que empezar a realizar los nuevos componentes sin conocer la aplicación donde deben integrarse es una forma segura de tener que repetir los avances realizados.  Aplicaciones en desarrollo: las aplicaciones en las que se integra el proyecto no están cerradas, sino que avanzan de versión continuamente. Debe ser necesario planificar un tiempo para integrar los nuevos desarrollos con las nuevas versiones. El tiempo necesario para realizar estas integraciones puede minimizarse si el proyecto se realiza de la forma más independiente posible de la aplicación existente.  Falta de experiencia: debido a que este desarrollo es un proyecto fin de carrera, el proyectando no posee una gran experiencia en la realización de proyectos de esta envergadura. No hay solución fácil para este riesgo, simplemente participar en más desarrollos y dejarse aconsejar por gente con más experiencia.  Desconocimiento de algunos temas que se tratan: asuntos como por ejemplo las previsiones de series de tiempo, son temas que el proyectando, a pesar de haber estudiado alguna asignatura relacionada con la estadística, no domina, con lo cual, es necesario realizar una tarea de estudio previa. Esto puede ser un cuello de botella si los conocimientos necesarios para desarrollar la implementación no se consiguen en los plazos previstos. Por tanto, no se asignan unos tiempos determinados para realizar labores de investigación. Todos sabemos lo complicado que resulta a veces encontrar lo que se busca.  Simultaneidad con otros proyectos: también es digno de mencionar un hecho que puede ser considerado como un riesgo para la elaboración del proyecto, y es que a la vez que se realizaba este proyecto, el autor del mismo estaba trabajando en otros proyectos, siempre en la misma empresa. Como se podrá observar en el MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 24 apartado siguiente, durante el ciclo de vida del proyecto ha habido varios huecos en los que por motivos laborales el autor no pudo dedicarse a las labores de desarrollo, lo cual es el motivo principal del retraso en la fecha estimada inicialmente para la finalización del proyecto. 6.2 Plazos del proyecto Ver gráfico a continuación. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 26 7 Conclusiones 7.1 Cumplimiento de objetivos Una vez finalizado este proyecto fin de carrera se puede afirmar el cumplimiento global de los objetivos que se propusieron en sus inicios. Si se repasan dichos objetivos que se plantearon en un principio para este proyecto, podemos decir con toda seguridad que el cumplimiento es total, y el grado de satisfacción de la calidad obtenida, tanto por parte de TB-Solutions, como por parte de los clientes receptores (que por lo tanto, usan la aplicación), es máxima. Únicamente, si miramos uno a uno los requisitos que se enumeraron en el punto 2 de este documento, podríamos decir que el único punto de todos ellos que no se ha realizado es el que se refiere a la realización de un visualizador de ficheros de traza. Pero ya se indicó en su momento (al inicio del proyecto, y así se indica también en dicho punto de este documento), que este punto quizá estuviera fuera del proyecto, y solamente se realizaría en el caso de que los tiempos de finalización del resto de la aplicación se hubiesen cumplido con creces. 7.2 Extensiones no previstas en los objetivos iniciales En este punto quisiera agradecer a los jefes de proyecto de MC-Server que no incluyeran durante el desarrollo de este PFC ningún añadido a lo que inicialmente se propuso por parte de ellos. Este hecho facilitó la realización y su conclusión, al no verse interrumpido por nuevas solicitudes que hubiera que habido que estudiar e integrar, con las consecuentes penalizaciones de tiempo. Si acaso, reseñar el hecho de que una vez en fase de estudio (es decir, nada más comenzar el proyecto), se sugirió que la aplicación debería ser lo más portable posible, para poder ser utilizada no sólo en MC-Server, como era la proposición inicial, sino en cualquier otra aplicación web que se desarrollara en la empresa. Dicho esto, es justo decir que la sugerencia se hizo a tiempo, además de que desde un primer momento ya se intentó que este objetivo se consiguiera. 7.3 Implantación de MC-Spy en sistemas reales Actualmente MC-Spy está siendo usado como un módulo más en los siguientes entornos reales:  MC-Server para Banca Mora.  YAFAR(Sistema de gestión de tributos) para la DGA.  YAFAR para la Junta de Andalucía. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 33 A.1.2.5 Información En este aspecto nos referimos a la posibilidad de que con alguna de las dos opciones se pueda dar el caso de que alguno de los datos que se pretenden conservar para su posterior extracción, no pudieran ser guardados por algún motivo. Sin embargo no apreciamos motivo alguno para que este aspecto pueda llegar a ser un problema, ya que no observamos ninguna razón para que ni los ficheros de log ni la base de datos impidan la conservación de algún tipo de dato. Con todas estas conclusiones parciales obtenidas, se decidió que la opción que más ventajas ofrecía para la correcta obtención de los datos era la de la utilización de la base de datos. La elección del sistema gestor de base datos a elegir estaba claro ya que MCServer utilizaba Oracle, aunque el sistema a usar no debería de ser un problema (por supuesta fuera de la definición de las tablas en sí, pero no así en su utilización), ya que MC-Spy debería ser lo más portable posible, y debería permitir el uso de otros sistemas gestores. A.1.2 Composición del sistema Siguiendo las restricciones y los requerimientos impuestos, todos ellos comentados ya anteriormente, podemos ya realizar el análisis del proyecto, dividiéndolo en varias líneas de proyecto que en conjunción completarían lo que sería MC-Spy.  Recolección de datos  Consulta de estadísticas  Árbol de sesiones  Previsiones A.1.2.1 Recolección de datos El módulo de recolección de datos será el encargado de recolectar toda la información necesaria, y almacenarla en la base de datos para su posterior recolección por parte de los otros módulos. Para realizar todo esto, es necesario modificar el código del proyecto en el cual se integre MC-Spy, es decir, para el cual se pretende obtener información a través de sus estadísticas. El porqué de la necesidad de la modificación del código del proyecto padre está claro, solamente desde allí se podrá saber qué operativa se ha ejecutado, además de otros datos como por ejemplo cuando, quien y con qué objetivo y final se ha realizado. Cualquier otra forma de querer obtener esta información sería mucho más complicada e innecesaria. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 34 Habrá pues que identificar los puntos del código donde será necesario insertar las llamadas oportunas (explicadas posteriormente en el Diseño, Anexo B). Para ello es necesario estudiar con cierto detalle la implementación de dicho proyecto, ya que es imprescindible acertar con esta ubicación, ya que de ello depende que con posterioridad los datos que muestren las estadísticas de MC-Spy, sean datos fiables y se refieran a información verídica. Por supuesto, el lugar donde se va a almacenar toda esta información, va a ser en base de datos. Como se prevé que el número de inserciones puede ser alto (este número dependerá de los usuarios simultáneos que haya en la banca, o en cualquier otro sistema donde esté integrado MC-Spy, en un momento dado), habrá que diseñar algún modo de realizar las inserciones sin que por ello se penalice el funcionamiento normal del resto de la aplicación. A.1.2.2 Consulta de estadísticas Este módulo será el encargado de mostrar a los administradores de la banca, los datos que necesiten para comprobar su correcto funcionamiento, o para argumentar posibles decisiones sobre su uso por parte de los usuarios. El módulo será básicamente una aplicación web, la cual, mediante la solicitud de una serie de datos que se le pedirán al usuario, mostrará unas gráficas y unos datos, para lo cual utilizará la información previamente almacenada por el módulo de Recolección de datos. En este punto es interesante resaltar que también se hizo un análisis de cuáles eran las estadísticas que se iban a tener que mostrar en la aplicación. Para ello nos pusimos en la piel de un administrador de una banca electrónica, el cual tenía que poder demostrar a sus superiores cualquier hecho que se produzca en ella, así como presentarles informes regulares sobre su uso por parte de los clientes. Es por ello por lo que se realizó un listado de todas las estadísticas que resultaría interesante que MC-Spy tratase, el cual mostramos a continuación:  Número y detalle de los establecimientos de sesión (entradas a la banca) en un periodo de tiempo:  Por un cliente.  Desde una IP. ***  Desde un región, país... ***  Número y detalle de consultas de saldo realizadas en un intervalo de tiempo:  Por un cliente.  Sobre una determinada cuenta.  Por una modalidad.  Número y detalle de consultas de movimientos realizadas en un intervalo de tiempo:  Por un cliente. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 35  Sobre una determinada cuenta.  Intervalo de tiempo medio por el que se realizan consultas de movimientos.  Número y detalle de consultas de valores realizadas en un intervalo de tiempo:  Por un cliente.  Sobre una determinada cuenta.  Número y detalle de traspasos entre cuentas propias realizados en un intervalo de tiempo:  Por un cliente.  Desde una determinada cuenta.  Teniendo como destino una determinada cuenta.  Con un importe máximo.  Con un importe mínimo.  Importe medio en los traspasos entre cuentas propias.  Número y detalle de cambios de moneda en un intervalo de tiempo:  Por un cliente.  Desde una determinada cuenta.  Teniendo como destino una determinada cuenta.  Con un importe máximo.  Con un importe mínimo.  Importe medio en los cambios de moneda realizados en un intervalo de tiempo.  Número y detalle de traspasos a cuentas ajenas realizadas en un intervalo de tiempo:  Por un cliente.  Desde una determinada cuenta.  Teniendo como destino una determinada cuenta.  Con un importe máximo.  Con un importe mínimo.  Importe medio en los traspasos a cuentas ajenas realizados en un intervalo de tiempo.  Número y detalle de transferencias realizadas en un intervalo de tiempo:  Por un cliente.  Desde una determinada cuenta.  Teniendo como destino una determinada cuenta.  Con un importe máximo.  Con un importe mínimo. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 36  Importe medio en las transferencias realizadas en un intervalo de tiempo.  Número y detalle de consultas de traspasos y transferencias realizadas en un intervalo de tiempo:  Por un cliente.  Número y detalle de las consultas de detalles de traspasos y transferencias realizadas en un intervalo de tiempo:  Por un cliente.  Número y detalle de consultas de información general realizadas en un intervalo de tiempo:  Por un cliente.  Número y detalle de los créditos documentarios realizados en un periodo de tiempo:  Por un cliente.  Por una cuenta.  Por importe máximo.  Por importe mínimo.  Importe medio en los créditos documentarios realizados en un intervalo de tiempo.  Número y detalle de las asignaciones de referencias realizadas en un periodo de tiempo:  Por un cliente.  Número y detalle de los cambios de clave de acceso realizadas en un periodo de tiempo:  Por un cliente.  Número y detalle de los cambios de clave de acceso realizadas en un periodo de tiempo:  Por un cliente.  Número y detalle de los mensajes enviados a la entidad en un periodo de tiempo:  Por un cliente.  Para un destinatario concreto.  Número y detalle de los riesgos de cedentes (totales y en detalle) consultados en un intervalo de tiempo:  Por un cliente.  Por una cuenta.  Número y detalle de las consultas de efectos en un intervalo de tiempo:  Por un cliente. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 37  Por una cuenta.  Número y detalle de consultas de ficheros realizadas en un intervalo de tiempo:  Por un cliente.  Número y detalle de las consultas de detalles de ficheros realizadas en un intervalo de tiempo:  Por un cliente.  Número y detalle de las personalizaciones del perfil de usuario realizadas en un periodo de tiempo:  Por un cliente.  Número y detalle de las firmas realizadas sobre una transferencia en un periodo de tiempo:  Por un cliente.  Número y detalle de las firmas realizadas sobre un fichero en un periodo de tiempo:  Por un cliente.  Número y detalle de los borrados de firmas realizados sobre una transferencia en un periodo de tiempo:  Por un cliente.  Número y detalle de los borrados de firmas realizados sobre un fichero en un periodo de tiempo:  Por un cliente.  Número y detalle de las recepciones realizadas por la banca en un periodo de tiempo:  De un cliente.  Número y detalle de las ayudas consultadas en un periodo de tiempo:  Por un cliente.  Cantidad de dinero movido en la banca en un periodo de tiempo.  Tiempos medios de ejecución de cada operativa.  Gráfico indicando los porcentajes de qué operativas ejecutan más los clientes.  Gráfico detallando los porcentajes de cada una de las modalidades de consultas de saldo.  Gráfico con los intervalos mas utilizados en las consultas de movimientos.  Gráfico con los intervalos de importes realizados en los traspasos entre cuentas propias.  Gráfico con las monedas con las que se hacen los traspasos entre cuentas propias.  Gráfico con los intervalos de importes realizados en los cambios de moneda. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 38  Gráfico con las monedas con las que se hacen los cambios de moneda.  Gráfico con los intervalos de importes realizados en los traspasos a cuentas ajenas.  Gráfico con las monedas con las que se hacen los traspasos a cuentas ajenas.  Gráfico con los intervalos de importes realizados en las transferencias.  Gráfico con las monedas con las que se hacen las transferencias.  Gráfico comparativo entre varios meses de la cantidad de dinero movido en transferencias y traspasos.  Gráficos con la procedencia de los accesos a la banca (IP´s, países,...).  Gráfico con el número de visitas por día en el último mes(o semana,...).  Gráfico con el número de visitas que hace un cliente en un día, una semana, ...  Gráfico de la actividad de la banca en los distintos días de la semana.  Gráfico de la actividad de la banca en las distintas horas del día.  Gráfico con el número de operativas realizadas por cliente en una sesión.  Gráfico con las operativas que han dado error al ejecutarse.  Gráfico comparativo con los tiempos medios de ejecución de cada una de las operativas.  Gráfico comparativo del dinero movido en la banca en dos periodos de tiempo. De todas formas, el diseño de la aplicación se realizará de tal forma, que este listado dependerá exclusivamente del cliente, y de la información que los administradores de la banca consideren necesario que hay que mostrar. A.1.2.3 Árbol de sesiones Este módulo será el encargado de mostrar la información relativa a la actividad generada por un usuario a lo largo de una sesión en la banca electrónica. Por medio de un árbol que mostrará gráficamente la información requerida, se podrá seguir fácilmente todo el recorrido que el cliente haya hecho a través de la aplicación bancaria, conociendo si en alguna operación ha ocurrido algún error, y en el caso de que así sea, cual ha podido ser el motivo de dicho fallo. Para ello habrá que dotar al modelo de algún sistema que establezca el nexo entre todas las operativas que ejecuta un usuario, para que después, mediante la aplicación gráfica, poder unirlas, asociándolas al mismo usuario y a la misma sesión abierta en la banca por él. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 39 A.1.2.3 Previsiones Este módulo va muy íntimamente ligado al de Consulta de estadísticas, ya que el funcionamiento es muy similar al de Consulta de estadísticas, y aunque en este punto de la construcción del proyecto podría haberse integrado perfectamente en el módulo citado, ya prevemos que las previsiones van a requerir un tratamiento muy distinto al de las estadísticas normales, sobre todo a la hora del procesado de los datos. El sistema gráfico de las previsiones es semejante al de las estadísticas, ya que se mostrarán en gráficas (y en forma de texto si así se cree conveniente), distintas previsiones de cómo se cree que van a comportarse los datos para un plazo medio-corto. Como decimos, ahora quizá no se vea aun la distinción, pero en posteriores estudios se verá su necesidad. A.1.3 Casos de uso Dentro de la aplicación MC-Spy identificamos una serie de Casos de Uso que describen las posibles interacciones del usuario con el sistema. Para la descripción de estos casos de uso se ha utilizado UML. A.1.3.1 Uso de una operativa de la banca electrónica Se trata de la operación que llevará a cabo un usuario de la banca electrónica cuando realice cualquier operativa dentro de la banca electrónica, desde hacer login, hasta desconectarse de ella, pasando por envió de transferencias, consulta de saldos o cualquier otra acción que la banca permita a un cliente. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 40 Figura 7Caso de uso de una operativa en la banca Todas estas acciones, tengan el resultado que tengan, quedarán registradas en la base de datos. CASO DE USO Realizar una transferencia en la banca electrónica Objetivo Realizar un traspaso de dinero entre 2 cuentas, ya sean propias, de la misma o de otra entidad Precondiciones Haberse logado dentro de la banca electrónica. Tener alguna cuenta desde la que poder hacer el traspaso, y que tenga saldo suficiente. Condición de fin con éxito Se añade una orden de transferencia, para que el proceso batch de la banca lo ejecute cuando corresponda. Condición de fin erróneo No se realiza la transferencia Actores principales Usuario Actores secundarios Ninguno Disparador Petición del usuario DESCRIPCIÓN Paso Acción 1 El usuario accede al módulo de transferencias dentro de la banca MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 41 2 El sistema muestra sus cuentas disponibles 3 El usuario elige la cuenta, la cantidad y demás datos necesarios para completarla. 4 El usuario clicka en el icono de ejecutar 5 El sistema añade la orden con la transferencia 6 El sistema muestra un resumen con la transferencia realizada por el usuario A continuación se muestra el diagrama de secuencia asociado a este caso de uso, en concreto de una operación de transferencia, para mostrar un ejemplo de una operativa medianamente completa, y mostrar que la banca se comunica con MC-Spy, pero no al revés: Figura 8Diagrama de secuencia de una transferencia Como se puede ver en esta secuencia, el registro de operaciones en MC-Spy es totalmente transparente para el usuario, ya que el usuario no se apercibe que se MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 42 producen dichos registros de sus acciones, siendo consciente únicamente de su comunicación con la banca. A.1.3.2 Consulta de una estadística En este caso se trata de la operación que llevará a cabo un administrador de la banca electrónica, cuando desee consultar algún dato referente a su uso por parte de los clientes. Figura 9Caso de uso Consulta estadística CASO DE USO Realizar una consulta de una estadística en MC-Spy Objetivo Consultar datos sobre alguna de las posibles estadísticas que MC-Spy ofrece a los administradores Precondiciones Haberse logado dentro de MC-Spy. Condición de fin con éxito Se muestra un gráfico, o una serie de datos con la estadística seleccionada Condición de fin erróneo No se mostrará nada. Actores principales Administrador Actores secundarios Ninguno Disparador Petición del administrador DESCRIPCIÓN Paso Acción 1 El administrador accede al módulo de estadísticas dentro de MC-Spy 2 El sistema muestra las estadísticas disponibles 3 El administrador elige los datos necesarios MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 49  El Modelo Funcional, que muestra en el ámbito conceptual las distintas funcionalidades disponibles para el usuario final y las relaciones ( o usos) existentes entre ellas. B1.1.1 Modelo lógico de subsistemas La identificación de cada subsistema, su distribución y las relaciones existentes con el resto de subsistemas resultó bastante clara y sencilla desde el primer momento en que se planteó. Como puede verse en el siguiente gráfico, MC-Spy consta de dos subsistemas. Cada una de las instancias que se ejecutan de cada subsistema está pensada para ejecutarse en un nodo, aunque debería darse la posibilidad de que en un mismo nodo se ejecuten varios procesos distintos. Los dos subsistemas identificados son los siguientes:  Recolector de datos, que se encarga de recoger la información de las operativas ejecutadas en la Aplicación Web monitorizada por MC-Spy y almacenarla en base de datos.  Cliente de consultas, que es el proceso que ejecutan los usuarios del sistema –los administradores de la banca-. El cliente accederá a los datos que previamente ha almacenado el recolector. Esta distribución de procesos se modela de forma general en la siguiente ilustración, en la cual se ha puesto como ejemplo un sistema integrado por tres usuarios que van a utilizar el recolector de datos a través de MC-Server, y dos administradores que acceden para consultar los datos. Figura 15Modelo lógico MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 50 Tal y como se deduce del Análisis de Requisitos, y como muestra en la ilustración anterior, el sistema que se está diseñando será utilizado por los administradores, los cuales utilizarán el Cliente de consultas para acceder a la información almacenada en el sistema. B1.1.2 Modelo lógico de módulos de los subsistemas Como puede observarse en el modelo de la ilustración que a continuación se muestra, los dos subsistemas han sido diseñados de tal forma que tienen los dos un módulo de acceso a base de datos, aunque las semejanzas entre ellos allí se acaban. Como se puede apreciar, se han identificado dos actores distintos que pueden usar el sistema:  Usuario de MC-Server. Es el usuario de la banca electrónica, que genera información que se almacenará en la base de datos.  Administrador de la banca electrónica. Es quien va a consumir dichos datos, a través de las peticiones al módulo de interfaz gráfica del Cliente de consultas. En el subsistema Recolector de datos se han identificado los siguientes módulos, desde el punto de vista horizontal:  Módulo de acceso a base de datos. En este caso se trata de la inserción de los datos.  Módulo de gestión temporal de datos. Se encargará de gestionar la inserción en la base de datos de forma que no cause perjuicio en el resto de la aplicación. De este modo se colabora a garantizar el requisito de fiabilidad y estabilidad.  Módulo de integración con MC-Server: Es el módulo usado para conectarse con MC-Server y encargarse de recibir toda la información que este le facilite. Figura 16Subsistema Recolector de datos MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 51 El subsistema Cliente de consultas, se encarga de mostrar de forma gráfica toda la información almacenada por el subsistema anterior, por supuesto organizada toda ella según peticiones de los usuarios. En este subsistema se han identificado los siguientes módulos, desde el punto de vista horizontal:  Módulo de acceso a base de datos. Es el módulo usado para conseguir toda la información que soliciten los usuarios.  Módulo de interfaz gráfica. Es el módulo usado por los administradores de la banca (ellos serán generalmente los usuarios de la aplicación), y que se encarga de interactuar con el módulo de acceso a base de datos. Este módulo, como su propio nombre indica, presenta de una forma visual la información solicitada. Figura 17Subsistema Cliente de consultas B.1.2 Diseño físico del sistema El Diseño Físico consiste en una especificación detallada del sistema resultante del Diseño Lógico, teniendo en cuenta el lenguaje de programación y las bibliotecas que se van a utilizar para el acceso a datos. Como se especifica en el capítulo 2.2 Requisitos no funcionales, el proyecto está desarrollado utilizando Java (JDK 1.3, 1.5,…) como lenguaje de programación y Oracle como gestor de base de datos. La generación de estos modelos físicos del sistema es simple, ya que se trata de una evolución de los modelos lógicos horizontales del sistema presentados en apartados anteriores. Para cada uno de los módulos de los subsistemas identificados, se ha especificado una clase principal. Cada una de estas clases está asociada con otras clases principales MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 52 siguiendo los usos entre casos especificados en los diagramas anteriores de Casos de Uso de los que evoluciona este diagrama de clases. B.1.2.1 Modelo físico general del sistema El modelo físico inicial se muestra en la siguiente ilustración. Este modelo no presenta ningún detalle adicional del sistema. Como se ha introducido antes, cada una de las clases que aparecen en este diagrama es la clase principal de cada uno de los módulos identificados para cada subsistema. La especificación detallada de los métodos de estas clases no aparece en este modelo, ya que aún no han sido definidos en este punto del diseño físico. Tampoco se especifican el resto de las clases utilizadas en cada uno de los módulos –clases auxiliaresni las relaciones existentes entre ellas. Como puede observarse en la imagen, se nombra para cada uno de los módulos una clase que se podría llamar como “principal” o localizadora. En algunos casos no es posible identificar a una sola clase para tal fin, con lo que se nombra el paquete en el cual residen las clases que cometen dicha labor. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 53 Figura 18Modelo físico El sistema está dividido en dos subsistemas, los cuales representan procesos independientes:  Por un lado tenemos el subsistema Recolector de datos, que se encarga de interaccionar con MC-Server y recoger los datos que esté le facilita para su posterior uso.  Finalmente tenemos el subsistema de Cliente de consultas que se encarga de interrogar al sistema para obtener la información que se le solicite. Cada uno de estos subsistemas será descrito en los puntos siguientes de este mismo apartado. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 54 B.1.2.1.1 Subsistema Recolector de datos El subsistema Recolector de Datos está compuesto por tres clases o paquetes principales, cada una de ellas equivalente a un módulo del diagrama de casos de uso que se muestra anteriormente. Figura 19Subsistema recolector de datos La clase LogEntryQueue (además de otras clases auxiliares que ésta utiliza) es la encargada de implementar el sistema de gestión de recepción de información desde MCServer y su priorización y ordenamiento para su posterior almacenamiento en base de datos. El paquete de Acceso a BD se encargará precisamente de este almacenamiento en la base de datos. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 55 La clase SessionJBean centralizará la comunicación directa con MC-Server, recibiendo de este sistema todas sus invocaciones, las cuales contienen la información a almacenar en la base de datos. B.1.2.1.2 Subsistema Cliente de consultas Al ser el subsistema del Cliente de consultas una aplicación web, el modelo físico y sus subsistemas se pueden identificar con cada uno de los componentes del patrón ModelView-Controller, que como ya se ha dicho anteriormente en este documento, es el que se iba a utilizar para la implementación de este PFC. Así pues, vamos en un primer lugar a explicar brevemente la filosofía de este patrón. B1.2.1.1.1 Patrón Model-View-Controller El patrón Model-View-Controller (MVC ó Model 2) merece un especial interés puesto que se trata de una pieza clave en la arquitectura física de la aplicación, por lo que se describirá brevemente a continuación. El siguiente esquema muestra los componentes básicos del patrón MVC que se ha aplicado a la arquitectura propuesta para el sistema: Figura 20Esquema patrón MVC MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 56 La filosofía MVC consiste básicamente en separar claramente estos tres conceptos:  Model: equivalente a los niveles de lógica de negocio y acceso a datos. En este nivel se implementa el acceso y modificación de datos de negocio. Como se ha introducido anteriormente, se unifican físicamente estas dos capas, aunque a nivel lógico continúen perfectamente delimitadas las responsabilidades de cada una de ellas.  View: equivalente al nivel de presentación. Se implementa siempre en un entorno web a través de JSP o de XSL. Nunca podrá un servlet enviar información de presentación al navegador de forma directa; únicamente podrá hacerlo a través de un JSP o de una plantilla XSL (que transforma la información XML).  Controller: equivalente al nivel de control. Se implementa siempre a través de un servlet o un conjunto de servlets. Un controlador recibe una petición desde el cliente, invoca a la lógica de negocio y elige un view (JSP) apropiado para que éste realice el formateo de la información que será presentada al cliente. El servlet utiliza uno o varios JavaBean (JBean), que serán los encargados de interactuar con los componentes de negocio (EJB) siguiendo así el patrón de diseño “Command”. El uso del patrón MVC dentro de una arquitectura J2EE, y usando (pero no abusando) componentes EJB, garantiza la flexibilidad del sistema y la interacción con múltiples actores, tanto en lo que se refiere a los clientes del sistema (navegador, móvil, PDA, o extranets para su sindicación) como en lo que se refiere a los interfaces de interacción con las distintas fuentes de datos actuales o futuras. Una vez explicado el sistema del Model-View-Controller, pasamos a explicar cada uno de las clases o paquetes principales que conforman el subsistema que estamos explicando: MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 57 Figura 21Subsistema Cliente de consultas El paquete de la interfaz gráfica contendrá los jsps encargados de mostrar gráficamente al usuario la información solicitada a través del navegador. La clase ControllerServlet será la que gestione tanto el flujo desde el navegador hacia la parte Model, como la inversa, es decir, decidirá el jsp a mostrar según la acción que se haya ejecutado. El paquete de Acceso a BD se encargará precisamente de las búsquedas en la base de datos. B.1.3 Diseño de los orígenes de datos (BD) En este apartado se va a detallar cual va a ser el origen de toda la información que MCSpy va a poder mostrar, y cómo la va a almacenar. Como se verá a continuación, el principal método será a través de base de datos. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 58 Se adoptan los siguientes acuerdos de nomenclatura para tener en cuanta a lo largo del presente documento:  El nombre de una tabla se especificará entre corchetes: [nombre_tabla]  Aquellos campos que sean clave de la tabla, se marcarán con un subrayado: Campo_PK B.1.3.1 Diseño lógico de MCSpy BD El modelo lógico de la base de datos de MC-Spy se ha realizado mediante un modelo Entidad-Relación. Este modelo es una representación lógica de las entidades existentes en modelo de datos, y las relaciones existentes entre ellas. Este modelo representa un esquema conceptual (es decir, es un modelo lógico) de la información que desea almacenarse en la base de datos. A partir de estos conceptos se realizará la decisión física de la metodología que va a utilizarse – bien relacional o bien orientada a objetos-. La utilización del modelo ER retrasa la elección entre un modelo relacional o un modelo orientado a objetos, ya que a partir de un MER puede inferirse cualquiera de las dos metodologías, en función de las necesidades o restricciones existentes en el sistema en desarrollo. Después de esta primera introducción, veamos en la siguiente ilustración el esquema entidad-relación definido para MC-Spy. Como puede observarse en la ilustración, nos encontramos ante un esquema simple en el que las entidades están perfectamente definidas y el descubrimiento de las relaciones existentes entre ellas resulta simple. El modelo que parece en la mencionada imagen ha sido realizado a partir de la descripción funcional realizada en el Análisis de Requisitos. Las entidades que forman la columna vertebral del esquema son dos: Item_Informacion y Estadística, mientras que el resto de entidades representan información auxiliar y necesaria según los requisitos. Una breve explicación de las entidades:  Item_Informacion: Representa una acción que realiza cada uno de los usuarios que accede a la banca electrónica. Cada operativa que ejecute, quedará registrada como una entrada en esta entidad. Sus atributos serán: usuario, fecha, estado,…  Usuario: Cada uno de los usuarios de la banca.  Estadística: Representa cada una de las estadísticas que la aplicación podrá mostrar. Sus atributos podrán ser su nombre, el tipo, la leyenda a mostrar,… Las relaciones que aparecen en el modelo lógico son muy sencillas, puesto que representan asociaciones reales entre las entidades. En la fase de diseño físico se puede MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 65 B.1.3.3 Diseño físico de la base de datos Partiendo de las tablas que acabamos de obtener, el paso para obtener el diseño físico de la base de datos es simple. Tenemos que adecuar dichas tablas a clases, y organizar el flujo de información entre ellas. Las clases e interfaces que van a presentarse a continuación conforman tanto el gestor de la base de datos, como la base de datos propiamente dicha, puesto que se trata de una base de datos orientada a objetos. De este modo, en las propias clases están definidos tanto los datos y estructuras que se almacenan, como la lógica de negocio referente a cada clase (permisos, actualizaciones en cascada, etc.). El esquema que representa dicha organización es el siguiente: Figura 22Diseño físico BD Vamos a explicar a continuación la lista de clases e interfaces que conforman este módulo.  El interfaz ResultInformation será un interfaz el cual tendrá que ser implementado por todas aquellas clases que necesiten devolver un ResultInfo, como es el caso. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 66  La clase InfoAccessor, implementa como hemos dicho el interfaz ResultInformation, y almacena la información de la instancia de un solo elemento, con el añadido de que esta clase ofrece métodos para convertir sus datos a xml, a String, a CSV, a Array.  La clase InfoSetAccessorPlus, implementa también el interfaz ResultInformation, y almacena varias instancias de InfoAccesor. A su vez, ofrece funcionalidades añadidas, como la ordenación de estos elementos por alguno de sus campos.  La clase LogEntryInfo, extiende de InfoAccessor, y contiene la información de una fila de la tabla [LOG_ENTRY]. Es decir, contiene información sobre una acción realizada por un usuario en la banca.  La clase McUserInfo, extiende de InfoAccessor, y contiene información de una fila de la tabla [MCUSER]. Es decir, contiene información sobre un usuario de la banca.  La clase OperativeInfo, extiende de InfoAccessor, y contiene información de una fila de la tabla [OPERATIVE]. Es decir, contiene información sobre una posible estadística que debe mostrar MC-Spy.  La clase LogEntryInfoSet, extiende de InfoSetAccessorPlus, y contendrá varias instancias de la clase LogEntryInfo.  La clase McUserInfoSet, extiende de InfoSetAccessorPlus, y contendrá varias instancias de la clase McUserInfo.  La clase OperativeInfoSet, extiende de InfoSetAccessorPlus, y contendrá varias instancias de la clase OperativeInfo. B.1.3.4 Principales decisiones en el diseño de la BD  Lo primero que se tuvo que tener en cuenta a la hora de diseñar la base de datos es, por supuesto, que se pudiera conservar la máxima información posible, para que la muestra posterior de datos pudiera ser lo más representativa posible. Para ello, en un primer lugar, se dudó entre crear una sola tabla que albergara toda la información, o crear varias tablas, concretamente una para cada una de las posibles operativas que pudiera ejecutar el usuario en la banca electrónica. Se optó por la primera opción, principalmente por dos razones: porque el número de operativas puede ser relativamente grande, y porque en el caso de ampliar su número, no habría que hacer grandes cambios en la base de datos.  Una vez decidido esto, el gran inconveniente con el que nos encontramos fue la enorme cantidad de información que hay que guardar, y en la diversidad de dicha información, según sea de una operativa u otra. Para el problema de la cantidad de datos, no hay solución sencilla, por lo menos aparentemente. La información es la que es, y si se desea mostrar la mayor cantidad de ella, habrá que almacenarla de alguna forma para luego poder obtenerla. Con lo cual, el único remedio que hay es seleccionar bien que datos hay que conservar y cuáles no, por ser innecesarios o irrelevantes, y por otro lado usar algún método de optimización de conservación de datos en la base de MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 67 datos. Se pensó en un primer momento en tener en la tabla [LOG_ENTRY] los datos únicamente unos meses, para posteriormente, con un proceso batch o por cualquier otro medio, pasarlos a una tabla de históricos que estuviera en otra base de datos distinta, sin embargo de desechó la idea, porque en la mayoría de los casos, para una misma consulta habría que acceder a las dos bases de datos, lo que complicaría la extracción de datos y su posterior tratamiento. Además, con una sola base de datos, se tiene centralizada toda la información.  Otro problema que surgió desde los inicios del proyecto, y que se resolvió mediante la base de datos, fue el permitir reflejar de alguna forma que las operativas que se ejecutan en una banca electrónica puede estar anidadas unas dentro de otras. Vamos a poner un ejemplo para verlo mucho mejor: Estando dentro de la banca electrónica, vamos a realizar una transferencia a otra cuenta. Estando en esa pantalla, queremos ver el listado de los distintos códigos de conceptos que existen, para indicarlo en la transferencia. Este es el ejemplo de una operativa (consulta de códigos de concepto) que se ejecuta dentro de otra (transferencia). A la hora de mostrar el árbol de sesiones (del que se ha hablado anteriormente en este documento), es muy útil poder conocer este hecho. Se optó por una solución sencilla, que no supusiera mucho desarrollo ni complejidad, ya que no es un caso muy habitual dentro de una banca (de hecho, se hizo una revisión de todas las operativas que se podían ejecutar en ella, y este hecho solo ocurría en un caso). Para ello, lo que se hizo fue añadir un campo más a la tabla [OPERATIVE], que es jerarquia, que indica el nivel de anidamiento que supone para esa operativa ejecutada.  Otro problema que apareció fue el poder gestionar de una manera sencilla el hecho de poder crear estadísticas que no solo se refirieran a datos de una sola operativa, sino que se pudieran comparar varias de ellas, para poder cotejarlas juntamente. Este hecho se consiguió también mediante la adición de un campo más a la tabla [OPERATIVE] : REAL_OPERATIVE2, el cual identifica la segunda variable (que en este caso sería la operativa) por la cual se hará la comparación de los datos.  Cada interacción con la base de datos se realizará a través de transacciones atómicas (“all-or-nothing”); es decir, si todas las operaciones que componen una transacción se ejecutan satisfactoriamente, se realiza un commit, y si alguna de ellas falla, se aborta la transacción, para llevar a la base de datos al mismo estado que tenía antes de comenzar la transacción: un rollback.  Es normal también que una vez instalado MC-Spy dentro de un sistema, éste se desarrolle y crezca. Por ejemplo, en el caso de una banca electrónica, es normal que el número y la variedad de funciones que ofrezca se aumente con el tiempo. Pensando en esto, se añadió a la tabla [LOG_ENTRY] un campo que podríamos llamar “auxiliar”, pero que llegado el momento puede llegar a ser muy util. Es el campo auxiliar3, que es un texto, el cual, como decimos, cuando se cree una nueva operativa que contenga un dato que hasta ahora no se ha MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 68 tenido en cuenta en el desarrollo de MC-SPy, se pueda añadir dicho dato en este campo, haciendo que no se tenga que modificar el código de MC-Spy en nada, o al menos mínimamente. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 69 B.1.4 Diseño de la interfaz gráfica En este apartado se detallará el diseño que se hizo de la interfaz gráfica de la parte de la administración de MC-Spy. B.1.4.1 Árbol de usuarios Figura 23Página selección o búsqueda usuario MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 70 Figura 24Última sesión usuario seleccionado MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 71 Figura 25Información de la operativa seleccionada, junto con sesión en árbol MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 72 B.1.4.2 Consulta de estadísticas Estas mismas pantallas servirán tanto para las consultas de estadísticas como para el cálculo de previsiones. Figura 26Selección de datos y selección de estadística MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 73 Figura 27Ejemplo de serie con estacionalidad MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 74 Figura 28Ejemplo de gráfica con estadísticas MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 81 InfoAccessor. Utiliza los siguientes paquetes ajenos a este proyecto: o java.util.Date  OperativeInfoSet: Contenedor de información de varias filas de la tabla [OPERATIVE]. Extiende de la clase abstracta InfoSetAccessorPlus. Utiliza los siguientes paquetes ajenos a este proyecto: o java.util.Collection o java.util.Vector o java.util.Iterator  MCUserInfo: Contenedor de información de una fila de la tabla [MCUSER]. Extiende de la clase abstracta InfoAccessor. Utiliza los siguientes paquetes ajenos a este proyecto: o java.util.Date  MCUserInfoSet: Contenedor de información de varias filas de la tabla [MCUSER]. Extiende de la clase abstracta InfoSetAccessorPlus. Utiliza los siguientes paquetes ajenos a este proyecto: o java.util.Collection o java.util.Vector o java.util.Iterator  MCAdminInfo: Contenedor de información de una fila de la tabla [MCADMIN]. Extiende de la clase abstracta InfoAccessor. Utiliza los siguientes paquetes ajenos a este proyecto: o java.util.Date  MCAdminInfoSet: Contenedor de información de varias filas de la tabla [MCADMIN]. Extiende de la clase abstracta InfoSetAccessorPlus. Utiliza los siguientes paquetes ajenos a este proyecto: o java.util.Collection o java.util.Vector o java.util.Iterator  Paquete jfactory.mcserver2.util: Este paquete contiene todas las clases que sirven de ayuda al resto de las clases y paquetes del proyecto. Contienen métodos utilizados por todos ellos, tanto por el subsistema de Recolección de datos como el del Cliente de consultas, ya que así se decidió para tener todas estas clases mas centralizadas y poder favorecer la reutilización de las mismas a lo largo del proyecto. Las clases que contiene este paquete son las siguientes: MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 82  Constantes: Clase que contiene todas las constantes utilizadas en todo el proyecto.  MCServerUtil: Clase que contiene varios métodos e utilidades para el manejo de distintos tipos de datos, transformación y migración entre ellos, etc. Utiliza los siguientes paquetes ajenos a este proyecto: o java.util.Collection o java.util.Vector o java.util.Iterator o java.io.StringWriter o java.io.PrintWriter  Propiedades: Clase que extiende la clase java.util.Properties, y que se utiliza para obtener los valores contenidos en los ficheros de propiedades. De la clase que extiende, le añade varias funcionalidades, como por ejemplo, se han añadido los métodos getString(), getBoolean(), getInt(), getDate() y getFloat(), los cuáles devuelven la propiedad pasada como parámetro comoo un String, un boolean, un int, un Date y un float respectivamente. Utiliza los siguientes paquetes ajenos a este proyecto: o java.util.Properties; o java.io.File; o javax.ejb.EJBObject; o javax.naming.Context; o javax.naming.InitialContext; o javax.naming.NamingEnumeration; o javax.naming.NamingException; o javax.naming.Binding;  Log: Interface para escribir los mensajes de error y el fichero de log de la aplicación. Utiliza los siguientes paquetes ajenos a este proyecto: o java.util.Properties;  LogFactory: Clase encargada de instanciar la clase que implementa el interface Log.  Paquete jfactory.mcserver2.servlet: Paquete que contiene los servlets necesarios para llevar el control entre la parte ‘View’ y la parte ‘Model’ del proyecto. Es decir, decide el jsp a mostrar según la acción ejecutada, y MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 83 decide que acción ejecutar según la acción que se haya realizado en el jsp. En nuestro caso se decidió que esta función la podía realizar un solo servlet, ya que el número de jsps y de acciones no era muy elevada. Las clases que contiene este paquete son las siguientes:  ControllerServlet: Servlet que realiza el control de las acciones a ejecutar y los jsps a mostrar. Utiliza los siguientes paquetes ajenos a este proyecto: o javax.servlet.HttpServletRequest; o javax.servlet.HttpServletResponse o javax.servlet.http.HttpRequest; o java.util.HashMap; o java.util.ArrayList; o java.util.Calendar; o java.io.File;  Paquete jfactory.mcserver2.jbean: Paquete que contiene las clases que hacen de unión entre el servlet y los EJB’s que se encargarán de consultar a la base de datos. Se procura mover la mayor cantidad de código a estas clases, para evitar a los EJB’s esta carga. Las clases que contiene este paquete son las siguientes:  BaseJBean: Clase abstracta de la cual tendrán que extender las restantes clases pertenecientes a este paquete. Ofrece a éstas servicios de paginación para los listados de elementos, además de otras servicios como log, propiedades, contexto para acceso a los ejbs, etc. Utiliza los siguientes paquetes ajenos a este proyecto: o java.util.ArrayList;  AccountsJBean: Clase que hace de nexo entre el servlet y el EJB asociado a la tabla de cuentas de la base de datos (es una tabla ya existente, perteneciente al proyecto MC-Server, por eso no se nombró en el diseño). A través de ella (y por extensión, todas las que ella invoca y utiliza) se obtienen los datos bancarios de los usuarios, tales como cuentas, bancos,etc. Extiende de la clase BaseJBean. Utiliza los siguientes paquetes ajenos a este proyecto: o java.util.ArrayList;  LogEntryJBean: Clase que hace de nexo entre el servlet y el EJB asociado a la tabla [LOG_ENTRY] de la base de datos. Extiende de la clase BaseJBean. Utiliza los siguientes paquetes ajenos a este proyecto: MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 84 o java.util.ArrayList; o java.util.Date;  OperativeJBean: Clase que hace de nexo entre el servlet y el EJB asociado a la tabla [OPERATIVE] de la base de datos. Extiende de la clase BaseJBean. Utiliza los siguientes paquetes ajenos a este proyecto: o java.util.ArrayList; o java.util.Date;  UsersJBean: Clase que hace de nexo entre el servlet y el EJB asociado a la tabla [MCUSER] de la base de datos. Extiende de la clase BaseJBean. Utiliza los siguientes paquetes ajenos a este proyecto: o java.util.ArrayList; o java.util.Date;  McAdminJBean: Clase que hace de nexo entre el servlet y el EJB asociado a la tabla [MCADMIN] de la base de datos. Extiende de la clase BaseJBean. Utiliza los siguientes paquetes ajenos a este proyecto: o java.util.ArrayList; o java.util.Date;  Paquete jfactory.mcserver2.ejb.bl: Paquete que contiene las clases de los EJBs necesarios para toda la aplicación. Como se sabe, cada EJB lo componen 3 clases, el Home, el Bean y el Remote. En este paquete además, añadimos para cada uno de los EJBs, una clase más: el BLImpl (business logic), en la cual insertamos todo la lógica de negocio, sacándola del EJB, para evitar que su ejecución lo cargue en exceso. Esta clase hace también de nexo de unión entre el EJB y la clase que accede directamente a la base de datos. Vamos a ir relatando cada uno de los EJBs que componen este paquete: o EJB Accounts:  Accounts, AccountsBean, AccountsHome: Clases que componen el EJB de Accounts. Utilizan los siguientes paquetes ajenos a este proyecto: o javax.ejb.EJBObject; o java.rmi.RemoteException; MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 85 o java.util.ArrayList; o java.util.Iterator; o javax.ejb.FinderException; o javax.ejb.SessionContext; o javax.ejb.SessionBean; o javax.ejb.CreateException; o javax.ejb.EJBHome  AccountsBlImpl: Clase con la implementación de la lógica de negocio del EJB Accounts. Utiliza los siguientes paquetes ajenos a este proyecto: o java.util.ArrayList; o java.rmi.RemoteException; o java.util.Date o EJB LogEntry:  LogEntry, LogEntryBean, LogEntryHome: Clases que componen el EJB de LogEntry. Utilizan los siguientes paquetes ajenos a este proyecto: o javax.ejb.EJBObject; o java.rmi.RemoteException; o java.util.ArrayList; o java.util.Iterator; o javax.ejb.FinderException; o javax.ejb.SessionContext; o javax.ejb.SessionBean; o javax.ejb.CreateException; o javax.ejb.EJBHome  LogEntryBlImpl: Clase con la implementación de la lógica de negocio del EJB LogEntry. Utiliza los siguientes paquetes ajenos a este proyecto: o java.util.ArrayList; o java.rmi.RemoteException; o java.util.Date o EJB Operative:  Operative, OperativeBean, OperativeHome: Clases que componen el EJB de Operative. Utilizan los siguientes paquetes ajenos a este proyecto: o javax.ejb.EJBObject; o java.rmi.RemoteException; MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 86 o java.util.ArrayList; o java.util.Iterator; o javax.ejb.FinderException; o javax.ejb.SessionContext; o javax.ejb.SessionBean; o javax.ejb.CreateException; o javax.ejb.EJBHome  OperativeBlImpl: Clase con la implementación de la lógica de negocio del EJB Operative. Utiliza los siguientes paquetes ajenos a este proyecto: o java.util.ArrayList; o java.rmi.RemoteException; o java.util.Date o EJB McUser:  McUser, McUserBean, McUserHome: Clases que componen el EJB de McUser. Utilizan los siguientes paquetes ajenos a este proyecto: o javax.ejb.EJBObject; o java.rmi.RemoteException; o java.util.ArrayList; o java.util.Iterator; o javax.ejb.FinderException; o javax.ejb.SessionContext; o javax.ejb.SessionBean; o javax.ejb.CreateException; o javax.ejb.EJBHome  McUserBlImpl: Clase con la implementación de la lógica de negocio del EJB McUser. Utiliza los siguientes paquetes ajenos a este proyecto: o java.util.ArrayList; o java.rmi.RemoteException; o java.util.Date o EJB McAdmin:  McAdmin, McAdminBean, McAdminHome: Clases que componen el EJB de McAdmin. Utilizan los siguientes paquetes ajenos a este proyecto: o javax.ejb.EJBObject; o java.rmi.RemoteException; MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 87 o java.util.ArrayList; o java.util.Iterator; o javax.ejb.FinderException; o javax.ejb.SessionContext; o javax.ejb.SessionBean; o javax.ejb.CreateException; o javax.ejb.EJBHome  McAdminBlImpl: Clase con la implementación de la lógica de negocio del EJB McAdmin. Utiliza los siguientes paquetes ajenos a este proyecto: o java.util.ArrayList; o java.rmi.RemoteException; o java.util.Date  Paquete jfactory.mcserver2.ejb.dal: Paquete que contiene las clases de acceso a datos (DAL: Data access logic). Son realmente las clases que, a través del driver necesario para acceder a la base de datos de Oracle, ejecutan las sentencias SQL. Son también ellas las encargadas en transformar las respuestas que obtienen en instancias de objetos entendibles por el resto de las clases del proyecto. Lógicamente, existe una clase DAL por cada una de las tablas a las que accedemos en la base de datos. Las clases que contiene este paquete son las siguientes:  AccountsDALImpl: Clase de acceso a base de datos para todas aquellas tablas que contienen datos bancarios sobre los usuarios. Utiliza los siguientes paquetes ajenos a este proyecto: o java.util.ArrayList; o java.sql.Timestamp; o java.util.Date; o java.sql.Time; o java.sql.Connection; o java.sql.ResultSet; o java.sql.PreparedStatement; o java.sql.SQLException  LogEntryDALImpl: Clase de acceso a base de datos para la tabla [LOG_ENTRY]. Utiliza los siguientes paquetes ajenos a este proyecto: o java.util.ArrayList; o java.sql.Timestamp; o java.util.Date; o java.sql.Time; MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 88 o java.sql.Connection; o java.sql.ResultSet; o java.sql.PreparedStatement; o java.sql.SQLException  OperativeDALImpl: Clase de acceso a base de datos para la tabla [OPERATIVE]. Utiliza los siguientes paquetes ajenos a este proyecto: o java.util.ArrayList; o java.sql.Timestamp; o java.util.Date; o java.sql.Time; o java.sql.Connection; o java.sql.ResultSet; o java.sql.PreparedStatement; o java.sql.SQLException  McUserDALImpl: Clase de acceso a base de datos para la tabla [MCUSER]. Utiliza los siguientes paquetes ajenos a este proyecto: o java.util.ArrayList; o java.sql.Timestamp; o java.util.Date; o java.sql.Time; o java.sql.Connection; o java.sql.ResultSet; o java.sql.PreparedStatement; o java.sql.SQLException  McAdminDALImpl: Clase de acceso a base de datos para la tabla [MCADMIN]. Utiliza los siguientes paquetes ajenos a este proyecto: o java.util.ArrayList; o java.sql.Timestamp; o java.util.Date; o java.sql.Time; o java.sql.Connection; o java.sql.ResultSet; o java.sql.PreparedStatement; o java.sql.SQLException  Paquete jfactory.mcserver2.rc.jbean: Paquete que contiene las clases que hacen de unión entre el servlet y los EJB’s, dentro del recolector de datos, y por lo tanto, integradas en MC-Server. Contiene un jBean por cada uno de MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 89 los módulos que tiene la banca, por lo tanto, son demasiados para enumerarlos aquí, además de algunos comunes que si que pasamos a detallar a continuación: o SessionJBean: Es la clase que realiza la comunicación entre MC-Server y MC-Spy, y que por lo tanto, actua de nexo de unión entre las dos aplicaciones. o BaseJBean; o PaginationCache; o PropApplication; o Sequences; o …;  Paquete jfactory.mcserver2.rc.ejb.bl: Paquete que contiene las clases de los EJBs necesarios para toda la aplicación. Como se sabe, cada EJB lo componen 3 clases, el Home, el Bean y el Remote. En este paquete además, añadimos para cada uno de los EJBs, una clase más: el BLImpl (business logic), en la cual insertamos todo la lógica de negocio, sacándola del EJB, para evitar que su ejecución lo cargue en exceso. Esta clase hace también de nexo de unión entre el EJB y la clase que accede directamente a la base de datos. Al igual que el caso de los JBeans, existen demasiados paquetes dentro de éste para exponerlos.  Paquete jfactory.mcserver2.rc.ejb.dal: Paquete que contiene las clases de acceso a datos (DAL: Data access logic). Son realmente las clases que, a través del driver necesario para acceder a la base de datos de Oracle, ejecutan las sentencias SQL. Son también ellas las encargadas en transformar las respuestas que obtienen en instancias de objetos entendibles por el resto de las clases del proyecto. Lógicamente, existe una clase DAL por cada una de las tablas a las que accedemos en la base de datos. Como es fácil de suponer, la infinidad de tablas que pueden existir en la base de datos, hace imposible poder aquí detallar la lista de todo los DALS que existen dentro de este paquete.  Paquete jfactory.mcserver2.rc.util: Este paquete contiene todas las clases que nos pueden servir de ayuda para la implementación del resto de clases. En este caso, aparte de las anteriormente mencionadas ya en el paquete jfactory.mcserver2.util, y que son las clases “útiles” que se utilizan tanto en el recolector de datos como en las consultas, se utilizan también las siguientes clases exclusivamente:  LogEntreQueue: Es la clase encargada de gestionar la inserción de los datos recibidos desde MC-Server en la BD. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 90 Se explicará posteriormente con más detalle las características de esta clase.  Date: Clases para el manejo de fechas.  JCrypt: Clase que contiene varios métodos e utilidades para la encriptación de datos.  Fast: Clases para facilitar el manejo de datos dentro de objetos de datos destinados para ello. Por ejemplo se pueden usar: o fastHashTable; o fastVector;  Exception: Clases con los distintos tipos de excepciones que puede manejar la aplicación: o …;  JMS: Clases encargadas de gestionar el servicio de mensajes en colas.  Paquete jfactory.mcserver2.rc.util.sa : Este paquete contiene clases e interfaces necesarios para almacenar información, y transportarla a lo largo del flujo de invocación entre las clases implicadas en éste. Ya explicado anteriormente en este mismo capítulo su funcionamiento dentro de esta arquitectura. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 97 característica lógica que nos haga predecir cómo va a ser esa serie en el futuro). Por otro lado, de los métodos existentes para este tipo de series, es de los que mejores resultados aporta. C.3.2.2 Serie sin tendencia con estacionalidad Para las series de este tipo se ha utilizado el método de Medias estacionales. Es un método de estructura fija que define la predicción para cada periodo a partir de la media muestral de los períodos con idéntico componente estacional. Es decir, si por ejemplo tenemos datos trimestrales durante varios años, hacemos la media de todos los datos de los primeros trimestres, y eso será lo que utilicemos como predicción para los datos futuros de esos periodos. Igual se hará con el resto de periodos (o estaciones). Puede parecer un método bastante sencillo y no tener demasiada precisión, pero dentro de los métodos para este tipo y que sean implementables, era el que mejor resultados daba. C.3.2.3 Serie con tendencia sin estacionalidad En este caso, usaremos el método de Alisado exponencial lineal de Holt, para obtener las predicciones de las series de tipo 3. Es un método de estructura variable que asume que la tendencia es localmente lineal. Por lo tanto, la predicción está basada en una actualización de la estimación de la tendencia y la pendiente para cada periodo muestral, conforme se incorpora nueva información. Para ello, se utilizan todos los valores previos de la serie y no solo un número reducido de ellos, como se hace en otros métodos. Con la estimación de la tendencia, veremos si la serie de datos tiende a ser lineal, o por el contrario por ejemplo, sigue una tendencia cuadrática. Con esta estimación, junto con la pendiente (como de rápido va esa tendencia), podremos obtener una previsión de los valores bastante fiable. C.3.2.4 Serie con tendencia y con estacionalidad Para este último tipo de series, utilizaremos el método de Alisado exponencial de Holt-Winters. Éste es un método de estructura variable basado en la reestimación a lo largo de todos los períodos muestrales de la tendencia, la pendiente y el componente estacional mediante unas ecuaciones de actualización. La predicción en un periodo se formula en términos de los valores estimados de estos tres términos en el periodo en que se formula la predicción. Como se puede suponer viendo el nombre del método, está MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 98 íntimamente relacionado con el método del anterior tipo de series. Por lo tanto, además de la tendencia y de la pendiente, se añade ahora el cálculo de otra componente que es el componente estacional (éste último sería algo así como el valor de lo que se separa cada uno de esos periodos de la media de la serie). Este método, comparándolo con otros similares y también utilizados para este tipo de series (como por ejemplo el método de Tendencia lineal con variables ficticias o el método de Descomposición), obtiene unos resultados similares a los demás, pero se adapta mucho mejor a los algoritmos programables que aquí podríamos utilizar e implementar. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 99 C.4 Implementación de aspectos gráficos C.4.1 Árbol de sesiones Para mostrar debidamente el árbol de sesiones necesitamos dotarle de dinámica, como en todos los elementos gráficos en forma de árbol que pueden aparecer en una página web. Para ello se utilizó HTML dinámico, modificando el aspecto de la página de forma dinámica en base a eventos javascript previamente definidos (abrir una rama, cerrar una rama, etc…). Figura 32Árbol de sesiones C.4.2 Estadísticas gráficas Para dibujar las gráficas (tanto en formato de tarta como de barras), se implementó un sencillo applet que se integraba dentro de la página jsp, y que dibujaba la estadística correspondiente. Para ello se le pasaban como parámetro el tipo de gráfica que se trataba, y todos los valores que se debían emplear en la gráfica. Así obtendríamos gráficas como la que aquí se muestra a continuación. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 100 Figura 33Gráfica de una estadística MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 101 Anexo D. Pruebas La fase de pruebas nos permite comprobar el buen funcionamiento de los algoritmos utilizados durante la implementación, y detectar si cumplen con los requisitos inicialmente planteados. Se realizaron durante el ciclo de vida del proyecto dos tipos de pruebas: pruebas unitarias (probando cada uno de los módulos durante y tras su implementación), y pruebas de integración (cuando dichos módulos se integraban unos con otros para formar la aplicación). Como se ha explicado anteriormente en la memoria, para este proyecto se utilizó un modelo incremental, por lo que para cada módulo se realizaron pruebas unitarias que certificaban su completitud, y una vez que se finalizaron todos los módulos habiendo pasado dichas pruebas, se realizaron las pruebas de integración, ya dentro de la fase de Modo Operacional. D.1 Pruebas unitarias Se realizaron pruebas unitarias en la finalización de la implementación de cada uno de los módulos para el aseguramiento de la calidad y de la afinidad con los requisitos iniciales. En este proyecto, como se ha comentado en los apartados del Análisis y el Diseño, se identifican dos grandes módulos, a los cuales se les aplicaron etas pruebas. Se realizaron pues pruebas unitarias en el Módulo de Recolección de Datos, asegurándose que los datos insertados en la BD, eran exactamente iguales a los que el usuario había insertado en la web de la banca electrónica, y que los datos que se generaban automáticamente (por ejemplo fechas y tiempos), coincidían con la realidad de la acción. Para ello se realizaban consultas a la BD, comprobando la verisimilitud de esta información. Usando pues un entorno de pruebas de la banca electrónica, se generaban datos, que luego eran consultados (mediante SELECTS directas a la BD) para su comprobación. Respecto al otro módulo, el de Consultas, para la fase de pruebas se identificaron tres submódulos sobre los que ejecutar las pruebas unitarias. A saber:  Árbol de sesiones.  Estadísticas  Previsiones. Dada la criticidad de cada uno de ellos, se prefirió dividir estas pruebas para cada uno de los submódulos, para así cerciorarnos de manera más definitiva de su correcto funcionamiento. Para el árbol de sesiones, se preparó una batería de pruebas de usuarios que entraban en la banca electrónica, y que realizaban diversas operativas (también incluyendo usuarios que no hacían nada, por ejemplo, o usuarios que repetían constantemente una operativa, es decir, casos raros para ver si el árbol de sesiones funcionaba correctamente en todo tipo de situaciones y bajo todas las posibles casuísticas), y se comprobaba que la MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 102 información que se mostraba en las ramas del árbol correspondía con lo ejecutado anteriormente en la banca. En el caso de las estadísticas, se probaron una a una todas las estadísticas disponibles, y para comprobar que los datos eran ciertos, se cargaron previamente en la BD datos con varias posibilidades variadas (por ejemplo que no hubiera datos, que solo hubiera uno, que hubiera múltiples), para ver cómo se comportaba la estadística, ya fuera gráfica o en texto. A destacar en este punto que debido a la integración con el componente que dibujaba los gráficos (de tarta, de barras, etc…), hubo varios casos de errores en la muestra en pantalla de las gráficas, sobre todo a la hora de tratar datos especialmente singulares (como por ejemplo y como ya se ha comentado, el que no hubiera ningún dato para mostrar o bien que sólo hubiera uno y no se mostrara correctamente en el gráfico de tarta). En el apartado XXXX, se explica la respuesta ante este tipo de situaciones. En el caso de las previsiones se trata de un apartado especial, ya que no solo influyen los datos que hay almacenados en la BD, y que son con lo que trabajarán para obtener las previsiones, sino que también influye (y mucho en este caso) los algoritmos que construyen las series de tiempo previstas. Ante la dificultad de poder comprobar o bien visualmente o bien mediante consultas a BD la verisimilitud de dichas previsiones, lo que se hizo fue preparar varias series de datos, y construir “a mano” el resultado con la serie de tiempo que tendría que obtenerse. Gracias a este método se obtuvieron diversos errores en la implementación de los algoritmos. D.2 Pruebas de integración Para hacer pruebas de integración, y dado que los dos módulos están separados pero íntimamente relacionados, se decide que la mejor forma de planificarlas y ejecutarlas es crear un usuario totalmente nuevo en la banca electrónica, y con él, iniciar una serie de consultas en el módulo de Consultas. Posteriormente, y habiendo dicho usuario entrado ya a la banca y habiendo ejecutado varias operativas, se comprobaban que los datos que se mostraban en las Consultas correspondían con lo realizado en la banca (y por lo tanto con lo insertado a través del módulo de Recolección de Datos); con lo cual se podía comprobar conjuntamente el correcto funcionamiento de ambas partes de la aplicación MC-Spy. Durante varias jornadas se estuvieron realizando dichas pruebas para comprobar y asegurar el correcto funcionamiento de ambos módulos integrados en una sola aplicación. D.3 Respuesta ante un error detectado Si a lo largo de las pruebas unitarias se encontraba un error en la implementación de alguno de los módulos de la aplicación, la forma de actuar era simple. Tal y como muestra el apartado 5 de la memoria de este proyecto, y siguiendo el modelo incremental, cuando se encontraba este error, se intentaba corregir en el código, y se comprobaba si era debido a un error de implementación o de diseño. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 103 En caso de que fuera de éste último, se revisaba el diseño para corregir lo que fuera necesario, y se volvían a ejecutar las pruebas unitarias de ese módulo. En caso de que fuera únicamente de implementación, se corregía y se pasaban de nuevo las pruebas. Durante las pruebas de integración, la respuesta era similar, pero en este caso, incluyendo todos los módulos en la ejecución de las pruebas tras la búsqueda y la solución del error. MC-Spy Proyecto Fin de Carrera. Santiago Abadía Zárate 104 Índice de figuras 1. Servicios de MC-Server.………………………………………………….Pág 7 2. Arquitectura técnica MC-Server………………………………………….Pág 8 3. Aspecto maqueta MC-Spy ……………………………………………….Pág 12 4. Modelo de Recolección de datos ……………………………………..….Pág 16 5. Módulo Administración o de Estadísticas….…………………………….Pág 17 6. Modelo incremental………………………………………………………Pág 21 7. Caso de uso de una operativa en la banca………………………………..Pág 39 8. Diagrama de secuencia de una transferencia.…………………………….Pág 40 9. Caso de uso Consulta estadística…………………………………………Pág 41 10. Diagrama secuencia Consulta estadística……………………….…….….Pág 43 11. Caso de uso Consulta árbol de sesiones……………………….………….Pág 43 12. Diagrama de secuencia Consulta árbol de sesiones…………………...….Pág 45 13. Ejemplo de serie con estacionalidad.……………………………….…….Pág 46 14. Ejemplo de serie con tendencia….……………………………………….Pág 46 15. Modelo lógico…………………………………………………………….Pág 49 16. Subsistema Recolector de datos.……………………….……………..….Pág 50 17. Subsistema cliente consultas……………………………………………..Pág 51 18. Modelo físico……………………………………………………………..Pág 53 19. Subsistema recolector de datos…..……………………………………….Pág 54 20. Esquema patrón MVC..…………………………………………………..Pág 55 21. Subsistema Cliente de consultas………………………………………….Pág 57 22. Diseño físico BD……...………………………………………………….Pág 65 23. Página selección o búsqueda usuario……………………………………..Pág 69 24. Última sesión usuario seleccionado………………………………………Pág 70 25. Información de la operativa seleccionada, junto con sesión en árbol…….Pág 71 26. Selección de datos y selección de estadística…………………………….Pág 72 27. Ejemplo de serie con estacionalidad…..………………………………….Pág 73 28. Ejemplo de gráfica con estadísticas...…………………………………….Pág 74 29. Paquetes genéricos Recolector de datos………………………………….Pág 76 30. Paquetes genéricos Consultas ……...…………………………………….Pág 77 31. Esquema funcioamiento JMS…………………………………………….Pág 93 32. Árbol de sesiones……...………………………………………………….Pág 99 33. Gráfica de una estadística………………………………………………...Pág 100