UNIVERSIDAD SIMN BOLVAR

Ingeniera de la Computacin

PLATAFORMA PARA LA CREACIN, MANTENIMIENTO, MONITOREO

Y DESPLIEGUE AUTOMATIZADO DE CONCURSOS PARA SMS

Por
Miguel ngel Sucre Gonzlez

INFORME FINAL DE CURSOS EN COOPERACION

Presentado ante la ilustre Universidad Simn Bolvar
como requisito parcial para optar al ttulo de
Ingeniero en Computacin
Sartenejas, Febrero de 2007

UNIVERSIDAD SIMN BOLVAR

Decanato de Estudios Profesionales
Coordinacin de Ingeniera de la Computacin

Acta de Evaluacin de Cursos en Cooperacin

PLATAFORMA PARA LA CREACIN, MANTENIMIENTO, MONITOREO

Y DESPLIEGUE AUTOMATIZADO DE CONCURSOS PARA SMS

Presentado por
Miguel ngel Sucre Gonzlez

Este informe final de Cursos de Cooperacin ha sido aprobado por el siguiente

jurado examinador:

____________________________
Prof. Ascnder Surez
Jurado

____________________________
Prof. Carlos Figueira
Tutor Acadmico

ii

PLATAFORMA PARA LA CREACIN, MANTENIMIENTO, MONITOREO Y

DESPLIEGUE AUTOMATIZADO DE CONCURSOS PARA SMS

