Process Modeling – DFD Chao-Hsien Chu, Ph.D. School of Information Sciences and Technology The Pennsylvania State University DFD IDEF.

Slides:



Advertisements
Similar presentations
CAPE INFORMATION TECHNOLOGY – Unit 2
Advertisements

Software Engineering-II
Systems Analysis Requirements structuring Process Modeling
SYSTEMS ANALYSIS AND DESIGN TOOLS
Using Data Flow Diagrams
Chapter 7 Structuring System Process Requirements
Using Dataflow Diagrams
© 2005 by Prentice Hall 7-1 Chapter 7 Structuring System Process Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey.
PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and Design, 2 nd Edition Copyright 2003 © John Wiley & Sons, Inc. All rights reserved.
Chapter 4 Enterprise Modeling.
1 Introduction to Data Flow Modelling The data flow approach to requirements determination in building a system for business use. This type of computer.
Systems Analysis and Design 9th Edition
Chapter 7 Using Data Flow Diagrams
Jump to first page Chapter 2 System Analysis - Process Modeling.
Chapter 7 Using Data Flow Diagrams
Modern Systems Analysis and Design
Structuring System Requirements: Process Modeling
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 8 Structuring.
Chapter 9 Using Data Flow Diagrams
Modeling the Processes and Logic
Chapter 4.
System Analysis and Design
DATA FLOW DIAGRAMS IT 155.
 A data flow diagram ( DFD ) is a graphical representation of the "flow" of data through an information system.  A data flow diagram can also be used.
Chapter 7 Structuring System Process Requirements
National Diploma in Systems Analysis and Design Data Flow Modelling.
staffs.ac.uk Process Model. staffs.ac.uk Contents Provide definitions Explain the components and representations Introduce a step.
1 Structured Analysis Techniques. 2 Data Flow Diagrams.
Chapter 8 Structuring System Requirements: Process Modeling
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 6.1.
Data Flow Diagrams (DFDs)
Chapter 1: Data Flow Diagram Structuring System Process Requirements
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 6.1.
PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and Design Copyright 2000 © John Wiley & Sons, Inc. All rights reserved. Slide 1 Process.
Business Process Management. Key Definitions Process model A formal way of representing how a business operates Illustrates the activities that are performed.
Data Flow Diagrams.
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall Essentials of Systems Analysis and Design Fourth Edition Joseph S. Valacich Joey F.
Computer System Analysis Chapter 8 Structuring System Requirements: Process Modeling Dr. Sana’a Wafa Al-Sayegh 1 st quadmaster University of Palestine.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 8 Structuring.
Chapter 7 Structuring System Process Requirements
Chapter 7 Using Data Flow Diagrams
SAD - DFD Context Diagrams
SYSTEMS ANALYSIS AND DESIGN TOOLS DATA FLOW DIAGRAMS.
DFDs (Data Flow Diagrams). Data Flow Diagrams DFDs are a system modeling tool, the most popular and important representation in data flow modeling. DFDs.
7. ANALYZING REQUIREMENTS- (Data Flow Diagrams)
Chapter 4 enterprise modeling
System Decomposition Overview. Data Flow Diagrams Despite the name “Data Flow Diagrams”, DFD have a process, rather than a data, focus We represent all.
Using Dataflow Diagrams – Part 1 Systems Analysis and Design, 7e Kendall & Kendall 7 © 2008 Pearson Prentice Hall.
IS3320 Developing and Using Management Information Systems Lecture 16: Data-Flow Diagrams 1 (Intro to Context-Level diagrams) Rob Gleasure
Modern Systems Analysis and Design Fifth Edition
Chapter 7 Structuring System Process Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich.
Systems Analysis and Design 8th Edition
CS223: Software Engineering
© 2005 by Prentice Hall Chapter 7 Structuring System Process Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George.
McGraw-Hill/Irwin Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 5 Modeling the Processes and Logic.
DATA FLOW DIAGRAMS.
C_ITIP211 LECTURER: E.DONDO. Unit 3 : PROCESS MODELING.
MIS 360: System Analysis and Design Dr. Qasem Al-Radaideh Department of Computer Information Systems Faculty of Information Technology Yarmouk University.
7-1 Chapter 7 Structuring System Process Requirements Modern Systems Analysis and Design Fourth Edition.
Chapter 6 Structuring System Requirements: Process Modeling
Process Modeling Graphically represent the processes that capture, manipulate, store, and distribute data between a system and its environment Models DFDs.
Modern Systems Analysis and Design Third Edition
Chapter 1: Data Flow Diagram Structuring System Process Requirements
Process & Logic Modeling
Chapter 6 Structuring System Requirements: Process Modeling
Modern Systems Analysis and Design Third Edition
Requirement Analysis using
Chapter 7: Data Flow Diagram Structuring System Process Requirements
Modern Systems Analysis and Design Third Edition
Chapter 4: documenting information systems
Presentation transcript:

Process Modeling – DFD Chao-Hsien Chu, Ph.D. School of Information Sciences and Technology The Pennsylvania State University DFD IDEF

Enterprise Modeling Requirement Analysis Normalization Data Modeling Process Modeling Process Analysis Process Improvement Process Redesign Data Management Organization Modeling Network Modeling

Building Blocks of Process Process Activity Work Item Data Item

What is DFD? DFD, stands for data flow diagram, is a graphical technique that depicts information flow and the transforms that are applied as data moves from input to output. DFD is also known as data flow graph or a bubble chart. A DFD can be seen as a method of organizing data from its raw state.

Characteristics of DFD Graphic Partitioned Hierarchic Multidimensional Emphasize flow of data Viewpoint of data and process Materials Information Cash

Facts About DFDs Not all models use control information in their DFD. Some models describe manual as well as computer activities in their DFD. DFD’s go from left to right, up and down or other directions. Notations (symbols) in DFDs differ heavily. A minimum or a lot of explaining text around the symbols in a DFD.

Symbols for DFD id Text id Data store Process name External Interactor Text External Entity: Source or destination of data Process: Action on data Data Store: Storage of data Data Flow: Data Transfer Yourdon- Constantine Game- Sarson

Data Flow Diagram Example An employment system An applicant submits an application form, which is reviewed by the personnel section and filed. A request for reference letter is sent to the references named by the applicant. After one-week a summary of reference reports received is prepared and a decision is made whether or not to interview. Unsuccessful applicants are sent a standard rejection letter. An interview is scheduled with likely applicants, and references are stored with the applicant details. Applicants are interviewed and a decision is made on who to hire. Unsuccessful interviewees are sent a commiseration letter, while the successful applicant is sent an employment contract

Data Flow Diagram Example An applicant submits an application form, which is reviewed by the personnel section and filed. A request for reference letter is sent to the references named by the applicant. Job Applications Applicant Referees Application Form Request for reference Receive & Review Application

Data Flow Diagram Example After one-week a summary of reference reports received is prepared and a decision is made whether or not to interview. Unsuccessful applicants are sent a standard rejection letter. reference data Rejection or Interview Advice Check References Summarise Referees Job Applications Applicant

External Entity External entity represents the sources and destination of data created by the system. External entity represents the immediate interface of the system with the external world. When an external source of data is also a destination for data, a loop or occurrence number may be used. In case the destination or use of data created by the process are not known, the flow simply points outside the system. Similarly, data flows may originate from “nowhere”.

Process Boxes Each processes box in a DFD describes an action on data. The Identifier. A number indicating the sequence of the process. The Action. A verb specifying the action on which it is performed on the data. The Actor or Place. A noun indicating who performs the action or where it is performed.

Data Flow Arrows Data flow arrows link all the process boxes and data stores in DFDs. Data flows should be labeled, except in case the data flows into and out of simple files. DFDs show only the flow of data, not materials. A DFD depicts information flow without explicit representation of procedural logic (e.g., conditions or loops).

Data Store Rectangles Data stores can be manual files or computer files. The type of file is not indicated. Only in case the data store is altered the flow is not indicated. A simple access is not indicated. A data store is never the direct recipient of unprocessed data from external sources or from other data stores nor is data from a data store ever directly delivered to an external sources. There must be a process step in between.

A data item stored in the data store is read by a process Examples of Data Stores Read W rite Read/ Write A data item is created or deleted or updated in the data store by a process

Rules for Constructing DFDs Overall: 1.Know the purpose of the DFD. It determines the level of detail to be included in the diagram. 2.Organize the DFD so that the main sequence of actions reads left to right and top to down. 3.Very complex or detailed DFDs should be leveled. Processes: 1.Identify all manual and computer processes. 2.Label each process symbol with an active verb and the data involved. 3.A process is required for all data transformations and transfers. 4.Do not indicate hardware or where a process is manual or computerized.

Rules for Constructing DFDs Data Flows: 1.Identify all data flows for each process, except simple record retrievals. 2.Label data flows on each arrow. Data Stores: 1.Data not indicate file types for data stores. 2.Draw data flows into data stores only if the data store will be changed. External Entities: 1.Indicate external sources and destination of data when known. 2.Number each occurrence of repeated external entities. 3.Do not indicate actors or places as entity squares when the process is internal to the system.

