1. Introducción y objetivos

Nos hemos propuesto desarrollar un sistema de gestión rutas descentralizado, siguiendo las caracteristicas de SOLID. Buscaremos desarrollar el proyecto para que tenga un sistema con una arquitectura descentralizada, que separe el amacenamiento de datos de la aplicación que estamos desarrollando. También, tenemos como objetivo que los usuarios puedan almacenar los datos de sus rutas en sus pods. Los usuarios de la aplicación buscarán registrar sus rutas en el pod propio, las cuales que después podrán visualizar, se podrá compartir con los amigos imágenes, videos u otro tipo de ficheros. Puede obtener notificaciones cuando algún amigo quiera compartir una ruta con él, grupos de amigos con los que compartir

1.1. Vista de requisitos

Funcionales
  • Los usuarios que utilicen la aplicación deberán de poseer un pod de SOLID.

  • El sistema deberá de notificar al usuario cuando quieran compartir un archivo con él.

  • Los usuarios podran crear grupos de amigos con quienes ellos puedan compartir una ruta.

  • Para registrar las rutas los usuarios deberán de estar conectados y autentificados en SOLID.

  • El sistema deberá poder ver las rutas cargadas por usuarios que estén utilizando una app diferente.

No funcionales
  • Facilidad de aprendizaje para interaccionar con la aplicación por parte de los usuarios novatos en un corto espacio de tiempo.

  • El usuario pueda utilizar la aplicación con un tiempo de registro de rutas óptimo (especificar en versiones posteriores).

  • No poseer de una base central de datos, que comprometa la información de los usuarios que la usen.

  • Buscar la seguridad, sin tener puntos vulnerables.

  • Nivel de accesibilidad y usabilidad siguiendo las recomendaciones de w3c.

1.2. Atributos de calidad

  • Disponibilidad: diseño de una aplicación que asegure un cierto grado absoluto de continuidad operacional durante un periodo de duración dado.

  • Seguridad: diseño de una aplicación que no sea vulnerable a ataques externos

  • Usabilidad: diseño de una aplicación que sea fácil de usar por parte de los usuarios que interactúen con ella.

  • Portabilidad: característica que posee un software para ejecutarse en diferentes plataformas.

Table 1. Prioridad de los atributos de calidad en el proyecto
Prioridad Atributo

1

Disponibilidad

2

Seguridad

3

Consistencia

4

Robustez

5

Integridad

6

Modificabilidad

7

Accesibilidad

8

Usabilidad

9

Trazable

10

Rendimiento

11

Testeabilidad

12

Modular

13

Escalabilidad

14

Interoperabilidad

15

Portabilidad

1.3. Stakeholders

Table 2. Stakeholders
Rol/Nombre Expectativas

Profesorado de la asignatura

Seguir un proceso de desarrollo de la aplicación de acuerdo a lo visto en la asignatura, así como un correcto diseño y arquitectura del producto final.

SOLID

Realizar sistema de gestión de rutas descentralizado.

Equipo de desarrollo

Realizar el trabajo asignado siguiendo los requisitos establecidos en la documentación siguiendo una metodología ágil de acuerdo a lo aprendido en la asignatura.

Inrupt

Obtener una aplicación descentralizada para tener un almacen de rutas

Usuario app

Espera una app usable, que no tenga dificultades de uso y sea fácil de interaccionar con ella.

2. Restricciones de arquitectura

Table 3. Restricciones técnicas
Restricción Descripción

RT1

Implementación en React

La aplicación estará desarrollada en React. Nos restringiremos a las limitaciones que pueda tener React como framework.

RT2

Librerías

Usaremos librerías que no dependen directamente de nosotros y por tanto estaremos limitados a su funcionalidad y seguridad.

RT3

Principios SOLID

Seguir los principios SOLID significa hacer una aplicación descentralizada. Esto nos restringirá al uso de los PODS como almacenes de datos.

