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

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)

In team of 2, write three user

stories for the Cashless Jukeboxwe'll collate them in 5 minutes live

8

User stories for the Cashless

Jukebox

One example

1. 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:1. A user can select a Song from the collection of songs

2. Songs can be played up to 5 times per day

3. User can hear audio files play

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

5. Jukebox can find a user given an ID

6. Notify Student the song is not selectable

7. The system should be able to queue songs on a FIFO basis

8. Show the play list (queue) to help users decide what to do

9. Have a nice GUI interface

10. User can swipe card

11. Students see their account 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

15. Use this for "WebRadio"

16. The system should be able to play mp3s

10

Responsibility Driven Design

Responsibility Driven Design, Rebecca Wirfs Brock, 1990

The Coffee Machine Design Problem, Alistair Cockburn, C/C++ User's

Journal, May and June 1998.

Introducing Object-Oriented Design with ActiveLearning, Rick Mercer , Consortium for Computing inSmall 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 Designin 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 responsibilityhttp://en.wikipedia.org/wiki/Single_responsibility_principle

Why?

— Cohesion, when high, reduces complexity, makes the system more understandable

http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29

— Maintenance: Fixing or changing a module should not break other parts of the system

14

First Design a ModelNote: 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 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)

The Problem Specification repeated

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 activitiesone 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

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?

22

Another No?

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

CardReaderGets student ID JukeboxAccountCollection

Stores all JukeboxAccount objects

JukeBoxCoordinates

activities

SongPlayerPlays a song

SongCollectionStores all Songs that can be played

JukeboxAccount

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