Merge pull request #19 from Arquisoft/develop

Develop

docs/01_introduction_and_goals.adoc

@@ -1,75 +1,45 @@
 [[section-introduction-and-goals]]
-== Introduction and Goals
+== Introducción y metas
 
-[role="arc42help"]
-****
-Describes the relevant requirements and the driving forces that software architects and development team must consider. These include
+LoMap es una aplicación desarrollada por HappySw, en la que sus usuarios tendrán acceso a un mapa personalizado con los sitios de su interés dentro de la ciudad de Bruselas.
 
-* underlying business goals, essential features and functional requirements for the system
-* quality goals for the architecture
-* relevant stakeholders and their expectations
-****
+La funcionalidad principal se basa en un mapa, en el cual el propio usuario podrá seleccionar y guardar sus locales o lugares favoritos para tenerlos siempre a mano. Estos lugares pueden ir desde tiendas, bares o los monumentos más icónicos de la capital belga.
 
-=== Requirements Overview
+A diferencia de otras aplicaciones de mapas, LoMap permite al usuario que sea él el que decida que ver sobre su propio mapa, eliminando los lugares de menos interés, lo cual permite que sea muy práctico, tanto para los propios habitantes de la ciudad como para los turistas.
 
-[role="arc42help"]
-****
-.Contents
-Short description of the functional requirements, driving forces, extract (or abstract)
-of requirements. Link to (hopefully existing) requirements documents
-(with version number and information where to find it).
+La aplicación respeta la privacidad de los clientes mediante los principios SOLID.
 
-.Motivation
-From the point of view of the end users a system is created or modified to
-improve support of a business activity and/or improve the quality.
 
-.Form
-Short textual description, probably in tabular use-case format.
-If requirements documents exist this overview should refer to these documents.
+=== Descripción de los requisitos
 
-Keep these excerpts as short as possible. Balance readability of this document with potential redundancy w.r.t to requirements documents.
-****
+Los principales requisitos funcionales de la aplicación serán:
 
-=== Quality Goals
+* Los usuarios podrán marcar con chinchetas (temporal) los lugares de interés.
+* El sistema almacenará y mostrará los lugares ya marcados anteriormente dependiendo de los datos que haya en el pod de cada usuario.
+* Los usuarios podrán añadir tanto fotos, como comentarios en los lugares que hayan añadido.
+* Los usuarios podrán agregar amigos para poder ver los lugares y comentarios que hicieron sobre los mismos.
+* El mapa tendrá filtros, ya sea para filtrar los lugares por restaurantes o monumentos, o para ver los lugares favoritos de sus amigos.
 
-[role="arc42help"]
-****
-.Contents
-The top three (max five) quality goals for the architecture whose fulfillment is of highest importance to the major stakeholders. We really mean quality goals for the architecture. Don't confuse them with project goals. They are not necessarily identical.
 
-.Motivation
-You should know the quality goals of your most important stakeholders, since they will influence fundamental architectural decisions. Make sure to be very concrete about these qualities, avoid buzzwords.
-If you as an architect do not know how the quality of your work will be judged …
+=== Objetivos de calidad
 
-.Form
-A table with quality goals and concrete scenarios, ordered by priorities
-****
-
-=== Stakeholders
-
-[role="arc42help"]
-****
-.Contents
-Explicit overview of stakeholders of the system, i.e. all person, roles or organizations that
-
-* should know the architecture
-* have to be convinced of the architecture
-* have to work with the architecture or with code
-* need the documentation of the architecture for their work
-* have to come up with decisions about the system or its development
+[options="header",cols="1,2,2"]
 
-.Motivation
-You should know all parties involved in development of the system or affected by the system.
-Otherwise, you may get nasty surprises later in the development process.
-These stakeholders determine the extent and the level of detail of your work and its results.
+|===
+|Prioridad|Meta|Motivación
+| 1 | Usabilidad | La aplicación debe ser fácilmente usable por cualquier usuario, con mucha o poca experiencia.
+| 2 | Calidad | La aplicación debe satisfacer las necesidades del usuario de una forma correcta.
+| 3 | Privacidad | El tratamiento de la información privada del usuario debe ser descentralizada, asegurando así su privacidad.
+| 4 | Eficiencia | Al abrir la aplicación o seleccionar un elemento debe ser eficiente y sus tiempos de carga bajos.
+|===
 
-.Form
-Table with role names, person names, and their expectations with respect to the architecture and its documentation.
-****
+=== Stakeholders
 
 [options="header",cols="1,2,2"]
+
 |===
