Scribd
Upload
9 views19 pages

Chapter 5 Data and Process Modeling

Chapter 5 covers data and process modeling within system development, focusing on the relationship between logical and physical models, the role of Data Flow Diagrams (DFDs), and the creation of data dictionaries. It outlines the construction and guidelines for DFDs, including symbols, errors to avoid, and the importance of balancing and leveling diagrams. Additionally, it introduces tools for process description such as structured English, decision tables, and decision trees.

Uploaded by

Aifani Mmbubana
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
9 views19 pages

Chapter 5 Data and Process Modeling

Chapter 5 covers data and process modeling within system development, focusing on the relationship between logical and physical models, the role of Data Flow Diagrams (DFDs), and the creation of data dictionaries. It outlines the construction and guidelines for DFDs, including symbols, errors to avoid, and the importance of balancing and leveling diagrams. Additionally, it introduces tools for process description such as structured English, decision tables, and decision trees.

Uploaded by

Aifani Mmbubana
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 19

CHAPTER 5: DATA AND PROCESS

MODELING
LEARNING OUTCOMES

After completing this chapter, you will be able to:


• Remember the relationship between logical and physical
models in system development
• Understand the role and purpose of Data Flow Diagrams
(DFDs) in the SDLC
• Apply knowledge to draw and label the four basic DFD symbols
• Analyze differences between context diagrams and Diagram 0
• Evaluate the importance of balancing and leveling DFDs
• Create a data dictionary to document system elements
2
LOGICAL VS. PHYSICAL MODELS

Four-Model Approach:
1.Physical model of current system - How tasks are currently
executed
2.Logical model of current system - What the system currently
does
3.Logical model of new system - What the new system should do
4.Physical model of new system - How the new system will be
implemented
Benefits:
• Detailed understanding of current operations
• Prevents costly early-stage errors
• Easier adaptation when requirements are similar
3
• Clear transition from concept to implementation
DATA FLOW DIAGRAMS (DFDS)

Purpose: Visually depict how input data is processed and


