desarrollo de herramienta colaborativa en tiempo real · curso académico 2014 / 2015. ... •...

Eduardo Benito Díez

Julio Rubio García

Facultad de Ciencias, Estudios Agroalimentarios e Informática

Grado en Ingeniería Informática

2014-2015

Título

Director/es

Facultad

Titulación

Departamento

TRABAJO FIN DE GRADO

Curso Académico

Desarrollo de herramienta colaborativa en tiempo real

Autor/es

© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2015

publicaciones.unirioja.esE-mail: [email protected]

Desarrollo de herramienta colaborativa en tiempo real, trabajo fin de gradode Eduardo Benito Díez, dirigido por Julio Rubio García (publicado por la Universidad de

La Rioja), se difunde bajo una LicenciaCreative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported.

Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a lostitulares del copyright.

Facultad

Facultad de Ciencias, Estudios Agroalimentarios e Informática Titulación

Grado en Ingeniería en Informática Título

Desarrollo de herramienta colaborativa en tiempo real Autor/es

Eduardo Benito Díez Tutor/es

Julio Jesús Rubio García Departamento

Departamento de Matemáticas y Computación Curso académico

2014 / 2015

Resumen

Este trabajo fin de grado consistira en el analisis y la implementacion deuna herramienta colaborativa que permita a los miembros de un equipode trabajo coordinarse durante la realizacion de pequenos proyectos.

Ademas de explicar las tecnologıas utilizadas y especificar las fases dedesarrollo del proyecto como el analisis, diseno, implementacion y prue-bas, se estudiaran las buenas practicas del desarrollo de software y seintentara hacer una lista de recomendaciones a la hora de desarrollareste tipo de proyectos, como la reutilizacion de codigo o el uso de li-brerıas de terceros para tareas especıficas como la autenticacion.

Tambien se explicara como instalar e integrar estas librerıas median-te el uso de gestores de paquetes y herramientas de construccion deproyectos.

Abstract

This work will consist in the analysis and implementation of a real timecollaborative tool that allows members of a work team be coordinatedduring a small project realization.

Besides describing used technologies and the different developmentstages such as analysis, design, implementation or testing, the aim ofthis project is to intend to study the best practices for software devel-opment and deployment as code reuse or using third party libraries forspecific purposes like authentication.

Also we try to explain how to manage the installation and integrationof these libraries using package managers and building tools.

Indice

1 Documento de objetivos 11.1 Aproximaciones iniciales . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Descripcion . . . . . . . . . . . . . . . . . . . . . . . . 11.1.2 Antecedentes y justificacion del proyecto . . . . . . . . 1

1.2 Alcance del proyecto . . . . . . . . . . . . . . . . . . . . . . . 21.2.1 Informe del alcance . . . . . . . . . . . . . . . . . . . . 21.2.2 Entregables principales del proyecto . . . . . . . . . . . 31.2.3 Documentacion necesaria . . . . . . . . . . . . . . . . . 3

1.3 Recursos humanos y personal . . . . . . . . . . . . . . . . . . 31.4 Plan de comunicaciones . . . . . . . . . . . . . . . . . . . . . . 41.5 Arquitectura y tecnologıa . . . . . . . . . . . . . . . . . . . . 4

1.5.1 Tecnologıas disponibles . . . . . . . . . . . . . . . . . . 41.5.2 Tecnologıas utilizadas . . . . . . . . . . . . . . . . . . . 41.5.3 Herramientas utilizadas . . . . . . . . . . . . . . . . . . 61.5.4 Herramientas de testing . . . . . . . . . . . . . . . . . 7

1.6 Metodologıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.7 Calendario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Analisis 92.1 Identificacion del entorno tecnologico . . . . . . . . . . . . . . 92.2 Estudio de alternativas . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1 Sistema de base de datos . . . . . . . . . . . . . . . . . 92.2.2 Sistemas NoSQL . . . . . . . . . . . . . . . . . . . . . 102.2.3 Almacenamiento de MongoDB . . . . . . . . . . . . . . 112.2.4 Backend . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.5 Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.6 Tiempo real . . . . . . . . . . . . . . . . . . . . . . . . 122.2.7 Alojamiento . . . . . . . . . . . . . . . . . . . . . . . . 132.2.8 Herramienta de construccion . . . . . . . . . . . . . . . 142.2.9 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Identificacion de usuarios participantes y finales . . . . . . . . 152.3.1 Usuarios participantes . . . . . . . . . . . . . . . . . . 152.3.2 Usuarios finales . . . . . . . . . . . . . . . . . . . . . . 15

2.4 Establecimiento de requisitos . . . . . . . . . . . . . . . . . . . 152.4.1 Actores . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.4.2 Casos de uso . . . . . . . . . . . . . . . . . . . . . . . 162.4.3 Base de datos . . . . . . . . . . . . . . . . . . . . . . . 17

3 Diseno 203.1 Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . 203.2 Diseno de casos de usos . . . . . . . . . . . . . . . . . . . . . . 213.3 Diseno de la base de datos . . . . . . . . . . . . . . . . . . . . 243.4 Diseno de la interfaz . . . . . . . . . . . . . . . . . . . . . . . 253.5 Definicion de los tests . . . . . . . . . . . . . . . . . . . . . . . 28

4 Construccion 324.1 Implementacion . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1.1 Lenguajes usados . . . . . . . . . . . . . . . . . . . . . 324.1.2 Tecnologıas empleadas . . . . . . . . . . . . . . . . . . 324.1.3 Autenticacion . . . . . . . . . . . . . . . . . . . . . . . 344.1.4 Funcionamiento del tiempo real . . . . . . . . . . . . . 34

4.2 Puesta en produccion . . . . . . . . . . . . . . . . . . . . . . . 35

5 Gestion del proyecto 37

6 Conclusiones 396.1 Mejoras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

1 DOCUMENTO DE OBJETIVOS 1

1 Documento de objetivos

1.1 Aproximaciones iniciales

1.1.1 Descripcion

El objetivo principal de este proyecto es construir una herramienta de cola-boracion que permita a los miembros de un equipo de trabajo coordinarsedurante la realizacion pequenos proyectos. Para ello se podran crear diferentesespacios en los que colgar nuestras notas o tareas, a los que llamaremos ta-bleros. Estos tableros podran ser publicos o privados y sus creadores tendranla posibilidad de invitar al resto de participantes del proyecto a que utiliceel tablon.La aplicacion dara la posibilidad de registrarse con una direccion de correomas una contrasena o bien utilizando los servicios de identificacion de redessociales como Google+, Facebook, Twitter o LinkedIn.

