Chapter 2: Developing a Program

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

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

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. 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. 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. 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. 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.2 Program Design

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

13. 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 commentsare used for documentation • Internal and external documentation • Internal documentation is for the programmers to read • External documentation is for the user

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

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. 2.4 Commercial Programs:Testing and Documenting External documentation Purposes: • Documentation in a user’s guide or on-screen help system provides information about the program for the end users • Documentation in a maintenance manual provides information about how the program code accomplishes its purposes

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

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

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

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. Object Oriented Programming • Focus is on the objects that will be used to solve the problems. • Object – a structure that contains attributesandmethods (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. 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. 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. Pseudocode Language (Ch 2) In this chapter we added a way to create and call modules in our programs. InputAssignment InputVariableSetVariable= 10 SetVariable=AnotherVariable OutputArithmetic Operations Write “literal text” ( ) ^ * / + - WriteVariable Write “literal text”, Variable Create a moduleCall a sub-module ModuleName Call ModuleName …. End