diff --git a/images/Context diagram.png b/images/Context diagram.png index 2186832..0bce9d8 100644 Binary files a/images/Context diagram.png and b/images/Context diagram.png differ diff --git a/images/Generated Questions API (White Box).png b/images/Generated Questions API (White Box).png new file mode 100644 index 0000000..4966391 Binary files /dev/null and b/images/Generated Questions API (White Box).png differ diff --git a/images/White box overall system.png b/images/White box overall system.png new file mode 100644 index 0000000..9dd0cde Binary files /dev/null and b/images/White box overall system.png differ diff --git a/index.html b/index.html index 6886fb6..49b7ddc 100644 --- a/index.html +++ b/index.html @@ -447,8 +447,7 @@

arc42 T
  • 1. Introduction and Goals
  • 2. Architecture Constraints
    • @@ -462,7 +461,6 @@

    arc42 T
  • 6. Runtime View @@ -490,7 +488,6 @@

    arc42 T
  • 10. Quality Requirements
  • 11. Risks and Technical Debts
    • @@ -577,6 +574,9 @@

    1. Introduction and Goals

    +
    +

    In these points, the main goals and functional requirements will be explained. In order to give context on how the webapp will be developed.

    +

    1.1. Requirements Overview

    @@ -606,9 +606,119 @@

    1.1. Requirements Overview

    +
    +

    The functional requirements have been grouped into the different microservices the web application will have. +==== User and Authorization Services

    +
    +
    +
      +
    1. +

      The User service allows the user to

      +
      +
        +
      1. +

        Register.

        +
        2. +
      2. +

        Delete the account.

        +
        3. +
      3. +

        Update the account.

        +
        4. +
      4. +

        Recover the password.

        +
        5. +
      +
      +
      2. +
    2. +

      The authorization service allows the user to

      +
      +
        +
      1. +

        Log in.

        +
        2. +
      2. +

        Log out.

        +
        3. +
      +
      +
      3. +
    3. +

      A user can retrieve the following information from the User service

      +
      +
        +
      1. +

        Name.

        +
        2. +
      2. +

        Email.

        +
        3. +
      3. +

        Profile picture.

        +
        4. +
      4. +

        Questions answered.

        +
        5. +
      +
      +
      4. +
    4. +

      The system must be able to manage the user’s access to the system.

      +
      5. +
    +
    +
    +

    1.1.1. Question Service

    +
    +
      +
    1. +

      The Question service retrieves questions generated from wikidata.

      +
      2. +
    2. +

      A user can retrieve the following information from the Question service

      +
      +
        +
      1. +

        Select a category.

        +
        2. +
      2. +

        Select a difficulty.

        +
        3. +
      3. +

        Select a question.

        +
        4. +
      4. +

        Select an answer.

        +
        5. +
      +
      +
      3. +
    3. +

      Questions must be stored in a database.

      +
      4. +
    4. +

      The database used is MongoDB.

      +
      5. +
    5. +

      Questions are classified by

      +
      +
        +
      1. +

        Category.

        +
        2. +
      2. +

        Difficulty.

        +
        3. +
      +
      +
      6. +
    6. +

      The questions should be selected randomly. +=== Quality Goals

      +
      7. +
    -
    -

    1.2. Quality Goals

    @@ -637,9 +747,40 @@

    1.2. Quality Goals

    + ++++ + + + + + + + + + + + + + + + + + + + + + + + + +
    GoalDescription

    Testability

    Test will be developed, so the application has a good quality.

    Usability

    The application has to be intuitive for its users.

    Portability

    The application works in different devices and browsers. With different screen sizes.

    Performance

    The application can handle a big number of users and give good response times.

    +
    -

    1.3. Stakeholders

    +

    1.2. Stakeholders

    @@ -799,7 +940,7 @@

    3.1. Business Context

    -Context diagram +Context diagram
    @@ -1006,25 +1147,54 @@

    5.1. Whitebox Overall System

    -
    -

    <Overview Diagram>

    +
    +
    +White box overall system +
    Motivation
    -

    <text explanation>

    -
    -
    Contained Building Blocks
    -
    -

    <Description of contained building block (black boxes)>

    -
    -
    Important Interfaces
    -
    -

    <Description of important interfaces>

    +

    We made the decomposition separating the functionallities (The names are self explanatory but components will be described later)

    +
    Contained Black boxes
    +
    ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    NameResponsibility

    WIQ Game GUI

    Main window in which questions are shown and can be answered by the player. The latter can also see past scores.

    Data View

    Access to data about users and generated questions for the client.

    Generated Questions API

    In charge of generating the questions and storing their data

    UsersAPI

    In charge of keeping track of the data of the users (registration and scores)

    Wikidata

    External element used for the generation of questions

    @@ -1062,8 +1232,6 @@

    5.1. Whitebox Overall System

    -
    -

    5.1.1. <Name black box 1>

    @@ -1093,47 +1261,6 @@

    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>

    -
    @@ -1151,7 +1278,7 @@

    5.2. Level 2

    -

    5.2.1. White Box <building block 1>

    +

    5.2.1. Generated Questions API (White Box)

    @@ -1159,62 +1286,62 @@

    5.2.1. White Box <building block 1&g

    -
    -

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

    -
    +
    -
    -

    Specifies the internal structure of building block x.1.

    -
    +Generated Questions API (White Box)
    -
    -

    <white box template>

    +
    +
    +
    Motivation
    +
    +

    We made the decomposition separating the functionallities.

    +
    +
    Contained Black boxes
    +
    + ++++ + + + + + + + + + + + + + + + + + + + + +
    NameResponsibility

    GenQuestsService

    Receives different petitions regarding the generation of questions or their retrieval and responds accordingly.

    wikidatanpm

    External library that facilitates and simplifies the use of wikidata for the generation of questions.

    MongoDB

    The data of the generated questions is stored here for showing it later to the client.

    +
    +
    +
    Additional explanation of relationships
    +
    +

    The service is requested either the generation of a question or the retrieval of a subset (from WIQ Game GUI or +Data View respectively).

    +
    +
    -
    -

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

    -

    <white box template>

    -
    +

    For the first case, it makes use of the library to generate the question, retrieves it +for the interface to use and stores the pertinent data in the DB.

    -
    -

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

    -

    <white box template>

    +

    In the other case, it just makes the query according to the client choosings and retrieves the data of the +questions for the Data View to show.

    @@ -1696,9 +1823,16 @@

    10.1. Quality Tree

    +
    +

    @startmindmap +* Quality + Testability + Usability + Portability + Performance +@endmindmap +=== Quality Scenarios

    -
    -

    10.2. Quality Scenarios

    @@ -1737,10 +1871,88 @@

    10.2. Quality Scenarios

    +
    +

    10.1.1. Usage Scenarios

    + ++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Quality goalMotivationUsage scenarioPriority

    Testability

    Test will be developed, so the application has a good quality.

    The coverage should be higher than 70% and SonarCloud should give a pass in unit tests

    High

    Usability

    The application has to be intuitive for its users.

    Users don’t like to spend a lot of time trying to understand how to use an application. Therefore when they want to do something, they want to know where to go and what to do.

    Very high

    Portability

    The application works in different devices and browsers. With different screen sizes.

    Users connect from different devices and browsers, we should ensure that the application works in all of them.

    Medium

    Performance

    The application can handle a big number of users and give good response times.

    The application should be able to stand at least 10 users simultaneously and give a response time of less than 20 seconds.

    High

    +
    +
    +

    10.1.2. Change Scenarios

    + ++++++ + + + + + + + + + + + + + + + + + + + + + + +
    Quality goalMotivationChange scenarioPriority

    Maintainability

    An application should be easy to update and maintain by the dev team. Respecting the architecture of the web application and the continuous integration.

    If a developer wants to add a feauture or include a hotfix, he should be able to do it without major consequences on the system, always respecting the architecture of the web application.

    High

    Maintainability

    An application should be easy to update and maintain by the dev team. Respecting the architecture of the web application.

    As there is continuous integration, when fixing a bug or adding a feature, if an error is found, the application won’t be affected as changes won’t be applied.

    Very High

    +

    11. Risks and Technical Debts