system analysis and design Chap008

Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved
Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 5th Edition
8
C H A P T E R
PROCESS
MODELING

Chapter Eight Process Modeling
• Define systems modeling and differentiate between logical and physical system
models.
• Define process modeling and explain its benefits.
• Recognize and understand the basic concepts and constructs of a process model.
• Read and interpret a data flow diagram.
• Explain when to construct process models and where to store them.
• Construct a context diagram to illustrate a system’s interfaces with its work
environment.
• Identify use cases, external and temporal business events for a system.
• Perform event partitioning and organize events in a functional decomposition
diagram.
• Draw event diagrams and merge those events into a system diagram.
• 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.
• Document the distribution of processes to locations.
• Synchronize data and process models using a CRUD matrix.

Chapter Map

Models: Logical and Physical
Logical models show
what a system is or does.
They are implementation
independent; that is, they
depict the system
independent of any
technical implementation.
Physical models show not
only what a system is or
does, but also how the
system is (to be) physically
and technically implemented.
They are implementation
dependent because they
reflect technology choices.
A model is a representation of reality. Just as a
picture is worth a thousand words, most models are
pictorial representations of reality.

Why Logical System Models
• Logical models remove biases that are the result of the
way the system is currently 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 results.
• Logical models allow us to communicate with end-
users in nontechnical or less technical languages.

Process Modeling and DFDs
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.
A data flow diagram (DFD) is a tool (and type of process
model) that depicts the flow of data through a system and
the work or processing performed by that system.
DFDs have become a popular tool for business process
redesign.

Simple Data Flow Diagram

Differences Between DFDs and Flowcharts
• Processes on DFDs can operate in parallel (at-the-
same-time)
– Processes on flowcharts execute one at a time
• DFDs show the flow of data through a system
– Flowcharts show the flow of control (sequence and
transfer of control)
• Processes on one DFD can have dramatically different
timing
– Processes on flowcharts are part of a single program
with consistent timing

Systems Thinking
Systems thinking is the application of formal systems
theory and concepts to systems problem solving.
DFDs are a tool that supports systems thinking.

Process Concepts
A process is work
performed on, or
in response to,
incoming data
flows or
conditions.
A System is a Process
T h e
S y s t e m
is a
P r o c e s s
in p u t o u t p u t
in p u t
in p u t o u t p u t
o u t p u t
F e e d a c k a n d
C o n t r o l L o o p
T h e S y s t e m 's E n v ir o n m e n t
( c o n s t a n t ly c h a n g in g )
A
P r o c e s s

System Decomposition
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.

Decomposition Diagrams
A decomposition
diagram or
hierarchy chart
shows the top-
down, functional
decomposition of
a system.

Types of Logical Processes
• A function is set of related and ongoing activities of a
business.
• An event (or transaction) is a logical unit of work that
must be completed as a whole (as part of a function).
• An elementary process (or primitive process) is a
discrete, detailed activity or task required to respond to
an event. Usually, several such tasks must be
completed to respond to an event.

Common Process Errors on DFDs

PROBLEMS WITH NATURAL ENGLISH 1
Source: Adapted from Matthies, Leslie, The New Playscript Procedure,
(Stamford, CT: Office Publications, Inc. 1977)
Problems with Natural English
• Many of us do not write well, and we also tend not to question our writing abilities.
• Many 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. For 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.
• Some 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.
• English 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.” Does 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? Or 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?
• We overuse compound sentences Consider the following procedure: “Remove the screws that hold the outlet
cover to the wall. Remove the outlet cover. Disconnect 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. For example, an loan officer asks a teacher to certify that a
student is in good academic standing. What is good?
• Conditional instructions can be imprecise. For 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?
• Compound conditions tend to show up in natural English. For 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.

1. For each CUSTOMER NUMBER in the data store CUSTOMERS:
a. For each LOAN in the data store LOANS that matches the above
CUSTOMER NUMBER:
1) Keep a running total of NUMBER OF LOANS for the
CUSTOMER NUMBER.
2) Keep a running total of thw ORIGINAL LOAN PRINCIPALfor the
CUSTOMER NUMBER.
3) Keep a running total of CURRENT LOAN BALANCE for the
CUSTOMER NUMBER.
4) Keep a running total of AMOUNTS PAST DUE for the
CUSTOMER NUMBER.
b. If the TOTAL AMOUNTS PAST DUE for the CUSTOMER NUMBER
is greater than $100.00 then:
1) Write the CUSTOMER NUMBER and all their data attributes
as described in the data flow LOANS AT RISK.
Else
1) Exclude the CUSTOMER NUMBER and data from the data
flow LOANS AT RISK.
Structured English
Structured English is a language and syntax, based on the
relative strengths of structured programming and natural
English, for specifying the underlying logic of
elementary processes on DFDs.