Table 4. Restricciones organizativas
Restricción Descripción

RO1

Tiempo pre-establecido

Nos tenemos que atener al itinerario de la asignatura.

Table 5. Convenciones
Restricción Descripción

RC1

Arc42

Se usará Arc42 como plantilla para la documentación del proyecto

RC2

Git

Se usará Git como herramienta de control de versiones

3. Contexto y alcance del sistema

3.1. Contexto de negocio

Nuestra aplicacion de rutas descentralizada permitira a los usuarios logearse a traves de su POD que es su identificador en la comunidad de SOLID. El usuario podra subir sus rutas con imagenes de esta. Las rutas y las imagenes quedaran almacenadas en el POD del usuario, lo que hace que este sea su unico propietario.

Diagrama de Negocio

3.2. Contexto tecnico

En el diagrama aparece, ademas del usuario, los profesores encargados de corregir el proyecto y los miembros de SOLID que valoran la aplicación. Lo que aumenta el numero de stakeholders implicados. Al iniciar sesion mediante SOLID se crea en el POD del usuario una carpeta en la que se guardaran las rutas subidas y una subcarpeta con las imagenes.

4. Estrategia de solución

A continuación se hablará de qué compromisos o estrategias se han seguido para implementar la solución.

Decisiones tecnológicas

En cuánto a las tecnologías, se remite a la restricciones RT1, RT2 y RT3. Mucha parte de la tecnología usada para el desarrollo de la solución forma parte de restricciones. Sí se ha sugerido Visual Studio Code como editor de texto en el grupo, pero no se ha fijado un editor para todos como tal.

Descomposición del sistema

La arquitectura adoptada está bastante restringida debido al requisito RT3. Al ser una aplicación descentralizada, la base de datos será el POD de cada usuario. Se tendrá un módulo de comunicación con los PODS basado en la librería LDFlex y un módulo de tratamiento de datos (Linked Data) basado principalmente en rdflib. Debido a la restricción RT1, toda la parte de interfaz gráfica estará situada "junto" a lógica y dominio. Se seguirá la estructura adoptada por la aplicación de SOLID en React de ejemplo, separando en varios documentos JavaScript lo que en otro caso sería CSS y HTML, e implementando la lógica en un único fichero por componente relevante.

Cómo alcanzar los atributos de calidad

Se han explicitado muchos atributos de calidad pero entre los más importantes se encuentran la disponibilidad, seguridad consistencia o robustez.

Para la disponibilidad, (posiblemente) se usará Docker para el despliegue de la aplicación. Usando este entorno de trabajo se eliminarán muchos riesgos de un despliegue "a mano".

Para la seguridad, seguir una buena metodología de programación y respetar el uso de patrones conocidos ayudará a no caer en errores que puedan provocar fallos de seguridad de inyección (SQL, JavaScript). Además, se consultará documentación de otros proyectos SOLID e incorporaremos sus medidas de seguridad.

En cuanto a la consistencia, el equipo se asegurará de aprender y manejar bien la librería rdflib, que se usará para rescatar y escribir datos en los pods correspondientes. De esta manera no tendría por qué existir ningun problema de consistencia. También sería interesante manejar el concepto de sesión.

Por último, seguiremos las recomendaciones del entorno SOLID para el manejo de errores y así asegurarnos de que la aplicación sea robusta y resistente a fallos.

Decisiones de organización

Cada semana se repartirán responsabilidades a cada miembro del grupo. Las decisiones que no se puedan tomar en la reunión se tomarán a lo largo de la semana vía mensajería instantánea. Se intentarán reflejar todas las decisiones y discusiones en el repositorio de GitHub, haciendo uso de la wiki y de los issues.

5. Vista bloque de construcción

Viade
Table 6. Descripciones Nivel 1
Nombre Responsabilidad

Pod

Descrito en glosario

Viade

Nuestra app

6. Vista tiempo de ejecución

