Online Survey App

Detailed Design

COP 4331, Fall, 2014

Team Name: Group # 2

Team Members:

• Kaan Arikan - kaan@knights.ucf.edu
• Adam Hollifield - ahollifield@knights.ucf.edu 
• Robert Montalbano - jazavac@knights.ucf.edu 
• Shawn Morrison - groundlevelcustoms@knights.ucf.edu 
• Cody Showers - cshowers@knights.ucf.edu 
• Franklin Yi - frankyi@knights.ucf.edu 

Modification history:

Contents of this Document

Design Issues

Detailed Design Information

Trace of Requirements to Design

Design Issues:

Issue Relevance:

• Issues related to software reusability will be evaluated on a case-by-case basis.  Some reusable code, such as the Android APIs used for system and permission functions, cannot be built from scratch and their existing implementations must be included in the project.  This application’s code cannot be reused on another mobile platform.  UI layouts will be written from scratch and will not use pre-built activity layouts.  Security hashing and encryption module code must be written from scratch and not be shared with others.  This keeps database security in tact.  Database schema inserts and reads are specific to this application and must be built.  
• Issues related to maintainability will mostly arise from the server side portion of this project.  Any changes to security encryption and message handling must be replicated on both server and client side systems.  This may cause version incompatibility with newer versions of server side applications and older versions of the Android application.  Amazon AWS provides storage for server instance backups that must be performed on an interval.  Amazon AWS provides custom yum repositories for Amazon Linux security updates.  These must also be applied at regular intervals.    
• Issues related to testability will be evaluated during all developmental phases of the project.  It was decided to use mySQL running on a cloud server instead of a local database on SQLite.  This makes integration testing much more difficult as both the client and server side must be checked for database accuracy.  The requirement for a phone number adds extra complexity to testing.  This can alienate certain simulators and devices (such as tablets) requiring later testing only on mobile phones.  A phone number is required for our database entry and project specification.
• Issues related to performance will also be evaluated during all developmental phases of the project.  Java code is inherently more performance impacted and uses more system resources than an alternative language choice.  The cloud server has performance implications over choosing a custom hosted server.  The cloud server has performance limitations and could be negatively impacted by other heavily bandwidth users on Amazon AWS service.  Communication with the server can be hindered and negatively impacted by the speed of the phone’s connection to the internet.  TCP based communication will be used for the cloud server.  UDP could have chosen for this communication for performance benefits, however, data accuracy is essential for this application.  
• Portability to other mobile (or desktop) platforms is not a primary focus of this project.  Portability issues between different Android devices may become a relevant issue to this project and should be investigated during the testing phase.  This application requires API calls and software that is specific to Android that would not work on other mobile platforms.
• Safety issues related to this project are minimal.  Including the phone number in the process of the design is a safety risk for end users.  If these numbers become exposed, it could impact the personal privacy of the application’s users.  No encryption method is perfect and could expose user data if the server is brute forced.  

Prototyping:

• Various prototypes evaluating different database solutions
• Various prototypes evaluating multiple UI design and layout schemes
• Various prototypes evaluating multiple survey response mechanisms
• Various server side database and socket prototypes
• Prototypes evaluating different cloud server operating systems

Technical Difficulties:

• The largest technical difficulty expected to be encountered is lack of programming knowledge about the Android environment.  These difficulties will be solved by researching and reading tutorials on Android development.
• Simulation difficulties could be encountered as well when testing the application.  These difficulties will be solved by testing on multiple Android Virtual Devices as well as multiple physical devices.
• Technical difficulties can also arise from cloud server configuration such as opening the proper server ports to the cloud server as well as ensuring the billing for the cloud instance remains zero.  These technical difficulties will be solved by consulting Amazon AWS support documents as well as configuring billing reminders if the usage approaches an amount not covered by the free tier.
• GitHub and version control technical difficulties could arise from a lack of understanding of version control paradigm.  Group members could commit changes overwriting the development efforts of other members.  These technical difficulties will be solved by each member coding on a branch of the master and then committing; resolving any conflicts that may arise.    
• Security could be another technical difficulty.  Each person should be able to login with their personal phone number and password.  If they have not made a unique phone number and password, they should not be allowed to login until they make their personal profile.  
• Another technical difficulty would synchronizing the data that the user inputs and storing the information correctly.   From there, showing the results of the information so that it is clear and easy to be read could add to the difficulty.  

