DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
UNIVERSITY OF TEXAS AT ARLINGTON
THE
MACtivity
Design Specification
Team Members:
Sanjay Vasudeva Iyer
Shwetha Narayan
Hardik Shah
Khandaker Moinur Rahman
Yu Xuan Zhang
4/16/2012
This document serves as a design specification for MACtivity app. This document is intended
to provide a high level overview of our design as well as detailed design description of some
major components of our system
MACtivity
Table of Contents
1. Introduction………………………………………….2
2. System Overview…………………………………...3
3. Design Considerations……………………………..3
4. Development Methods……………………………..4
5. Architectural Strategies…………………………….5
6. System Architecture………………………………...6
7. Database Design……………………………………7
8. Iteration 1…………………………………………...10
9. Iteration 2…………………………………………...19
10.
Iteration 3…………………………………….28
11.
Requirements Traceability………………….41
12.
Conclusion……………………………………43
1
MACtivity
1. Introduction
Making a suitable schedule for Maverick Activities Center (MAC) is a common
issue for UTA students. Students often go and wait long hours for slots. We envision
an android based application named MACtivity that gives a feasible solution by
estimating number of players playing different games at particular time slots. This
application also helps to automate the process of inviting friends to play together.
1.1. Purpose of this document
This document serves as a design specification for MACtivity app. This
document is intended to provide a high level overview of our design as well as
detailed design description of some major components of our system
1.2. Scope
This document describes all design issues of our app. It focuses on design
details based on each iteration of our project.
1.3. Intended Audience
First of all, this document serves as a design specification for students
developing this app. Next, this document gives an opportunity to share our
knowledge and view with our honorable professor and TA of course CSE 5324. Also,
assigned reviewer team will be able to evaluate our design and express their
opinions based on this design specification.
1.4. Prerequisite Documents
Readers of this document are requested to go through Project documents/slides
(available here) to get a better idea about what our app is and what are other
preliminary details of our project.
2
MACtivity
2. System Overview
MACtivity is an open source app based on android platform. It facilitates
students, faculties and guests of UTA who are interested to use various facilities of
Maverick Activities Center (MAC). This app provides an interface to schedule plan
for weekly activities in MAC, estimate number of users in MAC at a particular time
slot for particular games. It also makes group invitation process easier and faster for
multi-player games.
Our key system features include:
●
●
●
●
●
●
●
●
●
New user registration
User login/logout
Maintain a friend list
Plan Individually
Plan as a group
Important notifications
View various statistical data
Manage personal profile
Display schedule for a week
3. Design Considerations
In this section, we describe issues which need to be addressed before we
devise the design solution.
Assumption and Dependencies:






Our app will be available for android platform only.
MACtivity isn’t an app to book a slot in MAC.
It’s just an aid in planning. MACtivity doesn’t show the dynamic data (current
no of people) at the MAC.
The app doesn’t take into account the number of people who don’t use the
app, while showing an estimated number of people using the facility.
The numbers predicted are just the numbers collected from different users of
the app.
This app depends on a central server to store and update data
3
MACtivity
4. Development Methods
As the software development methodology, we are following iterative/incremental
approach. As proposed by our professor, we have 3 iterations in our project each
consisting of 2 weeks. We have designed our iterations in following way:
Iteration 1:
1. Login Page
2. Registration Page
3. Individual Plan
Iteration 2:
1. Group Plan
2. Friend List
3. Notification Page
Iteration 3:
1. Statistics Chart
2. User Profile Page
3. User Dashboard
In this design document, we covered all three iterations. We developed a running
system that works on android emulator with all the functionalities mentioned above.
4
MACtivity
5. Architectural Strategies
In this section, we describe some major design decisions and corresponding
reasoning behind those decisions.
Programming Language: Java is the obvious choice in this case
Database: Our app depends on a centralized database server. So, SQLite does not
fit in our scenario. We have chosen MySQL database system.
Build Target: We have chosen Android API 15, as this is the most up-to-date API
with all cutting-edge features and attractive components.
Project Hosting and Licensing: We are using google code as our repository under
license GNU GPL v3.
Version Control: Some of our programmers are already familiar with SVN as
version control system and we are using this for our project.
Hardware Interface: Our primary goal is to develop this app for android cell phones,
not for tablets. Once we succeed, we can enhance app to fit in tablet interface too.
Error Detection and Recovery: For better error handling we have designed several
test plans that would be applied during development. A set of test plans is described
in a separate document titled “Test Cases for MACtivity” (available here).
External Database: OIT of UTA provides 50 MB free space for students upon
request. We are using this benefit to host our MySQL database in Omega server.
5
MACtivity
6. System Architecture
For simplification, we divided our system into several components. Following figure
shows these components:
Figure 1: Major components of our system
We successfully developed all the modules during given time period.
Domain Model
6
MACtivity
7. Database Design
7.1. Database Description

Objective: The objective of this database is to store the credentials of
registered users and also to store the activity that is scheduled by the user.

DBMS Environment: For the First iteration we used the SQLite database
which is inherent to Android OS, however as the SQLite is server less and our
application requires a centralized server, by 2nd iteration, we moved to the
MySQL database hosted on the UTA Omega server.
7.2. Designs for Database Connectivity
Our app requires communicating a centralized DB server. For this purpose, we
used MySQL DB provided by UTA OIT. To pass data from our app to DB we have to
use a Custom HTTP Client which posts data as name value pairs to a PHP script.
PHP script runs the DB query and generates result. To fetch this result and use in
our app, we used JSON encoding.
For setting up this remote connectivity, we used and modified codes available in
net. We would like to thank following source for giving a detailed guideline along with
source code:
http://webdesignergeeks.com/mobile/android/android-login-authentication-with-remotedb/
7.3. Database Layouts
This app uses 6 tables in database. They are as following:
7.3.1. User Table
It has following attributes and data types:
a)
b)
c)
d)
id(Primary key): int(10)
fullName:varchar(50)
email:varchar(50)
password: varchar(50)
7.3.2. Friends Table
It has following attributes and data types:
7
MACtivity
a) UserId: int(10)
b) FriendId: int(10)
7.3.3. IndividualPlanTable
a)
b)
c)
d)
It has following attributes and data types:
SportType: varchar(20)
Date: date
Time: varchar(11)
UserId(Foreign key): int(11)
7.3.4. GroupPlanTable
It has following attributes and data types:
a) Sport: varchar(20)
b) Date: date
c) Time: varchar(10)
d) GroupPlanOwner(Foreign key): int(10)
7.3.5. NotificationTable
a)
b)
c)
d)
e)
f)
It has following attributes and data types:
NoteId: int(10)
NoteFrom: int(10)
NoteTo: int(10)
NoteType: int(1)
TypeStatus: int(1)
GroupPlanId: mediumint(10)
7.3.6. IndividualPlanTable
e)
f)
g)
h)
It has following attributes and data types:
SportType: varchar(20)
Date: date
Time: varchar(11)
UserId(Foreign key): int(11)
7.4. Data Definition Language (DDL):
8
MACtivity
1: For creating UserTable Relation:
 create table
UserTable ( _id primary key auto increment, fullname
varchar(20) not null, password varchar(20) not null, email varchar(20) not
null);
2: For creating Individual Plan Relation:
 create table PlanTable (Sport varchar( 20 )character set utf8 collate
utf8_unicode_ci not null ,Date date not null, Time time not null, Id mediumint(
10 )not null);
7.5. Data Manipulation Language (DML):
1. For logging in:
 SELECT fullname, password FROM 'UserTable' WHERE
'[email protected]';
EmailAdd=
2: For registering a user:

INSERT INTO 'UserTable '(`Id` ,`FirstName` ,`LastName` ,`UserName`
,`Password` ,`Email`) VALUES (1, 'Hardik', 'Shah', 'hbs1966', 'abcde',
'[email protected]');
3: For finding an Id of a user:
 SELECT Id from UserTable where EmailAdd="[email protected]";
4: For scheduling an activity:

INSERT INTO `PlanTable` (`Sport` ,`Date`
('Basketball', '2012-02-27', '18:00:00', 'Id');
,`Time`
,`Id`)
VALUES
5: For seeing an activity:

SELECT * FROM `PlanTable` WHERE Time='18:00:00' and Date='2012-0601' and Sport='BasketBall';
6: For getting the value of number of people coming at an activity:
SELECT COUNT(*) FROM 'PlanTable' WHERE Time='18:00:00' and Date='201206-01' and Sport='BasketBall';
9
MACtivity
8. Iteration 1
8.1. Use Cases
8.1.1. Registration
Name: Registering for the App
Scope: Maverick Activity Center
Level: User goal
Primary Actor: Student, Faculty, Staff or Guests
Shareholders and Interests:
1. User: Wants to register for the app, to use its scheduling feature.
2. Administrator: Wants to manage system and data of the users in an efficient
and reliable manner in the database.
Precondition: User has access to an Android phone and internet connectivity
Success Guarantee: User registers without any hassle
Main success scenario:
1. User clicks on “Register” button
2. User inputs the Full Name and Email Id.
3. An email containing a randomly generated password is sent to the entered
email Id.
Alternate Scenarios:
1. The user enters an email id already registered with the app, the user is
prompted to enter a new email Id.
Extensions:
Database crashes:
Administrator performs troubleshooting
Restarts the system to original state
Frequency of occurrence: Almost continuous
10
MACtivity
8.1.2. Login
Name: Login for the App
Scope: Maverick Activity Center
Level: User goal
Primary Actor: Student, Faculty, Staff or Guests
Shareholders and Interests:
1. User: Wants to login to the app, to use its scheduling feature.
2. Administrator: Wants to manage system and data of the users in an
efficient and reliable manner in the database.
Precondition: User has access to an Android phone and internet connectivity,
and is registered to the application previously.
Success Guarantee: User logins to the application without any hassle
Main success scenario:
1. User inputs the registered email Id and Password.
2. User clicks on “Login” button
3. User is logged into the application and is navigated to the home page.
Alternate Scenarios:
1. The user enters an email id of invalid format; the user is prompted to enter
a valid email Id.
2. The user enters an Email Id and Password, which does not match the
database entry. User is prompted to enter the details again.
3. The user clicks on login without entering any details in the input fields,
user is prompted to enter the details first and then click on login.
Extensions:
Database crashes:
Administrator performs troubleshooting.Restarts the system to original state
Frequency of occurrence: Almost continuous
11
MACtivity
8.1.3. Plan
8.1.3.1.
Individual plan
Name: Planning on individual workout/sport
Scope: Maverick Activity Center
Level: User goal
Primary Actor: Student, Faculty, Staff or Guests
Shareholders and Interests:
1. User: User selects a particular sport/workout plan, so that it is updated and
displayed to other users.
2. Administrator: Manages the data of different users.
Precondition: User has access to an Android phone and internet connectivity and
user is registered for the app.
Success Guarantee: User successfully schedules for the sport and its effectively
updated on the calendar.
Main success scenario:
1. User selects the sport, selects the date, and the time slot.
2. User selects "Individual Plan" .
3. After selecting all, it gets updated in the database and displayed effectively on
the Calendar.
Extensions:
Database crashes:
Administrator performs troubleshooting
Performs restoring to a Consistent State
Frequency of occurrence: Almost continuous
12
MACtivity
8.2. Detailed System Design
8.2.1. Registration
The registration function provides the user the functionality of registering to the
application. It also handles the constraint of maintaining unique login information for
each user. This is mapped to the requirement R1 in the Inception Revision
Documentation (available here).
Classification
This module includes the components required to register a user to the
system. It includes the following
 RegistrationActivity.java in the com.mactivity.activities package
 registration_screen.xml in the layout folder of resources(res)
 RegistrationFunctions.java in the com.macitivity.database package.
