Tesis Mensajeria Masiva

BOLIVAR
UNIVERSIDAD SIMON
DECANATO DE ESTUDIOS PROFESIONALES
DE INGENIERIA DE LA COMPUTACION
COORDINACION
SISTEMA DE ENVIO DE MENSAJERIA MASIVA MULTIPLATAFORMA
Por:
Andres H. Mari
no O.
Realizado con la asesora de:

Tutor Academico: Mara Angelica Perez de Ovalles
Tutor Industrial: Grisel D Alessio
PASANTIA LARGA
Presentado ante la Ilustre Universidad Simon Bolvar
como requisito parcial para optar al ttulo de
Ingeniero en Computacion
Sartenejas, Enero de 2012
Resumen
El presente trabajo describe el desarrollo(analisis, dise

no, implementacion y pruebas unitarias
y de integracion) del Sistema de Envo de Mensajera Multiplataforma, u
til para enviar informacion a listas de distribucion, El sistema fue desarrollado en plataforma web, permitendole
a los usuarios poder registrarse, agregar suscriptores, gestionar listas sobre los suscriptores,
enviar alertas a estas listas, y recibir reportes.
Dicho sistema fue de beneficio para la empresa Ogangi, ya que permite facilitar sus servicios a sus clientes simplificando y unificando el proceso de Envo de SMS y Correos.
Actualmente, es necesario realizar pruebas de carga en el sistema para observar su rendimiento.
El sistema fue implementado en los lenguajes JSP, JavaScript, Java, ademas, utilizo Mobile API, un sistema propietario de Ogangi, el cual se comunica mediante Servicios Web y
Servlets con la base de datos y los servidores para enviar la mensajera. Tambien posee niveles
de encriptamiento y seguridad, tales como protocolo HTTPS(Hypertext Transfer Protocol
Secure ) y se encripto cierta informacion con el algoritmo Sha-1, su desarrollo se llevo a cabo
bajo la metodolga RUP, en cuatro iteraciones.
iv
DEDICATORIA
A mi Madre.
Agradecimientos
A todas aquellas personas que de una u otra manera me han ayudado a lo largo de la
carrera, en especial a mi mama Luz Amparo Osorio y a Orlando Gonzales.
Indice general
Indice general
VII
Indice de cuadros
IX
Indice de figuras
Lista de Abreviaturas
XII
Introducci
on
1. La empresa: Ogangi de Venezuela

1.1. Rese
na Historica . . . . . . . . .
1.2. Vision . . . . . . . . . . . . . . .
1.3. Mision . . . . . . . . . . . . . . .
1.4. Estructura de la empresa . . . . .
.
.
.
.
3
3
4
4
4
.
.
.
.
7
7
8
10
10
.
.
.
.
.
11
11
11
13
14
15
2. Marco Te
orico
2.1. Arquitectura de capas
2.2. Servicio Web REST . .
2.3. JQuery . . . . . . . . .
2.4. DataTables . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3. Marco Metodol
ogico
3.1. Rational Unified Process . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1. Estructura de RUP . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2. Fases de RUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.3. Fases y artefactos de RUP contemplados en el proyecto de pasanta
3.1.3.1. Artefactos elaborados . . . . . . . . . . . . . . . . . . . .
4. Desarrollo
4.1. Primera Iteracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1. Extraccion de requerimientos . . . . . . . . . . . . . . . . . . . .
4.1.1.1. Estudio del Sistema MMC . . . . . . . . . . . . . . . . .
4.1.1.2. Estudio del Sistema siMple . . . . . . . . . . . . . . . .
4.1.2. Establecimiento de alcance y lmites del proyecto . . . . . . . . .
4.1.3. Eleccion de Herramientas a usar . . . . . . . . . . . . . . . . . . .
4.1.4. Elaboracion de los documentos de Vision del sistema, ERS y DAS
4.2. Segunda Iteracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1. Caso de Uso Registrar Usuario . . . . . . . . . . . . . . . . . . . .
4.3. Tercera Iteracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1. CU Modificar Listas . . . . . . . . . . . . . . . . . . . . . . . . .
4.4. Cuarta Iteracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.1. Enviar SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
16
16
17
17
18
19
20
21
23
27
30
33
36
39
5. Conclusiones y recomendaciones
45
Bibliografa
47
A. Visi
on Del Sistema
49
B. Documento de Arquitectura
62
C. Especificaciones de Requerimientos del Sistema
80
viii
Indice de cuadros
3.1. Artefactos elaborados durante la pasanta . . . . . . . . . . . . . . . . . . . .
15
4.1. Narrativa CU Registrar Usuario . . . . . . . . . . . . . . . . . . . . . . . . .

4.2. Narrativa CU Modificar Lista . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3. Narrativa CU Enviar SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
34
43
Indice de figuras
1.1. Organigrama Ogangi Corporation Diciembre 2011. Fuente: [Cor10] . . . . . .
3.1. Disciplinas y fases de RUP. Fuente: [ee11] . . . . . . . . . . . . . . . . . . . .
12
4.1. Caso de Uso Inicial. Fuente:Elaboracion propia . . . . . . . . . . . . .

4.2. Modelo de Dominio Inicial. Fuente:Elaboracion propia . . . . . . . . .
4.3. Vista de implementacion. Fuente:Elaboracion propia . . . . . . . . . .
4.4. Diagrama de componentes. Fuente:Elaboracion propia . . . . . . . . .
4.5. Caso de Uso primera iteracion. Fuente:Elaboracion propia . . . . . .
4.6. WAE primera iteracion. Fuente:Elaboracion propia . . . . . . . . . .
4.7. Caso de Uso segunda iteracion. Fuente:Elaboracion propia . . . . . .
4.8. WAE segunda iteracion. Fuente:Elaboracion propia . . . . . . . . . .
4.9. Interfaz Registrar Usuario. Fuente:Elaboracion propia . . . . . . . .
4.10. Diagrama de Secuencia Registrar Usuario. Fuente:Elaboracion propia
4.11. Caso de Uso tercera iteracion. Fuente:Elaboracion propia . . . . . . .
4.12. WAE tercera iteracion. Fuente:Elaboracion propia . . . . . . . . . . .
4.13. Interfaz Modificar Listas. Fuente:Elaboracion propia . . . . . . . . . .
4.14. Diagrama de Secuencia Modificar Listas. Fuente:Elaboracion propia .
4.15. Caso de Uso cuarta iteracion. Fuente:Elaboracion propia . . . . . . .
4.16. WAE cuarta iteracion, Fuente:Elaboracion propia . . . . . . . . . . .
4.17. Interfaz de Enviar SMS Paso 1. Fuente:Elaboracion propia . . . . . .
4.21. Diagrama de Secuencia Enviar SMS. Fuente:Elaboracion propia . . .
19
20
21
22
22
23
25
26
28
29
31
32
33
35
37
38
40
41
42
42
43
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Lista de Abreviaturas
API
Application Programming Interface (Interfaz de programacion de

aplicaciones)
CSS
Cascading Style Sheets
CU
Caso de Uso
DAS
Documento de Arquitectura de Software
EGO
Enterprise on the GO
ERS
Documento de Especificaci
on de Requerimientos de Software
HTTP
HyperText Transfer Protocol (Protocolo para Transferencia de HiperTexto)
JDE
Java Development Environment (Ambiente de Desarrollo Java)
JDK
Java Development Kit (Equipo de Desarrollo Java)
JSP
JavaServer Pages
MAPI
Mobile API
MMC
Mobile Master Control
REST
Representational State Transfer (Transferencia de Estado Representacional)

xii
1
RUP
Rational Unified Process (Proceso Unificado de Rational)
SDK
Software Development Kit (Kit de Desarrollo de Software)
SMS
Short Message Service (Servicio de Mensajera Corta)
UI
Unit Interface
URI
Uniform Resource Identifier
URL
Uniform Resource Locator (Localizador Uniforme de Recursos)
VS
Documento de Visi
on del Sistema
WAE
Web Application Extension
W3C
World Wide Web Consortium
XML
eXtensible Markup Language (Lenguaje de Marcas Extensible)
Introducci
on
Con la utilizacion de las tecnologas de la informacion en cada vez mas aspectos de

nuestras vidas, se han diversificado las maneras de enviar informacion a las personas, en
formas rapidas y directas, tales como son los SMS o los correos electronicos; estas han ganado
terreno a la hora de informar a los usuarios de productos, facturas, informacion relevante,
como miscelanea, mantener comunicacion, entre otros. De manera rapida y sencilla.
Esto da muchas oportunidades a las compa
nias, empresarios y emprendedores de abrir
una comunicacon directa con sus clientes; tal es el caso de un banco que quiere, notificar
a sus clientes que el corte de sus tarjetas de credito es en una fecha especfica, o enviar
2
informacion pertinente acerca de un evento, entre otros. Existen pocas compa
nias capaces de
ofrecer este tipo de servicios, no unifican el envio de informacion por ambas plataformas(SMS
y Correo Electronico), tampoco tienen un manejo sencillo de las listas de distribucion de los
clientes, y suelen ser engorrosas de manejar, editar, entre otros. sobrecargando el trabajo de
los usuarios.
Actualmente Ogangi de Venezuela, es una empresa que ofrece estos servicios, esta posee
dos sistemas para el envio de Alertas. Ante la necesidad de sus clientes de unificar estos
sistemas se decide crear un nuevo sistema EGO(Por sus siglas en ingles Enterprise on the
GO).
Este proyecto se concibe con la finalidad de crear un sistema Web, que facilite la gestion
de listas de distribucion, as como el envo de alertas a estas, concretamente debera poseer
las siguiente caractersticas:
Gestion se suscriptores
Gestion de listas de distribucion a partir de los suscriptores
Creacion, configuracion y envo de alertas a listas de distribucion por multiples plataformas (SMS, correo electronico).
Las limitaciones que poseen los sistemas actuales son: m

ultiples listas, para poder enviar
las alertas, una lista por cada plataforma( SMS , correo electronico), las listas de distribucion
no son modificables, una vez cargadas en el sistema sus suscriptores no se pueden modificar.
Las ventajas de esta nueva aplicacion son la unificacion de las listas de distribucion,
posibilidad de edicion, tanto de los suscriptores como de las listas, as como posibilidad de
armar las listas de distribucion sobre los suscriptores existentes.
Captulo 1
La empresa: Ogangi de Venezuela
En este captulo se presenta una descripcion del entorno en el cual se desarrollo el proyecto
de pasanta en Ogangi de Venezuela C.A. Comprende la composicion corporativa, una breve
rese
na historica de la empresa, su mision y vision, as como la estructura organizacional, y
la ubicacion del pasante dentro de la misma.
1.1.
Rese
na Hist
orica
En el a
no 2002, un grupo de ejecutivos provenientes de empresas como Bell Labs, 3Com
Corporation y The Walt Disney Company se agruparon para formar Ogangi Corporation
con una vision dirigida hacia la tecnologa movil. La empresa ha desarrollado innovaciones
tecnologicas que integran las plataformas de los diferentes operadores moviles en America,
incrementando de esta forma, los beneficios que ofrecen los equipos celulares en los negocios,
proveedores de contenidos, gobiernos y usuarios finales.
En Miami (EE.UU) se encuentra la sede administrativa y de alta gerencia de la empresa,
en Venezuela se encuentra el area operativa, ubicada en dos estados: Distrito Capital y
Merida. [Cor10].
1.2.
Visi
on
La Vision de Ogangi Corporation es:

Generacion de nuevas oportunidades de ingresos para las empresas proveedoras de contenidos y operadores moviles a traves de la gestion de nuevos contenidos a un enorme
mercado de usuarios moviles de manera rapida y economica.
Proveer soluciones para negocios y gobiernos en la b
usqueda de nuevas vas de comunicacion hacia los receptores, de una forma efectiva y economica, como portales WAP,
mensajera de texto , entre otros.
Proveer opciones de entretenimiento a usuarios finales a traves de concursos, trivias,
portales WAP, entre otros.
Satisfacer necesidades y requerimientos de clientes y usuarios finales. [Cor10]
1.3.
Misi
on
La mision de la empresa se define de la siguiente manera: Brindar soluciones de bajo

costo y efectivas que transformen la red de los operadores y los dispositivos moviles de los
usuarios en una plataforma interactiva de contenido. [Cor10]
1.4.
Estructura de la empresa
Ogangi Corporation esta integrada por distintos departamentos con la finalidad de distribuir de forma eficiente las actividades correspondientes al proceso de negocio de la misma.
Actualmente, se tienen 5 departamentos en Ogangi: Desarrollo de Software, Ventas, Operaciones e Infraestructura Tecnologica, Finanzas y Contenido. Ver figura 1.1
Figura 1.1: Organigrama Ogangi Corporation Diciembre 2011. Fuente: [Cor10]

