Configurador P3S: Capa Middleware

UNIVERSIDAD SIMÓN BOLÍVAR
DECANATO DE ESTUDIOS PROFESIONALES
COORDINACIÓN DE INGENIERÍA DE LA COMPUTACIÓN
CONFIGURADOR P3S: CAPA MIDDLEWARE
POR:
CHRISTIAN ENRIQUE DELGADO SERRANO
INFORME FINAL DE PASANTÍA
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 2010
UNIVERSIDAD SIMÓN BOLÍVAR
DECANATO DE ESTUDIOS PROFESIONALES
COORDINACIÓN DE INGENIERÍA DE LA COMPUTACIÓN
CONFIGURADOR P3S: CAPA MIDDLEWARE
POR:
CHRISTIAN ENRIQUE DELGADO SERRANO
Realizado con la asesoría de:
Tutor Académico: Prof. Soraya Abad Mota
Tutor Industrial: Ing. Nelson Galán
INFORME FINAL DE PASANTÍA
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 2010
UNIVERSIDAD SIMÓN BOLÍVAR
DECANATO DE ESTUDIOS PROFESIONALES
COORDINACIÓN DE INGENIERÍA DE LA COMPUTACIÓN
ACTA FINAL DE PROYECTO DE PASANTÍA
CONFIGURADOR P3S: CAPA MIDDLEWARE
PRESENTADO POR:
CHRISTIAN ENRIQUE DELGADO SERRANO
Este proyecto de pasantía ha sido aprobado por el siguiente jurado examinador:
Prof. José Tomás Cadenas
Prof. Soraya Abad Mota
Ing. Nelson Galán
Sartenejas, Octubre de 2010
RESUMEN
El presente informe describe las actividades realizadas para el desarrollo del proyecto de
pasantía, ejecutado en la Gerencia de Servicios de Mantenimiento de Aplicaciones (AM) de la
empresa Indra, compañía global de tecnología, innovación y talento, la cual tiene como cliente a
una de las empresas de telecomunicaciones más grandes del país. A finales del año 2009, se
expresa la necesidad que tiene la empresa cliente de obtener una aplicación que permita al equipo
encargado del área de aprovisionamiento de P3S, realizar el proceso de configuración de tarifas y
descuentos de una manera más automatizada y sencilla a la utilizada actualmente, buscando
reducir los errores que se presentan por la gran intervención manual que tiene dicho proceso. Esta
configuración manual genera datos incorrectos o inconsistentes, los cuales frecuentemente deben
ser depurados por no ser consistentes con las reglas del negocio. En ese momento se plantea
como solución el desarrollo de la aplicación Configurador P3S por parte de Indra, cuyo desarrollo
se estructura usando una arquitectura de tres capas, constituida por un BackEnd, un Middleware y
un FrontEnd.
El presente proyecto de pasantía consistió en el desarrollo de la capa Middleware. Desde
el punto de vista tecnológico, se utilizaron diversas herramientas y tecnologías, como por
ejemplo, Servidor de aplicaciones WebLogic, JEE, EJB, JDBC, XDoclet, entre otras. Los
lineamientos utilizados para el proceso de desarrollo del proyecto de pasantía fueron basados en
los estándares propios de la empresa, contemplándose las fases de análisis y diseño,
implementación, pruebas y por último, implantación y seguimiento.
iv
DEDICATORIA
A mi Padre,
esté es el último paso para cumplirte mi promesa.
A Luis,
por ser una figura paterna para mí, y servirme de inspiración.
Donde quiera que estén, espero poder honrarlos.
v
AGRADECIMIENTOS
A mi Dios por ayudarme a encontrar la fuerza necesaria para alcanzar el triunfo.
A mi Madre, por dedicarme su vida, por sembrar en mí todas sus fortalezas y su
experiencia, para no dejarme ser vencido por ningún obstáculo que se interponga. Solo pido ser
algún día al menos la mitad de lo grande que es ella como persona.
A mi Abuela quien con sus consejos y apoyo incondicional, que me ha brindado a lo largo
de mi vida, me ayuda a no desanimarme bajo ninguna circunstancia y siempre seguir adelante.
A mis Hermanas, Kysbel y Xandra, que sin ellas saberlo, han sido siempre una enorme
fuente de inspiración para superarme. El servirles de ejemplo me ayuda a creer en mí, y el saber
que las ayudaré a tener también un futuro glorioso y exitoso.
A mi familia del colegio y de la banda. Pompa, Víctor, Julio, Deninnson, Kike, Mari y
Kari, por siempre estar ahí desde el comienzo de este largo camino, sé que siempre puedo contar
con ellos.
A toda la gente del área de Aprovisionamiento de Indra, mis compañeros y amigos:
Bianca, Marcy, Anely, Yhoni, Chris, Came, Mayra, Leo, Jerry, Felipe y en especial a mi tutor
Nelson Galán, quienes me brindaron su apoyo, confianza y amistad durante este tiempo en la
empresa, haciendo de mi pasantías una experiencia única.
A la profesora Soraya Abad, por toda la ayuda y confianza puesta en mí a lo largo de la
carrera y finalmente en la realización de este proyecto.
A mis compañeros y amigos de la USB, Isma, Henry, Jomar, Luismi, Jorge, Gian, Caroli,
Tommy, Anita, Chiky, quienes al brindarme sus consejos y ayuda en los momentos que los
necesitaba, se han vuelto parte importante de mi vida, sin importar donde estén.
A los que puedo clasificar como mis compañeros de clases, colegas de trabajo y amigos:
Katy, Jessie y Ale, por vivir juntos toda esta experiencia. Con el trabajo en equipo y el apoyo que
nos brindamos entre nosotros desde el comienzo, pudimos hacer que nuestros proyectos salieran
a la perfección, superando nuestras expectativas.
A todos ustedes, Gracias.
vi
ÍNDICE GENERAL
INTRODUCCIÓN ......................................................................................................................... 1
CAPÍTULO 1 - ENTORNO EMPRESARIAL .......................................................................... 3
1.1
1.2
1.3
1.4
1.5
Historia ............................................................................................................................ 3
Misión ............................................................................................................................. 5
Visión .............................................................................................................................. 5
Valores ............................................................................................................................ 5
Estructura Organizacional ............................................................................................... 5
CAPÍTULO 2 - DEFINICIÓN DEL PROYECTO ................................................................... 7
2.1
2.2
2.3
2.4
Antecedentes del problema ............................................................................................. 7
Planteamiento del problema ............................................................................................ 7
Solución propuesta .......................................................................................................... 8
Objetivos ......................................................................................................................... 9
2.4.1 Objetivo General ................................................................................................. 9
2.4.2 Objetivos Específicos .......................................................................................... 9
2.5
Alcance del Proyecto .................................................................................................... 10
CAPÍTULO 3 - MARCO TEÓRICO Y TECNOLÓGICO .................................................... 11
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
Arquitectura de Tres Capas ........................................................................................... 11
Servicio Web ................................................................................................................. 13
JEE ................................................................................................................................ 13
EJB ................................................................................................................................ 14
JDBC ............................................................................................................................. 14
DataSource .................................................................................................................... 15
Apache Log4J ............................................................................................................... 15
Apache Ant ................................................................................................................... 16
XDoclet ......................................................................................................................... 16
Servidor de aplicaciones ............................................................................................... 16
BPEL ............................................................................................................................. 17
CAPÍTULO 4 - PROCESO DE DESARROLLO .................................................................... 19
4.1
Fases .............................................................................................................................. 19
4.1.1 Análisis y Diseño .............................................................................................. 19
4.1.2 Implementación ................................................................................................. 21
4.1.3 Pruebas .............................................................................................................. 21
4.1.4 Implantación y Seguimiento ............................................................................. 21
vii
CAPÍTULO 5 - DESARROLLO DE LA SOLUCIÓN ........................................................... 23
5.1
Análisis y Diseño .......................................................................................................... 23
5.1.1 Identificación y análisis de los requerimientos funcionales y no funcionales .. 23
5.1.2 Definición de objetivos y alcance ..................................................................... 24
5.1.3 Estudio de las herramientas a utilizar................................................................ 24
5.1.4 Elaboración del diseño funcional ...................................................................... 25
5.1.5 Elaboración del diseño técnico.......................................................................... 25
5.1.6 Elaboración del documento de arquitectura ...................................................... 26
5.1.7 Diseño de la matriz de pruebas ......................................................................... 26
5.2
Implementación ............................................................................................................. 27
5.2.1 Clases elaboradas .............................................................................................. 27
5.2.2 Conexión con la capa BackEnd ......................................................................... 28
5.2.3 Implementación de los EJB ............................................................................... 30
5.2.4 Métodos y funcionamiento del Middleware ..................................................... 31
5.2.5 Compilación e implantación del Middleware ................................................... 33
5.2.6 Implementación de prototipos usando BPEL .................................................... 34
5.3
5.4
Pruebas .......................................................................................................................... 37
Implantación y seguimiento .......................................................................................... 37
CONCLUSIONES Y RECOMENDACIONES ........................................................................ 39
REFERENCIAS BIBLIOGRÁFICAS ...................................................................................... 41
A - GLOSARIO DE TÉRMINOS .............................................................................................. 43
B - REQUERIMIENTOS DEL SISTEMA ............................................................................... 45
B.1 Requerimientos funcionales .......................................................................................... 45
B.2 Requerimientos no funcionales ..................................................................................... 47
C - MATRIZ DE PRUEBAS ...................................................................................................... 48
viii
ÍNDICE DE FIGURAS
Figura 1.1 – Organigrama de Indra ................................................................................................. 6
Figura 3.1 – Arquitectura de tres capas ......................................................................................... 12
Figura 3.2 – Ejemplo de un servidor de aplicaciones JEE ............................................................ 17
Figura 5.1 – Objetos diseñados para la Capa Middleware ............................................................ 26
Figura 5.2 – Ejemplo de la invocación a un procedimiento en el BackEnd. ................................. 30
Figura 5.3 – Ciclo de ejecución del Configurador P3S ................................................................. 32
Figura 5.4 – Servicio Web prototipo desarrollado usando BPEL ................................................. 36
ix
ÍNDICE DE TABLAS
Tabla 1 – Clases Desarrolladas ...................................................................................................... 27
Tabla 2 – Convención usada para los nombres de los EJB. .......................................................... 31
Tabla 3 – Cuadro comparativo entre los tiempos de configuraciones según los tipos de tarifas .. 40
x
LISTA DE SÍMBOLOS Y ABREVIATURAS
API
Application Programming Interface
BPEL
Business Process Execution Language
EAR
Enterprise ARchive
EJB
Enterprise JavaBeans
IDE
Integrated Development Environment
JAR
Java ARchive
JEE
Java Enterprise Edition
JDBC
Java DataBase Connectivity
JNDI
Java Naming and Directory Interface
P3S
Producto, Planes, Promociones y Servicios
SOAP
Simple Object Access Protocol
SPI
Service Provider Interface
SQL
Structured Query Language
WAR
Web Application aRchive
WSDL
Web Services Description Language
XML
eXtensible Markup Language
xi
INTRODUCCIÓN
En la actualidad las empresas de servicio de telecomunicaciones han tenido mucho auge y
desarrollo, éstas han revolucionado las actividades realizadas diariamente, ofreciéndole a la gente
común y de negocio, herramientas primordiales para el desempeño personal y profesional.
Las telecomunicaciones permiten transmitir un mensaje desde un punto a otro. Estas
cubren todas las formas de comunicación a distancia, incluyendo radio, televisión, telefonía,
transmisión de datos e interconexión de computadoras a nivel de enlace. Estos servicios generan
costos para las empresas proveedoras y los usuarios deben cancelar los precios establecidos para
poder disfrutarlos.
Es por ello que Indra toma la decisión de ofrecerle a una de las empresas de
telecomunicaciones más importante del país, una solución para una de las actividades más
significativas de la empresa, la cual es el cobro de sus tarifas; con esto se busca agilizar y
optimizar la funcionalidad de los cobros a los clientes.
A partir de una serie de dificultades e inconvenientes que presenta la empresa cliente
dentro del área que maneja la configuración de las tarifas asociadas a los planes, promociones y
servicios de los productos Postpago ofrecidos (P3S), se determina la necesidad de desarrollar una
aplicación que automatice este proceso de configuración, buscando disminuir la ocurrencia de
errores ocasionados por la intervención manual.
P3S es un módulo de la plataforma de Postpago, que permite configurar los planes,
promociones y servicios que aplican a los productos que brinda la empresa cliente a sus usuarios
dentro de las distintas líneas de negocio que éste maneja. Estudiados los requerimientos del
cliente se hace la propuesta de lo que sería el Configurador P3S, donde se contempla que la
aplicación deberá ser desarrollada en una arquitectura de tres capas, divididas en BackEnd,
Middleware y FrontEnd.
El presente proyecto de pasantía consiste en diseñar, desarrollar e implementar las
funcionalidades de la capa Middleware de una aplicación que permita optimizar la configuración
de tarifas, planes, promociones, productos y servicios de forma automatizada, y así poder generar
finalmente los scripts de modificación. Dentro del alcance de este proyecto se incluye la
integración del Middleware con las otras dos capas del Configurador P3S, creando una aplicación
1
completamente funcional y operativa.
El desarrollo del proyecto se presenta a través del informe de pasantía, el cual se compone
de cinco capítulos. En el Capítulo 1 se presenta una descripción del entorno empresarial en el
cual se desarrolló la pasantía, la Empresa Indra, contemplándose su historia, misión, visión,
valores y la estructura organizativa.
En el Capítulo 2 se presenta la definición del proyecto, para ello se detallan los
antecedentes y planteamiento del problema, solución propuesta, objetivos general y específicos,
finalizando con el alcance del proyecto.
El Capítulo 3 comprende los marcos teórico y tecnológico, presentándose los conceptos y
teorías que fundamentan este proyecto. Se abordan temas como la arquitectura de tres capas, los
servicios web, servidor de aplicaciones, JEE, EJB, JDBC, ANT, entre otros.
En el Capítulo 4 se exponen los lineamientos utilizos para el desarrollo del producto, las
fases y disciplinas que se siguieron, así como los artefactos generados durante la construcción de
la aplicación.
El Capítulo 5 presenta las actividades desarrolladas por cada fase contemplada,
proporcionando los detalles de las decisiones de diseño que se tomaron.
Por último, se presentan las Conclusiones y Recomendaciones que resumen los resultados
y experiencias obtenidas luego de la culminación del proyecto. Adicionalmente, se incluye un
área de apéndices donde se complementa la información ofrecida en el cuerpo principal del
trabajo.
2
CAPÍTULO 1
ENTORNO EMPRESARIAL
El presente capítulo describe el entorno empresarial de Indra, indicando su reseña
histórica, misión, valores y estructura organizacional, a fin de dar a conocer el área de trabajo y
las principales funciones del Departamento al cual el pasante ha sido asignado, para el desarrollo
de su proyecto de pasantías.
Indra es una compañía global de tecnología, innovación y talento, líder en soluciones y
servicios de alto valor añadido para los sectores de Transporte y Tráfico, Energía e Industria,
Administración Pública y Sanidad, Servicios Financieros, Seguridad y Defensa, y Telecom y
Media. Indra opera en más de 100 países y cuenta con más de 30.000 profesionales a nivel
mundial que comparten su conocimiento de los diferentes sectores y países para encontrar
soluciones innovadoras a los desafíos de sus clientes.
A través de la combinación de la electrónica, las comunicaciones y las tecnologías de la
información, sus soluciones añaden inteligencia a diferentes infraestructuras para dar respuesta a
los nuevos retos y problemas de sus clientes y mejorar el desempeño económico, social y
medioambiental, garantizando su sostenibilidad a largo plazo.
1.1 Historia
El origen de las actividades de Indra se remonta a 1921, cuando se constituyó en la
localidad madrileña de Aranjuez la primera de sus empresas llamada “EISA” que, posteriormente
y tras varias modificaciones de carácter patrimonial y societario, daría lugar a la configuración en
1993 de lo que hoy es Indra. Es en el año 1993 cuando todas las filiales de INISEL y CESELSA
se fusionan para constituir Indra Sistemas, por lo que la nueva marca aglutina cuatro sociedades:
ERITEL (Consultoría y servicios informáticos), DISEL (Automatización y control), CESELSA
(Electrónica de defensa) e INISEL ESPACIO (Espacio).
3
En el año 1994 se forma la primera filial Indra América. Para 1995, Indra comienza a
desarrollar sus primeros proyectos tecnológicos en China. Posteriormente, en 1999 surge la
absorción de todas las sociedades ya integradas desde el año 1993.
Indra realiza en el año 2001 la adquisición de la empresa Europraxis, especializada en
consultoría estratégica, y del 10,83% de la empresa BMB, especializada en servicios de Business
Process Outsourcing (BPO) para el sector financiero. En el 2002, se instala en Arroyo de la
Vega, Alcobendas, Madrid y constituye Indra Beijing IT Systems con sede en China. Además, se
adquiere el 60% de la compañía portuguesa llamada Companhia Portuguesa de Computadores
Informática e Sistemas (CPC-IS), una de las cinco primeras compañías de tecnologías de la
información del mercado portugués y se crea Indra CPC.
Para el 2003, Indra era el único proveedor no Americano de la US Navy y comienza con
el desarrollo de tecnología de vanguardia para el Cielo Único Europeo1.
En el 2004, se realiza la firma de los diez principios del Pacto Mundial de las Naciones
Unidas, el cual supone para Indra un paso adelante en su política de sostenibilidad con el trabajo
y con la sociedad. Indra se convierte en el 2005 en la compañía española con mayor número de
profesionales certificados Project Management Professional (PMP) y se obtienen los primeros
certificados CMMi Nivel 3.
Indra en el 2006 entra a cotizar en los índices selectivos de sostenibilidad, The Dow Jones
Sustainability Indices (DJSI), y se consolida como la primera compañía de soluciones y servicios
de alto contenido tecnológico en España y una de las principales compañías europeas y
latinoamericanas.
Para el año 2007 adquiere la compañía australiana de alta tecnología Interscan y se crea la
nueva compañía Indra BMB con 100% capital de Indra, la cual aglutina todas las actividades de
BPO de la antigua BMB (adquirida en marzo de 2007) y del grupo Azertia, también asociado a
Indra. Además, Indra entra en el mercado de Seguridad China con el sistema de vigilancia de
fronteras de Hong Kong.
1
El Cielo Único Europeo es un conjunto de medidas dirigidas a responder a las necesidades en términos de
capacidad y de seguridad del espacio aéreo de Europa.
4
1.2 Misión
“Asistir a las organizaciones para su exitosa gestión del cambio empresarial, lo que
incluye colaborar con su evolución de avance tecnológico.”[1]
1.3 Visión
“Ser una empresa innovadora y del conocimiento en las relaciones con nuestros públicos
internos y externos (accionistas, empleados, clientes, proveedores, etc.) así como las instituciones
que lo cultivan y desarrollan y las comunidades en las que actúan.”[1]
1.4 Valores
 Innovación en el servicio que se presta.
 Excelencia en el servicio.
 Responsabilidad y compromiso con el trabajo.
 Calidad en los servicios y soluciones.
 Garantizar soluciones sostenibles.
