Process Modeling
Introduction

The chapter will address the following questions:







What is systems modeling and what is the difference between
logical and physical system models?
What is process modeling and what are its benefits?
What are the basic concepts and constructs of a process model.
How do you read and interpret a data flow diagram.
When in a project are process models constructed and where are
they stored?
How do you construct a context diagram to illustrate a system’s
interfaces with its environment?
How do you identify external and temporal business events for a
system?
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
1
Copyright Irwin/McGraw-Hill 1998
Process Modeling
Introduction

The chapter will address the following questions:



How do you perform event partitioning and organize events in a
functional decomposition diagram?
How do you draw event diagrams and then merge those event
diagrams into a system diagram?
How do you draw primitive data flow diagrams, and describe the
elementary data flows and processes in terms of data structures and
procedural logic (Structured English and decision tables),
respectively?
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
2
Copyright Irwin/McGraw-Hill 1998
Process Modeling
An Introduction to System
Modeling

System Models



System models play an important role in systems development.
Systems analysts or users constantly deal with unstructured
problems.
One way to structure such problems is to draw models.
 A model is a representation of reality. Just as a picture is worth
a thousand words, most system models are pictorial
representations of reality.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
3
Copyright Irwin/McGraw-Hill 1998
Process Modeling
An Introduction to System
Modeling

System Models

Models can be built for existing systems as a way to better
understand those systems, or for proposed systems as a way to
document business requirements or technical designs.


Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
Logical models show what a system ‘is’ or ‘does’. They are
implementation-independent; that is, they depict the system
independent of any technical implementation. As such, logical models
illustrate the essence of the system. Popular synonyms include
essential model, conceptual model, and business model.
Physical models show not only what a system ‘is’ or ‘does’, but also
how the system is physically and technically implemented. They are
implementation-dependent because they reflect technology choices,
and the limitations of those technology choices. Synonyms include
implementation model and technical model
4
Copyright Irwin/McGraw-Hill 1998
Process Modeling
An Introduction to System
Modeling

System Models

Systems analysts have long recognized the value of separating
business and technical concerns.
 They use logical system models to depict business
requirements.
 They use physical system models to depict technical designs.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
5
Copyright Irwin/McGraw-Hill 1998
Process Modeling
An Introduction to System
Modeling

System Models

Systems analysis activities tend to focus on the logical system
models for the following reasons:
 Logical models remove biases that are the result of the way the
current system is implemented or the way that any one person
thinks the system might be implemented.
 Logical models reduce the risk of missing business
requirements because we are too preoccupied with technical
details.
 Logical models allow us to communicate with end-users in
non-technical or less technical languages.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
6
Copyright Irwin/McGraw-Hill 1998
Process Modeling
An Introduction to System
Modeling

System Models

What is Process Modeling?
 Process modeling is a technique for organizing and
documenting the structure and flow of data through a system’s
PROCESSES and/or the logic, policies, and procedures to be
implemented by a system’s PROCESSES.
 Process modeling originated in classical software engineering
methods.
 A systems analysis process model consists of data flow
diagrams (DFDs).
• A data flow diagram (DFD) is a tool that depicts the flow of data
through a system and the work or processing performed by that
system. Synonyms include bubble chart, transformation graph, and
process model.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
7
Copyright Irwin/McGraw-Hill 1998
Process Modeling
IN F O R M AT IO N S Y S T E M S F R AM E W O R K
FOCUS ON
FOCUS ON
FOCUS ON
FOCUS ON
S YS T E M
S YS T E M
S YS T E M
S YS T E M
DATA
PROCESSES
IN T E R F A C E S
GEOGRAPHY
B usiness Functions
S ystem C ontext
S u rvey P h ase
Accounts
Receivable
Database
Marketing
(estab lish sco p e
Cr edit
an d p ro ject p lan )
S YS T E M
OW NERS
Advertising
Custom er
Sales
Or der
Or der
Managem ent
System
(sco p e )
Picking
Or der
War ehouse
Cr edit
Voucher
Orders
Cancellations
FAST
M e th o d o lo g y
S tu d y P h ase
Services
Bank
(estab lish
D e c o m p o s itio n D ia g ra m
C o n te x t D ia g ra m
system
B usiness P rocesse
im p ro vem en t
rejected order
Customers
S
Y
S
T
credit
o b jectives)
Check
credit
customer
S YS T E M
number
order with
approved order
valid products
USERS
order
Validate
valid order
Validate
customer
products
Orders
approved
(re q u ire m e n ts)
order without
D efin itio n P h ase
order
prices
valid
customer
picking
E
Products
quantity
Release
in stock
order
ticket
M
(estab lish an d
A
D a ta F lo w D ia g ra m s
p rio ritize
N
A
b u sin ess system
L
req u irem en ts)
Y
S
T
S
R everse
S YS T E M
D E S IG N E R S
E n g in eerin g
(sp e cifica tio n )
(o p tio n al)
S YS T E M
B U IL D E R S
(co m p o n e n ts)
Interface
S oftw are
D atabase
Technology
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
Technology
(and H ardw are)
N etw orking
Telchnology
Technology
8
Copyright Irwin/McGraw-Hill 1998
Process Modeling
M onthly Account
S ta te m e nts
N ew or M odified
M onthly S tatem ent
Ba nk
M onthly
S tatem ent
P rior M onthly
S tatem ent
R e concile
Account
Ba la nce s
Transaction
B ill
C re ditor
P aym ent
A ccount
B alance
C urrent
B alance
Pay
a
Bill
Account
T ra nsa ctions
Ba nk Accounts
M odified B alance
P aym ent
M odified
B alance
W ithdra w
F unds from
a n Account
D eposit
Account
T ra nsa ctions
W ithdraw or transfer
E m ploye r
P ay
D e posit F unds
into a n
Account
Ba nk
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
O the r
Incom e
S ource
9
R eim bursem ent
Copyright Irwin/McGraw-Hill 1998
Process Modeling
An Introduction to System
Modeling

System Models

Data Flow Diagram
 There are only three symbols and one connection:
• The rounded rectangles represent processes or work to be done.
• The squares represent external agents – the boundary of the
system.
• The open-ended boxes represent data stores, sometimes called
files or databases, and correspond to all instances of a single entity
in a data model.
• The arrows represent data flows, or inputs and outputs, to and from
the processes.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
10
Copyright Irwin/McGraw-Hill 1998
Process Modeling
An Introduction to System
Modeling

System Models

Data Flow Diagrams Versus Flowcharts
 Processes on a data flow diagram can operate in parallel.
Processes on flowcharts can only execute one at a time.
 Data flow diagrams show the flow of data through the system.
• Their arrows represent paths down which data can flow. Looping
and branching are not typically shown.

Flowcharts show the sequence of processes or operations in an
algorithm or program.
• Their arrows represent pointers to the next process or operation.
This may include looping and branching.

Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
Data flow diagrams can show processes that have dramatically
different timing and flowcharts don’t.
11
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

What is Systems Thinking?



Systems thinking is the application of formal systems theory and
concepts to systems problem solving.
Systems theory and concepts help us understand the way systems
are organized, and how they work.
Techniques teach us how to apply the theory and concepts to build
useful real-world systems.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
12
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Process Concepts

A System is a Process
 The simplest process model of a system is based on inputs,
outputs, and the system itself – viewed a process.
 The process symbol defines the boundary of the system.
 The system is inside the boundary; the environment is outside
that boundary.
 The system exchanges inputs and outputs with its environment.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
13
Copyright Irwin/McGraw-Hill 1998
Process Modeling
in p u t
in p u t
in p u t
T he
S ystem
P rocess
o u tp u t
o u tp u t
o u tp u t
F eeb ack an d
C o n tro l L o o p
The S yste m's E nvironme nt
(consta ntly cha nging)
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
14
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Process Concepts

P ro c e s s n a m e
(th e G a n e & S a rs o n s h a p e ;
u s e d th ro u g h o u t th is b o o k )
A System is a Process (continued)
 A rounded rectangle (the Gane and Sarson notation) is used
