UNIVERSIDAD SIMÓN BOLÍVAR Ingeniería de la Computación

Transcripción

1 UNIVERSIDAD SIMÓN BOLÍVAR Ingeniería de la Computación Construcción del Módulo de Gestión de Alertas para el Control de Fraude Masivo en Entidades Bancarias. Por Orlando Alberto Rocca Mata INFORME FINAL DE CURSOS EN COOPERACIÓN Presentado ante la Ilustre Universidad Simón Bolívar como Requisito Parcial para Optar al Título de Ingeniero en Computación Sartenejas, Octubre de 2007 i

2

3 Construcción del Módulo de Gestión de Alertas para el Control de Fraude Masivo en Entidades Bancarias. Autor: Orlando Rocca Fecha: Octubre 2007 Tutor Académico: Marlene Goncalves Tutor Industrial: José Materán RESUMEN La inseguridad que se presenta en el sistema bancario electrónico venezolano y mundial obliga a las entidades a desarrollar soluciones de software que permitan implementar controles para evitar el fraude. En el siguiente informe se presenta la documentación del proceso de construcción del módulo de gestión de alertas para SUAF+ (Sistema Unidad Anti-Fraude Plus), el cual forma parte de la solución de software que la empresa Sigmenta Business Technologies quiere desarrollar en su sistema de control de fraude masivo en entidades bancarias. El proceso de desarrollo del proyecto se basa fundamentalmente en dos módulos del sistema, el módulo front Web y el módulo de servicios de acceso a datos implementado completamente en Java junto con las especificaciones de Java Edición Empresarial. Ya que pueden existir otras implementaciones de los servicios hechas en ambiente CICS-COBOL, el diseño del módulo front Web debe ser lo suficientemente flexible como para soportar distintas implementaciones de los servicios. iii

4 DEDICATORIA A mi madre, porque siempre te paraste primero que yo a darme fuerzas para iniciar todos los días de mi vida. A mi padre, por darme el espíritu de lucha que hoy me tiene aquí. A mi hermano Arnaldo, por el apoyo incondicional que siempre me ayudó a continuar. A mi hermanita Marianny, por seguir adelante. A Dios, por lo que soy, lo que tengo y lo que tendré. iv

5 AGRADECIMIENTOS Gracias a mi familia que siempre me ayudó incondicionalmente a continuar esforzándome para conseguir lo que quiero. A la profesora Marlene Goncalves por brindarme los conocimientos y la ayuda en las mil y una materias que me impartió incluyendo el trabajo de ser mi tutora académica. Al profesor Ascender Suárez por haberme brindado la confianza al iniciar esta hermosa carrera, sus palabras bienvenido a la carrera al cambiarme a Ingeniería de la Computación fueron significativas por más sencillas que parezcan. A mis compadres y amigos por el apoyo mutuo para salir adelante con esta carrera, incluyendo los días de trasnocho y entregas de proyectos a última hora. También a los profesores que nos daban las eternas prorrogas. Gracias a Dios por permitirme seguir luchando y haberme brindado la oportunidad de superarme. A todos, infinitas gracias. v

6 ÍNDICE GENERAL RESUMEN... III DEDICATORIA... IV AGRADECIMIENTOS...V ÍNDICE GENERAL... VI ÍNDICE DE TABLAS... VIII ÍNDICE DE FIGURAS... IX INTRODUCCIÓN...13 PLANTEAMIENTO DEL PROBLEMA OBJETIVOS GENERALES...16 ENTORNO EMPRESARIAL...18 SIGMENTA BUSINESS TECHNOLOGIES...18 MARCO TEÓRICO/TECNOLÓGICO ARQUITECTURA DE SOFTWARE FUNDAMENTOS TECNOLÓGICOS...22 ANÁLISIS PANORAMA GENERAL CASOS DE USO...30 FIGURA 5.1. DIAGRAMA DE CASOS DE USO DEL SISTEMA...32 DISEÑO DECISIONES GENERALES ARQUITECTURA DEL SISTEMA Sobre el Diseño Lógico Despliegue del Sistema Sobre el Diseño Visual...41 IMPLEMENTACIÓN CONFIGURACIÓN DEL AMBIENTE DE DESARROLLO IMPLEMENTACIÓN DEL SISTEMA SUAF Módulo Front Web: Módulo de Servicios de Acceso a Datos Módulo de Ayudas Online FASES DE PRUEBA PROBLEMAS ENCONTRADOS...51 CONCLUSIONES Y RECOMENDACIONES CONCLUSIONES RECOMENDACIONES...54 REFERENCIAS...56 vi

