1
1

1.0 Oct. 14, 2011
1.1
2.0
2.1
2.2
Oct. 14, 2011
Nov. 2, 2011
Nov. 5, 2011
Nov 6, 2011
Document created, individual parts compiled
System diagrams added; entire document edited, finalized, submitted
Feature priority updated
Separated Revision History and Table of Contents
Descriptions added to the
System diagrams
Jake Turner,
Derek Wu
Arsh Bhullar, Brian Hanley,
Jake Turner, Derek Wu,
Jason Wu, George Xie
Jake Turner
Jake Turner
Jake Turner
2
2

Website – p.4
Documentation – p.4
Ethical/Legal Guidelines – p.4
Fig. 1 – Class Diagram – p.5
Fig. 2 – Use Case Diagram – p.6
Input – p.7
iPhone/iPad Touch Screen – p.7
Website – p.7
Output – p.7
iPhone/iPad Touch Screen – p.7
Audio – p.7
Website – p.8
File Formats – p.8
Version 1 – p.10
Version 2 – p.10
Version 3 – p.10
3
3


This software will be developed under iPhone SDK for iPhone OS 2.2.1

Coding will be done in the Object C 2.0 programming language

This application will be a Cocoa application

GUI will be created using Xcode UIkit with built in interface builder

Data will be store in SQL in the .db format

Testing will be done using Xcode’s iPhone simulator

Subversion will be used as our primary Version Control System
Website

Website constructed using XHTML 1.0 and CSS mark-up language

Data will be stored in the SFU server under user : phw1

The Web platform was constructed using Javascript
Documentation

All documentation will be available in .pdf formats

Meeting Schedule was planned in Google Calendar

Meeting content was created in Google Document

System Diagram/User diagram will be scanned and uploaded to the website
Ethical/Legal Guidelines

All code is open source and is programmed by team Rainbow Hammer

All media including the sound, image and animation is original
4
4

5
Fig. 1 – Class Diagram
Summarizes the most important classes used by the system and the functions that manipulate them, categorized by where they are used. The arrows indicate user access to these classes and function; for example, the classes and functions grouped under the Reminder function can be accessed by both the Admin and User GUIs, but those grouped under the Alarm System function can only be accessed from the User GUI.
5

Fig. 2 – Use Case Diagram
Demonstrates the relationship between the Admin (i.e. a caregiver) and the User (i.e. a patient) with respect to the functions to be carried out by the application. A connection indicates that the client has write access to the specified module; both the Admin and the User have read access to the information contained within these modules.
6
6

iPhone/iPad touch screen

Main input device will be a 3.5 inches touch pad

Scratch-resistant glass

Volume up/down bottoms are design to control the all the audio volume in the device

Designed for a bare finger, multi-touch sensing

Silent/Screen rotation lock switch is to be used to switch different mode

On/Off Sleep/wake bottom to turn off the device or to set it to sleep or wake

Home bottom design for closing the active app and navigates to the home screen

Fingerprint-resistant oleophobic coating for later model ( iPhone3GS and later)
Website

Keyboard and mouse will be the primary input for user to navigate the website

Information on the website will be read only
iPhone/ iPad touch screen

3.5 inches liquid crystal display

320 x 480 HVGA 163ppi ( iPhone 3GS and before) , 640 x 960 at 326 ppi (iPhone4 and iPhone4S)
Audio

Speaker (audio output) is located on the bottom left

Microphone (audio input) is located on the bottom right
7
7

Website

PC monitor or any other device will allow user to view

All the document can be seen in .pdf or .doc format
File Formats

.mp3
Primary format for audio in the application

.png
Any images in the software will be created using this format

.pdf/.doc
Format for all the documentation in the project

.css
Style sheet applied on the website

.html
Basis of the website used to view data online

.db
Database format

.txt
Used to create database, raw data and error logs
 buttons & gestures
 iOS Developer Library - Apps Respond to Gestures, Not Clicks
 So far we have the tap gesture only, we can add more stranded gestures based on the above link.
8
8

9
 For most of our data usage, we can have objects archived to data-blocks such that they can be saved in a simple key-value store without complex databases on the server side
(values are data-blocks). This makes the server setup and connections simple, and allows very good privacy by encrypting the data-blocks on the client size such that even the server cannot and does not look into the user data.
In Summary:

Application data is archived to data-blocks, not SQL tables.
 In addition to https, all data on the server is encrypted so that only the client can decipher.

For the client side storage, we can save the large media files (.mp3, .jpg) in the file system. What is left is a relatively small data-set that can be completely loaded to ram at start up, and saved after edit.
 To upload data, a client groups all local edits since last upload into one encrypted datablock keyed by clientID and block# (to avoid conflicting with any other key). This key - data-block pair is uploaded to the server.
 To download data, a client periodically (once every hour) checks the server for new datablocks submitted by other users. (If network permits, a server side push format can also be considered) Once found and downloaded, it applies changes described in the datablocks to itself. (A normal notification is presented to the receiving user of the incoming data)



Add/edit/delete: As a simplification, all edits in data-blocks are Add operations. Add of a new object is a true add. Add of an existing object is an edit (it replaces all existing data, so we don't have to worry about delta encoding). Add of an existing object with nil data is a delete. All objects are identified by creator’s clientID and object#.
Conflict resolution: A data-block 'd' has one or more links to parent data-blocks that describes data presented to the user when 'd' was created. This link is followed recursively to find ancestor data-blocks. There can be no conflicts between ancestor and descendant since a descendant always overwrites data. If two data-blocks edit the same data 't' and one is not an ancestor of the other, then a conflict is discovered (A warning notification is presented to all users of the conflicting data). The conflict will be resolved by a data-block that is a descendant of both conflicting data-blocks by including a new version of ’t’.
Clients decipher data-blocks by a pre-shared key generated from a password that is never transmitted over the server. (it’s just like using secure wi-fi)
9

10
Version 1
The first version of our app will only feature the "Add Reminder" function, which will include the interface of the reminder itself. This will provide us with a framework upon which we can build our other features in future versions.
Version 2
Here, we will add the other offline features outlined in the Requirements Document. These features are as follows:
- Edit a Reminder
- Delete a Reminder
- Panic Button
- Who Am I?
- Contact Info
Some of these will be more trivial than others; for example, Editing and Deletion will essentially be alterations on the Add function. On the other hand, the Panic Button will need to include a mechanism to access the iPhone’s calling feature, which will likely be more complex.
Version 3
With all the major offline features implemented, development of the final version will be centered on implementation of the online component. Once we implement this, we will continue to refine the app to enhance the quality of the final product. This process may include, but is not limited to:
- Testing for a robust application
- Enhancing performance
- Polishing the UI
- Adding any additional features we may come up with
- Tweaking implementation of existing features to enhance the product
1
0