Music Case Study
By:
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
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.
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.
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.
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.
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.
· 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
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.
Task 3: ER (Entity Relationship) Diagram
Task 4: Testing Plan
Jukebox Test Cases:
Test Input Expected Output Actual Output
1 Check Library Check Library Opens Check Library Opens
2 Create Playlist Create Playlist Opens Create Playlist Opens
3 Update Library Update Library Opens Update Library Opens
4 Exit Program Quits 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 List All Tracks 5 Tracks 5 Tracks
2 01, Check Track How much is that doggy ... How much is that doggy ...
3 03, Check Track I'm dreaming ... - Ludwig ... I'm dreaming ... - Ludwig ...
4 05, Check Track Anarchy in the UK - The ... Anarchy in the UK - The ...
5 00, Check Track No Tracks No such track number
6 06, Check Track No Tracks No such track number
7 Null, Check Track No Tracks No such track number
8 'a', Check Track No Tracks 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).
Create Playlist Test Cases:
Test Input Expected Output Actual Output
1 01, Add Track 01 How much is that ... 01 How much is that ...
2 03, Add Track 03 I'm Dreaming of a ... 03 I'm Dreaming of a ...
3 05, Add Track 05 Anarchy in the UK 05 Anarchy in the UK
4 00, Add Track No Track No Track
5 06, Add Track No Track No Track
6 Null, Check Track No Track No Track
7 'a', Check Track No Track No Track
8 Play 0 Tracks No Change Crashed! Exception Raised
9 Play 1 Track 1 Track's Play Count + 1 1 Track's Play Count + 1
10 Play 3 Tracks 3 Track's Play Count + 1 3 Track's Play Count + 1
11 Play 1 Track x 3 1 Track's Play Count + 3 1 Track's Play Count + 3
12 Play 3 Tracks x 3 3 Track's Play Count + 3 3 Track's Play Count + 3
13 Reset 0 Tracks No Change No Change
14 Reset 1 Track Track Delete Track Deleted
15 Reset 5 Tracks All 5 Tracks 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.