DFDs vs. Use Case Modeling COP 4331 and EEL4884 OO Processes for Software Development © Dr. David A. Workman School of EE and Computer Science University.

Slides:



Advertisements
Similar presentations
CAPE INFORMATION TECHNOLOGY – Unit 2
Advertisements

Chapters 7 & 9 System Scope
Chapter 7 Structuring System Process Requirements
Using Dataflow Diagrams
Data Flow Diagram Purpose – visually depict how data moves and changes through a top-down, logical model Logical model – requirements and the relationship.
ACG 4401 Data Modeling: Data Flow Diagrams Flow Charts.
How to : Data Flow Diagrams (DFDs)
Process Modeling and Data Flow Diagrams
The Traditional Approach to Requirements: Using Dataflow Diagrams Spring
Systems Analysis I Data Flow Diagrams
System Analysis and Design
Data and Process Modeling.  Describe data and process modeling, and name the main data and process modeling techniques.
Requirements Specification with Data Flow Diagrams COP 4331 and EEL4884 OO Processes for Software Systems Development © Dr. David A. Workman School of.
Chapter 7 Structuring System Process Requirements
Structured Vs. Object Oriented Analysis and Design SAD Vs. OOAD
Traditional Approach to Requirements Data Flow Diagram (DFD)
staffs.ac.uk Process Model. staffs.ac.uk Contents Provide definitions Explain the components and representations Introduce a step.
2 Approaches to Requierements Engineering Reference: Systems Analysis and Design in a Changing World, 3 rd Edition, chapter 2 and chapter 6.
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.
Structuring System Process Requirements. Learning Objectives Understand the logical modeling of processes by studying examples of data flow diagrams (DFDs).
SDLC Phase II: Structuring System Requirements IS 582 Dr. Dania Bilal Spring 2008.
10/12/2001Data Structure1 Relationships Between The Data Flow Diagram and The Systems Design Activities Mohammad A. Rob School of Business and Public Administration.
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.
Chapter 7 Structuring System Process Requirements
Documenting the Flow of Information within a System  A Data flow diagram (DFDs) describes the flow of data within an information system, while ignoring.
Data Flow Diagrams (DFD). ScenarioCriteriaTasks Data flow diagram(DFD) is a diagram of the movement of data between external entities.
Chapter 3 Systems Documentation Techniques Copyright © 2012 Pearson Education, Inc. publishing as Prentice Hall 3-1.
Department of Electrical Engineering and Computer Science University of Central Florida Fall 2014.
SAD - DFD Context Diagrams
Software Engineering INTRODUCTION TO SOFTWARE ENGINEERING.
Requirements Specification for Lab3 COP4331 and EEL4884 OO Processes for Software Development © Dr. David A. Workman School of Computer Science University.
Lab3 Use Case Modeling Lessons Learned COP 4232: Software Systems Development © Dr. David A. Workman School of EE and Computer Science University of Central.
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.
Chapter 3 Systems Documentation Techniques Copyright © 2012 Pearson Education, Inc. publishing as Prentice Hall 3-1.
SYSTEMS ANALYSIS AND DESIGN TOOLS DATA FLOW DIAGRAMS.
Chapter 3 Systems Documentation Techniques Copyright © 2012 Pearson Education, Inc. publishing as Prentice Hall 3-1.
Data Flow Diagrams (DFDs) 1Information Systems Engineering.
Midterm Study Guide COP 4331 and EEL4884 OO Processes for Software Development © Dr. David A. Workman School of EE and Computer Science University of Central.
IS3320 Developing and Using Management Information Systems Lecture 16: Data-Flow Diagrams 1 (Intro to Context-Level diagrams) Rob Gleasure
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.
Structuring User Requirements IS 592 Dr. Dania Bilal Spring 2005.
Requirements1. Structured Analysis Method Structured system analysis and design (SSAD) Formal structured dev method Developed by UK Gov. in the 1980’s.
1.The following diagram illustrates the relationship among various hardware components. The arrows indicate the directions of data flow. Activity 1 Relationship.
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.
Requirements Modeling with Data Flow Diagrams CEN5016 Software Engineering © Dr. David A. Workman School of EE and CS University of Central Florida January.
SYSTEMS ANALYSIS AND DESIGN ITDB 2101 HAND OUT # 3 1.
Software Development Lifecycle- SDLC Design- using DFDs.
Final Exam Study Guide COP 4331 and EEL4884 OO Processes for Software Development © Dr. David A. Workman School of EE and Computer Science University of.
Lab 3 Data Flow Diagram CPIT 250 System Analysis and Design.
Data Flow Diagrams 1. What is a Data Flow Diagram?  A data flow diagram (DFD) is a graphical representation of the movement of data between external.
WHAT IS A Context Diagram?
Business System Development
G063 - Data flow diagrams.
Business System Development
Data Flow Diagram (DFD)
SDLC Phase III: Structuring System Requirements
Context and Data Flow Diagrams
Structuring System Requirements: Process Modeling
Welcome to my presentation
تحلیل سیستم‌ها مدل‌سازی پردازشی.
G063 - Data flow diagrams.
Public Management Information Systems System Analysis & Design Tuesday, December 04, 2018 Hun Myoung Park, Ph.D. Public Management & Policy Analysis.
What is a Relationship Map?
Requirement Analysis using
Public Management Information Systems System Design Monday, July 01, 2019 Hun Myoung Park, Ph.D. Public Management & Policy Analysis Program Graduate.
Presentation transcript:

DFDs vs. Use Case Modeling COP 4331 and EEL4884 OO Processes for Software Development © Dr. David A. Workman School of EE and Computer Science University of Central Florida February 18, 2010

(c) Dr. David A. Workman2 Similarities Data Flow Diagram FeatureUse Case Model Feature Process Bubble: Major system processing function at Level 1 (possibly Level 2). Use Case: System function as perceived by one or more system actors. External Sources and Sinks: Entities outside the system that provide system input flows and/or receive system output flows. Actors: External entities that directly interact with system use cases by providing input data and receiving system responses. Context Diagram: Highest level DFD depicting the entire system as a single process bubble connected only to external data sources and sinks. System Box: defines the boundary of the proposed system – separates internal functional capabilities from external entities (actors) that use those capabilities.

February 18, 2010(c) Dr. David A. Workman3 Differences Data Flow Diagram FeatureUse Case Model Feature Stores: Internal data storages devices/areas when persistent data resides until it is needed by a process. No corresponding feature. Data Flow Arrows: Channels connecting two processes, or a process and a store, or a process and an external source/sink. Flow direction is indicated by the arrow head. Data content of the flow appears as a label. Association relation: Between actor and use case such relations indicate a bi-directional flow of data, but no labels or data content are specified. Between two processes, association indicates the sharing of data, but does not specify data content nor flow direction. Include, Gen/Spec, Uses relation: Defined only between use cases. They describe control relationships and/or functional capabilities, but do not carry data, nor are they labeled.