1. Introducción y objetivos

El objetivo del proyecto es la creación de un sistema descentralizado de gestión de rutas basado en las especificaciones SOLID, en la que lo más importante será la privacidad de los datos y el control de los mismos por los usuarios.

1.1. Resumen de requisitos

  • El sistema debe utilizar una arquitectura descentralizada, separando datos y aplicación.

  • Los usuarios deben poder ver sus rutas en un mapa.

  • Los datos de las rutas se deben guardar en los PODs de los usuarios.

  • Los usuarios pueden tener amigos con los que compartir sus rutas.

  • El usuario puede recibir notificaciones cuando le compartan una ruta.

  • Los usuarios pueden compartir fotos, videos u otros ficheros con sus amigos.

1.2. Objetivos de calidad

Prioridad Atributo de calidad Motivación

1

Descentralizado

Cada usuario debe tener sus datos en su propio servidor, sin que ningún otro usuario pueda acceder a ellos.

2

Seguridad

Los usuarios deben tener total control sobre sus datos personales, rutas subidas…​

3

Usabilidad

La aplicación debe poder usarse por cualquier persona independientemente de su nivel de informática.

4

Disponibilidad

La aplicación debe estar disponible en cualquier momento del día sin interrrupción, una caída de la aplicación afectará a su imagen y bajarán las visitas.

5

Rendimiento

La aplicación debe manejar unos tiempos de carga razonables para que los usuarios no pierdan la paciencia.

1.3. Stakeholders

Rol Descripción Expectativas

Profesor

Encargado de supervisar y evaluar el proyecto

Espera que los estudiantes trabajen continuamente en el proyecto y que la aplicación cumpla con ciertos criterios y requisitos funcionales

Usuarios

Personas que van a hacer uso de la aplicación

Esperan que la aplicación sea segura, disponible, cuente con un buen rendimiento y sea fácil de comprender y usar

Inrupt

Organización que trabaja con Solid y ha propuesto el desafío de desarrollar una aplicación de rutas descentralizadas

Esperan que los estudiantes creen una aplicación de rutas descentralizadas utilizando la tecnología Solid y que cumpla una serie de requisitos técnicos y de calidad

Desarrolladores de software

Estudiantes que se encargarán de desarrollar la aplicación

Esperan aprender nuevas tecnologías como es SOLID y no ceñirse solo a ciertas tecnologías que podrían caer en desuso. Otra expectativa es reforzar la capacidad de trabajar en grupo que nos ayudará a adaptarnos más fácilmente en las empresas

2. Restricciones de la Arquitectura

Contenido

En esta sección, vamos a describir de manera detallada las diferentes restricciones que podemos contemplar sobre el desarollo del proyecto VIADE. Se ha optado por agrupar las restricciones en varias categorías, pudiendo distinguir las siguientes:

  • Restricciones tecnológicas.

  • Restricciones de implementación.

  • Organizativas.

  • De diseño.

  • Convenciones.

Estas restricciones limitan a los miembros del equipo a la hora de desarrollar el proyecto, obligando a estos a ajustarse a las decisiones tomadas en base a dichas restricciones.

Motivación

El objetivo de este proyecto es desarrollar una red social descentralizada que permita a los usuarios subir y registrar sus rutas, compartirlas con sus amigos.

Pudiendo recibir comentarios de estos, así como poder adjuntar archivos multimedia asociados a cada una de sus rutas.
De forma que el usuario tenga control total a la hora de decidir si desea comparti sus rutas, o por el contrario mantenerlas en su propio servidor (POD).

Restricciones

A continuación, se muestran las diferentes restricciones agrupadas por categorías, en forma de tabla (una para cada categoría).

Table 1. Restricciones tecnológicas
Restricción Explicación

Usar lenguaje JavaScript

Utilizar como lenguaje de codificación el estándar ES6 (JavaScript).

Usar framework React.js

Para el desarrollo de la interfaz de usuario y sus componentes Web, se usará el framekwork React.js, que plasma los cambios en un DOM virtual antes de representarlos en el DOM real.

Usar la tecnología SOLID.

Implementar el sistema de persistencia mediante servidores POD descentralizados, con la tecnología SOLID desarrollada por Inrupt.

Software de Control de Versiones Git.

Se debe utilizar la plataforma Git para gestionar las versiones y la evolución del proyecto, con ayuda del repositorio remoto que se nos ofrece en GitHub.

Uso del modelo Arc42 para documentar.

A la hora de documentar, se requiere utilizar el modelo Arc42, respetando su estructura y utilizando la plantilla AsciiDoc.

Table 2. Restricciones de implementación
Restricción Explicación

Sistema descentralizado.

Debe consistir en una red social descentralizada donde se almacenen los datos (rutas) en un servidor propio, del cual dispone cada usuario.

Datos separados.

Obligatorio que los datos de los usuarios estén separados de la lógica de la aplicación, en un servidor POD.

Lógica y UI juntas.

La lógica referente a la interacción entre el usuario y los componentes Web, validación de entradas, navegación…​etc debe gestionarse de manera conjunta a través de los componentes de React.

Integración del FrontEnd con BackEnd.

Debe integrarse correctamente la parte de cliente/usuario, con la parte de datos de la aplicación, es decir, persistencia y lógica computada en el servidor. Para ello será necesario integrar React con SOLID.

Desarrollo de una aplicación Web

El resultado final debe ser una aplicación Web soportada mediante un servidor, y a la cual se pueda acceder desde cualquier equipo, incluyendo opcionalmente dispositivos móviles.

Table 3. Restricciones organizativas
Restricción Explicación

Realizar la documentacion de forma incremental

Puesto que carecemos de experiencia en las tecnologias solicitadas, no podemos aportar una documentacion completa de la forma mas eficiente.

Entregas periodicas de una implementación parcial

Debido a la metodologia de la practica, debemos realizar entregas periodicas con funcionalidades, lo que puede afectar al rendimiento en otros aspectos. Por ejmeplo pruebas u optimizaciones.

Redactar actas semanalmente

Esto nos obliga a realizar un seguimiento continuo del proyecto, lo cual beneficia la calidad del mismo.

Uso de ramas individuales

Por cada feature se creara una rama, la cual partira del subconjunto al que pertenece el programador dentro del paradigma organico del grupo de trabajo. De esta forma se intenta impedir el codigo muerto, o crear conflictos con otras partes del proyecto.

Table 4. Restricciones de diseño
Restricción Explicación

Uso de componentes React

De esta forma, los componenetes ya creados pueden ser incluidos facilmente en nuestra aplicacion, sin necesidad de crearlos desde cero.

Uso de Solid

