Data structures / collections

Data structures / collections

Data structures (informally:) By size: • Static (e.g. arrays) • Dynamic (e.g. vectors) By ordering: • Last In First Out (LIFO) • First In First Out (FIFO) • Priority

Data Structures • Types of dynamic generic data structures are: • Stacks • Queues • Lists • Trees

What is a Stack? • A stack is similar in concept to a pile of plates, books, blocks, boxes, etc. • The first item put on the stack is on the bottom of the stack. • All items added to the stack are placed on top of the previous item. • The last item put on the stack is on the top of the stack.

What is a Queue? • A queue is similar to waiting in line for a service, e.g., at the bank, at the bathroom • The first item put on the queue is at the front of the queue. • All items added to the queue are placed behind of the previous items. • The last item put on the queue is at the back of the queue.

Queues • Queues are called First-in First-out (FIFO) data structures. • The first person to enter the queue is the first person to be served, i.e., leave the queue. • The last person to enter the queue is the last one to be removed from it.

Queues • Characteristics of queues: • Data can only be placed at the back of the queue. • Data can only be removed from the front of the queue. • Data can only be removed from the rear of the queue if there is only one item on the queue. • Data can not be removed from the middle of the queue without first removing all items in front of it.

Queue Behaviors • The behavior of putting an item in the queue is called enqueue( ). • Enqueue 4 onto the queue. • The behavior of removing and item from the queue is called dequeue( ). • Dequeue 4 from the stack. (Remember this only works if 4 is in the front of the queue.)

Example • What queue exists after executing the following commands? • enqueue(3) • enqueue(6) • enqueue(8) • enqueue(1) • dequeue() • dequeue() • enqueue(14)

Queue Implementation • The ability to use a queue is not built into Java like arrays; nor is it available in util • You can implement a queue in many different ways, e. g. using a list or an array.

Queue Implementation • A queue class can be written using arrays that will simulate a queue in your programs. • A restriction of using arrays to implement a queue is that the total size of the queue is limited. • Why? • Can you define a method that will resize the array to hold a queue of any size?

Queue Implementation • Can you write a program to implement the Queue class that holds data of any data type? • How do we modify our queue implementation so that the queue will grow?

Palindrome Example • A program that determines if a word is a palindrome using a stack and a queue. • A palindrome is a word that is spelled the same both forwards and backwards.

Testing and debugging

Why testing and debugging? • Software development has a “black eye” • Schedules and time-to-market pressure • Reliability and warranty issues • Rising costs • New technology and market demands • Increased focus on security and safety • Poor results

What we know • We must shift the focus from detection to prevention. Learn to look for the root cause • Pareto Principle - 80% of the defects will cluster in 20% of the components or causes • The more rigorously tested at the front end, the more reliable at the back end

Fixing errors • Fixing defects is more error-prone than the original development. One in 4 fixes introduces another defect elsewhere • Finding and fixing defects • accounts for most of maintenance costs • accounts for 50% or more of typical development costs • introduces a new risk. Fixing a defect late in the cycle introduces a significant risk

Cannot rely on compiler to find ALL errors! • The number of errors at the first compile may be indicative of the number of defects still in code (Myers) • What can’t the compiler find? • Logical errors

What is Testing? • Testingis the process of finding errors in the system implementation. • The intent of testing is to find problems with the system.

What is Debugging? • Debugging is the process of finding the source of errors and fixing such errors. • Testing is done beforedebugging.

Why Test? • The purpose of testing is to identify implementation errors before the product is shipped. • The errors may be: • Actual bugs in the code. • Incorrect implementation of the requirements or functional specifications. • Misunderstandings • Incomplete requirements or functional specifications.

What Testing is not • Testing is not a random process. • There is a rhyme and reason to the process. • Testing is not debugging. • Testing identifies the problems. • Debugging finds the location of a problem and fixes the problem.

Who is responsible for Testing? • Multiple people are responsible for testing a system. • Initially the programmers are responsible for testing their implementation but this is not systems testing. • Usually a testing team will perform the majority of the tests, particularly at the system level. • The customer will also test the entire system. • Alpha and Beta testing.

Who is responsible for Debugging? • There is also a number of people who are responsible for debugging. • If there is a testing team responsible for testing the system, this team will also attempt to precisely identify the problem and report it to the appropriate programmer. • The programmer is responsible for determining the actual problem and repairing it. • The customer should not debug a system.

When does Testing begin? • Testing begins during the implementation phase. • The programmer is responsible for testing their unit to ensure the code meets the design and functional specifications. • As multiple units become available and can be combined, system testing can begin by the testing team. • It is not unusual for implementation and testing phases to overlap. This is particularly true with today’s shorter development cycles.

What is tested? • The system is tested by: • Units of the system. • In object oriented programming the classes would be tested. • Related units of the system. • The entire system.

How are Tests Passed? • A system passes the tests if it produces results that are consistent with the functional specification and requirements. • The program does what it is supposed to do. • The program does not do anything it is not supposed to.

