T2 Physiological Sensors
From SoftwarePractice.org
Team Members
Faisal Syed
Project Introduction
This is the Group Assignment of Christian, Jimmy and Faisal's group T2, where we will be designing and creating certain features for a wearable physiological sensors. We will be designing the devices software and hardware and continually be testing and updating the various aspects of the project. In the end we will have an analysis of the design aspects like usage scenarios and class descriptions, and also some code implementation in Java to develop code for our proposed software system for the device.
Miniature Unified Process
Requirements
- Take readings of heart rate/body temperature/Galvanic Skin Response every 5 seconds when worn by user.
- Display updated monitor of heart rate/body temperature/Galvanic Skin Response.
- Timestamp all readings and store data in memory.
- Stored data can be later retreived and viewed on device.
- Stored data can be send and viewed on computer via USB.
- GUI must be clear and big enough for users of all type.
- Device Navigation must be as simple as possible.
- Allow multiple profiles for different users.
- Warn user when heart rate excessively high. ie. greater than 200 b/min.
- Allow user to start/stop readings.
- Have a power save function.
Stakeholders
- People who do the designs and development of the product, has the role of developing the concept to making the final prototype. They will decide on every aspect of the product eg. size, reliability, aesthetic, interface.
- Role of constructing the product, from the final prototype given by designers. Must also package and distribute product to retailers.
- Must advertise product to target users. Must do research to maximize product revenue. Also calculate selling price to obtain maximum profit, at an attractable price.
- Will sell the product to users. They must has a key understanding of product features and functions, to persuade consumers in purchasing product.
- These are the majority of users, marketers will focus on this group to promote product. Designers must design product to suit END USER needs and expectations
Usage Scenarios
Scenarios 1
Dr. Phil had a patient with an unknown heart condition, Bill. He insisted that Bill wear the Physiological Sensor to record his heart activity until his next visit. Bill wears it for 3 days before the next visit to Dr. Phil. During the 3 days Bill continues his normal everyday life, while the sensor records his heart rate. After the 3 days Bill visits Dr. Phil who connects the sensor to a computer and downloads the data that the sensor has collect in the 3 days. A computer program then interrupts the data and displays it on a graph. Dr. Phil reads the graph and he provides his feedback on what he thinks is Bill has and ways Bill can improve his health.
Scenarios 2
Frank is 80 years old and lives in a nursing home, he has a critical heart condition, where his heart beats irregular and when under stress he sometime as a heart attack. It is mandatory that Frank wears the Physiological Sensor 24/7 to monitor his heart. The sensor reads his heart rate in real-time and whenever it shows that his heart rate is increasingly high it will flash brightly red until his heart rates drop to normal levels. This will alert him and the people around him so he/others can take corrective measures to prevent him from undergoing a heart attack.
Scenarios 3
Professor's Ned Pharmaceutical company recently came up with a breakthrough in medicine and wanted to have clinical trials of the medicine on a large number of people. He needs a device that is inexpensive and is portable so that the patients can carry them. T2 provided them with their sensor watch which gave them real time information on the patient’s galvanic skin response, pulse, skin temperature.
Use Case Diagrams
Based on scenario 1
Based on scenario 2
Based on scenario 3
This collaboration diagram is just a quick and easy diagram to illustrate the basics of the various classes and how they will interact with eachother. We need to identify the subclasses of the GUI and decide where to interpret the data; either in the Sensor Data Class or the GUI Class. Once we define these classes and finish our CRC Cards we can draw up a more detailed Collaboration Diagram and even a Sequence Diagram
This is a collaboration diagram that is based on the patient/doctor scenario. It shows how the patient uses the device, displays the sensor data in the GUI and stores the data in Storage, where the Doctor is able to view the patients data.
Essential Use Case Diagram
* This is not a use case diagram! It looks like you want to show the flow of activity - use an activity diagram for this!
Class Diagrams
CRC Cards
Sequence Diagrams
Image:Sequence diagram.jpg
* The first sequence diagram is fine in terms of sequencing, but does not use correct UML syntax.
* The second sequence diagram does not reflect the textual description at all!
GUI Design
This sketch is the initial design of the Graphical User Interface done on paper. It shows how the buttons are layed out and where the various graphs will be positioned.
This is a modification of the GUI design after some discussion within the group to streamline the buttons and controls and make it a simpler and easy-to-use device. Also added was a STOP/RUN button, another screen to show a numerical value for the associated graph, and a button to allow the user to cycle through the different graphs. The design is shown in 3-D to show the various features and screen and button sizes. On the side on the device there is an ON/OFF button which you can press in and out, a USB slot and also added was a SD Memory Card Slot. Another diagram is also there to show the various dimensions and position of the various buttons and screens
* This is lovely! Well presented and thought through GUI design.
Design Issues & Points of Contention
-The initial size of the device as a whole was too large to wear comfortably on the body needed to be cut down in size to allow it to be worn underneath clothing\
-Since the device had to be wearable by a variety of users the wrist strap had to be adjustable so we made it with a Velcro strap so users would be able to adjust it to the appropriate comfort
-The device has to have enough storage capacity to store the data collected from the user so we needed a reliable cheap storage medium. We chose to use SD Card memory cards which are available in many different sizes. There is also the option of connecting the device via USB to a computer and uploading the data there
-We wanted to make the User Interface as simple as possible so we decided to have the various graphs and their buttons colour coded to symbolise which graph the user was viewing.
Some more design issues and decisions have arisen during the 2nd part of the design stage of the device. These have been discussed and the _ main issues are discussed below;
More Design Issues For Milestone 2
-The GUI had to be modified for simplicity and to ensure that the device would be small enough for it to be comfortable and wearable on the wrist. Our initial design had too many unnecessary buttons so we combines some buttons, edited the layout and implemented some side buttons and slots to utilise as much space as possible.
-for example- instead of having 3 buttons for each sensor we made it into 1 button which cycles through the different sensor readings to display them. this saved space and made it easier for users to navigate the system.
* Yes, good idea.
- We had to cut down some of the classes because some of them were impractical and we realised we could combine some classes. For example we made each of the sensor classes into one major class instead of 3 seperate ones. This made it easier for us to code it in just one class instead of three.
* Easier to code, but not necessarily more object-oriented! Also, you should have catered for simulation of data and having explicit interfaces to each sensor so that in the final product, you can easily substitute the hardware interface for the simulation class.
Problems Encountered
-We started off with 4 group members but one dropped out of the class so we had to do all the work with just the 3 of us
-We all have only basic knowledge of java from Object Oriented Programming so we had a lot to revise and learn for the coding of the project like the GUI and how to show a graph in Java. We obtained some help from the tutor and from internet so we worked from these sources.
-We all live pretty far from uni and eachother so it was difficult to schedule team meetings. We decided to work on the project for a time after the scheduled lectures on monday.
Contracts
Test Cases
* The test case design for RateMonitor is partially correct. What is not clear is where the range of values for Number have come from, and what is Number? Is it the input parameter to the method that provides the seed to the random number generator? If so, this should have been specified in the class/operation specification. If the range applies to the precondition, then this should have generated 5 test cases. For example, if the range is 100 <= x <= 200, then you get one normal test case for a mid-range value (say 150), 4 boundary test cases (100, 101, 199, 200). Or ... should the range limits be on the postcondition??
* Preconditions do not describe method calls. They describe restrictions on data/state. So for HrGraph, the call to the method in the precondition should be part of the test sequence, so that the program is in the desired state prior to calling the method under test.
Instructor comments
A fair start! Good to see some usage scenarios. You may like to write some that are from the point of view of the person wearing the device, not just the doctors. I see you have found a reference for a usage scenario template. That particular template is probably a little too structured for this assignment. I prefer that you write narratives like you have, where you include the motivations, background and context of the user. The uses cases are the more structured form, where a template like that can be useful.
I have added some comments in red throughout the document. These supplement the comments provided on the marking sheet. Lian 6th Nov 2008.
Task Allocations for Milestone Presentation Session
There are 8 slides we have to have for the presentation We can divide the work up between us, so put your name beside the ones you want to do
Jymmee
1. 3-5 sentences capturing the essential scope and functionality of your
system
2. Diagram of how software prototype fits into overall device/system
Phrasal:
3. A single example of a usage scenario (we've done some of these already we just need to choose which one to use)
4. The associated use case
5. Class diagram showing class names and relationships
6. A single sequence diagram related to a specific scenario/use case
Christiano.
7. Sketch/mockup of GUI design ideas (Christian- I can use the same sort of design I used for the IndividualAssignment)
8. Design issues or points of contention (2-5)
Things to do for Milestone 2! We gotta do these really well and make sure we address each point properly and thoroughly. We should meet early next week and choose what each one will do. Another way to do it is that we all work on one point for a weeka dn get one of the points done a week so we can focus on making them really detailed. See you guys on monday
1
Detailed model represented in UML class diagram, showing attributes,
operation signatures, multiplicity, named and typed associations.
2
Well-defined and unambiguous class specifications, including contracts for each (non-trivial) operation.
3
Exploration and documentation of object interactions using UML sequence and/or collaboration diagrams based on scenarios
4
Clear and logical articulation and explanation of design assumptions and decisions.
5
A selective set of unit test cases based on contracts, following functional unit testing guidelines.
