smsc (1)
DESCRIPTION
guiaTRANSCRIPT
UNIVERSIDAD SIMÓN BOLÍVAR
Ingeniería de la Computación
PLATAFORMA PARA LA CREACIÓN, MANTENIMIENTO, MONITOREO Y DESPLIEGUE AUTOMATIZADO DE CONCURSOS PARA SMS
Por
Miguel Ángel Sucre González
INFORME FINAL DE CURSOS EN COOPERACION
Presentado ante la ilustre Universidad Simón Bolívar
como requisito parcial para optar al título de
Ingeniero en Computación
Sartenejas, Febrero de 2007
ii
UNIVERSIDAD SIMÓN BOLÍVAR
Decanato de Estudios Profesionales
Coordinación de Ingeniería de la Computación
Acta de Evaluación de Cursos en Cooperación
PLATAFORMA PARA LA CREACIÓN, MANTENIMIENTO, MONITOREO Y DESPLIEGUE AUTOMATIZADO DE CONCURSOS PARA SMS
Presentado por
Miguel Ángel Sucre González
Este informe final de Cursos de Cooperación ha sido aprobado por el siguiente jurado examinador:
____________________________
Prof. Ascánder Suárez
Jurado
____________________________
Prof. Carlos Figueira
Tutor Académico
iii
PLATAFORMA PARA LA CREACIÓN, MANTENIMIENTO, MONITOREO Y
DESPLIEGUE AUTOMATIZADO DE CONCURSOS PARA SMS
Resumen
En el mundo de la telefonía celular es importante el crecimiento que ha tenido el uso de
la mensajería de texto en los últimos años. Gracias a esto la mensajería de texto no sólo es
para comunicarse entre personas sino que también se utiliza para el entretenimiento,
participación y diversión de los usuarios, principalmente en la Radio y TV. En respuesta al
nuevo crecimiento de aplicaciones para la mensajería de texto, surge el objetivo de esta
pasantía: la elaboración de un sistema automatizado para la creación, mantenimiento, y
reportes de concursos para SMS (Short Message Service). El SMS es un servicio para el envío
y recepción de mensajes cortos, que funciona sobre las redes de telefonía celular digital.
Se desarrollo una primera versión del sistema, llamado ActiveSMS que engloba todas
las tareas que implican crear, mantener y monitorear un concurso SMS, reduciendo los recursos
necesitados por la empresa Conectium Limited para el desarrollo y la puesta en marcha de los
concursos.
El sistema se compone de cuatro módulos: el de lógica de concursos (cómo funcionan
los concursos y qué contenido mostrarán), de conexión con la red celular (cómo llegan los
mensajes a la red celular y viceversa), Web para configurar visualmente los concursos y otras
opciones, por último, el de persistencia para almacenar información del sistema en un
repositorio de datos.
iv
Dedicatoria
A mi madrina, Carmen Cecilia González de Mayz.
v
Tabla de Contenidos
1 Introducción ...................................................................................................................... 1
2 Entorno Empresarial ......................................................................................................... 3
2.1 Misión y Visión de Conectium Limited.......................................................................... 3
2.1.1 Visión................................................................................................................... 3
2.1.2 Misión .................................................................................................................. 3
2.2 Trayectoria de Conectium Limited en el ámbito Internacional y Venezuela.................. 3
2.3 Organización y Estructura de Conectium Limited......................................................... 4
2.3.1 Unidad de Gerencia y Mercadeo.......................................................................... 4
2.3.2 Unidad de Tecnología y Operaciones .................................................................. 4
2.3.3 Unidad de Contenido y Multimedia....................................................................... 4
2.4 Ubicación del pasante ................................................................................................. 4
3 Planteamiento del Problema............................................................................................. 5
3.1 Objetivo General:......................................................................................................... 7
3.2 Objetivos Específicos: ................................................................................................. 7
4 Marco Teórico.................................................................................................................... 8
4.1 Definición de SMS ....................................................................................................... 8
4.2 Funcionamiento del SMS............................................................................................. 8
4.3 SMS Centers (SMSC).................................................................................................. 9
4.3.1 Protocolos de comunicación ................................................................................ 9
4.4 Protocolo SMPP ........................................................................................................ 10
4.5 Arquitectura de Tres Capas Cliente/Servidor ............................................................. 10
4.6 Metodología de Desarrollo Aplicada .......................................................................... 12
4.6.1 Dos dimensiones del proceso de desarrollo....................................................... 12
4.6.2 Estructura Dinámica de RUP ............................................................................. 13
4.6.2.1 Fase de Inicio................................................................................................. 13
4.6.2.2 Fase de Elaboración ...................................................................................... 13
4.6.2.3 Construcción .................................................................................................. 14
4.6.2.4 Transición ...................................................................................................... 14
4.6.3 Estructura Estática de RUP................................................................................ 14
4.7 Patrones de Diseño ................................................................................................... 15
4.7.1 Clasificación de Patrones................................................................................... 15
4.7.1.1 Patrones de Creación..................................................................................... 15
vi
4.7.1.2 Patrones Estructurales ................................................................................... 16
4.7.1.3 Patrones de Comportamiento......................................................................... 17
5 Fase de Inicio: ................................................................................................................. 18
5.1 Visión del Proyecto .................................................................................................... 18
5.1.1 Módulo de lógica de concursos y procesamiento de sesiones ........................... 18
5.1.2 Módulo de Conexión con la red móvil celular ..................................................... 19
5.1.3 Módulo de Administración Web.......................................................................... 20
5.1.4 Módulo de Persistencia de Datos....................................................................... 20
5.2 Actores y principales casos de uso: ........................................................................... 21
5.2.1 Actores............................................................................................................... 21
5.2.2 Casos de Uso .................................................................................................... 21
5.2.2.1 Módulo de Manejo de concursos:................................................................... 21
5.2.2.2 Módulo de Conexión con la red Celular.......................................................... 22
5.2.2.3 Módulo Web:.................................................................................................. 22
5.2.2.4 Módulo de Persistencia de Datos................................................................... 22
5.3 Glosario del Sistema.................................................................................................. 22
5.4 Estudio Inicial de Riesgos.......................................................................................... 23
5.5 Plan de Desarrollo del Software................................................................................. 23
5.6 Hitos Alcanzados....................................................................................................... 23
6 Fase de Elaboración........................................................................................................ 24
6.1 Vistas de la arquitectura del Software........................................................................ 24
6.2 Las 4 + 1 Vistas de la arquitectura............................................................................. 24
6.2.1 Vista de Casos de Uso....................................................................................... 24
6.2.1.1 Diagrama de Casos de uso............................................................................ 25
6.2.2 Vista Lógica ....................................................................................................... 25
6.2.2.1 Modelo Conceptual o del Dominio.................................................................. 25
6.2.2.2 Diagramas de Clases..................................................................................... 25
6.2.2.3 Diagramas de Secuencia ............................................................................... 26
6.2.3 Vista de Implementación.................................................................................... 26
6.2.4 Vista de Despliegue ........................................................................................... 27
6.3 Decisiones de Diseño ................................................................................................ 29
6.3.1 Módulo de Lógica de Concursos y Manejo de sesiones..................................... 29
6.3.2 Módulo de Conexión con la red móvil celular ..................................................... 30
6.3.3 Módulo de Persistencia de Datos....................................................................... 31
vii
6.3.4 Módulo de Administración Web.......................................................................... 32
6.4 Lista de Requerimientos no funcionales .................................................................... 32
6.5 Hitos Alcanzados....................................................................................................... 32
7 Fase de Construcción I ................................................................................................... 33
7.1 Implementación de la Arquitectura propuesta: ........................................................... 33
7.1.1 Módulo de Lógica de Concursos........................................................................ 33
7.1.1.1 Manejador de Sesiones:................................................................................. 33
7.1.1.2 Sesiones ........................................................................................................ 34
7.1.1.3 Manejador de Concursos ............................................................................... 35
7.1.1.4 Concursos...................................................................................................... 35
7.1.1.5 Manejador de teléfonos de prueba................................................................. 36
7.1.2 Módulo de Conexión con la Red Celular ............................................................ 36
7.1.2.1 IMG-Queue .................................................................................................... 36
7.1.2.2 Subsistema de Conexiones............................................................................ 37
7.1.3 Módulo de Persistencia...................................................................................... 37
7.2 Hitos Alcanzados....................................................................................................... 38
8 Fase de Construcción II .................................................................................................. 39
8.1 Módulo Web .............................................................................................................. 39
8.1.1 Vistas................................................................................................................. 40
8.1.2 Controlador ........................................................................................................ 40
8.1.3 Modelo............................................................................................................... 40
8.2 Conexión con la red celular a través del módulo Web ............................................... 40
8.3 Módulo de Persistencia.............................................................................................. 41
8.4 Hitos Alcanzados....................................................................................................... 41
9 Fase de Transición.......................................................................................................... 42
9.1 Módulo de Lógica de Concursos: Comentarios.......................................................... 42
9.2 Proceso de Pruebas del Sistema............................................................................... 42
9.3 Estatus Actual del Sistema ........................................................................................ 44
10 Conclusiones............................................................................................................... 45
11 Recomendaciones....................................................................................................... 47
12 Notas ............................................................................................................................ 48
13 Referencias Bibliográficas.......................................................................................... 50
14 Apéndices .................................................................................................................... 51
viii
Lista de Figuras
Figura 1.Funcionamiento Del SMS. [2]........................................................................................ 9
Figura 2. Arquitectura de tres capas. [6].................................................................................... 11
Figura 3. RUP en dos dimensiones. [7] ..................................................................................... 13
Figura 4 Plan de desarrollo del software. Elaboración propia. ................................................... 23
Figura 5. Vista Implementación. Elaboración Propia. ................................................................ 27
Figura 6. Vista de Despliegue. Elaboración Propia.................................................................... 28
Figura 7. Fábrica Abstracta. [8] ................................................................................................. 29
Figura 8. Decorador. [8] ............................................................................................................ 30
Figura 9. Patrón DAO. [12]........................................................................................................ 31
Figura 10. Flujo de mensajes. Elaboración Propia .................................................................... 34
Figura 11. Flujo del IMG-Queue. Elaboración Propia ................................................................ 36
Figura 12. Arquitectura de Hibernate. [12]................................................................................. 37
Figura 13. Arquitectura Struts. [13]............................................................................................ 39
ix
Lista de Abreviaciones
API Application Programming Interface
CIMD Computer Interface to Message Distribution
CNTM Conectium Limited
EMI External Machine Interface
GSM Global System for Mobile Communications
HQL Hibernate Query Language
HTML Hyper Text Mark up Language
HTTP Hyper Text Transfer Protocol
IMG Internet Message Gateway
IP Internet Protocol
JSP Java Server Pages
OIS Open Interface Specification
PDU Protocol Data Unit
RUP Rational Unified Process
SMPP Short Message Peer to Peer
SMS Short Message Service
SQL Structured Query Language
TCP Transfer Control Protocol
UCP Universal Computer Protocol
UML Unified Modelling Language
URL Universal Resource Locator
VPN Virtual Private Network
1
1 Introducción
La popularidad de la mensajería de texto ha venido aumentando aceleradamente a lo
largo de los últimos años en Venezuela y Latinoamérica en general. Gracias a su bajo costo y
gran potencial de aplicaciones, los mensajes de texto son la primera forma de comunicación a
través de las redes móviles en Venezuela. Hoy en día aproximadamente el 60% de los
venezolanos están en capacidad de utilizar este servicio con expectativas de crecimiento
bastante altas.
La mensajería de texto no solo sirve para comunicarse entre los suscriptores de las
compañías de telefonía celular, además sirven para el entretenimiento (Trivias, Votaciones,
Comentarios, etc.), consultas y otra infinidad de servicios de información también llamados
servicios SMS Premium.
Gracias al crecimiento, la demanda de servicios de entretenimiento SMS ha
incrementado de la misma forma, lo cual requiere que se desarrollen cada vez más y mejores
sistemas que puedan satisfacer esta creciente demanda del mundo móvil.
La intención de este proyecto es diseñar e implementar un sistema para la construcción,
administración y monitoreo de concursos a través de mensajería de texto, de fácil uso y rápida
puesta en marcha, además de contar con la capacidad de extender sus funcionalidades de
forma sencilla y rápida por cualquier otro desarrollador.
El objetivo principal del proyecto hacer un sistema para crear, administrar y monitorear
un concurso SMS totalmente adaptable a las necesidades del usuario. Para lograr esto se
requiere manejar cual es la lógica de los tipos concursos, los distintos comportamientos que
deben tener los concursos durante la sesión de juego. Por otro lado se necesita la conexión con
la red celular para el envío y recepción de mensajes, y por último una consola Web
administrativa que permita manipular los concursos.
2
El proyecto se desarrolla basándose en la metodología Rational Unified Process
tomando lo más importante, con el fin de utilizar las mejores prácticas de desarrollo, dando
como resultado un software de calidad y documentos que sirven como referencia para futuros
desarrollos.
Este informe está estructurado de la siguiente forma: en el primer capítulo se describe el
entorno empresarial en donde se desarrolló el proyecto, como segundo el planteamiento del
problema, luego un marco teórico y finalmente cinco capítulos que describen las actividades
que se realizaron durante las etapas de la metodología RUP: Fase de de inicio, elaboración,
constricción I, constricción II y la fase transición.
3
2 Entorno Empresarial
En este capítulo se describe el entorno en el cual el proyecto de pasantía fue
desarrollado, con el fin de conocer a la empresa Conectium Limited. Se expone la misión y
visión de esta empresa, luego la trayectoria de Conectium Limited en el ámbito internacional y
en Venezuela, seguido de la organización y estructura, y finalmente la ubicación del pasante
dentro de la empresa.
2.1 Misión y Visión de Conectium Limited
2.1.1 Visión
“Convertirse en el proveedor líder de soluciones de Internet inalámbrica para las más
importantes compañías de servicios de comunicación móvil en toda Latinoamérica”. [1]
2.1.2 Misión
“Conectium Limited, se propone obtener la mayor base de suscriptores de comunicación
inalámbrica del continente, suministrando un servicio de Internet móvil de amplio espectro;
basado principalmente en el aporte de desarrollo de contenido y asesoría en gerencia de redes
que proporcione al usuario final la información apropiada a sus necesidades y que le permitan
experimentar toda la funcionalidad de la autopista de la información a través de sus equipos de
teléfono celular”. [Ob. Citada]
2.2 Trayectoria de Conectium Limited en el ámbito Internacional y Venezuela
Conectium Limited fundada en el año 2000, líder en Internet Móvil en Latinoamérica. Es
una empresa que ha incrementado su cartera de productos y servicios para ofrecer aplicaciones
como portales SMS, WAP entre otros, desarrollo de contenidos, descargas de tonos para
celulares, imágenes y video, etc.
En Venezuela se encuentra la base de desarrollo y operaciones de la empresa,
contando también con oficinas comerciales en México, Panamá, Costa Rica, Colombia, y Chile.
Conectium Limited desarrolla soluciones de Internet móvil utilizando la figura private-label, es
decir portales que llevan la marca y nombre del operador celular, desarrollados para satisfacer
las necesidades de las empresas celulares (operadores) y sus mercados. Se especializa en el
manejo y desarrollo de aplicaciones, que a través de las distintas interfaces inalámbricas,
permiten integrar contenidos, información, y aplicaciones apropiadas para la Internet móvil y
otros servicios.
4
2.3 Organización y Estructura de Conectium Limited
La organización de la empresa consta de tres grandes unidades operativas:
2.3.1 Unidad de Gerencia y Mercadeo
Responsables de realizar todas las labores de mercadeo, ventas y certificaciones.
Departamento de Ventas, Departamento de productos y Departamento de proyectos.
2.3.2 Unidad de Tecnología y Operaciones
Se encarga del desarrollo de software y del correcto funcionamiento de este las 24
horas, 7 días a la semana. Departamento de Operaciones y Departamento de Tecnología.
2.3.3 Unidad de Contenido y Multimedia
Responsables de mantener y actualizar las categorías y objetos de contenido generados
periódicamente por la empresa. Departamento de Contenido.
2.4 Ubicación del pasante
El proyecto de pasantía se realizó en la unidad de Tecnología y Operaciones,
específicamente en el departamento de tecnología. El proyecto consiste en diseñar e
implementar un sistema funcional para la creación, mantenimiento y monitoreo de concursos
SMS. El pasante fue el único encargado de toda la tarea, basándose en requerimientos
solicitados por parte del personal del área de productos y la dirección de la empresa. Para el
despliegue en producción del sistema se necesitó el apoyo del Departamento de Operaciones.
En el siguiente capítulo, se plantea el problema con mayor detalle, ya que fue el objeto
de la pasantía.
5
3 Planteamiento del Problema
Actualmente Conectium Limited cuenta con una herramienta Web para servicios SMS de
Radio y TV. Esta herramienta no posee la funcionalidad para crear concursos, y mucho menos
concursos personalizados para clientes distintos; sin embargo es posible emular concursos muy
sencillos que se pueden implementar en corto tiempo. Las limitaciones de esta herramienta son
muy grandes, sólo se pueden emular preguntas con una sola respuesta, sin ningún tipo de
lógica o comportamiento.
Ya que cada cliente exige un concurso estrictamente personalizado, la empresa se ve en
la obligación de desarrollar un software adicional que cumpla con las especificaciones del
cliente. Las características de los concursos varían mucho, desde el tipo de concurso que
pueden ser Trivias, Votaciones, Sorteos, Comentarios, etc., hasta el comportamiento interno de
cada uno de ellos, por ejemplo, preguntas en orden aleatorio, acumulación de puntos, etc. En
fin, la cantidad de requerimientos y detalles de los concursos por parte del cliente son diversos y
amplios.
Adicionalmente se requiere manejar países, operadoras y números cortos de acceso
(Short Codes), en donde van a estar operativos estos concursos. Esta tarea es bastante
complicada debido a que, primero se necesita desplegar el concurso, y luego configurar los
sistemas que procesen mensajes (IMG) según los requerimientos de cada país, lo cual implica
tiempo fuera del aire y probables conflictos con otros servicios. Por ejemplo, si una trivia ya se
encuentra activa en Venezuela (Movistar, Movilnet, Digitel) con el numero de acceso 1515, y la
palabra clave “F.*” basada en expresiones regulares; de igual manera se quiere poner en
funcionamiento una votación en Venezuela y en México utilizando también el 1515 con la
palabra clave “Futbol”, esta trivia generará conflictos con la anterior.
Entonces ¿Por qué no es posible tener un sistema integrado con los sistemas de
recepción y envío de mensajes, que sirva para generar concursos que cumplan con los
requerimientos del cliente rápidamente? Como se menciona anteriormente, los clientes
necesitan concursos bastante particulares, por ende los detalles a controlar son amplios, pero
en algunos casos las funcionalidades se pueden repetir. Por ejemplo, en el caso de una trivia
con preguntas aleatorias.
6
De allí surge la necesidad de diseñar un sistema automatizado que maneje la creación,
mantenimiento, monitoreo despliegue de concursos a través de mensajería de texto SMS, que
cuente con facilidad para atender de forma rápida nuevos requerimientos por parte de los
clientes.
Otra de las limitantes es el proceso de creación, mantenimiento y puesta en marcha de
concursos SMS, se requiere de un Analista de producto encargado de tomar todos los
requerimientos del cliente, dos o más Analistas de Sistemas que se encarguen de diseñar,
implementar y probar el concurso especificado por el cliente, finalmente se necesita un analista
de operaciones para colocarlo en producción. Adicionalmente, si el cliente necesita realizar
cualquier cambio en las especificaciones se repite nuevamente este proceso.
Por otro lado, los reportes de actividad de los concursos son realizados por un analista
que recopila la información directamente de la base de datos, la procesa y luego la envía a los
respectivos clientes periódicamente o cuando estos la soliciten.
Se puede concluir que estos procesos son muy lentos y requieren mucho personal, lo
cual genera retrasos de respuesta al cliente, mayor probabilidad de fallas y poca reutilización de
software. De allí surge otro objetivo del proyecto de pasantía que consiste en desarrollar una
consola o portal Web desde donde el cliente de Conectium Limited o el analista de producto
responsable puedan crear de forma automatizada los concursos. De esta forma se mejora la
eficiencia dentro de la empresa y se brinda mejor calidad de servicio a los clientes.
7
3.1 Objetivo General:
Diseñar e implementar una plataforma que integre las funcionalidades de creación,
mantenimiento y reportes de todo tipo de concursos SMS. Esta plataforma estará constituida
por una herramienta Web y un sistema de procesamiento de mensajes de texto.
En la primera fase del desarrollo de la herramienta Web se incluirá únicamente el
desarrollo de las siguientes secciones: Administración, Reportes y Concursos. Sin embargo, en
el módulo de concurso se desarrollará únicamente la sección de Trivias y Comentarios, que
integran las funcionalidades de creación, edición, verificación, sorteos y visualización de
aquellos participantes con mayor número de mensajes o puntos.
3.2 Objetivos Específicos:
• Desarrollar un programa que permita manejar las sesiones y la interacción entre los
usuarios y los concursos, utilizando patrones de diseño de tipo estructural, creación y
comportamiento. Módulo de Manejo de concursos y procesamiento de sesiones.
• Implementar varias interfaces con el sistema IMG (Internet Message Gateway) para la
transmisión y recepción de mensajes de texto. Módulo de Conexión con la red móvil celular.
• Desarrollar una aplicación Web, utilizando el patrón de diseño MVC Modelo Vista
Controlador, para la administración, generación y reportes de los concursos SMS.
• Implementar una arquitectura para la persistencia de datos, basada en el patrón de diseño
DAO (Data Access Objects), con el fin independizar el manejador de datos.
8
4 Marco Teórico
En este capítulo, serán definidos algunos términos y conceptos específicos del tema a
tratar. Son tomados de varios autores reconocidos en el área.
.
4.1 Definición de SMS
“SMS significa Servicio de Mensajes Cortos (En inglés, Short Message Service). Es un
método de comunicación que envía texto entre teléfonos celulares. También es posible desde
computadoras o dispositivos móviles, a teléfonos celulares y viceversa. Se le llama “corto”
porque el tamaño máximo del mensaje es de 160 caracteres (letras, números o símbolos del
alfabeto Latino). Para otros alfabetos como el chino, el tamaño máximo es de 70 caracteres”. [2]
“El SMS fue creado en Europa a finales de los años 1980’s cuando se incluyo dentro de
la tecnología GSM, inicialmente se ideó para dejar mensajes cortos a usuarios de la telefonía
celular para cuando tuviesen el teléfono apagado o sin cobertura“. [Ob. Citada]
4.2 Funcionamiento del SMS
“Los teléfonos celulares utilizan un canal especial de comunicación con la celda, llamado el
canal de control, que se utiliza para mantener en la red al usuario, hacer y recibir llamadas. El
canal de control funciona como vía para enviar los SMS. Cuando se envía un SMS, el teléfono
desde donde se origina lo envía a la celda a través del canal de control, luego va desde la torre
hasta el SMS Centre, el cual lo redirecciona hasta la otra torre donde se encuentra el teléfono
destinatario, una vez ahí la torre hace la entrega”. [Ob. Citada]
9
Figura 1.Funcionamiento Del SMS. [2]
4.3 SMS Centers (SMSC)
“Cuando un usuario envía un mensaje de texto a otro usuario, el mensaje se almacena
en el SMSC, el cual lo entrega a su destinatario final en el momento que esté disponible en la
red; a esto se le llama guardar y reenviar. Usualmente el SMSC se puede configurar para definir
los tiempos para guardar los mensajes”. [3]
“Un mensaje puede venir también desde una aplicación, por ejemplo, un buzón de
correos de voz enviando alertas de mensajes de voz. Los operadores telefónicos permiten a
algunas empresas interactuar con su SMSC para enviar o recibir mensajes. Desde el punto de
vista del SMSC, estas aplicaciones son llamadas SME (En inglés, Short Message Entities)”.
[Ob. Citada]
4.3.1 Protocolos de comunicación
"Para la transmisión y recepción de mensajes SMS, los SMSC tienen interfaces de redes
cableadas, así como también interfaces con la red móvil”. Se han definido un número de
protocolos para poder interactuar con los SMSC desde las redes cableadas:
• SMPP (Short message peer-to-peer).
• EMI/UCP (External Machine Interface/Universal Computer Protocol).
• CIMD (Computer Interface to Message Distribution).
• OIS (Open Interface Specification). [Ob. Citada]
10
4.4 Protocolo SMPP
"El SMPP es un protocolo estándar de las telecomunicaciones para intercambiar
mensajes SMS entre dos nodos entidades SMS como lo son los SMS Centers Frecuentemente
es utilizado para permitir a las aplicaciones de terceros (Ej. Proveedores de servicios de valor
agregado como lo es Conectium Limited) enviar y recibir mensajes de forma masiva. EL SMPP
fue originalmente diseñado por Aldiscon, una pequeña empresa irlandesa. En 1999, paso a ser
parte del SMS Forum”. [4]
“Está basado en pares de solicitud y respuesta de PDUs (Protocol Data Units, o
paquetes) intercambiados por conexiones TCP/IP o X.25 SVC3. Los PDU son codificados en
formato binario por eficiencia. Las versiones mas utilizadas son la 3.3 y la 3.4 que permite la
opción de un transmisor-receptor sobre una sola conexión”. [Ob. Citada]
4.5 Arquitectura de Tres Capas Cliente/Servidor
"La arquitectura del software de tres o más capas nace en los años 1990s para superar
las limitaciones de la arquitectura de dos capas. La capa adicional (capa intermedia) se
encuentra entre la interfaz del usuario (cliente) y el manejador de datos (servidor). Esta capa
intermedia provee el manejo de procesos de la lógica del negocio, puede soportar cientos de
usuarios, utilizando varios mecanismos. La arquitectura de tres capas es utilizada cuando se
necesita un diseño de cliente/servidor efectivo y distribuido que provea un mejor desempeño,
flexibilidad, mantenimiento, reutilización y escalabilidad, al mismo tiempo esconder del usuario
toda la complejidad del procesamiento distribuido. Estas características han hecho que la
arquitectura de tres capas sea muy popular en las aplicaciones de Internet y otros sistemas de
información”. [5]
11
Figura 2. Arquitectura de tres capas. [6]
“Una arquitectura de tres capas, incluye una capa superior donde residen la interfaz
gráfica y servicios del usuario. Una segunda capa que se encarga de proveer servicios para el
manejo de procesos (administración y monitoreo) que son utilizados entre aplicaciones. La
segunda capa o capa intermedia también es llamada servidor de aplicaciones. La centralización
de los procesos lógicos hace que la administración y los cambios sean mucho más fáciles,
simplemente se realiza el cambio una sola vez dentro del servidor de la capa de aplicación y
automáticamente está disponible para todos los usuarios. Con otro diseño de arquitectura se
tendría que hacer el cambio en cada aplicación del usuario”. [Ob. Citada]
“La tercera capa o capa de datos, provee la funcionalidad del manejo optimizado de
servicios de datos y archivos. El manejo de datos asegura que la data sea consistente en todo
el sistema distribuido, utilizando funciones como bloqueo, consistencia y replicación de datos.
La conectividad entre las capas puede ser modificada según los requerimientos de datos y
servicios por parte del usuario”. [Ob. Citada]
“En algunos casos la capa intermedia se divide en varias unidades, en estos casos la
arquitectura es referida como multi-capa. Por ejemplo, algunas aplicaciones de Internet, tienen
clientes escritos en HTML y servidores de aplicaciones en C++ o Java, la brecha entre estas
dos capas es muy grande para que trabajen en conjunto. A pesar de esto, se utiliza otra capa
intermediaria; un servidor Web con un lenguaje de tipo scripting (JSP, ASP, etc.) que se
encargue de procesar las solicitudes de los clientes, y genere el HTML a partir de los servicios
de la capa de aplicación”. [Ob. Citada]
12
4.6 Metodología de Desarrollo Aplicada
La metodología basada para el desarrollo del proyecto fue la de Rational Unified Process
(RUP). Se dice que fue basada porque no se siguió estrictamente sus lineamientos, sin
embargo se utilizaron varios aspectos y mejores prácticas que ayudan desarrollar un mejor
software.
En pocas palabras, RUP es un proceso de desarrollo de software. “Provee un enfoque
disciplinado para asignar tareas y responsabilidades dentro de una organización de desarrollo.
Su principal objetivo es generar software de alta calidad que cumpla con las necesidades de los
usuarios finales, dentro de un tiempo y presupuesto predecible. RUP adopta las mejores
prácticas del desarrollo de software, comprobadas a lo largo del tiempo por organizaciones
exitosas: desarrollar iterativamente, manejar requerimientos, arquitectura basada en
componentes, modelar visualmente el software, verificar continuamente la calidad y controlar
cambios del software. Como ningún proceso es ideal para todos los desarrollos de software,
RUP es configurable y se adapta a cualquier tipo de organización, desde pequeñas con pocas
personas, hasta grandes donde existen varios equipos de desarrollo”. [7]
4.6.1 Dos dimensiones del proceso de desarrollo
• “El eje horizontal representa el tiempo, mostrando la estructura dinámica del proceso, y
es expresado en términos de ciclos, iteraciones, fases e hitos”. [Ob. Citada]
• “El eje vertical representa el aspecto estático del proceso, es expresado en términos de
actividades, trabajadores, flujo de trabajos y artefactos”. [Ob. Citada]
13
Figura 3. RUP en dos dimensiones. [7]
4.6.2 Estructura Dinámica de RUP
"Es la organización del proceso a lo largo del tiempo. La vida de un software está
compuesta por varios ciclos, cada ciclo representa una nueva generación del producto”. [Ob.
Citada]. RUP divide cada ciclo en cuarto fases:
4.6.2.1 Fase de Inicio
“Durante la fase de inicio, se establecen los casos del negocio para el sistema y se
define el alcance del proyecto. Se identifican los actores que interactuarán con el sistema, esto
implica definir los casos de uso y describir a los más significantes. También se incluyen los
factores de éxito, riesgos potenciales y la estimación de recursos necesarios para el proyecto”.
[Ob. Citada]
4.6.2.2 Fase de Elaboración
“El propósito de la fase de elaboración es analizar el dominio del problema, establecer
una arquitectura base, crear el plan de desarrollo, y eliminar los riesgos más grandes del
proyecto. Para alcanzar los objetivos es necesario tener una visión amplia y poco profunda del
proyecto. Las dediciones de la arquitectura deben ser hechas con el entendimiento total del
sistema: su alcance, su funcionalidad principal y los requerimientos no funcionales. Durante las
primeras iteraciones de esta fase se obtiene un prototipo ejecutable de la arquitectura. La idea
14
es que el esfuerzo se concentre en los casos de uso críticos, que usualmente representan los
mayores riesgos técnicos”. [Ob. Citada]
4.6.2.3 Construcción
“Durante esta fase, todos los componentes y funcionalidad restante de la aplicación son
desarrollados e integrados dentro del producto, al mismo tiempo de que son cuidadosamente
probados. La fase de construcción representa el proceso de manufactura del producto y hace
énfasis en el manejo de recursos, optimizar costos, cumplir con el plan de trabajo y asegurar la
calidad”. [Ob. Citada]
4.6.2.4 Transición
“Tiene como propósito la transición del producto a los usuarios finales. Incluye
actividades como: pruebas de versiones “beta”, operación paralela con sistema el cual se
reemplaza, adaptación de bases de datos, entrenamiento de usuarios, pasar el producto a los
equipos de ventas. También se hace un esfuerzo en ajustar, corregir errores, y mejorar la
usabilidad y el desempeño del software”. [Ob. Citada]
“Cada una de estas fases concluyen con un hito bien definido, en cada hito se toman
decisiones críticas, por ende se deben cumplir los objetivos claves. Cada una tiene un propósito
distinto y se pueden realizar una o más iteraciones en cada fase, según el plan de desarrollo”.
[Ob. Citada]
4.6.3 Estructura Estática de RUP
"Un proceso representa el quién esta haciendo qué, cómo y cuándo. En RUP se
representa utilizando cuarto elementos en el modelo. Los Trabajadores (“Workers”) representan
el quién; los Artefactos el qué; las Actividades el cómo; y el Flujo de Trabajo (“Workflow”) el
cuándo”. [Ob. Citada]
15
4.7 Patrones de Diseño
“Los patrones de diseño son descripciones de objetos y clases que se comunican entre sí
y que son adaptados para resolver un problema de diseño en un contexto determinado”. [8] En
general un patrón tiene cuarto partes esenciales:
“El nombre del patrón es un término que se utiliza para describir un problema de diseño,
y su solución en una palabra o dos. El problema describe cuando aplicar el patrón, explica el
problema y el contexto para el cual es utilizado. La solución describe los elementos que
conforman el diseño, sus relaciones, responsabilidades y colaboraciones. La solución no
describe una solución concreta en particular, ya que un patrón es una plantilla que puede ser
aplicado en distintas soluciones. Las consecuencias son los resultados y costos de haber
aplicado el patrón”. [Ob. Citada]
4.7.1 Clasificación de Patrones
“Los patrones de diseño se clasifican de dos formas: la primera, por su propósito y la
segunda, por su alcance. Los patrones pueden tener propósitos de creación, estructural o de
comportamiento. Los patrones de creación se enfocan de la construcción de los objetos, los
estructurales manejan la composición de clases u objetos, y los patrones de comportamiento se
caracterizan por la forma en que las clases u objetos interactúan y distribuyen
responsabilidades. El otro criterio de alcance especifica si el patrón se aplica a una clase o a
objetos”. [Ob. Citada]
4.7.1.1 Patrones de Creación
“Básicamente abstraen el proceso de instanciación. Ayudan a hacer un sistema
independientemente de cómo son creados, compuestos y representados sus objetos. Un patrón
de creación para una clase utiliza la herencia para variar el tipo de clase concreta que ha sido
creada; en cambio para los objetos, el patrón delegará la instanciación a otro objeto”. [Ob.
Citada]
“Los patrones de creación son importantes en sistemas que dependen cada vez más en
la composición de objetos que en la herencia de clases. Mientras esto ocurra, el énfasis se aleja
16
de codificar un conjunto fijo de comportamientos, hacia un menor conjunto de comportamientos
fundamentales que pueden ser mezclados entre si para crear unos más complejos. Por ende
crear objetos con comportamientos particulares requiere mas que simplemente instanciar una
clase”. [Ob. Citada]
“Existen dos temas importantes en estos patrones, primero todos encapsulan
conocimiento de las clases concretas que el sistema utiliza. Segundo esconden como las
instancias son creadas y colocadas juntas. Todo lo que el sistema sabe desde más arriba son
las interfaces de los objetos definidas por clases abstractas. En consecuencia, los patrones de
creación dan una gran flexibilidad en qué se construye, quién lo construye, cómo lo construye, y
cuando. Permiten configurar un sistema con objetos que varían en estructura y funcionalidad.
La configuración puede ser estática (a tiempo de compilación) o dinámica (en tiempo de
ejecución)”. [Ob. Citada]
Algunos de los patrones de creación son: Prototipo, Fábrica Abstracta, Builder o Constructor,
Singleton y Método de Fabricación
4.7.1.2 Patrones Estructurales
“Los patrones estructurales se enfocan en cómo se componen clases y objetos para
formar estructuras más grandes. En el caso de clases utilizan herencia para componer
interfaces o implementaciones. Por ejemplo, en el caso de la herencia múltiple que mezcla dos
o más clases, genera como resultado una clase que combina las propiedades de las clases
padre. Este patrón es útil para hacer que dos librerías independientes funcionen juntas“. [Ob.
Citada]
“En vez de componer interfaces o implementaciones, en el caso de patrones
estructurales de objetos se describen formas para componer objetos que realizan una nueva
funcionalidad. La flexibilidad agregada de componer objetos, viene de la habilidad de cambiar la
composición en tiempo de ejecución, lo cual es imposible con una composición estática”. [Ob.
Citada]
Dentro de los patrones estructurales se tiene: Decorador, Adaptador, Fachada, Puente,
Proxy y Composite
17
4.7.1.3 Patrones de Comportamiento
“Los patrones de comportamiento tienen que ver con algoritmos y la asignación de
responsabilidades entre objetos. Adicionalmente estos patrones no sólo describen objetos y
clases, sino que también describen patrones de comunicación entre ellos. Se caracterizan por
un complejo control de flujo que resulta difícil de entender en tiempo de ejecución. La idea es
sólo concentrarse en la forma en que los objetos están interconectados”. [Ob. Citada]
“En el caso de las clases los patrones de comportamiento utilizan herencia para distribuir
el comportamiento entre ellas. Un ejemplo es el patrón Método Plantilla, que es una definición
abstracta de un algoritmo, lo define paso a paso. En el caso de patrones de comportamiento
para objetos utilizan composición en vez de herencia. Algunos describen como un grupo de
objetos cooperan para realizar una tarea que ningún objeto puede llevar a cabo solo”. [Ob.
Citada]
Los patrones de comportamiento más comunes son: Interpretador, Método Plantilla, Cadena
de Responsabilidad, Comando, Iterador, Mediador, Memento, Flyweight (“Peso mosca”),
Observador, Estado, Estrategia y Visitante.
18
5 Fase de Inicio:
Este capítulo presenta todas las actividades realizadas durante la fase de inicio de la
metodología RUP. También se señalan algunos artefactos resultantes de las actividades.
5.1 Visión del Proyecto
La tarea de implementar un concurso SMS implica varios procesos dentro de la
empresa. Generalmente el cliente decide cuáles especificaciones tendrá su concurso, luego
pasa a los analistas de producto quienes revisan los requerimientos, por último se utilizan
analistas de sistemas que desarrollan el programa del concurso, se prueba y luego se pone en
producción. Cualquier cambio que se solicite tiene que volver a pasar por gran parte de este
proceso.
Dada la complejidad del proceso y los retrasos en el tiempo de entrega hacia los
clientes, se ideó una plataforma interactiva (ActiveSMS) desde donde los clientes pueden
realizar cualquier tipo de concurso SMS de manera fácil y rápida, la plataforma tiene la
funcionalidad de:
• Crear, modificar y eliminar concursos SMS (Primera fase sólo Trivias y Comentarios) a
través de un portal Web.
• Manejo de sesiones entre los usuarios y concursos (Flujo de los juegos).
• Visualizar reportes de actividad y los mejores resultados de los participantes.
• Administrar usuarios, operadoras y números de acceso (Shortcodes).
• Realizar sorteos en varias modalidades.
El documento visión del proyecto se encuentra en el Apéndice A, para la descripción del
de los requerimientos de la empresa ver el Apéndice F.
5.1.1 Módulo de lógica de concursos y procesamiento de sesiones: ¿Cómo funcionan los
concursos? y ¿Qué contenido manejarán los concursos?
19
Para poder participar y llevar a cabo un concurso, es necesario enviar un mensaje desde
un teléfono celular con la palabra clave indicada a un número determinado y luego el operador
telefónico redirecciona el mensaje a los sistemas de Conectium Limited. Cuando el sistema
ActiveSMS recibe el mensaje, verifica la palabra clave y si corresponde a un concurso activo, se
crea una sesión entre el concurso y el número telefónico desde donde se encuentra
participando la persona. A partir de este momento, todos los mensajes recibidos se dirigirán
directamente hacia la sesión del concurso, siempre y cuando esté activa.
Una vez que llega el mensaje a la sesión del concurso, es procesado y se responde de
una forma específica. La idea es que este comportamiento de procesamiento y respuesta pueda
ser extendido, modificado o combinado con otros dependiendo de los requerimientos
especificados por el cliente. En fin, la principal función del módulo de manejo de los concursos
es procesar los mensajes entrantes, verificar el contenido y dar un mensaje de respuesta a
solicitud previa.
Por otro lado, el módulo de manejo de concursos realiza operaciones de mantenimiento
de sesiones, ya que es posible que un participante deje de enviar mensajes y por lo tanto la
sesión se mantenga abierta hasta que expire un tiempo previamente preestablecido.
Para evitar el acceso de usuarios a concursos que no se encuentran abiertos al público
este módulo se encarga de filtrar los teléfonos no permitidos para hacer pruebas del concurso.
Otra de las funciones es poder hacer cambios de concursos durante una misma sesión.
5.1.2 Módulo de Conexión con la red móvil celular. ¿Cómo se envían y reciben los
mensajes de texto?
Dentro de Conectium Limited existe un sistema ya probado de envío y recepción de
mensajería SMS: el IMG (Internet Message Gateway). Este sistema se utiliza actualmente en
varios países y maneja una alta cantidad diaria de mensajes SMS, además posee otras
funcionalidades interesantes de control de conexiones con los operadores telefónicos.
Para que funcione correctamente la plataforma ActiveSMS es necesario poder enviar y
recibir mensajes SMS, esto se logra conectándose con la red de telefonía celular. Para
aprovechar el sistema existente de envíos y recepción, se necesitará desarrollar un módulo que
20
permita establecer una comunicación de mensajes desde ActiveSMS con el IMG y viceversa.
Se necesita un mecanismo robusto de comunicación entre los dos sistemas, donde se
minimice la cantidad de mensajes que no se envían de vuelta al usuario. Por ejemplo, un
usuario envía un mensaje al sistema pero éste no le responde porque no se encuentra
disponible en ese instante. Este caso genera muchas molestias al público que participa porque
se le cobra el mensaje sin haber recibido respuesta. Debido a este problema se piensa utilizar
un servidor de colas de mensajes (Message Queue) que sirva como intermediario para evitar
esta situación.
Sin embargo el IMG ya posee una interfaz para conectarse con otros sistemas a través
de una llamada HTTP. Esta forma de integrarse con el IMG es mucho más sencilla y rápida
aunque no tan robusta. De todas maneras se implementará una interfaz adicional en el modulo
de conexión conjuntamente con el módulo Web, para proveer la opción de comunicarse con
el IMG de esta forma.
5.1.3 Módulo de Administración Web. ¿Cómo se controla al sistema?
Uno de los requisitos indispensables para la plataforma es el módulo de administración
vía Web, el cual permitirá administrar todo lo referente a la plataforma de forma rápida y
sencilla. Se compone de 3 secciones: Concursos, Administración y Reportes. Gracias a esto
el proceso de creación de concursos pasa de ser tarea de un grupo de empleados (Analistas de
sistemas y de producto) a tarea de tan sólo un Analista de Producto, o mejor aún se les puede
permitir el acceso a los clientes de Conectium Lugar para que generen, modifiquen y vean la
actividad de sus concursos desde cualquier lugar vía Web.
Un prototipo detallado del módulo de administración Web realizado por la empresa, se
puede ver en el apéndice G.
5.1.4 Módulo de Persistencia de Datos. ¿Cómo se guarda toda la información del sistema?
Todos los módulos anteriores exceptuando el de conexión con la red celular, necesitan
de un sub-sistema que se encargue de almacenar información; para esto se idea un sistema de
21
persistencia que funciona independientemente del manejador de datos, es decir, los datos se
pueden almacenar en una base de datos, un archivo XML, etc.
5.2 Actores y principales casos de uso:
A continuación se presentan los principales actores y casos de uso del sistema:
5.2.1 Actores
Nombre Descripción Rol
Gerente de la plataforma Persona interna encargada del funcionamiento y monitoreo de la plataforma ActiveSMS.
Administra los shortcodes, pruebas, y usuarios registrados en el sistema. Ve todos los concursos creados. Posee todos los privilegios de la plataforma.
Usuario Gerente Persona externa designada por el cliente que contrata el servicio. Puede ser interna.
Se encarga de crear, modificar y eliminar los concursos
Usuario Monitor Persona externa designada por el cliente que contrata el servicio. Puede ser interna.
Se encarga de observar el estatus de los concursos así como también los resultados.
Usuario Final Persona que juega el concurso a través de su teléfono.
Envía y Recibe mensajes hacia el número del concurso.
5.2.2 Casos de Uso
5.2.2.1 Módulo de Manejo de concursos:
1. Jugar concursos: procesar los mensajes entrantes de los usuarios para poder llevar a
cabo distintos tipos de concursos en los que se desea participar. Incluye los casos de
uso: iniciar sesión, procesar mensajes y terminar sesión.
2. Cambiar de concurso: se le da la posibilidad a un usuario que se cambie desde un
concurso en marcha a otro.
22
5.2.2.2 Módulo de Conexión con la red Celular
1. Enviar/Recibir mensajes con la red móvil celular, se envían y se reciben mensajes hacia
el sistema IMG, que luego serán entregados a los distintos SMSC de las operadoras
telefónicas y viceversa.
5.2.2.3 Módulo Web:
1. Crear/Modificar/Eliminar operadoras, short codes y usuarios del portal Web. Esta
sección del módulo Web es totalmente administrativa y es restringida a los usuarios
finales.
2. Crear/Modificar/Eliminar/Hacer Sorteos/Visualizar mensajes/ concursos, en esta parte se
configuran los concursos, en esta primera versión solo podemos configurar Trivias y
Comentarios. Esta información será proporcionada al módulo de manejo de concursos
para poder llevar a cabo el concurso previamente configurado.
3. Ver resumen/Ver detallado de todos los mensajes. Se presenta de una forma organizada
el movimiento de los mensajes procesados por la plataforma.
5.2.2.4 Módulo de Persistencia de Datos
1. Buscar/Insertar/Actualizar/Eliminar cualquier entidad interna del sistema que necesite
ser almacenada en alguna base de datos.
El documento de casos de uso del sistema ActiveSMS se encuentra en el Apéndice B.
5.3 Glosario del Sistema
Todos los términos y abreviaturas utilizadas para describir al sistema ActiveSMS se
encuentran definidos en el documento de glosario del sistema. Debido a la gran cantidad de
conceptos y su extensión, el glosario es presentado en el Apéndice C.
23
5.4 Estudio Inicial de Riesgos
Durante la primera etapa del proyecto, se realizó un breve estudio de los riesgos más
importantes que pudiesen afectar a la calidad final del producto a desarrollar. Los más
importantes fueron los siguientes:
• Utilización de nuevas tecnologías, poca experiencia del desarrollador con la tecnología
de colas.
• Aprendizaje de la arquitectura del software de transmisión y recepción de mensajes de
texto (IMG) para realizar la integración entre los sistemas.
• Gran cantidad de requerimientos solicitados por la empresa.
• Complejidad de la aplicación, ya que se necesita que posea mucha flexibilidad para
desarrollos futuros.
Para una descripción más detallada, que incluye la magnitud, los impactos, los
indicadores y la estrategia de mitigación ver el Apéndice D.
5.5 Plan de Desarrollo del Software
Figura 4 Plan de desarrollo del software. Elaboración propia.
El plan detallado del desarrollo de software ActiveSMS se encuentra en el Apéndice E
5.6 Hitos Alcanzados
• Lista de requerimientos muy claros y específicos.
• Arquitectura preliminar.
24
6 Fase de Elaboración
Durante esta fase se concibe el dominio del problema, se analiza y se identifican los
casos de uso más riesgosos del proyecto. El objetivo fundamental de esta fase es minimizar
estos riesgos que ponen en juego el éxito del desarrollo. Durante esta fase se realizaron las
actividades propuestas por la metodología RUP, de las cuales se generaron los siguientes
artefactos:
6.1 Vistas de la arquitectura del Software
“Para representar la arquitectura del software se han escogido varias vistas. Cada una
involucra un conjunto de requerimientos funcionales y no funcionales, específicos para cada
uno de los stakeholders: usuarios, diseñadores, gerentes, ingenieros, etc.” [9]
“Estas vistas capturan las decisiones más significativas del diseño, mostrando como la
arquitectura se descompone en componentes, y como éstos están interrelacionados entre sí.
Las decisiones tomadas de diseño deben estar estrechamente relacionadas con los
requerimientos, funcionales y no funcionales del software, sin embargo estas decisiones
también afectan a los requerimientos y en diseños futuros”. [Ob. Citada]
Se utiliza el Lenguaje de Modelado Universal (UML), como notación de todas las vistas
de la arquitectura. En la metodología RUP se llaman las “4+1 vistas” que son descritas a
continuación a excepción de la vista de proceso:
6.2 Las 4 + 1 Vistas de la arquitectura
6.2.1 Vista de Casos de Uso
“La vista de casos de uso recopila la mayoría de los requerimientos funcionales e
ilustran los distintos escenarios en los cuales pueden ser ejecutados los casos de uso. Los
casos de uso son descripciones de la interacción entre un usuario y el sistema. Los casos de
uso sirven como contrato entre el cliente y el desarrollador y son una parte esencial para las
siguientes actividades durante el proceso de desarrollo. En esta vista se incluyen los diagramas
25
de caso de uso y el documento de casos de uso extendido”. [Ob. Citada]
6.2.1.1 Diagrama de Casos de uso
El diagrama de casos de uso del sistema ActiveSMS sirve para ilustrar los actores,
casos de uso y las relaciones entre ellos. Se pueden organizar por módulo del sistema, pero en
este caso se representan todos en un sólo diagrama. El diagrama de casos de uso se
encuentra en el apéndice B.
6.2.2 Vista Lógica
"Para entender la estructura y la organización del diseño del sistema utilizamos la vista
lógica, ya que ilustra los subsistemas o módulos, paquetes y clases que componen a toda la
arquitectura del sistema. También representa el dominio y la solución del problema. Esta vista
se refina a lo largo de las iteraciones del proceso de desarrollo”. [Ob. Citada]
Los artefactos que se utilizaron para describir esta vista son: el modelo conceptual y el
diagrama de clases. También señalamos los patrones que utilizamos en el diseño de los
distintos módulos del sistema, que explican detalladamente el porqué y cuál es la ventaja de
utilizar este tipo de patrones dentro del sistema ActiveSMS.
6.2.2.1 Modelo Conceptual o del Dominio
Aquí se describen todos los aspectos sobre el problema a resolver, este modelo no
contiene ningún tipo de solución solo se encarga de modelar y relacionar los conceptos de la
realidad que rodean al problema que se quiere resolver. Ver apéndice H.
6.2.2.2 Diagramas de Clases
“El Diagrama de Clases es el diagrama principal de diseño y análisis para un sistema.
En él, la estructura de clases del sistema se especifica, con relaciones entre clases y
estructuras de herencia. Durante el análisis del sistema, el diagrama se desarrolla buscando
una solución ideal. Durante el diseño, se usa el mismo diagrama, y se modifica para satisfacer
los detalles de las implementaciones. La definición de clase incluye definiciones para atributos y
operaciones”. [Ob. Citada]
26
En la fase de elaboración se generaron varios diagramas de clases con los elementos
básicos de la arquitectura con el fin de diseñar e implementar los componentes con mayor
riesgo. Durante las próximas fases se agregaron y modificaron elementos a los diagramas. Los
diagramas de clases por módulos se encuentran en los Apéndices I, J, K, L.
6.2.2.3 Diagramas de Secuencia
“El Diagrama de Secuencia es uno de los diagramas más efectivos para modelar
interacción entre objetos en un sistema. Un diagrama de secuencia se modela para cada caso
de uso. Contiene detalles de implementación del escenario, incluyendo los objetos y clases que
se usan para implementar el escenario, y mensajes pasados entre los objetos”. [Ob. Citada]
Los diagramas de secuencia detallados, para los casos de uso principales se pueden
encontrar en los Apéndices M, N.
6.2.3 Vista de Implementación
“En esta vista se describirá la organización estática del proyecto, es decir, cómo están
organizados los módulos, subsistemas o paquetes del sistema. Esta vista tiene como objetivo
guiar el desarrollo del software, distribución, agrupamiento y visibilidad. Además esta vista sirve
para la asignación de requerimientos al equipo de desarrollo, para la planificación de costos y
tiempos, para el monitoreo y justificar la reusabilidad, portabilidad y seguridad del software”.
[Ob. Citada]
El sistema ActiveSMS consta de cuatro módulos, de esta forma se puede representar el
sistema completo de la siguiente forma:
El módulo de lógica de concursos: se implementarán las clases que manejan todo el
proceso de sesiones con los usuarios; de la misma forma, clases para manejar los concursos,
sus comportamientos y filtros de números telefónicos. Dentro de este módulo existen clases
implementadas para los concursos tipo trivias y comentarios. Ver apéndice I.
El módulo de conexión con la red celular: consta de la implementación de dos
módulos independientes, uno lo representa el software IMG-queue, y el otro el sub-sistema de
27
conexiones que se encuentra dentro del paquete principal. Ver apéndice J.
El módulo Web: se implementará bajo la arquitectura cliente/servidor de tres capas, utilizando
un esquema de trabajo para aplicaciones Web facilitando la implementación. Ver apéndice K.
El módulo de persistencia: se implementará el patrón DAO, utilizando la tecnología Hibernate.
Ver apéndice I.
Para visualizar mejor qué clases estructuran cada módulo del sistema ActiveSMS, se
recomienda ver el diagrama de clases. A continuación se presenta la Fig. 5 que contiene la
distribución de los subsistemas y paquetes.
Figura 5. Vista Implementación. Elaboración Propia.
6.2.4 Vista de Despliegue
El sistema ActiveSMS, después de haber estado en pruebas servidores de desarrollo
(Pre-Producción) se decide instalarlo y ejecutarlo en el servidor de aplicaciones de producción
(NAP) de Conectium Limited. La topología del sistema consiste en la plataforma de mensajería
del operador telefónico, y los sistemas de Conectium Limited.
Los teléfonos celulares envían el mensaje al SMS Center, este mismo reenvía el
28
mensaje hacia el IMG a través de un enlace dedicado (VPN) utilizando varios protocolos,
generalmente el mas utilizado es el SMPP. Una vez que llega al IMG se genera una llamada
HTTP al servidor de aplicaciones ActiveSMS, quien da el mensaje de respuesta y se envía por
el mismo camino hasta el usuario final.
Figura 6. Vista de Despliegue. Elaboración Propia.
Hardware
Servidor de Aplicaciones para ActiveSMS (Web, Base de Datos, Colas): HP ProLiant DL320
(Rack). Especificaciones: Intel Pentium D con EM64T, 2 GB de RAM, Unidad de disco tipo Hot
plug 3.5” SATA
Software
Servidor de Aplicaciones (Web, Base de Datos, Colas):
• Sistema operativo: Linux Fedora Core 5, Kernel Linux 2.6.11.
• Servidor WEB: Apache Tomcat v.5.5
• Manejador Base de Datos: Postgres v 8.0
• Servidor de Colas: Apache ActiveMQ v 4.0.1
29
6.3 Decisiones de Diseño
6.3.1 Módulo de Lógica de Concursos y Manejo de sesiones
Para el diseño de este módulo se aplicaron patrones de tipo estructurales, de
comportamiento y de creación. El objetivo es resolver los problemas de diseño orientado a
objetos, utilizando técnicas ya probadas que llevan a un más alto nivel de abstracción los
componentes del sistema. A continuación, se describe en detalle qué patrones y por qué se
utilizaron dentro del diseño de este módulo.
Fábrica Abstracta: se utiliza para crear la fábrica indicada del tipo de concurso que
crea una sesión especial entre el participante y el concurso, debido a que existen varios tipos de
concursos y en un futuro una posibilidad de que existan muchos más.
Figura 7. Fábrica Abstracta. [8]
Método Plantilla: se utiliza para especificar los pasos del algoritmo que maneja los
estados de un concurso especifico. Se utiliza conjuntamente con los decoradores para
manipular el comportamiento de los concursos.
Singleton: son utilizados para el manejo de sesiones, concursos y teléfonos de prueba.
La idea es tener sólo una instancia de estos manejadores de modo que no es necesario utilizar
varias instancias a la vez. Otra de las razones es para tener una lista de atributos que se
pueden compartir entre sesiones.
30
Decoradores: se utilizan para alterar el comportamiento de los concursos, en este caso
se utilizan varios decoradores sobre una trivia genérica para agregar funcionalidades extra. Sólo
se le aplicó a las trivias en la primera fase del sistema.
Figura 8. Decorador. [8]
¿Cuál es la ventaja? La principal ventaja de utilizar este patrón es poder realizar varias
combinaciones de varios comportamientos a la vez, esto da la gran flexibilidad de crear un
concurso con las funcionalidades deseadas. Por ejemplo, si un cliente necesita una Trivia con
preguntas aleatorias, puntaje y que dé un premio al n-ésimo ganador, no es necesario
implementar una trivia con estos comportamientos, con sólo aplicarle los decoradores deseados
obtenemos el comportamiento que necesitemos.
Desarrollos Futuros: En el futuro es probable que se requieran más comportamientos.
En el caso que un cliente desee un comportamiento especial que no exista, basta con tan sólo
implementar un nuevo decorador. Una vez listo se agrega al módulo de concursos y funciona
sin ningún problema.
6.3.2 Módulo de Conexión con la red móvil celular
La solución propuesta para este módulo fue crear una versión del IMG pero que enrute
todos los mensajes entrantes hacia un servidor de colas, para luego ser procesado por el
31
módulo de manejo de concursos, que se conectara a través de este módulo. Una vez
procesado, se genera un mensaje de respuesta que es enviado de nuevo al servidor de colas y
finalmente entregado al IMG para ser remitido a la red celular.
Otra solución fue la idea de crear un Servlet que hiciera la misma función de recibir
mensajes a través de una solicitud HTTP. La ventaja de esta propuesta es que el IMG ya posee
una forma de enviar solicitudes HTTP, entonces no se necesitaría modificar nada del IMG, sólo
configurarlo para que envíe las solicitudes hacia el sistema ActiveSMS.
6.3.3 Módulo de Persistencia de Datos
Este módulo fue diseñado con el patrón DAO (Data-Access-Objects):
Figura 9. Patrón DAO. [10]
Las ventajas más importantes de utilizar este patrón:
• “Da un acceso transparente a la fuente de datos, ya que la implementación se
esconde tras las interfaces”. [10]
• “Permite migrar a otros manejadores de datos fácilmente”. [Ob. Citada]
• “Centraliza la capa de datos en una capa separada”. [Ob. Citada]
32
6.3.4 Módulo de Administración Web
Se toma la decisión de utilizar el patrón MVC (Modelo, Vista, Controlador) como base del
módulo Web.
• Modelo: Esta es la representación específica de la información con la cual el sistema
opera. La lógica de datos asegura la integridad de éstos y permite derivar nuevos datos.
[11]
• Vista: Este presenta el modelo en un formato adecuado para interactuar, usualmente la
interfaz de usuario. [Ob. Citada]
• Controlador: Este responde a eventos, usualmente acciones del usuario e invoca
cambios en el modelo y probablemente en la vista. [Ob. Citada]
6.4 Lista de Requerimientos no funcionales
A continuación se describen los requerimientos que no están especificados en los casos
de uso, y que debe poseer el sistema para su buen funcionamiento:
• Usabilidad: la interfaz Web debe ser rápida de usar, intuitiva y con la misma apariencia
que utilizan los otros sistemas de Conectium Limited.
• Escalabilidad: se debe construir el sistema de forma modular, para poder agregar
mayor funcionalidad a los distintos módulos.
• Desempeño: el sistema debe procesar y responder los mensajes rápidamente. De
desea que el tiempo de procesamiento sea menos a 1 segundo con el fin de soportar
grandes volúmenes de mensajes.
• Robustez: debe soportar grandes cargas de mensajes sin generar errores.
• Disponibilidad: es necesario que el sistema esté activo 99% del tiempo, debido que los
concursos pueden ser utilizados a cualquier hora.
• Seguridad: todos los módulos deben estar protegidos, específicamente el módulo Web
que puede ser visto por el público.
6.5 Hitos Alcanzados
• Diseño general del sistema a implementar.
• Arquitectura definida que cumple con los requerimientos.
• Prototipo funcional del Módulo de manejo de concursos.
• Conocimiento del diseño del IMG.
33
7 Fase de Construcción I
Este capítulo presenta la primera fase de construcción del proceso de desarrollo, la cual
comprende las implementaciones completas del módulo de manejo de concursos y el módulo
de conexión con la red celular diseñados en la fase anterior. También comprende la
realización de las primeras pruebas de funcionalidad y prueba de la arquitectura.
7.1 Implementación de la Arquitectura propuesta:
7.1.1 Módulo de Lógica de Concursos
El módulo de lógica de concursos se implementa como un programa utilizando el
lenguaje Java 5. Puede ejecutarse como una aplicación estándar, o a través de una aplicación
Web (J2EE). Para esta primera fase solo se implementaron las Trivias. Sus componentes
principales son los siguientes:
7.1.1.1 Manejador de Sesiones:
El manejador de sesiones se encarga de crear, mantener y eliminar las sesiones de los
concursos (Trivias en este caso). Cada vez que se procesa un mensaje entrante se verifica lo
siguiente:
• El short code y la operadora desde donde fue generado el mensaje.
• Si esa persona se encuentra jugando un concurso específico, de no ser así se
ordena crear una sesión de un concurso con el mensaje entrante.
• Pasa el mensaje a la sesión.
• Devuelve el mensaje de respuesta, dado por la sesión del concurso.
34
Figura 10. Flujo de mensajes. Elaboración Propia
Vale la pena destacar que las sesiones activas se almacenan en una lista, sin embargo
existen concursos que no se necesitan almacenar. Adicionalmente existe un hilo que revisa
cada minuto las sesiones activas, y elimina aquellas que su tiempo de vida ha expirado o que
su estado es inactivo.
7.1.1.2 Sesiones
Las sesiones se implementan como una clase que extiende de la clase padre “Sesion”.
Cada concurso implementa su clase sesión, que contiene todo lo que implica la mecánica de
funcionamiento. Su responsabilidad es determinar como debe responder el concurso a un
mensaje entrante. El comportamiento de la sesión es posible alterarlo implementando uno o
varios decoradores para esta clase.
35
7.1.1.3 Manejador de Concursos
Su función principal es buscar el concurso según el contenido de un mensaje, cuando se
crea una sesión. Para identificar el concurso se quiere jugar, el manejador tendrá varias
opciones según la configuración:
• Identificación por palabra clave (Keyword): es cuando el contenido del primer mensaje
entrante contiene una o varias palabras que identifica al concurso. La mayoría usan esta
modalidad ya que es posible compartir un mismo shortcode para varios concursos. Por
ejemplo, cuando llega un mensaje desde el shortcode 8080 con la palabra “Futbol”, el
manejador elige el concurso que corresponde a esa palabra clave.
• Identificación por hora: es cuando la hora del primer mensaje entrante cae dentro de
un intervalo de un concurso previamente configurado. Se utiliza la mayoría de las veces
para concursos de tipo comentario, se puede compartir el shortcode siempre y cuando
los intervalos no se solapen. Por ejemplo, un programa de radio que dura desde una
hora determinada a otra quiere recibir los comentarios de los radio escucha. Entonces
se configura el concurso (en este caso comentarios) en el sistema y todos los mensajes
que lleguen dentro del período del programa serán identificados.
• Identificación exclusiva: se utiliza cuando un shortcode es dedicado totalmente a un
concurso. No se puede reutilizar el shortcode con otros concursos de forma simultánea.
Por ejemplo, un concurso para hacer un sorteo de un viaje, donde la gente escribe sus
datos y los envía al número de acceso indicado en la promoción.
Es importante saber que los concursos tienen fecha de inicio y una de finalización, la
identificación de un concurso por parte del manejador dependerá de estas fechas.
7.1.1.4 Concursos
Son las sub-clases que se derivan de la clase padre Concurso y forman toda la variedad
de concursos del sistema. Su única función es almacenar toda la información referente al
concurso. Por ejemplo, la clase Trivia contiene la colección de preguntas, respuestas, puntaje,
etc.
36
7.1.1.5 Manejador de teléfonos de prueba
Cuando un concurso en específico está en proceso de pruebas, el público en general no
debería tener acceso a éste, solamente los usuarios de prueba previamente registrados
pudiesen utilizarlo. La función de este componente es verificar, a la llegada de un mensaje si el
número de teléfono desde donde fue generado pertenece a un usuario de prueba o no. Puede
ser extendido para manejar listas blancas y/o negras que filtran teléfonos no autorizados.
7.1.2 Módulo de Conexión con la Red Celular
Este módulo se conforma de dos componentes: una nueva versión del IMG, y el
subsistema de conexiones que se comunican entre sí a través de un servidor de colas. El
software utilizado fue Apache ActiveMQ 4.0 el cual es una implementación gratuita del servidor
de colas que incluye un API para Java.
7.1.2.1 IMG-Queue
Es una modificación del IMG, la cual cuando recibe el mensaje desde la red celular a
través de distintos medios, lo redirecciona y almacena en un servidor de colas (Message
Broker). Para mayor detalle acerca de la estructura del IMG-Queue ver el apéndice O.
Figura 11. Flujo del IMG-Queue. Elaboración Propia.
37
La forma más común del IMG para conectarse con la red celular es a través de una
conexión SMPP con el SMSC del operador telefónico. Sin embargo en esta fase se implementó
una forma de conexión a través de un MODEM GSM, utilizando el API de SMSLib v 1.0 lo cual
facilitó el proceso de pruebas.
7.1.2.2 Subsistema de Conexiones
Por otro lado, el subsistema de conexiones es un paquete que contiene un conjunto de
clases e interfaces, que en este caso son implementadas para conectarse con el servidor de
colas.
Al iniciar el sistema ActiveSMS, se lee la configuración desde un archivo
(activesms.properties) para posteriormente establecer una conexión con el servidor de colas.
Una vez conformado, el sistema se prepara para recibir mensajes que luego serán procesados
por el módulo de manejo de concursos.
7.1.3 Módulo de Persistencia
El módulo de persistencia es implementado utilizando la herramienta Hibernate 3
(versión para Java) que permite trabajar objeto/relacional y generar sentencias SQL [16], con el
fin de poder utilizar un manejador de base de datos para almacenar los objetos entidad en
tablas. El módulo de manejo de concursos y el módulo Web utilizan el de persistencia para
obtener y almacenar la información del repositorio de datos. Durante el proyecto se utilizó el
manejador relacional de base de datos PostgreSQL 8.0.
Figura 12. Arquitectura de Hibernate. [12]
38
Ahora bien, para lograr la funcionalidad básica se implementó un manejador genérico
para Hibernate de objetos que realiza todas las operaciones CRUD (en inglés, Create, Retrieve,
Update y Delete) para todos los objetos del sistema. Luego se hicieron los mapas (XML) a la
base de datos de los objetos principales del sistema ActiveSMS (Concurso, Mensaje,
ShortCode, Operadora, Pregunta, Respuesta, etc.).
Adicionalmente, se configuró el caché que provee Hibernate para optimizar las
consultas, y fueron agregadas en un archivo aparte (queries.hbm.xml) del código fuente para
independizar el código fuente Java del código HQL (Hibernate Query Language). Aparte de eso,
debido a que Hibernate maneja transacciones, se necesitó diseñar e implementar una interfaz
para manejarlas. Para más detalles ver los documentos de mapeo de hibernate para cada
objecto en el apéndice P.
7.2 Hitos Alcanzados
• Primer sistema con la funcionalidad básica.
• Dominio de la funcionalidad e implementación del IMG.
• Verificación de los tiempos de respuesta del sistema.
39
8 Fase de Construcción II
En este capítulo se presenta la segunda fase de construcción del sistema, que abarca
principalmente la implementación del módulo Web y la parte restante del módulo de
persistencia. Adicionalmente se agregaron nuevos requerimientos dentro de los módulos de
manejo de concursos. Finalmente se realizaron algunas pruebas del sistema.
8.1 Módulo Web
Este módulo utiliza una arquitectura de 3 capas, que son las siguientes: La capa de
presentación representada por las páginas, la capa de aplicación que es manejada por el
servidor Web y la capa de datos en la cual se utiliza el módulo de persistencia de datos.
El módulo Web se implementó utilizando el marco de trabajo Apache Struts v.1.2,
facilitando la codificación y mantenimiento de aplicaciones Web, además de adoptar el patrón
MVC (Model-View-Controller) como su objetivo principal.
Figura 13. Arquitectura Struts. [13]
El archivo de configuración de Struts (struts-config.xml) se puede detallar en el apéndice Q.
40
8.1.1 Vistas
Las vistas son implementadas utilizando páginas JSP + Struts TagLibs + StrutsForm. En
las primeras se encuentra todo el diseño grafico y la información que está contenida en los
formularios de Struts. Previamente el controlador carga la información de la base de datos en
los formularios de Struts, luego esta información se despliega en el navegador, según los Tags
de Struts colocados dentro de las paginas JSP.
8.1.2 Controlador
Es manejado por el Struts Servlet el cual se encarga de recibir la petición HTTP del
navegador, busca que acción se necesita realizar, la ejecuta, carga el formulario de Struts y
luego redirecciona a la página JSP indicada.
8.1.3 Modelo
La capa del modelo de datos, viene directamente desde los objetos del negocio a través
del módulo de persistencia.
8.2 Conexión con la red celular a través del módulo Web
Como se ha mencionado anteriormente, para facilitar la integración del IMG con el
sistema ActiveSMS, se utiliza un Servlet que atiende peticiones HTTP para recibir los mensajes
que el IMG envía y viceversa. Esta parte del módulo Web es una implementación del
subsistema de conexiones que se describió anteriormente, sólo que esta vez se usa
conjuntamente con un Servlet. A continuación se describe el proceso:
1. Llega una solicitud HTTP de la forma:
http://servidor/ActiveSMS?from=04141330820&fromOperador=Movistar&to=8080&msg=Futbol
2. El Servlet transforma los parámetros en un objeto mensaje.
3. Se invoca al módulo de manejo de concursos.
4. Se retorna el mensaje de respuesta.
5. El Servlet escribe el contenido del mensaje de vuelta por la respuesta HTTP
Básicamente se facilita la integración; de hecho las primeras pruebas reales con
sistemas en producción utilizan este esquema de conexión, ya que ahorra tiempo y trabajo de
los analistas de operaciones, además de no utilizar la versión modificada del IMG evitando
fallas no previstas y el despliegue de servidores de colas para producción.
41
8.3 Módulo de Persistencia
En esta segunda parte de construcción de este módulo, se completó la implementación
de todas las interfaces y fabricas, que son necesarias para el correcto funcionamiento del
módulo Web.
Modificación de archivos de mapas de Hibernate: se revisaron los archivos de mapas
de objetos para que cumplan correctamente con las relaciones entre objetos y colecciones, de
tal modo evitar así problemas cuando se realicen operaciones sobre estos.
Por ejemplo, una Trivia hace referencia a una lista de preguntas que a su vez hace
referencia a un conjunto de respuestas, al editar o eliminar una pregunta, las respuestas
pueden quedar sin relación, lo que llevaría a dejar datos no relacionados, y a generar un error.
Por último se preparó el código para las consultas HQL que hacen los reportes de
tráfico de mensajes, sorteos de varias modalidades, más puntos por participante, filtros, etc.
8.4 Hitos Alcanzados
• Sistema totalmente funcional.
• Mayor velocidad de respuesta (Aprox. 66 mensajes por segundo).
• Disminución de errores en los comportamientos de las trivias.
• Integración de todos los módulos del sistema.
42
9 Fase de Transición
En este capítulo final se presenta un resumen de ajustes y pruebas realizadas al sistema
ActiveSMS durante todo el proceso de desarrollo. De la misma forma, durante esta fase nuevos
requerimientos fueron solicitados por Conectium Limited no obstante, se tomó la decisión de
implementar algunos y les demás se planificaron para versiones futuras. Para finalizar se
realiza un resumen del estado actual del sistema.
9.1 Módulo de Lógica de Concursos: Comentarios
En la última fase del proyecto la empresa solicito con urgencia un nuevo tipo de
concurso: los comentarios para programas de radio y TV. Ya que este tipo de concursos no
son complejos ni requieren de mucha codificación o pruebas, se decidió implementarlos dentro
del sistema.
Funcionan en dos modalidades; la primera utiliza la modalidad de rango de horas para
recibir los mensajes correspondientes al programa (por ejemplo, todos los días desde las 15
horas hasta las 17 horas), y la segunda utiliza la modalidad de palabra clave seguido del
comentario. Cualquiera de estas dos modalidades devuelve un mensaje previamente
configurado. Del mismo modo que las Trivias, se pueden realizar sorteos y visualizar los
mensajes. Para mayor detalle del paquete correspondiente a comentarios, ver el apéndice I.
9.2 Proceso de Pruebas del Sistema
En las fases anteriores, aparte del diseño e implementación se realizaron distintas
pruebas del sistema; sin embargo durante la fase de transición fueron mucho más extensas con
el fin de verificar el correcto funcionamiento de todos los casos de usos y los requerimientos no
funcionales. Los tipos de pruebas aplicados durante todo el desarrollo fueron:
• Pruebas Unitarias.
• Pruebas de Integración.
• Pruebas Funcionales.
• Pruebas contra requerimientos no funcionales.
43
Durante todo el desarrollo se utilizó una herramienta de control de versiones para
almacenar cada una de las versiones diarias de la aplicación. Cada una consiste en que cada
sección nueva del código o clase, es compilada, enlazada e instalada. Luego se corre el
sistema y se realizan las pruebas correspondientes, así se puede garantizar un control del
progreso del desarrollo, como también podemos detectar cualquier falla que ocurra al agregar el
código nuevo.
En la fase de elaboración se escribió un caso de prueba unitaria para el módulo de
lógica de concursos, utilizando la herramienta JUnit 4.0 con el fin de verificar el procesamiento y
respuesta de un mensaje entrante. Luego para la primera etapa de construcción se realizaron
pruebas de integración entre el módulo de conexión con la red celular y el módulo de lógica de
concursos, fue en esta prueba donde se logró jugar por primera vez un concurso SMS desde un
teléfono celular.
Las pruebas contra los requerimientos funcionales que se realizaron en esta fase fueron
hechas utilizando los casos de uso del sistema y sus posibles escenarios, se probo casi la
totalidad de todas las funciones posibles, encontrando en el camino varios errores que se
corrigieron.
Por otro lado se realizaron pruebas a los requerimientos no funcionales. De éstas
pruebas se llevaron a cabo pruebas de desempeño y las de usabilidad. Para las pruebas de
desempeño se codificó un programa que simulara la entrada masiva de mensajes con
contenido aleatorio, y se midió el tiempo de respuesta general de cada uno de los mensajes.
Adicionalmente se contabilizó el tiempo transcurrido en cada uno de los módulos del sistema.
Se pudo detectar que el uso del servidor de colas retrasaba considerablemente los mensajes,
en cambio utilizando el Servlet la respuesta mejoró considerablemente.
En cuanto a las pruebas de usabilidad, se realizaron de la siguiente forma: primero
utilizar a varios analistas de producto y sistemas para que configuraran una Trivia en el módulo
Web, y luego que jugaran la misma Trivia que ellos habían creado. Consideraron que el sistema
ActiveSMS era bastante amigable, aunque no entendían bien la parte de configurar los
comportamientos de las Trivias. En cuanto al desenvolvimiento del juego, fue bastante intuitivo
y no hubo ninguna sugerencia en específico.
44
9.3 Estatus Actual del Sistema
Para el primer desarrollo de ActiveSMS se implementaron los cuatro módulos descritos
anteriormente. Básicamente, se crean y configuran los concursos vía el módulo Web que son
guardados en la base de datos (módulo de persistencia), luego cuando llegan los mensajes por
el módulo de conexión con la red celular, el sistema puede empezar a procesar mensajes y
comienza el flujo del juego (módulo de lógica de concursos) hasta que finaliza la interacción con
el usuario.
Hasta ahora, los concursos disponibles en el módulo de lógica de concursos son: Trivias
y Comentarios, los cuales son configurados a través del módulo Web. Dentro de las Trivias
tenemos varias opciones como, decidir si la Trivia acumula puntos, si las preguntas tienen
orden secuencial o aleatorio, si la trivia da un premio, etc. En una versión futura se piensan
agregar más comportamientos u opciones a las trivias, así como también otros tipos de
concursos como Votaciones, Loterías, Pruebas de admisión, etc.
Por otro lado, el módulo Web sólo maneja reportes sencillos de tráfico, realiza sorteos y
contiene un pequeño buscador de mensajes enviados y recibidos. Para la próxima versión se
requieren hacer reportes gráficos, buscadores más avanzados, sorteos con distintas
modalidades, en fin, una serie de mejoras a nivel de reportes Web. A pesar de las pruebas
exhaustivas del módulo Web, todavía quedan algunos pequeños errores que serán corregidos
próximamente.
Actualmente el sistema ActiveSMS se encuentra operativo y totalmente funcional en los
servidores de producción de Conectium Limited. Es utilizado como el nuevo sistema para
concursos de Radio y TV en toda Latinoamérica. Algunos de los países en los cuales se puede
utilizar ActiveSMS son: Panamá, Chile, Colombia, Ecuador, México, Bolivia, Puerto Rico, Costa
Rica, Guatemala, El Salvador y Venezuela.
45
10 Conclusiones
ActiveSMS es un sistema automatizado diseñado para integrar las funcionalidades de
creación, mantenimiento y reportes de todos los tipos de concursos SMS de forma rápida y
sencilla. Su diseño fue pensado para que sirviera como plataforma para diseñar e implementar
cualquier tipo de concurso y para reutilizar al máximo posible el código.
La gran ventaja de este sistema es que reduce considerablemente los tiempos de
diseño, desarrollo, instalación y mantenimiento de los concursos SMS. De esta forma se logra
que los Analistas de Producto no necesiten recurrir a los Analistas de Sistemas cuando un
cliente solicite un concurso, mejor aún los mismos clientes o los Analistas de Producto utilizan el
módulo Web para crear y monitorear sus concursos directamente.
Otra de las características es que provee una forma rápida y sencilla de crear, activar y
monitorear concursos utilizando una aplicación Web como parte del esencial del sistema. Del
mismo modo la separación de las capas dentro de la aplicación para facilitar la integración de
los componentes y el mantenimiento del sistema. Se decidió basarse en la metodología RUP
para desarrollar un producto que cumpla con las mejores prácticas en el desarrollo de software.
El sistema se compone de cuatro grandes módulos:
En primer lugar el módulo de lógica de concursos y procesamiento de sesiones,
que es la base fundamental del sistema, ya que se puede extender fácilmente para programar
cualquier tipo de concursos SMS.
Segundo, el responsable de enviar y recibir los SMS por medio de varias vías es el
módulo de conexión con la red celular, que se encuentra integrado directa o indirectamente
con el sistema IMG (Internet Message Gateway).
Tercero el módulo Web, es considerado otra pieza clave que se encarga de la
administración general del sistema, creación y modificación de concursos, reportes, entre otros;
básicamente desde allí se controla todo el sistema.
46
Por último el módulo de persistencia de datos que es un subsistema adicional, que
sirve para abstraer de forma elegante el manejador de datos que se decide utilizar, el cual es
indispensable para almacenar toda la información que necesita el sistema para operar.
Adicionalmente, se proveen mecanismos sencillos para el desarrollo de nuevos tipos de
concursos que funcionan sobre el sistema, en el caso que un cliente solicite alguna
funcionalidad específica que no existía anteriormente.
Para finalizar, gracias a la facilidad para crear y poner en marcha los concursos SMS,
ahora Conectium Limited utilizará menos recursos en desarrollar para sus clientes, reduciendo
así los costos y traduciéndose en mayor cantidad y calidad de concursos SMS para toda
Latinoamérica.
47
11 Recomendaciones
• Comprender los mecanismos para crear nuevos tipos de concursos, dentro del módulo
de lógica de concursos y procesamiento de sesiones. Se recomienda leer las referencias
bibliográficas de los patrones decorador, método plantilla y fábrica abstracta.
• Para el Módulo Web, mejorar el manejo de excepciones en versiones futuras; plantear e
implementar un esquema más detallado para los niveles de acceso de usuarios al portal,
restringir sorteos de cierto tipo en casos donde no aplican y mejorar el filtro de mensajes. Se
sugiere continuar utilizando el esquema de trabajo Struts para mantener el patrón MVC.
• Optimizar la configuración de caches, y archivos de mapas de Hibernate en el módulo de
persistencia.
• Mejorar el enrutamiento de mensajes por parte del IMG, para que se pueda verificar la
operadora, país y número de acceso.
• Realizar la integración de las configuraciones del IMG con las de ActiveSMS.
• Añadir un menú de ayuda y de preguntas frecuentes para el portal Web.
• Mantener una metodología de desarrollo basada en RUP, realizando algunas de sus
actividades más importantes y generando artefactos, facilitando el trabajo a nuevas
personas dentro del equipo de desarrollo.
• Optimizar el servidor de colas para que mejore el tiempo de respuesta.
48
12 Notas
[1] Conectium Limited. “Misión-Visión”. Extraído el 16 de febrero de 2007.
URL:http://www.conectium.com/es-conectium.html
[2] Hord Jennifer. “How SMS Works”. Extraído el 16 de febrero de 2007.
URL: http://electronics.howstuffworks.com/sms.htm
[3] Varios Autores. “Short Message service center”. Extraído el 16 de febrero de 2007 de
Wikipedia.
URL: http://en.wikipedia.org/wiki/Short_message_service_center
[4] Varios Autores. “Short message peer-to-peer protocol”. Extraído el 16 de febrero de 2007
de Wikipedia.
URL: http://en.wikipedia.org/wiki/SMPP
[5] Sadoski, Darleen (2000), “Three Tier Software Architectures”. Extraído el 20 de febrero de
2007, de Carnegie Mellon University, Software Engineering Institute.
URL: http://www.sei.cmu.edu/str/descriptions/threetier.html#34492.
[6] Venture Information Systems, “VISCO”. Extraído el 20 de febrero de 2007.
URL: http://www.ventureinformationsystem.com/images/application_structure.gif
[7] Rational Software. “Best Practices for Software Development Teams”. Whitepaper, 1998, 21
páginas.
[8] Gamma, Erich and Helm Richard. “Design Patterns: Elements of Reusable Object-Oriented
Software”. Addison-Wesley Professional, 1era edición, 1995, 395 páginas.
[9] Popkin Software and Systems, “Modelado de Sistemas con UML”. Extraído el 16 de
febrero de 2007.
URL: http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/multiple-html/index.html
49
[10] Sun Developers Network, “Core J2EE Patterns - Data Access Object”. Extraído el 30 de
Julio de 2006.
URL: http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
[11] Varios Autores, “Modelo Vista Controlador”. Extraído el 16 de febrero de 2007 de
Wikipedia en español.
URL: http://es.wikipedia.org/wiki/Modelo_Vista_Controlador
[12] HIBERNATE - Relational Persistence for Idiomatic Java, “Hibernate Reference
Documentation”. Extraído el 16 de febrero de 2007.
URL: http://www.hibernate.org/hib_docs/v3/reference/en/html_single/
[13] Yu Colin, Fung Jane (2003). “Writing a Simple Struts application using WebSphere Studio
v5”. Extraído el 16 de febrero de 2007 de IBM WebSphere Developer Technical Journal.
URL: http://www-128.ibm.com/developerworks/websphere/techjournal/0302_fung/fung.html
50
13 Referencias Bibliográficas
Ambler, S. “The Unified Process Elaboration Phase”. CMP, 1era edición, 2000, 277 páginas.
Ambler, S. “The Unified Process Transition Phase”. CMP, 1era edición, 2001, 309 páginas.
Brown, E. and Helm R. “AntiPatterns: Refactoring Software, Architectures, and Projects in
Crisis”. John Wiley & Sons, 1era edición, 2001, 336 páginas.
Fowler, M. “Analysis Patterns: Reusable Object Models”. Addison-Wesley Professional, 1era
edición, 1996, 384 páginas.
Fowler, M. “Patterns of Enterprise Application Architecture”. Addison-Wesley Professional, 1era
edición, 2002, 560 páginas.
Gamma, E. and Helm R. “Design Patterns: Elements of Reusable Object-Oriented Software”.
Addison-Wesley Professional, 1era edición, 1995, 395 páginas.
Larman, C. “Applying UML and Patterns”. Prentice Hall, 2da edición, 2002.
Kroll P. “The Rational Unified Process Made Easy”. Addison-Wesley Professional, 1era edición,
2003, 464 páginas.
Pugh E. and Gradecki J. “Professional Hibernate”. Wrox, 1era edición, 2004, 456 páginas.
Teurel, A. (2001), “Pruebas de sistemas orientados a objetos”. Extraído el 16 de febrero de
2007. URL: http://www.ldc.usb.ve/~teruel/ci3715/clases/testing2.html
51
14 Apéndices
Apéndice A: Documento Visión del Proyecto.
Apéndice B: Documento de Casos de uso.
Apéndice C: Documento Glosario del sistema.
Apéndice D: Documento de Riesgos.
Apéndice E: Plan de desarrollo del proyecto.
Apéndice F: Descripción de los requerimientos por parte de Conectium Limited.
Apéndice G: Prototipo del módulo Web.
Apéndice H: Modelo conceptual.
Apéndice I: Diagrama de Clases. Módulo lógica de concursos y manejo de sesiones.
Apéndice J: Diagrama de Clases. Módulo conexión con la red celular.
Apéndice K: Diagrama de Clases. Módulo Web.
Apéndice L: Diagrama de Clases. Módulo de persistencia.
Apéndice M: Diagrama de secuencia. Procesar mensaje.
Apéndice N: Diagrama de secuencia. Crear/Editar/Eliminar Trivias.
Apéndice O: Arquitectura del IMG-Queue.
Apéndice P: Archivos de mapeo de Hibernate.
Apéndice Q: Archivo de configuración de Struts.
Los apéndices se encuentran en el disco (CDROM) de anexos.