Csc 130 class 2 problem analysis and flow charts(2)

  • View
    366

  • Download
    0

Embed Size (px)

DESCRIPTION

flow chart in software programming

Text of Csc 130 class 2 problem analysis and flow charts(2)

  • 1. CSC 130Class 2

2. Software Development Lifecycle Rewriting the Problem Statement Three Components of Every Problem Defining Diagram Algorithm Design Tools Flowcharts Starting and Ending Flow Chart Control Structures Sequence Structure in Flow Chart Selection Structure in Flow Chart Repetition Structure in Flow Chart 3. Analyze a simple problem and develop an algorithm for its solution using various techniques to include top-down development, pseudo code, flow charts, hand-checking, wellchosen test data, and stubs and drivers Problem Analysis and algorithm development Top down program development Algorithm representation in pseudo code and flowcharts 4. Step #Step NameDescription1Requirements SpecificationUnderstanding the problem. This will begin by rewriting the problem statement in your own words. If you cant understand the problem in English you will not be able to solve the problem in a programming language. Discuss the problem with the customers and the users. In this class your instructor is your customer and your user.2System AnalysisTranslate the user and/or customer requirements into technical requirements. Describe input values that are required for the program. Describe the processing that must be accomplished in the program in order to take the input and generate the required output.. Describe the outputs that are required for the program.3System DesignDevelop a detailed logical plan to solve the problem that was analyzed in step 2. Break down the problem into small manageable pieces. Use pseudo code, UML, and other appropriate tools to represent your design. Desk check your design using appropriate input data to make sure that the design will give you the correct output.4ImplementationTranslate your design into a programming language. Write the computer program following the syntax of the language. During this phase we will find syntax errors. Syntax errors are grammar errors in the programming language.5TestingRun your completed program on the computer to make sure that it works. Input real life data and look at the resulting output. You must test all paths through the program. This process is called debugging. You are looking for bugs in your program bugs are errors. During this phase we will find logical errors. Logical errors are errors with our algorithm our plan for solving the problem. 5. The first step for any problem is to fully understand your problem statement. Understand the EXPLICIT details outlined in the problem These are the facts that you see stated immediately in the problem statement Understand the IMPLIED details required by the problem These are details that are not stated immediately by the problem statement These are details that are required to support the EXPLICIT details outlined in the problem. Rewriting the problem statement in your own words helps to define both the EXPLICIT and IMPLIED details. Details to Consider What actions the program must be able to do What information the program must be able to remember 6. If you cant explain the problem in your own words, then you are not ready to continue with the design process If you can rewrite the problem in your own words, then you have a good understanding of the problem. When you rewrite the problem statement, the rewritten version should be longer than the original version. 7. We own a pizza shop, and we need a better way to control orders and customer records. Were a small shop, but have lots of part-time workers, and we want to have as much uniformity as possible in how customers and orders are handled. We sell only in the restaurant (no delivery) for both eat-in and carry-out. Regular customers can join the Frequent-Eaters club which entitles them to a free pizza after purchasing 10 pizzas. We sell pizzas with zero or one extra topping (extra cheese, pepperoni, green pepper, mushrooms, or onions). We have two sizes: small and large. If a customer is ordering multiple pizzas, all pizzas must be the same size and have the same topping. 8. Explicit Details Details that written specifically in the problem statement. Consider action statements from the problem and list them as Action Verb Phrases in the rewritten problem statement. Consider data details from the problem and list them as information to Remember in the rewritten problem statement.Example Remember the valid pizza sizes of small and large. Remember the number of pizzas in the order Remember the valid pizza toppings of extra cheese, pepperoni, green pepper, mushrooms, or onions Be able to take an order for a pizza Be able to 9. Implied Details Details that are not written specifically in the problem statement. Details that are implied based on the problem specifics. Implied details can include both actions and information to remember.Example Be able to validate the size of the pizzas in the order (small or large). Be able to validate the number of pizzas in the order (greater than 0). Prompt the user for the number of pizzas in the order Read in the number of pizzas in the order. Remember the number of pizzas in the order 10. Input A list of source data provided to the problem Output A list of data generated and provided by the solution to the problem Processing A list of actions that need to be completed in order to produce the required output for the problem. Examples Computer can receive information - Input Computer can print out information Output Computer can perform Arithmetic Processing Computer can assign a value to a variable or memory location Storage Computer can compare two variables and select one of two alternative actions Processing Computer an repeat a group of actions - Processing 11. A Defining Diagram is created using the details of the problems statement. A Defining Diagram is created using the explicitly defined details of the problem and also the implied details of the problem. The Defining Diagram presents the input, output, and processing for the problem in a simple tabular form. The Defining Diagram does not show time sequence of the problem solution. At this point you do not care how the processing is done you just need to have a place holder for the action. Creating the Defining Diagram Look for descriptive words and nouns these become the inputs and outputs Look for the actions required and verbs these become the processing One column for Input, one column for processing, and one column for Output 12. Example Adding Two Numbers Problem Statement Create a program that will calculate the sum of two numbers that are entered at the keyboard. The sum should be printed to the screen. Defining Diagram InputProcessingOutputfirst numberPrompt for numberssecond numberGet numbers from keyboardPrompt message for first number Prompt message for second number sumcalculate sum Display sum 13. List of steps involved in accomplish a task. Detailed precise ordered instructions describing the process necessary to produce the desired output from a given input. A logic plan for a solution to a problem. We will use the information from the rewritten problem statement and the Defining Diagram to fill in the details of the algorithm. 14. Once you understand the problem you are now ready to move forward in the design of the problem. These tools can be used to represent your algorithm (your logical plan to solve the problem) Different design tools work well for different programming languages. Flow Charts Pictorial representation of the logical steps to solve the problem Flow charts show action and not data Flow Charts are good for procedural programming languages Flow Charts can also be used for defining the steps within a method. Pseudo code Statements between English and a programming language that represent the logical steps to solve a problem. Pseudo code can be used to support the design of procedural and object oriented programs Pseudo code can be used to represent both data and action. UML Unified Modeling Language This is a design tool used for object oriented programs This can easily show data and action This can easily show classes, objects, and how they relate and interact with each other. 15. Pictorial representation of the logical steps it takes to solve a problem. Flow charts show the flow of actions. Flow charts do not show the any information about data Flow charts are not the best tool used to design object oriented programs because they only show actions and not information Flow charts are good tools for procedural programming languages. Program Steps are placed in different shaped boxes and connected with arrows. These connections show the order in which the steps must take place. Each shape for a box represents a specific type of action. Oval for Start and Stop Parallelogram for input and output. Rectangle for processing for example calculations Diamond is used to ask a question. The question may only have two answers Yes or No (true or false) The design for every program begins with Start. The design for every program ends with Stop. 16. Every flow chart has a starting point The Starting Point is marked with an Oval for Start. Every flow chart has an ending point The Ending Point is marked with an oval for Stop. The actual steps required to accomplish the goals of the program are represented by other shapes and connecting lines in between the Start and the Stop. StartStop 17. Basic shapes represent activities that must occur in the program.Each shape will contain text that specifies details of the activity.Arrows An arrow always show the flow of actions in a flow chart The arrow head is always pointing at the next actionRectangle Shows processing activities such as mathematical calculations The text inside the rectangle specifies the exact calculation Calculate Tax based on total salesParallelogram Shows that input or output of some sort must occur. Input and output both use the