Definition
This module registers the user to the application and associates him with
unique credentials to log into the application.
Responsibilities
The module includes the following functionalities
 Checks if the user’s Email Id provided while registering is unique throughout
the application. This ensures that the each user has unique login information,
necessary to log into application.
 After a successful registration, the password is sent to the registered email Id.
This validates the existence of the registered email Id.
.
Constraints
The user should have an email Id in order to register him/her into the
application.
Composition
The registration_screen.xml gives the layout of the registration screen, where
the user gives details like Name and email Id required for registering to the
application. The details from this xml are then accessed in the RegistrationActivity
class which makes all the necessary checks and registers the user into the
application.
Interaction
This module collaborates with the following modules:
 Validation Helper (ValidationHelper.java) which validates the user inputs.
 Random Password Helper (RandomPasswordHelper.java), which generates a
random password for a user.
13
MACtivity



Encryption Helper(EncryptionHelper.java) that encrypts the passwords for
protection
Mail Helper (MailHelper.java), sends the mail to the given email Id with the
randomly generated password.
Registration database Functions (RegistrationFunctions.java) are handled by
another class from where the database calls are made.
Resources
The registration module requires a centralized database, where the details of
the registered users can be maintained.
Interfaces/Exports
N.A
8.2.2. Login
The login module provides a means for the user to login to the application.
This is mapped to the requirement R2 for the Login Function and R17 for the Forgot
Password functions the Inception Revision Documentation (available here).
Classification
This module includes the components required to login a user to the system.
It includes the following
 LoginActivity.java in the com.mactivity.activities package.
14
MACtivity


main.xml in the layout folder of resources(res).
LoginFunctions.java in the com.macitivity.database package.
Definition
This module validates the credentials of a user and logs him/her into the
application.
Responsibilities
The module includes the following functionalities
 Validates if the user provided email Id and password combination match.
 User is logged into the application if the credentials match, else the user is
asked to re-enter the details in order to login.
 Resets the users password, if the user has forgotten his/her password
Constraints
The user should have registered to the application using a valid email Id and
password, and should use the same to login to the application.
Composition
The main.xml gives the layout of the login screen, where the user provides the
email id and password with which he is registered to the application. The details from
this xml are then accessed in the LoginActivity class which makes all the necessary
validations on the given email Id and password to let the user login to the application.
Interaction
This module collaborates with the following modules:
 Validation Helper (ValidationHelper.java) which validates the user inputs.
 Encryption Helper(EncryptionHelper.java) that encrypts the passwords.
 Login database Functions (LoginFunctions.java) are handled by another class
from where the database calls are made.
 Home Activity, on successful login, the user is logged into the application and
is navigated to the Home module (home_screen.xml and HomeActivity.java).
 Forgot Password module (forgotpassword.xml, ForgotPasswordActivity.java
and ForgotPasswordFunctions.java), where the user can reset his password.
Resources
The Login module requires a centralized database, where the details of the
registered users can be maintained.
Interfaces/Exports
N.A
15
MACtivity
8.2.3. Plan
8.2.3.1.
Individual Plan
The plan activity module allows users to plan an individual activity by sport
type, date, and time or invite friends to a group activity that he/she creates. Also,
users can obtain population of a specific sport at certain date and time by viewing
the time table in this module. This is mapped to the requirement R7, R8, R9, R10,
R11, and R13 in the Inception Revision Documentation.
Classification
This module includes the components required to create an activity by sport
type, date and time.
 PlanEventActivity.java in the com.mactivity.activities package
 picktype.xml in the layout folder of resources(res)
 pickdate.xml in the layout folder of resources(res)
 picktime.xml in the layout folder of resources(res)
 confirmation.xml in the layout folder of resources(res)
 invitefriend.xml in the layout folder of resources(res)
Definition
This module helps user to create individual and group activities in MAC
Responsibilities
The module includes the following functionalities
 Check if the date is valid.
 Check if the time is valid.
 Check if there is conflict plan with the selected date and time
16
MACtivity


show total number of people attending
show number of group member accepts the invitation
Constraints
Cannot show the name or email address of the members whom has accepted
the invitation
Number is an estimation based on the statistic collected by the database of
our project.
Composition
The picktype.xml, pickdate.xml, and picktime.xml prompt the user to select the
sport type, date, and time that he/she wants to plan on. The details from these xmls
are collected and showed in confirmation.xml. From Confirmation.xml page, user can
choose between making current plan as an individual plan or a group plan. If
individual plan is chosen, PlanEventActivity will take all the input and pass it to the
database manager and insert the new plan into database. When group plan is
chosen, user is prompted to pick friends from friend list to send invitations. After the
list of invited friends are confirm, PlanEventActivity will pass the input to the
database manager and insert the new plan into database. Then send out invitation to
the invited members. Moreover, PlanEventActivity will handle exception checking,
validation of date and time, conflict plan checking while each parameter is being
chosen.
Interaction
This module collaborates with the following modules:
 Constants.java which stores constants that needed by this module
 Messages.java which stores toast messages, error messages, log messages
that needed by this module
 Plan activity database functions (PlanAcitivtyFunctions.java) are handled by
