SOFTWARE DESIGN SPECIFICATION

advertisement

SOFTWARE DESIGN SPECIFICATION

Mysh Svidersky

Nathaniel H. Clay

1.0 Introduction

1.1 Goals and objectives

The main goal of the software is to provide the users with an easy to use interface for making location based playlists and tour guides, as well as the ability to share their creations with their friends and the rest of the world. The user would be able to search for, play, pause stop and create different playlists or guides.

1.2 Statement of scope

There are two major features of the software: the ability to play audio files stored on the central server or on their phone, and to create playlists, all while traversing a certain area.

The user would be able to use their phone to look through a list of available files for the area that the GPS system on their phone is currently returning. The files are ordered by their rating. The user would also be able to search for a certain file or look through those files labeled as music or tour. While listening to a particular file, the user will be able to rate the file, stop it, pause it, or play the next file in the list.

Another function of the software is the playlist maker. While traversing an area, the user will be able to mark certain locations and input songs for those flagged places, putting it together into a playlist file that they would be able to place on the server and share with the world.

The third, and final, major function is the Location Information tab, which takes the input from the users GPS and allows the user to enter or see the user created content or linked content about that location.

1.3 Software context

As with many Web 2.0 applications, we do not know, exactly, how the users will use the software. The goal of a Web 2.0 software project is to provide unique functionality that is useful to the software user, allow the company to either gather unique valuable information (while respecting and protecting the privacy of the users of the software by providing clear

TOS and opt-in to each data collection effort) , or gather advertisement revenue. The users define the individual possible uses for the software application.

One possible use for the application is for the user to create his own directions to a location of a meeting or house with personalized audio prompts. Universities or Organizations can create a tour of their campus for their visitors to tour the locations around the campus. Another use is for individual users to leave relevant information about a location for other users to see and use.

The users may choose to mark a POI(Point of Interest) with a particular song or audio recording that strikes them artistically. This will be available for other users to subscribe to or, if marked private, the POI will only available to that user.

1.4 Major constraints

Due to the limited amount of time alloted for the implementation of this product, there will be several constraints on it. It will only be tested on

Android, but it is the company's hope that it will function eventually on other phones such as the iPhone and the Blackberry Smartphones. On the Blackberry systems, the program would have to be supported by a native Blackberry application as the Blackberry Browser does not implement the proper technologies to handle the capabilities need by the loMuze application, such as HTML 5 support. Also, the creation of playlists will be limited to the phone application and there will be no PC interface provided. However the application should load and function as on a phone in any modern web-browser such as IE with Google Gears,

Safari, Google Chrome and Opera. This is expected but will not be tested, a side-affect of using Google Web Tool Kit for the UI.

2.0 Data design

2.1 Internal software data structure

Plain Ol' Java Objects will be used to pass data from each of the different components in the system this is provided by the Hibernate Framework.

2.2 Temporary data structure

Arrays of coordinates will be created, when flagging locations and creating play-list before uploading to the server. These arrays will be used by the

Viewer to verify that the information has been properly transfered.

2.3 Database description

All databases and tables will be managed and created by hibernate framework.

3.0 Architectural design

3.1 Program Structure

This program will be split into three distinct parts, the model, the viewer and the controller. This is referred to as a MVC architecture. This architecture aids the developer in splinting web products into three separate parts that are easily developed separately then brought together in parts, integrated into one cohesive system.

4.0

Sc he dul e

4.1

Sc he dul ing dia gra m

3.1.1 Architecture diagram

4.2 Definition of milestones

Milestone 1 -(Model) Should also be completed, but no communication with the sever ( controller/presenter). April 5, 2010

Milestone 2

– (Viewer) GWT Interface should be done and rendering correctly, but with out any interaction from the server.

April 7, 2010

Milestone 3

– ( Controller/ Presenter ) Should be completed and the application should function as one. April 21, 2010

Milestone 4 – (V&V) completed and release April 28, 2010

5.0 Component - level design

5.1 Description for components included in the current design and development iteration

5.1.1 Processing narrative (PSPEC) for component n

When the program is opened, the user is displayed with an interface containing a central page, which at the top includes a rendering of the company logo, an exit icon, a file player, and three tabs labeled File List, Location Information and Playlist Maker.

The exit icon, when clicked, terminates the program. A pop up is generated before hand, asking the user if they are sure they wish to exit. The user has the option of hitting yes or no. If they select yes, the program terminates, if they answer no, then the pop up simply drops and the program resumes operations.

The rest of the components function as follows.

File Player

The file player has three major functions: playback of the file, rating of a file and displaying the current location of a user.

The first function has three sub-functions: play, pause and stop. When a file is loaded into the file player (via the file list function, which is described elsewhere in this document), the

system queues it up from the current location (for example, if the file starts on street a, changes audio at street b and then at street c, but the user is currently at street b, the player will queue up to the audio for street b). The system then plays the audio for that file. If the user selects pause on the interface, the file will pause playback without moving away from the current time index on the audio file.

If the user selects the stop function, the player will stop playback and queue the file up to the very beginning (as per the example, at street a).

While the file is still loaded into the system (in whichever state: paused, stopped, or currently playing), the user has the option of rating the file. The user can click on the rating, which will pop up a window for selecting a new rating. Once the user has clicked on the star of their choice, the system is sent one of the following numbers: one for the first star, two for the second star and three for the third star. The system takes the current rating of the file and averages it with the new rating, rounding it to the nearest full star. The new rating is then updated in the file database as the new and current rating of the file.

The last component of the file player is the display of the current location of the user. This component will rely on the GPS system and library to list both the street address of the current location, as well as the latitude and longitude for the user to see. It will be updated every time the user moves to a new point that the

GPS recognizes as a new location.

If the user choses to select one of the tabs, the tab slides open (an xhtml artifact) and that component is displayed. The components are as follows:

File List

The File list interface also has four actions that can be performed. Once the user clicks on the File List tab, the user's current location is taken from the GPS, and the function

List_All(Location) is called. This function reads through the database to find all of the files (both playlist and tour) that are associated with locations within one mile from the users current location. The program will then list the file names of those available files in the file window, as well as the symbol for whether they are a

music or a tour file and the rating (this will all be in the database).

The user has two options of narrowing down the list, either by selecting List_Tours() or List_Playlists(). These functions limit the list to only Tours or only Playlists, respectively.

The user also has the option to search for a particular file within the database, or their phone. Clicking on the search symbol pops up a small box with a text field for entering any keywords associated with a file, as well as the option to click whether they want to search their phone or the database. If the database option is selected, then the database is searched for tags pertaining to the search criteria. If the phone option is chosen, then the phone is searched for any native playlist files that have related tags.

Location Information

When this tab is brought up, it takes the current location from the GPS system and libraries and calls Get_Location_Info() which accesses the database for that particular location and displays it on a page. When the user is ready to read the next bit of information, they can click the yellow buttons, which call the functions next_Page(), or if they want to return to the previous bit prev_Page(), which displays the new page of information.

This tab has no user input, aside from the arrows that allow the user to move from one page of content to another.

PlayList Maker

This component allows the user to make their own playlists or tour files.

When the tab is clicked, the interface is rendered, and the user has the option of pressing the record button, which calls the function Rec_Path(), which begins storing the users latitude and longitude (GPS coordinates) of the locations that they flag. Only the flagged locations are stored in the database. The user then has the option to hit the search button to search for the file they wish to add to that flagged location. In actuality, it only records a series of flagged locations for which the user can then add audio files. Once the recording is stopped, all the points that were added during the

“recording” phase, are considered one tour or playlist file.

When the user is ready to associate a file with a flagged location, they click the search button, which runs the Search_Files() function. The user also has the option to search for a particular file within the database, or their phone. Clicking on the search symbol pops up a small box with a text field for entering any keywords associated with a file, as well as the option to click whether they want to search their phone or the database. If the database option is selected, then the database is searched for tags pertaining to the search criteria. If the phone option is chosen, then the phone is searched for any native playlist files that have related tags.

Once the recording is complete, and there is a tour or playlist file, the user now has the option to hit a button to save their newly created file. The button calls the function add_Playlist(), which pops up a window with various text fields that allows the user to enter their data, such as the title and description of the file, as well as the tags for search indexing and whether the file will be private or not. Once the data is entered and the user hits the save file button, the file is saved on the database with the information. It is then available for viewing in the file list. This function should most likely include the option to save on their phone versus the database.

5.1.2 Component n interface description.

Controller

File List and Player

List_All(Location)

The function takes a location from the GPS system in the form of longitude and latitude. It then searches through the database for files that have a longitude and latitude coordinate pair that is within a mile from the input location, and returns an array of file location pointers in the database.

List_Playlist_Files (Playlist)

This is an internal component. It takes in the parameter of a playlist file that contains pointers in an array of the files for a playlist indexed by the location that the file is to be played at. The array

will be a two dimensional array that has the first dimension as the location and the second dimension as the pointer to the header of the file to be played.

List_Tours(location)

This function does much the same what List_All() does, only it returns only the files labeled in the database as tours.

List_Playlists(location)