transformed into valuable information.
Key Characteristics:
• Focus on data movement, not processing logic
• Show WHAT happens to data, not HOW it's processed
• Provide high-level system behavior understanding
• Avoid premature design limitation
DFDs are complemented by:
• Object models
• Entity-relationship diagrams
•4 Business process diagrams
FOUR BASIC DFD SYMBOLS
1. Process Symbol
• Representation: Rectangle with rounded corners
• Purpose: Function that transforms input data into output
• Naming: Verb + singular noun (e.g., "CALCULATE
COMMISSION")
• Characteristics: Black box hiding internal logic
2. Data Flow Symbol
• Representation: Line with arrowhead
• Purpose: Shows movement of data between components
• Naming: Singular noun (e.g., "INVOICE PAYMENT")
• Requirements: Must connect to at least one process

5
FOUR BASIC DFD SYMBOLS

3. Data Store Symbol


• Representation: Open-ended rectangle (Gane & Sarson)
• Purpose: Repository where data is stored for future use
• Naming: Usually plural (e.g., "STUDENTS", "ACCOUNTS")
• Connection: Must link to process via data flow
4. External Entity Symbol
• Representation: Rectangle (may be shaded)
• Purpose: Sources or destinations of data outside the system
• Types: Source (supplies data) or Sink (receives data)
•6 Naming: Singular form (e.g., "CUSTOMER", "EMPLOYEE")
DFD CONSTRUCTION GUIDELINES
Layout Rules:
• Context diagram should fit on single page
• Use system name as main process in context diagram
• No more than 9 process symbols per diagram
• Avoid crossing lines (use duplicate symbols if needed)
Naming Conventions:
• Unique names within each symbol set
• Consistent naming across all DFD levels
• Process names: verb + descriptive noun
• Data flows: descriptive singular nouns
Process Numbering:
• Context diagram contains Process 0
•7 Diagram 0 breaks down Process 0
DFD ERRORS TO AVOID
Spontaneous Generation
• Process produces output without input
• Example: APPLY INSURANCE PREMIUM with no input data
• Problem: Violates logical data transformation principle
Black Hole
• Process receives input but produces no output
• Example: CALCULATE GROSS PAY with input but no output
• Problem: Process serves no useful purpose
Gray Hole
• Input insufficient to produce expected output
• Example: Date of birth input cannot produce final grade
8
• Problem: Logical relationship between input and output is
CONTEXT DIAGRAM

Purpose: Provides top-level view of information system


boundaries and scope.
Construction Steps:
1. Place single process symbol (Process 0) at center
2. Arrange external entities around perimeter
3. Connect entities to Process 0 with data flows
4. Exclude data stores (internal to system)
Example - Grading System:
• Entities: Student Records System, Student, Instructor
• Data Flows: CLASS ROSTER, SUBMITTED WORK, GRADED
9 WORK, GRADING PARAMETERS, GRADE REPORT, FINAL GRADE
DIAGRAM 0 DFD
Purpose: Breaks down Process 0 to show major internal
processes, data flows, and data stores.
Key Features:
• Retains all external entities from context diagram
• Maintains all incoming/outgoing data flows
• Introduces internal processes and data stores
• Shows data flow between internal processes
Example - Grading System Processes:
1. Establish Gradebook
2. Grade Student Work
3. Assign Final Grade
4. Produce Grade Report
Diverging Data Flows:
•10 Same data sent to multiple destinations
LOWER-LEVEL DFDS
Leveling (Decomposition):
• Purpose: Progressive refinement through detailed diagrams
• Process: Continue until functional primitives are reached
• Alternative names: Exploding, partitioning, decomposing
Balancing:
• Purpose: Ensure consistency between parent and child diagrams
• Rule: Input/output data flows must match between levels
• Example: If parent has 1 input and 3 outputs, child must have same
Functional Primitives:
• Single processing functions that cannot be further decomposed
• Will be implemented as program code
• Documented with detailed process descriptions
11
DATA DICTIONARY

Definition: Centralized repository organizing and maintaining


facts about an information system.
Components Documented:
• Data Elements: Smallest units of meaningful information
• Data Flows: Movement of data between components
• Data Stores: Locations where data is held
• Entities: External actors interacting with system
• Processes: Actions that transform data
• Records: Collections of related data elements

12
DATA ELEMENT DOCUMENTATION
Key Attributes:
• Name/Label: Standard, meaningful identifier
• Aliases: Alternative names used by different departments
• Data Type/Length: Numeric, alphabetic, alphanumeric
specifications
• Default Value: Predefined value when none specified
• Acceptable Values: Domain of permissible values
• Source: Origin of data element
• Security: Access and modification restrictions
• Responsible Users: Who maintains the data
• Description: Additional explanatory notes
13
DATA ELEMENT DOCUMENTATION

Example:
• Name: CURRENT_BALANCE
• Aliases: OUTSTANDING_BALANCE, CUSTOMER_BALANCE
• Type: Numeric, 2 decimal places
• Default: $0.00
• Domain: $0.00 to $50,000.00

14
PROCESS DESCRIPTION TOOLS
Modular Design Principles:
Three basic logical structures (control structures):
1. Sequence
• Steps executed in linear, ordered fashion
• Each step depends on completion of previous one
2. Selection
• Choose between alternatives based on condition
• If-then-else decision making
• Example: Calculate overtime if hours > 40
3. Iteration
• Repeat steps until condition changes
• Looping mechanism
• Example: Print paychecks for all employees
15
STRUCTURED ENGLISH

Purpose: Simplified form of standard English for describing


logical processes.
Guidelines:
• Use only three logical building blocks (sequence, selection,
iteration)
• Proper indentation for readability
• Limited vocabulary from data dictionary
• Clear logical rules for processing steps

16
DECISION TABLES
Purpose: Document every possible combination of conditions
and outcomes.
Structure:
• Conditions: Yes/No questions about the process
• Rules: All possible combinations of condition outcomes
• Actions: What happens for each rule combination
Types:
• Single Condition: 2 rules (2¹)
• Two Conditions: 4 rules (2²)
• Three Conditions: 8 rules (2³)
Simplification:
• Mark irrelevant conditions with dashes (-)
• Combine rules with identical outcomes
17
• Eliminate redundant or impossible combinations
DECISION TREES
Purpose: Graphical representation of conditions, actions, and
rules.
Characteristics:
• Read from left to right
• Root at left, branches extend right
• Conditions on branches, actions at endpoints
• Alternative to decision tables
Use Cases:
• Decision Tables: Better for complex condition combinations
• Decision Trees: Better for simple processes and visual clarity
• Management Presentations: Trees provide clearer visual
18communication
THANK YOU
than

You might also like