Transcript ppt

eMatchBay
Hendi Chandi
Aleksandr Lyamtsev
Arifin Tahir
Ie Ling Tjam
Itasari Wiryanto
Operational Concepts

User Community
• People from all lifestyles and
demographics
• People with desires to meet new friends
anywhere and anytime safely.
• Good for people who are always on the
moves.
Operational Concepts
(continued)

Environment
• Works in any mobile devices running on
Windows platform, eg: IPAQ
• Information gathered from clients and
transferred to server through web services
using the Internet.
• Server filters and processes data according to
user’s requests.
• Assume:


More cell phones’ users switch to PDAs in future.
Transmissions of high bandwidth data become more
affordable.
Operational Concepts
(continued)

Major Benefits
• Meet new friends safely - rating system
• Link people with same interests and
lifestyle
• Provides feedback to users from peers
for self-reflection
• Provides an avenue for users to express
their opinion about their friends freely.
• Help shy-natured users to meet new
people.
Operational Concepts
(continued)

eMatchBay does not support:
• Verbal communications
• Concurrent written communications (eg:
MSN)
• Displaying matches on map
• Landscape detections
System Requirement
New Sign Up
User
•
•
•
•
•
•
Prompt with a welcome
page
Click on SIGNUP button
Fill in his information,
ranging from hobbies to
recreation. Everything else
is optional - set by default
as all null, except biodata.
Once data entry is
completed, prompt a
disclosure page.
Prompt a page disclosing all
risks involved, and
eMatchBay will not be
responsible for any harm
done to user.
After user accepts
agreement, user will be
able to use eMatchBay to
user’s heart content.
Server
•
•
•
•
•
User will supply, either from a
mobile device or a remote
computer, their personal data
(name, age, username,
password, gender, sexual
orientation, e-mail, marital
status).
Some constraints will be imposed
on these inputs (for example,
password must be 8 characters
long).
These information must be stored
successfully in our database for
future retrieval.
Database generates an ID
number for this user.
If information storage fails, user
must be prompted to re-input
data.
System Requirement
Returning User Login
User
•
•
•
•
Server
Starts program.
Login window will be
prompted to login.
One scenario out of three is
possible thereafter:

Profile found and
password matches.

Profile found but
password incorrect.

Profile not found.
User will be fed a home
page with all relevant links
or actions.
•
•
•
receives login information
looks for user profile in database
(using username) and clarifies
password.
If username and password
matches, grant permission for
this current user. If not, send
error message.
System Requirement
Edit Profile
User
•
•
•
•
•
User presses edit profile
button
To edit anything, user will
just need to change user’s
information, either using
textbox, dropdown menu,
radio button, etc.
User will have option to
disclose or hide certain
information.
After user completed all
changes, user will need to
click “SUBMIT CHANGES”.
From this time on, any
retrieval of user’s
information will be the
updated information
Server
• User must be able to update
profile at any time
• client side calls web service
that retrieves user profile, so
server retrieves those
attributes and returns them.
• Client side calls the web
service that updates user’s
profile, passing as
parameters all fields in
profile and their display
status.
System Requirement
User sets search criteria
User
•
User can choose from drop
down menu of several options
ranging from hobbies, bio-data
to recreation. All entries will
initially be by default set to
null.
•
User will most certainly be
prompted to enter biodata
range of person user expects
to meet. Everything else is
optional.
•
After user make all necessary
changes, user has to click
“SUBMIT CHANGES” to update
all changes on server.
•
From now, if user looks for a
match, it will be based on
criteria set up by user unless
user changes it again.
Server
•
•
•
Client side calls web service that
retrieves user’s search criteria,
server retrieves those attributes
and returns them
If user has never set a search
criteria before, null strings are
returned. Otherwise current
search criteria are returned to be
displayed.
If user decides to change search
criteria, client calls web service
that updates search criteria.
Search criteria includes age,
hobby, occupation, etc, and limit
to the number of matches.
System Requirement
User Searches For Matches
User
•
•
•
•
•
•
User will be checked whether
user has set the search criteria.
If not, user will go to part (c),
else user proceeds.
This will send a request to
user’s GPS-like* system to
locate his universal location.
User’s location will be stored at
user’s program
Program sends his location to
server to find best 10 matches
within user’s radius.
Matches will be placed inside
contact links. User can click
next or previous to browse
through pictures.
If user is interested to contact
person, user can use any
communication means specified
by other user. From here on,
user will be on user’ own risk.
Server
• User must have submitted a
search criteria.
• User must specify his/her location
to server using webservice.
• Server then queries database to
find all users within a certain
radius of current user which
doesn’t ban current user, doesn’t
opt to only give access to his/her
profile to people in his/her friend
list.
• After server retrieves profiles of
these other users, it calculates
best matches with user’s search
criteria.
• If another user is ON, current
user will be able to add user to
friend list, or send static
messages..
* Since GPS is not available, we will
be uploading map-coordinates to find
user’s location.
System Requirement
User Adds Another User
User
•
•
•
•
•
•
User will be checked whether
user has set search criteria.
This will send a request to
user’s GPS-like* system to
locate his universal location.
User’s location will be stored at
user’s program. Program will
send his location to server to
find best 10 matches within
user’s radius.
Matches will be placed inside
contact links.
User can click next or previous
to browse through pictures.
If user is interested to contact
person, user can use any
communication means specified
by other user
Server
•
•
•
•
User must have found other user
through the matching
User must know either the
username or e-mail address of
other user.
Other user must have his/her
status set to “on”, and must not
be in the friend list of the current
user. Other user is found through
match finding function, and when
prompted, accepts the request to
add him/her to friend list.
Other user receives a request,
and has the chance to either
accept or reject the request sent
by the current user.
System Requirement
User Rates Other Users
User
•
•
•
•
The user will choose the
person the user wants to
rate by selecting the
username or identifier
The user will then answer
question about user’s match
The user will then click
submit to prompt the server
to update the match’s
rating
From now on, every time
the user’s match rating is
requested, the new updated
rating will appear.
Server
•
•
•
•
The other user must be
contained in the current user’s
friend list. The scoring is open,
so the other user will not be able
to reject any score.
The current user will be asked to
provide a score that will be
entered into the database.
There will also be an option to
enter a textual “testimonial” of
the other user which will not
count toward the scoring.
This new score should be
displayed along with the other
user’s profile the next time some
other user asks requests it.
System Requirement
User Sends Static Message
User
•
•
•
To communicate with your new
match, the user will double click
at the match username or
identifier
A new window will open.
The user can just communicate
just like any instant messaging
system (more like SMS, not
MSN).
Server
•
•
•
User can send a static message to
any other users in his/her friend
list, and non-friend users who are
ON.
After user types in the messages
and submits it through a web
service, the server receives it and
first queries if the target user if
ON or OFF.
If target user is ON then it sends
message directly to client app. If
target user is OFF the message is
stored in the user’s inbox table in
the database. The next time user
is online and checks his/her inbox,
this message should be displayed.
System Requirement
User Bans Another User
User
•
•
•
•
The user will choose the
person’s username or
identifier
The user will be prompted
to make sure the user has
met the correct selection.
The user will have to click
“YES” to be processed, or
the ban is dropped.
After clicking “YES”, that
match’s username will be
entered at user’s ban’s list.
Server
• Either the other user was in
the current user’s friend list,
or he/she was included in a
match, or he/she sent a
message to the current user.
• Client side calls a web service
that takes the ID of the
person to be banned. The
other user’s ID is entered into
a list of banned users by this
user in the database
Software Architecture
Software specifications:
• Operating System: Windows Mobile Computing
• Software:
Microsoft .Net, using C# and SQL
Microsoft SQL Server
GPS software (ex: MapPoint) to identify users’ location.
Database specifications:
• Database will contain multiple tables with schema defined
using 3d normal form.
• Database should represent following properties:
- Personal information of a user
- Public information of a user
- Location descriptors
- Contact list and ratings stored by a user.
System architecture
•
•
•
•
•
•
Fast and reliable client-server communication using on-fly/session interactions with web services
Web services are called by application via a well defined API
API layer, sessions, and data buffers interface our web services
with database and clients
modular nature of our architecture will provide a convenient way
of producing updates for our application and issuing new features
for future releases.
API specification support administrative tools and updates
System behavior:
• Client application uses brief connection to internet from mobile
device to perform a specified task.
• Once connection is established, mobile application will access
appropriate web service, using client id as a session ID.
• server will perform task specified by a webservice, and return
information back to client using an XML stream.
Execution oriented view and data flow
Target
Requester
 Profiles
 Rating
 Matches