1.1.2 Antecedentes y justificacion del proyecto

Aunque ya existen herramientas para la gestion de proyectos, estas suelenser bastante completas y esto anade una complejidad adicional a la hora demanejarlas. Con este proyecto se busca construir una herramienta sencilla deusar y que pueda ser integrada en un sitio web existente. Tambien se esperaque sea facil de desarrollar y mantener, evitando tener que instalar softwareadicional y que pueda alojarse en cualquier servidor o incluso en la nubesin necesidad de complicadas configuraciones. Otra de las razones personalespara justificar este proyecto es la opcion de aprender nuevas tecnologıas comoAngularJS o MongoDB.


1.2 Alcance del proyecto

1.2.1 Informe del alcance

1.2.1.1 Estado del Arte

• Estudio de aplicaciones similares.

• Estudio de frameworks para el desarrollo con JavaScript y nodeJS,herramientas de scaffolding como Yeoman que ayudan a crear la es-tructura inicial y a organizar el codigo de la aplicacion en directorios,build systems como Grunt o Gulp y gestores de paquetes como NPM oBower que facilitan la instalacion de las librerıas externas que utilizaranuestro proyecto.

• Estudio de herramientas de testing como Karma, Protractor o Jasmine,para decidor cual de ellas se adapta mejor a nuestro proyecto.

1.2.1.2 Descripcion de la aplicacion

• Gestion de usuarios.

El registro en la aplicacion lo podra realizar cada usuario introduciendosu cuenta de correo electronico y asignado una contrasena de acceso,tambien contaran con la posibilidad de registrarse usando sus cuentasde las redes sociales Facebook, Twitter, LinkedIn o Github, y usandoel servicio de openId.

El administrador podra bloquear el acceso a la aplicacion desde unacuenta concreta pero nunca modificar sus datos de acceso.

• Gestion de tableros.

Cualquier usuario puede crear un nuevo tablero, al que se le dara unnombre y una descripcion si se desea. El usuario decidira si se trata deun tablero de acceso publico o privado, seleccionando en este ultimocaso una lista de los usuarios que podran ver o modificar dicho tablero.

• Gestion de notas.

Dentro de cada tablero se crearan notas. Una nota puede consistir enun simple texto o tambien puede ser una tarea que podra ser asignadaa un usuario y estar marcada como realizada o no. El usuario podraasignar colores a estas notas y modificar su posicion dentro del tablero.


1.2.2 Entregables principales del proyecto

• DOP (Documento de Objetivos del Proyecto)

• Memoria: sera entregada al tribunal para su posterior valoracion.

• Aplicacion web: se proporcionara la URL donde se alojara la aplicaciony su codigo fuente.

• Plan de pruebas.

1.2.3 Documentacion necesaria

Sera conveniente recopilar informacion sobre:

• NodeJS

• JavaScript

• AngularJS

• JSON

• MongoDB

• Express

• Moongose

1.3 Recursos humanos y personal

• Eduardo Benito: realizador del proyecto.

Decisiones a tomar: todas las decisiones, algunas de ellas discutidaspreviamente con el director del proyecto.

Dedicacion: completa.

• Julio Rubio: director del proyecto.

Decisiones a tomar: todas las relacionadas con la metodologıa a seguir,los documentos a redactar y la forma de presentarlos.

Revisara periodicamente las entregas y se preocupara de que se cumplanlos plazos previstos.

Dedicacion: esporadica.


1.4 Plan de comunicaciones

Correo electronico

Actualmente el alumno se encuentra viviendo y trabajando en Madrid porlo que esta sera la manera mas habitual de comunicarse.

Reuniones

Aunque no se realicen con frecuencia, se preve que a lo largo del proyecto selleven a cabo algunas reuniones presenciales, sobre todo al final del proyectode cara a preparar la memoria y la presentacion.

1.5 Arquitectura y tecnologıa

1.5.1 Tecnologıas disponibles

• Debian

• Apache

• MongoBD

1.5.2 Tecnologıas utilizadas

Node.js

Entorno de programacion en JavaScript para la parte backend basado en elmotor de JavaScript V8, el mismo que usa Google Chrome, aunque esto noquiere decir que el uso de Node sea incompatible en otros navegadores. Esorientado a eventos, no bloqueante, por lo que es idoneo para aplicaciones entiempo real.

MongoDB

Es una base de datos no relacional (NoSQL) de codigo abierto, escrito enC++, que guarda los datos en documentos tipo JSON (JavaScript ObjectNotation) pero en forma binaria (BSON). Ademas se integra muy bien conNode.js mediante drivers propios o bien con el uso de Moongose. Debido asu flexibilidad es muy escalable.


Moongose

Un ODM (Object-document mapping) para Mongo y Node.js. Nos permiteinteractuar con la base de datos mediante objetos de JavaScript, y facilitalas operaciones CRUD (Create, Read, Update, Delete) y las validaciones.

Express

Es un framework de Node.js con el que poder levantar un servidor web yrecibir peticiones HTTP de una manera sencilla. Su objetivo principal espoder crear una API REST (Representational State Transfer) rapidamente.

AngularJS

Un framework JavaScript, que sigue el patron MVC (Model View Controller)y permite crear aplicaciones web de una sola pagina, mas conocidas comoSPAs por sus siglas en ingles (Single-Page Applications), son aplicaciones enlas que la pagina se carga completamente despues de la primera peticion y seva reemplazando pequenas partes del contenido mediante peticiones AJAX(Asynchronous JavaScript And XML). Una de sus principales ventajas es quese trata de un proyecto desarrollado y mantenido por Google.

HTML5

HTML5 es la quinta version del popular HyperText Markup Language. Unlenguaje de marcado para crear paginas web. Esta ultima version incorporamas semantica con etiquetas como header, article, section, nav o footer quedefinen con mayor precision cada una de las partes de la pagina y permiteuna mejor integracion de elementos multimedia.

CSS3

Hojas de Estilo en Cascada (Cascading Style Sheets) es un lenguaje paradefinir el estilo o la apariencia de las paginas web, escritas con HTML. Sirvepara separar el contenido de la forma, a la vez que permite a los disenadoresmantener un control preciso sobre la apariencia de las paginas. La novedadmas importante que aporta CSS3 consiste en la incorporacion de nuevosmecanismos para mantener un mayor control sobre el estilo con el que se


