First version of the building block

docs/05_building_block_view.adoc

@@ -3,204 +3,41 @@
 
 == 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, ...)
+The LoMap application is mainly divided into two modules with very differentiated behaviour: the WebAPP and the RestAPI. Each of the modules has several components, focused in smaller functionalities.
 
-This view is mandatory for every architecture documentation.
-In analogy to a house this is the _floor plan_.
+=== Black box view
 
-.Motivation
-Maintain an overview of your source code by making its structure understandable through
-abstraction.
+==== Level 1
+The LoMap application is divided into two modules, each of which interact with different external services.
 
-This allows you to communicate with your stakeholder on an abstract level without disclosing implementation details.
+image:5-BuildingBlock/BuildingBlockLvl1.drawio.png["Building block level 1"]
 
-.Form
-The building block view is a hierarchical collection of black boxes and white boxes
-(see figure below) and their descriptions.
+.WebApp
+The web app is the module responsible for managing the communication with the user. It will manage the GUI by means of different views, some of which will access an external API to implement a visual map. It will communicate with the Rest API (described later on) with http requests.
 
-image:05_building_blocks-EN.png["Hierarchy of building blocks"]
+At this point of development, we have decided that this component will also be responsible to communicate the application with the user POD to manage operations such as the login and potentially more stored data, although this decision could change during the development process.
 
-*Level 1* is the white box description of the overall system together with black
-box descriptions of all contained building blocks.
+.RestAPI
+The rest API will manage the business logic and access to the information stored in the database. At this point of development, we are also exploring the option of accessing the data stored in the PODs from this component.
 
-*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.
+It will receive the petitions of the web app (described before), process them, access the necessary information and return a response in form of data.
 
-*Level 3* zooms into selected building blocks of level 2, and so on.
-****
 
-=== Whitebox Overall System
+==== Level 2
 
-[role="arc42help"]
-****
-Here you describe the decomposition of the overall system using the following white box template. It contains
+Each of the previously mentioned modules is divided into smaller components, whose behaviour is described in this section.
 
- * an overview diagram
- * a motivation for the decomposition
- * black box descriptions of the contained building blocks. For these we offer you alternatives:
+image:5-BuildingBlock/BuildingBlockLvl2.drawio.png["Building block level 2"]
 
-   ** 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).
+.Views
+Component responsible for rendering the GUI.
 
+.Solid access
+Component in charge of accessing the user solid POD. Right now this component is in the Web App module, but it could change during the development of the project.
 
- * (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.
 
-****
+.Facade
+Component in charge of receiving the petitions and manage them. Responsible for the business logic.
 
-_**<Overview Diagram>**_
-
-Motivation::
-
-_<text explanation>_
-
-
-Contained Building Blocks::
-_<Description of contained building block (black boxes)>_
-
-Important Interfaces::
-_<Description of 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"]
-|===
-| **Name** | **Responsibility**
-| _<black box 1>_ | _<Text>_
-| _<black box 2>_ | _<Text>_
-|===
-
-
-
-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.
-****
-
-
-==== <Name black box 1>
-
-[role="arc42help"]
-****
-Here you describe <black box 1>
-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
-
-****
-
-_<Purpose/Responsibility>_
-
-_<Interface(s)>_
-
-_<(Optional) Quality/Performance Characteristics>_
-
-_<(Optional) Directory/File Location>_
-
-_<(Optional) Fulfilled Requirements>_
-
-_<(optional) Open Issues/Problems/Risks>_
-
-
-
-
-==== <Name black box 2>
-
-_<black box template>_
-
-==== <Name black box n>
-
-_<black box template>_
-
-
-==== <Name interface 1>
-
-...
-
-==== <Name interface m>
-
-
-
-=== 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 _<building block 1>_
-
-[role="arc42help"]
-****
-...describes the internal structure of _building block 1_.
-****
-
-_<white box template>_
-
-==== White Box _<building block 2>_
-
-
-_<white box template>_
-
-...
-
-==== White Box _<building block m>_
-
-
-_<white box template>_
-
-
-
-=== 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 template>_
-
-
-==== White Box <_building block x.2_>
-
-_<white box template>_
-
-
-
-==== White Box <_building block y.1_>
-
-_<white box template>_
+.DB access
+Component in charge of accessing the database. Reads, stores, updates and deletes information.