represent a process.
 Other process modeling notations:
• The Demarco/Yourdon notation uses a circle.
• The SSADM/IDEF0 notation uses a rectangle.
P ro c e s s n a m e

(th e D e M a rc o & Y o u rd o n s h a p e )
What is a process?
• A process is work performed on, or in response to, incoming data
flows or conditions. A synonym is transform.
P ro c e s s n a m e
(th e S S A D M & ID E F 0 s h a p e )
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
15
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Process Concepts

Process Decomposition
 What do you do when a complex system is too difficult to fully
understand when viewed as a whole (meaning, as a single
process)?
• In systems analysis we separate a system into its component
subsystems, which in turn are decomposed into smaller
subsystems, until such a time as we have identified manageable
subsets of the overall system.
• This technique is called decomposition.
– Decomposition is the act of breaking a system into its
component subsystems, processes, and subprocesses. Each
‘level’ of abstraction reveals more or less detail (as desired)
about the overall system or a subset of that system.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
16
Copyright Irwin/McGraw-Hill 1998
Process Modeling
0
The S yste m
1
A Function of the S yste m
1 .1
Activity of the Function
T ask 1.1.1
1 .2
Anothe r Activity of the Function
T ask 1.1.2
T ask 1.2.1
T ask 1.2.2
T ask 1.1.3
2
Anothe r Function of the S yste m
2 .1
Activity of this Function
T ask 2.1.1
2 .2
Anothe r Activity of this Function
T ask 2.1.2
T ask 2.2.1
T ask 2.1.3
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
T ask 2.1.4
T ask 2.2.2
T ask 2.2.3
17
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Process Concepts

Process Decomposition (continued)
 A decomposition diagram is a popular tool to illustrate system
decomposition.
• A decomposition diagram, also called a hierarchy chart, shows
the top down functional decomposition and structure of a system.

Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
A decomposition diagram is essentially a planning tool for
more detailed processes models, namely, data flow diagrams.
18
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Process Concepts

Process Decomposition (continued)
 The decomposition diagram rules:
• Each process in a decomposition diagram is either a parent
process, a child process (of a parent), or both.
• A parent must have two or more children – a single child does not
make sense since that would not reveal any additional detail about
the system.
• In most decomposition diagramming standards, a child may have
only one parent.
• A child of one parent may, of course, be the parent of its own
children.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
19
Copyright Irwin/McGraw-Hill 1998
Process Modeling
0
T he S yste m
2
Anothe r
F unction
1
A F unction
1 .1
Activity of the
F unction
2 .1
Acivity of this
F unction
1 .2
Anothe r Activity
of the F unction
2 .2
Anothe r Activity
of this F unction
T a sk 1 .1 .1
T a sk 1 .2 .1
T a sk 2 .1 .1
T a sk 2 .2 .1
T a sk 1 .1 .2
T a sk 1 .2 .2
T a sk 2 .1 .2
T a sk 2 .2 .2
T a sk 2 .1 .3
T a sk 2 .2 .3
T a sk 1 .1 .3
T a sk 2 .1 .4
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
20
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Process Concepts

Logical Processes and Conventions
 Logical processes are work or actions that must be performed
no matter how you implement the system.
 Each logical process is (or will be) implemented as one or more
physical processes that may include:
• work performed by people
• work performed by robots or machines
• work performed by computer software

Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
Naming conventions for logical processes depend on where the
process is in the decomposition diagram/data flow diagram and
type of process depicted.
21
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Process Concepts

Logical Processes and Conventions (continued)
 There are three types of logical processes: functions, events,
and elementary processes.
• A function is a set of related and on-going activities of the
business. A function has no start or end – it just continuously
performs its work as needed.
– Each of these functions may consist of dozens, or hundreds of
more discrete processes to do support specific activities and
tasks.
– Functions serve to group the logically related activities and
tasks.
– Functions are named with nouns that reflect the entire function.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
22
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Process Concepts

Logical Processes and Conventions (continued)
 There are three types of logical processes: functions, events,
and elementary processes.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
• An event is a logical unit of work that must be completed as a
whole. An event is triggered by a discrete input, and is completed
when the process has responded with appropriate outputs. Events
are sometimes called transactions.
– Functions consist of processes that respond to events.
– Each of these events has a trigger and response that can be
defined by its inputs and outputs.
– System functions are ultimately decomposed into business
events.
– Each business event is represented by a single process that will
respond to that event.
23
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Process Concepts

Logical Processes and Conventions (continued)
 There are three types of logical processes: functions, events,
and elementary processes.
• A event process can be further decomposed into elementary
processes that illustrate in detail how the system must respond to
an event.
– Elementary processes are discrete, detailed activities or tasks
required to complete the response to an event. In other words,
they are the lowest level of detail depicted in a process model.
A common synonym is primitive process.
– Elementary processes should be named with a strong action
verb followed by an object clause that describes what the work
is performed on (or for).
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
24
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Process Concepts

Logical Processes and Conventions (continued)
 Logical process models omit any processes that do nothing
more than move or route data, thus leaving the data unchanged.
 You should be left only with logical processes that:
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
• Perform computations (e.g., calculate grade point average)
• Make decisions (determine availability of ordered products)
• Sort, filter or otherwise summarize data (identify overdue
invoices)
• Organize data into useful information (e.g., generate a report or
answer a question)
• Trigger other processes (e.g., turn on the furnace or instruct a
robot)
• Use stored data (create, read, update or delete a record)
25
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Process Concepts

Logical Processes and Conventions (continued)
 Be careful to avoid three common mechanical errors with
processes (as illustrated in the following slide):
• A black hole is when a process has inputs but no outputs. Data
enters the process and then disappears.
• A miracle is when a process has outputs but no input.
• A gray hole is when the inputs of a process are insufficient to
produce the output. (most common)
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
26
Copyright Irwin/McGraw-Hill 1998
Process Modeling
M e m be rship
a pplica tion
E m ploye e
Ba nk sta te m e nt
E xisting a ccount
3 .1 .1
G e ne ra te a n
e m ploye e ba nk
sta te m e nt
3 .1 .2
C re a te a ne w
m e m be r a ccount
E m ploye e
sta tus
E m ploye e a ddre ss
E m ploye e s
M e m be r Accounts
N e w a ccount sta tus
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
3 .1 .3
F re e z e m e m be r
a ccount num be r
27
F roz e n a ccount notifica tion
Accounts
R e ce iva ble
D e pa rtm e nt
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Process Concepts

Process Logic
 Decomposition diagrams and data flow diagrams will prove
very effective tools for identifying processes, but they are not
good at showing the logic inside those processes.
 We need to specify detailed instructions for the elementary
processes on a data flow diagram.
 To address this problem, we require a tool that marries some of