1.5 Estructura Organizacional
El pasante a fin de realizar su proyecto de pasantía larga, fue ubicado en la Gerencia de
Servicios
de
Mantenimiento
de
Aplicaciones
(AM),
dentro
del
Departamento
de
Aprovisionamiento, el cual tiene entre sus funciones principales las siguientes.
 La comunicación debido a que actúa como el centro de interlocución con el cliente para
tareas asociadas al Servicio (Calidad, ANS, Procedimientos, estándares, y planes de
recursos) y brinda apoyo en la definición y elaboración de los informes a la Dirección
(comités), tanto de Indra, como del Cliente.
 Seguimiento y control para la coordinación con las diferentes áreas de Indra y el Cliente
para el seguimiento, control del contrato, gestión de estándares (metodología Indra,
Cliente), biblioteca de activos (modelos, plantillas, instrucciones, y guías). Seguimiento y
atención de informes de resultado de auditorías.
5
 Apoyo a la operación para el Aseguramiento de Calidad, asegurando la definición y
seguimiento de los planes de calidad, planes de recursos, revisiones de calidad y apoyo en
la configuración y utilización de las herramientas para la gestión del Servicio.
Figura 1.1 - Organigrama de Indra
6
CAPÍTULO 2
DEFINICIÓN DEL PROYECTO
El siguiente capítulo contiene la definición del proyecto de pasantía. Se presentan los
antecedentes y planteamiento del problema, así como las soluciones propuestas para solventar la
situación presentada. También se plantean los objetivos y alcances del proyecto.
2.1 Antecedentes del problema
P3S es un módulo de la plataforma de Postpago, que permite configurar los planes,
promociones y servicios que aplican a los productos que brinda la empresa cliente a sus usuarios
dentro de las distintas líneas de negocio que éste maneja.
En noviembre del 2009 se llevó a cabo una reunión entre los líderes funcionales del área
de aprovisionamiento de Indra y el líder de proyecto de la empresa cliente, donde se expresa la
necesidad que tiene el cliente de obtener una aplicación que permita al equipo encargado del área
de aprovisionamiento de P3S, realizar el proceso de configuración de tarifas de una manera más
automatizada y sencilla, buscando reducir los errores que se presentan por la gran intervención
manual que tiene dicho proceso; como resultado de la reunión se acuerda el desarrollo del
proyecto Configurador P3S por parte de Indra.
Estudiados los requerimientos del cliente Indra hace la propuesta de lo que sería el
Configurador P3S, donde se contempla que la aplicación será desarrollada en una arquitectura de
tres capas, divididas en BackEnd, Middleware y FrontEnd. El proyecto de pasantía consiste en el
desarrollo de la capa Middleware.
2.2 Planteamiento del problema
El proceso de configuración P3S consiste en la modificación y actualización de las tarifas
y descuentos sobre los elementos pertenecientes a las líneas de negocio que maneja el módulo
7
P3S; este proceso ha sido un trabajo manual a lo largo de los años; la actividad principal de la
configuración P3S es la elaboración de los scripts de configuración y modificación, los cuales
son ejecutados en la base de datos generando así las modificaciones a las tarifas y los descuentos.
Esta actividad requiere el trabajo de varias personas con conocimiento profundo de toda la lógica
de negocio asociada, así como de una gran inversión de tiempo para completar dicha tarea. Por
causa de que el proceso es hecho de forma manual existen datos incorrectos e inconsistentes, que
aunque no son reflejados como un error para el comportamiento de la transacción o facturación
de los servicios del usuario, deben corregirse por no ser consistentes en el negocio.
Los principales problemas de la configuración P3S actual son:
 La información que se maneja para estas configuraciones es bastante extensa y se
almacenan en una gran cantidad de tablas en la base de datos; la distribución que tiene esta
información no es sencilla, y la búsqueda de los datos necesarios para una configuración
específica puede tomar una gran cantidad de tiempo.
 Algunos de los tipos de tarifas que se desean configurar en P3S, se manejan usando
