Please enable JavaScript.
Coggle requires JavaScript to display documents.
CHAPTER 3.2 DATA AND PROCESS MODELLING - Coggle Diagram
CHAPTER 3.2 DATA AND PROCESS MODELLING
Data & Process Modelling Concepts
-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
-Other relelated tools including data dictionary and process descriptions
Data Flow Diagram
-(DFD) shows how data moves through an information system but does not show program logic or processing steps( flow of data between process).
-DFDs provides a logical model that shows what the system does, not how it does it
DFD Symbols
Process symbol
Receives input data and produces output that has a different content, form, or both
Contain the business logic, also called business rules
Referred to as a black box
Data flow symbol
-Represents one or more data items
-The symbol for a data flow is a line with a single or double arrowhead
AVOID:
Spontaneous generation = process produces output, but has no input data flow
Black hole = process that has input, but produces no output
Gray hole = process that has at least one input and one output, but the data obviously is insufficient to generate the output
Data store symbol
Represent data that the system stores
-The physical characteristics of a data store are unimportant because you are concerned only with a logical model
Entity Symbol
Shows only external entities that provide data to the system or receive output from the system
Name of the entity appears inside the symbol
Creating a set of DFD
Create a graphical model of the information system based on your fact-finding results
Guidelines for drawing DFD
1)Draw the context diagram so that it fits on one page
2)Use the name of the information system as the process name in the context diagram
3)Use unique names within each set of symbols
4)Do not cross lines
5)Provide a unique name and reference number for each process
6)Obtain as much user input and feedback as possible
Step 1 : Draw a context diagram
The first step in constructing a set of DFDs is to draw a context diagram.
A context diagram is a top-level view of an information system that shows the system’s boundaries and scope.
The symbol represents the entire information system, and you identify it as process 0
start by placing a single process symbol in the center of the page.
place the system entities around the perimeter of the page and use data flows to connect the entities to the central process.
begin by reviewing the system requirements to identify all external data sources and destinations.
EXAMPLE: CONTEXT DIAGRAM FOR AN ORDER SYSTEM
Step 2: Draw a Diagram 0 DFD
a context diagram provides the most general view of an information system and contains a single process symbol, which is like a black box.
To show the detail inside the black box, you create DFD diagram 0.
Diagram 0 zooms in on the system and shows major internal processes, data flows, and data stores.
repeats the entities and data flows that appear in the context diagram.
Diagram 0 is an exploded view of process 0, and it shows considerably more detail than the context diagram.
When you explode a DFD, the higher-level diagram is called the parent diagram, and the lower-level diagram is referred to as the child diagram.
EXAMPLE: DIAGRAM 0 DFD FOR AN ORDER SYSTEM
Step 3: Draw the Lower-Level Diagrams
To create lower-level diagrams, you must use leveling and balancing techniques.
Leveling is the process of drawing a series of increasingly detailed diagrams, until all functional primitives are identified.
Balancing maintains consistency among a set of DFDs by ensuring that input and output data flows align properly.
Leveling example
Leveling uses a series of increasingly detailed DFDs to describe an information system.
Leveling also is called exploding, partitioning, or decomposing.
EXAMPLE:
Balancing example
Ensures that the input and output data flows of the parent DFD are maintained on the child DFD
EXAMPLE :
Data Dictionary
An analyst uses the data dictionary to collect, document, and organize specific facts about the system
A data dictionary, or data repository, is a central storehouse of information about the system’s data
defines and describes all data elements and meaningful combinations of data elements
A data element, also called a data item or field, is the smallest piece of data that has meaning
Data elements are combined into records, also called data structures
A record is a meaningful combination of related data elements that is included in a data flow or retained in a data store
Using CASE Tools for Documentation
Modern CASE tools simplify the task
A CASE repository ensures data consistency
The more complex the system, the more difficult it is to maintain full and accurate documentation
Documenting the Data Elements
must document every data element in the data dictionary
to provide clear, comprehensive information about the data and processes that make up the system
(9) The following attributes usually are recorded and described:
Source
Security
Acceptable values - Domain and validity rules
Responsible user(s)
Default value
Type and length
Alias
Description and comments
Data element name and label
Documenting the Data Elements
(7) The typical attributes are as follows
1) Data flow name or label
2) Description
3) Alternate name(s)
4) Origin
5) Destination
6) Record
1 more item...
Documenting the Data Flows
(5) Typical characteristics of a data store are
Alternate name(s)
Attributes
Description
Volume and frequency
Data store name or label
Documenting the Data Stores
(4) Typical characteristics of a process
Description
Process number
Process name or label
Process description
Documenting the Processes
(5) Typical characteristics of an entity include
Description
Alternate name(s)
Entity name
Input data flows
Output data flows
Documenting the Entities
( 4) Typical characteristics of a record include
Definition or description
Alternate name(s)
Record or data structure name
Attributes
Documenting the Records
Documenting the Records
Many valuable reports
An alphabetized list of all data elements by name
A report of all data flows and data stores that use a particular data element
Detailed reports showing all characteristics of data elements, records, data flows, processes, or any other selected item stored in the data dictionary
Process Description
A process description documents the details of a functional primitive, which represents a specific set of processing steps and business logic
(3) Process specification
Modular design
Structured English
Decision Table
Modular design
based on combinations of three logical structures, sometimes called control structures, which serve as building blocks for the process.
Each logical structure must have a single entry and exit point
The three structures are called
sequence
selection
iteration
Symbol
A diamond shape represents a condition or decision
The logic follows the lines in the direction indicated by the arrows.
A rectangle represents a step or process
Sequence
The completion of steps in sequential order, one after another
One or more of the steps might represent a subprocess that contains additional logical structures.
Selection
The completion of one of two or more process steps based on the results of a test or condition.
example, the system tests the input, and if the hours are greater than 40, it performs the CALCULATE OVERTIME PAY process
Iteration
The completion of a process step that is repeated until a specific condition changes
example of iteration is a process that continues to print paychecks until it reaches the end of the payroll file. Iteration also is called looping
Structure English
Must conform to the following rules
Use indentation for readability
The primary purpose of structured English is to describe the underlying business logic
Use only the three building blocks of sequence, selection, and iteration
Decision Tables
Shows a logical structure, with all possible combinations of conditions and resulting actions
It is important to consider every possible outcome to ensure that you have overlooked nothing
(4) Types of tables;
Tables with two condition
When documenting a process, it is important to ensure that you list every possibility.
the process description contains two conditions: product stock status and customer credit status.
If both conditions are met, the order is accepted. Otherwise the order is rejected
Tables with three condition
First, you must fill in the Y-N patterns
The best way to assure that all combinations appear is to use patterns like these.
The first condition uses a pattern of Y-Y-Y-Y followed by N-N-N-N
The second condition uses a repeating Y-YN-N pattern
The pattern in the third condition is a series of Y-N
To simplify the table, follow these steps:
2) If you identify conditions that do not affect the outcome, mark them with dashes (-)
3) Now combine and renumber the rules
Study each combination of conditions and outcomes. When you have rules with three conditions, only one or two of them may control the outcome, and the other conditions simply do not matter.
Tables with one condition
If a process has a single condition, there only are two possibilities – yes or no.
example, to trigger an overtime calculation, the process condition might be: Are the hours greater than 40? If so, the calculation is made. Otherwise, it is not.
Either the condition is present or it is not, so there are only two rules.
Table with multiple outcomes
Table with multiple outcome
In addition to multiple conditions, decision tables can have more than two possible outcomes.
For example, the sales promotion policy includes three conditions:
Did the customer order $1,000 or more
Did the customer use our company charge card
Was the customer a preferred customer
Decision tree
A decision tree is a graphical representation of the conditions, actions, and rules found in a decision table
Like flowcharts, decision trees are useful ways to present the system to management.
Decision trees and decision tables provide the same results, but in different forms.
Sequence of Models
A physical model shows how the system’s requirements are implemented
Sequence of Models
Performing that extra step allows them to understand the current system better
Four-Model Approach
Develop a physical model of the current system, a logical model of the current system, a logical model of the new system, and a physical model of the new system
The only disadvantage of the four-model approach is the added time and cost
