E Trabajo Fin de Grado STUDIO Y DESARROLLO DE UN …tauja.ujaen.es/bitstream/10953.1/6143/1/TFG...

Escu

ela

Po

lité

cn

ica

Su

peri

or

de J

aé

n

Gra

do

en

Ing

enie

ría

Info

rmát

ica

ESTUDIO Y DESARROLLO DE

UN PROTOTIPO DE

PLATAFORMA ONLINE PARA

AYUDA A LA REALIZACIÓN DE

PRESENTACIONES DE FORMA

REMOTA

UNIVERSIDAD DE JAÉN

Escuela Politécnica Superior de Jaén

Trabajo Fin de Grado

Alumno: Gabriel Fernández Moral

Tutor: Prof. D. José Ramón Balsas Almagro

Dpto: Informática

Gabriel Fernández Moral Estudio y desarrollo de un prototipo de plataforma online para ayuda a la realización de presentaciones de forma remota

Universidad de Jaén

Escuela Politécnica Superior de Jaén

Departamento de Informática

Don José Ramón Balsas Almagro , tutor del Proyecto Fin de Carrera titulado: Estudio

y desarrollo de un prototipo de plataforma online para ayuda a la realización de

presentaciones de forma remota, que presenta Gabriel Fernández Moral, autoriza su

presentación para defensa y evaluación en la Escuela Politécnica Superior de Jaén.

Jaén, 2 de Septiembre de 2016

El alumno: Los tutores:

Gabriel Fernández Moral José Ramón Balsas Almagro


Índice

1. Introducción .................................................................................................................... 7

1.1. Motivación ............................................................................................................... 8

1.2. Objetivos ................................................................................................................. 9

1.3. Metodología ...........................................................................................................10

1.4. Estructura del documento ......................................................................................11

2. Análisis ..........................................................................................................................13

2.1. Análisis preliminar ..................................................................................................13

2.2. Propuesta de solución ............................................................................................19

2.3. Requisitos del sistema ...........................................................................................21

2.4. Historias de usuario................................................................................................23

2.5. Planificación inicial de tareas .................................................................................26

2.6. Estudio de viabilidad ..............................................................................................29

2.7. Modelo de dominio .................................................................................................41

2.8. Análisis de la interfaz .............................................................................................42

3. Diseño ...........................................................................................................................44

3.1. Diagrama Entidad-Relación ....................................................................................45

3.2. Diagrama de componentes ....................................................................................48

3.3. Diseño de la interfaz de usuario .............................................................................50

4. Implementación .............................................................................................................52

4.1. Arquitectura ............................................................................................................53

4.2. Detalles sore implementación ................................................................................62

4.3. Despliegue del proyecto .........................................................................................75

5. Conclusiones .................................................................................................................75

5.1. Mejoras y trabajos futuros ......................................................................................77

6. Bibliografía ....................................................................................................................79

Apéndice I. Manual de instalación del sistema .....................................................................80

Apéndice II. Manual de usuario ............................................................................................82

Apéndice III. Descripción de contenidos suministrados ........................................................94

Apéndice IV. Acceso a instalación de pruebas .....................................................................95


Índice de ilustraciones

Ilustración 2.1 – Microsoft PowerPoint ..................................................................................14

Ilustración 2.2 – Prezi ...........................................................................................................15

Ilustración 2.3 – Dropbox ......................................................................................................16

Ilustración 2.4 – Google Drive ..............................................................................................17

Ilustración 2.5 – Dispositivos de control remote ....................................................................18

Ilustración 2.6 – Icono de la aplicación Remote Mouse ........................................................19

Ilustración 2.7 – Propuesta de solución ................................................................................21

Ilustración 2.8 – Beneficios en relación al número de usuarios .............................................41

Ilustración 2.9 – Modelo de dominio .....................................................................................42

Ilustración 3.1 – Diagrama Entidad Relación ........................................................................45

Ilustración 3.2 – Diagrama Entidad Relación FN1 ................................................................47

Ilustración 3.3 – Diagrama de componentes de back-end ....................................................49

Ilustración 3.4 – Diagrama de componentes de aplicación front-end ....................................50

Ilustración 3.5 – Pantalla de login .........................................................................................51

Ilustración 3.6 – Pantalla de lista de ficheros ........................................................................51

Ilustración 3.7 – Pantalla de visualización de ficheros ..........................................................52

Ilustración 4.1 – Arquitectura ................................................................................................55

Ilustración 4.2 – Conversión de aplicación web a aplicaciones móviles nativas ....................57

Ilustración 4.3 – Gestión de peticiones en Node.js ...............................................................58

Ilustración 4.4 – Captura de la aplicación exportada con GoNative.io funcionando como

aplicación nativa en Android .................................................................................................61

Ilustración 4.5 – Callbacks ....................................................................................................63

Ilustración 4.6 – Callback hell ...............................................................................................64

Ilustración 4.7 – Evitar el ‘callback hell’ mediante la correcta definición de funciones ...........64

Ilustración 4.8 – Promises ...................................................................................................65

Ilustración 4.9 – Componentes .............................................................................................66

Ilustración 4.10 – Modelos y relaciones en Sequelize.js .......................................................68

Ilustración 4.11 – Utilización de Socket.io.............................................................................69

Ilustración 4.12 – JSON web tokens .....................................................................................72

Ilustración 7.1 – Firewall para Node.js ..................................................................................81

Ilustración 7.2 – Crear cuenta de usuario .............................................................................83

Ilustración 7.3 – Creando cuenta de usuario ........................................................................84

Ilustración 7.4 – Cuenta creada satisfactoriamente ..............................................................85

Ilustración 7.5 – Validación de cuenta ..................................................................................86

Ilustración 7.6 – Cuenta validada .........................................................................................86

Ilustración 7.7 – Pantalla principal sin ficheros .....................................................................87

Ilustración 7.8 – Selección de ficheros .................................................................................87

Ilustración 7.9 – Subida de ficheros ......................................................................................88

Ilustración 7.10 – Lista de ficheros actualizada ....................................................................88

Ilustración 7.11 – Borrado de ficheros ..................................................................................89

Ilustración 7.12 – Confirmar borrado ....................................................................................89

Ilustración 7.13 – Descarga de fichero .................................................................................90

Ilustración 7.14 – Fichero descargado ..................................................................................90

Ilustración 7.15 – Iniciar presentación ..................................................................................91


Ilustración 7.15 – Compartir presentación ............................................................................91

Ilustración 7.16 – Enlace a presentación ..............................................................................92

Ilustración 7.17 – Visualización de presentación a través del enlace ....................................92

Ilustración 7.18 – Navegación a través de la presentación ...................................................93

Ilustración 7.19 – Cerrar sesión ............................................................................................94


Índice de tablas

Tabla 2.1 – Historias de usuario ...........................................................................................26

Tabla 2.2 – Tareas ...............................................................................................................29

Tabla 2.3 – Sueldos .............................................................................................................31

Tabla 2.4 – Horas según rol .................................................................................................36

Tabla 2.5 – Costes de salarios .............................................................................................37

Tabla 2.6 – Estimaciones porcentaje de usuarios premium ..................................................39

Tabla 2.7 – Costes empresariales de desarrollo y mantenimiento ........................................40

Tabla 2.8 – Personas ...........................................................................................................44

Tabla 3.1 – Tuplas de usuarios ............................................................................................46

Tabla 3.2 – Tuplas de ficheros .............................................................................................46

Tabla 3.3 – Tuplas de presentaciones ..................................................................................46


1. Introducción

El imparable avance de internet durante este siglo ha supuesto un auténtico

cambio en la forma en que las personas nos comunicamos, trabajamos, nos

relacionamos o simplemente disfrutamos de nuestro tiempo de ocio.

La popularización de herramientas y servicios como Dropbox1, Whatsapp2 o

Skype3 ha abierto todo un nuevo abanico de posibilidades que nos permiten

interactuar de forma mucho más natural con personas que no necesariamente se

encuentran en nuestras inmediaciones geográficas.

No resulta ya extraño escuchar hablar sobre entrevistas de trabajo remotas,

equipos de desarrollo distribuidos a lo largo y ancho del planeta o personas que

producen vídeos que son visionados por usuarios de todo el mundo. Todas estas

aplicaciones que ya han cambiado nuestras vidas, son posibles gracias a las

posibilidades que hoy en día nos ofrece un internet mucho más completo que en sus

orígenes.

Dentro del ámbito de las aplicaciones ofimáticas, observamos cómo se está

produciendo un claro cambio de paradigma. Si bien hasta hace unos años empresas

como Microsoft vendían licencias de uso para productos de escritorio, cada vez más

el usuario demanda aplicaciones basadas en la nube, que no necesiten de laboriosos

procesos de instalación para su uso y que permitan de serie la interacción desde

cualquier lugar y con cualquier persona.

Esta demanda ha conllevado consigo también un cambio en el modelo de

negocio. En lugar de vender licencias de uso, ahora la tendencia es el Software As A

Service (SAAS). Esta nueva forma de vender un producto, permite una mayor agilidad

a las empresas y a los usuarios frente a los inevitables cambios de este mundo, así

como una cuantiosa reducción de costes.

Merece la pena destacar a su vez, el impulso de los sistemas operativos móviles

como Android e iOS, que han conseguido popularizar el acceso a internet en movilidad

1 Sitio web de Dropbox: www.dropbox.com 2 Sitio web de Whatsapp: www.whatsapp.com 3 Sitio web de Skype: www.skype.com


y han revolucionado la forma de trabajar. Son muchos los profesionales que ya no

están sujetos a su ordenador de sobremesa a la hora de realizar la mayoría de sus

tareas laborales.

También en el ámbito de la enseñanza, la forma de impartir contenidos, la

manera en que los alumnos interactúan con la información o los cauces de

comunicación entre ellos no tienen nada que ver con los habituales hace unos años.

1.1. Motivación

Este proyecto surge de una necesidad en las aulas de la Universidad de Jaén.

Como alumno de la misma, a menudo me encontraba ante la tesitura de tener que

realizar alguna presentación ante profesores y alumnos. La forma habitual de realizar

dichas exposiciones consistía en utilizar el ordenador conectado al proyector del que

constan todas las aulas.

Sin embargo, este método presentaba el inconveniente de tener que interactuar

directamente con el ordenador para realizar transiciones en dichas presentaciones.

Una solución habitual para los profesores consistía en la adquisición de un dispositivo

pulsador que permitiera realizar dichas transiciones desde algunos metros de

distancia respecto al equipo. En este sentido han sido muchos los dispositivos que he

llegado a ver, desde ratones que permiten varios metros de alcance inalámbrico, hasta

dispositivos más especializados que incluyen hasta un puntero láser.

No obstante, esta solución implicaba tener que llevar siempre contigo dicho

dispositivo. Además, para alumnos que sólo realizamos un uso esporádico de él, sería

un gasto un tanto innecesario.

Por otro lado, si bien el mercado actual cuenta con un buen número de

alternativas a la hora de realizar videoconferencias (léase Skype, Google Hangouts4,

GoToMeeting5…), resulta mucho más complejo encontrar una herramienta sencilla

para realizar presentaciones de documentos de forma remota. Muchas de estas

4 Sitio web de Google Hangouts: www.google.com/hangouts 5 Sitio web de GoToMeeting: www.gotomeeting.com


soluciones incluyen opciones de edición colaborativa o para compartir pantalla, pero

ninguna de ellas incluye una solución simple y dedicada para presentar documentos

a distancia.

Todo esto ha motivado mi decisión de basar mi Trabajo de Fin de Grado en el

estudio y desarrollo de un prototipo de aplicación enfocada a realizar presentaciones

remotas en tiempo real.

1.2. Objetivos

Los objetivos globales que se pretenden conseguir mediante el desarrollo del

presente trabajo se enumeran a continuación:

Realizar un estudio de tecnologías web para la comunicación asíncrona

entre aplicaciones cliente y servidor.

Diseñar e implementar un prototipo de la aplicación de servidor que

permita la gestión de los servicios de presentación y la operación remota

tanto del orador como de los asistentes.

Desarrollo de un prototipo de aplicación cliente para el orador, adaptada

a dispositivos móviles, que envíe al servidor datos relativos al

desplazamiento dentro de una presentación.

Desarrollo de un prototipo de aplicación web que permita a los asistentes

visualizar de forma remota la presentación controlada desde el dispositivo

móvil.

En un orden más específico al desarrollo del proyecto, también se incluyen los

siguientes objetivos:

Estudio y análisis de las tecnologías de desarrollo a nivel de servidor.

Comparativa de las tecnologías de desarrollo a nivel de aplicación web.

Estudio y análisis de las tecnologías de comunicación asíncrona entre

aplicaciones web y de servidor.


Investigación de las alternativas existentes en cuanto a persistencia de

datos, así como de herramientas de interacción entre la aplicación de

servidor y dicha capa de persistencia.

Comparativa de librerías visuales para el desarrollo de la interfaz de

usuario de la aplicación web.

Aplicación de los estándares REST6 [1] en la capa de servicios que

expondrá la aplicación de servidor.

Estudio y aplicación de visualización de ficheros pdf en aplicaciones web.

Despliegue del prototipo de aplicación en alguna de las plataformas

existentes en el mercado destinadas a tal fin.

En resumen, tras la realización de este trabajo, el fruto del desarrollo debería

otorgar los siguientes productos:

A. Un servicio web con interfaz REST de forma que pueda ser consumido

tanto por nuestra aplicación web como por cualquier otro producto que

decida utilizarlo.

B. Una aplicación web que saque partido de dicho servicio web para la

realización de presentaciones remotas. Esta aplicación debería ser

accesible desde dispositivos con pantallas pequeñas.

C. Un despliegue de las dos herramientas anteriores en una plataforma

destinada a tal fin que permita su utilización por parte de cualquier usuario.

1.3. Metodología

Durante el desarrollo del trabajo se utilizarán principalmente las siguientes

metodologías a nivel global:

Estudio de los requisitos del sistema a desarrollar.

Recopilación bibliográfica sobre la temática y tecnologías relacionadas.

Estimación temporal y de costes de desarrollo.

6 REST: Representational Estate Transfer. Hace referencia a una forma concreta de desarrollar interfaces para servicios web basada en la realización de operaciones sobre los datos mediante el uso de los métodos del protocolo HTTP.


Diseño del sistema utilizando una metodología de orientación a

componentes utilizando el patrón de diseño Modelo-Vista-Controlador.

Implementación del prototipo del sistema.

De forma más específica al desarrollo del proyecto, tanto en su vertiente técnica,

como de gestión del mismo, también se pondrán en uso las siguientes metodologías

que facilitarán el proceso de desarrollo:

Elaboración y estimación de historias de usuario que reflejen los requisitos

del sistema a desarrollar.

Utilización de un sistema de control de versiones de forma efectiva con

división de ramas para desarrollo, producción, así como para cada nueva

funcionalidad.

Además, a lo largo del desarrollo del proyecto se aplicarán el conjunto de

metodologías ágiles SCRUM [2]. Entre sus características destacan el desarrollo

iterativo mediante ciclos de igual longitud temporal, la flexibilidad y capacidad de

adaptación a entornos cambiantes. Por tanto, teniendo en cuenta que contamos con

un equipo pequeño y que nuestro conocimiento del producto y las tecnologías pueden

ir cambiando conforme avance el desarrollo, el uso de SCRUM nos permitirá poder

adaptarnos de manera más fácil a los posibles cambios.

Por otro lado, puesto que este proyecto se plantea a largo plazo, podría continuar

añadiendo funcionalidades una vez concluida la fase de liberación del producto

mínimo viable. En este sentido, no teniendo aún definidas dichas funcionalidades, la

