Understanding Data Flow Diagrams Donald S. Le Vie, Jr. Data flow diagrams (DFDs) reveal relationships among Before There Were DFDs… and between the various components in a program or system. DFDs are an important technique for modeling a system’s high-level detail by showing how input data is Flowcharts and Pseudocode transformed to output results through a sequence of Years ago, programmers used a combination of functional transformations. DFDs consist of four major flowcharts and pseudocode (a combination of English components: entities, processes, data stores, and data and the programming language being written) to design flows. The symbols used to depict how these components programs. Pseudocode can actually be simpler to read interact in a system are simple and easy to understand; than corresponding flowcharts, as Figure 1 illustrates. however, there are several DFD models to work from, each having its own symbology. DFD syntax does remain Pseudocode constant by using simple verb and noun constructs. Such Start DO Fill_Water_Can a syntactical relationship of DFDs makes them ideal for IF Plant_Soil_Moist THEN object-oriented analysis and parsing functional IF Plant_Type = Succulent THEN specifications into precise DFDs for the systems analyst. DO Add_Some_Water Fill ELSE water Do Add_Lots_of_Water DEFINING DATA FLOW can ENDIF ENDIF DIAGRAMS (DFDs) When it comes to conveying how information data flows Is plant Yes through systems (and how that data is transformed in the soil Done process), data flow diagrams (DFDs) are the method of moist? choice over technical descriptions for three principal reasons. No Add 1. DFDs are easier to understand by technical and Is plant Yes some nontechnical audiences a water 2. DFDs can provide a high level system overview, succulent complete with boundaries and connections to other No Add lots systems of water 3. DFDs can provide a detailed representation of system components1 Figure 1. A Flowchart With Corresponding Pseudocode for Watering House Plants. DFDs help system designers and others during initial analysis stages visualize a current system or one that may be necessary to meet new requirements. Systems Entity-Relationship Diagrams (ERDs) analysts prefer working with DFDs, particularly when Entity-Relationship Diagrams (ERDs) are another way they require a clear understanding of the boundary of showing information flow for a process. An ERD between existing systems and postulated systems. DFDs shows what data is being used in the process or program, represent the following: and how the files are related. The E-R (entity- relationship) data model views the real world as a set of 1. External devices sending and receiving data basic objects (entities) and relationships among these 2. Processes that change that data objects. It is intended primarily for the database design 3. Data flows themselves process by allowing for the specification of an enterprise 4. Data storage locations scheme. This enterprise scheme represents the overall logical structure of the database. ERDs do not show any The hierarchical DFD typically consists of a top-level program functions, nor data flow. An ERD is shown in diagram (Level 0) underlain by cascading lower level Figure 2. diagrams (Level 1, Level 2…) that represent different parts of the system. the DFD). Entities are also referred to as agents, customer account no. terminators, or source/sink. city balance street Process The process is the manipulation or work that transforms date data, performing computations, making decisions (logic SSN flow), or directing data flows based on business rules. In other words, a process receives input and generates some output. Process names (simple verbs and dataflow customer account names, such as “Submit Payment” or “Get Invoice”) CustAcc usually describe the transformation, which can be performed by people or machines. Processes can be drawn as circles or a segmented rectangle on a DFD, and include a process name and process number. Figure 2. An Example of an Entity-Relationship Diagram. Data Store A data store is where a process stores data between Data Flow Diagrams processes for later retrieval by that same process or Data flow diagrams have replaced flowcharts and another one. Files and tables are considered data stores. pseudocode as the tool of choice for showing program Data store names (plural) are simple but meaningful, design. A DFD illustrates those functions that must be such as “customers,” “orders,” and “products.” Data performed in a program as well as the data that the stores are usually drawn as a rectangle with the right- functions will need. A DFD is illustrated in Figure 3. hand side missing and labeled by the name of the data storage area it represents, though different notations do exist. Paycheck Data Flow D1 Bill payable Data flow is the movement of data between the entity, the process, and the data store. Data flow portrays the A1 interface between the components of the DFD. The flow Bill details of data in a DFD is named to reflect the nature of the Prepare Deposit data used (these names should also be unique within a bank amount specific DFD). Data flow is represented by an arrow, deposit A2 where the arrow is annotated with the data name. A3 Bank Update These DFD components are illustrated in Figure 4. Pay Deposit check bills book Check details Entity Faculty D2 Check Register Figure 3. An Example of a Data Flow Diagram. New Student Data Flow Record Defining DFD Components DFDs consist of four basic components that illustrate ID 2.1 how data flows in a system: entity, process, data store, and data flow. Process Create (could be Student Entity drawn as Record An entity is the source or destination of data. The source a circle) in a DFD represents these entities that are outside the context of the system. Entities either provide data to the ID Data Store B2 Student Record system (referred to as a source) or receive data from it (referred to as a sink). Entities are often represented as rectangles (a diagonal line across the right-hand corner Figure 4. The Four Major DFD Components. means that this entity is represented somewhere else in Process for Developing DFDs GUIDELINES FOR PRODUCING Data flow diagrams can be expressed as a series of DFDS levels. We begin by making a list of business activities to determine the DFD elements (external entities, data flows, processes, and data stores). Next, a context Why They Aren’t Called “Rules” diagram is constructed that shows only a single process (representing the entire system), and associated external The most important thing to remember is that there are entities. The Diagram-0, or Level 0 diagram, is next, no hard and fast rules when it comes to producing DFDs, which reveals general processes and data stores (see but there are when it comes to valid data flows. For the Figures 5 and 6). Following the drawing of Level 0 most accurate DFDs, you need to become intimate with diagrams, child diagrams will be drawn (Level 1 the details of the use case study and functional diagrams) for each process illustrated by Level 0 specification. This isn’t a cakewalk necessarily, because diagrams. not all of the information you need may be present. Keep in mind that if your DFD looks like a Picasso, it could be External External an accurate representation of your current physical Entity Entity system. DFDs don’t have to be art; they just have to accurately represent the actual physical system for data flow. Preliminary Investigation of Text Information This process The first step is to determine the data items, which are bubble could Computer- External usually located in documents (but not always). Once you be drawn as Based Entity identify the data items, you’ll need to determine where a rectangle System they come from (source) and where they go with round (destination). Construct a table to organize your corners… information, as shown in Table 1. Data Item Source Destination External External Entity Needs Analysis Account Executive Project Manager Entity ROI Study Pre-Sales Support Proposal Manager Figure 5. General Form of a Level 0 DFD. Table 1. Data Item Table Figure 6 offers a more specific Level 0 DFD. Determining System Boundaries Once you have the data items, sources, and destinations in a table, determine which entities (sources and Digital Mixer Sound Studio Data Link destinations) belong internal to the system and which Mixer Speakers Music ones are external to the system. Sometimes it helps to Output have some knowledge about what may be happening at Mixer Music deeper levels (Level 1+) to work backwards to help you Sound Output MIDI DR5 develop a Level 0 DFD. Such a method depends on the Commands Amplifier Link Band in system being modeled or personal preference, but a Box knowing that DFD development is an iterative process MIDI Sound DR5 Settings prepares you for the many DFD drafts you may have to Commands generate. MIDI Status External Sound Display Developing the Level 0 DFD Monitor MIDI Data At this point, you should have a good idea of the system Display Device boundary. All components within the system boundary are included within a single system/process box in the DFD. External entities lie outside the system boundary; internal entities will become locations for processes. The Figure 6. Specific Level 0 DFD data flow arrows to and from the external entities will indicate the system’s relationship with its environment. Remember that information always flows to or from a process, an external entity, or a data store. You can use a dashed line to show data flows between external entities that are strictly external to the system at hand if it will outputs and outputs, and use one process for each source help make the DFD easier to understand. or destination from the DFD. Child (Level 1+) Diagrams Revising the Level 1 DFD Once you’ve finished your first attempt at a Level 1 DFDs can be expressed as a series of levels. The DFD, review it for consistency and refine it for balance outermost level (Level 0) is concerned with how the by asking yourself these questions: system interacts with the outside world. Subsequent 1. Do the Level 1 processes correspond with the major levels examine the system in more detail, and use the functions that a user expects from the system? same symbols and syntax as with Level 0. See Figure 7. 2. Is the level of detail balanced across the DFD? 3. Can some processes be merged? 4. Can I remove data stores not shared by more than Instrument one process? Music Output Sound 5. Have I avoided crossed data flow lines by making 1 use of duplicated components (external entities and MIDI Sound MIDI Sound data stores)? Commands Data Digital Sound Mixer Sound Some Guidelines About Valid and Non- Wizard Data Link Valid Data Flows Record MIDI Sound Data Before embarking on developing your own data flow Playback Commands Data diagram, there are some general guidelines you should Sound be aware of. 1 Waveform Data stores are storage areas and are static or passive; therefore, having data flow directly from one data store to another doesn't make sense because neither could initiate the communication. Figure 7. Example of a Level 1 DFD Showing the Data Flow and Data Store Associated With a Data stores maintain data in an internal format, while SubProcess “Digital Sound Wizard.” entities represent people or systems external to them. Because data from entities may not be syntactically When producing a first-level DFD, the relationship of correct or consistent, it is not a good idea to have a data the system with its environment must be preserved. In flow directly between a data store and an entity, other words, the data flow in and out of the system in the regardless of direction. Level 1 DFD must be exactly the same as those data flows in Level 0. If you discover new data flows crossing Data flow between entities would be difficult because it the system boundary when drawing the Level 1 DFD, would be impossible for the system to know about any then the Level 0 DFD must be amended to reflect the communication between them. The only type of changes in the Level 1 DFD. communication that can be modeled is that which the system is expected to know or react to. Developing the Level 1 DFD It is important that the system relationship with its Processes on DFDs have no memory, so it would not environment be preserved no matter how many levels make sense to show data flows between two deep you model. In other words, you can’t have new asynchronous processes (between two processes that data flows crossing the system boundary in Level 1. The may or may not be active simultaneously) because they next section deals with such non-valid data flows. may respond to different external events. The Level 1 DFD provides a high-level view of the Therefore, data flow should only occur in the following system that identifies the major processes and data scenarios: stores. Identify or list each incoming and outgoing data • Between a process and an entity (in either direction) flow with a corresponding process that receives or • Between a process and a data store (in either generates data. Make sure you refer to your data item direction) table for any missing internal data flows and to identify • Between two processes that can only run data stores. If your table contains documents with the simultaneously same source and destination, they might be data stores. Some processes share data stores while some data stores Figure 8 illustrates these valid data-flow scenarios. are used by one process. It may be possible to move the single process • data store inside the process itself. Identify those processes that only address internal ANALYSIS AND DESIGN Registration form METHODS Student Class Analysis and design methods are tools used during the Subject Register Rolls project life cycle for bringing order and structure to the Registered 1 Degree/ analysis and design process. They specify the steps, Transcripts notation, rules, and guidelines for conducting object- Grades oriented analysis and design (OOAD). We will briefly Student Record Exam focus on object-oriented analysis (OOA). 2 Steps in Object-Oriented Analysis Graduate 3 Academic Exam or The first step in OOA is often the identification of Paper Faculty important classes, which is done by identifying the Record nouns in the requirement specification. Many times, Figure 8. A Valid DFD Example Illustrating Data classes are defined from tangible things, roles, or Flows, Data Store, Processes, and Entities. incidents. In Figure 8, Student and Faculty are the source and Analysis also includes defining object attributes and destination of information (the entities), respectively. object and class or other relationships. Analysis also Register 1, Exam 2, and Graduate 3 are the processes in attempts to identify the behavior of objects and classes the program. Student Record is the data store. Register 1 as well as data flow between objects. performs some task on Registration Form from Student, and the Subject Registered moves to the data store. The Object Modeling Technique (OMT) Class Rolls information flows on to Faculty. Graduate 3 obtains Academic Record information from Student The Object Modeling Technique (OMT) is an approach Record, and Degree/Transcript information is moved to to object-oriented analysis and design that is also Student. Exam 2 obtains exam/paper information from referred to as the Rumbaugh Method, named after the Faculty, and moves the Grades to the Student Record for principal author of the technique. The OMT storage. methodology is programming language-independent, instead relying on a consistent, single notation for both Here are a few other guidelines on developing DFDs: analysis and design. • Data that travel together should be in the same data flow OMT Modeling • Data should be sent only to the processes that need The output of OMT is a three-dimensional view (from three different models) of the system that stays the same during the data the transition from analysis to design. • A data store within a DFD usually needs to have an input data flow The Object Model describes the static system components • Watch for Black Holes: a process with only input and is modeled using object diagrams. The Dynamic Model data flows describes the dynamic system components that change over • Watch for Miracles: a process with only output time and are modeled using state diagrams. The Functional flows Model describes operations performed on data in a system and uses data flow diagrams. • Watch for Gray Holes: insufficient inputs to produce the needed output Advantages and Disadvantages of • A process with a single input or output may or may not be partitioned enough DFDs • Never label a process with an IF-THEN statement • Never show time dependency directly on a DFD (a Strengths process begins to perform tasks as soon as it As we have seen, the DFD method is an element of object- receives the necessary input data flows) oriented analysis and is widely used. Use of DFDs promotes quick and relatively easy project code development. DFDs are easy to learn with their few-and- simple-to-understand symbols (once you decide on a particular DFD model). The syntax used for designing DFDs is simple, employing English nouns or noun- (data stores). The hierarchical DFDs consist of a single adjective-verb constructs. top layer (Level 0 or the context diagram) that can be decomposed into many lower level diagrams (Level 1, Disadvantages Level 2…Level N), each representing different areas of DFDs for large systems can become cumbersome, the system. difficult to translate and read, and be time consuming in their construction. Data flow can become confusing to DFDs are extremely useful in systems analysis as they programmers, but DFDs are useless without the help structure the steps in object-oriented design and prerequisite detail: a Catch-22 situation. Different DFD analysis. Because DFDs and object technology share the models employ different symbols (circles and rectangles, same syntax constructs, DFDs are appropriate for the for example, for entities). OO domain only. Using DFDs in the Appropriate DFDs are a form of information development, and as such provide key insight into how information is Application Domain transformed as it passes through a system. Having the skills to develop DFDs from functional specs and being DFDs are useful tools for OO architectures and are best able to interpret them is a value-add skill set that is well utilized with OO languages and compiler programming. within the domain of technical communications. DFD semantics can be accurately and precisely represented within OO technology, as Figure 9 illustrates. The methods of the Customer Object and Vendor Object are of the same syntactical construct as REFERENCES DFDs. (1) Perry, Greg. Sams Teach Yourself Beginning Programming in 24 Hours, Sams Publishing, 1998. 492 pages. Object X Interface Object Z Interface (2) Le Vie, Jr., Donald. “An eCommerce Primer for Technical Communicators,” STC Proceedings of the 47th Annual Conference, 2000. CalculateCost CalculateCost DisplayCost DisplayCost FormatInvoice FormatInvoice Customer Object Vendor Object Figure 9. Example of DFD Semantics Used in 2 Object Technology Because of the semantic relationship DFDs have with OO programming, DFDs are inappropriate for non-OO architectures. The first and most important step in translating a functional spec into a DFD is to parse it into its component verbs and nouns so that a DFD can be developed that precisely coincides with the functional specification. Donald (Donn) S. Le Vie, Jr. Information Development Director Integrated Concepts, Inc. CONCLUSION 8834 Capital of Texas Highway North, Suite 280 Austin, Texas 78759 Data flow diagramming is a highly effective technique (512) 231-9999, ext. 231 for showing the flow of information through a system. firstname.lastname@example.org DFDs are used in the preliminary stages of systems analysis to help understand the current system and to Donn directs the information development efforts at represent a required system. The DFDs themselves Integrated Concepts, Inc., an eCommerce software represent external entities sending and receiving development company in Austin, Texas. He has more information (entities), the processes that change than 20 years’ experience in private industry, academia, information (processes), the information flows and government. When he’s not writing articles and themselves (data flows), and where information is stored books, Donn records and tours with his band, SnakeByte.
Pages to are hidden for
"Understanding Data Flow Diagrams"Please download to view full document