diff --git a/images/10-Quality_Tree.png b/images/10-Quality_Tree.png new file mode 100644 index 00000000..0e0ee967 Binary files /dev/null and b/images/10-Quality_Tree.png differ diff --git a/images/Sequence diagram.png b/images/Sequence diagram.png deleted file mode 100644 index 3f560336..00000000 Binary files a/images/Sequence diagram.png and /dev/null differ diff --git a/images/context.png b/images/context.png new file mode 100644 index 00000000..4313a20a Binary files /dev/null and b/images/context.png differ diff --git a/images/deployment.png b/images/deployment.png new file mode 100644 index 00000000..d2170bbb Binary files /dev/null and b/images/deployment.png differ diff --git a/images/level1.png b/images/level1.png new file mode 100644 index 00000000..9260e859 Binary files /dev/null and b/images/level1.png differ diff --git a/images/level2.png b/images/level2.png new file mode 100644 index 00000000..ab5c807c Binary files /dev/null and b/images/level2.png differ diff --git a/images/level3.png b/images/level3.png new file mode 100644 index 00000000..32ce031e Binary files /dev/null and b/images/level3.png differ diff --git a/images/sequencediagram-game.png b/images/sequencediagram-game.png new file mode 100644 index 00000000..74837802 Binary files /dev/null and b/images/sequencediagram-game.png differ diff --git a/images/sequencediagram-history.png b/images/sequencediagram-history.png new file mode 100644 index 00000000..2fca9437 Binary files /dev/null and b/images/sequencediagram-history.png differ diff --git a/images/sequencediagram-login.png b/images/sequencediagram-login.png new file mode 100644 index 00000000..41a8de9e Binary files /dev/null and b/images/sequencediagram-login.png differ diff --git a/images/sequencediagram-ranking.png b/images/sequencediagram-ranking.png new file mode 100644 index 00000000..93c23f82 Binary files /dev/null and b/images/sequencediagram-ranking.png differ diff --git a/index.html b/index.html index df6f54f0..69b39492 100644 --- a/index.html +++ b/index.html @@ -451,51 +451,70 @@