Resumen
En el mundo de la telefona celular es importante el crecimiento que ha tenido el uso de
la mensajera de texto en los ltimos aos. Gracias a esto la mensajera de texto no slo es
para comunicarse entre personas sino que tambin se utiliza para el entretenimiento,
participacin y diversin de los usuarios, principalmente en la Radio y TV. En respuesta al
nuevo crecimiento de aplicaciones para la mensajera de texto, surge el objetivo de esta
pasanta: la elaboracin de un sistema automatizado para la creacin, mantenimiento, y
reportes de concursos para SMS (Short Message Service). El SMS es un servicio para el envo
y recepcin de mensajes cortos, que funciona sobre las redes de telefona celular digital.
Se desarrollo una primera versin 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 mdulos: el de lgica de concursos (cmo funcionan

los concursos y qu contenido mostrarn), de conexin con la red celular (cmo 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 informacin del sistema en un
repositorio de datos.

iii

Dedicatoria

A mi madrina, Carmen Cecilia Gonzlez de Mayz.

iv

Tabla de Contenidos
1

Introduccin ...................................................................................................................... 1

Entorno Empresarial ......................................................................................................... 3

2.1

2.1.1

Visin................................................................................................................... 3

2.1.2

Misin .................................................................................................................. 3

2.2

Trayectoria de Conectium Limited en el mbito Internacional y Venezuela.................. 3

2.3

Organizacin y Estructura de Conectium Limited......................................................... 4

2.3.1

Unidad de Gerencia y Mercadeo.......................................................................... 4

2.3.2

Unidad de Tecnologa y Operaciones .................................................................. 4

2.3.3

Unidad de Contenido y Multimedia....................................................................... 4

2.4
3

Misin y Visin de Conectium Limited.......................................................................... 3

Ubicacin del pasante ................................................................................................. 4

Planteamiento del Problema............................................................................................. 5

3.1

Objetivo General:......................................................................................................... 7

3.2

Objetivos Especficos: ................................................................................................. 7

Marco Terico.................................................................................................................... 8
4.1

Definicin de SMS ....................................................................................................... 8

4.2

Funcionamiento del SMS............................................................................................. 8

4.3

SMS Centers (SMSC).................................................................................................. 9

4.3.1

Protocolos de comunicacin ................................................................................ 9

4.4

Protocolo SMPP ........................................................................................................ 10

4.5

Arquitectura de Tres Capas Cliente/Servidor ............................................................. 10

4.6

Metodologa de Desarrollo Aplicada .......................................................................... 12

4.6.1

Dos dimensiones del proceso de desarrollo....................................................... 12

4.6.2

Estructura Dinmica de RUP ............................................................................. 13

4.6.2.1

Fase de Inicio................................................................................................. 13

4.6.2.2

Fase de Elaboracin ...................................................................................... 13

4.6.2.3

Construccin .................................................................................................. 14

4.6.2.4

Transicin ...................................................................................................... 14

4.6.3
4.7

Estructura Esttica de RUP................................................................................ 14

Patrones de Diseo ................................................................................................... 15

4.7.1
4.7.1.1

Clasificacin de Patrones................................................................................... 15
Patrones de Creacin..................................................................................... 15
v

Patrones Estructurales ................................................................................... 16

4.7.1.3

Patrones de Comportamiento......................................................................... 17

Fase de Inicio: ................................................................................................................. 18

5.1

Visin del Proyecto .................................................................................................... 18

5.1.1

Mdulo de lgica de concursos y procesamiento de sesiones ........................... 18

5.1.2

Mdulo de Conexin con la red mvil celular ..................................................... 19

5.1.3

Mdulo de Administracin Web.......................................................................... 20

5.1.4

Mdulo de Persistencia de Datos....................................................................... 20

5.2

4.7.1.2

Actores y principales casos de uso: ........................................................................... 21

5.2.1

Actores............................................................................................................... 21

5.2.2

Casos de Uso .................................................................................................... 21

5.2.2.1

Mdulo de Manejo de concursos:................................................................... 21

5.2.2.2

Mdulo de Conexin con la red Celular.......................................................... 22

5.2.2.3

Mdulo Web:.................................................................................................. 22

5.2.2.4

Mdulo 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

Fase de Elaboracin........................................................................................................ 24
6.1

Vistas de la arquitectura del Software........................................................................ 24

6.2

Las 4 + 1 Vistas de la arquitectura............................................................................. 24

6.2.1
6.2.1.1
6.2.2

Vista de Casos de Uso....................................................................................... 24

Diagrama de Casos de uso ............................................................................ 25
Vista Lgica ....................................................................................................... 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 Implementacin.................................................................................... 26

6.2.4

Vista de Despliegue ........................................................................................... 27

6.3

Decisiones de Diseo ................................................................................................ 29

6.3.1

Mdulo de Lgica de Concursos y Manejo de sesiones..................................... 29

6.3.2

Mdulo de Conexin con la red mvil celular ..................................................... 30

6.3.3

Mdulo de Persistencia de Datos....................................................................... 31

vi

6.3.4

Mdulo de Administracin Web.......................................................................... 32

6.4

Lista de Requerimientos no funcionales .................................................................... 32

6.5

Hitos Alcanzados ....................................................................................................... 32

Fase de Construccin I ................................................................................................... 33

7.1

Implementacin de la Arquitectura propuesta: ........................................................... 33

7.1.1
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 telfonos de prueba................................................................. 36

7.1.2

Mdulo de Conexin con la Red Celular ............................................................ 36

7.1.2.1

IMG-Queue .................................................................................................... 36

7.1.2.2

Subsistema de Conexiones............................................................................ 37

7.1.3
7.2

Mdulo de Lgica de Concursos ........................................................................ 33

Mdulo de Persistencia...................................................................................... 37

Hitos Alcanzados ....................................................................................................... 38

Fase de Construccin II .................................................................................................. 39

8.1

Mdulo Web .............................................................................................................. 39

8.1.1

Vistas................................................................................................................. 40

8.1.2

Controlador ........................................................................................................ 40

8.1.3

Modelo............................................................................................................... 40

8.2

Conexin con la red celular a travs del mdulo Web ............................................... 40

8.3

Mdulo de Persistencia.............................................................................................. 41

8.4

Hitos Alcanzados ....................................................................................................... 41

Fase de Transicin .......................................................................................................... 42

9.1

Mdulo de Lgica 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 Bibliogrficas.......................................................................................... 50

14

Apndices .................................................................................................................... 51

vii

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. Elaboracin propia. ................................................... 23
Figura 5. Vista Implementacin. Elaboracin Propia. ................................................................ 27
Figura 6. Vista de Despliegue. Elaboracin Propia.................................................................... 28
Figura 7. Fbrica Abstracta. [8] ................................................................................................. 29
Figura 8. Decorador. [8] ............................................................................................................ 30
Figura 9. Patrn DAO. [12]........................................................................................................ 31
Figura 10. Flujo de mensajes. Elaboracin Propia .................................................................... 34
Figura 11. Flujo del IMG-Queue. Elaboracin Propia ................................................................ 36
Figura 12. Arquitectura de Hibernate. [12]................................................................................. 37
Figura 13. Arquitectura Struts. [13]............................................................................................ 39

viii

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

ix

1 Introduccin
La popularidad de la mensajera de texto ha venido aumentando aceleradamente a lo
largo de los ltimos aos en Venezuela y Latinoamrica en general. Gracias a su bajo costo y
gran potencial de aplicaciones, los mensajes de texto son la primera forma de comunicacin a
travs de las redes mviles en Venezuela. Hoy en da aproximadamente el 60% de los
venezolanos estn en capacidad de utilizar este servicio con expectativas de crecimiento
bastante altas.
La mensajera de texto no solo sirve para comunicarse entre los suscriptores de las
compaas de telefona celular, adems sirven para el entretenimiento (Trivias, Votaciones,
Comentarios, etc.), consultas y otra infinidad de servicios de informacin tambin 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 ms y mejores
sistemas que puedan satisfacer esta creciente demanda del mundo mvil.
La intencin de este proyecto es disear e implementar un sistema para la construccin,
administracin y monitoreo de concursos a travs de mensajera de texto, de fcil uso y rpida
puesta en marcha, adems de contar con la capacidad de extender sus funcionalidades de
forma sencilla y rpida 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 lgica de los tipos concursos, los distintos comportamientos que
deben tener los concursos durante la sesin de juego. Por otro lado se necesita la conexin con
la red celular para el envo y recepcin de mensajes, y por ltimo una consola Web
administrativa que permita manipular los concursos.

El proyecto se desarrolla basndose en la metodologa Rational Unified Process

tomando lo ms importante, con el fin de utilizar las mejores prcticas 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 captulo se describe el

entorno empresarial en donde se desarroll el proyecto, como segundo el planteamiento del
problema, luego un marco terico y finalmente cinco captulos que describen las actividades
que se realizaron durante las etapas de la metodologa RUP: Fase de de inicio, elaboracin,
constriccin I, constriccin II y la fase transicin.

2 Entorno Empresarial
En este captulo se describe el entorno en el cual el proyecto de pasanta fue
desarrollado, con el fin de conocer a la empresa Conectium Limited. Se expone la misin y
visin de esta empresa, luego la trayectoria de Conectium Limited en el mbito internacional y
en Venezuela, seguido de la organizacin y estructura, y finalmente la ubicacin del pasante
dentro de la empresa.

2.1
2.1.1

Misin y Visin de Conectium Limited

Visin
Convertirse en el proveedor lder de soluciones de Internet inalmbrica para las ms

importantes compaas de servicios de comunicacin mvil en toda Latinoamrica. [1]

2.1.2

Misin
Conectium Limited, se propone obtener la mayor base de suscriptores de comunicacin

inalmbrica del continente, suministrando un servicio de Internet mvil de amplio espectro;

basado principalmente en el aporte de desarrollo de contenido y asesora en gerencia de redes
que proporcione al usuario final la informacin apropiada a sus necesidades y que le permitan
experimentar toda la funcionalidad de la autopista de la informacin a travs de sus equipos de
telfono celular. [Ob. Citada]

2.2

Trayectoria de Conectium Limited en el mbito Internacional y Venezuela

Conectium Limited fundada en el ao 2000, lder en Internet Mvil en Latinoamrica. 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, imgenes y video, etc.

En Venezuela se encuentra la base de desarrollo y operaciones de la empresa,

contando tambin con oficinas comerciales en Mxico, Panam, Costa Rica, Colombia, y Chile.
Conectium Limited desarrolla soluciones de Internet mvil 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 travs de las distintas interfaces inalmbricas,
permiten integrar contenidos, informacin, y aplicaciones apropiadas para la Internet mvil y
otros servicios.
3

2.3

Organizacin y Estructura de Conectium Limited

La organizacin 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 Tecnologa y Operaciones

Se encarga del desarrollo de software y del correcto funcionamiento de este las 24

horas, 7 das a la semana. Departamento de Operaciones y Departamento de Tecnologa.

2.3.3

Unidad de Contenido y Multimedia

Responsables de mantener y actualizar las categoras y objetos de contenido generados

peridicamente por la empresa. Departamento de Contenido.

2.4

Ubicacin del pasante

El proyecto de pasanta se realiz en la unidad de Tecnologa y Operaciones,

especficamente en el departamento de tecnologa. El proyecto consiste en disear e

implementar un sistema funcional para la creacin, mantenimiento y monitoreo de concursos
SMS. El pasante fue el nico encargado de toda la tarea, basndose en requerimientos
solicitados por parte del personal del rea de productos y la direccin de la empresa. Para el
despliegue en produccin del sistema se necesit el apoyo del Departamento de Operaciones.
En el siguiente captulo, se plantea el problema con mayor detalle, ya que fue el objeto
de la pasanta.

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, slo se pueden emular preguntas con una sola respuesta, sin ningn tipo de
lgica o comportamiento.

Ya que cada cliente exige un concurso estrictamente personalizado, la empresa se ve en

la obligacin de desarrollar un software adicional que cumpla con las especificaciones del
cliente. Las caractersticas de los concursos varan 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, acumulacin 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 pases, operadoras y nmeros 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) segn los requerimientos de cada pas, 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 votacin en Venezuela y en Mxico utilizando tambin 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

recepcin y envo de mensajes, que sirva para generar concursos que cumplan con los
requerimientos del cliente rpidamente? 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.
5

De all surge la necesidad de disear un sistema automatizado que maneje la creacin,

mantenimiento, monitoreo despliegue de concursos a travs de mensajera de texto SMS, que
cuente con facilidad para atender de forma rpida nuevos requerimientos por parte de los
clientes.

Otra de las limitantes es el proceso de creacin, 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 ms Analistas de Sistemas que se encarguen de disear,
implementar y probar el concurso especificado por el cliente, finalmente se necesita un analista
de operaciones para colocarlo en produccin. 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 informacin directamente de la base de datos, la procesa y luego la enva a los
respectivos clientes peridicamente 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 reutilizacin de
software. De all surge otro objetivo del proyecto de pasanta 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.

3.1

Objetivo General:
Disear e implementar una plataforma que integre las funcionalidades de creacin,

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: Administracin, Reportes y Concursos. Sin embargo, en
el mdulo de concurso se desarrollar nicamente la seccin de Trivias y Comentarios, que
integran las funcionalidades de creacin, edicin, verificacin, sorteos y visualizacin de
aquellos participantes con mayor nmero de mensajes o puntos.

3.2