utilización de metodologías ágiles se antoja fundamental.

1.4. Estructura del documento

Este documento se divide en 3 índices, 6 apartados y 4 apéndices.

En primer lugar, nos encontraremos con 3 índices de diferentes elementos cada

uno.


El primero de ellos, hace referencia a cada uno de los puntos de que consta todo

el documento en cuestión.

El segundo índice indica cada una de las ilustraciones que se han incluido en el

documento así como la página en la que aparecen.

Por último, un tercer índice nos señaliza cada una de las tablas que se incluyen

este documento.

A continuación, contamos con 6 puntos en los que se desarrolla detalladamente

este proyecto. El primero de ellos, realiza una breve introducción al mismo,

contemplando los objetivos y la necesidad real que motiva este trabajo.

El segundo punto, realiza un análisis sobre las herramientas similares ya

existentes en el mercado y busca un nicho de mercado que aún no se encuentre

cubierto para poder centrar en él nuestro sistema. Se realiza un estudio de viabilidad

y se tienen en cuenta todos los requisitos que debe cubrir nuestro producto así como

las tareas necesarias para su desarrollo.

En el tercer punto, se realiza un diseño a partir de los requisitos obtenidos

durante la fase de análisis. Se tiene en cuenta en cada momento los objetivos que

pretende nuestro sistema en la toma de decisiones y se establece de forma clara la

idea de la solución a desarrollar.

El siguiente punto, el punto 4, realiza una revisión más técnica sobre el proceso

de implementación del sistema, se nombran muchas de las tecnologías utilizadas

durante el mismo y se justifica el uso de cada una de ellas.

El quinto apartado, realiza una revisión de los objetivos del proyecto y extrae las

conclusiones pertinentes una vez finalidado el proyecto.

En último lugar, el punto sexto enumera una lista de referencias bibliográficas

que han servido de fuente de inspiración para el desarrollo del proyecto.

En cuanto a los apéndices, cada uno sirve a un propósito específico. El primero

de ellos indica de forma muy detallada los pasos necesarios para realizar la instalación


del sistema de forma local, si bien esto no es necesario para probar el producto como

podemos ver de forma más detallada en dicho apéndice.

El segundo de los apéndice constituye una guía o manual de usuario a través de

la funcionalidad básica que se incluye en el prototipo desarrollado con el fin de guiar

al posible lector de esta memoria en el uso de la aplicación desarrollada.

El tercer apéndice enumera de forma breve los contenidos suministrados como

entrega final junto a esta memoria.

El último de los apéndices indica el enlace de acceso a la versión de pruebas

desplegada para poder realizar pruebas sobre este proyecto sin necesidad de realizar

una instalación previa.

2. Análisis

2.1. Análisis preliminar

El uso de presentaciones para exponer ideas o trabajos se ha convertido en algo

habitual en nuestra sociedad. Tanto en el sector empresarial, como en el educativo,

es ya muy común asistir a reuniones, conferencias o clases magistrales cuyo hilo

conductor son las diapositivas.

El número de soluciones existentes para tal fin se ha visto incrementado con la

popularización del acceso a internet y la aparición de nuevas tecnologías que permiten

desarrollos mucho más complejos.

Dentro de este sector existen un buen número de aplicaciones muy diferentes

entre sí, desde las tradicionales diapositivas de PowerPoint, hasta productos mucho

más elaborados con multitud de opciones.

A continuación procedemos a realizar un breve análisis de algunas de las

soluciones más relevantes.


2.1.1. Microsoft PowerPoint

Ilustración 2.1 – Microsoft PowerPoint

Microsoft PowerPoint es sin duda la aplicación más veterana dentro de este

sector [3]. Los orígenes de su desarrollo se remontan a la década de los ochenta y

gracias a sus numerosas opciones y a su inclusión dentro de la suite ofimática de

Microsoft ha sabido ganarse un buen hueco en el mercado.

A pesar de las numerosas bondades de PowerPoint como herramienta de

edición, su principal limitación quizás sea la restricción de trabajar con tipos de ficheros

propios de esta solución. Esto, en un mundo en el que estamos acostumbrados a

trabajar con una gran variedad de diferentes tipos de ficheros, puede ser un problema.

PowerPoint ha dado pasos en la realización de presentaciones remotas

incluyendo entre otras novedades, la liberación de las aplicaciones de la suite

ofimática de Microsoft para las plataformas móviles Android e iOS.

Estas aplicaciones móviles permiten comenzar a crear una presentación para

continuar trabajando en ella posteriormente en un ordenador. Sin embargo, no

incluyen la posibilidad de difundir presentaciones ni de utilizar el terminal móvil como

mando para una presentación remota.

Las últimas versiones de Powerpoint incluyen la característica de realización de

presentaciones en línea. Sin embargo, éstas necesitan de una configuración previa

de un servidor específico para su difusión. Otra alternativa mucho más viable son los

planes de suscripción para Office 365. Estos planes tienen unos precios que oscilan

alrededor de los 10 € por usuario y mes. Sin embargo, siguen teniendo la gran

desventaja de tan sólo permitirnos realizar presentaciones sobre los documentos

realizados con la propia aplicación de Powerpoint.


2.1.2. Prezi

Ilustración 2.2 – Prezi

Prezi surgió en 2009 como una vuelta de tuerca más en el ámbito de las

presentaciones. Se enfoca en la posibilidad de desplazarse a través de un documento

a través de zooms en las diferentes partes del mismo, creando así un efecto visual

muy sorprendente.

Si bien la idea de esta empresa ha supuesto una pequeña revolución en la forma

de visualizar las diapositivas [4], también es cierto que su capacidad para asombrar

pierde efecto una vez la solución ha llegado a ser conocida por un grupo amplio de la

población.

Prezi incluye una novedosa forma de realizar presentaciones remotas mediante

desplazamientos. Sin embargo, presenta dos grandes limitaciones. La primera de

éstas, consiste en su incapacidad para trabajar sobre documentos no generados en

la misma plataforma, esto es, tan sólo podemos realizar presentaciones sobre los

documentos que generemos con el editor de presentaciones de Prezi. Por otro lado,

esta aplicación web se basa en tecnologías en desuso como son Adobe Flash [5] y

Adobe Air, lo cual limita tanto su compatibilidad con otros servicios y navegadores,

como sus posibilidades de desarrollo y mantenimiento.


2.1.3. Dropbox

Ilustración 2.3 – Dropbox

El caso de Dropbox es quizás el de una de las compañías de reciente creación

más exitosas de los últimos años [6]. Sus comienzos se remontan a 2007 y, tras ser

pretendida por otras grandes empresas tecnológicas como Apple, decidió seguir su

propio camino.

Su principal baza es la de permitir almacenar ficheros en la nube, accesibles

desde cualquier lugar con conexión a internet. También permite compartir los ficheros

alojados con cualquier otra persona incluso si no dispone de una cuenta en el servicio.

Dropbox se presenta no sólo como una aplicación, sino como un servicio, lo que

permite su integración con multitud de otras aplicaciones, hecho del que han sabido

sacar partido otras plataformas.

Pese a que Dropbox cuenta ya con herramientas integradas en su propia

aplicación web capaces de visualizar ciertos contenidos como imágenes o pdf, aún no

dispone de capacidad alguna para realizar presentaciones remotas.


2.1.4. Google Drive

Ilustración 2.4 – Google Drive

Tras el éxito de Dropbox, Google decidió lanzar al mercado su propio sistema de

almacenamiento. Con Google Drive, no sólo tenemos la capacidad de almacenar y

compartir ficheros, sino que también integra un completo modo de edición colaborativa

[7].

Las presentaciones creadas en esta plataforma pueden reproducirse

remotamente a través de Hangouts, otra de las herramientas online de Google. Sin

embargo, esto reduce mucho el ámbito de uso. Si bien tiene sentido al usar la suite

completa de aplicaciones de Google, una vez más nos encontramos ante la limitación

de tener que usar dicho ecosistema de aplicaciones y tipos de ficheros para todo.


2.1.5. Dispositivos de control remoto

Ilustración 2.5 – Dispositivos de control remote

En cuanto a elementos hardware para el control de presentaciones, el mercado

nos ofrece un amplio rango de productos. El precio de estos mandos oscila entre los

10 y los 100€ dependiendo del grado de sofisticación que exijamos.

Sin embargo, muchos de estos productos sólo son compatibles con Microsoft

PowerPoint y no ofrecen soporte a otras plataformas de presentaciones remotas. Su

rango de uso suele establecerse en torno a unos 10 metros lo que quizás aporta una

capacidad suficiente si nos limitamos a su uso dentro de una habitación. Por otro lado,

estos dispositivos podrían no ser suficientes para la realización de presentaciones en

grandes conferencias donde la distancia entre el presentador y el equipo puede

superar con creces dicho rango.

2.1.6. Aplicaciones de ratón para móviles

Otra alternativa en el mercado actual serían las aplicaciones de ratón para

móviles. Estas aplicaciones se conectan mediante wifi o bluetooth a un ordenador y

permiten simular la utilización de un ratón mediante la pantalla táctil de nuestro

dispositivo móvil.


Ilustración 2.6 – Icono de la aplicación Remote Mouse

Un buen ejemplo de este sector es el representado por la aplicación Remote

Mouse7. Al igual que el resto de sus competidoras, pueden ser bastante útiles en

alguna situación de emergencia, si bien la interacción para controlar un ordenador con

ellas resulta bastante engorrosa para el usuario.

2.2. Propuesta de solución

Como hemos podido comprobar en el análisis preliminar, existe un buen número

de soluciones relacionadas con el ámbito de las presentaciones, así como el

almacenamiento de ficheros. Sin embargo, ninguna de ellas ofrece una forma sencilla

de realizar presentaciones sobre ficheros de los que ya disponga el cliente si no es

creandolos directamente en dichas plataformas.

Intentar abordar este proyecto como la creación de una plataforma que

permitiera realizar presentaciones de cualquier fichero sería una tarea demasiado

ardua. No obstante, esta no debe ser jamás la idea de un proyecto que empieza desde

cero.

En lugar de ello, la idea inicial sería apostar por conseguir realizar

presentaciones remotas de ficheros pdf. Éste es un tipo de fichero muy común y con

el que la mayoría de usuarios están acostumbrados a trabajar. Además, presenta la

7 Aplicación Remote Mouse para android: https://play.google.com/store/apps/details?id=com.hungrybolo.remotemouseandroid

https://play.google.com/store/apps/details?id=com.hungrybolo.remotemouseandroid


ventaja de que casi cualquier documento puede convertirse fácilmente a este tipo de

fichero, con lo cuál podría ser presentado a través de nuestra herramienta.

Por otro lado, aún no sabemos cómo de grande puede llegar a ser nuestro

proyecto, o qué impacto puede llegar a tener en el público. Teniendo esto en cuenta,

deberíamos pensar en una arquitectura escalable. Es decir, debemos pensar al

realizar el diseño de nuestro sistema en que, quizás, con el tiempo no sólo tengamos

una aplicación web que quiera utilizar el servicio sino también posiblemente

aplicaciones móviles, aplicaciones de Windows u OSX, televisiones inteligentes…

Por tanto, la idea inicial del sistema consistirá en:

Una capa de persistencia, que pueda ser fácilmente migrada a sistemas

mayores de almacenamiento si así se requiere.

Una capa de lógica de negocio que se comunicará con dicha capa de

persistencia y, a su vez, expondrá las funcionalidades a través de un

servicio REST.

Una aplicación adaptable a pantallas de teléfonos móviles que consuma

los servicios REST haciendo así uso de toda la funcionalidad.

La comunicación entre la aplicación web y el servicio debería realizarse de forma

asíncrona, ya que, una vez el cliente de la aplicación web se conecte a una

presentación remota, dicha aplicación deberá recibir eventos desde el servicio cada

vez que se produzca un desplazamiento a través de la navegación en la presentación.


Ilustración 2.7 – Propuesta de solución

2.3. Requisitos del sistema

En este apartado procedemos a detallar los requisitos, tanto funcionales como

no funcionales, que debería satisfacer nuestro sistema. Este es un paso previo a la

fase de diseño, que nos permitirá tener una idea clara del ámbito del problema a

resolver.

2.3.1. Requisitos funcionales

Entre los requisitos funcionales incluimos todos aquellos que deben dotar al

producto de funcionalidades específicas.

El sistema debe permitir al usuario la creación de una cuenta a partir de

un nombre de usuario, contraseña y dirección de correo electrónico.

Al crear una cuenta, el sistema debe enviar un correo electrónico a la

dirección proporcionada con un enlace que permita validar dicha cuenta.

Esto servirá para garantizar que dicha cuenta de correo electrónico

pertenece al usuario.


El sistema debe permitir al usuario acceder mediante los credenciales de

identificación asociados a una cuenta validada.

El usuario debe poder subir cualquier tipo de fichero al sistema una vez

se ha identificado con los credenciales de su cuenta.

El sistema debe ser capaz de mostrar al usuario una lista completa de

todos los ficheros que el usuario a introducido en el sistema.

Cada fichero debe poder ser eliminado por su usuario dueño cuando éste

lo desee.

El usuario debe poder descargar cada uno de los ficheros que ha

introducido en el sistema.

Debe permitir visualizar ficheros que sean de tipo pdf y comenzar así una

presentación del mismo.

Al iniciar una presentación, el sistema debe generar un enlace que

identifique unívocamente a dicha presentación.

El usuario debe poder ver el enlace de su presentación para compartirlo

con los posibles espectadores que quieran seguir dicha presentación.

Cualquier usuario, incluso sin cuenta en el sistema, que acceda al enlace

de una presentación válida, debe poder visualizar el documento asignado

a dicha presentación.

El usuario que ha iniciado una presentación, debe poder desplazarse

hacia adelante y atrás a través del documento.

Los espectadores de una presentación deben ver en tiempo real los

desplazamientos a través de la presentación conforme el presentador los

realice.

El usuario debe poder finalizar una presentación. En este caso, la

presentación ya no será accesible a través del enlace asignado.

Si una presentación no finaliza correctamente en 24 horas desde su

creación, el sistema deberá encargarse de eliminarla.

2.3.2. Requisitos no funcionales

En esta sección se incluyen características que debe cumplir el producto sin

aportar necesariamente una funcionalidad específica al producto.


El sistema debe ser accesible por nuevas aplicaciones que se desarrollen

en el futuro.

La aplicación web debe contar con una interfaz adaptada a móviles que

permita su uso en terminales de reducidas dimensiones. Este requisito

estará especialmente orientado a permitir controlar la presentación desde

un terminal móvil.

El sistema debe proporcionar la seguridad necesaria para que los ficheros

de cada usuario no sean expuestos a terceros sin su consentimiento.

La aplicación web debe contar con una estética minimalista para que el

usuario encuentre fácilmente las opciones.

2.4. Historias de usuario

Puesto que hemos decidido utilizar una metodología SCRUM durante el

desarrollo, a continuación definiremos las historias de usuario, que reflejarán de forma

global el trabajo a realizar durante todo el desarrollo.

Además, procederemos a valorar las historias de usuario con puntos de historia

que nos darán una estimación aproximada de la cantidad de trabajo que puede

conllevar el desarrollo de cada una de ellas.

Número identificativo Historia de usuario Puntos de historia

1

Como usuario, me gustaría poder visualizar una lista de mis ficheros para poder interactuar con ellos.

5

2

Como usuario, me gustaría poder subir ficheros a la plataforma para poder almacenarlos en el sistema.

5

3

Como usuario, me gustaría que la lista de ficheros se actualice al añadir nuevos ficheros al sistema para poder interactuar con los ficheros que acabo de añadir.

