---
# System prepended metadata

title: Testbed v3.0 SRS - Use Case
tags: [Testbed]

---

# Testbed v3.0 SRS - Use Case

###### tags: `Testbed`

## Use Case

### Login
    
1. User enters **username**.
2. User enters **password**.
3. User click *login* button.
4. System checks if the **username** and **password** are valid.
5. System directed User to DSAL editor page.

:::info
noun: username, password
:::

```=
POST /api/token : Get a token by sent account and password

param: {
    username: string,
    password: string
}
```

```sequence
User->Browser: User enters username and password
User->Browser: User click “login” button
Browser->Backend: POST /api/token
Backend->Browser: Resposne token
Browser->Browser: Save the token into Cookie
Browser->User: Redirect user to DSAL editor page 
```

### Logout

1. User click *logout* button on top bar.
2. System remove the cookie which save the authentication token.
3. System redirect to login page.


```sequence
User->Browser: User click "logout" button
Browser->Browser: System remove the Cookie \n which store the token
Browser->User: System redirect to login page
```

### Create a new blank DSAL

1. User dropdown the DSAL menu.
2. User select "New…" selection.
3. System show a modal on browser, which contain a blank let user input DSAL filename. Besides, the input blank only let user input filename and user don’t need to add .yml or .yaml.
4. User enters **filename of new DSAL**.
5. User click *yes* button to create a new DSAL.
6. System create a new DSAL.
7. If System successfully create a new DSAL, then showing the default sample and DSAL filanem on browser.
8. System response **DSAL filename** and **DSAL content.**
9. User can see the new DSAL content on DSAL editor.

:::info
noun: filename of new DSAL, DSAL content
:::

```=
POST /api/dsals

param: {
    token: <auth-token>,
    daslFilename: string,
    dsalContent: string
}

headers: {
    "Content-Type": "application/json"
}
```

```sequence
User->Browser: User dropdown the DSAL menu
User->Browser: User select "New..." seletion
Browser->Browser: Sysetm show a modal on browser
User->Browser: User enters the filename \n of new DSAL on the modal
User->Browser: User click "yes" button
Browser->Backend: POST /api/DSAL
Backend->Database: Save a new DSAL
Database->Backend: Return the new DSAL \n which just saved to database
Backend->Browser: Response new DSAL \n with DSAL sample content
Browser->User: Display the DSAL filename \n and DSAL content on DSAL editor
```

### Create a new DSAL after writing DSAL content

1. User write **DASL content** on DSAL editor.
2. User click "Save" button.
3. System show a modal on browser, which contain a blank let user input DSAL filename. Besides, the input blank only let user input filename and user don’t need to add .yml or .yaml.
4. User enters **filename of new DSAL**.
5. User click "yes" button to create a new DSAL.
6. Sysetm verify the created DSAL is valid. If the DSAL is valid, system save the new DSAL into database.
7. If system successfully create a new DSAL, system response DASL filename and DSAL content.
8. User can see the new **DSAL filename** and **DSAL content** on DSAL editor.

:::info
noun: DASL filename, DSAL content
:::

```=
PSOT /api/dsals

param: {
    token: <auth-token>,
    dsalFilename: string,
    dsalContent: string
}

headers: {
    "Content-Type": "application/json"
}
```

```sequence
User->Browser: User write DASL content on DSAL editor
User->Browser: User click "Save" button
Browser->Browser: Sysetm show a modal on browser
User->Browser: User enters the filename \n of new DSAL on the modal
User->Browser: User click "yes" button
Browser->Backend: PSOT /api/dsals
Backend->DSAL Module: Verify if the DSAL is valid
DSAL Module->Backend: Response validation result
Backend->Database: Save a new DSAL
Database->Backend: Return the new DSAL \n which just saved to database
Backend->Browser: Response new DSAL
Browser->User: Display the DSAL filename \n and DSAL content on DSAL editor
```

### Load DSAL

1. User dropdown the DSAL menu.
2. User select "Load from server" selection.
3. System show a modal on browser, which contain DSAL selection and filename filter that user can input some keyword to filter DSAL selections.
4. User dropdown the DSAL selection.
5. User select a **DSAL filename**.
6. User click *load* button.
7. System load the DSAL from database.
8. System response **DSAL filename** and **DSAL content.**

:::info
noun: DSAL filename, DSAL content
:::

```=
GET /api/dsals/name
GET /api/dsals/<dsal-filename>
```