diversas combinaciones de parámetros y valores que las caracterizan. Estas combinaciones
son complejas, y muchas veces los valores varían en rangos sumamente amplios.
2.3 Solución propuesta
Se le propone al cliente el desarrollo de una aplicación que genere los scripts de
modificación, necesarios para realizar la configuración de tarifas y descuentos de los elementos
P3S. Esta aplicación debe tener una interfaz sencilla, de manera que el usuario tenga fácil acceso
a los datos requeridos, sin necesidad de poseer conocimientos detallados de la base de datos que
almacena esta información. La aplicación se divide en tres capas, la capa FrontEnd se encarga de
toda la interacción con el usuario, la capa BackEnd se encarga de obtener la información
proveniente de la base de datos, y la capa Middleware busca ser el enlace entre las otras dos
capas de la aplicación, encargándose de aplicar la lógica del negocio necesaria en las
configuraciones P3S.
El proyecto de pasantía larga consiste en el desarrollo de la capa Middleware de la
aplicación Configurador P3S; este desarrollo permitirá la abstracción de los datos obtenidos
desde la capa BackEnd, así como la transformación y aplicación de la lógica del negocio
requerida sobre dichos datos, con el fin de hacerlos accesibles para la capa FrontEnd del sistema.
8
El Middleware también se encargará de generar los scripts de configuración a partir de los datos
suministrados por la capa FrontEnd, que indican los cambios que el usuario del Configurador
P3S introdujo en la aplicación. Estos scripts generados son los necesarios para aplicar las
modificaciones de las tarifas deseadas, sobre el módulo de aprovisionamiento P3S.
La capa Middleware es planteada como un módulo independiente con respecto a las otras
dos capas con las que se comunica, que encapsule el modelo de negocio que maneja el
Configurador P3S. El módulo debe tener las siguientes características:
 Portable, para que pueda ser llevado de una plataforma a otra sin modificaciones a nivel de
programación y no limitándose a un sólo entorno de ejecución determinado.
 Interoperable, para que pueda ser compatible no solo con las otras capas de la aplicación,
sino también con las distintas plataformas que maneja el cliente; buscando que esta capa
pueda ser reutilizada por algún otro aplicativo que necesite acceder la información
manejada en P3S.
 De fácil acceso, para que se pueda acceder a sus funcionalidades desde cualquier sistema o
módulo del cliente, aplicando estándares de comunicación.
2.4 Objetivos
A continuación se presentan la definición del objetivo general y los objetivos específicos
que se tienen para este proyecto de pasantía.
2.4.1 Objetivo General
 Diseñar, desarrollar e implementar las funcionalidades de la capa Middleware de una
aplicación que permita optimizar la configuración de tarifas y descuentos de los planes,
promociones, productos y servicios ofrecidos; y así poder generar de forma automatizada
los scripts que inserten en la base de datos las modificaciones realizadas.
2.4.2 Objetivos Específicos
 Realizar un estudio del problema tomando en cuenta los requerimientos presentados por la
empresa cliente, y posteriormente plantear una solución que se adapte a sus necesidades.
 Realizar una investigación acerca de las herramientas y tecnologías a ser utilizadas para la
9
resolución del problema.
 Diseñar y desarrollar los objetos que servirán para resguardar y abstraer toda la lógica de
negocio de la configuración de P3S, para el fácil manejo y entendimiento de los datos por
parte del usuario final de la aplicación.
 Diseñar y desarrollar la comunicación con los paquetes y procedimientos a nivel de base de
datos proporcionados por la capa BackEnd, para la obtención de los datos involucrados en
la configuración y la debida manipulación de los mismos para el manejo por parte de la
capa FrontEnd.
 Diseñar y desarrollar la creación de los scripts de configuración con los datos de las
modificaciones ingresadas por el usuario de la aplicación a nivel de FrontEnd, aplicando
las reglas del negocio para la modificación de tarifas y descuentos.
 Crear los servicios web donde serán publicados las funcionalidades desarrolladas en la capa
Middleware, para que puedan ser accedidas por la capa FrontEnd u otros aplicativos.
2.5 Alcance del Proyecto
El proyecto abarca el desarrollo de la capa de negocio de la aplicación Configurador P3S,
Este desarrollo comprende:
 Desarrollo de la capa Middleware, con los objetos y los métodos que abarquen la
funcionalidad de dicha capa.
 Publicación de los servicios web que le proporcionen a la capa FrontEnd estructuras
accesibles para el manejo de los datos.
 Documentación funcional y formal que incluye: documento técnico, documento funcional y
documento de arquitectura.
 Realización de pruebas individuales e integrales y documentación de las mismas, mediante
la matriz de pruebas y el documento de evidencias.
10
CAPÍTULO 3
MARCO TEÓRICO Y TECNOLÓGICO
En el presente capítulo se describen los principales conceptos y bases teóricas aplicadas
en el desarrollo de este proyecto de pasantía, buscando exponer las características de la
arquitectura y de las principales herramientas utilizadas para la implementación del sistema.
3.1 Arquitectura de Tres Capas
La arquitectura de software es la organización fundamental de un sistema, que comprende
sus componentes, las relaciones entre ellos y el ambiente, y los principios que rigen su diseño y
su ejecución.
Existen diversos patrones y estilos de arquitecturas; uno de los más utilizado por las
empresas dado los beneficios que aporta a la calidad de los sistemas es la arquitectura en varios
niveles o capas, en particular la arquitectura de tres capas. Un sistema por niveles está organizado
de manera jerárquica, donde cada capa provee un servicio a la capa superior, y requiere de
servicios de la capa inferior.
La arquitectura de tres capas divide la aplicación en tres secciones. Una capa es la de
presentación o FrontEnd la cual se encarga de crear la interacción con el usuario de la aplicación
haciendo uso de interfaces, estas interfaces buscan traducir las funcionalidades de la aplicación
en instrucciones que el usuario pueda entender. Otra pieza es la capa de negocio o Middleware,
donde están los métodos y objetos que materializan y construyen el manejo de la lógica de
negocio dentro de la aplicación así como el traslado de los datos entre las otras dos capas; el
concepto de Middleware se usa propiamente cuando la comunicación entre la capa de negocio y
la capa de presentación se hace mediante servicios o invocaciones externas permitiendo que la
capa de negocio sea vista como si fuera un aplicativo externo a la capa de presentación. Y por
último, la capa de datos o BackEnd, es donde se maneja la obtención de la información
11
almacenada y necesaria para la aplicación, esta información es representada generalmente por
una base de datos o un sistema de archivo.
Figura 3.1- Arquitectura de tres capas. [2]
En la Figura 3.1, se puede observar la distribución propuesta por un modelo de tres capas.
Se describen los elementos que componen cada capa, y las conexiones entre ellos. Como ya se
mencionó, la capa FrontEnd contiene los elementos de interfaz del usuario, la capa de
Middleware, contiene todos los artefactos que materializan e implementan la aplicación, en
general, las reglas del negocio. Y por último, la capa de BackEnd, contienen lo que serían los
recursos de la aplicación, por ejemplo, las bases de datos.
La arquitectura de tres capas constituye un modelo óptimo de distribución de los
componentes y partes de un sistema, permitiéndole a los desarrolladores dividir un problema
complejo en una secuencia de pequeños problemas. Esta separación también facilita una
distribución real de la aplicación, permitiendo que cada capa pueda estar implantada en
servidores diferentes. [3]
12
3.2 Servicio Web
Un Servicio Web es un conjunto de estándares y protocolos que permite la comunicación
distribuida entre sistemas o aplicaciones en diferentes máquinas al exponer uno o varios métodos
para que sean invocados por estos sistemas externos. Los servicios web proveen medios
estándares de interoperabilidad entre distintas aplicaciones de software, ejecutándose en una
variedad de plataformas. [4]
Los servicios web presentan las siguientes características:
 Son accesibles a través del protocolo SOAP (Simple Object Access Protocol).
 Su interfaz se describe con un documento WSDL (Web Services Description Language).
SOAP es un protocolo de comunicaciones entre aplicaciones establecido por paso de
mensajes en formato XML. Los mensajes SOAP son unidireccionales, sin embargo todas las
aplicaciones pueden participar como emisoras o receptoras indistintamente. Los mensajes SOAP
pueden tener diversos fines: petición, respuesta, notificación, mensajería asíncrona, entre otros.
WSDL es un lenguaje basado en XML que permite describir los servicios web que se
despliegan, así como localizar y ubicar dichos servicios web en la Internet. Un documento WSDL
es en realizad un documento XML que describe en su totalidad las características que posee un
servicio web, su localización y ubicación, y los métodos y parámetros que soporta. [5]
3.3 JEE
Java Edición Empresarial (JEE, Java Enterprise Edition) es la plataforma de
programación principal para desarrollar y ejecutar aplicaciones en el lenguaje Java sobre una
arquitectura distribuida en varios niveles, mediante la composición de varios componentes o
especificaciones de software modulares bajo un servidor de aplicaciones.
La Plataforma JEE tiene varios beneficios entre los cuales se pueden mencionar:
 Permite al programador la creación y desarrollo de una aplicación empresarial portable
entre plataformas, escalable e integrable con tecnologías anteriores.
 Permite al desarrollador mayor concentración en la lógica del negocio que en las tareas de
mantenimiento a bajo nivel. [6]
13
3.4 EJB
Enterprise JavaBeans (EJB) es la arquitectura de componentes del lado del servidor para
la plataforma JEE. La tecnología EJB permite el desarrollo rápido y simplificado de aplicaciones
distribuidas basadas en tecnología Java. [7]
El objetivo principal de los EJB es dotar al programador de un modelo que le permita
abstraerse de los problemas generales de una aplicación empresarial (concurrencia, transacciones,
persistencia, seguridad, entre otras) para centrarse en el desarrollo de la lógica de negocio.
Los EJB proporcionan a la plataforma JEE la posibilidad de dividir la lógica del negocio
en componentes, con el fin de crear arquitecturas distribuidas que proporcionen servicios remotos
con un sistema de seguridad y transacciones homogéneo, así como la posibilidad de conectarse
con otros sistemas diferentes. [8]
Las características esenciales del desarrollo usando la arquitectura EJB son:
 Portabilidad a través de diferentes servidores de aplicación.
 Reutilización de componentes.
 Incremento de la productividad de los desarrolladores.