muestran los elementos de las paginas, sin tener que recurrir a trucos o hacks,que a menudo complicaban el codigo de las web.

Bootstrap 3

Es un framework desarrollado por Twitter de HTML, CSS y JavaScript paracrear sitios web con un diseno compatible con dispositivos moviles.

DOM

Document Object Model (DOM) es una API para acceder, anadir y cam-biar dinamicamente el contenido, la estructura y el estilo de los documentosHTML mediante lenguajes del lado del cliente.

JSON

JavaScript Object Notation (JSON) es un formato para el intercambio dedatos que se integra muy facilmente con aplicaciones JavaScript. La principalventaja de JSON sobre XML es que es mas compacto, es decir la mismainformacion codificada en JSON ocupa menos espacio que en formato XML.

1.5.3 Herramientas utilizadas

GIT

Se trata de un sistema de control de versiones distribuido disenado paramanejar todo tipo de proyectos con eficiencia.

Bower

Es un gestor de paquetes para el frontend. Se encarga de instalar las librerıasy paquetes que necesita una aplicacion. Es una forma comoda de tener laslibrerıa actualizadas y gestionar las dependencias que puede haber entre ellas.

NPM

Es el gestor de paquetes por defecto para Node.js.


GRUNT

Es una librerıa JavaScript que nos permite automatizar tareas y ası ahorrartiempo en el desarrollo y despliegue de aplicaciones webs. Permite configurartareas de todo tipo como ejecutar tests, unificar las hojas de estilos o subira produccion.

1.5.4 Herramientas de testing

Jasmine

Es un framework BDD (Behavior-Driven Development) para realizar pruebasde codigo JavaScript.

Karma

Test runner para JavaScript especialmente compatible con proyectos que uti-lizar AngularJS. El objetivo de esta herramienta es proporcionar un entornode desarrollo en el que sea facil probar la aplicacion sin necesidad de invertirtiempo en configuraciones.

1.6 Metodologıa

Se han estudiado varias metodologıas para aplicar en este proyecto comoMetrica, SCRUM o XP (Extreme Programming).

Aunque no se seguira una metodologıa estricta, sı se adoptara un ciclode vida similar al de Metrica que consta de las fases: analisis, diseno, imple-mentacion y pruebas.

1.7 Calendario

La realizacion del proyecto se llevara a cabo entre septiembre de 2014 y sepreve terminar en enero de 2015 (4 meses).

1. Gestion del proyecto (36 horas)

1.1. Creacion del plan del proyecto (2 horas)

1.2. Gestion del plan (6 horas)

1.3. Creacion de la memoria (20 horas)


1.4. Documentacion (4 horas)

1.5. Defensa del proyecto (4 horas)

2. Requisitos (10 horas)

2.1. Identificacion de los casos de uso (2 horas)

2.2. Realizacion del modelo de casos de uso (8 horas)

3. Analisis del sistema (24 horas)

3.1. Definicion del sistema (4 horas)

3.2. Analisis de requisitos (12 horas)

3.3. Analisis de casos de uso (6 horas)

3.4. Analisis de clases (2 horas)

4. Diseno del sistema (22 horas)

4.1. Diseno de la arquitectura del sistema (2 horas)

4.2. Diseno de casos de uso (4 horas)

4.3. Diseno de clases (4 horas)

4.4. Diseno de la base de datos (2 horas)

4.5. Diseno de interfaces de usuario (10 horas)

5. Implementacion (60 horas)

5.1. Creacion de la base de datos (4 horas)

5.2. Codificacion (36 horas)

5.3. Diseno del sitio web (20 horas)

6. Pruebas (10 horas)

7. Implantacion del sistema (4 horas)

2 ANALISIS 9

2 Analisis

2.1 Identificacion del entorno tecnologico

Fase de desarrollo

• HardwareUn ordenador portatil es el unico elemento que se necesitarıa en estafase, con el se desarrollara la aplicacion y tambien hara las funcionesde servidor local.

• SoftwareSistema operativo: Linux Debian Wheezy.Navegadores web: Se utilizara Chrome 38 y se probara habitualmenteen Firefox 32.

Fase de produccion:

• ServidorEl proyecto se alojara en Heroku. Un servicio de alojamiento en la nubeque a su vez hace uso de los servidores de Amazon Web Services.

• ClienteCualquier equipo con conexion a internet y un navegador con JavaS-cript habilitado, se utilizaran estandares de desarrollo para que no hayaproblemas de visualizacion en los navegadores mas utilizados.

2.2 Estudio de alternativas

2.2.1 Sistema de base de datos

Alternativa elegida

Los puntos fuertes de los sistemas NoSQL son la escalabilidad, el rendimientoy laflexibilidad de la estructura de datos.

Aunque en este caso dado que el sistema no es demasiado complejo yno va a necesitar soportar una alta carga de trafico, la eleccion respondemas a la facilidad de integracion con NodeJS, ya que en un sistema NoSQLse pueden guardar objetos en formato JSON que manipularemos facilmente

2 ANALISIS 10

desde la aplicacion. Por tanto una de las razones de peso es el tiempo queahorraremos transformando datos y evitando problemas de formatos.

Otra de las razones es el deseo del desarrollador de aprender este tipo detecnologıas, probandolas en un sistema de tamano medio.

Alternativas estudiadas

MySQL o PostgreSQL

Una de sus ventajas es que tanto los sistemas como el lenguaje SQL sonconocidos. Y la naturaleza del proyecto es bastante adecuada para este tipode sistemas.

2.2.2 Sistemas NoSQL

Alternativa elegida

De todos los sistemas para bases de datos NoSQL, se ha optado por Mon-goDB, porque ademas de ofrecer las caracterısticas basicas de los sistemasNoSQL como el almacenamiento orientado a documentos, indexacion, repli-cacion, sistema flexible de consultas... es uno de los mas conocidos y tiene unamuy buena documentacion, dispone decursos de formacion y ofrece soportepor parte de sus creadores. Ademas ninguna de las alternativas disponen deun servicio como Mongolab que se explica en el siguiente apartado.


CouchDB

CouchDB es una base de datos pensada especıficamente para aplicacionesweb, almacena los datos en formato JSON y puede acceder a los datos di-rectamente por HTTP a traves de una API. Utiliza JavaScript para indexar,combinar o transformar los documentos. Funciona eficientemente en aplica-ciones moviles. Esta bastante centrado en la disponibilidad y permite tenerlos datos distribuidos.

2 ANALISIS 11