2

4 Como usuario, 3


me gustaría poder descargar los ficheros que he añadido a la plataforma para poder recuperarlos siempre que quiera.

5

Como programador, me gustaría notificar al usuario mediante alertas accesibles si se ha producido algún error en el sistema, para que el usuario sepa que algún tipo de problema está afectando a su experiencia.

3

6

Como usuario, me gustaría poder acceder al sistema con mis credenciales, para evitar que otra persona pueda acceder a mis ficheros.

8

7

Como programador, me gustaría que todas las interacciones con el API Resto requieran de un token para garantizar la autorización de dicha acción.

13

8

Como usuario, me gustaría que mis ficheros se muestren por páginas si hay un gran número de ellos para poder visualizarlos de forma correcta.

5

9

Como usuario, me gustaría poder salir del sistema cuando ya no necesite trabajar más para impedir que otra persona pueda acceder a mi cuenta.

5

10

Como programador, me gustaría evitar que un usuario pueda añadir al sistema dos ficheros con el mismo nombre para evitar conflictos.

3

11

Como usuario, me gustaría poder crear una cuenta en el sistema para poder acceder y trabajar con mis ficheros.

5

12

Como programador, me gustaría que en el proceso de creación de una cuenta sea necesario validar la cuenta de correo electrónico asociada para asegurarme de que dicha dirección pertenece al usuario.

3


13

Como usuario, me gustaría poder visualizar mis ficheros pdf para poder iniciar una presentación con ellos.

13

14

Como programador, me gustaría que sólo los ficheros de tipo pdf puedan ser visualizados para restringir el ámbito del proyecto.

1

15

Como usuario, me gustaría poder desplazarme a través de las páginas de mi fichero pdf mientras lo visualizo para poder leer distintas páginas.

5

16

Como usuario, me gustaría poder disponer de un enlace a mi presentación para poder compartirlo con los posibles espectadores.

3

17

Como usuario, me gustaría que cualquier espectador que acceda al enlace de mi presentación pueda ver mi presentación para visualizar el documento.

8

18

Como usuario, me gustaría que cada vez que me desplazo por las páginas del documento de mi presentación, dichos cambios se reflejen también en la visualización de los espectadores para que puedan seguir la presentación en tiempo real.

8

19

Como usuario, me gustaría que cuando un espectador se conecte a mi presentación, visualice la página actual en que se encuentra la presentación para que su visualización esté desde el principio actualizada.

2

20

Como usuario, me gustaría que mi presentación no sea accesible una vez haya cerrado dicha presentación para evitar que cualquier persona con el enlace pueda

5


seguir visualizando mi documento.

21

Como programador, me gustaría que cualquier presentación iniciada hace más de 24 horas se elimine automáticamente para evitar una acumulación de presentaciones inutilizadas en el servidor.

3

Tabla 2.1 – Historias de usuario

En total tenemos una estimación de 108 puntos de historia.

2.5. Planificación inicial de tareas

Una vez elaborada la lista completa de historias de usuario, procedemos a

descomponer dichas historias en tareas más concretas, que nos permitan tener una

mejor idea del trabajo que conlleva cada historia de usuario.

Historia de usuario Tareas

1

Instalación de la base de datos

Instalación del servidor para el back-end

Creación de modelos de fichero y usuario

Creación del servicio web para recuperar los datos de ficheros asociados a un usuario

Instalación del servidor para la aplicación web

Diseño y creación de interfaz de usuario para la lista de ficheros en la aplicación web

Realizar solicitud de ficheros desde la aplicación web al api REST

Actualizar la lista de ficheros en la interfaz de usuario

2

Modificación de interfaz de usuario para permitir añadir nuevos ficheros

Lógica de envío de ficheros desde la aplicación web al api REST

Creación del servicio web en el api REST para añadir nuevos ficheros

Persistencia de los nuevos ficheros en base de datos


Persistencia de los nuevos ficheros en disco en el servidor del back-end

3 Refrescar la lista de ficheros cuando llegue la respuesta del back-end tras haber añadido nuevos ficheros.

4

Modificar la interfaz de usuario para permitir descargar cada fichero existente

Realizar petición de descarga al api REST

Crear servicio web para descargar un fichero

Recuperar instancias de fichero de la base de datos

Recuperar fichero de disco duro y devolverlo como respuesta

5

Diseño e implementación de la interfaz de usuario para mostrar alertas.

Gestión de alertas al mostrar la lista de ficheros

Gestión de alertas al añadir ficheros

Gestión de alertas al descargar ficheros

6

Diseño e implementación de interfaz de usuario de login

Realizar petición de autentificación al api REST

Crear un servicio web para autentificación

Redireccionamiento a pantalla principal tras login exitoso

Redireccionamiento a pantalla de login tras intentar acceder a cualquier ruta sin estar autenticado

7

Generación de tokens en el servicio web de login y envío a cliente

Envío de token en cada petición desde la aplicación web

Comprobación de token en cada acceso al api REST salvo el login

8 Diseño e implementación de la interfaz de usuario paginada

Gestión de cambio de páginas

9

Diseño e implementación de la interfaz de usuario de logout

Borrado de token de web storage

Redirección a pantalla de login

10 Gestión de subida de ficheros con nombres ya existentes

Muestra de alerta

11

Diseño e implementación de interfaz de usuario para creación de cuentas

Realizar petición de creación de cuenta al api REST

Creación de servicio web para creación de cuentas

Generación de enlace tras crear cuenta


12

Envío de enlace a la dirección de correo electrónico asociada a la cuenta

Redirección del enlace a pantalla de login de la aplicación web

Petición de validación al api REST

Creación de servicio web para validación de cuentas

Notificación de éxito o error

13

Diseño e implementación de interfaz de usuario para visualización de ficheros pdf

Solicitud de fichero al api REST con autentificación

Implementación de visualización de fichero pdf

14

Comprobación de tipo de fichero al solicitar visualización

Mostrar alerta en caso de que no sea un fichero de tipo pdf

15

Diseño e implementación de interfaz de usuario para navegación a través de documento

Gestión de eventos sobre los botones de navegación

Renderizado de páginas del documento

16

Llamada al api REST para generación de presentación

Creación de servicio web para creación de presentaciones

Generación de url asociada a la presentación y envío a la aplicación web

Guardado de la url en local storage

Diseño e implementación de interfaz de usuario para mostrar url asociada a presentación

17

Redirección de url a aplicación web

Realizar petición de fichero al api REST

Comprobar en el servicio web de descarga de ficheros que existe una presentación para el fichero asociado y que el token de la url es correcto

Visualización de fichero asociado a url en aplicación web

Mostrar alerta en caso de error o acceso no autorizado.

18

Creación de servicio web para gestión de mensajes de presentaciones

Creación de namespace asociado a la presentación al iniciar presentación

Envío de mensajes al namespace de la presentación en los eventos de cambio de página

Conexión al namespace de la presentación cuando un espectador accede al url de una presentación


Replica de mensajes del namespace a todos los espectadores de dicho namespace

Gestión de eventos de cambios de página en el visualizador de los espectadores

19

Guardado de última página visualizada para cada namespace

Envío de mensaje de página actual a espectador recién conectado

Gestión de mensaje de página actual para mostrar dicha página

20

Gestión de eventos de cerrado de presentación

Realizar petición al api REST para eliminación de presentación

Creación de servicio web para borrado de presentaciones

21 Automatización de borrado de instancias antiguas de presentaciones en base de datos

Tabla 2.2 – Tareas

2.6. Estudio de viabilidad

En este apartado realizaremos un análisis sobre la viabilidad de este proyecto,

tanto para su presentación para la asignatura de Trabajo de Fin de Grado, como para

una posterior puesta en marcha en el mercado.

2.6.1. Análisis de tiempos de desarrollo

Como podemos observar de los puntos anteriores, el ámbito de nuestro proyecto

queda constituido por un conjunto de 21 historias de usuario que, en total, suman una

estimación de 108 puntos de historia.

A partir del trabajo del alumno en proyectos similares, y teniendo en cuenta la

limitación de horas disponibles en el día a día, se estima que el alumno será capaz de

alcanzar una media de 10 puntos de historia por cada ciclo de iteración bisemanal

trabajando durante 3 horas por cada jornada laboral.


Esta estimación nos llevaría a la necesidad de contar con 11 ciclos de iteración,

o lo que es lo mismo, 22 semanas naturales. Esto es, 5 meses y medio

aproximadamente.

El tiempo requerido para la realización de este prototipo de aplicación encaja

dentro de los límites establecidos para la asignatura de Trabajo de Fin de Grado, por

lo que podemos asegurar que este proyecto es viable para tal fin. Sin embargo, para

su posterior explotación comercial sería necesario el desarrollo de nuevas

funcionalidades que permitan monetizar el producto, lo que requeriría una mayor

dedicación de tiempo. En ese caso, la viabilidad del proyecto estaría comprometida a

un plazo de tiempo mayor al que permite esta asignatura.

2.6.2. Análisis de costes de desarrollo para este proyecto

Para la puesta en marcha del proyecto contaremos con el mínimo número

necesario de roles que se describirán a continuación. Más adelante, una vez el

proyecto empezara a generar beneficios, se podrían incluir nuevos roles que cubrieran

necesidades mucho más específicas.

Analista de negocio: será la persona encargada de gestionar los requisitos

de las funcionalidades a desarrollar. Su trabajo comprenderá el desglose

de cada nueva característica para una mejor definición de la misma.

Participará con el resto del equipo en la elaboración de las historias de

usuario, aportando siempre un punto de vista técnico enfocado a los

requisitos. Es el principal encargado de definir de forma clara y concisa el

ámbito del problema.

Programador: será el encargado de diseñar e implementar la solución

técnica ante el problema definido por el analista de negocio. Participará

también en la elaboración y valoración de las historias de usuario,

aportando en este caso un enfoque basado en la complejidad del software

a desarrollar. Debe velar por la seguridad, estabilidad y escalabilidad del

producto.

Diseñador de interfaz de usuario: la persona al cargo de este rol deberá

diseñar desde un punto de vista estético y funcional la capa de interacción


de nuestro software con el usuario. Será el principal encargado de

garantizar que la experiencia de uso sea satisfactoria y el producto resulte

intuitivo en su utilización.

Analista de calidad: este rol es el asociado a aquella persona que debe

velar por la calidad de nuestro software. Su principal objetivo es garantizar

que nuestra solución al problema cumple con todos los requisitos

establecidos. Definirá y aplicará los procesos de prueba que deberán

aplicarse al final de cada iteración para asegurar que el producto cumple

con lo demandado.

La tabla 2.3 incluye una estimación de salarios basado en el convenio colectivo

de Telefónica publicado en el BOE a fecha de 21 de enero de 2016 [8] para una

jornada regular de 160 horas mensuales y el cálculo proporcional al trabajo de una

hora para cada uno de estos roles.

Rol – rango salarial Sueldo mensual Sueldo por hora

Analista de negocio –

Titulado Superior o Máster

Nivel 5

3.655,67 € 22,84 €

Programador – Técnico

Medio o de Grado Nivel 5 3.011,67 € 18,82 €

Diseñador de interfaz de

usuario – Operador

Audiovisual Nivel 5

2.376,85 € 14,86

Analista de calidad –

Técnico Medio o de Grado

Nivel 5

3.011,67 € 18,82 €

Tabla 2.3 – Sueldos

A continuación, realizamos una estimación de las horas de trabajo que conllevará

cada una de las tareas en que se descompone el proyecto para cada uno de los


diferentes roles. De esta forma, podremos tener un cálculo aproximado del número de

horas que serán necesarias de trabajo de cada rol.

Tareas Horas analista Horas

programador

Horas

diseñador

de

interfaz

Horas

analista

de

calidad

Instalación de la base de datos

1

Instalación del servidor para el back-end

2

Creación de modelos de fichero y usuario

1 1

Creación del servicio web para recuperar los datos de ficheros asociados a un usuario

1 2 1

Instalación del servidor para la aplicación web

1

Diseño y creación de interfaz de usuario para la lista de ficheros en la aplicación web

1 2 3 2

Realizar solicitud de ficheros desde la aplicación web al api REST

2

Actualizar la lista de ficheros en la interfaz de usuario

1 2

Modificación de interfaz de usuario para permitir añadir nuevos ficheros

2 2 1

Lógica de envío de ficheros desde la aplicación web al api REST

4 1 3

Creación del servicio web en el api REST para añadir nuevos ficheros

2

Persistencia de los nuevos ficheros en base de datos

2 2

Persistencia de los nuevos ficheros en disco en el servidor del back-end

2 3

Refrescar la lista de ficheros cuando llegue la

2 1


respuesta del back-end tras haber añadido nuevos ficheros.

Modificar la interfaz de usuario para permitir descargar cada fichero existente

1 2

Realizar petición de descarga al api REST

2

Crear servicio web para descargar un fichero

2

Recuperar instancias de fichero de la base de datos

2

Recuperar fichero de disco duro y devolverlo como respuesta

3 2

Diseño e implementación de la interfaz de usuario para mostrar alertas.

2 3

Gestión de alertas al mostrar la lista de ficheros

2 2

Gestión de alertas al añadir ficheros

2 2

Gestión de alertas al descargar ficheros

2 2

Diseño e implementación de interfaz de usuario de login

1 2 3

Realizar petición de autentificación al api REST

2

Crear un servicio web para autentificación

2

Redireccionamiento a pantalla principal tras login exitoso

2 2

Redireccionamiento a pantalla de login tras intentar acceder a cualquier ruta sin estar autenticado

2 2

Generación de tokens en el servicio web de login y envío a cliente

1 2

Envío de token en cada petición desde la aplicación web

2

Comprobación de token en cada acceso al API REST salvo el login

2


Diseño e implementación de la interfaz de usuario paginada

2 2

Gestión de cambio de páginas

2 2

Diseño e implementación de la interfaz de usuario de logout

2 2

Borrado de token de web storage

2

Redirección a pantalla de login

2 2

Gestión de subida de ficheros con nombres ya existentes

2

Muestra de alerta 1 2

Diseño e implementación de interfaz de usuario para creación de cuentas

2 1 1

Realizar petición de creación de cuenta al api REST

2

Creación de servicio web para creación de cuentas

2

Generación de enlace tras crear cuenta

1 3

Envío de enlace a la dirección de correo electrónico asociada a la cuenta

2 2 3

Redirección del enlace a pantalla de login de la aplicación web

3 2

Petición de validación al api REST

2

Creación de servicio web para validación de cuentas

2

Notificación de éxito o error

2 1

Diseño e implementación de interfaz de usuario para visualización de ficheros pdf

4 2 2

Solicitud de fichero al api REST con autentificación

2

Implementación de visualización de fichero pdf

4 2

Comprobación de tipo de fichero al solicitar visualización

2 1


Mostrar alerta en caso de que no sea un fichero de tipo pdf

2 1

Diseño e implementación de interfaz de usuario para navegación a través de documento

1 2 2

Gestión de eventos sobre los botones de navegación

2

Renderizado de páginas del documento

3

Llamada al api REST para generación de presentación

2

Creación de servicio web para creación de presentaciones

1 2

Generación de url asociada a la presentación y envío a la aplicación web

1 2

Guardado de la url en local storage

2

Diseño e implementación de interfaz de usuario para mostrar url asociada a presentación

2 2 1

Redirección de url a aplicación web

2 2

Realizar petición de fichero al api REST

2

Comprobar en el servicio web de descarga de ficheros que existe una presentación para el fichero asociado y que el token de la url es correcto

3 1

Visualización de fichero asociado a url en aplicación web

2 1 2

