CS 151: Object-Oriented Design August 29 Class Meeting Department of Computer Science San Jose State University Spring 2012 Instructor: Ron Mak mak

CS 151: Object-Oriented DesignAugust 29 Class Meeting

Department of Computer ScienceSan Jose State University

Spring 2012Instructor: Ron Mak

www.cs.sjsu.edu/~mak

SJSU Dept. of Computer ScienceFall 2013: August 29

CS 151: Object-Oriented Design© R. Mak

2

Project Teams

Send as soon as possible to [email protected] Team name Team members (3 or 4 students per team) Team member email addresses

First team assignment will be next week.



3

Key Points from Last Time

Developing Great Software can be a messy business!

Be willing to admit you made some bad design decisions and fix them. The sooner the better!

_



4

A Good Design?

From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006.

Such a pretty diagram!



5

But It Doesn’t Scale!




6

A Much Better Design after Encapsulation




7

What Did We Encapsulate?

The original GuitarSpec class The varying properties of guitars.

Rick decided to add the number of strings to the original set of guitar properties.

The final InstrumentSpec class The varying properties of all the different types of instruments.

Guitar properties are different from trombone properties. Contains the properties in a hash map (hash table).

_



8

Application Development Big Picture



9

Analysis Precedes Design

Understand the problem. The application is no good if it doesn’t do what it’s supposed to do.

Gather requirements from the client. Client: the person for whom you’re writing the software Talk to Rick! Ask him what he wants the software to do.

Write a functional specification. Defines what the software is supposed to do, not how. Contains use cases. Understandable by both the client and the developers. The client may come up with new or modified requirements.

Create and demo a mockup of the application. The client may come up with new or modified requirements.



10

A Truly Messy Business

Clients often don’t know what they want. “I’ll know it when I see it.”

Eliciting requirements from a client is tough! Many iterations (multiple interviews with the client). Many show-and-tell sessions using application mock-ups. Many revisions to the functional specification.

Of course, a client can change his mind during design. Example: Rick decides to sell more types of instruments.

If you thought software design was messy ...

... analysis can be just as messy!



11

What is a Requirement?

A requirement is a specific task that your software application must do

in order to work correctly.

This is actually the definition of afunctional requirement.



12

Sources of Requirements

Client End users Software developers Development managers Technology providers

All can have conflicting ideas of what the application is supposed to do.

All of them change their minds about the requirements._

Stakeholders



13

Types of Requirements

Functional requirements What the system shall be able to do or allow users to do.

“The phone shall use GPS to determine the wearer’s location.” “Users shall be able to choose either Option A or Option B.”

Describe the interactions between the system and its environment, independent of its implementation.

Nonfunctional requirements Usability, reliability, performance, supportability, etc.

“The system must respond to the user within 15 seconds.” “The system must run on Windows and Linux servers.” “The new GUI should resemble the existing GUI.”

Constraints that the system must meet._



14

Requirements Must Have ...

Completeness Are all system features described by requirements?

Consistency No two requirements can contradict each other.

Clarity Each requirement must be unambiguous.

Correctness No errors in the requirements. Can each system function be traced to a requirement?

_



15

Requirements Must Have, cont’d

Realism Can the system be implemented?

Verifiability Can the system be tested?

Traceability Can each requirement be traced to a system function?

_



16

Example Application: Automated Dog Door

Todd and Gina hire your programming team to develop a dog door with a remote button so they can open the door from their bedroom when their dog Fido wakes them up in the middle of the night.




17

Initial Requirements

Push the button on the remote and open the door. Push the button again to close the door.

Do these requirements satisfy what Todd and Gina say they want?_



18

Get More Requirements

Interview the clients. Ask probing questions.

How tall is Fido? The door must be at least 12” tall.

How many buttons do you want on the remote? Only one that toggles between opening and closing the door.

Should the door close automatically after a while?

Developers should do brainstorming. Look at the problem from many points of view.

_



19

Stated and Implied Requirements

Stated by the client The door should be able to be opened remotely. The door should close after dog goes out.

Implied (what do you think?) The door should not close while the dog is going through it. The door should close automatically after a wait.

Also implied The clients want the application soon. It must be cost-effective.

_



20

Test the Requirements with Use Cases




21

What is a Use Case?

A complete sequence of steps that provides value to one of the actors.

Actor: Someone or something that is not part of your system. Todd, Gina, Fido You’re building a software application to implement an

automatic dog door, not simulations of people or dogs.

Describes something that your application must do. A single goal of your application.

Todd and Gina remotely let Fido out from their bedroom.

Initiated by an actor._



22

Parts of a Use Case

Name Verb-Noun (example: Let out the dog)

Description One or two paragraphs describing the purpose and goal.

Actors Who’s involved?

Preconditions What must be true before the use case can start?

Trigger What initiates the sequence of steps?



23

Parts of a Use Case, cont’d

Primary sequence Most common sequence of steps

Postconditions What must be true when the use case ends successfully?

Alternate sequences Variations of the basic flow Alternate triggers Alternate postconditions

Nonfunctional requirements Examples: performance, user interface

Glossary



24

Example Alternate Sequence

6. Fido does his business.

6.1 The door shuts automatically.

6.2 Fido barks to be let back inside.

6.3 Todd or Gina hears Fido barking (again).

6.4 Todd or Gina presses the remote control button.

6.5 The dog door opens (again).

7. Fido goes back inside.From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006.



25

Some Key Points for Success

The best way to get good requirements is to understand what the application is supposed to do. Make sure the application works the way the client wants it to

work, not necessarily how you would want it to work.

To be a successful developer, you must understand the application better than your client. Know exactly what the application needs to do. Be able to anticipate problems.

You won’t be successful if your application doesn’t do what the client wants. Use cases are a tool to help you figure that out,

before you start to do design._



26

The Only Thing that’s Constant ...

... in Analysis and Design is

CHANGE

Clients (and other stakeholders) change their minds about purpose and requirements.

Market conditions change. The environment changes.



27

New Requirement: Bark Recognition




28

A Better Format

Make sure theuse cases make

sense to you,the developers.




29

Did We Completely Analyze the Problem?

The Real World

DogDoor.java

The Perfect World

DogDoor.java

Make sure yourapplication will work in a real-world context.




30

But Avoid ...

Paralysis by Analysis



31

Good Use Cases

Write your use cases in a way that makes sense to all stakeholders (client, developers, managers, ...).

Good use cases show that you’ve done your analysis well and that your application will work in a real-world context._



32

The Functional Specification Clear problem

statement What is the

problem? Objectives

What is your application supposed to accomplish?

Functional requirements

Nonfunctional requirements

Use cases

Primary contents of aFunctional Specification



33

In Future Episodes

How do we go from analysis to design?So where do all those classes come from?

Read Chapter 2 of the Horstmann book.Always bring your laptop to class for any

potential online quizzes.

Documents

CS 151: Object-Oriented Design August 29 Class Meeting Department of Computer Science San Jose State University Spring 2012 Instructor: Ron Mak mak