Merge pull request #39 from Arquisoft/develop

Final merge to first review

docs/01_introduction_and_goals.adoc

@@ -10,6 +10,8 @@ Describes the relevant requirements and the driving forces that software archite
 * relevant stakeholders and their expectations
 ****
 
+LoMap es un aplicación solicitada por el ayuntamiento de Bruselas. Esta se encargará de generar mapas personalizados para cualquier ciudadano que desee utilizarla. En este mapa personalizado se pueden almacenar sitios favoritos (de multitud de categorías), reseñas y se puede generar una red de amigos para tener acceso a sus sitios y reseñas.
+
 === Requirements Overview
 
 [role="arc42help"]
@@ -30,6 +32,26 @@ If requirements documents exist this overview should refer to these documents.
 Keep these excerpts as short as possible. Balance readability of this document with potential redundancy w.r.t to requirements documents.
 ****
 
+Requisitos prioritarios:
+
+* Varias categorías de lugares.
+* Interfaz tipo mapa.
+* Se pueden crer reseñas y comentarios sobre tus lugares.
+* Existe una red de amigos para compartir reseñas, comentarios y lugares.
+* Existirán los filtros para poder visualizar la información deseada en cada momento.
+
+Requisitos de segundo nivel:
+
+* Incorporar el concepto de ruta que unirá varios lugares.
+* Los establecimientos podrán crear pods de su negocio para interactuar con los usuarios.
+* Poder comparar mapas, aplicando filtros a las comparaciones.
+* Generar boletines de noticias personalizados en función de los lugares favoritos del usuario.
+* Introducir la gamificacón (permitir descubrir lugares, almacenar información sobre ellos,etc)
+* Incorporar los mapas compartidos entre varios usuarios
+* Incluir roles dentro de la aplicación 
+* Los dueños de negocios podrán crear sus mapas con lugares recomendados en las inmediaciones de su negocio.
+* Conectar con el libro de direcciones para mostrar información recomendada.
+
 === Quality Goals
 
 [role="arc42help"]
@@ -45,6 +67,19 @@ If you as an architect do not know how the quality of your work will be judged 
 A table with quality goals and concrete scenarios, ordered by priorities
 ****
 
+Principales objetivos de calidad para satisfacer los intereses de los stakeholders y las necesidades de los usuarios.
+
+[options="header",cols="1,2"]
+|===
+|Objetivo|Motivación
+|Privacidad|La privacidad para LoMap es de vital importancia debido a que los datos de los usuarios no deben ser accesibles por terceros no deseados. La información se almacenara en los Pods de cada usuario y la información almacenada en servidores comunes deberá ser minimizada y justificada.
+|Flexibilidad|LoMap debe ser una aplicación flexible que permita su uso en otros contextos geográficos alejados de la ciudad de Bruselas.
+|Accesibilidad|Al ser un producto dirigido a un público general nuestra aplicación deberá cumplir los estándares de accesibilidad.
+|Usabilidad|Cualquier usuario no familiarizado con las aplicaciones y la tecnología deberá poder usar la aplicación. Se cumplirán las recomendaciones de usabilidad que nos brindan los organismos de estandarización.
+|Mantenibilidad|El código de LoMap debe seguir los estándares de diseño adecuados para generar una aplicación mantenible en el futuro.
+|Escalabilidad|LoMap debe ser una aplicación implementada con la intención de crecer y abarcar más funcionalidades. El código escrito debe facilitar esta dinámica.
+|===
+
 === Stakeholders
 
 [role="arc42help"]
@@ -67,9 +102,11 @@ These stakeholders determine the extent and the level of detail of your work and
 Table with role names, person names, and their expectations with respect to the architecture and its documentation.
 ****
 
-[options="header",cols="1,2,2"]
+[options="header",cols="1,2"]
 |===
-|Role/Name|Contact|Expectations
-| _<Role-1>_ | _<Contact-1>_ | _<Expectation-1>_
-| _<Role-2>_ | _<Contact-2>_ | _<Expectation-2>_
+|Rol/Nombre|Expectativas
+|Ayuntamiento de Bruselas|Entidad solicitante de la aplicación que busca ofrecer un servicio de calidad a sus habitantes. Requiere que se cumplan los objetivos de calidad.
+|Ciudadanos de Bruselas|Quieren que la experiencia de uso de la aplicación al ser presentada por su ayuntamiento sea agradable, sencilla y aporte valor.
+|Futuros usuarios|Necesitan que la solución sea genérica y escalable.
 |===
+

docs/02_architecture_constraints.adoc

@@ -17,3 +17,11 @@ If needed you can subdivide them into
 technical constraints, organizational and political constraints and
 conventions (e.g. programming or versioning guidelines, documentation or naming conventions)
 ****
+
+[options="header",cols="1,2"]
+|===
+|Tipo de restrición|Explicación
+| Restricción temporal | Tenemos aproximadamente un cuatrimestre para tener una versión de lanzamiento de la aplicación.
+| Restricción de alcance|  Esta app debe cumplir como mínimo con diferentes funciones como guardar lugares; asociar puntuaciones, comentarios y/o fotos a los lugares; visualizarlos en un mapa; informarse sobre estos; filtrar las ubicaciones.
+| Restricción de modelo| La información sobre los lugares de cada usuario se debe guardar en su pod personal. Se debe respetar la privacidad de cada usuario en la medida de lo posible.
+|===

