00. Decisiones arquitectónicas

DA-01: Elección del lenguaje de programación

Estado: Aceptada
Contexto: Se deja a libre elección del equipo de desarrollo el lenguaje de programación de la aplicación. El equipo de desarrollo había planteado realizar la aplicación utilizando JavaScript o TypeScript.
Decisión: El equipo de desarrollo ha acordado el uso de TypeScript debido a que permite la utilización de tipos estáticos lo que, bajo nuestro punto de vista, facilita la comprensión del código del resto de los integrantes.
Consecuencias: Familiarizarse con el lenguaje, ya que ningún miembro lo ha utilizado con anterioridad.

Estado: Aceptada
Contexto: Por motivos de rendimiento, se almacenará información de manera centralizada en una base de datos, respetando la privacidad de los usuarios en la medida de lo posible.
Decisión: Se decide utilizar como base de datos MongoDB debido a ser un sistema que aloja bases de datos NoSQL y de código abierto. Para desplegar la base de datos en la nube utilizaremos MongoDB Atlas.
Consecuencias: Una base de datos NoSQL es más sencilla de gestionar y se ajusta a nuestro proyecto. MongoDB, pese a ser una tecnología joven, cuenta con una gran documentación, lo que nos facilitará su uso.

Estado: Aceptada
Contexto: Se necesita crear una interfaz de usuario, en la asignatura se proporciona información acerca de la biblioteca React.
Decisión: Se decide utilizar React para la creación de la interfaz de usuario usando como base el proyecto proporcionado por los profesores.
Consecuencias: Familiarizarse con los distintos componentes de la biblioteca.

Estado: Aceptada
Contexto: Es necesario un entorno que facilite la ejecución de la aplicación. En la asignatura se nos proporciona un proyecto base que usa NodeJs con express, por lo que es la opción que hemos considerado.
Decisión: Se utilizará NodeJS con express debido a que permiten crear aplicaciones web escalables y disponen de mucha documentación.
Consecuencias: Instalación del software necesario y familiarizarse con su uso, investigando dependencias de NodeJS que faciliten el desarrollo del proyecto.

Estado: Rechazada
Contexto: Para facilitar el desarrollo de la aplicación es necesario el uso de una API que nos proporcione los servicios de mapas imprescindibles para el proyecto. La opción con la que los miembros nos encontramos más familiarizados es la API Google Maps.
Decisión: Se usarán los servicios de la API Google Maps debido a que requiere menos adaptación de los miembros y su interfaz es la más limpia.
Consecuencias: Terminar de perfeccionar el uso de la API mencionada. Creación de una cuenta introduciendo la tarjeta de crédito de uno de los miembros para usar su licencia temporal gratuita. El alcance de la mencionada licencia es suficiente para el desarrollo del proyecto actual.

Estado: Aceptada
Contexto: No se ha podido conseguir una licencia gratuita de la API de Google Maps por lo que nos hemos decantado por utilizar otra API
Decisión: Se usarán los servicios proporcionados por Leaflet, una librería para JavaScript que proporciona mapas interactivos de forma gratuita.
Consecuencias: Familiarizarse con la nueva API ya que nunca habíamos trabajado con ella.

Estado: Aceptada
Contexto: Investigando sobre la Leaflet se ha encontrado la librería React Leaflet que proporciona componentes personalizados para usar con Leaflet sin sustituir a este.
Decisión: Se usará React Leaflet en su versión 3.x para simplificar su integración con el resto de versiones que estamos usando en el proyecto.
Consecuencias: Familiarizarse con los componentes y manejadores de eventos que proporciona.

Estado: Aceptada
Contexto: Se necesitaba actualizar el estado del mapa al interactuar con otros componentes.
Decisión: Utilización de la biblioteca Redux ya que permite centralizar el estado de la aplicación y compartirlo entre los componentes que se suscriban a él de manera sencilla.
Consecuencias: Nueva configuración para manejar cierto tipo de eventos y, por lo tanto, adaptación a ella.

Estado: Aceptada
Contexto: Se buscaba un formato de archivos que facilitase la interacción con el pod además de la interoperabilidad entre las distintas aplicaciones creadas en el curso.
Decisión: Se utiliza como formato JSON-LD ya que se integra con otros formatos como RFD y Schema.org además de ser relativamente sencillo su uso ya que hacemos uso de la biblioteca jsonld.
Consecuencias: N/A

Estado: Aceptada
Contexto: La aplicación permite a los usuarios elegir imágenes almacenadas en su ordenador y vincularlas a los lugares que van a añadir al mapa. Para esto es necesario procesar las imágenes y almacenarlas en la nube.
Decisión: Se utilizará Cloudinary que es una solución para el procesamiento de imágenes y nos proporciona un almacenamiento en la nube de estas.
Consecuencias: Familiarizarse con el uso de este entorno para lograr una correcta integración en nuestra aplicación.

Estado: Aceptada
Contexto: Como consecuencia de la decisión arquitectónica anterior, el uso de Cloudinary, es necesario enviar solucitudes HTTP a dicha plataforma para subir las imágenes. Por este motivo es necesario elegir un cliente HTTP a través del cual realizar las peticiones.
Decisión: Se hará uso de la librería Axios que es un cliente HTTP ya que se integra bien con las tecnologías usadas en nuestra aplicación.
Consecuencias: N/A

Estado: Aceptada
Contexto: Es necesario desplegar la aplicación creada en la nube, para ello hacía falta encontrar un proveedor que nos proporcionase servicios en la nube a un coste asequible.
Decisión: Para desplegar la aplicación web se hace uso de Azure debido a que proporciona a los estudiantes una cantidad de créditos gratuitos suficientes para realizar el despliegue.
Consecuencias: Es un entorno con el que los miembros del equipo estamos familiarizados por lo que nos ahorramos parte de la curva de aprendizaje. También hay que tener en cuenta el saldo limitado que nos proporciona la plataforma y actuar en base a ello.

Universidad de Oviedo

Escuela de Ingeniería Informática del Software

Arquitectura del Software