Transcript document

uKuda
Design and Planning
University of California, Los Angeles
CS 130, Spring 2009
Prof. Rupak
Michelle Auyoung - Borys Boyko - Kin Chung Chu - Brian Geffon - Brian Hou - Christopher Oentojo - Zev Solomon
Design Details
 uKuda will utilize HTTP and HTTPs protocols
 Challenge: obtaining a Secure Sockets Layer (SSL)
certificate for free
 Our toolkit: CakePHP, MySQL, JavaScript, CSS,
HTML
 Risk: can we develop everything we want within
the given deadline?
 Functionality over aesthetics
The Plan
 Establish framework, develop key features first
 Beautify later (aesthetically pleasing UI, Web 2.0)
 1) Database
 Controls whole backend
 What tables are needed, what they represent, how are they
connected?
 2) User accounts
 HTTPs and SSL
 3) Location database
 Importing – how to get 2.7 million entries into a database from a .txt
file
…
The Plan (continued)
 4) User profiles
 Google Maps API
 Friends
 Comments system
 “Where I’ve been”
 5) Location profiles
 Google Maps API
 Rating system
 “Who’s been here”
 6) Stories
 Integration with locations and user profiles
…
The Plan (continued)
 7) Homepage Layout and Design
 Story feed
 Top 10 lists
 Google Maps API
 8) Templates
 Search bar
 Quick login
 Navigation tabs
 9) Photo Upload Feature
 10) Web 2.0
 Aesthetics
 Fluid GUI
 Split into multiple builds
The Plan (continued)
 Build 1 (= prototype)
 User Accounts – Brian Geffon
 User Profiles – Brian Hou, Chris Oentojo, Zev Solomon
 Location Profiles – Michelle Auyoung, Borys Boyko, Kin Chung Chu
 Build 2
 Stories – Brian Hou, Chris Oentojo, Zev Solomon
 Home Page – Michelle Auyoung, King Chung Chu, Brian Geffon
 Website Template – Borys Boyko
 Build 3
 Photo Upload Feature – Michelle Auyoung, Kin Chung Chu, Brian
Geffon
 Web 2.0 – Borys Boyko, Brian Hou, Chris Oentojo, Zev Solomon
System Architecture
 Based around an SQL database hierarchy
 Database will contain several interacting tables
 Tables will have entries (ex: an entry in a “Users”
table is a single “User”)
 All interaction between components occurs at the
database level due to database table relationships
Cities
PK
Countries
id int(10) primary
PK
Regions
FK1
FK2
country_code char(2)
region_code char(4)
name char(64)
latitude double
longtitude double
population int(10)
slug char(255)
id int(10) primary
PK
id int(10) primary
FK1
country_code char(2)
code char(4) unique
name char(64)
Users_Cities
Users
FK2
FK1
city_id int(10)
user_id int(10)
PK
username char(16) unique
email char(255) unique
password char(64)
first_name char(32)
last_name char(32)
confirmed bool
confirmation_code char(10)
created DATETIME
Stories
PK
id int(10) primary
FK1
FK2
city_id int(10)
user_id int(10)
message text
rating int(1)
num_ratings int(5)
created DATETIME
latitude double
longitude double
id int(10) primary
id int(10) primary
code char(2) unique
name char(64)
flag_image char(255)
Profiles
PK
id int(10) primary
FK1
FK2
user_id int(10)
city_id int(10)
about_me text
date_of_birth DATETIME
created DATETIME
occupation char(64)
Users_Users
FK1
FK2
Images
PK
id int(10) primary
FK1
FK2
story_id int(10)
profile_id int(10)
local_path CHAR(255)
filename CHAR(64)
System Architecture: Continued… Database Table Structure
user_id int(10)
friend_id int(10)
Check First Name Field
Erroneous Input
User Clicks Registration Link
Check Last Name Field
Open Registration Window/Take User to Registration Page
Check Username Field
User Enters Information
User Clicks Submit Button
Check Email Field
Ask User to Edit Information
Check Password Field
Register User (add user to Users table, add user profile to Profiles table, link)
Ask User to Check Email and Confirm Membership
System Architecture: Continued… User Registration Procedure
User Clicks Login Link
Verify Account Credentials via the Users Table
Open Login Window/Take User to Login Page
Incorrect Information
Log User In
User Enters Information, clicks Submit Button
Ask User to Login Again
System Architecture: Continued… User Login Procedure
User Clicks "Forgot Username/Password" Link
User Enters Email Address, clicks Submit Button
Field Was Filled out Incorrectly
Verify that Field Was Filled out Correctly
Email Does Not Exist
Verify that Email Exists in Users Table
Tell User, Ask to Fill out Information Once More
Send Username and (new) Reset Password to User's Email
System Architecture: Continued… User Information Retrieval Procedure
System Architecture (continued)
 Clearly, there is a pattern for accepting user input:
Accept User Input
Verify User Input
User Input Incorrect/Missing
Ask User to fix Input Error
Proceed
System Architecture (continued)
 Adding user input to database table(s):
Attempt to add User Input to Appropriate Database Table(s)
Success
Proceed
Return Error
Failure
 Verifying user input via database table(s):
Attempt to Verify User Input against Appropriate Database Table(s)
Success
Proceed
Return Error
Failure
Testing Plan
 Unit testing for each module during development
1. User Accounts
2. User Profile
3. Registration/Login
4. Location pages
5. Stories
6. Google Maps API
 Mostly manual, possibly with customer
involvement
Testing Plan (continued)
 Integration testing for module groupings
1. Location databases
2. Search function
3. User account
4. Login
5. User / location interaction
6. Story
 Regression testing for each module intergration
Testing Plan (continued)
 System testing for whole system
1. Non-user actions
2. User actions
3. GUI testing
4. Load testing
5. Security testing
 Regression testing, one more time
 Have all requirements been met?
Milestones
 Repository has been up since the first week of
group meetings (current build number is in the
90s, mostly due to document edits)
 Basic database structure has been established
 World country, region, and city data has been
located (over 2.7 million entries!)
 Domain names and web space has been purchased
Thank You!
www.ukuda.com
Coming Spring 2009