Utilizando solid, obtenemos un paradigma de persistencia desacoplada. Esto nos obliga a no depender de las bases de datos mas usuales. En su lugar los datos se almacenan de forma privada en el servidor del usuario (Pod), a no ser que este decida compartirla.

Division del proyecto de forma interna

Una division estructurada del diseño de la aplicacion (en cuanto a diagrama de directorios) resulta muy util de cara a procesar cambios, o localizar componentes de forma sencilla. Esta directriz, aunque poco usada, es altamente recomendable.

AsciiDoctor

Utilizamos esta herramienta para la documentacion porque cuenta con diversas plantillas muy utiles. Ademas, es capaz de dar formato a multiples lenguajes (.doc, .html, etc) lo que facilita una documentacion mas accesible.

Table 5. Convenciones
Restricción Explicación

Separación en capas

El código debe separarse en capas/módulos cohesivos y con una interfaz bien definida aumentando así la mantenibilidad del código. El front-end y el back-end deben estar bien delimitados para hacer que la comunicación sea lo mas sencilla posible.

Agrupar componentes en paquetes

Relacionado con la restricción anterior, es útil agrupar componentes y clases relacionadas en paquetes o módulos aumentando la cohesión.

3. Alcance y contexto del sistema

Contenido

Nuestra aplicación descentralizada de rutas da la posibilidad al usuario de compartir sus rutas fácilmente sin poner en riesgo la seguridad de sus datos.

Motivación

Las interfaces de dominio y las interfaces técnicas para los socios de comunicación se encuentran entre los aspectos más críticos de su sistema. Asegúrese de entenderlos completamente.

Forma

Varias opciones:

  • Diagrama de contexto

  • Listas de socios de comunicación y sus interfaces.

3.1. Contexto empresarial

Contenido

Los usuarios de la aplicación podrán compartir sus rutas con otros usuarios sin que sus datos tengan que pasar a través de un servidor externo. Es decir esta aplicación utiliza datos que están en nuestro servidor privado (POD). De este modo sus datos simpre están en un sitio seguro.

Motivación

Cada usuario podrá compartir sus rutas y podrá acceder a rutas de otros usuarios.

Forma

En un futuro se realizará el diagramas para el Business Context, seguido de una breve explicación.

bd

3.2. Contexto técnico

Backend

La aplicación utiliza un servidor SOLID a través de un POD. Un POD es como una clave para un usuario. Determina quién puede obtener un contenido, como las rutas, evitando accesos no deseados de personas externas.

Frontend

Para la creación de interfaces de usuario utilizaremos React, una biblioteca de JavaScript diseñada para crear interfaces de usuario con el objetivo de facilitar el desarrollo de aplicaciones de una sola página.

Contenido

Leaflet/React Leaflet, GitHub, Visual Studio Code ejecutado sobre una terminal Windows / Linux con npm (sistema de gestión de paquetes por defecto para Node.js).

Motivación

Se ha escogido SOLID para el backend por su seguridad, al darnos la capacidad para tener una aplicación descentralizada. Así mismo, se utiliza React para el Frontend por su facilidad para la creación de interfaces de usuario.

Forma

Se describirá en un diagrama UML, seguido de una breve explicación

El siguiente diagrama es una descripción técnica del funcionamiento de nuestra aplicación, siendo las cajas rojas los elementos más complejos que en versiones posteriores se pasarán a representar con más diagramas. La aplicación permite ver las rutas en un mapa usando la API de Leaflet, encapsulada dentro de la librería de componentes React Leaflet.

TecnicDG

4. Estrategia de solución

A continuación, se muestra una tabla en la que se describen las diferentes tecnologías que se han ido utilizando a lo largo del desarrollo de la aplicación. Se recogen aquellas tecnologías y herramientas realmente importantes y que tienen cierto peso en el desarrollo del proyecto.

Table 6. Tecnologias
Tecnología Propósito

Solid

Separación entre la aplicación y los datos de los usuarios.

React

Framework para la creación de la interfaz de usuario.

GitHub

Control de versiones.

Javascript

Lenguaje de programación objeto/funcional basado en eventos ideal para implementar la lógica de negocio del lado del cliente/navegador.

Visual Studio Code

IDE para la codificación de la solución y de la documentación.

React Bootstrap

Framework de estilos que proporciona componentes React ya implementados para modelar la interfaz de usuario de manera rápida y elegante.

React Leaflet Map

Componente de React que nos permite visualizar un mapa con coordenadas, polilíneas, figuras, layers…​ Hace uso de la API de Leaflet Map.

React Testing Library + Jest

Librerías que proporcionan herramientas para llevar a cabo el desarrollo de las pruebas unitarias TDD del proyecto.

Jest Cucumber

Herramienta que proporciona todo lo necesario para la especificación y definición de las pruebas de aceptación o BDD, mediante las plantillas para definir las historias de usuario.

Jest Puppeteer

Librería para llevar a cabo la implementación de las pruebas de aceptación definidas en las historias de usuario y poder ejecutarlas en un entorno controlado mediante Chromium.

Docker Desktop + Docker Compose

Herramienta utilizada para desplegar la aplicación web en un contenedor local, junto con un servidor de POD’s con la ayuda de Docker Compose. De esta forma se pueden realizar los test de carga en un entorno controlado.

Gatling Load Testing

Herramienta de testing que permite realizar tests de carga para generar unos reportes finales que puedan reflejar el rendimiento de las operaciones de la aplicación, y así detectar aquellas zonas en las que el rendimiento sea inferior.

Asciidoctor

Herramienta para agilizar el proceso de creación de la documentación del proyecto, junto con la extensión AsciiDoc de Visual Studio Code.

Enfoques para alcanzar objetivos de calidad

