diff --git a/images/context.png b/images/context.png index 4313a20a..06d0ee44 100644 Binary files a/images/context.png and b/images/context.png differ diff --git a/images/deployment.png b/images/deployment.png index d2170bbb..c839760e 100644 Binary files a/images/deployment.png and b/images/deployment.png differ diff --git a/images/level1.png b/images/level1.png index 9260e859..8c235476 100644 Binary files a/images/level1.png and b/images/level1.png differ diff --git a/images/level2.png b/images/level2.png index ab5c807c..b71a8b27 100644 Binary files a/images/level2.png and b/images/level2.png differ diff --git a/images/level3.png b/images/level3.png index 32ce031e..59cf67f9 100644 Binary files a/images/level3.png and b/images/level3.png differ diff --git a/index.html b/index.html index 69b39492..50a2f26a 100644 --- a/index.html +++ b/index.html @@ -458,63 +458,39 @@

arc42 T
  • 2.3. Conventions
    • -
  • System Scope and Context -
    • -
  • Solution Strategy -
    • +
  • 8. Glossary
    • @@ -771,13 +747,14 @@

    2.3. Conventions

    -

    System Scope and Context

    -
    -

    1. Contents

    +

    3. System Scope and Context

    +
    -

    1.1. Scope and context

    +

    3.1. Contents

    +
    +

    3.1.1. Scope and context

    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.

    @@ -785,12 +762,10 @@

    1.1. Scope and context

    -
    -
    -

    2. Business Context

    -
    -
    -

    2.1. Contents

    +
    +

    3.2. Business Context

    +
    +

    3.2.1. Contents

    • @@ -803,15 +778,15 @@

      2.1. Contents

    -
    -

    2.2. Motivation

    +
    +

    3.2.2. Motivation

    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

    +
    +

    3.2.3. Form

    @@ -842,22 +817,20 @@

    2.3. Form

    -
    -

    2.4. Context diagram

    +
    +

    3.2.4. Context diagram

    -context +context
    -
    -
    -

    3. Technical Context

    -
    -
    -

    3.1. Contents

    +
    +

    3.3. Technical Context

    +
    +

    3.3.1. Contents

    • @@ -870,27 +843,29 @@

      3.1. Contents

    -
    -

    3.2. Deployment diagram

    +
    +

    3.3.2. Deployment diagram

    -deployment +deployment
    -

    Solution Strategy

    -
    -

    1. Contents

    +
    +
    +

    4. Solution Strategy

    +
    +

    4.1. Contents

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

    -
    -

    1.1. Technology Decisions

    +
    +

    4.1.1. Technology Decisions

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

    @@ -915,8 +890,8 @@

    1.1. Technology Decisions

    -
    -

    1.2. Top-Level Decisions

    +
    +

    4.1.2. Top-Level Decisions

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

    @@ -954,8 +929,8 @@

    1.2. Top-Level Decisions

    -
    -

    1.3. Quality Goals

    +
    +

    4.1.3. Quality Goals

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

    @@ -991,8 +966,8 @@

    1.3. Quality Goals

    -
    -

    1.4. Relevant Organizational

    +
    +

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

    @@ -1020,8 +995,8 @@

    1.4. Relevant Organizational

    -
    -

    1.5. Motivation

    +
    +

    4.1.5. Motivation

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

    @@ -1053,24 +1028,25 @@

    1.5. Motivation

    +
    -

    2. Building Block View

    +

    5. Building Block View

    -

    2.1. Level 1: Whitebox of the Overall System

    +

    5.1. Level 1: Whitebox of the Overall System

    -level1 +level1
    -

    2.1.1. Motivation

    +

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

    -

    2.1.2. Contained building blocks

    +

    5.1.2. Contained building blocks

    @@ -1100,20 +1076,20 @@

    2.1.2. Contained building blocks

    -

    2.2. Level 2

    +

    5.2. Level 2

    -level2 +level2
    -

    2.2.1. Motivation

    +

    5.2.1. Motivation

    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.

    -

    2.2.2. Contained building blocks

    +

    5.2.2. Contained building blocks

    @@ -1143,20 +1119,20 @@

    2.2.2. Contained building blocks

    -

    2.3. Level 3

    +

    5.3. Level 3

    -level3 +level3
    -

    2.3.1. Motivation

    +

    5.3.1. Motivation

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

    -

    2.3.2. Contained Building Blocks

    +

    5.3.2. Contained Building Blocks

    @@ -1201,10 +1177,10 @@

    2.3.2. Contained Building Blocks

    -

    3. Runtime View

    +

    6. Runtime View

    -

    3.1. Login

    +

    6.1. Login

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

    @@ -1222,7 +1198,7 @@

    3.1. Login

    -

    3.2. Game

    +

    6.2. Game

    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.

    @@ -1233,7 +1209,7 @@

    3.2. Game

    -

    3.3. Ranking

    +

    6.3. Ranking

    In this view, the user can watch different rankings:

    @@ -1257,7 +1233,7 @@

    3.3. Ranking

    -

    3.4. History

    +

    6.4. History

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

    @@ -1284,7 +1260,7 @@

    3.4. History

    -

    4. Deployment View

    +

    7. Deployment View

    @@ -1292,7 +1268,7 @@

    4. Deployment View

    -

    4.1. Infrastructure Level 1

    +

    7.1. Infrastructure Level 1

    @@ -1395,50 +1371,6 @@

    4.1. Infrastructure Level 1

    == Architecture Decisions

    -
    -
    -
    -
    Contents
    -

    Important, expensive, large scale or risky architecture decisions including rationales. -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:

    -
    -
    -
      -
    • -

      ADR (Documenting Architecture Decisions) for every important decision

      -
      • -
    • -

      List or table, ordered by importance and consequences or:

      -
      • -
    • -

      more detailed in form of separate sections per decision

      -
      • -
    -
    -
    -
    Further Information
    -

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

    -
    -
    -
    @@ -1475,104 +1407,17 @@

    4.1. Infrastructure Level 1

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

    -
    -
    -

    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.

    -
    -
    -
    Further Information
    -

    See Quality Requirements in the arc42 documentation.

    -
    -
    -
    -
    -

    === Quality Tree

    -
    -
    -
    -
    -
    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 Tree +Quality Tree
    +
    Figure 2. Quality Tree

    === Quality Scenarios

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

    -
    -
    -
    • @@ -1702,7 +1547,7 @@

      4.1. Infrastructure Level 1

    -

    5. Glossary

    +

    8. Glossary