Lecture Note 7 Using Data Flow Diagrams

Slides:



Advertisements
Similar presentations
CAPE INFORMATION TECHNOLOGY – Unit 2
Advertisements

Data Flow Diagram (DFD) Review
SYSTEMS ANALYSIS AND DESIGN TOOLS
Using Data Flow Diagrams
Using Dataflow Diagrams
Chapter 4 Enterprise Modeling.
Chapter 4.
Systems Analysis and Design 9th Edition
Dataflow modelling: Context and Data Flow Diagrams
Chapter 7 Using Data Flow Diagrams
Jump to first page Chapter 2 System Analysis - Process Modeling.
Chapter 9 Describing Process Specifications and Structured Decisions
Using Dataflow Diagrams
Chapter 7 Using Data Flow Diagrams
Topics Creating DFD Physical and logical DFD Event driven modeling
Structuring System Requirements: Process Modeling
Data and 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
Chapter 7 Using Data Flow Diagrams
Modeling the Processes and Logic
L ECTURE 9 – PROCESS MODELLING PART 1 Data Flow Diagrams for Process Modelling Multi-level Data Flow Diagrams Logical Vs Physical DFDs Steps to Construct.
Chapter 4.
The Traditional Approach to Requirements: Using Dataflow Diagrams Spring
Systems Analysis I Data Flow Diagrams
System Analysis and Design
DATA FLOW DIAGRAMS IT 155.
Process Modeling SYSTEMS ANALYSIS AND DESIGN, 6 TH EDITION DENNIS, WIXOM, AND ROTH © 2015 JOHN WILEY & SONS. ALL RIGHTS RESERVED. 1 Roberta M. Roth.
Lecture Note 8 Using Data Flow Diagrams
Chapter 7 Structuring System Process Requirements
Traditional Approach to Requirements Data Flow Diagram (DFD)
Systems Analysis and Design 10th Edition
System Analysis Overview Document functional requirements by creating models Two concepts help identify functional requirements in the traditional approach.
Chapter 8 Structuring System Requirements: Process Modeling
Data Flow Diagrams (DFDs)
Systems Analysis – Analyzing Requirements.  Analyzing requirement stage identifies user information needs and new systems requirements  IS dev team.
Chapter 9 Describing Process Specifications and Structured Decisions
Business Process Management. Key Definitions Process model A formal way of representing how a business operates Illustrates the activities that are performed.
Phase 2: Systems Analysis
Data Flow Diagram A method used to analyze a system in a structured way Used during: Analysis stage: to describe the current system Design stage: to describe.
Using Dataflow Diagrams – Part 2 Systems Analysis and Design, 7e Kendall & Kendall 7 © 2008 Pearson Prentice Hall.
Chapter 7 Structuring System Process Requirements
Chapter 7 Using Data Flow Diagrams
SYSTEMS ANALYSIS AND DESIGN TOOLS DATA FLOW DIAGRAMS.
Chapter 4 enterprise modeling
System Analysis System Analysis - Mr. Ahmad Al-Ghoul System Analysis and Design.
Using Dataflow Diagrams – Part 1 Systems Analysis and Design, 7e Kendall & Kendall 7 © 2008 Pearson Prentice Hall.
Modern Systems Analysis and Design Fifth Edition
Systems Analysis and Design 8th Edition
Context Process0. student Data Flow Diagram Progression.
Systems Analysis and Design 8th Edition
1Lecture 8 Introduction to Systems Analysis l Objectives –Explain how systems analysis relates to business needs, problems, and opportunities –List and.
Information System Analysis Topic-2. Data Gathering Observations Questionnaires Interviews.
© 2005 by Prentice Hall Chapter 7 Structuring System Process Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George.
SYSTEMS ANALYSIS AND DESIGN ITDB 2101 HAND OUT # 3 1.
McGraw-Hill/Irwin Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 5 Modeling the Processes and Logic.
C_ITIP211 LECTURER: E.DONDO. Unit 3 : PROCESS MODELING.
Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall Using Dataflow Diagrams Systems Analysis and Design, 8e Kendall & Kendall 7.
© 2006 Prentice Hall Business Publishing Accounting Information Systems, 10/e Romney/Steinbart1 of 37 C System Process Modeling DATA Flow Diagrams.
Information System Analysis Topic-2. Data Gathering Observations Questionnaires Interviews.
Systems Analysis and Design in a Changing World, Fourth Edition
Information System Analysis
IS 334 information systems analysis and design
Ch 7: using Data Flow Diagrams
Welcome to my presentation
Chapter 6 Structuring System Requirements: Process Modeling
Chapter 11 Describing Process Specifications and Structured Decisions
Chapter 4: documenting information systems
Keng Siau Department of Management University of Nebraska - Lincoln
Presentation transcript:

Lecture Note 7 Using Data Flow Diagrams Part III: The Analysis Process Lecture Note 7 Using Data Flow Diagrams Systems Analysis and Design Kendall & Kendall Sixth Edition

CS206 Syatem Analysis & Design Note 7 By ChangYu Major Topics Data Flow Diagram Symbols Data Flow Diagram Levels Creating Data Flow Diagrams Physical and Logical Data Flow Diagrams Partitioning CS206 Syatem Analysis & Design Note 7 By ChangYu

Basic Concepts Process Model: is a formal way of representation to show how a business system operates. It involves graphically representing the functions, or processes, which capture, manipulate, store, and distribute data between a system and its environment, and between components within a system. Data Flow Diagram: (DFD) is one of the most commonly used techniques available for process modeling. It is a picture of the movement of data between external entities, the processes and stores within a system.

Data Flow Diagrams DFDs are one of the main methods available for analyzing data-oriented systems. DFDs emphasize the logic underlying (成為 .. 的基础) the system. The systems analysts can put together a graphical representation of data movement through the organization. Data flow diagrams can be used for several different purposes: Unexploded (非探索) data flow diagrams are useful to identify information requirements. Meaningful labels should be used for good communication.

Advantages of the Data Flow Diagram Approach Four advantages over narrative (敘述) explanations of data movement: Freedom from committing to the technical implementation too early. Understanding of the interrelationships of systems and subsystems. Communicating current system knowledge to users. Analysis of the proposed system to determine if the necessary data and processes have been defined.

Basic Symbols A double square for an external entity--a source or destination of data. An arrow for movement of data from one point to another. A rectangle with rounded corners for the occurrence of transforming process. An open-ended rectangle for a data store.

External Entities The double square is used to depict (描寫) an external entity that can send data to or receive data from the systems. External entity shows the initial source and final recipient of data and information. External entity 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 A processes may represent either: A whole system when naming a context process. (INVENTORY CONTROL SYSTEM) A subsystem. (INVENTORY REPORTING SUBSYSTEM) Work being done, an activity by using a verb-adjective-noun format for detailed processes. (PRINT BACKORDERED REPORT, ADD INVENTORY RECORD) A process must be given a unique identifying number indication its level in the diagram.

Data Stores Name with a noun, describing the data Data stores are usually given a unique reference number, such as D1, D2, D3. The data store symbol is simply showing a depository for data that allows examination, addition and retrieval of data. 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.

Developing Data Flow Diagrams Top-Down approach: Make a list of business activities and use it to determine various External Entities, Data Flows, Processes, Data Stores. Create a Context Diagram which shows external entities and data flows to and from the system. Do not show any detailed processes or data stores. Draw Diagram 0, the next level. Show processes, but keep them general. Show data stores at this level. Create a Child Diagram for each of the processes in Diagram 0.

Check for Errors and make sure the labels you assign to each process and data flows are meaningful. Develop a Physical DFD from the logical DFD. Distinguish (分開) between manual and automated processes, describe actual files and reports by name, and add controls (conditions) to indicate when processes are complete and errors occur. Partition the physical DFD by separating or grouping parts of the diagram in order to facilitate (促進) programming and implementation.

DFD 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 (簡單).

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.

Diagram 0 (The Next Level) Diagram 0 is the more detail next level of the context level diagram. It should include up to 7 or 9 processes and showing data stores and new lower-level data flows. Processes are numbered with an integer. (start from the upper left-hand corner of the diagram and working toward the lower right-hand corner). The major data stores and all external entities are included on Diagram 0.