En esta sección, se proporciona una lista de los enfoques que se han llevado a cabo para alcanzar diversos objetivos de calidad.

  • Uso de Bootstrap y React framework para el diseño de la interfaz de nuestra aplicación web, mejorando así la usabilidad y accesibilidad.

  • Uso de Solid nos permite crear una aplicación descentralizada y en la que cada usuario es responsable de sus datos, y de con quién desea compartirlos mejorando así la seguridad y disponibilidad de los datos.

  • Uso de PODs de Solid proporciona seguridad a los usuarios a la hora de evitar el acceso a sus rutas a usuarios no autorizados.

  • Separación del equipo de desarrollo en frontend y backend para agilizar el proceso de investigación sobre las tecnologías utilizadas y así obtener funcionalidad relativamente rápido.

  • Uso de la API de Leaflet para representar las rutas del usuario en un mapa y así mejorar la usabilidad, al ser más intuitivo visualizar la ruta dibujada en un mapa. También mejora la usabilidad considerablemente a la hora de permitir la creación de una ruta seleccionando los puntos en un mapa.

  • Uso de spinners y overlays, es decir, iconos y pantallas de carga para mejorar la experiencia del usuario en aquellas operaciones que impliquen una mayor tiempo de respuesta.

  • Separación del código en varios módulos o capas, una dedicada a la renderización de los componentes de la interfaz de usuario y otra encargada de procesar los datos y de su persistencia. De este modo se aumenta la mantenibilidad del código y su modularidad, lo cual hace que sea más sencillo realizar cambios en un futuro.

  • Implementar componentes de React desacoplados de la lógica, es decir, pasando referencias a las funciones que utilizan a través de sus Props. De este modo, se mejora la adaptabilidad de estos componentes y su reutilización, además de que se hace más fácil testearlos mediante pruebas unitarias.

  • Uso de funciones Async/await para escribir código completamente asíncrono mientras realizamos tareas asíncronas en segundo plano, mejorando así la eficiencia y la disponibilidad de los datos en la interfaz de usuario.

Descomposición de alto nivel

A continuación, se muestra el diagrama de la descomposición de alto nivel de nuestra aplicación web. En el cual podemos observar que se divide en dos funcionalidades principales: usuarios y servicio de rutas.

Descomposición de alto nivel del sistema.

En este diagrama, se muestran de color azul claro, aquellos módulos o componentes de alto nivel en los que se divide la aplicación. Por otro lado, aquellos componentes o funcionalidades concretas que no ha sido posible finalizar se muestran en rojo. En cuanto a los módulos de color verde, estos representan aquellas funcionalidades que han sido terminadas y probadas con éxito, y que están disponibles en la versión actual de la aplicación.

Puede verse que casi el 100 % de la funcionalidad ha sido implementada, exceptuando el caso concreto de crear una nueva ruta mediante un fichero, el cual contenga toda la información de la ruta. En un futuro se propone implementar esta funcionalidad permitiendo a la aplicación generar rutas a partir de ficheros subidos por los usuarios, pudiendo incluso la subida simultánea de múltiples ficheros.

Los usuarios serán capaces de crear sus propias rutas, para luego visualizarlas en un mapa. Además también tendrán la posibilidad de añadir comentarios y fotos a sus rutas. Otra funcionalidad destacable, es la posibilidad de agregar amigos introduciendo su webID. No existen las peticiones de amistad, así que una vez agregado el usuario, este ya entablará una relación de amistad con nosotros.

El usuario loggeado tendrá la posibilidad de compartir sus rutas con otros usuarios, que deben formar parte de su lista de amigos. Se puede compartir una ruta con varios amigos, de tal forma que estos podrán ver la información básica de la ruta, visualizarla en el mapa, y ver los comentarios y fotos publicadas por el autor de la ruta.

Decisiones Organizativas

Como ya se mencionó antes, se ha llevado a cabo una separación en capas o módulos bien definidos, de forma que se mejore así la mantenibilidad del código, además de facilitar el reparto de tareas entre los miembros del equipo.

También se ha optado por comenzar el desarrollo de aquellas funcionalidades o tareas de mayor prioridad como añadir y visualizar rutas, de forma que así se obtiene algo funcional que pueda ser enseñado al cliente (en este caso al profesor de prácticas) en periodos tiempos relativamente cortos.

Por otro lado, se ha llevado a cabo la division del trabajo en dos equipos (backend y frontend), cuyo reparto entre los miembros del grupo se muestra a continuación.

BackEnd FrontEnd

Alejandro Iglesias

Diego Marcos

Francisco Barriocanal

Adnane Moulud

Pedro José Fernández

Lucía Prado

Alejandro Flórez

Convenciones

El código debe separarse en capas/módulos cohesivos y con una interfaz bien definida aumentando así la mantenibilidad del código. El front-end y el back-end deben estar bien delimitados para hacer que la comunicación sea lo mas sencilla posible.

Relacionado con lo anterior, es útil agrupar componentes y clases relacionadas en paquetes o módulos aumentando la cohesión.

De este modo, obtenemos una arquitectura en dos capas, que se conecta mediante una interfaz definida por los servicios, que contienen la lógica de negocio y son quienes se comunican con los servicios de persistencia.

5. Vista del bloque de contrucción

5.1. Sistema general de caja blanca

Arquitectura del Contexto del Sistema

El objetivo de la caja blanca que se muestra en la imagen superior, es reflejar una visión global del sistema. El usuario interactúa con su propio POD, sobre el cual tiene control total, y también interacciona con la aplicación Viade, que es la caja negra que se describirá a continuación.

5.1.1. Aplicación Viade

El bloque Aplicación Viade, se intercomunica con el bloque de caja blanca que representa al POD del usuario, con el cual intercambia datos. También interactúa con el usuario, pues representa la aplicación en su totalidad. Su responsabilidad es la de procesar las peticiones que realiza el usuario desde su navegador para comunicarse con su POD y devolverle unas respuestas en base a esta información. El tiempo de respuesta de la aplicación debe ser lo suficientemente corto como para satisfacer las peticiones del usuario en un tiempo razonable. Además, este bloque no debería acceder a los datos del POD del usuario, a menos que este de su consentimiento.

5.2. Nivel 1

Nivel 1

En este primer nivel, se detallan los bloques de construcción contenidos en la caja negra descrita en la sección anterior, Aplicación Viade. Esta caja es de vital importancia ya que representa a la aplicación en su totalidad, y es la que lleva a cabo toda la lógica de negocio de la aplicación, que está desacoplada de los datos de los usuarios, que residen en los PODs.

La responsabilidad de esta caja es llevar a cabo el procesamiento de los datos de acuerdo a la lógica de negocio de la aplicación, comunicándose mediante la interfaz SOLID con los usuarios y sus PODs, así como con otras dependencias como React Leaflet o la API File. Podemos distinguir entre Front End y Back End. El primero se encarga principalmente de la lógica de negocio que trata con los objetos del dominio y con los componentes de la interfaz de usuario modelados mediante Componentes JSX de React.js. Este módulo utilizará los servicios de la capa de Back-End para obtener datos y escribirlos en los PODs de los usuarios, recibiendo como respuestas entidades del dominio de alto nivel. Por otro lado, en el Back End se utilizan librerías como tripledoc para trabajar con los documentos del POD.