3.5 JDBC
Java Database Connectivity (JDBC) es el API de Java que es estándar para las conexiones
entre una aplicación Java y una gran cantidad de manejadores de base de datos. [9]
La idea que está detrás de JDBC es dar a los programadores un API que permita codificar
y manejar los datos dentro de sus aplicaciones Java, de manera independiente al fabricante del
gestor de base de datos. JDBC tiene dos capas, a saber, por una parte el API JDBC y por otra el
controlador del fabricante, este último recibe las peticiones de JDBC y las traduce en servicios
internos del gestor de bases de datos, este controlador es específico para cada manejador. El
controlador es el que recibe las peticiones del programa Java y las traduce a órdenes directas al
gestor de la base de datos seleccionada, de manera transparente para el programador. [10]
14
3.6 DataSource
Dentro de las tecnologías usadas en el proyecto se encuentran los DataSource, que no son
más que clases Java pertenecientes al API JDBC, estas clases contienen un conjunto de
propiedades que identifican, describen y generalizan las conexiones a una base de datos desde
una aplicación Java. Estas propiedades incluyen información como el nombre de la base de datos,
la ubicación del servidor donde ésta se encuentra y el protocolo de red usado para comunicarse.
Las aplicaciones desarrolladas sobre la plataforma JEE generalmente usan objetos
DataSource para acceder a bases de datos relacionales, estos objetos son manejados dentro del
servidor de aplicaciones donde está implantado el sistema.
Además, los objetos DataSource trabajan con el servicio de nombres JNDI (Java Naming
and Directory Interface) el cual asocia un nombre al objeto para poder referenciarlo en el código.
Una vez que un objeto DataSource está registrado en el servicio JNDI, las aplicaciones pueden
usar el API JNDI para acceder al objeto DataSource, mediante al nombre que fue establecido,
para conectarse a la base de datos deseada. La ventaja de esto es que el programador no necesita
conocer los detalles de la conexión a la base de datos, ni cómo se establece, y si se presenta un
cambio en el servidor que contiene al manejador o en la manera que se conecta a él, dentro de la
codificación no se necesita hacer cambio alguno, ya que esos detalles le son transparentes a la
aplicación desarrollada. [10]
3.7 Apache Log4J
Es una herramienta de código abierto, basada en Java, que permite generar mensajes de
registro (también llamados logs) en aplicaciones Java, estos mensajes de registro son
comúnmente usados para depurar las aplicaciones, buscando identificar y corregir los errores que
éstas presenten. Esta herramienta permite configurar la salida y el nivel de granularidad de los
mensajes, a tiempo de ejecución y no a tiempo de compilación como es comúnmente realizado;
esta configuración se hace mediante el uso de archivos externos donde se establece un conjunto
de propiedades determinadas.
“Debido a que los logs en Log4J son gestionados en tiempo de ejecución y sin alterar la
fuente, éstos no incurren en altos costos de desempeño. Este proceso de registro provee al
desarrollador con un contexto eficiente y detallado de las fallas de la aplicación”. [11]
15
3.8 Apache Ant
Apache Ant es una herramienta de programación basada en Java usada para la
compilación y construcción de proyectos mediante el uso de archivos XML de configuración;
estos archivos contienen distintos árboles de ejecución, llamados targets, que contienen diversas
tareas a ser ejecutadas; en lugar de tener que utilizar comandos de cónsola que ejecuten dichas
tareas, esto permite que el proceso de compilación sea una tarea mecánica y no limitada a las
distintas órdenes de cónsola que tiene cada sistema operativo, siendo una buena solución
multiplataforma. Esta herramienta también permite el uso de distintas bibliotecas externas para
agregar tareas a ejecutar, facilitando el proceso de compilación. [12]
3.9 XDoclet
XDoclet es un motor de generación de código Java, que permite, con el uso de etiquetas
colocadas en los comentarios del código, generar clases Java, así como archivos descriptores y de
configuración, necesarios para la correcta ejecución de las aplicaciones desarrolladas. Viene con
una biblioteca de etiquetas predefinidas, que simplifican la codificación para las varias
tecnologías. Es una herramienta bastante útil ya que puede llegar a reducir bastante el tiempo
usado para el desarrollo.
Mayormente esta herramienta es integrada con Apache Ant, para generar el código
necesario al momento de compilar toda la aplicación. XDoclet se originó como una herramienta
para la creación de clases EJB, pero dado su naturaleza de código abierto y el gran aporte de los
desarrolladores, se ha aumentado la funcionalidad de la herramienta convirtiéndose en un motor
para generar código con propósito general. [13]
3.10 Servidor de aplicaciones
Un servidor de aplicaciones es un software que proporciona aplicaciones a los equipos o
dispositivos cliente, por lo general a través de Internet y utilizando distintos protocolos de
conexión. Los servidores de aplicación se distinguen de los servidores web por el uso extensivo
del contenido dinámico y por su frecuente integración con bases de datos. Además, un servidor
de aplicaciones es un producto basado en un componente que se encuentra en el plano medio de
la arquitectura central de un servidor, siendo perfecta para la estructuración de una capa de
negocio o Middleware dentro de una arquitectura de tres capas.
16
Los servidores de aplicaciones están estrechamente ligados con el desarrollo usando la
plataforma JEE, ya que los primeros servidores de este tipo fueron concebidos para estas
tecnologías, esto no impide que sea la única ya que existen en el mercado otros servidores de
aplicaciones para distintas tecnologías. [14]
Figura 3.2 – Ejemplo de un servidor de aplicaciones JEE. [15]
En la figura 3.2 se puede ver el manejo de aplicaciones en arquitecturas de tres capas en
un servidor de aplicaciones JEE; la capa cliente puede contener una o más aplicaciones, tanto
locales como aplicaciones web. El manejo de la plataforma JEE se hace en la capa intermedia,
donde generalmente los servidores de aplicaciones JEE están comprendidos por al menos dos
servidores internos, llamados también contenedores, un contenedor Web y un contenedor EJB,
estos contenedores son los que manejan las peticiones de la capa FrontEnd, para luego el servidor
de aplicaciones es el que maneja las conexiones con la capa BackEnd para el acceso a los datos
requeridos. El servidor de aplicaciones usado en este proyecto es Oracle WebLogic Server que
consta de una estructura similar a lo explicado previamente.
3.11 BPEL
Business Process Execution Language (BPEL) es un lenguaje de especificación basado en
XML para representar flujos de procesos de una manera adecuada para que un servidor BPEL
pueda leerla e interpretarla. Es decir, es un lenguaje de especificación completamente ejecutable.
17
El desarrollo de BPEL nace de la necesidad de manejar lenguajes distintos entre la
programación a gran escala y la programación detallada, ya que en su esencia ambos tipos de
desarrollo requieren de distintos grados de comunicación con otros servicios.
A través de un documento XML BPEL, un analista de negocio es capaz de representar la
lógica asociada y los elementos con los que se verá relacionado. Estos elementos serán servicios
Web y la lógica el proceso BPEL.
Es un lenguaje de alto nivel que lleva el concepto de servicio un paso adelante al
proporcionar métodos de definición y soporte para flujos de trabajo y procesos de negocio. [16]
18
CAPÍTULO 4
PROCESO DE DESARROLLO
Para la construcción del Configurador P3S se utilizó una metodología de desarrollo que
sigue unos lineamientos propios de la empresa. En el presente capítulo se estudia en qué consiste
este proceso de desarrollo, explicando sus fases y actividades
A lo largo de las fases del proceso de desarrollo dentro de la empresa Indra, se busca
destacar los siguientes aspectos:
 Trabajo en equipo: las tareas para el desarrollo del proyecto son divididas entre los
participantes y buscan complementarse entre sí.
 Reuniones semanales: semanalmente se realizan reuniones para discutir el progreso del
proyecto, lo que permite la comunicación constante entre los miembros del equipo, la cual
se hace extensiva al cliente para darle a conocer la evolución del proyecto.
 Modular: el proyecto se desarrolla por módulos haciéndolo más legible y manejable. Estos
lineamientos de desarrollo buscan dividir un problema complejo en varios sub-problemas
más simples con el fin de que puedan ser resueltos fácilmente.
4.1 Fases
El desarrollo del proyecto se basa en un proceso de desarrollo por etapas o fases a través
de las cuales se simplifican los objetivos, buscando respuestas eficientes y rápidas para un
ambiente de requerimientos cambiantes.
A continuación se describen las actividades correspondientes a cada fase.
4.1.1 Análisis y Diseño
En esta primera fase del desarrollo se realiza un estudio del proyecto, cuyo fin es
19
planificar y diseñar la solución al problema planteado. Las actividades ejecutadas en esta fase se
detallan a continuación:
 Identificación y análisis de los requerimientos funcionales y no funcionales: esta
actividad permite determinar con exactitud las necesidades y los requerimientos del cliente.
Se realiza un estudio sobre el modelo de negocios de la empresa cliente, se coteja la
situación actual (problema) versus la situación ideal (solución).
 Definición de objetivos y alcance: se precisan los objetivos a cumplir una vez analizado el
problema, lo que permite determinar los productos a desarrollar en el proyecto definiendo
así su alcance.
 Estudio de las herramientas a utilizar: se definen las herramientas tecnológicas a ser
utilizadas considerando las necesidades del proyecto, las cuales son estudiadas para conocer
sus ventajas y desventajas.
 Elaboración del diseño funcional: esta actividad permite preparar el documento que
contempla la visión general del proyecto a desarrollar definiendo el alcance y los objetivos
que alcanzará, se describe el modelo del negocio implicado en la solución, se especifican
los requerimientos funcionales y no funcionales, finalizando con la presentación visual de
cómo será el producto final.
 Elaboración del documento de arquitectura: realización del registro documental donde
se especifica la estructura de la aplicación así como las decisiones tecnológicas establecidas
para la concepción de la solución, indicando los requerimientos que tiene el ambiente de
desarrollo de cada módulo en que es dividido el proyecto.
 Elaboración del diseño técnico: se documenta el bosquejo que se tiene de la solución
diseñada, donde se indican las estructuras de los objetos y métodos a utilizar, la
codificación, así como los criterios para realizar las validaciones y verificación de los datos
involucrados.
 Diseño de la matriz de pruebas: actividad que tiene como fin elaborar en base a las
funcionalidades planteadas, un patrón de pruebas de la aplicación, las cuales serán
realizadas una vez culminado el desarrollo.
20
4.1.2 Implementación
La segunda fase del desarrollo consiste en la aplicación de métodos que permiten poner en
funcionamiento el Configurador P3S. Las actividades ejecutadas se resumen a continuación.
 Codificación: se desarrolla la solución planteada en base a lo establecido en los
documentos de arquitectura, técnico y funcional, aplicando para ello las tecnologías
analizadas.
 Integración: se unifica el trabajo con la integración de las funcionalidades y módulos
paralelamente al desarrollo, lo que permite observar los resultados rápidamente.
4.1.3 Pruebas
Esta tercera fase permite ejecutar las pruebas necesarias para evaluar la aplicación y
determinar los ajustes de ser necesarios. Las actividades ejecutadas se resumen:
 Pruebas unitarias: se aplica la matriz de pruebas realizada en el diseño, y se señalan los
resultados obtenidos.
 Validación de las soluciones: se elabora un registro donde se evidencian los resultados de
la matriz de pruebas con el fin de comprobar que el comportamiento obtenido en las
pruebas unitarias es el correcto.
 Pruebas integrales: se aplica la matriz de pruebas integrales realizada en el diseño, y se
indican en ella los resultados obtenidos.
 Validación de la solución integral: se elabora un registro donde se evidencian los
resultados de la matriz de pruebas con el fin de comprobar que el comportamiento obtenido
en las pruebas integrales es el correcto.
 Identificación de fallas y ajustes: de acuerdo a los resultados obtenidos con la aplicación
de las pruebas, se reparan las fallas encontradas y se realizan los ajustes pertinentes.
4.1.4 Implantación y Seguimiento
La cuarta y última fase se relaciona con la culminación del proyecto. Las actividades
ejecutadas se detallan a continuación:
 Preparación de la solución: se elabora una carpeta de entrega con los archivos listos para
ser implantados.
21
 Documentación formal: se elabora el manual del programador, representado por un
documento que contiene las especificaciones técnicas de la solución desarrollada y los
pasos para su instalación. De igual manera, un manual de usuario para explicar el
funcionamiento de la aplicación a los usuarios finales.
 Apoyar el proceso de implantación: esta actividad permite al equipo de desarrollo servir
de soporte durante la implantación del sistema en la empresa cliente.
 Apoyar las pruebas integrales del cliente: servir de soporte durante el proceso de pruebas
