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

• Specifications may be incomplete
• Software product is expected to be used 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

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 a two-study, 87 of all investigated 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 is a small part of the entire 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 (Kent Becks eXtreme
  Programming), mid 1990s
• Teams often choose from a set of practices
• A few Agile practices we are or will be using
• Planning game stories, estimation, iterations
• Test Driven Development (TDD)
• Pair Programming
• Continuous Integration
• Sustainable Pace (determine velocity would be
  nice)
• Coding Style (use the same style as team whether
  you like it or not)
• On-site customer (simulated)

9
Responsibility Driven Design
Responsibility Driven Design, Rebecca Wirfs
Brock, 1990The 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
10
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.Responsib
  le able to answer for one's conduct and
  obligationstrustworthy, Merriam Webster

11
Responsibility Driven DesignSummarizing Rebecca
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

12
OO Design Principle

• The Single Responsibility Principle
• Classes should have a single responsibility
• http//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_
  science29
• Maintenance Fixing or changing a module should
  not break other parts of the system

13
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?

14
Find the Objects

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