Some suggestions for drawing a DFD Start with the data flow from an entity in the input side. Ask: “What happens to the data entering the system?” “ Is it stored?”. “Is it input for several processes?”. Work backwards from an output data flow. Examine the output fields on a document or screen. Ask: “Where does it come from?”. “Is it calculated or stored in a file?”. Examine the data flow to or from a data store. Ask: “What processes put data into the store?”. “What processed use the data?”. Analysis the well-defined process. Look at what input data the process needs and what output it produces. Then connect the input and output to the appropriate data stores and entities. Take note of any fuzzy areas where you are unsure of what should be included or of what input or output is required.

Child Diagrams (More Detailed Levels) Each process on diagram zero may be exploded to create a child diagram. Each process on a lower-level diagram may be exploded to create another child diagram. These diagrams found below Diagram 0 are given the same number as the parent process. Process 3 would explode to Diagram 3. Each process is numbered with the parent diagram number, a period, and a unique child diagram number. Examples are: 3.2 on Diagram 3, the child of process 3. 5.2.7 on Diagram 5.2, child of process 5.2. On Diagram 3, the processes would be numbered 3.1, 3.2, 3.3 and so on.

External 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. A lower-level diagram may contain data stores not shown on the parent process, such as: A file containing a table of information (such as a tax table). A file linking two processes on the child diagram. Minor data flow, such as an error line, may be included on a child diagram.

An interface data flow is data that are input or output from a child diagram that matches the parent diagram data flow. Processes that do not create a child diagram are called primitive (簡單) processes. Logic is written for these processes.

Rules for Drawing a DFD 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. Each process transforms data and must receive input and produce output. Calculate Grade has an input that is obviously unable to produce the output.

Data stores and external entities must connect only with a process. Data stores or external entities are connected directly to each other, in any combination. Data stores and external entities must connect only with a process.

Incorrectly labeling data flow or objects. E.g.: 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.). If more then nine processes are involved in a system, group some of the processes that work together into a subsystem and place them in a child diagram. Omitting (遺漏) data flow from the diagram. Creating unbalanced decomposition between a parent process and a child diagram. A process should indicate the system name or use the verb-adjective-noun format. Each data flow should be described with a noun. Each child diagram should have the same input and output data flow as the parent process.

Different Types of Data Flow Diagrams Logical DFD: Logical data flow diagrams focus on the business and how the business operates and what the business must do. Physical DFD: Physical data flow diagrams show how the system constructed or how the new system will be implemented. Physical data flow diagrams advantages: * Clarifying which processes are manual and which are automated. * Describing processes in greater detail. * Sequencing processes in the order they must be executed. * Temporary data stores and transaction files. * Specifying actual document and file names. * Controls to ensure accuracy and completeness.

Data Flow Diagram Progression The progression of creating data flow diagrams is: Create a logical DFD of the current system. Next add all the data and processes not in the current system that must be present in the new system. Finally derive the physical data flow diagram for the new system.

Logical Data Flow Diagrams Advantages Advantages of logical DFDs are: Better communication with users. More stable (不易改变的) systems, since the design is based on a business framework. Increased understanding of the business by analysts. The system will have increased flexibility and be easier to maintain. Elimination of redundancy and easier creation of the physical model.

Developing Physical Data Flow Diagrams After you develop the logical model of the new system, you may use it to create a physical data flow diagram. The physical data flow diagram shows how the system will be constructed.

Partitioning Partitioning is the process of analyzing a data flow diagram and deriving a series of manual procedures and computer programs. Group automated procedures into a series of computer programs which perform the work of some human activities. A manual procedure is performed by the people. A dashed line is drawn around a group of processes that are included in each computer program or manual procedure. Automated processes are either batch (一批) or on-line programs.

Reasons for Partitioning The reasons for partitioning a data flow diagram into separate computer programs are: Different user groups should have different programs. If two processes execute at different times, they can not be grouped into one programs. Processes may be separated into different programs for security. Similar tasks may be included in the same program. Several batch (一批) processes may be included in the same program for efficiency. Several processes may be included in the same program or job stream for consistency of data.

Partitioning Web Sites Partitioning is a very useful principle when designing a Web site. Web sites are partitioned into pages. Improves speed of processing Easier Web page maintenance Different pages when reading different data Partitioned for security, separating pages using a secure connection from those that do not