Antes de describir las cajas negras, vamos a explicar la nueva caja blanca de nombre Sistema de autenticación, la cual se encuentra dentro de la aplicación de Viade, y actúa como un sistema vecino de ambas cajas negras. Este sistema de autenticación interactúa con el Front End, ya que existen componentes de la interfaz de usuario que modelan el formulario de Log In, los cuales permiten escoger el modo para iniciar sesión, es decir, introduciendo directamente el WebID del usuario, o a través de un provedor de PODs, incluyendo nuestro propio servidor de PODs. De este modo, se redirige al usuario al formulario de Log In para recoger la información de sus credenciales y enviarlas al sistema de autenticación de SOLID.

El Back End también se relaciona con el sistema de autenticación, pues en muchos casos necesita acceder a los datos del usuario en sesión para realizar las consultas sobre los datos de su POD, teniendo en cuenta los permisos proporcionados por su dueño.

5.2.1. Descripción de las cajas negras de el nivel 1.

A continuación, se muestra en formato de tabla, las dos cajas negras que residen en este primer nivel, junto con una breve descripción de sus responsabilidades.

Nombre Responsabilidad

Front End

 Interactuar con el usuario final, recogiendo los datos de entrada proporcionados por el mismo en las distintas operaciones disponibles a través de la interfaz. Se comunica con el backend para enviarle los datos y también para recibir los resultados de las operaciones y mostrarselas al usuario.

BackEnd

Recibe los datos del FrontEnd y los procesa de distinta forma para obtener resultados que mostrar al usuario. Tiene la responsabilidad de acceder al POD del usuario para consultar sus datos, escribirlos o compartir información entre diversos PODs que no tienen porqué ser del usuario que está en sesión.

5.2.2. Interfaces importantes

En este primer nivel, podemos distinguir dos interfaces importantes. La primera es la interfaz entre FrontEnd y BackEnd, la cual está definida por una capa de servicios que actúa de fachada entre ambas capas. De este modo, el front end solo conoce los servicios que necesita y se despreocupa de cómo se lleven a cabo esos servicios en el back end.

Por otro lado, se encuentra una segunda interfaz entre el back end y el Solid POD, es decir, el backend no trabaja directamente sobre el POD, si no que se usan interfaces y librerías como tripledoc para manejar los documentos y los denominados triples despreocupándonos de lidiar con el lenguaje RDF, y así poder llevar a cabo la consulta de datos y su modificación de manera flexible.

5.3. Nivel 2

Nivel 2

En este segundo nivel se descompone el sistema en dos cajas blancas, el front end y el back end.

5.3.1. Caja blanca del Front End

En cuanto al Front End, su responsabilidad ya ha sido mencionada anteriormente. Simplemente interacciona con el usuario para obtener datos de entrada y enviárselos al back end, del cual recibe los resultados a mostrar.

Descripción de las cajas negras del Front End

En este apartado se muestra en una tabla las cajas negras del Front End junto con su responsabilidad.

Nombre Responsabilidad

Módulo de autenticación

Interactúa con el usuario para determinar el modo de autenticación, y así comunicarse con el sistema de autenticación de SOLID. Contiene los componentes de la interfaz y la lógica necesaria para modelar la autenticación dentro de la aplicación.

Gestión de rutas

Es un módulo que se encarga de modelar operaciones básicas sobre las rutas, es decir, añadir rutas, listarlas, o eliminarlas del POD del usuario. Componentes e infraestructura necesaria para renderizar la interfaz de usuario para el CRUD de las rutas. Se comunica con la caja negra BackMain para consumir sus servicios.

Módulo de amigos

Contiene los componenes, infraestructura y lógica necesaria para modelar los elementos de la interfaz de usuario relacionados con añadir amigos y visualizar su lista de amigos. También se comunica con la fachada del BackEnd para utlizar sus servicios.

Módulo de compartir

Engloba toda la infraestructura para compartir rutas con los amigos del usuario, incluyendo comentarios y fotos, así como proporcionar un listado de las rutas que me han compartido mis amigos. Este módulo interacciona con el CRUD de rutas para seleccionar qué ruta compartir y también con el Módulo de amigos para escoger al grupo de amigos con quien compartir la ruta.

5.3.2. Caja blanca del Back End

Por otro lado, disponemos de la caja blanca del BackEnd, que como ya vimos se encarga de manejar los documentos del POD, consultar sus datos y modificarlos, para luego comunicar los resultados al Front End.

Descripción de las cajas negras del Back End

Se describen en formato de tabla las diferentes cajas negras que conforman el Back End, junto con la responsabilidad de cada una de ellas.

Nombre Responsabilidad

BackMain

Se trata de la fachada que representa las operaciones que proporciona todo el subsistema del Back End, y que servirá a la capa de servicios que utiliza el Front End. Se comunica con los diversos módulos del FrontEnd y también con una serie de módulos que residen en el back end, que constituyen cajas negras que trabajan sobre el POD del usuario.

CRUD de rutas

Se trata del módulo complementario a la gestión de Rutas del Front End. Proporciona una serie de servicios relacionados con la inserción, eliminación y listado de las rutas del POD, siguiendo diversos criterios, como buscar por ID, WebID…​etc

Gestión de amigos

Modela las operaciones que se pueden realizar en cuanto a los amigos de un usuario, listarlos, añadirlos…​ manejando estos datos dentro del POD del usuario en sesión.

Compartir

Lleva a cabo las operaciones relacionadas con la lógica para compartir rutas, comentar en mis rutas o en las de mis amigos, subirles fotos, además de gestionar el envío y recibo de notificaciones en la bandeja de entrada o inbox del POD de los usuarios.

5.3.3. Interfaces importantes

Interfaz para las notificaciones

El módulo de las notificaciones se encuentra integrado tanto en el módulo de compartir del front end como del back end. Su responsabilidad es la gestión de las notificaciones que reciben los usuarios cuando se les comparte una ruta, o alguien comenta en ella o sube alguna foto, así como cuando el autor de la ruta decide eliminarla de su POD.

En el lado del front end, existe un servicio ejecutándose en segundo plano que monitoriza cada cierto tiempo el inbox del POD del usuario en sesión para comprobar si hay alguna notificación. Esto mejora la experiencia del usuario, ya que se le notifica sobre cualquier actividad relacionada con las rutas que ha compartido o que le han compartido, además de que no afecta a otros módulos de la aplicación al tratarse de un proceso en segundo plano modelado mediante la función setInterval del estándar de JavaScript.

6. Vista de tiempo de ejecución

Contenido

La vista de tiempo de ejecución describe el comportamiento concreto y las interacciones de los componentes básicos del sistema en forma de escenarios de las siguientes áreas:

  • casos de uso o características importantes: ¿cómo los ejecutan los bloques de construcción?

  • interacciones en interfaces externas críticas: ¿cómo cooperan los bloques de construcción con los usuarios y los sistemas vecinos?

  • operación y administración: lanzamiento, puesta en marcha, parada

  • escenarios de error y excepción