Structured English Constructs (Part 1)

complex logic in which rows represent conditions

Policies and Decision Tables
A policy is a set of rules that governs some process of
the business.
A decision table is a tabular form of presentation that
specifies a set of conditions and their corresponding
actions (as required to implement a policy).

A Simple Decision Table

• A data flow represents an input of data to a process, or
the output of data from a process.
– A data flow may also be used to represent the
creation, reading, deletion, or updating of data in a file
or database (called a data store).
– A composite data flow is a data flow that consists of
other data flows.
• A control flow represents a condition or nondata event
that triggers a process.
– Used sparingly on DFDs.
Data Flows & Control Flows

Data Flow Packet Concept

Composite and Elementary Data Flows

Data Flows to and from Data Stores

Illegal Data Flows

Data Structures
Data flows can be defined by data structures.
A data structure is a specific arrangement of data
attributes that defines the organization of data contained
in a data flow.
A data attribute is the smallest piece of data that has
meaning to the end-users of a business.

A Data Structure for a Data Flow
DATA STRUCTURE
ORDER=
ORDER NUMBER +
ORDER DATE+
[ PERSONAL CUSTOMER NUMBER,
CORPORATE ACCOUNT NUMBER]+
SHIPPING ADDRESS=ADDRESS+
(BILLING ADDRESS=ADDRESS)+
1 {PRODUCT NUMBER+
PRODUCT DESCRIPTION+
QUANTITY ORDERED+
PRODUCT PRICE+
PRODUCT PRICE SOURCE+
EXTENDED PRICE } N+
SUM OF EXTENDED PRICES+
PREPAID AMOUNT+
(CREDIT CARD NUMBER+EXPIRATION
DATE)
(QUOTE NUMBER)
ADDRESS=
(POST OFFICE BOX NUMBER)+
STREET ADDRESS+
CITY+
[STATE, MUNICIPALITY]+
(COUNTRY)+
POSTAL CODE
ENGLISH ENTERPRETATION
An instance of ORDER consists of:
ORDER NUMBER and
ORDER DATE and
Either PERSONAL CUSTOMER NUMBER
or CORPORATE ACCOUNT NUMBER
and SHIPPING ADDRESS (which is equivalent
to ADDRESS)
and optionally: BILLING ADDRESS (which is
equivalent to ADDRESS)
and one or more instances of:
PRODUCT NUMBER and
PRODUCT DESCRIPTION and
QUANTITY ORDERED and
PRODUCT PRICE and
PRODUCT PRICE SOURCE and
EXTENDED PRICE
and SUM OF EXTENDED PRICES and
PREPAID AMOUNT and
optionally: both CREDIT CARD NUMBER and
EXPIRATION DATE
An instance of ADDRESS consists of:
optionally: POST OFFICE BOX NUMBER and
STREET ADDRESS and
CITY and
Either STATE or MUNICIPALITY
and optionally: COUNTRY
and POSTAL CODE

Data Structure Constructs
Data Structure
Sequence of Attributes - The
sequence data structure indicates one
or more attributes that may (or must)
be included in a data flow.
Selection of Attributes - The
selection data structure allows you to
show situations where different sets
of attributes describe different
instances of the data flow.
Repetition of Attributes - The
repetition data structure is used to set
off a data attribute or group of data
attributes that may (or must) repeat
themselves a specific number of time
for a single instance of the data flow.
The minimum number of repetitions
is usually zero or one.
The maximum number of
repetitions may be specified as “n”
meaning “many” where the actual
number of instances varies for each
instance of the data flow.
Format by Example
(relevant portion is boldfaced)
WAGE AND TAX STATEMENT=
TAXPAYER IDENTIFICATION NUMBER+
TAXPAYER NAME+
TAXPAYER ADDRESS+
WAGES, TIPS, AND COMPENSATION+
FEDERAL TAX WITHHELD+…
ORDER=
(PERSONAL CUSTOMER NUMBER,
CORPORATE ACCOUNT NUMBER)+
ORDER DATE+…
CLAIM=
POLICY NUMBER+
POLICYHOLDER NAME+
POLICY HOLDER ADDRESS+
0 {DEPENDENT NAME+
DEPENDENT’S RELATIONSHIP} N+
1 {EXPENSE DESCRIPTION+
SERVICE PROVIDER+
EXPENSE AMOUNT} N
English Interpretation
An instance of WAGE AND TAX STATEMENTS
consists of:
TAXPAYER IDENTIFICATION NUMBER and
TAXPAYER NAME and
TAXPAYER ADDRESS and
WAGES, TIPS AND COMPENSATION and
FEDERAL TAX WITHHELD and…
An instance or ORDER consists of:
Either PERSONAL CUSTOMER NUMBER or
CORPORATE ACCOUNT NUMBER; and
ORDER DATE and…
An instance of CLAIM consists of:
POLICY NUMBER and
POLICYHOLDER NAME and
POLICYHOLDER ADDRESS and
zero or more instance of:
DEPENDENT NAME and
DEPENDENT’S RELATIONSHIP and
one or more instances of:
EXPENSE DESCRIPTION and
SERVICE PROVIDER and
EXPENSE ACCOUNT