7 ADMINISTRACIÓN DEL PROYECTO...58 A.1 PLANIFICACIÓN...58 A.2 RIESGOS...59 DOCUMENTOS DE DISEÑO...61 B.1. CASOS DE USO...61 B.2. DIAGRAMAS DE SECUENCIA DEL SISTEMA...64 DISEÑO DE INTERFACES DE USUARIO...70 ENTORNO EMPRESARIAL...79 vii

8 ÍNDICE DE TABLAS TABLA 7.1. CAPACIDADES EXIGIDAS VS FUNCIONALIDAD EN EL SISTEMA TABLA A.1. PLANIFICACIÓN GENERAL DEL PROYECTO...58 TABLA A.2. TABLA DE RIESGOS...59 TABLA B.1. CASO DE USO: ATENDER ALERTAS PENDIENTES...61 TABLA B.2. CASO DE USO: CONSULTAR ALERTAS PENDIENTES...62 TABLA B.3. CASO DE USO: CONSULTAR ALERTAS GESTIONADAS...62 TABLA B.4. CASO DE USO: CONFIGURAR PARÁMETROS GENERALES...63 TABLA B.5. CASO DE USO: CONSULTAR AYUDAS EN LÍNEA...63 TABLA B.6. CASO DE USO: CONSULTAR LISTA DE ENTIDADES...64 viii

9 ÍNDICE DE FIGURAS FIGURA 4.1. ARQUITECTURA DE TRES CAPAS...21 FIGURA 5.1. DIAGRAMA DE CASOS DE USO DEL SISTEMA...32 FIGURA 6.1. MODELO CONCEPTUAL DEL MÓDULO DE GESTIÓN DE ALERTAS...34 FIGURA 6.2. CAPAS DE LA APLICACIÓN SUAF FIGURA 6.3. MODELO DE DISEÑO: PAQUETES...37 FIGURA 6.4. NODOS DEL SISTEMA...40 FIGURA 6.5. COMPONENTES DEL SISTEMA EN LOS NODOS DONDE SE EJECUTAN...40 FIGURA 7.1 VENTANA DE AYUDAS EN LÍNEA DE LA APLICACIÓN...48 FIGURA 7.2. VENTANA DE AYUDAS EN LÍNEA DE LA APLICACIÓN CON BARRA MINIMIZADA...49 FIGURA B.1. DIAGRAMA DE SECUENCIA PARA EL CASO COMPLETO DE GESTIÓN DE ALERTAS FIGURA B.2. DIAGRAMA DE SECUENCIA PARA LA CONEXIÓN A LOS SERVICIOS DE ACCESO A DATOS FIGURA B.3. DIAGRAMA DE SECUENCIA DEL MÓDULO DE SERVICIOS DE ACCESO A DATOS. FUNCIONALIDAD DE ATENCIÓN DE ALERTAS...69 FIGURA C.1. BOCETO INICIAL DE ENTIDADES ALERTADAS PARA LA ATENCIÓN DE ALERTAS...70 FIGURA C.2. PANTALLA FINAL DE ENTIDADES ALERTADAS PARA LA ATENCIÓN DE ALERTAS...71 FIGURA C.3. BOCETO INICIAL DE ALERTAS PENDIENTES PARA LA ATENCIÓN DE ALERTAS...71 FIGURA C.4. PANTALLA FINAL DE ALERTAS PENDIENTES PARA LA ATENCIÓN DE ALERTAS...72 FIGURA C.5. PANTALLA FINAL DE ALERTAS PENDIENTES PARA LA ATENCIÓN DE ALERTAS...73 FIGURA C.6. BOCETO INICIAL DE ENTIDADES ALERTADAS PARA LA SUPERVISIÓN DE ALERTAS FIGURA C.7. PANTALLA FINAL DE ENTIDADES ALERTADAS PARA LA SUPERVISIÓN DE ALERTAS...74 FIGURA C.8. BOCETO INICIAL DE ALERTAS PENDIENTES PARA LA SUPERVISIÓN DE ALERTAS...75 FIGURA C.9. PANTALLA FINAL DE ALERTAS PENDIENTES PARA LA SUPERVISIÓN DE ALERTAS...75 FIGURA C.10. BOCETO INICIAL DE ALERTAS GESTIONADAS PARA LA SUPERVISIÓN DE ALERTAS...76 FIGURA C.11. PANTALLA FINAL DE ALERTAS GESTIONADAS PARA LA SUPERVISIÓN DE ALERTAS...76 FIGURA C.12. BOCETO INICIAL DE PARÁMETROS GENERALES...77 FIGURA C.13. PANTALLA FINAL DE CONSULTA DE PARÁMETROS GENERALES...77 FIGURA C.14. PANTALLA FINAL DE CONFIGURACIÓN DE PARÁMETROS GENERALES...78 FIGURA ANEXO1. ESTRUCTURA ORGANIZACIONAL DE SBT ix