-|Role/Name|Contact|Expectations
-| _<Role-1>_ | _<Contact-1>_ | _<Expectation-1>_
-| _<Role-2>_ | _<Contact-2>_ | _<Expectation-2>_
+|Rol/Nombre|Contacto|Expectativas
+| Cliente | Interaccionan de manera directa con la aplicación, tienen un usuario y amigos y pueden visualizar los puntos de interés | El objetivo principal es que sea capaz de interactuar con la aplicación de forma intuitiva y de una manera cómoda para el usuario aún sin ser un usuario avanzado.
+| Equipo de desarrollo | Los creadores de la aplicación, pueden modificarla y mejorarla | Trabajan para aprender las tecnologías necesarias para desarrollar el proyecto y funcionar como un equipo.
+| Profesores | Interaccionan con el equipo de desarrollo para corregir posibles defectos | Esperan que la aplicación sea funcional y cumpla los requisitos requeridos. También proporcionan soporte en caso de que sea necesario para el equipo de desarrollo.
 |===

docs/02_architecture_constraints.adoc

@@ -1,19 +1,44 @@
 [[section-architecture-constraints]]
-== Architecture Constraints
+== Restricciones
 
+=== Restricciones tecnicas
 
-[role="arc42help"]
-****
-.Contents
-Any requirement that constrains software architects in their freedom of design and implementation decisions or decision about the development process. These constraints sometimes go beyond individual systems and are valid for whole organizations and companies.
+[options="header", cols="1,1"]
+|===
+|Restricción |Explicación
 
-.Motivation
-Architects should know exactly where they are free in their design decisions and where they must adhere to constraints.
-Constraints must always be dealt with; they may be negotiable, though.
+|Implementación 
+|El front-end estará formado por React y el back-end por Node.js con Express.
 
-.Form
-Simple tables of constraints with explanations.
-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)
-****
+|Seguridad
+|La información de los usuarios se almacenará en PODs siguiendo los principios SOLID.
+
+|Base de Datos
+|Usaremos TBD.
+|===
+
+=== Restricciones organizacionales
+
+[options="header", cols="1,1"]
+|===
+|Restricción |Explicación
+
+|Equipo 
+|Lara Fernández Méndez, Eloy Alfredo Schmidt Rodríguez, Luis Manuel Solares García, Miguel Mier Castañón.
+
+|Control del Repositorio
+|Todo el proyecto se encuentra en un repositorio en github con las siguientes ramas: Rama Master, rama Release, Rama Develop y una rama por cada usuario.
+|===
+
+=== Convenciones
+
+[options="header", cols="1,1"]
+|===
+|Restricción |Explicación
+
+|Documentación 
+|Arquitectura AsciiDoc.
+
+|Idioma
+|Español.
+|===

docs/03_system_scope_and_context.adoc

@@ -1,66 +1,39 @@
 [[section-system-scope-and-context]]
 == System Scope and Context
 
+=== Contexto Empresarial
 
-[role="arc42help"]
-****
-.Contents
-System scope and context - as the name suggests - delimits your system (i.e. your scope) from all its communication partners
-(neighboring systems and users, i.e. the context of your system). It thereby specifies the external interfaces.
+La aplicación LoMap consta de un Frontend y un Backend que se comunican con un sistema de PODs y una base de datos que contiene los lugares que se van a utilizar en la aplicación.
 
-If necessary, differentiate the business context (domain specific inputs and outputs) from the technical context (channels, protocols, hardware).
+Los usuarios se comunicarán con el Frontend de la aplicación el cual se comunicará con el sistema de PODs externo a la aplicación para obtener la información del Usuario y sus lugares almacenados. El Frontend también se comunicaré con el Backend de la aplicación para obtener la información de los lugares que almacena en Usuario en el POD.
 
-.Motivation
-The domain interfaces and technical interfaces to communication partners are among your system's most critical aspects. Make sure that you completely understand them.
+**Diagrama de Contexto Empresarial**
 
-.Form
-Various options:
+image:03_business_context.png["Business Context de la Aplicación"]
 
-* Context diagrams
-* Lists of communication partners and their interfaces.
-****
+**Tabla de Contexto Empresarial**
+[options="header", cols="1,1,1"]
+|===
+| Elemento de comunicación | Input| Output
+| Frontend | El Frontend recibe como entradas los datos solicitados al POD así como peticiones por parte del Usuario de diferentes pantallas de la pagina Web. También recibe las respuestas de las peticiones al Backend de la aplicación. | Las salidas que proporciona el Frontend son peticiones al Backend de la aplicación para la obtención de información sobre un lugar así como peticiones al POD para obtener información de los mapas de un usuario. También proporciona una visualización al usuario de forma gráfica.
+| Backend | Recibe como entradas las peticiones por parte del Frontend y las respuestas por parte de la BBDD | El Backend tiene como salidas las respuestas a las peticiones del Frontend y las peticiones de datos a la BBDD. 
+| BBDD | Como entrada tiene las peticiones de datos almacenados por parte del Backend de la aplicación | Como salidas devuelve los objetos solicitados o un mensaje de error en el caso de que no exista lo que el Backend solicita.
+| POD | Como entrada el POD recibe una petición de obtención de los datos de un Usuario | Como salida devuelve los datos del Usuario si está autorizada la petición o un mensaje de error en caso contrario.
+| Usuario | El usuario visualiza de forma gráfica la petición que ha realizado al Frontend de la aplicación | El usuario solicita al Frontend la visualización de una pagina de la aplicación.
+|===
 
+=== Contexto Técnico
 
-=== Business Context
+**Diagrama de Contexto Técnico**
 
-[role="arc42help"]
-****
-.Contents
-Specification of *all* communication partners (users, IT-systems, ...) with explanations of domain specific inputs and outputs or interfaces.
-Optionally you can add domain specific formats or communication protocols.
+image:03_technical_context.png["Technical Context de la Aplicación"]
 
-.Motivation
-All stakeholders should understand which data are exchanged with the environment of the system.
-
-.Form
-All kinds of diagrams that show the system as a black box and specify the domain interfaces to communication partners.
-
-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>**
-
-=== Technical Context
-
-[role="arc42help"]
-****
-.Contents
-Technical interfaces (channels and transmission media) linking your system to its environment. In addition a mapping of domain specific input/output to the channels, i.e. an explanation with I/O uses which channel.
-
-.Motivation
-Many stakeholders make architectural decision based on the technical interfaces between the system and its context. Especially infrastructure or hardware designers decide these 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>**
+**Mapeado de Input/Output a Canales**
+[options="header", cols="1,1,1"]
+|===
+|Canal de comunicación|Input|Output
+| SOLID-WebAPP | Se utiliza una comunicación HTTPS para solicitar datos a SOLID | Se utiliza una comunicación HTTPS para la obtención de la respuesta por parte de SOLID.
+| _WebApp-RestAPI_ | Se utiliza una petición HTTPS desde la WebApp hacía la RestAPI | Se utiliza una respuesta HTTPS desde la RestAPI hacía la WebApp.
+| _RestAPI-MongoDB_ | Se utiliza una petición HTTPS desde la RestAP hacía la base de datos MongoDB online | Se devuelve una respuesta HTTPS por parte de la base de datos MongoDB hacía la RestAPI.
+| _WebAPP-Usuario_ | La WebApp recibe una peticíon HTTP por parte del Usuario | La WebApp devuelve una pagina dinámica al Usuario por medio de una respuesta HTTP.
+|===

docs/04_solution_strategy.adoc

@@ -1,24 +1,29 @@
 [[section-solution-strategy]]
-== Solution Strategy
+== Estrategia de solución
 
+* Base de datos: TBD.
 
-[role="arc42help"]
-****
-.Contents
-A short summary and explanation of the fundamental decisions and solution strategies, that shape the system's architecture. These include
+* Express js: Express es un marco de aplicación web de Node js que proporciona amplias funciones para crear aplicaciones web y móviles. Se utiliza para crear una aplicación web híbrida, de varias páginas y de una sola página.
 
-* technology decisions
-* decisions about the top-level decomposition of the system, e.g. usage of an architectural pattern or design pattern
-* decisions on how to achieve key quality goals
-* relevant organizational decisions, e.g. selecting a development process or delegating certain tasks to third parties.
+* React JS: Es un framework creado por Facebook ampliamente utlizado para crear componentes de la interfaz de usuario. Escogido por el gran volumen de documentación y ser el framework utilizado durante los anteriores cursos.
 
-.Motivation
-These decisions form the cornerstones for your architecture. They are the basis for many other detailed decisions or implementation rules.
+* Despliegue: TBD.
+
+=== Diseño
+
+=== Seguridad
+Garantizamos la seguridad del usuario mediante el uso de PODs.
+
+=== Testabilidad
+Se realizarán pruebas para cada parte individual de la aplicación, garantizando así el correcto funcionamiento de los diferentes modulos tanto individualmente como de forma conjunta.
+
+=== Desarrollo
+Para esta fase inicial del proyecto se ha tenido más en cuenta el Front-End, el Back-End se tendrá mayor en consideración más adelante en el curso, ya que en otras asignaturas se van a adquirir conocimientos útiles que se podrán aplicar.
+
+=== Estructura
+
+=== Interfaz
+La interfaz gráfica será elegida entre todos los miembros del equipo, aportando cada uno algún boceto o idea, los cuales serán puestos en común y se decidirá cual se ajusta mejor a la apicación esperada y que elementos de dichos bocetos resultan más adecuados.
+Para ello se tendrá en cuenta la usabilidad y las necesidades de los difentes tipos de usuarios.
 
-.Form
-Keep the explanation of these key decisions short.
 
-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.
-****