Process modeling

Dr. Jael Wekesa

Lecture 5
Introduction

Process modeling involves graphically representing the

functions, or processes, that capture, manipulate, store,
and distribute data between a system and its
environment and between components within a
system.
1) Data Flow Diagrams,
2) Specifying processes,
3) Process Description Tools,
4) Logical Versus Physical Models
Data Flow Diagrams

 A data flow refers to data in motion, moving from one place in

a system to another.
 A data flow diagram (DFD) is a graphical representation of the
"flow" of data through an information system.
 DFDs can also be used for the visualization of data processing
(structured design).
 DFDs are used as tools for both analysis and communication.
 Because data flow diagrams concentrate on the movement of
data between processes, these diagrams are called process
models.
Data Flow Diagrams symbols

(Name of Whole System, Name of Subsystem Verb-Adjective-Noun)

 DFD Naming Guidelines
External Entity  Noun

Data Flow  Names of data

Process  verb phrase

a system name

a subsystem name

Data Store  Noun

 Process

1.0

Grade Detail Grade Report

Produce
Grade
Report

The work or actions performed on data so that they are

transformed, stored, or distributed.

Process labels should be verb phrases!

Data Flow

2.1
Payment Detail

D1 Accounts
Post Invoice Detail Receivable
Payment

A path for data to move from one part of the system

to another.
Data in motion!
Arrows depict the movement of data.
NO VERBS
Data Store

D1 Students

Used in a DFD to represent data that the system

stores
Data at rest!
Labels should be noun phrases
(NO VERBS)
8
External Entity aka Source/Sink

1.0
Order

CUSTOMER Invoice
Verify
Order

The origin or destination of data!

This represents things outside of the system.
Source – Entity that supplies data to the system.
Sink – Entity that receives data from the system.
The labels should be noun phrases!
Developing Data Flow Diagrams

 A few basic rules to follow:

1) A DFD must have at least one process, and it must not have any
freestanding objects or objects connected to themselves.
2) A process must receive at least one data flow coming into the process
and create at least one data flow leaving from the process.
3) A data store should be connected to at least one process.
4) External entities should not be connected to each other. Although they
communicate independently, that communication is not part of the
system we design using DFDs.
General DFD Rules

A process to another process YES NO

A process to an external entity

A process to a data store

An external entity to another

external entity
An external entity to a data store

A data store to another data store

11
Rules for Developing Data Flow Diagrams

 A few basic rules to follow:

1) A DFD must have at least one process, and it must not have any
freestanding objects or objects connected to themselves.
2) A process must receive at least one data flow coming into the
process and create at least one data flow leaving from the process.
3) A data store should be connected to at least one process.
4) External entities should not be connected to each other. Although
they communicate independently, that communication is not part
of the system we design using DFDs.
Advantages of DFDs

1) Simple graphical techniques which are easy to understand

2) Helps define the boundaries of the system
3) Useful for communicating current system knowledge to users
4) Explains the logic behind the data flow within the system
5) Used as the part of system documentation file
Levels of Details
 Context Diagram
• Main External Environment
 Level 0 Diagram
• Main focus is top-level internals
• Might be the same as the context diagram for small projects
• Sources and Sinks need not be shown, but represent the flow
 Level i Diagram
• Provides a higher level of detail for nodes in level i-1
• Use “Dewey decimal” notation to clarify relationships
Node 2.3 expands to 2.3.1, 2.3.2 and so on
Context DFD

- Context diagram – is an
overview of an
organizational system that
shows the system
boundaries, external
entities that interact with
the system, and the major
information flows between
the entities and the system.

Fig. 1. Context diagram DFD for a grading system.

 Example 2: Context DFD

- What makes one system more

complex than another is the
number of components, the
number of levels, and the degree of
interaction among its processes,
entities, data stores, and data
flows.

Fig. 1. Context diagram DFD for an order system.

DFD Example 3: Bus Garage Repairs
 Buses come to a garage for repairs.
 A mechanic and helper perform the repair, record the reason for the
repair and record the total cost of all parts used on a Shop Repair
Order.
 Information on labor, parts and repair outcome is used for billing by
