1. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Extended Prelude to Programming Concepts & Design, 3/e by Stewart Venit and Elizabeth Drake Chapter 2: Developing a Program

2. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-2 2.1The 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

3. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-3 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

4. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-4 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

5. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-5 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

6. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-6 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: compiler will alert you to errors in syntax but not logic Finally, check your program with as many sets of test data as possible (min, max, max)

7. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-7 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

8. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-8 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

9. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-9 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 Perform Calculations Output Input variables: AmountSaved = Display: OriginalPrice * DiscountRate/100 TotalPrice ItemNameSalePrice = OrigialPrice-AmountSaved DiscountRateTax = SalePrice * TaxRate OriginalPriceTotalPrice = SalePrice + Tax

10. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-10 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 Why modularize?

11. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-11 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.

12. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-12 Hierarchy Chart Sample Hierarchy Chart for the Sale Price Program:

13. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-13 2.3Coding, 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

14. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-14 2.3Coding, 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.

15. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-15 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. –These errors can be detected during the desk checking phase of the programming cycle.

16. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-16 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

17. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-17 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

18. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-18 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

19. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-19 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

20. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-20 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 –May be unsuitable for event driven programming

21. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-21 Flowchart Symbols

22. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-22 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.

23. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-23 Flowchart for a Loop Loop or repetition structure flowchart:

24. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-24 Flowchart for a Decision Decision or selection structure flowchart:

25. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-25 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.

26. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-26 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

27. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-27 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.

28. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-28 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

29. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-29 Pseudocode Language (Ch 2) In this chapter we added a way to create and call modules in our programs. InputAssignment Input Variable Set Variable = 10 Set Variable = AnotherVariable OutputArithmetic Operations Write “literal text” ( ) ^ * / + - Write Variable Write “literal text”, Variable Create a module Call a sub-module ModuleName Call ModuleName …. End

30. Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 2-30 Questions & Discussion