UNIVERSIDAD SIMÓN BOLÍVAR PLATAFORMA PARA LA CREACIÓN, MANTENIMIENTO, MONITOREO Y DESPLIEGUE AUTOMATIZADO DE CONCURSOS PARA SMS

Transcripción

1 UNIVERSIDAD SIMÓN BOLÍVAR Ingeniería de la Computación PLATAFORMA PARA LA CREACIÓN, MANTENIMIENTO, MONITOREO Y DESPLIEGUE AUTOMATIZADO DE CONCURSOS PARA SMS Por Miguel Ángel Sucre González INFORME FINAL DE CURSOS EN COOPERACION Presentado ante la ilustre Universidad Simón Bolívar como requisito parcial para optar al título de Ingeniero en Computación Sartenejas, Febrero de 2007

2 UNIVERSIDAD SIMÓN BOLÍVAR Decanato de Estudios Profesionales Coordinación de Ingeniería de la Computación Acta de Evaluación de Cursos en Cooperación PLATAFORMA PARA LA CREACIÓN, MANTENIMIENTO, MONITOREO Y DESPLIEGUE AUTOMATIZADO DE CONCURSOS PARA SMS Presentado por Miguel Ángel Sucre González Este informe final de Cursos de Cooperación ha sido aprobado por el siguiente jurado examinador: Prof. Ascánder Suárez Jurado Prof. Carlos Figueira Tutor Académico ii

3 PLATAFORMA PARA LA CREACIÓN, MANTENIMIENTO, MONITOREO Y DESPLIEGUE AUTOMATIZADO DE CONCURSOS PARA SMS Resumen En el mundo de la telefonía celular es importante el crecimiento que ha tenido el uso de la mensajería de texto en los últimos años. Gracias a esto la mensajería de texto no sólo es para comunicarse entre personas sino que también se utiliza para el entretenimiento, participación y diversión de los usuarios, principalmente en la Radio y TV. En respuesta al nuevo crecimiento de aplicaciones para la mensajería de texto, surge el objetivo de esta pasantía: la elaboración de un sistema automatizado para la creación, mantenimiento, y reportes de concursos para SMS (Short Message Service). El SMS es un servicio para el envío y recepción de mensajes cortos, que funciona sobre las redes de telefonía celular digital. Se desarrollo una primera versión del sistema, llamado ActiveSMS que engloba todas las tareas que implican crear, mantener y monitorear un concurso SMS, reduciendo los recursos necesitados por la empresa Conectium Limited para el desarrollo y la puesta en marcha de los concursos. El sistema se compone de cuatro módulos: el de lógica de concursos (cómo funcionan los concursos y qué contenido mostrarán), de conexión con la red celular (cómo llegan los mensajes a la red celular y viceversa), Web para configurar visualmente los concursos y otras opciones, por último, el de persistencia para almacenar información del sistema en un repositorio de datos. iii

4 Dedicatoria A mi madrina, Carmen Cecilia González de Mayz. iv

5 Tabla de Contenidos 1 Introducción Entorno Empresarial Misión y Visión de Conectium Limited Visión Misión Trayectoria de Conectium Limited en el ámbito Internacional y Venezuela Organización y Estructura de Conectium Limited Unidad de Gerencia y Mercadeo Unidad de Tecnología y Operaciones Unidad de Contenido y Multimedia Ubicación del pasante Planteamiento del Problema Objetivo General: Objetivos Específicos: Marco Teórico Definición de SMS Funcionamiento del SMS SMS Centers (SMSC) Protocolos de comunicación Protocolo SMPP Arquitectura de Tres Capas Cliente/Servidor Metodología de Desarrollo Aplicada Dos dimensiones del proceso de desarrollo Estructura Dinámica de RUP Fase de Inicio Fase de Elaboración Construcción Transición Estructura Estática de RUP Patrones de Diseño Clasificación de Patrones Patrones de Creación v

6 Patrones Estructurales Patrones de Comportamiento Fase de Inicio: Visión del Proyecto Módulo de lógica de concursos y procesamiento de sesiones Módulo de Conexión con la red móvil celular Módulo de Administración Web Módulo de Persistencia de Datos Actores y principales casos de uso: Actores Casos de Uso Módulo de Manejo de concursos: Módulo de Conexión con la red Celular Módulo Web: Módulo de Persistencia de Datos Glosario del Sistema Estudio Inicial de Riesgos Plan de Desarrollo del Software Hitos Alcanzados Fase de Elaboración Vistas de la arquitectura del Software Las Vistas de la arquitectura Vista de Casos de Uso Diagrama de Casos de uso Vista Lógica Modelo Conceptual o del Dominio Diagramas de Clases Diagramas de Secuencia Vista de Implementación Vista de Despliegue Decisiones de Diseño Módulo de Lógica de Concursos y Manejo de sesiones Módulo de Conexión con la red móvil celular Módulo de Persistencia de Datos vi

7 6.3.4 Módulo de Administración Web Lista de Requerimientos no funcionales Hitos Alcanzados Fase de Construcción I Implementación de la Arquitectura propuesta: Módulo de Lógica de Concursos Manejador de Sesiones: Sesiones Manejador de Concursos Concursos Manejador de teléfonos de prueba Módulo de Conexión con la Red Celular IMG-Queue Subsistema de Conexiones Módulo de Persistencia Hitos Alcanzados Fase de Construcción II Módulo Web Vistas Controlador Modelo Conexión con la red celular a través del módulo Web Módulo de Persistencia Hitos Alcanzados Fase de Transición Módulo de Lógica de Concursos: Comentarios Proceso de Pruebas del Sistema Estatus Actual del Sistema Conclusiones Recomendaciones Notas Referencias Bibliográficas Apéndices vii