10 GLOSARIO DE TÉRMINOS Y ACRÓNIMOS API Del inglés Application Programming Interface - Interfaz de Programación de Aplicaciones, es el conjunto de funciones y procedimientos o métodos que ofrece cierta librería para ser utilizado por otro software como una capa de abstracción. BEAN Es un componente software que tiene la particularidad de ser reutilizable y así evitar la tediosa tarea de programar los distintos componentes uno a uno. CICS Acrónimo en inglés de Customer Information Control System (en español, Sistema de Control de Información de Clientes), es un gestor transaccional, o monitor de teleproceso, que se ejecuta principalmente en mainframes IBM COBOL Acrónimo de COmmon Business -Oriented Language, Lenguaje Común Orientado a Negocios, es un lenguaje creado en el año 1960 con el objetivo de crear un lenguaje de programación universal que pudiera ser usado en cualquier ordenador, ya que en los años 1960 existían numerosos modelos de ordenadores incompatibles entre sí, y que estuviera orientado principalmente a los negocios, es decir, a la llamada informática de gestión. CORBA Common Object Request Broker Architecture arquitectura común de intermediarios en peticiones a objetos, es un estándar que establece una plataforma de desarrollo de sistemas distribuidos facilitando la invocación de métodos x

11 remotos bajo un paradigma orientado a objetos. CORE Núcleo. En informática se usa especialmente para referirse al núcleo de un procesador. En el ambiente de Mainframe es utilizado para referirse al conjunto de procesos que conforman el motor principal del sistema. CSS Hojas de estilo en cascada (Cascading Style Sheets, por sus siglas en ingles), son un lenguaje formal usado para definir la presentación de un documento estructurado escrito en HTML o XML (y por extensión en XHTML). El W3C (World Wide Web Consortium) es el encargado de formular la especificación de las hojas de estilo que servirá de estándar para los agentes de usuario o navegadores. FRONT WEB Es la parte del software que interactúa con el usuario y hace referencia a la visualización del usuario navegante (por un lado), y del administrador del sitio con sus respectivos sistemas (por el otro). HTML HyperText Markup Language. Lenguaje de marcación diseñado para estructurar textos y presentarlos en forma de hipertexto, que es el formato estándar de las páginas web. IDE Un entorno de desarrollo integrado o en inglés Integrated Development Environment ('IDE') es un programa compuesto por un conjunto de herramientas para un programador JAVA Es un lenguaje de programación orientado a objetos desarrollado por Sun Microsystems a principios de los años El lenguaje en sí mismo toma mucha de su sintaxis de C y C++, pero tiene un modelo de objetos más simple y elimina herramientas de bajo nivel como punteros. xi

