1. Introducción y objetivos
1.1. Descripción general de los requisitos
-
Permitir añadir lugares en categorías diferentes.
-
Se podrán mostrar lugares en una ventana tipo mapa.
-
A los lugares añadidos se les puede asociar información extra.
-
Se podrán gestionar los accesos a la información compartida por otros usuarios.
-
La información sobre los lugares se almacenará en el pod de cada usuario.
-
Los usuarios podrán ver lugares e información aportada por sus amigos.
-
Se podrán incorporar filtros a los mapas.
Información más detallada: https://arquisoft.github.io/course2223/labEnunciadoPractica.html#requirements
1.2. Objetivos de calidad
Objetivo de calidad | Descripción | Prioridad (IMPORTANCIA, DIFICULTAD) |
---|---|---|
Interoperabilidad |
Los datos deben ser operables entre distintas aplicaciones similares - Compatibilidad |
HIGH, MEDIUM |
Disponibilidad |
El sistema debe ser capaz de reaccionar a caídas del sistema y ofrecer el servicio adecuadamente el máximo tiempo posible |
MEDIUM, HIGH |
Seguridad |
El sistema debe ser revisado y actualizado periódicamente, y aplicar las medidas de seguridad pertinentes de forma correcta - Privacidad |
HIGH, MEDIUM |
Escalabilidad |
El sistema debe reaccionar y no decrementar su rendimiento ante un crecimiento exponencial de usuarios y datos |
HIGH, HIGH |
1.3. Stakeholders
Rol/Nombre | Contacto | Expectativas |
---|---|---|
HappySw |
Cumplimiento de los objetivos de calidad y obtención de un sistema óptimo |
|
Ayuntamiento Bruselas |
Entrega de una aplicación para que los ciudadanos puedan disponer de mapas personalizados sobre lugares y negocios |
|
Equipo de desarrollo |
Desarrollo y entrega en plazo del producto solicitado, cumpliendo con todos los requisitos |
|
Usuarios |
Posibilidad de crear mapas personalizados sobre los lugares en los que estén interesados, e interaccionar con ellos |
|
Negocios |
Permitir crear sus propios espacios como una versión digital de su lugar físico |
2. Restricciones de la arquitectura
2.1. Restricciones técnicas
Restricción | Explicación |
---|---|
Solid |
Solid es una especificación que permite a los usuarios almacenar sus datos de una forma segura en Pods, unos almacenes de información descentralizados en los que los usuarios pueden controlar qué aplicaciones o usuarios pueden acceder a ellos. |
Git |
Se utilizará Git como sistema de control de versiones. |
GitHub |
Además del sistema de CV mencionado, el repositorio del proyeto será alojado en Github. |
2.2. Restricciones de organización
Restricción | Explicación |
---|---|
Planificación |
El sistema debe cumplir los requisitos y objetivos propuestos en un plazo aproximado de 3 meses, realizando entregas parciales cuando sean solicitadas. |
Equipo |
El equipo está formado por 4 personas cuya experiencia con las tecnologías mencionadas anteriormente es muy limitada. Será responsabilidad de cada integrante el adquirir los conocimientos necesarios, en pos de favorecer el trabajo conjunto y poder proporcionar un producto de calidad. |
Reuniones |
Nos reuniremos en la sesión semanal de prácticas para tomar decisiones sobre cualquier aspecto necesario, pudiendo también realizarse más reuniones si es se considera necesario para el desarrollo del proyecto. |
Distribución |
Se procurará realizar una repartición equitativa de las competencias a desarrollar para que el aporte de los miembros del grupo sea lo más justo posible. |
2.3. Convenciones
Restricción | Explicación |
---|---|
Documentación |
Usaremos la plantilla Arc42 para el desarrollo de la documentación. |
Protección de datos |
Se realizará un trato cuidadoso de los datos sensibles de los usuarios. Aplicar diferentes técnicas de seguridad, en aras de preservar y asegurar la protección de los datos, y velar por el bienestar de los usuarios. |
Convención SOLID |
La aplicación debe seguir las convenciones Solid establecidas. |
Convenciones de nombrado |
La aplicación debe seguir las convenciones de nombrado de las múltiples tecnologías. |
3. Alcance y contexto del sistema
3.1. Contexto de negocio
Socios de comunicación detallados:
Elemento | Entradas | Salidas |
---|---|---|
Usuario |
Órdenes a través de la interfaz de usuario |
La ejecución asociada a la orden recibida, y su materialización en la interfaz |
LOMAP System |
Recibe peticiones del usuario y datos del POD del usuario y de la BD |
Solicita información a los PODs y a la BD, y genera respuestas al usuario |
MongoDB |
Recibe datos para almacenarlos y recibe solicitudes de recuperación de los mismos |
Genera una respuesta con los datos pedidos por el sistema |
PODs |
Almacena información asociada a un usuario determinado, y se va actualizando |
Facilita información al sistema y trabaja con información del usuario |
3.2. Contexto técnico
Interfaces | Descripción |
---|---|
TypeScript |
Lenguaje para implementar y desarrollar la aplicación |
React |
Para componer la interfaz gráfica de usuario (Front-End) |
MongoDB |
Sistema de persistencia de datos |
NodeJS |
Entorno de ejecución de JavaScript |
SOLID |
Para almacenar datos de forma descentralizada |
Docker |
Plataforma para elaborar y probar el sistema en funcionamiento |
4. Estrategia de solución
4.1. Decisiones tecnológicas
Decisión | Explicación |
---|---|
SOLID |
Especificación que permite almacenar datos de forma descentralizada. De uso obligatorio. |
Git |
Sistema de control de versiones. De uso obligatorio. |
GitHub |
Plataforma para Git. De uso obligatorio. |
React |
Librería de Javascript para crear interfaces de usuario, caracterizado por su facilidad de uso. Muy popular en estos menesteres. |
Node.js |
Entorno de ejecución para desarrollar aplicaciones del lado del servidor. Facilita el uso de eventos. |
TypeScript |
Lenguaje de programación que añade funcionalidad a Javascript y permite fácilmente la escalabilidad del código, además de detección de errores más rápidamente. Enfocado en la lógica de negocio. |
Docker |
Orientado al despliegue de aplicaciones con todas las dependencias necesarias del proyecto. |
Jest |
Framework de pruebas JavaScript simple y rápido. |
Open Street Maps |
Para la creación de mapas y el uso de funciones variadas relativas a ello. La API permite realizar un consumo del servicio web de manera fácil y cómoda. |
MongoDB |
Sistema de base de datos NoSQL orientado a documentos. |
Bootstrap |
Librería de código abierto para el diseño de aplicaciones, permitiendo un diseño web adaptable sin dificultad. |
4.2. Enfoques para alcanzar objetivos de calidad
Para alcanzar los objetivos de calidad trataremos de aplicar un conjunto de herramientas y decisiones que puedan hacer que los datos sean interoperables. Aplicando los Pods conseguimos que la información esté descentralizada, lo que desemboca en una considerable mejora de la seguridad al no tener datos sensibles de los usuarios de forma centralizada.
4.3. Decisiones organizativas relevantes
Cada semana realizaremos una reunión presencial (en el espacio reservado a la sesión de prácticas), pudiendo también realizar reuniones por la plataforma Microsoft Teams. Para establecer las tareas que hace cada miembro, se utilizará GitHub Projects; y para el tratamiento de errores se utilizarán las Issues.
5. Vista por bloques
5.1. Sistema general de caja blanca
- Motivación
-
Los usuarios interactuarán con la aplicación LoMap que es la estructura general del sistema en la que podrán añadir lugares, mostrarlos y opinar sobre ellos. Toda esta información será almacenada de forma segura en sus propios PODs. Los usuarios serán los dueños de estos PODs.
- Bloques de construcción contenidos
Nombre | Descripción |
---|---|
User |
Es el cliente que usará la aplicación LoMap a través de la interacción con esta y también tendrá un POD personal. |
LoMap |
Aplicación desarrollada que intercambia información con los PODs y está diseñada para interactuar con el usuario |
POD’s |
Almacena la información del usuario y se comunica con la aplicación |
5.2. Nivel 2
- Motivación
-
La aplicación LoMap se ve dividida en 2 capas que se especificarán en el siguiente nivel. Además se incorparan las API que complementarán la aplicación LoMap
- Bloques de construcción contenidos
Nombre | Descripción |
---|---|
Model |
Se comunica con los PODs para intercambiar información y con los controladores para que esta información pueda comunicarse con el resto de la aplicación |
View |
Encargada de la interacción con el usuario y se comunica con los controladores. |
Controller |
Encargado de interaccionar entre las distintas capas. |
API |
Se comunicará con la capa del controlador para proporcionar servicios. |
5.3. Nivel 3
- Motivación
-
Se detallan las 2 capas anteriores para especificar la estructura del sistema.
6. Vista en tiempo de ejecución
6.1. Nivel 0
6.1.1. Identificación
6.1.2. Añadir lugar en mapa
6.1.3. Compartir lugares
6.1.4. Añadir review a lugar
6.1.5. Visualizar lugares
6.1.6. Filtrar lugares
6.1.7. Enviar solicitud de amigo
6.1.8. Listar lugares de amigos
6.2. Nivel 1
6.2.1. Identificación
6.2.2. Añadir lugar en mapa
6.2.3. Compartir lugares
6.2.4. Añadir review a lugar
6.2.5. Visualizar lugares
6.2.6. Filtrar lugares
6.2.7. Enviar solicitud de amigo
6.2.8. Listar lugares de amigos
7. Vista de despliegue
7.1. Nivel 1 de infraestructura
Diagrama general
- Componentes
-
-
El cliente accederá desde su dispositivo a nuestra aplicación desplegada en un servidor de Amazon (AWS).
-
Tras acceder se le mostrará el indice que posee información un login que redirecciona a un login que dependerá del distribuidor de pods seleccionado.
-
Tras iniciar sesión con el servicio pods correspondiente se le redireccionará a la página principal de la aplicación, donde el solo verá una página formada por una gran cantidad de componentes con sus diferentes funcionalidades.
-
Estos compomentes pueden llegar a estar formados por más componentes y podrán usar también APIs externas (maps API), así como llamadas a funciones TypeScript y JavaScript de ficheros adicionales (principalemnte para realizar la conexión con los PODS). Estos componentes también podrán realizar peticiones a la base de datos.
-
Respecto a la persistencia, la mayoría de la infirmación se guardará en los PODS, siendo la base de datos en mongoDB unica y exclusivamente para aumentar la eficiencia de la aplicación.
-
8. Conceptos transversales
8.1. Modelo de dominio
8.2. Experiencia de usuario
Se diseñará una interfaz de usuario que facilite la experiencia utilizando el framework React jutno con TypeScript. Se seguirán todas las medidas posibles para garantizar la usabilidad y adaptabilidad del sitio web. Además se tratará de ofrecer toda la ayuda posible junto a interfaces que sean intuitivas para el usuario.
8.3. Seguridad
La seguridad en LoMap será un aspecto muy importante ya que cada usuario almacenará la información personal. Se evitará el uso malicioso sobre las API y el sistema de POD integrará la información necesaria para que la información sea personal. Por otro lado las contraseñas de los usuarios si se ven expuestas serán cifradas. También se implementará un sistema para que los roles de los usuarios se puedan distinguir y asi separar sus opciones (Usuario normal, Dueños de negocio, Administradores).
8.4. Testeabilidad
Antes de que cualquier cambio se realice, se probará todos los escenarios posible dejandolos documentados para su posible reutilización en un futuro. Tambien habrá pruebas no solo unitarios (de webapp y restapi) sino tambien de carga y end to end.
8.5. Persistencia
Los datos se almacenarán en los pods siendo la base de datos para gestionar las solicitudes de amistad y mejorar el rendimiento de la aplicación.
9. Decisiones de diseño
Contexto | Decision |
---|---|
Es necesario almacenar las relaciones entre los usuarios, así como los lugares destacados de cada uno de estos. Del mismo modo, se han de almacenar ciertas caracteristicas, comentarios, etc. de cada ubicación. |
Para guardar los datos se usarán los pods en todo momento, puedioendose guardar una copia de la información obtenida en la base de datos de mongo para disminuir tiempos de espera. |
Necesitamos identificar a los usuarios en nuestra aplicación para que no se creen mapas anonimos |
Para esto redireccionaremos a los usuarios a un login de SOLID del distribuidor de pods que seleccionen y así de paso obtendremos un token de inicio de sesión que nos facilitará el proceso de la persistencia con los pods. |
Será necesario mostrar un mapa donde los usuarios podrán ver sus ubicaciones, así como la de sus amigos y todos los comentarios establecidos en cada punto. |
Para ello usaremos una API externa, en nuestro caso emplearemos OpenStreetMaps. |
A la hora de crear la interfáz gráfica se optó por cuidar su diseño. |
Para ello usaremos MUI lo que facilitará el desarrollo de interfaces gráficas más visuales. |
Se buscaron libreriás para que respecto a ciertas partes tediosas del desarrollo del backend fueran más amenas. |
Se empleará expressjs para desarrollar ciertas partes de la aplicación y mongoose para facilitar la comunicación con la base de datos. |
Es neciesario realizar una gran cantidad de tests y tener una covertura mínima. |
Se empleará SonarCloud, Jest, Gatling. |
10. Requisitos de calidad
10.1. Árbol de calidad
10.2. Escenario de calidad
Objetivo de calidad | Escenario | Prioridad para el usuario | Prioridad para el desarrollador |
---|---|---|---|
Interoperabilidad |
Los usuarios pueden tener dispositivos muy variados, con SO diversos, herramientas concretas, etc. Si se elabora un sistema orientado a un único tipo de dispositivo, se cierra una enorme puerta a una cantidad masiva de usuarios. La interoperabilidad hace referencia a la posibilidad de desplegar y trabajar con un sistema desde diversos tipos de terminales, con características distintas, pudiendo ofrecer un servicio unificado y de igual calidad, independientemente del dispositivo. |
HIGH |
HIGH |
Disponibilidad |
Un sistema cuyo servicio está caído la mayor parte del tiempo es un servicio inútil. La disponibilidad hace referencia a la capacidad del sistema para ofrecer un servicio de manera ininterrumpida, pudiendo responder ante situaciones que comprometan su funcionamiento de manera adecuada y recuperarse de la forma más rápida, segura y eficiente posible. |
MEDIUM |
MEDIUM |
Seguridad |
Todo sistema está expuesto a una serie de riesgos, tanto a nivel físico (hardware) como a nivel de software. Aplicar unas correctas contramedidas para asegurar el perímetro de los elementos influyentes, evitando así propagación de virus, extracción de información, etc… resulta fundamental. Además, el almacenamiento de información descentralizadamente es una buena práctica para preservar la privacidad del usuario. |
HIGH |
HIGH |
Escalabilidad |
A medida que un sistema va creciendo, existe la posibilidad de que haya un impacto en el rendimiento. La mayor cantidad de datos a manejar y el incremento del tráfico en el sistema, puede ralentizar y deteriorar la experiencia de usuario, pudiendo llegar a convertir la aplicación en una pieza de software inútil e ineficiente. La escalabilidad describe la forma que tiene de reaccionar el sistema ante la evolución y el crecimiento de sí mismo. |
MEDIUM |
HIGH |
11. Riesgos y deudas técnicas
A continuación, la lista de riesgos y deudas técnicas localizadas, ordenadas por prioridad / importancia:
Riesgo | Descripción | Solución |
---|---|---|
Mal diseño / enfoque de un problema |
Si el sistema contiene fallos en las fases preliminares del proyecto, que a su vez suelen ser las más importantes, esto puede tener consecuencias fatales. Las decisiones de diseño son vitales, y un error detectado tiempo después de comenzar la implementación puede ser imposible de subsanar. De ahí, la importancia de plantear las cosas bien desde el principio y tener visión de futuro, para evitar caer en errores que acaben pagándose tiempo después, con el proyecto ya en fase de implementación, y teniendo que tirar parte del producto. |
Hacer especial hincapié en las fases de diseño, considerar todas las posibilidades, aplicar patrones conocidos, ser ordenado a la hora de trabajar. |
Desconocimiento de las tecnologías |
Inicialmente, los integrantes del grupo parten de un nivel prácticamente nulo sobre las tecnologías que van a ser empleadas. Esto puede implicar que no se aproveche todo el potencial de las herramientas. |
Formación autodidacta a través de investigación operativa por parte de todos los miembros, pudiendo incluso especializarse cada uno de ellos en una herramienta específica (conociendo el funcionamiento básico del resto, indispensable). |
Fallo en la implementación |
Pueden existir fallos en la lógica de negocio que persistan en el sistema durante largo tiempo, sin que los desarrolladores se percaten. No suelen ser fallos críticos, ya que en tal caso serían facilmente detectables, pero nunca un programa va a estar al 100% libre de bugs. |
Hacer pruebas suficientes del funcionamiento, comprobar la lógica adecuadamente, implementar con especial atención y cuidado. |
Mala comunicación entre miembros |
Al trabajar conjuntamente, los distintos integrantes deben comunicarse para llevar a cabo un plan de trabajo bajo un marco común. No siempre es posible, debido a múltiples factores: discrepancia en opiniones, diferencias personales, pasividad por parte de miembros,… Esto es fundamental para un buen trabajo en grupo. |
Establecer unas reglas de trabajo firmes desde el primer momento, y tomar las medidas pertinentes para que el desarrollo no se vea perturbado por la mala práctica de cierto sector del grupo. |
Mala distribución de trabajo |
Generalmente cada miembro se encarga de partes diferentes, o comparten una parte pero hacen una labor distinta sobre ella. Se trata de evitar una mala distribución de las tareas, para que un miembro no se vea sobrecargado y saturado con sus responsabilidades, mientras que otros están mucho más liberados en ese aspecto. |
Repartición de responsabilidades equitativa mediante un sistema de votación en el que se persiga la unanimidad. |
Disminución del tamaño del grupo |
Cualquier integrante puede llegar a fallar y desvincularse del proyecto. Esto no puede implicar la detención del proyecto, sino que debe seguir adelante. Al ser un hecho de caracter personal, no existe una medida a ciencia cierta para evitarla, pero sí ciertas políticas para responder ante estos casos. |
Supuesta la situación mencionada conviene, en primer lugar, que nadie del grupo sea categoricamente imprescindible. De esta forma, mediante una nueva planificación y repartición del trabajo, se podrá proseguir (aunque con mayor carga de trabajo individual). |
12. Glosario
Term | Definition |
---|---|
arc42 |
Plantilla para la documentación de arquitectura de sistemas y de software. |
React |
Librería de código abierto de JavaScript para desarrollar interfaces de usuario. |
Solid |
Proyecto de descentralización de datos en la web, cuyo objetivo es que los usuarios tengan el control de sus datos privados. |
Docker |
Permite el despliegue de aplicaciones dentro de contenedores de software, proporcionando una capa adicional de abstracción. |
POD |
Contenedor de información de caracter privado del usuario. Puede estar asociado a uno o varios contenedores, como los de Docker. |
TypeScript |
Es un preprocesador, un lenguaje de programación libre y de código abierto que genera JavaScript. |
GUI |
Interfaz gráfica de usuario, es decir, la parte del sistema con la que interacciona un usuario. |
Git/GitHub |
Sistema de control de versiones, es decir, programa que facilita el trabajo multiusuario a través de un sistema dedicado, que ofrece funciones para mezclar partes de código, controlar modificaciones, etc… |
NodeJS |
Entorno en tiempo de ejecución multiplataforma, de código abierto, basado en JavaScript. |
MongoDB |
SIstema de Base de Datos NoSQL, de código abierto, que permite persistir la información manejada por una aplicación de forma eficiente. |
JSON |
Tipo de archivo con un formato concreto destinado al intercambio de información a través de medios como la web. Más eficiente que XML. |
API |
Pieza de código incrustada en un programa que permite a una aplicación comunicarse con otra para recibir información, consumir servicios web, etc… |
Stakeholder |
Entidad (persona, empresa, …) interesada en el proyecto, implicada en el mismo o a la que afecte directa o tangencialmente. |
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.