Diagrama para ver la interacción para crear un POD en SOLID

Inicio de Sesion

*Explicacion: El usuario entrará a su perfil de SOLID, introducirá sus credenciales para que el servidor de SOLID los valide, una vez hecho, devolverá si el logueo fue satisfactorio o no.

Publicar ruta en POD

*Explicacion: El usuario entrará a su perfil de SOLID, introducirá sus credenciales para que el servidor de SOLID los valide, una vez hecho, devolverá si el logueo fue satisfactorio o no. Después, registrará la ruta y quedará almacenada en su propio POD

Listar rutas del POD

*Explicacion: El usuario entrará a su perfil de SOLID, introducirá sus credenciales para que el servidor de SOLID los valide, una vez hecho, devolverá si el logueo fue satisfactorio o no. Después, accederá al POD del usuario para recuperar el listado de rutas y mostrarselas al usuario.

7. Vista tiempo de despliegue

Vista de despliegue

Podemos ver un primer nodo que es el nodo del computador del usuario, él se conecta al navegador con Internet.

El segundo nodo es la aplicación, necesitamos un servidor para conectarnos a la aplicación de rutas.

Finalmente nos conectamos al último nodo, este nodo es un servidor SOLID que nos proporciona el POD del usuario, nos conectamos al pod del usuario para almacenar la ruta.

La distribución de nuestro sistema fue la misma en todos los escenarios porque solo necesitamos una computadora con internet, podríamos probarla en casa y en la universidad de la misma manera. Desde el principio, sabíamos que se trataba de una aplicación de navegador y SOLID era nuestro sistema para almacenar información de nuestra comunicación, por lo que implementamos viade app para un navegador como Firefox, por lo que obviamente necesitamos una computadora con conexión a Internet y el navegador. Cualquier computadora puede usar la aplicación dechat. Después de conectarnos al chat en el navegador, usamos Internet para conectarnos al servidor SOLID y publicar las rutas.

8. Conceptos

En este apartado se describirá, generalmente las principales regulaciones e ideas de soluciones que serán relevantes en nuestro sistema.

Modelo de dominio
  • Modelos de dominio: Utilizamos un dominio donde tenemos un archivo de índice que depende de bibliotecas, luego tenemos varias carpetas donde almacenamos pruebas y documentación

Conceptos de experiencia de usuario (UX)
  • User interface As user interface we can understand the interface of the application, in this case the interface is a normal chat interface like other chats applications.

  • Internationalization We did the application in English and for the moment we will not add internationalization to other lenguages.

Conceptos de seguridad

La seguridad es uno de los temas claves en este proyecto. La aplicación al estar basada en SOLID archiva la información de cada usuario en su propio POD de forma descentralizada y segura, por lo que se evitan problemas de seguridad.

Arquitectura y patrones de diseño

Se utilizará principalmente la arquitectura REACT para el diseño de la interfaz, la API de Google Maps para trabajar con las rutas y se trabajara con SOLID para almacenar la información personal de cada usuario en su propio POD. Los patrones de diseño se añadirán más adelante.

"Under-the-hood"
  • Manejo de sesión: Iniciamos sesión con nuestro usuario de SOLID en la aplicación, una vez que estamos en el servicio podemos comunicarnos con el servidor.

  • Persistencia para guardar nuestra información, la almacenamos en PODs en SOLID, por lo que no utilizamos información almacenada en bases de datos.

Conceptos de desarrollo

A lo largo del proyecto, el equipo tendrá que

  • Plantear y desarrollar la idea sobre la que se trabajará después

  • Implementar dicha idea.

  • Testear y corregir los errores que se puedan producir.

9. Decisiones de diseño

9.1. Greenfield vs Legacy

9.1.1. Problema

Se plantea el problema del desarrollo de una aplicación descentralizada para el manejo de rutas con tecnologías bastante novedosas y la duda de si se podría reutilizar un esqueleto provisto por los creadores de SOLID.

