Merge pull request #22 from Arquisoft/develop

Develop

docs/04_solution_strategy.adoc

@@ -1,6 +1,17 @@
 [[section-solution-strategy]]
 == Solution Strategy
 
+Hemos tomado varias decisions para solucionar los distintos problemas respecto al diseño de la aplicación. Estas son:
+
+- SOLID. Utilizaremos SOLID como método de almacenar la información de los usuarios con una gran privacidad.
+
+- React y TypeScript. Como lenguaje para el diseño de la aplicación.
+
+- Github. Como método de control y copia del proyecto.
+
+- MVC. Utilizaremos un diseño de modelo-vista-controlador para el desarrollo de la aplicación y comunicación entre sus capas.
+
+- MongoDB. Utilizaremos MongoDB como base de datos para almacenar determinada información.
 
 [role="arc42help"]
 ****

docs/06_runtime_view.adoc

@@ -54,6 +54,36 @@ Alice <-- Bob: another authentication Response
 === Cargar mapa
 image:cargarMapa.png["Upload map"]
 *_El usuario iniciará sesión y automáticamente se cargará el mapa, para ello tiene que llamar a la clase principal y que esta escoja el mapa deseado_
-=== ...
+
+=== Añadir un amigo
+En este caso de uso podemos observar el flujo seguido para añadir a un amigo nuestro pod de SOLID
+[plantuml,Añadir amigo,png]
+
+=== Eliminar un amigo
+image:DiagramaEA_06.png["Eliminar amigo"]
+----
+@startuml
+autonumber
+
+actor User as user
+participant "loMap" as loMap
+database "Solid POD" as pod
+
+user -> loMap : AñadirAmigo()
+user <- loMap: listaAmigos()
+user -> loMap : IntroducePodId()
+loMap -> pod: buscaPodId()
+loMap <- pod: AñadeAmigoId()
+user <- loMap : listaAmigos()
+alt Id de amigo no encontrado
+    loMap <- pod: noExisteId()
+    user <- loMap : listaAmigos()
+else amigo ya añadido
+     loMap <- pod: amigoYaAñadido()
+    user <- loMap : listaAmigos()
+end
+@enduml
+----
+
 
 === <Runtime Scenario n>

docs/07_deployment_view.adoc

@@ -3,6 +3,8 @@
 
 == Deployment View
 
+La estructura del proyecto se basa en varias estructuras que operan y se comunican entre si para funcionar correctamente.
+
 [role="arc42help"]
 ****
 .Content
@@ -36,6 +38,10 @@ when your infrastructure is more complex.
 
 === Infrastructure Level 1
 
+La infraestructura de nivel 1 está compuesta de tres partes. La parte de la aplicación web desde el cual el usuario opera, y que se comunica con las otras partes. La base de datos donde se almacena información de la aplicación. El servidor de pods, donde el usuario tiene guardada su información y al cual se llama para pedir datos y guardar datos privados del usuario.
+
+image:infraestructura1.png["infraestructura 1"]
+
 [role="arc42help"]
 ****
 Describe (usually in a combination of diagrams, tables, and text):
@@ -64,6 +70,10 @@ _<description of the mapping>_
 
 === Infrastructure Level 2
 
+Dentro de la infraestructura de nivel 2 podemos entrar en la composición del servidor de pods, el cual está compuesto de muchos pods, uno para cada usuario que tenga información almacenada en ese lugar.
+
+image:infraestructura2.png["infraestructura 2"]
+
 [role="arc42help"]
 ****
 Here you can include the internal structure of (some) infrastructure elements from level 1.

docs/08_concepts.adoc

@@ -52,7 +52,7 @@ image:08-Crosscutting-Concepts-Structure-EN.png["Possible topics for crosscuttin
 
 === Domain model
 
-image:UmlDiagram.png["Example UML Diagram"]
+image:08_domain_model.png["Diagrama de Modelo"]
 
 
 

docs/10_quality_scenarios.adoc

@@ -35,9 +35,29 @@ The quality tree is a high-level overview of the quality goals and requirements:
 
 In any case the tree should include links to the scenarios of the following section.
 ****
+En la siguiente imagen podemos observar los requisitos de calidad que tendra nuestra aplicación LoMap.
+
+image::quality.svg["Árbol de requisitos de calidad"]
 
 === Quality Scenarios
 
+En la siguiente tabla podemos ver la aplicabilidad de los requisitos de calidad previmaente definidos,estos han sido analizados minuciosamente para proporcionar calidad a nuestro desarollo
+
+Escenarios:
+[options="header",cols=".^1,.^1,.^1,.^1"]
+|===
+|Requisito de calidad |Aplicabilidad | Necesidades tenidas en cuenta | Priorización
+|Mantenibilidad| Con el fin de desarollar una aplicación flexible a los cambios|Añadir una nueva funcionalidad| 3
+|Usabilidad|Creación de una aplicación inclusiva , haciendo su uso asequible a usuarios sin pericia informática o con cualquier tipo de discapacidad  |Cumplir unos mínimos requisitos para facilitar el uso de cualquier usario| 5
+|Interoperabilidad | Creación de un modelo de datos común para toda las asignatura, por lo que la aplicación tendra la posibilidad de comunicarse entre diferentes sistemas | Abierta a futuros desarollos | 4
+|Privacidad| Garantizar la privacidad de nuestros usuarios, para ello usaremos el pod de SOLID| No almacenaremos datos de terceros, y en el caso de ser indispinsable se  notificará al usuario y se guardará solamente la información imprescindible|5
+|Descentralización| Estrachamente ligado con la privacidad, el suaurio decidirá que infomración compartira |Proporcionar al usuario la capacidad de decidir sobre sus datos en todo momento| 5
+|Diseño limpio| Ligado con la mantenibilidad, un código limpio nos proporciona flexibilidad, reutilización de código |Código abierto al cambio| 4|
+
+
+
+|===
+
 [role="arc42help"]
 ****
 .Contents