```sequence
User->Browser: User dropdown the DSAL menu
User->Browser: User select "Load from server" selection
Browser->Backend: GET /api/dsals/name
Backend->Database: Get all of the dasls name
Database->Backend: Return all of the dasls name
Backend->Browser: Response all of the dsals name
Browser->Browser: Sysetm show a modal on browser
User->Browser: User dropdown the DSAL selection
User->Browser: User select a DSAL filename
User->Browser: User click "load" button
Browser->Backend: GET /api/DSAL?filename=string
Backend->Database: Get the DSAL from database
Database->Backend: Return the DSAL
Backend->Browser: Response the DSAL
Browser->User: Display the DSAL filename \n and DSAL content on DSAL editor
```

### Upload DSAL

1. User dropdown the DSAL menu.
2. User select "Upload from device" selection.
3. System show a modal on browser, which contain a browsing file button.
4. User click the browsing file button.
5. User select a DSAL on device.
6. System will verify the format of uploaded file is .yml or .yaml.
7. If the format is correct, user will see **the filename of uploaded file**.
8. User click "upload" button.
9. System verify if the format and values of the uploaded DSAL are valid. Otherwise, return error status.
10. System save the uploaded DSAL into database
11. User can see the uploaded DSAL filename and DSAL content on DSAL editor.

:::info
noun: DSAL filename
:::

```=
POST /api/dsals

headers: {
    "Content-Type": "multipart/form-data"
}

param: {
    token: <auth-token>,
    "dsalFilename": string,
    "dsalFile": file
}
```

```sequence
User->Browser: User dropdown the DSAL menu
User->Browser: User select "Upload from device" selection
Browser->Browser: Sysetm show a modal on browser
User->Browser: User click the browsing file button
User->Browser: User select a DSAL on device
Browser->Browser: System verify the format \n of uploaded file is valid.
Browser->User: System response the uploaded DSAL filename
User->Browser: User click "Upload" button.
Browser->Backend: POST /api/DSAL
Backend->DSAL Module: Verify if the DSAL is valid
DSAL Module->Backend: Response validation result
Backend->Database: Save a new DSAL
Database->Backend: Return the new DSAL \n which just saved to database
Backend->Browser: Response the DSAL
Browser->User: Display the DSAL filename \n and DSAL content on DSAL editor
```

### QoS validation

1. System use DSAL module to validate QoS setting.

:::info
noun: DSAL
:::

### Save DSAL

1. User click "save" button.
2. System save the **DSAL** into database.
3. System return the **DSAL** to user, then showing message to user that DSAL successfully save into database.
4. System show successfully saved message.

:::info
Noun: DSAL
:::

```=
PUT /api/dsals/<dsal-filename>

param: {
    token: <auth-token>,
    dsalFilename: string,
    dsalContent: string
}
```

```sequence
User->Browser: User click "save" button
Browser->Backend: PUT /api/DSAL
Backend->Database: System updated the DSAL
Database->Backend: Return the updated DSAL
Backend->Browser: Response the updated DSAL
Browser->User: Show successfully saved message
```

### Edit DSAL

1. User using DSAL editor to modify the **DSAL content**.

:::info
Nonu: DSAL content
:::

### ==Delete DSAL==

:::danger
待補
:::

### Visualize DSAL

1. User click "visualization" button.
2. System request to parse the **DSAL content** to **data setting**.
3. System convert the DSAL content to **data setting**.
4. System response the **data setting** to browser.
5. System render the **data setting** on browser.

:::info
noun: data setting, DSAL content
:::

```=
GET /api/dsal/<filename>/data-setting
```

```sequence
User->Browser: User click "visualization" button
Browser->Backend: GET /api/data_setting?dsal_filename=string
Backend->DSAL Module: Request to pare the DSAL
DSAL Module->Backend: Return the data setting
Backend->Browser: Reponse the data setting
Browser->User: Visualize the data setting
```

### View the available devices and pending task

1. System request to get the **available devices** and **pending task**
2. Display the number of **available devices** and the number of **pending task**.

:::info
noun: available device, pending task
:::

```=
GET /api/devices?token=<auth-token>
GET /api/emulations?token=<auth-token>
```

```sequence
User->Browser: Access emulation page
Browser->Backend: GET /api/devices
Backend->Redis: Get the number of devices
Redis->Backend: Return the number of devices
Backend->Browser: Response the number of devices
Browser->Backend: GET /api/emulations
Backend->Task Manager: Get the number of emulation tasks
Task Manager->Backend: Return the number of emulation tasks
Backend->Browser: Response the number of emulation tasks
Browser->User: Display the number available devices \n and the number of pending tasks
```

### Execute emulation

1. User enter **emulation time**.
2. User enter **report name**.
3. User click "execute" button.
4. System request to execute a emulation.
5. System add a emulation into task queue.
6. System response the task id
7. System show the message that a new task is pending to execute.


:::info
noun: emulation time, report name
:::