another class from where the database calls are made.
Resources
The plan activity module requires a centralized database, where the details of
the created plans, registered users can be maintained.
Interfaces/Exports
N.A
17
MACtivity
18
MACtivity
9. Iteration 2
As discussed in section 4 of this document, we had planned 3 parts to implement
in iteration 2.
1. Group Plan
2. Add Friends
3. Notification
But unfortunately we fell behind at some important points in iteration 1. So we
pushed them to iteration 2. For example, in iteration 1, we used SQLite database for
temporary purpose. But to fulfill the requirement of a centralized server for our app,
we switched to MySQL DB in iteration 2 which required lots of efforts in changing
code.
Also individual planning was not working perfectly in iteration 1. So, we had to fix
that in iteration 2 and push group plan for next iteration.
However, we successfully implemented Friend List and Notification Page features
as planned for iteration 2.
We also fixed some other important issues in iteration 2. For example, we made
the validity of input fields more robust in login page and used SharedPreference to
share common data among different activities.
9.1. Use Cases
9.1.1. Group Plan
Name: Planning on Group Sport plan
Scope: Maverick Activity Center
Level: User goal
Primary Actor: Student, Faculty, Staff or Guests.
Shareholders and Interests:
1. User: User wants to plan a group activity for a particular sport
2. Administrator: Manages the data of different users.
Precondition: User has access to an Android phone and Internet connectivity and
user is registered for the app.
Success Guarantee: Initiator successfully schedules for the sport and its effectively
updated on the calendar and also invites his/her mates for the scheduled sport
activity.
19
MACtivity
Main success scenario:
1. User selects the sport, selects the date, and the time slot
2. User selects "Group Plan".
3. After selecting all, it gets updated in the database and displayed effectively on
the Calendar.
4. He/She invites his/her friends for the activity.
5. Receives the response from the buddies.
Extensions:
Database crashes:
Administrator performs troubleshooting
Performs restoring of the database to a Consistent State
Frequency of occurrence: Almost continuous
9.1.2. Add Friends
Name: Add User as a Friend
Scope: Maverick Activity Center
Level: User goal
Primary Actor: Student, Faculty, Staff or Guests
Shareholders and Interests:
1. User: Wants to add a user as a friend to use its scheduling feature.
2. Administrator: Wants to manage system and data of the users in an efficient
and reliable manner in the database.
Precondition:
1. User has access to an Android phone and internet connectivity
2. User is already registered with the app
Success Guarantee: User sends a friend request without any hassle
Main success scenario:
1. User inputs the email of the friend who he wants to add
2. After clicking Search, entered emails' details is retrieved and on clicking the
detail friend request is successfully placed.
Extensions:
Database crashes:
Administrator performs troubleshooting
Restarts the system to original state
Frequency of occurrence: Almost continuous
20
MACtivity
9.1.3. Notification
Name: Notifications for a particular user - For viewing, accepting and rejecting
requests. Also, indicate if there is a clash with the current group plan request with an
already existing plan.
Scope: Maverick Activity Center
Level: User goals.
Primary Actor: Student, Faculty, Staff or Guests.
Shareholders and Interests:
1. User: User wants to view various requests for like Group Plans and Friend
Requests. User should be able to Accept\Reject those requests.
2. Initiator: User who initiated the Group Plan or Friend request should be able
to view replies from different users on each request.
Precondition: User has access to an Android phone and Internet connectivity. User
is registered in the system.
Success Guarantee: Initiator schedules a plan for a sport on a particular day at a
particular time and invites some of his friends\sends a friend request. For a group
plan request, the friends of the initiator can view the request and on clicking them
moves to another screen with the details. If the user accepts/rejects the request
there, the initiator should be able to view the reply. For a Friend Request, he moves
to new screen with Name-Email Id and can accept\reject the request. The user who
initiated the friend request should be able to view the reply from the user.
Main success scenario:
1. User views a "Group Plan request" on his dashboard.
2. User views the sport, selects the date, and the time slot.
3. User accepts or rejects the plan.
4. The initiator should be able to view the responses from different users.
1.
2.
3.
4.
User views a “Friend request" on his dashboard.
User views the Name and Email request.
User accepts or rejects the plan.
The initiator should be able to view the responses from the user.
1. User views a "Group Plan request" on his dashboard.
2. User views the sport, selects the date, and the time slot.
3. User should view a message if there is an already existing plan.
4. If there is a group plan he has made at the same time-date, he should not
be able to accept the plan. If there is an individual or an accepted group plan
at the same time, on accepting this plan should be viewed in the schedule on
the dashboard.
21
MACtivity
Extensions:
Database crashes:
Administrator performs troubleshooting
Performs restoring of the database to a Consistent State
Frequency of occurrence: Almost continuous
9.2. Detailed System Design
9.2.1. Group Plan
Classification:
Planning activity module includes com.mactivity.activities.PlanActivity.java,
com.mactivity.database.PlanActivityFunction.java, res.layout.picktype.xml,
res.layout.confirmation.xml, res.layout.doneplan.xml, res.layout.picktime.xml,
res.layout.pickdate.xml
Definition:
Planning activity module is designed for allowing user to plan an activity by
specifying its type, date and time.
Responsibilities:
This module is responsible for prompting the user to creating a plan, which is
the major function of the application. In this module, the user should be guided to
pick the corresponding sport type, date and time to create a plan. Also the user can
choose from individual plan and group plan.
Constraints:
Currently, only individual plan will work. Also, withdrawing data from database
for display total number of attendants for a certain sport at a specific time is not
working either.
Composition:
picktype.xml shows all sport types that are provided by the MAC, user is
asked to click on one of time, which will bring up the date picker dialog. On the date
picker dialog, user selects the appropriate date and he/she will be directed to the
picktime.xml to select a time slot. After the all the information is selected, the user is
asked to choose the type of the plan, which is either individual or group. Finally, the
new inserted plan will be displayed as a table format.
22
MACtivity
Uses/Interactions:
The module will be connected to the database to store any plan activities that
are created by the user. Also, the main table module is connected to this module.
After an activity has been created, the module is connected back to the main table
module.
Resources:
Database is required for this module
Interface/Export:
This module will insert an entry which includes three fields: type, date and
time into the database
23
MACtivity
9.2.2. Add Friends
The Add Friend Module function provides the user the functionality of
increasing his contact list by adding his/her friends who are active users of the app
so as to be able to schedule an group activity amongst his friends . This is mapped
to the requirement R5 in the Inception Revision Documentation (available here).
Classification
This module includes the components required to request an existing user to
add as a friend. It includes the following
 AddFriendActivity.java in the com.mactivity.activities package
 add_friend.xml in the layout_port folder of resources(res)
