1

Software DevelopmentSoftware 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 ChallengesSoftware 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 Approach:One Approach:WaterfallWaterfall

Software go through several stages called the life cycle Waterfall model

4

Waterfall ModelWaterfall Model

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 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 DevelopmentIterative Software Development

An iteration is a small part of the entire system

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/

8

A Process we'll useA Process we'll use

Agile Manifesto See http://agilemanifesto.org/ Started with Scrum and XP (Kent Beck’s 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 DesignResponsibility 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

10

In Rebecca Wirfs Brocks' WordsIn 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

11

Responsibility Driven DesignResponsibility Driven DesignSummarizing Rebecca in Rick's wordsSummarizing 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 PrincipleOO 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 understandablehttp://en.wikipedia.org/wiki/Cohesion_%28computer_science%29

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

13

First Design a ModelFirst Design a ModelNote: design is iterativeNote: 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 ObjectsFind 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