Cassandra

Apache Cassandra es una de las mejores opciones cuando la escalabilidad,la alta disponibilidad y la integridad de los datos son las prioridades de unproyecto.

Riak

Riak es una base de datos distribuida de codigo abierto. Esta disenada es-pecialmente para dar una respuesta muy rapida a cada peticion de datos.Asegura una alta disponibilidad y tolerancia a fallos gracias a un sistema dereplicacion interna. Por otra parte aseguran que es muy escalable gracias a lafacilidad para anadir nuevos servidores al sistema y a las tecnicas que empleapara distribuir los datos entre ellos.

2.2.3 Almacenamiento de MongoDB

Alternativa elegida

Para nuestro proyecto utilizaremosMongolab, un servicio de alojamiento debases de datos MongoDB en la nube. Este sistema ofrece varias ventajas; unade ellas es que de esta manera no debemos preocuparnos de la instalacion nidel mantenimiento de MongoDB en nuestro servidor. La otra es la facilidadcon la que podrıamos conseguir una mayor capacidad de almacenamiento yprocesamiento, simplemente anadiendo o mejorando los servidores del clusterque ofrecen gratuitamente, aunque no se preve que lo vayamos a necesitar.


Instalacion en local

Con esta opcion conseguirıamos un control mayor sobre nuestro sistema,teniendo mas libertad a la hora de la eleccion de versiones o plugins. Y laseguridad de que nuestros datos no son accesibles por terceros.

2.2.4 Backend

Alternativas elegida

NodeJS se ha considerado como la tecnologıa mas adecuada para realizar elproyecto, gracias a la excelente integracion que tiene con MongoDB y sobre

2 ANALISIS 12

todo con el resto de librerıas que utilizaremos para el frontend.


PHP

Un lenguaje ampliamente conocido, con una extensa documentacion y mul-titud de ejemplos. No se integra tan bien como NodeJS con MongoDB y laslibrerıas de tiempo real.

2.2.5 Frontend

Alternativa elegida

AngularJS es en estos momentos el framework MVC JavaScript mas po-pular y con mayor numero de contribuidores. el proposito de este tipo deframeworks es ahorrar muchas lıneas de codigo y facilitar la manipulacionde objetos DOM que de otra manera tendrıa que hacerse directamente conJavaScript o algun otro framework de mas bajo nivel como jQuery.


EmberJS

Sus puntos fuertes son la facilidad de configuracion y su gran rendimiento(por encima de AngularJS), como desventajas se pueden nombrar la falta deplugins y documentacion.

BackboneJS

Otro de los frameworks mas conocidos y utilizados. Es ligero, rapido, consumepoca memoria y es facil de usar. Su principal desventaja es que se necesitanotras librerıas como jQuery o UnderscoreJS para realizar algunas tareas.

2.2.6 Tiempo real

Alternativa elegida

Socket.io es una librerıa JavaScript que permite mantener una comunicacionbidireccional entre el servidor y el cliente basada en eventos. Funciona paratodas las plataformas, navegadores y dispositivos, proporcionando fiabilidad

2 ANALISIS 13

y rapidez. Esta especialmente disenada para aplicaciones de estadısticas entiempo real, mensajerıa instantanea y en la edicion distribuida de documen-tos.


AJAX

Se podrıa realizar una aplicacion sin la utilizacion de ninguna librerıa especıfi-ca de tiempo real que utilizase peticiones al servidor mediante JavaScript. Elproblema es que usando peticiones AJAX serıa necesario un contador paraque cada pocos segundos comprobase si se ha realizado alguna modificacionen el tablero o se ha recibido algun mensaje y en caso de tener cambiosprocesar la respuesta de manera manual, lo que incrementarıa bastante lacomplejidad y la cantidad de codigo utilizado.

Comet

Un conjunto de tecnologıas similar a las que se usan en AJAX, la principaldiferencia es que en este caso la conexion entre cliente y servidor se mantieneabierta y el servidor envia informacion al cliente cada cierto tiempo (lo que seconoce como tecnologıa PUSH), con esta solucion tambien nos encontramoscon el problema de procesar las peticiones e incrementar el codigo necesario.

Meteor.js

Es un moderno framework JavaScript para desarrollar aplicaciones web, cen-trado en aplicaciones en tiempo real, con el que por ejemplo se pueden realizaraplicaciones de chat con unas pocas lıneas. Se ha descartado para el proyectopor tratarse de un framework completo con el que podrıan producirse incom-patibilidades con el resto de tecnologıas utilizadas y ademas serıa necesariauna considerable labor de formacion.

2.2.7 Alojamiento

Alternativa elegida

Heroku es un servicio de almacenamiento en la nube que ademas tiene me-canismos y herramientas para que la puesta en produccion de las aplicaciones

2 ANALISIS 14

web sea practicamente automatica. Es escalable y esta pensado para obtenerun buen rendimiento.


Plataformas en la nube

En los ultimos anos han aparecido numerosas plataformas PAAS (Platformas a service) como DigitalOcean, OpenShift y Amazon AWS. Casi todos elloscuentan con soluciones similares a Heroku en cuanto a prestaciones pero seha decidido utilizar Heroku por las facilidades que ofrece a la hora de ponerla applicacion en produccion.

Servidor dedicado

Ofrece mayor independencia y como en el caso de la base de datos nos asegu-rarıamos que ninguna empresa externa tiene acceso a nuestro codigo. Comodesventajas: mayor mantenimiento y dificultades para escalar en el caso deque la aplicacion aumente el numero de usuarios o el trafico.

2.2.8 Herramienta de construccion

Alternativa elegida

Grunt es una de las primeras herramientas de este tipo en aparecer y sinduda la mas extendida, cuenta por tanto con un gran numero de plugins ydocumentacion.


Gulp

La principal diferencia entre ambas esta en la sintaxis de sus archivos; mien-tras que Grunt las acciones se definen mediante un archivo de configuracion,en Gulp se usa un archivo mucho mas compacto en el que las acciones seespecifican con funciones como si tratase de un script. Destaca por su mayorvelocidad aunque la diferencia no es tan determinante para compensar lafalta de documentacion.

2 ANALISIS 15

2.2.9 Testing

Alternativa elegida

Se ha obtado por Karma como framework de testeo por ser uno de losmas utilizados porque se puede encontrar buena documentacion de su uso eneste tipo de proyectos. Ademas es el framework utilizado por el equipo dedesarrollo oficial de AngularJS y tiene una buena integracion con Grunt.


