Music Case Study
By:
1
Table Of Contents
Table Of Contents ............................................................................................................................. 2
Introduction ...................................................................................................................................... 3
Task 1: Interview Questions & Answers ............................................................................................ 4
Task 2: Requirements Specification .................................................................................................. 6
PROBLEM STATEMENT ......................................................................................................... 6
BACKGROUND INFORMATION ............................................................................................. 6
IMPORTANT ISSUES ............................................................................................................. 6
ENVIRONMENT AND SYSTEM MODELS ................................................................................ 7
FUNCTIONAL REQUIREMENTS ............................................................................................. 7
NON_FUNCTIONAL REQUIREMENTS ....................................................................................8
Task 3: ER (Entity Relationship) Diagram .......................................................................................... 10
Task 4: Testing Plan ........................................................................................................................... 11
JUKEBOX TEST CASES ........................................................................................................... 11
CHECK LIBRARY TEST CASES ................................................................................................. 11
CREATE PLAYLIST TEST CASES .............................................................................................. 11
UPDATE LIBRARY TEST CASES .............................................................................................. 12
Task 5: Query Implementation ......................................................................................................... 15
Task 6: Query Execution .................................................................................................................... 16
Task 7: Critical Review Of Database .................................................................................................. 17
Task 8: Use Case Diagram Of Commercial Jukebox .......................................................................... 18
Task 9: Class Diagram Of Commercial Jukebox ................................................................................. 19
Task 10: Sequence Diagrams Of Commercial Jukebox ...................................................................... 20
Task 11: State Machine Diagram Of Commercial Jukebox ................................................................ 21
Conclusion ......................................................................................................................................... 22
2
Introduction
A jukebox is a machine that stores, holds, and plays songs. The goal of this project, CJB -Commercial Jukebox, is to create a virtual jukebox that can hold songs, look at the descriptions,
and play the songs that are stored based on the user's input. This project aims to support the
customer requirements to create a design for the CJB machine. One of the steps is to use UML
diagrams to create the design of the system, diagrams that model how the system works and
what to expect. Then the other step is to use Microsoft SQL Server to model the database,
finding out the tables, information, and possibly queries based on the customer expectations.
3
Task 1: Interview Questions & Answers
Q: What sort of jukebox solution are you looking for?
A: Well there will be a basic model jukebox for private and home use and then another for
Commercial placement.
Q: Do you have a budget in mind and when would you like this software delivered?
A: £40,000 and Late December.
Q: Is there any area of the jukebox which you are more concerned about that than others?
A: No, so long as there is the capability to store all the music required.
Q: Is there a specific genre of music that you have in mind for this jukebox?
A: For the commercial version it will be personalized and for the basic player it's up to the user
what they upload.
Q: Do you think it would be a good idea to include the availability to publish adverts in loading
screens, between track selection and track play for example?
A: That's up to you to implement this.
Q: Would you like the final product to be a touch screen device? Or have physical input from
buttons?
A: Up to you.
Q: So you're looking for a system in which the user will upload their own music to it?
A: We're not that interested in the upload process, what we're interested in is that they can
add music, they should be able to select tracks, artist or album and select all the music on
an album.
Q: What storage solution would you prefer for the track data?
A: Again, that's up to you.
Q: How many songs are you looking to hold?
A: Thousands and thousands.
Q: Is there any sort of platform you'd like it to run on?
A: Whatever you'd suggest, it should at least run on a windows PC.
4
Q: How many front end users per night would you expect to have?
A: Entirely dependent on whom the product is sold to.
Q: How many back end users will be using the software, adding tracks, albums, editing
information, creating playlists etc.?
A: One, the manager of the premises, who will be in charge of the management of Tracks and
removal of money.
Q: Will the manager be able to access the songs and change information? Possibly from home
as well?
A: Yes they should be able to as they will decide what type of music will be on each type of
jukebox. For example if you own a small cafe frequented by OAPs you wouldn't necessarily
want a selection of heavy metal on there.
5
Task 2: Requirements Specification
PROBLEM STATEMENT
To create a music entertainment system (Jukebox). This system should run on various devices.
The system will have two versions a basic and commercial one. The basic Jukebox is expected to
be an individual repository of a selection of music that can be played by a single user. The
commercial Jukebox is a more advanced extension to the basic Jukebox.
BACKGROUND INFORMATION
As mentioned in the problem statement, the system will involve basic and commercial jukebox
models. The basic model is to be used individually for one’s own entertainment purpose. It will
not be as expensive and it will have some basic design and functionality, whereas the purpose
of the commercial model is to make profit from usage in commercial settings, such as clubs and
pubs. It will be accessed by number of users for a wider user entertainment purposes, this is
more expensive version of the Jukebox and it will have limited functionality.
IMPORTANT ISSUES
The first issue is how to attract users to use the Jukebox and pay money to play songs with it.
First of all we think the basic model should attract the user in a way that he or she would spend
more time using and enjoying it which we hope will result in familiarity with the software so
they could feel more comfortable using the same (but the commercial one) in public
environments. Having all kinds of digital devices nowadays which are able to play music with a
single click or two without having to pay a single penny to repeat songs or to select another
album makes it difficult to make people pay for something which they already have for free. So
we suggest the managers of commercial Jukebox system should be really careful when setting
up the prices for individual songs so that users will be more likely to pay and play songs more
often. If we have high prices on the songs, people might choose not to use our system at all and
that will result in having useless software.
The second issue involves budgeting. The budget for the initial project is £40,000 which needs
to be delivered by late December 2013. We need to be sure we control the flow of that money
very well during the creation of the project.
6
ENVIRONMENT AND SYSTEM MODELS
FUNCTIONAL REQUIREMENTS
A list of functional requirements for the Basic Jukebox model:





