System and Software Architecture Description (SSAD ...

System and Software Architecture Description (SSAD) Version 1.2

i SSAD_DCP_F20a_V1.2 Version Date: 10/22/2020

System and Software Architecture Description (SSAD)

MoveIntel Web App

Team 6

Guangyu Li Project Manager

Yu Deng Quality Focal Point

Austin Klein Operational Concept Engineer

Sheng Luo Requirements Engineer

Yitong Song Feasibility Analyst

Sebastian Val IIV & V

Xining Wang Prototyper

Heng Yan Life Cycle Plan

Weijie Ye Software Architect


ii SSAD_DCP_F20a_V1.2 Version Date: 10/22/2020

Version History Date Author Version Changes made Rationale

09/28/20 WY 0.1 • Original template of SSAD for DCP • Initial draft of SSAD before

development phase

10/02/20 WY 0.2 • Added Use-case Diagram

• Added Software Component

Diagram

• Added Hardware Component

Diagram

• Diagrams for ARB presentations

10/04/20 WY 0.3 • Added System Context Diagram

• Added Artifact Diagram

• Completed the draft of system

analysis

10/07/20 WY 0.4 • Added Deployment Diagram

• Added Web Framework Component

Diagram

• discussed more about and settled

down the deployment and web

framework

10/12/20 WY 1.0 • Update Process Realization

• Added System Analysis Rationale

Section

• Added Design Classes Section

• Focused more on Technology-

Independent Model

• Finish Technology-Independent

Model Section

10/17/20 WY, YD 1.1 • Updated Use-case description

• Improve diagrams of Use-case,

Hardware Component, Software

Component

• Added React Structure Diagram

• Added Backend and Database

Diagram

• Added Architectural Styles, Patterns

& Framework

• Changes after ARB Presentation

• Added more details on use-case

description

• Worked on technique-specific

models

• Sync with OCD

10/22/20 WY, YD 1.2 • Updated all diagrams

• Updated all contents

• Review among teammates


iii SSAD_DCP_F20a_V1.2 Version Date: 10/22/2020

Table of Contents

System and Software Architecture Description (SSAD) ............................................................ i Version History ............................................................................................................................. ii Table of Contents ......................................................................................................................... iii Table of Tables ............................................................................................................................. iv Table of Figures............................................................................................................................ vi

1. Introduction ............................................................................................................................. 1

1.1 Purpose of the SSAD .................................................................................................... 1

1.2 Status of the SSAD ....................................................................................................... 1

2. System Analysis ....................................................................................................................... 2

2.1 System Analysis Overview ........................................................................................... 2

2.2 System Analysis Rationale ......................................................................................... 17

3. Technology-Independent Model .......................................................................................... 18

3.1 Design Overview ......................................................................................................... 18

3.2 Design Rationale ......................................................................................................... 28

4. Technology-Specific System Design .................................................................................... 30

4.1 Design Overview ......................................................................................................... 30

4.2 Design Rationale ......................................................................................................... 36

5. Architectural Styles, Patterns and Frameworks ................................................................ 38


iv SSAD_DCP_F20a_V1.2 Version Date: 10/22/2020

Table of Tables

Table 1: Actors Summary................................................................................................................ 3

Table 2: Artifacts and Information Summary ................................................................................. 3

Table 3: Process Description – Log In ........................................................................................... 5

Table 4: Typical Course of Action - Log In: Successful ................................................................. 5

Table 5: Alternate Course of Action - Log In: Failure ................................................................... 6

Table 6: Process Description – Log Out ........................................................................................ 6

Table 7: Typical Course of Action - Log Out: Successful .............................................................. 6

Table 8: Exception Course of Action - Log Out: Failure ............................................................... 7

Table 9: Process Description – Create Account ............................................................................. 7

Table 10: Typical Course of Action - Log Out: Successful ............................................................ 7

Table 11: Exception Course of Action - Log Out: Failure ............................................................. 7

Table 12: Process Description – View Profile ............................................................................... 8

Table 13: Typical Course of Action -View Profile: Successful....................................................... 8

Table 14: Alternate Course of Action - View Profile and Edit ....................................................... 8

Table 15: Process Description – Manage Patients ........................................................................ 8

Table 16: Typical Course of Action - Manage Patient ................................................................... 9

Table 17: Alternate Course of Action - Manage Patient: Edit ....................................................... 9

Table 18: Process Description – Upload Video ............................................................................. 9

Table 19: Typical Course of Action - Upload video: No warning ................................................ 10

Table 20: Alternate Course of Action - Upload Video: warning .................................................. 10

Table 21: Process Description – Check Video ............................................................................. 10

Table 22: Typical Course of Action - Check videos ..................................................................... 10

Table 23: Process Description – Configure Analysis Request ..................................................... 11

Table 24: Typical Course of Action - Configure Analysis Request .............................................. 11

Table 25: Process Description – Request Video Analysis ............................................................ 11

Table 26: Typical Course of Action - Request Video Analysis ..................................................... 12

Table 27: Process Description – View Report .............................................................................. 12

Table 28: Typical Course of Action -View report ......................................................................... 12

Table 29: Process Description – Change Optimal Frame ........................................................... 12


v SSAD_DCP_F20a_V1.2 Version Date: 10/22/2020

Table 30: Typical Course of Action - Change optimal frame: Success ........................................ 13

Table 31: Alternate Course of Action - Change optimal frame: Failure ..................................... 13

Table 32: Process Description – Add Comment ........................................................................... 13

Table 33: Typical Course of Action - Add Comments: Successful ............................................... 14

Table 34: Alternate Course of Action - Add Comments: Failure ................................................. 14

Table 35: Process Description – Generate Line Graph ............................................................... 14

Table 36: Typical Course of Action – Generate Line Graph: Successful..................................... 15

Table 37: Hardware Component Description .............................................................................. 20

Table 38: Software Component Description................................................................................. 21

Table 39: Web Framework Component Description .................................................................... 21

Table 40: Design Class Description ............................................................................................. 22

Table 41: Video Upload Class Description .................................................................................. 23

Table 42: User Management Class Description ........................................................................... 24

Table 43: Video Analysis Class Description ................................................................................ 25

Table 44: Report Management Class Description........................................................................ 26

Table 45: Notification Class Description ..................................................................................... 27

Table 46: Hardware Component Description .............................................................................. 30

Table 47: Frontend React Structure Description ......................................................................... 32

Table 48: Backend Structure Description..................................................................................... 33

Table 49: Database Description ................................................................................................... 34

Table 50: NDI Component Description ........................................................................................ 35

Table 51: Connections Between Servers....................................................................................... 36

Table 52: Architectural Styles, Patterns, and Frameworks .......................................................... 38


vi SSAD_DCP_F20a_V1.2 Version Date: 10/22/2020

Table of Figures

Figure 1: System Context Diagram ................................................................................................ 2

Figure 2: Artifacts and Information Diagram ................................................................................ 3

Figure 3: Process Diagram ............................................................................................................ 5

Figure 4: Conceptual Domain Model ........................................................................................... 18

Figure 5: Hardware Component Class Diagram ......................................................................... 19

Figure 6: Software Component Class Diagram ........................................................................... 19

Figure 7: Deployment Diagram.................................................................................................... 20

Figure 8: Web Framework Component Class Diagram ............................................................... 20

Figure 9: Design Class Diagram .................................................................................................. 22

Figure 10:Video Upload Class Diagram ...................................................................................... 23

Figure 11: User Management Class Diagram ............................................................................. 24

Figure 12: Video Analysis Class Diagram ................................................................................... 25

Figure 13: Report Management Class Diagram ......................................................................... 26

Figure 14: Notification Class Diagram ........................................................................................ 27

Figure 15: Video Analysis Process Sequence Diagram ............................................................... 27

Figure 16: Report Management Process Sequence Diagram ...................................................... 28

Figure 17: Hardware Component Class Diagram ....................................................................... 30

Figure 18: Frontend React Structure Diagram ............................................................................ 32

Figure 19: Backend Structure & Database Diagram ................................................................... 33

Figure 20: NDI Component Diagram (Besides Hardware) ......................................................... 34

Figure 21: Video Analysis Process Sequence Diagram ............................................................... 36

Figure 22: 3-layer Server Structure ............................................................................................. 37


1 SSAD_DCP_F20a_V1.2 Version Date: 10/22/2020

1. Introduction

1.1 Purpose of the SSAD

The objective of the SSAD document is to offer the analysis the operational system, design the

thorough architecture for the system and act as a foundation of the implementation of the

MoveIntel AI movement analysis system for healthcare sports medicine. This document serves

as a basis of the whole development and a bridge between the foundation phase and development

phase with the system analysis as well as the model system design.

1.2 Status of the SSAD

This version of SSAD is the first version of the document, which is edited between the

foundation phase and development phase. At this point, we have completed all the design and

analysis before development and begin to develop and implement the project. Therefore, all the

sections of this document will be completed and finalized.



2. System Analysis

2.1 System Analysis Overview

The purpose of the Movement Analysis System is to provide sports medicine practitioners and

clients/patients with software that replaces expensive hardware used in movement analysis

evaluations. This automates data collection, reduces evaluation time from hours to minutes, and

reduces cost to help increase accessibility.

The mission includes 2 aspects. For clients/patients to receive greater access to high level

movement analysis technology so musculoskeletal pain, injuries, and surgery can be avoided.

For practitioners, to expedite analysis time, provide greater insights, and improve care overall.

2.1.1 System Context

Figure 1: System Context Diagram



Table 1: Actors Summary

Actor Description Responsibilities

Patient Users that requires movement

analysis • Upload videos

Practitioner Users that make clinical

decision for patients • Upload videos

• Adjust display settings

• Request video analysis

• Change optimal frames on report

• Comment on reports

• Generate graph for data

visualization

• Send notification to patients

• Handle a list of patients

MoveIntel A company which acts as the

owner and service provider of

the system

• Automate the process of movement

analysis

• Maintain data of users, videos and

reports

Algorithm A video algorithm on

movement analysis • Generate AI analysis results on

videos

2.1.2 Artifacts & Information

Figure 2: Artifacts and Information Diagram

Table 2: Artifacts and Information Summary

Artifact Purpose



ATF-1: Patient Profile Contains all information of a patient including the basic

information of the patient like age, name and education, the

practitioner of the user and the diagnosis history. This profile

is used for the system and other user interact with the patient.

ATF-2: Practitioner Profile Contains all information of a practitioner including the basic

information like name and certifications he owned, the

information about the practitioner’s clinic and the contact info

of the practitioner. This profile is used for the system and

other user interact with practitioner.

ATF-3: Patient List This artifact is automatically generated according to the

relationship between patients and practitioners. It contains the

practitioner and the patients belonging to his clinic.

ATF-4: Video The movement videos uploaded by the patients or

practitioners. The video is classified by patient on whom it is

taken. This is used for further analysis and storage.

ATF-5: Display Setting Contains the parameters set for the report generated from

video analysis by the practitioner. This includes display

settings templates set by parameters. The report will display

with statistical data and data visualization based on this

artifact. This artifact is used for reusing each time the

practitioner requests for a report.

ATF-6: Analysis Request

Form

Contains all information about an analysis request for

algorithm to process. This artifact includes the display setting,

certain videos and other information. It is used for the input of

the algorithm and report.

ATF7: Algorithm The movement analysis algorithm on videos.

ATF-8: Raw Result This artifact is automatically generated by the algorithms. It

contains the raw data, as the output of the algorithm. It is the

foundation of the report.

ATF-9: Report This artifact is originally generated by the movement analysis

system based on the analysis request form and the statistical

data analysis is based on display setting. It contains the

movement analysis and its corresponding frames. This artifact

can be edited by practitioner. This artifact is used for the final

result of the analysis process and clinical decision.

ATF-10: Frame It refers to the frame in videos. It is generated on the report

automatically and could be edited by practitioner. This artifact

is used for an important part of report.

ATF-11: Graph It refers to statistical graphs based on the data generated by the

algorithms. This artifact is used for data visualization.

ATF-12: Comment This artifact is generated by practitioners. It contains the

comments on the frames on the report as well as the whole

report. This artifact is used for an important part of report.

ATF-13: Notification This artifact is sent and received between system, practitioner

and patients. It contains important messages or remainders for

the recipient.



2.1.3 Behavior

Figure 3: Process Diagram

2.1.3.1 Authentication

2.1.3 .1 .1 Log In

Table 3: Process Description – Log In

Identifier UC-1 Log In

Purpose Determine whether user is a patient or a practitioner

Requirements OC-1 Sign up and authentication

Development

Risks

None

Pre-conditions System database is properly initialized

Post-conditions If user is authorized, he is given access to the system based on his

role. Otherwise, he cannot access any information.

Table 4: Typical Course of Action - Log In: Successful

Seq# Actor’s Action System’s Response



1 [user] Enters a username and

password

2 [user] Clicks login

3 Sends username and password to the

authentication module of the web app

4 [AWS]Sends authentication

verification and user session data

5 Redirect the actor to his role’s

homepage

Table 5: Alternate Course of Action - Log In: Failure


1-4 Refer to typical course of action

5 Display an error message indicating

wrong combination

2.1.3 .1 .2 Log Out

Table 6: Process Description – Log Out

Identifier UC-2 Log Out

Purpose To log out of the system


Development

Risks

None

Pre-conditions System database is properly initialized.

Login session exists.

Post-conditions The user login session is terminated and cannot access

information from the website.

Table 7: Typical Course of Action - Log Out: Successful


1 [user] Clicks the logout button

2 Signal the authentication module with

the user session data

3 [AWS] Returns the logout

verification and data

4 Display a message indicating successful

logout

5 Redirect the actor to the login page



Table 8: Exception Course of Action - Log Out: Failure


1-4 [user]Tries to logout

5 Display an error message indicating

user has not logged in yet.

2 .1 .3 .1 .3 Create Account

Table 9: Process Description – Create Account

Identifier UC-3 Create Account

Purpose To create an account for new users


Development

Risks

None

Pre-conditions System database is properly initialized;

Post-conditions New user’s information is stored in AWS database

Table 10: Typical Course of Action - Log Out: Successful


1 [user] Clicks the Register button

2 Redirect the actor to register page

3 [user] Enters all the necessary

entries

4 Check the database whether username

is not used yet

5 Display a registration successful

message

6 Redirect the actor to the home page of

his role

Table 11: Exception Course of Action - Log Out: Failure


1-4 Refer to the typical course of action

5 Display an error message indicating the

user failed to register for a new account



2.1.3.2 User Management

2.1.3 .2 .1 V iew Profi le

Table 12: Process Description – View Profile

Identifier UC-4 View profile

Purpose To check personal information

Requirements OC-8 User management

Development

Risks

None

Pre-conditions System database is properly initialized; User has logged in to the

system.

Post-conditions New user’s information is stored in AWS database

Table 13: Typical Course of Action -View Profile: Successful


1 [user] Clicks the My Profile

button

2 Redirect the actor to profile page

3 Load the page with user info from

database

Table 14: Alternate Course of Action - View Profile and Edit



4 [user] Edit the info

5 Send and store the edited field to

database

6 Reload the profile page

2 .1 .3 .2 .2 Manage Pat ients

Table 15: Process Description – Manage Patients

Identifier UC-5 Manage Patient

Purpose To have an overview of the patient, and add more patients

Requirements OC-7 Patient management OC-9 Security feature



OC-10 Tracking system

Development

Risks

None

Pre-conditions Current user is practitioner

Post-conditions New user’s information is stored in AWS database under this

practitioner

Table 16: Typical Course of Action - Manage Patient


1 [practitioner] Open the home

page

2 Load the page with patient table

Table 17: Alternate Course of Action - Manage Patient: Edit



3 [practitioner] Click the Add

Patient button

4 Redirect actor to add patient’s page

5 [practitioner] Enter the patient’s

info and submit

Store the patient info under this

practitioner

2.1.3.3 Video Operation

2.1.3 .3 .1 Upload Video

Table 18: Process Description – Upload Video

Identifier UC-6 Upload Videos

Purpose To upload videos for further analysis

Requirements OC-2 Video uploader OC-11 Information storage

Development

Risks

None

Pre-conditions System database is properly initialized; User has logged in to the

system.

Post-conditions New video is stored in S3



Table 19: Typical Course of Action - Upload video: No warning


1 [user] Clicks Add New Video

button

2 Redirect the actor to upload page

3 Load the page with already uploaded

video in the same task

4 [user] Select local videos to

upload

5 Store the new video to s3 bucket

6 Redirect actor to patient detail page

Table 20: Alternate Course of Action - Upload Video: warning



5 System warns users that the video does

not meet the standard

6-8 Refer to the typical course of

action 4-6

2 .1 .3 .3 .2 Check Video

Table 21: Process Description – Check Video

Identifier UC-7 Check videos

Purpose To play the videos and decide whether it is good or not

Requirements OC-6 Video player

Development

Risks

None

Pre-conditions Video is properly stored in database

Post-conditions Video starts playing

Table 22: Typical Course of Action - Check videos


1 [user] Click on a video

2 Play the video in new window



2.1.3.4 Analysis Preparation

2.1.3 .4 .1 Conf igure Analysis Request

Table 23: Process Description – Configure Analysis Request

Identifier UC-8 Adjust Settings

Purpose To prepare inputs for analysis algorithm

Requirements OC-3 Movement analysis

Development

Risks

None

Pre-conditions Parameters and videos should be available to select on the page.

Post-conditions All inputs are settled.

Table 24: Typical Course of Action - Configure Analysis Request


1 [practitioner] Clicks the Analyze

button in patient task page

2 Redirect the actor to param page

3 Load the page with available

parameters and videos for current task

4 [practitioner] Selects parameters

and videos

2 .1 .3 .4 .2 Request V ideo Analys is

Table 25: Process Description – Request Video Analysis

Identifier UC-9 Request Video Analysis

Purpose To send the videos to analyze

Requirements OC-3 Movement analysis

Development

Risks

None

Pre-conditions Parameters and videos have been selected

Post-conditions Report will be generated, stored and displayed.



Table 26: Typical Course of Action - Request Video Analysis


1 [practitioner] Clicks the Analyze

button in patient task page or

param page

2 Send the parameters and videos to EC2

to analyze

3 Display a pop-up window indicating

success of sending to analyze

4 Redirect actor to patient task page

2.1.3.5 Report

2.1.3 .5 .1 V iew Report

Table 27: Process Description – View Report

Identifier UC-10 View report

Purpose To check the report

Requirements OC-4 Report generation OC-14 Data Visualization

Development

Risks

None

Pre-conditions Report is successfully generated

Post-conditions Report is stored in database

Table 28: Typical Course of Action -View report


1 [user] Clicks the view report

button

2 Redirect the actor to report page

3 Load the page with visualized data

2 .1 .3 .5 .2 Change Opt imal Frame

Table 29: Process Description – Change Optimal Frame

Identifier UC-11 Change Optimal Frames

Purpose To correct the report because sometimes analysis algorithm

produces the wrong optimal frames



Requirements OC-5 Report editing

Development

Risks

None


Post-conditions Modified report is stored in database

Table 30: Typical Course of Action - Change optimal frame: Success


1 [practitioner] Clicks the view

report button


3 Load the page with visualized data and

video

4 [practitioner] Play the video,

pause at desired image and click

change button

5 Frame number is received at backend

6 Frame number is sent to database

7 Backend receives the corresponding

picture of that frame

8 Display the picture on page

9 [practitioner] Drag the picture to

desired place

10 [practitioner] Click save button

11 Modification is stored

Table 31: Alternate Course of Action - Change optimal frame: Failure



2 Display an error indicating saving fails

2 .1 .3 .5 .3 Add Comment

Table 32: Process Description – Add Comment

Identifier UC-12 View report

Purpose To check the report




Development

Risks

None



Table 33: Typical Course of Action - Add Comments: Successful



report button



4 [practitioner] Click the edit icon

near textbox

5 Textbox becomes editable

6 [practitioner] Write comments

and click finish

7 Modified comment is stored in database

8 Display the modified comment

Table 34: Alternate Course of Action - Add Comments: Failure



7 An error message displays, indicating

saving fails

2 .1 .3 .5 .4 Generate L ine Graph

Table 35: Process Description – Generate Line Graph

Identifier UC-13 Generate Line Graph

Purpose Practitioner has an option to include the line graph in report


Development

Risks

None





Table 36: Typical Course of Action – Generate Line Graph: Successful



report button



4 [practitioner] Click the graph tab

5 Switch to the graph tab


2.1.3.6 Notification

2.1.3 .6 .1 Send Not i f icat ion

Table 37: Process Description – Send Notification

Identifier UC-14 Send Notifications

Purpose To send the notification to practitioner once report is completed

Requirements OC-16 Notification system

Development

Risks

Do not have enough time


Post-conditions Practitioner receives the notification

Table 38: Typical Course of Action - Send Notification: Successful


1 Sends a notification message once

analysis algorithm finishes to backend

2 Display a message at homepage

indicating a task is complete

3 [practitioner] View the new task

Table 39: Alternate Course of Action - Send Notification: Failure


1 Refer to typical course of action



2 Notification sending fails

2.1.3.7 Setting

2.1.3 .7 .1 Change Display Set t ing

Table 40: Process Description – Change Display Setting

Identifier UC-15 Change settings

Purpose To allow practitioner modify how the data is displayed by default

Requirements OC-13 Settings panel

Development

Risks

Difficult to implement because frontend needs to change the

display structure

Pre-conditions None

Post-conditions New settings info is stored under current user

Table 41: Typical Course of Action - Change settings: Successful


1 [Practitioner] Click the settings

menu

2 Direct the actor to settings page

3 [practitioner] Select some of the

settings button and save

4 Save the new settings for the users in

database

Table 42: Alternate Course of Action - Send Notification: Failure



4 Display saving settings fails

2.1.4 Modes of Operation

The MoveIntel Movement Analysis System will operate in only one mode, as required by

MoveIntel and designed by our team, so nothing further need to be stated in modes of operation

part.



2.2 System Analysis Rationale

As introduced in previous sections, we have identified 2 classes of operational stakeholders:

1. Patients: these users include people who suffers from pain or injuries or need a better

movement pose during doing sports. Our system can help patients get results faster, have a more

thorough understanding of what they need to do, and have a long-term resource to help maintain

the benefits of analysis. Overall, this can help improve their mechanics, stop injuries, and prevent

unnecessary surgeries during doing sports.

2. Practitioners: these users include people who own mall sports medicine clinics and need to

make clinical decision on their patients. From our system, they can get results in near real time,

and allows them to quickly draw insights on the data with the data visualizations, to help with

clinical decisions.

There are two components of our system which requires further explanations:

1. Algorithm: It is a movement analysis algorithm provided by MoveIntel. The video is the input

of the algorithm, and a textual data is the output. In the data, there are overall information of the

videos and the analysis of each frame. The analysis includes the key angel of each body parts and

the pose of that frame.

2. Display Settings: It is stored in the type of template. In each template, the practitioner can set

and description of each key angel of each body part, so that the report will display the description

based on the data provided by the output of the algorithm. This will make the report much easier

to read for the users.

Current System:

There is also a current service run by MoveIntel for movement analysis. However, it requires the

user to send videos to us via Dropbox and we manually input them into our server so our

algorithm can process the image and video data. Then we manually put in the JSON files into our

data visualizations (Power BI). Then we manually send the data back to our users. This is a time-

consuming process on our end. And a poor user experience for the practitioner and patient/client

who must wait up to 24 hours to see the results. This impedes the practitioner’s ability to help

their clients and limits the ability to make clinical decisions.



3. Technology-Independent Model

3.1 Design Overview

3.1.1 System Structure

Figure 4: Conceptual Domain Model



Figure 5: Hardware Component Class Diagram

Figure 6: Software Component Class Diagram



Figure 7: Deployment Diagram

Figure 8: Web Framework Component Class Diagram

Table 37: Hardware Component Description

Hardware Component Description Networked Computer The PC or tablets owned by users of our system. They are

connected on the Internet and can access to the server held by

MoveIntel. Web Server A server that accepts the connections from the Internet and run the

frontend user interface as well as the backend business logic.



AI Server A server communicates the backend web server. It runs the

algorithms, which has high performance on graphic processing as

well as AI algorithms computation. Persistence Storage A storage communicates with backend web server and works as

the database of the system. It stores textual data in database. Large File Storage A storage communicates with the frontend web server, and stores

the videos uploaded by users, which has a huge storage.

Table 38: Software Component Description

Software Component Description User interface Component This component contains all web pages in Movement Analysis

System. It is shown to all users of this system. It includes all user

interface of this system. Video Management

Component This component performs functions related to the operations of

the videos. It includes:

• upload the videos

• view the uploaded videos

• delete the videos User Management

Component This component contains two main functions. The first is the

authentication function including log in, log out and register. The

second contains user management. The user can view and edit its

profile, and the practitioner can view the profiles of his patients. Video Analysis

Component This component performs the core functions of our system. It

contains all main functionalities of the movement analysis

process. These functionalities include:

• request movement analysis

• adjust report display setting

• view the reports

• adjust frames on report

• add comments on report

• choose graph for data visualization Notification Application

Component This component includes the notification function among the

system, practitioners and patients. DMBS This is the database management system that stores all textual

data used by the system. File Storage This is the file storage system that stores all videos uploaded to

the system.

Table 39: Web Framework Component Description

Support Software Component Description



Browser A browser that connects to the Movement Analysis

System web application and is responsible for displaying

web pages. Web Pages The web pages, act as user interfaces, created by the

Movement Analysis System. Web Server Component The server component receives the requests from the

Internet to the website. All business logical computations

are done. AI Server Component The server component is where the algorithms resides on.

All graphic computations and analysis are done on this

component.

3.1.2 Design Classes

3.1.2.1 Interface Classes

Figure 9: Design Class Diagram

Table 40: Design Class Description

Class Type Description



LoginPage Boundary Login page.

RegisterPage Boundary Register page.

PractitionerHomePage Boundary The practitioner home that shows all the

clients of the practitioner.

PatientDetailPage Boundary Display all tasks for one patient. This is also

the home page for patient.

UploadVideoPage Boundary Upload videos and display videos uploaded

AnalyzePage Boundary Let users choose parameters and videos to do

analysis

ReportPage Boundary Shows the analysis report

EditKeyFramePage Boundary Let users correct wrong key frames.

EditContentPage Boundary Let practitioner choose what to show on

report.

GenerateGraphPage Boundary Let practitioner choose graph for data

visualization.

OverallDisplaySettingPage Boundary Let user change overall display.

ImageDisplaySettingPage Boundary Let user change image display.

NormativeValueSettingPage Boundary Let user change normative values.

NotificationViewPage Boundary Let user view the notifications

3.1.2.2 Video Upload Classes

Figure 10:Video Upload Class Diagram

Table 41: Video Upload Class Description


VideoUploadController Component Contains all the management operation

including upload, delete, view videos and

related functions.

Video Entity Videos uploaded by users.



3.1.2.3 User Management Classes

Figure 11: User Management Class Diagram

Table 42: User Management Class Description


AuthenticationController Component Contains all authentication service including

logging in, creating account for patients and

practitioners.

PatientManagementController Component Contains all the functions for management

operated by practitioner on their patients,

including adding and deleting patients.

PatientProfile Entity Contains all information about a patient.

PractitionerProfile Entity Contains all information about a practitioner.

PatientList Entity Set of patients managed by a practitioner.



3.1.2.4 Video Analysis Classes

Figure 12: Video Analysis Class Diagram

Table 43: Video Analysis Class Description


DisplaySettingController Component Contains all the logical computation for

adjusting display settings related functions.

VideoAnalysisController Component Contains all functions of the management

operated by practitioner on their patients,

including adding and deleting patients.

DisplaySettingForm Entity Contains all display settings including overall

setting, image setting and normative

parameter setting.

RequestAnalysisForm Entity Contains all information submitted by

practitioner to request movement analysis.

This includes the information about patient.

video and settings.

Video Entity The videos to be analyzed.

Algorithm Entity The algorithm running the movement

analysis.

RawReport Entity Output report generated by the algorithm.

3.1.2.5 Report Management Classes



Figure 13: Report Management Class Diagram

Table 44: Report Management Class Description


ReportMgtController Component Contains all logical computations for report

management related functions.

Comment Entity Comments the practitioners add on the

reports.

RawReport Entity Output report generated by the algorithm.

Graph Entity Data visualization graphs

Frame Entity Frame of the video displayed on the report.

Report Entity The movement analysis report used for

clinical decision and viewed by users.

3.1.2.6 Noti fication Controller



Figure 14: Notification Class Diagram

Table 45: Notification Class Description


NotificationController Component Contains all logical computations for

notification related functions.

Notification Entity Notifications among system, practitioners,

and patients.

3.1.3 Process Realization

In this part, we will show the high-risk processes in our system. Each diagram shows the

implementation of the process using the design classes which has been introduced previously.

The following sequence diagram is for the Video Analysis process.

Figure 15: Video Analysis Process Sequence Diagram

The following sequence diagram is for the Report Management process.



Figure 16: Report Management Process Sequence Diagram

3.2 Design Rationale

We applied a 3-layer web app architecture, which is the most advanced and popular design

nowadays. It has high capability of extension and flexibility.

The three layers of architecture is shown as follows:

1. User Interface Layer:

User Interface Component

2. Business Logic Layer:

User Management Component

Video Upload Component

Video Analysis Component

Notification Component

3. Data Access & Engine Layer:

DBMS

File Storage

AI Algorithm

The client provides the components in the data access & engine layer on AWS. What we need to

develop is the user interface layer and the business logic layer the interaction between these three

layers.

The User Interface Layer has only one component, the User Interface Component, which refers

to the frontend web pages. The frontend will show the contents to the users, make request to



backend based on the operation of the users and handle the logic of web page redirection.

However, it will never do the business logic computation or interact with the database.

Additionally, it will directly with file storage for video storage.

The Business Logic Layer is the backend of our system. It is separated into 5 components, and

each of them has individual functions. They will never overlap with others’ functions because

they are broken down in a delicate way. For example, one can never upload a video through

Video Analysis Component, even though that video is very important in Video Analysis

Component. The business logic will response to requests from the frontend and interact with

DBMS for storage and AI algorithm for analysis.

The reason why we do not develop the frontend and backend together is mainly because that we

may develop mobile app version of our system in the future. If we develop them together, we

need to develop the backend again when working on the mobile version. If we develop them

separately, we can just develop the mobile app frontend and then connect with the backend we

are developing now for the mobile version. Separating the frontend and backend offers much

more capability of extension.



4. Technology-Specific System Design

4.1 Design Overview

4.1.1 System Structure

4.1.1.1 Hardware Component Class

The hardware we select are mainly from AWS. We select the most suitable server/storage from

AWS for each hardware component for better performance and lower cost.

Figure 17: Hardware Component Class Diagram

Table 46: Hardware Component Description

Hardware Component Description User Terminal The PC/tablet which can access to the Internet through browser.

Mobile terminal may be included later. AWS t2.micro Acts as web server.

T2 instances are a low-cost, general purpose instance type that

provides a baseline level of CPU performance with the ability to

burst above the baseline when needed.



It runs both the frontend and backend server of our project. It can

satisfy all we need from a web server.

“micro” refers to a relatively lightweight server in t2. AWS g3.4xlarge Acts as AI server.

g3 instances are the latest generation of Amazon EC2 GPU

graphics instances that deliver a powerful combination of CPU,

host memory, and GPU capacity.

It runs the algorithm provided by MoveIntel which requires high-

performance GPU computation. AWS DynamoDB Acts as persistence storage (database).

DynamoDB is a key-value and document database that delivers

low latency performance at any scale.

It is a kind of NoSQL, easy to implement and manage textual data

in our system, and better for further extension. AWS S3 Acts as large file (video) storage.

S3 is an object storage service with high data availability, security

and performance.

It can store videos easily, securely and last for a long term.

4.1.1.2 Frontend React Structure

The framework we select for frontend is React, and we also select Ant Design as React UI

library.

The following figure is the structure of our React project. In the figure, all the main web pages of

our system are in /src/page directory. Each web page is a folder which contains three files:

index.tsx, model.js and style.less. We can just inspect on these folders representing web pages

for further description.



Figure 18: Frontend React Structure Diagram

Table 47: Frontend React Structure Description

Frontend Component Description uploadVideo Refers to UploadVideoPage in software component architecture. analyze Refers to AnalyzePage in software component architecture notification Refers to NotificationPage in software component architecture Report Refers to ReportPage in software component architecture generateGraph Refers to GenerateGraphPage in software component architecture editFrame Refers to EditFramePage in software component architecture editComment Refers to EditCommentPage in software component architecture overallSettings Refers to OverallSettingPage in software component architecture normativeParaSetting Refers to NormativeParaPage in software component architecture imageSettings Refers to ImageSettingPage in software component architecture register Refers to RegisterPage in software component architecture patientDetail Refers to PatientDetailPage in software component architecture practitionerHome Refers to PractitionerHomePage in software component

architecture login Refers to LoginPage in software component architecture



4.1.1.3 Backend Flask & Database Structure

In this part, we will discuss the structure the backend and database structure, which is the regular

web app backend structure. Flask is adopted as the backend framework and AWS DynamoDB is

adopted as the database. The .py files are from Flask and table elements are from database.

Figure 19: Backend Structure & Database Diagram

Table 48: Backend Structure Description

Backend Component Description user_management.py Refers to UserMgtController in software component

architecture. authentication.py Refers to AuthenticationController in software component

architecture. video_analysis.py Refers to VideoAnalysisController in software component

architecture. display_setting.py Refers to DisplaySettingController in software component

architecture. report_management.py Refers to ReportMgtController in software component

architecture. video_upload.py Refers to VideoUploadController in software component

architecture.



notification.py Refers to NotificationController in software component

architecture.

Table 49: Database Description

Table Description user Textual data of user information including patients and

practitioners process Textual data of the analysis process requested in the

system video Textual data and meta data of the videos uploaded setting Textual data of the display setting stored by the

practitioners notification Textual data of notifications sent in the system report Textual data of all reports in the system

4.1.1.4 NDI Component Structure

In this part, we focus on the NDIs we adopt in our system. In the hardware component part, we

have introduced several NDIs from AWS. In this part, we will continuously introduce other

NDIs we adopted which is important to our system.

Figure 20: NDI Component Diagram (Besides Hardware)



Table 50: NDI Component Description

Support Software Component Description React A frontend JavaScript library (framework) for building

interfaces or UI components. The user interfaces including

the webpage and the logic relationship between them are

done by React. The request to backend function should

also be initialized by React. Ant Design A React UI library with a set of high-quality React

components. We can have feasible and pretty components

for our user interface from Ant Design. Furthermore, it

also provides a structure for a complete website, and we

can develop on it directly. Flask A backend web framework written in Python. It will

response to the request from the frontend, interact with the

database for textual data, run the business logic of our

system and so on. AWS Lambda An AWS service which let user run code without

provisioning or managing servers. For the algorithms, we

can just use AWS Lambda to run the code to process the

algorithms set in AWS g3. Algorithm The movement analysis algorithms on videos built by

MoveIntel and set in AWS g3.

4.1.2 Process Realization

In this part, we will show the high-risk processes in our system in the view of technique. We

have adopted several techniques and we will show the interaction among them in sequence.

The following sequence diagram is for the Video Analysis process.



Figure 21: Video Analysis Process Sequence Diagram

4.2 Design Rationale

As mentioned in Section 3.2, we run a 3-layer architecture for our web app, we separate the

server as designed.

User Interface Layer

Frontend ----- AWS t2.micro Server one

Business Logic Layer

Backend ----- AWS t2.micro Server two

Data Access & Engine Layer

Database ----- AWS DynamoDB

Algorithm ----- AWS g3

Video Storage ----- AWS S3

Table 51: Connections Between Servers

Server 1 Server 2 Transferring info

Frontend Backend All request and response of the system

Frontend Video Storage Videos uploaded

Backend Algorithms Movement Analysis request and result

Backend Database Textual data transfer

Video Storage Algorithms Retrieve the video for analysis



Figure 22: 3-layer Server Structure



5. Architectural Styles, Patterns and

Frameworks

Table 52: Architectural Styles, Patterns, and Frameworks

Name Description Benefits, Costs, and Limitations

3-layer

Architecture

The 3-layer architecture separate the

application into 3 different layers,

user interface, logic and data access.

Benefits: it allows for increased

abstraction between the layers of

components. It also allows the

independence of each layer, so it enables

a single model to have multiple views. It

increases the extension and flexibility for

further development.

Costs: Increase the complexity and the

size of application. It requires more

workload on interact between layers.

React React is an open-source, front

end, JavaScript library for

building user interfaces or UI

components.

Benefits: it allows reusable component

which make the development faster. It

also simplifies the overall process of

scripting components. It also enables

quick rendering.

Cost: Harder to learn than simple

css/javascript/html. Flask Flask is a micro web

framework written in Python.

Benefits: It allows simpler development

than other frameworks like Django and

Spring. It allows modular code with high

efficiency.

Limitation: It has no standardized coding

guideline, so it is easy to develop with

worse codes. It has fewer tools.

DynamoDB A NoSQL database, a key-value and

document database

Benefits: easy to manage and implement,

easy to extend in the future

Limitation: Lack of functions than

relational databases have.

https://en.wikipedia.org/wiki/Open-source

https://en.wikipedia.org/wiki/Front_end_and_back_end

https://en.wikipedia.org/wiki/Front_end_and_back_end

https://en.wikipedia.org/wiki/JavaScript_library

https://en.wikipedia.org/wiki/User_interfaces

https://en.wikipedia.org/wiki/Web_framework

https://en.wikipedia.org/wiki/Web_framework

https://en.wikipedia.org/wiki/Python_(programming_language)

https://en.wikipedia.org/wiki/Database

Date post:	04-Apr-2022
Category:	Documents
Upload:	others
View:	7 times
Download:	0 times

System and Software Architecture Description (SSAD ...

Documents