Observación: El criterio principal para la elección de posibles escenarios (secuencias, flujos de trabajo) es su * relevancia arquitectónica *. Es * no * importante describir una gran cantidad de escenarios. Debería más bien documentar una selección representativa.

Motivación

Debe comprender cómo (las instancias de) bloques de construcción de su sistema realizan su trabajo y se comunican en tiempo de ejecución. Capturará principalmente escenarios en su documentación para comunicar su arquitectura a las partes interesadas que estén menos dispuestas o sean capaces de leer y comprender los modelos estáticos (vista de bloque de construcción, vista de implementación).

Forma

Hay muchas anotaciones para describir escenarios, p. Ej.

  • lista numerada de pasos (en lenguaje natural)

  • diagramas de actividades o diagramas de flujo

  • diagramas de secuencia

  • BPMN o EPCs (cadenas de procesos de eventos)

  • máquinas de estado

  • …​

6.1. Iniciar sesión

inicioSesionDiagrama

6.2. Crear ruta

  1. Click en "Añadir ruta" en la barra de navegación.

  2. Rellenar los campos sobre información de la nueva ruta.

  3. Click en el botón "Añadir ruta".

  4. Rellenar los campos sobre la información de los hitos de la ruta.

  5. Click en el botón "Añadir hito".

  6. Click en el botón "Guardar ruta" para guardar la ruta en el POD.

DiagramaAddRuta

6.3. Ver rutas

  • Click en "Mis rutas" en la barra de navegación.

DiagramaVerRutas

6.4. Eliminar ruta

  1. Click en "Mis rutas" en la barra de navegación.

  2. Escoger la ruta a eliminar.

  3. Click en el botón de "Eliminar" de la ruta elegida y se eliminará la ruta del POD.

DiagramaEliminarRuta

6.5. Agregar amigo que existe y no es amigo del usuario

  1. Click en "Amigos".

  2. Escribimos el WebId del usuario que queremos agregar como amigo.

  3. Click en el botón de "Agregar".

  4. Existe el amigo y lo agrega en la lista de amigos del usuario.

DiagramaAgregarAmigoExistente

6.6. Agregar amigo que no existe o ya es amigo del usuario

  1. Click en "Amigos".

  2. Escribimos el WebId del usuario que queremos agregar como amigo.

  3. Click en el botón de "Agregar".

  4. No existe el webId del amigo que queremos agregar o ya es un amigo, no se añade un nuevo amigo en la lista de amigos.

DiagramaAgregarAmigoNoExistenteOYaAmigo

6.7. Listar amigos

  • Click en "Amigos" en la barra de navegación.

DiagramaVerAmigos

6.8. Compartir ruta con amigos

  1. Click en "Mis rutas".

  2. Escoger la ruta a compartir.

  3. Click en el botón de "Compartir".

  4. Escogemos los amigos a los que queremos compartirle la ruta.

  5. Click en "Compartir".

DiagramaCompartirRuta

6.9. Ver rutas compartidas por usuarios

  1. Click en "Compartido conmigo".

DiagramaRutasCompartidas

6.10. Comentar una ruta propia

  1. Click en "Mis rutas".

  2. Escogemos la ruta en la que queremos crear un comentario.

  3. Click en "Comentarios".

  4. Escribimos el comentario y click en el botón de "Publicar".

DiagramaComentarRuta

6.11. Añadir una imagen a una ruta propia

  1. Click en "Mis rutas".

  2. Escogemos la ruta en la que queremos añadir una imagen.

  3. En Galería seleccionamos la imagen y click en el botón de "Subir".

DiagramaSubirImagenRuta

6.12. Ver comentarios de una ruta propia

  1. Click en "Mis rutas".

  2. Escogemos la ruta de la que queremos ver los comentarios.

  3. Click en "Comentarios".

DiagramaVerComentariosRuta

6.13. Ver galería de una ruta propia

  1. Click en "Mis rutas".

  2. Escogemos la ruta de la que queremos ver la galería.

  3. Visualizamos en la galería de la ruta las imágenes.

DiagramaVerGaleriaRuta

6.14. Comentar una ruta compartida

  1. Click en "Compartido conmigo".

  2. Escogemos la ruta compartida en la que queremos crear un comentario.

  3. Click en "Comentarios".

  4. Escribimos el comentario y click en el botón de "Publicar".

DiagramaComentarRutaCompartida

6.15. Añadir una imagen a una ruta compartida

  1. Click en "Compartido conmigo".

  2. Escogemos la ruta en la que queremos añadir una imagen.

  3. En Galería seleccionamos la imagen y click en el botón de "Subir".

DiagramaSubirImagenRutaCompartida

6.16. Ver comentarios de una ruta compartida

  1. Click en "Compartido conmigo".

  2. Escogemos la ruta de la que queremos ver los comentarios.

  3. Click en "Comentarios".

DiagramaVerComentariosRutaCompartida

6.17. Ver galería de una ruta compartida

  1. Click en "Compartido conmigo".

  2. Escogemos la ruta de la que queremos ver la galería.

  3. Visualizamos en la galería de la ruta las imágenes.

DiagramaVerGaleriaRutaCompartida

7. Vista de implementación

7.1. Infraestructura Nivel 1

dv
Motivación

En el diagrama se representa una vista de la estructura de la aplicación que se va a proceder a realizar. En ella el usuario, en este caso el actor estaría comodamente situado en su casa y a través de un ordenador accedería a nuestra aplicacíon por medio de una interfaz. Esta aplicación estaría en la nube, y accedería a los datos del usuario a través de su POD una vez que el usuario le de permisos para hacerlo.

Características de calidad y/o rendimiento

La aplicación, al ser descentralizada tendrá tiempos de espera mayores, ya que accede a la información de estos a traves de sus PODs. Por otro lado se asegura la seguridad y la protección de los datos del usuario ante un intento de robo de datos.

Mapeo de bloques de construcción a infraestructura

La aplicación permite hacer diferentes acciones al usuario dentro de la aplicación, y usar sus datos a través de solid para formar la interfaz por la que podrá navegar.

7.2. Infraestructura Nivel 2

dwE1

Por una parte el "Actor" sube su ruta y se guarda en su POD, en esa ruta comenta el "Actor2" y el comentario se guarda en el POD de este. Es decir, los datos que suba cada usuario se guardan en su propio POD. Esto funciona de la misma forma con las fotos que pueder ser añadidas a una ruta

dwE2

