Download Chapter 1 Overview

CIS 112
Data Structures and
Algorithms
Lession 3
Program Specification, Design and Analysis
Specification - what a program
(function) is meant to do. (but not how it
does it)
Design - Select (create) the data
structures and algorithms to meet the
specification.
Analysis - tries to answer the
questions:
1. is the design correct?
2. is the algorithm efficient?
Program Specification
Describe what the program is intended to do. We
do this in terms of input, output and process.
This needs to be done as exactly as possible. If
the specifications are unclear, the solution to the
problem is impossible to determine.
Note: Specifications describe the what but not
the how.
Design the Solution
Algorithm - a precise set of instructions that leads
to a solution of the problem.
Pseudocode - a mixture of English and a
programming language that expresses the steps
necessary to code the algorithm. [This is an
abstraction. Like the specification, it describes what
happens but not how it happens.]
Data - is the information manipulated by the
algorithm.
Data Structure - a way to organize data.
Design (continued)
The first pass through the design process will typically
produce a design that is not detailed enough to
translate directly into a programming language.
We need to further break the problem down into
smaller units (sub-programs). The sub-programs
address one specific detail of the solution.
If a sub-program is still to complex, it may need to be
broken down again (and again) until it become trivial to
translate into a programming language.
Design (continued)
The process of breaking a larger problem into
smaller problems is called Decomposing
Problems.
The process of breaking a function into smaller
functions is referred to as functional
decomposition.
You should focus on one function at a time.
Once you complete a function's implementation,
you should concentrate what it does and "forget"
how it does it. This is called information hiding.
Design (continued)
Two common design models are:
Top down design - where we design from the top,
leaving the details to be filled in later. We use function
stubs to stand in for functions we have not yet
defined.
Bottom up design - where we design a lower level
function first, intending later, to "plug it into" a higher
level function. We use a test driver to set up enough
of the calling environment to test a lower level
function.
In practice, we use both models when writing a
Time analysis
Reasoning about the algorithm's speed.
As the size of the input increases, how
does the time the algorithm takes to reach a
solution increase?
This is a very practical real world concern.
Our choice of the implementation of the
algorithm and the representation of the data
and its structure impact the answer to this
question.
Testing and Debugging
Program testing occurs when you run a
program and observe its behavior.
Part of the science of software engineering
is the systematic construction of a set of test
inputs that is likely to discover errors.
Properties of Good Test Data
1. You must know what output a correct
program should produce for each test input.
This may require you to hand calculate a
result before you run the program.
2. The test inputs should include those
inputs that are most likely to cause errors. A
boundary value is one type of data that is
likely to cause an error.
3. You should select data that will exercise
every line of code and take every branch.
Debugging Tips
Never start changing suspicious code on
the hopes that the change "might work
better".
Instead you should discover exactly why a
test case is failing and limit your changes to
corrections of known errors.
Once you have corrected a known error, all
test cases should be rerun. (ripple effect)