cs 151: object-oriented design september 3 class meeting department of computer science san jose...

CS 151: Object-Oriented DesignSeptember 3 Class Meeting

Department of Computer ScienceSan Jose State University

Spring 2013Instructor: Ron Mak

www.cs.sjsu.edu/~mak

SJSU Dept. of Computer ScienceSpring 2013: September 3

CS 151: Object-Oriented Design© R. Mak

2

Ye Olde Waterfall Model

Requirements

Design

Implementation

Testing



3

The Waterfall Model Make sure each phase is 100% complete and

absolutely correct before proceeding to the next phase.

Big Design Up Front (BDUF) Set requirements in stone before starting the design.

Otherwise, design work that is based on “incorrect” requirements would be wasted.

Spend extra time at the beginning to make sure that the requirements and design are absolutely correct.

The waterfall model has been mostly discredited. It doesn’t work! But it’s still commonly practiced.

Source: Wikipedia article on “Waterfall Model”

Requirements

Design

Implementation

Testing



4

Project Phases

Today we know that development is a series of iterations. Each iteration is a “mini waterfall” consisting of

design, code, and test. Advocates of Extreme Programming will say: design, test, code



5

Agile Software Development

Iterative and incremental development Each iteration is a “mini waterfall”:

plan (with new requirements) refine design add new code unit and integration testing

Iterations are short: days and weeks rather than months._

Requirements

Design

Implementation

Testing



6

Ways to Elicit Requirements

Interview the stakeholders But you need to know the right questions to ask! Be aware of cultural or political issues.

Joint Application Design (JAD) Multi-day workshop with stakeholders and developers

to hash out requirements.

Ethnography Developers “live with” the users to observe, learn, and

understand their world._



7

But …

Users don’t always know what they want! There must be an ongoing dialog among the developers,

the clients, and the users. There needs to be an iterative process:

Developers show something Clients and users validate Repeat

If the developers force the clients or users to come up with the requirements too soon ... They may make something up! Such requirements will most likely be wrong or incomplete.

_



8

Requirements Elicitation Tasks

Identify actors

Identify and document use cases Abstractions of actor-system interactions.

Identify functional requirements Extract functional requirements from the use cases.

Identify nonfunctional requirements Do this at the same time as when you’re identifying the

functional requirements (as embodied by the use cases). Nonfunctional requirements have as much impact

on the development and cost of the system as functional requirements.



9

Use Cases A use case describes how to achieve a single goal or

accomplish a single task. A complete sequence of actions or events. Primary sequence plus

alternate sequences (“exception paths”). A sequence is triggered by an actor. Focus on what the system must do, not how to do it.

Actors are external agents that interact or communicate with the system. actor = role abstraction An actor can be a person or another system.

A use case treats the system as a “black box”. ?



10

Example: Bank ATM System

Log incustomer

Display balance

Shut downATM

Start upATM

Log outcustomer

Withdrawcash

Operator

Customer

Bank

system boundary

actor

interaction

system

UML use case diagram

use cases



11

Example Use Case Description Name: Withdraw Cash

Goal: Customer withdraws cash from ATM.

Summary: A customer who has logged in can withdraw up to $500 cash in $20 bills.

Actors: The customer and the bank

Preconditions: The ATM has been started up.

See use case “Start up ATM”. The customer has inserted a valid bank card. The customer has entered a correct PIN.

What must be true before the use case can start.

verb object



12

Example Use Case Description, cont’d

Trigger: The customer selects the “Withdraw Cash” option.

Primary sequence:1. The system prompts the customer for the amount.

2. The customer chooses from a list of amounts or enters a amount.

3. The customer submits the amount.

4. The system dispenses the amount in $20 bills.

5. The bank deducts the amount from the customer’s balance.

6. The system displays the customer’s balance See use case “Display balance”.

At most about 10 steps.



13


Alternate sequences: 3.1 The customer entered an amount not a multiple of $20.

3.1.1 The system displays a message to the customer . 3.1.2. The system prompts the customer for a new amount.

3.2 The customer’s bank balance is insufficient. 3.2.1 etc.

Postconditions: The customer receives the desired amount of cash.

The amount is deducted from the customer’s account. The customer sees the new account balance.

OR: The customer receives no cash. The customer’s account is unchanged.

What must be true after the use case is done.



14


Nonfunctional requirements: The system responds to each customer input within 5 seconds. The system displays messages in either English, Spanish, or

Vietnamese.

Glossary customer = a person who wants to withdraw cash from the ATM. bank = a system that maintains customer accounts and balances. etc.

_



15

Use Case Guidelines

Use case names should be verb object. Each name should describe an achievable goal

