# Assignment 2: ADD: Insaf Safin, Tymur Lysenko, Idel Ishbaev, Ruslan Muravev, Vitaliy Korbashov

# Original Hackmd link (for better readability):
https://hackmd.io/Yp26QbeJSvu3OPtS2odX3w?both

# Links to the interation pictures:
1. https://i.imgur.com/Qw9mmX1.png
2. https://i.imgur.com/CFrfonN.png
3. https://i.imgur.com/oE4wV77.png
4. https://i.imgur.com/3qZi774.png
5. https://i.imgur.com/G7K9QpS.png
6. https://i.imgur.com/MUnv7bC.png

## Part 1: Refining Architectural Drivers

---

### Functional responsibilities

Application is divided into three parts:
1. Storage server
2. Web application
3. Mobile application

* Storage server must:
* store data received from the athlete's phone
* store personal training plans received from coach
* generate and send personal statistics using training data
* send personal training plans to athlete's phone
* receive and process athlete request to edit collected data of a completed workout

* Web application must:
* access relevant athlete data
* find athletes relevant to a specific coach and display their data:
* training history
* statistics
* current training plan
* real-time training information
* provide an interface to create and edit training plans

* Mobile application must:
* send training data to the server in a real-time manner
* request server to edit collected data of a completed workout when needed
* receive information from the server about
* statistical data about training from the server
* training plans from the server
* use a voice assistant to notify the athlete
* generate feedback on the technique of performing the exercise
* notify when the exercise is finished
* check compliance to a training plan
* fetch data from the athlete's smartwatch
* monitor athlete's training via video
* monitor athlete's state:
* exercise performance
* number of repetitions
* number of sets
* the time between sets
* the physical condition of the athlete during training, namely:
* pulse
* calories

---

### Constraints

* Centralized storage must be present
* The system must be agnostic to the location of training
* The main system interface for an **athlete** is a **mobile application**
* The main interface for the **coach** is a **web application**
* The data needs to be stored for up to 1 year for analytical purposes

---

### Engineering objectives

| Engineering objective | Quality Attribute and Scenario | Priority</br>(B,E) |
| --------------------- |------------------------------ | ------------- |
The system must provide a personal page with statistics for athletes |**Q1.Attribute**: Security</br></br>**Scenario**:athlete logs into the mobile application and 100% of data displayed belongs only to their account.| (H,L)|
A complementary device such as a smartwatch can be used to collect additional data and improve the overall accuracy.| **Q2.Attribute**: Interoperability</br></br>**Scenario**:athlete connects a complementary device to their mobile phone and 99% of data is fetched from it and data is not corrupted or lost.| (M,M)|
It is very important not to lose training data and transfer it in full to centralized storage. |**Q3.Attribute**: Integrity</br></br>**Scenario**: athlete or coach send/receive information to the server and 100% of it is not corrupted or lost.| (H,L)|
The system should include video monitoring of the athlete and give feedback/adjustments in real-time |**Q4.Attribute**: Performance</br></br>**Scenario**: athlete receives the relevant data(feedback or adjustments) from the application with the delay less than 3 seconds | (M,M)|
For analytics, historical purposes data up to a year is used. |**Q5.Attribute**: Traceability </br></br>**Scenario**: Coach requests information about athlete's trainings and get statistic about all workouts in the span of one year | (M,M)|

---

## Part 2: Apply ADD


### One-component system


**NOTE**: all responsibilities of the elements were previously described; putting all of them in one text square would simply result in an unreadable eyesore

## **ITERATION 1**

### Addressed driver: **The system must be agnostic to the location of training. The main system interface for an athlete is a mobile application.**

### Applied tactic:

Incorporating separate blocks for different types of users to interact with.
2-tiered pattern (client-server) is used for communication between them.

### Side effects:
It introduces network delay into communications between elements. Although it is required that the coach receives information about training in real-time, network delay is small and there is no alternative due to constraints.
It also introduces security problems, but they will be addressed in one of the next iterations (iteration 5).

### Resulting architectural diagram:


**NOTE**: all responsibilities of these elements were previously described; putting all of them in one text square would simply result in an unreadable eyesore

---

## **ITERATION 2**

### Addressed driver: **Centralized storage must be present. The data needs to be stored for up to 1 year for analytical purposes**

### Applied tactic:
Moving the datastore into a separate tier(database).

### Side effects:
Cost of the system increases because usage of a separate database that stores data for one year incurs additional costs. It can be tolerated as the application will generate revenue.

### Resulting architectural diagram:


---

## **ITERATION 3**

### Addressed driver: **The main interface for the coach is a web-interface**

### Applied tactic:
Applying "Split module" and "Encapsulate" to separate concerns.

### Side effects:
Server complexity increases. It is necessary to achieve coordination among system components. Can be tolerated via utilization of proper inter-component interfaces.

### Resulting architectural diagram:


---

## **ITERATION 4**

### Addressed driver: **Interoperability**

### Applied tactic:
Applying the "Split module" and "Discovery service" to achieve Q2.

### Side effects:
Mobile application complexity increases. It is necessary to achieve coordination among system components. Can be tolerated via utilization of proper inter-component interfaces.

### Resulting architectural diagram:


---

## **ITERATION 5**

### Addressed driver: **Security**

### Applied tactic:
Add authentication responsibilities to the storage server and the database to achieve Q1.

### Side effects:
Communication overhead due to the need to send authorization data. Can be tolerated as the overhead is negligible.

### Resulting architectural diagram:


---

## **ITERATION 6**

### Addressed driver: **Integriity**

### Applied tactic:
Make the storage server validate data as well as switch to TCP to achieve Q3.

### Side effects:
Real-time performance suffers a bit. The difference is negligible, so it can be tolerated.

### Resulting architectural diagram: