SOFTWARE DESIGN SPECIFICATIONMysh SviderskyNathaniel H. Clay1.0 Introduction1.1 Goals and objectivesThe 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 scopeThere 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 musicor 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 theuser created content or linked content about that location.1.3 Software contextAs 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 constraintsDue 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 design2.1 Internal software data structurePlain 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 structureArrays of coordinates will be created, when flagging locations and creatingplay-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 descriptionAll databases and tables will be managed and created by hibernate framework.3.0 Architectural design3.1 Program StructureThis 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.3.1.1 Architecture diagram4.0Schedule4.1 Scheduling diagram4.2 Definition of milestonesMilestone 1 -(Model) Should also be completed, but no communication with the sever ( controller/presenter). April 5, 2010Milestone 2 – (Viewer) GWT Interface should be done and rendering correctly, but with out any interaction from the server. April 7, 2010Milestone 3 – ( Controller/ Presenter ) Should be completed and theapplication should function as one. April 21, 2010Milestone 4 – (V&V) completed and release April 28, 20105.0 Component - level design5.1 Description for components included in the current design and development iteration 5.1.1 Processing narrative (PSPEC) for component nWhen 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 PlayerThe 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), thesystem 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