Protractor

Es un end-to-end framework para probar aplicaciones AngularJS. Es un pro-grama en Node.js basado en WebDriverJS. Protractor simula la ejecucion delos tests en un navegador real, realizando las acciones como si de un usariofinal se tratase. Su principal ventaja es que esta especialmente disenado paraser usado en aplicaciones Angular, pero se ha descartado por no estar tanextendido y bien documentado como Karma.

2.3 Identificacion de usuarios participantes y finales

2.3.1 Usuarios participantes

• Eduardo Benito: realizador del proyecto.

• Julio Rubio: tutor academico del proyecto.

2.3.2 Usuarios finales

La aplicacion se encontrara disponible en internet y sin restricciones de ac-ceso. Cualquier persona podra acceder a la aplicacion mediante la siguientedireccion web:http://backlogiberico.heroku.com/

2.4 Establecimiento de requisitos

2.4.1 Actores

• Invitado: la persona que entra a la aplicacion sin estar registrado, lasunicas opciones que tiene son autenticarse o registrarse.

2 ANALISIS 16

• Usuario: una persona registrada e identificada, podra crear o editarsus tableros y acceder a los tableros publicos o en los que haya sidoinvitado.

• Propietario: un usuario que crea un tablero, puede administrarlo poste-riormente, modificando sus atributos o controlando el acceso al mismo.

• Administrador: puede conceder o denegar el acceso a la aplicacion delresto de usuarios registrados.

2.4.2 Casos de uso

CU.1. Gestionar usuarios

CU.1.1. Registrarse

CU.1.2. Autenticarse en el sistema

CU.1.3. Cambiar contrasena

CU.1.4. Recuperar contrasena

CU.1.5. Cerrar sesion

CU.1.6. Bloquear usuario

CU.1.7. Desbloquear usuario

CU.2. Gestionar tableros

CU.2.1. Crear

CU.2.2. Gestionar acceso

CU.2.3. Modificar

CU.2.4. Borrar

CU.3. Gestionar notas

CU.3.1. Crear

CU.3.2. Modificar

CU.3.3. Borrar

2 ANALISIS 17

CU.4. Gestionar tareas

CU.4.1. Crear

CU.4.2. Modificar

CU.4.3. Asignar a usuario

CU.4.4. Marcar como completada

CU.4.5. Borrar

CU.5. Notificaciones y chat

CU.5.1. Mostrar notificacion

CU.5.2. Escribir mensaje

2.4.3 Base de datos

Se utilizara la base de datos NoSQL MongoDB, por lo tanto no hay quepensar en un modelo de base de datos relacional sino en las colecciones ne-cesarias (equivalentes a las tablas) y teniendo en cuenta el tipo de consultasy la frecuencia con la que se ejecutaran, realizar la separacion.

Existiran 5 colecciones:

• Usuarios

– id: String.

– email: String.

– username: String.

– hashedPassword: String.

– salt: String.

– name: String.

– admin: Boolean.

– guest: Boolean.

– providerId: String.

– provider: String.

2 ANALISIS 18

– photo: String.

– blocked: Boolean.

• Tableros

– id: String.

– title: String.

– content: String.

– access: String.

– created: Date.

– updated: [Date].

– creator: String, referencia al documento de un usuario

– usersId: [String], referencias a documentos de usuarios

• Notas

– id: String.

– text: String.

– color: String, codigo RGB del color.

– y: Number, coordenada y de la posicion de la nota.

– x: Number, coordenada x de la posicion de la nota.

– board: String, referencia al documento de un tablero.

• Tareas

– id: String.

– note: String, referencia al documento de una nota.

– asignedTo: String, referencia al documento de un usuario.

– completed: Boolean.

• Historial

– id: String.

– note: String, referencia al documento de una nota.

2 ANALISIS 19

– author: String, referencia al documento de un usuario.

– date: Date.

– change: String, descripcion del cambio realizado.

3 DISENO 20

3 Diseno

3.1 Arquitectura del sistema

La aplicacion esta compuesta por tres capas siguiendo la aquitectura MVC(Modelo-Vista-Controlador)

Modelo: es la capa que se comunica directamente con la base de datos.Se encarga de todos los procedimientos necesarios para crear, eliminar,recuperar y actualizar informacion de la base de datos, estara imple-mentada en NodeJS y en nuestro caso estara preparada para conectarsea una base de datos MongoDB utilizando Moongose como puente entreambos.

Vista: capa de presentacion, implementa los metodos relacionados conlos componentes de la interfaz de la aplicacion. AngularJS nos permiterealizar aplicaciones SPA (Single Page Aplication), es decir, una solapagina que se ira actualizando dinamicamente a medida que se realicenlas distintas peticiones.

Controllador: se encarga de la comunicacion entre la vista y el modelo.En la aplicacion parte de la logica se manejara dentro de la propiapagina utilizando JavaScript dentro de los controladores de AngularJSy otra parte se hara en el servidor de NodeJS.

El modelo y la parte de la logica manejada en el servidor se implementarancomo una API REST, algo que facilitarıa mucho las cosas en caso de unamigracion a otro sistema de base de datos o incluso de tecnologıa backend.

3 DISENO 21

Figura 1: Esquema MVC para Angular

3.2 Diseno de casos de usos

CU.1. Gestionar usuarios

CU.1.1. Registrarse

Tendremos dos posibles escenarios: para los usuarios que se registren lo-calmente tendran que realizar el registro en la pantalla existente con eseproposito; para los usuarios que hagan uso del login social no realizaraneste paso de forma manual sino que seran registrados automaticamenteal autenticarse por primera vez.

CU.1.2. Autenticarse en el sistema

Nuevamente tenemos dos escenarios. Para los usuarios locales tendranque introducir su usuario y contrasena. Y en caso de usar las platafor-mas sociales tendran que hacer click en el enlace correspondiente, si yaestan autenticados previamente en la plataforma social no sera necesa-ria ninguna otra accion por su parte; si no tendran que autenticarse enese momento. En cualquier caso una vez autenticados seran redirigidosal listado de sus tableros.

3 DISENO 22

CU.1.3. Cambiar contrasena

El usuario podra cambiar la contrasena en cualquier momento introdu-ciendo su antigua contrasena, para asegurarnos que no se trata de otrousuario intentando suplantarle, y la nueva contrasena por duplicado.

CU.1.4. Recuperar contrasena