Data Structure Constructs (concluded)
Data Structure
Optional Attributes - The optional
notation indicates that an attribute, or
group of attributes in a sequence or
selection date structure may not be
included in all instances of a data
flow.
Note: For the repetition data
structure, a minimum of “zero” is the
same as making the entire repeating
group “optional.”
Reusable Attributes - For groups of
attributes that are contained in many
data flows, it is desirable to create a
separate data structure that can be
reused in other data structures.
Format by Example
CLAIM=
POLICY NUMBER+
POLICYHOLDER NAME+
POLICYHOLDER ADDRESS+
( SPOUSE NAME+
DATE OF BIRTH)+…
DATE=
MONTH+
DAY+
YEAR+
English Interpretation
An instance of CLAIM consists of:
POLICY NUMBER and
POLICYHOLDER NAME and
POLICYHOLDER ADDRESS and
optionally, SPOUSE NAME and
DATE OF BIRTH and...
Then, the reusable structures can be included in other
data flow structures as follows:
ORDER=ORDER NUMBER…+DATE
INVOICE=INVOICE NUMBER…+DATE
PAYMENT=CUSTOMER NUMBER…+DATE

Data Types and Domains
Data attributes should be defined by data types and
domains.
A data type defines what class of data can be stored in an
attribute (e.g., character, integers, real numbers, dates,
pictures, etc.).
A domain defines what values or range of values an
attribute can legitimately take on.

Diverging and Converging Data Flows
• A diverging data flow is one that splits into multiple
data flows.
– Useful for illustrating data that starts out naturally as
one flow, but needs to be routed to parallel processes.
– Also useful for illustrating multiple copies of the same
output going to different destinations.
•
A converging data flow is the merger of multiple data
flows into a single packet.
– Useful for illustrating data from multiple sources that
must come back together for some subsequent
processing

Diverging and Converging Data Flows

External
Agent
External Agents
• An external agent defines a person, organization unit,
or other organization that lies outside of the scope of
the project but that interacts with the system being
studied.
– External agents define the “boundary” or scope of a
system being modeled.
– As scope changes, external agents can become
processes, and vice versa.
– Almost always one of the following:
• Office, department, division inside the business but outside
the system scope.
• An external organization or agency.
• Another business or another information system.
• One of your system’s end-users or managers

Data
Store
Data Stores
• A data store is an inventory of data.
– Frequently implemented as a file or database.
– A data store is “data at rest” compared to a data flow
that is “data in motion.”
– Almost always one of the following:
• Persons
(or groups of persons)
• Places
• Objects
• Events
(about which data is captured)
• Concepts
(about which data is important)
– Data stores depicted on a DFD store all instances of
data entities (depicted on an ERD)

When to Draw Process Models
• Strategic systems planning
– Enterprise process models illustrate important
business functions.
• Business process redesign
– “As is” process models facilitate critical analysis.
– “To be” process models facilitate improvement.
• Systems analysis (primary focus of this course)
– Model the existing system including its limitations
– Model the target system’s logical requirements
(meaning processes and data flows needed regardless
of how the system will be implemented)
– Model candidate technical solutions (physical DFDs
only)
– Model the target technical solution (physical DFDs
only)

Classical Structured Analysis
1. Draw top-down physical DFDs that represent the current
physical implementation of the system including its limitations.
2. Convert the physical DFDs to their logical equivalents.
3. Draw top-down logical DFDs that represent an improved
system.
4. Describe all data flows, data stores, policies, and procedures in
a data dictionary or encyclopedia.
5. Optionally, mark up copies of the logical DFDs to represent
alternative physical solutions.
6. Draw top-down physical DFDs that represent the target
solution.
THE ABOVE METHODOLOGY IS RARELY PRACTICED
ANYMORE BECAUSE IT IS VERY CUMBERSOME AND
TIME-CONSUMING.