12 JAVASCRIPT Es un lenguaje interpretado, es decir, que no requiere compilación, utilizado principalmente en páginas web, con una sintaxis semejante a la del lenguaje Java y el lenguaje C. JDBC Es el acrónimo de Java Database Connectivity, un API que permite la ejecución de operaciones sobre bases de datos desde el lenguaje de programación Java independientemente del sistema de operación donde se ejecute o de la base de datos a la cual se accede utilizando el dialecto SQL del modelo de base de datos que se utilice. PDF Del inglés Portable Document Format, Formato de Documento Portátil, es un formato de almacenamiento de documentos, desarrollado por la empresa Adobe Systems. SQL Lenguaje de Consulta Estructurado (Structured Query Language), es un lenguaje declarativo de acceso a bases de datos relacionales que permite especificar diversos tipos de operaciones sobre las mismas. UML: Siglas en inglés (Unified Modeling Language) de Lenguaje Unificado de Modelado, que corresponde al lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad. Web: Palabra usada para hacer referencia al World Wide Web, que es un sistema de documentos de hipertexto enlazados y accesibles a través de Internet, denominados páginas Web. XML: Siglas en inglés de extensible Markup Language («lenguaje de marcas extensible»), es un metalenguaje extensible de etiquetas desarrollado por el World Wide Web Consortium. xii

13 INTRODUCCIÓN Capítulo 1 En la actualidad, los sistemas bancarios presentan grandes problemas a causa de las estafas electrónicas realizadas por personas inescrupulosas, las cuales mediante distintas modalidades de fraude se apoderan de grandes cantidades de dinero de las entidades a través de los sistemas digitales de las mismas. Estas modalidades de fraude suelen ser difíciles de detectar en el momento de la ejecución del delito por lo que las entidades bancarias se ven obligadas a tomar acciones posteriores a los hechos que minimicen las violaciones a sus sistemas. Aún más difícil de detectar son las estafas que se llevan a cabo con complicidad interna. Tal es el caso por ejemplo del fraude informático realizado en el 2006 cuando se logró extraer de forma irregular diez mil millones de bolívares del Banco Confederado con tarjetas de crédito en solo dieciséis horas y que según investigaciones se llevo a cabo a través de un empleado de confianza de la referida institución bancaria.[6] La inseguridad que se presenta en el sistema bancario electrónico venezolano y mundial obliga a las entidades a implementar controles para evitar el fraude por representar una pérdida de activos de sus clientes. Así, surgen diversas herramientas antifraude que detectan el acto delictivo siguiendo constantemente las irregularidades que se puedan presentar en las transacciones hechas sobre los bancos, permitiendo que las entidades bancarias estén en conocimiento de posibles fraudes. De esta forma, las entidades pueden tomar las acciones respectivas para evitar o solucionar la pérdida de sus activos. En este contexto, es útil contar con un sistema de gestión de alertas de posibles estafas, en el que se puedan atender eficientemente estas alarmas y éstas 13

14 puedan ser procesadas debidamente para minimizar el impacto de los fraudes sobre las entidades bancarias. La empresa Sigmenta Business Technologies (SBT)[17] ofrece actualmente entre sus productos un sistema de control antifraude para clientes (SUAF, Sistema Unidad Anti-Fraude). El producto está dirigido a solventar casos de fraude sobre los clientes de las entidades y permite la gestión de alertas que reflejan el posible uso indebido de las tarjetas de crédito o débito del cliente por parte de terceras personas. Si se sospecha de un uso indebido de una tarjeta, ésta es bloqueada con el fin de evitar su uso inapropiado. Pero esto sólo resuelve los casos de fraude realizados directamente contra las tarjetas de un cliente y todavía sigue quedando un abanico de posibilidades de hechos fraudulentos directamente contra las entidades. No obstante, SBT se ha planteado la tarea de solucionar el problema de los ataques a través de fraudes masivos que extraen grandes sumas de dinero al banco con diversos tipos de tarjetas en puntos específicos de servicio bancario. Por otra parte, el Sistema Unidad Anti-Fraude Plus (SUAF+), es una nueva herramienta que requiere ser integrada con SUAF como un módulo nuevo, para proporcionar la gestión de alertas de fraude masivo en entidades, lo que implica que se abarque más el rango de control de fraude para las entidades con los productos de SBT. La idea es incorporar la herramienta con la posibilidad de poder proveer ambos sistemas juntos (SUAF y SUAF+) o cada uno de manera individual. En el presente informe se explica con detalle el desarrollo del sistema SUAF+ para gestionar las alertas de fraude masivo en entidades bancarias. En el segundo capítulo se describe el planteamiento detallado del problema, seguido por el tercer capítulo donde se muestra el contexto empresarial en donde se realizó la pasantía. En el capítulo 4 se presenta el marco teórico/tecnológico para el desarrollo del proyecto. Los capítulos 5, 6 y 7 describen detalladamente el proceso de análisis, diseño y desarrollo del proyecto, respectivamente. Finalmente, en el capítulo octavo se exponen una serie de conclusiones y las recomendaciones finales de esta pasantía. 14