the advantages of natural English with the rigor of
programming logic tools.
• Structured English is a language and syntax, based upon the
relative strengths of structured programming and natural English,
for specifying the underlying logic of elementary processes on
process models (such as data flow diagrams).
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
28
Copyright Irwin/McGraw-Hill 1998
Process Modeling
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
*
M any of us do not write well, and we also tend not to question our writing abilities.
*
M any of us are too educated! It’s often difficult for a highly educated person to communicate with an
audience that may not have had the same educational opportunities. F or example, the average college
graduate (including most analysts) has a working vocabulary of 10,000 to 20,000 words; on the other
hand, the average non-college graduate has a working vocabulary of around 5,000 words.
*
S ome of us write everything like it was a program. If business procedures required such precision,
we’d write everything in a programming language.
*
Too often, we allow the jargon and acronyms of computing to dominate our language.
*
E nglish statements frequently have an excessive or confusing scope. How would you carry out this
procedure: “If customers walk in the door and they do not want to withdraw money from their
account or deposit money to their account or make a loan payment, send them to the trust
department.” D oes this mean that the only time you should not send the customer to the trust
department is when he or she wishes to do all three of the transactions? O r does it mean that if a
customer does not wish to perform at least one of the three transactions, that customer should not be
sent to the trust department?
*
W e overuse compound sentences C onsider the following procedure: “R emove the screws that hold
the outlet cover to the wall. R emove the outlet cover. D isconnect each wire from the plug, but first
make sure the power to the outlet has been turned off.” An unwary person might try to disconnect the
wires prior to turning off the power!
*
Too many words have multiple definitions.
*
Too many statements use imprecise adjectives. F or example, an loan officer asks a teacher to certify
that a student is in good academic standing. W hat is good?
*
C onditional instructions can be imprecise. F or example, if we state that “all applicants under the age
of 19 must secure parental permission,” do we mean less than 19, or less than or equal to 19?
*
C ompound conditions tend to show up in natural E nglish. F or example, if credit approval is a
function of several conditions: credit rating, credit ceiling, annual dollar sales for the customer in
question, then different combinations of these factors can result in different decisions. As the number
of conditions and possible combinations increases, the procedure becomes more and more tedious
and difficult to write.
29
Copyright Irwin/McGraw-Hill 1998
Process Modeling
1 . For each C UST O M E R N UM B E R in the data store C UST O M E R S :
a . For each LO A N in the data store LO A N S that m atches the above C UST O M E R N UM B E R :
1 ) K eep a ru nning total of N UM B E R O F LO A N S for the C UST O M E R N UM B E R .
2 ) K eep a ru nning total of O R IGIN A L LO A N P R IN C IP LE for the C UST O M E R N UM B E R .
3 ) K eep a ru nning total of C UR R E N T LO A N B A LA N C E for the C UST O M E R N UM B E R .
4 ) K eep a ru nning total of A M O UN T S P A ST D UE for the C UST O M E R N UM B E R .
b. If the T O T A L A M O UN T S P A ST D UE for the cu stom er nu m ber is greater than 1 0 0 .0 0 then
1 ) W rite the cu stom er nu m ber and data in the data flow LO A N S A T R ISK .
E lse
1 ) E xclu de the cu stom er nu m ber and data from the data flow LO A N S A T R ISK .
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
30
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Process Concepts

Process Logic (continued)
 The overall structure of a Structured English specification is
built using the fundamental constructs that have governed
structured programming for nearly three decades.
 These constructs are:
• A sequence of simple, declarative sentences – one after another.
• A conditional or decision structure indicate that a process must
perform different actions under well specified conditions.
• A iteration or repetition structure specifies that a set of actions
should be repeated based on some stated condition. There are two
variations on this construct.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
31
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Process Concepts

Process Logic (continued)
 The sequence construct:
• Compound sentences are discouraged because they frequently
create ambiguity.
• Each sentence uses strong, action verbs such as GET, FIND,
RECORD, CREATE, READ, UPDATE, DELETE, CALCULATE,
WRITE, SORT, MERGE, or anything else recognizable or
understandable to the users.
• A formula may be included as part of a sentence (e.g.,
CALCULATE GROSS PAY = HOURS WORKED X HOURLY
WAGE.)
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
32
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Process Concepts

Process Logic (continued)
 The conditional or decision structure construct:
• There are two variations (and a departure) on this construct.
– The IF-THEN-ELSE construct specifies that one set of actions
should be taken if a specified condition is ‘true’, but a different
set of actions should be specified if the specified condition is
false.
– The CASE construct is used when there are more than two sets
of actions to choose from.
– For logic that based on multiple conditions and combinations
of conditions, decision tables are a far more elegant logic
modeling tool.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
33
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Process Concepts

Process Logic (continued)
 The iteration or repetition construct:
• There are two variations on this construct.
– The DO-WHILE construct indicates that certain actions
(usually expressed as one or more sequential and/or
conditional statements) are repeated zero, one, or more times
based on the value of the stated condition.
– The REPEAT-UNTIL constructs indicates that certain actions
(again, usually expressed as one or more sequential and/or
conditional statements) are repeated one or more times based
on the value of the stated condition.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
34
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Process Concepts

Process Logic (continued)
 Structured English places the following restrictions on process
logic:
• Only strong, imperative verbs may be used.
• Only names that have been defined in the project repository may
be used.
• State formulas clearly using appropriate mathematical notations.
• Undefined adjectives and adverbs are not permitted unless clearly
defined in the project repository as legal values for data attributes.
• Blocking and indentation are used to set off the beginning and
ending of constructs and to enhance readability.
• When in doubt, user readability should always take precedence
over programmer preferences.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
35
Copyright Irwin/McGraw-Hill 1998
Process Modeling
C on stru ct
S am p le T em p late
S eq u en ce of action s – unconditionally perform a
sequence of actions.
[ Action 1 ]
[ Action 2 ]
…
[ Action n ]
S im p le con d ition action s – if the specified condition
is true, then perform the first set of actions.
O therwise, perform the second set of actions.
If [ truth condition ]
th en
[ sequence of actions or other conditional actions ]
else
[ sequence of actions or other conditional actions ]
E n d If
Use this construct if the condition has only two
possible values.
(N ote: The second set of conditions is optional.)
C om p lex con d ition action s – test the value of the
condition and perform the appropriate set of actions.
Use this construct if the condition has more than two
values.
M u ltip le con d ition s – test the value of multiple
conditions to determine the correct set of actions.
Use a d ecision tab le instead of nested if-then-else
S tructured E nglish constructs to simplify the
presentation of complex logic that involves
A d ecision tab le is a tabular presentation of com plex
logic in w hich row s represent cond itions and possible
actions, and colum ns ind icate w hich com binations of
cond itions result in specific actions.
D o th e followin g b ased on [ condition ]:
C ase 1: If [ condition] = [value] then
[ sequence of actions or other conditional actions ]
C ase 2: If [ condition] = [value] then
[ sequence of actions or other conditional actions ]
…
C ase n : If [ condition] = [value] then
[ sequence of actions or other conditional actions ]
E n d C ase
D E C IS IO N T A B L E
R u le
R u le
R u le
R u le
[ C o n d itio n ]
v alu e
v alu e
v alu e
v alu e
[ C o n d itio n ]
v alu e
v alu e
v alu e
v alu e
[ C o n d itio n ]
v alu e
v alu e
v alu e
v alu e
X
X
[ S eq u en ce o f actio n s o r
co n d itio n al actio n s ]
X
[ S eq u en ce o f actio n s o r
co n d itio n al actio n s ]
[ S eq u en ce o f actio n s o r
co n d itio n al actio n s ]
X
A lthough it isn’t a Structured E nglish construct, a d ecision table
can be nam ed , and referenced w ithin a Structured E nglish
proced ure.
O n e-to-m an y iteration – R epeat the set of actions
until the condition is false.
Use this construct if the set of actions must be
performed at least once, regardless of the condition’s
initial value.
Zero-to-m an y iteration – R epeat the set of actions
until the condition is false.
Use this construct if the set of actions are conditional
based on the condition’s initial value.
R ep eat th e followin g u n til [truth condition]:
[ sequence of actions or conditional actions ]
E n d R ep eat
D o W h ile [truth condition]:
[ sequence of actions or conditional actions ]
End Do
- OR F or [truth condition]:
[ sequence of actions or conditi onal actions ]
E n d F or
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
36
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Process Concepts

Process Logic (continued)
 Many processes are governed by complex combinations of
conditions that are not easily expressed with Structured
English.
 This is most commonly encountered in business policies.
• A policy is a set of rules that govern some process in the business.
In most firms, policies are the basis for decision making.
 Policies consist of rules that can often be translated into
computer programs if the users and systems analysts can
accurately convey those rules to the computer programmer.

Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
37
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Process Concepts

Process Logic (continued)
 One way to formalize the specification of policies and other
complex combinations of conditions is by using a decision
table.
• A decision table is a tabular form of presentation that specifies a
set of conditions and their corresponding actions.