Mostrar alerta en caso de error o acceso no autorizado.

2 1

Creación de servicio web para gestión de mensajes de presentaciones

3

Creación de namespace asociado a la presentación al iniciar presentación

1


Envío de mensajes al namespace de la presentación en los eventos de cambio de página

2

Conexión al namespace de la presentación cuando un espectador accede al url de una presentación

2

Réplica de mensajes del namespace a todos los espectadores de dicho namespace

2

Gestión de eventos de cambios de página en el visualizador de los espectadores

2 2

Guardado de última página visualizada para cada namespace

2

Envío de mensaje de página actual a espectador recién conectado

1

Gestión de mensaje de página actual para mostrar dicha página

1 1

Gestión de eventos de cerrado de presentación

1

Realizar petición al api REST para eliminación de presentación

2

Creación de servicio web para borrado de presentaciones

2 1

Automatización de borrado de instancias antiguas de presentaciones en base de datos

1 2 1

TOTAL 16 159 26 53 Tabla 2.4 – Horas según rol

Teniendo en cuenta estas estimaciones de horas y el sueldo promedio por hora

de cada rol, podemos realizar el siguiente presupuesto de gastos en salarios para la

elaboración de este proyecto. Podemos comprobarlo en la tabla 2.5.


Rol – rango salarial Sueldo por hora Horas Coste total

Analista de negocio –

Titulado Superior o

Máster Nivel 5

22,84 €

16 365,44 €

Programador –

Técnico Medio o de

Grado Nivel 5

18,82 €

159 2992,38 #

Diseñador de interfaz

de usuario –

Operador Audiovisual

Nivel 5

14,86

26 386,36 €

Analista de calidad –

Técnico Medio o de

Grado Nivel 5

18,82 €

53 997,46 €

Coste total 4.741,64 €

Tabla 2.5 – Costes de salarios

Como podemos ver, los costes de salarios para la realización de este proyecto

supondrían un total de 4.741,64 € aproximadamente.

El resto de elementos necesarios para el desarrollo de este proyecto no han

supuesto coste alguno, a saber:

Equipo portátil para el desarrollo: ya disponible previamente.

Suscripción a GitHub para repositorios privados: gratuita gracias al

acuerdo de la Universidad de Jaén.

Suscripción a Heroku: la versión gratuita ha sido suficiente para lo

necesario durante esta primera versión.

Por tanto, el coste total del desarrollo de este proyecto se remite directamente al

coste de salarios, esto es 4.741,64 €.


2.6.3. Análisis de explotación

A continuación, realizamos un análisis sobre el futuro de este proyecto. Esto es,

en caso de continuar con este desarrollo y crear una empresa con el fin de explotar

este producto, ¿cuáles serían los costes?, ¿qué volumen de usuarios necesitaríamos

para que la actividad fuera sostenible? En este apartado intentaremos aclarar estas

cuestiones.

La idea de negocio de este proyecto conlleva la necesidad de un equipo de

desarrollo estable que aporte de manera continua nuevas funcionalidades al producto

principal de la compañía. Esta situación deberá mantenerse una vez el producto

mínimo viable haya sido liberado al mercado. Por tanto, en lugar de realizar una

estimación de horas de trabajo necesarias para cada rol, se establece que los

contratos serán indefinidos y el cálculo de los costes de desarrollo asociados a los

salarios será por meses completos y no por horas de trabajo.

El modelo de explotación diseñado para nuestro proyecto seguiría el paradigma

freemium, esto es, ofreceríamos el servicio a todo el mundo de forma gratuita para

garantizar que el sistema se da a conocer y la gente puede probarlo en cualquier

momento. Esta versión sin embargo sería una versión limitada, con poco espacio de

almacenamiento y alguna restricción respecto al número de espectadores.

Para complementar a esta versión, existiría también una versión de pago con

más almacenamiento y número de espectadores ilimitados para las presentaciones.

Además, existiría la posibilidad de conseguir espacio adicional.

Para calcular el precio que debería tener la versión de pago, realizaremos una

estimación de costes y beneficios mediante varios escenarios.

Para las cuentas gratuitas hemos decidido que el espacio disponible será de 100

MB, mientras que para las cuentas premium el espacio será de 1 GB con opción de

ampliación.


Basándonos en los planes de de pago de Heroku [9], esto nos supone unos

costes por usuario gratuito de 0,2 € y de 2 € por usuario premium en la modalidad

standard 6 de los planes que ofrece dicha empresa.

Como desconocemos el porcentaje de nuestros usuarios que optarán por una

cuenta de pago, realizaremos tres estimaciones diferentes.

Estimación

pesimista

Estimación

realista

Estimación

optimista

Usuarios de

pago /

usuarios

totales

1 / 1000 1/100 1/10

Precio mínimo

para usuario

de pago

202 € 22 € 4 €

Tabla 2.6 – Estimaciones porcentaje de usuarios premium

Como podemos ver en la tabla, la estimación pesimista queda un poco fuera de

lugar, ya que en este caso los costes serían tan elevados que nuestra empresa habría

fracasado y no sería viable.

Por tanto, decidimos apostar por la estimación realista como opción más

aproximada a una posible realidad. Para facilitar aún más las cosas a nuestros clientes

premium, optamos por no generar beneficios mediante la venta de espacio añadido.

Esto es, por cada gigabyte extra que requiera el cliente, el precio será de 2 € al mes,

que es lo que el mismo volumen de gastos que le supone a nuestra empresa.

Basándonos en la estimación del escenario realista, aplicamos un porcentaje del

25% para generar beneficios, lo que nos daría un precio final de 27,5 € para las

cuentas premium. Esta cuantía puede parecer algo elevada para un uso particular,

pero resulta un gasto casi irrisorio para una empresa que quiera obtener estos

servicios, y son ellas quienes constituirían nuestro principal nicho de mercado. En un


futuro, podríamos estudiar la posibilidad de ofrecer una versión de coste menor para

particulares, pero de momento, la mejor opción parece apostar por lo simple.

A los costes del servicio de Heroku, habría que añadir los costes mensuales

salariales del equipo de desarrollo y mantenimiento. También debemos tener en

cuenta otros elementos necesarios, todos estos quedan reflejados en la tabla 2.7.

Concepto Cuantía/mes

Coste mensual de salarios 12.055,86 €

Coste mensual de espacio de coworking

en Jaén para 4 personas 280 €

Suscripción empresarial a GitHub 7 €

Suscripción avanzada a Heroku 25 €

Alquiler mensual de 4 ordenadores

portátiles 180 €

TOTAL 12.547,86 €/mes

Tabla 2.7 – Costes empresariales de desarrollo y mantenimiento

Ahora, una vez definidos todos los costes y beneficios globales, podemos

calcular el mínimo número de usuarios que nuestro sistema necesitaría para empezar

a producir beneficios. Esto lo hacemos mediante la siguiente ecuación.

Ingresos - costes = 0

Y desarrollando tenemos que:

X · 0,01 · 27,5 – ( X · ( 0,01 · 2 + 0,99 · 0,2 ) + 12.547,86 ) = 0

Donde X es el número de usuarios totales de nuestro sistema. Despejando esta

variable tenemos que:

X = 220. 138 usuarios


Es decir, con un ratio de un usuario premium por cada cien usuarios totales,

necesitaríamos un mínimo de 220.138 usuarios totales para cubrir todos los gastos y

empezar a generar beneficios.

Como podemos ver en la gráfica, la diferencia entre nuestros beneficios y

nuestros costes crecerá en mayor medida conforme aumente nuestro número de

usuarios. De ahí, que nuestro principal objetivo debería ser llegar al mayor número

posible de personas. Esto da sentido al hecho de ser un sistema basado en la nube,

el cual convertiría a todo el mundo con acceso a internet en nuestro mercado. También

aquí encuentra su razón de ser el modelo freemium, ya que nos permite, por un lado,

darnos a conocer y que cualquier persona pueda utilizar la aplicación en un momento

dado y, por otro lado, monetizar nuestro servicio mediante el acceso a funcionalidades

más avanzadas a cambio de una cuota mensual.

Ilustración 2.8 – Beneficios en relación al número de usuarios

2.7. Modelo de dominio

A partir de las historias de usuario de que se compone el proyecto, elaboramos

el siguiente modelo de dominio. Al habernos centrado en una solución sencilla pero

que esconde mucho potencial, nuestro modelo de dominio es muy sencillo, pues tan

sólo consta de varios conceptos y algunas relaciones entre ellos.

-500.000,00 €

0,00 €

500.000,00 €

1.000.000,00 €

1.500.000,00 €

2.000.000,00 €

2.500.000,00 €

3.000.000,00 €

Ingre

sos -

coste

s

Usuarios

Ingresos - costes


Ilustración 2.9 – Modelo de dominio

2.8. Análisis de la interfaz

Para el análisis previo al diseño de la interfaz de usuario, nos basaremos en el

siguiente estudio de algunos de los perfiles de personas que utilizarán nuestro

sistema.

Persona 1

Nombre: Eddie

Trabajo: Estudiante

Conocimientos técnicos: tiene un nivel medio de ofimática con ordenadores,

está acostumbrado a trabajar con aplicaciones webs así como con

aplicaciones móviles.

Fin: Eddie utiliza la aplicación para realizar una presentación sobre uno de

sus trabajos en clase. Necesita que el proceso sea rápido para poder

empezar la presentación cuanto antes y que el paso de páginas se produzca

en tiempo real.

Persona 2

Nombre: Laura

Trabajo: Profesora de universidad


Conocimientos técnicos: Laura está acostumbrada a redactar documentos

mediante su portátil, así como a utilizar programas destinados con su área

de investigación. A veces consulta redes sociales o páginas para informarse.

Fin: Laura necesita utilizar nuestro sistema para su uso diario en sus clases.

Le gustaría poder guardar varios de sus ficheros sobre presentaciones y ver

un listado de ellos de forma rápida y concisa para poder iniciar una

presentación sobre uno de ellos. En ocasiones, realiza ponencias online y le

vendría bien tener una herramienta que le permita dar la posibilidad a sus

oyentes de no estar necesariamente en presencia física.

Persona 3

Nombre: Arturo

Trabajo: Responsible de ventas de seguros

Conocimientos técnicos: Arturo está acostumbrado a utilizar su ordenador en

su día a día para realizar presupuestos y manejar contabilidades. Tiene un

iPhone mediante el cual gestiona su correo corporativo ya que su trabajo le

obliga conlleva tanto trabajo de oficina como desplazamientos sobre el

terreno.

Fin: A menudo Arturo tiene que realizar pequeñas presentaciones en

reuniones con compañeros de trabajo para definir algún plan de actuación.

En otras ocasiones, Arturo explica a sus posibles clientes o empresas

colaboradoras, las bondades de las ofertas que su compañía ofrece. En

ambos casos, Arturo necesita poder realizar presentaciones de forma ágil y

poder manejar el sistema desde su móvil para no tener que depender de

moverse con un ordenador portátil.

Persona 4

Nombre: Andrea

Trabajo: Fisioterapeuta, autónoma

Conocimientos técnicos: Andrea no ha tenido mucho contacto con las

tecnologías de la información. En ocasiones utiliza alguna aplicación de

mensajería desde su ya antiguo móvil. Es capaz de navegar en internet por

páginas simples para buscar alguna información en un momento puntual.

Fin: Andrea se ha apuntado a un curso para ahondar en sus conocimientos

sobre la técnica de fisioterapia manipulativa. Sin embargo, el curso se realiza


en Madrid y Andrea vive en Vigo. Para facilitar el seguimiento a los alumnos

inscritos no residentes en Madrid, la institución que imparte el curso ha tenido

a bien utilizar nuestro sistema. Andrea necesita poder seguir la presentación

del curso desde cualquier dispositivo con conexión a internet ya que, al

trabajar como autónoma, no sabe muy bien en qué lugar se encontrará a la

hora de realización del curso.

Tabla 2.8 – Personas

De este estudio, extraemos algunos de los requisitos que serán necesarios en el

posterior diseño de la interfaz de usuario de nuestra aplicación:

Debemos contar con una pantalla inicial que muestre de forma clara los ficheros

del usuario

Debe existir algún menú auxiliar en la pantalla inicial para realizar otras

operaciones complementarias.

La interfaz debería ser utilizable en dispositivos con una gran variedad en

cuanto a tamaños de pantalla, ya que podría ser utilizada desde un ordenador

de escritorio, portátil, tablet, móvil o cualquier otro dispositivos con conexión a

internet y un navegador moderno.

Debe existir un modo presentación en el que se pueda visualizar de forma

cómoda el archivo de la presentación.

Los espectadores de presentaciones deberían acceder directamente a la

presentación para facilitar su seguimiento a personas de diversas capacidades

tecnológicas.

3. Diseño

En esta sección, una vez ya realizado un análisis completo, procederemos a

detallar de manera especificada la solución al problema que pretendemos abordar.

Para ello, nos basaremos principalmente en distintos diagramas que tratarán de

mostrar una idea lo suficientemente detallada de cómo queremos construir el sistema.

Estos diagramas serán los de entidad-relación, de componentes y de secuencia.


Posteriormente, realizaremos un diseño de la interfaz de usuario en base a los

requisitos obtenidos en el análisis realizado en el punto anterior.

3.1. Diagrama Entidad-Relación

Una vez tenemos una idea del modelo de dominio de nuestro sistema, podemos

definir un esquema con el que comenzaremos nuestro modelo de entidad relación. En

este caso, puesto que pretendemos aplicar llamadas asíncronas para realizar las

presentaciones, nuestra base de datos no necesitará almacenar información sobre los

espectadores o los eventos de cambio de página. Por tanto, el diagrama inicial que

representa nuestras entidades y relaciones es el siguiente.

Ilustración 3.2 – Diagrama Entidad Relación

3.1.1. Proceso de normalización

A continuación, podemos comenzar a aplicar a este diagrama el proceso de

normalización. Este proceso consiste en la aplicación de 3 fases con unas reglas

definidas que garantizarán que nuestro esquema de base de datos es óptimo. Esto

es, que no presenta redundancia de datos o campos innecesarios.

La realización de este proceso nos servirá para ocupar un menor volumen de

espacio en disco conforme nuestra base de datos crezca, así como para facilitar el

mantenimiento en caso de que sea necesario realizar borrado de datos o

reestructuraciones del esquema.


3.1.2. Primera forma normal (FN1)

Para aplicar la primera fase de normalización, necesitaremos aplicar las

siguientes reglas:

Eliminación de los grupos de repetición en cada una de las tablas.

Creación de una tabla independiente para cada conjunto de datos.

Definición de una clave primaria para cada tabla.

Para aplicar la primera forma normal, damos valores a algunas tuplas en cada

una de las tres tablas que tenemos definidas

Usuario

Id Username Email Pass Validated

1 pepe [email protected] Abwgys5 True

2 antonio [email protected] adrTuIi0 False

3 luz [email protected] 1a2b3c4d True

4 max [email protected] maxJayMax12! True

Tabla 3.1 – Tuplas de usuarios

File

Id Name

1 tfg.pdf

2 Presentación.ppt

3 calendario.jpg

Tabla 3.2 – Tuplas de ficheros

Presentation

Id timestamp

1 01/02/16 14:55

2 03/07/12 13:22

Tabla 3.3 – Tuplas de presentaciones

mailto:[email protected]





Como vemos, ninguna de ellas presenta grupos de repetición, pues tienen, para

cada tupla, un único valor en cada columna.

Además, definimos en cada una de dichas tablas su “Id” como clave primaria. Si bien

es cierto, que en la tabla de Usuario podríamos haber definido la columna