A continuacion se describe el departamento de Ogangi Corporation en el que se desarrollo la pasanta. [pdDdAdOC10]. El departamento de Desarrollo Los miembros de este
equipo se encargan del desarrollo de software, ademas de solucionar cualquier requerimiento,
de ambito tecnologico, establecido por los clientes y por la empresa.
El desarrollo del proyecto fue bajo la tutela de la Ingeniero Grisel D Alessio, quien
forma parte de dicho departamento como Desarrollador Senior y Project Leader Manager.
La mision principal de este departamento es desarrollar software y aplicaciones a la medida
de los clientes.
El pasante Andres Mari
no cumplio la mision de desarrollar EGO (Enterprise on the
GO), un sistema propietario de Ogangi, que permite el envo de mensajera por m
ultiples
6
plataformas (SMS, Correo electronico) a listas de distribucion.
Una vez descrita la empresa, Vision y Mision de la misma, asi como el departamento en
el que se desarrollo el sistema, se sigue al captulo 2 en el cual se explican las bases teoricas,
y tecnologicas para el desarrollo de la pasanta.
Captulo 2
Marco Te
orico
Este captulo presenta las bases teoricas que fundamentan el desarrollo del proyecto.
Principalmente se hace un enfoque en el tipo de arquitectura usada. Una arquitectura de
capas, los servicios Web REST, tambien tecnologas utilizadas como JQuery.
2.1.
Arquitectura de capas
Seg
un Kappel [KG03] una arquitectura de N capas es aquella que permite organizar una
aplicacion Web en un n
umero arbitrario de capas. Tpicamente se consideran tres capas. La
capa de datos, que re
une todos los aspectos del software que tienen que ver con el manejo
de los datos persistentes, la capa de negocio que re
une todas las tareas, reglas y restricciones
que implementan y apoyan los procesos de negocio. Y finalmente, la capa de presentacion que
prepara el resultado de las peticiones en el formato de salida deseado; esta capa por lo general
re
une todos los aspectos del software que tiene que ver con las interfaces y la interaccion con
los diferentes tipos de usuarios humanos.
8
Seg
un Larman [Cra03] la idea esencial del modelo de capas es organizar la estructura
logica del sistema en distintas capas que tendran distintas responsabilidades pero que estaran
relacionadas de una manera cohesiva.
Algunas de las ventajas de esta arquitectura es que facilita la estandarizacion, permite la
contencion de cambios a una o pocas capas y en algunos casos garantiza la reutilizacion de
las capas conceptualizadas.
En este proyecto se decidio utilizar una arquitectura por capas, por su facilidad de reutilizacion y mantenibilidad, tambien se usaron los servicios Web REST.
2.2.
Servicio Web REST
REST(por sus siglas en ingles: Representational State Transfer). Es un estilo de arquitectura para Web orientada al Software. A traves de este mecanismo se pueden ofrecer servicios
web para utilizar la web como una plataforma de computacion distribuda [RES11].
El termino REST inicialmente se refera a un conjunto de principios de arquitectura. En
la actualidad se usa en el sentido mas amplio para describir cualquier interfaz Web simple que
utiliza XML y HTTP, sin las abstracciones adicionales de los protocolos basados en patrones
de intercambio de mensajes como el protocolo de servicios Web SOAP.
Se pueden dise
nar sistemas de servicios Web de acuerdo con el estilo arquitectural REST
de Roy Fielding y tambien es posible dise
nar interfaces XMLHTTP de acuerdo con el estilo
de llamada a procedimiento remoto pero sin usar SOAP. Estos son los dos usos diferentes del
termino REST.
9
Los sistemas que siguen los principios REST se llaman con frecuencia RESTful. REST
afirma que la Web ha disfrutado de escalabilidad como resultado de una serie de dise
nos
fundamentales clave: [RES11]
Un protocolo cliente/servidor sin estado: cada mensaje HTTP contiene toda la informacion necesaria para comprender la peticion. Como resultado, ni el cliente ni el servidor
necesitan recordar ning
un estado de las comunicaciones entre mensajes. Sin embargo, en
la practica, muchas aplicaciones basadas en HTTP utilizan cookies y otros mecanismos
para mantener el estado de la sesion (algunas de estas practicas, como la reescritura de
URLs, no son permitidas por REST).
Un conjunto de operaciones bien definidas que se aplican a todos los recursos de informacion: HTTP en s define un conjunto peque
no de operaciones, las mas importantes
son POST, GET, PUT y DELETE. Con frecuencia estas operaciones se equiparan a
las operaciones CRUD que se requieren para la persistencia de datos, aunque POST no
encaja exactamente en este esquema.
Una sintaxis universal para identificar los recursos: en un sistema REST, cada recurso es
direccionable u
nicamente a traves de su URI (Por sus siglas en ingles Uniform Resource
Identifier).
El uso de hipermedios, tanto para la informacion de la aplicacion como para las transiciones de estado de la aplicacion: la representacion de este estado en un sistema REST
son tpicamente HTML o XML. Como resultado de esto, es posible navegar de un recurso REST a muchos otros, simplemente siguiendo enlaces sin requerir el uso de registros
u otra infraestructura adicional.
Aparte de utilizar este tipo de servicios Web, tambien se utilizo del lado del cliente,
JQuery una librera de Java-Script.
10
2.3.
JQuery
JQuery es una biblioteca de JavaScript rapida y concisa que simplifica el recorrido de

documentos HTML, el manejo de eventos, animacion, y las interacciones con Ajax para el
desarrollo Web rapido [Jqu11].
Este framework ha sido de gran utilidad para el manejo de funciones con JavaScript ya
que posee una cantidad de libreras con metodos ya implementados que ofrecen facilidad al
momento de ejecutar ciertas acciones por parte del Cliente en un ambiente Web. De este modo
se pudo realizar con rapidez la implementacion de una interfaz dinamica con validaciones
pertinentes.
2.4.
DataTables
DataTables es un plug-in para la libreria de JQuery. Es una herramienta Open-Source,

muy fexible que permite interaccion avanzada con las tablas HTML, su manipulacion, creacion, b
usqueda de informacion entre ellas, exportacion, entre otros, de manera dinamica [Jar11].
Ahora se procede en el siguiente captulo a explicar la metodologa utilizada para desarrollar el sistema.
Captulo 3
Marco Metodol
ogico
El presente captulo tiene como objetivo dar a conocer los aspectos metodologicos en los
que se baso la ejecucion del proyecto de pasanta.
3.1.
Rational Unified Process
Rational Unified Process (RUP) es una metodologa de desarrollo de software propuesta

por la empresa Rational, la cual se define como un proceso iterativo e incremental de desarrollo
de software que no consta de pasos firmemente establecidos sino que por el contrario, se
adapta al contexto y necesidades de cada organizacion [KR03].
3.1.1.
Estructura de RUP
El Proceso Unificado de Rational es un proceso de la Ingeniera del Software. RUP provee

de un enfoque disciplinario para la asignacion de tareas y responsabilidades dentro de una
organizacion de desarrollo y su meta es asegurar la calidad en la produccion de software.
12
Seg
un [KR03], la estructura de RUP esta compuesta por dos dimensiones, una dinamica
y otra estatica. La primera division representa el aspecto dinamico del proceso y esta constituido por fases, iteraciones e hitos. La segunda dimension representa el aspecto estatico del
proceso y esta constituido por actividades, disciplinas, artefactos y roles.
La figura 3.1 muestra la arquitectura global de RUP. El eje horizontal representa la organizacion a lo largo del tiempo, la dimension dinamica, mientras que el eje vertical representa
la organizacion en terminos de contenido, la dimension estatica.
Figura 3.1: Disciplinas y fases de RUP. Fuente: [ee11]
13
3.1.2.
Fases de RUP
RUP se conforma a traves de ciclos los cuales constituyen la vida de un producto. Cada
ciclo esta representado por cuatro fases: Inicio, Elaboracion, Construccion y Transicion las
cuales se detallaran brevemente a continuacion. Cada fase presenta sus propios criterios de
evaluacion los cuales deben ser revisados inmediatamente despues de su finalizacion, si los
criterios no son satisfechos se debe abandonar el desarrollo o realizar una reestructuracion
del proyecto.
La Fase de Inicio es la primera fase del proceso de desarrollo, tiene un conjunto de objetivos
bien definidos y se consideran concluidos con el hito: Objetivo del ciclo de vida. El objetivo
principal de esta fase es entender el alcance y objetivos del proyecto. En esta fase se identifica
la funcionalidad clave del sistema, a traves de la identificacion de los casos de uso mas crticos.
La Fase de Elaboracion provee direccion a los principales riesgos, se dise
na la arquitectura
del sistema de software que satisfaga los requerimientos, y se da refinamiento al plan de
proyecto. Los objetivos especficos de esta fase son:
Obtener un entendimiento mas detallado de los requerimientos.
Dise
nar, implementar, validar y generar una lnea base para la arquitectura.
Mitigar los riesgos esenciales y producir un plan de costos mas preciso.
De la Fase de Construccion el objetivo principal es la construccion del sistema. Su enfoque

principal es el desarrollo de los componentes y caractersticas del sistema que se ha dise
nado.
Esta fase se caracteriza por una gran actividad de codificacion. En proyectos de gran escala
suele tener varias iteraciones que dividen el conjunto de casos de uso con el fin de producir
varios prototipos.
14
Esta fase se considera finalizada cuando se han desarrollado todas las funcionalidades y se
produce un primer realease del software. Su conclusion esta marcada por el hito de Capacidad
Inicial de Operaciones.
De la Fase de Transicion el objetivo principal es la transicion del sistema del ambiente de
desarrollo al ambiente de produccion, haciendo que el sistema este disponible para el usuario,
dotandole de charlas de induccion, entrenamientos y manuales de usuario. Ademas se caracteriza por la ejecucion de pruebas beta por parte de los usuarios, lo que permitira validar las
expectativas de los usuarios en relacion con el producto implementado. Si todos los objetivos
son alcanzados, el hito Release de Producto se considera alcanzado y por tanto el ciclo de
desarrollo finaliza.
Finalmente, para el desarrollo de este proyecto se adopto la metodologa RUP, pero no se
realizo ninguna iteracion de Transicion.
3.1.3.
Fases y artefactos de RUP contemplados en el proyecto de

pasanta
En la planificacion del proyecto de pasanta se contemplaron en su totalidad las primeras

tres fases de RUP: Inicio(una Iteracion), Elaboracion(una Iteracion)y Construccion(dos Iteraciones) con cuatro iteraciones. La iteracion de Transicion no se desarrollo, debido a que no
forma parte del objetivo general del proyecto la implantacion y puesta en produccion de la
solucion.
La metodologa RUP contempla la elaboracion de un conjunto de artefactos en cada
una de las fases; estos se pueden adaptar al contexto y necesidades de cada organizacion.
Partiendo de listado de estos artefactos, se acordo el subconjunto de entregables a elaborar
15
durante el proyecto de pasanta, adaptados al contexto del proyecto.
3.1.3.1.
Artefactos elaborados
A continuacion, en la tabla 3.1, se presentan los artefactos que se decidieron elaborar en

cada fase de RUP.
Fase de Inicio
Descripci
on
El documento de Vision permite analizar y definir las necesidades del sistema a alto nivel.
Especificaci
on de Requerimientos del Sistema(ERS) El documento de Requerimientos del Sistema
permite especificar los requerimientos funcionales y no funcionales del sistema.
Fase de Elaboraci
on
Documento
Descripci
on
Documento de Arquitectura del Software(DAS)
El documento de Arquitectura del Software
proporciona una vision general de la arquitectura del sistema, a traves de diferentes vistas.
Entre ellas estan vista de datos, vista de casos
de uso, vista de implementacion, vista logica
y vista de despliegue.
Fase de Construcci
on
Documento
Descripci
on
Manual de Usuario
Describe las funcionalidades del sistema de
forma detallada, brindando asistencia a cualquier usuario de la aplicacion.
Documento
Vision del Sistema(VS)
Cuadro 3.1: Artefactos elaborados durante la pasanta
Finalmente despues de describir la metodologa a utilizar, n

umero de iteraciones contempladas y tipo de las mismas, proseguimos con el captulo de Desarrollo en el cual se describe
como fue el desarrollo del proyecto.
Captulo 4
Desarrollo
En este captulo se describen los productos mas importantes generados durante la ejecucion de todas las tareas realizadas para el desarrollo de este proyecto. Ademas, se explican
los problemas encontrados con sus respectivas soluciones y las decisiones de dise
no tomadas
junto con sus razonamientos, el proyecto se desarrollo en cuatro iteraciones, a continuacon
se describe el desarrollo de cada iteracion, junto con los elementos elaborados en ellas.
4.1.
Primera Iteraci
on
Esta iteracion tuvo una duracion de dos semanas, al iniciar el desarrollo del proyecto, en
Ogangi ya exista un sistema que cumpla la funcion de enviar mensajeria de texto a listas
de distribucion y otro a listas de correo electronico. Sin embargo, para poder desarrollar el
nuevo sistema se vio la necesidad de analizar los sistemas existentes para retomar sus puntos
fuertes y eliminar las fallas de dise
no de ambos.
Esta primera iteracion contemplo la investigacion en la que se obtuvo la informacion
necesaria para definir el alcance de las iteraciones del proyecto.
17
Para poder definir de forma adecuada los lineamientos se llevaron a cabo las siguientes
tareas:
Extraccion de requerimientos.
Estudio del Sistema MMC.
Estudio del Sistema siMple.
Establecimiento de alcance y lmites del proyecto.
Eleccion de Herramientas a usar.
Elaboracion del diagrama de Casos de Uso inicial(se coloco en el Documento de Requerimientos del Sistema ERS) y del Modelo de Dominio(se coloco en el Documento
de Arquitectura de Software DAS).
Elaboracion de los documentos de Vision del sistema VS.
A continuacion se presenta el resultado de cada una de las actividades anteriormente

