Prepare for your exams
Get points
Guidelines and tips
Sell on Docsity
Docsity AI

Prepare for your exams

Study with the several resources on Docsity

Earn points to download

Earn points by helping other students or get them with a premium plan

Guidelines and tips

Sell on Docsity

Docsity AI

Log in Sign up

Prepare for your exams

Study with the several resources on Docsity

Find documents

Prepare for your exams with the study notes shared by other students like you on Docsity

Search for your university

Find the specific documents for your university's exams

Docsity AINEW

Summarize your documents, ask them questions, convert them into quizzes and concept maps

Explore questions

Clear up your doubts by reading the answers to questions asked by your fellow students

Earn points to download

Earn points by helping other students or get them with a premium plan

Share documents

20 Points

For each uploaded document

Answer questions

5 Points

For each given answer (max 1 per day)

All the ways to get free points

Get points immediately

Choose a premium plan with all the points you need

Study Opportunities

Choose your next study program

Get in touch with the best universities in the world. Search through thousands of universities and official partners

Community

Ask the community

Ask the community for help and clear up your study doubts

Free resources

Our save-the-student-ebooks!

Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors

Lecture Notes on Oriented Programming and Design | CS 535, Study notes of Computer Science

San Diego State University (SDSU)Computer Science

Prof. R. E. Whitney

Material Type: Notes; Professor: Whitney; Subject: Computer Science; University: San Diego State University; Term: Fall 2003;

Typology: Study notes

Pre 2010

Uploaded on 03/28/2010

koofers-user-5di 🇺🇸

4

(1)

9 documents

1 / 22

This page cannot be seen from the preview

Don't miss anything!

November 13, 2003 Doc 16 OO Design Exploratory Phase slide #1

CS 535 Object-Oriented Programming & Design

Fall Semester, 2003

Doc 16 OO Design Exploratory Phase

References........................................................................................................................ 1

Overview of Design.......................................................................................................... 4

Exploratory Phase............................................................................................................ 6

Classes................................................................................................................. 6

Finding Classes........................................................................................ 6

Record Your Candidate Classes ............................................................... 7

Finding Abstract Classes.......................................................................... 8

Responsibilities.................................................................................................... 10

Identifying Responsibilities...................................................................... 11

Scenarios.................................................................................................. 12

Assigning Responsibilities....................................................................... 14

Recording Responsibilities....................................................................... 17

Collaboration........................................................................................................ 18

Finding Collaborations............................................................................. 18

Examining Relationships Between Classes .............................................. 19

Common Collaboration Types ................................................................. 20

Summary of the Exploratory Phase...................................................................... 22

References

Wirfs-Brock, Designing Object-Oriented Software, chapters 1- 5

Discover Study notes of Computer Science San Diego State University (SDSU)

Partial preview of the text

Download Lecture Notes on Oriented Programming and Design | CS 535 and more Study notes Computer Science in PDF only on Docsity!

CS 535 Object-Oriented Programming & Design

 - Fall Semester,

References........................................................................................................................ Doc 16 OO Design Exploratory Phase
Overview of Design..........................................................................................................
Exploratory Phase............................................................................................................
- Classes.................................................................................................................
  - Finding Classes........................................................................................
  - Record Your Candidate Classes
  - Finding Abstract Classes..........................................................................
- Responsibilities....................................................................................................
  - Identifying Responsibilities......................................................................
  - Scenarios..................................................................................................
  - Assigning Responsibilities.......................................................................
  - Recording Responsibilities.......................................................................
- Collaboration........................................................................................................
  - Finding Collaborations.............................................................................
  - Examining Relationships Between Classes
  - Common Collaboration Types
- Summary of the Exploratory Phase......................................................................
Wirfs-Brock, Designing Object-Oriented Software , chapters 1- References

Words of Wisdom

The best laid schemes o' mice and men often go astray

Robert Burns (1759-1796)

There is always something to upset the most careful of human

calculations

Ihara Saikaku (1642-1693)

Overview of Design

Exploratory Phase

• Who is on the team?

What are the goals of the system?

What must the system accomplish?

What objects are required to model the system and

accomplish the goals?

• What are their tasks, responsibilities?

What does each object have to know in order to accomplish

each goal it is involved with?

What steps toward accomplishing each goal is it

responsible for?

• Who works with whom?

With whom will each object collaborate in order to

accomplish each of its responsibilities?

What is the nature of the objects' collaboration

These activities have an analysis flavor to them. Note the link between the

goals of the system and its objects. The state and behavior of an object

are derived, in theory, from the goals. ParcPlace has a design tool that

tracks this relationship. Select a goal, and the tool will list all the objects

required for that goal. Conversely, given any object, the tool will show you

the goal(s) it helps accomplish.

Overview of Design

Analysis Phase

Who's related to whom?

Determine which classes are related via inheritance

Finding abstract classes

Determine class contracts

Finding sub teams

Divide responsibilities into subsystems

Designing interfaces of subsystems and classes

Putting it all together

Construct protocols for each class

Produce a design specification for each class and

subsystem

Write a design specification for each contract

Record Your Candidate Classes

Record the class name on the front of an index card. One class per card. Write a brief

description of the overall purpose of the class. The front of the card will be filled in with

information as the design process continues. If you prefer to use some other medium (

1/2" by 11" sheets of paper, computer program) do so. The goal is a tool that will