“Username” como clave primaria, hemos optado por elegir el campo Id para que, en

caso de que nuestro usuario desee cambiar su nombre de usuario en el futuro, no

sea necesario cambiar todas las referencias de ficheros a esa tupla.

Por tanto, podemos garantizar que nuestro diagrama de Entidad-Relación ya está en

primera forma normal (FN1) y quedaría de la siguiente forma:

Ilustración 3.2 – Diagrama Entidad Relación FN1

3.1.3. Segunda forma normal (FN2)

El proceso de conversión a segunda forma normal consiste en la supresión de

dependencias parciales sobre claves compuestas. Consta de la aplicación de las

siguientes reglas:

Tablas independientes para valores que se apliquen a múltiples tuplas.

Relacionar estas tablas mediante una clave externa

Puesto que ninguna de nuestras tablas contienen claves compuestas, podemos

asegurar que nuestro diagrama ya cumple con la segunda forma normal (FN2).


3.1.4. Tercera forma normal (FN3)

La tercera forma normal es la que asegura que no existen campos que dependan

de otros campos que no sean la clave primaria.

En nuestra tabla Usuario, vemos que cada uno de sus campos, no tiene sentido

sin la presencia de un Id que haga referencia a un usuario concreto.

En el caso de la tabla File, no tiene cabida un nombre de fichero sin un id de

fichero. Lo mismo para la tabla Presentation.

Podemos asegurar por tanto, que nuestro diagrama de entidad-relación se

encuentra en tercera forma normal.

3.2. Diagrama de componentes

Nuestra idea inicial consiste en utilizar Node.js8 para la implementación del

servicio REST y angularJS para el desarrollo de la aplicación web que consuma dicho

servicio.

Puesto que ambas herramientas están muy enfocadas al uso de componentes,

este diagrama toma especial interés. En él, podremos definir las partes esenciales en

que se distribuirá nuestro sistema y cómo interactuarán entre ellas.

Nuestro sistema constará de dos partes bien diferenciadas. Por un lado, el

servicio REST que ofrecerá una interfaz que pueda ser utilizada por cualquier

aplicación que quiera desarrollarse para tal fin. Por otro lado, nuestra aplicación web

que consumirá el servicio REST ofrecido y que nos permitirá hacer uso de toda su

funcionalidad.

El siguiente diagrama muestra los componentes del sistema de back-end. Cada

componente define una interfaz que será utilizada por otros componentes. Como

podemos ver, a la derecha quedan definidas las interfaces de los componentes que

8 Node.js: Entorno de servidor basado en el lenguaje de programación javascript.


compondrán el API REST para que nuestra aplicación web pueda comunicarse con

dicho sistema.

Ilustración 3.3 – Diagrama de componentes de back-end

Por otro lado, tendremos los componentes de la aplicación web. Podemos ver

su estructura en la ilustración 3.4.


Ilustración 3.4 – Diagrama de componentes de aplicación front-end

3.3. Diseño de la interfaz de usuario

Basándonos en el análisis realizado en el punto 2.8, decidimos realizar una

interfaz de usuario sencilla y fácil de entender que pueda adaptarse a pantallas de

diferentes tamaños para ser utilizada en dispositivos de distinto tipo.

Necesitaremos una pantalla de login, una pantalla que nos muestre al usuario el

listado de sus ficheros en el sistema y permita interactuar con ellos y, por último, una

pantalla que permita la visualización de ficheros pdf tanto en modo presentador como

en modo espectador.


Ilustración 3.5 – Pantalla de login

Ilustración 3.6 – Pantalla de lista de ficheros


Ilustración 3.7 – Pantalla de visualización de ficheros

4. Implementación

Este apartado se enfoca en el desarrollo del sistema una vez realizado su

análisis y diseño. A través de los siguientes apartados trataremos de explicar los

aspectos más relevantes de la implementación que se ha seguido durante el

desarrollo de este proyecto. Además, se justificarán algunas de las decisiones que se

han tomado desde un punto de vista técnico.

Para mayor claridad, este apartado se divide en dos secciones bien diferencias.

En primer lugar, una sección más generalista sobre la arquitectura del sistema y sus

ventajas. Durante la misma, trataremos de dar una visión global del proyecto haciendo

hincapié en los temas más importantes que se han tenido en cuenta durante el

desarrollo relativos a la estructura del producto.

En segundo lugar, otra sección mucho más detallista se centrará en cada una de

las herramientas con que se ha construido el proyecto.Trataremos de explicar las

particularidades de cada una de ellas así como su elección y encaje dentro de este

trabajo.


4.1. Arquitectura

Este proyecto software consiste en una aplicación en la nube, que permita

realizar presentaciones sobre documentos a cualquier persona con una conexión a

internet independientemente del tipo de dispositivo desde el que acceda.

Además, necesitaremos que la comunicación se produzca en tiempo real, pues

cualquier retraso en la transmisión de los mensajes, frustaría la experiencia de

usuario.

Teniendo estas particularidades en cuenta, nuestros principales objetivos

durante la implementación del sistema serán:

Conseguir un sistema versátil, que pueda ser fácilmente adaptado

a cualquier plataforma.

Asegurar que nuestro sistema pueda adaptarse fácilmente a retos

futuros como mayor volumen de tráfico o nuevas plataformas.

Inmediatez en la realización de presentaciones.

Mediante los siguientes puntos, ponemos de manifiesto las decisiones tomadas

para la consecución de dichos objetivos.

4.1.1. Escalabilidad9

Como ya hemos comentado, uno de los principales retos de nuestro sistema

consistirá en su capacidad para adaptarse a los cambios. Un problema común en

desarrollos de productos software ocurre cuando un sistema pensado para ser

utilizado con un volumen relativamente estable de usuarios, pasa a ser utilizado con

volúmenes de tráfico mucho mayores. Esto puede llegar a suponer retrasos en las

9 Escalabilidad: En telecomunicaciones y en ingeniería informática, la escalabilidad es la propiedad deseable de un sistema, una red o un proceso, que indica su habilidad para reaccionar y adaptarse sin perder calidad, o bien manejar el crecimiento continuo de trabajo de manera fluida, o bien para estar preparado para hacerse más grande sin perder calidad en los servicios ofrecidos. En general, también se podría definir como la capacidad del sistema informático de cambiar su tamaño o configuración para adaptarse a las circunstancias cambiantes.[11]


comunicaciones, denegaciones de servicio, inestabilidad o incluso inoperatividad del

sistema.

Otra característica que puede hacer no escalable un proyecto es su dependencia

de una plataforma concreta o de un lenguaje de programación que caiga en desuso y

deje de ser soportado.

El mundo de la tecnología cambia constantemente, apareciendo nuevas

plataformas de forma continua que cambian la forma en que las personas interactúan

entre sí y con la información. Nuestro sistema debe ser capaz de adaptarse a todas

esas nuevas plataformas que puedan aparecer en el futuro, con los menores costes

de tiempo y desarrollo posibles, para poder competir en un mercado con tantas

alternativas.

Ejemplos comunes que hacen que una arquitectura no sea escalable hay

muchos. Desde aplicaciones para una plataforma (por ejemplo de escritorio o web)

que, posteriormente, necesitan utilizarse en móviles, hasta sistemas cuya base de

datos está ligada a una aplicación en sí, haciéndola inaccesible desde otras

aplicaciones.

Para evitar estos problemas, en este proyecto se aplica una estructura orientada

a servicios web10 [12]. Contamos con distintas piezas independientes que se unen

entre sí.

10 Servicios web: conjunto de aplicaciones o de tecnologías con capacidad para interoperar en la web. Estas aplicaciones o tecnologías intercambian datos entre sí con el objetivo de ofrecer unos servicios. Los proveedores ofrecen sus servicios como procedimientos remotos y los usuarios solicitan un servicio llamando a estos procedimientos a través de la web.


Ilustración 4.1 – Arquitectura

En primer lugar, un Sistema de Gestión de Bases de Datos independiente del

resto del sistema. Esto nos garantiza que en un momento dado, podamos migrar dicho

sistema a un servidor con mayores prestaciones, realizar duplicación del mismo o

simplemente instalarlo en una plataforma de terceros como AWS11 o Microsoft

Azure12.

Por otro lado, tendremos un sistema de back-end13, que se comunicará con el

Sistema de Gestión de Bases de Datos y que, a su vez, ofrecerá toda la funcionalidad

básica del sistema a través de un API basada en en un servicio web. De esta forma,

desligamos la funcionalidad que ofrece el sistema de una aplicación orientada a una

plataforma concreta. Así, nos aseguramos de que cualquier aplicación cliente que

necesitemos construir en un futuro, podrá comunicarse con dicha API para consumir

los servicios que ofrece. Ahondaremos más sobre este tema en el punto 4.1.2

especialmente destinado a ello.

11 AWS: Amazon Web Services. Plataforma de la empresa Amazon que ofrece servicios de computación en la nube bajo demanda. 12 Microsoft Azure: Plataforma de la empresa Microsoft que ofrece servicios de computación en la nube bajo demanda. 13 Back-end: hace referencia al trabajo puramente de servidor en un producto software. Esta capa ofrece una serie de servicios mediante una interfaz que serán utilizados por las aplicaciones clientes o front-end.


Por último, tenemos una aplicación web (parte front-end14) que hará uso de los

servicios que ofrece el back-end. Esta aplicación gestiona la interacción del usuario

con el sistema. Ha sido creada pensada para ser lo más versátil posible pero, gracias

a la arquitectura implementada, podríamos desarrollar cualquier otra aplicación para

cualquier plataforma que se comunique de igual manera con la capa de back-end.

La elección de una aplicación web como plataforma para la aplicación cliente se

debe principalmente a su capacidad para ser utilizada desde multitud de dispositivos.

Una aplicación web puede ejecutarse en cualquier dispositivo con un navegador y

conexión a internet. Desde ordenadores de escritorio a tabletas o teléfonos móviles

pueden hacer uso de sus ventajas.

Esta capacidad multiplataforma, también conlleva consigo que, para dotar a la

aplicación de una experiencia de usuario satisfactoria, su interfaz visual debe

adaptarse a multitud de diferentes formatos de pantallas. Para ello, utilizaremos un

framework15 de elementos visuales construido específicamente para este fin. Si bien

en el mercado existen numerosas opciones, nos decantamos por Bootstrap16 debido

a su comunidad y amplia documentación. Hablaremos más sobre Bootstrap en el

apartado 4.2 que hace referencia a tecnologías concretas.

Por otro lado, la elección de la web como plataforma de nuestra aplicación

cliente, también nos permite adaptar dicha aplicación para ser convertida con ciertas

herramientas a aplicaciones nativas de otras plataformas. En este sentido,

utilizaremos Gonative17 para poder portar dicha aplicación web a plataformas móviles

como Android o iOS sin tener que realizar un desarrollo específico para cada

plataforma.

14 Front-end: en contraposición al término back-end, front-end hace referencia al desarrollo de un sistema de software en la parte de la aplicación cliente, que gestiona la interacción del usuario con el sistema y hace uso de la funcionalidad que ofrece la capa de back-end. 15 Framework: en el desarrollo de software, un framework o infraestructura digital, es una estructura conceptual y tecnológica de soporte definido, normalmente con artefactos o módulos concretos de software, que puede servir de base para la organización y desarrollo de software. Típicamente, puede incluir soporte de programas, bibliotecas, y un lenguaje interpretado, entre otras herramientas, para así ayudar a desarrollar y unir los diferentes componentes de un proyecto. 16 Bootstrap: framework visual que ofrece herramientas para el desarrollo de aplicaciones cuya interfaz visual se adapta a diferentes tamaños de pantalla. 17 Gonative: herramienta que permite portar aplicaciones web a aplicaciones nativas para plataformas móviles.


Ilustración 4.2 – Conversión de aplicación web a aplicaciones móviles nativas

4.1.2. Servicio web (API)

La interfaz de nuestro servicio web o API18, puede construirse desde diferentes

enfoques. Entre los servicios web existentes en internet destacan principalmente dos

estilos distintos. Por un lado, los servicios de tipo SOAP19, más antiguos y basados en

el intercambio de información mediante datos en formato XML20. Por otro lado, los

servicios de tipo REST, que actualmente son la tendencia natural, y cuyo intercambio

de información puede realizarse mediante una gran variedad de formatos, aunque,

habitualmente se realice mediante formato JSON21.

En nuestro caso, servicio web estará implementado mediante el uso de un

servidor Node.js. Esta decisión viene marcada por el objetivo de inmediatez de que

necesitamos dotar a nuestro sistema. Node.js, ha demostrado en numerosos estudios,

resultar mucho más rápido y eficiente en la gestión de peticiones que otras tecnologías

de servidor como Java [13].

18 Bootstrap: framework visual que ofrece herramientas para el desarrollo de aplicaciones cuya interfaz visual se adapta a diferentes tamaños de pantalla. 19 SOAP: Simple Object Access Protocol (Protocolo de Acceso a Objeto Simple) es un protocolo que define como dos objetos en procesos diferentes pueden comunicarse entre sí a través del intercambio de información mediante ficheros XML. 20 XML: Extensible Markup Language (Lenguaje de Marcas Extensible) es un lenguaje de marcas desarrollado para el intercambio de información en sistemas software. 21 JSON: Javascript Object Notation (Objeto de Anotación de Javascript) es un formato de texto ligero para el intercambio de datos a través de sistemas software basado en la notación literal de objetos del lenguaje de programación javascript.


Node.js consigue esta eficiencia mediante el uso de operaciones asíncronas y

no bloqueantes a través de todo su diseño y no sólo en la gestión de operaciones de

entrada y salida. Esto consigue que, cuando se realizan operaciones que, a su vez

dependen de otras operaciones más lentas como una conexión a base de datos, el

sistema no permanece inactivo esperando una respuesta, sino que continúa su flujo

natural de ejecución y reacciona en consecuencia cuando cada petición ha sido

respondida.

Ilustración 4.3 – Gestión de peticiones en Node.js

Esta particularidad de Node.js será clave tanto en la realización de

presentaciones, donde el usuario necesita que los desplazamientos tengan el menor

retardo posible, como en la gestión de peticiones cuando crezca el volumen de tráfico

que nuestro servicio web tiene que gestionar.

Node.js está implementado en el lenguaje de programación javascript, utilizando

el motor V8. La elección de esta plataforma para nuestro back-end conlleva consigo

la elección natural del formato JSON para la transferencia de datos con la capa de

front-end.


A su vez, el marcado carácter web de nuestra aplicación, en conjunción con el

uso de JSON, hace de la elección del protocolo HTTP22 y del estándar REST para la

definición del API del back-end, una elección sencilla.

4.1.3. Front-end

Para el desarrollo de aplicaciones web del lado del cliente, existen numerosos

frameworks tanto de javascript, como de HTML23 y CSS24 que ofrecen multitud de

funcionalidades específicas.

Dentro del amplio abanico de frameworks para javascript, nos hemos decantado

por Angular.js. Entre sus bondades, destacan su sistema de “data binding”25, que

facilita enormemente la manipulación de la información, sus herramientas de

comunicación con servicios externos, que posibilitarán la comunicación con nuestra

capa de back-end, o la multitud de componentes externos adicionales que existen

para esta herramienta.

En cuanto a los elementos visuales, necesitamos una herramienta que nos

proporcione facilidad para la creación de una interfaz de usuario que se pueda adaptar

a pantallas de formatos muy diversos. En este sentido, existen muchas opciones como

Foundation26, Pure27, Ink 28o HTML KickStart29.

