diff --git a/docs/01_introduction_and_goals.adoc b/docs/01_introduction_and_goals.adoc index 7bba443..054e8f6 100644 --- a/docs/01_introduction_and_goals.adoc +++ b/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 -| __ | __ | __ -| __ | __ | __ +|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. |=== diff --git a/docs/02_architecture_constraints.adoc b/docs/02_architecture_constraints.adoc index d77b90e..fa38bb1 100644 --- a/docs/02_architecture_constraints.adoc +++ b/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. +|=== diff --git a/docs/03_system_scope_and_context.adoc b/docs/03_system_scope_and_context.adoc index 87e3464..ef6ccbe 100644 --- a/docs/03_system_scope_and_context.adoc +++ b/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. -**** - -**** - -**** - -=== 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. - -**** - -**** - -**** - -**** +**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. +|=== diff --git a/docs/04_solution_strategy.adoc b/docs/04_solution_strategy.adoc index 8f7872c..10b7ca9 100644 --- a/docs/04_solution_strategy.adoc +++ b/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. -**** diff --git a/docs/05_building_block_view.adoc b/docs/05_building_block_view.adoc index df24089..e155c71 100644 --- a/docs/05_building_block_view.adoc +++ b/docs/05_building_block_view.adoc @@ -3,204 +3,25 @@ == Building Block View -[role="arc42help"] -**** -.Content -The building block view shows the static decomposition of the system into building blocks (modules, components, subsystems, classes, -interfaces, packages, libraries, frameworks, layers, partitions, tiers, functions, macros, operations, -datas structures, ...) as well as their dependencies (relationships, associations, ...) +El código se descompone de manera estructurada por niveles, en los que se enseñan las dependencias internas de cada elemento. +El sistema se divide en Whitebox y Blackbox. -This view is mandatory for every architecture documentation. -In analogy to a house this is the _floor plan_. - -.Motivation -Maintain an overview of your source code by making its structure understandable through -abstraction. - -This allows you to communicate with your stakeholder on an abstract level without disclosing implementation details. - -.Form -The building block view is a hierarchical collection of black boxes and white boxes -(see figure below) and their descriptions. - -image:05_building_blocks-EN.png["Hierarchy of building blocks"] - -*Level 1* is the white box description of the overall system together with black -box descriptions of all contained building blocks. - -*Level 2* zooms into some building blocks of level 1. -Thus it contains the white box description of selected building blocks of level 1, together with black box descriptions of their internal building blocks. - -*Level 3* zooms into selected building blocks of level 2, and so on. -**** === Whitebox Overall System -[role="arc42help"] -**** -Here you describe the decomposition of the overall system using the following white box template. It contains - - * an overview diagram - * a motivation for the decomposition - * black box descriptions of the contained building blocks. For these we offer you alternatives: - - ** use _one_ table for a short and pragmatic overview of all contained building blocks and their interfaces - ** use a list of black box descriptions of the building blocks according to the black box template (see below). - Depending on your choice of tool this list could be sub-chapters (in text files), sub-pages (in a Wiki) or nested elements (in a modeling tool). - - - * (optional:) important interfaces, that are not explained in the black box templates of a building block, but are very important for understanding the white box. -Since there are so many ways to specify interfaces why do not provide a specific template for them. - In the worst case you have to specify and describe syntax, semantics, protocols, error handling, - restrictions, versions, qualities, necessary compatibilities and many things more. -In the best case you will get away with examples or simple signatures. - -**** - -_****_ - -Motivation:: - -__ - - -Contained Building Blocks:: -__ - -Important Interfaces:: -__ - -[role="arc42help"] -**** -Insert your explanations of black boxes from level 1: - -If you use tabular form you will only describe your black boxes with name and -responsibility according to the following schema: - -[cols="1,2" options="header"] +.Añadir el dibujo del whitebox +[options="header",cols="1,2"] |=== -| **Name** | **Responsibility** -| __ | __ -| __ | __ +|Actores | Descripción +| Cliente / Usuario | Es el que interactúa directamente con la aplicación y su interfaz de usuario. Cada uno tiene un POD en el cual se almacenan sus datos y al cual se puede acceder. +| Administrador | Tiene acceso al completo de la aplicación y puede administrarla para que funcione correctamente. |=== - - -If you use a list of black box descriptions then you fill in a separate black box template for every important building block . -Its headline is the name of the black box. -**** - - -==== - -[role="arc42help"] -**** -Here you describe -according the the following black box template: - -* Purpose/Responsibility -* Interface(s), when they are not extracted as separate paragraphs. This interfaces may include qualities and performance characteristics. -* (Optional) Quality-/Performance characteristics of the black box, e.g.availability, run time behavior, .... -* (Optional) directory/file location -* (Optional) Fulfilled requirements (if you need traceability to requirements). -* (Optional) Open issues/problems/risks - -**** - -__ - -__ - -_<(Optional) Quality/Performance Characteristics>_ - -_<(Optional) Directory/File Location>_ - -_<(Optional) Fulfilled Requirements>_ - -_<(optional) Open Issues/Problems/Risks>_ - - - - -==== - -__ - -==== - -__ - - -==== - -... - -==== - - - -=== Level 2 - -[role="arc42help"] -**** -Here you can specify the inner structure of (some) building blocks from level 1 as white boxes. - -You have to decide which building blocks of your system are important enough to justify such a detailed description. -Please prefer relevance over completeness. Specify important, surprising, risky, complex or volatile building blocks. -Leave out normal, simple, boring or standardized parts of your system -**** - -==== White Box __ - -[role="arc42help"] -**** -...describes the internal structure of _building block 1_. -**** - -__ - -==== White Box __ - - -__ - -... - -==== White Box __ - - -__ - - - -=== Level 3 - -[role="arc42help"] -**** -Here you can specify the inner structure of (some) building blocks from level 2 as white boxes. - -When you need more detailed levels of your architecture please copy this -part of arc42 for additional levels. -**** - - -==== White Box <_building block x.1_> - -[role="arc42help"] -**** -Specifies the internal structure of _building block x.1_. -**** - - -__ - - -==== White Box <_building block x.2_> - -__ - - - -==== White Box <_building block y.1_> - -__ +=== Blackbox Overall System +[options="header",cols="1,2"] +|=== +| Nombre | Descripción +| SOLID | Cada usuario tiene su POD y permite a la aplicación acceder a sus datos. +| Base de Datos | Provee a la aplicación de la información necesaria, ya sean los mapas o los puntos de interés. +| Interfaz de usuario | La interfaz con la que interactúa el usuario. +|=== \ No newline at end of file diff --git a/docs/06_runtime_view.adoc b/docs/06_runtime_view.adoc index 573d234..ce398ac 100644 --- a/docs/06_runtime_view.adoc +++ b/docs/06_runtime_view.adoc @@ -1,57 +1,62 @@ [[section-runtime-view]] -== Runtime View - - -[role="arc42help"] -**** -.Contents -The runtime view describes concrete behavior and interactions of the system’s building blocks in form of scenarios from the following areas: - -* important use cases or features: how do building blocks execute them? -* interactions at critical external interfaces: how do building blocks cooperate with users and neighboring systems? -* operation and administration: launch, start-up, stop -* error and exception scenarios - -Remark: The main criterion for the choice of possible scenarios (sequences, workflows) is their *architectural relevance*. It is *not* important to describe a large number of scenarios. You should rather document a representative selection. - -.Motivation -You should understand how (instances of) building blocks of your system perform their job and communicate at runtime. -You will mainly capture scenarios in your documentation to communicate your architecture to stakeholders that are less willing or able to read and understand the static models (building block view, deployment view). - -.Form -There are many notations for describing scenarios, e.g. - -* numbered list of steps (in natural language) -* activity diagrams or flow charts -* sequence diagrams -* BPMN or EPCs (event process chains) -* state machines -* ... - -**** +== Vista en tiempo de ejecución === +* Registro en aplicación +---- +actor Bob +participant Iomap +participant Pod +Bob -> Iomap: Bob pide registrarse +Iomap -> Pod: Redirecciona registro al proveedor del POD +Bob <-- Pod: Pide datos del registro +Bob -> Pod: Bob inserta sus datos +Iomap <-- Pod: Validación +Bob <-- Iomap: Confirmación registro +---- +=== + +* Inicio de sesión en aplicación -* __ -* __ +---- +actor Bob +participant Iomap +participant Pod +Bob -> Iomap: Bob pide iniciar sesión +Iomap -> Pod: Redirecciona al proveedor del POD +Bob <-- Pod: Pide datos del inicio de sesión +Bob -> Pod: Bob inserta sus datos +Iomap <-- Pod: Validación +Bob <-- Iomap: Confirmación inicio sesión +---- -It is possible to use a sequence diagram: +=== +* Busqueda de lugares mediante filtros (considerando que la sesión ya está iniciada) -[plantuml,"Sequence diagram",png] ---- -actor Alice actor Bob -database Pod as "Bob's Pod" -Alice -> Bob: Authentication Request -Bob --> Alice: Authentication Response -Alice --> Pod: Store route -Alice -> Bob: Another authentication Request -Alice <-- Bob: another authentication Response +participant Iomap +participant Pod +database DataBase as "DataBase" +Bob -> Iomap: Pulsa en filtro "Restaurantes" +Iomap-> DataBase: Pide la lista de restaurantes +DataBase --> Iomap: Devuelve la lista de restaurantes +Iomap-> Iomap: Muestra solo los restaurantes en el mapa ---- -=== -=== ... +=== +* Añadir nuevo lugar al mapa (considerando que la sesión ya está iniciada) -=== +---- +actor Bob +participant Iomap +participant Pod +database DataBase as "DataBase" +Bob -> Iomap: Pulsa en "Crear lugar" +Iomap-> Iomap: Bob es redireccionado a la vista de "Crear lugar" +Bob <-- Iomap: La aplicación pide los datos del lugar +Bob -> Iomap: Bob inserta los datos +Iomap --> DataBase: La aplicación añade el lugar a la base de datos +Bob <-- Iomap: Confirmación de datos añadidos correctamente +---- diff --git a/docs/07_deployment_view.adoc b/docs/07_deployment_view.adoc index 1088a09..2ddd417 100644 --- a/docs/07_deployment_view.adoc +++ b/docs/07_deployment_view.adoc @@ -1,86 +1,32 @@ [[section-deployment-view]] +== Vista de implementación +=== Infraestructura Nivel 1 +image:07_deployment_view.png["Deployment view de la aplicación"] -== Deployment View +La aplicación se encuentra alojada en un servidor web que interactúa con los diferentes clientes a traves del puerto 8081. Ademés, este servidor se nutre de la información almacenada dentro de una base de datos MongoDB alojada en un servidor en la nube. También obtiene la información de los usuarios a traves de los PODs de SOLID que se encuentran en nuestro caso dentro del provedor de SOLID Inrupt. -[role="arc42help"] -**** -.Content -The deployment view describes: +=== Infraestructura Nivel 2 +==== Web App +La Web APP es la que se comunica con los distintos clientes de usuario a traves del puerto 3000. Esta proporciona vistas HTML 5 con JavaScript con las que el usuario podrá interactuar desde su navegador. Además desde la propia WebAPP se conectará con lo PODs de los usuarios para permitir el acceso y permitir la visualización de los mapas. - 1. the technical infrastructure used to execute your system, with infrastructure elements like geographical locations, environments, computers, processors, channels and net topologies as well as other infrastructure elements and +==== REST API +La REST API nutre de información a la Web App por medio de los distintos endpoints que proporciona. La API se encuentra alojada en el puerto 5000. Además, la información que proporciona la obtiene de la BBDD MongoDB alojada en la nube. -2. the mapping of (software) building blocks to that infrastructure elements. +==== PODs SOLID +Los PODs almacenan la información de los usuarios y se encuentran dentro de los servidores de Inrupt en la nube, que sirve PODs de SOLID. -Often systems are executed in different environments, e.g. development environment, test environment, production environment. In such cases you should document all relevant environments. +==== MongoDB +La base de datos se encuentra alojada en los propios servidores que proporciona MongoDB en la nube exactamente se encuentra en (Poner la máquina de AWS que almacena la BBDD) -Especially document the deployment view when your software is executed as distributed system with more then one computer, processor, server or container or when you design and construct your own hardware processors and chips. +=== Aspectos de calidad y rendimiento +Se espera que los componentes de la LoMap proporcionen los siguientes aspectos de calidad y de rendimiento en cuanto a los tiempos de respuesta y a la disponibilidad de los distintos elementos -From a software perspective it is sufficient to capture those elements of the infrastructure that are needed to show the deployment of your building blocks. Hardware architects can go beyond that and describe the infrastructure to any level of detail they need to capture. - -.Motivation -Software does not run without hardware. -This underlying infrastructure can and will influence your system and/or some -cross-cutting concepts. Therefore, you need to know the infrastructure. - -.Form - -Maybe the highest level deployment diagram is already contained in section 3.2. as -technical context with your own infrastructure as ONE black box. In this section you will -zoom into this black box using additional deployment diagrams: - -* UML offers deployment diagrams to express that view. Use it, probably with nested diagrams, -when your infrastructure is more complex. -* When your (hardware) stakeholders prefer other kinds of diagrams rather than the deployment diagram, let them use any kind that is able to show nodes and channels of the infrastructure. -**** - -=== Infrastructure Level 1 - -[role="arc42help"] -**** -Describe (usually in a combination of diagrams, tables, and text): - -* the distribution of your system to multiple locations, environments, computers, processors, .. as well as the physical connections between them -* important justification or motivation for this deployment structure -* Quality and/or performance features of the infrastructure -* the mapping of software artifacts to elements of the infrastructure - -For multiple environments or alternative deployments please copy that section of arc42 for all relevant environments. -**** - -_****_ - -Motivation:: - -__ - -Quality and/or Performance Features:: - -__ - -Mapping of Building Blocks to Infrastructure:: -__ - - -=== Infrastructure Level 2 - -[role="arc42help"] -**** -Here you can include the internal structure of (some) infrastructure elements from level 1. - -Please copy the structure from level 1 for each selected element. -**** - -==== __ - -__ - -==== __ - -__ - -... - -==== __ - -__ +[options="header", cols="1,1,1"] +|=== +| Dispositivo | Tiempo de respuesta | Disponibilidad +| Web App | Poco tiempo de respuesta | Alta +| REST API | Tiempo medio de respuesta | Alta +| MongoDB | Especificado por el proveedor | Especificado por el proveedor +| PODs Solid | Especificado por Inrupt | Especificado por Inrupt +|=== diff --git a/docs/08_concepts.adoc b/docs/08_concepts.adoc index 569ac0e..fd3a786 100644 --- a/docs/08_concepts.adoc +++ b/docs/08_concepts.adoc @@ -1,67 +1,20 @@ [[section-concepts]] -== Cross-cutting Concepts +== Conceptos transversales +=== Persistencia +Los datos de los usuarios serán almacenados, de manera que cada usuario conservará la información que hayan creado sobre un lugar de manera descentralizada. -[role="arc42help"] -**** -.Content -This section describes overall, principal regulations and solution ideas that are -relevant in multiple parts (= cross-cutting) of your system. -Such concepts are often related to multiple building blocks. -They can include many different topics, such as +=== Usuarios y su privacidad +Las contraseñas e información sensible no sera almacenada en una base de datos para mayor seguridad. En cambio, se optará por almacenar dicha información en un pod personal de cada usuario siguiendo los principios SOLID. -* domain models -* architecture patterns or design patterns -* rules for using specific technology -* principal, often technical decisions of overall decisions -* implementation rules +=== Interfaz de Usuario +Para la interfaz gráfica se usará el framework React, teniendo como base los diseños aceptados y creados por los miembros del equipo. -.Motivation -Concepts form the basis for _conceptual integrity_ (consistency, homogeneity) -of the architecture. Thus, they are an important contribution to achieve inner qualities of your system. +=== Manejo de Sesión +Para el inicio de la sesión será necesario estar registrado previamente o deberá registrarse. La información almacenada por el usuario solo será accesible por este a través de su pod y siguiendo los principios SOLID. -Some of these concepts cannot be assigned to individual building blocks -(e.g. security or safety). This is the place in the template that we provided for a -cohesive specification of such concepts. +=== Testeable +Para añadir una funcionalidad o característica deberá ser probada adecuadamente con anterioridad. Con esto en mente se deberán realizar tanto pruebas unitarias, para comprobar el correcto funcionamiento del código, como pruebas relacionadas con la usabilidad. -.Form -The form can be varied: - -* concept papers with any kind of structure -* cross-cutting model excerpts or scenarios using notations of the architecture views -* sample implementations, especially for technical concepts -* reference to typical usage of standard frameworks (e.g. using Hibernate for object/relational mapping) - -.Structure -A potential (but not mandatory) structure for this section could be: - -* Domain concepts -* User Experience concepts (UX) -* Safety and security concepts -* Architecture and design patterns -* "Under-the-hood" -* development concepts -* operational concepts - -Note: it might be difficult to assign individual concepts to one specific topic -on this list. - -image:08-Crosscutting-Concepts-Structure-EN.png["Possible topics for crosscutting concepts"] -**** - - -=== Domain model - -image:UmlDiagram.png["Example UML Diagram"] - - - -=== __ - -__ - -... - -=== __ - -__ +=== Modelo de dominio +Concepto inicial del modelo de dominio, altamente sujeto a cambios y ampliaciones. diff --git a/docs/09_design_decisions.adoc b/docs/09_design_decisions.adoc index 5536888..de28178 100644 --- a/docs/09_design_decisions.adoc +++ b/docs/09_design_decisions.adoc @@ -1,26 +1,13 @@ [[section-design-decisions]] == Design Decisions - -[role="arc42help"] -**** -.Contents -Important, expensive, large scale or risky architecture decisions including rationals. -With "decisions" we mean selecting one alternative based on given criteria. - -Please use your judgement to decide whether an architectural decision should be documented -here in this central section or whether you better document it locally -(e.g. within the white box template of one building block). - -Avoid redundancy. Refer to section 4, where you already captured the most important decisions of your architecture. - -.Motivation -Stakeholders of your system should be able to comprehend and retrace your decisions. - -.Form -Various options: - -* List or table, ordered by importance and consequences or: -* more detailed in form of separate sections per decision -* ADR (architecture decision record) for every important decision -**** +[options="header",cols="1,2,2"] +|=== +|Nombre|Problema|Decisión +| POD | La aplicación necesita acceder a información del usuario de una manera descentralizada. | Cada usuario debe tener su propio POD con información del mismo y al iniciar la aplicación le dará permiso a la misma para usar su información guardada. +| DB | Se piensa en cómo guardar información general de la aplicación y se piensa en usar una base de datos. | POR DECIDIR ESTE APARTADO +| Frontend | Se necesita decidir el lenguaje a usar en frontend | Se usará React, ya que su posibilidad con los componentes es realmente buena. +| Backend | Se necesita decidir el lenguaje a usar en backend | Se usarán Node.js y Express.js. +| Documentación | Se necesita decidir el lenguaje a usar en la documentación | Se usará Asciidoc, se pensó en usar Markdown, pero por evitar posibles problemas de compatibilidad se decide usar Asciidoc. +| Reuniones | El grupo tiene que decidir como repartir el trabajo o solucionar problemas | Previo a las clases de laboratorio, cada miembro propondrá temas a tratar en cada reunión mediante Issues en el repositorio en Github. Una vez reunidos, si durante la semana fuera necesario, se reune otra vez el grupo y quedará constancia de ello. +|=== \ No newline at end of file diff --git a/docs/10_quality_scenarios.adoc b/docs/10_quality_scenarios.adoc index a19dedf..6995bd6 100644 --- a/docs/10_quality_scenarios.adoc +++ b/docs/10_quality_scenarios.adoc @@ -1,63 +1,19 @@ [[section-quality-scenarios]] -== Quality Requirements +== Requisitos de calidad +=== Árbol de calidad -[role="arc42help"] -**** +image::arbolDeCalidad.png["Example UML Diagram"] -.Content -This section contains all quality requirements as quality tree with scenarios. The most important ones have already been described in section 1.2. (quality goals) +=== Escenarios de calidad +[options="header"] +|================================================================================== +|Id |Atributo de calidad |Escenario de calidad +|US1 |Usabilidad |La navegación por la aplicación debe de ser sencilla, permitiendo a los usuarios diferenciar claramente las diferentes opciones. +|COM1 |Comprensibilidad |La aplicación debe ser sencilla de usar para todos los usuarios independientemente de su nivel de experiencia o posibles dificultades como discapacidades visuales. +|SEG1 |Seguridad |Los datos de los usuarios estarán protegidos y no será posible el acceso por parte de terceros. +|TEST1 |Testabilidad |Se documentará la funcionalidad de las diferentes partes de la aplicación en su código con la finalidad de poder ser modificado y testeado por los diferentes miembros del equipo. +|TEST2 |Testabilidad |Antes de de añadir una funcionalidad, ésta debe ser probada, ya sea con pruebas unitarias o pruebas de usabilidad. +|================================================================================== -Here you can also capture quality requirements with lesser priority, -which will not create high risks when they are not fully achieved. -.Motivation -Since quality requirements will have a lot of influence on architectural -decisions you should know for every stakeholder what is really important to them, -concrete and measurable. -**** - -=== Quality Tree - -[role="arc42help"] -**** -.Content -The quality tree (as defined in ATAM – Architecture Tradeoff Analysis Method) with quality/evaluation scenarios as leafs. - -.Motivation -The tree structure with priorities provides an overview for a sometimes large number of quality requirements. - -.Form -The quality tree is a high-level overview of the quality goals and requirements: - -* tree-like refinement of the term "quality". Use "quality" or "usefulness" as a root -* a mind map with quality categories as main branches - -In any case the tree should include links to the scenarios of the following section. -**** - -=== Quality Scenarios - -[role="arc42help"] -**** -.Contents -Concretization of (sometimes vague or implicit) quality requirements using (quality) scenarios. - -These scenarios describe what should happen when a stimulus arrives at the system. - -For architects, two kinds of scenarios are important: - -* Usage scenarios (also called application scenarios or use case scenarios) describe the system’s runtime reaction to a certain stimulus. This also includes scenarios that describe the system’s efficiency or performance. Example: The system reacts to a user’s request within one second. -* Change scenarios describe a modification of the system or of its immediate environment. Example: Additional functionality is implemented or requirements for a quality attribute change. - -.Motivation -Scenarios make quality requirements concrete and allow to -more easily measure or decide whether they are fulfilled. - -Especially when you want to assess your architecture using methods like -ATAM you need to describe your quality goals (from section 1.2) -more precisely down to a level of scenarios that can be discussed and evaluated. - -.Form -Tabular or free form text. -**** diff --git a/docs/11_technical_risks.adoc b/docs/11_technical_risks.adoc index c52fb74..efa7220 100644 --- a/docs/11_technical_risks.adoc +++ b/docs/11_technical_risks.adoc @@ -1,17 +1,22 @@ [[section-technical-risks]] -== Risks and Technical Debts +== Riesgos y deudas técnicas +[cols="1,1"] +|=== +|Riesgo |Explicación -[role="arc42help"] -**** -.Contents -A list of identified technical risks or technical debts, ordered by priority +|Desconocimiento de REACT +|Es la primera vez que trabajamos con este framework. -.Motivation -“Risk management is project management for grown-ups” (Tim Lister, Atlantic Systems Guild.) +|Desconocimiento de Node.js +|Es la primera vez que trabajamos con ello. Lo estamos usando también en otra asignatura, lo cual nos beneficiara para entenderlo. -This should be your motto for systematic detection and evaluation of risks and technical debts in the architecture, which will be needed by management stakeholders (e.g. project managers, product owners) as part of the overall risk analysis and measurement planning. +|Uso de POD's +|No conocemos el funcionamiento de estos. -.Form -List of risks and/or technical debts, probably including suggested measures to minimize, mitigate or avoid risks or reduce technical debts. -**** +|Equipos +|No estamos muy familiarizados con los trabajos en equipo y puede que nos sea dificil coordinarnos. + +|Github +|Todos lo hemos usado ya y sabemos más o menos el funcionamiento, pero hay caracteristicas que son nuevas para nosotros y estamos aprendiendo a utilizar. +|=== diff --git a/docs/12_glossary.adoc b/docs/12_glossary.adoc index 01e71be..8abff20 100644 --- a/docs/12_glossary.adoc +++ b/docs/12_glossary.adoc @@ -1,31 +1,29 @@ [[section-glossary]] == Glossary +[options="header"] +|=== +| Termino | Definición +| REACT +| Biblioteca de JavaScript para construir interfaces de usuario -[role="arc42help"] -**** -.Contents -The most important domain and technical terms that your stakeholders use when discussing the system. - -You can also see the glossary as source for translations if you work in multi-language teams. +| Principios SOLID +| Single Responsibility, Open-Close Principle, Liskov Substitution, Interface Segregation Principle, Dependency Inversion Principle -.Motivation -You should clearly define your terms, so that all stakeholders +| AsciiDoc +| Lenguaje de marcado de texto sin formato para escribir contenido técnico. -* have an identical understanding of these terms -* do not use synonyms and homonyms +| GitHub +| Portal creado para alojar el código de las aplicaciones de cualquier desarrollador -.Form -A table with columns and . +| Node.js +| Entorno de tiempo de ejecución de JavaScript -Potentially more columns in case you need translations. +| Express +| Es el framework web más popular de Node -**** +| POD +| Contenedor, en el que se presenta un conjunto de datos al usuario. -[options="header"] -|=== -| Term | Definition -| | -| | |=== diff --git a/docs/Documentacion b/docs/Documentacion new file mode 100644 index 0000000..4bb9695 --- /dev/null +++ b/docs/Documentacion @@ -0,0 +1,28 @@ += Estrategia de solución + +* Base de datos: TBD. + +* 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. + +* 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. + +* 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. + + diff --git a/docs/images/03_business_context.png b/docs/images/03_business_context.png new file mode 100644 index 0000000..cd5e02e Binary files /dev/null and b/docs/images/03_business_context.png differ diff --git a/docs/images/03_technical_context.png b/docs/images/03_technical_context.png new file mode 100644 index 0000000..0de27db Binary files /dev/null and b/docs/images/03_technical_context.png differ diff --git a/docs/images/07_deployment_view.png b/docs/images/07_deployment_view.png new file mode 100644 index 0000000..ac0b39c Binary files /dev/null and b/docs/images/07_deployment_view.png differ diff --git a/docs/images/Modelo de dominio.png b/docs/images/Modelo de dominio.png new file mode 100644 index 0000000..4098fc2 Binary files /dev/null and b/docs/images/Modelo de dominio.png differ diff --git a/docs/images/arbolDeCalidad.png b/docs/images/arbolDeCalidad.png new file mode 100644 index 0000000..dcffeb1 Binary files /dev/null and b/docs/images/arbolDeCalidad.png differ