1. Data and Process Modeling
PHASE 2: SYSTEMS ANALYSIS
Chapter 4
Data and Process Modeling

2. Chapter Objectives
Describe data and process modeling concepts and tools, including data flow diagrams, a data dictionary, and process descriptions
Describe the symbols used in data flow diagrams and explain the rules for their use
Draw data flow diagrams in a sequence, from general to specific
Explain how to level and balance a set of data flow diagrams 3

3. Chapter Objectives
Describe how a data dictionary is used and what it contains
Use process description tools, including structured English, decision tables, and decision trees
Describe the relationship between logical and physical models 3

4. Introduction
In Chapter 4, we will use data and process modeling techniques …
To develop a logical model of the proposed system
Logical model  WHAT system must do
Physical model  HOW system will be constructed (later in systems design phase)
To document system requirements
A logical model could specify output as a list of data, without committing to a specific format.
A physical model would include details about the format. 4

5. Overview Data and Process Modeling Tools
Systems analysts use many graphical techniques to describe an information system
A data flow diagram (DFD) uses various symbols to show how the system transforms input data into useful information
Data Flow Diagram
A DFD shows inputs, processes, storage, and outputs of a system

6. Data Flow Diagrams
A data flow diagram (DFD) shows how data moves through an information system but does not show program logic or processing steps
A set of DFDs provides a logical model that shows what the system does, not how it does it

7. Data Flow Diagrams DFD Symbols
DFDs use four basic symbols that represent processes, data flows, data stores, and entities
Gane and Sarson symbol set
Yourdon symbol set
With minimal training DFDs can be read and interpreted by many different workers - both end users, and management, making them a valuable tool for communication.

8. Data Flow Diagrams DFD Symbols
PROCESS symbol
Receives input data and produces output that has a different content, form, or both
Contains the business logic  business rules
Referred to as a black box
Process:
A process can be a procedure or an algorithm. Processes can be simple or complex. Keep in mind that processing details are not shown in a DFD.
Black Box:
Because inputs, outputs, and general functions of process are known but underlying details and logic of process are hidden. Don’t know the internal operations.

9. Data Flow Diagrams DFD Symbols
DATA FLOW symbol
Represents one or more data items
The symbol is a line with a single or double arrowhead
Fork  same data
Data Flow:
Data flows represent data movement among processes, data stores, and external entities.
Fork  same data go from a common location to two or more processes, data stores or entities

10. Data Flow Diagrams DFD Symbols
Basic rules for all PROCESSES and DATA FLOWS
At least 1 data flow must enter and 1 data flow must exit each process
AVOID:
Spontaneous generation
Has no input
Black hole
Produces no output
Gray hole
Input insufficient to generate output
No process can have only outputs
Something must go in or a miracle has occurred
No process can have only inputs
This should not happen lest we call this the “black hole”

11. Data Flow Diagrams DFD Symbols
DATA STORE symbol
Represent data that the system stores
Physical characteristics of data store are unimportant
Concerned only with logical model
Data Store:
Stores  file, database server, web server, file server
A DFD does not show detailed contents of a data store.

12. Data Flow Diagrams DFD Symbols
Basic rules for all DATA STORES
Data cannot be moved from one store to another
Data cannot move from an outside source to a data store
Data cannot move directly from a data store to a data sink
1) Data cannot be moved from one store to another
Example: In 4-23, pg. 166, Data cannot go from the Master Schedule database to the Orders database without some type of process in between.
2) Data cannot move from an outside source to a data store
Example: Same example. A Customer‘s order information does not enter directly to the Orders database without some processing (Order System) in between.
3) Data cannot move directly from a data store to a data sink
Example: Same example. Reordered parts do not go directly from the Parts database to the Suppler entity without some processing (Purchasing System) in between.

13. Data Flow Diagrams DFD Symbols
ENTITY Symbol
Symbol is a rectangle
Depicts origin and/or destination of data
Sometimes referred to as external entity
Name of the entity appears inside the symbol
AKA:
Terminators  final destination
Source  supplies data
Sink  receives data
Entity:
A person, place, thing, or event for which data is collected and maintained. An external entity is outside the system boundary but supplies input or accepts output.
A DFD shows the boundaries of a system and how it interfaces with the outside world.
Terminators – data origins or final destinations.
Source – Entity that supplies data to the system
Sink – Entity that receives data from the system

