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
-
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.
-
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.
| 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
| 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
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.
3.2. Contexto tecnico
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
| 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
*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.
*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
*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
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.
-
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
-
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.
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.
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.
-
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.
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
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:
*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.
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.