Por otra parte cuando un usuario desea añadir a otro como amigo lo hara mediante su webID. Los amigos no son recíprocos y cada usuario tiene la información de sus amigos guardada en su propio POD. En este caso el usuario 1 sería amigo del usuario 2 pero no al revés.

8. Conceptos transversales

8.1. Interfaz de usuario

Los usuarios emplearán una interfaz desarrollada en JavaScript junto con React y Bootstrap a la cual se le incluirán los componentes específicos que modelen la interfaz de usuario y que permitan comunicar al usuario con los datos almacenados en su POD.

8.2. Seguridad

La seguridad se va a basar en la de la arquitectura SOLID donde cada usuario será identificado con su WebID y el mismo otorgará los permisos pertinentes sobre los datos contenidos en su POD.

8.3. Persistencia

Debido al carácter descentralizado de la aplicación, no se puede contar con una base de datos en la cual se puedan manejar todos los datos de la aplicación. Cada usuario será el único que tendrá acceso a los datos que genere.

8.4. Manejo de transacciones

Las transacciones serán asíncronas, debido al empleo de React en el cual es muy habitual este funcionamiento al basarse en JavaScript. Además de que la integración con Solid se realiza de esta manera también y es más fácil encontrar ejemplos para aplicar a nuestra arquitectura.

8.5. Manejo de sesiones

La sesión se iniciará en el momento en el que el usuario se autentifique con su cuenta en solid y en ese momento tendrá acceso a su pod, sus amigos y las rutas que posee actualmente.

8.6. Excepción y manejo de errores

Todos los datos inconsistentes que se traten de hacer circular serán interceptados por el protocolo HTTP así como los intentos de autenticación erróneos.

8.7. Comunicación e interoperabilidad

Los usuarios podrán compartir las rutas que deseen entre los distintos amigos que tengan en la solid community. También se intentará que los usuarios puedan enviar sus rutas a otros usuarios que empleen aplicaciones desarrolladas por los otros compañeros de la asignatura.

8.8. Pruebas

La aplicación dispone de casos de prueba que muestren su eficiencia. Para ello la aplicación cuenta tanto con test TDD como BDD que comprueban las funcionalidades de la aplicación y aseguran el correcto funcionamiento de la aplicación.

8.9. Modelo De Dominio

modeloDeDominioFoto

  • Persona: Usuario de la aplicación que tiene una cuenta creada en solid. Como atibutos tiene un nombre, un webId para identificarlo y una foto personalizable.

  • Ruta: Camino dibujado en un mapa distinguida con un nombre, un punto de inicio, una descripción una lista de comentarios,una lista de ficheros y una lista de hitos.

  • Hito: Punto en el mapa que forma parte de una ruta. Como atributos tiene un nombre, latitud y longitud.

  • Comentario: Nota sobre la ruta. Como atributos tiene una fecha y el texto del comentario.

  • RutaAmigo: Ruta que ha sido compartida con el usuario. Como atributos tiene una ruta y la persona que la ha compartido.

  • Notificación: Aviso de alguna interacción con el usuario (cuando le comparten una ruta). COmo atributos tiene fecha y texto.

9. Decisiones de diseño

A continuación, se detallan las diferentes decisiones de diseño/arquitectura que se han tomado para llevar a cabo la solución de los diferentes problemas con los que se ha tenido que lidiar. Se utiliza un formato de tabla, donde la primera columna contiene el nombre de la herramienta o decisión tomada, y en la segunda columna una breve descripción del motivo o para que se utiliza.

Table 7. Listado de decisiones importantes

Decisión

Descripción

Modelado de una ruta

Dentro del POD del usuario, lo que se almacena es un documento para cada ruta, que contiene su nombre, coordenadas de inicio (lat y long), descripción, una lista de hitos, cada uno con un nombre y unas coordenadas. Además también se almacenan los comentarios y fotos asociadas a dicha ruta.

Relación de amistad

Por el momento, una relación de amistad entre dos usuarios se modela sin usar una petición de amistad de por medio, simplemente se busca a un usuario por su WebID y si existe pasa a formar parte de la lista de amigos del usuario, almacenada en su POD. Sin embargo, el usuario receptor, el que es añadido como amigo, no contiene en su lista de amigos al usuario que le agregó como amigo, es decir, no es recíproca, y por ello el usuario emisor podrá compartir sus rutas con el receptor, pero no a la inversa, a menos que ambos se agreguen como amigos.

Listado de rutas

Por el momento, al entrar en la vista del listado de rutas, se cargan automáticamente todas las rutas del POD del usuario, lo que conlleva un tiempo de respuesta considerable, que se ha tratado de paliar cargando todos los datos de la ruta salvo sus comentarios, estos serán cargados una vez se haga click sobre el botón para desplegar la caja de comentarios. Las imágenes y el mapa de cada ruta se cargan de manera asincrona, aunque los mapas cargan de manera bastante rápida. Las imágenes se cargan desde el POD, y se utiliza un Spinner para mostrar al usuario la carga de las mismas. En un futuro se propone modificar esto para que solo se muestre un listado con el nombre de las rutas del usuario, y que se pueda hacer click sobre cada una de ellas para mostrar sus detalles, será entonces cuando se carguen todos estos datos desde el POD.

Compartir rutas

La funcionalidad de compartir rutas es bastante compleja, y en la versión actual del proyecto se encuentra implementada de manera bastante sencilla. El usuario dispone para cada una de sus rutas de una opción Compartir, la cual le permite seleccionar de entre sus amigos, a aquellos a los que desea compartir la ruta. El hecho de compartir una ruta se basa en compartir el enlace a dicha ruta dentro del POD del autor de la misma, de forma que cuando un usuario quiera ver aquellas rutas que le han compartido, se irá al POD del usuario que le compartió la ruta para cargar sus datos, además de los comentarios y fotos asociadas.

Adaptar componentes para que sea fácil testearlos

A la hora de testear un componente, surgen varias complicaciones debido a que contiene varias dependencias de módulos externos como puede ser el mapa de Leaflet o bien funciones de la capa de servicios, de modo que ha sido necesario llevar a cabo una refactorización del código de los componentes para que a la hora de probar su funcionamiento sea más fácil hacerlo. Un ejemplo de ello es el componente RouteCard que contiene el mapa de la ruta. Este componente dispone en su estado de una propiedad showMap que recibe de su padre a través de las props. De esta forma se puede escoger cuándo se desea mostrar o no el mapa. Así, en los tests esta propiedad tomará el valor false y no dará problemas con Leaflet. Otro ejemplo sería el caso de los componentes de la vista de rutas, cuyo padre es el componente VerRutas. Este componente es quien dispone de las instancias de los diferentes servicios, de forma que se encargará de distribuir las referencias a las funciones de los servicios entre las props de de los componentes que renderiza, de modo que se ván pasando las referencias a las funciones de un nodo a otro. Esto permite el uso de funciones Mock a través del módulo Jest, que permite probar la invocación de funciones en los componentes simulando su ejecución. Permite comprobar el valor de los parámetros en su llamada, cuantas veces fue invocada…​etc. De este modo se puede pasar a los componentes funciones "virtuales" para evitar problemas con la capa de persistencia, que requiere de tener acceso a los PODs de los usuarios loggeados.

