Jukebox Active Learning

1
Object-Oriented Software Development
By Rick Mercer with help from these
sources Computing Fundamentals with C, Rick
Mercer Designing Object Oriented Software,
Rebbeca Wirfs-Brock, Wilkerson,
Wiener Object-Oriented Design Heuristics, Arthur
Riel
2
Outline

• In the context of the Jukebox case study
• Analyze a specification
• Understand what the system should do
• Design a mode as a set of candidate objects, each
  with a well-defined responsibility
• Determine what can be done by The Date

3
The Problem Specification

• The student affairs office want 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.
• What a drag it would be to hear "I Honestly
  Love You" 14 times while eating lunch (apologies
  to Olivia Newton John)

4
What do we do next?

• We could do role-play (but won't)
• We could build the most minimal thing that works
  (good idea, but we're short on time)
• Figure out what is due next Monday
• Practical in this course and in industry
• First consider what needs to be done?
• Let's consider user stories

5
User Stories (Chapter 2)

• A user story
• Describes functionality that will be valuable to
  either a user or purchaser of a system or
  software
• Can be tests that document details
• You'll see some details as part of Project 1
• Can be a written description of the story used
  for planning and as a reminder
• represents a customer requirement rather than
  documents them
• Traditionally written on an index card, but I
  will use lines of text in these slides and
  Projects

6
Some user stories for Jukebox

• 1. A user can select a Song from the collection
• 2. Any song can be played up to 5 times per day
• 3. Can hear audio files play
• 4. Any user can play up to 2 songs per day

7
Others

• When originally planned, there were other user
  stories that seemed valuable to the students or
  anyone purchasing this system

8
Seem reasonable?

• 5. Notify Student the song is not selectable
• 6. The system should be able to queue songs on a
  FIFO basis
• 7. Show the play list (queue) to help users
  decide what to do
• 8. The system should be able to play mp3s
• 9. Have a nice GUI interface

9
Seem reasonable?

• 10. User can swipe card and find if successful or
  not
• 11. Students see their status
• 12. Students can see how long all songs in the
  queue would play
• 13. Administrator can add and remove Students
• 14. Administrator can add and remove songs

10
What can we do by 28-Aug _at_ 1000 pm, The Date?

• See Project 1, Iteration 1 at the end of lecture

11
Design a Model

• Try to find a set of things that model a solution
• Each thing should be a part of the bigger system
• Each thing should have a single responsibility
• What are these things?

12
1. Find the Objects

• Candidate objects may come from
• The problem statement
• An understanding of the problem domain
• knowledge of the system that the problem
  specification may have missed or took for granted
  
• The words floating around the room while
  analyzing the problem Alistair Cockburn

13
The Noun Phrases

• student affairs office
• activity fee funds
• jukebox
• money
• student center
• student
• student ID card
• card reader

• song
• song collection
• minutes
• Jukebox music
• academic careers
• date
• selection

14
OO Design Principle

• The Single Responsibility Principle
• Classes should have a single responsibility
• http//en.wikipedia.org/wiki/Single_responsibility
  _principle
• Why?
• Cohesion, if high reduces complexity, makes the
  system more understandable
• http//en.wikipedia.org/wiki/Cohesion_28computer_
  science29
• Maintenance Fixing or changing a module should
  not break other parts of the system

15
A First Cut at the Candidate Objects (may become
classes)

• Jukebox
• Student
• Song
• SongCollection
• Card reader
• Student ID card

16
Yesses

• Jukebox coordinates activities
• one instance to start things and keep them going
• JukeboxAccount (was Student) maintain one
  account a model a user that can select
• Song one song that can be played
• CardReader reads the magnetic ID card

17
A No

• StudentIdCard store user data
• Object-Oriented Design Guideline
• Eliminate classes that are outside the system
• The hallmark of such a class is one whose only
  importance to the system is the data contained in
  it.
• Student identification number is of great
  importance
• The system should not care whether the ID number
  was read from a swiped magnetic ID card, typed in
  at the keyboard, or "if a squirrel arrived
  carrying it in his mouth" Arthur Reil

18
More Candidate Objects?

• SongCollection songs to choose from
• What about storing a collection of accounts?
• JukeBoxAccountCollection
• What about a compact disk player?
• CdPlayer plays the songs
• could have a software equivalent to talk to this

19
Another No?

• StereoSystem Amplifies the music
• No, it's on the other side of the physical
  CdPlayer
• The next slide summarizes some needed candidate
  objects
• It also sets the boundaries of the system
• There are model of the real world objects

20
Candidate Objects and the system boundary
CardReader Gets student ID
JukeboxAccountCollection Stores all
JukeboxAccount objects
JukeboxAccount
JukeBox Coordinates activities
SongCollection Stores all Songs that can be played
Song
CdPlayer Plays a song