15 PLANTEAMIENTO DEL PROBLEMA Capítulo 2 Con el objeto de monitorear el flujo transaccional que transita a través de un punto de servicio bancario, la empresa Sigmenta Business Technologies ha puesto en desarrollo el Sistema Unidad Anti-Fraude Plus, SUAF+ 1. El objetivo de SUAF+ es gestionar alertas tempranas que permitan atenuar el efecto que tiene un fraude electrónico a nivel masivo, a diferencia de SUAF que se orienta al control antifraude a nivel del cliente individual. En particular, SUAF+ busca captar la utilización incorrecta del resultado de transacciones o la alteración de cualquiera de las etapas del procesamiento de una transacción, para frenar el perjuicio que esto puede provocar en las entidades financieras. Para ello, SUAF+ monitorea algún tipo de variación en la cantidad de transacciones y en el monto de estas en un lapso determinado de tiempo sobre distintos puntos de servicios bancarios. Esta variación se compara versus el comportamiento histórico de cada entidad involucrada lo que debe generar indicadores para detectar el posible fraude. Para realizar esta tarea el sistema cuenta con distintos módulos que cumplen con funcionalidades especificas, entre ellos están los módulos de gestión de alertas que se encargan del procesamiento de los datos de transacciones anómalas por posible fraude. Actualmente, en SUAF se utilizan repositorios de datos a los cuales se acceden a través de servicios implementados en tecnología COBOL-CICS [7], lo que implica grandes gastos de dinero para sus clientes debido a la necesidad de adquirir licencias de software. De esta forma, es una exigencia de mucho valor para la empresa que los servicios a los repositorios de datos de SUAF+ puedan ser implementados en lenguajes y ambientes que no impacten al sistema con costos de licencias ajenas al producto o en procesos de conversión de datos entre servicios y la capa front. 1 SUAF+, por ser sucesor del sistema actual SUAF, Sistema Unidad Anti-Fraude de la empresa SBT 15

16 2.1. Objetivos Generales El objetivo principal de este proyecto de pasantía es diseñar e implementar el módulo de gestión de alertas de SUAF+ que permita la atención de alertas por parte de los operadores, las consultas de alertas y la parametrización general de SUAF+. Este módulo es de carácter significativo para el sistema puesto que a través de él, el usuario tendrá la posibilidad de: Configurar los parámetros generales del sistema para la gestión de alertas. Los parámetros generales incluyen la decisión de hacer la carga automática de bines 2, el lapso de espera para anular una alerta en gestión, el envío de mensaje de alerta al operador, la frecuencia del envío de alerta al operador, la frecuencia a utilizar para el análisis de la información que puede originar alerta, u otras características generales con respecto al módulo de gestión de alertas que se consideren necesarios. Atender cada una de las alertas por entidad bancaria para que el operador determine los posibles fraudes masivos y así se atenúe el efecto que éstos conllevan. Esta gestión de alertas debe considerar que no se le asignen las mismas alertas a diferentes operadores, de manera que no se solapen en trabajo. Consultar las alertas que están pendientes, en gestión o que ya han sido gestionadas, de manera que el usuario tenga la posibilidad de ver todos los movimientos anómalos por entidad bancaria y como están siendo atendidos por sus operadores. Además, es necesario entonces la posibilidad de que el front pueda acceder indistintamente según configuración de la aplicación a servicios desarrollados en 2 Los bines son datos específicos de tarjetas por banco, estos son únicos para todas las entidades y reflejan el tipo de tarjeta (por ejemplo tarjeta dorada, platinum, etc) que provee la entidad a sus clientes. 16

