Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING.

Slides:



Advertisements
Similar presentations
CAPE INFORMATION TECHNOLOGY – Unit 2
Advertisements

Johnb DFDs and Design John Bell The DeMarco notation.
Software Engineering-II Sir Zubair Sajid. 3 Data Flow Diagrams (DFD)  DFDs describe the flow of data or information into and out of a system what does.
Systems Analysis Requirements structuring Process Modeling
SYSTEMS ANALYSIS AND DESIGN TOOLS
IFS310: Week 3 BIS310: Structured Analysis and Design 5/4/2015 Process Modeling and 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.
How to : Data Flow Diagrams (DFDs)
Dataflow modelling: Context and Data Flow Diagrams
Jump to first page Chapter 2 System Analysis - Process Modeling.
DT211 Stage 2 Software Engineering
Modern Systems Analysis and Design
Structuring System Requirements: Process Modeling
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.
Process Modeling and Data Flow Diagrams
The Traditional Approach to Requirements: Using Dataflow Diagrams Spring
System Analysis and Design
DATA FLOW DIAGRAMS IT 155.
Data Flow Diagrams BCA Sem IV K.I.R.A.S.
Chapter 7 Structuring System Process Requirements
Software Design Description (SDD) Diagram Samples
Traditional Approach to Requirements Data Flow Diagram (DFD)
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.
Data Flow Diagrams (DFDs)
Chapter 1: Data Flow Diagram Structuring System Process Requirements
Data Flow Diagrams (DFDs). Data flow diagram (DFD) is a picture of the movement of data between external entities and the processes and data stores within.
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 6.1.
SDLC Phase II: Structuring System Requirements IS 582 Dr. Dania Bilal Spring 2008.
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.
DATA FLOW DIAGRAMS Learning Units
Lecture 6 Data Flow Modeling
Data-Flow Diagrams Week 10 Lecture 1. Data Flow Diagrams (DFDs) One of most important modelling tools used by system analysts In use since late 1970’s.
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.
Chapter 7 Structuring System Process Requirements
PHASE 2: SYSTEMS ANALYSIS
AN INTRODUCTION BUSINESS PROCESS DOCUMENTATION WITH DATA FLOW DIAGRAMS.
Analysis Modeling. Function Modeling & Information Flow  Information is transformed as it flows through a computer-based system. The system accepts input.
Context Diagrams. What are dataflow diagrams used for? Dataflow diagram  A graphical representation that depicts information flow and the transforms.
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.
Data Flow Diagrams (DFDs) 1Information Systems Engineering.
Using Dataflow Diagrams – Part 1 Systems Analysis and Design, 7e Kendall & Kendall 7 © 2008 Pearson Prentice Hall.
Copyright 2001 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter 5 Structuring.
Data Flow Diagrams (DFDs)
Chapter 7 Structuring System Process Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich.
1Lecture 8 Introduction to Systems Analysis l Objectives –Explain how systems analysis relates to business needs, problems, and opportunities –List and.
CS223: Software Engineering
Data Flow Diagram, Data Dictionary, and Process Specification PART I
Software Analysis 1 PROCESS MODELING: Data Flow Diagrams (DFDs)
© 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.
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.
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.
DFD(Data Flow Diagram)
Data Flow Diagrams.
Process Modeling Graphically represent the processes that capture, manipulate, store, and distribute data between a system and its environment Models DFDs.
Business System Development
Function-Oriented Software Design (continued):
Chapter 1: Data Flow Diagram Structuring System Process Requirements
Process & Logic Modeling
Software design and architecture
Requirement Analysis using
Chapter 7: Data Flow Diagram Structuring System Process Requirements
Presentation transcript:

Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING

Data Flow Diagrams (DFD) DFDs describe the flow of data or information into and out of a system what does the system do to the data? A DFD is a graphic representation of the flow of data or information through a system INTRODUCTION TO SOFTWARE ENGINEERING

Elements of data-flow diagrams Information Flow/Data Flow Process/Data Transform External Entity/Information Sources Data Store/Information Store Output INTRODUCTION TO SOFTWARE ENGINEERING

Information Flow/Data Flow Information flows represent the information being passed into or out of a system. It is represented as a labeled arrow: Taxable Income INTRODUCTION TO SOFTWARE ENGINEERING

Data transforms/Process Data transforms labeled circles with one or more incoming and outgoing information flows: INTRODUCTION TO SOFTWARE ENGINEERING

Information sources/External Entity Information sources and sinks are information that come into the system, or leave the system, and are represented by squares: Any human or external software system which interact with the system is an external entity INTRODUCTION TO SOFTWARE ENGINEERING

Information store/Data store Information Stores represent locations where information can be store for the duration of the system activity: INTRODUCTION TO SOFTWARE ENGINEERING

Output This element shows the output of a system. This is represented as: INTRODUCTION TO SOFTWARE ENGINEERING

Importance of DFDs in a good software design DFD is a very simple formalism – it is simple to understand and use. Starting with a set of high-level functions that a system performs, a DFD model hierarchically represents various sub-functions. In fact, any hierarchical model is simple to understand. DFD is an elegant modeling technique that turns out to be useful not only to represent the results of structured analysis of a software problem But also for several other applications such as showing the flow of documents or items in an organization. INTRODUCTION TO SOFTWARE ENGINEERING