enhance exploring the model. Once you are experienced with object-oriented design, you

may find better tools. However, while learning, it is hard to find a cheaper tool than index

cards. Even when you have a fancy case tool you might find yourself using these cards

to help with designing parts of programs.

Finding Abstract Classes

An abstract class springs from a set of classes that share a

useful attribute. Look for common attributes in classes, as

described by the requirement

Grouping related classes can identify candidates for abstract

classes

Name the superclass that you feel each group represents

Record the superclass names

Responsibilities

The knowledge an object maintains
The actions an object can perform

General Guidelines

Consider public responsibilities, not private ones

Specify what gets done, not how it gets done

Keep responsibilities in general terms

Define responsibilities at an implementation-independent level

Keep all of a class's responsibilities at the same conceptual

level

Identifying Responsibilities

Requirements specification

Verbs indicate possible actions

Information indicates object responsibilities

The classes

What role does the class fill in the system?

Statement of purpose for class implies responsibilities

Walk-through the system

Imagine how the system will be used

What situations might occur?

Scenarios of using system

Scenarios

Identifying Scenarios

Read the requirement specification from user's perspective

Interview users of the system

Normal ATM Scenario

The ATM asks the user to insert a card; the user inserts a card. The ATM accepts the card and reads its serial number. The ATM requests the password; the user enters "1234." The ATM verifies the serial number and password with the ATM consortium; the consortium checks it with the user's bank and notifies the ATM of acceptance. The ATM asks the user to select the kind of transaction; the user selects "withdrawal." The ATM asks the user for the amount of cash; the user enters "$100." The ATM verifies that the amount is within predefined policy limits and asks the consortium to process the transaction; the consortium passes the request to the bank, which confirms the transaction and returns the new account balance. The ATM dispenses cash and asks the user to take it; the user takes the cash. The ATM asks whether the user wants to continue; the user indicates no. The ATM prints a receipt, ejects the card and asks the user to take them; the user takes the receipt and the card. The ATM asks a user to insert a card.

Special Case ATM Scenario

The ATM asks the user to insert a card; the user inserts a card. The ATM accepts the card and reads its serial number. The ATM requests the password; the user enters "9999." The ATM verifies the serial number and password with the ATM consortium; the consortium checks it with the user's bank and notifies the ATM of rejection. The ATM indicates a bad password and asks the user to reenter it; the user hits "cancel." The ATM ejects the card and asks the user to take it; the user takes the card. The ATM asks a user to insert a card.

Lecture Notes on Oriented Programming and Design | CS 535, Study notes of Computer Science

Related documents

Partial preview of the text

Download Lecture Notes on Oriented Programming and Design | CS 535 and more Study notes Computer Science in PDF only on Docsity!

CS 535 Object-Oriented Programming & Design

Words of Wisdom

The best laid schemes o' mice and men often go astray

Robert Burns (1759-1796)

There is always something to upset the most careful of human

calculations

Ihara Saikaku (1642-1693)

Overview of Design

Exploratory Phase

• Who is on the team?

What are the goals of the system?

What must the system accomplish?

What objects are required to model the system and

accomplish the goals?

• What are their tasks, responsibilities?

What does each object have to know in order to accomplish

each goal it is involved with?

What steps toward accomplishing each goal is it

responsible for?

• Who works with whom?

With whom will each object collaborate in order to

accomplish each of its responsibilities?

What is the nature of the objects' collaboration

These activities have an analysis flavor to them. Note the link between the

goals of the system and its objects. The state and behavior of an object

are derived, in theory, from the goals. ParcPlace has a design tool that

tracks this relationship. Select a goal, and the tool will list all the objects

required for that goal. Conversely, given any object, the tool will show you

the goal(s) it helps accomplish.

Overview of Design

Analysis Phase

Determine which classes are related via inheritance

Finding abstract classes

Determine class contracts

Divide responsibilities into subsystems

Designing interfaces of subsystems and classes

Construct protocols for each class

Produce a design specification for each class and

subsystem

Write a design specification for each contract

Record Your Candidate Classes

Record the class name on the front of an index card. One class per card. Write a brief

description of the overall purpose of the class. The front of the card will be filled in with

information as the design process continues. If you prefer to use some other medium (

1/2" by 11" sheets of paper, computer program) do so. The goal is a tool that will

enhance exploring the model. Once you are experienced with object-oriented design, you

may find better tools. However, while learning, it is hard to find a cheaper tool than index

cards. Even when you have a fancy case tool you might find yourself using these cards

to help with designing parts of programs.

Finding Abstract Classes

An abstract class springs from a set of classes that share a

useful attribute. Look for common attributes in classes, as

described by the requirement

Grouping related classes can identify candidates for abstract

classes

Name the superclass that you feel each group represents

Record the superclass names

Responsibilities

General Guidelines

Consider public responsibilities, not private ones

Specify what gets done, not how it gets done

Keep responsibilities in general terms

Define responsibilities at an implementation-independent level

Keep all of a class's responsibilities at the same conceptual

level

Identifying Responsibilities

Requirements specification

Verbs indicate possible actions

Information indicates object responsibilities

The classes

What role does the class fill in the system?

Statement of purpose for class implies responsibilities

Walk-through the system

Imagine how the system will be used

What situations might occur?

Scenarios of using system