Definition
This module sends the user a Add Friend request and the requests goes to the
user via a notification, wherein he can accept or reject the request.
Responsibilities
The module includes the following functionalities
 User should be able to find the user by giving the email-id of the friend.
 Checks if the user tries to add already friend, if yes gives an error message.
 Checks if the request has been sent but yet it has to be Accepted/Rejected, it
should notify accordingly.
 After the request is sent the user should be able to accept/reject the request.
Constraints
The user should know friends email Id in order to find and send request to the
friend.
Composition
The add_friend.xml gives the layout of the Add Friend screen, where the user
gives details like email Id required for searching a friend and send a request to a
friend. The details from this xml are then accessed in the AddFriendActivity class
which makes all the necessary checks and sends notification to the requested user.
Interaction
This module collaborates with the following modules:
 Add Friend database Functions (AddFriendActivityFunctions.java)
handled by another class from where the database calls are made.
are
Resources
The Add Friend module requires a centralized database, where the details of
the friends can be maintained.
Interfaces/Exports
N.A
24
MACtivity
9.2.3. Notification
Notifications in the MACtivity app helps the user track his own and related
operations. To view the Notifications related to the user, he should click on the
second icon from the left in the MACtivity app. On clicking, a list of items appear
which are the Notifications specific to that particular user. Notifications can be of two
kinds –
1. Friend Request related – Requests, Messages on Accept\Reject
If another user wants to add this particular user as a friend, he will go
into the Add Friend, search the user and send him a request to add him as a
friend. This request appears on Notifications board of the user. On clicking he
will be lead to another screen where he could Accept\Reject the request by
clicking on respective buttons. That is posted as a Notification on the user
who sent the request as “Friend Request accepted\rejected”.
2. Group Plan related - Requests, Messages on Accept\Reject
If a particular user wants to create a Group Plan and invite his friends,
he goes into the Plan, creates the plan by selecting Sport, Date and Time and
in the end invites his friends. The invited friends will get a Notification on their
Notifications list that “Group Plan request from”. On clicking the request the
user can view in another screen the details of the plan and could
Accept\Reject on clicking the respective buttons. The creator of the plan will
get a Notification as which users accepted or rejected the plan.
Classification
This module includes the components required for Notifications in the system.
It includes the following
25
MACtivity




The com.mactivity.activities package includes - NotificationActivity.java,
NotificationFriendActivity.java and NotificationGroupPlanActivity.java.
The com.mactivity.database package - NotificationActivityFunctions.java
notification.xml and notificationpost.xml in the layout folder of resources(res)
PHP scripts – notifications_script.php, delete_notification_script.php,
accept_groupplan_script.php,fetch_group_plan_script.php,accept_friend_scri
pt.php,add_friend_script.php,fetch_user_details_script.php,delete_old_individ
ualplan_acceptGP.php,reject_oldaccepted_groupplan.php,san_accepted_gro
up_conflict.php
Definition
This module is focused in managing the Notifications of different users of the
application and also the actions they could take on each of the Notification.
Responsibilities
The module includes the following functionalities
 On making a group plan or sending a friend request, the user who is sent the
request should be able to view the request on his notifications list.
 The user should be able move to a new screen to view details of the request
and be able accept or reject the request.
 On accepting\rejecting, the user who initiated the request should be able to
view the action done by a particular user on a particular request.
 The notifications of the past should not appear.
 The friend request accepted\rejected message on the initiating user should be
deleted on viewing them by clicking.
Constraints
The user should be able to view Notifications on clicking the second icon to
left. On clicking on a group plan\ friend request user should be led to another screen
where Accept and Reject buttons could be view, on clicking of which that particular
action should be taken on that particular request.
Composition
The notification.xml gives the layout of the list of notifications on screen,
where the user can view messages like –“Friend Request from”,” is your friend”,”
rejected your friend request”, ”Group Plan request from”, “: is in for a Group Plan”
and “:is not in for a Group Plan”. The details from this xml are then accessed in the
NotificationActivity class which fetches the user related Notifications.
The notificationpost.xml gives the layout where the details of a particular
notifications can be viewed. The user can view details like –“Message From”, ”Email
Id”,” Sport”, ”Date” and “Time”. There are also buttons like Accept, Reject and OK,
these buttons provide the actions which user can take on that Notification. The
details from this xml are then accessed in the NotificationFriendActivity and
NotificationGroupPlanActivity class which fetches the user details of a particular
Notification.
Also the Notifications mechanism should manage and show alerts when there
are plans clashing with the group plan request coming in. They notifications Should not allow a user to accept a group plan when he has made a particular
group plan at the same date and time.
26
MACtivity