General Rules:- No internal Logic To keep it uncluttered(input same then join) No miracles/Blackholes(only i/p, no o/p) Database cannot sink/source(no data storing, only reading) No data stores should be there at level 0 No direct dataflow between two entities and two data stores. Direct dataflows between two processes-yes INTRODUCTION TO SOFTWARE ENGINEERING

Levelled DFDs Even a small system could have many processes and DFD could be large and messy use levelled DFDs - view system at different levels of detail INTRODUCTION TO SOFTWARE ENGINEERING

Level 0 - Context Diagram It is the most abstract data flow representation of a system. It represents the entire system as a single bubble. This bubble is labelled according to the main function of the system. The various external entities with which the system interacts and the data flow occurring between the system and the external entities are also represented. Only one process and all external entities identified at context level. No new entity can come in level 1 and level 2. The name ‘context diagram’ is well justified because it represents the context in which the system is to exist, i.e. the external entities who would interact with the system and the specific data items they would be supplying the system and the data items they would be receiving from the system. The context diagram is also called as the level 0 DFD. INTRODUCTION TO SOFTWARE ENGINEERING

Level 1 - Overview Diagram Gives overview of full system Identifies major processes and data flows between them Identifies data stores that are used by the major processes Process will be decomposed but external entity will remain same. INTRODUCTION TO SOFTWARE ENGINEERING

Level 2 - Detailed Diagram Level 1 process is expanded into more detail Each process in level 1 is decomposed to show its constituent processes INTRODUCTION TO SOFTWARE ENGINEERING

Numbering of Bubbles(Processes) It is necessary to number the different bubbles occurring in the DFD. These numbers help in uniquely identifying any bubble in the DFD by its bubble number. The bubble at the context level is usually assigned the number 0 to indicate that it is the 0 level DFD. Bubbles at level 1 are numbered 0.1, 0.2, 0.3, etc, etc. When a bubble numbered x is decomposed, its children bubble are numbered x.1, x.2, x.3, etc. In this numbering scheme, by looking at the number of a bubble we can determine its level, its ancestors, and its successors. INTRODUCTION TO SOFTWARE ENGINEERING

Commonly made errors while constructing a DFD model Many beginners commit the mistake of drawing more than one bubble in the context diagram. A context diagram should depict the system as a single bubble. Many beginners have external entities appearing at all levels of DFDs. All external entities interacting with the system should be represented only in the context diagram. The external entities should not appear at other levels of the DFD. It is a common oversight to have either too less or too many bubbles in a DFD. Only 3 to 7 bubbles per diagram should be allowed, i.e. each bubble should be decomposed to between 3 and 7 bubbles. INTRODUCTION TO SOFTWARE ENGINEERING

A common mistake committed by many beginners while developing a DFD model is attempting to represent control information in a DFD. It is important to realize that a DFD is the data flow representation of a system, and it does not represent control information. For an example mistake of this kind: Consider the following example. A book can be searched in the library catalog by inputting its name. If the book is available in the library, then the details of the book are displayed. If the book is not listed in the catalog, then an error message is generated. While generating the DFD model for this simple problem, many beginners commit the mistake of drawing an arrow to indicate the error function is invoked after the search book. But, this is a control information and should not be shown on the DFD. INTRODUCTION TO SOFTWARE ENGINEERING

Showing control information on a DFD - incorrect Another error is trying to represent when or in what order different functions (processes) are invoked and not representing the conditions under which different functions are invoked. If a bubble A invokes either the bubble B or the bubble C depending upon some conditions, we need only to represent the data that flows between bubbles A and B or bubbles A and C and not the conditions depending on which the two modules are invoked. INTRODUCTION TO SOFTWARE ENGINEERING

Many beginners leave different levels of DFD unbalanced. A data store should be connected only to bubbles through data arrows. A data store cannot be connected to another data store or to an external entity. All the functionalities of the system must be captured by the DFD model. No function of the system specified in its SRS document should be overlooked. Only those functions of the system specified in the SRS document should be represented, i.e. the designer should not assume functionality of the system not specified by the SRS document and then try to represent them in the DFD. The data and function names must be intuitive. Some students and even practicing engineers use symbolic data names such a, b, c, etc. Such names hinder understanding the DFD model. Many beginners leave different levels of DFD unbalanced. Balancing: No. of Inputs and outputs in a process in context diagram should be equal to the number of inputs and outputs in processes in overview diagram and so on. INTRODUCTION TO SOFTWARE ENGINEERING

Rules of Data Flow Data can flow from Data cannot flow from External entity to process Process to external entity Process to store and back Process to process Data cannot flow from External entity to external entity External entity to store Store to external entity Store to store

Level 0 - Context Diagram Customer Sales Clerk Cust. Deatils Sales details CN SuperMarket System All Cust. details External Entities identified: Customer, Sales Clerk and Manager Manager Winner lists Winner Lists INTRODUCTION TO SOFTWARE ENGINEERING

Level 1 – Overview Diagram Reset Cust. details Register Customer 0.1 Register Sales 0.2 Customer details Sales Details Main processes and data stores identified Generation of winner lists 0.3 Winner lists INTRODUCTION TO SOFTWARE ENGINEERING

Level 2 – Detailed Diagram Generation of Gold Coin winner list 0.3.2 Verification 0.3.1 Final Data Winner list1 Generation of Surprise gift winner list 0.3.3 Winner list2 INTRODUCTION TO SOFTWARE ENGINEERING