17 tecnología COBOL-CICS o en el lenguaje con el que se implementen en este proyecto de pasantía. Adicionalmente, es indispensable que se incluya un módulo independiente de Ayudas para facilitar el manejo de la aplicación por parte de los usuarios, por lo que este módulo ha de ser desarrollado pensando en su uso tanto en la aplicación SUAF+ como en otras aplicaciones. Finalmente, el módulo requiere que los servicios al repositorio de datos sean desarrollados de manera independiente para ser utilizados por otras aplicaciones que requieran de ellos. Asimismo, las distintas funcionalidades producto de esta pasantía deben ser integradas en el front de SUAF por lo que es necesario que el diseño y el desarrollo del front para SUAF+ consideren especificaciones del sistema SUAF de tal manera que puedan ser integrados en un mismo producto. 17

18 ENTORNO EMPRESARIAL Capítulo 3 Sigmenta Business Technologies Sigmenta Business Technologies (SBT) es una subsidiaria de G. M. Advanced Security Technologies (GMAST) group, uno de los principales proveedores mundiales de sistemas de seguridad. GMAST ha participado en el desarrollo de muchos sistemas transaccionales que la han llevado a acumular experiencia y le han permitido penetrar en el complicado mundo del negocio financiero y así conocer lo importante que es alcanzar el delicado equilibrio requerido entre la riqueza de proceso y el tiempo de respuesta aceptable. Apoyado en esta experiencia y considerando los requisitos del negocio de sus clientes, GMAST desarrolló y patentó la Tecnología Transaccional Sincrónica/Asincrónica (TTSA )[17]. Basada en redes neuronales y sistemas expertos, esta tecnología se construyó con algoritmos exclusivos y esquemas de alta precisión, cuyo enfoque principal es ayudar al sistema transaccional de la institución a ejecutar procesos pesados con el alto contenido de inteligencia de negocio, mientras cumple con los estrictos requerimientos de tiempos de respuesta que los sistemas en línea deben contemplar. En marzo de 2003, GMAST respondió al éxito de sus productos y servicios en el sector financiero altamente competitivo y creó Sigmenta Business Technologies (SBT). Sigmenta, desde entonces, está a cargo de todo lo que se relaciona con innovación tecnológica única de GMAST, incluyendo productos, servicios, recursos humanos y técnicos, conocimiento, desarrollo y soluciones. Sigmenta se dedica exclusivamente a soluciones de negocios de comercialización y desarrollo para las instituciones financieras. Por otra parte, su 18

19 sistema de productos está enfocado a permitir que las instituciones emisoras de tarjetas puedan crear productos financieros nuevos y personalizados para clientes finales, mientras brindan nuevas dimensiones de seguridad al área de transacciones financieras. La estrategia de negocio de Sigmenta es desarrollar un conjunto de productos avanzados basados en tecnologías únicas. La Tecnología Transaccional Sincrónica/Asincrónica (TTSA ) permite una dirección sofisticada de alta velocidad y síncrona en el manejo de transacciones de pago y que puede utilizarse en diversas áreas. Esta tecnología puede ser aplicada, entre otras, a la prevención de fraude en medios de pago, a servicios únicos que se pueden ofrecer a los titulares de tarjeta y a los dueños individuales de la cuenta, y los nuevos modelos del negocio que pueden ser creados basados en las aplicaciones innovadoras para las tarjetas del pago y extenderse a otros sectores de la población como son los prepagados y no bancarizados. La empresa mantiene en su visión el poder ofrecer a las instituciones financieras, tecnología de punta que les permita crear rápidamente productos y servicios innovadores para acceder a sectores de la población tradicional y no tradicional, así como a empresas y gobierno; teniendo como visión convertirse en el proveedor principal de tecnologías y de soluciones innovadoras para el sector financiero. Entre los principales productos que mantiene la empresa podemos mencionar las siguientes soluciones de software: la solución financiera total para no bancarizados CNB, la solución antifraudes para medios de pago SUAF, el sistema de segmentación de condiciones de consumo para tarjetas crédito/debito SCAT y la solución total para prepago ebonus. [17] Finalmente, se presenta en el Anexo A la estructura organizacional de la empresa donde se resalta en amarillo la posición del pasante en la empresa. 19

