CIS3343-Chapter 7: DATA FLOW DIAGRAMS

Event Modeling and Data Flow Diagrams

- An input flow from an external entity is sometimes called a trigger because it starts the activities of a process - Events cause the system to do something and act as a trigger to the system - An approach to creating physical data flow diagrams is to create a data flow diagram fragment for each unique system event

DEVELOPING DATA FLOW DIAGRAMS

Basic Rules: i. External entities ii. Data flows iii. Processes iv. Data stores Steps in Developing Data Flow Diagrams: 1. Creating Context Diagram 2. Drawing Diagram 0 (The Next Level at the "Context Diagram" 3. Creating Child Diagrams (More Detailed Levels) 4. Checking Diagrams for Errors

Creating Child Diagrams (More Detailed Levels)

- Each process on diagram 0 may be exploded to create a child diagram - A child diagram cannot produce output or receive input that the parent process does not also produce or receive - The child process is given the same number as the parent process i. Process 3 would explode to Diagram 3 - Entities are usually not shown on the child diagrams below Diagram 0 - If the parent process has data flow connecting to a data store, the child diagram may include the data store as well - When a process is not exploded, it is called a primitive process

Uses Case and Data Flow Diagrams

- Each use case defines one activity and its trigger, input, and output - Allows the analyst to work with users to understand the nature of the processes and activities and then create a single data flow diagram fragment

PARTITIONING WEBSITES

- Improves the way humans use the site - Improves speed of processing - Ease of maintaining the site - Keep the transaction secure

Contents of Physical Data Flow Diagrams

- Manual processes - Processes for adding, deleting, changing, and updating records - Data entry and verifying processes - Validation processes for ensuring accurate data input - Sequencing processes to rearrange the order of records - Processes to produce every unique system output - Intermediate data stores - Actual file names used to store data - Controls to signify completion of tasks or error conditions

Partitioning Data Flow Diagrams

- Partitioning is the process of examining a data flow diagram and determining how it should be divided into collections of manual procedures and computer programs - A dashed line is drawn around a process or group of processes that should be placed in a single computer program

Drawing Diagram 0 (The Next Level at the "Context Diagram")

- Start with the data flow from an entity on the input side - Work backward from an output data flow - Examine the data flow to or from a data store - Analyze a well-defined process Take note of any fuzzy areas

Creating the Context Diagram

- The highest level in a data flow diagram - Contains only one process, representing the entire system The process is given the number 0 - All external entities, as well as major data flows are shown

COMMUNICATING USING DATA FLOW DIAGRAMS

- Use unexploded data flow diagrams early when ascertaining information requirements - Meaningful labels for all data components

THE DATA FLOW APPROACH TO HUMAN REQUIREMENTS DETERMINATION

1. Conventions used in Data Flow Diagrams

LOGICAL AND PHYSICAL DATA FLOW DIAGRAMS

1. Developing Logical Data Flow Diagrams 2. Developing Physical Data Flow Diagrams a. Event Modeling and Data Flow Diagrams b. Use Cases and Data Flow Diagrams 3. Partitioning Data Flow Diagrams

A DATA FLOW DIAGRAM EXAMPLE

1. Developing the List of Business Activities 2. Creating a Context-Level Data Flow Diagram 3. Drawing Diagram 0 4. Creating a Child Diagram 5. Creating a Physical Data Flow Diagram for the Logical DFD 6. Partitioning the Physical DFD

Developing Logical Data Flow Diagrams

Advantages: i. Better communication with users ii. More stable systems iii. Better understanding of the business by analysts iv. Flexibility and maintenance v. Elimination of redundancy and easier creation of the physical model

Steps in Developing Data Flow Diagrams

Developing Data Flow Diagrams Using a Top-Down Approach: 1. Make a list of business activities and use it to determine various - External entities - Data flows - Processes - Data stores 2. Create a context diagram that shows external entities and data flows to and from the system. Do not show any detailed processes or data stores. 3. Draw Diagram 0, the next level. Show processes, but keep them general. Show data stores at this level. 4. Create a child diagram for each of the processes in Diagram 0. 5. Check for errors and make sure the labels you assign to each process and data flow are meaningful. 6. Develop a physical data flow diagram from the logical data flow diagram. Distinguish between manual and automated processes, describe actual files and reports by name, and add controls to indicate when processes are complete or errors occur. 7. Partition the physical data flow diagram by separating or grouping parts of the diagram in order to facilitate programming and implementation.

Six reasons to partition DFD

a. Different user groups b. Timing c. Similar tasks d. Efficiency e. Consistency of data f. Security

Checking Diagrams for Errors

a. Forgetting to include a data flow or pointing an arrow in the wrong direction b. Connecting data stores and external entities directly to each other c. Incorrectly labeling processes or data flow d. Including more than nine processes on a data flow diagram e. Omitting data flow

Developing Physical Data Flow Diagrams

i. Clarifying which processes are performed by humans and which are automated ii. Describing processes in more detail iii. Sequencing processes that have to be done in a particular order iv. Identifying temporary data stores v. Specifying actual names of files and printouts vi. Adding controls to ensure the processes are done properly