chore: Added sections 2 and 8 to the documentation

docs/src/02_architecture_constraints.adoc

@@ -6,22 +6,30 @@ ifndef::imagesdir[:imagesdir: ../images]
 
 [role="arc42help"]
 ****
-.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.
+The application must be developed according to some constraints that were defined by the professors. These constraints are meant to be the cornerstones of our project as they are mandatory and provide a baseline to work on. The following tables will define the constraints.
+
+
+*Technical constraints*
+|===
+| *Constraint* | *Description* 
+| Web accesible front-end | The application must be possible to access through a web browser
+| Use of WikiData | The system must make use of WikiData to gather information
+| Automatic questions | The questions prompted by the game must be generated automatically
+|===
+
+*Organizational constraints*
+|===
+| *Constraint* | *Description* 
+| Weekly meetings | Each class week, the team must meet and discuss the development
+| Use of GitHub | GitHub must be used to communicate and keep track of the development process
+| Deliverables | The project will be reviewed by the professors on three occasions
+|===
+
+*Conventional constraints*
+|===
+| *Constraint* | *Description*
+| Documentation in Arc42 | The documentation must follow the Arc42 template
+|===
 
-.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 https://docs.arc42.org/section-2/[Architecture Constraints] in the arc42 documentation.
 
 ****

docs/src/08_concepts.adoc

@@ -6,68 +6,58 @@ ifndef::imagesdir[:imagesdir: ../images]
 
 [role="arc42help"]
 ****
-.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
 
-* models, especially domain models
-* architecture or design patterns
-* rules for using specific technology
-* principal, often technical decisions of an overarching (= cross-cutting) nature
-* implementation rules
 
-
-.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:
-
-* 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)
-
-.Structure
-A potential (but not mandatory) structure for this section could be:
-
-* Domain concepts
-* User Experience concepts (UX)
-* Safety and security concepts
-* Architecture and design patterns
-* "Under-the-hood"
-* development concepts
-* operational concepts
-
-Note: it might be difficult to assign individual concepts to one specific topic
-on this list.
-
-image::08-Crosscutting-Concepts-Structure-EN.png["Possible topics for crosscutting concepts"]
-
-
-.Further Information
-
-See https://docs.arc42.org/section-8/[Concepts] in the arc42 documentation.
-****
-
-
-=== _<Concept 1>_
-
-_<explanation>_
-
-
-
-=== _<Concept 2>_
-
-_<explanation>_
-
-...
-
-=== _<Concept n>_
-
-_<explanation>_
+.Domain Model
+These diagram is just a sketch, it should be replaced by a more accurate version upon discussion.
+
+[plantuml,"ConceptsDomainModel1",png]
+----
+@startuml
+
+enum Category {
+    HISTORY
+    GEOGRAPHY
+    MATHS
+}
+
+class Question{
+    id: int
+    content: String
+    category: Category
+    language: String
+}
+
+class User{
+    id: int
+    name: String
+    email: String
+    password: String
+    answered: List<Question>
+}
+
+class Score{
+    user: User
+    rightRate: float
+    timeAvg: float
+    answeredQuestions: int
+}
+
+User o--> Question
+User --> Score
+
+@enduml
+----
+
+|===
+| Class | Explanation
+| Question | The model of the questions
+| User | The people using the application
+| Score | A class that keeps tracks of each user scores
+|===
+
+.Architecture and design patterns
+We decided to use a React based frontend with BootSpring for the backend, which will follow the model view controller pattern to make the code clear.
+
+.User Experience
+As this is a game, the focus must be in user experience so players can have an enjoyable experience, for achieving this, the response time should be as low as possible and the interfaces should be intuitive and beautiful.