Skip to content

Commit

Permalink
Merge pull request #19 from Arquisoft/documentation2and5
Browse files Browse the repository at this point in the history
Added documentation for points 2 and 5
  • Loading branch information
UO294067 authored Feb 15, 2025
2 parents 7a1ff08 + 78b317d commit fcde92e
Show file tree
Hide file tree
Showing 4 changed files with 60 additions and 224 deletions.
Binary file added docs/images/05_level1.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/images/05_level2.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
66 changes: 49 additions & 17 deletions docs/src/02_architecture_constraints.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -2,28 +2,60 @@ ifndef::imagesdir[:imagesdir: ../images]

[[section-architecture-constraints]]
== Architecture Constraints
The application has some constraints, these are requirements of the stakeholders or environment that we must accept. They are divided in technical constraints, organizational constraints and convention constraints.


ifdef::arc42help[]
[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.
=== Technical Constraints

.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.
[options="header", cols="1,1"]

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

| Constraint | Limitations

.Further Information
| Web Frontend | The system will have at least a Web frontend

See https://docs.arc42.org/section-2/[Architecture Constraints] in the arc42 documentation.
|Wikidata | We must use Wikidata to get information to generate the questions

| LLM | An LLM will be used to generate hints for the questions

| GitHub | We must use GitHub for the version control of the project

|===



=== Organizational Constraints

[options="header", cols="1,1"]

|===

| Constraints | Limitations

| Team | The team for the project was chosen by the professors

| Weekly meetings | There must be at least one weekly meeting

| Public repository | The project source code will be available in a public repository

|===



=== Conventions



[options="header", cols="1,1"]

|===

| Conventions | Limitations

| Documentation architecture | The documentation must follow Arc42

| Language | The documentation and in general the project will be written in English

|===

****
endif::arc42help[]
218 changes: 11 additions & 207 deletions docs/src/05_building_block_view.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -5,221 +5,25 @@ ifndef::imagesdir[:imagesdir: ../images]

== Building Block View

ifdef::arc42help[]
[role="arc42help"]
****
.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.
image::05_building_blocks-EN.png["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 https://docs.arc42.org/section-5/[Building Block View] in the arc42 documentation.
****
endif::arc42help[]

=== Whitebox Overall System

ifdef::arc42help[]
[role="arc42help"]
****
Here you describe the decomposition of the overall system using the following white box template. It contains
* an overview diagram
* a motivation for the decomposition
* 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
** 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).
* (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.
****
endif::arc42help[]

_**<Overview Diagram>**_

Motivation::

_<text explanation>_


Contained Building Blocks::
_<Description of contained building block (black boxes)>_

Important Interfaces::
_<Description of important interfaces>_

ifdef::arc42help[]
[role="arc42help"]
****
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:
[cols="1,2" options="header"]
|===
| **Name** | **Responsibility**
| _<black box 1>_ | _<Text>_
| _<black box 2>_ | _<Text>_
|===
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.
****
endif::arc42help[]

==== <Name black box 1>

ifdef::arc42help[]
[role="arc42help"]
****
Here you describe <black box 1>
according the the following black box template:
* Purpose/Responsibility
* Interface(s), when they are not extracted as separate paragraphs. This interfaces may include qualities and performance characteristics.
* (Optional) Quality-/Performance characteristics of the black box, e.g.availability, run time behavior, ....
* (Optional) directory/file location
* (Optional) Fulfilled requirements (if you need traceability to requirements).
* (Optional) Open issues/problems/risks
****
endif::arc42help[]

_<Purpose/Responsibility>_

_<Interface(s)>_

_<(Optional) Quality/Performance Characteristics>_

_<(Optional) Directory/File Location>_

_<(Optional) Fulfilled Requirements>_

_<(optional) Open Issues/Problems/Risks>_




==== <Name black box 2>

_<black box template>_

==== <Name black box n>

_<black box template>_


==== <Name interface 1>

...

==== <Name interface m>
=== Level 1
Overall view of the system and the parts in which it is divided as well as the external systems it connects to.

image::05_level1.png["Level 1"]

Application represents the entire system implemented by our team. This is the part of the system with which the user interacts. LLM stands for Large Language Model, which is used to generate hints. Wiki data is the external system that provides information about the questions in the game. The last part is the Database, which represents the connection to a database where data about the program, such as user data, is stored.

=== Level 2

ifdef::arc42help[]
[role="arc42help"]
****
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
****
endif::arc42help[]

==== White Box _<building block 1>_

ifdef::arc42help[]
[role="arc42help"]
****
...describes the internal structure of _building block 1_.
****
endif::arc42help[]

_<white box template>_

==== White Box _<building block 2>_


_<white box template>_

...

==== White Box _<building block m>_


_<white box template>_



=== Level 3

ifdef::arc42help[]
[role="arc42help"]
****
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.
****
endif::arc42help[]

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

ifdef::arc42help[]
[role="arc42help"]
****
Specifies the internal structure of _building block x.1_.
****
endif::arc42help[]

_<white box template>_

image::05_level2.png["Level 2"]

==== White Box <_building block x.2_>
* The Frontend is what the user will interact with, the part the user will be able to see. It will send requests to the GameService and UserService.

_<white box template>_
* The GameService handles the game, it will ask for questions and hints, and send them to the frontend, then process the answers. It will also interact with the user service to keep track of scores and other user information related to the game.

* The UserService is in charge of logging in the user and keeping track of all their relevant information by storing it and retrieving it from a database.

* The HintService will be used to interact with an LLM in order to generate hints.

==== White Box <_building block y.1_>
* The QuestionService will be used to generate questions based on data extracted from WikiData.

_<white box template>_
* The Database will store information used in the system such as the user login details, the previous games and scores, in the future we might also use it for information about the questions.

0 comments on commit fcde92e

Please sign in to comment.