Como en ningun momento se guarda la contrasena sin cifrar, no sepodra recuperar realmente su anterior contrasena; en su lugar el usuariorecibira por correo un enlace a un formulario para poder cambiarla poruna nueva.

CU.1.5. Cerrar sesion

El usuario deja de estar autenticado en el sistema.

CU.1.6. Bloquear usuario

El administrador puede bloquear a un usuario que este realizando unuso inapropiado de la aplicacion.

CU.1.7. Desbloquear usuario

Por supuesto tambien se podra revertir la accion anterior.

CU.2. Gestionar tableros

CU.2.1. Crear

Todos los usuarios pueden crear nuevos tableros mediante un senci-llo formulario, especificando unicamente un tıtulo, una descripcion yen caso de considerarlo necesario restringir el acceso a determinadosusuarios, como se explica en el caso siguiente.

CU.2.2. Gestionar acceso

El creador del tablero puede elegir si un tablero sera publico (accesiblepor todos los usuarios registrados) o privado. En este ultimo caso deberair eligiendo de una lista los usuarios a los que va a otorgar permiso parapoder acceder y modificar el tablero. El creador puede modificar lospermisos de un tablero en cualquier momento, no solo en el momentode su creacion.

3 DISENO 23

CU.2.3. Modificar

Tanto el tıtulo como la descripcion son modificables por el creador deltablero.

CU.2.4. Borrar

Cuando el creador de un tablero borre un tablero se eliminaran con eltodas sus notas y dejara de estar accesible para todos los miembros,por tanto esta es una accion muy delicada y se mostrara una alerta alusuario para que confirme su decision.

CU.3. Gestionar notas

CU.3.1. Crear

Los creadores y todos los usuarios que dispongan de acceso a un tableropueden crear nuevas notas. La nota se colocara automaticamente en elhueco libre que se disponga en el tablero.

CU.3.2. Modificar

Se podra modificar el texto de la nota ası como su posicion y color,cada modificacion se guardara en la coleccion de historial guardando lafecha, el usuario y una descripcion del cambio que se ha realizado.

CU.3.3. Borrar

Todos los usuarios pueden borrar las notas existentes aunque no lashayan creado.

CU.4. Gestionar tareas

CU.4.1. Crear

Ademas de notas en un tablero se podran crear tareas. La aparienciay disposicion en el tablero sera muy similar pero tiene dos diferenciasfundamentales, la casilla de completitud y el usuario al que estara asig-nada.

CU.4.2. Modificar

El texto es modificable por cualquier usuario, ası como la persona asig-nada y su estado, los dos casos siguientes lo explican con mas detalle.

3 DISENO 24

CU.4.3. Asignar a usuario

Una diferencia principal de una tarea de una nota simple es que sepueden asignar a un usuario para que sea el encargado de llevarla acabo, la accion se realizara mediante un desplegable de los usuariosque tienen acceso a ese tablero.

CU.4.4. Marcar como completada

Cuando una tarea ha sido completado se puede marcar un checkbox. Eltexto de la tarea pasa en ese momento a estar tachado para que sirvade ayuda visual al usuario y pueda ver rapidamente el estado de unatarea.

CU.4.5. Borrar

Exactamente igual que en el caso de las notas simples.

CU.5. Notificaciones y chat

CU.5.1. Mostrar notificacion

Cuando un usuario anada, modifique o elimine una nota de un tablero,se mostrara una notificacion al resto de usuarios conectados al tableroen ese momento.

CU.5.2. Escribir mensaje

Los usuarios de un mismo tablero podran escribir mensajes a modo dechat en la zona de notificaciones de un tablero.

3.3 Diseno de la base de datos

El diseno de la base de datos se ha realizado siguiendo la estructura pensadadurante la fase de analisis.El unico punto a destacar es el uso del tipo especialOid que utiliza MongoDBinternamente para que cada objeto tenga un identificador unico.Este tipo de dato tambien se utilizara en los campos que hacen de referenciaa los documentos de otras colecciones.

3 DISENO 25

3.4 Diseno de la interfaz

Se utilizara Bootstrap 3, un framework CSS, para que la aplicacion tenga unbuen diseno sin necesidad de invertir demasiado tiempo en ello.Todo el sitio web seguira un diseno comun, compuesto basicamente de unacabecera con un menu superior desde el cual podremos acceder a las distintassecciones y una parte principal donde se mostrara el contenido.Dependiendo de si se accede como un usuario invitado o uno registrado elmenu superior constara de los siguientes elementos:

• Invitado (Logo, Tableros, Login, Registro)

Figura 2: Cabecera para usuario invitado

• Registrado (Logo, Tableros, Nuevo tablero, Nombre de usuario con op-cion de Logout)

Figura 3: Cabecera para usuario registrado

• Login

Figura 4: Pantalla de login

3 DISENO 26

• Registro

Figura 5: Pantalla de registro

• Lista de Tableros

Figura 6: Pantalla de listado de tableros

3 DISENO 27

• Nuevo Tablero

Figura 7: Pantalla de nuevo tablero

• Vista Tablero

Figura 8: Pantalla de tablero

3 DISENO 28

3.5 Definicion de los tests

Usuarios

• Registro

Se probaran los siguientes casos cuyo resultado sera fallido:

- Direccion de correo electronico vacıa.

- Direccion de correo electronico con formato invalido (no contengaarroba o termina en un dominio incorrecto).

- Nombre de usuario vacıo.

- Nombre de usuario repetido.

- Contrasena vacıa.

- Contrasena invalida (menor de 6 caracteres).

- Campo de repetir contrasena vacıo

- La contrasena y la contrasena repetida no coinciden.

Tambien se comprobara que si todos los campos se introducen correc-tamente si se realiza el registro.

• Autenticarse en el sistema

- Nombre de usuario vacıo.

- Nombre de usuario no existente.

- Contrasena vacıa.

- Contrasena no se corresponde a la del usuario.

• Cambiar contrasena

- Contrasena anterior vacıa.

- Contrasena anterior no se corresponde a la de usuario.

- Contrasena nueva vacıa.

- Contrasena nueva invalida (menor de 6 caracteres).

- Contrasena repetida vacıa.

- Contrasena repetida no coincide con la contrasena nueva.

3 DISENO 29

• Recuperar contrasena

- Direccion de correo electronico vacıo.

- Direccion de correo electronico no existente.

• Cerrar sesion

- Forzaremos el logout de un usuario de prueba previamente logueadoy comprobaremos que ya no puede acceder a sus tableros.

• Bloquear usuario

