Construcción del módulo de gestión de alertas para el control de

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
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
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
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
Í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............................................................................................................15
2.1. OBJETIVOS GENERALES ................................................................................................................................16
ENTORNO EMPRESARIAL ..............................................................................................................................18
SIGMENTA BUSINESS TECHNOLOGIES ......................................................................................................................18
MARCO TEÓRICO/TECNOLÓGICO.............................................................................................................20
4.1 ARQUITECTURA DE SOFTWARE .......................................................................................................................20
4.2 FUNDAMENTOS TECNOLÓGICOS ....................................................................................................................22
ANÁLISIS................................................................................................................................................................27
5.1 PANORAMA GENERAL.......................................................................................................................................27
5.2 CASOS DE USO ...............................................................................................................................................30
FIGURA 5.1. DIAGRAMA DE CASOS DE USO DEL SISTEMA ................................................................................32
DISEÑO ....................................................................................................................................................................33
6.1 DECISIONES GENERALES ...............................................................................................................................33
6.2 ARQUITECTURA DEL SISTEMA ........................................................................................................................34
6.2.1 Sobre el Diseño Lógico...................................................................................................................34
6.2.2 Despliegue del Sistema............................................................................................................39
6.2.3 Sobre el Diseño Visual....................................................................................................................41
IMPLEMENTACIÓN ............................................................................................................................................42
7.1 CONFIGURACIÓN DEL AMBIENTE DE DESARROLLO .......................................................................................42
7.2 IMPLEMENTACIÓN DEL SISTEMA SUAF+.......................................................................................................43
7.2.1 Módulo Front Web: ..........................................................................................................................44
7.2.2 Módulo de Servicios de Acceso a Datos...................................................................................46
7.2.3 Módulo de Ayudas Online..............................................................................................................47
7.3 FASES DE PRUEBA...........................................................................................................................................50
7.4 PROBLEMAS ENCONTRADOS ...........................................................................................................................51
CONCLUSIONES Y RECOMENDACIONES ...............................................................................................53
8.1 CONCLUSIONES ...............................................................................................................................................53
8.2 RECOMENDACIONES ........................................................................................................................................54
REFERENCIAS.......................................................................................................................................................56
vi
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
ÍNDICE DE TABLAS
TABLA
TABLA
TABLA
TABLA
TABLA
TABLA
TABLA
TABLA
TABLA
7.1. CAPACIDADES EXIGIDAS VS FUNCIONALIDAD EN EL SISTEMA................ 50
A.1. PLANIFICACIÓN GENERAL DEL PROYECTO...............................................58
A.2. TABLA DE RIESGOS..............................................................................59
B.1. CASO DE USO: ATENDER ALERTAS PENDIENTES......................................61
B.2. CASO DE USO: CONSULTAR ALERTAS PENDIENTES..................................62
B.3. CASO DE USO: CONSULTAR ALERTAS GESTIONADAS...............................62
B.4. CASO DE USO: CONFIGURAR PARÁMETROS GENERALES...........................63
B.5. CASO DE USO: CONSULTAR AYUDAS EN LÍNEA........................................63
B.6. CASO DE USO: CONSULTAR LISTA DE ENTIDADES...................................64
viii
Í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+..........................................................35
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................................................................................. .....................65
FIGURA B.2. DIAGRAMA DE SECUENCIA PARA LA CONEXIÓN A LOS SERVICIOS DE
ACCESO A DATOS ................................................ ........................................67
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...................................................................................................... 73
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 ...................................... .79
ix
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
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
1990. 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
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
etiquetas desarrollado por el World Wide Web Consortium.
xii
de
Capítulo
1
INTRODUCCIÓN
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
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
Capítulo
PLANTEAMIENTO DEL PROBLEMA
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
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
bines2, 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
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.
2
16
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
Capítulo
3
ENTORNO EMPRESARIAL
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
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
Capítulo
MARCO TEÓRICO/TECNOLÓGICO
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
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
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
La plataforma Java EE está definida por una especificación e incluye varias
especificaciones de API, tales como JDBC [13], RMI [15], e-mail, 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
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
En el presente proyecto se utilizará los EJBs de entidad para garantizar la
persistencia y los EJBs de sesión como fachada para el acceso a los servicios de
acceso a datos.
Otra de las tecnologías importantes utilizadas en el sistema fue los Java
Server Pages (JSP) [12] que permiten generar contenido dinámico para Web, en
forma de documentos HTML [20], XML [21] o de otro tipo. Esta tecnología es un
desarrollo de la compañía Sun Microsystems. La especificación JSP 1.2 fue la
primera que se liberó y en la actualidad está disponible la especificación JSP 2.1.
JSP fue la base para el desarrollo de las interfaces de usuario de la aplicación.
Las JSP's permiten la utilización de código Java mediante bloques de código
incrustado en páginas Web. Además es posible utilizar algunas acciones JSP
predefinidas mediante etiquetas. Estas etiquetas pueden ser enriquecidas mediante
la utilización de librerías de etiquetas (TagLibs o Tag Libraries) externas e incluso
personalizadas.
El funcionamiento general de la tecnología JSP comienza cuando el servidor
de aplicaciones interpreta el código contenido en la página JSP para construir un
Servlet, cuya salida será un documento estático, típicamente HTML, que se
presentará en la pantalla del navegador del usuario. Un Servlet es un programa que
se ejecuta en un servidor y cuyo uso más común es generar páginas Web de forma
dinámica a partir de los parámetros de la petición que envíe el navegador Web.
Por último, la tecnología JDBC [13] que es el acrónimo de Java Database
Connectivity, es 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.
25
El API JDBC se presenta como una colección de interfaces Java y métodos de
gestión de manejadores de conexión hacia cada modelo específico de base de datos.
Un manejador de conexiones hacia un modelo de base de datos en particular es un
conjunto de clases que implementan las interfaces Java y que utilizan los métodos
de registro para declarar los tipos de localizadores a base de datos (URL) que
pueden manejar. Para utilizar una base de datos particular, el usuario ejecuta su
programa junto con la librería de conexión apropiada al modelo de su base de
datos, y accede a ella estableciendo una conexión, para ello provee un localizador a
la base de datos y los parámetros de conexión específicos. A partir de cuando se
conecta el usuario puede realizar cualquier tipo de tareas con la base de datos a las
que tenga permiso: consultas, actualizaciones, creación y eliminacion de tablas,
ejecución de procedimientos almacenados en la base de datos, etc.
Este tipo de conectividad a base de datos será de mucha utilidad para
implementar consultas alternas a las bases de datos en el módulo de servicios de
acceso a datos.
26
Capítulo
5
ANÁLISIS
En este capítulo se describen las actividades realizadas durante el inicio del
desarrollo del Sistema SUAF+. Para el análisis se desarrollaron diversas actividades
como por ejemplo el estudio del panorama general del sistema y levantamiento de
requerimientos donde se determinará cuáles requerimientos funcionales y no
funcionales serán necesarios para que el módulo cumpla con los objetivos deseados
por la compañía. Además se tuvo un lapso de estudio de las herramientas de
tecnología a ser utilizadas.
En esta fase de análisis se hizo una previa planificación a seguir para el
desarrollo del sistema que se puede ver en el Apéndice A.1. De igual manera, se
construyó una tabla de riesgos posibles sobre la planificación y el proceso de
implementación del proyecto que se pueden ver en el Apéndice A.2.
5.1 Panorama general
SUAF+ es una herramienta que consta de varios módulos. Para este proyecto
de pasantía se ha escogido el desarrollo del módulo de gestión de alertas con los
respectivos servicios a los repositorios de datos, el módulo de ayudas online, y el
desarrollo de los diversos componentes de interacción entre los distintos módulos.
Para el entendimiento de cómo debe operar el módulo es necesario conocer
las restricciones del sistema. La entidad bancaria no debe esperar por el sistema
para seguir despachando dinero a las peticiones, sino más bien el sistema recaba
los datos de las transacciones y mediante algunos filtros se emiten alertas que
deben ser presentados a los operadores para que las gestionen.
27
En cuanto a la gestión de alertas, no puede haber solapamiento en la
operación entre los operadores. Es decir, un operador no puede atender las alertas
que actualmente están siendo atendidas por otro operador. Los operadores tienen
un límite máximo de gestión de una alerta dada. Es decir, un operador no puede
tener retenida una alerta por tiempo ilimitado por lo que si no ha concluido de
gestionar la alerta en el lapso dado se le retira la gestión de esa alerta. Esto para
evitar sabotajes o caídas del sistema de cada operador. Es de resaltar que, la
atención de alertas es realizada por un operador y la consulta de alertas serán
hechas
sólo
por
los
supervisores.
Con
respecto
a
las
funcionalidades
de
parametrización general sólo puede ser llevada a cabo por los administradores del
sistema.
Por último, aunque el operador esté en el front de SUAF se le debe presentar
una alerta si hay alertas por atender en SUAF+
Por otra parte, un problema encontrado en el sistema actual de conexión de
SUAF es que los tiempos de desarrollo de front para nuevas funcionalidades que se
comunican con COBOL-CICS [7] se hacen muy largos, porque no hay una
configuración dinámica que permita ayudar al desarrollo. Por lo tanto, es deseable
que el grupo de trabajo diseñe un componente que conste de un manejo dinámico y
eficiente para la conexión a los servicios de COBOL-CICS.
Entre las características que el sistema debe presentar de acuerdo a los
requerimientos establecidos por los clientes está el manejo amigable al usuario. Es
decir, es necesario que la herramienta sea sencilla de usar ya que los usuario
pasaran gran parte del tiempo en ellas y necesitan rapidez al momento de
manipularla. El cliente desea que el personal de SUAF+ se acostumbre fácilmente a
la nueva herramienta, para ello se debe contemplar una interfaz sencilla, manejo
amigable, que permitan la rápida adaptación de los usuarios al sistema.
28
De igual forma el sistema debe ser flexible a distintas configuraciones de
interfaz por lo que se debe tener esto en cuenta a la hora de diseñar la estructura
de la interfaz.
Además, el desarrollo debe contemplar que la herramienta sea escalable y de
poder soportar inserciones de nuevas funcionalidades en la gestión de alertas de
manera que el producto pueda ir creciendo según los requerimientos.
Asimismo, es necesaria una ayuda en línea, así que la herramienta contará
con páginas de ayuda especializadas para cada una de las funcionalidades. Éstas
sirven como una referencia rápida para el usuario en caso que no comprenda alguno
de los elementos de navegación de la página o la funcionalidad de la misma.
También se desea que los sistemas SUAF y SUAF+ se puedan manejar desde
un mismo portal, por lo que se espera la integración de las dos aplicaciones y
desarrollo de SUAF+ que incluya un fácil acoplamiento con SUAF. La integración
tiene como meta que el producto pueda ser comercializado para quien lo requiera
sin el problema de la adquisición de costosas nuevas licencias de terceros, y que el
sistema se pueda distribuir con las viejas licencias si ya los clientes las tienen, razón
por la que se espera un desarrollo modular de la conexión a servicios a repositorios,
para que se pueda escoger la plataforma de servicios que se requiera.
Finalmente, se quisiera minimizar el tiempo de desarrollo para nuevas
funcionalidades hacia servicios en COBOL-CICS, lo que hace pensar en un desarrollo
de un módulo de conexión a COBOL-CICS de manera dinámica y eficiente, para
facilitar el desarrollo y mejorar el sistema en escalabilidad.
Como característica adicional, la aplicación a nivel de front end se debe poder
presentar multi-idioma pues así esta implementado SUAF por lo que se debe
contemplar este requerimiento.
29
5.2 Casos de Uso
Los casos de uso definen la funcionalidad pura del sistema y derivan de los
requerimientos funcionales del proyecto. Asimismo, sobre cada caso de uso actúan
los usuarios que harán tendrán disponibilidad de efectuar dichas funcionalidades.
Aquí se hará una descripción simple de los usuarios del sistema y de los casos de
uso del mismo según los usuarios implicados.
En la figura 5.1, se observa el diagrama de casos de uso de la aplicación.
Como se ve en el sistema se contemplan tres tipos básicos de usuarios: operadores,
supervisores y administradores. Los operadores son los usuarios que atienden de
alertas en el sistema. Por otra parte, los supervisores son los que suelen hacer
inspección de cómo están trabajando los operadores y revisan el estado de las
alertas atendidas y por atender. Por último, los administradores que configuran el
sistema en general y se encargan de operaciones de mantenimiento del sistema.
Los casos de uso que se observan en la figura 5.1 están agrupados por
usuario del sistema, lo que deja un panorama claro de lo que debe hacer cada
integrante del sistema.
Se puede discernir que existen tres casos de uso que pueden ejecutar todos
los integrantes del sistema estos son las consultas listado de entidades, ayudas en
línea y parámetros generales. Se tiene entonces que consultar lista de entidades es
el caso de uso que permite a todos los usuarios obtener el conjunto de
identificadores de entidades para acceder a otras funcionalidades sobre ellas. Luego
consultar ayudas en línea permite a todos los usuarios obtener referencia rápida en
caso que no se comprenda alguno de los elementos del sistema. Y por último en
este grupo de casos de uso se tiene a consultar parámetros generales, el cual
brinda información del sistema a todos los usuarios del mismo para que se pueda
informar a los administradores de una posible mala configuración que deban
atender.
30
En el caso de los usuarios de tipo operador sólo se le asigna el caso de uso
Atender alertas pendientes, pues es una funcionalidad que consiste básicamente en
asignarle al operador las alertas pendientes de una entidad en particular para que
pueda procesarlas. Este caso de uso incluye a su vez el caso de uso de procesar
alertas, el cual consiste en que el operador envíe al servidor la información
procesada de una o más alertas que ya han sido gestionadas por él.
En cuanto a los supervisores, sólo tiene las funciones de inspeccionar el
estado de la gestión de alertas por lo que los casos de uso asociados a este usuario
son consultar alertas pendientes y alertas gestionadas. Las consultas de alertas
pendientes de una entidad, es un caso de uso que corresponde a la actividad de
revisión de las alertas que se encuentran como no atendidas o las que están siendo
atendidas, para poder verificar si están siendo gestionadas por los operadores. Por
otra parte, las consultas de alertas gestionadas de una entidad, es un caso de uso
exclusivo para los supervisores del sistema y corresponde a la actividad de
supervisión de las alertas que ya fueron procesadas por los operadores de manera
de comprobar datos de alertas y poder verificar como han sido gestionadas por los
operadores.
Para culminar con los casos de uso, se tiene el caso de uso del administrador
del sistema a desarrollar, configurar parámetros generales. Este caso de uso
solamente debe ser asignado a los administradores del sistema pues tienen la
potestad de configurar la carga automática de bines o datos específicos de tarjetas
por banco, el lapso de espera para anular una alerta en gestión, 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.
31
Figura 5.1. Diagrama de Casos de Uso del sistema
La descripción más detallada de estos casos de uso puede ser vista en el
Apéndice B.
32
Capítulo
6
DISEÑO
En este capítulo se describen las actividades asociadas al diseño de la
arquitectura general que tendrá el sistema a desarrollar, por ello es la fase más
delicada del proyecto.
6.1 Decisiones Generales
Para esta fase se necesitaron tomar ciertas decisiones importantes para el
cumplimiento de los requerimientos de desarrollo. Las primeras decisiones de
diseño se basaron en los objetivos generales del proyecto y en las restricciones del
mismo.
Por decisión general, el diseño principal de interfaz de usuario es la misma del
diseño del sistema SUAF ya que para la integración de los dos sistemas el cliente
prefiere que se vean como si fuese uno solo.
Para la conexión con los servicios de repositorios de datos se creará un
módulo de conexión general que conecte los módulos de front con los módulos de
servicios de repositorio de manera transparente.
33
6.2 Arquitectura del Sistema
A continuación se describirá el modelado de la arquitectura del sistema a
desarrollar utilizando varias herramientas que brinda el lenguaje UML[8].
6.2.1 Sobre el Diseño Lógico
Aquí se expone el modelo conceptual del módulo de gestión de alertas, el cual
describe los conceptos más importantes y sus respectivas relaciones los unos con
los otros. La figura 6.1 muestra el modelo conceptual del módulo de gestión de
alertas. Se puede observar en la figura que las entidades bancarias son el centro de
la gestión, pues sobre ellas es que se producen las alertas de fraude y sobre ellas
estarán estas alertas pendientes o gestionadas.
Figura 6.1. Modelo Conceptual del módulo de gestión de alertas
Por otro lado, la estructura del diseño del sistema a desarrollar se basa
principalmente en dos módulos: Front Web y Servicios de Acceso a Datos. Estos
módulos comprenden varias capas del sistema como lo son las capas de
presentacion, Negocio y conexión a Acceso de Datos en el caso del módulo Front
Web y JavaServicios para el Módulo de Servicios de Acceso a Datos.
34
En el diagrama de la Figura 6.2 se observa las distintas capas representadas
dentro de su correspondiente módulo. Estas capas están dispuestas según el flujo
de datos en el sistema, y como se ve también la organización de los módulos
cumple con esta norma.
Figura 6.2.Capas de la Aplicación SUAF+.
En el desarrollo de cada una de las capas se ha dispuesto una manera
modular de diseño que independice cada capa y que a su vez haga transparente la
comunicación entre ellas minimizando el impacto que pueda tener un cambio
esencial en alguna de las capas sobre las demás.
35
Cada una las capas según los módulos cumple un objetivo especifico dentro
de la arquitectura de programación por capas. Estas son explicadas a continuación.
Primero, la capa de Presentación es la capa con la cual interactúa el usuario
en el Front Web, lo que comúnmente se denomina interfaz de usuario.
Siguiendo con la siguiente capa, la de lógica de Negocio es la capa que recibe
la petición del usuario desde la capa de presentación y se encarga de darle manejo
a dicha petición en el Front Web. Se han establecido una serie de manejadores
dentro de esta capa que se encargan de distribuirse la carga de las peticiones según
la funcionalidad que el usuario este solicitando.
La capa de Conexión a Servicios de Acceso a Datos en Core es más bien un
submódulo que surge de la necesidad de que la aplicación en el Front Web pueda
interactuar con distintas implementaciones de Servicios de Acceso a Datos a Core
(en COBOL-CICS [7] o JAVA en nuestro caso), por lo que es considerablemente
importante que el diseño de esta capa se haga de la manera más dinámica posible.
Por último la capa de Servicios (Java) de Acceso a Datos en Core: esta capa
es la que maneja las peticiones de datos a Core, accede a los datos y los manipula
según las peticiones retornando los datos procesados. Además en esta capa se
maneja la concurrencia de acceso de usuarios a los datos para garantizar la
integridad de los mismos, como es el caso de la atención de alertas donde es
necesario bloquear el acceso a otros usuarios por cierto tiempo estimado. Este
módulo se desarrollará completamente independiente del módulo Front Web de
manera que pueda ser utilizado por otro módulo si se necesita.
36
Ahondando más en el diseño, la Figura 6.3 muestra los paquetes de cada
capa mencionada anteriormente separados por los módulos en los que se clasifican
las capas.
Figura 6.3. Modelo de Diseño: Paquetes
En este diseño se expone claramente que se debe tener un orden de
paquetes según cada capa que se esté desarrollando, esto para ahorrar problemas
de identificación de clases y evitar el posible solapamiento de archivos en el mismo
directorio lo que traería problemas de implementación y pruebas.
37
Esto hace separar más los conceptos en los paquetes los cuales se irán
describiendo según su funcionalidad y el conjunto de clases que encierran dentro de
cada módulo a desarrollar.
Dentro del módulo Front Web que será implementado en su totalidad bajo el
paquete <com.swd.cfp.fr> se puede también ver que se han especificado subpaquetes del mismo para las capas que contiene. Estas capas son la de
presentación, negocio y conexión a de acceso a datos.
La capa de presentación del módulo Front Web se diseñó bajo el paquete
<com.swd.cfp.fr.fachada> y estará asignado a contener las clases que gestionan las
peticiones de la capa de presentación enviando la respectiva petición a la siguiente
capa.
La capa de Negocio tiene su diseño bajo el paquete <com.swd.cfp.fr.logica> y
que tiene a su vez dos sub-paquetes más: el <com.swd.cfp.fr.logica.beans> que es
un paquete que contiene los contenedores que se usaran para transportar los datos
de una capa a la otra; y el <com.swd.cfp.fr.logica.manejadores> que es un paquete
que gestionará todo lo correspondiente a la petición de la capa de presentación hará
la petición de acceso a datos y responderá nuevamente a la capa de presentación.
Por último, para el módulo de Front Web se tiene la capa de Conexión de
Acceso
a
Datos
en
Core
quien
tiene
su
diseño
sobre
el
paquete
<com.swd.conexioncore> el cual es un paquete que contiene todas las clases que
hacen posible la conexión a los servicios de acceso a datos de forma transparente.
Luego, se tiene que el módulo de Servicios de Acceso a Datos en Java tendrá
como paquete principal a <com.swd.cfp.jservicios>, éste también contemplará
varios sub-paquetes. Estos son: <com.swd.cfp.jservicios.fachada> que es el
paquete que contiene la fachada de comunicación hacia los servicios que se
implementan en este módulo. Siguiendo con <com.swd.cfp.jservicios.servicios> que
38
contiene todas las clases que proveen de los servicios que manejan los datos de la
petición, procesan los mismos y devuelven la respuesta a la petición. Finalizando
con <com.swd.cfp.jservicios.accesodatos> que será el paquete que contiene todas
las clases que proveen la conexión a los repositorios de datos
Adicionalmente, se encuentran tres paquetes genéricos fuera de los dos
módulos principales. Estos son paquetes reutilizables que contienen clases que
pueden ser utilizadas a lo largo del sistema, evitando así la redundancia de código.
El primero de ellos es <com.swd.util> que contiene las clases genéricas de
conversión de datos como fechas y montos y es donde están las clases encargadas
de acceder a las propiedades del sistema. El segundo de los paquetes es
<com.swd.excepciones> el cual es necesario pues en el se definen las clases
manejadoras de errores o excepciones del sistema. Por último, se encuentra el
paquete <com.swd.ayudas> el cual será el que contenga todas las clases
necesarias para el módulo de ayudas en línea.
6.2.2 Despliegue del Sistema
En la figura 6.4 se observa los nodos físicos que participan en el flujo de
datos en el sistema. Esto es, desde que el usuario hace una petición desde su
computador pasando el mensaje al servidor Web quien hará la petición a un
servidor de conexión de datos hasta gestionarse el acceso a la base de datos. Luego
se producirá el proceso inverso para hacer llegar al cliente la respuesta a su
petición.
39
Figura 6.4. Nodos del sistema
En la figura 6.5 se puede ver específicamente los componentes de software
que interactúan en el flujo de datos sobre cada uno de los nodos físicos.
Figura 6.5. Componentes del sistema en los nodos donde se ejecutan.
Particularmente se sigue una lógica sencilla del modelo Cliente Servidor de
tres capas, aunque con un nodo más por estar el servidor de servicios de acceso a
40
datos. La necesidad de este servidor de acceso a datos es básicamente por
seguridad de los datos, aunque los tres servidores dispuestos en la imagen anterior
cumplen funciones distintas, es muy probable que sea el mismo servidor.
6.2.3 Sobre el Diseño Visual
Como ya se mencionó el diseño general de las pantallas deben ir de acuerdo
al diseño de SUAF pues es requerimiento poder integrar los dos sistemas y que no
existan discordancias entre uno y otro.
Por otra parte, se diseñaron algunos bocetos gráficos de la mayoría de las
funcionalidades a implementar. Estos fueron presentados al cliente para garantizar
que la disposición de los elementos estuviese acorde con sus requerimientos. Estos
bocetos están incluidos en el apéndice D, así como también las pantallas finales de
la aplicación.
41
Capítulo
7
IMPLEMENTACIÓN
En este capítulo se describen todas las actividades realizadas con respecto a
la construcción del sistema.
Durante esta fase se describen las herramientas utilizadas, la implementación
del sistema, el estado actual del sistema y los problemas encontrados en esta fase.
7.1 Configuración del ambiente de desarrollo
El ambiente de desarrollo principal se centra en las estaciones de trabajo
asignados, los cuales constan del sistema operativo Microsoft Windows XP
Professional.
Como gran parte del sistema a desarrollar se encuentra en el lenguaje Java
se necesitaba una herramienta que ayudara al desarrollador a construir las clases y
paquetes necesarios de manera efectiva. Para ello se decidió hacer uso del IDE
NetBeans 5.5, que es una herramienta muy potente para construir proyectos del
tipo J2EE, además tiene una gran capacidad de conexión a los servidores de
aplicaciones y servidores Web desde la misma herramienta, lo cual provee gran
agilidad a la hora de montar las funcionalidades que se van desarrollando en los
servidores de pruebas.
Como existen varios desarrolladores implementando distintas partes del
sistema se decidió utilizar una herramienta de control de versiones (cvs), para ello
se recurrió a la aplicación CVSNT pues es de fácil uso, instalación y configuración lo
que ahorra el tiempo al momento de aprender a utilizar la herramienta.
42
Como herramienta de ayuda para el desarrollo Web se usaron Macromedia
Dreamweaver 8, que es una herramienta de diseño Web muy útil pues tiene una
extensa biblioteca de información de referencia de varios lenguajes y tópicos para el
desarrollo Web. Por otro lado también se utilizó Eclipse Palette 2.0.20, que es un
selector o capturador de colores, que permite copiar cualquier tono que se vea en
cualquier pixel de nuestro monitor. A partir del tono capturado, se puede generar
una paleta de tonos similares.
Como era necesario agilizar las pruebas de las funcionalidades en los
servidores, se prefirió hacer una instalación del servidor Sun Java System
Application Server 7 en la estación de trabajo del pasante para esas pruebas
inmediatas que se hacen necesarias hacer sin tener que ir a otra máquina.
También fue necesario instalar la herramienta Adobe Acrobat 7.0 Professional
para la creación de los documentos en formato PDF que son necesarios para el
módulo de ayudas de la aplicación.
Para comprobar que la páginas Web que se están desarrollando son
compatibles con la mayoría de los navegadores, además del Internet Explorer para
el que debe estar certificado obligatoriamente el sistema, se decidió instalar los
navegadores Mozilla Firefox, Netscape y Opera, los cuales junto con el IE forman
gran parte de los navegadores que hay actualmente en el mercado.
7.2 Implementación del Sistema Suaf+
El sistema se decidió implementar en dos partes principales, la primera parte
se dedicaría enteramente a desarrollar todo lo relacionado con el módulo Front Web,
luego de esto se desarrollaría la segunda parte donde se dedicaría a desarrollar el
módulo de Servicios de Acceso a Datos de SUAF+. En esta sección se explicará el
desarrollo de estas partes.
43
7.2.1 Módulo Front Web:
Para el módulo de front Web se había hecho un diseño de tres capas las
cuales se desarrollan de manera modular para que la comunicación entre ella fuese
totalmente transparente. Estas capas son la capa de presentación, la capa de lógica
de negocio y la sub-capa de conexión a servicios de acceso a datos en core.
La
implementación de estas capas se describen a continuación.
En la capa de presentación se implementó todo lo relacionado con la interfaz
de usuario.
Como es un sistema que debe ser totalmente compatible con SUAF se decidió
tomar las especificaciones de éste para desarrollar SUAF+. El desarrollo las páginas
Web se manejó con el lenguaje JSP[12] en las páginas dinámicas y se usó el
lenguaje HTML en los documentos que no requieren de mayor dinamismo. El
lenguaje JavaScript [2] fue útil para proveer a los documentos de mayor
funcionalidad de cara al usuario, para hacerlas más dinámicas a la hora de validar
datos que el usuario ingrese en el sistema, lo cual hace más ágil la funcionalidad
pues como los datos se validan en la misma máquina del cliente, éste no tiene que
esperar a que los datos vuelvan del servidor cuando hay un error en ellos.
Para dar un manejo eficiente de la apariencia de la aplicación de cara al
usuario se empleó de las hojas de estilo (CSS) [19] que permiten cambiar la
apariencia del sistema sin tener que modificar las páginas Web. Las “pantallas”
finales se pueden observar en el apéndice D.
El servidor escogido para esta aplicación fue el Sun Java System Application
Server 7 [9] que provee la empresa Sun Microsystems, el cual consta de una gran
robustes en el manejo de concurrencia de usuarios.
44
Para la comunicación de esta capa con la capa de lógica de Negocio se
implementó una clase neurálgica que actúa de puente entre una capa y la otra, lo
que hace totalmente transparente las implementaciones que existan en la capa de
Negocio haciendo el desarrollo de las capas enteramente modulares.
Luego, en la capa de lógica de negocio se programó todo lo relacionado con la
lógica de la aplicación.
Para la construcción de esta capa se usó el lenguaje Java el cual provee
grandes ventajas en el desarrollo de sistemas como lo son modularidad, flexibilidad
y reusabilidad, junto con la gran cantidad de librerías de utilidad que existen de este
lenguaje lo que ahorra muchísimo en desarrollo de aplicaciones. Se empleó Java en
su versión J2SE 1.4 para la realización de las clases y J2EE 1.3 para la construcción
de los paquetes de instalación.
Esta capa se desarrolló siguiendo el diseño de paquetes hecho en la fase de
diseño. Los datos que mandan y esperan estas clases con respecto a la capa de
conexión a servicios de acceso a datos se manejan a través de estructuras de tipo
Hash. Estos datos se procesan y se incluyen en los contenedores tipo bean para
regresarlos al la capa de Presentación.
Por otro lado, en la capa de conexión a servicios de acceso a datos en Core se
presenta la implementación de la conexión a los servicios de datos.
En esta capa se emplea Java J2SE [5] para el desarrollo de las clases,
recurriendo a la ‘Reflexión’ para resolver el problema de la conexión a distintas
implementaciones de servicios de acceso a datos pues es una de las grandes
ventajas que ofrece a los programadores el lenguaje Java, ya que para conectarse a
una o a otra implementación de los servicios no se necesita reescribir y recompilar
el código dependiendo del servicio a utilizar, pues se toma el tipo de conexión de
una variable en un archivo externo de propiedades del sistema (property) el cual
contiene los datos de conexión y se hace la invocación al servicio configurado sin
45
necesidad de importarse clases innecesarias. Con esto dependiendo de los datos de
conexión el módulo hará reflexión hacia las respectivas interfaces que harán el
enlace a los servicios correspondientes.
Una parte delicada para la conexión a los Servicios en COBOL-CICS es que se
tiene que hacer un manejo eficiente y dinámico para las nuevas funcionalidades o
modificaciones en las existentes que surjan de ese lado. Para solucionar ese
problema se implementó en esta capa un manejo dinámico de la conexión a este
tipo de servicio donde la descripción de los parámetros de entrada y de salida se
leen desde archivos XML[21] situados en el servidor Web, los cuales proveen toda la
información para poder hacer llamada a estos servicios en COBOL-CICS a través de
una gran cadena de caracteres donde van los campos de los parámetros de entrada
y salida según se describan en los XML. Este manejo quita un buen lapso de retraso
de los tiempos desarrollo en el sistema para las nuevas funcionalidades o las
modificaciones a las existentes.
7.2.2 Módulo de Servicios de Acceso a Datos
En este módulo se implementará todo lo relacionado con los servicios de
acceso a datos del sistema.
Se sirvió de Java en su versión J2SE 1.4 para el desarrollo de las clases y
J2EE 1.3 para la construcción de los paquetes de instalación, sobre todo se hará uso
de los EJB2.0 provistos por J2EE 1.3 que proporcionan entre otras cosas gran
capacidad de manejo de concurrencia de usuarios con los EJB de sesión y un buen
manejo de acceso a las bases de datos a través de los EJB de entidad pues brindan
confiabilidad y buen desempeño, además se hace uso también de JDBC para
algunas funcionalidades que no son soportadas por EJB2.0 como count, max, min y
otras funcionalidades de SQL que son necesarias tener.
46
Este módulo consta de una interfaz de acceso, la cual hace la distribución de
las peticiones a los respectivos servicios. Esta interfaz esta implementada en EJB de
sesión al que debe referenciar el módulo que interactúe con ella. Cada servicio
esperará un contenedor de datos de tipo Hash que se retornará con los datos de
salida.
Para el acceso a los repositorios de datos se hace uso de los EJB de entidad
pues proveen de gran confiabilidad a la hora
de acceder a los datos de manera
concurrente, estos EJB son configurados por archivos XML de despliegue propios
para estas funcionalidades y necesitan de parámetros especiales que hay que añadir
en la configuración del servidor.
7.2.3 Módulo de Ayudas Online
Aquí se desarrolló también el módulo de Ayudas que está totalmente en la
capa de presentación. Este módulo consta de un grupo de páginas en JSP y HTML y
elementos como archivos JS, CSS [17], imágenes y documentos pdf, que están
reunidos en un paquete independiente de la aplicación, esto hace que cualquier
aplicación pueda utilizarlo siguiendo unos simples pasos de instalación.
El módulo de ayudas consta principalmente de una sección de búsqueda por
índice de palabras y la sección principal donde se muestra el documento de ayuda
solicitado. Este documento solicitado es de formato PDF y se almacena en un
directorio específico del servidor, al igual que el archivo donde se almacena el índice
de búsqueda.
El módulo actúa como una ventana de tipo emergente que será invocada con
una función en JavaScript provista por un archivo JS que se incluye en el módulo de
Ayudas. Para hacer esta llamada es necesario agregarle una clave de búsqueda, la
cual sirve para buscar el documento en el servidor y mostrarlo en la sección
principal de la ventana emergente de ayudas.
47
Para las búsquedas por índice de palabras se diseñó un esquema por índices
en un archivo de propiedades del sistema. En el lenguaje Java existen muchas
librerías para el manejo de estos archivos, sobre todo en la búsqueda de palabras
clave pues las mismas son almacenadas en una estructura de tipo Hash lo que
agiliza esta búsqueda. Teniendo esta facilidad sobre estos archivos se asigna las
palabras a los documentos de búsqueda asociados o viceversa y luego se busca los
títulos de estos documentos para mostrarlos en los resultados de la búsqueda para
que puedan ser seleccionados por el usuario y mostrados entonces en la sección
principal para visualizar el documento.
En la figura 7.1 se presenta la pantalla principal del módulo de ayudas.
Figura 7.1 Ventana de Ayudas en Línea de la aplicación
48
El diseño de la página se basó en un compendio de páginas de ayuda de
aplicaciones entre las cuales resaltaba más la disposición del elemento de búsqueda
en el área superior izquierda y la disposición de la lista de resultados por debajo de
la primera mencionada dejando todo el espacio restante para mostrar el documento
que se requiera.
Para mayor comodidad del usuario se dispuso de un elemento que oculta la
barra izquierda lo que deja mayor rango de visión del documento como se puede
ver en el ejemplo de la figura 7.2.
Figura 7.2. Ventana de Ayudas en Línea de la aplicación con barra minimizada
49
7.3 Fases de Prueba
Las pruebas para el sistema tuvieron como enfoque cada uno de las
funcionalidades del sistema así como los requerimientos para el mismo. Para la
realización de estas pruebas fueron utilizados métodos muy simples que sólo
incluyeron la comprobación por parte del cliente que los requerimientos impuestos
al sistema eran aceptables. Esta comprobación puede ser vista en la tabla 7.1 en el
estado actual del sistema.
Capacidades exigidas
Interfaz para que el personal de
SUAF+ se acostumbre fácilmente
a la nueva herramienta.
Que los sistemas SUAF y SUAF+
se puedan manejar desde un
mismo portal.
Que el producto pueda ser
comercializado para quien lo
requiera sin el problema de la
adquisición de costosas nuevas
licencias de terceros.
Funcionalidad en el sistema
Si, Interfaz sencilla, manejo amigable, Ayudas Online.
Si.
Si, Desarrollo en ambiente abierto (JAVA).
Que el sistema se pueda
distribuir con las viejas licencias.
Si, soporte para varias implementaciones de servicios,
incluyendo la anterior.
Minimizar el tiempo de desarrollo
para nuevas funcionalidades
hacia servicios en COBOL-CICS.
Si.
Funcionalidades totalmente
operativas.
Si.
Tabla 7.1. Capacidades exigidas vs Funcionalidad en el sistema
50
7.4 Problemas encontrados
Para
el
desarrollo
del
sistema
se
encontraron
varios
problemas
de
implementación y configuración del sistema.
Además de la dificultad de aprender el manejo de los componentes EJB2.0 se
tuvo problemas al hacer ciertas consultas a base de datos pues no se soportan
funciones nativas de ORACLE como count, max, min, avg ,etc lo que limitaba al
momento de tener que hacer ciertas consultas especificas en el módulo de servicios.
Aunque estas limitaciones se resuelven en versiones posteriores de los EJB, la no
compatibilidad de otras versiones con la versión de J2EE 1.3 hizo decidir seguir
usando los EJB2.0. Para resolver esta limitación fueron utilizadas accesos a la base
de datos a través de funcionalidades provistas por JDBC que sí facilitaban el manejo
de las funciones antes mencionadas.
Otro problema encontrado fue la configuración del aplicativo desde la
herramienta Netbeans pues esta soporta solamente configuraciones desde las
versiones de J2EE 1.4 y EJB2.1 y EJB3, y las demás herramientas para hacerlo en
las versiones anteriores se encuentran descontinuadas y ya no se consiguen. Para
resolver este problema se decidió hacer los paquetes de la aplicación en la versión
J2EE1.4 y EJB2.1 en el IDE NetBeans y luego se hicieron los cambios para la versión
anterior a mano.
Otro problema que surgió fue cómo hacer que el módulo de conexión a
servicios de acceso a datos fuese totalmente dinámico, pues para nuevas
implementaciones de servicios se debía recompilar el módulo para que atendiera a
estas nuevas implementaciones. Esto se resolvió utilizando reflexión de Java y un
archivo de propiedades donde se encuentran los datos de conexión a los servicios
que se desean usar.
Para el módulo de ayudas se había establecido que los archivos PDF se
almacenaran dentro del paquete de la aplicación tal como se guardan las páginas
51
HTML, pero esto hizo ver que el paquete de instalación se haría excesivamente
grande a medida que se agregaran más documentos PDF de ayuda lo que incurre en
hacer más pesado el despliegue de la aplicación en el servidor. Para ello se diseño
una nueva estructura para la búsqueda de los documentos de ayuda. Los
documentos serán almacenados en un lugar cualquiera del servidor y su ruta será
establecida en un archivo de propiedades de la aplicación, así se podrá hacer la
instalación de la aplicación a parte de los documentos de ayuda y estos serán leídos
en tiempo de ejecución y desplegados en la máquina del cliente como si estuviesen
dentro del paquete de la aplicación.
52
Capítulo
CONCLUSIONES Y RECOMENDACIONES
8
8.1 Conclusiones
El proyecto de pasantía permitió construir satisfactoriamente el módulo de
gestión de alertas el cual permite a los usuarios hacer la debida atención de alertas
de fraude masivo contra entidades bancarias, permitiendo la posterior supervisión y
la correspondiente configuración general del sistema. El proceso de desarrollo se ha
llevado a cabo con éxito en el tiempo estimado de duración de la pasantía.
Todos
los
objetivos
de
la
pasantía
fueron
cubiertos
completamente,
incluyendo aquellos requerimientos que fueron incluidos posteriormente a la
elaboración del plan de pasantía, logrando conseguir un producto que cumple con
todos los requisitos funcionales y no funcionales que se habían impuesto.
Para facilitar dicha labor se llevó a cabo procesos de análisis, diseño y
desarrollo para la herramienta de gestión de alertas de SUAF+, la cual da
efectivamente una interfaz de gestión y resuelve el problema de tener que invertir
demasiado tiempo en atender las alertas de posibles fraudes sobre las entidades
bancarias.
La solución planteada involucró el desarrollo de una aplicación empresarial
Web bajo el enfoque de separación por capas totalmente modulares que permiten
mayor flexibilidad a la hora de integrar nuevas funcionalidades a la aplicación.
El uso de servidores de control de versiones, la continua revisión del
desarrollo y la correcta planificación de actividades aumentaron el entendimiento
entre los desarrolladores de los distintos módulos del sistema lo que incrementa la
capacidad de trabajo en equipo de los implicados incluyendo el pasante. Además, el
53
contacto con el cliente y la empresa han dejado en el pasante conocimientos de
diversa índole empresarial que valen de mucho para enfrentar futuros retos.
Se lograron buenas características de usabilidad en el sistema mediante la
constante revisión del mismo junto con los usuarios inmediatos, los cuales
aportaron buenas ideas de cómo serían las interfaces más fáciles de manejar para
ellos.
8.2 Recomendaciones
Para que la gestión de alertas sea más eficiente y efectiva, ayudaría en gran
manera incluir un servicio de mensajes de texto para enviar mensajes a celulares de
los supervisores o de alguien predeterminado del sistema cuando hay una alerta sin
atender. Esto es importante, pues puede ser el caso que ningún operador este
conectado a la aplicación, por lo que no se podría saber en esos casos que hay un
posible fraude sino hasta que alguien ingrese a la aplicación. Para hacer este
servicio es necesario contratar un proveedor de servicios de mensaje de texto, y
establecer
reglas
o
protocolos
de
comunicación
que
pueden
variar
entre
proveedores lo que hace un poco engorroso el desarrollo, pero aportaría gran
funcionalidad al sistema.
En estos instantes el sistema front de SUAF y el de SUAF+ trabajan sobre una
plataforma muy vieja (J2EE1.3, J2SE1.4, EJB2.0, Sun Application Server 7) por lo
que se tiene que reinventar la rueda al querer añadir nuevos módulos a los
aplicativos, o como en el caso del Sun Java System Application Server 7 al cual no
se le piensa dar más soporte por parte de Sun Microsystems. Es muy recomendable
que se estudie la posibilidad de subir a versiones más avanzadas en la plataforma
del
sistema
para
agilizar
el
desarrollo
de
nuevas
funcionalidades
y
darle
mantenimiento seguro a la aplicación.
En el módulo de ayudas desarrollado, la búsqueda por índice de palabras fue
realizado a través del uso de un archivo que contiene este índice. Sería
recomendable para otra fase de desarrollo implementar el índice de búsquedas
54
desde una base de datos pues las búsquedas se acelerarían considerablemente en
especial cuando el índice de palabras crezca en gran medida.
Aunque no es el caso del módulo de Front de SUAF desarrollado por el
pasante, el sistema en general está certificado para su uso a través del navegador
Internet Explorer de Microsoft. Sería recomendable que se certifique también para
la mayoría de los navegadores como Netscape, Firefox u Opera, para no obligar a
los usuarios a utilizar algo distinto de lo que usualmente usan y dar al sistema otra
característica de accesibilidad.
55
REFERENCIAS
[1]Bodoff, S. (2004). The J2EE Tutorial. Boston: Addison-Wesley.
[2]Goodman, D. (2001). JavaScript Bible, Gold Edition. Hungry Minds, Inc.
[3]Buschmann F., Meunier R., Rohnert H., Sommerlad P., Stal M. (1996) A System of
Patterns: Pattern-Oriented Software Architecture. Wiley.
[4]Fowler, M. (1997). Analysis Patterns: Reusable Object Models. Addison-Wesley.
[5]Gosling J., Joy B., Steele G. y Bracha G. (2005). The Java language specification. Boston:
Addison-Wesley.
[6]Hernández,G. (2006, 30 de octubre) Mediante fraude informático roban 10 millardos a
banco Confederado. Diario el Carabobeño. (URL: http://www.el-carabobeno.com/
p_pag_hnot.aspx?art=a311006e14&id=t311006-e14).
[7]IBM
(2007).
CICS:
Customer
Information
Control
System.
(URL:
http://www-
306.ibm.com/software/htp/cics/).
[8]Larman, C. (2002), UML y Patrones, Segunda edición, Prentice-Hall.
[9]SDN, SUN Developer Network (2007). Sun Java System Application Server 7 (URL:
http://docs.sun.com/app/docs/coll/ApplicationServer7_04q2_Update2?l=es).
[10]SDN, SUN Developer Network (2007). Enterprise JavaBeans Technology. (URL:
http://java.sun.com/products/ejb/).
[11]SDN, SUN Developer Network (2007). Java EE at a Glance. (URL: http://java.sun.com/
javaee/index.jsp).
56
[12]SDN,
SUN
Developer
Network
(2007).
JavaServer
Pages
Technology.
(URL:
http://java.sun.com/products/jsp/).
[13]SDN, SUN Developer Network (2007). Java SE - Java DB and Java Database
Connectivity (JDBC). (URL: http://java.sun.com/javase/technologies/database/).
[14]SDN,
SUN
Developer
Network
(2007).
Java
Message
Service.
(URL:
http://java.sun.com/products/jms/index.jsp).
[15]SDN, SUN Developer Network (2007). Remote Method Invocation Home. (URL:
http://java. sun.com/javase/technologies/core/basic/rmi/index.jsp).
[16]SDN,
SUN
Developer
Network
(2007).
Java
Servlet
Technology
(URL:
http://java.sun.com / products/servlet/).
[17]Sigmenta Business Technologies (SBT) (2007). Company Overview. (URL: http://www.
sigmenta.com).
[18]The Object Management Group (2007) About the Object Management Group (OMG).
(URL: http://www.omg.org/gettingstarted/)
[19]World Wide Web Consortium (W3C) (2006). Guía Breve de CSS. (URL: http://www.
w3c.es/Divulgacion/Guiasbreves/HojasEstilo)
[20]World Wide Web Consortium (W3C) (2006). Guía Breve de XHTML. (URL: http://www.
w3c.es/Divulgacion/Guiasbreves/XHTML).
[21]World Wide Web Consortium (W3C) (2007). Guía Breve de Tecnologías XML. (URL:
http:// www.w3c.es/Divulgacion/Guiasbreves/TecnologiasXML).
57
APÉNDICE
A
Administración del Proyecto
A.1 Planificación
Para el comienzo del proyecto se previó que el desarrollo del sistema tuviera una
duración de 5 meses (20 semanas), los cuales están detallados por actividades
descritas en el Plan de trabajo y pueden estar sujetas a cambios.
Como se requiere desarrollar dos módulos del componente SUAF+ para la
gestión de alertas (front y servicios), la planificación del proyecto deberá entonces
constar con dos fases importantes:
- Fase de desarrollo de los servicios a repositorio
- Fase de desarrollo de Front
Además se previó una fase previa de estudio del panorama general del sistema y
una fase final de integración, pruebas y certificación del producto.
Se tiene entonces la siguiente tabla de planificación del proyecto:
FASE
DESCRIPCIÓN
•
•
•
Estudio del panorama general del sistema.
Levantamiento de requerimientos funcionales y no
funcionales del sistema.
Estudio de tecnología a ser utilizada
•
•
•
Análisis
Diseño
Implementación
Desarrollo de Front
•
•
•
Análisis
Diseño
Implementación
Integración, pruebas y certificación
•
•
Integración de Servicios y Front
Pruebas , refinamiento y certificación de los
componentes de Atención de Alertas, Consultas de
Alertas y Parametrización General del sistema
SUAF+
Documentación
Estudio del panorama general
Desarrollo de los servicios a
repositorio
•
Tabla A.1. Planificación General del proyecto
58
A.2 Riesgos
En la siguiente tabla se presentan los riesgos encontrados en la fase de inicio con
sus
correspondientes
consecuencias,
su
estrategia
de
mitigación,
plan
de
contingencia, su impacto en el desarrollo y su probabilidad de ocurrencia:
Riesgo
Impacto
(1-5)
%
probabilidad
Realizar una
nueva
planificación del
proyecto.
4
30%
Revisar el
estatus
del proyecto
periódicamente
para verificar
que las
actividades se
están
realizando en
el tiempo
previsto.
Realizar una
nueva
planificación del
proyecto,
dividiendo las
actividades de
manera más
adecuada y
dejando un
tiempo prudencial
entre cada una
de ellas.
3
50%
Delimitar
cuidadosament
e el alcance del
proyecto.
Realizar una
nueva
planificación del
proyecto
incluyendo mayor
tiempo para las
actividades.
3
50%
Consecuencia
Mitigación
Se retrasa la
culminación de la
fase de análisis.
Realizar la
validación de
los
requerimientos
con todos los
integrantes del
desarrollo de
SUAF+.
Mala
planificación de
las actividades a
realizar para el
desarrollo de la
herramienta
dado que se
requiere mayor
esfuerzo del
previsto.
Este riesgo
puede retrasar y
afectar la
culminación
proyecto.
El alcance del
sistema resulta
muy extenso y
ambicioso.
No es posible
construir el
sistema diseñado
en el tiempo
disponible.
Surgimiento de
nuevos
requerimientos o
modificaciones
en los mismos.
59
Contingencia
Retraso de otros
desarrolladores
en partes del
sistema de las
cuales depende
el módulo que
se esta
desarrollando
Que el cliente
no le guste la
manera en que
se muestran las
funcionalidades
Este riesgo
puede retrasar y
afectar la
culminación
proyecto en el
tiempo estimado.
Revisar el
estatus
del proyecto
periódicamente
para verificar
que las
actividades se
están
realizando en
el tiempo
previsto.
Trabajo en
equipo.
Exigir a todos
los
desarrolladores
cumplir con los
tiempos de
entrega
previstos.
Esto puede
retrasar el
proyecto y
afectar la
culminación
proyecto en el
tiempo estimado.
Reuniones
periódicas con
el cliente para
que esté al
tanto de todo lo
que se muestra
de las
funcionalidades
.
Tener holguras
en la
planificación
del proyecto
para poder
mitigar este
riesgo a
tiempo.
Realizar una
nueva
planificación del
proyecto,
exigiendo a todos
los
desarrolladores
cumplir con los
tiempos de
entrega
previstos.
3
60%
Realizar una
nueva
planificación del
proyecto si es
necesario.
3
70%
Tabla A.2. Tabla de riesgos
60
APÉNDICE
Documentos de Diseño
B
B.1. Casos de Uso
En este apéndice se muestran los casos de uso que describen el uso del
sistema por parte del usuario. Estos casos de uso son para el proyecto las
funcionalidades propias del sistema a desarrollar, aquellas perceptibles para el
usuario final.
En estos casos se cumple una lógica de ejecución que se puede describir
haciendo uso de las definiciones de casos de uso que se hace a continuación.
Tabla B.1. Caso de Uso: Atender Alertas Pendientes
Actor Principal Operadores
Precondiciones • Listar Entidades Alertadas
Indicadores de • El Sistema indica un mensaje de alertas procesada exitosamente.
Éxito
Principal
1.El operador selecciona una entidad alertada para atender
Escenario de
Éxito
2.El sistema le muestra al operador las alertas pendientes para la entidad
3.El operador procesa una o más alertas con un una descripción de las
acciones tomadas
Flujos
Alternativos
4. El sistema le indica que las alertas fueron procesadas exitosamente.
- Ya existe un operador B atendiendo el grupo de alertas que pretende
tomar el operador A
1. Las alertas de la entidad que quiere procesar el operador A ya esta
siendo procesada
1.1.El sistema no permite acceder al operador A a las alertas que esta
procesando el operador B
- El operador se excede el tiempo que se le dio para procesar las alertas
2. El operador excede el tiempo que se le dio para procesar alertas y aun
no hace ningún movimiento.
2.1 El sistema expulsa al operador del proceso de las alertas que tenia
asignadas
Frecuencia de
Ocurrencia
Alta , es la principal funcionalidad de uno de los usuarios
61
Tabla B.2. Caso de Uso: Consultar Alertas Pendientes
Supervisores
Actor Principal
Precondiciones
• Listar Entidades Alertadas
Indicadores de Éxito
• El Sistema muestra una lista de alertas pendientes de la entidad
deseada por el supervisor
Principal Escenario de
1.El operador selecciona una entidad alertada para consultar alertas
Éxito
pendientes
2.El sistema le muestra al operador las alertas pendientes para la
entidad
Flujos
Alternativos
- No existen alertas pendientes para la entidad seleccionada para el
momento
1. No existen alertas pendientes para el momento
1.1 El sistema indica al usuario que no existen alertas pendientes
para esta entidad
Frecuencia de
Ocurrencia
Alta , es una de las principales funcionalidades de uno de los
usuarios
Tabla B.3. Caso de Uso: Consultar Alertas Gestionadas
Supervisores
Actor Principal
Precondiciones
• Listar Entidades Alertadas
Indicadores de Éxito
• El Sistema muestra una lista de alertas gestionadas de la entidad
deseada por el supervisor
Principal Escenario de 1.El operador selecciona una entidad alertada para consultar alertas
Éxito
gestionadas
2.El sistema le muestra al operador las alertas gestionadas para la
entidad
Flujos
Alternativos
- No existen alertas gestionadas para la entidad seleccionada para el
rango de fechas actual
1. No existen alertas gestionadas para el rango de fechas actual
1.1 El sistema indica al usuario que no existen alertas gestionadas
para esta entidad en el rango de fechas indicado
1.2 El usuario cambia el rango de fechas de búsqueda de alertas
gestionadas a f
1.3.a Existen datos para el rango de fechas f
El sistema le muestra al operador las alertas gestionadas para la
entidad
1.3.b No existen datos para el rango de fechas f
Volver al punto 1
Frecuencia de
Ocurrencia
Alta , es una de las principales funcionalidades de uno de los usuarios
62
Tabla B.4. Caso de Uso: Configurar Parámetros Generales
Administradores
Actor Principal
Precondiciones
Ninguna
Indicadores de Éxito
• El Sistema muestra un mensaje de que los parámetros fueron
modificados con éxito
Principal Escenario de
Éxito
Flujos
Alternativos
1.El administrador cambia uno o más de los parámetros generales
posibles.
2.El sistema le muestra al administrador un mensaje de que los
parámetros fueron modificados con éxito
- Existe invalido un valor invalido dentro de los parámetros
1. El administrador ingresó un valor invalido
2. El sistema le muestra un mensaje que indica que el parámetro
modificado tiene un formato invalido
Frecuencia de
Ocurrencia
Alta , es una de las principales funcionalidades de uno de los usuarios
Tabla B.5. Caso de Uso: Consultar Ayudas en línea
Todos
Actor Principal
Precondiciones
Ninguna
Indicadores de Éxito
•
Principal Escenario
de Éxito
1.El usuario pide un documento de ayuda de una la funcionalidad f
Flujos
Alternativos
El Sistema muestra al usuario un documento de ayuda para la
funcionalidad pedida
2.El sistema le muestra al usuario un documento de ayuda para la
funcionalidad f
- No existe documento de ayuda para la funcionalidad f
1. El usuario eligió un documento de ayuda que no existe
2. El sistema le muestra un mensaje que indica que el documento de
ayuda para la funcionalidad f no esta disponible
Frecuencia de
Ocurrencia
Media , es una de las principales funcionalidades de apoyo para
manejar el sisitema.
63
Tabla B.6. Caso de Uso: Consultar Lista de Entidades
Todos
Actor Principal
Precondiciones
Ninguna
Indicadores de Éxito
•
Principal Escenario de
Éxito
1.El usuario pide la lista de entidades del sistema
Flujos
Alternativos
El Sistema muestra al usuario una lista de las entidades en el
sistema
2.El sistema le muestra al usuario una lista de las entidades en el
sistema
- No existen entidades configuradas en el sistema
1. El sistema indica al usuario que no existen entidades para listar es
ese momento
Frecuencia de
Ocurrencia
Alta , es la manera a través de la cual se acceden a otras
funcionalidades de frecuencia Alta.
B.2. Diagramas de Secuencia del Sistema
A continuación se presentan los diagramas de secuencia que representan al
sistema en un ejemplo del caso de uso atención de alertas. Estos reflejan el flujo de
datos a través de los módulos por lo que los se separarán en dos diagramas del
módulo front Web y el diagrama que muestra el flujo en el módulo de servicios de
acceso a datos .
Para la figura B.1 el diagrama de secuencia completo para lo que sería el
proceso en front de gestionar una alerta. Esto de por sí implica 3 de los casos de
uso antes mencionados: consultar lista de entidades, atender alertas y procesar la
alerta.
Como se puede ver todas las llamadas que se hacen desde los JSPs se
realizan contra la clase FachadaInterfaz que es una clase neurálgica que recibe las
64
peticiones y las asigna a la clase manejador correspondiente para esa petición. Esto
hace que se trabaje de manera modular y que los cambios en una u otra capa de la
aplicación tenga un menor impacto el los restantes módulos.
Luego de la FachadaInterfaz se encuentran a los manejadores de peticiones
que son los que gestionan las peticiones, verifican los datos, los envían a Core y al
recibir
la
respuesta
de
Core
procesan
la
información
para
retornársela
a
FachadaInterfaz para presentar en la Web.
En el diagrama de la figura B.1 se muestra los tres casos de uso juntos para
poder ver la estructura de las llamadas y el flujo de datos que se toma para una
proceso completo dentro del front Web entre las capas de presentación y negocios.
Figura B.1. Diagrama de secuencia para el caso completo de gestión de alertas
65
Por otra parte, en la figura B.2 se muestra el flujo de datos en la capa de
conexión a servicios de acceso a datos. Aquí se puede observar como se resuelve la
transparencia de conexión a servicios de distintas implementaciones. Primero que
nada las peticiones las recibirá el objeto “ConectorACore”, que es el que administra
el tipo de conexión y los pasos a seguir para efectuar la llamada los servicios.
Continuando con lo anterior, el objeto “ConectorACore” extrae el tipo de
conexión a servicios desde el objeto “Prop” el cual es el encargado de administrar el
archivo de propiedades de la aplicación. Luego se resuelve en hacer la conexión y
envío de los datos según el tipo de conexión obtenida.
Luego, para las llamadas a los JServicios sólo es necesario enviar los mismos
datos que se reciben de la capa de negocios al módulo de servicios en Java sin
realizar ninguna conversión adicional. Por el contrario, en la conexión con los
servicios en COBOL-CICS se hacen procesos adicionales, pues se desarrolló también
una manera efectiva y eficiente de soportar ese tipo de servicios aumentando la
capacidad de mantenimiento del sistema y minimizando el tiempo de desarrollo. El
flujo de datos en esta sección se observa en la figura B.2 cuando el objeto
“ConectorACore” llama al objeto “Trama” donde se construyen los datos a partir del
servicio y el contenedor que se le provee, el objeto “Trama” sabe como armar la
llamada pues obtiene el descriptor del servicio del objeto “DescripciónEsquema”.
Además, el objeto “DescripciónEsquema” extraerá la descripción del servicio
indicado de un archivo XML, esta información quedará cargada en memoria de
manera que cuando se vuelva a preguntar por el servicio se mantenga la
descripción a la mano y se ahorre el trabajo de leerlo desde un archivo
nuevamente.
Después de obtener la descripción del archivo se genera una trama o
contenedor de los campos en una cadena de caracteres que en el diagrama se llama
“tramaString” al cual se le agregan los campos que vienen de la web según la
descripción que viene de los XMLs. Esta trama se envía a los servicios en COBOL-
66
CICS, los que se representan en la figura B.2 con el objeto Cics. Por último la trama
que es obtenida como retorno se le hace la conversión inversa al tipo de contenedor
que se maneja en la capa de negocio.
Figura B.2. Diagrama de secuencia para la conexión a los servicios de acceso a datos
67
Por último, se presenta el flujo de datos para la funcionalidad de atención de
alertas pendientes que se puede observar en el diagrama de la figura B.3.
Este módulo fue diseñado para que solamente se tenga que hacer referencia
al objeto “InterfazJServicios” de manera que el resto módulo sea totalmente
transparente para quien lo utilice como es el caso del módulo front en este
proyecto. El objeto “InterfazJServicios” cumple con la función de recibir las
peticiones y enviarlas al servicio que es solicitado.
Por otra parte, todo lo que tiene que ver con los accesos a datos de alertas
pendientes o gestionadas es procesado por el objeto “Alertas” el cual contiene los
métodos respectivos para el procesamiento del servicio.
Luego de que el objeto “InterfazJServicios” delega el servicio al objeto
“Alertas” se procede a obtener el constructor de EJB de entidad “AlertasLocalHome”
para el acceso a los datos de alertas en la base de datos. Este constructor de EJB de
entidad se obtiene de un objeto “ResourceLocator” que resuelve la referencia al EJB
a través del JNDI de alertas que le es provisto.
Por otro lado, cuando el objeto “Alertas” recibe el constructor de EJB de
entidad “AlertasLocalHome” se procede a hacer la llamada a la instancia de
“DataPaginación”, la cual a través del constructor de EJB de entidad y los
parámetros de busqueda hará el acceso a base de datos y obtendrá el subconjunto
de alertas pedido. Esto es una colección de EJB de entidad “AlertasLocal” que son
los que mantienen la persistencia contra la base de datos.
Por último, se le extraen a las instancias “AlertasLocal” los datos necesarios
para procesar en el servicio y se construye el contenedor de respuesta con los datos
procesados.
68
Figura B.3. Diagrama de secuencia del módulo de servicios de acceso a datos.
Funcionalidad de atención de alertas
De los diagramas anteriores se puede establecer cual es flujo de datos
correspondientes a todas la aplicación pues todas las funcionalidades han sido
desarrolladas de la misma manera. Esto ayuda a la hora de hacerle mantenimiento
a la aplicación pues se sabe donde se realizan exactamente los procesos de las
funcionalidades y al estar diseñado modularmente el mantenimiento se hace más
limpio.
69
APÉNDICE
Diseño de Interfaces de Usuario
C
Aquí se mostraran los bocetos que fueron hechos para visualizar lo que el
cliente deseaba inicialmente para el desarrollo de las mismas y además se
presentan las pantallas finales de la aplicación atención consultas de alertas y
parámetros generales, las cuales son el resultado del continuo feedback con el
cliente.
Entidades alertadas para la atención de alertas.
Figura C.1. Boceto inicial de entidades alertadas para la atención de alertas
Se puede observar en la pantalla final (Figura C.2) que las entidades
alertadas que no están siendo gestionadas por los operadores se muestran con un
icono en color rojo titilante, el cual al ser presionado da acceso al operador a
atender las alertas de esa entidad. Por otra parte, las entidades que están siendo
atendidas por otro operador muestran un icono en color amarillo el cual no contiene
el acceso a esa entidad pues está siendo gestionada por otro operador. Los demás
elementos como la hora de alerta, código de entidad, etc. con respecto al boceto
inicial (Figura C.1) corresponden con la pantalla final.
70
Figura C.2. Pantalla final de entidades alertadas para la atención de alertas
Alertas Pendientes para la atención de alertas.
Figura C.3. Boceto inicial de alertas Pendientes para la atención de alertas
71
En las pantallas que siguen a continuación se muestran las pantallas las que
se llegaron para mostrar la funcionalidad de atención de alertas con respecto al
boceto inicial mostrado en la figura C.3. En la figura C.4 se muestran las alertas
dentro de una subventana con scroll, pues al cliente no le parecía que se mostraran
todas continuamente hacia abajo en la ventana principal ya que prefería que toda la
aplicación se mostrara dentro de la ventana principal sin el scroll en esta última. De
igual modo, se tiene que los indicadores de alertas por transacción o por monto se
muestran resaltados en color rojo pero además se muestran en un tamaño de
carácter superior y en negritas para aquellos que no puedan distinguir el color que
se les presenta.
Figura C.4. Pantalla final de alertas Pendientes para la atención de alertas
Luego en la figura C.5, se muestra el momento de enviar las alertas
procesadas a las cuales se les debe ingresar obligatoriamente una descripción de las
acciones tomadas. Como se ve sólo aparecen las alertas que se debieron seleccionar
en la pantalla anterior.
72
Figura C.5. Pantalla final de alertas Pendientes para la atención de alertas
Entidades alertadas para la consulta de supervisión de alertas
Figura C.6. Boceto inicial de entidades alertadas para la supervisión de alertas
En la pantalla final (figura C.7) se puede observar que además de las
funcionalidades del boceto original visto en la figura C.6, donde se elige una acción
a realizar sobre una de las entidades de la lista de entidades, se añade la
funcionalidad de realizar la acción ingresando el código de la entidad, esto para
73
agilizar la búsqueda en el caso que existan muchas entidades y se conozca el
identificador correspondiente.
Figura C.7. Pantalla final de entidades alertadas para la supervisión de alertas
74
Alertas pendientes para la consulta de supervisión de alertas
Figura C.8. Boceto inicial de alertas pendientes para la supervisión de alertas
Se ve que en la pantalla final en la figura C.9 se mantienen en general todas
las funcionalidades del boceto inicial (figura C.8) incluyendo el rango de fechas y las
búsquedas por identificador de tipo de tarjetas -bin. En la pantalla el campo estatus
muestra si las alertas están siendo gestionadas o se encuentran pendientes por
gestionar.
Figura C.9. Pantalla final de alertas pendientes para la supervisión de alertas
75
Alertas gestionadas para la consulta de supervisión de alertas
Figura C.10. Boceto inicial de alertas gestionadas para la supervisión de alertas
Siguiendo con la descripción de las pantallas, se tiene que en la pantalla final
se mantienen en general todas las funcionalidades del boceto inicial incluyendo el
rango de fechas y las búsquedas por identificador de tipo de tarjetas -bin-. Cada
registro de alerta contiene la descripción de la acción tomada para la gestión.
Figura C.11. Pantalla final de alertas gestionadas para la supervisión de alertas
76
Parámetros generales
Figura C.12. Boceto inicial de parámetros generales
Para los parámetros generales se decidió separar en dos pantallas la
consulta de la modificación por el motivo la configuración es realizada por los
administradores y nadie más. La mayoría de los elementos en las pantallas se
encuentran de manera semejante al de los bocetos pues el cliente lo prefirió así.
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
ANEXO
A
Entorno Empresarial
Figura Anexo1.Estructura Organizacional de SBT
79
El primer nivel de la jerarquía en la empresa Sigmenta Business Technologies
corresponde a la Presidencia de la empresa, en donde se encuentran los socios de la
empresa que son los encargados de realizar las negociaciones con los clientes. En el
segundo nivel se presenta la Dirección de Tecnología y Productos Latinoamérica,
que se encarga de las actividades gerenciales respecto al desarrollo de productos y
tecnologías en Latinoamérica, específicamente en Venezuela. Por debajo de esta
dirección se encuentran tres secciones gerenciales: Tecnología y Desarrollo,
Relaciones Corporativas y Estrategia del Producto y Estudio del Mercado. La primera
se encarga del desarrollo de los productos y tecnologías que la empresa ofrece a sus
clientes, la segunda gestiona las relaciones con los clientes y las empresas con las
cuales existen sociedades o convenios, y la tercera se encarga de las actividades de
publicidad y mercadeo de los productos y tecnologías de la empresa. A su vez, la
sección de Tecnología y Desarrollo, que es la más extensa de las tres mencionadas,
se subdivide en cinco secciones especializadas en áreas técnicas: Desarrollo de
componentes Front-End y aplicaciones Web, Sistemas de cuentas (accounting
systems), Arquitectura Técnica, Soporte técnico y de Bases de Datos y Sistemas de
Autorización. En cada una de estas se tienen líderes de proyectos, analistas y
desarrolladores,
bajo
la
supervisión
correspondiente.
80
de
los
encargados
de
la
sección
81