Requirements Change!

Chapter 3Object-Oriented

Analysis and DesignTom Perkins

Welcome!

• 10 (+) week book study

• Tom Perkins– tomperki@gmail.co

m

• Books available at Nerdbooks.com

• http://69.41.237.216/STUDYGROUPSIG/OOAD

Chapter 3 Topics• Review

– Good software– Use Cases

• The One Constant in Software Design• Todd and Gina’s Idea• The Bark Recognizer Scenario• A Revised Use Case• Introducing the Bark Recognizer Object• Updating the Dog Door Simulator• Doug’s Idea• Duplicate Code for the Timer?• Class and Code Walkthrus

Review (Chapter 1)3 Steps to Good Software

1. Make sure the software does what the customer wants it to do

2. Apply basic OO principles to add flexibility

3. Strive for a maintainable, reusable design

Review – Chapter 2

What is a Use Case?

A Use Case describes what your system does to accomplish a singular goal.

Focuses on “what”, not “how”

Single goal: different goal, different use case

Main path; alternative paths (can occur only some of the time)

Users outside the system: Gina, Todd, Fido

Dog door and remote inside the system

Formal Use Case: A technique for capturing the potential requirements of a new system or a software change. It provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific goal.

Scenario: a path through the use case that will result in the goal.

Your new programming job:

Doug’s Dog Doors

(High tech, automated dog doors)

Todd GinaFido

Your first CustomersWhat they want:

An automated, remote-

controlled

Dog Door barks !!!

want to push button to open door

No Problem

!!!

Todd and Gina’s Dog Door, Version 2.0 (Review)

Dog Door Use Case

1. Fido barks to be let out.

2. Todd or Gina hears Fido barking.

3. Todd or Gina presses the button on the remote control.

4. The dog door opens.

5. Fido goes outside.

6. Fido does his business..

6.1 The door shuts automatically.

6.2 Fido barks to be let in.

6.3 Todd or Gina hears Fido barking (again).

6.4 Todd or Gina presses button on remote control.

6.5 The dog door opens (again).

7. Fido goes back inside.

8. The door shuts automatically.

The One Constant in Software Design

Doug and Gina’s Idea

It (the dog door) is working great, but what if …

Fido

barks (Woof-Woof )!!!

Bark Recognizer Attachment

Dog Door Opens!

Fido barks

Recognizer hears Recognizer

Opens doorFido out, does

business

Fido back in

Door closes

All is well

Door shuts

Fido barks

Recognizer

hears

Recognizer opens door

Main path Alternate

path

Note: Todd and Gina are not in this picture

A Revised Use Case

Main Path

1. Fido barks to be let out

2. Bark Recognizer hears

3. Bark Recognizer send open request

4. Dog door opens

5. Fido goes outside

6. Fido does his business.

7. Fido goes back inside.

8. Dog door shuts automatically

Alternate paths:

2.1 Todd or Gina hears Fido

3.1 Todd or Gina presses remote control

6.1 Dog door shuts automatically

6.2 Fido barks

6.3 Bark recognizer hears bark

6.3.1 Todd or Gina hears

6.4. Bark recognizer requests

6.4.1 Todd or Gina presses remote

6.5 Dog door opens

Old Dog Door Object Walkthrus

• DogDoor• Remote• Simulator object• Walkthru

Dog Door with Bark RecognizerObject Walkthrus

• Recognizer object• Code Walkthru• But the door stays open!!!

Doug’s Idea!

Put a timer on it! Just copy the one in the remote!

Question: Duplicate the timer code in the Remote?

Better solution:

Put a single timer in the DogDoor class; remove the

remote timer.

DRY Principle (Don’t Repeat Yourself)

The Modified DogDoor Class

• Modify code• Run Simulator

In-class exercise

• Suppose it’s January in North Texas, and your car is parked overnight in your garage.

• Write a use case that would describe the process you go through in starting your car and backing it onto the street.

• Did you include any alternate paths? Does your car-starting experience always follow the “Happy Path”?