University of Arizona



The Cashless Jukebox Model

Iteration 1: Due Tuesday 14-Feb-2012 @ 6:00pm to D2L DropBox JukeboxModel

Collaboration: Both iterations of the Cashless Jukebox are to be completed with one other student registered in C Sc 335, Spring 2012

Project 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.

Begin with this zipped Eclipse project that can play audio files including mp3s (or find you own way to play mp3s:

Stories (features) to be Constructed During Iteration 1: The Model

1. A user can select a Song from the song collection 

      -- No GUI yet. Just have a way to iterate over all songs in order

2. Any song can be played up to 5 times per day

      -- No more than 5 on the same date, but the same song can play 5 times at any future date

3. Can queue up and play several audio files (au, aif, wav, mp3s)

     -- Play songs in order, completely, short pause between, no overlapping 

4. Any user can play up to 2 songs per day

     -- No more, but the same user can play 2 songs at a future date (if they have time remaining)

5. Can find a user by a given ID

     -- No GUI yet, the collection is searchable somehow with a String ID

Grading Criteria, 100 pts, Subject to Change  

____/ 15 Song  

+3 A unit test exists for Song

+3 You have a good test for songs playing 5 times max per day

+3 Know if a Song can be played (5 max per day)

+3 Each song knows the file name associated with it (directory not needed)

+3 Song implements Comparable (Java 6 style, with a type parameter). The Songs must be sortable by Artist first and then by Title. For example, if you have a two argument constructor, "Beatles A Hard Day's Night" should precede "Beatles Help" in the natural ordering defined by compareTo:

Song s1 = new Song("Beatles", "A Hard Day's Night");

Song s2 = new Song("Beatles", "Help");

assertTrue(pareTo(s2) < 0);  // 'A H...' < 'Hel...'

assertTrue(pareTo(s1) > 0);  // 'H' > 'A' 

assertTrue(pareTo(s1) == 0); // 'A' == 'A'

____/ 15 SongCollection  

+3 A good unit test exists for SongCollection

+3 There is only one reference to any one Song in the collection (it's a set)

+3 Song Collection implements javax.swing.ListModel

+3 The Song reference at index 0 precedes others alphabetically (it's sorted)

+3 SongCollection always has at least these five Songs at construction (distributed with starter project).

Hard code them in a private helper. We will not have any adds or removes in this project.

• bottle-open.wav, Sun Microsystems, time to play is 0:03 (3 seconds)

• DeterminedTumbao.mp3, Freeplay, 0:16 (16 seconds)

• spam_song.au, Monty Python, 0:30

• SwingCheese.mp3, Freeplay, 0:16

• tada.wav, Microsoft, 0:02

____/ 15 PlayList 

+20 You have a file named Play5Songs.java in the test package with a main method to play the required five songs in a FIFO order with no overlap and a second or two between. Thread.sleep(1000) pauses applications for 1 second. Note: You might want to work on this early.

____/ 15 JukeboxAccount 

+3 A good unit test exists for JukeboxAccount

+4 Be able to debit correctly. See specification that states the student can only have 1500 minutes and

only play two songs on any one given date. 

+4 Student knows if it can play a song even when running for many days

+4 Unit test for has test methods for each method

____/ 15 JukeboxAccountCollection

+4 A good unit test exists for JukeboxAccountCollection

+4 Can store a collection of JukeboxAccount objects with unique IDs (no duplicate IDs allowed)

+4 Can find a JukeboxAccount by ID

+3 The following IDs are all that is needed to successfully verify a user and are established at construction (hard coded): Casey, Carson, Chase, and Chris

 

____/ 25 General

+5 Eclipse project and .zip file are both named like this: JB_MyLastName_PartnerLastName

+5 model, view, test packages exist and each package contains the appropriate types

+15 Used good Design and Style

• Maintainable (readable code) (3pts)

• Each class has a single responsibility (3pts)

• Each class has your name and a description of its responsibility as comments (3pts)

• Class names begin with an UpperCase letter (2pts)

• All method and variable names begin with a lowerCase letter (2pts)

• There are no unanticipated errors or breeches of good style or design (2pts)

o examples: non private instance variables, using instance variables where locals would be better, code not formatted consistently, using == to compare strings...

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download