Download - DESARROLLO DE UNA APLICACIÓN MÓVIL …
1
DESARROLLO DE UNA APLICACIÓN MÓVIL MULTIPLATAFORMA DE MENSAJERÍA INSTANTÁNEA PARA AGENTES EMPRESARIALES
Presentado por: JOBELO ANDRÉS QUINTERO RODRÍGUEZ
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA
PROYECTO CURRICULAR DE INGENIERÍA DE SISTEMAS BOGOTÁ, COLOMBIA
2016
2
DESARROLLO DE UNA APLICACIÓN MÓVIL MULTIPLATAFORMA DE
MENSAJERÍA INSTANTÁNEA PARA AGENTES EMPRESARIALES
Presentado por: JOBELO ANDRÉS QUINTERO RODRÍGUEZ
INFORME FINAL DE PASANTIA
Dr. Ing. CARLOS ENRIQUE MONTENEGRO MARÍN Director
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA
PROYECTO CURRICULAR DE INGENIERÍA DE SISTEMAS BOGOTÁ, COLOMBIA
2015
3
CONTENIDO
1. INTRODUCCIÓN ..................................................................................................... 12
2. PLANTEAMIENTO DEL PROBLEMA .................................................................. 13
3. OBJETIVOS .............................................................................................................. 15
3.1 OBJETIVO GENERAL ..................................................................................... 15
3.2 OBJETIVOS ESPECÍFICOS ............................................................................ 15
4. JUSTIFICACIÓN ...................................................................................................... 16
5. MARCO TEÓRICO .................................................................................................. 17
5.1 FRAMEWORK ................................................................................................. 17
5.2 MENSAJERÍA INSTANTÁNEA ..................................................................... 20
5.3 API REST .......................................................................................................... 23
5.4 DISEÑO RESPONSIVO ................................................................................... 24
6. ALCANCES Y LIMITACIONES ............................................................................. 27
6.1 ALCANCES ...................................................................................................... 27
6.2 lIMITACIONES ................................................................................................ 27
4
7. METODOLOGÍA ...................................................................................................... 29
8. desarrollo de aplicación MOVIL multiplataforma de mensajeria instantanea para
agentes empresariales ..................................................................................................................... 32
8.1 investigacion inicial ........................................................................................... 32
8.2 ARQUITECTURA ............................................................................................ 39
8.3 DESARROLLO DEL CLIENTE DE MENSAJERIA INSTANTANEA ......... 81
8.4 CRONOGRAMA OBTENIDO ......................................................................... 87
8.5 Metodologia ....................................................................................................... 89
8.6 INCONVENIENTES ......................................................................................... 97
5
9. TRABAJOS FUTUROS ............................................................................................ 98
10. CONCLUSIONES ................................................................................................. 98
11. BIBLIOGRAFÍA ................................................................................................. 100
6
LISTA DE TABLAS
Tabla 1 - Cronograma obtenido - Fuente: El Autor ......................................................... 88
7
LISTA DE DIAGRAMAS
Diagrama 1 - Metamodelo vista de organización .............................................................. 39
Diagrama 2 - Modelo vista de organización ...................................................................... 40
Diagrama 3 - Metamodelo vista de cooperación de actor .................................................. 41
Diagrama 4 – Modelo vista de cooperación de actor ......................................................... 42
Diagrama 5 - Metamodelo vista función de negocio ......................................................... 43
Diagrama 6 - Modelo vista función de negocio ................................................................. 43
Diagrama 7 - Metamodelo vista proceso de negocio ......................................................... 44
Diagrama 8 - Modelo vista proceso de negocio ................................................................. 45
Diagrama 9 - Metamodelo vista de producto ..................................................................... 46
Diagrama 10 - Modelo vista de producto ........................................................................... 47
Diagrama 11 - Metamodelo vista de comportamiento de aplicación ................................. 48
Diagrama 12 - Modelo vista de comportamiento de aplicación ........................................ 49
Diagrama 13 - Metamodelo vista de cooperación de aplicación ....................................... 50
Diagrama 14 - Modelo vista de cooperación de aplicación ............................................... 51
Diagrama 15 - Metamodelo vista de estructura de aplicación ........................................... 52
Diagrama 16 - Modelo vista de estructura de aplicación ................................................... 53
Diagrama 17 - Metamodelo vista de uso de aplicación ..................................................... 54
Diagrama 18 - Modelo vista de uso de aplicación ............................................................. 55
Diagrama 19 - Metamodelo vista de infraestructura .......................................................... 56
Diagrama 20 - Modelo vista de infraestructura ................................................................. 57
Diagrama 21 - Metamodelo vista de uso de infraestructura .............................................. 58
Diagrama 22 - Modelo vista de uso de infraestructura ...................................................... 59
Diagrama 23 - Metamodelo vista de estructura de información ........................................ 60
Diagrama 24 - Modelo vista de estructura de información ................................................ 61
Diagrama 25 - Metamodelo vista de realización de servicio ............................................. 62
Diagrama 26 - Modelo realización de servicio Realización de servicio ............................ 63
Diagrama 27 - Modelo vista de capas ................................................................................ 64
Diagrama 28 - Metamodelo vista de Stakeholder .............................................................. 65
8
Diagrama 29 - Modelo vista de Stakeholder ...................................................................... 65
Diagrama 30 - Metamodelo vista de realización de objetivos ........................................... 66
Diagrama 31 - Modelo vista de realización de objetivos ................................................... 66
Diagrama 32 - Metamodelo vista de contribución ............................................................. 67
Diagrama 33 - Modelo vista de contribución ..................................................................... 68
Diagrama 34 - Metamodelo vista de principios ................................................................. 69
Diagrama 35 - Modelo vista de principios ......................................................................... 69
Diagrama 36 - Metamodelo vista de realización de requerimientos .................................. 70
Diagrama 37 - Modelo vista de realización de requerimientos ......................................... 71
Diagrama 38 - Metamodelo vista de motivación ............................................................... 72
Diagrama 39 - Modelo vista de motivación ....................................................................... 73
Diagrama 40 - Metamodelo vista de proyecto ................................................................... 74
Diagrama 41 - Modelo vista de proyecto ........................................................................... 75
Diagrama 42 - Metamodelo vista de migración ................................................................. 76
Diagrama 43 - Modelo vista de migración ......................................................................... 76
Diagrama 44 - Metamodelo vista de migración e implementación ................................... 77
Diagrama 45 - Modelo vista de migración e implementación ........................................... 78
Diagrama 46 – Arquitectura FLUX ................................................................................... 80
9
LISTA DE ANEXOS
Los anexos que se listan a continuación se encuentran en el cd Anexos del presente
trabajo, cada archivo se encuentra en la raíz del cd con los nombres que se especifican entre
paréntesis de cada elemento de la lista.
Anexo 1: Mockups de aplicación web/escritorio y móvil (Mockups.DOCX)
Anexo 2: Cronograma obtenido detallado (Cronograma detallado.pdf)
Anexo 3: Manual de usuario de cliente de mensajeria instantanea para agentes
empresariales (Manual de usuario.DOCX)
10
GLOSARIO
Se incluye este glosario para definir términos que ayuden al lector en la comprensión del
presente documento.
Backend: Es la labor de ingeniería que compone generación de servicios del lado del
servidor.
First-mobile: Aplicación que en sus primeras versiones estará disponible para
plataformas móviles.
Flux: Arquitectura de aplicación creada por Facebook para construir aplicaciones web del
lado del cliente.
Frontend: Es la labor de ingeniería que se encarga de estructurar un servicio del lado del
cliente, aplicaciones en el lado del cliente.
HTML: HyperText Markup Language (lenguaje de marcas de hipertexto), lenguaje de
marcado para la elaboración de páginas web.
HTTP: HyperText Transport Protocol (Protocolo de Transporte de Hipertexto).
Messenger: Aplicación de mensajería instantánea
Mocukp: Boceto básico y de baja calidad del desarrollo de una página web o el diseño de
una interfaz.
MVC: Modelo Vista Controlador, Es un patrón de arquitectura de software.
Multiplataforma: Hace alusión a la capacidad de una aplicación de poder ejecutarse en
diversos tipos de plataformas, por ejemplo: Microsoft Windows, Linux, MacOS, Android,
Windows Phone, IOS, etc.
OnBoarding: Hace referencia al proceso de registro, integración de un ente a una
organización.
Responsividad: En aplicaciones web hace referencia a la capacidad de las páginas de
reajustar su tamaño y apariencia según la resolución de pantalla del dispositivo que las muestra.
REST: Transferencia de Estado Representacional (Representational State Transfer) es un
estilo de arquitectura software para sistemas hipermedia distribuidos como la World Wide Web.
RPC: Remote Procedure Call, una técnica para la comunicación entre procesos en una o
más computadoras.
11
XML: Extensible Markup Language: Es un meta-lenguaje que permite definir lenguajes
de marcado adecuados a usos determinados.
12
1. INTRODUCCIÓN
La mensajería instantánea se ha vuelto popular en distintos ámbitos de la vida cotidiana;
muchas de las personas la utilizan para estar en contacto con sus familias y amigos, al igual que
muchas compañías la utilizan para mantener contacto interno entre sus empleados y también con
sus clientes. La mensajería instantánea posee varias ventajas frente a otras tecnologías: Por un
lado su naturaleza casi síncrona es ideal para peticiones y respuestas sencillas, proporciona
presencia y notificación de eventos que hacen que sea fácil hacer seguimiento de la
disponibilidad de contactos (colegas, amigos, familiares, etc.), Además muchos de los sistemas
de mensajería instantánea incorporan soporte para voz, video y transferencia de archivos,
permitiendo así que sea un entorno integrado para las necesidades que plantea la comunicación.
(Xiao, Guo, & Tracey, 2007)
Twnel es un "messenger" móvil que conecta a empresas con sus clientes. Aprovechando el
crecimiento acelerado de los teléfonos inteligentes en nuestro país1, y los cambios en el
comportamiento de la nueva generación de consumidores conectados (los cuales prefieren chatear
por su celular en vez de hablar); Twnel tiene como objetivo lograr que el poder de la mensajería
móvil en teléfonos inteligentes acerque a empresas con sus clientes, ahorrándole a ambos tiempo
y dinero a la hora de resolver inquietudes y realizar trámites; permitiéndole a éstos últimos recibir
información de su interés.
Mediante el presente proyecto se plantea el desarrollo de una aplicación móvil
multiplataforma de mensajería instantánea para los agentes empresariales, la cual será la nueva
cara de Twnel frente a las empresas que lo utilizan.
1 “En Colombia los usuarios móviles pasaron de 47,2 millones en septiembre de 2013 a 50,5 millones en el
mismo mes de 2014, registrando un crecimiento del 6,9% durante el último año”.
http://www.elpais.com.co/elpais/economia/noticias/colombia-tercer-mercado-latinoamericano-usuarios-smartphones
13
2. PLANTEAMIENTO DEL PROBLEMA
Con el transcurrir el tiempo el uso de dispositivos móviles dentro de ambientes laborales
se ha hecho común, dejando atrás la concepción de que el computador es la herramienta
fundamental. El uso de aplicaciones web responsivas es más evidente en los últimos años debido
a lo anterior. Por otro lado el surgimiento de frameworks y herramientas para el desarrollo web
ha permitido que se abarquen aspectos tales como interoperabilidad, portabilidad, escalabilidad y
usabilidad.
Actualmente Twnel cuenta con un aplicativo web que es usado por agentes de empresas el
cual permite la comunicación directa con sus clientes. Debido a la necesidad inmediata de un
aplicativo web se pasó por alto la implementación de un diseño responsivo o inclusive, el
establecimiento de una arquitectura que permita extender dicha aplicación web a otros tipos de
dispositivos diferentes a un ordenador que cuente con un navegador, afectando así, la experiencia
de usuario de los agentes empresariales que acceden al aplicativo web por medio de dispositivos
móviles.
Adicionalmente el aplicativo web está construido con Angularjs en su versión 1.x, esta
versión de framework está destinada a dejar de recibir soporte en el año 2018 debido al anuncio
de lanzamiento de la versión 2.0 («Migrating to AngularJS 2.0», s. f.), La versión 2.0 de contará
con cambios drásticos en la arquitectura del framework, lo cual podría incurrir a futuro, en malas
experiencias del equipo de desarrollo y retrasos en lanzamiento de características proyectadas
para el cliente web, además, expandir las funcionalidades de la aplicación requiere de más tiempo
del propuesto por Google frente al soporte de Angular 1.x
El mercado de la mensajería móvil es un mercado joven, un mercado en el cual sobresalen
aplicaciones como Whatsapp, Line o Messenger, sin embargo, no se han explotado todas las
ventajas que posee la mensajería instantánea en distintos ámbitos («What is the future of instant
messaging?», s. f.), es por eso que todos los “messengers” están probando distintas cosas, por
14
ejemplo el desarrollo del cliente web de Whatsapp y Messenger o inclusive la gran tienda de
Stickers que ofrece Line («Mobile Messaging Clients Compared - TechSpot», s. f.).
El fuerte de Twnel es el canal directo que brinda a las empresas para comunicarse con sus
clientes, a pesar de que otros “messengers” están empezando a incurrir en la prestación de
servicios a empresas, Twnel cuenta con un servicio consolidado para empresas, el cual es su
razón de ser y ha permitido establecer alianzas con empresas a nivel nacional tales como
EasyTaxi, Uff Móvil, ETB, Bancolombia, BBVA, entre otros («Twnel», s. f.).
De acuerdo con lo anterior se hace necesario identificar y proponer una nueva arquitectura
utilizando un framework que cuente con soporte para la construcción de una aplicación móvil
multiplataforma, teniendo como finalidad la reconstrucción del aplicativo para agentes
empresariales.
15
3. OBJETIVOS
3.1 OBJETIVO GENERAL
Desarrollar una aplicación móvil multiplataforma de mensajería instantánea para agentes
empresariales que permita a estos comunicarse con sus clientes a través de distintos tipos de
dispositivos
3.2 OBJETIVOS ESPECÍFICOS
• Documentar, analizar y proponer distintos frameworks para el desarrollo de la aplicación.
• Definir los requerimientos de la aplicación móvil de mensajería instantánea con la
finalidad de cubrir las necesidades presentadas por los agentes empresariales
• Proponer la arquitectura de la aplicación móvil con base al framework elegido teniendo
como finalidad soportar los requerimientos definidos
• Establecer un diseño responsivo para el aplicativo teniendo como finalidad la extensión
del mismo a otros tipos de plataformas.
• Construir los módulos la aplicación de acuerdo a la arquitectura y diseño propuestos,
teniendo como finalidad la entrega de un producto funcional.
• Realizar las pruebas unitarias y de integración pertinentes para la validación de los
requerimientos del proyecto.
• Realizar la Documentación correspondiente al diseño lógico y visual de la aplicación para
que luego puedan ser consultados por miembros del equipo de Twnel y posibles
consultores.
16
4. JUSTIFICACIÓN
El uso de dispositivos móviles ha tenido un incremento considerable en los últimos años,
incluso es más común que una persona cuente con un dispositivo móvil que con un computador
(«Colombia, tercer mercado latinoamericano en usuarios de smartphones | El País - Noticias de
Cali, Valle y Colombia», s. f.), incluso, muchas de las personas han reemplazado el uso de la
computadora personal por el del móvil para sus trabajos.
El objetivo empresarial de Twnel es conectar a las empresas con sus clientes a través de
un canal de mensajería instantánea, por medio del cual, las empresas hacen uso de una aplicación
web que actualmente se visualiza de manera correcta en dispositivos con una resolución mayor o
igual a 1024 x 800 pixeles. El cliente web está construido con Angular 1.x; en su versión 2.0,
Angular modificará totalmente su arquitectura dejando sin soporte a sus versiones anteriores y
obligando a realizar una migración de todo el cliente a un nuevo framework.
De esta manera, Twnel evidencia la necesidad un cliente web responsivo (first-mobile) y
el uso de un nuevo framework y una nueva arquitectura, pretendiendo mejorar la experiencia de
usuario y solventar el problema de soporte, ofreciendo un servicio óptimo independiente de la
plataforma en que sea usado.
17
5. MARCO TEÓRICO
5.1 FRAMEWORK
Un framework es una plataforma para el desarrollo de aplicaciones, la cual provee una
base para que los desarrolladores puedan construir software para plataformas específicas, estos
pueden definir estándares, clases y funciones que el desarrollador puede usar para la construcción
de un software específico (Ferguson, Peterson, & Thompson, 2005). Los frameworks suelen
confundirse con una interface de programación de aplicación API, exactamente un framework
sirve como base para el desarrollo, mientras que una API proporciona acceso a los elementos
admitidos por el framework («Framework Definition», s. f.) .El uso de frameworks en los
aplicativos web actuales es fundamental debido a que estos permiten agilizar el proceso de
desarrollo, además de brindar arquitecturas predefinidas que facilitan la comprensión de la
estructura del software. A continuación se describen algunos de los frameworks que se tendrán a
consideración para la creación de la aplicación multiplataforma de Twnel para agentes
empresariales.
AngularJS
AngularJS es un framework MVC para JavaScript de código abierto, el cual es mantenido
por Google, es utilizado para la creación de aplicaciones del lado del cliente. En contraste con la
arquitectura tradicional MVC, donde todo el sitio web es renderizado desde el lado del servidor,
Angular permite que la vista sea generada en el navegador usando los datos de los modelos
enlazados a una vista, además el controlador se encarga de la interacciones entre el documento
HTML y el modelo, esto quiere decir que en este tipo de MVC no existen llamadas al servidor y
todo es resuelto en el lado del cliente. AngularJS abstrae las llamadas al servidor a una capa
separada para evitar redundancia de código a través de múltiples vistas por un punto de acceso
construido únicamente con HTML5, JavaScript y Servicios REST (Balasubramanee,
Wimalasena, Singh, & Pierce, 2013).
18
AngularJS permite extender el vocabulario HTML a través del concepto de directivas,
además permite crear vistas dinámicas en aplicaciones web manipulando el modelo de objetos del
documento DOM a través del enlace bidireccional de datos, una manera de actualizar la vista
cada vez que hay cambios en el modelo enlazado(«AngularJS — Superheroic JavaScript MVW
Framework», s. f.). En el año 2014 se hace anuncio de la versión 2.0 la cual difiere en gran
medida de la versión 1.x, debido a cambios radicales en la arquitectura del mismo y en la
construcción del core de AngularJS 2.0 el cual está escrito completamente en TypeScript debido
a la alianza entre Google Y Microsoft para desarrollar la nueva versión del framework. La
construcción de AngularJS 2.0 tiene como finalidad hacer un salto a tecnologías nuevas como lo
son la versión 6 de ECMASCript (ES),web components y otras («My Thoughts on AngularJS 1.3
and 2.0», s. f.). Dentro de los cambios que hay en la versión 2.0 cabe destacar los siguientes
(«What’s New in AngularJS 2.0», s. f.)(«The Core Concepts of Angular 2», s. f.):
• Enfoque en el desarrollo de aplicaciones móviles.
• Varios módulos fueron removidos del core de Angular, obteniendo así un mayor
rendimiento del framework.
• El objetivo de angular es ES6 y los navegadores “Evergreen” (Navegadores que se
mantienen actualizados a su última versión estable)
• Cambios en el manejo de enlace bidireccional de datos y manejo de plantillas.
• Cambios en las directivas, agregando así 3 tipos de directivas.
o Directivas de componente – La facilidad de poder crear componentes
reusables encapsulando lógica Javascript, HTML, inclusive hojas de estilo
CSS.
o Directivas de decorador – Estas directivas son usadas para decorar los
elementos de DOM HTML.
o Directivas de plantilla – Este tipo de directivas permiten convertir el
documento HTML en una plantilla reutilizable. Por ejemplo las directivas ng-
if y ng-repeat.
• Se remueve el concepto de ámbito ($scope) en favor a las clases de ES6.
• Se brinda al desarrollador un mayor control sobre el ciclo de vida de navegación en
la aplicación a través de las llamadas de retorno can*.
19
EmberJS
Ember.js es un framework de código abierto para crear aplicaciones del lado del cliente
con javascript basado en el patrón MVC. Este permite la creación de aplicaciones web single-
page (aplicaciones web de única página). En Ember.js son comunes los conceptos de Rutas (cada
estado de la aplicación es representado por una URL), Modelos (Cada ruta es asociada a un
modelo y contiene los datos asociados al estado actual de la aplicación), Plantillas y
Componentes (Etiquetas HTML personalizadas).(«Ember.js - A framework for creating
ambitious web applications. », s. f.)
ReactJS
ReactJS es una librería de código abierto de javascript para crear interfaces de usuario,
esta librería es mantenida por Facebook, Instagram y la comunidad de desarrolladores javascript.
Esta librería ofrece grandes beneficios en cuanto a rendimiento, modularidad, además, promueve
un flujo muy claro de datos y eventos, facilitando así la planeación y desarrollo de aplicaciones
complejas («Qué es y cómo funciona ReactJS», s. f.). Se recomienda que para la iniciación de un
proyecto nuevo con esta librería se haga uso de la arquitectura FLUX, sin embargo si se utiliza un
framework MVC (AngularJS, por ejemplo) («Why React?», s. f.), se puede utilizar ReactJS para
el manejo de las vistas dentro de la arquitectura MVC, lo anterior se debe a que ReactJS tiene un
performance superior al momento de manipular el DOM («Qué es y cómo funciona ReactJS»,
s. f.).
ReactJS implementa algo llamado Virtual DOM, el cual, en vez de renderizar todo el
DOM en cada cambio realizado, este hace los cambios en una copia de memoria y luego usa un
algoritmo para comparar las propiedades de la copia en memoria con las de la versión del DOM y
así aplicar los cambios exclusivamente en las partes que varían, haciendo que el performance en
comparación con otros frameworks o librerías sea muy alto(«Qué es y cómo funciona ReactJS»,
s. f.).
20
ReactJS promueve el flujo de datos en un solo sentido, a diferencia del flujo de datos
bidireccional propuesto por Frameworks Modernos (AngularJS, EmberJS por ejemplo), esto hace
más fácil la planeación y detección de errores en aplicaciones complejas, en las que el flujo de
información puede ser muy complejo, dando lugar a errores difíciles de ubicar(«Qué es y cómo
funciona ReactJS», s. f.).
5.2 MENSAJERÍA INSTANTÁNEA
A continuación se presentan algunas tecnologías para la implementación de mensajería
instantánea.
XMPP
A continuación se describe la tecnología utilizada por los clientes móviles IOS y Android
para clientes de empresas o usuarios que no son agentes empresariales.
El Protocolo extensible de mensajería y comunicación de presencia (Extensible
Messaging and Presence Protocol) mejor conocido como XMPP es una tecnología abierta para la
comunicación en tiempo real, que alimenta una amplia gama de aplicaciones, incluyendo la
mensajería instantánea, presencia, grupos de chat, llamadas de voz y video sindicación de
contenidos y enrutamiento generalizado de datos XML. El core de la tecnología detrás de XMPP
fue inventada por Jerimie Miller en 1998, refinada por la comunidad open-source Jabber en 1999
y 2000, y formalizada por el IETF en 2002 y 2003, resultando en la publicación de los RFCs de
XMPP en 2004 y actualizados en el 2011. (admin, s. f.-a).
Según la especificación del RFC3920, el core de la capa de transporte de XMPP es un
protocolo de flujo del lenguaje extensible de marcado (XML) que permite a dos entidades
intercambiar elementos XML a través de una red. Aunque la implementación punto-a-punto de
XMPP existe, la arquitectura típica de XMPP sigue el modelo cliente-servidor donde los clientes
se conectan al servidor y los servidores se conectan a otros servidores para comunicaciones
21
interdominio (Hornsby, Belimpasakis, & Defee, 2009). Una de las ventajas de XMPP es que
soluciona el problema de conexión de los sistemas de mensajería instantánea con sistemas de
diferente tipo debido al uso de XML (Lu, Lei, & Zhang, 2012).
La comunicación XMPP trata con tres tipos de estructuras, cada una con su propio
significado.
- <presence/>, esta estructura es un mecanismo básico para suscribirse-publicar a través
del cual varias entidades pueden recibir información de una entidad con la cual tienen
suscripción, la estructura de presencia es usada para informar sobre la disponibilidad de
una entidad en una red, conocido comúnmente en términos de mensajería instantánea
cuando una entidad esta online u offline.
- <message/>, esta estructura es un mecanismo de “empuje” (push) donde una entidad
puede enviar información asíncrona a otra entidad.
- <iq/> (info/query), esta estructura es un mecanismo donde las entidades pueden hacer
peticiones y recibir respuestas unas de otras.
Estos tres tipos de estructuras son suficientes para proveer una gran variedad de
aplicaciones, desde sistemas de administración de redes hasta monitoreo remoto.(Hornsby et al.,
2009).
BOSH
A continuación se describe la tecnología para mensajería instantánea utilizada por los
clientes de Windows Phone y FirefoxOS de la aplicación Twnel para usuarios que no son agentes
empresariales.
22
BOSH (Bidirectional-streams Over Synchronous HTTP), es una tecnología de
comunicación bidireccional que trabaja sobre el protocolo HTTP (Hypertext Transfer Protocol).
Este emula muchas de las primitivas de transporte, las cuales se asemejan al protocolo de control
de transmisión (TCP). Una de las ventajas de BOSH es que es mucho más eficiente en cuanto al
manejo de ancho de banda para comunicación bidireccional respecto a otros protocolos basados
en HTTP y técnicas como AJAX (XMPP Technologies:BOSH, s. f.-b). Uno de los usos
principales de BOSH es el manejo de tráfico intercambiado entre clientes y servidores
Jabber/XMPP, por ejemplo, para facilitar la conexión desde clientes web y clientes móviles que
cuentan con conexiones intermitentes(Paterson, Saint-Andre, Stout, & Tilanus, 2014).
La técnica empleada por BOSH, también es conocida como “HTTP Long polling”,
reduciendo la latencia y el ancho de banda consumido a través de otras técnicas HTTP. Cuando el
cliente envía una petición, el administrador de conexión no envía inmediatamente una respuesta;
en su lugar mantiene la petición abierta hasta que posee los datos necesarios para poder enviarlos
al cliente (o un envío de respuesta al cliente indicando que el tiempo de espera ha sido
superado)(Paterson, Smith, et al., 2014).
WebSocket
WebSocket es una especificación definida con el estándar HTML5 que define un API
para establecer una conexión persistente entre el navegador web del usuario y el servidor, a través
de esta conexión, ambas partes pueden enviar datos en cualquier momento (Ubl, 20th, & article,
s. f.). A través de este API es posible enviar mensajes al servidor y recibir respuestas dirigidas
por eventos sin necesidad de tener que consultar de nuevo al servidor para obtener dicha
respuesta («WebSockets», s. f.).
Dentro de los distintos paradigmas que afrontan comunicación de manera asíncrona,
WebSocket ha sido aceptado como framework fundamental para la implementación de
conexiones web full-duplex de manera asíncrona (Skvorc, Horvat, & Srbljic, 2014).Es decir,
WebSocket define una conexión de socket único full-duplex sobre la cual cliente y servidor
23
pueden enviar mensajes, simplificando así, la complejidad de la comunicación bidireccional y
administración de conexión («WebSocket.org -- A WebSocket Community», s. f.).
5.3 API REST
El backend de Twnel está constituido por un API REST, el cual permite el guardado de
contactos, conversaciones, usuarios, etc., A continuación se da la definición de servicio web tipo
API REST.
REST (Representational State Transfer), es un tipo de arquitectura web que se apoya en
totalmente en el estándar HTTP. REST permite crear servicios y aplicaciones que pueden ser
usadas por cualquier dispositivo o cliente que entienda HTTP, permitiendo que sea más simple y
convencional que otras alternativas como SOAP y XML-RPC (Asier, s. f.).
Los servicios web que siguen la arquitectura REST publican un conjunto de recursos
relacionados que los clientes pueden descubrir a través de hiperenlaces e interactuar con estos a
través de una interfaz uniforme (Haupt, Leymann, & Pautasso, 2015).
REST es el tipo de arquitectura más natural y estándar para crear APIs para servicios
orientados a Internet según (Asier, s. f.).
Aspectos Clave
A continuación se definen los aspectos clave para el desarrollo de un API REST según
(Asier, s. f.).
• Métodos HTTP
• Códigos de estado
• Aceptación de tipos de contenido
24
5.3.1.1 Métodos
Para manipular los recursos, HTTP posee los siguientes métodos con los cuales el cliente
debe operar (Asier, s. f.):
• GET: Para consultar y leer recursos
• POST: Para crear recursos
• PUT: Para editar recursos
• DELETE: Para eliminar recursos.
• PATCH: Para editar partes concretas de un recurso.
5.3.1.2 Códigos de estado
HTTP define estados a través de valores numéricos para los tipos de respuesta cuando un
cliente realiza una petición a través de los métodos definidos, por ejemplo: 200 para cuando la
petición fue resuelta, 4xx cuando hay un error en la petición hecha por el cliente, 5xx cuando hay
un error en el lado del servidor, entre otras(«Status codes in HTTP», s. f.).
5.3.1.3 Aceptación de tipos de contenido
Definen los tipos de respuesta y contenido del cuerpo de la petición, por ejemplo: JSON,
XML, PDF, ZIP, etc. (Usier, s. f.).
5.4 DISEÑO RESPONSIVO
Teniendo en cuenta que uno de los problemas principales que presenta el cliente web de
Twnel para agentes empresariales es la falta de un diseño responsivo, se hace necesaria la
definición de este concepto.
El acceso a internet estaba limitado en su mayoría al uso de computadoras, los distintos
diseñadores web se preocupaban únicamente de que sus páginas tuvieran soporte para los
distintos navegadores, sin embargo con la llegada de los dispositivos móviles este escenario tuvo
25
cambios abismales. Actualmente los usuarios de internet utilizan cada vez más dispositivos
móviles para navegar. El diseño responsivo tiene la capacidad de responder a las distintas
resoluciones de los dispositivos en los cuales se está visualizando un sitio web, dimensionando
todos los componentes de esta de acuerdo a dichas resoluciones(«Diseño Responsivo», s. f.). Este
diseño especifica en el código de las hojas de estilo CSS los distintos tipos de consultas de media
(media query) para detectar las características de visualización del dispositivo y modificar la
presentación de la aplicación web, de acuerdo al conjunto de archivos HTML5 / CSS los cuales
permiten una visualización que se ajusta al dispositivo. Por otro lado, el diseño responsivo es
diferente al diseño adaptativo, el cual utiliza consultas al servidor para detectar que archivos
HTML5/CSS se van a enviar al cliente para visualizar el sitio web de manera correcta de acuerdo
al dispositivo, es decir, cada conjunto de dispositivos tiene asignada una plantilla determinada
para la visualización del sitio web (Zervas, Trichos, Sampson, & Li, 2014).
Ventajas
A continuación se listan algunas ventajas definidas por (Jiang, Zhang, Zhou, Jiang, &
Zhang, 2014) del diseño responsivo:
- El diseño responsivo es amigable con el usuario, muchos de los dispositivos móviles
mejoran la experiencia de usuario. Evidentemente, el diseño web responsivo ha proveído
a los usuarios una interfaz web amigable, debido a que esta puede adaptarse a todas las
pantallas de los dispositivos.
- Menos mantenimiento, el desarrollo responsivo de un sitio web puede reducir costos en
mantenimiento, debido a que este solo tienen un único conjunto de archivos que
responden a todos los tipos de dispositivos.
- No hay que tener nombres de dominio adicionales, es decir, será un mismo sitio, a
diferencia de cuando se accede a una página web móvil, allí habrían dos sitios, esto hace
necesario la configuración de un nombre de dominio adicional.
26
Desventajas
A continuación se listan algunas desventajas definidas por (Jiang et al., 2014) del diseño
responsivo:
• Debido a la cantidad de código incluido en los archivos, es evidente que se afecta la
velocidad de carga del sitio web.
• Generalmente en el diseño responsivo, las imágenes, videos y otros recursos se cargan
uniformemente. Esto resulta en que cuando se cargan estos recursos en dispositivos de
baja resolución pueden afectar el desempeño del dispositivo, por ejemplo, cuando se
cargan videos o imágenes con resoluciones más altas que las especificadas por este.
• En los últimos años, la tasa de aplicaciones con diseño responsivo son bajas en portales
web de gran contenido, como los sitios web de e-commerce. Porque el principio básico
del diseño responsivo es brindar a los usuarios el mismo contenido en el distinto tipo de
dispositivos, y muchos de estos sitios eliminan contenido para dispositivos que cuentan
con baja resolución.
27
6. ALCANCES Y LIMITACIONES
6.1 ALCANCES
El alcance de la pasantía se basa en la construcción de una aplicación móvil
multiplataforma de mensajería instantánea, teniendo como base el portal web para agentes
empresariales luego pretende ser extendida a otros dispositivos y tipos de plataforma (Windows,
OSX, Linux).
Se planteará la arquitectura de la aplicación de mensajería instantánea para agentes
empresariales y se realizará la documentación pertinente para explicar de manera general la
arquitectura planteada.
Teniendo en cuenta que la estrategia del proyecto esta enfocada en mejorar la experiencia
de usuario de los agentes empresariales, se construirá una aplicación web que pretende ser
extendida a dispositivos móviles y a plataformas de escritorio y a su vez establecer una
arquitectura que permita solventar los problemas de soporte actuales de la plataforma web para
agentes empresariales.
6.2 LIMITACIONES
El proyecto no pretende extenderse hasta la infraestructura del backend (Servidores de
base de datos, servidores de mensajería instantánea, Servidores de automatización de procesos,
etc.), debido a que esta infraestructura ya está establecida.
La aplicación en sus inicios tendrá como plataformas objetivo los dispositivos móviles
basados en IOs y Android, seguido de plataformas de escritorio (Windows, MacOS), dejando por
fuera plataformas como Windows Phone, Firefox OS, Linux, entre otras.
28
La documentación que se realizara para el proyecto solo comprende mockups para la
parte visual de la aplicación de mensajería instantánea, y algunos diagramas que permitan
entender la funcionalidad y arquitectura de la aplicación de una manera general.
Las pruebas unitarias y de integración que se realizaran a lo largo del proyecto pretenden
cubrir funcionalidades generales de algunos componentes clave dentro de la aplicación, esto
quiere decir que algunos componentes no tendrán pruebas unitarias debido a que sus
funcionalidades son básicas y no requieren validación, estas pruebas pueden ser automatizadas o
manuales.
29
7. METODOLOGÍA
Scrum es una metodología ágil que cual cuenta con pequeños ciclos de desarrollo
conocidos como “Sprints”, a continuación se especifican las fases que se definen cada Sprint
según (Trigas Gallego & Domingo Troncho, s. f.):
1. Concepto: Se define de forma general las características del producto y se asigna el
equipo que se encargará de su desarrollo.
2. Especulación: En esta fase se hacen disposiciones con la información obtenida y se
establecen los límites que marcarán el desarrollo del producto. Esta fase consiste
específicamente en:
a. Desarrollar y revisar los requisitos generales
b. Mantener la lista de las funcionalidades que se esperan.
c. Plan de entrega. Se establecen las fechas de las versiones, hitos e iteraciones.
3. Exploración: Se incrementa el producto en el que se añaden las funcionalidades de la fase
de especulación.
4. Revisión: El equipo revisa todo lo que se ha construido y se contrasta con el objetivo
deseado.
5. Cierre: Se entregará en la fecha acordada una versión del producto deseado.
Scrum gestiona estas iteraciones a través de reuniones diarias, uno de los elementos
fundamentales de esta metodología.
A continuación se definen los elementos de la metodología Scrum según (Trigas Gallego
& Domingo Troncho, s. f.):
- Product Backlog: La lista de necesidades del cliente
- Sprint Backlog: Lista de tareas que se realizan en un Sprint
- Incremento: Parte añadida o desarrollada en un Sprint, es una parte terminada y
totalmente operativa.
30
El Product Backlog está compuesto por historias de usuario, las cuales son descripciones
de las funcionalidades que va a tener el software. Las historias de usuario serán el resultado de la
colaboración entre el cliente y el equipo, e irán evolucionando durante toda la vida del proyecto.
Las historias de usuario se componen de tres fases denominadas “las 3 C”:
- Card: Será una breve descripción escrita que servirá como recordatorio.
- Conversation: Es una conversación que servirá para asegurarse que se ha entendido bien
todo y concretar el objetivo.
- Confirmation: Tests funcionales para fijar detalles que sean relevantes e indicar cuál va a
ser el límite.
Existen historias de usuario “grandes”, por su tamaño (puntos) y/o dedicación (horas),
estas son conocidas como épicas. Las épicas proporcionan una visión de alto nivel, son valiosas
para la planificación inicial del sistema y generalmente incluyen trabajo para varias iteraciones,
estas deben ser divididas en historias de usuario más pequeñas(«Formación “user stories” biko -
mayo 2011», 03:52:44 UTC).
A continuación se presentan las fases a seguir a lo largo del proyecto.
• Investigación sobre los distintos frameworks que se ajustan a las necesidades del proyecto
y establecimiento de arquitectura
• Diseño de mockups gráficos de la plataforma (Maquetado)
• Diseño del core de la plataforma (lógica) y diseño de pruebas
• Desarrollo de las vistas de la aplicación
• Desarrollo del core (lógica) de la aplicación
Las dos últimas fases, correspondientes al desarrollo, tendrán de base a SCRUM como
metodología, las demás fases se pretenden abordar según lo presentado en el cronograma del
proyecto.
31
El product Backlog que se presenta a continuación presenta épicas que luego serán
descompuestas en tareas más pequeñas de acuerdo a lo establecido por la metodología.
• Desarrollo de vistas del proceso de registro (on-boarding)
• Desarrollo de vista de conversaciones activas
• Desarrollo de vista de conversaciones pendientes
• Desarrollo de vista de contactos
• Desarrollo de vista del chat
• Desarrollo de vista de analíticas
• Desarrollo del módulo de mensajería
• Desarrollo del módulo de contactos
• Desarrollo del módulo de administración de empresa
• Desarrollo del módulo de analíticas
El manejo del backlog del proyecto será manejado a través de la aplicación web
Trello(«Trello», s. f.), esta será supervisada por varios miembros del equipo de Twnel, el director
externo será el Scrum Master a lo largo del proceso, Además se incluirán las respectivas pruebas
de cada componente desarrollado a lo largo de cada sprint.
Se definen sprints con duración de 2 semanas de acuerdo a las recomendaciones del
equipo de trabajo. Además se realizaran revisiones periódicas (Daily Scrum Meeting) cada 2-3
días vía Google hangouts y Slack, Con la finalidad de informar al equipo de trabajo el progreso,
trabajo próximo y problemas presentados a lo largo del periodo de trabajo.
32
8. DESARROLLO DE APLICACIÓN MOVIL MULTIPLATAFORMA DE
MENSAJERIA INSTANTANEA PARA AGENTES EMPRESARIALES
8.1 INVESTIGACION INICIAL
A continuación se describen las librerías utilizadas en la implementación del cliente web
de mensajería instantánea para agentes empresariales
FLUX
FLUX es una arquitectura propuesta por Facebook, sin embargo ellos proponen su propia
librería para implementar dicha arquitectura, a continuación se hace una descripción breve del
por que se hace uso de FLUX y no de un framework como AngularJS o EmberJS, los cuales
implementan una arquitectura MVC.
A continuación se presenta un modelo que describe la arquitectura MVC.
Imagen 1 - Modelo arquitectura MVC con una vista - Fuente: (CostaRicaJS, s. f.)
A medida que se agregan más controladores, modelos y vistas las dependencias se
vuelven más complejas
33
Imagen 2 - Modelo arquitectura MVC con mas de una vista – Fuente: (CostaRicaJS, s. f.)
Es por esto que se opta por emplear una arquitectura diferente para la construcción del
cliente web, en este caso una arquitectura que emplee flujo de datos unidireccional a diferencia
del flujo bidireccional que ofrece MVC, esta arquitectura es FLUX.
FLUX es una arquitectura para aplicaciones que corren en el cliente diseñada por
Facebook junto con ReactJS, la librería para vistas. La principal diferencia de Flux con MVC es
que las vistas no modifican datos directamente, todas las modificaciones de datos son hechas a
través de eventos que disparan Acciones.
34
A continuación se presenta un diagrama que explica el modelo de la arquitectura FLUX.
Imagen 3 - Modelo arquitectura FLUX
sencillo – Fuente: («Flux | Application Architecture for Building User Interfaces», s. f.)
Una razón de peso para usar Flux puede ser evitar el manejo de imperativo de estados del
UI cuando los datos de la aplicación han cambiado. (Por ejemplo cuando se elimina una tarea de
la lista de tareas por hacer de una aplicación, va a ser una molestia si debo actualizar
imperativamente el estado en otros lugares de la aplicación, como el contador de tareas y la
misma lista de tareas).
Además el flujo de datos es simple y claro, los cambios de estado son explícitos, las partes
están desacopladas y encapsuladas (Los stores empujan el estado a las vistas, estas genera
acciones que los stores escuchan; ninguno sabe del funcionamiento interno del otro). («ReactJS,
la biblioteca JavaScript para ‘front--end’ desarrollada por Facebook», s. f.)
35
A diferencia de MVC el flujo de datos unidireccional presentado por flux permite
disminuir la complejidad de la aplicación, como se muestra a continuación.
Imagen 4 - Modelo arquitectura FLUX con mas de una vista – Fuente: (Costarías, s. f.)
REACTJS
ReactJS es una librería para crear componentes de UI, esta librería fue creada por
Facebook y propuesta a su vez con la arquitectura FLUX, ReactJS no es un framework. Una de
las características sobresalientes de ReactJS es que abstrae la API de render nativa (DOM
Virtual), lo cual permite que se actualicen los nodos del DOM que necesitan actualizarse y no
actualice aquellos nodos que no sufrieron algún cambio, a diferencia de la forma en que
frameworks como AngularJS o EmberJS realizan su renderizado de DOM.
36
8.1.2.1 Ventajas
- Componentes declarativos y reutilizables
- Encapsulación y separación de preocupaciones
- API compacta
- Curva de aprendizaje muy corta
- Flujo de datos simple y claro, saber en qué estado se encuentra, saber de dónde
vienen los datos.
- Desacoplamiento e incremento de cohesión utilizando un modelo de componentes
(«javascript - Pros and Cons of Facebook’s React vs. Web Components (Polymer) -
Programmers Stack Exchange», s. f.)
- Virtual DOM (Aumento en el performance de las aplicaciones construidas)
- Renderizado del lado del servidor
- («What are the pros and cons of React.js and Flux? Are they the future of front-
end development? - Quora», s. f.)
8.1.2.2 Desventajas
- No es un framework, es una librería.
- Para crear web componentes hay que detallar demasiado, a diferencia de hacerlo
con HTML y JS Puro.
- La integración de ReactJS en una arquitectura MVC requiere de configuración que
puede llegar a ser tediosa.(Este no es caso de preocupación debido a que la
arquitectura del cliente para empresas tiene una arquitectura FLUX)
- Va en contra de lo propuesto por la Open Web (Web Components), ReactJS obliga
a usar JSX y virtual DOM a la vez, además ReactJS permite la creación de
componentes web que a la final limitan el uso de estos a aplicaciones que utilicen
ReactJS, es decir no promueve el uso de Web Components libres de cualquier
framework. («Panda Strike: React Is A Terrible Idea», s. f.) (A pesar de que los
componentes estén ligados a ReactJS, siguen haciendo que el acoplamiento de la
aplicación sea mínimo debido a la encapsulación e independencia de cada uno de
37
los componentes que se crean, además el Virtual DOM que ofrece ReactJS es algo
que vale la pena aprovechar )
REACTJS NATIVE
ReactJS Native es una extensión de ReactJS que permite crear componentes de UI nativos
para dispositivos móviles, se tiene en cuenta para la realización del cliente móvil para agentes
empresariales en un futuro. Las ventajas que presenta dicha librería son las mismas que presenta
ReactJS, además de las siguientes:
- La lógica de la aplicación es escrita en javascript, y el u de la misma es nativo
- La interfaz de usuario es expresada en función del estado de la aplicación
React Native no es una herramienta que apunte a aplicaciones multi plataforma, es decir
no apunta a write-once run-anywere (escribir una vez y corre donde sea), react native apunta a
learn-once write-anywere (aprende una vez y escribe donde sea) («React Native», s. f.)
CROSS PLATFORM FRAMEWORKS
Debido a que se prevé el uso del cliente para agentes como aplicación de escritorio, se
tienen en cuenta los Cross plattform frameworks, frameworks que permiten portar aplicaciones
web a plataformas de escritorio. A continuación se hace una descripción de las que se tuvieron en
cuenta para dicha implementación.
8.1.4.1 Appjs
Se tuvo en consideración debido a que es el que tiene mas trayectoria, sin embargo no es
aconsejable para proyectos nuevos debido a que la comunidad ha dejado de dar soporte desde
hace algunos años (dos años aproximadamente), cuenta con soporte para crear aplicaciones para
Windows, MAC y Linux con Javascript, HTML5 y CSS.
38
8.1.4.2 NW.js (node-webkit)
Este es uno de los mas populares y maduros, tiene gran soporte por la comunidad, permite
portar aplicaciones creadas con tecnologías web como HTML, JS y CSS a plataformas como
Windows, MAC y Linux; a pesar de tener características a favor su uso no es tan sencillo y
existen otros frameworks mas sencillos.
8.1.4.3 Electron
Es el mas popular de todos, fue construido inicialmente para el editor atom de Github,
además es menos complejo a la hora de la construcción en comparación a NW.js (Usa una
librería para acceder al API de chromium mientras que NW necesita construir chromium),
Simplifica varios procesos de NW.js.
En la actualidad es usado en varios proyectos, como el ya mencionado editor Atom de
Github, Slack, VisualStudio Code, Mapbox y otros. («NW.js and Electron.js: Web Technology
on the Desktop | Tivix», s. f.)
39
8.2 ARQUITECTURA
A continuación se presentan diagramas que se consideraron esenciales para la explicación
de la arquitectura empresarial y del cliente de mensajería instantánea, teniendo en cuenta
generalidades de cada una de las capas propuestas por el estándar TOGAF y OpenGroup («The
Open Group ArchiMate® Forum Landing Page | The Open Group», s. f.) , ademas dejando
descrito de manera parcial estructura de la organización, el cliente móvil (Personas) e
infraestructura de todo el negocio (Backend).
CAPA DE NEGOCIO
8.2.1.1 Organización
El punto de vista de organización pretende mostrar la estructura interna de la
organización, el Diagrama 1 - Metamodelo vista de organización, presenta el metamodelo
definido por el estandar OpenGroup para el presente punto de vista , el Diagrama 2 - Modelo
vista de organización, presenta la estructura interna de organización de Twnel Inc.
• Meta modelo
Diagrama 1 - Metamodelo vista de organización
– Fuente: Documentación Colosoft
40
• Modelo
Diagrama 2 - Modelo vista de organización
– Fuente: El Autor
41
8.2.1.2 Cooperación de actor
El punto de vista de cooperación de actor presenta las relaciones entre los actores de
negocio, el Diagrama 3 - Metamodelo vista de cooperación de actor, presenta el metamodelo
definido por el OpenGroup para el presente punto de vista, y el Diagrama 4 – Modelo vista de
cooperación de actor, presenta las relaciones entre los actores de negocio de Twnel Inc.
• Metamodelo
Diagrama 3 - Metamodelo vista de cooperación de actor
– Fuente: Documentación Colosoft
42
• Modelo
Diagrama 4 – Modelo vista de cooperación de actor
– Fuente: El Autor
43
8.2.1.3 Función de negocio
El punto de vista de función de negocio muestra las principales funciones de negocio, el
Diagrama 5 - Metamodelo vista función de negocio, presenta el metamodelo definido por el
OpenGroup para el presente punto de vista, el Diagrama 6 - Modelo vista función de negocio,
presenta las principales funciones de negocio de Twnel Inc.
• Metamodelo
Diagrama 5 - Metamodelo vista función de negocio
– Fuente: Documentación Colosoft
• Modelo
Diagrama 6 - Modelo vista función de negocio
– Fuente: El Autor
44
8.2.1.4 Proceso de Negocio
El punto de vista de proceso de negocio es usado para mostrar la estructura a alto nivel y
composicion de uno o mas procesos de negocio, el Diagrama 7 - Metamodelo vista proceso de
negocio presenta el metamodelo planteado por el OpenGroup para el presente punto de vista, el
Diagrama 8 - Modelo vista proceso de negocio presenta la estructura a alto nivel del proceso de
negocio principal de Twnel Inc.
• Metamodelo
Diagrama 7 - Metamodelo vista proceso de negocio
– Fuente: Documentación Colosoft
45
• Modelo
Diagrama 8 - Modelo vista proceso de negocio – Fuente: El Autor
46
8.2.1.5 Producto
El punto de vista de producto representa el valor que los productos ofrecen a los clientes,
el Diagrama 9 - Metamodelo vista de producto presenta el metamodelo definido por el
openGroup para el presente punto de vista, el Diagrama 10 - Modelo vista de producto representa
el valor del cliente de mensajeria instantanea empresarial para las empresas que utilizan Twnel.
• Metamodelo
Diagrama 9 - Metamodelo vista de producto – Fuente: Documentación Colosoft
47
• Modelo
Diagrama 10 - Modelo vista de producto
– Fuente: El Autor
48
CAPA DE APLICACIÓN
8.2.2.1 Comportamiento de aplicación
El punto de vista de comportamiento de aplicación describe el comportamiento interno de
una aplicación,el Diagrama 11 - Metamodelo vista de comportamiento de aplicación presenta el
metamodelo planteado por el OpenGroup para el presente punto de vista, el Diagrama 12 -
Modelo vista de comportamiento de aplicación presenta el comportamiento interno del cliente de
mensajeria instantanea empresarial de Twnel.
• Metamodelo
Diagrama 11 - Metamodelo vista de comportamiento de aplicación – Fuente: Documentación Colosoft
49
• Modelo
Diagrama 12 - Modelo vista de comportamiento de aplicación – Fuente: El Autor
50
8.2.2.2 Cooperación de aplicación
El punto de vista de cooperación de aplicación describe la relación entre componentes de
aplicación en terminos de flujo de información entre ellos, el Diagrama 13 - Metamodelo vista de
cooperación de aplicación presenta el metamodelo definido por el OpenGroup para el presente
punto de vista, el Diagrama 14 - Modelo vista de cooperación de aplicación, describe la relación
entre componentes de aplicación del cliente de mensajeria instantanea empresarial con los
componentes principales de la infraestructura de Twnel.
• Metamodelo
Diagrama 13 - Metamodelo vista de cooperación de aplicación
– Fuente: Documentación Colosoft
51
• Modelo
Diagrama 14 - Modelo vista de cooperación de aplicación
– Fuente: El Autor
52
8.2.2.3 Estructura de aplicación
El punto de vista de estructura de aplicación muestra la estructura de una o mas
aplicaciones, el Diagrama 15 - Metamodelo vista de estructura de aplicación, muestra el
metamodelo definido por el OpenGroup para el presente punto de vista, el Diagrama 16 - Modelo
vista de estructura de aplicación, presenta la estructura de aplicación del cliente de mensajeria
instantanea en termino de sus componentes principales, interfaces y objetos de datos.
• Metamodelo
Diagrama 15 - Metamodelo vista de estructura de aplicación – Fuente: Documentación Colosoft
53
• Modelo
Diagrama 16 - Modelo vista de estructura de aplicación – Fuente: El Autor
54
8.2.2.4 Uso de la aplicación
El punto de vista de uso de la aplicación muestra como una o mas aplicaciones son usadas
para dar soporte a uno o mas procesos de negocio, el Diagrama 17 - Metamodelo vista de uso de
aplicación, presenta el metamodelo definido por el OpenGroup para el presente punto de vista, el
Diagrama 18 - Modelo vista de uso de aplicación, presenta como la colaboración entre dos de los
componentes lógicos mas importantes del cliente de mensajeria instantanea empresarial da
soporte al proceso de negocio principal de Twnel.
• Metamodelo
Diagrama 17 - Metamodelo vista de uso de aplicación
– Fuente: Documentación Colosoft
55
• Modelo
Diagrama 18 - Modelo vista de uso de aplicación
– Fuente: El Autor
56
CAPA DE INFRAESTRUCTURA
8.2.3.1 Infraestructura
El punto de vista de infraestructura muestra los elementos de infraestructura
(software/hardware) que dan soporte a la capa de aplicación, el Diagrama 19 - Metamodelo vista
de infraestructura, presenta el metamodelo definido por el OpenGroup para el presente punto de
vista, el Diagrama 20 - Modelo vista de infraestructura, presenta los elementos de infraestructura
que dan soporte al cliente de mensajeria instantanea empresarial de Twnel.
• Metamodelo
Diagrama 19 - Metamodelo vista de infraestructura
– Fuente: Documentación Colosoft
57
• Modelo
Diagrama 20 - Modelo vista de infraestructura – Fuente: El Autor
58
8.2.3.2 Uso de infraestructura
El punto de vista de uso de infraestructura muestra como las aplicaciones son soportadas
por elementos de infraestructura (software/hardware) , el Diagrama 21 - Metamodelo vista de uso
de infraestructura, presenta el metamodelo definido por el OpenGroup para el presente punto de
vista,el Diagrama 22 - Modelo vista de uso de infraestructura, presenta como los elementos de
infraestructura brindan servicios que son usados por dos de las funciones esenciales del cliente de
mensajeria instantanea empresarial de Twnel.
• Metamodelo
Diagrama 21 - Metamodelo vista de uso de infraestructura – Fuente: Documentación Colosoft
59
• Modelo
Diagrama 22 - Modelo vista de uso de infraestructura
– Fuente: El Autor
60
8.2.3.3 Estructura de información
El punto de vista de estructura de la información muestra la estructura de información
usada en un proceso especifico de aplicación o negocio, en el Diagrama 23 - Metamodelo vista
de estructura de información, se presenta el metamodelo planteado por el OpenGroup para el
presente punto de vista, el Diagrama 24 - Modelo vista de estructura de información, se muestra
como los objetos de datos de negocio se relacionan con los objetos de datos de aplicación dentro
del cliente de mensajeria instantanea empresarial de Twnel.
• Metamodelo
Diagrama 23 - Metamodelo vista de estructura de información
– Fuente: Documentación Colosoft
61
• Modelo
Diagrama 24 - Modelo vista de estructura de información
– Fuente: El Autor
62
8.2.3.4 Realización de servicio
El punto de vista de realización de servicio muestra como uno o mas servicios de negocio
son realizados por procesos subyacentes y algunas veces por componentes de aplicación, el
Diagrama 25 - Metamodelo vista de realización de servicio, muestra el metamodelo definido por
el OpenGroup para el presente punto de vista, el Diagrama 26 - Modelo realización de servicio
Realización de servicio, muestra como el servicio de negocio principal de Twnel es realizado por
dos de los componentes de aplicación principales del cliente de mensajeria empresarial Twnel.
• Metamodelo
Diagrama 25 - Metamodelo vista de realización de servicio
– Fuente: Documentación Colosoft
63
• Modelo
Diagrama 26 - Modelo realización de servicio Realización de servicio – Fuente: El Autor
64
8.2.3.5 Vista de Capas
El punto de vista de capas presenta un resumen de la relación entre las capas de negocio,
aplicación e infraestructura, el Diagrama 27 - Modelo vista de capas, muestra la relación entre los
elementos principales de las capas de negocio, aplicación e infraestructura de la arquitectura de
alto nivel de Twnel, teniendo en cuenta el cliente de mensajeria instantanea empresarial.
Diagrama 27 - Modelo vista de capas
– Fuente: El Autor
65
CAPA MOTIVACIONAL
8.2.4.1 Punto De Vista Stakeholder
El punto de vista de Stakeholder permite dar un vistazo general de cómo la organización
se relaciona con los stakeholders, en terminos de majeadores, valoraciones, objetivos y
stakeholders. El Diagrama 28 - Metamodelo vista de Stakeholder, muestra el metamodelo
definido por el OpenGroup para el presente punto de vista, el Diagrama 29 - Modelo vista de
Stakeholder, presenta de manera general la relación de Twnel con sus stakeholders.
• Metamodelo
Diagrama 28 - Metamodelo vista de Stakeholder
– Fuente: Documentación Colosoft
• Modelo
Diagrama 29 - Modelo vista de Stakeholder – Fuente: El Autor
66
8.2.4.2 Punto De Vista De Realización De Objetivos
El punto de vista de realización de objetivos permite al diseñador modelar al detalle a alto
nivel los objetivos de la organización. El Diagrama 30 - Metamodelo vista de realización de
objetivos presenta el metamodelo definido por el OpenGroup para el presente punto de vista, el
Diagrama 31 - Modelo vista de realización de objetivos presenta una aproximación de cómo
Twnel pretende lograr sus objetivos principales de acuerdo a su principio esencial.
• Metamodelo
Diagrama 30 - Metamodelo vista de realización de objetivos – Fuente: Documentación Colosoft
• Modelo
Diagrama 31 - Modelo vista de realización de objetivos – Fuente: El Autor
67
8.2.4.3 Punto De Vista De Contribución
El punto de vista de contribución permite al diseñador o analista modelar las relaciones de
influencia entre objetivos y requerimientos. El Diagrama 32 - Metamodelo vista de contribución,
presenta el metamodelo definido por el OpenGroup para el presente punto de vista, El Diagrama
33 - Modelo vista de contribución, presenta la influencia entre requerimientos y objetivos
prestados por los dos frentes de Twnel, cliente personas y cliente empresas en terminos de la
disponibilidad de recursos y el uso de estos.
• Metamodelo
Diagrama 32 - Metamodelo vista de contribución – Fuente: Documentación Colosoft
68
• Modelo
Diagrama 33 - Modelo vista de contribución – Fuente: El Autor
69
8.2.4.4 Punto De Vista De Principios
El punto de vista de principios permite al diseñador modelar los principios relevantes para
el problema a tratar, incluyendo los objetivos que motivan dichos principios. El Diagrama 34 -
Metamodelo vista de principios, muestra el metamodelo definido por el OpenGroup para el
presente punto de vista, el Diagrama 35 - Modelo vista de principios, muestra los principios
esenciales de Twnel y su objetivo principal a cumplir.
• Metamodelo
Diagrama 34 - Metamodelo vista de principios – Fuente: Documentación Colosoft
• Modelo
Diagrama 35 - Modelo vista de principios – Fuente: El Autor
70
8.2.4.5 Punto De Vista De Realización De Requerimientos
El punto de vista de realización de requerimientos premite al diseñador modelar la
realización de requermientos con la finalidad de alcanzar los objetivos de la organización. El
Diagrama 36 - Metamodelo vista de realización de requerimientos, muestra el metamodelo
definido por el OpenGroup para el presente punto de vista, el Diagrama 37 - Modelo vista de
realización de requerimientos presenta los requerimientos principales para la realización del
objetivo esencial de Twnel.
• Metamodelo
Diagrama 36 - Metamodelo vista de realización de requerimientos
– Fuente: Documentación Colosoft
71
• Modelo
Diagrama 37 - Modelo vista de realización de requerimientos – Fuente: El Autor
72
8.2.4.6 Punto De Vista De Motivación
El punto de vista de motivación pretende mostrar el aspecto motivacional de la
organización, relacionando stakeholders con sus principales objetivos. El Diagrama 38 -
Metamodelo vista de motivación, muestra el metamodelo definido por el OpenGroup para el
presente punto de vista, el Diagrama 39 - Modelo vista de motivación, presenta a Twnel como
participante, con sus respectivos objetivos y valoraciones asignados a dichos objetivos.
• Metamodelo
Diagrama 38 - Metamodelo vista de motivación – Fuente: Documentación Colosoft
73
• Modelo
Diagrama 39 - Modelo vista de motivación – Fuente: El Autor
74
CAPA DE IMPLEMENTACIÓN Y MIGRACIÓN
8.2.5.1 Punto De Vista De Proyecto
El punto de vista de proyecto en el presente contexto pretende mostrar los distintos
paquetes de trabajo de Twnel y como estos se relacionan con el objetivo principal de la
organización (Diagrama 41 - Modelo vista de proyecto), el Diagrama 40 - Metamodelo vista de
proyecto., muestra el metamodelo definido por el OpenGroup para el presente punto de vista
• Metamodelo
Diagrama 40 - Metamodelo vista de proyecto
– Fuente: Documentación Colosoft
75
• Modelo
Diagrama 41 - Modelo vista de proyecto – Fuente: El Autor
76
8.2.5.2 Punto De Vista De Migración
El punto de vista de migración pretende mostrar la transición específica desde una
arquitectura existente a una arquitectura deseada. El Diagrama 42 - Metamodelo vista de
migración, muestra el metamodelo definido por el OpenGroup para el presente punto de vista, el
Diagrama 43 - Modelo vista de migración, presenta la transición pretendida por el equipo Twnel
del cliente de mensajeria instantanea para agentes empresariales, dicha transición recalca en que
la arquitectura obtenida no eliminará a su predecesor, simplemente es una extensión.
• Metamodelo
Diagrama 42 - Metamodelo vista de migración – Fuente: Documentación Colosoft
• Modelo
Diagrama 43 - Modelo vista de migración – Fuente: El Autor
77
8.2.5.3 Punto De Vista De Migración E Implementación
El punto de vista de migración e implementación permite modelar el alcance de
programas, actividades de proyecto en terminos de plateas. El Diagrama 44 - Metamodelo vista
de migración e implementación, muestra el metamodelo definido por el OpenGroup para el
presente punto de vista, el Diagrama 45 - Modelo vista de migración e implementació presenta un
diagrama general concerniente a la capa de implementación y migración de la arquitectura de
Twnel, teniendo como referencia principal el cliente de mensajeria instantanea para agentes
empresariales.
• Metamodelo
Diagrama 44 - Metamodelo vista de migración e implementación – Fuente: Documentación Colosoft
78
• Modelo
Diagrama 45 - Modelo vista de migración e implementación – Fuente: El Autor
79
ARQUITECTURA FLUX
El Diagrama 46 – Arquitectura FLUX, presenta la arquitectura a nivel de aplicación de
manera mas detallada, teniendo en cuenta capas adicionales a la capa lógica, dichas capas
componen la estructura básica de la arquitectura FLUX (componentes de UI, stores, dispatcher,
acciones).
80
Diagrama 46 – Arquitectura FLUX
– Fuente: El Autor
81
8.3 DESARROLLO DEL CLIENTE DE MENSAJERIA INSTANTANEA
La arquitectura del cliente web esta compuesta por varias capas, tres de las cuales están
definidas por FLUX como tal (componentes, sores, acciones, dispatcher) y una capa adicional
referente a componentes lógicos, tal como se puede observar en el Diagrama 46 – Arquitectura
FLUX.
COMPONENTES UI
Dentro de la arquitectura FLUX los componentes principales son conocidos como View
Controllers, estos componentes son aquellos que se comunican directamente con el store y pasan
a sus subcomponentes dichos datos obtenidos del store vía props (propiedades), cada view
controller tiene asociadas sus respectivas acciones y su store correspondiente, según lo definido
en la arquitectura FLUX.
A continuación se describen los view controllers de la aplicación
8.3.1.1 CHATS
Este view controller es el encargado de mostrar la ventana de conversaciones pendientes y
conversación activa
8.3.1.2 BROADCASTS
Este view controller es el encargado de mostrar el historial de broadcasts enviados y el
componente que permite enviar broadcasts de acuerdo a las preferencias del usuario.
8.3.1.3 SETTINGS
Es el view controller que permite la administración de agentes, gags, códigos de
invitación e información básica de la empresa activa.
82
8.3.1.4 CONTACTS
Permite revisar el listado de contactos agregados por la empresa y agregar un solo
contactos o un grupo de contactos a partir de un archivo CSV.
SUBCOMPONENTES
A continuación se describen subcomponentes generales creados para la aplicación y que
fueron fundamentales para el funcionamiento de la plataforma
8.3.2.1 FILE INPUT
Un componente general utilizado por varios view controllers dentro del cliente web, tales
como Settings (carga de imagen de la empresa), Broadcasts y chats (envío de mensajes con
Imágenes, videos y audio)
8.3.2.2 TAG INPUT
Componente que permite agregar etiquetas y sugerir al usuario las etiquetas previamente
establecidas, dichas recomendaciones se pasan al componente vía props.
8.3.2.3 PHONE NUMBER INPUT
Componente que tiene la funcionalidad de verificar si un numero ingresado es valido de
acuerdo a la selección previa de un código de país
COMPONENTES LÓGICOS
A continuación se describe la funcionalidad general de cada uno de los componentes
lógicos creados, para un mayor detalle se invita al lector a revisar la sección de pruebas (TDD).
8.3.3.1 API
Este componente es el encargado de comunicarse con el API de Twnel, esta subdividido
en varios sub-módulos, encargados de realizar acciones de actualización y lectura
correspondientes al modelo designado, estos sub-módulos son: Conversations, Contacts,
Messages, Conversations.
83
Existe un sub-módulo adicional dentro de API, este es el modulo HTTPHandler, el cual
permite a los otros sub-módulos realizar consultas HTTP.
8.3.3.2 COUNTRIES
Modulo encargado de manejo de formatos de números telefónicos, códigos de país y
validación de números de acuerdo a código de país
8.3.3.3 DATA
Modulo intermediario, encargado de pasar datos a los stores de la arquitectura FLUX
provenientes desde el modulo API y Socket.
8.3.3.4 MEDIA
Modulo encargado de la interacción con S3 de Amazon, subida y bajada de archivos de
media (Imágenes, Audio, Video)
8.3.3.5 MODELS
Modulo encargado de la traducción de datos de tipo API (Respuestas del backend) a
objetos de aplicación.
8.3.3.6 SOCKET
Modulo encargado de establecimiento de conexión del webSocket, recepción y envío de
mensajes.
PRUEBAS (TDD)
Se tomo el desarrollo guiado por pruebas (TDD de sus siglas en ingles) como pilar
fundamental en el desarrollo de los componentes lógicos de la aplicación en general, dicho
enfoque fue posible gracias a el uso de MochaJS, framework de pruebas que permite aplicar
dicho enfoque en la creación de software con javascript, específicamente en aplicaciones creadas
con NodeJS.(«Mocha - the fun, simple, flexible JavaScript test framework», s. f.).
84
A continuación se hará un listado breve de las pruebas implementadas en cada uno de los
componentes lógicos de la aplicación.
8.3.4.1 Pruebas del módulo API
• Sub-módulo Contacts
o Debería obtener los contactos de la empresa deseada
o Debería registrar contactos de la empresa deseada
o Debería actualizar los contactos de la empresa deseada
o Debería eliminar contactos de la empresa deseada
• Sub-módulo CompanyInfo
o Debería obtener la información básica de la empresa
o Debería actualizar la información básica de la empresa
o Debería actualizar extensiones de la empresa
o Debería actualizar la imagen de la empresa
o Debería obtener las etiquetas de la empresa
o Debería obtener los códigos de invitación de la empresa
o Debería actualizar los códigos de invitación de la empresa
o Debería obtener agentes de la empresa
o Debería actualizar agentes de la empresa
• Sub-módulo Messages
o Debería cargar los mensajes de difusión (Broadcasts)
o Debería enviar un mensaje de difusión (Broadacast)
o Debería enviar un mensaje de media (Imagen, video, audio)
o Debería cargar mensajes de una conversación
• Sub-módulo Conversations
o Debería cargar conversaciones
o Debería crear conversaciones
85
o Debería predecir alcance de mensajes de difusión (Broadcast)
8.3.4.2 Pruebas del módulo Countries
• Debería retornar el listado de países
• Debería retornar los países mas usados
• Debería sugerir el país del cliente
• Debería validar los números telefónicos
8.3.4.3 Pruebas del módulo DataHandler
• Debería inicializarse si no hay datos presentes
• Debería cargar los datos y conectarse con el socket
• Sub-módulo SessionHandler
o Debería establecer los datos de sesión
o Debería obtener los datos de sesión
o Debería decir si hay o no datos de sesión
o Debería borrar datos de sesión
o Los datos deberían expirar y el tiempo de expiración debería ser establecido
o El tiempo de expiración debería ser actualizado
o El tiempo de expiración podría ser deshabilitado
8.3.4.4 Pruebas del Modulo Media
• Sub-módulo FileHandler
o Debería subir/descargar archivos de imagen
o Debería subir/descargar archivos de audio
o Debería subir/descargar archivos de video
• Sub-módulo MediaCache
o Debería insertar y obtener archivos de video
o Debería insertar y obtener archivos de audio
o Debería insertar y obtener archivos de imagen
o Debería hacer espacio cuando este lleno
86
8.3.4.5 Pruebas del módulo Models
• Inicialización correcta del objeto Agent
• Inicialización correcta del objeto Broadcast Message
• Inicialización correcta del objeto Company
• Inicialización correcta del objeto Customer
• Inicialización correcta del objeto Conversation
• Inicialización correcta del objeto Message
8.3.4.6 Pruebas del módulo Socket
• Debería conectar con el servidor
• Debería reservar una conversación
• Debería archivar una conversación
• Debería enviar mensajes
• Debería desconectarse del servidor
LIBRERIAS Y HERRAMIENTAS UTILIZADAS
Para la implementación del cliente web empresarial de Twnel se utilizaron varias librerías
y frameworks base, entre ellos cabe destacar los siguientes:
• NodeJS: Entorno en tiempo de ejecución para la construcción de aplicaciones con
javascript
• Browserify: Librería para construcción de paquetes teniendo en cuenta el árbol de
dependencias
• Envify: Librería para el manejo de variables de entorno
• Reactify: Librería para la traducción de notación JSX (propia de componentes de
ReactJS) a Javascript
• FLUX: Librería para la implementación de arquitectura FLUX
• ReactJS: Librería para construcción de componentes de UI
87
• ReactDOM: Interacción con el DOM de HTML para componentes de ReactJS
• MochaJS: Framework de pruebas
• SocketIO: Librería para establecer conexión a través de Websocket
• Watchify : Librería encargada de realizar operaciones de acuerdo a cuando hay un
cambio en algún archivo, por ejemplo, hacer la compilación de archivos .less en hojas de
estilo CSS.
8.4 CRONOGRAMA OBTENIDO
Se hicieron cambios en el cronograma, optando por crear una versión web del cliente que
extienda luego a una versión de escritorio, esto se debe a la demanda de las empresas que utilizan
Twnel y a problemas de performance con el cliente actual. Además se presentaron adiciones en
cuanto al personal humano que pretendían aumentar la velocidad de desarrollo del cliente pero
terminaron retrasándolo debido a eventualidades relacionadas con otros frentes de Twnel
(Infraestructura). Además de tratar de hacer catch up del cliente actual con los nuevos features
incluidos, por ejemplo el manejo de tags de agentes , faqs y autoresponders.
88
Tabla 1 - Cronograma obtenido - Fuente: El Autor
89
8.5 METODOLOGIA
SPRINTS
Cada sprint dentro del proyecto tiene una duración de una semana, a continuación se
listan las tareas realizadas desde el momento en el que comenzó la implementación del mismo.
- FrontEnd Developer -> Jobelo Andrés Quintero Rodríguez
- Backend Developer -> Ericson Cepeda
- Project Manager -> Santiago Castillo
• Sprint #1 (5/10/2015 -12/10/2015)
FrontEnd Developer
- Implementación inicial del modulo/pruebas communicationHandler
Project Manager
- Implementación inicial del modulo/pruebas mediaHandler
- Implementación inicial del modulo/pruebas MixedUtilities
- Implementación inicial del modulo/pruebas CountryCodes
Sprint #2 (12/10/2015-19/10/2015)
FrontEnd Developer
- Ajustes implementación del modulo/pruebas communicationHandler
- Implementación del sub-módulo/pruebas pingHandler
- Implementación de conversationHandler
- Implementación de métodos/pruebas para la recepción y envío de mensajes
Project Manager
- Implementación inicial del modulo/pruebas de navegación
Sprint #3(19/10/2015-26/10/2015)
FrontEnd Developer
- Implementación inicial del componente Broadcasts (Estructura)
- Implementación del subcomponente BroadcastHistory
90
- Implementación del subcomponente BroadcastHistoryList
- Implementación del subcomponente BroadcastsNavbar
- Implementación del subcomponente MessagePreview
- Implementación del subcomponente SendMessageBox
- Implementación del subcomponente WriteMessageBox
• Sprint #4 (26/10/2015-02/11/2015)
FrontEnd Developer
- Implementación inicial de appDispatcher
- Implementación de Broadcasts store y acciones
- Integración de flujo de datos store/acciones componente Broadcasts
• Sprint #5(02/11/2015-09/11/2015)
FrontEnd Developer
- Refactorización de subcomponentes de Broadcasts (Props/state)
- Implementación de componente general FileInput
- Renderizacion de mensajes con imagen de Broadcast
• Sprint #6 (09/11/2015-16/11/2015)
FrontEnd Developer
- Extensión de funcionalidad de subcomponente MessagePreview (Audio)
- Refactorización de Subcomponente BroadcastHistory (Eventos)
- Refactorización de flujo de datos en componente Broadcast (Instancia de BroadcastStore
únicamente en componente padre)
Project Manager
- Implementación de modulo SessionHandler
- Integración de modulo SessionHandler con modulo de navegación
• Sprint #7 (16/11/2015-23/11/2015)
FrontEnd Developer
- Implementación de estructura base de componente Contacts
91
- Implementación de contactsStore
- Implementación de contactsActions
Project Manager
- Implementación de estructura base de componente Chats
• Sprint #8 (30/11/2015-07/12/2015)
FrontEnd Developer
- Implementación de CompanyActions (Acciones básicas)
- Implementación de CompanyStore (Códigos de invitación, tags, información básica)
- Implementación de componente general TagInput
- Refactorización de subcomponente contactRegister
• Sprint #9 (07/12/2015-14/12/2015)
FrontEnd Developer
- Implementación de característica en componente Contacts (poder registrar contactos a
partir de un archivo CSV)
- Refactorización de flujo de datos y eventos en componente TagInput
• Sprint #10 (14/12/2015-21/12/2015)
FrontEnd Developer
- Ajustes del componente TagInput (Sugerencias)
- Implementación inicial del componente Settings
- Ajustes de navegación dentro del componente Settings
- Implementación de subcomponente Agents (componente Settings)
- Implementación de subcomponente BasicInfo (componente Settings)
- Implementación de componente general PhoneNumber
92
• Sprint #11 (21/12/2015-28/12/2015)
FrontEnd Developer
- Ajustes en el subcomponente Agents (atributos isAdmin, agregar agente, cambio de flujo
de datos state -> props)
- Creación de gulpfile para stylus
• Sprint #12 (04/01/2016-11/01/2016)
FrontEnd Developer
- Layout inicial de aplicación (CSS)
o Settings
o Chats
o Contacts
- Implementación de paginación en listado de contactos e historial de broadcasts
BackEnd Developer
- Implementación inicial del modulo intermediario
o Conversations
o Contacts
o Messages
o Companies
Project Manager
- Ajustes en el modulo de navegación (Permitir navegar en árbol de mas de dos niveles)
• Sprint #13 (11/01/2016-18/01/2016)
FrontEnd Developer
- Refactorización de flujo de datos dentro del componente Contacts
- Refactorización de flujo de datos relacionados con códigos de invitación de empresa y
paginación
93
• Sprint #14 (18/01/2016-25/01/2016)
FrontEnd Developer
- Implementación de subcomponente TagsList
- Refactorización de flujo de datos relacionados con tags de empresa
- Corrección de flujo de datos cuando un objeto es eliminado en la sección de settings (tags,
invitationCodes, contacts)
• Sprint #15 (25/01/2016-01/02/2016)
FrontEnd Developer
- Implementación de sub-módulo/pruebas contacts (Intermediary)
- Ajustes en sub-módulo Models relacionados con el modelo contacto
Project Manager
- Refactorización del modulo Intermediary (Estructura general)
- Implementación de sub-módulo httpHandler (Intermediary)
• Sprint #16 (01/02/2016-08/02/2016)
FrontEnd Developer
- Ajustes en sub-módulo Models relacionados con el modelo agente
- Ajustes en sub-módulo Models relacionados con el modelo empresa
- Refactorización de sub-módulo companies de Intermediary (Partición en sub-módulos de
acuerdo a sus responsabilidades: BasicInfo, Contacts, Agents)
• Sprint #17 (08/02/2016-15/02/2016)
FrontEnd Developer
- Ajustes en sub-módulo httpHandler (Intermediary)
- Implementación de sub-módulos Messages y conversations (Intermediary)
94
• Sprint #18 (15/02/2016-22/02/2016)
FrontEnd Developer
- Ajustes en modelo Message
- Ajustes en modelo Conversation
- Pruebas de modelos Conversation y Message
Project Manager
- Implementación de componente pantalla de carga (Loading)
- Ajustes en el SessionStore
• Sprint #19 (22/02/2016-29/02/2016)
FrontEnd Developer
- Ajustes en el modulo intermediario (API)
o Creación, actualización de contactos
o Creación, actualización de tags de empresa
o Creación, actualización de códigos de invitación
Project Manager
- Implementación del LoadingStore
• Sprint #20 (29/02/2016-07/03/2016)
FrontEnd Developer
- Complementación de pruebas del modelo Agent
- Ajustes en modelos
o Conversation
o Message
o Customer
o Broadcast
- Refactorización y cambio de nombre del modulo intermediary a API
95
Project Manager
- Extensión de funcionalidad del modulo DataHandler
o Obtención de mensajes
o Obtención de listado de conversaciones
- Integración del loadingStore
• Sprint #21 (07/03/2016-14/03/2016)
FrontEnd Developer
- Integración del nuevo flujo de API y DataHandler
Project Manager
- Ajustes en el modulo comunicationHandler
- Exposición de servicios del dataHandler
• Sprint #22 (28/03/2016-04/04/2016)
FrontEnd Developer
- Integración del nuevo flujo de API y DataHandler
- Refactorización en el flujo de datos del componente Chats (viewController)
• Sprint #23 (04/04/2016-11/04/2016)
FrontEnd Developer
- Integración del nuevo flujo de API y DataHandler
Project Manager
- Implementación de carga inteligente de mensajes
- Implementación de carga inteligente de conversaciones
- Complementación de funcionalidad de modulo DataHandler
• Sprint #24 (11/04/2016-18/04/2016)
FrontEnd Developer
- Implementación de flujo de carga de mensajes previos
96
- Ajustes en funcionalidad del componente de Chats
o Implementación/Ajustes de subcomponente MessageRenderer
Project Manager
- Complementación de UI de componente de carga (Loading)
- Ajustes en la carga y envío de mensajes en DataHandler
- Integración de LESS y eliminación de Stylus como compilador CSS
• Sprint #25 (18/04/2016-25/04/2016)
FrontEnd Developer
o Integración de componentes (MessagesRenderer y MessageComponent)
o Ajustes de UI en pantalla de chats
Project Manager
- Creación de componente Message
- Complementación de funcionalidad del componente message
o Hallar altura con base en el tipo de mensaje y/o texto
Con la finalidad de visualizar de manera mas profunda los resultados de los sprints anteriormente
descritos, se invita al lector a consultar el anexo 3 – manual de usuario del cliente de mensajería
instantánea, además de consultar el sitio de pruebas donde se encuentra alojada la aplicación,
http://twnel.io.s3-website-us-west-2.amazonaws.com
97
8.6 INCONVENIENTES
• Estimación de tiempo errada del proyecto debido al uso de una herramienta nueva,
ReactJS y la arquitectura FLUX, se presentaron inconvenientes debido al flujo de
datos en FLUX y la familiarización del equipo con ReactJS para la creación de
componentes.
• Uno de los miembros del equipo incluyo el uso de coffee script para la realización
de uno de los módulos core del proyecto, esto desencadeno retrasos debido a que
los demás miembros del equipo no estaban familiarizados con dicho lenguaje.
• La asignación de un modulo fundamental a uno de los miembros encargados de
infraestructura se reflejo en retraso del proyecto, debido a que se formó un cuello
de botella que no permitía al equipo avanzar, ya que dicho miembro tuvo
problemas que solucionar relacionados con la infraestructura actual de Twnel.
98
9. TRABAJOS FUTUROS
El presente proyecto estableció la arquitectura para la extensión a otras plataformas, el
paso a seguir luego de la realización de la presente aplicación (WEB), es la extensión de la
misma a plataformas de escritorio a la par con el cliente móvil, los componentes lógicos, acciones
y stores propios de FLUX están construidos para que dicha extensión sea posible sin tener que
modificar la presente lógica en el flujo de datos y estructura de aplicación.
10. CONCLUSIONES
Como resultado del presente proyecto, es posible concluir que el uso de una arquitectura
unidireccional permite la detección de errores de una manera mas fácil a diferencia de una
arquitectura bidireccional (MVC). Además se hace evidente la mejora de performance debido al
virtualDOM brindado por ReactJS y la omisión del two-way-data-binding brindado por
AngularJS.
De la investigación inicial realizada en la que se pretendía evaluar los diversos
frameworks, arquitecturas y librerías que permitirían abordar el proyecto de la mejor manera, se
concluyó que la arquitectura FLUX y el uso de ReactJS eran la mejor opción.
Los requerimientos propuestos desde el inicio para el cliente web de mensajería
instantánea para agentes empresariales son los mismos que se pretenden cubrir en las versiones
del mismo para las demás plataformas (Escritorio y móviles), dichos requisitos fueron propuestos
a lo largo de cada sprint, cada una de las actividades realizadas dentro de estos pretendían abordar
dichos requisitos.
A lo largo del proyecto se documentó de diversas maneras cada uno de los componentes
creados, una de estas formas fue haciendo uso de archivos README.md dentro del repositorio
alojado en github, y otra manera fue la creación de diagramas en archimate y el modelo de la
arquitectura FLUX, obteniendo como resultado que la mejor manera de documentar un proyecto
99
para un equipo de desarrollo es el README.md y para alguien que quiera entender la
arquitectura de manera general el modelo de arquitectura FLUX.
La aplicación fue construida pensando en un diseño responsivo que permita al mismo ser
usado en dispositivos con resoluciones mínimas de 800 x 500 pixeles, dando soporte a ciertos
dispositivos móviles como tablets y IPADs, además los mockups creados sirvieron de carta guía
para dicho cometido, permitiendo así que los usuarios en un futuro puedan acceder desde
distintas plataformas al cliente web construido.
Por otro lado el enfoque ofrecido por FLUX y ReactJS, la construcción de componentes,
permitió desarrollar una aplicación con altos estándares en cuanto a desarrollo de software, los
componentes construidos son extensibles, reutilizables y desacoplados, además el flujo de datos
en la aplicación es claro, tiene baja complejidad y es fácil de depurar.
El desarrollo guiado por pruebas (TDD) permitió que el proyecto avanzara mas rápido de
lo esperado, teniendo en cuenta los percances presentados a lo largo del mismo, además de que
ayudo a que la escritura de código innecesario se redujera al mínimo, adicionalmente dar soporte
a la construcción de componentes de software de calidad.
El uso de SCRUM como metodología permitió que el desarrollo del proyecto fuese organizado,
claro y rápido, a pesar de los inconvenientes presentados, además se evidenció que el uso de esta
metodología permitía desde sus inicios contar con módulos/componentes funcionales.
El modelado de la arquitectura de la organización y proyecto sirvió como carta guía del cliente de
mensajería construido y los pasos a seguir en el futuro, tanto para la organización en general
como para el equipo de desarrollo.
Finalmente la versión actual de la aplicación construida, es una versión que cuenta con
todos los módulos lógicos establecidos en el diseño inicial, además de la vista principal (Chats)
con funcionalidad total y es posible utilizarla en dispositivos móviles que soporten mínimo una
resolución de 800 x 500 pixeles (Tablets y Ipads).
100
11. BIBLIOGRAFÍA
admin. (s. f.-a). About – The XMPP Standards Foundation. Recuperado a partir de
http://xmpp.org/about-xmpp/
admin. (s. f.-b). XMPP Technologies: BOSH – The XMPP Standards Foundation. Recuperado a
partir de http://xmpp.org/about-xmpp/technology-overview/bosh/
AngularJS — Superheroic JavaScript MVW Framework. (s. f.). Recuperado 8 de agosto de 2015,
a partir de https://angularjs.org/
Asier, A. (s. f.). Conceptos sobre APIs REST. Recuperado a partir de
http://asiermarques.com/2013/conceptos-sobre-apis-rest/
AWS | Amazon EC2 | Precios. (s. f.). Recuperado 15 de septiembre de 2015, a partir de
//aws.amazon.com/es/ec2/pricing/
Balasubramanee, V., Wimalasena, C., Singh, R., & Pierce, M. (2013). Twitter bootstrap and
AngularJS: Frontend frameworks to expedite science gateway development. En 2013
IEEE International Conference on Cluster Computing (CLUSTER) (pp. 1-1).
http://doi.org/10.1109/CLUSTER.2013.6702640
Colombia, tercer mercado latinoamericano en usuarios de smartphones | El País - Noticias de
Cali, Valle y Colombia. (s. f.). Recuperado 27 de agosto de 2015, a partir de
http://www.elpais.com.co/elpais/economia/noticias/colombia-tercer-mercado-
latinoamericano-usuarios-smartphones
CostaRicaJS. (s. f.). La Arquitectura Flux. Recuperado 25 de marzo de 2016, a partir de
http://costaricajs.co/2015/03/La-Arquitectura-Flux/
Diseño Responsivo. (s. f.). Recuperado 9 de agosto de 2015, a partir de
http://www.animus.com.ar/que-hacemos/diseno-responsivo.html
Ember.js - A framework for creating ambitious web applications. (s. f.). Recuperado 8 de agosto
de 2015, a partir de http://emberjs.com/
Ferguson, R. C., Peterson, B. L., & Thompson, H. C. (2005). System software framework for
system of systems avionics. En Digital Avionics Systems Conference, 2005. DASC 2005.
The 24th (Vol. 2, p. 10 pp. Vol. 2-pp.). http://doi.org/10.1109/DASC.2005.1563458
101
Flux | Application Architecture for Building User Interfaces. (s. f.). Recuperado 26 de abril de
2016, a partir de http://facebook.github.io/flux/index.html
Formación «user stories» biko - mayo 2011. (03:52:44 UTC). Recuperado a partir de
http://www.slideshare.net/jrramon/formacin-user-stories-biko-mayo-2011
Framework Definition. (s. f.). Recuperado 8 de agosto de 2015, a partir de
http://techterms.com/definition/framework
Haupt, F., Leymann, F., & Pautasso, C. (2015). A Conversation Based Approach for Modeling
REST APIs. En 2015 12th Working IEEE/IFIP Conference on Software Architecture
(WICSA) (pp. 165-174). http://doi.org/10.1109/WICSA.2015.20
Hornsby, A., Belimpasakis, P., & Defee, I. (2009). XMPP-based wireless sensor network and its
integration into the extended home environment. En IEEE 13th International Symposium
on Consumer Electronics, 2009. ISCE ’09 (pp. 794-797).
http://doi.org/10.1109/ISCE.2009.5156807
javascript - Pros and Cons of Facebook’s React vs. Web Components (Polymer) - Programmers
Stack Exchange. (s. f.). Recuperado 25 de marzo de 2016, a partir de
http://programmers.stackexchange.com/questions/225400/pros-and-cons-of-facebooks-
react-vs-web-components-polymer
Jiang, W., Zhang, M., Zhou, B., Jiang, Y., & Zhang, Y. (2014). Responsive web design mode and
application. En 2014 IEEE Workshop on Advanced Research and Technology in Industry
Applications (WARTIA) (pp. 1303-1306). http://doi.org/10.1109/WARTIA.2014.6976522
Lu, X., Lei, W., & Zhang, W. (2012). The Design and Implementation of XMPP-Based SMS
Gateway. En 2012 Fourth International Conference on Computational Intelligence,
Communication Systems and Networks (CICSyN) (pp. 145-148).
http://doi.org/10.1109/CICSyN.2012.35
Mobile Messaging Clients Compared - TechSpot. (s. f.). Recuperado 27 de agosto de 2015, a
partir de http://www.techspot.com/article/776-messaging-clients-compared/
Mocha - the fun, simple, flexible JavaScript test framework. (s. f.). Recuperado 29 de abril de
2016, a partir de https://mochajs.org/
My Thoughts on AngularJS 1.3 and 2.0. (s. f.). Recuperado 9 de agosto de 2015, a partir de
http://weblogs.asp.net/dwahlin/my-thoughts-on-angularjs-1-3-and-2-0
102
NW.js and Electron.js: Web Technology on the Desktop | Tivix. (s. f.). Recuperado 25 de marzo
de 2016, a partir de http://www.tivix.com/blog/nwjs-and-electronjs-web-technology-
desktop/
Panda Strike: React Is A Terrible Idea. (s. f.). Recuperado 25 de marzo de 2016, a partir de
https://www.pandastrike.com/posts/20150311-react-bad-idea
Paterson, I., Saint-Andre, P., Stout, L., & Tilanus, W. (2014, abril 9). XMPP Over BOSH [XMPP
Extension Protocol]. Recuperado 16 de agosto de 2015, a partir de
http://xmpp.org/extensions/xep-0206.html
Paterson, I., Smith, D., Saint-Andre, P., Moffitt, J., Stout, L., & Tilanus, W. (2014, abril 9).
Bidirectional-streams Over Synchronous HTTP (BOSH) [XMPP Extension Protocol].
Recuperado 16 de agosto de 2015, a partir de http://xmpp.org/extensions/xep-
0124.html#technique
Qué es y cómo funciona ReactJS. (s. f.). Recuperado 8 de agosto de 2015, a partir de
https://platzi.com/blog/intro-react-js/
React Native: Bringing modern web techniques to mobile. (s. f.). Recuperado 26 de abril de
2016, a partir de https://code.facebook.com/posts/1014532261909640/react-native-
bringing-modern-web-techniques-to-mobile/
ReactJS, la biblioteca JavaScript para ‘front--end’ desarrollada por Facebook. (s. f.). Recuperado
25 de marzo de 2016, a partir de http://www.bbvaopen4u.com/es/actualidad/reactjs-la-
biblioteca-javascript-para-front-end-desarrollada-por-facebook
Skvorc, D., Horvat, M., & Srbljic, S. (2014). Performance evaluation of Websocket protocol for
implementation of full-duplex web streams. En 2014 37th International Convention on
Information and Communication Technology, Electronics and Microelectronics (MIPRO)
(pp. 1003-1008). http://doi.org/10.1109/MIPRO.2014.6859715
Status codes in HTTP. (s. f.). Recuperado 17 de agosto de 2015, a partir de
http://www.w3.org/Protocols/HTTP/HTRESP.html
The Core Concepts of Angular 2. (s. f.). Recuperado 9 de agosto de 2015, a partir de
http://victorsavkin.com/post/118372404541/the-core-concepts-of-angular-2
The Open Group ArchiMate® Forum Landing Page | The Open Group. (s. f.). Recuperado 27 de
abril de 2016, a partir de http://www.opengroup.org/subjectareas/enterprise/archimate
Trello. (s. f.). Recuperado 15 de septiembre de 2015, a partir de https://trello.com
103
Trigas Gallego, M., & Domingo Troncho, A. C. (s. f.). Gestión de Proyectos Informáticos,
Metodología SCRUM.
Twnel. (s. f.). Recuperado 27 de agosto de 2015, a partir de http://www.twnel.com/
Ubl, M., 20th, E. K. P. octubre, & article, 2010 Comments: 47 Your browser may not support the
functionality in this. (s. f.). Introducción a los WebSockets: incorporación de sockets a la
Web - HTML5 Rocks. Recuperado 15 de agosto de 2015, a partir de
http://www.html5rocks.com/es/tutorials/websockets/basics/
WebSocket.org -- A WebSocket Community. (s. f.). Recuperado 15 de agosto de 2015, a partir
de https://www.websocket.org/
WebSockets. (s. f.). Recuperado 15 de agosto de 2015, a partir de
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API
What are the pros and cons of React.js and Flux? Are they the future of front-end development? -
Quora. (s. f.). Recuperado 25 de marzo de 2016, a partir de https://www.quora.com/What-
are-the-pros-and-cons-of-React-js-and-Flux-Are-they-the-future-of-front-end-
development
What is the future of instant messaging? (s. f.). Recuperado a partir de
https://www.sinch.com/opinion/future-of-instant-messaging/
What’s New in AngularJS 2.0. (s. f.). Recuperado 9 de agosto de 2015, a partir de
http://www.sitepoint.com/whats-new-in-angularjs-2/
Why React? | React. (s. f.). Recuperado 17 de agosto de 2015, a partir de
https://facebook.github.io/react/docs/why-react.html
Zervas, P., Trichos, A., Sampson, D. G., & Li, N. (2014). A Responsive Design Approach for
Supporting Mobile Access to Virtual and Remote Laboratories. En 2014 IEEE 14th
International Conference on Advanced Learning Technologies (ICALT) (pp. 11-13).
http://doi.org/10.1109/ICALT.2014.13