Objetivos Especficos:
Desarrollar un programa que permita manejar las sesiones y la interaccin entre los
usuarios y los concursos, utilizando patrones de diseo de tipo estructural, creacin y
comportamiento. Mdulo de Manejo de concursos y procesamiento de sesiones.

Implementar varias interfaces con el sistema IMG (Internet Message Gateway) para la
transmisin y recepcin de mensajes de texto. Mdulo de Conexin con la red mvil celular.

Desarrollar una aplicacin Web, utilizando el patrn de diseo MVC Modelo Vista
Controlador, para la administracin, generacin y reportes de los concursos SMS.

Implementar una arquitectura para la persistencia de datos, basada en el patrn de diseo

DAO (Data Access Objects), con el fin independizar el manejador de datos.

4 Marco Terico
En este captulo, sern definidos algunos trminos y conceptos especficos del tema a
tratar. Son tomados de varios autores reconocidos en el rea.
.

4.1

Definicin de SMS

SMS significa Servicio de Mensajes Cortos (En ingls, Short Message Service). Es un
mtodo de comunicacin que enva texto entre telfonos celulares. Tambin es posible desde
computadoras o dispositivos mviles, a telfonos celulares y viceversa. Se le llama corto
porque el tamao mximo del mensaje es de 160 caracteres (letras, nmeros o smbolos del
alfabeto Latino). Para otros alfabetos como el chino, el tamao mximo es de 70 caracteres. [2]

El SMS fue creado en Europa a finales de los aos 1980s cuando se incluyo dentro de
la tecnologa GSM, inicialmente se ide para dejar mensajes cortos a usuarios de la telefona
celular para cuando tuviesen el telfono apagado o sin cobertura. [Ob. Citada]

4.2

Funcionamiento del SMS

Los telfonos celulares utilizan un canal especial de comunicacin 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 va para enviar los SMS. Cuando se enva un SMS, el telfono
desde donde se origina lo enva a la celda a travs 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 telfono
destinatario, una vez ah la torre hace la entrega. [Ob. Citada]

Figura 1.Funcionamiento Del SMS. [2]

4.3

SMS Centers (SMSC)

Cuando un usuario enva 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 tambin desde una aplicacin, por ejemplo, un buzn de
correos de voz enviando alertas de mensajes de voz. Los operadores telefnicos 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 ingls, Short Message Entities).
[Ob. Citada]
4.3.1

Protocolos de comunicacin
"Para la transmisin y recepcin de mensajes SMS, los SMSC tienen interfaces de redes

cableadas, as como tambin interfaces con la red mvil. Se han definido un nmero 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]

9

4.4

Protocolo SMPP
"El SMPP es un protocolo estndar 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 diseado por Aldiscon, una pequea 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
opcin de un transmisor-receptor sobre una sola conexin. [Ob. Citada]

4.5

Arquitectura de Tres Capas Cliente/Servidor

"La arquitectura del software de tres o ms capas nace en los aos 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 lgica del negocio, puede soportar cientos de
usuarios, utilizando varios mecanismos. La arquitectura de tres capas es utilizada cuando se
necesita un diseo de cliente/servidor efectivo y distribuido que provea un mejor desempeo,
flexibilidad, mantenimiento, reutilizacin y escalabilidad, al mismo tiempo esconder del usuario
toda la complejidad del procesamiento distribuido. Estas caractersticas han hecho que la
arquitectura de tres capas sea muy popular en las aplicaciones de Internet y otros sistemas de
informacin. [5]

10

Figura 2. Arquitectura de tres capas. [6]

Una arquitectura de tres capas, incluye una capa superior donde residen la interfaz
grfica y servicios del usuario. Una segunda capa que se encarga de proveer servicios para el
manejo de procesos (administracin y monitoreo) que son utilizados entre aplicaciones. La
segunda capa o capa intermedia tambin es llamada servidor de aplicaciones. La centralizacin
de los procesos lgicos hace que la administracin y los cambios sean mucho ms fciles,
simplemente se realiza el cambio una sola vez dentro del servidor de la capa de aplicacin y
automticamente est disponible para todos los usuarios. Con otro diseo de arquitectura se
tendra que hacer el cambio en cada aplicacin 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 replicacin de datos.
La conectividad entre las capas puede ser modificada segn 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 aplicacin. [Ob. Citada]
11

4.6

Metodologa de Desarrollo Aplicada

La metodologa 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 prcticas 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 organizacin 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

prcticas 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 ningn proceso es ideal para todos los desarrollos de software,
RUP es configurable y se adapta a cualquier tipo de organizacin, desde pequeas 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 dinmica del proceso, y
es expresado en trminos de ciclos, iteraciones, fases e hitos. [Ob. Citada]

El eje vertical representa el aspecto esttico del proceso, es expresado en trminos de

actividades, trabajadores, flujo de trabajos y artefactos. [Ob. Citada]

12

Figura 3. RUP en dos dimensiones. [7]

4.6.2

Estructura Dinmica de RUP

"Es la organizacin del proceso a lo largo del tiempo. La vida de un software est

compuesta por varios ciclos, cada ciclo representa una nueva generacin 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 interactuarn con el sistema, esto
implica definir los casos de uso y describir a los ms significantes. Tambin se incluyen los
factores de xito, riesgos potenciales y la estimacin de recursos necesarios para el proyecto.
[Ob. Citada]
4.6.2.2 Fase de Elaboracin
El propsito de la fase de elaboracin es analizar el dominio del problema, establecer
una arquitectura base, crear el plan de desarrollo, y eliminar los riesgos ms grandes del
proyecto. Para alcanzar los objetivos es necesario tener una visin 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
13

es que el esfuerzo se concentre en los casos de uso crticos, que usualmente representan los
mayores riesgos tcnicos. [Ob. Citada]
4.6.2.3 Construccin
Durante esta fase, todos los componentes y funcionalidad restante de la aplicacin son
desarrollados e integrados dentro del producto, al mismo tiempo de que son cuidadosamente
probados. La fase de construccin 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 Transicin
Tiene como propsito la transicin del producto a los usuarios finales. Incluye
actividades como: pruebas de versiones beta, operacin paralela con sistema el cual se
reemplaza, adaptacin de bases de datos, entrenamiento de usuarios, pasar el producto a los
equipos de ventas. Tambin se hace un esfuerzo en ajustar, corregir errores, y mejorar la
usabilidad y el desempeo del software. [Ob. Citada]

Cada una de estas fases concluyen con un hito bien definido, en cada hito se toman
decisiones crticas, por ende se deben cumplir los objetivos claves. Cada una tiene un propsito
distinto y se pueden realizar una o ms iteraciones en cada fase, segn el plan de desarrollo.
[Ob. Citada]

4.6.3

Estructura Esttica de RUP

"Un proceso representa el quin esta haciendo qu, cmo y cundo. En RUP se

representa utilizando cuarto elementos en el modelo. Los Trabajadores (Workers) representan

el quin; los Artefactos el qu; las Actividades el cmo; y el Flujo de Trabajo (Workflow) el
cundo. [Ob. Citada]

14

4.7

Patrones de Diseo
Los patrones de diseo son descripciones de objetos y clases que se comunican entre s

y que son adaptados para resolver un problema de diseo en un contexto determinado. [8] En
general un patrn tiene cuarto partes esenciales:

El nombre del patrn es un trmino que se utiliza para describir un problema de diseo,
y su solucin en una palabra o dos. El problema describe cuando aplicar el patrn, explica el
problema y el contexto para el cual es utilizado. La solucin describe los elementos que
conforman el diseo, sus relaciones, responsabilidades y colaboraciones. La solucin no
describe una solucin concreta en particular, ya que un patrn es una plantilla que puede ser
aplicado en distintas soluciones. Las consecuencias son los resultados y costos de haber
aplicado el patrn. [Ob. Citada]