Table 8. Listado de herramientas y módulos utilizados
Herramienta Utilidad

Solid

Cómodo para los usuarios ya que le dan permiso a las personas y a sus aplicaciones para leer o escribir en partes de su Solid POD. Por lo tanto, cada vez que abra una nueva aplicación, no tendrá que completar sus datos nunca más.

Otra ventaja es la protección de la privacidad del usuario gracias a esta herramienta.

React

Nos permite un desarrollo ágil, ordenado y con una arquitectura focalizada en componentes y fácil de mantener ya que los errores sucederán en la propia funcionalidad del componente o en la comunicación con los demás.

RDF con Turtle

Se utiliza para el modelado de datos en los PODs de los usuarios, junto con el lenguaje Turtle para su representación.

Tripledoc

Módulo que facilita la gestión de los denominados Triplets, de forma que se pueden leer y escribir datos en los PODs de los usuarios, siguiendo la especificación de SOLID.

Solid-auth-client

Módulo imprescindible para llevar a cabo todo lo relacionado con la sesión de un usuario que dispone de una cuenta de Solid. Permite a un usuario loggearse y registrarse utilizando varios provedores de PODs (por el momento solo Solid e Inrupt) o bien utilizando un servidor de solid local. También es utilizado para los layouts de la aplicación en función de si el usuario se encuentra o no loggeado, mostrando diferentes opciones en la barra de navegación superior.

React Leaflet

Módulo que permite visualizar mapas de varios tipos, y con gran variedada de Layers. En nuestro caso lo utilizamos para mostrar cada una de las rutas que se procesan en la aplicación. Hace uso de la API de Leaflet, de modo que encapsula toda la lógica del mapa en un solo componente Map muy sencillo de usar. Utilizamos métodos de esta API para dibujar una polylinea que representa los diferentes hitos de la ruta, así como una serie de marcadores que contienen un PopUp con el nombre de cada hito. Un marcador verde en el mapa simboliza el inicio de una ruta.

Solid-file-client

Junto con la API File de HTML, recibe los ficheros que desea subir el usuario, y se encarga de almacenarlos en el POD del mismo.

API File de HTML

Es la API File normal y corriente de HTML, solo que en nuestro caso se encuentra encapsulada dentro de un componente de React denominado Form.File, que permite cargar archivos desde el equipo local. Se utiliza sobre todo a la hora de publicar fotos asociadas a la ruta del usuario.

React-router-dom

Consiste en un sistema de enrutación, donde disponemos de un Router que se encarga de procesar peticiones en forma de recursos URL, por ejemplo, cuando se hace una petición del recurso "/login" se renderiza el componente correspondiente con la vista para la identificación de un usuario. Se utiliza en conjunto con el componente NavBar de React Bootstrap, que permite definir Links en una barra de navegación.

React Bootstrap

Framework de React basado en Bootstrap que proporciona gran cantidad de componentes de React personalizables para casi cualquier elemento de la interfaz de usuario. Muy útil para mostrar la información de las rutas al usuario de manera simple y flexible.

React Spinners y Loading Overlays

Se trata de componentes de React que simplemente modelan iconos de carga para mejorar la usabilidad en aquellas zonas de la aplicación donde se disminuye el tiempo de respuesta debido a operaciones pesadas, como puede ser traer información del POD del usuario cuando se cargan sus rutas, o cuando se tienen que cargar todos los comentarios de una ruta.

React Notifications

Módulo de React que permite llevar a cabo la gestión de las notificaciones de la aplicación, por ejemplo cuando nos comparten una ruta, o hacen algún comentario…​etc.

React Grid Gallery

Componente de React que modela una galería de fotos muy simple de utilizar, que recibe como propiedades una lista de imágenes, entre otras. Estas imágenes son objetos que contienen un enlace a la imagen así como a un thumbnail, dimensiones y otras caracterísitcas. Las imágenes se van disponiendo en un grid, y además se puede hacer click sobre ellas para mostrarlas en forma de carrousel.

JQuery

Esta librería basada en JavaScript se utiliza para implementar pequeños scripts de código como puede ser por ejemplo la carga dinámica de los ficheros en los Input File de HTML.

Git

Facilita el trabajo colaborativo.

Reduce considerablemente los tiempos de despliegue de un proyecto.

Permite regresar a versiones anteriores de forma sencilla y muy rápida.

Las "branches" o ramas, permiten trabajar con una base de código paralela al proyecto en sí, donde podemos corregir bugs o desarrollar nuevas características para el producto sin afectar el "master", pero manteniendo todas las ventajas de usar un sistema de control de versiones.

Empezar a trabajar desde otro entorno es tan fácil como "clonar" el proyecto a tu nuevo entorno.

Proporciona un sistema de etiquetas, para etiquetar las distintas versiones del proyecto.

Arc42

Nos proporciona una plantilla con los principales puntos para documentar la arquitectura software de nuestra aplicación web.

AsciiDoctor

Sistema de documentación dinámico y con sintaxis clara que nos permite mantener actualizada la documentación.

10. Requisitos de calidad

10.1. Árbol de calidad

qualityTreeFoto
Figure 1. Contenido
Explicación

En este arbol podemos observar los diferentes objetivos de calidad que serán usados para representar los escenarios de uso.

10.2. Escenarios de calidad

Table 9. Escenarios de uso
ID Objetivo de calidad Escenario Enfoque de la solución Riesgo

US-1

Usabilidad

Un usuario sin conocimientos previos sobre el uso de aplicaciones de rutas desea crear una ruta con 3 hitos sin tener que acceder a tuturiales. Tiempo máximo en crearla 5 minutos.

La aplicación cuenta con una interfaz de creación de rutas que permite crear estas simplemente haciendo click en el mapa para seleccionar los hitos que la forman.

Rechazo por parte del usuario de la aplicación.

US-2

Usabilidad

Un usuario daltónico intenta crear una ruta con 3 hitos con la aplicación.

Se han usado colores diferenciables en la aplicación a la vez de texto en los botones que evitan al usuario confundirse. Tiempo máximo en crearla 5 minutos.

Rechazo por parte del usuario de la aplicación.

ES-1