que se realicen en la empresa cliente, lo que permitirá resolver dificultades si se presentan.
22
CAPÍTULO 5
DESARROLLO DE LA SOLUCIÓN
El siguiente capítulo explica detalladamente el proceso de desarrollo del proyecto de
pasantía, describiendo de qué manera se emplearon las distintas herramientas expuestas en
capítulos anteriores. Este capítulo está dividido de acuerdo a las distintas fases establecidas por
los lineamientos de desarrollo utilizados en la empresa.
Dado que la capa Middleware es la encargada de manejar toda la lógica de negocio que
implica el Configurador P3S, en este informe de pasantía se busca el no ser muy específico con
respecto a las funcionalidades desarrolladas y a los datos que se manejan, para respetar las
políticas de confidencialidad acordadas entre Indra y la empresa cliente.
5.1 Análisis y Diseño
Esta es la primera fase del desarrollo del proyecto Configurador P3S, como se explicó de
forma detallada anteriormente, esta fase viene representada por el análisis de las necesidades y de
los requerimientos del sistema así como el estudio de las tecnologías a ser utilizadas durante el
desarrollo, estableciendo así el enfoque técnico que tendrá el proyecto. Dado que es la fase de
planteamiento y planificación de la solución, gran parte de las actividades se efectuaron en
conjunto con todo el equipo del Configurador P3S para el correcto acoplamiento de las tres capas
de la aplicación.
En esta fase se realizaron las actividades descritas en las próximas subsecciones.
5.1.1 Identificación y análisis de los requerimientos funcionales y no funcionales
En esta actividad se analizaron las necesidades del cliente principalmente por medio de
reuniones entre parte del equipo del Configurador P3S de Indra y los líderes del proyecto de la
empresa cliente. En total se identificaron un total de 25 requerimientos, 20 requerimientos
23
funcionales y 5 requerimientos no funcionales.
Los cuadros de requerimientos funcionales y no funcionales determinado se pueden
consultar en los apéndices B1 y B2, respectivamente.
5.1.2 Definición de objetivos y alcance
En esta actividad se estudiaron los requerimientos funcionales y no funcionales, y se
analizó el problema planteado y la solución propuesta para determinar los objetivos y el alcance
que tenía el Configurador P3S y la capa del Middleware, esta información se encuentra descrita
dentro del Capítulo 2 del presente libro, donde se describe la definición del proyecto de pasantía.
5.1.3 Estudio de las herramientas a utilizar
A lo largo de esta fase se contemplaron distintas opciones para la codificación en cuanto
al ambiente de desarrollo y el lenguaje usado en la implementación del Middleware, basándose
en las necesidades que tenía la empresa.
En cuanto al ambiente de desarrollo de la capa Middleware, se planteó la codificación
bajo la plataforma JEE, el cual requiere un entorno de ejecución conocido como servidor de
aplicaciones, este servidor permite la publicación de servicios web que proveen las
funcionalidades que ejecuta el Middleware facilitando así el acceso a dichas funcionalidades por
parte del FrontEnd y de otros aplicativos que las requieran.
Se propuso el usar el servidor de aplicaciones Oracle WebLogic dado que el cliente tiene
varios aplicativos dentro de la plataforma Postpago que usan este servidor. Se establece que el
desarrollo se hará sobre la versión del servidor WebLogic más reciente Oracle WebLogic Server
11gR1. Con el fin de crear una capa compatible con los demás aplicativos que tiene el cliente, el
desarrollo se hace de forma tal que el Middleware sea compatible con versiones anteriores de este
servidor de aplicaciones, ya que existen sistemas usados en la plataforma Postpago del cliente
que están publicados en versiones antiguas, se establece como requisito mínimo para el uso de la
aplicación contar con la versión BEA WebLogic Server 8.1.
Basándose en las necesidades del cliente y las exigencias del mismo se estudian dos
posibles lenguajes para realizar la codificación de los servicios web a publicar. Primero se plantea
desarrollar toda la capa sobre el lenguaje Java usando los distintos componentes que tiene la
plataforma JEE para la creación de los servicios web, pero por una solicitud del cliente se llega al
24
acuerdo de dividir la implementación del Middleware creando los objetos necesario como clases
Java y usando el lenguaje BPEL en la composición de los servicios web. A pesar de que esta
combinación de lenguajes fue la que se acordó con el cliente en la fase de diseño como ambiente
de desarrollo de la capa, una vez invertido algún tiempo en la fase de implementación del
sistema, el cliente solicita volver al planteamiento original de desarrollar la capa Middleware en
su totalidad usando Java junto a la plataforma JEE.
Se plantea usar la herramienta Apache Ant para ejecutar las tareas necesarias de
compilación y construcción del archivo que empaquete todo el aplicativo para ser publicado en el
servidor de aplicaciones.
Adicionalmente, se hace uso de un sistema de registro de mensajes utilizando la
herramienta Log4J, esto con el principal fin de ejecutar la depuración del sistema en el momento
que sea necesario.
5.1.4 Elaboración del diseño funcional
Esta actividad consistió en la elaboración del documento funcional, donde se refleja la
descripción general del proyecto así como los objetivos y alcances del mismo, los requerimientos
funcionales y no funcionales, una visión general del problema y de la solución planteada. Parte
del contenido de este documento está desglosado previamente a lo largo de las distintas secciones
del presente informe de pasantía. Este documento también incluye todas las reglas del negocio
implicadas en la configuración P3S, esta información no se incluyen en este documento por
políticas de confidencialidad de la empresa cliente.
5.1.5 Elaboración del diseño técnico
En este documento se indican todos los aspectos técnicos diseñados para el desarrollo del
Configurador P3S. Para la capa Middleware se presentan las clases a crear y las principales
funciones que son implementadas para el manejo de la lógica de negocio.
En la figura 5.1 se muestran los tipos abstractos de datos creados por el Middleware para
la abstracción de la información manejada por el Configurador P3S, las flechas indican la
relación de contención que hay entre los objetos del negocio.
25
Figura 5.1 – Objetos diseñados para la Capa Middleware
5.1.6 Elaboración del documento de arquitectura
Este documento describe los diferentes aspectos relacionados con las decisiones
tecnológicas establecidas para el desarrollo del Configurador P3S según se estudió en las
actividades anteriores. Las herramientas usadas por el Middleware descritas en este documento
fueron las siguientes:
 Plataforma: Java Enterprise Edition (JEE 6)
 Servidor de Aplicaciones: Oracle WebLogic Server 11gR1
 Herramienta de compilación: Apache Ant 1.8.1
 Registro de logs: Apache Log4J 1.2.15
 IDE: Eclipse 3.5 Galileo
Estas herramientas se encuentran especificadas en el capítulo 3.
5.1.7 Diseño de la matriz de pruebas
Durante esta actividad se especificaron las pruebas unitarias e integrales a realizar, los
datos de prueba y los resultados esperados. El modelo de esta matriz de pruebas puede verse en el
Apéndice C.
26
5.2 Implementación
Una vez terminado el tiempo establecido de análisis y diseño del proyecto, se inició con la
fase de implementación del mismo; en esta fase se desarrollaron las funcionalidades previstas
lográndose completar la codificación en un tiempo menor al establecido. Dentro de esta fase se
buscó codificar el Middleware como la capa más independiente de las tres del Configurador P3S;
mientras avanzaba el desarrollo se iban integrando paralelamente cada funcionalidad alcanzada
junto con las capas BackEnd y FrontEnd.
5.2.1 Clases elaboradas
La función principal que tiene el Middleware es el de abstraer los datos y la lógica del
negocio implicada para su fácil manejo a nivel de FrontEnd o de alguna otra aplicación que
quiera tener acceso a la información manejada por el Configurador P3S, para cumplir esto se
crean tipos abstractos de datos que permitan encapsular la información requerida en la
configuración P3S.
En la tabla 1 se describen las distintas clases desarrolladas.
Nombre de
la clase
Descripción
Este objeto es usado para encapsular
los datos de un servicio, producto, plan
QuerySeleccion
o promoción requeridos para la
configuración P3S.
Es el objeto principal que contiene
todos los datos necesarios para el
proceso de configuración P3S,
ElementoTarificable buscando abstraer la lógica del negocio
implicada en dicho proceso.
ArbolTarificacion
Objeto usado como cabecera del árbol
binario en que se contemplan las
tarifas a modificar. Esta concepción de
árbol binario viene dada por cómo se
maneja el negocio del cliente.
Nodo
Con esta clase se representan los nodos
del ArbolTarificacion, cada Nodo
cuenta con dos apuntadores a objetos
de su mismo tipo, representando así
una estructura de árbol binario.
27
Nombre del
Atributo
Tipo del
Atributo
identificador
long
nombre
abreviatura
id_elem_tarif
id_prod
tipo_elem_tar
nombre_elem_tar
estado
tipo_tarifa_general
arboles_tarificacion
id_arbol_tar
id_concepto_fact
id_def_cpto_fact
nombre_cpto_fact
nodo_raiz
id_nodo
nodo_true
nodo_false
condicion
tarifas
String
String
long
long
String
String
String
String
ArbolTarificacion[]
long
long
long
String
Nodo
long
Nodo
Nodo
String
DetalleTarifa[]
Parametro
DetalleTarifa
ModifTarifa
AbstractObject
Objeto usado para representar los datos
que contiene un tipo de tarifas que son
concebidas en forma de matrices.
Este es el objeto que representa cada
tarifa con la que se facturan los
productos, planes, promociones y
servicios, y son estos objetos los que se
busca modificar en el Configurador
P3S. Con este objeto se representan
tanto las tarifas como los descuentos.
Objeto usado para encapsular toda la
información necesaria para la creación
de los scripts de configuración. Este
objeto se construye con la información
del DetalleTarifa a modificar y los
datos nuevos ingresados por el usuario
de la aplicación.
Clase abstracta de donde extienden
todas las otras clases creadas en el
Middleware. Dentro de ella se
implementaron los métodos comunes
que tengan los objetos abstractos.
nom_parametro
String
val_parametro
descripcion
id_spec
id_tarifa
id_conex_tarifa_dcto
nombre_tarifa
monto
numero_tramo
categoria_spec
fecha_inicio
fecha_fin
unidad
parametros
id_spec
id_conex_tarifa_dcto
id_nodo
numero_tramo
monto
fecha_inicio_vigencia
fecha_fin_vigencia
nuevo
modificado
categoria_spec
String
String[]
long
long
long
String
double
int
int
date
date
String
Parametro[]
long
long
long
int
double
date
date
boolean
boolean
int
Tabla 1 – Clases Desarrolladas
(Nota: la representación “TIPO []”, indica que el atributo es un arreglo de ese tipo.)
5.2.2 Conexión con la capa BackEnd
La capa BackEnd está conformada por un paquete que contiene los procedimientos
escritos en SQL capaces de consultar, organizar y devolver la información solicitada por el
Middleware.
La conexión entre el Middleware y la base de datos donde se encuentra la capa BackEnd,
fue establecida por medio de un objeto DataSource, creado desde el servidor de aplicaciones
WebLogic. Este DataSource usa el controlador Oracle's Driver Thin XA para conexiones por
instancias, para acceder a la base de datos Oracle donde están almacenados los procedimientos
del BackEnd.
28
Al usar este controlador se deben configurar las propiedades para la conexión al servidor
de base de datos que usa el Configurador P3S; dichas propiedades son las siguientes.
 Dirección IP o nombre de la maquina servidor.
 Puerto de conexiones del servidor.
 Nombre de la base de datos.
 Usuario y contraseña con la que se conectará a la base de datos.
Además, se establece el nombre JNDI que tendrá el DataSource; este nombre será
asociado con el objeto DataSource, mediante a una interfaz proveedora de servicios (Service
Provider Interface, SPI) contenida en el servidor de aplicaciones. Los objetos que se encuentran
en la capa Middleware pueden usar el objeto DataSource, y las conexiones que éste establece, a
través de su nombre JNDI, pudiendo así realizar llamadas a los procedimientos de la capa
BackEnd.
Se creó una clase llamada DBAccess.java, la cual sólo se encarga manejar las conexiones
a la base de datos usando el DataSource previamente descrito; esta clase tiene dos métodos, uno
encargado de establecer la conexión con la base de datos, y el otro método cierra dicha conexión.
Estas conexiones son manejadas mediante instancias de la clase java.sql.Connection del
API JDBC.
La invocación de los procedimientos creados en la capa BackEnd se hace de una forma
generalizada en todos los métodos del Middleware; primero se establece la conexión con la clase
DBAccess.java, se arma la línea en SQL para invocar al procedimiento, se instancia la clase
java.sql.CallableStatement con el comando SQL realizado y en este objeto se establecen
los parámetros de entrada y los tipos de los parámetros de salida del procedimiento a ejecutar.
Después se realiza la asignación de los datos devueltos por este procedimiento a los objetos que
se van a manejar; esta asignación implica transformar la información recibida como estructuras
de base de datos, en instancias de las clases Java creadas por el Middleware.
En la figura 5.2 se ve cómo se establece el proceso de llamada de algún procedimiento de
base de datos. En el ejemplo se llama a un procedimiento que tiene tres parámetros, el primero es
un parámetro de entrada de tipo VARCHAR, el segundo es un parámetro de entrada y de salida y
es de tipo NUMBER, y el tercero es un parámetro solo de salida el cual es una estructura de base
de datos creadas por el BackEnd.
29
Figura 5.2 - Ejemplo de la invocación a un procedimiento en el BackEnd.
5.2.3 Implementación de los EJB
Dado que el Configurador P3S fue diseñado en una arquitectura de tres capas, y el pedido
del cliente de desarrollar el Middleware usando el lenguaje Java, todo el desarrollo de esta capa
se realizó bajo la plataforma JEE, usando la API Enterprise JavaBeans versión 2.0 (EJB), la cual
es uno de los estándares de Java más usados para la creación de las capas de negocio en
aplicaciones distribuidas.
Desde el punto de vista de la codificación, un EJB no es más que un conjunto de clases
Java que cumplen ciertas normas de implementación y de nomenclatura que permite ser
desplegado desde el servidor de aplicaciones, para que pueda ser manejado; esta estructura
permite publicar métodos en servicios web para que sean accedidos desde cualquier aplicación
externa; se crearon cuatro EJB entre los que se dividen los métodos según el manejo del negocio.
La estructura de cada EJB del Middleware es la siguiente:
 Bean de sesión (SessionBean): esta es la clase Java que implementa el EJB en sí, es donde
