# 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 待補 :::