Skip to content

Commit

Permalink
Merge pull request #20 from Arquisoft/documentation_marcos
Browse files Browse the repository at this point in the history
Documentation marcos
  • Loading branch information
MarcosBarrilVillaverde authored Feb 16, 2024
2 parents 15a547f + 7111516 commit 64dc143
Show file tree
Hide file tree
Showing 3 changed files with 79 additions and 35 deletions.
3 changes: 3 additions & 0 deletions .vscode/settings.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
{
"asciidoc.antora.enableAntoraSupport": true
}
54 changes: 37 additions & 17 deletions docs/src/02_architecture_constraints.adoc
Original file line number Diff line number Diff line change
@@ -1,27 +1,47 @@
ifndef::imagesdir[:imagesdir: ../images]

[[section-architecture-constraints]]
== Architecture Constraints

=== Technical Constraints

[cols="1,2", options="header"]
|=========================================================================================================================================================================================================
| Constraint | Explanation
| Docker | The application will operate within a Docker environment.
| GitHub | We'll leverage GitHub as our remote repository for project development, task delegation among team members, and version control. GitHub streamlines communication and project organization.

|=========================================================================================================================================================================================================

=== Organizational Constraints

[cols="1,2", options="header"]
|==========================================================================================================================================================================================================================================================
| Constraint | Explanation
| Size of the team | The team comprises six individuals.
| Meetings | Weekly meetings are scheduled to discuss task organization during each laboratory class session. In the event of requiring an extraordinary meeting, various tools such as WhatsApp or Discord are employed to coordinate effectively.
| Testing | Various scenarios will be explored to ensure the app's functionality is tested. We'll employ a range of techniques to maximize test coverage, striving for comprehensive assessment.
| Experience | Team members possess limited experience with the diverse technologies being employed.
|==========================================================================================================================================================================================================================================================


=== Conventions

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

.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)
| Documentation
| The documentation must adhere to the Arc42 method, ensuring it is clear, simple, and effective.

| Accessibility
| The application should be user-friendly, allowing all individuals to navigate effortlessly, irrespective of any disabilities, ensuring inclusivity for all users.

.Further Information
| Programming Language conventions
| We ought to follow the conventions specific to the programming languages we're employing.

See https://docs.arc42.org/section-2/[Architecture Constraints] in the arc42 documentation.
| Clean Code
| The code in the application must be meticulously crafted and neat, with a focus on readability and maintainability.

****
| Mircroservices
| The application will be divided into microservices to facilitate its development.
|===
57 changes: 39 additions & 18 deletions docs/src/04_solution_strategy.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -3,30 +3,51 @@ ifndef::imagesdir[:imagesdir: ../images]
[[section-solution-strategy]]
== Solution Strategy

=== Technology Decisions

[role="arc42help"]
****
.Contents
A short summary and explanation of the fundamental decisions and solution strategies, that shape system architecture. It includes
In order to develop the application and adhere to the constraints, we selected the following technologies:

* 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.
- ReactJS: JavaScript library that streamlines the development of graphical interfaces for web applications.
- TypeScript: Extension of JavaScript, bolstering it with type support for improved development.
- GitHub: Platform offering remote repository services for project development, task management, and version control.
- MongoDB: A non-linear database selected to oversee storage of diverse application contents, with each microservice possessing its dedicated database.
- NodeJS: Facilitates efficient management of asynchronous events, notably beneficial for scalable network applications and database administration.
- Docker: Employed for seamless deployment of the application environment.

.Motivation
These decisions form the cornerstones for your architecture. They are the foundation for many other detailed decisions or implementation rules.
=== Top-level Decomposition

.Form
Keep the explanations of such key decisions short.
==== Diagramming tools

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.
We will use PlantUML and UMLet for creating the documentation's diagrams.

=== Approaches to Achieve Top Quality Goals

.Further Information
[cols="1,2,3"]
|===
| Quality Goal | Scenario | Solution Approach

See https://docs.arc42.org/section-4/[Solution Strategy] in the arc42 documentation.
| Privacy
| Users seek reassurance in the safety and privacy of their data within our app.
| Ensuring user data security and privacy within the application.

****
| Usability
| Seamless execution of all application functions is crucial for user satisfaction.
| Optimizing usability through the utilization of React.

| Maintainability
| Application architecture must facilitate seamless addition or modification of functionalities with minimal code changes.
| Implementing design patterns and adhering to code conventions to ensure clean and maintainable code. Additionally, prioritizing testing during development for long-term maintainability.

| Scalability
| The application's design must accommodate changes effortlessly throughout its lifecycle.
| Employing a microservices approach to minimize code repetition and enhance understanding of application distribution, ensuring future scalability.

|===

=== Organizational Decisions

We've established the following organizational guidelines:

- *Language*: Adhering to international standards, the project, encompassing code and documentation, will be developed in English as the primary language.
- *Issues:* All deliberations will be documented as issues on GitHub.
- *GitHub Projects:* Employing this tool, we'll plan the application's development process, utilizing GitHub's integrated features for efficient project management in accordance with AGILE methodology.

0 comments on commit 64dc143

Please sign in to comment.