cs 151: object-oriented design august 29 class meeting department of computer science san jose state...
TRANSCRIPT
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.
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
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!
_
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
4
A Good Design?
From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006.
Such a pretty diagram!
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
5
But It Doesn’t Scale!
From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006.
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
6
A Much Better Design after Encapsulation
From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006.
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
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).
_
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
8
Application Development Big Picture
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
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.
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
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!
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
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.
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
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
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
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._
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
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?
_
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
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?
_
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
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.
From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006.
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
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?_
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
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.
_
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
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.
_
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
20
Test the Requirements with Use Cases
From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006.
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
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._
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
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?
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
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
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
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.
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
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._
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
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.
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
27
New Requirement: Bark Recognition
From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006.
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
28
A Better Format
Make sure theuse cases make
sense to you,the developers.
From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006.
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
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.
From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006.
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
30
But Avoid ...
Paralysis by Analysis
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
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._
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
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
SJSU Dept. of Computer ScienceFall 2013: August 29
CS 151: Object-Oriented Design© R. Mak
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.