This function does much the same what List_All() does, only it returns only the files labeled in the database as tours.

Playlist Maker

Rec_Path (Location)

This function takes the location of where the user starts the path.

The function add_Flag is a sub-function of this function, in that

Rec_Path creates a new Tour or playlist file and within that file it records the flags that the user flags. It then records the files that the user records as well using the add_File function. Together, this stores locations and pointers to headers of files in a two dimentional array. Once the function exits, it returns a file with the array in it. add_Flag(Location) add_File(Location)

Location Information

 get_Location_Info(Location)

This function takes the information provided by the GPS system on the current location of the user and searches the database for the information pertaining to that location. It returns the information as a text file, which is rendered, 5 kilobytes at a time in the locINf window.

6.0 User interface design

6.1 Description of the user interface

6.1.1 Screen images t h e f o t n i t t a s e n n i o r e

R e p a c e f r e r o f t m h e user's point of view.

6.1.2 Objects and actions

The Viewer (File Player)

File play()

Gives the user the ability to start playback on a certain file of their choice. This action can be accessed during the pause() phase and the stop() phase.

File pause()

Gives the user the ability to pause a certain file during playback at the time of their choice. The file remains queued at the stop time.

File stop()

Allows the user to stop playback on the currently loaded file completely. This would keep the file loaded, but would queue back to the very beginning.

File Rate(int R)

Allows the user to rate a file they are currently listening to (stopped, paused or playing) any whole number of stars out of three. The data is saved in the database.

Clicking on the stars (which show the current overall rating) pops up a small window with three stars from which the user can choose their personal rating.

The rating is cumulative from the left, meaning that pressing on the middle star would give the file a rating of two out of three stars.

CurrentLoc()

This function renders the current location of the user in the user interface.

File List

List_All(location)

This function lists all of the files that are currently available for streaming for the location the user is currently in. They are ordered by the overall user rating that is stored in the database. This is the default display when the File List tab is clicked.

Search_Files()

This pops up a window that allows the user to search through the available files either on the Internet (the database) or their own personal phone.

List_Tours()

When clicked (true) this function lists only the tours in the available files section.

List_Playlists()

When clicked (true) this function lists only the playlists that are available in the files section.

Location Information

Get_Location_Info()

This is a function that, when the Location Information tab is clicked, searches the web for information on that particular location and displays it in the window.

 next_Page()

Displays the next page of information in the window.

 prev_Page()

Displays the previous page of information in the window.

Playlist Maker

Rec_Path()

This records the path traversed by the user until the button is hit again, at which point, the recording stops. In actuality, it only records a series of flagged locations for which the user can then add audio files. Once the recording is stopped, all the points that were added during the “recording” phase, are considered one tour or playlist file.

 add_Flag()

This button flags a location in the current path traversal for later indexing of audio files. The user can later click on that flag and add a song or file there. LoMuze assumes that the user will remember where certain flags are, or that they will imput the information as soon as they flag an area.

 add_Playlist()

Saves the created playlist on the database or on the user's phone for later use.

This action opens up a window that requires the user to name the file, give it a short description, add any tags that would help with the searching for this file, as well as the ability to set this file as private, viewable only by the creator. It should also ask if the file is a playlist or a tour.

 search_Files()

Opens up the search window that allows the user to search through the available files either on the Internet (the database) or their own personal phone.

This then allows for that file to be indexed at one of the flagged locations of the user's choice.

7.0 Restrictions, limitations, and constraints

To use this software, the user will be required to own and now how to operate either an Android Smartphone or an Apple iPhone. They should also be familiar with general aspects of audio playback on computers and

these devices.

Due to the limited amount of time alloted for the implementation of this

product, there will be several constraints on it. It will only be tested on

Android, but it is the company's hope that it will function eventually on other phones such as the iPhone and the Blackberry Smartphones. On the Blackberry systems, the program would have to be supported by a native Blackberry application as the Blackberry Browser does not implement the proper technologies to handle the capabilities need by the

loMuze application, such as HTML 5 support. Also, the creation of playlists will be limited to the phone application and there will be no PC interface provided. However the application should load and function as

on a phone in any modern web-browser such as IE with Google Gears,

Safari, Google Chrome and Opera. This is expected but will not be tested,

a side-affect of using Google Web Tool Kit for the UI.

8.0 Appendices

Presents information that supplements the design specification.

8.1 Packaging and installation issues

Since the software is not for installing on a phone, so the majority of the power required to run the program will be on the server side. This means that there would not have to be any executable file that is installable on the clients phones. The phone will only need to have the power to load all

of the images, as the software is pretty image heavy, and be able to accept the playback of a number of large audio files.

Download