A decision table consists of three components:
• Condition stubs (the upper rows) describe the conditions or factors
that will affect the decision or policy.
• Action stubs (the lower rows) describe, in the form of statements,
the possible policy actions or decisions.
• Rules (the columns) describe which actions are to be taken under a
specific combination of conditions.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
38
Copyright Irwin/McGraw-Hill 1998
Process Modeling
A S IM P L E P O L IC Y S T A T E M E N T
C H E C K C A S H IN G ID E N T IF IC A T IO N C A R D
A c u s to me r with c he c k c a s hing p riv ile ge s is e ntitle d to c a s h
p e rs o na l c he c k s o f u p to $ 7 5 .0 0 a nd p a y ro ll c he c k s o f fro m
c o mp a nie s p re -a p p ro v e d b y LM ART. T his c a rd is is s u e d in
a c c o rd a nc e with the te rms a nd c o nd itio ns o f the a p p lic a tio n a nd is
s u b je c t to c ha nge witho u t no tic e . T his c a rd is the p ro p e rty o f
LM ART a nd s ha ll b e fo rfe ite d u p o n re q u e s t o f LM ART.
S IGN ATUR E
E X P IR E S
M ay 31, 1998
T H E E Q U IVA L E N T P O L IC Y D E C IS IO N T A B L E
C on d ition s an d A ction s
R u le 1
C 1: Type of check
C 2: C heck amount less than or equal to $75.00
C 3: C ompany accredited by L M A R T
A1: C ash the check
A2: D on’t cash the check
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
39
R u le 2
R u le 3
R u le 5
personal
payroll
personal
payroll
yes
doesn’t
matter
no
doesn’t
matter
doesn’t
matter
yes
doesn’t
matter
no
X
X
X
X
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Data Flows

Data in Motion
 A data flow is data in motion.
 The flow of data between a system and its environment, or
between two processes inside a system an relationship between
a system and its environment, or between two processes is
communication.
• A data flow represents an input of data to a process, or the output
of data (or information) from a process. A data flow is also used to
represent the creation, deletion, or update of data in a file or
database (called a data store on the DFD).
• A data flow is depicted as a solid-line with arrow.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
40
Copyright Irwin/McGraw-Hill 1998
Process Modeling
C o rre c t u s e o f th e
packet concept
T e le p h o n e
S e rv ic e
P ro v id e r
Ite m ize d
c a lls
and
In c o rre c t
in v o ic e
u s e o f th e
packet
concept
Ite m ize d c a lls
Pay
phone
In v o ic e
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
b ill
41
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Data Flows

Data in Motion (continued)
 A data flow is composed of either actual data attributes (also
called data structures), or other data flows.
• A composite data flow is a data flow that consists of other data
flows. They are used to combine similar data flows on generallevel data flow diagrams to make those diagrams easier to read.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
42
Copyright Irwin/McGraw-Hill 1998
Process Modeling
Order
Customer
Process
Accepted
order
Order
...
(a) General-Level DFD
Standing
Order
Recurring
Order
Customer
Order
Process
Accepted
standard
Standing
order
Order
Process
Accepted
recurring
Recurring
order
Order
Process
Accepted
...
...
y
Rush
Order
Employee
Order
rush
Rush
order
Order
Process
Accepted
employee
Employee
order
Order
...
...
(b) More Detailed DFD
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
43
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Data Flows

Data in Motion (continued)
 Some data flow diagramming methods also recognize non-data
flows called control flows.
• A control flow represents a condition or non-data event that
triggers a process. Think of it as a condition to be monitored while
the system works. When the system realizes that the condition
meets some predetermined state, the process to which it is input is
started.
• The control flow is depicted as a dashed-line with arrow.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
44
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Data Flows

Logical Data Flows and Conventions
 In the Analysis phase, we are only interested in logical data
flows, that the flow is needed (not how we will implement that
flow).
 Data Flow Names:
• Should discourage premature commitment to any possible
implementation.
• Should be descriptive nouns and noun phrases that are singular, as
opposed to plural.
• Should be unique.
– Use adjectives and adverbs to help to describe how processing
has changed a data flow.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
45
Copyright Irwin/McGraw-Hill 1998
Process Modeling
O rd e r
C a n c e lle d O rd e r
P ro c e s s
Cencel
O rd e r
O rd e r
O rd e r
2
to b e
D e le te d
2
New
O rd e r
O rd e rs
U n fille d
O rd e r
l
New
O rd e r
1
2
A d d re s s
Change
S u m m a rize
O rd e r
U n fille d
A d d re s s
O rd e rs
S u m m a ry o f O rd e rs
C h a n g e o f A d d re s s
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
46
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Data Flows

Logical Data Flows and Conventions (continued)
 No data flow should ever go completely unnamed.
 Data flow names should describe the data flow without
describing how the flow is or could be implemented.
 All data flows must begin or end at a process, because data
flows are the inputs and outputs of a process.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
47
Copyright Irwin/McGraw-Hill 1998
Process Modeling
C o rre c te d
Ille g a l
d a ta
d a ta
flo w s
flo w s
a p ro c e s s is
n e e d e d to
B1
B2
B1
e x c h a n g e d a ta
B1
flo w s b e tw e e n
b o u n d a rie s
a p ro c e s s is
n e e d e d to
B1
DS1
B1
u p d a te (o r
DS1
u s e ) a d a ta
s to re
a p ro c e s s is
n e e d e d to
DS1
B1
DS1
p re s e n t d a ta
B1
fro m a d a ta
s to re
a p ro c e s s is
n e e d e d to
DS1
DS2
DS1
m o v e d a ta
fro m o n e d a ta
DS2
s to re to
a n o th e r
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
48
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Data Flows

Data Flow Conservation
 Data conservation, sometimes called “starving the processes”,
requires that a data flow only contain that data which is truly
needed by the receiving process.
 By ensuring that processes only receive as much data as they
really need, we simplify the interface between those processes.
 In order to practice data conservation, we must precisely define
the data composition of each (non-composite) data flow.
• Data composition is expressed in the form of data structures.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
49
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Data Flows

Data Structures
 A data flow contains data items called attributes.