9.1.2. Alternativas

La primera alternativa es el escenario Greenfield, en el que se tendría que construir la aplicación desde cero. El segundo escenario es adoptar este esqueleto y adaptarnos a sus restricciones

9.1.3. Decisión

Se opta por el escenario Legacy, en el que incluiremos este esqueleto en nuestra aplicación y nos moldearemos a su estructura.

9.2. Uso de react-google-maps

9.2.1. Problema

Para la representación de rutas en el mapa, se necesita una librería, compatible con React, que permita la actualización dinámica del mapa, así como el uso de marcadores y líneas.

9.2.2. Alternativas

Se barajaron dos librerías, react-google-maps y google-maps-react. La primera es un wrapper de la segunda, que simplifica algunos procesos que son muy repetitivos, como la creación de un mapa simple o la incrustación de marcadores. La segunda es la librería oficial de Google, que cuenta con una amplia documentación y está actualizada al día.

9.2.3. Decisión

Se decide el uso de react-google-maps por simplificar mucho el proceso de creación. Se suplirá la falta de documentación con horas de investigación, pero se concluye que compensará.

9.3. Usar rdflib/LDFlex

9.3.1. Problema

Se tiene que usar algún tipo de tecnología para manejar la parte de Linked Data de SOLID y la lectura y escritura en PODS.

9.3.2. Alternativas

Para el manejo de Linked Data hay (hasta dónde se sabe) una sola librería bien documentada en JavaScript, y es rdflib. Para la escritura y lectura en PODS hay varias alternativas, pero se ha desarrollado una específica que funciona bien con SOLID y es LDFlex.

9.3.3. Solución

Se usarán estas dos librerías que parecen ser estándar a la hora de trabajar con SOLID/Linked Data. Se aprenderán ambos frameworks.

10. Requerimientos de calidad

En este apartado vamos a explicar algunos de los requisitos de calidad de este proyecto.

10.1. Arbol de calidad

qualityTree

10.2. Escenarios de calidad

Atributos de calidad Escenarios Prioridad

Disponibilidad

Esta aplicación de rutas descentralizadas estará disponible para todo el mundo que tenga una cuenta de Solid y un Solid POD para compartir su información.

Alto

Modificabilidad

Si es necesario cambiar algo en el proyecto, será posible hacerlo sin modificar mucho el codigo del programa.

Medio

Funcionamiento

Si compartes una ruta en la aplicación, se enviará al instante y no sufrirá ningún cambio ni manipulación.

Alto

Seguridad

La seguridad dependerá del usuario, ya que él es quien otorga permisos sobre su propia información.

Alto

Usabilidad

Será posible compartir información de las rutas de manera descentralizada de forma que el usuario no tenga ningún problema y sea un entorno fácil de entender.

Alto

11. Riesgos y deuda técnica

Los riesgos que vamos a tener a la hora de desarrollar la aplicación son:

Riesgos

*React: Nunca hemos trabajado con React, por lo que supone un riesgo, ya que hay que investigar para encontrar documentación y ver como trabajaremos con él en nuestro proyecto.

*SOLID: Desconocemos el funcionamiento de la arquitectura SOLID y habrá que buscar en la documentación como integrarla a nuestro proyecto para el lenguaje de programación que vamos a utilizar.

*Almacenamiento de información sensible: Necesitaremos investigar las políticas de privacidad de la red para ver que métodos de seguridad hay que seguir para proteger esa información del usuario sensible a ser mostrada o robada por parte de otros usuarios.

*Seguridad en la red: Debemos informarnos como proteger nuestra aplicación para que no haya accesos inesperados a PODS de otros usuarios que puedan ocasionar robos de información de los propios usuarios.

Medidas para reducirlos/eliminarlos

Se van a tomar medidas para que estos riesgos se vean reducidos o eliminados durante el desarrollo de nuestro proyecto para llegar a conseguir el objetivo de desarrollar la aplicación.

