Transcript Information Systems 1

IMS9001 - Systems Analysis and Design
Topic 4
PROCESS MODELLING USING
DATA FLOW DIAGRAMS;
DETAILED PROCESS
DEFINITIONS;
THE DATA DICTIONAARY
4.1
Logical and physical DFDs
Data flow diagrams may focus on either:
 the “physical” view of the system’s
processing
OR
 the “logical” view of the system’s
processing
4.2
Physical DFDs
 represent a particular way of
implementing the processes and data in a
system
 they are technology dependent
 they show how the processing takes place
and how the data is implemented
4.3
Logical DFDs
 represent what a system must do regardless of
how it is implemented
 they are technology independent
 they show what processing, data movements
and data storage must occur in a system
 they show the essential aspects of a system
4.4
Using Logical and Physical DFDs
physical DFDs help systems analysts become familiar
with how a business or system operates
physical DFDs help systems analysts understand and
document problems with existing systems
users can relate to physical DFDs more readily because
they contain implementation details:
landmarks e.g. people or roles, actual locations
implementation details can be removed
from physical DFDs
4.5
Physical to Logical DFDs
use names for data flows and data
stores which indicate their content, not
their physical form or location
use names for processes that indicate
what, not how
4.6
Physical to Logical DFDs
AZ104 form
2.1
Bill
checks
form
sales order
2.1
Validate
sales
order
checked AZ104 form
Master File
valid sales order
Sales orders
4.7
Physical to Logical
eliminate physical processes that refer to physical activities
only and do not transform data
daily mail
delivery
1.1.1
opened mail
Open
mail
customer order
1.1.2
Retrieve
mail
orders
mail orders
1.1.3
Register
mail
orders
registered
mail orders
1.1.1
Record
customer
order
received customer order
4.8
Physical to Logical
remove any data stores that are implementation dependent
1.1.2
1.1.1
transactions
Update
master
file
Validate
transactions
Transaction file
Master file
1.1.1
employee details
Validate
employee
details
Employees
4.9
Physical to Logical
avoid arbitrary sequencing
2.1.2
2.1.3
A
B
only show this sequence if process B
requires data produced by process A
4.10
Physical to Logical
 consider the implications for processing cycles of
1.1.1
sales order
showing data stores
1.1.2
Produce
customer
invoice
Validate
sales
order
customer invoice
Sales orders
OR
1.1.2
1.1.1
sales order
Validate
sales
order
valid sales order
Produce
customer
invoice
customer invoice
4.11
Example Physical DFD and
Logical DFD
an example physical DFD for part of an order processing system
AZ4-order
form
2..1.1
checked
order forms
Orders
clerk
2..1.2
Sorted orders file
Run the
orders
program
Sort into
order
number
reject
2.1.3
Stock file
processed
orders
a logical DFD derived from the physical DFD above
Products
sales orders
reject
2..1.1
Check
sales
orders
valid sales
orders
2..1.2
Check
stock
available
2..1.3
Complete
sales
orders
accepted sales orders
filled sales orders
4.12
Logical and Physical DFDs
Physical DFDs
View
Logical DFDs
How processing is What the system does
implemented
Processes
Actual sequence
Essential sequence
Naming
Forms, locations,
people/roles
Underlying data and
activities
Data flows
Excess/duplicated data
for implementation
needs
Only essential inputs
and outputs of the
processes
4.13
Building a Set of Data Flow Diagrams
originally there were four different types of DFDs
used in a four stage modelling process:
 current physical model
build a set of physical DFDs representing
the current system
 current logical model
derive a logical equivalent

new logical model
incorporate new system requirements identified

new physical model
add physical implementation details to reflect the
selected implementation option
4.14
Building a Set of Data Flow Diagrams
disadvantages of the four stage modelling approach:
 unnecessary emphasis on detailed modelling
of existing system
 inhibits creative problem solving and redesign
preferred approach:
 create a set of physical DFDs for the current system
which are detailed enough to understand and grasp
any problems
 focus on the essential model of the system, i.e. the
new logical model which identifies what the new
system must do
4.15
Data Dictionary (Repository)
 the data dictionary is a database or repository