• A data attribute is the smallest piece of data that has meaning to
the end users and the business.
• The data attributes that comprise a data flow are organized into
data structures.
– Data structures are specific arrangements of data attributes
that define the organization of a single instance of a data flow.

Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
Data flows can be described in terms of the following types of
data structures:
• A sequence or group of data attributes that occur one after another.
• The selection of one or more attributes from a set of attributes.
• The repetition of one or more attributes.
50
Copyright Irwin/McGraw-Hill 1998
Process Modeling
D A T A ST R U C T U R E
ORDER
=
A n in stan ce of
O RD ER N UM BER
O RD ER D AT E
[
E N G L ISH IN T E R P R E T A T IO N
+
+
O RD ER D AT E
PE R SO N A L C U ST O M E R N U M B E R ,
C O R PO R A T E A C C O U N T N U M B E R
E ith er PE R SO N A L C U ST O M E R N U M B E R
or C O R PO R A T E A C C O U N T N U M B E R
an d SH IPPIN G A D D R E SS (w h ich is equivalen t to
A D D R E SS )
an d option ally: B IL L IN G A D D R E SS (w h ich is
eqivalen t to A D D R E SS )
an d on e or m ore in stan ces of:
PR O D U C T N U M B E R an d
PR O D U C T D E SC R IPT IO N an d
Q U A N T IT Y O R D E R E D an d
PR O D U C T PR IC E an d
PR O D U C T PR IC E SO U R C E an d
E X T E N D E D PR IC E
an d SU M O F E X T E N D E D PR IC E S an d
PR E PA ID A M O U N T an d
option ally: both C R E D IT C A R D N U M B E R an d
]+
= A D D R E SS +
( B IL L IN G A D D R E SS = A D D R E SS ) +
1 { PR O D U C T N U M B E R +
PR O D U C T D E SC R IPT IO N +
Q U A N T IT Y O R D E R E D +
PR O D U C T PR IC E +
P R O D U C T PR IC E SO U R C E +
E X T E N D E D PR IC E } N +
SU M O F E X T E N D E D PR IC E S +
PR E PA ID A M O U N T +
( C R E D IT C A R D N U M B E R + E X PIR A T IO N
( Q UO T E N UM BER )
SH IPPIN G A D D R E SS
A D D R E SS
(
C IT Y
[
(
D AT E
)
=
PO ST O FFIC E B O X N U M B E R
ST R E E T A D D R E SS
con sists of:
an d
an d
ORDER
O RD ER N UM BER
)+
E X PIR A T IO N D A T E
+
an d option ally:
Q UO T E N UM BER
+
ST A T E , M U N IC IPA L IT Y
CO UN T RY
)+
PO ST A L C O D E
]+
A n in stan ce of A D D R E SS con sists of:
option ally: PO ST O FFIC E B O X N U M B E R an d
ST R E E T A D D R E SS an d
C IT Y an d
E ith er ST A T E or M U N IC IPA L IT Y
an d option ally: C O U N T R Y
an d PO ST A L C O D E
F igu re 6.15
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
51
Copyright Irwin/McGraw-Hill 1998
Process Modeling
D ata S tructure
S eq uen ce of A ttrib utes - T h e sequen ce data
structure in dicates on e or m ore attributes th at m ay
(or m ust) be in cluded in a data flow .
F orm at b y E xam p le
E n glish In terp retation
(relevan t portion is b old faced )
(relevan t portion is b old faced )
=
W A G E A N D T A X ST A T E M E N T
T A X P A Y E R ID E N T IF IC A T IO N N U M B E R
TAX PAPY ER N AM E
+
R ep etition of A ttrib utes - T h e repetition data
structure is used to set off a data attribute or group
of data attributes th at m ay (or m ust) repeat
th em selves a specified n um ber of tim es for a sin gle
in stan ce of th e data flow .
C L A IM
T h e m in im um n um ber of repetition s is usually zero
or one.
=
C O R PO R ATE AC C O U N T N U M BER
N ote: F or the repetition data structure, a m inim um
of ‘zero’ is the sam e as m aking the entire repeating
grouy ‘optional’.
R eusab le A ttrib utes – F or groups of attributes th at
are con tain ed in m an y data flow s, it is desirable to
create a separate data structure th at can be resued in
oth er data structures.
A n in stan ce of O R D E R con sists of:
E ith er P E R SO N A L C U ST O M E R
)+
O RD ER D AT E
=
A n in stan ce of
+
or
an d
an d …
con sists of:
an d
PO L IC Y H O L D E R N A M E an d
PO L IC Y H O L D E R A D D R E SS an d
zero or m ore in stan ces of:
D E P E N D E N T N A M E an d
D E P E N D E N T ’ S R E L A T IO N SH IP an d
on e or m ore in stan ces of:
E X P E N SE D E SC R IP T IO N an d
SE R V IC E P R O V ID E R an d
C L A IM
PO L IC Y N U M B E R
PO L IC Y H O L D E R N A M E
+
+
PO L IC Y H O L D E R A D D R E SS
0 {
D EPEN D EN T N AM E
+
1 {
E X P E N SE D E SC R IP T IO N
D E P E N D E N T ’ S R E L A T IO N SH IP
SE R V IC E P R O V ID E R
E X P E N SE A M O U N T
+
}
N
+
}
N
+
E X P E N SE A C C O U N T
C L A IM
=
A n in stan ce of
PO L IC Y N U M B E R
+
PO L IC Y H O L D E R N A M E
+
PO L IC Y H O L D E R A D D R E SS
(
SP O U SE N A M E
+
D A T E O F B IR T H
D AT E
)+ …
=
MONTH
D AY
con sists of:
an d
PO L IC Y H O L D E R N A M E an d
PO L IC Y H O L D E R A D D R E SS an d
op tion ally, SP O U SE N A M E an d
D A T E O F B IR T H
an d …
C L A IM
PO L IC Y N U M B E R
+
T h en , th e resuable structures can be in cluded in
oth er data flow structures as follow s:
+
+
O RD ER
Y EAR
=
IN V O IC E
O RD ER N UM BER
=
PA Y M E N T
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
NUM BER
C O R PO R ATE AC C O U N T N U M BER ;
+ …
PO L IC Y N U M B E R
T h e m axim um n um ber of repetition s m ay be
specified as “n ” m ean in g “m an y” w h ere th e actual
n um ber of in stan ces varies for each in stan ce of th e
data flow .
O p tion al A ttrib utes – T h e option al n otation
in dicates th at an attribute, or group of attributes in a
sequen ce or selection data structure m ay n ot be
in cluded all all in stan ces of a data flow .
+
+ …
P E R SO N A L C U ST O M E R N U M B E R ,
O RD ER D AT E
con sists
TAX PAY ER N AM E
F E D E R A L T A X W IT H H E L D
(
W A G E A N D T A X ST A T E M E N T
an d
an d
T A X P A Y E R A D D R E SS an d
W A G E S , T IP S , A N D C O M P E N SA T IO N an d
F E D E R A L T A X W IT H H E L D an d …
+
W A G E S , T IP S , A N D C O M P E N SA T IO N
O RD ER
A n in stan ce of
of:
T A X P A Y E R ID E N T IF IC A T IO N N U M B E R
T A X P A P Y E R A D D R E SS
S election of A ttrib utes - T h e selection data
structure allow s you to sh ow situation s w h ere
differen t sets of attributes describe differen t
in stan ces of th e data flow .
+
52
… +
IN V O IC E N U M B E R
=
D AT E
… +
C U ST O M E R N U M B E R
D AT E
… +
D AT E
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Data Flows

Domains
 An attribute is a piece of data.
 The values for each attribute are defined in terms of two
properties: data type and domain.
• The data type for an attribute defines what class of data can be
stored in that attribute.
• The domain of an attribute defines what values an attribute can
legitimately take on.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
53
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Data Flows

Divergent and Convergent Flows
 A diverging data flow is one which ‘splits’ into multiple data
flows.
• Diverging data flows indicate that all or parts of a single data flow
are routed to different destinations.

A converging data flow is the ‘merger’ of multiple data flows
into a single data flow.
• Converging data flows indicate that data flows from different
sources can (must) come together as a single packet for subsequent
processing.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
54
Copyright Irwin/McGraw-Hill 1998
Process Modeling
d a ta flo w U
d a ta flo w A
1
1
d iv e rg in g
c o n v e rg in g
d a ta flo w B
d a ta flo w
d a ta flo w
A + B + C
U + V + W
d a ta flo w V
d a ta flo w W
d a ta flo w C
d a ta flo w H
3
d a ta flo w I
d a ta flo w R
P ro c e s s
d a ta flo w J
d a ta flo w S
3
d a ta flo w T
d a ta flo w X
d a ta flo w D
c o n v e rg in g
d a ta flo w E
d iv e rg in g
d a ta flo w
d a ta flo w
D or E or F
X or Y or Z
2
2
d a ta flo w Z
d a ta flo w F
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
d a ta flo w Y
55
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

External Agents


All information systems respond to events and conditions in the
environment.
The environment of an information system includes external
agents that form the boundary of the system, and define places
where the system interfaces with its environment.
 A external agent defines an a person, organization unit, other
system, or other organization that lies outside of the scope of
the project, but which interacts with the system being studied.
External agents provide the net inputs into a system, and
receive net outputs from a system. Common synonyms include
external entity.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
56
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

External Agents




The term external means “external to the system being analyzed or
designed.”
An external agent is represented by a square on the data flow
diagram.
The Yourdon/Demarco equivalent is a rectangle
External agents on a logical data flow diagram may include people,
business units, other internal systems with which your system must
interact, and external organizations.
Gane & Sarson
External Agent
Shape
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
DeMarco/Yourdon
External Agent
Shape
57
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

External Agents




External agents should be named with descriptive, singular nouns.
External agents represent fixed, physical systems; therefore, they
can have very physical names or acronyms.
To avoid crossing data flow lines on a DFD, it is permissible to
duplicate external agents on DFDs.
As a general rule, external agents should be located on the
perimeters of the page, consistent with their definition as a system
boundary.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
58
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process
Modeling

Data Stores





Most information systems capture data for later use.
The data is kept in a data store.
 A data store is an ``inventory’’ of data. Synonyms include file
and database (although those terms are too implementationoriented for essential process modeling).
A data store is represented by the open-end box.
If data flows are data in motion, think of data stores as data at rest.
Data stores should describe ``things’’ about which the business
wants to store data.
Gane & Sarson
Data Store Shape
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
59
Copyright Irwin/McGraw-Hill 1998
Process Modeling
System Concepts for Process Modeling

Data Stores



There should be one data store for each data entity on your entity
relationship diagram.
Data stores should be named as the plural of the corresponding
data model entity
 Avoid physical terms such as file, database, file cabinet, file
folder, and the like.
It is permissible to duplicate data stores on a DFD to avoid
crossing data flow lines.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
60
Copyright Irwin/McGraw-Hill 1998
Process Modeling
The Process of Logical Process Modeling

Strategic Systems Planning



Many organizations select application development projects based
on strategic information system plans.
Strategic planning produces an information systems strategy plan.
The information systems strategy plan defines an architecture for
information systems and this architecture frequently includes an
enterprise process model.
 An enterprise process model identifies only business areas and
functions.
 An enterprise process model usually takes the form of a
decomposition diagram and/or very high-level data flow
diagram.
 A enterprise process model is stored in a corporate repository.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
61
Copyright Irwin/McGraw-Hill 1998
Process Modeling
The Process of Logical Process Modeling

Process Modeling for Business Process Redesign


BPR projects analyze business processes and then redesign them to
eliminate inefficiencies and bureaucracies prior to any
(re)application of information technology.
In order to redesign business processes, the existing processes must
first be studied and documented using process models.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
62
Copyright Irwin/McGraw-Hill 1998
Process Modeling
The Process of Logical Process Modeling

Process Modeling during Systems Analysis


In systems analysis, the logical process model for a system or
application is an application process model.
In the heyday of the original structured analysis methodologies,
process modeling was also performed in the study phase of
systems analysis.
 Analysts would build a physical process model of the current
system, a logical model of the current system, and a logical
model of the target system.
 While conceptually sound, this approach led to “analysis
paralysis” - modeling overkill.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
63
Copyright Irwin/McGraw-Hill 1998
Process Modeling
The Process of Logical Process Modeling

Process Modeling during Systems Analysis


Today, most modern structured analysis strategies focus
exclusively on the logical model of the target system being
developed.
They are organized according to a strategy called event
partitioning.
 Event partitioning factors a system into subsystems based on
business events and responses to those events.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
64
Copyright Irwin/McGraw-Hill 1998
Process Modeling
The Process of Logical Process Modeling

Process Modeling during Systems Analysis

The strategy for event-driven process modeling is as follows:
 Step 1: A system context diagram is constructed to establish
initial project scope.
 Step 2: A functional decomposition diagram is drawn to
partition the system into logical subsystems and/or functions.
 Step 3: An event-response list is compiled to identify and
confirm the business events to which the system must provide a
response.
 Step 4: One process, called an event handler is added to the
decomposition diagram for each event.
 Step 5: An event diagram is constructed and validated for
each event.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
65
Copyright Irwin/McGraw-Hill 1998
Process Modeling
The Process of Logical Process Modeling

Process Modeling during Systems Analysis

The strategy for event-driven process modeling is as follows:
(continued)
 Step 6: A system diagram(s) is constructed by merging the
event diagrams.
 Step 7: A primitive diagram is constructed for each event
process.
• These data flow diagrams show all of the elementary processes,
data stores, and data flows for single events.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
66
Copyright Irwin/McGraw-Hill 1998
Process Modeling
E v e n t-R e s p o n s e L is t
even t 1
resp o n se
even t 2
resp o n se
even t 3
resp o n se
even t 4
resp o n se
resp o n se
1
3
resp o n se
resp o n se
The
...
S y s te m
The
S y s te m
2
F u n c tio n 1
4
5
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
Event 1
Event 2
F u n c tio n 2
Event 3
Event 4
Event 5
Event 5
Event 1
. . .
67
F u n c tio n n
. . .
. . .
E v e n t n -2
E v e n t n -1
Event n
Event n
. . .
Copyright Irwin/McGraw-Hill 1998
Process Modeling
Event 2
Event 1
E v e n t n -2
Event 4
Event n
6
E v e n t n -1
Event 5
Event 3
2 .3
. . .
2 .1
. . .
2 .4
7
2 .2
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
68
Copyright Irwin/McGraw-Hill 1998
Process Modeling
The Process of Logical Process Modeling

Looking Ahead to Systems Configuration and Design



The logical process model from systems analysis describes
business processing requirements of the system, not technical
solutions.
The purpose of the configuration phase is to determine the best
way to implement those requirements with technology.
During system design, the logical process model will be
transformed into a physical process model (called an application
schema) for the chosen technical architecture.
 This model will reflect the technical capabilities and limitations
of the chosen technology.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
69
Copyright Irwin/McGraw-Hill 1998
Process Modeling
The Process of Logical Process Modeling

Fact Finding and Information Gathering for Process
Modeling

Process models cannot be constructed without appropriate facts
and information as supplied by the user community.
 These facts can be collected by:
•
•
•
•
•
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
sampling of existing forms and files
research of similar systems
surveys of users and management
interviews of users and management
JAD
70
Copyright Irwin/McGraw-Hill 1998
Process Modeling
The Process of Logical Process Modeling

Computer-Aided Systems Engineering (CASE) for
Process Modeling


Process models are stored in the repository.
CASE technology provides the repository for storing the process
model and its detailed descriptions.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
71
Copyright Irwin/McGraw-Hill 1998
Process Modeling
How to Construct Process Models

The Context Diagram

Before we construct the actual process model, we need to establish
initial project scope.
 A project’s scope defines what aspect of the business a system
or application is supposed to support.
 A project’s scope also defines how the system or application
being modeled must interact with other systems and the
business as a whole.
 A project’s scope is documented with a context diagram.
• A context diagram defines the scope and boundary for the system
and project. Because the scope of any project is always subject to
change; the context diagram is also subject to constant change. A
synonym is environmental model.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
72
Copyright Irwin/McGraw-Hill 1998
Process Modeling
How to Construct Process Models

The Context Diagram

A strategy follows for determining the system’s boundary and
scope:
 Step 1: Think of the system as a ‘container’ in order to
distinguish the inside from the outside.
• Ignore the inner workings of the container .

Step 2: Ask your end-users what business events or
transactions a system must respond to.
• These are the net inputs to the system.
• For each net input, determine its source.
• Sources will become external agents on the context diagram.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
73
Copyright Irwin/McGraw-Hill 1998
Process Modeling
How to Construct Process Models

The Context Diagram

A strategy follows for determining the system’s boundary and
scope: (continued)
 Step 3: Ask your end-users what responses must be produced
by the system.
• These are the net outputs to the system.
• For each net output, determine its destination.
• Destinations may be external agents.

Step 4: Identify any external data stores.
• Many systems require access to the files or databases of other
systems.

Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
Step 5: Draw your context diagram from all of the preceding
information.
74
Copyright Irwin/McGraw-Hill 1998
Process Modeling
How to Construct Process Models

The Context Diagram




The context diagram contains one and only one process.
External agents are drawn around the perimeter.
External data stores are drawn around the perimeter.
Data flows define the interactions of your system with the
boundaries and with the external data stores.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
75
Copyright Irwin/McGraw-Hill 1998
Process Modeling
D
Club
M ember
Club Promotion
Othe r Order
Ne w M ember Subscription
Warehouse
M ember
Credit S tatus
M ember Orde r Re sponse
Potential
M ember
Ac counts
Re ceiv able
Da ta Ba se
P
Order to be Filled
M ember
Se rv ic es
Sys tem
Ne w M onthly P romotion
Subscription P rogram
Subscription Renew al
M arketing
De partme nt
Sa les a nd Promotions Reports
Pa st
M ember
M embership Re ports
M ember
Se rv ic es
M ember Reports
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
76
Copyright Irwin/McGraw-Hill 1998
Process Modeling
How to Construct Process Models

The Functional Decomposition Diagram



A decomposition diagram shows the top-down functional
decomposition or structure of a system.
A decomposition diagram provides the beginnings of an outline for
drawing data flow diagrams.
The following is an item-by-item discussion of the decomposition
diagram.
 Item 1: The root process corresponds to the entire system.
 Item 2: The system is initially factored into subsystems and/or
functions.
 Item 3: Factor the subsystems into the operational and
reporting aspects.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
77
Copyright Irwin/McGraw-Hill 1998
Process Modeling
M em b er S e rv ic e s
S y ste m
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
M em b ers h ip
P ro mo tio n s
O rd e rs
S u b sy ste m
S u b sy ste m
S u b sy ste m
P ro c es s
P ro c es s
M em b ers h ip
P ro mo tio n
O rd e r
T ra n sa c tio n s
T ra n sa c tio n s
T ra n sa c tio n s
G e n e rate
P ro c es s
G e n e rate
G e n e rate
M em b ers h ip
P ro mo tio n
O rd e r
R e p o rts
R e p o rts
R e p o rts
78
Copyright Irwin/McGraw-Hill 1998
Process Modeling
How to Construct Process Models

The Event-Response List


The purpose of this step is to determine what business events the
system must respond to, and what responses are appropriate.
Some of the inputs on the context diagram are associated with
events.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
79
Copyright Irwin/McGraw-Hill 1998
Process Modeling
How to Construct Process Models

The Event-Response List

There are three types of events.
 External events are so named because they are initiated by
external agents.
• External events are illustrated as input data flows.

Temporal events trigger processes on the basis of time, or
something that merely happens.
• Temporal events are illustrated as input control flows.

State events trigger processes based on a system’s change from
one state or condition to another.
• State events are illustrated as an input control flows.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
80
Copyright Irwin/McGraw-Hill 1998
Process Modeling
How to Construct Process Models

The Event-Response List



Each event should be named.
The name should reveal the system nature of the event – that is,
provide some insight as to at least one appropriate response.
The following guidelines for external and temporal events:
 External event - External agent name + reason for the data
flow.
• Example: CUSTOMER REQUESTS ACCOUNT BALANCE.

Temporal event - Time to + action that must be taken.
• Example: TIME TO BILL CUSTOMER ACCOUNTS.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
81
Copyright Irwin/McGraw-Hill 1998
Process Modeling
E V E N T L IS T
E v e n t D e s c rip tio n
M a rke tin g d e p a rtm e n t e sta b lish e s a n e w
m e m b e rsh ip p la n a n d o ffe r.
M a rke tin g d e p a rtm e n t te rm in a te s a
m e m b e rsh ip o ffe r.
T rig g e r (In p u ts )
S U B S C R IP T IO N P R O G R A M
R e s p o n s e s (O u tp u ts )
S U B S C R IP T IO N P LA N C O N F IR M A T IO N
CREATE AGREEMENT
S U B S C R IP T IO N P R O G R A M T E R M IN A T IO N
S U B S C R IP T IO N P LA N T E R M IN A T IO N N O T IC E
D E LE T E A G R E E M E N T
UPDATE MEMBERS
P o te n tia l m e m b e r re sp o n d s to a su b scrip tio n
o ffe r.
N E W M E M B E R S U B S C R IP T IO N
P o te n tia l m e m b e r is re fe rre d to m e m b e rsh ip b y
a cu rre n t m e m b e r.
R E F E R A L S U B S C R IP T IO N
S U B S C R IP T IO N C O N F IR M A T IO N
R EFER AL BO N U S O R D ER
S U B S C R IP T IO N R E J E C T IO N
P o te n tia l m e m b e r e xe rcise s 1 0 d a y ca n ce lla tio n
o p tio n .
C lu b m e m b e r ch a n g e s n a m e o r a d d re ss.
T im e to ca n ce l th o se in a ctive m e m b e rs.
S U B S C R IP T IO N C A N C E LLA T IO N
M a rke tin g d e p a rtm e n t e sta b lish e s a n e w
m o n th ly o r se a so n a l p ro m o tio n .
M e m b e r re sp o n d s to d a te d p ro m o tio n a l o rd e r.
M O N T H LY P R O M O T IO N
DATED ORDER
S E A S O N A L P R O M O T IO N
CREATE ORDER
MEMBER ORDER RESPONSE
O R D E R T O B E F ILLE D
S U B S C R IP T IO N C O N F IR M A T IO N
S U B S C R IP T IO N R E J E C T IO N
CREATE MEMBER
CREATE MEMBER
S U B S C R IP T IO N C A N C E LLA T IO N N O T IC E
D E LE T E M E M B E R
MEMBER CHANGE OF NAME OR ADDRESS
UPDATE MEMBER
IN A C T IV IT Y C H E C K
C A N C E LLE D M E M B E R S R E P O R T
UPDATE MEMBER
C R E D IT P R O B LE M N O T IF IC A T IO N
UPDATE MEMBER
UPDATE ORDER
UPDATE PRODUCT
T im e to a u to m a tica lly fill o rd e r fo r w h ich
m e m b e r h a s n o t re p lie d to d a te d p ro m o tio n .
D A T E D O R D E R D E A D LIN E
O R D E R T O B E F ILLE D
D E LE T E O R D E R
CREATE ORDER
UPDATE ORDER
UPDATE MEMBER
UPDATE PRODUCT
T im e to p ro d u ce p ro m o tio n a n a lyse s
T im e to a n a lyze sa le s.
E N D O F P R O M O T IO N
P R O M O T IO N A N A LYS IS R E P O R T
END OF MONTH
S A LE S A N A LYS IS R E P O R T
END OF QUARTER
E N D O F F IS C A L YE A R
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
82
Copyright Irwin/McGraw-Hill 1998
Process Modeling
How to Construct Process Models

The Event-Decomposition Diagram




The purpose of this step is to further partition our functions in the
decomposition diagram.
Simply add event handling processes (one per event) to the
decomposition.
If the entire decomposition diagram will not fit on a single page,
add separate pages for subsystems or functions.
The root process on a subsequent page should be duplicated from
an earlier page to provide a cross reference.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
83
Copyright Irwin/McGraw-Hill 1998
Process Modeling
M e m b e r S e r v ic e s
S y s te m
M e m b e rs h ip
P ro m o t io n s
O r d e rs
S u b s y s te m
S u b s y s te m
S u b s y s te m
P ro c e s s
G e n e ra te
P ro c e s s
G e n e ra te
P ro c e s s
M e m b e rs h ip
M e m b e rs h ip
P ro m o t io n
P ro m o t io n
O rd e r
O rd e r
T ra n s a c tio n s
R e p o rts
T ra n s a c tio n s
R e p o rts
T ra n s a c tio n s
R e p o rts
P ag e
P ag e
P ag e
P ag e
2
2
3
3
G e n e ra te
G e n e ra te
G e n e ra te
G e n e ra te
R e s p o n d to
In a c tiv e
M em be r
A g re e m t
M e m b e rs h ip
M em be r
M em be r
A c t iv ity
C o m p lia n c e
L is t
In q u iry
R e p o rt
R e p o rt
Rpt
G e n e ra te
P ro c e s s
P ro c e s s
P ro c e s s
P ro c e s s
Cha ng e
M ov e
Can c e l
New
R e fe rra l
S u b s c r ip tio n
N a me /
M em be r
M e m b e r to
In a c tiv e
M em be r
M em be r
S u b s c r ip tio n
Can c e l
A d d re s s
A g re e m e n t
a N e w C lu b
M e m b e rs
C a n c e lla tio n
S u b s c r ip tio n
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
P ro c e s s
Cha ng e
84
Copyright Irwin/McGraw-Hill 1998
Process Modeling
How to Construct Process Models

The Event Diagram


Using the decomposition diagram as an outline, one event diagram
can be constructed for each event process.
 An event diagram is a context diagram for a single event. It
shows the inputs, outputs, and data store interactions for the
event.
Most event diagrams contain a single process – the same process
that was named to handle the event on the decomposition diagram.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
85
Copyright Irwin/McGraw-Hill 1998
Process Modeling
How to Construct Process Models

The Event Diagram

For each event, illustrate the following:
 The input(s) and its source(s).
• Sources are depicted as external agents.
• The data structure for the input should be recorded in the
repository.

The outputs and their destinations.
• Destinations are depicted as external agents.
• The data structure for the output should be recorded in the
repository.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
86
Copyright Irwin/McGraw-Hill 1998
Process Modeling
How to Construct Process Models

The Event Diagram

For each event, illustrate the following: (continued)
 Any data stores from which records must be ‘read’ should be
added to the event diagram.
• Data flows should be added and named to reflect what data is read
by the process.

Any data stores in which records must be ‘created’, ‘deleted’,
or ‘updated’ should be included in the event diagram.
• Data flows to the data stores should be named to reflect the nature
of the update.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
87
Copyright Irwin/McGraw-Hill 1998
Process Modeling
E v e nt D ia g ra m
E v e nt: M e m b e r c ha ng e s na me o r a d d re s s
P
Member
N ame/ Address Change Confirm
Proc ess
Change of
Address
U pdate to N ame/ Address
D
Members
Change of Address
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
88
Copyright Irwin/McGraw-Hill 1998
Process Modeling
Event Diagram
Event: Member responds to promotional order.
Original Dated Order
D
D
Orders
Accounts
Receivable DB
Update to Order Status
Update: Order Changes
Credit Rating and Limits
Member Order Response
Member
Backorder
P
Process
Member Order
Response
Warehouse
Picking Ticket
Update to Membership Credits
Product Availability
D
Memberships
D
Members
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
Update to Agreement Stats
Member Address
89
D
Products
D
Agreements
Copyright Irwin/McGraw-Hill 1998
Process Modeling
Eve nt Dia gram
Eve nt: De adline for member to reposnd to dated order has passed.
Original Dated Order
D
Orders
D
Accounts
Rece iva ble DB
Update to Order Sta tus
Update: Order Changes
Credit Rating
and Limits
P
Deadline to Fill Dated Order
Automatically
Fill Da ted Order
Warehouse
Picking Ticket
Update to
Membership
Credits
D
Memberships
D
Members
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
Product Availability
Member Address
Update to Agreement Stats
90
D
Products
D
Agreements
Copyright Irwin/McGraw-Hill 1998
Process Modeling
How to Construct Process Models

The Event Diagram


Each event process should be described to the CASE repository
with the following properties:
 Event sentence – for business perspective.
 Throughput requirements – the volume of inputs per some
period of time.
 Response time requirements – how fast the typical event must
be handled.
 Security, audit, and control requirements.
 Archival requirements (from a business perspective).
All of the above properties can be added to the descriptions
associated with the appropriate processes, data flows, and data
stores on the model.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
91
Copyright Irwin/McGraw-Hill 1998
Process Modeling
How to Construct Process Models

The System Diagram




The system diagram is said to be ‘exploded’ from the single
process that was created on the context diagram.
The system diagram(s) shows either:
 all of the events for the system on a single diagram
 all of the events for a single subsystem on a single diagram
Depending on the size of the system, a single diagram may be too
large.
Synchronization is the balancing of data flow diagrams at
different levels of detail to preserve consistency and completeness
of the models.
 Synchronization is a quality assurance technique.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
92
Copyright Irwin/McGraw-Hill 1998
Process Modeling
Figure 6-27
We are sorry but
the diagram is
currently not
available. Please
refer to your
textbook, pages
250 and 251.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
93
Copyright Irwin/McGraw-Hill 1998
Process Modeling
How to Construct Process Models

The System Diagram


The event diagram processes are merged into the system diagrams.
It is very important that each of the data flows, data stores, and
external agents that were illustrated on the event diagrams be
represented on the system diagrams.
 This is called balancing.
 Most CASE tools include facilities to check balancing for
errors.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
94
Copyright Irwin/McGraw-Hill 1998
Process Modeling
How to Construct Process Models

The System Diagram


When creating a system diagram, do not consolidate data stores –
otherwise, you will create balancing errors between the system and
event diagrams.
You may elect to consolidate some data flows (from event
diagrams) into composite data flows on the system diagram.
 If you do, be sure to use junctions on the event diagrams to
demonstrate how the elementary data flows are derived from
the composite data flows.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
95
Copyright Irwin/McGraw-Hill 1998
Process Modeling
How to Construct Process Models

Primitive Diagrams



Each event process on the system diagram(s) must be exploded
into either:
 a procedural description
 a primitive data flow diagram
For event processes that are not very complex – in other words,
they are both an event and an elementary process, they should be
described in one page (usually much less) of Structured English.
Event processes with more complex event diagrams should be
exploded into a more detailed, primitive data flow diagram.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
96
Copyright Irwin/McGraw-Hill 1998
Process Modeling
How to Construct Process Models

Primitive Diagrams


A primitive DFD shows detailed processing requirements for the
event.
A primitive DFD shows several elementary processes for the event
process.
 Each elementary process is cohesive – that is, it does only one
thing.
 Each of the elementary processes can now be described with
procedural Structured English specifications, and where
appropriate, decision tables.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
97
Copyright Irwin/McGraw-Hill 1998
Process Modeling
Back order
Invalid Product ID
M em ber De mogr aphics
P
Invalid M em be r ID
Validate
M em ber
Updated Me mber De mographics
D
M em ber s
Or iginal Dated Order
D
Or de rs
D
Or de red Pr oducts
D
Pr oducts
M em ber ID and Addr ess
Update: Order Changes
Update Order Product
P
Check
Or de red
Pr oduct
Validity
Or de red Pr oduct ID
Pr oduct ID
M em ber
M em ber Or de r
Re spons e
Valid Product
Pr oduct Availability
P
Check Product
Availability
Inventor y Com mitme nt
Update Ordere d Product Status
Or de red
Pr oduct
Quantity
Available Pr oduct
and Quantity
P
Calculate
Extende d
Cost
Pr oduct Price
Or de red Pr oduct Extended Pr ice
P
P
Check
M em ber Cr edit
Calculate
Or de r Total
Cost
Total Or der Pr ice
Paym ent M ethod and Am ount
Pr e-Paym e nt Reques t
Cr edit Rating and Lim its
Fillable Ordere d Product
Fillable Order
D
Accounts
Re ce ivable DB
Update to Orde r Status
Ware house
Picking Tick et
P
P
Re lease Or der
to Warehouse
Cr edit M em be r
Purchas e
M em ber Addr ess
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
D
D
Or de rs
M em ber s
Update to M em be rship Cre dits
D
M em ber ships
D
Agre em ents
Updated Activity Record
Elem entary Pr oce ss es for
Pr oce ss Me m ber Or der Re spons e
R. Martinez
as of March 6, 1997
Update to Agre em ent Stats
98
Copyright Irwin/McGraw-Hill 1998
Process Modeling
The Next Generation

The Next Generation


Process modeling skills remain valuable for two reasons:
 The current interest of business process redesign requires
process models.
 Process models are included in many object modeling strategies
such as the Object Modeling Technique (OMT).
Business process design emphasizes physical process modeling.
 Physical process models include those processes which reflect
the current implementation.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
• This may include sequential processes that merely edit, route, copy
or approve a data flow.
• Physical data flow diagrams also include additional details such as
who or what performs each process, the cost of each process, and a
critical evaluation of the value returned by each process.
99
Copyright Irwin/McGraw-Hill 1998
Process Modeling
Summary






Introduction
An Introduction to System Modeling
System Concepts for Process Modeling
The Process of Logical Process Modeling
How to Construct Process Models
The Next Generation
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
100
Copyright Irwin/McGraw-Hill 1998
Descargar

Object Oriented Analyis & Design Training Agenda