1 / 35

Data Structures Toolkit: Abstract Types, Algorithms, and Practical Programming

This course introduces the concepts of abstract data types, algorithms, and practical programming related to data structures. It covers various data structures like lists, queues, stacks, trees, and graphs, along with algorithms to implement and use these types. The course also explores additional Java topics such as exceptions, interfaces, and collections.

mstaley
Download Presentation

Data Structures Toolkit: Abstract Types, Algorithms, and Practical Programming

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. Introduction Ellen Walker CPSC 201 Data Structures Hiram College

  2. Data Structures • Toolkit for programmers • Abstract Data Types: List, Queue, Stack, Tree, Graph • Algorithms to implement and use these types • Practical Programming • Larger programs than CS 172 • More “independence” in design • Additional Java topics (exceptions, interfaces & implementations, collections…) • [ time management in programming ]

  3. What we won’t cover • In-depth analysis of algorithms related to data structures • Sorting and searching (except as it relates to specific data structures) • Advanced algorithms, especially those not tied to data structures • There is a 400-level course “Algorithms” that deals with these topics in depth

  4. Problem Solving • Algorithm • Step by step description of how to solve the problem • (Not enough by itself!) • Data structure • How the data is stored • Organized so that you can “operate on it easily as the algorithm requires” • Must be coordinated!

  5. Data Structures You’ve Used • Array - collection of data, all of the same type, accessible by index • Class - collection of data of many types, relating to a single object • Classes also include methods (functions) • String - sequence of characters • Appendix A (Introduction to Java) should be a review of material you learned in 172

  6. Software Life Cycle Activities • Requirements • Analysis • Design • Implementation • Testing • (Maintenance)

  7. Waterfall (unworkable!) Requirements Analysis Design Implementation Testing

  8. Unified Model • Project developed in “iterations” • Each iteration is a mini-waterfall • Depending on “phase”, different activities are emphasized • Allows loops: requirement -> analysis -> improve requirement -> more analysis -> design ->improve analysis …

  9. Unified Model Phases • Inception • Requirements, some Analysis • Elaboration • Requirements, Analysis, some Design & Testing • Construction • Design, Implementation, some Analysis, minimal Requirements, increasing Testing • Transition • Testing, some Implementation

  10. Requirements • Finding out what the client really needs • Generally a dialog with the client • Result is specific enough to take forward to…

  11. Analysis • Evaluate alternative approaches and make necessary decisions (e.g. off-the-shelf vs. custom design) • Refine requirements if necessary

  12. Design • Determine how the system will be organized and broken down into smaller parts for implementation • Top-down • Object-oriented

  13. Design vs. Implementation • Design • Determine what the pieces are (abstractions) • Determine how they fit together (interfaces) • Implementation • Translate pieces into (Java) code • Develop Java interfaces • Develop Java classes, including implementing algorithms

  14. Abstraction • Model of a physical entity or activity • Emphasizes what we need; “abstracts away” irrelevant complexity • Different abstractions of the same entity for different uses: • CAR, to a driver • CAR, to a mechanic • CAR, to a new-model designer • CAR, to an insurance agent

  15. Procedural Abstraction • Separating what a method does … • …from how it does it • Example: system.out.println() • Another example (assuming methods do what their names say): Circle Sun = new Circle(); Sun.setColor(“yellow”); Sun.draw();

  16. Advantages of Procedural Abstraction • Reducing complexity • Allowing code reuse • Easy to improve all code by improving a library method (as long as the what doesn’t change) • Example: substitute binary search for sequential search to make directory lookups faster

  17. Data Abstraction • Separate the “logical view” of data from the “physical view” of how it’s actually stored • Example: number • Logical view: the numeric value • Physical view: binary 2’s complement or floating point representation • Example: list • Logical view: sequence of elements • Physical view: exactly how and where those elements are stored, as well as any bookkeeping information

  18. Advantages of Data Abstraction • Same program can work on different underlying architectures • Programmer freed from dealing with representation issues • Except if they’re implementing the object itself (such as Integer or Double)

  19. Information Hiding • Clients (higher-level objects) can access data objects only through their methods • Clock.set (“01:00”); • Clock.addMinute(); //NOT Clock.minute++; • Illegal representations impossible • Changing implementations doesn’t break existing code

  20. Abstract Data Type • An abstract data type (ADT) encapsulates all relevant data items and methods • Includes data and procedural abstraction • Provides information hiding • Allows for reusable code ADT (data inside) (public methods)

  21. Interfaces & Implementations • An interface is an abstract specification for an object • Methods it provides • Parameters those methods take • An implementation is a class that includes methods specified by the interface • An instance is an actual object (created with new) • A client is a “higher-level” program that uses the implementation (knowing only the interface)

  22. Interface: Light Bulb Socket • Implementations (instances) • Clients (instances)

  23. Interface as Contract • Interface designer specifies methods and parameters (and what they mean) • Implementor promises to implement all specified methods • Java compiler enforces this (to a point) • Client must use methods as specified • No knowledge of implementation • Consider implementation can change tomorrow

  24. Specifying What a Method Does • Preconditions • True before the method runs (assumptions) • Example: “X is a positive number” • Postconditions • True after the method runs (results) • Example: “Y = 2X” • Contract • IF preconditions are true before, THEN postconditions are true after • When preconditions are false, all bets are off!

  25. Specification with Preconditions and Postconditions • Sort(anArray, num) • Sorts an array into ascending order • Precondition: anArray is an array of num integers • Num is positive • Num is less than the declared size of the array (MAXARRAY) • Postcondition: anArray is sorted into ascending order , i.e anArray[0] <= anArray[1] <= anArray[2]… <=anArray[num-1], elements beyond num are not affected, and num is the same as before…

  26. If we use a list instead… • Sort(aList) • Sorts a vector into ascending order • Precondition: aList is a list of objects that have a value that can be compared (i.e. have a compareTo method) • Postcondition : aList is sorted into ascending order , i.e each element is <= the following one

  27. What about search? • aSequence.Search (anItem) • Precondition • Postcondition

  28. Documentation • Write preconditions and postconditions as part of your documentation • You might as well write them first! • They are a “contract” - if you know these conditions, you can use a method without even looking at its source code!

  29. Conditions as Documentation /** Process a bank account deposit pre: amount is positive post: Adds the specified amount to balance */ Public void processDeposit(double amt){ balance += amt; }

  30. Assertions • Statements that must be true at a given point in the code • Preconditions & postconditions are special cases • Java provides “assert” function to test assertions in the code • Loop invariants are another kind of assertion…

  31. Assertions and Verification • Goal: given precondition and algorithm, prove the postcondition will happen • Technique: work backwards step by step from the postcondition, seeing what is needed… • Example: x=y+1, postcondition x=2 • Required precondition:

  32. Loop invariant • True before the loop begins (after initialization) • True before / after each iteration of the loop • True after the loop terminates • Usually, all variables that are changed by a loop are included in its invariant.

  33. Example: • Code int i=1 int x=2 while(i<n) x+=x; i++; • Invariant is: • Postcondition is:

  34. A Loop is Correct When… • The invariant is true before the loop. • The invariant is preserved through a single execution of the loop. • If the invariant is true and the loop exited, the postcondition is true. • The loop always terminates.

  35. Using Invariants • Determine invariants to understand existing code • Develop invariants during design • Aid in correct initialization • Aid in avoiding “off by one” errors • Document invariants in code (especially complex loops)

More Related