SOFTWARE DESIGN SPECIFICATION

aquahellishΛογισμικό & κατασκευή λογ/κού

13 Δεκ 2013 (πριν από 3 χρόνια και 9 μήνες)

91 εμφανίσεις






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 gui
des, 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 tha
t 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 place
s, 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 ent
er 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 f
unctionality 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
prom
pts. 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 constr
aints

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
loMuz
e 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 I
E 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 array
s 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 th
en brought together
in parts, integrated into one cohesive system.


3.1.1 Architecture diagram


4.0
Sc
he
dul
e



4.1
Sc
he
dul
ing
dia
gra
m








4.2 Definition of milestones

Milestone 1
-
(Model) Should also be completed, but no
communication with the seve
r ( 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
applicatio
n 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) f
or 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 an
d 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 loca
tion (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 sel
ects 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 examp
le, 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 r
ating. 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 w
ith 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 compo
nent 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 l
ocation.


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 w
ithin 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).
Th
e 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 t
he 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 opt
ion
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 th
e 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_P
ath(), 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 d
atabase 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 tha
t 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 functi
on. 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 i
n the locINf
window.

6.0 User interface design

6.1 Description of the user interface

6.1.1 Screen images

R
e
p
r
e
s
e
n
t
a
t
i
o
n

o
f

t
h
e

i
n
t
e
r
f
a
c
e

f
o
r
m

t
h
e user's point of view.


6.1.2 Objects and actions

The Viewer (File Player)



File

play()


Gives the user the ab
ility 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 ar
e 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 c
hoose
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
in
terface.

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
def
ault 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 file
s. 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 use
r 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 datab
ase 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 privat
e,
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 S
martphone 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 app
lication 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 To
ol 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 b
e 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
ac
cept the playback of a number of large audio files.