4.7.1

Clasificacin de Patrones
Los patrones de diseo se clasifican de dos formas: la primera, por su propsito y la

segunda, por su alcance. Los patrones pueden tener propsitos de creacin, estructural o de
comportamiento. Los patrones de creacin se enfocan de la construccin de los objetos, los
estructurales manejan la composicin de clases u objetos, y los patrones de comportamiento se
caracterizan por la forma en que las clases u objetos interactan y distribuyen
responsabilidades. El otro criterio de alcance especifica si el patrn se aplica a una clase o a
objetos. [Ob. Citada]
4.7.1.1 Patrones de Creacin
Bsicamente abstraen el proceso de instanciacin. Ayudan a hacer un sistema
independientemente de cmo son creados, compuestos y representados sus objetos. Un patrn
de creacin para una clase utiliza la herencia para variar el tipo de clase concreta que ha sido
creada; en cambio para los objetos, el patrn delegar la instanciacin a otro objeto. [Ob.
Citada]
Los patrones de creacin son importantes en sistemas que dependen cada vez ms en
la composicin de objetos que en la herencia de clases. Mientras esto ocurra, el nfasis se aleja
15

de codificar un conjunto fijo de comportamientos, hacia un menor conjunto de comportamientos

fundamentales que pueden ser mezclados entre si para crear unos ms 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 ms arriba son
las interfaces de los objetos definidas por clases abstractas. En consecuencia, los patrones de
creacin dan una gran flexibilidad en qu se construye, quin lo construye, cmo lo construye, y
cuando. Permiten configurar un sistema con objetos que varan en estructura y funcionalidad.
La configuracin puede ser esttica (a tiempo de compilacin) o dinmica (en tiempo de
ejecucin). [Ob. Citada]
Algunos de los patrones de creacin son: Prototipo, Fbrica Abstracta, Builder o Constructor,
Singleton y Mtodo de Fabricacin

4.7.1.2 Patrones Estructurales

Los patrones estructurales se enfocan en cmo se componen clases y objetos para
formar estructuras ms grandes. En el caso de clases utilizan herencia para componer
interfaces o implementaciones. Por ejemplo, en el caso de la herencia mltiple que mezcla dos
o ms clases, genera como resultado una clase que combina las propiedades de las clases
padre. Este patrn es til para hacer que dos libreras 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
composicin en tiempo de ejecucin, lo cual es imposible con una composicin esttica. [Ob.
Citada]

Dentro de los patrones estructurales se tiene: Decorador, Adaptador, Fachada, Puente,

Proxy y Composite
16

4.7.1.3 Patrones de Comportamiento

Los patrones de comportamiento tienen que ver con algoritmos y la asignacin de
responsabilidades entre objetos. Adicionalmente estos patrones no slo describen objetos y
clases, sino que tambin describen patrones de comunicacin entre ellos. Se caracterizan por
un complejo control de flujo que resulta difcil de entender en tiempo de ejecucin. La idea es
slo concentrarse en la forma en que los objetos estn 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 patrn Mtodo Plantilla, que es una definicin
abstracta de un algoritmo, lo define paso a paso. En el caso de patrones de comportamiento
para objetos utilizan composicin en vez de herencia. Algunos describen como un grupo de
objetos cooperan para realizar una tarea que ningn objeto puede llevar a cabo solo. [Ob.
Citada]
Los patrones de comportamiento ms comunes son: Interpretador, Mtodo Plantilla, Cadena
de Responsabilidad, Comando, Iterador, Mediador, Memento, Flyweight (Peso mosca),
Observador, Estado, Estrategia y Visitante.

17

5 Fase de Inicio:
Este captulo presenta todas las actividades realizadas durante la fase de inicio de la
metodologa RUP. Tambin se sealan algunos artefactos resultantes de las actividades.

5.1

Visin del Proyecto

La tarea de implementar un concurso SMS implica varios procesos dentro de la

empresa. Generalmente el cliente decide cules 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
produccin. 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 fcil y rpida, la plataforma tiene la
funcionalidad de:

Crear, modificar y eliminar concursos SMS (Primera fase slo Trivias y Comentarios) a
travs 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 nmeros de acceso (Shortcodes).

Realizar sorteos en varias modalidades.

El documento visin del proyecto se encuentra en el Apndice A, para la descripcin del

de los requerimientos de la empresa ver el Apndice F.

5.1.1

Mdulo de lgica de concursos y procesamiento de sesiones: Cmo funcionan los

concursos? y Qu contenido manejarn los concursos?

18

Para poder participar y llevar a cabo un concurso, es necesario enviar un mensaje desde
un telfono celular con la palabra clave indicada a un nmero determinado y luego el operador
telefnico 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 sesin entre el concurso y el nmero telefnico desde donde se encuentra
participando la persona. A partir de este momento, todos los mensajes recibidos se dirigirn
directamente hacia la sesin del concurso, siempre y cuando est activa.

Una vez que llega el mensaje a la sesin del concurso, es procesado y se responde de
una forma especfica. 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 funcin del mdulo 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 mdulo 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
sesin se mantenga abierta hasta que expire un tiempo previamente preestablecido.

Para evitar el acceso de usuarios a concursos que no se encuentran abiertos al pblico

este mdulo se encarga de filtrar los telfonos no permitidos para hacer pruebas del concurso.
Otra de las funciones es poder hacer cambios de concursos durante una misma sesin.
5.1.2

Mdulo de Conexin con la red mvil celular. Cmo se envan y reciben los
mensajes de texto?

Dentro de Conectium Limited existe un sistema ya probado de envo y recepcin de

mensajera SMS: el IMG (Internet Message Gateway). Este sistema se utiliza actualmente en
varios pases y maneja una alta cantidad diaria de mensajes SMS, adems posee otras
funcionalidades interesantes de control de conexiones con los operadores telefnicos.

Para que funcione correctamente la plataforma ActiveSMS es necesario poder enviar y

recibir mensajes SMS, esto se logra conectndose con la red de telefona celular. Para
aprovechar el sistema existente de envos y recepcin, se necesitar desarrollar un mdulo que
19

permita establecer una comunicacin de mensajes desde ActiveSMS con el IMG y viceversa.

Se necesita un mecanismo robusto de comunicacin entre los dos sistemas, donde se

minimice la cantidad de mensajes que no se envan de vuelta al usuario. Por ejemplo, un
usuario enva un mensaje al sistema pero ste no le responde porque no se encuentra
disponible en ese instante. Este caso genera muchas molestias al pblico 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 situacin.

Sin embargo el IMG ya posee una interfaz para conectarse con otros sistemas a travs
de una llamada HTTP. Esta forma de integrarse con el IMG es mucho ms sencilla y rpida
aunque no tan robusta. De todas maneras se implementar una interfaz adicional en el modulo
de conexin conjuntamente con el mdulo Web, para proveer la opcin de comunicarse con
el IMG de esta forma.

5.1.3

Mdulo de Administracin Web. Cmo se controla al sistema?

Uno de los requisitos indispensables para la plataforma es el mdulo de administracin

va Web, el cual permitir administrar todo lo referente a la plataforma de forma rpida y

sencilla. Se compone de 3 secciones: Concursos, Administracin y Reportes. Gracias a esto
el proceso de creacin de concursos pasa de ser tarea de un grupo de empleados (Analistas de
sistemas y de producto) a tarea de tan slo un Analista de Producto, o mejor an 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 va Web.
Un prototipo detallado del mdulo de administracin Web realizado por la empresa, se
puede ver en el apndice G.