the Accounting Department, parts monitoring by the inventory
management computer system and a performance review by the
supervisor.
DFD Example: Bus Garage Repairs (cont’d)
 External Entities: Bus, Mechanic, Helper, Supervisor, Inventory
Management System, Accounting Department, etc.
 Key process (“the system”): performing repairs and storing
information related to repairs
 Processes:
o Record Bus ID and reason for repair
o Determine parts needed
o Perform repair
o Calculate parts extended and total cost
o Record labor hours, cost
Bus Garage Repairs (cont…)
 Data stores:
o Personnel file
o Repairs file
o Bus master list
o Parts list
 Data flows:
o Repair order
o Bus record
o Parts record
o Employee timecard
o Invoices
Bus Garage Context Diagram

Bus

Mechanical Fixed
problem mechanical
to be repaired problems

Repair Supervisor
Helper Labor Bus summary
Repair
Process List of
System parts used Inventory
Labor Management
Labor, System
parts cost
details
Mechanic

Accounting
 Diagram 0 DFD (Level-0 diagram)
- Diagram 0 (zero) provides an
overview of all the components
that interact to form the overall
system.
- It zooms in on the system and
shows major internal processes,
data flows, and data stores.

Fig. 1. Diagram 0 for Grading System

Decomposition of DFDs

 The act of going from a single system to four component

processes is called (functional) decomposition.
 Functional decomposition is an iterative process of breaking
the description or perspective of a system down into finer and
finer detail.
 This process creates a set of hierarchically related charts in
which one process on a given chart is explained in greater
detail on another chart.
Level-1 DFD

 Level-1 diagram showing the decomposition of Process 1.0

from the level-0 diagram for Hoosier Burger’s food-ordering
system
 Example of Level – n DFD
 A DFD that is the result of n nested
decompositions from a process on a level-0
diagram.
 The DFD in the Figure describes adding
and removing books, which is a function
shown in the Library Management

Level-1 diagram showing the decomposition of Process 4.0 from

the level-0 diagram for Hoosier Burger’s food-ordering system
Data dictionary
A data dictionary (DD) is a part of the database that contains
meta data i.e. data about data.
Typically it will be stored in the same way as all other data
i.e. in tables.
 A DD contains a list of all files in the database, the number of
records in each file, and the names and types of each field.
 Data dictionaries do not contain any actual data from the
database, only bookkeeping information for managing it.
Why do we need a DD?
 An analyst uses the DD to collect, document, and organize specific facts
about the system, including the contents of data flows, data stores,
entities, and processes.
 May be referenced during system design, programming, and by
actively-executing programs.

 For example:
- An auto parts store inventory record might include part number,
description, supplier code, minimum and maximum stock levels,
cost, and list price.
Functions and parts of a data dictionary

 Store entity (table) definitions

 Store synonyms, views etc.
 Define access control
 Produce reports
 Store relationship definitions
 Provide a user interface
Information Stored in a Data Dictionary

 The names associated with that element (aliases)

 A description of the data element in natural language.
 Details of ownership.
 Details of users that refer to the element.
 Details of the systems and programs which refer to or update the
element.
 Details on any privacy constraints that should be associated with
the item.
Cont…

 Details about the data element in data processing systems, such as the
length of the data item in characters, whether it is numeric alphabetic or
another data type, and what logical files include the data item.
 The security level attached to the element in order to control access.
 The total storage requirement.
 The validation rules for each element (e.g. acceptable values).
 Details of the relationship of the data items to others.
Cont…
 Data Dictionary
 Documenting the Data Flows
- The typical attributes are as follows
o Data flow name or label
o Description
o Alternate name(s)
o Origin
o Destination
o Record
o Volume and frequency
Benefits of a DDS
Benefits of a DDS are mainly due to the fact that it is a central store of information
about the database. Benefits include:
 Improved documentation and control
 Consistency in data use
 Easier data analysis
 Reduced data redundancy
 Simpler programming
 The enforcement of standards
 Better means of estimating the effect of change.
Types of Data Dictionary
1) Independent (free-standing, standalone)
- Necessary to make entry in DD after change to DB
- May lead to inconsistency
2) Integrated (interfaced, dependant)
- Stored and managed by the DBMS
3) Embedded (active)
- DD is fully functional part of the DBMS
Process Description Tools
- A process description documents the details of a functional primitive
and represents a specific set of processing steps and business logic.
- Typical process description tools include:
 Structured English,
 Decision tables, and
 Decision trees.