- Bloquearemos un usuario de prueba e intentaremos entrar con suscredenciales para comprobar tiene restringido el acceso.

• Desbloquear usuario

- Desbloquearemos un usuario previamente bloqueado y comprobare-mos que despues sı puede acceder.

Gestionar tableros

• Crear

- Tıtulo vacıo.

- Descripcion vacıa.

• Gestionar acceso

- Crear un tablero publico y comprobar que cualquier usuario puedeentrar.

- Crear uno privado sin usuarios asignados y ver que nadie tiene acceso.

- Crear uno privado y asignar usuarios y comprobar que pueden verlo.

• Modificar

- Si el tıtulo queda vacıo comprobar que no deja guardar y muestra unmensaje de error.

• Borrar

- Borraremos un tablero de prueba y comprobaremos que deja de seraccesible para todos.

3 DISENO 30

Gestionar notas

• Crear

- Crear una nota y ver que aparece y es visible para otros usuarios.

• Modificar

- Modificar su texto.

- Modificar su posicion.

- Modificar su color.

En los 3 casos comprobar que los cambios han surtido efecto.

• Borrar

- Borrar una nota y comprobar que deja de ser visible para el autor dela accion y el resto de usuarios del tablero.

Gestionar tareas

• Crear

- Crear una tarea y ver que aparece y es visible para otros usuarios.

• Modificar

- Se realizaran los mismos tests que para una nota simple.

• Asignar a usuario

- Asignaremos una tarea a uno de los usuarios de entre los disponiblesen la lista desplegable y comprobaremos que la tarea ha cambiado.

• Marcar como completada

- Al marcar una de las tareas hay que comprobar que el estilo del textoha pasado a estar tachado.

• Borrar

- Borrar una nota y comprobar que deja de ser visible para el autor dela accion y el resto de usuarios del tablero.

3 DISENO 31

Notificaciones y chat

• Mostrar notificacion

- Nos conectaremos con dos usuarios diferentes a un mismo tablero.Uno de ellos creara, modificara y eliminara una nota y comprobaremossi el otro usuario recibe una notificacion para cada una de las acciones.

• Escribir mensaje

- Accederemos con varios usuarios diferentes, uno de ellos enviara unmensaje y comprobaremos que el resto lo recibe.

Importante

En todos los casos comprobaremos que los cambios producidos son visiblespara el autor de la accion y para todos los usuarios conectados en ese mo-mento al tablero y para los que accedan posteriomente.

4 CONSTRUCCION 32

4 Construccion

4.1 Implementacion

4.1.1 Lenguajes usados

JavaScript Un lenguaje de programacion que permite a los desarrollado-res crear acciones en sus paginas web. JavaScript es un estandar de ECMA(European Computer Manufacturers Association). Tanto NodeJS como An-gularJS utilizan JavaScript; por lo tanto es el unico lenguaje de programacionutilizado en el proyecto.

4.1.2 Tecnologıas empleadas

NPM

Sirve para la gestion de paquetes necesarios para ejecutar o probar la apli-cacion. La manera de indicar los paquetes utilizados es mediante el archivopackaje.json que se encuentra en el directorio raız del proyecto. El archivoconsta de varios atributos fundamentales:

“name”, el nombre de nuestro proyecto, si queremos que se publiqueen el directorio de proyectos de npm tiene que ser unico.

“version”, para indicar la version de la aplicacion y que se ira incre-mentando a medida que se realicen nuevas puestas en produccion.

“description”, en el que se incluye una pequena descripcion de la apli-cacion.

“private”, debemos marcarlo si no queremos que el proyecto se publiqueen el directorio de npm.

“dependencies”, para definir las librerıas que utilizaremos y la versionde cada una, hay varias maneras de indicar la version: de manera exacta,indicando la version mınima o mediante un asterisco para que utilicela ultima version disponible.

“devDependecies”, funciona igual que dependencies pero en este casosolo se incluyen las librerıas que utilizaremos para la fase de desarrollo,

4 CONSTRUCCION 33

como todas las relacionadas con el testing, y que no queremos que sesuban junto con la aplicacion a produccion.

“engines”, para indicar la version de node que usamos.

“scripts”, para definir el comando de ejecucion de los scripts, lo mascomun es definir start para iniciar la aplicacion y test para ejecutar lostests.

Se puede encontrar mas informacion sobre el archivo package.json en la do-cumentacion oficial de NPM:

https://www.npmjs.org/doc/files/package.json.html

Para instalar todas las librerıas indicadas en la seccion de ”dependen-cies”debemos ejecutar el siguiente comando en una consola dentro del di-rectorio de nuestro proyecto:

npm install

GRUNT

Grunt es una herramienta que permite la automatizacion de tareas en pro-yectos web, para este proyecto en concreto se utiliza para eliminar archivosno utilizados, unificar archivos CSS y levantar y configurar el servidor webtanto en desarrollo como en produccion, ası como de ejecutar los tests.

La configuracion de grunt se encuentra en un archivo llamado Gruntfile.jsen la raiz del proyecto. En el que se definen en formato JSON las diferentestareas a realizar y las dependencias entre ellas.

Utilizando grunt levantar un entorno de desarollo en local es tan facilcomo teclear lo siguiente:

grunt server

Con este comando levantamos un servidor en local en el puerto por defecto(aunque se puede modificar en el fichero de configuracion), con una versionfuncional de la aplicacion.

En la misma lınea de sencillez, para ejecutar los test solo tenemos queteclear el siguiente comando.

grunt test

4 CONSTRUCCION 34

4.1.3 Autenticacion

Para facilitar la labor del registro de usuarios y su posterior autenticacion seutilizara la librerıa Passport.js, gracias a ella la integracion con los sistemas delogin proporcionados por las principales redes sociales (Facebook y Twitter)se puede realizar en unas pocas horas.

Passport-twitter y Passport-facebook son las librerıas especıficas para ellogin con Twitter y Facebook ya que podemos utilizar Passport sin redessociales implementando un metodo local con Passport-Local.

En Passport se pueden implementar varias Strategies, con TwitterStra-tegy y FacebookStrategy utilizamos las estrategias de autenticacion que nosproporciona Passport, necesitaremos los parametros los API Key y API se-cret que nos dan las plataformas cuando registramos una aplicacion en ellas.

Las plataformas al hacer login a traves de ellas devuelven un objeto enformato JSON que contiene toda la informacion del usuario y del que pode-mos sacar los atributos que queramos para la aplicacion (ID, nombre, correoelectronico, fotografia de perfil...)

