ICS23 A problem-based collaborative approach

1. ICS23Aproblem-based collaborative approach Dennis Kibler kibler@ics.uci.edu http://www.ics.uci.edu/~kibler

2. 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

3. 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]

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

5. 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

6. What is a good program?

7. How can we achieve quality? • Correctness • Efficiency • Maintainability

8. 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

9. 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.

10. 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

11. 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

12. Object-Oriented Design 7th Grade shop Building a bird house or building the Hoover Dam

13. 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...

14. 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

15. 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

16. 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.

17. 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

18. 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

19. 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

20. 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)

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

22. 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.

23. 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);

24. 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.

25. 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.

26. 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