mencionadas:
4.1.1.
Extracci
on de requerimientos
En la presente seccion se describen los sistemas actuales, uno denominado MMC y el otro
demoninado siMple, estos son los sistemas que se utilizan para el envo de SMS y correos
electronicos.
4.1.1.1.
Estudio del Sistema MMC
Ogangi cuenta con un sistema online llamado MMC(por sus siglas en ingles Mobile Master Control) el cual sirve para enviar mensajes de texto y de correo electronico a listas de
18
distribucion. Este
es un sistema que esta sobrecargado, tiene muchas funcionalidades repetidas, puesto que fue un sistema que crecio, desviandose de su vision original. A continuacion
algunas caracterstiscas que posee MMC:
Posee manejo de listas de distribucion a SMS y posee manejo de listas de distribucion
a correos electronicos, mas no integra ambas en una sola lista.
Posee facil configuracion de alertas, para enviar a las listas de distribucion
Esta implementado con un FrameWork llamado ECHO, el cual produce un codigo poco
reutilizable.
No posee manejo asincronico lo cual hace que se recargue la informacion cada vez que
se navega por alg
un elemento del sistema.
4.1.1.2.
Estudio del Sistema siMple
Ogangi cuenta, ademas con un sistema Web llamado siMple, el cual ofrece un servicio que
permite a los usuarios intercambiar informacion va mensajes de texto Premium, envo masivo
de mensajes de texto, programar informacion, entre otras. A continuacion se presentan las
caractersticas principales que conforman el sistema siMple:
Es un sistema bastante dinamico con caractersticas desarrolladas en JQuery.
El sistema no posee un manejo intuitivo de las listas de distribucion.
El sistema posee un modulo de envo de alertas poco sencillo.
El sistema cuenta con un manejo de sesiones por usuario el cual permite a este administrar de manera efciente y comoda las transacciones que desee mediante las funcionalidades ofrecidas, con solo ingresar su correo y su contrase
na.
19
4.1.2.
Establecimiento de alcance y lmites del proyecto
En un principio se penso, abarcar todas las funcionalidades que posee MMC, Alertas,
Campa
nas, manejos de listas de distribucion, sin embargo por razones de tiempo, se tomo la
decision de que solo se abarcara los componentes de la gestion de usuarios, gestion de suscriptores, manejo de sesion, gestion de listas de distribucion, manejo de alertas y reportes.
No se contemplo el manejo de la gestion de campa
nas.
Se decidio que el sistema solo tendra dos tipos de usuario: Administrador, quien posee
control total del sistema, y Usuario, quien puede usar todos los modulos del sistema exceptuando el de usuarios. Se realizo el diagrama de casos de uso inicial, se muestra en la figura
4.1
Figura 4.1: Caso de Uso Inicial. Fuente:Elaboracion propia
Tamben se elaboro el Modelo de Dominio inicial. Ver figura 4.2
20
Figura 4.2: Modelo de Dominio Inicial. Fuente:Elaboracion propia
4.1.3.
Elecci
on de Herramientas a usar
Considerando el conjunto de requerimientos propuestos y conociendo los lenguajes mediante los cuales se realizara el sistema, se procedo a elegir las herramientas a utilizar para
un desarrollo rapido y efciente.
Como servidor Web se selecciono JBOSS ya que posee soporte de servlets, webServices y
JSPs ademas de contar con alta documentacion.
Como entorno de desarrollo de programacion se selecciono Eclipse ya que posee soporte
tanto para Java como para JSP, ademas ofrece un plugin especial para el desarrollo Web
dinamico integrado con JBOSS (JBOSS AS A TOOL) y control de versiones (CVS) que
permiten colocar el sistema en un repositorio que puede ser compartido por otros miembros
de la compa
na para la supervision y colocacion en servidores de prueba, ademas de las
herramientas para probar los servicios Web.
21
4.1.4.
Elaboraci
on de los documentos de Visi
on del sistema, ERS
y DAS
En esta primera iteracion se elaboraron las primeras versiones de los documentos de VS,
ERS y DAS. definiendo los esquemas que se siguieron para el desarrollo del sistema.
Se decidio que se utilizara una arquitectura por capas, la cual permite facil mantenimiento
y reutilizacion, estas capas se definieron de la siguiente manera:
JSP: Es la que contiene el codigo en HTML, CSS y todo lo necesario para la capa de
presentacion del sistema
JS: Esta es la capa que contiene los archivos JQuery(JavaScript), en esta capa se decidio realizar muchos de los chequeos de tipos y verificaciones de los campos, al igual
que la presentacion y carga de las tablas utilizadas para mostrar la informacion.
JSPLogic: Esta capa es la que se encarga de la logica del sistema, tambien realiza las
conexiones con Mobile API(MAPI), entre otras funciones.
Se procedio a elaborar el diagrama de la vista de implementacion, ver figura 4.3
Figura 4.3: Vista de implementacion. Fuente:Elaboracion propia
22
Asi como se realizo el diagrama de componentes, ver figura 4.4, para mas informacion
acerca de los componentes ver apendice B
Figura 4.4: Diagrama de componentes. Fuente:Elaboracion propia
Con el alcance mas preciso, se procedio con un refinamiento de los diagramas de Casos
de uso y modelo de dominio el cual evoluciono a un Diagrama de Dise
no con notacion WAE,
ambos diagramas quedaron de la siguiente manera, ver figura 4.5 y 4.6, para mas informacion
ver apendice A y apendice B.
Figura 4.5: Caso de Uso primera iteracion. Fuente:Elaboracion propia
23
Figura 4.6: WAE primera iteracion. Fuente:Elaboracion propia
4.2.
Segunda Iteraci
on
Esta iteracion tuvo una duracion de cuatro semanas. Se procedio con el refinamiento de
los documentos, as como el inicio de la implementacion del sistema. En el diagrama de los
casos de uso, as como en el diagrama de WAE se agrego todo lo relacionado con la Gestion
de suscriptores, en el documento ERS se detallaron todos los requerimientos para estos casos
de Uso; en el DAS se documentaron todos los diagramas de secuencia correspondientes a los
casos de uso realizados. Se implemento todo lo referente a la Gestion de la sesion, Gestion
de usuarios. y Gestion de suscriptores, se implementaron los siguientes casos de uso: Iniciar
24
Sesion, Ver Perfil, Modificar Perfil, Cerrar Sesion, Registrar Usuario, Seleccionar idioma, Listar Usuarios, Eliminar Usuarios, Crear Suscriptor, Cargar Suscriptor, Modificar Suscriptor,
Eliminar Suscriptor.
Se implementaron los siguientes archivos, en la capa JSP: index.jsp, main.jsp,profile.jsp,
suscriptor.jsp y user.jsp. Estos

archivos contienen el HTML y CSS del sistema. En la capa JS:
index.js, profile.js, login.js, registration.js, suscriptor.js, user.js, logout.js. Estos

archivos contienen las mayoria de las verificaciones de los formularios y de los datos, asi como la carga en
tablas de la informacion de los suscriptores, tambien se encarga del pasaje de parametros a la
capa logica de manera asincronica y en la capa de JSP logico: loginLogic.jsp, logoutLogic.jsp,
registrationLogic.jsp, profileEditLogic.jsp, profileReviewLogic.jsp, userLoadLogic.jsp, userDeleteLogic.jsp, suscriptorLoadLogic.jsp, suscriptorAddLogic.jsp, suscriptorDeleteLogic.jsp,
suscriptorEditLogic.jsp. Estos
archivos se encargan de recibir los parametros enviados por el
usuario, hacer las llamadas a MobileAPI (MAPI) el sistema que se encarga del envio de la
informacion, asi como el manejo de a Base de datos, y tambien de interpretar la respuesta
de MAPI. Tambien se implementaron las clases XML y Sha-1, una se encarga de leer los archivos XML que devuelve MAPI, y la otra clase se encarga del encriptamiento del password
del usuario.
A continuacion en las figuras 4.7 y 4.8 se presenta el diagrama WAE y el Diagrama de
casos de uso de la segunda iteracion:
25
Figura 4.7: Caso de Uso segunda iteracion. Fuente:Elaboracion propia
Figura 4.8: WAE segunda iteracion. Fuente:Elaboracion propia
26
27
A manera de ejemplo, se describe la implementacion del CU Registrar Usuario, para
mayor detalle de los casos de uso realizos ver apendice B y apendice C.
4.2.1.
Caso de Uso Registrar Usuario
En el caso de uso Registrar Usuario, el cual implica que en el sistema se pueden registrar
los usuarios, se determino que requera los siguientes campos:
Correo: Es un campo obligatorio, es el correo electronico del usuario, es del tipo alfanumerico.
Contrase
na: Es un campo obligatorio, es la contrase
na del usuario, es del tipo alfanumerico, con longitud mnima de 6, y maxima de 30.
Nombre: Es un campo obligatorio, es el nombre del usuario, es del tipo alfanumerico,
con longitud maxima de 100.
Codigo Zip: Es un campo obligatorio, es el codigo Zip del usuario, es del tipo numerico,
de longitud maxima de 10.
Categora del Negocio: Es un campo obligatorio, es la categora del tipo de negocio del
usuario, los valores posibles son: Arte y Entretenimiento, Automotriz, Servicios Empresariales y Profesionales, Accesorios y Ropa, Comunidad y Gobierno, Computacion y
Electronica, Construccion y Contratistas, Educacion, Alimentos y Restaurantes, Salud
y Medicina, Hogar y Jardinera, Industria y Agricultura, Legal y Financiero, Medios y
Comunicaciones, Cuidado Personal y Servicios, Bienes Races, Compras, Recreacion y
Deportes, Transporte y Turismo.
Sitio Web: Es un es obligatorio, es la pagina Web del usuario, es del tipo caracter, no
tiene longitud maxima.
28
Direccion: No es campo obligatorio, es la direccion del usuario, es del tipo caracter y
no tiene longitud maxima.
Contacto Principal: Es un campo obligatorio, es el contacto principal del usuario, es
del tipo caracter y no tiene longitud maxima.
Contacto Secundario: No es un campo obligatorio, es el contacto secundario del usuario,
es del tipo caracter y no tiene longitud maxima.
Descripcion del negocio: No es un campo obligatorio, es la descripcion del negocio del
cliente, es del tipo caracter y no posee longitud maxima.
Como reglas de negocio se requirio que la Constrase

na tiene que codificarse seg
un el
algoritmo SHA-1. La figura 4.9 muestra la interfaz de RegistrarUsuario.
Figura 4.9: Interfaz Registrar Usuario. Fuente:Elaboracion propia
Seguido de esto se procedio con las especificaciones del caso de uso (CU), la narrativa y
la realizacion del diagrama de secuencia en el cual se pueden ver como se van conectando
29
los archivos y las solicitudes que se le hacen al sistema y las respuestas que se obtienen. Ver
tabla 4.1 y figura 4.10.
FLUJO BASICO
ACTOR
SISTEMA
1. Se ingresa en la p
agina de inicio del sistema 2. Se muestra un formulario con los datos ney le da click al bot
on de registrarse
cesarios para registrarse, indicando cuales son
obligatorios.
3. Se ingresan todos los datos solicitados y pre- 4. Se verifica que los datos ingresados son cosiona el bot
on de Enviar.
rrectos. 5. Se registra el usuario en la base de
datos. 6. se muestra una alerta informando que
la operacion es exitosa.
7. Se le da al bot
on de OK.
8. Se dirige a CU-2.
FLUJOS ALTERNOS
ACTOR
SISTEMA
4. Se verifica que los datos ingresados no son
correctos. 4.1. Se muestra un mensaje en la
pantalla que informa el error en los datos ingresados. 4.2 Se regresa al punto 3
Cuadro 4.1: Narrativa CU Registrar Usuario
Figura 4.10: Diagrama de Secuencia Registrar Usuario. Fuente:Elaboracion propia
30
Para la implementacion se utilizo la librera de Unit Interface (UI) de JQuery, la cual
contiene los dialogos que se pueden colocar como ventanas emergentes sin necesidad de tener
estas, en el formulario todos los chequeos de tipo, chequeo si es vacio, entre otros. Son
realizadas con JQuery, el cual permite que estas verificaciones se hagan a nivel del cliente y
no del servidor, optimizando el sistema. La comunicacion con la capa logica se realiza tambien
con JQuery mediante llamadas asincronicas lo cual evita la constante recarga de la pagina en
cada operacion, de la capa logica, que es la que se encarga de conectarse con MAPI, recibir
la respuesta e interpretartar usando la clase XML. Una vez se completo el proceso de la
implementacion se hicieron pruebas puntuales, con respecto a la funcionalidad e integracion.
4.3.
Tercera Iteraci
on
En esta iteracion se procedio con el refinamiento de los documentos, y se continuo con

la implementacion del sistema. En el diagrama de los casos de uso, as como en el diagrama
de WAE se agrego todo lo relacionado con la Gestion de Listas, en el documento ERS se
describen todos los requerimientos para este caso de uso, en el DAS se documentaron todos los
diagramas de secuencias correspondientes a los casos de uso realizados. Se implemento todo
lo referente a la Gestion de la listas, as como se implementaron los siguientes casos de uso:
Crear Lista, Cargar Listas, Modificar Listas, Eliminar Listas.
Se implementaron los siguientes archivos, en la capa JSP: list.jsp. Este

se encarga del
contenido HTML y CSS de las listas. En la capa JS: list.js. Este

se encarga de manejar los
chequeos de tipo, asi como la carga de la tabla dinamica, entre otras cosas. Y en la capa
de JSP logico: listAddLogic.jsp, listLoadLogic.jsp, listModifyLoadLogic.jsp, listModifySave
Logic.jsp, listDeleteLogic.jsp. Estos
se encargan de hacer las llamadas correspondientes a
MAPI, as como interpretar su respuesta. Al igual que se tuvo que actualizar la clase XML
31
que se encarga de la lectura de los archivo XML que devuelve MAPI.
A continuacion se presenta el diagrama WAE y el Diagrama de casos de uso de la tercera
iteracion, Ver figura 4.11 y 4.12
Figura 4.11: Caso de Uso tercera iteracion. Fuente:Elaboracion propia
Figura 4.12: WAE tercera iteracion. Fuente:Elaboracion propia
32
33
Ahora se va a describir el proceso de desarrollo de un caso de uso implementado en esta
iteracion. Se selecciono Modificar Listas. Para mas informacion acerca de los casos de uso
desarrollados ver apendice B y apendice C.
4.3.1.
CU Modificar Listas
En el caso de uso Modificar Listas, el cual implica que un usuario puede modificar las listas
de distribucion que posea incluyendo los suscriptores que pertenezcan a esta, se determino que
requeriria el siguiente campo:
Nombre: Es in campo obligatorio, este representa el nombre de la lista y es del tipo
alfanumerico.
Su interfaz se muestra en la figura 4.13
Figura 4.13: Interfaz Modificar Listas. Fuente:Elaboracion propia
34
Tambien se especifico que, el pasar suscriptores de una lista a otra, se podra hacer arrastrando y soltando los suscriptores de una a la otra. Seguido de esto se procedio con las
especificaciones del CU, y la realizacion del diagrama de secuencia en el cual se pueden ver
como van conectando los archivos y las solicitudes que se le hacen al sistema y las respuestas
que se obtienen.
la figura 4.14 muestra su diagrama de secuencia y la tabla 4.2 muestra la narrativa
FLUJO BASICO
ACTOR
SISTEMA
1. Se le da click sobre el nombre de la lista a 2. Se despliega una pantalla con el nombre de
modificar.
la lista (sujeto a modificaciones), una lista de
de los suscriptores pertenecientes y otra lista
de suscriptores no pertenecientes a dicha lista.
3. Se modifica el nombre si se quiere, al igual 5. Se procesan los datos y El sistema proceque se puede arrastrar los suscriptores de la sa los datos ingresados y salva en la BD 6. Se
lista de no pertenecientes hacia la lista de per- muestra una alerta con indicando que la opeteneciente, y viceversa 4. se le da al boton de racion fue exitosa.
salvar.
7. Se presiona el bot
on de OK
8. Se dirige al CU-13
FLUJOS ALTERNOS
ACTOR
SISTEMA
4.1 Se presiona el bot
on de cancelar
4.2 Se redirige al CU-13.
Cuadro 4.2: Narrativa CU Modificar Lista
Figura 4.14: Diagrama de Secuencia Modificar Listas. Fuente:Elaboracion propia
35
36
Al igual que para la iteracion anterior se utilizo utilizo la libreria Unit Interface (UI)
de JQuery, utilizando los dialogos y ventanas emergentes sin necesidad de tener estas, en el
formulario todos los chequeos de tipos, si es vacio. Son realizados con JQuery que permite que
estas verificaciones se hagan a nivel del cliente y no del servidor. Tambien se implemento la
llamada para listar los suscriptores pertenecientes y no pertenecientes a la lista, De esta
manera poder mostrarlos en los detalles en una ventana emergente, el manejo arrastrar
y soltar de las listas se hizo con JQuery , una vez lista las modificaciones a la lista al
darle al boton de .OK. La capa JS se encarga de extraer la informacion de la lista de
suscriptores pertenecientes que a su vez se conecta con la capa logica que se encarga de enviar
la informacion con los parametros necesarios a MAPI, y a su vez interpretar la respuesta de
este. Una vez finalizada la operacion se encarga de refrescar la tabla que contiene las listas
de distribucion.
4.4.
Cuarta Iteraci
on
En esta iteracion se procedio con el refinamiento de los documentos, y se continuo con