Design Trade-offs:

• Developing in a high level interpretive language such as Java does have performance implications.  Java was selected as the primary architecture because it is natively supported on Android as well as team member familiarity with Java.  Technical risks can include improper coding syntax and code security.  An improperly coded application could have the ability to crash the Android device or consume unwarranted information from the user.
• A free-tier Amazon AWS EC2 instance is allocated a lower amount of system resources than a paid instance.  This limit should not be an issue for this application as we expect low server utilization.  This architecture was chosen to keep the project costs at a minimum.  Technical risks of this solution include not having enough disk space to store the database as well as not processing server requests in the time limits mentioned in the SRS document.
• A single home page application structure is a usability trade off.  This design may require the user to navigate to the home page between performing each task within the application; movement directly between activities will not be supported.  This architecture was chosen due to developmental simplicity and to give the user a single, familiar, starting location.  Technical risks of this solution are minimal, although, this architecture does introduce a single point of failure to the system.
• SQLite vs mySQL. vs closed source like Microsoft SQL Server. The cost of the system was our first consideration for use of database systems. Although Microsoft SQL Server comes with specific and thorough support, continued support would be at a cost. MySQL and SQLite are free alternatives. SQLite was under consideration as it does not require a server setup as it is completely contained. However, sending and receiving information would be far more complicated on the system as a whole without a centralized data source. MySQL is widely used, so there is an abundance of information available about it and several libraries for interaction.
• Ultimately we chose Android development for our platform of choice over Iphone. Iphone development requires a developer licence which is not free. Android also supports native Java, a language we chose for our familiarity with it, and Iphone does not.
• Having a phone number requirement adds a layer of complexity to the testing of this application. Application use could have been limited to devices that had phone numbers to add a layer of security at the expense of complicating development. However, this security does not extend to every device, as phone numbers can easily be spoofed. Giving the user the ability to set the phone number if the environment cannot determine this number will ease the difficulty of testing and expand the compatibility to devices that might not inherently have a phone number.

Detailed Design Information:

Create Survey:

Sequence diagram for the Create Survey functionality of the application.  User selects the appropriate button to Create Survey.  User is presented with the various options to make the survey, upon clicking submit, the survey is saved and entered into the database, making it available for other users to take.

Login:

Main activity for the application.   User enters credentials into appropriate fields.  Both the phone number user ID and the password are hashed and sent to the database.  The database then returns whether the user has entered valid credentials or whether a new account must be created.  If a new account must be created, the user enters their phone number and password, both are hashed, and entered into the server’s database.

Logout:
Button present on the homepage for this activity.  The request is processed by the user database server and the user is returned to the login screen of the application.

Take Survey:

User starts this sequence by selecting the appropriate button on the home page.  The database server is then queried and returns a list of the current available surveys.  The user can then select a survey from the list.  The user is then redirected to the survey itself, completes the survey, and presses submit.  Once submit is pressed, the responses are submitted to the server and are available for reporting.

Update Personal Profile:

User presses the update profile button present on the homepage to start this sequence.  A user can view and modify all account attributes such as gender, age, and education level.  When a user submits their updated profile, the corresponding user attributes are saved on the database server and will be tagged in any surveys this user completes.

View Results:

The user pushes a button on the homepage to begin this sequence.  The database is queried for a list of the current surveys.  The user then selects the survey for which they wish to view the results.  The results and demographic information are also returned along with the survey.  Lastly, a user may also view the comments made on the survey.

Class Diagram:

Trace of Requirements to Design:

* - Strong Correlation