1. Extended Prelude to Programming Concepts & Design, 3/e by Stewart Venit and Elizabeth Drake Chapter 2: Developing a Program

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. 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. 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. 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. 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: software will alert you to errors in syntax Finally, check your program with as many sets of test data as possible

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

11. 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. 12 Hierarchy Chart Sample Hierarchy Chart for the Sale Price Program:

13. 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. 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. 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. –Sometimes called runtime errors –These errors can be detected during the desk checking phase of the programming cycle.

16. 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. 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. 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 Trade Study documentation –A research tool –An attempt to find the best solution

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

21. 21 Flowchart Symbols

22. 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. 23 Flowchart for a Loop Loop or repetition structure flowchart:

24. 24 Flowchart for a Decision Decision or selection structure flowchart:

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