se encuentran definidos todos los métodos que se publican en el servicio web y otros
30
relacionados con la propia clase. Dentro de estas clases es que se codifica la lógica del
negocio.
 Interfaz remota (EJBObject): en esta interfaz se describen los métodos implementados en
el SessionBean que se desea sean accesibles por el cliente externo; mediante esta interfaz el
cliente puede invocar los métodos como si el propio EJB se encontrara disponible en su
máquina.
 Interfaz home (EJBHome): es usada por el cliente únicamente para crear, destruir o buscar
algún EJB; se puede considerar como una interfaz administrativa para el EJB.
Con respecto a los métodos propios que debe contener los EJB, el programador sólo debe
declararlos y no ocuparse de su implementación ya que será el propio servidor de aplicaciones
quien lo haga y permita la conexión remota.
En la tabla 2 se refleja la nomenclatura para las clases creadas por el Middleware según
las convenciones para los EJB.
Clase EJB
Nombre del Archivo
Bean de sesión
<nombre_del_ejb>Bean.java
Interfaz remota
<nombre_del_ejb>.java
Interfaz home
<nombre_del_ejb>Home.java
Tabla 2 – Convención usada para los nombres de los EJB.
Además de lo anterior, hacen falta unos archivos XML de nombre ejb-jar.xml y
weblogic-ejb-jar.xml, llamados Descriptores de Despliegue; dichos archivos contienen la
información de todos los EJB creados, se indican los métodos, interfaces y demás datos
necesarios para su despliegue en el servidor.
5.2.4 Métodos y funcionamiento del Middleware
La mayoría de los métodos desarrollados son para ejecutar los procedimientos de base de
datos de la forma como se explicó previamente en este capítulo. Todos estos procedimientos solo
ejecutan consultas a la base de datos sin realizar modificaciones, por lo que el fin de estos
métodos es el de buscar la información y ordenarla según sea la aplicación de la lógica del
negocio que se deba realizar.
31
El método principal que no implica el acceso a la base de datos, es el que se encarga de la
generación de los scripts; este método recibe desde la capa FrontEnd un arreglo de la estructura
ModifTarifa, que contiene todas las modificaciones realizadas por el usuario del Configurador
P3S. Dentro de este método se manejan los datos recibidos dependiendo de la lógica del negocio
y de los cambios realizados por el usuario para estructurar el script SQL; este script es el que
posteriormente se aplicará a la base de datos de Postpago para completar el proceso de
configuración en la plataforma P3S.
Para que la capa FrontEnd haga uso de los métodos implementados en los EJB del
Middleware, se crea un servicio web que se ejecuta en el servidor de aplicaciones WebLogic,
donde se publica el acceso a dichos métodos para su implementación. El desarrollo de este
servicio web permite también que el Middleware pueda ser usado desde cualquier aplicación que
tenga acceso al servidor WebLogic.
En la figura 5.3 se representa gráficamente la integración de las tres capas en la ejecución
de algún método de consulta del Configurador P3S.
Figura 5.3 – Ciclo de ejecución del Configurador P3S
El funcionamiento del servidor de aplicaciones del
Middleware dentro del
Configurador P3S es el siguiente: Cuando el FrontEnd realiza una invocación de algún método
dentro del servicio web, el servidor al recibir la llamada debe encontrar una referencia del EJB
que contiene el método invocado; si no existe una instancia del EJB dentro del contenedor, se usa
32
la interfaz EJBHome para crearla; es necesario asociar la instancia generada con el EJBObject del
EJB, esto permite invocar los métodos del EJB sobre dicha instancia. Una vez confirmado que
existe la instancia del EJB se ejecuta el método a través de la interfaz remota, si el método accede
a un procedimiento de la capa BackEnd se maneja la conexión a la base de datos con el
DataSource, se obtiene la información y se ejecuta el método en el servidor sobre la instancia del
EJB en cuestión, para luego retornar los resultados al FrontEnd.
5.2.5 Compilación e implantación del Middleware
A pesar de que toda la codificación de la lógica del negocio se hace en la clase Bean, es
necesaria la creación de las interfaces y de los descriptores de despliegue para el correcto
funcionamiento de los EJB, esto supone un trabajo extra para el programador ya que para crear
un nuevo método o reflejar un cambio relevante en alguna clase Bean se deben modificar tres
clases .java. Pensando en esto y en el crecimiento que tendrá el Configurador P3S en posteriores
fases, se hizo uso de la herramienta XDoclet, esta herramienta permite generar código usando
ciertas etiquetas en los comentarios de las clases Bean, de forma que al ejecutar el XDoclet se
analizan estas etiquetas y se generan las interfaces EJBObject y EJBHome para cada EJB, así
como los descriptores de despliegue necesarios para la publicación de los servicios, con esto se
trabaja cada EJB en un sólo archivo, reduciendo el tiempo necesario para el desarrollo y
facilitando la codificación al momento de algún cambio. XDoclet se emplea junto con la
herramienta Apache Ant al momento de querer compilar el proyecto, se generan las interfaces y
los descriptores de despliegue para luego compilar los EJB con el resto del Middleware.
Con la herramienta Apache Ant se ejecuta todo el proceso de compilación y despliegue
del Middleware, una vez generadas las interfaces y los descriptores de despliegue usando
XDoclet, se compilan todas las clases y se empaquetan junto con los descriptores de despliegue
en un archivo .JAR (Java ARchive), que es el formato indicado para que el servidor de
aplicaciones los ejecute dentro de su contenedor de objetos. Usando un conjunto de bibliotecas
proporcionadas por WebLogic se desarrollan los archivos XML y las clases necesarias para la
creación del servicio web donde se publican los métodos implementados en los EJB; estos
archivos son empaquetados en otro archivo con la extensión .WAR (Web Application aRchive),
este formato de archivo es el usado por el servidor de aplicaciones para las aplicaciones web;
tanto el .JAR que contiene los EJB como el .WAR donde se declara el servicio web son
empaquetados en un archivo .EAR (Enterprise ARchive), con el cual el servidor de aplicaciones
33
ejecuta todo el Middleware como una sola aplicación. Una vez terminado el proceso de
compilación, se despliega la aplicación en el servidor usando la herramienta Apache Ant.
Para la invocación del servicio por parte del FrontEnd, es necesario utilizar una biblioteca
cliente que contenga las clases necesarias para poder hacer uso de los métodos y los objetos
proporcionado por el Middleware. Esta biblioteca es generada usando la herramienta Apache Ant
junto con varias clases suministradas por el servidor WebLogic, a partir del archivo WSDL que
describe el servicio web publicado
5.2.6 Implementación de prototipos usando BPEL
Al inicio del proyecto se tenía planteado, por exigencia de la empresa cliente, el uso del
Lenguaje de Ejecución de Procesos de Negocio (Business Process Excecution Language, BPEL,
por sus siglas en inglés) como lenguaje estandarizado para el desarrollo del Middleware. La razón
es que esta tecnología permite el control centralizado de la invocación de distintos servicios web,
que en conjunto con una cierta lógica del negocio ayuda a la programación en gran escala.
Además, este lenguaje proporciona una serie de beneficios a la hora de modelar procesos
complejos, componiendo procesos en base a un conjunto de servicios web que se encarguen de su
ejecución.
En la fase de análisis y diseño se realizó un estudio detallado de esta herramienta, y se
determinó que presentaba una complejidad y amplitud que no se adaptaba a las necesidades del
proyecto. Esto debido a que la empresa tenía planteado el uso de esta tecnología para el proyecto
global Configurador P3S que incluye una serie de fases y funcionalidades cuya interacción
presenta una estructura que requiere una organización bastante compleja; estas funcionalidades
adicionales serán desarrolladas para el Configurador P3S en fases posteriores. Para este periodo
de pasantía sólo se contempla la primera fase que abarca el módulo de tarifas y descuentos, donde
la interacción es mucho más sencilla y el proceso no requiere de una estructura compleja.
BPEL está orientado a la orquestación, que impone un orden y comportamiento individual
a cada uno de los servicios web. Además maneja la distribución de los procesos en un sistema, es
decir, se enfoca en todo el flujo y jerarquía de procesos involucrados en la aplicación, detallando
su estructura en una composición de varios servicios que permiten llevar a cabo todas las
acciones de un proceso complejo. Para esto se toma mucho en cuenta la interacción con entes
externos que permita la comunicación completa de los módulos o componentes.
34
Para el módulo de tarifas del Configurador P3S el proceso es muy sencillo, se requiere
algo más aplicado al manejo de los datos, como lo son los EJB de Java. Dado esto, se planteó a la
empresa cliente una segunda opción que proponía el uso de Java para este desarrollo, herramienta
que permitía una interacción sencilla y una buena inclusión de la lógica del negocio. La empresa
cliente se negó a tomar esta opción, alegando que debía utilizarse BPEL como habían exigido en
un principio.
Como consecuencia de esto y a pesar de las dificultades encontradas, se inició la fase de
implementación desarrollando las primeras funcionalidades con este lenguaje. Se invirtió un
tiempo considerable en el desarrollo, al mismo tiempo que se aprendían las formas de uso que
tiene el lenguaje.
Se crearon distintos prototipos funcionales de aplicativos que emularan el desarrollo de la
capa del Middleware. Al entrar en la cuarta semana de desarrollo, se empieza a codificar, usando
BPEL, los distintos servicios web que tendría la capa Middleware definitiva; es ahí cuando la
empresa cliente pidió el uso de Java para el desarrollo de los métodos del Middleware, y se tuvo
que volver a iniciar la implementación bajo esta nueva tecnología, que fue con la cual se
completó el desarrollo de la solución.
BPEL es un lenguaje que usa una codificación basada en archivos XML y los servicios
web son implementados como flujos procesos; distintas herramientas de desarrollo integrado
permiten programar estos procesos usando representaciones graficas de estos flujos. En la figura
5.4 se refleja gráficamente un servicio web prototipo codificado en BPEL, aquí se ve
representado el servicio web como un flujo de procesos, donde la primera tarea viene dada por la
invocación del servicio así como la recepción de los parámetros de entrada proporcionados por el
cliente, luego se ejecuta un condicional que despliega dos flujos, si se da el caso afirmativo del
condicional se ejecuta el flujo de la izquierda, que ejecuta una asignación, luego ejecuta un trozo
de código Java, y luego se hace una invocación a un método de inserción en la base de datos. El
flujo de la negación del condicional solo asigna los valores y ejecuta un método de consulta en
BackEnd, ambos flujos terminan con la asignación de los valores deseados al mensaje de salida
del servicio web.
Podemos ver con el ejemplo la forma de codificación que tendrían los servicios web del
Middleware usando BPEL. El cambio más significativo para las otras capas sería que para cada
método debe ser publicado un servicio web, ya que ese es el esquema con el que BPEL maneja la
35
orquestación de servicios; mientras que, usando Java junto con las diversas herramientas
previamente descritas, se publica un sólo servicio web para todos los métodos realizados.
Figura 5.4 – Servicio Web prototipo desarrollado usando BPEL
36
Se considera que para posteriores fases y nuevos alcances del proyecto Configurador P3S
se puede estudiar si es conveniente usar BPEL para estructurar la interacción compleja de los
módulos a elaborar. Pero actualmente, basándose en las pruebas elaboradas tanto por el equipo de
desarrollo como por el cliente, la tecnología Java permite satisfacer de forma eficaz las
necesidades contempladas en este módulo inicial de configuración de tarifas y descuentos P3S.
5.3 Pruebas
Al culminar la fase de desarrollo se procedió con la fase de pruebas siguiendo las matrices
planteadas en la fase de análisis y diseño.
Las pruebas unitarias de la capa Middleware se realizaron desde un programa Java creado
para las pruebas que emula la forma como el FrontEnd llama a los métodos publicados en el
servicio web. Las pruebas integrales de las tres capas fueron ejecutadas aplicando lo establecido
en la matriz de pruebas desde el punto de vista del usuario final del Configurador P3S. Las fallas
encontradas fueron debidamente corregidas, tras cada modificación del código se realizaban las
pruebas establecidas hasta que todo el resultado de las matrices resultara exitoso.
5.4 Implantación y seguimiento
Dentro del alcance inicial del proyecto de pasantía no se tenía contemplado el
cumplimiento de esta fase, pero dado que el proceso de desarrollo fue en un tiempo menor a lo
estimado, y como al realizar las pruebas no se reflejaron incidencias significativas, fue posible
realizar esta actividad.
Con el fin de cumplir en su totalidad con el desarrollo de la aplicación, el pasante se
involucró en el proceso de implantación del Configurador P3S en la empresa cliente; la primera
actividad fue la elaboración del manual del programador, el cual incluye las especificaciones
técnicas que requiere la capa Middleware, los pasos para la instalación del ambiente de ejecución,
y las instrucciones de compilación y despliegue de la aplicación.
Luego el pasante asistió a las oficinas de la empresa cliente para el proceso de instalación
del sistema; se instaló en un ambiente similar al que tendrá el Configurador P3S en producción,
también se creó un dominio del servidor de aplicaciones portable, para poder distribuirlo en
varias máquinas del cliente sin necesidad de instalar componentes externos requeridos por la
37
aplicación.
Una vez entregado el producto por parte de Indra, la empresa cliente lleva a cabo una serie
de pruebas propias para asegurar la calidad del sistema antes de su paso a producción. Si se
presenta alguna falla o alguna corrección que se quiera hacer, el equipo de desarrollo del
Configurador P3S proporciona el soporte necesario.
Este proceso de seguimiento concluyó, y no se presentó incidencia alguna relacionada con
la capa Middleware. El proyecto Configurador P3S fue finalizado y aprobado por la empresa
cliente con 2 semanas de antelación a lo previsto, y se encuentra actualmente en el área de
producción del cliente. Reflejando así la calidad que hubo en el proceso de desarrollo de la
aplicación durante el periodo de pasantía.
38
CONCLUSIONES Y RECOMENDACIONES
La realización del proyecto de pasantía larga permitió al pasante interactuar en el campo
de trabajo, así como tener la oportunidad de utilizar los conocimientos académicos adquiridos en
el transcurso de la carrera, logrando culminar con éxito los objetivos planteados al inicio del
proyecto.
El proyecto contempló el desarrollo de la capa Middleware de la aplicación
Configurador P3S, la cual permite enlazar las capas de BackEnd y FrontEnd. Este desarrollo
permitió la abstracción de los datos obtenidos de la capa de datos (BackEnd), así como la
transformación y aplicación de la lógica de negocio requerida sobre dichos datos, haciéndolos
accesibles a la capa de presentación (FrontEnd) del sistema. Adicionalmente, la capa Middleware
se encarga de generar los scripts de configuración a partir de los datos suministrados por la capa
FrontEnd, los cuales indican los cambios que el usuario del Configurador P3S, introdujo en la
aplicación. Estos scripts generados son necesarios para aplicar las configuraciones de tarifas
deseadas sobre el módulo de aprovisionamiento de P3S.
La capa Middleware se planteó como un módulo independiente con respecto a las otras
dos capas con las que se comunica, encapsulando el modelo del negocio que maneja el
Configurador P3S. Se desarrolló la capa Middleware como un módulo portable, interoperable y
de fácil acceso.
El proyecto contempló la investigación de las herramientas a emplear, el análisis de los
requerimientos presentados por el cliente, y el estudio de los conceptos del negocio involucrados
en la configuración de producto, planes, promociones y servicios. Una vez desarrollada la capa
Middleware, se realizaron todas las pruebas unitarias y posteriormente las pruebas integrales.
Todo este proceso fue realizado bajo un estándar de desarrollo propio de la empresa, el cual
contempla cuatro fases, cada una con sus respectivas actividades.
En cuanto al alcance del proyecto, no se acordó la realización de la última fase de
desarrollo (implantación y seguimiento); sin embargo, las actividades planteadas se realizaron en
tiempos menores a los planificados, por lo que dicha fase se ejecutó y actualmente se está
realizando el seguimiento al proyecto.
39
El éxito del proyecto ha motivado al cliente a plantearse la realización de una segunda
fase de desarrollo del Configurador P3S. El planteamiento propone ampliar las funcionalidades
en el Configurador P3S teniendo como meta futura un aplicativo primordial para la plataforma
Postpago del cliente, donde el Configurador P3S sea el único encargado de la gestión y manejo
de los productos, planes, promociones y servicios.
Es importante mencionar que el éxito del proyecto le permite a la empresa reducir
sorprendentemente los tiempos de las configuraciones. En la Tabla 3 se pueden observar las
diferencias entre la configuración manual y la realizada con el Configurador.
Tipos de tarifa
Tiempos
Configuración
Configuración
automatizada
manual (Vieja)
(Configurador P3S)
3 horas
2 min
4 horas
4 min
Ítem
Renta Básica
Tarifas Planas Cupos Adicionales
y Descuentos Renta básica + Cupos
Adicionales
Renta Básica
Tarifas de
Cupos Adicionales
Matrices
Renta básica + Cupos
Adicionales
8 horas
5 min
3 horas
6 horas
2 min
4 min
10 horas
5 min
Tabla 3 – Cuadro comparativo entre los tiempos de configuraciones según los tipos de tarifas
Por último, se tienen dos recomendaciones para la empresa Indra. La primera es sobre la
elaboración de futuros proyectos en la empresa, se pide que se realicen continuas reuniones con
el cliente, logrando una efectiva comunicación donde la forma en que se desarrolla el proyecto
sea totalmente entendida por el cliente, y no se tengan que realizar grandes cambios en el
transcurso del desarrollo.
La segunda recomendación, es el de que se elabore una documentación más formal de lo
que es el proceso de desarrollo y la forma de trabajo que lleva Indra con sus distintos proyectos,
ya que para cumplir con todo el proceso de desarrollo establecido se siga una metodología formal
que esté fundamentada en estándares definidos, para así poder llevar a cabo todas las actividades
de las distintas fases del desarrollo, cumpliendo con un orden específico.
40
REFERENCIAS BIBLIOGRÁFICAS
[1]
Indra Company. Disponible en: http://www.indracompany.com/.
[2]
IBM. “Concepts and Planning: What is distributed computing” en el enlace:
http://publib.boulder.ibm.com/infocenter/txformp/v6r0m0/index.jsp?topic=/com.ibm.cics.
te.doc/erziaz0015.htm, consultado el 09/09/2010.
[3]
Kernel
Error.
(2009).
Arquitectura
3
Capas.
Disponible
en
Internet:
http://kernelerror.net/programacion/php/arquitectura-3-capas/#more-169, consultado el
20/08/2010.
[4]
World Wide Web Consortium. (2004). Web Services Architecture. Disponible en Internet:
http://www.w3.org/TR/ws-arch, consultado el 01/09/2010.
[5]
C. Mateu. Desarrollo de Aplicaciones Web, Fundació per a la Universitat Oberta de
Catalunya 2004.
[6]
ORACLE Corporation. Java EE at a Glance: Overview. 2010. Disponible en:
http://www.oracle.com/technetwork/java/javaee/overview/index.html,
consultado
el
09/09/2010.
[7]
ORACLE
Corporation.
Enterprise
JavaBeans
Technology
http://www.oracle.com/technetwork/java/index-jsp-140203.html,
Disponible
en:
consultado
el
01/09/2010.
[8]
R. Monson-Haefel. Enterprise Java Beans 4th Edition, Ed. O'Reilly & Associates 2004.
[9]
ORACLE
Corporation.
JDBC
Overview
http://www.oracle.com/technetwork/java/overview-141217.html,
Disponible
consultado
en:
el
01/09/2010.
[10]
D. Bales. JDBC Pocket Reference. O'Reilly Media. 2003.
[11]
Apache Software Foundationion. Logging Services: Log4J 1.2. Disponible en:
http://logging.apache.org/log4j/1.2/index.html, consultado el 01/09/2010.
41
[12]
Apache Software Foundationion. Apache Ant 1.8.1 Manual. Disponible en Internet:
http://ant.apache.org/manual/index.html, consultado el 01/09/2010.
[13]
XDoclet
Team.
About
XDoclet.
Disponible
en
Internet:
http://xdoclet.sourceforge.net/xdoclet/index.html, consultado el 01/09/2010.
[14]
A. Molpeceres Touris; M. Pérez Mariñán. Arquitectura empresarial y software libre,
J2EE Disponible en: http://ccia.ei.uvigo.es/docencia/SCS/articulo-j2ee.pdf, consultado el
01/09/2010.
[15]
Área de Ciencias de la Computación e Inteligencia Artificial de la Universidad de Vigo.
Proyecto Java EE 2009/10: Presentación de la práctica, consultado el 09/09/2010.
[16]
T. Andrews; F. Curbera; H, Dholakia. Business Process Execution Language for Web
Services. Disponible en Internet:
http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-bpel/ws-bpel.pdf,
consultado el 09/09/2010.
42
APÉNDICE A
GLOSARIO DE TÉRMINOS
 API (Application Programming Interface): Es una interfaz que permite que una aplicación
