Detailed Design

COP4331 Processes in Object-Oriented Programming | Fall 2014 | Group 12 - Project 17

Modification history:

Team Name: The Spungos' Turbo Wallhacks

Team Members:

• Alex Berliner; alexberliner@knights.ucf.edu
• Christopher Kovaleski; ckovaleski@knights.ucf.edu
• Oscar Hedblad; oscarhedblad@gmail.com
• Luis Duque; luisduque23@gmail.com
• Alan Birmaher; abirmaher@knights.ucf.edu
• Jimmie Potts; jimmie.potts@knights.ucf.edu

Issue Relevance:

• Testing-related issues will be evaluated while in the testing-stages of the process of development. We are making sure that no interfaces require excessive time consuming data generation in order to complete the testing.

• All project interfaces should be built in an easy manner so that testing can be done smoothly.

• Safety issues are next to minimal. The only safety concerns that we could think of are physical, such as people uploading dangerous challenges. However, we expect all users to follow common sense protocols while using the Android application.

• Portability to other devices. A goal is to get our application to run on iOS, BlackBerry, and Windows.

Prototyping:

• Prototype on various services we could potentially use

• Prototype evaluating multiple design layouts

• Prototype evaluating different database solutions

• Prototype evaluating different cloud server possibilites

Technical Difficulties Expected:

• Getting the API to work properly might take more effort than planned. Framework may prove to be an insufficient fit for some specific scenarios due to deficiencies within the features, or even unnecessary features. Furthermore, libraries and frameworks might need to be switched out in order to maximize compatibility and efficiency. All members of the group do not share the same technical skills, and further learning is required from all of us in order to successfully complete the application.

• Having the users upload videos directly to YouTube brings in YouTube-related risks, such as something being wrong with their server, etc.

Solutions to Technical Difficulties:

• Choosing the framework correctly will maximize the compatibility and minimizes unnecessary features. The application should also be stable when in between updates.

• All members of our development group will be expected to learn any new necessary skills in order to complete the project.

Design Trade-offs:

• As Java is a very high level interpretive language and comes with performance implications. We selected Java as the language of choice as Android already supports it, which eases the process of development. With Java, as many other languages,  comes technical risks, which can include improper coding syntax as well as code security. Coding the application improperly could potentially lead to the application crashing the Android device.

• We chose not to have any databases connected to our application. Instead, we’ll be allowing the users to directly send the video to their friends via YouTube. The user takes a photo or records a video, the application lets the user then upload the clip to YouTube. Upon being uploaded, the application sends a link addressed to the YouTube clip, to the receiving user.

• We have also decided to make the application fairly obvious to use. We will have a starting menu-screen where the user will be starting when running the application. On this main-page there will be a few options, like connecting to Twitter. Synchronizing with the Twitter social media lets the application access the users friend-list, which allows the user to select between various friends. Once a friend is selected the user can record a video or take a photo which then can be sent to a (or multiple) friend(s).

Design Decisions and Associated Risks:

The decision to target Android devices was made primarily because of accessibility. The Challenge Your Friends app is meant to be a mobile application and the Android environment is the most accessible. Most of us on the development team have little experience in programming for the Android platform, so it is essential we take the time to learn and understand the platform. Since there are so many different Android devices, however, we must be aware of the challenges of having the app operate correctly across the different devices.

Twitter is one of the largest social media platforms in the world and thus lead to the decision to rely on Twitter for users to post and receive challenges. Much of the application relies on Twitter, so if Twitter goes down, it would bring our application down as well. This risk however is minimal since Twitter has a history of being a reliable platform. Also, we must be aware of the 140 character limit that Twitter has when challenges are created. This will be accounted for when we allow the users to make challenges by limiting the length of the challenge name.

Detailed Design Information:

Application state diagram:

Application UML diagram:

Accept challenge diagram:

Create challenge diagram:

View local challenges diagram:

Open application diagram:

Send a challenge diagram:

Trace of Requirements to Design:

Sequence Diagram	Software Requirements SpecificationS
Login Sequence	3.1: 1, 2, 3 3.2: 1 3.3: 1 3.4.1 3.8: 1
Send Challenge	3.2: 2, 3, 4, 5, 6 3.6: 1 3.8: 1
Accept Challenge	3.2: 3, 4, 5 3.6: 1 3.8: 1
Create Challenge	3.2: 2, 3, 4, 5, 6 3.4: 2 3.6: 1, 2 3.8: 1
View and Get Challenge	3.2: 2, 3, 4, 5 3.6: 1

Template created by G. Walton (GWalton@mail.ucf.edu) on October 8, 1999 and last modified on August 15, 2000

This page last modified by Alan Birmaher on 11/16/14.