Chapter 2 Developing a Program Extended Prelude to

  • Slides: 29
Download presentation
Chapter 2: Developing a Program Extended Prelude to Programming Concepts & Design, 3/e by

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

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

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

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

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

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

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,

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: Sale. Price = Original. Price – Amount. Saved = Original. Price * (Discount. Rate/100) Tax = Sale. Price * Tax. Rate Total. Price = Sale. Price + Tax 2 -8

Top Down Design The first illustration of top down design describes the 3 fundamental

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 variables: Item. Name Discount. Rate Original. Price Perform Calculations Amount. Saved = Original. Price * Discount. Rate/100 Sale. Price = Origial. Price-Amount. Saved Tax = Sale. Price * Tax. Rate Total. Price = Sale. Price + Tax Output Display: Total. Price 2 -9

A Code Module • Performs a single task • Is self-contained and independent of

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 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

Hierarchy Chart Sample Hierarchy Chart for the Sale Price Program: 2 -12

2. 3 Coding, Documenting, and Testing • Coding – Coding is done in a

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

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

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

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

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

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

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

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

Flowchart Symbols 2 -21

Control Structures • Sequence –in sequential order. – The simplest of control structures –

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 or repetition structure flowchart: 2 -23

Flowchart for a Loop or repetition structure flowchart: 2 -23

Flowchart for a Decision or selection structure flowchart: 2 -24

Flowchart for a Decision or selection structure flowchart: 2 -24

2. 6 An Introduction to GUIs and OOP • GUI – Graphical User Interface

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

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++, Java. Script 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

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

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

Pseudocode Language (Ch 2) In this chapter we added a way to create and call modules in our programs. Input Variable Assignment Set Variable = 10 Set Variable = Another. Variable Output Arithmetic Operations Write “literal text” () ^ */+Write Variable Write “literal text”, Variable Create a module Module. Name …. End Call a sub-module Call Module. Name 2 -29