1 / 23

Problem Solving

Learn how to attack large problems, define the problem, output and input, and refine algorithms using data flow diagrams in software development.

toland
Download Presentation

Problem Solving

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Problem Solving • How do we attack a large problem? • Before we can seriously begin to even think about coding, what do we need to do? • What do we need to know to start solving ANY problem?

  2. The “Approach” • Integration Thread – what gets built and tested first • Development order • But first, what are the components? • Once these “components” are identified, we need to spend some no-trivial time looking at how we plan to organize our work. • Parallel development explored

  3. Problem Solving Steps • Define the Problem • Define the Output • Define the Input • Define the Initial Algorithm • What are the components? • How will I solve the problem? • Refine the Algorithm - To some degree, 1-5 is language independent Only Now -- Define the Program

  4. Top Down Decomposition • Large Systems are usually not developed as single programs • Large Systems are often not developed by single teams • Large Systems must be broken up into functional components that act as if they were free-standing independent programs • These functional components may or may not map to functional requirements or constraints

  5. Top Down Decomposition “… is characterized by moving from a general statement of what the program does to detailed statements about specific tasks that are performed.” What are the functional parts of the system? What information does each of these functional components produce? What information does each of these functional components need to do its work?

  6. Data Flow Diagrams (DFDs) • Diagram the logical flow of the data. • What diagram do we draw? Is there only one correct diagram? • Many interpretations are possible. • Duplicate how it is currently done • Use a different process, a different algorithm

  7. DFDs Data flow diagrams have the advantage of leaving out procedural details while emphasizing the central role of data in organizing the eventual design and code of a software system.

  8. What does a DFD Look Like?

  9. What does a DFD Look Like? DFDs are composed of a limited number of graphical components. • Bubbles • Arrows • Boxes • Double Boxes/Double lines

  10. DFD Symbols: • Rectangle: represents an external entity, a temporary event • INPUT • a system element (hardware or a person etc.) • another system that produces information for transformation by the software • OUTPUT • receives information produced by the software

  11. DFD Symbols: • Circle (or oval) represents A process or transform that acts on data and changes it in some way

  12. DFD Symbols: • Arrow represents • one or more data items • All arrows on a DFD should be labeled

  13. DFD Symbols: • Shaded Rectangle or Double line represents: •  a data store - stored information that is used by the software (a database)

  14. Data “Conservation”: When moving down a level the data-in must be the same as at the higher level. Similarly, the data-out must be consistent. • Information continuity must be maintained. • All information transfers must be clearly identified.

  15. Refinement -- • During stepwise refinement, one bubble at a time should be refined. How does one refine a bubble?

  16. Data Flow Diagrams -- • represent algorithms as black boxes (MAGIC), with data input and output shown. • focus on what happens to the data as it "flows" from process to process. It does not focus on how the process works. • hide the details of an algorithm, but they are useful in describing the interaction between/among algorithms.

  17. Data Flow • DFDs indicate the flow of information from one process to the next. • Control is not indicated • Each time data is transformed by the system there is a process (bubble)

  18. DFD Guidelines: 1) the level 00 DFD should depict the software/system a a single bubble 2) primary Input/Output files should be carefully noted 3) all arrows and bubbles should be labeled with meaningful names 4) information flow continuity must be maintained 5) one bubble at a time should be refined

  19. Using your Intuition: DFDs are an INTUITIVE way of showing how data is processed by a system. The Notation represents: • functional processing • data stores • data movement

  20. Don’t Get Complicated: DFDs are easy to over-complicate This occurs when: • analyst attempts to show too much detail too early on • represents procedural aspects of the software rather than information flow

  21. DFDs DFDs show how data flows through a sequence of processing steps processing steps = transformations program functions

  22. Beginning-to-end processing DFDs show the flow of processing from when data enters the system to where it leaves the system.

  23. DFDs DFDs show "functional transformations," but DO NOT suggest how these might be implemented.

More Related