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, data structures, …) as well as their dependencies (relationships, associations, …)
-This view is mandatory for every architecture documentation. -In analogy to a house this is the floor plan.
-Maintain an overview of your source code by making its structure understandable through -abstraction.
+The designed website is composed of a frontend in React, a backend in Node.js and is documented using Asciidoc. Each user will have their own account where their information will be saved. Design-related decisions are detailed in point 9.
This allows you to communicate with your stakeholder on an abstract level without disclosing implementation details.
4.2. Security
The building block view is a hierarchical collection of black boxes and white boxes -(see figure below) and their descriptions.
-
+We guarantee the safety of the user
4.3. Testability
Level 1 is the white box description of the overall system together with black -box descriptions of all contained building blocks.
+Tests will be carried out for each individual part of the application, thus ensuring the correct operation of the different modules both individually and together.
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.
4.4. Interface
Level 3 zooms into selected building blocks of level 2, and so on.
+The graphical interface will be chosen among all the members of the team, each one contributing a sketch or idea, which will be shared and it will be decided which best fits the expected performance and which elements of these sketches are most suitable. +This will take into account the usability and needs of different types of users.
See Building Block View in the arc42 documentation.
+5. Building Block View
+5.1. Whitebox Overall System
- -<Overview Diagram>
--
-
- Motivation -
-
-
<text explanation>
-
- - Contained Building Blocks -
-
-
<Description of contained building block (black boxes)>
-
- - Important Interfaces -
-
-
<Description of important interfaces>
-
-
The code is broken down in a structured way by levels, in which the internal dependencies of each element are taught. The system is divided into Whitebox and Blackbox.
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:
| Name | -Responsibility | +Actors |
+Description |
|---|---|---|---|
<black box 1> |
-<Text> |
+Admin |
+You have access to the entire app and can manage it to make it work properly. |
<black box 2> |
-<Text> |
+User |
+It’s the one that interacts directly with the app. |
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.
-5.1.1. <Name black box 1>
- -<Purpose/Responsibility>
-<Interface(s)>
-<(Optional) Quality/Performance Characteristics>
-<(Optional) Directory/File Location>
-<(Optional) Fulfilled Requirements>
-<(optional) Open Issues/Problems/Risks>
-5.1.2. <Name black box 2>
-<black box template>
-5.1.3. <Name black box n>
-<black box template>
-5.1.4. <Name interface 1>
-…
-5.1.5. <Name interface m>
- -5.2. Level 2
- -5.2.1. White Box <building block 1>
- -<white box template>
-5.2.2. White Box <building block 2>
-<white box template>
-…
-5.2.3. White Box <building block m>
-<white box template>
-5.2. Blackbox Overall System
+Name |
+Description |
+
Interface |
+The interface with which the user interacts |
+
WikiData |
+Provide the questions that will be used in the app |
+
MongoDB |
+Store user data |
+
5.3. Level 3
- -5.3.1. White Box <_building block x.1_>
- -5.3.2. White Box <_building block x.2_>
-<white box template>
+
5.3.3. White Box <_building block y.1_>
<white box template>
+In this diagram we can see the decided microservices that will provide all the operations necessary for the +application to work properly.
Name |
+Description |
+
Game Service |
+It is the microservice that will be in charge of the correct functioning of the game and calculate the user’s score. |
+
UserData Service |
+It is the microservice that provides the necessary user data. |
+
Authetification Service |
+It’s a microservice that users use to sign in to your app. |
+
Question Service |
+It is the microservice that will generate the questions through the WikiData API. |
+
6. Runtime View
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.
-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).
-6.1. <The user plays>
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
-
- -
-
…
-
-
The user starts a game, and the game uses the questions service to run it.
6.1. <Runtime Scenario 1>
--
-
-
-
<insert runtime diagram or textual description of the scenario>
-
- -
-
<insert description of the notable aspects of the interactions between the -building block instances depicted in this diagram.>
-
-
6.2. <The user looks at their history>
It is possible to use a sequence diagram:
+The user checks their scores and statistics.
+
6.2. <Runtime Scenario 2>
- -6.3. …
- -6.4. <Runtime Scenario n>
7.1. Infrastructure Level 1
- Motivation
-
-
<Simple structure of how the different parts of the application would work>
-
- - Quality and/or Performance Features -
-
-
<We will have a link to wikidata that will be where we get the different questions, in addition a registration and persistence layer of user and registration data, finally they will be united in the link layer and this will be the one that is directly related to the application>
-
- - Mapping of Building Blocks to Infrastructure -
-
-
<Quiestion Generator: give us the questions posible answers - User service: All the options that users needs - Register: create new acounts or login with one>
+As we can see, this would be the initial diagram of how the classes would relate to each other. We have, in the first place, the 'app' class that is related to 'link', which in turn is related to the different parts of the app.
7.2. Infrastructure Level 2
7.2.1. <Infrastructure Element 1>
+7.2.1. APP
<diagram + explanation>
+"App": It is the part with which the user interacts. This part would be responsible for providing the visual interface and using the rest of the created classes.
7.2.2. <Infrastructure Element 2>
+7.2.2. LINK
<diagram + explanation>
+"Link" is the part of the application that connects the rest of the parts. This will facilitate the use of the different parts of the application in the App section.
7.2.3. REGISTER
…
+"Register" is the part of the application that handles user registration and login. It’s very important as it’s the first thing a potential user will encounter when they visit our page.
7.2.3. <Infrastructure Element n>
+7.2.4. USER SERVICE
<diagram + explanation>
+"User service" is the part of the application that generates the various services within the application to the user, such as a ranking, correctly answered questions, and so on.
+7.2.5. QUESTION GENERATOR
+"Question generator" is the part of the application that, using the data from Wikidata and some pre-created templates, generates the questions and possible answers of the application.
+7.2.6. WIKIDATA
+Wikidata” is the API that you will use to obtain the data for the questions. Wikidata is a free and collaborative database that can be read and edited by both humans and machines. It provides a common source of certain types of data that can be used by Wikimedia projects.
8. Cross-cutting Concepts
8.1. <User Interface >
+8.1. User Interface
<A user interface is the space where a human and a computer or device communicate and exchange information.>
+A user interface is the space where a human and a computer or device communicate and exchange information
8.2. <Ergonomics >
+8.2. <Ergonomics >
<Ergonomics is the science of designing and arranging workplaces, products, and systems to fit and adapt to the people who use them. Ergonomics aims to improve comfort, efficiency, and safety by considering human physical and psychological needs and limitations. >
+Ergonomics is the science of designing and arranging workplaces, products, and systems to fit and adapt to the people who use them. Ergonomics aims to improve comfort, efficiency, and safety by considering human physical and psychological needs and limitations.
8.3. <Internationalization >
+8.3. Internationalization
<Internationalization is the practice of designing and developing applications that can support multiple languages, formats, and conventions>
+Internationalization is the practice of designing and developing applications that can support multiple languages, formats, and conventions
8.4. <Security >
+8.4. Security
<Security is a broad term that can refer to different aspects of protection, resilience, or prevention of harm. >
+Security is a broad term that can refer to different aspects of protection, resilience, or prevention of harm.
8.5. <Safety >
+8.5. Safety
<Is the state of being protected from danger or harm.>
+Is the state of being protected from danger or harm.
8.6. <Build, Test, Deploy >
-← Build: This stage involves compiling, validating, and packaging the source code into executable or deployable artifacts. -- Test: This stage involves running various tests, such as unit tests, integration tests, and regression tests, to ensure the quality and functionality of the software. -- Deploy: This stage involves delivering or releasing the software to the target environment, such as a server, a cloud platform, or a user device. >
-8.7. <Code Generation >
-<Code generation is the process of creating executable or deployable code from various sources of information, such as natural language, images, or other code.>
+8.6. Build, Test, Deploy
+-
+
-
+
Build: This stage involves compiling, validating, and packaging the source code into executable or deployable artifacts.
+
+ -
+
Test: This stage involves running various tests, such as unit tests, integration tests, and regression tests, to ensure the quality and functionality of the software.
+
+ -
+
Deploy: This stage involves delivering or releasing the software to the target environment, such as a server, a cloud platform, or a user device.
+
+
8.8. <Migration >
+8.7. Code Generation
<Migrating from one software application or platform to another, such as switching from a legacy system to a modern one, or from a local server to a cloud service.>
+Code generation is the process of creating executable or deployable code from various sources of information, such as natural language, images, or other code.
8.9. <Configurability >
+8.8. Migration
<Configurability is the ability to modify or customize something, especially in computing, electronics, or de>
+Migrating from one software application or platform to another, such as switching from a legacy system to a modern one, or from a local server to a cloud service.
8.10. <Administration >
+8.9. Configurability
<The process or activity of managing, directing, or organizing something or someone>
+Configurability is the ability to modify or customize something, especially in computing, electronics, or devices
8.11. <Management >
+8.10. Administration
<Management is the process of organizing and directing the resources of a business or organization to achieve its goals. >
+The process or activity of managing, directing, or organizing something or someone
8.12. <Disaster-Recovery >
+8.11. Management
<Is the process of restoring the functionality and data of software applications after a disaster, such as a natural calamity, a cyberattack, or a human error.>
+Management is the process of organizing and directing the resources of a business or organization to achieve its goals.
8.13. <Architecture and design patterns >
+8.12. Disaster-Recovery
<Architecture and design patterns are concepts that help software developers and architects design and build software systems that are efficient, scalable, and maintainable>
+Is the process of restoring the functionality and data of software applications after a disaster, such as a natural calamity, a cyberattack, or a human error.
8.14. <Concept >
+8.13. Architecture and design patterns
<explanation>
+Architecture and design patterns are concepts that help software developers and architects design and build software systems that are efficient, scalable, and maintainable