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


42

• Modelo

Diagrama 4 – Modelo vista de cooperación de actor


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


• Modelo

Diagrama 6 - Modelo vista función de negocio


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


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


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


51

• Modelo

Diagrama 14 - Modelo vista de cooperación de aplicación


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


55

• Modelo

Diagrama 18 - Modelo vista de uso de aplicación


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


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


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


61

• Modelo

Diagrama 24 - Modelo vista de estructura de información


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


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


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


• 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


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


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


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


- Refactorización en el flujo de datos del componente Chats (viewController)

• Sprint #23 (04/04/2016-11/04/2016)

FrontEnd Developer


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

DESARROLLO DE UNA APLICACIÓN MÓVIL …

Documents

Transcript of DESARROLLO DE UNA APLICACIÓN MÓVIL …