ICS23

A problem-based collaborative approach

Dennis Kibler

kibler@ics.uci.edu

http://www.ics.uci.edu/~kibler

Course Mechanics• Four homeworks, due mondays (except holidays)• Five Quizzes, lowest Quiz dropped• Final• Dishonesty = F + letter in file• Office hours: right after class and by appointment• Read newsgroup ics.23• Visit my webpage

Course Contents• Object-Oriented Design• Analysis• Data Structures

– lists, arrays, trees, balanced trees, hash tables, graphs

• Problem Solving Models– separate and conquer, divide and conquer [, dynamic

programming]

• Search Methods– exhaustive, [iterative deepening, greedy]

• [Gui Interfaces]

Problems with C/C++• What Errors are most costly?

C/C++ Problems• Syntax

– annoyance, compiler fixes

• array out of bound– can be very harmful

• Uninitialized variables– can be very harmful

• Memory leaks– very difficult to find

• Ptr manipulation– very difficult to find

• Java prevents all the expensive problems

What is a good program?

How can we achieve quality?• Correctness

• Efficiency

• Maintainability

Correctness• Proof technology

– provably impossible (usually)

– only for very small program

– research area

• Testing – provably incomplete (usually)

• Reuse– it worked before, it will work again

– other peoples classes

• Simplicity– simple methods, simple objects

Efficiency• Main Question: Does it Scale

– i.e. will it work on a bigger problem

– how much bigger

– So we measure it by...

• Run Time Complexity– O(n) notation analysis

• Space Complexity– amount of memory required, O(n) analysis

• Reuse– classes with documented complexities.

– Theory area devoted to finding best data structures and algorithms.

Maintainability• Large programs not written by one person

– need to divide labor and assign responsibility

• Useful program have long life times• Program goals change over time

– enhancements, feature-based programming

• Need code that is– simple to understand by others

– understandable by yourself, a year later.

• Practical answer– Objects

Why Java?• Java Language Goals

– fully object-oriented

– simple (not really)

– efficient (not too bad)

– supports reuse (Yes)

– supports team-programming

• Read Stroustrup (C++ Programming Language)– industrial support

– ease of learning

– ease of implementing

– usefulness

Object-Oriented Design

7th Grade shop

Building a bird house

or building the Hoover Dam

Object-Oriented Design• Understand the Problem

– write an concise English statement of what should be computed, not how it should be computed

• What vs How– understand What a radio does

– understand Interface to radio

• turn on/off, adjust station, adjust vol,….

– do not need to understand How (yet)

– Caveat: Need to guess that the task is doable

• Other examples:– automobile, thermostat, CD, TV, microwave...

Recipe for ODD• Identify objects

– concrete objects correspond to nouns in statements

• Identify methods of objects– methods correspond to verbs

• Identify attributes (can add as needed)– correspond to adjectives, such as color, size, etc

• Write Driver program– main program that constructs needed objects

– object code is not written

• After methods identified, select data structures based on properties

Problem: Electronic Telephone Book

• Vague statement: typical– users do not know what they want

– cycle: show and revise

• Step 1. English– what can we do with a telephone book

– how do we use a telephone book

• Rarely get design completely right on first try• Good designs are easy to modify/extend

English• Scenario Analysis

– What do you do with a personal telephone book?

• Questions/commands– Find the number of a person

– Add the number of a person (person-number)

– Delete the person-number pair

– Change the number of a person

– Optional: find address of a person.

What are the Objects• Telephone book• Questions/commands

– Find the number of a person

– Add the number of a person

– Delete the person-number pair

– Change the number of a person

• all objects have constructors• Usually objects have a method:

public String toString() • good for debugging

Identify Methods• Questions/commands

– Find the number of a person

– Add the number of a person

– Delete the person-number pair

– Change the number of a person

Identified Methods• Questions/commands

– Find the number of a person

– Add the number of a person

– Delete the person-number pair

– Change the number of a person

Moving towards code• Class TelephoneBook

– TelephoneBook() … empty constructor

– TeleNumber find(Person p)

– void add(PersonNumber pn)

– void delete(Person p) .. Deletes PersonNumber

– void changeNumber(Person p, TeleNumber n) ..

• “n” is the new number

– Alternatively:

• change(TeleNumber n) where change is a method on a PersonNumber(Entry)

Stubbed Class• Class TelephoneBook• { TelephoneBook()• { }• Address find(Person p)• { return null; }• void add(PersonNumber pt)• {} …• }• }• This will compile! But do nothing.

More classes• Class Person

– Person(String firstName, String lastName)

• Class TeleNumber– TeleNumber(String s)

• Class PersonTeleNumber– PersonTeleNumber(Person p, TeleNumber t)

• Stub these also, so all will compile.

Beginning Driver 1 import java.io.*;

Class Driver

{

public static void main(String[] args)

{

TelephoneBook tbook = new TelephoneBook();

Person p = new Person(“Dennis”, “Kibler”);

TelephoneNumber = new TelephoneNumber

( “(949) 012-3456”) );

PersonTeleNumber ptn = new PersonTeleNumber ( p,ptn);

Driver (2) tbook.add(ptn);

TelephoneNumber tn = tbook.find(p);

System.out.println(tn);

}

}

• If we try to compile this, it will fail.• There a number of methods that need to be

defined: add, find, toString for telephone numbers.

Top-Down Design• Know What should be computed• Know What are the inputs and expects outputs

Many designs are right. • First designs are usually wrong, but can be close.

– If program is complicated, design may be wrong

• Identify objects• Identify their methods• Write Driver using stubbed objects• Selected order of coding so that objects can be

tested.• Testing may involve extra code.

Bottom-up implementation• When designing, I assume I am smartest

programmer in the world. • When coding, I assume I’m the dumbest

programmer in the world.• Code in testable small pieces.• Try to keep program in running form.• If possible, write code to test each method.• If you can’t test methods separately, then

– your design may be wrong

– the program will be more difficult to change

– the program will be more difficult to get right