Data Flow Diagram - DFD Levels, Symbols, Case Study, Tutorial, Example,

  Difference between Uses and Extends Probably the best way to think about these diagram elements is as follows:- "X uses Y" indicates that the task "X" has a subtask "Y"; that is, in the process of completing task "X", task "Y" will be completed at least once. "X extends Y" indicates that "X" is a task for the same type as "Y", but "X" is a special, more specific case of doing "Y". That is, doing X is a lot like doing Y, but X has a few extra processes to it that go above and beyond the things that must be done in order to complete Y.

Uses Arrow: The uses arrow (or uses edge as it would be called in traditional graph theory) is drawn from a use case X to another use case Y to indicate that the process of doing X always involves doing Y at least once (although it may involve doing it many times, "at least once" is the only relationship guaranteed by this symbol.) This symbol can be referred to as an aggregation operator, because it indicates that a given use case is an aggregate (made up of parts) whose components are the use cases that it uses. If a certain use case uses several others, that means that all of the component use cases must be completed in the process of completing the aggregate use case, although there is no specification in Use Case Diagrams of the order in which these are completed. A brief, mnemonic way to think about the uses arrow is that it can be read X uses Y means that "X has a Y" as part of it's behaviour.   Extends Arrow: The extends arrow (or extends

 How to Find Actors for Use Case Diagram? When working from an Action/Response table, identifying the actors is easy: entities whose behaviour appears in the "Actor's Actions" column are the actors, and entities whose behaviour appears in the "System's Response" column are components in the system. If you are working from an informal narrative, a sequence diagram, or a scenario description, the actors are typically those entities whose behaviour cannot control or change (i.e., agents that are not part of the system that you are building or describing.) The most obvious candidates for actors are the humans in the system. Except in rare cases when the system you are describing is actually a human process, such as a specific method of dealing with customers that employees should follow, the humans that you must interact with will all be actors. If your system interacts with other systems (databases, servers maintained by other people, legacy sy

Introduction to Use Case Diagram UML Use Case Diagrams can be used to describe the functionality of a system in a horizontal way. That is, rather than merely representing the details of individual features of your system, Use Case Diagrams can be used to show all of its available functionality. It is important to note, though, that Use Case Diagrams are fundamentally different from sequence diagrams or flow charts because they do not make any attempt to represent the order or number of times that the systems actions and sub-actions should be executed. There are a number of graphical examples in this FAQ; you might want to look over them to familiarise yourself with the look of them. Use Case Diagrams have only 4 major elements: ·          the actors that the system you are describing interacts with ·          the system itself ·          the use cases, or services, that the system knows how to perform ·          the lines that represent relationships between these

The Unified Modeling Language (UML) is a general-purpose visual modeling language that is used to specify, visualize, construct, and document the artifacts of a software system. It captures decisions and understanding about systems that must be constructed. It is used to understand, design, browse, configure, maintain, and control information about such systems. It is intended for use with all development methods, life cycle stages, application domains, and media. The modeling language is intended to unify past experience about modeling techniques and to incorporate current software best practices into a standard approach. UML includes semantic concepts, notation, and guidelines. It has static, dynamic, environmental, and organizational parts. It is intended to be supported by interactive visual modeling tools that have code generators and report writers. The UML specification does not define a standard process but is intended to be useful with an iterative development process. It is

The purpose of Data Flow Diagrams is to show the “flow” and transformation of data through the system.  These diagrams are used as a visualization tool to help the audience get a better idea of what exactly is going on in the system.     A Context Diagram is shown next, which is the general overview of each of the different agents interacting with the system.    The Level 0 Diagram shows some more details about which processes each of the agents will be interacting with.  Arrows are drawn to show the flow of data between the agents and processes.    Following the Level 0 Diagram are Level 1, Level 2, Level 3 and Level 4 Diagrams.  These Diagrams further break down each of the processes that are involved with the system, each showing more detail the further down the level is.

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. On a DFD, data items flow from an external data source or an internal data store to an internal data store or an external data sink, via an internal process. A DFD provides no information about the timing of processes, or about whether processes will operate in sequence or in parallel. It is therefore quite different from a flowchart, which shows the flow of control through an algorithm, allowing a reader to determine what operations will be performed, in what order, and under what circumstances, but not what kinds of data will be input to and output from the system, nor where the data will come from and go to, nor where the data will be stored (all of which are shown on a DFD). It is common practice to draw the context-level data flow diagram first, which shows the interaction between t

Data Flow Diagram (DFD) Summary Data Flow Symbols Unique Names for Data Flows.   No two data flows should ever have the same name.  (Remember, data is transformed by a process, so the input and output data flows from a process will have different names.) Data Flows should be consistent and cascade among levels. For example, if a “Student” EE provides an application to a process on a level 1 DFD (Figure 1 or Figure 2 or Figure 3), then it must appear on the Figure 0 DFD and the context diagram As a quick double-check before you turn in home work and projects: Count all the data flows on your context diagram from each EE.  On the level 0 diagram, the counts should be the same.  Cascade this rule for each subordinate level. NOTE: You should perform this same check for each data store. Process Symbols DFD Process symbols have 3-parts : a numeric id on top, a verb-object process label in th

Rules for Stopping the Decomposition Process in DFD (1) when you have reduced each process to a single decision or calculation or to a single database operation;  (2) when each data store represents data about a single entity;  (3) when the system user does not care to see any more detail or when you and other analysts have documented sufficient detail to do subsequent systems development tasks;  (4) when every data flow does not need to be split further to show that different data are handled in different ways;  (5) when you believe that you have shown each business form or transaction, computer on-line display, and report as a single data flow;  (6) when you believe there is a separate process for each choice on all lowest-level menu options for the system.

To construct a data flow diagram: Maintain a consistent level of detail with between five and nine symbols per page.  Data flow arrows do not cross each other. Label your data flow arrows first - these are the most important items - and your processes circles last Process circles may have several arrows flowing into and out of them An arrow from a data store always go to a process.  An arrow to a data store always comes from a process Include a descriptive narrative that explains the data flow diagram

DEFINING DATA FLOW DIAGRAMS (DFDs) When it comes to conveying how information data flows through systems (and how that data is transformed in the process), data flow diagrams (DFDs) are the method of choice over technical descriptions for three principal reasons. 1. DFDs are easier to understand by technical and nontechnical audiences 2. DFDs can provide a high level system overview, complete with boundaries and connections to other systems 3. DFDs can provide a detailed representation of system components 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 analysts prefer working with DFDs, particularly when they require a clear understanding of the boundary between existing systems and postulated systems. DFDs represent the following: 1. External devices sending and receiving data 2. Processes that change that data 3. Data flows themselves 4. Data storage locations

Structured analysis is a development method for the analysis of existing manual or automated systems, leading to the development of specifications for a new or modified system. The underlying objective in structured analysis is to organise the tasks associated with requirements determination to provide an accurate and complete understanding of a current situation. The word structure in structured analysis means: 1.The method attempts to structure the requirements determination process, beginning with documentation of the existing system. 2.The process is organised in such a way that it attempts to include all relevant details that describe the current system. 3. It is easy to verify when relevant details have been omitted. 4. The identification of requirements will be similar among individual analysts and will include the best solutions and strategies for systems development opportunities. 5. The working papers produced to document the existing and proposed systems are effecti

How to Derive Logical DFD from Physical DFD? Physical DFDs are a means to an end, not an end in themselves. They are drawn to describe an implementation of the existing system for two reasons: ·   to ensure a correct understanding of the current implementation (users are generally better able to discuss the physical system as they know it through people, workstations and days of the week.) ·   the implementation itself may be a problem or limiting factor; changing the implementation, rather than the system concept may provide the desired results. A logical view steps back from the actual implementation and provides a basis for examining the combination of processes, data flows, data stores, inputs and outputs without concern for the physical devices, people or control issues that characterise the implementation. A logical data flow diagram is derived from the physical version by doing the following: ·   Show actual data needed in a process, not the documents that contain them.

The Level 1 DFD presents us with an overview of the system, a description that could come from a preliminary interview with departmental managers, perhaps. Now we must examine each process in more detail and break it down into other processes. The following steps explain how this is done. Step 1. Make each process box the system boundary. All data flows to or from that process are now flows across the lower-level system boundary. Step 2. Draw, outside the new boundary, the sources and recipients of these flows, as shown on the higher level DFD, (these can be external entities, data stores or other processes. Ensure the labelling is consistent with the higher level. Step 3. Identify and draw the processes at the lower levels that act on these data flows. Number the sub-processes with a decimal extension of the higher level number. i.e. Level 1, Process 3 will break down to processes 3.1, 3.2, 3.3 etc. Those processes that cannot be decomposed further, mark with an asterisk in the

There are many errors that may occur when drawing data flow diagrams. Here is a check list to help you avoid some of the major difficulties. External entities must be people or systems that send information to or accept information form the system to be engineered Data flows must always be labelled with the data they contain. Do not put verbs in the data flow description as this implies a process Parent and child diagrams should be consistent. Do not shows a data flow coming from or to an external entity on a level 1 DFD that isn’t shown on the context diagram (and vice versa). Check the direction of data flows to and from data stores Make sure each process has at least one input and one output Each data store should have at least one input and one output on the DFDs somewhere Each process name should start with a verb Where a process has only two data flows (one input and one output) then check it. Usually a data flow has been omitted.

The normal stages are Model the current system as it is presently implemented. It is rare that a system is designed to do something entirely new. Normally the intention is to make an existing system efficient by automating it to streamline more than one system by integrating them to replace a sequence of tasks with a new process The DFD drawn at the end of this stage is called the Current Physical System. The main characteristics of a Physical DFD are that a user will recognise how a system currently operates, warts and all. It should not attempt to improve the system, although it may document problems. The essential activities of the system are extracted. What is now left is just the data, information stores and starts and destinations. What is removed is physical things like any IT used, the media on which the data is recorded and stored, and who does what. The idea is to focus attention on what is being done to the data and free the mind from

All the data flows are labelled and describe the information that is being carried. It tends to make the diagram easier to read if the processes are kept to the middle, the external entities to the left and the data stores appear on the right hand side of the diagram. The process names start with a strong verb Each process has access to all the information it needs. In the example above, process 4 is required to check orders. Although the case study has not been given, it is reasonable to suppose that the process is looking at a customer’s order and checking that any order items correspond to ones that the company sell. In order to do this the process is reading data from the product data store. Each process should have an output. If there is no output then there is no point in having that process. A corollary of this is that there must be at least one input to a process as it cannot produce data but can only convert it form o

A Data Flow Diagram (DFD) is a diagrammatic representation of the information flows within a system showing How information enters and leaves the system  What changes the information  Where information is stored The purpose of a DFD is To show the scope and boundaries of a system  To show that the whole system has been considered May be used as a communications tool between a systems analyst and any person who plays a part in the system To act as the starting point for redesigning a system 

All information systems respond to events and conditions in the system’s environment. System’s environment includes external agents that form the boundary of the system and define where the system interfaces with its environment. It’s also referring to source or sink. External agents give an input to a system and receive an output from the system. An external agent of an information system are already fixed and defined. When the system is getting big, the external agents may be changed. An external agent can be an outside person, organization unit, system or organization that interacts with a system and eternal organization It can be such as : ·          An office, department, division or individual from the same organization ·          An organization, agency, or individual that is outside the organization ·          Another business or information system ·          System’s end users or managers The name of the entity appears inside the symbols. External agents should be named wit

Process modeling is a formal way of representing how an information system operates. It illustrates the processes or activities that are performed and how data moves among them in the system environment. Process modeling involves representing the functions, processes, manipulate, store and distribute the data among them and its environment. There are many different process modeling techniques can be used today. The most popular one is Data flow diagram (DFD). Data flow diagramming is a technique that diagrams the processes and the data passes among them in the system. It’s a traditional process modeling technique of structured analysis and design. Data flow diagram uses various symbols to show how the system transforms input data into useful information. There are two standard sets of data flow diagram symbols being used; DeMarco and Yourdon and Gane and Sarson.

Data Flow Diagrams :  graphical system model that shows all main requirements for an IS in one diagram. Inputs/outputs, processes, data storage. DFD’s and levels of abstraction: Higher-level diagrams provide general views of system Lower-level diagrams provide detailed views of system Differing views are called levels of abstraction. Context diagrams: DFD   that summarizes all processing activity for the system or subsystem Highest level (most abstract) view of system Shows system boundaries System scope is represented by a single process, external agents, and all data flows into and out of the system. DFD fragments: Created for each use case in the event table Represent system response to one event within a single process symbol Self-contained models Focus attention on single part of system Show only data stores required in the use case Event-partitioned system model: DFD to model system requirements using single process for each use case/activity in system or sub

Data Flow Symbols Unique Names for Data Flows.   No two data flows should ever have the same name.  (Remember, data is transformed by a process, so the input and output data flows from a process will have different names.) Data Flows should be consistent and cascade among levels. For example, if a “Student” EE provides an application to a process on a level 1 DFD (Figure 1 or Figure 2 or Figure 3), then it must appear on the Figure 0 DFD and the context diagram As a quick double-check before you turn in home work and projects: Count all the data flows on your context diagram from each EE.  On the level 0 diagram, the counts should be the same.  Cascade this rule for each subordinate level. NOTE: You should perform this same check for each data store. Process Symbols DFD Process symbols have 3-parts : a numeric id on top, a verb-object process label in the middle, and an actor-place-system identifier

Reasons for Partitioning Data Flow Diagram: 1.Different user groups: Are the processes performed by several different user groups, often at different physical locations in the company? If so, they should be partitioned into different computer programs. 2.Timing: Processes that execute at different times must be in separate programs 3.Similar tasks: May be included in the same program 4.Efficiency: Several batch processes may be included in the same program for efficiency 5.Consistency: Several processes may be included in the same program or job stream for consistency of data. 6.Security: May be partitioned into different programs for security reasons.

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 Drawing Diagram 0: The explosion of the context diagram May include up to nine processes Each process is numbered Major data stores and all external entities are included Start with the data flow from an entity on the input side Work backwards 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 Data Flow Diagram Levels: Data flow diagrams are built in layers The top level is the Context level Each process may explode to a lower level The lower level diagram number is the same as the parent process number Processes that do not create a child diagram are called primitive Creating Child Diagrams: Each process on diagram 0 may be exploded to create a child diagr