1. Introduction and Goals
LoMap es el proyecto del curso actual de la asignatura Arquitectura del Software, que será desarrollado por el equipo 5A compuesto por los integrantes:
-
Ricardo Marqués Garay
-
Miguel González Navarro
-
Francisco Coya Abajo
-
Marcos Valín Fernández
-
Sergio Buenaga Gutiérrez
Y, con la ayuda del profesorado:
-
Jose Emilio Labra Gayo
-
Irene Cid Rico
Consiste en una aplicación donde los ciudadanos podrán disponer de mapas personalizados sobre lugares y negocios actuales de la ciudad.
1.1. Requirements Overview
-
El sistema permitirá a los usuarios añadir localizaciones a los mapas en diversas categorías. Además los usuarios podrán añadir comentarios, puntuaciones, etc. sobre dichas localizaciones.
-
El sistema permitirá a los usuarios mostrar localizaciones en una ventana de tipo mapa
-
El sistema gestionará la información almacenada sobre una localización por cada usuario de forma descentralizada. Se pueden dar excepciones por rendimiento siempre que se respete la privacidad de los usuarios.
-
El sistema permitirá a los usuarios gestionar la información que comparten con otros usuarios. Y, siempre que lo permitan, acceder a localizaciones e información relativa a ellas compartida por sus amigos.
-
El sistema permitirá a los usuarios emplear filtros a la hora de visualizar el mapa.
Se puede consultar el siguiente documento, que contiene una descripción de la aplicación a desarrollar, así como una lista de requisitos funcionales más detallada:
1.2. Quality Goals
Segun ISO/IEC 25010
| Objetivo de Calidad | Motivación | Prioridad |
|---|---|---|
Usabilidad |
Para que el producto sea consumible por los usuarios finales, ha de tener un diseño moderno y minimalista, centrado en un público de edades diversas. Para ello, tiene que ser intuitivo y fácil de usar |
3 |
Seguridad |
Desarrollar aplicaciones 100% seguras a día de hoy es imposible, pero ello no quiere decir que sea posible implementar medidas de protección ante ataques comunmente conocidos. La descentralización del sistema, contribuye a un incremento de la seguridad. Además, implementar medidas tanto para el lado cliente como para el servidor |
4 |
Privacidad |
Lo primero es la privacidad de los usuarios. Por ello, la gestión de mapas mediante el uso de SOLID, almacenando los datos en un sistema distribuido. Cada usuario tendrá un POD personal, no visible a otros usuarios |
5 |
Testabilidad |
Se implementarán pruebas unitarias en la aplicación para asegurar el correcto funcionamiento del sistema. |
4 |
1.3. Stakeholders
| Rol | Descripción | Expectativas |
|---|---|---|
Cliente |
Empresa que nos contrata, ficticia (HappySw), representada por los profesores de la asignatura |
Que la aplicación desarrollada cumpla con los requisitos mencionados en el apartado 1.1 |
Equipo de desarrollo |
Ricardo Marqués, Miguel González, Francisco Coya, Marcos Valín y Sergio Buenaga |
Desarrollar la aplicación con éxito en base a la documentación, de forma que refleje los conocimientos de arquitectura adquiridos durante el curso |
Usuarios |
El conjunto de personas que van a utilizar el producto final desarrollado |
Que la aplicación funcione correctamente y que cumpla, implícitamente, con los objetivos de calidad |
Ayuntamiento de Bruselas |
Organismo público que contrata al Cliente |
Mismas expectativas que nuestro Cliente (HappySw) |
2. Architecture Constraints
2.1. Technical constraints
| Restricción | Descripción |
|---|---|
SOLID |
Haremos uso de las especificaciones SOLID de forma que la información de los usuarios no esté centralizada y el uso de la aplicación sea más seguro. Para nuestro caso se ha decidido utilizar el proovedor INRUPT. |
TypeScript |
El lenguaje de programación que se empleará para realizar la aplicación será TypeScript. |
React JS |
Se empleará React JS para realizar la parte de front end de la aplicación. ReactJS ofrece gestión de estados, hooks (con posibilidad de personalización), pero obtamos por el uso de la librería Zustand. |
Librerías externas |
Para facilitar el trabajo y poder llegar a los plazos de entrega, se tiene el riesgo de utilizar librerías que realicen ciertas funcionalidades con el riesgo que conlleva. En principio el uso de estas librerias facilitarán el desarrollo del proyecto pero si algun modulo de dependencias falla podria ocasionar daños en nuestra aplicación. |
Node JS |
Para el back end se utilizará Node JS. |
Firebase Cloud Storage |
Con el objetivo de que la aplicación pueda mostrar imágenes de las ubicaciones, se utilizará el servicio Firebase Cloud Storage para almacenar el contenido multimedia. |
GitHub |
GitHub será el controlador de versiones que emplearemos durante el proceso de desarrollo. |
Jest |
Con el fin de poder probar la funcionalidad de la aplicación se utilizará la librería de pruebas Jest. |
React Leaflet |
Para poder implementar la funcionalidad del mapa se hará uso de la librería React Leaflet. |
2.2. Organizational Constraints
| Restricción | Descripción |
|---|---|
Equipo |
El proyecto se llevará a cabo mediante un equipo de 5 personas. Los integrantes son Ricardo Marqués Garay, Miguel González Navarro, Francisco Coya Abajo, Marcos Valín Fernández y Sergio Buenaga Gutiérrez |
Reuniones |
El equipo deberá reunirse periodicamente de forma obligatoria. |
Fechas límites de las entregas |
Las distintas versiones del proyecto deberán entregarse antes de la fecha límite para cada una de ellas. Estas fechas las dictaminarán los profesores de la asignatura. |
Organización del proyecto |
Para llevar un orden establecido, se ha optado por realizar una estructura guiada por paquetes separados por su distinta funcionalidad. |
Experiencia |
La Experiencia de los miembros del equipo es variada y por ello el ritmo de desarrollo sera flexible. |
Tiempo de trabajo |
Las horas de trabajo que se dediquen al desarrollo, documentación o investigación seran cruciales para menantener el proyecto al orden del día. |
Distribucion de tareas |
Tras las reuniones los integrantes del proyecto se repartirán las tareas a realizar. Principalmente se destaca el equipo de backend y el equipo de frontend. |
2.3. Conventions
| Restricción | Descripción |
|---|---|
Arc42 |
Para llevar a cabo la documentación del proyecto se utilizará el modelo Arc42. |
Idioma |
La documentación estará redactada en español. |
W3C standars |
Se utilizara las convenciones de W3C para la usabilidad de la aplicación. |
3. System Scope and Context
3.1. Business Context
3.2. Technical Context
4. Solution Strategy
4.1. Technology decisions
| Tecnología | Descripción |
|---|---|
Git |
Sistema de control de versiones de software. |
GitHub |
Servicio basado en la nube que aloja al sistema de control de versiones antes mencionado, Git. |
Solid |
Especificación que permite almacenar datos de forma segura en almacenes descentralizados de datos denominados Pods. |
Node.js |
Entorno de ejecución para JavaScript empleado para desarrollar aplicaciones escalables del lado del servidor. |
Express |
Framework para la construcción de aplicaciones web en Node.js. |
TypeScript |
Lenguaje de programación construido a un nivel superior de JavaScript que ofrece una mayor seguridad, escalabilidad y limpieza en el código. |
React |
Biblioteca de JavaScript que nos permite creear interfaces de usuario interactivas de manera sencilla. Se basa en componentes. |
Leaflet |
Biblioteca de mapas, open-source y basada en OpenStreetMaps. |
Docker |
Docker es una herramienta que facilita la creación, implementación y ejecución de aplicaciones mediante el uso de contenedores. Los contenedores permiten empaquetar una aplicación con todas las partes que necesita, como bibliotecas y otras dependencias, y desplegarla como un solo paquete. |
Firebase Cloud Storage |
Servicio empleado para almacenar contenido generado por los usuarios, por ejemplo, imágenes y vídeos. |
Jest |
Framework de pruebas para JavaScript. |
Puppeteer |
Herramienta de automatización de pruebas para navegadores web desarrollada por Google. Permite controlar el navegador a través de una API. |
Cucumber |
Herramienta de automatización de pruebas de software empleada para realizar pruebas a partir de los criterios de aceptación. A través de Cucumber, se pueden definir un conjunto de casos de uso que permiten validar el desarrollo realizado. |
4.2. Decisions on how to achieve quality goals
-
Usabilidad: el equipo se preocupará de diseñar una interfaz clara y accesible para cualquier usuario. Para ello nos basaremos en los estándares de usabilidad en la web.
-
Privacidad: la información privada del usuario se almacenará en pods de SOLID, manteniéndola, de este modo, descentralizada. Sólo se almacenará en una base de datos centralizada lo estrictamente necesario.
-
Seguridad: nos preocuparemos de implementar todas las medidas que consideremos oportunas para securizar nuestra aplicación. Además, el mantener la información personal de los usuarios descentralizada constituye un gran paso en el proceso.
-
Testabilidad: es un objetivo de calidad importante para garantizar que el software sea confiable, robusto y libre de errores. Es importante implementar prácticas de desarrollo de software adecuadas, como la separación de preocupaciones y el diseño modular.
4.3. Relevant organizational decisions
En cuanto a la organización dentro del equipo, hemos tomado las siguientes decisiones:
-
Las reuniones extraordinarias, las hacemos a través de Discord, por estar todos los miembros del equipo familiarizados con dicha herramienta.
-
La comunicación entre los miembros del equipo se produce, principalmente, a través de un grupo de WhatsApp, pero cualquier problema que surja también se refleja como una issue en Github.
-
Empleamos un tablero Kanban dentro de github para tener bien organizadas y de forma muy clara las tareas que tiene que realizar/está realizando cada miembro del equipo.
5. Building Block View
5.1. Level 0: Whitebox of the Overall System
- Motivation
-
LoMap es la estructura principal de un sistema en el que el usuario interactúa con su mapa, personalizándolo con los lugares que le interesan. Además, el usuario puede añadir a sus amigos a la aplicación y compartir con ellos sus marcadores. La información personal del usuario se almacena de forma descentralizada en PODs.
- Contained Building Blocks
| Nombre | Responsabildad |
|---|---|
Usuario |
Interactúa con la aplicación. |
LoMap |
Sistema con el que interactúa el usuario. Se comunica con el proveedor de PODs para obtener/almacenar información del usuario. |
POD |
Proveedor encargado de almacenar la información de cada usuario en un POD de forma descentralizada. |
5.2. Level 1
- Motivation
-
Muestra como funcionan los distintos componentes de LoMap, a grandes rasgos.
- Contained Building Blocks
| Nombre | Responsabildad |
|---|---|
WebApp |
Parte del sistema con la que interactúa el usuario (Frontend). Además, es la parte encargada de comunicarse con los pods de los usuarios. |
5.3. Level 2
- Motivation
-
Muestra como funcionan los distintos componentes de LoMap, con mas detalle que el nivel anterior. Se profundiza en los distintos componentes de la aplicación que forman parte de WebApp.
- Contained Building Blocks
| Nombre | Responsabildad |
|---|---|
LoginPage |
Parte del sistema encargada de redirigir al usuario al proveedor Solid seleccionado para llevar a cabo su autenticación. |
HomePage |
Muestra un mapa en el que se sitúan los puntos almacenados del usuario, así como los compartidos por sus amigos, si así lo desea. Permite filtrar los puntos a mostrar por su categoría. Además, permite acceder a cualquier parte de la aplicación. |
CreatePointPage |
Permite al usuario en sesión crear un nuevo punto y compartirlo con sus amigos, si así lo desea. |
AboutPage |
Muestra al usuario de la aplicación información acerca de ésta. |
SavedPointsPage |
Permite al usuario interactuar con los puntos que ha decidido guardar. |
SinglePointDetailsPage |
Permite al usuario ver en detalle toda la información almacenada acerca de un punto dado. También permite ver en detalle toda la información de puntos que les han compartido sus amigos. |
6. Runtime View
6.1. Runtime Level 1
6.1.1. Inicio de sesión
El inicio de sesión de la aplicación se gestiona a través del proveedor de SOLID Inrupt, que se encarga de almacenar las credenciales e información privada del usuario. El usuario se comunica con el sistema Lomap y accede a su POD personal. Al introducir el webId en el formulario, se redirecciona al proveedor Inrupt para su autenticación y, si los datos son verídicos, se redirecciona a lomap, mostrando en una vista de la aplicación el mapa con los puntos de interés añadidos (y que el usuario en sesión tenga permiso para ver).
6.1.2. Listado de puntos de interés de un usuario
Los puntos de interés se almacenan en el pod personal de cada usuario. El sistema lomap se encarga de recuperar los datos del pod personal del usuario y mostrarlos en la vista correspondiente. El usuario puede interactuar con la vista y acceder a la información de cada punto de interés.
6.1.3. Añadir un punto de interés al mapa
Para añadir un punto de interés al mapa, el usuario tendrá varias opciones. A continuación, se explicará la opción más "compleja". El usuario interactúa dentro de su vista privada y accede a una opción que le redirecciona a una vista específica para añadir un nuevo punto al mapa. La vista de añadir nuevo punto contiene un formulario, a través del cual se envían los datos al sistema lomap, que se encarga de comunicar con el pod personal del usuario y actualizar la interfaz de usuario.
6.2. Runtime Level 2
6.2.1. Inicio de sesión
Para iniciar sesión, el usuario introducirá su webId en el formulario. El proveedor de PODs recibe el webId y procesa la petición. Redirecciona a la página privada del usuario y, a su vez, los datos del POD de éste. Si se produce un error al realizar la petición, se mostrará un error en el formulario de la página de inicio de sesión. En caso de producirse un error en el proveedor (Por otros motivos inherentes a él), se gestionará el error redireccionando de nuevo al formulario.
6.2.2. Listado de puntos de un usuario
El listado de puntos de interés de un usuario se obtiene del pod del usuario. Sin embargo, el sistema lomap se encarga de gestionar la petición y mostrar los datos en la vista correspondiente. El usuario puede interactuar con la vista y acceder a la información de cada punto de interés. El fichero JSON devuelto por el POD tiene que ser procesado para mostrar los datos en la vista.
6.2.3. Añadir un punto de interés en el mapa
Para añadir un punto de interés en el mapa se contemplan varias opciones. El siguiente diagrama representa el escenario de añadir un punto de interés desde la vista privada del usuario (Dashboard).
6.3. Runtime Level 3
6.3.1. Inicio de sesión
6.3.2. Listado de puntos de interés de un usuario
6.3.3. Añadir un punto de interés en el mapa
7. Deployment View
7.1. Infrastructure Level 1
- Motivation
-
La aplicación consta de dos partes claramente diferenciadas y separadas, que son lado cliente y lado servidor. En este primer nivel se puede apreciar una arquitectura cliente-servidor, donde el lado del cliente realiza y recibe peticiones HTTP (Mediante dicho protocolo) al lado del servidor, que lo forma una API Rest, la cual realiza consultas contra una base de datos no relacional documental (NoSQL) de MongoDB
- Mapping of Building Blocks to Infrastructure
| Nodo | Descripción |
|---|---|
webapp |
Nodo que engloba el Front-End de la aplicación, ofreciendo una interfaz de usuario y comunicándose con la api rest para obtener y mostrar los resultados. |
Proveedor SOLID |
Nodo que representa al proveedor de PODS de SOLID de la empresa Inrupt. Almacenará los PODS personales de los usuario, donde se guardará información privada. |
Firebase |
Entorno que ofrece un servicio de almacenamiento de recursos multimedia, utilizado para almacenar las imágenes de la aplicación (Véase avatares o imágenes referentes al punto de interés). El servicio se denomina "Firebase Cloud Storage". |
7.2. Infrastructure Level 2
- Mapping of Building Blocks to Infrastructure
| Nodo | Descripción |
|---|---|
GitHub |
Servicio de control de versiones, donde se almacena el código fuente de la aplicación. |
GitHub Pages |
Servicio de hosting de GitHub, donde se almacena el código compilado de la aplicación. |
Leaftlet |
API Open Source para integración de mapas en el lado del cliente. Proporciona componentes para React. |
Servidor Inrupt |
Servicio descentralizado para almacenas los PODS de los usuarios que se registren en él. Cada POD contiene información única de cada usuario. |
Firebase |
Entorno que ofrece un servicio de almacenamiento de recursos multimedia, utilizado para almacenar las imágenes de la aplicación (Véase avatares o imágenes referentes al punto de interés). El servicio se denomina "Firebase Cloud Storage". |
webapp |
Nodo que engloba el Front-End de la aplicación, ofreciendo una interfaz de usuario y comunicándose con la api rest para obtener y mostrar los resultados. |
Dispositivo electrónico |
Cualquier dispositivo con acceso a internet, que se conecte al servidor web. Este puede ser un smartphone, tableta, ordenador, consola, etc. |
8. Cross-cutting Concepts
8.1. Domain model
8.2. Usability
Usaremos react con Typescript. React es un framework que facilita mucho la interactividad con la interfaz de usuario, por lo que es importante para llegar a los usuarios
8.3. Security
La seguridad de la aplicación es una parte muy importante. Para que cada persona tenga el control de su información y puedan gestionarla, tendrán cada uno un POD propio.
8.4. Privacity
El sistema debe mantendrá la privacidad del usuario. Atendiendo a las características de los principios SOLID, toda la información del usuario será almacenada el su propio POD, por lo que no tendrá ninguna vulnerabilidad por tener datos almacenados en una base de datos.
8.5. Testability
Para el correcto funcionamiento de la aplicacion, para checkear el funcionamiento de los componentes. Es importante unos test para que el usuario tenga la mejor experiencia posible.
9. Design decisions
9.1. Accepted decisions
Estas son las decisiones que en grupo hemos tomado para nuestra aplicación:
| Decision arquitectonica | Ventajas | Desventajas | Enlace al ADR |
|---|---|---|---|
TypeScript |
Resuelve uno de los grandes problemas de JavaScript, el enlace dinámico. |
Ninguno de nosotros hemos usado nunca, y debemos aprender. |
|
React js |
Actualiza componentes y vistas en tiempo real, permite modularizar la interfaz de usuario en componentes. |
Documentación muy escueta, dificultando el aprendizaje. |
|
SOLID |
Organiza de forma descentralizada |
Dificil de utilizar |
|
NodeJS |
Se integra con solid, contiene muchas librerias probadas y verificadas, creación de APIs mas sencilla. |
Monohilo, la integración de asincronía puede hacer el codigo inmantenible. |
|
React Leflet |
Calidad-coste superior a las demás. |
Nunca hemos trabajado con el. |
|
Styled Components |
Facilita enormemente el trabajo, altamente probados y validados por la comunidad. |
Se depende del mantenimiento de y licencia de uso de esta libreria. |
|
Github pages |
Es la tecnología utilizada para el control de versiones, y es posible integrarlo de una forma relativamente fácil |
Solo admite una instancia por repositorio, y actualmente la documentación técnica de la aplicación está desplegada en este servicio |
|
Firebase Cloud Storage |
Gran velocidad de desarrollo, y no necesidad de servidor |
Principiantes con ella |
|
Visual Studio Code |
Muy facil de usar, experiencia con el, y disponible en muchos sistemas operativos. |
Necesidad de instalar muchos pluggins. |
|
Test unitarios |
Buena documentación y recursos, paralización de test y facil configuración. |
No tenemos conocimiento con esta libreria |
|
Cucumber |
Lenguaje natural, Reutilización de código, Inntegración |
Puede ser difícil de aprender, requiere conocimientos de programación y una comprensión de los conceptos de pruebas. |
|
Puppeter |
Control completo del navegador Chrome, fácil de usar, integración con otras herramientas |
Consumo de recursos del sistema, dependencia de la versión del navegador |
|
Zustand |
Ofrece mayor rendimiento por la sencillez de su implementación |
No sigue un patrón, la estructura es libre para el desarrollador |
10. Quality Requirements
10.1. Quality Tree
10.2. Quality Scenarios
| Número | Atributo de calidad | Escenario de calidad | Prioridad | Complejidad de implementación |
|---|---|---|---|---|
1 |
Usabilidad |
Queremos ofrecer al usuario la posibilidad de filtrar puntos del mapa por amigos, además de un servicio de acceso a información y almacenamiento de datos, en un sistema intuitivo y eficaz para los clientes (lo más rápido posible) |
Alta |
Media |
2 |
Seguridad |
Garantizaremos la mayor seguridad posible, guardando la información sensible del usuario de forma segura e intentando prevenir cualquier tipo de ataque o riesgo. Securizar la api rest protegiendo determinadas rutas también será otro objetivo para llevar a cabo |
Alta |
Alta |
3 |
Privacidad |
Vamos a respetar la privacidad de los usuarios, los datos del usuario estarán protegidos en todo momento. El objetivo es minimizar la cantidad de datos que tome nuestra aplicación, siempre teniendo en cuenta una entrega descentralizada |
Media |
Media |
4 |
Testabilidad |
La aplicacion sera sometida a pruebas unitarias, de aceptación y de carga, para probar que funcione correctamente. Si se da el caso de que se añaden nuevas funcionalidades al mapa, se deberá poder probar exhaustivamente antes del despliegue |
Alta |
Media |
11. Risks and Technical Debts
11.1. Risks
| Riesgo | Explicación | Solución |
|---|---|---|
Tiempo |
Vamos a estar continuamente condicionados por el tiempo para entregar el proyecto |
Debemos de trabajar en equipo y trabajar lo más eficiente posible para no perjudicarnos a lo largo del tiempo, evitando cualquier conflicto innecesario |
Github |
No hemos trabajado tan a fondo con GitHub, tenemos una base pequeña sobre lo básico |
Aprender e investigar lo máximo posible, además de hacer pruebas propias (como pull Request, issues, commits…) |
Nuevas tecnologías |
Para la mayoría del grupo la falta de conocimiento de tecnologías como React, Node.js o Solid; supondrá un extra añadido a la dificultad del desarrollo de la aplicación |
Utilizaremos la documentación de cada una, donde podemos encontrar numerosos ejemplos de como empezar,para desenvolvernos y ganar agilidad a corto plazo |
Comunicación del equipo |
La comunicación no es inmediata y mucho menos de todos los miembros del grupo al mismo tiempo, cada miembro tiene unos horarios y asignaturas diferentes, luego será un factor añadido en contra para nosotros |
Los miembros del equipo deberán hacer un esfuerzo colectivo para colaborar entre todos, facilitando las opciones tanto del horario de cada uno como la disponibilidad, por ello las reuniones en Microsoft Teams agilizarán el proceso ya que nos permite reunirnos virtualmente |
Posible abandono de algún miembro del grupo |
Uno o varios miembros podrían abandonar la asignatura debido a la carga de trabajo acumulada a lo largo del semestre |
Intentaremos aliviar la situación reforzando el trabajo en grupo y el apoyo extra en las tareas, en especial a aquellas que son críticas para el proyecto |
11.2. Technical Debts
| Deuda técnica | Explicación |
|---|---|
Usabilidad |
Nos gustaría que la usabilidad fuera uno de nuestros puntos fuertes, logrando que personas reales puedan probar nuestra aplicación, y realizar el número máximo de pruebas posibles |
Código limpio para el desarrollo ágil del software |
El código debe ser claro y refactorizado, sobre todo en la parte del backend; y también el frontend, para hacerlo más conciso y modificable. |
Investigación |
Una búsqueda amplica de información acerca de cómo trabajar con Typescript, React y Solid facilitará el trabajo una vez iniciado el proyecto. Solo hemos utilizado JavaScript, nunca Typescript, luego supondrá un periodo de adaptación a dicha tecnología |
Toma de decisiones |
Es importante decidir con cabeza y con un buen razonamiento la arquitectura del proyecto, hay que evitar improvisar en todo momento, ya que puede afectar negativamente al proyecto en gran medida |
El desconocimiento inicial por parte de la mayoría de los miembros del grupo supondrá una deuda técnica, trataremos de colaborar el máximo y reforzar los conocimientos de manera progresiva, con el objetivo de ganar estabilidad y constancia a lo largo del proyecto.
12. Glossary
| Término | Definición |
|---|---|
Arc42 |
Plantilla para la documentación de la arquitectura del sistema. |
Azure |
Servicio de nube que ofrece, entre otros muchos, servicios de virtualización para máquinas. Se utiliza para desplegar aplicaciones y servicios en servidores remotos (Propietarios de Microsoft). |
Commit |
Consiste en confirmar un conjunto de cambios provisionales de forma permanente. Los utilizaremos para poder medir el trabajo de cada uno en el proyecto. |
Docker |
Herramienta de código abierto (Open Source) que permite gestionar contenedores. Se ejecuta bajo un entorno virtualizado y contiene todas las librerías y dependencias del proyecto que lo integra, evitando la instalación y gestión de dichas herramientas en un entorno local. |
Discord |
Servicio de mensajería instantánea y chat de voz VolP, donde nos comunicaremos en las reuniones extraordinarias de manera virtual- Este servicio cuenta con la posibilidad de compartir el escritorio de cada uno de los miembros a la vez, lo cuál facilitará la resolución de dudas y conceptos |
Github |
Plataforma donde se alojará el proyecto, con sus distintas ramas de desarrollador (tanto para el código como para la documentación) |
Issue |
Es una nota en un repositorio que trata de llamar la atención sobre un problema o un tema. Puede ser un error a corregir, una petición para añadir una nueva opción o característica, una pregunta para aclarar algún tema que no está correctamente aclarado o muchas otras cosas diferentes. Se utilizará para contar las tareas que se van desarrollando y quién las realiza |
ReactJS |
Marco de trabajo (framework) basado en JavaScript para crear aplicaciones web en el entorno cliente. Permite crear aplicaciones web reactivas a cambios (en tiempo real) y se organiza en componentes. Entre sus características principales, destaca la incorporación de un DOM virtual, que es una copia del árbol DOM pero dinámico, sin afectar directamente al árbol DOM original. |
Pod |
Referente al proyecto SOLID, es un mecanismo de almacenamiento distribuido que almacena la información de un usuario de forma privada y segura. Se puede comunicar con otros PODS. Se identifica mediante una URL. |
Pull request |
Es la acción de validar un código que se va a mergear de una rama a otra, una petición para que el propietario del repositorio original incorpore los commits que están en la rama |
WebId |
Referente al proyecto SOLID, es un identificador que representa de manera única a un usuario. |
Test |
Pruebas empiricas cuyo objetivo es proporcionar informacion sobre la calidad del producto |
Usabilidad |
Medida en la cual un producto puede ser usado por usuarios con efectividad. |
13. Appendices
13.1. Appendix A
Prototipos de las vistas de la aplicación realizados en Figma.
13.1.1. Página de inicio de sesión
13.1.2. Página de inicio
13.1.3. Página de añadir un nuevo punto
13.1.4. Página de puntos guardados
El diseño es genérico para todas las vistas de la cuenta del usuario (Puntos guardados, perfil del usuario, etc.)
13.1.5. Página de detalle de un punto de interés
13.1.6. Página de acerca de
13.2. Appendix B
Prototipos de componentes de la aplicación realizados en Figma.
13.2.1. Popup de filtros de categoria y amigos
Mostrado en la página de inicio.
Vista I
Vista II
13.2.2. Popup de añadir una valoración a un punto
Mostrado en la página de detalle de un punto de interés.
13.3. Appendix C
Paleta de colores de la aplicación original.
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.