Logical Versus Physical Models
 A logical model shows what the system must do, regardless of
how it will be implemented physically.
 A physical model describes how the system will be
constructed.
 Structured analysis tools are used to develop both logical and
physical models
 DFDs do not show the logic inside the processes, Logic
modeling can be used to show when processes on a DFD occur
Logic Modeling
Logic modeling involves representing internal structure and functionality
of processes depicted on a DFD
Deliverables and Outcomes
 Structured English
 Decision Tables
 Decision Trees
 State-transition diagrams
 Sequence diagrams
 Activity diagrams
Modeling Logic with Structured English
 Structured English - is a modified form of English used to
specify the logic of information processes
 Uses a subset of English
•Action verbs
• Noun phrases
• No adjectives or adverbs
 No specific standards
Modeling Logic with Structured English
 Similar to programming language
o If conditions
o Case statements
o Psudocode
Example: Structured English
The VERIFY
ORDER process
description
includes logical
rules and a
structured
English version
of the policy.
Structured English (Cont…)
Modeling Logic with Decision Tables
 Decision table: A matrix representation of the logic of a
decision
 Specifies the possible conditions and the resulting actions
 Best used for complicated decision logic
Modeling Logic with Decision Tables
Consists of three parts
 Condition stubs
- Lists condition relevant to decision
 Action stubs
- Actions that result from a given set of conditions
 Rules
- Specify which actions are to be followed for a given set of
conditions
Modeling Logic with Decision Tables
Indifferent Condition
- Condition whose value does not affect which action is taken for two or more rules
Standard procedure for creating decision tables
- Name the condition and values each condition can assume
- Name all possible actions that can occur
- List all rules
- Define the actions for each rule
- Simplify the table
Complete decision table for payroll system example
Modeling Logic with Decision Trees
Decision Tree: is a graphical representation of a decision situation
 Decision situation points are connected together by arcs and terminate in
ovals
 Two main components
- Decision points represented by nodes
- Actions represented by ovals
Modeling Logic with Decision Trees
 Read from left to right
 Each node corresponds to a numbered choice on a legend
 All possible actions are listed on the far right
Decision tree representation of the decision logic in the Payroll
system decision table, with only two choices per decision point
Alternative decision tree representation of salary decision,
with multiple choices per decision point
 Decision tree representation of the decision logic in the decision tables,
with multiple choices per decision point
Choosing a Structured Decision Analysis Technique
 The following guidelines provide you with a way to choose one of the three techniques for a
particular case:
1. Use structured English when
a. There are many repetitious actions,
OR b. Communication to end users is important.
2. Use decision tables when
a. Complex combinations of conditions, actions, and rules are found,
OR b. You require a method that effectively avoids impossible situations, redundancies,
and contradictions.
3. Use decision trees when
a. The sequence of conditions and actions is critical,
OR b. When not every condition is relevant to every action (the branches are different).
Deciding Among Structured English, Decision Tables
and Decision Trees
Criteria Structured Decision Decision
English Tables Trees
Determining Second Best Third Best Best
Conditions and
Actions
Transforming Best Third Best Best
Conditions and
Actions into
Sequence
Checking Third Best Best Best
Consistency and
Completeness
Summary
Several methods of logic modeling
 Structured English
- Primarily communication technique for analysts and users
 Decision Tables
- Conditions are listed in condition stubs
- Possible actions are listed in action stubs
- Rules link conditions with actions
- Lists all possible rules
Summary
 Decision Trees
- Conditions are portrayed by decision points
- Values are represented by paths between decision points and
ovals that contain actions
Summary
 Comparison of Structured English, Decision Tables and Decision
Trees
- Most studies show that decision trees are best for many criteria
- There is no best technique
- Analyst must be proficient in all three
 Questions?

a) Draw a decision tree to show the noncash purchase approval action for
a department store
i) Draw a context DFD for the above example with at least 1 process
b) The IT manager has asked you to develop a decision table that will
reflect the promotional rules that a programmer will use. She wants you
to show all possibilities, and then to simplify the results to eliminate any
combinations that would be unrealistic or redundant.