14. Data Flow Diagrams DFD Symbols
Basic rules for all ENTITIES (i.e. sources/sinks)
Entity must be connected to a process by a data flow and not directly to a data store
Data cannot move directly from a source to a sink
Entity must be connected to a process by a data flow and not directly to a data store
 The data must be processed in between before going to the database.
Data cannot move directly from a source to a sink  Otherwise what was the purpose of the system in the first place.

15. Data Flow Diagrams
Basic rules for connecting processes, data stores, and entities in a DFD

16. Creating a Set of DFDs
Create a graphical model of the information system based on your fact-finding results
Performing three main tasks
Step 1: Draw a context diagram
Step 2: Draw a diagram 0 DFD
Step 3: Draw the lower-level diagrams
Step 1: Draw a context diagram
Highest level – scope of system
Step 2: Draw a diagram 0 DFD
More detail – breaks down system into detail
Step 3: Draw the lower-level diagrams
 Greater detail – break each module into its lowest level of detail until no more detail is necessary

17. Creating a Set of DFDs Draw a Context Diagram Process 0 represents
system
Context diagram
The most abstract, least detailed, model. It shows the system’s boundaries and scope
Symbolizes all processing activity within a system with a single process symbol.
Data stores are not shown.
Mention how to determine which entities and data flows are shown in a context diagram.

18. Creating a Set of DFDs Draw a Context Diagram
Context Drawing Guidelines (Page 156, Figure 4-13)
Fit on one page
Name of information system  Process name
Use unique names within each set of symbols
Do not cross lines
Obtain user input and feedback

19. Creating a Set of DFDs Context Diagram
Refer to Figure 4-13 on page 156 of textbook
What is the name of the system in this Context Diagram?
How many sources of data are there? What are they?
Which entities (sinks) do not supply inputs to the Order System?
What data is going into the Order System from Customer?
What data is going to the Warehouse from the Order System?
Name Order system
2 sources of data  Customer and Warehouse
Sinks only  Sales Rep, Bank, Accounting
From Customer  Payment, Order
To Warehouse  Picking List

20. Creating a Set of DFDs Draw a Level-0 DFD Diagram
Draw a Level-0 Diagram
This is the expanded view (or child diagram) of the Order System.
The Order Context Diagram has been decomposed to show…
3 processes: Fill Order, Create Invoice, Apply Payment
1 data store: Accounts Receivable
2 new data flows: Invoice Detail and Payment Detail
1 diverging data flow: Invoice

21. Creating a Set of DFDs Draw a Level-0 DFD Diagram
Level-0 DFD Drawing Guidelines (p. 161, Figure 4-16)
Decomposition of Context diagram
Parent/Child diagram
KEEP all data flows into and out of process 0
KEEP all entities
Functional primitive
Diverging data flow – different locations
Decomposition:
Decompose a diagram to show what lies beneath. Here we show the major processes, data flows, and data stores within the main system
Each process has a reference number. Reference numbers are important because we can then break each Level-0 process down further into a Level 1 diagram
Parent/Child:
We exploded, or decomposed, the Context diagram (Process 0). The higher level is called the Parent diagram. The lower level is called the Child diagram. Which one is the Parent here? Context. Which is the child? Level-0.
Keep all data flows: (Balancing)
All data flows going into/coming out of Context diagram must be on Level-0 diagram.
Keep all entities: (Balancing)
All entities that appeared on the Context must appear on the Level-0 diagram.
Functional Primitive:
A process that has been broken down into its smallest unit, a single function that cannot be broken down further. At this point it can be handed off to the programmer to use to develop code.
Diverging data flow
Same data travels to two or more different locations. In this situation, a diverging data flow is the best way to show the flow rather than showing two identical data flows – misleading.