haga uso de las funcionalidades que tenga una biblioteca u otra aplicación externa.
 Biblioteca: Es una colección subprogramas empaquetados, que se usan para desarrollar
software.
 Configuración P3S: Proceso para establecer algún cambio sobre los planes, promociones y
servicios de los productos que ofrece la empresa cliente.
 Descuento: monto en moneda o porcentaje (%) que se le deduce a las tarifas asociadas a un
cliente.
 Interoperabilidad: Capacidad de los sistemas de tecnologías de la información y las
comunicaciones, y de los procesos empresariales a los que apoyan, de intercambiar datos y
posibilitar la puesta en común de información y conocimientos.
 Log: Es usado para registrar datos o información de eventos ocurridos para un dispositivo en
particular o aplicación, en un periodo de tiempo determinado.
 Plan: Elemento que permiten definir tarifas y/o contadores para los diferentes conceptos
facturables del negocio. Define la forma de facturar y/o tasar un concepto.
 Portabilidad: Se define como la característica que posee un software para ejecutarse en
diferentes plataformas, el código fuente del software es capaz de reutilizarse en vez de crearse
un nuevo código cuando el software pasa de una plataforma a otra.
 Producto: agrupación de uno o más líneas de negocio que será ofrecido al usuario bajo un
cierto comportamiento predefinido por el negocio.
 Promoción: Modifican la forma de facturar o tasar un concepto, a través de: descuentos,