(e.g., “Withdraw Cash”).

Keep use cases short, simple, and informal. Clients and users need to understand them. No GUI or implementation details.

When your use cases cover most possible scenarios of your application, then you have enough requirements to start design. Some use cases may cause you to add new requirements.

_



16

Assignment #1

Your team is going to write an application that where the computer plays the Rock-Paper-Scissors game with a human player. Note: You will not actually write this application

for this assignment.

A match consists of one or more throws: The number of throws per match is an input parameter.

Example: 20 throws per match For each throw, the human player inputs his or her choice

(rock, paper, or scissors) and then the computer responds with its choice.

Although the computer records the human’s choice, its own choice must not depend on knowledge of the human’s choice.

The computer keeps track of who wins each throw (or it’s a tie).



17

Assignment #1

Instead of entering his or her choice, the human can ask for the current score a help message

At the end of a match, the computer displays the number of throws won by the human the number of throws won by the computer the number of ties who is the winner of the match

See these links: http://en.wikipedia.org/wiki/Rock-paper-scissors http://www.nytimes.com/interactive/science/rock-paper-scissors.html



18

Assignment #1

Write a Function Specification for this application. It must contain, in this order: problem statement objectives functional requirements (at least 6) nonfunctional requirements (at least 3) use case diagram containing at least 3 use cases use case descriptions (at least 3)

Use case form:http://www.cs.sjsu.edu/~mak/CS151/assignments/1/UseCaseForm.doc



19

Assignment #1

Send as a Word document or a PDF to [email protected] Subject: CS 151 Assignment #1 team-name CC all the team members Team assignment (each team has one hand-in) Due Thursday, September 12 at 11:59 PM



20

Where Do Classes Come From?

Textual analysis Look for nouns and verbs in your use cases. Nouns classes

Some nouns are actors. Verbs methods Class names should be nouns in the singular form,

such as Inventory, Instrument, InstrumentSpec.

How will the classes support the behaviors that your use cases describe?

Focus on concepts, not implementation._



21

Categories of Classes

Things Examples: Instrument, InstrumentSpec

Agents Represent doers of tasks. Names often end in “er” or “or” Examples: Scanner, Paginator

Events and transactions Model records of activities that describe what happened in the

past or what needs to be done later Example: MouseEvent remembers when and where the

mouse was moved or clicked.



22

Categories of Classes

Users and roles Stand-in for the actual users of the application. Common in systems that are used by more than one person

or where one person needs to perform distinct tasks. Examples: Administrator, Reviewer

System Model a subsystem or the overall system being built. Typical methods: initialize, shutdown, read input

System interfaces and devices Interfaces to the host operating system, file system, etc.

Foundation Typically the built-in classes. Examples: String, Date



23

Class Responsibilities

Responsibilities correspond to verbs in the use cases.

Each responsibility should be owned by one and only one class.

Common mistakes: Assigning a responsibility to an inappropriate class. Assigning too many responsibilities to a class. Ideally, each class should have a single primary responsibility.

_



24

Class Responsibilities Example

class Automobile start() stop() changeTires() drive() wash() displayOilLevel() checkOil()

class Automobile start() stop() displayOilLevel()

class Driver drive()

class CarWash wash()

class Mechanic changeTires() checkOil()

Too many responsibilities!

A cohesive class does one thing really well and

does not try to be something else.



25

Class Relationships: Dependency

Class C depends on class D: Some method of C manipulates objects of D Example: Mailbox objects manipulate Message objects.

Dependency is asymmetric. The Message class is not aware of the existence of the

Mailbox class. Therefore, Message objects do not depend on Mailbox

objects.

Loose coupling Minimize the number of dependency relationships. Another way for a design to handle change.

_



26

Class Relationships: Aggregation

Class C aggregates class A: Objects of class C contains objects of class A

over a period of time.

A special case of dependency. The “has-a” relationship. Example: An Inventory object has a list of Instrument

objects.

Multiplicity 1:1 – Example: Each Person object has a single

StreetAddress object. 1:n – Example: Each Inventory object has an array of

multiple Instrument objects.



27

Class Relationships: Inheritance

Class C inherits from class S. The “is-a” relationship. All class C objects are special cases of class S objects. Class S is the superclass of class C. Class C is a subclass of class S. An object of class C is an object of class S.

Note Aggregation: A Mailbox object has a Message object. Inheritance: A ForwardedMessage object

is a Message object._

cs 151: object-oriented design september 3 class meeting department of computer science san jose...

Documents

use casesa use case

bdufset requirements

incorrect requirements

design work

mini waterfall

big design

system interactions

users validaterepeatif