MACtivity Design Specification

Size: px

Start display at page:

Download "MACtivity Design Specification"

Beverly Baldric Preston
5 years ago
Views:

1 MACtivity Design Specification Department of Computer Science and Engineering The University of Texas at Arlington Team 6 CSE 5324 Team Members: Sanjay Vasudeva Iyer Shwetha Narayan Hardik Shah Khandaker Moinur Rahman Yu Xuan Zhang

2 Table of Contents 1. Introduction 2. System Overview 3. Design Considerations 4. Development Methods 5. Architectural Strategies 6. System Architecture 7. Detailed System Design 8. Database Design 9. Improvements in Iteration Conclusion

3 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. 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. Scope: This document does not describe all design issues of our app. Rather, it focuses on design details required for the first iteration of our project. 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 Also, assigned reviewer team will be able to evaluate our design and express their opinions based on this design specification. Prerequisite Documents: Readers of this document are requested to go through Project inception documents/slides (available here) to get a better idea about what our app is and what are other preliminary details of our project. 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

4 View various statistical data Manage personal profile 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: o Our app will be available for android platform only. o MACtivity isn t an app to book a slot in MAC. It s just an aid in planning. o MACtivity doesn t show the dynamic data (current no of people) at the MAC. o 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. o This app depends on a central server to store and update data 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

5 2. User Profile Page 3. User Dashboard In this design document, we have focused on the first iteration. We developed a running system that works on android emulator with registration, login and individual planning options. 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 designed for iteration one is described in a separate document titled MACtivity_Test_Case (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.

to implement 3 of these components/modules for iteration 1. These modules are: User registration, login and individual plan.

6 6. System Architecture For simplification, we divided our system into several components. Following figure shows these components: Figure 1: Major components of our system As discussed in Development Methods section, we have chosen to implement 3 of these components/modules for iteration 1. These modules are: User registration, login and individual plan. To get details of these modules, we would like you to go through use case section of our Inception Revision Document, section 4 (download from here). To depict these modules we present the sequence diagrams as follows:

7 Figure 2: Sequence diagram for New User Registration Figure 3: Sequence diagram for existing User Login

8 Figure 4: Sequence diagram for Individual Planning 7. Detailed System Design In this section, we shall describe 3 major modules implemented in first iteration. Registration Module: 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) 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 Id provided while registering, is unique throughout the application. This ensures that the each user has unique login information, necessary to log into application. Checks for the availability of user s additional detail like Name. After a successful registration, the user is logged into the application, navigating him to the home screen. The user is navigated to the Login screen if he chooses not to register. Constraints The user should have an 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, Id and password 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 Login module (main.xml and LoginActivity.java), where if the user does not have the credentials to log into the application is navigated to the registration module. On successful registration of the

9 user, he/she is logged into the application and is navigated to the Home module (home_screen.xml and HomeActivity.java). Resources The registration module requires a centralised database, where the details of the registered users can be maintained. Interfaces/Exports N.A Login Module: The login module provides a means for the user to login to the application. This is mapped to the requirement R2 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 LoginActivity.java in the com.mactivity.activities package main.xml in the layout folder of resources(res) 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 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. Constraints The user should have registered to the application using a valid 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 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 Id and password to let the user login to the application. Interaction This module collaborates with the Home module. On successful login, the user is logged into the application and is navigated to the Home module (home_screen.xml and HomeActivity.java). The login module also provides a means to navigate to the

10 Registration module (registration_screen.xml and RegistrationActivity.java), where if the user can register himself to the application. Resources The Login module requires a centralised database, where the details of the registered users can be maintained. Interfaces/Exports N.A Planning Activity Module: Classification: Planning activity module includes com.mactivity.activities.planactivity.java, res.layout.picktype.xml, res.layout.picktime.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. Constraints: Currently, the module will not be able to check if the user picks a day in the past. Moreover, the time table will not change according to the day of the week. 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. 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

11 8. Database Design 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 are using the SQLite database which is inherent to Android OS, however as the SQLite is server less and our application requires a centralized server, by 2 nd iteration, we will move to the MySQL database which will be hosted on the UTA Omega server. Database Layouts: The database will have 2 tables for the first iteration: 1: UserTable: It will have following attributes and data types: a) Id(Primary key): mediumint(10) b) Full Name:varchar(20) c) Add:varchar(20) d) Password: varchar(20) 2: PlanTable: It will have following attributes: a) Sport: varchar(20) b) Date: DATE(20) c) Time: TIME(20) d) Id(Foreign key):mediumint(10) Data Definition Language (DDL): 1: For creating UserTable Relation: create table UserTable ( _id primary key auto increment, fullname varchar(20) not null, password varchar(20) not null, varchar(20) not null); 2: For creating Individual Plan Relation:

