Wakey Tracker: An Application for Emotion Tracking and Prediction in Adolescents

Abstract

Wakefield School is a school for emotionally and behaviorally disturbed students. They requested an application be developed to track their students emotions through an easy to use application.

This application has an easy to use interface, where students can quickly and easily enter their emotional state. Features include showing past emotions to students, along with a teacher mode, where a teacher can see emotions for all students in their class. Additionally, the application should implement a predictive feature, where it can predict a students future emotion.

This project will be developed the software development lifecycle, with prototyping. The application will be hosted on a cloud platform, with an emphasis on speed and usability of the application. Wakefield School will be used as a case study of this application, where they will be performing tests of the software.

Survey results show mild project success, with grounds for good future work.

This application has the potential of being a useful resource, especially to schools with emotionally disturbed students, where tracking and predicting emotion can assist teachers in keeping class running smoothly.

ACKNOWLEDGEMENTS

Duncan Wotherspoon-Brown: client. Was extremely keen and happy to help throughout project

Shauna Gillett: Principal. Maintained interest and gave extra feedback throughout course

Karen Blackmore: supervisor. Helped immensely with the entire project, gave great advice and spurred me on to achieve this thesis

Friends and family. To put up with me during my long hours working on this thesis. The stress relief will be felt on not just me, but them too

Kate Jones. Helped proof-read my thesis through my many drafts

Table of Contents

TOC o "1-3" h z u 1Introduction PAGEREF _Toc24719213 h 61.1Problem and Motivation PAGEREF _Toc24719214 h 61.2Objective PAGEREF _Toc24719215 h 91.3Organisation of this Thesis PAGEREF _Toc24719216 h 92Literature Review PAGEREF _Toc24719217 h 112.1Interface Design PAGEREF _Toc24719218 h 112.2Cloud Hosting Providers PAGEREF _Toc24719219 h 112.3Web Application Optimisations for Emotion Recording PAGEREF _Toc24719220 h 122.4Machine Learning for Emotion Prediction PAGEREF _Toc24719221 h 133Methodology and Design (15%) PAGEREF _Toc24719222 h 143.1Introduction to the Software Development Methodology PAGEREF _Toc24719223 h 143.2Requirements Phase PAGEREF _Toc24719224 h 143.2.1Functional Requirements PAGEREF _Toc24719225 h 143.2.2Non-Functional Requirements PAGEREF _Toc24719226 h 153.3Design Phase PAGEREF _Toc24719227 h 153.3.1Use Case Diagram PAGEREF _Toc24719228 h 153.3.2Activity Diagrams PAGEREF _Toc24719229 h 173.3.3System Diagrams PAGEREF _Toc24719230 h 193.3.4User Interface Mock-ups PAGEREF _Toc24719231 h 203.3.5Entity Relationship Diagram PAGEREF _Toc24719232 h 243.4Testing Phase PAGEREF _Toc24719233 h 253.4.1Testing Plan PAGEREF _Toc24719234 h 253.4.2Evaluation Plan PAGEREF _Toc24719235 h 253.5Project Deliverables PAGEREF _Toc24719236 h 263.6Ethical Considerations PAGEREF _Toc24719237 h 264Implementation and Evaluation PAGEREF _Toc24719238 h 274.1System Implementation PAGEREF _Toc24719239 h 274.2User Interface PAGEREF _Toc24719240 h 284.3Web Application PAGEREF _Toc24719241 h 344.4Database PAGEREF _Toc24719242 h 354.5Evaluation PAGEREF _Toc24719243 h 364.5.1Software Testing PAGEREF _Toc24719244 h 364.5.2User Evaluation PAGEREF _Toc24719245 h 375Results and Conclusion PAGEREF _Toc24719246 h 395.1Results PAGEREF _Toc24719247 h 395.1.1System Testing PAGEREF _Toc24719248 h 395.1.2System Usability Scale (SUS) PAGEREF _Toc24719249 h 395.1.3Net Promoter Score (NPS) PAGEREF _Toc24719250 h 405.2Ethical Concerns PAGEREF _Toc24719251 h 415.3Future Work PAGEREF _Toc24719252 h 425.3.1Application PAGEREF _Toc24719253 h 425.3.2Emotion Prediction PAGEREF _Toc24719254 h 425.4Potential Contributions PAGEREF _Toc24719255 h 425.5Limitations PAGEREF _Toc24719256 h 426References PAGEREF _Toc24719257 h 447Appendix PAGEREF _Toc24719258 h 46

IntroductionThe project, with the name Wakey Tracker, is to design an application for emotionally disturbed adolescent students to check in during the day to convey their emotional state. This information can be used to show these students their past reported emotions, and be sent to a teacher mode, where teachers can keep track of their students emotions in the teachers classroom. The application should also be able to predict students emotions and notify this prediction to teachers if necessary. The project aims to assist classes and schools where these emotionally disturbed students are present and to determine if future emotions can be reliably predicted through simple emotion inputs. Teachers knowing their students current emotional state and predictions on students future potential state can help them properly target and modify their teaching pedagogy CITATION Bru152 l 3081 [1], as reading emotions of students from an emotionally or behaviourally disturbed background can be challenging. The application will be developed in close conjunction with Wakefield School which will serve as a case study for this project, including providing user feedback on prototypes throughout the project. Duncan Wotherspoon-Brown, the client for the project, is a teacher at Wakefield School, and will have a large influence on design decisions.

Problem and MotivationWakey Tracker is an important project that aims to address a lack of applications that allow teachers to track students emotions by allowing students to self-report their emotional well-being. Currently, there is no system like this, where students can report their current emotional status and have teachers can view emotion reports of their whole classroom. This is especially important for the client, Duncan Wotherspoon-Brown and his colleagues at Wakefield School. The school, located west of Lake Macquarie in NSW, provides specialist education services to emotionally disturbed adolescents. They have adopted leading-edge teaching strategies which dictate an approach of teaching that is based around the students behaviours and emotions. Knowing the emotions of students during the day would allow better fine tuning of the teaching behaviours for Duncan and Wakefield School teachers.

Noting the psychological benefits of this application is important in justifying this projects viability. This application should have a positive benefit to both students and teachers. A recent article CITATION Bru152 l 3081 [1] discusses the trauma-informed approaches and strategies that can be utilised in the classroom. The article refers to the requirement to build self-regulation and introduce students to coregulatory experiences both physically and emotionally. For this project, the article assists in the understanding of healing physically and emotionally through the recognition of self. This provides evidence of the requirement to have this application in the classroom for students with emotional disturbances, to allow students to identify and document their feelings in the application for their own benefit and to allow the classroom teacher to utilise the data to ensure student self-regulation is happening in the classroom. This application will also help students self-regulate by allowing them to identify the current emotion/s they are feeling, whilst simultaneously informing teachers of their emotion.

This book chapter CITATION Bru153 l 3081 [2] looks at the behavioural views of learning from an educational psychological lens in relation to applications of behaviours in the classroom. This chapter specifically looks at theories on the behavioural explanations of learning and classroom conditioning. In terms of this project, the sections on classroom conditioning are important to consider to be able to know the benefits and implications of the application in the real world. Obtaining the knowledge on how teachers can use this application and understanding the response to the student inputs into the application that will take place in the classroom and how it may benefit the students. This book chapter further illustrates the requirement for this application in classrooms to gather information from the students to be able to recondition the classroom and adapt teaching practices to the needs of individual students.

The article Shifting Teacher Practice in TraumaAffected Classrooms: Practice Pedagogy Strategies Within a TraumaInformed Positive Education Model debates the shifting pedagogical strategies that assist students with trauma in the classroom in relation to the Trauma-Informed Positive Education Model. This article looks at the requirement for teachers to adapt and change their pedagogical understanding when it comes to teaching students with trauma. There is a body of evidence highlighting the benefits of emotionally aware teaching, which this application will aim to assist in achieving. This evidence will also help frame the software requirements of Wakey Tracker.

There are currently no applications or technological solutions which satisfy the outcomes for this project. However, there have been applications developed in the past related to emotion tracking. The application Emotion Map, is an application written for adults CITATION Mor10 l 3081 [3]. This mobile app simply asks for the user to enter their current emotional status and based on how theyre feeling, provide tips for improving their emotional state. Whilst some aspects of the interface are useful for Wakey Tracker, the app isnt designed for use by adolescents, or in a classroom setting. The screenshot REF _Ref24641239 h Figure 1.1.1 shows a sliding scale for the emotion that the user is reporting, a design aspect that will be employed for Wakey Tracker. Another mobile application, Emotion Map Emotion Map: A Location-Based Mobile Social System for Improving Emotion Awareness and Regulation, allows users to share their emotion by pinning it to a location on a map. This is not suitable for minors, as it violates their privacy and is not suitable in a classroom situation. This location-based emotion reporting can be seen in REF _Ref24674502 h Figure 1.1.2, which is not what will be implemented with Wakey Tracker.

Figure 1.1.1 Mobile Therapy screenshot. Here there is a 1D slider for the emotion the user is reporting - their anxiety level.

Figure 1.1.2 Emotion Map application screenshots. Screenshot L2 shows the location-based emotion reporting

ObjectiveCurrently, there is no good way for students to report their emotions, with the ability for teachers to see this. This lack of data impacts on the teachers of Wakefield Schools ability to implement trauma-aware pedagogy. Additionally, collection of emotion data for students will enable the prediction of future student emotions. This may allow teachers to more effectively teach with a trauma-informed mind-set, by pre-empting emotions before they eventuate and reacting accordingly.

Organisation of this ThesisChapter 1 contains the introduction of the project. The introduction consists of the motivation and problem Wakey Tracker and its objectives. The motivation and problem of Wakey Tracker will demonstrate the potential usefulness and benefits Wakey Tracker will have for the client. It will also show that a solution does not currently exist for their use cases. Next is the objective, which will explain what Wakey Tracker plans to provide to the client.

Chapter 2 describes the literature review, which explores the many aspects of designing and implementing Wakey Tracker. Application design for adolescents is an important topic as it is the majority demographic for Wakey Tracker. Here, research is aimed at finding ways to produce an app that is engaging and easy to use for adolescents. Interface design is also discussed, where research is undertaken of previously made applications of emotion reporting, as well as ensuring Wakey Tracker stays consistent throughout the application, and to provide intuitive flow and control through the whole app.

Chapter 3 covers the methodology and design of Wakey Tracker. This includes the software design lifecycle, the project plan at different stages of the project, and development process. It also describes the project deliverables; the project aims to deliver and its outcomes. The Methodology and Design section also covers ethical considerations of the project, as data generated from minors will be collected.

Chapter 4 discusses the implementation of Wakey Tracker. The database schema, the models used to reflect how the system operates and their relations are shown in detail here. The web application itself is discussed, where its shown how the frameworks, libraries and tools are used to build the web application. The implementation of the user interface is also described. This implementation relies heavily on the system designs from Chapter 3. Once this was completed, the results of Wakey Trackers performance (in both user feedback and code) is shown.

Lastly, chapter 5 is the discussion and conclusion of the Wakey Tracker project. This chapter contains an analysis of the results gathered from chapter 4, the contributions of Wakey Tracker, the ethical considerations of the data collected from the results section in chapter 4 and any future work that should be performed to further improve the Wakey Tracker project.

Literature ReviewInterface DesignDesigning the interface is a crucial step of the project. This is a piece of the application that users must interact with, and poor design choices discourage users from using the application. A good user interface feels intuitive a user doesnt have to ask anyone how to use it. Wakefield school want a simple to use interface as emotionally disturbed children dont typically have a long attention span; they dont want to be spending a lot of time on one task. At the same time, enough information should be retrieved to get a reasonable understanding of the students true emotion.

The paper on the mobile application Mobile Therapy discusses the effectiveness of adult users tracking their emotions CITATION Mor10 l 3081 [3]. This article is essential for information in relation to what other use cases require the same or a similar application to that of the school. This is somewhat relevant as the article reports some of their users found that identifying their emotions helped them realise why they were feeling that way and thus come back to a better state. This evidence further solidifies the viability of the project. However, the app employed an interesting method for collecting the users emotion. First, a 2D graph was shown, then second, a 1D scale for conveying specific mood intensities. This interface allows for a good starting point for designing the user interface and portrays a potential graph design for the application.

The Emotion Map application paper discusses the use of a mobile based system for Adult users to generate awareness and regulate their emotions CITATION Hua15 l 3081 [4]. This paper also investigates an application that has been designed for adult users to convey their emotions and pinpoint it to a location or situation. This emotion that was shared at a location or during a situation can then be seen by other people also using the application to create awareness. This is not relevant to this specific application being developed is being used at a school, where privacy breaches such as locations are not appropriate for children and create ethical concerns. However, the app employed emojis for the user to convey how they were feeling which is an interesting graphical representation of emotion used by this application. This is an interesting idea, as it is quick and easy for students to choose an emoji to convey their feelings.

