1. Outline Derive some user stories for next Project
Consider Responsibility Driven Design
Design a solution as a set of candidate objects with well-defined responsibilities
Role play different scenarios to understand the problem and help make design decisions
Assign responsibilities, which is the most important part of OO Design
Consider some design guidelines

2. User Stories Much taken from
User Stories Applied: For Agile Software Development
Mike Cohn Mountain Goat Software

3. User Stories
Agile Process such as Scrum and Extreme programming (XP) introduced the practice of expressing requirements in the form of user stories
A user story is a short descriptions of functionality–told from the perspective of a user–that are valuable to either a user of the software or the customer of the software

4. A few Example User Stories
The following are typical user stories for a job posting and search site:
A user can post her resume to the web site
A user can search for jobs
A company can post new job openings
A user can limit who can see her résumé

5. User Stories
A user story describes functionality that will be valuable to either a user or purchaser of the system
User stories are traditionally written on an index card when the team and customers are communicating
They will be written now as a line of text
in the slides that follow, and
in the project specification

6. Aspects of a User Story A user story can provide three things:
Written description of the story, used for planning and as a reminder
Placeholder for future conversations among the user, customer, and developer
User: You, me, section leaders, maybe you can sell it?
Customer: Rick
Developer: You
Tests that convey and document details that can be used to determine when a story is complete

7. In team of 2, write three user stories for the Cashless Jukebox we'll collate them in 5 minutes live
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 "Dancing Queen" 14 times while eating lunch (apologies to ABBA)

8. User stories for the Cashless Jukebox
One example
Any song can be 5 times per day at most

9. Other Stories?
In the past, other user stories seemed valuable to the students and the customer
We will some, eliminate others intentionally small font:
A user can select a Song from the collection of songs
Songs can be played up to 5 times per day
User can hear audio files play
Any user can play up to 2 songs per day
Jukebox can find a user given an ID
Notify Student the song is not selectable
The system should be able to queue songs on a FIFO basis
Show the play list (queue) to help users decide what to do
Have a nice GUI interface
User can swipe card
Students see their account status
Students can see how long all songs in the queue would play
Administrator can add and remove Students
Administrator can add and remove songs
Use this for "WebRadio"
The system should be able to play mp3s

10. Responsibility Driven Design
Responsibility Driven Design, Rebecca Wirfs Brock, The Coffee Machine Design Problem, Alistair Cockburn, C/C++ User's Journal, May and June 1998.
Introducing Object-Oriented Design with Active
Learning, Rick Mercer , Consortium for Computing in
Small Colleges, 2000

11. In Rebecca Wirfs Brocks' Words
Responsibility-Driven Design is a way to design that emphasizes behavioral modeling using objects, responsibilities and collaborations. In a responsibility-based model, objects play specific roles and occupy well-known positions in the application architecture. Each object is accountable for a specific portion of the work. They collaborate in clearly defined ways, contracting with each other to fulfill the larger goals of the application. By creating a "community of objects", assigning specific responsibilities to each, you build a collaborative model of our application. Responsible: able to answer for one's conduct and obligations—trustworthy, Merriam Webster

12. Responsibility Driven Design in Rick's words
1. Identify candidate objects that model a system as a sensible set of abstractions
2. Determine the responsibility of each object
what an instance of the class must be able to do,
and what each instance must know about itself
3. Understand the system through role play
To help complete its responsibility, an object often needs help from other objects

13. OO Design Principle The Single Responsibility Principle
Classes should have a single responsibility
Why?
Cohesion, when high, reduces complexity, makes the system more understandable
Maintenance: Fixing or changing a module should not break other parts of the system

14. First Design a Model Note: design is iterative
Find a set of objects (candidate classes) that model a solution
Each will be a part of the bigger system
Each should have a single responsibility
What are these objects?

15. Find the Objects Candidate objects may come from
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 Alistair Cockburn
The nouns in the problem statement
Underline the noun phrases to look for the objects that could model the system

16. The Problem Specification repeated
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 "Dancing Queen" 14 times while eating lunch (apologies to ABBA)

17. A First Cut at the Candidate Objects (may become classes)
What objects effectively model the system? What is the responsibility, Example
Song: Know song title, artist, playtime, how often it's been played today
Others?

18. Yesses Jukebox: coordinates activities
one instance to start things and keep them going
JukeboxAccount changed from Student: maintain one account: model user who play songs
Song: one song that can be played
CardReader: reads the magnetic ID card

19. A No Object-Oriented Design Guideline
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

20. More Candidate Objects?
SongCollection: songs to choose from
What about storing a collection of accounts?
JukeBoxAccountCollection
What about a compact disk player?
Could have a software equivalent like SongPlayer to play audio files?

21. Date Date: Can determine when a song is played and the current date.
Maybe
Can we use use java.util.GregorianCalendar?
Could we use class Usage?

22. Another No? The next slide summarizes some needed candidate objects
StereoSystem: Amplifies the music
No, it's on the other side what we have to build
The next slide summarizes some needed candidate objects
It also sets the boundaries of the system
There are model of the real world objects

23. 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
SongPlayer
Plays a song

24. Role Play Need 7 volunteers to play the roles of these objects
You must be willing to write down responsibilities as they are discovered on the whiteboard
These are potential methods
Should be related to encourage high cohesion
Should have meaningful names
When done, form teams of 2 or 3 and complete a class diagram
We'll check it if you want, do not turn in these