1 / 26

ICS23 A problem-based collaborative approach

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

alicia
Download Presentation

ICS23 A problem-based collaborative approach

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related