The survey that was provided to Wakefield school was issued to the 35 students. This survey can be seen <>. Most of the responses from this survey voted for two different interface designs or a combination of the same two. The two interface designs included a slider using emojis to represent the emotions felt by the student or the interface design that just utilised the emoji system to be able to choose one or more. It is evident from these two responses that the students are more interested and more likely to be intrinsically motivated to use the application if it uses the emoji system to be able to input the students individual emotions.

Cloud Hosting ProvidersDeveloping an application to meet project requirements is important but being able to serve it to the users is also very important. A cloud hosting service provider was used for this purpose. REF _Ref24646994 h Table 2.2.1 shows a comparison between major cloud hosts, Google, Microsoft and Amazon. In the end, Google Cloud was chosen, with Google App Engine being the host of the web application server.

Table 2.2.1 Cloud hosting provider comparison

Google Cloud Microsoft Azure Amazon EC2

+ Have past experience - No past experience + Run glassfish in docker - customisable

+ GAE glassfish and Java web container with minimal configuration + Web apps with Java and Spring At ~$0.165 per hour - Requires configuration time/effort

+ Both NoSQL and RDS (SQL) services available to GAE easy to setup + MySQL, PostgreSQL aaS 12 months free. 1 instance runs all month free cost ~$5 per month

Tensorflow on Google Cloud ML: ~$0.074 per hour DB: RDS service - ~$0.026 per hour (1 sec increments)

ML: Docker in EC2 EC2 rates apply

Web Application Optimisations for Emotion RecordingThe usability of an application is highly dependent on the speed and responsiveness of it. Special consideration should be made to ensure this application is highly responsive. Since this application will primarily be used on a touch-screen interface, a slow interface may discourage users from using the application. Steps will be taken to ensure this web application will be fast and efficient, especially on a touch interface. The following are papers on steps that can be taken to optimize web applications.

Implementation of AJAX and JSON to Improve Web Application Performance:

There is a major benefit to implementing a web application with a dynamic front end as opposed to a static CITATION Abd16 l 3081 [5]. This paper discusses and compares between static and dynamic applications. A dynamic web application is one that does not reload all menus every time a link or action is selected. This is done by AJAX, which is a technology implemented by JavaScript to allow for server-side requests after a page has loaded, which typically uses XML to send information. The paper also argues for the use of JSON, which parses in JavaScript faster, has a native JavaScript parser and becomes a smaller file-size compared to XML. This paper claims that a dynamic web application performs much better than a static web page, as well as being more responsive and better user experience. The paper claims an almost 2.5x performance improvement for a dynamic web application over a static one. This paper shows that I should be employing a responsive web application design, utilising JSON for sending and receiving data.

Understanding Database Performance Inefficiencies in Real-world Web Applications:

Addressing database performance and its implications in real-world situations and applications is important for application speed CITATION Yan17 l 3081 [6]. For this application a database is required for storing user emotion data, as well as potentially login data, ensuring this database is efficient is very important for the speed and efficiency of the application. Using an ORM (Object Relational Mapping) framework (such as Hibernate) does decrease programming complexity and increases the portability of the program but can introduce inefficient database structures and ways of accessing the data. The paper provides many suggestions and recommendations on how to use an ORM, whilst maintaining the speed and efficiency of writing native queries for accessing data. I should keep these suggestions in mind whilst designing the database for this application.

Machine Learning for Emotion PredictionThe aim of using machine intelligence within the application is to predict the students emotions and to then warn teachers of students with a potential upcoming negative emotion. The application will use the data that has been inputted from the student to predict how the student may input their emotion in the future. It may be beneficial to take other students emotions in the same classroom into account, as students may affect each others emotional state.

LSTMs (Long Short-Term Memory) utilise unsupervised learning to predict future events CITATION Sri15 l 3081 [7]. In the case of this article, a video stream. This article is useful for its use of a LSTM to learn from previous input and output predictions of the future based on data streamed to it. The limitations within in the article are its a parallel to the data from this application. However, the article employs video data to train the LSTM, which is very different from the data the emotion application will feed to get predictions.

Unsupervised learning artificial intelligence algorithms can be utilised to perform anomaly detection in streamed data CITATION Ahm17 l 3081 [8]. It utilises unsupervised learning to achieve this. This article is useful due to the way they handle the streamed data. Since the emotion application will get data in a stream fashion, this article will help this application by implementing a machine learning algorithm for predicting future emotion from the past data. The article may also be helpful as it detects anomalies, which could have a parallel to negative emotion.

Methodology and Design (15%)Introduction to the Software Development MethodologyThere are several methodologies that have been developed for software projects

I will be implementing the Software Development Lifecycle (SDLC) using the Prototyping Model

First stages are iterative

Prototype refining and user evaluation are performed many times until requirements are met

Prototype - an actual working version of the project. Will have some features missing. Each iteration adds features

Final prototype is then implemented

ability to react to feature creep is vital for project success.