8 Lista de Figuras Figura 1.Funcionamiento Del SMS. [2]... 9 Figura 2. Arquitectura de tres capas. [6] Figura 3. RUP en dos dimensiones. [7] Figura 4 Plan de desarrollo del software. Elaboración propia Figura 5. Vista Implementación. Elaboración Propia Figura 6. Vista de Despliegue. Elaboración Propia Figura 7. Fábrica Abstracta. [8] Figura 8. Decorador. [8] Figura 9. Patrón DAO. [12] Figura 10. Flujo de mensajes. Elaboración Propia Figura 11. Flujo del IMG-Queue. Elaboración Propia Figura 12. Arquitectura de Hibernate. [12] Figura 13. Arquitectura Struts. [13] viii

9 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

10 1 Introducción La popularidad de la mensajería de texto ha venido aumentando aceleradamente a lo largo de los últimos años en Venezuela y Latinoamérica en general. Gracias a su bajo costo y gran potencial de aplicaciones, los mensajes de texto son la primera forma de comunicación a través de las redes móviles en Venezuela. Hoy en día aproximadamente el 60% de los venezolanos están en capacidad de utilizar este servicio con expectativas de crecimiento bastante altas. La mensajería de texto no solo sirve para comunicarse entre los suscriptores de las compañías de telefonía celular, además sirven para el entretenimiento (Trivias, Votaciones, Comentarios, etc.), consultas y otra infinidad de servicios de información también llamados servicios SMS Premium. Gracias al crecimiento, la demanda de servicios de entretenimiento SMS ha incrementado de la misma forma, lo cual requiere que se desarrollen cada vez más y mejores sistemas que puedan satisfacer esta creciente demanda del mundo móvil. La intención de este proyecto es diseñar e implementar un sistema para la construcción, administración y monitoreo de concursos a través de mensajería de texto, de fácil uso y rápida puesta en marcha, además de contar con la capacidad de extender sus funcionalidades de forma sencilla y rápida por cualquier otro desarrollador. El objetivo principal del proyecto hacer un sistema para crear, administrar y monitorear un concurso SMS totalmente adaptable a las necesidades del usuario. Para lograr esto se requiere manejar cual es la lógica de los tipos concursos, los distintos comportamientos que deben tener los concursos durante la sesión de juego. Por otro lado se necesita la conexión con la red celular para el envío y recepción de mensajes, y por último una consola Web administrativa que permita manipular los concursos. 1

11 El proyecto se desarrolla basándose en la metodología Rational Unified Process tomando lo más importante, con el fin de utilizar las mejores prácticas de desarrollo, dando como resultado un software de calidad y documentos que sirven como referencia para futuros desarrollos. Este informe está estructurado de la siguiente forma: en el primer capítulo se describe el entorno empresarial en donde se desarrolló el proyecto, como segundo el planteamiento del problema, luego un marco teórico y finalmente cinco capítulos que describen las actividades que se realizaron durante las etapas de la metodología RUP: Fase de de inicio, elaboración, constricción I, constricción II y la fase transición. 2

12 2 Entorno Empresarial En este capítulo se describe el entorno en el cual el proyecto de pasantía fue desarrollado, con el fin de conocer a la empresa Conectium Limited. Se expone la misión y visión de esta empresa, luego la trayectoria de Conectium Limited en el ámbito internacional y en Venezuela, seguido de la organización y estructura, y finalmente la ubicación del pasante dentro de la empresa. 2.1 Misión y Visión de Conectium Limited Visión Convertirse en el proveedor líder de soluciones de Internet inalámbrica para las más importantes compañías de servicios de comunicación móvil en toda Latinoamérica. [1] Misión Conectium Limited, se propone obtener la mayor base de suscriptores de comunicación inalámbrica del continente, suministrando un servicio de Internet móvil de amplio espectro; basado principalmente en el aporte de desarrollo de contenido y asesoría en gerencia de redes que proporcione al usuario final la información apropiada a sus necesidades y que le permitan experimentar toda la funcionalidad de la autopista de la información a través de sus equipos de teléfono celular. [Ob. Citada] 2.2 Trayectoria de Conectium Limited en el ámbito Internacional y Venezuela Conectium Limited fundada en el año 2000, líder en Internet Móvil en Latinoamérica. Es una empresa que ha incrementado su cartera de productos y servicios para ofrecer aplicaciones como portales SMS, WAP entre otros, desarrollo de contenidos, descargas de tonos para celulares, imágenes y video, etc. En Venezuela se encuentra la base de desarrollo y operaciones de la empresa, contando también con oficinas comerciales en México, Panamá, Costa Rica, Colombia, y Chile. Conectium Limited desarrolla soluciones de Internet móvil utilizando la figura private-label, es decir portales que llevan la marca y nombre del operador celular, desarrollados para satisfacer las necesidades de las empresas celulares (operadores) y sus mercados. Se especializa en el manejo y desarrollo de aplicaciones, que a través de las distintas interfaces inalámbricas, permiten integrar contenidos, información, y aplicaciones apropiadas para la Internet móvil y otros servicios. 3

13 2.3 Organización y Estructura de Conectium Limited La organización de la empresa consta de tres grandes unidades operativas: 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 Unidad de Tecnología y Operaciones Se encarga del desarrollo de software y del correcto funcionamiento de este las 24 horas, 7 días a la semana. Departamento de Operaciones y Departamento de Tecnología Unidad de Contenido y Multimedia Responsables de mantener y actualizar las categorías y objetos de contenido generados periódicamente por la empresa. Departamento de Contenido. 2.4 Ubicación del pasante El proyecto de pasantía se realizó en la unidad de Tecnología y Operaciones, específicamente en el departamento de tecnología. El proyecto consiste en diseñar e implementar un sistema funcional para la creación, mantenimiento y monitoreo de concursos SMS. El pasante fue el único encargado de toda la tarea, basándose en requerimientos solicitados por parte del personal del área de productos y la dirección de la empresa. Para el despliegue en producción del sistema se necesitó el apoyo del Departamento de Operaciones. En el siguiente capítulo, se plantea el problema con mayor detalle, ya que fue el objeto de la pasantía. 4

