forked from Arquisoft/wiq_0
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge branch 'Develop' into FeatureQuestions
- Loading branch information
Showing
39 changed files
with
1,719 additions
and
163 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,75 +1,90 @@ | ||
ifndef::imagesdir[:imagesdir: ../images] | ||
|
||
[[section-system-scope-and-context]] | ||
== System Scope and Context | ||
# System Scope and Context | ||
|
||
|
||
[role="arc42help"] | ||
**** | ||
.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. | ||
--- | ||
|
||
If necessary, differentiate the business context (domain specific inputs and outputs) from the technical context (channels, protocols, hardware). | ||
## Contents | ||
### Scope and context | ||
|
||
.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. | ||
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. | ||
|
||
.Form | ||
Various options: | ||
--- | ||
|
||
* Context diagrams | ||
* Lists of communication partners and their interfaces. | ||
## Business Context | ||
|
||
[role="arc42help"] | ||
|
||
.Further Information | ||
### Contents | ||
|
||
See https://docs.arc42.org/section-3/[Context and Scope] in the arc42 documentation. | ||
* *Users:* They interact directly with the application through the user interface provided by the frontend using React, HTML, CSS, and JavaScript. | ||
* *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. | ||
|
||
**** | ||
--- | ||
|
||
### Motivation | ||
|
||
=== Business Context | ||
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. | ||
|
||
[role="arc42help"] | ||
**** | ||
.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. | ||
### Form | ||
|
||
.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. | ||
| *Quiz Game* | *Comunication Partners* | *Inputs* | *Outputs* | ||
| Users | User Interface | User answers | Game questions | ||
| Wikidata API | API Service | Question requests | JSON Responses | ||
|
||
**** | ||
|=== | ||
|
||
**<Diagram or Table>** | ||
--- | ||
|
||
**<optionally: Explanation of external domain interfaces>** | ||
### Context diagram | ||
[plantuml, "context", png] | ||
---- | ||
component "App" as app | ||
=== Technical Context | ||
:User: -> [app]: Answer question | ||
[app] -> User: Return result | ||
[role="arc42help"] | ||
**** | ||
.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. | ||
database DB | ||
[app] -> DB: Ask for question | ||
DB -> [app]: Return question | ||
component "WikiData" as wd | ||
[app] --> wd: Ask for keyword | ||
wd --> [app]: Return keyword | ||
---- | ||
|
||
.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. | ||
--- | ||
|
||
## Technical Context | ||
|
||
[role="arc42help"] | ||
|
||
.Form | ||
E.g. UML deployment diagram describing channels to neighboring systems, | ||
together with a mapping table showing the relationships between channels and input/output. | ||
### 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. | ||
|
||
**<Diagram or Table>** | ||
--- | ||
|
||
**<optionally: Explanation of technical interfaces>** | ||
### Deployment diagram | ||
[plantuml, "deployment", png] | ||
---- | ||
node "Aplication Server" as app | ||
node "DB Server" as db { | ||
artifact "MongoDB Server" | ||
} | ||
node Wikidata as w | ||
node Interface as i | ||
**<Mapping Input/Output to Channels>** | ||
app - db | ||
app -- w | ||
app -- i | ||
---- |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,32 +1,85 @@ | ||
ifndef::imagesdir[:imagesdir: ../images] | ||
|
||
[[section-solution-strategy]] | ||
== Solution Strategy | ||
|
||
# Solution Strategy | ||
|
||
[role="arc42help"] | ||
**** | ||
.Contents | ||
A short summary and explanation of the fundamental decisions and solution strategies, that shape system architecture. It includes | ||
## Contents | ||
This page contains a short summary and explanation of the fundamental decisions and solution strategies, that shape system architecture. | ||
|
||
--- | ||
|
||
### Technology Decisions | ||
Below, all the technologies to be used in the development of the application are listed: | ||
|
||
* *JavaScript / React:* A JavaScript library designed to facilitate the development of web applications. | ||
* *JavaScript / NodeJS:* An asynchronous runtime environment based on JavaScript. | ||
* *MongoDB:* A document-oriented NoSQL database system. | ||
* *Docker:* Used for deploying applications locally. | ||
* *Azure:* Used for deploying applications on a server. | ||
|
||
--- | ||
|
||
### Top-Level Decisions | ||
In this section, a summarized list of all decisions regarding the architecture of the application is included. | ||
|
||
|=== | ||
|
||
| *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 | ||
|
||
|=== | ||
|
||
--- | ||
|
||
### Quality Goals | ||
Next, several quality goals are established, along with the decisions made to achieve them. | ||
|
||
|=== | ||
| *Quality Goal* | *Decisions* | ||
|
||
| Usability | ||
| Creation of a responsive interface adaptable to all types of screens. | ||
|
||
| Accessibility | ||
| Compliance with accessibility standards to ensure a usable application. | ||
|
||
| Maintainability | ||
| A structured project that facilitates the maintainability of the application. | ||
|
||
| Testing | ||
| Assurance of a fully functional and error-free application. | ||
|
||
|=== | ||
|
||
--- | ||
|
||
### 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. | ||
|
||
* 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. | ||
Practices to be followed: | ||
|
||
.Motivation | ||
These decisions form the cornerstones for your architecture. They are the foundation for many other detailed decisions or implementation rules. | ||
* Division of the project into *tasks*. | ||
* Equitable *assignment* of tasks. | ||
* Frequent *meetings* on the progress of the application. | ||
* Construction of *"Alpha"* versions before the final release. | ||
|
||
.Form | ||
Keep the explanations of such key decisions short. | ||
Additionally, "Issues" and the GitHub-provided Kanban (ToDo - In Progress - Done) are used for communication. | ||
|
||
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. | ||
--- | ||
|
||
### Motivation | ||
This section addresses the fundamental decisions for the project's architecture. | ||
|
||
.Further Information | ||
|=== | ||
|
||
See https://docs.arc42.org/section-4/[Solution Strategy] in the arc42 documentation. | ||
| *Data Management* | | ||
| *Deployment* | | ||
| *Security* | | ||
| *Monitoring* | | ||
|
||
**** | ||
|=== |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.