22 HTTP: Hypertext Transfer Protocol (Protocolo de Transferencia de Hipertexto) es el protocolo de comunicación que permite las transferencias de información en la web. 23 HTML: HyperText Makup Language (Lenguaje de Marcado de Hipertexto) es un lenguaje de etiquetas que se utiliza en la elaboración de la estructura del contenido en las páginas web. 24 CSS: Cascading Style Sheet (Hoja de estilos en cascada) es un lenguaje usado para definir los estilos visuales de un documento estructurado escrito en HTML, XML y XHTML. 25 Data binding: hace referencia sistema de mapeo de datos entre dos capas de software distintas de manera automática. 26 Foundation: framework visual especialmente orientado al desarrollo de pantallas adaptables a diferentes formatos. 27 Pure: biblioteca muy pequeña de elementos visuales que tan sólo utiliza CSS para la creación de layouts gráficos. 28 Ink: framework que se basa en la utilización de otras bibliotecas como Sass, Compass y Normalize.css para extender las funcionalidades del lenguaje CSS estándar. 29 HTML KickStart: framework de elementos visuales que incluye herramientas para el uso de tipografías, iconos, layouts y otros elementos web.


Sin embargo, nos decantamos por Bootstrap30, debido a los conocimientos

previos que el desarrollador de este proyecto ya tiene sobre esta herramienta, así

como a su comunidad, puesto que ésta es la principal alternativa en su sector.

4.1.4. Aplicación web convertible a aplicación móvil

Uno de los beneficios de las aplicaciones web, son su carácter multiplataforma,

lo que las hace aptas para su uso en multitud de dispositivos distintos.

Además, hoy en día el mercado del software brinda varias alternativas que nos

permiten portar aplicaciones web a aplicaciones nativas de otras plataformas como

pueden ser Android o iOS en dispositivos móviles, y Mac OS X, Windows o Ubuntu en

sistemas tradicionales de escritorio.

Si bien estas aplicaciones portadas nunca serán tan eficientes como

aplicaciones nativas desarrolladas sobre la propia plataforma, en casos como el actual

donde la necesidad de procesamiento no resulta elevada, ésta puede ser una buena

opción.

De esta manera, conseguimos que mediante un sólo desarrollo, podamos tener

una aplicación para un buen rango de plataformas distintas. En proyectos que

empiezan desde el principio y para empresas con pocos recursos, esta opción resulta

muy atractiva, pues los costes que supondrían el desarrollo de una aplicación

específica para cada plataforma, podrían resultar inasumibles.

Un buen enfoque consiste en empezar el proyecto con una aplicación web

adaptable a distintos dispositivos que nos permita llegar al mayor número de usuarios

posible. En caso de éxito, una vez nuestra empresa adquiera más recursos, se podría

valorar el desarrollo de aplicaciones específicas para cada plataforma.

30 Bootstrap: biblioteca de elementos visuales para el desarrollo de sitios web enfocados primero a su uso en dispositivos móviles. Fue desarrollado por la empresa Twitter que, más tarde, lo liberó como proyecto de código abierto para que pueda ser utilizado por los desarrolladores de todo el mundo.


Entre las alternativas para este fin destacan PhoneGap31 o Titanium32. No

obstante, en el proyecto actual hemos hecho uso de una nueva herramienta

denominada GoNative.io33 debido a su facilidad de uso.

Con GoNative.io se pueden crear paquetes instalables en dispositivos Android e

iOS con tan sólo insertar la dirección url del sitio donde se encuentre instalada nuestra

aplicación web.

Ilustración 4.4 – Captura de la aplicación exportada con GoNative.io funcionando como aplicación nativa en Android

31 PhoneGap: sistema para crear aplicaciones híbridas usando las tecnologías HTML5, CSS3 y Javascript, ejecutadas dentro de un componente WebKit del dispositivo móvil. 32 Titanium: sistema para crear aplicaciones nativas a partir de aplicaciones web que utilicen los estándares de HTML5, CSS3 y Javascript. 33 GoNative.io: herramienta que permite la conversión de aplicaciones web en paquetes instalables en dispositivos Android e iOS. Esta herramientas es una herramienta comercial de código cerrado. Si bien no podríamos utilizarla de forma comercial para explotar un sistema sin pagar su licencia, sí que podemos hacer uso de ella con el objetivo de creación de un prototipo. https://gonative.io/

https://gonative.io/


4.2. Detalles sore implementación

En este apartado nos centramos en detalles más específicos de la

implementación del sistema, así como en diferentes tecnologías y bibliotecas que se

han utilizado y el problema que han ayudado a resolver cada una de ellas.

4.2.1 Programación asíncrona en javascript

Si bien javascript como tal no implica el uso de programación asíncrona, la

implementación del motor V8 que utiliza Node.js sobre este lenguaje sí que lo hace.

En la práctica esto quiere decir que las operaciones de nuestro código no serán

bloqueantes, pues la ejecución del código continuará sin necesidad de tener que

ejecutar las operaciones de manera secuencial tal cual fueron escritas.

Este enfoque ha demostrado resultar mucho más eficiente puesto que las

operaciones costosas como acceso a base de datos o lectura de ficheros no ralentizan

al resto del programa.

En la utilización de llamadas asíncronas en javascript existen dos

aproximaciones diferentes, son los llamados callbacks34 y promises35.

En frameworks que se ejecutan asíncronamente por defecto como son Node.js

y Angular.js, el orden de ejecución de un programa no tiene por qué seguir el orden

secuencial en que están escritas las líneas de código en el código fuente. No sabemos

a ciencia cierta, si una sección de código se va a ejecutar antes o después que otra y,

por tanto, no sabemos por ejemplo si el resultado de una función ha sido ya resuelto

o no.

Sin embargo, siempre existen secciones que necesitamos que no sean resueltas

o procesadas hasta que otra lo haya sido previamente, puesto que existe una relación

34 Callback: en programación, una devolución de llamada o retrollamada (callback) es una función “A” que se utiliza como argumento de otra función “B”. Cuando se llama a “B”, ésta ejecuta a “A” tras su finalización. 35 Promise: es un objeto que se ejecuta en programación asíncrona. Puede encontrarse en tres estados diferentes: pendiente, cumplida o rechazada. Puede recibir manejadores de eventos que se ejecuten cuando la promesa sea resuelta ante un eventual éxito o fracaso.


de dependencia entre ellas. Es aquí donde son útiles estas dos aproximaciones, que

se utilizan para indicar que una función no debe ejecutarse hasta que otra lo haya

hecho previamente.

La aproximación mediante callbacks consiste en pasar como parámetro la

función dependiente a aquella de la cual depende. Al terminar su ejecución, esta

segunda función realizará una llamada a la función dependiente que le fue pasada

como argumento, pasándose a su vez como argumento el resultado de su propia

ejecución.

Podemos ver un ejemplo de esto en la ilustración 4.5. En este caso, la función

‘getUsersByUserName’ recibe a su vez dos funciones callbacks como parámetros,

‘onGetUserByUserNameFailed’ y ‘checkAuthenticationAndValidation’. En tiempo de

ejecución y una vez la primera llamada haya sido resuelta, ésta llamará a una de estas

dos funciones que se le han pasado como parámetros según cuál sea el resultado de

su propia ejecución.

Ilustración 4.5 – Callbacks (fichero: slidecloud/modules/controllers/auth_controller.js)

La aproximación mediante callbacks suele conducir a un problema conocido

como callback hell si no se presta especial atención a la estructuración ordenada del

código.

Podemos ver un ejemplo de este fenómeno en la ilustración 4.6.


Ilustración 4.6 – Callback hell

Este fenómeno se produce cuando tendemos a definir las funciones callback que

pasamos como argumentos en línea, de manera que al final nuestro código acaba

teniendo esta apariencia tan escalonada y difícilmente legible. Para evitarlo, es

importante definir cada función de forma apropiada, con su nombre correspondiente

como podemos ver en la ilustración 4.7.

Ilustración 4.7 – Evitar el ‘callback hell’ mediante la correcta definición de funciones (fichero: slidecloud/modules/controllers/file_controller.js)


En cuanto a los promises, estos utilizan los métodos “then” y “catch” para indicar

que una función debe ejecutarse al finalizar otra y qué función debe ejecutarse si se

produce un error, respectivamente. Podemos ver un ejemplo en la ilustración 4.8.

Ilustración 4.8 – Promises (fuente: slidecloud/modules/persistence/filesHandler.js)

En Node.js se puede programar utilizando tanto callbacks como promises, si bien

la plataforma está pensada desde sus inicios para la utilización de callbacks. En su

gran mayoría, las bibliotecas externas se encuentran implementadas siguiendo el

primer enfoque, mientras que tan sólo un margen residual hacen uso de los promises.

Para el desarrollo de un código limpio y legible resulta inevitable elegir uno de los dos

enfoques y realizar una adaptación de uno a otro cuando utilicemos una biblioteca que

utilice el enfoque contrario como podemos ver en la ilustración 4.8 donde el método

findAll utiliza promises mientras que nuestro sistema está pensado en callbacks.

Angular.js por su parte, hace uso de los promises, sin embargo esto no supone

ningún problema, puesto que la única comunicación entre front-end y back-end se

lleva a cabo mediante el intercambio de información en objetos JSON.


4.2.2 Componentes en Angular.js 36y Node.js

Tanto Node.js como Angular.js utilizan una arquitectura basada en

componentes37.

Ambos se sirven de las funcionalidades que ofrecen las palabras reservadas

exports y require para definir la interfaz de un módulo e importar otros módulos

respectivamente.

En la ilustración 4.9 podemos ver cómo el componente filesHandler importa a su

vez al módulo usersHandler y cómo define los métodos que ofrece en su interfaz para

que puedan ser utilizados por otros componentes.

Ilustración 4.9 – Componentes (fichero: slidecloud/modules/persistence/usersHandler.js)

La arquitectura orientada a componentes [14] se basa en la descomposición del

diseño en componentes funcionales o lógicos que expongan interfaces de

comunicación definidas. Define un nivel de abstracción mayor que el paradigma de

orientación a objetos y no trata asuntos relativos a los objetos como el envío de

mensajes o la representación de sus estados.

36 A lo largo, de este documento nos referimos siempre a la primera versión de Angular.js, puesto que la segunda versión recientemente liberada al mercado, supone un framework completamente distinto y diseñado desde cero. 37 Componente: un componente o módulo es un conjunto de funcionalidad de software que se encapsula en una unidad única de código y puede ser utilizada por otros componentes o realizar llamadas a otros componentes a su vez.


Los componentes pueden reutilizarse en diferentes partes de un proyecto o en

diferentes proyectos de software, así como ser extendidos para crear otro componente

con funcionalidad añadida.

4.2.3 Sequelize.js38

Para la comunicación entre el Sistema de Gestión de Bases de Datos y la capa

de back-end de nuestro sistema, resulta muy útil el uso de una herramienta de ORM39

o Mapeador Objeto-Relacional.

Una herramienta de ORM nos permite convertir los objetos con los que trabaja

nuestra lógica de negocio en entradas de una base de datos relacional y viceversa.

De esta forma, realizamos una abstracción sobre el lenguaje del Sistema de Gestión

de Bases de Datos y nos centramos en la lógica de negocio, ahorrándonos la

complejidad que supone la conversión de elementos de un modelo a otro.

En nuestro caso hemos optado por la biblioteca Sequelize.js ya que, al estar

desarrollada en javascript, encaja perfectamente dentro del conjunto de herramientas

que utilizamos en nuestro proyecto.

Sequelize.js soporta multitud de dialectos de bases de datos como PostgreSQL,

MySQL, SQLite y MSSQL. Su desarrollo mediante promises permite un gran soporte

de transacciones sólidas.

Esta herramienta también nos permite definir modelos y sus relaciones de

manera sencilla como podemos ver en la ilustración 4.10.

38 Sequelize.js: http://docs.sequelizejs.com/ 39 ORM: Object-Relational Mapping (mapeo objeto-relación) consite en una herramienta de comunicación entre la capa de lógica de negocio y la capa de persistencia de información de un sistema de software, que permite convertir objetos en instancias de una base de datos relacional.

http://docs.sequelizejs.com/


Ilustración 4.10 – Modelos y relaciones en Sequelize.js (fichero: slidecloud/modules/models/models.js)

4.2.4 Websockets y Socket.io

Una de las principales limitaciones de http y la estructura básica de internet

consiste que tan sólo está orientado para comunicaciones del tipo petición-respuesta.

Este modelo no permite, por ejemplo, que un servidor pueda comunicarse con una

aplicación cliente a voluntad si no es porque ésta ha realizado previamente una

petición.

Los websockets40 surgen para solucionar este problema. Son una tecnología

muy novedosa que utilizan el protocolo TCP41 para permitir comunicaciones

bidireccionales. En nuestro proyecto, ésta es una pieza clave pues al realizar

presentaciones, necesitamos que el presentador pueda enviar un evento de

desplazamiento a la capa de back-end y ésta a su vez debe enviar dicho evento a

todas las aplicaciones cliente que estén visualizando dicha presentación.

40 Websocket: tecnología que proporciona un canal de comunicación bidireccional sobre un único socket TCP. 41 TCP: Transmission Control Protocol (Protocolo de Transmisión de Control) es uno de los protocolos fundamentales en Internet.


Socket.io 42es un framework desarrollado en javascript que nos permite utilizar

esta tecnología en nuestros desarrollos.

En la ilustración 4.11 podemos ver un ejemplo de su utilización en este proyecto

para comenzar a escuchar eventos sobre una presentación.

Ilustración 4.11 – Utilización de Socket.io (fichero: slidecloud/modules/controllers/io_controller.js)

4.2.5 File upload

Angular File Upload43 es un pequeño módulo que facilita la tarea de realizar

subidas de ficheros desde una aplicación web con Angular.js. En nuestro caso la

hemos utilizado para la gestión de los ficheros que el usuario puede subir a su cuenta.

Soporta subidas de un único fichero o de varios de forma simultánea y trabaja con

cualquier extensión de fichero.

4.2.6 Git y Github

Durante el desarrollo de un proyecto de cierta envergadura, resulta

imprescindible la utilización de un sistema de control de versiones.

En el mercado contamos con varias alternativas como Team Foundation Server44

de Microsoft, Mercurial45 o Subversion46. Nos decantamos por Git47 por su popularidad

y facilidad de uso, por ser de código abierto y por la enorme comunidad con que cuenta

a sus espaldas.

42 Socket.io: http://socket.io/ es un framework que permite comunicación bidireccional en tiempo real basada en eventos mediante la utilización de web sockets. 43 Angular File Upload: https://github.com/nervgh/angular-file-upload 44 Team Foundation Server: https://www.visualstudio.com/en-us/products/tfs-overview-vs.aspx 45 Mercurial: https://www.mercurial-scm.org/ 46 Subversion: https://subversion.apache.org/ 47 Git es un sistema de control de versiones libre y de código abierto. https://git-scm.com/

http://socket.io/

https://github.com/nervgh/angular-file-upload

https://www.visualstudio.com/en-us/products/tfs-overview-vs.aspx

https://www.mercurial-scm.org/

https://subversion.apache.org/

https://git-scm.com/


Git nos ofrece la posibilidad de poder trabajar con distintas ramas y repositorios,

así como deshacer cualquier cambio para volver a un cierto punto en el desarrollo.

GitHub48 por su parte, es un portal web que nos ofrece la posibilidad de gestionar

nuestros propios repositorios utilizando el sistema de control de versiones Git.

Podemos interactuar con él a través del propio Git en línea de comandos o mediante

las distintas aplicaciones con interfaz de usuario que hacen uso del sistema.

En nuestro proyecto se ha trabajado en dos repositorios distintos, uno para la

capa de back-end, y otro para la aplicación web que consume el API de la primera

