Upload
giovanni-briceno-fuentes
View
247
Download
3
Embed Size (px)
DESCRIPTION
tesis para elaborar una mensajeria masiva en las instituciones educativas ...Los antecedentes de la investigación se refieren a la revisión de los trabajos anteriores sobre el tema de investigación en estudio que realizaron instituciones de educación superior y que sirve para sustentar lo antes investigado.Según Pérez (2002) define antecedentes “Es una investigación bibliográfica en investigaciones anteriores, tanto del ámbito nacional como internacional”.Por otra parte Tamayo y Tamayo (2004), define los antecedentes “Consiste en el análisis de investigaciones iguales o similares relacionadas en nuestro campo de estudio”.A continuación se presentan los antecedentes de la investigación, los cuales se resumen en la investigación para que se estudiaran en el tema del razonamiento lógico.Mariño (2012) en su trabajo de grado para optar al título de ingeniero en computación en la Universidad Simón Bolívar realizo un “Sistema de envío de mensajería masiva multiplataforma” este trabajo es similar a nuestra investigación y es de referencia por la mensajería masiva.
Citation preview
UNIVERSIDAD SIMON BOLIVARDECANATO DE ESTUDIOS PROFESIONALES
COORDINACION DE INGENIERIA DE LA COMPUTACION
SISTEMA DE ENVIO DE MENSAJERIA MASIVA MULTIPLATAFORMA
Por:Andres H. Marino O.
Realizado con la asesora de:Tutor Academico: Mara Angelica Perez de Ovalles
Tutor Industrial: Grisel D Alessio
PASANTIA LARGAPresentado ante la Ilustre Universidad Simon Bolvar
como requisito parcial para optar al ttulo deIngeniero en Computacion
Sartenejas, Enero de 2012
Resumen
El presente trabajo describe el desarrollo(analisis, diseno, implementacion y pruebas unitarias
y de integracion) del Sistema de Envo de Mensajera Multiplataforma, util para enviar infor-
macion 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 ser-
vicios 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 rendi-
miento.
El sistema fue implementado en los lenguajes JSP, JavaScript, Java, ademas, utilizo Mo-
bile 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.
v
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 X
Lista de Abreviaturas XII
Introduccion 1
1. La empresa: Ogangi de Venezuela 3
1.1. Resena Historica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Mision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Estructura de la empresa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Marco Teorico 7
2.1. Arquitectura de capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Servicio Web REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. JQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4. DataTables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Marco Metodologico 11
3.1. Rational Unified Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.1. Estructura de RUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.2. Fases de RUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.3. Fases y artefactos de RUP contemplados en el proyecto de pasanta . 14
3.1.3.1. Artefactos elaborados . . . . . . . . . . . . . . . . . . . . . 15
4. Desarrollo 16
4.1. Primera Iteracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.1. Extraccion de requerimientos . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1.1. Estudio del Sistema MMC . . . . . . . . . . . . . . . . . . . 17
4.1.1.2. Estudio del Sistema siMple . . . . . . . . . . . . . . . . . . 18
4.1.2. Establecimiento de alcance y lmites del proyecto . . . . . . . . . . . 19
4.1.3. Eleccion de Herramientas a usar . . . . . . . . . . . . . . . . . . . . . 20
4.1.4. Elaboracion de los documentos de Vision del sistema, ERS y DAS . . 21
4.2. Segunda Iteracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.1. Caso de Uso Registrar Usuario . . . . . . . . . . . . . . . . . . . . . . 27
4.3. Tercera Iteracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.1. CU Modificar Listas . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4. Cuarta Iteracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.1. Enviar SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5. Conclusiones y recomendaciones 45
Bibliografa 47
A. Vision 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 . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2. Narrativa CU Modificar Lista . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3. Narrativa CU Enviar SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Indice de figuras
1.1. Organigrama Ogangi Corporation Diciembre 2011. Fuente: [Cor10] . . . . . . 5
3.1. Disciplinas y fases de RUP. Fuente: [ee11] . . . . . . . . . . . . . . . . . . . . 12
4.1. Caso de Uso Inicial. Fuente:Elaboracion propia . . . . . . . . . . . . . . . . . 19
4.2. Modelo de Dominio Inicial. Fuente:Elaboracion propia . . . . . . . . . . . . . 20
4.3. Vista de implementacion. Fuente:Elaboracion propia . . . . . . . . . . . . . . 21
4.4. Diagrama de componentes. Fuente:Elaboracion propia . . . . . . . . . . . . . 22
4.5. Caso de Uso primera iteracion. Fuente:Elaboracion propia . . . . . . . . . . 22
4.6. WAE primera iteracion. Fuente:Elaboracion propia . . . . . . . . . . . . . . 23
4.7. Caso de Uso segunda iteracion. Fuente:Elaboracion propia . . . . . . . . . . 25
4.8. WAE segunda iteracion. Fuente:Elaboracion propia . . . . . . . . . . . . . . 26
4.9. Interfaz Registrar Usuario. Fuente:Elaboracion propia . . . . . . . . . . . . 28
4.10. Diagrama de Secuencia Registrar Usuario. Fuente:Elaboracion propia . . . . 29
4.11. Caso de Uso tercera iteracion. Fuente:Elaboracion propia . . . . . . . . . . . 31
4.12. WAE tercera iteracion. Fuente:Elaboracion propia . . . . . . . . . . . . . . . 32
4.13. Interfaz Modificar Listas. Fuente:Elaboracion propia . . . . . . . . . . . . . . 33
4.14. Diagrama de Secuencia Modificar Listas. Fuente:Elaboracion propia . . . . . 35
4.15. Caso de Uso cuarta iteracion. Fuente:Elaboracion propia . . . . . . . . . . . 37
4.16. WAE cuarta iteracion, Fuente:Elaboracion propia . . . . . . . . . . . . . . . 38
4.17. Interfaz de Enviar SMS Paso 1. Fuente:Elaboracion propia . . . . . . . . . . 40
4.18. Interfaz de Enviar SMS Paso 2. Fuente:Elaboracion propia . . . . . . . . . . 41
4.19. Interfaz de Enviar SMS Paso 3. Fuente:Elaboracion propia . . . . . . . . . . 42
4.20. Interfaz de Enviar SMS Paso 3. Fuente:Elaboracion propia . . . . . . . . . . 42
4.21. Diagrama de Secuencia Enviar SMS. Fuente:Elaboracion propia . . . . . . . 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 Especificacion de Requerimientos de Software
HTTP HyperText Transfer Protocol (Protocolo para Transferencia de Hi-
perTexto)
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 Repre-
sentacional)xii
1RUP 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 Vision del Sistema
WAE Web Application Extension
W3C World Wide Web Consortium
XML eXtensible Markup Language (Lenguaje de Marcas Extensible)
Introduccion
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 companias, 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
2informacion pertinente acerca de un evento, entre otros. Existen pocas companias 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 plata-
formas (SMS, correo electronico).
Las limitaciones que poseen los sistemas actuales son: multiples 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
resena historica de la empresa, su mision y vision, as como la estructura organizacional, y
la ubicacion del pasante dentro de la misma.
1.1. Resena Historica
En el ano 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].
41.2. Vision
La Vision de Ogangi Corporation es:
Generacion de nuevas oportunidades de ingresos para las empresas proveedoras de con-
tenidos 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 busqueda de nuevas vas de comu-
nicacion 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. Mision
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 dis-
tribuir de forma eficiente las actividades correspondientes al proceso de negocio de la misma.
Actualmente, se tienen 5 departamentos en Ogangi: Desarrollo de Software, Ventas, Opera-
ciones e Infraestructura Tecnologica, Finanzas y Contenido. Ver figura 1.1
5Figura 1.1: Organigrama Ogangi Corporation Diciembre 2011. Fuente: [Cor10]
A continuacion se describe el departamento de Ogangi Corporation en el que se desa-
rrollo 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 Marino cumplio la mision de desarrollar EGO (Enterprise on the
GO), un sistema propietario de Ogangi, que permite el envo de mensajera por multiples
6plataformas (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 Teorico
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
Segun Kappel [KG03] una arquitectura de N capas es aquella que permite organizar una
aplicacion Web en un numero arbitrario de capas. Tpicamente se consideran tres capas. La
capa de datos, que reune todos los aspectos del software que tienen que ver con el manejo
de los datos persistentes, la capa de negocio que reune 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
reune todos los aspectos del software que tiene que ver con las interfaces y la interaccion con
los diferentes tipos de usuarios humanos.
8Segun 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 reuti-
lizacion 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 arquitec-
tura 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 disenar sistemas de servicios Web de acuerdo con el estilo arquitectural REST
de Roy Fielding y tambien es posible disenar 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.
9Los 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 disenos
fundamentales clave: [RES11]
Un protocolo cliente/servidor sin estado: cada mensaje HTTP contiene toda la informa-
cion necesaria para comprender la peticion. Como resultado, ni el cliente ni el servidor
necesitan recordar ningun 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 infor-
macion: HTTP en s define un conjunto pequeno 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 unicamente 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 transi-
ciones 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 recur-
so 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, crea-
cion, busqueda de informacion entre ellas, exportacion, entre otros, de manera dinami-
ca [Jar11].
Ahora se procede en el siguiente captulo a explicar la metodologa utilizada para desa-
rrollar el sistema.
Captulo 3
Marco Metodologico
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
Segun [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 consti-
tuido 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 orga-
nizacion 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 disena 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.
Disenar, 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 disenado.
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 carac-
teriza 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 Ite-
raciones) 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 InicioDocumento DescripcionVision del Sistema(VS) El documento de Vision permite analizar y de-
finir las necesidades del sistema a alto nivel.Especificacion de Requerimientos del Sistema(ERS) El documento de Requerimientos del Sistema
permite especificar los requerimientos funcio-nales y no funcionales del sistema.
Fase de ElaboracionDocumento DescripcionDocumento de Arquitectura del Software(DAS) El documento de Arquitectura del Software
proporciona una vision general de la arquitec-tura del sistema, a traves de diferentes vistas.Entre ellas estan vista de datos, vista de casosde uso, vista de implementacion, vista logicay vista de despliegue.
Fase de ConstruccionDocumento DescripcionManual de Usuario Describe las funcionalidades del sistema de
forma detallada, brindando asistencia a cual-quier usuario de la aplicacion.
Cuadro 3.1: Artefactos elaborados durante la pasanta
Finalmente despues de describir la metodologa a utilizar, numero de iteraciones contem-
pladas 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 ejecu-
cion 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 diseno 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 Iteracion
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 diseno 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 Re-
querimientos 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. Extraccion 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 Mas-
ter 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 repeti-
das, 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 algun 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 admi-
nistrar de manera efciente y comoda las transacciones que desee mediante las funcio-
nalidades ofrecidas, con solo ingresar su correo y su contrasena.
19
4.1.2. Establecimiento de alcance y lmites del proyecto
En un principio se penso, abarcar todas las funcionalidades que posee MMC, Alertas,
Campanas, 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 sus-
criptores, manejo de sesion, gestion de listas de distribucion, manejo de alertas y reportes.
No se contemplo el manejo de la gestion de campanas.
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 excep-
tuando 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. Eleccion de Herramientas a usar
Considerando el conjunto de requerimientos propuestos y conociendo los lenguajes me-
diante 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 compana para la supervision y colocacion en servidores de prueba, ademas de las
herramientas para probar los servicios Web.
21
4.1.4. Elaboracion de los documentos de Vision 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 de-
cidio 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 Diseno 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 Iteracion
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, Lis-
tar 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 con-
tienen 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, user-
DeleteLogic.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 ar-
chivos 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
26
Fig
ura
4.8:
WA
Ese
gunda
iter
acio
n.
Fuen
te:E
lab
orac
ion
pro
pia
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 alfa-
numerico.
Contrasena: Es un campo obligatorio, es la contrasena del usuario, es del tipo alfa-
numerico, 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 Em-
presariales 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 Constrasena tiene que codificarse segun 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 BASICOACTOR SISTEMA1. Se ingresa en la pagina de inicio del sistemay le da click al boton de registrarse
2. Se muestra un formulario con los datos ne-cesarios para registrarse, indicando cuales sonobligatorios.
3. Se ingresan todos los datos solicitados y pre-siona el boton de Enviar.
4. Se verifica que los datos ingresados son co-rrectos. 5. Se registra el usuario en la base dedatos. 6. se muestra una alerta informando quela operacion es exitosa.
7. Se le da al boton de OK. 8. Se dirige a CU-2.FLUJOS ALTERNOS
ACTOR SISTEMA4. Se verifica que los datos ingresados no soncorrectos. 4.1. Se muestra un mensaje en lapantalla que informa el error en los datos in-gresados. 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 Iteracion
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
32
Fig
ura
4.12
:W
AE
terc
era
iter
acio
n.
Fuen
te:E
lab
orac
ion
pro
pia
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 arras-
trando 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 BASICOACTOR SISTEMA1. Se le da click sobre el nombre de la lista amodificar.
2. Se despliega una pantalla con el nombre dela lista (sujeto a modificaciones), una lista dede los suscriptores pertenecientes y otra listade suscriptores no pertenecientes a dicha lista.
3. Se modifica el nombre si se quiere, al igualque se puede arrastrar los suscriptores de lalista de no pertenecientes hacia la lista de per-teneciente, y viceversa 4. se le da al boton desalvar.
5. Se procesan los datos y El sistema proce-sa los datos ingresados y salva en la BD 6. Semuestra una alerta con indicando que la ope-racion fue exitosa.
7. Se presiona el boton de OK 8. Se dirige al CU-13FLUJOS ALTERNOS
ACTOR SISTEMA4.1 Se presiona el boton de cancelar 4.2 Se redirige al CU-13.
Cuadro 4.2: Narrativa CU Modificar Lista
35
Fig
ura
4.14
:D
iagr
ama
de
Sec
uen
cia
Modifi
car
Lis
tas.
Fuen
te:E
lab
orac
ion
pro
pia
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 Iteracion
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, broadcastSendLo-
gic.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 MA-
PI.
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
38
Fig
ura
4.16
:W
AE
cuar
tait
erac
ion,
Fuen
te:E
lab
orac
ion
pro
pia
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 alfa-
numerico, 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,
sigue el siguiente formato HHMMSS.
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
Figura 4.18: Interfaz de Enviar SMS Paso 2. Fuente:Elaboracion propia
42
Figura 4.19: Interfaz de Enviar SMS Paso 3. Fuente:Elaboracion propia
Figura 4.20: Interfaz de Enviar SMS Paso 3. Fuente:Elaboracion propia
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 BASICOACTOR SISTEMA1. Se selecciona el boton de broadcast delmenu.
2. Se despliega las listas disponibles a las quese le puede enviar el broadcast.
3. Se selecciona una lista y se le da al botonde siguiente.
4. Se despliega los campos de texto y titulo delbroadcast a enviar, tambien se despliega unalista de shortCodes disponibles.
5. Se ingresan los datos y se selecciona unshortCode, y se presiona el boton de siguiente.
6.Se despliega los campos de horas de restric-cion, hora y fecha de inicio del broadcast, dasrestringidos. Y despliega el boton de enviar.
7. Se elecciona las restricciones de horario, day fecha de inicio y le da enviar
8. El sistema enva el broadcast con las res-tricciones seleccionadas 9. Se enva una alertaindicando que la operacion fue exitosa.
10. Se presiona el boton de OK. 11. Se redirige a CU-19.FLUJOS ALTERNOS
ACTOR SISTEMA3.1 El usuario Cancela el broadCast. 3.1 Se redirige a CU-195.1 El usuario Cancela el broadCast. 5.1 Se redirige a CU-197.1 El usuario Cancela el broadCast. 7.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 implemen-
tacion 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 util 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 util 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 corpo-
ration, 2010.
[Cra03] Larman Craig. Arquitectura de capas en sistemas de informacion. 2003.
[ee11] Rup en espanol. 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, BIR-
GIT 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 Ogan-
gi Corporation. Ogangi corporation departamento de administracion, 2010.
48
[RES11] REST. http://wikipedia.org/wiki/representationalstatetransfer , febrero
2010, Consultado el 1 de diciembre de 2011.
Apendice A
Vision Del Sistema
Enterprise on the Go(EGO) Visin del Sistema
Versin 1.0
Enterprise on the Go(EGO) Versin: 1.0 Visin del Sistema Fecha: 15/08/2011
Confidencial Ogangi de Venezuela, 2012 Pg. 2 de 12
Historia de Revisiones Fecha Versin Descripcin Autor
15/08/11 1.0 Documento de Visin Andrs Mario
Enterprise on the Go(EGO) Versin: 1.0 Visin del Sistema Fecha: 15/08/2011
Confidencial Ogangi de Venezuela, 2012 Pg. 3 de 12
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.
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.
1.4 Referencias
Entendiendo el proceso de migracin. 1999. Microsoft TechNet. http://www.microsoft.com/latam/technet/articulos/199911/art03/default.aspx
Documento de Visin. 2007. Arca.
Http://www.openplans.org/projects/arca/documentode-visiA-n
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
Enterprise on the Go(EGO) Versin: 1.0 Visin del Sistema Fecha: 15/08/2011
Confidencial Ogangi de Venezuela, 2012 Pg. 4 de 12
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 los sistemas actuales
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
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.
2.3 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.
Enterprise on the Go(EGO) Versin: 1.0 Visin del Sistema Fecha: 15/08/2011
Confidencial Ogangi de Venezuela, 2012 Pg. 5 de 12
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 Responsabilidades
Grisel D'Alessio Ingeniero de Software de la empresa Ogangi de Venezuela. Ocupa el cargo de desarrollador Senior, y lder de proyecto.
-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 la informacin requerida del negocio.
-Validar los requerimientos y diseo de la solucin mvil.
Desarrollador de Se encarga del diseo e implementacin del
Definir los requerimientos y realizar el diseo, anlisis y desarrollo del
Enterprise on the Go(EGO) Versin: 1.0 Visin del Sistema Fecha: 15/08/2011
Confidencial Ogangi de Venezuela, 2012 Pg. 6 de 12
EGO: Andrs Mario.
sistema. sistema, as como su implantacin y prueba.
Clientes de Ogangi, as como cualquier persona en Ogangi.
Cualquier persona interesada en usar el sistema EGO, para enviar informacin.
Se encarga del envo de informacin, y gestin de las listas de distribucin.
3.3 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 a las listas de distribucin.
-Consultar reportes.
Administrador Es el Sper usuario del sistema. Responsable del mantenimiento del sistema.
-Administrar clientes.
-Gestionar usuarios. -Gestionar listas de distribucin.
-Enviar mensajera a las listas de. Distribucin.
-Consultar reportes.
3.4 Ambiente Usuario
Todos los usuarios del sistema accedern a sus funcionalidades a travs de la Web, utilizando sus respectivos computadores. Esto permite portabilidad y evita el problema de configuracin de terminales. Una vez en la pgina del sitio, se presenta la interfaz principal del sistema. Los usuarios registrados pueden ser: usuarios o administrador
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..
Enterprise on the Go(EGO) Versin: 1.0 Visin del Sistema Fecha: 15/08/2011
Confidencial Ogangi de Venezuela, 2012 Pg. 7 de 12
Segn el tipo de usuario, se presentarn ventanas con la interfaz apropiada segn
sea el caso.
3.5 Perfil de los Interesados 3.5.1 Pasante Desarrollador de Ogangi
Representantes Andrs Mario.
Descripcin La pasante se encargar del diseo y desarrollo del SI, junto con el apoyo de su tutor industrial.
Tipo Conocimiento en lenguajes de programacin y metodologas de desarrollo.
Responsabilidad Analizar los requerimientos, disear, desarrollar, implantar y probar el sistema de informacin solicitado.
Criterios de xito
El xito es alcanzado si el proyecto de SI, es un sistema con una interfaz intuitiva y amigable, robusto, eficiente, portable, confiable.
Nivel de participacin
El pasante participa en el SI durante su elaboracin e implantacin. Posteriormente solo participar para labores de mantenimiento.
3.5.2 Clientes
Representantes Los diversos clientes de Ogangi.
Descripcin Entes encargados del envo de informacin a sus clientes. Tipo Cualesquiera.
Responsabilidad Analizar los requerimientos, disear, desarrollar, implantar y probar el sistema de informacin solicitado.
Criterios de xito
Que al utilizar el sistema, aumente la eficiencia de envo de informacin por mltiples plataformas.
Nivel de participacin
Sern los usuarios finales de BM.
3.6 Perfil del Usuario
3.6.1 Usuario
Representante Cliente
Descripcin Una persona interesada en enviar informacin mediante mltiples plataformas.
Tipo Usuario.
Enterprise on the Go(EGO) Versin: 1.0 Visin del Sistema Fecha: 15/08/2011
Confidencial Ogangi de Venezuela, 2012 Pg. 8 de 12
Responsabilidad -Gestionar clientes. -Gestionar listas de distribucin.
-Enviar informacin a las listas de distribucin.
-Consultar reportes.
Criterios de xito
Que el usuario logre enviar la informacin que quiere transmitir a todos sus clientes por mltiples plataformas de manera eficiente.
Nivel de participacin
Alta, estos usuarios son el corazn del sistema ya que es bsicamente el que provee la informacin requerida para la creacin de las listas de distribucin, como el envo de informacin a dichas listas.
3.6.2 Administrador
Representante Ogangi.
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 de xito
Si la realizacin de su trabajo se puede lograr en menor tiempo que lo que toma actualmente, y de manera exitosa.
Nivel de participacin
Alta, El Administrador de BM es el encardado del mantenimiento del SI, y que este preste un servicio optimo para los usuarios.
3.7 Necesidades de los Stakeholder o Usuarios
Necesidad
Prioridad Problema que origina la necesidad
Solucin Actual 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
Enterprise on the Go(EGO) Versin: 1.0 Visin del Sistema Fecha: 15/08/2011
Confidencial Ogangi de Venezuela, 2012 Pg. 9 de 12
listas 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
3.8 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.
Enterprise on the Go(EGO) Versin: 1.0 Visin del Sistema Fecha: 15/08/2011
Confidencial Ogangi de Venezuela, 2012 Pg. 10 de 12
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 Prioridad
Gestin de Usuarios El administrador de EGO podr permitir el ingreso, modificacin, consulta y eliminacin
de clientes en el sistema.
Alta
Gestin de Suscriptores
El Cliente de EGO podr agregar, modificar, consultar y eliminar Usuarios con los cuales se crearan las listas de
Alta
Enterprise on the Go(EGO) Versin: 1.0 Visin del Sistema Fecha: 15/08/2011
Confidencial Ogangi de Venezuela, 2012 Pg. 11 de 12
distribucin necesarias para el envi de mensajera
Gestin de listas de distribucin
El Cliente de EGO podr agregar, modificar, consultar, y eliminar, Listas de distribucin en base a los Usuarios que este posea.
Alta
Envi Masivo de Mensajera
El Cliente podr enviar mensajes ya sea por va de mensajera de texto por correos electrnicos, a las listas de distribucin que posea dicho cliente, seleccionando configurando las restricciones pertinentes.
Alta
Estadsticas y reportes acerca de los envos de mensajera
El Cliente podr consultar los reportes generados por el sistema acerca de la difusin de los mensajes, status, etc.
Media
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.
Enterprise on the Go(EGO) Versin: 1.0 Visin del Sistema Fecha: 15/08/2011
Confidencial Ogangi de Venezuela, 2012 Pg. 12 de 12
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.
Apendice B
Documento de Arquitectura
Enterprise On the Go (EGO) Documento de la Arquitectura del Software
Versin
Enterprise on the GO(EGO) Versin: Documento de la Arquitectura de Software Fecha:
Confidencial Ogangi de Venezuela, 2012 Pgina 2 de 17
Historia de Revisin Fecha Versin Descripcin Autor
15/08/2011 1.0 4. Diagrama de casos de uso inicial.
5.1 Modelo de Dominio.
Andrs Mario
30/10/2011 2.0 Andrs Mario
15/11/2011 3.0 Andrs Mario
15/12/2011 4.0 Andrs Mario
Enterprise on the GO(EGO) Versin: Documento de la Arquitectura de Software Fecha:
Confidencial Ogangi de Venezuela, 2012 Pgina 3 de 17
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.
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 the GO, sistema de envi masivo de mensajera mediante mltiples plataformas.
1.4 Referencias. Introduccin a la Arquitectura de Software. 1999. Microsoft msdn.
http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/intro.mspx#ESLAC Documento de visin. Documento de ERS.
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.
Vista de Proceso: En esta vista se muestra la concurrencia entre los procesos e hilos que conforman el sistema.
Enterprise on the GO(EGO) Versin: Documento de la Arquitectura de Software Fecha:
Confidencial Ogangi de Venezuela, 2012 Pgina 4 de 17
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
3. 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.
4. Vista de Casos de Uso
Enterprise on the GO(EGO) Versin: Documento de la Arquitectura de Software Fecha:
Confidencial Ogangi de Venezuela, 2012 Pgina 5 de 17
Enterprise on the GO(EGO) Versin: Documento de la Arquitectura de Software Fecha:
Confidencial Ogangi de Venezuela, 2012 Pgina 6 de 17
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
Enterprise on the GO(EGO) Versin: Documento de la Arquitectura de Software Fecha:
Confidencial Ogangi de Venezuela, 2012 Pgina 7 de 17
5.3.2 Registrar usuario
5.3.3 Ver perfil
Enterprise on the GO(EGO) Versin: Documento de la Arquitectura de Software Fecha:
Confidencial Ogangi de Venezuela, 2012 Pgina 8 de 17
5.3.4 Modificar Perfil
5.3.5 Listar Usuarios
Enterprise on the GO(EGO) Versin: Documento de la Arquitectura de Software Fecha:
Confidencial Ogangi de Venezuela, 2012 Pgina 9 de 17
5.3.6 Eliminar Usuarios
5.3.7 Agregar suscriptor
Enterprise on the GO(EGO) Versin: Documento de la Arquitectura de Software Fecha:
Confidencial Ogangi de Venezuela, 2012 Pgina 10 de 17
5.3.8 Cargar suscriptores
5.3.9 Modificar suscriptor
Enterprise on the GO(EGO) Versin: Documento de la Arquitectura de Software Fecha:
Confidencial Ogangi de Venezuela, 2012 Pgina 11 de 17
5.3.10 Eliminar suscriptor
5.3.11 Agregar lista
Enterprise on the GO(EGO) Versin: Documento de la Arquitectura de Software Fecha:
Confidencial Ogangi de Venezuela, 2012 Pgina 12 de 17
5.3.12 Cargar listas
5.3.13 Modificar listas
Enterprise on the GO(EGO) Versin: Documento de la Arquitectura de Software Fecha:
Confidencial Ogangi de Venezuela, 2012 Pgina 13 de 17
5.3.14 Eliminar listas
5.3.15 Enviar SMS
Enterprise on the GO(EGO) Versin: Documento de la Arquitectura de Software Fecha:
Confidencial Ogangi de Venezuela, 2012 Pgina 14 de 17
5.3.16 Enviar correo
5.3.17 Cargar Reportes
5.3.18 Cerrar sesin
Enterprise on the GO(EGO) Versin: Documento de la Arquitectura de Software Fecha:
Confidencial Ogangi de Venezuela, 2012 Pgina 15 de 17
6. Vista de Procesos N/A
7. Vista de Implantacin
8. Vista de Implementacin
8.1 Vista General
Enterprise on the GO(EGO) Versin: Documento de la Arquitectura de Software Fecha:
Confidencial Ogangi de Venezuela, 2012 Pgina 16 de 17
8.2 Capas Componente Archivos JS broadcast.js
credit.js forgotPassword.js list.js index.js main.js profile.js registration.js suscriptor.js login.js logout.js user.js
JSP index.jsp main.jsp user.jsp suscriptor.jsp list.jsp broadcast.jsp credit.jsp profile.jsp
JSP Logico 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 Xml.java
Enterprise on the GO(EGO) Versin: Documento de la Arquitectura de Software Fecha:
Confidencial Ogangi de Venezuela, 2012 Pgina 17 de 17
9. 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.
Apendice C
Especificaciones de Requerimientos
del Sistema
Enterprise on the GO(EGO) Requerimientos del Sistema
Versin 4.0
Enterprise on the Go(EGO) Versin: 4.0 Especificaciones de Requerimientos del Software Fecha: 15/12/2011
Confidencial Ogangi de Venezuela, 2012 Pgina 2
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
Enterprise on the Go(EGO) Versin: 4.0 Especificaciones de Requerimientos del Software Fecha: 15/12/2011
Confidencial Ogangi de Venezuela, 2012 Pgina 3
Especificaciones de Requerimientos del Software
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 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 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: Nombre del Requerimiento:
Enterprise on the Go(EGO) Versin: 4.0 Especificaciones de Requerimientos del Software Fecha: 15/12/2011
Confidencial Ogangi de Venezuela, 2012 Pgina 4
R-1 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