Transcript Chapter 2

Chapter 2:
Developing a Program
Extended Prelude to Programming
Concepts & Design, 3/e
by
Stewart Venit and Elizabeth Drake
Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
2.1 The Program Development Cycle
• Problem solving principles
–
–
–
–
Completely understand the problem
Devise a plan to solve it
Carry out the plan
Review the results
• Writing a program
–
–
–
–
1) Analyze the problem
2) Design the program
3) Code the program
4) Test the program
2-2
1. Analyze the Problem
• Identify desired results (output)
• Determine input needed to produce those results
• Example: Create a program to generate 6 numbers to
play the lottery
– Problem must be more specific
– Desired results: 6 different positive integers within the range
of 1 to 40
2-3
2. Design the program
• Create a detailed description of program
– Use charts or ordinary language (pseudocode)
• Identify algorithms needed
– Algorithm: a step-by-step method to solve a problem or
complete a task
• Algorithms must be:
–
–
–
–
Well defined
Well ordered
Must produce some result
Must terminate in a finite time
2-4
3. Code the program
• Translate charts or pseudocode (ordinary
language) into program code
• Add statements to document what the code does
– Internal documenation
– External documentation
• Each programming language uses its specific
syntax
2-5
4. Test the program
• In analysis phase: continually ask questions
– Did I interpret data correctly?
– Does program fulfill requirements? Etc…
• In design phase: use desk-checking to walk through
the program
• In coding phase: software will alert you to errors in
syntax
• Finally, check your program with as many sets of test
data as possible
2-6
2.2 Program Design
• Modular programming
– Determine the major tasks that the
program must accomplish. Each of these
tasks will be a module.
– Some modules will be complex
themselves, and they will be broken into
submodules, and those submodules may
also be broken into even smaller modules.
– This is called top-down design
2-7
The Sale Price Example
A local department store needs to develop a program which, when given an item’s
original price and the percentage it is discounted, will compute the sale price, with
sales tax.
Output required:
name of item, discounted price, amount of sales tax, total price
Input required:
name of item, original price, percent discounted
Formulas required:
SalePrice = OriginalPrice – AmountSaved
AmountSaved = OriginalPrice * (DiscountRate/100)
Tax = SalePrice * TaxRate
TotalPrice = SalePrice + Tax
2-8
Top Down Design
The first illustration of top down design describes the 3
fundamental tasks that are required in the Sale Price
example:
– Input
– Perform Calculations (Process)
– Output
Input
Input variables:
ItemName
DiscountRate
OriginalPrice
Perform Calculations
AmountSaved =
OriginalPrice * DiscountRate/100
SalePrice = OrigialPrice-AmountSaved
Tax = SalePrice * TaxRate
TotalPrice = SalePrice + Tax
Output
Display:
TotalPrice
2-9
A Code Module
• Performs a single task
• Is self-contained and independent of other modules
• Is relatively short – less than 1 page
• A module is called by the calling module
• A call statement causes a called module to be
executed; control is transferred from the calling
module to the called module
• The main module is the controller of all sub-modules
2-10
The Hierarchy Chart
• Like an organization chart – shows position of
modules in the program.
• Depicts what modules exist and how they are related.
• Large programs need a “map” for documentation.
• One page of code per module – keeps the program
manageable.
• We will have very small modules while getting
comfortable using these tools.
2-11
Hierarchy Chart
Sample Hierarchy Chart for the Sale Price
Program:
2-12
2.3 Coding, Documenting, and Testing
• Coding
– Coding is done in a specific programming language. We will use
pseudocode.
– This phase should only begin after a solid design exists.
• Documenting
– Code needs to contain documentation that describes to the reader what
the code is doing
– Two types of comments are used for documentation
• Internal and external documentation
– Internal documentation is for the programmers to read
– External documentation is for the user
2-13
2.3 Coding, Documenting, and Testing
• Testing
– Create test data that will be used to check the program’s
correctness.
• Use desk checking (or walking through a program by hand with a
set of data that you know the answer to)
– Check that the program will catch errors by using test data
designed to create errors
– The more testing of various types of data you can use, the
more likely you are to have a program that is free of errors.
2-14
Types of Errors
• Syntax errors: a violation of the programming
language’s rules for creating valid statements
– May be caused by incorrect grammar or punctuation, or misspelling a
keyword
– The program will not run at all with syntax errors
• Logic errors: the program runs, but does not produce
the expected results
– May be caused by using an incorrect formula, or incorrect sequence of
statements, etc.
– Sometimes called runtime errors
– These errors can be detected during the desk checking phase of the
programming cycle.
2-15
2.4 Commercial Programs:
Testing and Documenting
External documentation
Purposes:
1. Documentation in a user’s guide or on-screen
help system provides information about the
program for the end users
2. Documentation in a maintenance manual
provides information about how the program
code accomplishes its purposes
2-16
The User’s Guide
• Usually written during alpha or beta test phases
• Written by a technical writer
• Forms of user’s guides:
– Tutorials
– Thematic approach
– Alphabetical order
2-17
Documentation for other programmers
• Program maintenance manual
– For programming experts to help them fix or
enhance code written by other programmers
• Design documentation
– Written by programmer to explain rationale behind
methods and code used
• Trade Study documentation
– A research tool
– An attempt to find the best solution
2-18
2.5 Structured Programming
• A method for designing and coding programs in a
systematic, organized manner
• It combines the principles of top-down design,
modularity and the use of the three accepted control
structures of sequence, repetition and selection
• Sequence, repetition and selection can be expressed in
pseudocode, or with flowcharts
2-19
Flowcharts
• A tool for programmers to design programs
– Describes the flow of a program module’s execution with
diagrams
– Completely different from hierarchy charts
– Connected symbols are used to describe sequence,
repetition, and selection structures
– Some prefer to use flowcharting to learn how to express
algorithms, and others prefer to use pseudocode
– Many programs are designed with a combination of
pseudocode and flowcharts
2-20
Flowchart Symbols
2-21
Control Structures
• Sequence –in sequential order.
– The simplest of control structures – start at the beginning and continue in
sequential order.
• Repetition – repeat statements more than once
– Also called a loop, it needs a stop condition, i.e, the program will
continue to loop until some condition is met.
• Selection – selectively execute statements
– Called a branch, it requires a condition to determine when to execute
statements.
2-22
Flowchart for a Loop
Loop or repetition structure flowchart:
2-23
Flowchart for a Decision
Decision or selection structure flowchart:
2-24
2.6 An Introduction to GUIs and OOP
• GUI – Graphical User Interface
– Users interact with software using a mouse, to select from
menu choices, clicking on buttons, etc.
– Development of GUI software uses tools specifically
designed for that task.
– Event-driven programming is the development of software
where the flow of control is based on the user’s clicking on
menus and buttons, etc. These user actions are called
events.
• Event-driven programming still uses the basic principles of
structured programming – program modules, control structures,
good programming style, and program testing.
2-25
Object Oriented Programming
• Focus is on the objects that will be used to solve the
problems.
• Object – a structure that contains attributes and
methods (data and process)
• Object-oriented design starts with identifying the
required objects.
• Java, C++, JavaScript and others are languages based
on object-oriented programming
2-26
Importance of Structured Programming
• Structured, event-driven, and object-oriented
programming techniques are not separate form
each other.
• All require the basic principles of structured
programming – program modules, control
structures, good programming style, and
program testing.
2-27
Style Pointers
•
•
•
•
•
•
Write modular programs
Use descriptive variable names
Provide a welcome message for the user
Use a prompt before an input
Identify program output
Document your programs
2-28
Pseudocode Language (Ch 2)
In this chapter we added a way to create and call modules in our programs.
Input
Input Variable
Assignment
Set Variable = 10
Set Variable = AnotherVariable
Output
Arithmetic Operations
Write “literal text”
() ^ */+Write Variable
Write “literal text”, Variable
Create a module
ModuleName
….
End
Call a sub-module
Call ModuleName
2-29