capa. En cada uno de estos repositorios se cuenta con una rama master donde se

almacena el código principal del proyecto, una rama development donde se incorporan

las últimas novedades que se van a incorporar a la rama master una vez se alcance

algún hito del proyecto, así como una rama para cada tarea específica de

programación que se irán uniendo a la rama de development. Por último, también

contamos con una rama de producción production que diferirá de la rama master en

cuestiones específicas al despliegue del sistema.

4.2.7 Heroku

A la hora de realizar un proyecto de desarrollo, resulta siempre interesante poder

contar con un entorno donde realizar una instalación del proyecto y poder realizar

pruebas de desarrollo o con usuarios para tener algún feedback sobre el

funcionamiento del mismo.

En este caso hemos utilizado Heroku49. Esta plataforma nos ofrece un plan

gratuito con especificaciones reducidas que resulta muy útil a la hora de poner en

marcha un proyecto con poco presupuesto. Podemos ampliar las funcionalidades que

nos brinda la plataforma conforme lo hagan las necesidades de nuestro sistema.

48 GitHub: portal web que permite alojar proyectos software mediante su gestión con Git. https://github.com/ 49 Heroku: plataforma web que nos permite realizar despliegues de proyectos software. https://www.heroku.com/

https://github.com/

https://www.heroku.com/


Además, Heroku ofrece la posibilidad de realizar despliegues automáticos desde

ramas y repositorios concretos de GitHub, lo que facilita mucho la integración con el

entorno de desarrollo.

4.2.8 Nodemailer

El proceso de creación de una cuenta en nuestro proyecto se realizar de igual

manera a como funcionan numerosos servicios hoy en día en internet. En primer lugar,

el usuario selecciona sus credenciales y asigna una cuenta de correo electrónico. El

sistema procederá entonces a enviar un correo electrónico a dicha cuenta a modo de

verificación. Dicho correo incluye un enlace a una url única que utilizará el sistema

como prueba de validación sobre dicha cuenta de correo electrónico.

Para el envío de correos electrónicos desde nuestro sistema, hemos utilizado la

biblioteca Nodemailer50. Ésta funciona sobre Node.js, lo cual encaja a la perfección

con nuestro proyecto, y nos permite enviar correos personalizados tanto con texto

plano como con plantillas que incluyan código HTML.

4.2.9 Autentificación, JSON web tokens y jwt.io

En el ámbito de un proyecto de software, hablamos de autentificación para

referirnos al procedimiento por el cual un usuario garantiza ser quien dice ser a la hora

de realizar una acción sobre el sistema. De esta forma nos aseguramos, por ejemplo,

de que tan sólo un usuario puede eliminar los ficheros de su propia cuenta.

Existen diversas maneras de implementar el proceso de autentificación en una

plataforma. En esta ocasión hemos optado por JSON web tokens51.

El procedimiento funciona mediante el cifrado de cierta información utilizando un

“secreto” o clave tan sólo conocida por quien realiza el cifrado y el algoritmo de cifrado

HMAC52. Una vez el usuario introduce sus credenciales de acceso al sistema y se

50 Nodemailer: biblioteca sobre Node.js que permite el envío de correos electrónicos. https://nodemailer.com 51 JSON web tokens: estándar abierto (RFC 7519) que define una forma compacta y autocontenida para transmisiones de información de forma segura entre dos partes en forma de objeto JSON. 52 HMAC: algoritmo de cifrado que combina una función hash criptográfica con el uso de una llave criptográfica secreta.

https://nodemailer.com/


comprueba la validez de las mismas, el sistema responde con un “token” que debe

ser enviado cada vez que se realice una operación. De esta forma, el sistema conoce

que el usuario que envía el token es quien dice ser.