14 3 Planteamiento del Problema Actualmente Conectium Limited cuenta con una herramienta Web para servicios SMS de Radio y TV. Esta herramienta no posee la funcionalidad para crear concursos, y mucho menos concursos personalizados para clientes distintos; sin embargo es posible emular concursos muy sencillos que se pueden implementar en corto tiempo. Las limitaciones de esta herramienta son muy grandes, sólo se pueden emular preguntas con una sola respuesta, sin ningún tipo de lógica o comportamiento. Ya que cada cliente exige un concurso estrictamente personalizado, la empresa se ve en la obligación de desarrollar un software adicional que cumpla con las especificaciones del cliente. Las características de los concursos varían mucho, desde el tipo de concurso que pueden ser Trivias, Votaciones, Sorteos, Comentarios, etc., hasta el comportamiento interno de cada uno de ellos, por ejemplo, preguntas en orden aleatorio, acumulación de puntos, etc. En fin, la cantidad de requerimientos y detalles de los concursos por parte del cliente son diversos y amplios. Adicionalmente se requiere manejar países, operadoras y números cortos de acceso (Short Codes), en donde van a estar operativos estos concursos. Esta tarea es bastante complicada debido a que, primero se necesita desplegar el concurso, y luego configurar los sistemas que procesen mensajes (IMG) según los requerimientos de cada país, lo cual implica tiempo fuera del aire y probables conflictos con otros servicios. Por ejemplo, si una trivia ya se encuentra activa en Venezuela (Movistar, Movilnet, Digitel) con el numero de acceso 1515, y la palabra clave F.* basada en expresiones regulares; de igual manera se quiere poner en funcionamiento una votación en Venezuela y en México utilizando también el 1515 con la palabra clave Futbol, esta trivia generará conflictos con la anterior. Entonces Por qué no es posible tener un sistema integrado con los sistemas de recepción y envío de mensajes, que sirva para generar concursos que cumplan con los requerimientos del cliente rápidamente? Como se menciona anteriormente, los clientes necesitan concursos bastante particulares, por ende los detalles a controlar son amplios, pero en algunos casos las funcionalidades se pueden repetir. Por ejemplo, en el caso de una trivia con preguntas aleatorias. 5

15 De allí surge la necesidad de diseñar un sistema automatizado que maneje la creación, mantenimiento, monitoreo despliegue de concursos a través de mensajería de texto SMS, que cuente con facilidad para atender de forma rápida nuevos requerimientos por parte de los clientes. Otra de las limitantes es el proceso de creación, mantenimiento y puesta en marcha de concursos SMS, se requiere de un Analista de producto encargado de tomar todos los requerimientos del cliente, dos o más Analistas de Sistemas que se encarguen de diseñar, implementar y probar el concurso especificado por el cliente, finalmente se necesita un analista de operaciones para colocarlo en producción. Adicionalmente, si el cliente necesita realizar cualquier cambio en las especificaciones se repite nuevamente este proceso. Por otro lado, los reportes de actividad de los concursos son realizados por un analista que recopila la información directamente de la base de datos, la procesa y luego la envía a los respectivos clientes periódicamente o cuando estos la soliciten. Se puede concluir que estos procesos son muy lentos y requieren mucho personal, lo cual genera retrasos de respuesta al cliente, mayor probabilidad de fallas y poca reutilización de software. De allí surge otro objetivo del proyecto de pasantía que consiste en desarrollar una consola o portal Web desde donde el cliente de Conectium Limited o el analista de producto responsable puedan crear de forma automatizada los concursos. De esta forma se mejora la eficiencia dentro de la empresa y se brinda mejor calidad de servicio a los clientes. 6

16 3.1 Objetivo General: Diseñar e implementar una plataforma que integre las funcionalidades de creación, mantenimiento y reportes de todo tipo de concursos SMS. Esta plataforma estará constituida por una herramienta Web y un sistema de procesamiento de mensajes de texto. En la primera fase del desarrollo de la herramienta Web se incluirá únicamente el desarrollo de las siguientes secciones: Administración, Reportes y Concursos. Sin embargo, en el módulo de concurso se desarrollará únicamente la sección de Trivias y Comentarios, que integran las funcionalidades de creación, edición, verificación, sorteos y visualización de aquellos participantes con mayor número de mensajes o puntos. 3.2 Objetivos Específicos: Desarrollar un programa que permita manejar las sesiones y la interacción entre los usuarios y los concursos, utilizando patrones de diseño de tipo estructural, creación y comportamiento. Módulo de Manejo de concursos y procesamiento de sesiones. Implementar varias interfaces con el sistema IMG (Internet Message Gateway) para la transmisión y recepción de mensajes de texto. Módulo de Conexión con la red móvil celular. Desarrollar una aplicación Web, utilizando el patrón de diseño MVC Modelo Vista Controlador, para la administración, generación y reportes de los concursos SMS. Implementar una arquitectura para la persistencia de datos, basada en el patrón de diseño DAO (Data Access Objects), con el fin independizar el manejador de datos. 7