20 MARCO TEÓRICO/TECNOLÓGICO Capítulo 4 En este capítulo se expone la información teórica y tecnológica que soporta el trabajo de pasantía. Estos conceptos relatados a continuación forman parte del diseño e implementación del proyecto. Básicamente, se comenzará a exponer la teoría para el desarrollo del sistema, ésta como se verá explica el modelo de programación por capas que es el centro de desarrollo de nuestra aplicación. Luego se enfatizará sobre cada una de las tecnologías importantes utilizadas para la implementación del sistema. 4.1 Arquitectura de software En el diseño de sistemas informáticos actual se suele usar las arquitecturas multinivel o Programación por capas. En dichas arquitecturas a cada nivel se le confía una misión simple, lo que permite el diseño de arquitecturas escalables que pueden ampliarse con facilidad en caso de que las necesidades aumenten [8]. El diseño más en boga actualmente es el diseño en tres niveles o en tres capas [3], el cual consiste en dividir los componentes del sistema en capa de presentación, capa de negocio y capa de datos. La primera capa, la de presentación, es la que ve el usuario, presenta el sistema al usuario, le comunica la información y captura la información del usuario dando un mínimo de proceso. Esta capa se debe comunicar únicamente con la capa de negocio. En el siguiente nivel tenemos la capa de negocio que es donde residen los programas que se ejecutan, recibiendo las peticiones del usuario y enviando las respuestas tras el proceso. Se denomina capa de negocio, e incluso de lógica del negocio, pues es aquí donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de presentación, 20

21 para recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos para almacenar o recuperar datos de él. Por último se encuentra la capa de datos donde residen los datos. Está formada por uno o más gestores de bases de datos que realiza todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio. En la figura 4.1 se puede ver la conceptualización de cómo se distribuyen los componentes de una aplicación de arquitectura de tres capas sobre los nodos físicos que participan en el flujo de datos [8]. La capa de presentación sería la que se muestra en la máquina del cliente, la capa de negocios estaría en el servidor principal de la aplicación y la capa de datos en un servidor de base de datos. Figura 4.1 Arquitectura de tres capas Todas estas capas pueden residir en un único ordenador, si bien lo más usual es que haya una multitud de ordenadores donde reside la capa de presentación. Las capas de negocio y de datos pueden residir en el mismo ordenador, y si el crecimiento de las necesidades lo aconseja se pueden separar en dos o más ordenadores. Así, si el tamaño o complejidad de la base de datos aumenta, se 21

22 puede separar en varios ordenadores los cuales recibirán las peticiones del ordenador en que resida la capa de negocio. Si por el contrario fuese la complejidad en la capa de negocio lo que obligase a la separación, esta capa de negocio podría residir en uno o más ordenadores que realizarían solicitudes a una única base de datos. En sistemas muy complejos se llega a tener una serie de ordenadores sobre los cuales corre la capa de datos, y otra serie de ordenadores sobre los cuales corre la base de datos. Uno de los más importantes patrones de la arquitectura de software es la programación por capas, la cual es un estilo de programación en la que el objetivo primordial es la separación de la lógica de negocios de la lógica de diseño. La ventaja principal de este estilo, es que el desarrollo se puede llevar a cabo en varios niveles y en caso de algún cambio sólo se ataca al nivel requerido sin tener que revisar entre código mezclado. Además, permite distribuir el trabajo de creación de una aplicación por niveles, de este modo, cada grupo de trabajo está totalmente abstraído del resto de niveles, simplemente es necesario conocer la API que existe entre niveles [4]. 4.2 Fundamentos Tecnológicos Para el desarrollo del sistema SUAF+ se tiene previsto utilizar varias tecnologías con las que cuenta su predecesor SUAF por lo que es necesario tener presente cuáles son y las ventajas que presentan para poder asegurar una implementación óptima en condiciones de desarrollo. Lo más importante en esta sección es la plataforma Java Platform, Enterprise Edition o Java EE [11], que es una plataforma de programación para desarrollar y ejecutar software de aplicaciones en el lenguaje de programación Java[5] con arquitectura distribuida de n niveles, basándose ampliamente en componentes de software modulares que se ejecutan sobre un servidor de aplicaciones. 22