Modern Structured Analysis
1. Draw a context DFD to establish initial project scope.
2. Draw a functional decomposition diagram to partition the
system into subsystems.
3. Create an event-response or use-case list for the system to
define events for which the system must have a response.
4. Draw an event DFD (or event handler) for each event.
5. Merge event DFDs into a system diagram (or, for larger
systems, subsystem diagrams).
6. Draw detailed, primitive DFDs for the more complex event
handlers.
7. Document data flows and processes in the data dictionary.
THE ABOVE METHODOLOGY, BASED ON EVENT
PARTITIONING, IS MORE COMMONLY PRACTICED.

Structured Analysis Diagram Progression (1 of 3)

CASE for DFDs (Sample Screen) from System Architect 2001

SoundStage Context DFD
Member
Services
System
Potential
Member
Club
Member
Marketing
Department
Warehouse
Accounts
Receivable
Past
Member
Member
Services
various Inquiry Reponses
various Sales Reports
various
Promotion Reports
Subscription Offer
Member Order
New Subscription
Promotion
Subscription Renewal
Resubscription Offer
various Member
Reports
various Subscription Reports
Subscription Program
New Promotion
Revised Packing Order
Member
Credit
Status

SoundStage Functional Decomposition Diagram
Order
Subsystem
Promotion
Subsystem
Operations
Subsystem
Subscription
Subsystem
Member
Services
System
Process
Order
Transactions
Generate
Promotion
Reports
Process
Membership
Transactions
Process
Promotion
Transactions
Generate
Subscription
Reports
Generate
Order
Reports
Process
Marketing
Transactions
Process
Subscription
Transactions
Process
Warehouse
Transactions

Events
• Events define processes needed to respond to those
events.
– External events are those initiated by external agents.
They result in an input transaction or data flow.
– Temporal events are those that are triggered by the
passage of time. They simply “happen” and are
indicated by a control flow.
– State events are those based on a system’s change
from one state to another.

Use Cases
• Use cases are based upon object-oriented concepts that
are essentially the same as events.
– Use case analysis is the process of identifying and
modeling business events and how the system
responds to them.
– An actor is anything that needs to interact with the
system (essentially, a synonym for external agent).

membership subscription plan
AGREEMENT
Logically Delete (void)
in the database.
Use Case List
Actor Event (or Use Case) Trigger Responses
Marketing Establishes a new
to entice new members.
NEW MEMBER SUBSCRIPTION
PROGRAM
Generate SUBSCRIPTION
PLAN CONFIRMATION.
Create AGREEMENT in the
database.
Marketing Establishes a new
membership resubscription
plan to lure back former
members.
PAST MEMBER
RESUBSCRIPTION PROGRAM
Generate SUBSCRIPTION
PLAN CONFIRMATION.
Create AGREEMENT in the
database.
Marketing Changes a subscription plan
for current members (e.g.,
extending the fulfillment
period)
SUBSCRIPTION PLAN
CHANGE.
Generate AGREEMENT
CHANGE CONFIRMATION.
Update AGREEMENT in the
database.
(time) A subscription plan expires. (current date) Generate AGREEMENT

Generate
Logically Delete (void)
AGREEMENT
Generate MEMBER
DIRECTORY UPDATE
CONFIRMATION.
Create MEMBER in the
database.
Create first
MEMBER ORDERED
PRODUCTs in the database.
Generate MEMBER
DIRECTORY UPDATE
CONFIRMATION.
Update MEMBER in the
database.
Use Case List (continued)
Marketing Cancels a subscription plan
before its planned expiration CANCELATION
in the database.
Member Joins the club by subscribing.
(“Take any 12 CDs for one
penny and agree to buy 4
more at regular prices within
two years.”)
NEW SUBSCRIPTION
MEMBER ORDER
Member hanges address
(including email and privacy
code)
CHANGE OF ADDRESS