```=
POST /api/emulations

param: {
    token: <auth-token>,
    emulationTime: integer,
    reportName: string,
    dataSetting: json
}
```

```sequence
User->Browser: Enter emulation time and report name
Browser->Backend: POST /api/emulation
Backend->Task Manager: Request to execute a emulation
Task Manager->Backend: Return task id
Backend->Browser: Response task id
Browser->User: show the message that a new \n task is pending to execute
```

### ==Use DSAL to specify computing resource==

:::danger
待補
:::

### View emulation status

1. System read all task of task queue and get emulation status of the executing task.
2. System display the task status on browser.
3. User can see the emulation status which contains task name deciding by report name and take status.

:::info
noun: emulation status
:::

```=
GET /api/emulations
```

```sequence
User->Browser: Access task board page
Browser->Backend: GET /api/emulations
Backend->Task Manager: Get emulation status
Task Manager->Backend:  Return emulation status
Backend->Browser: Response emulation status
Browser->User: Display each task status
```

###  Cancel emulation

1. User click "cancel" button on a task card which present that the emulation task is pending to execute.
2. System request to cancel a emulation which haven't run yet.
3. System cancel the emulation.
4. User see the pending emulation disappear from the task board page.

:::info
noun: emulation
:::

```=
DELETE /api/emulations/<emulation-task-id>
```

```sequence
User->Browser: Click "cancel" button
Browser->Backend: DELETE /api/emulation/<task-id>
Backend->Task Manager: Delete the task
Task Manager->Backend: Return the removed task id
Backend->Browser: Response the removed task id
Browser->User: Remove the task card from website
```

###  Abort emulation

1. User click abort button on a task card which present that the **emulation** task is executing.
2. System request to abort a **emulation** which is executing.
3. System abort the **emulation**.
4. User see the executing **emulation** disappear from the task board page.

:::info
noun: emulation
:::

```sequence
User->Browser: Click "cancel" button
Browser->Backend: DELETE /api/emulation/<task-id>
Backend->Task Manager: Delete the task
Task Manager->Backend: Return the removed task id
Backend->Browser: Response the removed task id
Browser->User: Remove the task card from website
```

### Save performance report after emulation finished

1. After a emulation is finished, system will automatically transfer the device report into **performance report**.
2. Then system save the **performance report** into database.

:::info
Noun: performance report
:::

```sequence
Emulation Interface->Report parser: Request to parse the device \n report to performance report
Report parser->Emulation Interface: Return the performance report
Emulation Interface->Task Worker: Return the performance report
Task Worker->Task Manager: Return the performance report
Task Manager->Backend:  Return the performance report
Backend->Database: Save the performance report into database
```

### Select performance report

1. System load all the **performance report name** into browser.
2. User select a **performance report name**.
3. System get the **performance report** from database.
4. System response the **performance report** to user.
5. User see a **performance report** of a **emulation** with table.

:::info
Nonu: performance report name, performance report
:::

```=
GET /api/reports/name
GET /api/reports/<report-id>
```

```sequence
User->Browser: Access performacne report page
Browser->Backend: GET /api/reports-name
Backend->Database: Get all of the reports name
Database->Backend: Return all of the reports name
Backend->Browser: Response all of the reports name
Browser->User: Display all of the reports name
User->Browser: Select a report name
Browser->Backend: GET /api/report-name/<report-id>
Backend->Database: Get the performacne report from database
Database->Backend: Return the performance report
Backend->Browser: Response the performance report
Browser->User: Display the performance of a emulation \n with a table and bar chart.
```

### ==Delete performance report==

:::danger
待補
:::

###  Display performance report chart

1. System display the **performance report chart** of loss rate to user. The chart should present every loss rate of partition-publisher-topic-format combination.

:::info
Nonu: performance report chart
:::

```sequence
Browser->User: Display the performance report chart of lost rate
```

### Display performance report

1. System display the **performance report** of each partition-publisher-topic-format combination.

:::info
noun: performance report
:::

```sequence
Browser->User: Display the performance report in table
```

###  Download performance report

1. User click "download report(csv)" button.
2. System show the download modal on browser.
3. User select a directory in computer.
4. User confirm the download.
5. A **performance report** is downloaded into user’s device.

:::info
noun: performance report
:::

```=
GET /api/reports/<report-name>.csv
```

```sequence
User->Browser: Click "Download report(csv)" button
Browser->Browser: Show the download modal
User->Browser: Select a directory on computer
User->Browser: Confirm the download
Browser->Backend: GET /api/report-name/<report-id>?format=csv
Backend->Database: Get the performance report
Database->Backend: Return the performance report
Backend->Browser: Download the performance report
Browser->User: Get the performance report on computer
```

###  ==QoS recommendation==

:::danger
待補
:::