MACtivity Design Specification - Maverick Wikis - The University of ...

blareweyrSoftware and s/w Development

Dec 13, 2013 (3 years and 8 months ago)

62 views

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



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. Conclusion








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
numbe
r 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 hon
orable professor and TA of course CSE 5324. Also,
assigned reviewer team will be able to evaluate o
ur 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
ac
tivities 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



Maint
ain a friend list



Plan Individually



Plan as a group



Important notifications



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 coll
ected 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.

Statistic
s

Chart

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 go
ogle 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 phone
s,
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
i
teration 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.





6.
System Architecture

For simplification, we divided our system into several components. Following figure
shows these c
omponents:


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:


Figure 2: Sequence diagram for New User Registration



Figure 3: Sequence diagram for existing User Login


Figure 2: 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 appli
cation.


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.



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 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, email Id and password required for registering to the
application. The details from this xml are then accessed in the RegistrationActivity clas
s
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
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 d
atabase, 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 Docume
ntation

(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 credent
ials 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.


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 th
e 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 em
ail 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
Registration module (registration_screen.xml and RegistrationActivity.java), where if the
user can register himself to the application.


Resources


The Login module requires a ce
ntralised 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 creatin
g 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 i
n 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 d
ate
picker dialog, user selects the appropriate date and he/she will be directed to the
picktime.xml to select a time slot.

Uses/Interactions:

T
he 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 thr
ee fields: type, date
and time into the database



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 Environ
ment:
F
or 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
M
y
SQL

database which will be hosted on the
UTA O
mega 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)

EmailAdd: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:



creat
e 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 collat
e
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 EmailAdd=
'hardik@uta.edu';

2: For registering a user:



INSERT INTO 'UserTable '(`Id` ,`FirstName` ,`LastName` ,`UserName`
,`Password` ,`Email`) VALUES (1, 'Hardik', 'Shah', 'hbs1966', 'abcde',
'hardik@uta.edu');


3: For finding an Id of a user:



SELECT Id from UserTable where EmailAdd="hardik@uta.edu";


4: For scheduling an activity:




INSERT INTO `PlanTable` (`Sport` ,`Date` ,`Time` ,`Id`) VALUES ('Basketball',
'2012
-
02
-
27', '18:00:00', 'Id');

5: For seeing an activity:



SELECT * FROM `PlanTable` WHERE Time='18:00:00' and Date='2012
-
06
-
01'
and Sport='Ba
sketBall';


6: For getting the value of number of people coming at an activity:



SELECT COUNT(*) FROM 'PlanTable' WHERE Time='18:00:00' and
Date='2012
-
06
-
01' and Sport='BasketBall';





9.
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 (
shwethan1
4@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:
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