13/30/98

CSE 143

Object-Oriented Design[Chapter 10]

23/30/98

Design Process The traditional development model consists of

three phases: Analysis - defining the problem (what) Design - the solution (high level) Implementation - the solution (code)

Traditional development is sometimes called the waterfall model.

Analysis Design Implementation

33/30/98

Traditional DevelopmentIn this course, the problem is usually pretty well defined. We often suggest a design and ask you to provide an implementation.

Most of the time, development isn’t so easy…Analysis or design may be poorGoals may change during developmentImplementation may be too hard or take too longTesting?Social, political, economic factors

43/30/98

Design Methodology Changes may result in lots of wasted work! How

to minimize their impact? Use a good design methodology Procedure and structure by which a design is created

Top-Down Design, aka structured design Focus on overall control flow rather than data. Think of problem in terms of functions and algorithms

and how they need to interact Often have a layered or hierarchical approach: make

successively more detailed refinements to design

53/30/98

Top-Down Design Advantages and disadvantages?

Usually gives very structured approach to problemFirst input is read, then processed, then results are printed, etc.

Adapts well to analysis, design, implementation phases

If right breakdown is chosen, everything works OKEach function does one thing and is separated from others

What happens if a bad decision was made?Not easy to fix without rewriting a lot of code

What happens if design needs to be changed?

63/30/98

Problems and alternativesThe traditional design model has shown itself to be insufficient for many real world tasks

cf. C-17, Air Traffic Control SystemAlternatives:

Iterative software development modelsrapid prototyping, exploratory programming (requires higher-level programming languages)

participatory designobject-oriented design

Need to involve the user early in the process.

73/30/98

Object-Oriented Design Alternate design philosophy. Instead of control flow, concentrate on entities

(“objects”) in the problem (data-driven approach) Object = Collection of data and operations on

that data All phases of design are in terms of objects

Lends consistency across phases without arbitrary breakdown between ideas and implementations

More relaxed, iterative, three-phase approach: Can prototype a design or implementation and adapt it

to changing needs relatively easily (true?)

83/30/98

OO Design (2) What about changes?

Should be localized to a single object, or operations of objects, not spread out across lots of functions

What about bad decisions? Hopefully, changes will be restricted to objects instead

of functions

Ideally, objects are more reasonable way to think about problem than “flow control” is

Which approach is better? Depends on the problem, the people, etc...

93/30/98

Designing in the OO Style Identify the objects in the problem, and the

operations they should have What are the objects in the problem?

Determine organization of objects and operations How do the objects relate to one another? Are some contained inside another object, or need to

organize other objects? Drawing an object hierarchy diagram might help

Design a driver Implement objects (C++ classes, or off-the-shelf) Test and refine

103/30/98

What is an object?Metaphor: robot, daemonIn C++

A class instanceA variable of a built-in typeExamples:

ItemList I;

int c;

Bus b; // traffic simulation

DieselBus d;

ElectricBus e;

DualModeBus f;

113/30/98

What is an operation?Metaphor: a message which is sent to an object, requesting an action or service

Any action that manipulates dataExamples:

i++; // built-in operation

list.insertItem(. . .); // member function

strcmp(a, b); // global function

123/30/98

Objects and operationsFrom the problem statement:

nouns may suggest objectsverbs (and often adjectives) may suggest operations

Determining which nouns and verbs are important is difficult

Examples of nouns from a bank simulation:bank, customer, account,

accountNumber, balance, name, etc.

Example verbs:balance, deposit, withdraw, has, close

Adjectives:overdrawn

133/30/98

Object - BankCharacteristics

namelist of customerslist of accounts

Operationsopen an accountget the balance of an accountdeposit money into an account

143/30/98

Object - AccountCharacteristics

account numbertypebalance

Operationsopencloseget balancedeposit

153/30/98

Organizing the objectsRelationships among the objects

has-a relationship (e.g. a customer has a name)part-of relationship (e.g. an account number is part of the account)

Why do we need to determine the relationsips?Leads to natural ways to implement the designSuggest where to place the operations

163/30/98

Placing the operationsWho is responsible for this operation: Deposit an amount into an account.Account (object)Amount (object)Deposit (operation)

Compare these calls:account.deposit(amount);

amount.deposit(account);

deposit(account, amount);

Which is better? If you can’t assign primary responsibility, the function is probably global.

173/30/98

The DriverIn a well designed program, the driver (main) is the easiest part to write.

The driver program should do little more than process user commands and delegate tasks to the objects.

183/30/98

SummaryObject-oriented design typically results in layered software.

ADTs play a vital role in these layers of abstraction.

OO design helps in problem decomposition and aids in reuse.

Still to consider:inheritancepolymorphism