of information about objects identified during
systems development
 every object (and each of its components) must
have a definition in the data dictionary
 the data dictionary is a major source of
documentation about the information system
4.16
Data Dictionary Entries for
Components of DFDs
 the data dictionary must contain precise definitions of all
components of all data flow diagrams:
 to fully explain the meaning of the DFDs
 to describe the contents of all data flows and data
stores
 to describe the processing that occurs in primitive
processes
 to ensure that names and meanings of components
are used consistently (a common vocabulary)
4.17
Data Dictionary Entries
 a data dictionary entry must be included
for each





data flow
data store
higher level process
primitive process
external agent (source/sink)
4.18
Data elements
 each data flow consists of a series of data
elements
 a data element is a unit of data that cannot
be further broken down into meaningful units
of data
 each data element should also have an entry
in the data dictionary
 data flows and data stores are made up of
data elements
4.19
Data Elements
 a data dictionary entry for a data element should include
any aliases (alternative names), a brief description of its
meaning, the kinds of values it can take, and the range
of values it can have (if appropriate)
E.g.
Data element:
Alias:
Description:
Values:
Range:
product code
product number
identifies a product held in
the warehouse
must be a positive integer
between 1000 and 5000
4.20
Data Flows
 a data dictionary entry for a data flow describes the
sequence of data elements and data structures in the
data flow using the following connectors:
 =
is equivalent to
 +
and
 [ ]
select one of
 {}
iterations of
 ()
optional
 *
comments
4.21
Example Data Flow Entry
 sales order =
sales order no.
+
sales order date
+
customer number +
[account customer
cash customer]
+
customer name
+
customer address +
(customer telephone no) +
{item no + item desc + item price +
item qty} +
sales order total amount
4.22
Data Stores
 a data store is made up of data flows and data elements
 where a data store consists of a collection of data flows
it is described as repetitions of that data flow
 e.g.
Data Store:
{customer invoice}
 data stores may also be described by listing their data
elements
 e.g customer deposit
=
account no +
deposit date +
deposit amount +
account balance
4.23
Describing Processes
 each process in higher level DFDs is defined by the DFD
that decomposes the process at the next level down:
these are parent processes
 each such process should have a data dictionary entry
which includes a brief description of the overall nature
and purpose of the process
4.24
Describing Processes
 example data dictionary entry for a process
Treat patients:
Patient consultations are carried out to
determine the causes of patients’ illnesses/
medical problems. Further treatment/
follow up is recommended if appropriate.
Details of consultations are recorded.
 specific process description (minispecs)
4.25
Describing External Agents
 each external agent (source or sink) should have a data
dictionary entry which describes its relationship with the
system
 e.g.
Referring Doctors:
These are doctors who refer their patients to a specialist
medical practitioner for treatment. They are usually
general practitioners.
4.26
Building and Maintaining
the Data Dictionary
 determine standard formats and information content for
all types of data dictionary entries
 have a standard means of organising and storing the
entries in the data dictionary
 ensure that all components of the DFDs have entries in
the data dictionary and that they are kept up-to-date
 cross-referencing of entries in the data dictionary can
help to check the completeness and consistency of the
DFDs and other types of models
4.27
Detailed Process Definitions
 the processing that occurs within the bottom level
(primitive) processes in DFDs needs to be defined
 detailed process descriptions are also known as
minispecs
 detailed process descriptions form part of the data
dictionary: they define the contents of primitive
processes
4.28
Detailed Process Definitions
 many techniques can be used to define the
details of processing:

e.g. narrative text
Structured English
decision tables
decision trees
flow charts
4.29
Detailed Process Definitions
detailed process descriptions should:
 express what the process does (i.e. policy), not how the
process is carried out (i.e. procedure)
 be in a form that can be easily understood and verified
by both users and systems analysts
 be in a form that can be easily communicated to all
potential stakeholders:
e.g.
end-users, systems analysts, managers,
system designers, project leaders, programmers
4.30
Structured English
Structured English is a modified form of English with
some major restrictions on vocabulary and structure:
 only action (imperative) verbs such as get, put, add,