Should be able to accept a group plan at the same date and time for which he
has made an individual plan
He should be able to accept another group plan instead of a group plan he
has already accepted.
Interaction
This module collaborates with the following modules:
Notifications database Functions (NotificationActivityFunctions.java) are handled by
another class from where the database calls are made.
The Notifications interact with these tables in the MACtivity database User–For names of the Users and their Email Ids.
GroupPlan – For accessing Group Plans details.
Notifications - Has all the Notifications in the system currently.
IndividualPlan - To check if an Individual Plan which clashes at the same datetime as a group plan request.
Friends – Adds 2 users as friends on accepting a friend request.
Resources
The Notifications module requires a centralized database, where the details of
the Notifications can be stored. Currently
Interfaces/Exports
N.A
27
MACtivity
10. Iteration 3
As discussed in section 4 of this document, we had planned 3 parts to implement
in iteration 3.
1. Statistics Chart
2. User Profile Page
3. User Dashboard
We were successful to implement all 3 parts in this iteration. Hence we can claim
that, we implemented all functional requirements of our app. After iteration 3, we can
work on improving current features and make the app more user-friendly.
Here we discussed in details about what we did for iteration 3.
10.1. Use Cases
10.1.1.
10.1.1.1.
Login Module
Forgot Password
Name: Password Reset for the App
Scope: Maverick Activity Center
Level: User goal
Primary Actor: Student, Faculty, Staff or Guests
Shareholders and Interests:
1. User: User has forgotten the password used to login to the application, and
wants to reset it.
2. Administrator: Wants to manage system and data of the users in an efficient
and reliable manner in the database.
Precondition: User has access to an Android phone and internet connectivity, and
is registered successfully to the application previously.
Success Guarantee: User can reset the password to the application successfully.
Main success scenario:
1. User clicks on the Forgot Password link in the Login screen.
2. User inputs the Email Id with which he/she had previously registered to the
application.
3. The password is reset with the new randomly generated password and an
email is sent to the input email Id.
Alternate Scenarios:
1. The user enters an email id of invalid format; the user is prompted to enter a
valid format of email Id.
28
MACtivity
2. The user enters an Email Id which does is not previously registered with the
application. User is prompted to enter the registered email Id.
3. Clicking on the back button will navigate the user to the Home Screen.
Extensions:
Database crashes:
Administrator performs troubleshooting
Restarts the system to original state
Frequency of occurrence: Almost continuous
10.1.2.
Profile Module
The profile module displays the details user’s Login information. It also
provides the functionalities of Logout and Change password.
10.1.2.1.
Change Password
Name: Change Login Password to the App
Scope: Maverick Activity Center
Level: User goal
Primary Actor: Student, Faculty, Staff or Guests
Shareholders and Interests:
1. User: User wants to change the password which he/she uses to login to the
application.
2. Administrator: Wants to manage system and data of the users in an efficient
and reliable manner in the database.
Precondition: User has access to an Android phone, internet connectivity and is
logged into the app, displaying the home screen.
Success Guarantee: The user is able to change the login password to the app
successfully.
Main success scenario:
1. User clicks on the Profile icon.
2. User is navigated to the Profile tab of the profile page, which displays the user
information that includes Full Name and Email Id.
3. User clicks on the Change Password tab.
4. User is asked to input Old Password, and then a new password along with
confirming the password.
29
MACtivity
5. A message is displayed to the user that the password is successfully
changed.
Alternate Scenarios:
1. The old password entered by the User, does not match the database entry for
the existing password. Message is displayed that the old password is
incorrect and is asked to input the details again.
2. The new password and the confirm password entered by the User, does not
match each other. Message is displayed that the new password and confirm
password do not match and is asked to input the details again.
3. The user leaves some field blank. User is prompted to enter all the fields.
4. Clicking on the back button will navigate the user to the Home Screen.
Extensions:
Database crashes:
Administrator performs troubleshooting
Restarts the system to original state
Frequency of occurrence: Almost continuous
10.1.2.2.
Profile
Name: User profile in the App
Scope: Maverick Activity Center
Level: User goal
Primary Actor: Student, Faculty, Staff or Guests
Shareholders and Interests:
1. User: Wants to look at his profile, which includes the login details (Email Id
and Full Name).
2. Administrator: Wants to manage system and data of the users in an efficient
and reliable manner in the database.
Precondition: User has access to an Android phone, internet connectivity and is
logged into the app, displaying the home screen.
Success Guarantee: Profile details are shown to the user and user can change his
password.
Main success scenario:
1. User clicks on the Profile icon.
2. User is navigated to the Profile tab of the profile page, which displays the user
information that includes Full Name and Email Id.
30
MACtivity
Alternate Scenarios:
1. Clicking on the back button will navigate the user to the Home Screen.
Extensions:
Database crashes:
Administrator performs troubleshooting
Restarts the system to original state
Frequency of occurrence: Almost continuous
10.1.2.3.
Logout
Name: Logout of the App
Scope: Maverick Activity Center
Level: User goal
Primary Actor: Student, Faculty, Staff or Guests
Shareholders and Interests:
1. User: User wants to Logout of the application.
2. Administrator: Wants to manage system and data of the users in an efficient
and reliable manner in the database.
Precondition: User has access to an Android phone, internet connectivity and is
logged into the app, displaying the home screen.
Success Guarantee: The user is able to Logout of the application without any
hassle.
Main success scenario:
1. User clicks on the Profile icon.
2. User is navigated to the Profile tab of the profile page, which displays the user
information that includes Full Name and Email Id.
3. User clicks on the Logout Button.
4. The user is logged out of the application.
Alternate Scenarios:
1. Clicking on the back button will navigate the user to the Home Screen.
Extensions:
Database crashes:
31
MACtivity
Administrator performs troubleshooting
Restarts the system to original state
Frequency of occurrence: Almost continuous
10.1.3.
DashBoard
Name: Dashboard for a particular user - For viewing all plans associated with users
from the current day.
Scope: Maverick Activity Center
Level: User goals.
Primary Actor: Student, Faculty, Staff or Guests
Shareholders and Interests:
1. User: User wants to view various activities like Group Plans or Individual
Plans he has made along with the group plans he has accepted to be part of.
Precondition: User has access to an Android phone with Internet connectivity. User
is registered in the system.
Success Guarantee: On logging into the app or opening the app, the user should be
able to view all of his activities scheduled from the current day to future.
Main success scenario:
1. User logs in or opens the app to view the dashboard.
2. If there are activities planned for him, he should be able to see them.
Extensions:
Database crashes:
Administrator performs troubleshooting
Performs restoring of the database to a Consistent State
Frequency of occurrence: Almost continuous
10.1.4.
10.1.4.1.
Chart Module
Statistics Chart
Name: Show Statistics to Users
Scope: Maverick Activity Center
32
MACtivity
Level: User goal
Primary Actor: Student, Faculty, Staff or Guests
Shareholders and Interests:
1. User: User wants to view statistics of other people using MAC facilities.
2. Administrator: Wants to manage system and statistics of the users in an
efficient and reliable manner in the database.
Precondition: User has access to an Android phone and internet connectivity, and
is registered successfully to the application previously.
Success Guarantee: User can view the statistics of different games successfully.
Main success scenario:
1. User clicks charts icon in the Home screen.
2. User selects a particular game from list and clicks submit button.
3. An interactive pie chart is loaded on screen showing average number of
people present on different days for that particular game.
Alternate Scenarios:
1. Clicking on the back button will navigate the user to the Home Screen.
Extensions:
Database crashes:
Administrator performs troubleshooting
Restarts the system to original state
Frequency of occurrence: Almost continuous
10.2. Detailed design
10.2.1.
10.2.1.1.
Login Module
Forgot Password
This module includes the components required to login a user to the system. It
includes the following
 LoginActivity.java in the com.mactivity.activities package.
 main.xml in the layout folder of resources(res).
 LoginFunctions.java in the com.macitivity.database package.