23 La plataforma Java EE está definida por una especificación e incluye varias especificaciones de API, tales como JDBC [13], RMI [15], , JMS[14], Servicios Web, XML[21], etc. Java EE también permite configurar algunas especificaciones únicas para Java EE para componentes permitiendo al desarrollador crear una aplicación empresarial portable entre plataformas y escalable, a la vez que integrable con otras tecnologías. Estas especificaciones incluyen Enterprise JavaBean[10]s, servlets[16], JavaServer Pages[12] y varias tecnologías de servicios Web. Otros beneficios añadidos son, por ejemplo, que el servidor de aplicaciones puede manejar transacciones, seguridad, escalabilidad, concurrencia y gestión de los componentes desplegados, lo que implica que los desarrolladores pueden concentrarse más en la lógica de negocio de los componentes en lugar de en tareas de mantenimiento de bajo nivel. Es de resaltar que en esta plataforma se desarrollará todo el sistema propuesto, esto para aprovechar todas las ventajas que ya se discutieron anteriormente. Por otra parte, en Java EE se especifica el uso de un contenedor Web el cual es la implementación que hace cumplimiento del contrato de componentes Web [1] de la arquitectura J2EE. Este contrato especifica un entorno de ejecución para componentes Web que incluye seguridad, concurrencia, gestión del ciclo de vida, procesamiento de transacciones, despliegue y otros servicios. Un contenedor Web suministra muchos servicios así como también una vista federada de las APIs de la plataforma J2EE. Para el caso del desarrollo del sistema SUAF se utilizará el Sun Java System Application Server 7 [9] como contenedor Web porque cumple con un buen desempeño y robustez, además es el contenedor por excelencia con el que trabaja la empresa SBT. 23

24 Por otro lado, una de las especificaciones más significativas en el desarrollo del sistema son los Enterprise JavaBeans (EJB) [10] que son una de las API que forma parte del estándar de construcción de aplicaciones empresariales Java EE de Sun Microsystems. Su especificación detalla cómo los servidores de aplicaciones proveen objetos desde el lado del servidor que son, precisamente, los EJBs como por ejemplo comunicación remota utilizando CORBA [18], transacciones, control de la concurrencia, eventos utilizando JMS [14] (Java messaging service), servicios de nombres y de directorio, seguridad, ubicación de componentes en un servidor de aplicaciones. La especificación de Enterprise Java Bean define los roles jugados por el contenedor de EJB y los EJBs, además de disponer los EJBs en un contenedor [1]. El objetivo de los EJBs es dotar al programador de un modelo que le permita abstraerse de los problemas generales de una aplicación empresarial como son la concurrencia, las transacciones, la persistencia, la seguridad, etc. El hecho de estar basado en componentes permite que éstos sean flexibles y sobre todo reutilizables. Por otra parte, existen tres tipos de EJBs : los EJBs de entidad, los de sesión y los dirigidos por mensajes. Los EJBs de Entidad (Entity EJBs) tienen como objetivo encapsular los objetos del lado del servidor que almacena los datos. Los EJBs de Entidad presentan la característica fundamental de la persistencia y robustez en acceso a datos. Con respecto a los EJBs de Sesión (Session EJBs) son los que gestionan el flujo de la información en el servidor y generalmente, sirven a los clientes como una fachada de los servicios proporcionados por otros componentes disponibles en el servidor. Por último, los EJBs dirigidos por mensajes (Messagedriven EJBs) son los únicos beans con funcionamiento asíncrono, que se suscriben a un tema (topic) o a una cola (queue) usando el Java Messaging System (JMS) y los mismos se activan al recibir un mensaje dirigido a dicho tema o cola. 24