la implementacion del sistema, en el diagrama de los casos de uso, as como en el diagrama
WAE se agrego todo lo relacionado con el envo de BroadCast y la Gestion de Reportes. En
el documento ERS se describen todos los requerimientos para estos casos de uso. En el DAS
se documentan los diagramas de secuencia correspondientes a los casos de uso realizados. Se
implementaron mas concretamente los siguientes casos de uso: Enviar Correo, Enviar SMS,
Listar Reportes.
Se implementaron los siguientes archivos, en la capa JSP: broadcast.jsp. En la capa JS:
broadcast.js y en la capa de JSP logico: broadcastListGroupLogic.jsp, broadcastSendLogic.jsp, loadShortCodesLogic.jsp y alertSchedulesLoadLogic.jsp. Al igual que se tuvo que
37
actualizar la clase XML que se encarga de la lectura de los archivo XML que devuelve MAPI.
A continuacion se presenta el diagrama WAE y el Diagrama de casos de uso de la cuarta
iteracion, en las figuras 4.15 y 4.16
Figura 4.15: Caso de Uso cuarta iteracion. Fuente:Elaboracion propia
Figura 4.16: WAE cuarta iteracion, Fuente:Elaboracion propia
38
39
Ahora se va a describir el proceso de desarrollo de un caso de uso implementado en
esta iteracion. Se selecciono Enviar SMS. Para mas informacion acerca de los casos de uso
realizados ver apendice B y apendice C
4.4.1.
Enviar SMS
En el caso de uso Enviar SMS, el cual implica que en el sistema se pueden enviar SMS a
las listas de distribucion, se determino que requera los siguientes campos:
Ttulo: Es un campo obligatorio, es el ttulo del mensaje a enviar, es del tipo alfanumerico, y no tiene longitud maxima.
Texto: Es un campo obligatorio, es el texto del mensaje a enviar, es del tipo alfanumerico
ShortCode: Es un campo obligatorio, es la salida por la cual se enviara el SMS, es del
tipo numerico.
Lista: Es un campo obligatorio, es el nombre de la lista a la cual se desea enviar el
mensaje, es del tipo alfanumerico.
FechaDeInicio: Es un campo opcional, es la fecha en que se desea que se empiecen a
enviar los mensajes, es del tipo date.
Desde: Es un campo opcional, es la hora de inicio en la que se pueden enviar los SMS,
sigue el siguiente formato HHMMSS.
Hasta: Es un campo opcional, es la hora de fin en la que se pueden enviar los SMS,
DiasRestringidos: Es un campo opcional, son los das en los que no se pueden enviar
SMS, y los posibles valores son: Lun, Mar, Mie, Jue, Vie, Sab, Dom
40
La interfaz se muestra en las figuras 4.17, 4.18, 4.19 y 4.20
Figura 4.17: Interfaz de Enviar SMS Paso 1. Fuente:Elaboracion propia
41
42
43
Como regla de negocio se especifico que en el envio de broadCast la fecha de inicio del
envo fuese por medio de un calendario. A continuacion la tabla 4.3 muestra y la narrativa
la figura 4.21 muestra su diagrama de secuencia.
FLUJO BASICO
ACTOR
SISTEMA
1. Se selecciona el bot
on de broadcast del 2. Se despliega las listas disponibles a las que
men
u.
se le puede enviar el broadcast.
3. Se selecciona una lista y se le da al boton 4. Se despliega los campos de texto y titulo del
de siguiente.
broadcast a enviar, tambien se despliega una
lista de shortCodes disponibles.
5. Se ingresan los datos y se selecciona un 6.Se despliega los campos de horas de restricshortCode, y se presiona el bot
on de siguiente. cion, hora y fecha de inicio del broadcast, das
restringidos. Y despliega el boton de enviar.
7. Se elecciona las restricciones de horario, da 8. El sistema enva el broadcast con las resy fecha de inicio y le da enviar
tricciones seleccionadas 9. Se enva una alerta
indicando que la operacion fue exitosa.
10. Se presiona el bot
on de OK.
11. Se redirige a CU-19.
FLUJOS ALTERNOS
ACTOR
SISTEMA
3.1 El usuario Cancela el broadCast.
3.1 Se redirige a CU-19
Cuadro 4.3: Narrativa CU Enviar SMS
Figura 4.21: Diagrama de Secuencia Enviar SMS. Fuente:Elaboracion propia
44
Tambien para la implementacion se utilizo la libreria Unit Interface (UI) de JQuery,
que tiene DaterPicker que permite en los campos de entrada colocar un calendario para
seleccionar fechas. Tambien se implemento una funcion que trajera las listas disponibles para
un suscriptor para que se pudiesen desplegar en un comboBox y este pueda seleccionar a
la que desea enviar el mensaje. Las validaciones se realizaron con JQuery permitiendo que
todas se hagan a nivel de cliente, y evitar que se realicen llamadas a MAPI con los parametros
incorrectos. Se decidio dividir el proceso en tres pasos, todos a nivel de cliente. En el primero
se coloca un asunto del mensaje y el texto a enviar. En el segundo paso, se selecciona la lista
de distribucion a la que se desea enviar el SMS, y en el tercer paso vienen las restricciones
de horario, as como la fecha de inicio. Despues cuando se le da al boton de enviar, la capa
logica se encarga de hacer las conexiones con MAPI, que se encarga de enviar el mensaje.
Seguido este paso se regresa a la pagina de alertas en la cual se muestra la tabla de Reportes.
Se hicieron pruebas puntuales y se enviaron mensajes a la lista de distribucion de manera
exitosa
Una vez finalizada la implementacion de todos los casos de uso, se finalizo la implementacion del sistema. Ahora pasamos a las conclusiones.
Captulo 5
Conclusiones y recomendaciones
Se desarrollaron todos los casos de uso requeridos por la empresa para el sistema. Se
cumplieron todos los objetivos propuestos al iniciar el desarrollo de la aplicacion. Se hicieron
pruebas unitarias funcionales y de integracion puntuales y se logro enviar exitosamente SMS
y correos electronicos, a las listas de distribucion. Mas concretamente se cumplieron los
siguientes objetivos.
Se desarrollaron los componentes para la gestion de suscriptores, tanto como la gestion
para las listas de distribucion.
Se desarrollaron los componentes para la creacion, configuracion y envo de alertas a
listas de distribucion.
Se desarrollaron los componentes para ver los reportes generados por las alertas.
La empresa Ogangi es una empresa que tiene una vision y un potencial de crecimiento
fuerte, ofrecio un ambiente de desarrollo y aprendizaje muy u
til para una persona que no
tiene experiencia en el campo laboral.
46
La tecnologa utilizada facilito el desarrollo de las aplicaciones, tecnologias como Jquery
que permiten desarrollar la funcionalidad a nivel de cliente, sin necesidad de sobrecargar
la funcionalidad del servidor. As su facilidad y la cantidad de libreras disponibles que se
encuentran en la red permitiendo al programador realizar un trabajo de manera mas comoda,
lo cual es altamente recomendado para desarrollar aplicaciones WEB.
La metodologa usada RUP, probo ser bastante u
til a la hora de adapartarse a cambios en
el flujo de desarrollo de los casos de uso, as como en la adaptabilidad a nuevos requerimientos.
Se recomienda continuar con el desarrollo de mas funcionalidades para la aplicacion tales
como: expandir el rango de las plataformas(blackberry, android, twitter, entre otros). Tambien
se recomienda hacer pruebas de carga. A pesar de tener buenos resultados en las pruebas del
sistema, es necesario observar el comportamiento ante cargas grandes de datos, y ver si es
necesaria la optimizacion en el manejo actual de las listas de distribucion.
Bibliografa
[Cor10]
Ogangi Corporation. Folleto informativo de presentacion de ogangi corporation, 2010.
[Cra03]
Larman Craig. Arquitectura de capas en sistemas de informacion. 2003.
[ee11]
Rup en espa
nol.
http://bannysolano.wordpress.com/2010/02/09/rup-en-
espanol, febrero 2010, Consultado el 01 de diciembre de 2011.

[Jar11]
Allan Jardine. http://datatables.net/, Consultado el 01 de diciembre de

2011.
[Jqu11]
Jquery. http://jquery.com/, Consultado el 01 de diciembre de 2011.
[KG03]
SIEGFRIED Reich WERNER Retschitzegger KAPPEL Gerti, BIRGIT Proll. Web engineering: The discipline of systematic development of
web applications. 2003.
[KR03]
Phillipe Kruchten and Pierre Robillard. Pedu:unified process for education.

2003.
[pdDdAdOC10] Informacion proveniente del Departamento de Administracion de Ogangi Corporation. Ogangi corporation departamento de administracion, 2010.
48
[RES11]
REST.
http://wikipedia.org/wiki/representationalstatetransfer , febrero
2010, Consultado el 1 de diciembre de 2011.
Ap
endice A
Visi
on Del Sistema
Enterprise on the Go(EGO)

Visin del Sistema
Versin 1.0

Visin del Sistema
Versin:
1.0
Fecha: 15/08/2011
Historia de Revisiones
Fecha
Versin
Descripcin
Autor
15/08/11
1.0
Documento de Visin
Andrs Mario
Confidencial
Ogangi de Venezuela, 2012
Pg. 2 de 12

Visin del Sistema
Versin:
1.0
Fecha: 15/08/2011
Visin del Sistema

1.
Introduccin
1.1
Propsito+
El propsito de este documento es proveer una perspectiva amplia al lector sobre
el sistema EGO, as como tambin la definicin de las caractersticas y los propsitos que
debe cumplir el sistema.
1.2
Alcance
Este documento tiene como alcance el proyecto de sistema para Anlisis y
Visualizacin de Bitcoras de Seguridad: sus objetivos, paradigmas y propsitos.
1.3
Definiciones, Siglas y Abreviaciones

Stakeholders: Actores relacionados con el uso de la aplicacin. Representan a las partes
interesadas.
1.4
AJAX: Asynchronous JavaScript And XML, refiere a JavaScript asncrono y XML es

una tcnica de desarrollo web para crear aplicaciones interactivas o RIA (Rich Internet
Applications). Estas aplicaciones se ejecutan en el cliente.
EGO: Enterprise on Go, sistema de envi masivo de mensajera mediante mltiples

plataformas.
SMS: Short Message Service.

Referencias
Entendiendo
el
proceso
de
migracin.
1999.
Microsoft
http://www.microsoft.com/latam/technet/articulos/199911/art03/default.aspx
Documento
de
Visin.
2007.
Http://www.openplans.org/projects/arca/documentode-visiA-n
TechNet.
Arca.
1.5
Sntesis.
Este documento est dividido en 10 secciones, entre las cuales destacan el
posicionamiento, la descripcin del usuario y del cliente, el resumen del producto, las
caractersticas del producto, precedentes, requerimientos no funcionales, entre otros.
2.
Posicionamiento
2.1
Oportunidades de Negocio
Hasta la fecha, en Venezuela Ogangi posee dos sistema propietarios de envi
Confidencial
Pg. 3 de 12

Visin del Sistema
Versin:
1.0
Fecha: 15/08/2011
masivo de mensajera de texto SMS y correo electrnico, estos sistemas permiten a

muchas empresas enviar informacin pertinente a todos sus clientes por estas vas.
La oportunidad del negocio es crear un sistema capaz de integrar dichos sistemas
en uno solo, de manera de tener un solo sistema que sirva para enviar mensajes a varias
plataformas utilizando una lista de distribucin nica, y tambin mejorando el manejo de
las listas de distribucin, esto lleva a mayor eficiencia a la hora de enviar de informacin
a los clientes. De esta manera se genera un producto ms atractivo para los clientes.
En la realizacin del sistema Web queremos mantener ante todo la perspectiva del
cliente y procurar satisfacer sus necesidades, para as darle eficiencia a sus
acostumbradas actividades, ofrecerles un mayor control y transparencia sobre el envo de
la informacin.
2.2
Declaracin del Problema

El problema de
sistemas actuales
los El problema que se tiene es que si un cliente quiere

enviar mensaje tanto por la va del correo, como por
la va del SMS tiene que cargar dos veces las listas
de distribucin, el manejo de dichas listas puede ser
engorroso, a falta de un sistema completamente
integrado y automatizado que permita el envo
masivo mensajera por varias plataformas.
Afecta a
A los clientes que utilizan los sistemas actuales.
Cuyo impacto es
Poca eficiencia a la hora de enviar mensajera

masiva, proceso complejo.
Una solucin exitosa sera
2.3
Realizar un sistema que integre, los sistemas y

funcionalidades existentes y que tengan una interfaz
sencilla y amigable que optimice el proceso de envo
de mensajera masiva.
Declaracin del Posicionamiento del Sistema

Para
Cualquier persona interesada en enviar mensajera

masiva, por SMS o por Correo electrnico.
Quines
Los usuarios tendrn la posibilidad de gestionar los

envos de forma sencilla y eficiente.
Confidencial
Pg. 4 de 12

Visin del Sistema
Versin:
1.0
Fecha: 15/08/2011
EGO
Es un sistema propietario Web de envo masivo de

mensajera de texto por mltiples plataformas.
Qu
Dar mayor eficiencia a la hora de enviar mensajes de

manera masiva, tambin manera la listas de
distribucin de manera eficiente y ms amigable.
Se diferencia de
En los sistemas propietarios actuales no existe alguno

que integre envo de SMS y correos, tampoco existe
un sistema Software libre que realice dichos envos.
Nuestro Producto
Ofrece un sistema de calidad, capaz de gestionar las

listas de distribucin de manera sencilla y amigable, al
igual que el envo masivo de mensajera, para el cual
es necesario estas listas, tambin ofrecer reportes
acerca de estos envos.
3.
Descripciones de los Stakeholders y Usuarios
3.1
Demografa del Mercado

Cualquier cliente de Ogangi, que este interesado en enviar informacin a sus
suscriptores, por SMS correo electrnico.
3.2
Resumen de Stakeholders
Nombre
Descripcin
Grisel D'Alessio Ingeniero de Software

de la empresa Ogangi de
Venezuela. Ocupa el
cargo de desarrollador
Senior, y lder de
proyecto.
Responsabilidades
-Ayudar a definir el alcance del
proyecto.
-Asegurar el cumplimiento de todos los
objetivos.
-Revisar y aprobar la documentacin
realizada tanto para la empresa
desarrolladora como para los usuarios
del sistema.
-Ayudar a validar los requerimientos y
caractersticas del sistema.
-Proporcionar o facilitar toda
informacin requerida del negocio.
la
-Validar los requerimientos y diseo de