5.1.4

Mdulo de Persistencia de Datos. Cmo se guarda toda la informacin del sistema?

Todos los mdulos anteriores exceptuando el de conexin con la red celular, necesitan

de un sub-sistema que se encargue de almacenar informacin; para esto se idea un sistema de

20

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 continuacin se presentan los principales actores y casos de uso del sistema:

5.2.1

Actores

Nombre

Descripcin

Rol

Gerente de la plataforma

Persona interna encargada

del
funcionamiento
y
monitoreo de la plataforma
ActiveSMS.

Usuario Gerente

Persona externa designada

por el cliente que contrata el
servicio. Puede ser interna.
Persona externa designada
por el cliente que contrata el
servicio. Puede ser interna.

Administra los shortcodes,

pruebas, y
usuarios
registrados en el sistema.
Ve todos los concursos
creados. Posee todos los
privilegios de la plataforma.
Se encarga de crear,
modificar y eliminar los
concursos
Se encarga de observar el
estatus de los concursos
as como tambin los
resultados.
Enva y Recibe mensajes
hacia
el
nmero
del
concurso.

Usuario Monitor

Usuario Final

5.2.2

Persona que juega el

concurso a travs de su
telfono.

Casos de Uso

5.2.2.1 Mdulo 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 sesin, procesar mensajes y terminar sesin.
2. Cambiar de concurso: se le da la posibilidad a un usuario que se cambie desde un
concurso en marcha a otro.

21

5.2.2.2 Mdulo de Conexin con la red Celular

1. Enviar/Recibir mensajes con la red mvil celular, se envan y se reciben mensajes hacia
el sistema IMG, que luego sern entregados a los distintos SMSC de las operadoras
telefnicas y viceversa.

5.2.2.3 Mdulo Web:

1. Crear/Modificar/Eliminar operadoras, short codes y usuarios del portal Web. Esta
seccin del mdulo 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 versin solo podemos configurar Trivias y
Comentarios. Esta informacin ser proporcionada al mdulo 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 Mdulo 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 Apndice B.

5.3

Glosario del Sistema

Todos los trminos 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 extensin, el glosario es presentado en el Apndice C.

22

5.4

Estudio Inicial de Riesgos

Durante la primera etapa del proyecto, se realiz un breve estudio de los riesgos ms

importantes que pudiesen afectar a la calidad final del producto a desarrollar. Los ms
importantes fueron los siguientes:

Utilizacin de nuevas tecnologas, poca experiencia del desarrollador con la tecnologa

de colas.

Aprendizaje de la arquitectura del software de transmisin y recepcin de mensajes de

texto (IMG) para realizar la integracin entre los sistemas.

Gran cantidad de requerimientos solicitados por la empresa.

Complejidad de la aplicacin, ya que se necesita que posea mucha flexibilidad para

desarrollos futuros.

Para una descripcin ms detallada, que incluye la magnitud, los impactos, los
indicadores y la estrategia de mitigacin ver el Apndice D.

5.5

Plan de Desarrollo del Software

Figura 4 Plan de desarrollo del software. Elaboracin propia.

El plan detallado del desarrollo de software ActiveSMS se encuentra en el Apndice E

5.6

Hitos Alcanzados

Lista de requerimientos muy claros y especficos.

Arquitectura preliminar.

23

Fase de Elaboracin
Durante esta fase se concibe el dominio del problema, se analiza y se identifican los

casos de uso ms 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 metodologa 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, especficos para cada

uno de los stakeholders: usuarios, diseadores, gerentes, ingenieros, etc. [9]

Estas vistas capturan las decisiones ms significativas del diseo, mostrando como la
arquitectura se descompone en componentes, y como stos estn interrelacionados entre s.
Las decisiones tomadas de diseo deben estar estrechamente relacionadas con los
requerimientos, funcionales y no funcionales del software, sin embargo estas decisiones
tambin afectan a los requerimientos y en diseos futuros. [Ob. Citada]

Se utiliza el Lenguaje de Modelado Universal (UML), como notacin de todas las vistas
de la arquitectura. En la metodologa RUP se llaman las 4+1 vistas que son descritas a
continuacin a excepcin de la vista de proceso:

6.2
6.2.1

Las 4 + 1 Vistas de la arquitectura

Vista de Casos de Uso
La vista de casos de uso recopila la mayora 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 interaccin 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
24

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 mdulo del sistema, pero en
este caso se representan todos en un slo diagrama. El diagrama de casos de uso se
encuentra en el apndice B.

6.2.2

Vista Lgica
"Para entender la estructura y la organizacin del diseo del sistema utilizamos la vista

lgica, ya que ilustra los subsistemas o mdulos, paquetes y clases que componen a toda la
arquitectura del sistema. Tambin representa el dominio y la solucin 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. Tambin sealamos los patrones que utilizamos en el diseo de los
distintos mdulos del sistema, que explican detalladamente el porqu y cul 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 ningn tipo de solucin solo se encarga de modelar y relacionar los conceptos de la
realidad que rodean al problema que se quiere resolver. Ver apndice H.
6.2.2.2 Diagramas de Clases
El Diagrama de Clases es el diagrama principal de diseo y anlisis para un sistema.
En l, la estructura de clases del sistema se especifica, con relaciones entre clases y
estructuras de herencia. Durante el anlisis del sistema, el diagrama se desarrolla buscando
una solucin ideal. Durante el diseo, se usa el mismo diagrama, y se modifica para satisfacer
los detalles de las implementaciones. La definicin de clase incluye definiciones para atributos y
operaciones. [Ob. Citada]
25

En la fase de elaboracin se generaron varios diagramas de clases con los elementos

bsicos de la arquitectura con el fin de disear e implementar los componentes con mayor
riesgo. Durante las prximas fases se agregaron y modificaron elementos a los diagramas. Los
diagramas de clases por mdulos se encuentran en los Apndices I, J, K, L.
6.2.2.3 Diagramas de Secuencia
El Diagrama de Secuencia es uno de los diagramas ms efectivos para modelar
interaccin entre objetos en un sistema. Un diagrama de secuencia se modela para cada caso
de uso. Contiene detalles de implementacin 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 Apndices M, N.
6.2.3

Vista de Implementacin
En esta vista se describir la organizacin esttica del proyecto, es decir, cmo estn

organizados los mdulos, subsistemas o paquetes del sistema. Esta vista tiene como objetivo
guiar el desarrollo del software, distribucin, agrupamiento y visibilidad. Adems esta vista sirve
para la asignacin de requerimientos al equipo de desarrollo, para la planificacin de costos y
tiempos, para el monitoreo y justificar la reusabilidad, portabilidad y seguridad del software.
[Ob. Citada]

El sistema ActiveSMS consta de cuatro mdulos, de esta forma se puede representar el

sistema completo de la siguiente forma:
El mdulo de lgica de concursos: se implementarn 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 nmeros telefnicos. Dentro de este mdulo existen clases
implementadas para los concursos tipo trivias y comentarios. Ver apndice I.
El mdulo de conexin con la red celular: consta de la implementacin de dos
mdulos independientes, uno lo representa el software IMG-queue, y el otro el sub-sistema de
26

conexiones que se encuentra dentro del paquete principal. Ver apndice J.

El mdulo Web: se implementar bajo la arquitectura cliente/servidor de tres capas, utilizando
un esquema de trabajo para aplicaciones Web facilitando la implementacin. Ver apndice K.

