7-1

Software DevelopmentSoftware Development

By Rick Mercer with help from these sources:Rational Unified ProcessComputing Fundamentals with C++, Rick MercerDesigning Object Oriented Software, Rebbeca Wirfs-Brock, Wilkerson, WienerObject-Oriented Design Heuristics, Arthur Riel

7-2

Software ChallengesSoftware Challenges

♦Specification may be incomplete♦Software product is expected to be used for for a

long time ♦Ever more complex systems, high expectations♦Requirements change♦We don't know what the customer wants♦The customers don't know what they want

7-3

One Approach:One Approach:WaterfallWaterfall♦ Software go through several stages called the life cycle♦Waterfall model: popular way to organize activities

7-4

Waterfall ModelWaterfall Model

7-5

Waterfall Model (con.)Waterfall Model (con.)

♦ Waterfall has some severe problems. — The team has to be almost clairvoyant little room for error— places the high risk and difficult elements towards the end

♦ Craig Larman's book[1] provides proof that waterfall has proved to be a terrible way to develop software. — In one study, 87% of all projects failed — The waterfall process was the "single largest contributing factor for

failure, being cited in 82% of the projects as the number one problem." • Rick will now attempt to tell a joke

[1] Agile and Iterative Development: a Manager's Guide, Addison-Wesley Professional, 2003

7-6

Iterative Software DevelopmentIterative Software Development

♦An iteration deals with a small part of the system

7-7

Rational Unified ProcessRational Unified Process

♦Practices of RUP— Develop iteratively— Manage changing requirements— Use components such as Java classes— Visually Model with UML— Continuously test

♦RUP allows you to select from many processeshttp://www-306.ibm.com/software/awdtools/rup/

7-8

A Process we'll useA Process we'll use

♦Agile Manifesto See http://agilemanifesto.org/♦Started with Scrum and XP, around 1995♦Teams often choose from a set of practices♦Use these Agile practices for the next project

— Planning game: stories and estimation— Test Driven Development (TDD)— Short Releases— Sustainable Pace (two iterations)— Coding Style (use default preferences)

7-9

Analysis Tools we'll use Analysis Tools we'll use or are in this ppt fileor are in this ppt file

♦Nouns (objects) Verbs (operations)♦Scenarios

— what happens when…♦Role Play

— team members become objects and do scenarios♦Candidate Object / Responsibility / Collaborator

(CRC) cards— document candidate objects, assign responsibilities,

consider associations between objects

7-10

Design Tool #1 we'll useDesign Tool #1 we'll useResponsibility Driven DesignResponsibility Driven Design

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

• less important at first3. Understand the system through role play

— To help complete its responsibility, an object often needs help from other objects

7-11

Design Tool #2 we'll useDesign Tool #2 we'll useTest Driven DevelopmentTest Driven Development

♦TDD turns traditional development around — Write test code before the methods— Do so in very small steps — Refuse to add any code until a test exists for it

♦You can run the test anytime— And you should do so quite often

♦Design consists of writing the class, the methods, and the code

7-12

Project 2:Project 2:The Cashless JukeboxThe Cashless Jukebox

♦Coming up:— Analyze the problem specification— List some user stories (requirements)— 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 decision— Consider some design heuristics

7-13

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)

SpecificationSpecification

7-14

What do we do next?What do we do next?

♦We could do role-play♦We could build the most minimal thing that

works (good idea, but we're short on time)♦We could model this with objects♦We could start coding♦First consider what needs to be done and write

them as user stories

7-15

User StoriesUser 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 are included as line of text • in the slides that follow and• in the project specs online

♦User stories are a placeholder for future conver-sations among the user, customer, and developer

7-16

Some User Stories for the Cashless Some User Stories for the Cashless JukeboxJukebox

1. A user can select a Song from the collection2. Any song can be played up to 5 times per day3. Can hear audio files play4. Any user can play up to 2 songs per day5. Can find a user by a given ID

7-17

Other Stories?Other Stories?

♦When originally planned, there were other user stories that seemed valuable to the students and paying for this system

7-18

Do These Seem Reasonable? Do These Seem Reasonable?

5. Notify Student the song is not selectable6. The system should be able to queue songs on a FIFO basis7. Show the play list (queue) to help users decide what to do8. Have a nice GUI interface9. User can swipe card

7-19

Seem reasonable?Seem reasonable?

10. Students see their account status 11. Students can see how long all songs in the queue would

play12. Administrator can add and remove Students13. Administrator can add and remove songs14. Use this for unmanned WebRadio15. The system should be able to play mp3s

7-20

What can we do by What can we do by THE DATE THE DATE ??

♦ You have 16.08 days Iteration 1: The Model due Thu 16-Sep 19:00 Iteration 2: The View Thu 23-Sep 19:00

♦ Stories (requirements) that need to be implemented in Iteration 1: The Model

• See project spec

7-21

Design a ModelDesign a Model

♦Try to find a set of object that model a solution♦Each will be a part of the bigger system♦Each should have a single responsibility♦What are these objects?

7-22

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 The Problem Specification repeatedrepeated

7-23

1. Find the Objects1. 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

— Discovering abstractions— 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

7-24

The Noun Phrases 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

7-25

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

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

7-26

OO Design PrincipleOO Design Principle

The Single Responsibility Principle Classes should have a single responsibilityhttp://en.wikipedia.org/wiki/Single_responsibility_principle

♦Why?— High cohesion reduces complexity, makes the

system more understandablehttp://en.wikipedia.org/wiki/Cohesion_%28computer_science%29

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

7-27

YessesYesses

Jukebox: coordinates activitiesone 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

7-28

A NoA No

StudentIdCard: store user data

Object-Oriented Design GuidelineEliminate 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

7-29

More Candidate Objects?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

7-30

Another No?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

7-31

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

7-32

Unit Tests and Classes in Iteration 1Unit Tests and Classes in Iteration 1

♦Song♦SongCollection♦SongPlayer (wait till Thursday) ♦PlayList (so all songs to played FIFO)♦JukeboxAccount♦JukeboxAccountCollection