ID
Profile
Rating
Request
Location
Server
 Profile1
 Profiles
 Location
 Match
 Profile + rating
 Rating
 Feedback
Administrator
• Database Maintenance
• Critical updates, releases
 GPS services
 Map Point
 GPS data
 SQL requests
 GPS data
 Profiles
 Rating
 Location
API, sessions, data buffer
Matching
Comparator
 DB modifiers
 GPS requests
Rating
Calculator
Location
Identifier
Information
Gateway ->
Retrieval/Storage
Sample UI
Main page interface
User profile
User defined
matching specs
Lifecycle Plan
Why is the system being developed?



Create a program that satisfy the
customers’ need of close connectivity
Create sense of community
Networking
Lifecycle Plan
Milestones





Wk 1 – 2 (April 7th - May 3rd): Research
& design ( writing LCO and LCA)
Wk 3 (May 3rd – May 8th): Research on
rating questions, Database constructions
Wk 4 – 5 (May 9th – May 22nd): Build
server & client app (concurrently)/
Database Integrating
Wk 6 (May 23rd – 26th): Product
Integration (include: testing & debug),
Usage Doc. (README, etc)
Wk 7 (May 26th – June 2nd): Testing &
Debug, Prepare for final release
Lifecycle Plan
Who will do it?



Database constructions:
•
•
Design & build database
Team members: Hendi, Arifin, Ie Ling, Aleksandr
•
•
•
Search online for cosmopolitan style questions for rating users.
Set rating criteria for users
Team member: Itasari
•
•
Build UI for user interaction with program
Connect to server through server’s web services to carry out the functions in the
program.
Team members: Aleksandr, Arifin
Research on rating questions:
Client (user) App
•

Server App
•
•
Build web services that connect with client app and perform operations on
databases & user data according to request from client app.
Four parts:




Matching Comparator -> Team member: Hendi
Rating Calculator -> Team member: Ita
Location Identifier -> Team member: Hendi, Ie Ming, Ita
Information Gateway: Retrieval and Storage -> Team member: Ie Ming
Feasibility Rationale

Resources & Facilities
• All required resources are available & fulfilled:




2 PDAs
Database
Software: C# & SQL Server
Program Risks
• Seems small/manageable:



4 members experienced in databases and dealt with
web services before
Architectures (both client/server) are clearly laid out.
Seems reasonable for completion in four weeks time.
.Net provides easy implementation of UI.
Feasibility Rationale
(continued)

Other Risks:
• Unforeseen circumstances – may not be
able to finish program in 4 weeks.
• Not enough time to optimize the
program – efficiency problem
• Cost of mobile devices still high, but
expected to go down in future
• Users may not like the program