docs/03_system_scope_and_context.adoc

@@ -1,7 +1,6 @@
 [[section-system-scope-and-context]]
 == System Scope and Context
 
-
 [role="arc42help"]
 ****
 .Contents
@@ -20,7 +19,6 @@ Various options:
 * Lists of communication partners and their interfaces.
 ****
 
-
 === Business Context
 
 [role="arc42help"]
@@ -39,9 +37,17 @@ Alternatively (or additionally) you can use a table.
 The title of the table is the name of your system, the three columns contain the name of the communication partner, the inputs, and the outputs.
 ****
 
-**<Diagram or Table>**
-
-**<optionally: Explanation of external domain interfaces>**
+image:03_Context_Diagram.png["Context Diagram"]
+[options="header",cols="1,2,2"]
+|===
+|Entidad|Entrada|Salida
+|User|Recibe el feedback proporcionado por la WebApp.|Crea y guarda en el POD su información personal.
+|POD|Recibe peticiones para recuperar información en la WebApp y de guardar información del usuario.|Proporciona la información guardada por el usuario a la aplicación.
+|WebApp|Recibe la información solicitada al POD y la API, y la interacción del usuario.|Guarda y actualiza información en el POD, además de mostrar el mapa al usuario a través de la interfaz.
+|Proveedor de mapas|Solicitud de la aplicación para obtener el mapa.|Información necesaria para mostrar el mapa.
+|RestApi|Hace consultas a la base de datos solicitadas por la aplicación|Recoge la información de la base de datos y se la envía a la aplicación.
+|Database|Hay información global que no se guardará en un POD y, por tanto se almacenará aquí|Responde a las peticiones realizadas por la RestApi.
+|===
 
 === Technical Context
 
@@ -56,11 +62,13 @@ Many stakeholders make architectural decision based on the technical interfaces
 .Form
 E.g. UML deployment diagram describing channels to neighboring systems,
 together with a mapping table showing the relationships between channels and input/output.
-
 ****
 
-**<Diagram or Table>**
-
-**<optionally: Explanation of technical interfaces>**
-
-**<Mapping Input/Output to Channels>**
+Usaremos las siguientes tecnologías:
+[options="header",cols="1,2"]
+|===
+|Tecnología|Descripción
+|TypeScript|Lenguaje utilizado para realizar la aplicación.
+|React|Biblioteca utilizada para crear interfaces de usuario en una sola página.
+|SOLID|Arquitectura para almacenar la información privada de los usuarios de manera descentralizada.
+|===

docs/04_solution_strategy.adoc

@@ -1,7 +1,6 @@
 [[section-solution-strategy]]
 == Solution Strategy
 
-
 [role="arc42help"]
 ****
 .Contents
@@ -22,3 +21,31 @@ Motivate what you have decided and why you decided that way,
 based upon your problem statement, the quality goals and key constraints.
 Refer to details in the following sections.
 ****
+
+=== Decisiones tecnológicas
+
+Como lenguaje de programación y fundamento de la aplicación hemos decidido utilizar TypeScript en contra parte de JavaScript, ya que el tipado estático de TypeScript nos facilitará entender el código creado por el resto del equipo. Además usaremos las siguientes tecnologías:
+
+* MongoDB: Base de datos NoSQL sencilla de gestionar. Y con la capacidad de desplegar en la nube gracias a MongoDB Atlas.
+* React: Biblioteca de JavaScript utilizada para crear la interfaz de la aplicación.
+* NodeJS: Permite la ejecución de JavaScript del lado del servidor, además de hacer la web fácilmente escalable.
+
+
+=== Descomposición de Alto Nivel
+==== Patrón de arquitectura
+
+Utilizamos uno de los patrones de arquitectura más comunes hoy en día, que es el patrón modelo vista controlador (MVC). Permite originalmente desacoplar la interfaz de usuario, la lógica de control y el modelo de datos. Al MVC añadiremos una separación entre el dominio de la aplicación y la persistencia, ya que es más oportuno para esta aplicación.
+
+
+=== Decisiones para alcanzar los criterios de calidad
+
+* Privacidad: Utilizaremos los PODs para mantener descentralizada la información privada de cada usuario, intentado guardar en la base de datos centralizada únicamente la información imprescindible.
+* Flexibilidad: Aunque el contrato de crear LoMap procede del ayuntamiento de Bruselas, generalizaremos el sistema para que pueda ser utilizado en cualquier otra ciudad.
+* Usabilidad: Para que cualquier persona sea capaz de utilizar de forma sencilla y cómoda la aplicación nos basaremos en las normas de los institutos de estandarización para la usabilidad en la web.
+* Mantenibilidad: Para conseguir una mantenibilidad adecuada nos basaremos en la arquitectura MVC y añadiremos algún otro patrón de diseño si es necesario, con el fin de que sea mantenible en el futuro.
+
+
+=== Decisiones organizativas
+
+La principal manera de comunicación del equipo será GitHub, por medio de la creación de Issues y el uso de Kanban, para organizar el trabajo y asignar los desarrolladores encargados de realizar las diferentes características. También hemos creado una rama por cada desarrollador con la intención de que cuando alguien ha terminado una funcionalidad se realice una pull request y el resto del equipo revise el código hasta dar su visto bueno y tener centralizado el desarrollo en una única rama.
+