Software Development

1
Software Development
By Rick Mercer with help from these
sources Rational Unified Process Computing
Fundamentals with C, Rick Mercer Designing
Object Oriented Software, Rebbeca Wirfs-Brock,
Wilkerson, Wiener Object-Oriented Design
Heuristics, Arthur Riel
2
Software 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

3
One ApproachWaterfall

• Software go through several stages called the
  life cycle
• Waterfall model popular way to organize
  activities

4
Waterfall Model
5
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 book1 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

6
Iterative Software Development

• An iteration deals with a small part of the
  system

7
Rational 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 processes
• http//www-306.ibm.com/software/awdtools/rup/

8
A 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)

9
Analysis Tools we'll use or 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

10
Design Tool 1 we'll useResponsibility 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 first
• 3. Understand the system through role play
• To help complete its responsibility, an object
  often needs help from other objects

11
Design Tool 2 we'll useTest 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

12
Project 2The 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

13
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 "Dancing Queen"
  14 times while eating lunch (apologies to ABBA)

14
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)
• We could model this with objects
• We could start coding
• First consider what needs to be done and write
  them as user stories

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

16
Some User Stories for the Cashless 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
• 5. Can find a user by a given ID

17
Other Stories?

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

18
Do These 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. Have a nice GUI interface
• 9. User can swipe card

19
Seem reasonable?

• 10.Students see their account status
• 11.Students can see how long all songs in the
  queue would play
• 12.Administrator can add and remove Students
• 13. Administrator can add and remove songs
• 14. Use this for unmanned WebRadio
• 15. The system should be able to play mp3s

20
What can we do by THE DATE 12-Sep_at_1100 pm when
system is needed (2nd iteration is due)

• We have 2 weeks, model first
• GUI in iteration 2
• See Stories (requirements) that need to be told
  linked as Project 2, Iteration 1or 2_1

21
Design 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?

22
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)

23
1. 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

24
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

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

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

26
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

27
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

28
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

29
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

30
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

31
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
32
Unit Tests and Classes in Iteration 1?

• Song
• SongCollection
• SongPlayer (wait till Tuesday)
• JukeboxAccount
• JukeboxAccountCollection