la solucin mvil.
Desarrollador de
Confidencial
Se encarga del diseo e Definir los requerimientos y realizar el

implementacin
del diseo, anlisis y desarrollo del
Pg. 5 de 12

Visin del Sistema
Versin:
1.0
Fecha: 15/08/2011
EGO:
Andrs
Mario.
Clientes
de
Ogangi,
as
como cualquier
persona
en
Ogangi.
3.3
sistema.
sistema, as como su implantacin y

prueba.
Cualquier
persona Se encarga del envo de informacin, y
interesada en usar el gestin de las listas de distribucin.
sistema EGO, para
enviar informacin.
Resumen de los Usuarios

Nombre
Descripcin
Responsabilidades
Usuario
El usuario registrado en
el
sistema
EGO,
Interesado en enviar
informacin
a
sus
clientes.
-Gestionar usuarios.
-Gestionar listas de distribucin.
-Enviar mensajera
distribucin.
las
listas
de
-Consultar reportes.
Administrador
Es el Sper usuario del -Administrar clientes.

sistema.
Responsable -Gestionar usuarios.
del mantenimiento del -Gestionar listas de distribucin.
sistema.
-Enviar mensajera a las listas
Distribucin.
de.
3.4
Ambiente Usuario
Todos los usuarios del sistema accedern a sus funcionalidades a travs de
Web, utilizando sus respectivos computadores. Esto permite portabilidad y evita
problema de configuracin de terminales. Una vez en la pgina del sitio, se presenta
interfaz principal del sistema. Los usuarios registrados pueden ser: usuarios
administrador
la
el
la
o
Los usuarios pueden gestionar los suscriptores de las listas de distribucin,

gestionar las listas de distribucin, observar reportes de envos de informacin, tanto
como el envi de la informacin por mltiples plataformas.
El administrador posee un control total del sistema: Adems de los privilegios
del Usuario, puede gestionar los clientes, usuarios, listas de distribucin, envos de
informacin y reportes..
Confidencial
Pg. 6 de 12

Visin del Sistema
Versin:
1.0
Fecha: 15/08/2011
Segn el tipo de usuario, se presentarn ventanas con la interfaz apropiada segn

sea el caso.
Perfil de los Interesados
3.5
3.5.1 Pasante Desarrollador de Ogangi
Representantes
Andrs Mario.
La pasante se encargar del diseo y desarrollo del SI, junto con el
apoyo de su tutor industrial.
Conocimiento en lenguajes de programacin y metodologas de
desarrollo.
Descripcin
Tipo
Analizar los requerimientos, disear, desarrollar, implantar y probar

el sistema de informacin solicitado.
de El xito es alcanzado si el proyecto de SI, es un sistema con una
interfaz intuitiva y amigable, robusto, eficiente, portable, confiable.
Responsabilidad
Criterios
xito
Nivel
de El pasante participa en el SI durante su elaboracin e implantacin.
Posteriormente solo participar para labores de mantenimiento.
participacin
3.5.2 Clientes
Representantes
Los diversos clientes de Ogangi.

Entes encargados del envo de informacin a sus clientes.
Cualesquiera.
Descripcin
Tipo
Analizar los requerimientos, disear, desarrollar, implantar y probar

el sistema de informacin solicitado.
de Que al utilizar el sistema, aumente la eficiencia de envo de
informacin por mltiples plataformas.
Responsabilidad
Criterios
xito
Nivel
de Sern los usuarios finales de BM.
participacin
3.6
Perfil del Usuario

3.6.1 Usuario
Representante
Cliente
Descripcin
Una persona interesada en enviar informacin mediante mltiples

plataformas.
Tipo
Usuario.
Confidencial
Pg. 7 de 12

Visin del Sistema
Versin:
1.0
Fecha: 15/08/2011
-Gestionar clientes.
Responsabilidad
-Gestionar listas de distribucin.

-Enviar informacin a las listas de distribucin.
Criterios
xito
Que el usuario logre enviar la informacin que quiere transmitir a

todos sus clientes por mltiples plataformas de manera eficiente.
de
Nivel
de Alta, estos usuarios son el corazn del sistema ya que es bsicamente
el que provee la informacin requerida para la creacin de las listas
participacin
de distribucin, como el envo de informacin a dichas listas.
3.6.2 Administrador
Ogangi.
Representante
Descripcin
Gerencia todas las operaciones realizadas por el SI. As como el

mantenimiento del mismo.
Tipo
Experto en los procesos de envo masivo de informacin mediante

mltiples plataformas.
Responsabilidad
-Administrar clientes.
-Mantenimiento del Sistema.
Criterios
xito
de Si la realizacin de su trabajo se puede lograr en menor tiempo que

lo que toma actualmente, y de manera exitosa.
Nivel
de Alta, El Administrador de BM es el encardado del mantenimiento del
SI, y que este preste un servicio optimo para los usuarios.
participacin
3.7
Necesidades de los Stakeholder o Usuarios

Necesidad
Prioridad
Problema
Solucin Actual
que origina
la necesidad
Soluciones
Propuestas
(Caractersticas
Preliminares)
Gestionar Suscriptores
Alta
Actualmente
no
hay
manera
de
modificar los
suscriptores
Construir
un
mdulo
en
la
aplicacin web que
facilite la gestin
de suscriptores
Gestionar Listas
Alta
Actualmente
no
existe
manera
de
gestionar
Construir
un
mdulo
en
la
aplicacin web que
facilite la gestin
Confidencial
Pg. 8 de 12

Visin del Sistema
Versin:
1.0
Fecha: 15/08/2011
listas
3.8
de listas
Gestionar Broadcast
Alta
Construir
un
mdulo
en
la
aplicacin web que
facilite el envo de
broadcast
Gestionar Reportes
Media
Construir
un
mdulo
en
la
aplicacin web que
facilite la gestin
de reportes
Gestionar Sesion
Alta
Construir
un
mdulo
en
la
aplicacin web que
facilite la gestin
de sesin
Gestionar Usuarios
Alta
Construir
un
mdulo
en
la
aplicacin web que
facilite la gestin
de usuarios
Intuitivo y Amigable
Alta
Construir
el
sistema con una
interfaz intuitiva y
amigable
Eficiente
Alta
Robusto
Alta
Construir
el
sistema con el
mejor manejo ante
posibles
fallas
posibles
Seguro
Alta
Usar
protocolos
https, y algoritmos
de
encriptacin
para ciertos datos
Alternativas y Competencias
Actualmente no existen sistemas en el mercado, ni propietarios ni de software
libre que cumplan con los requisitos, por lo tanto no hay competencia.
Confidencial
Pg. 9 de 12

Visin del Sistema
Versin:
1.0
Fecha: 15/08/2011
4.
Descripcin del Sistema
4.1
Perspectiva del Sistema

EGO es un sistema de fcil uso y manejo, se desarrollar con la intencin de
simplificar la tarea del envi masivo de mensajera por mltiples plataformas, facilitar la
gestin de las listas de suscriptores creadas para este fin, as como los suscriptores y
gestionar sus respectivos reportes.
4.2
Resumen de Capacidades
Tabla 4-1
Soporte de Sistema al Cliente
Beneficios
Caractersticas
Facilidad para gestionar suscriptores
El sistema, facilita la insercin, modificacin y

eliminacin de suscriptores.
Facilidad para gestionar listas
El sistema, facilita la insercin, modificacin y

eliminacin de listas.
Facilidad para gestionar Broadcast
El sistema, facilita el envio de broadcast .
Facilidad para gestionar reportes
El sistema facilita y genera automticamente los

reportes sobre los broadcast
4.3
Aspectos asumidos y Dependencias

Es indispensable que el usuario posea una conexin a Internet.
4.4
Costos y Precios
N/A.
4.5
Licencias e Instalacin
N/A.
5.
Caractersticas del Sistema

Caracterstica
Descripcin
Gestin de Usuarios
El administrador de EGO podr permitir el ingreso, Alta

modificacin, consulta y eliminacin
Gestin
Suscriptores
Confidencial
Prioridad
de clientes en el sistema.
de El Cliente de EGO podr agregar, modificar, consultar y Alta
eliminar Usuarios con los cuales se crearan las listas de
Pg. 10 de 12

Visin del Sistema
Versin:
1.0
Fecha: 15/08/2011
distribucin necesarias para el envi de mensajera

Gestin de listas de El Cliente de EGO podr agregar, modificar, consultar, Alta
distribucin
y eliminar, Listas de distribucin en base a los Usuarios
que este posea.
Envi Masivo
Mensajera
de El Cliente podr enviar mensajes ya sea por va de Alta

mensajera de texto por correos electrnicos, a las
listas de distribucin que posea dicho cliente,
seleccionando
configurando
las
restricciones
pertinentes.
Estadsticas y reportes El Cliente podr consultar los reportes generados por el Media
acerca de los envos de sistema acerca de la difusin de los mensajes, status, etc.
mensajera
6.
Restricciones
El usuario debe poseer un navegador que soporte HTML5.
El Lenguaje de programacin a utilizar ser JS,JSP (JavaServer Pages),Java.
7.
Rangos de Calidad
Que el sistema posea una documentacin clara y precisa, una interfaz amigable e
intuitiva, tiempo de respuesta minimos, robustez y niveles de seguridad.
8.
Precedencia y Prioridad
La siguiente definicin de prioridades pertenecientes a las caractersticas del
sistemapermitir conocer cuales habr que atender primero y cuales despus durante el
desarrollo del proyecto.
1. Registro e identificacin del usuario en el sistema EGO.
2. Gestionar los usuarios pertenecientes a la listas de distribucin del sistema.
3. Carga, creacin, manipulacin y destruccin, de las listas de distribucin del
sistema.
4. Creacin y envo de mensajes de texto correos electrnicos a las listas de
distribucin.
5. Generacin de reportes acerca de los envos mensajes a las listas de distribucin.
9.
Otros Requerimientos del Sistema
9.1
Estndares Aplicables
EGO debe poder utilizarse en los sistemas operativos ms comunes en el
mercado, Incluyendo Software Libre. Los estndares de interfaz, robustez, portabilidad,
eficiencia, las mejores prcticas de programacin sern aplicados.
Confidencial
Pg. 11 de 12

Visin del Sistema
Versin:
1.0
Fecha: 15/08/2011
9.2
Requerimientos del Sistema

Se requiere un computador con conexin a Internet y un navegador que soporte
aplicaciones en AJAX y JavaScript.
9.3
Requerimientos de Desempeo
El sistema debe cargar rpidamente en los navegadores y la apariencia debe ser
independiente del navegador.
9.4
Requerimientos del Ambiente

La funcionalidad del sistema est condicionada al acceso al servicio de Internet.
10.
Requerimientos de Documentacin
10.1
Manual de Usuario
El propsito del manual es asistir a los usuarios del Sistema EGO, ayudarlos a
entender las funcionalidades de ste y de esta manera poder responder y atender cualquier
inquietud que se presente sobre el funcionamiento o sobre el sistema como tal. El manual
debe ser comprensible para el usuario y fcil de utilizar.
El manual debe tener respuestas a las preguntas y dudas ms frecuentes, dando
repuestas claras, acertadas y concisas sobre la temtica en cuestin, y en casos
particulares, si es posible, presentar ejemplos de cmo se llevara a cabo una accin
(como por ejemplo, registrar un usuario).
10.2
Guas de Instalacin, Configuracin y archivos Read Me

A pesar de que no est contemplada la implantacin del sistema se crear una gua
sobre la instalacin del sistema en el servidor.
Confidencial
Pg. 12 de 12
Ap
endice B
Documento de Arquitectura
Enterprise On the Go (EGO)

Documento de la Arquitectura del Software
Versin <4.0>
Enterprise on the GO(EGO)

Documento de la Arquitectura de Software
Versin:
<4.0>
Fecha: <15/12/2011>
Historia de Revisin
Fecha
Versin
Descripcin
Autor
15/08/2011
1.0
4. Diagrama de casos de uso inicial.
Andrs Mario
5.1 Modelo de Dominio.

30/10/2011
2.0
Andrs Mario
15/11/2011
3.0
Andrs Mario
15/12/2011
4.0
Andrs Mario
Confidencial
Pgina 2 de 17

Versin:
<4.0>
Fecha: <15/12/2011>
Documento de la Arquitectura del Software

1.
Introduccin
1.1
Propsito
Se mostrar la arquitectura del sistema empleando el Modelo de las 4 + 1 vistas. En
cada una de las vistas se detallarn las decisiones que se tomaron respecto a ellas.
1.2
Alcance
El documento presenta una descripcin detallada de la vista lgica y la arquitectura del
sistema, incluyendo diagrama de casos de uso, vista de despliegue, vista de implementacin y
vista de datos.
1.3
Definiciones, Siglas, y Abreviaciones
JSP: JavaServer Pages (JSP) es una tecnologa Java que permite generar contenido dinmico
para web, en forma de documentos HTML, XML o de otro tipo.

EGO: Enterprise on the GO, sistema de envi masivo de mensajera mediante mltiples
plataformas.
Introduccin
a
la
Arquitectura
de
Software.
1999.
Microsoft
http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/intro.mspx#ESLAC
Documento de visin.
Documento de ERS.
1.4
Referencias.
msdn.
1.5
Vista Global
Este documento se basa en la representacin de arquitectura del sistema, para lo cual
se especifican cada una de las vistas: casos de uso, lgica, de procesos, de despliegue, de
implementacin y de datos. Adicionalmente, contiene las restricciones del sistema con respecto
a la arquitectura, sus metas, una breve descripcin de las dimensiones del producto, al igual que
todo lo relacionado con el desempeo y calidad de plataformas y portabilidad, entre otros.
2.
Representacin Arquitectnica
Siguiendo la metodologa RUP, se va a implementar el modelo de 4 + 1 vistas de
Kruchten para el sistema EGO. A continuacin se describe en qu consiste cada una de estas
vistas.
Vista Lgica: Constituye el modelo conceptual del sistema a travs de los subsistemas,
clases e interfaces ms importantes y las relaciones entre estos componentes.
Confidencial
Vista de Proceso: En esta vista se muestra la concurrencia entre los procesos e hilos que
conforman el sistema.
Pgina 3 de 17

3.
4.
Versin:
<4.0>
Fecha: <15/12/2011>
Vista de Implementacin: Es un resumen de la organizacin de los entregables y de los

cdigos fuentes que se generan a partir de estos.
Vista de Implantacin: Lo constituye la distribucin del software en el hardware, as como