there will be 2 weeks per sprint, with 5 sprints in total (except for the first sprint, which will last for 6 weeks

rapid development for a project, where a small set of requirements will be fully implemented

The prototype will also be validated on an iPad similar to what is used at Wakefield School, to confirm that the prototype is ready to be shown

Figure 3.1.1 Software Development Lifecycle with Prototyping model

Requirements PhaseFunctional RequirementsBelow at REF _Ref24646994 h Table 2.2.1 are the explicit deliverables expected to be carried out by project completion. There is a priority of deliverables, in order of completion, where all high priority deliverables must be completed, most medium priority deliverables must be completed, and low priority deliverables are to be done last, and may not be completed.

Table 3.2.1 Wakey Tracker project deliverables

Deliverable Priority Description

Student view track emotion

H An interface for students to input their emotion

Student view show previous emotions H A chart or graph for displaying a student users past emotions

Teacher view

H A teacher mode view for when teacher accounts log in

Student view

M A student mode view for when student accounts log in

Teacher view Specify students in class

M Teacher can select which students are in their class

Student view send alert for user to input emotion M When a student hasnt inputted their emotion for a while, send an alert for them to do so

Predict students future emotions M Use machine learning to use students previous emotions to predict their future emotions

Teacher inputs a score for a student for the day L Teacher inputs a score for the student based on their behaviour for the day

Cognitive-stimulating games as rewards for conveying emotion L These games can be simple, but relatively challenging, to give an incentive for conveying emotion, and be beneficial to the student playing the mini game

Non-Functional RequirementsThese are the non-functional requirements for the Wakey Tracker project:

The application must work on an iPad most students at Wakefield own an iPad. Wakefield school uses a 6th generation 9.7 iPad running iOS 12, therefore, special consideration must be kept for this model

The application should work on a laptop as there is an option between a laptop and an iPad, students at Wakefield may own or want to use a laptop for the emotion-tracking application

The application should be fast, simple to use and follow consistent UX rules.

Design PhaseUse Case DiagramFigure X shows the use case diagram for Wakey Tracker. It shows all the tasks the application should be able to perform and its interactions with the actors. There are 3 actors. These actors are: User, Student and Teacher. The Student and Teacher actors are descendants of User, as they inherit the actions of User. When signing up, the User actor decides what account type to sign up as. From this, the Student and Teacher child actors then have their own specific functionality.

Figure 3.3.1 Use case diagram for Wakey Tracker

Activity DiagramsEach of these activity diagrams is a description of a use case as outlined in REF _Ref24643484 h Figure 3.3.1. These diagrams follow the UML standard CITATION Obj19 l 3081 [9].

REF _Ref24643544 h Figure 3.3.2 demonstrates the activity of a User logging in. The use case description for user login can be found at Appendix A REF _Ref24643606 h Table A - 2. At the start of logging in, the system is not aware of the actor type (whether the user is a student or a teacher). The user logging into Wakey Tracker allows the system to determine which actor the User is.

Figure 3.3.2 Login use case activity diagram

REF _Ref24643854 h Figure 3.3.3 describes the flow of the student emotion report. This system takes the emotion inputs from the student user and validates them. If the inputs are valid, then the system creates the report from the input. If the inputs are invalid, an error message is shown.

Figure 3.3.3 Student Reports Emotion use case activity diagram

The activity diagram for teacher mode for displaying each students emotion in the teachers classroom is described in REF _Ref24643895 h Figure 3.3.4. Firstly the system retrieves each student in the classroom and gets their most recent report data, then the system displays this information to the teacher user.

Figure 3.3.4 Teacher Mode - View Student Reports Activity Diagram

System DiagramsThis section is a high-level overview of the design of Wakey Tracker. It will describe the connections between the high-level components and how they will interact. These connections and interactions are described in REF _Ref24644002 h Figure 3.3.5. More detailed designs will be found in the next sections.

Web application

In charge of all logic of Wakey Tracker

Serves data to the user interface

User interface

Served by the web application

What the user will interact with

When a student submits a report, the web application sends an update to the AI processing engine, to notify it of the new student report

Must be compatible with both an iPad and a laptop, as stated in the Non-Functional Requirements at Section REF _Ref24715705 r h 3.2.2

Database

Will store the generated data from the application

Will serve to the emotion prediction AI engine

Emotion Prediction Engine

An AI engine for predicting future emotions

The engine trains with streamed data, so a new student report gives the prediction a new sample to train with

The future emotion prediction and guess confidence (a percentage) is then written to the database

Figure 3.3.5 High level system diagramUser Interface Mock-upsThe signup screen needs username and password fields. There should be two password fields (one with a repeat) which matches against each other to ensure the user correctly typed their password. There is also a switch to choose either a student or teacher account. In REF _Ref24645402 h Figure 3.3.6, the user type switch is set to be a student. The switch should be animated to scroll over to the other side when selected. When this is checked, the nickname hint in parentheses should be shown to hint to the user that their real name shouldnt be used. This nickname hint is for ethical reasons. To read more on these ethical reasons, please read Section REF _Ref24645480 w h 3.6.

Figure 3.3.6 Signup screen - student user selected. The username shows a hint that it should be a nickname

The mock-up at REF _Ref24645642 h Figure 3.3.7 shows the user type switch has been set to teacher. The nickname hint that is shown for students has been removed, as it is not required for teachers.

Figure 3.3.7 Signup screen - teacher user selected. The username does not need to show the nickname

After the user has signed up, they log in, so they are able to use Wakey Tracker. The user type switch should still be displayed. The user must choose which user type they signed up for here. The user types in their username and password to login, which is seen in REF _Ref24645680 h Figure 3.3.8. Additionally, the user has the option to select the forgot your password? link if theyve forgotten their password, as well as the link to access the Sign Up page.

Figure 3.3.8 The login page

This mockup at REF _Ref24645750 h Figure 3.3.9 was the first iteration of the student reporting page. Firstly, the user chooses the relevant emotions from the box of emojis. Then, for each emoji that is selected, a slider is shown below for the user to input the level of that emotion.

Figure 3.3.9 The first iteration of the student reporting screen

REF _Ref24645824 h Figure 3.3.10 shows the second iteration of the student emotion reporting page. This screen was developed after feedback from the client was given. Whilst the client was impressed with the first iteration of the student reporting screen at REF _Ref24645750 h Figure 3.3.9, he requested a simplification of this interface. This second iteration easily demonstrates the level of each emotion to the user, providing an intuitive interface for reporting.

Figure 3.3.10 The second iteration of the student reporting screen

REF _Ref24646042 h Figure 3.3.11 demonstrates the design for the teacher screen for displaying each student. On this screen, each student in the teachers classroom is represented as a card. The student card will show the last emotion that was reported by the student (in a reduced form) as well as the future emotion prediction. Clicking the menu button in the bottom right of the card (the hamburger symbol) expands the card, into a details page for the specific student.

Figure 3.3.11 The teacher screen for displaying all the students in their classroom and their last reported emotion

Entity Relationship DiagramThe ERD (Entity Relationship Diagram) is an important part of designing a database schema. The ERD, shown at REF _Ref24646118 h Figure 3.3.12, has been designed to meet all Wakey Trackers functional requirements.

The StudentUser entity records user accounts of students. A new record is created in StudentUser for each new account generated. The StudentReport entity stores the reference to the emotion report a student makes, along with which student produced this result, which is also referenced by the EmotionLevel entity. A field in EmotionLevel must reference a valid emotion as defined by the EmotionSet entity. These entities facilitate the student emotion reporting functional requirement. The FuturePrediction entity stores the predicted emotions for each student, satisfying the AI prediction functional requirement.

The TeacherUser entity records user accounts of teachers. The Classroom entity defines which students are in the teachers class. Both StudentUser and TeacherUser entities are referenced here. From this, the application can infer which students emotion data is accessible by the teacher, so it can be displayed to the teacher. This functionality acknowledges the functional requirement of teachers having the ability to check up on students emotions in their class.

Figure 3.3.12 Entity Relationship Diagram (ERD) of the database schema for Wakey Tracker

Testing PhaseTesting PlanOnce the agile testing sprints are done, the next phase will be user and client testing. Wakefield school will start using the application and give feedback on how it performs. This feedback will be given through surveys, where after some usage, users will answer some questions on ease of use, effectiveness and how much they like it. Any problems during use can be reported through a report button which will also be implemented in the application. Reporting problems in this manner can also get useful information about the state of the application, to allow the developer some insight into what went wrong.

Unit testing is an important way to mitigate bugs in Wakey Trackers code. There will be unit testing coverage targets set for code written for Wakey Tracker, ensuring that the code is well tested. Note that code from external libraries doesnt require unit testing. Wakey Tracker custom classes will have 100% unit test class coverage and method coverage will also be 100%. Branch coverage is much harder to completely test for, but branches that are commonly used will be tested for.

For system testing the Wakey Tracker application, an automated tool will be used to run tests of flow through the entire system. Tests will be made which addresses and flows through each use case as defined in Section REF _Ref24646270 w h 3.3.1. The tests should only pass if it completely satisfies that use case.

Evaluation PlanEvaluation is important as it gives a good indication of the success of the project. To evaluate Wakey Tracker, two surveys will be used. The System Usability Scale (SUS) will be used to score the perceived usability of the Wakey Tracker application. A good perceived usability score will mean the applications interface is well designed, making it more likely the users will continue to use Wakey Tracker. The second survey will be the Net Promoter Score (NPS). This survey simply measures brand loyalty, which assesses the likelihood of promotion of the product. This score will be useful for the evaluation of Wakey Tracker as it will assess how satisfied with the application.

Project DeliverablesAt the completion of the project, the client, Duncan, will receive a copy of this report. He will also receive access to the developed application.

Ethical ConsiderationsThe study involved the collection of data from students at Wakefield School. Under the National Framework for the ethical conduct of research (follow the link to the national code here), the following provisions were made to ensure data obtained by minors is properly controlled in the Wakey Tracker application:

Anonymity was ensured. Whilst measures will be taken to ensure database security, even if a breach were to occur, the data in the database will be anonymised. References to student data will be made using an alias to the minors real name

An Information Use Statement was provided to the client. This statement is to inform the client of the use of student-generated data

Informed consent was gained to use minors data

The research was conducted as part of undergraduate coursework, and as such, formal ethics approval from a human research ethics committee was not obtained. As a result, the findings from the study will not be published beyond this thesis for marking purposes, and all data gathered will be deleted on award of final grade for the course.

An Information Use Statement was provided to the client. This statement is to inform the client of the use of student-generated data

Informed consent was gained to use minors data

Implementation and EvaluationSystem ImplementationThis section addresses the overall implementation of the Wakey Tracker system. The UML class diagram for Wakey Tracker can be found at REF _Ref24661677 h Figure F 1 in Appendix F. The next paragraphs will be referencing this figure, as it will describe its various features.

Powerful external backend libraries have been utilised. Spring has been used as it is a common and powerful framework for developing web applications, allowing for a consistent development approach throughout the project. It is well designed and very feature rich. Spring MVC has specifically been relied on, as it provides a MVC (Model View Controller) framework for implementing well designed web applications. Hibernate has also been used, which connects with the MySQL database and maps its data to the web application. Spring security has been utilised to give a secure login layer to the application. Spring security is well tested, and as a result, gives good security to Wakey Tracker without too much implementation effort. Using these libraries allows for future expandability as well as good maintenance.

For the project to function, configuration files must be created. These configurations are defined in the com.wakefield.config package. These classes configure the various frameworks being used. These configurations will be further explained in Section REF _Ref24661849 w h 4.3.

The com.wakefield.entity package contains the entities created for mapping the relational MySQL database to objects. Each class in this package labelled <<entity>> references a table in the database. This object-relational mapping is done with Hibernate, which will be further explained in Section REF _Ref24661849 w h 4.3.

The com.wakefield.controller package contains the classes which control the flow of the application, as by Spring MVC standards. Each controller is mapped to a URL, so when a user hits that URL, the controller is what responds. These controllers can get data from the entities as necessary and perform the necessary logic on them. Once the data has been properly manipulated, relevant data is then sent to the front end for display. Application Hosting and Deployment

The Google Cloud Platform was chosen to be the hosting platform for Wakey Tracker. A comparison of cloud services was made in Section REF _Ref24676653 r h 2.2, and Google Cloud Platform was found to be the most fitting for this project.

For database hosting, Cloud SQL was used. Cloud SQL is a fully managed database service, without the need to configure a MySQL instance yourself; a database as a service provider CITATION Goo192 l 3081 [10].

For application hosting, Google App Engine was employed. Google App Engine is a Platform as a Service (PaaS), where the entirety of the management of the server is done by Google CITATION Goo193 l 3081 [11]. Google App Engine provides a range of supported languages, but Java was chosen for Wakey Tracker. There are two modes for Google App Engine: Standard and Flexible. Standard was chosen over flexible for a number of reasons: the majority of the documentation is for standard, requires less configuration, standard is cheaper to run than flexible; standard charges in seconds for instance start-up time, whereas flexible charges by the minute CITATION Goo194 l 3081 [12]. Additionally, standard has access to app engine APIs, flexible doesnt.

Connecting to the MySQL instance provided by Cloud SQL from App Engine was easy. By default, app engine has permissions to connect to Cloud SQL, all the App Engine project needs to do is import the App Engine libraries, provide the connection string, SQL username and password during connection initialisation CITATION Goo195 l 3081 [13].

User InterfaceThe user interface has been implemented with Bootstrap 4, jQuery and JSP (Java Server Pages). Since JSP is simply HTML with the ability to take data submitted to it and dynamically generate more HTML, the screens are laid out with bootstrap, utilising the grid model. Backend data is sent from the Spring controller to the JSP page, which then utilises the data to build up the page.

The control of the data flow in the context of the User Interface is outlined in REF _Ref24644002 h Figure 3.3.5 with the Web App and User Interface attributes of the diagram. The backend data to be displayed is sent from the relevant Web Apps Controller, where the user interface formats this to display to the user. When the user submits data, the user interface sends this back to the relevant controller in the web application. Retrieving user data involves the HTML page sending the data with jQuery via AJAX to the respective controller.

Below are the screens that have been implemented for Wakey Tracker.

This is a simple sign up page for Wakey Tracker. There is a link shown on the login screen to access this page; which is standard website design. After the fields are filled in and the user pressesthe sign-up button, the user will be taken back to the login page.

The fields for the sign-up page, as in REF _Ref24660138 h Figure 4.2.1, are:

Nickname, a textbox which is the name the account should be referenced by;

Account type, a switch which can be either teacher or student (changing the switch to teacher changes the nickname textbox label to Name);

and password, and a repeat password field, which the values in both should match.

Figure 4.2.1 Sign up screen set to Student mode

REF _Ref24660231 h Figure 4.2.2 shows the sign-up page with the switch set to teacher mode. This is for users who wish to sign up for a teacher account.

Figure 4.2.2 Sign up screen set to Teacher mode

REF _Ref24660296 h Figure 4.2.3shows the sign-up screen with text inputted. Obviously, the password fields are set to the password input type (where text is hidden).

Figure 4.2.3 Sign up screen with text input

Logging in should be a straightforward experience. The developed screen is basic, with a very visible username and password. Since there are student and teacher accounts, there must be a way to distinguish between the account types. This is why there is a toggle switch above the username and password fields to choose to login to a student or teacher account. This is shown in REF _Ref24660357 h Figure 4.2.4. The design language is consistent with the rest of the application.

Figure 4.2.4 Login Screen set to Student mode with text input

REF _Ref24660429 h Figure 4.2.5 shows the login page with the account type switch set to the teacher position. This is for users with teacher accounts to log in. By default, the username and password prompts appear in the input fields, which is the same for the student mode.

Figure 4.2.5 Login screen set to Teacher mode

Once a student has logged in, theyll be shown the emotion reporting page, demonstrated at REF _Ref24660471 h Figure 4.2.6. This page will show the students username as well as the available emotions to report. The slider to the right of each emotion conveys the level of that emotion the student is feeling at that time. When the user presses submit, AJAX is used to submit the page without page refresh, which <reference> denotes. Whilst the application is submitting the emotions, a bootstrap spinner on the submit button is displayed. The response from this AJAX call is shown with a bootstrap alert dialogue is shown, signifying either the success or failure of submitting the emotion report. The green bars are sliders, which the user uses to convey the level of the emotion they are feeling, which is demonstrated in REF _Ref24660603 h Figure 4.2.7.

Figure 4.2.6 The Student Report page as seen on an iPad. This is what the user sees after theyve logged in

Figure 4.2.7 The Student Report page as seen on an iPad. Here the user has inputted how they are feeling

This is the main screen for teacher users, shown at figure X. It shows a card view of each student in their classroom. Each card shows a student in the teachers classroom, along with their last reported emotion and a details button. Currently, the Details button is a placeholder, which is a task for future work.

Figure 4.2.8 The teacher mode overall review screen. Shows the last emotion report for each student in the teachers class

Web ApplicationSpring Boot and MVC was used as the main framework for Wakey Tracker. After special configuration for Google App Engine was performed CITATION Goo197 l 3081 [14].

In Spring MVC, a controller is mapped to a URL, so each main use case was mapped to a corresponding page. Some pages that are mapped are:

Student report page

Teacher overview page

In order to connect to the relational database, an ORM (Object Relational Mapping) was used. Hibernate is the standard ORM manager to use with Spring. Tables in the relational database are mapped to Java classes, or entities. Each row in the table is mapped to an object of an entity class CITATION Red191 l 3081 [15]. To access the data from the database, DAOs (Data Access Objects) are created, which contain HQL (Hibernate Query Language) to query the database, but in an object-oriented way. In Wakey Tracker, access to the entities are behind the DAOs call the desired method from the DAO, the DAO will perform the query and return the object(s).

Spring security CITATION Piv19 l 3081 [16] has been used to create the login layer of Wakey Tracker. Spring security is a standard way of controlling access to pages on a website, through a login layer. Wakey Tracker stores user accounts in the database, so logins must be performed by querying the database CITATION myk14 l 3081 [17].

DatabaseWakey Trackers database has been implemented using MySQL5.7. MySQL 5.7 is supported in Googles Cloud SQL service. This allows for rapid development, where time is spent on the development of the application and not researching configurations.Cloud SQL features:

Hosts MySQL

Ability for google app engine to easily connect

An overall ERD and description of the roles of each of each of the tables at a high-level view is described in Section REF _Ref24660770 w h 3.3.5. REF _Ref24660828 h Figure 4.4.1 provides the EER diagram of the database tables for Wakey Tracker. The database schema is defined as SQL in Appendix C.

The reasons for this design of Wakey Trackers schema is as follows:

The schema allows for efficient storage of student emotion reports

For adding a student report, create a new report, and add each of the emotion levels for each of the emotions referencing that report

Adding a new report simply inserts a new StudentReport row. The SQL then creates its own primary key and timestamp of this insert. After this, just retrieve this generated primary key and insert each emotion and its corresponding level into the EmotionLevel table

Efficient access for teacher class reporting

For overall view, get all students in teachers class, get students latest report

For detailed view of student, identical to student report view

Good normalisation of data. There is no repetition of data, all joins are maintained with a primary key ID

Emotion prediction machine learning engine can easily access the required data

Due to time constraints, the Future Prediction table used for the AI prediction engine defined in the ERD at Section REF _Ref24660770 r h 3.3.5 was not implemented, as the AI processing engine has been moved to future work

The schema also allows for Hibernate, the ORM, to efficiently handle the data.

Figure 4.4.1 EER Diagram of the MySQL database schema for Wakey Tracker

EvaluationAs stated in Section REF _Ref24658029 w h 3, there are two main areas of testing; software testing and user testing.

Software TestingThis section describes the implementation of the testing procedures outlined in Section REF _Ref24703263 r h 3.4.1. It will describe the unit testing implementation, as well as system testing.

Unit Testing

Several libraries were utilised in Wakey Tracker to assist in making its unit tests robust, easy to extend and easy to maintain. The Junit unit testing framework CITATION The19 l 3081 [18] was used to handle the execution of tests. In addition, the Hamcrest framework CITATION ham19 l 3081 [19] was used to assist the JUnit unit testing process. Hamcrest provides additional assertion matchers, which provide nice user feedback for when tests fail, as well as the ability to easily declare custom matchers.

Since unit tests should be testing single classes at a time, dependencies on other classes make this difficult. Therefore, Mockito was employed in Wakey Trackers unit testing. Mockito allows for mocking of dependency classes when a class is being tested CITATION Moc19 l 3081 [20]. This especially useful for an entity that is being updated by a database for example: simply mock the DAO (Data Access Object) for retrieving that entity with a fixed entity, allowing the unit test to test the functionality of just the class being tested, not the database and DAO functionality.

System Testing

To execute system testing, Selenium and JUnit were used. These system tests should address each use case. JUnit is used to start the tests and keep both the unit and system tests in a neat package, so they are easily run. Selenium is an automated web driver CITATION Ope19 l 3081 [21]. This allows for tests where Selenium automatically navigates through the Wakey Tracker web application. It has been used to test for elements on screen (if the element is not displayed, the test will fail). These tests help ensure that use cases have been met.

User EvaluationUser evaluation involves the users testing Wakey Tracker then filling out the two surveys below, which is described in more detail in Section REF _Ref24704827 r h 3.4.2.

System Usability Scale (SUS)

I modified the standard questions to have some more simpler vocabulary, to fit the demographic of the students. Each question has 5 potential responses: strongly disagree, disagree, unsure, agree and strongly agree. The questions asked are below:

I think that I would like to use Wakey Tracker frequently

I found Wakey Tracker unnecessarily complex

I thought Wakey Tracker was easy to use

I think that I would need the support of a technical person or my teacher to be able to use Wakey Tracker

I found the various functions in Wakey Tracker were well put together

I thought there was too much inconsistency in Wakey Tracker

I would imagine that most people would learn to use the Wakey Tracker app very quickly

I found that Wakey Tracker took a lot of effort to use

I felt confident using Wakey Tracker

I needed to learn a lot of things before I could get going with Wakey Tracker

Net Promoter Score (NPS)This was a standard template from Survey Monkey CITATION Sur19 l 3081 [22].

There is only one question, with a possible response from 0-10 inclusive. Survey Monkey then interprets the scores and gives a ranking of the app. The question is: How likely are you to recommend Wakey Tracker to a friend?

Results and ConclusionResultsSeveral students from Wakefield School were able to test the application and provide feedback over the course of 1 day. Raw results from this test can be found in Appendix E in tables: REF _Ref24714369 h Table E - 1, REF _Ref24714371 h Table E - 3, REF _Ref24714372 h Table E - 4, REF _Ref24714373 h Table E - 5, REF _Ref24714374 h Table E - 6, where each table references the reported emotions by each user. Most users were able to submit results.

As is clear in REF _Ref24714373 h Table E - 5 (where all inputs are the slider all the way to the right), some users were not taking the emotion input seriously. These sorts of inputs would become less common if testing were to be undertaken for a longer time period.

System TestingUnit tests were written for all classes, meeting the 100% class coverage target.

Automated system tests were written for each use case as defined in Section REF _Ref24646270 r h 3.3.1. However, not all system tests passed, as not all use cases were implemented.

Passed:

Student reporting

Teacher overall view of classroom

Failed:

Past reports view (student and teacher)

AI prediction

System Usability Scale (SUS)There were 8 responses for the SUS survey. From the survey, a score can be calculated CITATION Had19 l 3081 [23]. After calculating the scores, the final SUS score for Wakey Tracker was 76.875. This score gives it a C rating CITATION Ban09 l 3081 [24]. This rating scale also provides an adjective to describe the survey results; this survey is in the good range.

From this result, it seems that Wakey Tracker did a good result in bringing a usable and suitable application that meets requirements. REF _Ref24705894 h Table 5.1.1 shows the summarised results of the SUS.

Table 5.1.1 System Usability Scale Survey Results Summary. The most common response of each question has been coloured

Question Strongly Disagree Disagree Uncertain Agree Strongly Agree

1. I think that I would like to use Wakey Tracker Frequently 1 2 0 3 2

2. I found Wakey Tracker complex without it needing to be 2 5 0 0 1

3. I thought Wakey Tracker was easy to use 0 0 1 2 5

4. I think that I would need the support of a technical person or my teacher to be able to use Wakey Tracker 5 2 0 0 1

5. I found the various functions in Wakey Tracker were well put together 1 1 2 2 2

6. I thought there was too much inconsistency in Wakey Tracker 3 2 1 1 1

7. I would imagine that most people would learn to use Wakey Tracker very quickly 0 0 1 4 3

8. I found that Wakey Tracker took a lot of effort to use 5 3 0 0 0

9. I felt confident using Wakey Tracker 0 0 1 5 2

10. I needed to learn a lot of things before I could get going with Wakey Tracker 6 2 0 0 0

Net Promoter Score (NPS)There were 8 responses to the NPS survey. A detailed description of an NPS can be found at Section REF _Ref24709564 r h 3.4.2 and the survey question can be found at Section REF _Ref24709605 r h 4.5.2.2. Survey monkey provides a template for the NPS survey, which then automatically analyses the survey results CITATION Sur19 l 3081 [22]. Different parts of the scale map to the promoter level of the user. Detractors report to the scale from 0-6, which are unhappy customers. Passives are defined from the 7-8 region; these people are indifferent to the application. Promoters are users who are more likely to promote the application in the future.

From Wakey Trackers survey, 38% of the responders fall in the promoters category. This result is decent, as it shows a sizeable amount of the users are happy with Wakey Tracker. However, most results were for detractors, which is 63%. This means that most users didnt enjoy the experience, or it didnt meet the mark for their expectations. REF _Ref24709871 h Figure 5.1.1 demonstrates these result figures from above, as well as an overall score for the survey, which is at -25.

Figure 5.1.1 Net Promoter Score Results

Ethical ConcernsThis section details concerns with regards to user privacy, especially of minors who will be using the application. Comprehensive privacy policy on all data collected and any that is shared will be developed and will be accessible on the application. This privacy policy will provide all users with informed consent on their data being used.

Since most of the users of this software will be minors, privacy must be of the utmost importance. When students create their account, they will be encouraged to not use their real names, reducing the risk of identification, even in the event of a data breach. Their data will not be shared public anyway, as it is a breach of a minors rights.

This section also details the concerns of the licensing around the use of the programming language used, program libraries and hosting licenses. REF _Ref24648151 h Table 5.2.1 outlines the licenses for the libraries used in Wakey Tracker. From this table, all libraries used in the Wakey Tracker can be used without charge. Some licenses require the license to be transferred, which will happen with Wakey Tracker.

Table 5.2.1 Library Licenses

Library License Description

Java JRE Binary Code License (BCL) Can use without modification for the sole purpose to run (Java) programs

Spring (Boot, MVC, Security) Apache 2.0 Can use freely without any royalties, dont have to open source the code

Hibernate GNU Lesser General Public License (LGPL) Allowed to use freely in open source or commercial setting

Bootstrap MIT License Can do anything with the library, if this license is transferred with the code

Future WorkApplicationThe Wakey Tracker web application was hosted whilst utilising the free credit from Google Cloud. However, once this runs out, continued hosting will require payment. Currently, Wakey Tracker consumes more computing time then necessary, due to Springs configuration. To keep costs down, optimisations should be made to the Wakey Trackers configuration to more efficiently use Google Clouds resources.

Currently, minimal asynchronous requests are being utilised. According to CITATION Abd16 l 3081 [5], exploiting more asynchronous requests improves actual and perceived performance of the web application. This would be achieved with a front-end Javascript framework like AngularJS. Wakey Trackers current implementation offers a great foundation for this future improvement, thanks to the use of Spring MVC.

The ability for a teacher to have access to multiple classes was requested. This would be handled by a new table and a modification to the Classroom table, and is defined by SQL in Appendix D. The Classroom table would become a master record for classrooms the teacher is a teacher of. The new table ClassMembers behaves like the Classroom table does currently, storing the class the student is in. Then, the teacher would have the ability to select multiple different classes, and have different students show in each.

Emotion PredictionEmotion prediction with the use of AI was not able to be developed in time. In order to properly test the prediction engine, a backlog of data would be needed to train on. This was not possible in the given timeframe. Google Cloud offers an extensive AI and Machine learning suite of tools suitable for this task CITATION Goo196 l 3081 [25]. These tools also allow for easy interaction with Cloud SQL and App Engine, so that a future deployment of this feature would be simple.

Potential ContributionsWakey Tracker is an application that allows adolescents to report their emotions and have the ability for their teacher to see their reported emotions. This application could potentially improve the teaching quality in schools, especially in schools like Wakefield School, as well as potentially improve the quality the students education in the setting where this application is used.

The emotion prediction engine could potentially bring new research in prediction of emotion from the abstraction of the users current emotional state into the input that Wakey Tracker employs for its emotion reporting.

LimitationsNot all functional requirements were met. These include:

Student view show previous emotion reports

Student view send alert for user to input emotions

Predict students future emotions

Teacher view show previous emotion report for student

Teacher view specify students in class

Teacher view input a daily score for a student

However, these unfinished functional requirements can all be addressed in the future development of the Wakey Tracker application.

Wakey Tracker has been implemented as a PWA (Progressive Web Application). This means it has been designed for a mobile device (in this case, primarily an iPad) but is written as a web application. There are a few limitations of a PWA on Apple mobile devices. These are:

Push notifications arent allowed. If the application sends push notifications, then the iPad will ignore it

Offline storage. There is no guarantee that offline storage will last with a PWA

Installation. In order to install, the user must navigate to the website on the browser and then dock it to their home screen

These limitations can be circumvented with a wrapper tool, where the PWA sits in a wrapper that is a native application. However, developing a native application is much more difficult than a PWA.

References BIBLIOGRAPHY

[1] T. Brunzell, L. Waters and H. Stokes, Teaching with Strengths in Trauma-Affected Students: A New Approach to Healing and Growth in the Classroom, American Journal of Orthopsychiatry, pp. 1-3, 2015.

[2] T. Brunzell, H. Stokes and L. Waters, Trauma-Informed Positive Education: Using Positive Psychology to Strengthen Vulnerable Students, California Association of School Psychologists, pp. 1-2, 2015.

[3] M. E. Morris, Q. Kathawala, T. K. Leen, E. E. Gorenstein, F. Guilak, M. Labhard and W. Deleeuw, Mobile Therapy: Case Study Evaluations of a Cell Phone Application for Emotional Self-Awareness, 2010.

[4] Y. Huang, Y. Tang and Y. Wang, Emotion Map: A Location-Based Mobile Social System for Improving Emotion Awareness and Regulation, 2015.

[5] M. Z. Abdillah, Implementation of AJAX and JSON to Improve Web Application Performance, 2016.

[6] C. Yan, J. Yang, A. Cheung and S. Lu, Understanding Database Performance Inefficiencies in Real-world Web Applications, 2017.

[7] N. Srivastava, E. Mansimov and R. Salakhutdinov, Unsupervised Learning of Video Representations using LSTMs, in 32nd International Conference on Machine Learning, Toronto, 2015.

[8] S. Ahmad, A. Lavin, S. Purdy and Z. Agha, Unsupervised real-time anomaly detection for streaming data, 2017.

[9] Object Management Group, Unified Modeling Language Languge Specification, December 2019. [Online]. Available: https://www.omg.org/spec/UML. [Accessed 1 November 2019].

[10] Google, Cloud SQL, [Online]. Available: https://cloud.google.com/sql/docs/. [Accessed 15 November 2019].

[11] Google, App Engine, [Online]. Available: https://cloud.google.com/appengine/. [Accessed 15 November 2019].

[12] Google, Choosing an App Engine Environment, [Online]. Available: https://cloud.google.com/appengine/docs/the-appengine-environments. [Accessed 21 October 2019].

[13] Google, Connecting to Cloud SQL from App Engine, [Online]. Available: https://cloud.google.com/sql/docs/mysql/connect-app-engine. [Accessed 15 September 2019].

[14] Google, Deploy Spring Boot Application in App Engine standard, [Online]. Available: https://codelabs.developers.google.com/codelabs/cloud-app-engine-springboot/index.html?index=..%2F..index#0. [Accessed 15 October 2019].

[15] Red Hat, Hibernate ORM, [Online]. Available: https://hibernate.org/orm/. [Accessed 15 October 2019].

[16] Pivotal, Spring Security, 2019. [Online]. Available: https://spring.io/projects/spring-security. [Accessed 17 October 2019].

[17] mykong, Spring Security form login using database, 23 April 2014. [Online]. Available: https://www.mkyong.com/spring-security/spring-security-form-login-using-database/. [Accessed 10 October 2019].

[18] The JUnit Team, JUnit 5, 2019. [Online]. Available: https://junit.org/junit5/. [Accessed 7 October 2019].

[19] hamcrest.org, Java Hamcrest, [Online]. Available: http://hamcrest.org/JavaHamcrest/. [Accessed 16 October 2019].

[20] Mockito, Mockito, 2019. [Online]. Available: https://site.mockito.org/. [Accessed 10 November 2019].

[21] OpenQA, SeleniumHQ, [Online]. Available: https://www.seleniumhq.org/. [Accessed 9 November 2019].

[22] Survey Monkey, Net Promoter Score (NPS) Survey, [Online]. Available: https://www.surveymonkey.com/mp/net-promoter-score/ . [Accessed 1 November 2019].

[23] H. Alathas, How to Measure Product Usability with the System Usability Scale (SUS) Score, 19 November 2019. [Online]. Available: https://uxplanet.org/how-to-measure-product-usability-with-the-system-usability-scale-sus-score-69f3875b858f. [Accessed 14 November 2019].

[24] A. Bangor, P. Kortum and J. Miller, Determining What Individual SUS Scores Mean: Addingan Adjective Rating Scale, Journal of Usability Studies, vol. 4, no. 3, pp. 114-123, 2009.

[25] Google, AI and machine learning products, [Online]. Available: https://cloud.google.com/products/ai/. [Accessed 12 November 2019].

AppendixAppendix A Use Case Descriptions:

Table A - 1 Create an account Use Case Description

ID FR001

Title Create an account

Description The user creates an account for Wakey Tracker

Actors User

Related Use Case Includes: none

Extends: none

Preconditions Entered the sign-up page from the login screen

Main flow Actor System

1. Enters account details into the screen and choose the account type

2. Validate the details

3. Save the details

Alternative flows N/A

Exception condition 2.a If invalid details are given (passwords dont match, username already taken, user submits invalid fields), then the user account is not created

Postcondition The user account of either student or teacher has been created

Notes Table A - 2 Login Use Case Description

ID FR002

Title Login

Description The user logs into Wakey Tracker

Actors User

Related Use Case Includes: none

Extends: none

Preconditions User is on the login page

Main flow Actor System

1. Enter username, password and account type

2. Validates username, password, account type

Alternative flows N/A

Exception condition The details are invalid. The user will not be logged in and will be moved back to the login screen

Postcondition User has logged in and moved to the relevant screen for their user type

Notes The user must choose between student and teacher the application wont know

Table A - 3 Report emotions Use Case Description

ID FR003

Title Report Emotions

Description The student reports their current emotions

Actors Student User

Related Use Case Includes: none

Extends: none

Preconditions Student User has logged in

Main flow Actor System

Alternative flows 3.1

Exception condition Postcondition The emotion report has been saved

Notes Table A - 4 Review previous emotions Use Case Description

ID FR004

Title Review previous emotions

Description Student can open a report of their previous emotions

Actors Student User

Related Use Case Includes: none

Extends: none

Preconditions Student logged in, student has previously reported emotions

Main flow Actor System

1. Request past emotions report 2. Retrieves past emotions

Alternative flows 2.1 If not past emotions, displays a message stating this

Exception condition N/A

Postcondition Student receives emotion report

Notes Table A - 5 View students' emotions in classroom Use Case Description

ID FR005

Title View students emotions in classroom

Description See an overall view of all students in the teachers classroom and their last reported emotion

Actors Teacher User

Related Use Case Includes: none

Extends: none

Preconditions Teacher is logged in. Teacher has students in their classroom

Main flow Actor System

1. Loads overview page 2. Retrieves data for each student

Alternative flows N/A

Exception condition N/A

Postcondition Overview of each student in classroom shown

Notes Table A - 6 See future emotion prediction

ID FR006

Title See future emotion prediction

Description Have the emotion prediction displayed

Actors Student User

Related Use Case Includes: none

Extends: none

Preconditions Student has enough emotion reports

Main flow Actor System

1. Request the emotion prediction 2. Retrieves emotion prediction

Alternative flows 2.1 If emotion prediction not set, then a message will be displayed, notifying user that not enough emotions yet

Exception condition N/A

Postcondition Emotion prediction is displayed

Notes Table A - 7 Student's future emotion prediction

ID FR007

Title See students future emotion prediction

Description Get the emotion prediction for a student in the teachers classroom

Actors Teacher User

Related Use Case Includes: none

Extends: none

Preconditions Teacher logged in

Main flow Actor System

1. Request prediction for student 2. Retrieve student prediction

Alternative flows 2.1 If prediction is from the past, then dont return it and notify the prediction engine

2.2 If a prediction for the student isnt found, send message notifying of this

Exception condition N/A

Postcondition Prediction returned

Notes Table A - 8 Register student to classroom Use Case Description

ID FR008

Title Register student to classroom

Description Teacher registers a student to their classroom

Actors Teacher User

Related Use Case Includes: none

Extends: none

Preconditions In register student view

Main flow Actor System

2. Chooses students to add and submits 1. Retrieves all students nicknames

3. Validates students to add to classroom

4. Adds students to teacher classroom

Alternative flows N/A

Exception condition 3.a If invalid, then show error message

Postcondition Students added to teachers classroom

Notes

Appendix B: SQL Entity Descriptions

Table B - 1 A description of each entitys attributes, their datatypes, and constraints. This is a description of the database schema that has been implemented for Wakey Tracker.

Entity Name Attributes Description Constraints Data Type & Length Null? Default

StudentUser id The unique id associated with the student account Primary Key INT NO Auto Increment

username The username the user set for the account UNIQUE VARCHAR

(20) NO password The students password. This is a hashed password CHAR

(64) NO accountCreated The date & time the account was created DATETIME NO Current Time of insertion

StudentReport reportId The unique identifier for the student report Primary Key INT NO Auto Increment

studentId The student that submitted the report Foreign Key (references StudentUser.id) INT NO reportTimestamp The date & time the emotion report was submitted by the student DATETIME NO Current Time of insertion

EmotionLevel reportId The report the emotion level is linked to - Primary Key (composite)

- Foreign Key (references StudentReport.reportId) INT NO Auto Increment

emotionId The emotion the emotion level is describing - Primary Key (composite)

- Foreign Key (references EmotionSet.id) INT NO emotionLevel The emotion level (from 0-9) the user reported INT NO EmotionSet id The unique identifier of the emotion that can be chosen Primary Key INT NO name The name of the emotion VARCHAR

(10) NO icon The icon of the emotion to be shown VARCHAR

(40) NO description The description of the emotion VARCHAR

(50) YES TeacherUser id The unique id associated with the teacher account Primary Key INT NO Auto Increment

username The username the user set for the teacher account UNIQUE VARCHAR

(20) NO password The teachers password. This is a hashed password CHAR

(64) NO accountCreated The date & time the teacher account was created DATETIME NO Current Time of insertion

Classroom teacherId The teacher in charge of the classroom Primary Key (Composite) INT NO studentId The student in the teachers classroom Primary Key (Composite) INT NO

Appendix C: Table Creation SQL Queries

SET FOREIGN_KEY_CHECKS=0;

DROP TABLE IF EXISTS StudentReport;

DROP TABLE IF EXISTS EmotionSet;

DROP TABLE IF EXISTS EmotionLevel;

DROP TABLE IF EXISTS Classroom;

DROP TABLE IF EXISTS StudentUser;

DROP TABLE IF EXISTS TeacherUser;

DROP TABLE IF EXISTS Users;

DROP TABLE IF EXISTS UserTypes;

SET FOREIGN_KEY_CHECKS=1;

CREATE TABLE StudentUser (

id INT PRIMARY KEY,

username VARCHAR(20) UNIQUE,

password CHAR(64),

accountCreated DATETIME DEFAULT NOW()

);

CREATE TABLE TeacherUser (

id INT PRIMARY KEY,

username VARCHAR(20) UNIQUE,

password CHAR(64), #Bcrypt hash

accountCreated DATETIME DEFAULT NOW()

);

CREATE TABLE IF NOT EXISTS StudentReport (

reportId INT PRIMARY KEY AUTO_INCREMENT,

studentId INT,

reportTimestamp DATETIME DEFAULT NOW(),

FOREIGN KEY (studentId) REFERENCES StudentUser(id) ON UPDATE CASCADE

);

CREATE TABLE IF NOT EXISTS EmotionSet (

id INT PRIMARY KEY AUTO_INCREMENT,

name VARCHAR(10) UNIQUE,

icon VARCHAR(40),

description VARCHAR(50)

);

CREATE TABLE IF NOT EXISTS EmotionLevel (

reportId INT,

emotionId INT,

emotionLevel INT,

FOREIGN KEY (reportId) REFERENCES StudentReport(reportId)

ON UPDATE CASCADE,

FOREIGN KEY (emotionId) REFERENCES EmotionSet(id) ON UPDATE CASCADE,

PRIMARY KEY (reportId, emotionId)

);

CREATE TABLE IF NOT EXISTS Classroom(

teacherId INT,

studentId INT,

PRIMARY KEY (teacherId, studentId),

FOREIGN KEY (teacherId) REFERENCES TeacherUser(id),

FOREIGN KEY (studentId) REFERENCES StudentUser(id)

Appendix D: SQL Table Creation Queries for redesigned Classroom

CREATE TABLE IF NOT EXISTS Classroom (

classId INT,

teacherId INT,

classCode VARCHAR(20) UNIQUE,

FOREIGN KEY (teacherId) REFERENCES TeacherUser(id),

PRIMARY KEY (classId)

);

CREATE TABLE IF NOT EXISTS ClassMembers (

classId INT,

studentId INT,

FOREIGN KEY (classId) REFERENCES Classroom(classId),

FOREIGN KEY (studentId) REFERENCES StudentUser(id)

);

Appendix E: Report Data

Table E - 1 Student Id 12345

ReportId Happy Neutral Sad Angry Anxious Depressed Datetime

1 3 7 1 1 1 1 Tue Nov 12 06:36:25 UTC 2019

2 4 1 1 1 1 1 Tue Nov 12 06:40:41 UTC 2019

3 0 0 0 6 0 0 Tue Nov 12 06:44:00 UTC 2019

4 0 0 0 0 0 0 Wed Nov 13 22:02:16 UTC 2019

5 0 0 0 0 0 0 Wed Nov 13 22:02:23 UTC 2019

6 2 2 0 0 0 0 Wed Nov 13 22:04:18 UTC 2019

7 2 2 0 0 0 0 Wed Nov 13 22:04:35 UTC 2019

8 2 0 0 0 0 0 Wed Nov 13 22:04:41 UTC 2019

9 9 0 0 0 0 0 Wed Nov 13 22:04:50 UTC 2019

10 4 0 0 0 0 0 Wed Nov 13 22:06:10 UTC 2019

11 0 0 0 0 0 0 Wed Nov 13 23:11:47 UTC 2019

12 5 0 0 0 0 0 Wed Nov 13 23:19:44 UTC 2019

13 6 0 0 0 0 0 Wed Nov 13 23:19:56 UTC 2019

14 6 9 0 0 0 0 Wed Nov 13 23:20:12 UTC 2019

15 1 3 0 0 4 9 Wed Nov 13 23:59:41 UTC 2019

16 1 3 0 0 4 9 Wed Nov 13 23:59:41 UTC 2019

17 0 9 0 0 0 0 Wed Nov 13 23:59:53 UTC 2019

18 9 9 9 9 9 9 Thu Nov 14 01:15:26 UTC 2019

19 0 0 0 0 0 0 Thu Nov 14 01:15:32 UTC 2019

20 0 0 0 0 0 0 Thu Nov 14 01:15:35 UTC 2019

21 0 0 0 0 0 0 Thu Nov 14 01:15:35 UTC 2019

22 0 0 0 0 0 0 Thu Nov 14 01:15:36 UTC 2019

23 4 2 0 0 0 0 Thu Nov 14 01:15:36 UTC 2019

Table E - 2 Student Id 1673

ReportId Happy Neutral Sad Angry Anxious Depressed Datetime

1 0 0 0 0 0 0 Wed Nov 13 22:09:24 UTC 2019

2 0 0 0 0 0 0 Wed Nov 13 22:09:25 UTC 2019

3 9 9 9 9 9 0 Wed Nov 13 22:27:39 UTC 2019

4 0 0 0 0 0 0 Wed Nov 13 22:27:51 UTC 2019

5 9 9 9 9 9 0 Wed Nov 13 22:28:04 UTC 2019

6 0 0 0 0 0 0 Wed Nov 13 23:29:12 UTC 2019

7 0 2 0 5 9 0 Wed Nov 13 23:59:09 UTC 2019

Table E - 3 Student Id 24376

ReportId Happy Neutral Sad Angry Anxious Depressed Datetime

1 0 0 0 0 0 0 Wed Nov 13 22:09:34 UTC 2019

2 9 0 0 0 0 0 Wed Nov 13 22:27:58 UTC 2019

3 9 0 0 0 0 0 Wed Nov 13 22:29:08 UTC 2019

4 9 0 0 0 0 0 Wed Nov 13 22:29:17 UTC 2019

5 9 0 0 0 0 0 Wed Nov 13 22:34:33 UTC 2019

6 9 0 0 0 0 0 Wed Nov 13 22:34:41 UTC 2019

7 9 0 0 0 0 0 Wed Nov 13 23:56:18 UTC 2019

8 9 0 0 0 0 0 Wed Nov 13 23:56:23 UTC 2019

9 0 0 0 0 0 0 Wed Nov 13 23:56:24 UTC 2019

10 9 0 0 0 0 0 Thu Nov 14 00:52:35 UTC 2019

Table E - 4 Student Id 34561

ReportId Happy Neutral Sad Angry Anxious Depressed Datetime

1 0 0 0 0 0 0 Wed Nov 13 22:09:00 UTC 2019

2 9 9 9 9 9 9 Wed Nov 13 22:28:55 UTC 2019

3 9 9 9 9 9 9 Wed Nov 13 22:28:55 UTC 2019

4 0 0 0 0 0 0 Wed Nov 13 22:29:02 UTC 2019

5 9 9 9 9 9 9 Wed Nov 13 22:29:53 UTC 2019

6 9 9 9 9 9 9 Wed Nov 13 22:29:53 UTC 2019

7 9 9 9 9 9 9 Wed Nov 13 22:30:27 UTC 2019

8 9 9 9 9 9 9 Wed Nov 13 22:31:41 UTC 2019

9 9 9 9 9 9 9 Wed Nov 13 22:34:20 UTC 2019

10 9 9 9 9 9 9 Wed Nov 13 22:35:06 UTC 2019

11 0 0 0 0 0 0 Wed Nov 13 22:35:08 UTC 2019

12 9 9 9 9 9 9 Wed Nov 13 22:38:29 UTC 2019

13 9 9 9 9 9 9 Wed Nov 13 23:58:53 UTC 2019

14 9 7 5 8 9 0 Thu Nov 14 00:55:22 UTC 2019

Table E - 5 Student Id 40612

ReportId Happy Neutral Sad Angry Anxious Depressed Datetime

1 0 0 0 0 0 0 Wed Nov 13 22:08:42 UTC 2019

2 0 0 0 0 0 0 Wed Nov 13 22:08:46 UTC 2019

3 0 8 0 1 0 0 Wed Nov 13 23:59:49 UTC 2019

Table E - 6 Student Id 50321

ReportId Happy Neutral Sad Angry Anxious Depressed Datetime

1 0 0 0 0 0 0 Wed Nov 13 22:09:17 UTC 2019

2 0 0 0 1 0 0 Wed Nov 13 22:32:48 UTC 2019

3 4 0 0 1 0 0 Thu Nov 14 00:01:21 UTC 2019

Appendix F: UML Class Diagram

Figure F 1 UML Class Diagram

This page has been intentionally left blank.

Trim Fit : An Accurate, Stable, and Low-Computational Framework for Predicting Body Fat.

Interim Report

Student Name :

Supervisor(s) Name:

Course:

Abstract

Recent years have seen a dramatic rise in both the incidence of chronic diseases and treatment expenditures. Loss of healthy years of life is accelerated by cardiovascular illness, diabetes, stroke, lung cancer, and chronic obstructive pulmonary disease. To make informed decisions about health, it is vital to have a precise estimate of body fat percentage. The inaccuracy of assessing body fat with conventional approaches like body mass index (BMI) and waist circumference highlights the need for a computationally efficient and trustworthy framework for predicting body composition. The research will gather a large dataset reflecting a variety of demographics, then use machine learning and statistical methods to develop an accurate prediction model. The project's goals include developing an easy-to-use method for determining body fat percentage, reducing computational requirements, ensuring inclusivity and generalizability across diverse populations, and achieving stability in forecasts over time. Accurate body composition evaluation for individuals and healthcare professionals is a primary goal of this research, with the hope that it will lead to better health management, disease prevention, and general well-being. The built framework will be incorporated into a functional and intuitive web-based or software application.

1.1 Background

According to WHO 2020, the global burden of death from cardiovascular disease, diabetes, stroke, lung cancer, and chronic obstructive pulmonary disease increased by over 100 million healthy life years between 2000 and 2019 (World Health Organization, 2020). A staggering US$1,044 billion is expected to be spent on heart diseases in 2030, up from approximately US$863 billion in 2010. Healthcare professionals use cardiovascular Risk Factors diseases in 2030, up from about US$863 billion in 2010 (Wang et al., 2021).

Healthcare professionals use cardiovascular Risk Factors (CRFs) to estimate the likelihood of heart attacks. CRF is associated with body fat percentage (PBF), whereby the PBF can help detect early-stage accumulations of CRF (Zeng et al., 2012). Hence, this study intends to develop a common computational-accurate-stable body fat prediction framework to enable medical practitioners and leers to make informed decisions about fat deposited in body fat prediction framework to allow medical practitioners and users to make informed decisions about fat deposits in the most vital body parts.

This study aims to create a computationally efficient and reliable approach for estimating body composition from sparse data. If you want an accurate picture of your health and disease risk, you must know your body fat % (Parker, 2018). Erroneous results, instability, and high computing requirements are only some problems plaguing the state-of-the-art approaches to measuring body fat. To overcome these obstacles, this project will develop a unique framework for accurate and efficient body fat prediction. The project aims to create a technology that accurately estimates body fat percentage using little computational resources.

1.2 Objectives

To establish a framework that can reliably forecast a person's body fat percentage.

To address current body fat prediction models' instability and create a framework that reliably predicts body fat percentage over time.

To develop a low-computationalmethod for predicting body fat that will function consistently across various computer systems, even those with limited resources.

To makeaninclusive and generalizable system that willenable precise body fat predictions for people from various demographic backgrounds.

To develop an accessible and valuable method of calculating a person's body fat percentage.

1.3 Research question

This study will seek to answer the following research question:

What variables or factors should be included in the framework for reliably forecasting a person's body fat percentage?

How can the instability of current body fat prediction models be addressed to create a framework that reliably predicts body fat percentage over time?

What strategies or techniques can create a low-computational framework for body fat prediction that can operate smoothly on computing platforms with constrained processing power?

How can the framework be designed to ensure inclusivity and generalizability, allowing accurate body fat predictions for individuals from different demographic backgrounds?

What methods or algorithms can be utilized to develop an accessible and valuable approach for calculating a person's body fat percentage?

If these questions could be answered, they would greatly aid in comprehending the complexities of BMI estimates. Body mass index (BMI), waist circumference (WC), skinfold thickness (SF), bioelectrical impedance (BI), and other pertinent measures will need to be measured and analyzed for this study to be successful.

The dataset's wide variety means that the framework can be used to solve many different types of issues. The research will use machine learning and statistical techniques to create a reliable prediction model. The framework will be built to be as computationally efficient as feasible, making it suitable for various computer systems (including mobile devices) without sacrificing precision or dependability.

2. Related Work

Assessing health, calculating disease risk, and tracking the success of measures to improve body composition all rely on reliable estimates of body fat percentage. Over the years, predicting body fat has been done in various ways, from straightforward anthropometric measurements to sophisticated imaging technologies (Gallagher et al., 2020). Many of these approaches, however, have low accuracy, inconsistent results, and excessive computing needs. This literature review summarizes the current methods and emphasizes the need for a computationally light, robust, and reliable framework for estimating body composition.

2.1 Traditional methods for estimating body fat

Body mass index (BMI) and waist circumference are two of the most common measures used to estimate body fat because they are easy to measure (Tran et al., 2018). However, several caveats to these approaches reduce their reliability for estimating body fat. For instance, body mass index (BMI) ignores differences in body composition in favor of measuring only height and weight (Anaya & Barroso, 2019). Inaccuracies arise, especially in those with high muscle mass or unusual body forms, because it fails to distinguish between fat and lean muscle mass.

The need for an accurate, stable, and low-computational framework for predicting body fat is heightened by the limits of traditional methods and the complications involved with modern techniques (Carlos M.P. Sousa et al., 2019). The constraints of conventional approaches can be solved without resorting to resource-intensive, high-tech procedures if an easily-accessible model is developed to account for changes in body composition. Such a structure would close the gap between the ease of use and precision, paving the way for its more comprehensive implementation and making it easier to routinely monitor body fat in a wide range of healthcare, fitness, and research settings.

2.2 Machine learning and statistical modeling approaches

Predicting body fat percentage has become increasingly dominated by methods from machine learning and statistical modeling in recent years. Due to their capacity to use large datasets and implement complex algorithms to produce reliable predictive models, these approaches have received much attention (Fan et al., 2022).

Figure1: Body fat prediction from Statistical (anthropometric and laboratory data). https://journals.plos.org/plosone/article/figure?id=10.1371/journal.pone.0263333.t002 Artificial neural networks, support vector machines, and random forests are just some machine learning techniques that have shown promise for use in assessing body fat. Compared to the previously employed approaches, these cutting-edge models produce more reliable estimates of body fat percentage. It is worth noting, however, that there are obstacles to general adoption and future improvement of these methods, such as difficulties of instability and large processing requirements.

2.3 Bioelectrical Impedance Analysis (BIA) Method

Researchers have started looking into several potential solutions to these problems. Bioelectrical impedance analysis (BIA) is one example of a popular, low-cost method for determining a person's fat percentage. Electrical impulse BIA has shown reasonable accuracy compared to reference methods for measuring body composition (Galitzer, 2020). However, issues about its consistency and generalizability across populations persist.

Figure 2: Bioelectrical Impedance Analysis (BIA). https://drgalitzer.com/blogs/energy-medicine/about-bioelectrical-impedance-analysis-bia There has also been work to reduce the complexity of models, making them easier to implement and execute on a smaller scale. Waist-to-hip ratio and skinfold thickness are the most prominent anthropometric measures in these models to predict body fat percentage. However, the accuracy of these simplified models may suffer compared to more thorough methods (Duren et al., 2018).

Figure 3: (Body Composition in Sport: BIA - Adam Virgile Sport Science, 2018) https://adamvirgile.com/2018/12/30/body-composition-in-sport-bia/

3. Project Outcomes and Deliverables

3.1 Framework for Predicting Body Fat Percentage

The completed work will provide a reliable system for estimating body fat. The framework will use machine learning and statistical techniques to make reliable forecasts. Anthropometric data, including body mass index (BMI), waist circumference (WC), the standard for height and weight (SF), blood inoculation (BI), and other factors, will be used to improve forecast accuracy. The framework will be made to function for a wide variety of people and on a wide variety of computing platforms, including those with constrained processing power.

3.2 Increased Stability in Predictions

This study aims to improve upon previously established methods for estimating body fat percentage. The created system will ensure accurate prediction of body fat % by providing steady and consistent forecasts. Reducing fluctuations and forecasting errors will enhance the reliability and usability of body fat measures for health evaluations.

3.3 Low-Computational Requirements

The method will produce a computationally cheap framework for determining fat mass. This framework will be designed to run well on various devices, from smartphones to older, less powerful desktop computers. Using this approach, calculating a person's body fat percentage won't require a lot of processing power, making it accessible to both laypeople and medical specialists.

3.4 Inclusive and Generalizable Framework

The research will collect a diverse dataset of many demographics to guarantee the framework's broad applicability. The framework's accuracy in predicting body fat percentage for different demographics depends on its ability to properly account for these variations. Health inequities may be mitigated due to the expanded user base for the framework.

3.5 Accessible Body Fat Calculation Method

This work intends to supply an accessible method of calculating a person's body fat percentage. The user-friendly design of the underlying framework will facilitate BMI estimation by anyone, not just trained professionals in the field of medicine. The project will contribute to health management and promote effective disease prevention by providing a reliable method of measuring body fat.

4. Project Plan and Methodology

These goals can be accomplished through the use of the following framework and procedures:

4.1 Data Collection

The data collection method will center on amassing a diverse dataset that reflects numerous demographics to guarantee the framework's inclusiveness and generalizability (Romero et al., 2019). Age ranges, sexes, ethnicities, and geographic locations will be represented. The framework's scope can be expanded by incorporating diverse people.

By teaming up with hospitals, universities, and health clubs, data can be collected from various sources, making the findings more generalizable. The results of body composition assessments performed as part of healthcare or fitness monitoring can be gathered thanks to these partnerships.

The major variable of interest for estimation will be body fat percentage (BF%), measured in the dataset. The participant's body mass index, waist size, skinfold thickness, and bioelectrical impedance will also be recorded. These are standard tools for gauging body fat percentage, and they'll provide the prediction model with more data to work with.

Variable Description

Body Fat Percentage Percentage of body weight that is fat

Body Mass Index Ratio of weight to height squared

Waist Size Circumference measurement at the waist

Skinfold Thickness Thickness of skinfolds at specific sites

Bioelectrical Impedance Measurement of electrical impedance through the body

Table 1: summary of the parameters and measurements involved in determining a person's body fat percentage.4.2 Data Preprocessing

Several preprocessing processes will be applied to the obtained dataset before it is ready for analysis and modeling. These procedures will improve the prediction model's accuracy by addressing missing data, outliers, and noise. The following procedures will make up the preparation of data:

Preprocessing Procedure Description

Data Cleaning Missing data, outliers, and noisy data must be dealt with during data cleaning. Imputation approaches, including mean imputation, regression imputation, and cutting-edge methods like multiple imputations, will fill in the gaps left by missing data. The Z-score, a modified Z-score, or Winsorization, will be used to identify and handle outliers appropriately. The data will be smoothed and filtered to get rid of the noise.

Feature Scaling Scaling features to a common range is a typical practice for ensuring all features are similarly weighted in the model. The characteristics will be rescaled using normalization (min-max scaling) and standardization (z-score scaling).

Feature Selection or Dimensionality Reduction Dimensionality reduction (also known as feature selection) involves decreasing the number of characteristics to eliminate extra or useless data. Feature selection procedures (such as recursive feature elimination and L1 regularization) and statistical methods like principal component analysis (PCA) will narrow the pool of candidates.

Data Transformation Sometimes, the quality of the predictive model can be enhanced by altering the data. Skewed distributions, for instance, will be normalized using logarithmic or exponential transformations.

Data Splitting The dataset is typically partitioned into training, validation, and test sets. The model is trained on the training set, validated on the validation set, and tuned for optimal performance using hyperparameters on the test set.

4.2.1 Addressing Missing Data

Any missing data points from the set will be tracked down and filled in. Imputation methods (e.g., mean imputation, regression imputation) and the exclusion of incomplete samples are two methods that can be used to deal with missing data (Nguyen, n.d.). The dataset's characteristics and the effect of missing values on the analysis will determine the approach taken.

4.2.2 Outlier Detection and Treatment

Extreme values beyond the norm might skew analysis and impact how well a model works. Statistical tools (such as the z-score and the interquartile range) and machine learning algorithms (like the isolation forest and the k-nearest neighbors) will be used to find and deal with outliers. Outliers can be treated through strategies like removing them, crediting them with appropriate values, or transforming them to reduce their impact (Bonthu, 2021).

4.2.3 Noise Reduction

The prediction model may produce inaccurate and unreliable results if "noise," or random fluctuations or faults in the data, is present. Noise reduction techniques, such as smoothing methods (e.g., moving averages and median filters), can be applied to reduce the impact of noise and enhance the robustness of the data (Median Filtering - an Overview | ScienceDirect Topics, n.d.).

4.3 Model Development

The model construction stage aims to utilize machine learning algorithms and statistical methods to establish a body fat prediction framework. This research seeks to create a robust and trustworthy prediction model by experimenting with various techniques and algorithms.

4.3.1 Algorithm Selection

The viability of several algorithms for the body fat prediction task will be evaluated. Linear regression, polynomial regression, and support vector regression are all regression models that can be used to determine if there is a correlation between the input features and the BMI (Frost, 2017). Multiple models can be combined to increase prediction performance using ensemble methods such as random forests, gradient boosting, or Boost. The capacity of deep learning architectures like convolutional neural networks and recurrent neural networks to grasp intricate patterns in the data should be explored.

4.3.2 Resources (Hardware and Software Requirement)

Hardware

The scalability of the dataset and computational complexity of the machine learning methods selected will determine the hardware requirements. The system program will be developedusinga computer with at least 8GB of RAM and a powerful central processing unit (CPU) or graphics processing unit (GPU). Access to high-performance computing resourcesor cloud computing services will be necessary for massive data sets or computationally intensive methods.

Software

The software requirements for developing the framework include the following:

Programming Language: Java and relevant libraries and frameworks will be used for application development.

Machine Learning Libraries: Weka, sci-kit-learn (for Python), or Apache Spark MLlib will be utilized for implementing machine learning algorithms. The one which will exhibit best result will be considered.

Web Development Frameworks: Frameworks like Django (for Python) will be employed for web application development.

Database Management System (DBMS): MongoDB will be used for storing and retrieving data.

Version Control: Git will be used to manage the source code and collaborate with other researchers.

4.3.3 Framework Implementation and Optimization of Objectives

The resulting model will become a part of a fully-fledged, user-friendly website or software. Users will be able to anticipate their body fat % with high accuracy after entering important factors (such as their height, weight, and age) into the app's user-friendly interface. Several programming languages, including Java, are suitable for the implementation. Java is well-suited for the framework's development because of its extensive machine learning and web development libraries. Java willbe used to create the application with the help of frameworks and libraries like Spring Boot, Hibernate, and Weka.

To symbolize the framework's aim to perform exceptionally well in accuracy, dependability, and speed, the following formula will be used:

Framework Objective = f (Accuracy, Stability, Computational Efficiency)

The success of the framework is contingent on these three variables:

Accuracy: This metric measures the precision with which the model can predict changes in body fat. Root Mean Squared Error (RMSE) or Mean Absolute Error (MAE) could be used to quantify this. Predictions with a greater accuracy value are more likely to come true.

Stability: Stability is the model's capacity to produce reliable long-term predictions. It guarantees that the model's accuracy doesn't decline as more data is added. The stability of a model could be evaluated by monitoring its performance metrics throughout a range of time intervals and checking the reliability of its predictions.

Computational Efficiency: The goal of optimizing the framework for computational efficiency is to make it run effectively on a wide range of computing systems, even those with constrained hardware and software. Training, prediction, and inference times and resource consumption are all taken into account here. Training time, prediction time, memory use, and central processing unit (CPU) utilization are all possible indicators.

These three components interact to generate the framework's ultimate goal, which is represented by the formula "f". The precise formulation of the function relies on the weights and relative relevance of the various criteria, which can change depending on the nature of the project.

4.3.4 Model Selection and Hyperparameter Tuning

Model selection is narrowing down a pool of potential algorithms to a manageable number by comparing their relative performance and picking the best one based on validation and evaluation data (Du, n.d.). Cross-validation can be used to assess how well various algorithms perform on the collected data.

Finding the sweet spot for an algorithm's hyperparameters is the goal of hyperparameter tweaking (Prabhu, 2018). The effectiveness of a model can be tweaked by adjusting its hyperparameters. Grid search, random search, and Bayesian optimization will determine the best values for the model's hyperparameters.

4.3.5 Validation Techniques

The generated model will be validated using appropriate methods to confirm its robustness and generalizability. To prevent overfitting, k-fold cross-validation, hold-out validation, and stratified sampling will be used to evaluate the model's performance on subsets of the data (Brownlee, 2018).

4.4 Evaluation and Validation

Depending on the specifics of the prediction task, measures like mean squared error, mean absolute error, and accuracy will be used to gauge the success of the created framework. The framework's effectiveness will be checked using cross-validation methods like k-fold cross-validation on various subsets of the entire dataset. The framework's performance will be evaluated using longitudinal data to ensure consistent predictions across periods.

4.5 Integration and Deployment

Individuals and medical professionals will have easy access to and use the body fat prediction system because of the framework's incorporation into a user-friendly software application or web platform. To ensure the best possible user experience on as many devices as possible, the software will be optimized for performance on low-powered systems. Rigorous testing and quality assurance procedures will be carried out to guarantee the deployed system's correctness, dependability, and usefulness.

4.6 Iterative Improvement

Feedback from users and domain experts will be collected to continuously improve the framework's performance and usability. Ongoing research and advancements in the field will be monitored to incorporate any novel techniques or methodologies that can enhance the accuracy and efficiency of the body fat prediction framework.

5 Ethical Issues

The development and implementation of the body fat prediction framework entail several ethical considerations. These considerations revolve around user studies, data privacy, copyright, and the potential impact on individuals and healthcare professionals. The project team will prioritize ethical practices throughout the research process to ensure the participants' and stakeholders' protection and well-being.

User studies involving human participants will require obtaining informed consent. All participants should be fully informed about the study's goals, methods, risks, benefits, and ability to voluntarily participate and discontinue at any time. Adequate data anonymization techniques will be employed to minimize the risk of re-identification (World Medical Association, 2022). Compliance with relevant data protection regulations (e.g., HIPAA) will be ensured.

Collaboration with medical institutions, research centers, and fitness centers for data collection necessitates addressing data ownership and copyright issues. Clear agreements and legal contracts will define the rights and responsibilities regarding data sharing, ownership, and usage. Proper acknowledgment and attribution of data sources will be ensured.

The project aims to collect a diverse dataset representing various populations to ensure inclusivity and generalizability. Special attention will be given to avoiding biases and discriminatory practices during data collection, preprocessing, and model development.

The framework's deployment should prioritize responsible use and consider the potential impact on individuals' health management and well-being. Clear communication and user guidelines should be provided to ensure proper interpretation and use of the body fat predictions. The framework should not replace professional medical advice but be a supportive tool for individuals and healthcare professionals.

Conclusion

In conclusion, this research aims to use machine learning and statistical methods to create a reliable prediction model that can overcome the shortcomings of existing methods like body mass index (BMI) and waist circumference. The goals are to build an accessible approach for computing body fat %, to make it easier for predictions to hold up over time, to make the framework low-computational, to ensure inclusivity and generalizability, and to improve prediction stability.

Data on body mass index, waist size, skinfold thickness, and bioelectrical impedance will be collected from participants from various backgrounds. Cleaning, scaling, selecting, and separating the data are all preprocessing operations applied to the obtained information. Imputation techniques will be used to fill in missing data, identify and handle outliers, and reduce noise in every way possible. Popular options in the model creation phase include linear regression, support vector regression, and convolutional neural networks, among other deep learning designs. The framework's development will prioritize precision, dependability, and computing efficiency. Validation and evaluation data will be used for model selection and hyperparameter adjustment.

A reliable framework for predicting body fat %, improved stability in forecasts, reduced computational requirements, inclusivity and generalizability, and an approachable method for calculating body fat percentage are all project outcomes and deliverables. The goal is to help people and medical professionals make more informed decisions about their health by providing more precise measures of body composition. The established framework will be implemented into a fully operational, user-friendly website or software.

6 Time Plan

Stage Start Date Finish Date Milestones Progress Reports Deliverables

Data Collection 1/7/2023 30/07/2023 Collaborations established with data sources Progress report on data collection Diverse dataset representing various populations

Data Preprocessing 1/08/2023 20/08/2023 Missing values handled Progress report on preprocessing Cleaned and preprocessed dataset

Model Development 21/08/2023 08/09/2023 Algorithm selection and evaluation. System Demo Progress report on model development Developed body fat prediction framework & System demonstration

Evaluation and Validation 08/09/2023 22/09/2023 Performance evaluation and validation Progress report on evaluation Evaluation metrics and validation results

Integration and Deployment 23/09/2023 20/10/2023 Framework integration into software application Progress report on integration User-friendly software application or web platform

Iterative Improvement 20/10/2023 10/10/2023 Feedback collection and incorporation of improvements Progress report on iterative improvement Feedback collection and incorporation of improvements

References

Anaya, C., & Barroso, M. (2019, October 15).6 Methods of Measuring Body Fat and Their Pros and Cons. Muscle & Fitness. https://www.muscleandfitness.com/workouts/workout-tips/6-methods-measuring-body-fat/Body Composition in Sport: BIA - Adam Virgile Sport Science. (2018, December 30). Adam Virgile Sport Science. https://adamvirgile.com/2018/12/30/body-composition-in-sport-bia/Bonthu, H. (2021, May 21).Detecting and Treating Outliers | How to Handle Outliers. Analytics Vidhya. https://www.analyticsvidhya.com/blog/2021/05/detecting-and-treating-outliers-treating-the-odd-one-out/Brownlee, J. (2018, May 21).A Gentle Introduction to k-fold Cross-Validation. Machine Learning Mastery. https://machinelearningmastery.com/k-fold-cross-validation/Carlos M.P. Sousa, Santana, E., Vinicius, M., Lima, G. F., Monteiro, L., Ribeiro, C., Allan Kardec Barros, & Pires, N. (2019).Development of a Computational Model to Predict Excess Body Fat in Adolescents through Low Cost Variables.16(16), 29622962. https://doi.org/10.3390/ijerph16162962Du, D. H. (n.d.). Chapter 4 Model Assessment and Selection | Machine Learning and Neural Networks. Inbookdown.org. Retrieved May 26, 2023, from https://bookdown.org/hailiangdu80/Machine_Learning_and_Neural_Networks/model-assessment-and-selection.htmlDuren, D. L., Sherwood, R. J., Czerwinski, S. A., Lee, M., Choh, A. C., Siervogel, R. M., & Chumlea, Wm. C. (2008). Body Composition Methods: Comparisons and Interpretation.Journal of Diabetes Science and Technology,2(6), 11391146. https://doi.org/10.1177/193229680800200623Fan, Z., Chiong, R., Hu, Z., Keivanian, F., & Chiong, F. (2022). Body fat prediction through feature extraction based on anthropometric and laboratory measurements.PLOS ONE,17(2), e0263333. https://doi.org/10.1371/journal.pone.0263333Frey, M. (2022, July 26).Bioelectrical Impedance Analysis (BIA). Verywell Fit; Verywell Fit. https://www.verywellfit.com/bioelectrical-impedance-analysis-bia-3495551Frost, J. (2017, November 10).Choosing the Correct Type of Regression Analysis. Statistics by Jim. https://statisticsbyjim.com/regression/choosing-regression-analysis/Galitzer, M. (2020, May 18).About Bioelectrical Impedance Analysis (BIA). Drgalitzer.com. https://drgalitzer.com/blogs/energy-medicine/about-bioelectrical-impedance-analysis-biaGallagher, D., Andres, A., Fields, D. A., Evans, W. J., Kuczmarski, R., Lowe, W. L., Lumeng, J. C., Oken, E., Shepherd, J. A., Sun, S., & Heymsfield, S. B. (2020). Body Composition Measurements from Birth through 5 Years: Challenges, Gaps, and Existing & Emerging TechnologiesA National Institutes of Health workshop.Obesity Reviews,21(8). https://doi.org/10.1111/obr.13033Median Filtering - an overview | ScienceDirect Topics. (n.d.). Www.sciencedirect.com. Retrieved May 26, 2023, from https://www.sciencedirect.com/topics/engineering/median-filteringNguyen, M. (n.d.). Chapter 11 Imputation (Missing Data) | A Guide on Data Analysis. Inbookdown.org. https://bookdown.org/mike/data_analysis/imputation-missing-data.htmlParker, T. (2018, August 15).Best way to measure body fat. Bhf.org.uk; British Heart Foundation. https://www.bhf.org.uk/informationsupport/heart-matters-magazine/nutrition/weight/best-way-to-measure-body-fatPetropoulos, F., Apiletti, D., Assimakopoulos, V., Babai, M. Z., Barrow, D. K., Ben Taieb, S., Bergmeir, C., Bessa, R. J., Bijak, J., Boylan, J. E., Browell, J., Carnevale, C., Castle, J. L., Cirillo, P., Clements, M. P., Cordeiro, C., Cyrino Oliveira, F. L., De Baets, S., Dokumentov, A., & Ellison, J. (2022). Forecasting: theory and practice.International Journal of Forecasting,38(3). https://doi.org/10.1016/j.ijforecast.2021.11.001Prabhu. (2018, July 3).Understanding Hyperparameters and its Optimisation techniques. Medium. https://towardsdatascience.com/understanding-hyperparameters-and-its-optimisation-techniques-f0debba07568Romero, D., Kwan, A., & Suchman, L. (2019). Methodologic approach to sampling and field-based data collection for a large-scale in-depth interview study: The Social Position and Family Formation (SPAFF) project.PLOS ONE,14(1), e0210776. https://doi.org/10.1371/journal.pone.0210776Tran, N. T. T., Blizzard, C. L., Luong, K. N., Truong, N. L. V., Tran, B. Q., Otahal, P., Nelson, M., Magnussen, C., Gall, S., Bui, T. V., Srikanth, V., Au, T. B., Ha, S. T., Phung, H. N., Tran, M. H., & Callisaya, M. (2018). The importance of waist circumference and body mass index in cross-sectional relationships with risk of cardiovascular disease in Vietnam.PLoS ONE,13(5). https://doi.org/10.1371/journal.pone.0198202Wang, W., Yan, Y., Guo, Z., Hou, H., Garcia, M., Tan, X., Anto, E. O., Mahara, G., Zheng, Y., Li, B., Kang, T., Zhong, Z., Wang, Y., Guo, X., & Golubnitschaja, O. (2021). All around suboptimal health a joint position paper of the Suboptimal Health Study Consortium and European Association for Predictive, Preventive and Personalised Medicine.EPMA Journal,12(4), 403433. https://doi.org/10.1007/s13167-021-00253-2World Health Organization. (2020, December 9).WHO reveals leading causes of death and disability worldwide: 2000-2019. Www.who.int. https://www.who.int/news/item/09-12-2020-who-reveals-leading-causes-of-death-and-disability-worldwide-2000-2019World Medical Association. (2022, September 6).WMA - the World Medical Association-WMA Declaration of Helsinki Ethical Principles for Medical Research Involving Human Subjects. Wma.net; WMA - the World Medical Association-WMA Declaration of Helsinki Ethical Principles for Medical Research Involving Human Subjects. https://www.wma.net/policies-post/wma-declaration-of-helsinki-ethical-principles-for-medical-research-involving-human-subjects/Zeng, Q., Dong, S.-Y., Sun, X.-N., Xie, J., & Cui, Y. (2012). Percent body fat is a better predictor of cardiovascular risk factors than body mass index.Brazilian Journal of Medical and Biological Research,45(7), 591600. https://doi.org/10.1590/s0100-879x2012007500059

Description: The Project Report should concisely overview their work on their l project. Assessment will be marked according to criteria that involve clarity, depth, and overall research coverage and outcomes of the individual contribution. The report will be approximately 10,000 words (approx. 50 pages).

In addition to electronic submission, two (2) hard copies signed by the student and supervisor must also be submitted to the course coordinator.

TECHNICAL CONTENT Absent or poor Below average Average Good Excellent Mark

Abstract (/5)

Concise summary of project.

Should convey the problem, solution and conclusion. 0-1: Poor summary of project. Several of: overly brief, overly general, unfocused, poorly structured/balanced, limited engagement with

actual project. 2: Unsatisfactory abstract. One of more of: overall brief, overly general, unfocused, poorly structured/balanced, limited engagement with

actual project. 3: Adequate summary of project. Should be a self- contained document. Some minor issues with project focus, structure and/or sentence balance. Mainly

descriptive. 4: Good abstract. Clear and concise overview of project. Balanced sentences on problem, solution and conclusion. 5: Excellent and structured abstract. Clear and concise summary of project.

Reflective content and project overview. Introduction/Problem definition (/5)

Brief overview of project context.

Clear problem definition and explicit project

aims. 0-1: Poorly defined project and lacking clear project aims. Several of: overly brief, overly general, poorly structured/balanced, limited engagement with

actual project 2: Unsatisfactory introduction. One of more of: overall brief, overly general, unfocused, poorly structured/balanced, limited engagement with

actual project. 3: Adequate project introduction and clear problem definition. Some minor issues with matching topic to project aims. Mainly descriptive. 4: Good introduction. Clear topic outline and why the topic is important.

Appropriate level of detail and clear engagement with broader discipline. 5: Excellent introduction and structured problem definition. Detailed aims and clear deliverables for the project. Literature review/Related work (/5)

Appropriate summary of prior work.

Suitable background for present work. 0-1: Section absent or has not demonstrated understanding of project background and implications of related work. 2: Limited review. Missing literature to answer key questions including: where the problem came from, what approaches are currently used, why current methods are limited and

who are the stakeholders. 3: Adequate review of literature and related work. Good overage of literature but some minor issues with topic coverage, balanced sub-sections and/or limited reflection. Mainly

descriptive. 4: Good standard indicating adequate knowledge and understanding of the relevant background and appropriate use of related work. Includes reflective summary. 5: Evidence of excellent engagement with project- oriented research.

Excellent analysis and discussion of research; explicitly points out relevance. Methodology/Design (/15)

Appropriate description of project methodology and design.

Use of appropriate SE tools and methods. 0-3: No or limited methodology. Limited engagement with SE context and/or individual project problem domain. Poor or

very brief design. 4-6: Brief or overly general methodology. Lack of engagement to the specific individual project. Ad hoc design and little evidence of

good software engineering. 7-9: Adequate use of good SE practice for project methodology and design. Minor issues in the use of SE tools or SE methods and/or

limited in design coverage. 10-12: Good standard indicating a high level of SE knowledge and understanding of SE methods for this specific

project. Detailed design. 13-15: Excellent standard indicating comprehensive knowledge and understanding of SE methods. Comprehensive

design. Implementation/Evaluation (/30)

Description of system implementation.

Detailed evaluation of project outcomes. 0-7: No or very limited evidence of software implementation and/or evaluation. 8-14: Some evidence of implementation and evaluation. One or more of: very simple, limited in scope, little evidence of testing, poor or limited useof SE methods. 15-20: Evidence of implemented system and appropriate testing.

Evidence-based evaluation. Some minor errors in either method and/or

presentation of evaluation. 21-25: Good system implementation and evaluation. Individual contribution highlighted. Well-structured evaluation across system and user

aspects, as appropriate. 26-30: Excellent report on significant implementation. Detailed evaluation with appropriate coverage of system and user issues.

Excellent mapping to

project outcomes. Results/Conclusion (/15)

Appropriate presentation of results.

Justified project conclusions. 0-3: No or poorly presented results. Limited, unjustified or overly general conclusions. 4-6: Overly brief or simple results presented. Limited conclusions and lacking consistency with project aims. 7-9: Adequate presentation of results. Appropriate summary of project. Some minor errors or overly brief sections in presented material. Mainly descriptive. 10-12: Good summary of project results and reflection on relevance. Clear conclusions and identification of limitations and possible future work. 13-15: Excellent results and conclusions. Significance clearly highlighted and summary that relates back to rest of report and literature. Clear reflection

on conclusions and project. REPORT Absent or poor Below average Average Good Excellent MARK

Quality of report and academic literacy (/20)

Good report structure with formal language.

Correct punctuation, sentence structure,

spelling and grammar. 0-4: Consistent major errors in report structure and communication, poor academic literacy used.

Student needs to seek help from Learning Development. 5-8: Mix of major and minor errors in either report or paragraph structure, or in academic language or ideas are not logically connected.

Inadequate academic literacy. 9-12: Several minor errors in either report or paragraph structure, or in academic language or ideas are not logically connected. Has

numerous errors in academic literacy. 13-16: Minor errors in either report or paragraph structure, or in academic language or ideas are not logically connected. Has

minor errors in academic literacy. 17-20: Report is lucidly written, cogent and concise. It is well structured, flows well and the ideas are clearly expressed.

Demonstrates excellent academic literacy. References (/5)

Appropriate reference style and correct use of citations.

Complete reference section and appropriate number of references. 0-1: Major errors in references including examples of: missing or low quality references, inconsistent referencing, incomplete references and incorrect citation. 2: Minor errors in references including one or more of: missing references, inconsistent referencing, low quality references, incomplete references, and incorrect citation. 3: Adequate use of referencing. Minor errors in references including: inconsistent referencing, incomplete references, and incorrect citation. 4: Good use of referencing. Appropriate and consistent referencing style. Some minor issues including incorrect citation use and/or errors in figure referencing. 5: Appropriate and consistent referencing style. Complete reference section and excellent use of citations in text body. Mark (%)

Download Solution Now

Uploaded By : Pooja Dhaka
Posted on : November 21st, 2024
Downloads : 0
Views : 135

Wakey Tracker: An Application for Emotion Tracking and Prediction in Adolescents

Download Solution Now

Download Solution Now

Choose a Plan

Premium

Gold

Silver

Wakey Tracker: An Application for Emotion Tracking and Prediction in Adolescents

Download Solution Now

Download Solution Now

Choose a Plan

Premium

Gold

Silver

Request a Call Back