DFD Not Allowed Flows

If part of our system If not part of our flow ignore

Data Flows Only one direction of flow between processes

Data Flows Joins & forks allowed only if exactly the same data

Data Flows Cannot go directly back to the process it leaves

Data Flows Data which moves together should be shown in a single data flow itemised calls invoice payment itemised calls And invoice Pay Invoice Telephone Company Pay Invoice Telephone Company invoice payment

DFD Rules IncorrectCorrect

DFD Rules Incorrect Correct

DFD Rules IncorrectCorrect

Naming Use process name as a qualifier Edit Invoice Edited Invoice Verify Invoice Verified Invoice

Naming To avoid clutter external agents can be duplicated indicated by a corner line

Modeling Procedure Determine requirements/purposes. Divide activities. Model separate activities Construct preliminary context diagram. Construct preliminary level 0 diagrams. Deepen into preliminary level n diagrams

Creating a Data Flow Diagram The level 0 should depict the software/system as a single bubble Primary input and output should be carefully noted Refinement should begin by isolating candidate processes, data items and stores to be represented at the next level

Creating a Data Flow Diagram All arrows and bubbles should be labelled with meaningful names Information flow continuity must be maintained from level to level One bubble at a time should be refined

Producing DFDs Pretend you are looking at the system from above Record where you go and what happens to you as you sit on each data flow in turn, record each process as you as the data flow is being transformed –Start with an high-level summary –Build on this detail –Do not try and draw the final product first time round refine and redraw –Check it

Hierarchical DFDs DFDs are hierarchically structured The top-level is referred to as the context diagram (or fundamental system model or the level zero design) the purpose of the context diagram is to define external to the system interfaces and identify system boundaries

Hierarchical DFDs The system of interest is usually contained in a single process bubble Subsequent DFD levels will show increasing system detail –label clearly all DFD symbols Stop when –each process is a single decision or operation –each data store has data for a single entity –when every data flow does not need to be split to handle different flows

Decomposition Conventions Ensure no information is lost –balancing –hierarchical numbering –add data stores at lower levels, if they are internal to the higher level process, not at context diagram –external agents are introduced at level-0 never at owner levels

Level 0 DFD Origin #1 Destination 2 System a b c z r Destination 1 Origin #2

Level 1 DFD 1.1 a b c z r d e f gh i

Level 2 DFD c f

Usages of DFDs Requirements Analysis. DFDs has been used to transform users requirements to processes, entities, and data stores. Process Modeling. Systems Implementation. Understanding Communication Improvement

Thank You? Any Question?

Balancing The conservation of input and output flows through different levels A B C A B C D E

Data-flow models Show the processing steps as data flows through a system Intrinsic part of many analysis methods Simple and intuitive notation that customers can understand Show end-to-end processing of data

Data-flow diagrams may be used to show processing at different levels of abstraction from fairly abstract to fairly detailed May also be used for architectural description showing data interchange between the sub- systems making up the system Not a good way to describe system interfaces

Data Flow Diagrams They show the overall data flow through a system and they do NOT show –control –order –time –errors It is primarily a systems analysis tool used to draw the basic procedural components and the data that pass among them

DFDs Physical –describes operations of existing system, however badly the existing system is performing. This is essential in the fact finding stage of the life cycle Logical –shows the essential processes and data interfaces, without reference to design or implementation Can be Current and NEW current physical or logical new logical

DFD Elements Sources and sinks (or external entities or terminators) –a producer or consumer of information that resides outside the bounds of the system to be modelled –can be a person, another system, a program, hardware,… –usually a singular noun is used to name the source or sink

DFD Elements Processes (or functions or data transformations) –a transformer of information that resides within the bounds of the system to be modelled –it receives the data and changes it in some way –if not decomposed usually a verb and noun together describe the activity –if decomposed then a verb is used to name the process

DFD Elements Data flows (directional) –represent the flow of data item of a collection of data items from one node to another a node can be a process, a source, or a data store –can be input or output information –the arrowhead indicates the direction of data flow –all arrows should be labelled (a data flow into or out of a data store may be nameless in which case it is assumed to carry the entire contents of one record in the store) usually with a singular noun

DFD Elements Data stores –a repository of data that is to be stored for use by one or more processes –usually named using a plural noun (the singular describes the individual data items in the store)

Naming Too general process names should define a specific action data stores should store only a single structure Receive Data Needed data information Store