los requisitos funcionales a nivel de escalabilidad, confiabilidad y respuesta.
Vista de Casos de Uso: Est constituida por los casos de uso o escenarios del sistema. Se
basa en las 4 vistas anteriores
Metas y Restricciones Arquitectnicas
Plataforma Tcnica: El sistema EGO es desarrollado con JSP como lenguaje de

programacin y se encuentra en un servidor web, tambin utiliza WebServices. El servidor
debe tener en consideracin posibles fallas de electricidad, con el fin que la aplicacin no
cese su funcionamiento por culpa de stas.
Seguridad: Dado que distintos tipos de usuarios pueden acceder al sistema, es necesario
establecer niveles de privilegios, y por tanto establecer un sistema de acceso a sesiones
mediante un login y un password, tambin tiene que estar implementado en un servidor con
https, y nivel de encriptamiento de ciertos datos.
Vista de Casos de Uso
Confidencial
Pgina 4 de 17

Confidencial
Versin:
<4.0>
Fecha: <15/12/2011>
Pgina 5 de 17

Versin:
<4.0>
Fecha: <15/12/2011>
5.
Vista Lgica
5.1
Visin general
5.2
Paquetes de Diseo Significativos Arquitectnicamente
5.3
Realizaciones de los casos de uso
5.3.1 Iniciar sesin
Confidencial
Pgina 6 de 17

Versin:
<4.0>
Fecha: <15/12/2011>
5.3.2 Registrar usuario
5.3.3 Ver perfil
Confidencial
Pgina 7 de 17

Versin:
<4.0>
Fecha: <15/12/2011>
5.3.4 Modificar Perfil
5.3.5 Listar Usuarios
Confidencial
Pgina 8 de 17

Versin:
<4.0>
Fecha: <15/12/2011>
5.3.6 Eliminar Usuarios
5.3.7 Agregar suscriptor
Confidencial
Pgina 9 de 17

Versin:
<4.0>
Fecha: <15/12/2011>
5.3.8 Cargar suscriptores
5.3.9 Modificar suscriptor
Confidencial
Pgina 10 de 17

Versin:
<4.0>
Fecha: <15/12/2011>
5.3.10 Eliminar suscriptor
5.3.11 Agregar lista
Confidencial
Pgina 11 de 17

Versin:
<4.0>
Fecha: <15/12/2011>
5.3.12 Cargar listas
5.3.13 Modificar listas
Confidencial
Pgina 12 de 17

Versin:
<4.0>
Fecha: <15/12/2011>
5.3.14 Eliminar listas
5.3.15 Enviar SMS
Confidencial
Pgina 13 de 17

Versin:
<4.0>
Fecha: <15/12/2011>
5.3.16 Enviar correo
5.3.17 Cargar Reportes
5.3.18 Cerrar sesin
Confidencial
Pgina 14 de 17

6.
Versin:
<4.0>
Fecha: <15/12/2011>
Vista de Procesos
N/A
7.
Vista de Implantacin
8.
Vista de Implementacin
8.1
Vista General
Confidencial
Pgina 15 de 17

8.2
Versin:
<4.0>
Fecha: <15/12/2011>
Capas
Componente
JS
JSP
JSP Logico
XML
Confidencial
Archivos
broadcast.js
credit.js
forgotPassword.js
list.js
index.js
main.js
profile.js
registration.js
suscriptor.js
login.js
logout.js
user.js
index.jsp
main.jsp
user.jsp
suscriptor.jsp
list.jsp
broadcast.jsp
credit.jsp
profile.jsp
alertSchedulesLoadLogic.jsp
broadcastListGroupLogic.jsp
broadcastSendLogic.jsp
forgotPasswordLogic.jsp
languageSetLogic.jsp
listAddLogic.jsp
listModifyLoadLogic.jsp
listModifySaveLogic.jsp
loadShortCodesLogic.jsp
loginLogic.jsp
logoutLogic.jsp
profileChangePasswordLogic.jsp
profileEditLogic.jsp
profileReviewLogic.jsp
suscriptorAddLogic.jsp
suscriptorDeleteLogic.jsp
SuscriptorEditLogic.jsp
userLoadLogic.jsp
userDeleteLogic.jsp
registrationLogic.jsp
userLoadLogic.jsp
userDeleteLogic.jsp
Xml.java
Pgina 16 de 17

9.
Versin:
<4.0>
Fecha: <15/12/2011>
Vista de Datos
N/A
10.
Tamao y Desempeo
El desempeo se logro mediante:
1. validaciones en la capa de presentacin.
2. Uso moderado de memoria RAM.
11.
Calidad
Escalabilidad: El sistema debe poder soportar varias conexiones simultneamente, esto se

logra mediante el soporte de concurrencia del servidor Web.
Confiabilidad y disponibilidad: Es importante que el sistema se mantenga en

funcionamiento las 24 horas, todos los das, para ello hay que garantizar que no caiga ante
fallas de electricidad, etc. Esto se logra mediante instalaciones en la planta fsica en donde
se van ubicar los servidores, as como mediante equipos (UPS, etc) que aseguren que el
servicio se mantenga arriba incluso durante una falla elctrica.
Portabilidad: Debido al uso de JSP, JQuery,Ajax, WebServices, el sistema puede ser

migrado fcilmente a cualquier otro servidor en caso de ser necesario, ya que estas
herramientas funcionan bajo cualquier sistema operativo.
Modificable y mejor manejo de fallas: El sistema EGO cuenta con una arquitectura basada
en capas, lo cual facilita su modificacin y control de fallas.
Extensible: La arquitectura de tres capas tambin permite que el sistema sea extensible. A
la hora de ser necesaria la inclusin de una nueva funcionalidad al sistema, se puede
implementar un nuevo componente e integrarlo a la arquitectura sistema.
Seguridad:Ego tiene que estar implementado en un servidor que posea https, y tambien la
informacin critica tiene que estar codifcada con el algoritmo de encriptacion SHA-1.
Confidencial
Pgina 17 de 17
Ap
endice C
Especificaciones de Requerimientos
del Sistema

Requerimientos del Sistema
Versin 4.0

Especificaciones de Requerimientos del Software
Versin:
4.0
Fecha: 15/12/2011
Historia de Revisiones
Fecha
Versin
Descripcin
Autor
24/09/2011
1.0
3.0 Casos de uso Inicial
Andrs Mario
30/10/11
2.0
Caso de Uso
Andrs Mario
15/11/11
3.0
Andrs Mario
15/12/11
4.0
Andrs Mario
Confidencial
Pgina 2

Versin:
4.0
Fecha: 15/12/2011

1. Introduccin
1.1 Alcance
El alcance de este documento es la Especificacin de los Requerimientos de
Software para EGO tanto funcionales como no funcionales (especificaciones
suplementarias), las cuales se encuentran asociadas a todos Casos de Uso definidos para
el mismo
1.2
Definiciones, Acrnimos y Abreviaturas
JSP: JavaServer Pages (JSP) es una tecnologa Java que permite generar contenido
dinmico para web, en forma de documentos HTML, XML o de otro tipo.
BD : Base de Datos
EGO: Enterprise on the GO , sistema de envi masivo de mensajera mediante mltiples
plataformas.
1.3
Referencias
Documento de Vision del Sistema.
Introduccin a la Arquitectura de Software. 1999. Microsoft msdn.

http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/intro.mspx#ESLAC
MOBILETOOLS USER MANUAL v1.7
2.
Especificaciones Funcionales
2.1.
ID requerimiento:
Confidencial
Nombre del Requerimiento:

Pgina 3

R-1
Versin:
4.0
Fecha: 15/12/2011
Registrar Usuarios
Descripcin del Requerimiento:

1. El sistema debe registrar los datos de los usuarios.
2. RN: La contrasea suministrada por el usuario debe ser codificada bajo el algoritmo
SHA-1.
3. Estructura de datos :
Correo: Este campo es obligatorio, es el correo electrnico del usuario, del tipo
alfanumrico.
Contrasea: Este campo es obligatorio, es la contrasea del usuario, del tipo
alfanumrico, longitud mnima de 6, y mxima de 30.
Nombre, Este campo es obligatorio, es el nombre del usuario, del tipo alfanumrico,
longitud mxima de 100.
Cdigo Zip: Este campo es obligatorio, es el cdigo Zip del usuario, es del tipo
numrico, de longitud mxima de 10.
Categora del Negocio: Este campo es obligatorio, el la Categora del tipo de negocio
del usuario, los valores posibles son: Arte y Entretenimiento, Automotriz, Servicios
Empresariales y Profesionales, Accesorios y Ropa, Comunidad y Gobierno,
Computacin y Electrnica, Construccin y Contratistas, Educacin, Alimentos y
Restaurantes, Salud y Medicina, Hogar y Jardinera, Industria y Agricultura, Legal y
Financiero, Medios y Comunicaciones, Cuidado Personal y Servicios, Bienes Races,
Compras, Recreacin y Deportes, Transporte y Turismo.
Sitio Web: Este campo es obligatorio, es la pagina web del usuario, es del tipo carcter,
no tiene longitud mxima.
Direccin: Este Campo No es Obligatorio, es la direccin del usuario, el del tipo
carcter y no tiene longitud mxima.
Contacto Principal: Este campo es obligatorio, es el contacto principal del usuario, es
del tipo carcter y no tiene longitud mxima.
Contacto Secundario: Este campo no es obligatorio, es el secundario del usuario, es del
tipo carcter y no tiene longitud mxima.
Descripcin del negocio: Este campo no es obligatorio, es la descripcin del negocio
del cliente, es del tipo carcter y no posee longitud mxima.
4. Ver Documentos interfaces CU-1.
|Atributo: Prioridad
( x) Alta ( ) Media Alta ( ) Media ( ) Media Baja ( ) Baja
Caracterstica Asociada: Gestin de usuarios: registrar nuevo usuario.
2.2
Confidencial
Pgina 4

Versin:
4.0
Fecha: 15/12/2011
ID requerimiento:
R-2
Ver Perfil

1. El sistema debe mostrar los datos del perfil del usuario.
2. No posee RN.
3. Estructura de datos:
4.
alfanumrico.
Sitio Web: Este campo es obligatorio, es la pagina web del usuario, es del tipo carcter,
Contacto Secundario: Este campo no es obligatorio, es el secundario del usuario, es del
tipo carcter y no tiene longitud mxima.
Ver Documentos interfaces CU-4.
Atributo: Prioridad
Caracterstica Asociada: Ver Perfil.
2.3
ID requerimiento:
Confidencial

Pgina 5

R-3
Versin:
4.0
Fecha: 15/12/2011
Modificar Perfil

1. El sistema debe permitir modificar los datos del perfil.
2. La contrasea suministrada por el usuario debe ser codificada bajo el algoritmo SHA1.
alfanumrico.
Sitio Web: Este campo es obligatorio, es la pagina web del usuario, es del tipo
carcter, no tiene longitud mxima.
Contacto Secundario: Este campo no es obligatorio, es el secundario del usuario, es
4. Ver Documentos interfaces CU-5
Atributo: Prioridad
Caracterstica Asociada: Modificar Perfil.
2.4
ID requerimiento:
R-4
Confidencial

Listar Usuarios
Pgina 6

Versin:
4.0
Fecha: 15/12/2011

1. El sistema mostrar los usuarios registrados.
2. No posee RN.
alfanumrico.

Atributo: Prioridad
Caracterstica Asociada: Gestin de Usuarios: listar usuarios.
2.5
ID requerimiento:
R-7
Eliminar Usuarios

1. El sistema debe permitir eliminar los usuarios.
2. No posee RN.
3.
Estructura de datos: N\A

Atributo: Prioridad
Caracterstica Asociada: Gestin de Usuarios: Eliminar usuarios.
2.6
ID requerimiento:
Crear Suscriptor
R-8
1. El sistema debe permitir crear suscriptores.
2.
No posee RN.
Confidencial
Pgina 7

Versin:
4.0
Fecha: 15/12/2011
Nombre: este campo es obligatorio, es el nombre del suscriptor, es del tipo carcter, y
Apellido: este campo es obligatorio, es el apellido del suscriptor, es del tipo carcter, y
Mvil: Este campo es obligatorio, es el nmero del telfono mvil del suscriptor, es
del tipo numrico y posee una longitud mxima de 12.
Correo: Este campo es obligatorio, es el correo electrnico del suscriptor, del tipo
alfanumrico y no tiene longitud mxima.
Atributo: Prioridad
Caracterstica Asociada: Gestin de Suscriptores: Agregar Suscriptor.
2.7
ID requerimiento:
Modificar Suscriptor
R-7
1.
El sistema debe permitir modificar los datos del suscriptor.
2.
No posee RN.
3.
Estructura de datos:
Mvil: Este campo es obligatorio, es el numero del telfono mvil del suscriptor, es
Atributo: Prioridad
Caracterstica Asociada: Gestin de Suscriptores: Modificar Suscriptor.
2.8
ID requerimiento:
Listar Suscriptor
R-8
Confidencial
Pgina 8

Versin:
4.0
Fecha: 15/12/2011

1. El sistema debe listar los suscriptores.
2. No posee RN.
Mvil: Este campo es obligatorio, es el nmero del telfono mvil del suscriptor, es
Id: Este campo es obligatorio, el identificador del suscriptor, es del tipo numrico.
Atributo: Prioridad
Caracterstica Asociada: Gestin de Suscriptores: Listar Suscriptor.
2.9
ID requerimiento:
Eliminar Suscriptor
R-9
2. No posee RN.
3.
Estructura de datos: N\A.

Atributo: Prioridad
Caracterstica Asociada: Gestin de Suscriptores: Eliminar Suscriptor.
2.10
ID requerimiento:
Crear lista
R-10
Confidencial
Pgina 9

Versin:
4.0
Fecha: 15/12/2011

1. El debe permitir crear listas.
2. No posee RN.
Nombre: Este campo es obligatorio, es el nombre que posee la lista, es del tipo
Atributo: Prioridad
Caracterstica Asociada: Gestin de Listas: Crear lista.
2.11
ID requerimiento:
Consultar listas
R-11
1. El debe mostrar las listas.
2. El sistema debe mostrar la cantidad de suscriptores que posee una lista.
#: Este campo es obligatorio, es el nmero de suscriptores que posee una lista, es del
tipo numrico.
Id: Este campo es obligatorio es el identificador de la lista. Es del tipo numrico.
Atributo: Prioridad
Caracterstica Asociada: Gestin de Listas: Consultar lista.
2.12
ID requerimiento:
Modificar listas
R-12
Confidencial
Pgina 10

Versin:
4.0
Fecha: 15/12/2011