Generate CREDIT
DIRECTORY UPDATE
CONFIRMATION.
Update MEMBER in the
database.
Generate
CONFIRMATION.
Logically Delete
(deactivate) PRODUCT
database.
Generate CATALOG
DESCRIPTION.
Changes member’s credit
status
90 days after a Marketing
decides to no longer sell a
product.
Wants to pick products for
possible purcase.
(Logical requirement is driven
by vision of web-based access
Use Case List (continued)
Accounts
Receivable
CHANGE OF CREDIT STATUS
(time) (current date) CATALOG CHANGE
in the
Member PRODUCT INQUIRY

Event Decomposition Diagram (partial)
Member
Services
System
Process
Member
Change of
Preferences
Process
Former
Member
Resubscrip-
tion
Process
Subscription
Plan
Cancelation
Process
Member
Change of
Address
Process
Subscription
Plan Expiration
Generate
Inactive
Member
Report
Process
Change
to a
Subscription
Plan
Generate
Quarterly
Subscription
Report
Process New
Member
Subscription
Process
New
Resubscrip-
tion Plan
Generate
Membership
Directory
Generate
Subscription
Analysis
Report
Process
New
Subscription
Plan
Generate
Agreement
Compliance
Report
Promotion
Subsystem
Order
Subsystem
Operations
Subsystem
Subscription
Subsystem
Process
Membership
Transactions
Process
Warehouse
Transactions
Process
Marketing
Transactions
Generate
Subscription
Reports
Generate
Order
Reports
Process
Order
Transactions
Process
Promotion
Transactions
Process
Subscription
Transactions
Generate
Promotion
Reports
Pg
4
Pg
3
Pg
2

External Event DFD
Process
Member
Address
Change
Club
Member Members
Member Updated Address Confirmation
Updated
Member
Address
Member Change
of Address

External Event DFD (more complex)
Process
Member
Order
Club Member Warehouse
Accounts
Receivable
Products
Members
Member
Ordered
Products
Member
Orders
Member
Order
Confirmation
New
Member
Ordered
Products
New
Member
Order
Inventory Commitment
Product
and
Availability
Relevant
Transactions
Updated Member
from Order
Member
Packing Order
Member Order

Temporal Event DFD
Identify
Agree-
ments
Near
Default
Calendar Agreements
Manager
AgreementsMembers
AgreementFulfillment
Progress
Agreement
Default
Exception
ReportEnd of Month

System DFD (see book for more readable copy)
Generate
Order Analysis
Report
Process
Member Order
Cancelation
Process
Member Order
Revision
Process
Subscription
Order
Process
Member Order
Club
Directors
TimeWarehouse
Warehouse
Member
Member
Member
Member Ordered
Products
Products
Transactions
Products
Member Orders
Member Orders
Members
Members
Inventory Commitment
Product and Availability
Address
New Member Order
New Member
Ordered Products
Member
Order
Cancelation
Notice
Updated
Member
Deleted
Member
Order
Deleted Member
Ordered Products
Order
Analysis
Report
End of Day
Orders
Ordered
Products
Packing Order
Packing Order
Member Order Confirmation
Inventory
Commitment
Product and
Availability
Updated Member
from Updated Order
Updated
Member
Ordered
Products
Updated
Member
Order
Member
New Member
Ordered
Products
Relevant
Transactions
Inventory
Commitmen
t
Product and
Availability
New
Member
Order
Updated Member
from Order
Member
Subscription
Order
Confirmation
Member Order
Confirmation
Revised
Packing Order
Member Order
Cancelation
Member
Order
Change
Request
Subscription Order
Member Order

Primitive DFD (see book for more readable copy)
Record Order Release Order
Check Member
Credit
Calculate
Order Cost
Check Product
Availability
Validate
Ordered
Product
Validate
Member
Warehouse
Member
Member Ordered
Products
Members
Products
Members
Transactions
Member Orders
Order to be Filled
Updated Credits
Confirmed Member Order
Packing
Order
Order to be Filled
Credit Details
Credit Problem and Instruction
Product Price
Invalid
Order
Invalid Member ID
Invalid Product ID
Inventory Comittment
Product Availability
Product
Updated Member from Order
Member
Cost to
Member
Available
Product
Valid
Product
Bonus
Credits
Claimed
Ordered
Product ID
Payment
Ordered
Product
Quantity
Member ID
and Address
Member Order
Relevant
Transactions
New Member
Ordered Products
New
Member
Order

Data Structure for a Primitive Data Flow
Data
Structure
Data Flow

Logic for a Primitive Process
Logic
Process

8.30 Data to Process CRUD Matrix

8.31 Process to Location Association Matrix

system analysis and design Chap008

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (17)

Ähnlich wie system analysis and design Chap008

Ähnlich wie system analysis and design Chap008 (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

system analysis and design Chap008

Hinweis der Redaktion