Definition
33
MACtivity
This module validates the credentials of a user and logs him/her into the
application.
Responsibilities
The module includes the following functionalities
 Validates if the user provided email Id and password combination match.
 User is logged into the application if the credentials match, else the user is
asked to re-enter the details in order to login.
 Resets the users password, if the user has forgotten his/her password
Constraints
The user should have registered to the application using a valid email Id and
password, and should use the same to login to the application.
Composition
The main.xml gives the layout of the login screen, where the user provides the
email id and password with which he is registered to the application. The details from
this xml are then accessed in the LoginActivity class which makes all the necessary
validations on the given email Id and password to let the user login to the application.
Interaction
This module collaborates with the following modules:
 Validation Helper (ValidationHelper.java) which validates the user inputs.
 Encryption Helper(EncryptionHelper.java) that encrypts the passwords.
 Login database Functions (LoginFunctions.java) are handled by another class
from where the database calls are made.
 Home Activity, on successful login, the user is logged into the application and
is navigated to the Home module (home_screen.xml and HomeActivity.java).
 Forgot Password module (forgotpassword.xml, ForgotPasswordActivity.java
and ForgotPasswordFunctions.java), where the user can reset his password.
Resources
The Login module requires a centralized database, where the details of the
registered users can be maintained.
Interfaces/Exports
N.A
34
MACtivity
10.2.2.
Profile with Change Passowrd
The Profile module provides a means for the user to browse his Login details
and change the password used for application login. This is mapped to the
requirement R17 and R18 in the Inception Revision Documentation (available here).
Classification
This module includes the components required to login a user to the system.
It includes the following
 ProfileTabActivity.java, ProfileActivity.java and ChangePasswordActivity.java
in the com.mactivity.activities package.
 profile.xml, changepassword.xml and profilemain.xml in the layout folder of
resources (res).
 tab.xml in the drawable folder of the resources(res)
 ChangePasswordFunction.java in the com.macitivity.database package.
Definition
This module allows the user to view his profile details, which includes his full
name and email address with which he logs into the application. It also gives the
user an option to change the password.
Responsibilities
The module includes the following functionalities
 Display the user details, includes full name and email Id used for login.
 Allow the user to Logout of the application.
 Allow the user to change his password.
35
MACtivity
Constraints
The user should have logged into the application with a valid email id and
password.
Composition
The Profile page is split into two tabs.
 User details
 Change Password
The profile.xml gives the layout of the Profile screen; the tab.xml gives the details
of the tab that needs to be included in the Profile Page. The details from this xml are
then accessed in the ProfileTabActivity class which includes the functionalities to
handle
the
tab
initialization
process.
The
ProfileActivity.java
and
ChangePasswordActivity.java handle the display of user profile details and password
change respectively.
Interaction
This module collaborates with the following modules:
 Profile Activity (ProfileActivity.java) which handles the actions on the Profile
tab of the profile page, which includes displaying of the user profile details and
logout functionality.
 Change Password Activity (ChangePasswordActivity.java) that handles the
change password tab and its actions.
 Validation Helper (ValidationHelper.java) that validates the strength of the
new password entered in the change Password tab of the Profile.
 Change password (ForgotPasswordFunctions) which contains methods to
reset the password with the new password entered by the user.
Resources
The Profile module requires a centralized database, where the details of the
registered users can be retrieved.
Interfaces/Exports
N.A
36
MACtivity
37
MACtivity
10.2.3.
DashBoard
The Dashboard provides the user the list of all the activities a particular user
is part of. Dashboard is the default view of the app. On logging in Dashboard is
displayed. Each item in the list is an activity for the user. Dashboard has 4 columns –
Type – Type column in short describes what sort of an activity. It can be of 3
types – Individual Plan (I), Group Plan made by the user (MyGP) and part of a
group plan made by another user (GPOthr) ,the current user has accepted to
be part of.
Sport – The sport described in the activity
Date – The date on which the activity has been scheduled with the day of the
activity.
Time – Time on that particular date when the activity is scheduled.
Classification
This module includes the components required to bring up the dashboard. It
includes the following
 HomeActivity.java in the com.mactivity.activities package.
 HomeActivityFunctions.java in the com.mactivity.database package.
 home_screen.xml in the layout folder of resources(res).
 PHP scripts - delete_automatic_script.php, delete_auto_groupplan_script.php,