En la tabla de usuario en nuestra base de datos guardaremos un campoextra llamdo provider en el que se almacena si el usuario se ha registradousando una de las plataformas sociales o es un usuario ”local”.

4.1.4 Funcionamiento del tiempo real

En nuestro caso usaremos la librerıa Socket.io que facilita muchısimo el desa-rrollo de este tipo de aplicaciones. El primero paso consiste en abrir unaconexion que se mantenga a la espera de peticiones de todos los clientes:

io = require(’socket.io ’).listen(server);

Despues se crea un manejador para el evento de nueva conexion desdecada uno de los clientes:

io.sockets.on(’connection ’, function(socket) {

...

}

Cada vez que un usuario entra a un tablero el servidor responde a esteevento devolviendo las notas que hay actualmente. Y el cliente queda conec-tado a una sesion.

Aunque la librerıa nos permite separar las sesiones en diferentes grupos,emulando al funcionamiento de las salas de chat, en nuestro caso solo existe

4 CONSTRUCCION 35

un tipo de sesion y se distingue en cada peticion del cliente a que tableroesta conectado gracias a su identificador unico.

Por ejemplo cuando un cliente manda un mensaje, primero se crea elsiguiente evento:

socket.emit(’sendMessage ’, data);

El servidor se encarga de recoger y a su vez eniva un mensaje ”broadcast”,es decir, un mensaje que reciben todos los clientes conectados a la sesionactual menos el usuario que ha enviado el mensaje:

socket.on(’sendMessage ’, function(data) {

if (data){

socket.broadcast.emit(’onMsgReceived ’,

data);

}

});

El resto de clientes se mantiene escuchando el evento broadcast y cuandollega uno nuevo lo muestra en pantalla:

socket.on(’onMsgReceived ’, function(data) {

$scope.notifications.push(data);

});

4.2 Puesta en produccion

Como ya se ha comentado en otros apartados, la aplicacion se encontrara alo-jada en el servicio de almacenamiento en la nube de Heroku. Esta plataformatiene unos mecanismos definidos para poner las aplicaciones en produccionque paso a explicar a continuacion.

El primer paso necesario es que la aplicacion se encuentre dentro de unrepositorio de Git.

Para poder autentificarnos en Heroku sera necesario crear un certificadoSSL y realizar el login en su sistema; para facilitar el proceso la plataformaproporciona una aplicacion CLI con la que poder realizar estos procesos.

Una vez identificados, el siguiente paso sera crear un repositorio remotode Git para heroku, para ello unico que tenemos que hacer es ejecutar elcomando:

4 CONSTRUCCION 36

heroku create

Una vez creado el repositorio remoto debemos ejecutar lo siguiente paraque el codigo de nuestro repositorio local se suba al repositorio remoto deHeroku:

git push heroku master

Antes de subir el codigo a produccion necesitamos asegurarnos de quetodo funciona correctamente, para ello se ha creado una tarea en Grunt queejecute los tests y deja el diretorio preparado antes de realizar el push aproduccion.

Al finalizar el proceso veremos la nueva version de la web en:http://backlogiberico.heroku.com/

5 GESTION DEL PROYECTO 37

5 Gestion del proyecto

El desarrollo se ha llevado a cabo aproximadamente en las horas esperadas,aunque para la implementacion y sobre todo para la documentacion se hainvertido mas tiempo que el previsto, se ha compensado esa desviacion conotras secciones.

1. Gestion del proyectoEstimado: 36 horasReal: 42 horasDesviacion: +16%

2. RequisitosEstimado: 10 horasReal: 8 horasDesviacion: -20%

3. Analisis del sistemaEstimado: 24 horasReal: 22 horasDesviacion: -8%

4. Diseno del sistema (22 horas)Estimado: 22 horasReal: 18 horasDesviacion: -18%

5. ImplementacionEstimado: 60 horasReal: 64 horasDesviacion: +6.6%

6. Pruebas (10 horas)Estimado: 10 horasReal: 8 horasDesviacion: -20%

5 GESTION DEL PROYECTO 38

7. Implantacion del sistemaEstimado: 4 horasReal: 6 horasDesviacion: +50%

En general el calendario del proyecto se ha cumplido en cuanto a fechade finalizacion, aunque no tanto en las horas dedicadas cada dıa/semana,debido a cuestiones laborales. Por tanto se ha dedicado mas horas durantefines de semana y perıodos vacacionales y menos durante dıas laborales.

6 CONCLUSIONES 39

6 Conclusiones

Una de las sorpresas durante de la realizacion de este proyecto es lo agilque puede ser el desarrollo de una aplicacion de estas caracterısticas con lastecnologıas utilizadas.

La integracion entre MongoDB, NodeJS y AngularJS es idonea gracias aluso de un lenguaje comun como JavaScript y del JSON para el intercambiode los datos y su persistencia.

6.1 Mejoras

Se han descartado varias funcionalidades durante el desarrollo de este pro-yecto para no incrementar en exceso su tiempo de desarrollo que podrıamosdesarrollar en fases futuras. Algunas de estas funcionalidades son:

- Poder adjuntar archivos en las notas.- Varios niveles de permisos en la aplicacion Para que el creador de un

tablero pueda establecer para cada usuario a los que garantiza acceso a sutablero permisos de lectura, edicion y/o borrado de las notas.

A nivel tecnico se podrıa haber hecho uso de caracterısticas avanzadas dela librerıa socket.io, como son los namespaces y las rooms que harıan maseficiente la sincronizacion entre todos los usuarios conectados.

Otra de las mejoras a realizar serıa el incremento de la seguridad de laaplicacion, un asunto al que no se le ha dado demasiada importancia y quese podrıa mejorar notablemente utilizando conexiones https.

REFERENCIAS 40

Referencias

[1] Setting Up a MEAN Stack Single Page Application, http:

//scotch.io/bar-talk/setting-up-a-mean-stack-single-page-

application

[2] Registro y autorizacion de usuarios en Node.js con Twitter y Facebook,http://carlosazaustre.es/blog/registro-y-autorizacion-de-

usuarios-en-node-js-con-twitter-y-facebook/

[3] npm Documentation, https://docs.npmjs.com/

[4] Getting started - Grunt, http://gruntjs.com/getting-started

[5] Deploying with Git, https://devcenter.heroku.com/articles/git

desarrollo de herramienta colaborativa en tiempo real · curso académico 2014 / 2015. ... •...

Documents