22. Creating a Set of DFDs Draw Lower Level 1-n DFD Diagrams
Level 1-N Diagrams

23. Creating a Set of DFDs Draw Lower Level 1-n DFD Diagrams
Level 1-n DFD Drawing Guidelines
Leveling
Balancing
Leveling:
Keep decomposing the DFDs until all functional primitives are identified. i.e. Until you get to the lowest level necessary to describe the function.
Balancing:
Maintains consistency among DFDs by ensuring that the input and output data flows of the parent DFD are drawn on the child DFD.

24. Creating a Set of DFDs Draw a Level-0 DFD Diagram
Draw a Level-0 Diagram
Ci1 Wo Co C2 Wi
This is the expanded view (or child diagram) of the Order System.
The Order Context Diagram has been decomposed to show…
3 processes: Fill Order, Create Invoice, Apply Payment
1 data store: Accounts Receivable
2 new data flows: Invoice Detail and Payment Detail
1 diverging data flow: Invoice
Ci2 Ao So Bo

25. Creating a Set of DFDs Draw Lower Level 1-n DFD Diagrams
Level 1-N Diagrams Co
Ci1 Wo

26. Data Dictionary Central Storehouse (aka Data Repository)
Facts about system
Data elements (aka Field)
Record (aka Data Structures)
Facts about system:
Contents of data flows, data stores, entities, and processes
Data Elements:
Defines and describes fields. Like student name, social security number.
Record:
Data elements are combined into records, also called data structures. A record is a combination of related data elements that is included in a data flow or retained in a data store.
For example: A Student demographic record might include student id, name, address, city, state, zip.

27. Data Dictionary Documenting the Data Elements
Objective: Provide clear, comprehensive information about the data and processes that make up the system

28. Data Dictionary Documenting the Data Elements
The following attributes are recorded and described:
Data element name or label
Alias
Type and length
Default value
Acceptable values - Domain and validity rules
Name of data element, meaningful to users
Alias – Alternate name users may refer to it. Instead of Current Balance  Amount Owed
Type/Length – numeric, alpha, character and max # of characters if alpha, max # of digits & # of decimals if numeric.
Default value – If value is not entered, amount to be entered.
i.e. date
Acceptable values –
Domain: set of values permitted for data element  list or use a lookup table, i.e. Tax Code based on Adjusted Gross Income lookup table
Validity Rules: Does entered value make sense? Salary is within range for job classification.

29. Data Dictionary Documenting the Data Elements
The following attributes are recorded and described:
Source
Security
Responsible user(s)
Description and comments
Source:
The origination point for the data element’s values. Did it come from a form, a department, outside organization, another system, or the result of a calculation. i.e. Perhaps you obtain an employee’s review code for a non-HR system from an HR system. The source would be another system – specifically the HR system.
Security:
Who has access or update privileges – at the data element level. Some workers may have read-only while the manager may be able to update.
Responsible users:
Those responsible for maintaining the data element.
Description and comments:
Notes

30. Data Dictionary Documenting the Data Flows
Typical attributes of data flows:
Data flow name or label
Description
Alternate name(s)
Origin
Destination
Record
Volume and frequency
Origin:
The DFD beginning, or source, for the data flow; can be a process, a data store, or an entity. Where is it coming from?
Destination:
The DFD ending point(s) for the data flow; can be a process, data store, or entity. Where is it going to?
Record:
Each data flow represents a group of related data elements (or a record). In data dictionaries, records are defined separately from the data flow and stores. When records are defined, more than one data flow or data store can use the same record, if necessary.
Volume and Frequency:
Expected # of occurrences for the data flow per unit of time. Example: If company has 300 hourly employees  Time Card dataflow would have 300 transactions and records each week when they punch their time card.

31. Data Dictionary Documenting the Data Stores
Typical attributes of a data store:
Data store name or label
Description
Alternate name(s)
Attributes
Volume and frequency
Attributes:
DFD data flow names that enter or leave the data store. These names are standardized throughout the data dictionary for consistency purposes.
Volume and frequency:
Estimated number of records in the data store and how frequently they are updated. This is important because they will affect design decisions in subsequent SDLC phases.