1. El sistema debe permitir modificar las listas.
2. El sistema debe permitir agregar o eliminar suscriptores de listas.
Atributo: Prioridad
Caracterstica Asociada: Gestin de Listas: Modificar lista.
2.13
ID requerimiento:
Eliminar listas
R-13
2. No posee RN.
3.
Estructura de datos: N\A.

Atributo: Prioridad
Caracterstica Asociada: Gestin de Listas: Eliminar lista.
Caracterstica Asociada: Gestin de Usuarios: Listar Usuarios.
2.14
ID requerimiento:
Enviar SMS
R-14
1. El sistema debe enviar SMS.
2. Se debe poder configurar los das de permitidos para enviar los mensajes, as como la
hora y fecha de salida, y el horario permitido.
Titulo: Este Campo es obligatorio, es el ttulo del mensaje a enviar, es del tipo
Confidencial
Pgina 11

Versin:
4.0
Fecha: 15/12/2011
alfanumrico, y no tiene longitud mxima.

Texto: Este Campo es obligatorio, es el texto del mensaje a enviar, es del tipo
alfanumrico
ShortCode: Este Campo es obligatorio, es la salida por la cual se enviara el SMS, es del
tipo numrico.
Lista: Este Campo es obligatorio, es el nombre de la lista a la cual se desea enviar el
mensaje, es del tipo alfanumrico.
FechaDeInicio: Este Campo es opcional, es la fecha en que se desea que se empiecen a
Desde: Este Campo es opcional, es la hora de inicio en la que se pueden enviar los
SMS, sigue el siguiente formato HHMMSS.
Hasta: Este Campo es opcional, es la hora de fin en la que se pueden enviar los SMS,
DiasRestringidos: Este campo es opcional, son los das en los que no se pueden enviar
SMS, y los posibles valores son: Lun, Mar, Mie, Jue, Vie, Sab, Dom.
4. Ver Documento interfaces CU-16.
Atributo: Prioridad
Caracterstica Asociada: Enviar Broadcast: Enviar SMS.
2.15
ID requerimiento:
Enviar Correo
R-15
1. El sistema debe enviar Correos.
2. Se debe poder configurar los das de permitidos para enviar los mensajes, as como la
hora y fecha de salida, y el horario permitido.
Titulo: Este Campo es obligatorio, es el ttulo del mensaje a enviar, es del tipo
alfanumrico, y no tiene longitud mxima.
Texto: Este Campo es obligatorio, es el texto del mensaje a enviar, es del tipo
alfanumrico
Lista: Este Campo es obligatorio, es el nombre de la lista a la cual se desea enviar el
Correo, es del tipo alfanumrico.
FechaDeInicio: Este Campo es opcional, es la fecha en que se desea que se empiecen a
Desde: Este Campo es opcional, es la hora de inicio en la que se pueden enviar los
Correos, sigue el siguiente formato HHMMSS.
Hasta: Este Campo es opcional, es la hora de fin en la que se pueden enviar los Correo,
Confidencial
Pgina 12

Versin:
4.0
Fecha: 15/12/2011

DiasRestringidos: Este campo es opcional, son los das en los que no se pueden enviar
Correo, y los posibles valores son: Lun, Mar, Mie, Jue, Vie, Sab, Dom.
Atributo: Prioridad
Caracterstica Asociada: Enviar Broadcast: Enviar Correo.
2.16
ID requerimiento:
Seleccionar Idioma
R-16
Descripcin del Requerimiento
1. El sistema debe permitir cambiar el idioma en que se despliega.
2. El idioma se debe cargar de un archivo de propiedades.
Idioma: Este campo es obligatorio, es el idioma en que se desea mostrar la aplicacin,

los posibles valores son English y Espaol.
Atributo: Prioridad
Caracterstica Asociada: Seleccionar Idioma.
2.17
ID requerimiento:
Listas Reportes
R-11
1. El debe mostrar los Reportes.
2. No posee RN.
Texto: Este campo es obligatorio, es el texto que se envio en el broadcast, es del tipo
FechaDeInicio: Este campo es obligatorio, es el da en el que se empiezan a enviar los
mensajes es del tipo date.
Esperados: Este campo es obligatorio, es el nmero de mensajes esperados a ser
Confidencial
Pgina 13

Versin:
4.0
Fecha: 15/12/2011
enviados, es del tipo entero.

Enviados: Este campo es obligatorio, es el nmero de mensajes enviados, es del tipo
entero
Fallidos: Este campo es obligatorio, es el nmero de mensajes fallidos, es del tipo
entero
Status: Este campo es obligatorio, es el estado del envo, puede ser completado, En
proceso, En espera.
Atributo: Prioridad
Caracterstica Asociada: Gestin de Listas: Consultar lista.
3.
Casos de Uso
3.1
Resumen de Casos de Uso y Actores
ID Caso de Uso
Caso de Uso
Actor
CU-1
Registrar Usuario
Usuario
CU-2
Iniciar Sesin
Usuario
CU-3
Cerrar Sesin
Usuario
CU-4
Ver Perfil
Usuario
CU-5
Modificar Perfil
Usuario
CU-6
Listar Usuario
Administrador
CU-7
Eliminar Usuario
Administrador
CU-8
Crear Suscriptor
Usuario
CU-9
Modificar Suscriptor
Usuario
CU-10
Listar Suscriptor
Usuario
CU-11
Eliminar Suscriptor
Usuario
CU-12
Crear Listas
Usuario
CU-13
Consultar Listas
Usuario
CU-14
Modificar Listas
Usuario
CU-15
Eliminar Listas
Usuario
CU-16
Enviar SMS
Usuario
CU-17
Enviar Correo
Usuario
Confidencial
Pgina 14

Versin:
4.0
Fecha: 15/12/2011
CU-18
Seleccionar Idioma
Usuario
CU-19
Consultar Reportes
Usuario
CU-20
Mostrar Men
Usuario
3.2
Especificaciones de Casos de Uso
3.2.1 Registrar Usuario
Caso de uso: CU-1

Descripcin: Los usuarios pueden registrarse en el sistema.
Requerimiento: R-1
Precondicin: N/A
FLUJO BASICO:
ACTOR
SISTEMA
1. Se ingresa en la pgina de inicio del sistema

y le da click al botn de registrarse.
2. Se muestra un formulario con los datos

necesarios para registrarse, indicando cuales
son obligatorios.
3. Se ingresa todos los datos solicitados y

presiona el botn de Enviar.
4. Se verifica que los datos ingresados son

correctos.
5. Se registra el usuario en la base de datos.
6. se muestra una alerta informando que la
operacin es exitosa.
7. Se le da al botn de OK.
6. Se dirige a CU-2.
FLUJOS ALTERNOS
ACTOR
SISTEMA
4. Se verifica que los datos ingresados y no
son correctos.
4.1. Se muestra un mensaje en la pantalla que
informa el error en los datos ingresados.
4.2 Se regresa al punto 3
Poscondicin: El usuario se registr en BD.

Requerimientos especiales: El usuario no puede estar registrado.
Puntos de extensin: N/A
Confidencial
Pgina 15

Versin:
4.0
Fecha: 15/12/2011
3.2.2Iniciar Sesin
Caso de uso: CU-2
Descripcin: Para que los usuarios puedan ingresar al sistema.
Requerimiento: N/A
Precondicin: N/A
FLUJO BASICO:
ACTOR
SISTEMA
1. ingresa a la pgina de inicio del sistema y el

usuario le da al botn de login.
2. Se muestra una pantalla de inicio de sesin.
3. El usuario ingresa todos los datos y presiona

el botn de login.
4. Se verifica que los datos ingresados son

correctos.
FLUJOS ALTERNOS
ACTOR
SISTEMA
4.1. Se verifica que los datos ingresados son
incorrectos.
4.2 Se muestra un mensaje en la pantalla que
4.3 Se regresa al punto 3.
Poscondicin: N/A
Requerimientos especiales: N\A
Puntos de extensin: N\A
3.2.3 Cerrar sesin:
Caso de uso: CU-3

Descripcin: Los usuarios puedan salir del sistema exitosamente.
Requerimiento: N/A
Precondicin: El usuario debe tener una sesin abierta.
FLUJO BASICO:
Confidencial
Pgina 16

Versin:
4.0
Fecha: 15/12/2011
ACTOR
SISTEMA
1. Se le da click en el botn de salir
2. Se muestra una pantalla un mensaje de

confirmacin de salir del sistema.
3. Se acepta el mensaje de confirmacin.
4.Se cierra la sesin y redirige al CU-2
FLUJOS ALTERNOS
ACTOR
SISTEMA
3.1 El usuario no acepta el mensaje de

confirmacin
3.2 Se dirige al CU-20.
Poscondicin: N/A
3.2.4 Ver Perfil

Caso de uso: CU-4
Descripcin: los usuarios puedan ver su perfil.
Requerimiento: R-2
Precondicin: El usuario debe tener un perfil creado en la BD.
FLUJO BASICO:
ACTOR
SISTEMA
1. Se da click al botn de perfil del men.
2. Se muestra el perfil del usuario.
FLUJOS ALTERNOS
ACTOR
SISTEMA
No posee
Poscondicin: N/A
Requerimientos especiales: N/A
Puntos de extensin: N/A
3.2.5 Modificar Perfil
Caso de uso: CU-5
Descripcin: Los usuarios modificar su Perfil.
Requerimiento: R-3
Confidencial
Pgina 17

Versin:
4.0
Fecha: 15/12/2011
Precondicin: El Usuario tiene que tener un perfil en la BD.

FLUJO BASICO:
ACTOR
SISTEMA
1. Se le da click encima del campo que se desee 2. Se muestra una pantalla un formulario con
modificar.
el campo a modificar.
3. El Usuario ingresa el dato y le da al botn de
salvar.
4. El sistema verifica que el dato sea

compatible.
5. Se actualiza el perfil y se muestra una alerta
de que la operacin fue exitosa.
6. Se presiona el botn de OK.
7. Si es compatible el sistema actualiza el

perfil y redirige a CU-4
FLUJOS ALTERNOS
ACTOR
SISTEMA
4.1. Se verifica que los datos ingresados son
incompatibles.
4.2 Se muestra un mensaje en la pantalla que
4.3 Se regresa al punto 3.
Poscondicin: El modific exitosamente su perfil en la BD

3.2.6 Listar Usuarios
Caso de uso: CU-6
Descripcin: El administrador puede ver los usuarios del sistema.
Requerimiento: R-4
Precondicin: Deben existir usuarios en la BD.
FLUJO BASICO:
ACTOR
SISTEMA
1.- Le da click botn de usuarios en el men.
2 El sistema despliega una tabla con los

usuarios disponibles y sus respectivos datos.
FLUJOS ALTERNOS
ACTOR
Confidencial
SISTEMA
Pgina 18

Versin:
4.0
Fecha: 15/12/2011
No posee flujos alternos

Poscondicin: N/A
3.2.7 Eliminar Usuarios
Caso de uso: CU-7
Descripcin: Para que el administrador pueda ver eliminar los usuarios del sistema.
Requerimiento: R-5
Precondicin: Deben existir usuarios en la BD.
FLUJO BASICO:
ACTOR
SISTEMA
1. Se selecciona los usuarios que quiere eliminar 2. Se despliega un mensaje de confirmacin

y le da al botn de eliminar.
para eliminar los usuarios.
3. Se presin el botn de OK.
4. Se eliminan los usuarios del sistema

seleccionados
5. se muestra una alerta en pantalla que la
operacin fue xitosa.
6. Se presiona OK
7. redirige a CU-6
FLUJOS ALTERNOS
ACTOR
SISTEMA
3.1 Se le da al botn de cancelar.
Poscondicin: Se eliminaron los usuarios de la BD.

3.2.8 Crear Suscriptor
Caso de uso: CU-8
Descripcin: Para que los usuarios puedan agregar suscriptores
Requerimiento:R-6
Precondicin: N/A.
FLUJO BASICO:
Confidencial
Pgina 19

Versin:
4.0
Fecha: 15/12/2011
ACTOR
SISTEMA
1. Se le da click al botn de agregar suscriptor.
2. Se despliega una pantalla con los campos

requeridos para agregar un suscriptor
3. Se ingresan los datos y se presiona el botn

de salvar.
4. Si los datos son compatibles se crea en el

sistema los un nuevo suscriptor.
5. Se muestra una alerta que indica que la
operacin fue exitosa.
6. El usuario le da al botn de OK
7. Se dirige a CU-10
FLUJOS ALTERNOS
ACTOR
SISTEMA
4.1 Si los datos ingresados no son validos.
4.2 Se muestra en pantalla un mensaje con el
respectivo error
4.3 Se redirige al punto 3.
Poscondicin: Se agrego un suscriptor a la BD.

3.2.9 Modificar Suscriptor
Caso de uso: CU-9
Descripcin: Para que los usuarios puedan modificar sus suscriptores
Requerimiento: R-7
Precondicin: Deben existir suscriptores en la BD.
FLUJO BASICO:
ACTOR
SISTEMA
1. Se le da click en la tabla de suscriptores sobre 2. Se despliega una pantalla con el campo

el campo que se desea modificar.
requerido para modificar.
3. Se introduce la informacin requerida y se le
da al botn de salvar.
4. Se procesa el dato ingresado y si es

compatible.
5. Se modifica el suscriptor en el sistema y se
muestra una alerta de operacin exitosa.
6. Se le da click al botn de OK.
7. Redirige al CU-10
FLUJOS ALTERNOS
Confidencial
Pgina 20

ACTOR
Versin:
4.0
Fecha: 15/12/2011
SISTEMA
4.1 Si el dato ingresado no es vlido.
4.2 El Sistema despliega un mensaje de error
con el error respectivo.
4.3 regresa al paso 3.
Poscondicin: Se modifico los datos del suscriptor en la BD.

3.2.10 Listar Suscriptor
Caso de uso: CU-10
Descripcin: Para que el usuario pueda ver los suscriptores disponibles
Requerimiento: R-8
FLUJO BASICO:
ACTOR
SISTEMA
1. Se le da click al botn del suscriptores en el

men.
2. Se despliega una tabla con los suscriptores

disponibles.
FLUJOS ALTERNOS
ACTOR
SISTEMA
No hay flujo alterno

Poscondicin: N/A
3.2.11 Eliminar Suscriptor
Caso de uso: CU-11

Descripcin: Para que los usuarios puedan eliminar suscriptores
Requerimiento: R-9.
FLUJO BASICO:
Confidencial
Pgina 21

ACTOR
Versin:
4.0
Fecha: 15/12/2011
SISTEMA
1. Se seleccionan los suscriptores que se quieren 2. Se despliega un mensaje de confirmacin

