T5
From SoftwarePractice.org
Contents |
Inception
Introduction
The medical profession are interested in a wearable device that can measure and record physiological parameters of the human body. They hope that data collected in this way can be useful for medical diagnosis and provide clues to a person's physiological state over time.
Our task is to develop a system for such a device that a user can interact with. Our team is to design, develop, implement and deliver a functional software program that is capable of the following:
- collect data from 3 'simulated' hardware sensors
- store the data collected into a form of memory and timestamped
- retrieve that data
- display that data in the form of a graph
- the graph must dynamically update itself as data is collected
- user can enter personal data into the system
- all data stored must be capable of being stored onto an external file
- the size of the user interface must be of an appropriate size for a device that is to be worn by a human being
This system is to be delivered at the end of the semester and its functionality demonstrated.
Project Team
Team 5 consists of Nick, Carlo, Dragana and Anton. Between the two options that were available for this assignment, Team 5 opted to undertake Topic B: Wearable Physiological Sensors.
Ground Rules
The team will conduct formal group meetings during OOD tutorial sessions on Mondays between 12pm and 3pm. Additional meetings will be created when necessary, subject to team member availability.
Communication between team members will consist of face-to-face discussions during meetings and via e-mail exchanges.
Each team member will keep an online log of the activites that have been undertaken for this project:
Nick Larin - Nick's Logbook
Carlo Reyes - Carlo's Logbook
Dragana Stanic - Dragana's Logbook
Anton Ranaweera - Anton's Logbook
Minature Unified Process
Research
A summary of research data collected regarding the hardware sensors introduced in the Wearable Physiological Sensors topic scenario.
The project requires us to "design and construct a small software system using a set of object oriented design techniques and Java programming language". The context that this software system will be developed in is in the form of a device that measures the skin temperature, pulse and galvanic skin response of a user. The device is to be worn on the user and must be able to show the user the data that the device has collected. In order to collect the data, it is assumed that three hardware sensors attached appropriately onto the body of the user will be connected to (or be part of) the device.
Skin Temperature
Methods
- Feedback Thermometer: A thermistor attached to the subject's digits or web dorsum measures the subject's skin temperature.
- Non-contact infrared thermometer located at forearm or chest.
([1])
Pulse (Heartbeat)
Methods
- The pulse can be measured in any place that allows for an artery to be compressed against a bone: neck, wrist, on the inside of an elbow. Or a pulse can be measured with a sensor at the source of the beat - the heart.
Galvanic Skin Response
Background
- Galvanic Skin Response (GSR) is a method of measuring the electrical resistance of the skin. There has been links made between the GSR of a user and their current emotional state.
Practical Uses
- Measuring the GSR of a user has been used in polygraph devices (lie detectors). It is a component of polygraph devices.
- Members of the Church of Scientology utilize E-meters in their performance of auditing. The E-meter is based on GSR measurement.
Methods
- The GSR can be measured by attaching two sensors to the body and measuring the resistance between the sensors either by passive means (measuring current generated by the body) or by active means (passing a current through the body and measuring the resistance).
Key system elements
- The physical parameters of the device must be small (no larger than 11cm x 6cm x 0.8cm in height x width x depth) and light (weighing no more than 120 grams) so that it can be worn by a user.
- The system must take samples of readings at least once every 10 seconds or more.
- The system must be able to collect, store, retrieve and display data readings of skin temperature, pulse and galvanic skin response of a human being.
- The system must be able to present a dynamically updated graph(s) of sensor readings collected.
- The sensor data collected must be time*stamped.
- The sensor data collected must be able to be stored to a file.
- The historical data must be able to be retrieved and displayed over a selected timeframe.
- The historical data must be able to be downloaded to an external device.
- The system must be able to receive personal data that the user can enter, and store this data.
- The data entered into the system through the sensors will be numerical, converted by the hardware sensors into their appropriate standard units of measurements. (Pulse is measured in Beats per Minute [bpm]; Skin Temperature is measured in degrees Celsius [Cº]; and Galvanic Skin Response is measured in kilo-ohms [kΩ])
Key stakeholders
Key Stakeholders
- The user of the device who may be a:
- Athlete: who may want to monitor their statistics for improvement
- Patient: who is made to wear the device to assist in medical/clinical diagnosis
- Doctor: who uses the device on their patients to assist in their diagnosis
- Generic user: who has no unique motivation for getting the device
- Hypochondriac: who is obsessively concerned with one’s health
- Teacher: who is demonstrating the device to a class/audience concerning health awareness
- Student: who is studying that needs to know what the device does or how it works
- The system programmers/designers
- Retailers that will be selling the product
- The company manufacturing and distributing the product
- Competitors that produce similar products with all or some of the device's functionality
Key risks
- Risk
- Contingency Plan
System Risks
- Inaccurate sensor reading.
- Software bugs.
- Hardware sensors may cause unexpected harm to user (i.e. small electrical shocks, may get caught in user's clothing and "choke" parts of user's body)
- Device may not be compatible with all types of computer systems when the device is in the process of uploading the data stored in its memory to an external system.
Project Risks
- Problem team member
- Approach team member: identify problem and discuss future direction
- Incomplete code
- If code cannot be completed by the due date, any penalties will have to be accepted.
Elaboration
The architecture and requirements of the system were established during the "Elaboration" phase. To better understand the system, usage scenarios and a use cases were created. These allowed for a general set of classes to be produced. Finally, after gaining a better understaning of the interactions of the classes though class diagrams and sequence diagrams three user interface concepts were developed.
Usage Scenarios
1. Assisting in Diagnosis
"Beverly was feeling ill. Unable to narrow down what Beverly could possibly have, Dr. Foo suggested she use a device she could wear to measure her pulse, skin temperature and galvanic skin response to help him determine what could be wrong with her. Beverly was made to wear the device for an hour while she walked around the hospital, before Dr. Foo examined the results he downloaded to his computer. The readings Dr Foo found were important in seeing how Beverly’s statistics changed during an un-strenuous period of time."
2. Self Awareness
"Kevin was an occasional runner. He wanted to see how his body behaved while he ran. He purchased a device he could wear that measured his skin temperature, pulse and galvanic skin response. Kevin wore the device and programmed it to begin measuring and recording. He ran on a treadmill in order to control his running pace. At the start of the run Kevin felt motivated, but towards the end he felt tired and found little encouragement to continue running. At the end of the run he recalled the data on the device and examined the graph it displayed."
3. Exercise Monitoring
"Billy borrowed the new exercise-monitoring sensor off a friend as he'd heard it was helpful. On day 2 Billy felt enthusiastic to exercise so he connected the device up to his computer. It took a while for Billy to enter in his information onto the computer due to the small buttons and interface. He had additional difficulty attaching the device to his body. Growing impatient, Billy became so grumpy that he gave up and threw the device against the wall. Now Billy's very upset as he'll have to buy a new one for his friend and they don't come cheap."
4. Body Performance Evaluation
"Coach Johnson is the head coach of 'The Bears' - a premier league football team. He was interested in monitoring the bodily responses of each of the team’s members during their training sessions, and then comparing this to responses during actual games. Coach Johnson felt that having this extra information would enable him to make better informed decisions as a coach. Recently, he read about and purchased a new device for each member of the football team. The device is able to collect and store three items of information obtained from the user: skin temperature, galvanic skin response and pulse. The data collected by the device could also be downloaded to a computer. Coach Johnson found that this was a convenient way to compare the results of various team members. The players were really pleased that the device could be worn comfortably and that it did not interfere with their movement."
Initial Milestone Presentation Scenario
(Usage Scenario used during the initial milestone presentation)
Dwight Schrute wanted to show Angela just how fit he was. He took out the medical device that he had been using the day before. The device had stored the changes in his pulse, skin temperature and galvanic skin response over the course of one of his jogs at his farm. Dwight switched the device on and showed Angela several graphs which displayed how his pulse, skin temperature & GSR changed while he jogged. Looking to impress Angela further, he connected the device to his office computer, uploaded the data onto the computer, and emailed a copy of it to Angela.
Use Cases
Use Case Number: 1
Use Case Name: User Turns System On/Off
Description: A user wants to turn the device on. The user will manipulate a physical switch on the device to turn the system on. The system will initiate and turn on. When the user wants to turn the device off, they will do the same in turning the device on, and the system will turn off.
Use Case Number: 2
Use Case Name: User Enters Personal Data
Description: A user wants to enter their personal data into the system. The system will ask the user for their name, age, height and weight. The user will enter their details using alpha-numeric symbols. The user's details will be stored on the device.
Main Path:
1. User will navigate through the system to enter their data.
2. The system will ask the user for their name.
3. The user will enter their name, using only letters. The user will confirm when they are finished entering their name.
4. The system will ask for the user's age, height and weight.
5. The user will enter them just as they entered their name in step 3.
6. The system will save the data and return the user to the previous screen before they had entered their data.
Use Case Number: 3
Use Case Name: Begin Session
Description: The user wants the device to begin recording their physiological changes. The user navigates through the system to begin a recording session. The system will begin recording data collected by the hardware sensors.
Use Case Number: 4
Use Case Name: End Session
Description: The user wants the device to cease recording their physiological changes. The user navigates through the system to stop the current recording session. The system will stop recording data collected by the hardware sensors, and note the end of the current session.
Use Case Number: 5
Use Case Name: Retrieve/Display Data
Description: The user wants to display the data the device is currently recording in the current session. The user will navigate through the system to display the data they want to view. The system will retrieve the data it has stored from the session, as well as the data currently being collected from the hardware sensors, and display it on the screen of the device. The user will also want to retrieve data recorded by the device from other sessions. The user will navigate through the system to retrieve the data from a particular session. The system will retrieve the data the user has selected, and display the data onto the screen of the device.
Main Path:
1. User asks the device to show the data for the current session and the data as it is being recorded.
2. The system retrieves the data for the current session only, from storage.
3. The system displays the data retrieved from storage, and also displays the data being received from the hardware sensors as they are collected.
Alternate Path:
1. User asks the device to show the data for a particular session.
2. The system retrieves the data for that session only, from storage.
3. The system displays the data retrieved from storage.
Use Case Number: 6
Use Case Name: Hardware Sensors Enter Data
Description: The hardware sensors are collecting data representing changes in the user’s physiology. This data is being sent to the system. The system will receive this data and store it, depending on if a session is currently active. If there is no current active session, then the system will discard the data received from the hardware sensors.
Use Case Number: 7
Use Case Name: Download/Transfer Data to External Device
Description: A user wants to transfer the data the device has collected onto an external device. The user will connect the device to another system. The device will communicate with the other system. The device will then copy its data onto the other system.
CRC cards
Initial Class Diagram
Initial Sequence Diagrams
The first sequence diagram includes the User entering details or choosing a user file, and initiating the sensor recording.
This sequence diagram shows the interaction enabling the user to view graphs of their sensor recordings.
User Interface Concepts
Idea One
This idea was inspired by the iPod Touch interface. It adopts the screen resolution and touch screen control. It is only viewed on a landscape orientation. Due to limitations of the screen and the data to be displayed on the screen, only numerical data can be entered into the device. A UserID is used to personalize each user.
Description:
There is a bar at the top of the screen which shows the current time and the remaining battery power of the device. The time shown could be the current time, a countdown of how much more time the device is to be worn, or a timer that shows how long the device has been worn so far.
At the bottom of the screen is a toolbar that contains five (5) buttons: Data Input, Skin Temperature, Pulse, GSR and Preferences. Pressing these buttons changes what is displayed at the center of the screen. Skin Temperature, Pulse and GSR will show graphs of the data recorded, as well as previous data collected. Data Input will allow the user to input unique information about themselves. Preferences will allow the user to control particular settings of the device, such as screen brightness, the current time, or the frequency at which data is collected.
The center part of the screen displays information unique to each of the buttons in the toolbar. Depending on which button is pressed will determine what can be viewed on the screen.
Ideas for a user interface with the following assumptions:
- The device has a touch screen display. If not, physical buttons can be placed on the sides of the screen to allow the user to select options displayed on a screen, similar to the interface observed on an Automatic Teller Machine.
- The screen of the device is 480 by 320 pixels. The size & proportion of the interface and its components can be scaled accordingly to any final decisions made as to the size of the screen. The screen must not be smaller than 3.3cm x 4.3 (height x width cm), otherwise the interface will become unusable and the data unreadable.
A rough sketch of an idea for the UI for the device.
A rough presentation of an idea for the UI for the device.
Idea Two
This idea was inspired by the “Tamagotchi” device. This device allows the user to control the game via only 3 input buttons. Pressing the buttons in different ways results in a different output, that is, pressing a button quickly (for <3 seconds) performs one task while pressing the same button for longer (>3 seconds) performs a different task.
While this device is controlled using 5 push-buttons there is potential for this to be reduced down to 3 by incorporating the functionality of the two yellow buttons into the red button.
Description:
The device is operated using 5 push-buttons. The green button acts as an on/off switch as well as an “enter” key. The device can be switched on/off by holding down the green button for >5 seconds. If the green button is to be used as an enter key then it only needs to be pushed quickly (ie. held down for <5 seconds).
The blue button brings up the user input screen. Here the user is able to enter the current time, their name, weight and height. As the device does not have a keyboard as such, the user will need to scroll through the numbers (0 – 9) and letters (A – Z) using the yellow up and down buttons to enter their information. Once the user has scrolled to the correct character they will need to press the enter key (green button) for the selection to be “locked in”. The position marker will then move to the next character. This method of entering data may be a little cumbersome, but is suitable as there is not a lot to be entered. If the user wishes to cancel an input, they must hold down the "up" and the "down" button simultaneously.
The red button allows the user to view a graphical display of the three sensor outputs: pulse, skin temperature and galvanic skin response. While viewing one graph (eg. pulse sensor output) the user can press the red button again and this will display the next graph (eg. skin temperature sensor output). A graph title will be displayed in the top-centre of the screen so as to avoid confusion between different graphs.
Finally, a small icon in the top-right-hand corner of the screen will indicate the remaining battery power.
Idea Three
Insert description here
Touch Screen and Touch Pads are growing trends in the modern technology. They simplify the input components and let the user to perform an increased number of operations. For this 3rd idea, we decided to use touch screen interface because there are number functionalities compared to the size of the device.
The Main screen displays three main characteristics of the device; Skin Temperature, Pulse and the GSR value at present. In addition to that, it displays touch links to five sub sections; Skin Temperature, Pulse, GSR Value, Data Inputs and Preferences.
Skin Temperature interface displays a graph with the values of the temperature within last 24 hours. It also displays the maximum, minimum and the average temperatures during that period.
Pulse interface also displays a graph of pulses at a given time. It shows the number of pulses per minute in numerical form. In addition to that, it evaluates whether the pulse rate is high, low and average and shows the status.
GSR interface is similar to the Skin Temperature. It shows the GSR values of the body for the last 24 hour period. It also displays the maximum, minimum and the present values of GSR.
Data Inputs interface is where the device can be fed with new user and its inputs. The device holds information such as user's name, weight and height. These values and be entered through a touch numerical pad consisting of characters similar to a pad in a typical mobile phone.
Preferences interface simply maintains the functions of the device. Its basic functions are as follows.
Data recording Clock settings Configuring data input type (Manual or Scheduled) Data Transferring method
At this approach, we decided that, by touching the interface buttons displayed at the bottom corner will navigate to the previous menu. That is the reason we have not added a "Back" button which navigates to the previous menus. But after consideration of Preferences interface, this could be rather complex. Therefore we decided to add a Back button on each of the interfaces.
Initial Milestone Presentation
These are the slides for the "Initial Milestone Presentation".
Construction
The construction phase includes the completion of the design of the software. We need to build the system and test that it functions as expected, through a series of test cases and system tests.
Source Code
The source code for this assignment can be found here
Final Class Diagram
Final Sequence Diagram
This sequence diagram shows the processes when a user runs the program and chooses to change the user name.
This sequence diagram shows the processes when a user creates a graph of one of their body responses.
Final User Interface
The screens shots below are that of the final user interface of the Physiological Wearable Sensor device.
Home
This is the first screen that the user will see when the device is powered on. The items of information that are displyed here are the name of the last user and the last known values for galvanic skin response, skin temperature and pulse. Once the new user has started recording a new session, this screen will reflect the current values.
Pulse
This screen shows a graphical representation of the changes in the user's pulse.
GSR
This screen shows a graphical representation of the changes in the user's galvanic skin response.
Temperature
This screen shows a graphical representation of the changes in the user's skin temperature.
Record
This screen allows the user to enter their name and start recording a new session. Once the new name has been entered the device will automatically start recording.
Transition
Class Specification
| Class | Name |
|---|---|
| Purpose of class: | To deal with the changes & storage of the username |
| Data attributes: |
|
| Operation Signatures: | |
| Class invariant: | firstName cannot be blank |
| Operation contracts: | Pre-Conditions: none
Post-Conditions:
|
| Class | Display |
|---|---|
| Purpose of class: | To create the jframes, content panes and buttons |
| Data attributes: |
|
| Operation Signatures: | |
| Class invariant: | firstName cannot be blank |
| Operation contracts: | Pre-Conditions: none
Post-Conditions:
|
| Class | ReadSensor |
|---|---|
| Purpose of class: | To take data input (from a text file), time-stamp the data and store it into a text file with the current date |
| Data attributes: | |
| Operation Signatures: | |
| Class invariant: | The data input file must be a .txt file type |
| Operation contracts: | Pre-Conditions:
Post-Conditions: none |
| Class | ReadFile |
|---|---|
| Purpose of class: | To read the data that has been stored to the text file. Each item of data is tokenized so that it can be used by the Graph class |
| Data attributes: |
|
| Operation Signatures: | |
| Class invariant: | |
| Operation contracts: | Pre-Conditions:
Post-Conditions: none |
| Class | Graph |
|---|---|
| Purpose of class: | Processes the data read in by the ReadFile class and creates graphs from that data |
| Data attributes: | |
| Operation Signatures: | |
| Class invariant: | |
| Operation contracts: | Pre-Conditions:
Post-Conditions: none |
| Class | Today |
|---|---|
| Purpose of class: | Obtains the data and current system time |
| Data attributes: | |
| Operation Signatures: | |
| Class invariant: | |
| Operation contracts: | Pre-Conditions: none
Post-Conditions: none |
References
http://www.jfree.org/jfreechart/ Package we used for the Graph class. Included classes and methods that make graphing in Java customizable.
http://www.java2s.com/Code/Java/Chart/JFreeChartDynamicDataDemo.htm Demo code used to demonstrate how dynamically updated graphs using jfreechart are implemented. Unfortunately we were unable to use the code to suit our needs.
http://java.sun.com/docs/books/tutorial/essential/concurrency/sleep.html
http://www.javaworld.com/jw-04-1996/jw-04-synch.html
http://www.faqs.org/docs/javap/c10/s2.html
http://java.sun.com/docs/books/tutorial/java/nutsandbolts/variablesummary.html
http://www.pixel2life.com/tutorials/java_development/date_and_time/
http://www.tutorialhero.com/tutorial-70-java_date.php
Citation
Instructor comments
Great start! Good to see you have researched some hardware sensors and referenced existing products as inspiration for your ideas. The usage scenarios cover a range of different user needs.