Single user's ability to lock or limit the machine use.
Import media into BJB in the common Mp3 format. So has interface for connecting to
Internet, computer or other digital data transfer device.
Storage for the collection of music and can be expanded as collection increase.
Have ports to make interface with keyboard and LCD screens.
Create and edit playlist.
7




Media Play - Playback of Music, Radom play, continuous play.
Volume and sound controls.
A Customized View – Skin and Menu Display (Playlists, Genres, Decades, Albums,
Artists).
Remote Control - Control BJB using an infrared remote control.
A list of functional requirements for the Commercial Jukebox model (Manager):











Administrative/Manager interface, with a password or code controlled area accessible
to only the manager. From where, he/she can perform the following 10 tasks.
Import media into CJB in the common Mp3 format.
Connection port or Wi-Fi so he/she can connect the CJB to the Internet, Computer or
other digital file carrying device that music can be imported from.
Database imports can be stored which leads on to storage.
Storage for the storage of database and the size can be expanded as required.
Managers can set tariff.
Adjust catalogue according to the locals,/customers preference.
Manage users.
Lock or limit use of features like volume and display skin.
Retrieve reports.
Inbuilt Recording and storage of usage report
A list of functional requirements for the Commercial Jukebox model (User):







Customers interface features.
Payment slot cash and card.
Search music.
Browse catalogue.
User’s account details on display screen (name, balance, playlist, usage history record).
Create and edit playlist.
Will be able to rate songs.
NON-FUNCTIONAL REQUIREMENTS
We would like our system to have a weekly back-up of the database and the music catalogue,
and that goes for both models.
Basic Jukebox
8
In terms of design the Basic Jukebox should look simple and user-friendly. It must work on
number of platforms: Windows, Android, iOS. We would like to implement features like
editable fonts in terms of size and color (plus background color), to ease users who have
sight problems. We would like every playlist to have option to sort the songs by name, date,
duration, artist name and album name. The user should be able to edit their playlists, and
have as many as they wish. Playlist should be able to be named and organized for easy
browsing and access. The songs should be in widely use and common file formats – MP3,
WMA.
Commercial Jukebox
In terms of design the Commercial Jukebox should be highly visible. So we would like to
design it in bright colors but we will also include different color themes so users would be
able to switch the color scheme as they prefer it to look like. There should be a free option
for the users to see the top rated songs and most played ones, some brief information for
particular song or album. We need to be sure that our system is secured we make this
possible as we make the content (music, playlists, albums) of our system not editable from
user prospective. Also it will be possible for use only if payment has been made i.e. in order
to hear a song the user must pay the fee. Only the manager is able to edit the content
therefore he or she should use username and password in order to verify him/her to the
system so he or she could whatever is necessary. The manager is the only one authorized to
set the tariff for the songs.
9
Task 3: ER (Entity Relationship) Diagram
10
Task 4: Testing Plan
Jukebox Test Cases:
Test
Input
Expected Output
Actual Output
1
2
3
4
Check Library
Create Playlist
Update Library
Exit
Check Library Opens
Create Playlist Opens
Update Library Opens
Program Quits
Check Library Opens
Create Playlist Opens
Update Library Opens
Program Quits
As far as the Jukebox.java file is concerned, the main if-statements in actionPerformed() was
tested to see if the button pressed was the correct one. From testing different inputs that can
come in from the 4 buttons, they have done the necessary actions for the expected and actual
outputs.
Check Library Test Cases:
Test
Input
Expected Output
Actual Output
1
2
3
4
5
6
7
8
List All Tracks
01, Check Track
03, Check Track
05, Check Track
00, Check Track
06, Check Track
Null, Check Track
'a', Check Track
5 Tracks
How much is that doggy ...
I'm dreaming ... - Ludwig ...
Anarchy in the UK - The ...
No Tracks
No Tracks
No Tracks
No Tracks
5 Tracks
How much is that doggy ...
I'm dreaming ... - Ludwig ...
Anarchy in the UK - The ...
No such track number
No such track number
No such track number
No such track number
For testing of the CheckLibrary.java file, the if-statements were the main basis for white-box
testing in the actionPerformed() function. All of the buttons were tested to make sure they
work properly, based on the boundary values of the input. There were 01-05 tracks, so possible
test cases were based on boundary values, 00, 01, 05, and 06. All of the boundaries that should
have failed did fail (00 and 06) and all of the boundary that should have worked did work (01
and 05). There were also tests for null or incorrect data and those also resulted in no data
outputted or error messages (Java-based exceptions).
11
Create Playlist Test Cases:
Test
Input
Expected Output
Actual Output
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
01, Add Track
03, Add Track
05, Add Track
00, Add Track
06, Add Track
Null, Check Track
'a', Check Track
Play 0 Tracks
Play 1 Track
Play 3 Tracks
Play 1 Track x 3
Play 3 Tracks x 3
Reset 0 Tracks
Reset 1 Track
Reset 5 Tracks
01 How much is that ...
03 I'm Dreaming of a ...
05 Anarchy in the UK
No Track
No Track
No Track
No Track
No Change
1 Track's Play Count + 1
3 Track's Play Count + 1
1 Track's Play Count + 3
3 Track's Play Count + 3
No Change
Track Delete
All 5 Tracks Deleted
01 How much is that ...
03 I'm Dreaming of a ...
05 Anarchy in the UK
No Track
No Track
No Track
No Track
Crashed! Exception Raised
1 Track's Play Count + 1
3 Track's Play Count + 1
1 Track's Play Count + 3
3 Track's Play Count + 3
No Change
Track Deleted
All 5 Tracks Deleted
For the Create Playlist class, most of it was tested thoroughly using boundary value cases. Most
of the work was done adding (good and bad) tracks, playing good and bad playlists, and
resetting the playlist for the actionPerformed() function. For the Adding of the Tracks, all of the
actions performed well and had no problems adding good or bad tracks. There was a problem
with playing tracks though. It would play any number of tracks that was a good input (tracks >
0). However, when 0 or fewer tracks came in, when the (tracks ≤ 0) came in, the output was a
crash and Exception. In the future update of the code, this can be corrected by changing it so
that it will catch if there's no tracks left in the list. Resetting the list also was fine.
Update Library Test Cases:
Test
Input
Expected Output
Actual Output
1
2
3
4
5
6
7
8
Null, null, Update
01, 3, Update
03, 3, Update
05, 3, Update
00, 3 Update
06, 3, Update
Null, 3, Update
'a', 3, Update
No Change
Rating 3 for Track 01
Rating 3 for Track 03
Rating 3 for Track 05
No Change
No Change
No Change
No Change
No Change
Rating 3 for Track 01
Rating 3 for Track 03
Rating 3 for Track 05
No Change
No Change
No Change
No Change
12
9
10
11
12
03, 0, Update
03, 5, Update
03, -1, Update
03, 6, Update
Rating 0 for Track 3
Rating 5 for Track 3
No Change
No Change
Rating 0 for Track 3
Rating 5 for Track 3
Rating -1 for Track 3
Rating 6 for Track 3
For the UpdateLibrary.java file, this one was to test a series of input and update functions for
the track # and rating count. For the most part the null and bad data for the track number was
checked thoroughly and performed well. However, when it came time to check for bad rating
inputs, the program did store bad data in the rating for song 03. In this case, this can be
corrected by checking to make sure the boundary for the rating is a valid number between 0-5,
using another if-statement.
13
Task 5: Query Implementation
Query 1: Adding a song
INSERT INTO wo608.Artist VALUES(13, 'Beyonce');
Query 2: Retrieve all songs on an album.
SELECT *
FROM Song s, Album a
WHERE s.album_id = a.id AND a.albumName = 'Music Box';
Query 3: Given an artist name, retrieve all of their songs.
SELECT s.songName
FROM Song s, Album a, Artist t
WHERE a.artist_id = t.id AND s.album_id = a.id AND t.name = 'Mariah
Carey';
Query 4: Show the Top 5 rated songs within the catalogue.
SELECT TOP 5 s.songName, s.rating
FROM Song s
ORDER BY rating DESC;
14
Task 6: Query Execution
Query 1: Adding a song
Query 2: Retrieve all songs on an album.
15
Query 3: Given an artist name, retrieve all of their songs.
Query 4: Show the Top 5 rated songs within the catalogue.
16
Task 7: Critical Review of Database
Play Track
Make Payment
See All Available Tracks
Change Track Ratings
Add Tracks To Playlist
Clear Playlist Tracks
Query Database Info
Remove Tracks To DB
Add Tracks To DB
Manager
Update DB
Admin / System
Review Reports
Set Tariffs
CJB System
17
Task 8: Use Case Diagram Of Commercial Jukebox
The Use Case Diagram will represent the actions of any actor on the system. There are two
actors, the user who will be accessing the jukebox system (database, query, and jPanels) while
the administrator/system on the back side will be adding data. For the use case diagram, the
actors are put on the outside
Store Songs
See Track Stats
See All Available Tracks
Add Tracks To Playlist
Play Track
Clear Playlist Tracks
Change Track Ratings
Query Database Info
Remove Tracks To DB
Add Tracks To DB
Admin / System
BJB System
18
Task 9: Class Diagram Of Commercial Jukebox
The class diagram pretty much represents the class diagram for all of the classes with the
Jukebox project. Each box contains name of the class is in the top box of each section (in bold)
and the bottom section contains the functions and the member functions. The + means the
members/functions are public while the - means private. For each member/variable that has no
()'s have a : and a type to specify the kind of variable they are and the functions have a : and the
return type that they give. For each line that connects the classes, a regular, non-directed line
(no arrow) means the class creates instances that it does not draw upon while the lines with
arrows means that the class draws information from that class. A 1 next to the line and that
class means the number of instances that the class creates in that relationship. For instance on
Jukebox to CheckLibrary line, it has 1:0...infinity meaning that for each instance of Jukebox,
there can be 0...infinite number of instances of CheckLibrary (you can press it as many times as
you want to make it go).
CheckLibrary
1
Song
- name : String
- artist : String
- rating : int
- playCount : int
+ Item(String, String, int)
+ toString() : String
1
LibraryData
- library : Map<String, int>
- listAll() : String
+ getName(String) : String
+ getArtist(String) : String
+ getRating(String) : int
+ getPlayCount(String) : int
+ incrementPlayCount(String) : int
+ close() : void
0..∞
CreatePlaylist
0..∞
1
+ trackNo : JTextField
+ information : TextArea
+ list : JButton
+ check : JButton
+ main(string[])
+ CheckLibrary() : void
+ actionPerformed(ActionEvent) : void
+ stars(int) : String
1
1
1
1
+ trackNo : JTextField
+ information : TextArea
+ play : JButton
+ add : JButton
+ resetPlayList : JButton
+ library : LibraryData
+ main(string[])
+ CreatePlaylist() : void
+ actionPerformed(ActionEvent) : void
1
Jukebox
1
0..∞
+ check : JButton
+ playlist : JButton
+ update : JButton
+ quit : JButton
+ main(string [])
1
UpdateLibrary
+ trackNo : JTextField
+ information : TextArea
+ rating : JTextField
+ update : JButton
+ resetPlayList : JButton
+ library : LibraryData
+ main(string[])
+ UpdateLibrary() : void
+ actionPerformed(ActionEvent) : void
0..∞
19
Task 10: Sequence Diagram Of Commercial Jukebox
A Sequence Diagram represents the flows of information from one actor to classes though the
system. In this case to do a sequence diagram, here the actor will be the user and go through
the motions of playing a song, adding a song, and creating playlists. Each box represents the
waiting time/action time for that part of the system. Data moves when function calls, and
makes calls go back and forth. It does incorporate error calls as well and what happens when
those do occur.
CreatePlaylist
User
DB
CreatePlaylist()
User
CheckLibrary
DB
CheckLibrary()
GUI
Query(song)
GUI
Query(song)
Query(song)
Query(*)
If Error
If Error
Message(N/A)
Message(N/A)
Song
Songs
Play(song)
Display(song)
Playing A Song
User
Displaying All Songs
UpdateLibrary
DB
UpdateLibrary()
GUI
Query(song)
Query(song)
If Error
Message(N/A)
Message('Success')
Message('Success')
Adding A Song
20
Task 11: State Machine Diagram Of Commercial Jukebox
A State Machine Diagram is one that shows the actions and states that the system can
do/function from beginning to end. In this system, the system starts in an idle state until some
money is put in. If the system has money put into it then it will continue waiting until it reaches
the amount of the tariff needed to play the song. Once enough money is put into the system,
then it goes to the next state which is set to Ready for the system to read what is going to
happen next. The user may want to browse songs. If the user wants to know more about the
song, then the system can query for that song data (move to another state called Query) and
then once it finds the information pass it back and set it back to the Ready state. Once the user
actually selects the song then the jukebox will go into Play mode until the end of the song
which then it'll go back to the Idle state.
[Start]
[Money Inserted] < Tariff
Idle
[Money Inserted]  Tariff
[Song Info Sent]
[Song Ends]
Ready
Query
[Song Info Request]
[Play Pressed]
Play
21
Conclusion
This project aimed to design a CJB, a Commercial Jukebox, using UML to determine the design
of the system and Microsoft SQL Server to create the code and database. The first step was to
do the interview to develop the system requirements and customer expectations for the
system. Basically what the system should do, how it works, and what kind of platform should
the system be under. The next step is to create some information about the database -- which
includes an ER Diagram that shows the tables for all the data members, the type of values in
the table, and how they interact and connect with each other. Then using that database full of
tables, information was created for those tables and 4 queries were implemented from the
customer requirements. The last step was to create some UML diagrams that model how the
system will work -- Use Case Diagrams, Class Diagrams, Sequence Diagrams, and State Machine
Diagrams. These UML diagrams and SQL code provide the basis for how the program will be
written when it comes time to program the actual system.
22