eliminar, y se le da click al botn de eliminar.
para eliminar los usuarios.
3. Se presin el botn de OK.
4. Se eliminan de la BD los suscriptores

seleccionados.
5. Se muestra una alerta indicando que la
7. Se redirige al CU-10
FLUJOS ALTERNOS
3.1 Se presiona el botn de cancelar
3.2 redirige a CU-10
Poscondicin: Se eliminaron los suscriptores de la BD.

3.2.12 Crear Lista
Caso de uso: CU-12
Descripcin: Para que los usuarios puedan agregar listas de distribucin.
Requerimiento: R-10.
Precondicin: N/A.
FLUJO BASICO:
ACTOR
SISTEMA
1. Se presiona el botn de crear una lista.
2. Se despliega una pantalla con los campos

requeridos para crear una lista.
3. Se ingresan los datos y se le da click al botn 4. Se verifican los datos ingresados sean
de salvar..
correctos
5. Se crea la lista en la BD y se muestra una
alerta en el indicando que la operacin fue
exitosa.
6. Se presiona el botn de OK
FLUJOS ALTERNOS
ACTOR
SISTEMA
4.1 Se verifican que los datos ingresados sea
correctos de no serlo.
4.2El Sistema despliega un mensaje de error
Confidencial
Pgina 22

Versin:
4.0
Fecha: 15/12/2011
al agregar la lista y regresa al paso 3

Poscondicin: Se creo exitosamente una lista en la BD.
3.2.13 Consultar Listas
Caso de uso: CU-13
Descripcin: Para que el usuario pueda ver las listas disponibles
Precondicin: Deben exisir listas en la BD.
FLUJO BASICO:
ACTOR
SISTEMA
1. Se le da click al botn de listas en el men

principal
2. Se despliega una tabla con las listas

disponibles.
FLUJOS ALTERNOS
ACTOR
SISTEMA
No hay flujos alternos

Poscondicin: N/A
3.2.14 Modificar Lista
Caso de uso: CU-14
Descripcin: Para que Los Usuarios puedas modificar las listas, agregar y eliminar suscriptores
a dicha lista.
Precondicin: Deben existir suscriptores y listas en la BD.
FLUJO BASICO:
ACTOR
SISTEMA
1. Se le da click sobre el nombre de la lista a

modificar.
2. Se despliega una pantalla con el nombre de

la lista (sujeto a modificaciones), una lista de
de los suscriptores pertenecientes y otra lista
de suscriptores no pertenecientes a dicha lista.
Confidencial
Pgina 23

Versin:
4.0
Fecha: 15/12/2011
3. Se modifica el nombre si se quiere, al igual

5. Se procesan los datos y El sistema procesa
que se puede arrastrar los suscriptores de la lista los datos ingresados y salva en la BD
de no pertenecientes hacia la lista de
6. Se muestra una alerta con indicando que la
perteneciente, y viceversa
4. se le da al botn de salvar.
FLUJOS ALTERNOS
ACTOR
SISTEMA
4.1 Se presiona el botn de cancelar
Poscondicin: Se modifico exitosamente la lista en la BD.

3.2.15 Eliminar Listas

Caso de uso: CU-15
Descripcin: Para que los usuarios puedan eliminar listas del sistema
Precondicin: Deben existir listas en la BD.
FLUJO BASICO:
ACTOR
SISTEMA
1. Se selecciona las listas que se van a eliminar

y se presiona el botn de eliminar.
2. Se despliega un mensaje de confirmacin.
3. Se acepta la confirmacin.
4. Se borra las listas en la BD y se muestra un

mensaje de operacin exitosa.
FLUJOS ALTERNOS
ACTOR
SISTEMA
3.1 No se acepta la confirmacin.
Poscondicin: Se eliminaron las listas de la BD.

Confidencial
Pgina 24

Versin:
4.0
Fecha: 15/12/2011
3.2.16 Enviar SMS

Caso de uso: CU-16
Descripcin: Para que los usuarios puedan enviar SMS a listas de distribucin.
Requerimiento:R-14
Precondicin: Tienen que haber listas creadas en la BD.
FLUJO BASICO:
ACTOR
SISTEMA
1. Se selecciona el botn de broadcast del men. 2. Se despliega las listas disponibles a las que
3. Se selecciona una lista y se le da al botn de
siguiente.
4. Se despliega los campos de texto y titulo

del broadcast a enviar, tambin se despliega
una lista de shortCodes disponibles.
5. Se ingresan los datos y se selecciona un

shortCode, y se presiona el botn de siguiente.
6.Se despliega los campos de horas de

restriccin, hora y fecha de inicio del
broadcast, das restringidos. Y despliega el
botn de enviar.
7. Se elecciona las restricciones de horario, da y 8. El sistema enva el broadcast con las

fecha de inicio y le da enviar
restricciones seleccionadas
9. Se enva una alerta indicando que la
11. Se redirige a CU-19
FLUJOS ALTERNOS
ACTOR
SISTEMA
Poscondicin: Se Envi un broadCast a la una lista.

3.2.17 Enviar Correo

Caso de uso: CU-17
Descripcin: Para que los usuarios puedan enviar Correo a listas de distribucin.
Confidencial
Pgina 25

Versin:
4.0
Fecha: 15/12/2011
Requerimiento:R-15
Precondicin: Tienen que haber listas creadas en la BD.
FLUJO BASICO:
ACTOR
SISTEMA
1. Se selecciona el botn de broadcast del men. 2. Se despliega las listas disponibles a las que
3. Se selecciona una lista y se le da al botn de
siguiente.
4. Se despliega los campos de texto y titulo

del broadcast a enviar.
5. Se ingresan los datos, y se presiona el botn

de siguiente.
6.Se despliega los campos de horas de

restriccin, hora y fecha de inicio del
broadcast, das restringidos. Y despliega el
botn de enviar.
7. Se elecciona las restricciones de horario, da y 8. El sistema enva el broadcast con las

fecha de inicio y le da enviar
restricciones seleccionadas
9. Se enva una alerta indicando que la
11. Se redirige a CU-19
FLUJOS ALTERNOS
ACTOR
SISTEMA
Poscondicin: Se Envi un broadCast a la una lista.

3.2.18 Seleccionar Idioma

Caso de uso: CU-18
Descripcin: Para que los usuarios puedan elegir el idioma en que se despliega el sistema.
Requerimiento:_R-16
Precondicin:
FLUJO BASICO:
Confidencial
Pgina 26

ACTOR
Versin:
4.0
Fecha: 15/12/2011
SISTEMA
1. Se selecciona en la pagina de inicio el idioma 2. El sistema se despliega en el idioma

que se desea.
seleccionado.
FLUJOS ALTERNOS
ACTOR
SISTEMA
No hay flujo alterno

Poscondicin:
3.2.19 Listar Reportes

Caso de uso: CU-19
Descripcin: Para que el usuario pueda ver los reportes de los BroadCast.
Precondicin: Deben exisir Broadcast realizados.
FLUJO BASICO:
ACTOR
SISTEMA
1. Se le da click al botn de BroadCast en el

men principal
2. Se despliega una tabla con los BroadCast

Disponibles.
FLUJOS ALTERNOS
ACTOR
SISTEMA

Poscondicin: N/A
3.2.20 Listar Men

Caso de uso: CU-20
Descripcin: Se puede ver el men principal del sistema con sus opciones.
Requerimiento: N/A
Precondicin: N/A
Confidencial
Pgina 27

Versin:
4.0
Fecha: 15/12/2011
FLUJO BASICO:
ACTOR
SISTEMA
1. Se despliega el men principal.
FLUJOS ALTERNOS
ACTOR
SISTEMA

Poscondicin: N/A
3.3
Diagrama de Caso de uso
Confidencial
Pgina 28

Versin:
4.0
Fecha: 15/12/2011
4. Especificaciones Suplementarias
Confidencial
Pgina 29

Versin:
4.0
Fecha: 15/12/2011
4.1
Usabilidad
4.1.1 Interfaz Amigable para el Usuario
El sistema debe contar con un entorno, en el cual un usuario
sin experiencia previa acerca de este pueda utilizarlo de manera fcil y sencilla, tambin tiene
que ser intuitivo.
4.2 Confiabilidad
4.2.1 Disponibilidad
El sistema debe estar disponible para los usuarios.
4.3 Desempeo
4.3.1 Tiempo de respuesta entre transacciones:
El sistema debe presentar los resultados de las consultas en un tiempo de 20 seg.
4.4
Mantenibilidad
4.4.1 Mantenimiento del Sistema.

N/A
4.5.
Seguridad
El Sisema debe manejar :
4.6.
Encriptamiento de ciertos datos, Utilizando el algoritmo SHA-1.

El sistema debe manejar dos tipos de usuario, Administrador y Usuario.
Restricciones de Diseo
Para el desarrollo de software se emplear el lenguaje JAVA, utilizando la tecnologa JSP para generar las
aplicaciones dinmicas Web; el servidor JBOSS, que posee soporte de servlets, Servicios web y JSP.
4.7.
Requerimientos de Documentacin en Lnea y de Sistemas de Ayuda
4.7.1 Manual de Usuario
Se crear un manual que debe contener los siguientes elementos:
Instrucciones necesarias para utilizar la aplicacin.
4.7.2 Ayuda en Lnea
Se plantea tener disponible soporte tcnico para la aplicacin debido a la importancia que
tiene la misma para la empresa
4.7.3 Gua de Instalacin, Configuracin, y archivo Leme.
N\A
Confidencial
Pgina 30

4.8.
Versin:
4.0
Fecha: 15/12/2011
Componentes Comprados
N/A
4.9.
Interfaces
4.9.1. Interfaces de Usuario

La interfaz debe seguir los lineamientos de la empresa, colores, estilo, ver Documento de
interfaces.
4.9.2 Interfaces de Hardware
N/A
4.9.3 Interfaces de Software
Este sistema interactua con mapi, y su comunicacin se da por medio de archivos XML,
en general
los archivos XML poseen la siguiente estructura:
<status>
<code></code>
<description></description>
<tags>
<tag id= >some description</tag>
</tags>
</status>
Donde code es el cdigo de la respuesta de la operacin, description es la descripcin del
cdigo, y tags, como tag depende del tipo de llamada que se est haciendo a MAPI, Para ms
informacin ver el documento MOBILETOOLS- USER MANUAL v1.7
4.9.4 Interfaces de Comunicaciones
El sistema utiliza las interfaces, http y https para conectarse a MobileApi.
4.10 Requerimientos de Licenciamiento
N/A
Confidencial
Pgina 31

Tesis Mensajeria Masiva

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tesis Mensajeria Masiva

Cargado por

Copyright:

Formatos disponibles

BOLIVAR

SISTEMA DE ENVIO DE MENSAJERIA MASIVA MULTIPLATAFORMA

Realizado con la asesora de:

Sartenejas, Enero de 2012

El presente trabajo describe el desarrollo(analisis, dise

1. La empresa: Ogangi de Venezuela

C. Especificaciones de Requerimientos del Sistema

4.1. Narrativa CU Registrar Usuario . . . . . . . . . . . . . . . . . . . . . . . . .

3.1. Disciplinas y fases de RUP. Fuente: [ee11] . . . . . . . . . . . . . . . . . . . .

4.1. Caso de Uso Inicial. Fuente:Elaboracion propia . . . . . . . . . . . . .

Application Programming Interface (Interfaz de programacion de

Cascading Style Sheets

Documento de Arquitectura de Software

HyperText Transfer Protocol (Protocolo para Transferencia de HiperTexto)

Java Development Environment (Ambiente de Desarrollo Java)

Java Development Kit (Equipo de Desarrollo Java)

Mobile Master Control

Representational State Transfer (Transferencia de Estado Representacional)

Rational Unified Process (Proceso Unificado de Rational)

Software Development Kit (Kit de Desarrollo de Software)

Short Message Service (Servicio de Mensajera Corta)

Uniform Resource Identifier

Uniform Resource Locator (Localizador Uniforme de Recursos)

Web Application Extension

World Wide Web Consortium

eXtensible Markup Language (Lenguaje de Marcas Extensible)

Con la utilizacion de las tecnologas de la informacion en cada vez mas aspectos de

Las limitaciones que poseen los sistemas actuales son: m

La Vision de Ogangi Corporation es:

La mision de la empresa se define de la siguiente manera: Brindar soluciones de bajo

Figura 1.1: Organigrama Ogangi Corporation Diciembre 2011. Fuente: [Cor10]

Servicio Web REST

JQuery es una biblioteca de JavaScript rapida y concisa que simplifica el recorrido de

DataTables es un plug-in para la libreria de JQuery. Es una herramienta Open-Source,

Rational Unified Process

Rational Unified Process (RUP) es una metodologa de desarrollo de software propuesta

El Proceso Unificado de Rational es un proceso de la Ingeniera del Software. RUP provee

Figura 3.1: Disciplinas y fases de RUP. Fuente: [ee11]

De la Fase de Construccion el objetivo principal es la construccion del sistema. Su enfoque

Fases y artefactos de RUP contemplados en el proyecto de

En la planificacion del proyecto de pasanta se contemplaron en su totalidad las primeras

A continuacion, en la tabla 3.1, se presentan los artefactos que se decidieron elaborar en

Cuadro 3.1: Artefactos elaborados durante la pasanta

Finalmente despues de describir la metodologa a utilizar, n

A continuacion se presenta el resultado de cada una de las actividades anteriormente

Estudio del Sistema MMC

Estudio del Sistema siMple

Establecimiento de alcance y lmites del proyecto

Figura 4.1: Caso de Uso Inicial. Fuente:Elaboracion propia

Tamben se elaboro el Modelo de Dominio inicial. Ver figura 4.2

Figura 4.2: Modelo de Dominio Inicial. Fuente:Elaboracion propia

Se procedio a elaborar el diagrama de la vista de implementacion, ver figura 4.3

Figura 4.3: Vista de implementacion. Fuente:Elaboracion propia

Figura 4.4: Diagrama de componentes. Fuente:Elaboracion propia

Figura 4.5: Caso de Uso primera iteracion. Fuente:Elaboracion propia

Figura 4.6: WAE primera iteracion. Fuente:Elaboracion propia

suscriptor.jsp y user.jsp. Estos

index.js, profile.js, login.js, registration.js, suscriptor.js, user.js, logout.js. Estos

Figura 4.7: Caso de Uso segunda iteracion. Fuente:Elaboracion propia

Figura 4.8: WAE segunda iteracion. Fuente:Elaboracion propia

Caso de Uso Registrar Usuario

Como reglas de negocio se requirio que la Constrase

Figura 4.9: Interfaz Registrar Usuario. Fuente:Elaboracion propia