El mdulo de persistencia: se implementar el patrn DAO, utilizando la tecnologa Hibernate.

Ver apndice I.

Para visualizar mejor qu clases estructuran cada mdulo del sistema ActiveSMS, se
recomienda ver el diagrama de clases. A continuacin se presenta la Fig. 5 que contiene la
distribucin de los subsistemas y paquetes.

Figura 5. Vista Implementacin. Elaboracin Propia.

6.2.4

Vista de Despliegue
El sistema ActiveSMS, despus de haber estado en pruebas servidores de desarrollo

(Pre-Produccin) se decide instalarlo y ejecutarlo en el servidor de aplicaciones de produccin

(NAP) de Conectium Limited. La topologa del sistema consiste en la plataforma de mensajera
del operador telefnico, y los sistemas de Conectium Limited.

Los telfonos celulares envan el mensaje al SMS Center, este mismo reenva el
27

mensaje hacia el IMG a travs 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 enva por
el mismo camino hasta el usuario final.

Figura 6. Vista de Despliegue. Elaboracin 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

28

6.3
6.3.1

Decisiones de Diseo
Mdulo de Lgica de Concursos y Manejo de sesiones
Para el diseo de este mdulo se aplicaron patrones de tipo estructurales, de

comportamiento y de creacin. El objetivo es resolver los problemas de diseo orientado a

objetos, utilizando tcnicas ya probadas que llevan a un ms alto nivel de abstraccin los
componentes del sistema. A continuacin, se describe en detalle qu patrones y por qu se
utilizaron dentro del diseo de este mdulo.
Fbrica Abstracta: se utiliza para crear la fbrica indicada del tipo de concurso que
crea una sesin 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 ms.

Figura 7. Fbrica Abstracta. [8]

Mtodo 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 telfonos de prueba.
La idea es tener slo 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.

29

Decoradores: se utilizan para alterar el comportamiento de los concursos, en este caso

se utilizan varios decoradores sobre una trivia genrica para agregar funcionalidades extra. Slo
se le aplic a las trivias en la primera fase del sistema.

Figura 8. Decorador. [8]

Cul es la ventaja? La principal ventaja de utilizar este patrn 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 slo aplicarle los decoradores deseados
obtenemos el comportamiento que necesitemos.

Desarrollos Futuros: En el futuro es probable que se requieran ms comportamientos.

En el caso que un cliente desee un comportamiento especial que no exista, basta con tan slo
implementar un nuevo decorador. Una vez listo se agrega al mdulo de concursos y funciona
sin ningn problema.

6.3.2

Mdulo de Conexin con la red mvil celular

La solucin propuesta para este mdulo fue crear una versin del IMG pero que enrute

todos los mensajes entrantes hacia un servidor de colas, para luego ser procesado por el
30

mdulo de manejo de concursos, que se conectara a travs de este mdulo. 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 solucin fue la idea de crear un Servlet que hiciera la misma funcin de recibir
mensajes a travs de una solicitud HTTP. La ventaja de esta propuesta es que el IMG ya posee
una forma de enviar solicitudes HTTP, entonces no se necesitara modificar nada del IMG, slo
configurarlo para que enve las solicitudes hacia el sistema ActiveSMS.

6.3.3

Mdulo de Persistencia de Datos

Este mdulo fue diseado con el patrn DAO (Data-Access-Objects):

Figura 9. Patrn DAO. [10]

Las ventajas ms importantes de utilizar este patrn:

Da un acceso transparente a la fuente de datos, ya que la implementacin se

esconde tras las interfaces. [10]

Permite migrar a otros manejadores de datos fcilmente. [Ob. Citada]

Centraliza la capa de datos en una capa separada. [Ob. Citada]

31

6.3.4

Mdulo de Administracin Web

Se toma la decisin de utilizar el patrn MVC (Modelo, Vista, Controlador) como base del
mdulo Web.

Modelo: Esta es la representacin especfica de la informacin con la cual el sistema

opera. La lgica 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 continuacin se describen los requerimientos que no estn especificados en los casos

de uso, y que debe poseer el sistema para su buen funcionamiento:

Usabilidad: la interfaz Web debe ser rpida 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 mdulos.

Desempeo: el sistema debe procesar y responder los mensajes rpidamente. De

desea que el tiempo de procesamiento sea menos a 1 segundo con el fin de soportar
grandes volmenes 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 mdulos deben estar protegidos, especficamente el mdulo Web
que puede ser visto por el pblico.

6.5

Hitos Alcanzados

Diseo general del sistema a implementar.

Arquitectura definida que cumple con los requerimientos.

Prototipo funcional del Mdulo de manejo de concursos.

Conocimiento del diseo del IMG.

32

7 Fase de Construccin I
Este captulo presenta la primera fase de construccin del proceso de desarrollo, la cual
comprende las implementaciones completas del mdulo de manejo de concursos y el mdulo
de conexin con la red celular diseados en la fase anterior. Tambin comprende la
realizacin de las primeras pruebas de funcionalidad y prueba de la arquitectura.

7.1
7.1.1

Implementacin de la Arquitectura propuesta:

Mdulo de Lgica de Concursos
El mdulo de lgica de concursos se implementa como un programa utilizando el

lenguaje Java 5. Puede ejecutarse como una aplicacin estndar, o a travs de una aplicacin
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 especfico, de no ser as se

ordena crear una sesin de un concurso con el mensaje entrante.

Pasa el mensaje a la sesin.

Devuelve el mensaje de respuesta, dado por la sesin del concurso.

33

Figura 10. Flujo de mensajes. Elaboracin 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 sesin, que contiene todo lo que implica la mecnica de
funcionamiento. Su responsabilidad es determinar como debe responder el concurso a un
mensaje entrante. El comportamiento de la sesin es posible alterarlo implementando uno o
varios decoradores para esta clase.

34

7.1.1.3 Manejador de Concursos

Su funcin principal es buscar el concurso segn el contenido de un mensaje, cuando se
crea una sesin. Para identificar el concurso se quiere jugar, el manejador tendr varias
opciones segn la configuracin:

Identificacin por palabra clave (Keyword): es cuando el contenido del primer mensaje
entrante contiene una o varias palabras que identifica al concurso. La mayora 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.

Identificacin por hora: es cuando la hora del primer mensaje entrante cae dentro de
un intervalo de un concurso previamente configurado. Se utiliza la mayora 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 perodo del programa sern identificados.

Identificacin exclusiva: se utiliza cuando un shortcode es dedicado totalmente a un

concurso. No se puede reutilizar el shortcode con otros concursos de forma simultnea.
Por ejemplo, un concurso para hacer un sorteo de un viaje, donde la gente escribe sus
datos y los enva al nmero de acceso indicado en la promocin.

Es importante saber que los concursos tienen fecha de inicio y una de finalizacin, la
identificacin 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 funcin es almacenar toda la informacin referente al
concurso. Por ejemplo, la clase Trivia contiene la coleccin de preguntas, respuestas, puntaje,
etc.

35

7.1.1.5 Manejador de telfonos de prueba

Cuando un concurso en especfico est en proceso de pruebas, el pblico en general no
debera tener acceso a ste, solamente los usuarios de prueba previamente registrados
pudiesen utilizarlo. La funcin de este componente es verificar, a la llegada de un mensaje si el
nmero de telfono desde donde fue generado pertenece a un usuario de prueba o no. Puede
ser extendido para manejar listas blancas y/o negras que filtran telfonos no autorizados.
7.1.2

Mdulo de Conexin con la Red Celular

