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
