mactivity - maverick wikis web viewthis document serves as a design specification for mactivity...
TRANSCRIPT
Department of Computer Science and Engineering The University of Texas at Arlington
MACtivityDesign Specification
Team Members:
Sanjay Vasudeva Iyer
Shwetha Narayan
Hardik Shah
Khandaker Moinur Rahman
Yu Xuan Zhang
4/29/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……………………........43
12. What’s New in MACtivity……………………………45
13. Future Enhancements………………………………46
14. Data Dictionary………………………………………46
15. Conclusion…………………………………..……….47
1
MACtivity
1. IntroductionMaking 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 OverviewMACtivity 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 the probable 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 an activity for a group● Important notifications● View various statistical data● Manage personal profile● Display schedule for a week
3. Design ConsiderationsIn 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 reserve for courts 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 MethodsAs 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 Page2. Registration Page3. Individual Plan
Iteration 2:
1. Group Plan2. Friend List 3. Notification Page
Iteration 3:
1. Statistics Chart2. User Profile Page3. 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 StrategiesIn 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 ArchitectureFor 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
The domain model gives a brief overview of how the project modules are designed. The user is the main object of the domain model. The user is associated to all the other objects like Plan (Includes Individual and Group Plan), Notification and Friends. The Plan object contains all the functionalities for the user to create a plan. It has to sub-modules Individual and Group Plan. A Notification module maintains the entire functionality of alerts to and from the user. The Friend module maintains all the users whom the user has friended.
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-remote-db/
7.3. Database LayoutsThis app uses 6 tables in database. They are as following:
7.3.1. User Table
It has following attributes and data types:
a) id(Primary key): int(10)b) fullName:varchar(50)c) email:varchar(50)d) password: varchar(50)
7.3.2. Friends Table
It has following attributes and data types:
7
MACtivity
a) UserId(Foreign Key): int(10)b) FriendId: int(10)
7.3.3. IndividualPlanTableIt has following attributes and data types:
a) SportType: varchar(20)b) Date: datec) Time: varchar(11)a) UserId(Foreign key): int(11)
7.3.4. GroupPlanTableIt has following attributes and data types
a) Sport: varchar(20)b) Date: datec) Time: varchar(10)d) GroupPlanOwner(Foreign key): int(10)
7.3.5. NotificationTableIt has following attributes and data types
a) NoteId: int(10)b) NoteFrom: int(10)c) NoteTo: int(10)d) NoteType: int(1)e) TypeStatus: int(1)f) GroupPlanId: mediumint(10)
7.3.6. ChartDataTable It has following attributes and data types
a) Id: int(4)b) Game: varchar(20)c) Mon: int(4)d) Tue: int(4)e) Wed: int(4)f) Thu: int(4)g) Fri: int(4)h) Sat: int(4)i) Sun: int(4)
7.4. Entity Relationship diagram
8
MACtivity
8. Iteration 18.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” button2. 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 troubleshootingRestarts 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” button3. 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
8.1.3. Plan
11
MACtivity
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 troubleshootingPerforms restoring to a Consistent State
Frequency of occurrence: Almost continuous
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).
12
MACtivity
ClassificationThis 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.
DefinitionThis 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..
ConstraintsThe user should have an email Id in order to register him/her into the
application.
CompositionThe 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.
InteractionThis 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. 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.
ResourcesThe registration module requires a centralized database, where the details of
the registered users can be maintained.
13
MACtivity
Interfaces/ExportsN.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).
ClassificationThis 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.
DefinitionThis module validates the credentials of a user and logs him/her into the
application.
Responsibilities The module includes the following functionalities
14
MACtivity
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
ConstraintsThe user should have registered to the application using a valid email Id and
password, and should use the same to login to the application.
CompositionThe 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.
InteractionThis 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.
ResourcesThe Login module requires a centralized database, where the details of the
registered users can be maintained.
Interfaces/ExportsN.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.
ClassificationThis 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)
DefinitionThis 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
ConstraintsCannot show the name or email address of the members whom has accepted
the invitationNumber is an estimation based on the statistic collected by the database of
our project.
CompositionThe 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.
InteractionThis 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.
ResourcesThe plan activity module requires a centralized database, where the details of
the created plans, registered users can be maintained.
Interfaces/ExportsN.A
17
MACtivity
9. Iteration 2As discussed in section 4 of this document, we had planned 3 parts to implement
in iteration 2.
1. Group Plan2. Add Friends3. 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 sport2. 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 slot2. 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 troubleshootingPerforms 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 connectivity2. 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 add2. After clicking Search, entered emails' details is retrieved and on clicking the
detail friend request is successfully placed.
Extensions:
Database crashes:Administrator performs troubleshootingRestarts 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. User views a “Friend request" on his dashboard.2. User views the Name and Email request.3. User accepts or rejects the plan.4. 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 troubleshootingPerforms 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).
ClassificationThis 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)
DefinitionThis 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.
ConstraintsThe user should know friends email Id in order to find and send request to the
friend.
CompositionThe 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.
InteractionThis module collaborates with the following modules:
Add Friend database Functions (AddFriendActivityFunctions.java) are handled by another class from where the database calls are made.
ResourcesThe Add Friend module requires a centralized database, where the details of
the friends can be maintained.
Interfaces/ExportsN.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 is the Notifications specific to that particular user. Notifications can be of two kinds –
1. Friend Request related – Requests, Messages on Accept\RejectIf 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.
ClassificationThis 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_script.php,add_friend_script.php,fetch_user_details_script.php,delete_old_individualplan_acceptGP.php,reject_oldaccepted_groupplan.php,san_accepted_group_conflict.php
DefinitionThis 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.
CompositionThe 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 date- time as a group plan request.Friends – Adds 2 users as friends on accepting a friend request.
ResourcesThe Notifications module requires a centralized database, where the details of
the Notifications can be stored. Currently
Interfaces/ExportsN.A
27
MACtivity
10. Iteration 3As discussed in section 4 of this document, we had planned 3 parts to implement
in iteration 3.
1. Statistics Chart2. User Profile Page3. 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. Login Module10.1.1.1. 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 troubleshootingRestarts 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 troubleshootingRestarts 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 troubleshootingRestarts 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 troubleshootingRestarts 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 troubleshootingPerforms restoring of the database to a Consistent State
Frequency of occurrence: Almost continuous
10.1.4. Chart Module10.1.4.1. Statistics Chart
Name: Show Statistics to Users
Scope: Maverick Activity Center
Level: User goal
32
MACtivity
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 troubleshootingRestarts the system to original state
Frequency of occurrence: Almost continuous
10.1.5 Delete Friend
Name: Deleting a friend from Contact List
Scope: Maverick Activity Center
Level: User goals.
Primary Actor: Student, Faculty, Staff or Guests
Shareholders and Interests:User: User wants to delete a particular friend from his friend list.
Precondition: User has access to an Android phone with Internet connectivity. User is registered in the system and the user he wants to delete should be his friend in the first place.
33
MACtivity
Success Guarantee: After deleting the user from his friend list, he shouldn't be able to see that friend in his friend list.
Main success scenario:1. User sees his list of friends in his contact list.2. On selecting a friend he should be given a dialog asking if he wants to delete the Friend.3. On delete, it should un-friend the selected user.
Extensions:
Database crashes:Administrator performs troubleshootingPerforms restoring of the database to a Consistent State
Frequency of occurrence: Almost continuous
10.2. Detailed design
10.2.1. Login Module10.2.1.1. 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.
DefinitionThis 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
ConstraintsThe user should have registered to the application using a valid email Id and
password, and should use the same to login to the application.
CompositionThe 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
34
MACtivity
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.
InteractionThis 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.
ResourcesThe Login module requires a centralized database, where the details of the
registered users can be maintained.
Interfaces/ExportsN.A
10.2.2. Profile with Change Password
35
MACtivity
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).
ClassificationThis 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.
DefinitionThis 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.
ConstraintsThe 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.
InteractionThis 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.
36
MACtivity
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.
ResourcesThe Profile module requires a centralized database, where the details of the
registered users can be retrieved.
Interfaces/ExportsN.A
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 activityDate – 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.
ClassificationThis 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).
38
MACtivity
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
DefinitionThis 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.
CompositionThe 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.
InteractionThis module collaborates with the following modules:
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.
ResourcesThe dashboard module requires a centralized database, where the details of
the all the activities are stored.
Interfaces/ExportsN.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/bar chart. Data is provided
39
MACtivity
by MAC staff. This module is mapped to the requirement R16 in the Inception Revision Documentation (available here).
ClassificationThis 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 /assets/chart directory chart.php in /charts directory of omega server
DefinitionThis 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 and chart type. Based on the selection, fetches data from database and loads an interactive
chart on screen using the data
ConstraintsThe user should be logged in to access charts feature.
CompositionThe chartwebview.xml gives the layout of WebView of the game type
selection screen, where the user selects a particular game and chart type. 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.
InteractionCharts module uses the ChartData table in database. It fetches data for 7 days of a particular game.
ResourcesThe charts module requires a centralized database, where the data of the
MAC users can be maintained.
Interfaces/ExportsN.A
40
MACtivity
Sequence Diagram
10.2.5. Delete Friend
The Delete Friend Module function provides the user the functionality of deleting a friend from his contact list who are active users of the app and also is his/her friend. This is mapped to the requirement R6 in the Inception Revision Documentation (available here).
ClassificationThis module includes the components required to delete a friend from friend
contact list. It includes the following DeleteFriendActivity.java in the com.mactivity.activities package delete_friend.xml in the layout_port folder of resources(res)
DefinitionThis module deletes a particular friend from the user's Friend List.
Responsibilities The module includes the following functionalities User should get the list of all his friends. On selecting a particular friend from the list, the particular should be removed
from the Friend List.Constraints
The user should be friends with the person before he wants to delete.
CompositionThe delete_friend.xml gives the layout of the Delete Friend screen. List of
user's friends are displayed to the user. On selecting a friend a dialog box prompts which confirms with the user if he wants to delete the user. On clicking delete, the user is deleted from the user's friend list.
41
MACtivity
InteractionThis module collaborates with the following modules:
Delete Friend database Functions (DeleteFriendActivityFunctions.java) are handled by another class from where the database calls are made.
ResourcesThe Delete Friend module requires a centralized database, where the details
of the friends can be maintained.
Interfaces/ExportsN.A
11. Requirement Traceability42
MACtivity
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.
Requirement Traceability Table:
Regist Login Plan Notifica Add Delete Chart Profile Home
43
MACtivity
erActivit
y
Activity
EventActivity
tionActivity
FriendActivity
Friend Activity Activit
yActivit
yActivit
y
Requirement
IdentifiersR1 XR2 XR3 XR4 XR5 XR6 XR7 XR8 XR9 XR10 XR11 XR12 XR13 XR14 XR15 XR16 XR17 XR18 X
12. What’s new in MACtivity44
MACtivity
MACtivity is a custom tailored application. It aids users to plan their activities at the Maverick Activity Centre. The idea of the application is to remove all the cumbersome details finding the activities available, planning an activity for a group, keeping track of the planned activities etc. The application lets user choose from the list of activities/sports available at the MAC at a particular time, and gives details on number of people who might be there at the same time as that of the user. The following features of the application make it stand out.
One of a kind application
● The application is tailored to help, planning activities at MAC.
Simple interface with easy navigation.
● Creating new activities is simple, requiring only a few sequential steps.● Each activity will include choosing a sport type, then the day and the time of
the day when the sport is to be played.● No typing of any sort, all the menu based options let you click your way
through the application, making it less cumbersome.
Dashboard containing the list of activities planned by the user.
● List of all the sporting activities planned by the user, including the information of the type of activity planned the user.
● The dashboard also contains the number of people who have planned an activity for the same time as the time selected by the user, giving him a fair idea about the number of people playing the sport at a given time.(The number shown considers only the people using the application)
Ability to plan an activity for a group of people.
● Playing at MAC alone or playing with a group of people, planning it is simple with just a few clicks.
● Add the people in the list of friends to organize a group activity at MAC.
Notifications on the invitations to the activities planned by others.
● Notification sent to each friend selected, who has an option to either accept or reject the request.
● The organizer gets the update on number of people who have accepted or rejected.
Statistics● Statistics on the average number of people, who might be present at any
given time at MAC.● This is the static data given by the Maverick Activity Center authorities.
13. Future Enhancements
45
MACtivity
MACtivity though complete as an application, covering all the requirements envisioned, has some scope for future enhancements which will benefit the users greatly.
Performance
The generation of charts with the static data takes a little longer than expected with the Google charts API. A better way to implement this can be included in the future.
Look and Feel
The application though has a pleasing look and feel, it has can be improved by using gestures which are available with the OS, which makes the application more appealing.
Better layout for the tables, will help the user.
Features
Dashboard can be made more interactive giving the user more information about the sport that he has chosen.
As the application is used over time, the data collected by the application about the number of users using a particular sport in the Maverick Activity Center can be used to derive and give more detailed information to the user about the frequency of usage.
User’s profile can contain more details about the history of activities used by the user.
Currently the application allows the user to select a start time, and a time slot of 1 hour is selected from the start time. Allowing the user to select an end time, will improve the usability.
14. Data DictionaryHere is a list of few words used though out the application and their meanings for
better understanding.
Word Scope/Screen MeaningIndividual Plan Confirmation Planning an activity which for just the logged in user.
Group Plan Confirmation Planning an activity for a group of people.I Dashboard Individual plan made by the user.
GPOthr Dashboard Group Plan made by other user, but is accepted by the logged in user.
MyGP Dashboard Group plan made by the logged in user.
15. Conclusion
46
MACtivity
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] Mactivity
Special Note:
Generating charts & few other tasks may require time more than expected for checking purposes. So, kindly be patient while testing.
47