1 / 18

More On Data Flow Modeling

More On Data Flow Modeling. CMSC 445 Pressman Chapters 11/12. Basic idea of Dataflow Modeling. Information flow through the system is modified by a series of transformations. Dataflow diagrams (DFD) DFDs capture these transformations in graphical form. Overview of Lecture.

orly
Download Presentation

More On Data Flow Modeling

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. More On Data Flow Modeling CMSC 445 Pressman Chapters 11/12

  2. Basic idea of Dataflow Modeling • Information flow through the system is modified by a series of transformations. Dataflow diagrams (DFD) • DFDs capture these transformations in graphical form.

  3. Overview of Lecture • Components and notation of DFD's • Three important properties of DFD • Constructing a DFD • Some observations and hints

  4. Components and notation • Alternative notations possible (see Pressman Page 313)

  5. Another DFD Example • See also Pressman page 313 for another example

  6. Important DFD properties • Information flow in any system can be represented • ”Bubbles" can be refined to represent more detail • They describe flow of data rather than flow of control • Makes DFD implementation independent • Bottom level is a PSPEC • see Pressman page page 318

  7. Constructing a DFD • Start with Context diagram (Level 0 DFD)which shows only a single process (represents the entire system), and external entities • Identify the functions to be performed • Show the information flow between functions and identify data stores and external entities • Repeatedly elaborate on the DFD ( bottom up and top down ) • After each elaboration is complete validate the DFD: • identify missing functions • identify functions that need more detail • rearrange in higher order bubbles • identify features that do not meet with the user's approval

  8. Constructing a DFD • We always start with a physical representation of the problem • That is translated into a requirements spec • From the spec a context diagram is derived • Process detailed in Pressman pgs. 323 -325 • We’ll look at another example

  9. Context Diagram Example • Suppose that the requirements said the following Letters of complaint received from citizens are entered into a complaints master file by the City Clerk’s office. The date, department code, and a complaint description are stored for each letter. Weekly reports are produced from the complaints master file and given to the City Manager. Two weekly reports are produced: a department summary and a detail list.

  10. Identifying Flows, Processes and Sources, and Sinks

  11. Resulting Context Diagram

  12. Considerations for the Level One Diagram

  13. Level - 1 Diagram City Complaint Handling System

  14. Some observations and hints • All Bubbles should be connected • At each Level there should be no more than 5 - 7 sub bubbles • Refine only one Process Bubble at a time • When refining the information flow: information continuity must be maintained • Deciding when to stop may be difficult

  15. When to stop decomposing • Reduced each process to a single decision or calculation or single database operation • Data store represents data about a single entity • System user doesn’t want to see any more detail • Every data flow doesn’t need to be split further to show the differences in data handling • Each business form or transaction, on-line display, report is a single data flow

  16. How to get started building logical DFDs • Start with a physical DFD, then get rid of all physical references • Organize all the information in the problem by type • data (data flows, data stores, data elements) • people (sources/sink or physical) • activities (processes) • hardware/software (physical) • places (physical) • Build the decomposition diagram first to identify activities (processes), then work on lower level DFDs

  17. DFD Rule Review Checklist • All data flows should be labeled. (These are the most common labeling omissions.) • If you can’t name a data flow, re-evaluate it’s existence -- is it really a data flow? • External entities (or agent) are outside the system: sources or sinks of data. • Individuals performing functions within the system are NOT entities -- their functions are captured as processes. • If you find yourself naming a data flow a verb -- take another look -- it may be a process! Data flows should be noun clauses. • All external entities shown on sub-diagrams (Level 0+) should be on the context level diagram. • Make certain your labels are meaningful

  18. References for Lecture • Pressman Chapters 11/12 • Online Sources: • nyquist.ee.ualberta.ca/~wjoerg/SE/SE_Notes-F/SE_What-F/SE_Req-F/SE_DFD.htm • www.wright.edu/coba/msis/mis321

More Related