*Investigar: Antes de iniciar el proyecto, buscaremos información para ver como funciona un poco la arquitectura/lenguaje que vayamos a desarrollar, que se irá complementando con las búsquedas necesarias para ir desarrollando la aplicación y que vayan siendo necesarias.

*Realización de tutoriales: React tiene una serie de tutoriales de creación de una aplicación que nos puede ayudar a ver como se trabaja con ese lenguaje de programación.

12. Glosario

Termino Definición

AsciiDoc

Formato de escritura en texto plano que puede convertirse a otros formatos como HTML, PDF o ePub.

AsciiDoctor

Herramienta de codigo abierto basada en la sintaxis de AsciiDoc.

API

Es un conjunto de reglas (código) y especificaciones que las aplicaciones pueden seguir para comunicarse entre ellas: sirviendo de interfaz entre programas diferentes de la misma manera en que la interfaz de usuario facilita la interacción humano-software.

Arc 42

Modelo divido en 12 secciones utilizado para comunicar y documentar software y arquitecturas de sistemas.

Chi

Es un paquete de expressjs para trabajar en las pruebas de la aplicación.

Codacy

Herramienta que identifica automáticamente problemas a través del análisis de revisión de código estático. Avisa sobre problemas de seguridad, cobertura de código, duplicación de código y complejidad de código en cada commit o pull request.

Cross-site request forgery

Tipo de exploit malicioso de un sitio web en el que comandos no autorizados son transmitidos por un usuario en el cual el sitio web confía.

Cucumber

Es una herramienta que permite ejecutar descripciones funcionales en texto plano como pruebas de software automatizadas. El lenguaje usado por Cucumber para estas descripciones funcionales se llama Guerkin.

Gatling

Es un marco de prueba de carga y rendimiento de código abierto basado en Scala, Akka y Netty.

Google Maps

Servidor de aplicaciones de mapas en la web que pertenece a Alphabet Inc.

Guerkin

Lenguaje Específico de Dominio creado para resolver un problema.

Jest

Jest es un Framework utilizado para realizar pruebas en JavaScript. Esta enfocado en la simplicidad y no necesita configuracion. Funciona con proyectos usando: Babel, TypeScript, Node, React, Angular, Vue, etc.

JSON

Es un formato de texto sencillo para el intercambio de datos. Se trata de un subconjunto de la notación literal de objetos de JavaScript.

Mocha

Framework de pruebas de JavaScript que se ejecuta en Node.js. Nos da la posibilidad de crear tanto tests síncronos como asíncronos de una forma muy sencilla.

Node

Entorno en tiempo de ejecución multiplataforma, de código abierto, para la capa del servidor basado en el lenguaje de programación ECMAScript.

Parser

Programa informático que analiza una cadena de símbolos de acuerdo a las reglas de una gramática formal.

POD

Personal Online Data, es el espacio en el que se almacenan tus datos, imágenes, etc.

React

React es una biblioteca escrita en JavaScript, desarrollada en Facebook para facilitar la creación de componentes interactivos, reutilizables, para interfaces de usuario.

Ruby

Es un lenguaje de programación interpretado, reflexivo y orientado a objetos.

Ruta

Camino determinado que va de un sitio a otro.

Travis

Servicio de integración continua utilizado para construir y probar proyectos de software alojados en GitHub.

SOLID

Deriva de Social Linked Data, es un conjunto de convenciones y herramientas para construir aplicaciones sociales descentralizadas.

About arc42

arc42, the Template for documentation of software and system architecture.

By Dr. Gernot Starke, Dr. Peter Hruschka and contributors.

Template Revision: 7.0 EN (based on asciidoc), January 2017

© We acknowledge that this document uses material from the arc 42 architecture template, http://www.arc42.de. Created by Dr. Peter Hruschka & Dr. Gernot Starke.