Este mdulo se conforma de dos componentes: una nueva versin del IMG, y el

subsistema de conexiones que se comunican entre s a travs de un servidor de colas. El

software utilizado fue Apache ActiveMQ 4.0 el cual es una implementacin gratuita del servidor
de colas que incluye un API para Java.
7.1.2.1 IMG-Queue
Es una modificacin del IMG, la cual cuando recibe el mensaje desde la red celular a
travs 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 apndice O.

Figura 11. Flujo del IMG-Queue. Elaboracin Propia.

36

La forma ms comn del IMG para conectarse con la red celular es a travs de una
conexin SMPP con el SMSC del operador telefnico. Sin embargo en esta fase se implement
una forma de conexin a travs 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 configuracin desde un archivo
(activesms.properties) para posteriormente establecer una conexin con el servidor de colas.
Una vez conformado, el sistema se prepara para recibir mensajes que luego sern procesados
por el mdulo de manejo de concursos.

7.1.3

Mdulo de Persistencia
El mdulo de persistencia es implementado utilizando la herramienta Hibernate 3

(versin 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 mdulo de manejo de concursos y el mdulo Web utilizan el de persistencia para
obtener y almacenar la informacin 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]

37

Ahora bien, para lograr la funcionalidad bsica se implement un manejador genrico