17 4 Marco Teórico En este capítulo, serán definidos algunos términos y conceptos específicos del tema a tratar. Son tomados de varios autores reconocidos en el área Definición de SMS SMS significa Servicio de Mensajes Cortos (En inglés, Short Message Service). Es un método de comunicación que envía texto entre teléfonos celulares. También es posible desde computadoras o dispositivos móviles, a teléfonos celulares y viceversa. Se le llama corto porque el tamaño máximo del mensaje es de 160 caracteres (letras, números o símbolos del alfabeto Latino). Para otros alfabetos como el chino, el tamaño máximo es de 70 caracteres. [2] El SMS fue creado en Europa a finales de los años 1980 s cuando se incluyo dentro de la tecnología GSM, inicialmente se ideó para dejar mensajes cortos a usuarios de la telefonía celular para cuando tuviesen el teléfono apagado o sin cobertura. [Ob. Citada] 4.2 Funcionamiento del SMS Los teléfonos celulares utilizan un canal especial de comunicación con la celda, llamado el canal de control, que se utiliza para mantener en la red al usuario, hacer y recibir llamadas. El canal de control funciona como vía para enviar los SMS. Cuando se envía un SMS, el teléfono desde donde se origina lo envía a la celda a través del canal de control, luego va desde la torre hasta el SMS Centre, el cual lo redirecciona hasta la otra torre donde se encuentra el teléfono destinatario, una vez ahí la torre hace la entrega. [Ob. Citada] 8

18 Figura 1.Funcionamiento Del SMS. [2] 4.3 SMS Centers (SMSC) Cuando un usuario envía un mensaje de texto a otro usuario, el mensaje se almacena en el SMSC, el cual lo entrega a su destinatario final en el momento que esté disponible en la red; a esto se le llama guardar y reenviar. Usualmente el SMSC se puede configurar para definir los tiempos para guardar los mensajes. [3] Un mensaje puede venir también desde una aplicación, por ejemplo, un buzón de correos de voz enviando alertas de mensajes de voz. Los operadores telefónicos permiten a algunas empresas interactuar con su SMSC para enviar o recibir mensajes. Desde el punto de vista del SMSC, estas aplicaciones son llamadas SME (En inglés, Short Message Entities). [Ob. Citada] Protocolos de comunicación "Para la transmisión y recepción de mensajes SMS, los SMSC tienen interfaces de redes cableadas, así como también interfaces con la red móvil. Se han definido un número de protocolos para poder interactuar con los SMSC desde las redes cableadas: SMPP (Short message peer-to-peer). EMI/UCP (External Machine Interface/Universal Computer Protocol). CIMD (Computer Interface to Message Distribution). OIS (Open Interface Specification). [Ob. Citada] 9

19 4.4 Protocolo SMPP "El SMPP es un protocolo estándar de las telecomunicaciones para intercambiar mensajes SMS entre dos nodos entidades SMS como lo son los SMS Centers Frecuentemente es utilizado para permitir a las aplicaciones de terceros (Ej. Proveedores de servicios de valor agregado como lo es Conectium Limited) enviar y recibir mensajes de forma masiva. EL SMPP fue originalmente diseñado por Aldiscon, una pequeña empresa irlandesa. En 1999, paso a ser parte del SMS Forum. [4] Está basado en pares de solicitud y respuesta de PDUs (Protocol Data Units, o paquetes) intercambiados por conexiones TCP/IP o X.25 SVC3. Los PDU son codificados en formato binario por eficiencia. Las versiones mas utilizadas son la 3.3 y la 3.4 que permite la opción de un transmisor-receptor sobre una sola conexión. [Ob. Citada] 4.5 Arquitectura de Tres Capas Cliente/Servidor "La arquitectura del software de tres o más capas nace en los años 1990s para superar las limitaciones de la arquitectura de dos capas. La capa adicional (capa intermedia) se encuentra entre la interfaz del usuario (cliente) y el manejador de datos (servidor). Esta capa intermedia provee el manejo de procesos de la lógica del negocio, puede soportar cientos de usuarios, utilizando varios mecanismos. La arquitectura de tres capas es utilizada cuando se necesita un diseño de cliente/servidor efectivo y distribuido que provea un mejor desempeño, flexibilidad, mantenimiento, reutilización y escalabilidad, al mismo tiempo esconder del usuario toda la complejidad del procesamiento distribuido. Estas características han hecho que la arquitectura de tres capas sea muy popular en las aplicaciones de Internet y otros sistemas de información. [5] 10

20 Figura 2. Arquitectura de tres capas. [6] Una arquitectura de tres capas, incluye una capa superior donde residen la interfaz gráfica y servicios del usuario. Una segunda capa que se encarga de proveer servicios para el manejo de procesos (administración y monitoreo) que son utilizados entre aplicaciones. La segunda capa o capa intermedia también es llamada servidor de aplicaciones. La centralización de los procesos lógicos hace que la administración y los cambios sean mucho más fáciles, simplemente se realiza el cambio una sola vez dentro del servidor de la capa de aplicación y automáticamente está disponible para todos los usuarios. Con otro diseño de arquitectura se tendría que hacer el cambio en cada aplicación del usuario. [Ob. Citada] La tercera capa o capa de datos, provee la funcionalidad del manejo optimizado de servicios de datos y archivos. El manejo de datos asegura que la data sea consistente en todo el sistema distribuido, utilizando funciones como bloqueo, consistencia y replicación de datos. La conectividad entre las capas puede ser modificada según los requerimientos de datos y servicios por parte del usuario. [Ob. Citada] En algunos casos la capa intermedia se divide en varias unidades, en estos casos la arquitectura es referida como multi-capa. Por ejemplo, algunas aplicaciones de Internet, tienen clientes escritos en HTML y servidores de aplicaciones en C++ o Java, la brecha entre estas dos capas es muy grande para que trabajen en conjunto. A pesar de esto, se utiliza otra capa intermediaria; un servidor Web con un lenguaje de tipo scripting (JSP, ASP, etc.) que se encargue de procesar las solicitudes de los clientes, y genere el HTML a partir de los servicios de la capa de aplicación. [Ob. Citada] 11