arc42 T
  • 1.3. Stakeholders
    • -
  • 2. Architecture Constraints
    • -
  • 3. System Scope and Context +
  • 2. Architecture Constraints
    • -
  • 4. Solution Strategy
    • -
  • 5. Building Block View +
  • System Scope and Context +
    • -
  • 6. Runtime View +
  • Solution Strategy +
    • -
  • 11. Risks and Technical Debts
    • -
  • 12. Glossary
    • @@ -551,133 +570,78 @@

    arc42 T

    1. Introduction and Goals

    -
    -
    -
    -

    Describes the relevant requirements and the driving forces that software architects and development team must consider. -These include

    -
    -
    -
      -
    • -

      underlying business goals,

      -
      • -
    • -

      essential features,

      -
      • -
    • -

      essential functional requirements,

      -
      • -
    • -

      quality goals for the architecture and

      -
      • -
    • -

      relevant stakeholders and their expectations

      -
      • -
    -
    -
    -
    -
    -

    1.1. Requirements Overview

    -
    -
    -
    -
    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).

    -
    -
    -
    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.

    -
    -
    -

    Keep these excerpts as short as possible. Balance readability of this document with potential redundancy w.r.t to requirements documents.

    -
    -
    -
    Further Information
    -

    See Introduction and Goals in the arc42 documentation.

    -
    -
    -
    -
    -
    -

    1.2. Quality Goals

    -
    -
    -
    -
    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.

    -
    -
    -

    Consider this overview of potential topics (based upon the ISO 25010 standard):

    -
    -
    -
    -Categories of Quality Requirements -
    -
    -
    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…​

    +

    WIQ is a web application developed by HappySw that allows users to play an online quiz game.

    -
    Form
    -

    A table with quality goals and concrete scenarios, ordered by priorities

    -
    -
    -
    +

    The questions are automatically generated from Wikidata data and can be grouped by topic. Users can get a prize for each correctly answered question within a limited time and can also check their historical results in the game.

    -

    1.3. Stakeholders

    -
    -
    +

    1.1. Requirements Overview

    -
    Contents
    -

    Explicit overview of stakeholders of the system, i.e. all person, roles or organizations that

    +

    The main functional requirements to be met are:

    • -

      should know the architecture

      +

      Users must be able to register

    • -

      have to be convinced of the architecture

      +

      Users must be able to consult their participation history

    • -

      have to work with the architecture or with code

      +

      Each question must have one correct answer and several incorrect answers.

    • -

      need the documentation of the architecture for their work

      +

      Questions must have a time limit to answer them

    • -

      have to come up with decisions about the system or its development

      +

      Access to the user’s data must be allowed through an API.

      +
      • +
    • +

      Access to the information of the generated questions must be allowed through an API.

    -
    -
    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.

    +
    +

    1.2. Quality Goals

    -
    Form
    -

    Table with role names, person names, and their expectations with respect to the architecture and its documentation.

    -
    +

    The quality goals in order of priority are as follows:

    + ++++ + + + + + + + + + + + + + + + + + + + + + + + + +
    Quality goalDescription

    Usability

    The application must be easy to understand and use

    Performance efficiency

    Question generation must be efficient

    Security

    The confidentiality and integrity of user data must be ensured

    Maintainability

    The application must be testable and easily modifiable

    +
    +

    1.3. Stakeholders

    @@ -693,14 +657,24 @@

    1.3. Stakeholders

    - - - + + + + + + + + - - - + + + + + + + +

    <Role-1>

    <Contact-1>

    <Expectation-1>

    Teachers

    They interact with the development team and review the project to detect and correct errors

    The application must meet all functional requirements and must follow the quality goals

    RTVE (client)

    Company commissioning the development of the application

    The company hopes that the application will be easy to use for all users and that it will be a good version of its "Saber y Ganar" programme

    <Role-2>

    <Contact-2>

    <Expectation-2>

    Development Team

    They are the creators of the project

    They must develop an application that meets all the requirements and is attractive in order to attract as many users as possible

    Users

    End-users who will interact with the application

    They expect it to be user-friendly, attractive and similar to the programme it imitates ("Saber y Ganar")
    @@ -711,856 +685,718 @@

    1.3. Stakeholders

    2. Architecture Constraints

    -
    -
    -
    -
    Contents
    -

    Any requirement that constraints 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.

    -
    -
    -
    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.

    -
    -
    -
    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)

    -
    -
    -
    Further Information
    -

    See Architecture Constraints in the arc42 documentation.

    -
    +
    +

    2.1. Technical constraints

    + ++++ + + + + + + + + + + + + + + + + + + + + +
    ConstraintDescription

    Wikidata

    The generation of the questions should be done automatically with the data from Wikidata

    Web access

    The application must be accessible via the web

    Git and GitHub

    Version control and project tracking will be done using Git. GitHub is used to remotely store the repositories

    +
    +

    2.2. Organizational constraints

    + ++++ + + + + + + + + + + + + + + + + + + + + +
    ConstraintDescription

    Team

    The development team is composed of 6 people

    Repository control

    The repository has a "main" and a "develop" branch and numerous "feature" branches where new functionalities are developed

    Meetings

    At least one weekly team meeting is held to maintain proper organisation

    +
    +

    2.3. Conventions

    + ++++ + + + + + + + + + + + + + + + + +
    ConventionDescription

    Arc42

    The arc42 template is used in the documentation

    AsciiDoc

    The documentation is done using AsciiDoc as markup language

    +
    +

    System Scope and Context

    +
    -

    3. System Scope and Context

    +

    1. Contents

    -
    -
    +
    +

    1.1. Scope and context

    -
    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.

    +

    This project aims to develop a quiz game. +The main constraints are developing the game as a web app and using Wikidata to obtain the questions and answers.

    -
    -

    If necessary, differentiate the business context (domain specific inputs and outputs) from the technical context (channels, protocols, hardware).

    +
    -
    -
    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.

    -
    -
    Form
    -

    Various options:

    +
    +

    2. Business Context

    +
    +
    +

    2.1. Contents

    • -

      Context diagrams

      +

      Users: They interact directly with the application through the user interface provided by the frontend using React, HTML, CSS, and JavaScript.

    • -

      Lists of communication partners and their interfaces.

      +

      Wikidata API: The application communicates with the Wikidata service to obtain questions and answers related to different topics. Requests are made using the HTTP protocol, and response data is received in JSON format.

    +
    +
    +
    +

    2.2. Motivation

    -
    Further Information
    -

    See Context and Scope in the arc42 documentation.

    +

    Regarding the information exchanged with the application, it will require having a registered account to play, and it will also exchange information with a MongoDB database and Wikidata itself to obtain the questions.

    +
    +
    +

    2.3. Form

    + ++++++ + + + + + + + + + + + + + + + + + + + + +

    Quiz Game

    Comunication Partners

    Inputs

    Outputs

    Users

    User Interface

    User answers

    Game questions

    Wikidata API

    API Service

    Question requests

    JSON Responses

    +
    -

    3.1. Business Context

    -
    +

    2.4. Context diagram

    +
    -
    -
    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.

    -
    -
    -
    Motivation
    -

    All stakeholders should understand which data are exchanged with the environment of the system.

    +context
    -
    -
    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>

    +
    +

    3. Technical Context

    +
    +
    +

    3.1. Contents

    +
    +
      +
    • +

      HTTP Channel: The application uses the HTTP protocol to communicate with the Wikidata API service.

      +
      • +
    • +

      MongoDB Data Channel: Interactions with the MongoDB database allow for storing and retrieving questions and answers.

      +
      • +
    +
    -

    3.2. Technical Context

    -
    +

    3.2. Deployment diagram

    +
    -
    -
    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 which 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.

    +deployment
    -
    -
    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>

    +

    Solution Strategy

    +
    +

    1. Contents

    +
    -

    <optionally: Explanation of technical interfaces>

    +

    This page contains a short summary and explanation of the fundamental decisions and solution strategies, that shape system architecture.

    +
    +
    +

    1.1. Technology Decisions

    -

    <Mapping Input/Output to Channels>

    -
    -
    -
    -
    -
    -
    -

    4. Solution Strategy

    -
    -
    -
    -
    -
    Contents
    -

    A short summary and explanation of the fundamental decisions and solution strategies, that shape system architecture. It includes

    -
    -
    -
      -
    • -

      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.

      -
      • -
    -
    -
    -
    Motivation
    -

    These decisions form the cornerstones for your architecture. They are the foundation for many other detailed decisions or implementation rules.

    -
    -
    -
    Form
    -

    Keep the explanations of such key decisions short.

    -
    -
    -

    Motivate what was decided and why it was decided that way, -based upon problem statement, quality goals and key constraints. -Refer to details in the following sections.

    -
    -
    -
    Further Information
    -

    See Solution Strategy in the arc42 documentation.

    -
    -
    -
    -
    -
    -
    -
    -

    5. Building Block View

    -
    -
    -
    -
    -
    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, 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.

    -
    -
    -
    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.

    -
    -
    -
    -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.

    -
    -
    -
    Further Information
    -

    See Building Block View in the arc42 documentation.

    -
    -
    -
    -
    -

    5.1. Whitebox Overall System

    -
    -
    -
    -

    Here you describe the decomposition of the overall system using the following white box template. It contains

    +

    Below, all the technologies to be used in the development of the application are listed:

    • -

      an overview diagram

      +

      JavaScript / React: A JavaScript library designed to facilitate the development of web applications.

    • -

      a motivation for the decomposition

      +

      JavaScript / NodeJS: An asynchronous runtime environment based on JavaScript.

    • -

      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

        +

        MongoDB: A document-oriented NoSQL database system.

      • -

        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).

        -
        • -
      -
      +

      Docker: Used for deploying applications locally.

    • -

      (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.

      +

      Azure: Used for deploying applications on a server.

    +
    -
    +
    +

    1.2. Top-Level Decisions

    -

    <Overview Diagram>

    +

    In this section, a summarized list of all decisions regarding the architecture of the application is included.

    -
    -
    -
    Motivation
    -
    -

    <text explanation>

    -
    -
    Contained Building Blocks
    -
    -

    <Description of contained building block (black boxes)>

    -
    -
    Important Interfaces
    -
    -

    <Description of important interfaces>

    -
    -
    -
    -
    -
    -
    -

    Insert your explanations of black boxes from level 1:

    + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + +

    Architectural Pattern

    In this project, the pattern based on the Microservices model is used.

    Frontend (Client)

    React: Building the user interface

    Backend (Server)

    NodeJS: Building the server on the backend

    Mongoose: Interaction with the database

    Database

    MongoDB: NoSQL database storing data in BSON format

    Deployment

    Azure cloud services

    +
    +
    +

    1.3. Quality Goals

    -

    If you use tabular form you will only describe your black boxes with name and -responsibility according to the following schema:

    +

    Next, several quality goals are established, along with the decisions made to achieve them.

    --++ - - + + - - + + + + + + - - + + + + + +
    NameResponsibilityQuality GoalDecisions

    <black box 1>

     <Text>

    Usability

    Creation of a responsive interface adaptable to all types of screens.

    Accessibility

    Compliance with accessibility standards to ensure a usable application.

    <black box 2>

     <Text>

    Maintainability

    A structured project that facilitates the maintainability of the application.

    Testing

    Assurance of a fully functional and error-free application.
    -
    -

    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.

    -
    +
    +
    +

    1.4. Relevant Organizational

    +
    +

    Regarding the organization of the team, we have decided to use agile methodologies for better and faster group work. In this project, we will follow the best practices of the SCRUM framework.

    -
    -

    5.1.1. <Name black box 1>

    -
    -
    -

    Here you describe <black box 1> -according the the following black box template:

    +

    Practices to be followed:

    • -

      Purpose/Responsibility

      +

      Division of the project into tasks.

    • -

      Interface(s), when they are not extracted as separate paragraphs. This interfaces may include qualities and performance characteristics.

      +

      Equitable assignment of tasks.

    • -

      (Optional) Quality-/Performance characteristics of the black box, e.g.availability, run time behavior, …​.

      +

      Frequent meetings on the progress of the application.

    • -

      (Optional) directory/file location

      -
      • -
    • -

      (Optional) Fulfilled requirements (if you need traceability to requirements).

      -
      • -
    • -

      (Optional) Open issues/problems/risks

      +

      Construction of "Alpha" versions before the final release.

    -
    -
    -
    -

    <Purpose/Responsibility>

    -
    -

    <Interface(s)>

    +

    Additionally, "Issues" and the GitHub-provided Kanban (ToDo - In Progress - Done) are used for communication.

    -
    -

    <(Optional) Quality/Performance Characteristics>

    -
    -
    -

    <(Optional) Directory/File Location>

    -
    -
    -

    <(Optional) Fulfilled Requirements>

    +
    +
    +

    1.5. Motivation

    -

    <(optional) Open Issues/Problems/Risks>

    +

    This section addresses the fundamental decisions for the project’s architecture.

    + ++++ + + + + + + + + + + + + + + + + + + +

    Data Management

    Deployment

    Security

    Monitoring

    +
    -
    -

    5.1.2. <Name black box 2>

    -
    -

    <black box template>

    -
    -

    5.1.3. <Name black box n>

    -
    -

    <black box template>

    +
    +

    2. Building Block View

    +
    +
    +

    2.1. Level 1: Whitebox of the Overall System

    +
    +
    +level1
    -

    5.1.4. <Name interface 1>

    +

    2.1.1. Motivation

    -

    …​

    +

    WIQ application is the general structure of a system in which users will have the possibility to play a game like Saber y Ganar and compare their results with their friends.

    -

    5.1.5. <Name interface m>

    - +

    2.1.2. Contained building blocks

    + ++++ + + + + + + + + + + + + + + + + + + + + +
    NameDescription

    User

    Client of the application which will interact with it.

    WIQ

    System developed to be used by the users.

    WIKIDATA

    Aplication to generate the questions and answers.

    -

    5.2. Level 2

    -
    -
    -
    -

    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

    -
    -
    -
    -
    -

    5.2.1. White Box <building block 1>

    -
    +

    2.2. Level 2

    +
    -
    -

    …​describes the internal structure of building block 1.

    -
    -
    -
    -
    -

    <white box template>

    +level2
    -

    5.2.2. White Box <building block 2>

    +

    2.2.1. Motivation

    -

    <white box template>

    -
    -
    -

    …​

    +

    Shows how the application will work internally. The user, through the user interface, will use microservices to access the different modules with the help of the database.

    -

    5.2.3. White Box <building block m>

    -
    -

    <white box template>

    -
    +

    2.2.2. Contained building blocks

    + ++++ + + + + + + + + + + + + + + + + + + + + +
    NameDescription

    User Interface

    The user will interact with the UI.

    Microservices

    It is the backend of the UI, formed by different modules.

    DataBase

    MongoDB is the chosen NoSQL database management system. It stores all the information necessary for the proper functioning of the application.

    -

    5.3. Level 3

    -
    -
    -
    -

    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.

    -
    -
    -
    -
    -

    5.3.1. White Box <_building block x.1_>

    -
    +

    2.3. Level 3

    +
    -
    -

    Specifies the internal structure of building block x.1.

    -
    -
    -
    -
    -

    <white box template>

    +level3
    -

    5.3.2. White Box <_building block x.2_>

    +

    2.3.1. Motivation

    -

    <white box template>

    +

    Detailed structure of the system. Focused on the components of the User Interface and Data Access.

    -

    5.3.3. White Box <_building block y.1_>

    -
    -

    <white box template>

    -
    +

    2.3.2. Contained Building Blocks

    + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    NameDescription

    Game

    Game screen where the user can play the game.

    Ranking

    It contains the best scores recorded in the game, including the user’s highest score and the scores of other users belonging to their group.

    History

    Contains all user participations with the number of games played, correct/incorrect answers, and times.

    About

    Contains important information about the project, like the development method, the developers and how to contact them.

    Users Service

    Allows the client to create a new account for the application, log in and log out.

    Question service

    Allows to ask him questions and receive the answers of them.

    -

    6. Runtime View

    +

    3. Runtime View

    -
    -
    -
    -
    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.

    -
    +
    +

    3.1. Login

    -
    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).

    +

    For the login, the app shows the login view, which asks the user for his username and his password.

    -
    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

      -
      • -
    • -

      …​

      -
      • -
    +

    Then, the app does a login request to the users microservice, which redirect the user to the identity provider, which handles the authentication.

    -
    Further Information
    -

    See Runtime View in the arc42 documentation.

    -
    -
    -
    -
    -

    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.>

      -
      • -
    -
    -
    -

    It is possible to use a sequence diagram:

    +

    If the login is succesfully, the app shows the different options of the game. +In case the login isn’t succesfully, a warning message is shown.

    -Sequence diagram -
    +sequencediagram login
    -
    -

    6.2. <Runtime Scenario 2>

    -
    -

    6.3. …​

    - -
    -
    -

    6.4. <Runtime Scenario n>

    -
    -
    -
    -
    -
    -

    7. Deployment View

    -
    -
    -
    -
    -
    Content
    -

    The deployment view describes:

    -
    -
    -
      -
    1. -

      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

      -
      2. -
    2. -

      mapping of (software) building blocks to that infrastructure elements.

      -
      3. -
    -
    +

    3.2. Game

    -

    Often systems are executed in different environments, e.g. development environment, test environment, production environment. In such cases you should document all relevant environments.

    +

    When the user starts a game, the app generates a question and request the correct answer to the WikiData API. When the user choose a posible answer, the app checks if it is the correct answer. Then, this process is repeated until the end of the game.

    -
    -

    Especially document a deployment view if your software is executed as distributed system with more than one computer, processor, server or container or when you design and construct your own hardware processors and chips.

    -
    -
    -

    From a software perspective it is sufficient to capture only those elements of an infrastructure that are needed to show a deployment of your building blocks. Hardware architects can go beyond that and describe an infrastructure to any level of detail they need to capture.

    -
    -
    -
    Motivation
    -

    Software does not run without hardware. -This underlying infrastructure can and will influence a system and/or some -cross-cutting concepts. Therefore, there is a need to know the infrastructure.

    -
    -
    -
    Form
    -

    Maybe a 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 one can -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 a deployment diagram, let them use any kind that is able to show nodes and channels of the infrastructure.

      -
      • -
    -
    -
    -
    Further Information
    -

    See Deployment View in the arc42 documentation.

    -
    -
    -
    -
    -

    7.1. Infrastructure Level 1

    -
    +
    -
    -

    Describe (usually in a combination of diagrams, tables, and text):

    +sequencediagram game
    -
    -
      -
    • -

      distribution of a system to multiple locations, environments, computers, processors, .., as well as physical connections between them

      -
      • -
    • -

      important justifications or motivations for this deployment structure

      -
      • -
    • -

      quality and/or performance features of this infrastructure

      -
      • -
    • -

      mapping of software artifacts to elements of this infrastructure

      -
      • -
    -
    -
    -

    For multiple environments or alternative deployments please copy and adapt this section of arc42 for all relevant environments.

    -
    -
    -
    -
    -

    <Overview Diagram>

    -
    -
    -
    -
    Motivation
    -
    -

    <explanation in text form>

    -
    -
    Quality and/or Performance Features
    -
    -

    <explanation in text form>

    -
    -
    Mapping of Building Blocks to Infrastructure
    -
    -

    <description of the mapping>

    -
    -
    -

    7.2. Infrastructure Level 2

    -
    -
    -
    -

    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.

    -
    -
    -
    -
    -

    7.2.1. <Infrastructure Element 1>

    -
    -

    <diagram + explanation>

    -
    -
    -
    -

    7.2.2. <Infrastructure Element 2>

    -
    -

    <diagram + explanation>

    -
    -
    -

    …​

    -
    -
    -
    -

    7.2.3. <Infrastructure Element n>

    -
    -

    <diagram + explanation>

    -
    -
    -
    -
    -
    -
    -
    -

    8. Cross-cutting Concepts

    -
    -
    -
    +

    3.3. Ranking

    -
    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

    +

    In this view, the user can watch different rankings:

    • -

      models, especially domain models

      -
      • -
    • -

      architecture or design patterns

      -
      • -
    • -

      rules for using specific technology

      +

      Ordered by accuracy percentage

    • -

      principal, often technical decisions of an overarching (= cross-cutting) nature

      +

      Ordered by number of questions answered correctly

    • -

      implementation rules

      +

      Ordered by quantity of game rounds

    -
    -
    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.

    -
    -
    -

    Some of these concepts cannot be assigned to individual building blocks, e.g. security or safety.

    -
    -
    -
    Form
    -

    The form can be varied:

    +
    +
    +sequencediagram ranking
    -
    -
      -
    • -

      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)

      -
      • -
    +
    +
    +

    3.4. History

    -
    Structure
    -

    A potential (but not mandatory) structure for this section could be:

    +

    In this view, the user can watch this options about his past games:

    • -

      Domain concepts

      -
      • -
    • -

      User Experience concepts (UX)

      -
      • -
    • -

      Safety and security concepts

      -
      • -
    • -

      Architecture and design patterns

      +

      Number of games played

    • -

      "Under-the-hood"

      +

      Best times

    • -

      development concepts

      -
      • -
    • -

      operational concepts

      +

      Correct/incorrect questions

    -
    -

    Note: it might be difficult to assign individual concepts to one specific topic -on this list.

    -
    -Possible topics for crosscutting concepts +sequencediagram history
    -
    -
    Further Information
    -

    See Concepts in the arc42 documentation.

    +
    +
    +
    +
    +

    4. Deployment View

    +
    +
    +
    +
    -

    8.1. <Concept 1>

    +

    4.1. Infrastructure Level 1

    +
    +
    +
    +
    +Diag Comp +
    +
    Figure 1. Deployment Diagram
    +
    +
    +
    +
    Motivation
    +
    +

    The system is based in microservices architecture with three independent services, each responsible for a specific aspect of the functionality. One service is the Graphic interface, this service handles the presentation layer of a web application. Another service is tasked with managing user-related functionalities. MongoDB, a NoSQL database, is used to store and manage user data efficiently. The third service utilizes Wikidata, a free open base, to automatically generate questions.

    +
    +
    Quality and/or Performance Features
    +
    +

    The main reason we have chosen a microservices architecture is to achieve a fast and efficient application.. The availability and efficiency of the application will be affected by Wikidata’s availability, but just in the question generation moment.

    +
    +
    Mapping of Building Blocks to Infrastructure
    +
    +
    + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ElementDescription

    Browser

     The browser on the user’s device where they can access to the application.

    WebApp

     The graphical interface through which users can interact.

    API Gateway

     The API that comunicates the rest of the microservices with the graphical interface.

    Question_Generator

     The microservice responsible for generating questions through Wikidata.

    Wikidata

     The Wikidata API that allows us to access its information.

    Users

     The microservice responsible for managing users.

    MongoDB

     A NoSQL based database where we can save the user’s data.

    +
    +
    +

    == Cross-cutting Concepts

    +
    +
    +
    +
    +
    -

    <explanation>

    +

    === Domain Model

    +
    +

    TBD

    -
    -

    8.2. <Concept 2>

    -

    <explanation>

    +

    === Security

    +
    +
    +

    The communication between the application’s APIs will be through the secure mode of HTTP.

    +
    +
    +

    === Privacy

    +
    +
    +

    The user’s data will be stored in a MongoDb database. That implies that the information is stored securely.

    …​

    +
    +

    === <Concept n>

    -
    -

    8.3. <Concept n>

    <explanation>

    +
    +

    == Architecture Decisions

    -
    -

    9. Architecture Decisions

    -
    -
    -
    Contents

    Important, expensive, large scale or risky architecture decisions including rationales. @@ -1601,16 +1437,44 @@

    9. Architecture Decisions

    See Architecture Decisions in the arc42 documentation. There you will find links and examples about ADR.

    -
    -
    +
    +
    + ++++ + + + + + + + + + + + + + + + + + + + + + + + + +
    DecisionMotivation

    Docker

    It is decided to use Docker due to its popularity in the professional field and its ease of execution thanks to the configuration files provided by the subject’s faculty.

    MongoDB

    It is decided to use MongoDB based on the recommendation of the faculty, as it is one of the most popular NoSQL databases and because it fits perfectly with the application’s needs.

    NodeJS

    It is decided to use NodeJS since it is the recommended option by the subject’s faculty and one of the most widely used technologies in this area of web applications, thus having extensive documentation and examples available on the Internet.

    React

    It is decided to use React since it is the recommended option by the subject’s faculty.

    +
    +

    == Quality Requirements

    +
    -
    -

    10. Quality Requirements

    -
    -
    -
    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)

    @@ -1629,12 +1493,13 @@

    10. Quality Requirements

    Further Information

    See Quality Requirements in the arc42 documentation.

    +
    +
    +
    +

    === Quality Tree

    +
    -
    -

    10.1. Quality Tree

    -
    -
    Content

    The quality tree (as defined in ATAM – Architecture Tradeoff Analysis Method) with quality/evaluation scenarios as leafs.

    @@ -1660,14 +1525,19 @@

    10.1. Quality Tree

    In any case the tree should include links to the scenarios of the following section.

    +
    +
    +Quality Tree
    -
    -
    -

    10.2. Quality Scenarios

    -
    +
    +

    === Quality Scenarios

    +
    +
    +
    +
    Contents

    Concretization of (sometimes vague or implicit) quality requirements using (quality) scenarios.

    @@ -1701,80 +1571,139 @@

    10.2. Quality Scenarios

    Form

    Tabular or free form text.

    -
    -
    -
    -
    -
    -
    -
    -

    11. Risks and Technical Debts

    -
    -
    -
    -
    -
    Contents
    -

    A list of identified technical risks or technical debts, ordered by priority

    -
    -
    -
    Motivation
    -

    “Risk management is project management for grown-ups” (Tim Lister, Atlantic Systems Guild.)

    -
    -
    -

    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.

    -
    -
    -
    Form
    -

    List of risks and/or technical debts, probably including suggested measures to minimize, mitigate or avoid risks or reduce technical debts.

    -
    -
    -
    Further Information
    -

    See Risks and Technical Debt in the arc42 documentation.

    -
    -
    -
    -
    -
    -
    -
    -

    12. Glossary

    -
    -
    +
    -
    -
    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.

    -
    -
    -
    Motivation
    -

    You should clearly define your terms, so that all stakeholders

    -
    • -

      have an identical understanding of these terms

      +

      Usage Scenarios

      • +
    +
    + +++++ + + + + + + + + + + + + + + + + + + + + + + + + +
    Quality GoalScenarioResponse

    Performance efficiency

    The user wants to start answering questions.

    The application generates a set of questions. This generation should be as fast as possible.

    Usability

    A new user starts using the application.

    User should be able to do it without difficulty.

    Security

    The application must encript sensible data.

    Data will be only accessible by its owner.

    +
    +
    • -

      do not use synonyms and homonyms

      +

      Change Scenarios

    -
    -
    Form
    -

    A table with columns <Term> and <Definition>.

    + +++++ + + + + + + + + + + + + + + +
    Quality GoalScenarioResponse

    Maintainability

    Introduce new functionality.

    Reuse key components in order to easily add that new functionality.

    +
    +
    +

    == Risks and Technical Debts +=== Risks

    + ++++ + + + + + + + + + + + + + + + + + + + + + + + + +
    RiskDescription

    Teamwork failures

    The distribution of tasks must be done effectively, so that if one member of the team does not perform an assigned task, it can be solved by another member.

    Version management problems

    Errors in version control can delay the project. Ignorance of the branches and their purpose can lead to code conflicts.

    Lack of time

    Not planning work well can result in difficulties meeting deadlines

    Use of unknown technologies

    The use of languages and technologies unknown to group members can make it difficult to perform assigned tasks

    -

    Potentially more columns in case you need translations.

    +

    === Technical debts

    -
    -
    Further Information
    -

    See Glossary in the arc42 documentation.

    + ++++ + + + + + + + + + + + + +
    RiskDescription

    Insufficient documentation

    A lack of clear documentation about code and architecture can make it difficult to understand and maintain code, leading to additional work.

    +
    +
    +
    +
    +

    5. Glossary

    +
    @@ -1788,12 +1717,24 @@

    12. Glossary

    - - + + + + + + + + + + + + + + - - + +

    <Term-1>

    <definition-1>

    React

    JavScript library, we make use of this User Interface library on the front-end

    Docker

    We use it to deploy applications within virtual containers

    Node.js

    JavaScript runtime environment, we make use of this on the back-end

    GitHub

    Portal used to host the application code and documentation

    <Term-2>

    <definition-2>

    MongoDB

    NoSQL database management system used in the application