Ilustración 4.12 – JSON web tokens (fuente: https://jwt.io/introduction/)

El protocolo JSON web tokens está definido en su totalidad por la IETF53 y cuenta

entre sus ventajas con el hecho de ser compacto, lo que permite que los “tokens”

puedan ser enviados a través de la red como parámetros de una petición de tipo POST

o dentro de la propia cabecera.

Además, son autocontenidos, es decir, el “token” contiene dentro de sí toda la

información sobre el usuario, evitando tener que realizar un mayor número de

consultas a la base de datos.

Para la aplicación de este procedimiento hemos utilizado el framework jwt.io54

que permite utilizar el estándar de JSON web tokens en multitud de plataformas como

.NET, Python, Node.js, Java, Perl o Ruby.

53 IETF: Internet Engineering Task Force define el estándar de JSON web tokens en https://tools.ietf.org/html/rfc7519 54 JWT.io: framework que permite aplicar el estándar de autentificación JSON web tokens.

https://tools.ietf.org/html/rfc7519


4.2.10 Pdf.js

En cuanto a la visualización de documentos en nuestro sistema, hemos

implementado soporte para los ficheros con extensión “pdf”55. Para esta labor hemos

utilizado la biblioteca “pdf.js” desarrollada por Mozilla, que nos permite poder realizar

lecturas desde documentos de tipo “pdf” desde nuestra propia aplicación web en el

navegador web.

4.2.11 Bower

Como hemos visto hasta ahora, el desarrollo de un proyecto conlleva el uso de

diferentes herramientas y bibliotecas. Si bien gestionar esta tarea puede parecer

sencillo en un principio, se vuelva más compleja conforme aumenta el número de

herramientas externas de las que depende nuestro proyecto.

En este sentido, un gestor de paquetes es siempre una buena opción para

mantener de forma ordenada las librerías que vamos añadiendo al proyecto.

Hemos utilizado Bower en la aplicación web, una herramienta especialmente

diseñada para la instalación y desinstalación de paquetes en aplicaciones web.

Trabaja sobre Npm56 y Node.js.

4.2.12 Npm

Npm funciona de forma parecida a como lo hace Bower, aunque en este caso se

centra en la gestión de paquetes sobre un sistema Node.js.

Hemos utilizado npm para la gestión de bibliotecas externas en nuestro sistema

de back-end. De esta forma el proceso de instalación o despliegue en otra máquina

resulta mucho más cómodo y sencillo.

55 PDF: Portable Document Format (formato de documento portable) es un formato de almacenamiento abierto para documentos digitales independiente de plataformas, creado por la empresa Adobe Systems. 56 NPM: es un manejador de paquetes para proyectos software.


Otra de las ventajas que aporta un sistema de gestión de paquetes como npm

consiste en la actualización de las bibliotecas externas. De esta forma podemos

decidir cuándo queremos que se instale la última verisón de cada una de ellas.

4.2.13 Base de datos

Hoy día existen en el mercado numerosas alternativas en cuanto al uso de bases

de datos. Si bien las bases de datos realacionales clásicas han perdido algo en cuanto

a capacidad de innovación, actualmente no faltan otros modelos que apuestan por

una revolución en este sector como son las bases de datos no relacionales57.

Dentro de este sector, contamos con alternativas como MongoDB58, MariaDB59

o Cassandra60. Todas ellas utilizan un enfoque distinto, unas basadas en documentos,

otras en grafos y otras en pares clave-valor.

Por otro lado, en el sector de las bases de datos más tradicionales también

contamos con un amplio abanico de posibilidades como son PostgreSQL61, MySQL62

o Microsoft SQL Server63.

En este proyecto, si bien las bases de datos no relacionales podrían suponer una

fuerte mejora de rendimiento y escalabilidad, apostaremos por una base de datos

clásica SQLite64, con capacidades limitadas pero suficientes para la elaboración de un

prototipo. De esta manera, podremos centrar nuestros esfuerzos en otros aspectos

57 Bases de datos no relacionales: bases de datos que no utilizan el modelo tradicional de estructura de tablas y relaciones, ni el lenguaje de consulta SQL. Estos modelos han demostrado ser más eficientes que las bases de datos tradicionales. 58 MongoDB: Sistema de Gestión de Bases de Datos no relacional orientado a documentos bajo el concepto de código abierto. 59 MariaDB: Sistema de Gestión de Bases de Datos no relacional derivado de MySQL, lo que le proporciona una gran capacidad de migración desde este sistema. 60 Cassandra: Sistema de Gestión de Bases de Datos no relacional y distribuido creado por la fundación Apache y escrito en Java. 61 PostgreSQL: Sistema de Gestión de Bases de Datos relacional, de código abierto, orientado a objetos y libre. 62 MySQL: Sistema de Gestión de Bases de Datos relacional, de código abierto, desarrollado por Oracle y probablemente el sistema más popular para este fin. 63 Microsoft SQL Server: Sistema de Gestión de Bases de Datos relacional desarrollado por la empresa Microsoft. Sólo está disponible para sistemas operativos Windows. 64 SQLite: Sistema de Gestión de Bases de Datos relacional compuesto de una pequeña biblioteca que lo convierte en un sistema muy ligero en comparación al resto.


que sí entran en el ámbito de este proyecto y dejar una posible actualización a otro

Sistema de Gestión de Bases de Datos para futuras mejoras.

4.3. Despliegue del proyecto

Con el fin de plasmar hacer disponible a pruebas el proyecto desarrollado, se ha

realizado un despliegue del mismo en los servidores de Heroku. Esta versión está

disponible para su libre uso y testeo.

Si bien aún tiene muchas posibles mejoras, así como funcionalidad que podría

ser añadida en un futuro, esta versión ya incluye la posibilidad de guardar cualquier

tipo de documento en la cuenta de usuario, así como realizar presentaciones sobre

ficheros de tipo pdf.

El despliegue del que hablamos en cuestión, se encuentra accesible a través de

la siguiente dirección:

http://slidecloud.herokuapp.com/

5. Conclusiones

En esta sección realizaremos un análisis de los resultados obtenidos mediante

el desarrollo de este proyecto y los compararemos con los objetivos propuestos

inicialmente. Más adelante, en el punto 5.1, analizaremos cuáles serían las siguientes

mejoras y trabajos futuros a realizar sobre el presente proyecto siguiendo la inercia

natural de desarrollo del mismo.

Como podemos comprobar en el apartado de implementación, se ha realizado

una clara explicación sobre Node.js y Angular.js así como sobre websockets y

Socket.io, se han identificado sus potenciales ventajas para el proyecto y se ha

justificado así su uso dentro del mismo.



El diseño e implementación tanto del sistema back-end como de la aplicación

cliente específicamente adaptada a móviles, han sido diseñadas e implementadas tal

y como se definió en los objetivos.

Además la misma aplicación web, permite a los posibles espectadores de una

presentación realizar su seguimiento de forma remota y en tiempo real.

En el punto 4.2 sobre detalles de implementación, se ha realizado un extenso

estudio sobre cada una de las tecnologías empleadas tanto en servidor como en la

aplicación cliente, y se ha justificado la adecuación de cada una de ellas en el marco

de este proyecto.

En dicho punto también se ha explicado en qué consiste la biblioteca sequelize.js

y por qué encaja dentro del ámbito del proyecto, así como una mención del panorama

actual de bases de datos y la elección que se ha tomado en este caso.

A su vez, también se han analizado diferentes biblitecas visuales para el

desarrollo de la aplicación web y se ha justificado la elección de Bootstrap.

También hemos hablado de REST y se ha aplicado en la implementación del API

de la capa del sistema de back-end.

En cuanto a la visualización de ficheros, hemos justificado la elección de los

ficheros de tipo pdf como principal enfoque de nuestro sistema y hemos hablado de la

biblioteca pdf.js para su renderizado.

Se ha llevado a cabo el proceso de despligue del sistema en la plataforma

Heroku y se ha presentado dicho sistema en este documento para su libre utilización

y testeo.

Teniendo todo esto en consideración, podemos concluir que se han alcanzado

los objetivos iniciales de este proyecto y su fruto queda plasmado en forma del sistema

de back-end y su api, la aplicación web que utiliza dicho sistema y que está

específicamente adaptada a pantallas pequeñas y su despliegue en Heroku.


5.1. Mejoras y trabajos futuros

El trabajo desarrollado durante este proyecto constituye una buena base de

producto sobre la que poder seguir trabajando. Cumple con las funciones básica que

debería cumplir un producto mínimo viable centrándose en ofrecer una funcionalidad

muy específica pero de forma correcta en lugar de pretender ser una herramienta para

todo pero que no consiga hacer nada bien.

Desde este punto podemos aportar numerosas mejoras y nuevas

funcionalidades, así como otros aspectos técnicos que no han sido cubiertos en este

proyecto por quedar fuera del ámbito del mismo pero que, sin duda, en un proyecto a

largo plazo deberían tenerse en cuenta.

A continuación enumero de forma breve algunas de las mejoras funcionales que

deberían añadirse a este proyecto de aquí en adelante:

Soporte para presentaciones en mayor tipo de ficheros. Si bien el soporte

a presentaciones en ficheros pdf resulta muy versátil pues casi cualquier

documento puede ser convertido a pdf, el soporte a otros tipos de ficheros

como diapositivas de PowerPoint, hojas de cálculo o imágenes aportaría

un valor añadido al cliente que podría olvidarse de tener que convertir

estos ficheros previamente.

Aplicaciones nativas para móviles. Si bien la aplicación web desarrollada

cumple con su función, gracias a disponer de un API REST que ofrece

nuestros servicios, resultaría bastante rápido poder desarrollar

aplicaciones nativas para cada plataforma con el consiguiente aumento

en la experiencia de usuario.

Aplicación de escritorio para sincronizar los ficheros de una carpeta. De

esta forma, el usuario no tendría que preocuparse de subir los ficheros a

nuestra plataforma, pues directamente los tendría sincronizados.

Soporte para poder realizar marcas, dibujos o resaltar texto sobre un

documento en una presentación. Esto serviría para que el presentador

pudiera hacer hincapié en secciones específicas del documento mientras

realiza su presentación.


Añadir la posibilidad de realizar notas sobre el documento. Esto podría

implementarse de varias formas, esto es, que el presentador pueda crear

anotaciones o bien, que el público de una presentación pueda hacer

comentarios sobre una sección específica, lo cual resultaría aún más

interesante.

Posibilidad de incluir streaming 65de audio y quizás vídeo. Esto convertiría

definitvamente a nuestro producto en una plataforma online con la que

poder impartir eventos, conferencias, cursos o clases de forma remota sin

tener que recurrir a servicios externos como Skype.

Por otro lado tenemos también una lista de mejoras técnicas que también

pasamos a detallar:

Cobertura de tests unitarios y de integración, así como cobertura de testeo

de escenarios principales para realizar un desarrollo mediante BDD66.

Cualquier desarrollo constante hoy día necesita un conjunto de tests que

sirvan como “esqueleto” sobre el que desarrollar. Sería imposible editar

código constantemente y tener que comprobar de forma continua que

todo el código existente hasta entonces sigue funcionando de forma

correcta. Una estructura de tests con automatización constante nos daría

siempre información sobre si con nuestros últimos cambios algo ha dejado

de funcionar correctamente.

Migración del Sistema de Gestión de Bases de Datos a un servicio de

terceros. Mediante esta acción conseguiríamos que nuestro sistema fuera

totalmente distribuido, garantizando así que, por ejemplo, otro sistema

futuro pudiera acceder a los mismos datos en dicho sistema con total

garantía. También facilitaría la posible expansión de recursos que nuestro

sistema de back-end podría llegar a necesitar conforme el volumen de

tráfico creciese.

65 Streaming (del inglés): dícese de la capacidad de un servicio en línea para emitir contenido bajo demanda, ya se trate de audio, vídeo o cualquier otro contenido multimedia. 66 BDD: Behaviour Driven Development. Dícese de un proceso de elaboración de software mediante el cual se definen en primer lugar, con lenguaje natural, los escenarios que debe satisfacer el producto en cuestión para, posteriormente, automatizar dichos escenarios sobre el producto en forma de tests e implementar la funcionalidad suficiente para que dichos tests sean satisfechos.


Mejora del sistema de renderizado de presentaciones para abarcar un

mayor rango de proporciones en los documentos. De esta forma

garantizaríamos que no aparecen en ningún caso barras de

desplazamiento horizontales ni verticales en la presentación.

Experimentar con bases de datos no relacionales para poder añadir una

mejora de rendimiento cuando nuestras necesidades en cuanto a

volumen de usuarios lo requieran.

6. Bibliografía

[1] E Tomàs (2014). Qué es REST. Desarrolloweb.com [Online]. Disponible:

http://www.desarrolloweb.com/articulos/que-es-rest-caracteristicas-sistemas.html [2] Proyectos Ágiles (2015). Qué es SCRUM. Proyectosagiles.org [Online]. Disponible:

https://proyectosagiles.org/que-es-scrum/. Acceso: Jul 23, 2016 [3] J. Hewitt (2008). MS PowerPoint: From Humble Beginnings to Business Meeting

Standard. Bright Hub. [Online]. Disponible: http://www.brighthub.com/office/collaboration/articles/13189.aspx. Acceso: May. 29, 2016.

[4] R Wauters (2014). Big numbers for Prezi. 50 million users, 160 million presentations created and $57m in fresh funding. Techeu. [Online]. Disponible: http://tech.eu/news/prezi-funding-50-million-users/. Acceso: May 29, 2016.

[5] Europapress (2015). Adobe anuncia el principio del fin de Flash y se centrará en HTML5. Europapress. [Online]. Disponible: http://www.europapress.es/portaltic/internet/noticia-adobe-anuncia-principio-fin-flash-centrara-html5-20151202175822.html. Acceso: Jul 23, 2016.

[6] M Hendrickson (2008). Dropbox: The Online Storage Solution We’ve Been Waiting For?. TechCrunch. [Online]. Disponible: http://techcrunch.com/2008/03/11/dropbox-the-online-storage-solution-weve-been-waiting-for/. Acceso: May 29, 2016.

[7] J McEleney (2015). How Google solved the versión control problem. OnShape. [Online]. Disponible: https://www.onshape.com/cad-blog/how-google-solved-the-version-control-problem. Acceso: May 29, 2016.

[8] Ministerio de Empleo y Seguridad Social. Boletín Oficial del Estado. [Online]. Disponible: https://www.boe.es/boe/dias/2016/01/21/pdfs/BOE-A-2016-541.pdf. Acceso Jun 4, 2016.

[9] Heroku (2016). Heroku Pricing. Heroku. [Online]. Disponible https://www.heroku.com/pricing. Acceso: Jun 6, 2016.

[10] Zenith (2015). ¿Qué es y cómo funciona el modelo freemium? BlogginZenith. [Online]. Disponible: http://blogginzenith.zenithmedia.es/que-es-y-como-funciona-el-modelo-freemium-diczionario/.Acceso: Jul 23, 2016.

[11] Technopat (2012). Escalabilidad. Wikipedia. [Online]. Disponible: https://es.wikipedia.org/wiki/Escalabilidad#Referencias. Acceso: Jul 23, 2016.

[12] W3C (?). Guía breve de Servicios Web. W3C. [Online]. Disponible: http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb. Acceso: Jul 23, 2016.

[13] I. Roth (2014). What makes Node.js Faster Than Java?. StrongLoop. [Online]. Disponible: https://strongloop.com/strongblog/node-js-is-faster-than-java/. Acceso: Jul 23, 2016.

http://www.desarrolloweb.com/articulos/que-es-rest-caracteristicas-sistemas.html

https://proyectosagiles.org/que-es-scrum/

http://www.brighthub.com/office/collaboration/articles/13189.aspx

http://tech.eu/news/prezi-funding-50-million-users/

http://www.europapress.es/portaltic/internet/noticia-adobe-anuncia-principio-fin-flash-centrara-html5-20151202175822.html

http://www.europapress.es/portaltic/internet/noticia-adobe-anuncia-principio-fin-flash-centrara-html5-20151202175822.html

http://techcrunch.com/2008/03/11/dropbox-the-online-storage-solution-weve-been-waiting-for/

http://techcrunch.com/2008/03/11/dropbox-the-online-storage-solution-weve-been-waiting-for/

https://www.onshape.com/cad-blog/how-google-solved-the-version-control-problem

https://www.onshape.com/cad-blog/how-google-solved-the-version-control-problem

https://www.boe.es/boe/dias/2016/01/21/pdfs/BOE-A-2016-541.pdf

https://www.heroku.com/pricing

http://blogginzenith.zenithmedia.es/que-es-y-como-funciona-el-modelo-freemium-diczionario/

http://blogginzenith.zenithmedia.es/que-es-y-como-funciona-el-modelo-freemium-diczionario/

https://es.wikipedia.org/wiki/Escalabilidad%23Referencias

http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb

https://strongloop.com/strongblog/node-js-is-faster-than-java/


[14] J. Peláez (2015). Arquitectura basada en Componentes. Geeks.ms [Online]. Disponible: http://geeks.ms/jkpelaez/2009/04/18/arquitectura-basada-en-componentes/. Acceso: Jul 23, 2016.

Apéndice I. Manual de instalación del sistema

Como ya comentamos en el punto 4.3, una versión desplegada de este sistema

está disponible de forma online para su libre uso:


En cualquier lugar, a continuación detallamos los pasos necesarios para

cualquier usuario que así lo requiera pueda realizar la instalación pertinente de este

software de forma local.

Instalación del sistema de back-end y base de datos:

En primer lugar, será necesario tener instalado Node.js. Para ello, podemos

descargar sus instalables para Windows, Linux o Mac OS X desde aquí:

https://nodejs.org/en/download/

En sistemas Windows, se lanzará una ventana y de Windows Firewall, en el que

deberemos desbloquear Node.js como vemos en la siguiente ilustración.

http://geeks.ms/jkpelaez/2009/04/18/arquitectura-basada-en-componentes/

http://geeks.ms/jkpelaez/2009/04/18/arquitectura-basada-en-componentes/


https://nodejs.org/en/download/


Ilustración 7.1 – Firewall para Node.js

Junto con esta instalación, también queda instalado npm, el gestor de paquetes

de Node.js. Puesto que todas las dependencias del proyecto están gestionadas con

dicho gestor de paquetes, esto facilitará mucho la instalación. Tan sólo será necesario

copiar el código del proyecto, bien desde el código presentado junto con esta

documentación, o bien desde el siguiente repositorio de GitHub:

https://github.com/gabrifdez89/slidecloud

Una vez copiado el código, deberemos abrir una ventana de comandos en el

directorio raíz del proyecto y ejecutar la siguiente instrucción para realizar toda la

instalación de las dependencias:

sudo npm install

A continuación, una vez instaladas todas las dependencias, será necesario

lanzar el servidor de Node.js que ejecutará la aplicación. Para ello tecleamos:

npm start

https://github.com/gabrifdez89/slidecloud


Con esto ya tendremos la parte de back-end corriendo y la base de datos

enlazada a él. Ahora tan sólo nos falta instalar la aplicación web.

Instalación del sistema de front-end:

En este caso, ya tendremos instalados Node.js y npm, por lo que procederemos

directamente a copiar el código desde aportado junto a este proyecto o desde el

siguiente enlace:

https://github.com/gabrifdez89/slidecloud-webclient

Abrimos una ventana de comandos distinta a la anterior en la ruta raíz de este

proyecto y ejecutamos nuevamente:

npm install

Y a continuación:

npm start

Ahora, ya tenemos todo nuestro sistema funcionando debidamente. Para

acceder a la aplicación, bastará con acceder a la siguiente ruta a través de nuestro

navegador web:

http://localhost:3030/

Apéndice II. Manual de usuario

Una vez instalado el software o accedido a la versión de prueba disponible en la

url que aparece a continuación, el usuario deberá crearse una cuenta para poder

utilizar el sistema.


https://github.com/gabrifdez89/slidecloud-webclient

http://localhost:3030/



Si ha instalado la versión de forma local y desea saltarse este paso, puede utilizar

el usuario de pruebas que ya existe en la base de datos, cuyas credenciales son:

Usuario: pepe

Contraseña: pepe

Este usuario viene prestablecido en la versión que aún no es de producción para

poder realizar pruebas sin necesidad de crear una nueva cuenta.

En caso de necesitar crear una nueva cuenta desde cero, bastará con

seleccionar la opción “Create account” que aparece en la pantalla de login, tal y como

vemos en la siguiente ilustración.

Ilustración 7.2 – Crear cuenta de usuario

A continuación, veremos como el formulario cambia para permitirnos registrar

una nueva cuenta. Deberemos especificar un nombre de usuario que se encuentre


disponible, una contraseña y una dirección de correo electrónico válida. Podemos ver

un ejemplo en la ilustración 7.3. A continuación, pulsaremos sobre “Log in”.

Ilustración 7.3 – Creando cuenta de usuario

Si el proceso ha transcurrido de forma correcta, el sistema nos mostrará una

notificación indicando que nuestra cuenta ha sido creada y que debemos proceder a

activarla mediante el enlace enviado a la cuenta de correo proporcionada.


Ilustración 7.4 – Cuenta creada satisfactoriamente

Procedemos a comprobar nuestro correo electrónico y vemos el correo que ha

sido enviado. Si no lo encontramos, deberíamos registrar la sección de correo no

deseado, puesto que es posible que nuestro proveedor de correo lo haya archivado

en dicha sección. Una vez localidado el correo, presionamos sobre el enlace que éste

incluye o copiamos y pegamos dicho enlace en la barra de direcciones de nuestro

navegador web.


Ilustración 7.5 – Validación de cuenta

Al acceder al enlace el sistema debería avisarnos de que nuestra cuenta ha sido

validada y podremos comenzar a utilizar el servicio.

Ilustración 7.6 – Cuenta validada

Introducimos nuestras credenciales para entrar al sistema y presionamos sobre

el botón de “Log in”. Si no hemos cometido ningún error, veremos la pantalla principal

de SlideCloud con nuestros ficheros en el sistema. Como aún no hemos subido ningún

fichero, nuestra lista de ficheros estará vacía.

Para comenzar a interactuar con el sistema deberíamos presionar sobre el botón

“Choose files” que aparece en el margen derecho para seleccionar uno o varios

ficheros que subir al sistema.


Ilustración 7.7 – Pantalla principal sin ficheros

A continuación se abrirá una ventana del sistema de ficheros de nuestro sistema

oeprativo mediante la cual podremos seleccionar los ficheros a subir. Recomendamos

subir al menos un fichero de tipo pdf para poder realizar presentacions sobre él. En

este caso hemos seleccionado dos ficheros, uno de ellos de tipo pdf.

Ilustración 7.8 – Selección de ficheros

Comprobamos que el componente de subida de ficheros se actualiza con los

elementos seleccionados y hacemos click sobre el botón “Upload”


Ilustración 7.9 – Subida de ficheros

Comprobaremos que la lista de ficheros se actualiza automáticamente.

Ilustración 7.10 – Lista de ficheros actualizada

Una vez que ya hemos añadido ficheros al sistema, podemos interactuar con

ellos. En esta ocasión vamos a presionar el icono del aspa sobre la línea del fichero

con extensión “.docx” para eliminarlo del sistema puesto que no vamos a utilizarlo.


Ilustración 7.11 – Borrado de ficheros

Nos aparecerá una ventana de confirmación. Presionamos en el botón de

“Delete” para confirmar la acción y comprobamos que éste desaparecerá de la lista

de ficheros.

Ilustración 7.12 – Confirmar borrado

Para descargar el otro fichero que aún tenemos en el sistema, pulsaremos sobre

el icono de flecha hacia abajo dentro de un círculo que aparece en la línea del fichero.

Comprobaremos como nuestro navegador web inicia la descarga del fichero.


Ilustración 7.13 – Descarga de fichero

Ilustración 7.14 – Fichero descargado

Por último, procedemos a iniciar la presentación del documento pdf. Para ello,

presionamos sobre el icono de la pizarra sobre la línea del fichero.


Ilustración 7.15 – Iniciar presentación

Se visualizará el documento en cuestión. Para compartir nuestra presentación

con otros espectadores o realizar una prueba individual, pulsaremos sobre el icono de

los eslabones para visualizar el enlace a la presentación.

Ilustración 7.15 – Compartir presentación

Aparecerá una ventana con el enlace a la presentación que podemos copiar y

compartir con los espectadores. Para realizar una prueba, podemos abrir nosotros

mismos dicho enlace en otra ventana del navegador o en un dispositivo diferente.


Ilustración 7.16 – Enlace a presentación

Al acceder a dicho enlace en otro dispositivo o ventana de navegador,

comprobamos que se visualiza el mismo fichero, esta vez sin los controles de

navegación, pues estamos accediendo al mismo como espectadores de la

presentación.

Ilustración 7.17 – Visualización de presentación a través del enlace


Podemos comprobar que al desplazarnos por el documento en la primera

ventana del navegador mediante los botones de flechas horizontales, dichos

desplazamientos se renderizan en tiempo real también en la otra ventana o en el otro

dispositivo desde el que hayamos accedido a la presentación.

Ilustración 7.18 – Navegación a través de la presentación

Una vez nuestra presentación finalice, podemos cerrar el documento mediante

el botón con el aspa y cerrar nuestra cuenta en el sitema mediante el botón de “Log

out” de la barra superior.


Ilustración 7.19 – Cerrar sesión

El sistema volverá automáticamente a la pantalla de login y nuestra sesión habrá

sido cerrada.

Apéndice III. Descripción de contenidos suministrados

En el dispositivo de almacenamiento entregado se incluyen, además de este

documento a modo de memoria explicativa del desarrollo, lo siguientes elementos:

Carpeta source. Aquí podemos encontrar todo el código fuente del

proyecto. En su interior encontraremos dos carpetas, la primera

denominada “slidecloud” que contiene el proyecto de back-end y base de

datos, y la segunda denominada “slidecloud-webclient” que contiene el

proyecto de front-end. Podremos realizar su instalación tal y como se

indica en el apéndice I.

Carpeta repositorios. En esta carpeta encontraremos un par de enlaces a

los repositorios en GitHub que incluyen el código fuente del proyecto.


Carpeta despliegue. Aquí encontraremos otro enlace al despliegue del

proyecto en Heroku. Esta versión puede utilizarse para realizar pruebas

sobre el proyecto desarrollado sin necesidad de realizar una instalación.

Carpeta ilustraciones. Incluye todas las ilustraciones que han sido

utilizadas en la elaboración de esta memoria.

Carpeta aplicación android. Incluye el apk para la instalación de la

aplicación cliente en android.

Apéndice IV. Acceso a instalación de pruebas

Como ya hemos mencionado previamente durante esta memoria, una versión de

pruebas del proyecto desarrollado se encuentra disponible a través del siguiente

enlace:


Si desea probar la funcionalidad de este proyecto sin tener que realizar una

instalación específica del mismo, puede servirse de este despligue con dicho fin.

Le recomendamos encarecidamente que consulte el apéndice II “manual de

usuario” a modo de guía e introducción a la funcionalidad básica que incluye el

proyecto.


E Trabajo Fin de Grado STUDIO Y DESARROLLO DE UN …tauja.ujaen.es/bitstream/10953.1/6143/1/TFG...

Documents

Transcript of E Trabajo Fin de Grado STUDIO Y DESARROLLO DE UN …tauja.ujaen.es/bitstream/10953.1/6143/1/TFG...