21 4.6 Metodología de Desarrollo Aplicada La metodología basada para el desarrollo del proyecto fue la de Rational Unified Process (RUP). Se dice que fue basada porque no se siguió estrictamente sus lineamientos, sin embargo se utilizaron varios aspectos y mejores prácticas que ayudan desarrollar un mejor software. En pocas palabras, RUP es un proceso de desarrollo de software. Provee un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organización de desarrollo. Su principal objetivo es generar software de alta calidad que cumpla con las necesidades de los usuarios finales, dentro de un tiempo y presupuesto predecible. RUP adopta las mejores prácticas del desarrollo de software, comprobadas a lo largo del tiempo por organizaciones exitosas: desarrollar iterativamente, manejar requerimientos, arquitectura basada en componentes, modelar visualmente el software, verificar continuamente la calidad y controlar cambios del software. Como ningún proceso es ideal para todos los desarrollos de software, RUP es configurable y se adapta a cualquier tipo de organización, desde pequeñas con pocas personas, hasta grandes donde existen varios equipos de desarrollo. [7] Dos dimensiones del proceso de desarrollo El eje horizontal representa el tiempo, mostrando la estructura dinámica del proceso, y es expresado en términos de ciclos, iteraciones, fases e hitos. [Ob. Citada] El eje vertical representa el aspecto estático del proceso, es expresado en términos de actividades, trabajadores, flujo de trabajos y artefactos. [Ob. Citada] 12

22 Figura 3. RUP en dos dimensiones. [7] Estructura Dinámica de RUP "Es la organización del proceso a lo largo del tiempo. La vida de un software está compuesta por varios ciclos, cada ciclo representa una nueva generación del producto. [Ob. Citada]. RUP divide cada ciclo en cuarto fases: Fase de Inicio Durante la fase de inicio, se establecen los casos del negocio para el sistema y se define el alcance del proyecto. Se identifican los actores que interactuarán con el sistema, esto implica definir los casos de uso y describir a los más significantes. También se incluyen los factores de éxito, riesgos potenciales y la estimación de recursos necesarios para el proyecto. [Ob. Citada] Fase de Elaboración El propósito de la fase de elaboración es analizar el dominio del problema, establecer una arquitectura base, crear el plan de desarrollo, y eliminar los riesgos más grandes del proyecto. Para alcanzar los objetivos es necesario tener una visión amplia y poco profunda del proyecto. Las dediciones de la arquitectura deben ser hechas con el entendimiento total del sistema: su alcance, su funcionalidad principal y los requerimientos no funcionales. Durante las primeras iteraciones de esta fase se obtiene un prototipo ejecutable de la arquitectura. La idea 13

23 es que el esfuerzo se concentre en los casos de uso críticos, que usualmente representan los mayores riesgos técnicos. [Ob. Citada] Construcción Durante esta fase, todos los componentes y funcionalidad restante de la aplicación son desarrollados e integrados dentro del producto, al mismo tiempo de que son cuidadosamente probados. La fase de construcción representa el proceso de manufactura del producto y hace énfasis en el manejo de recursos, optimizar costos, cumplir con el plan de trabajo y asegurar la calidad. [Ob. Citada] Transición Tiene como propósito la transición del producto a los usuarios finales. Incluye actividades como: pruebas de versiones beta, operación paralela con sistema el cual se reemplaza, adaptación de bases de datos, entrenamiento de usuarios, pasar el producto a los equipos de ventas. También se hace un esfuerzo en ajustar, corregir errores, y mejorar la usabilidad y el desempeño del software. [Ob. Citada] Cada una de estas fases concluyen con un hito bien definido, en cada hito se toman decisiones críticas, por ende se deben cumplir los objetivos claves. Cada una tiene un propósito distinto y se pueden realizar una o más iteraciones en cada fase, según el plan de desarrollo. [Ob. Citada] Estructura Estática de RUP "Un proceso representa el quién esta haciendo qué, cómo y cuándo. En RUP se representa utilizando cuarto elementos en el modelo. Los Trabajadores ( Workers ) representan el quién; los Artefactos el qué; las Actividades el cómo; y el Flujo de Trabajo ( Workflow ) el cuándo. [Ob. Citada] 14

24 4.7 Patrones de Diseño Los patrones de diseño son descripciones de objetos y clases que se comunican entre sí y que son adaptados para resolver un problema de diseño en un contexto determinado. [8] En general un patrón tiene cuarto partes esenciales: El nombre del patrón es un término que se utiliza para describir un problema de diseño, y su solución en una palabra o dos. El problema describe cuando aplicar el patrón, explica el problema y el contexto para el cual es utilizado. La solución describe los elementos que conforman el diseño, sus relaciones, responsabilidades y colaboraciones. La solución no describe una solución concreta en particular, ya que un patrón es una plantilla que puede ser aplicado en distintas soluciones. Las consecuencias son los resultados y costos de haber aplicado el patrón. [Ob. Citada] Clasificación de Patrones Los patrones de diseño se clasifican de dos formas: la primera, por su propósito y la segunda, por su alcance. Los patrones pueden tener propósitos de creación, estructural o de comportamiento. Los patrones de creación se enfocan de la construcción de los objetos, los estructurales manejan la composición de clases u objetos, y los patrones de comportamiento se caracterizan por la forma en que las clases u objetos interactúan y distribuyen responsabilidades. El otro criterio de alcance especifica si el patrón se aplica a una clase o a objetos. [Ob. Citada] Patrones de Creación Básicamente abstraen el proceso de instanciación. Ayudan a hacer un sistema independientemente de cómo son creados, compuestos y representados sus objetos. Un patrón de creación para una clase utiliza la herencia para variar el tipo de clase concreta que ha sido creada; en cambio para los objetos, el patrón delegará la instanciación a otro objeto. [Ob. Citada] Los patrones de creación son importantes en sistemas que dependen cada vez más en la composición de objetos que en la herencia de clases. Mientras esto ocurra, el énfasis se aleja 15