How are Tests Passed? • If any single unit test fails, then the entire system is not correct. • If all unit tests pass, then there is a good probability that the entire system will work together.

Types of Testing • Formal verificationis a process that uses mathematical and logical assertions to prove that the program is correct. • Formal verification is difficult to do.

Types of Testing • Empirical testing is the process of generating test cases and running the tests to show that errors exist. • Empirical testing involves observing the results of using the system. • Empirical testing can only prove that an error exists. It can not prove that there are no errors. • There are two types of Empirical Testing: white boxandblack boxtesting.

Empirical Testing • White box testing: • Requires access to the actual implementation code. • Requires the development of test cases that will exercise each unit of the system, and possible “flows” through the system based upon the actual implementation. • All statements, all decisions, all conditions, and all inputs. • This type of testing is not very practical but sometimes it is required.

Empirical Testing • Methodologies that are used for White Box testing are: • Statement coverage • Decision coverage • Condition coverage • Decision/condition coverage • Multiple-condition coverage

Empirical Testing • Black Box Testing: • Typically a testing team develops use cases based upon the requirements and functional specification without looking at the actual implementation. • Tests valid and invalid inputs but can not possibly test all inputs. • Must determine what subset of inputs will sufficiently cover all inputs. • You want to break the system, it is your job with Black Box Testing.

Empirical Testing • Methodologies for Black Box Testing: • Equivalence partitioning: • A set of inputs that are processed identically by the program • Legal input values • Numeric/non-numeric values • Boundary Testing • Error Guessing

Testing Formal verification Empirical testing White Box testing Black Box testing • Statement coverage • Decision coverage • Condition coverage • Decision/condition coverage • Multiple-condition coverage • Equivalence partitioning • Boundary Testing • Error Guessing

Testing Statement Coverage • Statement coverage tests that each statement in the system is executed at least once by the test data. • Testing the statement coverage is necessary but is not sufficient.

Testing Statement Coverage • What problems can you find? Assume that a = 2, b = 2, and that x is properly defined and initialized. • if (a > 1) && (b == 2){ • x = x / a; • } • if (a == 2) || ( x > 1) { • x++; • }

Testing Decision Coverage • Testing for Decision Coverage requires testing every decision for both a true and false outcome.

Testing Decision Coverage a) Assume: a = 2, b = 2, x > 1 b) Assume: a = 1, b = 2, x = 0 • if (a > 1) && (b == 2){ • x = x / a; • } • if (a == 2) || ( x > 1) { • x++; • }

Testing Decision Coverage • Testing for Decision Coverage also tests for statement coverage in modern languages. • This is not true of languages that have multiple entry points, contain self-modifying code, etc.

Testing Condition Coverage • Testing Condition Coverage requires testing each possible outcome for every condition within a decision at least once. • The Decision Coverage testing we did only covered half of the cases in the previous example. • The cases are: • a > 1 (1) • b == 2 (2) • a == 2 (3) • x > 1 (4)

Testing Condition Coverage • Assume: a = 2, b = 2, x = 4 • Assume a = 1, b = 3, x = 1 • if (a > 1) && (b == 2){ • x = x / a; • } • if (a == 2) || ( x > 1) { • x++; • }

Multiple-Condition Coverage • Testing for Multiple-condition coverage requires test cases that test all possible combinations of condition outcomes for every decision tested. • This type of testing will generate many test cases.

Debugging • Debugging should be a formal process of attempting to narrow down the location of the problem and then identifying the problem. • Debugging does not mean simply changing code until the problem goes away. • Debugging requires thinking about what might be the problem.

Debugging • Methods of determining the location of a bug: • Use extra output statements in the program to trace the program execution. • Use a debugger to trace the program execution. • Possibly write special test code to exercise parts of the program in special ways that will allow you to better understand the error.

Debugging • Potentially test a certain range of values to see which ones fail. • Attempt to eliminate parts of the program as the problem, thus narrowing your search. • Check that the data is valid. • Many times, the location where you see the first instance of the bug is not the source of the bug.

Fixing Bugs • Steps for fixing bugs: • Fix only one bug at a time and then rerun the same exact tests. • Changing multiple things makes id difficult to identify which change caused the behavior change. • If the problem appears to be fixed, still run a full test suite to ensure the “fix” did not break something else.

General Rules to follow • Test your code as your write it: • Test the code boundaries. • Test pre- and post- conditions. • The necessary or expected properties before and after the code is executed. • Use assertions (if you are programming in C or C++) • Program defensively by adding code to handle the “can not happen” cases. • Check error returns

General Rules to Follow • Steps for Systematic Testing • Test incrementally by writing part of the system, test it, then write some more code, test that code, etc. • Test the simple parts of the system first. • Know what output you are expecting. • Compare independent implementations of a library or program provide the same answers.

General Rules • Ensure that testing covers every statement of the program. • Every line of the program should be exercised by at least one test.

Data structures / collections