1. Introducción y Objetivos
LoMap es un proyecto de ASW que consiste en la creacion de un sistema en el que los ciudadanos dispongan de un mapa personalizado con lugares, negocios y otros sitios de interés de la ciudad de Bruselas. Lo interesante de LoMap son las amplias posibilidades que te ofrece como usuario, desde añadir marcadores con puntos de interés y valorarlos, hasta poder visualizar los mapas de diferentes amigos. Los miembros son:
-
Ruben Diaz Zapico - UO283204
-
Alonso Antuña Gómez-UO282834
-
Javier Novella Tomás-UO282944
-
Sergio Moro Muñiz - UO284622
-
Pablo Fernandez Diaz-UO271116
1.1. Resumen de Requisitos
La aplicación se ejecutará en el servidor, y la información del usuario se almacenará en su pod. Asi mismo, no habra una base de datos centralizada ya que todos los datos se almacenan en los pod. Todos estos requisitos son compatibles con el proyecto SOLID, ya que la información de los usuarios no se almacena de forma centralizada.
-
Los usuarios pueden añadir lugares en categorías diferentes: tiendas, bares, restaurantes, paisajes, monumentos, etc.
-
Los usuarios serán capaces de mostrar lugares en una ventana tipo mapa.
-
Los usuarios pueden asociar puntuaciones, comentarios, fotos, etc. sobre los lugares añadidos.
-
Se podrán gestionar desde la aplicación los accesos a la información que comparten con otros usuarios, como sus amigos o grupos de amigos.
-
La información sobre un lugar almacenada por cada usuario no deberá estar centralizada, sino que se almacenará en el pod de cada usuario.
-
Si fuese necesario, se podría almacenar alguna información de forma centralizada por razones de rendimiento tratando de respetar la privacidad de los usuarios en la medida que sea posible.
-
El sistema permitirá a los usuarios ver lugares e información sobre dichos lugares tomada de sus amigos.
-
El sistema permitirá visualizar el mapa incorporando filtros, por ejemplo, por categoría, amigos, etc.
1.2. Objetivos de calidad
| Objetivos de calidad | Motivación | Importancia |
|---|---|---|
Seguridad |
Garantizar la seguridad de los datos del cliente para aumentar su confianza y mantener a salvo su privacidad |
Alta |
Robustez |
Buen manejo de excepciones para mejorar la experiencia del usuario |
Alta |
Usabilidad |
La aplicación ha de ser intuitiva y de fácil manejo para gente de todo tipo de nivel |
Alta |
Transparencia |
Todo el proyecto sera visible |
Bajo |
Eficiencia |
La aplicación sera lo más eficiente posible usando los menores recursos posibles |
Media |
-
Permitir a los usuarios crear rutas (por ejemplo, rutas para hacer compras o tomar algo)
-
Permitir a los usuarios comparar mapas, por ejemplo, comparar ciertas categorías como sólo restaurantes.
-
Permitir a los establecimientos (restaurantes, tiendas, bares, etc. ) crear su propio pod para que otras personas puedan conectarse a ellos.
-
Crear un boletín de noticias (newsfeed) a partir de los lugares conectados.
-
Añadir características de gamificación (recoger información de lugares, descubrir nuevos lugares, etc. )
-
Crear múltiples mapas entre grupos de usuarios (por ejemplo, mapas de familia, de compañeros de viaje, …)
-
Conectar con el libro de direcciones para chequear información sobre lugares o realizar recomendaciones de lugares
-
Añadir roles (ciudadano, turista, dueño de negocio,…)
-
Oportunidades para dueños de negocios, por ejemplo, crear un mapa con lugares recomendados cerca de un establecimiento, bares para tomar algo después de realizar la compra, etc.
1.3. Stakeholders
| Role/Name | Contact | Expectations |
|---|---|---|
Profesores |
-Jose Emilio Labra -Cristian Augusto Alonso -Irene Cid Rico -Pablo González |
Puesta en practica de los conocimientos y explicaciones realizadas en clase para la realización del proyecto |
Clientes |
Clientes |
Aplicación web sencilla, con una buena usabilidad, con todas las funcionalidades requeridas y que protega/asegure los datos introducidos |
Administrador |
Administrador |
Manejar una aplicación robusta, útil, esteticamente atractiva y eficiente, además de ser mantenible con el tiempo. |
Equipo |
-Javier Novella Tomás -Ruben Díaz Zapico -Pablo Fernádez Díaz -Sergio Moro Muñiz -Alonso Antuña Gómez |
Mejorar la técnica de trabajo y cooperación en un equipo de desarrollo |
2. Arquitectura
Usamos el MVC(modelo vista-controlador). MVC es un patrón de arquitectura de software que separa una aplicación en tres componentes: Modelo, Vista y Controlador. El Modelo maneja los datos y la lógica de negocio, la Vista se encarga de la presentación de la información al usuario, y el Controlador actúa como intermediario entre los dos, gestionando las interacciones del usuario y actualizando el Modelo y la Vista según sea necesario.
2.1. Explicación sobre la Pila Tecnológica
React |
Usamos React para el front-end, para la interfaz gráfica de usuario. |
SOLID |
Con SOLID,este es un requisito sobre las tecnologías que usar, los usuarios guardaran su información usando PODs. De esta forma, pueden permitir o rechazar la solicitud de acceso a los datos. |
GitHub |
Usaremos github para el control de versiones y comunicarnos. |
TypeScrypt |
TypeScript para escribir el back-end, TS es una evolución de javascript con tipos. |
2.2. Organización del equipo
Organización |
Explicación |
Reuniones |
Es la primera vez que trabajamos juntos en un proyecto de estas dimensiones, tanto por complejidad en el software como por sus tecnologías. Somos un equipo de 5 personas y hemos seguido una metodología ágil. |
Tiempo |
Tiene un tiempo de entrega corto, ya que el desarrollo completo debe hacerse en unos 4 meses. |
Fechas Límite |
Dependiendo el mes y la semana, debemos ir entregando versiones del producto final, hasta que la entrega final llegue. |
2.3. Puntos a tener en cuenta
Estetica y uso |
La interfaz gráfica debe ser facil de usar, ademas de tener un alto grado de accesibilidad y usabilidad. |
Documentación |
Usamos Arc42 para la documentación. |
TypeScript |
Usamos los lenguajes TypeScript/JavaScript y alguno de sus frameworks. |
MVC |
Usaremos el modelo vista-controlador. |
W3C AAA |
Nuestra aplicación seguira el convenio del W3C triple AAA, es decir, será tanto accesible como usable para cualquier tipo de público. |
3. Alcance y contexto del sistema
3.1. Contexto empresarial
El objetivo del proyecto es desarrollar un sistema de software llamado “LoMap” donde los ciudadanos puedan tener mapas personalizados sobre lugares y negocios locales en su ciudad. Por otro lado, en esta aplicación los usuarios pueden agregar ubicaciones en diferentes categorías como:
-
Tiendas
-
Barras
-
Restaurantes
-
Lugares de interés
-
Monumentos Los usuarios también pueden agregar puntajes de revisión, comentarios, imágenes, etc. sobre los lugares agregados.
Nustra app es una red social con la infraestructura "dispersa" en pods que pertenecen al usuario(uno por usuario) en vez de una base de datos centralizada en los servidores de la empresa se sigue teniendo una base de datos central pero solo se usa para guardar informacion basica del usuario tambien la app hara uso de apis externas
3.2. Contexto técnico
Nuestra aplicación LoMap sigue los principios de descentralización de datos personales SOLID al almacenar datos personales en el POD independiente de cada usuario. El front-end se desarrolla utilizando el framework React, el cual implementa componentes propios diseñados o creados, el lenguaje utilizado para desarrollar diversas funciones en pantalla es TypeScript. No usamos nada de Back-End ya que el Front-End se comunica directamente con los PODs de inrupt.
| Tecnología | Descripción |
|---|---|
SOLID |
Principios de descentralización de la aplicación. |
PODs |
Para guardar los datos de los usuarios. |
TYPESCRIPT |
Lenguaje principal de la aplicación. |
REACT |
Framework usado para el Front-End. |
Mapbox |
Api que usamos para los mapas. |
4. Soluciones Estratégicas
Para la realización de LoMap hemos tomado la decisión de desarrollarlo en TypeScript, usando el framework React y el proovedor de pods de inrupt. TypeScript es un superconjunto de JavaScript cuyo punto más resaltable es el uso de tipado.
-
Pods Solid: para mejorar la seguridad y privacidad de los datos de los usuarios, se ha impuesto como una condición necesaria el uso de los pods (no una base de datos centralizada). Los pods almacenan independientemente la información de cada usuario.
-
React: Framework de código abierto concebida para crear interfaces de usuario. Hemos elegido React por su sencillez y las númerosas posibilidades que proporciona, entre ellas desarrollar aplicaciones web multiplataforma.
-
Docker: es un proyecto de código abierto que automatiza el despliegue de aplicaciones dentro de contenedores de software, proporcionando una capa adicional de abstracción.
-
Seguridad y privacidad: se mejorará la seguridad del usuario debido a que sus datos serán almacenados de forma descentralizada en los PODs.
-
Diseño: vamos a utilizar el MVC (Modelo Vista Controlador)para facilitar el desarrollo, la limpieza de código y la organización del mismo.
-
Desarrollo y reparto: Dividimos el trabajo por partes de la aplicación. Por ejemplo 2 integrantes del equipo se encargan del login, otros 2 del mapa y asi hasta cubrir todos los componentes de la aplicación.
-
Usabilidad-Accesibilidad: intentaremos hacer la aplicación lo más accesible posible para facilitar en la medida de lo posible el uso de la aplicación para personas con alguna discapacidad.
5. Vista de bloque de creación
5.1. Nivel 0: Vista general del sistema
- Motivación
-
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.
- Bloques de construcción contenidos
| 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. |
inrupt.net/solidcommunity.net |
Sistema encargado de almacenar la información de cada usuario en un POD de forma descentralizada. |
5.2. Nivel 1
- Motivación
-
Muestra como funcionan los distintos componentes de LoMap, a grandes rasgos.
- Bloques de construcción contenidos
| 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. Nivel 2
- Motivación
-
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.
- Bloques de construcción contenidos
| Nombre | Responsabildad |
|---|---|
Log in |
Parte del sistema encargada de redirigir al usuario al proveedor Solid seleccionado para llevar a cabo su autenticación. |
Mapa |
Muestra un mapa en el que se sitúan los puntos almacenados del usuario. Permite filtrar los puntos a mostrar por su categoría. |
About Us |
Permite al usuario ver los desarrolladores de la aplicación. |
Amigos |
Permite al usuario llevar a cabo la gestión de sus amigos (añadirlos/eliminarlos). |
Home |
Permite al usuario ver una introducción sobre LoMap. |
6. Vista de tiempo de ejecución
6.1. Escenario de ejecución 1. Registro de nuevo usuario
6.2. Escenario de ejecución 2. Inicio de sesion de usuario
6.3. Escenario de ejecución 3. Añadir localización
El login ante el provedor de PODs ya está hecho en este escenario.
Las ubicaciones guardadas pueden ser vistas más tarde por el usuario y sus amigos a través de la aplicación web.
El usuario puede agregar una ubicación a su mapa.
6.4. Escenario de ejecución 4. Eliminar localización
Las ubicaciones agregadas al mapa luego serán eliminadas por el usuario a través de la aplicación.
6.5. Escenario de ejecución 5. Usuario visualiza una de sus localizaciones.
7. Vista de Despliegue
7.1. Infraestructura
- Motivacion
-
Se ha intentado plantear el sistema de la manera más descentralizada posible y mantener la privacidad del usuario de manera más optima posible. Como provedor de PODs usamos inrupt ya que nos facilita mucho el desarrollo del proyecto y tiene una fácil comunicación con la aplicación.
- Caracteristicas de calidad y/o rendimiento
-
Como nuestro objetivo es tener un sistema con alto rendimiento,seguridad y mantenible con el tiempo se ha intentado buscar y comenzar a usar la mejor infraestructura posible.
- Mapeo de Bloques de Construccion a Infraestructura
| Building Block | Mapping |
|---|---|
WebApp |
La parte donde el usuario podra interactuar, el cual ejecuta el navegador web. |
Web browser |
Depende de la eleccion del usuario, y unica forma de acceder a la aplicacion. |
POD |
"Almacenes" para guardar los datos de los usuarios de forma segura. el provedor de pods sera inrupt |
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. |
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. |
8. Conceptos Transversales
8.1. Modelo de dominio
8.2. Conceptos de seguridad y privacidad
-
Privacidad: los datos introducidos serán privados y no visibles. Las opiniones y marks creados por el usuario solo podrán ser visualizados por los amigos añadidos.
-
Seguridad: los datos serán completamente seguros, siendo almacenado en PODs individuales y no en una base de datos centralizada.
-
Gobernanza del dato: La calidad y confiabilidad de los datos es muy alta ya que usamos PODs para almacenarlos de forma totalmente descentralizada.
8.3. Arquitectura y patrones de diseño
-
Patrón fachada: para facilitar el desarrollo del proyecto por parte del equipo, haremos uso del patrón fachada para conectar el back con el front.
-
Pods: para guardar la información personal de cada usuario.
-
Interoperabilidad entre proyectos: el proyecto se intentará hacer de tal forma que la información alamacenada pueda ser usada de un proyecto a otro.
8.4. Experiencia usuario
-
Interfaz simple: trataremos de realizar una interfaz limpia, capaz de ser usada por cualquier usuario.
-
Capacidad de marcar y opinar de sus sitios favoritos con mapas.
-
Ver opiniones y recomendaciones de amigos.
-
Filtrar marcadores y opiniones por tipos de local.
8.5. Conceptos de desarrollo
-
Front-end: parte del desarrollo que se encarga de la parte visible de la aplicación. Esta parte se centra en la creación de la interfaz de usuario.
-
Back-end: "carece" de este puesto que toda la informacion se hace mediante los pods
-
Testeabilidad: será un proyecto desarrollado en base a la comprobación de test. Estos test pueden ser de funcionalidad o de rendimiento.
8.6. Conceptos operacionales
-
Rendimiento: es la medida de la eficacia en que la aplicación usa los recursos del sistema para hacer lo que ha diseñado para hacer. Este parámetro se tratará de mejorar mediante pruebas.
9. Decisiones de diseño
| Decisión Arquitectónica | Ventajas | Desventajas |
|---|---|---|
TypeScript |
Simplifica y mejora JavaScript al cual extiende agregando tipado de tipos |
Nadie ha trabajado con el así que hay que aprender a usarlo |
Pods |
Permiten que la información de los usuarios sea almacenada de forma distribuida en vez de centralizada, lo cual aparte de aumentar la robustez, también abarata costes |
agregaría el problema de que es una tecnología con la que nadie del grupo tiene experiencia y de que probablemente complicaría el desarrollo de la aplicación agregando complejidad al sistema |
GitHub |
Una herramienta muy útil para el control de versiones de la aplicación (tiene ramas, issues, etc.) |
Si no se gestionan bien los merges pueden ser muy problemáticos |
React |
Teniendo en cuenta la aplicación que se va a hacer usar React es muy conveniente, puesto que está diseñada principalmente para hacer aplicaciones de una sola página con JavaScript |
Puede agregar complejidad al proyecto |
10. Requerimientos de calidad
10.1. Árbol de calidad
10.2. Escenarios de calidad
| Objetivos de calidad | Motivación | Importancia |
|---|---|---|
Privacidad |
Uno de los principales objetivos es hacer una aplicación que respete la privacidad de los usuarios recogiendo la menor información posible de estos |
Alta |
Seguridad |
Garantizar la seguridad de los datos del cliente para aumentar su confianza y mantener a salvo su privacidad |
Alta |
Robustez |
Buen manejo de excepciones para mejorar la experiencia del usuario y el uso de pods para aumentar la robustez de los servers, alta disponibilidad y tolerancia a fallos software |
Alta |
Usabilidad |
La aplicación ha de ser intuitiva y de fácil manejo para gente de todo tipo de nivel |
Alta |
Eficiencia |
La aplicación será lo más eficiente posible usando los menores recursos posibles |
Media |
Transparencia |
Todo el proyecto será de codigo abierto, disponible en el repositorio de github para su modificación |
Bajo |
11. Riesgos y Deudas Técnicas
11.1. Riesgos
| Riesgo | Explicación | Solución |
|---|---|---|
Tiempo |
Poco tiempo de trabajo |
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 |
Tenemos poco conocimiento de GitHub |
Aprender cosas básicas. |
Nuevas tecnologías |
Para la mayoría del grupo la falta de conocimiento de tecnologías como React o Solid. |
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. Deuda técnica
| 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 |
12. Glosario
| Termino | Definición |
|---|---|
Discord |
Servicio de mensajería instantánea que incluye texto y llamadas de audio (por donde hacemos las reuniones). |
SOLID |
Proyecto desarrollado por Tim Berners-Lee que busca descentralizar los datos de los usuarios del resto de datos de la aplicacion almacenandolos en POD |
Pod |
Almacenamiento personal de datos alojado en un servidor elegido por el usuario. |
Github |
Repositorio en github para alojar proyectos utilizando el sistema de versiones Git. |
REACT |
Biblioteca Javascript de código abierto diseñada para crear interfaces de usuario con el objetivo de facilitar el desarrollo de aplicaciones en una sola página. |
Inrupt |
Empresa colaboradora con el proyecto SOLID de Tim Berners-Lee ofrece un servicio de provedor de PODs, su url es Inrupt.net. |
Material-UI |
Libreria de componentes para React con multiples estilos. |
HTTP |
Protocolo de transferencia de hipertexto, es el protocolo usado para las comunicaciones entre maquinas en la web. |
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.