Escalabilidad

La aplicación pasa a tener 50 usuarios conectados a la vez.

Test de carga con la herramienta gatling que permitieron ver un correcto funcionamiento de la aplicación con esa carga de usuarios. Tiempos de carga de la aplicación menores de 1200ms.

Tiempos de carga mayores de 1200ms y por tanto inaceptable para el usuario.

EF-1

Eficiencia

Un usuario interactua con la aplicación entrando en las diferenten pantallas que esta proporciona. El usuario espera tiempos de carga asumibles al realizar cualquier operación(menos de 1 minuto).

Animaciónes entre los tiempos de carga que indiquen al usuario que la aplicación sigue funcionando. Pruebas de tiempos de reacción de la aplicación con resultados menores a un minuto. Uso de peticiones asíncronas con async / await.

Tiempos de espera demasiado largos que pueden producir el rechazo de la aplicación por parte del usuario.

PD-1

Portabilidad, Descentralización

Un usuario desea entrar en la aplicación con su POD del proveedor inrupt. Tiempo máximo de acceso 3 minutos.

Nuestra aplicación permite acceder con un WebId de este proveedor.

Rechazo por partede los usuarios que tienen su POD con este proveedor.

PD-2

Portabilidad, Descentralización

Un usuario desea entrar en la aplicación con su POD del proveedor Solid Community. Tiempo máximo de acceso 3 minutos.

Nuestra aplicación permite acceder con un WebId de este proveedor.

Rechazo por partede los usuarios que tienen su POD con este proveedor.

PD-3

Portabilidad, Descentralización

Un usuario desea entrar en la aplicación con su POD de su Servidor local. Tiempo máximo de acceso 3 minutos.

Nuestra aplicación permite acceder con un WebId de su servidor local.

Rechazo por partede los usuarios que tienen su POD en su servidor local.

MA-1

Mantenibilidad

Un programador quiere añadir una nueva funcionalidad a la aplicación para que se puedan editar las rutas.

Se ha establecido una organización en paquetes y un acceso a datos de manera que añadir esta funcionalidad no significaría modificar ninguna parte funcional de la aplicación quitando los nuevos elementos de la interfaz. Clases del backend modificadas: 1 (la clase fachada).

Estancamiento de la aplicacion ya que no se podría ampliar su funcionalidad.

IN-1

Interoperabilidad

Un usuario quiere compartir una ruta con uno de sus amigos.

La aplicación permite a los usuarios compartir sus rutas. Tiempo máximo en compartir la ruta 2 minutos.

El usuario dejará de usar la aplicación y pasará a usar otra que le permita compartir estas rutas.

IN-2

Interoperabilidad

Un usuario quiere dejar un comentario en una ruta que ha sido compartida con él.

La aplicación permite a los usuarios hacer comentarios en la rutas que han sido compartidas con él. Tiempo máximo en realizar un comentario de una frase 3 minutos.

El usuario se planteará el uso de otras aplicacíones de rutas que si permitan los comentarios.

SE-1

Seguridad

Una persona quiere suplantar la identidad de un usuario de la aplicación.

La aplicación cuenta con un sitema de login que evita acceder a cuentas de otros sin permiso. Ataques por fuerza bruta con exito: 0.

Robo de datos del usuario. Inaceptable.

DI-1

Disponibilidad

La aplicación debe estar disponible 24hx365d.

Se verificará cada minuto la disponibilidad de la aplicación, en caso de fallo se notificará al equipo técnico para reparar el problema.

No disponibilidad de la aplicación hasta que se resuelva el incidente. Tiempo máximo 5 horas.

11. Riesgos y deudas técnicas

A continuación se muestran los apartados más críticos de emplear las distintas tecnologías escogidas para la aplicación:

  • Inicialmente desconocemos todos por completo tanto la arquitectura SOLID como el framework React, con lo cual perderemos bastante tiempo en adecuarnos antes de poder trabajar de una manera ágil.

  • Todas las librerías que sean de utilidad para el manejo de SOLID también son desconocidas para nosotros y no tenemos aún definido cuales utilizaremos.

  • SOLID es un proyecto muy reciente y no se puede encontrar demasiada información de ayuda en la web para integrar este con React.

  • Los conceptos que tenemos de javaScript son básicos y hemos practicado con el lenguaje durante poco tiempo con lo cual ciertos aspectos mas específicos dedicados a SOLID son desconocidos para nosotros.

Soluciones

Las medidas que hemos adoptado ante estos problemas o carencias consisten en informarnos lo más pronto posible en todas estas tecnologías nuevas para nosotros, hemos repartido el equipo en dos grupos para poder concentrar los esfuerzos de cada grupo en el frontend y el backend. También es muy importante la realización de tutoriales para una rápida adaptación.

12. Glosario

Solid

Conjunto de especificaciones modulares que se basan y amplían la tecnología de fundación de la red mundial (HTTP, REST, HTML).

React

Biblioteca de JavaScript para construir interfaces de usuario

Leaflet

Módulo externo utilizado para la representación visual de las rutas en un mapa.

Marcador

Representa un punto o hito de una ruta en un mapa.

Polilínea

Se trata de una linea que se utiliza para definir el itinerario que sigue la ruta en un mapa.

POD

Espacio de almacenamiento personal interoperable entre las diferentes aplicaciones.

Ruta

Recorrido definido por un inicio y una serie de hitos.

Hito

Punto carácterístico que ayuda a formar una ruta.

Stakeholders

Personas u organizaciones afectadas por las actividades y las decisiones de una empresa.

DOM real

Representación de la interfaz gráfica de nuestra aplicación.

DOM virtual

Representación en memoria del DOM real que actúa de intermediario entre el estado de la aplicación.

Git

Sistema de control de versiones distribuido gratuito y de código abierto.

Arc42

Conjunto de plantillas (Creative-Commons Sharealike) para describir una arquitectura software.

API

Conjunto de definiciones y protocolos que se utiliza para desarrollar e integrar el software de las aplicaciones.

WebID

Identificador que perite a los servicios de Internet y a los usuarios saber con quién se comunican.

JSX

Extensión de JavaScript creada por Facebook para el uso con su librería React.

CRUD

Acrónimo de crear, leer, actualizar y borrar. Las cuatro funciones básicas de la persistencia de Bases de Datos.

Protocolo HTTP

Protocolo de comunicación que permite las transferencias de información en la World Wide Web.

Test TDD

Práctica de la ingeniería de software basada en escribir primero las pruebas y a continuación el código que hace que la prueba funcione.

Test BDD

Proceso del desarrollo software en el cual las pruebas están basadas en el usuario y el comportamiento del sistema.

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.