25 de codificar un conjunto fijo de comportamientos, hacia un menor conjunto de comportamientos fundamentales que pueden ser mezclados entre si para crear unos más complejos. Por ende crear objetos con comportamientos particulares requiere mas que simplemente instanciar una clase. [Ob. Citada] Existen dos temas importantes en estos patrones, primero todos encapsulan conocimiento de las clases concretas que el sistema utiliza. Segundo esconden como las instancias son creadas y colocadas juntas. Todo lo que el sistema sabe desde más arriba son las interfaces de los objetos definidas por clases abstractas. En consecuencia, los patrones de creación dan una gran flexibilidad en qué se construye, quién lo construye, cómo lo construye, y cuando. Permiten configurar un sistema con objetos que varían en estructura y funcionalidad. La configuración puede ser estática (a tiempo de compilación) o dinámica (en tiempo de ejecución). [Ob. Citada] Algunos de los patrones de creación son: Prototipo, Fábrica Abstracta, Builder o Constructor, Singleton y Método de Fabricación Patrones Estructurales Los patrones estructurales se enfocan en cómo se componen clases y objetos para formar estructuras más grandes. En el caso de clases utilizan herencia para componer interfaces o implementaciones. Por ejemplo, en el caso de la herencia múltiple que mezcla dos o más clases, genera como resultado una clase que combina las propiedades de las clases padre. Este patrón es útil para hacer que dos librerías independientes funcionen juntas. [Ob. Citada] En vez de componer interfaces o implementaciones, en el caso de patrones estructurales de objetos se describen formas para componer objetos que realizan una nueva funcionalidad. La flexibilidad agregada de componer objetos, viene de la habilidad de cambiar la composición en tiempo de ejecución, lo cual es imposible con una composición estática. [Ob. Citada] Dentro de los patrones estructurales se tiene: Decorador, Adaptador, Fachada, Puente, Proxy y Composite 16

26 Patrones de Comportamiento Los patrones de comportamiento tienen que ver con algoritmos y la asignación de responsabilidades entre objetos. Adicionalmente estos patrones no sólo describen objetos y clases, sino que también describen patrones de comunicación entre ellos. Se caracterizan por un complejo control de flujo que resulta difícil de entender en tiempo de ejecución. La idea es sólo concentrarse en la forma en que los objetos están interconectados. [Ob. Citada] En el caso de las clases los patrones de comportamiento utilizan herencia para distribuir el comportamiento entre ellas. Un ejemplo es el patrón Método Plantilla, que es una definición abstracta de un algoritmo, lo define paso a paso. En el caso de patrones de comportamiento para objetos utilizan composición en vez de herencia. Algunos describen como un grupo de objetos cooperan para realizar una tarea que ningún objeto puede llevar a cabo solo. [Ob. Citada] Los patrones de comportamiento más comunes son: Interpretador, Método Plantilla, Cadena de Responsabilidad, Comando, Iterador, Mediador, Memento, Flyweight ( Peso mosca ), Observador, Estado, Estrategia y Visitante. 17

27 5 Fase de Inicio: Este capítulo presenta todas las actividades realizadas durante la fase de inicio de la metodología RUP. También se señalan algunos artefactos resultantes de las actividades. 5.1 Visión del Proyecto La tarea de implementar un concurso SMS implica varios procesos dentro de la empresa. Generalmente el cliente decide cuáles especificaciones tendrá su concurso, luego pasa a los analistas de producto quienes revisan los requerimientos, por último se utilizan analistas de sistemas que desarrollan el programa del concurso, se prueba y luego se pone en producción. Cualquier cambio que se solicite tiene que volver a pasar por gran parte de este proceso. Dada la complejidad del proceso y los retrasos en el tiempo de entrega hacia los clientes, se ideó una plataforma interactiva (ActiveSMS) desde donde los clientes pueden realizar cualquier tipo de concurso SMS de manera fácil y rápida, la plataforma tiene la funcionalidad de: Crear, modificar y eliminar concursos SMS (Primera fase sólo Trivias y Comentarios) a través de un portal Web. Manejo de sesiones entre los usuarios y concursos (Flujo de los juegos). Visualizar reportes de actividad y los mejores resultados de los participantes. Administrar usuarios, operadoras y números de acceso (Shortcodes). Realizar sorteos en varias modalidades. El documento visión del proyecto se encuentra en el Apéndice A, para la descripción del de los requerimientos de la empresa ver el Apéndice F Módulo de lógica de concursos y procesamiento de sesiones: Cómo funcionan los concursos? y Qué contenido manejarán los concursos? 18

28 Para poder participar y llevar a cabo un concurso, es necesario enviar un mensaje desde un teléfono celular con la palabra clave indicada a un número determinado y luego el operador telefónico redirecciona el mensaje a los sistemas de Conectium Limited. Cuando el sistema ActiveSMS recibe el mensaje, verifica la palabra clave y si corresponde a un concurso activo, se crea una sesión entre el concurso y el número telefónico desde donde se encuentra participando la persona. A partir de este momento, todos los mensajes recibidos se dirigirán directamente hacia la sesión del concurso, siempre y cuando esté activa. Una vez que llega el mensaje a la sesión del concurso, es procesado y se responde de una forma específica. La idea es que este comportamiento de procesamiento y respuesta pueda ser extendido, modificado o combinado con otros dependiendo de los requerimientos especificados por el cliente. En fin, la principal función del módulo de manejo de los concursos es procesar los mensajes entrantes, verificar el contenido y dar un mensaje de respuesta a solicitud previa. Por otro lado, el módulo de manejo de concursos realiza operaciones de mantenimiento de sesiones, ya que es posible que un participante deje de enviar mensajes y por lo tanto la sesión se mantenga abierta hasta que expire un tiempo previamente preestablecido. Para evitar el acceso de usuarios a concursos que no se encuentran abiertos al público este módulo se encarga de filtrar los teléfonos no permitidos para hacer pruebas del concurso. Otra de las funciones es poder hacer cambios de concursos durante una misma sesión Módulo de Conexión con la red móvil celular. Cómo se envían y reciben los mensajes de texto? Dentro de Conectium Limited existe un sistema ya probado de envío y recepción de mensajería SMS: el IMG (Internet Message Gateway). Este sistema se utiliza actualmente en varios países y maneja una alta cantidad diaria de mensajes SMS, además posee otras funcionalidades interesantes de control de conexiones con los operadores telefónicos. Para que funcione correctamente la plataforma ActiveSMS es necesario poder enviar y recibir mensajes SMS, esto se logra conectándose con la red de telefonía celular. Para aprovechar el sistema existente de envíos y recepción, se necesitará desarrollar un módulo que 19