12 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); Data Manipulation Language (DML): 1. For logging in: SELECT fullname, password FROM 'UserTable' WHERE Add= 2: For registering a user: INSERT INTO 'UserTable '(`Id`,`FirstName`,`LastName`,`UserName`,`Password`,` `) VALUES (1, 'Hardik', 'Shah', 'hbs1966', 'abcde', 'hardik@uta.edu'); 3: For finding an Id of a user: SELECT Id from UserTable where Add="hardik@uta.edu"; 4: For scheduling an activity: INSERT INTO `PlanTable` (`Sport`,`Date`,`Time`,`Id`) VALUES ('Basketball', ' ', '18:00:00', 'Id'); 5: For seeing an activity: SELECT * FROM `PlanTable` WHERE Time='18:00:00' and Date=' ' 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=' ' and Sport='BasketBall';

13 9. Improvements in Iteration 2 As discussed in section 4 of this document, we had planned 3 parts to implement in iteration Group Plan 2. Friend List 3. Notification Page 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. Now, we shall discuss design of these improvements in details: 9.1 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:

14 9.2 Detail Design for Planning Activity 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. 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 9.3 Detail Design for Notification Classification: NotificationActivity.java, NotificationFriendActivity.java, NotificationGroupPlanActivity.java, notification.xml, notificationpost.xml

15 Definition: Notification system is system which enables the user to track all related activities, plans and friend request. Responsibilities: The user can view all his notifications, on certain notifications he might need to take some action to which he will be moved on clicking on that particular notification. Constraints: If user never clicks on a particular notification it won t be deleted. Composition: The notification.xml shows all notification that is specific to the user. If he received an invite to a group plan or a friend request, on clicking on that notification he will moved to another screen, notificationpost.xml where the user can click on Accept or Reject button. Uses/Interactions: All the requests, on being accepted will return back to the sender as an acceptance message. On being rejected will also return a notification back to the sender of the request as an acceptance message. Resources: Database is required for this module Interface/Export: This module will swap NoteTo and NoteFrom and change TypeStatus to 2 on accept and 3 on reject. Friend List Notification Design - First when a user searches an id and clicks on Add Friend button. The UserID of the current user and the ID of the requested friend are placed as a tuple in the Notification table. The query is as follows. Insert into Notification (`NoteFrom`, `NoteTo`, `NoteType`, `TypeStatus`, `GroupPlanId` ) values (<User ID>,<ID of the friend added>,1,1,null); The mechanism is as follows - The NoteType has 2 possible values - 1 and 2. 1 It s a Friend request. 2- It s a Group Plan notification The TypeStatus has 3 possible values - 1,2 and Invitation, 2- Accepted and 3-Rejected. Now when user opens the Notification page, it fetches 1-1 as Friend requests and 2-1 as Group Plan requests. The user is shown either to Accept or Reject. Once on accepting, the entry in notification table is modified and the Friend table as those User IDs as friends. Group Plan notification design - An entry in GroupPlan table is made when 'Group Plan' button is clicked. Insert into GroupPlan(`Sport`, `Date`, `Time`, `GroupPlanOwner`)...

16 Now when user searches and add friends, an entry into Notification table using the following query - Insert into Notification (`NoteFrom`, `NoteTo`, `NoteType`, `TypeStatus`, `GroupPlanId` ) values (<User ID>,<ID of one the friend added>,2,1,<group Plan ID>); On accepting\rejecting the GroupPlan \ Friend Request there will be a change of TypeStatus to 2, Flip NoteFrom & NoteTo and make a new notification, hence notifying the initiator of the plan about accept\rejects. 9.4 Detail Design for FriendList: Classes used: Feature: AddFriendActivity AddFriend: This class takes friends address to be added as a friend, checks for the validation of the Address and also checks if the entered address is already friends with the user. If not, sends a notification message to the friend about the friend request. Database design: Notification Relation: Following are the attributes of the Notification: a)notefrom b)noteto c)notetype d)typestatus e)groupplanid The mechanism is as follows - NoteFrom and NoteTo are straightforward: It says, the request is from which person to which person The NoteType has 2 possible values: 1 It s a Friend request.

17 2 It s a Group Plan notification The TypeStatus has 3 possible values: 1 - Invitation 2 - Accepted 3 - Rejected. 10. Conclusion In this document, we presented a design specification of part of our android app MACtivity. If you have any questions, comments, feedbacks, please feel free to contact members of team 6 Sanjay Vasudeva Iyer (sanjay2207@gmail.com) Shwetha Narayan (shwethan14@gmail.com) Hardik Shah (hbs.wit.1989@gmail.com) Khandaker Moinur Rahman (khandaker.moinur.rahman@gmail.com) Yu Xuan Zhang (isaac.zhang913@gmail.com) Useful Links: Our Wiki page: Project Hosting Page: SVN Repository Location: (>trunk>mactivity) Source Code Checkout for non-members:

MACtivity Test Cases Team 6 CSE 5324: Spring 2012 Khandaker Moinur Rahman Shwetha Narayan Hardik Shah Yu Xuan Zhang Sanjay Vasudeva Iyer

MACtivity Test Cases Team 6 CSE 5324: Spring 2012 Khandaker Moinur Rahman Shwetha Narayan Hardik Shah Yu Xuan Zhang Sanjay Vasudeva Iyer Department of Computer Science and Engineering The University of