delete_auto_individualplan_script.php,dashboard_othergroupplan_script.php,
dashboard_groupplan_script.php and dashboard_individualplan_script.php
Definition
This module displays all the activities associated with the user at that
particular point in time. Dashboard displays all the activities associated with the user
for the current date and the future.
Responsibilities
The module includes the following functionalities
 On logging in, collects the user specific activities and displays it on the home
screen.
 On creating or accepting an activity it should be displayed in the Dashboard.
.
Constraints
The user should have registered and logged into the system. The user must
have activities associated with him to be displayed on the dashboard, else a empty
table is displayed.
Composition
The home_screen.xml gives the layout of the dashboard screen, where there
is a table with columns Type, Sport, Date (Day) and Time. User cannot perform any
operations on the dashboard screen but can just view the list of activities associated
with him.
Interaction
This module collaborates with the following modules:
38
MACtivity


Home activity database functions (HomeActivityFunctions.java) are handled
by another class from where the database calls are made.
The Dashboard interacts with following tables in MACtivity database GroupPlan – For getting Group Plans which user had made himself.
Notifications - Has all the Group Plans which the user has accepted.
IndividualPlan - Individual Plan which the user has created.
Resources
The dashboard module requires a centralized database, where the details of
the all the activities are stored.
Interfaces/Exports
N.A
10.2.4.
Chart
The charts function helps the user to know approximate statistics of people
using different facilities of MAC. It shows average number of people present at MAC
for a particular day and a particular sport using pie chart. Data is provided by MAC
staff. This module is mapped to the requirement R16 in the Inception Revision
Documentation (available here).
Classification
This module includes the components required to show statistics on screen
using data fetched from database. It includes the following
 ChartsActivity.java in the com.mactivity.activities package
 chartwebview.xml in the layout folder of resources(res)
 sport_type.html in /charts directory of Omega server
 piechart.php in /charts directory of omega server
Definition
This module shows average statistics of people using MAC at different days
for selected sport.
Responsibilities
The module includes the following functionality
 Shows user option to select a particular game.
 Based on the selection, fetches data from database and loads an interactive
pie chart on screen using the data
Constraints
The user should be logged in to access charts feature.
Composition
The chartwebview.xml gives the layout of webview of the game type selection
screen, where the user selects a particular game. The selection is passed to a PHP
script which is responsible to fetch data for that game. Next a javascript is used to
plot pie chart using Google Chart Tools.
39
MACtivity
Interaction
Charts module uses the ChartData table in database. It fetches data for 7
days of a particular game.
Resources
The charts module requires a centralized database, where the data of the
MAC users can be maintained.
Interfaces/Exports
N.A
Sequence Diagram
40
MACtivity
11. Requirement Traceability
Following are the high level requirements that we specified in Design
specification Documents and the table shows what requirements are met.
High Level Requirements:
R1: The system should allow user to register an account with the system.
R2: The system should allow user to Login with a valid user name and password.
R3: The system should allow user to view his dashboard once he logs into the App.
R4: The system should allow user to click on the Friend tab to see all his friends
R5: The system should allow user to add friends by their user name
R6: The system should allow user to delete friends from friend list
R7: The system should allow user to choose a specific sport
R8: The system should allow user to choose a specific time slot after choosing the
date
R9: The system should allow user to add his own attendance at a time slot after
choosing a time slot
R10: The system should allow user to view total number of people attending at that
time slot
R11: The system should allow user to the attending number of people in a group
invitation at the time slot
R12: The system should allow user to show all his notifications on the notification tab
R13: The system should allow user to invite friends to attend a sport activity at a
specific date and time
R14: The system should allow user to accept invitation
R15: The system should allow user to decline invitation
R16: The system should show user the statistic in the chart tab
R17: The system should allow user to update his profile.
R18: The system should allow user to log out.
41
MACtivity
Requirement Traceability Table:
Registe
r
Activity
Requiremen
t
Identifiers
R1
R2
R3
R4
R5
R6
R7
R8
R9
R10
R11
R12
R13
R14
R15
R16
R17
R18
Login
Activit
y
PlanEven
t
Activity
Notificatio
n
Activity
Add
Friend
Activit
y
Chart
Activit
y
Profile
Activit
y
Home
Activit
y
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Only the requirement R6 from the requirement specification is eliminated as now we
so no reason to have this requirement present. Also, there is a slight tweak in the
requirement R5, as in instead of username, we search by user email id , however
before the final deliverable we plan to come up with giving user the option to search
by username or user email-id.
42
MACtivity
12. Conclusion
In this document, we presented a design specification for various models
involved in our android app MACtivity, also we present various sequence diagrams
and use cases which gives a clean understanding and flow of the various activities
involved. If you have any questions, comments, feedbacks, please feel free to
contact members of team 6
Sanjay Vasudeva Iyer ([email protected])
Shwetha Narayan ([email protected])
Hardik Shah ([email protected])
Khandaker Moinur Rahman ([email protected])
Yu Xuan Zhang ([email protected])
Useful Links:
Our Wiki page: https://wiki.uta.edu/display/sp12cse5324team6/Home
Project Hosting Page: http://code.google.com/p/mactivity/
SVN Repository Location: https://mactivity.googlecode.com/svn
(>trunk>MACtivity)
Source Code Checkout for non-members:
http://code.google.com/p/mactivity/source/checkout
Sample User Id & Password:
Login Email
[email protected]
[email protected]
Password
moinur
mactivity
Special Note:
Generating charts & few other tasks may require time more than expected for
checking purposes. So, kindly be patient while testing.
43