29 permita establecer una comunicación de mensajes desde ActiveSMS con el IMG y viceversa. Se necesita un mecanismo robusto de comunicación entre los dos sistemas, donde se minimice la cantidad de mensajes que no se envían de vuelta al usuario. Por ejemplo, un usuario envía un mensaje al sistema pero éste no le responde porque no se encuentra disponible en ese instante. Este caso genera muchas molestias al público que participa porque se le cobra el mensaje sin haber recibido respuesta. Debido a este problema se piensa utilizar un servidor de colas de mensajes (Message Queue) que sirva como intermediario para evitar esta situación. Sin embargo el IMG ya posee una interfaz para conectarse con otros sistemas a través de una llamada HTTP. Esta forma de integrarse con el IMG es mucho más sencilla y rápida aunque no tan robusta. De todas maneras se implementará una interfaz adicional en el modulo de conexión conjuntamente con el módulo Web, para proveer la opción de comunicarse con el IMG de esta forma Módulo de Administración Web. Cómo se controla al sistema? Uno de los requisitos indispensables para la plataforma es el módulo de administración vía Web, el cual permitirá administrar todo lo referente a la plataforma de forma rápida y sencilla. Se compone de 3 secciones: Concursos, Administración y Reportes. Gracias a esto el proceso de creación de concursos pasa de ser tarea de un grupo de empleados (Analistas de sistemas y de producto) a tarea de tan sólo un Analista de Producto, o mejor aún se les puede permitir el acceso a los clientes de Conectium Lugar para que generen, modifiquen y vean la actividad de sus concursos desde cualquier lugar vía Web. Un prototipo detallado del módulo de administración Web realizado por la empresa, se puede ver en el apéndice G Módulo de Persistencia de Datos. Cómo se guarda toda la información del sistema? Todos los módulos anteriores exceptuando el de conexión con la red celular, necesitan de un sub-sistema que se encargue de almacenar información; para esto se idea un sistema de 20

30 persistencia que funciona independientemente del manejador de datos, es decir, los datos se pueden almacenar en una base de datos, un archivo XML, etc. 5.2 Actores y principales casos de uso: A continuación se presentan los principales actores y casos de uso del sistema: Actores Nombre Descripción Rol Gerente de la plataforma Usuario Gerente Usuario Monitor Persona interna encargada del funcionamiento y monitoreo de la plataforma ActiveSMS. 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. Usuario Final Persona que juega el concurso a través de su teléfono. 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 también los resultados. Envía y Recibe mensajes hacia el número del concurso Casos de Uso Módulo de Manejo de concursos: 1. Jugar concursos: procesar los mensajes entrantes de los usuarios para poder llevar a cabo distintos tipos de concursos en los que se desea participar. Incluye los casos de uso: iniciar sesión, procesar mensajes y terminar sesión. 2. Cambiar de concurso: se le da la posibilidad a un usuario que se cambie desde un concurso en marcha a otro. 21

31 Módulo de Conexión con la red Celular 1. Enviar/Recibir mensajes con la red móvil celular, se envían y se reciben mensajes hacia el sistema IMG, que luego serán entregados a los distintos SMSC de las operadoras telefónicas y viceversa Módulo Web: 1. Crear/Modificar/Eliminar operadoras, short codes y usuarios del portal Web. Esta sección del módulo Web es totalmente administrativa y es restringida a los usuarios finales. 2. Crear/Modificar/Eliminar/Hacer Sorteos/Visualizar mensajes/ concursos, en esta parte se configuran los concursos, en esta primera versión solo podemos configurar Trivias y Comentarios. Esta información será proporcionada al módulo de manejo de concursos para poder llevar a cabo el concurso previamente configurado. 3. Ver resumen/ver detallado de todos los mensajes. Se presenta de una forma organizada el movimiento de los mensajes procesados por la plataforma Módulo de Persistencia de Datos 1. Buscar/Insertar/Actualizar/Eliminar cualquier entidad interna del sistema que necesite ser almacenada en alguna base de datos. El documento de casos de uso del sistema ActiveSMS se encuentra en el Apéndice B. 5.3 Glosario del Sistema Todos los términos y abreviaturas utilizadas para describir al sistema ActiveSMS se encuentran definidos en el documento de glosario del sistema. Debido a la gran cantidad de conceptos y su extensión, el glosario es presentado en el Apéndice C. 22

