The Cashless Jukebox View

Iteration 2: Due Tuesday 21-Feb-2012 @ 6:00pm to D2L DropBox: Jukebox View

Specification: The student affairs office wants to put some newfound activity fee funds toward a Jukebox in the student center. The Jukebox must allow students to play a song. No money will be required. Instead, a student will swipe a magnetic ID card through a card reader, view the song collection and choose a song. Students will each be allowed to play up to 1500 minutes worth of "free" Jukebox music in their academic careers, but never more than two songs on any given date. No song can be played more than five times a day.

User Stories to implement in Iteration 2

Have a nice graphical user interface

User can select from the song collection in a graphical manner

The system queues songs in a first-in-first-out manner

Show the play list (the queued songs) to help users decide what to do

Students can see their account status

Students will know if the song is not selectable on the current date

The system is persistent--if the program is shut down and data is saved, the next program startup retrieves the most recent state of everything

Details

Users should be able to "login" with just their ID (this replaces swiping a CAT card)

Jukebox should have at least 5 songs to choose from

The user should be able to select songs from the list of songs.

Your system should be robust in that only one song is heard at a time, all songs play in their entirety, and there are no unreasonable pauses (pause about 1 to 2 seconds) between songs

Songs must be queued in a first in first out (FIFO) manner even if you select 5 songs in 5 seconds, you should hear all 5 play in their entirety in FIFO

A song can only be played 5 times maximum on the same Calendar date

A user can only play up to 2 songs maximum on the same Calendar date

The user see if any Song has been played the max times per day

The user is informed if they are not allowed to play a song

The user can see their status (time remaining, songs played today)

Grading Criteria for Iteration 2 Subject to Change

Subjective (27pts)
+9 Robust: Gracefully handles all inputs with appropriate responses: 0, 3, 6, or 9 pts (subjective)

+9 Usable: Interface is easy to work with it: 0, 3, 6, or 9 pts (subjective)

+9 Clear: Easy to see, hear, and understand what is happening at all times: 0, 3, 6, or 9 pts (subjective)

Help us (13pts)

+3 System begins with class RunJukebox.java in the view folder (please help us find how to start)

+3 You have your project separated into at least three Java packages

+3 You used meaningful identifiers

+3 Both team member names are on almost all file, even the test files.

+1 All code compiles (we do not have to correct any source code)

Functionality (60pts)

+5 User can "login" with just their ID (like a cat card swipe) and you have these four account Ids

Casey, Carson, Chase, and Chris (helps us grade)

+5 User knows when a Song has maxed out for the day (shows in the song list perhaps)

+5 After maxing out, the song can be played on a future date

+5 Can choose the same five Songs from Iteration 1

consider adding any three additional songs of your choosing a total of 8

+5 The Songs are shown in their natural ordering (by artist, then title), or in a Sortable JTabel

+5 Songs are played in a First In First Out (FIFO) out order

+5 The user is able to hear the selected song playing

+5 Each song plays in its entirety

+5 There is a 1 to 2 second delay between songs (need a little time, but not much)

+10 The system is persistent: remembers the current state of the system if desired.

+5 The user can exit with a save data, quit without saving, or cancel option