para Hibernate de objetos que realiza todas las operaciones CRUD (en ingls, 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 cdigo fuente para
independizar el cdigo fuente Java del cdigo HQL (Hibernate Query Language). Aparte de eso,
debido a que Hibernate maneja transacciones, se necesit disear e implementar una interfaz
para manejarlas. Para ms detalles ver los documentos de mapeo de hibernate para cada
objecto en el apndice P.

7.2

Hitos Alcanzados

Primer sistema con la funcionalidad bsica.

Dominio de la funcionalidad e implementacin del IMG.

Verificacin de los tiempos de respuesta del sistema.

38

8 Fase de Construccin II
En este captulo se presenta la segunda fase de construccin del sistema, que abarca
principalmente la implementacin del mdulo Web y la parte restante del mdulo de
persistencia. Adicionalmente se agregaron nuevos requerimientos dentro de los mdulos de
manejo de concursos. Finalmente se realizaron algunas pruebas del sistema.

8.1

Mdulo Web
Este mdulo utiliza una arquitectura de 3 capas, que son las siguientes: La capa de

presentacin representada por las pginas, la capa de aplicacin que es manejada por el
servidor Web y la capa de datos en la cual se utiliza el mdulo de persistencia de datos.

El mdulo Web se implement utilizando el marco de trabajo Apache Struts v.1.2,

facilitando la codificacin y mantenimiento de aplicaciones Web, adems de adoptar el patrn
MVC (Model-View-Controller) como su objetivo principal.

Figura 13. Arquitectura Struts. [13]

El archivo de configuracin de Struts (struts-config.xml) se puede detallar en el apndice Q.

39

8.1.1

Vistas
Las vistas son implementadas utilizando pginas JSP + Struts TagLibs + StrutsForm. En

las primeras se encuentra todo el diseo grafico y la informacin que est contenida en los
formularios de Struts. Previamente el controlador carga la informacin de la base de datos en
los formularios de Struts, luego esta informacin se despliega en el navegador, segn 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 peticin HTTP del

navegador, busca que accin se necesita realizar, la ejecuta, carga el formulario de Struts y
luego redirecciona a la pgina JSP indicada.
8.1.3

Modelo
La capa del modelo de datos, viene directamente desde los objetos del negocio a travs

del mdulo de persistencia.

8.2

Conexin con la red celular a travs del mdulo Web

Como se ha mencionado anteriormente, para facilitar la integracin del IMG con el

sistema ActiveSMS, se utiliza un Servlet que atiende peticiones HTTP para recibir los mensajes
que el IMG enva y viceversa. Esta parte del mdulo Web es una implementacin del
subsistema de conexiones que se describi anteriormente, slo que esta vez se usa
conjuntamente con un Servlet. A continuacin 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 parmetros en un objeto mensaje.

3. Se invoca al mdulo 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

Bsicamente se facilita la integracin; de hecho las primeras pruebas reales con

sistemas en produccin utilizan este esquema de conexin, ya que ahorra tiempo y trabajo de
los analistas de operaciones, adems de no utilizar la versin modificada del IMG evitando
fallas no previstas y el despliegue de servidores de colas para produccin.
40

8.3

Mdulo de Persistencia
En esta segunda parte de construccin de este mdulo, se complet la implementacin

de todas las interfaces y fabricas, que son necesarias para el correcto funcionamiento del
mdulo Web.
Modificacin 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 relacin, lo que llevara a dejar datos no relacionados, y a generar un error.
Por ltimo se prepar el cdigo para las consultas HQL que hacen los reportes de
trfico de mensajes, sorteos de varias modalidades, ms puntos por participante, filtros, etc.

8.4

Hitos Alcanzados

Sistema totalmente funcional.

Mayor velocidad de respuesta (Aprox. 66 mensajes por segundo).

Disminucin de errores en los comportamientos de las trivias.

Integracin de todos los mdulos del sistema.

41

9 Fase de Transicin
En este captulo 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 decisin de
implementar algunos y les dems se planificaron para versiones futuras. Para finalizar se
realiza un resumen del estado actual del sistema.

9.1

Mdulo de Lgica 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 codificacin 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 das 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 apndice I.

9.2

Proceso de Pruebas del Sistema

En las fases anteriores, aparte del diseo e implementacin se realizaron distintas

pruebas del sistema; sin embargo durante la fase de transicin fueron mucho ms 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 Integracin.

Pruebas Funcionales.

Pruebas contra requerimientos no funcionales.

42

Durante todo el desarrollo se utiliz una herramienta de control de versiones para

almacenar cada una de las versiones diarias de la aplicacin. Cada una consiste en que cada
seccin nueva del cdigo 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 tambin podemos detectar cualquier falla que ocurra al agregar el
cdigo nuevo.

En la fase de elaboracin se escribi un caso de prueba unitaria para el mdulo de

lgica 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 construccin se realizaron
pruebas de integracin entre el mdulo de conexin con la red celular y el mdulo de lgica de
concursos, fue en esta prueba donde se logr jugar por primera vez un concurso SMS desde un
telfono 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 desempeo y las de usabilidad. Para las pruebas de
desempeo 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 mdulos 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 mdulo
Web, y luego que jugaran la misma Trivia que ellos haban creado. Consideraron que el sistema
ActiveSMS era bastante amigable, aunque no entendan 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 especfico.
43

9.3

Estatus Actual del Sistema

Para el primer desarrollo de ActiveSMS se implementaron los cuatro mdulos descritos

anteriormente. Bsicamente, se crean y configuran los concursos va el mdulo Web que son
guardados en la base de datos (mdulo de persistencia), luego cuando llegan los mensajes por
el mdulo de conexin con la red celular, el sistema puede empezar a procesar mensajes y
comienza el flujo del juego (mdulo de lgica de concursos) hasta que finaliza la interaccin con
el usuario.

Hasta ahora, los concursos disponibles en el mdulo de lgica de concursos son: Trivias
y Comentarios, los cuales son configurados a travs del mdulo 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 versin futura se piensan
agregar ms comportamientos u opciones a las trivias, as como tambin otros tipos de
concursos como Votaciones, Loteras, Pruebas de admisin, etc.
Por otro lado, el mdulo Web slo maneja reportes sencillos de trfico, realiza sorteos y
contiene un pequeo buscador de mensajes enviados y recibidos. Para la prxima versin se
requieren hacer reportes grficos, buscadores ms avanzados, sorteos con distintas
modalidades, en fin, una serie de mejoras a nivel de reportes Web. A pesar de las pruebas
exhaustivas del mdulo Web, todava quedan algunos pequeos errores que sern corregidos
prximamente.

Actualmente el sistema ActiveSMS se encuentra operativo y totalmente funcional en los

servidores de produccin de Conectium Limited. Es utilizado como el nuevo sistema para
concursos de Radio y TV en toda Latinoamrica. Algunos de los pases en los cuales se puede
utilizar ActiveSMS son: Panam, Chile, Colombia, Ecuador, Mxico, Bolivia, Puerto Rico, Costa
Rica, Guatemala, El Salvador y Venezuela.

44

10 Conclusiones
ActiveSMS es un sistema automatizado diseado para integrar las funcionalidades de
creacin, mantenimiento y reportes de todos los tipos de concursos SMS de forma rpida y
sencilla. Su diseo fue pensado para que sirviera como plataforma para disear e implementar
cualquier tipo de concurso y para reutilizar al mximo posible el cdigo.

La gran ventaja de este sistema es que reduce considerablemente los tiempos de

diseo, desarrollo, instalacin 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 an los mismos clientes o los Analistas de Producto utilizan el
mdulo Web para crear y monitorear sus concursos directamente.

Otra de las caractersticas es que provee una forma rpida y sencilla de crear, activar y
monitorear concursos utilizando una aplicacin Web como parte del esencial del sistema. Del
mismo modo la separacin de las capas dentro de la aplicacin para facilitar la integracin de
los componentes y el mantenimiento del sistema. Se decidi basarse en la metodologa RUP
para desarrollar un producto que cumpla con las mejores prcticas en el desarrollo de software.

El sistema se compone de cuatro grandes mdulos:

En primer lugar el mdulo de lgica de concursos y procesamiento de sesiones,
que es la base fundamental del sistema, ya que se puede extender fcilmente para programar
cualquier tipo de concursos SMS.
Segundo, el responsable de enviar y recibir los SMS por medio de varias vas es el
mdulo de conexin con la red celular, que se encuentra integrado directa o indirectamente
con el sistema IMG (Internet Message Gateway).
Tercero el mdulo Web, es considerado otra pieza clave que se encarga de la
administracin general del sistema, creacin y modificacin de concursos, reportes, entre otros;
bsicamente desde all se controla todo el sistema.

45

Por ltimo el mdulo 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 informacin 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 especfica que no exista 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 traducindose en mayor cantidad y calidad de concursos SMS para toda
Latinoamrica.

46

11 Recomendaciones

Comprender los mecanismos para crear nuevos tipos de concursos, dentro del mdulo

de lgica de concursos y procesamiento de sesiones. Se recomienda leer las referencias

bibliogrficas de los patrones decorador, mtodo plantilla y fbrica abstracta.

Para el Mdulo Web, mejorar el manejo de excepciones en versiones futuras; plantear e

implementar un esquema ms 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 patrn MVC.

Optimizar la configuracin de caches, y archivos de mapas de Hibernate en el mdulo de

persistencia.

Mejorar el enrutamiento de mensajes por parte del IMG, para que se pueda verificar la

operadora, pas y nmero de acceso.

Realizar la integracin de las configuraciones del IMG con las de ActiveSMS.

Aadir un men de ayuda y de preguntas frecuentes para el portal Web.

Mantener una metodologa de desarrollo basada en RUP, realizando algunas de sus

actividades ms 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.

47

12 Notas
[1] Conectium Limited. Misin-Visin. Extrado el 16 de febrero de 2007.
URL:http://www.conectium.com/es-conectium.html

[2] Hord Jennifer. How SMS Works. Extrado el 16 de febrero de 2007.

URL: http://electronics.howstuffworks.com/sms.htm
[3] Varios Autores. Short Message service center. Extrado 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. Extrado el 16 de febrero de 2007
de Wikipedia.
URL: http://en.wikipedia.org/wiki/SMPP
[5] Sadoski, Darleen (2000), Three Tier Software Architectures. Extrado 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. Extrado 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
pginas.
[8] Gamma, Erich and Helm Richard. Design Patterns: Elements of Reusable Object-Oriented
Software. Addison-Wesley Professional, 1era edicin, 1995, 395 pginas.
[9] Popkin Software and Systems, Modelado de Sistemas con UML. Extrado el 16 de
febrero de 2007.
URL: http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/multiple-html/index.html

48

[10] Sun Developers Network, Core J2EE Patterns - Data Access Object. Extrado el 30 de
Julio de 2006.
URL: http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
[11] Varios Autores, Modelo Vista Controlador. Extrado el 16 de febrero de 2007 de
Wikipedia en espaol.
URL: http://es.wikipedia.org/wiki/Modelo_Vista_Controlador
[12] HIBERNATE - Relational Persistence for Idiomatic Java, Hibernate Reference
Documentation. Extrado 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. Extrado 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

49

13 Referencias Bibliogrficas
Ambler, S. The Unified Process Elaboration Phase. CMP, 1era edicin, 2000, 277 pginas.

Ambler, S. The Unified Process Transition Phase. CMP, 1era edicin, 2001, 309 pginas.

Brown, E. and Helm R. AntiPatterns: Refactoring Software, Architectures, and Projects in

Crisis. John Wiley & Sons, 1era edicin, 2001, 336 pginas.
Fowler, M. Analysis Patterns: Reusable Object Models. Addison-Wesley Professional, 1era
edicin, 1996, 384 pginas.

Fowler, M. Patterns of Enterprise Application Architecture. Addison-Wesley Professional, 1era

edicin, 2002, 560 pginas.
Gamma, E. and Helm R. Design Patterns: Elements of Reusable Object-Oriented Software.
Addison-Wesley Professional, 1era edicin, 1995, 395 pginas.

Larman, C. Applying UML and Patterns. Prentice Hall, 2da edicin, 2002.
Kroll P. The Rational Unified Process Made Easy. Addison-Wesley Professional, 1era edicin,
2003, 464 pginas.
Pugh E. and Gradecki J. Professional Hibernate. Wrox, 1era edicin, 2004, 456 pginas.
Teurel, A. (2001), Pruebas de sistemas orientados a objetos. Extrado el 16 de febrero de
2007. URL: http://www.ldc.usb.ve/~teruel/ci3715/clases/testing2.html

50

14 Apndices
Apndice A: Documento Visin del Proyecto.
Apndice B: Documento de Casos de uso.
Apndice C: Documento Glosario del sistema.
Apndice D: Documento de Riesgos.
Apndice E: Plan de desarrollo del proyecto.
Apndice F: Descripcin de los requerimientos por parte de Conectium Limited.
Apndice G: Prototipo del mdulo Web.
Apndice H: Modelo conceptual.
Apndice I: Diagrama de Clases. Mdulo lgica de concursos y manejo de sesiones.
Apndice J: Diagrama de Clases. Mdulo conexin con la red celular.
Apndice K: Diagrama de Clases. Mdulo Web.
Apndice L: Diagrama de Clases. Mdulo de persistencia.
Apndice M: Diagrama de secuencia. Procesar mensaje.
Apndice N: Diagrama de secuencia. Crear/Editar/Eliminar Trivias.
Apndice O: Arquitectura del IMG-Queue.
Apndice P: Archivos de mapeo de Hibernate.
Apndice Q: Archivo de configuracin de Struts.

Los apndices se encuentran en el disco (CDROM) de anexos.

51