32 5.4 Estudio Inicial de Riesgos Durante la primera etapa del proyecto, se realizó un breve estudio de los riesgos más importantes que pudiesen afectar a la calidad final del producto a desarrollar. Los más importantes fueron los siguientes: Utilización de nuevas tecnologías, poca experiencia del desarrollador con la tecnología de colas. Aprendizaje de la arquitectura del software de transmisión y recepción de mensajes de texto (IMG) para realizar la integración entre los sistemas. Gran cantidad de requerimientos solicitados por la empresa. Complejidad de la aplicación, ya que se necesita que posea mucha flexibilidad para desarrollos futuros. Para una descripción más detallada, que incluye la magnitud, los impactos, los indicadores y la estrategia de mitigación ver el Apéndice D. 5.5 Plan de Desarrollo del Software Figura 4 Plan de desarrollo del software. Elaboración propia. El plan detallado del desarrollo de software ActiveSMS se encuentra en el Apéndice E 5.6 Hitos Alcanzados Lista de requerimientos muy claros y específicos. Arquitectura preliminar. 23

33 6 Fase de Elaboración Durante esta fase se concibe el dominio del problema, se analiza y se identifican los casos de uso más riesgosos del proyecto. El objetivo fundamental de esta fase es minimizar estos riesgos que ponen en juego el éxito del desarrollo. Durante esta fase se realizaron las actividades propuestas por la metodología RUP, de las cuales se generaron los siguientes artefactos: 6.1 Vistas de la arquitectura del Software Para representar la arquitectura del software se han escogido varias vistas. Cada una involucra un conjunto de requerimientos funcionales y no funcionales, específicos para cada uno de los stakeholders: usuarios, diseñadores, gerentes, ingenieros, etc. [9] Estas vistas capturan las decisiones más significativas del diseño, mostrando como la arquitectura se descompone en componentes, y como éstos están interrelacionados entre sí. Las decisiones tomadas de diseño deben estar estrechamente relacionadas con los requerimientos, funcionales y no funcionales del software, sin embargo estas decisiones también afectan a los requerimientos y en diseños futuros. [Ob. Citada] Se utiliza el Lenguaje de Modelado Universal (UML), como notación de todas las vistas de la arquitectura. En la metodología RUP se llaman las 4+1 vistas que son descritas a continuación a excepción de la vista de proceso: 6.2 Las Vistas de la arquitectura Vista de Casos de Uso La vista de casos de uso recopila la mayoría de los requerimientos funcionales e ilustran los distintos escenarios en los cuales pueden ser ejecutados los casos de uso. Los casos de uso son descripciones de la interacción entre un usuario y el sistema. Los casos de uso sirven como contrato entre el cliente y el desarrollador y son una parte esencial para las siguientes actividades durante el proceso de desarrollo. En esta vista se incluyen los diagramas 24

34 de caso de uso y el documento de casos de uso extendido. [Ob. Citada] Diagrama de Casos de uso El diagrama de casos de uso del sistema ActiveSMS sirve para ilustrar los actores, casos de uso y las relaciones entre ellos. Se pueden organizar por módulo del sistema, pero en este caso se representan todos en un sólo diagrama. El diagrama de casos de uso se encuentra en el apéndice B Vista Lógica "Para entender la estructura y la organización del diseño del sistema utilizamos la vista lógica, ya que ilustra los subsistemas o módulos, paquetes y clases que componen a toda la arquitectura del sistema. También representa el dominio y la solución del problema. Esta vista se refina a lo largo de las iteraciones del proceso de desarrollo. [Ob. Citada] Los artefactos que se utilizaron para describir esta vista son: el modelo conceptual y el diagrama de clases. También señalamos los patrones que utilizamos en el diseño de los distintos módulos del sistema, que explican detalladamente el porqué y cuál es la ventaja de utilizar este tipo de patrones dentro del sistema ActiveSMS Modelo Conceptual o del Dominio Aquí se describen todos los aspectos sobre el problema a resolver, este modelo no contiene ningún tipo de solución solo se encarga de modelar y relacionar los conceptos de la realidad que rodean al problema que se quiere resolver. Ver apéndice H Diagramas de Clases El Diagrama de Clases es el diagrama principal de diseño y análisis para un sistema. En él, la estructura de clases del sistema se especifica, con relaciones entre clases y estructuras de herencia. Durante el análisis del sistema, el diagrama se desarrolla buscando una solución ideal. Durante el diseño, se usa el mismo diagrama, y se modifica para satisfacer los detalles de las implementaciones. La definición de clase incluye definiciones para atributos y operaciones. [Ob. Citada] 25

35 En la fase de elaboración se generaron varios diagramas de clases con los elementos básicos de la arquitectura con el fin de diseñar e implementar los componentes con mayor riesgo. Durante las próximas fases se agregaron y modificaron elementos a los diagramas. Los diagramas de clases por módulos se encuentran en los Apéndices I, J, K, L Diagramas de Secuencia El Diagrama de Secuencia es uno de los diagramas más efectivos para modelar interacción entre objetos en un sistema. Un diagrama de secuencia se modela para cada caso de uso. Contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes pasados entre los objetos. [Ob. Citada] Los diagramas de secuencia detallados, para los casos de uso principales se pueden encontrar en los Apéndices M, N Vista de Implementación En esta vista se describirá la organización estática del proyecto, es decir, cómo están organizados los módulos, subsistemas o paquetes del sistema. Esta vista tiene como objetivo guiar el desarrollo del software, distribución, agrupamiento y visibilidad. Además esta vista sirve para la asignación de requerimientos al equipo de desarrollo, para la planificación de costos y tiempos, para el monitoreo y justificar la reusabilidad, portabilidad y seguridad del software. [Ob. Citada] El sistema ActiveSMS consta de cuatro módulos, de esta forma se puede representar el sistema completo de la siguiente forma: El módulo de lógica de concursos: se implementarán las clases que manejan todo el proceso de sesiones con los usuarios; de la misma forma, clases para manejar los concursos, sus comportamientos y filtros de números telefónicos. Dentro de este módulo existen clases implementadas para los concursos tipo trivias y comentarios. Ver apéndice I. El módulo de conexión con la red celular: consta de la implementación de dos módulos independientes, uno lo representa el software IMG-queue, y el otro el sub-sistema de 26