calculate, find, delete are used
 only nouns/noun phrases which refer to components of
the DFDs should be used, i.e. data flows, data stores,
data elements
4.31
Structured English
 sentences consist of action verbs and DFD
components
 sentences are combined to form process
descriptions using the control structures of
sequence, condition, and repetition
4.32
Control Structures
 Condition uses
or
Select Case
If... Then...Else
Case 1...Case 2...End Case
 E.g.
If qty-in-stock is less than minimum-order-qty
Then update stock-reorder indicator
Else do nothing
4.33
Control Structures
 e.g.
Select Case
CASE 1
qty-in-stock is less than
minimum-order-qty
Do update stock-reorder indicator
CASE 2
qty-in-stock is equal to minimumorder-qty
Do nothing
CASE 3
qty-in-stock is greater than minimumorder-qty
Do nothing
End Case
4.34
Control Structures
 Sequence is represented with one sentence
following another in sequence:
Add student to class list
Decrease available-places
Calculate class-fee
4.35
Control Structures
 Repetition uses Do-Until or Do-While loops:
Do
Accept customer-account-details
Calculate daily-interest = daily balance * daily
interest rate
Add daily-interest to monthly-interest-due
Until
no more customer-accounts
4.36
Example Structured English
Accept sales-order
Find customer-details
If customer-details not found
Then reject sales-order
Else
Create sales-order-header
Do while more sales-order-items
find item-details
calculate sales-order-item price =
item price *order-qty
Enddo
Authorise sales-order
Endif
4.37
Guidelines for Structured English
 use indentation to indicate control structures and their
scope: assists readability and understanding
 avoid more than three levels of nesting: complicated logic
can be represented using other techniques
 Stuctured English descriptions should illustrate the logic of
the processing, not the implementation of the processing
4.38
Decision Tables
 decision tables are useful for describing processes where
several different conditions apply and the particular
actions that are taken are determined by combinations
of the values of the conditions
 decision tables are useful where the process logic is
complex
 decision tables show all the possible choices and the
conditions they depend on in a tabular form
4.39
Decision Tables
decision tables have three stubs (four quadrants):
combinations of condition values
conditions
actions
rules
outcomes
for each set
of condition
values
4.40
Example Decision Table
avg account bal >
$1,000
overdraft amount
< $50,000
previous paid-out
loan
approve
conditional
approval
reject
Y
Y
Y
Y
N
N
Y
Y
N
N
Y
Y
N
N
Y
N
Y
N
Y
N
Y
N
X
X
X
X
X
N
N
X
X
X
4.41
Decision Trees
decision trees are an alternative graphical representation of a
decision situation as a connected series of nodes and branches
local item
15%
wholesale
customer
imported item
local item
10%
12%
retail
customer
Determine Customer Discount
imported item
7%
4.42
Selecting Techniques for Process
Descriptions
 Structured English is useful where a process has
a sequence of activities and there is no more
than three levels of nesting of decisions
 decision trees and decision tables are useful
where a process involves a decision based on
combinations of values of several conditions
4.43
Selecting Techniques for Process
Descriptions
 decision trees visually distinguish the decision conditions
and their values from the actions:
they show the paths that decisions can follow but soon
become cluttered if each condition has several possible
values
 decision tables are able to show decisions involving
many conditions each with many possible values
4.44
Overview of Process Modelling
 several techniques are available for representing
the processing within systems
 the aim of process modelling in systems analysis
is to define the processing that occurs within a
system
4.45
Process Modelling Techniques
 models representing:
an overview of the system processing
the structure of the system processing
the flow of data into and out of the processes
the detailed logic of the processes
can be constructed
4.46
References
 HOFFER, J.A., GEORGE, J.F. and VALACICH (2005)
Modern Systems Analysis and Design, (4th edition),
Pearson Education Inc., Upper Saddle River, New
Jersey, USA. Chapters 7, 8
 WHITTEN, J.L., BENTLEY, L.D. and DITTMAN, K.C.
(2001) 5th ed., Systems Analysis and Design Methods,
Irwin/McGraw-HilI, New York, NY. Chapter 8
4.47