DFD Data Flow Diagrams PDF

MODULE VI: System Model (Data Flow Diagram) o Data Flow Diagrams and its Symbols o Different Leveling of Data Flow Diagrams o Data Flow Diagrams Errors o Data Flo...

MODULE VI: System Model (Data Flow Diagram) o Data Flow Diagrams and its Symbols o Different Leveling of Data Flow Diagrams o Data Flow Diagrams Errors o Data Flow Diagram Guidelines o Logical and Physical DFD OBJECTIVES: At the end of the lesson the students will be able to:  Explain Data Flow Diagrams and its Symbols  Discuss and Demonstrate the different Leveling of DFD  Demonstrate good style conventions in developing DFDs  Discuss the difference between Logical and Physical DFDs DATA FLOW DIAGRAMS A data flow diagram (DFD) is a graphical representation of the "flow" of data through an information system. DFDs can also be used for the visualization of data processing (structured design). It views a system as a function that transform the input into desired output. Data flow diagram used for data flow analysis Data flow analysis help the system analysts to determine the activities that make up a system, what data are essential to each activity. What data enter and leave the system. Data flow diagram provides a logical model of system and shows the flow of data and the flow of logic involved DFDs models the system by depicting external entities from which the data flows and where results terminate, processes which transform data flows, data stores from which the data are read or into which data are written by the processes. The DFD has following characteristics:  They show the passage of data through the system.  They focus on the process that transforms incoming data flows (input) into outgoing data flows (output).  The processes that perform this transformation normally create as well as use data.  External entities send and receive data flows from the system.  DFD supports a top-down approach for analysis. CREATING A DATA FLOW DIAGRAM Steps 1. Create a list of activities 2. Construct Context Level DFD (identifies external entities and processes) 3. Construct Level 0 DFD (identifies manageable sub process ) 4. Construct Level 1- n DFD (identifies actual data flows and data stores ) 5. Check against rules of DFD How to Identify Entities External Interactions: Think of who or what interacts with the system but is not part of it. External interactions could include users, other systems, departments, or organizations. Data Flow: Identify who provides input to the system or consumes the output. These are typically sources and sinks of data. Outside Control: Entities lie outside the control of the system being modeled. If a component does not handle internal operations but simply exchanges data with your system, it’s an external entity. Key Considerations for Defining an Entity:  Role in the System: Who interacts with the system? Examples: A customer, a supplier, an employee, an external application. Why does this interaction occur? Example: A customer places an order, or a supplier provides inventory updates.  Source or Destination of Data: Entities are sources when they send data to the system (e.g., a customer submitting a form). Entities are destinations when they receive data from the system (e.g., a payment gateway receiving payment details).  Not Part of Internal Operations: Entities do not perform any of the processing within the system. They only send or receive data, leaving the actual processing tasks to internal components(processes). If an entity is involved in processing data, it’s better modeled as a process within the system.  Human or System Interaction: Entities can represent people (users, managers), other departments, or external systems (another software application, API, etc.).  Independence: Entities operate independently from your system. They are often from outside your organization (e.g., external customers, vendors), or they could represent distinct roles within your organization that use your system (e.g., sales department).  Clarity and Specificity: Entities should be clearly labeled with specific roles or names that reflect their function. Avoid vague names like "Person" or "Department"; instead, use labels like "Customer", "Supplier", or "HR System." Common Examples of Entities:  Customer: Submits an order, inquiries, or requests. Supplier: Sends invoices, product data, or inventory updates. Manager: Approves requests, accesses reports, or provides feedback. Payment Gateway: Processes payments and sends back confirmation. External System: Communicates with your system to exchange data SYMBOLS USED IN DFD EXTERNAL ENTITIES (SOURCE/SINK) Represent people or organizations outside of the system being studied Shows the initial source and final recipient of data and information Should be named with a noun, describing that entity External entities may be: A person, such as CUSTOMER or STUDENT. A company or organization, such as BANK or SUPPLIER. Another department within the company, such as ORDER FULFILLMENT. Another system or subsystem, such as the INVENTORY CONTROL SYSTEM. PROCESSES Represent either: A whole system A subsystem Work being done, an activity Names should be in the form verb-adjective-noun The exception is a process that represents an entire system or subsystem. DATA STORES Name with a noun, describing the data Data stores are usually given a unique reference number, such as D1, D2, D3. Include any data stored, such as: A computer file or database A transaction file A set of tables A manual file of records DATA FLOW Data flow shows the data about a person, place, or thing that moves through the system. Names should be a noun that describes the data moving through the system. Arrowhead indicates the flow direction. Use double headed-arrows only when a process is reading data and updating the data on the same table or file. depicts data that are in motion and moving as a unit from one place to another in the system single element structure diverge converge two-way Example: Online Ordering System Customer (The customer interacts with the system by placing orders and providing payment information). Data Flow (Sends order details (input to the system)). (Receives order confirmation (output from the system)). External to the System (The customer is not involved in internal operations like checking inventory or processing payments, but they interact with the system by submitting and receiving data) Payment (Processes payments on behalf of the system). Data Flow (Receives payment details (input from the system)) Sends payment confirmation or failure notice (output to the system)). External to the System (The gateway processes payments but does not handle other system tasks like managing orders or inventory). NOTE (When to Exclude Something as an Entity) Internal Process: If a component performs internal operations (e.g., verifying an order, checking inventory), it should be modeled as a process, not an entity. Data Stores: These are repositories of data (e.g., databases) and are represented differently on a DFD. They are part of the system and not external entities. Sample Scenario for identifying entities in a Library Management System. Scenario: A university library allows students and faculty to borrow and return books through an online system. Users can check the availability of books, borrow them, and return them after use. The library's internal system manages the catalog and records transactions. The system also connects with an external payment system to handle late fees. How to Identify Entities (based on the scenario) we can identify various external entities: 1. Student (or Faculty Member) o Role: The student or faculty member uses the system to search for, borrow, or return books. o Data Flow:  Input: Provides login credentials, searches for a book, submits a request to borrow or return a book.  Output: Receives notifications about book availability, loan status, and overdue fees. o Why is it an Entity?: The student or faculty member interacts with the library system but does not handle internal processing, such as book management or fine calculation. The system needs input from them and sends output in response (e.g., loan confirmation or fine notices). 2. Library Staff o Role: Staff members approve or reject book loan requests and manage book inventory. o Data Flow:  Input: Receives borrow requests and returns from students and faculty.  Output: Updates the system to approve or reject requests, manage overdue fines, and send reminders. o Why is it an Entity?: Although they manage operations, library staff interact with the system externally by handling specific tasks. They are not part of the internal processes like inventory updates or fine calculations, which are system-driven. 3. Payment o Role: Handles the payment of overdue fines. o Data Flow:  Input: Receives payment requests when a user has overdue fines.  Output: Sends confirmation of payment or failure. o Why is it an Entity?: This system is external to the library management system but is necessary for handling payments. The library system sends payment requests, and the external system processes them and sends a response back. 4. Book Supplier o Role: Supplies books to the library and updates the catalog when new books arrive. o Data Flow:  Input: Provides information about new books to be added to the system.  Output: Receives orders or requests from the library. o Why is it an Entity?: The supplier is external to the system and interacts with it by supplying books or receiving purchase orders from the library. Visualizing in a DFD (Level 0) At the context level, the library management system would have these external entities interacting with it. Here’s how the data flows between the system and the entities: Student (or Faculty Member) → (Search/Request books, borrow/return books) → Library Management System. Library Management System → (Send notifications, loan status) → Student (or Faculty Member). Library Staff → (Manage inventory, approve/reject loans) → Library Management System. Library Management System → (Send book orders) → Book Supplier. Payment System → (Handle overdue fees) → Library Management System. Library Management System → (Send fine information) → Payment System. Summary of Entities Student (or Faculty Member): An external user who interacts with the system to borrow or return books. Library Staff: External users who manage the operations related to book lending and returning. Payment: An external system that handles late fees. Book Supplier: An external entity that supplies books to the library and interacts with the system for inventory management. CONTEXT-LEVEL DATA FLOW DIAGRAM It contains only one process, representing the entire system. The process is given the number zero. All external entities are shown on the context diagram as well as major data flow to and from them. The diagram does not contain any data stores. CREATING DATA FLOW DIAGRAMS Examine the data flow to or from a data store. Analyzing a well-defined process for data requirements and the nature of the information produced. Noting and investigating unclear areas. DFD LEVELS Context DFD Overview of the organizational system Level-0 DFD Representation of system’s major processes at high level of abstraction Level-1 DFD Results from decomposition of Level 0 diagram Level-n DFD  Results from decomposition of Level n-1 diagram DFD Levels 1. Context DFD (Level 0) Overview:  Definition: The Context Diagram, also known as Level 0 DFD, provides a high- level view of the entire system as a single process.  Purpose: It illustrates the system’s boundaries, showing how it interacts with external entities (such as users, other systems, or organizations).  Components: o Single Process: Represents the entire system. o External Entities: Sources or destinations of data outside the system. o Data Flows: Arrows indicating the movement of data between the system and external entities. Example: Imagine an Online Library System.  External Entities: Users, Book Suppliers, Payment Gateway.  Single Process: Online Library System.  Data Flows: o Users request books and make payments. o Book Suppliers provide inventory updates. o Payment Gateway processes transactions. DIAGRAM (SAMPLE) 2. Overview of the Organizational System Overview: Before diving into detailed DFD levels, it's essential to understand the organizational context in which the system operates. This includes:  Business Goals: Objectives the system aims to achieve.  Key Processes: Major functions or operations within the organization.  Stakeholders: Individuals or groups with an interest in the system.  Existing Systems: Other systems that interact or integrate with the new system. Example: For the Online Library System, the organizational overview might include:  Goals: Provide easy access to books, streamline inventory management, ensure secure transactions.  Key Processes: User registration, book cataloging, order processing, payment handling.  Stakeholders: Library staff, IT department, users, suppliers.  Existing Systems: Inventory Management System, Customer Relationship Management (CRM). 3. Level-0 DFD Overview:  Definition: While sometimes used interchangeably with the Context DFD, the Level-0 DFD can also provide a slightly more detailed view by breaking down the single process into major sub-processes without going into exhaustive detail.  Purpose: To introduce the primary functions of the system and how they interact with external entities and data stores. Example: Continuing with the Online Library System:  Processes: 1. User Management 2. Catalog Management 3. Order Processing 4. Payment Handling Diagram (sample) 4. Level-1 DFD Overview:  Definition: The Level-1 DFD decomposes each major process from the Level-0 DFD into more detailed sub-processes.  Purpose: To provide a clearer view of the system’s functionality by breaking down complex processes into simpler, more manageable parts. Example: For the Order Processing process in the Online Library System:  Sub-Processes: 1. Validate Order 2. Check Inventory 3. Confirm Order 4. Update Inventory Diagram (sample) Detailed Flow:  Validate Order: Ensures user information and order details are correct.   Check Inventory: Verifies if the requested books are available.  Confirm Order: Sends confirmation to the user.  Update Inventory: Adjusts stock levels based on the order. 5. Level-n DFD Overview:  Definition: Level-n DFDs represent further decomposition of Level-(n-1) DFDs. Each subsequent level provides increasing detail until the processes are simple enough to be easily understood.  Purpose: To drill down into specific processes for detailed analysis, often used during system design and implementation phases. Example: Taking the Validate Order sub-process from the Level-1 DFD:  Level-2 DFD: 1. Verify User Credentials 2. Check Order Details 3. Confirm Payment Information Diagram (sample) Further Decomposition (Level-3):  Verify User Credentials: o Authenticate User o Retrieve User Profile  Check Order Details: o Validate Book IDs o Calculate Total Cost  Confirm Payment Information: o Process Payment o Send Receipt Digram (sample) Key Points Across All Levels:  Data Stores: Represented as open-ended rectangles, indicating where data is stored within the system (e.g., User Database, Inventory Database).  Data Flows: Arrows showing the direction of data movement between processes, data stores, and external entities.   External Entities: Boxes representing sources or destinations outside the system boundary.  Processes: Rounded rectangles or circles indicating activities that transform data. Benefits of Using DFD Levels: 1. Clarity: Breaks down complex systems into understandable parts. 2. Modularity: Facilitates focusing on individual components without getting overwhelmed by the entire system. 3. Communication: Enhances understanding among stakeholders, developers, and analysts. 4. Documentation: Provides a clear blueprint for system design and implementation. 5. Analysis: Helps identify redundancies, inefficiencies, and areas for improvement within the system. Tips for Creating Effective DFDs:  Start High, Then Drill Down: Begin with a Context Diagram and progressively decompose processes.  Maintain Consistency: Use consistent naming conventions and symbols across all levels.  Avoid Overcomplication: Each DFD level should be as simple as possible while conveying necessary details.  Validate with Stakeholders: Ensure that DFDs accurately represent the system by reviewing them with relevant parties.  Iterate as Needed: Refine DFDs based on feedback and as the system evolves. DIAGRAM 0 Diagram 0 is the explosion of the context level diagram. It should include up to 7 or 9 processes. Any more will result in a cluttered diagram. Processes are numbered with an integer. The major data stores and all external entities are included on Diagram 0. DATA FLOW DIAGRAM ERRORS The following conditions are errors that occur when drawing a data flow diagram: A process with only input data flow or only output data flow from it.  Data stores or external entities are connected directly to each other, in any combination. Incorrectly labeling data flow or objects Examples are: Labels omitted from data flow or objects. Data flow labeled with a verb. Processes labeled with a noun. Too many processes on a data flow diagram. Nine is the suggested maximum. Omitting data flow from the diagram Unbalanced decomposition between a parent process and a child diagram The data flow in and out of a parent process must be present on the child diagram. TYPICAL ERRORS IN DFD DFD DIAGRAMMING RULES Process  No process can have only outputs or only inputs…proces ses must have both outputs andlabels Process inputs.should be DFD DIAGRAMMING RULES verb phrases. DATA STORE DFD DIAGRAMMING RULES SOURCE/SINK DFD DIAGRAMMING RULES DATA FLOW  Data flow from a process to a data store means update (insert, delete or change). Data flow from a data store to a process means retrieve or use. Data flow labels should be noun phrases. DFD EXAMPLE (CONTEXT DIAGRAM) LEVEL 0-DFD LEVEL-1 DFD LEVEL-N DFD GUIDELINES FOR DRAWING DFDS Completeness DFD must include all components necessary for system. Each component must be fully described in the project dictionary or CASE repository. Consistency The extent to which information contained on one level of a set of nested DFDs is also included on other levels. Timing  Time is not represented well on DFDs. Best to draw DFDs as if the system has never started and will never stop. Iterative Development Analyst should expect to redraw diagram several times before reaching the closest approximation to the system being modeled. Primitive DFDs Lowest logical level of decomposition Decision has to be made when to stop decomposition Rules for stopping decomposition When each process has been reduced to a single decision, calculation or database operation When each data store represents data about a single entity When the system user does not care to see any more detail Rules for stopping decomposition When every data flow does not need to be split further to show that data are handled in various ways When you believe that you have shown each business form or transaction, online display and report as a single data flow When you believe that there is a separate process for each choice on all lowest- level menu options DESCRIBING SYSTEMS WITH DFD & LEVELLING DFDs  An entire system is represented by one DFD which gives the system’s overview It is called a context diagram. It gives little detail & is also known as the top level DFD. LEVELLING DFD A context diagram gives an overview, it should be split into major processes which give greater detail. Each major process is further split to give more detail. Each major process is further split to give more detail. WHY Level DFD? If a DFD is too detailed it will have too many data flows and will be large and difficult to understand. Therefore start from a broad overview. Expand the details - Idea similar to using procedures and linking these with a main program. Each DFD must deal with one aspect of a big system LEVELLING Rules  If process p is expanded, the process at the next level are labeled as p.1,p.2 etc.  All data flow entering or leaving p must also enter or leave its Expanded version.  Expanded DFD may have data stores  No new external entity can appear in expanded DFD  Keep the number of processes at each level less than 7.