32. Data Dictionary Documenting the Processes
Typical attributes of a process:
Process name or label
Description
Process number
Process description
Description vs. Process Description:
Description is a brief statement of the process’s purpose.
Process description includes the input and output data flows. For functional primitives, this description should also document the processing steps and business logic.

33. Data Dictionary Documenting the Entities
Typical attributes of an entity:
Entity name
Description
Alternate name(s)
Input data flows
Output data flows
Input data flows:
Flows going to the entity.
Output data flows:
Flows leaving the entity.

34. Data Dictionary Documenting the Records
Typical attributes of a record:
Record or data structure name
Definition or description
Alternate name(s)
Attributes
Record name:
As it appears in the related data flow and data store entries in the data dictionary.
Attributes:
A list of all the data elements included in the record. The data element names must match exactly what was entered in the data dictionary.

35. Data Dictionary Data Dictionary Reports
Many valuable reports may be obtained
Data Element report
Data Flows/Stores report
Detailed reports
Data Element Report:
A report describing each data element and indicating the user or department that is responsible for data entry, updating, or deletion
An alphabetized list of all data elements by name
Data Flow/Store Report:
A report of all data flows and data stores that use a particular data element
Detailed Reports:
Detailed reports showing all characteristics of data elements, records, data flows, processes, or any other selected item stored in the data dictionary

36. Process Description Tools
A process description documents the details of a functional primitive
AND represents a specific set of processing steps and business logic
When you analyze a functional primitive, you break the processing steps down into smaller units in a process called modular design.

37. Process Description Tools Modular Design
Based on the combination of 3 logical structures
Sequence
Selection
Iteration - looping
3 logical structures:
These are building blocks for the process/program.
Sequence:
Complete steps one after another. In a program, once a record is read in and verified, a number of sequential steps are done. Page 173, Figure 4-33.
Selection:
Here you have to make a decision. This would be like an IF statement. If this then this path, else the other path.
Iteration:
This is like a Do…While or Do…Until statement. Also Looping. You have an iteration of a process until some condition has been satisfied.

38. Process Description Tools
Typical process tools include:
Structured English
Decision Tables
Decision Trees

39. Process Description Tools Structured English
Purpose: Describe underlying business logic
Structured English Rules
Use 3 building blocks
Sequence, Selection, Iteration
Use indentation for readability
Use limited vocabulary
Standard terms used in data dictionary
Specific words that describe the processing rules

40. Process Description Tools
Structured English (Pg. 174, Figure 4-37)
Might look familiar because it resembles pseudocode

41. Process Description Tools Decision Tables
Logical structure  All combinations of conditions
Resulting actions
VERIFY ORDER Process
Conditions
Combo of Y/N for condition – 4 diff. rules or combos
X to accept or reject order given the rule 1 2 3

42. Process Description Tools Decision Tables
Can have > 3 possible outcomes
Best way to describe complex set of conditions
Sales Promotion Policy

43. Process Description Tools Decision Trees
Graph of conditions, actions, rules in decision table
Personal preference  Decision table or tree

44. Logical Versus Physical Models Four-Model Approach
What analysts can do …
1st Create a physical model of current system
2nd Develop a logical model of current system
3rd Develop a logical model of new system
4th Develop a physical model of new system
Disadvantage: Added time and cost

45. Chapter Summary
During data and process modeling, a systems analyst develops graphical models to show how the system transforms data into useful information
The end product of data and process modeling is a logical model that will support business operations and meet user needs
Data and process modeling involves three main tools: data flow diagrams, a data dictionary, and process descriptions
Data flow diagrams (DFDs) graphically show the movement and transformation of data in the information system
DFDs use four symbols 49

46. Chapter Summary Any questions?
A set of DFDs is like a pyramid with the context diagram at the top
The data dictionary is the central documentation tool for structured analysis
Each functional primitive process is documented using structured English, decision tables, and decision trees
Structured analysis tools can be used to develop a logical model during one systems analysis phase, and a physical model during the systems design phase
Any questions? 49