redefinición de tarifas, otorgamiento de cupos/contadores. Pueden tener asociado un cargo
mensual por el disfrute de la promoción.
 Script: Un script es un conjunto de instrucciones que permiten la automatización de tareas
creando pequeñas utilidades.
43
 Servicio: Valor agregado que puede ofrecerse para un producto base.
 Tarifa: monto en una moneda determinada que se le configura a un plan, promoción o
servicio, con lo cual se le tasa el consumo o renta del cliente.
 WSDL (Web Services Description Language): Es un lenguaje basado en XML que se usa
para describir la interfaz pública de los servicios web; eso significa que detalla los protocolos
y los formatos de los mensajes necesarios para interactuar con los servicios listados en su
catálogo. Un programa cliente que se conecta a un servicio web puede leer el WSDL para
determinar las funciones disponibles en el servidor
.
44
APÉNDICE B
REQUERIMIENTOS DEL SISTEMA
A continuación se muestran algunos requerimientos funcionales y no funcionales del
Configurador P3S. En total se identificaron un total de 25 requerimientos, 20 requerimientos
funcionales y 5 requerimientos no funcionales. En este informe se muestran solo algunos
requerimientos levantados en la fase de diseño, y son mostrados de forma parcial respetando las
políticas de confidencialidad acordadas entre Indra y la empresa cliente.
B.1 Requerimientos funcionales
Código
Nombre
Descripción
Tipo
Precondiciones
Detalles
RF-001
Consulta de productos
Consulta de los productos a configurar
Consulta
Código
Nombre
Descripción
Tipo
Precondiciones
Detalles
RF-002
Consulta de los planes de producto
Consulta de los planes de producto según el producto seleccionado
Consulta
Es necesario el id_producto y el estado del plan a consultar
Código
Nombre
Descripción
Tipo
Precondiciones
Detalles
RF-003
Consulta de las promociones de producto
Consulta de las promociones de producto según el producto seleccionado
Consulta
Es necesario el id_producto y el estado de la promoción a consultar
Código
Nombre
Descripción
Tipo
Precondiciones
Detalles
RF-004
Consulta de los planes de servicio
Consulta de los planes de servicio según el producto y servicio seleccionado
Consulta
Es necesario el id_producto, id_servicio y el estado del plan a consultar
Se mostraran todos los productos configurados en la base de datos
45
RF-005
Consulta de las promociones de servicio
Consulta de las promociones de servicio según el producto y servicio
seleccionado
Consulta
Tipo
Precondiciones Es necesario el id_producto, id_servicio y el estado del plan a consultar
Detalles
Código
Nombre
Descripción
RF-006
Consulta de tarifas en base al plan o promoción escogido
Consulta de la información completa referente a las tarifas correspondientes
al plan o promoción seleccionado
Consulta
Tipo
Precondiciones Es necesario el id_plan o id_promocion a consultar
Detalles
Código
Nombre
Descripción
RF-007
Actualización puntual del monto de una tarifa en función de un intervalo de
fechas
Se modifica el monto de una tarifa determinada.
Descripción
Modificación
Tipo
Precondiciones Es necesario el nuevo monto que tendrá la tarifa y el intervalo de fechas que
estará vigente. El monto debe ser en la moneda que esté actualmente
definida para la tarifa a actualizar.
El monto puede ser representado en cualquier tipo de moneda que se haya
Detalles
configurado en el sistema.
Código
Nombre
Código
Nombre
Descripción
Tipo
Precondiciones
Detalles
RF-008
Actualización puntual del monto de un descuento en función de un
intervalo de fechas
Se modifica el monto de un descuento determinado.
Modificación
Es necesario el nuevo monto que tendrá el descuento y el intervalo de
fechas que estará vigente. El monto debe ser de la forma que esté
actualmente definida para el descuento a actualizar.
El monto puede ser representado en porcentaje o en el monto monetario
exacto a descontar.
46
B.2 Requerimientos no funcionales
RNF-001
Código
Construir una interfaz gráfica sencilla y amigable
Nombre
Descripción La interfaz debe presentar la información de una manera ordenada de manera
que al usuario se le haga sencillo su uso e identifique de manera rápida las
funcionalidades.
La estructura de las pantallas es especificada en el diseño técnico de la
Detalles
aplicación.
RNF-002
Código
Tiempos eficientes de respuesta
Nombre
Descripción Para las búsquedas de las tarifas a modificar y la creación de los scripts de
modificación, se requiere que los tiempos de respuesta sean rápidos.
Se determinarán los tiempos de configuración manual, y una vez terminada la
Detalles
aplicación se tomarán estos nuevos tiempos para realizar una comparación.
RNF-003
Código
Crear una capa middleware genérica para otros aplicativos.
Nombre
Descripción Las funcionalidades de la capa middleware deben ser publicadas mediante a
servicios web, para poder ser accedido por otros aplicativos que puedan requerir
de los servicios brindados por el configurador.
Detalles
47
APÉNDICE C
MATRIZ DE PRUEBAS
A continuación se presenta una muestra de la matriz de pruebas rellenada en las pruebas
unitarias hechas en la capa Middleware.
Descripción:
Pruebas Unitarias Middleware
Aplicación:
Configurador de Tarifas P3S
ID Prueba
1
2
3
4
5
6
7
Fecha
Ejecución
22/08/2010
22/08/2010
22/08/2010
22/08/2010
23/08/2010
23/08/2010
23/08/2010
Funcionalidad
RSAN:
Descripción
Datos de Entrada
Resultado Esperado
INDRA
Resultado Obtenido
Se espera obtener un arreglo Se obtuvo un arreglo de tipo
del tipo querySeleccion con querySeleccion con todos los
todos los productos existentes productos existentes
obtenerProducto
Método que retorna un arreglo de
QuerySeleccion con todos los
productos existentes
N/A
obtenerPlanServicio
Método que retorna un arreglo de
QuerySeleccion con todos los
Planes de Servicio, para un
id_producto, id_servicio y un
estado específicos.
id_producto: 1 (VALIDO)
id_servicio: 20 (VALIDO)
estado: H (VALIDO)
obtenerPlanServicio
Método que retorna un arreglo de
QuerySeleccion con todos los
Planes de Servicio, para un
id_producto, id_servicio y estado
específicos
id_producto: 1 (VALIDO)
id_servicio: 20 (VALIDO)
estado: G (INVALIDO)
Se espera obtener un NULL y Se obtuvo como respuesta un NULL y
que se registre un mensaje en el siguiente mensaje en el log de la
el Log de la aplicación
aplicación: "El estado ingresado no es
válido"
obtenerPlanServicio
Método que retorna un arreglo de
QuerySeleccion con todos los
Planes de Servicio, para un
id_producto, id_servicio y estado
específicos
id_producto: -15 (INVALIDO)
id_servicio: -15 (INVALIDO)
estado: G (INVALIDO)
Se espera obtener un NULL y Se obtuvo como respuesta un NULL y
que se registre un mensaje en el siguiente mensaje en el log de la
el Log de la aplicación
aplicación: "El estado ingresado no es
válido"
obtenerPlanServicio
Método que retorna un arreglo de
QuerySeleccion con todos los
Planes de Servicio, para un
id_producto, id_servicio y estado
específicos
id_producto: 0
id_servicio: 0
estado: NULL
Se espera obtener un NULL y Se obtuvo como respuesta un NULL y
que se registre un mensaje en el siguiente mensaje en el log de la
el Log de la aplicación
aplicación: "El estado no puede ser
NULL"
obtenerPlanServicio
Método que retorna un arreglo de
QuerySeleccion con todos los
Planes de Servicio, para un
id_producto, id_servicio y estado
específicos
id_producto: 0
id_servicio: 0
estado: H (VALIDO)
Se espera obtener un NULL y Se obtuvo como respuesta un NULL y
que se registre un mensaje en el siguiente mensaje en el log de la
el Log de la aplicación
aplicación: "No se encontraron planes
asociados"
obtenerPlanServicio
Método que retorna un arreglo de
QuerySeleccion con todos los
Planes de Servicio, para un
id_producto, id_servicio y estado
específicos
id_producto: 0
id_servicio: 20 (VALIDO)
estado: NULL
Se espera obtener un NULL y Se obtuvo como respuesta un NULL y
que se registre un mensaje en el siguiente mensaje en el log de la
el Log de la aplicación
aplicación: "El estado no puede ser
NULL"
id_producto: 0
id_servicio: 20 (VALIDO)
estado: H (VALIDO)
Se espera obtener un NULL y Se obtuvo como respuesta un NULL y
que se registre un mensaje en el siguiente mensaje en el log de la
el Log de la aplicación
aplicación: "No se encontraron planes
asociados"
Se espera obtener un arreglo
del tipo querySeleccion con
todos los planes de servicio.
Se obtuvo un arreglo del tipo
querySeleccion con los planes de
servicio de un id_producto,
id_servicio y estado especificados
Status
Exitoso
Exitoso
Exitoso
Exitoso
Exitoso
Exitoso
Exitoso
8
23/08/2010
obtenerPlanServicio
Método que retorna un arreglo de
QuerySeleccion con todos los
Planes de Servicio, para un
id_producto, id_servicio y estado
específicos
9
23/08/2010
obtenerServicio
Método que retorna un arreglo de
QuerySeleccion con todos los
Servicios, para un id_producto, y
estado específicos
id_producto: 1 (VALIDO)
estado: "H" (VALIDO)
Se espera obtener un arreglo
del tipo querySeleccion con
todos los planes de servicio
Se obtuvo un arreglo del tipo
querySeleccion con los servicios de un
id_producto, y estado especificados
Exitoso
10
23/08/2010
obtenerServicio
Método que retorna un arreglo de
QuerySeleccion con todos los
Servicios, para un id_producto, y
estado específicos
id_producto: 2 (VALIDO)
estado: "I" (VALIDO)
Se espera obtener un arreglo
del tipo querySeleccion con
todos los planes de servicio
Se obtuvo un arreglo del tipo
querySeleccion con los servicios de un
id_producto, y estado especificados
Exitoso
11
23/08/2010
obtenerServicio
Método que retorna un arreglo de
QuerySeleccion con todos los
Servicios, para un id_producto, y
estado específicos
id_producto: -15 (INVALIDO)
estado: "H" (VALIDO)
Se espera obtener un NULL y Se obtuvo como respuesta un NULL y
que se registre un mensaje en el siguiente mensaje en el log de la
el Log de la aplicación
aplicación: "No se encontraron
servicios asociados"
Exitoso
id_producto: 1 (VALIDO)
estado: "G" (INVALIDO)
Se espera obtener un NULL y Se obtuvo como respuesta un NULL y
que se registre un mensaje en el siguiente mensaje en el log de la
el Log de la aplicación
aplicación: "El estado ingresado no es
válido"
Exitoso
Se espera obtener un NULL y Se obtuvo como respuesta un NULL y
que se registre un mensaje en el siguiente mensaje en el log de la
el Log de la aplicación
aplicación: "El estado ingresado no es
válido"
Exitoso
Se espera obtener un NULL y Se obtuvo como respuesta un NULL y
que se registre un mensaje en el siguiente mensaje en el log de la
el Log de la aplicación
aplicación: "El estado no puede ser
NULL"
Exitoso
12
23/08/2010
obtenerServicio
Método que retorna un arreglo de
QuerySeleccion con todos los
Servicios, para un id_producto, y
estado específicos
13
23/08/2010
obtenerServicio
Método que retorna un arreglo de
QuerySeleccion con todos los
Servicios, para un id_producto, y
estado específicos
id_producto: -15 (INVALIDO)
estado: "G" (INVALIDO)
14
23/08/2010
obtenerServicio
Método que retorna un arreglo de
QuerySeleccion con todos los
Servicios, para un id_producto, y
estado específicos
id_producto: 0
estado: NULL
48
Exitoso